Automatyzacja procesów biznesowych: jak policzyć koszt pracy ręcznej i zaplanować MVP

Automatyzacja procesów biznesowych jest opłacalna wtedy, gdy koszt powtarzalnej pracy ręcznej jest większy niż koszt uporządkowania procesu. Nie chodzi o zastąpienie ludzi systemem. Najczęściej chodzi o usunięcie przepisywania danych, pilnowania statusów, wysyłania przypomnień i ręcznego składania raportów.

Najlepszy pierwszy krok to policzyć koszt obecnego procesu. Bez tego łatwo zbudować funkcje, które wyglądają dobrze, ale nie zmieniają ekonomii pracy.

Automatyzacja procesów: jak znaleźć dobry punkt startu

Dobry kandydat jest częsty, mierzalny i ma jasny wynik. Może nim być zamówienie, zgłoszenie, akceptacja dokumentu, rozliczenie, wdrożenie klienta albo raport operacyjny. Proces nie musi być duży. W takim miejscu automatyzacja procesów ma wyraźny cel.

Słaby kandydat to zadanie rzadkie, eksperckie i za każdym razem inne. Takie działania można wspierać listą kontrolną albo panelem informacyjnym, ale pełna automatyzacja procesów może się nie zwrócić.

Jak policzyć koszt pracy ręcznej

Podstawowa kalkulacja powinna uwzględniać czas zadania, oczekiwanie, poprawki, pytania klientów, błędy w danych i raportowanie. Jeżeli jedna sprawa trwa 20 minut, a firma ma ich 500 miesięcznie, to ponad 160 godzin pracy. Jeśli połowę czasu zajmuje przepisywanie danych, pilnowanie statusów i wysyłanie przypomnień, automatyzacja procesów ma konkretny punkt odniesienia.

Warto zebrać:

• liczbę spraw miesięcznie,
• średni czas obsługi,
• liczbę osób zaangażowanych,
• czas poprawek,
• koszt błędów,
• liczbę pytań o status,
• sezonowość i przewidywany wzrost.

Automatyzacja procesów wymaga punktu odniesienia, nie idealnego szacunku. Kalkulacja ma pomóc wybrać proces z największą szansą na zwrot.

Model bazowy przed decyzją o MVP

Pomiar warto prowadzić przez okres obejmujący przynajmniej jeden pełny cykl pracy. Tydzień bez zamknięcia miesiąca, dostawy albo rozliczenia może zaniżyć wynik. Dla każdej sprawy zapisujemy czas aktywnej pracy, czas oczekiwania, poprawki i wyjątki. Czekanie nie zawsze generuje koszt pracy, ale może wydłużać odpowiedź dla klienta albo blokować kolejne zadanie, dlatego nie należy go mieszać z czasem faktycznej obsługi.

W podanym wcześniej przykładzie 500 spraw po 20 minut oznacza 166 godzin i 40 minut pracy miesięcznie. Automatyzacja procesów nie oznacza jednak, że cały ten czas stanie się potencjalną oszczędnością. Najpierw trzeba wskazać, które minuty wynikają z przepisywania danych, kontroli kompletności, przekazywania statusu lub tworzenia dokumentu, a które pozostaną potrzebne, bo obejmują ocenę eksperta albo rozmowę z klientem. Jeżeli automatyzacja procesów może bezpiecznie usunąć tylko część kroków, właśnie tę część przyjmujemy do kalkulacji.

Koszt bazowy można policzyć jako iloczyn liczby godzin i pełnego kosztu pracy, a następnie dodać udokumentowany koszt poprawek, reklamacji lub opóźnień. Gdy automatyzacja procesów wymaga nowego rozwiązania, po tej stronie uwzględniamy wdrożenie, licencje, utrzymanie, obsługę wyjątków oraz czas użytkowników potrzebny na zmianę sposobu pracy. Porównanie samych kosztów budowy z wynagrodzeniami pracowników byłoby niepełne.

Przed zgodą na MVP warto przygotować trzy warianty: ostrożny, bazowy i graniczny. Różnią się udziałem spraw obsłużonych przez system, liczbą wyjątków i tempem przyjęcia rozwiązania przez zespół. Każdy wariant powinien pokazywać założenia, koszt roczny, miernik po starcie i warunek przerwania dalszego rozwoju. Dzięki temu decyzja nie opiera się na obietnicy, że automatyzacja usunie całą pracę ręczną. Po pierwszym pełnym cyklu te same dane pozwalają porównać założenie z rzeczywistym wynikiem.

Co automatyzować najpierw

Automatyzacja procesów powinna najpierw usuwać największą blokadę przy możliwie małym ryzyku. Często są to statusy, formularze, powiadomienia, integracja z CRM lub ERP, generowanie dokumentów albo prosty panel dla zespołu.

Poniższa mapa pomaga przejść od kosztu obecnej pracy do zakresu MVP: wskazuje sprawę, decyzję, dane, zadanie, termin i raport, które powinny tworzyć jeden zamknięty proces.

Nie warto zaczynać od pełnego systemu. Lepiej wybrać jeden przepływ: formularz dostarcza dane, system nadaje status, tworzy zadania, pobiera informacje z jednego źródła i zapisuje wynik. Taki zakres pokaże, czy automatyzacja procesów skraca pracę i ogranicza błędy.

