Публикации

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

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

Очевидно, что все эти мероприятия так или иначе затрагивают основные функциональные направления в типовой среде управления жизненным циклом (PLM), и при их реализации неизбежно возникают вопросы и задачи, связанные с верификацией данных и объектов. Так, в рамках календарного планирования необходимо понимать, как контролировать факт того, что весь объем конструкторской документации по текущему проекту сдан в обозначенные сроки. При управлении требованиями придется определять, как проводить их верификацию для обоснования проектных решений. Кроме того, понадобится обеспечить соответствие версий 3D-моделей и чертежей AutoCAD, а в части управления расчетными данными – конструкторских данных и версий аналитических расчетов. Наконец, необходимо верифицировать и управление конфигурацией, то есть понять, выйдет ли проект за рамки бюджета по стоимости и по срокам при проведении изменений, а также выявить всю цепочку компонентов структуры, которые будут затронуты изменениями.
Конечно, это далеко не полный набор необходимых задач верификации, и понятно, что корректно их осуществить в полном объеме можно лишь с использованием механизмов согласования данных и информационных потоков в автоматизированном режиме. Между тем именно такие механизмы автоматизированной верификации реализованы в разработанной LM Soft платформе управления полным жизненным циклом. И в данной статье мы постараемся показать, как детальная верификация сведений о фактическом исполнении работ на каждом этапе жизненного цикла, а также возможности PLM-платформы LM Soft в части управления требованиями позволяют полностью автоматизировать функции контроля над изменениями и соблюдением целевых критериев эффективности программы производства.

 Календарное планирование

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

Взглянем детальнее на процесс планирования в системе LM Soft. Сформировав расписание с вложенным списком задач, ответственный сотрудник имеет возможность назначить исполнителя задачи, выбрав его из списка зарегистрированных в системе пользователей в корреляции с графиком загрузки ресурсов. А вот дальше каждая задача в модуле планирования автоматически связывается через ссылку с конкретным, например, заранее созданным, объектом в системе. Иными словами, уже на этапе планирования обозначается результат выполнения задачи, который связан с физически созданным в системе объектом, даже если еще не определена сущность этого объекта и сам он де-факто не имеет своего воплощения нигде, кроме как в ИС.
В качестве реализации такого сценария можно обеспечить со стартом каждой задачи календарного плана запуск соответствующего ей рабочего процесса. При этом в модуле управления рабочими процессами можно задать условия завершения крайнего этапа процесса только в том случае, если приложенный объект (результат выполнения задачи) имеет, например, статус «Согласовано». Иными словами, работа будет считаться завершенной только при наличии гарантированного ожидаемого результата, согласованного с «заказчиком» этой работы. Кроме того, в качестве объекта согласования можно указать и комплект конструкторской документации, а в качестве справочных данных – перечень требований к комплекту и согласовывать комплект лишь при полном соответствии приложенным требованиям.
Таким образом, имея комплекс инструментов в составе модуля управления проектами, рабочими процессами и требованиями в составе единой среды, можно обеспечить контроль целевых событий, таких как комплектность разработанной конструкторской документации. Применяя инструментарий по описанному сценарию, предприятие может получить в свой ИТ-ландшафт комбайн, обеспечивающий верификацию требований. Ведь это действительно важно – иметь картину взаимосвязанных задач календарного плана, которые автоматизированно управляются через рабочие процессы с показателем степени завершенности в процентах. А они, в свою очередь, собирают воедино с целью управления процессом, к примеру, проведения изменений, такие объекты, как требования и проектные решения. Через трассировочные связи эти разнородные объекты образуют нейросеть проекта, которая позволяет в любой момент времени понять статус работ по любому объекту.

Управление требованиями

