Вы начинаете проект по автоматизации бизнес процессов бюджетирования

Бюджетирование – основной инструмент прогнозирования деятельности компании, управления финансовыми потоками, контроля издержек и достижения финансовых результатов. Бюджеты позволяют согласовывать деятельность различных центров финансового учета (ЦФУ) внутри компании, контролировать вклад отдельных структурных единиц в достижение целей и выполнение задач компании.

В качестве ЦФУ, в зависимости от целей составления бюджетов, руководители различных уровней могут выделять следующие объекты:

• Сегменты бизнеса, направления деятельности
• Проекты
• Элементы организационной структуры (подразделения организации, компании холдинга, ЦФО)

В большинстве случаев бюджетирование компании состоит из трех бюджетов:

• Бюджет доходов и расходов (БДР)
• Бюджет движении денежных средств (БДДС)
• Бюджет баланса (или Бюджет по балансовому листу, ББЛ).

Формы бюджетов могут быть различными, с укрупненными статьями или более подробные, разбиты на длительные периоды (например, годовой бюджет по кварталам) или на более короткие периоды (например, месячный бюджет по неделям), консолидированные или составленные для каждого ЦФУ – в зависимости от потребности финансового менеджмента в компании.

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

Когда требуется автоматизация бюджетного процесса?

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

1. Подготовка и согласование прогнозов деятельности ЦФУ.
2. Консолидация бюджетов и утверждение KPI организации на бюджетный период.
3. Контроль исполнения бюджетов по ЦФУ и достижения общих KPI.
4. Анализ отклонений, составление отчетов о выполнении бюджетов.

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

Автоматизированная система бюджетирования позволяет решить три проблемы:

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

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

В то же время бюджетирования на базе Excel имеет ряд недостатков:

1. Невозможность коллективной работы
2. Ручная консолидация данных
3. Отсутствие гибкой настройки доступа к данным
4. Низкая производительность и отказоустойчивость при работе с большими отчетами
5. Минимальные возможности по интеграции с другими учетными системами

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

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

Модели внедрения автоматизации системы бюджетирования

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

Затем можно использовать различные модели внедрения. Каждый из подходов имеет свои плюсы и минусы и ограничения по применению.

• Программный продукт – методология учета

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

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

• Методологическая модель – программный продукт

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

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

Плюсы, которые получает компания:

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

Выбор программы для автоматизации бюджетирования

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

Наиболее популярные отечественные средства реализованы на базе 1С. Это могут быть как специализированные системы (Бит.Финанс, Финансист, Инталев и пр.), так и комплексные системы автоматизации, включающие блоки бюджетирования: 1С:Управление холдингом, 1C:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей. Из зарубежных – Oracle, SAP, IBM. Рассмотрим некоторые из названных продуктов.

SAP

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

Система комплексной автоматизации предприятия включает интеграционную платформу и несколько десятков отраслевых решений, а также готовое решение для среднего и малого бизнеса SAP All-in-One. С помощью интеграции SAP и 1С возможно создать единое информационное пространство, повысить качество аналитики и эффективность управления, тем самым снижая трудозатраты. Интерфейс приложения SAP Fiori адаптирован для России вместе со всеми отчетами, с учетом всех особенностей российского законодательства.

1C:ERP

Функционал конфигурации «1С:ERP Управление предприятием» включает обширный набор инструментов финансового планирования и контроля. Автоматизация бизнес-процессов на основе 1С:ERP в части бюджетирования дает возможность моделировать финансовые планы компании с учетом имеющихся ресурсов, осуществлять планирование оплат по планам продаж и закупок, контролировать расходы денежных средств, исходя из установленных лимитов. В отдельные разделы выделено планирование в различных разрезах: «Планы продаж по категориям», «Планы продаж по номенклатуре», «Планы производства», «Планы сборки (разборки)», «Планы закупок».

WA:Финансист

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

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

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

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

