Introducere
Există un paradox frecvent în organizațiile care decid să se digitalizeze: achiziționează un sistem software, îl instalează, poate chiar îl configurează parțial și apoi, după câteva luni, îl folosesc tot mai rar. Eventual, nu îl mai folosesc deloc. Activitatea revine la Excel, la agende, la comunicarea informală.
Nu este o problemă de calitate a software-ului. Este o problemă de adoptare. Iar adoptarea eșuează din motive previzibile, care se repetă în industrii diferite și la dimensiuni diferite de organizații.
Înțelegerea acestor motive este mai utilă decât orice listă de funcționalități, pentru că arată ce trebuie pregătit înainte ca software-ul să fie cumpărat, nu după.
Software-ul a fost cumpărat fără o problemă clară de rezolvat
Cea mai frecventă cauză a abandonării unui sistem este că nu a existat niciodată o nevoie concretă și măsurabilă care să justifice achiziția. Software-ul a fost cumpărat pentru că „toată lumea se digitalizează”, pentru că un concurent a implementat ceva similar sau pentru că a existat o presiune externă de modernizare.
Fără o problemă clară de rezolvat, nu există nici un criteriu de succes. Echipa nu știe ce ar trebui să fie diferit după implementare față de înainte. Și dacă nu este clar ce se îmbunătățește, motivația de a schimba obiceiurile de lucru este aproape zero.
Digitalizarea eficientă pornește dintr-o întrebare specifică: ce proces din activitatea noastră consumă cel mai mult timp inutil sau generează cel mai multe erori? Răspunsul la această întrebare definește ce ar trebui să facă software-ul și cum va fi măsurat dacă funcționează.
Echipa nu a fost pregătită pentru schimbare
Implementarea unui software nou înseamnă, înainte de orice, o schimbare în modul de lucru al oamenilor. Această schimbare generează rezistență chiar și atunci când nimeni nu o verbalizează explicit.
Rezistența apare din motive concrete: oamenii nu știu să folosească noul sistem la fel de repede ca metoda veche, iar în primele săptămâni productivitatea lor scade. Dacă nu există răbdare și suport în această perioadă, ei revin la ceea ce știu. Nici nu este o decizie conștientă, este o reacție naturală la fricțiune.
Problema se complică atunci când conducerea a comunicat implementarea ca pe un fapt împlinit, fără să explice de ce se schimbă lucrurile, ce va fi mai bun și cum va arăta activitatea zilnică după tranziție. Oamenii nu sunt împotriva schimbării în sine. Sunt împotriva schimbărilor pe care nu le înțeleg și în care nu au niciun cuvânt de spus.
Implementarea a fost superficială
Un software instalat și configurat minimal nu este un software implementat. Este un software prezent.
Implementarea reală presupune că procesele din organizație au fost adaptate pentru a funcționa prin sistem. Datele existente au fost migrate. Nomenclatoarele sunt completate. Permisiunile fiecărui utilizator sunt definite corect, astfel încât fiecare persoană vede și poate face exact ce are nevoie, nu mai mult și nu mai puțin. Notificările automate sunt configurate. Rapoartele relevante sunt identificate și testate.
Când implementarea se oprește la instalare și la o sesiune scurtă de prezentare, software-ul rămâne un instrument pe care echipa nu știe cum să îl folosească în situațiile concrete din activitatea lor zilnică. La prima dificultate, revin la metoda veche.
Procesele interne nu au fost clarificate înainte de implementare
Software-ul automatizează și standardizează procese. Dacă procesele nu sunt definite clar înainte de implementare, software-ul nu poate face decât să formalizeze haosul existent.
O clinică în care fiecare medic gestionează programările altfel, în care fișele pacienților sunt completate incomplet sau în formate diferite, în care responsabilitățile administrative nu sunt clare, nu va deveni mai organizată prin simpla introducere a unui sistem digital. Va fi la fel de dezorganizată, doar că pe un suport digital.
Înainte de a configura un sistem, organizația trebuie să știe răspunsul la câteva întrebări fundamentale: cine introduce ce date și când, cine are acces la ce informații, care sunt pașii unui proces de la start la final. Abia după ce aceste răspunsuri există, software-ul poate fi configurat să le respecte.
Datele introduse în sistem nu sunt folosite
Există organizații care introduc date în sistem în mod consecvent, dar nu generează niciodată rapoarte, nu analizează ce se întâmplă cu activitatea lor și nu iau decizii pe baza informațiilor disponibile. Sistemul este folosit ca un registru mai modern, nu ca un instrument de management.
Această situație apare când nu există cultura de a lucra cu date și când nu există obiceiul de a verifica periodic indicatorii activității. Dacă managerul nu cere rapoarte, echipa nu generează rapoarte. Dacă rapoartele nu sunt citite, datele nu sunt introduse cu acuratețea necesară. Cercul se închide și software-ul devine marginal.
Valoarea reală a unui sistem digital apare când datele introduse zilnic sunt transformate în informații utile pentru management: câți pacienți noi au venit luna aceasta, care sunt tratamentele cel mai des efectuate, cum evoluează încasările față de aceeași perioadă a anului anterior, care este situația stocurilor sau care este raportul dintre producția realizată și cheltuielile înregistrate. Aceste informații există în sistem. Trebuie doar căutate.
Așteptările față de rezultate au fost nerealiste
Unele organizații abandonează software-ul pentru că rezultatele nu au apărut imediat. Au așteptat ca, în prima lună după implementare, procesele să devină mai eficiente, costurile să scadă și echipa să lucreze mai bine. Când nu s-a întâmplat asta, au concluzionat că software-ul nu funcționează.
Digitalizarea nu produce rezultate în prima lună. Produce rezultate după ce echipa a adoptat noile fluxuri de lucru, după ce datele din sistem sunt suficient de complete pentru a genera analize relevante și după ce organizația a dezvoltat obiceiul de a lua decizii pe baza informațiilor din sistem.
Aceasta nu este o problemă a software-ului. Este o problemă de așteptări, care trebuie gestionată din start, cu realism despre ce înseamnă tranziția și cât durează.
Concluzie
Software-ul care stă nefolosit nu este un eșec al tehnologiei. Este, de obicei, un simptom al unuia dintre lucrurile descrise mai sus: o nevoie nedefinită clar, o echipă nepregătită, o implementare incompletă, procese interne neclare, lipsa obiceiului de a lucra cu date sau așteptări nerealiste.
Fiecare dintre aceste cauze poate fi prevenită. Dar poate fi prevenită doar dacă este identificată înainte de achiziție, nu după. Întrebarea nu este ce funcționalități are software-ul. Întrebarea este ce este gata organizația să schimbe și ce suport are nevoie echipa ca schimbarea să se întâmple cu adevărat.
