Экономика миграции: цифры, которые принимает CFO

Если вы CTO и готовите переход на headless-архитектуру — вот что на самом деле увидит ваш CFO, когда откроет презентацию. И почему в 9 из 10 случаев он её закрывает через 3 слайда.

Мы в WebGoodPeople видим это каждую неделю. CTO приходит с детальным техническим обоснованием: микросервисы, API-first, независимые деплои, developer experience. Всё правильно. Всё неработающе.

CFO не покупает архитектуру. CFO покупает устранение конкретного финансового риска. Эта статья — каркас, который переводит первое во второе.

Три слоя математики, которые работают

Каждое обоснование headless-миграции для CFO должно строиться на трёх слоях, именно в таком порядке:

Слой 1: цена НЕ-миграции. Сколько бизнес теряет сейчас из-за текущей архитектуры.

Слой 2: прямые затраты на миграцию. Человеко-часы, инструменты, риск простоя.

Слой 3: risk-adjusted сравнение. Ожидаемая доходность с учётом вероятности провала.

Если вы начинаете с Слоя 2 — CFO видит только цифру расхода. Это почти всегда красный сигнал. Начинайте с Слоя 1.

Слой 1: цена НЕ-миграции (shadow revenue)

Возьмём реалистичную модель e-commerce:

• 500 000 сессий в месяц
• 1.2% конверсия
• Средний чек 4500 ₽

Месячная выручка: 500 000 × 1.2% × 4500 = 27 000 000 ₽/месяц.

Потеря от TTFB

Правило Amazon («каждые 100 мс латентности = 1% продаж») было перемеряно десятки раз. Точные цифры варьируются по рынкам, но направление устойчивое: 500 мс задержки = 3–6% потерянной конверсии.

Если ваш TTFB на каталоге 900 мс (типичный для Битрикс-монолита среднего возраста), то по сравнению с 400 мс (достижимо на headless с ISR/edge) — вы теряете около 4% конверсии.

Потеря: 27 000 000 × 4% = 1 080 000 ₽/месяц.

Это деньги, которые ваша команда не видит в отчётах. Они никогда не существовали как строка в P&L. Вы их не «экономите» через миграцию — вы их разблокируете.

Потеря от bus factor

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

Консервативно: одна задержка критичного релиза на 2 недели из-за отсутствия разработчика = упущенная маркетинговая кампания или запуск акции. Оценка: 2–5% месячной выручки на один такой случай. В год случается 3–6 раз.

Итог: 540 000–1 350 000 ₽/год в среднем по рынку.

Потеря от скорости изменений

Каждый запуск лендинга, акции или кампании в монолитной админке занимает 2–4 недели против 1–2 дней на headless. За год это 10–30 «неуспетых» активностей. Если каждая даёт 2% роста выручки в свой месяц — вы недополучаете 2–6 месяцев роста в год.

Суммарно: Слой 1 обычно даёт 18–30 млн ₽/год для типичного среднего e-commerce.

Слой 2: прямые затраты на миграцию

Здесь важно различать two kind of миграций:

Big-bang reрайт (который CFO боится): переписать всё за 12 месяцев. 4–8 разработчиков × 12 месяцев × 400 000 ₽/мес = 19–38 млн ₽. Плюс риск срыва сроков 40–60%.

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

Пилот 2 недели = 800 000–1 500 000 ₽. Если метрики не двинулись — закрыто, потерян бюджет пилота. Если двинулись — продолжаем эволюционно, фиксируя выгоду каждого этапа.

Цифра для CFO: «Риск = стоимость пилота. До пилота — нулевой.»

Слой 3: risk-adjusted сравнение

Теперь сравнение в чистой форме, которую CFO принимает:

Опция Ожидаемая выгода (12 мес) Прямые затраты Риск провала Risk-adjusted Статус-кво 0 ₽ 0 ₽ — 0 ₽ (но shadow loss = −18 млн) Big-bang переписать +25 млн (после миграции) −25 млн 50% срыв +0 ± 15 млн Staged headless +12 млн в первый год −4 млн (поэтапно) 15% на каждый этап +8 млн

Последняя строка — это то, что CFO смотрит. Не «миграция за 25 млн», а «+8 млн в год с управляемым риском».

Шаблон, который можно показать CFO

Шаг 1. Назвать три конкретных риска (не «архитектурный долг», а: «теряем 1.08 млн/мес на TTFB», «один человек знает Bitrix-компонент», «акции запускаем 2 недели вместо 2 дней»).

Шаг 2. Посчитать их в рублях. Не «много», а конкретная сумма. Таблица на 5 строк.

Шаг 3. Предложить пилот 2 недели за фиксированную цену, с чётко определённым scope и метриками «до/после». Показать это как «минимальный тест гипотезы» — формулировка, которую CFO понимает из финансового словаря.

Шаг 4. В конце презентации — ОДНА цифра: «Риск = X ₽ (бюджет пилота). Ожидаемая выгода = Y ₽/год. Решение: одобрить или отклонить пилот».

Не «одобрить или отклонить миграцию». Только пилот.

Типичные ошибки в таких презентациях

Начинать с архитектуры. CFO закрывает на слайде «микросервисы vs монолит». Архитектуру обсуждают CTO и архитекторы. CFO обсуждает рубли и риски.

Большая сумма впереди. «Миграция займёт 12 месяцев и стоит 25 млн». CFO видит это и думает «пусть подождёт до следующего года». Всегда разбивайте на этапы, первый из которых — пилот за маленькую сумму.

Нет метрик успеха. «Будет быстрее и удобнее» — это не метрика. Метрика — это «TTFB с 900 мс до 400 мс за 4 недели, измерение Lighthouse в конце второй недели».

Нет сценария неудачи. Если CFO не видит, что он теряет при неудачном пилоте — он не может оценить риск. «Риск = 1.2 млн (бюджет пилота). Если метрики не двинулись — закрыли, потерян бюджет пилота» — это понятная сумма в понятном контексте.

Что это значит на практике

Если у вас готовится обсуждение с CFO и уже есть презентация — переделайте обложку. С «Почему нам нужен headless» на «Три финансовых риска и их цена в ₽».

Если CFO ещё не в обсуждении — подготовьте таблицу из Слоя 1 до разговора. Покажите shadow revenue первыми, до любых технических слайдов.

Если вы готовы к следующему шагу — запросите 48-часовой CWV аудит. Он даст вам конкретные цифры из Слоя 1 для ВАШЕГО стека, а не из типовой модели.

---

WebGoodPeople делает 48-часовой аудит CWV бесплатно. Возвращаем расчёт shadow revenue по вашим данным и конкретный план на пилот 2 недели: webgoodpeople.com/api-audit