Привет друзья! Как можно было понять из заголовка статьи, речь пойдёт об управлении инженерными данными.  Цель - дать общий взгляд под новым углом. Статья выполнена по канонам постмодерна, пестрит отсылками и будет не только полезной, но и занимательной, коей и стоит быть статье на Хабре. Приведу реальные кейсы, в нужных местах дам определения и сошлюсь на стандарты, где уместно.

Интернет, в лице одного из GPT-ботов даёт следующее определение: Инженерные данные — структурированная цифровая информация в электронном виде, которая используется в процессе проектирования, разработки и производства инженерных систем и изделий...

Объект данных – квант информации, который состоит из идентификатора и значений параметров. Объект данных обозначает реальный или абстрактный объект физического мира, в этом и есть его смысл. Так, на пример, 3D модель – это набор структурированных инженерных данных, содержит уникально идентифицированные объекты, с перечнем свойств, часть из которых передают пространственное расположение и геометрическую форму объектов. Документ (файл) как таковой, тоже является объектом данных: у него есть идентификатор и перечень метаданных, описывающих его свойства. Однако сама техническая информация сконцентрирована не в заголовке файла, а в массиве файла. Если этот документ не таблица или база данных (БД) – то техническая информация в нём может быть отнесена к неструктурированным данным, хотя сам документ может при этом оставаться объектом данных.       

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

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

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

*На самом деле, здесь велико влияние вендора софта, в котором будут использоваться или генерироваться инженерные данные, а также стадия жизненного цикла объекта и отрасль.           

В чём нужда человечества в цифровых инженерных данных?

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

Уточним вопрос: «В чем потребность именно в цифровых инженерных данных и в чем их преимущество?». Далее, употребляя «инженерные данные», имею в виду их цифровой вид.

При обсуждении тем близких к цифровизации инвестиционных проектов капитального строительства постулируется:

• превосходство процессов на основе инженерных данных по сравнению с любыми другими;

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

• и вообще, инженерные данные – это цифровой актив, «новая нефть».   

И здесь кроются три неприятных новости:

• все нужно считать, в некоторых случаях цифровые процессы мы просто можем себе позволить, хотя они затратнее, чем альтернативные – бумажные;

• преимущество — это когда что-то выделяет тебя над другими. Так что, если ты не пионер, который рискнул внедрить новую прорывную технологию, то скорее всего ты просто пытаешься как все, не отстать от среднего темпа прогресса и за спиной у тебя лангольеры;

  

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

Дело в том, что цифровизация достаточно давно не ноу-хау, есть кейсы удачного и иногда поражающе эффективного применения цифровых данных. Вообще, состав и приоритеты мероприятий в рамках цифровой трансформации сильно зависят от того, где конкретная компания находится сейчас: «в чём сила, брат?», «в чем слабость, брат?» и так далее по SWOT.

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

В порядке анализа чужого опыта.

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

На масштабах становится понятно, инженерные данные могут дать преимущества в четырёх условных направлениях:

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

• Эффект: улучшение влияния на внутренние возмущения. Источник эффекта - полнота данных. Полнота инженерных данных способна уменьшить операционные или капитальные затраты. Непрерывные улучшения* пропорциональны полноте знаний об объекте улучшения. Если что-то хуже, чем могло быть – очень вероятно мы об этом не знали или не придавали значение важности этого. Как пример, плотность мероприятий по обслуживанию активов может быть выше, чем должна быть, пока мы не соберём достаточно данных о вероятности отказа актива, стоимости его простоя и ремонта.

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

• Эффект: улучшение влияние на внешние возмущения. Источник эффекта – интеграция данных.  Перефразировав классика, можно сказать: «Данные должны течь^**».  Дело в том, что у данных есть стоимость владения, скорость сбора и передачи, а у человека есть физиологические ограничения на объём воспринимаемых данных. Из-за совокупности этих причин только 2% информации от возможного объёма вовлекается в принятие решений. Цель строительства заводов и фабрик приносить хозяевам выгоду за счёт удовлетворения потребности рынка в продукции и уже в следующую очередь создавать рабочие места для избирателей. Потребности рынка меняются со временем, а марки товаров конкурируют между собой. Корпорация, которая полнее обеспечивает надёжными и своевременными данными процессы принятия решений - точнее и чётче формулирует сбалансированные цели и критерии их достижения для каждого звена цепочки добавленной стоимости. Для того, чтобы совершать конкурентные манёвры - необходимо, чтобы производство слушалось штурвала, а на капитанском мостике были необходимые приборы^***. Интеграция инженерных данных в рамках компании или отрасли позволяет вовлечь больше данных в анализ и принятие решений, чаще измерять обратную связь, давая представление об отклонении, повысить утилизацию данных, увеличив выгоду от вложенных для сбора данных ресурсов.  

