Особенности бюджетного планирования. 29

Особенности бюджетного планирования в одном американском стартапе.
Содержание - http://proza.ru/2026/08/21/1876
---

Глава 29

в которой я рассуждаю о принципе сохранения информации в индивидуальных операционных бюджетах

В предыдущей главе мы позволили менеджеру прикладывать к закрытым месяцам новую линейку. Он мог пересчитать ретроспективный эталон, но не мог переписать Факт, Первоначальный Бюджет и сохраненные версии прежних прогнозов. Теперь нужно разобраться, как такая память устроена внутри самого регистра.

В одной из предыдущих глав я упоминал о важном недостатке Отчета Оперативного Бюджета. Он должен показывать исполнимый график движения денег, по крайней мере на коротком отрезке времени. Когда директора переносят, сокращают или отменяют Проекты, кривая остатка денег становится лучше. На экране исчезает проблема, которая заставила людей принять решение. Поэтому при внесении записей нужно следовать принципу консерватизма: сохранять не неудобное число в текущем прогнозе, а свидетельство о том, какая опасность была увидена и что с ней сделали. К бухгалтерскому принципу осмотрительности это местное словоупотребление не относится. Речь идет о сохранении следа решения, а не о занижении активов или доходов.

При работе с индивидуальными операционными бюджетами директорам необходимо постоянно менять и корректировать свои представления о действительности. И как вы уже знаете, некоторые из них, особенно химики, любят это делать не только по отношению к будущему, но и к прошлому. Поскольку в стартапах изменения приходится вносить часто, иногда директор может не помнить, по какой или каким конкретным причинам график движения денег по его направлению именно такой, а не другой. Эти причины зависят не только от объективных событий, но и от субъективных - изменений того, что директор думал об ожидаемых событиях.

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

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

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

Предположим, вы планировали потратить 100 долларов на Проект №1 в марте 2017 года. Этот Проект попал в Первоначальный Бюджет. 12 февраля вы приняли решение, что Проект не будет реализован. 18 февраля компенсирующая запись попала в Регистр Операционного Бюджета: «Отмена Проекта №1; период плановой оплаты - март 2017 года; сумма - минус 100 долларов; дата решения - 12 февраля; дата внесения - 18 февраля». Новая запись ссылается на исходную. Исходная запись в 100 долларов остается на месте, а текущая оценка Проекта становится равна нулю: плюс 100 и минус 100.

В Регистрах Бюджетов все первоначальные записи по Проектам делаются в виде положительных чисел - так удобнее. Это локальная договоренность данного регистра, а не универсальное правило финансовых систем. При переносе в Отчет плановый отток может получить знак минус, потому что там он уменьшает остаток денег. Важно не то, какой знак сам по себе кажется «правильным», а то, чтобы одна и та же договоренность последовательно применялась во всех записях и формулах.

Предположим теперь, что отмененный Проект №1 тут же заменили Проектом №2 с той же плановой оплатой в 100 долларов в марте. Менеджеру может показаться, что ничего не изменилось: как было 100 долларов, так и осталось. Он может удалить старую строку, переименовать ее или просто заменить описание. Денежный итог при этом совпадет. Но совпадение итога не означает совпадения решения. Один Проект был отменен, другой появился. У них могут быть разные цели, контрагенты, риски, ответственные и последствия. Новый Проект будет небюджетным не потому, что для него «нет бюджета», а потому, что его не было в утвержденном Первоначальном Бюджете и он появился уже при обновлении прогноза. Если не записать его отдельно, план-факт анализ покажет нулевую разницу там, где изменилось само содержание плана.

Поэтому в регистре должны остаться три записи.

Первая: исходный Проект №1, март, 100 долларов.

Вторая: отмена Проекта №1, март, минус 100 долларов.

Третья: новый Проект №2, март, 100 долларов.

Текущий общий прогноз оплаты по-прежнему равен 100 долларам. Но из записей видно, что это уже другие 100 долларов.

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

У каждой из этих записей должны быть свой идентификатор, автор и время внесения. Компенсирующая запись должна ссылаться на ту, действие которой она отменяет. Исправление ошибки должно ссылаться на ошибочную версию. Новый Проект может ссылаться на отмененный как на причину замены. Кроме суммы и периода плановой оплаты нужны дата решения, тип изменения, причина, статус согласования и валюта. Иначе система сохранит цифры, но потеряет смысл изменения.

