Какие риски несет «архипелаг» инструментов

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

Итак, типовой набор программных инструментов выглядит так:

1. Вендорские западные и российские отраслевые продукты. Коробочные решения, например, EngGeo или Geotek Field, обычно решают конкретные задачи, но не всегда стыкуются между собой или с внутренними ИТ-системами компании и не образуют единый сквозной процесс. При этом часть продуктов осталась без вендорской поддержки, а другие не до конца закрывают потребности компаний.
2. Самописные инструменты. Обычно в архитектуру таких локальных решений изначально не закладывается сквозная автоматизация, масштабируемость, возможности горизонтальной интеграции и работа с единым хранилищем данных. Конкретная задача решается «здесь и сейчас». Нередко геологи используют устаревшие парадигмы разработки ПО, не самые оптимальные для конкретной задачи технологический стек и инструменты.
3. Программные инструменты общего назначения, прошедшие глубокую адаптацию, ставшие «платформой поневоле». Яркий пример – САПР Bentley MicroStation с десятками плагинов (Графическая колонка, Геологический разрез и другие), разработанными специалистами. Такие решения работают и развиваются в организациях десятилетиями. Отказаться от них без потери качества и скорости работы почти невозможно.

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

1. Сроки и стоимость проектов увеличиваются. Интеграционные взаимодействия создаются по схеме «точка – точка» и корректно функционируют только в самых распространённых случаях, а зачастую только в присутствии разработчика. Если что-то идет не так, информацию приходится доставать вручную из разных систем. Высокооплачиваемые, квалифицированные специалисты-предметники тратят часы на перенос и агрегацию данных, а также их верификацию. В результате лишние действия повышают итоговую стоимость процесса. Кроме того, человеческий фактор может стать причиной неточностей в данных.
2. Процессы становятся все менее прозрачными и управляемыми. До появления «зоопарка» средств автоматизации, руководитель достаточно четко представлял, в каком состоянии сейчас находится процесс. Сейчас процесс происходит «в цифре». Причем очень специфично, «транспорт» с данными с одного острова архипелага ушел, а на другой не пришел или его не удается «разгрузить». У руководителя часто нет возможности отслеживать ход и результаты изысканий, и производство остается «черным ящиком» вплоть до момента сдачи финального отчета.
3. Каждый «островок» суверенен по части организации хранения данных. Исторические результаты и проектные наработки могут храниться как в старых базах данных Access и Oracle, так и на компьютерах сотрудников. В этом случае отслеживать и контролировать изменения данных не получится. Кроме того, повышается риск потерять информацию в случае сбоев.
4. Низкий КПД решения в целом при достаточно высоком локальном КПД отдельных программных продуктов или самописных решений.

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

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

Например, «Да, наше решение, визуализирующее ИГЭ (инженерно-геологические элементы) для MicroStation Bentley Map выдаёт полностью устраивающий результат, но решение на российской платформе NanoCAD более перспективно, так как получает регулярные обновления и развивается».

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

Покупка очередного коробочного продукта не решает проблему лоскутной автоматизации, ровно как и самостоятельная разработка очередного инструмента. Также компании не хотят менять весь свой стек технологий, отказываться от написанных годами алгоритмов и переучивать персонал на новые программы. Подход «снести до основания и построить» вызывает сомнения заказчиков и поднимает вопросы о сохранении ИТ-активов.

Ключевой запрос рынка – решение, которое объединяет разрозненные данные, процессы, знания и инструменты в единой платформе, но не разрушает работающие механизмы. Предполагается, что такой инструмент внедряется поступательно – «сегодня мы включаем в сквозной автоматизированный процесс шаги 1, 2 и 3, а послезавтра добавляем к ним шаги 4 и 5».

Для этого решение не должно быть жесткой платформой, где набор компонентов «залит бетоном». Необходим конструктор с единым хранилищем данных, который можно подстраивать под специфику бизнес-процессов конкретной компании, технологический ландшафт, «боли» и планы развития. Разберем одно из таких решений – «Эпик» от «Инфосистемы Джет», выход которого компания анонсировала летом этого года.

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

