Wdrożenie Dynamics 365 krok po kroku

Wdrożenie Dynamics 365 krok po kroku przebiega w sześciu fazach: analiza przedwdrożeniowa, projekt rozwiązania, konfiguracja i rozwój, migracja danych, testy i szkolenia oraz uruchomienie produkcyjne z opieką powdrożeniową. Cały cykl trwa zwykle od kilku do kilkunastu miesięcy, a o jego długości decyduje nie liczba modułów, lecz ilość danych do przeniesienia, liczba integracji i dostępność Twojego zespołu. Poniżej rozkładamy każdą fazę na czynniki pierwsze: co się w niej dzieje, kto za co odpowiada, gdzie projekty najczęściej się potykają i w którym miejscu Microsoft każe zatrzymać się na bramce kontrolnej.  

Dla zarządu użyteczniejsze od samego kalendarza jest zrozumienie, że każda z tych faz zamyka się decyzją, która zawęża pole manewru w następnej: zakres ustalony w analizie wyznacza budżet konfiguracji, a jakość danych przyjęta w migracji przesądza o możliwym terminie startu. Program tej klasy nie jest zakupem oprogramowania, lecz zmianą sposobu, w jaki organizacja rejestruje i rozlicza własną działalność, dlatego jego właścicielem powinien być członek zarządu z mandatem do rozstrzygania sporów między działami, a nie kierownik projektu pozbawiony wpływu na priorytety.  

Badania nad wdrożeniami ERP od lat pokazują, że to nie technologia, lecz przygotowanie organizacji odpowiada za większość przekroczeń budżetu i terminu, a koszt zatrzymanego programu rośnie nieliniowo: im później wykryje się błąd założeń, tym drożej się go koryguje. Dlatego poniższy opis warto czytać nie jak instrukcję techniczną, lecz jak dokument kontrolny, w którym każda faza ma wymierne kryterium wyjścia pozwalające ocenić, czy inwestycja idzie zgodnie z planem, czy wymaga interwencji, zanim zaangażuje się kolejną transzę kapitału. Taki sposób czytania przenosi rozmowę na komitecie sterującym z pytania o cenę na pytanie o kontrolę nad ryzykiem i tempo zwrotu.

1. Analiza przedwdrożeniowa
2. Projekt rozwiązania
3. Konfiguracja i rozwój
4. Migracja danych
5. Testy i szkolenia
6. Uruchomienie produkcyjne i stabilizacja
‍

Harmonogram wdrożenia w skrócie

‍

‍

Ta tabela pokazuje jedną rzecz, o której większość opisów milczy: co drugą pozycję w kolumnie odpowiedzialności zajmuje klient. Dynamics 365 nie wdraża się firmie, tylko z firmą. Jeżeli właściciele procesów nie mają czasu na warsztaty, a zespół nie ma kiedy testować, żadna metodyka tego nie nadrobi. Druga rzecz, którą tabela pokazuje tylko pośrednio, to nakładanie się faz.  

Migracja danych nie stoi w kolejce za konfiguracją, lecz biegnie z nią równolegle od momentu, w którym znany jest model docelowy, i to ona, a nie liczba modułów, najczęściej wyznacza najwcześniejszą możliwą datę startu. Podane widełki czasowe są zakresami, a nie zobowiązaniami: różnica między trzema a sześcioma tygodniami analizy nie wynika z tempa pracy partnera, lecz z tego, jak szybko klient udostępni właścicieli procesów i podejmie decyzje, które do niego należą. Dlatego harmonogram czyta się jak łańcuch zależności, w którym opóźnienie jednej pozycji przesuwa wszystkie następne, a nie jak zbiór niezależnych zadań. Dla zarządu praktyczny wniosek jest taki, że zasób najbardziej deficytowy w całym programie to nie budżet gotówkowy ani konsultanci partnera, lecz czas kluczowych pracowników, którzy muszą testować i decydować obok swoich codziennych obowiązków.  

Ten czas jest kosztem alternatywnym, który nie pojawia się na żadnej fakturze, a mimo to przesądza o tym, czy podane widełki się utrzymają, czy rozjadą się o kwartał. Firma, która wchodzi w projekt bez formalnego zwolnienia tych osób z części bieżących zadań, płaci za to później najdroższą walutą: przesuniętą datą startu i wydłużonym okresem utrzymywania równolegle starego i nowego systemu. Dostępność zespołu bywa więc twardszym ograniczeniem projektu niż jego budżet gotówkowy.

