Системи бюджетування класифікація та вибір

Олександр Смотров

У цій роботі ми розповімо про основні концепції побудови автоматизованих систем бюджетування (АСБ), наведемо їх основні характеристики, а також дамо їх класифікацію та рекомендації щодо застосування.

Давно минули ті часи, коли бухгалтер займався тільки виписуванням документів, підрахунком оборотів за рахунками головної книги і складанням бухгалтерської звітності. З приходом ери персональних комп'ютерів на них лягло виконання частини звичних бухгалтеру рутинних функцій. Однак роботи від цього у нього не поменшало. Сьогодні керівник все частіше вимагає від бухгалтера не тільки підготувати бухгалтерську звітність, а й відповісти на ряд інших питань. Наскільки ефективно працює підприємство і які напрями діяльності найбільш прибуткові? Яка продуктивність праці і ефективність витрат? Які перспективи на найближчий квартал за величиною прибутку і потреби в отриманні кредиту?

Як і раніше, на допомогу знову приходить комп'ютер. Однак бухгалтерські системи не допоможуть у вирішенні поставлених завдань, потрібні програми іншого класу, звані "автоматизованими системами бюджетування".

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

Розмір має значення

Зазвичай усвідомлення необхідності автоматизації процесу бюджетування зароджується саме у фінансових службах. Але процес планування і виконання бюджету охоплює всю організацію, адже плани одного підрозділи тісно пов'язані з планами іншого. Так, бюджет продажів повинен бути тісно пов'язаний з бюджетом закупівель і з бюджетом витрат на рекламу, бюджет податків залежить від загального бюджету доходів і витрат і т. д. У невеликих організаціях процес бюджетування може бути централізований. Для даного випадку підійдуть "коробкові" програми з простою адаптацією під вимоги єдиного користувача, але функціонально вони підтримують лише базові елементи бюджетування. Для великих підприємств, в яких процес бюджетування розподілений по підрозділах, потрібні набагато більш потужні програми, що підтримують сотні користувачів. Наприклад, електронна таблиця - це ефективний засіб відстеження бюджетних показників на рівні одного фінансового підрозділу, але вона незрівняна за можливостями зі спеціалізованою автоматизованою системою бюджетування.

