Analiza przedwdrożeniowa: jak ją przeprowadzić i co zawiera

Wdrożenie miało trwać cztery miesiące. Trwa dziesiąty. Na stole leży aneks numer trzy, a dostawca i klient przerzucają się mailami o to, czy "obsługa reklamacji" była w zakresie, czy nie. Nie dlatego, że ktoś działał w złej wierze. Dlatego, że umowę podpisano na podstawie prezentacji handlowej, a nie analizy tego, jak firma naprawdę pracuje.

Analiza przedwdrożeniowa istnieje po to, żeby ten scenariusz się nie wydarzył. W tym artykule dostajesz komplet: zakres, plan tydzień po tygodniu, strukturę dokumentu do skopiowania i checklistę gotowości. Wszystko z perspektywy analityka biznesowego, bo to on tę robotę zwykle wykonuje.

Czym jest analiza przedwdrożeniowa i dlaczego wdrożenia bez niej kończą się aneksami do umowy

Analiza przedwdrożeniowa to etap PRZED zobowiązaniem się do zakresu, budżetu i terminu. Jej zadanie: zbadać, jak organizacja działa dzisiaj (procesy AS-IS), czego potrzebuje jutro (wymagania), co system musi umieć, z czym się integrować i jakie dane trzeba przenieść. Efektem jest dokument, na podstawie którego da się rzetelnie wycenić i zaplanować wdrożenie.

Bez niej dzieje się zawsze to samo. Dostawca wycenia "systemowo": tyle modułów, tyle licencji, standardowy czas. Klient podpisuje, bo cena wygląda dobrze. A potem, w trzecim tygodniu wdrożenia, wychodzi na jaw, że dział sprzedaży ma cztery różne warianty procesu ofertowania, magazyn pracuje na Excelu, którego nikt nie wspominał, a "prosta integracja z księgowością" to system pisany na zamówienie w 2011 roku, do którego nie ma dokumentacji.

Każde takie odkrycie to change request. Każdy change request to negocjacje, dopłata, przesunięcie terminu. Stąd aneksy.

Moje zdanie jest proste: wycena wdrożenia bez analizy to zgadywanie z fakturą. Jeśli dostawca proponuje Ci stały budżet bez etapu analizy, to znaczy, że ryzyko nieznanego zakresu wliczył w cenę (płacisz za bufor) albo przerzuci je na Ciebie aneksami. Trzeciej opcji nie ma.

Zakres analizy: procesy AS-IS, wymagania, integracje, migracja danych, role

Dobra analiza przedwdrożeniowa pokrywa pięć obszarów. Pominięcie któregokolwiek z nich to dziura, która wypłynie w trakcie wdrożenia.

Procesy AS-IS

Jak praca wygląda NAPRAWDĘ, nie jak wygląda w procedurach. Mapujesz procesy objęte wdrożeniem (BPMN sprawdza się najlepiej, ale czytelny diagram w dowolnej notacji bije nieczytelny standard). Dla każdego procesu notujesz:

• kroki, decyzje i wyjątki (wyjątki są ważniejsze niż happy path - to one generują koszty),
• kto wykonuje który krok i w jakim systemie,
• wolumeny: ile faktur miesięcznie, ile zamówień dziennie, ile reklamacji,
• wąskie gardła i obejścia ("to robimy w Excelu, bo system nie umie").

Wymagania