‍

Faza 1. Analiza przedwdrożeniowa

Analiza przedwdrożeniowa to mapowanie procesów biznesowych i przełożenie ich na zakres projektu, harmonogram oraz cele. Partner prowadzi warsztaty z działami, które będą pracować w systemie, i spisuje, jak firma działa dziś oraz jak ma działać po starcie. To najtańsza faza i zarazem ta, która ustawia budżet całości. Tu powstaje decyzja, ile procesów idzie na standard Dynamics 365, a ile wymaga rozszerzeń.  

Najczęstszy błąd to zakres spisany zbyt ogólnie. Zdania w stylu „obsługa zamówień jak dotychczas” wracają w fazie testów jako dziesiątki drobnych zmian, których nikt nie wycenił. Dobrze poprowadzona analiza kończy się dokumentem, po którym da się policzyć koszt, a nie tylko go oszacować. Ekonomia tej fazy opiera się na prostej zależności: koszt korekty błędnego założenia rośnie o rząd wielkości z każdą kolejną fazą, więc godzina uwagi zarządu poświęcona zakresowi w analizie oszczędza wielokrotność tej godziny w testach i jeszcze więcej po starcie. Dlatego na warsztatach powinni zasiadać ludzie z prawem do rozstrzygania, jak ma wyglądać proces docelowy, a nie delegaci bez mandatu, których ustalenia i tak trafią później do renegocjacji.  

Kluczowe rozstrzygnięcie tej fazy nie brzmi „jak pracujemy dziś”, lecz „które z dzisiejszych praktyk są przewagą wartą utrzymania, a które jedynie przyzwyczajeniem, które warto porzucić na rzecz standardu”. Każdy proces obroniony wyłącznie argumentem, że zawsze tak robiliśmy, zamienia się później w rozszerzenie, które trzeba budować, testować i utrzymywać przez cały cykl życia systemu. Dokument zakresu powstały na końcu analizy pełni funkcję punktu odniesienia dla wszystkich późniejszych faktur i sporów, dlatego im mniej zawiera zdań otwartych na interpretację, tym węższy przedział, w którym może się poruszyć końcowy koszt programu.

‍

Faza 2. Projekt rozwiązania

Projekt rozwiązania to architektura systemu: dobór modułów, zaprojektowanie integracji z pozostałym oprogramowaniem oraz rozstrzygnięcie, co realizuje standard, a co rozszerzenie. Efektem jest plan, według którego zespół będzie budował. Microsoft opisuje ten moment jako pierwszą obowiązkową bramkę kontrolną. W metodyce Success by Design nazywa się ona Solution Blueprint Review i sprawdza, czy projekt uwzględnia model danych, bezpieczeństwo, integracje i strategię testów, zanim ktokolwiek zacznie konfigurować. Warto pilnować, żeby partner faktycznie przez tę bramkę przechodził, bo to ona wyłapuje błędy, które w fazie testów kosztują dziesięciokrotnie więcej.  

Najczęściej niedoszacowanym elementem projektu są integracje. Jeden system rzadko żyje sam. W wdrożeniu Dynamics 365 Finance dla TERG, właściciela sieci Media Expert, obejmującym finanse i finanse magazynowe dla sieci blisko 500 sklepów, system trzeba było zintegrować z istniejącymi systemami biznesowymi klienta w oparciu o usługi Azure. Każdy taki interfejs to osobny projekt w projekcie, dlatego liczbę integracji trzeba znać na etapie architektury, a nie odkrywać w trakcie. Każdy interfejs ma jeszcze drugi, ukryty koszt, który ujawnia się dopiero po starcie: to zobowiązanie utrzymaniowe, bo system po drugiej stronie również się zmienia, a zerwana integracja potrafi zatrzymać sprzedaż lub wysyłkę równie skutecznie jak awaria samego ERP. Dlatego dojrzała architektura rozstrzyga nie tylko, ile jest integracji, ale też która strona odpowiada za kontrakt danych, jak wersjonuje się ten kontrakt i co się dzieje, gdy jedna ze stron zmieni format bez uprzedzenia.  

