Стратегия

2.2.1Плавное нарастание по месяцам

Все дельты сценария — рост клиентов, изменение среднего чека, цена лида по каналам, снижение оттока — применяются не сразу на все 100% с первого месяца года. В основе лежит формула плавного нарастания: коэффициент готовности рассчитывается как номер месяца, делённый на 11, где номер месяца идёт от 0 (январь) до 11 (декабрь). Январь всегда равен типовому месяцу — базовой финансовой модели без каких-либо изменений, а декабрь выходит на полную заданную цель сценария. Такой подход к финансовому планированию намного реалистичнее, чем наивное «умножить типовой месяц на 12 с учётом роста»: в реальности любое управленческое решение — запуск нового канала маркетинга, программа удержания клиентов, снижение оттока — требует времени на раскрутку и не даёт полного эффекта с первого же месяца.

Важный нюанс, который стоит понимать при чтении годового прогноза: это не «догоняющая» модель. Если старт года вышел медленнее, чем планировалось — например, программа снижения оттока заработала не в январе, а только к весне — итоговый годовой прирост окажется МЕНЬШЕ исходной цели сценария. Декабрь просто выходит на 100% заданного темпа, но не компенсирует упущенные месяцы задним числом. Для собственника это значит, что откладывание запуска инициативы «на потом» имеет реальную цену в виде недополученной годовой выручки — и эта цена видна в цифрах уже на этапе планирования, а не только по факту в конце года.

Одна и та же цель «−0,4 п.п.» даёт разный эффект в январе и в декабре — темп нарастает линейно.

2.2.2OKR как «ключ» к дельте, а не только бюджет

Менее очевидный, но важный для управленца момент: стратегический OKR в этой системе управления компанией — это не только про бюджет инициативы, но и про то, действует ли вообще соответствующий рычаг сценария. Если для конкретного рычага — например, «снижение оттока клиентов» — существует OKR и он ещё не утверждён, дельта в расчёте откатывается на дефолтное значение (отток считается по базовым рыночным цифрам, без снижения), даже если слайдер на экране физически выставлен на другое значение. Это защищает от ситуации, когда красивая цифра на слайдере создаёт иллюзию запланированного эффекта, которого на самом деле ещё нет в утверждённой стратегии компании.

Если же OKR для этого рычага никогда не создавался в разделе стратегического управления — слайдер действует свободно, без необходимости какого-либо утверждения: не любое предположение в финансовой модели обязано быть оформлено как формальная стратегическая инициатива. То есть создание OKR не обязательно для работы со сценарием, но если он всё же создан — именно он управляет тем, что реально учитывается в прогнозе, а не просто дополняет расчёт комментарием для отчётности. Такая связка управленческого учёта и стратегического планирования не даёт разъехаться словам («мы решили снизить отток») и цифрам («в прогнозе заложено снижение оттока») — либо решение формально утверждено и работает, либо оно не влияет на финансовый результат.

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

2.2.3Бюджет OKR учитывается только в свои месяцы

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

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

Бюджет OKR виден в прогнозе только внутри своего окна — за его пределами добавка исчезает, а не «размазывается» дальше.

2.2.4Прогноз на 5 лет — не продолжение той же кривой нарастания

Под годовым расчётом сценарий сразу показывает таблицу на 5 лет вперёд — но года 2–5 считаются принципиально ИНАЧЕ, чем год 1, и это стоит понимать, прежде чем читать цифры как «рост продолжится в том же темпе». Год 0 — справочная строка «типовой месяц × 12» без каких-либо эффектов сценария. Год 1 — это в точности тот же расчёт с плавным нарастанием (ramp = i/11), который описан в 2.2.1, просто просуммированный по месяцам. А вот годы 2–5 — упрощённая модель равновесия: приток новых клиентов (маркетинг + органика) замораживается на уровне последнего месяца года 1 и дальше НЕ растёт по годам («бюджет не растёт»), при этом отток по-прежнему съедает пропорциональную долю базы каждый месяц. Итог — база клиентов и выручка не продолжают линейный или ramp-рост, а асимптотически выходят на плато: чем больше база, тем больше абсолютных клиентов теряется на тот же % оттока, пока приток и отток не уравновесятся. OKR-бюджеты в годы 2–5 учитываются пропорционально пересечению их окна дат с границами конкретного года — та же логика окна, что в 2.2.3, но применённая уже не к месяцам, а к годам.

Темп прироста плавно гаснет к 5 году сам по себе — если реальный план подразумевает продолжающийся рост бюджета на маркетинг, эта таблица его не покажет, она моделирует сценарий «без изменений после года 1».

2.3.1Утверждение бюджета создаёт новую версию, не перезаписывает старую

Кнопка «Утвердить как бюджет» не редактирует существующий бюджет поверх старых цифр — она сохраняет текущий расчёт как новый именованный снапшот версии (в системе хранится до 10 последних версий одновременно) и только затем помечает именно его как активный бюджет компании. Это принципиальное архитектурное решение для бюджетирования: изменение стратегии в середине года — например, из-за выхода на новый рынок или пересмотра плана продаж — не стирает историю прежних решений безвозвратно.

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

Утверждение создаёт v3, а v1 и v2 остаются доступны для сравнения — всего хранится до 10 версий.

2.3.2Перенос фактов ФП и ТБУ между версиями бюджета

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

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

Копируются только уже заполненные поля прошлой версии — пустые остаются пустыми, а не затираются нулями.