To PLM or not? Рассказ о внедрении КИС на Усть-Каменогорском арматурном заводе

Борис Золотарев
Директор по ИТ УК «УКАЗ», в 2013 и 2014 годах работал директором по развитию ЗАО «Усть-Каменогорский арматурный завод»

Внедрение PDM/PLM­системы на Усть­Каменогорском арматурном заводе началось в 2009 году и дважды заканчивалось ничем. Именно так: дважды. Но была и третья, успешная попытка, о которой и пойдет речь в нашей публикации.

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

Попытка первая, и первые причины провала

В 2009 году техническим руководством завода совместно с ИТ­отделом под влиянием красноречия и убедительности выверенных описаний нескончаемых преимуществ профильных программ одной известной российской фирмы было принято решение не просто легализовать лишь конструкторский софт, но и перевести на «современные рельсы» работу всего конструкторско­технологического управления (КТУ), в штате которого на тот момент было более 100 человек, что составляло порядка 10% общей численности сотрудников завода.

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

Результаты первой попытки внедрения было решено считать «частично успешными», а на незадействованные 65% функционала приобретенного комплекса программ просто не обращать внимания.

Причины первого провала были вполне очевидны:

1. Спонтанное решение о внедрении целой комплексной PLM­системы при отсутствии внут­ренней потребности в данном продукте;

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

3. Увы, возраст и личные качества ответственных руководителей, трое из которых включали рабочие компьютеры не чаще одного­двух раз в неделю, да и то ради «Сапера» или «Пасьянса».

Но были и плюсы:

1. Никогда не встречавшиеся с данным ПО сотрудники увидели и «потрогали его своими руками», смогли оценить и сопоставить его функционал с привычной «бумажной» работой;

2. Некоторые из сотрудников оказались ответственными и прогрессивными, а некоторые проявили диаметрально противоположные качества, что позволило, во­первых, сформировать будущую команду проекта, а во­вторых, наметить кандидатов на сокращение.

Попытка вторая, и новые причины

Спустя год при утверждении годового бюджета на бюджетном комитете всплыли затраты на обновление PLM­системы, а поскольку сменившееся за год руководство завода стало внимательно относиться к неэффективному расходованию денежных средств, было решено внедрение то ли повторить, то ли завершить, в общем — довести до логического конца.

Ставка на автоматизацию конст­рукторско­технологической подготовки производства (КТПП) долж­на была, по мнению нового руководства и акционеров, помочь в решении целого ряда проблем, среди которых были и непропорционально разросшийся вслед за увеличением объемов производства штат, и своевременность выдачи конструкторско­технической документации (КТД) в производство, которое зачастую работало по старым чертежам без каких­либо внятных техпроцессов, и перспективная интеграция с внедряемой ERP­системой, для которой PDM должна была стать «поставщиком» точных и полных данных о составе и способах изготовления изделий. Так была устранена первая причина предыдущей неудачи.

Вторую устранили следующим образом. На этот раз менеджмент завода доверил ведение проекта опытному руководителю, который начал с подбора команды, в которую были включены самые продвинутые сотрудники КТУ и отдела информационных технологий. Они должны были оценить причины провала предыдущего «недовнедрения», собрать со всех неудавшихся пользователей список потребностей и выявленных проблем, оценить их актуальность, систематизировать и предложить способы их решения. Затем, совместно с руководителями отделов превратив эти проблемы и потребности в задачи на доработки и техзадания, были расставлены приоритеты их реализации, оценены сроки, способы и средства для их решения. Так родился план внедрения. При подготовке бюджета проекта было решено провести «довнедрение» собственными силами, деньги же тратить лишь на решение тех задач, которые невозможно было решить самостоятельно из­за недостатка квалификации или ограничений по срокам. Как говорится, «дешево и сердито», хотя если учесть бестолковые траты предыдущего периода, то не так уж и дешево.

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