Автоматизация процесса бюджетирования – внедрение специализированного решения для системного построения бюджета, его планирования и контроля.

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

Бесплатная консультация по автоматизации бюджетирования

Автоматизация бюджетирования в 1С. Модели внедрения

В основном используется один из двух вариантов проведения автоматизации бюджетирования на базе программ, созданных на платформе «1С:Предприятие».

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

Для того чтобы не ошибиться в выборе стратегии внедрения рассмотрим плюсы и минусы этих подходов.

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

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

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

Методологическая информация, необходимая для автоматизации бюджетирования

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

Положение о финансовой структуре – описывает основные направления деятельности и виды затрат, структуру центров финансовой ответственности (ЦФО) и сферу их полномочий, структурный состав ЦФО – наименование структурных подразделений, основные статьи доходов, статьи затрат, поступления денежных средств и т.д.

Положение о бюджетировании включает в себя:

• Методику бюджетирования – правила формирования плановых цифр в бюджетных статьях всех бюджетных форм;
• Бюджетные формы – шаблоны представления бюджетов компании по статьям затрат, структуре доходов или другим аналитическим разрезам;
• План-фактный анализ задает границы благоприятных, допустимых и неблагоприятных отклонений для разных бюджетных статей (например, благоприятное отклонение – 0-3%, допустимое – 4-7%, неблагоприятное – более 8%).

Бюджетный регламент – маршруты действий по разработке, согласованию, корректировке, анализу и утверждению бюджетов. Он должен отвечать на вопросы:

• «Что делаем?» разрабатываем бюджет, согласовываем бюджет и т.п.;
• «Кто это делает?» указываем ответственных сотрудников;
• «Когда это делается?» указываем конкретные сроки исполнения.

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

Настройка бюджетирования в 1С под ваши бизнес-процессы и структуру компании

Проблемы в процессе автоматизации

На этапе подготовки к внедрению программы могут возникнуть следующие проблемы:

1. Отсутствие вовлеченности персонала компании Заказчика, саботаж со стороны сотрудников, срыв сроков, отказ от выполнения заданий;
2. Недостаточно квалифицированные, некомпетентные кадры со стороны компании Заказчика;
3. Смена участников проекта, задействованных в процессе его подготовки;
4. Недостаточность первичной информации, неверный подход к описанию задач, неоднозначная их трактовка;
5. Продолжительные согласования ТЗ заинтересованными участниками процесса, изменение требований к проекту.

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

• Установить временные рамки проекта;
• Распределить зоны ответственности;
• Создать инструменты контроля реализации системы;
• Определить и утвердить методы решения нестандартных задач;
• Провести дополнительное обучение персонала, принять дисциплинарные меры или нанять других людей.

Подбор оптимальной программы для бюджетирования — индивидуальный анализ ваших бизнес-процессов

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

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

Комментарий эксперта ITeam:Внедрение автоматизированной системы бюджетного управления не следует начинать с выбора программного обеспечения, только если это не «политическое» решение. Такой подход приводит к повышенным рискам затягивания сроков и стоимости проекта, т.к. не определены требования к автоматизированной системе и не ясен результат, который будет получен. Вероятнее всего, что такая разработка превратиться в непрерывный процесс совершенствования и перенастройки, пока руководство будет готово «содержать» специалистов. Можно предположить, что первый подход к автоматизации вполне реализуем, но в этом случае методология УЖЕ существует на предприятии, пусть и слабо формализовано, но «в головах» ключевых специалистов и руководителей она есть! Нельзя не согласиться с автором в том, что при внедрении необходимо много внимания уделять будущим участникам процесса бюджетирования: вовлекать их в проект и проводить обучение. Однако не стоит забывать и о вопросах мотивации, коммуникаций в процессе планирования, принятии управленческих решений и взаимосвязи с другими бизнес-процессами!

Выпускникконсалтинговой компании ITeam
ведущий специалист отдела бюджетирования ОАО “ГЛАВСТРОЙ”
Сергей Бежин

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

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

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

