Wdrożenie systemu ERP jest procesem skomplikowanym, absorbującym setki osób w Firmie oraz u Partnera wdrażającego. Eksperci uważają, że jest to jeden z najtrudniejszych projektów, prowadzony w przedsiębiorstwie, porównywalny z budową nowego zakładu produkcyjnego. W związku z tym należy prowadzić wdrożenie w sposób zorganizowany wg ustalonych zasad, w miarę możliwości z wykorzystaniem standardowych wzorców dokumentacji. Sposób taki nazywamy metodyką wdrożenia systemu ERP. Dla systemu Dynamics 365 for Finance and Operations jego producent, firma Microsoft poleca metodykę Microsoft Dynamics Sure Step. Metodyka ta wykorzystuje standardy ustalone przez największą organizację zrzeszającą setki tysięcy kierowników projektów z całego świata, tzn. PMI (Project Management Institute) Mogą ją także bez problemu wykorzystywać osoby znające standardy PRINCE2.
Zarówno PMBOK jak i PRINCE2 to metodyki zarządzania wszelkiego rodzaju i wszelkiej wielkości projektami. Microsoft Dynamics Sure Step jest z kolei ściśle wyspecjaizowaną metodyką wdrażania konkretnej rodziny produktów – systemów ERP i CRM. W jej ramach istnieje kilka odmian, zależnych od wielkości przedsiębiorstwa oraz wybranego podejścia:
Różnią się one ilością przewidywanych zadań, dokumentów, stopniem formalizacji itp. W dalszej części artykułu przedstawimy podstawowe zadania związane ze standardowym projektem wdrożenia Microsoft Dynamics 365 for Finance and Operations (dawniej AX).
Nasza firma ma ponad 20 lat doświadczenia we wdrażaniu systemów zarządzania klasy ERP, w trakcie których zrealizowała ponad 100 projektów. Uczestniczyliśmy w projektach o najróżniejszej skali, od rolloutu międzynarodowego wdrożenia, gdzie w polskim oddziale pracowała 1 osoba, po wdrożenia firm wielooddziałowych o dziesiątkach zakładów produkcyjnych w Polsce i poza nią z kilkuset równolegle pracującymi użytkownikami. Przez wiele lat wykorzystywaliśmy własną metodykę opartą na ogólnych standardach wdrażania systemów ERP, a od momentu pojawienia się metodyki Sure Step oparliśmy się na niej. Uczestniczyliśmy we wdrożeniach wielu największych światowych partnerów Microsoft Dynamics, z grupy DynamicsPact, a także spoza niej, pracujących wg najróżniejszych metodyk. Wszystko to nauczyło nas tego, że dla sukcesu projektu ważne jest z jednej strony oparcie na standardzie, takim jak Sure Step, a z drugiej wybór z niego tych elementów, które będą najwłaściwsze w konkretnej sytuacji. Należy tu brać pod uwagę zarówno zakres wdrożenia, wielkość klienta a także jego kulturę organizacyjną. W związku z tym przedstawioną poniżej metodykę należy traktować jako materiał wyjściowy do dyskusji na etapie organizacji projektu.
Metodologia Sure Step dzieli wdrożenie na pięć oddzielnych faz:
W fazie Analiz przeprowadza się szczegółowe analizy procesów biznesowych. Konsultanci przeprowadzają z członkami Zespołu Wdrożeniowego warsztaty analizy procesów biznesowych aby udokumentować I zamodelować przyszły przebieg procesów.
Warsztaty te dzielą się na dwie tury:
Efektem warsztatów analiz procesów biznesowych jest Raport Analizy. Obejmuje on m.in. spis procesów objętych systemem, ich docelowy przebieg, informacje na temat procesów oraz rozszerzony opis wymagań, tam gdzie jest to potrzebne
W trakcie fazy Analizy najważniejszym zbiorem czynności jest zebranie i udokumentowanie wymagań biznesowych Klienta oraz przeprowadzenie analizy dopasowania. Wymagania dokumentowane są w Arkuszu Dopasowania, który zawiera wszystkie ziedntyfikowane wymagania wobec Systemu wraz z oceną, które z nich wymagają modyfikacji Systemu. Wymagania dokumentuje się w trakcie warsztatów Analizy stanu docelowego i wymagań. Zebrany po warsztatach zbiór wymagań stanowi wejście do Analizy Dopasowania, wykonywanej przez konsultantów. W jej wyniku Arkusz Dopasowania jest aktualizowny o informacje, czy dane wymaganie biznesowe jest spełnione używając standardowej funkcjonalności Systemu (“Fit”) czy też wymaga modyfikacji programistycznych (“Gaps”).
Celem fazy Projektowanie jest zdefiniowanie w jaki sposób zaimplementować wymagania biznesowe. Ta faza zawiera konfigurację systemu Microsoft Dynamics i szczegółowe zaprojektowanie specyficznych modyfikacji, które są niezbędne aby zaspokoić wymagania zidentyfikowane w trakcie fazy Analizy. Modyfikacjami mogą być zarówno proste zmiany interfejsu użytkownika (np. Formatek), modyfikacje raportów aż do złożonych nowych funkcjonalności. Faza ta zawiera także projektowanie mechanizmów integracji (interfejsów) oraz niezbędnych elementów migracji danych. Faza projektowania bazuje na wynikach Analizy, tzn. produktach, które w jej trakcie powstały
Celem szkoleń Zespołu Wdrożeniowego w fazie Projektowanie jest zwiększenie efektywności warsztatów modelujących poprzez edukację osób, które będą aktywnie uczestniczyły w podejmowaniu decyzji na temat sposobu implementacji Systemu, w tym nowego przebiegu procesów. Ich uczestnicy przechodzą szczegółowe szkolenie w obszarze. Szkolenie, tam gdzie jest to możliwe, jest wykonywane na wcześniej przygotowanej bazie zawierającej przykładowe dane firmy. Tam gdzie nie jest to możliwe używa się standardowej bazy danych.
Po odbyciu szkoleń odbywają się warsztaty projektowania, w trakcie których następuje przegląd i aktualizacja modelu procesów biznesowych uzgodnionych podczas fazy Analiz. Jednocześnie następuje aktualizacja Zestawienia Wymagań o ewentualne braki, które odkryto w trakcie szkoleń w ramach procedury zarządzania zmianą.
W trakcie fazy Projektowania rozpoczyna się konfigurację standardowych funkcjonalności Systemu w tym uzupełnianie słowników pomocniczych W miarę możliwości część parametryzacji może odbyć się przed szkoleniami Zespołu Wdrożeniowego, w ramach przygotowania przykładowej bazy na szkolenia. Pozostałą część parametrów ustawia się po warsztatach przeglądu procesów biznesowych. Parametryzacja firmy jest wykonywana pod kierownictwem konsultantów z odpowiednich obszarów przy udziale użytkowników kluczowych, którzy np. przygotowują i wprowadzają niektóre słowniki.
Dla najważniejszych ustaleń przygotowuje się projekt parametryzacji w dokumencie Projektu Funkcjonalnego, np. ustalenia odnośnie przyjętej ilości i zawartości wymiarów finansowych.
W trakcie warsztatów projektowania, które odbywają się po szkoleniach Zespołu Wdrożeniowego, przegląda się wymagania, które zostały określone jako braki (“gaps”) funkcjonalności. W razie możliwości konsultant przedstawia możliwe alternatywne rozwiązania oraz możliwe modyfikacje programistyczne. Takie przygotowanie projektu modyfikacji w Projekcie Funkcjonalnym może też nastąpić poprzez szczegółowe uzgodnienia po warsztatach.
W miarę potrzeby dla bardziej skomplikowanych modyfikacji przygotowuje się Projekt Techniczny, zawierający bardziej szczegółowy opis modyfikacji z punktu widzenia technicznego.
Tam gdzie jest to możliwe odbywa się już testowanie funkcjonalności sytemu standardowego oraz dodatkowych modułów. Jest to testowanie pojedyńczych funkcji, tam gdzie system jest już skonfigurowany.
W miarę potrzeby dla bardziej skomplikowanych modyfikacji następuje Przygotowanie scenariuszy testowych dla testów jednostkowych danej funkcji. Są one umieszczane w projekcie technicznym danej modyfikacji.
Dla wymagań dotyczących integracji z innymi systemami, które zostały zidentyfikowane w fazie Analizy wykonuje się szczegółowy Projekt komponentów integracji i interfejsów.
Celem fazy Przygotowanie jest zbudowanie i przetestowanie komponentów Systemu, w tym modyfikacji programistycznych, interfejsów. Głównym produktem jest w pełni skonfigurowany system, zawierający przygotowane modyfikacje programistyczne, w tym kod integracji i interfejsów.
W celu upewnienia się, że System został przygotowany zgodnie z założeniami przeprowadza się testy migracji danych, procesów oraz interacyjne. Przygotowuje się także scenariusze testowe dla testów wydajności i testów akceptacyjnych użytkownika.
W trakcie fazy następuje zakończenie konfiguracji standardowego systemu i modułów dodatkowych w danym obszarze. Będzie miało miejsce uzgodnienie szczegółów realizacji nowych modyfikacji. Uzgodnienia zapisywane w formie zleceń programistycznych. Zlecenia programistyczne akceptują Kierownicy Projektu (dotyczy obu stron)
Przygotowanie to główna faza, w której odbywają sie Prace programistyczne, w trakcie których przygotowuje nowe modyfikacje zgodnie ze zleceniami progrmistycznymi. Prace programistyczne obejmują zarówno kodowanie jak i testy jednostkowe funkcji.
W trakcie fazy Przygotowanie Systemu następuje przygotowanie dokumentacji szkoleniowej. W zależności od ustaleń przygotowywane są specjalizowane materiały szkoleniowe – materiały te obejmują nagrania przy pomocy wbudowanego w Dynamics 365 Rejestratora Zadań. Filmy te dostępne są wprost w systemie, a także na ich podstawie może zostać wygenerowana dokumentacja w formie dokumentów Word zawierających wykonanie poszczególnych czynności „krok po kroku”. Nie wszystkie instrukcje muszą zostać wykonane w formie filmu.
Poza tym używany będzie przygotowany przez Integris standardowy podręcznik do szkolenia ogólnego, zawierający informacje na temat ogólnych funkcjonalności systemu, takich jak sposób poruszania się, filtrowania, narzędziach, tworzeniach autoraportów, alertów, integracji z Excelem itp.
Następnie odbywają się szkolenia użytkowników kluczowych na przygotowanym Systemie.
W trakcie fazy Przygotowanie, po zakończeniu konfiguracji oraz przygotowaniu modyfikacji, w testowanym zakresie, odbywa się Testowanie rozwiązania. Przeprowadza się testy procesów, integracyjne oraz migracji danych (szczegółowy opis poniżej). W fazie tej przygotowuje się także scenariusze testów akceptacyjnych, które będą przeprowadzane w fazie Testów Akceptacyjnych, a których celem jest sprawdzenie możliwości przeprowadzenia standardowych procesów w normalnych warunkach działania firmy.
Opis poszczególnych kategorii testów:
Testy procesowe wykonują użytkownicy kluczowi Klienta, przy wsparciu konsultantów, aby upewnić się, że System jest przygotowany do prowadzenia procesów zgodnie z uzgodnieniami. Przykładowym testowanym procesem może process “Od zamówienia do płatności” (order-to-cash). Testy przeprowadza się w środowisku testowym na przykładowych danych Klienta.
Każdy z użytkowników kluczowych, przeprowadzających testy, możę mieć własne wyobrażenie jak powinna działać konkretna funkcjonalność. W związku z tym ważne jest, żeby zapoznał się szczegółowo z ustaleniami z fazy Projektowania, zawartymi w Projekcie Funkjonalnym. W ten sposób łatwiejsze będzie oddzielenie rzeczywistych błędów/problemów od ewentualnych różnic między zaprojektowaną i dostępną funkcjonalnością a życzeniami konkretnego pracownika (które może przekazać poprzez procedurę zarządzania zmianami) . Należy pamiętać o tym, że niektórzy testerzy mogą mieć negatywne nastawienie do wdrożenia rozwiązania i można napotkać na opór. Ważne jest aby unikać konfrontacji z nimi, jednocześnie zabiegając o przekazywanie przez nich komentarzy i informacji zwrotnej o wynikach testów. Należy też mieć na uwadze, że testy procesów mają służyć weryfikacji funkcjonalności, a nie są one testami obciążenia i nie należy angażować tu zbyt wielu użytkowników.
Wszelkie ewentualne zmiany funkcjonalności, których pomysł powstał w trakcie testowania, należy przekazywać poprzez procedure zarządzania zmianami.
Rezultatem końcowym testów procesowych jest upewnienie się, że skonfigurowane funkcjonalności wraz z modyfikacjami zostały przetestowane z biznesowego punktu widzenia w takim zakresie, że jesteśmy przekonani o poprawności ich działania. Jeśli jakieś funkcje nie mogą być przetestowane samodzielnie, są one testowane w trakcie testów integracyjnych.
Testy integracyjne obejmują całościowe procesy biznesowe. Przykładowo może to być test obejmujący całościowo procesy dla towarów handlowych: od zamówienia do płatności (order to cash) oraz od zakupu do zapłaty (procure to pay). Testy te prowadzone są przez użytkowników kluczowych, przy wsparciu konsultantów, na Systemie testowym z ustawionymi uprawnieniami. Włączenie systemu uprawnień jest ważne, gdyż testujemy tu także bezpieczeństwo i prawidłowość przyjętych ustawień uprawnień użytkowników.
Celem testów integracyjnych jest sprawdzenie wszystkich aspektów Systemu, włączając wszelkie element integracji z innymi systemami.
Sprawdza się, czy dane te można wykorzystywać w standardowych procesach (np. wystawiać faktury dla zaimportowanych odbiorców i produktów). Ewentualne problem należy notować i kontynuować testy (nie przerywać po pierwszym znalezionym błędzie) tak długo jak jest to możliwe. W ten sposób proces usuwania błędów będzie bardziej efektywny.
W trakcie fazy Uruchomienie Systemu – Testy akceptacyjne wykonywane jest próbne uruchomienie systemu. W trakcie fazy Uruchomienia wykonywane są ostateczne działania, prowadzące do przejścia do nowego Systemu Microsoft Dynamics. Rozpoczyna się ją od wykonania szkolenia użytkowników kluczowych i testów akceptacyjnych. Po zakończeniu testów akceptacyjnych podejmowana jest decyzja o starcie lub jego odłożeniu, do czasu rozwiązania krytycznych problemów.
Kluczowe działania w tej fazie obejmują szkolenie użytkowników końcowych, ostateczną migrację danych i rzeczywiste przejście do nowego Systemu produkcyjnego. W trakcie fazy finalizuje się Plan Uruchomienia oraz wykonuje zgodnie z nim czynności niezbędne dla startu system (go-live). Użytkownicy Kluczowi przegotowują Użykowników Końcowych do startu nowej wersji systemu i przeprowadzają ich szkolenia. Po zakończeniu testów akceptacyjnych podejmowana jest decyzja o starcie lub jego odłożeniu, do czasu rozwiązania krytycznych problemów.
Zespół techniczny przygotowuje środowisko produkcyjne do startu.
Po zakończeniu testów akceptacyjnych następuje migracja danych, w terminach określonych w projekcie migracji danych.
Wykonywany jest ostateczny audyt środowiska produkcyjnego i ostateczne zatwierdzenie gotowości Systemu.
Inną kluczową aktywnością w tej fazie jest transfer wiedzy, zgodnie z planem ustalonym w trakcie fazy projektowania.
Szkolenia użytkowników końcowych mają na celu przygotowanie Użytkowników Końcowych do pracy z Microsoft Dynamics. Wszyscy uczestnicy szkoleń są zobowiązani do zapoznania się przed szkoleniem z opisem procesów w dotyczącym ich zakresie. Odpowiedzialni za dopilnowanie tego są użytkownicy kluczowi, którzy przeprowadzają szkolenia. Zapoznanie to może także mieć miejsce na początku szkoleń, gdzie przed każdą sesją użytkownik kluczowy opowiada jak i dlaczego będzie wyglądał nowy przebieg procesów. Szkolenia powinny mieć miejsce możliwie najbliżej startu produktywnego, tak aby uniknąć erozji uzyskanej wiedzy. Rekomenduje się szkolenie zorientowane na role, tak aby użytkownicy końcowi uzyskiwali wiedzę jak najbardziej zbliżoną do ich codziennych zadań.
Użytkownicy kluczowi przygotowują instrukcje stanowiskowe dla użytkowników końcowych na podstawie dokumentacji wytworzonej przez Integris w poprzednich fazach.
Ze względu na istotność przeszkolenia wszystkich pracowników, którzy będą pracować w nowym Systemie, należy z odpowiednim wyprzedzeniem uzgodnić terminy i rezerwację odpowiedniego czasu. Uczestnictwo w szkoleniach jest obowiązkowe i powinno być dokumentowane. Uczestnicy powinni mieć możliwość oceny szkolenia np. przy pomocy Formularza oceny szkolenia.
Start Systemu (Go live) jest kulminacją działań w projekcie wdrożeniowym. Przed Startem weryfikowana jest gotowość, zgodnie z przygotowaną wcześniej checklistą. Sam Start Systemu odbywa się zgodnie z uzgodnionym wcześniej planem. Po Starcie wszelkie problemy raportowane są zgodnie z uzgodnioną procedurą.
Zapewnione musi być ukończenie następujących czynności :
Ostateczna migracja danych do środowiska produkcyjnego zazwyczaj składa się z kilku faz:
Z chwilą gdy dane zostaną załadowane do systemu, Kierownik Projektu ze strony Klienta upewnia się, na podstawie informacji od odpowiednich użytkowników kluczowych, że wszystkie salda i dane są poprawne. Jeżeli dane zostały załadowane i są bezbłędne, to system jest gotowy do uruchomienia. Tam gdzie jest możliowość weryfikacji z danymi w starej wersji taka weryfikację powinni też dodatkowo przeprowadzić konsultanci (kontrola krzyżowa) .
Gotowy do pracy system Microsoft Dynamics 365 for Finance and Operations
Faza Pracy z Systemem obejmuje działania związane z nadzorem powdrożeniowym i zamknięciem projektu.
W pierwszym okresie konsultanci Integrisu w ramach nadzoru powdrożeniowego wspieraja użytkowników, służąc krótkim szkoleniem, pomocą i wiedzą przez określony czas. W procesie tym przekazuje się system w ręce użytkowników, tak aby byli oni pewni, że mogą samodzielnie kontynuować jego użytkowanie. Nadzór ten wykonują konsultanci obecni na miejscu, a także dostępni telefonicznie i z wykorzystaniem połączenia zdalnego.
Ten czas jest krytyczny, należy zadbać o sprawne zarządzanie i rozwiązywanie błędów. Ewentualne wcześniejsze zaniedbania lub niedostateczne szkolenia mogą sprawić że okres ten będzie bardzo męczący dla wszystkich uczestników.
Ważne jest aby Kierownicy Projektu ze strony Klienta i Partnera wymusili stosowanie zgłoszeń przez Portal Zgłoszeniowy
Jednocześnie następuje przekazanie Systemu do wsparcia powdrożeniowego, którego warunki ustala się w umowie serwisowej.