Ghid: Cum să-ți motivezi echipa să adopte noile soluții software fără rezistență

Adoptarea unei noi soluții software nu este niciodată doar o chestiune tehnică. De cele mai multe ori, provocarea reală nu ține de cât de repede pot fi învățate funcționalitățile aplicației, ci de modul în care echipa reacționează la schimbare. Acceptarea unei astfel de soluții presupune mult mai mult decât familiarizarea cu butoane și meniuri — este un proces de adaptare, de construire a încrederii și de aliniere la o nouă viziune de lucru. 

Acest articol nu este despre coduri, servere sau integrări complexe. Este despre oameni. Despre cum îi implici, cum le câștigi încrederea și cum transformi o implementare software într-un proces colaborativ, fluid și eficient. Vom explora împreună motivele frecvente ale rezistenței la schimbare, pașii esențiali ai unei implementări reușite, rolurile-cheie din echipă, importanța analizei proceselor, avantajele abordării agile și, bineînțeles, cum să construiești un plan de proiect care să inspire și să mobilizeze.

Dacă vrei ca echipa ta să accepte schimbarea cu deschidere, să o integreze firesc în modul de lucru și să o valorifice cu încredere, acest ghid este pentru tine.

Motive ale rezistenței la schimbare

Bineînțeles că, în orice proces de implementare a unei soluții informatice, bugetul reprezintă prima și cea mai mare provocare. Imediat după acesta, urmează identificarea furnizorului potrivit și a echipei de implementare. Aceste două decizii — bugetul și alegerea furnizorului — sunt, de regulă, asumate de un număr restrâns de persoane, care, paradoxal, ajung rareori să fie utilizatorii direcți ai aplicației achiziționate.

Totuși, poate cea mai dificilă etapă într-un astfel de proiect este adoptarea efectivă a soluției de către echipă. Fără implicarea și susținerea celor care o vor folosi zi de zi, orice implementare riscă să rămână doar o inițiativă formală.

Procesul de adopție trebuie să înceapă încă din faza de bugetare, moment în care sponsorul proiectului are responsabilitatea de a comunica intenția și de a evidenția beneficiile aduse de noua soluție. Indiferent de tipul aplicației sau de furnizorul ales, scopul este același: ușurarea muncii de zi cu zi. Pentru utilizatori, cuvântul-cheie este „ușurare”, iar pentru management — „eficiență”.

O soluție informatică nu se implementează doar de dragul digitalizării. Ea trebuie să automatizeze acele sarcini repetitive care consumă timp, generează plictiseală și sunt predispuse la erori involuntare. Doar astfel poate deveni cu adevărat valoroasă pentru organizație.

De ce utilizatorii unei aplicații ar putea respinge sau nu ar accepta o soluție informatică?

Una dintre cauzele frecvente este teama că vor fi înlocuiți și își vor pierde locul de muncă. În contextul actual, în care resursa umană este tot mai greu de găsit, disponibilizarea nu este o soluție viabilă. Persoanele pot fi reorientate către alte zone ale activității, însă, de cele mai multe ori, implementarea unei soluții informatice duce la creșterea volumului de date procesate — cum ar fi, de exemplu, numărul de facturi — și astfel, cu același număr de operatori, se pot executa mai multe sarcini.

Un alt motiv pentru care utilizatorii ar putea respinge o soluție informatică este conceptul că „nu se poate mai bine”, pentru că angajatul știe să facă acel lucru de X ani. Poate are dreptate, însă viitorul utilizator al aplicației nu are o viziune de ansamblu asupra a ceea ce se întâmplă în amonte sau în aval de etapa operațională în care este implicat.

Se întâmplă frecvent ca, de exemplu, o verificare de lot în depozit să fie realizată de două ori — o dată la recepție și apoi la culegerea pentru livrare. În sistemul xTrack WMS, o dată ce lotul este înregistrat la recepție, nu mai este necesară o verificare suplimentară la livrare. Astfel, persoana care culege marfa devine mai eficientă, pentru simplul motiv că operatorul de la recepție a făcut deja această verificare.

