Етапи і проблеми впровадження бюджетування в банку
У Договорі необхідно уточнити специфікацію ПО, точно визначити які програмні продукти будуть поставлені розробником. Це дозволить виключити ситуацію, коли необхідна функціональність єдиної системи бюджетування, буде забезпечуватися безліччю програмних продуктів даного розробника, кожен з яких володіє надлишкової або недостатньої функціональністю. Для ліцензій на ПЗ, що поставляється з-за кордону… Читати ще >
Етапи і проблеми впровадження бюджетування в банку (реферат, курсова, диплом, контрольна)
- 1. 1-й етап: вибір автоматизованої системи
- 2. 2-й етап: впровадження «чудо-системи»
- 3. 3-й етап: оцінка результатів впровадження автоматизованого рішення.
Сьогодні термін «бюджет» багато хто розуміє вже не тільки як деталізований план доходів і витрат, але і як ефективний інструмент процесно-орієнтованого планування, управління банківськими зобов’язаннями і активами з урахуванням фінансових ризиків, а також як інструмент підвищення мотивації та узгодженості діяльності бізнес-центрів. Бюджетування з використанням декількох аналітичних вимірів дозволяє сформувати узгоджений і систематизований бюджет на плановий період за статтями, підрозділам, бізнес-напрямків, банківським продуктам та послугам, терміновості фінансових ресурсів, сегментам ринку та ін.
1-й етап: вибір автоматизованої системи
«Прихована» функціональність
Вибір автоматизованої системи зумовлений багатьма чинниками. Це, перш за все — функціональність такої системи, вартість і трудовитрати по впровадженню такої системи. Однак об'єктивно оцінити переваги тієї чи іншої системи дуже складно, тому що, незважаючи на досить агресивну маркетингову компанію багатьох роздавальників, інформативність, пропонованих ними матеріалів не висока.
Можливості адаптації
Сьогодні кожен банк, що пройшов через важкі кризові роки, має власну якщо не довгострокову, то середньострокову стратегію. Впровадження нової автоматизованої системи не означає відмову від напрацьованих методів планування, а передусім скорочення тимчасових і людських витрат на виконання рутинних операцій. Тому автоматизована система бюджетування повинна володіти можливостями її 100%-ої налаштування на прийняту схему планування, а не навпаки. Система повинна дозволяти користувачеві використовувати як вже закладені в систему алгоритми типових розрахунків, так і самому визначати власні.
Тому одним з головних властивостей автоматизованої системи бюджетування є еволюційність її впровадження. Якщо постачальник, не провівши обстеження існуючої в банку схеми фінансового планування, пропонує реалізувати нову бюджетну модель, це перша ознака того, що в майбутньому Ви можете зіткнутися з проблемою розвитку такої системи.
Як правило, при виборі автоматизованої системи фахівець банку, якому доручено таку відповідальну справу, складає таблицю з параметрами існуючих на ринку рішень, зіставляючи потім наявність тих чи інших характеристик. Такі характеристики доцільно розділити на функціональні і технічні. табл.
Функціональні характеристики автоматизованої системи бюджетування.
Використання ієрархічно організованих вимірювань бюджету (Статті, Бізнес-центри, Фінансові інструменти, Продукти і послуги, Терміновість ресурсів, Контрагенти, Сегменти ринку та ін). | Чи є можливість представити вимірювання в табличній і деревоподібній формі, як передбачається актуалізувати елементи вимірювань. Як внесення змін до АБС буде відбиватися на вимірах бюджету. Чи можливо встановити зв’язки між різними вимірами і виключити при плануванні заздалегідь нелогічні перетину вимірювань. | |
Сценарне планування і сценарний аналіз. | Можливість ведення в єдиній базі даних одночасно декількох сценаріїв одного бюджету (оптимістичний, кризовий і т.д.); Можливості використання для сценарного аналізу зовнішніх і внутрішніх обмежувачів бюджету (цільових показників). | |
Контроль несуперечності на етапі введення даних в систему. | Перевірка відповідності даних, що вводяться структурі та зв’язках заданих вимірювань бюджету; Перевірка відповідності даних, що вводяться цільових показників (лімітування статей); Перевірка циклічності розрахунків. | |
Коректність роботи з часовими рядами. | Підтримка різного типу бюджетних статей (оборот, сальдо); Робота з середніми значеннями (курсами, середніми залишками, середніми оборотами і ін); Коректність округлення значень при розподілі за часом. | |
Використання математичних, фінансових та інших функцій. | Можливості проводити розподіл/перерозподіл даних; Наявність логічних умов і операторів для введення формул; Наявність функцій обробки дат, а не тільки цифрових даних; Наявність функцій обробки масивів бюджетних даних, а не тільки однієї бюджетної запису або рядки. | |
Отримання масиву планових даних однією операцією. | Сучасні інформаційні технології дозволяють визначати правила, за якими однією операцією (дією) можна сформувати масив планових даних на основі заданої структури одного з вимірів. Це дозволяє значно скоротити трудовитрати на введення і розрахунок однотипних даних. | |
Можливості визначення курсів валют, бюджетних передумов і цільових показників. | Можливість завдання необхідної кількості валют і обмінних курсів; Наявність в системі типізованих показників (ліміт, норматив та ін) і показників, що визначаються користувачем як цільові або довідкові; Можливість пов’язувати або не пов’язувати показники з вимірюваннями бюджету. | |
Підтримка і контроль регламенту обміну бюджетними даними. | У багатьох системах, включаючи дорогі закордонні, відстеження регламенту і саме поняття регламент взаємодії віддається на відкуп користувача. Це означає, що дана система не має ефективних засобів автоматизації, для того, щоб полегшити і упорядкувати процедури узгодження й затвердження бюджетних даних окремих користувачів і бюджетів підрозділів. | |
Формування комплекту бюджетних звітів. | Наявність типових бюджетних звітів (Balance, P & L, Cash Flow); Можливості динамічної угруповання і деталізації статей у звітах (Drill up, Drill down); Можливості подання звітів у вигляді структурованих крос-таблиць (вимірювання бюджету можуть знаходитися як у рядках, так і в стовпцях); Технологія та швидкість оновлення даних у звітах; Достатність графічних засобів; можливості інтеграції з MS Office та спеціалізованим програмним забезпеченням побудови аналітичних звітів (Business Objects, Crystal Reports та ін.). | |
Засоби контролю виконання бюджету. | Частота, з якою здійснюється контроль виконання бюджету; Математичний апарат для аналізу відхилень. | |
Підтримка процесно-орієнтованого бюджетування (Activity-Based Budgeting). | Наявність можливості закласти в модель бюджету послідовність алгоритмів розподілу/перерозподілу бюджетних даних за видами діяльності, групам банківських продуктів та послуг; Реалізація підходів процесно-орієнтованого бюджетування неможлива без наявності характеристик у пп. |
У таблиці наведені лише необхідні, але недостатні функціональні характеристики, на які слід орієнтуватися при виборі автоматизованої системи. У таку таблицю корисно включити 2−3 абсолютно конкретних алгоритму розрахунків, які використовуються при складанні бюджету в конкретному банку, і перевірити можливість їх реалізації.
Відкритість системи
Важливим при взаємодії облікових автоматизованих систем і системи бюджетування є технологія поновлення бюджетних довідників. Якщо Вам необхідна модель бюджету, яка дозволяла б проводити контроль відхилень і аналізувати фактичні дані, переконайтеся, що дана система бюджетування підтримує синхронне (з обліковими системами) оновлення бюджетних довідників. Повноцінне оновлення припускає хронологічний облік всіх змін, таких як додавання, видалення, об'єднання, дроблення, зміна найменувань для статей, одиниць організаційної структури і т.д.
«Відкритість» системи бюджетування, однак, має певні межі. Система бюджетування — це, перш за все спеціалізований додаток, реалізоване або розробником, або власними силами. Необхідно визначитися, чи збираєтеся Ви купувати інструмент для самостійної розробки автоматизованої системи (наприклад, на основі OLAP-додатки) або готову систему бюджетування з можливістю її гнучкої адаптації до специфіки бюджету банку. Цей вибір багато в чому визначать витрати часу і ступінь участі у впровадженні ІТ-фахівців банку.
Вимоги безпеки
Представлені на ринку системи значно відрізняються за технічними або технологічними характеристиками: від файл-серверних систем до систем з WEB — серверною архітектурою. Однак кожен банк повинен сам визначити необхідний баланс між функціональністю і новизною технічного рішення. Однак автоматизована система повинна відповідати найбільш загальним технічним вимогам (Таблиця), що пред’являються до систем бюджетування.
Технічні характеристики автоматизованої системи бюджетування
Єдина база даних, що забезпечує багатокористувацьку роботу. | Деякі системи, пропоновані для вирішення завдань бюджетування, мають файл-серверну архітектуру, що ускладнює синхронізацію даних і контроль версій бюджету. Рекомендується використання централізованої бази даних на основі повноцінних промислових СУБД (MS SQL Server, Oracle, Informix, DB2). Це дозволяє знизити залежність від конкретного постачальника програмного забезпечення (далі ПЗ), звести до мінімуму не регламентовані помилки, а також більшою мірою задіяти власних фахівців і забезпечити необхідний рівень безпеки бюджетних даних. | |
Інтеграція з суміжними автоматизованими системами. | Можливості системи повинні дозволяти здійснювати повноцінний імпорт/експорт, при необхідності попередню обробку фактичних даних з АБС та інших облікових систем; Бажана підтримка двостороннього зв’язку з наявними обліковими системами, якщо вони дозволяють її здійснювати. Використання стандартних СУБД (MS SQL Server, Oracle, Informix, DB2) також полегшує інтеграцію. | |
Відсутність обмежень по кількості об'єктів (максимальна кількість вимірювань, записів, звітів, число одночасно працюючих користувачів і т.д.). | Будь-які обмеження щодо кількості об'єктів, якими оперує система, говорять про недосконалість технічного рішення такого програмного продукту. Навіть якщо ці обмеження становлять десятки тисяч одиниць і сьогодні здаються прийнятними, це означає, що в майбутньому Ви зіткнетеся з непереборним бар'єром при розвитку бюджетної моделі. | |
Вимоги безпеки. | Зберігання та передача даних повинні здійснюватися в зашифрованому вигляді. Система повинна забезпечувати багатокористувацьку роботу в режимі реального часу. Краща політика ліцензування, коли встановлене робоче місце програмного забезпечення не залежить від конкретної робочої станції користувача. Іншими словами, кількість одночасно працюючих користувачів не повинно обмежуватися кількістю інсталяцій системи. Засоби системи повинні підтримувати резервне копіювання і відновлення даних. | |
Вимоги до технічного забезпечення. | Необхідно перевірити відповідність характеристик власних робочих станцій і сервера бази, даних поставленим вимогам. Можливо, що витрати по оновленню комп’ютерного обладнання будуть порівнянні з вартістю обраної Вами системи. | |
Можливості доопрацювання системи на вимогу Замовника. | Необхідно з’ясувати чи володіє постачальник ПЗ можливостями його доопрацювання на рівні програмного коду. Можливо, постачальник є лише продавцем добре налаштовується коробкового програмного продукту і не зможе здійснити його повноцінну адаптацію до Ваших вимог. |
Прихована вартість
Слід пам’ятати, що купівля ліцензій це ще тільки вершина айсберга. Сукупна вартість складається також із вартості впровадження та технічної підтримки системи. Перед покупкою ліцензій корисно заздалегідь знати чи включає технічна підтримка консультації з реалізованої моделі бюджету або лише оновлення до новий версій та виправлення помилок в старих. У таблиці 3 наведені вартісні параметри, які характерні як для вітчизняних, так і зарубіжних систем.
Структура вартості і термін впровадження автоматизованої системи бюджетування.
Вартість ліцензій. | У Договорі необхідно уточнити специфікацію ПО, точно визначити які програмні продукти будуть поставлені розробником. Це дозволить виключити ситуацію, коли необхідна функціональність єдиної системи бюджетування, буде забезпечуватися безліччю програмних продуктів даного розробника, кожен з яких володіє надлишкової або недостатньої функціональністю. Для ліцензій на ПЗ, що поставляється з-за кордону бажано знати актуальне митне законодавство, а також уточнити хто несе витрати по сплаті митних зборів. | |
Вартість додаткового програмного забезпечення. | Найчастіше базова конфігурація без додаткових модулів не відповідає всім функціональним і технічним вимогам. Краще дізнатися про це до покупки ліцензій на ПЗ. У разі використання в якості бази даних програмного забезпечення сторонніх розробників необхідно уточнити наявність у банку ліцензій на таке ПЗ та оцінити його вартість. | |
Вартість послуг по впровадженню. | Послуги фірми-постачальника, як правило, дешевше, ніж послуги консультантів, наприклад, з першої п’ятірки. |