Что такое управление знаниями

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

Но прошло всего… лет 7-8, — и я не просто увидел компанию, где управление знаниями работало и приносило ощутимый эффект, но и 2 года подряд погружался внутрь их собственной системы, знакомился с ее особенностями, развитием, людьми… Это была компания ConocoPhillips, работу по обмену знаниями в которой возглавлял Дэн Ранта. И лишь после этого я начал искать и находить своих коллег в России. С каждым годом их становится все больше!

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

И, кстати, есть вполне определенные 2-3 десятка инструментов управления или обмена знаниями, которые широко используются во всем мире (к слову, из более чем 100 известных). Каждый из них может работать и у нас!

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

Тема очень интересная, и я планирую в ближайшее время провести вебинар по теме Управления знаниями.

Владимир Баронов

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

Владимир Баронов.

Чьим достоянием является ЕСКД?

Ответ на вопрос, вынесенный в заголовок, не так очевиден, как кажется.

 

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

 

Сейчас Федеральное Агентство по техническому регулированию и метрологии наконец-то выполняет требования постановления Правительства РФ от 25 сентября 2003 г. № 594 «Об опубликовании национальных стандартов и общероссийских классификаторов технико-экономической и социальной информации», и понемногу ГОСТ, в том числе и ЕСКД, появляются в свободном доступе на сайте Федерального Агентства по техническому регулированию и метрологии.

 

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

 

Сейчас ГОСТ, включая ЕСКД, можно посмотреть на сайте Федерального Агентства по техническому регулированию и метрологии. Но почему-то, по-прежнему нельзя скачать на жесткий диск нужную подборку стандартов, почему-то опубликованы только сканированные копии ЕСКД. И самое главное — до сих пор сохраняется неоднозначность с возможностью свободной публикации стандартов ГОСТ. Это тем более удивительно, потому что это национальные стандарты, создающиеся на бюджетные деньги, призванные сохранять и распространять знания, имеющие в конечном итоге своей целью повышение эффективности экономики…

 

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

 

Коллеги, если у вас есть свое мнение по этому поводу — выскажитесь на нашем форуме! Ведь дискуссия еще не окончена и доступ инженеров к ЕСКД  имеет существенные ограничения.

 

Она из наших целей — развитие отечественного инженерного дела, эффективное применение PDM, MCAD систем. Поэтому на нашем портале мы предоставляем бесплатный доступ к коллекции стандартов, составляющих ЕСКД.

 

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

ВНИМАНИЕ! ТЕСТ-ДРАЙВ!

 

На примере одинаковой детали, по общему чек-листу эксперты по каждой из MCAD систем покажут, как можно легко и быстро оформить КД в популярных MCAD в соответствии с ЕСКД. Об этом многое сказано, опровергнуто и пересказано на САПР форумах, но в живую, на одной площадке, в полностью сопоставимых условиях — этого еще никто не делал и не видел.

 

Это не сравнение, не битва, а скорее обмен опытом. Каждый автор искренне любит MCAD систему, которую он будет представлять.

 

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

Что предлагают 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 вендоров.

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

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

 

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

База рисков 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

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

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

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

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

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

 

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

Три независимых среды разработки — вызов актуален

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

 

Очевидно, что это несет в себе новые вызовы для промышленности: нужны конструктора новых специализаций, программисты, менеджеры со специфическим опытом и способностью находить общий язык как с конструкторами, так и с программистами. Новым инженерам нужны специализированные инструменты проектирования и разработки — системы проектирования электроники EDA (Electronic Design Automation), среды разработки ПО. Появляются новые поставщики компонентов, которые имеют другой уровень сложности и интеграции. Нужна новая конструкторская и производственная инженерная экспертиза. Единовременно перейти в новое качество невозможно, и в условиях недостатка опыта проектирование устройств новых поколений становится серьезным вызовом для предприятий, их менеджеров и инженеров.

s1_65843_75

При проектировании мехатронных изделий предприятия сталкиваются с тем, что фактически существуют три независимых среды разработки: MCAD (Mechanical Computer-Aided Design), EDA и отдельная от них среда разработки ПО. Все эти среды имеют собственную длительную историю развития и устоявшуюся идеологию. Эти идеологии не совпадают. В MCAD системах по большому счету все вращается вокруг дерева построения модели и состава изделия. В свою очередь, в EDA 3D модель объективно малополезна, зато важны обширные каталоги элементов, качественные алгоритмы компоновки и трассировки печатных плат, а результатом является по сути многомерная плоская модель печатной платы, имеющая большое количество ссылок и описывающая распределение и связи элементов из баз компонентов. В средах разработки ПО мы вообще сталкиваемся с продуктом не имеющем воплощения в физическом мире — с точки зрения инженера-конструктора программный код — это вообще чистая бесплотная абстракция, почти не привязанная к физическому миру.

 