Bramka Solution Blueprint Review ma sens ekonomiczny właśnie dlatego, że wymusza te rozstrzygnięcia przed napisaniem pierwszej linijki kodu, kiedy zmiana projektu kosztuje godziny architekta, a nie tygodnie zespołu deweloperskiego i regresję całego łańcucha zależności. Zatwierdzenie architektury przez klienta nie jest formalnością, lecz momentem przejęcia współodpowiedzialności za założenia, na których oprze się cała dalsza budowa.

‍

Faza 3. Konfiguracja i rozwój

Konfiguracja to ustawienie standardowych funkcji Dynamics 365 pod procesy firmy, a rozwój to budowa rozszerzeń tam, gdzie standard nie wystarcza. Im więcej mieści się w standardzie, tym taniej i szybciej. Tu leży decyzja, którą łatwo zlekceważyć. Dynamics 365 aktualizuje się w chmurze kilka razy w roku, a każde rozszerzenie odbiegające od standardu trzeba przy tych aktualizacjach utrzymać. Nadmiar customizacji nie podnosi więc tylko kosztu wdrożenia, ale i rachunku za kolejne lata. Rozsądny partner najpierw szuka rozwiązania w standardzie lub w gotowych, sprawdzonych rozszerzeniach, na przykład w autorskich modułach ANEGIS Power Center do zarządzania personelem czy obiegu dokumentów, a dopiero potem pisze kod od zera.  

Warto policzyć customizację jak zobowiązanie, a nie jak koszt jednorazowy: każde rozszerzenie odbiegające od standardu staje się pozycją na liście regresji, którą trzeba przetestować przy każdej z kilku dorocznych aktualizacji platformy. Dwadzieścia niestandardowych rozszerzeń to dwadzieścia cykli testów regresyjnych rocznie, powtarzanych tak długo, jak system żyje, a ich koszt narasta w tle, poza budżetem samego wdrożenia. Dlatego dojrzały zespół pyta przy każdym rozszerzeniu nie tylko o to, ile kosztuje jego zbudowanie, ale ile będzie kosztować jego utrzymanie przez pięć lat modelu One Version. Bardzo często odpowiedź prowadzi do wniosku, że dopasowanie procesu do standardu jest tańsze niż dopasowanie standardu do procesu, a pozorna oszczędność na zmianie sposobu pracy zwraca się wielokrotnie w latach, w których nikt nie musi łatać rozszerzenia po każdej aktualizacji. Warto więc wprowadzić prostą zasadę zarządczą: każde odstępstwo od standardu wymaga właściciela biznesowego, który podpisze się pod jego wieloletnim kosztem utrzymania, bo rozszerzenie bez takiego właściciela to dług technologiczny, za który po starcie nie odpowiada już nikt.

‍

Faza 4. Migracja danych

Migracja danych to przeniesienie i oczyszczenie informacji z dotychczasowych systemów, często ze starszego Dynamics AX lub rozwiązań lokalnych. To faza, która najczęściej wykłada projekty, i jednocześnie ta, którą najłatwiej zbagatelizować. Problem prawie nigdy nie leży w samym przeniesieniu rekordów, tylko w ich jakości. Zduplikowani kontrahenci, indeksy bez opisów, historyczne salda, które się nie spinają, wychodzą zwykle na jaw dopiero przy pierwszym teście, czyli w najgorszym możliwym momencie. Microsoft traktuje to na tyle poważnie, że zarządzanie danymi opisuje jako osobny obszar cyklu wdrożenia, z własnymi kryteriami jakości. Dlatego migrację zaczyna się wcześnie, równolegle z konfiguracją, a nie na końcu.  

Za jakość danych źródłowych odpowiada klient, bo to on wie, które z nich są prawdziwe. Partner odpowiada za mapowanie, walidację i próbne ładowania, których w większym projekcie jest kilka, zanim padnie to ostateczne. Praktyka, która oddziela projekty kontrolowane od tych, które osuwają się na migracji, to wczesne ocenianie jakości danych: nadanie każdemu zbiorowi źródłowemu wymiernego wskaźnika kompletności i spójności, zanim zapadnie decyzja, co w ogóle przenosić.

