Analiza przedwdrożeniowa systemu IT – co powinna obejmować i co przekazać wykonawcy?

Analiza przedwdrożeniowa porządkuje procesy, wymagania, dane, integracje i odpowiedzialności, zanim organizacja podpisze umowę lub rozpocznie kosztowne wdrożenie nowego systemu IT.

Wdrożenie ERP, CRM, WMS, systemu obiegu dokumentów, rozwiązania AI albo dedykowanej aplikacji zwykle zaczyna się od potrzeby biznesowej. Firma chce ograniczyć pracę ręczną, skrócić czas obsługi, połączyć kilka systemów, poprawić kontrolę nad procesem albo zastąpić rozwiązanie, które przestało odpowiadać skali działalności.

Problem pojawia się wtedy, gdy ogólna potrzeba zostaje zbyt szybko zamieniona w zapytanie do dostawców. Organizacja przedstawia kilka zdań opisu, wykonawcy przygotowują oferty na podstawie własnych założeń, a szczegółowe decyzje są odkładane do czasu realizacji projektu.

Na początku może się wydawać, że takie podejście przyspiesza wdrożenie. W praktyce często prowadzi do rozbieżnych wycen, sporów o zakres, dodatkowych kosztów i sytuacji, w której każda ze stron inaczej rozumie oczekiwany rezultat.

Dobra analiza przedwdrożeniowa nie jest dokumentem tworzonym do szuflady. Ma doprowadzić do sytuacji, w której wiadomo, co ma zostać wdrożone, po co, dla kogo, w jakim zakresie i po czym poznamy, że rozwiązanie działa poprawnie.

Czym jest analiza przedwdrożeniowa?

Analiza przedwdrożeniowa to uporządkowanie wiedzy potrzebnej do zaplanowania i przeprowadzenia wdrożenia systemu. Łączy perspektywę biznesową, procesową i techniczną.

Jej zadaniem jest między innymi ustalenie:

• jaki problem biznesowy ma zostać rozwiązany,
• jak organizacja pracuje obecnie,
• jak powinien wyglądać proces docelowy,
• kto uczestniczy w procesie i podejmuje decyzje,
• jakie dane są potrzebne,
• które systemy będą uczestniczyć w rozwiązaniu,
• jakie integracje są konieczne,
• jakie wymagania musi spełnić system,
• jak będą obsługiwane wyjątki i błędy,
• jak rozwiązanie zostanie przetestowane i odebrane,
• jak podzielić wdrożenie na bezpieczne etapy.

Analiza nie musi od razu opisywać każdego ekranu i każdego pola. Poziom szczegółowości powinien zależeć od celu projektu, sposobu wyboru wykonawcy i ryzyka związanego z wdrożeniem.

Innego zakresu potrzebuje firma wybierająca standardowy system dla kilkunastu użytkowników, a innego organizacja wdrażająca rozwiązanie obejmujące wiele departamentów, integracje, migrację danych i kilku wykonawców.

Kiedy analiza przedwdrożeniowa jest potrzebna?

Nie każde wdrożenie wymaga wielomiesięcznej analizy. Jeżeli firma wybiera proste narzędzie, korzysta głównie ze standardowych funkcji i nie potrzebuje rozbudowanych integracji, wystarczające może być krótkie rozpoznanie potrzeb oraz poprawna konfiguracja.

Pełniejsza analiza staje się szczególnie ważna, gdy:

• projekt obejmuje kilka działów lub lokalizacji,
• system ma obsługiwać kluczowy proces organizacji,
• występuje wiele ról, akceptacji i wyjątków,
• rozwiązanie ma wymieniać dane z innymi systemami,
• planowana jest migracja danych,
• konfiguracja standardowa może nie pokrywać wszystkich potrzeb,
• organizacja przygotowuje zapytanie ofertowe lub postępowanie zakupowe,
• wykonawca wygrał projekt, ale szczegóły procesu nie zostały jeszcze uzgodnione,
• projekt już trwa, lecz pojawiają się spory o zakres,
• koszt błędnej decyzji może być znacznie wyższy niż koszt przygotowania analizy.

Analiza może więc powstać przed wyborem systemu, przed wyborem wykonawcy, po podpisaniu umowy albo podczas naprawy projektu, który utknął. W każdym z tych momentów ma jednak nieco inny cel.

