I.

SISTEME INFORMATICE INTEGRATE (ERP)

1. Obiective
Dup parcurgerea acestui capitol, studenii vor putea:
S evalueze modul n care sistemele informatice integrate de tip ERP furnizeaz valoare
adugat pentru organizaie i s descrie modul de funcionare a acestora
S explice modul n care sistemele informatice integrate pot fi utilizate pentru crearea de
servicii cross-funcionale
S identifice provocrile ridicate de implementarea sistemelor informatice integrate
S evalueze o strategie de implementare a unui sistem informatic integrat
S evite principalele greeli aprute n implementarea sistemelor informatice integrate
2. Introducere
O cale excelent de a ncepe analiza unei organizaii este de a vedea organizaia ca un sistem
sau grup de procese legate. Gndirea la nivel de sistem presupune nelegerea forelor i
interdependenelor existente ntre diferitele arii funcionale dintr-o organizaie. Sistemele ERP
trebuie privite ca un grup de procese interdependente, gestionate de oameni. nelegerea
acestora presupune aprofundarea modului n care sunt dezvoltate, gestionate i ntreinute de
ctre oameni, n cadrul unei organizaii.
3. Definirea i importana sistemelor de tip ERP
Sistemele ERP integreaz informaii interne i externe de management din ntreaga organizaie,
acoperind toate procesele din cadrul acesteia, precum cele financiar-contabilitate, vnzri,
aprovizionare, producie service, gestiunea relaiilor cu clienii etc.
Sistemele ERP automatizeaz activitile din organizaie cu ajutorul aplicaiilor software
integrate. Scopul ERP este de a facilita fluxul de informaii ntre diferite funcii ale organizaiei i
a de a gestiona tranzaciile i conexiunile cu partenerii externi.
Sistemele ERP pot rula pe diferite platforme hardware i configuraii de reea i au de regul o
baz de date unic, pentru a depozita informaiile n mod consistent.
Acronime consacrate:
ERP = Enterprise Resurce Planning
MRP = Materials Requirement Planning
4. Motive pentru apariia ERP-urilor
O organizaie care nu are un ERP croit pe nevoile ei se poate regsi n situaia n care utilizeaz
mai multe programe/aplicaii software care nu interacioneaz ntre ele i care nu pot fi
modificate/adaptate. Din aceast cauz, aceste aplicaii nu pot optimiza activitile din cadrul
organizaei. n acest scenariu se cheltuie efort semnificativ cu ntreinerea i mbuntirea

aplicaiilor singulare, iar complexitatea crete exponenial pe msur ce se ncearc crearea

interdependenelor ntre aplicaii, respectiv ariile funcionale: vnzri, aprovizionare, producie,
contabilitate etc.
Toate aceste lucruri se schimb n momentul n care se implementeaz un sistem ERP. Fluxurile
informaionale sunt fluide i constante i permit urmrirea proceselor n orice moment,
indiferent de proces sau de activitate din cadrul procesului. De exemplu, stadiul livrrilor se
poate urmri n timp real, de la comanda clientului i pn la ncasare. Achiziiile i cheltuielile
pot fi controlate n funcie de limitele bugetare i de nivelele de aprobare din organizaie, cu
reflectare imediat n contabilitate.
Funciile de marketing, vnzri, aprovizionare, logistic, controlul calitii, stocuri, producie,
trezorerie, contabilitate i multe alte areale funcionale pot fi integrate ntr-o baz de date
unic cu ajutorul unui sistem ERP. Acest lucru duce la eliminarea pierderilor ocazionale de
informaii i la minimizarea erorilor care provin din reintroducerea datelor. Aceast abordare
integreaz toate departamentele i funciile din cadrul organizaiei, ntr-un singur sistem
informatic care poate fi accesat i utilizat de ctre angajai i deservete nevoile specifice la
nivel departamental, precum i pe cele la nivel organizaional.
Sistemele ERP modeleaz i automatizeaz procesele de business, care sunt astfel standardizate
i ofer acelai nivel de nelegere pentru toat lumea, chiar i n relaiile cu clienii i furnizorii
cu care organizaia interacioneaz. Aceste sisteme stocheaz date istorice despre activitile
din organizaie, pe o perioad lung de timp, precum i activitatea curent i planurile viitoare
i organizeaz informaiile ntr-o manier uor de neles, pentru a dezvolta strategiile de
business i a ajuta la luarea mai rapid a deciziilor.
n sistemele ERP sunt integrate datele financiare prin funcia financiar-contabil, ce reprezint
fundaia pe care se sprijin restul proceselor i care colecteaz toate tranzaciile i consecinele
lor contabile pentru a nelege i analiza performana organizaiei. Cifrele din operaional (ex.
volumul de vnzri) se reflect imediat i n contabilitate (ex. conturile de venituri din balanta
contabila sau contul de profit si pierdere) astfel nct se poate obine o singur versiune a
adevrului.
Un caz aparte, care justific nevoia unui sistem ERP, se regsete n organizaiile cu mai multe
divizii (business units) sau organizaii care au fuzionat sau au achiionat alte companii i care
sunt puse n situaia de a integra procesele.

5. Noiunea de siloz (silo) versus noiunea de sistem integrat

Noiunea de siloz presupune existena mai multor programe, care nu comunic ntre ele fiecare
utiliznd o baz de date proprie, n contradicie cu un sistem integrat care, avnd o singur baz
de date, reuete s integreze toate procesele din organizaie.

Sistemul integrat acoper toate ariile funcionale din organizaie

6. Istoria ERP-urilor
Istoria ERP-urilor este un subiect destul de amplu i interesant. n cteva cuvinte, evoluia a
nceput de la sistemele MRP din anii 60 care acopereau nevoia de a gestiona cereea i
comenzile, fr s se uite la timp (dinamic), doar la nevoi. MRP II s-a dezvoltat n anii 70
pentru a aduce att cererea, ct i orizontul ei de timp n procesele de planificare. n acelai
timp, soluiile de gestiune financiar-contabil au ctigat 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 aplicaiile financiare, pentru a oferi soluii complete i integrate de gestiune.
Istoria ERP-urilor cunoate cteva etape majore, dependente i de evoluia tehnologie
informaiei:

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 aprovizionrii de componente.

1970 - MRP i dezvoltri hardware i software

Primele sisteme MRP sunt mari, scumpe i greoaie. Este nevoie de o echip tehnic
numeroas pentru a ntreine sistemele mainframe, pe care rulau aceste programe.
1972 - Cinci ingineri din Mannheim, Germania, nfiineaz compania SAP
(Systemanalyse und Programmentwicklung). Scopul SAP este de a produce i
comercializa software standard pentru soluii integrate de business.

 1975 - Richard Lawson, Bill Lawson, John Cerullo dau natere la Lawson Software.
Fondatorii au intuit nevoia unor soluii software de ntreprindere gata mpachetate, ca
alternativ la aplicaiile de business la cheie (customizare).
1976 - n domeniile cu producie, sistemul MRP (Material Requirements Planning)
devine concept fundamental utilizat n controlul i gestiunea produciei.
1977 - Jack Thompson, Dan Gregory i Ed McVaney formeaz JD Edwards. Fiecare
fondator are o bucat din numele su n denumirea companiei. n acelai an, Larry
Ellison nfiineaz Oracle Corporation.
1978 - Jan Baan - Olanda - nfiineaz The Baan Corporation pentru a furniza servicii de
consultan financiar i de management.
1979 - Oracle ofer primul sistem de baze de date relaionale, 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/seciile de lucru) i managementul activitilor
de distribuie.
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 funcionalitile de producie i planificare.
1985 - JD Edwards este recunoscut ca leader n industria aplicaiilor software pentru
succesul repurtat cu IBM AS/400, un descendent al System/38.
1987 - Peoplesoft este fondat de ctre 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
apariia, cnd 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 crete i ajunge la 1800 clieni globali i peste 1000 angajai
1999 - JD Edwards are peste 4700 clieni, n peste 100 ri. Oracle are peste 41000
clieni, din care 16000 n SUA. Peoplesoft este utilizat n mai mult de 50% din piaa de
aplicaii pentru HR.
1999 - SAP este cel mai mare productor de soft pentru nteprinderi i al patrulea
furnizori independent de software., cu peste 20500 angajai n peste 50 ri. La aceeai
dat, mai mult de 2800 sisteme Baan au fost implementate n aproximativ 4800 locaii
pe glob.

2000 - consolidarea furnizorilor de software

2001 - Dup 11-Septembrie are loc o scdere n cererea de sisteme ERP.
2002 - Majoritatea sistemelor ERP actualizeaz produsele pentru a le face Internet
enabled (Internet active), astfel nct clienii 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 consolidrile:
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

Piaa va cunoate n continuare consolidri, dat fiind faptul c n spaiul SMB (Small and
Medium Sized Companies) ea este nc foarte fragmentat, cu sute de juctori.
O nou etap n istoria ERPurilor se scrie pe msur ce furnizorii migreaz ctre cloud,
fie furnizori tradiionali, fie furnizorii mai noi.

