Microsoft Розвивайте вашу компанію завдяки SMART впровадженню надійної ERP-системи, налаштованої відповідно до потреб вашого бізнесу Dynamics 365 Finance and Operations Applications

1. Обсяг робіт (Scope);
2. Трудовитрати на проєкт (Work);
3. Тривалість проєкту (Duration);
4. Етапність введення системи в експлуатацію (Release plan);
5. Вартість проєкту (Cost);
6. Ліцензійна частина проєкту (Licensing);
7. Якісний та кількісний склад проєктної команди (Team);
8. Припущення та обмеження проєкту (Assumptions & Constraints).

Дії в рамках процесу Оцінки проєкту здійснюються у тісній взаємодії Замовника проєкту та Виконавця робіт і можуть бути описані таким чином:

• Визначити високорівневий обсяг робіт (Define High-Level Scope) – визначити вимоги до функцій ERP-системи на підставі формального або неформального запиту від Замовника. Це завдання може виконуватися ітераційно і зазвичай вимагає формалізації та класифікації вимог. З цією метою застосовується стандартний Класифікатор Бізнес-Процесів (Business Process Classifier);
• Уточнити вимоги (Refine Requirements) – уточнити вимоги Замовника шляхом проведення зустрічей, можливо, демонстрації деяких функцій ERP-системи для розуміння ключових проблем/обмежень/процесів/очікувань та інших атрибутів, які визначають ключові фактори управління проєктом (див. вище). Ця операція застосовується для проєктів малого ступеня складності;
• Виконати проєкт Discovery (Accomplish Discovery Project) – ця операція є, по суті, підпроєктом, який рекомендується здійснити для отримання якісного плану основного проєкту впровадження. Цей підпроєкт не замінює фазу Аналізу в рамках основного проєкту (див. статтю «Методологія впровадження ERP-системи D365FO має значення »), але дозволяє з достатнім ступенем точності розробити оцінку та планування основного проєкту з впровадження ERP-системи середнього та високого ступенів складності. Виконання робіт у рамках Discovery зазвичай займає від 3 до 6 тижнів і є платним. Також можливе фінансування з боку Майкрософт. Ключовими кінцевими результатами підпроєкту Discovery є:
  • Оцінка Обсягу робіт (Project Scope) – процеси/підпроцеси, модулі системи;
  • Релізність постачання (Release Plan) – угруповання Змісту для цілей інкрементного запуску цих процесів в експлуатацію:
    • За процесами;
    • За юридичними особами;
    • За географічними локаціями.
  • Трудовитрати (Work) на кожний Реліз з деталізацією до рівня підпроцесів;
  • Тривалість на кожний реліз (Duration);
  • Вартість на кожний Реліз (Cost);
  • Склад та організаційна структура проєктної команди (і Замовник, і Виконавець) (Project Team);
  • Архітектура Рішення (System Landscape) – схема взаємодії модулів ERP-системи та систем, що становлять загальну архітектуру майбутнього рішення, зокрема потоки даних та методи інтеграції;
  • Аналіз застосовності (Fit&Gap) – відсоток покриття стандартним функціоналом системи вимог Замовника;
  • Ключові ризики проєкту та методи управління ними;
  • Ключові припущення оцінки проєкту;
  • Обмеження проєкту.

• Оцінити проєкт – оцінити трудовитрати, якісний та кількісний склад команди, тривалість проєкту з розбивкою за процесами та етапами проєкту у вигляді файлу оцінки;
• Узгодити оцінку – провести зустрічі для презентації, обговорення та уточнення даних оцінки, щоб переконатися в тому, що всі вимоги, обмеження та очікування враховані та оцінка є зрозумілою Замовнику;
• Розробити/узгодити Комерційну пропозицію – розробити документ, що підсумовує результати попередніх робіт, можливо План проєкту з впровадження ERP-системи, що пропонується, у форматі MS Project, який містить інформацію щодо вартості Проєкту та ERP-системи, а також елементів, з яких ця вартість складається, та принципів її формування. Цей документ є формальною пропозицією і, у разі його прийняття Замовником, є підставою для підготовки, погодження та підписання відповідних Договорів.

