
IT-отдел — это не просто техническая поддержка, а часть бизнеса, которая должна приносить измеримую пользу. Но многие руководители теряют контроль над бюджетом, ведь «процессы сложные, а язык специалистов — непонятный». И деньги уходят на ненужные обновления, затянутые проекты или завышенные сметы.
Даже на государственном уровне все чаще заявляют, что средства на IT-системы расходуются неэффективно. Итак, разберемся, как распознать проблему, пока потери не стали критическими.
Непрозрачность IT-расходов
Когда я провожу аудит, то часто вижу одну и ту же картину: собственник получает отчеты, перегруженные техническими терминами, но не понимает, как эти траты влияют на бизнес. Например, фразы вроде «расширение канала связи для обеспечения SLA» или «обновление модуля синхронизации» звучат солидно, но не объясняют, какую пользу это принесло компании.
За сложными формулировками могут скрываться дорогостоящие бессмысленные работы. И если решения принимаются «на доверии», а не на основе данных, так ли нужны эти расходы?
Как исправить?
- Требуйте перевода каждой статьи затрат на бизнес-язык: что покупаем, зачем и какого эффекта ожидаем.
- Привязывайте траты к простым метрикам: скорость обработки заказов, отсутствие простоев и так далее.
- Находите аналогии, понятные всем. Например, «модуль интеграции» — это «автоматический курьер, который передает заказы с сайта на склад без участия менеджера».
На одном из проектов я столкнулся с ситуацией, когда бюджет на разработку согласовывался разными командами по отдельности, поэтому не было единой картины. Мы провели детальный разбор и фасилитацию, то есть все активно высказались по теме. Выяснилось, что многие команды планируют к разработке одни и те же модули в своих системах. Мы снизили расходы на 40% и увеличили управляемость разрабатываемых продуктов, просто собрав всех вместе и задавая правильные вопросы.
Постоянные переносы сроков релизов
Задержки в IT — это не норма, а плохое управление. Да, иногда релизы срываются из-за внешних факторов, но если проект переносится третий раз подряд — это системная проблема.
Что может скрываться за переносами? Неверно оценили сроки на старте? Нет четкого плана и контроля? Или работы намеренно затягивают, чтобы продлить финансирование? Нужно разбираться.
Кейс: в Volkswagen Group Rus мы столкнулись с задержкой релиза мобильного приложения. После анализа оказалось, что задачи блокировались из-за плохой координации между командами. Мы внедрили методологию SAFe и четко распределили роли. В итоге последующие оценки сроков и реализации релизов стали подконтрольными, а расходы на команду прекратили раздуваться.
Почему это тревожно? Каждый перенос = дополнительные расходы на зарплаты, инфраструктуру и поддержку. Но главное — бизнес не получает запланированный результат, будь то новый продукт или автоматизация процессов.
Как решить проблему с переносом сроков?
- Фиксируйте изначальные сроки и причины переносов.
- Внедряйте визуальные инструменты: диаграммы Ганта, Kanban-доски.
- Если задержки повторяются, меняйте подход к управлению.
Запросы на дополнительный бюджет без изменений в бизнесе
Если компания не растет, но IT-отдел просит больше денег, это повод насторожиться. Например, обоснование вроде «серверы на грани перегрузки» звучит убедительно, но если объемы операций не изменились, стоит задать вопросы.
Если вы будете выделять больше денег, траты могут стать необоснованными. А бюджет, который отложат «про запас», обычно расходуют совсем неэффективно.
Что делать:
- Спрашивайте, как увеличенный бюджет повлияет на выручку или издержки.
- Сравнивайте предложения с рыночными альтернативами.
- Привлекайте независимых экспертов для оценки крупных запросов.
Годовой бюджет тратят «под ноль» каждый год
В некоторых компаниях IT-отдел стремится освоить весь выделенный бюджет до конца года. Необходимости нет, но вдруг в следующем году финансирование урежут? Такая практика опасна, поскольку приводит к пустым тратам и смещению приоритетов.
Почему это тревожный сигнал?
- Решения принимают, чтобы освоить бюджет, а не принести прибыль. Например, закупают лишнее оборудование «на будущее», хотя текущие мощности не загружены. Или внедряют второстепенные функции, которые не влияют на прибыль.
- Деньги уходят «про запас», а не на рост. IT-директор может аргументировать траты как: «Лучше перестраховаться». Но если нет четких KPI, это просто пустые расходы.
Что делать?
- Внедрите гибкий подход к бюджету. Разрешите переносить остатки на следующий год, но только с планом, куда он пойдет. И введите правило: если бюджет не освоен, это повод не сокращать его, а пересмотреть приоритеты.
- Привяжите IT-расходы к бизнес-метрамкам. Например: «Если мы тратим N рублей на облачные сервисы, это должно сократить время обработки заказов на Х%».
- Организуйте промежуточные проверки. Раз в полгода анализируйте, куда ушли деньги и какой эффект они дали. Если траты не принесли результата — меняйте подход.
Зависимость от одного поставщика
Если 80% IT-бюджета уходит одному подрядчику, вы рискуете не только переплатить, но и подвергнуть бизнес опасности. Особенно если подрядчик контролирует и оборудование, и разработку, и поддержку.
Чем это опасно:
- Ценовой диктат — подрядчик может постепенно повышать цены, ведь у компании нет альтернатив.
- Снижение качества — когда нет конкуренции, незачем особенно стараться.
- Риск срыва сроков — если подрядчик загружен другими проектами, он может откладывать ваши задачи месяцами.
Предположим, вы подозреваете подобную ситуацию. Как это проверить? Во-первых, сравните цены с рыночными. Запросите коммерческие предложения у других вендоров, даже если не планируете менять подрядчика. Во-вторых, оцените SLA (уровень обслуживания). Если инциденты решаются неделями, а подрядчик ссылается на «загрузку», ищите замену.
Как предотвратить проблему в будущем?
- Разделите зоны ответственности. Например, один подрядчик отвечает за облачные сервисы, другой — за разработку, третий — за безопасность.
- Введите регулярные тендеры. Даже с любимым подрядчиком раз в год проверяйте рынок.
- Создайте «подушку безопасности». Документируйте процессы, чтобы при смене подрядчика не начинать с нуля.
Кейс с антипримером
Я несколько лет наблюдал за попытками развития и рефакторинга огромного монолитного сервиса, который закрывал более 60% операционных бизнес-процессов компании.
Проблема: сервис находился в руках одного подрядчика и даже разработчика. Я бы обозначил это как негативный флеш-рояль — вендор-лок и бас-фактор сразу.
Целых 5 лет компания тратила колоссальные ресурсы, пытаясь изменить ситуацию, пока бизнес страдал. К сожалению, попытки не увенчались успехом. Подобные ситуации нужно предотвращать изначально или выявлять на ранних стадиях.
В своих проектах я планирую архитектуру так, чтобы каждый контекст был независимым и его мог поддерживать любой разработчик.
Если вы обнаружили у себя несколько сигналов
Один тревожный признак — еще не катастрофа. Но если их три или больше, значит, в IT-управлении есть системные проблемы.
Вот пошаговый план действий.
- Проведите аудит. Разберитесь, куда уходят деньги, какие проекты затягиваются и почему.
- Переведите IT-отчетность на бизнес-язык. Каждая трата должна быть привязана к конкретной цели: рост продаж, снижение издержек и так далее.
- Внедрите контрольные точки. Например, ежеквартально проверяйте, насколько эффективны IT-расходы.
- Диверсифицируйте подрядчиков. Ни один вендор не должен контролировать больше 50% бюджета.
Не ждите, пока убытки станут критическими. Маленькая утечка быстро превращается в миллионы потерь.
Итог: IT — это не черный ящик, а часть бизнеса
Не понимаете IT-процессы? Значит, ими управляет кто-то другой. Но это можно исправить.
- Контролируйте бюджет — не через технические термины, а через бизнес-показатели.
- Задавайте вопросы — если IT-директор не может объяснить траты простыми словами, копайте глубже.
- Действуйте системно — внедряйте прозрачные процессы, а не разовые проверки.