Как рассчитать TCO программного обеспечения для бизнеса

124

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

Бывает и обратная ситуация: более дорогая платформа оказывается выгоднее за счет автоматизации и меньших расходов на сопровождение.

Чтобы сравнить решения честно, используют показатель TCO - Total Cost of Ownership, или совокупную стоимость владения. Он показывает, сколько денег организация потратит на программный продукт за выбранный период: обычно за три, пять или семь лет.

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

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

Примеры будут связаны с CRM, ERP, системами электронного документооборота, корпоративными порталами и другими программами, которые используются в компаниях ежедневно.

Что такое TCO и зачем его считать

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

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

Например, у одной CRM стоимость подписки составляет 2 000 рублей за пользователя в месяц, а у другой есть бессрочная лицензия за 3 млн рублей.

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

Облачный сервис тоже не всегда дешев: платные модули, расширение числа пользователей и услуги интегратора способны заметно увеличить расходы.

Расчет TCO нужен в нескольких типичных ситуациях:

• при выборе новой корпоративной системы;

• при замене устаревшей программы;

• при переходе из локальной инфраструктуры в облако;

• при сравнении нескольких поставщиков;

• при подготовке бюджета на цифровизацию;

• при обосновании проекта перед руководством или собственниками;

• при оценке экономии от автоматизации.

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

Для этого задают одинаковый горизонт и считают все денежные потоки.

В упрощенном виде формулу можно представить так:

TCO = первоначальные расходы + регулярные расходы + внутренние расходы + затраты на риски − остаточная ценность.

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

В большинстве ИТ-проектов этот компонент небольшой, но полностью забывать о нем не стоит.

Определение границ расчета и периода владения

Первый практический шаг - определить, что именно считается и за какой период. Без этого TCO превращается в набор приблизительных цифр.

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

Границы нужно закрепить в отдельном документе или хотя бы на первой странице таблицы.

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

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

Иначе недорогая на старте система может оказаться непригодной для масштабирования.

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

Если программа критична для бизнеса и рассчитана на десятилетия, иногда используют семь лет, но прогноз на такой срок должен содержать сценарии, а не одну "точную" цифру.

При выборе периода полезно учитывать жизненный цикл оборудования и договора:

• рабочие станции часто меняют раз в четыре-шесть лет;

• серверы обычно обновляют примерно раз в пять лет;

• облачные подписки могут пересматриваться ежегодно;

• корпоративные системы получают крупные версии каждые несколько лет;

• договоры поддержки нередко заключаются на один год с продлением.

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

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

Еще один момент - учет инфляции и изменения тарифов. Если поставщик прямо указывает ежегодную индексацию, ее нужно заложить в расчет.

Если условия не определены, создают отдельный сценарий: базовый, оптимистичный и консервативный. Например, в базовом варианте тариф растет на 7 процентов в год, а в консервативном - на 12 процентов. Это честнее, чем делать вид, будто цена подписки пять лет не изменится.

Из чего состоит структура TCO

Правильная структура расчета разделяет расходы по природе и времени возникновения. Обычно выделяют единовременные, регулярные, внутренние и риск-ориентированные затраты.

Такое разделение помогает увидеть, почему проект может быть дешевым в эксплуатации, но дорогим на запуске, или наоборот.

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

Они особенно важны при выборе коробочных продуктов и крупных платформ.

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

Даже если поставщик рекламирует "фиксированный тариф", необходимо проверить, что именно в него входит.

Внутренние расходы часто не видны в коммерческом предложении, но могут составлять значительную часть TCO.

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

Риск-ориентированные расходы связаны с вероятными событиями. Например, система может потребовать срочной доработки, интеграция может выйти из бюджета, а простой сервиса - привести к потере заказов.

Не все риски можно выразить с высокой точностью, но хотя бы основные из них следует оценить вероятностным методом.

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

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

Лицензии, подписка и скрытые платежи поставщика

Лицензирование - заметная, но далеко не единственная часть TCO. Сначала нужно понять, за что именно платит компания: за пользователя, рабочее место, сервер, объем данных, транзакции, функциональный модуль или уровень обслуживания.

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

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

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

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

Для корректного расчета составьте каталог функций и сопоставьте его с тарифной сеткой. Не ограничивайтесь фразой "профессиональный тариф". В коммерческом предложении должны быть указаны:

• число лицензий и их тип;

• доступные пользователи и роли;

