Как защитить ИТ-бюджет перед собственником: Run, Grow, Transform

В субботу утром встали кассы в нескольких магазинах.

Не сбой оборудования. Не отключение интернета. Закончились фискальные накопители.

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

Накопители живут 15 месяцев, а не 12. Каждый год пик замен в другом месяце. Скопировать прошлый год - значит гарантированно ошибиться с датой.

Суббота. Выходной. Найти фискальный накопитель в маленьком городе или селе - нереально. Магазины ждали понедельника.

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

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

Коротко: что должен видеть собственник вместо плоской таблицы

В нормальной модели собственник видит не только рост ИТ-бюджета с 9,1 до 16,7 млн руб.

Он видит главное:

• сопоставимые объекты выросли на 1,4% - текущий контур остался под контролем;
• основной рост дали новые объекты, склад и расширение мощности;
• Transform вынесен отдельно - потому что сегодняшние расходы должны менять будущий OPEX;
• каждая строка имеет источник, драйвер и последствие удаления.

Это другой разговор. Не «ИТ-бюджет вырос на 83%», а «вот откуда каждый рубль роста, вот что за ним стоит и где нужно управленческое решение».

В статье:

• почему копирование бюджета прошлого года ломает операцию;
• как разделить ИТ-бюджет на Run, Grow и Transform;
• как показать собственнику рост бюджета без ощущения «ИТ стало дороже»;
• какие реестры нужны для управляемой модели;
• как проверять спорную строку перед сокращением бюджета.

Плоский бюджет выглядит аккуратно. До первого сбоя.

Во многих компаниях ИТ-бюджет выглядит как нормальная финансовая таблица.

Лицензии. Оборудование. Связь. Подрядчики. ФОТ. Подписки. Поддержка. Информационная безопасность. Проекты.

Формально всё разложено.

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

Без этого бюджет превращается в спор по названиям статей. Собственник видит сумму. Финансы видят лимит. ИТ видит обязательства. CEO видит конфликт функций. Система последствий не видна никому.

Три блока вместо одной таблицы расходов

Одно замечание до того как говорить о структуре.

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

Run / Grow / Transform - не английские термины ради красоты. В рабочей управленческой логике это три простых вопроса.

Что держит бизнес живым прямо сейчас - Run. Что обеспечивает рост объектов, людей и каналов - Grow. Что меняет модель и будущую экономику - Transform.

Одна и та же строка может попасть в разные блоки.

Компьютер вместо сломанного рабочего места - Run. Компьютеры для нового отдела - Grow. Новая модель рабочих мест, которая снижает TCO поддержки - Transform.

Run не равен OPEX, а Transform не равен CAPEX. Run может быть CAPEX - плановая замена оборудования, без которой контур начнёт деградировать. Transform почти всегда меняет будущий OPEX - и именно это нужно показывать, иначе бизнес видит только цену внедрения, а не изменение экономики.

Для CFO такая модель тоже удобнее. Она переводит разговор из «дорого / недорого» в другой вопрос: какое последствие мы покупаем или принимаем своим решением.

Один из уроков, который я вынес из практики: собственник не обязан понимать ИТ. Его задача - управлять бизнесом. Задача CIO - говорить с ним на его языке. Не «нам нужен сервер», а «вот риск для продаж, вот цена этого риска, вот стоимость решения». Эта модель - инструмент такого перевода.

Что видит собственник на выходе

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

Ниже показана демонстрационная модель: учебный пример с 15 магазинами, 3 складами и 2 офисами. Цифры условные, логика и структура соответствуют рабочей практике защиты бюджета.

Собственнику нужны три главных экрана. Экран управленческих решений, экран структуры изменения бюджета и экран unit economics. Остальные экраны - для drill-down: сопоставимая база, прошлогодние объекты, новые объекты, Run CAPEX, Grow и Transform.

