директор и машина · стратегия · запись № 059 · 24 августа 2026 · Давид Герштейн

Автоматизация финансовой модели: во что обходится и когда возвращает деньги

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

Марк написал в пятницу вечером, коротко: «Слушай, сколько вообще стоит сделать так, чтобы финмодель сама пересчитывалась? Не хочу больше ждать три дня, пока сведут таблицы». Вопрос по делу — его задаёт себе любой руководитель, глядя на очередной Excel с формулами, которые давно никто не проверял. Отвечаю развёрнуто, сколько стоит автоматизация финансовой модели и когда она окупается, — как коллеге, а не слайдом на презентации.

Сколько стоит — если коротко

Автоматизация финансовой модели для компании уровня нашей легенды — 8 менеджеров, оборот около 9 млн ₽ в месяц, штат 40 человек — стоит разово 120–160 тыс ₽ на настройку и 5–7 тыс ₽ в месяц на работу самой модели (оценка, это часы аналитика и разработчика плюс стоимость обработки данных ИИ). Окупаемость зависит от того, что считать эффектом: если только сэкономленное время финансиста — около 7–8 месяцев; если хотя бы один предотвращённый кассовый разрыв из-за неверного прогноза — в первый же квартал. Складывать эти два эффекта нельзя: один считается временем, другой — вероятностью инцидента, и ниже они разложены отдельно.

Дальше Марк спросил то, что спрашивает всегда: «за счёт чего конкретно, не просто скажи, что дорого или дёшево». Разбираю по частям: почему ручная модель обходится дороже, чем кажется на бумаге, как устроена автоматизация по шагам, что в ней делает ИИ, а что — обычная формула, и во сколько это выливается в деньгах.

Почему ручная финмодель обходится дороже, чем кажется

Ручной пересчёт финмодели съедает не столько зарплату аналитика, сколько скорость решений: пока три дня сводятся таблицы, собственник уже принял решение по интуиции, а не по цифрам. Отдельная и более дорогая проблема — путаница между суммой договора и суммой авансового платежа: если модель считает выручку по факту подписания, а кассу нужно планировать по поступлениям (обычно это 37–40% от суммы договора на старте), прогноз кассы уезжает на десятки процентов от реальности. В одной из стратегий на нашем материале так и было: план кассы держался на цифре в 53 млн ₽, а по факту заложено было 22 млн — и никто на встрече не мог сразу ответить, это сумма договоров или сумма реально поступивших авансов. Разница в трактовке — это разница в 2,4 раза в том, сколько денег компания якобы должна увидеть на счету. Похожая история — с дебиторкой: искажение видимости денег на счету часто растёт из того же корня, что и рост просроченной задолженности, — см. разбор дебиторка под контролем, который не зависит от памяти людей.

Дальше все числа в этом разделе — оценка, основанная на пропорциях легенды; отдельно по каждой цифре это уже не помечаю. Переведу в цифры нашей легенды. При обороте 9 млн ₽/мес и среднем чеке 180 тыс ₽ компания закрывает около 50 сделок в месяц — по 6–7 на менеджера. Если модель путает 10% этих сделок (записывает аванс как уже поступившую выручку или наоборот), это 5 сделок × 180 тыс ₽ = 900 тыс ₽ искажения видимости кассы в месяц. Это не потеря денег — это потеря зрения: собственник либо решит, что денег больше, чем есть, и одобрит закупку или найм, либо решит, что денег меньше, и придержит инвестицию, которая была бы оправдана. Порядок цены одной такой ошибки — от нескольких сотен тысяч до нескольких миллионов рублей неверного решения, что уже само по себе выше стоимости всей автоматизации.

Плюс время. Ручной пересчёт финмодели и сверка отклонений от плана съедают у аналитика или финансиста около 20 часов в месяц — не потому что расчёт сложный, а потому что данные разбросаны по CRM, банку и голове менеджера. Каждое внеплановое изменение — акция, потерянный клиент, задержка оплаты — это ещё один ручной прогон таблицы.

На диаграмме — время ручного пересчёта и сверки финмодели в месяц: 20 часов вручную против 6 часов при автоматизации (проверка и сверка).

Считаем экономию времени: формула и пример на числах

Формула словами, чтобы прикинуть свой случай: часы ручного пересчёта в месяц × доля, которую снимает автоматизация, × ставка специалиста в час = сумма экономии в месяц; из неё вычитаем стоимость эксплуатации модели — получаем чистую экономию; разовые затраты на внедрение делим на чистую экономию — получаем срок окупаемости в месяцах.

