Прежде чем внедрять ИИ: оцените зрелость IT-департамента — культура и процессы

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

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

Зрелость IT-департамента: два фактора, которые решают всё

Работает IT-департамент или нет — и приживётся ли в нём новый инструмент — определяется, по сути, двумя вещами. Первая — культура: как в департаменте на самом деле принимают решения, кто кому и почему подчиняется, что считается нормой. Вторая — процессы: насколько работа описана, повторяема и управляема. Культуру недооценивают чаще: она невидима, её нельзя купить лицензией, и она молча «съедает» любую стратегию и любую систему KPI, которую вы в неё положите. Поэтому начну с неё.

Фактор 1. Корпоративная культура: спиральная динамика

Для оценки культуры я использую модель спиральной динамики в бизнес-адаптации Марка Розина (ЭКОПСИ, «Путешествие по спирали 2.0»). Причина проста: именно она в наиболее наглядном виде показывает отличие уровней с точки зрения двух ключевых требований — централизации и менеджмента. А это ровно те две оси, которые определяют, как реально управляется IT-департамент. Модель раскладывает культуру на шесть уровней, у каждого — своя определяющая фраза:

• Уровень 1 — принадлежность: «потому что у нас так принято». Семья, традиции, лояльность; работа неотделима от отношений.
• Уровень 2 — сила: «потому что я так сказал». Власть и личное лидерство; порядок держится на воле руководителя.
• Уровень 3 — правила: «потому что таковы правила». Системность, регламенты, дисциплина, надёжность, стабильность.
• Уровень 4 — успех: «потому что это даёт результат». Достижение, эффективность, скорость; правила уходят на второй план ради результата.
• Уровень 5 — согласие: «потому что мы об этом договорились». Диалог, консенсус, различия как ценный ресурс.
• Уровень 6 — синтез («бирюза»): «потому что за этим будущее». Интеграция всех предыдущих состояний.

По результатам аудита выясняется текущий уровень культуры — отдельно у департамента и отдельно у компании. Типичная и очень показательная картина: IT-департамент оказывается на 1-м уровне из 6 (минимальном), а компания вокруг — на 2-м. Дальше — самый важный вопрос: какой уровень культуры вообще нужен IT-департаменту и почему его нельзя тянуть в отрыве от компании.

Какой уровень нужен IT-департаменту — и правило ±1

Для нормального функционирования IT-департамента его внутренняя культура, по моему опыту, должна быть минимум 3-го уровня из 6, идеально — 4-го. Ниже третьего в IT не появляется того, без чего он не работает вдолгую: регулярного менеджмента, повторяемых процессов, предсказуемости. Культура силы (2) держится на герое-руководителе и рушится, как только он в отпуске; культура принадлежности (1) вообще не про управляемость.

Но поднять один департамент в отрыве от компании нельзя, и здесь работает жёсткое правило: если департамент отличается от всей компании или от другого департамента более чем на один уровень — будут конфликты. Департамент 4-го уровня внутри компании 2-го уровня не «подтянет» её собой — он будет восприниматься как чужеродный и вязнуть в трении. Поэтому цель ставится реалистично: продуманная стратегия, по моему опыту, позволяет примерно за шесть месяцев вывести культуру внутри IT-департамента на 3-й уровень — это ровно на один уровень выше компании 2-го, что правило ±1 допускает; выход на 4-й возможен, только если и вся компания сдвигается на 3–4-й. Зрелость культуры — командная игра, а не героический рывок одного отдела.

И правило шире, чем только культура — оно управляет соотношением самих измерений зрелости. Зрелость процессов и, главное, уровень автоматизации подчиняются той же дисциплине ±1: они не могут отстоять от культуры, и друг от друга, более чем на один уровень. Уровень автоматизации на две ступени выше культуры, которая должна с ним работать, обречён так же, как департамент 4-го уровня внутри компании 2-го, — его обходят, им тяготятся и тихо отторгают. В этом механическая причина, почему «просто внедрить ИИ» проваливается: накинуть высокую автоматизацию на низкую культуру и хаотичные процессы — это по определению нарушение правила ±1. Поднимают не одно измерение — культуру, процессы и автоматизацию поднимают вместе, по уровню за раз.

Сразу оговорю, откуда берётся это правило ±1: это моя рабочая эвристика — но не произвольная, а прикладная форма принципа, к которому сходятся сразу несколько устоявшихся моделей. Модели зрелости прямо говорят, что подниматься можно только на один уровень за раз: Capability Maturity Model (SEI) формулирует, что каждый уровень зрелости — необходимый фундамент для следующего, а попытки перепрыгнуть через уровни обычно контрпродуктивны — та же логика «без прыжков», только применённая здесь и к автоматизации. Социотехническая теория систем добавляет боковое ограничение: её принцип совместной оптимизации гласит, что технический контур, разогнанный далеко впереди социального, не поднимает систему в целом, а деградирует её. И это подтверждается экономически: Эрик Бриньолфссон (MIT) показал, что ИТ и автоматизация окупаются только вместе с сопутствующими изменениями в организации — внедрённые впереди них, они дают не нулевую, а отрицательную отдачу. Теории задают направление — не перепрыгивать через уровни, держать подсистемы в балансе; а конкретный допуск «не больше одного уровня разницы» — это та планка, которой я пользуюсь на практике.

