Корзина
Ваша корзина пуста
Выходные и праздничные дни с 12:00 до 20:00
Офис в Санкт-Петербурге
с 9:00 до 19:00
Офис в Москве
с 9:00 до 19:00
Продажа и внедрение программного обеспечения для проектирования, обучение. САПР, ГИС PDM и PLM-решения

Союз PLM

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

Памятка к выбору PLM-системы с позиции ИТ-специалиста

В настоящее время рынок 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.    Возможности по миграции компонентов системы на другие программно-аппаратные ресурсы:
  1. Смена версии/редакции СУБД.
  2. Смена версии/редакции ОС на серверах PLM-системы.
  3. Изменение пропускной способности сети, в частности возможность работы на узких каналах связи.
7.    Доступность и качество сервиса технической поддержки Поставщика.

8.    Наличие в штате Поставщика специалистов по конфигурированию PLM-системы.

9.    Готовность ИТ специалистов Заказчика к выполнению функциональных обязанностей по техподдержке, администрированию и расширению функциональности PLM-системы.

10.    Стоимость подготовки внутренних специалистов Заказчика по конфигурированию PLM-системы.

11.    Позиция и степень надежности Поставщика на рынке поставщиков решений данного класса.


Эволюция модели данных по мере развития предприятия

В "Союз-PLM" преодолено принципиальное ограничение PLM-систем предыдущего поколения – предопределённость прикладной модели данных. Теперь возможно на ходу, без остановки системы развивать модель данных, добавляя атрибуты информационных объектов и правила их обработки и отображения, не дожидаясь выпуска очередной новой версии продукта и не испытывая ограничения текущей версии.

Работа в географически распределённой среде

Благодаря системе упреждающего кэширования "Союз-PLM" расходует минимум сетевого трафика для своей работы, что даёт превосходные показатели при работе в географически распределённой среде. Например, работа с САПР под управлением "Союз-PLM" будет комфортной даже вне предприятия (аэропорт, Интернет-кафе, "на дому").

Разграничение и управление доступом

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

Доступность информации для повседневной работы и принятия оперативных решений

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

Коллективная работа в САПР

Современные системы моделирования, например, такие как Autodesk "Inventor" или система оформления 2D-документации "AutoCAD Mechanical", используемые под управлением единой информационной системы "Союз-PLM", приобретают новое качество - становятся мощной системой проектирования. В сочетании с PLM резко возрастает эффективность применения САПР за счёт добавления к САПР возможностей по хранению версий, проработки альтернативных вариантов, механизмов многопользовательской работы над общей моделью сборки, функциональности по обмену информацией между сотрудниками в реальном времени, автоматического ведения состава изделия и управления доступом на основе иерархии сборочной единицы.

Интеграция с внешними приложениями

Как правило, требуется передача данных в системы управления предприятием (ERP) и бухгалтерские системы (1С). В зависимости от конкретных задач применяется передача данных напрямую между СУБД, управляемая событиями на сервере приложений "Союз-PLM". Также широко используется возможность встраивания пользовательских команд в интерфейс клиентского приложения Союз-PLM. Например, можно выполнить экспорт структуры изделия в XML и передать его в систему технологической подготовки производства. Или, наоборот, из PLM обратиться к внешнему справочнику покупных изделий и т.д. Открытая архитектура обеспечивает возможность наращивания функциональности системы силами специалистов предприятия без привлечения разработчика.

Оформление текстовой технической документации по PLM-данным

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

Управление процессами и регламентированными процедурами

Для управления процессами используется подсистема Workflow. В базовую поставку "Союз-PLM" включён набор типовых шаблонов-процессов для организации активно используемых процедур согласования и утверждения документов, подготовки предварительных изменений, согласования утверждения и проведения изменений. Подсистема Workflow работает с учётом видов документов, штатного расписания сотрудников предприятия и их ролей в проектах.
Имя Телефон E-Mail Комментарии