Подставляю числа нашей легенды консервативно. Ручной пересчёт — 20 часов в месяц. Автоматизация не убирает работу финансиста целиком: он всё ещё проверяет план на сверке по четвергам — берём консервативную долю снятой нагрузки в 70%. Это 14 часов в месяц. При типовой ставке финансиста около 1 700 ₽/час для позиции такого уровня экономия — 14 × 1 700 = 23 800 ₽/мес. Минус эксплуатация модели 6 000 ₽/мес — чистая экономия около 17 800 ₽/мес. Разовые затраты 140 000 ₽ (середина вилки 120–160 тыс) делим на чистую экономию: 140 000 / 17 800 ≈ 7,9 месяца. Отсюда и цифра в 7–8 месяцев в оценке окупаемости по времени — она не взята с потолка, а собрана из трёх допущений, каждое из которых можно поправить под свою компанию.

Второй эффект — предотвращённые ошибки прогноза — считается иначе и складывать его с первым нельзя: он не про часы, а про вероятность и цену одного инцидента. Если за квартал модель хотя бы раз поймает искажение кассы порядка 900 тыс ₽ (как в примере выше) до того, как оно превратится в решение о найме или закупке, — это перекрывает всю стоимость внедрения за один раз, независимо от того, сколько месяцев прошло. Считать эти два эффекта в одной сумме — типовая ошибка презентаций: время экономится постепенно, ошибка предотвращается разово, и годовой эффект — это не сумма, а два разных сценария, которые стоит показывать раздельно.

Как это делается по шагам

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

По шагам это выглядит так:

1. Собрать обучающую выборку. Берём 40–50 закрытых сделок за последний месяц (для нашей легенды это как раз месячный поток отдела продаж) и сводим их вручную с финансистом: где договор, где аванс, где сделка сорвалась после частичной оплаты. Это не автоматизация — это разметка, на которой модель потом будет учиться отличать одно от другого.
2. Заменить фиксированные цифры формулой. Вместо «план на месяц — Х рублей» пишем «план = база текущего месяца × (1 + темп роста в %)», где темп роста подтягивается из факта предыдущих периодов. Это снимает главную причину, по которой стратегии и финмодели устаревают за несколько месяцев: план перестаёт быть застывшим числом и пересчитывается сам при каждой новой загрузке факта. Этот же приём я подробно разбирал на уровне стратегии в целом — см. «Стратегия как рабочий инструмент, а не презентация для полки», здесь не повторяю механику, беру только принцип.
3. Подключить выгрузку данных. CRM (в нашем случае Bitrix24) отдаёт данные по сделке через вебхук при смене стадии — сумма, дата, статус оплаты. Данные летят в Google Sheets, где живёт сама модель. Если сомневаетесь, что даты и суммы из CRM вообще можно доверять напрямую — стоит сначала прочитать, как Битрикс24 сдвигает даты сделок, и заложить эту проверку в конвейер заранее.
4. Протестировать на контролируемом сегменте. Не запускаем на весь отдел сразу — берём 20% сделок или одного менеджера, гоняем модель две недели, сверяем с ручным расчётом финансиста построчно.
5. Масштабировать и закрепить ритм проверки. После сходимости — подключаем весь отдел и вводим фиксированный день сверки, например четверг: маркетинг, продажи и авансы сводятся в одну таблицу к концу недели.
6. Кто смотрит. Финансист проверяет модель на сверке раз в неделю, собственник смотрит итог раз в месяц — и не читает отчёт длиннее одной страницы.

ИИ-связка: промпты, обвязка, платформа

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

Схема конвейера: Bitrix24 (сделка меняет стадию) → вебхук → Google Apps Script дописывает строку в лист «Сделки» → дешёвая модель размечает договор/аванс/статус и подставляет цифры в формулу плана → раз в неделю дорогая модель прогоняет весь план целиком и ищет нестыковки → результат — в отдельный лист «Аудит» и уведомление в Telegram, если модель нашла подозрительное допущение.

Промпт 1 (дешёвая модель — например, лёгкая версия GPT для формальных задач). Задача разовая и структурная: разметить строку сделки, не нужно рассуждение — нужна скорость и низкая цена за вызов.

Ты обрабатываешь одну строку сделки из CRM для финансовой модели.
Входные данные (JSON):
{
  "deal_id": "8841",
  "amount_contract": 180000,
  "amount_paid": 72000,
  "stage": "Оплата частичная",
  "date_stage_change": "2026-08-14"
}

Определи:
1. category: "аванс" (paid < contract), "полная оплата" (paid == contract), "без оплаты" (paid == 0)
2. cash_now: сумма, которую нужно учесть в кассовом плане ЭТОГО месяца (это amount_paid, не amount_contract)
3. flag_review: true, если amount_paid > amount_contract или amount_paid < 0 (аномалия)

Ответ строго в JSON, без пояснений текстом.

Пример ответа модели:

{
  "deal_id": "8841",
  "category": "аванс",
  "cash_now": 72000,
  "flag_review": false
}

