AI rysuje proces: ładny schemat może zgubić drogę wyjścia

Na schemacie wszystkie strzałki prowadzą do „Wydano zestaw”. Klient może nie dosłać wymiarów, zrezygnować albo zmienić termin, lecz diagram nie przewiduje dla niego takiej swobody. Narysowana firma obsługuje wyłącznie ludzi zdecydowanych, kompletnych i punktualnych. To wygodna klientela — szkoda, że nie zawsze przychodzi do prawdziwego punktu obsługi.

W fikcyjnej wypożyczalni Doba AI zamienia opis rezerwacji wyposażenia w schemat. Zespół chce używać go do rozmowy o procesie, zanim cokolwiek zautomatyzuje. Odbiór polega na porównaniu rysunku z uzgodnionymi warunkami i przeprowadzeniu przez niego konkretnych spraw. Nie jest formalną certyfikacją modelu i nie wymaga jednej określonej notacji. Ładna grafika ma pomóc zauważyć decyzje, a nie zastąpić ich ustalenie.

Najpierw zachowaj warunki, które łatwo skrócić

W materiale wejściowym oddziel czynności, warunki, zdarzenia i zakończenia. „Pracownik sprawdza komplet danych” jest czynnością. „Jeśli brakuje wymiaru, prosi o uzupełnienie” opisuje warunek dalszej drogi. „Klient rezygnuje” jest zdarzeniem, które może zmienić przebieg. „Rezerwacja zamknięta po rezygnacji” oznacza inne zakończenie niż wydanie wyposażenia. Nie sprowadzaj wszystkiego do listy kolejnych prostokątów.

Dla Doby zapisujemy robocze zasady przykładu. Do przygotowania rezerwacji potrzebne są termin, wybrany zestaw i wymagany wymiar. Brak danych prowadzi do prośby o uzupełnienie. Rezygnacja wymaga zatrzymania przygotowania i oznaczenia sprawy. Wydanie zestawu wymaga potwierdzenia wykonania tej czynności. To założenia fikcyjnego obiegu, które w rzeczywistej firmie musi potwierdzić właściciel procesu.

Zaznacz również luki. Jeżeli opis nie mówi, co zrobić po braku odpowiedzi klienta, nie pozwalaj AI samodzielnie ustalić trzech przypomnień i zamknięcia po tygodniu. Poproś o oznaczenie nierozstrzygniętej reguły. Model może przygotować wariant do rozmowy, ale powinien być widoczny jako propozycja. W przeciwnym razie decyzja generatora ukryje się w rysunku pod pozorem dokumentowania obecnej pracy.

Do każdego istotnego warunku przypisz fragment źródła i osobę potwierdzającą. Krótka identyfikacja wystarczy: opis rezerwacji, wersja instrukcji, uzgodnienie właściciela. Nie kopiuj całej firmowej korespondencji do diagramu. Kolejna osoba powinna móc odtworzyć, dlaczego po jednym zdarzeniu wolno wydać zestaw, a po innym proces ma się zatrzymać.

Jeśli opis pochodzi z rozmowy kilku zespołów, sprawdź sprzeczności przed generowaniem. Jedna osoba może mówić o rezerwacji wstępnej, druga o potwierdzonej. Takie słowa nie powinny przypadkiem opisywać tego samego pola. Mapa usługi łącząca kontakt i zaplecze pomaga zobaczyć różne perspektywy. W odbiorze diagramu sprawdzamy potem, czy uzgodnione różnice przetrwały uproszczenie do rysunku.

Oznacz również, czy rysunek opisuje pracę obecną, czy proponowaną zmianę. Doba może dziś ręcznie potwierdzać rezygnację, a w przyszłości chcieć automatycznego zatrzymania przygotowania. Obie wersje wymagają osobnej nazwy i daty. Jeśli model połączy je bez objaśnienia, zespół może uznać planowaną funkcję za już działającą. W przeglądzie każda różnica powinna prowadzić do pytania o stan obecny lub świadomą decyzję projektową.

Ustal granice modelu. Może zaczynać się od przyjęcia zapytania i kończyć potwierdzeniem wydania, a dalszy zwrot wyposażenia pozostawić poza zakresem. Wtedy trzeba tę granicę podpisać. Brak zwrotu na rysunku nie jest błędem, jeśli świadomie wyłączono go z modelu. Brak ścieżki rezygnacji w objętej zakresem rezerwacji jest inną sytuacją i wymaga wyjaśnienia.

Przeprowadź sprawy, które nie mają identycznego finału

Zanim obejrzysz szczegóły wyglądu, przygotuj kilka małych kart przypadków. Każda zawiera dane początkowe, kolejne zdarzenia i uzgodniony wynik. W naszym przykładzie wybieramy cztery:

1. Klient podał pełne dane, zestaw jest dostępny, pracownik potwierdził przygotowanie i wydanie. Sprawa powinna dojść do potwierdzonego wydania.
2. Brakuje wymiaru. Klient uzupełnia go po pytaniu pracownika. Sprawa wraca do oceny danych, zamiast automatycznie przeskakiwać do wydania.
3. Klient rezygnuje przed przygotowaniem zestawu. Zespół zatrzymuje dalsze czynności i zapisuje właściwe zakończenie, bez potwierdzania wydania.
4. Termin zmienia się po wstępnym sprawdzeniu dostępności. Przed dalszym krokiem trzeba ponownie ocenić warunek dostępności dla nowego terminu.

To projekt próby na fikcyjnych danych, nie raport z przeprowadzonego wdrożenia. Dla każdej karty przejdź po widocznych połączeniach i zapisz miejsce zatrzymania albo nieuprawnionego skrótu. Nie dopowiadaj brakującej strzałki gestem, bo „wszyscy wiedzą, że można wrócić”. Przyszły użytkownik diagramu nie zawsze będzie mieć obok autora z długopisem.

Przy rozgałęzieniu zapytaj, kto i na jakiej podstawie wybiera dalszą drogę. Etykiety „tak” i „nie” mają sens tylko przy jednoznacznym pytaniu. „Dane poprawne?” może oznaczać ich kompletność, zgodność z ofertą albo zatwierdzenie przez pracownika. Jeśli te oceny prowadzą do różnych działań, rozdziel je. Dodatkowy krok na rysunku bywa czytelniejszy niż trzy znaczenia schowane w jednym rombie.

W formalnej notacji BPMN, czyli sposobie opisywania procesów za pomocą określonych elementów, symbole rozgałęzień mają konkretne znaczenia. Specyfikacja OMG BPMN 2.0.2 odróżnia między innymi wybór jednej alternatywnej drogi od uruchomienia dróg równoległych. Jeśli zespół używa tej notacji, przypadkowa zamiana symbolu może więc zmienić sens modelu. W prostym schemacie własnym również trzeba jasno wyjaśnić znaczenie połączeń.

Przy pytaniu o dostępność uwzględnij także stan „jeszcze nie sprawdzono”. Nie jest on ani potwierdzeniem wolnego zestawu, ani potwierdzeniem jego braku. Diagram ma wskazywać czynność, która pozwoli rozstrzygnąć pytanie. Jeżeli informacja przychodzi z innego systemu, brak odpowiedzi powinien zachować własny stan. Zespół musi ustalić dalszą obsługę, zamiast pozwalać generatorowi wybrać dogodną gałąź dla nieznanej wartości.

Doba może osobno przygotować zestaw i wysłać informację klientowi. Jeśli obie czynności są potrzebne, diagram powinien wyjaśniać, kiedy wolno przejść dalej. Nie łącz dwóch gałęzi w jeden punkt tylko dlatego, że wizualnie robi się porządniej. Ustal, czy dalszy krok wymaga obu potwierdzeń, jednego z nich, czy innego warunku. Nazwa „połącz” nie odpowiada na to pytanie.

W każdym oczekiwaniu sprawdź zdarzenie, które je kończy. „Czekamy na dane” wymaga możliwości rozpoznania odpowiedzi i związania jej z właściwą sprawą. Jeśli reguła czasu oczekiwania nie została ustalona, pozostaw otwarte pytanie. Nie kieruj sprawy po prostu do sukcesu, żeby pozbyć się luźnej strzałki. Ładny koniec linii nie potwierdza zakończenia obsługi.

Rozróżnij przekazanie pracy od jej przyjęcia. Zadanie wysłane do innego działu może nadal wymagać potwierdzenia odpowiedzialności i przekazania potrzebnego kontekstu. Przy pracy kilku agentów podobny problem opisuje odbiór przekazania zadania między agentami AI. Samo połączenie dwóch pól nie dowodzi, że druga strona otrzymała dane wystarczające do działania.

W miejscu przekazania wyjątku wskaż następną czynność i odpowiedzialną rolę. Kolejka wyjątków nie kończy sprawy samym przyjęciem rekordu. Jeżeli diagram odsyła tam sprawy z brakującymi danymi, osoba korzystająca z niego powinna znaleźć regułę powrotu albo zakończenia. Pełna reguła nie musi mieścić się na jednym obrazie, ale odsyłacz do dalszego opisu powinien być jednoznaczny i dostępny.

Sprawdź również moment zakończenia. Wysłanie prośby o odbiór nie oznacza jeszcze wydania zestawu. Zamknięcie po rezygnacji nie oznacza udanej realizacji. Jeśli wszystkie drogi kończą się etykietą „gotowe”, zespół może później pomylić los sprawy z wykonaniem określonej czynności. Nazwij zakończenia według tego, co potwierdzają, i wskaż podstawę tego potwierdzenia.

