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

Великі постачальники програмного забезпечення класу ERP такі як SAP і Огаc1е, а також ведучі фірми-консультанти розробили стандартні методики впровадження систем даного класу. Ціль кожної з таких методик — зниження витрат на проект і пов'язаних з ним ризиків на основі попереднього досвіду впровадження аналогічних систем. Це досягається за рахунок наявності:

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

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

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

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

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

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

Як приклад розглянемо методику ASАР фірми SAP АG по впровадженню системи R/3. За основу опису візьмемо маршрутну карту даної методики.

Етап 1. Підготовка проекту. На цьому етапі формуються стандарти проекту, керівні органи проекту і проектна команда. Вихідний пункт — прийняття керівництвом підприємства рішення про впровадження системи SАР R/3 і підписання пакета договорів з постачальником програмного забезпечення і консультантом по проекту впровадження. Готуються такі проектні документи:

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

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

- узагальнений план проекту - сформований па підставі маршрутної карти ASАР перелік заходів проекту з вказанням термінів виконання робіт і відповідальних осіб. Даний план підлягає уточненню на подальших стадіях проекту;

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

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

- стандарти всіх основних видів діяльності проекту (документація, тестування, управління системою, безпека і т.д);

- стандарти обліку витрат проекту, які пов’язують кроки плану проекту з певними сервісами (детально ця методика описана нище);

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

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

Окремо стоїть проблема організації системного ландшафту. Методика ASАР вимагає як мінімум трьох незалежних одна від одної копій системи R/3 — для розробки, для тестування, для промислової експлуатації (у термінал компанії SAP — продуктивної аксплуатації). Ці копії називаються середовищем розробки, середовищем тестувань і продуктивним середовищем відповідно. Копії повинні бути цілком ізольовані одна від одної, фірма SAP рекомендує розміщати їх на різних серверах. Перенесення даних між копіями повинно бути строго регламентоване, в іншому випадку недостатньо протестовані дані із середовища чи розробки середовища тестування можуть потрапити в продуктивне середовище і призвести до збоїв у роботі діючих сервісів ІТ. Таким чином, технічні ризики проекту багато в чому залежать від того, наскільки вірно спроектований системний ландшафт.

Безпосередній ризик зупинки проекту на цій фазі дуже невеликий. Однак саме на ній можуть бути закладені чи виключені основні фактори даного ризику. До них відносяться:

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

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

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

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

- зупинки проекту при виникненні проблем істотно зростає;

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

Етап 2. Концептуальне проектування. До задач даного етапу відносяться розробка і затвердження моделі бізнес-процесів, реалізованої в проекті. Модель повинна враховувати як вимоги кінцевих користувачів, так і можливості самої системи, унаслідок чого неминуче являє собою компроміс. Вихідний пункт — наказ керівника підприємства про ведення робіт із проекту. Кінцевий пункт — затвердження концептуального проекту Керуючою радою.

Основні проектні документи, які готуються на даному етапі, це:

- концептуальний проект системи;

- вибудовані в системі прототипи бізнес-процесів;

- уточнений обсяг проекту;

- уточнений план проекту.

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

Компромісний характер концептуального проекту висуває високі вимоги до процедури його узгодження і затвердження. Ключовий момент - прихильність керівників усіх рівнів принципу: потреби користувача є не що інше, як цільові бізнес-процеси, затверджені в складі концептуального проекту. Останній стає, таким чином, базою процедур управління змінами. Друга проблема концептуального проектування — зведення до мінімуму користувацьких розробок. У главі 2 було показано, що в зворотному випадку готове рішення буде включати високу ціну промислової системи і високу вартість і ризики експлуатації, які притаманні власним розробкам. Даний етап завершується затвердженням концептуального проекту Керуючою радою. З етапом концептуального проектування пов'язані ризики:

- ризик відсутності затвердженого концептуального проекту (основний ризик даного етапу);

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

- ризик зайвого обсягу користувальницьких розробок у системі;