Comoditatea de a învăța lucruri noi este, poate, aspectul care necesită cel mai mult efort în procesul de implementare. Dacă în cazul provocărilor legate de buget sau alegerea furnizorului se pot folosi argumente logice, aici este nevoie de o strategie de convingere, înainte ca viitorii utilizatori să-l ia pe „NU” în brațe.

Există două abordări eficiente:

Identificarea de suporteri ai proiectului — persoane-cheie care susțin inițiativa și care apar în mai multe etape:

• La stabilirea bugetului
• La identificarea furnizorului
• După primele teste

Adoptarea unei abordări de tip Agile în implementare. Aici nu ne referim la metoda utilizată de furnizor, ci la o abordare cu pași mărunți în instruirea și pornirea aplicației. Practic, trebuie identificate fluxuri care pot fi implementate și utilizate cu ușurință. Bineînțeles, aceste fluxuri trebuie să fie utile în ansamblu, iar implementarea lor să aducă beneficii clare.

Teama că sistemul va aduce mai mult de muncă este o reacție firească atunci când aplicația nu este cunoscută de către utilizatori. Necunoscutul poate genera un sentiment de complexitate, exact opusul a ceea ce își dorește managementul — adică eficientizare. Este interesant cum acest aspect se contrazice cu primul, în care oamenii cred în eficientizare, dar se tem de posibilitatea pierderii locului de muncă.

Pentru a elimina această temere, este esențială alocarea de timp pentru învățare, organizarea de workshop-uri și sesiuni de testare împreună cu implementatorii. Aceste acțiuni pot clarifica rapid modul de funcționare al aplicației și pot demonstra concret beneficiile aduse în activitatea zilnică.

Pentru a trece cât mai ușor peste provocarea dată de rezistența la schimbare, un lucru este necesar și obligatoriu: convingerea echipei de management — și mai ales a sponsorului — că noua aplicație trebuie implementată fără a se accepta scuze din partea viitorilor utilizatori. Mesajul transmis trebuie să fie ferm, clar și fără ezitări.

Cum trebuie implementat un proiect

Pentru ca un proiect să fie implementat cu succes, este absolut necesar ca atât furnizorul, cât și beneficiarul să investească timp și resurse. Implicarea activă a persoanelor din partea beneficiarului este importantă în toate etapele implementării, inclusiv în faza de analiză de fluxuri.

Pe baza sutelor de implementări realizate de echipa Axes Software, indiferent de complexitatea sistemului, am identificat câteva elemente-cheie care contribuie decisiv la finalizarea unui proiect cu succes și într-un buget convenabil pentru ambele părți. Printre acestea se numără:

• Definirea clară a responsabilităților în cadrul echipelor, în special din partea beneficiarului. În acest sens, o persoană foarte importantă într-un proiect informatic este power user-ul — utilizatorul care va cunoaște în detaliu aplicația și modul în care aceasta a fost configurată și pusă în funcțiune.
• Etapa de analiză a fluxurilor, necesară pentru identificarea celor mai bune soluții adaptate nevoilor clientului.
• Modul de lucru Agile, care nu se referă neapărat la dezvoltarea aplicației, ci la modul de implementare — cu pași mici, bine controlați, care permit o adaptare progresivă.
• Sesiuni de testare live, organizate după ce conceptele au fost explicate clar, atât în etapa de analiză, cât și în cea de instruire a utilizatorilor.
• Stabilirea unui plan de proiect asumat de ambele părți, a cărui nerespectare poate duce la costuri suplimentare și întârzieri.

Rolurile în cadrul proiectului

Ne referim aici la rolurile membrilor echipei din partea beneficiarului. În cazul proiectelor mici, o singură persoană poate prelua mai multe responsabilități dintre cele necesare pentru implementare.

Un rol important îl are project managerul de la beneficiar — persoana care se asigură că planul de proiect este respectat și că există resursele necesare, cum ar fi infrastructura, echipamentele hardware etc. Nu poți planifica o etapă în desfășurarea proiectului fără ca aceste resurse să fie disponibile. De exemplu, serverul trebuie să fie pregătit în momentul în care se dorește instalarea aplicației.

Super user-ul este persoana care trebuie să cunoască toate fluxurile care se implementează și, la un moment dat, să știe cum se fac configurările în aplicația respectivă. În etapa de implementare efectivă, această persoană devine puntea de legătură între echipa de utilizatori și echipa de implementatori (furnizorul).

