Бюджетирование — это набор правил, по которым компания превращает цели в лимиты, планы и прогнозы, а потом проверяет план/факт и корректирует курс.
В этой статье разберем четыре рабочих метода: приростное, с нуля (ZBB), скользящее, по видам деятельности (ABB).
Покажу, когда метод «ломает» управляемость, как выбрать метод под задачу и как не перепутать бюджет с «таблицей для согласования».
Будут примеры типичных ситуаций: «всем добавить 7%», «защита бюджета как переговоры», «прогноз стыдно обновлять», «накладные живут своей жизнью».
Вызов: Управленческий вопрос на повестке
Проблема. Один и тот же бюджет может быть и инструментом управления, и источником конфликтов — в зависимости от выбранного метода.
Управленческий вопрос. Какой метод бюджетирования даст вам предсказуемость решений, а не «красивую подачу цифр»?
Проверка. Если бюджет чаще используется для «защиты» и «выбивания» лимитов, чем для управления, — метод выбран не под цель.
Система координат: Глоссарий и основа методологии
Определение
Метод бюджетирования — это способ, как вы формируете план: от прошлого, с нуля, постоянно обновляя прогноз, или через драйверы деятельности.
Простыми словами
Метод — это ваш ответ на вопрос: «Откуда берём цифру?»
Из прошлого года? Из потребности? Из прогноза спроса? Из объема операций и драйверов?
Пример
Один и тот же «ФОТ отдела» может считаться как прошлый год + 8%, как ноль с обоснованием каждой роли, как прогноз по загрузке на 3–6 месяцев, или как стоимость функций (подбор, обучение, сопровождение) через драйверы.
Опора управленческого цикла
Чтобы метод работал, нужны договоренности:
● календарь планирования и пересмотра
● границы ответственности (кто владелец статьи/лимита)
● правила корректировок (когда можно менять план)
● единые аналитики (ЦФО, статьи, проекты, договоры, направления)
Система координат: Границы модели
Что включаем в «модель бюджета»
Модель бюджета — это не «все строки, которые вспомнили». Это минимально достаточная конструкция, которая отвечает на управленческие вопросы.
Обычно в границы попадают:
● операционные бюджеты (выручка, закупки, ФОТ, коммерческие, общепроизводственные)
● БДДС (платежный календарь, лимиты, прогноз кассы), БДР, ББЛ
● CAPEX (инвестпроекты, графики оплат, лимиты)
● принципы план-факт (что считается фактом, когда фиксируется период)
Что не надо тащить сразу
Если вы включаете в бюджет «все возможные разрезы», вы получаете:
● рост трудоемкости в разы
● падение доверия к данным
● «закрытие бюджета» вместо управления
Проверка границы. Если строка бюджета не влияет ни на одно решение (лимит, цена, объем, приоритет), — она пока лишняя.
Цель расчётов: Ответы на ключевые управленческие вопросы
Метод бюджетирования выбирают не «по традиции», а по тому, какие ответы вам нужны.
Какие вопросы бюджет обязан закрыть
● Где у нас ограничение? Деньги, мощность, люди, поставки?
● Что можно заморозить без ущерба? А что трогать нельзя?
● Какая цена ошибки прогноза? В кассе, марже, запасах, сроках?
● Кто и за что отвечает? Где зона контроля ЦФО, где общая «погода»?
● Когда пересматриваем курс? Раз в год, раз в квартал, каждый месяц?
Критерий «живости» бюджета
Бюджет живой, если по нему регулярно принимают решения:
● приоритизация платежей
● корректировка плана продаж и закупок
● заморозка/разморозка найма
● пересмотр скидок/условий
● перенос CAPEX по окупаемости и кассе
Методология: Различные подходы к решению одной задачи
Задача одна: управлять ресурсами. Подходы — разные. И каждый ломается по-своему.
Приростное бюджетирование (Incremental)
Определение. План строится от базы прошлого периода: «было X, станет X ± %».
Смысл для управления. Хорошо работает, когда структура расходов стабильна, а цель — быстро зафиксировать базовый коридор.
Где подходит.
● зрелые процессы, мало изменений
● сильная нормативка по затратам
● небольшая доля «проектных» расходов
Главный риск. Метод консервирует «исторические ошибки»: лишние функции, дубли, неэффективные договоры.
Пример. Отделу оставили прошлогодние услуги «на всякий случай», добавили 10% — и это стало «новой нормой», хотя объем работ не вырос.
Бюджетирование с нуля (Zero-Based Budgeting, ZBB)
Определение. План собирается не от прошлого, а от необходимости: каждая статья должна быть обоснована как новая.
Смысл для управления. Метод хорош для перезапуска дисциплины затрат: убрать «автопилот», вернуть контроль.
Где подходит.
● резкое изменение рынка/объема
● рост накладных без понятной причины
● запуск централизованных закупок и лимитов
● регулярные «внебюджетные» заявки
Главный риск. ZBB превращается в бюрократию, если делать «с нуля вообще всё».
Пример. ZBB на командировки и представительские дает эффект быстро. ZBB на каждую мелкую канцелярию — вы получите идеальный план и потеряете месяц жизни команды.
Скользящее бюджетирование и прогноз (Rolling budget / Rolling forecast)
Определение. План пересматривается регулярно: добавляется новый период, а ближайшие месяцы уточняются по факту и прогнозу.
Смысл для управления. Это метод про управление будущим, а не про «сдать годовой бюджет и выдохнуть».
Где подходит.
● волатильная выручка и закупки
● длинные циклы поставок и производства
● касса критична (лимиты, ковенанты, кредиты)
● сильная сезонность
Главный риск. Скользящий прогноз «умирает», если нет правил: кто обновляет, на каких драйверах, когда фиксируем версию.
Пример. Прогноз продаж обновили, а закупки и производство оставили «как было». Через месяц виноват становится не прогноз, а люди, которые ему поверили.
Бюджетирование по видам деятельности (Activity-Based Budgeting, ABB)
Определение. План затрат строится от объема операций (деятельностей) и их драйверов, а не от «статей прошлого года».
Смысл для управления. ABB связывает накладные с реальной нагрузкой: вы управляете не суммой «общих расходов», а причинами, почему они возникают.
Где подходит.
● много косвенных расходов
● ассортимент/клиенты сильно различаются по «стоимости обслуживания»
● сервис, логистика, склад, качество, ИТ — заметная доля затрат
● есть данные об объемах операций (заказы, отгрузки, обращения, поставки)
Главный риск. Неправильно выбрать драйвер и получить «математику без причинности».
Пример. Складовые расходы распределили по выручке. Выручка выросла — «по модели» склад стал дороже. Но операций не добавилось. Значит, драйвер не отражает объем работы.
Как выбрать метод, если у вас не научный проект, а бюджет
Практическая логика выбора выглядит так:
● Нужно быстро зафиксировать базу и стабильность → приростное
● Нужно «вынуть» лишнее и вернуть контроль → ZBB точечно
● Нужно управлять будущим при изменчивости → скользящее
● Нужно приручить накладные и сервисную нагрузку → ABB для выбранных блоков
Комбинация — нормальна. В реальности часто работает «гибрид»: приростное для стабильных статей, ZBB для спорных, скользящий прогноз для выручки/кассы, ABB для накладных функций.
Наглядно: О чём это, если говорить просто?
Перевод на «язык управленческих ситуаций»
Приростное — «мы продолжаем жить примерно так же, просто аккуратнее и с поправкой на изменения».
ZBB — «давайте докажем, что это вообще нужно, и сколько нужно на самом деле».
Скользящее — «годовой план — это ориентир, но рулить будем по обновляемому прогнозу».
ABB — «расходы — это не сумма, а следствие операций; хотим управлять расходами — управляем операциями».
Мини-пример на одной теме: расходы на склад
Приростное: прошлый год 12 млн, план 13 млн.
ZBB: какие функции склада обязательны, какие — «исторически сложились», что можно отдать на сторону, что автоматизировать.
Скользящее: каждый месяц обновляем прогноз затрат склада по плану отгрузок/поставок.
ABB: затраты = приемка × ставка + комплектация × ставка + возвраты × ставка.
Типовые ошибки: На что обращать внимание
Ошибка 1. Выбрать метод «по привычке», а цель — другая
Риск. Вы ждете контроля и управляемости, а метод дает только «формальную цифру».
Проверка за 2 минуты. Можете назвать 3 решения, которые вы примете по бюджету в следующем месяце?
Ошибка 2. Сделать ZBB «на всё»
Риск. Команда утонет в обоснованиях, а качество решений не вырастет.
Проверка за 2 минуты. У вас есть список «дорогих и спорных» статей, где ZBB даст эффект быстрее всего?
Ошибка 3. Скользящий прогноз без владельца и календаря
Риск. Прогноз превращается в документ «на случай совета директоров», а не в инструмент управления.
Проверка за 2 минуты. Кто обновляет прогноз, когда, и что считается «версией, по которой работаем»?
Ошибка 4. ABB без данных об операциях
Риск. Драйверы становятся «красивыми предположениями», и доверие к модели исчезает.
Проверка за 2 минуты. Драйвер измеряется в системе и влияет на загрузку? Если драйвер упадет на 20%, расход реально снизится?
Ошибка 5. Путать бюджет и лимиты
Риск. Бюджет превращается в «разрешение тратить», а не в план достижения целей.
Проверка за 2 минуты. У вас отдельно описано: что планируем (P&L/ДДС), а что ограничиваем (лимиты/заявки/платежи)?
Что делать с понедельника: План на 60–90 минут
Шаг 1. Зафиксировать цель бюджета (10 минут)
● Решения, которые должны появиться: лимиты, приоритеты, корректировки, стоп-листы
● Горизонт управления: год, квартал, 13 недель, 6 месяцев
Шаг 2. Разложить статьи на 4 корзины (15 минут)
● Стабильные → приростное
● «Исторически раздутые» → ZBB точечно
● Критичные к будущему → скользящее
● Накладные с операционной природой → ABB
Шаг 3. Выбрать 1 пилотный блок (10 минут)
Правило пилота. Там, где больно, видно и можно измерить.
Пример. Командировки, подрядчики, склад/логистика, ИТ-сопровождение, ремонты, маркетинг.
Шаг 4. Назначить владельцев и календарь (15 минут)
● владелец статьи/лимита
● дата обновления прогноза
● правило «что можно менять, а что фиксируем»
Шаг 5. Определить 3 драйвера (10–20 минут)
Для скользящего/ABB нужны драйверы:
● объем продаж/заказов/отгрузок
● курс/цены/тарифы (если применимо)
● операции: приемка, комплектация, обращения, поставки, смены и т.д.
Как объяснить руководителю и коллегам: Скрипты
Скрипт 1. Почему мы меняем метод
Формулировка. «Мы не усложняем бюджет. Мы выбираем метод, который отвечает на управленческие вопросы: где ограничение, что приоритетно, когда пересматриваем курс».
Скрипт 2. Почему ZBB будет не на всё
Формулировка. «С нуля считаем только спорные и дорогие блоки. На стабильных статьях оставляем базовый подход, чтобы не тратить ресурсы на контроль копеек».
Скрипт 3. Зачем нам скользящий прогноз
Формулировка. «Годовой бюджет фиксирует цель. Скользящий прогноз помогает не промахнуться в кассе и ресурсах, когда реальность меняется быстрее календаря».
Скрипт 4. Что такое ABB без академизма
Формулировка. «Мы планируем накладные не как сумму “в целом”, а как стоимость операций. Это позволяет управлять причинами расходов, а не спорить о процентах распределения».
Мини-глоссарий
● Приростное бюджетирование — план от базы прошлого периода с корректировками на изменения.
● ZBB (бюджетирование с нуля) — планирование «с чистого листа» с обоснованием каждой статьи.
● Скользящий бюджет/прогноз — регулярное обновление плана с добавлением нового периода.
● ABB (бюджетирование по видам деятельности) — план затрат через объем операций и драйверы.
● Драйвер — измеримый фактор, который объясняет объем работы и затрат (заказы, отгрузки, обращения).
● База (baseline) — исходный уровень затрат/объемов, от которого строятся изменения.
● Рефоркаст (reforecast) — пересмотр прогноза на основании факта и новых предпосылок.
● Лимит — управленческое ограничение расходов/платежей, связанное с правилами согласования.
Финал
● Метод бюджетирования — это не стиль оформления, а логика управления ресурсами.
● Приростное дает скорость и стабильность, но может законсервировать «исторические хвосты».
● ZBB полезен точечно: там, где спорно, дорого и влияет на управляемость.
● Скользящий прогноз нужен, когда важнее «не промахнуться в будущем», чем «сдать план раз в год».
● ABB приручает накладные, если у вас есть измеримые операции и причинные драйверы.
Вопрос: какой блок в вашем бюджете сегодня вызывает больше всего переговоров — и какой метод вы там реально используете (приростный, ZBB, скользящий или «как договоримся»)?
Если хотите — расскажу, как собрать гибридную схему (приростное + ZBB + скользящий + ABB) так, чтобы она пережила и закрытие месяца, и бюджетный комитет.
Цифры, как обычно, ни в чём не виноваты.