Тема 10. Класифікація проектів інформатизації

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

Разом з тим, розглядаючи проблеми управління проектами інформатизації, саме ця класифікація не завжди відображає їх особливості і специфіку управління ними.

До основних особливостей проектів інформатизації можна віднести:

- інтелектуалоємкий характер предметної області більшості проектів;

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

- мала частка господарської діяльності, пов'язаної з матеріальними активами;

- високий ступінь залежності від зовнішніх умов, насамперед, поведінки замовника;

- підвищені ризики, включаючи ризики порушення термінів і бюджету, припинення або призупинення проекту, невдалого впровадження результатів;

- підвищені вимоги до якості, що мають об'єктивно-конструктивний характер, тобто такий, що можна перевірити;

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

- висока ймовірність появи нових, раніше не виконуваних робіт, для яких технологія й система управління створюються "на ходу";

- критична важливість офісної системи, що підтримує комунікації й базу знань;

- наявність суттєвих особливостей планування, контролю й обліку;

- нерівномірність надходження замовлень, що утрудняє управління ресурсами;

- досить часто географічна віддаленість клієнта;

- наявність кількох виконавців та їх географічна розподіленість.

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

Варто зазначити, що Українська асоціація управління проектами так класифікує проектизатипом: інвестиційний, дослідний, організаційний, інформаційних технологійі зазначає, що проекти можуть класифікуватись і за іншими критеріями (внутрішніми й зовнішніми) [30]. Тобто проекти, пов’язані з інформаційними технологіями (проекти інформатизації) виділено як окремий тип, що відповідає сучасним тенденціям у проектному менеджменті.

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

Здійснюючи таку класифікацію слід пам’ятати, що проекти інформатизації:

- можуть відноситись до різних професійних сфер діяльності (фінансова, юридична, маркетингова та ін.);

- мають різну складність задач, що розв’язуються;

- мають різний масштаб з точки зору ресурсів, що залучаються.

На основі розглянутих (та інших) реальних особливостей можна скласти узагальнену класифікацію проектів інформатизації (див. табл. 10.1)

Таблиця 10. 1. Узагальнена класифікація проектів інформатизації

Кожний конкретний проект може мати кілька класифікаційних ознак.

На особливу увагу заслуговують проекти рівня підприємства, оскільки саме вони складають більшу частину проектів, пов’язаних з інформатизацією. У таблиці 1 наведено класифікацію таких проектів за різними ознаками.

Таблиця 1. Класифікація проектів інформатизації рівня підприємства

За ознакою впливу на сервіси інформаційних технологій (ІТ) проекти інформатизації рівня підприємства можна розділити на дві групи [15]:

1. Бізнес-проекти. До них відносять проекти метою яких є створення нових сервісів ІТ для бізнес-підрозділів.

2. Інфраструктурні проекти. Це проекти, які не впливають на склад ІТ-сервісів для бізнес-підрозділів.

Проекти кожної з цих груп також можна класифікувати за різними ознаками. Так, за ознакою ступеня впливу проекту на основні бізнес-процеси підприємства виділяють такі класи бізнес-проектів інформатизації рівня підприємства:

- проекти розвитку систем АСУ ТП[1]і контрольно-вимірювального обладнання – системи, що забезпечують збір даних з технологічних установок і управління останніми. Вони є частиною технологічного ланцюжка основних бізнес-процесів;

- проекти розвитку предметної області – системи автоматизують окремі операції основних бізнес-процесів, реалізують складні математичні алгоритми і вимагають великих обчислювальних потужностей. Прикладом таких систем є системи:

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

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

- технічного аналізу і прогнозування біржових котирувань цінних паперів;

- комп’ютерної графіки;

- біржової торгівлі та ін.

- проекти розвитку фінансово-економічних систем – системи автоматизують, як правило, забезпечуючі бізнес-процеси. Виключенням є системи MRP II / ERP, які автоматизують крім того і планування операцій основних бізнес-процесів. Прикладом таких систем є :

ü системи MRP II / ERP;

ü системи бюджетування і контролю виконання бюджету;

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

ü системи розрахунків з постачальниками/покупцями і контролю заборгованості;

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

ü проекти електронного бізнесу тощо.

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

Інфраструктурні проектитакож можна поділити за ознакою ступеня впливу на основні бізнес-процеси підприємства на такі класи [15]:

- проекти підтримки. Проекти розвитку ІТ-інфраструктури з метою підтримки декількох бізнес-проектів;

- проекти розширення. Проекти розвитку ІТ-інфраструктури з метою впровадження на підприємстві існуючих бізнес-сервісів (ІТ-сервісів для бізнес-підрозділів);

- проекти розв’язання проблем.Проекти, що адаптують ІТ-інфраструктуру підприємства до обставин, які не передбачені регулярним плануванням і викликані необхідністю розвитку ІТ- інфраструктури;

