Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Федерирование инженерных информационных систем разных стадий жизненного цикла

Обычно при необходимости федерировать данные информационных систем разных стадий жизненного цикла оборудования крупного инженерного проекта (например, PLM стадии проектирования с ERP стадии сооружения, а далее с EAM стадии эксплуатации) рассматривается только "передача проектной информации". Даже если сказать "передача данных жизненного цикла" (data handover), то обычно думают, что это "данные о структуре или документах целевой системы", но никак не "данные обеспечивающией системы по поводу целевой системы" (например, issues с ценной дискуссией по принятым техническим решениям и их основаниям, указаний на то, кто конкретно разрабатывал то или иное техническое решение).

Часть этих "данных по поводу проекта" (но не прямо "проектных данных") можно будет обсудить как «метаданные» (о разработчиках, например), но вот все эти issues, исторические данные по трудозатратам времени на разработку (для определения velocity и последующей оценки трудоёмкости модернизаций или ведения аналогичных работ) и т.д.. в дискуссию о метаданных не попадут. И опять мы останемся только с традиционными геометрией, P&ID для process plants и отчасти информацией каталога, но без управления конфигурацией – с соответствующими последствиями для конфигурации.

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

1. Используется ли онтология, корректно работающая с понятием система? Ппри проектировании речь идёт о функциональных объектах, закупаются физические объекты, эксплуатируютсяя физические объекты в функциональных позициях, нормализация данных должна быть доведена до 6й нормальной формы, т.е. нужна работа с 4D представлением проходящих по жизненному циклу объектов. Подробнее -- http://dot15926.livejournal.com/39300.html, когда успех "простой семантической интеграции", или MDM проекта, или "внедрения PLM-сервера" для информационных систем инженерной поддержки одной стадии жизненного цикла целевой системы пытаются закрепить прихватом систем другой стадии, и нарываются на потерю управления конфигурацией целевой системы. Этот чекпойнт как раз про предотвращает эти проблемы с управлением конфигурацией.

