К вопросу о сравнении и выборе PLM/PDM-решений

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

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

Цели внедрения системы

Как показывает практика, проблемы возникают еще на этапе формулирования целей внедрения системы. Нередко цель декларируется без привязки к конкретным показателям, например «повышение эффективности работы предприятия за счет внедрения PLM­технологий». Также на данном этапе иногда происходит «жонглирование» терминами,  а впоследствии из­за терминологической путаницы происходит неверное формулирование требований к системе (типичный пример, когда к PLM/PDM­решению предъявляются требования по функционалу, относящемуся к системам САПР или технологической подготовке производства).

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

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

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

Также требуется максимально четко сформулировать перечень решаемых системой задач.

Формирование рабочей группы

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

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

Формулирование требований к системе

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

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

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

Такой сценарий может включать, например, следующие этапы:

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

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

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

Рассмотрим некоторые возможные требования к PLM/PDM­системам. Важно, чтобы каждое из них было максимально конкретным.

Архитектура и программная реализация системы

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

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

Любой отход от корпоративных стандартов, например на используемые СУБД, в дальнейшем приведет к дополнительным расходам на эксплуатацию системы. 

Пользовательский интерфейс

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

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

Должна быть реализована возможность настройки пользовательских сценариев ввода и обработки информации.

Интерфейс должен иметь возможность модификации без привлечения представителей разработчиков системы.

Требования к персоналу

Также еще на этапе разработки технических требований к системе необходимо спланировать потребности по численности и режиму работы группы внедрения и обслуживающего персонала (администраторов и операторов системы). В зависимости от выбранной стратегии, внедрение системы может осуществляться собственными силами (тогда необходимо уже на начальном этапе предусмотреть обучение сотрудников настройке системы), силами компании­интегратора или в комбинированном варианте. У каждого из вариантов есть свои плюсы и минусы: внедрение собственными силами обеспечивает больший контроль процесса и лучшее понимание настройки системы, но, как правило, требует большего времени и дополнительных расходов, связанных с содержанием собственного штата программистов; внедрение силами интегратора хотя и обойдется дороже на начальном этапе, но в дальнейшем даст существенную экономию за счет отсутствия необходимости оплачивать работу большого штата сотрудников на постоянной основе.

Этапность работ

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

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

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

Требования к структуре данных и схемам хранения информации

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

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

Необходимо исключить наличие всяческих ограничений на типы хранимых объектов и документов. Должна быть возможность создавать собственные типы информационных объектов (рис. 1) и атрибуты для них.

Рис. 1. Создание нового типа объекта в системе Lotsia PDM PLUS

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

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

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

Для изделий машиностроения система должна поддерживать работу с исполнениями по ЕСКД, а также с версиями и вариантами. Для документов также должна поддерживаться версионность. 

Справочники и классификаторы

PLM/PDM­решения должны иметь как встроенные средства ведения справочников и классификаторов, так и механизмы подключения к справочникам, хранящимся во внешних системах (с использованием прямых SQL­запросов, через XML, PLM XML и т.п.). При использовании справочников из внешних систем необходимо наличие возможности задания мастер­системы (первичного источника данных) для каждого справочника или классификатора.

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

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

Импорт унаследованных данных

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

При необходимости массового ввода в систему унаследованных документов с бумажных носителей должен быть предусмотрен интерфейс пакетного импорта со сканеров.

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

Помещение вновь создаваемых объектов в систему

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

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

Рис. 2. Импорт документа в архив в системе Lotsia PDM PLUS

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

Поиск информации

Система должна обеспечивать поиск информационных объектов (документов и изделий) различными способами. Например:

• по заданному шаблону с использованием различных фильтров по параметрам информационных объектов;
• по связям между информационными объектами;
• по месту хранения информационных объектов;
• по служебным характеристикам (дата создания, автор и др.);
• по маске (шаблону или нескольким символам) обозначения;
• по штрих­коду;
• через полнотекстовый поиск;
• по структуре модели изделия.

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

Рис. 3. Пример возможной реализации окна поиска в системе Lotsia PDM PLUS

Должны быть заданы ограничения на среднее время поиска информации.

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

На основании результатов поиска должна быть возможность формировать подборки по различным критериям.

Визуализация информации

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

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

Функции поддержки жизненного цикла продукции

Для PLM­решений необходим функционал по управлению информацией об изделии на протяжении всего жизненного цикла.

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

Для информационных объектов различных типов система должна позволять настраивать различные сценарии жизненного цикла.

Для реализации данного функционала необходимо обеспечить взаимодействие как с конструкторскими САПР и системами технологической подготовки производства, так и с системами календарного планирования и управления проектами, ERP, MES и др. Перечень и функциональные требования по интеграции с каждой из систем определяются индивидуально. 

Обмен данными

Функционал по обмену данными с внешними системами должен обеспечивать следующие возможности:

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

Обмен данными должен проводиться на основе утвержденных процедур прямого доступа к данным (например, через прямые SQL­запросы) и форматов файлов (ISO 10303 (STEP), XML, PLM XML и др.).

Должна быть предусмотрена возможность выгрузки комплекта документов по изделию или проекту в соответствии с выбранными критериями (рис. 4).

Рис. 4. Экспорт комплекта документов в системе Lotsia PDM PLUS

 Аналитика и отчетность

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

• генерировать различные отчеты по состоянию информационных объектов и системы (по загрузке исполнителей, задержке сроков выполнения работ и др.);
• осуществлять экспорт отчетов в стандартные форматы  и на бланки документов, подготовленных в стандартных офисных приложениях (например, MS Excel и MS Word);
• формировать спецификации и различные ведомости (материальная, весовая, ведомость покупных изделий, заимствованных деталей и т.д.);
• формировать списки рассылки копий документации и т.п.

Дополнительным плюсом будет поддержка так называемых живых (динамических) многоуровневых отчетов.

Для выполнения глубокого анализа данных должна быть предусмотрена возможность подключения внешних аналитических средств (OLAP и т.п.).

Сервисные возможности

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

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

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

Администрирование

Система должна включать необходимый набор средств администрирования, в том числе:

• средства интеграции с ресурсами сетевой операционной системы (например, с MS Active Directory);
• средства создания и настройки типов информационных объектов, их атрибутов и связей между ними;
• средства описания бизнес­логики;
• средства конфигурирования;
• средства описания и настройки бизнес­процессов и маршрутизации документов;
• средства создания экранных форм (информационных объектов, поисковых запросов, диалогов подсистемы документооборота) и меню для различных групп пользователей;
• средства аудита;
• встроенный макроязык.

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

Сравнение систем

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

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

Рис. 5. Пример изменения шаблона Workflow в системе Lotsia PDM PLUS

Информация компаний­разработчиков

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

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

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

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

Информация из Интернета

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

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

Обучение на специализированных курсах

Если бюджет и ресурсы проекта позволяют, то перед окончательным выбором системы можно обучить нескольких сотрудников ее настройке и сопровождению на специализированных учебных курсах. Хотя подобные краткосрочные курсы, как правило, не позволяют в полном объеме изучить функционал современных систем, однако получить представление об их возможностях можно.

Конкурсные процедуры

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

САПР и графика 3`2013