Основных модулей семь:

• Единое хранилище данных (Data Lake). На предприятиях информация обычно лежит в реляционных базах (например, Oracle), сетевых папках или разрозненных файлах. Хранилище собирает все в одной точке. Данные дедублицированы и логически связаны: каждая скважина, интервал и проба существуют в единственном экземпляре. Технически это реализуется на базе современной СУБД PostgreSQL в связке с объектным хранилищем S3 для хранения файлов.
• Шина обмена данными и API. Через API все решения и программы, работающие в компании, взаимодействуют с хранилищем. Настроить обмен данными можно через любую шину, используя решения уровня ArenaData Streaming, Apache Airflow или платформы сторонних вендоров.
• Модуль Нормативно-справочной информации (НСИ) и управления метаданными (MDM). Важно, чтобы классификаторы грунтов, справочники лабораторных испытаний, реестры оборудования и другая метаинформация были едиными для всех участников проекта. Модуль НСИ в «Эпик» поддерживает версионность с привязкой к срокам действия каждой версии записи. Например, при изменении ГОСТа или внутреннего стандарта система сохраняет историю, поэтому старые проекты не ломаются и не пересчитываются по новым правилам. НСИ можно развернуть как независимый модуль решения или использовать уже внедренную у заказчика MDM-систему.
• Управление доступом, ролевая модель и авторизация. В платформе применяется open-source IAM-система Keycloak. Если у заказчика уже развернута своя служба каталогов (например, Microsoft Active Directory), решение подключается к ней. Пользователю не нужно заводить новые пароли — сохраняется сквозная авторизация и единый вход (SSO).
• Прикладные сервисы и бизнес-логика. Генераторы отчетов, системы мониторинга (своя сборка на базе Grafana или подключение к системам заказчика), потоковая аналитика для дашбордов руководства. Сюда же входит интеграция с системами электронного документооборота — Directum, Elma и другими решениями.
• Инфраструктура исполнения и контейнеризации. Вся бизнес-логика может быть развернута в платформе контейнеризации. В качестве основы интегратор предлагает отечественные решения, такие как платформа «Штурвал» от российского разработчика «Лаборатории Числитель». Контейнерная платформа позволяет снизить затраты на эксплуатацию, обеспечивает быстрый вывод новых сервисов и нулевые простои.
• Специализированные системы. Сюда входят все функциональные блоки платформы: планирование работ, проведение полевых работ и полевые исследования, лабораторные исследования и оборудование, камеральная геология, сметные расчеты и формирование отчетных документов.

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

Например, функциональный блок «Проведение полевых работ» — мобильное приложение для Android-смартфонов и планшетов, в котором UX и UI адаптированы под защищенные устройства и работу в перчатках. С его помощью сотрудники организации, работающие «в поле», получают информацию о заказах, плановых объёмах работ, список скважин и всю информацию о выбранных скважинах. Находясь на участке, они фиксируют интервалы, уровень грунтовых вод, пробы, испытания по пробам и выполненные работы.

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

Другой пример кастомизации – функциональный блок «Лабораторные исследования». Он помогает автоматизировать работу с испытаниями физических и химических свойств грунтов в строгом соответствии с ГОСТ и другими стандартами. В модуле можно вести назначения на исследования, формировать журналы, ведомости и протоколы.

При этом сотрудники могут без навыков программирования настраивать шаблоны печатных форм. Отдельная ценность – прямая интеграция с лабораторным оборудованием (например, весами Mettler и «Госметр», приборами одноплоскостного среза Giesa, Лига и Geomation, и с другими видами оборудования). Она позволяет без ручного ввода переносить результаты измерений в систему.

Открытый контур: как устроена работа с внешними подрядчиками

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