Сегодня на рынке есть решения по управлению требованиями под любой запрос предприятия – по крайней мере, на уровне рекламных заявлений. Но так ли это? Действительно ли под любой запрос? Реально ли вендоры задумывались о потребностях пользователей инженерного контура? Или это притянутые к желаемому решения, которые изначально были «заточены» под задачи управления требованиями при разработке программного обеспечения?
Анализ показывает, что, к сожалению, ситуация именно такова. Те, кто пытался адаптировать систему управления требованиями, созданную для нужд разработчиков ПО, под потребности инженеров-конструкторов или технологов, да еще таким образом, чтобы она гармонично встроилась в процессы какого-нибудь конструкторского бюро, однозначно подтвердят, что занятие это неблагодарное. Ведь задача по управлению требованиями при проектировании сложного технического изделия машиностроительного толка все равно при этом остается незакрытой.
Между тем в рамках PLM-решения LM Soft становится возможным обеспечить автоматизацию процессов управления требованиями в инженерном контуре. Для этого мы предлагаем для начала погрузить процесс проектирования изделия в единую среду на всем протяжении ЖЦ. Таким образом, именно PLM-система начинает обеспечивать единое информационное пространство в масштабе всего предприятия. И в этих условиях, имея PLM-среду как основу для цифровизации разнородных процессов и привнесения в нее любых информационных объектов, уже не представляет труда сделать эти объекты и процессы управляемыми.
В такой среде можно легко настроить трассировку между всеми необходимыми объектами в составе комплексного цифрового макета, реализовать возможность обмена информацией между доменами знаний в процессе управления конфигурацией и обеспечить заинтересованных лиц в любой момент времени легитимной актуальной информацией. В целом в своем решении мы сделали акценты на таких важных моментах, как:
·         интеграция со средой управления процессами разработки и проектирования;
·         управление жизненным циклом требований;
·         трассировка требований как между собой, так и с проектными решениями;
·         генерация выходных документов с сохранением структуры требований;
·         механизм обеспечения верификации данных;
·         интеграция с внутренними модулями и сторонними приложения.
Все это выгодно отличает комплексные интегрированные решения от одного вендора от разрозненного ПО. А требования и управление ими играют здесь одну из ключевых ролей.
Так уж выходит по логике вещей и на основании проектного опыта, что такой домен знаний, как управление требованиями, является средством и основой проведения верификации. Но в чем суть верификации? Верификацией называют проверку на соответствие предъявляемым требованиям. Но средства и методы проверки могут быть как автоматизированные, так и чисто ручные, силами ответственного специалиста.
В принципе ничего плохого в ручной проверке нет, ведь важно обеспечить их соблюдение по указанным в требованиях параметрах, обосновав эти параметры методологически с опорой на необходимые положения и стандарты и связав их с конкретными объектами требований. И вот тут ручной труд зачастую может быть эффективен только отчасти. Попробуйте удобно расположить в физическом мире требование из многолистового технического задания, проектное решение к нему в виде десятка листов текстового описания, кипу стандартов и положений, на которые опираются проектные решения, а еще ватман формата А0 с распечатанным календарно-сетевым графиком, где указана загрузка инженера, разработавшего проектное решение и многое другое.
Между тем в цифровой среде, по сути, реализуются те же действия, но при этом через ссылки и трассировочные связи видна вся картина взаимосвязей интересующего объекта. И все это – в рамках одной среды, включая и контент самих стандартов! Опираясь на требования и используя функциональность трассировки объектов между собой, инженер получает совершенный инструмент проектирования и верификации проектных решений. В едином комплексе в строгом соответствии с требованиями формируется цифровой макет изделия: конструкторские и расчетные данные, планы и задачи при управлении проектом, НСИ, данные сторонних CAD-систем и прочая необходимая информация. Именно поэтому так важно в корпоративной информационной системе обеспечивать комплексность, реализуя в рамках единой среды любой необходимый набор функций, и оперировать одними и теми же информационными объектами.

Посмотрим на характерную картину взаимодействия различных областей управления технологическими и организационными процессами предприятия при создании нового продукта. В этой схеме обеспечивается формирование данных в части конструкторской подготовки в составе 3D-моделей, электрических схем и, при необходимости, программного обеспечения.
На стадии подготовки производства в службу закупок передается состав изделия, формируется перечень покупных изделий и материалов, необходимых для производства и сборки, подготавливаются диаграммы P&ID и изометрические схемы.
На этапе производства создается информационная модель тестового образца и отлаженный опытный образец в виде информационной модели «как построено», и уж совсем продвинутые озадачиваются формированием эксплуатационного состава. При проведении же изменений, как правило, начинаются сложности, потеря бюджета и срыв сроков.
А что будет, если добавить в эту картину составляющую, которая обеспечивает управление требованиями и функционально-логическое моделирование? Тогда появляется четкая картина, показывающая, что требуется от изделия. В следующей фазе система однозначно прописывает, для чего изделие предназначено (т. е. определяет функции) и как именно эти функции должны быть реализованы (т. е. задает логику). Затем осуществляется трассировка, и формируется стройная картина анализа, какие именно объекты будут затронуты изменениями в случае таковых. В результате для руководителя создается аналитическая панель, насыщенная настраиваемыми данными, которые позволят принять обоснованное и информационно поддержанное управленческое решение. Это ли не заслуживающее внимания решение, которое позволяет сэкономить бюджет проекта и остаться в графике?
Имея настолько всеобъемлющую картину на основе взаимосвязанных данных, далее уже можно говорить и о такой дисциплине, как управление конфигурацией. Без сомнения, это другой уровень зрелости предприятия, но разве не стоит стремиться его достичь, если таким образом можно повысить степень прозрачности и управляемости процессов?
В свою очередь, домен знаний, посвященный управлению конфигурацией, является настолько всеобъемлющим, что заслуживает отдельного рассмотрения как в отношении подхода, предлагаемого компанией LM Soft в этой области, так и в отношении информационно-программной поддержки процессов управления конфигурацией.