Z czego składa się analiza przedwdrożeniowa w projektach IT – etapy, zadania, rezultaty.

O znaczeniu analizy przedwdrożeniowej pisaliśmy w jednym z poprzednich artykułów. Pora zatem na omówienie elementów, które powinna zawierać analiza oraz jak pracować przy jej przygotowaniu. Świadomość tego, co jest do zrobienia, podzielana przez wszystkich uczestników projektu, pozwala każdemu z nich łatwiej wejść w swoją rolę – a w rezultacie – właściwie się z niej wywiązać.

Szczegółowa struktura elementów analizy przedwdrożeniowej oraz czas niezbędny do przejścia jej etapów, zależą bezpośrednio od cech przyszłego wdrożenia, wśród których należy wymienić:

• kompleksowość – czy system będzie obsługiwał wszystkie operacje w działalności podstawowej przedsiębiorstwa, czy tylko wybrane,
• zakres integracji z innymi systemami – z jakimi systemami działającymi w organizacji klienta, wdrażane rozwiązanie należy zintegrować w celu zapewnienia wymiany informacji i przetwarzania danych,
• w jakim stopniu klient jest przygotowany do wdrożenia – czy posiada wizję funkcjonowania systemu,
• czy istnieje już jakaś wersja systemu, którą będziemy wdrażać, czy występuje konieczność stworzenia go od podstaw?

Niezależnie jednak od stanu wymienionych cech, w tworzeniu analizy przedwdrożeniowej, trzeba zwykle przejść przez następujące etapy:

• Analiza danych wejściowych,
• „Odkrywanie” przyszłego rozwiązania,
• Opisywanie wymagań,
• Mapowanie i opis procesów biznesowych.

Analityk biznesowy rozpoczyna pracę od przejrzenia notatek w systemie CRM, służącym do zarządzania kontaktem z klientem. Dokumentacja ta stanowi istotne źródło informacji dla analityka.

Na ich podstawie analityk powinien zrozumieć kontekst dotychczasowej relacji z klientem, w tym:

• kiedy i jak został nawiązany kontakt,
• jak długo trwał kontakt z wybranym klientem,
• czy klient szybko zdecydował się na wdrożenie danego systemu,
• jak długo trwało podejmowanie decyzji,
• jakie były oczekiwania klienta co do przyszłego systemu,
• jakie aspekty przekonały klienta do współpracy,
• na co zwracał uwagę od początku kontaktów.

Jeśli w firmie dostawcy rozwiązania nie używa się systemu CRM, to analityk powinien zebrać te informacje w rozmowie z handlowcem.

Ważnym źródłem informacji dla analityka są również:

• oferta złożona klientowi,
• umowa,
• strona internetowa klienta .

Warto również poznać strukturę organizacyjną przedsiębiorstwa klienta, zidentyfikować decydentów, zrozumieć przebieg procesów biznesowych. Należy również zidentyfikować kluczowych konkurentów i zebrać główne informacje o ich działalności, pozycji rynkowej oraz wykorzystywanych rozwiązaniach IT.

Etap analizy danych wejściowych zostaje zwykle zakończony identyfikacją i analizą interesariuszy przygotowywanego rozwiązania IT. Interesariusze szukani są zarówno wewnątrz firmy klienta, jak również na zewnątrz. Interesariuszem jest również sam dostawca rozwiązania. Zwykle po zakończeniu wdrożenia systemu, rozpoczyna się bowiem jego utrzymanie i rozwój.

Z analizy interesariuszy powinno wprost wynikać kto będzie źródłem informacji, kto będzie testował wdrażany system i będzie podejmował decyzje związane z projektem i jego rezultatami.

Warsztaty Product Discovery zazwyczaj obejmują kilka moderowanych spotkań z interesariuszami projektu, w trakcie których dokładnie precyzuje się m.in.:

• wizję projektu,
• grupę docelową,
• potrzeby odbiorców,
• cele biznesowe,
• konkurencja,
• oczekiwania wobec systemu.

Na tym etapie zwykle mapuje się nazwy tzw. „user stories”, które w dalszych etapach zostaną użyte do opisu wymagań. Mapowanie oznacza przypisanie ich do poszczególnych modułów systemu oraz planowanych funkcjonalności. Tu określa się również, które z nich będą działać w pierwszej wersji systemu – na etapie jego uruchomienia – i będą stanowić tzw. „MVP” (Minimum Viable Product), a które zostaną dodane później, w procesie rozwoju systemu. Decyzja o zakresie MVP to zwykle kompromis pomiędzy oczekiwaniami klientów i wymogami funkcjonalności systemu, a harmonogramem i budżetem projektu zapisanym w umowie.

