Ustne ustalenie nie daje pewności realizacji
Zakres projektu D365 F&O zaczyna się rozpadać, gdy ustne ustalenia są traktowane jak gwarancja realizacji. Rozwiązaniem nie jest większa liczba spotkań. Potrzebny jest pisemny, możliwy do przetestowania zakres, który jeszcze przed rozpoczęciem prac konfiguracyjnych i programistycznych określa wymagania, wyłączenia, odpowiedzialność, założenia, gotowość danych, kryteria akceptacji oraz zasady zarządzania zmianą.
Taki dokument powinien być punktem kontrolnym projektu, a nie formalnością związaną z zakupem usług.
Większość dodatkowych prac w projektach ERP zaczyna się od zdania, które podczas warsztatów brzmiało mniej więcej tak:
„Potrzebujemy lepszej widoczności stanów magazynowych”.
„Finanse potrzebują bardziej przejrzystego raportowania”.
„Integracja powinna automatycznie przesyłać dane zamówień”.
„Użytkownicy potrzebują prostszego procesu akceptacji”.
Każde z tych stwierdzeń może być prawdziwe. Żadne nie jest jednak wystarczająco precyzyjne, aby na jego podstawie rozpocząć konfigurację lub development.
W projekcie Microsoft Dynamics 365 Finance & Operations ogólna zgoda może ukrywać kilka różnych interpretacji. Dyrektor finansowy może rozumieć przez raportowanie miesięczne pakiety zarządcze. Kierownik operacyjny może mieć na myśli bieżącą widoczność marży. Programista może usłyszeć wymaganie dotyczące pól danych, encji i logiki odświeżania. Tester będzie potrzebował jednoznacznego warunku zaliczenia lub odrzucenia testu.
Wszyscy się zgadzają, ale każdy ma w głowie inną wersję wymagania.
W tym miejscu zakres projektu zaczyna tracić swoją wartość.
Dobry zakres projektu D365 F&O powinien odpowiadać na pytania, których często unika się podczas ustnych ustaleń:
To pierwszy element Testu Jasności Zakresu: czy uzgodniony zakres może zostać przeczytany, zakwestionowany, przetestowany i zarządzany przez osoby, które nie uczestniczyły w pierwotnych rozmowach?
Jeśli odpowiedź brzmi „nie”, zakres nie jest jeszcze wystarczająco dobrze przygotowany.
Nie chodzi o to, aby obciążyć realizację projektu ERP biurokracją, ale aby firma nie płaciła później za brak jasności, którą mogła zapewnić sobie wcześniej.
Po rozpoczęciu prac konfiguracyjnych i programistycznych każde nieprecyzyjne założenie staje się trudniejsze do wycofania. Brak jasno określonego wyłączenia może zamienić się w wniosek o zmianę zakresu. Niedokładny opis procesu może doprowadzić do konieczności ponownego zaprojektowania rozwiązania. Nieokreślone kryterium akceptacji może sprawić, że testy UAT staną się dyskusją, a nie podstawą do podjęcia kolejnych decyzji.
Dla osób zarządzających jest to kwestia kontroli. Słabo zdefiniowany zakres ogranicza widoczność kosztów, ryzyka i prawdopodobieństwa terminowej realizacji. Dobrze opisany zakres daje zespołowi projektowemu wspólny punkt odniesienia, zanim ustalenia staną się trudne do zmiany.
W D365 F&O jasność jest narzędziem kontroli ryzyka.
Różne zespoły mogą inaczej rozumieć to samo wymaganie
Wymaganie dotyczące D365 F&O ma wartość tylko wtedy, gdy biznes, konsultanci, programiści i testerzy rozumieją je w ten sam sposób. Zgoda podczas warsztatów nie wystarczy. Zanim rozpocznie się konfiguracja lub tworzenie rozszerzeń, wymaganie trzeba przełożyć na poszczególne kroki procesu, przykłady, reguły dotyczące danych, odpowiedzialność oraz kryteria akceptacji.
Weźmy często spotykane wymaganie:
„Potrzebujemy widoczności stanów magazynowych w czasie rzeczywistym”.
Może ono oznaczać kilka różnych rzeczy:
Problem tkwi nie w użytych słowach, ale w brakujących szczegółach.
W tym miejscu zakres projektu ERP wymaga tłumaczenia między zespołami. Użytkownicy biznesowi opisują potrzebę operacyjną. Konsultanci przekładają ją na analizę fit-gap i logikę procesu. Programiści określają, gdzie wystarczy standard D365 F&O, a gdzie może być potrzebne rozszerzenie, integracja lub wykorzystanie Power Platform. Testerzy zamieniają ostateczne wymaganie w dowód, na podstawie którego można jednoznacznie potwierdzić lub odrzucić jego realizację.
Bez tego tłumaczenia projekt przenosi ukrytą niejednoznaczność do etapu budowy rozwiązania.
Dobrze przeprowadzone warsztaty dotyczące zakresu powinny dać więcej niż jedynie notatki. Powinny doprowadzić do stworzenia znaczenia, które można przetestować.
Oznacza to wymagania napisane prostym językiem, mapy procesów, przykładowe scenariusze, wskazanych właścicieli, zależności dotyczące danych oraz jasne kryteria akceptacji.
Przykładowo wymaganie „widoczność stanów magazynowych w czasie rzeczywistym” może zostać doprecyzowane w następujący sposób:
„Kierownicy magazynu muszą mieć możliwość sprawdzenia dostępnego zapasu według lokalizacji, magazynu i statusu indeksu przed zwolnieniem pracy kompletacyjnej. Widok nie może uwzględniać zapasu objętego kwarantanną, musi odzwierciedlać zaksięgowane transakcje i zostanie zweryfikowany podczas testów UAT na podstawie pięciu uzgodnionych scenariuszy magazynowych”.
To zdanie nie jest idealne, ale można je przetestować. Daje zespołowi projektowemu znacznie bardziej konkretną podstawę niż sama intencja.
To drugi element Testu Jasności Zakresu: czy tester może udowodnić, że wymaganie zostało spełnione, bez pytania uczestników pierwotnych warsztatów, co mieli na myśli?
Jeśli nie, wymaganie nadal jest zbyt otwarte.
Wniosek dla osób zarządzających jest prosty: jakość realizacji projektu D365 F&O zależy od wspólnego języka. Im wcześniej firma zamieni rozmowy na przykłady, reguły i możliwe do zweryfikowania dowody, tym mniej miejsca pozostanie na późniejsze nieporozumienia.
Jasny zakres nie spowalnia projektu, lecz zapobiega szybkiemu podążaniu w niewłaściwym kierunku.
Luki w zakresie zwykle ujawniają się późno, gdy ich usunięcie kosztuje więcej
Luki w zakresie rzadko pozostają teoretyczne. Ujawniają się w momencie, gdy ktoś musi zaprojektować, skonfigurować, zintegrować, przetestować lub formalnie odebrać rozwiązanie.
Dlatego niejasny zakres projektu D365 F&O na początku może wydawać się niegroźny, ale później staje się kosztowny. Nieprecyzyjne wymaganie może pozostać niezauważone podczas planowania, a następnie stać się pilnym problemem, gdy testy UAT pokażą, że proces nie odpowiada rzeczywistemu sposobowi działania firmy.
Widocznym problemem może być wolne tempo realizacji. Głębszą przyczyną często jest brak odpowiedniego uzgodnienia zakresu na początku.
Typowy schemat wygląda następująco:
Właśnie dlatego dyscyplina w definiowaniu zakresu ma tak duże znaczenie w projektach ERP. D365 F&O łączy finanse, łańcuch dostaw, magazyny, zakupy, produkcję i raportowanie. Niewielka niejednoznaczność w jednym obszarze może wpłynąć na kilka pozostałych.
Przykładowo, jeśli odpowiedzialność za dane podstawowe nie zostanie uzgodniona odpowiednio wcześnie, niska jakość danych dotyczących indeksów, dostawców lub klientów może później zostać błędnie uznana za problem systemu.
Raporty mogą wyglądać nieprawidłowo. Skrypty testowe mogą nie przechodzić. Użytkownicy mogą stracić zaufanie do rozwiązania. Zespół wdrożeniowy może zostać poproszony o „naprawienie” obszaru, za który nigdy nie wskazano jednoznacznego właściciela.
Tego rodzaju nieporozumienia pochłaniają czas, ponieważ zmuszają projekt do cofania się. Zespoły muszą ponownie otwierać zamknięte decyzje, przepisywać skrypty testowe, weryfikować założenia projektowe i tłumaczyć zmiany budżetu interesariuszom, którzy byli przekonani, że dana kwestia została już rozstrzygnięta.
To trzeci element Testu Jasności Zakresu: jeśli wymaganie zmieni się na późniejszym etapie, czy zespół projektowy będzie w stanie wyjaśnić, co się zmieniło, kto zatwierdził zmianę, na jakie obszary ona wpływa oraz czy zmienia koszt lub harmonogram?
Jeśli odpowiedź brzmi „nie”, zarządzanie zmianą zakresu jest zbyt słabe.
Dobry zakres nie zapobiega każdej zmianie. Projekty ERP potrzebują przestrzeni na zdobywanie wiedzy, odkrywanie nowych zależności i wprowadzanie rozsądnych korekt.
Różnica polega na tym, czy zmiana jest formalnie zarządzana, czy też nieformalnie wchłaniana przez projekt do momentu, w którym staje się on coraz trudniejszy do kontrolowania.
Dla osób zarządzających to istotne rozróżnienie. Zarządzana zmiana chroni jakość decyzji. Nieformalna zmiana rozmywa odpowiedzialność.
Kiedy zakres projektu D365 F&O jest jasny, zespoły realizacyjne mogą działać z większą pewnością. Kiedy nie jest, każde późne odkrycie prowadzi do kolejnej rozmowy o tym, co poszczególne osoby uważały za wcześniej uzgodnione.
Pisemny zakres chroni budżet, zasady zarządzania i adopcję systemu
Jasny zakres projektu D365 F&O daje osobom zarządzającym, użytkownikom i zespołom realizacyjnym jeden wspólny punkt odniesienia, zanim nieporozumienia zaczną generować koszty.
Powinien określać prace, granice zakresu, założenia oraz zasady wprowadzania zmian językiem zrozumiałym dla biznesu i wystarczająco precyzyjnym dla zespołu wdrożeniowego.
Najlepsze dokumenty zakresowe zwykle obejmują:
Uzgodnione wymagania: co rozwiązanie musi realizować, wraz z przykładami.
Wyłączenia: czego projekt nie obejmuje, aby brak zapisu nie został uznany za domyślnie uwzględnioną pracę.
Założenia: od czego zależy plan, między innymi w zakresie dostępów, danych i terminowego podejmowania decyzji.
Zależności: dane, integracje, dostawcy zewnętrzni, zasoby wewnętrzne i akceptacje.
Kryteria akceptacji: w jaki sposób biznes potwierdzi, że praca została zakończona.
Zasady zarządzania zmianą: jak nowe wymagania będą analizowane, zatwierdzane i wyceniane.
Przed rozpoczęciem budowy rozwiązania warto zastosować Test Jasności Zakresu:
W tym miejscu etap analizy i definiowania zakresu pokazuje swoją wartość. Dobry zakres projektu D365 F&O nie usuwa całej niepewności, ale pozwala nią zarządzać.
Nowe potrzeby mogą zostać prawidłowo ocenione. Ryzyka mogą zostać zarejestrowane. Decyzje mogą być śledzone. Osoby zarządzające widzą, czy projekt zmienia się z uzasadnionego powodu biznesowego, czy zaczyna dryfować, ponieważ pierwotne ustalenia były zbyt ogólne.
Najczęściej zadawane pytania (FAQ)
Co powinien obejmować zakres projektu D365 F&O?
Zakres projektu D365 F&O powinien obejmować wymagania, wyłączenia, założenia, zależności, informacje o gotowości danych, kryteria akceptacji, role, kamienie milowe oraz zasady zarządzania zmianą.
Jaka jest różnica między zakresem projektu a Statement of Work (SOW)?
Zakres projektu określa, jakie prace są uwzględnione, a jakie zostały wyłączone. Statement of Work, czyli dokument określający warunki realizacji prac, zwykle obejmuje szersze zasady projektu, takie jak rezultaty, obowiązki stron, terminy, warunki handlowe i zasady odbioru.
Dlaczego kryteria akceptacji są ważne w projektach ERP?
Kryteria akceptacji zamieniają wymaganie w coś, co można przetestować. Ograniczają liczbę sporów podczas testów UAT, ponieważ zespół może porównać dostarczony proces z wcześniej uzgodnionymi dowodami i warunkami.
Kiedy należy rozpocząć zarządzanie zmianą zakresu?
Zasady zarządzania zmianą powinny zostać uzgodnione przed rozpoczęciem realizacji projektu. Odkładanie tego do momentu pojawienia się pierwszych nowych wniosków oznacza, że projekt już opiera się na indywidualnej ocenie zamiast na ustalonych zasadach zarządzania.
Wczesne zapewnienie jasności chroni budżet, poprawia zarządzanie projektem i ułatwia kontrolowanie wdrożenia. Zwiększa także zaufanie użytkowników, ponieważ przyszły proces zostaje wyjaśniony, przetestowany i uzgodniony, zanim pracownicy zostaną poproszeni o jego przyjęcie.
Dla organizacji przygotowujących projekt Microsoft Dynamics 365 Finance & Operations praktycznym kolejnym krokiem jest skoncentrowany przegląd zakresu: przetestowanie wymagań, założeń, gotowości danych oraz odpowiedzialności za decyzje przed rozpoczęciem prac konfiguracyjnych i programistycznych.
