АО «Уральский завод гражданской авиации» («УЗГА»), прежде известный своей специализацией на ремонте авиационных двигателей, сегодня развивается как авиастроительный холдинг в сегменте малой, региональной и учебной авиации. На новой производственной площадке создаётся высокотехнологичная база для изготовления собственных моделей самолётов «Байкал» и «Ладога».

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

Когда в технологической подготовке производства оперируют аналоговыми, бумажными документами, их невозможно использовать на следующих этапах жизненного цикла. Перед нами стояла задача обеспечить единое информационное пространство для решения задач ТПП, предусмотреть возможность тиражирования системы на все заинтересованные подразделения компании. На тот момент, а это был 2021 год, наши технологи работали в PLM-комплексе АСКОН версии 2014 — системах ЛОЦМАН:PLM, САПР ТП ВЕРТИКАЛЬ и Корпоративных справочниках. Нужные нам инструменты в тех версиях отсутствовали, а сами версии были сняты с технической поддержки. Так проект модернизации информационной системы ТПП одновременно стал и проектом обновления PLM-комплекса.

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

В команду проекта со стороны АСКОН-Урал вошли руководитель проекта, специалисты по внедрению и менеджер, курировавший вопросы коммерческого характера. С нашей стороны в проекте работали специалисты отдела САПР, кураторами выступили директор по информационным технологиям и технические директора по направлениям деятельности. Моя роль — руководитель проекта со стороны заказчика.

Согласовали план-график реализации функционала. По каждому этапу плана закрепили ответственного и исполнителя. В рамках коммуникации выстроили систему взаимодействия в виде еженедельных статусов, которые проводили по ВКС. Дополнительно, если была необходимость, специалисты АСКОН-Урал выезжали к нам для проведения работ и сдачи результатов работ функциональным заказчикам.

Главным вызовом в проекте стало объединение нескольких исторических баз данных, баз нормативно-справочной информации (НСИ) и архивов разных дивизионов в один источник. В эксплуатируемой на тот момент версии PLM-комплекса разделение направлений деятельности компании производилось за счет организации отдельных баз данных в контуре ЛОЦМАН:PLM. Это привело к тому, что появились четыре базы с инженерными данными об изделиях. С учётом того, что система постоянно развивалась и дорабатывалась, в какой-то момент эти базы данных перестали быть равны друг другу с точки зрения настроек, атрибутов и типов объектов. Фактически, мы имели четыре разнородные системы управления инженерными данными об изделии.

Потребность в объединении мы осознали в момент внедрения электронного согласования технологической документации. В этот момент пришло понимание, что если наши разработчики, конструкторы и технологи находятся в пределах одной базы данных, то согласующие лица — междивизиональные, они могут согласовывать документы всех направлений деятельности. Инструментарий системы управления инженерными данными ЛОЦМАН:PLM позволял формировать задачу на согласование тому или иному специалисту, но для того, чтобы эти задачи получить, специалисту приходилось переключаться между разными базами данных. Сформировать единый поток задач не представлялось возможным.

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

В итоге вся информация об изделиях, необходимая для планирования производства, должна выгружаться в систему управления производством класса ERP. Если мы работаем в четырёх разных базах данных с четырьмя разными комплектами настроек, нужно проектировать и создавать четыре интегратора между производственной системой и каждой из баз данных. Требовалось обеспечить единство и синхронность настроек, так как выполнять рабочие операции стало проблематично: поддерживать четыре базы данных — всё равно что поддерживать четыре разных PLM-системы.

На старте мы запросили у АСКОН-Урал прогноз развития рисков: важно было получить экспертное мнение. Проанализировав информацию, решили, что к риску готовы. Проблемы ожидаемо возникли, как только мы начали детально разбираться в комплектах настроечных файлов, метаданных, атрибутов, типах объектов, смотреть, как сопоставить различные базы данных. Информация в разных базах дублировалась, а в дублях были и противоречия, и уточняющие друг друга информационные объекты. Предстояло принять решение по каждому типу объектов. Сопоставив их напрямую, нужно было сохранить наиболее актуальные, учитывая ценность информации для пользователей. Поэтому определили исходный принцип работы по проекту: мы не должны допустить потери данных, накопленных за период работы компании с PLM-комплексом АСКОН версии 2014, а это технический долг: с 2012 по 2021 годы накопилось более 2,5 Тб инженерных данных. После существования системы в таком режиме требовалась синхронизация.

Ценность данных выявляли различными способами: консультировались с функциональными заказчиками, оценивали востребованность информации по связям внутри системы, где эта информация могла бы быть использована.

Работа проводилась вручную: мы выгружали и сопоставляли базы. Процесс растянулся на 10 месяцев. С комплектами настроек и метаданных работали специалисты АСКОН-Урал, а мы прорабатывали те объекты, которые требовали нашего внимания. Объём работ по проекту составил 4088 часов для специалистов АСКОН-Урал и 4282 часа для проектной команды УЗГА. Изменения в настройки баз данных вносились ежедневно. Если они касались только одной из четырёх баз, то получался инкремент в базе данных.

