Организация согласованного взаимодействия в конструкторско-технологической подготовке производства за счет информационной интеграции бизнес-процессов

Моделирование бизнес-процессов и данных на этапе проектирования информационных систем играет ключевую роль в машиностроении. Методология IDEF0 широко применяется для функционального моделирования конструкторско-технологической подготовки производства, наглядно отображая функции системы, потоки информации и материалы, преобразуемые этими функциями. Однако для разработки самой информационной системы и интеграции с системами управления инженерными данными (PDM/PLM) необходима табличная модель – формализованный перечень данных (сущностей, документов и процессов), подлежащих реализации в базе данных предприятия. Стандарт IDEF предусматривает связку методологий: после построения функциональной модели IDEF0 следует информационное моделирование данных (IDEF1X) для детализации входов/выходов функций. В современных стандартах моделирования зафиксирована необходимость согласования функционального и информационного представлений системы. Например, ГОСТ Р ИСО 19439–2008 (ISO 19439) определяет набор представлений модели предприятия, где функциональное (процессы) дополняется информационным (данные). Таким образом, возникает задача преобразования результатов IDEF0 в табличные модели данных, которые лягут в основу структуры базы данных предприятия.

Для достижения поставленной цели решаются следующие задачи: (1) разработка базы данных конструктора и базы данных технолога, отражающих информационные потребности конструкторских и технологических подразделений; (2) проектирование интерфейса обмена данными между этими двумя частями информационной системы (ИС) и интеграции с внешней PDM/PLM-системой; (3) разработка модели разграничения доступа на основе ролей и компетенций (RBAC+Skills), включая матрицу компетенций исполнителей; (4) описание варианта использования (use-case) для администрирования бизнес-процессов; (5) определение спецификаций интерфейсов (форматы обмена данными – XML/JSON, схемы, правила трансформации); (6) разработка алгоритмов автоматизированного назначения задач исполнителям и оценки сроков/стоимости выполнения с учетом грейда (квалификационного разряда) сотрудника и сложности соответствующей сущности/задачи.

ходимо обеспечить связь между табличной моделью и системой управления рабочими процессами (workflow) с разграничением доступа на основе ролей (RBAC), учетом маршрутов выполнения, лимитов времени и квалификационных уровней персонала. Предполагается, что реализация модели будет интегрирована в современную PDM/PLM-среду (например, Siemens Teamcenter, SmarTeam), поддерживающую единое информационное пространство предприятия.

ПОСТАНОВКА ЗАДАЧИ

Для достижения поставленной цели решаются следующие задачи: (1) разработка базы данных конструктора и базы данных технолога, отражающих информационные потребности конструкторских и технологических подразделений; (2) проектирование интерфейса обмена данными между этими двумя частями ИС и интеграции с внешней PDM/PLM-системой; (3) разработка модели разграничения доступа на основе ролей и компетенций (RBAC+Skills), включая матрицу компетенций исполнителей; (4) описание варианта использования (use-case) для администрирования бизнес-процессов; (5) определение спецификаций интерфейсов (форматы обмена данными – XML/JSON, схемы, правила трансформации); (6) разработка алгоритмов автоматизированного назначения задач исполнителям и оценки сроков/стоимости выполнения с учетом грейда (квалификационного разряда) сотрудника и сложности соответствующей сущности/задачи.

В рамках работы под базой данных (БД) конструктора понимается фрагмент корпоративной БД или подсистема, ответственная за управление конструкторскими данными: структурой изделия, электронными чертежами и 3D-моделями, нормативно-справочной информацией и пр. База данных технолога – аналогичная подсистема для технологических данных: технологических процессов, маршрутных карт, операций, оснастки и т.д. Каждая из этих подсистем может иметь собственную модель данных, но для сквозной цифровой цепочки необходимо обеспечить синхронизацию между ними. Интерфейс перехода/обмена должен поддерживать передачу данных об изделии от конструкторов к технологам и обратную связь при изменениях.