- ризик зупинки проекту, наприклад у зв'язку з відсутністю концептуального проекту в запланований термін.

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

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

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

Для етапу розробки характерні такі основні ризики:

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

- ризики зупинки проекту у зв’язку з невиконанням у заплановані терміни. Фаза реалізації вимагає узгодження багатьох напрямків діяльності - налаштування і програмування, адміністрування та інших системних робіт, підготовки довідників, тестування і т.д. Відповідно, при недостатній підготовленості менеджера проекту і проектної групи в цілому терміни робіт можуть бути не виконані.

Етап 4. Заключна підготовка. На даному етапі налаштована і протестована система переноситься в продуктивне середовище. Далі виробляється тестування стійкості системи при штатних і позаштатних ситуаціях. Працездатність системи при великому навантаженні в штатному режимі роботи перевіряється об'єм-тестом, працездатність в позаштатних ситуаціях — стрес-тестом.

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

На цьому же етапі проводяться розробка користувацької документації і навчання кінцевих користувачів роботі в системі. Паралельно на підставі робочих матеріалів проектної групи готуються технічний опис і технічні інструкції, необхідні для супроводження системи на етапі експлуатації. Вихідний пункт даного етапу - затвердження Керуючою радою протоколу інтегрального тісту; кінцевий пункт - видання наказу про початок промислової експлуатації системи R/3. Після цього починається етап 5 - промислова експлуатація системи.

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

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

На етапі підготовки проекту в ході оцінки його обсягу готується економічне обґрунтування проекту. У рамках цієї роботи оцінюються грошові потоки, пов'язані з упровадженням системи (див. глави 1, 2). Також будується дерево сценаріїв (рис. 3.2.), які пов’язують ймовірність відмови від проекту з дотриманням вимог методології на різних етапах.

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

3.2.1. Резюме

Сучасні методики ведення проектів впровадження інформаційних систем пропонують дієві способи управління витратами і ризиками в ході ІТ - проекту..Основний інструмент таких методик – “маршрутна карта”- докладний і максимально повний перелік передбачуваних робіт. Планування впровадження на основі маршрутної карти полягає у виключенні непотрібних у ньому робіт і внесенні в карту даних про обсяг проекту. Основних етапів проекту чотири. Перший етап - підготовка - забезпечує створення плану проекту, його стандартів і структури, необхідних для успішного виконання наступних кроків. Другий етап — концептуальне проектування — припускає розробку цільової моделі бізнес-процесів, тобто концептуального проекту. На третьому етапі - етапі реалізації – здійснюється налаштування цільових бізнес-процесів в інформаційній системі відповідно до концептуального проекту. Етап завершується інтегральним тестом зроблених налаштувань. На четвертому етапі, у ході заключної підготовки, забезпечується передача системи в промислову (продуктивну) експлуатацію. Для цього підготовляється документація, навчаються кінцеві користувачі, проводяться об'єм-тест і стрес-тест системи. Четвертий етап завершується передачею системи в промислову експлуатацію. Контроль ризиків забезпечується складанням дерева сценаріїв і контролем положення проекту на цьому дереві.

3.2.2. контрольні запитання

1. Розкрийте поняття маршрутної карти проекта. Як використовується маршрутна карта в плануванні ІТ-проекта і управління ним?

2. Опишіть етап підготовки проекту. Які стандарти проекту, проектна документація, організаційна структура, системний ландшафт проекту? Назвіть основні ризики на даному етапі.

3- Опишіть етап концептуального проектування. Розкажіть про концептуальний проект, налаштування прототипу в системі. Які основні ризики на даному етапі?

4. Опишіть етап реалізації. Розкажіть про цикли розробки, локальне та інтегральне тестування. Перелічіть основні ризики на даному етапі.

5. Опишіть етап заключної підготовки. Розкажіть про об’єм- тсст, стрес-тест, інші роботи. Як завершується даний етап?

6. Як використовується дерево сценаріїв для управління ризиками ІТ-проекту?