Automatizare procese cu AI: de ce proiectezi procesul înainte de model

Automatizare procese cu AI înseamnă că o parte din munca repetitivă a firmei o face un sistem care citește, înțelege și decide. Nu e doar un script care execută pași fixi. Diferența contează. Un script mută date dintr-un loc în altul, iar un model AI poate citi un e-mail scris în grabă și poate spune despre ce este vorba.

Pentru tine, ca manager, întrebarea utilă nu este ce poate face AI-ul în general. Întrebarea este ce decizii mici se iau zilnic în firmă, de oameni, după reguli pe care nu le-a scris nimeni. Acolo e de câștigat timp și acolo apar cele mai multe greșeli.

Automatizarea clasică merge bine când intrarea are mereu aceeași formă: un formular cu câmpuri fixe, un export zilnic, un document generat de alt sistem. AI-ul își face locul acolo unde intrarea variază. Vorbim de mesaje libere, de cereri formulate altfel de fiecare client, de documente cu structuri diferite.

Totuși, AI-ul nu repară un proces care nu există. Dacă nici echipa ta nu știe exact cine preia ce, modelul nu va ști nici el. Restul articolului pornește de la această idee și o arată pe un caz concret: rutarea cererilor într-un service desk.

Multe proiecte de AI pornesc invers. Firma alege un instrument, îl conectează la ce are și speră să iasă ceva util. De obicei iese un demo frumos, care se strică la primul caz real.

Motivul e simplu. Un model AI ia decizii pe baza a ceea ce îi spui tu că e corect. Dacă regulile de lucru stau în capul a doi colegi vechi, modelul nu are de unde să le învețe. Va ghici, iar ghicitul arată bine în prezentare și prost în producție.

Un proces proiectat are câteva lucruri clare:

• Intrările: ce fel de cereri vin, pe ce canale, în ce formă.
• Deciziile: ce trebuie hotărât pentru fiecare cerere, de exemplu categoria, prioritatea, echipa.
• Destinațiile: unde ajunge cererea după decizie și cine răspunde de ea.
• Excepțiile: ce se întâmplă când decizia nu e sigură.

Când ai aceste patru lucruri scrise, AI-ul devine o piesă dintr-un mecanism pe care îl înțelegi. Fără ele, AI-ul devine chiar mecanismul, și nu mai poți explica de ce a luat o decizie sau alta.

Dacă vrei o imagine mai largă despre unde poate intra AI-ul în firmă, ghidul despre cum poate folosi orice companie AI pornește tot de la procese, nu de la instrumente.

Rutarea e un exemplu aproape ideal. O cerere intră în Zoho Desk sau în alt sistem de tichete, iar cineva trebuie să decidă cine se ocupă de ea. Decizia pare banală. În practică, e locul unde se pierde cel mai mult timp.

Când o cerere ajunge la omul greșit, nu se pierde doar un minut. Omul o citește, își dă seama că nu e a lui, o trimite mai departe, iar următorul coleg o ia de la zero. Clientul așteaptă între timp. Dacă se întâmplă de câteva ori pe zi, echipa pierde ore întregi pe săptămână doar mutând tichete.

Rutarea are și avantajul că rezultatul se vede imediat. Ori cererea a ajuns unde trebuia, ori nu. Asta o face ușor de măsurat, deci ușor de îmbunătățit.

Un exemplu publicat: un service desk IT construit de Svennis pe Claude, în Teams, în fața Zoho Desk, pentru Asset Services Group, trimite corect din prima 99,7% din cereri și a adus un câștig de eficiență de 40%, cifre date public de Head of Technology al clientului în studiul de caz despre asistentul IT din Teams.

Un asemenea rezultat nu vine din alegerea modelului. Vine din faptul că procesul de rutare era descris suficient de clar încât modelul să aibă după ce să se ghideze.

Nu ai nevoie de un consultant ca să faci primul pas. Ai nevoie de o după-amiază, de oamenii care fac munca și de o foaie pe care notezi tot.

1. Strânge cereri reale

Ia un eșantion de cereri din ultimele luni, exact cum au venit. Nu le curăța și nu le rescrie. Modelul va primi mesaje la fel de dezordonate, deci trebuie să vezi realitatea.

2. Notează unde a ajuns fiecare

Pentru fiecare cerere, scrie cine ar fi trebuit să o preia și de ce. Motivul e partea importantă. „Pentru că e despre imprimantă” e o regulă. „Pentru că Andrei se pricepe” nu e o regulă, e o dependență de o persoană.

