4 - 2008

Российский опыт использования решений PLM/PDM

Николай Ширяев

Нужны ли PLM-решения?

Типичные задачи, решаемые на предприятиях с помощью систем PLM/PDM

Типичные ошибки, при внедрении PLM/PDM-систем

Техническая поддержка и развитие функционала решения

В настоящей статье рассматриваются некоторые аспекты внедрения PLM/PDM-решений в отечественных условиях и наиболее типичные проблемы, возникающие при их реализации.
Решения PLM/PDM (Product Lifecycle Management — управление жизненным циклом продукции, Product Data Management — управление данными о продукции) в данное время активно внедряются практически во всех отраслях (например, решения на базе Lotsia PLM (Lotsia PDM PLUS и Lotsia ERP) по состоянию на январь 2008 года используются в 27 отраслях).
Общий обзор состояния российского рынка PLM-решений был сделан в статье «PLM/PDM/ERP: реалии и перспективы» (см. журнал «САПР и графика» № 12’2007). Данная публикация посвящена некоторым практическим аспектам, связанным со спецификой внедрения PLM/PDM-решений в отечественных условиях.

Нужны ли PLM-решения?

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

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

Если полагать, что за аббревиатурой PLM скрывается некая панацея, что зачастую утверждают некоторые коммерческие представители ком­паний-продавцов, то, наверное, действительно «оно нам не нужно».

Рис. 1. Результаты опроса на тему «На каком количестве рабочих мест вы планируете использовать систему PLM?»

Рис. 1. Результаты опроса на тему «На каком количестве рабочих мест вы планируете использовать систему PLM?»

 

Рис. 2. Объемы первично приобретаемых лицензий на решения PLM/PDM

Рис. 2. Объемы первично приобретаемых лицензий на решения PLM/PDM

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

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

При этом потенциальные пользователи проявляют серьезный интерес к PLM-решениям.

Как видно из рис. 1, наибольший процент (35%1) опрошенных потенциальных пользователей планируют использовать PLM-решения не менее чем на 100-300 рабочих мест.

Казалось бы, приведенная диаграмма дает поставщикам PLM-решений все основания для оптимизма. Хотя, как можно видеть, доля предполагаемых крупных внедрений (более 500 рабочих мест) составляет не более 10%; а на 6% предприятий вообще не планируется использование каких-либо PLM-решений. Но это только планы.

Практика же реальных внедрений все же предоставляет несколько иные данные (рис.  2).

Как видно из диаграммы, почти половина организаций при первичном приобретении лицензий на решения PLM/PDM ограничивается менее чем 50 лицензиями, а доля компаний, приобретающих от 100 до 300 лицензий, составляет менее 15%. Правда, в дальнейшем в течение полутора-двух лет каждая вторая компания приобретает дополнительные лицензии.

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

В начало В начало

Типичные задачи, решаемые на предприятиях с помощью систем PLM/PDM

К сожалению, как показывает опыт внедрения решений PLM/PDM, довольно большой процент предприятий не использует в полной мере возможности, которыми располагают внедряемые системы.

Более того, на многих производствах решения PDM/PLM используются не более чем в качестве электронного архива технической документации, что, мягко говоря, является не лучшим способом их применения, то есть стрельбой из пушки по воробьям.

Управление структурой изделия используется примерно на 70% предприятий (при этом, например, возможности по управлению конфигурациями тоже применяются не на всех предприятиях — чаще всего проводится обычная привязка документов к дереву состава изделия).

По отзывам пользователей, не более чем на 50% предприятий, внедряющих PLM-решения, в полной мере используются возможности Workflow для управления бизнес-процессами. Чаще всего эти средства применяются в режиме свободного обмена сообщениями (по аналогии с программами электронной почты) или, что гораздо реже, не более чем для автоматизации процессов утверждения документов. Недооценка значимости возможностей Workflow для управления бизнес-процессами предприятия в настоящее время очевидна и крайне прискорбна.

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

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

В начало В начало

Типичные ошибки, при внедрении PLM/PDM-систем

