25 kluczowych elementów wdrożenia Microsoft Dynamics 365 for Finance and Operations

Jedna z wiodących firm wdrażających system Dynamics wskazuje 25 rzeczy, o których dostawca oprogramowania Microsoft Dynamics nie powie klientowi zamawiającemu oprogramowanie.

Polemizując z z tymi argumentami pokażemy w jaki sposób pracuje nasz zespół wdrożeniowy, i co dla nas jest kluczowe podczas przeprowadzania naszego kontrahenta przez trudny proces implementacji nowego systemu Microsoft Dynamics 365 for Finance and Operations

Według innej firmy wdrażającej
"‍W świecie Dynamics AX istnieją poważne niedobory zasobów. Dostawcy grają w grę „przynęta i zmiana”, na początek delegując swoich najlepszych pracowników na prezentacje sprzedażowe lub rozpoczęcia projektów, a następnie stopniowo zastępując ich mniej kompetentnymi osobami. Z trudem zdobyta w komunikacji z klientem wiedza przekazywana między zespołami podczas cyklu sprzedaży zostaje w większości stracona. Nalegaj na model sprzedawca=opiekun klienta, w którym dostawca wyznacza jeden, niezmienny zespół, który zajmuje się klientem od początku do końca, a w przypadku zmian w zespole gwarantowane jest bezpłatne wdrożenie nowej osoby."

W naszej firmie nie ma sprzedawców. Podczas procesu sprzedażowego spotykają się Państwo z ludźmi, którzy będą z Wami pracować podczas wdrożenia. To o czym będą opowiadać będą w przyszłości u Was implementować.

Nigdy nie spotkaliśmy się z podejściem, aby zmiany w zespole firmy wdrażajacej - wynikające z wewnętrznych sytuacji - spowodowały zwiększenie wyceny wdrożenia.

Według innej firmy wdrażającej
"W procesie wdrażania produktu nie ma miejsca na tajemnice. Należy z góry wyraźnie zadeklarować swój budżet i nalegać, aby dostawca powiedział, czy cele projektu mogą być osiągnięte przy podanych założeniach. Zbyt piękne, żeby było prawdziwe? Nie bój się zadawać trudne pytania zarówno przy niskich, jak i wysokich wycenach. Nieuniknione jest, że coś zostanie pominięte."

My jesteśmy elastyczni - jeśli chodzi o zakres wymagań  przyjęty do realizacji to określamy go na początku procesu wdrożeniowego - podczas analizy.

Jednak stosowana przez nas zwinna metoda wdrożeniowa zakłada, że co Sprint (najczęściej co miesiąc) wykonujemy sprawdzenie przyjętych założeń dla danego obszaru wdrożeniowego i gdy zajdzie taka potrzeba dostosowujemy Backlog kolejnych Sprintów do aktualnych - być może zmiennych - potrzeb (Backlog Sprintu - lista zagadnień, którymi w czasie Sprintu zajmuje się Zespół, aby osiągnąć Cel Sprintu uzgodniony z klientem). 

Według innej firmy wdrażającej
"Partnerzy systemu Dynamics AX zrealizowali wiele projektów i mają wiedzę o tym, jaki będzie odpowiedni budżet i harmonogram przy danych celach projektu. Ustal budżet, harmonogram lub ambitne cele, ale nie dyktuj tych wszystkich trzech czynników bez zasięgnięcia porady doświadczonego praktyka."

My uważamy, że budżet i harmonogram projektu są najważniejszymi elementami decydującymi o powodzeniu wdrożenia. Powinny być określone na początku wdrożenia i kontrolowane w trakcie zarówno po jednej jak i drugiej stronie. 

Tworzenie harmonogramu - Project Plan - wykonujemy wraz z klientem, tak, aby dostosować przyjęty zakres projektu do budżetu jaki posiada klient.
Według innej firmy wdrażającej
"Upewnij się, że dostawca poczyni znaczne inwestycje w celu dostarczenia Twojego systemu zgodnie z założeniami i w ustalonych ramach czasowych. Nalegaj na rozsądnej wysokości raty płatności realizowane po wykonaniu i dostarczeniu ważnych etapów projektu, ale zachowaj uczciwe podejście co do zakresu ryzyka i poziomu wynagrodzenia."

