Triaža prijav z umetno inteligenco: kaj se zapre samo in kaj ne

V našem CRM-ju je gumb, ki nikoli ne izgine, ne glede na to, na katerem zaslonu smo: namenjen je prijavi težave. Želeli smo, da je vedno viden, in to iz preprostega razloga. Če je treba za prijavo najprej poiskati, kje se to naredi, prijava ne pride. Kdor dela, ima v glavi pogajanja, ogled ali dokument, ki ga mora poslati, ne pa naše programske opreme. Gumb mora stati en klik in nič več.

Kar se zgodi po kliku, pa je del, o katerem smo največ razmišljali. Vsaka prijava se zapiše v tabelo, od tam pa se sproži samodejna triaža z umetno inteligenco. Tu opisujemo, kako deluje, predvsem pa pravilo, ki ga nikoli ne bomo postavili pod vprašaj.

Kaj naredi triaža, ko prispe prijava

Ko je prijava ustvarjena, triaža naredi tri stvari.

1. Zapiše prvo diagnozo. To ni razodeta resnica, temveč berljiva domneva o tem, kaj je morda šlo narobe, zapisana ob opisu prijavitelja. Koristi tistemu, ki bo prijavo prevzel pozneje, da ne začne iz nič.
2. Razvrsti težavo. Ker ima vsaka prijava svojo vrsto, je mogoče na prvi pogled ločiti na primer postopek, ki ga je treba ponoviti, od prave napake v programski opremi.
3. Poišče podobne, že rešene prijave. To je najkoristnejši korak. CRM, ki ga uporabljamo vsak dan, navadno povzroča iste spotike, in zgodi se, da kdo prijavi nekaj, kar se je že zgodilo in je že urejeno.

Kdaj se prijava zapre sama

Če triaža najde predhodni primer, pogleda, kako je bil rešen. Vsako rešitev je mogoče označiti kot ponovno uporabno ali ne. Ponovno uporabna pomeni, da jo je mogoče znova uporabiti nespremenjeno: na primer postopek, ki ga je treba ponoviti.

V tem primeru se prijava zapre sama, z uporabo iste rešitve. Prijavitelj ne čaka na nekaj, kar že poznamo, mi pa ne izgubljamo časa s ponovnim diagnosticiranjem težave, ki že ima odgovor.

Tako povedano se zdi to lahki del. V resnici je to del, ki ga je treba najbolje zamejiti, saj je sistem, ki stvari zapira sam, priročen natanko do dne, ko zapre napačno.

Pravilo, o katerem se ne pogajamo

Določili smo dve omejitvi in ju obravnavamo kot nedotakljivi.

Prva: ob vsakem zaprtju se zapiše rešitev. Nobena prijava se ne zapre, ne da bi ostala sled o tem, kaj je bilo narejeno. »Rešeno« ni dovolj. Če rešitve ni, naslednja triaža nima česa prepoznati in spomin sistema se izprazni prav tam, kjer bi bil najbolj potreben.

Druga: rešitev, ki je popravek kode, nikoli ni ponovno uporabna. Nikoli, tudi ko bi se zdelo priročno.

Razlog je tale. Postopek, ki ga je treba ponoviti, je po naravi nekaj, kar je lahko spet potrebno: ponovitev je zdravilo. Popravek kode pa bi moral težavo odpraviti enkrat za vselej. Če se ista okvara ponovi, potem ko je bila koda že popravljena, nimamo pred sabo znanega primera, temveč regresijo. Nekaj, kar smo uredili, se je spet pokvarilo, ali pa popravek ni bil pravi.

Če bi bila taka rešitev označena kot ponovno uporabna, bi triaža naredila tisto, kar je z njenega vidika najbolj razumno: prepoznala bi predhodni primer, videla, da je bil rešen, in novo prijavo zaprla. Potihoma. Evidenca bi kazala, da je vse v redu, napaka pa bi ostala v programski opremi – in kar je še huje, bila bi videti že obravnavana. To je vrsta napake, ki ne dela hrupa, in prav zato je najdražja.

Zato mora regresija ostati vidna. Prijava, ki spominja na popravek kode, se ne zapre sama: ostane odprta, s predhodnim primerom ob strani, in nekdo si jo mora ogledati.

Kdo posega v kodo in kako

Popravke kode izvajamo v delovni seji s Claudom po zapisanem postopku. Postopek je treba prebrati, preden se lotimo prijav, ne pozneje in ne vmes.

To ni birokracija. V postopek smo zapisali prav pravila iz tega članka: kako se prijava zapre, kaj se zapiše v rešitev, kdaj je rešitev mogoče označiti kot ponovno uporabno in kdaj ne. Seja, ki se začne, ne da bi ga kdo prebral, tvega, da bo naredila najbolj naravno stvar: odpravila težavo in jo zaprla, morda pa rešitev še označila kot ponovno uporabno, ker je »delovala«. Prav to vedenje želimo izključiti.

Če postopek preberemo vnaprej, kdor dela na kodi – naj bo človek ali model – začne z isto pogodbo: popravek se naredi, rešitev se zapiše, vrata samodejnega zapiranja za to vrsto okvare pa ostanejo zaprta.

Kaj odnesemo s seboj

Tri stvari, ki veljajo tudi zunaj našega CRM-ja.

• Avtomatizacija je primerna za tisto, kar se po naravi ponavlja. Postopek, ki ga je treba ponoviti, je odličen kandidat za samodejno zaprtje. Napaka v programski opremi ni: če se vrne, je to novica.
• Spomin ima vrednost le, če se zapisuje. Triaža prepoznava predhodne primere, ker ob vsakem zaprtju ostane zapisana rešitev. Brez nje iskanje podobnih primerov ne najde nič uporabnega.
• Pravila, ki štejejo, je treba zapisati tam, kjer se dela. Branje postopka pred začetkom dela vzame nekaj minut in odpravi najverjetnejšo napako, ki ni tehnična, temveč prenagljeno zapiranje.

Gumb ostaja vedno tam, na vsakem zaslonu. Naučili smo se skrbeti za to, kar se zgodi potem, predvsem pa za to, kaj se nikoli ne sme zgoditi samo od sebe.