Статьи

Версия для печати

Все статьи | Статьи за 2010 год | Статьи из номера N2 / 2010

Жизненный цикл и принципы эффективного финансового моделирования

Черемушкин С.В.,
к.э.н., доцент кафедры
государственного и муниципального управления
ГОУ ВПО «Мордовский государственный
университет им. Н.П. Огарева»

Введение

Мощнейшим аналитическим инструментом в управлении бизнесом является финансовое моделирование. Символическое моделирование — структурное и функциональное описание реально существующих объектов и процессов с помощью математических символов и формул. Разновидностью его является компьютерное моделирование, позволяющее создавать сложнейшие модели с использованием математических, статистических и логических операторов и функций. В свою очередь, в рамках компьютерного моделирования выделяют табличное моделирование (spreadsheet modeling), которое получило распространение с момента создания первой электронной таблицы. Собственно, под моделью можно понимать любую структуру, которая позволяет организовать процесс получения новой информации на основе старой, уже известной за счет раскрытия взаимосвязей между переменными, характеристиками объекта и переменными внешней среды. Таким образом, моделирование является одним из инструментов реализации системного подхода, о котором столь часто говорят на практике, но который редко удается увидеть выполненным в квантифицированной форме.

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

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

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

Концепция жизненного цикла модели

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

 

Определение сферы применения модели

Отправной точкой в построении модели является определение сферы ее применения (scope). На этой стадии устанавливаются цели и задачи модели, уровень ее использования, одиночная или совместная работа с моделью, необходимость консолидации данных различных подразделений и т. п.

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

Спецификация модели

Процесс спецификации охватывает определение структуры модели, составление перечня результатов (показателей), написание формул, по которым они рассчитываются, составление перечня исходных данных, допущений и требований к ним. Спецификация часто осуществляется на этапе разработки модели.

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

Процесс спецификации начинается с определения результатов, показателей, которые требуются пользователю для принятия управленческих решений.

В общем виде результаты формулируются уже на этапе определения сферы применения модели.

На этапе спецификации необходимо сформировать конкретные показатели, требования к ним, правила (стандарты) их расчета. Например, в прогнозировании финансовой отчетности можно придерживаться требований IFRS (МСФО) или РСБУ. Разумеется, при прогнозировании все учетные тонкости соблюсти не получится, да этого и не требуется, но общие принципы  (признание выручки, запасов, затрат по займам, аренды и т. п.) все-таки должны соблюдаться. Далее процесс идет от результатов к исходным данным. При составлении формул, по которым рассчитываются результирующие показатели, могут быть полезны взаимосвязанные схемы драйверов результатов на разных уровнях детализации. Они дают представление об исходных данных и промежуточных показателях. Они необходимы в тех случаях, когда формульная структура модели заранее неизвестна. Если представления о модели расплывчаты, формулы приходится выводить в несколько заходов. Возможно, наиболее сложные участки следует отложить до этапа разработки модели, но при этом остается риск провала проекта.

Инструментами спецификации модели являются:
1) схематическая карта модели, в которой в наиболее общей форме выясняются и отображаются структура взаимосвязей и содержание блоков модели;
2) пузырчатые диаграммы, деревья драйверов;
3) таблицы расчетов;
4) прототипы моделей.

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

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

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

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

Дизайн и разработка модели

Общепринятых стандартов экономического моделирования не существует.

Но организации могут принимать внутренние стандарты, основанные на передовых (best practices) принципах и правилах, собственных представлениях и пожеланиях руководства, пользователей моделей.

Принципы эффективного моделирования в электронных таблицах:
- выделение логических блоков модели (разделение исходных данных, промежуточных расчетов и результатов): блоков исходных данных, расчетов, отчетов, графиков, комментариев, служебной информации (логические операторы, флажки, данные для раскрывающихся списков и т. п.);
проверка исходных данных при вводе;
- размещение данных и написание формул слева направо и сверху вниз;
- ориентация данных в одном направлении либо в колонках, либо в строках;
- использование колонок для одних и тех же периодов — обеспечение соответствия между  переменными за счет расположения их в одной колонке или строке, т. е. использование каждой - колонки или строки по одному и тому же назначению;
- использование одной формулы на колонку или строку;
- недопущение использования констант в формулах (константы нужно вводить в отдельные ячейки, а в формулах использовать ссылки на них);
- прозрачность вычислений (использование имен в качестве ссылок на константы и переменные, по возможности использование одной формулы для целой строки или столбца);
- краткость изложения информации;
- форматирование ради описания, а не декорации;
- выставление, а не сокрытие информации;
- избегание циклических ссылок (для этого следует всегда ссылаться на ячейки, располагающиеся слева и выше от текущей ячейки, в которую вводится формула). Данное правило также позволяет соблюдать логическую последовательность при разработке модели. Однако от него приходится отступать в тех случаях, когда расчеты необходимо оформить в самостоятельные таблицы;
- использование разных книг для подразделений;
- документирование.

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

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

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

