Microsoft Rozwijaj swoją firmę dzięki SMART wdrożeniu niezawodnego systemu ERP dostosowanego do potrzeb Twojego biznesu Dynamics 365 Finance and Operations Applications

1. Zakres (Scope)
2. Koszt pracy (Work);
3. Czas trwania projektu (Duration);
4. Etap uruchomienia systemu (Release plan)
5. Koszt projektu (Cost);
6. Licencjonowanie;
7. Skład zespołu projektowego (Team);
8. Założenia i ograniczenia (Assumptions & Constraints).

Proces wyceny projektu realizowany w ścisłej współpracy Zamawiającego z Wykonawcą można opisać w następujący sposób:

• Określenie ogólnego zakresu prac (Define High-Level Scope) – określenie wymagań dotyczących funkcji systemu ERP na podstawie formalnego lub nieformalnego zlecenia Zamawiającego. Zadanie to może być wykonywane iteracyjnie i zazwyczaj wymaga formalizacji i klasyfikacji wymagań. W tym celu wykorzystywany jest standardowy klasyfikator procesów biznesowych;
• Doprecyzowanie wymagań (Refine Requirements) – doprecyzowanie wymagań klienta poprzez zorganizowanie spotkań, ewentualnie demonstrację niektórych funkcji systemu w celu zrozumienia kluczowych kwestii/ograniczeń/procesów/oczekiwań i innych atrybutów, które wpływają na kluczowe czynniki zarządzania projektem (patrz wyżej). Ta operacja jest stosowana w projektach o niskim stopniu złożoności.
• Realizacja projektu Discovery (Accomplish Discovery Project) – ta operacja jest de facto podprojektem, który zaleca się przeprowadzić w celu uzyskania jakościowego planu głównego projektu wdrożenia. Ten podprojekt nie zastępuje fazy analizy głównego projektu (patrz artykuł "Metodyka wdrożenia systemu ERP D365FO ma znaczenie"), ale pozwala dość dokładnie ocenić i zaplanować główny projekt wdrożenia systemu ERP o średnim lub wysokim stopniu złożoności. Wykonanie prac w ramach Discovery zwykle trwa od 3 do 6 tygodni i jest płatne; możliwe jest również dofinansowanie ze strony Microsoftu. Kluczowymi wynikami podprojektu Discovery są:
  • Zakres projektu (Project Scope) – procesy/podprocesy, moduły systemu ERP;
  • Plan wydania (Release Plan) – grupowanie Treści w celu stopniowego uruchamiania tych procesów:
    • Wg procesów;
    • Według podmiotów prawnych;
    • Według lokalizacji geograficznej.
  • Koszt pracy (Work) związany z każdym Wydaniem zawierający szczegóły aż do poziomu podprocesu;
  • Czas trwania każdego wydania (Duration);
  • Koszt każdego wydania (Cost);
  • Skład i struktura organizacyjna zespołu projektowego (zarówno Zamawiającego, jak i Wykonawcy) (Project Team);
  • Architektura systemu (System Landscape) – diagram interakcji modułów systemu i systemów, które składają się na ogólną architekturę przyszłego rozwiązania, w tym przepływy danych i metody integracji;
  • Analiza dopasowania (Fit&Gap) – procent pokrycia wymagań Zamawiającego standardową funkcjonalnością systemu;
  • Kluczowe ryzyka projektu i metody zarządzania nimi;
  • Kluczowe założenia kosztorysu projektu;
  • Ograniczenia projektu.