Рис. 1 Два классических варианта реализации стратегии автоматизации бюджетирования

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

Понятно, что оба эти подхода не являются безупречными. Основные их плюсы и минусы представлены в Таблице 1. Если компания выбирает первый подход, то здесь главное – убедиться в том, что методология, «зашитая» в программе, соответствует потребностям компании. Но одна из проблем как раз и заключается в том, что при первом подходе этот важный этап вообще отсутствует. Ведь компании, выбирающие этот путь, считают, что постановка бюджетирования – достаточно простая задача. К тому же в этом их убеждают ИТ-компании, которых Заказчик привлекает для автоматизации бюджетного управления. Поэтому этап планирования сводится только к выбору программы и компании, которая будет выполнять проект по ее внедрению. Очевидно, что если компания сама не знает, чего хочет добиться от проекта, то она и не сможет выдвинуть четкие требования к программному продукту и той методологии, которая должна быть в нем реализована.

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

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

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

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

Можно сказать, что получается как бы замкнутый круг. С одной стороны, перед тем как начать автоматизировать, нужно иметь четкое ТЗ, но для того чтобы его разработать, нужно обкатать методологию и регламент . А для того чтобы отладить методологию и регламент, потребуется собрать большое количество информации (плановой и фактической), причем не один раз, т.к. для внедрения бюджетирования может потребоваться пройтись по бюджетному циклу несколько раз. Естественно, что сбор информации в неавтоматизированном виде очень трудоемок и занимает много времени, но, с другой стороны, перед тем как автоматизировать, нужно знать, какая информация будет нужна.

Разорвать этот круг можно только итерациями. Но встает вопрос – с чего начать: с методологии и регламента или с программы? Как уже было сказано, практика показала, что когда компания выбирает первый путь, то на самом деле она тратит гораздо больше времени и денег на проект по постановке и автоматизации бюджетирования. Объясняется это на самом деле довольно просто. Переделать методологию, если она еще не автоматизирована, гораздо легче, чем в том случае, когда она уже «зашита» в программу. Поэтому и получается, что на перенастройку программы уходит очень много времени, а может оказаться и так, что, промучившись с программой несколько месяцев или даже год, компания может придти к выводу о том, что модель, используемая в этой программе, не соответствует потребностям компании. И что самое интересное, после того как происходит подобное событие, компания вместо того, чтобы сделать правильные выводы из допущенных ошибок, продолжает двигаться тем же путем. То есть компания начинает искать другую, более совершенную, программу и повторяет еще раз ту же саму ошибку, которая теперь может ей обойтись еще дороже. Таким образом, компания теряет деньги и, что более ценное, время.

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

Различия в подходах к автоматизации планирования и учета

Какой бы вариант автоматизации бюджетирования компания не выбрала, все равно она столкнется с решением такой задачи, как автоматизация плановой и учетной модели компании. Понятно, что для того чтобы что-то автоматизировать, это «что-то» должно быть. Речь идет о том, что для автоматизации плановой и учетной модели, они должны уже быть у компании. Правда, здесь нужно сделать одну очень важную оговорку. Ведь фразу «модель должна быть» можно понимать по-разному. Кто-то считает, что достаточно иметь в голове видение модели, чтобы начать ее автоматизировать. А кто-то убежден, что модель должна быть формализована на бумаге, и только при таком подходе можно обеспечить эффективное решение задачи автоматизации. Формализация модели как раз и происходит на этапе разработки технического задания (см. Рис. 1). Отказ от подготовки ТЗ иногда обусловлен тем, что создатели программных продуктов убеждают своих клиентов в том, что их разработка на самом деле является не просто программой, а конструктором, с помощью которого можно создать и автоматизировать модель бюджетирования в любой компании, причем как в части учета, так и в части планирования. То есть разработка ТЗ – вроде как лишний этап.

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

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

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

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

Рис. 2 Множество плановых и фактических управленческих отчетов

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

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