Наиболее опасный способ конструирования моделей, часто применяемый на практике, — создание новой модели на основе частей ранее созданных моделей путем копирования и вставки через буфер обмена. Такие «лоскутные» модели необходимо тщательно тестировать и выверять на ошибки, возникающие вследствие нестыковок при «сшивке» частей, и ошибки копирования.

Дизайн модели

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

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

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

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

При необходимости лучше поместить промежуточные таблицы отдельно, чтобы они не мешали чтению модели.

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

Модель должна позволять легко изменять горизонт прогнозирования. Например, при оценке бизнес-плана интересно оценить несколько версий модели с различной длительностью проекта.

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

Намного сложнее изменять интервал планирования, т. е. переключаться между годами, месяцами, кварталами. Если в этом есть необходимость, то модель должна рассчитываться для минимального интервала планирования (чаще всего для ежемесячных данных). Главная проблема здесь  заключается в учете сезонности и в описании переходов между временными интервалами. Для большинства переменных (например, выручки, затрат, прибыли и т. п.) переход к большему временному интервалу осуществляется суммированием. Для других переменных может потребоваться вычисление среднего значения (валютный курс, ставка процента). В отдельных случаях необходимы особые процедуры, как, например, с запасами: уровень запасов определяется на начало года и будет равен уровню запасов на начало первого месяца этого года.

Структура финансовой модели

Эффективная модель должна быть разбита на смысловые блоки, которые объединяют информацию, общую по целям представления или однородную по какому-либо признаку (признакам). Общая структура любой финансовой модели представлена на рис. 2.

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

При выборе горизонтального или вертикального расположения модели следует руководствоваться определенными правилами. В частности, при прогнозировании финансовой отчетности, построении экономических планов, бюджетов традиционно прибегают к горизонтальному расположению данных, когда переменные вводятся построчно. Для выполнения статистического анализа, например установления регрессионной зависимости между переменными, обычно используют вертикальное расположение. Это удобно по той причине, что цифр в рамках каждой из переменных обычно значительно больше, чем наименований переменных, и вертикальное расположение оказывается более компактным. Кроме того, штатные средства статистического анализа Excel, как, впрочем, и других статистических пакетов (Statistica, SPSS, EViews), позволяют выполнить анализ данных, только если они расположены построчно. При разработке громоздких моделей, если отсутствуют другие соображения, следует руководствоваться простым правилом — выбирать такое расположение, которое обеспечивает большую компактность модели (если в модели больше переменных, чем длина переменной, содержащей наибольшее количество ячеек с данными).

Раскладка (layout) логических блоков модели может осуществляться как на одном рабочем листе, так и на отдельных листах. В целях моделирования удобнее размещать модель на одном листе. При этом содержимое логических блоков можно сгруппировать. В сложных финансовых моделях переменные принято отображать по строкам, тогда как статистическую информацию чаще всего отображают в столбцах (что связано с экономией пространства рабочего листа и удобством обзора и навигации).

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

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

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

Например, ИПЦ — 12% (прогноз Министерства экономики). Источник можно указывать в примечаниях к ячейке с введенными данными, но это не очень удобно, поскольку примечания в Excel плохо читаются и выводятся на печать только с указанием на координаты ячеек и источник может распространяться не на одну ячейку, а на целый диапазон. Поэтому удобнее зарезервировать отдельный столбец для примечаний (рис. 3).

 

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

Важно отметить, что цель тестирования модели — не подтвердить соответствие целям и задачам, установленным в спецификации, правильность построения, удобство использования, отсутствие ошибок, а, наоборот, доказать, что модель не работает как положено, что модель содержит ошибки. То есть ответственные за тестирование изначально должны быть настроены критически.

Разработчики модели — лица заинтересованные, да и слишком замкнутые (зацикленные) на принятой в модели схеме. Поэтому полномасштабное тестирование следует поручать независимым экспертам из проектной группы или пользователям модели, которые обладают достаточными техническими знаниями в процедурах моделирования. В крайнем случае, если в организации моделированием занимаются несколько человек, то их обязанности можно распределить таким образом, чтобы они контролировали результаты друг друга. Этот вариант не очень хорош, поскольку специалисты становятся зависимыми друг от друга и быстро находят общий язык, чтобы скрывать взаимные промахи и ошибки.

