Можно сказать, что все начиналось с книги Роберта Хайнлайна "Дверь в лето", выпущенной в свет в 1956 г. В ней главный герой чертил (именно чертил) на фантастической машине под названием Drafting Dan. В 1961 г. Айван Сазерленд создал первое воплощение "господина чертежника" (Dan -- не только уменьшительная форма имени, но и устаревшее "господин") в форме систем уравнений Sketchpad. На сегодняшний день о заслугах Сазерленда лучше всего сказать так: "В Sketchpad есть все, что можно найти в современных CAD-решениях". Но от набора уравнений до готового к применению сотнями тысяч людей продукта путь оказался несоизмеримо более долгим, чем от идеи Хайнлайна до Sketchpad. Следующий шаг на этом пути сделал Пат Ханратти, создавший первое ядро геометрического моделирования с символичным названием ADAM (именно на нем компания--пионер на CAD-рынке Computervision построила первую систему трехмерного моделирования CADDS). Еще один шаг сделали основатели многих существующих по сей день компаний -- представители большой промышленности (в первую очередь автомобильной и авиационной). В те времена (конец 60-х -- начало 70-х годов) они еще не именовались IT-персоналом, но начинали свою карьеру как "карманные" CAD-разработчики у конкретных производителей. Тогда же начинался и первый всплеск роста ОС Unix, и первая волна "недорогих вычислений" -- 32-битные процессоры Motorola, мини-компьютеры, рабочие станции. CAD-системы тех времен полностью адекватны и возможностям техники, и специфике неспешной, академической подготовки кадров: криптографический командный интерфейс (разработчику всегда проще переложить ответственность за изучение сложного, но удобного с программной точки зрения командного языка на пользователя, чем написать сложный в машинной интерпретации, но удобный с точки зрения пользователя командный язык), концентрация усилий больше на высокоэффективной реализации базовых концепций, чем на совершенствовании и развитии этих концепций. В целом же "в точке расцвета" это был период, полностью аналогичный "структурному программированию", -- повторное использование созданных конструкций на уровне подпрограмм (фрагментов чертежа или модели), требующее внутренних модификаций данных подпрограмм для корректировки их характеристик (фактически -- переделывания части конструкции, когда изменение, например, всего одного размера ведет к полному ручному пересчету всех остальных размеров, проверке их согласования и т. д.). Взрыв произошел примерно в то же время, когда и в программировании, -- во второй половине 80-х годов тогда еще особо ничем не выдающаяся и неизвестная компания PTC (Parametric Technology Corporation) анонсировала объектно-ориентированный CAD -- трехмерную параметрическую систему моделирования с использованием конструктивных особенностей (design features). Параметризация модели на деле означала отход от создания моделей-подпрограмм в пользу моделей-классов, позволяющих генерировать множество объектов класса только за счет изменения параметров (например, вариация одного общего габарита детали автоматически приводит к согласованному пересчету всех размеров). А конструктивные особенности даже несколько обогнали программный аналог -- интерес к образцам дизайна (design patterns) в программировании только-только начинает расти. Собственно, PTC сделала последний, самый значимый шаг в "геометрической области" CAD, и большинство мощных современных систем попадают в класс параметрических, основанных на поддержке конструктивных особенностей (parametric feature-based). Но затишья на CAD-рынке после этого не наступило. Война между особенностями ядер геометрического моделирования (о ней мы немного говорили в давней статье аналогичной тематики, "Компьютерное Обозрение", # 12, 2001), фактически завершившаяся победой так называемых "гибридных" технологий представления твердых тел, позволяющих равноправно оперировать как твердотельными моделями, так и сложными поверхностями (об этой победе мы еще скажем пару слов), плавно перешла в войну сразу на двух фронтах. Первый обширный фронт -- интеграция CAD-систем в общую бизнес-структуру управления предприятием, и события тут развиваются просто стремительно. Второй фронт намного уже и более специфичен (т. е. более соответствует особенностям проектирования) -- здесь производители борются за нахождение красивого и эффективного решения, которое дало бы возможность использовать CAD-системы как источник самого ценного в производстве -- знаний или, если хотите, пресловутого know-how. Подготовка квалифицированного инженера-конструктора, по сути, длится всю его жизнь, и уровень квалификации достигает пика к тому времени, когда, увы, возраст отдаляет человека от пика работоспособности. Сохранить знания и опыт такого квалифицированного специалиста -- далеко не "игрушечная" задача. Соответственно и интерес к подсистемам, способным не только автоматически выделять параметризованные конструктивные особенности из реальных разработок, ведущихся компанией, но и поддерживающим повторное использование этих выкристаллизованных знаний, очень велик. Пояснить значимость подобных подсистем можно на примере следующего простого логического рассуждения. Колоссальные возможности геометрического моделирования современных CAD практически всех классов приводят к тому, что одну и ту же задачу удается решить множеством способов (и избавляться от этого "недостатка" никто не собирается -- ограничивать функциональность здесь просто нельзя). Опытный конструктор на основе своих знаний выберет из этого множества если не экстремально-оптимальный, то, даже в крайнем случае, и не наихудший способ. Молодой -- вынужден будет повторять все прежние ошибки своего маститого коллеги. А автоматическое выделение конструктивных особенностей позволяет "вырвать" из контекста реального проекта специфику решения задачи и повторно ее использовать. Точно так в программировании design patterns облегчают быстрое нахождение пусть не лучшего из лучших, но вполне приемлемого решения.
Проблема # 1
Беглый обзор PLM-идеологии был бы крайне неполным без упоминания о проблеме, постепенно становящейся самой главной. Все красивые слова "коллективная разработка", "управление требованиями", "управление поставками" ничего не значат, пока отсутствует формализация самого главного -- единого представления данных. А вот с этим-то как раз дело обстоит не просто плохо, а фактически -- ужасно. Ближайший, если не по смыслу, то по области применения, существующий стандарт обмена CAD-данными STEP (STandard for the Exchange of Product model data, ISO 10303) ориентирован, в большей степени, на описание геометрических характеристик моделей проектных объектов. На сегодняшний день реализации STEP доведены до степени пригодности к промышленному использованию самыми разными производителями CAD-систем (это была далеко не простая задача), и теперь только воцарившийся "мир" в области стандартов рискует стать временным "перемирием". В силу своей специфики STEP не удовлетворяет потребностям систем, основанных на PLM-идеологии, а производители ПО (равно как и пользователи) не в восторге от вынужденного поддержания разных стандартов описания данных в пределах одной системы. По мнению ряда аналитиков, только-только доведенному до ума STEP грозит вытеснение основанным на XML специфическим языком описания геометрии -- это позволит унифицировать CAD-данные в рамках системы, реализующей PLM-идеологию.
Интеграция: от CAD -- к PLM, от PLM -- к GCE
Достигшие к середине 80-х годов поры первой зрелости CAD-системы впервые породили интегративную проблему. Возникла потребность в упорядочении образующегося хаоса из разношерстных проектных и сопутствующих документов. И тогдашние лидеры IT-индустрии не заставили себя ждать -- Control Data Corporation (CDC) выпустила на рынок первую коммерческую систему управления CAD-документами EDL (Electronic Data Library). Впоследствии (и очень быстро) из-за интеграции CAD-решений различной целевой направленности в рамках одного проектного процесса (например, CAD класса EDA, Electronic Design Automation с классическими "машиностроительными" CAD в проектах промышленной электроники, станкостроения и т. д.) проблема "документохаоса" стала исключительно острой. Настолько, что появилась новая аббревиатура для класса масштабных продуктов, направленных на ее решение. PDM-системы (Product Data Management) управления проектными данными принесли заслуженную славу первопроходцам (Computervision, SDRC), но со временем перестали быть чем-то из ряда вон выходящим. Сегодня элементы PDM обязательно встраиваются в CAD-пакеты чуть ли не всех уровней. Но не только поэтому в заглавии этого раздела статьи аббревиатура PDM не упомянута. Данные системы изначально предназначались сугубо для проектных отделов компаний и за пределы конструкторского мира (инженерных подразделений) не выходили. В те времена этого было вполне достаточно -- шла настоящая битва за скорость вывода продукта на рынок, в которой узкая специализация позволяла добиться лучших результатов. Параллельно с PDM развивались и сопутствующие системы управления логистикой, поставками, взаимодействием с поставщиками и заказчиками -- каждая в своем направлении и в соответствии со своими локальными целями. От инженерных подразделений требовались перечни материалов (BOM, Bill Of Materials), и неудивительно, что эффективная поддержка автоматизации их создания -- также задача уже решенная. Но время шло, и, наконец, возникла ситуация, о которой сегодня говорят как о свершившемся факте, -- борьба за скорость выхода на рынок фактически завершена, производители по данному критерию практически уравняли свои шансы (и это вовсе не отсебятина зарвавшегося автора). Теперь начинаются серьезные войны -- за инновации (любые, даже малейшие) и за "глобальное качество" (под которым понимается не только качество изделия--товара, но и обслуживания, взаимодействия с заказчиком и т. д.). О первой мы немного поговорим отдельно (как ни странно, но и для генерирования инноваций существует свой собственный, исключительно узкий класс CAD-систем), а вот на обеспечение "глобального качества" направлено решение интеграционной задачи, удостоившееся очередной аббревиатуры PLM (Product Lifecycle Management).
В составе PLM-систем принято выделять пять основных составляющих, обеспечивающих решение следующих задач:
коллективная разработка (Collaborative Product Design, CPD);
управление данными проекта (Product Data Management, PDM);
прямое управление поставками материалов (Direct Materials Sourcing, DMS);
управление требованиями заказчиков (Customer Needs Management, CNM);
управление спектром продукции (Product Portfolio Management, PPM).
Естественно, в зависимости от профиля компании ей нужны не все элементы PLM. Так, фирмы, специализирующиеся в инструментальной поддержке производства и работающие сугубо под заказ, могут исключить из масштабной подсистемы CNM целый ряд модулей, направленных на удовлетворение потребностей другой формы производства -- выпуска продукции инициативной разработки "на склад". Но, что самое главное, обилие аббревиатур и программных систем, обеспечивающих в той или иной мере реализацию стоящих за этими аббревиатурами понятий, не должно вводить в заблуждение. PLM -- это не набор программ (именно так). PLM -- это бизнес-стратегия (или даже бизнес-идеология), на 90% состоящая из организационных процедур, и именно эффективность, продуманность и строгое соблюдение данных процедур обеспечивает работоспособность всей идеологии. А что же касается ПО, то ничем особо выдающимся оно на самом деле не блещет и, вполне очевидно, в реализации -- обычно все подсистемы строятся в рамках XML и intranet-технологий.
