Многие предприятия начинают автоматизацию традиционно - с модулей бухгалтерии, финансов или 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-системы.