Сценарий организационного провала ИТ‑функции. Хроника предсказуемой катастрофы

Что происходит:
Бизнес принимает решение запустить проект/инициативу/направление. Условия благоприятные: есть подходящая рыночная конъюнктура, у компании есть финансовый «жирок», есть хайповое направление или технология.

Запускается и реализуется пилотный проект для проверки рыночных и организационных гипотез. Результаты пилота хорошие, он коммерчески успешен. Эффективность ИТ‑функции бешеная — «на грош купили пятаков», появляется кураж. Бизнесом принимается решение развивать пилот дальше, сохраняя набранный темп.

Именно здесь, после успешной реализации пилота, находится точка бифуркации сценария. Если пилот далее масштабируется не так как описано, то последующие этапы или не наступают, или наступают, но в иной конфигурации и не с таким фатальными последствиями.
Однако компании, почему‑то, сворачивают не туда. Почему — мы обсудим в выводах, а пока — продолжаем наслаждаться.

Домен Cynefin: Complex

Применяемые методы:

• Технические и коммерческие эксперименты, быстрые проверки гипотез;

• Минимальная управленческая надстройка, минимум формализации, высокая адаптивность и изменчивость, используются вариации Agile, Scrum;

• Немногочисленная, горизонтальная, квалифицированная, универсальная и дорогая SpecOps команда;

Организационные проблемы:

• В явном виде отсутствуют

Что происходит:
Пилот хотят масштабировать не теряя темпа. Есть успех, кураж, амбиции и средства. Будущие результаты (разумеется, хорошие) уже заложены в бизнес‑планы следующего периода. Остается только сделать.

Как получить больше результата? Ответ кажется очевидным — нужно масштабироваться, нужно увеличить количество сотрудников: больше работников → больше делаем / быстрее делаем → PROFIT.

Этот подход поддерживается, так как амбиции и планы бизнес‑функции ограничиваются, как тогда кажется, только недостатком ресурсов ИТ. Начинается масштабирование ИТ‑функции. Нанимается больше сотрудников в существующие команды, создаются новые команды.
Предыдущий успех и первые шаги масштабирования создают иллюзию: кажется, что воспроизведение успешного подхода позволит сохранить взятый ранее темп и эффективность.

Домен Cynefin: попытка удержаться в Complex, хотя ситуация уже требует перехода в Complicated с дальнейшей эволюцией в Simple. К чему, естественно, никто не готовится, так как концептуально «все хорошо» и есть только «недостаток ресурсов».

Применяемые методы:

• Те же самые, что на этапе «Пилот», с поправкой на горизонтальное расширение;

• Массированный найм, расширение существующих и формирование новых команд;

• Повышение в менеджмент лучших исполнителей.

Организационные проблемы:

• Агрессивные (как по скорости реализации, так и по объему) планы бизнес‑функции, строящиеся на предположениях об условно‑бесконечном развитии в ситуации, когда низко висящие яблоки уже почти все сорваны.

• Массированный и быстрый найм. Берется уже не лучшее, а то что просто есть на рынке. Учитывая тенденции предыдущих лет — в работу брались переоцененные сотрудники существенно худшего качества, которые требуют кратно больших усилий по контролю, управлению и организации, в отличие от SpecOps команды первого набора;

• Распыление управленческого фокуса. Управляющая надстройка хронически перегружена как требуемым темпом и объемом работы, так и количеством и «качеством» новых управляемых объектов. Когнитивный предел превосходится быстро и беспощадно. Структура, фактически, начинает выглядеть так:

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

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

• О таких мелочах как отсутствие документирования, формализации и проектировании процессов, создания и поддержания общих практик и стандартов, распределения зон ответственности я даже не упоминаю. 

Что происходит:
Руководство обнаруживает, что рост эффективности ИТ‑функции сначала замедлился, а потом и вовсе остановился, в то время как от ИТ ожидается продолжения или даже ускорения роста, так как объем вложений постоянно увеличивается.

Возникает разрыв ожиданий. Он вызывает первый пристальный взгляд руководства и бизнеса на функцию. Начинает формироваться понимание, что ИТ‑функция — это черный ящик который работает по непонятному для руководства принципу с непонятным результатом.

Причин разрыва ожиданий может быть две и они могут возникнуть как совместно, так и по отдельности:

• Внутренняя деградация ИТ‑функции — организационный хаос, описанный выше, из‑за которого даже вложения большого объема средств не приводят к ожидаемому росту эффективности;

• Изменение внешнего контекста — средства на постоянную, опережающую, «накачку» средствами ИТ‑функции у бизнеса закончились, так как бизнес‑акела промахнулся или к компании прилетели «черные лебеди»

На этом этапе всем становится понятно, что с эффективностью ИТ — функции есть какие‑то сложности. Однако понимание проблем, зачастую, находится на низком, инструментальном уровне. Способ организации под сомнение не ставится.

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

