Wybór pierwszego procesu do automatyzacji, gdy każdy zespół ma inny pomysł

Dlaczego każdy zespół proponuje coś innego

Każdy dział proponuje pracę, która najbardziej mu doskwiera. To zrozumiałe, ale rzadko stanowi dobrą podstawę pierwszego projektu. Najbardziej widoczny problem często leży w procesie ze słabymi danymi, niejasnymi wynikami albo z obowiązkową oceną prawną na wejściu. Pierwszy projekt ma oprócz własnego wyniku drugie zadanie: tworzy zestaw testowy, dostęp do systemów i rutynę weryfikacji, z których skorzystają kolejne projekty. Udaje się to tylko wtedy, gdy zostanie ukończony.

Sześć pytań do oceny każdego kandydata

1. 1

   Wolumen

   Ile spraw wpływa miesięcznie i ile wykwalifikowanej pracy zajmuje każda? Pomnóżcie wolumen przez zmierzoną korzyść na sprawę i porównajcie to z kosztem budowy, kosztem utrzymania i nakładem weryfikacji. Niewielka liczba drogich spraw może uzasadnić projekt, a duża liczba banalnych może go nie uzasadniać.

2. 2

   Zmienność

   Czy sprawy różnią się w sposób, którego reguła nie uchwyci, na przykład wolnym tekstem, mieszanymi dokumentami albo brakującymi polami? Jeśli reguła działa, napiszcie regułę. Jeśli każda sprawa wymaga głębokiej oceny, agent odda większość z nich człowiekowi.

3. 3

   Dostęp

   Czy konto serwisowe może już dziś odczytać dane wejściowe i zapisać wyniki przez istniejące API? Kandydat, który najpierw potrzebuje nowej integracji, screen scrapingu albo oceny ochrony danych, ma przed sobą projekt przed projektem.

4. 4

   Koszt weryfikacji

   Ile czasu zajmuje człowiekowi sprawdzenie wyniku w porównaniu z wykonaniem pracy? Porównanie dwóch kwot z zamówieniem trwa sekundy. Sprawdzenie streszczenia umowy oznacza przeczytanie umowy.

5. 5

   Koszt pomyłki

   Czy błędny wynik da się wychwycić i cofnąć, zanim wyrządzi szkodę? Wewnętrzny błąd przekierowania kosztuje opóźnienie, a błędna płatność albo błędne zobowiązanie wobec klienta kosztuje więcej.

6. 6

   Znane wyniki

   Czy istnieją zamknięte sprawy, w których zapisano poprawny wynik? Bez nich nie zbudujecie zestawu testowego, a bez zestawu testowego nikt nie powie, czy system działa.

Te pytania odpowiadają fazie scopingu w AWS Generative AI Lens, która każe sprawdzić, czy generatywna AI w ogóle pasuje do problemu, jak będzie mierzony sukces, czy projekt jest wykonalny technicznie i organizacyjnie oraz czy potrzebne dane istnieją w użytecznej jakości.

Porównanie trzech propozycji krok po kroku

Poniższy przykład jest hipotetyczny. Dyrektor operacyjny dostaje trzy propozycje: obsługa klienta chce szkiców odpowiedzi na każdy przychodzący e-mail, finanse chcą dopasowywania faktur od dostawców do zamówień, a dział prawny chce przeglądu przychodzących umów pod kątem niestandardowych klauzul.

• Dopasowywanie faktur wypada dobrze. Wolumen jest wysoki, sprawy różnią się skanami, dostawami częściowymi i korektami, ERP ma API, księgowy sprawdza proponowane dopasowanie w kilka sekund, a lata zaksięgowanych faktur dostarczają znanych wyników. Błędne dopasowanie da się zatrzymać przed płatnością.
• Odpowiedzi na e-maile wypadają nierówno. Wolumen jest wysoki, a system pocztowy dostępny, ale dobra odpowiedź to kwestia oceny, wcześniejszych odpowiedzi nikt nie oceniał, a sprawdzenie złożonej odpowiedzi trwa prawie tyle, co jej napisanie. Węższy wycinek, na przykład klasyfikacja i przekierowanie przychodzącej poczty, wypada znacznie lepiej.
• Przegląd umów wypada słabo jako pierwszy projekt. Wolumen jest niski, przeoczona klauzula jest kosztowna, a prawnik i tak czyta całą umowę, więc koszt weryfikacji prawie się nie zmienia.

Dopasowywanie faktur idzie pierwsze. Przekierowywanie e-maili to rozsądny drugi kandydat, gdy pierwszy projekt zbuduje już rutynę testów i weryfikacji. Przegląd umów czeka, aż pojawi się powód, by oczekiwać spadku kosztu weryfikacji.

Sprawdźcie, czy wystarczy reguła

Zanim ocenicie kandydata jako projekt AI, weźcie pięćdziesiąt zamkniętych spraw i spróbujcie napisać dla nich reguły. Rules of Machine Learning od Google zaczynają się od rady, by nie bać się startu bez uczenia maszynowego, bo prosta heurystyka często prowadzi daleko. Artykuł Anthropic o agentach z 2024 roku rozróżnia podobnie: stałe workflowy pasują do dobrze zdefiniowanych zadań, a agenci do otwartych problemów, których kroków nie da się przewidzieć. NIST AI Risk Management Framework również każe rozważyć realne alternatywy bez AI.

Jeśli reguły obejmą większość z pięćdziesięciu spraw, zbudujcie reguły, a resztę przekażcie ludziom albo później modelowi. To udany wynik, a do tego zwykle tańszy w utrzymaniu i łatwiejszy do wyjaśnienia.

Przytnijcie zwycięzcę do pierwszego wycinka

Automatyzacja faktur to program. Dopasowywanie faktur w jednej walucie, z numerem zamówienia, dla czterdziestu dostawców o największym wolumenie, to pierwszy projekt. Ramy NIST wymagają określenia i udokumentowania docelowego zakresu zastosowania, a krótki opis zakresu robi właśnie to: które sprawy są w zakresie, a które nie, co system zwraca, kto to sprawdza i gdzie przekazuje sprawę dalej.

Udostępnienie ocen zespołom

Udostępnijcie oceny każdemu zespołowi, który coś zaproponował, razem z informacją, co mogłoby je zmienić. Kandydat, który przegrał przez dostęp, może wrócić, gdy powstanie API, a ten, któremu brakowało znanych wyników, może zacząć je zapisywać już teraz. Jeśli chcecie drugiej opinii o krótkiej liście, nasza praca nad agentami AI zaczyna się od rozrysowania jednego procesu i zmierzenia, ile dziś kosztuje jedna sprawa.

Agenci AI i automatyzacja procesówDane i dostępy potrzebne przed startem projektu