Agentna kupnja ne smije preskočiti poslovnu predaju. Agent može pronaći proizvod, usporediti informacije i pripremiti prijedlog, ali predaja agentne narudžbe ERP-u dolazi tek nakon potvrde identiteta kupca, komercijalnih uvjeta, ovlasti za naručivanje i statusa iznimki. ERP tada prima službenu transakciju s jasnim vlasnikom, provjerljivim zapisom i pravilima za daljnju obradu.
U agentnoj kupnji korisnik razgovara s AI sučeljem koje može pomoći pri pretraživanju ponude, sastavljanju košarice ili pripremi podataka za kupnju. To ne pretvara svaki prijedlog, klik ili strukturirani skup podataka u prihvaćenu poslovnu narudžbu.
Poslovni proces treba razlikovati najmanje četiri stanja:
Granica između trećeg i četvrtog stanja posebno je važna. Prije nje sustav može prikazati informaciju, procjenu ili nacrt. Nakon nje nastaje zapis kojim upravljaju pravila prodaje, financija, skladišta, isporuke i korisničke službe.
UCP se u dostupnom kontekstu opisuje kao protokol za povezivanje trgovine s AI površinama. Dodatni opis i dokumentaciju objavljuju Shopify - Universal Commerce Protocol i Google - Universal Commerce Protocol guide . Sama prisutnost protokola ne potvrđuje podršku pojedinog trgovca, platnog sustava ili tržišta. Svaku takvu podršku treba zasebno provjeriti prije projektne odluke, uključujući primjenjivost na hrvatsko tržište.
ERP je mjesto službene poslovne evidencije, a ne spremnik svakog podatka koji je agent prikupio. Kada agent preda narudžbu ERP-u, prijenos treba nositi dovoljno konteksta za odgovor na nekoliko operativnih pitanja:
Bez tih odgovora integracija može tehnički izraditi dokument, ali ostavlja otvoren spor oko sadržaja i odgovornosti. Zato kontrola uvjeta agentne kupnje treba prethoditi kreiranju prodajnog naloga, izlazne fakture, naloga za isporuku ili drugog službenog ERP zapisa.
Praktična granica može biti jednostavna: agent smije predložiti i pripremiti, a poslovno pravilo odlučuje smije li se prijedlog pretvoriti u narudžbu. To pravilo ne mora uvijek tražiti ljudsku intervenciju, ali mora biti izričito definirano i provjerljivo.
Tijek nije univerzalan, ali sljedeći redoslijed smanjuje nejasnoću između razgovornog sučelja i poslovnog sustava.
Agent ili povezano prodajno sučelje prikuplja artikle, količine, adresu isporuke, kontakt, željeni način plaćanja i poslovni identitet kupca kada je relevantan. Svaki podatak treba imati izvor: korisnik, katalog, ugovor, ERP matični podatak ili vanjski sustav.
Katalog može pomoći pri odabiru, ali ne smije samostalno preuzeti ulogu izvora za individualno ugovorene cijene ili kreditna ograničenja. Takve podatke treba provjeriti u sustavu koji ih poslovno vodi.
Potvrda identiteta odgovara na pitanje tko pristupa procesu. Potvrda ovlasti odgovara na pitanje smije li ta osoba naručiti za određenu pravnu osobu, troškovno mjesto, projekt ili ugovorni račun.
U B2B procesu te dvije provjere često nisu iste. Osoba može imati valjanu prijavu, ali ne i pravo prihvatiti određeni iznos, artikl ili uvjet plaćanja. Vlasnik pravila ovlasti treba biti jasno određen, primjerice komercijalna administracija, upravljanje kupcima ili drugi imenovani poslovni vlasnik.
Prije službene predaje potrebno je sastaviti verziju narudžbe za potvrdu. Ona uključuje barem stavke, količine, jedinične i ukupne iznose kada su primjenjivi, valutu, porezni tretman, adresu, način isporuke, rok ili napomenu o roku, način plaćanja te uvjete koji mijenjaju obvezu.
Izraz poput "dostupno" ili "isporuka u roku" zahtijeva poslovno definiran izvor i status. Ako podatak nije potvrđen iz pouzdanog izvora procesa, sučelje ga treba prikazati kao informaciju za provjeru, a ne kao prihvaćeni uvjet.
Pravila trebaju razvrstati narudžbu na automatski prihvat, ručnu provjeru ili odbijanje odnosno povrat na dopunu. Razlozi mogu uključiti nepodudaranje kupca, nedostajuću ovlast, promjenu cijene, nedostupan artikl, nejasan porezni tretman, ograničenje plaćanja, nepotpunu adresu ili nesukladnost s ugovorom.
Važno je zadržati razlog odluke. Poruka "nije moguće" nije dovoljna za operativni tim. Korisniji je status poput "ručna provjera - ugovorna cijena nije potvrđena" uz vlasnika sljedeće radnje.
Predaja agentne narudžbe ERP-u treba sadržavati identifikator izvornog zahtjeva, potvrđenu verziju uvjeta, odluku o prihvatu, vrijeme odluke, vlasnika odluke i poveznice na relevantne zapise kada postoje. ERP zatim vraća službeni identifikator te status zaprimanja ili odbijanja.
Agent ne treba pretpostaviti uspjeh samo zato što je poslao zahtjev. Tek odgovor ERP-a ili ugovorenog posrednog sloja potvrđuje uspješan primitak. Ako sustav odbije zahtjev, proces treba spriječiti dvostruko slanje i usmjeriti slučaj na odgovornu osobu ili red za obradu.
Zamislimo ovlaštenog korisnika kupca koji putem AI sučelja traži potrošni materijal za proizvodnju. Agent pronalazi artikle, predlaže količine na temelju unesenog zahtjeva i priprema košaricu. To je faza pripreme, ne narudžba.
Prije predaje sustav provjerava poslovni račun kupca, ovlast korisnika, ugovoreni cjenik, adresu pogona i način plaćanja. Jedna stavka nema potvrđen ugovorni cjenik. Umjesto stvaranja djelomično nejasne narudžbe, pravilo šalje cijeli zahtjev na komercijalnu provjeru ili odvaja tu stavku prema unaprijed određenom pravilu. Nakon potvrde uvjeta, ERP prima narudžbu s evidentiranim razlogom prihvata.
Ovaj scenarij nije opis stvarne implementacije ni potvrda dostupnosti bilo koje integracije. Služi kao okvir za odluku: koji trenutak stvara poslovnu obvezu i tko posjeduje odluku u tom trenutku?
Automatski prihvat smanjuje ručni rad samo za slučajeve s pouzdanim podacima i jasnim pravilima. Preširoka automatizacija može ubrzati unos, ali povećati broj naknadnih ispravaka, sporova ili ručnih intervencija. Prestroga pravila, s druge strane, vraćaju svaki zahtjev ljudima i poništavaju korist pripreme.
Dobar dizajn zato ne bira samo između "automatski" i "ručno". On određuje pragove, skupove dopuštenih uvjeta i put iznimke. Primjeri pitanja za poslovnu odluku:
Te odluke pripadaju poslovnom procesu. Tehnologija ih provodi, ali ne može ih razumno pretpostaviti umjesto prodaje, financija, logistike i upravljanja kupcima.
Prije razvoja integracije ili pilot-procesa sastavite kratak popis s vlasnicima i dokazima prihvata.
Ulazi i njihovi vlasnici
Odluke koje moraju imati vlasnika
Iznimke koje treba opisati prije rada
Provjerljivi kriteriji prihvata
Za organizacije koje tek određuju granicu između kanala, ljudi i ERP-a, koristan prvi korak je Screening poslovnog procesa . ORKA pristup stavlja svakodnevnu suradnju i službene ERP transakcije u različite, povezane odgovornosti. Nakon takvog pregleda tim može odabrati mali skup narudžbi i iznimki za provjeru prije šire automatizacije.