My stosujemy elastyczne metody rozliczeń, charakterystyczne dla umów realizowanych z wykorzystaniem metodyk zwinnych. Zamawiający, dokonując podziału etapu realizacji projektu na iteracje, może, a nawet powinien postanowić, że wynagrodzenie należne wykonawcy będzie mu wypłacane w częściach odpowiadających swą wartością danej iteracji, po należytym wykonaniu i odbiorze każdej z nich.
Według innej firmy wdrażającej
"Unikaj pokusy rozpoczynania projektu od długotrwałego procesu sprzedaży, próbując zrozumieć wszystkie wymagania w celu zapewnienia maksymalnie dokładnych wycen i zobowiązań od dostawców. Chociaż pozornie wydaje się to dobrym pomysłem, tak szczegółowe podejście do zapytania ofertowego bardziej prawdopodobnie zakończy się klęską projektu. Może się tak stać, ponieważ zapytanie ofertowe i projekt systemu będą bazować na procesach i funkcjach w stanie, w jakim się znajdują („as-is”), które mogą zupełnie stracić znaczenie, kiedy zostaną zniwelowane przez właściwości nowego systemu."

Patrick Lencioni - ceniony specjalista ds. zarządzania, konsultant, mówca i autor bestsellerów z listy „New York Timesa”napisał przypowieść biznesową o tym, jak pokonać trzy lęki, które niszczą związek z klientem. W naszej pracy z potencjalnymi klientami oraz w trakcie projektu staramy się zachować całkowitą transparentności postępowania i prezentować tzw "bezbronność" wobec klienta. Zgodnie z założeniami Lencioniego już podczas pierwszych sprzedażowych spotkań staramy się dowiedzieć od naszego potencjalnego klienta co skłoniło go do poszukiwań nowego systemu ERP oraz co jest jego największym problemem biznesowym. Pokazujemy jak można za pomocą naszego systemu rozwiązać taki problem. Nie boimy się rozdawania swojej wiedzy. Jesteśmy szczerzy wobec klienta, nie boimy się mówić otwarcie co może być dobre, a co może stanowić zagrożenie na projekcie, mimo, że może to być dość brutalne dla klienta. Uważamy, że szczerość jest bardzo ważna.

Według innej firmy wdrażającej

"Wykonanie dobrej pracy wymaga adekwatnej ilości czasu. Wcześniej niekoniecznie oznacza lepiej. Znacznie bardziej korzystne jest ustalenie zakresu projektu i zbudowanie mapy funkcyjnej projektu o odpowiednim stopniu szczegółowości, aby ułatwić opracowanie przyszłego projektu w okresie "przedsprzedażowym.""

Stosowane przez nas metody Agile traktują wymagania bardziej dynamiczne niż zwykłe metody. 

W procesach modelowania i projektowania uzyskuje się szybszą informację zwrotną od użytkownika systemu.
Skupiamy się na krótszych iteracjach, w których to dany obszar funkcjonalny, dość często jest doprowadzany do takiego poziomu jakości, który pozwala na jego wydanie, zazwyczaj trwa to miesiąc. Krótkie iteracje dostarczają wielu korzyści technicznych i tych dotyczących zarządzania.
Budowana zwinnie dokumentacja projektu nie jest nadmiarowa, gdyż częste pokazywania kupującemu przygotowanych obszarów funkcjonalnych, pozwalają szybciej osiągnąć zamierzony cel dokumentacyjny.
Pracując z klientem staramy mu pokazać gotowe artefakty (modele, dokumenty). Zapobiegamy w tedy sytuacji, że dany obszar funkcjonalny będzie wymagał wielu poprawek. Po drugie klient ma mniejszy obszar do przejrzenia co pozawala sądzić, że zrobi to szybciej i dokładniej.
Z punktu widzenia zarządzania, częste iteracje dostarczają często dowodów postępu, co zazwyczaj prowadzi do dobrej widoczności statusu, dobrych relacji z klientami

