Записи

Как получить субсидии на приобретение программного обеспечения от Минпромторга

В июне 2015г. Министерство промышленности и торговли Российской Федерации провело отбор операторов услуг на возмещение части затрат на приобретение специализированного инжинирингового программного обеспечения. Отбор проходил в рамках реализации подпрограммы «Развитие инжиниринговой деятельности и промышленного дизайна» государственной программы Российской Федерации «Развитие промышленности и повышение ее конкурентоспособности».

Субсидии Минпромторга могут составлять до 75% от стоимости приобретаемого программного обеспечения.

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

Как управляется 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 — вот это тревожный знак.

 

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

 

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

 

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

 

Критерий 10 000 часов при наборе команды

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

Критерий 10 000 часов

Этот критерий был открыт и позднее сформулирован Малкольмом Гладуэллом в своей книге «Гении и аутсайдеры», ставшей бестселлером. Малкольм проанализировал огромное количество информации, историй успеха, наблюдал за людьми и заметил следующее правило:
  • Люди, которые целенаправленно занимаются какой-либо профессиональной деятельностью регулярно, по 20-30 часов в неделю, через некоторое время становятся лучшими. К моменту, когда такой человек набирает 10 000 часов опыта, он, как правило, обладает блестящей экспертизой. Лучшие достигают этого к 26-27 годам непрекращающейся учебы и интенсивной работы, сопровождающимися искренним интересом к PLM. Дальше они уже с привычной энергией начинают идти дальше и осваивать менеджмент, предпринимательство, смежные области, становясь все более уникальными специалистами.
  • Люди, которые тоже стараются, но при этом не так сфокусированы на профессии, после окончания вуза, к 30 годам накопят 6 000 — 7 000 часов опыта. Но они уже не смогут конкурировать с лидерами. К сожалению, это «середнячки». Они могут между делом пойти попить чай, поболтать с коллегами, никогда не задерживаются на работе, не всегда стремятся участвовать в новых проектах. Есть работа — работают ее, нет — тоже не беда!
  • Ну и те, кто в принципе не могут сфокусироваться на чем-то одном и не сильно концентрируются на происходящем в рабочее время, наберут за сопоставимый отрезок времени максимум 3 000 — 4 000 часов в нужной отрасли. Ведь очевидно, что у них вряд ли будет выходить более 10-15 часов в неделю посвященных именно профессии, а не новостным сайтам и социальным сетям.

Простые выводы

Из всего этого можно сделать два, казалось бы простых вывода:
  1. Хочешь стать профессионалом — упорно трудись, непрерывно учись, общайся с лучшими экспертами в области.
  2. Хочешь найти профессионала в свою команду — попробуй проанализировать его резюме с точки зрения 10 000 часов.
Но теперь они подтверждены простым, механистичным критерием 10 000 часов, который легко применять.

Кейс «Битлз»

Это правило сработало даже для «Битлз». Малкольм посчитал, что до приезда в 1964 году группы в США, музыкантов в 1960 году пригласили в Гамбург, где они должны были беспрерывно играть в барах, чтобы привлечь внимание публики.
Музыканты вспоминали позже, что им приходилось играть по восемь часов без перерыва, работать семь вечеров в неделю.
Согласно расчетам Малкольма, «Битлз» дали уже около 1200 живых концертов к тому моменту, когда добились успеха. Все просто — они набрали 10 000 часов.
s1_577_44
Безусловно, это не единственный критерий и он годен только для грубой оценки — есть у человека «техническая» возможность быть профессионалом или нет. Безусловно, человек может «мимикрировать» под профессионала, на первых порах сложно проверить, не кроется ли за хорошим резюме ленивый обитатель социальных сетей с 3 000 случайно профессиональной деятельности за спиной. Но для этого вам и нужна голова на плечах, помощь HR менеджера, и свои 10 000 часов опыта, чтобы отобрать в команду настоящих людей.
Анатолий Суздальцев
Очень тяжело найти хорошего специалиста в PLM. Мы планируем помочь в разрешении этой ситуации. Во-первых, мы начинаем выкладывать в открытый доступ описания вакансий и требования к кандидатам в области PLM.
Во-вторых, мы готовы к широкому сотрудничеству с HR специалистами, PLM компаниями, предприятиями в поиске и подготовке специалистов. Напишите нам.
Анатолий Суздальцев