Особое внимание уделяется администрированию бизнес-процессов (БП): система должна позволять конфигурировать маршруты выполнения работ, назначать ответственных, ограничивать время выполнения этапов, контролировать продвижение задач. Администрирование предполагает наличие ролей (должностей) пользователей, распределение прав доступа, настройку типовых процессов и автоматизацию ряда функций. В модель должны быть включены механизмы поддержки ролевого доступа (RBAC) с учетом компетенций: каждый пользователь обладает определенной квалификацией и навыками, которые соотносятся с требованиями задач. Это позволит автоматически распределять задания между исполнителями, максимально учитывая их опыт и уровень подготовки.

Таким образом, задача сводится к разработке целостной архитектуры ИС КТПП, которая:

• .    Формализует функциональную модель (IDEF0) в виде списков данных сущностей предметной области (СПО), документов предметной области (ДПО) и БП посредством программных скриптов.

• .    Структурирует базы данных для конструкторской и технологической подготовки, обеспечивая совместимость с PDM/PLM.

• .    Реализует взаимодействие между конструкторскими и технологическими данными через стандартизованные интерфейсы обмена (XML/JSON) с соблюдением требований международных стандартов (ISO 10303 (STEP), CALS) и отечественных (ГОСТ, ЕСКД).

• .    Поддерживает управление процессами (workflow) с помощью RBAC-модели, включающей роли, права, маршруты согласований, временные ограничения, и матрицу компетенций персонала.

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

МЕТОДИКА ПРЕОБРАЗОВАНИЯ IDEF0-МОДЕЛЕЙ В ТАБЛИЧНЫЕ ДАННЫЕ

Первым этапом реализации является преобразование функциональной модели IDEF0 КТПП в перечень ключевых сущностей и документов – основу будущей модели данных [1]. Существуют разные подходы к такой трансформации. Традиционный метод подразумевает ручной анализ: эксперты, разработав диаграммы IDEF0, идентифицируют в потоках входов/выходов все материальные и информационные объекты, которые рассматриваются как кандидаты в ДПО. Далее путем обобщения выделяются СПО – категории объектов, для которых будут созданы записи в базе данных. Например, если на диаграммах фигурируют объекты «Спецификация требований» и «Спецификация конструкции», эксперт вручную вводит обобщающую сущность «Спецификация» [2]. Этот метод не требует сложных инструментов и фактически был основой многих проектов внедрения ИС в 1990-х годах (связка BPwin + ERwin и т.п.). Его недостатки – трудоемкость, зависимость от квалификации аналитиков, отсутствие формальной воспроизводимости.

Более продвинутые подходы опираются на интегрированные CASE-средства (например, ARIS), где функциональные модели и модели данных хранятся в едином репозитории и взаимно связаны. При таком подходе один и тот же объект может автоматически фигурировать и как объект на диаграмме функций, и как элемент модели данных. Однако подобные решения требуют наличия дорогостоящего ПО и строгого следования методологии [3, 4].

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

Парсинг IDEF0-диаграмм. IDEF0-модель представлена набором функций (блоков), связанных стрелками потоков: входы, выходы, механизмы и управления. Для заданной модели (например, в формате XML/IDEF0 или выгруженной структурой) выполняется обход всех диаграмм и сбор имен входных/выходных потоков функций. Эти имена считаются кандидатами на ДПО (документы/ин-формационные объекты).

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

. Выделение СПО. Анализируется полученный список ДПО с целью выявления родовых категорий объектов – СПО. Часто несколько документов относятся к одному объекту. Например, документы «Чертеж детали» и «3D-модель детали» относятся к сущности «Деталь». Здесь пригодятся правила обобщения: отбрасывать вид представления (чертеж, модель) и выделять собственно объект (деталь). Таким же образом из множества документов «Маршрутная карта», «Карта контроля», «Техпроцесс» – может быть выделена сущность «Технологический процесс». Автоматизация этого шага затруднена и может потребовать тезауруса или словаря терминов, однако возможна простейшая реализация через поиск общих корней или использования заранее заданных шаблонов имен. Формальным критерием может служить включение одного слова в состав других (например, “деталь” присутствует в обоих упомянутых документах). Результат – список СПО (объекты, информация о которых будет храниться постоянно).

