Особенности бюджетного планирования в одном американском стартапе. В 26-ти с половиной главах.
Содержание - http://proza.ru/2026/08/21/1876
---
Глава 20
в которой мы узнаём, какие платежи назначаются быть Проектами, а какие нет
В предыдущей главе мы перенесли платёж за оборудование из февраля в апрель и сохранили его исходную дату. Теперь возникает естественное желание завести такую карточку на каждый рубль компании. Желание естественное и губительное.
Регистр Оперативного Бюджета содержит записи операций, которые уже были в Первоначальном Бюджете, и новых операций, появившихся позднее. Зачем нужны новые записи, мы видели на примере второй комнаты:
Текстовое представление рисунка 1. Таблицу нужно читать сверху вниз. Внутри каждой строки значения идут слева направо в таком порядке: статья расхода; сумма в Первоначальном Бюджете; фактическая сумма; отклонение факта от бюджета; процент отклонения; управленческий смысл.
Первая строка. Аренда первой комнаты; в бюджете минус 100; фактически минус 130; отклонение минус 30; отклонение минус 30 процентов; прежняя бюджетная операция стала дороже.
Вторая строка. Аренда второй комнаты; в бюджете записи не было, поэтому исходная сумма равна нулю; фактически минус 20; абсолютное отклонение минус 20; процент отклонения неприменим, потому что делить на нулевую базу нельзя; появилась новая, небюджетная по отношению к исходной версии операция. На исходном рисунке в процентной колонке стоит 0 процентов, но это технически неверное обозначение. Здесь следует читать «N/A», то есть «не вычисляется».
Итоговая строка. В бюджете минус 100; фактически минус 150; общее отклонение минус 50; отклонение минус 50 процентов. Из этих пятидесяти тридцать относятся к удорожанию прежней комнаты, а двадцать - к появлению второй.
А зачем переносить в этот регистр платежи, которые уже присутствуют в исходном плане?
Чтобы отдельно наблюдать те из них, чьи сумма, срок или само исполнение способны изменить решение о деньгах компании.
В этом североамериканском стартапе такие записи назвали ПРОЕКТАМИ. Название местное. В обычном управлении проектом называют временную работу с началом, окончанием и уникальным результатом: например, запуск новой линии или переезд офиса. Здесь слово используется гораздо уже и немного нахально. Бюджетный Проект - это отдельная ожидаемая денежная операция, за которой решили следить поимённо: хранить её собственный номер, даты, сумму, состояние и историю изменений.
Можно было назвать её «индивидуально контролируемой прогнозной записью». Но после такого названия никто не дошёл бы до конца этой главы. Поэтому оставим Проект, только не будем выдавать внутренний словарь одной компании за закон финансовой науки.
Что заставляет превратить платёж в Проект?
Во-первых, его сумма или дата заметно влияют на будущий денежный остаток.
Во-вторых, они могут измениться, и это изменение требует решения, а не простой замены числа.
В-третьих, у операции есть владелец - человек, способный сообщить её состояние и отвечающий за своевременное обновление записи. Он не обязательно распоряжается деньгами и не обязательно один принимает решение об оплате.
В-четвёртых, ошибка или пропуск могут иметь последствия, несоразмерные сумме. Сто долларов регистрационного сбора в ключевом штате могут быть важнее нескольких тысяч долларов обычных расходов, если без сбора компания потеряет право вести там деятельность.
Наконец, такую операцию неудобно надёжно прогнозировать общей формулой вместе с десятками похожих платежей.
Размер важен, но одного размера мало. Большой платёж может быть совершенно предсказуем. Маленький может удерживать лицензию, договор или доступ к рынку. Существенность определяется ещё и тем, способна ли новая информация изменить решение.
На рабочем совещании длинный список критериев можно заменить двумя вопросами. Первый: если сумма или дата изменится, должен ли кто-нибудь принять отдельное решение? Второй: можно ли надёжно пересчитать эту выплату вместе с другими по одному правилу? Если отдельное решение требуется, а общего правила недостаточно, платёж просится в Проекты.
Представим две выплаты по тысяче долларов. Первая - месячный счёт за связь для двадцати сотрудников. Число линий и тариф известны, поэтому сумму можно пересчитывать вместе со всем потоком. Вторая - задаток поставщику за единственный опытный образец. Суммы равны, но перенос задатка означает перенос поставки, испытаний и, возможно, запуска продукта. Второй платёж получает собственную запись не потому, что он дороже, а потому, что его изменение требует отдельного разговора.
Телефон, электричество, заработная плата, постоянная аренда и другие повторяющиеся выплаты возникают снова и снова. Это не значит, что они неважны и за ними никто не следит. Просто каждый телефонный счёт редко требует отдельной управленческой истории от первоначального плана до последней версии.
Такие расходы часто удобнее прогнозировать как повторяющийся поток. Аренда следует из договора и площади. Электричество - из тарифа, сезона и потребления. Зарплата - из численности, ставок и дат выплаты. Телефон - из количества линий и тарифа. Эти измеримые причины суммы называются драйверами прогноза. Когда меняется драйвер, пересчитывается весь ожидаемый поток. Не нужно превращать каждый месяц в самостоятельный Проект.
Но слово «обычный» не приклеено к виду расхода навсегда. Аренда небольшого кабинета может идти общей строкой. Аренда главного склада, пересмотр которой способен остановить компанию, может потребовать отдельной записи. Ежемесячная выплата по долгу повторяется, но из-за размера и последствий просрочки её разумно отслеживать индивидуально.
Это разделение распределяет не уважение, а внимание. Электричество не становится менее реальным оттого, что его прогнозируют общей формулой. Задаток не становится благороднее оттого, что ему выдали собственную карточку. Компания решает, где достаточно исправить правило расчёта, а где необходимо позвать конкретного человека и спросить, что изменилось.
Управленческое внимание ограничено не хуже денег. Если назначить Проектом каждую пачку бумаги, менеджеры получат сотни уведомлений и научатся закрывать их, не читая. Среди них затеряется тот самый регистрационный сбор, без которого компания не сможет работать в штате. Система, требующая одинакового внимания ко всему, практически оставляет без внимания всё.
Возьмём пограничный случай. Обычно аренду платят первого числа. Январский платёж из-за праздника ушёл 31 декабря. В помесячном отчёте декабрь получил дополнительный расход, а январь - недоплату. Если смотреть на два месяца по отдельности, возникли два отклонения по 100 процентов. Если посмотреть на саму операцию, компания всего лишь заплатила на день раньше.
Для многих операционных решений это календарное отклонение будет шумом. Однако перенос через границу года может повлиять на денежный запас, бухгалтерское закрытие, налоги или договорные показатели. Поэтому сначала нужно понять, на какой вопрос отвечает отчёт. Для оценки общей стоимости аренды день почти ничего не меняет; для остатка денег на 31 декабря он может оказаться существенным.
Итак, одна и та же выплата может прогнозироваться двумя способами.
Повторяющийся поток рассчитывается по обновляемому правилу: договорной сумме, численности, тарифу, сезонности или фактическому темпу последних месяцев.
Проект хранится как отдельная запись: с постоянным номером, исходной, договорной и ожидаемой датами, суммой, статусом, источником и владельцем.
Новая операция, которой не было в Первоначальном Бюджете, обязательно входит в актуальный прогноз, но не обязана автоматически становиться Проектом. В книге такая операция называется небюджетной только по отношению к исходной версии: это не означает, что она незаконна, не согласована или не подлежит учёту. Если она мала, повторяется и надёжно попадает в общий драйвер, её можно включить в поток. Если она требует решения или отдельного наблюдения, она получает карточку Проекта.
В начале бюджетного цикла исходная и ожидаемая даты бюджетного Проекта обычно совпадают. Затем менеджер сообщает новую информацию, и ожидаемая дата меняется в Оперативном Бюджете. Исходная дата остаётся в утверждённой версии. Договорная дата меняется только тогда, когда действительно изменились условия обязательства.
В этой книге бюджет построен по месяцам. Месяц - не календарный день, поэтому запись «декабрь 2017 года» лучше хранить как бюджетный период 2017-12. Некоторые системы вместо периода технически используют первое или последнее число месяца. Тогда рядом должно быть ясно указано, что 1 декабря означает весь декабрь, а не срок платежа именно первого числа. Технический способ хранения не должен незаметно создавать договорную дату.
Теперь начинается самое интересное. Открытый Проект дошёл до ожидаемого месяца, но платежа не произошло. Что должна сделать система?
Она не должна забыть запись. Если просто оставить ожидаемый платёж в закрытом месяце, будущий денежный прогноз потеряет его. Компания увидит лишние деньги, которых у неё нет.
Она не должна и молча делать вид, что никакой задержки не было. Если каждый месяц передвигать запись вперёд, переписывая единственную дату, многолетний долг всегда будет выглядеть как аккуратный платёж следующего месяца.
Поэтому автоматический перенос нужно разделить на две операции. Для расчёта будущих денег открытая, то есть ещё не оплаченная и не отменённая, сумма временно попадает в ближайший прогнозный период. Для контроля сохраняются договорная дата, прежняя ожидаемая дата и возраст задержки - число дней от неисполненного договорного срока. Владелец получает сигнал и должен подтвердить новую оценку, назвать причину или отменить запись на основании решения.
Например, регистрационный сбор 100 долларов должен был быть уплачен 28 февраля. Первого марта система не нашла факта. В мартовском денежном прогнозе сто долларов должны остаться как ожидаемая выплата, иначе они исчезнут из будущего. Но карточка одновременно получает статус «просрочено: 1 день». Если владелец подтвердил 5 марта, эта дата становится ожидаемой, а 28 февраля остаётся договорной. Если владелец молчит, строка не должна бесконечно путешествовать по календарю без предупреждения.
В результате одна запись отвечает сразу на два разных вопроса. Казначею она сообщает: «эти сто долларов всё ещё придётся отдать». Руководителю она сообщает другое: «обещанный срок прошёл, а ответственный ещё не объяснил, что случилось». Если оставить только первое сообщение, задержка исчезнет из управления. Если оставить только второе, сумма выпадет из прогноза денег.
Правило эскалации компания выбирает сама: напоминание владельцу, повторное напоминание через несколько дней, сообщение руководителю после установленного срока. Эскалация здесь означает передачу неразрешённого вопроса на следующий уровень ответственности. Автоматизация защищает от забвения, но не освобождает человека от подтверждения.
Иначе автоматический перенос производит очень убедительную ложь без единого лжеца. Программа исправно ставит платёж в следующий месяц, владелец ничего не подтверждает, а руководитель видит свежую дату и принимает её за новую информацию. Через полгода в регистре лежит не прогноз, а старая догадка, шесть раз переодетая в будущее. Поэтому машина вправе сохранить сумму, но не вправе самостоятельно объявить обещание обновлённым.
Теперь схему разговора двух регистров можно нарисовать так:
Текстовое представление рисунка 2. Схему нужно читать слева направо.
Слева находится Регистр Первоначального Бюджета. В нём две группы записей. Первая группа - обычные периодические или не требующие индивидуального наблюдения платежи. Они остаются в исходном регистре и в актуальном прогнозе рассчитываются как потоки по общим правилам. Вторая группа - выбранные Проекты. Их исходные суммы и периоды навсегда сохраняются в утверждённой версии бюджета.
От группы «Проекты» стрелка ведёт вправо, в Регистр Оперативного Бюджета. Там первая группа записей называется «Проекты из Первоначального Бюджета». Они сохраняют связь с исходными номерами, суммами и периодами, но получают текущие ожидаемые даты, статусы и историю изменений.
Ниже в Оперативном Бюджете находится вторая группа - новые операции, которых не было в Первоначальном Бюджете. На рисунке они названы небюджетными платежами. Часть из них получает собственную карточку Проекта, а повторяющиеся и предсказуемые операции может рассчитывать общий прогнозный драйвер.
Подпись рисунка говорит, что даты в Оперативном Бюджете «меняются как хотят». Это шутка. В рабочей системе дата изменяется только с указанием источника, причины и владельца; прежнее значение остаётся в истории, а договорная просрочка не исчезает.
На схеме из Первоначального Бюджета выбранные Проекты переходят в Регистр Оперативного Бюджета; там к ним добавляются новые операции. Подпись «даты меняются как хотят» следует читать как шутку. Даты меняются по протоколу: с источником, владельцем, причиной, сохранённой историей и отдельным признаком просрочки.
Первоначальный Бюджет разговаривает с Оперативным коротко. При запуске цикла он передаёт выбранные Проекты вместе с их номерами, суммами и исходными периодами. Дальше их текущие состояния живут в оперативном регистре. Исходная версия остаётся точкой сравнения и не пытается командовать будущим.
---
Что мы узнали в этой главе:
Проект с большой буквы - внутреннее название индивидуально контролируемой денежной записи, а не универсальное определение проекта;
запись выбирают для индивидуального контроля по влиянию на решение, неопределённости, последствиям ошибки и возможности назначить владельца, а не только по размеру;
повторяющиеся расходы не исчезают из прогноза: их можно рассчитывать общим драйвером вместо отдельной карточки на каждый месяц;
новая операция входит в актуальный прогноз, но становится Проектом только тогда, когда требует отдельного наблюдения;
автоматический перенос сохраняет сумму в будущем прогнозе, но не стирает договорную дату и возраст просрочки;
владелец должен подтвердить новую ожидаемую дату, причину изменения или отмену записи.
Вот это скучное перечисление свойств записей и правил их перехода из одного регистра в другой и называется Протоколом. Хороший протокол обычно читают реже, чем плохую подделку или песню о милицейском протоколе, но компания всё равно должна придумать собственный язык, на котором менеджеры понимают финансового директора, а он - их.
Послесловие к этой главе
Чтобы заставить стул вращаться вокруг окна, нужно нанять рабочих, вынести окно вместе с рамой из стены и поставить вертикально на прочную опору. Над окном придётся закрепить горизонтальную вращающуюся раму длиннее оконной, подвесить к её концу стул и соединить ось с ручкой через передачу, меняющую направление вращения. Кто-то начнёт крутить ручку, рама повернётся, и стул станет описывать круг вокруг окна.
То есть даже для такой ерунды понадобятся опора, ось, крепление, источник движения и человек у ручки. С бюджетным протоколом происходит примерно то же самое, только стул в конце месяца не падает вам на голову.