База рисков 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 и по сей день я не пропускаю ни одной их игры. За это время я узнал много «тонкостей» футбола, и повторный просмотр фильмов был значительно интереснее нежели первый. Понимание правил и сути самой игры заставили меня смотреть на фильм с разных сторон, открылась вся его красота и смысл. Помимо красоты на поверхность вылезли и откровенные «ляпы» переводчиков фильма, когда, например, квотербека называли полузащитником. Это говорит о том, что люди, отвечающие за перевод, не знали игру, не знали термины и правила – не знали предметную область. Понимание предмета позволит Вам рассматривать его с разных сторон и убережет от многих ошибок.

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

Электронная подпись. Просто о сложном.

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

Наличие электронного документооборота на предприятии всегда подразумевает необходимость применения электронной подписи (ЭП). 6 апреля 2011 года был принят ФЗ № 65, вносящий изменения во все законодательные акты и меняющий словосочетание «электронно-цифровая подпись» на «электронная подпись» (поэтому правильно говорить электронная подпись, а не электронно-цифровая подпись, как мы все привыкли).

Закон выделяет три вида электронных подписей:

  • простая электронная подпись;
  • усиленная неквалифицированная электронная подпись;
  • усиленная квалифицированная электронная подпись.

схема

Что нам дает этот закон

Данный закон в совокупности с ГОСТами дает нам возможность полноценного использования документа электронного как подлинника на предприятии.

Основные выводы:

  • Электронные документы, хранимые, разрабатываемые, согласовываемые и утверждаемые в PDM-системе могут иметь любой статус по ГОСТ 2.102-68 (оригинал, подлинник, дубликат, копия).
  • Информация в электронной форме, подписанная простой электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью (статья 6 ФЗ № 63).
  • ГОСТ 2.511-2011 «ЕСКД. Правила передачи электронных конструкторских документов. Общие положения» и ГОСТ 2.051-2006 «ЕСКД. Электронные документы. Общие положения» регламентируют правила обмена информацией между предприятиями, в которых документ электронный выступает подлинником.

Таким образом, применение простой цифровой подписи позволяет придать документу электронному статус подлинника. А факт подписи документа простой электронной подписью обеспечивается введением пароля для учетной записи, например, при выполнении задачи согласования в процессе согласования и утверждения КД в PDM-системе.

Заключение

В этом обзоре я не претендую на рассмотрение всех юридических аспектов применения ЭП на предприятиях при электронном документообороте. Скорее это приглашение к дискуссии и обмену информацией, наработанной за время, которое прошло с принятия этого закона.

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

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

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

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

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

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

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

02 Client&Imlementor

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

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

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

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

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

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

03 Print

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

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

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

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

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

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

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

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

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

Что предлагают PLM вендоры для решения интеграционных проблем при проектировании мехатроники? Часть 2.

ПРОДОЛЖЕНИЕ. НАЧАЛО ЗДЕСЬ.

Как можно преодолеть указанные проблемы? Очевидно, что простого решения на данный момент не существует. Я не могу на этом моменте щелкнуть пальцами и сказать «Используйте систему ХХХХХХ и она решит все ваши проблемы, потому что она основана на лучших практиках и так далее, и так далее». Объективно, такой системы пока нет. Windchill ECAD Workgroup manager и ENOVIA Collaborative Design for ECAD могут помочь вам качественно упаковать все данные в PDM системе, сохранить их от потери и предотвратить ряд системных рисков, но не предложит решения для интеграции процессов и интеграции справочных данных. Teamcеnter предложит очень большое количество различных концепций и отдельных продуктов в данной области, но недостаточная интеграция этих решений друг с другом и их тяжелый для восприятия интерфейс (встречайте конфигурационные файлы!) затруднят их практическое использование.