Moment projektu	Główny cel analizy
Przed wyborem systemu	Ustalenie potrzeb i porównanie możliwych wariantów rozwiązania
Przed wyborem wykonawcy	Przygotowanie zakresu możliwego do rzetelnej wyceny
Po wyborze wykonawcy	Doprecyzowanie procesów, konfiguracji, integracji i etapów realizacji
Podczas trudnego wdrożenia	Rozdzielenie błędów, braków konfiguracji, luk wymagań i zmian zakresu

Najpierw cel biznesowy, później wybór systemu

Analiza nie powinna zaczynać się od listy funkcji dostępnych w konkretnym produkcie. Najpierw trzeba ustalić, jaki efekt organizacja chce osiągnąć.

Ogólne stwierdzenia, takie jak „potrzebujemy nowego ERP”, „chcemy elektroniczny obieg dokumentów” albo „musimy wdrożyć AI”, nie opisują jeszcze celu projektu.

Cel powinien odnosić się do problemu lub mierzalnej zmiany. Może nim być na przykład:

• ograniczenie wielokrotnego przepisywania tych samych danych,
• skrócenie czasu obsługi wniosku,
• zapewnienie widoczności aktualnego statusu sprawy,
• automatyczne przekazywanie danych pomiędzy systemami,
• zmniejszenie liczby dokumentów obsługiwanych poza systemem,
• uporządkowanie procesu akceptacji,
• ograniczenie błędów wynikających z ręcznej pracy,
• przygotowanie organizacji do obsługi większej liczby klientów lub spraw,
• uzyskanie danych potrzebnych do raportowania i podejmowania decyzji.

Dopiero po określeniu celu można ocenić, czy potrzebny jest nowy system, rozbudowa obecnego rozwiązania, dodatkowa integracja, zmiana procesu albo lepsze wykorzystanie funkcji, które firma już posiada.

Prezentacja systemu pokazuje, co potrafi produkt. Analiza przedwdrożeniowa ma ustalić, czego naprawdę potrzebuje organizacja.

Kto powinien uczestniczyć w analizie?

Wiedza o procesie rzadko znajduje się w jednym miejscu. Kierownictwo zna cele i ograniczenia organizacji, pracownicy znają rzeczywisty przebieg pracy, dział IT zna systemy i infrastrukturę, a wykonawca zna możliwości proponowanego rozwiązania.

W zależności od projektu w analizie mogą uczestniczyć:

• sponsor lub właściciel biznesowy projektu,
• właściciele analizowanych procesów,
• kierownicy komórek organizacyjnych,
• pracownicy wykonujący codzienne czynności,
• dział IT i administratorzy systemów,
• bezpieczeństwo informacji i ochrona danych,
• księgowość, kadry, logistyka lub inne zespoły dziedzinowe,
• przedstawiciele wykonawcy,
• analityk prowadzący warsztaty i przygotowujący dokumentację.

Analityk nie powinien zastępować osób merytorycznych w podejmowaniu decyzji. Jego rolą jest zebranie wiedzy, wskazanie niejasności, uporządkowanie wariantów i zapisanie decyzji w sposób zrozumiały dla organizacji oraz wykonawcy.

Mapa procesu AS-IS: jak organizacja pracuje obecnie?

Jednym z pierwszych produktów analizy może być mapa procesu obecnego, określana jako AS-IS. Jej celem nie jest pokazanie procedury idealnej, ale rzeczywistego sposobu pracy.

Proces opisany w regulaminie lub instrukcji może różnić się od procesu wykonywanego przez pracowników. Część działań może odbywać się przez e-mail, arkusze kalkulacyjne, rozmowy telefoniczne albo notatki przechowywane poza głównym systemem.

Przykładem może być obsługa wewnętrznego wniosku o zakup produktu lub usługi.

W procesie obecnym pracownik wysyła wniosek e-mailem do przełożonego. Po uzyskaniu zgody dokument jest przekazywany do finansów, a następnie do zespołu zakupowego. Status jest sprawdzany przez kolejne wiadomości i telefony, natomiast dane są ponownie przepisywane do arkusza oraz systemu finansowego.

Podczas analizy procesu obecnego warto ustalić:

• co rozpoczyna proces,
• kto wykonuje poszczególne czynności,
• jakie dane i dokumenty są potrzebne,
• gdzie informacje są zapisywane,
• ile razy te same dane są przepisywane,
• gdzie występują oczekiwanie i przestoje,
• które decyzje wymagają akceptacji,
• jak obsługiwane są wyjątki,
• jak pracownicy sprawdzają aktualny status,
• jakie błędy i problemy występują najczęściej.

Mapa AS-IS nie powinna jednak stać się dokładnym odwzorowaniem każdego ruchu wykonywanego przez pracownika. Jej poziom szczegółowości powinien pozwalać zrozumieć proces, problemy i zależności istotne dla projektowanego systemu.

Proces TO-BE: jak powinna wyglądać praca po wdrożeniu?

Proces docelowy, czyli TO-BE, nie powinien polegać wyłącznie na przeniesieniu obecnych kroków do nowego systemu. Wdrożenie jest okazją do ograniczenia zbędnych czynności, uporządkowania odpowiedzialności i automatyzacji wybranych etapów.

W przykładzie wniosku zakupowego proces docelowy może wyglądać następująco:

1. pracownik wypełnia formularz w portalu,
2. system sprawdza kompletność wymaganych danych,
3. wniosek otrzymuje jednoznaczny numer i status,
4. ścieżka akceptacji jest wybierana na podstawie kwoty, kategorii i jednostki organizacyjnej,
5. przełożony zatwierdza, odrzuca albo zwraca wniosek do uzupełnienia,
6. finanse potwierdzają dostępność budżetu,
7. zaakceptowany wniosek jest przekazywany do zespołu zakupowego lub systemu ERP,
8. status realizacji wraca do portalu,
9. wnioskodawca otrzymuje informacje o zmianach statusu,
10. historia decyzji pozostaje dostępna do kontroli i raportowania.

Proces docelowy powinien pokazywać nie tylko kolejne czynności. Powinien również wskazywać:

• role i odpowiedzialności,
• warunki podejmowania decyzji,
• wymagane dane,
• statusy procesu,
• zdarzenia uruchamiające kolejne kroki,
• integracje z innymi rozwiązaniami,
• komunikaty dla użytkowników,
• obsługę sytuacji wyjątkowych.

Od procesu do wymagań funkcjonalnych

Mapa procesu nie jest jeszcze kompletną specyfikacją systemu. Trzeba przełożyć ją na wymagania opisujące zachowanie rozwiązania.

Słabe wymaganie brzmi na przykład:

System ma obsługiwać wnioski zakupowe.

Takie zdanie nie mówi wykonawcy, jakie dane zawiera wniosek, kto go zatwierdza, co ma się wydarzyć po akceptacji ani jak obsługiwać sytuacje wyjątkowe.

Bardziej użyteczny opis może wyglądać następująco:

Po zapisaniu kompletnego wniosku system nadaje mu unikalny numer i status „Oczekuje na akceptację”.

Ścieżka akceptacji jest wybierana na podstawie wartości wniosku, jednostki organizacyjnej i kategorii zakupu.

Osoba akceptująca może zatwierdzić wniosek, odrzucić go albo zwrócić do uzupełnienia z obowiązkowym komentarzem.

Po zatwierdzeniu przez wszystkie wymagane osoby system przekazuje dane wniosku do ERP.

ERP zwraca identyfikator utworzonego zapotrzebowania albo opis błędu. Ponowienie operacji nie może utworzyć duplikatu.

Aktualny status realizacji jest widoczny dla wnioskodawcy i osób uczestniczących w procesie.

Na podstawie takiego opisu wykonawca może ocenić, czy wymaganie pokrywa standardowa konfiguracja, czy potrzebna jest rozbudowa systemu lub dodatkowa integracja.

Dobre wymaganie powinno być:

• jednoznaczne,
• możliwe do zweryfikowania,
• powiązane z procesem i celem biznesowym,
• zrozumiałe dla organizacji oraz wykonawcy,
• wystarczająco szczegółowe do wyceny i testów.

Dane i integracje muszą mieć właściciela

W projektach obejmujących kilka systemów jednym z najważniejszych pytań jest wskazanie źródła danych.

Organizacja powinna ustalić między innymi:

• w którym systemie utrzymywane są dane pracowników, klientów, produktów lub jednostek organizacyjnych,
• który system może zmieniać dane,
• które systemy tylko odczytują informacje,
• jak często dane są synchronizowane,
• co inicjuje wymianę danych,
• jak identyfikowane są rekordy,
• jak obsługiwane są błędy i ponowienia,
• jak zapobiegać tworzeniu duplikatów,
• jaki status wraca do systemu źródłowego,
• kto odpowiada za rozwiązanie problemu operacyjnego.

Samo stwierdzenie, że systemy mają zostać „połączone przez API”, nie opisuje integracji. API jest mechanizmem technicznym. Projekt nadal wymaga określenia procesu, danych, kierunków komunikacji, odpowiedzialności i oczekiwanego rezultatu.

Wymagania niefunkcjonalne nie mogą zostać na koniec

Organizacje często koncentrują się na funkcjach widocznych dla użytkownika. Tymczasem o przydatności rozwiązania decydują również wymagania niefunkcjonalne.

Mogą one obejmować:

• liczbę użytkowników i przewidywane obciążenie,
• czas odpowiedzi systemu,
• dostępność i godziny pracy rozwiązania,
• zasady uwierzytelniania i nadawania uprawnień,
• rejestrowanie operacji użytkowników,
• wymagania bezpieczeństwa i ochrony danych,
• wykonywanie kopii bezpieczeństwa,
• odtwarzanie systemu po awarii,
• retencję i archiwizację danych,
• dostępność dla osób ze szczególnymi potrzebami,
• monitorowanie integracji,
• środowiska testowe i produkcyjne,
• zasady aktualizacji i utrzymania rozwiązania.

Jeżeli wymagania te pojawią się dopiero przed odbiorem, mogą wymagać zmian architektury, infrastruktury albo sposobu działania systemu.

Role, odpowiedzialności i decyzje projektowe

Nawet najlepsza dokumentacja nie zastąpi właścicieli decyzji. Projekt powinien mieć jasno określone role po stronie organizacji i wykonawcy.

Trzeba ustalić:

• kto zatwierdza proces docelowy,
• kto akceptuje wymagania,
• kto podejmuje decyzje dotyczące zakresu,
• kto dostarcza dane i materiały,
• kto odpowiada za konfigurację, integrację i migrację,
• kto przygotowuje oraz wykonuje testy,
• kto zatwierdza rezultat,
• jak rozstrzygane są rozbieżności,
• jak zarządza się zmianami zakresu.

Brak właściciela decyzji prowadzi do sytuacji, w której warsztaty kończą się listą nierozstrzygniętych tematów. Wykonawca przyjmuje własne założenia albo wstrzymuje prace, a projekt traci czas.

Co powinien otrzymać wykonawca?

Wykonawca nie zawsze musi otrzymać jeden rozbudowany dokument. Bardziej praktyczny jest zestaw powiązanych materiałów, które można aktualizować podczas projektu.

W zależności od skali wdrożenia mogą to być:

• opis celu i zakresu projektu,
• lista interesariuszy i właścicieli procesów,
• mapy procesów AS-IS,
• mapy procesów TO-BE,
• katalog problemów i potrzeb biznesowych,
• lista wymagań funkcjonalnych,
• wymagania niefunkcjonalne,
• opis ról i uprawnień,
• katalog danych i źródeł informacji,
• opis integracji i kierunków komunikacji,
• założenia migracji danych,
• reguły biznesowe i obsługa wyjątków,
• scenariusze użycia,
• scenariusze testowe,
• kryteria odbioru,
• plan pilotażu i kolejnych etapów wdrożenia,
• rejestr ryzyk, założeń i decyzji projektowych.

Materiały powinny być dostosowane do sposobu realizacji projektu. Inaczej wygląda dokumentacja dla zakupu gotowego produktu, inaczej dla konfiguracji systemu, a jeszcze inaczej dla budowy dedykowanej aplikacji.

Wymagania muszą prowadzić do testów i odbioru

Wymaganie, którego nie można sprawdzić, będzie trudne do jednoznacznego odebrania. Dlatego już podczas analizy warto ustalić, jak zostanie zweryfikowane działanie rozwiązania.

