Швейцарский сыр, галстук-бабочка и риски проектов цифровой трансформации
Того, кто не задумывается о далеких трудностях, непременно поджидают близкие неприятности.
Конфуций
Возможно, вы слышали о модели швейцарского сыра, или еще ее называют моделью кумулятивного действия. Она пришла из авиации. Если совсем кратко, то суть этой модели в том, чтобы ставить на пути вероятного происшествия как можно больше преград («ломтиков сыра»). В каждой преграде есть дырки – отдельные упущения и ошибки («дырки в сыре» характерны для швейцарских сыров, отсюда и название) (см.рис.1).
Рис.1 Модель швейцарского сыра
Такие дыры всегда имеются в любой системе на любом уровне – не стоит заблуждаться на этот счет. Но в каждом следующем уровне, каждом ломтике, эти дыры находятся в другом месте. А потому, когда на одном уровне событие проходит в дыру ошибки, на следующем уровне на его пути дыры нет, и это останавливает развитие нежелательного явления. Данный механизм преград защищает всю систему от масштабных инцидентов, которые сложно или даже нельзя устранить. Ведь происшествие станет возможным, только если все упущения или дыры выстроятся в ряд. (см.рис.2)
Рис.2. Иллюстрация из «Руководства по управлению безопасностью полетов» (РУБП) Международной организации гражданской авиации
Модель «галстук-бабочка» – это немного переформулированная идея модели швейцарского сыра. В центре находится событие, которое мы хотим предотвратить. Для этого нам нужно приложить определенные усилия или предусмотреть меры по уменьшению ущерба на случай, если событие все-таки произойдет. То есть, прогнозируя, где можем упасть, мы «соломку подстелем» (рис.3).
Рис.3.Модель «Галстук-бабочка»
Модель «Галстук-бабочка» широко известна, даже входит в стандарт ГОСТ Р ИСО 31000.
Применительно к проекту рассмотрим эту модель следующим образом: с одной стороны, у нас есть дерево угроз, где отмечено, что может пойти не так. А с другой – у нас имеются ограничения, которые должны быть учтены в проекте (см. рис.4)
Рис.4. Применение модели «Галстук-бабочка» для проекта
Сроки, бюджет, удовлетворенность заказчика, надежность и производительность системы – в общем, любые ограничения, фиксируемые при запуске проекта.
И вот мы предполагаем, что может возникнуть некое событие, которое станет причиной того, что мы не впишемся в ограничения. (см.рис.5)
Рис.5. Пример проблемной ситуации в проекте
Элементы системы управления проектом и отдельные специальные меры, предпринятые нами вне системы, и есть те самые преграды, которые стоят на пути возможных происшествий.
Пример из области ИТ-проектов. Один из типовых рисков для всех ИТ-проектов – задержка принятия ключевых решений, в частности, согласования технического задания на систему. Причиной может быть отпуск специалистов, согласующих документы. Получается нужных специалистов нет -> ТЗ вовремя не согласовано –> обязательства перед заказчиком не выполнены –> мы не вписываемся в ограничения по срокам (или начинаем гнать остальные этапы, чтобы все-таки успеть, при этом там появляются свои цепочки рисков).
Но если в рамках выстраивания системы управления проектом мы введем обязательное требование – согласовывать отпуск с проектным менеджером, – то на пути возникнет преграда (которая, заметим, может быть и дырявой – особо наделенные властью согласующие могут просто дружелюбно проигнорировать правило…).
А вот другая распространенная причина проблем с ТЗ – перегрузка сотрудников операционной работой. Риск настолько распространенный, что в пору вводить его в список типовых, обязательных к отработке в любом корпоративном ИТ-проекте.
Ну а теперь к рискам проектов цифровой трансформации. В своей предыдущей статье «Использование модели сложности для управления проектами цифровой трансформации» я показывал, что такие проекты могут быть очень разными: проекты пилотирования содержат одни риски, проекты тиражирования – другие. Список рисков можно взять из представленной в статье модели сложности. А можно – из Интернета. Благо при запросе на английском языке «риски проектов цифровой трансформации» (digital transformation project risks) Google выдает примерно 83 100 000 результатов. При аналогичном запросе на русском примерно 2 500 000 результатов. Есть из чего выбирать.
Мне показался любопытным документ компании Deloitte «Управление рисками цифровой трансформации (Managing Risk in Digital Transformation)». В нем приводится 10 ключевых нет, не рисков, но областей рисков, из которых «прилетают» проблемы для проектов цифровой трансформации.
Анализируя примеры известных мне проблемных проектов цифровой трансформации, могу сказать, что существенная их часть действительно сталкивалась с такими трудностями. Список явно не выглядит исчерпывающим – в частности, в нем в основном перечислены риски технические, не связанные с человеческой стороной изменений. И конечно, упущена одна из главных областей риска для российских проектов цифровой трансформации – сложнозапутанная внутрикорпоративная политика, порождение «византийской» системы управления, но это предмет для отдельной статьи...
Ну а с технической точки зрения список весьма неплох и вполне может быть использован как основа для реестра рисков любого проекта цифровой трансформации. Упражнения по формированию такого реестра и по выбору «ломтиков сыра», предотвращающих подобные риски, предоставляются читателю в качестве самостоятельного упражнения
Опубликовано 01.10.2019
