Перечень недостатков существующей системы

В отделе администратора баз данных существует старая бумажная технология обработки информации. Бумажная технология характеризуется тем, что конструкторами-технологами вручную заполняются основные конструкторские документы:

- конструкторско-технологические спецификации

- справочники

- классификаторы

- бюллетени

- разовые заказы

- служебные записки

Вручную заполненная информация в этих документах перфорируется и вносится в общую базу данных, которая реализована на большой машине. В процессе поступления изменений различных документов информация корректируется и поддерживается в рабочем состоянии. Информацией с большой машины обеспечивает все подразделения предприятия для решения задач АСУП(Автоматизированной Системы Управления Предприятием).

Перечень недостатков существующей системы:

- дважды переписывается информация конструктором и оператором

- растягивается цикл обработки

- нет оперативности

- много посредников, что увеличивает трудозатраты на обработку КТД.

- система имеет устаревшую технологию обработки информации и работает в пакетном режиме и режиме телеобработки. Конечные пользователи имеют возможность работать только в режиме просмотра информации.

Существующие недостатки требуют создать Информационную систему нового поколения основанную на методологии CALS-технологий.

 

Анализ аналогичных разработок

Сейчас в технических СМИ появилось много статей о модуле PDM (поддержки данных жизненного цикла изделия). Последние часто носят заказной рекламный характер, не позволяющий разобраться во всех нюансах, особенно для неспециалистов по этой тематике. Обычно акцентируется внимание на определенных функциях и замалчиваются другие аспекты: полнота функциональности, взаимодействие и интеграция PDM в единую информационную среду предприятия. Проблема остро стоит для многих отраслей: авиа, автостроения, машиностроения.

 

 

Чтобы разобраться в этом вопросе рассмотрим ряд наиболее лучших зарубежных и отечественных систем: Windchill (PTC, США), Teamcenter (EDS, США), Search (Интермех, РБ) и сравним их с разработкой МЗКТ СпрутМ.

 

Функциональность

PDM Windchill (4 тыс. $/рабочее место) по своей функциональности в основном нацелен на организационную координацию деятельности различных служб, участвующих в разработке и производстве изделия: субподрядчиков по разработке, заказчиков, субподрядчиков по производству, поставщиков комплектующих, а также внутренних подразделений, таких как инженерная служба, маркетинг, продажи, обслуживание, производство, служба снабжения. Информационной поддержки проектирования, технологической подготовки производства у него нет. Заносимая информации с точки зрения конструкторов и последующей АСУ недостаточна: минимальная информация по ДСЕ (деталь-сборочная единица) и составу в приделах 2-х десятков полей. Во многом это типичная система электронного документооборота. Из-за этих недостатков он слабо подходит на роль первичного звена CALS. Стоимость модуля сопряжения Windchill с BAAN порядка 250 тыс. $.

 

БелАЗ промучавшись 7 лет с его внедрением, отказался от закупленных Windchill, BAAN, предпочтя ему Search и старую заводскую систему на Сlipper при их разрозненном использовании. Камнем преткновения явилась проблема синхронизации данных в разных системах построенных по разной бизнес-логике, слишком большой объем вносимой и меняемой информации из-за наличия разных систем, проблема с высококвалифицированными кадрами и разочарование в функционале Windchill и BAAN. Выбор Search был обусловлен, в первую очередь, более низкой ценой и потребностью технологов в модуле Техкард для формирования технологических карт и отсутствием на рынке полноценной PDM. Последний без Search работать не может.

 

Search является типичной системой электронного документооборота с большей ориентацией и поддержкой Автокада (в других модулях). В версии 9 добавлена поддержка UG, ProE, ведение заказных спецификаций и замен, значительно изменен его интерфейс. Предусмотрено варьирование составом, как на уровне головной сборки, так и внутреннем. Данный пакет лучше вышеперечисленных зарубежных настроен на отечественную систему бумажной конструкторско-технологической документации и документооборот. Обеспечивает формирования и распечатку бумажных документов спецификаций на основе информации баз данных, ведение электронного архива чертежей, согласование. Однако заносимая информация Search все же минимальна: только то, что содержится в штампе чертежа, спецификации и извещении и связанная с заменами и вариациями сборок. Организация электронного архива не в полной мере отвечает современным потребностям производства: файлы сбрасываются в папки, они не кодируются в БД, потом сложно с ними разбираться (различать). ERP-функций у него практически нет. Например, отсутствует функция применяемости. И все это из-за ссылочного механизма ведения состава, не позволяющего вести сортировки. Построить полноценную систему CALS при использовании Search в качестве первичного звена сложно, возникает много проблем по интеграции. Сфера применения Search - проектные организации в основном конструкторско-технологического профиля, которым нет необходимости в CALS. Следует отметить, что Search от версии к версии заметно прогрессирует и по своим возможностям во многом уже превзошел TeamCenter. Подводит его наличие ошибок в программном обеспечении.

 

