Прежде чем внедрять ИИ: оцените зрелость 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-минутный разговор.