Рис. 3 Проектирование и автоматизация финансовой модели бюджетирования

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

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

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

Модель фактической управленческой отчетности

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

Рис. 4 Концептуальная модель формирования фактической управленческой отчетности

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

Модель плановой управленческой отчетности

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

Рис. 5 Концептуальная модель формирования плановой отчетности

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

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

Комбинированная стратегия автоматизации бюджетирования

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

Выпускник

консалтинговой компании ITeam
ведущий специалист отдела бюджетирования ОАО “ГЛАВСТРОЙ”
Сергей Бежин

В самом начале этой статьи речь шла о двух наиболее распространенных стратегиях автоматизации бюджетирования. Сейчас будет рассмотрен пример комбинированного варианта стратегии автоматизации финансовой модели бюджетирования. Логика его заключается в разделении задач автоматизации планировании и учета, поскольку они должны основываться на принципиально разных моделях. Но при этом необходимо добиться того, чтобы форматы плановых и фактических бюджетов совпадали. То есть при таком параллельном решении задачи автоматизации, конечно же, есть опасность того, что затем придется потратить время на стыковку форматов плановой и фактической отчетности. Причем такая опасность может существенно увеличиваться при автоматизации бюджетирования на крупном предприятии. Например, на одном достаточно крупном металлургическом комбинате возникла именно такая проблема. У них была автоматизирована модель планирования и модель учета, но по форматам отчетности они не совпадали. К тому же модель планирования была автоматизирована в одной информационной системе, а модель учета – в другой. Одна из причин сложившейся ситуации заключалась в том, что изначально не было обеспечено необходимых условий успешности проекта. В частности, вместо организации выполнения одного проекта с выделением в нем двух подпроектов (автоматизация планирования и учета) реализовывалось два проекта, которые выполнялись разными исполнителями без единого координирующего центра. Естественно, что потом пришлось потратить достаточно много сил и времени на то, чтобы в итоге построить интегрированное решение. В данном примере ошибка в организации работ по постановке и автоматизации бюджетирования обошлась компании достаточно существенными потерями времени, поскольку предприятие насчитывало более двух десятков тысяч сотрудников. Очевидно, что задача внедрения бюджетного управления в таких масштабных системах требует особенно тщательной проработки, но, к сожалению, достаточно часто по ряду причин этапом планирования проекта пренебрегают либо выполняют не с той степенью детализации, которая требуется. Все эти ошибки, допущенные при планировании, приводят в будущем к большим затратам финансовых и, что самое главное, временных ресурсов.

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

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

Рис. 6 Пример комбинированной стратегии автоматизации бюджетирования

Этап 1. Автоматизация управленческого учета

