ИТ-бюджет нельзя резать линейкой

Собственник спросил: можем не покупать сервер за 18 миллионов?

ИТ-директор ответил: ну да.

Так CAPEX-бюджет потерял строку. Через несколько месяцев та же инфраструктура не выдержала нагрузки. Формально ИТ было чем защищаться: мы запрашивали, вы отказали. Но для бизнеса это слабое утешение. Система всё равно не выдержала.

Это не злой умысел. Это системная управленческая ошибка - и она повторяется каждый раз, когда CAPEX-бюджет выглядит как список железа с ценниками.

Почему диалог «ну да» - это ловушка

Собственник смотрел на строку в бюджете и видел деньги. В голове шёл нормальный предпринимательский расчёт: 18 миллионов за сервер или открытие объекта, который за год-два окупится. Выбор очевидный.

ИТ-директор смотрел на ту же строку и видел железо. Когда спросили «можем не покупать?», он ответил честно: технически - можем. С точки зрения сиюминутного функционирования систем - это правда. Сервер ещё работает. Данные не пропадут. Ничего сразу не рухнет.

Никто не солгал. Но разговор шёл на разных языках.

Собственник задавал управленческий вопрос - про деньги, риски и последствия. ИТ-директор отвечал на технический вопрос - про текущую работоспособность системы. Из-за этого разрыва крупные CAPEX-строки одна за другой шли под нож. После каждого раунда планирования доверие падало с обеих сторон: собственник видел, что ИТ просит и тут же отступает. ИТ-директор копил аргумент «мы же предупреждали» - и при первом серьёзном сбое им пользовался.

Замкнутый круг. Выйти из него можно только одним способом: сменить предмет разговора.

Не «покупаем или нет сервер», а «что происходит с бизнесом, если эту строку срезать».

Что я изменил в подготовке CAPEX-бюджета

Я видел эту модель в разных компаниях. Когда принимал функцию - первым делом пересобрал сам формат.

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

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

Для каждой крупной статьи добавил три сценария - что происходит, если срезать, перенести или заменить. Это не таблица страха. Это таблица ответственности: собственник видит, что именно он покупает своим решением.

Привязал каждую строку к одному из контуров - защита текущей выручки, масштабирование, регуляторный минимум или развитие. Это разделение работает. Когда финансовый директор предлагает урезать всё на 10%, сразу видно, какие строки касаться нельзя, а где есть пространство для манёвра.

И зафиксировал с командой и с бизнесом одно правило. Если строка бюджета срезается - это принятое управленческое решение с понятными последствиями. Не «ИТ не дотащило». Не «нам не дали денег». Решение принято, риск принят, цена решения понятна.

После этого CAPEX перестал быть просьбой ИТ. Он стал языком решений для собственника и CEO.

Четыре измерения, через которые я смотрел на каждую строку

Любое оборудование в инфраструктуре я разбирал через четыре измерения. Именно эта декомпозиция превращает список железа в понятную для бизнеса картину.

Срок эксплуатации. У каждой категории оборудования есть нормальный горизонт службы, определённый производителем. После него начинается не просто риск отказа. Заканчивается поддержка, исчезают запчасти, инженеры работают не с системой, а с её технической историей. Когда что-то ломается - нет ни замены, ни компетентного сервиса в разумные сроки. Первый вопрос по каждой строке: где мы находимся относительно жизненного цикла? Это не вопрос «когда сломается». Это вопрос «когда перестанем управлять ситуацией».

История инцидентов. Если конкретный узел регулярно даёт сбои, которые видит выручка, - это не техническая проблема. Это операционный расход, который просто не отражён в P&L. Час простоя кассы в магазине - конкретная сумма. Умножить на частоту и число точек - получается цифра, которую можно положить рядом с CAPEX-строкой. Иногда оказывается, что замена окупается за квартал.

Доступность обслуживания и запчастей. Это измерение чаще всего упускают. Оборудование может работать, платформа - поддерживаться, но запчасти уже исчезли с рынка. Один сгоревший компонент - и встала вся система. Нет ни замены, ни сроков, ни управляемости. Обратное тоже верно: если оборудование ещё на гарантии или доступна сервисная поддержка производителя, иногда правильное решение - не замена, а планово-профилактическое обслуживание. Но этот вывод нужно получить через анализ, а не принять по умолчанию.

Бизнес-цели на горизонте 3-5 лет. Текущая инфраструктура спроектирована под текущий бизнес. Если через год планируется рост сети на 20-30 объектов - узкое место появится раньше, чем кто-то успеет к нему подготовиться. Если компания переводит сотрудников из нескольких офисов в один - инфраструктура должна быть готова. Аудит не означает «покупать новое». Аудит - это «что используем сейчас, что после обслуживания, что точно не продолжаем». Иногда из десяти позиций три полностью заменяются, четыре восстанавливаются, три продолжают работать как есть.

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

