Automatyzacja obsługuje setki spraw poprawnie, aż trafia się zamówienie bez wymaganych danych, duplikat albo spóźniona płatność. Wtedy proces, który miał oszczędzać czas, zaczyna wymagać ręcznego szukania błędu. Dobra automatyzacja procesów w firmie nie polega na tym, że nigdy się nie myli, tylko że wiadomo, co dzieje się po wystąpieniu wyjątku.
Idealny scenariusz to za mało
Najłatwiej zautomatyzować idealny scenariusz: kompletne dane, dostępny system, poprawny dokument i płatność na czas. Problem w tym, że codzienna praca rzadko wygląda tak przez 100% czasu.
Klient może nie podać NIP-u, formularz może zostać wysłany dwa razy, ERP może przez chwilę nie odpowiadać, a dostawca zmieni format faktury. Jeśli automatyzacja nie przewiduje takich sytuacji, pojedynczy wyjątek może zatrzymać cały proces.
Najczęstsze wyjątki da się przewidzieć
W większości wdrożeń powtarzają się podobne problemy:
- brak wymaganych danych,
- duplikat rekordu lub zamówienia,
- opóźniona płatność albo odpowiedź systemu,
- inny format dokumentu,
- chwilowa niedostępność zewnętrznego systemu.
Przykład: zamówienie trafia do ERP, ale potwierdzenie płatności przychodzi dopiero po 15 minutach. Jeśli automat od razu uzna brak płatności za błąd, pracownik będzie interweniował bez potrzeby. Lepszym rozwiązaniem jest ponowne sprawdzenie statusu po określonym czasie.
Automat powinien mieć trzy sposoby reakcji
Nie każdy błąd automatyzacji wymaga tego samego działania. Najczęściej wystarczą trzy strategie.
Jeśli dalsze wykonanie procesu mogłoby spowodować szkodę, automat powinien go zatrzymać. Jeśli potrzebna jest decyzja biznesowa, przypadek powinien trafić do człowieka z jasnym komunikatem, np. „Brak NIP dla zamówienia 5821”. Jeśli problem jest chwilowy, system może spróbować ponownie po kilku minutach.
Najgorszy scenariusz to cichy błąd, po którym nikt nie wie, czy proces się wykonał.
Log błędów jest ważniejszy niż efektowne demo
Podczas prezentacji łatwo pokazać, że zamówienie automatycznie przechodzi z jednego systemu do drugiego. Po wdrożeniu ważniejsze jest jednak pytanie: „Dlaczego właśnie to zamówienie nie przeszło?”.
Dobry log powinien pokazywać, którego rekordu dotyczył problem, kiedy wystąpił, na jakim kroku i z jakiego powodu. Dzięki temu nie trzeba sprawdzać kilku systemów i pytać różnych osób.
Historia błędów pomaga też wykryć powtarzalne problemy. Jeśli większość wyjątków wynika z jednego brakującego pola, poprawa formularza może być bardziej opłacalna niż rozbudowa automatyzacji.
Wyjątki trzeba testować przed uruchomieniem
Nie wystarczy sprawdzić jednego poprawnego przypadku. Przed wdrożeniem warto celowo przetestować brak danych, duplikat, awarię API, opóźnione zdarzenie i błędny format pliku.
Dla każdego scenariusza trzeba wcześniej ustalić: czy proces się zatrzymuje, czy następuje ponowienie i kto otrzymuje informację. Prosty diagram z punktami „automat / człowiek / ponowienie / stop” często wystarcza, aby znaleźć luki jeszcze przed startem.
Nie każdy wyjątek warto przy tym automatyzować. Jeśli nietypowa sytuacja występuje kilka razy w roku i jej obsługa trwa dwie minuty, stworzenie rozbudowanej logiki może nie mieć ekonomicznego sensu.
Dobra automatyzacja wie, kiedy potrzebuje pomocy
Celem nie powinno być automatyczne obsłużenie 100% przypadków za wszelką cenę. Lepszym celem jest proces, w którym standardowe sprawy przechodzą bez udziału człowieka, a wyjątki są szybko wykrywane i trafiają we właściwe miejsce.
Jeśli planujesz automatyzację procesu, zacznij od wypisania nie tylko jego standardowych kroków, ale też pięciu najczęstszych sytuacji, w których coś idzie inaczej. To zwykle najszybszy sposób, aby ocenić, czy projekt będzie działał również poza prezentacją.