- проекти розвитку інформаційної служби. Проекти розвитку ІТ- інфраструктури, націлені на підвищення ефективності діяльності самої інформаційної служби з розробки сервісів, їх супроводу та управління ними.

Кожний з наведених класів та видів проектів має свої особливості та відрізняється механізмом ініціювання та прийняття рішення щодо його доцільності.

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

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

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

Рисунок 1 – Схема прийняття рішення щодо проекту розвитку АСУ ТП

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

Проекти розвитку предметної області дуже різноманітні, що видно з наведених вище прикладів систем такого виду. Разом з тим вони мають цілу низку загальних властивостей, що відрізняють їх від проектів інших видів. До числа таких особливостей належать:

· жорсткі вимоги до апаратних і програмних засобів, які повинні бути виконані за принципом "усе або нічого";

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

· високий ступінь спеціалізації апаратного й програмного забезпечення.

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

Рисунок 2 – Схема прийняття рішення щодо систем предметної області

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

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

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

Навпаки, фінансово-економічні системи тривалий час розроблялися самими підприємствами-користувачами. Винятком були лише бухгалтерські системи, серед яких уже з кінця 1970-х років домінували покупні рішення. Разом з тим в 1990-і роки мало місце значне зростання частки промислово виготовлених фінансово-економічних систем. Саме цей процес вивів компанію SAP на одне з перших місць у галузі програмування й дав життя цілому ряду конкуруючих з нею виробників.

Таким чином, в останнє десятиліття XX століття, по-перше, виникла необхідність масової заміни успадкованих систем, по-друге, значно зблизилися моделі бізнес-процесів на різних підприємствах і навіть у різних країнах, а по-третє, розвиток технологій баз даних і розподілених систем забезпечило можливість розробки систем, придатних для широкого кола підприємств, за прийнятні строки й при розумних обсягах витрат. Як наслідок, один раз витрачені кошти на розробку розподілялися на значно більшу кількість систем, а можливості настроювання й програмування останніх виявилися достатніми для урахування специфіки бізнес-процесів того або іншого підприємства. Це й послужило основною причиною стрімкого витиснення власних розробок на західних ринках Фінансово-економічних систем.

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

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

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

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

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

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

· вартості одного екземпляра системи за рахунок тиражування;

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

· ризиків втрати супроводу системи у зв'язку, наприклад, зі звільненням групи розробників.

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

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

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

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

Рисунок 3 – Прийняття рішення з розробки фінансово-економічної системи

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

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

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

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

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

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

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

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

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

На закінчення розглянемо схему прийняття рішень у проекті впровадження систем класу MRP II/ERP (рис. 4).

Рисунок 4 – Бізнес-процеси моделі MRP II

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

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

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

2. Робоча група оцінює масштаб проекту, беручи до уваги наступні критерії:

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

— можливість рішення поставлених завдань у розумний термін (як показує практика, якщо строк реалізації пілотного проекту перевищує один рік, то різко знижується ймовірність досягнення успіху);

— ув'язування бізнес-завдань із пропускною спроможністю ІТ-інфраструктури.

Два перших пункти вже були розглянуті вище, тому зосередимося на останньому. Системи класу ERP надзвичайно вимогливі до пропускної здатності ІТ-інфраструктури. З одного боку, промислові СКБД, на яких побудовані такі системи, висувають високі вимоги до інфраструктури зберігання даних. З іншого боку. інтеграція всіх робочих місць подібної системи з доступом до єдиної бази даних висуває високі вимоги до корпоративної інформаційної мережі. Як наслідок, у рамках інформаційної служби повинен бути створений окремий проект по розвитку ІТ-інфраструктури відповідно до вимог ERP-системи. На розглянутому етапі мова йде про оцінку вартості й часу створення (Наприклад, середній строк виконання замовлення на серверне обладнання - вісім тижнів, що становить від 1/6 до 1/3 загального часу проекту впровадження ERP-системи.) такої інфраструктури при різних варіантах обсягу проекту. В інформаційній службі на даній стадії задіяні служби планування сервісів, управління пропускною спроможністю й управління витратами. На цьому ж етапі проводиться економічна оцінка проекту й формуються вимоги до рішення, що забезпечують досягнення запланованого ефекту.

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

4. Після вибору системи й консультанта формуються спільна проектна команда й керівні органи проекту. На даному етапі принципові наступні моменти:

—запуск проекту за наказом керівника підприємства;

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

—запуск проекту забезпечення інфраструктури ERP- системи у рамках інформаційної служби.

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

5. Виконання проекту.

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

[1] АСУ ТП - автоматизовані системи управління технологічними процесами

• ⇐ Назад
• 1
• 2
• 3
• 4
• 56