Многие предприятия начинают автоматизацию традиционно - с модулей бухгалтерии, финансов или HR. Но в машиностроительной отрасли этот подход, по мнению Виктора Кучерявых, начальника управления информационных сис-тем ОАО "Машиностроительный завод "Арсенал"", неприменим. Наш собесед-ник убежден, что первым шагом к ERP-системе должна быть PDM-система. Именно по этому пути и пошло его предприятие.


Intelligent Enterprise: Расскажите об истории автоматизации завода "Арсенал".

Виктор Кучерявых: На "Арсенале" был свой ВЦ и отдел АСУП. В на-чале 90-х завод разделился на несколько предприятий. При акционировании производства образовалось ОАО "Машиностроительный завод "Арсенал"", а ВЦ и отдел АСУП остались во ФГУП КБ "Арсенал". Я помню собрание отдела, на котором принималось решение, где быть вычислительному центру - в КБ или на заводе. Решили оставить в КБ. Завод пользовался услугами ВЦ, но зада-чи бухгалтерского учета и расчета заработной платы постепенно перешли с ЕС, использовавшихся в ВЦ, на аппаратные и программные средства нескольких заводов. Затем в 1996 году все заводы объединились в холдинг. Началось тех-ническое перевооружение в области ИТ - срок жизни ЕС ЭВМ закончился. Пришла пора ПП ЭВМ и графических станций для рабочих мест конструкторов. В это время я стал ответственным за применение ИТ на машиностроительном заводе "Арсенал".

Нам не раз задавали вопрос, как такое большое предприятие может рабо-тать без ERP-системы. Мы отвечали, что согласны на внедрение, но начинать его будем не с бухгалтерии, финансов или HR-модуля, а с описания наших из-делий. Ведь "Арсенал" -- это проектирование и производство на заказ сложной наукоемкой машиностроительной продукции, мы проектируем сами изделия и технологию их изготовления или технологию изготовления изделий сторонних КБ, например КБ "Арсенал". Автоматизировать управление таким предприяти-ем, не ответив с помощью информационной системы на вопрос, что мы произ-водим, нельзя. Без специализированной системы для конструкторской и техно-логической документации применить ИТ в управлении производственными процессами не получится. Поэтому мы начали с создания конструкторской и технологической документации наших изделий в среде САПР. Затем подошли к PDM-системе, ведь это инструмент, который позволяет объединить конструкто-ра изделия, конструктора оснастки, технолога и сотрудников производственных подразделений, работающих со спецификациями заказов. Для нас очевидно, что без PDM-технологий никакие ERP-решения на "Арсенале" работать не смогут.

Как выбиралась PDM-система?

Поставщики, предлагавшие нам ERP-решения, имели и свои PDM-системы. В частности, такие системы есть у SAP и Baan. Однако ни отраслевые решения, ни PDM на тот момент не были локализованы для России. Кроме того, предприятия машиностроения в нашей стране находятся совершенно не в том состоянии, в каком аналогичные западные заводы. Когда западный поставщик предлагает клиенту "красивый костюм", то возникает вопрос, как этот костюм на него натянуть, ведь есть атлет, подтянутый, тренированный, и есть россий-ский клиент - с лишним весом, одышкой... Отмечу, что успешных проектов по реализации ERP-систем в нашей отрасли единицы, да и то лишь после мучи-тельнейших усилий ИТ-команды предприятия, которая дорабатывает часть функционала системы.

Рассматривали мы и отечественные решения -- в то время они называ-лись не PDM, в моде был термин CALS. Самым привлекательным показалось решение компании "Интермех". Мы были готовы приобрести у них всю линей-ку продуктов, предназначенных для реализации управления данными об изде-лиях, но с одним условием. Для нас очень важно управление конфигурациями (номерами) изделий. Что это значит? Есть три изделия, одно из которых нахо-дится на испытаниях, второе -- в цехе, третье закладывается в производство. В целом у них одна конструкторская документация, но некоторые части разные, потому что эти изделия предназначены для установки, например, на разные ко-рабли. Проводится это как изменения в конструкторской документации на но-мер изделия. В "Интермехе" на тот момент нам сказали, что реализовать пол-номерный учет изделий в их продуктах можно только организационными мера-ми.

Познакомились мы и с PDM-системой SmarTeam одноименной компании (сейчас это дочерняя фирма Dassault Systemes, а ее продукт наряду с CATIA - один из основных компонентов PLM-линейки IBM. - Прим. ред.). Система нам понравилась, и мы решили рискнуть - стать одним из первых ее пользователей при условии настройки и локализации под требования ЕСКД для нашего типа производства. Решение поставила компания "Би Питрон". Мы предложили этой компании провести совместную работу по настройкам и локализации, но не до-говорились и решили делать это сами.

