Модули или блоки финансовой модели

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

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

2. Глубина моделирования, которую вы выяснили на этапе планирования. Здесь конечная цель — понять необходимый уровень точности и детализации модели. Любой из показателей (любую из статей отчетности) можно прогнозировать разными способами, которые дают разный уровень точности. Более того, значимость показателей для результатов моделирования тоже отличается. В зависимости от этого вы можете принимать решения, создавать или нет отдельные модули для показателей, расходов, доходов, статей и т.д.

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

4. Характерные особенности бизнеса и процессов, которые моделируются. В данном случае такие характерные особенности могут прямо указывать на необходимость выделения некоторых расчетов в отдельные модули. Например, у финансовой модели консалтингового бизнеса, вероятно, должен быть отдельный модуль расчета количества проектов в работе и утилизации персонала; а транспортной компании может потребоваться модуль расчета лизинга, если она использует лизинговые схемы для приобретения активов.

Применительно к моделированию бизнеса, или компании, или большого проекта внутри компании, или инвестиционного решения относительно компании все модули структуры можно условно разделить на обязательные (must have) и необязательные (nice to have).
Обязательные модули

Практически всегда обязательными в финансовой модели являются три формы отчетности: ОФР, ДДС, Баланс. Формы отчетности содержат важные для итоговых результатов показатели, а также представляют собой инструмент проверки корректности моделирования.

Почему «практически всегда», а не «всегда»?

В простых расчетах и моделях некоторые из форм отчетности могут не понадобиться. Как уже отмечалось выше, в таких случаях они могут сокращаться или принимать вырожденную форму.
Например, заказчик ведет простейший торговый бизнес по принципу «купил-продал», не дает отсрочек и не покупает ничего в кредит. Для него важно, какой оборот нужен, чтобы окупить зарплату продавцов и заработать, например, 15 млн руб. в год. Для этого достаточно простого расчета, который учитывает стоимость товара, наценку, зарплаты продавцов и объем продаж. В простейшей финансовой модели такого бизнеса PnL и Cashflow можно соединить в одну таблицу, а Баланс не нужен вообще. Однако, например, если его цель — привлечь кредитное финансирование в банке, то, скорее всего, банку потребуются все три формы отчетности в финансовой модели, а также много других документов.
Подробнее рассматривать три формы отчетности и отдельные модули мы будем позже, а ниже можно ознакомиться с их краткой характеристикой и примерами применения.
Необязательные модули

Как ясно из названия, такие блоки в моделях появляются не всегда. Необязательные модули реализуют потребности заказчика или самой модели, когда трех форм отчетности недостаточно. Эти модули всегда индивидуальны.

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

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

Резюмируем:

1. Определить, какие модули будут присутствовать в финансовой модели лучше заранее на основании 4-х критериев: цель модели, глубина построения, ожидания заказчика (или ТЗ), особенности процессов.

2. В контексте бизнеса и компаний, в структуру финансовой модели обязательно входят три формы отчетности: ОФР, ДДС, Баланс. Иногда они могут сливаться и вырождаться, что является нежелательной практикой.

3. Дополнительные модули могут появляться в зависимости от сложности расчета показателей, сложности структуры и требований заказчика, но в целом такие модули не являются обязательными.