Analiza przedwdrożeniowa automatyzacji procesów biznesowych – dlaczego nie warto na niej oszczędzać?

Analiza przedwdrożeniowa to etap wdrożenia automatyzacji procesu (lub jakiegokolwiek rozwiązania informatycznego), którego rola i waga często jest niedoceniana przez firmy. Chęć szybkiego uzyskania zamierzonych efektów często powoduje pokusę, aby jak najszybciej rozpocząć prace programistyczne i wdrożeniowe, marginalizując, a w skrajnych przypadkach nawet rezygnując z etapu analizy. W początkowej fazie projektów często występuje także wyzwanie skutecznego zaangażowanie działów biznesowych w dobre przygotowanie do startu projektu (mogę nie mieć dużego doświadczenia w projektach IT, mogę być problemy z pracą na dokumentacji technicznej opisującej dany proces) – nie jest to zarzut do działów biznesowych, a raczej nazwanie stojącego przed IT i biznesem wyzwania skutecznej komunikacji i współpracy.

Rezygnacja z dobrze przeprowadzonego etapu analizy może wydawać się (pozornie) kosztowo opłacalne, bowiem minimalizujemy liczbę roboczogodzin, jednak analiza to kluczowy etap, który oszczędza w przyszłości wielu rozczarowań związanych z otrzymanym produktem oraz niezwykle kosztownych prac modyfikacyjnych. Czym może się to skończyć? Postaramy się w skróconej formie przedstawić najważniejsze aspekty.

Niezrozumienie potrzeb

Budowanie rozwiązania niepoprzedzone dogłębną analizą to droga do otrzymania na końcowym etapie produktu, który nie spełnia oczekiwań klienta. Jeśli czas był ograniczony, siłą rzeczy nie uda się ustalić wszystkich możliwych w automatyzowanym procesie scenariuszy czy wyjątków, a nawet dobrze zrozumieć potrzeby będącej głównym powodem, dla którego w ogóle ten projekt się odbywa. W takich warunkach, znaczna część funkcjonalności musi być oparta na niepotwierdzonych założeniach, a mówiąc wprost – na domysłach. A to finalnie prowadzi nas do kolejnego punktu.

Niezadowolenie klienta

Takie rozwiązanie oparte na domysłach w pewnym momencie trafia do klienta i na etapie testów okazuje się na przykład, że pominięte zostały niezbędne do realizacji procesu funkcjonalności, a te, które są, działają w inny sposób niż klient tego oczekiwał. Wtedy pojawia się frustracja, bo „przecież wydaliśmy środki, a okazuje się, że to nie działa, jak powinno”. Pomimo poświęcenia dużej ilości czasu, trzeba się zatrzymać i rozwiązanie poprawić.

Kosztowne zmiany

Od doświadczonych ekspertów z branży można usłyszeć, że „każda godzina oszczędzona na analizie, to kilka dodatkowych dni pracy programistów w późniejszych etapach”. Powszechnie wiadomo, że zasoby developerskie to główny i największy koszt w projekcie. Właśnie ponieśliśmy ten koszt, budując rozwiązanie oparte na domysłach, a teraz znowu musimy go ponosić na wprowadzanie gruntownych zmian. Dodatkowo, często zmiana tego, co już jest i działa nieprawidłowo, może być bardziej czasochłonna, niż zbudowanie czegoś od zera – bo np. potrzeba wdrożenia brakujących funkcjonalności całkowicie zmienia wymagania do architektury systemu.

Przedłużający się projekt

Te zmiany, oprócz tego, że zwiększają koszt projektu, wydłużają też w oczywisty sposób jego czas. Wdrażanie nowych funkcjonalności, wycofywanie tych nieprawidłowo działających, ponowienie testów – to bardzo czasochłonny proces. Finalnie kończy się to tym, że klient otrzymuje rozwiązanie spełniające jego potrzeby o wiele później, niż gdybyśmy na początku zainwestowali kilka dodatkowych godzin w analizę.

Podsumowanie

Analiza przedwdrożeniowa to kluczowy etap wdrożenia systemów IT, a także projektów automatyzacji i robotyzacji, którego pomijanie może prowadzić do kosztownych i czasochłonnych problemów. Pominięcie tego kroku można nazwać „kosztowną oszczędnością”. Brak analizy skutkuje niezrozumieniem potrzeb klienta, co prowadzi do budowy rozwiązania niespełniającego oczekiwania. W efekcie pojawia się niezadowolenie użytkowników biznesowych, konieczność wprowadzania kosztownych zmian i przedłużenie projektu.

Dlatego warto edukować działy biznesowe, z którymi współpracuje się w realizacji projektu, z istotności przygotowania dokumentacji analizy na etapie zbierania wymagań, ale także pisać dokumentację w na tyle zrozumiały sposób, dla użytkowników biznesowych, że będą w stanie ją przeczytać, zrozumieć i faktycznie zaakceptować. Tego typu dokumentacja będzie też doskonałym narzędziem weryfikacji zakresu projektu na etapie testów i jego odbioru.