Вартість проєкту з впровадження ERP-системи

Сукупна вартість проєкту (TCO – Total Cost of Ownership) визначається для всього життєвого циклу використання системи та складається з таких елементів:

1. Вартість ліцензій на програмний продукт Microsoft Dynamics 365 finance and operations applications;
2. Вартість середовищ (environments), які необхідні для розгортання та роботи програмного продукту, якщо вони є додатковими до тих, що постачаються в рамках ERP-продукту;
3. Вартість додаткових програмних продуктів (наприклад Office 365, зовнішня система аналітики Power BI тощо), якщо їх використання передбачається в рамках бізнес-процесів, що проєктуються, а також додаткових модулів і сервісів (наприклад, пакети локалізації для деяких країн);
4. Вартість проєкту впровадження ERP-системи у рамках тих процесів та їхніх функцій, що знаходяться в рамках проєкту впровадження;
5. Вартість постпроєктного супроводу роботи системи.

• Комплексний проєкт (у межах одного релізу чи кількох релізів), на який можна спланувати обсяг робіт (Scope) на початок проєкту;
• Порелізний проєкт з плануванням обсягу робіт перед початком кожного наступного релізу (субпроєкти).

1. Вартість ліцензій на програмний продукт Microsoft Dynamics 365 finance and operations applications:
   • В екосистемі розрізняються 4 основні програмні продукти, які можуть бути придбані незалежно один від одного + додаткові програмні пакети, що надають ряд специфічних функцій – Microsoft Dynamics 365 Finance, Microsoft Dynamics 365 Supply Chain Management, Microsoft Dynamics 365 Commerce і Microsoft Dynamics 365 Human Resources;
   • Користувачі, що ліцензуються, є іменними та поділяються на 4 типи:
     • Premium;
     • Standard;
     • Operations – Activity;
     • Team Member.

• SCM Premium;
• SCM;
• Operations – Activity;
• Team Member;

2. 2. Вартість середовищ. У стандартному постачанні продукту (out-of-box) вже є 2 середовища, необхідних для налаштування та роботи ERP-системи – sandbox (тестування) та production (експлуатація). Необхідність у додаткових середовищах та оплаті за них залежить від таких факторів:

• Чи потрібна розробка у рамках проєкту. За необхідності будь-якої розробки (кодування) у рамках проєкту необхідні відповідні середовища у кількості, що визначається архітектурою розробки.
• Чи потрібна одночасна експлуатація однотипних середовищ. За порелізного введення ERP-системи в експлуатацію виникає необхідність одночасного використання кількох тестових середовищ або наявності додаткових середовищ для забезпечення процесу безперервного функціонування системи та одночасного її розгортання в рамках релізів.

3. Вартість додаткового програмного забезпечення. Якщо на етапі проєктування ERP-системи було прийнято рішення про необхідність використання додаткового програмного забезпечення для функціонування бізнес-процесів, то виникає необхідність у придбанні відповідних програмних пакетів.

4. Вартість проєкту впровадження ERP-системи. Ця вартість визначається двома показниками:

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

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

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

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

Влад Березін

Business Development Manager, SMART business

Етапи впровадження ERP

1. Старт проєкту
2. Аналіз та моделювання процесів
3. Конфігурування системи
4. Тестування системи
5. Розгортання системи/Підготовка до запуску
6. Введення Системи в експлуатацію/Підтримка

I. Старт проєкту (Project start)