TeamCenter (TCE) позиционируется как PDM система, призванная обеспечить информацией последующие модули EDS, охватывающие подготовку производства и АСУ. Но в СНГ эти модули практически не используются и дать им оценку не представляется возможным. Его PDM также слабо годится на роль первичного звена.

 

 

Преимущества и недостатки

Каждый пакет имеет свои преимущества и недостатки. Функциональность TeamCenter и Windchill в стандартном варианте явно недостаточна. Для применения под отечественную систему документации необходима доработка. Процесс настройки связей для описания объектов в TCE довольно сложен и по опыту ряда организаций (МАЗ, ОКБ Сухого) требуется порядка 3-5 лет. А на занесение полной информации на заводах может уйти до 8-10 лет. Необходимо написание своих программ на Java. Многие организации не в состоянии эти пакеты самостоятельно даже развернуть, не говоря об их модификации. TeamCenter (доработанный отечественными фирмами) несколько лучше чем Windchill адаптирован под производственную сферу в привычном АСУшном понимании. У Windchill уклон сделан на взаимодействие участников и согласование. Windchill слабее с точки зрения обеспечения привычной информацией конструкторов, технологов и АСУ. Работы по созданию надстройки к Windchill из-за слабого его применения в СНГ не ведутся и непонятны причины, по которому его собираются сделать основным в объединенной авиастроительной корпорации России. Единственным объяснением может быть необходимость в обмене данными при кооперации с западными разработчиками.

 

У доработанного TeamCenter содержится несколько больше информации по штампу чертежа и спецификации, к которой привыкли конструктора. PTC (Windchill), похоже, исходит из того, что данная информация должна содержатся в файле самой модели в виде атрибутов. В его БД многие параметры отсутствуют. С точки зрения обеспечения информацией других последующих систем (ERP) он слабее, чем Search, TCE.

 

Механизм ведения заказных спецификаций реализован в TeamCenter за счет дополнительной программной настройки, сделанной в СНГ. В стандартном варианте его нет. У Windchill ведение заказных спецификаций, ERP функций не реализовано. Хотя в принципе возможна его некоторая доработка. Но она требует высококвалифицированных кадров по Java, больших затрат и экономически нецелесообразна из-за присущих ему недостатков.

 

У Интермеха имеется неплохой отдельный модуль TechCard по формированию технологической документации, который работает в паре с Search. Но получить в Search информацию по расцеховке маршрутов без TechCard невозможно.

 

В отличие от Windchill к TCE можно подключить дополнительно приобретаемые модули: TeamCenter Manufacturing, TeamCenter Project и другие, где заявлена возможность создания техпроцессов, привязки детали к указанному техпроцессу, возможность указания рабочих областей, реализации расцеховки, нормирования материалов, формирования графиков технологического оснащения (формирование, контроль графиков). Но опять, это ПО требует доработки под отечественную систему документации. Информационная поддержка процесса проектирования, особенно конструкторской части у него все же недостаточна. Что касается документов, то они формируются в формате XML. На экране смотрятся нормально, но малопригодны при распечатке. Получить технологические карты невозможно. Требуется модификация БД и разработка дополнительных программ на Java для вывода на печать. А это не каждой организации под силу. Прикрепляемые к карточке документа ДСЕ файлы, как у Windchill и Search неупорядочены, неотсортированы, плохо читаемые и воспринимаемые в дереве. При интеграции с другими системами АСУ у TeamCenter, как и у других пакетов, возникает много проблем. Если в организации не ведется электронный архив (а это наблюдается на многих предприятиях), то перечисленные пакеты вообще не нужны: это лишнее звено.

Заявления фирм-дилеров о возможности серьезной доработки пакетов под ваши задачи во многом пустые обещания. Это связано с самими пакетами (системами их защиты) и их возможностями. В лучшем случае вам сделают интерфейс стыковки, требующий после него ручного редактирования. Подтверждением этому является опыт МАЗа, где за 8 лет смогли добавить в TeamCenter всего лишь одно символьное поле для маршрутов, передаваемое из Omega Soft и реализовать несколько внешних функций по контролю передачи данных в другую систему. Или мучаться с конвертацией данных, прибегая к использованию 2-3х смен (Уралмаш, Search), требующих больших затрат времени при использовании примененного интерфейса.

 

