Nu automatiza un proces dezorganizat. Un proiect de digitalizare începe cu o analiză

Ai un proces care te enervează de luni de zile. Durează prea mult, se blochează mereu în același loc, cineva din echipă pierde ore întregi cu el în fiecare săptămână. La un moment dat te hotărăști: gata, îl automatizăm și scăpăm de el. E o decizie bună, dar de aici încolo drumul se desparte în două - și diferența dintre cele două variante decide dacă vei fi mulțumit peste un an sau vei repara constant ceva ce nu trebuia construit așa.

Prima variantă, cea tentantă, e să sari direct la soluție. Iei procesul așa cum e, îl dai pe mâna cuiva să-l automatizeze repede și aștepți rezultatul. A doua, cea care pare o întârziere inutilă, e să te oprești întâi și să înțelegi procesul în detaliu înainte să atingi vreo unealtă. Articolul de față arată de ce a doua variantă, deși cere răbdare la început, e singura care duce la un rezultat care ține.

Ce se întâmplă când automatizezi un proces dezorganizat

Există o iluzie răspândită: că automatizarea repară un proces prost. Pui tehnologia peste el și, cumva, lucrurile se aranjează. În realitate se întâmplă exact pe dos.

Când automatizezi un proces dezorganizat, nu îi pui ordine - îi codifici dezordinea și o accelerezi. Tot ce mergea prost manual va merge prost și automat, doar că mai repede și la scară mai mare. Pașii inutili rămân inutili. Excepțiile pe care nimeni nu le-a pus vreodată în ordine rămân excepții, doar că acum le întâlnește o unealtă care nu știe să improvizeze. Un om care procesează o comandă poate să se prindă când ceva nu se potrivește și să ia o decizie pe loc. O automatizare face exact ce a fost construită să facă, inclusiv atunci când datele de intrare nu se potrivesc cu ce se aștepta.

Aici e miezul problemei. Când construiești o automatizare peste un proces pe care nu l-ai înțeles până la capăt, nu automatizezi realitatea, ci o presupunere despre cum crezi tu că funcționează procesul. Iar presupunerea aproape niciodată nu acoperă tot. Funcționează pe cazul obișnuit, cel la care te-ai gândit, și cedează la prima excepție pe care n-ai prevăzut-o. E unul dintre motivele pentru care multe firme nu obțin rezultate din AI.

Nu e o părere izolată: IBM, pornind de la decenii de experiență cu firme aflate în plină digitalizare, observă că prea des organizațiile automatizează procese dezorganizate sau prost executate, iar a ști ce să automatizezi și ce nu este primul pas către un plan reușit.

Discovery: pasul pe care graba îl sare

În proiectele serioase de automatizare și digitalizare, etapa de la început, cea în care înțelegi cum funcționează procesul cu adevărat înainte să construiești ceva, are un nume: discovery. E faza de descoperire, în care nu se atinge nicio unealtă și nu se scrie nicio linie de cod - se observă, se întreabă, se cartografiază. Cum începe, pe unde trece, cine ce face, unde se blochează, ce se întâmplă când apare un caz neobișnuit.

Pare un pas care întârzie lucrurile, dar e fix invers. Discovery e ceea ce desparte un proiect care merge de unul care se transformă în reparații nesfârșite. Orice achiziție serioasă a unei firme începe, de altfel, la fel: nu cu alegerea produsului, ci cu înțelegerea problemei. Înainte să cumperi un utilaj, înainte să schimbi un furnizor, te lămurești întâi ce nevoie ai cu adevărat. Automatizarea nu face excepție, chiar dacă tentația de a sări direct la partea spectaculoasă e mai mare.

Saltul peste discovery are o explicație psihologică simplă: faza de descoperire nu se vede și nu impresionează pe nimeni. Nu poți arăta la o ședință o hartă de proces așa cum arăți o automatizare care rulează. Și totuși, tocmai harta aceea nevăzută decide dacă automatizarea va rula bine sau va pica.

Ce scoate la iveală o analiză bună

Adevărata valoare a unei analize nu stă în documentul pe care îl produce, ci în ce vede ea și tu nu mai vezi, pentru că ești prea aproape de proces. Iată ce iese de obicei la suprafață.

Excepțiile pe care nu le-ai pus niciodată în cuvinte. Fiecare proces are cazuri speciale, situații care nu urmează regula. Tu și echipa le rezolvați din instinct, fără să le numiți vreodată. O analiză le scoate la lumină, fiindcă exact acolo pică automatizările construite în grabă.