Częścią Product Discovery jest także określenie powiązań pomiędzy przygotowywanym systemem, a innymi systemami. Powiązania te przedstawione są na schemacie blokowym, zawierającym:

• nazwy powiązanych systemów,
• rodzaj transferowanych informacji,
• nazwy dokumentów,
• kierunek transferu.

Szczegółowe, techniczne powiązania rozpisuje później architekt systemu, używając, np. notacji „C4”.

Notacja C4 to sposób dokumentowania i przedstawiania architektury oprogramowania, który pomaga zrozumieć kontekst systemu oraz jego strukturę na różnych poziomach abstrakcji. Nazwa pochodzi od angielskich nazw poziomów abstrakcji, według których dzielone są  diagramy architektury:

• kontekst,
• kontenery,
• komponenty.

Notacja jest narzędziem mającym na celu ułatwienie komunikacji między zespołem projektowym, a interesariuszami, umożliwiając zrozumienie kompleksowości architektury systemu na różnych poziomach szczegółowości.

Pojedyncze „user story” najlepiej sformułować wg następującego schematu:

„JAKO ….. CHCĘ ….. ABY …..”

„Jako” określa kim jest użytkownik, „chcę” precyzuje co użytkownik chce zrobić w systemie, zaś „aby” wskazuje cel działania użytkownika w systemie.

Przykład user story w systemie Asiston WMS:

„Jako magazynier, chcę wiedzieć jaki towar ile i na jaką lokalizację mam przyjąć, aby prawidłowo obsłużyć przyjęcie towaru do magazynu”.

Deklarację uzupełnia zestaw bardziej szczegółowych wymagań dla systemu, zwany kryteriami akceptacji. Kryteria akceptacji określają warunki, które funkcjonalność musi spełnić, aby „user story” zostało zrealizowane, zgodnie z tym, co chce klient. Kryteria akceptacji pozwalają przełożyć „user story” na zadania techniczne.

Przykład kryteriów akceptacji dla user story, napisanego wyżej:

1. Magazynier widzi listę dokumentów przyjęcia magazynowego, wraz z ich aktualnymi statusami.
2. Magazynier może:
   1. wybrać z listy dokument ze statusem „Oczekuje na przyjęcie”,
   2. wejść w szczegóły dokumentu i rozpocząć jego obsługę
3. Po wejściu do widoku szczegółów dokumentu, jego status zmienia się na „W przygotowaniu”,
4. W szczegółach dokumentu przyjęcia magazynier widzi: listę towarów, zawierającą:
   1. nazwę,
   2. ilość,
   3. kod towarowy (kreskowy),                                                                                                                                                                                                                                                                                                                                                           a także kod lokalizacji magazynowej, na którą towar ma być przyjęty.

Jeśli system, który przygotowujemy do wdrożenia, istnieje już w wersji podstawowej lub demonstracyjnej i jego wybrane funkcjonalności będą zastosowane u klienta w niezmienionej formie, to user stories, mogą być zastąpione widokami ekranów, wraz z opisem sposobu poruszania się w nich, w ramach danej funkcjonalności.

Procesy przedstawia się zwykle w dwóch uzupełniających się formach:

• diagram procesu – najczęściej w notacji BPMN,
• opis procesu z wykorzystaniem metody przypadków użycia – „Use case”.

Użycie notacji BPMN do projektowania i wizualizacji procesów, pozwala:

• dokładnie przemyśleć co się dzieje w procesie i zweryfikować pomysł na jego przebieg,
• przejrzyście odzwierciedlić proces, na różnych poziomach szczegółowości,
• wyodrębnić i pokazać różne rodzaje przepływów w procesie,
• zaimplementować diagram procesu bezpośrednio do oprogramowania, przystosowanego do jego obsługi,
• zrozumieć się lepiej z interesariuszami.

Standard BPMN zawiera również reguły użycia poszczególnych elementów graficznych, w tym: miejsc realizacji, obiektów przepływu, danych, połączeń i artefaktów.

W opisie przypadków użycia „Use cases” pokazujemy:

• aktora głównego,
• zakres,
• poziom,
• uczestników i ich interesy,
• warunek początkowy,
• wyzwalacz,
• główny scenariusz powodzenia,
• rozszerzenia (możliwe odstępstwa od głównego scenariusza).

Struktura analizy przedwdrożeniowej, wykonanej w konkretnym projekcie, ze względu na jego specyfikę, może się różnić od przedstawionej wyżej. W każdym projekcie potwierdza się jednak reguła, że im staranniej zrobimy analizę przedwdrożeniową, tym docelowe rozwiązanie będzie bardziej funkcjonalne i dopasowane do potrzeb klienta, a sam projekt będzie miał realną szansę zmieścić się w zakładanym harmonogramie i budżecie.