* непрерывные улучшения или (Continuous Improvement) — это философия, методология и практика, направленные на постоянное совершенствование процессов, продуктов или услуг.       

** отсылка к «spice must flow»- фраза из одноименной экранизации романа Френка Херберта «Дюна».

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

Разнообразие — это не всегда круто

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

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

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

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

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

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

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

Современный подход к решению задач непрерывного сбора и управления инженерными данными – построение Системы Управления Инженерными Данными (СУИД) на основе софта какого-либо из вендоров, сопоставимого задаче, и интеграция со смежными системами. При чём СУИД выполняет не только роль сбора данных от систем-источников и передачу их после обработки в системы-потребители и пользователям, но и диктует единый подход в управлении данными, а также предоставляет инструменты для эффективного управления данными на основе правил. Если что, такую систему можно построить на основе продукта Bimeister Data, в разработке функций которой вместе с командой нашего стрима я участвую.       

Я хотел обратить внимание ещё на несколько аспектов и дать пояснение.  

Инженерные данные могут двигаться в трёх измерениях, что необходимо отразить на диаграммах при проработке системы:

• по этапам жизненного цикла;

• между инженерными системами;

• между юридическими лицами.

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

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

• способом интеграции (файл, шина, API, …)

• категорией данных (изображение, данные реального времени, таблицы, …)

• форматом данных в источнике (avi, bmp, pdf, …)

• структурой данных (формат полей, порядок свойств, диапазоны значений, …)

• объёмом пакета передачи и частотой передачи...

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

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

Примером возможных этапов аналитического проекта может служить методология
CRISP-DM^** или другая похожая. Несмотря на то, что методология изначально разработана для Data Science общие подходы вполне применимы и для структурированных инженерных данных, так как инженерные данные также нуждаться в анализе, консолидации, форматировании, классификации и связывании. Аналитический проект должен позволить выявить закономерности, по которым в СУИД будут выстроены правила автоматизированного сбора данных.

Собственно, аналитический проект, решает задачи, которые позволяют в последствии устанавливать непрерывную интеграцию:

• создание (восстановление по семплу данных) информационного стандарта;

• классификация и/или сопоставление классифицированных данных;

• проработка и отладка алгоритмов преобразования данных при передаче;

• извлечение или генерация метаданных.

Чтобы было понятно, отметим пару особенностей инженерных данных:

• Наследственность. Важной особенностью инженерных данных является необходимость обеспечения наследственности или сквозной трассировки.
  В процессе сбора мы передаём данные в виде объектов с их свойствами. Как правило, при получении объекта данных в пункте назначения нам важно знать какому объекту данных это соответствует в источнике.

• Изменчивость. Объекты данных, в рамках потребности различных систем в процессе жизни и передачи могут менять свои границы (объединяться, делиться), менять атрибутивную полноту (наличие атрибута и его заполненность), порождаться (был атрибут объекта данных – стал самостоятельным объектом), схлопываться (был объект – стал атрибутом другого объекта).

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

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

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

Изменчивость данных – это вопрос энтропии информации. Если нам не нужно, чтобы информация об объекте терялась при передаче из источников в СУИД и далее в потребители – нам нужно обеспечить избыточность кодов и свойств объектов, Клод Шеннон вам в помощь. В рамках аналитического проекта это должно быть учтено, как в правилах кодирования объектов, так и процедурах сбора данных.

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

Связи между объектами также являются значимыми инженерными данными наряду со значениями свойств самого объекта. Связи могут присутствовать в источнике в явном виде: «объект один – связь – объект два». Также связи могут передаваться в виде свойств объекта или упоминании кода объекта в неструктурированном источнике.     

* приводятся данные об увеличении производительности труда проектировщиков порядка 15%. Внедрение цифровых средств проектирования окупается на сопоставимых решению масштабах проекта. Кроме того, эффект начинает ощущаться после освоения новых средств проектирования персоналом и выстраивания адекватных новым средствам бизнес-процессов. Инвестиционная фаза может достигать порядка 5 лет и не укладываться в длительность одного пилотного проекта.

**CRISP-DM - CRoss Industry Standard Process for Data Mining (CRISP-DM) – стандарт, описывающий общие процессы и подходы к аналитике данных, используемые в промышленных data-mining проектах независимо от конкретной задачи и индустрии.   