7. Piaa de ERP-uri
Pe msur ce lumea continu s evolueze ntr-o economie global i sistemele ERP cunosc o
evoluie similar. Soluiile ERP proprietate care se instaleaz pe infrastructura beneficiarului nu
mai reprezint astzi singura opiune. Azi exist soluii ERP de tip SaaS (software as a service),
de tip on-demand (la cerere) sau open-source. Cu toate aceste opiuni disponibile companiilor
de pe ntreg mapamondul, piaa soluiilor software ERP va ajunge la peste 50 miliarde dolari la
finele anului 2011, n condiiile n care, ncepnd cu anul 2006 piaa global a crescut cu o rat
anual de 11%. Cu toate acestea, o cretere de 11% nu este considerat o cretere mare, dat
fiind faptul c n trecut, nainte de 2006, piaa ERP-urilor cretea cu o rat anual de 18%.
Vremea cheltuielilor (bugetelor) nebuneti din anii 90 a apus.
Chiar dac nu mai sunt bugetele din anii 90, companiile cumpr n continuare sisteme ERP i
vor continua s cumpere i n viitor. Probabil este corect s presupunem c veniturile viitoare
din vnzarea soluiilor ERP vor fi distribuite ntre diferitele tipuri de soluii ERP. De exemplu,
ERP-urile cloud-based i SaaS vor lua o bucat din piaa de 50 miliarde USD. Aceste noi tipuri de
soluii ERP ne vor propulsa n economia global, permind acces facil web la sistem de ctre
angajaii situai n diferitele coluri ale lumii. Instrumentele de colaborare vor deveni eseniale
pentru orice tip de business i se vor integra cu sistemele ERP. Iar soluiile ERP mobile vor
deveni din ce n ce mai importante. Oricine dorete s aib acces la infomaiile de business de
oriunde s-ar afla n lume. O singur tendin sigur nu vom mai vedea n acest domeniu n
perioada imediat urmtoare, i anume boom-ul din anii 90. Astzi, piaa soluiilor software ERP
este aproape saturat. Muli furnizori mici au fost cumprai de furnizori mai mari, iar o parte
din ei au falimentat n perioada de criz/recesiune. Pe msur ce economia global i va reveni
putem anticipa un viitor mai luminos pentru soluiile ERP.
5

Piaa romneasc de ERP este nc puin dezvoltat, comparativ cu alte ri din Europa Central
(Cehia, Ungaria, Polonia) i are o dimensiune de aproximativ 100 milioane Euro, din care 50%
licene i servicii. Tendinele de pe piaa global se regsesc i pe piaa romneasc, mai
sensibil la pre fa de alte piee.
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 legturile
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 funcia de vnzri, n care regsim mai multe
subprocese care in de departamentul vnzri (contracte, oferte), departamentul
logistic/comercial (comanda client, avizul i factura) i departamentul financiar (ncasrile).

n partea de jos este reprezentat funcia de cumprri, n care regsim subprocesele ce in de

departamentul achiziii (contracte furnizori), aprovizionare/comercial (comenzi furnizori,
recepii marf), financiar-contabilitate (facturi i pli).
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 rspund la dou ntrebri fundamentale:
cnd i ct trebuie s aprovizionm/producem astfel nct s livrm la timp i s nu avem
suprastoc ?
cnd i ct trebuie s pltim i ncasm astfel nct s onorm la timp obligaiile i s
maximizm surplusul de cash pentru investiii ?

II. IMPLEMENTAREA SISTEMELOR ERP

Ciclul de implementare a unei soluii ERP1 conine patru faze mari:

Determinarea necesitii ERP

Selecia furnizorului

Implementarea propriu-zis

mbuntirea continu (postimplementarea)

Faza 1. DETERMINAREA NECESITII UNUI SISTEM ERP
Are n atenie urmrorele aspecte:

Necesitatea unui ERP

Costuri i beneficii

Cerinele
Obs. Poate fi un sistem ERP la prima implementare, sau un proiect de upgrade sau extindere.
Prima ntrebare: De ce?
Decizia de a achiziiona 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 organizaia, iar tehnologia apare ca un catalizator, oferind instrumente pentru
valorificarea oportunitilor. De aceea se spune c implementarea unui ERP determin
schimbri organizaionale.
A doua ntrebare: Ct cost?
Metoda tradiional de achiziie a unui sistem ERP presupune luarea n calcul a urmtoarelor
componente de cost, componente care formeaz costul total de deinere (TCO = Total Cost of
Ownership):
costul proiectului pilot
evaluarea ntre dou soluii finaliste
costul de achiziie
infrastructura hardware: servere, reelistic, staii de lucru, dispozitive mobile
infrastructura software: licene pentru sistemele de operare (Windows, Linux,
Unix), licene pentru baza de date (Oracle, Microsoft SQL Server, IBM DB2,
Postgres SQL etc), licene software ERP (per module sau per sistem, per
utilizatori nominali sau utilizatori concureni)
servicii de implementare: project management, consultan, instruire, asisten
funcional i tehnic, dezvoltri i adaptri
costul de mentenan: mentenana hardware, mentenana 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.

Level Agreement): helpdesk i rezolvarea incidentelor, asisten suplimentar, finetunning, optimizri, alte servicii extinse.
Adunnd toate aceste componente de cost rezult un buget de ordinul zecilor/sutelor de mii de
euro, n funcie de dimensiunea i complexitatea business-ului, adic un efort investiional
semnificativ. Evident tot acest efort trebuie pus n balan cu beneficiile anticipate i realizate
astfel nct randamentul investiiei (ROI) s justifice achiziia.
Experii apreciaz c implementarea unui sistem ERP va costa pn la 6 ori mai mult ca licenele
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 implementri ERP reprezint ntre 1 i 3% din cifra de afaceri a
organizaiei.
Ca tipologie exist costuri iniiale i costuri continue. Structura acestor costuri este redat n
tabelul:

Categoria de cost
Directe
Integrator

Indirecte

Hardware
Software
Analiz, configurare, testare, lansare, ntreinere
Dezvoltare, customizare (personalizare) aplicaii
Instruire
Personalul intern: management proiect, angajai,
contracte temporare prestri servicii

Costuri
iniiale

Costuri
continue
(pe an)

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

Mentenan
15-25%
5%

Comentarii.
Pentru a reduce acest efort investiional iniial au aprut diferite alte forme de achiziie
(vnzare) precum nchirierea soluiei (hardware, software, integral sau pe componente) sau
utilizarea soluiei 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 numr mult mai mare de organizaii din spaiul
SMB (eng.) PME (fr.), adic organizaiile mici i medii.

MOTIVAREA INVESTIIEI. COSTURI I BENEFICII.

Dac analizm bugetele alocate pentru sistemele ERP apare automat ntrebarea de ce
managerii sunt dispui s cheltuie aceti bani? (care sunt motivele i beneficiile majore pe care
un sistem ERP le aduce organizaiilor).

Beneficiile implementrii sistemelor ERP

Rspunsul este simplu i se traduce n patru cuvinte (n ordinea prioritizrii de ctre manageri).
1. Control
2. Productivitate
3. Eficien (costuri reduse)
4. Informaii
Controlul se refer la mecanismele prin care se monitorizeaz i urmresc realizrile fa de
obiectivele, intele propuse astfel nct incidentele de business s fie minimizate, chiar
eliminate.
Exemple de incidente de business pot fi: furturile, ntrzierile n livrri, nregistrarea la timp a
tuturor documentelor, auditul contabil (toate documentele sunt reflectate la timp i corect n
contabilitate), respectarea standardelor, procedurilor i instruciunilor 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 fr erori, dac se poate n mod automat. Automatizarea
proceselor presupune eliberarea lor de resurse i deci economii semnificative. Facturarea
automat, contarea automat a mailurilor, tipriri automate de rapoarte, mecanisme de
generare documente reprezint doar cteva exemple de automatizare.
Eficiena se obine 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 fr funcia de planificare. n consecin, sistemul ERP se
substituie actorilor umani n funciile de planificare/pregtire rspunznd la ntrebrile ct i
10

