Analiza procesu do automatyzacji – AS-IS, TO-BE i wymagania

Automatyzacja nie zaczyna się od wyboru narzędzia. Zaczyna się od zrozumienia, jaki problem ma zostać rozwiązany, jak proces działa dzisiaj i po czym organizacja pozna, że zmiana rzeczywiście przyniosła wartość.

Robot RPA, platforma workflow, integracja API albo model AI mogą przyspieszyć wykonanie pracy. Nie odpowiedzą jednak samodzielnie na pytanie, czy dana praca jest potrzebna, dlaczego przebiega właśnie w taki sposób i które elementy procesu należy wcześniej uprościć.

Analiza procesu do automatyzacji łączy perspektywę biznesową, procesową i systemową. Jej rezultatem nie powinien być wyłącznie diagram. Potrzebny jest uzgodniony model działania, który pokazuje cel, dane, role, decyzje, wyjątki, mierniki i granicę odpowiedzialności pomiędzy człowiekiem a systemem.

W skrócie

najpierw należy poznać rzeczywisty proces AS-IS, a nie tylko oficjalną procedurę,
proces TO-BE powinien usuwać i upraszczać zbędne kroki przed ich automatyzacją,
automatyzować można zadania, decyzje lub przepływ, ale każdy z tych zakresów wymaga innego podejścia,
dane, reguły i wyjątki są częścią procesu, a nie technicznym dodatkiem do wdrożenia,
efekt należy mierzyć na poziomie procesu i wyniku biznesowego, nie tylko liczby wykonanych operacji.

Automatyzacja zaczyna się od problemu, nie od narzędzia

Projekt automatyzacji często rozpoczyna się od zdania: „chcemy wdrożyć RPA”, „potrzebujemy workflow” albo „dodajmy do procesu AI”. W każdym z tych przypadków nazwa technologii pojawia się wcześniej niż opis problemu.

Tymczasem ten sam problem może mieć kilka różnych przyczyn. Długi czas realizacji może wynikać z ręcznego przepisywania danych, ale również z oczekiwania na decyzję, brakujących informacji, zbyt wielu akceptacji albo niejasnego podziału odpowiedzialności. Automatyzacja tylko jednego kroku nie usunie pozostałych ograniczeń.

Jeżeli nie wiadomo, jaki problem rozwiązujemy, automatyzacja może bardzo sprawnie wykonywać czynność, która nie powinna już istnieć.

Analizę warto rozpocząć od czterech pytań:

Jaki wynik procesu jest potrzebny klientowi, użytkownikowi lub organizacji?
Co obecnie utrudnia albo opóźnia osiągnięcie tego wyniku?
Jaką zmianę chcemy uzyskać?
Po czym zmierzymy, że zmiana się udała?

Tak zdefiniowany problem wyznacza zakres dalszej analizy. Pozwala też oddzielić potrzebę biznesową od pierwszego pomysłu na jej techniczną realizację.

Proces AS-IS powinien pokazywać rzeczywistość

Punktem wyjścia jest poznanie procesu AS-IS, czyli obecnego sposobu wykonywania pracy. Nie chodzi jednak wyłącznie o przepisanie istniejącej procedury do notacji BPMN.

Procedura pokazuje, jak proces powinien działać. Analiza musi również sprawdzić, jak działa naprawdę: gdzie pracownicy tworzą własne arkusze, ręcznie kopiują dane, uzgadniają sprawy przez e-mail, czekają na odpowiedź albo obchodzą ograniczenia systemu.

Więcej o rozróżnieniu stanu obecnego i docelowego opisuje materiał Proces AS-IS i TO-BE. Do przedstawienia przebiegu można wykorzystać również podstawowe elementy opisane na stronie BPMN dla początkujących.

Dla każdego kroku procesu warto ustalić:

co uruchamia wykonanie,
kto odpowiada za pracę lub decyzję,
jakie dane są potrzebne,
z jakiego systemu pochodzą informacje,
ile trwa sama praca, a ile oczekiwanie,
jakie błędy i wyjątki występują,
co jest wynikiem kroku.

Dopiero taki obraz pozwala odróżnić czynność rzeczywiście wymagającą automatyzacji od problemu organizacyjnego, braku decyzji albo niepotrzebnego przekazania między rolami.

Automatyzacja zadania a automatyzacja procesu

Pojedyncza automatyzacja może wykonać jedno powtarzalne zadanie: pobrać załącznik, odczytać dane, przenieść informacje między systemami albo wysłać powiadomienie. To może przynieść oszczędność czasu, ale nie oznacza jeszcze, że został zautomatyzowany cały proces.

