Записи

База рисков PLM проекта: Это сладкое слово бюрократия

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

 

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

 

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

 

Однажды я был свидетелем того, как это цветет и пахнет в космической отрасли. Заказчик был старой закалки и обожал собирать совещания человек на 25-40. В большой зашторенной комнате только за столом переговоров сидело человек 15, а еще 15-20 человек сидело «во втором ряду» — на стульчиках вдоль стен. Совещания тянулись часами, решить что-то по существу было невозможно. Все «гости» выгибали грудь перед начальством и пытались высказаться по вопросам в которых они мало понимали и которые к ним вообще не относятся. Зато при появлении конкретных задач все аргументированно валили их друг на друга, а под занавес директор традиционно находил одного-двух виноватых во всех бедах. Но зато теперь я, кажется, понимаю, почему ракеты не летают.

 

Опасно в бюрократии то, что она не только «занимает» своих авторов, но и блокирует всю полезную, продуктивную часть команды, которая вынуждена вместо проектирования, разработки и тестирования писать документы о проектировании, разработке и тестировании.

 

Этому недугу подвержены как команды заказчика, так и команды подрядчика. Где найдутся люди с пробелами в компетенциях и без явных обязанностей, там и расцветет этот цветок.

 

Конкретные способы снизить уровень бюрократии:
  • В команде не место людям, которые только «контролируют», «курируют», «отвечают за коммуникации», «оказывают методологическую поддержку» или «от холдинга».
  • Каждый член команды должен иметь конкретные задачи на всех этапах.
  • В команде не место людям, не обладающим должной компетенцией.
  • Совещания проводятся на территории той стороны, которая в данный момент имеет больший фронт практической работы.
  • В совещаниях участвует не более 4-5 человек, иначе все-равно получится базар.
  • Конечный перечень проектных документов должен быть определен в договоре, а их примерные содержание и объем — в Техническом задании.
  • Каждый документ подписывают строго не более 4-5 человек со всех сторон, включая согласующих. Матрицу подписания закрепите документально (в том, документе, который у вас больше подойдет по смыслу — Договор, Техническое задание, Устав, очередной протокол).
  • Различные «комитеты» склонны либо к организационным коллапсам, либо к профанации. Если вы не уверены в том, что сможете совладать с «комитетами» в проекте, то лучше от них отказаться. Введите персональную ответственность за решения.
  • Опыт показывает, что на внимательное прочтение документа объемом до 10 страниц достаточно 15-20 минут, а на документ объемом свыше 100 страниц люди в любом случае тратят не более 3-4 часов. Поэтому, установите срок утверждения документа до 10 страниц — 2 рабочих дня, а более 10 страниц — 3 рабочих дня. Если после истечения этого срока респондент не дал отклик, документ считается принятым без возражений.
  • Боритесь с бюрократами их же оружием. Если кто-то начал бурно запрашивать обширные документы и перетягивать ресурсы на их разработку, согласование, исправление, то найдите способ затребовать двадцать регламентов по его работе у него самого. После чего раз в месяц шлите на каждый документ любые замечания. Чем страннее и парадоксальнее будут замечания, и чем их будет больше — тем лучше. На это можно выделить один день в месяц — польза от заблокированного бюрократа окупит это вложение.
  • Получите поддержку топ-менеджмента в борьбе с бюрократией. Они должны поддержать вас хотя бы на словах.
  • Получите в борьбе с бюрократами поддержку широких масс как у подрядчика, так и у заказчика, бюрократы должны стать комичным образом.

 

Я не говорю о том, что документы и совещания не нужны. Конечно — они нужны. Но когда работы по созданию документов и проведению совещаний начинают занимать более 50% времени проекта, а версии документов легко переваливают за v.10.5 — вот это тревожный знак.

 

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

 

«…Протокол совещания по поводу переноса совещания требует дополнительного совещания, потому что в нем комитетом заместителей секретарей были обнаружены опечатки в сноске на регламент совещания секретарей проекта…»

 

Уже тошнит? Ну так не пускайте эту мерзость к себе в проект!

 

База рисков PLM проекта: Менеджер проекта «из смежной области»

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

Менеджер проекта «из смежной области»

Если не нашлось Менеджера проектов с опытом в PLM, то руководить PLM проектом часто ставят человека, который имеет опыт внедрения CRM, ERP, BI или других систем.

Логика примерно такая: его дело — грамотно управлять проектом, а для этого ему нужно знать PMBOK, Microsoft Project и PowerPoint, а также иметь хорошие коммуникативные навыки. Если же что-то ему нужно будет знать из специфики PLM, то он всегда сможет спросить у команды.

Доля истины в этой мысли есть. Действительно, никто не может быть компетентен во всем. Безусловно, по большинству вопросов менеджеру проекта лучше советоваться с командой, даже если он считает, что знает ответ.

Но для этого нужно:

  1. Объективно видеть пределы своей компетенции.
  2. Понимать что, как и у кого лучше спрашивать.
  3. Понимать полученный ответ и иметь возможность его анализировать.

