.jpg)
Academia Română a fost creată în 1866 pentru a cristaliza cele mai înalte valori intelectuale din provinciile românești într-o societate erudită menită să consolideze identitatea națională pe baza a patru componente esențiale: limbă și literatură, istorie, etnografie și cultură. La...
De ce esueaza implementarile software
„Cuuuum? Exista implementari software esuate? Account managerul vostru mi-a spus ca daca alegem compania voastra si produsul x, rata de succes a proiectului este de 100% - ca mergem la sigur cum s-ar spune...”.
Mi-as dori sa fie asa – daca as sti ca exista o companie si/sau o aplicatie pentru care rata de succes a implementarilor sa fie de 100% - as face tot posibilul sa lucrez pentru acea companie si as implementa numai acel produs. Mai mult, daca as sti ca exista o cale de a face ca implementarile sa reuseasca întotdeauna, ea ar fi deja implementata în compania pe care o coordonez.
Din pacate, lucrurile sunt ceva mai complicate – adica exista implementari esuate (si, mai mult decat atat, industria de aplicatii software are o rata atat de mare de esec încat a devenit un fel de referinta negativa în materie de management de proiect) si compania/produsul reprezinta numai o parte a problemei, dupa cum vom vedea mai departe.
1. Definirea incorecta a ariei de implementat. Chestiunea începe cu mult înainte de începerea implementarii – si anume de la primele prezentari si demonstratii de produs – atunci cand viitorul client pune celebrele întrebari „se poate si asta?”, iar raspunsul consultantului este aproape invariabil da, urmat de o explicatie sumara. Ce se întampla în spatele acestui proces este crearea a doua seturi de astep-tari (ale clientului si ale furnizorului) care numai întamplator sunt complet convergente.
Un alt factor îl constituie literatura sau afirmatiile „de marketing” de genul „avem un produs adecvat 100% companiilor de media si advertising”. Rezultatul unor astfel de afirmatii va fi – din nou – un set de asteptari care va fi mai tarziu infirmat partial de realitatile implementarii.
Solutia – ce tine de domeniul evidentei – este conturarea cu mult mai precauta si mai precisa a cerintelor de catre client (mult prea adesea clientii doresc implementari care sa faca „totul”) si întelegerea si evaluarea realista a solutiilor propuse de catre furnizor. Solutie simpla – atat de simpla încat este greu inaplicabila în practica... deoarece în orice selectie de software va exista cel putin un competitor care sa afirme cu mana pe inima si privind în ochii clientului ca produsul lui chiar face totul (ce-o fi totul, mai vedem).
2. Lipsa controlului asupra schimbarilor în procesul de implementare. Chiar daca s-au depus toate eforturile pentru o definire cat mai clara a ariei de implementare în procesul de selectie si la începutul proiectului, totusi exista un numar extrem de mare de elemente de detaliu care nu pot fi incluse în acest proces initial, si care apar pe parcurs, dupa cum tot pe parcurs pot aparea elemente semnificative ce pot produce schimbari importante.
Este extrem de important ca aceste elemente de parcurs sa fie si ele analizate si aprobate cu toata atentia, pentru ca în lipsa unui proces de control riguros al schimbarilor aceste cereri vor prolifera iar proiectul se va înnamoli în implementarea unor chestiuni cruciale cum ar fi „butonul de submit trebuie sa fie în partea dreapta-sus”, „înregistrarile selectate trebuie sa aiba culoarea de fond galben, nu albastru” sau „coloanele x si y ale raportului trebuie inversate”.
Desi poate importante pentru unii utilizatori, cand numarul cererilor de acest tip ajunge de ordinul zecilor (am vazut proiecte cu astfel de cereri de ordinul sutelor), tot ce se mai face în acel proiect este implementarea acestor cereri. Adica nimic.
3. Lipsa resurselor alocate proiectului. Este vorba atat de resursele din partea furnizorului (din ratiuni competitive, proiectele sunt foarte adesea dimensionate în asa fel încat este imposibila alocarea consultantilor on-site), cat si de resursele din partea clientului (o gluma pe aceasta tema spune ca un client va aloca în proiect fie angajatii care stau degeaba prin firma – caz în care managerul de proiect nu îi poate oricum folosi la nimic, fie angajatii cei mai performanti ai firmei – caz în care managerul de proiect poate sa faca orice cu ei – dar nu are cand, pentru ca acei angajati au deja gradul de ocupare mai mare de 100%).
Parerea ta conteaza: 
Informatizare in Tomania