Z tej oceny wynika drugie rozstrzygnięcie, które ma bezpośredni wpływ na budżet: co migrować na gorąco do środowiska produkcyjnego, a co zarchiwizować na zimno poza nim. Nie wszystkie dane historyczne muszą trafić do Dynamics 365. Salda otwarte, aktywni kontrahenci i bieżące indeksy to jedno, a piętnaście lat zamkniętych transakcji, do których sięga się raz na kwartał, to obciążenie, które taniej trzymać w osobnym archiwum z dostępem na żądanie. Każdy rekord przeniesiony bez potrzeby to koszt mapowania, walidacji i późniejszego utrzymania, dlatego zakres migracji jest decyzją finansową, a nie tylko techniczną. Migracja danych bywa też cichą ścieżką krytyczną całego harmonogramu: to ona, a nie konfiguracja modułów, najczęściej wyznacza najwcześniejszą możliwą datę startu, więc opóźnienie w danych przekłada się jeden do jednego na przesunięcie go-live.

‍

Faza 5. Testy i szkolenia

Testy akceptacyjne (UAT) to moment, w którym użytkownicy sprawdzają system na własnych procesach, a szkolenia przygotowują zespół do pracy w nowym środowisku. Formalnie to jedna faza, w praktyce testowanie toczy się od pierwszej konfiguracji. Najczęstsza przyczyna opóźnień nie jest techniczna. To niedostępność kluczowych użytkowników, którzy mają testować obok swojej codziennej pracy.  

Jeżeli firma nie zwolni im czasu, UAT się rozjeżdża, a data startu przesuwa. Druga pułapka to rozrost zakresu właśnie na testach: każde „a mogłoby jeszcze” dopisane teraz jest najdroższą zmianą w całym projekcie. Szkolenia z kolei decydują o tym, czy po starcie ludzie faktycznie użyją systemu, czy wrócą do arkuszy obok niego. Adopcja jest częścią wdrożenia, nie dodatkiem po nim. Testy warto prowadzić według scenariuszy odwzorowujących faktyczne transakcje firmy, z jednoznacznym kryterium wejścia i wyjścia oraz klasyfikacją błędów według wagi, tak by zespół sterujący odróżniał usterkę blokującą start od kosmetycznej, której poprawka może poczekać. Zamrożenie zakresu na czas testów nie jest sztywnością dla samej zasady, lecz decyzją finansową: zmiana wprowadzona na tym etapie wymaga ponownej konfiguracji, ponownej migracji próbki danych i ponownego przejścia scenariuszy, więc kosztuje wielokrotność tej samej zmiany zaplanowanej w fazie projektu.  

Model szkolenia trenerów wewnętrznych, w którym partner uczy wąską grupę liderów, a ci przekazują wiedzę zespołom, obniża koszt i zostawia w firmie kompetencję po zakończeniu projektu. Adopcję warto mierzyć twardo, na przykład udziałem transakcji zaksięgowanych w systemie zamiast w arkuszu obok niego, bo dopiero taka liczba pokazuje, czy wdrożenie zmieniło sposób pracy, czy tylko dołożyło kolejne narzędzie. Testowanie nie jest zatem etapem końcowym, lecz mechanizmem kontroli jakości rozłożonym na cały projekt.

‍

Faza 6. Uruchomienie produkcyjne i stabilizacja

Uruchomienie produkcyjne to przełączenie firmy na Dynamics 365, poprzedzone ostatnią obowiązkową bramką kontrolną. W Success by Design nazywa się ona Go live Readiness Review i odpowiada na jedno pytanie: czy dane, procesy, uprawnienia i zespół są gotowe, żeby ruszyć bez awaryjnego cofania się. Tu pada też decyzja o modelu startu.  

Big bang oznacza przełączenie całości naraz, wariant fazowy uruchamia kolejne obszary lub lokalizacje po kolei. Przy wielu oddziałach standardem jest rollout etapowy: najpierw powstaje wspólny model bazowy, potem pilota w jednej lokalizacji, a na końcu fale wdrożeń w kolejnych. Dla sieci New Yorker środowisko Dynamics 365 Finance objęło w ten sposób ponad 1000 sklepów w 40 krajach. Po starcie zaczyna się stabilizacja, czyli intensywna opieka pierwszych tygodni, a następnie stałe wsparcie powdrożeniowe i rozwój systemu. Wybór między startem jednorazowym a fazowym jest wyborem profilu ryzyka, nie preferencją estetyczną. Big bang bywa tańszy w kosztach bezpośrednich, bo nie utrzymuje się długo dwóch środowisk równolegle, ale koncentruje całe ryzyko w jednym dniu i wymaga wiarygodnego planu awaryjnego cofnięcia, z góry określonym oknem, po którym powrót do starego systemu przestaje być możliwy. Rollout etapowy rozkłada ryzyko i pozwala przenieść wnioski z pilota na kolejne fale, ale wydłuża okres, w którym firma płaci za utrzymanie starego i nowego systemu naraz oraz za zespół pilnujący spójności danych między nimi.  