. Определение базовых БП. Функциональная модель обычно многоуровневая: на верхнем уровне – укрупненные бизнес-процессы, декомпозированные далее на подфункции. Из диаграммы верхнего уровня IDEF0 извлекаются основные бизнес-процессы предприятия (например, «Конструкторская подготовка», «Технологическая подготовка», «Управление изменениями» и т.д.). Их уточнение на деталях IDEF0 не требуется, важны лишь названия и границы этих процессов. Базовые БП будут использованы затем для привязки ролей и регламентации прав.

. Связи между СПО, ДПО и БП. На основании исходной IDEF0-модели можно установить, какие документы (ДПО) задействованы в каждом бизнес-процессе, а также какие сущности (СПО) связаны с теми или иными документами. По сути, строятся двумерные связи: «БП–ДПО» и «ДПО–СПО». Например, БП «Разработка КД» использует документы «3D-модель», «Чертеж», «Спецификация» и т.д.; документ «Спецификация» связан с сущностью «Изделие» (или «Сборочная единица»). Построив такую сеть отношений, можно получить и сводную таблицу связи БП–СПО, исключив посредника (ДПО). Это позволит увидеть, какие сущности фигурируют в каких процессах, и с какой частотой.

. Оптимизация перечня сущностей. Введем коэффициент использования сущности: отношение числа бизнес-процессов, в которых она встречается, к общему числу БП. С помощью данного показателя можно количественно оценить значимость каждой СПО для деятельности предприятия. На практике целесообразно ограничить перечень реализуемых в ИС сущностей лишь наиболее важными. Если задать порог минимального коэффициента, отсекаются редко встречающиеся сущности, что упрощает модель данных и уменьшает объем разработки. При необходимости некоторые исключенные сущности могут быть возвращены по решению экспертов (например, если они критически важны, хоть и редко используются). Такой подход обеспечивает оптимизацию модели данных, сохраняя ключевой функционал.

На основе описанной методики разработан прототип скрипта на Python, реализующий автоматическое формирование списков СПО, ДПО и БП по заданной IDEF0-диаграмме. В прототипе модель IDEF0 представляется в виде структур данных (например, словарей Python), содержащих описание функций и их связей. Алгоритм проходит по всем функциям, собирая названия входных/выходных потоков, затем применяет правила обобщения и формирует итоговые списки. Ключевой фрагмент алгоритма (псевдокод) приведен на рисунке 1.

Результатом работы скрипта являются три таблицы (списка): Таблица СПО (с указанием имен сущностей и описанием их смысла), Таблица ДПО (перечень документов/информационных объектов) и Таблица БП (список бизнес-процессов верхнего уровня). Кроме того, генерируются таблицы

• 1    # Псевдокод извлечения ДПО и СПО из структуры IDEF0

• 2    documents = set()

3-for function in idef0_nodel. functions:

• 4 * for flo*i in function.inputs + function.outputs:

• 5          documents. odd(normol i ze_name(f low. name))

• 6    # documents - уникальные названия потоков (кандидаты ДПО) 7

• 8    entities = set()

• 9 - for doc in documents:

• 10    ent - generalize_to_entity(doc)

• 11    entities.add(ent)

• 12    # entities - уникальные сущности, полученные обобщением названий документов

Рис. 1. Фрагмент алгоритма Python для формирования СПО/ДПО связей: например, матрица включения ДПО в каждый БП, матрица связей СПО–ДПО и расчетные коэффициенты использования сущностей. Все эти артефакты формируют табличную модель данных предприятия, согласованную с функциональной моделью IDEF0. Они станут основой для проектирования базы данных ИС КТПП.