• лимиты хранилища;

• стоимость API и интеграций;

• цены дополнительных модулей;

• стоимость технической поддержки;

• правила индексации;

• условия досрочного расторжения;

• тарифы на перенос или выгрузку данных.

При бессрочной лицензии обычно платят за право использования конкретной версии или продукта. Но это не означает, что дальнейшая эксплуатация бесплатна.

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

В расчетах полезно разделять цену лицензии и стоимость доступа к актуальной версии. Если поставщик предлагает ежегодное сопровождение в размере 18 процентов от стоимости лицензий, то за пять лет только поддержка составит 90 процентов первоначальной цены без учета индексации.

Это не делает модель плохой, но показывает ее реальную экономику.

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

Такой прием особенно полезен для быстрорастущих компаний и сетевого бизнеса.

Внедрение, настройка и управление проектом

Внедрение - одна из самых недооцененных статей расходов. Под этим словом могут скрываться совершенно разные объемы работ: от подключения готового облачного сервиса за несколько дней до многолетней трансформации процессов с участием десятков специалистов.

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

Если подрядчик называет одну общую сумму, попросите расшифровку по этапам и результатам.

Примерная структура бюджета проекта может выглядеть так:

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

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

Если средняя стоимость часа сотрудника с учетом налогов и накладных расходов составляет 1 200 рублей, а команда суммарно потратит 2 500 часов, внутренний бюджет проекта составит 3 млн рублей. В счет поставщика эта сумма не попадет, но для TCO она реальна.

Еще одна частая ошибка - отсутствие резерва. В программных проектах изменяются требования, обнаруживаются проблемы в исходных данных, появляются новые обязательные интеграции. Для относительно понятного проекта можно заложить резерв 10–15 процентов от внешних расходов, а для сложной трансформации - 20–30 процентов.

Резерв не нужно тратить заранее, но он должен быть виден в модели.

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

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

Инфраструктура, безопасность и эксплуатация

Для локального программного обеспечения инфраструктура является обязательной частью TCO.

Потребуются серверы, системы хранения, сетевое оборудование, лицензии операционных систем и баз данных, средства виртуализации, резервное копирование, мониторинг и защита от несанкционированного доступа.

Цена сервера - только начало. Нужно учесть монтаж, замену дисков, продление гарантий, электроэнергию, охлаждение, резервное питание и работу специалистов.

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

Облачная модель переносит часть расходов поставщику, но не убирает их полностью.

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

Для каждого варианта следует определить требования к эксплуатации:

• допустимое время простоя;

• максимально приемлемую потерю данных;

• частоту резервного копирования;

• срок хранения резервных копий;

• порядок восстановления;

• ответственных за мониторинг;

• условия аварийной поддержки.

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

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

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

Если после запуска понадобится один специалист на полную ставку с годовой стоимостью 2,4 млн рублей, за пять лет только эта статья составит 12 млн рублей без учета индексации.

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

Поэтому корректнее говорить не об исчезновении расходов, а об их перераспределении.

Миграция данных, интеграции и доработки

Почти ни одна бизнес-программа не работает изолированно. CRM связана с сайтом, телефонией, почтой, системой аналитики и ERP. ERP обменивается данными с банком, складом, кадровой системой и электронным документооборотом.

Поэтому стоимость интеграций следует считать не по количеству красивых стрелок на архитектурной схеме, а по сложности каждого обмена.

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

Обмен остатками раз в сутки обычно проще, чем синхронизация заказов в реальном времени с контролем дублей и повторной доставкой сообщений.

Приблизительная оценка интеграции должна учитывать:

• анализ интерфейсов обеих систем;

• разработку коннектора или использование готового модуля;

• настройку авторизации и сертификатов;

• сопоставление справочников;

• обработку ошибок;

• нагрузочное и приемочное тестирование;

• мониторинг после запуска;

• поддержку при изменении внешнего API.

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

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

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

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

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

Если включить все пожелания в первый релиз, бюджет и сроки быстро выйдут из-под контроля.

Полезно оценить стоимость изменений после запуска. В стабильной системе ежегодные доработки могут составлять 5–15 процентов от бюджета внедрения, а в активно развивающемся бизнесе - значительно больше.

Если поставщик продает часы разработки, отдельно фиксируют их срок действия, минимальный объем заказа и правила переноса неиспользованного баланса.