Ситуация усугубляется тем, что у каждой системы существуют свои цели и задачи, свои форматы данных, а результаты работы не всегда могут быть сопряжены в одну модель изделия. Каждый развитый инструмент безусловно имеет также и соответствующую систему управления создаваемыми данными, например PDM (Product Data Management) и ALM (Application Lyfecycle Management) системы для механической и программной части изделия соответственно. При этом, для систем проектирования электроники EDA вообще почти не сформировалось определенного класса отдельных решений по управлению их информацией, а в силу идеологии EDA такой функционал начал развиваться внутри самих инструментов проектирования. Все перечисленные системы управления информацией этих инструментов тоже имеют колоссальные отличия, порожденные особенностями объекта управления (механическая конструкция, электроника, программный код) и сложившимися различиями в процессах управления данными — в софтверной компании и КБ бизнес-процессы обычно отличаются очень значительно.

Что предпринимает «большая тройка» PLM вендоров?

Ближе всего к объединяющей платформе на текущий момент находятся PDM системы основных отраслевых вендоров: Windchill компании PTC, Teamcenter компании Siemens PLM Software и Enovia разработки Dassault Systemes. Но все равно, говорить об этом можно только потому, что представить себе хранение, например, исходных кодов в PDM можно, а вот ведение состава изделия и его конфигураций в классической ALM системе — только в кошмарном сне. То есть мы просто имеем дело с меньшим из зол, которое пытаются использовать не по назначению, но творчески.

 

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

 

Что я имею в виду. Если мы рассмотрим решения компании PTC, то увидим, что ее решение Creo позволяет создавать 3D модели печатных плат на основе импортированных из EDA даных, а PDM система Windchill позволяет управлять не только «механическим» составом, но и микрокодом, а также импортировать в состав изделия данные из BOM (Bill os material) печатных плат различных EDA систем (продукты Creo View ECAD, Windchill ECAD Workgroup manager и др.). Да, это безусловно уже намного лучше, чем ничего.

 

У компании Dassault systemes похожая концепция и поддерживающие ее решения ENOVIA Collaborative Design for ECAD. Интеграция атрибутов, импорт BOM, данных библиотек и далее по списку, все уже было перечислено, не будем повторяться. Весь этот функционал, как и функционал решений решений, предлагаемых PTC и Siemens PLM Software безусловно полезен, но не является концептуальным прорывом в области сквозного проектирования мехатроники.

 

По сути речь идет только о «хранилище», в которое превращается PDM система. Да, в ней хранятся данные из EDA и среды разработки ПО, но эта система все равно чужеродна для конструкторов печатных плат и программистов, которые продолжают работать в своей основной среде и только по требованию руководства время от времени выгружают данные в PDM, в котором не видят для себя смысла.

 

5 системных проблем

Создание и внедрение специальных комплексных решений для мехатроники отягощают следующие системные проблемы:

 

1. Сложность интеграции справочников. Механические и электронные компоненты имеют существенные отличия в модели описания, и не всегда встроенные справочники PDM систем, ориентированные на крепеж, трубопроводную арматуру и прочие стандартные и покупные изделия, имеют функционал для корректного описания элемента, нужного EDA (например, координаты контактных площадок). Вторым тяжелым на практике вопросом является корректное получение информации EDA системами из этих справочников — необходимо сложное интеграционное решение на стороне EDA систем. Мало того, даже если PDM система может импортировать данные, как, например, Teamcenter gateway for ECAD part library позволяет импортировать в Teamcenter Classification библиотеки Orcad CIS, Altium, Mentor Expedition DXDatabook, то все равно остаются открытыми вопросы по распознаванию элементов на импортированной в MCAD топологии печатной плате и сопоставлению их со справочником, а также корректная передача изменений в EDA, если таковые будут иметь место. Наблюдая существующие решения создается впечатление, что все это полумеры, и есть существенный дефицит концептуального видения нового процесса проектирования и требований к новому (а не немного кастомизированному) инструменту. 
 
2. Сложность интеграции процессов. Многие бизнес-процессы, например, управление требованиями, или тот же процесс внесения изменений на стадии проектирования может затронуть все три слоя изделия — и механику, и электронику, и программное обеспечение. Но работы по оценке и реализации этого изменения будут вестись в разных средах, из-за чего могут возникать процессные, организационные коллизии и коллизии конструкционные.

 

3. Разный уровень зрелости процессов. Если многие R&D подразделения софтверных компаний в СНГ активно экспериментируют с Agile и Kanban подходами к управлению разработкой, внедряется большое количество новых подходов, таких как TDD (Test Driven Development), Continious Integration, и практик (рефакторинг, парная разработка), то отечественные КБ поглощены толкованием догматики ГОСТ, ЕСКД, ЕСТД, которые, конечно, не вредны сами по себе, но могут натворить бед, если превращаются в карго культ.

 

4. Отсутствие сквозной экспертизы. Кадровый голод в инжиниринге в России сейчас чувствуется особо остро. Не будет преувеличением сказать, что в стране мало (и становится все меньше) не только специалистов со сквозной экспертизой, понимающих процесс и все аспекты интеграции мехатронных изделий, но и просто хороших специалистов в каждой из этих трех областей.

 

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

 

В целом это на 80%-90% совпадает с проблематикой, которую получила в своем исследовании Aberdeen еще в 2006 году.

 

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

Напишите свое мнение на форуме!

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

Я приглашаю всех заинтересованных специалистов к созданию нового отраслевого процессного фреймворка. 
Пишите нам.

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

 

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

 

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