Инвентаризация влияния: четыре зоны, где CIO отвечает за деньги

CIO может держать высокую доступность систем, выстраивать сильную архитектуру и вовремя выводить изменения. И все равно оставаться уязвимым на уровне совета директоров. И проблема чаще всего не в качестве работы.

Проблема в другом: CIO описывает свою роль через технологии, а совет директоров смотрит на финансовую модель компании.

Проблема. Пока CIO говорит про инфраструктуру, скорость вывода изменений, архитектуру, уровни обслуживания и внедрения, он нужен для текущей работы компании.

Но совет директоров смотрит на другое:

• выручка
• маржа
• снижение затрат
• риски
• устойчивость

Именно здесь и проверяется зрелость роли CIO.

Модель: инвентаризация влияния

Для себя я давно использую простой инструмент. На листе или в таблице собираю четыре зоны влияния CIO на экономику компании.

Выручка. Где технологический контур напрямую влияет на деньги. Смотрю на:

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

Если через эти точки проходит значимая доля выручки, это уже не "ИТ поддерживает бизнес". Это часть финансовой модели, за которую CIO реально отвечает.

Маржа. Где технология начинает влиять на стоимость изменений. Смотрю на:

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

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

Снижение затрат. Где ИТ влияет на базу затрат. Смотрю на:

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

Это самый очевидный контур влияния. Но, как ни странно, именно этот контур реже всего переводят в управленческий язык.

Риск и устойчивость. Где технологическая проблема уже имеет прямую цену для бизнеса. Смотрю на:

• стоимость часа простоя критичного процесса
• концентрацию на одном поставщике (vendor lock)
• концентрацию на одной команде (bus factor)
• санкционные риски
• ИБ риски
• регуляторный риски

Здесь важна сама постановка разговора. Не "у нас все зарезервировано", а "мы понимаем цену этого риска и держим его под контролем".

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

Как звучит сильная формулировка

Если смотреть на ИТ как на федерацию продуктовых, платформенных и сервисных команд, CIO не должен приписывать себе чужую операционную ответственность. За скорость вывода конкретных изменений отвечают ИТ БП, владельцы продукта, менеджеры поставки и руководители команд.

На этом уровне ответственность другая. Не скорость отдельных команд, а управляемость, предсказуемость, экономика и устойчивость всего технологического контура.

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

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

Слабо: "Я отвечаю за уровни обслуживания". Сильно: "Я отвечаю за такой уровень устойчивости и качества сервиса, при котором бизнес не теряет деньги, клиентов и управляемость"

Слабо: "Я отвечаю за архитектуру". Сильно: "Я отвечаю за то, чтобы стоимость и сложность изменений не росли быстрее бизнеса"

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

Какие инструменты я использую

В федеративной модели инструменты CIO должны показывать не только состояние ИТ, но и качество самой системы управления.

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

P&L Impact Mapping - привязка ИТ-контура к экономике бизнеса. Раскладываю ключевые системы, процессы и команды по четырем вопросам:

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

Этот инструмент нужен не для операционного управления командами. Он нужен, чтобы зафиксировать, где CIO реально отвечает за часть финансовой модели компании.

Run vs Change Allocation - соотношение поддержки и развития. Смотрю не только на загрузку команд, но и на то, сколько ресурса система в целом тратит на удержание текущего состояния, а сколько - на развитие.

Если поддержка текущего начинает съедать основную часть ресурса, это уже вопрос стоимости всей модели.

Value Stream Mapping плюс Lead Time и Cycle Time - инструменты, чтобы видеть, где сама система начинает тормозить бизнес.

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

Vendor & License Baseline - базовая картина затрат на технологии. Смотрю на:

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

Здесь речь о стоимости всего технологического ландшафта.

Board Reporting - формат отчетности для совета директоров. Первый слайд всегда про результат:

• что принесли
• что сэкономили
• что защитили
• что ускорили
• И только потом:
• проекты
• дорожная карта
• архитектура

Именно этот порядок меняет восприятие CIO на уровне CEO и совета директоров.

Что меняется после этой работы

Меняется отчетность. Она начинается не с релизов и проектов, а с результата.

Меняется смысл роли. Бюджет перестает быть разговором о затратах и становится инвестиционным решением.

Меняется переговорный вес. Не "дайте ресурс на проект", а "вот часть экономики, за которую я отвечаю".

Основной вывод

Недостаточно быть владельцем технологий. Недостаточно даже владеть большой командой и сложным ландшафтом. Пока за CIO закреплены системы, он защищает функцию. Когда за ним закреплен финансовый контур, он защищает стоимость бизнеса.

В этот момент CIO становится владельцем части экономической устойчивости компании.

И тут возникает следующая задача ) Текущая ИТ-команда может оказаться к этому не готова.

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