Analiza przedwdrożeniowa systemu – jak wygląda i co powinna dać firmie?

Przed wdrożeniem nowego systemu często pojawia się hasło „analiza przedwdrożeniowa”. Dla jednej firmy oznacza kilka rozmów z użytkownikami. Dla innej – kilkudziesięciostronicową specyfikację. Jeszcze inny dostawca ogranicza analizę do zebrania listy funkcji, które klient chciałby zobaczyć w programie.

Problem w tym, że sama liczba spotkań albo stron dokumentacji nie świadczy o jakości analizy. Dobra analiza przedwdrożeniowa powinna przede wszystkim odpowiedzieć na kilka prostych pytań: jak firma pracuje dzisiaj, gdzie naprawdę występuje problem, co warto zmienić, co powinien obsługiwać system i od czego najlepiej zacząć. Dopiero później przychodzi czas na technologię.

Analiza przedwdrożeniowa nie jest pisaniem systemu na papierze

Jednym z najczęstszych nieporozumień jest przekonanie, że przed rozpoczęciem projektu trzeba bardzo dokładnie opisać wszystkie przyszłe ekrany, pola, przyciski, raporty i funkcje. W efekcie powstaje dokument, który próbuje przewidzieć cały system, zanim ktokolwiek dobrze poznał rzeczywisty proces. To odwrócona kolejność.

Jeśli firma samodzielnie projektuje rozwiązanie, zanim wspólnie z dostawcą przeanalizuje problem, łatwo przenosi do nowego systemu wszystkie ograniczenia obecnego sposobu pracy. Dlatego podczas analizy znacznie bardziej interesuje nas zdanie „dzisiaj robimy to w ten sposób i tutaj pojawia się problem” niż „potrzebujemy przycisku, który będzie robił X”. Funkcja jest odpowiedzią – najpierw trzeba dobrze zrozumieć pytanie.

Od czego powinna zacząć się analiza?

Najlepiej od jednego rzeczywistego procesu. Nie od prezentacji firmy, nie od katalogu wszystkich używanych programów i nie od listy kilkudziesięciu oczekiwanych funkcji. Znacznie więcej można dowiedzieć się, przechodząc krok po kroku przez konkretny przykład – na przykład przez rzeczywiste zlecenie: klient wysyła zapytanie → handlowiec przygotowuje ofertę → klient ją akceptuje → powstaje zlecenie → przygotowywana jest dokumentacja → zadania trafiają do odpowiednich osób → rozpoczyna się realizacja → sprawdzane są terminy → przygotowywane są dokumenty końcowe → zlecenie trafia do rozliczenia.

Dopiero podczas takiej rozmowy wychodzą rzeczy, których często nie ma w żadnej procedurze. Okazuje się, że ktoś dodatkowo prowadzi własny arkusz. Ktoś inny zapisuje ważne informacje w mailach. Kierownik codziennie ręcznie sprawdza kilka miejsc. Dane między dwoma programami przepisuje pracownik. Na schemacie proces może wyglądać bardzo dobrze – dopiero rzeczywisty przykład pokazuje, jak firma naprawdę pracuje.

Trzeba poznać nie tylko proces prawidłowy

Podczas analizy łatwo opisać model idealny: „jeśli klient zaakceptuje ofertę, tworzymy zlecenie, realizujemy je i zamykamy”. Tyle że codzienna praca prawie nigdy nie przebiega wyłącznie według modelu idealnego.

Co się dzieje, jeśli klient zmieni zakres po zaakceptowaniu oferty? Co jeśli część produktów jest niedostępna? Co jeśli zlecenie trzeba podzielić? Co jeśli dokumentacja wraca do poprawy, termin zostaje przesunięty albo klient anuluje tylko część zamówienia?