Домен Cynefin: Фактически система дрейфует из Complex в Chaotic (перегрузка, потеря управляемости), но менеджмент и руководство по‑прежнему цепляется за методы домена Complex. В целом, «всё хорошо, просто надо немного напрячься».

Применяемые методы:

1. Ротация «не справившихся» и выгоревших руководителей на новых;

2. Приглашение консалтеров;

3. Наем «корпоратов»;

4. Формирование «геймчейнджера».

При перечислении методов вводится несколько терминов. Необходимо разъяснить что под ними подразумевается:

Корпораты — что есть «корпорат»? Это человек, который сформировался как сотрудник и/или долгое время проработал в (очень)крупных, зрелых компаниях. У корпората есть подвид — «американец». Это почти тоже самое, только работал он в зарубежных компаниях или их филиалах. Корпораты делятся на три типа:

• Оперативники — те, кто поддерживал, развивал или выстраивал оперативный контур ИТ‑функции. Эти ребята могут помочь. Но только при условии, что руководство им выдает большой мандат доверия и готово идти на конфликт с остальными и начинать перестройку функции (нет). Без этой поддержки, необходимой для перестройки функции, их деятельность и полезность носит ограниченный характер. Изменения блокируют, саботируют, а сами они, в итоге, выгорев, или уходят или плывут по течению.

• Инструменталисты — технические специалисты, хорошо владеющие конкретными инструментами и технологиями. Они привыкли работать в настроенном оперативном контуре, который можно точечно улучшать, внедряя изменения «снизу», «до мышей» разбирая процесс. Но на этом этапе оперативного контура нет. Их погружение в детали и внедрения определенных технологий даёт или ограниченный эффект, не способный переломить общую ситуацию и/или дополнительно нагружает уже перегруженную функцию.

• Коммуникаторы — строят подход на личных связях. Прогрызают коммуникационные тоннели в корпоративном монолите идя от человека к человеку. Имеют какой‑либо смысл только когда вокруг них есть этот самый корпоративный «монолит» с функционирующим оперативным контуром, работу которого нужно ускорить. На этом этапе оперативного контура нет. Но уже есть перегруз большим количеством неупорядоченной и мусорной коммуникации. Дополнительный слой встреч, созвонов, синков только увеличивает эту перегрузку без существенного результата.

Геймчейнджер — Это амбициозный антикризисный проект/инициатива/направление, задача которого снова вывести ИТ‑функцию на прежнюю кривую роста эффективности.
Инициатор этого проекта зависит от того, какой была причина разрыва ожиданий. Если проблема в торможении на стороне ИТ‑функции, то формируется предложение, зачастую техническое. Прорывная технология или новая система которая решит все проблемы. Если проблема на стороне бизнес‑функции, то формируется предложение по коммерческой части — бизнес‑прорыв. Если причина торможения была и там и там, то формируется двойной геймчейнджер.

Организационные проблемы:

• Аналогичны предыдущему этапу;

• Приглашение консалтеров. Запрос к консалтингу, на этом этапе: «нам не хватает инструментов или умения работы с инструментами, которые находятся внутри нашей текущей организационной парадигмы». Консалтеры отрабатывают конкретно этот запрос, они тоже хотят есть. Существенных результатов это не приносит. Функция перегружается нововведениями;

• Найм и деятельность корпоратов. Учитывая уровень обсуждаемой проблематики, зачастую, запрос формируется на инструменталистов и коммуникаторов, которые на этом этапе не приносят ожидаемого эффекта. Функция перегружается нововведениями и/или коммуникацией;.

• Продолжающаяся деградация. Застойные зоны потребляют все больше ресурсов, создавая всё больше трения, результативность — отрицательная.

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

• Выгорание сотрудников и руководителей. Функция удерживается на плато эффективности благодаря героическим усилиям ограниченного круга сотрудников/проектов/направлений с понятными последствиями для них.

• «Релиз в эту пятницу» — в ответ на давление со стороны руководства и бизнеса в ИТ может сформироваться практика услужливой лжи, чтобы снять давление контроля. Даются обещания не реалистичных сроков, которые потом переносятся по, конечно же, объективным причинам. Это еще больше усугубляет проблему с доверием к «черному ящику», дезорганизацию и выгорание.

Что происходит:
Устав ждать возврата былой динамики, руководство дает разрешение на запуск геймчейнджера. Бизнес или ИТ‑функция, или оба хором, запускают его. Система к этому моменту перегружена за пределом. В хаос этой среды вбрасывается ещё один крупный проект и вместо ожидаемого прорыва он запускает процесс ускоренной деградации функции.

Геймчейнджер требует всё больше ресурсов, существенно превосходя запланированный уровень расходов и срывая плановые сроки реализации. И в итоге, фактически, проваливается. Формально, при талантливом подсчете, цели геймченджера могут считаться достигнутыми, но всем всё понятно.