2. Предусмотрено ли управление конфигурацией и изменениями справочных данных (а не только проектных данных). Справочные данные тоже должны версионироваться, для них должны вестись issues, должна поддерживаться методология их разработки. Эту методологию и поддерживающие её инструменты нужно предъявить (гордо укажу на нашу "Методологию инженерии справочных данных ISO 15926 v.3" (http://techinvestlab.ru/files/RefDataEngenEnglish/RefDataEngen_ver_3_English.doc) и поддерживающий её софт .15926 Editor (http://techinvestlab.ru/dot15926Editor), разработанную последовательность чтения для образования (http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/).

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

3. Предусмотрена ли штатная передача не только проектных данных, но и справочных данных (классификаторов и справочников) для целевой системы? Ибо без контекста справочных данных проектные данные обычно невозможно использовать. В наших проектах это традиционная ошибка: систему, куда передают информацию, сначала долго-долго "на коленке", внештатно настраивают (переносят классификаторы и справочники -- однократно), а затем начинают передавать туда проектные данные. И тут выясняется, что при шевелении справочных данных в исходной системе интеграция разваливается: нужно как-то опять "на коленке", внештатно, внерегламентно производить "настройку" целевой системы -- корректировать эти классификаторы и справочники. Для того, чтобы передачу справочных данных было делать легко, нужно предусматривать class of class конструкцию (классификацию отношений классификации) в справочных данных. Иначе будут проблемы с управлением конфигурацией в условиях использования множества классификаторов (а их всегда много -- на разных стадиях жизненного цикла используются обычно разные классификаторы для по-разному определённых объектов, которые объединяются механизмом совмещения во времени их целых темпоральных частей).

4. Сколько времени проходит такт передачи данных? Опыт показывает, что медленная работа обычно оказывается для всех большим сюрпризом. Тут нужно задать вопрос заказчику: есть ли наборы данных, которые должны быть федерированы? Сначала для заказчика является откровением, что для интеграции данных нужно иметь какие-то образцы данных с самого начала проекта (а не в самом конце, как ошибочно обычно думает заказчик), а затем исполнитель проекта вдруг обнаруживает, что в данных заказчика есть не только огромное число содержательных проблем (кастом-элементы данных, не предусмотренные никакими предварительно настроенными и отлаженными в других проектах "адаптерами"), но и их просто много, и время передачи данных существенно влияет на организацию рабочих процессов ("нажал кнопочку -- пошёл обедать -- вернулся и проверил" существенно отличается от "нажал кнопочку, проверил, поправил, нажал ещё раз" (в первом случае может даже требоваться создание нового issue для исправления ошибки, во втором случае этого явно делать не нужно).

5. Предусмотрена ли федерация процессов (issue trackers и workflow engines) всех этих PLM (проектирование), ERP (сооружение) и EAM (эксплуатация) систем? Помним, что во всех этих системах хранятся как данные по целевой системе, так и данные по рабочим процессам предпринятия: технически передача данных по процессам и по целевой системе абсолютно одинаковы, просто никто не вспоминает, что любая передача информации подразумевает какое-то рабочее взаимодействие в части процессов, эти процессы нужно отмоделировать и передачу "эстафетной палочки" в сквозном процессе (workflow travesal) поддержать софтом -- http://ailev.livejournal.com/977531.html. Надо помнить, что любая "приёмка-сдача" происходит отнюдь не одномоментно (иногда и полгода, а подготовка к этому происходит много раньше -- стадии это только стадии, а вот практики жизненного цикла выполняются в ходе всего инженерного проекта) и данные в этот период времени ходят в самые разные стороны между информационными системами, сопровождаемые созданием и закрытием issue в них всех.

6. Кто ответственен за федерирование данных между стадиями жизненного цикла: как решается конфликт интересов? Интересы вендоров софта, подрядчиков проектирования и сооружения не совпадают с интересами собственника/эксплуатирующей организации (owner-operator), и успех всех крупных интеграционных/федерационных проектов, затрагивающих стадии жизненного цикла гарантируется только при очень жестком надзоре со стороны owner-operator. Это единственная по-настоящему заинтересованная сторона, остальные по совокупности причин заинтересованы в саботаже федерирования инженерных информационных систем разных подрядчиков, разных вендоров софта, разных подразделений одного даже подрядчика, которые работают на поддержке разных стадий жизненного цикла (проектировании, сооружении, эксплуатации). Это не техническое требование, но прохождение этого чекпойнта иногда потруднее, чем реализация сложного технического проекта. Если чекпойнт не проходится, то проект превращается в ИБД (имитацию бурной деятельности), реального федерирования систем не происходит -- дело ограничивается демонстрациями успешности на тестовых данных, а до промышленной эксплуатации в реальных инженерных проектах дело не доходит по совокупности причин. Часть этого вопроса -- кадровая: сотрудники каких организаций владеют интеграционным/федерационным ноу-хау, как это ноу-хау попадает в другие проекты owner-operator, что происходит в момент, когда заканчиваются контракты (кто и как вносит изменения в справочные данные, мэппинги и т.д.).

Конечно, все эти чекпойнты сейчас нельзя "купить" в виде готового решения. Решение, которое пройдёт удовлетворительно через все эти вопросы, потребуется разрабатывать (в том числе долго готовить организационно - не всё закрывается разработкой софта, справочных данных и мэппингов). Тем самым эти "чекпойнты" нужно по-хорошему было бы переописать (в соответствии с Основами -- http://ailev.livejournal.com/1051048.html) как последовательность альф интеграционного проекта и их промежуточных и конечных состояний, а уж эти состояния описать чекпойнтами более подробно. Ну, и дальше предложить посоревноваться разным поставщикам федерирования/интеграции инженерных информационных систем разных стадий жизненного цикла в предлагаемых ими практиках продвижения этих альф по состояниям от начального до конечного.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments