Jak przygotować analizę przedwdrożeniową w średniej firmie

Czym jest analiza przedwdrożeniowa i dlaczego w średniej firmie nie można jej pominąć

Analiza przedwdrożeniowa to ocena projektu przed startem wdrożenia. Wskazuje problemy, ryzyka i potrzeby, które trzeba uwzględnić już na etapie projektowania i realizacji zadania. W jej zakres wchodzą między innymi identyfikacja potrzeb i oczekiwań, określenie wymagań technicznych oraz wskazanie potencjalnych zagrożeń i wyzwań mogących wpłynąć na realizację. Dzięki niej zapobiega się problemom w trakcie wdrażania i ogranicza ryzyko niepowodzenia projektu.

W firmie produkcyjnej analiza pokazuje rzeczywiste potrzeby organizacji i pozwala zdefiniować wymagania funkcjonalne. Bez tego etapu nawet najlepszy system informatyczny może okazać się nieadekwatny do specyfiki działania firmy.

System IT sam nie zmieni rzeczywistości biznesowej firmy – raczej ją „usankcjonuje”. Dostarczy narzędzie do obsługi procesów w takiej postaci, w jakiej zostaną one przygotowane i opracowane w formie wymogów biznesowych.

Typowy błąd przy wdrożeniach to oczekiwanie, że samo uczestnictwo w projekcie wdrożeniowym firmy informatycznej usprawni i zoptymalizuje procesy biznesowe. Problemy, z którymi firma boryka się na co dzień, nie znikną.

Efekty dobrze przeprowadzonej analizy w średniej firmie to uniknięcie kosztownych błędów projektowych, precyzyjniejsze oszacowanie budżetu i harmonogramu, większa akceptacja użytkowników końcowych oraz mniejsze ryzyko niepowodzenia projektu.

Przygotowanie do analizy: zespół, zakres, dokumentacja i harmonogram

Przygotowanie do analizy przedwdrożeniowej wymaga czterech działań. Trzeba powołać zespół projektowy z przedstawicieli wszystkich kluczowych obszarów firmy oraz określić zakres analizy, czyli zdefiniować, które procesy i obszary obejmie badanie. Następnie przygotować dokumentację, zbierając istniejące procedury, instrukcje i opisy procesów, i zaplanować harmonogram, ustalając terminy poszczególnych etapów analizy.

W skład zespołu warto włączyć przedstawicieli kluczowych obszarów firmy. Chodzi o osoby mające wiedzę o tym, jak praca faktycznie przebiega, przyszłych użytkowników systemu, którzy będą zgłaszać wymagania i później z niego korzystać, a także osoby odpowiedzialne za IT i za finanse. Zespół potrzebuje kierownika z mandatem do podejmowania ustaleń i eskalowania sporów, a nie wyłącznie zbioru osób zbierających opinie.

Zakres analizy trzeba ograniczyć świadomie. Objęcie wszystkich obszarów średniej firmy jednocześnie rozciąga projekt i utrudnia utrzymanie tempa warsztatów. Pomocne jest ustalenie przed startem, które procesy są krytyczne dla decyzji o wdrożeniu, i potraktowanie pozostałych jako drugiego etapu.

Zebranie danych i rzetelny opis stanu obecnego

Projekt analizy przedwdrożeniowej rozpoczyna się od analizy sytuacji i potrzeb biznesowych po stronie firmy. W praktyce chodzi o jak najszybsze przejście z języka odczuć, obserwacji i przekonań do stanu opartego na faktach, danych, miarach i konkretnych wynikach.

Przy wdrożeniu systemu informatycznego szczególnie istotna jest niezależna ocena efektywności obecnych procesów: kolejności wykonywanych zadań, uprawnień, obiegu informacji i dokumentów.

Jednym z celów analizy jest stworzenie szczegółowej mapy procesów biznesowych oraz identyfikacja obszarów wymagających optymalizacji. Mapa powinna pokazać nie tylko kroki, ale też źródła danych, dokumenty, miejsca, w których informacja jest przepisywana ręcznie, i punkty decyzyjne wymagające akceptacji przełożonego.