cnd trebuie s produc, aprovizionez, pltesc. Concret, acest lucru se traduce n sistem prin
mecanisme de generare a propunerilor de comand ctre furnizori, ctre producie i a
propunerilor de plat.
Informaii. Performana n management presupune luarea deciziilor la timp i n cunotin de
cauz i ca atare sistemul trebuie s furnizeze informaii corecte i la timp, pentru toate
palierele i funciile din organizaie.
Se analizeaz n continuare, n cazul unei firme de producie, cele mai relevante beneficii care
pot fi msurate (beneficii cantitative):
Reducerea stocurilor. Practicile de planificare i programare mbuntite permit o
reducere a nivelului stocurilor cu 20% sau chiar mai mult. Aceasta se reflect n scderea
nivelului imobilizrilor (unde stocurile au o pondere destul de mare) i determin
economii la nivelul cheltuielilor asociate stocurilor (depozitare, manipulare, asigurare,
perisabiliti etc.).
Reducerea cheltuielilor materiale. Cele mai bune practici sunt implementate prin
sistemul ERP i la departamentul de aprovizionare. Aceasta permite negocierea unor
preuri mai bune i o reducere a costurilor cu cel puin 5%. Se realizeaz prin bazele de
date create, care conin informaii utile despre furnizori legate de calitatea livrat i
respectarea termenelor de livrare. Prin integrarea n amonte a furnizorilor n sistemul
ERP acetia pot afla cererile viitoare, asigurnd creterea eficienei i posbilitatea de a
oferi preuri mai mici unor comenzi ferme.
Reducerea cheltuielilor cu fora de munc. Se apreciaz c un sistem ERP poate
conduce la o reducere a cheltuielilor cu fora de munc de 10%. Optimizarea fluxurilor
de materii prime i materiale elimin timpii mori i evit supraaglomerarea. Se poate
stabili mai bine necesarul de for de munc i se poate realiza mai bine creterea
calitii resurselor umane prin activiti de training2.
mbuntirea vnzrilor i a relaiilor cu clienii. Corelarea produciei cu vnzrile
asigur mbuntirea relaiei cu clienii. Sistemul ERP II integreaz n aval clienii prin
CRM. Se permite astfel gestionarea eficient a contactelor cu clienii, scurtarea
perioadei de la comand la livrare, respectarea termenelor. Toate acestea conduc la
creterea satisfaciei clienilor i implicit o cretere a vnzrilor, apreciat de analiti la
cel puin 10%.
Control mai bun asupra contabilitii i creanelor. Fluxurile informaionale i
procedurile definite permit o mai bun coordonare i un control mai eficient a tuturor
activitilor 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 creanelor mai ferme. Se permite cunoaterea n timp real a fluxului de trezorerie i
previzionarea acestuia. Se apreciaz o reducere a termenului de ncasare a creanelor cu
15-20%.