1. План проєкту (Project Baseline). Цей план базується на даних Оцінки проекту (див. статтю «Процес оцінки впровадження ERP-системи», але тут він адаптується під реальні ресурси, їхні календарі та контрактні умови. Затверджений проєктний план є базовим (baseline) для подальшого порівняння фактичних показників проєкту з плановими (роботи, тривалість, вартість, ресурси, трудовитрати, дані розкладу).
2. Організаційна структура проєкту та ролі. Початкове визначення цих даних може бути виконано в рамках передпроєктних активностей (див. статтю «Процес оцінки впровадження 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).

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

III. Конфігурування системи (System Configuration)

• Параметричне налаштування функцій системи (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)

• Навчання користувачів (ключових та кінцевих). Основне навчання ключових користувачів проводиться на етапі тестування, але на етапі «Розгортання системи» може знадобитися додаткове навчання. Навчання кінцевих користувачів здійснюється Ключовими користувачами Замовника. У виняткових випадках можливе залучення спеціалістів Виконавця.
• Підготовка шаблонів міграції даних.
• Міграція даних (зі старої/старих систем і вручну) та перевірка їхньої коректності. Ця робота виконується фахівцями Замовника. Слід також взяти до уваги те, що це завдання може бути пов'язане із значними трудовитратами і займати тривалий час. Некоректність даних є однією з найчастіших проблем під час введення Системи в експлуатацію.
• Налаштування прав доступу до даних системи – виконується спеціалістом Замовника після відповідного навчання.
• Підготовка промислового середовища системи.
• Підготовка плану до введення системи в експлуатацію. Цей план розробляється для покрокового опису дій, спрямованих на введення системи у промислову експлуатацію. Ці дії можуть бути як підготовчі, так і описувати послідовність введення підрозділів/процесів у роботу в системі в прив'язці до календаря.
• Реалізація плану введення системи в експлуатацію.
• Підготовка рольових інструкцій користувача – проводиться спеціалістом Замовника на підставі пройдених Функціональних тестових сценаріїв.

VI. Введення Системи в експлуатацію/Підтримка (Go Live/Support)

• Реалізація Плану щодо введення в експлуатацію.
• Підтримка користувачів.
• Усунення помилок.
• Внесення змін.

Управління змінами (Change Control)

• Ініціація та опис запиту на зміну (Change Request – CR):
  • Опис потреби;
  • Пріоритет.
• Аналіз запиту відповідальним за область спеціалістом:
  • Сутність запиту;
  • Доцільність;
  • Області впливу зміни.
  • Рев'ю Аналізу запиту керівництвом проєкту.
• Оцінка запиту відповідальним за область спеціалістом:
  • Трудовитрати;
  • Вартість;
  • Тривалість.
• Розгляд оцінки ініціатором зміни, членом групи управління проєктом та прийняття рішення:
  • Прийняти;
  • Відхилити;
  • Відкласти.
• Реалізація запиту в разі його схвалення:
  • Внесення в план і коригування Project Baseline;
  • Виконання робіт;
  • Тестування:
    • Внутрішнє;
    • Зовнішнє.
• Демонстрація роботи системи після реалізації зміни;
• Розгортання зміни (Deployment).

• Зміни є однією з найчастіших причин збільшення тривалості та вартості проєкту загалом.
• Складні зміни можуть виконуватися ітераційно.
• Нівелювання вищенаведеної процедури керування змінами може призвести до непередбачуваних наслідків для працездатності системи.
• Кількість змін безпосередньо залежить від якості робіт на етапі «Аналіз та моделювання» та відповідних проєктних документів.
• Трудовитрати, необхідні для реалізації можливих змін, зазвичай неможливо точно спланувати. Для цього в план закладаються резерви.

Підхід до впровадження проєктів ERP на базі Dynamics 365 finance and operations applications, що застосовується в SMART business та базується на методології Microsoft Sure Step (Success by Design), є логічним і комплексним набором процесів, документів і процедур. Дотримання цього підходу в проєктах впровадження є життєво необхідним елементом для успішної реалізації проєкту впровадження ERP-системи будь-якої складності.

Влад Березін

Business Development Manager, SMART business