• Szacowanie kosztów projektu (Estimate Project) – szacowanie kosztów pracy, składu zespołu, czasu trwania projektu z podziałem na procesy i etapy projektu w formie kosztorysu;
• Uzgadnianie kosztorysu (Negotiate Estimation) – przeprowadzenie spotkań w celu przedstawienia, omówienia i wyjaśnienia danych dotyczących kosztorysu, aby upewnić się, że wszystkie wymagania, ograniczenia i oczekiwania zostały uwzględnione, a kosztorys jest jasny dla klienta;
• Opracowanie/ uzgadnianie warunków Oferty handlowej (Create/Negotiate Commercial Proposal) – opracowanie dokumentu podsumowującego wyniki poprzednich działań, ewentualnie proponowanego Planu projektu w formacie MS Project, który zawiera informacje na temat kosztu Projektu i Systemu, a także elementów składających się na ten koszt i zasad jego tworzenia. Dokument ten stanowi formalną ofertę i, jeśli zostanie zaakceptowany przez Klienta, jest podstawą do przygotowania, negocjacji i podpisania stosownych Umów.

Koszt projektu

Całkowity koszt projektu (TCO – Total Cost of Ownership) jest określany dla całego cyklu życia systemu i składa się z następujących elementów:

1. Koszt licencji na oprogramowanie Microsoft Dynamics 365 finance and operations applications;
2. Koszt środowisk (environments) wymaganych do wdrożenia i eksploatacji oprogramowania, jeśli są to środowiska dodatkowe;
3. Koszt dodatkowego oprogramowania (np. Office 365, external Power BI itp.), jeśli ma ono być wykorzystywane w ramach projektowanych procesów biznesowych, a także dodatkowych modułów i usług (np. pakietów lokalizacyjnych dla niektórych krajów);
4. Koszt projektu wdrożenia systemu ERP w ramach procesów i ich funkcji, które są częścią projektu wdrożeniowego;
5. Koszt wsparcia powdrożeniowego systemu.

• Projekt kompleksowy (w ramach jednego lub kilku wydań), dla którego można zaplanować zakres prac (Scope) na początku projektu;
• Projekt porozwojowy z planowaniem zakresu prac przed każdym kolejnym wydaniem (podprojekty).

1. Koszt licencji na oprogramowanie Microsoft Dynamics 365 finance and operations applications:
   • W ekosystemie znajdują się 4 główne produkty programowe, które można zainstalować niezależnie od siebie, a także dodatkowe pakiety oprogramowania oferujące szereg specyficznych funkcji – Microsoft Dynamics 365 Finance, Microsoft Dynamics 365 Supply Chain Management, Microsoft Dynamics 365 Commerce і Microsoft Dynamics 365 Human Resources;
   • Użytkownicy, którzy posiadają licencję, mają określoną nazwę i dzielą się na 4 typy:
     • Premium;
     • Operations – Activity;
     • Standard;
     • Team Member.

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

2. Koszt środowisk. Standardowa wersja produktu (out-of-box) zawiera już 2 środowiska niezbędne do konfiguracji i eksploatacji systemu – sandbox (testowe) i production (produkcyjne). Konieczność dostarczenia dodatkowych środowisk i opłata za nie zależy od następujących czynników:

• Czy w ramach projektu wymagany jest rozwój. Jeśli w ramach projektu wymagany jest rozwój (pisanie kodu), wymagane są odpowiednie środowiska w ilości określonej przez architekturę oprogramowania;
• Czy wymagane jest wykorzystanie środowisk tego samego typu jednocześnie. Gdy system jest uruchamiany po wydaniu, konieczne jest jednoczesne korzystanie z kilku środowisk testowych lub posiadanie dodatkowych środowisk w celu zapewnienia nieprzerwanego funkcjonowania systemu i jego jednoczesnego wdrażania w ramach wydań.

3. Koszt dodatkowego oprogramowania. Jeśli na etapie projektowania systemu zdecydowano, że wymagane jest dodatkowe oprogramowanie do obsługi procesów biznesowych, wówczas konieczny staje się zakup odpowiednich pakietów oprogramowania.

4. Koszt wdrożenia systemu ERP. Koszt ten jest określany na podstawie dwóch wskaźników:

• Liczba roboczogodzin, które należy poświęcić na wykonanie wszystkich prac w ramach projektu wdrożeniowego zgodnie z podejściem wybranym dla danego projektu lub podprojektu (więcej informacji na temat podejść można znaleźć w "Metodyka wdrożenia systemu ERP D365FO ma znaczenie"). Współczynnik ten jest zmienny i zależy bezpośrednio od zakresu, tj. liczby i złożoności zadań wykonywanych w ramach projektu wdrożenia systemu. Wszelkie zmiany dotyczące zakresu prac w stosunku do planowanego prowadzą do zmiany wysokości kosztów pracy, a tym samym kosztów. Tak więc koszt projektu lub jego części jest czynnikiem drugorzędnym, a zatem zarządzanie tym kosztem oznacza zarządzanie zakresem prac i kosztami pracy;
• Koszt roboczogodziny (stawka), który jest określany w umowach handlowych między Zamawiającym a Wykonawcą i określany w odpowiedniej umowie.

5. Koszt wsparcia poprojektowego. Koszty te są związane z utrzymaniem produktu, który został już wprowadzony do eksploatacji komercyjnej. Wykonanie tych prac jest zwykle regulowane odrębną umową z odpowiednimi warunkami. Wysokość kosztów pracy w ramach takiej umowy zależy zazwyczaj od następujących czynników:

• Liczby i kwalifikacji personelu zatrudnionego przez Zamawiającego na potrzeby utrzymania systemu;
• Liczby procesów/użytkowników w systemie;
• Jakości testów systemu przed jego wprowadzeniem do eksploatacji;
• Kwalifikacji oraz jakości szkolenia użytkowników w zakresie funkcji systemu;
• Liczby niestandardowych i pozaplanowych operacji w systemie, które mogą pojawić się poza zakresem projektu;
• Jakości wykorzystywanych danych (katalogi itp.);
• Liczby i specyfiki integracji z systemami innych firm;
• Zainicjowanych zmian (nowe wymagania lub dostosowania do ustalonych procesów).

Dokładne zrozumienie czynników, które wpływają na koszt projektu, oraz sposobu zarządzania nimi jest powiązane ze zrozumieniem tego, jak powinna wyglądać metodyka wdrożenia systemu ERP i wymaga ciągłej uwagi.

Vlad Berezin

Business Development Manager, SMART business

Etapy wdrażania systemu ERP

1. Rozpoczęcie projektu
2. Analiza i modelowanie procesów
3. Konfiguracja systemu
4. Testowanie systemu
5. Wdrożenie systemu/Przygotowanie do uruchomienia
6. Uruchomienie/Wsparcie
7. Zarządzanie zmianami

I. Rozpoczęcie projektu (Project start)

1. Plan projektu (Project Baseline). Plan ten opracowany zostanie na podstawie wyników Oceny Projektu (patrz artykuł „Proces wyceny wdrożenia systemu ERP”), ale w tym przypadku zostanie on dostosowany do rzeczywistych zasobów, ich kalendarzy i warunków umowy. Zatwierdzony plan projektu służy jako punkt odniesienia, który umożliwia dalsze porównywanie rzeczywistych wyników projektu z planowanymi wynikami (działania, czas trwania, koszty, zasoby, koszty pracy, dane dotyczące harmonogramu).
2. Struktura organizacyjna projektu i role. Wstępne określenie tych danych może być dokonane w ramach działań przedprojektowych (patrz artykuł „Proces wyceny wdrożenia systemu ERP”), ale ostateczne zatwierdzenie odbywa się na tym etapie.

II. Analiza i modelowanie procesów (Process modelling and analysis)

• Analizę bieżących procesów, architektury i przepływów danych (As Is Model) w formie wywiadów oraz udokumentowanie ich wyników w formie opisu tekstowego i opracowania schematów procesów.
• Zbieranie wymagań i ograniczeń dotyczących procesów, przepływów danych i form prezentacji informacji oraz dokumentowanie ich w odpowiedniej formie.
• Modelowanie systemu w celu uwzględnienia wymagań dotyczących procesów, przepływów danych i form prezentacji informacji.
• Formalizacja wymagań dotyczących pożądanych procesów, przepływów danych i form prezentacji informacji w formie dokumentu wymagań funkcjonalnych (FRD)). Dokument ten zawiera schematy mapowania procesów, opisy tekstowe tych schematów oraz inne informacje.
• Stworzenie backlogu wymagań i odpowiednich prac związanych z konfiguracją systemu, priorytetów wymagań i ich specyfiki w formie dokumentu Fit&Gap, gdzie:
  • Fits – działania związane z konfiguracją systemu,
  • Gaps – opracowanie nowych lub rozszerzenie istniejących funkcji.
