ТЭО внедрения ITAM: как посчитать эффект и обосновать проект

Методология расчета экономического эффекта на сквозном примере обезличенного ТЭО для крупной распределенной компании с собственной серверной инфраструктурой

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

Эта статья — про то, как ответить на него так, чтобы обоснование выдержало разбор финансового директора. Разбираем методологию на сквозном примере: обезличенном ТЭО для крупной распределенной компании с собственной серверной инфраструктурой — около 4 000 физических серверов, 350 стоек и 20 000 инфраструктурных активов, 6 крупных серверных площадок и порядка 60 распределенных объектов. Горизонт расчета — 3 года; цифры иллюстративные. Забегая вперед — консервативная модель на этом профиле дает базовый эффект около 100 млн ₽, ROI ≈89%, окупаемость на третий год и NPV ≈30 млн ₽. И, что важнее самих чисел, каждую цифру в ней можно защитить.

Почему обоснование ITAM обычно проваливается

Большинство бизнес-кейсов гибнут одинаково — тремя способами. Качественный: «станет прозрачно, повысим управляемость» — все правда, но денег в этих словах нет, и в модель окупаемости их не занести.

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

Подменный (выручка вместо экономии): в эффект записывают оборот от «новых возможностей», хотя выручку зарабатывает бизнес, а не система учета.

Финансовому блоку нужен не «эффект вообще», а ответ по каждому рублю на пять вопросов: какой это драйвер, от какой базы считается, какая доля реально поддается оптимизации, за вычетом чего и когда эффект появится.

Принцип модели: эффект = база × применимость × зрелость

В основе всей модели — одна универсальная формула. Любой драйвер эффекта считается так:

База — реальная статья бюджета клиента (закупки оборудования и ЗИП, лицензии и поддержка, трудозатраты), а не цифра «с потолка».

Применимость — сознательное срезание базы до той части, где система действительно работает: не весь объем поддается оптимизации.

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

Пять драйверов экономического эффекта

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

Самый крупный — переиспользование невостребованных ресурсов. Система выявляет оборудование и мощности, которые можно вернуть в доступный пул и использовать вместо новой закупки: это прямой предотвращенный CAPEX. В примере годовой бюджет закупок серверного и инфраструктурного оборудования составляет около 420 млн ₽. Консервативно считаем, что примерно 7% потребности потенциально может быть закрыто за счет уже имеющихся ресурсов, а реальную новую закупку замещают только 70% подтвержденных возможностей. На зрелой стадии это около 21 млн ₽ предотвращенного CAPEX в год, или примерно 36 млн ₽ за три года с учетом постепенного выхода на полный эффект. Стойки и серверы здесь используются для описания масштаба инфраструктуры, но сам эффект считается от денежной базы закупок — так проще проверить расчет и избежать двойного счета.

Трудозатраты считаются так же прозрачно: 60 распределенных объектов × 30 часов ручных сверок и уточнений в месяц плюс около 400 часов центральной команды — это примерно 26 400 часов в год. При полной стоимости часа 2 000 ₽ база составляет около 53 млн ₽ в год; автоматизируется и высвобождается для других задач около четверти, то есть ≈13 млн ₽ в год на зрелой стадии и ≈23 млн ₽ за три года. Важно: это высвобождение людей на другие задачи, а не сокращение штата.

Остальные три драйвера устроены по той же логике. Закупки и ЗИП — меньше избыточных и дублирующих закупок от базы за вычетом уже учтенного переиспользования; в примере это около 20 млн ₽ за три года. Лицензии, подписки и поддержка — отмена лишнего и исключение сервисных контрактов по неиспользуемым активам, около 15 млн ₽. Ошибки и простои — меньше переделок, повторных выездов и нарушений SLA из-за неактуальных данных, около 8 млн ₽. Репутационный ущерб не считаем вообще — только прямые деньги.

Upside, который нельзя класть в ROI

