SISTEME ERP Implementarea PDF [PDF]

Zitiervorschau

I. SISTEME INFORMATICE INTEGRATE (ERP)

1. Obiective După parcurgerea acestui capitol, studenții vor putea:  Să evalueze modul în care sistemele informatice integrate de tip ERP furnizează valoare adăugată pentru organizație și să descrie modul de funcționare a acestora  Să explice modul în care sistemele informatice integrate pot fi utilizate pentru crearea de servicii cross-funcționale  Să identifice provocările ridicate de implementarea sistemelor informatice integrate  Să evalueze o strategie de implementare a unui sistem informatic integrat  Să evite principalele greșeli apărute în implementarea sistemelor informatice integrate 2. Introducere O cale excelentă de a începe analiza unei organizaţii este de a vedea organizaţia ca un sistem sau grup de procese legate. Gândirea la nivel de sistem presupune înţelegerea forţelor şi interdependenţelor existente între diferitele arii funcţionale dintr-o organizaţie. Sistemele ERP trebuie privite ca un grup de procese interdependente, gestionate de oameni. Înțelegerea acestora presupune aprofundarea modului în care sunt dezvoltate, gestionate și întreţinute de către oameni, în cadrul unei organizaţii. 3. Definirea și importanța sistemelor de tip ERP Sistemele ERP integrează informaţii interne şi externe de management din întreaga organizaţie, acoperind toate procesele din cadrul acesteia, precum cele financiar-contabilitate, vânzări, aprovizionare, producţie service, gestiunea relaţiilor cu clienţii etc. Sistemele ERP automatizează activităţile din organizaţie cu ajutorul aplicaţiilor software integrate. Scopul ERP este de a facilita fluxul de informaţii între diferite funcţii ale organizaţiei şi a de a gestiona tranzacţiile şi conexiunile cu partenerii externi. Sistemele ERP pot rula pe diferite platforme hardware şi configuraţii de reţea şi au de regulă o bază de date unică, pentru a depozita informaţiile în mod consistent. Acronime consacrate:  ERP = Enterprise Resurce Planning  MRP = Materials Requirement Planning 4. Motive pentru apariţia ERP-urilor O organizaţie care nu are un ERP croit pe nevoile ei se poate regăsi în situaţia în care utilizează mai multe programe/aplicaţii software care nu interacţionează între ele și care nu pot fi modificate/adaptate. Din această cauză, aceste aplicaţii nu pot optimiza activităţile din cadrul organizaţei. În acest scenariu se cheltuie efort semnificativ cu întreţinerea şi îmbunătăţirea

1

aplicaţiilor singulare, iar complexitatea creşte exponenţial pe măsură ce se încearcă crearea interdependenţelor între aplicaţii, respectiv ariile funcţionale: vânzări, aprovizionare, producţie, contabilitate etc. Toate aceste lucruri se schimbă în momentul în care se implementează un sistem ERP. Fluxurile informaţionale sunt fluide şi constante şi permit urmărirea proceselor în orice moment, indiferent de proces sau de activitate din cadrul procesului. De exemplu, stadiul livrărilor se poate urmări în timp real, de la comanda clientului şi până la încasare. Achiziţiile şi cheltuielile pot fi controlate în funcţie de limitele bugetare şi de nivelele de aprobare din organizaţie, cu reflectare imediată în contabilitate. Funcţiile de marketing, vânzări, aprovizionare, logistică, controlul calităţii, stocuri, producţie, trezorerie, contabilitate şi multe alte areale funcţionale pot fi integrate într-o bază de date unică cu ajutorul unui sistem ERP. Acest lucru duce la eliminarea pierderilor ocazionale de informaţii şi la minimizarea erorilor care provin din reintroducerea datelor. Această abordare integrează toate departamentele şi funcţiile din cadrul organizaţiei, într-un singur sistem informatic care poate fi accesat şi utilizat de către angajaţi şi deserveşte nevoile specifice la nivel departamental, precum şi pe cele la nivel organizaţional. Sistemele ERP modelează şi automatizează procesele de business, care sunt astfel standardizate şi oferă acelaşi nivel de înţelegere pentru toată lumea, chiar şi în relaţiile cu clienţii şi furnizorii cu care organizaţia interacţionează. Aceste sisteme stochează date istorice despre activităţile din organizaţie, pe o perioadă lungă de timp, precum şi activitatea curentă şi planurile viitoare şi organizează informaţiile într-o manieră uşor de înţeles, pentru a dezvolta strategiile de business şi a ajuta la luarea mai rapidă a deciziilor. În sistemele ERP sunt integrate datele financiare prin funcţia financiar-contabilă, ce reprezintă fundaţia pe care se sprijină restul proceselor şi care colectează toate tranzacţiile şi consecinţele lor contabile pentru a înţelege şi analiza performanţa organizaţiei. Cifrele din ‘operaţional’ (ex. volumul de vânzări) se reflectă imediat şi în contabilitate (ex. conturile de venituri din balanta contabila sau contul de profit si pierdere) astfel încât se poate obţine o singură versiune a adevărului. Un caz aparte, care justifică nevoia unui sistem ERP, se regăseşte în organizaţiile cu mai multe divizii (business units) sau organizaţii care au fuzionat sau au achiţionat alte companii şi care sunt puse în situaţia de a integra procesele.

5. Noţiunea de siloz (silo) versus noţiunea de sistem integrat Noţiunea de siloz presupune existenţa mai multor programe, care nu comunică între ele fiecare utilizând o bază de date proprie, în contradicţie cu un sistem integrat care, având o singură bază de date, reuşeşte să integreze toate procesele din organizaţie.

2

Sistemul integrat acoperă toate ariile funcţionale din organizaţie 6. Istoria ERP-urilor Istoria ERP-urilor este un subiect destul de amplu şi interesant. În câteva cuvinte, evoluţia a început de la sistemele MRP din anii ‘60 care acopereau nevoia de a gestiona cereea şi comenzile, fără să se uite la timp (dinamică), doar la nevoi. MRP II s-a dezvoltat în anii ‘70 pentru a aduce atât cererea, cât şi orizontul ei de timp în procesele de planificare. În acelaşi timp, soluţiile de gestiune financiar-contabilă au câştigat teren, fiind din ce în ce mai puternice şi performante. Sistemele ERP s-au metamorfozat din precedentele sisteme MRP II care au fost integrate cu aplicaţiile financiare, pentru a oferi soluţii complete şi integrate de gestiune. Istoria ERP-urilor cunoaşte câteva etape majore, dependente şi de evoluţia tehnologie informaţiei: 