Pe parcursul implementării, super user-ul joacă un rol foarte important: centralizează întrebările venite de la utilizatori, precum și eventualele erori apărute, și le transmite mai departe către echipa de implementare a furnizorului. De foarte multe ori, aceeași speță se repetă la mai mulți utilizatori și poate fi explicată sau rezolvată direct de către super user, fără a fi necesară intervenția furnizorului.

Utilizatorii care vor folosi aplicația zi de zi pot fi împărțiți pe diferite sectoare de activitate. Este recomandat ca, în procesul de implementare, cel puțin un reprezentant din fiecare departament sau echipă implicată pe diverse fluxuri să participe activ la discuțiile de analiză și la instruirea detaliată privind utilizarea aplicației.

Am observat că, de foarte multe ori, cei mai buni testeri sunt tocmai persoanele care, inițial, se opun proiectului. În dorința de a demonstra că au dreptate, aceștia testează aplicația în moduri variate și riguroase. Din acest motiv, recomandăm ca astfel de persoane să fie selectate ca reprezentanți ai departamentelor în procesul de implementare.

Consultantul de business: Beneficiarul poate desemna una sau mai multe persoane care să ofere răspunsuri clare și rapide legate de fluxurile de lucru, răspunsuri ce vor fi transmise echipei de la furnizor. De cele mai multe ori, această persoană este un consultant extern, care are o perspectivă diferită asupra proceselor de business față de angajații companiei beneficiare.

Consultantul de business poate propune modificări de flux care să fie integrate în soluția software. De regulă, este implicat în proiect chiar înainte de alegerea furnizorului, deoarece selecția acestuia se poate face inclusiv pe baza recomandărilor sau cerințelor consultantului, formulate din perspectiva proceselor interne.

Pe parcursul implementării, consultantul are responsabilitatea de a se asigura că recomandările și cerințele sale sunt puse în practică și, mai ales, acceptate de echipa beneficiarului. În plus, joacă un rol important de negociator neutru între cele două echipe — cea a beneficiarului și cea a furnizorului.

Pentru ca implementarea să fie realizată corect, persoanele implicate pe diferite roluri trebuie să aibă timp dedicat proiectului. Practic, acestea sunt scoase total sau parțial din activitatea curentă pe durata implementării aplicației software.

Etapele de instruire și testare ale funcționalităților pot dura multe ore, uneori chiar zile, în funcție de complexitatea proiectului. Este important ca acest timp să fie planificat din timp și asumat de echipa beneficiarului.

Analiza proceselor

Este clar că, în cadrul companiei beneficiare, există deja un model de business implementat și documentat. Mai mult, dacă în proiect este implicat un consultant, acesta a redactat un astfel de model care ar trebui să fie transpus în aplicația informatică. De regulă, acest model nu este detaliat din perspectiva unei soluții software, ci descrie pașii fiecărui proces și metodele de măsurare a performanței.

O aplicație informatică are propriile mecanisme și abordări, așa că modelul operațional trebuie tradus în termenii aplicației. De exemplu, dacă consultantul solicită ca factura să fie emisă în momentul în care șoferul a încărcat marfa, în aplicație trebuie definit clar modul în care se declanșează acel trigger care confirmă încărcarea. În funcție de capabilitățile aplicației, aceste cerințe pot fi automatizate într-un grad mai mare sau mai mic.

Toate aceste aspecte se detaliază într-un document de analiză, cunoscut și sub numele de Blue Print, care stă la baza implementării aplicației.

Documentul trebuie să fie validat de toate părțile implicate în proiect — în special de consultant, dar și de utilizatorii finali. În majoritatea cazurilor, acest document este întocmit de un reprezentant al furnizorului.

Documentul de analiză nu trebuie confundat cu un manual de utilizare, deoarece conține numeroase detalii tehnice care pot intimida utilizatorii finali. Scopul său este diferit: pe baza acestui document se face planificarea implementării și alocarea detaliată a resurselor.