Какие типичные ошибки совершаются отечественными предприятиями, планирующими внедрение систем PLM/PDM?

Отсутствие четкого понимания, что такое PLM

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

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

По моему мнению, форумы можно использовать только в дополнение к уже существующей достоверной информации для уточнения конкретных деталей (желательно, с перекрестной проверкой).

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

Пренебрежение техническим заданием

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

Поймите, никто не составит техническое задание (ТЗ) за вас и для вас. В лучшем случае, вы получите ТЗ, написанное под конкретную систему (если вы попросили подготовить его поставщика этой системы), в худшем случае — просто некий околотехнический текст. Но с очень большой долей вероятности в любом из перечисленных случаев в данном документе не будут учтены ваши реальные требования к системе и, как следствие, при внедрении решения по такому ТЗ добиться положительного результата будет очень трудно. Не забывайте, что по ГОСТ’у техническое задание должно составляться совместно заказчиком и исполнителем. И пренебрежение заказчиком этой частью работы почти наверняка приведет к краху проекта.

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

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

Проблемы интеграции с приложениями

Зачастую при выборе PLM-решения очень большое внимание (и совершено обоснованно) уделяется интеграции с САПР. Но в ряде случаев при этом делаются следующие ложные допущения:

САПР будет использоваться только одна (в реальности в нашей стране доля предприятий, где используется только одна САПР, составляет менее 5% — вообще же ориентация на выбор решения от одного производителя действительно в ряде случаев оправданна, но в реализации довольно сложна);

помимо САПР интегрировать PLM/PDM-систему больше ни с какими приложениями не нужно (что также не соответствует действительности, поскольку любой проект порождает, к примеру, массу текстовых документов);

в базу данных PLM должны быть занесены все возможные данные из справочников, используемых в САПР (пусть даже в реальности они никогда не будут применяться).

Начиная с этапа составления ТЗ мы должны планировать, с какими именно системами и в каком объеме нам потребуется организовать интеграцию и какие именно данные должны попасть в единые справочники.

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

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

Отсутствие типовых настроек для предметной области

Следствием неверного выбора системы может стать отсутствие в ней типовых настроек для предметной области (например, при попытке использовать систему, разработанную для машиностроения в проектных организациях архитектурно-строительного профиля). Данная проблема довольно характерна для случаев, когда выбор решения базировался не на проработанном ТЗ, а на каких-либо иных факторах. Попытка внедрить систему, изначально не предназначенную для данной предметной области, может существенно повысить стоимость и растянуть сроки внедрения; либо также может привести к полному провалу проекта внедрения.

Неприменение средств полнотекстового поиска

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

Digital Mock-Up и отечественные САПР

Очередная проблема, с которой сталкиваются российские предприятия при внедрении PLM-решений, — отсутствие поддерж­ки средствами цифрового моделирования сборки форматов отечественных САПР. То есть вы не можете просмотреть, как будут выглядеть в рамках единой сборки 3D-модели деталей, разработанных в отечественных и зарубежных САПР. Избежать этого можно только жесткой стандартизацией используемого программного обеспечения или разработкой собственных средств визуализации.

Чрезмерное увлечение программированием

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

Недостаточная квалификация персонала и отсутствие обученных пользователей

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

В начало В начало

Техническая поддержка и развитие функционала решения

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

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

Рис. 3. Результаты опроса на тему «Что для вас важнее в технической поддержке системы PLM?»

Рис. 3. Результаты опроса на тему «Что для вас важнее в технической поддержке системы PLM?»

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

***

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

Но, как показывает опыт более 500 внедрений решений PLM/PDM специалистами компании «Лоция Софт» в нашей стране, локализация даже рассмотренных выше проблем может существенно повысить шансы на успешную реализацию подобных проектов.


1Приведенные здесь и далее цифры основаны на материалах из открытых источников и опросах пользователей различных PLM/PDM-решений, проводившихся компанией «Лоция Софт» в 2007 году.

В начало В начало

САПР и графика 4`2008