Здесь же видно масштаб проблемы: 72 000 ₽ из 180 000 ₽ — это 40% от суммы договора, ровно та доля аванса на старте, которая в ручной модели чаще всего путается с полной выручкой. Если бы модель на этой строке ошиблась и записала в кассу 180 000 ₽ вместо 72 000 ₽, искажение по одной сделке составило бы 108 000 ₽ — больше половины месячной стоимости эксплуатации всей системы.

Промпт 2 (дорогая модель — уровня GPT-4o/Claude Sonnet). Задача еженедельная и требует рассуждения: найти в готовом плане допущения, которые формально верны, но по факту не учтены или не обоснованы — это ровно то место, где ИИ обычно ошибается уверенно и гладко, если его не проверять.

Ты финансовый аналитик. Проверяешь план на месяц перед тем, как он пойдёт собственнику.

Входные данные (JSON):
{
  "plan_revenue": 9500000,
  "fact_prev_month": 9000000,
  "growth_rate_applied": "5%",
  "bonus_scheme_included": false,
  "new_hires_planned": 2,
  "market_events": ["сезонное падение спроса в этом месяце"]
}

Найди минимум 3 потенциальные проблемы в этом плане: что не учтено,
что противоречит другим данным, что требует ручной проверки перед тем,
как показывать план собственнику.

Формат ответа — JSON-список объектов {issue, why, severity: "low/mid/high"}.

Пример ответа модели:

[
  {"issue": "Бонусы продаж не включены в план",
   "why": "amount_contract учтён, но расход на бонусы менеджеров не вычтен из маржи",
   "severity": "high"},
  {"issue": "Темп роста 5% не учитывает сезонное падение спроса",
   "why": "market_events указывает на спад, а формула роста этого не корректирует",
   "severity": "mid"},
  {"issue": "Найм 2 новых сотрудников не отражён в расходной части плана",
   "why": "new_hires_planned есть, но фонд оплаты труда не пересчитан с учётом двух новых ставок",
   "severity": "mid"}
]

Дальше решает severity. Проблему с меткой «high» финансист получает в Telegram сразу, не дожидаясь четверговой сверки — бонусы, не вычтенные из маржи, искажают план сильнее, чем любая формальная неточность в разметке сделки. Это тот же класс ошибки, который на практике уже случался: план выглядел убедительно, но не учитывал бонусы продаж, а прогноз объёма на следующий год был не обоснован ничем, кроме гладкого текста модели — именно такие вещи и должен ловить еженедельный аудит, а не ежемесячная презентация собственнику. Собственник видит план только после того, как метка снята или проблема объяснена руками, а не спрятана в примечании на второй странице. Это тот же принцип, что и в других задачах, где автоматизация работает только под присмотром человека, а не сама по себе — см. «Если бы я не пришёл, ничего бы не произошло»: автоматизация, требующая надзора.

Как прикинуть на своих цифрах

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

Первое — спросите у того, кто делает пересчёт вручную, сколько часов в месяц он на это тратит, а не оценивайте сами. Второе — если данные уже в одной CRM, можно закладывать долю снятой нагрузки в 70–80%; если данные разбросаны по трём системам и экселю — консервативнее, 40–50%. Третье — ставка часа именно в пересчёте на час, а не оклад делённый на 160.

Дальше формула та же: часы × доля автоматизации × ставка = экономия в месяц; минус стоимость эксплуатации (у вас она может отличаться от 5–7 тыс ₽, если сделок в разы больше); разовые затраты делим на чистую экономию — получаем свой срок окупаемости по времени (оценка, поскольку зависит от трёх ваших собственных допущений). Отдельно, не складывая с этим числом, прикиньте вторую цифру: сколько стоила бы вам одна ошибка прогноза кассы такого масштаба, как в примере с путаницей договор/аванс. Если эта цифра выше стоимости внедрения — у вас есть второй, более быстрый аргумент для решения, независимо от того, что покажет расчёт по времени.

Частые вопросы

Сколько стоит автоматизация финансовой модели?

Разово 120–160 тыс ₽ на настройку интеграции и формул — оценка, это 60–80 часов работы аналитика и разработчика по ставке около 2 000 ₽/час, плюс 5–7 тыс ₽ в месяц на обработку данных ИИ. Итоговая сумма зависит от числа источников данных и от того, насколько запутан текущий учёт.

От чего зависит окупаемость финансовой модели?

От двух разных эффектов: экономии времени финансиста на пересчёте (окупаемость 7–8 месяцев — оценка) и предотвращённых ошибок прогноза из-за путаницы договор/аванс или незамеченных бонусов (окупаемость может наступить в первый же квартал одним инцидентом). Эти эффекты нельзя складывать напрямую — считайте их отдельно.

Можно ли обойтись без ИИ, просто формулами в Excel?

Частично да — формулы вместо фиксированных цифр снимают проблему устаревания плана. Но ИИ-слой нужен там, где надо разметить массив сделок (договор/аванс/бонус) или раз в неделю проверить план на нестыковки, которые формула сама не находит.

#деньги #аналитика и отчётность #ии и нейросети