В настоящее время рынок PLM систем наполнен продуктами как отечественных, так и зарубежных разработчиков. Время, когда системы разных поставщиков существенно отличались по функционалу, прошло.
Выбрав ту или иную предметную область, можно обнаружить несколько систем, обладающих схожими функциональными возможностями.
Ценовые аспекты (стоимость конечных лицензий и стоимость внедрения) несомненно важны, но не могут являться определяющими. Срок службы качественно внедренной и надлежащим образом поддерживаемой PLM системы исчисляется десятилетиями. В этом случае, в негативном аспекте -цена ошибки (в случае неудачного внедрения, некачественной поддержки и обслуживания системы), а в позитивном аспекте - объем сокращенных трудовых издержек за счет правильно внедренной системы многократно превысит первоначальные вложения средств на приобретение лицензий и оплату проекта внедрения.
Принимая во внимание вышесказанное, на что следует обращать внимание при выборе той или иной системы? Анализируя опыт компаний – поставщиков услуг по поставке и внедрению PLM – систем можно выделить следующее:
1. Возможность реализации существующей прикладной бизнес-логики Заказчика (применимо к производственным предприятиям, фактически это реализация отраслевой и предметной специфики производства), а также аспект возможности реализации изменений/развития в бизнес-логике во временном промежутке не менее 8-10 лет после внедрения Системы:
- Очевидно, здесь может помочь изучение релевантного опыта внедрений PLM-системы на предприятиях идентичной или похожей отраслевой специфики.
- Изучение следует производить, опираясь скорее на опыт ИТ специалистов Заказчика (техподдержка, администрирование, расширение функциональности Системы), чем на опыт конечных пользователей (хотя, и он не будет лишним). Следует привлечь и собственных ИТ специалистов.
- Наличие базовой («коробочной») версии PLM-системы с объемом функциональности, учитывающей специфику прикладной области, в которой вы работаете. К примеру, если ваша отрасль машиностроение/приборостроение, то в системе, как минимум должны быть информационные сущности по ГОСТ серий 2.05 (электронные документы/изделия), и настроены процессы инженерного документооборота по ГОСТ серии 2.5 (Правила внесения изменений, архив). Коробочная версия никогда не удовлетворит ваши потребности на 100%, однако, это показатель того, что разработчик разбирается в вашей предметной области и потратил свое время и деньги на реализацию платформы для внедрения.
- Наличие сервисов интеграции
2. Возможности конфигурирования PLM-системы под требования Заказчика. Здесь важны такие аспекты как временные затраты (читай – стоимость) конфигурирования и возможность конфигурирования системы силами Заказчика. Базовые возможности, к которые должны предоставлять сервисы конфигурирования любой PLM-системы:
- Внесение изменений в бизнес-логику информационных объектов PLM-системы без остановки основных сервисов и/или перевода системы в режим монопольного доступа.
- Создание новых информационных объектов (сущностей) с реализацией графа наследования, интерфейсов и ассоциативных связей с другими сущностями системы.
- Возможность программирования бизнес-логики пользовательских информационных объектов и бизнес-процессов с использованием прикладных языков программирования высокого уровня (желательно группы .Net).
- Возможность внесения изменений в сконфигурированные бизнес-процессы.
- Возможность связать изменение состояния (жизненного цикла) любого информационного объекта Системы с изменением активного этапа экземпляра запущенного бизнес-процесса, в том числе средствами программирования информационного объекта и/или бизнес-процесса.
- Создание новых вариантов бизнес-процессов.
- Конфигурирование отчетов.
- Возможность разнесения прикладной бизнес-логики Заказчика и внутренней (системной) логики PLM_системы, а также возможность выгрузки прикладной логики во внешнюю информационную сущность (конфигурационный файл, база данных и т.п.).
3. Возможности по интегрированию сервисов PLM-системы в прикладное программное обеспечение (ППО) Заказчика.
- Теоретически идеальным вариантом здесь был бы вариант, когда разработчик PLM-системы выпускает бесплатный SDK, позволяющий реализовать функционал модуля интеграции PLM-системы в ППО силами сторонних разработчиков. Фактическая ситуация на рынке PLM-систем на данный момент практически не допускает подобного развития событий. Хотя в некоторых случаях, разработчик имеет выделенный SDK для разработки внешних модулей интеграции, но в этих случаях он закрыт от свободного доступа разработчиков, и максимум – доступен для авторизованных партнеров/дилеров разработчика.
- Тем не менее, изучая релевантный опыт внедрения, следует обратить пристальное внимание на аспект реализации требований Заказчика по интегрированию сервисов PLM - системы в ППО Заказчика (особо следует обратить внимание на системы класса САПР). Сколько это заняло времени, как минимум.
- Наличие «коробочных» версий модулей интеграции сервисов PLM-системы в ППО. От модуля интеграции, как правило не требуется излишней функциональности, но в базе должны быть представлены минимальные функциональные возможности по (процедуры открытия и сохранения электронных документов, внесения изменений, создания новых версий документов, работа с электронной структурой изделия).
4. Возможности по обмену данными со смежными ИС. Рано или поздно (а скорее всего в процессе внедрения системы) вам придется столкнуться с необходимостью обмениваться данными со сторонними приложениями. К примеру, возникнет необходимость связать привязать процесс разработки изделия с реальными позициями доступных к применению комплектующих на складе, автоматизировать процесс расчета себестоимости изделия и т.п.
- Реализовать эту задачу может представитель разработчика на этапе внедрения, это наиболее распространённый вариант решения.
- При этом следует понимать, что как правило, реализация интерфейса обмена данными не захватывает внутренний SDK/ядро системы и вполне по силам внешним разработчикам. Если это не так, следует задуматься о целесообразности приобретения подобной PLM-системы, так как фактически, при добавлении новой смежной системы в ваш ИТ-ландшафт, вам придется привлекать специалистов разработчика к решению любой прикладной задачи, связанной с обменом данными.
- Таким образом, даже если вы планируете закрыть задачи реализации интерфейсов обмена силами разработчика (организации, проводящей внедрение), следует обратить достаточно внимания на аспект фактической реализации интерфейсов обмена.
- Важно, чтобы интерфейс обмена базировался на распространенных транспортных протоколах, в 90% случаев это будут протоколы прикладного уровня стека TCP/IP (HTTP/HTTPS, SOCKS).
- Конечная реализация интерфейса обмена данными в большинстве случаев будет означать, что поверх транспортного протокола будет работать протокол сериализации/доступа к объектам. Вы не прогадаете, если интерфейс будет поддерживать распространенные протоколы XML, HTTP, JSON, SOAP.
5. Возможности по масштабируемости PLM-системы:
- Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.
- Горизонтальное масштабирование — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам), и (или) увеличение количества серверов, параллельно выполняющих одну и ту же функцию. Масштабируемость в этом контексте означает возможность добавлять к системе новые узлы, серверы, процессоры для увеличения общей производительности. Этот способ масштабирования может требовать внесения изменений в программы, чтобы программы могли в полной мере пользоваться возросшим количеством ресурсов.
6. Возможности по миграции компонентов системы на другие программно-аппаратные ресурсы:
- Смена версии/редакции СУБД.
- Смена версии/редакции ОС на серверах PLM-системы.
- Изменение пропускной способности сети, в частности возможность работы на узких каналах связи.
7. Доступность и качество сервиса технической поддержки Поставщика.
8. Наличие в штате Поставщика специалистов по конфигурированию PLM-системы.
9. Готовность ИТ специалистов Заказчика к выполнению функциональных обязанностей по техподдержке, администрированию и расширению функциональности PLM-системы.
10. Стоимость подготовки внутренних специалистов Заказчика по конфигурированию PLM-системы.
11. Позиция и степень надежности Поставщика на рынке поставщиков решений данного класса.
Если нужна помощь во внедрении PLM -системы: https://constructor.ru/services/4112/
#PLM #it-технологии #нтц_конструктор #plm_система