Реферати

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

Сутність ринку. Розвиток ринкових відносин у Росії. "Сутність ринку. Розвиток ринкових відносин у Росії" Зміст Зміст 2 Уведення 2 I. ПОНЯТТЯ РИНКУ 6 II. ХАРАКТЕРИСТИКА РИНКУ РОСІЇ НА 2000-2010 рр 18

Кафе з російською кухнею на 100 місць в Одинцово Московської області. Відомість дипломного проекту Найменування Формат аркушів Кількість аркушів Пояснювальна записка Генеральний план, розріз будинку, фасад будинку і будівельні деталі

Фредерик Шопен. Біографія Ф. Шопена. Його приватне життя.

Монголо-татарське ярмо. Версія математиків А. Фоменко і Г. Носовского. Ключ до розгадки російської історії. Версія істориків Д. Калюжного і С. Валянского.

Основні поняття предмета Мови програмування. Міністерство науки й утворення Кафедра "Иивт" ПОЯСНЮВАЛЬНА ЗАПИСКА До курсової роботи Організація і методика виробничого навчання по предметі: "Мови програмування"

Олександр Оглядів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№п/п

Програмний продукт

Принцип побудови ПО

1

Інтальов: Корпоративні фінанси 2004

М

2

Інтальов 2005 v. 8.0

М

3

BusinessBuilder PlanDesigner

м

4

ERA:Budgeting (Active Planner)

м/з

5

Oracle Financial Analyzer

м/з

6

Hyperion Pillar

з

7

Adaytum e.Planning

з

8

Comshare MPC

з

9

КИЦЬ: Бюджетірованіє. МІТ

з

10

Фінансовий органайзер Червоний Директор

з

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

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

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

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

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

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

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

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

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

№п/п

Програмний продукт

Моделі бюджетної інформація

1

Інтальов: Корпоративні фінанси

2

2

Інтальов 2005 v. 8.0

2

3

BusinessBuilder PlanDesigner

1

4

ERA:Budgeting (Active Planner)

4

5

Oracle Financial Analyzer

4

6

Hyperion Pillar

3

7

Adaytum e.Planning

1

8

Comshare MPC

3

9

КИЦЬ: Бюджетірованіє. МІТ

1

10

Фінансовий органайзер Червоний Директор

1

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

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

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

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

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

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

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

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

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

№п/п

Програмний продукт

Функціональна спеціалізація

1

Інтальов: Корпоративні фінанси 2004

У

2

Інтальов 2005 v. 8.0

ДО, У

3

BusinessBuilder PlanDesigner

П, А

4

ERA:Budgeting (Active Planner)

П

5

Oracle Financial Analyzer

П, А

6

Hyperion Pillar

А

7

Adaytum e.Planning

П

8

Comshare MPC

П, А

9

10

КИЦЬ: Бюджетірованіє. NET Фінансовий органайзер Червоний Директор

ПП

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

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

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

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

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

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

***

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