Ocenie podlega również aktualny stan projektu, jeśli analiza jest kontynuacją wcześniejszych prac. Pozwala to ocenić osiągnięty postęp i zidentyfikować potencjalne problemy. Osobnym elementem jest ocena środowiska, w którym projekt będzie realizowany: infrastruktury technicznej, dostępności zasobów ludzkich i procesów biznesowych.

Punkty odniesienia dla oceny stanu obecnego daje też analiza konkurencji i najlepszych praktyk branżowych. Pozwala wyznaczyć standardy i cele dla projektu. Bez takiego odniesienia dyskusja o tym, czy obecny proces jest dobry, sprowadza się do sporów o przyzwyczajenia poszczególnych działów.

Warsztaty i spotkania z użytkownikami jako źródło wymagań

Spotkanie z klientem i interesariuszami służy zrozumieniu potrzeb i celów biznesowych oraz omówieniu oczekiwań wobec projektu. Często nie jest to jedno spotkanie, ale cykliczne serie spotkań, zależne od konkretnego przypadku i zgłaszanych potrzeb. Taki tryb pozwala wracać do tematów pomiędzy sesjami i weryfikować ustalenia z osobami, które nie brały udziału w danej sesji.

Analiza przedwdrożeniowa przyjmuje formę warsztatów stosowanych w metodyce kaskadowej i odbywa się przed rozpoczęciem wdrożenia systemu. Na warsztatach z kluczowymi użytkownikami prowadzi się mapowanie procesów – w firmach produkcyjnych i logistycznych dotyczy ono procesów magazynowych lub produkcyjnych – oraz analizę wymagań integracyjnych.

Warsztaty są też okazją do ustalenia, ile czasu kluczowi użytkownicy mogą realnie poświęcić na prace analityczne i testy. Brak takiej deklaracji jest typowym źródłem opóźnień, gdy ten sam specjalista jest jednocześnie potrzebny w produkcji czy w dziale handlowym.

Praktyczna organizacja warsztatu obejmuje jasny temat sesji i listę uczestników z podziałem na role, moderatora prowadzącego dyskusję i osobę dokumentującą ustalenia. Po spotkaniu wysyła się notatkę z decyzjami i listą otwartych kwestii do zatwierdzenia przez uczestników. Bez zamknięcia ustaleń na piśmie te same zagadnienia wracają na kolejnych spotkaniach i rozciągają analizę.

Określenie wymagań funkcjonalnych i technicznych

Analiza wymagań obejmuje ocenę wymagań funkcjonalnych i technicznych projektu, takich jak funkcjonalność, wydajność, bezpieczeństwo i skalowalność. Te cztery wymiary trzeba opisać dla konkretnych procesów, a nie ogólnie dla całego systemu. Inaczej wymagań typu „system musi być wydajny” nie da się później zweryfikować.

Wymagania techniczne obejmują również integracje. Analiza wymagań integracyjnych ustala, z jakimi systemami nowe rozwiązanie musi się wymieniać dane, w jakim kierunku i na jakim poziomie szczegółowości.

Gdy wymagania powstają wyłącznie z katalogu możliwości narzędzia, firma przenosi do nowego systemu swoje obecne błędy organizacyjne i płaci za ich obsługę.

Każde wymaganie powinno mieć źródło w konkretnym procesie lub decyzji biznesowej, kryterium akceptacji (co uznamy za spełnienie) oraz priorytet (musi być / powinno być / może być). Taki układ pozwala w trakcie wdrożenia negocjować zakres na podstawie uzgodnionej listy, a nie siły nacisku poszczególnych działów.

Analiza ryzyka, finansowa i SWOT przed decyzją o wdrożeniu

Analiza ryzyka polega na identyfikacji i analizie potencjalnych zagrożeń, takich jak problemy techniczne, opóźnienia w harmonogramie i koszty. Dla każdego ryzyka warto ustalić, po czym poznamy, że się zmaterializowało, i kto w firmie odpowiada za reakcję.