Расскажите об опыте настройки PDM-системы…

Специалистам "Арсенала" удалось создать свою модель данных (в 2005 году эта разработка была запатентована) используя специальный инструмент Smart Wizard. Построена система идентификаторов изделий в соответствии с отраслевыми стандартами и стандартами самого завода, их моделей, подробно-го описания материалов - марок, сортаментов, профилей. Создан механизм ра-боты с нормалями и библиотека нормалей. Помимо настроек системы конструк-торской документации ЕСКД частично реализованы настройки ЕСТД - в мар-шрутном техпроцессе зафиксированы виды обработки изделия, виды оборудо-вания, на котором осуществляется эта обработка и и отвечающее за нее админи-стративное подразделение. То есть возникло понятие "рабочего центра". Появ-ление в PDM-системе не только параметров конструкторской документации по изделиям, но и маршрутных техпроцессов в привязке к рабочим центрам позво-ляет построить статическую модель изделия. С появлением нормативов времени по каждому рабочему центру она превращается в кинематическую. Это дает возможность создать список изделий, которые проходят через те или иные ра-бочие центры, и определить такой параметр, как трудоемкость.

Очень важным параметром для производственного процесса "Арсенала" является опережение. У завода есть задача -- сдать сборку изделия в определен-ное время. Изготовление изделия состоит из технологического цикла сборки и испытаний, а к началу сборочного цикла необходимо иметь комплектацию. Ес-ли цикл сборки составляет восемь недель, значит, за восемь недель необходимо представить ее состав и определить сроки запуска в производство всех деталей сборки. Составлять такой график на всю номенклатуру нецелесообразно. На "Арсенале" определяется командная деталь (номенклатура), требующая самого большого периода изготовления, или, в терминах план-графиков, деталь, нахо-дящаяся на критическом пути. Для построения графиков Ганта SmarTeam ин-тегрирован с Microsoft Project. Такая работа выполняется на уровне каждого от-дельного проекта. В SmarTeam управление проектами инженерной подготовки производства происходит с помощью механизма workflow в интеграции с Mi-crosoft Project.

Как персонал отнесся к внедрению PDM-системы?

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

Луддиты, противники автоматизации, становятся естественным явлением в таких условиях. Тот, кто может измениться, приобщиться к новым технологи-ям, -- тот ее сторонник. А кто лучше всех умел делать "руками", опытный со-трудник, но при этом понимающий, что не сможет приспособиться к новым технологиям, - самый активный противник внедрения информационной систе-мы. Таких людей надо пытаться сделать хотя бы консультантами.

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

Если человек действительно является специалистом, он может оценить свои возможности и понять, сумеет он работать с ИТ или нет. Но даже если нет -- он может взять учеников и помочь процессу внедрения информационной сис-темы. Нам отчасти это удается, хотя весь процесс зависит как от того, насколько хотят отдавать знания опытные сотрудники, так и от того, насколько хотят изу-чать их опыт новички. А этот опыт очень важен - ведь автоматизация не делает ничего такого, что не делалось бы ранее вручную. Все задачи "Арсенала" в об-ласти информационного сопровождения процесса производства в теории были прописаны еще 20 лет назад, а сейчас мы просто их реализовали средствами ИТ.

Как осуществляется информационная связь с другими поставщика-ми? Используются ли при этом возможности PDM-системы?

Пока все происходит на бумажных носителях, однако мы хотим перейти хотя бы к передаче растра и спецификаций и сейчас выстраиваем такое взаимо-действие с предприятиями нашего сектора. Отдавать CAD-модели "на сторону" для нас слишком большой риск, ведь мы занимаемся спецтехникой. Что касает-ся предприятий, для которых мы выполняем работы по их чертежам, то с ними мы пытаемся реализовать такую схему: они установят удобные для нас CAD-продукты и будут давать нам конструкторскую документацию на свои заказы из этих систем. ФГУП КБ "Арсенал", как близкой структуре, мы предлагаем вос-пользоваться нашей разработкой.

