Kupac pita zašto se za narudžbu ne može izvršiti povrat novca. Odgovor se ne nalazi u jednoj funkciji. On proizlazi iz evidencije plaćanja, statusa ispunjenja narudžbe, iznimke od pravila i prosudbe stručnjaka korisničke podrške koji zna koja je obećanja tvrtka dala.

To je poslovna logika: pravila, odluke i iznimke koji omogućuju da softver podržava poslovanje. AI asistent može pomoći ljudima da se snađu u toj logici, ali samo ako tim preuzme odgovornost za ono što asistent uči, što može učiniti i kako se njegovi odgovori provjeravaju.

Poslovna logika više je od koda

Razvojni programeri često se susreću s poslovnim pravilima u obliku uvjeta: za narudžbu se može izvršiti povrat novca ako ispunjava određene kriterije. U praksi stvarno pravilo može ovisiti i o ugovoru, regionalnom zahtjevu, nedavnoj promjeni pravila ili iznimci koja nikada nije ugrađena u aplikaciju.

Uzmimo za primjer poslovanje koje se temelji na pretplati. Podaci o pretplatničkom paketu kupca, datumu naplate i statusu računa mogu biti pohranjeni u softveru. Razlog zbog kojeg je određenom kupcu odobreno počekno razdoblje može se nalaziti u bilješci korisničke podrške. U međuvremenu, dokument s pravilima možda opisuje uobičajeni slučaj, ali ne govori ništa o osporenoj naplati.

AI sustav koji može čitati sav taj materijal nije automatski pouzdan. Može naići na proturječne verzije, previdjeti uvjet ili primijeniti pravilo na pogrešnog kupca. Omogućavanje pristupa informacijama početak je preuzimanja odgovornosti za sustav, a ne kraj.

Odredite što bi AI sustav trebao znati i raditi

Počnite s konkretnom odlukom ili radnim postupkom. „Pomoći djelatnicima korisničke podrške objasniti uvjete za povrat novca” lakše je osmisliti i vrednovati nego „razumjeti naše poslovanje”. Konkretniji cilj omogućuje utvrđivanje potrebnih informacija, osoba odgovornih za njih i cijene pogreške.

Razlikujte tri vrste znanja:

• Stalne definicije: Što u ovom kontekstu znače pojmovi kao što su „ispunjena narudžba”, „aktivna pretplata” ili „radni dan”.
• Trenutačne činjenice: Status narudžbe, povijest plaćanja i pravila koja se primjenjuju na određeni slučaj.
• Ovlast za odlučivanje: Koja pravila sustav smije primijeniti i koje iznimke zahtijevaju ljudsku prosudbu.

Ta razlika utječe na dizajn sustava. Stalne definicije mogu se održavati kao referentni materijal. Trenutačne činjenice trebale bi dolaziti iz sustava koji mogu pružiti ažurne informacije. Ovlast za odlučivanje treba biti uređena jasno definiranim radnim postupkom, s dozvolama i provjerama primjerenima mogućim posljedicama.

Primjerice, asistent može sažeti činjenice i djelatniku predložiti procjenu ispunjava li narudžba uvjete za povrat novca. Izvršavanje povrata zasebna je radnja. Korisno objašnjenje trebalo bi navesti pravila i činjenice na kojima se prijedlog temelji te upozoriti na informacije koje nedostaju ili su proturječne. Ako nije moguće dobiti podatak o statusu narudžbe, asistent bi to trebao reći umjesto da prazninu popuni uvjerljivom pretpostavkom.

Dodijelite odgovornost za znanje

Mnogi timovi otkriju da je njihov najveći problem s AI sustavom zapravo problem odgovornosti. Pravilo postoji, ali nitko ne zna koja je verzija mjerodavna. Polje ima poznat naziv, ali financije i operativni tim koriste ga na različite načine. Pravilo je uvedeno prije više godina, a njegov izvorni razlog zaboravljen je.

Za svaki važan izvor poslovne logike odredite odgovornu osobu ili tim. Ta osoba ili tim trebali bi moći objasniti što izvor obuhvaća, odobravati promjene i pomoći u rješavanju proturječja. Odgovornost ne znači da jedna osoba mora napisati svaki dokument. To znači da postoji jasan način da se dođe do odgovora kada sustav otkrije nejasnoću.

