ИТ-аудит бизнеса нужен не только тогда, когда ломаются серверы, не сходятся интеграции или подрядчик сорвал сроки. Часто он помогает ответить на более управленческий вопрос: зачем компании каждая технология, сколько она стоит и какой результат дает бизнесу. В деловой среде такую проверку часто называют и IT-аудит — по сути речь идет об оценке всего ИТ-ландшафта компании.
Переплата в ИТ редко начинается с одного завышенного прайса. Чаще она появляется там, где компания не может внятно объяснить, зачем ей система, внедрение, команда или подрядчик. Под неясную задачу закладываются риски в смете, покупаются лицензии, нанимаются люди, поднимается инфраструктура. Через год или два собственник смотрит на ИТ-бюджет и уже не понимает, почему он вырос.
Разбираться стоит по порядку: сначала понять, есть ли повод для проверки, затем собрать данные, связать каждую технологию с бизнес-задачей и только после этого искать, где утекают деньги.
Когда бизнесу нужен ИТ-аудит
Первый повод — ИТ-бюджет растет быстрее, чем сам бизнес. Если у компании не появилось нового направления, не выросло число пользователей, не запускались сложные продукты, а расходы на технологии прибавили десятки процентов за год, это повод разобраться в причинах.
Диана Распопова предлагает относиться к таким цифрам как к ориентиру, а не как к универсальной норме. По ее оценке, часть роста может быть объяснима внешними факторами: дорожают специалисты, софт, инфраструктура, меняются условия поставщиков. Но если рост становится резким и плохо объяснимым, скорее всего, часть причин находится внутри компании.
Второй повод — компания уже пытается что-то внедрить, тратит деньги и время, но результата нет. Объяснения могут быть разными: «не хватает данных», «подрядчик не успевает», «пользователи сопротивляются», «система почти готова». Для аудита важно не название проблемы, а сам факт: нужный бизнесу результат не появляется.
Третий повод — компания только собирается в большое внедрение. Все вокруг говорят, что система нужна, бюджет измеряется миллионами, но собственник или генеральный директор не понимает, что именно покупает и какой эффект должен получить. В такой ситуации аудит помогает проверить логику решения до того, как деньги уже потрачены.
Три признака, что проверку лучше не откладывать
- ИТ-расходы растут, а объяснить рост никто не может;
- внедрение идет месяцами, но границы результата постоянно сдвигаются;
- компания готовится к дорогому технологическому проекту, но бизнес-эффект не посчитан.
Что собрать перед аудитом
Набор документов зависит от цели проверки. Если компания оценивает устойчивость ИТ-функции, понадобятся данные об инфраструктуре, резервировании, размещении систем, критичных контурах. Если главная задача — найти переплату, фокус будет другим.
Для аудита стоимости нужны все данные, которые показывают, сколько компания тратит на технологии и зачем: перечень систем, лицензии, договоры с подрядчиками, сметы, расходы на инфраструктуру, ФОТ ИТ-команды, число пользователей, владельцы процессов, история роста расходов за последние годы.
Главное — заранее описать проблему. Что именно компания хочет проверить: рост бюджета, стоимость подрядчика, спорное внедрение, дублирующие сервисы, зависимость от одного специалиста, неиспользуемые лицензии. Без этого аудит превращается в сбор документов ради документов.
Если проблема на самом деле находится не в технологии, а в исходном бизнес-процессе, автоматизация ее не исправит. Об этом мы отдельно писали в статье «Оптимизация бизнес-процессов: с чего начать».
Как связать технологию с бизнес-задачей
После сбора данных начинается главный этап: нужно понять, какую задачу решает каждая система, интеграция, доработка или команда. Технология должна быть связана не с абстрактным «развитием», а с понятной бизнес-целью: сократить расходы, ускорить операцию, повысить выручку, снизить риск, дать возможность масштабироваться.
Диана предлагает смотреть на три критерия.
- Связь со стратегией. Технология должна работать на перспективу, а не на отдел, который через год компания планирует перестраивать или сокращать.
- Влияние на деньги. Решение должно либо сокращать расходы, либо увеличивать прибыль, либо снижать риск, который можно перевести в деньги.
- Соотношение эффекта и цены. Даже полезная система может быть неоправданно дорогой, если эффект мал относительно стоимости внедрения и дальнейшей поддержки.
Типичная ошибка — начинать с инструмента, а не с задачи. Например, компания формулирует цель как «владеть данными по клиентам» и решает внедрять CRM. Но при разборе выясняется, что данные уже есть: клиенты приходят через сайт, заявки фиксируются, контакты не теряются. Не хватает не CRM, а нормальной аналитики: откуда приходят клиенты, какие каналы окупаются, где падает конверсия. В такой ситуации дорогая CRM может не решить исходную задачу.
Чем точнее компания понимает, что ей нужно, тем легче определить, за что платить не стоит. Иногда бизнес переплачивает не за функцию, а за бренд вендора, за лишние модули, за сложную интеграцию, за поддержку, которая не нужна в таком объеме, или за систему, которую никто не использует.
Где чаще всего скрывается переплата
Первая зона — люди. В ИТ персонал часто составляет основную часть расходов, поэтому именно ФОТ сильнее всего влияет на бюджет. Бывает, что человека наняли под задачу, задача давно закрыта, а чем он занят сейчас, никто не проверяет. Или должность появилась не потому, что она нужна структуре, а потому что конкретного сотрудника хотели удержать и дать ему рост.
Вторая зона — инфраструктура и учетные записи. Серверы, тестовые среды, облачные мощности, корпоративная почта, документы, мессенджеры и другие сервисы могут продолжать оплачиваться, хотя проект закрыт, среда давно не нужна, а пользователи уволились.
Третья зона — внедрения без понятной цели. Иногда компания начинает проект, потому что новый руководитель привык к другому инструменту, потому что «у всех уже есть», потому что подрядчик красиво показал презентацию или потому что внутри накопилась усталость от хаоса. Но если не сформулировано, какой процесс меняется и что будет считаться результатом, проект быстро превращается в дорогое движение без финальной точки.
Отдельно стоит смотреть на новые ИИ-инструменты. Они могут дать реальную пользу, но только если понятна задача, данные, ответственный и метрика эффекта. О том, где искусственный интеллект действительно помогает малому бизнесу, а где создает иллюзию внедрения, мы писали в материале «ИИ в малом бизнесе: 9 экспертов о внедрении, ошибках и реальной пользе».
Как проверить подрядчика и смету
Часть переплаты приходит извне: со сметой вендора, интегратора или команды разработки. Здесь работает простое правило: чем абстрактнее задача, тем больше рисков подрядчик заложит в цену. Коммерческая команда не будет брать на себя неопределенность бесплатно.
Если внутри компании есть понимание задачи, нужно внимательно смотреть защиту сметы: что конкретно заложено в проект, сколько часов отведено на каждую часть, какие специалисты участвуют, что входит в стоимость, а что не входит. Особенно важны скрытые расходы: поддержка, дополнительные доработки, интеграции, обучение, эксплуатация после запуска.
Если внутри нет сильной технической экспертизы, Диана советует начинать с предпроектного исследования. Оно стоит меньше полноценного внедрения, но помогает уточнить требования, убрать лишние риски из сметы и получить более управляемый план. По сути это способ не покупать большой проект вслепую.
Есть и механические проверки, которые доступны руководителю без глубокой ИТ-подготовки. Можно запросить почасовку и состав команды, затем сверить, сходятся ли часы и роли. Можно попросить подрядчика показать релевантные кейсы: что похожего он уже делал, в какие сроки, с каким результатом. Можно прямо попросить объяснить логику дорогого решения и предложить более простой вариант.
Например, полноценная интеграция с 1С может стоить несколько миллионов. Но если бизнес-задача закрывается регулярной выгрузкой данных в согласованном формате, решение может оказаться заметно дешевле. Важен не сам факт «интеграции», а то, какой результат нужен компании.
При работе с внешними исполнителями важно сохранять контроль над доступами, документацией и результатом. Подробнее об этом — в статье «Какие задачи опасно отдавать подрядчикам без контроля».
Что нельзя сокращать без оценки риска
ИТ-аудит не должен превращаться в упражнение «срезать все, что дорого». Часть расходов может выглядеть избыточной только на первый взгляд. Резервирование, безопасность, мониторинг, поддержка критичных систем, качественная документация и надежная инфраструктура не всегда дают быстрый видимый эффект, но защищают бизнес от остановки.
Поэтому вопрос должен звучать не «как сделать дешевле любой ценой», а «какой риск мы получим, если перестанем за это платить». Иногда отключение лишних лицензий дает экономию без ущерба. А иногда сокращение поддержки может привести к простою, потере данных или срыву операционной работы.
Хороший аудит не только находит лишние расходы, но и отделяет их от затрат, которые бизнесу нужны для надежности, безопасности и роста.
Что делать после аудита
Если аудит проведен правильно, приоритизация появляется вместе с результатом. Изменения можно разделить на три группы: быстрые исправления, системные решения и риски, которые нельзя откладывать.
Начинать логично с быстрых исправлений, которые дают понятный эффект без большого проекта: отключить неиспользуемые лицензии, убрать учетные записи уволенных сотрудников, погасить забытые тестовые среды, остановить внедрение, у которого нет сформулированного результата.
Системные решения требуют больше времени: пересмотр команды, смена архитектуры, перепроектирование процесса, новая договорная модель с подрядчиком, предпроектное исследование перед крупным внедрением. Их нельзя делать импульсивно, но и откладывать бесконечно тоже опасно.
Эффект проверяют теми же показателями, по которым обнаружили проблему: общий ИТ-бюджет, расходы на софт, инфраструктуру, ФОТ ИТ-команды, стоимость подрядчиков, скорость проектов, число неиспользуемых лицензий, количество ручных операций. Горизонт у показателей разный: лицензии могут дать экономию уже в следующем месяце, а изменения по ФОТ часто видны только через квартал.
Кейс: ИТ-бюджет вырос на треть без роста бизнеса
К Диане обратился собственник среднего бизнеса. За год ИТ-бюджет вырос примерно на треть, но в компании не появилось нового направления, не увеличилось число пользователей и не запускались новые продукты. На вопрос «почему стало дороже» внутри никто не мог ответить целиком: каждый видел только свой участок.
Аудит показал три источника переплаты. Во-первых, часть сотрудников была нанята под задачи, которые уже закрылись, но их текущая загрузка не была пересмотрена. По оценке Дианы, около 20% персонала можно было вывести из избыточной структуры без потери критичных функций.
Во-вторых, компания продолжала оплачивать мощности, тестовые среды, лицензии и учетные записи, которые уже не использовались. Эти расходы выглядели небольшими по отдельности, но вместе заметно увеличивали бюджет.
В-третьих, бизнес готовился к крупному ERP-проекту на десятки миллионов рублей, хотя никто не мог четко сформулировать проблему, границы внедрения и будущую стоимость эксплуатации. По итогам проверки проект вернули на предпроектную проработку и пересчет.
Быстрые решения сработали почти сразу: лишнюю инфраструктуру погасили, учетные записи и лицензии вычистили. Решения по людям дали эффект позже, на горизонте квартала. В итоге темп роста ИТ-бюджета вернулся к уровню около 8% в год.
Что руководитель может проверить сам
Короткий чек-лист перед ИТ-аудитом
- возьмите ИТ-расходы за последние 2–3 года и посчитайте темп роста;
- составьте список всех систем и напротив каждой напишите, какую бизнес-задачу она решает;
- по каждой системе запросите список реальных пользователей;
- сверьте учетные записи в корпоративных сервисах со штатным расписанием;
- по каждому человеку в ИТ уточните, под какую задачу его нанимали и чем он занят сейчас;
- по каждому внедрению проверьте, когда результат обещали впервые и сколько раз срок сдвигался;
- по новой смете запросите почасовку и состав команды, затем проверьте, сходятся ли часы и роли.
Если после этих вопросов в компании появилось несколько зон, где никто не может объяснить, зачем нужна система, человек, подрядчик или внедрение, значит переплата уже есть. Хорошая новость в том, что часть таких расходов можно остановить быстро. Самое дорогое в ИТ часто лечится не сменой поставщика, а ясной задачей, ответственным владельцем и понятными критериями результата.
