Jak opisać proces przed automatyzacją

Opis procesu potrzebny do automatyzacji nie jest dekoracyjnym schematem. Ma umożliwić zespołowi wdrożeniowemu zrozumienie wejścia, wyniku, decyzji i sytuacji, w których rozwiązanie powinno się zatrzymać albo przekazać sprawę człowiekowi. Musi też być rozpoznawalny dla osób wykonujących pracę na co dzień.

Najczęstszy błąd polega na rysowaniu przebiegu z pamięci podczas jednego spotkania. Powstaje wtedy wersja oficjalna, pozbawiona ręcznych poprawek, arkuszy pomocniczych, wiadomości i nieformalnych uzgodnień. Automatyzacja zbudowana na takim obrazie napotyka wyjątki dopiero po uruchomieniu. Poniższe kroki pomagają opisać stan obecny wystarczająco dokładnie, bez tworzenia wielomiesięcznego projektu dokumentacyjnego.

Ustal granice i oczekiwany wynik

Najpierw nazwij zdarzenie rozpoczynające i kończące analizowany zakres. „Obsługa zamówienia” jest zbyt szeroka, jeśli nie wiadomo, czy zaczyna się od wysłania koszyka, zaksięgowania płatności czy wpłynięcia danych do systemu. Podobnie „zamówienie obsłużone” może oznaczać akceptację, wysyłkę albo potwierdzenie dostarczenia.

Granice powinny odpowiadać problemowi wybranemu wcześniej. Jeżeli celem jest skrócenie czasu rejestracji, nie trzeba od razu odwzorowywać całej realizacji zamówienia. Z drugiej strony zakres nie może urywać się przed miejscem, w którym da się ocenić wynik. Pomoc w ocenie kandydatów zawiera materiał jak wybrać proces do automatyzacji.

Wejście, wyjście i właściciel

Zapisz, jakie minimalne dane lub dokumenty uruchamiają proces oraz jak wygląda poprawny rezultat. Wskaż odbiorcę wyniku i osobę odpowiedzialną za cały zakres. Właściciel procesu zatwierdza reguły, rozstrzyga spory między zespołami i przyjmuje wynik wdrożenia. Poszczególne kroki mogą mieć innych wykonawców, ale odpowiedzialność za efekt nie powinna się rozmywać.

Dobry opis granic mieści się w kilku zdaniach: „Proces zaczyna się, gdy kompletne zgłoszenie otrzymuje identyfikator. Kończy się, gdy sprawa zostaje poprawnie przypisana i osoba obsługująca otrzymuje wszystkie załączniki. Właścicielem jest kierownik obsługi”. Dopiero potem warto przejść do szczegółów.

Odtwórz rzeczywisty przebieg

Wybierz kilka zakończonych spraw: typowe, trudniejsze i takie, które wróciły do poprawy. Przejdź przez nie razem z wykonawcami, ekran po ekranie i dokument po dokumencie. Pytaj, skąd wiadomo, jaki krok wykonać, gdzie trafia wynik, co powoduje oczekiwanie oraz jak rozpoznawany jest błąd. Notuj również czynności poza głównym systemem.

Użyj prostego zapisu: numer kroku, wykonawca, działanie, wejście, wynik, system i orientacyjny czas. Dodaj kolumnę „oczekiwanie”, ponieważ długi czas przejścia często nie wynika z samej pracy, lecz z kolejki lub przekazania. Na tym etapie nie próbuj jeszcze projektować lepszej wersji. Najpierw trzeba zrozumieć, co dzieje się obecnie.

Porównaj obserwację z obowiązującą instrukcją. Rozbieżność nie musi oznaczać błędu pracownika. Instrukcja może być nieaktualna, system może wymuszać obejście albo cel dwóch zespołów może być sprzeczny. Zapisz różnicę oraz osobę, która rozstrzygnie docelową regułę.

Zapisz decyzje, dane i systemy

Lista czynności nie wystarczy, jeśli proces zawiera rozgałęzienia. Dla każdej decyzji potrzebna jest reguła, dane wejściowe i możliwe wyniki. To pozwala odróżnić krok możliwy do wykonania według stałej zasady od sytuacji wymagającej osądu.