Według innej firmy wdrażającej
"Nie martw się przesadnie znalezieniem dostawcy, który ma doświadczenie z najnowszą wersją Twojego systemu. Rodzina Dynamics AX ewoluuje nieustanie od 16 pełnych i częściowych wersji przez ostatnie 27 lat. Większość praktyków, którzy pracowali z co najmniej dwiema lub trzema wersjami, powinna wiedzieć, jak przeprowadzić adaptację wersji najnowszej. W praktyce oznacza to, że każda ważna wersja to 2-letni cykl, a ponieważ ukończenie większości dużych projektów zajmuje ok. 2 lata, nigdy nie znajdziesz specjalisty doświadczonego w projektach w zakresie najnowszej wersji. Po prostu upewnij się, że dostawca jest w stanie przeprowadzić adaptację nowej wersji."

Nasi wiodący konsultanci i developerzey czyli techniczni liderzy zespołów wdrożeniowych mają w swoich portfoliach około 20 pełnych wdrożeń i kilkadziesiąt mniejszych rolloutów bądź upgradów. Partnerstwo zamiast outsourcingu jest sposobem, aby przeprowadzić naszego klienta przez proces modelowania nowego systemu. Dokładamy wszelkich starań, aby zrozumieć wymagania kupującego system i stworzyć rozwiązanie, które będzie dopasowane do potrzeb Jego organizacji.

Nasza konkurencja pisze.
"Wielu dostawców zrobi wszystko, żeby uniknąć odpowiedzialności wobec Twojej firmy. Nigdy nie zgadzaj się na podpisanie umowy, w której zapis o macierzy odpowiedzialności (ang. RACI) nie obejmuje partnera."

Nasza minimalna dokumentacja projektowa zawiera listę wymagań - Backlog projektu. Zawiera ona nie tylko spis wymagań, ale również twórcę wymagania - czyli key usera oraz Konsutanta wiodącego dla danego obszaru.

Nasza konkurencja pisze.

"Odsprzedawcy Microsoft Dynamics AX są ekspertami w wydobywaniu prawdy od opornych właścicieli procesów. Dzień spędzony na analizie funkcjonalnej bez wkładu Twojego dostawcy jest dniem straconym. Jego zespół będzie musiał przejść przez tę analizę ponownie i zadawać niezręczne pytania, których Twoi pracownicy mogli nie mieć odwagi zadać. Co gorsza, Twoi eksperci zniechęcą się, będąc zmuszeni do zajmowania się ponownie tymi samymi zagadnieniami."

Zgodnie z założeniami Lencioniego nie boimy się zadawać pytań, zarówno ważnych jak i mniej ważnych. Wiemy, że bez pytań nie ma rozwiązań. Stosując zwinne metody pracy zleceniobiorca otrzyma w krótszym czasie efekt naszych starań, jeśli będzie niesatysfakcjonujący problem powróci do Backlogu projektu i ponownie zostanie zbadany.
Nasza konkurencja pisze.
"Rozmawiaj z każdym liderem zespołu projektowego i zadawaj im podchwytliwe pytania dotyczące Twoich procesów. Wybierz jakieś mało znane funkcje Dynamics AX (w bazie TechNet) i zapytaj ich o zaprojektowanie procesu wykorzystującego tę funkcję. Jeśli powiedzą, że wymagane jest przeprogramowanie, masz do czynienia z amatorami."

My nie zadajemy podchwytliwych pytań - szczerze informujemy klienta o możliwościach rozwiązania zagadnienia i konfrontujemy postawione przez nas tezy i proponowane rozwiązania wraz z klientem. Jeśli mimo naszego doświadczenia nie umiemy odpowiedzieć na zadane pytania, rejestrujemy problem i powracamy do klienta ponownie z rozwiązaniem.