Есть эффект, который в ROI класть нельзя. Освободившийся ресурс может позволить раньше запустить новую услугу и получить дополнительную маржу — в примере это порядка 10–12 млн ₽ за три года. Но это маржа, а не гарантированная экономия, и ее нельзя засчитывать одновременно с предотвращенным CAPEX по тому же ресурсу. Поэтому upside выносим за скобки ROI. Правило простое: по одному ресурсу — либо предотвращенный CAPEX, либо маржа за ускорение, но не то и другое сразу. Добровольно вынести самую «вкусную» цифру за скобки — лучший способ повысить доверие к остальным.

Защита от двойного счета — признак честной модели

Если в ТЭО нет явного блока про защиту от двойного счета, финансист будет исходить из того, что двойной счет там есть. В нашей модели пять правил:

1. Драйвер 1 считает предотвращенную закупку по подтвержденной возможности переиспользования; один и тот же сервер, место в стойке или порт не превращаются в несколько отдельных эффектов.
2. База закупок и ЗИП берется за вычетом закупок, уже предотвращенных за счет переиспользования в драйвере 1.
3. Выручка целиком в эффект не входит — только маржа за ускорение и только как upside вне ROI.
4. Энергопотребление — не отдельный драйвер: учитывается, только если доказуемо связано с ресурсом или ошибкой.
5. Все вводные — редактируемые и прозрачные: базы, доли и ставки задает клиент.

Как читать финансовые метрики

Драйверы и полную стоимость проекта — внедрение, интеграции, лицензирование и поддержку — сводим в денежный поток (млн ₽):

Первый год планово убыточен: основные затраты на внедрение уже понесены, а эффект только разгоняется. По итогам второго года накопленный результат еще около нуля, а в третий год становится устойчиво положительным — это простая окупаемость. Дисконтированная окупаемость при ставке 14% также наступает в третий год. Итог за три года: базовый эффект ≈102 млн ₽, затраты проекта ≈54 млн ₽, чистый эффект ≈48 млн ₽, ROI ≈89%, NPV ≈30 млн ₽.

Короткий глоссарий, который полезно вынести и в сам документ ТЭО:

Возражение «а вдруг завышено» и как собрать свое ТЭО

Возражение о завышении прозвучит обязательно. Ответ — не спорить, а показать, что модель уже консервативна: для переиспользования учитываем только около 7% потребности в закупках и считаем, что новую закупку реально замещают 70% подтвержденных возможностей; по закупкам и ЗИП берем эффект в несколько процентов от базы; зрелость эффекта закладываем примерно на 25% в первый год, 50% во второй и 100% только в третий; upside оставляем за скобками. Лучший прием — собрать три сценария (пессимистичный / базовый / оптимистичный) на одних формулах: когда даже пессимистичный остается приемлемым, разговор смещается с «верю / не верю» на «в каком диапазоне выгода».

Чтобы повторить расчет на своей инфраструктуре:

1. Возьмите горизонт и ставку дисконтирования у финансового блока.
2. Соберите базы из реального бюджета: ресурсы, закупки и ЗИП, лицензии и поддержку, фонд трудозатрат.
3. Задайте по каждому драйверу долю применимости и коэффициент зрелости по годам — консервативно.
4. Пропишите защиту от двойного счета и вынесите выручку/ускорение в upside вне ROI.
5. Сведите денежный поток, посчитайте чистый эффект, NPV, ROI и обе окупаемости, постройте три сценария.

Откуда берутся достоверные данные для расчета

У методологии одно слабое место, и оно не в формулах: расчет достоверен ровно настолько, насколько достоверны базы под ним. Если парк ресурсов, загрузка мощностей и связи активов в учетных системах разошлись с реальностью — а в крупной распределенной инфраструктуре так почти всегда, — ТЭО стоит на песке. Поэтому предпосылка честного обоснования — достоверная модель активов, ресурсов и мощностей: данные из discovery, мониторинга, учетных систем и заявок, очищенные, нормализованные и проверенные на расхождения. Ровно эту задачу решает платформа SkyV ITAM — и на ее данных расчет эффекта перестает быть упражнением в предположениях и становится обоснованием, которое можно защитить.