Każde kluczowe wymaganie powinno prowadzić do scenariusza testowego i kryterium odbioru.

Przykładowy łańcuch może wyglądać tak:

Cel biznesowy:
Skrócenie obsługi wniosku i zapewnienie widoczności statusu.

Proces:
Złożenie wniosku → akceptacja → kontrola budżetu → przekazanie do ERP.

Wymaganie:
System wybiera ścieżkę akceptacji na podstawie wartości wniosku.

Test:
Użytkownik składa dwa wnioski o różnych wartościach.

Oczekiwany wynik:
Każdy wniosek trafia do właściwej ścieżki akceptacji.

Kryterium odbioru:
Dla wszystkich uzgodnionych progów system poprawnie wybiera osoby akceptujące.

Takie podejście pomaga również podczas zmian. Jeżeli pojawia się nowe wymaganie, można sprawdzić, z jakiego celu wynika, które procesy zmienia i jakie testy trzeba zaktualizować.

Pilotaż zamiast jednego dużego uruchomienia

W większych projektach analiza powinna wskazywać rozsądny zakres pierwszego uruchomienia. Próba jednoczesnego wdrożenia wszystkich procesów, integracji i grup użytkowników zwiększa ryzyko.

Pilotaż może objąć:

• jeden reprezentatywny proces,
• wybraną komórkę lub lokalizację,
• ograniczoną grupę użytkowników,
• najważniejsze integracje,
• pełną ścieżkę od rozpoczęcia procesu do jego zakończenia.

Pilotaż powinien mieć jasno określone kryteria zakończenia. Samo uruchomienie systemu nie oznacza jeszcze, że rozwiązanie jest gotowe do rozszerzenia na całą organizację.

Po pilotażu można ocenić:

• czy proces docelowy jest praktyczny,
• czy wymagania były kompletne,
• jakie wyjątki pojawiły się w rzeczywistej pracy,
• czy integracje działają stabilnie,
• czy użytkownicy rozumieją nowe zasady,
• jakiej pracochłonności wymagają kolejne etapy.

Najczęstsze błędy analizy przedwdrożeniowej

Analiza może nie spełnić swojej roli, jeżeli zostanie potraktowana jako formalność. Do częstych problemów należą:

• rozpoczęcie od prezentacji funkcji wybranego produktu,
• brak jednoznacznego celu biznesowego,
• rozmowy wyłącznie z kierownictwem albo wyłącznie z użytkownikami,
• opisanie procedury zamiast rzeczywistego sposobu pracy,
• bezrefleksyjne przenoszenie obecnego procesu do nowego systemu,
• brak decyzji o źródłach danych,
• ogólne wymagania, których nie da się przetestować,
• pominięcie wymagań niefunkcjonalnych,
• brak opisu błędów, wyjątków i ponowień,
• brak właścicieli decyzji,
• przygotowanie setek diagramów bez ustalonego celu,
• brak powiązania wymagań z testami i odbiorem,
• założenie, że wszystkie szczegóły zostaną ustalone podczas konfiguracji.

Największym zagrożeniem nie jest brak bardzo szczegółowej dokumentacji. Jest nim brak wspólnego rozumienia procesu, zakresu i odpowiedzialności.

Analiza po stronie organizacji i po stronie wykonawcy

Analiza przedwdrożeniowa może być potrzebna zarówno organizacji zamawiającej system, jak i firmie, która wygrała wdrożenie.

Wsparcie organizacji

Po stronie organizacji analiza pomaga przygotować zakres, uporządkować potrzeby i świadomie rozmawiać z dostawcami. Może być podstawą do zapytania ofertowego, wyboru rozwiązania, negocjacji zakresu i późniejszego odbioru prac.

Wsparcie wykonawcy

Firma wdrożeniowa może znać technologię, ale nadal potrzebować wsparcia w rozpoznaniu procesów klienta, prowadzeniu warsztatów, przygotowaniu dokumentacji i doprecyzowaniu wymagań.

Dobra analiza zmniejsza liczbę założeń, ułatwia estymację oraz pozwala wcześniej zidentyfikować elementy wykraczające poza standard systemu.

Niezależna diagnoza trudnego wdrożenia

Analiza może również pomóc, gdy projekt już trwa. W takim przypadku warto rozdzielić:

• błędy systemu,
• braki konfiguracji,
• niezrealizowane wymagania,
• potrzeby, które nie zostały wcześniej opisane,
• zmiany zakresu,
• problemy wynikające z obecnego procesu organizacji.

Rezultatem może być plan naprawczy obejmujący priorytety, odpowiedzialności, decyzje i kolejność dalszych prac.

Minimalny i rozszerzony zakres analizy

Zakres analizy powinien być proporcjonalny do projektu. Nie każda organizacja potrzebuje od razu pełnego katalogu procesów i rozbudowanej dokumentacji.

Minimalny zakres	Rozszerzony zakres
Cel i zakres projektu	Karta programu lub projektu
Jeden lub kilka kluczowych procesów AS-IS i TO-BE	Katalog procesów i zależności
Lista podstawowych wymagań	Pełny katalog wymagań funkcjonalnych i niefunkcjonalnych
Opis najważniejszych integracji	Specyfikacje przepływów, danych, statusów i błędów
Scenariusze testowe dla kluczowej ścieżki	Kompletny plan testów i macierz powiązań
Kryteria odbioru pierwszego etapu	Kryteria odbioru etapów, pilotażu i całego rozwiązania
Lista ryzyk i decyzji	Rejestr ryzyk, założeń, zależności i zmian

W wielu przypadkach dobrym rozwiązaniem jest rozpoczęcie od ograniczonego etapu analitycznego. Pozwala on ocenić rzeczywistą złożoność projektu i zdecydować, które obszary wymagają dalszego szczegółowego opracowania.

W czym może pomóc LISNET?

W LISNET mogę wesprzeć organizację albo firmę wdrożeniową w przygotowaniu i prowadzeniu analizy przedwdrożeniowej systemu IT.

Zakres współpracy może obejmować:

• uporządkowanie celu i zakresu projektu,
• identyfikację interesariuszy i właścicieli procesów,
• przygotowanie oraz prowadzenie warsztatów,
• mapowanie procesów AS-IS,
• projektowanie procesów TO-BE,
• przygotowanie wymagań funkcjonalnych i niefunkcjonalnych,
• opis danych, statusów, ról i reguł biznesowych,
• analizę integracji i przepływu informacji pomiędzy systemami,
• przygotowanie scenariuszy testowych i kryteriów odbioru,
• opracowanie materiałów dla wykonawcy,
• wsparcie wykonawcy w doprecyzowaniu procesów po stronie klienta,
• przygotowanie planu pilotażu i kolejnych etapów wdrożenia,
• wsparcie analityczne podczas realizacji, testów i odbioru,
• diagnozę projektu, w którym pojawiły się problemy z zakresem lub współpracą stron.

Nie zastępuję dostawcy systemu ani specjalistów dziedzinowych organizacji. Mogę natomiast połączyć ich wiedzę z analizą procesową i systemową oraz przygotować materiały, które pozwalają sprawniej przeprowadzić projekt.

Efektem współpracy może być ograniczona analiza jednego procesu, przygotowanie zakresu dla wykonawcy, pilotaż wybranego obszaru albo dłuższe wsparcie większego programu wdrożeniowego.

Podsumowanie

Analiza przedwdrożeniowa nie jest dodatkowym etapem, który tylko opóźnia rozpoczęcie prac. Jej zadaniem jest ograniczenie niepewności przed podjęciem kosztownych decyzji.

Organizacja powinna wiedzieć, jaki problem rozwiązuje, jak wygląda obecny i docelowy proces, jakie dane są potrzebne, które systemy uczestniczą w rozwiązaniu oraz kto odpowiada za poszczególne decyzje.

Wykonawca powinien otrzymać zakres możliwy do wyceny, wymagania możliwe do zrealizowania i scenariusze pozwalające sprawdzić rezultat.

Dopiero po połączeniu tych perspektyw można odpowiedzialnie wybrać system, przygotować konfigurację, zaplanować integracje i rozpocząć wdrożenie.

Dobra analiza przedwdrożeniowa nie gwarantuje, że podczas projektu nie pojawią się zmiany. Sprawia jednak, że zmiany można ocenić świadomie, zamiast odkrywać podstawowe założenia dopiero podczas odbioru systemu.