Статьи

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

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

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

Карпов А.Е.,
генеральный директор
компании «РиК»,
г. Москва

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

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

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

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

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

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

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

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

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

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

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

РАЗЛИЧИЯ В ПОДХОДАХ К АВТОМАТИЗАЦИИ ПЛАНИРОВАНИЯ И УЧЕТА
Какой бы вариант автоматизации бюджетирования компания не выбрала, все равно она столкнется с решением такой задачи, как автоматизация плановой и учетной модели компании. Понятно, что для того чтобы что-то автоматизировать, это «что-то» должно быть. Речь идет о том, что для автоматизации плановой и учетной модели они должны уже быть у компании. Правда, здесь нужно сделать одну очень важную оговорку. Ведь фразу «модель должна быть» можно понимать по-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МОДЕЛЬ ПЛАНОВОЙ УПРАВЛЕНЧЕСКОЙ ОТЧЕТНОСТИ
Теперь посмотрим, возможно ли создание универсального конструктора для разработки модели планирования. Опять-таки нужно начать с анализа информационной модели подготовки плановых управленческих отчетов. Пример такой концептуальной модели планирования представлен на рис. 5. Эта модель достаточно подробно рассматривается в литературе [3]. Сейчас основное внимание нужно уделить принципиальным отличиям модели учета и модели планирования.

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

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

Все равно их конструктор «заточен» под определенную модель планирования.

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

КОМБИНИРОВАННАЯ СТРАТЕГИЯ АВТОМАТИЗАЦИИ БЮДЖЕТИРОВАНИЯ
В самом начале этой статьи речь шла о двух наиболее распространенных стратегиях автоматизации бюджетирования. Сейчас будет рассмотрен пример комбинированного варианта стратегии автоматизации финансовой модели бюджетирования. Логика его заключается в разделении задач автоматизации планирования и учета, поскольку они должны основываться на принципиально разных моделях. Но при этом необходимо добиться того, чтобы форматы плановых и фактических бюджетов совпадали. То есть при таком параллельном решении задачи автоматизации, конечно же, есть опасность того, что затем придется потратить время на стыковку форматов плановой и фактической отчетности. Причем такая опасность может существенно увеличиваться при автоматизации бюджетирования на крупном предприятии. Например, на одном достаточно крупном металлургическом комбинате возникла именно такая проблема. У них была автоматизирована модель планирования и модель учета, но по форматам отчетности они не совпадали. К тому же модель планирования была автоматизирована в одной информационной системе, а модель учета – в другой. Одна из причин сложившейся ситуации заключалась в том, что изначально не были обеспечены необходимые условия успешности проекта. В частности, вместо организации выполнения одного проекта с выделением в нем двух подпроектов (автоматизация планирования и учета) реализовывалось два проекта, которые выполнялись разными исполнителями без единого координирующего центра. Естественно, что потом пришлось потратить достаточно много сил и времени на то, чтобы в итоге построить интегрированное решение. В данном примере ошибка в организации работ по постановке и автоматизации бюджетирования обошлась компании достаточно существенными потерями времени, поскольку предприятие насчитывало более двух десятков тысяч сотрудников. Очевидно, что задача внедрения бюджетного управления в таких масштабных системах требует особенно тщательной проработки, но, к сожалению, достаточно часто по ряду причин этапом планирования проекта пренебрегают либо выполняют не с той степенью детализации, которая требуется. Все эти ошибки, допущенные при планировании, приводят в будущем к большим затратам финансовых и, что самое главное, временных ресурсов.

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

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

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

ЭТАП 1. АВТОМАТИЗАЦИЯ УПРАВЛЕНЧЕСКОГО УЧЕТА
Итак, начинать автоматизацию бюджетирования можно с автоматизации управленческого учета. Эта задача решается легче, чем автоматизация планирования. Легче, конечно же, не означает легко, особенно если речь идет о крупном предприятии. Но все-таки учет и по методологии, и по организации проще, чем планирование. Грубо говоря, для того чтобы автоматизировать получение фактической информации, необходимо внедрить четкий регламент сбора первичных документов и ввода их в информационную систему [4]. Причем этот ввод должен осуществляться в соответствии с требуемой аналитикой. Это значит, что те сотрудники, которые будут непосредственно «вбивать» данные в проводки, должны обладать необходимой информацией, чтобы заполнить все требуемые аналитики. Набор этих аналитик, используемых в учете операций, может быть свой в зависимости от операций. После ввода данных для получения нужных форм управленческого отчета останется только нажать на кнопку, чтобы программа по заранее определенному алгоритму смогла «выдернуть» нужные значения из журнала проводок в соответствии с выбранным периодом отчетности.

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

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

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

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

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

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

ЭТАП 2. АВТОМАТИЗАЦИЯ ПЛАНИРОВАНИЯ
При автоматизации учета непосредственно к самой автоматизации можно приступать достаточно быстро, особенно если использовать для этих целей специализированное программное обеспечение, которое содержит в себе универсальный конструктор, позволяющий осуществлять оперативную настройку отчетных форм. По сути дела, с помощью такого инструмента можно разрабатывать методику управленческого учета и сразу реализовывать ее на практике, не прибегая к помощи программистов.

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

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

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

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

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

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

ЭТАП 3. СОЗДАНИЕ ЕДИНОЙ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ  БЮДЖЕТИРОВАНИЯ
На самом деле, конечно же, при разработке программного модуля для автоматизации модели планирования и учета нужно сразу стараться делать интегрированную систему, а не два отдельных программных продукта. Поэтому данный этап начинается не после завершения автоматизации модели планирования, а параллельно с этим этапом (рис. 6). К тому же не нужно забывать об одном из основных минусов такой комбинированной стратегии автоматизации бюджетирования. Используя такую стратегию, необходимо обеспечить четкую координацию работ по настройке программного модуля по управленческому учету и созданию программного модуля для автоматизации модели планирования.

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

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

Литература
1. Карпов А.Е. 100% практического бюджетирования: Книга 1. Бюджетирование как инструмент управления. – М.: Результат и качество, 2007.
2. Карпов А.Е. 100% практического бюджетирования: Книга 2. Регламент системы бюджетирования. – М.: Результат и качество, 2008.
3. Карпов А.Е. 100% практического бюджетирования: Книга 3. Финансовая модель бюджетирования. – М.: Результат и качество, 2007.
4. Карпов А.Е. Постановка и автоматизация управленческого учета. – М.: Результат и качество, 2008.
5. Карпов А.Е. Автоматизация бюджетирования и управленческого учета с использованием ПК «Интеграл». – М.: Результат и качество, 2008.

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



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