Персонал, обучение и стоимость изменений

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

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

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

Кроме занятий, потребуются инструкции, короткие подсказки, база знаний и канал для вопросов.

Во время адаптации сотрудники работают медленнее. Если 100 пользователей в течение двух месяцев теряют 10 процентов продуктивности, а средняя стоимость рабочего часа составляет 1 000 рублей, при 160 часах в месяц потери составят примерно 3,2 млн рублей.

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

Внутренние роли проекта можно оценивать по формуле:

Стоимость участия = количество часов × полная стоимость часа сотрудника.

Полная стоимость часа включает зарплату, страховые взносы, отпускные, рабочее место и накладные расходы. Если использовать только оклад, расчет получится слишком оптимистичным. Для руководителей также можно учитывать альтернативную стоимость времени: какие задачи не будут выполнены из-за участия в проекте.

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

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

Иногда часть функций передают подрядчику, но тогда в регулярный TCO попадает договор сопровождения.

Уровень принятия системы можно контролировать показателями:

• доля активных пользователей;

• процент операций, выполненных в новой программе;

• число обращений в поддержку;

• доля ошибок в данных;

• среднее время выполнения ключевой операции;

• количество ручных обходных процессов.

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

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

Расчет рисков и сценариев

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

В базовом варианте используют наиболее вероятные значения, в оптимистичном - лучшие реалистичные условия, в консервативном - рост расходов и задержки.

Для численной оценки риска применяют ожидаемую стоимость события:

Ожидаемая стоимость риска = вероятность события × финансовое последствие.

Если вероятность трехмесячной задержки оценивается в 20 процентов, а содержание команды и перенос эффекта обойдутся в 4 млн рублей, ожидаемая стоимость риска равна 800 тысячам рублей.

Это не означает, что компания обязательно потратит эту сумму. Показатель нужен для сравнения проектов и формирования резерва.

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

Если последствия трудно оценить деньгами, используют диапазон. Например, интеграция может стоить от 1 до 2,5 млн рублей, а миграция - от 600 тысяч до 1,8 млн. В итоговой таблице отображают минимум, наиболее вероятное значение и максимум.

Такой подход лучше, чем необоснованная точность до последнего рубля.

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

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

Риск нужно проверять на переговорах. Поставщику задают вопросы о фиксировании цены, сроках реакции поддержки, компенсации простоев, условиях хранения данных и стоимости выхода.

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

Сравнение облачной и локальной модели

Облачное и локальное программное обеспечение отличаются не только способом размещения. Они по-разному распределяют расходы, ответственность и риски.

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

Для облачной системы в TCO включают подписку, подключение, настройку, интеграции, миграцию, обучение, дополнительные модули, платный объем хранения и внутреннее администрирование.

Если сервис требует выделенного канала или локального шлюза, соответствующие расходы тоже добавляются.

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

Если используется собственный дата-центр, в модель попадают аренда площадки, климатическое оборудование и бесперебойное питание.

Пример расчета на пять лет может выглядеть так. Облачная CRM для 300 пользователей стоит 900 тысяч рублей в год, внедрение - 2,5 млн, интеграции - 1,8 млн, обучение - 500 тысяч, внутреннее участие - 1,2 млн. При индексации платежей средний TCO составит около 11–12 млн рублей.

Локальная CRM может потребовать 5 млн рублей на лицензии, 4 млн на внедрение и интеграции, 3 млн на серверы и защиту, а также примерно 2,5 млн ежегодно на поддержку и администрирование.

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

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

Решение принимают на основе TCO, требований безопасности, бизнес-процессов и допустимого уровня зависимости от поставщика.

Как собрать модель TCO в таблице

Практический расчет можно выполнить в электронной таблице. На первом листе размещают исходные данные, на втором - расходы по годам, на третьем - сценарии и риски, на четвертом - сравнение поставщиков.

Формулы должны быть простыми и понятными: сложная модель, которую никто не может обновить, быстро теряет пользу.

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

Каждое значение сопровождают примечанием и датой актуальности.

Для каждой статьи рассчитывают количество, цену и периодичность. Например, годовая подписка равна числу пользователей, умноженному на месячный тариф и на 12 месяцев.

Если пользователи подключаются поэтапно, расчет делают по месяцам. Для внедрения используют фиксированную сумму или часы по ролям:

Стоимость работ = часы аналитика × ставка аналитика + часы разработчика × ставка разработчика + часы тестировщика × ставка тестировщика.