Cum se leagă de fapt pașii între ei. Pe hârtie, un proces pare o linie dreaptă. În realitate are ramificații, reveniri, pași care se fac în paralel sau în altă ordine decât crede toată lumea. O analiză scoate la iveală cum curge procesul cu adevărat, fiindcă pe fluxul real, nu pe cel imaginat, se construiește o soluție care nu pică la primul pas care nu se potrivește.

Informația pe care o știe un singur om. De obicei există o persoană care știe cum merge de fapt procesul, cu toate ocolișurile lui. Dacă acel om pleacă sau lipsește, procesul se clatină. O analiză transformă ce e în capul lui în ceva scris, pe care se poate construi.

Și mai e un lucru pe care o analiză onestă ți-l poate spune: că, așa cum arată acum, procesul tău nu e gata de automatizat. Uneori un proces e atât de dezorganizat încât a pune o automatizare peste el ar însemna doar să-i accelerezi dezordinea. Un partener corect îți spune asta deschis, în loc să-ți vândă o automatizare care n-ar rezista - fiindcă lucrează pentru rezultatul tău, nu pentru factură.

De ce analiza cere pe cineva care știe s-o facă

Tentația e să crezi că analiza o poți face singur, în fugă, între alte sarcini. Cunoști procesul, doar e al tău. Dar tocmai aici e capcana: pentru că ești prea aproape de el, vezi cum crezi tu că funcționează, nu cum funcționează de fapt. Iar diferența dintre cele două e exact locul unde se ascund problemele.

O analiză bună cere un ochi din afară, care a mai văzut zeci de procese și știe ce să caute: unde se ascund de obicei excepțiile, ce întrebări scot la iveală pașii inutili, cum arată un proces gata de automatizat față de unul care doar pare gata. E o pricepere în sine, nu ceva ce improvizezi între două ședințe.

La Cicada Technologies, orice colaborare cu un client începe cu această etapă de discovery, înainte să automatizăm orice. Nu o tratăm ca pe o formalitate, ci ca pe temelia întregului proiect, fiindcă am văzut de prea multe ori diferența dintre o automatizare construită pe un proces înțeles până la capăt și una construită pe o presupunere. Prima ține ani de zile. A doua se repară lună de lună.

Întrebări frecvente

Ce este discovery în procesul de automatizare?

Discovery este etapa de început a unui proiect de automatizare sau digitalizare, în care procesul e înțeles și cartografiat în detaliu înainte de a construi ceva. Se observă cum decurge procesul în realitate, pe unde trece, unde se blochează și ce se întâmplă în cazurile neobișnuite. Abia după această fază se trece la automatizarea propriu-zisă.

De ce nu pot automatiza direct un proces, fără analiză?

Pentru că, fără analiză, automatizezi o presupunere despre cum crezi că funcționează procesul, nu realitatea lui. Automatizarea va merge pe cazul obișnuit și va ceda la prima excepție neprevăzută. Analiza scoate la iveală excepțiile, pașii inutili și detaliile ascunse înainte ca ele să devină probleme.

Cât durează o analiză înainte de automatizare?

Depinde de complexitatea procesului, dar de obicei e mult mai scurtă decât graba ar sugera. Un proces clar poate fi înțeles în câteva ore de discuții focalizate. Procesele care cer mai mult sunt tocmai cele pe care nimeni nu le-a privit vreodată în ansamblu - iar acelea aveau, oricum, cea mai mare nevoie de analiză.

Ce se întâmplă dacă automatizez fără analiză?

Cel mai des, intri într-un ciclu de reparații: automatizarea merge la început, apoi cedează pe rând la fiecare situație neprevăzută, iar tu plătești în timp și nervi ceea ce ai fi economisit cu o analiză la început. În unele cazuri, automatizarea ajunge să coste mai mult decât valoarea pe care o aduce.

Orice proces dezorganizat are nevoie de automatizare?

Nu. Uneori un proces merge prost doar pentru că e dezorganizat, iar punerea lui în ordine rezolvă problema fără nicio automatizare. O analiză onestă îți poate spune exact asta - și te scutește de o cheltuială inutilă.

Ce merită să reții

Tentația de a sări direct la automatizare e de înțeles. Vrei să scapi de un proces care te enervează, iar analiza pare o întârziere între tine și rezultat. Dar tocmai graba asta e cea care transformă automatizările în surse de probleme, fiindcă o unealtă construită peste un proces neînțeles nu repară dezordinea, ci o accelerează.

Etapa de discovery nu e doar o formalitate. E pasul care decide dacă automatizarea ta va ține ani de zile sau se va strica la prima excepție. Un proces înțeles până la capăt, cu excepțiile lui, cu particularitățile lui, cu realitatea lui mapată înainte de tehnologie, e singurul pe care merită să construiești ceva.