Если бы удалось объединить положительные стороны этих пакетов, включая СпрутМ, получилась бы идеальная система. А пока с точки зрения конструкторско-технологических служб и АСУ в рассматриваемых первых трех пакетах много недостает, их структура должна быть иная и поддерживаться больше за счет реляционных баз. Нет цепочки ДСЕ – изменение – извещение – их содержание (графика). Согласно ЕСКД извещение может выпускаться только на конкретное изделие или на группу. На конкретную ДСЕ оно не выпускается. Фактически, не к чему в рассматриваемых PDM прикрепить файлы документов по изменениям и извещениям. В классическом варианте база данных ДСЕ должна быть реляционно связана с БД изменений, в которой должны быть указано извещение. А само извещение должно представлять группу таблиц, содержащих помимо текстовой информации ссылки на графику. Должно обеспечиваться формирование бумажных документов по извещению и предписанию. Все это отсутствует.

 

Каждый рассматриваемый пакет ориентирован на свои модули, за которые надо отдельно платить. Полноты охвата функционала нет ни у одного импортного пакета. У многих пакетов нет функций формирования требующихся нам документов из-за отсутствия информации. Как уже указывалось у Windchill и Search нет своего модуля ERP. Поэтому многие используют ERP, другого разработчика или собственные разработки. Но чтобы все это нормально работало, необходимо, чтобы последующие модули придерживалось той же бизнес-логики и имели аналогичную структуру данных. А этого нет.

 

Имеются вопросы, как визуализировать на PDM сложные объекты, например весь автомобиль (2 тыс. сборок). По логике для этого надо выполнить разузлование проекта с подсуммированием с последующим копированием файлов в один каталог либо создать конфигурационный файл. Но об этом ничего не говорится в их документации и неясно делается ли это в пакетах вообще. Ответов на многие вопросы фирмы-продавцы дать не могут, предлагают вначале купить Windchill или TCE, а там мол, будем разбираться, он должен все решать.

 

Обычно на практике никто не работает в 3-D с такими сложными изделиями целиком, в основном по узлам. Если создается компоновка, то, как правило, делается на упрощенных моделях-составляющих – в противном случае не вытянут компьютеры. В этом случае возникают вопросы, а из чего строить дерево сборки: с действительных моделей или упрощенных и как их потом различать в PDM при отсутствии кодирования. Ответов пока нет.

 

Комплексная оценка пакетов

Для указанных PDM характерно занесение информации по обозначению в одно поле и использование ссылочного механизма при ведении базы данных состава (запись номера ДСЕ вместо обозначения). Все это приводит к невозможности выполнения сортировок по частям обозначения как по ДСЕ так составу. Это принципиальные недостатки перечисленных систем, которые накладывают много ограничений на дальнейшее использование их информации в других систем. Ведь без сортировок нельзя обойтись, особенно когда номенклатура изделий предприятий составляет сотни тысяч. Теряется информативность, можно легко пропустить при просмотре требующуюся информацию. Все это вынуждает внедрять дополнительные системы, включая собственные. А это ведет к необходимости дублировать ввод информации, объемы которой сейчас резко возрастают. Необходимо подключение технологов на ранней стадии еще до утверждения КД и обеспечения их необходимой информацией. Фактически сейчас имеется большая потребность, чтобы PDM помимо своих стандартных функций выполнял часть функций ERP систем. Именно в этом направлении ведется совершенствование СпрутМ.

 

Использование PDM Windchill, TeamCenter некоторыми российскими азрокосмическими КБ обусловлено спецификой их деятельности. У них КБ отделены от производства и применяется Unix на 64-х битных рабочих станциях для возможности работы с очень большими сборками. Задача этих КБ выпустить документацию, включая электронную. Вопросы интеграции с другими производственными системами считались не их сферой. Мол это проблемы заводов, которые выпускают их изделие. А производство больше ориентировано на ERP, а не PDM. Хотя сейчас начинают понимать в потребности в PDM и на производстве, чтобы разобраться с комплектацией. Вторая причина, что других пакетов под ОС Unix нет и надо как-то автоматизировать и координировать 3-хмерное проектирование и вести электронный архив. И поэтому приходится мириться с недостатками этих PDM.

 

Как показывает анализ зарубежные PDM при интеграции в наши системы вносят рассогласованность в построение единой информационной среды из-за некоторых своих подходов и требуют применения дополнительных средств. Путь создания собственной CALS/PLM со своим более простым, но функциональным модулем PDM более предпочтителен.

 

Почему-то не получается с данным программным обеспечением у ведущих зарубежных IT-корпораций: то ли они не представляют всей картины реального производства и объектов автоматизации и не могут создать единый комплекс программ, требующийся производству. Вроде бы многие отдельные вопросы у них неплохо решены, а единого продукта требующегося предприятиям не могут предложить.

 

