Desi vanzatorii de software de regula nu discuta despre riscurile de esuare a proiectelor de implementare software, nu este un secret faptul ca procentul de eroare in zilele noastre este destul de mare. Firme de consultanta si cercetare de piata publica procente de 25%-40% proiecte de implementare esuate sau cu probleme serioase. In unele cazuri clientii se retrag complet, in altele proiectele se desfasoara pentru mai putini useri decat in planul initial sau numai anumite module / functionalitati sunt utilizate.

 

Cum se poate evita acest risc? Studiile au scos la iveala o serie de aspecte ce trebuie avute in vedere inca de la inceputul proiectului pentru a evita esecurile si dezamagirile atat pentru client cat si pentru firma de consultanta cere realizeaza implementarea software:

 

  • Asteptari nerealiste din partea cumparatorului: cumparatorul impreuna cu consultantii trebuie sa evalueze in cel mai realist mod posibil aspctele specifice de business si masura in care se poate raspunde la problemele specifice. Intelegerea business-ului si a culturii companiei unde urmeaza sa se desfasoare proiectul de implementare sunt in egala masura importante ca si evaluarea structurii IT.

 

  • Fortarea implementarii: Riscurile de esec sunt ridicate atunci cand managementul din partea clientului forteaza proiectul in fata utilizatorilor. Managerii iau o decizie unilaterala fara sa stie exact situatia / starea de spirit din partea utilizatorilor. Utilizatorii pot sa nu doreasca deloc un sistem nou si sa nu inteleaga de ce o schimbare este necesara. In aceasta situatie, definirea unui project manager capabil, din partea clientului, este cea mai buna solutie in motivarea utilizatorilor si tinerea sub control permanent a evolutiei proiectului.

 

  • Lipsa suportului la nivel de top management: Proiectele de implementare pot intampina dificultati serioase atunci cand, de exemplu, numai departamentul de IT este implicat si responsabil.  Rareori apar propleme, dificultati sau intarzieri atunci cand top managementul este implicat in proiect. Managementul de la acest nivel trebuie sa fie implicat in proiect la nivelul de evaluare periodica a status-ului, problemelor, atingerea obiectivelor si riscuri existente.

 

  • Ignorarea aspectelor de business si a factorului uman: sisteme tehnlogice avansate sunt deseori alese pentru functionalitati superioare comparativ cu alte sisteme depasite. In aceste situatii aspecte deosebite legate de procesele de business sau probleme ale userilor risca sa fie ignorate. Astfel de proiecte implica schimbari de comportament si schimbari ale procesului de business si de management, aspecte foarte importante in calculul si estimarea efortului din partea clientului inca de la inceputul proiectului.

 

  • Criterii de evaluare a proiectului vagi: Cand este o implementare incheiata cu succes? Multe proiecte esueaza sau dezamagesc prin rezultate datorita lipsei unei definitii realiste a succesului implementarii. (departamente, procese, rezultate etc.)

 

  • Scopul proiectului este prea larg si nu poate fi controlat: Multe din proiectele mari sunt intarziate si produc dezamagiri in implemetare datorita controlului redus asupra implementarii. Proiectele mari trebuie impartite in etape, pe perioade scurte, cu obiective clare, pentru a putea fi controlate de la inceput pana la sfarsit. Termenele de evaluare a proiectului, in functie de definitia lor pot fi de zile, sau saptamani, nu luni sau chiar trimestre.

 

  • Capcana flexibilitatii: Cu cat un program software este mai flexibil cu atat este mai mare riscul de a dori adaptarea lui in cele mai mici detalii la procesul de business. De multe ori astfel de modificari afecteaza intregul proiect de implementare incepand cu scopul si obiectivele propuse initial. Controlul asupra acestui risc se realizeaza prin numireu unui manager de proiect calificat si investirea acestuia cu autoritatea de a spune nu atunci cand dezvoltarile si modificarile depasesc obiectivele si scopul initial al proiectului.

 

  • Proceduri de solicitate a modificarilor neadecvate: Chiar si modificarile in scopul initial al proiectului nu trebuie neaparat sa fie un risc major. Impactul pozitiv al acestor dezvoltari pe parcursul proiectului este asigurat de o procedura agreata, atat de client cat si de firma de implementare, de modificare a termenelor proiectului si a rezultatelor asteptate, precum si de amanarea anumitor faze ale proiectului catre un termen mai indepartat.

 

  • Complexitate nejustificata: De cele mai multe ori clientul doreste o aplicatie simplu de instalat, simplu de utilizat si care sa-i acopere cat mai mult din nevoi. Definirea corecta a proceselor pe care le acopera aplicatia fara a-i mari complexitatea inutil este un factor de succes al implementarii. Dezvoltarile excesive nu acopera de multe ori decat neinsemnate aspecte ale businessului dar consecintele construirii unei expertize ridicate in partea clientului pentru a controla aceste procese complexe de business au implicatii mult mai serioase.

 

  • Insuficient training pentru utilizatori: Niciodata dupa o implementare de succes clientul nu s-a plans ca utilizatorii au fost prea mult sau prea bine instruiti. In schimb de multe ori exista riscul ca o instruire insuficienta sa creeze propleme de utilizare si un volum mult mai mare de munca pentru utilizatori.

 

  • Delegarea deciziilor importante personalului neavizat: De multe ori managementul, din lipsa de timp, deleaga decizii personalului, necalificat in a lua astfel de decizii. Astfel se pierde foarte mult timp cu intrebari si incercari fara o finalizare concreta.

 

  • Lipsa unei viziuni de ansamblu si de perspectiva: de multe ori nu exista o persoana din partea clientului, calificata sa evalueze in ansamblu si in perspectiva proiectul de implementare. Modulele unui sistem ERP nu functioneaza separat si daca nu exista o viziune de ansablu asupra proiectului nu se face o evaluare realista a stadiului si a implicatiilor fiecarui proces implementat.

 

  • Bazarea excesiva pe consultanti: In calitate de consultanti, oamenii companiei de implementare duc greul proiectului, dar implicarea activa a clientului este esentiala. Trasferul total al muncii catre consultantii externi limiteaza abilitatea utilizatorilor clientului de a controla aplicatia si creaza de regula o dependenta nesanatoasa vis-a vis de firma de implementare.

 

  • Subestimarea importantei upgrade-urilor / dezvoltarilor in timp: In cazul trecerilor la versiuni superioare (upgrades) sau al extinderii sistemului de regula se subestimeaza resursele alocate si investitiile. Riscul creste daca modificarile / upgrade-urile sunt facute de personal intern (fara expertiza firmei de implementare).

 

  • Baze de date / date initiale neadecvate / incorecte / amestecate: Unul din cele mai importante motive de eroare sau esec in implementarea si utilizarea unui sistem informatic este incarcarea unei baza de date cu erori. O eroare de functionalitate se poate identifica si corecta usor dar erori provenite din baza de date incorecta fac sistemul inutilizabil si fac greu de identificat si de corectat sursa erorilor. Solutia este o verificare atenta a surselor de informatii si a calitatii datelor ce urmeaza a fi incarcate in sistem, din timp, astfel incat sa se evite blocaje in momentul de testare a sistemului.

 

  • Hardware necorespunzator: Caderi neasteptate a retelei sau a echipamentelor hardware sunt deseori sursa de probleme pe parcursul unui proiect de implementare a unui sistem ERP. Initiativa de a avea unu server comun pentru toate aplicatiile (mail, Internet, aplicatie soft pentru zeci de utilizatori) nu este o idee neaparat buna. Si de cele mai multe ori clientii nu fac o evaluare a echipamentelor hardware cand isi pun probleme instalarii unei aplicatii noi.

 

  • Suport post-vanzare slab: In achizitionarea unui sistem informatic unul dintre cele mai importante aspecte ce trebuie avut in vedere este suportul post vanzare. Competentele personalului de suport si lipsa intelegerii problemelor sau imposibilitatea de comunicare cu clientul sunt cele mai frecvente probleme ce pot aparea.

 

  • Ignorarea fazei “pilot” a proiectului, in proiectele complexe: Mai ales in proiectele mari, cu multe puncte de lucru si implementari separate pe fiecare punct de lucru, este importanta definirea unui proiect pilot care trebuie urmarit in cele mai mici detalii, atat pe parcurs cat si dupa finalizarea implementarii.

 

  • Lipsa de onestitate: Unele proiecte intampina probleme de la inceput, dar lipsa de onestitate in comunicarea acestora duce la tergiversarea si agravarea acestor probleme. Controlul asupra indeplinirii obiectivelor proiectului presupune o comunicare periodica bi-directionala, comunicare care, din nefericire, deseori este ignorata de ambele parti implicate in implementarea proiectului.