Na decyzję zarządu wpływają analiza ryzyka projektu, analiza finansowa projektu oraz analiza SWOT projektu. Służą one uporządkowaniu decyzji i ograniczeniu najczęstszych błędów decyzyjnych.

Analiza finansowa obejmuje między innymi pytanie o koszt braku decyzji, czyli o to, ile firmę kosztuje dalsze funkcjonowanie w obecnym trybie.

Koszt braku decyzji najłatwiej pokazać jako zestawienie nakładów ponoszonych dziś: pracy wykonywanej ręcznie i powtarzalnej, kosztów błędów wymagających korekt, opóźnień w obiegu dokumentów czy nadgodzin w okresach szczytów. To pozycje, które w razie odłożenia projektu pozostają w budżecie firmy.

Zestawienie kosztów wdrożenia powinno obejmować licencje lub opłaty abonamentowe, prace wdrożeniowe i konfiguracyjne, integracje, migrację danych, szkolenia, koszt utrzymania po starcie oraz czas pracy własnego zespołu. Ten ostatni element jest regularnie pomijany i odpowiada za zaniżone budżety.

Ryzykiem warto też nazwać konsekwencje pominięcia etapu analizy. Gdy w pierwszej fazie projektu, w momencie formułowania wymagań biznesowych, zabraknie wnikliwej analizy procesów, efekty po wdrożeniu mogą nie być zgodne z oczekiwaniami zarówno kadry kierowniczej, jak i samych pracowników. Zwykle ujawnia się to już po zakończeniu projektu.

Koszty braku decyzji vs. koszty wdrożenia systemu

Projektowanie procesów docelowych przed wyborem systemu

Właściwa kolejność prac: najpierw analiza procesów i wypracowanie docelowych rozwiązań dla obecnych problemów organizacyjnych, a dopiero potem projekt informatyczny – najlepiej jako zupełnie osobne zadanie. Optymalne zaprojektowanie procesów docelowych powinno nastąpić, zanim podejmie się decyzję o planowanej funkcjonalności rozwiązań technologicznych.

Zmiany dotyczą zwykle kilku typowych wymiarów: liczby kroków, kolejności zadań, uprawnień do decyzji, obiegu informacji i dokumentów oraz liczby miejsc, w których dane są wprowadzane ponownie.

Efektem powinien być opis procesu docelowego z właścicielem procesu, miernikiem jego działania i wskazaniem, co w procesie wymaga wsparcia systemowego, a co można uprościć niezależnie od narzędzia.

Raport przedwdrożeniowy: co powinien zawierać i jak nim zarządzać

Wynikiem analizy przedwdrożeniowej jest raport z rekomendacjami dotyczącymi strategii projektowej, harmonogramu, kosztów, ryzyka i innych kwestii. Dokument ten pozwala zespołowi projektowemu skutecznie zaplanować realizację projektu, minimalizując ryzyko i zapewniając, że projekt spełni oczekiwania.

Raport wskazuje, jak procesy działające obecnie w firmie zostaną zrealizowane w nowym rozwiązaniu. Uzupełniają go wyniki warsztatów, mapy procesów i wymagania – łącznie tworzą spójną specyfikację wdrożenia, która jest podstawą do rozmów z dostawcami i do wyceny.

Odrębnym elementem prac jest product discovery. Jego prowadzenie ogranicza liczbę zmian zakresu już po podpisaniu umowy wdrożeniowej. Im więcej niepewności zostanie rozwiązanych przed podpisaniem kontraktu, tym mniej aneksów i sporów w trakcie realizacji.

Zarządzanie raportem w średniej firmie obejmuje ustalenie, kto go zatwierdza po stronie zarządu, w jaki sposób będzie wersjonowany przy kolejnych uzgodnieniach oraz jak zostanie powiązany z umową wdrożeniową.

Zatwierdzony raport warto zakomunikować całej załodze jako uzgodniony opis kierunku zmian. Przekłada się to bezpośrednio na akceptację użytkowników końcowych, którzy wcześniej brali udział w warsztatach i widzą w dokumencie własne ustalenia.