Conceptul de training se refer la dezvoltarea abilitilor i cunotinelor individului necesare ndeplinirii mai
eficace a unor sarcini sau a procesului de evoluie personal (https://ro.wikipedia.org/wiki/Training).

11

STUDIU DE CAZ: Calculul beneficiilor cuantificabile

O firm cu activitate de producie are o cifr de afaceri de 25 milioane lei. Firma are solduri
importante la conturile de stocuri i creane/debitori. Partea de activ a balanei de verificare, cu
imobilizrile este prezentat n tabelul urmtor:
Economii determinate de sistemul ERP asupra imobilizrilor
Valoarea curent
Denumire
mbuntire
(mii lei)
A. Disponibiliti bneti
125
B. Debitori
500
18%
C. Stocuri
750
20%
D. Mijloace fixe
750
Total imobilizri (C+D-A)
1375
Total economii

Economii
(mii lei)
90
150
240

Rezult o reducere de 17.45% (240/1375) a valorii totale a imobilizrilor.

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
producie, costurile reprezint 70-75% din vnzri.
Presupunem c beneficiile aduse de sistemul ERP influeneaz valorile indicatorilor astfel:
Optimizarea activitii de aprovizionare duce la reducerea cheltuielilor materiale cu 5%.
Creterea productivitii, optimizarea fluxurilor informaionale i reducerea/eliminarea
prelucrrilor repetate conduce la reducerea cu 10% a cheltuielilor de personal.
Reducerea cheltuielilor administrative este asociat reducerii nivelului stocurilor
(cheltuieli aferente stocrii). 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
mbuntire
(mii lei)
(mii lei)
A. Venituri din vnzri
2500 (*)
10%
B. Cheltuieli materiale
1125
5%
56,25
C. Cheltuieli cu fora 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
(*) Creterea de aproximativ 10% a veniturilor din vnzri nu o lum n calcul, dei aceasta
va conduce la ridicarea nivelului profitului.
Prin introducerea unui sistem ERP se obine o economie total: 240+118,75= 358,75 (mii lei).
Dac estimm costurile sistemului ERP la 5% din cifra de afaceri a firmei rezult 1250 (mii lei).

12

Aceasta presupune o recuperare total a investiiei n mai puin de patru ani. Se remarc o
cretere a profitului de aproximativ 20% i o cretere a cifrei de afaceri n urmtorii ani prin
creterea veniturilor (aceasta nu a mai fost luat n calcul).
Beneficii necuantificabile (nonfinanciare)
Efecte asupra contabilitii. Baza de date ERP asigur introducerea datelor o singur
dat n sistem i apoi utilizarea lor n toate aplicaiile. Pe msur ce tranzaciile de
producie sunt nregistrate, echivalentele financiare sunt generate n mod automat,
pentru a actualiza fiele conturilor. Se asigur astfel trasabilitatea de la documentul
surs la fia contului. Informaiile financiare sunt corecte i actuale i permit urmrirea
cheltuielilor reale fa de cele bugetate. Se micoreaz timpul de realizare a
procedurilor contabile obinuite i de nchidere. Rapoartele financiare pot fi modificate
prin configurri rapide, pentru a rspunde factorilor de decizie. Acces rapid i controlat
la informaiile sensibile, n funcie de competene, n baza drepturilor de acces.
Creterea eficienei n munc a angajailor prin verificri de consisten, numeroase
optimizri i automatizri i prin generarea documentelor n vederea raportrilor
periodice.

Efecte asupra produsului i procesului de producie. Sistemul ERP ofer control total
asupra produsului i procesului de producie prin bazele de date care conin informaii
asupra produselor (nomenclatoare), structurii produselor, consumului tehnologic,
liniilor de producie, calitii produselor etc. Se pot calcula rapid costurile de producie
n cazul unor schimbri tehnologice sau schimbri de materiale. Se pot realiza simulri
ale costurilor de producie pentru diferite situaii. 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
vnzrilor i a necesarului de producie, gestiunea furnizorilor i a operaiunilor de
import.

Efecte asupra eficienei operaionale. Sistemul ERP permite o mai mare capacitate de
adaptare i o mai mare flexibilitate n relaia cu clienii i furnizorii. Se pot realiza
previziuni asupra evoluiei pieei i analize pe cuburi OLAP care reprezint un suport
important n procesul decizional. Se micoreaz timpul de livrare, se mbuntesc
activitile postvnzare, cu rezultat direct n creterea satisfaciei clienilor.

Concluzii
Cu ct beneficiile sunt orientate spre viitor, cu att crete dificultatea de msurare.
Beneficiile importante nu rezult neaprat din utilizarea efectiv a sistemului ERP, ci din
transformarea organizaional indus de implementarea lui i oportunitile de valorificare
create.

13

Se apreciaz c 90% din costuri i beneficii revin bunurilor intangibile, create prin investiiile
n software, educare i transformri organizaionale3.
Valoarea unui sistem nu se regsete n tehnologia informaional nglobat, ci n modul n
care tehnologia este utilizat4.

DEFINIREA CERINELOR
Scopul acestei activiti este identificarea proceselor, descrierea lor i a aspectelor cheie care
trebuie urmrite. 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.
Observaie. Exist multe situaii practice n care definirea cerinelor se realizeaz direct de ctre
firma furnizoare de software n colaborare cu firma beneficiar.
Teoretic, definirea cerinelor conduce la realizarea caietului de sarcini, care va fi transmis
potenialelor firme furnizoare participante la licitaie.
Exemplificare: Caietul de sarcini Loteria Romn, Caietul de sarcini Radiocomunicaii.

Faza 2. SELECIA FURNIZORULUI

Furnizorul care va fi selectat nu doar livreaz plaforma, ci o implementeaz i o personalizeaz
pentru firma-client prin transferul de cunotine i expertiz ctre acesta. Relaia cu furnizorul
trebuie s fie una de lung durat, de preferat pe toat durata de utilizare a aplicaiilor. 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 selecia5:
Alegere aleatoare echipa de manageri nu ajunge la un consens; alegerea aleatoare
rmne singura posibilitate de luare a deciziei.
Alegere pe baz de cunotine (persoane cunoscute) nu e recomandat, deoarece
relaia cu furnizorul va fi una prietenoas; este posibil ca aplicaia aleas s nu fie cea
mai bun soluie i aceasta va influena succesul implementrii.
Alegerea celei mai titrate soluii un singur criteriu de alegere nu asigur ntotdeauna
succesul.
Subcontractarea activitii de implementare evit responsabilitatea alegerii, dar
costurile externalizrii pot fi foarte mari.
Compararea i evaluarea riguroas a ofertelor primate rmne soluia cea mai
indicat.

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 selecie este important stabilirea echipei care va fi implicat n luarea deciziei.
Cteva aspecte de luat n considerare sunt:
Cine sunt beneficiarii noului sistem? Cum pot fi implicai prin reprezentani n procesul
de selecie?
Specialitii IT nu trebuie s predomine numeric, deoarece proiectul ERP este un
proiect economic!
Manageri din toate ariile funcionale trebuie s participe la selecie.
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 condiia obiectivitii.
Echipa poate fi mai mare la nceput n etapa de definire a cerinelor, iar apoi numrul
membrilor poate fi redus.
Etapele procesului de selecie:
Prospectarea pieei.
Crearea listei scurte de furnizori poteniali.
Restrngerea listei.
Selecia final.
Posibile criterii de evaluare pentru crearea listei scurte de furnizori poteniali:
Prezena furnizorului pe piaa din Romnia.
Orientarea soluiei ERP ctre domeniul de activitate al clientului.
Cerine funcionale sau tehnice.
Experiena - numrul de implementri din domeniul de activitate vizat.
Mrimea organizaiei furnizorului (numr de angajai, cifra de afaceri).
Situaia financiar a furnizorului.
Prima impresie lsat managerului din firma beneficiar.
Restrngerea listei. Criterii de selecie a furnizorului sistemului ERP:
Funcionalitatea este determinat de potrivirea dintre cerine i soluia furnizat la
nivel de aplicaii i echipamente.
Metodologia de implementare existena unei metodologii clare i de calitate reduce
riscul de eec.
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.
Experina n domeniu implementrile anterioare (ca numr i finalitate) n domeniul
de activitate n discuie nseamn experin i expertiz accumulate.
Suportul postimplementare este important disponibilitatea i experiena.
Reputaia contribuie la obinerea succesului.
Strategia furnizorului viziunea, strategia acestuia pe termen mediu i lung indic
direciile viitoare de dezvoltare.

15

Selecia final. Se poate identifica un patrulater al seleciei:

Latura 1. Funcionalitatea. Se organizeaz la sediul beneficiarului sesiuni de
prezentare i demonstraii funcionale. Cu acest prilej se investigheaz aspecte
legate de exploatarea aplicaiilor: interfaa grafic utilizator, conectivitatea BD
(gestiunea tabelelor, interfaa 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?

Eficiena metodologiei de implementare depinde de furnizorul sistemului ERP.

Latura 3. Asistena. Este furnizorului este important n faza de inplementare, dar i n

etapa urmtoare de postimplementare.

Latura 4. Costurile. Normal ar fi s se caute soluia care ofer cel mai mult pentru
preul pltit i nu soluia cea mai ieftin. Pentru a realiza comparaia se introduce
categorii clare de costuri:
- costuri cu echipamentele;
- costuri cu sistemul de operare;
- costuri de liceniere pentru SGBD;
- costuri de liceniere a modulelor;
- costuri de liceniere pentru alte aplicaii;
- costuri de integrare ntre modulele ERP a altor aplicaii 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 cerine suplimentare.
Alte aspecte de luat n considerare n procesul seleciei finale:
credibilitatea i reputaia firmei furnizorului;
experiena de implementare n domeniul de activitate al clientului;
strategia pe termen mediu-lung (reprezint un reper important al viabilitii
furnizorului: dac furnizorul are o viziune, direcii de aciune, expuse ntr-o strategie,
dac investete n cercetare dezvoltare, dac ncheie parteneriate cu nume mari);
poziia pe pia a firmei care dezvolt ERP-ul;
intuiia i inspiraia factorilor de decizie din firma beneficiar (dat i de experiena 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 implementrii unui sistem ERP

A. Project Setup
Scopul acestei etape este acela de a identifica organizaia clientului i necesarul de resurse
pentru o implementare de succes.
Reprezentanii beneficiarului i ai furnizorului vor stabili mpreun strategia i termenii
implementrii, 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 urmrire a implementrii.

17

Pe parcursul implementrii vor avea loc ntlniri ntre reprezentanii prilor pentru a se evalua
bunul mers al procesului i vor fi ntocmite rapoarte de evoluie (status report) a proiectului de
implementare n momente considerate cheie de ambele pri i/sau pe msur ce se consum
un cuantum prestabilit din efortul bugetat iniial.
Implementarea se va desfura conform unui grafic sau calendar de implementare, care ine
cont de resursele implicate n proiect i n aceast faz:
se stabilete i se consolideaz echipa de proiect;
se stabilesc obiectivele pe fiecare etap de implementare i se agreaz de ambele pri
(furnizor i beneficiar); acestea se comunic echipei de proiect;
se stabilete necesarul de resurse pentru buna implementare a proiectului;
se stabilete planificarea ct mai detaliat n timp a activitilor pe fiecare etap i resurse
implicate;
se stabilesc i se documenteaz rolurile i responsabilitile, matricea comunicrii;
se formalizeaz data de start a proiectului, precum i regulile jocului printr-un ntlnire.
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 cunotine n ansamblul
sistemului ERP care urmeaz s fie implementat, de ctre toat echipa de proiect.
B. Analiza proceselor curente
Scopul acestei etape este acela ca ntreaga echip de proiect s cunoasc i s neleag n
detaliu procesele curente de business din cadrul organizaiei clientului, pentru a putea face
setup-ul iniial al sistemului.
Ariile supusei analizei sunt:
Structura organizatoric.
Misiuni, probleme, obiective.
Procesele existente

Funcia de Aprovizionare;

Funcia de Vnzare;

Managementul Stocurilor i al Depozitelor;

Funcia de Producie;

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, rezultnd planul de dezvoltare software i planul de schimbare n procese.
18

C. Prototip & Build

Scopul acestei etape este acela de a obine sistemul configurat corect astfel nct s rspund la
maxim cerinelor de business rezultate din etapele A i B, nainte de a fi dat n producie.

Se lucreaz la diverse configuraii i setri ale sistemului:

Roluri i utilizatori, alte elemente de securitate

Definiri contabilie (planuri conturi, taxe, conturi bancare, reguli contabile,

termene de plat)

Definiri nomenclatoare: produse, teri, gestiuni etc.

Definiri tipuri documente, reguli i workflow

Traduceri i terminologie specific

Import de date istorice (iniializri)

Se identific toate modificrile necesare sistemului, acolo unde acesta nu rspunde sau nu
s-au gsit variante alternative acceptabile i se elaboreaz specificaiile pentru dezvoltrile
necesare.
Se fac teste, simulri i demonstraii pentru procesele stabilite n etapa B, pentru fiecare
cerin de business agreat de ctre responsabilii proceselor respective.
Se stabilesc toate ariile n care se preiau date istorice, forma acestora, responsabilii cu
pregtirea acestora.
Se reia trainingul echipei de proiect pe funcionaliti restrnse i pe specificul de business
al clientului; de data aceasta se decide cum se configureaz sistemul.

Tot n aceast etap se fac dezvoltrile necesare i agreate, pe baza specificaiilor. Tot aici este
inclus i efortul pentru pregtirea formatelor de import de date istorice, testarea acestora.
D. Pregtire final i training
Este etapa n care pe baza sistemului prototip se fac urmtoarele:
Setarea sistemului n mediul de producie.
Trainingul cu utilizatorii finali.
Documentarea procedurilor de lucru i a instruciunilor de lucru.
Testul de integrare - reprezint verificrile de integrare cu tere sisteme, dac este cazul.
Testul de utilizare - reprezint testele de acceptan din perspectiva utilizrii sistemului de
ctre utilizatorii finali.
Testul de stres - reprezint testele de volum pentru a dovedi c sistemul va face fa la
volumul de date din mediul de producie.
E. GO Live
Aceast ultim etap reprezint pornirea sistemului n producie.
Se ofer asisten din partea echipei de proiect pentru utilizatori i se valideaz primul set de
rapoarte, conform obiectivelor agreate.
Se stabilete planul pentru cazurile de urgen, incidente neprevzute i se face trecerea n
sistemul de suport intern i extern. n final se se celebreaz lansarea cu succes a sistemului.

19

Punerea n funciune 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: funcionarea concomitent a vechiului sistem n paralel cu

noul sistem; durata se stabilete pentru a surprinde perioadele de vrf de activitate
(ncheiere de lun, semestru, an). n general durata de implementare n paralel nu
trebuie s depeasc 3-4 luni.
Avantaj: se poate verifica pe date reale funcionarea 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 funcionrii corecte se trece la generalizarea
implementrii sistemului i la celelalte uniti 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 adaptri de la o unitate la alta.
Dezavantaj: riscul strategiei aprecierea greit a reprezentantului clasei tipologice ca
unitate pilot; rezult cheltuieli i ntrzieri importante.

Implementarea poate fi realizat prin urmtoarele tactici:

implementarea simultan a tuturor aplicaiilor sistemului;
implementarea n serie a aplicaiilor.
Alegerea strategiei i tacticii de implementare
Stabilirea strategiei se poate face innd cont de urmtoarele criterii:
gradul de pregtire profesional a utilizatorilor SI;
gradul de pregtire 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 cerinelor de informare de ctre vechiul i noul sistem
Alegerea tacticii depinde de:
numrul de specialiti din partea beneficiarului disponibili;
gradul de pregtire al beneficiarului n vederea implementrii;
Jaloane orientative pentru alegerea strategiei de implementare:
Implementarea direct recomandabil pentru SI mai puin complexe, cu grad de
originalitate mai redus. Diferena dintre SI vechi i SI nou este mai mare. Este indicat
20

pentru aplicaii care nu necesit termene stricte de predare a lucrrilor i este

contraindicat pentru aplicaii bancare, calculul salariilor etc.

Implementarea n paralel se recomand pentru sistemele complexe cu grad sporit de

originalitate, pentru aplicaii cu termene severe. Paralelismul nu afecteaz desfurarea
activitii organizaiei i evit situaiile de dezastru, datorate SI implementat.

Implementarea pilot se recomand n condiiile existenei unei clase tipologice cu un

numr nsemnat de uniti reprezentate de unitatea pilot.

Comentariu
Big Bang versus implementarea pe module
n etapa de planificare a proiectului se analizeaz diferite strategii de implementare, n funcie
de prioritile i obiectivele de business, gradul de pregtire i maturitate al organizaiei,
precum i de buget.
Complexitatea unei implementri este dependent de dimensiunea organizaiei, procesele i
funciile care se doresc a fi acoperite i rspndirea geografic: mai multe sedii, depozite,
magazine, uniti organizaionale.
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
pregtire.
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 privete completitudinea soluiei i finalizarea implementrii pentru toate
procesele/zonele.
Comentariu
Modificarea softului vs. modificarea proceselor
O organizaie care are de gnd s implementeze un ERP fr a restructura operaiunile nu face
dect s cheltuie inutil nite bani i s ating eventuale beneficii minore. Mai degrab este o
pierdere net.
Indiferent de ct de sofisticat este produsul software selectat (sistemul ERP), acesta nu poate
mbunti semnificativ organizaia doar prin utilizarea lui. n cel mai optimist scenariu,
organizaia se va mbunti marginal i cu siguran, valoarea mbuntirilor marginale nu se
va apropia nici pe de parte de costurile semnificative ale unui proiect de implementare,
consumator de resurse i timp.
Dac o organizaie nu se folosete 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 eecuri similare.
Mai degrab organizaia ar trebui s foloseasc proiectul ERP ca un catalizator pentru
schimbare. Este o scuz bun de a raionaliza i mbunti business-ul (procesele). Proiectul
21

ERP nu este un proiect software - este un proiect de restructurare, un proiect de schimbare

organizaional. Ar trebui s privii la proiectul ERP conform regulii 80/20: 80% din beneficii
rezult din mbuntirile proceselor de business, 20% din software-ul ca atare.
Este important s reinei aceste considerente operaionale atunci cnd facei evaluarea
propunerilor de implementare i a furnizorilor ERP. Dac de pild vorbim de o organizaie
medie i furnizorul propune o implementare cap-coad n decurs de cteva luni, semnalele de
alarm ar trebui trase. Gndii-v la urmtorul aspect. De ct timp organizaia voastr tie
despre anumite procese de business suboptimale care lovesc n perfomana organizaiei?
Probabil de un timp destul de ndelungat. Cel mai probabil c organizaia este anchilozat cu
aceste procese suboptimale pentru c schimbarea lor este prea complex i descurajatoare.
Deci, n acest context, chiar credei c un furnizor de soluii 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 fr cusur? Rspunsul este cel mai probabil, nu. Realizarea tuturor acestor
sarcini presupune timp, ndemnare, munc mult i determinare.
De cele mai multe ori (se pare c din ce n ce mai des) multe companii apeleaz la reimplementri sau proiecte de salvare. n cele mai multe cazuri, n implementarea iniial,
atenia s-a acordat doar asupra software-ului i sarcinilor legate de acesta precum: instalare,
migrarea datelor, instruirea utilizatorilor strict legat de aplicaie (ecrane, rapoarte etc.).
n acest caz, furnizorul de soluie nu a ajutat la restructurarea organizaiei - care este
componenta principal i cheie a proiectului - i nu s-a asigurat c utilizatorii au nvat noul
sistem, precum i procesele de business (pe lng alte probleme tipice care apar, inclusiv
testarea i migrarea datelor).
Rezultatul final al acestei abordri simpliste (care nu implic restructurarea proceselor de
business) este c organizaiile ajung s utilizeze sistemul ERP fr ca acesta s fie perfect pliat
pe modul lor de a face business. i, business-ul are n continuare aceleai probleme
operaionale 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 recomandri operaionale, mai mult
sau mai puin semnificative.
Pn la urm, nu exist implementarea miraculoas. Nu exist scurtturi 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 greeli generate n principal de:
depirea timpului alocat fazei de implementare;
depiri semnificative ale bugetelor stabilite;
probleme operaionale la startul productiv din cauza instruirii insuficiente;
neobinerea beneficiilor ateptate;
muli beneficiari nu cunosc exact beneficiile pe care le vor obine dup implementare.
Demonstrarea eecului este mai simpl dect a succesului. Evitarea eecului este mai uoar
dect dobndirea succesului. Ambele aciuni 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 prezeni, nu neleg sau nu se implic;
utilizatorii nu sunt educai i motivai, deci nu se implic;
managerul de proiect nu are experien;
managerul de proiect nu are cunotinele necesare conducerii proiectului;
managerul financiar nu nelege 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;
consultani neexperimentai;
pierderea de personal calificat (analiti, programatori) la furnizor;
echipa furnizorului grbete termenele pentru ncasarea mai rapid a tranelor;
conducere slab a proiectului din partea beneficiarului, prin alegerea unui manager de
proiect slab, ezitant, inflenabil.
Toate aceste probleme sunt rezultatul unei slabe culturi organizaionale, fragil la schimbare.
Exist culturi organizaionale care favorizeaz schimbrile bazate pe tehnologiile
informaionale, dar exist i culturi care le frneaz ori chiar le resping.
FACTORI DE SUCCES N IMPLEMENTAREA UNUI ERP
Provocrile clasice care apar pe parcursul unui proiect de implementare sunt:
Implicarea managementului - orice proiect ERP fr participarea activ a
managementului este sortit unui eec garantat. Managerii sunt cei care au puterea de a
aloca resursele atunci cnd trebuie, de a motiva oamenii pentru a accepta schimbara i
de a valida soluiile de business conform cu cerinele exprimate, implcit sau explicit.

Comunicarea si Change Management - 90% din eecurile proiectelor ERP se datorez

comunicrii. Comunicarea n interioriul organizaiei pentru pregtirea angajailor pentru
schimbare este critic i trebuie gestionat pe tot parcursul proiectului de ctre
reprezentantul beneficiarului care i asum rolul de project manager intern. La fel de
critic este i comunicarea extern, ntre furnizorul soluiei i beneficiarul ei, pe toate
nivelurile - project manageri, consultani 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
corespunztor.

Incadrarea n buget - este condiia 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 ateptri
nerealiste, comunicare defectuoas i lipsa de implicare.

Mai jos sunt prezentate problemele principale cu care se confrunt multe proiecte de
implementare i cteva sfaturi prin care se pot preveni/elimina aceste probleme.
PROBLEME N IMPLEMENTAREA ERP-urilor
Sunt binecunoscute sutele de poveti de groaz referitoare la greutile ntmpinate n
implementarea sistemelor ERP i ca orice veste proast, acestea sunt adesea exagerate pentru
a garanta efectul dramatic asupra auditoriului.
Vestea bun? Abordarea implementrii 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.
Nimnui nu-i place s vorbeasc (sau s scrie) despre greeli, aa c mai jos sunt cteva
explicaii cu privire la ceea ce trebuie s fac o companie pentru a evita primele cele mai
importante greeli comune.
Greeala Nr. 1: Clientul nu reuete s i fac pe consultanii de implementare sa neleag
business-ul pe deplin
Organizaia-client cunoate business-ul n detaliu pentru c zilnic oamenii lucreaz i iar
lucreaz, fr s se gndeasc la ontologia ei. Pe de alt parte, consultanii de implementare
nu cunosc business-ul aa de bine, de aceea este important de a planifica timp pentru a aduce
consultanii la nivelul de cunoatere din interiorul organizaiei. Evident, aceasta se aplic la
procese, politici si proceduri, ns cele mai multe organizaii greesc n includerea oamenilor i a
culturii n ntreg peisajul i cteodat consecina este c a avem consultani cu aptitudini
tehnice corecte, dar cu comportamente greite. Merit efortul de a fi siguri c angajaii i
consultanii se neleg intre ei.
Ca i clieni n procesul de implementare, trebuie s ne asigurm c implementatorii din firm
sunt cu noi pe ntreaga durat a proiectului. Investim timp n educarea consultanilor n spiritul
business-ului, iar ultimul lucru de care avem nevoie este (ei facnd parte dintr-o echip) s ne
confruntm cu situaia in care s explicm totul din nou urmtorului consultant care ne bate la
u.
Sfat
Responsabilizarea furnizorului de sistem pentru continuitatea consultanilor de proiect i
dac e necesar, se poate face din acest lucru o obligaie contractual cu penaliti financiare
de fiecare dat cnd trebuie re-educat sau re-orientat un consultant nou.

24

Greeala Nr. 2: Lipsa reperelor realiste i dese pe tot parcursul proiectului implementrii.
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 rspundem la trei ntrebri critice:
1. Unde ne gsim?
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
desfoar proiectul, vom reui s cuantificm progresul i mai important s srbtorim reuita
mpreun cu ntreaga echip, pe msur ce proiectul avanseaz la timp i conform bugetului. Cu
siguran, se pot face ajustri dac din orice motiv aprut, proiectul nu se desfoar conform
planului.
Un lucru important de amintit n ceea ce privete 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 uor de cuantificat. Astfel, echipa proiectului si angajaii 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 (msurare) va fi
similar cu trasarea cursului unei nave dup urma lsat pe luciul apei.

Greeala Nr. 3: Lipsa oamenilor dedicai i de nalt calitate n echipa de implementare i lipsa
unei soluii de backup.
Este o realitate dureroas c oamenii de care ntr-adevr avem nevoie pentru implementare
sunt fr ndoial cei mai buni oameni din organizaie i este aproape garantat c acetia sunt i
cei mai ocupai. Cel mai bun lucru pe care l putem face este s gsim modaliti prin care s
delegm anumite ndatoriri ale acestora ctre implementatorii juniori, pentru a-i putea focaliza
ntreaga experiena asupra proiectului.
Mai mult, acordnd ansa implementatorilor juniori de a-i dovedi calitile la nivel mai ridicat,
se poate ctiga o gama variat de abiliti pentru afacere i se pot identifica i poteniale
promovri n acelai timp.
Un lucru este sigur, att juniorii ct i seniorii vor avea de nvat din experiene i vor fi o
investiie mai valoroas pentru organizaie n viitor. Managerii trebuie s fie gata s-i
recompenseze pentru eforturile susinute i pentru noile aptitudini dezvoltate.
Sunt multe feluri de a recompensa participanii la proiect, de la fia postului refcut i
ncadrarea n alt gril de salarizare, la asigurri n cuantum ridicat, ns pe departe, cea mai
eficient este bonusul neateptat.
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 srbtorirea fiecrui succes n mod public, o clduroas apreciere la
sfritul proiectului, nsoit de un week-end prelungit (o extensie a concediului anual normal),
astfel nct fiecare a simit c este apreciat pentru eforturile sale.

25

Sfat
Ca viziune asupra ntregului proiect i n legtur cu costul proiectului, bonusul adiional i
recunoaterea public vor aduce venituri mult vreme dup realizarea proiectului, iar n
termeni de ROI rentabilitate a investiiei (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 mndru c
face parte din echip i c este respectat pentru munca susinut pe care a depus-o n
cadrul proiectului.

Greeala Nr. 4: Inexistena unui buget corespunztor pentru training-ul utilizatorilor n noul
sistem
n majoritatea organizaiilor modul de abordare a implementrii 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 obinerea 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
mbolnvesc, nu se schimb i sunt elevi silitori.
Sfat
Revizuirea bugetului de implementare i acordarea unei atenii deosebite training-ului, al
crui buget trebuie dublat.

Greeala Nr. 5: Modificarea sistemului standard fr a cntri cu mare atenie att beneficiile
ct i riscurile.
Exist o tendin n multe organizaii 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 actualizri devin extrem de dificil de aplicat i orice suport help-desk intern, va fi
compromis, deoarece help-desk-ul trebuie s afle despre modificrile fcute, nainte ca s
poat fi de ajutor.
Astfel, abordarea plecand de la Cele trei reguli este una adoptat de muli directori generali
nelepi:
1. Dac inem cont de aceast cerin, care este beneficiul msurabil dovedit?
2. Am analizat toate alternativele i riscurile/beneficiile lor nainte de a alege s
modificm?
3. Dac nu suntem pionieri n acest domeniu, am vzut ce au fcut alte companii n aceast
zon, pentru a ne folosi ca lecie din care s nvm?
Sfat
Pstreaz Cele trei reguli ca parte integrant a deciziei asupra oricrei devieri de la planul
de proiect stabilit.

26

ine legtura cu alte companii din domeniu care au experimentat acest lucru i nva din
experiena lor.

Not: ntr-o organizaie directorul general a invitat oameni cheie din alt companie s participe
la ntlnirile lor de stabilire a strategiei. Scopul a fost ca persoanele invitate s-i mprteasc
experiena i cunotinele, dar ce este de semnalat, ei nu erau constrni (limitai) de politica
intern a firmei, astfel nct ei aveau libertatea s pun ntrebri pe care toi doreau s le pun,
dar din diferite motive nu puteau.
Greeala Nr. 6: Greeala de a nu proteja i a nu garanta prile critice ale afacerii.
Un exemplu de situaie 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 garanii de la distribuitorul de software:
1. O garanie c niciodat, dar niciodat, nu va fi pus n situaia de nu putea s ia comenzi
de la clienii si.
2. O garanie c noul sistem nu-l va mpiedica niciodat n expedierea comenzilor ctre
clieni de la depozitul su.
3. O garanie c noul sistem nu-l va pune niciodat, dar niciodat, n situaia n care s nu
poat accepta plile clienilor si i s le transfere banii n contul su bancar.
Cererile sale au fost directe - comercializarea produselor, distribuirea lor ctre clieni, precum i
plata pentru ele. Acestea erau chiar esena afacerii sale i dorea sisteme care s-i garanteze
aceste lucruri, s se asigure c are acoperire la orice eveniment neprevzut, referitor la cderea
sistemului. Deasemenea, a specificat c se putea deine controlul n alte zone care nu sunt
critice cu ajutorul proceselor alternative, timp de cel putin 12-24 de ore, fr ntreruperi
majore.
Sfat
Lecia care trebuie nvat - analizeaz afacerea ta cu atenie i depisteaz aspectele
critice, de care ai nevoie, s fie disponibile 24/24 de ore 7/7 zile pe saptmn si apoi ia
legatura cu furnizorul de hard i soft s te asiguri c ei au posibilitatea s-i asigure opiuni
de backup, s pastreze totul n funciune.
Chiar avnd attea exemple catastrofale despre companii care falimenteaz datorit
implementrilor de software nereuite, multe companii nc nu acord atenia cuvenit
implicaiei riscurilor. Planificarea i pregtirea adecvat este necesar pentru a ajuta la
identificarea i gestionarea potenialelor 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
selecia pachetului software i a furnizorului. Un sistem ERP este o investiie de durat, astfel
nct alegerea furnizorului care se potrivete cerinelor afacerii cu care s se poat dezvolta un
parteneriat pentru urmtorii 5-10 ani, este esenial.
Cu o cercetare i o planificare amanunit se pot evita cele ase greeli de mai sus.
27

METRICI DE SUCCES ALE UNEI IMPLEMENTRI

Pentru a putea msura succesul unei implementri, trebuie definite cteva metrici sau
indicatori de performan, derivate din obiectivele de business i obiectivele proiectului.
Aceti indicatori se msoar nainte de a ncepe implementarea, prin realizarea unui diagnostic
iniial i dup finalizarea implementrii, precum i la anumite intervale de timp de la finalizarea
implementrii (de exemplu la fiecare 6 luni).
mbuntirea constant a acestor indicatori indic succesul implemntrii i poate sta la calcului
realist al randamentului investiiei (ROI).
Exemple de indicatori sunt:
volumul stocului (msurat n zile)
timpul de livrare
rata de servire client
profitul i cifra de afaceri
numrul de documente procesate
numrul de incidente/erori nregistrate
volumul pierderilor, etc.
IMPLEMENTAREA ERP I CHANGE MANAGEMENT
Rezistena la schimbare
Implementarea unui sistem ERP presupune o schimbare major n organizaie, schimbare n
modul de lucru, procesele de business i interaciunile umane. i ca orice schimbare, ea
ntmpin rezisten, din partea utilizatorilor i/sau a managerilor.
Promotorul proiectului ERP nu este ntotdeauna ntregul consiliu director. Sunt manageri care
i vd periclitat poziia prin adoptarea unui nou sistem ERP, sau sunt persoane crora le este
pur i simplu fric de nou i de schimbare.
Managementul schimbrii n acest context nseamn dou variante change people or change
people, cu alte cuvinte fie se schimb mentalitatea oamenilor i ei sunt dispui i capabili s
adopte noul sistem, fie se schimb oamenii cu ali oameni.
n tot acest demers de schimbare este aadar esenial implicarea managementului n toate
fazele proiectului. Managemenul poate angaja consultani externi specializai n proiecte de
managementul schimbrii, aa cum prin definiie este i un proiect de implementare ERP.
Managementul obiectivelor pe termen lung
Este de reinut c implementarea unui sistem ERP este un proces continuu. Sistemul ERP
trebuie s fie acordat n permanen cu schimbrile din organizaie, schimbri care sunt
inevitabile i sunt din ce n ce mai dese i mai rapide, n acest secol XXI.
Aadar miza noilor sisteme ERP este flexibilitatea i capabilitatea de adaptare la situaii i
scenarii noi de business. ERP-ul este acel partener n organizaie care susine procesele de
afaceri i un sistem ERP performant rspunde la obiectivele pe termen lung i la nevoia
crescnd de agilitate organizaional.

28

Faza 4. MBUNTIREA CONTINU (POSTIMPLEMENTAREA)

Un proiect ERP nu este o destinaie, ci o cltorie.
Organizaia este un sistem dinamic, n continu adaptare i schimbare, de aceea, practic,
implementarea sistemului integrat nu se oprete niciodat.
Cauze: beneficiile anticipate nu sunt realizate, unele procese nu se ridic la nivelul ateptat,
unele procese funcionale pot fi optimizate etc.
Rezult un program de mbuntire continu, care poate conduce i la nlocuirea sistemului
ERP existent cu un sistem nou, atunci cnd se decide c upgrade-urile nu mai pot ajuta.

ntrebri
1. Care este importana utilizrii 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 puin importante?
3. Care sunt principalii factori de succes n implementarea sistemelor informatice integrate?

Bibliografie
1. Managementul strategic al tehnologiei informaiei. Suport de curs realizat n cadrul
proiectului POSDRU /86/1.2/S/61086, cu titlul Dezvoltare, inovare i extindere a
accesului la nvare n programe de master n administrarea afacerilor.
2. Hurbean L., Fotache D., Pvloaia V.D., Dospinescu O., Platforme integrate pentru afaceri
ERP, Editura Economic, Bucureti, 2013.

29

Studiul 1.
Sistemele informatice i procesele de afaceri. Adaptarea aplicaiilor informatice la procesele
de lucru sau schimbarea modului de lucru?6
Orice implementare major a unui sistem informatic care cuprinde aplicaii software pentru
automatizarea proceselor de lucru trece printr-o etap de analiz, n cadrul creia se
analizeaz modul de lucru al organizaiei n scopul configurrii aplicaiilor software la
specificul respectivei organizaii. Din punctul de vedere al modului n care se realizeaz
analiza proceselor de lucru, se pot diferenia dou abordri care depind de tipul aplicaiilor
software care se implementeaz:
1. Implementarea unor aplicaii COTS Commercial Off The Shelf (Comercial de pe raft)
2. Implementarea unor aplicaii dezvoltate la cerere.
1. Implementarea unor aplicaii COTS.
n cazul implementrii unor aplicaii standard (COTS), etapa de analiz are rolul de a identifica
acele informaii specifice organizaiei, care sunt necesare n vederea configurrii aplicaiei
software. Atunci cnd implementeaz o aplicaiei software COTS, beneficiarul urmrete, de
obicei, nu numai reducerea costului, a riscului i a costului implementrii prin utilizarea unei
aplicaii software a crei utilizare n organizaii similare a fost demonstrat cu succes n trecut.
Un alt obiectiv subsidiar al apelrii la o aplicaie software de tip COTS este, n multe cazuri,
faptul c aceste aplicaii ncorporeaz bune practici ale industriei pentru care sunt dezvoltate,
iar organizaiile care implementeaz astfel de aplicaii beneficiaz implicit i de aceste bune
practici. n cazul implementrii unui produs COTS, etapa de analiz este, de asemenea, o ocazie
pentru a depista eventualele diferene ntre modul de lucru specific organizaiei care dorete
implementarea aplicaiei COTS i fluxul de lucru al aplicaiei. n cazul n care astfel de diferene
sunt identificate, o decizie este necesar cu privire la modul n care implementarea va continua:
organizaia i va pstra modul de lucru actual, i atunci este necesar modificarea aplicaiei
software pentru a modela un proces de lucru diferit fa de cel standard, sau organizaia i va
schimba modul de lucru i va adopta noul proces de lucru pe care aplicaia l modeleaz.
Fiecare dintre aceste opiuni prezint att avantaje ct 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 reprezentani ai utilizatorilor s fie implicai n aceast decizie. Am vzut
multe proiecte a cror implementare este coordonat de reprezentani ai organizaiei IT, care
eueaz n luarea unor decizii strategice cu privire la schimbarea modului de lucru odat cu
implementarea unor sisteme informatice, considernd c procesele de lucru ale utilizatorilor
sunt primordiale, iar aplicaiile informatice trebuie s le modeleze exact.
6

Ctlin 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 situaii aceast abordare este ns una greit, deoarece multe organizaii opereaz cu
procese de lucru motenite, care nu au fost optimizate, iar simpla automatizare a acestora
prin informatizare nu face dect s automatizeze ineficiena.
Un alt caz care poate ns complica situaia descris mai sus este cel n care beneficiarul nu
alege cu bun tiin o aplicaie de tip COTS, ci aceasta i este oferit de ctre un furnizor ca
rspuns la o serie de specificaii documentate ntr-un caiet de sarcini. ntr-o astfel de situaie,
ateptarea beneficiarului este aceea c va beneficia de o aplicaie software care s i modeleze
ntocmai procesele de lucru, n timp ce furnizorul are constrngerea lucrului cu o aplicaie care
poate fi configurat, dar nu neaprat rescris.
Exiat multe situaii n care o astfel de diferen de abordare a provocat conflicte n cadrul
echipei comune de implementare, iar finalizarea proiectului s-a fcut cu ntrzieri mari i cu
concesii importante din partea ambelor pri.
Observaie. O practic frecvent pe piaa romneasc de ERP sunt add-on-urile. Se menine
soluia 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 dispoziie de ERP i
care se integreaz pe aceast platform. Add-on-urile sunt dezvoltate de firmele partenere
productorului sistemului ERP, care se ocup i de implementarea soluiei n ansamblu.
2. Implementarea unor aplicaii dezvoltate la cerere
n cazul implementrii unor aplicaii dezvoltate la cerere, etapa de analiz este una semnificativ
mai complex i de mai lung durat dect cea necesar pentru configurarea unui produs COTS.
n cadrul unei astfel de analize, echipa furnizorului trebuie s neleag i s documenteze toi
paii proceselor de lucru pe care noile aplicaii le vor modela, toi actorii implicai, regulile de
business aplicabile (precum i excepiile).
Executarea corect i complet a acestei etape este fundamental, ntruct noua aplicaie va fi
construit exclusiv pe baza informaiilor 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
identificrii acelor procese de lucru care pot fi optimizate, att prin eficientizare, ct i prin
informatizare. Odat identificate aceste oportuniti de optimizare, procesul propriu-zis de
modificare a proceselor de lucru trebuie gestionat cu atenie n cadrul unui sub-proiect de
business re-engineering, iar introducerea noilor procese optimizate trebuie nsoit de activiti
de management al schimbrii. Pentru a avea succes, o astfel de iniiativ trebuie susinut la
nivel managerial de ctre organizaia beneficiar, deoarece, n caz contrar, rezistena la
schimbare a utilizatorilor va fi mai mare dect influena pe care echipa tehnic de
implementare o poate avea.
Pentru a evita ns apariia unei rezistene 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 schimbri
(schimbarea modului de lucru i introducerea unui nou sistem informatic) poate fi mai mult
dect un utilizator mediu poate realiza cu succes. Am asistat la proiecte majore de
informatizare al cror obiectiv a fost deturnat datorit faptului c furnizorul i-a propus o
analiz exhaustiv a ntregului mod de lucru al organizaiei beneficiare i o optimizare a
proceselor odat cu dezvoltarea i implementarea noului sistem informatic.
Acest demers s-a dovedit a fi unul pgubos, deoarece echipele de analiz au fost copleite de
complexitatea proceselor de lucru ale beneficiarului, timpul necesar absorbiei corecte a
tuturor informaiilor n vederea identificrii unui mod optim de lucru a fost foarte lung i a dus
la prelungirea excesiv a etapelor de analiz i de proiectare, iar timpul rmas 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
gsit prghiile necesare pentru a fora luarea unor decizii care afectau modul de lucru.
Consultana 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 aplicaii software s fie precedat de un proiect de
consultan care s i propun exclusiv analiza proceselor de lucru existente, documentarea
acestora i identificarea potenialului 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
dect o firm a crei specializare const n dezvoltarea aplicaiilor informatice, avnd n plus i
avantajul unei obiectiviti crescute, neinfluenat de eventuale restricii tehnologice. De
asemenea, un astfel de proiect de consultan este perceput ca fiind unul de business, i nu
unul IT, astfel nct implicarea nivelelor manageriale de decizie este mai mare dect n cazul
unui proiect care are ca finalitate o soluie tehnic i care este, n cele mai multe situaii,
catalogat ca fiind unul IT, fiind astfel delegat spre implementare compartimentului IT al
organizaiei beneficiare.
Un alt beneficiu al unei astfel de abordri const n faptul c descrierea proceselor care vor
trebui automatizate poate fi prezentat potenialilor furnizori de servicii de dezvoltare software
ca parte a documentaiei de atribuire a contractului de dezvoltare a aplicaiei software, astfel
nct acetia 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
aplicaii informatice datorit slabei documentri a cerinelor n cadrul documentaiei de
atribuire i a diferenelor mari ntre ceea ce s-a solicitat i ceea ce trebuie de fapt implementat,
diferene 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 cte ori ne uitm peste statisticile pivind implementrile de sisteme ERP, ne ngrozim cnd
vedem cifrele mici care indic rate de succes de 20-30%. Firesc, ne intrebm: ce se ntmpl?
cum se msoar rata de succes? este adevrat i pentru piaa romneasca? 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:
clienii nu tiu ce cumpr, iar furnizorii nu tiu ce vnd.
Acest studiu ncearc s argumenteze ambele poziii, client furnizor, i s sugereze posibile
soluii la aceast problem cronic din industria ERP.
Perspectiva Beneficiarului
Dac intrebm 10 manageri dac decizia de achiziie privind un sistem ERP este aceeai cu
decizia de achiziie pentru alte investiii precum echipamente industriale, spaii de birouri,
maini, utilaje etc. vom primi 9 din 10 rspunsuri identice, previzibile, i anume da, decizia i
procesul de achiziie sunt aceleai. Cine s-a nelat? care este rspunsul corect? Din pcate,
avem un singur rspuns corect (n cazul fericit), un manager contientizeaz ca achiziia unui
sistem ERP este altceva dect achiziia altor bunuri. De ce n-ar fi acelai lucru i de ce totui
este altceva?
ERP-ul este un actor n cadrul organizaiei, care afecteaz toate procesele i care se infiltreaz
subtil n toate ungherele ei, schimbnd modul n care oamenii lucreaz, interacioneaz i i
desfoar activitatea de zi cu zi. Viaa ante ERP este diferit de cea post ERP. ERP-ul (nteles n
sens larg include i CRM, SCM etc.) face parte din ADN-ul organizaiei i trebuie s se modeleze
pe realitatea concret n care triete respectiva organizaie. Performana organizaiei este
influenat de performana sistemului ERP.
Beneficiarul se ateapt ca sistemul achiziionat s se plieze rapid, eventual chiar automat, pe
realitatea organizaiei, uitndu-se n momentul achiziiei doar la functionalitile 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 construcie al ERP-ului i nu funcionaliile influeneaz direct performana
sistemului ERP (i deci performana organizaiei). Beneficiarii cumpr functionaliti, ca o cutie
neagr, fr s neleag dac ERP-ul poate susine modelul organizaiei, pn 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 organizaia, ontologic i funcional, i ca atare aceast potrivire ntre
organizaie i ERP este greu de realizat.
Fcnd o paralel cu construirea unei case, suntem ntr-un scenariu n care beneficiarul
construiete o cas tiind ca are nevoie de 3 dormitoare, un living, o buctrie utilat, 2
7

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

33

balcoane, grdin exterioar etc. (adic funcionaliti ) fr s vad i s valideze arhitectura

i planurile constructive ale casei ! Se semneaz contractul, se stabilete bugetul i se ncepe
lucrarea, iar casa, croit din mers, v dai seama cum iese dup imaginaia fiecruia.
Concluzia 1. Achiziia unui ERP nu nseamn achiziia de functionaliti! Caietele de sarcini
pentru achiziia de ERP-uri, cu multe pagini de functionaliti, nu garanteaza nicidecum succesul
implementrii, chiar dac furnizorul reuete s bifeze toate funcionalitile din caiet. Este
mai important maparea planurilor constructive ale organizaiei cu cele ale sistemului ERP,
pentru a determina dac exist o potrivire ntre ERP i organizaie.
Perspectiva Furnizorului
Vnztorul de ERP intr n aceeai capcan i prezint beneficiarului functionaliti, pentru a-l
convinge c are produsul potrivit. Negreit functionalitile software sunt importante, dar nu
sunt hotrtoare i nici suficiente pentru a asigura potrivirea i succesul implementrii.
Vnztorul evit discuii tehnice despre arhitectur, pentru c majoritatea interlocutorilor sunt
persoane de business non-tehnice, iar abordarea plecnd de la planurile constructive ale
organizaiei nu i este la ndemn.
Vnztorul de ERP nu tie de fapt c el nu vinde funcionaliti, ci parte din performana
organizaiei care se sprijin pe un model organizaional, model pe care, din nefericire, furnizorul
nu l cunoate n timpul procesului de vnzare.
Altfel spus, furnizorul se confrunt cu realitatea organizaiei beneficiarului, pe care nu o
nelege apriori, iar tot ceea ce poate face este s lanseze presupoziii, susinute eventual de
experiene similare n alte companii cu profil asemntor. Dar, chiar n cazul unor companii din
acelai domeniu de activitate, acelai sistem ERP poate fi implementat cu succes ntr-un caz, iar
n alte cazuri poate fi un eec.
Aadar, doar experiena n alte organizaii similare nu garanteaz succesul, pentru c realitile
sunt total diferite de la o organizaie la alta, inclusiv modul de implementare a aceluiai model
organizaional.
Pe lng necunoaterea realitii i ncercarea de aliniere la ateptrile beneficiarului cu
prezentarea de functionaliti, vnztorul care ar trebui sa fie primul consultant de business al
beneficiarului se confrunt i cu presiunea concurenei 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 frustrri i nemulumiri pe parcursul implementrii.
Concluzia 2. Realitatea beneficiarului este o necunoscut pentru furnizor. Fr o validare
prealabil a modelelor de business, furnizorul semneaz doar un contract de promisiuni i
ateptri (sperane) pentru un soft care are o arhitectur i anumite funcionaliti.
Cum se poate iei din capcana de mai sus? Beneficiarul nu tie ce cumpr, 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 crete ansele de succes non-accidental,

cteva aciuni se impun nainte de semnarea final a contractului:
1. Beneficiarul s angajeze un proiect pilot pentru a valida nu doar funcionalitile, ci
i arhitectura (interfaa, flexibilitatea n modificri/adaptri, raportri), precum i
modelul pe care este construit organizaia. 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 susinute de
sistemul ERP.
3. Definirea clar a responsabilitii este i concluzia a treia responsabilitatea pentru
succesul implementrii este la beneficiar. El trebuie s gseasc i s numeasc
persoana (i echipa) responsabil cu implementarea. Furnizorul ofer sistemul, toate
serviciile de asisten (analiza, colarizare, asistena, etc.), dar organizaia este
cunoscut i administrat (pe toate planurile) cel mai bine de ctre angajaii ei i
nicidecum de un furnizor extern, care nu se poate substitui n procesele critice unde se
infiltreaz i sistemul ERP.
Concluzia final.
Pe lng motivele clasice pentru insuccesul implementrii project management i scheme
simplificate de bugetare necunoaterea realitii beneficiarului de ctre furnizor, inexistena
unor modele organizaionale care s fie validate nainte de implementare i neasumarea clar a
responsabilitii implementrii sunt cauzele principale pentru care succesul implementrii ERP
rmne o incertitudine.
Sumar
Sistemele informatice integrate de tip ERP au devenit omniprezente n cadrul organizaiilor, i
vor deveni din ce n ce mai importante pentru activitatea acestora n viitor. Managementul i
dezvoltarea lor reprezint componente eseniale ale performanei organizaionale, datorit
faptului c ele reprezint coloana vertebral a organizaiei moderne din punct de vedere
informaional.
Fenomenul ERP a luat amploare n anii 80. Aproape peste noapte, majoritatea companiilor
importante din economiile dezvoltate s-au grbit s implementeze sisteme de tip ERP, pentru a
nlocui sistemele informaionale vechi, greu de ntreinut, care ameninau s le afecteze buna
funcionare. Companiile se temeau c aceste sisteme vechi le-ar face mai puin competitive n
faa unor productori 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
reconfigurrii i optimizrii proceselor organizaionale interne.
n anii 90, companiile au avut de-a face cu provocarea de a reduce timpul de dezvoltare a
produselor, de a crete calitatea acestora, n timp ce reduc costurile de producie i scad timpul
de livrare ctre client. Aceste deziderate nu mai puteau fi atinse prin schimbri locale (la nivel
35

de departament sau divizie funcional) complexitatea provocrilor pe care trebuie s le

depeasc compania modern necesit strngerea legturilor i interdependenelor dintre
diverse procese de afaceri, de la finane la distribuie.
Odat cu apariia comerului electronic, companiile trebuie s fie capabile s planifice, execute,
controleze procesele organizaionale la fiecare moment dat. Avantajele obinute de companiile
care implementeaz soluii de tip ERP includ reducerea costurilor i stocurilor, n special prin
facilitarea fluidizrii operaiunilor acestora. Procesul nu se oprete ns aici, este extrem de
important ce fac companiile dup ce procesele lor de afaceri au fost fluidizate.
n acest sens, mbuntirea continu a sistemului informatic integrat din companie reprezint
o provocare semnificativ. Modul n care companiile gestioneaz evoluia sistemelor ERP odat
cu organizaia este o sarcin complex. n aceeai msur n care companiile se schimb, i
infrastructura informaional a acestora, bazat pe ERP, trebuie s reflecte aceste schimbri.
Managerii de top neleg procesul de mbuntire i exploatare a investiiei efectuate n ERP. n
organizaiile cu viziune, cel mai important ingredient al succesului i avantajului competitiv va fi
probabil calitatea integrrii dintre iniiativele de tip ERP i cele de tip comer electronic din
cadrul organizaiilor.

36