Здесь важно развести три вещи. Отмена Проекта - решение: прежнюю запись не уничтожают, а закрывают новой. Замена Проекта - два решения: отмена одного и создание другого. Ошибка ввода - не новое управленческое решение. Если вместо 100 долларов кто-то набрал 1000, система должна показать, что была исправлена ошибка, а не сочинять историю о внезапном сокращении расхода на 900 долларов. В системе с журналом изменений прежняя версия сохранится, но в отчете исправление должно быть отмечено именно как исправление ошибки.

Дата тоже не одна. Март 2017 года показывает, когда ожидалась оплата. Февраль показывает, когда было принято решение об отмене. Системная отметка времени - дата и время, которые программа автоматически присвоила записи при ее внесении, - показывает, когда изменение фактически попало в регистр. Менеджер сообщает дату решения, а системную отметку формирует сама система. Если решение приняли 12 февраля, а запись внесли 18-го, это не одна дата, а шесть дней, в течение которых общий прогноз мог оставаться неверным.

Принцип «не удалять, а добавлять» похож на то, что в разработке систем называют журналом событий: текущее состояние собирается из последовательности исходных записей, отмен и замен. Но одному североамериканскому стартапу незачем превращать каждую бюджетную строку в часть дорогой архитектуры. Иногда достаточно запрета на незаметное перезатирание, журнала изменений и связи между исходной и компенсирующей записями. Журнал изменений, или аудиторский след, должен позволять увидеть, кто и когда внес изменение, какое значение было прежде, каким оно стало и с какой причиной связано. Важен не модный термин, а возможность ответить на четыре вопроса: что мы ожидали, что изменилось, кто принял решение и как оно повлияло на нынешний прогноз.

Принцип сохранения информации важен для объяснительной части итоговых отчетов. Дата решения связывает прогноз не только с будущим платежом, но и с тем моментом, когда менеджер узнал достаточно, чтобы изменить ожидания. Поэтому отчет может показать не только итоговое отклонение, но и то, располагала ли компания новым знанием вовремя.

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

Однако журнал изменений может испортить то, что должен защищать. Если каждое изменение прогноза объявляют уликой некомпетентности, менеджеры научатся не прогнозировать лучше, а менять прогноз реже. Они будут держать новую информацию при себе, смягчать формулировки и ждать, пока неопределенность разрешится без них. В итоге история станет чистой, а общий прогноз - запоздалым.

Поэтому оценивать нужно не сам факт изменения, а его качество. Была ли новая информация? Изменил ли менеджер прогноз вовремя? Объяснил ли причину? Связал ли отмену с исходным Проектом и заменившей его записью? Само по себе отличие нынешнего прогноза от прежнего не является ошибкой. Неизменность прогноза после получения новой информации говорит не о стабильности, а о задержке обновления.

Запрет на удаление нужен не для того, чтобы хранить каждое движение курсора и собрать на дне базы музей случайных опечаток. Он нужен на границе, после которой чужие решения уже начали зависеть от записи. Если запись еще была черновиком и никто ее не видел, ошибку можно исправить без театра с отменой. Но как только запись вошла в утвержденную версию, попала в общий прогноз или стала основанием для обещания, ее изменение должно оставить след.

На одном экране менеджеру нужен простой текущий ответ: Проект №1 отменен, Проект №2 действует, в марте нужно 100 долларов. Этот экран может быть представлением - текущим видом данных, который программа рассчитывает из всей последовательности записей, не уничтожая ее. Это не новая версия регистра, заменившая старую, а удобный способ показать его нынешний результат. По кнопке «История» должно быть видно, как этот ответ получился. Иначе система либо засыпает менеджера слоями старых строк, либо показывает ему гладкое настоящее без причин.

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

---

В этой главе мы узнали:

Утвержденные и уже использованные записи не затираются: их изменяют новыми, связанными записями;

Текущий прогноз может показывать простой ответ, но история должна объяснять, как он получился;

Отмена, замена и исправление ошибки - разные события и не должны притворяться друг другом;

Период оплаты, дата решения и время внесения записи отвечают на разные вопросы;

Замена Проекта другим на ту же сумму сохраняет денежный итог, но изменяет содержание плана;

Журнал изменений нужен не для наказания за прежнее незнание, а для восстановления цепочки решений.