Proces obejmuje również kolejność działań, status sprawy, decyzje, odpowiedzialność, terminy, wyjątki i wynik końcowy. Jeżeli robot przenosi dane szybciej, ale sprawa nadal przez dwa dni czeka na nieokreślonego właściciela decyzji, główne ograniczenie procesu pozostaje bez zmian.

Zakres	Pytanie analityczne	Przykład
Zadanie	Jak zautomatyzować konkretną, powtarzalną czynność?	Przepisanie danych z dokumentu do systemu
Decyzja	Czy warunek można jednoznacznie opisać i zweryfikować?	Skierowanie sprawy do dodatkowej akceptacji po przekroczeniu limitu
Przepływ	Jak zarządzać kolejnością, statusem, terminem i odpowiedzialnością?	Przekazanie sprawy między rejestracją, weryfikacją i akceptacją
Proces end-to-end	Jak połączyć zadania, decyzje, ludzi i systemy w jeden kontrolowany przebieg?	Obsługa wniosku od wpływu do zamknięcia i poinformowania klienta

Zakres powinien wynikać z celu. Czasami wystarczy automatyzacja jednego zadania. W innym przypadku lokalne usprawnienie tylko przesunie problem do kolejnego etapu procesu.

Jak ocenić potencjał procesu do automatyzacji?

Nie każdy proces jest równie dobrym kandydatem. Wysoki wolumen i powtarzalność pomagają uzasadnić inwestycję, ale nie wystarczą. Ważne są również stabilność procesu, jakość danych, możliwość opisania reguł oraz koszt błędu.

Obszar	Pytanie	Sygnał pozytywny	Sygnał ostrzegawczy
Cel	Czy wiadomo, jaki wynik chcemy poprawić?	Mierzalny czas, koszt, jakość lub SLA	Ogólne hasło „pracować szybciej”
Wolumen	Jak często proces jest wykonywany?	Regularny i wystarczająco duży wolumen	Proces sporadyczny lub silnie sezonowy bez danych
Reguły	Czy decyzje można opisać?	Jawne warunki i właściciele decyzji	Decyzje oparte wyłącznie na doświadczeniu jednej osoby
Dane	Czy dane są dostępne i wiarygodne?	Znane źródła, formaty i walidacje	Braki, duplikaty i informacje w prywatnych plikach
Wyjątki	Jak często proces opuszcza ścieżkę standardową?	Znane klasy wyjątków i sposób eskalacji	Każda sprawa jest traktowana jako „indywidualna”
Stabilność	Czy proces i systemy często się zmieniają?	Uzgodniony model i plan zmian	Trwająca reorganizacja lub brak właściciela procesu
Ryzyko	Jaki jest skutek błędnego wykonania?	Możliwość kontroli i odwrócenia operacji	Nieodwracalna decyzja bez nadzoru człowieka

Ocena nie musi prowadzić do odpowiedzi „automatyzować” albo „nie automatyzować”. Często poprawnym wynikiem jest decyzja o wcześniejszym uproszczeniu procesu, poprawie danych, ujawnieniu reguł lub ograniczeniu pierwszego wdrożenia do bezpiecznego zakresu. Praktyczne rozwinięcie tej oceny pokazuje analiza procesu pod automatyzację.

Dane są częścią procesu

Na diagramie dane bywają niewidoczne, mimo że to one uruchamiają decyzje i działania. System nie może poprawnie wykonać procesu, jeżeli nie wiadomo, skąd pochodzą informacje, kto jest ich właścicielem i jak rozpoznać brak albo błąd.

Dla kluczowych danych należy opisać:

źródło i właściciela,
format oraz znaczenie biznesowe,
moment powstania i aktualizacji,
reguły walidacji,
wymagany poziom kompletności,
uprawnienia i ograniczenia dostępu,
sposób postępowania przy braku lub sprzeczności.

Automatyzacja nie poprawia automatycznie jakości danych. Może natomiast szybciej rozpowszechnić błąd do kolejnych systemów. Dlatego walidacja, identyfikacja źródła i możliwość śledzenia zmiany powinny zostać ustalone przed wyborem technologii.

Reguły biznesowe i punkty decyzyjne

Każda bramka na diagramie BPMN powinna prowadzić do pytania: dlaczego proces wybiera tę ścieżkę? Odpowiedź może wynikać z prostej reguły, tabeli decyzji, uprawnienia, oceny eksperckiej albo kombinacji kilku przesłanek.

