Подальфы ​

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что уровня контроля не хватает, и нужно внимание к частям ситуации, определяемой альфой. Подальфа --- это просто альфа, связанная с другой альфой отношением «если состояние подальфы продвигается, то и состояние надальфы продвигается». Более того, у каждой альфы (в том числе у подальф) могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе (прежде всего тут нужно указать на разработки Ivar Jacobson International, они предложили наборы альф с их состояниями и контрольные вопросы этих состояний для самых разных практик, особенно для гибких методологий^[1]).

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

• Признан --- обоснование аутсорсинга есть; концепция использования для подсистемы есть; ожидания к гарантийному обслуживанию и ремонтным работам есть; понимание по технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.
• Выбран --- технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.
• Привлечён --- валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.
• Работы идут --- надзор за работами установлен; запросы обеих сторон учитываются; запросы обеих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.
• Работы приняты --- уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписаны; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.
• Работы закрыты --- акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

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

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

По всем проблемам, обнаруженным в ходе рассмотрения состояния альф как чеклиста, планируются решающие эти проблемы работы и им выделяются ресурсы в соответствии с принятой практикой управления работами (например, для документирования заданий на эти работы используется трекер, а для запуска в работу практика TameFlow). Затем эти работы будут двигать состояния всех альф в их взаимосвязи в направлении к успешному завершению проекта, а новые проблемы будут своевременно выявляться опять же с применением системной схемы проекта.

Например, если для альфы подрядчик работы приняты (предпоследнее состояние альфы), то работы закрыты (последнее состояние альфы) будут только после подписания акта приёмки-сдачи (первый вопрос чеклиста). Порождаем задание подписать акт, записываем его в трекер как task/задачу/работу, назначаем кого-то выполнить эту задачу. Эта работа не будет забыта, это управление вниманием. В этом и смысл использования системной схемы проекта, отслеживания состояний альф и подальф, прохождения чеклистов для этих состояний. А откуда берутся альфы верхнего уровня? Из системного мышления: что скрывается за этими альфами, подробно обсуждалось в наших курсах на сотнях страниц. Системное мышление занимается управлением вниманием в сложных проектах, меняющих физический мир.

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

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

Цифровые двойники/digital twins --- информационные/цифровые модели систем (физические двойники/воплощения системы), существующие на всём протяжении их жизненного цикла, особенно включая эксплуатацию.

Если поднимемся на системный уровень от цифрового двойника выше, то получим сеть цифровых двойников/digital twins network. Если пройдём на уровень ниже, то получим как целый ряд моделей по самым разным методам описания/viewpoints на стадии эксплуатации (это особо подчёркивается по сравнению с PLM-моделями, часто не доходящими до эксплуатации), так и целый ряд моделей на более ранних стадиях жизненного цикла (разработка, обоснование, наладка, ввод в эксплуатацию): все эти механические, электрические, тепловые и прочие модели.

Цифровая нить/digital thread --- это технология (инструменты и практика федерирования-объединения-интеграции данных, обычно на основе так называемых семантических моделей данных/semantic data models, которых довольно много в инженерии), связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. Инженер старой закалки скажет «интеграция данных жизненного цикла» и помянет множество PLM (а если это не машиностроение, то помянет «корпоративную шину данных»), менеджер новой закалки скажет «цифровая нить» и помянет PLM, ERP, EAM и даже CRM (и вообще всё остальное). И, поскольку «цифровой --- это новый информационный», то заметят, что для какого-нибудь здания или моста кроме BIM (building information model) цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь искусственный интеллект обнаружения аномалий для ремонта по состоянию. Инженеры старой закалки продолжают говорить «управление информацией» или «управление данными», их язык «цифровой нити» не увлекает, хотя менеджерам эта метафора очень нравится.

Так, если нужно сшить между собой мультифизическую модель (модели нескольких физик --- механическую модель, электрическую модель, тепловую модель, акустическую модель и т.д.), то инженеры будут говорить управление данными имитационного моделирования/SMD/simulation data management, а менеджеры старой закалки предпочтут говорить управление информацией (имитационного/мультифизичного) моделирования/simulation information management (но говорят так довольно редко, менеджеры до этих тонкостей уже не доходят, они больше про «нить»).

Цифровая инженерия/digital engineering --- это создание цифрового двойника путём сплетения цифровой нитью различных его моделей, экземпляра его физического двойника и цифровых двойников окружения. Цифровой инженерией занимается цифровой инженер/digital engineer, причём знания цифрового инженера::роль должны быть настолько широки (вся просто инженерия и всё просто айти), что его оргроль часто выполняется обычно командами/оргзвеньями из нескольких человек, и часто коллективами из многих оргзвеньями. Ещё один синоним для цифровой инженерии: моделеориентированная инженерия/MBE (model-basedengineering).

Современные инженерные проекты растут в сложности, число одновременно удерживаемых объектов внимания в них растёт, простые формализации становятся сложнее. Это означает, что число подальф растёт, и для удержания всех их во внимании нужно использовать экзокортекс: самые разные компьютерные модели.

Цифровые двойники^[2] и цифровые нити^[3] оказались очень удобным способом говорить о системном моделировании. Из инженерии этот подход перешёл в самые разные другие предметные области (в медицине речь идёт о цифровом двойнике пациента, в педагогике о цифровом двойнике студента, и так далее). Концепция настолько прижилась, что кроме киберфизических систем говорят о цифровых двойниках безмасштабно: для всех видов систем (вещество, киберфизические системы, существо, личность, организация, сообщество, общество, человечество).

Основная мысль: отслеживайте состояния этих моделей, отслеживайте ход моделирования, для этого используйте подальфы описания системы, и работайте с этими подальфами письменно --- ведите изменение их состояний в каком-то универсальном моделере, а работы по изменению этих подальф (достижение какими-то моделями цифрового двойника тех или иных состояний) ведите в issue tracker. Вы наверняка и так это делаете, но главная мысль тут --- обо всех этих подальфах думать нужно абсолютно одинаково, действовать по их поводу нужно абсолютно одинаково (по крайней мере на уровне мета-мета-модели. Уже на уровне мета-модели там все слова будут разные, но вас не должно это смущать).