16 марта 2026 г.

Дмитрий Лившин

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

Тревожные сигналы

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

Рассинхронизация

Первый и самый важный признак — отсутствие синхронизации между ИТ-подразделением и менеджментом, когда «левая рука не знает, что делает правая». Эффективный ИТ-департамент кроме поддержки существующей инфраструктуры должен быть опорой бизнесу, усиливая его рентабельность — то есть заниматься именно теми проектами, которые помогут бизнесу проще и быстрее масштабироваться и в итоге стать более эффективным и конкурентоспособным. Если руководство не понимает, что делает ИТ, а ИТ не понимает, чего ожидает от него руководство — это значит, что от 30% до 50% бюджета тратится неэффективно.

Отсутствие целей, метрик и планов на будущее

Отсутствие продуманной и прописанной стратегии развития ИТ и ИБ в компании — второй важный признак. Когда направления развиваются фрагментарно, бессистемно, без общей выстроенной карты существующего и перспективного ИТ-ландшафта, это часто приводит к необходимости переделывать уже сделанное: приходится повторно внедрять те или иные системы и решения или заменять их на другие до того, как они успевают окупиться.

Сюда же можно отнести отсутствие ясных и прописанных приоритетов для внутренних и клиентских систем и их функционала, а также утверждённых SLA (соглашений об уровне сервиса), RTO (Recovery Time Objective), задающих параметры восстановления систем после сбоя, и RPO (Recovery Point Objective), определяющих количество данных, которые компания может позволить себе потерять с момента последнего бэкапа.

Отсутствие таких соглашений и метрик явно означает, что либо в компании сильно превышены ресурсы на каждую из ИТ-систем, поскольку не определена степень их критичности для бесперебойной работы бизнеса, либо компания переплачивает на этапе восстановления при сбоях (замене компонентов, ремонте или восстановлении данных).

Отсутствие анализа рисков

Если в компании не проведена работа по составлению карты рисков с точки зрения ИБ, это может означать, что она тратит избыточные средства на попытки достичь некоего «идеального» уровня защищенности. Лучшей практикой было бы определение пределов возможного ущерба в случае тех или иных инцидентов и соотнесение возможных рисков с затратами на укрепление информационной защиты. Иногда оказывается, что проще раз в год потратить несколько сотен тысяч рублей на восстановление того или иного участка ИТ-инфраструктуры, чем десятки миллионов в год на его защиту.

Аппетиты подрядчиков или безграмотность заказчиков

Если компания переплачивает за услуги в сфере ИТ и ИБ, это не обязательно свидетельствует о жадности подрядчиков или бездарности её менеджмента.

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

Когда бюджет подготовлен, он должен пройти утверждение в так называемом ИТ-комитете (в некоторых корпорациях — в инвестиционном комитете), где проект рассматривается с точки зрения финансовой целесообразности. Если этого нет, то до реализации может дойти проект с ROI (возвратом на инвестиции) меньше, чем х3-х5 на горизонте 2-3 лет. Если же этот этап соблюдён — он позволит избежать затрат на проекты с низкой эффективностью и сосредоточить все ресурсы на более эффективных направлениях, а сэкономленные средства перераспределить на другие направления, прямо влияющие на генерацию выручки.

Единственное исключение может быть сделано для крупных инфраструктурных проектов — например, по внедрению новой ERP-системы или построению собственного серверного парка. Жизненный цикл таких проектов должен рассматриваться и рассчитываться с горизонтом в 5-7 лет или больше.

Грамотная организация закупок

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

Даже с учётом сказанного выше, опытные закупщики могут организовать ещё и переторжку, которая проводится по итогам состоявшихся торгов (особенно если их участники шли, что называется, «ноздря в ноздрю»), что иногда позволяет снизить цену лота ещё на 15-20%. При таком подходе у подрядчиков просто не остаётся простора для манипуляций с ценой и маржинальностью.

Кому нужны оценка бюджета и аудит ТЗ

Аудит эффективности работы ИТ-подразделения, зрелости процессов и эффективности затрат — мероприятие не дешёвое, поэтому смысл проводить его начинается при годовых затратах на ИТ от 200 млн руб. Только тогда внедрение полученных в результате рекомендаций обычно с лихвой окупается в течение последующих двух лет.

Аудит ТЗ на новый проект имеет минимальный порог примерно в 50 млн руб., причины аналогичные: результатом должна стать не менее чем трехкратная (а лучше пятикратная) экономия по сравнению с его стоимостью.

Поэтому спрос на такие услуги обычно ограничен размерами бизнеса и редко востребован в МСП.

Как определить адекватную цену?

Если использовать описанную выше схему организации закупок, то цена всегда будет адекватной. В дополнение замечу лишь, что разброс цен на небольших тендерах до 5 млн руб. в основном связан с внутренними нормами маржинальности. Небольшой ИП может выполнить работы по аудиту на комплаенс по 152-ФЗ или настроить межсетевой экран за меньшие деньги, чем крупная компания, которая несёт большой объём косвенных затрат (аренда офиса, бухгалтерия, маркетинг, юристы и т. п.) и вынуждена закладывать часть этих затрат на каждый свой проект.

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

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

Что является результатом оценки проекта или работ?

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

Что касается оценки технического задания, то мы не просто помогаем клиенту снизить НМЦ, но и предлагаем варианты изменения документации для снижения рисков как для самого клиента, так и для будущих подрядчиков. Обычно также указываем на потенциально узкие места, которые всплывут при эксплуатации системы, и помогаем скорректировать проектную документацию таким образом, чтобы для подрядчиков не осталось «слепых зон» и их скорректированная оценка подразумевала меньшие риски.

А если проблема не в цене?

Да, мы регулярно наблюдаем, что предложение, сделанное подрядчиком, является следствием непроработанной постановки задачи со стороны заказчика. Это и необоснованные требования, и слабо продуманный ИТ-ландшафт, и отсутствие ясной картины того, как именно бизнес выиграет от использования данного продукта.

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

Чем отличается подход к оценке ИТ и ИБ проектов?

В целом подходы не отличаются: и там, и там необходимо оценивать и стоимость внедрения, и стоимость владения, и возможности последующего развития хотя бы на 3 следующих года. И обычно вопрос не только в лицензиях или инфраструктуре, но и в FTE (человеческом ресурсе), необходимом для поддержки и развития новой системы.

И конечно же, никогда не стоит упускать из виду ROI от внедрения, чтобы не создавать ситуации, когда бизнес инвестирует в заведомо убыточную затею.

Чек-лист для ЛПР

Итак, кратко суммирую всё сказанное в виде простого списка.

Приступая к подготовке решения о разработке, приобретении или внедрении той или иной системы или решения, вам необходимо иметь:

  • чёткую стратегию развития своих ИТ- и ИБ-подразделений, синхронизированную с бизнес-целями компании и соответствующую вызовам, которые перед ней стоят;

  • контролирующий орган, который уполномочен в том числе отказаться от проекта, если выяснится, что проект не принесёт ценности для бизнеса или его инвестиционные параметры не дотягивают до целевых;

  • чёткие критерии приёмки выполненных работ или оказанных услуг, подтверждающие, что выделенные средства потрачены целевым образом;

  • жёсткие процедуры контроля исполнения бюджетов;

  • процедуры организации конкурентных закупок;

  • исчерпывающую и корректную закупочную документацию или ТЗ.

Источник: Дмитрий Лившин, генеральный директор «САЙБЕР Бизнес Консалтинг»