Спустя два с половиной месяца напряженной работы, когда все выявленные проблемы были устранены, PLM­система была передана в опытную эксплуатацию всеми сотрудниками КТУ, а еще через месяц — в промышленную.

Однако чуда не случилось — сис­тема вновь не заработала.

Причины провала второй попытки:

1. Ограниченность функционала и нестабильность работы выбранной PLM­системы.

2. Некомпетентность руководителей среднего звена, переходящая в откровенный саботаж.

3. Недостаточная вовлеченность руководства завода, недоверие и нежелание делегировать ответственность.

4. Психологическая отстраненность сотрудников КТУ и их бизнес­процессов от смежных процессов остального предприятия.

Здесь явно требуются пояснения.

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

Пункты 2, 3 и 4 проще пояснить на примере. Так, в приказе о передаче PLM­системы в промышленную эксплуатацию ключевым требованием было прописано: «разработка и хранение документации только в электронном виде», что позволило начальнику технологического отдела разрешить сотрудникам разрабатывать новую или переносить имеющуюся техдокументацию не в формат CAPP­системы (часть внедренной PLM­системы), а продолжать «разработку» техпроцессов в текстовых редакторах, а то и вовсе прикладывать написанные от руки сканы1.

Но нет минусов без плюсов 2:

1. Большинство сотрудников научились работать в автоматизированной системе, поняли и прочувствовали принципы их функционирования.

2. «Айтишники» и все члены рабочей группы внедрения наработали неоценимый (но оцененный деньгами) опыт.

3. Самые откровенные саботажники (их было несколько) были уволены.

4. В результате непродолжительной эксплуатации были четко сформулированы требования к искомой PLM­системе.

Попытка третья, успешная

Наступил 2013­й год, на заводе была завершена крупная многолетняя программа модернизации, и акционеры задумались об ускорении возврата инвестиций. Одной из причин частичного невыполнения этой задачи была признана недостаточная оперативность разработки и постановки на производство новых модификаций продукции. В связи с этим было решено реанимировать проект автоматизации в объеме PDM — ERP — APS, то есть с обязательным упором на интеграцию. Иными словами — основной целью проекта было планирование и получение точной информации о загрузке производства, прохождении изделия по переделам и материальных остатках сырья и полуфабрикатов. Но всё это было трудно представить без полноценно описанных техпроцессов изготовления изделий и спецификаций на них3.

Началось все со встреч расширенного состава заинтересованных лиц, в который вошли в том числе генеральный директор и финансовый директор, где выбирались новое PLM­решение и поставщик.

На таких встречах сотрудники КТУ вполне ожидаемо настаивали на отказе от «дважды неудачного» пакета программ, но в качестве альтернативы безапелляционно предлагали несовместимый набор программ разных производителей, главным качеством одной из которых была «возможность разработки техпроцессов в привычных разграфленных формах ЕСКД». Об интеграции с используемыми CAD, различными справочниками материалов и стандартных изделий, ERP­, PLM­ и APS­системами они просто не задумывались, а кроме того, продолжали ошибочно считать, что «приедут специалисты, во всем разберутся, всё внедрят и настроят так, что от нас никакое участие даже не потребуется».

Более того, генеральный директор даже назначил одного из них, самого «реакционного», руководителем проекта! Правда быстро снял, а вскоре и уволил, после того как тот заснул через 5 минут первой же расширенной встречи, на которой он председательствовал! Вслед за этим сотрудником завод избавился еще от нескольких, теперь уже последних ретроградов и «тормозов прогресса».

Руководителем проекта вновь был назначен тот самый сотрудник, который, работая на втором этапе, представил сводную таблицу имеющихся на рынке решений (включая закупленное), в которой были сведены воедино все плюсы и минусы каждого из них на фоне выстраданных предыдущими неудачами требований к функционалу. С заметным отрывом «по очкам» победило решение «1С:PDM Управление инженерными данными». Но это — по очкам. Совместно было решено убедиться в работоспособности этого ПО на контрольном примере, тем более что генеральный директор компании АППИУС г­н Тимошин убеждал, что это — наиболее правильный путь внедрения их продукта. К тому же зафиксированная в стандартном прайс­листе цена была более чем адекватна. Более того, г­н Тимошин настаивал, что 1С:PDM — система параметризуемая, она не требует никакого классического внедрения, а большинство доработок будут вращаться вокруг используемых на предприятии печатных форм.