Когда третье измерение становится аварией

Показательный пример. В одной компании Wi-Fi-инфраструктура работала на оборудовании 2016 года: формально функционировала, запчастей на рынке уже не было. Когда первый роутер вышел из строя - замену искали несколько дней. Плановая модернизация стала аварийной заменой всего контура.

Цена выросла. Но хуже было другое: компания потеряла выбор.

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

Кейс первый: ядро сети

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

Я зафиксировал это решение явно. Не оставил в воздухе, не принял молчаливо. Сказал прямо: решение зафиксировано, риск принят, цена решения понятна.

Через несколько месяцев в пиковый период оборудование начало давать сетевые штормы. Регулярные, непредсказуемые. На затронутых операционных контурах просадка оборота за месяц составила более 20%. Собственник сказал прямо: я видел предупреждения и принял другое решение. Моя ошибка.

А я сделал свой управленческий вывод. Моя задача как CIO - не просто получить подпись «риск принят» и оказаться правым после аварии. Моя задача - найти аргумент, который бизнес не сможет проигнорировать.

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

Кейс второй: запчасти

Это история не про меня - а про то, что происходит, когда первый кейс заканчивается не выводом, а бумагой.

ИТ-команда в одной из компаний три года подряд запрашивала резервные компоненты для серверного парка. Три года строку срезали. Каждый раз решение фиксировалось. Бумаги были в идеальном порядке: запросы, отказы, подписи, служебные записки. Всё по правилам.

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

90% информационных систем не работало. Бизнес стоял.

Я отложил папку и разобрал ситуацию по факту. Первый сервер был неисправен, но его компоненты были живы. За три дня мы разобрали первый, подняли второй, запустили ключевые системы. Бизнес заработал. Дальше - без тендеров, без длинных согласований - нашли запчасти в наличии у поставщиков, закрыли вопрос за несколько сотен тысяч рублей. Через неделю инфраструктура была полностью восстановлена.

Бумаги не спасли операционный контур. И счёт на несколько миллионов тоже не понадобился.

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

Матрица последствий - инструмент, а не аргумент

Когда CAPEX-бюджет разобран по четырём измерениям, к финансовому директору приходишь не с фразой «это нельзя резать». Приходишь с картой решений.

У каждой крупной строки - три сценария. Что будет, если срезать. Что будет, если перенести. Есть ли рабочая альтернатива.

Есть народная формулировка точнее любой консалтинговой: кроилово ведёт к попадалову.

Хорошее решение о бюджете - не то, которое сэкономило сейчас. То, которое не аукнулось потом.

Матрица - это не аргумент ИТ. Это инструмент бизнеса.

Как изменился разговор о бюджете

После того как CAPEX был пересобран в такой логике, защита бюджета перестала быть торгом.

Финансы по-прежнему просили оптимизировать. Но теперь за каждой строкой было видно: эта защищает контур продаж, эта обеспечивает масштабирование при запуске новых объектов, эта - регуляторный минимум. Когда предложили урезать всё на 10%, мы открыли матрицу и за 20 минут определили, где есть пространство, а где нет.

Бюджет был утверждён как модель риска и роста. Не как список закупок.

Раньше CIO выходил с переговоров с урезанным бюджетом и аргументом «я предупреждал». Теперь собственник и CEO выходят с пониманием, что именно защищает каждая строка, - и принимают решения с этим знанием.

Горизонт решает

Собственник, который смотрит на CAPEX в горизонте одного года, видит расходы. Кто смотрит на пять - видит инвестицию или страховку.

Инфраструктура не ломается в тихие периоды. Она ломается тогда, когда на неё давит нагрузка. А нагрузка растёт именно тогда, когда бизнес начинает разгоняться - открывает объекты, масштабирует операции, подключает новые контуры. В этот момент узкое место в инфраструктуре перестаёт быть технической проблемой. Оно становится ограничителем роста.

Один крупный сбой в пиковый период стоит дороже трёхлетней программы планового обновления. Это не пессимизм. Это экономика решений.

ИТ-бюджет нельзя резать линейкой.

Его нужно разбирать как систему последствий.

Каждая строка - это либо защита того, что уже работает, либо ресурс для того, что запланировано. Когда это видно, разговор о деньгах перестаёт быть торгом за ценники и становится управленческим решением.

Если этого не сделать, бизнес всё равно заплатит.

Только позже, дороже и уже не по плану.