Денежные потоки показывают по годам. Пример структуры:

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

Это особенно важно, когда сравниваются крупная закупка сейчас и длительная подписка.

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

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

Перед презентацией модель проверяют на тестовом сценарии и показывают человеку, который не участвовал в ее создании.

Пример полного расчета для корпоративной CRM

Рассмотрим условную компанию с 250 сотрудниками и отделом продаж из 80 пользователей CRM. Компания выбирает облачную систему на пять лет.

В первый год планируется подключить 80 пользователей, во второй - еще 30, а затем численность стабилизируется на уровне 120 пользователей. Тариф составляет 2 500 рублей за пользователя в месяц, ежегодная индексация - 8 процентов.

Начальные расходы включают обследование процессов на 600 тысяч рублей, настройку и внедрение на 1,6 млн, интеграцию с ERP и телефонией на 1,4 млн, миграцию данных на 500 тысяч, обучение на 350 тысяч и резерв проекта в размере 450 тысяч.

Итого первоначальная часть составляет 4,9 млн рублей.

Регулярные расходы первого года рассчитываются так:

• подписка: 80 × 2 500 × 12 = 2,4 млн рублей;

• техническая поддержка и консультации - 600 тысяч рублей;

• дополнительное хранилище и телефония - 300 тысяч рублей;

• администрирование со стороны компании - 900 тысяч рублей;

• поддержка пользователей и обновление инструкций - 250 тысяч рублей.

Второй год будет дороже из-за роста числа пользователей и индексации. При 110 пользователях подписка составит 110 × 2 500 × 1,08 × 12, то есть примерно 3,56 млн рублей.

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

Допустим, суммарные расходы по годам получились такими: первый год - 9,35 млн рублей, второй - 6,2 млн, третий - 6,6 млн, четвертый - 7,1 млн, пятый - 7,7 млн. TCO за пять лет составит 37 млн рублей.

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

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

Лицензии стоят 7 млн рублей, внедрение и интеграции - 5,5 млн, серверная инфраструктура - 4 млн, ежегодная поддержка - 1,8 млн, а внутреннее администрирование - 1,5 млн в год. За пять лет без учета обновления серверов TCO составит:

7 + 5,5 + 4 + 1,8 × 5 + 1,5 × 5 = 33,5 млн рублей.

По прямой сумме локальная система дешевле облачной на 3,5 млн рублей. Но вывод делать рано.

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

Если же у компании уже есть свободная инфраструктура и администраторы, его преимущество усилится.

Этот пример показывает важную вещь: TCO не выдает универсального победителя. Он показывает, какие предположения влияют на результат.

Руководство может изменить число пользователей, срок проекта, темп индексации или стоимость внутреннего персонала и сразу увидеть, как меняется решение.

Как учитывать экономический эффект и не путать его с TCO

TCO отвечает на вопрос "сколько стоит владение", но для инвестиционного решения нужно оценить еще и эффект. Эти показатели не смешивают в одну строку. Сначала считают расходы, затем отдельно оценивают экономию, дополнительные доходы и снижение рисков.

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

Если CRM помогает менеджерам обрабатывать на 10 процентов больше обращений, это не всегда означает прямой рост выручки: результат зависит от спроса, загрузки производства и качества продаж.

Пример расчета экономии на ручном труде:

Экономия = высвобожденные часы × полная стоимость часа − расходы на поддержку новой программы.

Если система экономит 8 000 часов в год, стоимость часа составляет 900 рублей, а ежегодные расходы на сопровождение равны 3 млн рублей, валовая экономия составит 7,2 млн, а чистая - 4,2 млн рублей. Но важно проверить, что высвобожденное время действительно используется: сотрудники могут перейти на более сложные задачи, а не сократить численность.

Для оценки окупаемости используют несколько показателей:

• ROI - отношение чистого эффекта к инвестициям;

• срок окупаемости - время, за которое накопленный эффект покрывает расходы;

• NPV - приведенная стоимость будущих денежных потоков;

• стоимость операции - расходы на выполнение одной транзакции;

• стоимость пользователя - TCO, разделенный на число активных пользователей.

Нельзя считать экономией весь оборот, который прошел через новую программу. Рост продаж может быть связан с рекламой, изменением ассортимента или сезонностью.

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