Таким образом, компании
АППИУС была передана предварительно очищенная от заводских «ноу­хау» бумажная документация, и спустя месяц, за время которого сотрудники вендора несколько раз уточняли неясности новой для них КТД, была назначена презентация для расширенного состава рабочей группы внедрения.

Естественно, все делалось в режиме интернет­презентации, которую, не побоюсь сказать, с блеском провел один из ключевых сотрудников АППИУСа Иван Берендеев. Но не только его ораторские способности убедили членов рабочей группы (РГ) в правильности выбора, но и те очевидность, скорость и устойчивость функционирования системы, которые многие из них так ожидали от продукта, использовавшегося ранее. Кроме того, немаловажными оказались сроки и цены внедрения, которые также обсуждались на этой виртуальной встрече. Выяснилось, что внедрение абсолютно подъемно в финансовом плане, поскольку требовало лишь обучения ключевых сотрудников КТУ и системных администраторов, после чего большинство настроек можно было произвести уже собственными силами.

Сказано — сделано. После всех необходимых формальностей — подписания договорных документов, оплаты, выбора сотрудников на обучение и, самое важное, подготовки списка практических вопросов преподавателю — в течение двух недель, теперь уже очно, с отрывом от производства, преподаватели АППИУСа Владислав Игонин и Олег Бессмертный обучили, в общем количестве, 30% состава КТУ, куда вошли и конструкторы, и технологи, и нормировщики, и архивариусы, и «админы». Обучение проводилось на том самом предварительно введенном контрольном примере, поэтому не вызывало того непонимания, какое могло возникнуть, если бы проводилось на неких абстрактных изделиях или на примерах из неизвестных сотрудникам УКАЗ областей деятельности. «Вишенкой на торте» явилось акцентирование внимания на недостатках имеющейся КТД, их разбор, критичность и способы устранения.

Но даже в этом случае проектный подход никто не отменял! Вновь сформированная рабочая группа внедрения определила «контрольные» изделия, которые должны быть внесены в базу 1С:PDM первыми и на примере которых будут обучены все остальные сотрудники КТУ. Был составлен график наполнения 1С:PDM этой информацией и, как и раньше, еженедельно сотрудники РГ собирались, чтобы оценить ход работ, разобраться с выявленными проблемами, наметить пути их решения. Как нам и обещали, технические проблемы в большей степени касались доработки печатных форм, в меньшей степени — простейших доработок программы, и были эти проблемы самыми простыми. Сложнее оказались проблемы организационного плана. Например, сотрудники КТУ недостаточно времени отводили на занесение в систему 1С:PDM «контрольных изделий». К сожалению, формально руководство КТУ понимало, что результатом автоматизации должно стать высвобождение и времени, и рук за счет отсутствия необходимости в повторном вводе примененной КТД, автоматизации различных расчетных блоков, простоты отслеживания занятости сотрудников, но на практике не уделяло этой работе достаточного внимания.

Понимая это, генеральный директор завода Андрей Кандинский активно участвовал в процессе освоения сотрудниками КТУ нового программного продукта, естественно на своем уровне. Он, например, предложил систему мотивации, регулярно обсуждал текущие проблемы с руководителем проекта, и даже научился пользоваться соответствующими интерфейсами 1С:PDM, чтобы оперативно следить за наполнением базы. Со временем с помощью различных организационных и административных методов эту работу удалось нормализовать. Для разработки и актуализации в электронном виде отбирались только те изделия, которые попали в годовой план производства завода, сроки появления в 1С:PDM различных видов КТД согласовывались со сроками постановки изделий на производство, а именно — ведомости [основных] материалов должны были быть готовы к моменту составления плана закупок, чтобы отдел снабжения успел закупить и привезти металл, а финансовая дирекция — подготовить необходимые объемы финансирования. Первыми из­под рук технологов должны были выходить заготовительные процессы, а последними — процедуры финальной сборки. В целом, процесс разработки КТД в новой информационной системе потребовал перестройки положенного в его основу бизнес­процесса взаимодействия конструкторов и технологов — как между собой, так и внутри профильных бюро соответствующих отделов КТУ. Эта работа велась руководителями подразделений КТУ совместно с руководителем проекта и дирекцией по качеству, в результате чего были актуализированы рабочие документы и инструкции, в том числе, в системе менеджмента качества завода.

