Почему линейное сокращение ИТ почти всегда бьет по P&L
Когда бюджет режут без смены модели, расходы не исчезают. Они переезжают в простои, ручной труд, аварии и потерянную скорость бизнеса.
Самая дорогая строка в P&L иногда выглядит как экономия.
Особенно в ИТ.
Сценарий обычно выглядит разумно. Собственник или CEO смотрит на цифры, сравнивает свой ИТ-бюджет с чужим и задает простой вопрос:
- У них меньше. Почему у нас больше?
После этого в компании часто начинается не управление затратами, а механическое урезание.
Кейс, который это хорошо показывает
У меня был показательный кейс.
Собственник увидел у знакомых владельцев бизнеса более низкий ИТ-бюджет и поставил своему ИТ-директору задачу:
- У других цифры ниже. Делай так же.
Директор пошел по самому слабому пути - просто срезал расходы.
На бумаге экономия появилась быстро.
В операционке почти сразу начались потери:
- выросли простои;
- замедлилось восстановление критичных сервисов;
- стало больше ручного тушения проблем;
- сильные люди начали выгорать;
- скорость изменений просела.
Когда я потом обсуждал с ним эту ситуацию, спросил прямо:
- Ты же понимал, что будут последствия. Зачем ты это сделал?
Ответ был предельно честный:
- Так сказал собственник.
И это очень важная точка для любого CEO и собственника.
Если ИТ-руководитель просто режет бюджет по команде сверху, не меняя модель работы, не считая последствия и не управляя ими, это не оптимизация функции.
Это перенос расходов из статьи "ИТ" в статьи "потери бизнеса".
Почему так происходит
Потому что бюджет становится меньше, а требования бизнеса - нет.
Кассы должны работать.Склад должен отгружать.Поддержка должна отвечать.Критичные системы должны восстанавливаться в срок.Проекты, от которых зависит выручка, не должны вставать.
То есть цена ошибки остается прежней.Нагрузка остается прежней.Ожидания остаются прежними.Сокращаются только ресурсы.
Дальше включается фальшивая экономия.
Компания как будто снизила OPEX на ИТ, но получила рост скрытых затрат:
- потерянную выручку из-за простоев;
- дорогие аварии вместо дешевой профилактики;
- ручную работу вместо устойчивого процесса;
- падение скорости изменений;
- рост зависимости от отдельных героев;
- потерю управляемости.
В этот момент проблема уже не в ИТ-бюджете.
Проблема в том, что бизнес начал экономить на модели, не меняя саму конструкцию функции.
Где собственник и CEO обычно ошибаются
Ошибка не в самом желании сократить затраты.
ИТ действительно можно и нужно оптимизировать.
Ошибка в другом: бизнес часто пытается получить более дешевую функцию без изменения требований к ней.
Это и есть главный управленческий самообман.
Нельзя оставить прежний уровень SLA, прежнюю скорость изменений, прежнюю отказоустойчивость и прежний масштаб поддержки, если вы просто убрали часть ресурсов и ничего не поменяли в модели.
В этот момент вы не снижаете стоимость функции. Вы ухудшаете систему и откладываете счет на потом.
А потом этот счет приходит в виде:
- срыва операций;
- ручного режима;
- перегруза ключевых людей;
- более дорогих аварийных решений;
- потери темпа бизнеса.
Что делает сильный CIO вместо линейного урезания
Сильный CIO не режет по живому.
Он пересобирает модель.
Нормальная логика выглядит так.
1. Не трогать критические сервисы
Если касса, склад, платежи или ключевая интеграция должны восстанавливаться за час, это нельзя резать ради красивой цифры в бюджете.
Сначала надо честно определить, что для бизнеса критично, и защитить это.
2. Отделить критичное от терпимого
Не все сервисы одинаково важны.
Часть некритичных функций действительно можно временно перевести в более дешевый режим:
- реже обслуживать;
- дольше чинить;
- перевести на инцидентную модель;
- заморозить развитие.
Но это должно быть сознательное решение, а не хаотичное ухудшение всего сразу.
3. Остановить все, что не дает прямого эффекта
Хотелки, второстепенные доработки, приятные, но не обязательные инвестиции должны уходить на паузу первыми.
Экономия без приоритизации почти всегда бьет по полезной работе вместе с бесполезной.
4. Считать не только экономию, но и цену решения
Правильный вопрос не "сколько мы сократили", а:
- что станет медленнее;
- где вырастет риск;
- сколько стоит один простой;
- что произойдет со SLA;
- как изменится TCO функции через 6-12 месяцев.
Пока этого расчета нет, разговор про "снижение ИТ-затрат" остается бухгалтерской иллюзией.
5. Сделать последствия прозрачными для CEO и собственника
Нужно показывать не только сумму сокращения, но и всю управленческую механику:
- что сократили;
- что не трогали;
- какие риски приняли;
- что изменится во времени реакции, восстановлении и объеме сервиса;
- где экономия реальная, а где она просто уехала в другую статью потерь.
Если этой прозрачности нет, бизнесу продают не экономию, а иллюзию контроля.
Главный вывод
Сокращать ИТ можно.
Сокращать его вслепую - нельзя.
Линейное урезание без смены модели почти никогда не снижает стоимость функции по-настоящему. Оно просто переносит расходы из OPEX в убытки бизнеса.
На бумаге ИТ стало дешевле.В реальности компания заплатила больше.
Сильный CIO снижает затраты не через механическое срезание, а через redesign модели: убирает хаос, дублирование, ненужную сложность и расходы без ценности для бизнеса.
Все остальное - это не оптимизация.
Это отложенный счет, который бизнес все равно оплатит.
CTA
Во сколько вашей компании на самом деле обходится не ИТ-бюджет, а "дешевое ИТ" после линейного урезания?