В случае, когда мы отдаем нашу документацию предприятиям-партнерам для работы по кооперации, мы готовы отдавать всю сопроводительную инфор-мацию и документы из PDM-системы. В составе инструментов выбранного на-ми решения есть возможность организовать совместную работу в двух вариан-тах. Но как она будет организована -- зависит от того, какая у нас система обо-значений. Значение атрибутов должно пониматься всеми. Если это ГОСТ -- то он обязателен для всех, но если отраслевые стандарты и стандарты предприятий - нужно договариваться. Здесь основная задача -- разобраться с правилами по-строения идентификаторов для деталей и сборочных единиц, стандартных изде-лий и материалов, использовать библиотеки электрических и электронных ком-понентов от одних поставщиков. В ИТ-периодике уже несколько лет обсуждают специальное ПО -- "клей для данных" на основе сопоставления атрибутов объ-ектов. Универсальных клеев не бывает, нужны технологии подготовки поверх-ностей и подбор соответствующего состава клея в зависимости от материала склеиваемых поверхностей. Все это требует согласованных усилий, мы уже на-чали работу и надеемся на понимание со стороны наших партнеров.

Как дальше будет развиваться информационная система предпри-ятия?

PDM-система сама по себе не может отражать реальную динамику про-изводства. Для этого требуется совместная работа с ERP-системой. На "Арсена-ле" выполнена большая часть предварительных работ. Первой нашей задачей было наполнить базу данных описанием наших изделий без привязки к их кон-кретным номерам, затем -- перейти к управлению конфигурациями по конкрет-ному номеру изделия, к интеграции PDM-системы с CAD-системами различно-го назначения и инструментами проектного управления. Мы хотим управлять всем портфелем заказов на верхнем уровне. И, наконец, учетная ERP-система позволит регистрировать с заданной точностью перемещение изделия по плано-во-учетным точкам, а потом уже регистрировать в реальном времени. Здесь уместна следующая аналогия: если ERP-система - это вуз, то PDM-система - школа, нельзя пойти в вуз без успешного обучения в школе.

При этом я убежден, что единая ИС нужна только тогда, когда можно получить выигрыш. Если не возникает синергетического эффекта, то зачем объ-единять PDM и ERP? Они все равно никогда не будут единой системой. Должна быть обеспечена возможность поатрибутной работы с объектами в объектно-ориентированной среде, когда в "родных" системах "рождаются" объекты, а в интегрированных - только атрибуты. И событие, произошедшее в одной систе-ме, инициирует процесс в другой.

Вы проводили работы по локализации и настройке PDM-системы своими силами, а это трудоемкий процесс. Откуда вы берете ресурсы для этого? Как мотивируете ИТ-сотрудников?

Основной мой партнер по нашему глав-ному проекту (локализация и настройка PDM-системы) - кандидат физико-математических наук Илья Музычук -- пришел к нам из ИТ-службы публичной библиотеки. Мы договорились, что начинаем проект и пока не доведем его до первых результатов, не расходимся. Вообще, новых людей набирать в отдел весьма сложно, они все у нас - "штучный товар". Наивно полагаться здесь на кадровую службу предприятия. В лучшем случае они могут по нашей заявке найти каких-то кандидатов. А собирать команду под проект может только сам руководитель.

Главный мотив для наших сотрудников - творческий, ведь мы создаем уникальное решение, в прошлом году даже получили патент на наши разработ-ки, а в перспективе замахиваемся и на то, чтобы оно стало отраслевым. Это и привлекает молодых ИТ-специалистов. Для них главное -- "не гнить", работать в творческой обстановке, самореализоваться. И мы в этом им максимально по-могаем: стараемся организовывать публикации, участвовать в различных тема-тических мероприятиях с выступлениями. Даже те, кто, может быть, в будущем и уйдет с завода, чтобы расти дальше, у нас могут получить уникальный опыт. И дело даже не в том, что мы не можем им предложить большие зарплаты, - я уверен, что купить творческий потенциал человека нельзя. Можно дать ему лю-бую зарплату, но если он не хочет или не может создавать что-то новое, этого от него все равно не получить.

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

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

Кроме того, в проекте и в работе ИТ-службы в целом необходимо уходить от "перекрестной" работы, когда каждый может выполнить работу другого, будем усиливать специализацию. Хотя сейчас у нас есть и должностные инструкции, и иерархия, все же основа нынешней работы ИТ-отдела - это сотрудничество. И в области творческих задач специализация у всех есть, а вот в рутинных, повсе-дневных задачах поддержки информационных систем и инфраструктуры одни и те же задачи могут выполнять разные сотрудники.

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

Кроме того, специалистам ИТ-отдела предстоит решать задачи проектного типа по внедрению ERP-системы, что для нас будет новым этапом. До сих пор глав-ным для нас была разработка PDM-системы.