Сергей ЕГОРОВ, директор по науке и инновациям группы компаний ASE. Статья подготовлена по материалам выступления на XIV Международном ядерном форуме «Безопасность ядерных технологий». Для того чтобы обеспечить безопасность на всем жизненном цикле объектов использования атомной энергии, которые в силу потенциальной опасности находятся в центре общественного внимания, необходимо четко описать требования и критерии обеспечения безопасности. Возникает задача сформировать представимость и объекта, и процесса его сооружения через артефакты, которые дают возможность измерить культуру безопасности.
Слон выглядит по-разному
Метафора, когда пять слепых пытались рассказать о слоне, и один говорил о ноге, а другой о хоботе – это обыденная ситуация на строительстве сложных объектов. Сложности представляет взаимодействие людей разной культуры, отличающихся подходов и взглядов, уровней образования. По замечанию академика Бочвара, «…структура не в меньшей степени определяет свойства, чем состав». То, как мы представляем (и описываем) объект, в большой степени характеризует тот результат, который мы получим при попытке воспроизведения. Важно обеспечить четкое описание культуры безопасности в системах управления проектом. Это позволяют сделать методы системной инженерии и информационных технологий объектно ориентированного программирования – инструментарий качественного улучшения технологии создания сложных инженерных объектов. Практики системной инженерии (и в частности, аспектный подход) описаны в стандарте ISO/IEC/IEEE 15288. Этот стандарт относится к сфере информационных технологий, хотя в действительности развивает предметные прак
тики в целом: объясняет, как описать договоренности, когда людям сложно договориться, как увязать между собой различные технические и организационные процессы… Словом, как организовать большие и сложные коллективы для достижения единых целей.
Счастливое число семь
Мы берем семь аспектов для описания проекта и выстраиваем соответствующие структуры (bs, Breakdown Structures): аспект «Потребности и Требования» (соответствуют «Требования» (RBS)); «Креативный» аспект (Структура «Участники Проекта» (WMBS)); аспект «Функциональность» (структура «Функциональная» (FBS)); аспект «Объектный» (структура «Объектная» (PBS)); аспект «Реализации проекта» (структура «Работ»(WBS)); аспект «Стоимости проекта» (структура «Затрат» (CBS)) и аспект «Документирование» (структура «Документации» (DBS)). Каждый из этих аспектов подлежит описанию в проекте.
Что касается аспекта «Потребности и Требования», их описание выполняется регулярно на протяжении последних 10–15 лет. Важно отметить, что мы научились отделять «требования» от «потребностей». Креативный аспект очень важен в описании проекта: даже если вы собрали хорошую профессиональную команду, но она не выработала надлежащих культурных ценностей и не коммуникабельна, то и хорошие профессионалы не могут дать ожидаемый результат (это показывает не только наш опыт, но и, например, большой спорт). Участники процесса – это очень важный аспект представлений о проекте. Все другие структуры описания проекта (функциональная, объектная, исполнения работ, декомпозиции затрат и, наконец, документальная) будут порождаться креативным аспектом. Какая бы ни была команда, хорошая или не очень, именно она будет драйвером приведения объекта в рабочее состояние, а остальные аспекты будут отслежены именно в ней.
Аспект функциональности: было отмечено, что «в бизнесе ничего не делается, пока что-то не продается». С этой позиции, пока энергоблок не включен в сеть, остальные действия могут выглядеть бессмысленно, если не учитывается конечная цель – функционирование объекта и его полезная функция. Функциональностью предопределяются поступки и действия, и с ней жестко связан следующий аспект – «Объектный». Мы создаем не виртуальные, а предметные сущности, которые можно ощутить, и они могут представлять опасность для человека. Тем более важно описывать их и воссоздавать правильным образом.
Поскольку объект не возникнет самостоятельно, мы выделяем аспект реализации – это способы реализации деятельностей. Он связан и представлен структурой декомпозиции работ (WBS). Поскольку это стоит денег (а каких-то денег стоит все: материалы, документы, поступки, и грамотный человек с калькулятором, который посчитает все трудочасы и усилия, может предъявить обоснованный счет), возникает структура затрат. Затраты и все процессы документируются (аспект и структура «Документы») – потому что попытки опираться на изустные предания, доверие «на слово» показали: лучше работают печать и подпись. Через документы мы видим артефакты, которые позволяют следить в том числе за культурой безопасности.
Еще один аспект: как описать структуры. Мы используем документы, они состоят из слов. Но, используя одни и те же слова, мы можем иметь в виду самые разные смыслы. Так, по-английски АЭС – это NPP, Nuclear Power Plant. Попытка перевести Plant на русский выдаст нам «растение». И такая потеря смысла случается не только при поспешном переводе. Объекты атомной энергетики базируются на референтном опыте, оплаченном дорогой ценой; это накопленные десятилетиями практики взаимодействия. Эти практики должны заимствоваться (а не переноситься механически) в полном объеме, когда создается новый проект. Если мы вспомнили plant, растение, то используем метафору: новое растение не тождественно своему прародителю, хотя Plant Background Structure переносится, как зерно или черенок, из проекта-аналога. Воспроизводить растения сравнительно легко, но это не будет объект «такой же как референтный»; правильно говорят юмористы: «Точно такой же, только меньше и другой». Если речь об АЭС – на новом блоке скажутся проектные изменения, обстоятельства площадки и пр. Мы пытаемся удерживать подобие, но действительность мешает нам: исходными данными, запросами заказчика, потребностями и требованиями. Их источники – социальный аспект (через законы и нормы – документированные основы требований) и договоренности с клиентом (даже если они не записаны в национальном стандарте, они становятся обязательны, попав в контракт).
Описать взаимодействия можно хоть глиняных табличках (ведь шумеры умели строить достаточно крупные объекты). Но когда поджимает время, люди спешат и сталкиваются с проблемой коммуникаций. Цифровизация взаимодействий, передачи информации на расстояние, технологии доступа порождают такое явление как «информационная модель». Споры о ее сущности еще долго не стихнут; разные люди понимают под информационной моделью и набор документов, и свод цифр, и 3D-визуализации… В принципе, информационной моделью может считаться и картонный макет, особенно если он подписан. В общем смысле под информационной моделью мы понимаем цифровую модель объекта, в которой заложены правила и которая отображает аспекты, представленные вышеперечисленными структурами. Чтобы закрепить это понятие, мы создаем стандарт.
Не может не радовать, что все структуры взаимосвязаны как классы; классы можно объединять, агрегировать, применять требования по инкапсуляции – и получать таким образом нечто, кажущееся понятным. Именно «кажущееся», поскольку понятность зависит от аспекта, с которого мы смотрим на ситуацию. Аспект ли это человека, функции, самого объекта или технологической реализации объекта, финансов, документального описания? Цепочка поставок – это не просто цепочка поставок, а способ достижения результата: когда из совокупности муравьиных усилий, массы различных действий получается задуманное.
Поскольку человек сложнее муравья (попробуй получить одинаковое описание события от разных свидетелей), то в проекте формируется система управления требованиями. Это дает надежду, что полученное от заказчика, регулятора, общества задание мы реализуем четко, и наш результат тоже будет воспринят однозначно. Ведь если задача поставлена «сделайте красиво», а понятия о прекрасном различаются, то получить ожидаемый результат сложно. Нужен предметный, деятельный, параметризованный контекст. Именно тогда будет «красиво», а также «безопасно» и «успешно». Лишь четкая стандартизация позволяет добиться единообразия и в поставках материалов, и в логистике, и в проектировании.
Создаем стандарты
За последние два-три года мы создали для своего понимания процессов два стандарта: стандарт по информационным моделям (что мы хотим наблюдать и как это делать) и стандарт организационно-ролевого подхода (роли и взимоотношения в реализации объекта). Организационные трансляции, требования к подрядчикам и принципы, основанные на функционально-ролевой модели, – все это подходы, которые мы исповедуем для реализации больших проектов за пределами страны.
Возвращаясь к вопросу о рациональных ожиданиях и действительности: есть заблуждение, в том числе в давно сложившихся профессиональных командах, полагать, что сложившиеся взаимодействия – результат написанных ими (или полученных извне) документов. На самом деле это результат труда, договоренностей, формирования культуры. Если эта команда разойдется за пределы проекта или перейдет в другой, то успех не гарантирован, пока не выстроится новая культура. В этом смысле квартет может быть плох не потому, что слабы музыканты, но и по причине неправильной рассадки. Получается, что организационная функционально-ролевая модель (ФРМ) – важнейший инструмент. Исполнителей мы подбираем по сложным комплексным процедурам, а как в действительности распределятся роли, показывает последующая работа.
Важно, чтобы требования не формулировались как «пожелания». Они должны с точностью пояснять, что такое «красиво» в общепринятом понимании. Наследование задач от одного подрядчика к другому порождает проблему договоренностей; кросс-процедура передачи требований очень сложна. Вы заключили контракт и взяли обязательства, но не советовались с подрядчиком, которого нанимаете, и это (по его мнению) не дает позволяет транслировать ему требования в полном объеме. Чтобы не впадать в цейтнот и компромиссы, важно договариваться на берегу, от генерального подрядчика к последнему субподрядчику.
Итак, требования проистекают из норм и договоренностей; они выполняются посредством исполнения работ, работы стоят затрат, они документированы и направлены на создание материальных объектов и процессов создания продукции. В этой взаимосвязи есть некое подобие технологии блокчейна, когда связи между различными сущностями фиксируются и наследуются. Создаваемая таким образом семантическая модель позволяет воспроизводить процесс в целостном состоянии и с достойным результатом. Это полезно, когда планируется построить не один, а десятки энергоблоков. Воспроизводство получившегося успеха – очень полезное знание, важнейшая часть реализуемости объекта и важная часть культуры безопасности.
Аспектно-ориентированный подход является практическим методом формирования информационного ландшафта любого проекта сооружения АЭС. Формирование структур проекта важно ориентировать на требования, включая отображенный ими аспект культуры безопасности, и получать трассировку их реализации во всех аспектах проекта: если что-то упущено, то не будут достигнуты цели. И наконец, аспект культуры безопасности гармонично отображается в доступных структурах инженерных данных, ролях и связях при управлении проектами сооружения АЭС.
Алексей Комольцев для журнала РЭА
