Ксения Епанчина рад нашему обмену мнениямия. Хотелось, чтобы Ваши идеи нашли отклик у корпоратвных архитекторов и архитекторов решений ИТ.

Российские решения для мониторинга отклонений от техрегламента:

«Иксперт»— АСДКиМ: мониторинг в реальном времени, прогноз аварий, отчётность для Ростехнадзора.

«Алинги» — АИСМК: управление качеством, анализ причин отклонений, работа с несоответствиями.

НТЦ «Комплексные системы мониторинга» — комплексный мониторинг инфраструктуры и оборудования.

«ИндаСофт» — I‑DS: контроль технологических, экологических и качественных норм.

Ваш пример отлично ложится на проблематику цифровых двойников и BIM: если исходные регламенты не имеют единой семантики и структуры, то «подружить» их с моделью или ПО практически невозможно. «КШ‑25» — это как элемент без уникального идентификатора и контекста: система не понимает, что это за узел, где он находится и как связан с потоками. "Визуальный генератор" в этом случае становится частью цифровой модели предприятия: регламент становится производным от модели, а не отдельным документом. Это сразу закрывает вопросы аудита, версионности и интеграции. Учитывая фокус на цифровизации производства и цифровых двойниках, такой подход может стать хорошим пилотом: формализовать типовые регламенты, привязать их к объектам модели и автоматизировать проверку. Что думаете насчёт связки с MES/PDM или с инструментами управления требованиями? Разве в Вашей практике не стремятся к это связанности на уровне архитектуры?

Георгий, Вы абсолютно правы в том, что без реального UUID “КШ-25” это просто строка. Если цифровой двойник будет опираться на такие висящие в воздухе данные, ничего хорошего из этого не выйдет, безусловно. Да, генератор должен опираться на реальные “материальные” части объектной модели предприятия. Наверное, регламент можно было бы даже представить в виде своеобразной витрины данных.

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

Что касается связки, то я думаю, что тут напрашивается такая цепочка: 1️⃣ Слой 1 - PDM- тут мы знаем всё о нашем кране шаровом из примера. 2️⃣ Слой 2 - визуальный генератор тех. регламентов - видим, где этот кран должен быть установлен, как он управляет потоками. 3️⃣ Слой 3 - MES - управляем процессом, опираясь на тех. регламент напрямую. В такой цепочке, в случае замены КШ, изменения потоков, все следующие слои опираются на эти новые данные. В результате мы всегда знаем правду и уверены в минимальном количестве ошибок.

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

Ксения, Георгий)

О, простите меня, пожалуйста! Тяжёлый день выдался! Не хотела Вас обидеть.

Понимаю, здесь не может быть обид.

На какой уровень вы выносили предложение?

И какая была аргументация против?

Георгий, отвечая на Ваши вопросы скажу: 1) идеи выносились на уровень руководителя отдела; 2) ни одного аргумента "против" не было. Просто идеи не получили совершенно никакой обратной связи вообще.

Я вот размышляла о цепочке всё того же КШ-25, и вспомнила: а ведь его "жизнь" в рамках предприятия начинается не просто в SAPе, например. Он появляется сперва на складе. И это - тоже ещё одна точка для потенциальной автоматизации! При чём здесь она начинается с самого простого - достаточно взять банку белой краски и разметить асфальт на "квадраты". А на складе будет ПО с выбором квадрата и привязкой ТМЦ к ним. Одно только это ускорит поиск нужных вещей на складе типа "открытая площадка". И это мы даже не говорим о сканерах и принтерах бирок. По сути мы создаём цифровой двойник склада. Ну и вот уже затем, садится наш технолог, например, открывает генератор тех. регламентов и видит: да, вот его КШ-25, он поступил тогда-то, смонтирован тогда-то, так-то. В случае чего - вся "история жизни" этого КШ-25 - как на ладони.

Как раз, выше говорил о том, что в предлагаемой архитектуре BIM выступает единым источником инженерных данных и отражает жизненный цикл объектов. На основе BIM автоматически формируются регламенты как производные от модели, что исключает расхождения между проектной информацией и эксплуатационными инструкциями. Данные передаются в MES для управления операциями, а телеметрия обеспечивает объективный контроль исполнения. Цифровой двойник/эмулятор используется на этапе проектирования и валидации сценариев, снижая риски при внедрении изменений. Такой подход минимизирует ошибки, вызванные ручным ведением регламентов, и сокращает стоимость простоев за счёт прослеживаемости и автоматического обновления данных по всей цепочке.

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

История с автоматизации складов совершенно не нова, Вы верно видите проблему и решения существуют.

Управление внутризаводской логистикой и складом)

Георгий, спасибо за развёрнутые ответы! Но вот мне интересно - что делать со старыми, созданными вручную тех. регламентами? Будем ли мы воссоздавать всю цепочку объекта Икс - от старта до того момента, когда сможет быть автоматически сгенерирован тех. регламент с его участием?

Поясню. Пусть есть тех. регламент, где написано "поток идёт через КШ-25 на Н-103". Так написано "в бумаге" и скреплено подписью. Но внезапно может оказаться при автоматическом построении регламента, что "КШ-25" не существует, а "Н-103" был заменён на "Н-112" ещё год тому назад. И что делать в такой ситуации? И будет ли некий специалист проверять правильность генерации? И если да, то как он будет это делать - вручную сравнивать с "бумажным" тех. регламентом?

Наверное, тут потребуется не только генерация новых и актуальных тех. регламентов, но всё таки и распознавание/чтение старых - с целью сравнения их с действительностью и выдачи некоего Лога сверки для анализа. Или всё таки старые должны отметаться, как утратившие актуальность в связи с введением в эксплуатацию ПО?

Внутренние регламенты как раз и рассчитаны на такую логику: изменение в проекте → реализация → обновление документации. Главное — чтобы все этапы были связаны через единый источник данных (например, через UUID и объектную модель). Тогда регламент перестаёт быть “вещью в себе” и становится производной от актуального состояния объекта. А контроль версий и статусов гарантирует, что в работу всегда попадает только согласованная и валидированная версия.

Распознование "старых регламентов" видится как единичная операция. Цифровой архив технической документации должен быть создан. Ведь на чем строить цифрового ИИ помощника технолога/инженера?

Более того, выстраивается система мониторинга и контроля отклонений от технологического регламента, которая обеспечивает непрерывную сверку фактических параметров процесса (по данным телеметрии MES) с нормативными значениями, зафиксированными в регламенте.

Ксения, конечно заказчики должны стремиться к наведения порядка в процессах управления своей НСИ. Зачастую подобные проекты сложно продать внутри компании - затраты ресурсов значительные (не забываем о необходимых изменениях в системах более верхнего уровня), а экономический эффект инициатор изменений обосновать не могут.

Полагаю, что для точного экономического обоснования требуется аналитика в разных разрезах, плюс, конечно, экономические расчёты. Думаю, что в целом это реализуемо, но вряд ли одним лицом, скорее всего. Наверное, если была бы инициативная группа, способная упаковать идею/предложение с полной раскладкой, может и можно было бы донести до руководства и получить одобрение на реализацию.

Но всякий раз это зависит от объёмов автоматизации и стандартизации, к которым мы стремимся. Иногда автоматизировать работу отдела под силу одному человеку, способному создать эффективные макросы в Excel и типовой вид файла таблицы.

Ксения Епанчина , Вы не знакомы с системой мониторинга отклонений от тех.регламента?

Появляется база для персонализации условий. Страховщики всё чаще используют данные с таких систем (это часть тренда InsurTech). На основе объективных телеметрических данных компания может точнее оценить реальный уровень риска на конкретном объекте. И как следствие — предложить более выгодную страховую премию или более детальные условия договора (например, сузить покрытие только на те участки, где риск объективно выше).

Ксения, не усложняйте. Как правило, один человек занимается проработкой гепотизы + ещё человек 20 помогают высказывание своих ценных мнений) Дорогу осилит идущий.

Тут важно понимать, как устроен процесс подачи и обработки идей в компании. Выстроен ли этот процесс?