Анатолий Левенчук - Системное мышление

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

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

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

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

Примером гибридной между «водопадом» крупных работ-стадий и более современной функциональной с практиками схемы является модель жизненного цикла капитального строительства будущего, разработанная консорциумом FIATECH 187 187 http://www.fiatech.org/tech-roadmap (Рис. 7).

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

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

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

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

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

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

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

В ранних версиях жизненного цикла крупных (прежде всего аэрокосмических, традиционных для системной инженерии) проектов гейтов было порядка пятнадцати, и проект надолго останавливался во всех пятнадцати точках для сведения всех отдельных разработок в непротиворечивое и лишённое конфигурационных коллизий целое и последующего просмотра результатов работ стадии независимыми экспертами. По мере осознания того, что водопадная модель с гейтами является утопией, появления компьютерных систем управления конфигурацией и изменениями и уменьшения числа конфигурационных коллизий, перехода к параллельной инженерии, число гейтов сокращалось. В авиации гейтов сначала стало порядка семи, а нынче их всего три, при этом даже не все из них связаны с инженерией: например, решение о сворачивании проекта принимается, когда проектирование зашло уже довольно далеко, но не собран достаточный для уверенности в финансовом успехе проекта пакет предзаказов на новую модель самолёта 188 188 Altfeld, Hans-Henrich. Commercial aircraft projects: managing the development of highly complex products, 2010 .

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

Управление выполнением практик (назначением практик на работы), чтобы получился результат без конфигурационных коллизий – это управление жизненным циклом(lifecycle management). Управление работами(operation management, управление операциями) заключается не столько в том, какие практики в какой момент выполнения работ выполняется, сколько в управлении выделением ресурсов для прохождения всех контрольных точек в срок и в соответствии с бюджетом. Управление жизненным циклом рассматривается как преимущественно инженерная дисциплина (нужно хорошо знать практики инженерной работы), управление работами как менеджерская дисциплина (нужно хорошо знать практики операционного менеджмента).