3. Grupează categoriile

Vei vedea că majoritatea cererilor se împart într-un număr mic de tipuri. Dă fiecărui tip un nume și o destinație. Dacă două categorii ajung mereu la aceeași echipă, poate nu merită să le separi.

4. Scrie excepțiile

Cererile ambigue, cele urgente și cele care ating mai multe echipe au nevoie de reguli proprii. Aici se decide calitatea automatizării. Un sistem care știe să spună „nu sunt sigur” e mai valoros decât unul care ghicește mereu.

Abia după acești pași are sens să scrii instrucțiunile pentru model. Ele vor fi, practic, procesul tău pus în cuvinte.

O greșeală frecventă e să dai totul modelului. Unele decizii se iau mai bine cu o regulă simplă, pe care o poți verifica oricând. Altele au nevoie de înțelegerea textului, și acolo AI-ul își merită locul.

Împărțirea asta face sistemul mai ieftin de întreținut. Când se schimbă programul echipei, modifici o regulă, nu reantrenezi nimic. Când apare un tip nou de cerere, ajustezi instrucțiunile modelului, fără să atingi restul fluxului.

În plus, împărțirea te ajută să explici deciziile. Dacă un client întreabă de ce cererea lui a ajuns la o anumită echipă, poți arăta ce a decis regula și ce a interpretat modelul.

Automatizarea bine făcută nu scoate oamenii din proces. Le schimbă rolul. În loc să sorteze fiecare cerere, echipa verifică doar cazurile pe care sistemul le marchează ca nesigure.

Pentru asta, sistemul trebuie să știe când să ceară ajutor. Un model care trimite totul mai departe cu aceeași încredere e periculos, pentru că greșelile lui arată exact ca deciziile corecte. Un model care spune „aici am nevoie de un om” îți dă control.

Câteva reguli practice:

• Stabilește dinainte ce tipuri de cereri trec mereu pe la un om, indiferent ce decide modelul.
• Pune un responsabil pentru coada de cereri nesigure, cu timp alocat în program.
• Când un om corectează o decizie, notează corecția. Din ea afli ce trebuie ajustat în instrucțiuni.

Oamenii din echipă sunt și cea mai bună sursă de îmbunătățiri. Ei văd primii când modelul începe să greșească pe un anumit tip de cerere. Dacă nu au un canal simplu prin care să semnaleze, problemele se adună în tăcere.

Un lucru merită spus deschis echipei: scopul nu e să înlocuiești pe cineva. Scopul e ca oamenii să lucreze pe cererile care chiar au nevoie de ei.

Un asistent AI pe care nu-l folosește nimeni nu automatizează nimic. De aceea, locul în care îl pui contează la fel de mult ca modelul din spate.

Dacă angajații tăi își petrec ziua în Teams, un asistent în Teams pornește cu un avantaj. Nu trebuie să deschidă alt portal, să-și amintească altă parolă sau să completeze alt formular. Scriu cererea cum ar scrie-o unui coleg, iar asistentul o preia.

În spate, cererea ajunge tot în sistemul de tichete. Zoho Desk rămâne locul unde se țin evidența, istoricul și rapoartele. Asistentul nu înlocuiește sistemul de tichete. Stă în fața lui și face partea de înțelegere și sortare.

Arhitectura asta are două beneficii practice:

1. Nu schimbi obiceiurile oamenilor. Adopția vine aproape de la sine, pentru că nimeni nu învață o unealtă nouă.
2. Nu pierzi controlul datelor. Fiecare cerere lasă o urmă în sistemul de tichete, unde poate fi urmărită și auditată.

Aceeași logică poate fi folosită și în alte zone. Un asistent pentru vânzări poate sta în instrumentul de mesagerie al echipei și poate scrie în CRM. Un asistent pentru facturare poate primi documente pe e-mail și le poate pune în sistemul contabil. Principiul e același: asistentul vine la oameni, nu oamenii la asistent. Pentru o privire de ansamblu asupra acestor zone, vezi pagina despre digitalizare cu AI pentru firme.

Fără măsurare, nu știi dacă AI-ul te ajută sau doar mută problemele în altă parte. Vestea bună e că la rutare indicatorii sunt simpli și îi poți urmări din sistemul de tichete.

Rutarea corectă din prima

Procentul de cereri care ajung la echipa potrivită fără să fie redirecționate. E indicatorul principal. Îl calculezi numărând tichetele reasignate după prima alocare.