Показатели эффекта связывают с базовыми значениями до внедрения. Если раньше заказ обрабатывался в среднем за 18 минут, а после запуска - за 11 минут, результат можно отслеживать по месяцам.

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

Частые ошибки при расчете TCO

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

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

Все решения должны быть приведены к одинаковому периоду и сопоставимому уровню требований.

Третья ошибка - не учитывать время сотрудников. Участники проекта получают зарплату независимо от того, заняты они внедрением или текущими задачами, но их рабочее время имеет стоимость.

Если его не показать, компания увидит только внешние счета и будет считать проект дешевле, чем он есть.

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

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

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

Шестая ошибка - скрывать неопределенность за точными цифрами. Прогноз "TCO равен 18 463 200 рублей" выглядит убедительно, но может быть построен на приблизительной оценке трудозатрат. Лучше показывать диапазон и ключевые допущения.

Точность должна соответствовать качеству исходных данных.

Седьмая ошибка - не обновлять модель. После выбора поставщика меняются объем работ, тарифы, сроки и состав команды. TCO пересматривают на этапе договора, перед запуском, после первого года и перед крупным расширением.

Это не разовый файл, а инструмент управления программным продуктом.

Пошаговый алгоритм расчета TCO

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

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

Затем собирают коммерческие и внутренние данные. У поставщиков запрашивают полную стоимость владения, а не только базовый прайс. Внутри компании уточняют зарплаты, доступность ИТ-специалистов, стоимость инфраструктуры, объем исторических данных и время сотрудников.

1. Определите срок владения и дату начала расчета.

2. Опишите пользователей, модули, филиалы и будущий рост.

3. Разделите расходы на единовременные и регулярные.

4. Добавьте внутренние трудозатраты бизнеса и ИТ.

5. Оцените инфраструктуру, безопасность, резервное копирование и поддержку.

6. Рассчитайте миграцию данных, интеграции и возможные доработки.

7. Сформируйте базовый, оптимистичный и консервативный сценарии.

8. Проверьте риски и условия выхода из продукта.

9. Сравните TCO с ожидаемым эффектом и нефинансовыми требованиями.

10. Зафиксируйте допущения и назначьте дату следующего пересмотра.

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

Четыре разных взгляда часто находят расходы, которые не заметил автор модели.

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

Для руководства готовят короткую версию, а подробную таблицу оставляют в приложении.

Хорошая модель должна отвечать на три вопроса: сколько заплатит компания, почему она заплатит именно столько и что произойдет, если изменятся основные условия. Если на эти вопросы можно ответить без ручного пересчета всей таблицы, TCO рассчитан достаточно качественно.

Что проверить в договоре с поставщиком

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

Юридические условия напрямую влияют на стоимость владения.

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

Для облачных решений важны условия размещения, резервирования, возврата и удаления данных.

• Какой объем данных можно хранить без доплаты?

• Есть ли плата за API, внешних пользователей и технические учетные записи?

• Как рассчитывается индексация и когда о ней предупреждают?

• Какие обновления входят в поддержку?

• Кому принадлежат результаты доработок?

• В каком формате выгружаются данные?

• Сколько стоит помощь при миграции на другую систему?

• Какие компенсации предусмотрены при нарушении уровня сервиса?

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

Формулировка "настроить интеграцию с ERP" слишком расплывчата. Нужно указать конкретные объекты, операции, частоту обмена и ожидаемое поведение при ошибках.

Если программный продукт критичен для бизнеса, стоит предусмотреть план непрерывности. Он может включать резервный канал связи, возможность работы при временной недоступности сервиса, регулярные выгрузки и тест восстановления.

Эти меры увеличивают TCO, но снижают вероятность крупных потерь.

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

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

Чем сложнее система и важнее ее роль в компании, тем опаснее ориентироваться только на стартовую цену.

Наиболее надежный подход - задать единый срок владения, собрать прозрачные исходные данные, разделить расходы по категориям и построить несколько сценариев.

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

Такой расчет не гарантирует, что выбранная программа будет идеальной. Но он позволяет понять цену решения заранее, увидеть слабые места договора и не попасть в ситуацию, когда "дешевая" система становится самой дорогой из-за скрытых затрат.

Для сайта тематики "Программы" это особенно важный ориентир: выбирать нужно не самый красивый интерфейс и не самый низкий тариф, а продукт, который дает бизнесу предсказуемую стоимость и понятную ценность на всем сроке использования.