Termin startu warto przy tym wpisać w kalendarz finansowy tak, by przełączenie nie wypadło w szczycie sezonu ani tuż przed zamknięciem okresu sprawozdawczego, kiedy każdy błąd kosztuje najwięcej. Pierwsze tygodnie po starcie, nazywane hypercare, wymagają zwiększonej obsady po obu stronach, bo to wtedy ujawniają się przypadki brzegowe, których nie pokrył żaden scenariusz testowy, a szybkość reakcji przesądza o tym, czy zespół zaufa nowemu systemowi, czy zacznie go omijać.

‍

Co faktycznie decyduje o czasie i budżecie

Liczba modułów jest tym, co widać w ofercie, ale nie tym, co przesuwa harmonogram. O faktycznym czasie i koszcie rozstrzygają cztery rzeczy, które łatwo policzyć zawczasu.  

• Pierwsza to dane: ich ilość, jakość i wiek. Migracja z systemu prowadzonego dwadzieścia lat potrafi trwać dłużej niż konfiguracja połowy modułów.  

• Druga to integracje, bo każdy interfejs do sklepu internetowego, magazynu czy systemu produkcyjnego to osobny nakład projektowy.  

• Trzecia, najczęściej niedoceniana, to dostępność Twojego zespołu, bo decyzje i testy leżą po stronie klienta i to one najczęściej blokują postęp.  

• Czwarta to zasięg wdrożenia: jeden zakład to inny projekt niż grupa z oddziałami w kilku krajach i lokalnymi wymogami prawnymi.  

Te cztery czynniki nie sumują się, lecz mnożą: duża liczba integracji przy słabej jakości danych i rozproszonym zespole potrafi wydłużyć projekt bardziej, niż wynikałoby z prostego dodania poszczególnych opóźnień, bo każdy z nich obciąża ten sam wąski zasób decyzyjny po stronie klienta.  Dlatego dwie oferty z tą samą liczbą modułów potrafią różnić się kosztem dwukrotnie, a różnicy nie wyjaśni cennik, lecz właśnie dane, integracje, zasięg i dostępność ludzi. Sam koszt licencji jest przy tym najmniejszą niewiadomą.  

Dynamics 365 Finance zaczyna się od 182 € za użytkownika miesięcznie, a wariant Premium od 259,90 € (cennik Microsoft, rozliczenie roczne, ceny bez VAT). Dlatego pytanie „ile kosztuje wdrożenie systemu ERP” nie ma jednej odpowiedzi cennikowej. Koszt wdrożenia ERP to zawsze suma licencji i prac dopasowanych do czterech czynników powyżej, a nie kwota z tabeli. Dla zarządu użyteczniejszym wskaźnikiem niż cena licencji jest relacja kosztu prac wdrożeniowych do rocznej opłaty licencyjnej, bo to ona pokazuje faktyczną złożoność projektu i najczęściej decyduje o tym, czy budżet się utrzyma.

‍

Całkowity koszt posiadania, a nie cena z cennika

Licencja jest pozycją, którą dyrektor finansowy widzi jako pierwszą, i zwykle jest to pozycja najmniejsza. Koszt wdrożenia ERP w rachunku trzyletnim rozkłada się na kilka warstw, z których większość nie pojawia się w cenniku producenta, a każda potrafi przewyższyć samą licencję.  