Изначально разделение на несколько баз данных было оправдано: требовалось разделить направления деятельности компании. Необходимо было обеспечить конфиденциальность данных в новой, объединённой целевой базе, руководствуясь принципом: инженерные данные одного направления не должны просматриваться специалистами другого направления. Что касается ролевой модели и прав доступа, сложность заключалась в том, что непосредственно разработчики не должны были видеть эту информацию друг у друга, а согласующие — должны. Для её решения специалисты АСКОН-Урал реализовали алгоритм раздачи прав, который функционирует по расписанию: каждые сутки в системе происходит пересчёт прав доступа. Это было необходимо для оперативности получения информации.

В эксплуатируемой нами 2014 версии PLM-комплекса использовался модуль управления архивом, разработанный АСКОН-Урал в 2015 году. Его доработка, поддержка и развитие были невозможны. Поэтому мы смотрели на тиражный модуль ЛОЦМАН:PLM Архив — доработать его и внедрить, чтобы как минимум сохранить функционал предыдущего самописного. Проектные решения описывали и согласовывали в тесном контакте со специалистами службы архива.

Цифровое решение «Инфокиоск» проектировалось специально под «УЗГА». Оно представляет собой поисковую систему, реализованную в web-формате и позволяющую в цеховых подразделениях печатать отдельные документы, либо просматривать то, что находится в архиве. Полноценный клиент ЛОЦМАН:PLM для цехового рабочего имеет заведомо излишнюю функциональность, к тому же компьютеры в цехах не позволяют использовать полноценный клиент ЛОЦМАН:PLM. Плюсом появляется возможность отслеживать, кто и какие документы печатает, чтобы не допустить оборот неучтённых технологических документов. Разработку для завода мы выполнили в рамках проекта, реализовав в ней авторизацию пользователей. Система специфична для авиации, потому что в ходе производства работ мы должны заполнять соответствующую сопроводительную документацию — дела ремонта и дела изготовления, фиксировать факт выполнения технологических операций. С использованием функционала Инфокиосков рабочий может самостоятельно распечатать актуальный бланк сопроводительной документации для заполнения, тем самым снизить нагрузку на специалистов копировально-множительного центра архива предприятия.

ПОЛИНОМ:MDM мы используем нестандартно. В своей изначальной задумке это система управления нормативно-справочной информацией предприятия. Мы же организовали внутри неё журнал регистрации различной технологической документации. При этом смогли внедрить не только автонумераторы последовательной выдачи номеров, но ещё и логику. В интерфейсе технолог заводит исходные данные: тип техники, тип деятельности, вид работ, дополнительные уточняющие данные, и нажимает кнопку «рассчитать». Система регистрирует его номер и сохраняет в журнале. Но в целом функционал системы применяем в полном объёме: в нём ведётся управление НСИ-данными предприятия. Данные, загружаемые в справочники, дополнительно проходят процедуру назначения специального отличительного признака, который позволяет идентифицировать их во всех корпоративных информационных системах, где требуется добавление данных НСИ.

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

Сейчас мы согласуем технологическую документацию в системе ЛОЦМАН:PLM. По выстроенному шаблону направляем на согласование инструментальный файл, полученный из ВЕРТИКАЛЬ, и его вторичное представление. Переход на новую версию ВЕРТИКАЛЬ, смена внешнего вида интерфейса прошли без особых проблем и сопротивления. Снизить вероятность «отторжения» удалось за счёт предварительного проведенного обучения и демонстрации целевого функционала для всех потенциальных пользователей решения.

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

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

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

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

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

Функционал конфигурирования изделий присутствовал еще в ЛОЦМАН:PLM 2014 как операции с группами замен. С одной стороны, конечная задача решалась, с другой стороны, исходя из объёмов проведения изменений и с точки зрения трудоёмкости было сложно оперировать различными конфигурациями. Потому что когда, например, мы определяли применяемость деталей и сборочных единиц не для конкретного бортового номера, а указывали принадлежность версии изделия в формате «начиная с ХХ борта и далее» или в виде интервала «с … по…», то мы были вынуждены проводить изменения для всех изделий, указанных в интервале.

После обновления на актуальную версию PLM-комплекса мы освоили новый подход — управление динамическими структурами. Функционал позволил нам управлять применяемостью более гибко и тратить значительно меньше времени на конфигурирование изделия.

Для оценки результатов проекта мы вели определенные метрики. Одна из ключевых — сокращение длительности процессов согласования: инженерно-технические работники больше не ходят друг к другу для подписи бумажных документов, а выполняют все действия по согласованию со своих рабочих мест. Но самое главное — мы не допустили потери данных. «Инфокиоск» адаптирован под актуальную модель данных PLM-комплекса. Четыре разнородных по своему содержанию и настройкам метаданных базы данных стали одной унифицированной с ролевой моделью внутри.

Наш проект позиционировался под fix price с чётким сроком окончания работ и оговоренным объёмом. При этом мы закладывали контрольные точки в формате «выполнить в срок не позднее...». После подписания договора наступил 2022 год, когда иностранные вендоры ушли из России и на отечественных разработчиков обрушился шквал запросов. Но, несмотря на отсутствие ресурса в достаточном количестве, мы смогли завершить проект в апреле 2023 года, со сдвигом сроков всего на месяц. Сейчас PLM-система введена в промышленную эксплуатацию. Реализованный проект – уникальный набор спроектированных и внедренных проектных решений, кейс цифровизации инженерных данных в рамках предприятия авиационной промышленности РФ, с учетом ограничений, требований и специфики отрасли. Кроме того, это первое в регионе решение по объединению и унификации разнородных исторических данных об изделии под управлением корпоративной импортонезависимой PDM-системы.