Хорошая финансовая модель
Финансовая модель инвестиционного проекта внешне очень похожа на финансовую отчетность действующей компании. Поэтому когда влезаешь в детали этой модели, то часто режет глаз расхождение в принципах учета или просто в том, в каком виде аналитик представил прогнозируемый бизнес. Где-то налоги считаются слишком приблизительно, где-то вместо точного описания перечня статей дается общая сумма, да еще и оценочно, на основе аналога, вместо того, чтобы указать цифры из прогнозов текущего проекта. Можно ли считать такие упрощения недостатком модели, зависит от обстоятельств.
За 15 лет мне четырежды приходилось с нуля придумывать принципы финансового моделирования и реализовывать их в программных продуктах. Три из этих продуктов до сих пор присутствуют на рынке и развиваются, выдержав много изменений версий, но сохранив первоначальную идеологию. Плюс с десяток моделей мы в разных ситуациях делали под заказ (это не считая мелких адаптаций). В результате накопилась уже некоторая статистика и можно попробовать определить простые правила, от соблюдения которых зависит – будет финансовая модель работоспособной и полезной или она станет бессмысленной игрушкой.
Вот эти правила:
1. Если учет какого-то фактора меняет денежные потоки на сумму, способную повлиять на решение по проекту, то этот фактор обязательно должен быть учтен. Как правило, речь идет о факторах, меняющих суммарный дисконтированный денежный поток проекта более чем на 5-10%.
Ну, например, нельзя игнорировать способ возврата НДС на инвестиции, т.к. это меняет денежные потоки примерно на 5% от общей суммы инвестиционных вложений. Именно на 5%, а не на 18%, т.к. вопрос обычно звучит так: вернется ли НДС через два месяца или через два года – ожидаемая реальная разница равна 18% * 25% * 1,5 = 6,75%. Здесь 25% – вероятная ставка дисконтирования, а 1,5 – среднее отставание зачета НДС (оценки приблизительные, взяты из усреднения практики).
2. Все прочие факторы из модели следует исключить, если только они не понадобятся для сохранения цельности описания проекта (см. п. 3).
Не надо мусорить в моделях! Они создаются не из любви к искусству, а для принятия решений. И если какие-то данные не влияют на принятие решения, то им нечего делать в модели.
У этого правила есть одна оговорка. О ней ниже.
3. Исходные параметры проекта всегда должны по формату и составу соответствовать тому набору данных, который обычно имеется у аналитика. Модель не должна запрашивать детальные цифры, которых обычно нет в готовом виде при подготовке прогнозов. Модель не должна игнорировать цифры, которые обычно известны аналитику и являются частью цельной картины проекта. Модель не должна вносить искажения в форму и состав данных проекта.
Модель должна быть автоматизированным отражением тех представлений, которые есть в голове у аналитика. Если по форме и содержанию она начинает существенно отличаться от того, в каком виде поступают исходные данные или в каком виде строятся сценарии, то модель становится мертвой. И тогда она служит уже не для принятия решений, а для создания отчетов.
Иногда даже незначимые данные имеет смысл вносить в модель просто для того, чтобы сохранить цельность картины.
4. Обоснованность модели всегда меньше или равна обоснованности исходных данных. Включение исходных данных с низким качеством обоснования снижает надежность всего прогноза.
По мере роста детализации модели обычно растет и неопределенность данных. Спросите у владельца магазина какую выручку он рассчитывает получить завтра – его прогноз будет вполне уверенным. Но расспросите его о прогнозах завтрашних продаж каждого товара – он не сможет ответить ничего разумно обоснованного. И поэтому модель, основанная на таком детальном планировании окажется бессмысленной. Это, конечно, две крайние ситуации. Но в каждой реальной модели приходится искать баланс между детальностью планирования и качеством доступных данных.
5. Если аналитик не может проследить как исходные данные влияют на результаты, значит модель неработоспособна.
Как только человек, работающий с моделью, перестает видеть общую картину, возникает ситуация, когда «за деревьями не видно леса». И тогда во внесенных данных обнаруживаются самые смешные и бестолковые ошибки, ведущие к совершенно недопустимым искажениям. Обычно признаком того, что аналитик контролирует свою модель является следующее:
а) он может примерно сказать в каких ячейках кэш-фло произойдут изменения от внесенной им в исходные данные цифры и какова будет примерная величина этих изменений;
б) он может изменить модель под свои форматы исходных данных.
Это не обязательные пункты, но они примерно отражают общую идею.
Вот примерно так.