Итак, начинать автоматизацию бюджетирования можно с автоматизации управленческого учета. Эта задача решается легче, чем автоматизация планирования. Легче, конечно же, не означает легко, особенно если речь идет о крупном предприятии. Но все-таки учет и по методологии, и по организации проще, чем планирование. Грубо говоря, для того чтобы автоматизировать получение фактической информации, необходимо внедрить четкий регламент сбора первичных документов и ввода их в информационную систему. Причем этот ввод должен осуществляться в соответствии с требуемой аналитикой. Это значит, что те сотрудники, которые будут непосредственно «вбивать» данные в проводки, должны обладать необходимой информацией, чтобы заполнить все требуемые аналитики. Набор этих аналитик, используемых в учете операций, может быть свой в зависимости от операций. После ввода данных для получения нужных форм управленческого отчета останется только нажать на кнопку, чтобы программа по заранее определенному алгоритму смогла «выдернуть» нужные значения из журнала проводок в соответствии с выбранным периодом отчетности. Удобство учетной модели заключается в том, что сама учетная модель универсальна для любых операций. Ведь каждую операцию можно расписать по дебету и кредиту определенных счетов из плана счетов, затем определить для них соответствующие значения аналитических признаков, выбрав нужные элементы справочников (в зависимости от типа операции). Получается, что из одного и того же массива данных (журнал проводок) можно формировать различные отчеты. Если при разработке форматов отчетов компания что-то не учла, то особых проблем не возникнет. Нужно будет просто изменить методику получения отчета и получить отчет в другом формате. Никаких изменений в журнале проводок при этом делать не нужно. Таким образом, получается, что отладку методики учета и ее автоматизацию производить гораздо легче, чем в случае с моделью планирования. Особенно, если компания использует программный продукт, который значительно упрощает пользователю создание нужных ему отчетов с помощью специального мастера отчетов. Этот мастер отчетов является достаточно гибким инструментом настройки и позволяет сделать практически любой классический отчет, состоящий из статей и колонок с периодами. Еще одним его существенным преимуществом является то, что для настройки отчетов не требуется программист. Это значит, что специалист по управленческому учету при отладке форматов отчетности может без помощи программистов «поиграться» с учетной моделью и получить требуемый результат. То есть можно задать форматы отчетов, методику их заполнения и осуществить необходимые настройки программного продукта с использованием специального мастера отчетов. К сожалению, на практике часто бывает так, что даже тщательно проработанные форматы отчетов после введения их в эксплуатацию претерпевают изменения. Если для автоматизации управленческого учета компания использует достаточно жесткую систему, то понятно, что любое изменение в форматах отчетности может потребовать перенастройку системы. Такие перенастройки, как правило, связаны с тем, что программистам приходится частично переписывать программный модуль. Наверное, не стоит говорить о том, как будет увеличиваться количество ненормативной лексики, используемой программистами при очередных запросах бухгалтеров по изменению форматов отчетности. Использование же специализированного мастера отчетов позволит избежать всех этих временных затрат и скандалов между бухгалтерами и программистами. Специалисты по учету могут вполне автономно заниматься поиском нужных форматов отчетности, не дергая каждый раз программистов и не создавая им дополнительной работы.

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

Рис. 7 Пример формирования методики учета

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

Автор: А.Карпов

О чем статья?

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

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем – вам сюда.

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

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

Почему я решил ее написать?

Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
3. Почему BI – не основной инструмент автоматизации бюджетирования?

ПРОБЛЕМЫ И ПРИНЦИПЫ ИХ РЕШЕНИЯ

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

Поэтому в учете оптимально работает схема Документ –> Таблица (Регистр) –> Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).

Рис. 1. Учетная схема «Документ –> Регистр –> Отчет»

Планы же изначально – укрупненные. Поэтому вводить их удобно именно «сверху» (то есть, в таких же формах, в которых формируются отчеты).

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

Рис. 3

Проблема 1: Администрирование правил

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

Проблема 2: Скорость «сбора факта»

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

Проблема 3: Формы ввода планов

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

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

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

Теперь рассмотрим каждую проблему подробнее.

Проблема 1: Администрирование правил трансформации

На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Это плохо:

• Правила нельзя администрировать без изменения кода;
• Использовать их можно только в этом отчете.

  а значит:

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

Сложность правил трансформации

Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения – к организации; от склада – к региону; от номенклатуры товара – к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

Решение проблемы 1: mapping

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

Рис. 4

Это дает сразу два преимущества:

• Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
• Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

Но разработать инструмент для удобного маппинга больших объемов справочников – непросто.

Проблема 2: Скорость трансформации фактических данных

Решение проблемы 2: хранение трансформированных данных

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

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

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

Рис. 5

DWH

С этой проблемой связана сфера Хранилищ данных (DWH).

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

Какие плюсы:

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

Минусы:

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

  На практике

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

• Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже условный минус, поскольку по сути мы переносим нагрузку с оперативной памяти на постоянную
• Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы

ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

Но обычно этот термин употребляют именно в случаях, когда данные после трансформации куда-то записываются для хранения. То есть, процедура трансформации, выделенная на рис. 5 — это ETL.

У такого подхода есть плюсы:

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

Минус же один:

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

