Product Backlog MS Dynamics AX – Od Ogółu Do Szczegółu

W ramach artykułu Product Backlog MS Dynamics AX – Analiza Od Ogółu … Do Szczegółu, postaram się przedstawić jedną z koncepcji prowadzenia fazy analizy wdrożenia systemu ERP. Faza ta niezależnie od przyjętej metodyki zarządzania jest według mnie najbardziej wymagającym etapem projektu czy to dla Kierownika Projektu czy Product Ownera. Jej główna trudność polega na ciągłym poruszaniu się w abstrakcyjnym środowisku nieistniejącego jeszcze rozwiązania. Opisywanie „nieznanego” nastręcza podstawowej trudności odpowiedzenia na pytanie jak dużą ilość tego „nieznanego” już przeanalizowaliśmy. A żeby rzetelnie odpowiedzieć na tak postawione pytanie, należy mieć przede wszystkim świadomość przeanalizowanego zakresu. Reasumując w ramach tego artykułu postaram się przedstawić sposób wymiarowania „nieznanego”.

Product Backlog MS Dynamics AX – Analiza Od Ogółu Do Szczegółu

Opisując fazę analizy warto zbudować świadomość pewnych jej fundamentów.

Pierwszym fundamentem jest cel tj. zbudowanie jak najlepszego Product Backlog MS Dynamics AX.

Drugim fundamentem jest określenie strategii przeprowadzania analizy oraz budowy Product Backlog MS Dynamics AX. Jednym z elementów wspomnianej strategi, jest wybór formuły prowadzenia analizy. Osobiście znam z praktyki tylko jedną z nich tj. od ogółu do szczegółu. Spotkania analityczne organizowane w tym podejściu możemy podzielić na 3 serie. Co ważne każda z serii powinna następować kolejno po sobie.

Seria I – Product Backlog MS Dynamics AX – Analiza Od Ogółu Do Szczegółu

Cel: Uświadomienie klientowi na wysokim poziomie ogólności, jak dochodzi do wypracowania marży przedsiębiorstwa oraz korzyści jakie niesie wykorzystanie poszczególnych modułów. Narzędzia: krótkie opisy obszarów, modułów czy składowych łańcucha kreowania wartości. Generalnie nie skupiamy się na szczegółach funkcjonalnych, tworzymy wysoko-poziomy obraz wdrożenia. Ryzyko: wielu klientom seria ta wydaje się zbędna, woleliby uznać za oczywistość jakie wysokopoziomowe klocki wchodzą w skład rozwiązania. W ramach spotkań należy zidentyfikować osoby odpowiedzialne oraz doprecyzować motywacje jakie przyświecały zarządzającym przy uruchamianiu projektu.

Seria II – Product Backlog MS Dynamics AX – Analiza Od Ogółu Do Szczegółu

Cel: Zbudowanie mapy procesów wraz z opisem realizujących je czynności. Mapa powinna zostać zbudowana w oparciu o składowe / obszary / epiki które zbudowaliśmy w ramach I serii spotkań. Przy czym nie chodzi tutaj o szczegółowe odwzorowanie czynności jakie użytkownik wykonuje w obecnym systemie. Narzędzia: Warto przyjąć któryś z obowiązujących standardów modelowania procesów biznesowych. We wdrożeniach ERP (Dynamics AX 2012) najczęściej wykorzystywanym jest BPMN (patrz artykuł: Modelowanie Procesów Biznesowych – BPMN). Zastosowanie w ramach serii II modelu referencyjnego procesów biznesowych (patrz artykuł: Referencyjny Model Procesów Biznesowych Dynamics AX 2012) pozwoli zredukować czas analizy oraz uprościć komunikację z biznesem. Ryzyko: Istnieje nieliczna grupa przedsiębiorstw zarządzanych procesowo. Znacznie częściej spotykanym modelem jest zarządzanie funkcyjne. Zarządzanie procesami polega m.in. na ich kwantyfikowalności, pomiarach wydajności, optymalizacji oraz wzmacnianiu wszechstronności pracowników. Zarządzanie funkcyjne opiera się na delegowaniu wąskiej grupy zadań, wąskiej grupie pracowników. Niestety dokonanie transformacji z jednego sposobu zarządzania na drugi nie jest proste i natychmiastowe. Dlatego w ramach tej fazy musimy wytworzyć odpowiednią świadomość procesów według których realizowana będzie faza wykonania projektu.

