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

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

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

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

Домен Cynefin ^[2]: Complex

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домен Cynefin: Chaotic

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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