Regułę można automatyzować wtedy, gdy jej warunki są jawne, dane dostępne, a wynik możliwy do sprawdzenia. Jeżeli decyzja zależy od nieopisanego doświadczenia pracownika, najpierw należy ustalić, jakie informacje rzeczywiście bierze on pod uwagę.

Połączenie procesu z wymaganiami zostało szerzej opisane w materiale Jak łączyć BPMN z wymaganiami. Diagram pokazuje miejsce decyzji, natomiast wymagania powinny doprecyzować dane, warunki, rezultat, komunikaty, uprawnienia i kryteria akceptacji.

Wyjątek nie jest awarią analizy

Ścieżka podstawowa zwykle wygląda atrakcyjnie: dane wpływają, system je przetwarza, decyzja zostaje podjęta, a proces kończy się sukcesem. Rzeczywiste procesy zawierają jednak brakujące dokumenty, sprzeczne dane, niedostępne systemy, przekroczone terminy i przypadki wymagające ludzkiej oceny.

Dla każdego istotnego wyjątku należy określić:

jak system lub pracownik go rozpoznaje,
do jakiej kategorii należy,
kto jest właścicielem dalszej decyzji,
jakie informacje trzeba przekazać,
jaki obowiązuje termin reakcji,
czy i jak sprawa wraca do procesu głównego,
czy przyczyna wyjątku będzie później analizowana.

Proces bez ścieżki wyjątków opisuje prezentację rozwiązania. Proces produkcyjny musi wiedzieć, co zrobić również wtedy, gdy rzeczywistość nie przeczytała instrukcji.

Przekazanie sprawy człowiekowi nie jest porażką automatyzacji. Jest poprawnym zachowaniem systemu, jeżeli decyzja przekracza jego zakres, poziom pewności albo uprawnienia.

Proces TO-BE: najpierw usuń i uprość

Proces TO-BE nie powinien być kopią AS-IS z ikoną robota przy każdym zadaniu. Automatyzacja daje możliwość przeprojektowania pracy, dlatego właściwa kolejność jest inna:

usuń krok, który nie tworzy wartości ani nie jest wymagany,
uprość przekazania i ogranicz oczekiwanie,
ujednolić dane oraz nazwy,
ujawnij reguły i właścicieli decyzji,
zaprojektuj obsługę wyjątków,
ustal mierniki,
dopiero potem dobierz technologię.

Proces docelowy powinien pokazywać nie tylko szybsze wykonanie, lecz również prostszy przebieg, mniejszą liczbę niejasnych przekazań i lepszą kontrolę wyniku. Dopiero na podstawie takiego modelu warto porównać technologie automatyzacji i ocenić, czy proces wymaga workflow, RPA, integracji API, low-code czy wsparcia AI.

Przykład: obsługa wniosku przesyłanego e-mailem

Rozważmy proces obsługi wniosku, który klient przesyła jako załącznik do wiadomości e-mail.

Stan AS-IS

pracownik otwiera wiadomość i zapisuje załącznik,
ręcznie sprawdza kompletność danych,
przepisuje podstawowe informacje do arkusza,
przesyła wiadomość do osoby podejmującej decyzję,
oczekuje na odpowiedź bez wspólnego statusu sprawy,
po decyzji aktualizuje arkusz i odpowiada klientowi.

W trakcie analizy okazuje się, że największym problemem nie jest samo zapisanie załącznika. Proces traci czas przez brakujące dane, ręczne przepisywanie, niejasnego właściciela decyzji oraz brak wspólnej kolejki spraw.

Stan TO-BE

wiadomość zostaje zarejestrowana i otrzymuje identyfikator,
dane z formularza lub załącznika są odczytywane i walidowane,
kompletna sprawa trafia do właściwej ścieżki decyzyjnej,
braki i przypadki nietypowe trafiają do kolejki wyjątków z właścicielem,
status i terminy są widoczne dla osób uczestniczących w procesie,
klient otrzymuje informację o przyjęciu, brakach i zakończeniu sprawy,
system mierzy czas cyklu, liczbę wyjątków i przyczyny odrzuceń.

W takim modelu technologia jest konsekwencją analizy. Odczyt dokumentu może wykorzystywać klasyczne reguły lub AI, przepływ może obsługiwać workflow, a dane mogą trafiać do systemu przez API. Analityk nie musi jeszcze wskazywać produktu. Powinien natomiast opisać, czego rozwiązanie ma dokonać i w jakich warunkach.