Проблема 3: Форма ввода бюджетов

Дело в том, что в классическом виде отчеты в программных продуктах – это средство вывода данных. Но вводить данные в них нельзя.

А вот для бюджетирования классическая схема «Форма ввода» (документ) –> внутренние таблицы –> Форма вывода (отчет)» не подходит.

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

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

Решение проблемы 3: интерактивные формы ввода-вывода

Решение тоже очевидно: вместо привычных «документов» и «отчетов», нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными – то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно «складывать» в то же самое хранилище данных, где лежат фактические данные (см. рисунок).

Рис. 6

Но реализовать такие формы значительно сложнее, чем обычные отчеты или документы в учетных системах.

Степень интерактивности может быть разной: проще реализовать заранее настроенные формы, сложнее – динамические (где заранее неизвестно количество колонок/строк, но заранее заданы их типы). Еще сложнее – позволять в пользовательском режиме «вращать» данные, строить новые формы и задавать произвольные формулы расчета, меняя структуру отчетов.

Решение проблемы 4: кубы

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

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

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

ВИДЫ ПРОГРАММНЫХ ПРОДУКТОВ В БЮДЖЕТИРОВАНИИ

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

• Системы исходных данных (системы учета, ERP-системы)
• ETL-инструменты
• Хранилища данных (обычные и OLAP-кубы)
• BI-системы
• EPM-системы
• Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):

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

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

Карта видов ПО в бюджетировании

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

Рис. 7

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

БЮДЖЕТИРОВАНИЕ В ERP-СИСТЕМАХ

Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

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

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

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

А теперь рассмотрим бюджетирование в конкретных ERP-системах.

1C: УПП

В УПП реализована следующая схема, но внутри одной базы.

Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

• УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping – в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

Недостатки бюджетирования в УПП:

• Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
• Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
• Старая платформа. Нельзя использовать технологию «Управляемые формы» 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP

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

Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

• Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

• Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
• Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
• Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на 1С:ERP, если она действительно подходит компании
• Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА

«Комплексная автоматизация» представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX

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

Рис. 10. Архитектура бюджетирования в MS Dynamics

И плюс, и минус системы – ее «заточенность» на собственные учетные модули Dynamics и их готовую структуру.

Плюсы:

• Интегрированность с учетными модулями. Настройка получения фактических данных из различных модулей ERP-системы достаточно проста.
• Интеграция. Достаточно много возможностей для загрузки готовых планов из внешних систем. Таким образом, Microsoft четко следует логике отделения EPM от ERP, вследствие чего EPM-системы очень хорошо «навешиваются» на Dynamics
• Workflow. Достаточно функциональная и прозрачная настраиваемая организационная модель бюджетного процесса

Минусы:

• ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
• Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) перерабатывать ее не только сложно, но и практически бессмысленно.

SAP S4 HANA

Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать отдельной EPM-системой «поверх» ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему (в SAP S4 HANA Cloud). Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в «обычной» практике. В нем аналитическая база данных строится не «над» храналищем (SAP BW), а реализована «под» ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу HANA.

Фактически, тот же эффект, ради которого задумывались технологии IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP

Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion (о котором мы тоже поговорим ниже), компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-СИСТЕМЫ

BI-системы (Business Intellegence) в «чистом» виде – это средство вывода данных. То есть, BI – это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).

Популярные BI-системы:

• Power BI
• Tableau
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

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

EPM-СИСТЕМЫ

EPM – сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных «План-факт» форм. Понятие EPM еще не стало общеприименимым на русскоязычном рынке, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте BI, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), которые выходят за рамки сводной отчетности, калькуляций и планирования. Но мы будем рассматривать EPM именно в части систем для автоматизации бюджетирования. Поэтому, например, мы будем называть продукт SAP Business Planning & Consolidation (SAP BPC) – EPM-системой, несмотря на то, что сам SAP называет ею более крупный продукт SAP EPM, в который включается SAP BPC.

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

