IT-бюджет растёт быстрее бизнеса – и непонятно, за что вы платите?
Аудит архитектуры переводит расходы на IT на язык финансов: из чего складывается стоимость владения каждой системой, где переплата – и что можно сократить без риска для работы бизнеса. Приоритеты – по эффекту и трудоёмкости каждого шага.
Почему расходы на IT не поддаются контролю
IT-бюджет растёт быстрее бизнеса
Больше половины ИТ-бюджета – по бенчмаркам Deloitte, до 56% – уходит на поддержание существующего, и эта доля растёт. На развитие остаётся всё меньше, а из бюджетных статей не видно, что именно дорожает и обязана ли компания платить столько.
Стоимость владения системой никто не назовёт
Полная картина собственного технологического стека есть лишь у четырёх компаний из десяти (Flexera, 2025). Инфраструктура, лицензии, подрядчики, штат поддержки – в разных статьях; целой суммы по системе не знает никто, и «дорого или нормально» решается на ощущениях.
В смете сотни позиций – и ни одну не проверить
Смета детальная, согласование тянется месяцами – но вопрос всё тот же: обоснованы ли объёмы часов? Сверить трудоёмкость внутри компании не с чем, и после всех кругов согласований подписывается почти то, что просили изначально.
Разработка идёт – и тянет за собой инфраструктуру
Неоптимальное инженерное решение не видно в отчётах: оно выглядит как «нужно докупить серверы». Строка счёта растёт, но никто не связывает её с решением, принятым в конкретной команде год назад.
Одну и ту же работу делают разные команды
После реорганизаций и слияний остаются системы-дубли, и каждую поддерживает своя команда: два бюджета разработки, две инфраструктуры, доработки – в обе. Изнутри это выглядит нормой: у каждой системы же свои пользователи.
Сокращать страшно: вдруг что-то остановится
Неизвестно, какая строка бюджета держит продажи, а какая – привычка. Поэтому под нож не идёт ничего, и бюджет растёт дальше.
Это не особенность вашей компании – это норма отрасли: по данным McKinsey и Оксфордского университета (5 400+ проектов), крупные ИТ-проекты в среднем превышают бюджет на 45% и приносят на 56% меньше ожидаемого, а каждый шестой уходит в перерасход более чем вдвое. Аудит архитектуры – способ выйти из этой статистики: из чего складывается стоимость владения, где переплата и что сокращать безопасно.
Что смотрим в стоимостном разрезе
Проверку ведёт основатель-архитектор; под масштаб ландшафта привлекаются профильные эксперты по СУБД, интеграциям и инфраструктуре.
- Стоимость владения по системам: инфраструктура, лицензии, поддержка, доработки
- Дублирующие функции и параллельные решения от разных подрядчиков
- Избыточные мощности и неиспользуемые лицензии
- Поддержка устаревших решений – против стоимости их замены
- Обоснованность смет и объёмов работ подрядчиков
- Двойные расходы переходного периода: параллельная оплата старого и нового ПО при импортозамещении
- Расходы, которые вырастут при росте бизнеса: докупка мощностей, пиковые авралы
- Риски незапланированных трат: простои, потеря данных, зависимость от людей
Расходы на IT – на языке финансового директора
Знакомый разговор: IT-бюджет защищается словами «иначе всё встанет», сметы приходят одним числом, а на вопрос «почему так дорого?» ответ один – «так устроены системы». Аудит заканчивает этот разговор: вместо слов – цифры, которые можно проверить.
Карта стоимости владения
Сейчас: цифра в бюджете есть, а из чего она состоит – знает только IT
Каждая система – с полной стоимостью: инфраструктура, лицензии, подрядчики, доля штата поддержки. Впервые видно, какая система сколько ест и почему. Разговор с IT переходит от «нам нужно больше» к цифрам по строкам.
Точки переплаты – с фактами
Сейчас: подозрение, что переплачиваете, есть – предъявить нечего
Дубли функций после слияний и смен подрядчиков, мощности «про запас», лицензии, которыми никто не пользуется, поддержка умирающего продукта дороже его замены. По каждому пункту – проверяемый факт и цена вопроса в рублях за год.
План сокращения без риска для работы
Сейчас: резать страшно – никто не скажет, что от чего зависит
Сначала – список неприкасаемого: системы, которые держат выручку и обязательства. Потом – шаги сокращения по порядку: эффект, трудоёмкость и риск каждого. Вы сокращаете не «на ощупь», а по плану, где за каждый пункт можно спросить.
Инструмент контроля подрядчиков
Сейчас: смету согласуют месяцами, а проверить обоснованность часов всё равно некому
Независимая оценка трудоёмкости по позициям: где объёмы обоснованы, где раздуты, что дублирует уже сделанное. Согласование перестаёт быть перепиской на месяцы – у вас появляются аргументы по существу, и подрядчики считают внимательнее.
Каждый вывод – с фактом-основанием, которое можно проверить; решения о сокращениях принимаете вы.
Три шага до плана сокращения
Аудит идёт по авторской методике компании – на базе архитектурной оценки ATAM (Университет Карнеги-Меллон), дополненной стоимостным разрезом: каждая находка – с фактом-основанием и ценой вопроса в рублях за год. Выводы можно проверить по каждой строке.
Консультация
Час с архитектором: что в расходах беспокоит, где искать в первую очередь. 25 000 ₽ – зачитывается в стоимость аудита при договоре в течение 30 дней.
Аудит в стоимостном разрезе
Интервью с IT и финансовым блоком, разбор ландшафта и расходов на него. Работа в вашем контуре, под NDA, не мешая операционной работе.
Отчёт и разбор результатов с вами
Карта стоимости владения, точки переплаты, план сокращения с приоритетами – разбираем лично с вами, отвечаем на вопросы. Если решение выносится выше – готовим материалы для правления или совета директоров.
Срок и стоимость фиксируются в договоре до старта; сумма по ходу работы не растёт. Удобно приурочить к бюджетному циклу – приходите до вёрстки бюджета.
Алексей Козей
Основатель LBA · более 11 лет в коммерческом IT
Первую консультацию проводит лично: час разбора вашей ситуации с первичной оценкой и рекомендациями. Под масштаб ландшафта к аудиту привлекаются профильные эксперты – СУБД, интеграции, инфраструктура.
Что мы уже убирали из IT-бюджетов – без остановки работы
Нашли две команды, годами развивающие одно и то же
После реорганизации у двух подразделений остались свои системы одной функции: две инфраструктуры, два бэклога, каждая доработка заказывалась дважды, каждая новая интеграция строилась с обеими. План слияния – на базе более зрелой; вторая команда ушла на развитие, а не на дублирование.
Двойная разработка и двойная инфраструктура – в одну
Показали, что серверы докупались из-за одного решения в коде
Сервисы опрашивали базу каждые несколько секунд вместо подписки на изменения – с ростом клиентов нагрузка росла лавинообразно, и её годами заливали железом. Опрос заменили событиями в трёх ключевых местах; очередная закупка не понадобилась.
Рост клиентов перестал требовать роста серверов
Посчитали, во что обходится «каждая команда выбирает свой стек»
Пять СУБД, три очереди сообщений, четыре инструмента мониторинга – за каждым специалисты, дежурства, обновления и отдельная инфраструктура. Утвердили целевой стек и план сведения; новые проекты стартуют только на нём, старые сводятся по мере доработок.
Пять параллельных стеков поддержки – к двум
Нашли собственную разработку там, где есть штатная функция платформы
Генератор отчётов писали и поддерживали выделенные разработчики – годами, при живой штатной функциональности уже купленной платформы. Отчёты перевели на штатный механизм, разработчиков – на продуктовые задачи.
Команда – с поддержки «велосипеда» на развитие
Нашли три системы, считающие одни и те же остатки
Ночные сверки между ними съедали смены сотрудников и серверные часы, а доработки заказывались трижды – по одной на систему. Назначили единый источник данных, две системы перевели в читающие. Доработки и сверки из бюджета ушли.
Тройные доработки и ручные сверки – в ноль
Разложили бюджет поддержки по причинам затрат
Выяснилось: основная часть уходила не на развитие системы, а на компенсацию дефектов устаревшего продукта – дежурства, перезапуски, ручные сверки после сбоев. Аудит дал план поэтапной замены с параллельной работой; клиент реализовал его своей командой.
Стоимость поддержки ниже на 30–40%
Обнаружили, что хранение логов стоит дороже боевой базы
Сервисы писали всё подряд, логи хранились вечно и на быстрых дисках – «на случай разбирательств», которых не случалось. Ввели уровни логирования и сроки хранения, старое ушло в дешёвый архив. Разборы инцидентов не пострадали.
Счёт за хранение – втрое ниже
Сняли лавину одинаковых запросов к базе
Каждый сервис при каждой операции заново спрашивал у базы одни и те же справочники – миллионы одинаковых запросов в день. База «не справлялась», готовился апгрейд железа. Поставили кеширование в двух точках – апгрейд не понадобился.
Закупка под «слабую» базу отменена
Остановили полную перезаливку хранилища каждую ночь
Аналитическое хранилище каждую ночь перегружало все данные целиком – так исторически настроили, и никто не возвращался к вопросу. Перевели на загрузку только изменений; ночное окно и вычислительные мощности сжались кратно.
Ночные вычисления – с полной перезаливки на приращение
Разобрали кластер, построенный под нагрузку, которой не случилось
Систему спроектировали под рост в пятьдесят раз: распределённое хранилище, резервы, редкие специалисты. Рост оказался трёхкратным. Упростили до соразмерной конфигурации, заложив план расширения – если рост всё же случится.
Платили за гибкость, которой никто не пользовался
Сократили полторы сотни микросервисов до тридцати
Каждая мелкая функция жила отдельным сервисом – со своей инфраструктурой, сборкой, мониторингом и дежурством. Свели сервисы по бизнес-доменам; функциональность не изменилась, а обслуживаемых единиц стало впятеро меньше.
Впятеро меньше единиц инфраструктуры и дежурств
Показали, что тестовые среды стоят как второй прод
Каждая команда держала свои среды с полной копией боевых данных – круглосуточно, включая выходные. Ввели общий пул сред по расписанию и сокращённые обезличенные наборы данных. Тестирование не пострадало.
Тестовые среды перестали стоить как второй прод
Роль команды в проектах – архитектура решения; результаты приведены по данным проектов. Референсы – по запросу при обсуждении.
Что обычно спрашивают финансовые директора
IT-директор говорит, что резать нечего. Зачем тогда аудит?
Возможно, он прав – тогда вы получите обоснование каждой крупной статьи и уверенность при защите бюджета. Мы не ищем виноватых: аудит – это факты о стоимости владения, полезные и финансовому, и IT-директору. Разрыв взглядов здесь – норма, а не конфликт: по данным Gartner, 94% ИТ-директоров уверены, что понимают финансовое влияние технологий, – но согласны с этим лишь 62% финансовых директоров. Аудит даёт общую фактуру, на которой сходятся оба.
Не пострадает ли надёжность от сокращений?
План строится от обратного: сначала фиксируем, что трогать нельзя – системы, которые держат выручку и обязательства перед клиентами. Сокращения ищем в остальном, и по каждому пункту даём оценку риска. Пункт без оценки риска в план не попадает.
Почему ИТ-проекты постоянно выходят за бюджет?
Потому что так почти у всех: по исследованию McKinsey и Оксфордского университета на 5 400+ проектах средний перерасход крупного ИТ-проекта – 45% к бюджету. Механика известна: проблема в одном компоненте каскадом расходится по связанным интеграциям, и смета растёт там, где её никто не ждал. Поэтому мы начинаем с карты взаимозависимостей: аудит заранее показывает узлы, через которые распространяется перерасход, – и что укрепить до старта проекта, а не после.
Чем это отличается от финансового аудита?
Финансовый аудит видит суммы и проводки. Мы видим, что стоит за суммами: какие системы и технические решения делают их такими – и где технически возможно дешевле. Работаем в паре с вашими финансистами: они дают цифры, мы – их техническую причину.
Вы гарантируете сокращение на сколько-то процентов?
Обещать процент до обследования – недобросовестно, таких обещаний мы не даём. Результат аудита – проверяемые факты переплаты и план действий с оценкой эффекта каждого шага; решения принимаете вы. Нередко одна найденная статья – дублирующая система или неиспользуемые лицензии – сопоставима со стоимостью всего аудита.
Сколько это стоит и как долго?
Аудит – от 2 недель, от 500 000 ₽. Объём оцениваем на входе по итогам консультации и закрепляем срок и цену в договоре; сумма по ходу работы не растёт.
Что потребуется от нас?
Контактное лицо с полномочиями, интервью с IT и финансовым блоком (для ландшафта среднего масштаба – суммарно 30–40 часов ваших людей; точный объём зависит от масштаба и оценивается на входе), доступ к документации и данным о расходах. Работа с системами – в вашем контуре, под NDA; операционную работу не останавливаем.
Начните с самопроверки бюджета
Рабочие материалы из практики аудитов – по ним видно, как мы ищем переплату и как выглядит результат.
12 типовых точек переплаты в IT-бюджете
Чек-лист финансового директора: как переплата выглядит в бюджете и какой вопрос задать IT и подрядчикам, чтобы её проверить, – без погружения в технику. Каждый пункт – типовая находка из практики аудитов.
Скачать PDFПример полного отчёта аудита
Обезличенный образец: карта системы, реестр рисков, приоритеты и дорожная карта – в том виде, в котором результат ложится на стол руководителю.
Скачать PDFРазберём расходы на IT – до вёрстки следующего бюджета
Оставьте заявку – это бесплатно и ни к чему не обязывает: согласуем тему и время консультации. Консультация – час с архитектором, 25 000 ₽: разберём, что в расходах беспокоит, и скажем, где искать в первую очередь. При договоре на аудит в течение 30 дней стоимость консультации зачитывается в его цену.
Telegram: написать · Email: start@lbatech.ru