Rata de cereri trimise la verificare

Câte cereri marchează sistemul ca nesigure. Dacă e prea mare, modelul e prea prudent și echipa tot sortează manual. Dacă e aproape zero, verifică dacă nu cumva modelul e prea sigur pe sine.

Timpul până la prima preluare

Cât trece de la intrarea cererii până când un om din echipa potrivită o deschide. Aici se vede efectul pentru client.

Corecțiile pe categorii

Unde greșește modelul cel mai des. De obicei, greșelile se adună pe una sau două categorii, iar cauza e o regulă neclară în proces, nu o slăbiciune a modelului.

Notează valorile înainte de lansare. Fără un punct de pornire, orice cifră de după pare bună. Cu el, poți spune exact ce s-a schimbat.

Cele mai multe proiecte eșuează din motive previzibile. Le poți evita dacă știi de ele de la început.

• Începi cu cel mai complicat proces. Tentația e să atingi imediat problema cea mai mare. Mai sigur e să alegi un proces repetitiv, cu volum mare și reguli pe care le poți scrie, cum e rutarea.
• Testezi pe exemple inventate. Cererile scrise de echipa de proiect sunt prea curate. Testează pe mesaje reale, cu greșeli de scriere, cu atașamente, cu două probleme în același mesaj.
• Nu definești ce e o greșeală. Dacă nu ai stabilit dinainte unde trebuia să ajungă o cerere, nu poți spune dacă sistemul a greșit.
• Lași sistemul nesupravegheat după lansare. Tipurile de cereri se schimbă, echipele se reorganizează, apar produse noi. Instrucțiunile trebuie revizuite periodic.
• Legi totul de o persoană. Dacă un singur om știe cum funcționează automatizarea, ai mutat dependența, nu ai eliminat-o.

Observă că niciuna dintre aceste greșeli nu ține de tehnologie. Toate țin de cum e gândit procesul și de cine răspunde de el. De aceea proiectarea procesului e partea cu cel mai mare impact asupra rezultatului.

Un asistent care citește cererile angajaților sau ale clienților are acces la date. Unele sunt banale, altele pot fi sensibile. Înainte de lansare, merită să știi exact ce date vede modelul, unde sunt procesate și cine are acces la istoric.

Câteva întrebări de clarificat cu echipa tehnică:

• Ce informații din cerere ajung la model și care pot fi eliminate înainte.
• Cât timp se păstrează conversațiile și cine le poate consulta.
• Cum afli, pentru o cerere anume, ce a decis sistemul și de ce.

Pe lângă protecția datelor, folosirea AI-ului în firme are și un cadru de reglementare european. Obligațiile depind de tipul de sistem și de cum este folosit, așa că nu merită să presupui nimic. Poți citi textul AI Act, adnotat în română, iar pentru o imagine mai largă, pagina despre cadrul legal AI în România strânge legislația și implicațiile ei.

Partea bună e că un proces bine proiectat te ajută și aici. Dacă ai scris ce decide modelul, ce decid regulile și unde intervine omul, ai deja o mare parte din documentația de care ai nevoie ca să explici sistemul.

Nu trebuie să pornești un proiect mare ca să afli dacă automatizarea cu AI are sens la tine. Poți începe cu un singur proces și cu date pe care le ai deja.

1. Alege un proces. Caută unul repetitiv, cu volum mare, unde intrarea e text liber. Rutarea cererilor interne sau a solicitărilor clienților e un punct de pornire bun.
2. Adună un eșantion real. Scoate cereri din ultimele luni, exact cum au venit, și notează unde ar fi trebuit să ajungă fiecare.
3. Scrie regulile și excepțiile. Stabilește categoriile, destinațiile și ce se întâmplă când decizia nu e sigură.
4. Măsoară situația de acum. Câte cereri sunt redirecționate, cât durează până la prima preluare, unde apar cele mai multe greșeli.
5. Decide unde stă asistentul. Alege canalul pe care echipa îl folosește deja și sistemul în care rămân evidența și istoricul.
6. Numește un responsabil. Cineva din firmă trebuie să urmărească indicatorii și să ajusteze instrucțiunile după lansare.

Dacă vrei să vezi mai întâi unde stai, evaluarea gradului de pregătire pentru AI îți arată ce procese și ce date ai deja pregătite. Cu rezultatul ei și cu harta procesului ales, discuția despre tehnologie devine mult mai scurtă și mai concretă.