Na ovoj stranici
Demonstracija čita primjer računa, izvlači iznos i uredno upisuje sažetak u sustav odobravanja. U stvarnom procesu računi stižu iz tri kanala, neki pripadaju drugoj pravnoj osobi, a sustav odobravanja prihvaća samo korisnike s određenom ulogom. Izdvajanje podataka i dalje radi. Tijek rada ne radi. Ovo je zamišljen slučaj, a ne izvješće o kupcu.
Rasprava o uvođenju AI-ja u starije poslovne sustave upućuje na podatke, postojeći softver i lokalne navike kao tvrdoglavi dio uvođenja. Opisana je praksa jedne tvrtke, a ne opća stopa uspjeha. Korisna je razlika između dokazivanja sastavnice i njezina uklapanja u posao.
Demonstracija bira svoje okruženje
Demonstracija može odabrati uredne ulaze. Može unaprijed odobriti račun, preskočiti red čekanja, poništiti neuspjelo pokretanje i dopustiti autoru da objasni nejasan izlaz. To su razumni izbori za dokazivanje mogućnosti. Postaju opasni kada tim test mogućnosti smatra dokazom operativne spremnosti.
U primjeru računa izdvajanje je samo jedan korak. Organizacija mora utvrditi koji je sandučić mjerodavan, kako se otkrivaju duplikati, smije li se iznos promijeniti nakon podnošenja, tko smije odobriti račun i kamo ide neuspjeli upis u sustav odobravanja. Bolje sročen sažetak ne može odgovoriti na ta pitanja.
Granicu je najlakše vidjeti ako jednu stavku pratimo od primitka do prihvaćenog rezultata:
Prikazana mogućnost postaje koristan posao tek kada je lokalni podaci, dopuštenja i oporavak povežu sa stvarnim tijekom operatera.
| Faza | Pitanje demonstracije | Pitanje u stvarnom radu |
|---|---|---|
| Ulaz | Može li model pročitati ovaj primjer? | Može li primiti svaki dopušteni format, a ostale odbiti? |
| Kontekst | Može li pronaći iznos? | Može li spojiti pravog dobavljača, pravnu osobu i verziju pravila? |
| Radnja | Može li stvoriti sažetak? | Može li izvesti samo dopuštene radnje i izbjeći duplikate? |
| Kvar | Može li voditelj demonstracije pokušati ponovno? | Tko vidi zapelu stavku, ispravlja je i sigurno nastavlja? |
| Prihvaćanje | Izgleda li izlaz korisno? | Koristi li ga odgovorna osoba u stvarnom redu i vjeruje li mu? |
Ova je usporedba pojmovna. Ne podrazumijeva izmjerenu stopu neuspjeha projekata AI-ja.
Pratite lokalno stanje
Integracija podataka često se naziva posljednjim dijelom puta, kao da je riječ o kabelu koji se priključi nakon dovršetka proizvoda. Lokalni podatkovni model može promijeniti značenje samog proizvoda. Jedna tvrtka račun smatra „zaprimljenim” čim stigne u sandučić; druga tek nakon podudaranja s narudžbenicom. Ako sustav djeluje na pogrešno stanje, tehnički valjan API poziv i dalje može biti poslovna pogreška.
Pitajte gdje svaka činjenica nastaje i tko je može ispraviti. Zatim pitajte što sustav radi kad se činjenice ne slažu. Ako se izvorni zapis promijeni nakon što je model sastavio nacrt odobrenja, treba li nacrt poništiti? Ako se dopuštenje opozove dok zadatak čeka, provjerava li ga izvršitelj ponovno prije radnje? Ta su pitanja dio uvođenja, ne završno uljepšavanje.
Članak o otkrivanju tijeka rada počinje ranije, promatranjem onoga što operateri zaista rade. Ovdje pitamo što mora vrijediti da bi prikazana mogućnost opstala u tom tijeku.
Prototipom provjerite mogućnost, zatim tijek rada
Malen prototip može najbrže pokazati može li model uopće obaviti osnovni zadatak. Prvoga dana ne mora imati sve kontrole za stvarni rad. Pogreška je preostali posao unaprijed proglasiti sitnim završetkom bez njegove provjere.
Koristan prototip jasno navodi granicu. Može reći: „Čita odobrene primjere računa, predlaže polja i ne poduzima vanjske radnje.” Sljedeći test može koristiti dopuštene stvarne zapise, ali zadržati isključenu predaju u sustav odobravanja. Tek nakon razumijevanja podudaranja podataka, dopuštenja i oporavka smije upisivati u taj sustav. Svaki korak odgovara na drugo pitanje.
Uvođenje ima i ljudski rub. Osobi koja već rješava nejasne račune treba način da ispravi prijedlog, vidi što je promijenjeno i zna hoće li sustav ponoviti istu pogrešku. Ako novi tijek traži više provjera nego što ih uklanja, uporaba će to pokazati. Ne zaključujte o prihvaćanju iz uspješne demonstracije.
Prag za puštanje može se izraziti operativnim pitanjem: može li drugi ovlašteni operater dovršiti jednu stavku i oporaviti je od pogreške bez autora demonstracije u prostoriji? Mora moći pronaći izvorni ulaz, vidjeti predloženu radnju, utvrditi osnovu dopuštenja i usmjeriti kvar. Uvježbano vraćanje promjene važno je jer uspješno prvo pokretanje ne govori ništa o duplikatu ili djelomičnom upisu. Vodič za uvođenje AI-ja u postojeće tijekove nudi širi okvir. Za ovaj prag zadržite uzak test i ponovite ga na iznimci koja najvjerojatnije ruši idealan put.
Rezultat koji treba brojiti nije generirani izlaz. To je prihvaćena stavka u stvarnom procesu, s poznatim putem za iznimke. Dok taj put ne radi, demonstracija ostaje vrijedan dokaz o jednoj sastavnici. Nije dokaz da je posao gotov.
Često postavljana pitanja
Zašto uspješna demonstracija može zakazati u stvarnom radu?
Demonstracija često koristi pripremljene podatke i jednog operatera. Stvarni posao dodaje promjenjive zapise, ograničenja pristupa, zakašnjele događaje, iznimke i ljude koji moraju vjerovati rezultatu.
Što treba uključiti test uvođenja?
Koristite stvarni tijek rada za koji imate dopuštenje, s uobičajenim i iznimnim slučajevima. Provjerite izvorne podatke, dopuštene radnje, oporavak od kvara, odgovornog vlasnika i koristi li predviđeni korisnik rezultat.
Znači li to da model nije važan?
Ne. Kvaliteta modela nužna je za zadatke koji je trebaju. Uvođenje ovisi i o tome može li model sigurno djelovati unutar okolnog sustava i tijeka rada.