• Pierwsza to prace wdrożeniowe partnera, które w projektach klasy enterprise bywają wielokrotnością rocznej opłaty licencyjnej — relacja usług do licencji w pierwszym roku sięga często trzy do jednego, a przy dużej liczbie integracji jeszcze więcej.
• Druga to warstwa danych: oczyszczenie, mapowanie i walidacja rekordów to praca liczona w setkach godzin, której nikt nie chce finansować, dopóki nie zablokuje testów.
• Trzecia to integracje, każda z własnym cyklem projektowym i własnym utrzymaniem po starcie.
• Czwarta, najczęściej pomijana w budżecie, to czas własnego zespołu klienta: właściciele procesów, testerzy i osoby decyzyjne nie znikają ze swoich stanowisk na czas projektu, a ich zaangażowanie jest kosztem alternatywnym, który nie trafia na żadną fakturę, lecz obciąża organizację równie dotkliwie jak wydatek gotówkowy.
• Piąta to zarządzanie zmianą i szkolenia, których pominięcie nie obniża kosztu, tylko przesuwa go w czasie i zamienia na niższy zwrot.
• Szósta, i jedyna, która nigdy się nie kończy, to utrzymanie w modelu One Version: Microsoft aktualizuje platformę kilka razy w roku, a każda aktualizacja wymaga regresji tego, co zbudowano ponad standard.
‍

Dopiero suma tych sześciu warstw jest budżetem wdrożenia, a firma, która patrzy wyłącznie na cennik, myli się zwykle o rząd wielkości i odkrywa to w połowie projektu, kiedy zmiana dostawcy jest już najdroższą z możliwych decyzji. Dyscyplina budżetowa polega tu na osobnej rezerwie na każdą z sześciu warstw, bo brak rezerwy nie usuwa kosztu, a jedynie przenosi go z planu do niespodzianki i pozbawia zarząd kontroli nad momentem, w którym ten koszt się ujawni.

‍

Time-to-first-value, czyli metryka dla zarządu

Zarząd zwykle pyta o datę uruchomienia, bo jest konkretna i wpada do harmonogramu. To jednak metryka, która myli, ponieważ dzień startu produkcyjnego nie jest dniem, w którym inwestycja zaczyna się zwracać. Wartość liczy się od momentu, w którym pierwszy proces działa lepiej niż przed wdrożeniem: kiedy zamknięcie miesiąca skraca się o kilka dni, kiedy stan magazynowy przestaje wymagać ręcznej korekty, kiedy dział handlowy widzi marżę na zamówieniu w chwili jego składania.  

Odległość między go-live a pierwszą wymierną korzyścią potrafi wynosić tygodnie albo kwartały i to ją powinien śledzić zarząd, bo to ona opisuje zwrot z zaangażowanego kapitału, a nie sam fakt przełączenia systemu. Konsekwencja jest praktyczna i dotyczy sposobu, w jaki tnie się zakres. Projekt zaprojektowany pod time-to-first-value zaczyna od procesów o najwyższej dźwigni finansowej i uruchamia je wcześnie, nawet kosztem tego, że reszta poczeka. Projekt zaprojektowany pod jedną wielką datę startu trzyma wszystko do końca i odkłada każdą korzyść na ten sam odległy termin, zwiększając przy okazji ryzyko, bo wszystko przełącza się naraz.  

Dla firmy o dużej skali różnica między tymi podejściami jest różnicą w rachunku przepływów: wcześniejszy strumień oszczędności ma wartość pieniądza w czasie, a rok zamrożonego kapitału bez zwrotu jest kosztem, którego nie widać w budżecie projektu, ale widać w wyniku finansowym. Dobrze postawione pytanie na komitecie sterującym brzmi więc nie „kiedy ruszamy”, lecz „który proces zacznie oddawać pieniądze najszybciej i jak przyspieszyć ten moment”. Ta zmiana pytania przekłada się na inny plan wdrożenia i inny sposób etapowania zakresu. Metrykę time-to-first-value da się przy tym zapisać w harmonogramie równie twardo jak datę startu, wiążąc płatność lub premię za wdrożenie z uruchomieniem konkretnego procesu, a nie z samym przełączeniem systemu.

‍

Jak skonstruować umowę i kto ponosi ryzyko

Model umowy nie jest formalnością prawną, lecz decyzją o tym, kto ponosi ryzyko przekroczenia zakresu, i dlatego należy do zarządu, a nie do działu zakupów. Kontrakt w cenie stałej przenosi ryzyko na partnera: to on gwarantuje wynik za ustaloną kwotę, więc to on zapłaci za własne niedoszacowanie. Brzmi bezpiecznie dla klienta, ale ma drugą stronę — partner, który bierze ryzyko na siebie, wycenia je z zapasem, a każda zmiana zakresu poza literą umowy staje się negocjacją i aneksem.  