Otwarty plik nie potwierdza poprawnego opisu pracy

Schemat może mieć postać obrazu albo pliku, którego elementy da się dalej edytować. Ustal, co zespół ma otrzymać. Jeżeli planuje zmieniać warunki i połączenia, sam obraz wymaga innego sposobu utrzymania niż uzgodniony model edytowalny. W odbiorze sprawdź rzeczywisty materiał i możliwość wykonania potrzebnej zmiany, a nie wyłącznie rozszerzenie pliku.

Dokumentacja bpmn-js opisuje odczyt, kontrolę zgodności i zapis struktury BPMN XML. Chodzi o zapis elementów i połączeń w określonym formacie pliku oraz reguły narzędzia. Z tego wynika wąska granica odbioru: poprawne otwarcie pliku w edytorze nie jest dowodem, że zawiera on wszystkie uzgodnione przypadki firmy. To drugi problem do sprawdzenia na źródle i kartach spraw.

Podobnie poprawna struktura JSON z AI nie rozstrzyga znaczenia danych. Nie przekreślaj kontroli technicznej — ona może wykryć własne błędy. Zapisz jednak osobno wynik importu, zgodność użytych elementów i wynik przejścia przypadków. W raporcie nazwij każdy z tych wyników osobno, zamiast zamykać je wspólnym „sprawdzono”.

Sprawdź także eksport do formatu, który zobaczą osoby omawiające proces. Drobna etykieta warunku może zniknąć albo stać się nieczytelna. Dwie krzyżujące się linie mogą wyglądać jak połączenie, którego nie ma w modelu. Poproś osobę nieuczestniczącą w tworzeniu o przejście jednej karty na tym materiale. Jej pytanie pozwala znaleźć niejasność bez odgadywania, czy winny jest opis, plik czy układ.

Nie zakładaj, że model przeznaczony do rozmowy jest gotową konfiguracją automatyzacji. Wykonanie wymaga dalszych ustaleń o danych, uprawnieniach, potwierdzeniach i obsłudze błędów. Audyt automatyzacji procesów firmowych dotyczy takiego działającego obiegu. Odbiór rysunku dostarcza podstawy do następnej pracy, ale nie zastępuje jej wyniku.

Poprawka jednej drogi powinna zachować pozostałe

Dopisanie rezygnacji może zmienić reguły przygotowania, powiadomień i zakończenia sprawy. Po zmianie przejdź ponownie przypadek rezygnacji oraz te wcześniejsze karty, których przebieg się zmienił. Nie ograniczaj kontroli do obejrzenia nowego pola. Część procesu mogła już zostać wykonana w momencie zdarzenia, a dalszy los tej pracy wymaga osobnego uzgodnienia.

Dodaj przypadek spóźnionej wiadomości. Po rezygnacji może nadejść wcześniejsze potwierdzenie przygotowania. Schemat nie powinien bez reguły przywracać sprawy do drogi wydania tylko dlatego, że ten komunikat zobaczono później. Spóźnione statusy automatyzacji pomagają odróżnić kolejność odbioru informacji od jej znaczenia dla obecnego stanu.

Sprawdź model podczas przekazania sprawy innej uprawnionej osobie. Czy z rysunku i wskazanej instrukcji rozpozna aktualny stan oraz rolę odpowiedzialną za następny krok? Nazwisko autora w komentarzu nie zastępuje reguły zastępstwa. Gdy nieobecność jednej osoby blokuje odczyt modelu, popraw sposób zapisu i dostęp do objaśnień. Ta próba dotyczy użyteczności dokumentacji, bez potwierdzania technicznego wykonania automatyzacji.

Przy rozbieżności ustal, czy trzeba poprawić rysunek, opis źródłowy czy sam sposób pracy. Dwie osoby mogą inaczej rozumieć ten sam warunek. W takim przypadku nowy diagram nie rozstrzyga sporu. Zapisz pytanie, osobę decydującą i wpływ braku ustalenia na dalszy etap. Dopiero potwierdzoną regułę włącz do kolejnej wersji.

Zachowaj poprzedni model, zakres poprawki i powiązanie z materiałem źródłowym. Gdy AI rysuje od nowa cały schemat, porównaj także pozornie niezmienione drogi. Poprawka jednego wyjątku nie upoważnia do usunięcia warunku z innej części procesu. Lista różnic pomoże odbierającemu skupić uwagę na rzeczywistych zmianach.

W Aeneia Audit można zacząć od jednego modelu i kilku rozstrzygających kart spraw. W Dobie użyteczny schemat pokazuje nie tylko wydanie zestawu, ale też oczekiwanie, ponowną ocenę i zakończenie po rezygnacji. Dzięki temu diagram pozwala porozmawiać o pracy, która naprawdę może się wydarzyć, zamiast uprzejmie odsyłać każdego klienta do tej samej strzałki sukcesu.