С другой стороны, они могут нести ответственность за ошибки, обнаруженные в ходе практического использования модели. Лучше, если тестирование будут проводить два независимых эксперта или две группы. Впоследствии их результаты сравниваются между собой.

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

Тестирование модели разработчиком предполагает выполнение расчетов с условными или историческими данными. Кроме того, во все ячейки с исходными данными нужно ввести нули (за исключением раскрывающихся списков) и убедиться в том, что все результаты также будут равны нулю. Могут быть выполнены анализ чувствительности и стресс-тестирование модели с применением пограничных значений данных, установленных в рамках опции «проверка данных».

Такое тестирование позволяет обнаружить возможные ошибки в расчетах.

Среди часто встречающихся ошибок следует отметить:
- ссылки не на те ячейки (вероятность таких ошибок уменьшается при использовании имен переменных в формулах);
- ссылки на неполные диапазоны ячеек, которые возникают при увеличении диапазона, без изменения формул, которые ссылаются на этот диапазон (данную ошибку легко исключить, если ссылаться на именованные строки или столбцы; итоги по переменной лучше вынести в отдельную строку или столбец, при этом соблюдается и требование использования одной формулы на переменную);
- путаницу с относительными и абсолютными ссылками;
- неверную последовательность аргументов в формулах;
- путаницу со знаками «+» и «–».

Для тестирования моделей существуют специальные программы (как правило, это надстройки к Excel), позволяющие проводить автоматический аудит рабочих листов на предмет заполнения его текстом, константами, формулами, последовательности ссылок и т. п. К числу таких программ относятся Spreadsheet Professional, Excel Auditor, Spreadsheet Detective, (OAK) Operis Analysis Kit, SPACE (Spreadsheet Audit for Customs & Excise) и Klagenfurt Tool Kit. Excel содержит встроенный инструмент аудита с весьма скромными возможностями, но и он может оказаться полезным. Вместе с тем практика показывает, что он редко оказывается востребованным у разработчиков моделей.

Карта рабочего листа позволяет проанализировать структуру и размещение данных и формул на рабочем листе. Для отображения элементов используются символические обозначения. Например, в Spreadsheet Detective символ ### используется для обозначения ячеек, содержащих числовые данные, которые не умещаются в узкие колонки, xx — текст, @ — новая формула, & — формула, которая является копией формулы другой несмежной ячейки, < — формула, скопированная слева направо, ^ — формула, скопированная сверху вниз, ? — ошибка, $ — тривиальная формула. В других программах аудита рабочих листов применяются свои символы, иногда используется условная заливка ячеек, но принцип остается тем же.

На рис. 4 представлен анализ модели в Spreadsheet Detective, на нем отчетливо видны ошибки в раскладке данных. Прежде всего, бросается в глаза наличие числовых данных (т. е. констант) вперемежку с формулами. Учитывая, что вкладка «Расчет потребности в оборотном капитале» содержит блок расчетов, ввод исходных данных осуществляется фактически внутри расчетных таблиц, такой дизайн затрудняет последующую модификацию модели и ее повторное использование для анализа других подобных проектов. Кроме того, неэффективно введены периоды в строке 2, в случае изменения даты начала проекта во все ячейки с периодами придется вводить данные вручную.

Подготовка модели к использованию

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

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

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

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

Еще одна полезная возможность — вести контроль изменений, производимых пользователями в модели (Рецензирование — Изменения — Защитить общую книгу). Впоследствии разработчик модели может принять или отвергнуть отдельные изменения или все изменения конкретного пользователя (Рецензирование — Изменения — Исправления — Выделить исправления, Принять/отклонить исправления). Эта возможность уместна в тех случаях, когда пользователям необходимо принимать живое участие в доработке и модификации модели, когда пароли раздражают персонал, но, тем не менее, необходимо вести контроль за тем, что происходит с моделью. Подобный вариант является наиболее предпочтительным при организации групповой работы с моделью.

Особо необходимо отметить организацию коллективной работы с финансовыми моделями.

Вопрос здесь упирается в управление правами доступа и распределение ответственности за ввод исходных данных. Желательно сделать соответствующие пометки в самой модели, чтобы в  дальнейшем знать, кто вводил данные и из каких источников они взяты.