To właśnie sytuacje wyjątkowe często decydują o tym, czy system rzeczywiście pomaga, czy po kilku miesiącach użytkownicy wracają do arkuszy, maili i notatek. Dobra analiza nie polega więc na opisaniu wyłącznie „ładnej ścieżki”. Trzeba zobaczyć też, co dzieje się wtedy, gdy proces nie przebiega zgodnie z planem.

Rozmawiaj z osobami, które naprawdę wykonują tę pracę

Sam właściciel firmy albo zarząd nie zawsze zna wszystkie szczegóły procesu – i nie jest to nic dziwnego. Inaczej proces widzi osoba zarządzająca firmą, inaczej kierownik działu, a jeszcze inaczej pracownik, który codziennie wykonuje konkretną czynność.

Z perspektywy zarządu proces może wyglądać tak: zamówienie → produkcja → wysyłka. Z perspektywy osoby operacyjnej między tymi trzema punktami może znajdować się kilkanaście czynności, kilka arkuszy, dwa telefony i trzy ręcznie przygotowywane dokumenty.

Dlatego w analizie powinni uczestniczyć również przyszli użytkownicy systemu. To oni najlepiej wiedzą, co zabiera najwięcej czasu, jakie informacje są potrzebne do wykonania pracy, gdzie najczęściej pojawiają się błędy, czego trzeba pilnować ręcznie i jakie obejścia powstały przez lata, których nie widać z poziomu zarządu.

Nie oznacza to, że każda sugestia użytkownika powinna zostać automatycznie zamieniona w funkcję systemu. Ale bez ich wiedzy łatwo zaprojektować rozwiązanie, które dobrze wygląda podczas prezentacji, a słabo działa w codziennej pracy.

Ważne jest pytanie „dlaczego?”

Podczas analizy często słyszymy: „tutaj przepisujemy numer do arkusza”. Dlaczego? „Bo dział produkcji korzysta z tego arkusza.” Dlaczego nie może korzystać z danych z systemu? „Bo nie widzi tam jednej informacji.”

I nagle okazuje się, że problemem nie jest sam arkusz, tylko brak jednej informacji we właściwym miejscu. To właśnie dlatego nie warto zatrzymywać się na pierwszej odpowiedzi. Za wieloma funkcjami, arkuszami i ręcznymi czynnościami stoją potrzeby, które można rozwiązać znacznie prościej, niż początkowo się wydaje.

Analiza powinna wskazać miejsca, w których ginie czas

Nie każda niedogodność wymaga zmiany. Jeśli czynność trwa dwie minuty i występuje raz w miesiącu, jej automatyzowanie może nie mieć żadnego ekonomicznego sensu. Inaczej wygląda sytuacja, gdy pięć osób codziennie wykonuje tę samą ręczną operację.

Dlatego podczas analizy warto ustalić nie tylko co się dzieje, ale też jak często, jak długo, przez ile osób i jakie są konsekwencje błędu lub opóźnienia. To pozwala odróżnić problemy naprawdę ważne od tych, które jedynie irytują użytkowników – i właśnie wtedy łatwiej później ocenić, czy wdrożenie systemu rzeczywiście się opłaca.

Trzeba sprawdzić, gdzie znajdują się dane

Proces to jedno, dane to drugie. W firmie informacje mogą znajdować się jednocześnie w systemie sprzedażowym, programie księgowym, arkuszach, skrzynkach mailowych, folderach sieciowych, programie produkcyjnym i prywatnych notatkach pracowników.

Przed wdrożeniem warto ustalić, co jest źródłem prawdziwej informacji, które dane są powielane, gdzie pojawiają się różne wersje tej samej informacji i co rzeczywiście trzeba przenieść do nowego rozwiązania.

Często okazuje się, że część „migracji danych” wcale nie powinna być migracją. Stare informacje można zarchiwizować zamiast przenosić. Duplikaty można usunąć. Nieaktualnych rekordów nie trzeba zabierać do nowego systemu. Przenoszenie bałaganu z jednego programu do drugiego nie jest transformacją cyfrową – to tylko szybszy bałagan w nowym miejscu.

