Книга Александра Карпова

"Эффективная система бюджетирования и управленческого учета. Практические советы и рекомендации"
Бумажная версия: 260 руб. Электронная версия: 100 руб. Заказать книгу


Статья Александра Карпова "Инвестиционный бюджет проектов и его связь с остальными бюджетами"


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

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

ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНО

ПК "ИНТЕГРАЛ" - программный комплекс для автоматизации бюджетирования и управленческого учета


Курс состоит из следующих частей:
  • Введение
  • Часть 1. Техническое задание на автоматизацию бюджетирования и управленческого учета
  • Часть 2. СУБД и ввод данных в систему
  • Часть 3. Создание новых справочников и настройка плана счетов
  • Часть 4. Ввод типовых операций и импорт данных из бухгалтерских программ
  • Часть 5. Мастер (конструктор) настройки модели
  • Часть 6. Создание новой строки бюджета/отчета и настройка модели планирования и учета
  • Часть 7. Многомерный OLAP-КУБ (OLAP-технология)


    Введение

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

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

    Какая программа лучше?

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

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

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

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

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

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

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

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

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

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

    А если чего-то нет, то это что-то невозможно автоматизировать.

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

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

    Несбыточная мечта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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

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

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

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

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

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

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

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

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

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

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

    ТЗ условно можно разбить на две основные части:
  • содержательная;
  • техническая.

    Кстати, техническую часть в некоторых случаях называют технический проект.

    Примерный состав содержательной части ТЗ:
  • цели и задачи системы;
  • основные функции;
  • предполагаемая структура данных;
  • предполагаемая стыковка с другими информационными системами.

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

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

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


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


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

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

    Основные требования к информационной системе

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

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

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

    Итак, можно выделить следующие основные технические требования к программному продукту по бюджетированию и управленческому учету:
  • использование перспективной СУБД (система управления базой данных) и многопользовательский режим работы;
  • удобство ввода данных;
  • удобство настройки модели;
  • использование многомерного иерархического OLAP-КУБа (OLAP-технология) для построения управленческой отчетности.

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

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

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

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

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

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

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

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


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


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

    Часть 2. СУБД и ввод данных в систему

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

    Система управления базой данных (СУБД) и многопользовательский режим работы

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

    Рис. 1. Укрупненная архитектура информационной системы

    Укрупненная архитектура информационной системы



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

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

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

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

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

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


    Если говорить о конкретных СУБД, то сейчас на рынке (причем в общемировом масштабе) наиболее распространенными являются разработки компании ORACLE и MicroSoft.


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

    Хотя если говорить о статистике, то СУБД компании ORACLE в основном пользуются очень крупные компании. А СУБД компании MicroSoft используют предприятия меньшего масштаба. На самом деле данное решение подходит и для крупного бизнеса, просто исторически ORACLE раньше вышла на этот рынок, чем MicroSoft.

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

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

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

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

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

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

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

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

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

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

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

    Но все равно вероятность этого события очень незначительна. А если она и возникнет, то всегда можно сослаться на то, что глючит операционная система или используемая СУБД. То есть можно сослаться либо на разработчиков операционной системы, либо СУБД.

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

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

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

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

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

    Ввод данных в систему

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

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

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


    Подробнее об автоматизации процессов ввода данных можно прочитать в бесплатной электронной книге "Автоматизация бюджетирования и управленческого учета с использованием ПК "ИНТЕГРАЛ"

    Книгу можно скачать здесь.




    Часть 3. Создание новых справочников и настройка плана счетов

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

    Создание новых справочников

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

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

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

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

    Рис. 2 Пример создания нового справочника

    Пример создания нового справочника



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

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

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

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

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

    Для построения таких иерархических отчетов желательно использовать многомерный иерархический OLAP-КУБ (подробнее об этом будет сказано ниже).

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

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

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

    Настройка плана счетов

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

    Рис. 3 Пример настройки плана счетов

    Пример настройки плана счетов



    Основные требования к информационной системе по настройке плана счетов:
  • неограниченное количество счетов;
  • достаточное количество аналитик;
  • контроль удаления счетов и аналитик;
  • изменение журнала проводок при добавлении/удалении аналитик у счетов.

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

    Кроме того должна быть возможность привязки к каждому счета необходимого количества аналитик (справочников). Например, в программном комплексе "ИНТЕГРАЛ" для каждого счета можно выбрать до 10 аналитик.


    Демо-версию ПК "ИНТЕГРАЛ" можно скачать на сайте здесь.



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

    Например, если у счета 90.1 "Выручка" есть аналитика "Продукты", а у счета 62.1 "Расчеты с покупателями" такой аналитики нет, то после того как в плане счетов к счету 62.1 добавить аналитику "Продукты" во всех проводках (где по Дт 62.1, а по Кт 90.1), значение аналитики "Продукты" у счета 62.1 должно быть скопировано из такой же аналитики счета 90.1.

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

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

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

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

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

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

    Часть 4. Ввод типовых операций и импорт данных из бухгалтерских программ

    В этой части курса будут рассмотрены основные способы ввода данных в информационную систему.

    Ввод типовых операций

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

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

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

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

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

    Таблица 1. Пример типовых операций в системе управленческого учета

    Название операции

    1

    Денежные средства

    1.1

    Поступление денежных средств

    1.2

    Выплата денежных средств

    2

    Покупатели

    2.1

    Оказание услуг

    2.2

    Реализация продукции

    3

    Поставщики

    3.1

    Начисление расходов

    4

    Сотрудники

    4.1

    Начисление зарплаты

    4.2

    Налоги с ФОТ

    4.3

    Начисление НДФЛ

    4.4

    Выплата зарплаты

    4.5

    Авансовый отчет

    5

    Основные средства

    5.1

    Поступление ОС

    5.2

    Ввод в эксплуатацию

    5.3

    Модернизация ОС

    5.4

    Начисление амортизации

    6

    Материалы

    6.1

    Поступление материалов

    6.2

    Перемещение материалов

    6.3

    Списание материалов

    6.4

    Передача готовой продукции на склад

    7

    Расходы будущих периодов (РБП)

    7.1

    Ежемесячное начисление РБП

    7.2

    Списание РБП

    8

    Доходы будущих периодов (ДБП)

    8.1

    Ежемесячное начисление ДБП

    8.2

    Признание ДБП



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

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

    К операциям группы "Покупатели" в рассматриваемом примере относятся операция 2.1 "Оказание услуг" и 2.2 "Реализация продукции". Очевидным отличием этих операций является то, что в операциях второго типа автоматически происходит начисление расходов путем списания себестоимости реализованной продукции.

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

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

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

    Следующая группа операций в данном примере связана с сотрудниками (см. Табл. 1). С помощью операции 4.1 "Начисление зарплаты" можно вводить информацию о начисленной заработной плате. Операция 4.2 "Налоги с ФОТ" и 4.3. "Начисление НДФЛ" используются для начисления соответствующих налогов, а операция 4.4 "Выплата зарплаты" – для отражения операций по выплате денежных средств.

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

    Операция 4.5 "Авансовый отчет" используется для занесения информации о различных операциях, связанных с выплатой денежных средств через сотрудников, а не через расчетные счета.

    Пятая группа в данном примере связана с операциями, осуществляемыми с основными средствами компании. В представленном примере это 5.1. "Поступление основных средств", 5.2 "Ввод в эксплуатацию", 5.3 "Модернизация основных средств" и 5.4 "Начисление амортизации". Кстати, последняя операция может осуществляться полностью автоматически.

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

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

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

    Таким образом, операция 6.1 "Поступление материалов" используется для отражения данных о поступивших от поставщиков материалах на склад(ы) компании. В данном примере операция 6.2 "Перемещение материалов" используется для занесения в базу данных информации о материалах, переданных в производство.

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

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

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

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

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

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

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

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

    Таблица 2. Пример формата описания типовых операций

    Название операции

    Проводки

    Основные требования

    1
    1
    1
    1
    1
    1
    1
    1
    1
    1
    1
    1

    1

    1

    1

    1

    1

    1



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

    Таблица 3. Фрагмент примера описания типовой операции ("Реализация готовой продукции")

    Название операции

    Проводки

    Основные требования

    Реализация готовой продукции 1 проводка: Отгрузка продукции
    Дт 62.1, 76.5, Кт выбранного счета
    = Сумма без НДС, Сумма с НДС, Цена, Количество
    В форме должны быть следующие поля:
  • Дата. Появляется автоматически, можно менять
  • Валюта. Выбираются из списка (Из Справочника Валют)
  • Курс. Появляется автоматически (На основе заполненной карточки Валюты)
  • Сумма в валюте. Заполняется вручную
  • Цена . Заполняется вручную
  • Количество. Заполняется вручную
  • Сумма без НДС . Считается автоматически (Цена * количество), можно корректировать
  • Ставка НДС. Выбираются из списка (Из Налогового справочника)
  • НДС . Считается автоматически, можно корректировать
  • Сумма с НДС. Если стоимость услуг рассчитывается в валюте - считается автоматически (Валюта * Курс), если в рублях рассчитывается на основе данных Сумма без НДС и НДС, получившиеся значение можно менять
  • Комментарий. Заполняется вручную
  • Дт. Выбираются из списка: 62.1, 76.5
  • Кт . Выбираются из списка: 90.1, 91.1.1, 91.1.2, 98
  • 2 проводка: Выделен НДС
    Если Ставка НДС > 0, то
    Дт = Дт, указанному в операции, Кт 90.3
    =НДС, Ставка НДС
    3 проводка: Зачет аванса от покупателей
    Если Дт = 62.1 и (Ск по Кт 62.2 – Сумма с НДС) >=0, то
    Дт = 62.2, Кт = 62.1
    = Сумма с НДС
    Если Дт = 62.1 и (Ск по Кт 62.2 – Сумма с НДС) < 0 и Ск по Кт 62.2 > 0 и Сумма с НДС – (Сумма с НДС - Ск по Кт 62.2) > 0, то
    Дт = 62.2, Кт = 62.1
    = Ск по Кт 62.2
    4 проводка Себестоимость
    Дт 90.2, Кт 43
    = (Ск по Дт 43 (по колонке Сумма без НДС)/ Ск по Дт 43 ( по колонке количество) * Количество (указанное в операции)
    5 проводка Начислен НДС
    Если Дт = 62.1 и Ск по Кт 62.2 = 0 и Ставка НДС > 0, то
    Дт = 90.3, Кт = 68.2
    =НДС
    Если Дт = 62.1, Ск по Кт 62.2 > 0 и (Сумма с НДС – Ск по Кт 62.2) > 0, то
    Дт = 90.3, Кт = 68.2
    = ((Сумма с НДС – Ск по Кт 62.2)*Ставка НДС/100)/(1+СтавкаНДС/100)
    6 проводка: Заключительная проводка


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

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

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

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

    Если Ск по кредиту 62.2 равно нулю (то есть предоплаты по этой реализации не было), то НДС начисляется в полном объеме. Если данное сальдо больше нуля (то есть была предоплата), то НДС может начислиться только в том случае, если сумма реализации больше предоплаты.

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

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

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

    Рис. 4. Пример типовой операции "Реализация продукции"

    Пример типовой операции Реализация продукции



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

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


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



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

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

    Импорт данных из бухгалтерских программ

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

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

    Следует отметить, что если придерживаться упомянутой выше стратегии, необходимость импорта обусловливается еще и тем, что данные в большинстве бухгалтерских программ (в том числе в 1С) хранятся в формате, не пригодном для использования в OLAP-КУБе (он используется для построения управленческой отчетности). Эти данные сначала нужно преобразовать в специальный формат.

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

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

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

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

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

    Часть 5. Мастер (конструктор) настройки модели

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

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

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

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

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


    Подробнее об этом можно прочитать в Книге 3 "Финансовая модель бюджетирования" (Серия книг "100% практического бюджетирования")



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Создание новой бюджетной модели

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

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

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

    Итак, одним из требований к возможностям информационной системы в части настройки бюджетной модели может являться создание новой модели (см. Рис. 5).


    Здесь и далее на рисунках представлены примеры реализации функций по настройке бюджетной модели с использованием программного комплекса "ИНТЕГРАЛ". Естественно, что все эти функции в каждом программном продукте могут быть реализованы по-своему.

    Скачать демо-версию ПК "ИНТЕГРАЛ" можно в разделе здесь.




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

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



    Создание нового бюджета/отчета

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

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

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


    Более подробно о целях и архитектуре системы бюджетирования можно прочитать в Книге 1 "Бюджетирование как инструмент управления" (Серия книг "100% практического бюджетирования")



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

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



    Часть 6. Создание новой строки бюджета/отчета и настройка модели планирования и учета

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

    Создание новой строки бюджета/отчета

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

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

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

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

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



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

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

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

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

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

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

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

    Настройка модели планирования и учета по каждой строке бюджета/отчета

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

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

    В программном продукте строки ввода (впрочем, как и все остальные типы строк) могут вообще не иметь справочников или могут быть построены на основе одного или нескольких справочников.

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

    Таким образом, если строка ввода строится на основе справочника "Продукты и услуги" (см. Рис. 8), то при вводе (составление бюджетов) и при выводе (просмотр бюджетов) данных пользователь должен иметь возможность видеть не только одну строку (в нашем примере "Объем продаж"), но и все строки, созданные на основе элементов справочника (в нашем примере "Объем продаж по каждому продукту").

    Рис. 8. Пример создания строки ввода

    Пример создания строки ввода



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

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

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

    Рис. 9. Пример создания строки "Выручка от реализации" на основе журнала проводок

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



    Итак, в основном такой тип строк, как "Журнал проводок" выбирается при настройке фактической методики формирования строки бюджета.

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

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

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

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

    Рис. 10. Пример создания строки "Стоимость основных средств" на основе журнала проводок

    Пример создания строки Стоимость основных средств на основе журнала проводок



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

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

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

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

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

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

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

    Рис. 11. Пример создания строки на основе норматива

    Пример создания строки на основе норматива



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

    Рис.12. Пример настройки формулы

    Пример настройки формулы



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

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

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


    Более подробно о настройках бюджетной модели можно прочитать в бесплатной электронной книге "Автоматизация бюджетирования и управленческого учета с использованием ПК "ИНТЕГРАЛ"

    Посмотреть примеры настроек бюджетной модели можно в демо-версии ПК "ИНТЕГРАЛ"

    Скачать книгу и демо-версию ПК "ИНТЕГРАЛ" можно на сайте здесь.




    Часть 7. Многомерный OLAP-КУБ (OLAP-технология)

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

    Возможно, для кого-то использование OLAP-технологии (On-line Analytic Processing) при построении отчетности покажется какой-то экзотикой, поэтому применение OLAP-КУБа для них вовсе не является одним из важнейших требований при автоматизации бюджетирования и управленческого учета.

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

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

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

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

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

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

    Для подтверждения актуальности использования КУБа при построении управленческой отчетности можно привести простейший пример с бюджетом продаж. В рассматриваемом примере для компании актуальными являются следующие аналитические срезы: "Продукты", "Филиалы" и "Каналы сбыта". Если для компании важны эти три аналитики, то бюджет (или отчет) продаж можно выводить в нескольких вариантах.

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

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

    Рис. 13. Пример бюджета продаж, построенного на основе одной аналитики "Продукты"

    Пример бюджета продаж, построенного на основе одной аналитики Продукты



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

    Рис. 14. Пример бюджета продаж, построенного на основе двух аналитик "Продукты" и "Филиалы"

    Пример бюджета продаж, построенного на основе двух аналитик Продукты и Филиалы



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

    Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Филиалы" и "Каналы сбыта" представлен на рисунке 15.

    Рис. 15. Пример бюджета продаж, построенного на основе трех аналитик: "Продукты", "Филиалы" и "Каналы сбыта"

    Пример бюджета продаж, построенного на основе трех аналитик: Продукты, Филиалы и Каналы сбыта



    Нужно напомнить о том, что КУБ, используемый для формирования отчетов, позволяет выводить данные в различной последовательности.

    На рисунке 15 бюджет продаж сначала "разворачивается" по продуктам, затем по филиалам, а потом по каналам сбыта.

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

    Рис. 16. Пример бюджета продаж, построенного на основе трех аналитик: "Продукты", "Каналы сбыта", "Филиалы"

    Пример бюджета продаж, построенного на основе трех аналитик: Продукты, Каналы сбыта, Филиалы



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

    Рис. 17. Пример бюджета продаж, построенного на основе трех аналитик: "Филиалы", "Продукты", "Каналы сбыта"

    Пример бюджета продаж, построенного на основе трех аналитик: Филиалы, Продукты, Каналы сбыта



    Нужно обратить внимание на то, что это не все возможные варианты вывода бюджета продаж.

    Кроме того, нужно обратить внимание на то, что КУБ позволяет работать с иерархической структурой справочников.

    В представленных примерах иерархическими справочниками являются "Продукты" и "Каналы сбыта".

    С точки зрения пользователя он в данном примере получает несколько управленческих отчетов (см. Рис. 13-17), а с точки зрения настроек в программном продукте – это один отчет. Просто с помощью КУБа его можно просматривать несколькими способами.

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

    На рисунке 18 приведен пример раскрытия строки "Объем продаж", в котором по горизонтали представлены две аналитики (в данном случае "Продукты" и "Канала сбыта"), а по вертикали дата.

    Рис. 18. Пример раскрытия строки "Объем продаж" в КУБе: две аналитики по горизонтали, дата по вертикали

    Пример раскрытия строки Объем продаж в КУБе: две аналитики по горизонтали, дата по вертикали



    Если вторую аналитику (справочник "Каналы сбыта") переместить в область вертикальных измерений КУБа, то получится отчет, представленный на рисунке 19.

    Рис. 19. Пример раскрытия строки "Объем продаж" в КУБе: одна аналитика по горизонтали, вторая аналитика и дата по вертикали

    Пример раскрытия строки Объем продаж в КУБе: одна аналитика по горизонтали, вторая аналитика и дата по вертикали



    Если теперь дату перенести в область горизонтальных измерений КУБа, то получится отчет в котором по горизонтали показатель "Объем продаж" сначала раскрывается по продуктам, а затем по дате (см. Рис. 20). По вертикали при этом представлены данные об объемах продаж в разрезе каналов сбыта.

    Рис. 20. Пример раскрытия строки "Объем продаж" в КУБе: одна аналитика и дата по горизонтали, вторая аналитика по вертикали

    Пример раскрытия строки Объем продаж в КУБе: одна аналитика и дата по горизонтали, вторая аналитика по вертикали



    Если в области горизонтальных измерений КУБа поменять местами аналитику "Продукты" и дату, то в отчете по горизонтали объем продажа будет выводится сначала по дате, а затем по продуктовой аналитике (см. Рис. 21).

    Рис. 21. Пример раскрытия строки "Объем продаж" в КУБе: дата и одна аналитика по горизонтали, вторая аналитика по вертикали

    Пример раскрытия строки Объем продаж в КУБе: дата и одна аналитика по горизонтали, вторая аналитика по вертикали



    При этом по вертикали по-прежнему будут представлены данные об объемах продаж в разрезе каналов сбыта.

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

    А уж сам набор аналитик зависит от потребности пользователей в детализации.

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

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

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


    Пример многомерного иерархического OLAP-КУБа можно посмотреть в демо-версии ПК "ИНТЕГРАЛ", которую можно скачать здесь.



    Подведем итоги

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

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

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

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

    ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНО






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









    Свои комментарии к этому электронному курсу Вы можете направлять по адресу budgeting@bk.ru, указав свое Ф.И.О., должность и название организации, в которой Вы работаете. Ваши комментарии будут размещены в конце данного электронного курса.

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

    Кроме того по адресу budgeting@bk.ru Вы можете направлять свои предложения по улучшению и возможному дальнешейму развитию раздела "Электронные курсы по бюджетированию и управленческому учету".




    Дорогин Анатолий Юрьевич, финансовый директор компании "МАБИР", г.Красноярск

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

    Содержательный уровень - 5 баллов.

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

    В любом случае, я благодарен Вам за этот курс.


    Жугуров Тамирлан Кайнарбекович, начальник финансового отдела "Каспийская нефтегазовая компания", Астрахань

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


  • Яндекс.Метрика Рейтинг@Mail.ru