Управление правами доступа в приложениях Microsoft Office (IRM) осуществляется с помощью утилиты «Клиент управления правами доступа Windows (WRM)». Служба управления правами доступа к данным позволяет отдельным пользователям и администраторам задавать разрешения на доступ к документам, книгам и презентациям для предотвращения печати, пересылки или копирования важных данных пользователями, которые не имеют соответствующих прав.

После ограничения разрешений на доступ к файлу с помощью службы IRM эти ограничения на использование и доступ будут применяться независимо от того, где находятся данные, поскольку разрешения на доступ к файлу хранятся в самом документе. С помощью службы управления правами на доступ к данным можно выполнить следующие задачи:
- предотвратить передачу, копирование, изменение, печать, отправку по факсу или вставку содержимого с ограниченным доступом получателями такого содержимого, не имеющими соответствующих разрешений;
- предотвратить копирование содержимого с ограниченным доступом с использованием функции печати экрана в операционной системе Microsoft Windows;
- предотвратить отправку содержимого с ограниченным доступом;
- указать время окончания использования файла, по истечении которого содержимое документа не удастся просмотреть;
- применить политику управления использованием и распространением содержимого в пределах организации (office.microsoft.com/ru-ru/excel/HA101029181049.aspx).

Устанавливаются три уровня доступа: чтение, изменение, полный доступ.

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

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

Документирование модели

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

В документировании модели следует предусмотреть две части:
- документирование самой модели;
- документирование ввода данных и допущений.

Документирование модели предполагает указание следующей информации:
- название модели;
- описание целей и задач использования модели, другая информация по сфере применения модели;
- авторы модели;
- ответственное лицо;
- дата создания модели;
- версия модели и дата ее последнего обновления;
- список изменений по сравнению с предыдущей версией (для каждой версии);
- краткая инструкция по использованию модели;
- содержание модели (перечень логических блоков или рабочих листов).

Документирование ввода данных и допущений направлено на контроль правильности ввода данных и установление лиц, ответственных за подготовку работающей модели в целях принятия важных управленческих решений, и включает следующую информацию:
- наименование компании, подразделения, для которых составлена модель;
- цели применения (для принятия каких решений она предназначена, например подготовка сделки по приобретению компании Y);
- лица, ответственные за сбор, обоснование и ввод информации в модель;
- лица, осуществлявшие ввод данных, могут быть установлены при использовании режима  внесения исправлений при совместном использовании книги Excel;
- список рассылки модели (указание пользователей);
- комментарии и обоснования к составленной модели.

Заключение

Финансовое моделирование охватывает широкий круг задач — от выполнения несложных расчетов и калькуляторов для решения единичных типовых задач (например, сравнение эффективности заемного финансирования или лизинга) до построения сложных балансовых и вероятностных имитационных моделей предприятия (анализ инвестиционных проектов, долгосрочное прогнозирование финансовой отчетности), используемых для анализа целого комплекса последствий различных управленческих решений. Качество финансового моделирования обеспечивается введением единых корпоративных стандартов, принципов эффективного моделирования в электронных таблицах, распределением ответственности, организацией коллективной работы и т. д. В некоторых организациях предпочитают коммерческое программное обеспечение для целей прогнозирования и планирования. Однако нет такого коммерческого ПО, которое позволило бы отказаться от электронных таблиц. Кроме того, коммерческое ПО не защищено от ошибок в расчетах и применяемой методологии, обычно содержит жестко заданный алгоритм, изменение которого в принципе невозможно (особенно это касается многих программ бизнес-планирования). Разумеется, некоторые профессиональные системы сочетают готовые алгоритмы расчетов с гибкостью настройки и модификации методологии. Они предпочтительны для решения определенного круга задач. Но  профессиональных систем для целей прогнозирования и планирования финансовой отчетности, решения разнообразных специфических финансовых задач в принципе не может существовать. Всего не предусмотришь. Поэтому финансовым и экономическим моделированием всерьез должны заниматься в каждой компании. Электронные таблицы позволяют разрабатывать модели любой сложности, обладают неограниченными возможностями для модификации методологии расчетов. При этом за основу часто берутся готовые модели или шаблоны. Плата за подобную гибкость — персонализация моделей. В случае ухода или временного отсутствия разработчика для выяснения методологии расчетов придется заново разбираться в формулах, на что уходит много времени и сил персонала. Данный недостаток легко преодолеть, если наладить процесс документирования и сопровождения модели на всех стадиях ее жизненного цикла. Между тем коммерческое ПО также не лишено этого недостатка — методология расчетов обычно скрыта от глаз пользователей, и при получении готового результата сложно разобраться в том, каким образом он был получен. Вместе с тем практически отсутствует литература по разработке и сопровождению моделей, подготовленных в электронных таблицах. Имеются в основном только руководства по использованию электронных таблиц, но они не отличаются системным взглядом на проблему. Их задача — привить базовые навыки пользования программным обеспечением, и не более того.

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

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

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

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

