Финансовое моделирование в Excel

Финансовое моделирование в Excel

1.   Вступление

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

2.   Предпосылки

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

3.   Обзор

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

4.   Масштаб

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

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

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

5.    Обязанности пользователя модели и рецензента модели

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

6.   Обязанности Разработчика

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

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

6.1. Планирование

Разработчик должен провести адекватное исследование для определения цели(целей) модели и информации, необходимой для проектирования и разработки модели. Этот процесс должен определить;

Что модель будет и не будет делать;

Уровень сложности и упрощения допущений, которые необходимо сделать;

Требования к данным для модели и откуда эти данные будут поступать;

Оценки временных масштабов разработки модели; и

Как результаты модели будут использоваться для принятия решений.

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

6.2. Проектирование

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

Кроме того, модель может быть легко передана от одного пользователя к другому. Разработчик должен создать общую схему компоновки архитектуры модели, потока данных и связанных с ним выходных данных, которые будут объединены на этапе разработки.

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

Как данные должны быть сгруппированы вместе на свой собственный лист(ы).

Рабочие листы должны быть краткими, информативными и сгруппированы в логическом порядке.

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

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

7. Разработка

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

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

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

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

На приведенном выше рисунке показано, как меньшая модель будет выложена на одной странице. Это показано более подробно в следующем примере;

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

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

7.1 Консолидация Моделей

Существует три распространенных способа подключения листов;

  • Использование нескольких листов в одной книге.
  • Использование нескольких книг с макросом для включения данных в одну книгу.
  • Связывание книг (не рекомендуется).

Использование нескольких листов

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

Преимущества этого метода включают в себя:

Модель небольшая и будет работать довольно быстро;

Хорошо написанный макрос опытного моделиста, будет прост в использовании и понимании; и

Добавление дополнительного отдела в папку автоматически добавит эти данные на лист консолидации.

К недостаткам этого способа можно отнести:

Модель может быть довольно большой с большим количеством данных, находящихся в одном листе; и

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

Использование макросов

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

Преимущества этого метода:

Модель небольшая и будет работать довольно быстро;

Хорошо написанный макрос опытного моделиста, будет прост в использовании и понимании; и

Добавление дополнительного отдела в папку автоматически добавит эти данные на лист консолидации.

К недостаткам этого способа можно отнести;

Разработка такого рода модели требует опытного моделиста и детального понимания языка VBA. Или нет идеи и немного удачи с Google.

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

Связывание Книг

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

При аудите модели было 11 книг, прикрепленных к одной книге в виде ссылок. После открытия всех 11 книг, эти книги имели от 6 до 10 книг, связанных с ними. При открытии третьего уровня книг было обнаружено, что больше книг были связаны с этими книгами. Если среднее количество связанных книг на втором уровне равно 8, то перед рассмотрением книг уровня 3 в Книгу консолидации будет подано 88 книг. Последствия-это сотни и, возможно, тысячи рабочих книг, которые подаются в окончательную модель. Результат проведения аудита по такой модели является исчерпывающей задачей, и вероятность ошибок высока. Кроме того, высока вероятность того, что модель рухнет из-за размера подаваемых в нее резервных данных. Все усилия должны быть направлены на то, чтобы очистить книги от их ссылок с помощью метода (несколько листов или несколько книг), упомянутого выше.

7.2 Использование Формулы

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

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

Обслуживание за предыдущий год, умноженное на ИПЦ, записывается как;

Обслуживание за предыдущий год х 1,025 (где ИПЦ равен 2,5%)

Хотя приведенное выше предположение верно, его необходимо будет вручную изменить во всех ячейках, на которые влияет расчет ИПЦ. Чтобы избежать этой проблемы, установите именованный диапазон, первоначально названный «CPI», поэтому вместо ввода константы выше можно ссылаться на именованный диапазон «CPI». При изменении предположений ИПЦ необходимо изменить только одну связанную входную ячейку.

7.3 Текст

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

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

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

7.4 Безопасность И Защита

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

Рекомендуется, чтобы книги были защищены, даже когда требуется, чтобы разработчик модели:

контролирует доступ к книге;

контролирует доступ к листам в рабочей книге;

останавливает внесение структурных изменений в рабочую книгу; и

защищает ячейки, в которых находятся ценные предположения.

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

7.5 Риски В разработке

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

ошибка ввода

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

Методология

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

Размер

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

8. Тестирование

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

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

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

Выше приведен пример того, как можно использовать стандартное программное обеспечение аудита Excel.  Программное обеспечение может помочь:

Графическое отображение или трассировка связей между ячейками и формулами;

Трассировка прецедентов ячеек (поставщиков данных) и зависимых ячеек (получателей данных ячеек); и

проверка наличие ошибок в расчетах.

Это дает пользователю полезную визуальную информацию о потоках данных в пределах конкретного листа.

9. Документация

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

Документ должен использовать согласованный формат для каждого раздела, например:

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

Опишите входы и выходы, что пользователь должен ввести в систему и что система будет делать в результате;

Опишите процедуры для выполнения этих задач;

Укажите области риска в модели. Если конкретный процесс не выполняется, то вполне может быть неожиданный результат; и

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

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

10. Использование

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

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

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

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

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

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

Результаты проверки качества

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

Управление изменениями

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

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

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

В форме указывается, кто является пользователем, важно, кто подписал изменение и на какой лист повлияет изменение.

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

11.  процесс обзора

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

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

Механические ошибки — это простые ошибки, такие как опечатка номера или ячейки, ссылающиеся на неправильную ячейку:

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

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

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

Ошибки с единицами / элементами, цифрами. Если цены указаны в тысячах долларов распространенной ошибкой является отображение данных в целых долларах;

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

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

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

12.  Документация Рецензента

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

Административные — те ошибки, которые не влияют на целостность модели, однако лучше всего было бы исправить.

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

Материальные — вопросы, которые оказывают влияние на нижнюю линию модели, которые, если оставить их без внимания, поставят под сомнение обоснованность модели.

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

 13.  Поток Процесса Обеспечения Качества

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.