Известные EPM-системы:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Бит.Финанс
• 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс

Бит.Финанс основан на методологии бюджетирования УПП, однако, в отличие от него, во-первых, поддерживается и развивается, а во-вторых, реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из внешних источников).

Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

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

Mapping – более развит, чем в УПП.

Получение фактических данных работает в трех вариантах:

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

Недостатки автоматизации бюджетирования в Бит.Финанс:

• Работа через формы документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от типичной для 1С документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования неудобно.
• Отсутствие гибких интерактивных форм ввода-и-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan

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

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

Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

Плюсы:

• Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн.
• Коллективная работа (в рамках подготовки плановых данных).
• UX и произвольное моделирование.
• ETL. Собственный и достаточно удобный ETL-инструмент.
• Требует минимальной IT-поддержки. Особенно по части моделирования.
• Стоимость. Дороговато для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже.
• Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении.

Минусы:

• Форматирование.
• Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.).
• Собственный синтаксис формул. Вообще использование собственного кода – всегда недостаток с точки зрения конечных пользователей.
• Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема не важна для многих компаний, но критична для некоторых. Возможно (я надеюсь на это), к данному моменту Anaplan уже решил эту проблему.
• Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: Anaplan в большей мере ориентирован на работу через моделирование, чем на быструю аналитику и репортинг.
• Ограниченные возможности для масштабирования.

И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс — в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа «Что-Если», расчета и утверждения планов (бюджетов), и планировать архитектуру заказчика нужно исходя из этого. Минус – в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможность легко «перегонять» данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (особенно с учетом того, что тарификация строится в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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

Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion

Поставляется минимум в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

Из-за экосистемности, архитектуры могут приобретать самые разные виды, но типовая выглядит примерно так.

Рис. 14. Архитектура бюджетирования в Hyperion (возможный вариант)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

В качестве ETL-решения предлагается Oracle Data Integrator, который выступает как универсальный механизм интеграции данных в экосистеме Oracle.

Плюсы автоматизации бюджетирования в Oracle Hyperion:

• Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle – один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracle’овой архитектуре (в этом я не специалист, если здесь таковые есть — просьба поправить).
• Ad-hoc («отчетность по запросу»).

Недостатки автоматизации бюджетирования в Oracle Hyperion:

• Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracle’овой среде в долгосрочной перспективе возможен меньший эффект.
• Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
• Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

IBM Planning Analytics

В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognos’а).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.

Рис. 15. Архитектура бюджетирования в Planning Analytics (возможный вариант)

Сильные стороны IBM Planning Analytics:

• Прогнозирование.
• Работа с событиями.
• Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
• Неэкосистемность. Что удивляет в работе с IBM – большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
• Поддержка продукта.

Минусы

• Сложность. Как и в случае с Hyperion: требуется значительное обучение пользователей, не самая легкая инфраструктура.

SAP BPC

В целом, отличительные особенности SAP – экосистемность, сложность архитектуры и инфраструктуры решений.

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

Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

• Интеграция данных. Хотя она и сложна, она функциональна и быстра, и это главное для крупных компаний.
• Визуализация.
• Workflow.

Недостатки бюджетирования на базе SAP BPC:

• UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
• Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо: разработчики ищут новые способы реализации задач. С другой стороны, для компаний это создает трудности при переходах на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища (SAP BW) для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как альтернативу NetWeaver; сейчас тенденция идет к тому, что компания переводит фокус с десктопной EPM-системы на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
• Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.

ETL-ИНСТРУМЕНТЫ

Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• SAP Data Services
• Oracle Data Integrator
• Microsoft Azure Data Factory
• и мн. др.

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

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

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

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

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

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

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

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

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

Рис. 1 Два классических варианта реализации стратегии автоматизации бюджетирования и управленческого учета

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

Понятно, что оба эти подхода не являются безупречными. Основные их плюсы и минусы представлены в Таблице 1.

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

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

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

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

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

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

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

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

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