Jakie artefakty powinny powstać?

Analiza procesu do automatyzacji powinna pozostawić zestaw spójnych materiałów, na podstawie których biznes i IT mogą podjąć decyzję oraz przygotować wdrożenie.

cel biznesowy i mierniki stanu obecnego,
granice procesu oraz właściciel wyniku,
model AS-IS potwierdzony z wykonawcami procesu,
lista problemów, opóźnień i czynności ręcznych,
model TO-BE po usunięciu i uproszczeniu zbędnych kroków,
opis danych i ich źródeł,
reguły biznesowe oraz tabela decyzji, gdy jest potrzebna,
katalog wyjątków i sposób eskalacji,
zakres automatyzacji oraz granica człowiek–system,
wymagania funkcjonalne i niefunkcjonalne,
kryteria akceptacji i scenariusze testowe,
KPI, baseline i oczekiwany rezultat.

Wymagania wynikające z procesu można dalej uporządkować z wykorzystaniem sekcji Wymagania i dokumentacja.

Rola AI w analizie procesu

AI może pomóc uporządkować notatki z warsztatów, zaproponować pytania kontrolne, znaleźć niespójne nazwy lub podzielić materiał na kroki, decyzje i wyjątki. Nie zna jednak automatycznie realiów organizacji ani nie potwierdzi, że opis odpowiada rzeczywistemu sposobowi pracy.

Wynik modelu powinien być traktowany jako szkic do weryfikacji z właścicielem i wykonawcami procesu. Temat rozwija materiał AI w analizie procesów.

Kiedy analiza jest wystarczająca?

Analiza nie musi opisywać każdego przyszłego szczegółu technicznego. Powinna jednak ograniczyć niepewność na tyle, aby zespół mógł świadomie podjąć kolejne decyzje.

Można przejść do projektu rozwiązania, gdy:

cel i zakres są uzgodnione,
proces AS-IS został potwierdzony z osobami wykonującymi pracę,
TO-BE wskazuje, co usuwamy, upraszczamy i automatyzujemy,
dane, reguły i kluczowe wyjątki są opisane,
właściciele decyzji i odpowiedzialności są znani,
istnieją mierniki stanu obecnego oraz celu,
zespół potrafi określić kryteria wyboru technologii i pilotażu.

Brak odpowiedzi na wszystkie pytania nie musi blokować pracy. Braki powinny być jednak jawne, przypisane do właścicieli i uwzględnione jako ryzyko albo zadanie do potwierdzenia. Po domknięciu kluczowych ustaleń materiał analityczny może bezpiecznie przejść do etapu wdrożenia automatyzacji krok po kroku.

Od analizy biznesowej do projektu automatyzacji

Analiza biznesowa odpowiada przede wszystkim na pytania: co warto zmienić, dlaczego i w jakim zakresie. Kolejny etap obejmuje dobór architektury, technologii, sposobu wdrożenia, monitoringu i utrzymania.

Serwis Automatyzacja.online rozwija dalszą warstwę tej ścieżki: projekt rozwiązania, realizację, monitoring i utrzymanie. Dzięki temu analiza biznesowa pozostaje źródłem decyzji o zakresie, a technologia jest dobierana do uzgodnionego procesu.

Pytania kontrolne

Jaki problem biznesowy ma rozwiązać zmiana?
Jak proces działa w rzeczywistości, a nie tylko w procedurze?
Które kroki tworzą wartość, a które są obejściem lub stratą?
Jakie dane sterują działaniem i decyzjami?
Czy reguły są jawne i możliwe do sprawdzenia?
Jakie wyjątki występują i kto je obsługuje?
Co powinien wykonać system, a co pozostać decyzją człowieka?
Jak zmierzymy rezultat przed wdrożeniem i po nim?

Powiązane materiały

Podsumowanie

Automatyzacja procesu nie jest prostym zastąpieniem człowieka narzędziem. Jest zmianą sposobu wykonywania pracy, przepływu danych, podejmowania decyzji i kontroli wyniku.

Dlatego analiza powinna rozpocząć się od celu i rzeczywistego procesu AS-IS. Następnie należy usunąć zbędne czynności, zaprojektować TO-BE, opisać dane, reguły, wyjątki, odpowiedzialność oraz mierniki. Dopiero wtedy wybór technologii staje się decyzją wynikającą z potrzeb procesu, a nie próbą dopasowania organizacji do wcześniej kupionego narzędzia.