Seria III – Product Backlog MS Dynamics AX – Analiza Od Ogółu Do Szczegółu

Cel: W ramach tej serii należy omówić / opisać funkcjonalności systemowe realizujące procesy biznesowe zidentyfikowane, w ramach II serii spotkań. W zależności od obranej metodyki zarządzania projektem w tym analizy opisy te będą bardziej lub mniej szczegółowe. Narzędzia: Warto przy w/w modelowaniu wykorzystać narzędzia dostarczone wraz z systemem ERP. Dla systemu Dynamics AX 2012 jest to np. Task Rekorder. Ryzyka: Faza ta potrafi być niezwykle pracochłonna, szczególnie przy podejściu kaskadowym (patrz artykuł: Zarządzanie wdrożeniem Dynamics AX z użyciem SCRUM).  Nadmierne jej przeciąganie jest wynikiem próby minimalizacji ryzyka po stronie dostawcy oraz klienta. Pracownicy klienta odpychają odpowiedzialność za stworzone opisy bo nie do końca rozumieją wdrażany system. Daje to złudne wrażenie zabezpieczania własnego interesu na wypadek gdyby o czymś zapomniano. Dostawca w atmosferze braku zaufania stara się opisywać wszystko jak najbardziej precyzyjnie, nie pozostawiając pola do interpretacji. Przy okazji za każdy dodatkowy dzień pracy oczekuje zapłaty. Cały zespół w takiej sytuacji obiera nowy cel projektu tj. zakończenie prac nad dokumentem, tracąc przy tym najważniejsze: zbudowanie systemu.

Kolejność spotkań – Product Backlog MS Dynamics AX – Analiza Od Ogółu Do Szczegółu

Nadrzędną zasadą analizy od ogółu do szczegółu jest kolejność odbywania się serii spotkań. Oznacza to że nie rozpoczynamy analizy funkcjonalności systemowych jeśli nie zakończyliśmy budowy mapy procesów etc. Warto podkreślać w trakcie pierwszych spotkań że naszym celem nie jest przeprowadzenie idealnej analizy a budowa systemu. Dążenie do ideału we wstępnych fazach projektu, się nie opłaca tj. lepiej mieć zidentyfikowanych 14 procesów i o 1 zapomnieć niż 7 idealnie opisanych ale nie zdążyć z analizą pozostałych 8. Jednym z najczęściej popełnianych błędów jest schodzenie w trakcie I / II serii spotkań do szczegółów funkcjonowania systemu. Najczęściej błąd ten wymuszają użytkownicy którym łatwiej jest opisywać funkcjonalność (czynność) z której korzystają na co dzień niż abstrakcyjny model biznesowy. Odnosi się to szczególnie do tych organizacji, które wraz z analizą systemu przechodzą transformację zarządzania z funkcyjnego na procesowy. Generalizując użytkownikom łatwiej przychodzi opowiadanie jak? coś chcieliby robić niż po co?