Održavajte znanje blizu posla koji dovodi do njegovih promjena. Kada proizvodni tim promijeni rok za povrat novca, povezana pravila, primjere i provjere trebalo bi preispitati u sklopu iste promjene. U suprotnom, aplikacija i asistent mogu se razići, iako se čini da oboje rade ispravno.

Za timove koji rade na daljinu posebno su važne odluke u pisanom obliku. Zabilježite pravilo, njegov opseg, nekoliko tipičnih primjera i razlog svake značajne iznimke. Kratak i ažuran zapis odluke korisniji je od dugog dokumenta kojem nitko ne vjeruje. Omogućite korisničkoj podršci, proizvodnom, operativnom i razvojnom timu da jednostavno prijave odgovor koji se čini pogrešnim.

Testirajte odluke, a ne samo tečne odgovore

Uvjerljiv odgovor i dalje može biti netočan. Vrednujte asistenta na slučajevima koji odražavaju posao koji ljudi doista obavljaju, uključujući uobičajene zahtjeve, granične uvjete, podatke koji nedostaju i iznimke.

U primjeru povrata novca mali skup slučajeva za provjeru mogao bi uključivati narudžbu koja ispunjava uvjete, narudžbu koja ih ne ispunjava, iznimku od pravila i slučaj u kojem podaci o ispunjenju narudžbe nisu dostupni. Za svaki slučaj odredite što dobar odgovor mora sadržavati: ispravnu procjenu kada je činjenice podupiru, relevantno obrazloženje i odgovarajući zahtjev za ljudsku provjeru kada je činjenice ne podupiru.

Uključite osobe odgovorne za pravila da zajedno s razvojnim programerima pregledaju pogreške. Je li izvor bio pogrešan, jesu li relevantne informacije bile nedostupne ili ih je asistent pogrešno protumačio? Te pogreške zahtijevaju različite ispravke. Pratite ih tijekom vremena i ponovno provodite testove s tipičnim slučajevima kada se promijene pravila, izvori podataka ili konfiguracija asistenta.

Provjerite i postupak koji okružuje sam odgovor. Ako izvor nije dostupan, može li korisnik to vidjeti? Ako djelatnik ispravi preporuku, postoji li način da se ispravak zabilježi radi provjere? Ako asistent može pokrenuti radnju, jesu li dozvole, potvrda i zapisi o tome što se dogodilo primjereni toj radnji? Pouzdanost sustava ovisi o njegovu ponašanju kada uobičajeni postupak zakaže.

Zadržite ljudsku kontrolu nad procesom učenja

„Uči o vašem poslovanju” ne bi smjelo značiti da svaki razgovor neprimjetno mijenja pravila tvrtke. Povratne informacije vrijedne su, ali ih treba protumačiti. Ispravak djelatnika korisničke podrške može otkriti iznimku koja nedostaje, jednokratnu prilagodbu ili nesporazum. Te činjenice nisu međusobno zamjenjive.

Uspostavite način da povratne informacije dođu do odgovorne osobe. Pregledavajte probleme koji se ponavljaju, ažurirajte relevantni izvor ili radni postupak i testirajte promjenu prije nego što se na nju počnete oslanjati. Tako se svakodnevna upotreba pretvara u sustavan proces poboljšavanja, uz očuvanje odgovornosti za pravila.

Počnite s pružanjem pomoći pri kojoj ljudi mogu provjeriti obrazloženje i uočiti pogreške. Proširite odgovornosti asistenta tek kada tim razumije načine na koje može pogriješiti i ima dokaze da se okolni radni postupak može nositi s tim pogreškama. Cilj nije ukloniti prosudbu iz poslovanja. Cilj je olakšati pronalaženje, objašnjavanje i primjenu valjane prosudbe.

Najvrjedniji AI sustav možda je onaj koji potakne tim da razjasni pravila na koja se godinama oslanjao. Kada je odgovornost jasna, znanje ima svoje mjesto, a neizvjesnost je vidljiva, asistent može postajati korisniji kako se poslovanje mijenja. Bez tih temelja može samo postati sigurniji u sve na što slučajno naiđe.