И вот с этим у людей «из смежной области» обычно проблемы…

Что произойдет, если вашим проектом будет управлять человек без знания PLM:

  • Он будет принимать решения исходя из опыта, который был им получен в другой области. Например, если у человека был опыт внедрения CRM, то как он представляет себе справочник стандартных изделий? Примерно, как перечень контрагентов, но только «про железки». Какие 3D модели? Какое вторичное представление?
  • Человек не сможет правильно формулировать вопросы и понимать ответы на них. Поэтому, команда ему вряд ли поможет.
  • Из-за этого, при принятии решений он будет существенно ошибаться в уровне сложности, в рисках, в необходимых ресурсах и компетенциях. Нужно или быть готовым к «учебным» потерям в проекте или проверять и корректировать его оценки и вытекающие из них решения.
  • Чаще всего человек «из смежной области» не увидит приближающихся рисков. Просто потому, что у него нет релевантного опыта.
  • Фактически, человека нужно будет учить новой области. Кто-то должен будет этим заниматься, вкладывать время. Может быть, вы хотите этим заниматься?
  • «Уполномоченный новичок» не сможет пользоваться полным уважением команды. Каким бы он не был хорошим парнем, команда всегда может сказать ему «ты просто этого не понимаешь». И он сам внутренне ждет этого момента.
  • Заказчик, партнеры и сотрудники после того, как поймут уровень компетенции человека могут начать им манипулировать в своих интересах, пользуясь его недостаточной компетенцией.

Конечно, все не так ужасно, и истории успеха есть. Можно за 2-3 года работы в таком режиме подготовить неплохого специалиста.

s1_63984_63Да, это будет очень похоже на обучение пилотов военной авиации прямо в воздухе.

Возможно, автомобильные права категории «В» помогут «пилоту», возможно даже никто не пострадает, сам же человек полюбит небо, станет профессионалом, а вам все будут говорить «спасибо большое» за нового пилота.

Вы в это верите? Такие истории заканчиваются иначе. Поэтому, к штурвалу реального самолета пускают только заранее подготовленных людей.

Как избежать этого риска:

  • Заранее определите требования по знанию предметной области и PLM. Используйте наш текст вакансии, который размещен в разделе «Скачать»;
  • Не верьте тем, кто говорит, что для менеджера проекта знание PLM не обязательно. Оно обязательно;
  • Не соглашайтесь на предложения типа «BI это почти то же самое, что и PLM, человек разберется за недельку». Не разберется;
  • Не верьте словам на собеседовании. Проверьте знания кандидата на простом тесте на знание PLM. 5-10 вопросов сделают ситуацию намного прозрачнее;
  • Не проводите собеседования в одиночку, обязательно приглашайте коллегу. Его мнение поможет вам лучше увидеть сильные и слабые стороны кандидата, которые вы можете пропустить в ходе разговора;
  • Обязательно позвоните предыдущим работодателям и спросите их мнение по компетентности менеджера. Расспросите их — насколько хорошо он понимал предметную область и процессы PLM;
  • Ищите менеджеров проектов там, где они могут быть — в профильных группах в Facebook (например, www.facebook.com/groups/plm.center), на конференциях, на профильных курсах, а также на портале plm.center.
  • Очень важно: Не давайте никому второго шанса. Если так получилось, что вы взяли на позицию Менеджера проекта человека, который плохо ориентируется в PLM, то не стройте иллюзий — лучше уже не станет. Немедленно увольняйте человека с испытательного срока, не принимайте в штат. Вы сэкономите его и ваше время.

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

База рисков PLM проекта: Один на всех или охота за экспертом

Волшебное начало

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

 

Выступление специалистов по PLM произвело на вас большое впечатление и вы просите этих людей в команду своего проекта. Подрядчик отвечает, что эти люди — лучшие, и что они, конечно, нарасхват. Но! Специально для вас он договорится о том, чтобы их включили в состав команды. Если вы подпишете договор на приобретение и внедрение PDM/CAx систем.

 

И много позже, когда PLM проект уже начался, вы неожиданно видите в команде совсем других людей, с другой, не такой прекрасной, компетенцией. Где же звезды, которые блистали для вас на презентации? Они на других презентациях и на других PLM проектах. Менеджер по продажам вас не обманул, они указаны в составе команды проекта. Но точно также они указаны еще в десяти командах и плюс к этому запланировано еще двадцать презентаций и выступление на конференции.

 

Сколько времени в неделю при таком раскладе у них будет на ваш проект?

Давайте посчитаем… Около двух часов в неделю! В месяц это будет около восьми часов, то есть один рабочий день. Что можно сделать за это время? Да ничего! Можно успеть приободрить заказчика, принять участие в паре совещаний, дать советы команде, ответить на пару писем и все…

 

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

 

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

 

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

 

Как не стать заложником такой ситуации? Как выцарапать нужных вам людей на нужное время?