Построй свою тиранию

Управление информацией — это не только решение математических и инженерных задачек, связанных со сбором, обработкой и передачей данных. Это ещё и решение задач по приведению внутренних и внешних поставщиков и потребителей инженерных данных к единым требованиям. И труд этот титанический.

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

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

Идея информационного стандарта проста:

• привести все охваченные сквозным интеграционным бизнес-процессом модули к единому языку и сократить затраты на преобразование данных;

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

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

Корпоративный информационный стандарт в зависимости от содержания может решать следующие задачи:

• технической совместимости данных из различных систем - то есть содержать требования к модели данных, типам данным, классификации данных и связям;

• сквозной трассируемости объектов данных – то есть содержать требования и процедуры к именованию объектов и документов, обеспечивающих уникальную идентификацию;

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

Информационный стандарт может меняться по мере необходимости. Важно закрепить в системе за одним из модулей функцию централизованного источника информационного стандарта. Как вариант интеграции на базе СУИД: запрос на изменение объектной модели допустим из любого модуля, но согласование изменения происходит только в модуле СУИД, после чего объектная модель или дельта раздаётся во все модули системы.

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

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

СУИД от компании Бимэйстер в состоянии решать эти задачи, осуществляя передачу по интеграционным потокам объектов данных и требований к данным в виде сущностей объектной модели. Требования к данным, воплощённые в объектной модели и бизнес-правилах позволяют проводить проверку данных на корректность и полноту с расширением СУИД Bimeister Standart. 

Требования стандарта жёстко диктуют правила, по которым осуществляется управление данными. Это форменная диктатура с выкручиванием рук подрядчикам. Однако, отступления от требований к данным будут создавать исключения и ограничивать глубину автоматизированной проверки  – то есть за системой придётся допроверять вручную. 

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

Отмечу, что поиск источников данных и закрепление обязанностей поставщиков и потребителей данных в отношении требований к данным и соблюдения процедур управления данными – это тоже круг обязанностей информационного менеджера. Используя логику максимального переиспользования однажды введённых данных, информационный менеджер может нагрузить такими обязательствами, к примеру, поставщика оборудования. Да, это увеличит нагрузку конкретного поставщика, которую он постарается переложить в стоимость договора, но это снизит необходимость ручного ввода данных в системе в целом = profit.

В идеальной картине мира проверка данных осуществляется один раз – и только там, где осуществляется ручной ввод, ведь требования к данным везде едины. По факту, такой тесной интеграции модулей добиться очень сложно: разные вендоры программных продуктов, использующихся для модулей системы, разные субъекты или юридические лица управляют модулями системы, модули существенно разнесены во времени - проектирование выполнено за 10 лет до создания системы сбора инженерных данных. По этим причинам на практике создают систему с единым окном сбора данных в виде СУИД, куда направляют данные из всех источников, проверяют их, в том числе сопоставлением и после этого раздают потребителям данных. В случае сбора данных проектных решений, с учётом текущего развития технологий, невозможно исключить необходимость хотя бы выборочной ручной проверки. Однако, сократить её объём на 90% - реально.

Попробую пояснить на гипотетическом примере как это вообще работает:

Шаг 0. В рамках проекта капитального строительства интегрированный с системой автоматизированного проектирования СУИД передаёт модель данных; диапазон кодов оборудования проекта, справочники. В объектной модели зашифрованы ограничения на диапазон значений свойств оборудования, взятые из строительных норм и правил, которые могут быть использованы при вводе инженерных данных. Там, где мы не можем проверить правильность технического решения по контролю значения свойства объекта, ещё на этапе исследовательского проекта мы предусмотрели генерацию в модулях-источниках метаданных, которые позволят проверить: правильным ли бизнес-процессом были приняты проектные решения. В объектной модели сформулированы требования, которые могут быть использованы для контроля полноты данных.       

Шаг 1. В рамках приёмки проектных решений мы получили пакет данных, включающий набор документов и запись, скажем, об оборудовании «40-20-XR-TI-046A». Положим, по правилам кодирования первые два блока кода оборудования — это номер установки и блока установки, а следующий блок – это код системы, в которой оборудование установлено. Четвертый блок, где записано «TI» по соглашению о кодировании является функциональным признаком и кодом класса этого оборудования. Используя маску кода для класса оборудования «TI» в виде регулярного выражения, мы можем установить валидность такой записи. Мы можем ожидать что в этом или в другом пакете мы должны получить объекты с кодами «40», «20» и «XR» — это позволит нам построить иерархию, создав между объектами связи типа декомпозиция. Отсутствие этих объектов в пакете может нам говорить о неполноте информации. Так же, опираясь на соглашение о кодировании мы можем установить соответствуют ли коды документов соглашению и каким классам документы принадлежат. Проанализировав полученные документы с использованием всё той же маски кода, мы можем установить в каких из них встречается упоминание нашего объекта и установить связи этого объекта с такими документами. Наличие связи оборудования со всеми необходимыми документами - также может быть критерием полноты информации.