Model w cenie stałej premiuje więc precyzyjnie spisany zakres i karze projekty, w których wymagania dojrzewają w trakcie. Model rozliczenia za czas i materiał przenosi ryzyko na klienta: płaci się za faktycznie wykonaną pracę, elastyczność jest pełna, ale to klient ponosi konsekwencje każdego opóźnienia i każdej zmiany zdania. W praktyce dojrzałe wdrożenie ERP rzadko jest czysto jednym albo drugim. Analizę i projekt, gdzie zakres dopiero powstaje, rozsądniej prowadzić w modelu czasowym, a budowę już zdefiniowanego rozwiązania w cenie stałej powiązanej z bramkami. Kluczowym mechanizmem, niezależnie od modelu, są kamienie milowe z płatnością powiązaną z odbiorem: umowa, w której pieniądze płyną dopiero po przejściu bramki kontrolnej, ustawia interesy obu stron w jednym kierunku i daje klientowi punkty, w których projekt można zatrzymać, zanim koszt urośnie. Umowa bez takich bramek, płacona ryczałtem z góry lub w równych ratach oderwanych od postępu, odbiera zarządowi jedyną dźwignię, jaką ma w trakcie: możliwość wstrzymania finansowania, gdy dostawa odbiega od planu. Warto też zapisać, jak wycenia się zmiany zakresu, bo to na tym parametrze rozstrzyga się później większość sporów.

‍

Etapy wdrożenia ERP niezależnie od systemu

Sześć faz opisanych wyżej to nie specyfika Dynamics 365. Etapy wdrożenia ERP wyglądają podobnie w każdym poważnym systemie klasy enterprise, bo wynikają z logiki projektu, a nie z marki oprogramowania. Analiza, projekt, budowa, dane, testy i start to szkielet, który Microsoft w Success by Design ujmuje jako pięć faz cyklu: Discover, Initiate, Implement, Prepare i Operate, spiętych obowiązkowymi przeglądami.  

Tak samo przebiega wdrożenie systemu ERP w firmie produkcyjnej, handlowej czy usługowej: zmienia się zawartość poszczególnych faz, nie ich kolejność. Microsoft prowadzi nawet osobny program FastTrack for Dynamics 365, w którym architekci pomagają zespołom przejść przez te fazy i bramki bez typowych błędów. Praktyczny wniosek jest taki, że jeżeli oferta na wdrożenie systemu ERP nie pokazuje tych etapów i bramek kontrolnych, to nie jest to plan, tylko obietnica. Dojrzała metodyka z kamieniami milowymi na końcu każdej fazy pozwala kontrolować zakres, budżet i ryzyko w trakcie, a nie dopiero po fakcie. Ta sama logika obejmuje projekty po stronie relacji z klientem: wdrożenie CRM przechodzi przez identyczny szkielet faz i bramek co wdrożenie ERP, bo różni je zawartość, a nie sposób prowadzenia i kontroli ryzyka. Dla zarządu praktyczna wartość metodyki z bramkami polega na tym, że zamienia projekt z aktu zaufania do dostawcy w serię odwracalnych decyzji: po każdej fazie istnieje punkt, w którym można ocenić dostawę, wstrzymać finansowanie albo skorygować kierunek, zanim koszt urośnie do poziomu, przy którym wycofanie się przestaje być opłacalne. Dlatego wybór metodyki jest w istocie wyborem tego, kto i w którym momencie może powiedzieć „stop”, a to pytanie należy do zarządu na długo przed podpisaniem umowy.

‍

Od czego zacząć wdrożenie

Zanim ruszy pierwsza faza, warto sprawdzić gotowość firmy. Kilka pytań odsiewa większość późniejszych problemów:

• Czy wiadomo, które procesy mają się zmienić, a które zostać takie jak są

• Czy właściciele procesów mają wygospodarowany czas na warsztaty i testy

• Czy ktoś odpowiada za jakość danych, które trafią do migracji

• Czy znana jest lista systemów, z którymi Dynamics 365 ma się integrować

• Czy po stronie firmy jest sponsor projektu z faktyczną decyzyjnością

Jeżeli na większość odpowiedź brzmi tak, faza analizy pójdzie sprawnie. Jeżeli nie, to właśnie tu leży pierwsza praca do wykonania, jeszcze przed wyborem partnera i podpisaniem umowy na wdrożenie Dynamics 365.

‍

‍

‍

‍

‍

‍

‍

‍