De câte ori ne uităm peste statisticile pivind implementările de sisteme ERP, ne îngrozim când vedem cifrele mici care indică rate de succes de 20-30%. Firesc, ne intrebăm: ce se întâmplă? cum se măsoară rata de succes? este adevărat şi pentru piața româneasca? reflectă aceste statistici realitatea?
Aceste cifre arată o stare de fapt şi reflectă gradul de maturitate al industriei ERP, precum şi o realitate crudă cu care se confruntă de cele mai multe ori companiile care adoptă sisteme ERP: clienţii nu ştiu ce cumpără, iar furnizorii nu ştiu ce vând.
Acest articol încearcă să argumenteze ambele poziţii, client - furnizor, şi să sugereze posibile soluţii la această problemă cronică din industria ERP.
Perspectiva Beneficiarului
Dacă intrebăm 10 manageri dacă decizia de achiziţie privind un sistem ERP este aceeaşi cu decizia de achiziţie pentru alte investiţii precum echipamente industriale, spații de birouri, mașini, utilaje etc. vom primi 9 din 10 răspunsuri identice, previzibile, şi anume "da, decizia şi procesul de achiziție sunt aceleaşi". Cine s-a înşelat? care este răspunsul corect? Din păcate, avem un singur răspuns corect (în cazul fericit), un manager conştientizează ca achiziţia unui sistem ERP este "altceva" decât achiziţia altor bunuri. De ce n-ar fi acelaşi lucru şi de ce totuşi este altceva?
ERP-ul este un actor în cadrul organizaţiei, care afectează toate procesele şi care se infiltrează subtil în toate ungherele ei, schimbând modul în care oamenii lucrează, interacţionează şi îşi desfăşoară activitatea de zi cu zi. Viaţa ante ERP este diferită de cea post ERP. ERP-ul (înteles în sens larg include și CRM, SCM etc.) face parte din ADN-ul organizaţiei şi trebuie să se modeleze pe realitatea concretă în care trăieşte respectiva organizaţie. Performanţa organizaţiei este influenţată de performanţa sistemului ERP.
Beneficiarul se aşteaptă ca sistemul achiziţionat să se plieze rapid, eventual chiar automat, pe realitatea organizaţiei, uitându-se în momentul achiziţiei doar la functionalităţile pe care le oferă sistemul ERP, doar la "ce se vede" şi nu la planurile constructive şi arhitectura sistemului, adică "ce se află sub capotă".
Modul de construcţie al ERP-ului şi nu funcţionaliţăţile influenţează direct performanţa sistemului ERP (şi deci performanţa organizaţiei). Beneficiarii cumpără functionalităţi, ca o cutie neagră, fără să înţeleagă dacă ERP-ul poate susţine modelul organizaţiei, până în cele mai mici detalii.
Tragedia este că, de cele mai multe ori, nici nu există în companii modele (planuri constructive) care să descrie în detaliu organizaţia, ontologic şi funcţional, şi ca atare această "potrivire" între organizaţie şi ERP este greu de realizat.
Făcând o paralelă cu construirea unei case, suntem într-un scenariu în care beneficiarul construieşte o casă ştiind ca are nevoie de 3 dormitoare, un living, o bucătărie utilată, 2 balcoane, grădină exterioară etc. (adică "funcționalități" ) fără să vadă şi să valideze arhitectura şi planurile constructive ale casei ! Se semnează contractul, se stabilește bugetul şi se începe "lucrarea", iar casa, croită din mers, vă daţi seama cum iese … după imaginaţia fiecăruia.
O primă concluzie: Achiziția unui ERP nu înseamnă achiziţia de functionalităţi! Caietele de sarcini pentru achiziţia de ERP-uri, cu multe pagini de functionalități, nu garanteaza nicidecum succesul implementării, chiar dacă furnizorul reuşeşte să "bifeze" toate funcționalitățile din caiet. Este mai importantă maparea planurilor constructive ale organizaţiei cu cele ale sistemului ERP, pentru a determina dacă există o potrivire între ERP şi organizaţie.
Perspectiva Furnizorului
Vânzătorul de ERP intră în aceeaşi capcană şi prezintă beneficiarului functionalităţi, pentru a-l convinge că are produsul potrivit. Negreşit functionalităţile software sunt importante, dar nu sunt hotărâtoare şi nici suficiente pentru a asigura "potrivirea" şi succesul implementării.
Vânzătorul evită discuţii tehnice despre arhitectură, pentru că majoritatea interlocutorilor sunt persoane de business non-tehnice, iar abordarea plecând de la planurile constructive ale organizaţiei nu îi este la îndemână.
Vânzătorul de ERP nu știe de fapt că el nu vinde funcționalităţi, ci parte din performanţa organizaţiei care se sprijină pe un model organizațional, model pe care, din nefericire, furnizorul nu îl cunoaşte în timpul procesului de vânzare.
Altfel spus, furnizorul se confruntă cu realitatea organizaţiei beneficiarului, pe care nu o înţelege apriori, iar tot ceea ce poate face este să lanseze presupoziţii, susţinute eventual de experienţe similare în alte companii cu profil asemănător. Dar, chiar în cazul unor companii din acelaşi domeniu de activitate, acelaşi sistem ERP poate fi implementat cu succes într-un caz, iar în alte cazuri poate fi un eşec.
Aşadar, doar experienţa în alte organizaţii similare nu garantează succesul, pentru că realităţile sunt total diferite de la o organizaţie la alta, inclusiv modul de implementare a aceluiași model organizațional.
Pe lângă necunoaşterea realităţii şi încercarea de aliniere la aşteptările beneficiarului cu prezentarea de functionalităţi, vânzătorul - care ar trebui sa fie primul consultant de business al beneficiarului - se confruntă şi cu presiunea concurenţei pe de o parte şi presiunea bugetului, de cealaltă parte, ceea ce-l determină să accepte diverse compromisuri la semnarea contractului, ce se transformă ulterior în frustrări şi nemulţumiri pe parcursul implementării.
Concluzia 2: Realitatea beneficiarului este o necunoscută pentru furnizor. Fără o validare prealabilă a modelelor de business, furnizorul semnează doar un contract de promisiuni şi aşteptări (speranţe) pentru un soft care are o arhitectură şi anumite funcţionalităţi.
Cum se poate ieși din capcana de mai sus? Beneficiarul nu știe ce cumpără, iar furnizorul nu ştie cui vinde şi în ce realitate intră cu proiectul de implementare.
Pentru a elimina riscurile legate de "necunoscut" şi a creşte şansele de succes non-accidental, câteva acțiuni se impun înainte de semnarea finală a contractului:
- Beneficiarul să angajeze un proiect - pilot pentru a valida nu doar funcționalităţile, ci şi arhitectura (interfaţa, flexibilitatea în modificări/adaptări, raportări), precum şi modelul pe care este construită organizaţia. Acest pilot înseamnă costuri suplimentare, dar poate evita un angajament final cu cheltuieli mult mari mari, în cazul unei nepotriviri.
- Furnizorul poate prezenta "planurile constructive ale viitoarei case", ceea ce presupune un angajament de consultanţă înainte de a implementa ERP-ul. Realitatea de la beneficiar trebuie validată de modele constructive care să fie susţinute de sistemul ERP.
- Definirea clară a responsabilităţii - este şi concluzia a treia - responsabilitatea pentru succesul implementării este la beneficiar. El trebuie să găsească şi să numească persoana (şi echipa) responsabilă cu implementarea. Furnizorul oferă sistemul, toate serviciile de asistenţă (analiza, școlarizare, asistența, etc.), dar organizaţia este cunoscută şi administrată (pe toate planurile) cel mai bine de către angajații ei și nicidecum de un furnizor extern, care nu se poate substitui în procesele critice unde se infiltrează şi sistemul ERP.
Concluzie
Pe lângă motivele clasice pentru insuccesul implementării - project management şi scheme simplificate de bugetare - necunoașterea realității beneficiarului de către furnizor, inexistența unor modele organizaționale care să fie validate înainte de implementare şi neasumarea clară a responsabilității implementării sunt cauzele principale pentru care succesul implementării ERP rămâne o incertitudine.