Pentru o implementare de succes, recomandăm o abordare Agile — adică o implementare etapizată. Documentul de analiză este structurat în funcție de etapele principale ale fluxurilor ce urmează să fie integrate în aplicație. Este recomandat ca procesul să înceapă cu funcționalitățile simple, ușor de înțeles și de asimilat de către utilizatori, urmând ca cele mai complexe să fie abordate ulterior, pe măsură ce gradul de familiarizare crește.

Etapele de analiză și redactare a documentului Blue Print reprezintă o oportunitate valoroasă de a prezenta funcționalitățile aplicației și, totodată, de a instrui utilizatorii într-un mod practic și aplicat.

Din punctul nostru de vedere, etapa de analiză a proceselor este esențială pentru ca aplicația să fie adoptată cu ușurință de către utilizatori. Realizarea acestei etape în mod etapizat permite expunerea completă a cerințelor clientului, înțelegerea lor de către toate părțile implicate și implementarea corectă în aplicație.

Rolul analistului este crucial în desfășurarea proiectului. Acesta trebuie să intuiască nevoile reale ale clientului și să propună cele mai potrivite soluții din perspectiva utilizatorului final, astfel încât activitatea acestuia să fie cât mai simplificată. Ideal ar fi ca, după implementarea unui modul sau a unei etape de flux, să nu fie nevoie de reveniri asupra funcționalităților din cauza unor aspecte omise.

Se poate spune că experiența se capătă din proiecte similare, iar această abordare este, într-adevăr, cea mai facilă. Totuși, noi susținem că experiența relevantă poate proveni din orice domeniu care contribuie la succesul unei implementări noi. De exemplu, cunoștințele acumulate în afaceri cu piese auto pot fi aplicate cu succes în proiecte din zona farmaceutică — un caz real întâlnit în cerințele legate de funcționalitățile din depozit.

O soluție software validată în mai multe verticale este, de regulă, mai flexibilă decât o aplicație dedicată exclusiv unui singur domeniu. Această flexibilitate permite abordări și rezolvări inedite, adaptate cerințelor specifice ale fiecărui client.

La Axes Software, nu de puține ori am reușit să aducem soluții inovative pentru automatizarea unor procese, tocmai datorită experienței acumulate în sutele de proiecte implementate. Acest know-how valoros a contribuit la flexibilitatea aplicațiilor noastre și la capacitatea de a răspunde eficient provocărilor din diverse industrii.

Toate aceste lucruri contribuie la transformarea aplicațiilor Axes Software în cei mai buni parteneri ai utilizatorilor. După perioada de implementare, utilizatorii devin mai relaxați, eficiența lor crește semnificativ, iar numărul de erori scade vertiginos.

Modul de lucru Agile

Agile este un concept de lucru la modă în industria IT, iar la Axes Software îl folosim pentru ca implementările să fie mai ușor de înțeles și de parcurs de către utilizatori. La nivel macro, metodologia adoptată este Agile, însă la nivel micro — pe fiecare etapă a proiectului — lucrăm în stil Waterfall.

Această abordare ne permite să colectăm toate informațiile relevante pentru fiecare etapă, să le documentăm clar și să le includem într-un sprint sau două, în funcție de complexitate. Astfel, fiecare pas este bine definit, ușor de urmărit și adaptat nevoilor reale ale clientului.

Atunci când privim un proiect în ansamblu, urmărim să evidențiem finalitatea acestuia prin fluxuri cât mai simple, ușor de înțeles și de aplicat. Ulterior, dezvoltările detaliate din documentul Blue Print vin să completeze aceste fluxuri. Această abordare permite câștigarea de timp în implementare și facilitează adoptarea aplicației de către utilizatori.

În cadrul echipei Axes Software, folosim două metode de implementare, fiecare cu punctele sale forte:

Prima metodă de implementare presupune ca fiecare modul să fie analizat, configurat și implementat separat. Deși această abordare are o componentă mai pronunțată de tip Waterfall, dimensiunea redusă a modulelor permite ca implementarea să fie asimilată cu un proces Agile, întrucât se încadrează într-un singur sprint.

Practic, documentul de analiză devine backlog-ul sprintului. Această abordare deschide calea pentru etapele următoare, deoarece lucrurile devin mai clare pentru beneficiar, iar fluxul de lucru este mai ușor de gestionat.

