Проєкти впровадження систем управління організаціями (ERP) є відносно складними в реалізації з погляду технологічних та організаційних ризиків, а також множинних взаємопов’язаних процесів, що підлягають автоматизації. Також часто у процесі реалізації проєкту усталені процеси модифікуються. Підхід до реалізації такого проєкту та його пропрацювання, ретельне дотримання процедур та процесів, закладених у методологію, є критично важливими факторами успіху проєкту.
Схематично проєкт впровадження ERP-системи Microsoft Dynamics 365 finance and operations applications, що застосовується в SMART business, можна представити так:
Етапи впровадження ERP
- Старт проєкту
- Аналіз та моделювання процесів
- Конфігурування системи
- Тестування системи
- Розгортання системи/Підготовка до запуску
- Введення Системи в експлуатацію/Підтримка
Розглянемо детальніше. В рамках проєкту впровадження ERP-системи Microsoft D365FO Apps присутні таки етапи (фази). Залежно від специфіки проєкту ці фази можуть бути суворо послідовними або виконуватися частково паралельно:
I. Старт проєкту (Project start)
Роботи в межах цього етапу виконуються з метою ініціації проєкту та отримання інформації та планів, необхідних для реалізації подальших кроків. Ключовими кінцевими результатами цього етапу є:
- План проєкту (Project Baseline). Цей план базується на даних Оцінки проекту (див. статтю «Процес оцінки впровадження ERP-системи», але тут він адаптується під реальні ресурси, їхні календарі та контрактні умови. Затверджений проєктний план є базовим (baseline) для подальшого порівняння фактичних показників проєкту з плановими (роботи, тривалість, вартість, ресурси, трудовитрати, дані розкладу).
- Організаційна структура проєкту та ролі. Початкове визначення цих даних може бути виконано в рамках передпроєктних активностей (див. статтю «Процес оцінки впровадження ERP-системи»), але тут відбувається остаточне затвердження.
Схема етапу «Старт проєкту» наведена нижче:
II. Аналіз та моделювання процесів (Process modelling and analysis)
В межах цього етапу відбувається:
- Аналіз поточних процесів, архітектури та потоків даних (Модель «Як є» (As Is Model)) у формі проведення інтерв’ю та документування їхніх результатів у вигляді текстового опису та розробки процесних діаграм.
- Збір вимог та обмежень до процесів, потоків даних та форм подання інформації та їх документування у відповідному вигляді.
- Моделювання системи щодо покриття вимог до процесів, потоків даних і форм подання інформації.
- Формалізація вимог до бажаних процесів, потоків даних та форм подання інформації у вигляді документа «Функціональні вимоги» (Functional Requirements Document (FRD)). Цей документ містить діаграми бізнес-процесів (Process Mapping), текстовий опис цих діаграм, а також іншу інформацію.
- Визначення беклогу вимог та відповідних робіт з налаштування системи, пріоритетів вимог та їхньої специфіки у вигляді документа Fit&Gap, де:
- Fits – роботи з конфігурування системи,
- Gaps – роботи з розробки нового функціоналу або розширення наявного.
- Визначення точок інтеграції ERP-системи зі сторонніми продуктами, опису потоків даних та технічних параметрів обміну інформацією.
- Визначення та формалізація загальної архітектури рішення, що показує ERP-систему та її місце у загальній структурі Рішення із зазначенням точок інтеграції та потоків даних у рамках Рішення.
- Узгодження документів FRD та Fit&Gap у рамках Технічного завдання з налаштування системи.
- Уточнення Плану проєкту з можливим його коригуванням на підставі даних Технічного завдання та, за необхідності, зміна та перезатвердження Базового плану проєкту (baseline).
Залежно від підходу до впровадження системи, що застосовується (стандартний або на підставі прототипу), а також складності проєкту, роботи в рамках етапу «Аналіз та моделювання» можуть відрізнятися – як за обсягом та трудовитратами, так і за змістом. Так, документ «Функціональні вимоги» (FRD) не розробляється для простих процесів та проєктів, а також для проєктів, що виконуються за моделлю прототипу, тобто на підставі вже налаштованої перед проєктом функціональності системи. Також для таких проєктів застосовується спрощений та скорочений за обсягом варіант аналізу поточних процесів Замовника. Таким чином, обсяг робіт, трудовитрати, вартість та тривалість у рамках етапу «Аналіз та моделювання» безпосередньо залежать від:
- типу впровадження (стандартний підхід або на підставі прототипу);
- складності конкретного бізнес-процесу;
- складності проєкту загалом;
- кількості та специфіки вимог до системи;
- кількості та специфіки точок інтеграції;
- інших факторів.
Схема етапу «Аналіз та моделювання процесів» наведена нижче:
III. Конфігурування системи (System Configuration)
В межах цього етапу впровадження ERP проводяться:
- Параметричне налаштування функцій системи (Perform Setups (Fits)).
- Доопрацювання функцій системи (Perform Development (Gaps)) – додавання/зміна функцій, полів, фільтрів, розробка звітів, первинних форм тощо вбудованими засобами системи:
- підготовка специфікацій на розробку;
- розробка;
- тестування.
- Конфігурування джерел даних, робочих процесів, параметрів даних, звітів вбудованими засобами системи (Configuration).
- Демонстрації прототипу системи з вибраних процесів.
- Обговорення та затвердження ключових специфікацій на розробку.
- Підготовка тестових сценаріїв:
- функціональні тестові сценарії;
- інтеграційні тестові сценарії.
- Внутрішнє тестування системи (Internal Functional Testing) – система тестується ресурсами проєктної команди.
Схема етапу «Конфігурування» наведена нижче:
IV. Тестування системи (System Testing)
В межах цього етапу проводиться цілісне тестування системи в рамках:
- окремих процесів, інтеграцій або груп процесів (Функціональне тестування – Functional Testing) – User Acceptance Testing:
- підготовка тестових даних;
- демонстрація роботи системи в рамках сценаріїв, що тестуються, та навчання ключових користувачів;
- система тестується ключовими користувачами за підтримки проєктної команди;
- коригування системи та відповідних тестових сценаріїв.
- системи в цілому (Інтеграційне тестування – End-to-End Testing):
- внутрішнє інтеграційне тестування (Internal Integrational Testing) – система;
- зовнішнє інтеграційне тестування (External Integrational Testing) – тестування системи ключовими користувачами за підтримки проєктної команди;
- коригування системи та відповідних тестових сценаріїв.
- Навантажувальне тестування – застосовується лише за наявності великої кількості операцій та/або користувачів.
Схема етапу «Тестування системи» наведена нижче:
V. Розгортання системи/Підготовка до запуску (System Deployment)
На цьому етапі впровадження ERP система готується до запуску у промислову експлуатацію:
- Навчання користувачів (ключових та кінцевих). Основне навчання ключових користувачів проводиться на етапі тестування, але на етапі «Розгортання системи» може знадобитися додаткове навчання. Навчання кінцевих користувачів здійснюється Ключовими користувачами Замовника. У виняткових випадках можливе залучення спеціалістів Виконавця.
- Підготовка шаблонів міграції даних.
- Міграція даних (зі старої/старих систем і вручну) та перевірка їхньої коректності. Ця робота виконується фахівцями Замовника. Слід також взяти до уваги те, що це завдання може бути пов’язане із значними трудовитратами і займати тривалий час. Некоректність даних є однією з найчастіших проблем під час введення Системи в експлуатацію.
- Налаштування прав доступу до даних системи – виконується спеціалістом Замовника після відповідного навчання.
- Підготовка промислового середовища системи.
- Підготовка плану до введення системи в експлуатацію. Цей план розробляється для покрокового опису дій, спрямованих на введення системи у промислову експлуатацію. Ці дії можуть бути як підготовчі, так і описувати послідовність введення підрозділів/процесів у роботу в системі в прив’язці до календаря.
- Реалізація плану введення системи в експлуатацію.
- Підготовка рольових інструкцій користувача – проводиться спеціалістом Замовника на підставі пройдених Функціональних тестових сценаріїв.
Схема етапу «Розгортання системи» наведена нижче:
VI. Введення Системи в експлуатацію/Підтримка (Go Live/Support)
Цей етап є завершальним для проєкту/релізу проєкту і передбачає дії, спрямовані на запуск системи в експлуатацію згідно з Планом введення в експлуатацію, підтримку користувачів у рамках їхньої операційної роботи в системі, усунення помилок та внесення змін. Цей етап обмежений за часом, який залежить від контрактних умов. Роботи, які виконуються в рамках цього етапу:
- Реалізація Плану щодо введення в експлуатацію.
- Підтримка користувачів.
- Усунення помилок.
- Внесення змін.
Після закінчення цього етапу впровадження ERP проєкт/реліз вважається завершеним, і система переходить у режим постпроєктної підтримки.
Схема етапу «Введення системи в експлуатацію» наведена нижче:
Управління змінами (Change Control)
Управління змінами – це набір підходів, документів та процедур, спрямованих на кероване внесення змін до системи та проєктного плану. Змінами вважаються будь-які коригування в узгоджених проєктних документах (FRD, F&G, Architecture, Points of Integrations, Project Baseline, всі види тестових сценаріїв, шаблону імпорту даних тощо). Процедура управління змінами містить такі кроки:
- Ініціація та опис запиту на зміну (Change Request – CR):
- Опис потреби;
- Пріоритет.
- Аналіз запиту відповідальним за область спеціалістом:
- Сутність запиту;
- Доцільність;
- Області впливу зміни.
- Рев’ю Аналізу запиту керівництвом проєкту.
- Оцінка запиту відповідальним за область спеціалістом:
- Трудовитрати;
- Вартість;
- Тривалість.
- Розгляд оцінки ініціатором зміни, членом групи управління проєктом та прийняття рішення:
- Прийняти;
- Відхилити;
- Відкласти.
- Реалізація запиту в разі його схвалення:
- Внесення в план і коригування Project Baseline;
- Виконання робіт;
- Тестування:
- Внутрішнє;
- Зовнішнє.
- Демонстрація роботи системи після реалізації зміни;
- Розгортання зміни (Deployment).
Необхідно взяти до уваги наступне:
- Зміни є однією з найчастіших причин збільшення тривалості та вартості проєкту загалом.
- Складні зміни можуть виконуватися ітераційно.
- Нівелювання вищенаведеної процедури керування змінами може призвести до непередбачуваних наслідків для працездатності системи.
- Кількість змін безпосередньо залежить від якості робіт на етапі «Аналіз та моделювання» та відповідних проєктних документів.
- Трудовитрати, необхідні для реалізації можливих змін, зазвичай неможливо точно спланувати. Для цього в план закладаються резерви.
Схема процесу «Управління змінами» наведена нижче:
Підхід до впровадження проєктів ERP на базі Dynamics 365 finance and operations applications, що застосовується в SMART business та базується на методології Microsoft Sure Step (Success by Design), є логічним і комплексним набором процесів, документів і процедур. Дотримання цього підходу в проєктах впровадження є життєво необхідним елементом для успішної реалізації проєкту впровадження ERP-системи будь-якої складності.
20+ років у сфері управління бізнесом, проєктами та продажами. Президент Project Management Institute (PMI), Kyiv Chapter з 2007 до 2012 року. Практичний досвід реалізації проєктів із планування корпоративних ресурсів (ERP), людських ресурсів (HR), маркетингу, організацій, EPM, PPM, BPMS та бізнес-процесів (BP).