Одновременно необходимо учитывать, что многие зарубежные пакеты также плохо подходят и по блоку экономических и финансовых задач из-за другого законодательства, форм документов. То же можно сказать о технологическом блоке в части форм документов. Поэтому имеются большие сомнения в эффективности использовании зарубежных пакетов АСУ. Потребуется много доработок и подключения своих систем. Исключение составляет моделирование техпроцессов, неплохо решенное в технологических модулях PTC и EDS. Но это автономные модули больше ориентированные на графические пакеты. Они могут работать и без PDM-ERP указанных фирм. Чтобы получить отдачу от CALS надо сочетать и импортные пакеты (их отдельные модули) и свои, например: импортные графические пакеты и развивать свои CALS-системы, перенимая положительные моменты. Гораздо хуже слепое преклонение перед оторванными от реального производства заморскими продуктами, проведение технической политики, заводящей в тупик собственные разработки и обрекающей нас на технический застой.

 

 

Важно понять, что если выбираем PDM Windchill, TeamCenter, SAP или им подобную то всю последующую ИИСП надо строить либо на основе их модулей или по их идеологии: применять обозначение в одно поле, использовать ссылочный механизм ведения состава, осуществлять изменение путем формирования новой спецификации и изменение статуса старой. А это повлечет за собой много указанных выше проблем и снизит функциональность и эффективность всей системы. Многих требующихся нам функций у них нет. Все дальнейшее построение интегрированной информационной системы предприятия при таком подходе пойдет не так, как хотелось. Из других систем нельзя будет изменять данные реализуемые PDM. Внедрение таких “PDM” потребует кардинальной перестройки всей системы предприятия, его ломку, создания конверторов, применения дополнительных пакетов, реализующих недостающие функции, полного переоснащения техникой

Приобретать такие PDM (СЭД) ради осуществления только красивого механизма электронного согласования и визуализации вряд ли целесообразно. С точки зрения наших предприятий это не является столь первоочередным и особо важным. Редко кто из предприятий, применяющих PDM, использует эту функцию, т.к. согласование это своеобразный торг конструктора и технолога и требует личного контакта. Визуализацию можно решать по-другому. Например, используя COM–Java технологии запускать из пакета сторонние 3-D редакторы и загружать файлы, как это сделано в СпрутМ. Или формировать в нем html страницы и запускать из него интернет-браузер для просмотра упрощенных 3D моделей. Единственное, что надо сделать: осуществить заранее вручную преобразование полной модели в упрощенную через 3-D редактор. У Windchill это делается динамически на сервере без участия человека, но требует мощных серверов. У СпрутМ применяется более простой механизм текстового электронного согласования и электронной подписи с идентификацией файлов, введен механизм замечаний с прикрепляемыми файлами графики, есть ведение заказных спецификаций и многих ERP задач.

 

Заводская система должна быть одна и исключать дублирование ввода информации и не гонять данные туда-сюда. А пока получается, что PDM сам по себе со слабой функциональностью, вне связи с другими заводскими системами. В случае их директивного внедрения требуется длительный период параллельного ведения различных систем. На это не часто хватает средств и сил. Пока вместо реальной отдачи получается игра в современные технологии в потемкинских деревнях.

 

Кроме того, западные продукты более ориентированы на верхний уровень управления, а не на средний и нижний, что сейчас больше необходимо нашим предприятиям. Стоимость одного рабочего места такого PDM не маленькая 4-6 тыс. $ /рабочее место (Windchill), 39 тыс.? для UG c TeamCenter, Search (3 тыс.$), а их требуется на предприятии несколько сотен, не учитывая других систем. Слишком дорогая цена за функцию согласование. Реально у большинства предприятий сейчас таких средств нет, тем более на кардинальное обновление всей системы предприятия. ИИСП - это комплексная система, где все должно работать во взаимодействии. И если какой-то модуль не вписывается в общее информационную среду, то лучше им пожертвовать.

 

Вывод:

На авиастаре приходится разрабатывать собственную PDM – систему так как если использовать имеющиеся сейчас PDM скатимся на организационно-распорядительные функции и не построим интегрированную информационную систему предприятия - полноценную CALS/PLM систему. Вложим большие средства и не получим в итоге отдачи. И такие отрицательные результаты в РБ и СНГ уже есть, а главное потеряем веру в собственные возможности.

 

Но PDM в первоначальном их определении все же необходимы, ибо от них должна строиться вся информационная система предприятия. Они должны быть созданы с несколько иной функциональностью, чем существующие. Необходима единая информационная система, которая бы охватывала все: информационное обеспечение процесса проектирования и технологической подготовки, управление производством, взаимодействие со всеми участниками, поддержку жизненного цикла изделия, причем на новом качественном уровне с графикой. Требуется объединение усилий в этом вопросе.