Главная «польза» геймчейнджера в том, что он безжалостно вскрывает всю накопившуюся проблематику. Но, увы, не решает её. Когда его крах становится очевидным, наступает точка дна: все осознают, что ИТ‑функция деградировала настолько, что в текущем виде работать дальше не может. Иллюзии заканчиваются, требуется пересборка ИТ‑функции с нуля. Однако сейчас цена изменений — кратно выше, чем на этапе масштабирования так как организационный и технический долг в точке дна сравним с государственным долгом небольшой страны.

Начинается пересборка ИТ‑функции.

Домен Cynefin: Chaotic

Применяемые методы:

• Запуск геймчейнджера.

• Попытки реанимации административными методами

Организационные проблемы:

• Аналогичны предыдущим этапам.

• Геймчейнджер превращается в «чёрную дыру». Проект создаётся не на стабильной основе, а в хаотичной среде. Он не получает вменяемой организации и управления, зато получает приоритетный статус, из‑за чего под него перекраивают и без того глубоко нестабильное состояние системы. Он поглощает остатки ресурсов и заделов, запуская и ускоряя деградацию.

• Застойные зоны теряют любую видимость управляемости и продуктивности

• Окончательно ломается коммуникация. Критическое падение доверия бизнес‑функции к ИТ, оно достигает дна. Диалог на всех уровнях превращается в назначение виновных; 

• Внешнее управление. В результате отсутствия результатов руководство или прибегает к микроменеджменту со своей стороны или, фактически, переподчиняет ИТ, для лучшего контроля, тому кто оказывается ближе к ИТ — какому‑либо «цифровому активисту» со стороны бизнес‑функции или руководства;

• Уход ключевых сотрудников и руководителей. Последняя вспышка последних героев, на которых держалось плато эффективности. Люди, способные хоть что‑то двигать, уходят. 

Как я и говорил в начале этой статьи — здесь мы не будем размышлять о том как лечить перечисленные частные проблемы этапов или как разорвать цикл провала если он уже запущен. Эти вопросы нужно рассматривать отдельно, так как антикризисное управление — самостоятельная и большая тема. Здесь, в выводах, я хотел бы попытаться разобрать, почему компании превращают масштабирование не в трамплин развития, а в могильщика ИТ‑ функции.

Видимая причина, как это ясно из сценария, всего одна — не происходит эволюции оргуправлеческого дизайна ИТ‑функции в другие домены.
Переход из Complex в Complicated и далее в Simple должен осуществляться или после успеха пилота или в точке разрыва ожиданий, однако, этого почему‑то не происходит. Причины по которым это не происходит, на мой взгляд, несколько:

• Скорость и стоимость;

• Неверное понимание контекста применяемых методов организации

Скорость и стоимость

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

• разработки целевой оргуправленческой структуры ИТ‑функции с учетом планов бизнес‑функции по расширению и планов по дальнейшей эволюции ИТ‑функции;

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

• наем сотрудников новыми руководителями в новые команды и переформатирование существующих команд, отладка взаимодействия между ними.

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

• или снизить текущий темп работы ИТ‑функции, сместив фокус и ресурсы с приносящего деньги пилота и его развития на оргуправленческое развитие и бизнес и ИТ‑функции;

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

Первая возможность адекватно не рассматривается, так как конфликтует с установками бизнеса по агрессивному расширению.

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

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

Неверное понимание контекста применяемых методов

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

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

• Высокая общая зрелость управления и организации;

• Компании уровня FAANG;

• Венчурный капитал и культура стартапов

Высокая общая зрелость управления и организации — это означает, что задача корректного масштабирования и эволюции не является для менеджмента «ракетной наукой». Есть общее и распространенное понимание что, когда и как нужно делать.
Компании уровня FAANG — у этих компаний есть уже выстроенный очень мощный оперативный контур, опирающийся на высокую управленческую и организационную зрелость. Это позволяет проводить эксперименты и далее, не теряя эффективности, масштабировать успешные проекты, интегрируя их в существующий оперативный контур.
Венчурный капитал и культура стартапов —  цель стартапа — максимально быстро и выгодно продаться. Поэтому стартап в точке падения эффективности, когда требуется масштабирование и эволюция, или продаётся компании уровнем выше (например кому‑то из FAANG) или выходит на IPO, после перерождаясь в компанию с иной структурой.

Эти отличия суммируются к следующему:

• или в компании уже существует свой оперативный контур, готовый подхватить пилотный проект;

• или оперативный контур есть в компании которая приобретет стартап;

• или оперативный контур может быть создан внутри самой компании с минимумом издержек

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

Я не встречал в популярной управленческой литературе акцента на этом. Мне кажется, что для западных коллег это являются настолько общим местом, что попросту не упоминается, как, например, наличие электричества в офисе. Поэтому информационное пространство и литература заполняется тем, что для наших западных коллег интересно и важно: специфическими способами организации и управления в домене Complex, где и куются инновации и стартапы.

Этот перекос в информационном пространстве приводит к тому, что российские коллеги забивают гвозди Complex — микроскопом до упора, ориентируясь на «лучшие» практики, так как базовым практикам не уделяется достаточно внимания в информационном поле, они не описываются и не транслируются, так как считаются общеизвестными.