В статье экспертного блога BITOBE про архетипы ИТ-организаций речь шла о самой модели: о том, почему каптив нельзя описать только через оргструктуру, набор процессов или модный словарь про «продуктовый подход». О том, что у ИТ-компании есть своя внутренняя логика жизни, свой способ принимать решения, распределять ответственность и работать с изменениями.
Продолжая эту тему, хочется пойти на шаг дальше и поговорить не о модели, а о практике. После десяти сессий диагностики каптивных ИТ-организаций у меня сложилось довольно устойчивое наблюдение. Почти ни одна компания не выглядела как «чистый» архетип. Наоборот: в большинстве случаев внутри одной ИТ-организации одновременно жили три, а то и больше, разных логик работы.
И вот тут начинается самое интересное.
На словах бизнес ждет от ИТ цифровой трансформации: инициативы, скорости, переосмысления процессов, новых решений, влияния на клиентский опыт. А по факту сама ИТ-организация часто устроена совсем для другого. Она живет как смесь сервисного оператора и фабрики фич. То есть одной ногой стоит в стабильности и поддержке, а другой – в бесконечном потоке доработок по запросу.
Именно в этом разрыве, похоже, и спрятана большая часть того, что обычно называют «медленностью каптива».
Медленность – это не просто проблема процессов
Когда говорят, что внутреннее ИТ работает медленно, объяснение обычно звучит довольно привычно: слишком много согласований, слишком длинные процессы, слишком большая нагрузка, слишком сложный ландшафт систем. Все это правда. Но это правда поверхностная.
Если смотреть глубже, медленность возникает не только из-за объема задач. Она возникает потому, что внутри одной организации одновременно действуют несколько разных моделей работы – и каждая тянет систему в свою сторону.
Одна часть ИТ живет в логике эксплуатации: главное – надежность, предсказуемость, контроль изменений. Другая – в логике delivery: главное – быстро доставлять запросы бизнеса. Третья пытается говорить языком продукта: ей нужна автономия, быстрые решения и право работать с неопределенностью. Четвертая уже вынуждена отвечать на запрос на трансформацию: не просто автоматизировать существующее, а помогать бизнесу меняться.
По отдельности каждая из этих логик имеет право на жизнь. Проблема начинается тогда, когда они смешиваются в одной конструкции, но не разведены ни по ролям, ни по ожиданиям, ни по ответственности. Тогда организация начинает тратить силы не на результат, а на внутреннее трение.
Что на самом деле показали диагностики
Самый важный вывод из проведенных сессий звучит довольно просто: проблема каптивных ИТ-компаний не в том, что они «не доросли» до какой-то правильной модели. Проблема в том, что они одновременно живут в нескольких моделях сразу.
И это не безобидная сложность, а вполне практическая причина потерь. Когда в одной системе сосуществуют несколько архетипов, растет количество внутренних стыков. А каждый стык – это дополнительные согласования, переводы с одного управленческого языка на другой, размывание ответственности и постоянная борьба приоритетов.
Бизнес говорит: «Нам нужна скорость и изменения». Эксплуатация отвечает: «Нам нужна устойчивость и контроль». Delivery-контур сообщает: «У нас и так очередь переполнена». Архитектура заявляет: «Нельзя ломать целостность ландшафта». Продуктовые команды утверждают: «Без автономии мы не полетим».
В итоге никто не совсем неправ. Но и система в целом не начинает работать лучше. Она просто становится тяжелее.
Почему в одной компании оказывается сразу несколько архетипов
На первый взгляд может показаться, что такая смесь – это ошибка проектирования. Но на деле все немного тоньше. Каптивная ИТ-организация почти никогда не создается сразу как единая, целостная система. Обычно она растет слоями.
В одном месте нужно было обеспечить надежную поддержку. В другом – быстро закрывать поток запросов от бизнеса. В третьем – построить что-то похожее на продуктовую команду. В четвертом – ответить на давление сверху про цифровую трансформацию. Каждый новый вызов добавляет в систему еще один способ жить и работать.
Сначала это выглядит как адаптация. Потом – как компромисс. А потом вся организация превращается в многослойную конструкцию, где поверх старых моделей просто надстраиваются новые, но старые никуда не исчезают.
Именно поэтому каптивы так часто напоминают геологический разрез: снизу – тяжелый операционный фундамент, поверх него – слои проектной и сервисной логики, еще выше – продуктовая надстройка, а над всем этим уже развевается флаг трансформации.
Снаружи выглядит амбициозно. Изнутри – создает огромные издержки на координацию.
Почему бизнес и ИТ так часто не совпадают в ожиданиях
Отдельная проблема в том, что бизнес и ИТ очень часто живут в разных картинах реальности. Бизнес уже исходит из того, что рынок меняется быстро, конкурировать нужно не только за счет масштаба, но и за счет скорости изменений, а значит, ИТ должно стать партнером развития. Не просто исполнителем, не просто поддержкой, а полноценным участником преобразований.
Но внутри самого ИТ-контура часто сохраняется прежняя организационная логика. Она может быть отлично приспособлена для эксплуатации, для надежной поддержки, для планового исполнения доработок – но не для трансформации.
И тогда возникает классический разрыв. От ИТ ждут поведения двигателя изменений, а устроено оно как механизм обслуживания и очередного производства фич.
Это примерно как требовать от грузового лифта танцевальной пластики. Он, может быть, и очень полезен, но проектировали его вообще не для этого.
Откуда берется ощущение постоянной перегрузки
Во многих каптивах есть знакомое ощущение: все очень заняты, все работают на пределе, встреч много, задач еще больше, а скорость изменений все равно не устраивает бизнес.
Это важный симптом. Он часто означает, что организация уперлась не в нехватку усилий, а в архитектуру собственной координации. Слишком много энергии уходит на то, чтобы склеивать несовместимые способы работы.
Именно здесь полезно говорить о транзакционных издержках – хотя по-человечески это можно назвать проще: цена внутренних стыков.
Чем больше в компании нестыковок между ролями, полномочиями, логиками принятия решений и ожиданиями, тем дороже обходится любое изменение. Не потому, что само изменение обязательно сложное. А потому, что оно проходит через слишком много переводов, согласований и локальных конфликтов.
Поэтому медленность каптива – это часто не техническая проблема и даже не процессная. Это организационная проблема.
Почему нельзя решить это еще одним регламентом
В таких ситуациях естественная реакция управления обычно предсказуема: добавить еще одну роль, еще один комитет, еще один процесс приоритизации, еще один слой контроля.
Иногда это даже дает короткий эффект. Но в долгую чаще происходит обратное: система становится еще тяжелее.
Причина простая. Если базовое противоречие в том, что организация живет одновременно в нескольких архетипах, то новый регламент не устраняет это противоречие. Он лишь помогает ему аккуратнее разложиться по папкам. То есть хаос становится не меньше, а бюрократически опрятнее.
Что тогда нужно диагностировать на самом деле
После нескольких сессий стало особенно ясно: главная задача диагностики – не приклеить компании ярлык. Не сказать: «Вы вот такой-то архетип» — и на этом успокоиться. Намного важнее понять три вещи.
Во-первых, как организация реально живет сегодня. Не на слайдах, не в стратегических формулировках, а в повседневной управленческой практике.
Во-вторых, чего от нее на самом деле ждет бизнес. Какую роль ей уже назначили, даже если это не до конца проговорено.
И в-третьих, где именно между этими двумя картинами возникает разрыв. Вот этот разрыв и есть настоящее поле для диагностики.
Не вопрос «кто мы по типологии?», а вопрос «почему при одном наборе ожиданий мы воспроизводим совсем другую организационную логику?»
Главное, с чем нужно работать, – противоречия
Наверное, самый важный вывод из всей этой практики в том, что работать нужно не с абстрактной «медленностью», а с конкретными противоречиями. Именно они создают неопределенность, перегрузку и лишние внутренние издержки.
Бизнес хочет трансформации, а ИТ живет как оператор. Командам говорят быть продуктовыми, но решения остаются централизованными. От ИТ ждут скорости, но нагружают его все новыми слоями контроля.
Ответственность за результат формально есть у всех, а фактически – расползается по стыкам. Пока эти противоречия не названы прямо, организация будет продолжать буксовать.
Можно сколько угодно обсуждать Agile, продуктовый подход, платформы и цифровую зрелость, но если внутри одной конструкции смешаны несовместимые логики, скорость будет съедаться еще до начала реальной работы.
Что из этого следует
Для меня главный вывод после этих десяти диагностик звучит так: каптивные ИТ-организации тормозят не потому, что они недостаточно современные, недостаточно гибкие или недостаточно мотивированные.
Чаще они тормозят потому, что в них накопилось слишком много слоев, ролей, ожиданий и моделей работы, которые плохо сочетаются друг с другом. Поэтому системная работа нужна не только с процессами. Она нужна с противоречиями.
Нужно не просто ускорять delivery. Нужно снижать неопределенность в самой организационной конструкции. Убирать лишние внутренние стыки. Разводить несовместимые логики. Делать яснее роли, ожидания и границы ответственности.
Иначе каптив будет жить в знакомом режиме: много активности, много задач, много разговоров про трансформацию — и слишком мало реального движения. А это уже не вопрос зрелости. Надо признать, как система устроена на самом деле, и начать работать не с симптомами, а с причинами.