У роки існування СРСР і наявності централізованої соціалістичної економіки не було економічних стимулів для створення автоматизованих систем оперативного управління фінансами підприємств і проведення наукових досліджень в даній області. Тоді продажі вважали в умовних штуках, а витрати - в нормо-годинах і інших сурогатах. Процес автоматизації промисловості і торгівлі йшов по шляху розробки АСУ великих державних структур, галузевих АСУ, систем підготовки статистичної звітності для вищих і середніх ланок управління в державі (міністерств союзних республік, галузевих об'єднань, обласних і крайових управлінь, а також для великих підприємств), що створюються на базі універсальних, великих ЕОМ. Впровадження локальних обчислювальних систем на окремих підприємствах в більшості випадків було можливо завдяки розвитку виробництва вітчизняних мікро-ЕОМ. Після лібералізації економіки і широкого поширення доступних персональних комп'ютерів розвиток отримали облікові системи, значну частку яких становили додатки баз даних. Пізніше вони отримали серйозний розвиток і стали називатися корпоративними інформаційними системами (КІС), а далі, в залежності від рівня та напрями автоматизації, ще класифікувалися як більш високорозвинені MRP-і ERP-системи (Material Requirements Planning - планування потреби в матеріальних ресурсах, Enterprise Resource Planning - планування ресурсів підприємства). Вони охоплювали всі основні ділянки інформаційного поля комерційних фірм, що стало можливим тільки з застосуванням модульної концепції побудови додатків з єдиною базою даних.

З розвитком ринку і підвищенням конкуренції, в тому числі і з боку західних компаній, російські фірми змушені шукати нові інструменти, які мали б не тільки обліковими функціями, але і широкими можливостями проведення аналізу і підтримуючих процес бюджетного управління. Так як значна частина інформації про господарську діяльність підприємства вже була зосереджена в існуючих ERP-системах, то логічним стала поява окремих бюджетних модулів, які працюють з вже наявною базою облікових (бухгалтерських) даних. Проте впровадження та підтримка таких великих систем вимагають від користувача не тільки витрат на придбання ліцензій, а й серйозних додаткових фінансових вкладень - як капітальних (модернізація комп'ютерного та комунікаційного обладнання), так і поточних (витрати на інтеграцію модулів, утримання кваліфікованих фахівців ІТ-служби, навчання користувачів та ін.) Крім того, призначені для користувача ліцензії на такі системи досить дорогі, тому що створення самого програмного продукту потребує великих витрат з боку розробників. Тому окупитися ERP-системи можуть тільки на великих підприємствах, здатних з їх допомогою підвищувати ефективність настільки, щоб покривати витрати на придбання та утримання цих систем. Тим більше що терміни впровадження ERP-систем нерідко становлять два-три роки, а то й більше.

Нова економічна ситуація в Росії породжує конкуренцію і зачіпає значну кількість малих і середніх підприємств, на яких застосування EPR-систем було б збитковим. Однак такі підприємства також потребують в програмах, що підтримують сучасні технології управління і бюджетування. У результаті масового впровадження персональних комп'ютерів у господарську діяльність невеликих і середніх підприємств з'явилася можливість використання таких програм, але з урахуванням обмежень по системним вимогам для відносно недорогих персональних ЕОМ. Крім того, таке ПЗ повинно володіти коротким терміном впровадження, простотою в експлуатації, зручним для користувача інтерфейсом і невисокою вартістю. Такі програми, звісно, ​​не підтримують всі можливості ERP-систем, проте виконують базовий набір функцій бюджетування.

У той же час на російському ринку з'явилися і влаштувалися західні спеціалізовані системи бюджетування, які хоч і дорожче, ніж російські, але підтримують більш широкий набір функцій. Вони використовують більш сучасні і дорогі ІТ-технології, ніж російські системи, але, як правило, їх впровадження обходиться користувачеві дешевше, ніж впровадження ERP-системи. Така спеціалізація не тягне за собою для розробників додаткових витрат на підтримку інтеграції, які існують при створенні ERP-систем, і дозволяє творцям системи сконцентрувати ресурси на підвищення функціональності і продуктивності саме бюджетних функцій, що знаходить своє відображення як у меншій вартості програмного рішення для користувача, так і в більш широкому наборі бюджетних функцій.

Спеціалізація або уніфікація?

Основна відмінність спеціалізованих АСБ (привласнимо їм умовний код моделі "С") від ERP-модулів бюджетування (привласнимо їм умовний код моделі "М") криється у відмові від концепції єдиної уніфікованої бази даних для всього підприємства на користь розподіленого зберігання і обробки спеціалізованої інформації. Взаємодія з обліковими та іншими програмами в спеціалізованих системах бюджетування здійснюється через взаємний обмін даними. Таким чином, можна говорити про існування двох базових концепцій автоматизації бюджетного процесу на підприємствах. Перша полягає у застосуванні інтегрованих модулів корпоративних інформаційних ERP-систем. Друга передбачає використання спеціалізованих систем бюджетування.

Обидві концепції мають право на існування хоча б тому, що є сотні прикладів успішних впроваджень і по одній, і з іншої моделі. Однак користувачеві, перед яким стоїть проблема вибору комп'ютерної програми, резонно поставити тут питання про розходження в ефективності застосування програм, побудованих на цих концепціях, на підприємствах різного типу. У числі іншого значну роль тут відіграють завдання, які потрібно вирішити з впровадженням АСБ. В інтегрованих бюджетних ERP-модулях планування йде в основному не від цілей, а від плану продажів. У них закладається, яким чином розподіляти наявні обмежені ресурси, щоб виконати такий план продажів найбільш ефективно, виявляючи резерви, наводячи економію і т. д. На відміну від спеціалізованих систем бюджетування тут використовується детальна номенклатура бюджетних аналітик. При цьому для модулів бюджетування важлива інтеграція з корпоративною обліковою системою, тому що якщо складається бюджет з детальними аналітиками, то і контролювати його виконання необхідно в тому ж детальному розрізі. Тому управлінський облік по бюджетним аналітикам повинен бути організований дуже чітко.

Приклади побудови різних варіантів систем бюджетування наведено в табл. 1.

Застосовуючи підхід поділу управління на оперативне і стратегічне до виділених концепціям побудови АСБ, можна визначити, що особливістю ERP-модулів бюджетування є їх орієнтація на управління бюджетами структурних підрозділів, на відміну від спеціалізованих програмних продуктів бюджетування, орієнтованих на управління бізнесами. Найчастіше окремі підприємства холдингу автоматизовані на різних платформах, за допомогою різних програмних систем, а звести воєдино таку розрізнену інформацію можливе лише за допомогою відповідної спеціалізованої АСБ. Тому такі спеціалізовані АСБ повинні вміти консолідувати дані, які розташовані віддалено, в різних регіонах, в різних інформаційних системах та на різних платформах. Для фірми, що працює лише в одному ринковому сегменті, ситуація з існуванням тільки ERP-модуля цілком підходить, так як в даному випадку стратегія розвитку дуже тісно пов'язана з операційною діяльністю.

Усунути недоліки і з'єднати переваги двох вищеназваних концепцій дозволяють програмні продукти змішаного типу. Типовим прикладом є Oracle Financial Analyzer (OFA). Ця система займає двояке місце на ринку засобів автоматизації бюджетування. З одного боку, це спеціалізована АСБ, яка може бути використана як окремий програмний продукт. Але з іншого - при інтеграції в рамках єдиної інформаційної системи модуль OFA виконує функцію оперативного контролю і проводить план-фактний аналіз відхилень, який робиться на рівні системи бюджетування. У даному випадку технологія сховища даних дозволяє використовувати переваги як ERP-системи, так і спеціалізованого програмного продукту.

Проводка проводці ворожнечу

Потреби користувача в обробці даних різного ступеня агрегації висловилися у розвитку ПЗ АСБ з принциповою відмінністю структур збережених і інтерпретованих даних. У класичному бюджетному управлінні, який оперує агрегованими даними, застосовується бюджетна структура, заснована на табличному принципі побудови інформаційних масивів. Такі системи бюджетування за своєю суттю є аналітичними інструментами, призначеними для накопичення і аналізу управлінської інформації, яка представляється у вигляді багатовимірних таблиць. При цьому показники таблиць пов'язані формулами, ніяка фінансова логіка (відмінність дебет / кредит, залишки, обороти по рахунках) не підтримується. Такі системи можна визначити як "АСБ табличного типу" (привласнимо їм умовний код моделі бюджетної інформації "1"). Рішення задач фінансового обліку в таких системах пов'язано з певними труднощами, так як вони не передбачають безпосередньої реєстрації кожної господарської операції. Тому дані про фактичне виконання плану або вводяться вручну в агрегованому вигляді (як сума за певний період за певною бюджетній статті), або необхідні дані витягуються з облікової системи, агрегуються та імпортуються в систему бюджетування автоматизованими способами. Після цього з'являється можливість проведення порівняльного план-фактного аналізу.

У багатьох вітчизняних АСБ, які розроблялися на основі автоматизованих систем бухгалтерського обліку, застосовується бюджетна структура, орієнтована на застосування принципів подвійного запису в фінансових планах рахунків. У переважній більшості випадків це російський план рахунків, хоча вже з'являється досить велике коло користувачів, які використовують спеціально розроблений для цих цілей управлінський план рахунків, в основу якого покладені стандарти МСФЗ. Такі системи можна визначити як "АСБ транзакційного типу" (привласнимо їм умовний код моделі "2"). У таких системах дані відображаються у форматі бюджетів тільки на рівні уявлення. Шар зберігання даних заснований на застосуванні плану рахунків. У системах транзакційного типу найбільш ефективно підтримуються завдання управлінського обліку. Однак для планування діяльності підприємства на досить тривалий період (квартал і більш) транзакційний механізм у ряді випадків непридатний.

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

"АСБ з імітацією фінансової логіки" (привласнимо їм умовний код моделі "3") є програми з табличним зберіганням масиву даних, але підтримують ряд фінансових інтерпретацій на рівні програмного коду. У такого типу програмах дані зберігаються в таблицях, але інтерпретуються системою по-різному: як оборот за період, як залишки на кінець періоду і т. д. При цьому на рівні програмного коду проводиться агрегація даних по правильної фінансової логіці (обороти належать певного періоду, залишки на кінець попереднього бюджетного періоду переходять на початок наступного). Хоча такі системи і дозволяють правильно інтерпретувати фінансові звіти, проблема реєстрації окремих операцій все одно залишається у яких невирішеною.

На відміну від російських систем обліку західні традиційно не використовують систему пар кореспондуючих рахунків, а для реєстрації операцій застосовують прості записи на рахунках, що отримали назву "простих проводок". Такий підхід дозволяє, з одного боку, використовувати переваги табличного представлення даних у вигляді набору однорідних записів на окремому рахунку, а з іншого - реєструвати окремі бюджетні операції з явною фінансової інтерпретацією. Подібні системи бюджетування можна визначити як "АСБ з явною підтримкою фінансової логіки" (привласнимо їм умовний код моделі "4").

Описані вище характеристики структур систем бюджетування вказані в табл. 2.

Найбільший інтерес для користувачів представляє ПО АСБ, в якому реалізовані змішані підходи до зберігання і поданням бюджетних операцій. Так, в АСБ "Інталев 2005" підтримується можливість використання як проводок з парою кореспондуючих рахунків, так і "простих проводок" (без подвійного запису). Це особливо актуально, так як не всі бюджетні дані повинні підтримувати фінансову логіку (наприклад, зміна чисельності персоналу не повинно проводитися із застосуванням двох кореспондуючих рахунків). У АСБ Oracle Financial Analyzer на рівні сховища даних фактична бюджетна інформація міститься в прив'язці до рахунку бюджетного плану рахунків. У той же час для всебічного аналізу бюджетів агреговані показники можуть зберігатися в OLAP-модулі у вигляді багатовимірних таблиць.

А навіщо взагалі вони потрібні?

Роль і місце АСБ в загальній схемі управління досить повно характеризуються функціями, які вона підтримує. Перш за все це повний цикл управління, що включає в себе процеси планування, оперативного контролю, обліку у форматі бюджетів та аналіз бюджетних відхилень. На малюнку наведена функціональна модель повного бюджетного циклу. Під функцією планування в бюджетуванні розуміється процес отримання бюджетної інформації на майбутні періоди, поданою з певним ступенем імовірності. Функція контролю необхідна для відстеження виконання затверджених планів і попередження порушень бюджетної дисципліни на основі даних про передбачувані господарських операціях безпосередньо перед їх здійсненням. Облік традиційно полягає у відстеженні виконання затверджених планів на основі даних про здійснені господарські операції. На стадії аналізу здійснюється порівняння бюджетної інформації та інтерпретація отриманих відхилень (у тому числі аналіз план / план, план / контроль, план / факт).

Виконувати ці функції можуть як окремі модулі бюджетування в рамках інтегрованої КІС, так і спеціалізовані програмні продукти, розроблені спеціально для бюджетування. Однак на практиці АСБ або обмежено підтримує основні етапи, повністю реалізуючи підтримку одного з них, або якісь з етапів бюджетного циклу не підтримуються взагалі. З точки зору функціональної орієнтації АСБ можна виділити системи наступних типів:

· АСБ, орієнтовані на управлінський облік (в основному це ті бюджетні системи, які виросли з російських систем бухгалтерського обліку) ("У");

· План-орієнтовані АСБ, тобто системи, призначені для розробки планів і аналізу виконання планів ("П");

· АСБ, орієнтовані на контроль виконання бюджетів, де завдання бюджетування тісно пов'язані з функціями документообігу, контролем виконання лімітів та обмежень на використання бюджетних коштів ("К");

· АСБ, орієнтовані на проведення багатовимірного OLAP-аналізу бюджетних даних ("А").

Відомості про функціональної спеціалізації для обраних систем наведено в табл. 3.

А тютюнець нарізно ...

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

Найчастіше АСБ співіснують з обліковими системами. У рамках облікової системи ведеться оперативний облік, а АСБ інтегрує дані або первинні, або агреговані. Існує два підходи до інтеграції фактичних даних: або облікова система і АСБ використовують одну базу даних, або проводиться витяг облікової інформації з облікової системи і передача її в АСБ. Для цього використовуються промислові стандарти обміну інформацією, XML і т. д.

У переважній більшості спеціалізовані АСБ призначені для підтримки складання плану, а бюджетні підсистеми в рамках ERP-систем - в основному для аналізу даних. З цієї точки зору вони можуть не протиставлятися одне одному, а використовуватися спільно. На стадії планування, наприклад, використовуються спеціалізовані програмні продукти, на етапі контролю і аналізу це може бути підсистема деякої інтегрованої системи.

Всі АСБ, що є модулями ERP-систем, підтримують розподілений принцип інтеграції з обліковими даними і дозволяють отримувати як деталізовані, так і агреговані дані. У той час як більшість спеціалізованих АСБ західних розробників дозволяють інтегрувати агреговані облікові дані, ряд російських розробок спеціалізованих систем підтримують централізований принцип зберігання бюджетних та облікових даних.

У рішеннях на основі комбінації спеціалізованих систем бюджетування і ERP-модулів зацікавлені перш за все компанії, що мають у своєму портфелі декілька різнорідних бізнесів. Для управлінського обліку і планування в такому холдингу на рівні керуючої компанії єдино можливим рішенням є автоматизована система бюджетного управління (нетранзакційні типу). При цьому відсутність інтерактивного доступу до операційних деталізованим даними тут є швидше перевагою спеціалізованих систем бюджетування, ніж їх недоліком, оскільки керуючої компанії не потрібна інформація про окремі бюджетних операціях, здійснюваних у її дочірніх структурах. У дочірніх підприємствах можуть використовуватися різні ERP-системи, так чи інакше інтегровані з інформаційною системою холдингу.

***

І маленьке резюме наостанок. Ми свідомо не приводили в даній статті показники популярності тих чи інших АСБ, так як дотримуємося думки, що вибір програмного забезпечення повинен бути заснований на тому, якою мірою воно здатне забезпечити ефективне вирішення конкретних завдань певного користувача. Кількість об'єктів впроваджень або проданих ліцензій у цьому випадку не є визначальним фактором.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://klerk.ru/