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

Почему одной сметы недостаточно

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

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

Соберите расходы по назначению

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

Не скрывайте труд сотрудников

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

Плановые операции отделите от инцидентов. Разобранный регламент поддержки помогает понять, оплачены ли диагностика и исправление, в какие часы доступна команда и что считается отдельной задачей. Формулировка «поддержка включена» без этих условий не позволяет рассчитать расходы. Не подменяйте неизвестный объём безусловной гарантией бесплатной работы.

Постройте три сценария

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

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

Условный расчёт на тридцать шесть месяцев

Предположим исключительно для обучения: запуск стоит 240 тысяч рублей, регулярные сервисы — 2 тысячи в месяц, сопровождение — 8 тысяч в месяц, развитие — 90 тысяч за весь период. Тогда сумма названных денежных расходов равна 240 + 72 + 288 + 90 = 690 тысяч рублей. Это не тариф Webexlab и не средняя рыночная цена.

В этом примере ещё не оценены труд редактора и перенос. Они должны остаться видимыми незакрытыми строками. Если второй вариант дешевле при запуске на 60 тысяч, но требует дополнительных 3 тысяч ежемесячно, за три года эта разница добавит 108 тысяч. Сравнение меняется ещё до учёта функций и риска — поэтому начальная скидка не определяет итог.

Проверьте чувствительность решения

Измените по одному допущению: число редакторов, частоту публикаций, объём обмена или потребность в переносе. Посмотрите, где появляется новый тариф или ручная операция. Именно такие пороги стоит проверять в договорённостях и документации платформы. Не переносите ограничения одного продукта на весь класс CMS или конструкторов.

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

Как поддерживать расчёт актуальным

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

Как не посчитать одни расходы дважды

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

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