Выйти из комнаты и осмотреться — хороший план!

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

  • Важно выйти из своих кабинетов в офисах вендоров и вместе с наиболее продвинутыми инженерами-конструкторами и разработчиками встроенного программного обеспечения создать реалистичное и практически применимое видение сквозного процесса проектирования мехатроники.
  • Также нужно быть готовыми к разработке принципиально новых, основанных на этих принципах систем, вместо легкой кастомизации своих базовых решений. Возможно, этому может также поспособствовать приобретение глобальными PLM компаниями разработчиков EDA решений.

Такой сценарий выглядит логичным и, возможно, реализуется, когда стоимость отраслевых компаний по разработке EDA и возможности глобальных игроков придут в некоторое соответствие. Пока же идет разработка принципиально новых решений (если она идет), стоит заняться рутинной работой по унификации ПО в рамках доменов: устранением «зоопарка» EDA, MCAD систем, настройке типовых, унифицированных workflow в каждой системе и наполнению каталогов систем.

Вперёд вендора в пекло не лезут

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

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

Рациональный план

Таким образом, разумным будет ограничиться просто хранением данных по печатным платам и программному коду в PDM системе с использованием модулей интеграции с EDA, предлагаемыми основными PLM вендорами — Siemens PLM Software, PTC, Dassault Systemes. Простое хранение всех данных в PDM хотя и не даст прорыв, но по-крайней мере сократит риски потери данных. Тем временем будем ожидать разработки PLM вендорами видения по-настоящему комплексной интеграции этих доменов.

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

s1_185_40

Также рекомендуется отказаться от практики «закрытых на ключ комнат» и провоцирующего на это функционального типа управления. Внедряйте взамен него проектное или матричное управление. Активно формируйте кросс-группы (кроссфункциональные, кросструктурные, кросскультурные) проектные группы, которые помещайте вместе, в одно помещение с их менеджером проекта. Формируйте сообщества практиков на предприятии. Назначайте ответственных за сквозной процесс. Внедряйте понятные всем KPI для всех уровней сотрудников, результаты по которым размещайте в открытом доступе, в том числе и по топ-менеджменту.

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

Знания — сила

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

  • сотрудничество с вузами, в первую очередь зарубежными;
  • партнерство с западными предприятиями, при этом с условием доступа к их компетенциям;
  • привлечение сотрудников, имеющих опыт работы в западных компаниях;
  • компенсация изучения иностранных языков;
  • участие в западных конференциях, выставках, учебных программах;
  • материальное поощрение исследований и инициатив в области оптимизации процессов;
  • поддержка людей с предпринимательским складом ума организационная помощь в создания спин-офф компаний в рамках предприятия;
  • приобретение и предоставление в открытый доступ для сотрудников западной профессиональной литературы и периодики;
  • блокирование очагов консервативного мышления в организации, лишение их накопленной административной власти;
  • избавление от балласта (сотрудников, не обладающих тягой к знаниям, апеллирующих к устаревшим стандартам, не выполняющих свою работу, ленящихся) в объеме не менее 10% от общей штатной численности ежегодно в течение 3-5 лет;
  • повышение оклада ИТР до уровня заработной платы + 10% в средней ИТ компании в регионе.

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

Сбросив непроизвольный пафос последних строк, обратимся к аналитике. Мы увидим, что близкий к предложенному план предлагает и Aberdeen Group. Конечно, у них нет такой остроты проблем, связанных с кадрами, знаниями и менеджментом, поэтому их рекомендации сосредоточены на кроссдисциплинарной интеграции и развитии бизнес-процессов, централизации инструментария управления данными и технологических аспектах.

Image
Рис. 2. Tactics to Improve Mechatronic Development

Прогнозы, предсказания и видение будущего

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

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

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

Анатолий Суздальцев

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

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

Анатолий Суздальцев

 

При написании статьи использованы данные следующих источников:

Портфолио