Можно сказать, что получается как бы замкнутый круг. С одной стороны, перед тем как начать автоматизировать, нужно иметь четкое ТЗ, но для того чтобы его разработать, нужно обкатать методологию и регламент . А для того чтобы отладить методологию и регламент, потребуется собрать большое количество информации (плановой и фактической), причем не один раз, т.к. для внедрения бюджетирования и управленческого учета может потребоваться пройтись по бюджетному циклу несколько раз. Естественно, что сбор информации в неавтоматизированном виде очень трудоемок и занимает много времени, но, с другой стороны, перед тем как автоматизировать, нужно знать, какая информация будет нужна.

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

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

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

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

Различия в подходах к автоматизации планирования и учета

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2 Множество плановых и фактических управленческих отчетов

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

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

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

Таким образом, и сам процесс разработки плановой и учетной модели, и процесс автоматизации этих моделей, в принципе, можно реализовывать параллельно (см. Рис. 3). Естественно, при этом нужно обеспечить стыковку между этими моделями как на методическом, так и на программном уровне.

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

Рис. 3 Проектирование и автоматизация финансовой модели бюджетирования и управленческого учета

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

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

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

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

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

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

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

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

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

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

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

Модель фактической управленческой отчетности

Итак, рассмотрим сначала информационную модель получения фактической управленческой отчетности. Она устроена следующим образом (см. Рис. 4).

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

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

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

Рис. 4 Концептуальная модель формирования фактической управленческой отчетности

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

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

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

То есть в этом программном продукте автоматизирован сам процесс изменения форматов и методик управленческих отчетов. Речь идет о программном комплексе «ИНТЕГРАЛ» (демо-версию можно скачать здесь).

Модель плановой управленческой отчетности

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

Рис. 5 Концептуальная модель формирования плановой отчетности (бюджетов)

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

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

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

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

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

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

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

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

Комбинированная стратегия автоматизации бюджетирования и управленческого учета

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6 Пример комбинированной стратегии автоматизации бюджетирования и управленческого учета

Этап 1. Автоматизация управленческого учета

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 7 Пример формирования методики учета в программном комплексе «ИНТЕГРАЛ»

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

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

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

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

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

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

Этап 2. Автоматизация планирования

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

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

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

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

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

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

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

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

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

Пример интегрированной финансовой модели бюджетирования, разработанной в электронных таблицах, можно найти на CD-решении «Бюджетное управление предприятием».

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

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

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

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

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

Рис. 8. Пример настройки методики планирования в программном комплексе «ИНТЕГРАЛ»

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

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

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

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

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

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

Примечание: более подробно тема данной статьи рассматривается на семинарах-практикумах «Бюджетное управление предприятием» и «Постановка и автоматизация управленческого учета», которые проводит автор данной статьи — Александр Карпов.

---

Если у Вас возникли какие-то вопросы по данной статье, Вы можете направить их по адресу budgeting@bk.ru. Автор статьи ответит на Ваши вопросы в течение нескольких дней с момента получения.

---

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

Узнать для чего нужно становиться подписчиком данного сайта

---

---

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

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

Что следует понимать под бюджетированием?

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

Какие задачи выполняет бюджетирование на предприятии?

Среди основных целей и задач:

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

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

Почему многие предприятия до сих пор не используют бюджетирование?

Можно выделить несколько основных причин:

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

Как бороться с данными проблемами?

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

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

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

Внедрение бюджетирования

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

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

Функции бюджетирования и финансового анализа

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

Этапы внедрения бюджетирования

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

На первом этапе формируется финансовая структура предприятия.

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

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

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

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

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

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

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

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

Внедренная система бюджетирования в действии

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

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

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

Читать продолжение

МАТЕРИАЛЫ ПО ТЕМЕ:

• Объединение баз данных 1С для создания многофирменного учета
• Автоматизация документооборота
• Формирование управленческого баланса на примере действующей компании
• Автоматизация финансовых задач
• Автоматизация бюджетирования