Analiza powinna uwzględniać istniejące systemy

Nowy projekt nie oznacza automatycznie wymiany wszystkiego. Jeśli firma ma program księgowy, magazynowy albo produkcyjny, który dobrze spełnia swoją rolę, najlepszym rozwiązaniem jest często pozostawienie go i odpowiednie połączenie z nowym systemem.

Podczas analizy trzeba więc określić, które narzędzia zostają, które można usunąć, gdzie potrzebna jest wymiana danych i w których miejscach obecnie „integracją” jest pracownik. To ostatnie szczególnie często wskazuje miejsca warte automatyzacji.

Nie wszystko musi znaleźć się w pierwszym etapie

Dobra analiza prawie zawsze prowadzi do nowych pomysłów. Skoro system będzie już obsługiwał zlecenia, może również raportować rentowność. Skoro mamy dane o realizacji, może przydałby się dodatkowy dashboard. Skoro powstają dokumenty, może można jeszcze zautomatyzować ich wysyłkę. I bardzo dobrze.

Problem pojawia się dopiero wtedy, gdy wszystkie te pomysły próbujemy umieścić w pierwszej wersji. Pierwszy etap powinien być wystarczająco duży, żeby dawać realną wartość, i wystarczająco mały, żeby dało się go rozsądnie wdrożyć i sprawdzić.

Dlatego po analizie funkcje warto rozdzielić na trzy grupy: potrzebne na start, wartościowe w kolejnym etapie i pomysły do sprawdzenia później. To często najlepszy sposób na ograniczenie kosztu i ryzyka projektu.

Analiza powinna zakończyć się decyzjami

Samo odbycie kilku spotkań nie jest jeszcze rezultatem. Po dobrej analizie firma powinna znacznie lepiej rozumieć, jaki problem rozwiązuje, jaki proces obejmuje projekt, kto będzie korzystał z systemu, jakie dane są potrzebne, które narzędzia pozostają, jakie integracje są niezbędne, co powinno znaleźć się w pierwszym etapie i po czym będzie można ocenić efekt.

Nie oznacza to konieczności stworzenia ogromnego dokumentu. Czasem kilka dobrze przygotowanych schematów i konkretnych ustaleń daje więcej niż kilkadziesiąt stron opisu. Celem analizy nie jest dokument – celem jest ograniczenie niewiadomych przed rozpoczęciem wdrożenia.

Czy po analizie wszystko musi być już ustalone?

Nie – i to też jest ważne. W projektach informatycznych część rzeczy staje się jasna dopiero wtedy, gdy użytkownicy zobaczą pierwszy działający fragment rozwiązania. Dlatego próba ustalenia wszystkich szczegółów na początku może być równie ryzykowna jak rozpoczęcie projektu bez żadnej analizy.

Dobra analiza powinna wystarczająco dobrze określić kierunek i pierwszy zakres, ale jednocześnie zostawić miejsce na uczenie się podczas wdrożenia. Im bardziej złożony i indywidualny proces, tym ważniejsze staje się takie podejście.

Analiza przedwdrożeniowa a specyfikacja

Te pojęcia nie są tym samym. Analiza odpowiada przede wszystkim na pytania: co dzieje się w firmie, gdzie jest problem i co chcemy poprawić. Specyfikacja opisuje natomiast bardziej szczegółowo, jak ma działać konkretne rozwiązanie.

W niektórych projektach szczegółowa specyfikacja będzie potrzebna. W innych znacznie lepiej sprawdzi się etapowe rozwijanie systemu wraz z użytkownikami. Najważniejsze, żeby nie tworzyć specyfikacji wyłącznie dlatego, że „tak robi się projekty IT” – dokument ma pomagać w realizacji projektu, a nie być celem samym w sobie.

Kiedy analiza może pokazać, że system nie jest potrzebny?