Одной из проблем, не самой критичной, но стоившей изрядного времени и сил, была проблема разграничения прав пользователей. Имеющаяся «из коробки» система контроля доступа на уровне ролей и групп была достаточно гибкой, но требовала времени и большого количества рутинной однообразной работы. Например, расцеховщики вынуждены были «вручную» раздавать права на каждую точку маршрута каждой ДСЕ, и для одного изделия эта непродуктивная работа могла занимать до трех дней! В конечном счете собственная служба информационных технологий в лице участника рабочей группы программиста Алексея Цыбенко справилась и с этим вызовом. При этом свою роль сыграл еще один немаловажный фактор, который был учтен при выборе PLМ­системы: распространенность платформы «1С:Предприятие», программистов для которой можно отыскать в любом уголке СНГ, и открытость конфигурации самой 1С:PDM.

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

Сложности третьего этапа, которые не смогли помешать успешному внедрению проекта:

1. Акцентированность руководителей среднего звена на текущей работе, приводившая к постоянному срыву сроков ввода «проектной» КТД в 1С:PDM.

2. Принципиальная неспособность части рядовых сотрудников работать с современными информационными системами.

3. Отстраненность теперь уже сотрудников смежных подразделений — финансовой дирекции, отдела снабжения, производственных участков — от процесса внедрения4.

Опередив внимательного читателя, сразу акцентирую внимание на том, что успешно завершен был лишь проект внедрения PLM­системы, а целью­то теперь было внедрить целый комплекс из PLM­, ERP­ и APS­системы! Что сказать? Процесс продолжается, внедрение оставшихся частей будущего комплекса программ идет своим чередом, понятно, не без сложностей, но выученные из сделанных ошибок уроки позволяют нам с известным оптимизмом ожидать успеха в достижении и этой цели.

Вместо эпилога

Боюсь, не обойтись в этой статье и без морализаторства и повторения для многих прописных, а для многих — неочевидных истин.

Любой процесс внедрения информационных систем — это процесс изменений, но, к сожалению, далеко не все руководители (владельцы бизнесов и топ­менеджеры), от чьих решений зависит успешность проекта, это понимают. Подобного рода непонимание может привести (а в нашем случае это случилось дважды) к краху проекта.

Внедрение PLM/PDM­решения на машиностроительном предприятии со штатом сотрудников конструкторско­технологического управления, достигающим 10% численности всего состава предприятия, — это процесс, требующий тщательного планирования, оценки рисков, безошибочного выбора программно­аппаратного решения, а самое главное, перестройки мышления и бизнес­процессов большого количества людей, постоянного внимания и активного участия лиц, заинтересованных в результате.

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

Хочется поблагодарить как сотрудников завода УКАЗ, без которых автор не приобрел бы этот бесценный жизненный опыт, а сам завод УКАЗ так и остался бы в начале двухтысячных в области освоения современных технологий подготовки конструкторско­технологической документации, так и сотрудников компании ­АППИУС, слова которых за время «третьей фазы» проекта не расходились с делом, которые оказывали техническую поддержку всеми доступными коммуникативными средствами, постоянно улучшая и обновляя свой продукт — 1С:PDM, который по праву можно считать одним из явных лидеров рынка PLM­систем СНГ. 

САПР и графика 5`2015