Следует отметить соответствие предложенной методики требованиям стандартов. Выходы IDEF0 корректно детализированы в виде информационной модели данных, как того требует методология IDEF1X. Полученные списки элементов могут служить отправной точкой для разработки ER-диаграммы (связной модели «сущность-связь»). Кроме того, применение формальных правил и скриптов обеспечивает объективность и воспроизводимость: уменьшается влияние человеческого фактора и ускоряется переход от анализа процессов к проектированию базы данных. В заключение данного этапа результаты могут быть экспортированы в формат, поддерживаемый PDM/PLM-системами. В качестве такого формата целесообразно использовать XML, поскольку он де-факто стал стандартом обмена технологическими данными. Древовидная структура информации в PDM (проект–изделие–документы и пр.) легко транслируется в иерархию XML-элементов. Для каждого класса объектов базы данных выделяются соответствующие узлы XML, связанные через дочерние элементы и атрибуты-ссылки. Следование открытым стандартам обмена (XML, STEP) гарантирует, что полученные данные могут быть загружены во внешние приложения: например, система отчетности (Crystal Reports) или непосредственно в модули PDM/PLM.

АРХИТЕКТУРА ИНТЕГРАЦИИ ТАБЛИЧНОЙ МОДЕЛИ С PDM/PLM

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

База данных конструктора. Ключевой класс объектов в PDM-системе – «Проекты», вокруг которого организованы все данные. Для КТПП это означает, что каждое изделие (проект) имеет свою иерархическую структуру сборок и деталей. В базе конструктора присутствуют классы, отражающие структуру изделия: изделия (проекты), сборочные единицы, детали, стандартные покупные изделия и материалы. К ним привязаны различные документы: конструкторская документация (чертежи, спецификации, модели), нормативы, требования. Данные классы соответствуют сущностям СПО, выделенным из IDEF0. Например, если среди СПО присутствуют «Деталь», «Сборочная единица», «Оснастка», – то в БД конструктора будут таблицы или классы с такими названиями. ДПО хранятся либо как атрибуты/ссылки (файлы) этих объектов, либо в отдельных таблицах, связанных отношением «многие-к-одному» (несколько документов могут относиться к одной детали). Важной частью конструкторской БД является классификатор документов – набор справочников (типов документов, типов материалов, единиц измерения и пр.), соответствующих ГОСТ и ЕСКД. Это гарантирует, что формируемые отчетные документы (спецификации, ведомости) будут удовлетворять требованиям ЕСКД и не нарушать государственных стандартов.

База данных технолога. Технологическая подсистема ориентирована на описание процессов изготовления и сборки. Основные объекты здесь – техпроцессы, операции, оборудование, инструменты, материалы, маршруты и графики. Структура техпроцесса может быть представлена деревом операций (переходов), которое в ИС хранится аналогично дереву изделия. В PDM-системах часто реализуют отдельный класс для технологических процессов, связанных ссылками с классами изделий. Например, в БД SmarTeam на одном предприятии класс «Техпроцесс» содержал маршруты изготовления, включающие операции (вложенные записи) и ссылки на оснастку, станки и норма- тивы времени. В нашем подходе сущности СПО, относящиеся к производству (например, «Операция», «Станок», «Оснастка»), образуют соответствующие таблицы технологической БД. Документы (ДПО), такие как маршрутные карты, карты контроля, инструкции, хранятся либо как файлы, либо как структурированные записи (например, перечень операций с параметрами). База технолога также опирается на классификаторы – материалы, оборудование, типовые технологические решения и пр., что обеспечивает соответствие стандартам и сквозную прослеживаемость.