Первый из трёх главных экранов - карта решений, а не таблица расходов. Критичный Run на 8,4 млн - утвердить. Новая база и Grow на 7,1 млн - утвердить по бизнес-плану. Склад - отдельное решение. Transform кассового ПО - при подтверждении эффекта. Кадровый ЭДО - вернуть на расчёт. Каждый блок с комментарием о риске при отказе.

Экран структуры изменения объясняет дельту бюджета. Рост с 9,1 до 16,7 млн видно не как единая цифра, а как набор источников с разной природой.

Главный вывод из этого экрана: рост бюджета на 83% сам по себе ничего не доказывает.

Если сопоставимая база выросла на 1,4%, а основной рост пришёл из новых объектов, склада и Grow - это не раздувание ИТ. Это стоимость бизнес-решения о росте.

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

Экран unit economics - один из самых важных для собственника. Он отвечает не на вопрос «сколько стоит ИТ», а на вопрос «масштабируется ли ИТ вместе с бизнесом».

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

Как модель ловит ошибки

ФН: возвращаюсь к субботе

Магазины стояли не потому что кто-то был невнимательным. Бюджет был скопирован с прошлого года - в июне строка пустая, деньги не заложены, заявку не провели.

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

+50 компьютеров

Офис сообщил о выходе 50 новых сотрудников во втором квартале и запросил соответствующее количество компьютеров. В старой модели это могло пройти как обычная закупка.

Есть заявка. Есть потребность. Людям нужны рабочие места. Значит нужно покупать.

Но после раскладки по потребителям и драйверам цифра сразу проявилась в бюджете.

Потребитель - офис. Блок - Grow. Драйвер - расширение штата. Основание - плюс 50 человек. Период - второй квартал.

CEO спросил: почему рост?

Открыли детализацию. Проверили драйвер. Выяснилось что фактического роста на 50 человек не будет.

Закупку скорректировали.

Модель не принимает решение. Она заставляет показать основание для денег.

Transform который нельзя резать как обычный OPEX

Решили менять кассовое ПО. Утвердили. Запустили пилотные магазины. Пилот прошёл нормально. Бизнес подтвердил эффект. При верстке бюджета на следующий год расходы на внедрение вписали в операционный - ПО же работает, значит это поддержка. На защите срезали операционный. Строка ушла. Никто не видел за ней Transform с окупаемостью.

В конце первого квартала следующего года: собственник спрашивает маркетинг - что с кассовым ПО? Маркетинг: ИТ не внедрило. ИТ: вы сами срезали бюджет. Круг замкнулся.

Разбирал эту ситуацию уже постфактум - в конце Q1. Вывели в отдельный проект с оценкой ROI и отдельной защитой через экономику.

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

Отдельный момент про проекты без очевидного финансового эффекта. Кадровый ЭДО нельзя защищать как финансовую инвестицию, пока не посчитаны часы, FTE и стоимость текущего бумажного процесса. Такой проект можно оставить в бюджете, но честно: не как ROI-кейс, а как управленческую гигиену, compliance или снижение операционного трения.

Как использовать модель при сокращении бюджета

Когда приходит задача срезать бюджет - плоская таблица провоцирует пропорциональный нож. Минус 10%, минус 20%. Выглядит как дисциплина. Но часто бьёт по критичному контуру и переносит риск в выручку.

В управляемой модели порядок другой.

Если строка Run и без неё магазин может остановиться - это не кандидат на линейное сокращение.

Если строка Grow, но драйвер роста не подтверждён - нужно остановить до подтверждения.

Если строка Transform, но нет влияния на OPEX, TCO или управляемость - это не Transform. Это расход с красивым названием.

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

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

Прикладной слой: как собрать такую модель

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

Если собирать модель руками - нужны реестры.

Модель держится на пяти источниках:

1. Реестр объектов - кто работает и когда.
2. Реестр касс, ФН и ОФД - где риск остановки продаж.
3. Реестр оборудования - стандарт запуска и замены.
4. Регулярные и периодические платежи - когда возникают обязательства.
5. Итоговый бюджет и Summary - где это превращается в управленческое решение.

Два момента перед тем как начать. Первый: номенклатура и статьи бюджета в каждой компании своя - логика Run/Grow/Transform добавляется как управленческий разрез поверх существующей структуры, финансовую номенклатуру менять не нужно. Второй: модель нужно усложнять только после того, как заработал минимальный контур.

Реестр объектов: кто и когда активен

Бюджет строится не от статей расходов, а от объектов которые эти расходы создают. Три типа объектов.

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

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

П - прошлогодние новые. Открылись в прошлом году, в текущем работают полный год. На сопоставимом периоде должны вести себя как С-объекты. Если ведут иначе - тоже сигнал.

Н - новые. Открываются в текущем году. Несут CAPEX запуска и OPEX с месяца открытия. Для новых объектов полезно сравнивать план текущего года с фактом прошлого по аналогичным объектам: разница в стоимости запуска - сигнал для разбора до того, как деньги потрачены.

Как собирать: список объектов берётся от владельца плана открытий - в разных компаниях это операционный директор, директор по развитию или CEO.

Реестр оборудования: стандарт объекта

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

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

Стандарт объекта формирует CIO совместно с владельцем объекта: для магазина - коммерческий или операционный директор, для склада - директор по логистике, для офиса - HR или административный директор.

Ежемесячные платежи: регулярный OPEX

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

Детализация по объектам принципиальна: у разных магазинов разные провайдеры и тарифы. Средний тариф по сети скрывает эту разницу. В рабочей модели сюда входят все ежемесячные расходы по статьям конкретной компании.

Периодические платежи: где прячутся сюрпризы

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

Правила из опыта: реестр ФН с датой по каждой кассе - не по магазину, а по кассе; смещение внутри магазина, чтобы кассы не заканчивались одновременно; замена за две недели до окончания.

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

Как всё собирается в бюджет

Все реестры - источники. Бюджет - сводный лист который тянет из них данные формулами. В каждой строке видно: тип расходов, блок Run/Grow/Transform, статус объекта С/П/Н, тип объекта, статья, помесячные суммы за текущий и прошлый год, дельта, источник данных.

Если хотя бы один из источников не обновляется - бюджет снова превращается в красивую таблицу с устаревшими предположениями.

Форма проверки спорной строки бюджета

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

Если строка Run и без неё магазин может остановиться - не кандидат на линейное сокращение. Если строка Grow, но драйвер не подтверждён - остановить до подтверждения. Если строка Transform без влияния на OPEX, TCO или управляемость - расход с красивым названием.

Где модель может обмануть

Модель не спасает, если:

• реестры не обновляются;
• драйверы роста не подтверждены бизнесом;
• Transform записан без расчёта эффекта;
• CAPEX и OPEX размечены вразрез с учётной политикой;
• бюджет можно обойти ручными перебросками между статьями.

В этом случае таблица снова становится красивой формой хаоса.

Цена модели

У этого инструмента есть цена.

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

Должен быть ответственный, который обновляет реестры. Если ответственного нет - модель деградирует за один бюджетный цикл.

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

Главный вывод

ИТ-бюджет нельзя защищать как таблицу расходов.

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

Пока за строкой не видно процесс, драйвер, владельца и цену удаления - собственник управляет не бюджетом. Он управляет набором сумм.

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

Он становится картой последствий: что будет, если срезать строку, перенести платёж или принять риск.

Без этого бюджет выглядит аккуратно.

Но управлять бизнесом по нему нельзя.

Если хотите посмотреть рабочий пример модели - напишите на e@sedegov.ru. Отправлю файл со структурой листов, реестрами, Summary и примерами расчёта. В нём видно, как бюджет собирается из объектов, касс, оборудования, подписок и сценарных проектов.