Содержание
В этой статье будут рассмотрены вопросы, связанные с автоматизацией финансовой модели бюджетирования. Конечно же, методологические вопросы финансового моделирования являются очень важными при внедрении и использовании системы бюджетного управления . Но конечным решением является автоматизированная система, позволяющая максимально облегчить техническую работу, которой может быть достаточно много как на этапе планирования бюджетов, так и на этапе сбора фактической информации об исполнении бюджетов. Поэтому автоматизация финансовой модели бюджетирования является также очень важной составляющей успешного функционирования системы бюджетирования.
Комментарий эксперта 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. Если же в аналитиках (справочниках) выбрать какие-то элементы, то суммироваться будут только те данные, у которых в соответствующих аналитиках приведен указанный элемент. В рассматриваемом примере по аналитике «Продукты-услуги» указано, что нужно формировать отчет по всем продуктам, то есть всем элементам справочника. Таким образом, если в справочнике «Продукты-услуги» сейчас пять элементов, то в отчете будут высвечиваться пять статей, в которых будут содержаться данные о выручке по каждому продукту за выбранный период. Если пользователя интересует конкретный канал сбыта, то в редакторе отчетов
Автор: А.Карпов