Warto w ramach tej fazy projektu uświadamiać zespół projektowy w tym przedstawicieli biznesu oraz komitet sterujący że do wypracowania koncepcji funkcjonowania systemu dochodzi się powoli. Nieudane analizy są bardzo często wynikiem zbyt szybkiego przejścia do szczegółów funkcjonowania systemu. Zbyt duża ilość szczegółów przekazana na początku analizy potrafi przytłoczyć konsultanta który nie rozumiejąc całości po prostu się poddaje. Kończy się to albo jego odejściem z projektu albo przekazaniem klientowi inicjatywy. Przy czym to drugie jest krótką ścieżką do zbudowania niespójnego modelu analitycznego. Modelu w którym, pewne procesy biznesowe są niewspółmiernie uproszczane kosztem nadmiernej komplikacji innych, włączana jako część procesu jest obsługa sytuacji wyjątkowych (tj. takich które zdarzają się rzadko lub co gorsza jeszcze się nie zdarzyły „ale zawsze mogą”).

Product Backlog MS Dynamics AX – Harmonogram

Załóżmy zatem że podjęto decyzję strategiczną co do sposobu realizacji fazy analizy. Zgodnie z tą decyzją Product Backlog MS Dynamics AX będzie budowany w trybie od ogółu do szczegółu. Jak zatem zbudować narzędzie do zarządzania tą fazą?

W pierwszej kolejności na poszczególne serie spotkań należy spojrzeć jak na iteracje (cykle) jakie wydarzą się w trakcie projektu. A zatem cykle będziemy mieli 3:

  1. Cykl I, Analiza strategiczna – podział wdrożenia na moduły, łańcuch kreowania wartości etc.
  2. Cykl II, Analiza biznesowa – zbudowanie mapy procesów biznesowych, wraz z opisem czynności;
  3. Cykl III, Analiza techniczna / systemowa – mapowanie czynności realizujące procesy biznesowe, na funkcjonalności systemowe;

Harmonogram budowy Product Backlog MS Dynamics AX opieram właśnie na w/w cyklach. Przy pierwszej prezentacji warto uświadomić KS że istotą zarządzania czymś „nieznanym” jest pogodzenie się z jego naturą. A w szczególności jego częściową nie-zarządzalnością. Takie postawienie sprawy prowadzi do wniosku, że po każdym z cykli to co było nieznane staje się wiadome zatem możemy pokusić się o dokładniejsze predykcje.

Zatem zwieńczeniem każdego z cykli jest (kamień milowy) spotkanie Komitetu Sterującego na którym prezentowane są 4 elementy diamentu zarządzania projektem. Przypomnę że chodzi tutaj o budżet, harmonogram, zakres projektu wraz z odniesieniem do jakości. Każdy z mierzonych wskaźników jest wartością początkową do wykonania dokładniejszego przybliżenia tzw. końca projektu.

W trakcie budowy harmonogramu należy wziąć pod uwagę że każdy z cykli jest bardziej złożony. Zatem zakładanie dla każdego z nich jednakowej pracochłonności jest nieporozumieniem. Jedynym sposobem na próbę zmniejszenia różnic w czasie ich trwania jest dołożenie dodatkowych osób do projektu. Należy to jednak robić z umiarem pamiętając że 9 kobiet nie urodzi w miesiąc dziecka. Z mojej praktyki wynika że nad jednym obszarem maksymalnie może pracować 2 osoby. Większa ich liczba nie przekłada się już tak mocno na wydajność.

Product Backlog MS Dynamics AX – Produkty cykli

W ramach tego akapitu chciałbym powiedzieć parę słów na temat produktów Product Backlog MS Dynamics AX. Warto od razu na wstępie wrócić do definicji SCRUMa która kładzie nacisk na tzw. inkrement. W przypadku fazy analizy oraz wyżej przedstawionych 3 jej cykli widać go jak na dłoni. Otóż produkty wytworzone w ramach poprzedniego cyklu są materiałem wejściowym dla kolejnej iteracji analizy. Służą one również jako punkt startowy do wykonania wszelkich estymacji projektowych. Mówiąc o estymacjach projektowych mam na myśli czas trwania, liczebność zespołu projektowego, wielkość budżetu, zaangażowanie biznesu etc.