Nasza konkurencja pisze.
"Pamiętaj, że na projekt musisz przeznaczyć odpowiednie zasoby. Poproś w swoim biurze, żeby zgłosiły się osoby, które mogą przeznaczyć 50% swojego czasu... Nie łudź się, że duży projekt oprogramowania może być zrealizowany wyłącznie przez właścicieli procesów i administratorów, którzy już i tak mają zajęty cały dzień. Tak: musisz zaangażować w prace projektowe swoich najlepszych ludzi."

Uważamy, że zespół projektowy - zarówno po stronie dostawcy jak i odbiorcy usług nie może być złożony z przypadkowych ludzi, którzy akurat mają czas. Musi to być zespół zarówno kompetentynych, merytorycznych i decyzyjnych osób, jak też znających procesy biznesowe w danym obszarze.
Nasza konkurencja pisze.
Przeprowadź porządkowanie i czyszczenie danych TERAZ. Główną przyczyną przekładania uruchomienia projektu jest źle zaplanowana i źle przeprowadzona migracja danych. Jeśli nie jesteś w stanie zapanować nad danymi, kiedy nic Cię nie pogania, nie masz szans nad nimi zapanować, kiedy pojawi się pośpiech i presja.

Przyczyn przekładania daty GO LIVE może być wiele. Nasza zwinna mini dokumentacja powstajaca podczas wstępnej fazy projektu zawiera projekt migracji danych. Zgadzamy się z tym, że dane exportowane ze starego systemu powinny być przejrzane i uporządkowane przez zleceniodawcę oraz pod okiem konsultanta uzupełnione o dane niezbędne w nowym systemie.
Nasza konkurencja pisze.
"Przygotuj się odpowiednio na duży nakład pracy przy testowaniu po dostarczeniu pierwszej wersji Twojego oprogramowania. Jeśli nie możesz przetestować oprogramowania, konfiguracji, migracji danych i ustawień bezpieczeństwa niezwłocznie po dostarczeniu systemu, Twoja gwarancja może wygasnąć długo zanim zostaną wykryte defekty."

Stosowana przez nas metodologia Conference Room Pilot pozwala pokazać i udowodnić, że nowe oprogramowanie spełnia wymagania i oczekiwania biznesowe użytkowników. metodologia CRP może mieć cechy Testów akceptacyjnych (UAT) nie mniej jednak użycie CRP pomaga potwierdzić, że ​ rozwiązanie jest poprawne na wyższym poziomie niż zwykłe testowanie funkcjonalne.

Nasza konkurencja pisze.
"Nie ignoruj zarządzania projektami — zarówno Ty, jak i odsprzedawca będziecie potrzebować dobrego kierownika projektów. I przygotuj się na finansowanie obu. Twój kierownik projektów musi być asertywny, zmotywowany i mieć odpowiednie uprawnienia, aby podejmować decyzje prowadzące projekt do mety. We wdrażaniu systemu Dynamics AX nie ma miejsca na święte krowy."

Uważamy, że kluczowym czynnikiem warunkującym powodzenie wdrożenia rozległych systemów informatycznych jest nadanie dużych uprawnień kierownikom projektu zarówno po stronie firmy wdrażającej jak i po stronie klienta. To kierownik projektu odpowiedzialny jest za harmonogram realizacji, kwestię techniczne oraz koszty. W sytuacji, gdy za projekt odpowiada kilka osób, czyli odpowiedzialność jest rozmyta, użytkownik jest sfrustrowany, ponieważ nie potrafi uzyskać jednorodnej informacji o całościowym statusie projektu
Skuteczne wsparcie wyższego kierownictwa w firmie jest niezbędne do prawidłowego postępu prac w projekcie w trakcie całego cyklu projektowego. Szczególnie ze względu na pojawianie się problemów, których rozwiązanie wykracza poza kompetencje posiadane przez Komitet Sterujący.

Malgorzata Pokornowska

Jeśli chciałbyś nawiązać z nami współpracę