Decyzje i reguły

Zamiast pisać „sprawdź poprawność”, określ warunki: które pola są obowiązkowe, jaki format jest dozwolony, z czym porównujemy wartość i co dzieje się po niespełnieniu warunku. Jeśli reguła zależy od doświadczenia, poproś o przykłady graniczne. Być może da się ją uściślić, a być może powinien pozostać punkt akceptacji człowieka.

Zapisz właściciela każdej reguły oraz sposób jej zmiany. Automatyzacja powinna korzystać z kontrolowanego źródła zasad, a nie z wartości ukrytych w konfiguracji, których nikt operacyjnie nie nadzoruje.

Dane i uprawnienia

Dla każdego pola określ źródło, format, identyfikator łączący rekordy, dopuszczalny brak wartości i system docelowy. Sprawdź próbkę, zamiast opierać się wyłącznie na opisie struktury. Zwróć uwagę na duplikaty, różne formaty dat, znaki specjalne i wartości wpisywane swobodnie.

Osobno opisz dostęp: jaka tożsamość wykona operację, jaki minimalny zakres uprawnień jest potrzebny i kto zatwierdzi dostęp. Nie zakładaj, że uprawnienia użytkownika można bezpiecznie przekazać rozwiązaniu. Zależnie od wymaganego śladu odpowiedzialności może to być minimalnie uprawniona tożsamość techniczna albo delegowany kontekst użytkownika. W obu wariantach trzeba przewidzieć rotację poświadczeń, rejestr operacji oraz odebranie dostępu po wycofaniu automatyzacji.

Oddziel warianty od wyjątków

Wariant jest przewidywalną ścieżką, na przykład obsługą innego typu klienta według osobnego zestawu reguł. Wyjątek to sytuacja, której nie da się poprawnie rozstrzygnąć w bieżącym zakresie: brak danych, niespójność systemów, przypadek wymagający decyzji lub awaria. To rozróżnienie pomaga zdecydować, co obejmuje pierwsza wersja.

Dla każdego wyjątku zapisz sposób wykrycia, bezpieczne zachowanie, odbiorcę zgłoszenia i dane potrzebne do ręcznego dokończenia sprawy. Sam komunikat „błąd” nie wystarczy. Sprawa nie może zniknąć między kolejkami ani zostać wielokrotnie wykonana bez kontroli. Ustal także, czy po poprawie można ją wznowić, czy trzeba rozpocząć od nowa.

Przelicz udział wariantów i wyjątków na reprezentatywnej próbce. Jeżeli podstawowa ścieżka obejmuje niewielką część wolumenu, pilot ograniczony tylko do niej może wyglądać dobrze, lecz nie wpłynie na wynik całego procesu. Wtedy warto uprościć reguły albo wybrać inny zakres.

Przygotuj kontrakt wdrożenia

Z opisu stanu obecnego wyprowadź zwięzły kontrakt: zdarzenie startowe, zakres spraw, wymagane dane, kolejne działania, reguły, wyłączenia, obsługę błędów i oczekiwany wynik. Dodaj kryteria odbioru zapisane jako obserwowalne zachowanie. Przykład: „dla kompletnego zgłoszenia system tworzy dokładnie jeden rekord, zachowuje identyfikator źródłowy i w ciągu pięciu minut zwraca status”.

Kryteria powinny obejmować też negatywne przypadki: brak obowiązkowego pola nie tworzy częściowego rekordu, awaria systemu docelowego nie powoduje utraty zgłoszenia, a ponowienie nie generuje duplikatu. Wskaż osobę zatwierdzającą każdy warunek.

Na koniec połącz kontrakt z planem pomiaru opisanym w artykule jak mierzyć efekty automatyzacji. Dokument procesu mówi, co rozwiązanie ma robić; plan pomiaru odpowiada, czy ta zmiana poprawiła wynik. Oba elementy są potrzebne przed pilotem w ramach metody automatyzacji.