Ниже даны 10 неудобных для подрядчика советов:

 

  1. Сначала идентифицируйте «технологического лидера». Спросите впрямую об этом у рядовых членов команды подрядчика по внедрению PDM/CAx, обязательно спросите у бывших сотрудников подрядчика, запросите резюме членов команды, спросите у конкурентов на рынке PLM, присмотритесь к людям на презентации PDM/CAx решения, поднимите расписания выступлений PLM конференций. Если будете настойчивы и внимательны, то обязательно поймете — кто на них был основным техническим экспертом и спикером. Добейтесь его включения в проект.
  2. Закрепите в приложении к договору состав команды (включая резервы и замены) поименно.
  3. Сделайте обязательным условием вовлечение каждого специалиста с коэффициентом не менее 0,4 FTE. Такой коэффициент характерен для ситуации, когда человек работает на двух PLM проектах. Если специалист будет вовлечен всего в два проекта, то это, скорее всего, не повредит вашему проекту. И в то же время будет приемлемо для подрядчика.
  4. Требуйте от подрядчика еженедельные таймшиты по всей команде. И самое главное — проверяйте их! Если вы не будете их проверять, вас рано или поздно (не со зла, конечно), начнут дурить.
  5. Организуйте для команды рабочие места на площадке внедрения и почаще старайтесь организовать рабочий процесс сотрудников подрядчика на своей территории. Причем, если им нужно поработать над документами, то будьте готовы обеспечить им необходимые для этого условия — отдельное помещение, тишину, время, доступ к справочной информации и быстрые ответы на вопросы от сотрудников предприятия.
  6. Будьте видимым. Не нужно оставлять проектную команду наедине с собой на долгий срок. Она может решить, что можно пока заняться теми проектами, где заказчик более материален и взволнован своим PLM.
  7. Адекватно оценивайте объем работ и сопоставляйте его с планами и таймшитами. Для этого вам потребуются свои PLM специалисты. Что же, это в любом случае не будет лишним!
  8. Наметьте промежуточные точки, с привязанной к ним сдачей конкретного результата (документ, часть работ, отчет). Обычно, если после продажи вам проекта команду бросили на другие «выступления», то проект начинает жить очень неравномерно — то необъяснимо «проседает» на месяц, то перед сдачей этапа начинается нездоровая активность, за которой вы не поспеваете. Регулярные обязательства затруднят незаметное отвлечение команды с вашего проекта.
  9. Установите хорошие человеческие отношения с командой подрядчика, покажите команду предприятия с человеческой стороны. Вложения в отношения вернутся вам сторицей на проекте.
  10. Не нужно переусердствовать в выжимании из подрядчика соков и остатков прибыли по PLM проекту с помощью аукционов, переторжки или агрессивных переговоров и манипуляций. В такой ситуации вы не столько лишаете подрядчика прибыли, сколько себя тех ресурсов на проекте, которые могли бы на нем быть, но после резекции бюджета уже не будут принимать участие. В самом деле, вы же не думаете, что подрядчик будет работать на вас с отрицательной рентабельностью? Нет, он свое так или иначе компенсирует. И это не самым лучшим образом скажется на вашем проекте. Так что, позвольте подрядчику иметь прибыль.

Одиннадцатое правило.

О нем, наверное, забывают чаще всего. Попробуйте не только принуждать подрядчика выполнять свои обязательства по ресурсам, но попробуйте сделать и так, чтобы людям самим хотелось бы выполнить работу для вас качественно и быстро. Пусть они выделяют вас среди остальных заказчиков. Для этого нужно не так уж и много: будьте дружелюбными, конструктивными и адекватными партнерами. Активно участвуйте в проекте, показывайте свою заинтересованность в результате, делайте свою часть работы так, как хотите чтобы работали на вас. Не пытайтесь выдавить из подрядчика всю его прибыль с помощью переторжки, не устраивайте сцен, не плетите интриг, будьте открытыми и искренними. И вы увидите — проекты станут результативнее.

 

Три фразы, после которых стоит начинать беспокоиться

С хорошим подрядчиком у вас не возникнет проблем при внедрении этих правил. Это вполне приемлемые,простые и понятные правила, если ты действительно собираешься выполнять обещания и направлять ресурсы на PLM проект. А если исполнитель работ с болью и удивлением начинает рассказывать, что «у них так не положено», «вы что, нам не доверяете» или «как вы себе это представляете», то это повод удвоить внимание к выделению вашим подрядчиком ресурсов на проект.

 

А в вашем проекте затраты ресурсов подрядчика были для вас прозрачны? Поделитесь опытом на форуме.
Анатолий Суздальцев
Мы продолжаем рассказывать про риски в PLM проектах. Заказчик видит одни риски, подрядчик опасается других. Часто они расходятся в оценке одних и тех же событий. Но на карте всегда — судьба проекта, а иногда и успешное будущее предприятия. Если вы хотите внести свой вклад в снижение рисков в PLM проектах в России, обязательно напишите нам.
Анатолий Суздальцев

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