Три уровня ответственности, без которых технологии только ускоряют хаос

Проведённый аудит даёт диагноз. Организационный дизайн - лечение.

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

Про RACI я писал в разборе инструментов аудита. Для меня это не только инструмент диагностики. Через матрицу я смотрю на зоны ответственности, снимаю конфликты между (или внутри) функциями и заново распределяю власть. От этого зависят и EBITDA, и устойчивость бизнеса. В этом смысле RACI - один из ключевых инструментов организационного дизайна.

Три уровня ответственности

После аудита практически всегда смотрю, как пересобрать организационную модель вокруг трёх уровней.

ПЕРВЫЙ УРОВЕНЬ - создание бизнес-ценности

Это продуктовые команды внутри бизнес-вертикалей. Их задача - скорость и результат. Внутри, как правило, такие роли:

• (PO) владелец продукта (обычно он на уровне бизнеса)
• аналитик
• delivery-manager (управляет потоком поставки, не только проектами)
• команда разработки

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

ВТОРОЙ УРОВЕНЬ - технологическая платформа

Это инженерное ядро:

• архитектура
• DevOps
• ИБ - по-хорошему контур ИБ должен быть организационно независим от ИТ, но операционно тесно с ним связан, иначе возникает конфликт интересов и снижается доверие к системе контроля
• OPS + инфраструктура
• поддержка (2L + ITIL)

Основная задача платформы - устойчивость и масштабирование. Платформенные команды работают как внутренний сервис для продуктовых команд. Их эффективность измеряется через SLA, SLO и стоимость платформенных сервисов.

Но даже два первых уровня не работают без третьего.

ТРЕТИЙ УРОВЕНЬ - связка бизнеса и технологий

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

Что меняется после пересборки

• Появляется прозрачность. У каждого процесса есть владелец, у каждого сервиса - ответственный.
• Ускоряются решения. Когда у процесса один A (см. матрицу RACI), согласование перестаёт быть бесконечным.
• Появляются измеримые метрики, которые сложно "читить". SLA и SLO становятся частью OKR. "Техника" начинает напрямую связываться с бизнес-результатами.

Переход от операционной нестабильности к управляемой модели обычно начинается не с технологий. Он начинается с организационного дизайна. Когда ответственность становится прозрачной, архитектура начинает выравниваться сама.

RACI - не матрица ролей. Это карта реальной ответственности и власти в организации.