Ideal este ca proiectul să fie împărțit în etape care pot fi tratate ca sprinturi de maximum două săptămâni. La finalul fiecărui sprint, după testările necesare împreună cu clientul, se poate face GoLive. Astfel, utilizatorii încep să folosească aplicația treptat, asimilând mult mai ușor informațiile.

Chiar și în etapele inițiale, unde nu toate persoanele sunt implicate direct, se pot organiza rotații de personal, astfel încât fiecare să aibă ocazia să se familiarizeze cu aplicația — fie pentru câteva ore, fie pentru câteva zile.

A doua metodă de implementare presupune instalarea aplicației cu funcționalitățile standard, pornirea fluxurilor, iar după o perioadă de instruire a personalului, se face GoLive pe întreaga aplicație.

Ulterior, analistul începe documentarea proceselor, iar clientul aduce în discuție mult mai multe aspecte și procese care pot fi optimizate, comparativ cu prima abordare. Pe măsură ce acumulează experiență și înțelege filosofia aplicației și capabilitățile acesteia, clientul devine un partener ideal — aproape un consultant — în procesul de implementare.

Efortul de învățare este concentrat într-un interval mai scurt, ceea ce poate genera un grad mai mare de stres pentru utilizatori și un risc crescut de respingere. Totuși, comunicarea cu clientul devine mult mai eficientă, pentru că se discută pe un teren comun, cu o înțelegere clară a aplicației.

Această abordare reflectă o orientare clară către principiile Agile și vine cu un avantaj important: distribuirea costurilor pe o perioadă mai lungă și obținerea de rezultate vizibile imediat după GoLive-ul inițial, cu funcționalitățile standard.

Fiecare proiect este unic, iar alegerea metodei de implementare trebuie făcută în funcție de alocările bugetare și de particularitățile clientului. Este important ca această decizie să fie precedată de o analiză SWOT, prin care clientul înțelege clar avantajele și riscurile asociate fiecărei abordări.

Există proiecte care nu pot fi tratate printr-o implementare standard, deoarece includ cerințe speciale care, dacă nu sunt integrate corect, pot transforma aplicația într-un obstacol în loc de un sprijin real. Un exemplu concret este cel al depozitelor în care marfa se cântărește, iar în timp pot apărea pierderi de greutate — un aspect ce trebuie gestionat cu atenție în aplicație.

Sesiuni de testare live 

Testarea live cu clientul este un pas esențial în procesul de implementare și ar trebui realizată cât mai aproape de etapa de analiză, pentru ca informațiile discutate să rămână proaspete și să nu se piardă. Această testare este necesară indiferent de metoda de implementare aleasă.

În timpul testării se utilizează manualele aferente fiecărui flux, chiar dacă acestea nu sunt încă în versiunea finală. Manualele pot fi apoi folosite și după finalizarea implementării, în procesul de instruire a noilor operatori. Este important ca aceste materiale să fie clare, să prezinte succesiunea operațiilor pas cu pas și să evite detaliile tehnice complexe, cum ar fi explicațiile privind comportamentul aplicației în anumite circumstanțe.

Testarea nu înseamnă doar parcurgerea unor pași și apăsarea unor butoane pentru a obține un rezultat. Totul începe cu o prezentare teoretică a conceptelor care stau la baza modulului sau etapei respective. Practic, se pornește „de la Adam și Eva”: se reia fluxul descris în documentul de analiză, se explică toate conceptele, inclusiv cele care nu sunt evidente la o primă utilizare, și abia apoi se trece la testare.

După instruirea teoretică, implementatorii exemplifică modul de lucru în aplicație, iar ulterior, toate testele sunt realizate de către utilizatori, fără intervenția directă a echipei de implementare. În această etapă, implementatorii devin observatori ai procesului de testare.

Este important ca toate scenariile de testare să fie acoperite de cât mai mulți dintre operatorii finali, pentru a valida corect funcționalitățile și a asigura o adoptare eficientă a aplicației.

Testarea se bazează pe scenarii clar definite, agreate împreună cu clientul înainte de începerea propriu-zisă a procesului. Fiecare scenariu trebuie să includă datele de intrare și rezultatele așteptate, astfel încât testele să fie relevante și complete. De exemplu, în cazul tipăririi unei facturi, trebuie verificate toate tipurile de facturi utilizate de client: cu stornări, cu discount-uri, cu același articol pe două linii, cu un număr mare de linii care nu încap pe o singură pagină, simulări de calcul TVA și alte particularități specifice fiecărei implementări.