Что меняется при переходах: централизация и менеджмент

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

По оси централизации. Уровень 1 держится на традиции как на едином центре; переход на 2-й дробит этот центр на конкурирующие фигуры силы — это и есть децентрализация (с точки зрения комплексного управления), — но при этом впервые появляется порядок. С 2-го на 3-й авторитет вновь централизуется — уже вокруг правил и системы — при сохранении порядка, но теряется гибкость: всё становится по регламенту. С 3-го на 4-й снова становятся возможны творчество и новые разработки — жёсткая централизация частично уступает, добавляется гибкость. То есть путь не линеен: вы то стягиваете управление, то отпускаете, и важно понимать, где вы на этой кривой.

По оси менеджмента. Переход с 1-го на 2-й уровень не меняет саму систему менеджмента — меняется только формат, а все ограничения персонального управления сохраняются: всё по-прежнему завязано на конкретного человека. Ключевой скачок происходит на переходе со 2-го на 3-й — именно тогда появляется регулярный менеджмент: управление процессами, а не людьми в ручном режиме. Вот почему планка «минимум 3» для IT не случайна: регулярный менеджмент — это тот порог, за которым департамент вообще можно системно измерять и автоматизировать.

Фактор 2. Бизнес-процессы и их зрелость

Второй фактор — процессы. Здесь есть устоявшийся стек инструментов, и у каждого своя роль:

• BPMN (нотация OMG) — общий язык, чтобы однозначно описать процесс: люди, ИИ и BPM-движок понимают «шаг согласования» одинаково.
• ITIL (Service Support) — набор эталонных процессов, за зрелостью которых вы и наблюдаете: управление инцидентами, проблемами, изменениями, релизами, конфигурациями (с CMDB как единым источником истины).
• COBIT и Risk IT (ISACA) — слой governance: разделение руководства и управления, цели контроля и управление ИТ-рисками (оценка и реагирование).

Описанный в BPMN и сверенный с ITIL/COBIT процесс дальше оценивают по единой шкале зрелости 0–5 (обзор методик — у BPM-аналитика А. Коптелова; сюда сходятся CMMI, ISO/IEC 15504, PEMM Хаммера, модель ABPMP). Логика лестницы едина: 0 — неполный / хаотичный процесс, 1 — выполняемый (делается, но без гарантий), 2 — управляемый, 3 — установленный (документирован и повторяем), 4 — предсказуемый (измеряется и управляется по метрикам), 5 — оптимизируемый. Вопрос не «хороший ли процесс», а «на каком он уровне и какого атрибута не хватает до следующего».

И здесь важный нюанс, который часто упускают. Зрелость — не то же самое, что «максимум». В модели зрелости безопасности IoT (Kaspersky/IIC) это сформулировано прямо: полнота реализации ещё не зрелость; зрелость относительна цели. Процессу калькулятора не нужен 5-й уровень; критичному биллингу — нужен. Гнать каждый процесс на верх лестницы — это не зрелость, а перерасход. Правильная зрелость — достаточная для задачи.

Почему это — до ИИ, а не после

Теперь связка. Когда вы знаете уровень культуры (и что до «регулярного менеджмента» нужно дорасти) и зрелость процессов (и где реально хаос, а где уже метрики), внедрение ИИ впервые становится осмысленным. Более того — эти же фреймворки становятся заземлением для модели. Попросите LLM «оценить, кто хорошо работает», не дав ей системы отсчёта, — и она выдумает критерии и раздаст уверенные, но безосновательные ярлыки. Дайте ей COBIT, процессы ITIL, шкалу зрелости 0–5 и уровень культуры — и она станет сравнивать реальность с признанными стандартами, а не сочинять свои. Заземление превращает «мнение модели» в проверяемое утверждение: «Управление инцидентами на 2 из 5, потому что владелец есть, а измеряемых KPI нет».

Отсюда же вытекают и границы. ИИ-контур наблюдения за IT — это про то, чтобы мерить работу, а не следить за людьми: метаданные и тайминги, не содержание; git-сигналы, не diff; агрегаты, не переписка. Детерминированные метрики (SLA, throughput, review latency, нагрузка) считает арифметика; ИИ подключается на краях — триаж, черновики сводок, разбор аномалий, человекочитаемые объяснения — всегда как вход для решения человека. И красная линия: никакого кейлоггинга, скриншотов и чтения переписки; никаких автоматических кадровых решений (ту же черту вокруг полностью автоматических решений проводят GDPR ст. 22 и LGPD ст. 20) и «рейтинга сотрудников». Всё это не «добавляется потом» — это часть дизайна, и, что показательно, культуре 3–4-го уровня такой прозрачный, правило-ориентированный контроль по душе, а культуре силы (2) — нет. Ещё одна причина сначала оценить культуру.