Интеграция конструкторской и технологической моделей. Поскольку конструкторская и технологическая подготовка связаны одним объектом – изделием, между их данными должны быть установлены связи. В PDM/PLM это реализуется через логические связи между объектами разных классов. Например, детали из конструкторской БД могут быть связаны с соответствующими техпроцессами из технологической БД. Принцип «единственного источника правды» требует, чтобы информация об объекте возникала в системе один раз (у создателя) и далее использовалась всеми. Это соответствует концепции ЕИП: «информация поступает в ЕИП в момент ее возникновения и хранится в единственном экземпляре, преобразуясь интерфейсами в требуемый вид». В нашем случае конструкторская подсистема генерирует структуру изделия и КД, после чего технологическая подсистема через интерфейс получает необходимые данные для разработки техпроцессов. Обратная связь (например, требования технологичности, заменяемость материалов) также может передаваться через интерфейс обратно конструкторам.

На рисунке 2 схематично представлена архитектура взаимодействия.

Рис. 2. Архитектура интегрированной ИС КТПП: связь базы конструктора и технолога через PDM/PLM-среду

Как показано на рисунке 2, PDM/PLM-система выступает каркасом, в котором функционируют обе подсистемы. Она обеспечивает единое хранилище данных (базу), сервисы управления версиями, доступом, электронным архивом. Конструкторы работают в своем контуре (например, CAD + PDM модуль), технологи – в своем (САПР технологических процессов + PDM модуль), но общие данные (структура изделия, идентификаторы объектов) синхронизированы. Интерфейс обмена может быть реализован несколькими способами: через прямое обращение к БД PDM (если обе подсистемы являются модулями одной системы, они могут читать/писать общие таблицы) либо через обмен файлами/сообщениями в стандартизованном формате. Например, конструкторская подсистема по запросу генерирует XML-файл со структурой изделия, включая необходимые атрибуты деталей (материалы, масса, номера чертежей). Технологическая подсистема парсит этот файл и создает у себя заготовки маршрутов для каждой детали. После разработки техпроцессов аналогичным образом может формироваться XML с описанием техпроцессов, доступный для просмотра конструкторами или для внешних ERP-систем. Использование XML как промежуточного формата обеспечивает независимость от конкретных программных продуктов и совместимость с международными стандартами обмена (например, STEP/ISO 10303 для структур изделий и процессов). При необходимости, вместо XML возможен формат JSON с RESTful API, что облегчает интеграцию с веб-сервисами и современными платформами. Однако в промышленных условиях XML предпочтителен из-за широкой стандартизации (XSD-схемы) и наличия готовых модулей импорта/экспорта во многих PDM/PLM.

Важно подчеркнуть, что разработанная модель данных опирается на отечественные и международные стандарты: структура конструкторской документации и техпроцессов соответствует ЕСКД/ ЕСТД; электронный документооборот – требованиям ГОСТ Р 50.1.031-2001 и серии ГОСТ 34.x по автоматизированным системам; форматы данных – рекомендациям STEP и XML. Это позволит в будущем аттестовать систему на соответствие требованиям цифрового производства и облегчить ее сопровождение.

МОДЕЛЬ RBAC И МАТРИЦА КОМПЕТЕНЦИЙ

Для управления бизнес-процессами в разработанной системе реализуется ролевая модель доступа (RBAC – Role-Based Access Control) [5, 6]. Все пользователи системы разделяются по ролям (должностям), соответствующим их функции на предприятии: конструктор, технолог, начальник отдела, проверяющий (аудитор), администратор и т.п. Роли определяют набор прав (permissions) на действия с объектами и процессами. Например, роль «Конструктор» может иметь право создания и редактирования конструкторских документов, запуска процесса разработки КД; «Технолог» – право редактировать техпроцессы, запускать процесс отработки технологии; «Начальник отдела» – утверждать результаты, контролировать сроки; «Администратор» – настраивать систему, управлять справочниками и правами. Согласно анализу научных концепций, в области промышленного производства можно выделить различные стратегии организации процессов, которые зависят от характеристик продукции и технологических особенностей. Так, процессы могут быть ориентированы на создание однородной продукции с использованием специализированного оборудования и строго определённого порядка операций, что типично для непрерывного потока, где материалы последовательно перемещаются через производственные линии [5]. Примером служит нефтепереработка, где сырьё обрабатывается в непрерывном режиме.

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