Шаг 2. Используя ограничения на значения свойств объектов класса «TI», мы контролируем правильность технических решений.        

Шаг 3. Любое несоответствие требованиям или расхождение информации между источниками фиксируется автоматически и направляется в виде готового протокола замечаний обратно в источник для исправления. Ничего руками заполнять не нужно.

Шаг 4. Проводим выборочную ручную проверку данных, которые прошли формальную автоматизированную проверку.  Мы открываем карточку свойств «40-20-XR-TI-046A» переходим по связям к документам и просматриваем их.

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

* CFIHOS (Capital Facilities HandOver Specification) — это стандарт для обмена, интеграции и обработки данных в области проектирования, строительства и эксплуатации промышленных объектов, таких как заводы, нефтегазовые объекты и другие. Он разрабатывается с целью создания единых правил и форматов для описания информации об оборудовании и объектах в промышленности, чтобы облегчить совместное использование данных и обеспечить их стандартизацию.

Образ результата

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

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

Эксперты по управлению инженерными данными формируют правила по представлению данных в универсальном, упрощающем контроль качества и передачу виде.

Доменные эксперты формируют правила контроля данных, позволяющих сократить затраты на ручную проверку соответствия инженерных данных и повысить качество данных.    

Так в чем же выгода

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

• Реакция на внутренние возмущения – инциденты, которые приводят к сбоям в работе оборудования и выпуска продукции, не редки. Не секрет, что просадка в производительности по возможности устраняется за счёт ввода резервов либо за счёт неоптимального форсированного режима работы производства. И то и другое — это потери. Снижение инцидентов, которое может достигать десятки процентов от общего числа, позволит на единицы процентов 1-2% увеличить общую производительность или стабильность выпуска продукции, что приведёт к обоснованному снижению резервов.

• Влияние на внутренние возмущения - увеличение продуктивности труда и повышение оптимальности технологических процессов могут на 10-30% увеличить эффективность фонда оплаты труда инженерно-технических сотрудников, на 2-3% снизить себестоимость потребляемых ресурсов, связанным с переходными технологическими процессами. Основной эффект, конечно же заключается в принципиальном повышении ситуационной осведомлённости и систематическом устранении первопричин инцидентов.

• Реакция на внешние возмущения – любая смена режима предприятия может вызывать просадки в эффективности, что проявляется в перерасходе ресурсов или снижении выпуска продукции. Заявляется об уменьшение операционных издержек на 5% за счёт грамотного использования инженерных данных. Кроме того, приводятся данные об уменьшении стоимости операций с данными. Порядка 5% стоимости проекта — это ввод и обращение данных, этот показатель может быть снижен на 1-2%.

• Влияние на внешние возмущения – общее повышение управляемости и отзывчивости производства на корректировку целевых показателей сказывается увеличением выручки 5%.

Приведу пример, чтобы не было магических представлений откуда берётся увеличение выручки за счёт удачного использования инженерных данных. Так, Saudi Aramco рапортует о дополнительных 150 тысяч долларов выручки за счёт увеличения выхода светлых с каждого миллиона тонн переработанного сырья. Дело в том, что отдельные фракции нефти, как сырьё нефтехимии или косметики на порядок ценнее, чем в виде топлива. Чем больший процент таких фракций мы извлечём и отгрузим как отдельный продукт – тем выше прибыль.

То, о чём приведённые показатели лукаво умалчивают – это скорость выхода на целевые значения. Ориентировочные сроки следующие: для эффектов тактического и оперативного горизонта это месяцы. Как правило 6–12 месяцев. Для эффектов оперативно-стратегического горизонта – это 2–5 лет и более.   

Сегодня мы многое поняли

Подытожим.

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

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

Что касается инженерных данных – то стоимость этого сорта «новой нефти» пропорциональна её вкладу в уменьшение издержек производства на единицу товара или увеличение качества этого товара. Конечная выгода компании сильно зависит от итогов маркетинговой войны.

Спасибо, что дочитали до конца. До новых встреч!