Фінансово-економічних систем. На закінчення розглянемо схему прийняття рішень за проектами розвитку фінансово-економічних систем

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

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

бізнес-процесу (групи бізнес-процесів). Результатами обстеження є попередня оцінка об'єму проекту і рішення про закупівлю або розробку необхідного програмного забезпечення, при необхідності – модель ФСА. Висновки відповідального виконавця контролюються службою управління витратами, і злагоджене рішення про закупівлю або власну (замовлений) розробку поступає на затвердження Комітету із управління змінами. Після схвалення Комітетом починається виконання проекту розробки або впровадження.

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

Зазначені системи можна розглядати по методу «чорного ящика», тобто оцінювати вимоги відповідної системи до інфраструктури ІТ і достатність останньої з погляду цих вимог.

Інша спрощена схема відноситься до розгляду простих власних (замовлених) розробок в області управлінського обліку. Умовами дії подібної схеми є:

- локальний характер робочого місця, тобто достатність файлового сервісу і електронної пошти для забезпечення потреб в обміні даними;

- відсутність купувальних рішень для цієї категорії бізнес-процесів;

- можливість реалізації проекту силами одного-двох розробників;

- наявність в рамках ІС можливостей супроводу розробленої системи.

Такі системи розглядаються і з погляду достатності інфраструктури ІТ. Узгоджений проект поступає на розгляд служби управління змінами і при необхідності затверджується Комітетом із схвалення змін.

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