To również możliwy i wartościowy wynik. Bywa, że problem nie wynika z braku programu – firma ma już wszystkie potrzebne narzędzia, ale pracownicy korzystają z nich w różny sposób, brakuje ustalonych zasad, dane są nieuporządkowane albo proces zawiera niepotrzebne kroki. Czasem problem da się rozwiązać niewielką zmianą konfiguracji istniejącego systemu.

Dobra analiza nie powinna prowadzić za wszelką cenę do dużego wdrożenia. Jeśli prostsze rozwiązanie wystarczy, właśnie ono powinno zostać zaproponowane.

Ile powinna trwać analiza przedwdrożeniowa?

Nie ma jednej prawidłowej odpowiedzi. Analiza jednego zamkniętego procesu w firmie zatrudniającej kilkanaście osób będzie wyglądała inaczej niż przygotowanie projektu obejmującego sprzedaż, produkcję, magazyn, logistykę i księgowość. Znaczenie ma liczba procesów, użytkowników, systemów, wyjątków i integracji.

Dlatego długość analizy sama w sobie nie jest dobrym kryterium jakości. Znacznie ważniejsze jest to, czy po jej zakończeniu wiadomo wystarczająco dużo, żeby bezpiecznie rozpocząć pierwszy etap.

Kto powinien uczestniczyć w analizie?

Najczęściej potrzeba kilku perspektyw: osoby, która rozumie cele biznesowe i może podejmować decyzje, właściciela analizowanego procesu i przyszłych użytkowników. Po stronie dostawcy potrzebny jest ktoś, kto potrafi nie tylko zebrać wymagania, ale też zakwestionować niepotrzebne założenia i zaproponować prostszy sposób działania.

Nie ma potrzeby, żeby wszystkie osoby uczestniczyły w każdym spotkaniu. Ważne, żeby żadnej z kluczowych perspektyw nie zabrakło.

Jak przygotować firmę do analizy?

Nie trzeba tworzyć specyfikacji. Znacznie bardziej pomocne jest przygotowanie jednego lub kilku prawdziwych przykładów. Warto mieć pod ręką rzeczywiste zlecenie, używane formularze, przykładowe dokumenty, arkusze, informacje o wykorzystywanych programach oraz osoby, które potrafią pokazać cały proces. Im bardziej realny materiał, tym mniej czasu trzeba poświęcać na rozmowę o teoretycznych scenariuszach.

Szerzej opisaliśmy to w naszej checkliście przygotowania firmy do wdrożenia systemu.

Jak podchodzimy do analizy przedwdrożeniowej w NSF?

Zaczynamy od procesu. Chcemy zobaczyć konkretny przykład i przejść przez niego od początku do końca. Pytamy, kto wykonuje poszczególne czynności, skąd bierze informacje, co tworzy, komu przekazuje wynik i co dzieje się w sytuacjach nietypowych. Szukamy ręcznej pracy, przepisywania danych, miejsc wymagających ciągłego pilnowania i informacji znajdujących się w kilku systemach jednocześnie.

Nie zakładamy z góry, że wszystko trzeba przenieść do jednego programu. Czasem właściwą odpowiedzią będzie konfiguracja NSF Core, czasem integracja, czasem niewielka automatyzacja, a czasem oprogramowanie na zamówienie. Czasem wystarczy uprościć proces i zostawić większość istniejących narzędzi. Technologia jest wynikiem analizy, nie jej początkiem.

Po czym poznać dobrą analizę przedwdrożeniową?

Nie po grubości dokumentacji. Po tym, że po jej zakończeniu zarówno firma, jak i wykonawca potrafią jasno odpowiedzieć na cztery pytania: co dziś jest problemem, co dokładnie chcemy poprawić, co robimy w pierwszym etapie i po czym poznamy, że zmiana przyniosła efekt.

Jeśli odpowiedzi nadal są niejasne, prawdopodobnie analiza jeszcze się nie skończyła.

Najczęstsze pytania