1960 - primele calculatoare, reorder point (ROP) systems şi primele sisteme MRP (material requirements planning.  J.I. Case - constructor de tractoare - şi IBM conlucrează pentru elaborarea unui software de pentru planificarea aprovizionării de componente.



1970 - MRP şi dezvoltări hardware şi software  Primele sisteme MRP sunt mari, scumpe şi greoaie. Este nevoie de o echipă tehnică numeroasă pentru a întreţine sistemele mainframe, pe care rulau aceste programe.  1972 - Cinci ingineri din Mannheim, Germania, înfiinţează compania SAP (Systemanalyse und Programmentwicklung). Scopul SAP este de a produce şi comercializa software standard pentru soluţii integrate de business.

3

 1975 - Richard Lawson, Bill Lawson, John Cerullo dau naştere la Lawson Software. Fondatorii au intuit nevoia unor soluţii software de întreprindere gata împachetate, ca alternativă la aplicaţiile de business la cheie (customizare).  1976 - În domeniile cu producţie, sistemul MRP (Material Requirements Planning) devine concept fundamental utilizat în controlul şi gestiunea producţiei.  1977 - Jack Thompson, Dan Gregory şi Ed McVaney formează JD Edwards. Fiecare fondator are o bucată din numele său în denumirea companiei. În acelaşi an, Larry Ellison înfiinţează Oracle Corporation.  1978 - Jan Baan - Olanda - înfiinţează The Baan Corporation pentru a furniza servicii de consultanţă financiară şi de management.  1979 - Oracle oferă primul sistem de baze de date relaţionale, comercial. SAP lansează sistemul R/2. 

1980 - MRP II  1980 - JD Edwards se concentrează pe IBM System/38. MRP evoluează în MRP II cu extensii în zonele de shop floor (ateliere/secţiile de lucru) şi managementul activităţilor de distribuţie.  1981 - Baan începe să utilizeze sistemul de operare Unix, ca sistem de bază  1982 - Baan livrează primul produs software. JD Edwards se concentrează în continuare pe IBM System  1983 - Oracle oferă o bază de date în mod VAX, precum şi o bază de date scrisă în întregime în limbaju C, pentru portabilitate  1984 - Baan îşi concentreză eforturile spre funcţionalităţile de producţie şi planificare.  1985 - JD Edwards este recunoscut ca leader în industria aplicaţiilor software pentru succesul repurtat cu IBM AS/400, un descendent al System/38.  1987 - Peoplesoft este fondat de către Dave Duffield şi Ken Morris  1988 - Peoplesoft dezoltă sistemul de gestiune a resurselor umane (HRMS)



1990 - MRP II şi începuturile sistemelor ERP  1990 - Baan software este distribuit în 35 ţări, prin canal indirect. Termenul ERP îşi face apariţia, când sistemele MRP II se extind pentru a acoperii arii precum: financiarcontabilitate, resurse umane, project management ş.a.  1991 - Peoplesoft deschide birouri în Canada, urmate apoi de altele în Europa, Asia, Africa, America de Sud.  1995 - Baan creşte şi ajunge la 1800 clienţi globali şi peste 1000 angajaţi  1999 - JD Edwards are peste 4700 clienţi, în peste 100 ţări. Oracle are peste 41000 clienţi, din care 16000 în SUA. Peoplesoft este utilizat în mai mult de 50% din piaţa de aplicaţii pentru HR.  1999 - SAP este cel mai mare producător de soft pentru înteprinderi şi al patrulea furnizori independent de software., cu peste 20500 angajaţi în peste 50 ţări. La aceeaşi dată, mai mult de 2800 sisteme Baan au fost implementate în aproximativ 4800 locaţii pe glob.

4



2000 - consolidarea furnizorilor de software  2001 - După 11-Septembrie are loc o scădere în cererea de sisteme ERP.  2002 - Majoritatea sistemelor ERP actualizează produsele pentru a le face “Internet enabled” (Internet active), astfel încât clienţii pot avea acces direct în sistemele furnizorilor ERP.  2004 - Services Oriented Architecture (SOA) devine standardul la care furnizorii ERP încep să se alinieze. Această arhitectură software permite ca diferite sisteme să comunice între ele.  2003 - 2005 apar consolidările: Oracle: E-Business Suite, JD Edwards, Peoplesoft, Siebel, Retek s.a. Microsoft: Axapta, Navision, Great Plains si Solomon Infor: Baan, Mapics s.a.  2004-2007 primele sisteme ERP opensource: Compiere, openERP s.a.



Viitorul sistemelor ERP  Piaţa va cunoaşte în continuare consolidări, dat fiind faptul că în spaţiul SMB (Small and Medium Sized Companies) ea este încă foarte fragmentată, cu sute de jucători.  O nouă etapă în istoria ERPurilor se scrie pe măsură ce furnizorii migrează către cloud, fie furnizori tradiţionali, fie furnizorii mai noi.

7. Piaţa de ERP-uri Pe măsură ce lumea continuă să evolueze într-o economie globală şi sistemele ERP cunosc o evoluţie similară. Soluţiile ERP proprietate care se instalează pe infrastructura beneficiarului nu mai reprezintă astăzi singura opţiune. Azi există soluţii ERP de tip SaaS (software as a service), de tip on-demand (la cerere) sau open-source. Cu toate aceste opţiuni disponibile companiilor de pe întreg mapamondul, piaţa soluţiilor software ERP va ajunge la peste 50 miliarde dolari la finele anului 2011, în condiţiile în care, începând cu anul 2006 piaţa globală a crescut cu o rată anuală de 11%. Cu toate acestea, o creştere de 11% nu este considerată o creştere mare, dat fiind faptul că în trecut, înainte de 2006, piaţa ERP-urilor creştea cu o rată anuală de 18%. Vremea cheltuielilor (bugetelor) nebuneşti din anii ‘90 a apus. Chiar dacă nu mai sunt bugetele din anii ‘90, companiile cumpără în continuare sisteme ERP şi vor continua să cumpere şi în viitor. Probabil este corect să presupunem că veniturile viitoare din vânzarea soluţiilor ERP vor fi distribuite între diferitele tipuri de soluţii ERP. De exemplu, ERP-urile cloud-based şi SaaS vor lua o bucată din piața de 50 miliarde USD. Aceste noi tipuri de soluţii ERP ne vor propulsa în economia globală, permiţând acces facil web la sistem de către angajaţii situaţi în diferitele colţuri ale lumii. Instrumentele de colaborare vor deveni esenţiale pentru orice tip de business şi se vor integra cu sistemele ERP. Iar soluţiile ERP mobile vor deveni din ce în ce mai importante. Oricine doreşte să aibă acces la infomaţiile de business de oriunde s-ar afla în lume. O singură tendinţă sigur nu vom mai vedea în acest domeniu în perioada imediat următoare, şi anume boom-ul din anii ‘90. Astăzi, piaţa soluţiilor software ERP este aproape saturată. Mulţi furnizori mici au fost cumpăraţi de furnizori mai mari, iar o parte din ei au falimentat în perioada de criză/recesiune. Pe măsură ce economia globală îşi va reveni putem anticipa un viitor mai luminos pentru soluţiile ERP. 5

Piaţa românească de ERP este încă puţin dezvoltată, comparativ cu alte ţări din Europa Centrală (Cehia, Ungaria, Polonia) şi are o dimensiune de aproximativ 100 milioane Euro, din care 50% licenţe şi servicii. Tendinţele de pe piaţa globală se regăsesc şi pe piaţa românească, mai sensibilă la preţ faţă de alte pieţe. Un exemplu de process integrat In exemplul de mai jos este prezentat un flux simplificat de documente pentru un scenariu de aprovizionare (productie) la comanda (Make-to-order) din care se pot observa legăturile interdepartamentale, precum si elementele de control de flux. Exemplu de proces integrat, implementat prin intermediul unui sistem de tip ERP

În partea de sus din figură este reprezentată funcţia de vânzări, în care regăsim mai multe subprocese care țin de departamentul vânzări (contracte, oferte), departamentul logistică/comercial (comanda client, avizul și factura) și departamentul financiar (încasările).

6

În partea de jos este reprezentată funcția de cumpărări, în care regăsim subprocesele ce ţin de departamentul achiziţii (contracte furnizori), aprovizionare/comercial (comenzi furnizori, recepţii marfă), financiar-contabilitate (facturi şi plăţi). Vom vedea mai departe că două din scopurile (beneficiile) ERP-urilor sunt controlul şi optimizarea resurselor, iar pe exemplul de mai sus avem ca resurse stocurile şi banii, iar sistemul ERP trebuie să răspundă la două întrebări fundamentale:  când şi cât trebuie să aprovizionăm/producem astfel încât să livrăm la timp şi să nu avem suprastoc ?  când şi cât trebuie să plătim şi încasăm astfel încât să onorăm la timp obligaţiile şi să maximizăm surplusul de cash pentru investiţii ?

7

II. IMPLEMENTAREA SISTEMELOR ERP Ciclul de implementare a unei soluţii ERP1 conţine patru faze mari:  Determinarea necesităţii ERP  Selecţia furnizorului  Implementarea propriu-zisă  Îmbunătăţirea continuă (postimplementarea) Faza 1. DETERMINAREA NECESITĂŢII UNUI SISTEM ERP Are în atenţie urmărorele aspecte:  Necesitatea unui ERP  Costuri şi beneficii  Cerinţele Obs. Poate fi un sistem ERP la prima implementare, sau un proiect de upgrade sau extindere. Prima întrebare: De ce? Decizia de a achiziţiona sau nu un sistem ERP trebuie să fie rezultatul unui proces de evaluare strategică. Analiza trebuie axată pe procesele din firmă şi nu pe tehnologii. Procesele implică toată organizaţia, iar tehnologia apare ca un catalizator, oferind instrumente pentru valorificarea oportunităţilor. De aceea se spune că implementarea unui ERP determină schimbări organizaţionale. A doua întrebare: Cât costă? Metoda tradiţională de achiziţie a unui sistem ERP presupune luarea în calcul a următoarelor componente de cost, componente care formează costul total de deţinere (TCO = Total Cost of Ownership):  costul proiectului pilot  evaluarea între două soluţii finaliste  costul de achiziţie  infrastructura hardware: servere, reţelistică, staţii de lucru, dispozitive mobile  infrastructura software: licenţe pentru sistemele de operare (Windows, Linux, Unix), licenţe pentru baza de date (Oracle, Microsoft SQL Server, IBM DB2, Postgres SQL etc), licenţe software ERP (per module sau per sistem, per utilizatori nominali sau utilizatori concurenţi)  servicii de implementare: project management, consultanţă, instruire, asistenţă funcţională şi tehnică, dezvoltări şi adaptări  costul de mentenanţă: mentenanţa hardware, mentenanţa software (sisteme de operare, sisteme de baze de date, sistem ERP), servicii de suport de tip SLA (Service 1

Harwood S., ERP: The Implementation Cycle, Butterwood-Heinemann, Oxford, 2003, p.3.

8

Level Agreement): helpdesk şi rezolvarea incidentelor, asistenţă suplimentară, finetunning, optimizări, alte servicii extinse. Adunând toate aceste componente de cost rezultă un buget de ordinul zecilor/sutelor de mii de euro, în funcţie de dimensiunea şi complexitatea business-ului, adică un efort investiţional semnificativ. Evident tot acest efort trebuie pus în balanţă cu beneficiile anticipate şi realizate astfel încât randamentul investiţiei (ROI) să justifice achiziţia. Experţii apreciază că implementarea unui sistem ERP va costa până la 6 ori mai mult ca licenţele software. De exemplu, pentru 1 euro investit în software se cheltuiesc între 3 şi 6 euros pe partea de implementare. Se apreciază că bugetul unei implementări ERP reprezintă între 1 şi 3% din cifra de afaceri a organizaţiei. Ca tipologie există costuri iniţiale şi costuri continue. Structura acestor costuri este redată în tabelul:

Categoria de cost Directe Integrator

Indirecte

Hardware Software Analiză, configurare, testare, lansare, întreţinere Dezvoltare, customizare (personalizare) aplicaţii Instruire Personalul intern: management proiect, angajaţi, contracte temporare prestări servicii

Costuri iniţiale

Costuri continue (pe an)

5-10% 25-30% 20-25% 5-10% 5% 10%

Mentenanţă 15-25% 5%

Comentarii. Pentru a reduce acest efort investiţional iniţial au apărut diferite alte forme de achiziţie (vânzare) precum închirierea soluţiei (hardware, software, integral sau pe componente) sau utilizarea soluţiei ERP pe bază de abonament. Ultima tendinţă este migrarea sistemelor în Cloud, ceea ce face ca prin modelul bazat pe abonament, sistemele ERP să fie accesibile unui număr mult mai mare de organizaţii din spaţiul SMB (eng.) PME (fr.), adică organizaţiile mici şi medii.

9

MOTIVAREA INVESTIŢIEI. COSTURI ŞI BENEFICII. Dacă analizăm bugetele alocate pentru sistemele ERP apare automat întrebarea de ce managerii sunt dispuşi să cheltuie aceşti bani? (care sunt motivele şi beneficiile majore pe care un sistem ERP le aduce organizaţiilor).

Beneficiile implementării sistemelor ERP Răspunsul este simplu şi se traduce în patru cuvinte (în ordinea prioritizării de către manageri). 1. Control 2. Productivitate 3. Eficienţă (costuri reduse) 4. Informaţii Controlul se referă la mecanismele prin care se monitorizează şi urmăresc realizările faţă de obiectivele, ţintele propuse astfel încât incidentele de business să fie minimizate, chiar eliminate. Exemple de incidente de business pot fi: furturile, întârzierile în livrări, înregistrarea la timp a tuturor documentelor, auditul contabil (toate documentele sunt reflectate la timp şi corect în contabilitate), respectarea standardelor, procedurilor şi instrucţiunilor de lucru. Productivitatea este calea principală prin care se pot reduce costurile şi prespune ca ceea ce se execută să se facă mai repede şi fără erori, dacă se poate în mod automat. Automatizarea proceselor presupune eliberarea lor de resurse şi deci economii semnificative. Facturarea automată, contarea automată a mailurilor, tipăriri automate de rapoarte, mecanisme de generare documente reprezintă doar câteva exemple de automatizare. Eficienţa se obţine printr-o productivitate mai mare (automatizare) pe de o parte şi prin eliminarea piederilor. Eliminarea pierderilor se realizează prin optimizarea resurselor, optimizare care nu se poate face fără funcţia de planificare. În consecinţă, sistemul ERP se substituie actorilor umani în funcţiile de planificare/pregătire răspunzând la întrebările cât şi 10

când trebuie să produc, aprovizionez, plătesc. Concret, acest lucru se traduce în sistem prin mecanisme de generare a propunerilor de comandă către furnizori, către producţie şi a propunerilor de plată. Informaţii. Performanţa în management presupune luarea deciziilor la timp şi în cunoştinţă de cauză şi ca atare sistemul trebuie să furnizeze informaţii corecte şi la timp, pentru toate palierele şi funcţiile din organizaţie. Se analizează în continuare, în cazul unei firme de producţie, cele mai relevante beneficii care pot fi măsurate (beneficii cantitative):  Reducerea stocurilor. Practicile de planificare şi programare îmbunătăţite permit o reducere a nivelului stocurilor cu 20% sau chiar mai mult. Aceasta se reflectă în scăderea nivelului imobilizărilor (unde stocurile au o pondere destul de mare) şi determină economii la nivelul cheltuielilor asociate stocurilor (depozitare, manipulare, asigurare, perisabilităţi etc.).  Reducerea cheltuielilor materiale. Cele mai bune practici sunt implementate prin sistemul ERP şi la departamentul de aprovizionare. Aceasta permite negocierea unor preţuri mai bune şi o reducere a costurilor cu cel puţin 5%. Se realizează prin bazele de date create, care conţin informaţii utile despre furnizori legate de calitatea livrată şi respectarea termenelor de livrare. Prin integrarea în amonte a furnizorilor în sistemul ERP aceştia pot afla cererile viitoare, asigurând creşterea eficienţei şi posbilitatea de a oferi preţuri mai mici unor comenzi ferme.  Reducerea cheltuielilor cu forţa de muncă. Se apreciază că un sistem ERP poate conduce la o reducere a cheltuielilor cu forţa de muncă de 10%. Optimizarea fluxurilor de materii prime şi materiale elimină timpii morţi şi evită supraaglomerarea. Se poate stabili mai bine necesarul de forţă de muncă şi se poate realiza mai bine creşterea calităţii resurselor umane prin activităţi de training2.  Îmbunătăţirea vânzărilor şi a relaţiilor cu clienţii. Corelarea producţiei cu vânzările asigură îmbunătăţirea relaţiei cu clienţii. Sistemul ERP II integrează în aval clienţii prin CRM. Se permite astfel gestionarea eficientă a contactelor cu clienţii, scurtarea perioadei de la comandă la livrare, respectarea termenelor. Toate acestea conduc la creşterea satisfacţiei clienţilor şi implicit o creştere a vânzărilor, apreciată de analişti la cel puţin 10%.  Control mai bun asupra contabilităţii şi creanţelor. Fluxurile informaţionale şi procedurile definite permit o mai bună coordonare şi un control mai eficient a tuturor activităţilor din sistem. Prin introducerea o singură dată a datelor în sistem se reduc timpii de operare şi se minimizează erorile. Sistemul ERP asigură proceduri de colectare a creanţelor mai ferme. Se permite cunoaşterea în timp real a fluxului de trezorerie şi previzionarea acestuia. Se apreciază o reducere a termenului de încasare a creanţelor cu 15-20%.

2

Conceptul de training se referă la dezvoltarea abilităților și cunoștințelor individului necesare îndeplinirii mai eficace a unor sarcini sau a procesului de evoluție personală (https://ro.wikipedia.org/wiki/Training).

11

STUDIU DE CAZ: Calculul beneficiilor cuantificabile O firmă cu activitate de producţie are o cifră de afaceri de 25 milioane lei. Firma are solduri importante la conturile de stocuri şi creanţe/debitori. Partea de activ a balanţei de verificare, cu imobilizările este prezentată în tabelul următor: Economii determinate de sistemul ERP asupra imobilizărilor Valoarea curentă Denumire Îmbunătăţire (mii lei) A. Disponibilităţi băneşti 125 B. Debitori 500 18% C. Stocuri 750 20% D. Mijloace fixe 750 Total imobilizări (C+D-A) 1375 Total economii

Economii (mii lei) 90 150 240

Rezultă o reducere de 17.45% (240/1375) a valorii totale a imobilizărilor. Pentru a analiza cum se reflectă beneficiile ERP în contul de profit şi pierdere, trebuie avut în vedere veniturile şi cheltuielile aferente acestora. În general, pentru majoritatea firmelor de producţie, costurile reprezintă 70-75% din vânzări. Presupunem că beneficiile aduse de sistemul ERP influenţează valorile indicatorilor astfel:  Optimizarea activităţii de aprovizionare duce la reducerea cheltuielilor materiale cu 5%.  Creşterea productivităţii, optimizarea fluxurilor informaţionale şi reducerea/eliminarea prelucrărilor repetate conduce la reducerea cu 10% a cheltuielilor de personal.  Reducerea cheltuielilor administrative este asociată reducerii nivelului stocurilor (cheltuieli aferente stocării). Acestea au o pondere de aproximativ 25% din cheltuielile de stocuri. Rezultă că se realizează economii de 25% x 150.000 = 37.500 lei. Economii determinate de sistemul ERP asupra contului de profit şi pierderi Valoarea curentă Economii Denumire Îmbunătăţire (mii lei) (mii lei) A. Venituri din vânzări 2500 (*) 10% B. Cheltuieli materiale 1125 5% 56,25 C. Cheltuieli cu forţa de muncă 250 10% 25,00 D. Cheltuieli indirecte 50 Total cheltuieli 1 (B+C+D) 1425 E. Cheltuieli administrative 500 37,50 Total cheltuieli 2 (B+C+D+E) 1925 Profitul brut (A-(B+C+D+E)) 575 Total economii 118,75 (*) Creşterea de aproximativ 10% a veniturilor din vânzări nu o luăm în calcul, deşi aceasta va conduce la ridicarea nivelului profitului. Prin introducerea unui sistem ERP se obţine o economie totală: 240+118,75= 358,75 (mii lei). Dacă estimăm costurile sistemului ERP la 5% din cifra de afaceri a firmei rezultă 1250 (mii lei).

12

Aceasta presupune o recuperare totală a investiţiei în mai puţin de patru ani. Se remarcă o creştere a profitului de aproximativ 20% şi o creştere a cifrei de afaceri în următorii ani prin creşterea veniturilor (aceasta nu a mai fost luată în calcul). Beneficii necuantificabile (nonfinanciare)  Efecte asupra contabilităţii. Baza de date ERP asigură introducerea datelor o singură dată în sistem şi apoi utilizarea lor în toate aplicaţiile. Pe măsură ce tranzacţiile de producţie sunt înregistrate, echivalentele financiare sunt generate în mod automat, pentru a actualiza fişele conturilor. Se asigură astfel trasabilitatea de la documentul sursă la fişa contului. Informaţiile financiare sunt corecte şi actuale şi permit urmărirea cheltuielilor reale faţă de cele bugetate. Se micşorează timpul de realizare a procedurilor contabile obişnuite şi de închidere. Rapoartele financiare pot fi modificate prin configurări rapide, pentru a răspunde factorilor de decizie. Acces rapid şi controlat la informaţiile sensibile, în funcţie de competenţe, în baza drepturilor de acces. Creşterea eficienţei în muncă a angajaţilor prin verificări de consistenţă, numeroase optimizări şi automatizări şi prin generarea documentelor în vederea raportărilor periodice. 

Efecte asupra produsului şi procesului de producţie. Sistemul ERP oferă control total asupra produsului şi procesului de producţie prin bazele de date care conţin informaţii asupra produselor (nomenclatoare), structurii produselor, consumului tehnologic, liniilor de producţie, calităţii produselor etc. Se pot calcula rapid costurile de producţie în cazul unor schimbări tehnologice sau schimbări de materiale. Se pot realiza simulări ale costurilor de producţie pentru diferite situaţii. Sistemul ERP permite un control detaliat, cantitativ-valoric, al stocurilor de produse şi al operatiunilor comerciale derulate. Automatizarea procesului de generare a necesarului de aprovizionare în baza vânzărilor şi a necesarului de producţie, gestiunea furnizorilor şi a operaţiunilor de import.



Efecte asupra eficienţei operaţionale. Sistemul ERP permite o mai mare capacitate de adaptare şi o mai mare flexibilitate în relaţia cu clienţii şi furnizorii. Se pot realiza previziuni asupra evoluţiei pieţei şi analize pe cuburi OLAP care reprezintă un suport important în procesul decizional. Se micşorează timpul de livrare, se îmbunătăţesc activităţile postvânzare, cu rezultat direct în creşterea satisfacţiei clienţilor.

Concluzii Cu cât beneficiile sunt orientate spre viitor, cu atât creşte dificultatea de măsurare. Beneficiile importante nu rezultă neapărat din utilizarea efectivă a sistemului ERP, ci din transformarea organizaţională indusă de implementarea lui şi oportunităţile de valorificare create.

13

Se apreciază că 90% din costuri şi beneficii revin bunurilor intangibile, create prin investiţiile în software, educare şi transformări organizaţionale3. Valoarea unui sistem nu se regăseşte în tehnologia informaţională înglobată, ci în modul în care tehnologia este utilizată4.

DEFINIREA CERINŢELOR Scopul acestei activităţi este identificarea proceselor, descrierea lor şi a aspectelor cheie care trebuie urmărite. Rezultă o listă detaliată pentru fiecare proces analizat. În general se optează pentru o variantă de lucru mixtă în care să fie implicate persoane din firma beneficiară şi o firmă de consultanţă. Observaţie. Există multe situaţii practice în care definirea cerinţelor se realizează direct de către firma furnizoare de software în colaborare cu firma beneficiară. Teoretic, definirea cerinţelor conduce la realizarea caietului de sarcini, care va fi transmis potenţialelor firme furnizoare participante la licitaţie. Exemplificare: Caietul de sarcini Loteria Română, Caietul de sarcini Radiocomunicaţii.

Faza 2. SELECŢIA FURNIZORULUI Furnizorul care va fi selectat nu doar livrează plaforma, ci o implementează şi o personalizează pentru firma-client prin transferul de cunoştinţe şi expertiză către acesta. Relaţia cu furnizorul trebuie să fie una de lungă durată, de preferat pe toată durata de utilizare a aplicaţiilor. De aceea se spune că succesul unui proiect de sistem ERP depinde şi de alegerea furnizorului. Se consideră că există cinci moduri de a face selecţia5:  Alegere aleatoare – echipa de manageri nu ajunge la un consens; alegerea aleatoare rămâne singura posibilitate de luare a deciziei.  Alegere pe bază de cunoştinţe (persoane cunoscute) – nu e recomandată, deoarece relaţia cu furnizorul va fi una prietenoasă; este posibil ca aplicaţia aleasă să nu fie cea mai bună soluţie şi aceasta va influenţa succesul implementării.  Alegerea celei mai titrate soluţii – un singur criteriu de alegere nu asigură întotdeauna succesul.  Subcontractarea activităţii de implementare – evită responsabilitatea alegerii, dar costurile externalizării pot fi foarte mari.  Compararea şi evaluarea riguroasă a ofertelor primate – rămâne soluţia cea mai indicată.

3

Brynjolfsson E., Yang S., The intangible benefits and costs of computer investments: evidence from the financialmarkets, În Proceedings of the International Conference on Information Systems, Atlanta, SUA, 1997. 4 Remenyi D., The effective measurement and management of IT costs and benefits, Butterworh-Heinemann, Oxford, 2000. 5 Harwood S., ERP: The Implementation Cycle, Butterwood-Heinemann, Oxford, 2003, p.70.

14

În procesul de selecţie este importantă stabilirea echipei care va fi implicată în luarea deciziei. Câteva aspecte de luat în considerare sunt:  Cine sunt beneficiarii noului sistem? Cum pot fi implicaţi prin reprezentanţi în procesul de selecţie?  Specialiştii IT nu trebuie să predomine numeric, deoarece proiectul ERP este un proiect economic!  Manageri din toate ariile funcţionale trebuie să participe la selecţie.  O echipă prea mare poate îngreuna procesul.  Se poate include un consultant extern, dar acesta nu trebuie să aibă rol decizional.  Participarea managerului general poate adduce echilibru, cu condiţia obiectivităţii.  Echipa poate fi mai mare la început în etapa de definire a cerinţelor, iar apoi numărul membrilor poate fi redus. Etapele procesului de selecţie:  Prospectarea pieţei.  Crearea listei scurte de furnizori potenţiali.  Restrângerea listei.  Selecţia finală. Posibile criterii de evaluare pentru crearea listei scurte de furnizori potenţiali:  Prezenţa furnizorului pe piaţa din România.  Orientarea soluţiei ERP către domeniul de activitate al clientului.  Cerinţe funcţionale sau tehnice.  Experienţa - numărul de implementări din domeniul de activitate vizat.  Mărimea organizaţiei furnizorului (număr de angajaţi, cifra de afaceri).  Situaţia financiară a furnizorului.  Prima impresie… lăsată managerului din firma beneficiară. Restrângerea listei. Criterii de selecţie a furnizorului sistemului ERP:  Funcţionalitatea – este determinată de potrivirea dintre cerinţe şi soluţia furnizată la nivel de aplicaţii şi echipamente.  Metodologia de implementare – existenţa unei metodologii clare şi de calitate reduce riscul de eşec.  Costuri – evaluarea costurilor este indispensabilă pentru compararea cu bugetul disponibil.  Credibilitate – arată gradul de maturitate al firmei, deoarece parteneriatul cu firma furnizoare a sistemului ERP va fi pe termen lung.  Experinţa în domeniu – implementările anterioare (ca număr şi finalitate) în domeniul de activitate în discuţie înseamnă experinţă şi expertiză accumulate.  Suportul postimplementare – este importantă disponibilitatea şi experienţa.  Reputaţia – contribuie la obţinerea succesului.  Strategia furnizorului – viziunea, strategia acestuia pe termen mediu şi lung indică direcţiile viitoare de dezvoltare.

15

Selecţia finală. Se poate identifica un patrulater al selecţiei:  Latura 1. Funcţionalitatea. Se organizează la sediul beneficiarului sesiuni de prezentare şi demonstraţii funcţionale. Cu acest prilej se investighează aspecte legate de exploatarea aplicaţiilor: interfaţa grafică utilizator, conectivitatea BD (gestiunea tabelelor, interfaţa web, generator rapoarte, instrumente de analiză a datelor – OLAP), administrarea sistemului (platforma de baze de date, securitatea etc.). 

Latura 2. Implementarea. Metodologia de implementare are o abordare structurată? Eficienţa metodologiei de implementare depinde de furnizorul sistemului ERP.



Latura 3. Asistenţa. Este furnizorului este importantă în faza de inplementare, dar şi în etapa următoare de postimplementare.



Latura 4. Costurile. Normal ar fi să se caute soluţia care oferă cel mai mult pentru preţul plătit şi nu soluţia cea mai ieftină. Pentru a realiza comparaţia se introduce categorii clare de costuri: - costuri cu echipamentele; - costuri cu sistemul de operare; - costuri de licenţiere pentru SGBD; - costuri de licenţiere a modulelor; - costuri de licenţiere pentru alte aplicaţii; - costuri de integrare între modulele ERP a altor aplicaţii existente; - costuri de personalizare; - costuri de conversie a datelor din vechiul sistem; - costuri aferente managementului de proiect; - costuri de consultanţă; - costuri de instruire; - costuri de deplasare; - costuri de mentenanţă pentru primul an; Mai există şi costuri care apar postimplementare: - taxă fixă de mentenanţă; - costuri de consultanţă/instruire; - costuri de dezvoltare a unor cerinţe suplimentare. Alte aspecte de luat în considerare în procesul selecţiei finale:  credibilitatea şi reputaţia firmei furnizorului;  experienţa de implementare în domeniul de activitate al clientului;  strategia pe termen mediu-lung (reprezintă un reper important al viabilităţii furnizorului: dacă furnizorul are o viziune, direcţii de acţiune, expuse într-o strategie, dacă investeşte în cercetare – dezvoltare, dacă încheie parteneriate cu nume mari);  poziţia pe piaţă a firmei care dezvoltă ERP-ul;  intuiţia şi inspiraţia factorilor de decizie din firma beneficiară (dată şi de experienţa în afaceri, puterea de negociere).

16

Faza 3. IMPLEMENTAREA PROPRIU-ZISĂ Scenariul standard de implementare presupune parcurgerea a cinci etape majore, care se derulează după semnarea contractului: Project Setup, Analiza, Prototip & Build, Implementare, Go Live.

Etapele implementării unui sistem ERP

A. Project Setup Scopul acestei etape este acela de a identifica organizaţia clientului şi necesarul de resurse pentru o implementare de succes. Reprezentanţii beneficiarului şi ai furnizorului vor stabili împreună strategia şi termenii implementării, planificarea în timp, bugetul şi alocarea de resurse. Acestea se vor documenta într-un document de referinţă al proiectului care va fi folosit ca instrument de bază în procesul de urmărire a implementării.

17

Pe parcursul implementării vor avea loc întâlniri între reprezentanţii părţilor pentru a se evalua bunul mers al procesului şi vor fi întocmite rapoarte de evoluţie (status report) a proiectului de implementare în momente considerate cheie de ambele părţi şi/sau pe măsură ce se consumă un cuantum prestabilit din efortul bugetat iniţial. Implementarea se va desfăşura conform unui grafic sau calendar de implementare, care ţine cont de resursele implicate în proiect şi în această fază:  se stabileşte şi se consolidează echipa de proiect;  se stabilesc obiectivele pe fiecare etapă de implementare şi se agrează de ambele părţi (furnizor şi beneficiar); acestea se comunică echipei de proiect;  se stabileşte necesarul de resurse pentru buna implementare a proiectului;  se stabileşte planificarea cât mai detaliată în timp a activităţilor pe fiecare etapă şi resurse implicate;  se stabilesc şi se documentează rolurile şi responsabilităţile, matricea comunicării;  se formalizează data de start a proiectului, precum şi regulile “jocului” printr-un întâlnire. Tot în această primă fază, se organizează un training introductiv pentru echipa de proiect a beneficiarului - scopul fiind de a asigura nivelul ridicat şi omogen de cunoştinţe în ansamblul sistemului ERP care urmează să fie implementat, de către toată echipa de proiect. B. Analiza proceselor curente Scopul acestei etape este acela ca întreaga echipă de proiect să cunoască şi să înţeleagă în detaliu procesele curente de business din cadrul organizaţiei clientului, pentru a putea face setup-ul iniţial al sistemului. Ariile supusei analizei sunt:  Structura organizatorică.  Misiuni, probleme, obiective.  Procesele existente  Funcţia de Aprovizionare;  Funcţia de Vânzare;  Managementul Stocurilor şi al Depozitelor;  Funcţia de Producţie;  Trezorerie şi cache flow;  Managementul Proiectelor;  Managementul Serviciilor;  Managementul Parcului Auto;  Contabilitate şi costuri.  Bugete şi analize financiare;  Salarii şi HR;  Mijloace fixe;  CRM. Prin analize se identifică gradul de adaptare al proceselor la software sau al software-ului la procese, rezultând planul de dezvoltare software şi planul de schimbare în procese. 18

C. Prototip & Build Scopul acestei etape este acela de a obţine sistemul configurat corect astfel încât să răspundă la maxim cerinţelor de business rezultate din etapele A şi B, înainte de a fi dat în producţie. 



  

Se lucrează la diverse configuraţii şi setări ale sistemului:  Roluri şi utilizatori, alte elemente de securitate  Definiri contabilie (planuri conturi, taxe, conturi bancare, reguli contabile, termene de plată)  Definiri nomenclatoare: produse, terţi, gestiuni etc.  Definiri tipuri documente, reguli şi workflow  Traduceri şi terminologie specifică  Import de date istorice (iniţializări) Se identifică toate modificările necesare sistemului, acolo unde acesta nu răspunde sau nu s-au găsit variante alternative acceptabile şi se elaborează specificaţiile pentru dezvoltările necesare. Se fac teste, simulări şi demonstraţii pentru procesele stabilite în etapa B, pentru fiecare cerinţă de business agreată de către responsabilii proceselor respective. Se stabilesc toate ariile în care se preiau date istorice, forma acestora, responsabilii cu pregătirea acestora. Se reia trainingul echipei de proiect pe funcţionalităţi restrânse şi pe specificul de business al clientului; de data aceasta se decide cum se configurează sistemul.

Tot în această etapă se fac dezvoltările necesare şi agreate, pe baza specificaţiilor. Tot aici este inclus şi efortul pentru pregătirea formatelor de import de date istorice, testarea acestora. D. Pregătire finală şi training Este etapa în care pe baza sistemului prototip se fac următoarele:  Setarea sistemului în mediul de producţie.  Trainingul cu utilizatorii finali.  Documentarea procedurilor de lucru şi a instrucţiunilor de lucru.  Testul de integrare - reprezintă verificările de integrare cu terţe sisteme, dacă este cazul.  Testul de utilizare - reprezintă testele de acceptanţă din perspectiva utilizării sistemului de către utilizatorii finali.  Testul de stres - reprezintă testele de volum pentru a dovedi că sistemul va face faţă la volumul de date din mediul de producţie. E. GO Live Această ultimă etapă reprezintă pornirea sistemului în producţie. Se oferă asistenţă din partea echipei de proiect pentru utilizatori şi se validează primul set de rapoarte, conform obiectivelor agreate. Se stabileşte planul pentru cazurile de urgenţă, incidente neprevăzute şi se face trecerea în sistemul de suport intern şi extern. În final se se celebrează lansarea cu succes a sistemului.

19

Punerea în funcţiune a sistemului. Strategii şi tactici de implementare:  Implementarea directă: se renunţă la un moment dat la vechiul sistem şi se introduce noul sistem; strategia cea mai eficace, dar şi cea mai riscantă. Sistemul informatic va fi implementat într-un timp redus. Riscul apare din eventualele erori de proiectare, realizare şi securitate. 

Implementarea în paralel: funcţionarea concomitentă a vechiului sistem în paralel cu noul sistem; durata se stabileşte pentru a surprinde perioadele de vârf de activitate (încheiere de lună, semestru, an). În general durata de implementare în paralel nu trebuie să depăşească 3-4 luni. Avantaj: se poate verifica pe date reale funcţionarea noului sistem. Dezavantaj: necesită un volum important de muncă suplimentară.



Implementarea pilot: se alege o unitate reprezentativă pe care se face implementarea sistemului proiectat. După verificarea funcţionării corecte se trece la generalizarea implementării sistemului şi la celelalte unităţi din sistem. Sistemul trebuie parametrizat, rezultă o mai mare flexibilitate şi se dă posibilitatea extinderii asupra clasei tipologice alese. Avantaj: standardizarea sistemelor pentru clasele tipologice existente şi extinderea rapidă cu mici adaptări de la o unitate la alta. Dezavantaj: riscul strategiei – aprecierea greşită a reprezentantului clasei tipologice ca unitate pilot; rezultă cheltuieli şi întârzieri importante.

Implementarea poate fi realizată prin următoarele tactici:  implementarea simultană a tuturor aplicaţiilor sistemului;  implementarea în serie a aplicaţiilor. Alegerea strategiei şi tacticii de implementare Stabilirea strategiei se poate face ţinând cont de următoarele criterii:  gradul de pregătire profesională a utilizatorilor SI;  gradul de pregătire materială şi psihologică a beneficiarului;  natura şi complexitatea SI proiectat;  gradul de originalitate a SI;  gradul de participare a beneficiarului la realizarea SI;  volumul de date şi diversitatea surselor de producere a acestora;  gradul de satisfacere al cerinţelor de informare de către vechiul şi noul sistem Alegerea tacticii depinde de:  numărul de specialişti din partea beneficiarului disponibili;  gradul de pregătire al beneficiarului în vederea implementării; Jaloane orientative pentru alegerea strategiei de implementare:  Implementarea directă – recomandabilă pentru SI mai puţin complexe, cu grad de originalitate mai redus. Diferenţa dintre SI vechi şi SI nou este mai mare. Este indicată 20

pentru aplicaţii care nu necesită termene stricte de predare a lucrărilor şi este contraindicată pentru aplicaţii bancare, calculul salariilor etc. 

Implementarea în paralel – se recomandă pentru sistemele complexe cu grad sporit de originalitate, pentru aplicaţii cu termene severe. Paralelismul nu afectează desfăşurarea activităţii organizaţiei şi evită situaţiile de dezastru, datorate SI implementat.



Implementarea pilot – se recomandă în condiţiile existenţei unei clase tipologice cu un număr însemnat de unităţi reprezentate de unitatea pilot.

Comentariu Big Bang versus implementarea pe module În etapa de planificare a proiectului se analizează diferite strategii de implementare, în funcţie de priorităţile şi obiectivele de business, gradul de pregătire şi maturitate al organizaţiei, precum şi de buget. Complexitatea unei implementări este dependentă de dimensiunea organizaţiei, procesele şi funcţiile care se doresc a fi acoperite şi răspândirea geografică: mai multe sedii, depozite, magazine, unităţi organizaţionale. Nu există o formulă magică şi unică în favoarea unui scenariu sau a altui scenariu, cert este că o abordare de tip big-bang, totul deodată, necesită un buget mai mare şi faze mult mai lungi de pregătire. Abordarea etapizată, pe module/zone/obiective, oferă vizibilitate sporită beneficiarilor proiectului, şanse mai mari de încadrare în buget (el fiind defalcat pe subproiecte), cu un risc sporit în ceea ce priveşte completitudinea soluţiei şi finalizarea implementării pentru toate procesele/zonele. Comentariu Modificarea softului vs. modificarea proceselor O organizaţie care are de gând să implementeze un ERP fără a restructura operaţiunile nu face decât să cheltuie inutil nişte bani şi să atingă eventuale beneficii minore. Mai degrabă este o pierdere netă. Indiferent de cât de sofisticat este produsul software selectat (sistemul ERP), acesta nu poate îmbunătăţi semnificativ organizaţia doar prin utilizarea lui. În cel mai optimist scenariu, organizaţia se va îmbunătăţi marginal şi cu siguranţă, valoarea îmbunătăţirilor marginale nu se va apropia nici pe de parte de costurile semnificative ale unui proiect de implementare, consumator de resurse şi timp. Dacă o organizaţie nu se foloseşte de proiectul ERP ca de o oportunitate de a restructura business-ul, proiectul are toate şansele să fie îngropat în cimitirul ERP-urilor, împreună cu miile de alte eşecuri similare. Mai degrabă organizaţia ar trebui să folosească proiectul ERP ca un catalizator pentru schimbare. Este o scuză bună de a raţionaliza şi îmbunătăţi business-ul (procesele). Proiectul 21

ERP nu este un proiect software - este un proiect de restructurare, un proiect de schimbare organizaţională. Ar trebui să priviţi la proiectul ERP conform regulii 80/20: 80% din beneficii rezultă din îmbunătăţirile proceselor de business, 20% din software-ul ca atare. Este important să reţineţi aceste considerente operaţionale atunci când faceţi evaluarea propunerilor de implementare şi a furnizorilor ERP. Dacă de pildă vorbim de o organizaţie medie şi furnizorul propune o implementare cap-coadă în decurs de câteva luni, semnalele de alarmă ar trebui trase. Gândiţi-vă la următorul aspect. De cât timp organizaţia voastră ştie despre anumite procese de business “suboptimale” care lovesc în perfomanţa organizaţiei? Probabil de un timp destul de îndelungat. Cel mai probabil că organizaţia este anchilozată cu aceste procese “suboptimale” pentru că schimbarea lor este prea complexă şi descurajatoare. Deci, în acest context, chiar credeţi că un furnizor de soluţii poate să realizeze într-un interval scurt de 2-3 luni restructurarea proceselor de business, migrarea datelor, instruirea utilizatorilor asupra noilor procese şi a sistemului, implementarea noilor procese şi a sistemului şi să testeze totul fără cusur? Răspunsul este cel mai probabil, nu. Realizarea tuturor acestor sarcini presupune timp, îndemânare, muncă multă şi determinare. De cele mai multe ori (se pare că din ce în ce mai des) multe companii apelează la reimplementări sau proiecte de salvare. În cele mai multe cazuri, în implementarea iniţială, atenţia s-a acordat doar asupra software-ului şi sarcinilor legate de acesta precum: instalare, migrarea datelor, instruirea utilizatorilor strict legat de aplicaţie (ecrane, rapoarte etc.). În acest caz, furnizorul de soluţie nu a ajutat la restructurarea organizaţiei - care este componenta principală şi cheie a proiectului - şi nu s-a asigurat că utilizatorii au învăţat noul sistem, precum şi procesele de business (pe lângă alte probleme tipice care apar, inclusiv testarea şi migrarea datelor). Rezultatul final al acestei abordări simpliste (care nu implică restructurarea proceselor de business) este că organizaţiile ajung să utilizeze sistemul ERP fără ca acesta să fie perfect pliat pe modul lor de a face business. Şi, business-ul are în continuare aceleaşi probleme operaţionale pe care le-a avut şi înainte de implementare. Singura diferenţă este că acum au un sistem software la modă care scoate rapoarte financiare şi recomandări operaţionale, mai mult sau mai puţin semnificative. Până la urmă, nu există implementarea miraculoasă. Nu există scurtături secrete. Implementarea cu succes a unui ERP înseamnă integrarea cu succes a sistemului ERP într-un mediu de business optimizat.

22

În faza de implementare se înregistrează în general mai multe “greşeli” generate în principal de:  depăşirea timpului alocat fazei de implementare;  depăşiri semnificative ale bugetelor stabilite;  probleme operaţionale la startul productiv din cauza instruirii insuficiente;  neobţinerea beneficiilor aşteptate;  mulţi beneficiari nu cunosc exact beneficiile pe care le vor obţine după implementare. Demonstrarea eşecului este mai simplă decât a succesului. Evitarea eşecului este mai uşoară decât dobândirea succesului. Ambele acţiuni au în comun factorul uman. S-a constatat că multe din motivele asociate cu insuccesul unui proiect ERP sunt legate sau depind de oameni:  top-managerii – nu sunt prezenţi, nu înţeleg sau nu se implică;  utilizatorii nu sunt educaţi şi motivaţi, deci nu se implică;  managerul de proiect nu are experienţă;  managerul de proiect nu are cunoştinţele necesare conducerii proiectului;  managerul financiar nu înţelege de ce să suplimenteze bugetul; preferă să taie din cheltuielile de instruire;  echipa proiectului nu include persoane potrivite;  comunicare defectuoasă în echipa de proiect (între oamenii beneficiarului şi cei ai furnizorului);  instruirea insuficientă a utilizatorilor finali;  consultanţi neexperimentaţi;  pierderea de personal calificat (analişti, programatori) la furnizor;  echipa furnizorului grăbeşte termenele pentru încasarea mai rapidă a tranşelor;  conducere slabă a proiectului din partea beneficiarului, prin alegerea unui manager de proiect slab, ezitant, inflenţabil. Toate aceste probleme sunt rezultatul unei slabe culturi organizaţionale, fragilă la schimbare. Există culturi organizaţionale care favorizează schimbările bazate pe tehnologiile informaţionale, dar există şi culturi care le frânează ori chiar le resping. FACTORI DE SUCCES ÎN IMPLEMENTAREA UNUI ERP Provocările clasice care apar pe parcursul unui proiect de implementare sunt:  Implicarea managementului - orice proiect ERP fără participarea activă a managementului este sortit unui eşec garantat. Managerii sunt cei care au puterea de a aloca resursele atunci când trebuie, de a motiva oamenii pentru a accepta schimbara şi de a valida soluţiile de business conform cu cerinţele exprimate, implcit sau explicit. 

Comunicarea si Change Management - 90% din eşecurile proiectelor ERP se datoreză comunicării. Comunicarea în interioriul organizaţiei pentru pregătirea angajaţilor pentru schimbare este critică şi trebuie gestionată pe tot parcursul proiectului de către reprezentantul beneficiarului care îşi asumă rolul de project manager intern. La fel de critică este şi comunicarea externă, între furnizorul soluţiei şi beneficiarul ei, pe toate nivelurile - project manageri, consultanţi şi utilizatori, stakeholderi. 23



Atingerea obiectivelor - presupune definirea lor în mod realist, concret şi încadreare corectă într-un orizont de timp în care toate resursele pot fi aliniate şi calibrate în mod corespunzător.



Incadrarea în buget - este condiţia care se presupune apriori că trebuie respectată, dar care de cele mai multe ori nu este respectată (post-factum - de cele mai multe ori). Cauzele sunt de cele mai multe ori legate de punctele de mai sus: obiective şi aşteptări nerealiste, comunicare defectuoasă şi lipsa de implicare.

Mai jos sunt prezentate problemele principale cu care se confruntă multe proiecte de implementare şi câteva sfaturi prin care se pot preveni/elimina aceste probleme. PROBLEME ÎN IMPLEMENTAREA ERP-urilor Sunt binecunoscute sutele de poveşti de groază referitoare la greutăţile întâmpinate în implementarea sistemelor ERP şi ca orice veste proastă, acestea sunt adesea exagerate pentru a garanta efectul dramatic asupra auditoriului. Vestea bună? Abordarea implementării din perspectiva de “a face simplu”, pare a fi cel mai bun sfat care poate fi dat cuiva care este gata să se implice într-un proiect de implementare ERP. Nimănui nu-i place să vorbească (sau să scrie) despre greşeli, aşa că mai jos sunt câteva explicaţii cu privire la ceea ce trebuie să facă o companie pentru a evita primele cele mai importante greşeli comune. Greşeala Nr. 1: Clientul nu reuşeşte să îi facă pe consultanţii de implementare sa înţeleagă business-ul pe deplin Organizaţia-client cunoaşte business-ul în detaliu pentru că zilnic oamenii lucrează şi iar lucrează, fără să se gândească la ontologia ei. Pe de altă parte, consultanţii de implementare nu cunosc business-ul aşa de bine, de aceea este important de a planifica timp pentru a aduce consultanţii la nivelul de cunoaştere din interiorul organizaţiei. Evident, aceasta se aplică la procese, politici si proceduri, însă cele mai multe organizaţii greşesc în includerea oamenilor şi a culturii în întreg peisajul şi câteodată consecinţa este că a avem consultanţi cu aptitudini tehnice corecte, dar cu comportamente greşite. Merită efortul de a fi siguri că angajaţii şi consultanţii se înţeleg intre ei. Ca şi clienţi în procesul de implementare, trebuie să ne asigurăm că implementatorii din firmă sunt cu noi pe întreaga durată a proiectului. Investim timp în educarea consultanţilor în spiritul business-ului, iar ultimul lucru de care avem nevoie este (ei facând parte dintr-o echipă) să ne confruntăm cu situaţia in care să explicăm totul din nou următorului consultant care ne bate la uşă. Sfat  Responsabilizarea furnizorului de sistem pentru continuitatea consultanţilor de proiect şi dacă e necesar, se poate face din acest lucru o obligaţie contractuală cu penalităţi financiare de fiecare dată când trebuie re-educat sau re-orientat un consultant nou.

24

Greşeala Nr. 2: Lipsa reperelor realiste şi dese pe tot parcursul proiectului implementării. Proiectul de implementare poate dura de la 3-6 luni la peste un an şi va avea impact asupra celor 4 domenii (oameni, procese, politici şi obiective). Astfel, în dezvoltarea planului de implementare va trebui să avem întotdeauna capacitatea să răspundem la trei întrebări critice: 1. Unde ne găsim? 2. Am ajuns deja? 3. Cum ştim cu siguranţă că am ajuns acolo? Stabilind repere în mod frecvent în momentele cheie de-a lungul perioadei în care se desfăşoară proiectul, vom reuşi să cuantificăm progresul şi mai important să sărbătorim reuşita împreună cu întreaga echipă, pe măsură ce proiectul avansează la timp şi conform bugetului. Cu siguranţă, se pot face ajustări dacă din orice motiv apărut, proiectul nu se desfăşoară conform planului. Un lucru important de amintit în ceea ce priveşte stabilirea acestor repere este principiul KISS (Keep It Simple, Stupid sau Keep It Straight Simple sau Keep It Short and Simple): să fim siguri că reperele alese sunt mai bune şi uşor de cuantificat. Astfel, echipa proiectului si angajaţii vor vedea progresul şi vor avea moralul ridicat, chiar şi in timpul etapelor dificile ale proiectului. Sfat  Dacă nu se stabilesc repere simple şi realiste, atunci procesul de evaluare (măsurare) va fi similar cu trasarea cursului unei nave după urma lăsată pe luciul apei.

Greşeala Nr. 3: Lipsa oamenilor dedicaţi şi de înaltă calitate în echipa de implementare şi lipsa unei soluţii de backup. Este o realitate dureroasă că oamenii de care într-adevăr avem nevoie pentru implementare sunt fără îndoială cei mai buni oameni din organizaţie şi este aproape garantat că aceştia sunt şi cei mai ocupaţi. Cel mai bun lucru pe care îl putem face este să găsim modalităţi prin care să delegăm anumite îndatoriri ale acestora către implementatorii juniori, pentru a-şi putea focaliza întreaga experienţa asupra proiectului. Mai mult, acordând şansa implementatorilor juniori de a-şi dovedi calităţile la nivel mai ridicat, se poate câştiga o gama variată de abilităţi pentru afacere şi se pot identifica şi potenţiale promovări în acelaşi timp. Un lucru este sigur, atât juniorii cât şi seniorii vor avea de învăţat din experienţe şi vor fi o investiţie mai valoroasă pentru organizaţie în viitor. Managerii trebuie să fie gata să-i recompenseze pentru eforturile susţinute şi pentru noile aptitudini dezvoltate. Sunt multe feluri de a recompensa participanţii la proiect, de la fişa postului refăcută şi încadrarea în altă grilă de salarizare, la asigurări în cuantum ridicat, însă pe departe, cea mai eficientă este bonusul neaşteptat. De exemplu, pentru o renumită companie farmaceutică europeană aceasta înseamnă acordarea unei sume de bani ca bonus pentru fiecare eveniment major ca etapă în cadrul proiectului precum şi sărbătorirea fiecărui succes în mod public, o călduroasă apreciere la sfârşitul proiectului, însoţită de un week-end prelungit (o extensie a concediului anual normal), astfel încât fiecare a simţit că este apreciat pentru eforturile sale.

25

Sfat  Ca viziune asupra întregului proiect şi în legătură cu costul proiectului, bonusul adiţional şi recunoaşterea publică vor aduce venituri multă vreme după realizarea proiectului, iar în termeni de ROI – rentabilitate a investiţiei (Return on Investment), rezultatele sunt inestimabile.  Bonus-ul trebuie să fie o surpriză, care l-a determinat pe cel care a primit-o să fie mândru că face parte din echipă şi că este respectat pentru munca susţinută pe care a depus-o în cadrul proiectului.

Greşeala Nr. 4: Inexistența unui buget corespunzător pentru training-ul utilizatorilor în noul sistem În majoritatea organizaţiilor modul de abordare a implementării dă greş din cauza bugetului alocat şi a timpului destinat training-ului, iar rezultatul final este că asimilarea noului sistem, a proceselor şi a politicilor este anevoioasă, iar obţinerea beneficiului scontat este decalat în timp. O regulă de aur este asigurarea unor provizioane pentru bugetul de training, care trebuie dublat faţă de propunerea furnizorilor, care se bazează pe un scenariu ideal în care utilizatorii nu se îmbolnăvesc, nu se schimbă şi sunt elevi silitori. Sfat  Revizuirea bugetului de implementare şi acordarea unei atenţii deosebite training-ului, al cărui buget trebuie dublat.

Greşeala Nr. 5: Modificarea sistemului standard fără a cântări cu mare atenţie atât beneficiile cât şi riscurile. Există o tendinţă în multe organizaţii de a modifica repede sistemul în zone în care nu se potrivesc proceselor actuale ale business-ului (afacerii), iar rezultatul final este un sistem în care viitoarele actualizări devin extrem de dificil de aplicat şi orice suport help-desk intern, va fi compromis, deoarece help-desk-ul trebuie să afle despre modificările făcute, înainte ca să poată fi de ajutor. Astfel, abordarea plecand de la “Cele trei reguli” este una adoptată de mulți directori generali înţelepți: 1. Dacă ținem cont de această cerinţă, care este beneficiul măsurabil dovedit? 2. Am analizat toate alternativele şi riscurile/beneficiile lor înainte de a alege să modificăm? 3. Dacă nu suntem pionieri în acest domeniu, am văzut ce au făcut alte companii în această zonă, pentru a ne folosi ca lecţie din care să învăţăm? Sfat  Păstrează “Cele trei reguli” ca parte integrantă a deciziei asupra oricărei devieri de la planul de proiect stabilit.

26



Ţine legătura cu alte companii din domeniu care au experimentat acest lucru şi învaţă din experienţa lor.

Notă: Într-o organizaţie directorul general a invitat oameni cheie din altă companie să participe la întâlnirile lor de stabilire a strategiei. Scopul a fost ca persoanele invitate să-şi împărtăşească experienţa şi cunoştinţele, dar ce este de semnalat, ei nu erau constrânşi (limitaţi) de politica internă a firmei, astfel încât ei aveau libertatea să pună întrebări pe care toţi doreau să le pună, dar din diferite motive nu puteau. Greşeala Nr. 6: Greşeala de a nu proteja şi a nu garanta părţile critice ale afacerii. Un exemplu de situație de acest tip ni-l oferă directorul unei firme mari de produse farmaceutice din Paris, care este pe punctul de a semna un contract pentru sisteme noi; înainte de a semna, solicită trei garanţii de la distribuitorul de software: 1. O garanţie că niciodată, dar niciodată, nu va fi pus în situaţia de nu putea să ia comenzi de la clienţii săi. 2. O garanţie că noul sistem nu-l va împiedica niciodată în expedierea comenzilor către clienţi de la depozitul său. 3. O garanţie că noul sistem nu-l va pune niciodată, dar niciodată, în situaţia în care să nu poată accepta plăţile clienţilor săi şi să le transfere banii în contul său bancar. Cererile sale au fost directe - comercializarea produselor, distribuirea lor către clienţi, precum şi plata pentru ele. Acestea erau chiar esenţa afacerii sale şi dorea sisteme care să-i garanteze aceste lucruri, să se asigure că are acoperire la orice eveniment neprevăzut, referitor la căderea sistemului. Deasemenea, a specificat că se putea deţine controlul în alte zone care nu sunt critice cu ajutorul proceselor alternative, timp de cel putin 12-24 de ore, fără întreruperi majore. Sfat  Lecţia care trebuie învăţată - analizează afacerea ta cu atenţie şi depistează aspectele critice, de care ai nevoie, să fie disponibile 24/24 de ore 7/7 zile pe saptămână si apoi ia legatura cu furnizorul de hard şi soft să te asiguri că ei au posibilitatea să-ţi asigure opţiuni de backup, să pastreze totul în funcţiune. Chiar având atâtea exemple catastrofale despre companii care falimentează datorită implementărilor de software nereuşite, multe companii încă nu acordă atenţia cuvenită implicaţiei riscurilor. Planificarea şi pregătirea adecvată este necesară pentru a ajuta la identificarea şi gestionarea potenţialelor riscuri. Un bun consultant de implementare poate ajuta la revizuirea practicilor curente de business, a ţintelor, a riscurilor şi poate să articuleze un plan de implementare solid. Unul dintre cele mai importante lucruri care trebuie facute înainte de a începe proiectul este selecția pachetului software şi a furnizorului. Un sistem ERP este o investiţie de durată, astfel încât alegerea furnizorului care se potriveşte cerinţelor afacerii cu care să se poată dezvolta un parteneriat pentru următorii 5-10 ani, este esenţială. Cu o cercetare şi o planificare amanunţită se pot evita cele şase greşeli de mai sus. 27

METRICI DE SUCCES ALE UNEI IMPLEMENTĂRI Pentru a putea măsura succesul unei implementări, trebuie definite câteva metrici sau indicatori de performanţă, derivate din obiectivele de business şi obiectivele proiectului. Aceşti indicatori se măsoară înainte de a începe implementarea, prin realizarea unui diagnostic iniţial şi după finalizarea implementării, precum şi la anumite intervale de timp de la finalizarea implementării (de exemplu la fiecare 6 luni). Îmbunătăţirea constantă a acestor indicatori indică succesul implemntării şi poate sta la calcului realist al randamentului investiţiei (ROI). Exemple de indicatori sunt:  volumul stocului (măsurat în zile)  timpul de livrare  rata de servire client  profitul şi cifra de afaceri  numărul de documente procesate  numărul de incidente/erori înregistrate  volumul pierderilor, etc. IMPLEMENTAREA ERP ŞI CHANGE MANAGEMENT Rezistenţa la schimbare Implementarea unui sistem ERP presupune o schimbare majoră în organizaţie, schimbare în modul de lucru, procesele de business şi interacţiunile umane. Şi ca orice schimbare, ea întâmpină rezistenţă, din partea utilizatorilor şi/sau a managerilor. Promotorul proiectului ERP nu este întotdeauna întregul consiliu director. Sunt manageri care își văd periclitată poziţia prin adoptarea unui nou sistem ERP, sau sunt persoane cărora le este pur şi simplu frică de nou şi de schimbare. Managementul schimbării în acest context înseamnă două variante “change people or change people”, cu alte cuvinte fie se schimbă mentalitatea oamenilor şi ei sunt dispuşi şi capabili să adopte noul sistem, fie se schimbă oamenii cu alţi oameni. În tot acest demers de schimbare este aşadar esenţială implicarea managementului în toate fazele proiectului. Managemenul poate angaja consultanţi externi specializaţi în proiecte de managementul schimbării, aşa cum prin definiţie este şi un proiect de implementare ERP. Managementul obiectivelor pe termen lung Este de reţinut că implementarea unui sistem ERP este un proces continuu. Sistemul ERP trebuie să fie acordat în permanenţă cu schimbările din organizaţie, schimbări care sunt inevitabile şi sunt din ce în ce mai dese şi mai rapide, în acest secol XXI. Aşadar miza noilor sisteme ERP este flexibilitatea şi capabilitatea de adaptare la situaţii şi scenarii noi de business. ERP-ul este acel partener în organizaţie care susţine procesele de afaceri şi un sistem ERP performant răspunde la obiectivele pe termen lung şi la nevoia crescândă de agilitate organizaţională.

28

Faza 4. ÎMBUNĂTĂŢIREA CONTINUĂ (POSTIMPLEMENTAREA) Un proiect ERP nu este o destinaţie, ci o călătorie. Organizaţia este un sistem dinamic, în continuă adaptare şi schimbare, de aceea, practic, implementarea sistemului integrat nu se opreşte niciodată. Cauze: beneficiile anticipate nu sunt realizate, unele procese nu se ridică la nivelul aşteptat, unele procese funcţionale pot fi optimizate etc. Rezultă un program de îmbunătăţire continuă, care poate conduce şi la înlocuirea sistemului ERP existent cu un sistem nou, atunci când se decide că upgrade-urile nu mai pot ajuta.

Întrebări 1. Care este importanța utilizării sistemelor informatice integrate în cadrul companiilor moderne? 2. Care sunt principalele motive de introducere a sistemelor de tip ERP? Din experiență, care ar fi cele mai importante, și care ar fi cele mai puțin importante? 3. Care sunt principalii factori de succes în implementarea sistemelor informatice integrate?

Bibliografie 1. Managementul strategic al tehnologiei informaţiei. Suport de curs realizat în cadrul proiectului POSDRU /86/1.2/S/61086, cu titlul Dezvoltare, inovare şi extindere a accesului la învăţare în programe de master în administrarea afacerilor. 2. Hurbean L., Fotache D., Păvăloaia V.D., Dospinescu O., Platforme integrate pentru afaceri – ERP, Editura Economică, Bucureşti, 2013.

29

Studiul 1. Sistemele informatice şi procesele de afaceri. Adaptarea aplicaţiilor informatice la procesele de lucru sau schimbarea modului de lucru?6 Orice implementare majoră a unui sistem informatic care cuprinde aplicaţii software pentru automatizarea proceselor de lucru trece printr-o etapă de analiză, în cadrul căreia se analizează modul de lucru al organizaţiei în scopul configurării aplicaţiilor software la specificul respectivei organizaţii. Din punctul de vedere al modului în care se realizează analiza proceselor de lucru, se pot diferenţia două abordări care depind de tipul aplicaţiilor software care se implementează: 1. Implementarea unor aplicaţii COTS “Commercial Off The Shelf” (Comercial de pe raft) 2. Implementarea unor aplicaţii dezvoltate la cerere. 1. Implementarea unor aplicaţii COTS. În cazul implementării unor aplicaţii standard (COTS), etapa de analiză are rolul de a identifica acele informaţii specifice organizaţiei, care sunt necesare în vederea configurării aplicaţiei software. Atunci când implementează o aplicaţiei software COTS, beneficiarul urmăreşte, de obicei, nu numai reducerea costului, a riscului şi a costului implementării prin utilizarea unei aplicaţii software a cărei utilizare în organizaţii similare a fost demonstrată cu succes în trecut. Un alt obiectiv subsidiar al apelării la o aplicaţie software de tip COTS este, în multe cazuri, faptul că aceste aplicaţii încorporează bune practici ale industriei pentru care sunt dezvoltate, iar organizaţiile care implementează astfel de aplicaţii beneficiază implicit şi de aceste bune practici. În cazul implementării unui produs COTS, etapa de analiză este, de asemenea, o ocazie pentru a depista eventualele diferenţe între modul de lucru specific organizaţiei care doreşte implementarea aplicaţiei COTS şi fluxul de lucru al aplicaţiei. În cazul în care astfel de diferenţe sunt identificate, o decizie este necesară cu privire la modul în care implementarea va continua: organizaţia îşi va păstra modul de lucru actual, şi atunci este necesară modificarea aplicaţiei software pentru a modela un proces de lucru diferit faţă de cel standard, sau organizaţia îşi va schimba modul de lucru şi va adopta noul proces de lucru pe care aplicaţia îl modelează. Fiecare dintre aceste opţiuni prezintă atât avantaje cât şi dezavantaje, iar decizia finală trebuie luată în fiecare caz în parte pe baza unei analize relative a avantajelor şi a dezavantajelor. Este foarte important ca reprezentanţi ai utilizatorilor să fie implicaţi în această decizie. Am văzut multe proiecte a căror implementare este coordonată de reprezentanţi ai organizaţiei IT, care eşuează în luarea unor decizii strategice cu privire la schimbarea modului de lucru odată cu implementarea unor sisteme informatice, considerând că procesele de lucru ale utilizatorilor sunt primordiale, iar aplicaţiile informatice trebuie să le modeleze exact. 6

Cătălin Hristea , http://www.marketwatch.ro/articol/10311/Sistemele_informatice_si_procesele_de_afaceri _Adaptarea_aplicatiilor_informatice_la_procesele_de_lucru_sau_schimbarea_modului_de_lucru/

30

În multe situaţii această abordare este însă una greşită, deoarece multe organizaţii operează cu procese de lucru “moştenite”, care nu au fost optimizate, iar simpla automatizare a acestora prin informatizare nu face decât să automatizeze ineficienţa. Un alt caz care poate însă complica situaţia descrisă mai sus este cel în care beneficiarul nu alege cu bună ştiinţă o aplicaţie de tip COTS, ci aceasta îi este oferită de către un furnizor ca răspuns la o serie de specificaţii documentate într-un caiet de sarcini. Într-o astfel de situaţie, aşteptarea beneficiarului este aceea că va beneficia de o aplicaţie software care să îi modeleze întocmai procesele de lucru, în timp ce furnizorul are constrângerea lucrului cu o aplicaţie care poate fi configurată, dar nu neapărat rescrisă. Exiată multe situaţii în care o astfel de diferenţă de abordare a provocat conflicte în cadrul echipei comune de implementare, iar finalizarea proiectului s-a făcut cu întârzieri mari şi cu concesii importante din partea ambelor părţi. Observaţie. O practică frecventă pe piaţa românească de ERP sunt add-on-urile. Se menţine soluţia ERP la nivelul de bază şi se adaptează la specificul diferitelor domenii de activitate prin add-on-uri. Acestea sunt concret module construite pe platforma pusă la dispoziţie de ERP şi care se integrează pe această platformă. Add-on-urile sunt dezvoltate de firmele partenere producătorului sistemului ERP, care se ocupă şi de implementarea soluţiei în ansamblu. 2. Implementarea unor aplicaţii dezvoltate la cerere În cazul implementării unor aplicaţii dezvoltate la cerere, etapa de analiză este una semnificativ mai complexă şi de mai lungă durată decât cea necesară pentru configurarea unui produs COTS. În cadrul unei astfel de analize, echipa furnizorului trebuie să înţeleagă şi să documenteze toţi paşii proceselor de lucru pe care noile aplicaţii le vor modela, toţi actorii implicaţi, regulile de business aplicabile (precum şi excepţiile). Executarea corectă şi completă a acestei etape este fundamentală, întrucât noua aplicaţie va fi construită exclusiv pe baza informaţiilor acumulate şi documentate în cadrul analizei. În cazul în care este realizată corect, o astfel de analiză poate fi însă extrem de utilă şi din perspectiva identificării acelor procese de lucru care pot fi optimizate, atât prin eficientizare, cât şi prin informatizare. Odată identificate aceste oportunităţi de optimizare, procesul propriu-zis de modificare a proceselor de lucru trebuie gestionat cu atenţie în cadrul unui sub-proiect de business re-engineering, iar introducerea noilor procese optimizate trebuie însoţită de activităţi de management al schimbării. Pentru a avea succes, o astfel de iniţiativă trebuie susţinută la nivel managerial de către organizaţia beneficiară, deoarece, în caz contrar, rezistenţa la schimbare a utilizatorilor va fi mai mare decât influenţa pe care echipa tehnică de implementare o poate avea. Pentru a evita însă apariţia unei rezistenţe majore faţă de noul sistem informatic, este bine ca furnizorul să evite modificarea cu orice preţ a modului de lucru al beneficiarului odată cu

31

implementarea unui nou sistem informatic, deoarece gestionarea simultană a două schimbări (schimbarea modului de lucru şi introducerea unui nou sistem informatic) poate fi mai mult decât un utilizator mediu poate realiza cu succes. Am asistat la proiecte majore de informatizare al căror obiectiv a fost “deturnat” datorită faptului că furnizorul şi-a propus o analiză exhaustivă a întregului mod de lucru al organizaţiei beneficiare şi o optimizare a proceselor odată cu dezvoltarea şi implementarea noului sistem informatic. Acest demers s-a dovedit a fi unul păgubos, deoarece echipele de analiză au fost copleşite de complexitatea proceselor de lucru ale beneficiarului, timpul necesar absorbţiei corecte a tuturor informaţiilor în vederea identificării unui mod optim de lucru a fost foarte lung şi a dus la prelungirea excesivă a etapelor de analiză şi de proiectare, iar timpul rămas pentru dezvoltare şi implementare a devenit insuficient. În plus, implicarea viitorilor utilizatori nu a fost suficientă, iar echipa de proiect a beneficiarului (formată preponderent din personal IT) nu a găsit pârghiile necesare pentru a “forţa” luarea unor decizii care afectau modul de lucru. Consultanţa BPR (Business Process Re-engineering) O abordare care a dat rezultate foarte bune, mai ales în cazul unor proiecte de anvergură, este aceea ca implementarea unui nou sistem de aplicaţii software să fie precedată de un proiect de consultanţă care să îşi propună exclusiv analiza proceselor de lucru existente, documentarea acestora şi identificarea potenţialului de optimizare a acestor procese (Business Process Reengineering). O astfel de abordare este indicată deoarece o firmă de consultanţă specializată în analiza proceselor de afaceri poate furniza un serviciu de analiză mai eficient şi mai bine structurat decât o firmă a cărei specializare constă în dezvoltarea aplicaţiilor informatice, având în plus şi avantajul unei obiectivităţi crescute, neinfluenţată de eventuale restricţii tehnologice. De asemenea, un astfel de proiect de consultanţă este perceput ca fiind unul “de business”, şi nu unul IT, astfel încât implicarea nivelelor manageriale de decizie este mai mare decât în cazul unui proiect care are ca finalitate o soluţie tehnică şi care este, în cele mai multe situaţii, catalogat ca fiind unul IT, fiind astfel delegat spre implementare compartimentului IT al organizaţiei beneficiare. Un alt beneficiu al unei astfel de abordări constă în faptul că descrierea proceselor care vor trebui automatizate poate fi prezentată potenţialilor furnizori de servicii de dezvoltare software ca parte a documentaţiei de atribuire a contractului de dezvoltare a aplicaţiei software, astfel încât aceştia să poată realiza o evaluare corectă a efortului de dezvol-tare necesar pentru finalizarea proiectului. Se evită astfel problemele care apar des în cadrul proiectelor de implementare a sistemelor de aplicaţii informatice datorită slabei documentări a cerinţelor în cadrul documentaţiei de atribuire şi a diferenţelor mari între ceea ce s-a solicitat şi ceea ce trebuie de fapt implementat, diferenţe care sunt sesizate însă doar după demararea proiectului şi care, în cele mai multe cazuri, duc la dispute între partenerii de implementare.

32

Studiul 2. Implementarea ERP – un succes accidental?7 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 studiu î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 7

Remus Cazacu, http://blog.bitsoftware.eu/bitsoftware-ro/ro/blog/implementarea-erp-un-succes-accidental/

33

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. Concluzia 1. 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.

34

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: 1. 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. 2. 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. 3. 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. Concluzia finală. 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. Sumar Sistemele informatice integrate de tip ERP au devenit omniprezente în cadrul organizațiilor, și vor deveni din ce în ce mai importante pentru activitatea acestora în viitor. Managementul și dezvoltarea lor reprezintă componente esențiale ale performanței organizaționale, datorită faptului că ele reprezintă coloana vertebrală a organizației moderne din punct de vedere informațional. Fenomenul ERP a luat amploare în anii 80. Aproape peste noapte, majoritatea companiilor importante din economiile dezvoltate s-au grăbit să implementeze sisteme de tip ERP, pentru a înlocui sistemele informaționale vechi, greu de întreținut, care amenințau să le afecteze buna funcționare. Companiile se temeau că aceste sisteme vechi le-ar face mai puțin competitive în fața unor producători cu costuri reduse, cum ar fi cei din Asia. Sistemele de tip ERP au fost percepute ca un panaceu universal, care va rezolva odată pentru totdeauna problema reconfigurării și optimizării proceselor organizaționale interne. În anii ‘90, companiile au avut de-a face cu provocarea de a reduce timpul de dezvoltare a produselor, de a crește calitatea acestora, în timp ce reduc costurile de producție și scad timpul de livrare către client. Aceste deziderate nu mai puteau fi atinse prin schimbări locale (la nivel 35

de departament sau divizie funcțională) – complexitatea provocărilor pe care trebuie să le depășească compania modernă necesită strângerea legăturilor și interdependențelor dintre diverse procese de afaceri, de la finanțe la distribuție. Odată cu apariția comerțului electronic, companiile trebuie să fie capabile să planifice, execute, controleze procesele organizaționale la fiecare moment dat. Avantajele obținute de companiile care implementează soluții de tip ERP includ reducerea costurilor și stocurilor, în special prin facilitarea fluidizării operațiunilor acestora. Procesul nu se oprește însă aici, este extrem de important ce fac companiile după ce procesele lor de afaceri au fost fluidizate. În acest sens, îmbunătățirea continuă a sistemului informatic integrat din companie reprezintă o provocare semnificativă. Modul în care companiile gestionează evoluția sistemelor ERP odată cu organizația este o sarcină complexă. În aceeași măsură în care companiile se schimbă, și infrastructura informațională a acestora, bazată pe ERP, trebuie să reflecte aceste schimbări. Managerii de top înțeleg procesul de îmbunătățire și exploatare a investiției efectuate în ERP. În organizațiile cu viziune, cel mai important ingredient al succesului și avantajului competitiv va fi probabil calitatea integrării dintre inițiativele de tip ERP și cele de tip comerț electronic din cadrul organizațiilor.

36