Библиотека управления

Новый подход к автоматизации бюджетирования

Карпов Александр Генеральный директор компании «РиК»

Оглавление журнала

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

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

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

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

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

(Продолжение следует.)