Записи

База рисков PLM проекта: Вам заплатили? Вот вы и внедряйте!

Сотрудники некоторых предприятий относятся к проекту PLM как к проекту укладки кафеля. Кафель закуплен, узор в виде китайского орнамента со вставками из золотых слитков утвержден, все! После этого заказчику в совмещенном санузле не место.

 

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

 

Очень занятые люди

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

 

Конечно, на каждом предприятии есть 5-7 инициативных молодых людей, которые готовы вложиться в развитие, которым на самом деле интересно внедрение PLM технологий, которые готовы приложить усилия на благо проекта внедрения PLM. Но их мало, их авторитет невысок и им часто не позволяют этого делать старшие товарищи.

 

Как минимизировать этот риск

Поэтому, стоит заранее решить этот вопрос с руководством, менеджерами и инженерами. Решать его можно в нескольких аспектах:
  • Получить личные письменные гарантии от топ-руководства предприятия.
  • Добиться назначения молодого, энергичного и профессионального менеджера PLM проекта со стороны Заказчика.
  • Отдельно собрать и «зажечь» PLM проектом больше десяти человек ИТР моложе 35 лет.
  • В договоре на внедрение PDM/CAx явно прописать объем привлечения сотрудников предприятия и предусмотреть денежные штрафы за срыв привлечения.
  • Вести таймшиты участия сотрудников предприятия в проекте внедрения PLM.
  • На предприятии должны быть назначены премии за деятельное участие в проекте, в объеме не менее 50% общего размера премии.
  • Раз в две недели информировать всех сотрудников о ходе проекта с помощью стендов и рассылок.

Будьте начеку!

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

Сталкивались ли вы с такой ситуацией? Или описанная ситуация не встречается в жизни? Напишите Ваше мнение на нашем форуме.

Анатолий Суздальцев
Мы продолжаем цикл статей про риски в PLM проектах. Этот проект безусловно важен для отрасли. Если Вы хотите принять участие и описать риски, с которыми сталкивались в своих проектах, обязательно напишите нам.
Анатолий Суздальцев

База рисков PLM проекта: «Ваша система должна выходить в открытый космос без скафандра…»

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

 

«Проектирование в полностью автоматическом режиме»

Несмотря на пробелы в компетенциях, работающие на предприятии люди искренне «болеют» за него. Если предприятие решило повысить производительность труда, чтобы вырваться из замкнутого цикла, решило вложить деньги в PLM проект, во внедрение PDM и CAD, то они безусловно приветствуют это начинание. Свою роль многие менеджеры на предприятии будут в этом случае видеть в том, чтобы
  • а) максимизировать результат проекта по внедрению PLM и выжать все из контракта,
  • б) не допустить отхода от сложившихся десятилетиями практик и процессов, чтобы случайно не разрушить построенное предшественниками из «золотого века» советской промышленности.

 

Все это вместе приходит к тому, что менеджеры предприятий заказчиков часто выдвигают к PLM проекту откровенно нереалистичные и абсурдные требования, которые с одной стороны направлены на «абсолютную» автоматизацию, вплоть до «проектирования в полностью автоматическом режиме», а с другой стороны — требуют перенести сложившуюся у них практику конструирования в систему буквально, в полном соответствии с ГОСТ, ТУ и СТП, с регламентами 70-х годов. При этом не анализируется — какой практический эффект даст реализация этих функций.

 

История из жизни

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

 

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

 

Чаще все заканчивается по другому: все — от инженера до генерального директора — хором требуют реализовать способ кодирования из 60-х годов, особый порядок сортировки элементов спецификации, историческую форму производственного плана. И команда проекта внедрения PLM, время и ресурсы которой не безразмерны, занимается этими задачами вместо чего-то более полезного — отладки сквозного процесса изменений, например, или настройки механизмов ведения технологического состава изделия. Ясно, что это драматически снижает шансы PLM проекта на выживание и успех…

 

Как минимизировать этот риск:

  • Руководить проектом внедрения PLM со стороны предприятия должен опытный менеджер, который раньше работал у вендора, реселлера или интегратора техническим специалистом и дорос там до менеджера проекта. Он лучше представляет себе возможности PLM решений и смотрит на процесс более трезво.
  • Подрядчик PLM проекта должен постоянно учить сотрудников предприятия. Все беды — от недостаточной квалификации. Чем больше люди будут знать о PLM, тем меньше у них будет странных вопросов и требований. Может быть они просто не знают что требовать от вашей системы?
  • Показывайте и требуйте показов PDM/CAx системы «вживую», делайте тест-драйвы для проверенных пользователей. Очень часто люди не представляют что внедряют до момента запуска в эксплуатацию. Покажите людям на живом примере, что внедряется обычный «бульдозер», а не «антигравитационный марсоход подводного базирования».
  • Подрядчику PLM проекта нужно научиться говорить заказчику «нет, потому что…».
  • Заказчику нужно всегда задавать самому себе вопрос: «если система будет это уметь, то…». То что? Сколько человеко-лет времени и миллионов рублей это сэкономит? Если же это просто кому-то «хочется», «так всегда делали» или «будет очень удобно» — отложите это на потом.
  • Оценивайте и обсуждайте каждое требование к внедрению PLM в рублях и рабочих днях. Должна быть четкая связь: чем больше требований, тем дороже.
  • Детализируйте требования к внедрению PLM на несколько уровней и моделируйте реальные ролевые кейсы (Use Cases, Варианты использования): кто, что делает в системе и что должен получить. Очень часто после этого абсурдность некоторых пожеланий становится очевидна всем.
  • Радикально сократите количество источников пожеланий и требований. Требования к PLM — это не письма к Деду Морозу.
  • Не бойтесь прямо отказаться от общения с конкретным неадекватным, агрессивным человеком. Прямо скажите об этом его руководству. Чем дольше вы его терпите, тем больший ущерб он наносит людям и проекту внедрения PLM. При необходимости — не бойтесь прямого конфликта с ним, иначе будет хуже.
  • Если вы видите полную неадекватность другой стороны — откажитесь от проекта внедрения PLM. Это предприятие просто пока не готово к проекту. Не нужно иллюзий, что вы скорректируете требования по ходу, наоборот — ситуация только станет хуже.

Не искажайте ожидания

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

 

Сегодня вам позвонили и сказали деловым тоном: «У нас есть отличная идея — запустите наши трактора на орбиту Юпитера, чтобы они там убирали космический снег. Если вы согласитесь включить уборку снега на орбите в план проекта, то мы подпишем договор завтра — я обещаю!». Ну как, согласитесь? А ваш менеджер по продажам согласится? А начальник департамента? А директор?

 

А почему тогда соглашаетесь на «Автоматическую генерацию 3D-моделей деталей и сборочных единиц по изометрическим проекциям«? Сам видел подписанные ТКП на внедрение PDM (даже не к CAD!) от нескольких (!) крупных (!) российских ИТ компаний…
Есть ли такой риск в вашем проекте? Сталкивались ли Вы с аналогичной ситуацией? Поделитесь опытом на форуме.
Анатолий Суздальцев
Этой публикацией мы открываем цикл статей про риски в PLM проектах. Я уверен, что дискуссия на эту тему будет интересна и полезна всему профессиональному сообществу. Если Вы хотите принять участие и описать риски, с которыми сталкивались в своих проектах — напишите нам.
Анатолий Суздальцев