Когда полезная мысль тонет в смешении понятий
Есть одна вещь, которую я очень жду почти от любого курса по бюджетированию.
Чтобы кто-нибудь наконец честно сказал:
невозможно выбрать “правильный метод бюджетирования”, если в компании плохой факт, слабые данные и никто толком не договорился, как вообще считать бизнес.
И вот в занятии про алгоритм выбора метода бюджетирования эта мысль наконец прозвучала.
И это хорошо.
Потому что до этого многие разговоры про бюджетирование часто звучат слишком нарядно: стратегия, цели, KPI, бюджеты, контроль, сценарии, драйверы. Всё красиво. Всё на уровне правильных управленческих слов.
А потом ты приходишь в реальную компанию — и видишь, что там:
- фактическая маржа спорная,
- себестоимость плавает,
- статьи трактуются по-разному,
- продажи считают одно, финансы другое,
- формы собираются вручную,
- а бюджет хотят “сделать современным”.
И вот на этом фоне фраза о том, что без нормального факта сложное бюджетирование не взлетает, звучит почти как глоток воздуха.
Но дальше урок снова делает то, что в таких курсах случается очень часто.
Берёт здравую практическую мысль — и заворачивает её в логику, где постепенно начинают смешиваться разные понятия.
В итоге посыл полезный, а методология снова получается не до конца чистой.
Что в этом уроке действительно сильное
Сильное место здесь есть, и его нельзя не признать.
Лектор прямо говорит: если управленческого факта нет, если данные плохие, если аналитики не хватает, если компания не умеет собирать достоверную базу, то сначала надо разбираться с этим, а не строить красивую модель бюджетирования.
Это очень правильная мысль.
Потому что в жизни часто происходит наоборот.
Компания хочет сразу:
- драйверную модель,
- сценарное планирование,
- скользящий прогноз,
- увязку всего со всем,
- быстрые управленческие решения.
А по факту у неё даже нет согласованной базы, на которой это можно строить.
Ещё мне понравилось, что в уроке признаётся очевидная, но важная вещь: один и тот же метод не обязан применяться ко всему бюджету сразу.
Это тоже правда.
Выручка может планироваться одной логикой.
Производство — другой.
Маркетинг — третьей.
Административные расходы — четвёртой.
Инвестиции — пятой.
И в реальной практике так и бывает.
Это нормальный, живой подход.
То есть у урока есть хороший фундамент.
Но дальше начинается путаница.
Где урок начинает разваливаться
Главная проблема в том, что он как будто отвечает на один вопрос, а по дороге начинает отвечать сразу на три.
Формально тема звучит так:
как выбрать метод бюджетирования.
Но фактически внутри урока обсуждаются сразу разные вещи:
- зрелость компании, качество данных, готовность команды, сложность процессов, частота изменений, сценарность, rolling forecast, драйверы, нулевая база, инкрементный подход.
И в какой-то момент уже не очень понятно, что именно нам предлагают выбрать.
Метод расчёта?
Уровень зрелости модели?
Формат планирования?
Или ритм обновления прогноза?
А это всё разные плоскости.
Самая частая подмена в уроке: метод путают со зрелостью
Вот это, на мой взгляд, центральная проблема занятия.
Когда лектор говорит:
если данных мало — берём простую логику,
если данные хорошие — можно брать более сложную,
если команда зрелая — можно идти глубже,
если не зрелая — остаёмся на базовом уровне,
то это звучит практично.
И даже очень жизненно.
Но это уже не совсем про выбор метода бюджетирования.
Это про выбор доступного уровня управленческой сложности.
А это не одно и то же.
Потому что метод бюджетирования в нормальной постановке всё-таки должен сначала вытекать из природы объекта, а не из общего настроения компании.
Например, производственная себестоимость не перестаёт быть нормативной и ресурсной только потому, что команда пока незрелая.
Выручка не перестаёт зависеть от объёма, цены, каналов и ассортимента только потому, что руководители не готовы отвечать за драйверы.
Маркетинг не перестаёт требовать переобоснования расходов только потому, что исторически так удобнее тянуть прошлый год с индексом.
То есть экономическая сущность статьи никуда не исчезает.
Да, зрелость компании ограничивает, насколько глубоко и качественно мы сможем эту сущность отразить в модели.
Но она не должна подменять собой саму природу объекта.
А в уроке иногда возникает именно такое ощущение:
будто метод — это не то, что соответствует бизнесу, а то, что компания психологически и организационно сейчас способна пережить.
Почему меня особенно зацепил инкрементный метод
Потому что именно через него очень хорошо видно, где логика съезжает.
В уроке инкрементный подход звучит почти как естественный выбор для компаний с плохими данными или слабо выстроенным учётом. Мол, если нормального факта нет, тянем прошлое с поправками и живём так.
В бытовом смысле это, конечно, жизненно.
Так действительно делают очень многие.
Но методологически здесь важно говорить жёстче.
Инкрементный метод — это не “подходящий метод для плохих данных”.
Это чаще всего вынужденный компромисс, когда компания не может пока построить что-то лучше.
И это принципиальная разница.
Если сказать, что инкрементный подход — это просто один из нормальных методов под определённый тип компании, то слушатель может решить, что всё в порядке: данные слабые, ну и ладно, значит нам просто подходит такой способ.
А если сказать честно, что это временная уступка реальности, то сразу возникает правильный следующий вопрос:
что нужно сделать, чтобы перестать быть заложниками такой модели?
Вот этот вопрос в уроке, на мой взгляд, звучит слишком слабо.
Rolling forecast тут вообще живёт не на своей полке
Это отдельная и важная путаница.
Когда в одном ряду начинают звучать:
- инкрементный метод, zero-based, драйверный подход, ABB, rolling forecast,
это уже признак того, что разговор пошёл по разным уровням сразу.
Потому что rolling forecast — это не метод бюджетирования в том же смысле, что остальные перечисленные вещи.
Это вообще про другое.
Это не ответ на вопрос:
как посчитать показатель?
Это ответ на вопрос:
как часто и в каком горизонте переоценивать будущее?
Можно делать:
- драйверную модель и rolling forecast;
- инкрементный бюджет и rolling forecast;
- сценарное планирование и rolling forecast;
- даже относительно простую систему и rolling forecast.
То есть это не взаимоисключающие варианты.
Это разные оси управления.
Но в устной подаче урока они местами начинают звучать почти как соседи по одной категории.
И в результате у слушателя легко может сложиться ощущение, что rolling forecast — это просто “самый продвинутый метод бюджетирования”.
Хотя это не так.
То же самое происходит со сценарностью
Сценарность в уроке тоже подаётся как будто почти самостоятельный способ планирования.
Но здесь тоже нужна жёсткая развилка.
Сценарий — это не метод расчёта.
Это набор предпосылок и условий внешней или внутренней среды.
Например:
- курс валюты, цена сырья, объём спроса, ставка кредита, уровень инфляции, доступность логистики.
А внутри каждого сценария показатели всё равно могут рассчитываться по-разному:
- драйверно, нормативно, по нулевой базе, инкрементно, проектно.
То есть сценарность — это надстройка над моделью, а не замена модели.
Когда это не проговаривается отдельно, у слушателя остаётся очень расплывчатое ощущение: как будто есть просто “ещё один метод — сценарный”.
Драйверы в уроке будто становятся наградой за хорошее поведение компании
Вот это тоже очень характерное место.
В уроке прослеживается логика:
если учёт налажен, аналитики есть, данные хорошие, взаимосвязи видны — можно идти в драйверную модель.
Практически это верно только частично.
Да, без данных драйверную модель не собрать.
Но драйверы появляются не потому, что компания “дорастает” до них как до следующего уровня сложности.
Они появляются потому, что бизнес сам по себе живёт через причинно-следственные зависимости.
Выручка зависит от цены и объёма.
Себестоимость — от программы выпуска, норм, потерь, загрузки и цен ресурсов.
Логистика — от маршрута, плеча, объёма, тарифа.
ФОТ — от численности, ставок, графиков, премий.
То есть драйверы — это не приз за цифровую зрелость.
Это описание реальной экономической логики бизнеса.
Другое дело, что без зрелых данных компания может быть не готова описать эту логику полноценно.
Но это уже ограничение реализации, а не причина появления самих драйверов.
Zero-based budgeting в уроке слегка упростили до житейской интуиции
Это тоже очень узнаваемо.
Когда речь заходит о нулевой базе, лектор описывает её через понятные жизненные примеры: особенно там, где кажется, что расходы просто раздулись, историческая база неадекватна и надо сесть и заново подумать, что вообще реально нужно.
Как интуитивное объяснение — нормально.
Но если оставаться только на этом уровне, то zero-based budgeting начинает выглядеть как управленческое настроение:
«что-то у нас бюджет распух, давайте всё обнулим и заново пересмотрим».
А методологически всё же правильнее говорить точнее.
Нулевая база — это не просто эмоциональное решение сократить лишнее.
Это подход, при котором расходы не наследуются автоматически из прошлого периода и требуют отдельного обоснования.
И применять его полезно там, где историческая база искажает реальность, а не просто там, где кто-то почувствовал, что “слишком много тратим”.
В уроке всё время мелькает правильная интуиция, но не хватает жёстких границ между терминами
И вот это, пожалуй, уже фирменный стиль курса.
Лектор говорит живо.
Не по-канцелярски.
По-человечески.
С примерами, с образами, с понятными формулировками.
Это плюс.
Но минус в том, что такие живые объяснения очень легко начинают размывать рамки.
Например, в одном потоке начинают соседствовать:
- метод бюджетирования, уровень зрелости, сценарность, rolling forecast, готовность команды, качество данных, степень автоматизации.
В устной речи это воспринимается легко.
А вот в практической методологии потом превращается в кашу, если это не разобрать по полкам.
Име Как я бы собрала эту логику чище
Если совсем убрать лишнее и оставить рабочий каркас, я бы предложила такой порядок.
Сначала — понять объект планирования
Что именно мы планируем:
- выручку, производство, закупки, маркетинг, административные расходы, инвестиции,проекты, денежные потоки.
Потом — определить экономическую природу показателя
Он:
- нормативный, драйверный, инерционный, проектный, требующий обоснования с нуля, чувствительный к сценариям.
Потом — оценить ограничения компании
Есть ли:
- нормальный факт, аналитика, достоверные данные, готовность команды, автоматизация, возможность поддерживать выбранную глубину модели.
И только потом — выбирать реалистичный уровень метода
Не “самый красивый”, не “самый модный”, а тот, который:
- соответствует природе объекта, и при этом реально выдерживается компанией.
А уже после этого отдельно живут:
- сценарность, rolling forecast, версия бюджета, корректировки, план-факт, контур исполнения.
Вот тогда вся картина становится намного чище.
Мой итог по уроку
Этот урок мне понравился больше предыдущих в одном важном месте:
он наконец возвращает разговор о бюджетировании с уровня красивых конструкций на уровень реальных ограничений компании.
И это очень полезно.
Но дальше он снова начинает смешивать:
- метод расчёта, формат прогноза, зрелость системы, готовность команды, сценарность, сложность модели.
Из-за этого урок хорошо чувствует практику, но пока не до конца держит методологические границы.
Мой короткий вывод
Полезная правда в этом уроке есть: метод нельзя выбирать в отрыве от реальности компании. Но сама логика выбора пока объясняется так, что местами путаются природа статьи, зрелость системы и формат управленческого процесса.