Automatyzacja workflow

Automatyzacja workflow

Przed automatyzacją ustalamy uczestników procesu, źródła danych, miejsca opóźnień, wyjątki i możliwe awarie oraz oczekiwany wynik. Jeśli zadanie ma jednoznaczne reguły, logika aplikacji może być prostsza, szybsza i bardziej przewidywalna niż AI.

Podział odpowiedzialności

| Uczestnik | Przykładowa odpowiedzialność | |---|---| | Aplikacja | tożsamość, uprawnienia, walidacja, obliczenia, stan procesu i dozwolone działania | | AI | proponowane kategorie i wartości z dokumentów, podsumowania, szkice odpowiedzi | | Upoważniona osoba | ocena wyjątków, korekty i decyzje wymagające zatwierdzenia |

To przykład podziału ról, nie obowiązkowa architektura. Zakres automatyzacji zależy od danych, skutków błędu i wymagań firmy. Wygenerowanie propozycji nie zmienia danych sprawy.

Jak może to wyglądać w praktyce

Rozważmy hipotetyczną obsługę zgłoszeń klientów. Aplikacja zapisuje wiadomość i przypisuje ją według swoich reguł. AI przygotowuje streszczenie i szkic odpowiedzi, a pracownik porównuje je z oryginałem i w razie potrzeby poprawia.

Przy fakturze AI może proponować odczytane pola. Aplikacja sprawdza formaty, kwoty, zgodność z regułami firmy i możliwe duplikaty. Upoważniona osoba weryfikuje dane w dotychczasowym obiegu zatwierdzania.

Inne hipotetyczne zastosowania to uporządkowanie zapytań sprzedażowych przed aktualizacją CRM oraz lista zadań dla nowego pracownika przygotowana z zatwierdzonych informacji. AI nie nadaje tu samodzielnie dostępu, nie zatwierdza płatności ani nie podejmuje wiążących decyzji.

Aplikacja: zapis zgłoszenia i kontrola dostępu
  |
  +-- AI: propozycja -> aplikacja sprawdza wynik
       |
       +-- poprawny -> pracownik ocenia / koryguje
       |              -> kontrola i zapis propozycji oraz oceny
       |
       +-- błąd / brak -> ustalona obsługa wyjątków
                         (np. praca ręczna)

Dalsza akcja, np. wysłanie odpowiedzi:
  zatwierdzona propozycja + uprawnienia + reguły
  -> wykonanie przez istniejącą aplikację

Po korekcie aplikacja ponownie sprawdza propozycję. Zapisanie jej wraz z oceną nie oznacza wysłania odpowiedzi; odrzucona propozycja nie jest stosowana.

Stan procesu i ponawianie zadań

Oryginalny dokument lub zgłoszenie, propozycję AI oraz sprawdzony lub zatwierdzony wynik przechowujemy oddzielnie. Status zadania pokazuje pracę oczekującą, zakończoną i błędy. Dłuższe zadania mogą trafić do kolejki, by nie blokować formularza. Sama kolejka nie zapewnia jednak niezawodnego wykonania.

Przekroczenie czasu, niedostępność dostawcy i błędna odpowiedź nie są sukcesem. Ponowienia mają limit i dotyczą błędów przejściowych, nie każdego niepowodzenia.

Idempotencja oznacza, że ponowienie tej samej operacji nie powiela jej skutków. Numer sprawy nie wystarcza: potrzebny jest klucz operacji, np. sprawa, zadanie i wersja danych, oraz trwały zapis wykonania. Ograniczenie unikalności w bazie i niepodzielny zapis chronią przed równoczesnym utworzeniem zduplikowanych rekordów wykonania. Nie gwarantują jednak pojedynczego wywołania dostawcy; jego obsługę duplikatów trzeba sprawdzić osobno.

Ścieżkę ręczną projektujemy i testujemy dla konkretnego procesu, ustalając, co można dokończyć bez AI i co musi poczekać.

Dane, bezpieczeństwo i wdrożenie

Do AI trafiają tylko potrzebne dane. Aplikacja kontroluje dostęp użytkowników i organizacji, sprawdza wyniki oraz zapisuje istotne decyzje w historii audytu. Wysoka ocena pewności modelu nie dowodzi poprawności danych i nie nadaje uprawnień. Przegląd przez człowieka uzupełnia te zabezpieczenia, ale ich nie zastępuje.

W GiSoft zaczynamy od ograniczonego zakresu. Mierzymy czas obsługi, poprawki pracowników, zaakceptowane propozycje, błędy i koszt ukończonej sprawy. Porównanie z dotychczasową obsługą pozwala zdecydować, czy rozszerzyć automatyzację, zmienić jej zasady, czy zrezygnować z AI w danym kroku.