ERP i automatizacija procesa
Automatizacija se ne uključuje, nego projektuje: događaj, uslov, imenovana akcija i osigurač. Kada uzeti determinističko pravilo, kada AI predlog, i šta automatizovati prvo.
- Objavljeno
- Autor
- Konis Software
Skoro svaki ERP danas dolazi sa graditeljem tokova: povučeš kutije, povežeš strelice, demo se odvrti. Pitanje koje ozbiljan kupac postavlja nije da li motor ume da automatizuje — to danas umeju svi — nego da li će automatizacija koju u njemu projektuješ preživeti dodir sa stvarnim zaključkom meseca. Većina ne preživi, i ne zato što je motor slab.
Automatizacija nije prekidač koji se uključi, nego dizajn koji se napiše. Pada onda kad je projektovana za slučaj u kom su sva polja prisutna i ispravna — za srećan put — a susretne stvarnost u kojoj uplata stigne bez poziva na broj, a prijemnica se proknjiži posle fakture. Ovaj tekst je o tom dizajnu: o anatomiji jednog pravila, o tome kada uzeti determinističko pravilo a kada AI predlog, gde namerno zadržati čoveka i šta automatizovati prvo. Kako se meri da li je vredelo — to je posebna tema.
Anatomija pravila: događaj → uslov → akcija
Svaka automatizacija svodi se na tri imenovana dela. Događaj budi pravilo. Uslov odlučuje da li treba da deluje. Akcija je ono što uradi. Ključna reč je „imenovana”: ako ne umeš da imenuješ nijedan od tri dela, ne možeš ni da revidiraš pravilo ni da poništiš njegov rezultat. Motor koji dozvoljava da bilo koji od ta tri dela bude proizvoljan kod izgleda moćnije na demou i skuplje ispadne u produkciji.
Događaj
Događaj je imenovana promena stanja u sistemu: dokument je primljen, status je promenjen, prag je pređen, datum je dostignut. To nije isto što i posao koji svake noći skenira sve i traži šta se promenilo. Batch koji obrađuje ceo registar ume da uradi posao, ali ne ume da odgovori zašto je dodirnuo baš taj zapis — a bez tog odgovora nema ni revizije ni poništavanja po zapisu. Pravilo vezano za događaj zna svoj povod; noćni skener zna samo svoj sat. Jedan dokument u svom veku podigne više događaja — primljen, uparen, odobren, plaćen — i pravilo se vezuje za tačno jedan od njih; vezivanje za pogrešan događaj je razlog zašto se pravilo okine prerano, nad podatkom koji još nije spreman.
Uslov
Uslov odlučuje da li pravilo sme da deluje i mora da bude deterministički i proverljiv — čovek koji ga čita mora unapred da zna šta će vratiti. Najčešća zamka je uslov koji zavisi od podatka koji još ne postoji: pravilo pokušava da upari fakturu sa prijemnicom pre nego što je prijemnica proknjižena. Dobro projektovan uslov ume da kaže „još ne” i da sačeka sledeći događaj, umesto da omane ili — gore — da pogrešno uspe na nepotpunom podatku.
Akcija: imenovana, ne proizvoljna
Akcija mora da dolazi iz zatvorenog rečnika imenovanih radnji, gde je svaka poništiva i ostavlja trag. Motor koji dozvoljava da akcija bude „pokreni ovu skriptu” nema ni povratak ni revizioni trag: kad takvo pravilo pogreši, ne znaš ni šta je tačno uradilo ni kako da vratiš. Imenovana akcija je upravo ono što ti daje da odgovoriš na dva pitanja koja svako pravilo mora da izdrži — šta je uradilo i kako se to poništava. Poništavanje pritom nije tiho prepisivanje vrednosti unazad, nego zabeležena kompenzujuća radnja: storno stoji u dnevniku pored originala, sa vezom na pravilo koje ga je proizvelo, jer istorija koja se prepravlja nije revizioni trag.
- „Napravi nacrt knjiženja” — pravilo predlaže kontiranje, ništa se ne knjiži bez potvrde.
- „Zatvori stavku izvoda” — determinističko uparivanje po ispravnom modelu 97 sa kontrolnim brojem.
- „Otvori zadatak” — posao se dodeljuje čoveku, sa razlogom i rokom.
- „Blokiraj sa razlogom” — radnja se zaustavlja i upisuje se zašto, tako da blokada može da se opravda ili opozove.
- „Postavi polje sa poreklom” — vrednost se upisuje uz oznaku ko ju je upisao, pa se automatski i ručni unos kasnije razlikuju.
- „Pošalji dokument” — na primer e-faktura na SEF, uz zapis o ishodu slanja.
Determinističko pravilo naspram AI predloga
To su dva različita alata i njihovo mešanje je najčešća greška u projektovanju. Determinističko pravilo preslikava ulaz u izlaz po pravilu koje si sam napisao: isti ulaz uvek daje isti izlaz i to se može dokazati. AI predlog nastaje tamo gde je preslikavanje dvosmisleno — nestrukturiran ulaz, procena, kontekst koji se ne da zapisati kao uslov — i njegov izlaz je uvek nacrt, nikad gotova radnja. Pravilo palca je jednostavno: ako umeš da napišeš uslov, napiši pravilo. Po AI posegni samo tamo gde je dvosmislenost stvarna, a ne tamo gde ti se ne piše uslov. Ulazna faktura za struju, sa istim dobavljačem i istim kontom iz meseca u mesec, jeste determinističko pravilo — uslov se napiše jednom. Skenirana otpremnica sa rukom dopisanom količinom jeste teren za AI, jer se pravilo koje bi to pokrilo ne može napisati unapred.
| Osobina | Determinističko pravilo | AI predlog |
|---|---|---|
| Kada | Preslikavanje ulaza u izlaz umeš da napišeš | Preslikavanje je dvosmisleno (nestrukturiran ulaz, procena) |
| Izlaz | Radnja ili nacrt — po dizajnu | Uvek nacrt, sa označenim poljima u koja nije siguran |
| Isti ulaz | Uvek isti izlaz — proverljivo | Može da varira, zato ide na potvrdu |
| Kad omane | Omane predvidivo, na uslovu koji vidiš | Omane tiho, ponekad sa visokim samopouzdanjem |
| Ko odgovara | Onaj ko je napisao pravilo | Onaj ko je potvrdio nacrt |
Maker-checker kao osigurač, ne kao formalnost
Automatizacija po dizajnu izbacuje čoveka iz petlje; maker-checker je mesto na kome ga namerno vraćaš. Ne na sve — to poništava automatizaciju — nego na one akcije kod kojih cena pogrešnog automatskog rezultata premašuje cenu jedne potvrde. To je odluka po akciji, sa definisanim uslovima pod kojima osigurač pregori: iznos preko praga, novi poslovni partner, nisko samopouzdanje predloga, prvi put da se pravilo okine za jedan tenant. Ključno je da onaj ko potvrđuje vidi predloženu akciju i dokaz iza nje, a ne dugme „da/ne” bez konteksta. Ko sme da odobri i u kojoj visini — to je zasebno pitanje autorizacije i rešava se drugim slojem. Osigurač koji niko ne gleda je ukras: ako onaj ko potvrđuje odobri sve redom bez čitanja, kontrola postoji na papiru a ne u praksi. Zato se stopa potvrda bez ijedne izmene prati kao znak da je prag možda postavljen prestrogo — ili da je provera postala pečat.
Pravilo bez definisanog uslova pod kojim staje i vraća posao čoveku nije automatizacija bez nadzora — to je odluka bez vlasnika. Osigurač nije formalnost oko automatizacije; on je deo koji je čini upotrebljivom.
Šta automatizovati prvo
Kriterijum izbora ima dve ose: učestalost i dvosmislenost. Visoka učestalost opravdava trošak projektovanja — pravilo koje se okine dvaput godišnje ne vraća uloženo. Niska dvosmislenost znači da uslov može da se napiše deterministički i da pravilo neće provesti život u izuzecima. Tek presek te dve ose kaže gde početi, i on razdvaja kandidata koji vredi automatizovati od onog koji će te godinu dana koštati održavanja.
| Niska dvosmislenost | Visoka dvosmislenost | |
|---|---|---|
| Visoka učestalost | Automatizuj prvo: deterministička pravila — uparivanje po modelu 97, ponavljajuće režijske fakture, provera statusa e-fakture na SEF-u. | AI priprema nacrt, čovek potvrđuje — kontiranje ulazne fakture iz OCR-a, predlog opomene. |
| Niska učestalost | Automatizuj ako je jeftino za održavanje; inače je dovoljan šablon koji čovek popuni. | Ostavi ručno: uvozna kalkulacija sa JCI-jem i landed cost-om, vanredni obračuni — dvosmislenost je previsoka za pravilo, a učestalost preniska za AI. |
Zamke low-code motora koji nikad ne prođu test
Graditelj tokova na demou uvek radi, jer demo teče srećnim putem. Ono što razlikuje demo od produkcije nije bogatstvo motora nego to kako se pravilo ponaša kada nešto pođe naopako — a u produkciji uvek pođe. Evo grešaka koje se ponavljaju bez obzira na to koji je motor ispod:
- Samo srećan put. Pravilo je projektovano za slučaj u kom su sva polja prisutna i validna; prvi delimično plaćeni izvod ili faktura bez porudžbenice ga sruše.
- Nema idempotentnosti. Pravilo se okine dvaput na ponovljenom pokušaju — mrežni ispad, retry reda poruka — i napravi dva knjiženja umesto jednog. Isti događaj obrađen dvaput mora da da jedan rezultat, inače je motor generator duplikata.
- Tihi pad bez reda za neisporučeno. Kad pravilo ne može da završi, gde ide posao? Ako nestane bez traga, to nije automatizacija nego mašina za gubitak podataka; mora da postoji red na koji neuspeli događaj padne i čeka.
- Zakovan parametar u uslovu. Stopa ili prag upisan kao literal u pravilu: propis se promeni, a pravilo i dalje okida na staroj vrednosti, jer parametar nema vremensku važnost odvojenu od koda.
- Bez verzionisanja pravila. Promeniš uslov i ne znaš više koja je verzija proizvela prošlomesečna knjiženja — a to je prvo pitanje na reviziji.
- Otvor „pokreni skriptu”. Motor koji dozvoljava da akcija bude proizvoljan kod pretvara nadziranu automatizaciju u neproverljiv posao bez traga i bez povratka.
Kako NG One pristupa ovome
NG One modeluje automatizaciju kao imenovana pravila nad tokom događaja. Svaka akcija dolazi iz zatvorenog rečnika, upisuje poreklo i može da se poništi; AI proizvodi isključivo nacrte; maker-checker je osigurač po akciji, podešen po tenantu, procesu i pragu. Automation Center u prostoru Uvidi, automatizacija i AI prikazuje aktivna pravila, uslove pod kojima staju i istoriju izvršenja. U demo tenantu, na primer, jedno pravilo zatvara stavke izvoda po modelu 97 i ostatak šalje na red za rešavanje, a pravilo za ponavljajuću režijsku fakturu pravi nacrt knjiženja koji čovek potvrđuje. To su konfiguracije za prikaz, ne izmereni ishodi kod imenovanog korisnika. Ista pravila i njihovi rezultati vide se i na početnom ekranu, na jeziku korisnika — koliko je stavki izvoda zatvoreno samo, koliko nacrta čeka potvrdu — i svaka takva brojka vodi do liste zapisa iza sebe; brojka bez puta do zapisa iza sebe je slogan, ne uvid.