Системное мышление

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

V-модели как модель декомпозиции системы

Ещё один вариант V-диаграммы показывает декомпозицию системы по системным уровням, определяемым отношениями часть-целое186:

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

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

Общий принцип «соответствие воплощения определению» тут показывается на каждом уровне – собранные и испытанные 4D-индивиды систем/подсистем/элементов каждого уровня удовлетворяют своим определениям.

Как и многие другие диаграммы системного мышления, V-диаграмма подразумевает рекурсивное применение, она применима на каждом системном уровне.

Гибридные модели жизненного цикла

Примером гибридной между «водопадом» крупных работ-стадий и более современной функциональной с практиками схемы является модель жизненного цикла капитального строительства будущего, разработанная консорциумом FIATECH187 (Рис. 7).

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

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

Стадии прекращения использования/вывода из эксплуатации/получения зелёной площадки на диаграмме нет, она отражает не полный жизненный цикл.

Авторам диаграммы для объяснения того, как будет работать обеспечивающая система в капитальном строительстве, явно не хватает упоминания практик. На какой стадии они планируют использовать практику управления проектом? На всех! На какой стадии они будут учитывать практики работы с новыми материалами, методами, оборудованием? На всех! И поэтому авторы диаграммы пририсовывают плашки практик, расположенные по всей длине жизненного цикла.

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

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

Управление работами и управление жизненным циклом

Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии и принималось решение о продолжении проекта на следующей стадии (go/no-go). Если до заранее запланированного рассмотрения проекта независимыми экспертами в рамках прохождения гейта кто-то из разработчиков частей системы не успевал закончить разработку своей части и проверку того, насколько она не нарушает работу всей системы в целом, то весь проект ждал окончания работ этого разработчика. Гейты как раз и были задуманы, чтобы выявить системные риски появления конфигурационных коллизий, неочевидных системных эффектов, непредвиденных трудностей в разработке отдельных частей системы. И если не включить в рассмотрение результаты чьей-то частной работы, то появляется риск неучёта каких-то системных эффектов в целой работе.