Z procesów AS-IS i rozmów o potrzebach wyprowadzasz wymagania: funkcjonalne (co system ma robić) i niefunkcjonalne (wydajność, dostępność, bezpieczeństwo, liczba użytkowników). Każde wymaganie dostaje priorytet - MoSCoW (Must/Should/Could/Won't) działa dobrze, bo zmusza do decyzji, co NIE wchodzi w pierwszą fazę.

Integracje

Lista systemów, z którymi nowe rozwiązanie ma rozmawiać. Dla każdej integracji: kierunek przepływu danych, częstotliwość (real-time czy paczka nocna), format, właściciel systemu po stronie klienta i stan dokumentacji. To ostatnie brzmi banalnie, a bywa najdroższym odkryciem całego projektu.

Migracja danych

Skąd dane przyjdą, w jakim są stanie i kto podejmie decyzje o czyszczeniu. Zapytaj o duplikaty klientów, o rekordy bez wymaganych pól, o dane historyczne (migrujemy 10 lat czy 2 lata?). Ustal zasadę: jakość danych to odpowiedzialność klienta, mapowanie i mechanizm migracji to odpowiedzialność wykonawcy. Zapisz to w dokumencie.

Role i uprawnienia

Kto będzie pracował w systemie, w jakich rolach, z jakimi uprawnieniami. Macierz ról do funkcji wystarczy. Przy okazji wyjdzie, czy klient ma w ogóle ludzi do utrzymania systemu po wdrożeniu.

Plan tydzień po tygodniu: warsztaty, wywiady, przegląd systemów (agenda do skopiowania)

Dla średniego wdrożenia (jeden obszar biznesowy, kilka działów) realny czas analizy to 3-5 tygodni. Poniżej wariant czterotygodniowy - skaluj w górę lub w dół według liczby procesów.

Tydzień 1 - rozpoznanie:

• kickoff (2h): cele biznesowe wdrożenia, lista interesariuszy, logistyka warsztatów, ustalenie decydenta po stronie klienta,
• zebranie dokumentów: procedury, instrukcje, przykładowe dokumenty z procesu (faktura, zamówienie, protokół),
• przegląd obecnych systemów (po 1-2h na system, z użytkownikiem przy ekranie, nie z prezentacją),
• wywiady 1:1 z szefami działów (po 45-60 min).

Tydzień 2 - warsztaty procesowe AS-IS. Sprawdzona agenda pojedynczego warsztatu (3h, jeden proces, 4-7 osób, w tym ludzie którzy proces WYKONUJĄ, nie tylko nim zarządzają):

1. 0:00-0:15 - cel warsztatu, zasady, słownik pojęć
2. 0:15-1:15 - przejście procesu krok po kroku ("co się dzieje od momentu X do momentu Y"), rysowanie na żywo
3. 1:15-1:30 - przerwa
4. 1:30-2:15 - wyjątki i warianty ("a co, jeśli klient odeśle towar?", "a jak to wygląda na koniec miesiąca?")
5. 2:15-2:45 - bolączki i oczekiwania wobec nowego systemu
6. 2:45-3:00 - podsumowanie ustaleń i otwartych pytań, kto dostarcza brakujące informacje i do kiedy

Dwa warsztaty dziennie to maksimum, przy którym notatki nadal coś znaczą. Trzeci robisz już na autopilocie.

Tydzień 3 - wymagania i technikalia:

• warsztaty TO-BE: jak procesy mają wyglądać w nowym systemie (tu zaczynają się decyzje: dopasowujemy system do procesu czy proces do systemu),
• sesja integracyjna z IT klienta: systemy, interfejsy, dokumentacja, środowiska,
• sesja o danych: źródła, jakość, zakres migracji,
• spisanie i priorytetyzacja wymagań.

Tydzień 4 - walidacja i domknięcie:

• wysyłka draftu dokumentu do przeglądu,
• sesja walidacyjna (2-3h): przejście przez wymagania Must i sporne punkty,
• korekty, wycena, harmonogram,
• prezentacja końcowa dla decydenta.

Produkt końcowy: struktura dokumentu analizy rozdział po rozdziale (szablon)

Struktura, którą możesz wziąć jak leci:

1. Streszczenie dla zarządu (1-2 strony) - cele, rekomendowany zakres, budżet, termin, główne ryzyka. Jedyny rozdział, który przeczyta każdy.
2. Cele biznesowe i mierniki - po co to wdrożenie i po czym poznamy, że się udało (konkretne mierniki, np. czas obsługi zamówienia).
3. Zakres i wyłączenia - co wchodzi, a co JAWNIE nie wchodzi. Sekcja wyłączeń jest warta więcej niż cała reszta, bo to o nią toczą się spory przy aneksach.
4. Procesy AS-IS - diagramy + opis, wolumeny, bolączki.
5. Procesy TO-BE - jak będzie po wdrożeniu, z zaznaczonymi zmianami organizacyjnymi (nie tylko systemowymi).
6. Wymagania - tabela: ID, treść, priorytet, źródło (kto zgłosił), sposób realizacji (standard systemu / konfiguracja / modyfikacja). Przykładowy wiersz: WYM-042 | "System blokuje wysyłkę zamówienia po przekroczeniu limitu kredytowego klienta" | Must | kierownik sprzedaży | konfiguracja. Ta ostatnia kolumna napędza wycenę.
7. Integracje - lista z kierunkami, częstotliwością i właścicielami.
8. Migracja danych - zakres, źródła, odpowiedzialności, znane problemy jakościowe.
9. Role i uprawnienia - macierz.
10. Ryzyka i decyzje - rejestr ryzyk z właścicielami oraz lista decyzji podjętych w trakcie analizy (kto, kiedy, co postanowił). Bez tego za pół roku nikt nie pamięta, dlaczego coś zrobiono tak, a nie inaczej.
11. Wycena i harmonogram - patrz niżej.
12. Załączniki - notatki z warsztatów, słownik pojęć, przykładowe dokumenty.

Objętość? Tyle, ile trzeba, ale pisz pod czytanie wyrywkowe: ludzie wchodzą do konkretnego rozdziału po jedną rzecz i wychodzą.

Od analizy do wyceny i harmonogramu - jak uniknąć widełek z sufitu

Widełki "od 200 do 600 tysięcy" mówią klientowi tylko tyle, że wykonawca nie wie, co wycenia. Analiza pozwala zejść do wyceny, którą da się bronić:

• Estymuj per wymaganie, nie per moduł. Kolumna "sposób realizacji" z tabeli wymagań robi robotę: standard kosztuje konfigurację, modyfikacja kosztuje development. Suma daje wycenę, którą można pokazać pozycja po pozycji.
• Bufor tylko na nazwane ryzyka. Zamiast "+30% na wszelki wypadek" - konkretny zapas przypisany do konkretnego ryzyka z rejestru ("integracja z systemem X bez dokumentacji: +N dni"). Jeśli ryzyko nie wystąpi, bufor się nie spala i wszyscy to widzą.
• Tnij zakres w wersje, nie w jakość. Jeśli budżet nie domyka się z wymaganiami Should, przenieś je do fazy 2 zamiast obiecywać wszystko taniej. Zakres fazowany to normalna praktyka; "zrobimy wszystko, jakoś to będzie" to plan aneksu.
• Harmonogram wiąż z dostępnością klienta. Najczęstszy powód obsuwy nie leży po stronie wykonawcy, tylko w czekaniu na decyzje i dane. Wpisz do harmonogramu terminy odpowiedzi klienta i konsekwencje ich przekroczenia.

Najczęstsze błędy: pomijanie AS-IS, brak decydenta, analiza pisana po podpisaniu umowy

Pomijanie AS-IS, bo "przecież wdrażamy nowy system, po co patrzeć na stary". Po to, że w AS-IS siedzą wyjątki, wolumeny i obejścia, których nikt nie zgłosi na warsztacie o przyszłości. Ludzie opowiadają o tym, czego chcą; o tym, co robią naprawdę, trzeba się dowiedzieć osobno.

Brak decydenta po stronie klienta. Warsztat mówi jedno, dyrektor tydzień później drugie, a Ty masz trzy wersje wymagania i zero rozstrzygnięcia. Zanim zaczniesz analizę, ustal jedną osobę z mandatem do podejmowania decyzji i wpisz ją do dokumentu. Serio, bez tej jednej osoby nie startuj.

Analiza pisana po podpisaniu umowy. Wtedy nie jest już analizą przedwdrożeniową, tylko dokumentacją powykonawczą zakresu, który i tak wynegocjowano w ciemno. Cała jej wartość, czyli wpływ na wycenę i granice zakresu, przepada.

Do kompletu trzy mniejsze, ale częste:

• warsztaty tylko z kierownikami - kierownik zna proces z raportów, wyjątki zna osoba, która klepie to codziennie,
• brak wolumenów - proces obsługiwany 5 razy w miesiącu i 500 razy dziennie to dwa różne wymagania wydajnościowe,
• dokument bez sekcji wyłączeń - wszystko, czego nie wykluczysz na piśmie, klient ma prawo uznać za wliczone.

Techniki, które tu pracują (warsztaty, wywiady, obserwacja, analiza dokumentów, prototypowanie), to standardowy warsztat elicytacji analityka biznesowego. Jeśli chcesz je poukładać w całość, zajrzyj do artykułu o technikach zbierania wymagań - analiza przedwdrożeniowa to w praktyce ich najbardziej skondensowane zastosowanie.

Checklista gotowości do wdrożenia + rola BA w całym procesie

Zanim ktokolwiek podpisze umowę wdrożeniową, odhacz:

• [ ] Procesy AS-IS zmapowane, z wyjątkami i wolumenami
• [ ] Procesy TO-BE uzgodnione i zaakceptowane przez biznes
• [ ] Wymagania spisane, spriorytetyzowane, z określonym sposobem realizacji
• [ ] Sekcja wyłączeń istnieje i klient ją widział
• [ ] Wszystkie integracje zinwentaryzowane, stan dokumentacji znany
• [ ] Zakres migracji danych ustalony, odpowiedzialność za jakość danych przypisana
• [ ] Macierz ról i uprawnień gotowa
• [ ] Rejestr ryzyk ma właścicieli, rejestr decyzji jest prowadzony
• [ ] Wycena rozbita na pozycje, bufory przypisane do nazwanych ryzyk
• [ ] Decydent po stronie klienta wskazany imiennie
• [ ] Harmonogram zawiera zobowiązania klienta (decyzje, dane, ludzie)
• [ ] Dokument formalnie zaakceptowany PRZED podpisaniem umowy na wdrożenie

Jeśli choć dwa punkty są na "nie", wdrożenie wystartuje z długiem, który oddasz z odsetkami w aneksach.

I na koniec o roli analityka. Analiza przedwdrożeniowa to jedno z zadań, w których BA jest najbardziej widoczny: prowadzi warsztaty, modeluje procesy, pisze wymagania, negocjuje zakres między biznesem a wykonawcą. Firmy wdrożeniowe regularnie szukają ludzi właśnie do tej roboty - zerknij na barometr rynku pracy BA, żeby zobaczyć, jakie kompetencje pojawiają się w ogłoszeniach. A jeśli dopiero celujesz w ten zawód i zastanawiasz się, jak przejść do niego z obecnej roli, sprawdź ścieżki przebranżowienia na analityka - prowadzenie analizy przedwdrożeniowej to dokładnie ten poziom, do którego te ścieżki prowadzą.

Samo czytanie o warsztatach nie nauczy Cię ich prowadzić. Trzeba mapować procesy, pisać wymagania i dostawać feedback. Jeśli chcesz trenować na realistycznych zadaniach zamiast na teorii, załóż darmowe konto na Analify i sprawdź, jak wygląda nauka przez praktykę.