Администратор системы в данном контексте выполняет настройку RBAC: создает новые роли (должности) и подразделения, регистрирует пользователей, назначает им роли и права. Вариант использования «Администрирование бизнес-процессов» включает, в частности, следующие функции (рисунок 3): управление списком пользователей и ролей; назначение прав ролей и отдельных пользователей на выполнение типовых процессов; настройка параметров процессов (лимитов времени, условий переходов); создание/удаление шаблонов бизнес-процессов; подключение внешних модулей (например, БД оборудования). На рисунке 3 показана фрагмент диаграммы прецедентов административного модуля workflow-системы.

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

Неотъемлемой частью модели является учет компетенций персонала. Введем понятие матрицы компетенций – таблицы, где по строкам перечислены роли (должности), а по столбцам – ключевые навыки или области знаний, важные для предприятия. Значения в ячейках отражают уровень владения данным навыком для роли (например, по шкале от 0 до 5 либо процентном отношении). Пример фрагмента матрицы: роль «Инженер-конструктор» – CAD-системы: 5 (эксперт), PLM: 3 (средний), Технология сварки: 2 (базовый); роль «Инженер-технолог» – CAD: 2, PLM: 4, САПР технологическая: 5, и т.д. Такая матрица может формироваться на основе должностных инструкций и оценки квалификации сотрудников. Она хранится в ИС и используется при назначении задач.

Как происходит распределение задач по компетенциям: каждому шагу бизнес-процесса, требующему ручного исполнения, сопоставляется требуемая компетенция – например, задача «разработать 3D-модель узла» требует навыка «CAD-системы» уровня не ниже 3; задача «разработать технологию сварки» – навыка «Технология сварки» уровня 4. При старте процесса система автоматически

Создать бизнес-процесс

Редактировать схему БП

Редактировать схему запущенного БП

Переименовать БП

Разблокировать БП

Удалить бизнес-процесс

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

Управление автоматическими операциями

Управление условиями перехода

Назначить права ролям/пользователям

Администратор.

^опровождение/Смстемные

Создать объект (тип/рол. / отдел)

Обновить информацию об объекте

Работа с буфером

Изменить срок полномочий пользователя

Администрирование / Настройка\

- ^«include»

«include»

«extend»

Эскалация по лимитам времени

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

Отметим, что модель компетенций тесно связана с RBAC: фактически, каждая роль предполагает определенный профиль компетенций. Однако внутри одной роли разные сотрудники могут иметь разный уровень (например, молодые специалисты и эксперты), поэтому индивидуальный профиль тоже важен. В системе это можно реализовать через присвоение квалификационного уровня – например, Junior, Middle, Senior. Квалификационный уровень (грейд) обобщенно отражает опыт сотрудника. В матрице компетенций грейд коррелирует с значениями по всем навыкам (Senior, как правило, ближе к максимальным уровням). Грейд используется и для расчета времени/стоимости, как будет показано далее.

АЛГОРИТМЫ НАЗНАЧЕНИЯ ЗАДАЧ И ОЦЕНКА СРОКОВ/СТОИМОСТИ

После того как в систему внесены данные о задачах (этапах процессов), их сложности и доступных исполнителях, встает задача планирования и прогнозирования – оценить, за какое время и с какими затратами предприятие выполнит тот или иной проект, а также оптимально распределить работу между сотрудниками [7, 8]. Разработанная модель позволяет автоматизировать эти расчеты. Ниже приводится алгоритм формирования расписания и оценки трудозатрат:

. Оценка сложности задачи. Под сложностью понимается объем работ, связанный с задачей, и ее взаимосвязи с другими элементами. Для задач разработки ИС (как в предыдущем разделе) естественным показателем сложности была численность связей сущности с документами. В общем случае сложность можно измерить трудоемкостью или количеством подзадач. В нашей табличной модели можно хранить для каждой сущности или документа параметр «сложность» (например, число связей или экспертная оценка в нормо-часах). Например, сущность «Сборочная единица» может иметь сложность 5 (так как включает много деталей и документов), а «Деталь» – 2. На этапе планирования проектирования ИС такой параметр заполняется аналитиками либо рассчитывается автоматически (по числу документов на сущность). В производственных процессах сложность операции может браться из нормативов времени.

. Модель времени выполнения. Вводится функция , где – квалификационный уровень исполнителя (грейд), – сложность (число связей или трудоемкость) задачи. Эта функция моделирует, за какое время специалист данного уровня выполнит задачу данной сложности. Точный вид функции может определяться статистически (ниже описан способ накопления данных), но в первом приближении можно принять линейную зависимость: , где коэффициент выше для низкоквалифицированных (Junior) и ниже для высококвалифицированных (Senior) сотрудников. Таким образом, Senior за единицу сложости затрачивает меньше времени, чем Junior. Более сложные модели могут учитывать нелинейность: практика показывает, что с ростом сложности время растет нелинейно – вероятность ошибок и итераций повышается, что приводит к дополнительным затратам времени. На графике (рис. 3) это проявляется как выпуклость кривой – время начинает расти быстрее после некоторого порога сложности. Если по эмпирическим данным график для разных уровней имеет изломы, то точка излома может интерпретироваться как оптимальный размер задачи для данного уровня – превышать его нежелательно, лучше декомпозировать задачу на несколько более простых. Такие выводы могут учитываться при совершенствовании бизнес-процессов (например, если выясняется, что процессы слишком сложны и не вписываются в разумные сроки у всех уровней специалистов).

Рис. 4. Зависимость времени выполнения от сложности для специалистов разных уровней квалификации

На рисунке 4 показана типичная зависимость: для Senior (верхняя кривая) время растет медленнее, чем для Junior (нижняя кривая) при увеличении сложности задачи. Разрыв между кривыми отражает разницу в продуктивности. При сложности, превышающей некоторый предел (зона излома), время резко возрастает даже у экспертов – такие задачи лучше разделить.

. Распределение задач между исполнителями. Зная функцию для всех уровней, система может смоделировать различные варианты распределения задач. Простейшие экстремальные случаи: минимальный срок – все задачи выполняют самые квалифицированные сотрудники (минимальные ), максимальный срок – все выполняют самые младшие (максимальные ). Реальность обычно между ними: задачи распределяются в соответствии с доступностью сотрудников и рациональным использованием их времени. Целесообразно более сложные задачи ( высокое) назначать более опытным, а простые – младшим специалистам. Алгоритм может быть жадным: отсортировать задачи по убыванию сложности и последовательно назначать их свободным сотрудникам самого высокого грейда из доступных. Либо можно решить задачу как линейное программирование, минимизируя суммарное время (или сбалансировав загрузку). В рамках статьи достаточно отметить, что правило «сложное – эксперту, простое – новичку» позволяет ускорить выполнение проекта без увеличения штата.

. Проверка реализуемости проекта во времени. Суммируя оценки по всем задачам (или по критическому пути, если задачи выполняются параллельно), можно получить прогнозные сроки проекта при данном распределении. Если желаемые сроки проекта находятся между минимальным и максимальным временем (то есть между сценарием «все Senior» и «все Junior»), можно считать, что проект реалистичен в заданных условиях. Если же требуемое время меньше даже чем при идеальном раскладе (все Senior заняты только этим проектом), значит, объем проекта слишком велик – следует либо увеличить число/уровень исполнителей, либо сократить объем работ (вернуться на этап оптимизации модели данных и уменьшить число сущностей, понижая порог коэффициента использования). Последнее соответствует изменению границ проекта: исключению менее значимых функций/сущностей из текущей очереди реализаци.

