s1_62909_27

База рисков 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 проектах. Я уверен, что дискуссия на эту тему будет интересна и полезна всему профессиональному сообществу. Если Вы хотите принять участие и описать риски, с которыми сталкивались в своих проектах — напишите нам.
Анатолий Суздальцев