Aceste teste necesită timp dedicat, atât din partea echipei de la furnizor, cât mai ales din partea beneficiarului. O testare riguroasă este esențială pentru a elimina erorile și pentru a acoperi toate aspectele funcționale. În același timp, etapa de testare este un moment excelent pentru ca utilizatorii să se familiarizeze cu aplicația și să o adopte în mod natural.

Scenariile de testare sunt construite în faza de analiză, când fiecare flux este detaliat. Documentul Blue Print evidențiază clar ce trebuie testat cu prioritate și care sunt zonele în care aplicația a fost particularizată.

La început, testarea poate fi anevoioasă, mai ales în primele etape ale implementării. Pe măsură ce proiectul avansează, testele devin mai ușor de realizat, iar timpul necesar pentru același grad de complexitate scade considerabil, ceea ce duce la creșterea eficienței utilizatorilor finali.

După finalizarea etapei de testare, manualele de utilizare sunt aduse la forma finală, ținând cont de feedback-ul primit de la utilizatori. Aceștia pot semnala aspecte neclare sau puncte care necesită clarificări, contribuind astfel la îmbunătățirea materialelor de instruire.

Este recomandat ca în etapa de testare să fie implicate și persoanele care, în fazele inițiale — fie la comunicarea intenției de implementare, fie la semnarea contractului — au manifestat un grad ridicat de respingere față de aplicație. O persoană reticentă care ajunge să accepte aplicația și îi recunoaște avantajele se poate transforma într-un aliat puternic. Prin simplul exemplu personal — „el a acceptat” — poate influența pozitiv colegii care urmează să fie implicați în etapele viitoare ale proiectului.

Planul de proiect 

Planul de proiect este un document foarte important în implementarea unei aplicații software. Prin intermediul acestuia, echipele își asumă o cadență clară, un buget estimat și o alocare precisă de resurse din diferite departamente ale beneficiarului.

Este important ca planul să țină cont de ritmul de învățare al utilizatorilor, pentru a evita suprasolicitarea și apariția unor noi motive de respingere a aplicației. În același timp, durata proiectului nu trebuie să fie excesiv de lungă, deoarece interesul pentru aplicație poate scădea, iar clientul poate ajunge să nu o mai dorească.

Respectarea planului de proiect este vitală: orice abatere poate duce la creșterea costurilor de implementare și la scăderea eficienței persoanelor implicate.

Planul de proiect reprezintă o călăuză pentru sponsori, oferindu-le repere clare privind momentele în care pot fi cuantificate beneficiile aplicației și etapele în care investiția începe să se recupereze treptat. Totodată, pentru utilizatorii finali, planul de proiect stabilește termenele la care aceștia trebuie să se mobilizeze pentru a realiza anumite activități — cum ar fi testarea — și pentru a începe utilizarea aplicației conform celor agreate.

Acest plan trebuie adoptat indiferent de metodele de implementare alese — descrise anterior — și trebuie să reflecte structura etapelor de analiză, fie că sunt parcurse treptat, fie simultan.

Planul de proiect devine astfel un instrument-cheie în procesul de adopție a aplicației. Respectarea lui contribuie decisiv la succesul implementării, oferind ambelor echipe — furnizor și beneficiar — un cadru clar pentru definirea și respectarea termenelor.

Rezistența la schimbare este poate cel mai mare obstacol în calea unei implementări reușite. Tocmai de aceea, fiecare etapă — de la analiză și testare până la instruire și GoLive — trebuie gândită nu doar din perspectiva tehnică, ci și umană. Implicarea utilizatorilor, ritmul adaptat de învățare și comunicarea constantă transformă reticența în încredere și contribuie decisiv la succesul proiectului.

La Axes Software, înțelegem că tehnologia nu funcționează fără oameni. Dacă vrei o echipă care să te ajute să gestionezi schimbarea, să adapteze soluția software la nevoile reale ale companiei tale și să transforme provocările în rezultate, te invităm să ne contactezi prin intermediul formularului de mai jos.