RPA, API czy własny moduł

RPA sprawdza się, gdy trzeba zautomatyzować czynności w systemie bez API. Może być rozwiązaniem przejściowym, ale bywa kruche, bo zależy od interfejsu użytkownika. Integracja API jest stabilniejsza, jeśli systemy ją udostępniają. Własny moduł ma sens, gdy firma potrzebuje logiki procesu, ról, statusów i raportów.

Automatyzacja procesów często łączy kilka rozwiązań. Formularz zbiera dane, API synchronizuje CRM, mechanizm przepływu pracy tworzy zadania, a RPA obsługuje starszy system. Każda technologia powinna mieć jasny cel.

Automatyzacja procesów: jak przygotować MVP

Przed wdrożeniem trzeba wskazać właściciela procesu, źródła danych, statusy, wyjątki, decyzje ręczne i mierniki. Bez tego system tylko przyspieszy chaos. Technologia nie rozstrzygnie, kto ma zaakceptować dokument albo odpowiada za brakujące dane.

Minimalny zakres powinien zawierać:

• jeden proces,
• role użytkowników,
• dane wejściowe,
• statusy,
• jedną krytyczną integrację,
• raport efektu,
• plan obsługi wyjątków.

Po wdrożeniu sprawdzamy, czy automatyzacja procesów poprawiła czas obsługi, liczbę błędów, liczbę ręcznych kroków i liczbę pytań o status. Jeśli wynik jest lepszy od wartości bazowej, można rozwijać kolejne etapy.

Automatyzacja procesów przed i po wdrożeniu

Przed rozpoczęciem warto opisać proces w dwóch wersjach: obecnej i docelowej. W obecnej zapisujemy ręczne kroki, oczekiwanie, narzędzia, osoby i miejsca powstawania błędów. W docelowej pokazujemy, które działania przejmuje system, które zostają decyzją człowieka i gdzie trafiają dane.

Taki model chroni przed automatyzowaniem wszystkiego. Nie każda decyzja powinna zniknąć z procesu. Czasem najlepszy efekt daje to, że system przygotuje dane, nada status, przypomni o terminie i zapisze historię, ale decyzję zostawi ekspertowi.

Utrzymanie procesu po starcie

Właściciel procesu i danych

Automatyzacja procesów wymaga po wdrożeniu właściciela procesu, nie tylko właściciela narzędzia. Ta osoba ustala, które wyjątki pozostają ręczne, jakie dane są obowiązkowe i kto reaguje na błąd integracji. Zadania powinny mieć właściciela, termin, status oraz regułę eskalacji. Za każde źródło danych należy też jasno przypisać odpowiedzialność. Bez tej roli system szybko zaczyna zależeć od jednej osoby albo od nieformalnych obejść.

Automatyzacja procesów: pomiar efektu

Po wdrożeniu porównujemy wynik z sytuacją bazową. Najważniejsze wskaźniki to czas obsługi, ręczne kroki, błędy, pytania o status i koszt poprawki. Dzięki temu widać, czy automatyzacja procesów przynosi trwały efekt. Warto też sprawdzić, czy użytkownicy widzą aktualny status, decyzje mają historię, a dane nie są ponownie przepisywane poza systemem.

Jeżeli wskaźniki się nie poprawiają, trzeba zmienić zakres procesu, a nie automatycznie dopisywać kolejne funkcje.

Cykl dalszych usprawnień

W pierwszym miesiącu warto prowadzić krótki, regularny przegląd zadań, wyjątków, danych i błędów integracji. Dzięki temu zespół widzi, gdzie automatyzacja procesów oszczędza czas, a gdzie użytkownicy obchodzą nowy sposób pracy.

Kolejny etap może dodać raport, integrację albo prostszą ścieżkę obsługi wyjątku. Decyzja powinna wynikać z danych po starcie, a nie z pierwotnej listy życzeń.

Lista kontrolna przed startem MVP

• policz koszt obecnej pracy i opóźnień,
• opisz jeden proces od danych wejściowych do wyniku,
• wyznacz właściciela procesu oraz właścicieli zadań,
• wybierz tylko krytyczne źródła danych i integracje,
• zaplanuj obsługę wyjątków oraz decyzje człowieka,
• zaproś użytkowników do testów,
• ustal miernik i wartość bazową przed wdrożeniem,
• zaplanuj przegląd wyniku po pierwszym pełnym cyklu pracy.

Źródła pierwotne

Sposób wyboru procesu, wzór kalkulacji i granice MVP są metodą roboczą PP Solutions. Poniższe źródła wspierają mapowanie procesu, ustalanie kosztu bazowego i późniejszy pomiar efektu, ale nie gwarantują opłacalności konkretnej automatyzacji.

• OMG Business Process Model and Notation 2.0.2 — wspiera formalne opisywanie uczestników, zadań, zdarzeń, decyzji i przepływów potrzebnych do porównania procesu przed i po automatyzacji.
• GOV.UK Service Manual: how the discovery phase works — wspiera zalecenie zdefiniowania problemu, ograniczeń, obecnego kosztu i mierników sukcesu przed rozpoczęciem budowy rozwiązania.
• GOV.UK Service Manual: measuring the benefits of your service — wspiera tworzenie modelu korzyści na etapie testów oraz weryfikowanie założeń danymi po uruchomieniu usługi.