В статье «Что входит в задачи PLM?» (Computerworld Россия, №39/2003) было отмечено, что «сильной стороной компании PTC является PDM (система Windchill), которая хорошо работает в сфере параллельной, но не индивидуальной разработки». В данный момент нас очень интересуют сильные и слабые стороны различных PDM-систем масштаба предприятия — в статье были введены критерии их сравнения: наличие поддержки в сфере параллельной разработки, наличие поддержки в сфере индивидуальной разработки. Первый критерий хорошо описан в литературе и в двух словах означает решение проблем надежной, быстрой и непротиворечивой централизации хранения данных об изделии; предоставление одновременного доступа к ним с реализацией правил бизнес-логики и разграничения доступа, а также решение проблем offline-взаимодействия между удаленными филиалами. Сложнее со вторым критерием. Какие, например, проблемы возникают при использовании Windchill для индивидуальной разработки и почему их нет при параллельной? Есть ли такие же проблемы у других систем: TeamCenter, SmarTeam или отечественных PDM?

Дмитрий Фиго (dmf@otd12.vniief.ru), сотрудник Института экспериментальной физики (ВНИИЭФ, г.Саров)

В принципе, точный смысл терминов «параллельная разработка» и «индивидуальная разработка» сегодня объяснить достаточно сложно. Мне по роду деятельности приходилось неоднократно сталкиваться с решениями по сопровождению проектных данных от Dassault Systemes, UGS, SDRC и от PTC — различие между «индивидуальной» и «параллельной» разработкой состоит в различных методах объединения данных. Как вы правильно отмечаете, «индивидуальное» объединение данных — это централизация хранения данных об изделии, при которой все участники процесса «отдают» свои данные в «центральный» банк, выполняя при этом еще и трансляцию форматов, полей, атрибутов и т.д. Несомненные плюсы такого подхода: высокая скорость работы поискового механизма (одна база данных и построенное по единым законам пространство данных) и простота администрирования. А минусы до недавнего времени были настолько незаметны, что их никто в расчет и не принимал: обязательность дорогостоящего процесса интеграции чужих баз данных, подсистем работы с данными и структур данных. Сегодня необходимость такой интеграции встречается сплошь и рядом, особенно в условиях всевозможных коопераций.

Действительно, представьте себе, что вы хотите завязать в единый бизнес-процесс работы с проектными данными свою PDM-систему, базы данных поставщиков, соисполнителей и дилеров — весьма тяжело будет потребовать от них в качестве обязательного условия «перейти» на стандарты представления информации именно вашей PDM. Всем, кроме вас, от легкости администрирования вашей системы «достается» тяжесть дополнительного администрирования своей, да и от простоты общения с централизованной базой консолидированных данных им также остаются «рожки-да-ножки» — как правило, они не напрямую подсоединены к вашему Центру данных. В современной промышленности уже давно доля соисполнителей-поставщиков-субподрядчиков зашкаливает за 60-70%, а ведь за этими процентами на самом деле скрывается реальная информация о составных частях изделия, позиции в спецификациях, описания техпроцессов и т.д. — все то, что как раз и образует содержимое «централизованного хранилища данных об изделии». Как «заставить» сторонние организации «плясать под дудку» вашего системного администратора? А если у поставщика таких бизнес-партнеров как вы много и каждый со своей «дудкой»?

Сама по себе идея строгой централизации данных к сегодняшнему дню в рамках существующих технических подходов уже начала себя изживать. Единственный видимый невооруженным глазом выход — не централизовывать, а объединять данные. Допустить множественность частных центров обработки информации со своими механизмами, форматами и приложениями. А объединять не данные, а процессы работы с ними. Естественно, что, например, никакого «быстрого» поиска по такой федеративной базе не получится — искать придется по частям, «сшивая» результат. Зато при этом кооперация вычислительных систем предприятий должна выполняться менее болезненно и более эффективно, чем при строгой централизации.

«Параллельное» объединение данных — это как раз и есть подход, предполагающий федеративность данных, их консолидацию без единого хранилища, с открытой структурой как самих данных, так и метаданных, а, возможно, и процессов.

Аналогичная ситуация наблюдалась и в Internet — пока не было стандартных стеков приложений, пока не появились практические успехи в разработке интероперабельных языков сетевых запросов, пока основные игроки на рынка не озаботились выпуском сред исполнения сетевых серверов, пока не появились сетевые реляционные СУБД — ни о каком «параллелизме» помышлять и не приходилось. В области «параллельной разработки» основная проблема — найти такой консолидирующий механизм.

Строго говоря, никаких проблем не появляется при попытке использования Windchill как средства «индивидуальной» разработки (при наличии централизованной модели данных), однако, при прочих равных условиях такая реализация может по эффективности «проиграть» централизованной системе. Windchill «не знает», что все его данные, структуры и механизмы выборки реализованы в одной базе данных, на единственном сервере и работают с одной САПР — механизмы федерализации он, Windchill, все равно стартует и на их работу какие-то ресурсы все равно тратятся. При параллельной работе одновременно со сборками на нескольких САПР (возможно, с индивидуальными подсборками в каждой из них в рамках единого проекта), при организации выборки на виртуальной базе, «размазанной» по Сети, как раз и понадобятся Web-сервисы, репликаторы запросов, встроенные унификаторы форматов и т.д. И ничем их не заменить. Если использовать средство параллельной разработки вместо «централизованного», то все будет работать, но неэффективно. Если использовать средства «индивидуальной разработки» для федерализации, то система на базе Windchill работать уже не будет.

Перечислим возможности «федерализации», присутствующие на сегодняшний день в Windchill и отсутствующие пока у других систем:

  • встроенный механизм интеграции внешних баз данных (интеграции моделей данных, форматов данных, структур хранения);
  • встроенный механизм интеграции запросов (наличие этой возможности проверить просто — достаточно оценить степень легкости, с которой администратор или пользователь может объединить в одном запросе, выполняемом со своего рабочего места, опрос любого количества внешних сторонних баз данных);
  • наличие ролевого управления и единой точки идентификации пользователя (проверить это также очень просто — администратор системы не должен ничего перенастраивать для обеспечения работы);
  • минимализация или отсутствие предустановленного «клиентского» ПО (идеал промышленного использования — «тонкий клиент» на рабочем месте: только Java и браузер).

Как только по этим показателям альтернативные систему догонят Windchill можно будет говорить о еще одном реальном представителе «параллельного» подхода. Для IBM (Dassault Systemes) — это ENOVIA в составе триады CATIA-DELMIA-ENOVIA, способная стать полноценным PLM-решением от IBM для задач интеграции процессов разработки, в условиях современной производственной кооперации. А для небольших предприятий, самостоятельно работающих и полностью контролирующих процесс разработки имеется централизованное решение — SmarTeam с прямой интеграцией на одну САПР (CATIA V5R11).

Про отечественные PDM можно сказать много хорошего. Но не в качестве систем для крупного предприятия и среды «параллельной» проектной консолидации. И тому есть одна простая причина — разработка хорошей промышленной PDM-системы стоит около 60-100 млн долл., а ее «доводка» в течение пяти-десяти лет требует еще столько же. Много ли отечественных компаний обладает такими ресурсами?

— Владимир Краюшкин (vkr@royint.com), сотрудник компании Roy International Consultancy (Москва)