• Identyfikacja obszarów integracji systemu ERP z produktami firm trzecich, opis przepływów danych i parametrów technicznych wymiany informacji.
• Definiowanie i formalizowanie ogólnej architektury rozwiązania, która pokazuje system ERP i jego miejsce w ogólnej strukturze rozwiązania, wskazując obszary integracji i przepływy danych w ramach rozwiązania.
• Koordynacja dokumentów FRD i Fit&Gap w ramach Specyfikacji konfiguracji systemu.
• Doprecyzowanie planu projektu z ewentualnymi korektami w oparciu o dane Specyfikacji istotnych warunków zamówienia oraz, w razie potrzeby, modyfikacja i ponowne zatwierdzenie Podstawowego planu projektu (baseline).

• rodzaju wdrożenia (podejście standardowe lub oparte na prototypach);
• złożoności konkretnego procesu biznesowego;
• ogólnej złożoności projektu;
• liczby i specyfiki wymagań systemowych;
• liczby i specyfiki obszarów integracji;
• innych czynników.

III. Konfiguracja systemu (System Configuration)

• Parametryzacja funkcji systemu (Perform Setups (Fits)).
• Dostosowanie funkcji systemu (Perform Development (Gaps)) – dodawanie/zmienianie funkcji, pól, filtrów, tworzenie raportów, formularzy podstawowych itp. przy użyciu wbudowanych narzędzi systemu:
  • przygotowanie specyfikacji modyfikacji;
  • realizacja modyfikacji;
  • testowanie.
• Konfiguracja źródeł danych, przepływów pracy, parametrów danych, raportów przy użyciu wbudowanych narzędzi systemu (Configuration).
• Demonstracja prototypu systemu dla wybranych procesów.
• Omówienie i zatwierdzenie kluczowych specyfikacji dotyczących rozwoju.
• Przygotowanie scenariuszy testowych:
  • scenariusze testów funkcjonalnych;
  • scenariusze testów integracyjnych.
• Wewnętrzne testy funkcjonalne (Internal Functional Testing) – system jest testowany przy użyciu zasobów zespołu projektowego.

IV. Testowanie systemu (System Testing)

• poszczególnych procesów, integracji lub grup procesów (Testowanie funkcjonalne– Functional Testing) – User Acceptance Testing:
  • przygotowanie danych testowych;
  • demonstrację działania systemu w ramach testowanych scenariuszy i szkolenie kluczowych użytkowników;
  • system jest testowany przez kluczowych użytkowników przy wsparciu zespołu projektowego;
  • dostosowanie systemu i odpowiednich scenariuszy testowych.
• Kompleksowe testowanie systemu jako całości (Testowanie integracyjne – End-to-End Testing):
  • wewnętrzne testy integracyjne (Internal Integrational Testing) – system;
  • zewnętrzne testy integracyjne (External Integrational Testing) – testowanie systemu przez kluczowych użytkowników przy wsparciu zespołu projektowego;
  • dostosowanie systemu i odpowiednich scenariuszy testowych.
• Testy wydajnościowe są stosowane tylko w przypadku dużej liczby operacji i/lub użytkowników.

V. Wdrożenie systemu/Przygotowanie do uruchomienia (System Deployment)