Именно за счет модульности архитектуры и открытых API взаимодействие с подрядчиками в «Эпике» переводится в полностью цифровой формат. Им больше не нужно присылать результаты в виде разрозненных PDF-отчетов или таблиц Excel, которые потом кто-то в головной компании вручную переносит в основную базу (рискуя при этом допустить ошибку).

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

Ролевая модель гарантирует, что подрядчик увидит в системе и сможет изменить только те данные скважин, которые относятся к зоне его ответственности. Доступ к остальной конфиденциальной информации закрыт.

Почему именно «Эпик»: единая версия данных и сохранение наработок

Преимуществ такого подхода в процессе инженерно-геологических изысканий несколько:

Непротиворечивость и целостность данных

В традиционной схеме полевые специалисты, эксперты лаборатории и камеральные геологи работают изолированно, обмениваясь файлами и выгрузками. В экосистеме «Эпик» они взаимодействуют в едином информационном пространстве.

Например, проба, взятая в процессе полевого бурения, фиксируется в функциональном блоке «Проведение полевых работ» и становится для данных отправной точкой. В функциональном блоке «Лабораторные исследования» не создают новую запись, а находят исходную пробу в цифровом виде и добавляют свои свойства (результаты тестов на сдавливание, сдвиг, испытания по влажности, пластичность и т.п.). Система контролирует права: лаборатория не может изменить исходные полевые данные, только дополнить их результатами тестов.
Камеральные геологи работают с опорой на протоколы лабораторных исследований. Специалист может вносить интерпретации и запрашивать уточнения, но базовая объективная информация остается неизменной. В результате, все участники процесса видят единую версию данных, а ошибки дублирования сводятся к нулю. С точки зрения пользователя, это может выглядеть как работа в трех разных интерфейсах (мобильном приложении, программе на C++ или веб-клиенте), но под капотом все они обращаются к единой структуре хранения.

Сохранение технических наработок заказчика

Код для лабораторных расчетов, алгоритмы кодирования грунтов в понятиях классификатора грунтов, плагины для САПР или графические модули, макросы и SQL-скрипты для подготовки отчетных форм, которые компании развивали десятилетиями, переписать с нуля сложно и экономически нецелесообразно. Практика показывает, что крупные тресты могут годами искать альтернативу старому софту, но не находят решений, которые обеспечили бы то же качество и точность.
Это особенно актуально в отношении наукоемкого софта, написанного специалистами-предметниками. В отличии от стандартных офисных или интеграционных задач «в два счета» мигрировать это приложение на современный технологический стек не получится. Еще сложнее убедиться, что после миграции новый код функционирует в точности как старый.
В «Эпик» старый код переводится на работу с API. Пользователи продолжают рисовать геологические разрезы в привычном интерфейсе MicroStation или AutoCAD, но программа сохраняет результаты их работ в единое информационное пространство.
Типичный пример: заказчик ставит цель уйти от использования СУБД Oracle, но при этом сохранить команду внутренней разработки и написанную ими сложную математическую логику. После внедрения «Эпик» бизнес-логика остается у заказчика, разработчики продолжают писать код на привычных языках, но переводят его с локальных баз на единое хранилище. Эти же структурированные данные напрямую используются для формирования управленческих дашбордов (BI) для руководства.

Гибкость

Архитектура решения работает как Enterprise-конструктор. Если компания планировала использовать встроенные средства формирования отчетов, но позже решила внедрить собственный мощный BI-инструмент, заказчик сможет безболезненно заменить модуль. «Эпик» позволяет подстроиться под меняющийся ИТ-ландшафт заказчика и не навязывает жесткий стек.

Информационная безопасность и производительность

Безопасность проектируется с учетом модели угроз, требований регуляторов и локальных нормативов заказчика. Платформа поддерживает ролевое управление доступом, интеграцию с Keycloak или Active Directory, журналирование, аудит и мониторинг действий пользователей. Код проверяется на уязвимости, а разработка ведется по принципам безопасного жизненного цикла ПО.

Кому подходит решение

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

Узнать больше о возможностях «Эпик» можно на сайте разработчика.