Алгоритм планирования, предложенный в данной работе, изначально был применен для задач разработки ИС КТПП (планирования этапов проектирования и внедрения системы). Однако он имеет универсальный характер и может быть использован и для производственных процессов при достаточной статистике норм времени. Необходимо при внедрении системы сбора данных включить механизм накопления фактических трудозатрат по каждой задаче и каждого исполнителя [9, 10]. Со временем это позволит уточнить функцию $ на основе реальных данных и настроить систему планирования более точно под специфику предприятия. Будет установлена эмпирическая связь «квалификация – сложность – время», возможно, отличная от линейной. Кроме того, система может учитывать фактор параллельности: если специалист ведет несколько задач сразу, эффективность падает из-за переключения контекста. Поэтому предпочтительно, чтобы сотрудники работали последовательно, или в модели вводятся поправочные коэффициенты за одновременное ведение задач.

В итоге, использование алгоритмов автоматического назначения и прогнозирования сроков/ стоимости на базе табличной модели дает существенные преимущества: более реалистичное планирование, раннее выявление «узких мест» (нехватки компетенций или чересчур сложных задач), рациональное распределение нагрузки [11]. Это ведет к снижению рисков срыва сроков и перерасхода бюджета, повышению прозрачности и управляемости проектов.

ЗАКЛЮЧЕНИЕ

В работе предложен комплексный подход к разработке ИС для КТПП, объединяющий функциональное и информационное моделирование, PDM/PLM-технологии и средства управления биз-нес-процессами. Данная архитектурно согласованная модель включает формализованную табличную модель данных (СПО, ДПО, БП), интегрированную в PDM/PLM-среду, и подсистему workflow с RBAC+Skills, обеспечивающую распределение задач по ролям и компетенциям. Применение методологии IDEF0 для анализа процессов и автоматизированной трансформации в данные позволяет сократить разрыв между этапом бизнес-моделирования и непосредственно реализацией ИС. Соответствие стандартизованным нотациям (IDEF1X, ER-моделирование) и использование XML/STEP для обмена гарантирует совместимость с международными требованиями (ISO 10303, CALS) и отечественными стандартами (ЕСКД, ГОСТ).

Основные результаты применения предлагаемого подхода:

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

• .    Сокращение времени разработки ИС за счет генерации структуры БД из моделей процессов – исключается длительный этап ручного составления списков сущностей, снижается вероятность упущений.

• .    Гибкость и расширяемость модели: благодаря табличной структуре и открытым интерфейсам, возможна интеграция новых модулей (например, подключение ERP-систем, CAD/CAE приложений) без ломки общей архитектуры.

• .    Улучшение управления проектами внедрения. Автоматический расчет сроков и потребных ресурсов позволяет более точно планировать проекты. Руководство получает инструмент для оценки сценариев: если требуется ускорить разработку, видно, во что это обойдется, и наоборот, при ограниченном бюджете понятны последствия для сроков. Это способствует принятию обоснованных решений.

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

• .    Создание предпосылок для сквозной цифровизации КТПП: данные конструкторов и технологов объединены, процессы регламентированы, информация доступна в актуальном состоянии для всех участников ЖЦ изделия.

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

Экономический эффект от полноценного внедрения подобной PDM/PLM-ориентированной ИС проявляется не столько в прямом снижении текущих издержек, сколько в ускорении вывода продукции на рынок и росте конкурентоспособности. Быстрее окупаются вложения в разработку новых изделий, увеличивается доля рынка за счет оперативности и качества подготовки производства. Перспективы развития системы включают интеграцию с смежными подсистемами цифрового предприятия: CRM, MES, системы управления качеством, а также применение технологий искусственного интеллекта для поддержки принятия решений (например, рекомендация оптимального плана работ или выявление аномалий в процессах).

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