Przechodząc do konkretów, Product Backlog MS Dynamics AX dzielę na następujące składowe:

  1. Łańcuch kreowania wartości, Epiki, Obszary (najwyższy poziom szczegółowości)
  2. Element nadrzędny (składowa łańcucha kreowania wartości, moduł systemowy, moduł logiczny)
    • Proces biznesowy – wchodzący w skład danego elementu nadrzędnego
      • Czynność zdefiniowana w ramach danego procesu
  3. Funkcjonalności systemowe (modyfikacje)

Poniższy rysunek przedstawia poziomy analizy wraz z odzwierciedleniem analizowanego zakresu:

Product Backlog MS Dynamics AX - Od Ogółu Do Szczegółu

Fazy etapu analizy Microsoft Dynamics AX

Zawsze staram się aby 2 pierwsze elementy miały postać u strukturyzowaną np. drzewiastą. Prosta nawigacja pozwala szybko odnaleźć się nawet w skomplikowanym wdrożeniu. Ponadto od razu wychodzą pewne powiązania pomiędzy procesami, ich właścicielami oraz tzw. między-obszarowość. Łańcuch kreowania wartości oraz wraz z realizującymi go procesami biznesowymi dla uproszczenia nazywamy analizą biznesową. Długość tej fazy stanowi około 1/3 całego czasu analizy. Jej zwieńczeniem jest odbiór mapy procesów biznesowych wraz z opisami czynności dokonywany przez zespół po stronie klienta / biznesu.

Ostatni cykl analizy tj. analiza zbioru funkcjonalności jest już częścią analizy technicznej. Z pozoru jej produkty nie mają żadnej struktury. Nie jest to oczywiście prawda, gdyż dziedziczą one strukturę z analizy biznesowej / procesowej. Dla większości wdrożeń struktura funkcjonalności tworzona jest przez linkowanie elementów procesów biznesowych z funkcjonalnościami technicznym. Czemu linki są bardziej naturalne niż budowanie struktury dla funkcjonalności? Na przykład dlatego, że jedną funkcjonalność wykorzystujemy w wielu procesach i przy wielu czynnościach. Utrzymanie poniekąd 2 struktur (biznesową oraz techniczną) co najmniej 2 krotnie zwiększa administracyjny nakład pracy. Ponadto już sama struktura poniekąd sugeruje wykorzystanie funkcjonalności, a lepiej budować modyfikacje między obszarowe.

Product Backlog MS Dynamics AX – Podsumowanie

Na koniec chciałbym napisać kilka słów na temat skali / zakresu analizy. Pamiętajmy że wdrożenia systemu ERP potrafią być na prawdę niezwykle skomplikowane. W wielu przypadkach bez odpowiednich narzędzi, Kierownik Projektu nie ma szans żeby zapanować nad całym wdrożeniem. O skali wdrożenia niech świadczą uśrednione liczby które przedstawię poniżej:

  1. Liczba konsultantów / programistów biorących udział przez cały cykl życia projektu: 20
  2. Liczba osób biorących udział we wdrożeniu po stronie biznesu: 25
  3. Liczba interesariuszy po stronie biznesu: 100 – 120
  4. Liczba obszarów / składowych łańcucha kreowania wartości: 12
  5. Liczba procesów biznesowych (globalnie): 150
  6. Liczba czynności / korków opisujących procesy: 1 000
  7. Liczba funkcjonalności / modyfikacji (niestandardowych): 600 – 800
  8. Łączna liczba zadań utworzonych w ramach projektu (JIRA): 2 500

Zarządzanie takim przedsięwzięciem na pewno nie jest proste, dlatego warto zastanowić nad wdrożeniem odpowiednich narzędzi, struktury i szablonów. W kolejnych artykułach przedstawię jak zbudować narzędzia które będą nas wspierały w trakcie prac projektowych. Krótko przestawię z jakich standardów korzystam oraz jak je konfiguruję.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

sixteen − 12 =