Человеческий фильтр: когнитивные искажения

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

Когда вы выставляете балл конкретному процессу по шкале 0–5, якорение привязывает всю оценку к первой названной цифре — или к красивой презентации вендора — вместо фактов. А фундаментальная ошибка атрибуции — главная ловушка контроля: мы виним человека («он небрежный»), когда на деле виноват незрелый процесс — без владельца и без правил. Спутать «плохого сотрудника» и «сломанный процесс» — значит оценить не то, а потом и лечить не ту болезнь.

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

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

Порядок действий

Сложите всё вместе — и получается ясная последовательность. Сначала оцените: уровень культуры (по спирали, отдельно департамент и компания) и зрелость ключевых процессов (по шкале 0–5, описав их в BPMN и сверив с ITIL/COBIT). Потом выровняйте: доведите культуру IT минимум до 3-го уровня (регулярный менеджмент) с оглядкой на правило ±1, и подтяните критичные процессы до достаточной зрелости. И только потом автоматизируйте — заземляя ИИ на те же фреймворки и удерживая его в границах «мерить работу, а не людей». Порядок здесь и есть методология: тот, кто начинает с ИИ, минуя оценку, автоматизирует свой хаос; тот, кто начинает с зрелости, — получает департамент, который этот ИИ действительно усилит.

Я провожу такие аудиты и выстраиваю зрелость IT-департаментов как внештатный технический директор. Если хотите разобрать свой случай — напишите мне.

Частые вопросы

Почему нельзя просто внедрить ИИ и на нём же навести порядок?

Потому что ИИ садится в существующую культуру и процессы, а не заменяет их. В хаотичном процессе он автоматизирует хаос, а в культуре силы (2 из 6) прозрачный контроль отторгается. Сначала оценка и выравнивание зрелости, потом автоматизация.

Какой уровень культуры нужен IT-департаменту?

Минимум 3-й из 6 (уровень правил и регулярного менеджмента), идеально 4-й (успех/результат). Ниже 3-го нет повторяемости и предсказуемости. При этом действует правило: разрыв более чем на один уровень с компанией или соседним департаментом порождает конфликты.

Почему именно модель Розина, а не другая?

Потому что она в самом наглядном виде показывает отличие уровней по двум ключевым для управления осям — централизации и менеджменту, — и прямо отвечает на вопрос, появился ли в департаменте регулярный менеджмент (переход 2→3).

Что такое «достаточная» зрелость процесса?

Зрелость, соответствующая критичности процесса, а не максимум по шкале. Полнота реализации — ещё не зрелость (модель IoT SMM). Критичный биллинг стоит довести до 4–5, рутинную мелочь — нет; иначе это перерасход, а не порядок.

Источники и фреймворки

• Марк Розин, «Путешествие по спирали 2.0» (ЭКОПСИ) — спиральная динамика корпоративной культуры.
• Методики зрелости в обзоре А. Коптелова — CMMI, ISO/IEC 15504, PEMM Хаммера, ABPMP.
• COBIT и Risk IT Framework (ISACA) — governance и управление ИТ-рисками.
• ITIL (Service Support) — процессы управления ИТ-услугами.
• BPMN 2.0 (OMG) — нотация моделирования процессов.
• IoT Security Maturity Model (IIC / Kaspersky) — зрелость как соответствие цели («полнота ≠ зрелость»).
• GDPR ст. 22 (и LGPD ст. 20) — ограничения на полностью автоматические решения о людях.
• Capability Maturity Model (SEI / Carnegie Mellon, по Уоттсу Хамфри) — зрелость как ступенчатый фундамент: каждый уровень опирается на предыдущий, а перепрыгивать через уровни контрпродуктивно.
• Социотехническая теория систем (Trist & Bamforth, Tavistock) — «совместная оптимизация»: социальная и техническая подсистемы должны развиваться вместе.
• Erik Brynjolfsson & Lorin Hitt, «Beyond Computation» (Journal of Economic Perspectives, 2000) — ИТ и автоматизация окупаются только вместе с сопутствующими изменениями в организации.
• Исследования когнитивных искажений — Даннинг–Крюгер (самооценка), Тверски и Канеман (якорение, ошибка планирования) и автоматизационная предвзятость (Parasuraman & Riley).

---

Нужна консультация?

Если хотите оценить зрелость своего IT-департамента — по культуре и процессам — прежде чем вкладываться в автоматизацию и ИИ, запишитесь на бесплатный 15-минутный разговор.