• Szkolenie użytkowników (kluczowych i końcowych). Główne szkolenie kluczowych użytkowników jest przeprowadzane podczas fazy testowania, ale dodatkowe szkolenie może być wymagane podczas fazy wdrażania systemu. Szkolenie użytkowników końcowych jest przeprowadzane przez kluczowych użytkowników klienta. W wyjątkowych przypadkach mogą być zaangażowani specjaliści Wykonawcy.
• Przygotowanie szablonów migracji danych.
• Migracja danych (ze starych/starszych systemów i ręcznie) oraz weryfikacja ich poprawności. To zadanie wykonywane jest przez specjalistów Zamawiającego. Należy również pamiętać, że zadanie to może wiązać się ze znacznym zwiększeniem kosztów pracy i zająć dużo czasu. Nieprawidłowe dane są jednym z najczęstszych problemów na etapie Uruchomienia systemu.
• Konfiguracja praw dostępu do danych systemu – przeprowadzana przez specjalistę Zamawiającego po odpowiednim przeszkoleniu.
• Przygotowanie środowiska produkcyjnego systemu.
• Przygotowanie planu uruchomienia systemu. Plan ten jest opracowywany w celu opisania krok po kroku działań mających na celu wprowadzenie systemu do eksploatacji. Działania te mogą być zarówno przygotowawcze, jak i opisywać kolejność wprowadzania działów/procesów do systemu zgodnie z kalendarzem.
• Realizacja planu uruchomienia systemu.
• Przygotowanie instrukcji ról użytkowników – realizowane przez specjalistę Zamawiającego na podstawie Scenariuszy testów funkcjonalnych.

VI. Uruchomienie/Wsparcie (Go Live/Support)

• Wdrożenie planu uruchomienia.
• Wsparcie użytkowników.
• Rozwiązywanie problemów i błędów.
• Wprowadzanie zmian.

Zarządzanie zmianami (Change Control)

• Inicjacja i opis wniosku o zmianę (Change Request – CR):
  • Opis potrzeby;
  • Ustalenie priorytetów.
• Analiza wniosku przez specjalistę odpowiedzialnego za dany obszar:
  • Istota wniosku;
  • Celowość;
  • Obszary wpływu zmian.
  • Dokonanie przeglądu Analizy wniosku przez kierownictwo projektu.
• Ocena wniosku przez specjalistę odpowiedzialnego za dany obszar:
  • Szacowanie pracochłonności;
  • Koszt;
  • Czas trwania.
• Dokonanie przeglądu przez inicjatora zmiany, członka zespołu zarządzania projektem i podjęcie decyzji:
  • Akceptuj;
  • Odrzuć;
  • Odłóż.
• Realizacja wniosku, jeśli został zaakceptowany:
  • Dodanie do planu i dostosowanie Project Baseline;
  • Wykonanie prac;
    • Testowanie:
    • Wewnętrzne;
    • Zewnętrzne.
• Demonstracja działania systemu po wdrożeniu zmiany;
• Wdrożenie zmiany (Deployment).

• Zmiany są jednym z najczęstszych powodów wydłużenia czasu trwania i zwiększenia kosztów projektu.
• Złożone zmiany mogą być wdrażane iteracyjnie.
• Nieprzestrzeganie powyższej procedury zarządzania zmianami może prowadzić do nieprzewidywalnych konsekwencji dla wydajności systemu.
• Liczba zmian zależy bezpośrednio od jakości pracy na etapie „Analiza i modelowanie” oraz odpowiednich dokumentów projektowych.
• Koszty pracy związane z wdrożeniem ewentualnych zmian są zazwyczaj niemożliwe do dokładnego zaplanowania. Z tego powodu w planie uwzględniane są rezerwy.

Podejście do wdrażania projektów ERP opartych na Dynamics 365 finance and operations applications wykorzystywane przez SMART business, które jest oparte na metodologii Microsoft Sure Step (Success by Design) to logiczny i kompleksowy zestaw procesów, dokumentów i procedur. Przestrzeganie tego podejścia w projektach wdrożeniowych jest kluczowym elementem udanej realizacji projektu systemu ERP o dowolnej złożoności.

Vlad Berezin

Business Development Manager, SMART business