Литература
1. Butler R. Losing At Spreadsheet Roulette. Proceedings of EuSpRIG 2002 Symposium. University of Wales Institute Cardiff, UK July 2002.
2. Butler R., 2002. The Subversive Spreadsheet, EuSpRIG. Available at: eusprig.org.
3. Cheremushkin, Sergei Vasilievich. Long-Term Financial Statements Forecasting: Reinvesting Retained Earnings (September 18, 2008). Available at SSRN: ssrn.com/abstract=1286542
4. Eugene F. Brigham and Joel F. Houston. Fundamentals of Financial Management (Thomson South-Western, 2007).
5. Grossman T., 2002. Spreadsheet Engineering: A Research Framework. Proceedings of EuSpRIG 2002 Symposium. University of Wales Institute Cardiff, UK. Available at: eusprig.org.
6. Howard, Malcolm K., 2008. Accounting and Business Valuation Methods, CIMA Publishing. Great Britain.
7. Martin Fridson and Fernando Alvarez, 2002. Financial Statement analysis: A Practitioner’s Guide, 3rd Ed., John Wiley & Sons, Inc.
8. McFedries, Paul, 2007. Formulas and Functions with Microsoft® Office Excel 2007 (Indianapolis: Pearson Education, Inc).
9. Michael C. Ehrhardt and Eugene F. Brigham, Corporate Finance: A Focused Approach (Thomson South-Western, 2006).
10. Nugus, Sue, 2006. Financial Planning using Excel Forecasting Planning and Budgeting Techniques, CIMA Publishing. Great Britain.
11. Panko, R. R., 2008. What We Know About Spreadsheet Errors. Journal of End User Computing’s, Vol. 10, № 2. (Spring 1998), Working Paper (Revised May 2008), Honolulu, HI 96822: Information Systems Department, College of Business Administration, University of Hawaii. URL: panko.shidler.
hawaii.edu/SSR/Mypapers/whatknow.htm.
12. Read, Nick, Jonathan Batson, 1999. Spreadsheet Modelling Best Practice, London: Business Dynamics.
13. Simon Benninga and Oded Sarig, Corporate Finance: A valuation Approach McGraw Hill, 1997).
14. Stephen Ross, Randolph Westerfield, and Bradford Jordan, Fundamentals of Corporate Finance (McGraw-Hill Irwin, 2008).
15. Swan, Jonathan, 2008. Practical Financial Modelling: A Guide to Current Practice. 2nd Ed. (Oxford: Elsevier).
16. Tjia, John S., 2004. Building Financial Models: A Guide for Creating and Interpreting Financial Statements (New York, The McGraw Hill Companies, Inc.).
17. Velez-Pareja, Ignacio and Tham, Joseph, Brief Introduction to the Construction of Financial Statements I(January 2002). Available at SSRN: ssrn.com/abstract=296293.
18. Velez-Pareja, Ignacio, A Step by Step Guide to Construct a Financial Model Without Plugs and Without Circularity for Valuation Purposes (July 25, 2008). Available at SSRN: ssrn.com/abstract=1138428.
19. Velez-Pareja, Ignacio, To Plug or Not to Plug, that is the Question: No Plugs, No Circularity: A Better Way to Forecast Financial Statements(June 16, 2008). Available at SSRN: ssrn.com/abstract=1031735.
20. Velez-Pareja, Ignacio, To Plug or Not to Plug, That is the Question: No Plugs, No Circularity: A Better Way to Forecast Financial Statements (Cuentas De Cuadre (Plugs) Y El Principio De Partida Doble: Construccion De Estados Financieros Sin Cuentas De Cuadre Y Sin Circularidad)(March 18, 2009). Available at SSRN: ssrn.com/abstract=1202142.

Отдельные номера журналов Вы можете купить на сайте www.5B.ru
Оформление подписки на журнал: http://dis.ru/e-store/subscription/



Все права принадлежат Издательству «Финпресс» Полное или частичное воспроизведение или размножение каким-либо способом материалов допускается только с письменного разрешения Издательства «Финпресс».