Записи

Простой способ для руководителя предприятия получить целостное видение PLM

Активное внедрение на предприятиях СНГ CAD систем шло почти с момента их появления. Масштабные приобретения CAD, внедрение PDM систем и начало комплексных PLM проектов стартовали с 2005-2008 годов. Сейчас сложно найти предприятие, на котором не было бы инициатив, связанных с PLM, готовящегося или идущего проекта.

К сожалению, историй успеха существенно меньше.

Читать/смотреть далее

Как управляется PLM программа PHENIX в EADS

В прошлых статьях по программе PHENIX мы разобрали организационный ландшафт и убедились в его невероятной сложности, обсудили цели и задачи программы. Очевидно, что в таких условиях программа жизнеспособна только при условии грамотно выстроенного управления.
Давайте обсудим все с организационными диаграммами в руках!
 structure

Читать/смотреть далее

База рисков 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 заставляет привлекать сторонних специалистов, как от Вендоров внедряемого ПО, так и специалистов по узкоспециализированным направлениям, например, таких как Информационная безопасность гос. предприятий).

Читать/смотреть далее

Понимание предметной области делает проект интересным

После просмотра фильмов «Каждое воскресение» и «Огни ночной пятницы» мне непременно захотелось узнать, что же такое Американский футбол. Мое знакомство с ним началось с Супер Кубка 2008, после которого я стал фанатом команды New York Giants и по сей день я не пропускаю ни одной их игры. За это время я узнал много «тонкостей» футбола, и повторный просмотр фильмов был значительно интереснее нежели первый. Понимание правил и сути самой игры заставили меня смотреть на фильм с разных сторон, открылась вся его красота и смысл. Помимо красоты на поверхность вылезли и откровенные «ляпы» переводчиков фильма, когда, например, квотербека называли полузащитником. Это говорит о том, что люди, отвечающие за перевод, не знали игру, не знали термины и правила – не знали предметную область. Понимание предмета позволит Вам рассматривать его с разных сторон и убережет от многих ошибок.

Читать/смотреть далее

Хочешь внедрять PLM профессионально — осваивай предметную область

Дураки и дороги

Как известно, «в России две беды — дураки и дороги». И если по дорогам (а также разгильдяйству и бюрократизму) можно ударить автопробегом, то что делать с первой бедой? В PLM проектах зачастую возникают конфликты между его участниками, связанные с недопониманием друг друга. А некоторые ситуации приводят к серьезным проблемам.

Трудности перевода

Даже если принять как факт, что Заказчик бесконечно хорошо разбирается в бизнес-процессах предприятия, а Исполнитель в совершенстве знает инструмент, который он внедряет, мы все равно сталкиваемся с трудностями взаимопонимания:

  1. Размытое формулирование потребностей. Заказчик попросту не знает, на что способен инструмент.
  2. Поверхностное описание внедряемого решения без учета специфики Заказчика. Исполнитель показывает типовую конфигурацию PLM, которая, по его мнению, полностью способна реализовать все его задачи.

02 Client&Imlementor

Проблема взаимопонимания Заказчика и Исполнителя всегда является источником одного из самых опасных рисков проекта – неконтролируемого увеличения его границ (Project scope).

Принтер не печатает gif анимации

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

Как известно, бухгалтера имеют дело с огромным количеством бумаги. Выяснив, что при подготовке документов тратится сто тысяч миллионов бумаги формата А4, руководитель решил, что назрела оптимизация. Все его требования сводились к «крутому принтеру, который быстро печатает с двух сторон». Такое задание и было поставлено перед IT специалистами.

Итог: купили супер принтер (с максимальным количеством печати бумаги в минуту) с бюджетом чуть больше чем «Очень дорого». Он умел даже раскладывать по копиям и сшивать скрепками.

Через некоторое время его эксплуатации стало понятно, что все его «крутые фишки» не востребованы, а принтер не был рассчитан на большой объем печати. Это яркий пример того, что Заказчик не описал свои потребности, а Исполнитель, не зная их, и, особо не утруждаясь, просто выбрал самый «типовой» вариант.

03 Print

Что делать и кто виноват

Выходит, что самая идеальная ситуация в проекте — это когда:

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

По какую сторону баррикад проекта внедрения PLM вы бы не находились, если хотите это делать профессионально, осваивайте предметную область. Иначе границы вашего проекта гарантировано «поплывут» в сторону увеличения.

Простой шаг к освоению предметной области

Вы сейчас читаете одну из цикла заметок, посвященных изучению предметной области машиностроения.
Заметка представляет собой сокращенный вариант статьи, потому что редакторы plm.center подозревают, что сейчас люди разучились читать длинные тексты и сократили его :-)

Поэтому, я жду вас на вебинаре «Что не знает команда проекта о предприятии».

Записывайтесь — будет интересно!

Евгений Ураски

База рисков 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 проектах в России, обязательно напишите нам.
Анатолий Суздальцев

PHENIX — Необычные цели и задачи PLM программы PHENIX

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

eads_phenix

Читать/смотреть далее

PHENIX: 150 000 сотрудников, 170 площадок — непростые условия внедрения PLM в EADS

Всем интересно узнать побольше про PHENIX — уникальный в своем роде проект. И даже не проект, а программа PLM в EADS. Но информации на русском (да и английском) языке почти нет. Мы решили заполнить этот пробел!

eads_phenix

Читать/смотреть далее

Портфолио