Unitatea de Învăţare 3 Implementarea Sistemelor ERP: Cuprins

Unitatea de învăţare 3
Implementarea sistemelor ERP

CUPRINS:
3.1 Mai întâi trebuie să fie nevoia… ........................................................................................................... 42

3.1.1 Prima întrebare: de ce? ................................................................................................................... 43
3.1.2 A doua întrebare: cât costă? ........................................................................................................... 43
3.1.3 Justificarea investiţiei: explorarea costurilor şi beneficiilor ........................................................... 45
3.1.4 Definirea cerinţelor ......................................................................................................................... 47
3.2 Selecţia furnizorului de ERP ................................................................................................................. 49
3.3 Implementarea sistemului ERP într-o organizaţie ................................................................................. 55
3.3.1 Metodologia de implementare ........................................................................................................ 56
3.3.2 Aspecte tehnice privind instalarea noului sistem ........................................................................... 62
3.3.3 Strategia de instruire a utilizatorilor ............................................................................................... 62
3.4 Utilizarea prototipurilor în implementarea sistemelor ERP .................................................................. 63
3.5 Modificarea aplicaţiilor – un compromis între procese şi funcţionalităţile software ............................ 64
3.6 Startul productiv .................................................................................................................................... 65
3.6.1 Problemele şi modul de rezolvare .................................................................................................. 65
3.6.2 Prima lună. revizuirea implementării ............................................................................................. 66
3.7 Îmbunătăţirea continuă .......................................................................................................................... 66
3.8 Modele de întrebări grilă ....................................................................................................................... 67
După parcurgerea acestui capitol ar trebui să:
 înţelegeţi importanţa deciziei de implementare a unui ERP,

 puteţi realiza bugetul unui proiect ERP,
 puteţi justifica investiţia ERP prin prisma beneficiilor şi a costurilor,
 înţelegeţi criteriile de selecţie a furnizorului de soluţii ERP,
 identificaţi etapele din implementarea propriu-zisă a unei soluţii ERP,
 distingeţi aspectele care au un impact mare asupra reuşitei unei implementări ERP (managementul
riscurilor, instruirea utilizatorilor ş.a.).
Timp de studiu: 4 ore

Câteva consideraţii preliminare
Moto-ul oricărui manager conştient de necesitatea unui ERP şi de riscurile asociate acestei iniţiative
trebuie să fie: Nu vreau să plătesc mai mult decât face, nu vreau sa cumpăr mai mult decât trebuie.
Procesul de implementare este cel mai important pentru reuşita unui proiect ERP. Succesul nu depinde de
şansă, cele trei condiţii esenţiale pentru implementarea reuşită şi utilizarea în condiţii de eficienţă maximă
sunt alegerea celei mai potrivite soluţii, educarea personalului şi planificarea resurselor. Literatura de
specialitate este vastă în acest domeniu. În această lucrare încercăm să găsim cel mai simplu demers de
descriere a procesului de implementare. După Stephen Harwood, ciclul de implementare a unei soluţii
ERP poate fi împărţit în patru faze mari:
1. determinarea necesităţii ERP,
2. selecţia furnizorului,
3. implementarea propriu-zisă,
4. îmbunătăţirea continuă (post-implementare).
Tabelul 3.1 prezintă structura demersului nostru. Ultima coloană face trimitere la paragrafele unde
au fost prezentate subiectele respective.
Tabelul nr. 3.1. Descrierea fazelor ciclului de implementare ERP

Faza Are în centrul atenţiei Activităţi
Determinarea  Necesitatea unui ERP Se determină necesitatea (de ce?)
nevoii de ERP  Costuri & beneficii Creare buget estimativ; evaluare beneficii
Sunt adunate cerinţele noului sistem
 Cerinţele
Selecţia  Ofertele de la Planificarea şi desfăşurarea procesului de selecţie; semnarea
furnizorului furnizori contractului
 Crearea condiţiilor
Implementarea pentru derularea
propriu-zisă proiectului
 Desfăşurarea planului
de implementare
 Instruirea
utilizatorilor
 Startul productiv
Îmbunătăţirea
continuă  Performanţa Îmbunătăţirea proceselor
proceselor
Cunoaşterea  Piaţa IT&C Urmărirea tendinţelor, înţelegerea noilor tehnologii şi a impactului
pieţei IT&C asupra afacerii, cunoaşterea principalilor furnizori
În desfăşurarea acestui ciclu este constantă conectarea la piaţa IT, cunoaşterea şi înțelegerea
noutăţilor şi tendinţelor.
3.1 Mai întâi trebuie să fie nevoia…

Această primă fază va da startul ciclului de implementare, chiar dacă vorbim de prima
implementare a unui sistem integrat sau un proiect succesiv, de upgrade sau extindere.
O altă denumire, utilizată frecvent în proiectele româneşti, este elaborarea unui studiu de
fezabilitate, care analizează toate ariile funcţionale implicate, defineşte cerinţele funcţionale, de
comunicaţie, disponibilitate şi securitate, apoi realizează o estimare a cheltuielilor de capital şi de
exploatare şi, în final, analizează oportunitatea investiţiei. Scopul acestui studiu este evaluarea eficienţei
scontată a fi obţinută în cadrul proceselor din întreprindere şi a impactului pozitiv al schimbărilor
organizaţionale rezultate din implementarea sistemului.
42
3.1.1 PRIMA ÎNTREBARE: DE CE?

Cineva, undeva, decide că e nevoie de un sistem informatic integrat în organizaţie. Cineva,
altundeva, decide că nu se poate implementa un sistem informatic integrat, deşi cel existent nu răspunde
cerinţelor managementului. În ambele cazuri s-a identificat nevoia de integrare informaţională şi s-a luat o
decizie. Oricare dintre cele două decizii trebuie să fie rezultatul unui proces de evaluare strategică a
afacerii şi nu al unui capriciu al managerului. O extravaganță de genul acesta poate costa scump
organizaţia, deoarece, din ignoranță, managerul nesocoteşte consecinţele acestei decizii: costurile
sistemului, costul timpului de implementare, riscul la care se expune firma dacă proiectul nu merge bine,
costurile de redresare, neatingerea beneficiilor aşteptate.
Instituirea nevoii de ERP este rezultatul unei introspecţii atente şi se poate constitui într-o
oportunitate, deoarece atunci când analizezi atent cum merg lucrurile poţi identifica un mod de a le
îmbunătăţi. În centrul atenţiei stau procesele şi nu tehnologia, de aceea se spune că implementarea unui
ERP determină schimbări organizaţionale. Abordarea centrată pe proces implică pe toată lumea şi efectul
său durează şi după startul productiv al sistemului nou, manifestându-se prin cultura orientată spre
îmbunătăţirea continuă. Tehnologia este un catalizator şi oferă multiple instrumente prin care
oportunitatea este valorificată.
3.1.2 A DOUA ÎNTREBARE: CÂT COSTĂ?

Practica a demonstrat că, dacă avem în vedere rezistenţa la schimbare, primul care se opune unei
iniţiative ERP într-o firmă este directorul financiar, care a auzit că pe această piaţă se vehiculează sume
exagerate. Lucrurile devin mult mai clare dacă, după identificarea necesităţii alinierii tehnologice prin
implementarea unui sistem integrat pentru afaceri, se iniţiază un buget estimativ. În faţa unui buget
estimativ orice manager poate evalua la rece posibilitatea de a începe un asemenea demers. Din lista
elementelor de cost nu trebuie să lipsească:
 echipamentele, evaluarea parcului existent şi estimarea necesarului (sunt foarte importante
performanţele serverului/serverelor ca şi volumul de date care este vehiculat în condiţii de maximă
activitate);
 sistemul de operare, evaluarea necesităţilor de up-grade;
 sistemul de gestiune a bazei de date;
 licenţe module ERP, inventarierea numărului de utilizatori de sistem;
 licenţe pentru aplicaţiile conexe (cele mai importante sunt cele cu baza de date);
 integrarea ERP cu terţele aplicaţii;
 personalizarea aplicaţiilor (costuri de dezvoltare);
 conversia datelor din sistemul existent;
 instruirea manegerilor şi a personalului, pregătirea administratorilor de aplicaţii ;
 managementul proiectului, pregătirea managerului de proiect;
 consultanţă externă, asistenţă din partea furnizorilor de platforme.
Experţii estimează că implementarea sistemului ERP va costa de până la 6 ori mai mult ca licenţele
software. Altfel spus, pentru 1 leu investit în software se cheltuiesc între 3-6 lei pe partea de
implementare. Totuşi, acest aspect devine din ce în ce mai puţin relevant dacă furnizorii oferă reduceri
substanţiale pe partea de software şi în condiţiile pătrunderii ofertei de open source ERP, caz în care
costurile de licenţiere sunt zero.
Costurile unui sistem ERP variază în funcţie de:
o mărimea întreprinderii (cifra de afaceri şi numărul de angajaţi);
o numărul de utilizatori ai sistemului;
43
o numărul de module implementate;

o componentele adăugate şi schimbările realizate la cererea beneficiarului.
Conform aprecierilor analiştilor de piaţă americani, preţul pe utilizator variază între 1000 şi 8000 de
dolari, cu tendinţe de scădere, datorate atât concurenţei, cât şi orientării către piaţa firmelor mici şi
mijlocii, cu putere financiară mai slabă. Pentru aceştia a apărut şi oferta de „pachet ERP", un sistem pre-
configurat, pre-instalat şi cu preţ fix, atractiv desigur.
O categorie aparte o constituie costurile indirecte, fiind de regulă costuri interne, generate de
„perturbarea" activităţii obişnuite de către proiectul ERP. Între acestea se pot regăsi:
 costul muncii prestate de angajaţii care preiau temporar sarcinile celor implicaţi în proiect;
 costuri induse de nedesfăşurarea unor activităţi sau costurile suplimentare presupuse de
desfăşurarea lor în alte condiţii;
 costuri legate de deplasări legate de proiect (vizite la furnizori/clienţi, instruire);
 costuri suplimentare presupuse de extinderea activităţii departamentului de IT.
În faza preliminară este dificilă conturarea unui buget estimativ, mai ales că multe dintre costuri
depind de soluţia ERP care va fi aleasă. Tocmai pentru a-i orienta pe manageri în această călătorie,
specialiştii au publicat diverse studii referitoare la costuri. Cea mai importantă concluzie este aceea că
bugetul unei implementări ERP reprezintă între 1% şi 3% din cifra de afaceri a organizaţiei. Cel
mai adesea, pragul de 3% este depăşit, fie „din prima", prin realizarea unui buget mai mare, fie pe parcurs,
din diverse cauze. Un sfat profesional şi totodată dezinteresat relativ la buget poate să vină de la un
consultant cu experienţă.
În ceea ce priveşte tipologia costurilor, ele se pot clasifica în: costuri iniţiale (hardware, conversie,
consultanţă, instruire) şi costuri continue (în principal de mentenanţă). Cu scopul de a crea o imagine mai
clară, proiecţia asupra costurilor trebuie să aibă un orizont mai mare (de preferat pe 5 ani). Specialiştii
apreciază că după această perioadă organizaţia ajunge într-un moment de revizuire a sistemului, optând
pentru un upgrade sau pentru extinderea lui.
Marele pericol al bugetării este subestimarea costurilor şi relevarea unor costuri neprevăzute,
mai ales dacă escaladarea costurilor are loc în plină desfăşurare a proiectului. Sunt sensibile în acest sens
costurile de customizare/personalizare. Singura soluţie care se prefigurează pe fondul lipsei unor fonduri
suplimentare este tăierea altor costuri, iar cele care suferă de obicei reduceri sunt cele de instruire. Şi cum
acestea sunt, tot de obicei, de la început, subestimate, consecinţele pot fi surprinzător de nemiloase.
Este superfluu poate, dar ne facem datoria să reiterăm nevoia de a asigura un control strâns al
costurilor. Un instrument foarte util este planificatorul inclus în platforma de management al proiectului,
care permite specificarea de costuri pentru resursele utilizate în activităţile planificate, ceea ce este util în
determinarea costurilor indirecte. În plus, programul actualizează permanent nivelul costurilor efectuate
deja, astfel că se pot observa eventualele dereglări.
44
3.1.3 JUSTIFICAREA INVESTIŢIEI: EXPLORAREA COSTURILOR ŞI BENEFICIILOR

Odată identificată nevoia şi estimate costurile, este momentul să se determine care sunt beneficiile
şi dacă acestea justifică investiţia. Problema e cum să măsori cât mai corect, dată fiind natura investiţiei.
Chiar dacă par mai palpabile, nu există nici o metodă infailibilă de determinare a costurilor
sistemului ERP din cauza faptului că în desfăşurarea proiectului există numeroase variabile, cum ar fi:
complexitatea afacerii, pregătirea companiei pentru schimbare şi ambiţia proiectului. Atunci când noul
sistem este subordonat unor obiective strategice, fiind menit să transforme şi să inoveze cele mai
importante activităţi, atunci proiectul va costa mult mai mult şi va fi implementat în mai mult timp faţă de
un proiect ancorat în obiective operaţionale. Un proiect ERP implică munca unui număr mare de oameni
care trebuie să lucreze împreună o perioadă mare de timp, într-un mod coordonat.
Nu toate beneficiile pot fi măsurate, de aceea trebuie luate în considerare cele cantitative. Cele mai
relevante sunt: reducerea stocurilor, scăderea cheltuielilor materiale, cu forţa de muncă şi indirecte,
îmbunătăţirea vânzărilor, un control mai bun asupra creanţelor. Practica implementării sistemelor ERP a
oferit posibilitatea de a măsura aceste beneficii, ceea ce oferă informaţii valoroase celor interesaţi. Valorile
estimate sunt prezentate în continuare:
 Reducerea stocurilor. Datorită practicilor de planificare şi programare îmbunătăţite se obţine 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) pe de o parte şi determină economii la
nivelului cheltuielilor asociate stocurilor (depozitare, manipulare, asigurare, perisabilităţi etc.);
 Reducerea cheltuielilor materiale. Într-un sistem ERP, cele mai bune practici sunt implementate
şi la departamentul de aprovizionare, sprijinind negocierea unor preţuri mai bune şi reducerea
costurilor cu cel puţin 5%. Sistemul perfecţionat de planificare permite utilizatorilor să-şi
concentreze eforturile asupra negocierii cu furnizorii şi ridicării calităţii şi oferă informaţii utile
negocierii, cum ar fi graficele de performanţă pentru furnizori. De asemenea, relaţiile cu furnizorii
sunt îmbunătăţite sub aspectul comunicării şi al „vizibilităţii"; furnizorii pot afla despre cererile
viitoare, asigurând creşterea eficienţei şi posibilitatea de a oferi preţuri mai mici unor comenzi
ferme;
 Reducerea cheltuielilor cu forţa de muncă. Sistemul îmbunătăţit de planificare a resurselor
susţine şi această reducere, apreciată la 10%. Optimizarea fluxurilor de materii prime şi materiale
va elimina timpii morţi şi perioadele de supra-aglomerare. Supervizorii au o imagine clară a
necesarului de forţă de muncă; îşi pot folosi mai bine timpul în activităţi de îndrumare şi instruire
a personalului, urmărind îmbunătăţirea calităţii resurselor umane;
 Îmbunătăţirea vânzărilor şi a relaţiilor cu clienţii. Mai buna coordonare şi corelarea producţiei
cu vânzările asigură îmbunătăţirea relaţiilor cu clienţii. Gestionarea eficientă a contactelor cu
clienţii, scurtarea perioadei de la comandă la livrare, respectarea termenelor duc la creşterea
satisfacţiei clienţilor şi implicit, creşterea vânzărilor – analiştii apreciază o majorare de cel puţin
10%;
 Control mai bun asupra contabilităţii şi creanţelor. Prin automatizarea fluxurilor, activităţile
sunt coordonate şi controlate de sistem – se reduc timpii de operare şi sunt minimizate erorile prin
introducerea doar o dată în sistem a unei date. Sistemul ERP asigură proceduri de colectare a
creanţelor mai ferme, ceea ce duce la reducerea facturilor cu termen de plată depăşit. Devine
posibilă cunoaşterea în timp real a fluxului de trezorerie şi previzionarea acestuia. În exprimare
cuantificabilă vorbim despre reducerea termenului de încasare a creanţelor cu 18-20% sau chiar
45
mai mult.
Beneficiile necuantificabile sau non-financiare ale unui sistem ERP pot fi văzute din mai multe
puncte de vedere. Pentru a ilustra unele dintre acestea, ne vom opri asupra beneficiilor în contabilitate,
design al produsului şi procesului de producţie:
 Efecte asupra contabilităţii. Cu ajutorul unei baze de date ERP, contabilitatea nu mai necesită
dosare în dublu exemplar şi este eliminată introducerea repetată a datelor. Pe măsură ce
tranzacţiile de producţie sunt înregistrate, echivalentele financiare sunt generate în mod automat
pentru a actualiza fişele conturilor. Aceasta oferă trasabilitate, mergând pe fir de la totalul din fişa
contului la documentele sursă, asigură informaţii financiare corecte şi actuale şi permite urmărirea
cheltuielilor reale faţă de cele bugetate. Activitatea tranzacţională detaliată poate fi, de asemenea,
uşor îmbunătăţită pentru a răspunde cerinţelor contabile. Procedurile contabile obişnuite şi cele de
închidere sunt realizate în minute sau ore, nu în zile sau săptămâni. Aceasta determină reducerea
muncii contabile şi a timpului destinat rapoartelor financiare. Totodată, rapoartele financiare pot fi
uşor modificate prin configurări rapide, pentru a răspunde cerinţelor factorilor de decizie;
 Efectul asupra produsului şi procesului de producţie. Fişierul cu date de bază păstrează
definiţiile produsului, oferind control asupra produsului şi procesului de producţie, în special în
ceea ce priveşte monitorizarea schimbărilor tehnologice. Schimbările planificate pot fi integrate,
iar modificările de urgenţă pot fi comunicate imediat. Costurile de producţie pot fi diminuate
folosind structuri ale produsului de ultimă oră. Simulări ale costului de producţie pot fi folosite
pentru a analiza impactul schimbării costurilor materialelor, ratei de muncă etc. Diferenţele dintre
costurile standard şi cele actuale sunt bine definite. Sistemele ERP oferă numeroase instrumente
analitice la dispoziţia personalului tehnic. Când se examinează impactul schimbărilor asupra
materialelor şi resurselor, spre exemplu, inginerii pot verifica informaţiile folosite pentru a
identifica produsele afectate.
Dacă aceste efecte ar putea fi, în cele din urmă cuantificate în termeni ce privesc economiile, sunt multe
alte beneficii necuantificabile care rămân aşa. De fapt, dacă privim din perspectiva orizontului de timp, cu
cât beneficiile sunt orientate spre viitor, cu atât creşte dificultatea de măsurare (vezi figura 3.1).
Figura nr. 3.1. Beneficiile intangibile
Aşa cum bine au observat unii specialişti, beneficiile importante nu vin din utilizarea efectivă a
ERP-ului, ci din transformarea organizaţională indusă de implementarea lui şi oportunităţile de
valorificare create. Sau, altfel spus, 90% din costuri şi beneficii revin bunurilor intangibile, create
prin investiţiile în software, educare şi transformări organizaţionale. S-a dovedit că valoarea unui
46
sistem nu se regăseşte în tehnologia informaţională înglobată, ci în modul în care tehnologia este

utilizată, atunci când ea devine un mijloc de realizare a unei strategii.
3.1.4 DEFINIREA CERINŢELOR

Această activitate se dovedeşte în multe cazuri una anevoioasă şi consumatoare de timp, deoarece
ea cere adunarea cerinţelor la un grad cât mai mare de detaliere – cam cum se umple o baniţă de grâu
adunând bob cu bob. Rezultatul trebuie să fie un document extrem de voluminos. Riscul cel mai mare
asociat acestei activităţi este schimbarea, deoarece procesele nu sunt statice. Se pune în mod legitim
întrebarea dacă această muncă migăloasă se justifică, deoarece transpunerea cerinţele identificate în noul
sistem operaţional va avea loc peste câtva timp (6 luni, chiar şi 1 an sau mai mult), fiind destul de probabil
ca atunci ele să se fi schimbat, mai mult sau mai puţin. Concluzia este că aceste cerinţe nu pot sunt în nici
un caz definitive.
Aflat într-o fază incipientă, proiectul se mai poate confrunta cu lipsa de interes (ca să nu spunem
direct respingere) din partea unor departamente care se declară mulţumite cu sistemele pe care le folosesc
momentan. Aceste deoartamente evită să formuleze cerinţe pentru un sistem nou. Sigur că dacă lucrurile
sunt privite din perspectiva lor, au dreptate, însă dacă le privim de sus, de la nivel organizaţional, este
altceva. Menţinerea vechilor aplicaţii trebuie să fie foarte bine justificată, deoarece costurile de integrare
pot fi exorbitante. Managerul desemnat şi echipa sa trebuie să aibă viziunea întregului, având misiunea de
a stabili aria de cuprindere a noului sistem.
Scopul activităţii este identificarea proceselor, descrierea lor şi a aspectelor cheie care trebuie
urmărite, iar rezultatul este o listă detaliată pentru fiecare proces analizat.
În practică există mai multe modalităţi de realizare a acestei activităţi – se pot utiliza instrumente de
analiză precum diagramele de flux sau diagramele de activităţi ori limbaje de modelare precum IDEF sau
UML. Cum cele mai multe firme nu au genul acesta de expertiză, au de ales între a apela la o firmă de
consultanţă (care au expertiza necesară, dar sunt străini de problemele firmei) sau a realiza definirea cu
mijloace mai rudimentare, dar având avantajul cunoaşterii intime a proceselor propriu-zise. După părerea
noastră, o variantă de lucru mixtă (puţină consultanţă, mai multă implicare internă, cu persoane
tinere, care pot asimila uşor noutatea instrumentelor de analiză specifice) este optimă.
Procesele unei organizaţii pot fi privite ca o reţea interconectată de cutii negre. Fiecare cutie neagră
transformă intrările în ieşiri, ieşirea unei cutii negre devine intrare pentru o alta. Examinând datele
colectate (intrările) şi rezultatele obţinute (ieşirile) ni se relevă natura transformării şi se poate denumi
corespunzător. Identificarea tuturor prelucrărilor şi a interdependenţelor permite realizarea unei hărţi a
proceselor, denumită diagrama de procese, care indică fluxul de activităţi în cadrul organizaţiei. Un
exemplu simplificat este prezentat în figura 3.2.
În realizarea diagramei de procese se cere parcurgerea tuturor proceselor, identificând scopul
fiecăruia, ce intrări se preiau şi ce ieşiri se obţin, care e sursa intrărilor şi care e destinaţia ieşirilor.
Intrările/ieşirile pot fi documente sursă primite sau trimise clienţilor/furnizorilor, documente interne,
planuri, rapoarte sau informaţii afişate pe ecran. Fiecare punct în care are loc o prelucrare este considerat o
cutie neagră (deoarece nu este descris modul de transformare sau algoritmul de calcul). Se înaintează pe
flux până la punctul final. Riscul acestei abordări este acela că se pot omite activităţi, din neglijenţă ori
necunoaştere. Diagrama oferă de principiu o imagine simplificată pentru ceea ce se întâmplă, riscul este ca
ea să fie incompletă.
47
Figura nr. 3.2. Exemplu diagramă de procese

(sursa: adaptare după Harwood S., ERP: The implementation cycle, Butterworh-Heinemann, Oxford, 2003, p. 59)
În practica implementărilor, după ştiinţa noastră, o astfel de analiză a cerinţelor nu se realizează

decât mai târziu, când se porneşte implementarea propriu-zisă.
Determinarea cerinţelor se reduce la culegerea acestora de la fiecare departament/birou, deoarece
ele sunt în final grupate din punct de vedere funcţional (contabilitate generală, vânzări, aprovizionare etc.).
Ele sunt exprimate sub formă de text (nu grafic) şi fac parte din documentul denumit caiet de sarcini.
Caietul de sarcini românesc este un document de aproximativ 80-100 de pagini (nu înseamnă că nu
poate avea mai multe sau mai puţine) care are în general următoarea structură:
 identificarea solicitantului (descrierea firmei, structura organizatorică, obiectul de activitate şi alte
aspecte descriptive);
 descrierea situaţiei existente (echipamentele deţinute, programele informatice utilizate, conexiune
Internet, alte tehnologii informaţionale şi de comunicaţii);
 obiectivele proiectului şi beneficiile estimate a fi atinse prin implementarea noului sistem;
 cerinţele generale ale sistemului informatic dorit;
 cerinţele specifice, în principal cerinţele funcţionale (acestea ocupă mai bine de jumătate din
numărul total de pagini – ideal ar fi 60%, pentru a furniza şi alte informaţii importante spre
informarea ofertanţilor). Pe lângă acestea, se pot formula cerinţe legate de instruirea utilizatorilor
sau cerinţe speciale de integrare (dacă sistemul ERP trebuie să fie integrat cu alte categorii de
aplicaţii), cerinţe legate de serviciile de mentenanţă;
48
Figura nr. 3.3. Extras din caietul de sarcini. Livrabilele solicitate.

(sursa: http://www.radiocom.ro/uploads/media/Caiet_sarcini_ERP.pdf)
 livrabilele care să fie cuprinse în ofertă – pentru a omogeniza ofertele şi a uşura compararea şi
evaluarea lor, definirea unei structuri cu livrabilele dorite este o idee foarte bună (figura 3.3);
 clauzele contractuale.
În demersul alegerii unui ERP, ar fi utilă o structurare a cerinţelor în funcţie de importanţa lor
pentru funcţionarea procesului în trei categorii: vitale, necesare şi utile (dacă se poate), ceea ce nu se
întâmplă, caietul de sarcini enumerându-le simplu.
Mai bun sau mai puţin bun, caietul de sarcini se foloseşte în practica implementării sistemelor
integrate în România. Ideal ar fi ca el să fie creat pe baza rezultatelor analizei proceselor de afaceri. Astfel,
managementul va fi sigur că acel caiet de sarcini va include toate cerinţele critice pentru fiecare proces. Cu
atât mai mult, analiza ar releva dificultăţi sau puncte slabe ale proceselor, iar cerinţele formulate pot să
conţină direct măsurile de corecţie necesare, pentru care ERP-ul va trebui să ofere soluţii.
3.2 Selecţia furnizorului de ERP

Odată ce a fost admisă necesitatea unui ERP şi au fost cumulate cerinţele, următorul pas va fi un
răspuns la întrebarea „cum pot fi puse în practică acele cerinţe". Primul gând ar fi găsirea unui furnizor de
soluţii informatice a cărui suită ERP să acopere întreaga listă de cerinţe. Şi s-ar găsi, doar că în cazul
furnizorilor de soluţii complexe – şi avem în vedere aici SAP sau Oracle – trebuie atent cântărite din start
aspecte practice precum timpul şi costul implementării. Pentru o firmă medie care are nevoie de un sistem
personalizat, adaptat unor cerinţe particulare, timpul şi costurile aferente unei implementări de la o casă
mare de software trebuie atent analizate, cu raportare la bugetul estimat.
Pe de altă parte, alegerea unei soluţii mai convenabile sub aspect financiar, dar cu sacrificarea
funcţionalităţii dorite este o alegere greşită – sistemul nou nu va furniza beneficiile aşteptate. Dacă oferta
unei case mari de software nu este accesibilă şi dacă nu se riscă succesul proiectului cu o soluţie de buget
mic, dar cu limite funcţionale, atunci se poate merge pe „best-of-breed", adică să alegi şi să combini cele
mai bune oferte din piaţă, pentru a crea soluţia dorită. Avantajul este că se obţine un grad înalt de
specializare, deoarece soluţia oferită înglobează expertiza dobândită de furnizorul ei, care s-a specializat
pe acea nişă de dezvoltare. Ideea este să se aleagă pachetul ERP de bază de la o firmă şi soluţia
49
specializată, specifică domeniului de activitate, de la altă firmă. Principala problemă aici este integrarea
dintre cele două soluţii, care trebuie să lucreze ca un singur sistem: ea trebuie să fie posibilă, iar costurile
ei să fie moderate. O practică frecventă pe piaţa românească de ERP sunt add-on-urile. Ideea porneşte de
la menţinerea soluţiei ERP la nivelul nevoilor generale (de bază) şi adaptarea ei la specificul diferitelor
industrii prin add-on-uri. Ele sunt concret module construite pe platforma pusă la dispoziţie de către ERP
şi care se integrează nativ pe această platformă. În acest fel se evită combinarea mai multor soluţii de la
mai mulţi furnizori, add-on-urile fiind dezvoltate chiar de firmele partenere producătorului soluţiei ERP,
care se ocupă şi de implementarea soluţiei în ansamblu.
Aceste două variante trebuie dezbătute înaintea demarării procesului de selecţie, pentru a stabili
dacă se caută un singur furnizor sau mai mulţi. Ar fi de menţionat aici că în România soluţiile „best-of-
breed" sunt rare, de altfel sunt puţini furnizori de soluţii de nişă, în condiţiile în care nu ar putea rezista pe
o piaţă încă imatură. Cei mai mulţi ofertanţi se străduiesc să prezinte soluţii complete cu care să poată
concura casele mari de software.
Furnizorul care va fi selectat nu doar livrează platforma, ci o implementează şi o personalizează în
firma client prin transferul de cunoştinţe şi expertiză către aceasta. Relaţia cu furnizorul va fi una de lungă
durată şi anume atâta timp cât vor fi folosite aplicaţiile în firmă. De aceea se spune că succesul proiectului
depinde (şi) de alegerea furnizorului.
Din practica acestei activităţi reiese că ar fi cam 5 moduri în care se realizează selecţia:
1. alegerea la noroc (dat cu banul);
2. alegerea pe bază de „cunoştinţe";
3. alegerea celei mai „titrate” soluţii;
4. subcontractarea activităţii de implementare;
5. compararea şi evaluarea riguroasă a ofertelor primite.
Prima situaţie se întâlneşte acolo unde nu se folosesc criterii de selecţie, ofertele sunt asemănătoare,
echipa de manageri nu ajunge la consens, iar „datul cu banul" rămâne singura cale de luare a deciziei.
A doua cale este poate cea mai păguboasă, în ciuda faptului că relaţia cu furnizorul va fi bună,
prietenoasă. Dat fiind criteriul de selecţie aplicat, este puţin probabil ca aplicaţia să fie cea mai potrivită
alegere, iar asta va afecta succesul implementării. Nu degeaba s-a inventat vorba „frate frate, da' brânza-i
pe bani".
Nici alegerea soluţiei celei mai elogiate nu este întotdeauna calea sigură de succes, dacă acesta este
singurul criteriu, căci aşa cum zice înţeleptul, „la pomul lăudat să nu te duci cu sacul".
Pentru a evita responsabilitatea alegerii şi a proiectului, unii subcontractează, adică trec întreaga
răspundere printr-un contract de prestare de servicii în sarcina unei terţe părţi, de regulă o firmă de
consultanţă. Evident, riscul de a obţine altceva decât propria concepție este mare, iar succesul este obţinut
la preţuri exorbitante (dacă subcontractantul este unul dintre The Big Four, să zicem, KPMG).
Ajungând la ultima variantă enumerată, n-o să surprindem pe nimeni spunând că este cea mai
indicată, deşi nu înseamnă că asta garantează succesul. E nevoie şi de un dram de noroc, uneori de sfatul
unui prieten sau de părerile avizate ale unui consultant independent.
Pentru a demara procesul de selecţie, este important să se stabilească echipa care va fi implicată în
luarea deciziei. Câteva aspecte de luat în considerare sunt:
o cine sunt beneficiarii noului sistem şi cum pot fi ei implicaţi în procesul de selecţie – ar fi bine
să fie incluşi, cel mai simplu prin reprezentanţi;
o proiectul ERP nu este un proiect IT, ci unul economic, specialiştii IT nu trebuie să predomine
numeric;
o toţi managerii cheie, din ariile funcţionale vizate, trebuie să participe la selecţie;
50
o încercând un demers democratic, se poate ajunge în extrema constituirii unei echipe prea
numeroase, ceea ce poate îngreuna acest proces;
o includerea unui consultant extern se face cu precizarea clară a rolului său în echipă, adică de
consultanţă, nu de decizie;
o participarea managerului general poate aduce echilibru, atâta vreme cât acesta îşi menţine
obiectivitatea;
o echipa poate fi elastică, în sensul de a implica mai multe persoane în primele faze şi de a o
restrânge în faza de selecţie finală.
Etapele necesare unui proces de selecţie sunt:  prospectarea pieţei;  crearea listei scurte de
furnizori potenţiali;  restrângerea listei;  selecţia finală. Durata acestui proces, aşa cum reiese ea din
practica proiectelor ERP, este între 4 şi 6 săptămâni, depinzând de gradul de cunoaştere al pieţei şi de buna
planificare a activităţilor. Este recomandată crearea unui plan de lucru şi utilizarea unui program de calcul
tabelar pentru colectarea datelor şi diferenţierea ofertelor primite.
Scopul este limpede, trebuie ales furnizorul şi implicit, soluţia ERP. Atingerea acestui scop solicită
cunoaşterea cât mai în amănunt a acestora. De aceea, am identificat două condiții care participă la o bună
selecţie: atenţia la detalii şi implicarea oamenilor. Identificăm de asemenea un patrulater al selecţiei, cele
patru laturi fiind constituite de: funcţionalitate, implementare, asistenţă (suport) şi costuri.
Latura 1. Funcţionalitatea are întâietate, de aceea trebuie să fie implicaţi cât mai mulţi dintre
viitorii utilizatori, pe toate ariile funcţionale, nu formal, ci solicitându-le să urmărească atent
caracteristicile funcţionale ale soluţiilor ERP aflate în triere. În acest fel ei vor avea sentimentul de
participare şi vor adopta mult mai uşor schimbările ce vor urma, cu responsabilitate. Dacă nu sunt
consultaţi, iar ulterior vor apare probleme în implementare, utilizatorii vor reproşa acest lucru şi vor
rămâne pe poziţii ostile faţă de noul sistem.
Mijlocul principal de realizare îl constituie sesiunile de prezentare sau demonstraţiile funcţionale.
Pentru a asigura comparabilitatea soluţiilor este indicat să se formuleze o AGENDĂ a acestor prezentări, în
sensul de a nu-l lăsa pe fiecare să prezinte ce vrea, cum vrea. Agenda va fi transmisă din timp fiecărui
furnizor, iar o cu bună pregătire din partea beneficiarului, se poate cere ca demonstraţia să se facă cu
datele sale (transmise anticipat în format electronic). În ziua prezentării se vor distribui participanţilor FIŞE
DE EVALUARE, prin care ei îşi vor exprima opiniile asupra celor văzute. După ce au avut loc toate
demonstraţiile, vor fi adunate şi centralizate fişele de evaluare, iar rezultatele vor fi sintetizate într-un
raport.
Avantajele acestei abordări sunt:
o folosirea agendei comune asigură comparabilitatea între soluţiile analizate;
o demonstrarea funcţionalităţilor cu datele proprii va fi confortabilă pentru utilizatori şi îi va
ajuta să înţeleagă mai bine procesele prezentate;
o implicarea cât mai multor utilizatori finali înseamnă identificarea eventualelor slăbiciuni,
vizibile doar pentru cei familiarizaţi cu un domeniu funcţional anume;
o examinarea rezultatelor obţinute din centralizarea fişele de evaluare se poate realiza în cadrul
unui grup de discuţii mai restrâns – participarea largă trebuie asigurată doar la sesiunile de
prezentare.
Un sistem ERP este, după cum se ştie, complex sub aspect funcţional, de aceea această activitate
este anevoioasă. Cum sistemele ERP au evoluat continuu în privinţa funcţionalităţii, există tentaţia de a
presupune că orice sistem „bun" acoperă activităţile operaţionale de rutină. Recomandarea specialiştilor
pentru beneficiari ar fi să nu acorde această prezumţie şi să exploreze sistemele pe care doresc să le
achiziţioneze înainte de a semna contractul.
51
Pe lângă complexitatea funcţională, tot prin sesiunile de prezentare trebuie investigate şi alte
aspecte legate de exploatarea aplicaţiilor, cum ar fi:
 interfaţa grafică utilizator: uşurinţa de navigare; intuitivitatea ecranelor; adaptabilitatea
formatelor de ecran şi a rapoartelor; exportul de date în format Excel, Word sau PDF etc.
 conectivitatea BD (ODBC sau alte standarde); gestiunea tabelelor – adăugarea de câmpuri noi;
culegerea datelor prin alte metode decât introducerea directă; interfaţă Web; generator de rapoarte;
instrumente de analiză a datelor (cum este OLAP); instrumente de workflow; uşurinţa/dificultatea
customizării aplicaţiilor etc.
 alte aspecte legate de administrarea sistemului, precum platforma de baze de date, managementul
performanţei, securitatea şi managementul utilizatorilor, scalabilitatea, managementul locaţiilor de
instalare etc.
La un moment dat, aspectele funcţionale trebuie corelate cu tehnologia pe care acestea sunt
construite. Deşi sesiunile de prezentare aşa cum le-am expus par a fi gândite doar pentru utilizatorii finali,
ele se adresează şi specialiştilor IT. Lor le revine sarcina de a evalua soluţia din punct de vedere tehnic
(am enumerat mai sus câteva aspecte urmărite). În acest sens, considerăm că este ideal ca demonstraţiile
făcute de furnizori să aibă două părţi:
o în partea I să participe utilizatorii finali şi să evalueze funcţionalităţile şi interfaţa grafică
utilizator din punctul lor de vedere,
o în partea a II-a să vină specialiştii din departamentul IT, vizând aspectele legate de
exploatarea aplicaţiilor.
În fine, este necesară în acest context o discuţie despre riscurile tehnologice care pot apare în cazul
fiecărei soluţii luate în discuţie. Pe de o parte, aşa cum mulţi bărbaţi trebuie să aibă ultimul model de
smartphone, multe firme sunt tentate de noutăţile tehnologiei IT&C. Dacă în primul caz, riscul asumat este
personal şi mic, în cazul firmei, ea riscă un eşec al proiectul ERP datorat adoptării unor tehnologii
insuficient testate. Pe de altă parte, nu este recomandat să se accepte soluţii tehnologice învechite,
deoarece ele limitează posibilităţile de dezvoltare ulterioară a sistemului informatic. Este o chestiune care
cere o analiză atentă şi bine documentată.
Latura 2. Dacă funcţionalitatea vine prima ca relevanţă pentru utilizatori, pentru managerul de
proiect supremația o deţine implementarea. Solicitând tuturor furnizorilor aflaţi în cursă informaţii,
echipa managerială va afla dacă:
o metodologia are o abordare structurată;
o sunt definite clar etapele de parcurs, fiecare etapă fiind divizată în activităţi clare şi
neambigui;
o sunt clar definite livrabilele şi punctele de transfer între activităţi.
Scopul este de a reduce probabilitatea ca proiectul să scape de sub control. O metodologie
structurată înseamnă o secvenţă coerentă de etape, în care sunt delimitate activităţi, pe care sunt asociate
persoanele implicate şi alte resurse, livrabilele, dar şi orizontul de timp planificat.
Eficienţa metodologiei de implementare depinde mult de experienţa furnizorului – aici contribuie în
egală măsură implementările reuşite şi cele eşuate. Identificarea greşelilor ce pot apare într-o
implementare şi tratarea lor duc la anticiparea unor situaţii şi la evitarea repetării lor în implementările
viitoare.
Se cuvine să facem aici o menţiune legată de metodologiile de implementare rapidă. Tentaţia de a
reduce semnificativ timpul de implementare poate fi foarte mare, dar la fel de mare este insuccesul dacă se
dovedeşte o decizie proastă. O metodologie de implementare rapidă înseamnă adoptarea unei soluţii pre-
configurate pe profilul unei anume industrii (verticală). Dacă beneficiarul este o firmă mică-medie, într-un
52
domeniu de activitate care nu are mari particularităţi de la o firmă la alta, alegerea se poate dovedi
câştigătoare. Pentru o firmă medie-mare, unde creşte complexitatea proceselor, nu este recomandată
implementarea rapidă, deoarece particularităţile pot genera situaţii fără ieşire, în sensul că nu poţi merge
înainte, dar nici nu te mai poţi întoarce.
Latura 3. Asistenţa din partea furnizorului este importantă în faza de implementare, dar şi în faza
post-implementare:
 Pe tot parcursul implementării furnizorul trebuie să asigure transferul de cunoştinţe către
beneficiar, să îi îndrume pe utilizatori şi să asigure soluţionarea rapidă a problemelor ivite. Se
doreşte ca furnizorul să fie o prezenţă apropiată în perioada de implementare, de aceea se vor
discuta cu furnizorii aspecte legate de numărul de consultanţi pe care îi va aloca proiectului,
experienţa lor în proiecte similare, modul de interacţiune cu utilizatorii (în timpul programului,
dar şi variante de contactare în afara orelor de program, în caz de urgenţă);
 După startul productiv urmează după cum se ştie o perioadă grea pentru firma beneficiară, de
adaptare cu noul sistem, iar cei mai afectaţi vor fi utilizatorii. Trebuie să se negocieze prezenţa
consultanţilor în primele câteva luni după go-live, pentru a rezolva prompt problemele apărute.
Chiar dacă se consideră că instruirea va fi bine făcută, pe parcursul mai multor sesiuni, lucrul „în
productiv" creează mereu emoţii angajaţilor. Un minim de suport este necesar, iar dacă distanţa
fizică este prea mare, deci şi cheltuielile induse de deplasare, există astăzi variante mai economice
de acțiune: prin telefon, e-mail sau messenger, iar în caz de urgenţă prin intervenţie de la distanţă
(conectarea remote a consultanţilor aflaţi în alte locaţii).
În examinarea acestor aspecte, pe lângă discuţiile sau informaţiile primite de la furnizori trebuie
avute în vedere opiniile clienţilor existenţi, care sunt determinante pentru formarea unei imagini obiective.
Latura 4. Costurile nu sunt analizate aici sub aspectul mărimii, se presupune că sunt este deja
cunoscute, iar furnizorii selectaţi până în această fază au oferte care se încadrează în limita de buget
convenită. Ceea ce îl preocupă acum pe client este: „ce obține în schimbul banilor". Se urmăreşte nu să se
găsească soluţia „cea mai ieftină", ci aceea care oferă cel mai mult pentru preţul plătit. Sigur că se porneşte
cu punerea faţă în faţă a tuturor ofertelor, având grijă să se asigure comparabilitatea prin introducerea unor
categorii clare de costuri. O propunere de defalcare a costului total de deţinere conţine: costuri cu
echipamentele; cu sistemul de operare; de licenţiere pentru SGBD; de licenţiere a modulelor ERP; de
licenţiere pentru alte aplicaţii necesare; de integrare între modulele ERP, alte aplicaţii necesare şi/sau
aplicaţiile existente; de personalizare; de conversie a datelor din vechiul sistem; aferente managementului
de proiect; de consultanţă; de instruire; de deplasare; de mentenanţă pentru primul an.
Pe lângă aceste costuri, care alcătuiesc bugetul proiectului, trebuie să se discute şi să se negocieze
costurile care apar post-implementare: taxa fixă de mentenanţă (procent din costul licenţelor software);
costuri de consultanţă/instruire (tariful pe om-oră); costuri de dezvoltare a unor cerinţe suplimentare
(tariful pe om-oră pentru programator şi pentru analist).
Beneficiarul trebuie să încerce să negocieze anumite costuri, dar să fie la curent cu nivelul preţurilor
practicate pe această piaţă, pentru a nu fi ridicol în anumite situaţii. Managerul financiar trebuie să se
informeze ori să apeleze la serviciile unui consultant de specialitate independent.
Un alt aspect deosebit de important, deşi la început poate părea irelevant este negocierea condiţiilor
de plată. Un furnizor care solicită plata la anumite momente a unor tranşe din suma totală nu poate fi
credibil. De asemenea, oferirea de reduceri pentru plata în avans este şi ea inacceptabilă, chiar dacă pare
ispititor. Plata către furnizor trebuie să se facă în mai multe tranşe, la termene care sunt corelate cu fazele
proiectului. Altfel, beneficiarul se poate trezi în situaţia că a plătit 80% din valoarea contractului, dar
53
furnizorul a livrat doar 50% sau chiar mai puţin. Termenii de plată se vor decide la semnarea contractului,
dar o discuţie prealabilă despre aceştia este necesară.
În final, aducem în discuţie şi variantele de implementare prin ASP (Application Service Provider),
SaaS (Software as a Service), cloud computing sau bazate pe alternativa open source, care pot oferi
economii semnificative. Aceste variante trebuie serios discutate cu specialiştii, luând în calcul toate
aspectele, deoarece avantajul economiei trebuie pus în balanţă cu dezavantajele acestor modalităţi de
implementare a sistemelor informatice.
Alte aspecte. Pe lângă cele patru laturi de parcurs, patrulaterul selecţiei are şi diagonale, pe care pot
fi plasate alte aspecte elocvente pentru realizarea unui portret cât mai fidel al fiecărui furnizor analizat.
Trecând peste figura de stil, vrem să oferim şi alte repere care pot fi utilizate, în special pentru
departajarea în caz de egalitate:
 Credibilitatea şi reputaţia firmei furnizorului. O schiţă a fost realizată în faza premergătoare,
informaţiile pot fi completate pentru a obţine portretul. Clientul trebuie să fie sigur că furnizorul
ales este o firmă solidă, cu o poziţie bună pe piaţă, respectat în domeniul în care activează. Dacă e
o firmă de top, cu experienţă bogată, e o garanţie a expertizei sale. Dacă e o firmă mai mică,
ambiţia de a creşte îi poate motiva să se implice cu seriozitate în proiect. Ambele alegeri pot fi
corecte, ambele au un anume grad de risc incorporat;
 Experienţa de implementare în domeniul de activitate al clientului. Şi acest criteriu a fost
propus anterior, el merită revizuit în scopul de a legitima alegerea unui furnizor în faţa altuia.
Simpla enumerare a implementărilor anterioare nu este satisfăcătoare, cea mai bună mărturie vine
din partea clienţilor. Vizitele la clienţi pot să ofere multe informaţii care să documenteze şi alte
criterii de selecţie urmărite;
 Strategia pe termen mediu-lung. Este un reper al viabilităţii furnizorului, pe o piaţă aflată într-o
continuă mişcare, unde firmele mici abandonează adesea lupta, fiind preluate de cele mari. Dacă
furnizorul are o viziune, direcţii de acţiune expuse într-o strategie, dacă investeşte în cercetare-
dezvoltare, dacă încheie parteneriate cu numele mari, toate acestea susţin ideea că el se va
dezvolta în anii următori, iar soluţia pe care o promovează va fi întreţinută şi dezvoltată la rândul
ei. Dacă furnizorul analizat este un integrator de servicii, o firmă care se ocupă doar cu
implementarea şi mentenanţa platformei, atunci trebuie investigată poziţia pe piaţă a firmei care
dezvoltă ERP-ul şi strategia lor;
 Intuiţie şi inspiraţie. Experienţa în afaceri, în negociere în particular, îşi poate spune şi ea
cuvântul în alegerea finală.
Pentru a asigura comparabilitatea datelor despre furnizorii evaluaţi, se pot utiliza mai multe metode.
Cea mai simplă este metoda scorurilor, care presupune notarea fiecărui criteriu pe o scară de valori,
obţinerea scorului prin ponderarea fiecărei note cu un procent din total şi adunarea acestor scoruri la final.
Metoda are popularitate pentru că e simplă, dar şi pentru că e flexibilă, deoarece ponderile sunt stabilite
după propria judecată – se acordă pondere mai mare sau mai mică după cum se consideră. Ca instrument
de lucru, cel mai potrivit este fără îndoială Excel, având facilităţile de calcul rapid, cu posibilităţi de
simulare dacă e nevoie, datele pot fi generate de mai multe persoane din echipa de selecţie şi apoi
consolidate într-un singur raport.
Obţinerea acestui raport final de evaluare, care conţine scorurile calculate pentru furnizorii evaluaţi
este o muncă dificilă, dat fiind că implică numeroase criterii de apreciat şi numeroase persoane care au sau
cred că au ceva de spus. O să încheiem cu un sfat pentru managerii ce trebuie să-şi asume alegerea făcută.
Există două căi sigure spre dezastru: să asculţi de toată lumea şi să nu asculţi de nimeni.
54
3.3 Implementarea sistemului ERP într-o organizaţie

Primele semnale de alarmă legate de abordarea implementării unui sistem integrat au fost făcute
publice încă din anii '80, când multe proiecte MRP II au eşuat sau nu şi-au atins obiectivele. Un studiu
realizat în anul 1994 de o firmă britanică de cercetare a pieţei a indicat că rezultatele implementărilor de
MRP II se caracterizează prin:
o 51% dintre ele au durat mai mult decât a fost planificat;
o 28% au avut depăşiri semnificative ale bugetelor stabilite;
o în 68% din cazuri au fost modificate aplicaţiile (personalizări);
o 56% au avut probleme operaţionale la startul productiv datorită instruirii insuficiente;
o 25% nu au obţinut beneficiile aşteptate;
o 28% nu ştiau exact care sunt beneficiile ce le vor obţine după implementare!
În ciuda acestor semnale, în anii ce au urmat, cu proiecte de integrare ERP, mai vaste şi mai
complicate decât MRP II, s-au repetat multe din greşelile „cunoscute", iar numărul proiectelor în care se
înregistrează depăşiri de buget şi de timp ori insatisfacţie după lansarea noului sistem este în continuare
mare.
Sigur că multe lecţii din cronica implementărilor de ERP au fost însuşite şi învăţămintele trase,
astfel că a crescut numărul proiectelor înfăptuite. Ne-am ferit să folosim cuvântul succes, căci rămâne în
continuare în dezbatere ce înseamnă succesul unei implementări şi, mai ales, când se spune despre o
implementare că a eşuat. Se poate afirma că un proiect finalizat la termen şi încadrat în buget este un
succes din perspectiva managerului de proiect. Acelaşi proiect, din perspectiva managerului economic este
un eşec dacă nu sunt atinse beneficiile estimate ori sunt nerezolvate cerinţe operaţionale care fac sistemul
ineficient.
Demonstrarea eşecului este mai simplă decât a succesului, la fel cum evitarea eşecului este mai
uşoară decât dobândirea succesului. Ceea ce au în comun ambele acţiuni este factorul uman, analiştii au
căzut de acord că problemele tehnice au rezolvare (uşoară ori anevoioasă), pe când cele legate de oameni
pot fi incurabile şi trebuie tratate cu mult mai multă considerație. Multe dintre motivele asociate cu
insuccesul unui proiect ERP sunt legate sau depind de oameni:
 top-managerii: nu sunt prezenţi, nu înţeleg ori nu se implică;
 utilizatorii nu sunt educaţi şi motivaţi, deci nu se implică;
 managerul de proiect nu are experienţă;
 managerul financiar nu înţelege de ce să suplimenteze bugetul în loc să taie din cheltuielile de
instruire;
 echipa proiectului nu include persoanele potrivite;
 comunicare defectuoasă în echipa de proiect (mai ales î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;
 conducerea slabă a proiectului din partea beneficiarului, prin alegerea unui manager de proiect
slab, ezitant, influențabil, incapabil să ţină proiectul în mână.
Toate aceste probleme se manifestă pe fondul unei culturi organizaţionale precare, fragilă la
schimbare. Fără îndoială că există culturi organizaţionale care favorizează adoptarea schimbărilor bazate
pe tehnologiile informaţionale, ca şi culturi care le frânează ori chiar le resping. Dar despre toate acestea şi
altele în plus vom vorbi în capitolul 4.
55
Revenind la motive, pe lângă cele de mai sus, eşecul va surveni atunci când cerinţele sunt definite
pe fugă, inconsistent şi imprecis, la fel procesele de afaceri sunt neclare şi confuze şi, firește, atunci când
s-a făcut o alegere îndoielnică a soluţiei ERP.
Să încheiem optimist acest preambul, spunând că alegerea fundamentată şi serioasă a furnizorului
de ERP şi consideraţia pentru factorul uman creează premizele unei implementări reuşite.
3.3.1 METODOLOGIA DE IMPLEMENTARE

Într-o exprimare elementară realizarea unei implementări parcurge următoarele etape:
 cunoaşterea desăvârșită a organizaţiei şi activităţii sale;
 cunoaşterea plenară a soluţiei software, ce poate să facă, ce nu poate să facă, până la ultimul
detaliu;
 maparea proceselor economice, pornind de la cum sunt acum la cum vor fi de acum încolo
(redefinirea lor de la zero dacă e cazul);
 configurarea proceselor în software pe aplicaţii pilot şi iterarea până când se obţine rezultatul
dorit;
 instruirea utilizatorilor şi documentarea sistemului;
 startul productiv;
 corecţii şi revizuiri.
Un proiect ERP este caracterizat prin mediu de lucru, o structură de organizare, un spirit de echipă
şi un plan coerent de activităţi, cu termene, resurse şi livrabile.
3.3.1.1 Organizarea proiectului
Persoana care îşi asumă responsabilitatea proiectului este managerul de proiect. În organizaţiile
mari, el răspunde în faţa unui comitet director alcătuit de managerii cei mai influenţi, căruia îi raportează
periodic statusul şi care poate delibera în anumite situaţii de conflict. Acest comitet este condus de top-
manager (director general sau altă denumire pentru funcţia cea mai mare din firmă), care trebuie să-şi
asume misiunea de sponsor al proiectului (în unele prezentări este denumit finanţator al proiectului).
Deşi pare că cea mai importantă persoană este managerul de proiect, rolul cheie revine directorului
general. În primul rând el trebuie să conceapă viziunea organizaţiei şi să promoveze inovarea bazată pe
noile tehnologii informaţionale. Directorul general trebuie să insufle tuturor curajul şi atitudinea favorabilă
schimbărilor organizaţionale, în mod special managerilor de mijloc şi celor cu atitudine conservatoare. Cu
realism, el poate convinge echipa managerială de nevoia de inovare, de reinventare a firmei, pe fondul
unei economii globale, deosebit de dinamice. În contextul proiectului ERP, este indispensabil ca directorul
să devină sponsor al proiectului, adică să îl sprijine cu convingere şi implicare. Acest rol devine după
părerea noastră determinant într-o implementare la scară mare, căci cu cât organizaţia este mai mare, cu
atât mai greu va fi de coordonat proiectul. Top-managerul nu doar promovează proiectul şi îl susţine pe
managerul de proiect, ci intervine şi pentru legarea echipei la nivelul managerilor de mijloc, ca mediator în
incidente şi conflicte. Implicarea activă îi va confirma temerile atunci când proiectul are o direcţie greşită,
prin poziţia sa el poate acționa şi impune măsurile necesare pentru redresare, inclusiv schimbarea
managerului de proiect.
Managerul de proiect are misiunea de catalizator, căci el face lucrurile să se întâmple, dar este şi
administrator căci va elabora planul proiectului şi va înregistra progresul acestuia şi sub aspect birocratic.
Însuşirile şi aptitudinile unui manager de proiect sunt:
o bun cunoscător al organizaţiei şi membrilor acesteia;
o educat în domeniul software şi tehnologii informaţionale;
56
o abilităţi de comunicare;
o diplomat şi negociator priceput;
o persoană organizată;
o onest şi leal organizaţiei;
o rezistent la presiune şi greutăţi (şi „cu obrazul gros" cum spune românul);
o influență şi charismă.
Este limpede că acesta este profilul managerului ideal şi că nu este posibil ca în fiecare organizaţie
să existe o persoană care să întrunească toate aceste calităţi. El este numit de directorul general, iar acesta
din urmă trebuie să aleagă o persoană în care are încredere şi care are cât mai multe dintre calităţile de mai
sus.
Proiectul se derulează în paralel cu activitatea normală a firmei, iar personalul implicat nu poate fi
degrevat de sarcinile zilnice. La un moment dat pot apare conflicte asupra priorităţii: proiectul este
important, trebuie respectate termene, dar asta nu înseamnă că firma nu lucrează în acest timp. Diplomaţia
managerului de proiect şi influenţa sa în rândul angajaţilor îl pot ajuta să depăşească aceste vârfuri de
sarcină.
Rolul managerului de proiect este dificil şi prin prisma poziţiei sale de lider al echipei de proiect pe
care o alcătuieşte. Echipa proiectului este mai mult decât un grup de persoane care colaborează şi
lucrează împreună, este esenţial să aibă la bază un set de valori care promovează ascultarea, răspunsurile
constructive şi recunoaşterea meritelor celorlalţi, independent de poziţia lor ierarhică în cadrul
organizaţiei. Pe scurt, o echipă de succes se obţine prin: eliminarea individualităţilor, bună coordonare şi
coeziune şi leadership. Caracteristicile care contează pentru membrii echipei sunt: instruiţi, deschişi la
minte şi cu dorinţă de a învăţa, la care s-ar mai adăuga creativitatea şi abilităţile analitice. Expertiza
fiecăruia într-o anumită arie funcţională este utilă, dar se va dovedi insuficientă, căci abordarea pe procese
depăşeşte barierele funcţionale. Membrii echipei trebuie să înţeleagă în amănunt modul în care
funcţionează aplicaţiile în conexiune cu funcţionalităţile specifice organizaţiei, astfel că oarecare
experienţă în software-ul pentru afaceri este utilă.
Un obstacol major în alcătuirea unei echipe ideale este disponibilitatea oamenilor. De obicei, cei
mai buni oameni sunt şi cei mai ocupaţi şi cu cât organizaţia este mai mică, cu atât mai critică este
alcătuirea echipei. Formarea echipei trebuie să asigure un echilibru între valoarea oamenilor şi
disponibilitatea lor. Oamenii de valoare trebuie atraşi, iar implicarea lor trebuie (re)compensată
corespunzător, căci vor surveni ore suplimentare şi sfârşituri de săptămână sacrificate pentru proiect.
Echipa de proiect se constituie deci din cele mai potrivite persoane (pe profilul prezentat mai sus),
având fiecare competenţe pe ariile funcţionale afectate de noul sistem. Astfel, o echipă poate avea între 5
şi 10 membri, fiecare reprezentând un departament: Vânzări şi marketing, Producţie, Aprovizionare,
Financiar, Contabilitate, Resurse umane, Cercetare-dezvoltare, Asigurarea calităţii etc.
Misiunea echipei este cea mai relevantă pentru succesul proiectului, dacă ne gândim că membrii
desemnaţi sunt autorizaţi să restructureze procesele economice şi să le organizeze pe noua structură a
sistemului ERP ales. Cunoaşterea temeinică a proceselor şi înţelegerea cerinţelor funcţionale de către
membrii aleşi contează enorm, de aceea membrii echipei trebuie să se consulte permanent şi îi pot aduce la
discuţii pe utilizatorii cheie sau managerii operaţionali.
Pe lângă specialiştii din zona de afaceri, echipa include şi cel puţin un specialist IT, care să se
ocupe de aspectele tehnice (dacă e o firmă mare, el va avea în subordine propria echipă IT). El va
răspunde de instalarea echipamentelor şi a aplicaţiilor, de întreţinerea lor, de conexiunile de reţea şi
securitatea sistemului. Prin natura sarcinilor sale, el va participa doar acele şedinţe la care opiniile sale
sunt necesare.
57
În ceea ce priveşte mediul de lucru, este ideal să existe un spaţiu dedicat proiectului, în care să
poată lucra toţi membrii echipei fără a fi deranjaţi. Biroul respectiv ar trebui să ofere suficient spaţiu pe
pereţi, unde se pot plasa schemele, diagramele şi alte planşe utile discuţiilor. Evident, nu trebuie să
lipsească din încăpere conexiunile Internet şi eventual staţii de lucru dacă nu se preferă laptopuri. În
funcţie de dimensiunea proiectului, sala poate fi utilizată şi pentru desfăşurarea sesiunilor de instruire.
3.3.1.2 Planul de proiect
Planul de proiect va oferi informaţii despre: cine, ce, de ce, unde, când şi cum, fiind rezultatul
discuţiilor între cei avizaţi şi al negocierilor de resurse, termene şi costuri. Cel mai bun plan de proiect este
cel care este realist, în special în ceea ce priveşte termenele. Rolul său este acela de călăuză şi, în al doilea
rând, de monitor al progresului. Planul coordonează acţiunile tuturor celor care lucrează, semnalând
întârzierile şi aducând măsuri corectoare.
În planul de proiect sunt cuprinse toate activităţile, grupate de obicei pe faze şi încadrate în timp.
Instrumentul utilizat este fie Excel, fie un program specializat cum este Microsoft Project. Avantajul celui
de-al doilea este facilitarea mai multor vederi asupra proiectului şi a obţinerii de diverse rapoarte şi este
indispensabil în desfăşurarea proiectelor complexe.
Figura nr. 3.4. Planul general de implementare ERP

(adaptare după Harwood S., ERP: The implementation cycle, Butterworh-Heinemann, Oxford, 2003,
p. 106)
Ipotetic, am conturat un plan general de implementare în figura 3.4. În această variantă el este util în
faza de organizare a proiectului şi constituie punctul de plecare în planificarea de detaliu. În figura 3.5 este
prezentat tot un plan general, desfăşurat pe 24 de luni, care surprinde întreg efortul dedicat scopului de
implementare a unui ERP, încă din faza de descoperire a nevoii de ERP.
Figura nr. 3.5. Planul de ansamblu al unui proiect ERP
58
Aşa cum precizam, planul de proiect după care se va monitoriza progresul acestuia este mult
detaliat, ceea ce înseamnă mai multe activităţi şi divizarea timpului la nivel de săptămâni şi zile. Fiecare
activitate din plan este descrisă prin: data de început, data de sfârşit, cine răspunde, resurse umane
participante, timpul de muncă estimat (în ore-om) şi costurile. Atât etapele, dar mai ales activităţile din
cadrul lor se pot desfăşura în paralel. Alteori, o etapă (activitate) depinde de rezultatele celei anterioare,
deci trebuie să aştepte finalizarea acesteia. În aceste condiţii, planificarea timpului este o sarcină dificilă,
deoarece estimările nerealiste şi nerespectarea unui termen determină reacţii în lanţ. Odată creat, planul
este folosit pentru monitorizarea activităţilor, consemnând progresul (procentele de realizare la un moment
dat) şi marcând întârzierile. El poate fi rectificat şi după demararea implementării, ceea ce credem că este
o variantă mai bună decât povara şi tensiunea efortului de a recupera din mers. Un manager atent va sesiza
din vreme problemele care pot cauza întârzieri – el va trebui să găsească soluţii de rezolvare/atenuare ori
să revizuiască termenele din plan.
În ceea ce priveşte managementul proiectului bazat pe acest plan, este important ca pe parcurs să se
folosească indicatori cantitativi în legătură cu cele trei aspecte ce descriu performanţa: timpul, costul şi
livrabilele. Unii autori sunt de părere că ar trebui măsurate şi beneficiile, pentru a însemna succesul unei
activităţi. În opinia noastră, monitorizarea celor trei indicatori asigură controlul asupra proiectului.
Livrabilele sunt un mijloc de a stabili cu maximă precizie gradul de îndeplinire al unei activităţi şi ele
trebuie clar precizate pentru fiecare activitate. Obţinerea livrabilelor este prioritară respectării termenelor
sau a costurilor – de multe ori acestea sunt depăşite atunci când apar probleme în finalizarea unei
activităţi, iar aceste depăşiri trebuie acceptate ca atare.
3.3.1.3 Relaţia cu furnizorul soluţiei ERP
Semnarea contractului cu firma câştigătoare îi conferă acesteia unele drepturi, dar nu şi acela de
suveran al proiectului ERP. Pe lângă importanţa stabilirii unor relaţii cordiale ca şi climat general de
desfăşurare a proiectului, este esențial să fie bine cunoscute limitele de autoritate ale furnizorului. El este
în primul rând călăuza beneficiarului prin hăţişul activităţilor care vor duce la implementarea şi utilizarea
unui nou sistem informatic. Prin poziţia sa, un furnizor puternic are în mod evident un ascendent asupra
beneficiarului, mai ales dacă acesta se află la prima experienţă de acest fel. Pe de altă parte, beneficiarul,
semnatar al unui contract bine gândit în privinţa eventualelor penalizări, nu trebuie să se comporte
totdeauna după lozinca „eu plătesc, eu decid". El trebuie să manifeste fermitate atunci când prestaţia
furnizorului este defectuoasă:
 consultanţii nu sunt disponibili, având mai multe proiecte simultan;
 erorile semnalate nu se repară;
 rapoartele cerute nu se dezvoltă;
 funcţionalităţile lipsă întârzie mult până la implementare ori nu sunt dezvoltate corect.
Prin vocea managerului de proiect, beneficiarul trebuie să intervină încă de la primele semnale de
acest fel. De regulă, managerul de proiect este singurul punct de contact cu furnizorul, mai precis cu
omologul său, managerul de proiect desemnat de furnizor. El are un rol esenţial în succesul implementării,
ar fi ideal să fie o persoană care are şi alte proiecte la activ, pe lângă necesarele calităţi de lider de echipă.
Pe de o parte, el are misiunea de a-l călăuzi şi sfătui pe managerul de proiect al clientului, începând de la
elaborarea planului de proiect şi pe tot parcursul. Altminteri, menirea sa este de a gestiona contul
clientului şi a conduce echipa proprie de proiect.
În faza de început cei doi manageri negociază o procedură prin care se fixează modalitatea de
recepţie a prestaţiilor efectuate. De asemenea, dacă nu s-a prevăzut prin contract, se discută modul de
tratare a incidentelor, fie că e vorba de disfuncţionalităţi software, probleme tehnice, solicitarea tardivă a
59
unor modificări. Dacă nu sunt stipulate într-o clauză din contract, e necesar un document oficial în acest
sens. De regulă, se stabilesc următoarele:
o orice incident este raportat managerului de proiect care ia legătura cu managerul de proiect al
furnizorului – se indică perioada de timp maximă în care se anunţă;
o incidentele trebuie raportate în scris;
o în ceea ce priveşte timpul de soluţionare, se realizează o clasificare a incidentului după criterii
convenite, în funcţie de care managerul furnizorului trebuie să ofere răspuns (în legătură cu
acest aspect, este important să se convină asupra semnificaţiei cuvântului „urgenţă");
o trebuie stipulată autoritatea care va interveni atunci când incidentul nu se soluţionează în
primă instanţă.
Munca echipei furnizorului presupune multe vizite la beneficiar, este sarcina managerului de proiect
să le organizeze şi să asigure condiţiile necesare pentru ca acestea să fie productive (cel mai important
factor este prezenţa şi disponibilitatea utilizatorilor „folositori", aceia care cunosc cel mai bine
problematica discutată). Pentru a documenta şi a putea revedea mersul proiectului (mai ales dacă lucrurile
nu vor merge „conform planului"), aspectele discutate la fiecare întâlnire sunt consemnate în scris şi
semnate de toţi participanţii – aceste documente se numesc minute. Minutele se întocmesc nu din elan
birocratic, ci pentru a consfinţi acceptarea anumitor solicitări de către furnizor, ori a unor compromisuri de
către beneficiar.
În fine, managerul de proiect monitorizează atent prestaţia echipei furnizorului sub aspectul
costurilor, atunci când contractul stipulează un anume număr de ore lucrate. Pe baza recepţiei livrabilelor,
la termenele stabilite, managerul de proiect este cel care se îngrijeşte de aprobarea plăţilor către furnizor.
Facturile trimise de aceste trebuie verificate înainte de a le admite la plată.
3.3.1.4 Managementul riscurilor
Murphy a ţinut să ne avertizeze că dacă ceva poate merge rău, atunci aşa se va întâmpla. Într-un
proiect ERP foarte multe pot „merge rău", astfel că este prudent să abordăm riscurile încă din faza de
planificare. Scopul este de a anticipa eventualele probleme, de a aprecia probabilitatea ca ele să apară, de a
estima intensitatea impactului asupra proiectului şi, în final, de a stabili măsuri de prevenire şi de
combatere.
Managementul riscurilor unui proiect IT constituie o temă frecvent abordată în literatura de
specialitate, iar cele gândite pentru un proiect IT se pot lesne adapta în cazul proiectelor ERP. O simplă
căutare pe Google ne-a returnat sute de cărţi şi de bloguri care discută despre acest subiect.
În implementările de mari dimensiuni, la companiile mari, cu echipe pe măsură, acest capitol este
gestionat în detaliu, deoarece nu doar riscurile sunt mai mari şi mai multe, ci şi efectele mai grave.
Pentru proiectele de dimensiuni medii, ne permitem să sugerăm aplicarea unui management de risc
denumit sugestiv „destul de bun" – good enough risk management. Ca şi alte activităţi „good enough", se
invocă regula 80/20. În cazul acesta, cu 20% din efortul presupus de o gestiune completă a riscurilor sunt
acoperite 80% dintre acestea. Managerul de proiect împreună cu echipa sa se vor preocupa de:
 crearea unui jurnal al riscurilor la începutul proiectului (nerespectarea acestui termen anulează
şansele de a obţine un management „destul de bun");
 descrierea fiecărui risc prin:
o tip (tehnic sau non-tehnic);
o impactul asupra timpului, calităţii şi costului proiectului, ca şi asupra reputaţiei;
o probabilitatea de a se produce (0-100%);
o impactul general asupra desfăşurării proiectului (0-100%);
60
 cuantificarea severităţii fiecărui risc (impact x probabilitate);

 definirea de măsuri pentru riscurile severe (cuantificare > 0.5 pe o scară de la 0 la 1);
 revizuirea periodică a riscurilor şi a statusului celor identificate împreună cu echipa de proiect.
Un jurnal „ţinut" într-un registru de lucru în Excel, cu structura prezentată în figura 3.6 este uşor de
gestionat pe întreg parcursul proiectului. Ce este foarte important în alegerea acestei abordări este
colaborarea cu membrii echipei pentru identificarea, cuantificarea şi găsirea măsurilor de combatere a
riscurilor.
Figura nr. 3.6. Structura unui jurnal de riscuri
Aşa cum se observă din figura 3.6, severitatea unui risc poate fi pusă în evidenţă şi vizual, colorând
valorile care solicită atenţie. Este vorba de cele cu probabilitate mare şi impact mare, care pot fi colorate
cu roşu. Ele trebuie tratate cu prioritate, încercându-se reducerea probabilităţii de producere (prevenire)
sau, dacă nu se poate, formularea de măsuri pentru a le neutraliza.
61
3.3.2 ASPECTE TEHNICE PRIVIND INSTALAREA NOULUI SISTEM

Cele spuse anterior, cum că în ERP este vorba de procese de afaceri şi că la implementare trebuie
atent gestionate resursele umane nu minimalizează importanţa componentei tehnice a unui proiect ERP. În
paralel cu activitatea din zona funcţională se lucrează pentru crearea infrastructurii noului sistem. Sarcinile
se referă la achiziţia, instalarea şi configurarea echipamentelor şi a aplicaţiilor şi sunt executate de
specialiştii IT. Dacă beneficiarul nu are personal propriu specializat, poate folosi resurse ale furnizorului
de ERP sau poate angaja o terţă firmă să se ocupe de aspectele tehnice ale proiectului.
În cazul abordării cu forţe proprii, între problemele care trebuie să se regăsească pe listă sunt:
 inventarierea tuturor locaţiilor în care se instalează staţiile de lucru (clienţii) şi alte echipamente
necesare (imprimantă, scanner etc.);
 asigurarea spaţiului şi a condiţiilor necesare pentru zona serverelor;
 rezolvarea problemelor legate de conexiunile cu serverul;
 analiza performanţei serverelor pe diferite contexte de lucru;
 configurarea mediului de lucru în mai multe domenii (cel puţin două servere: unul de test, utilizat
pentru dezvoltare şi testare şi al doilea cel productiv);
 determinarea spaţiului de stocare necesar şi estimarea acestuia pe termen mediu;
 stabilirea procedurilor de back-up (copii de siguranţă a datelor);
 analiza conflictelor între utilizatori în baza de date (blocarea acesteia în cazul accesului simultan
la date);
 realizarea procedurii de recuperare a datelor în caz de dezastre;
 examinarea securităţii sistemului şi elaborarea politicii de securitate în sistemul ERP (definirea
utilizatorilor şi accesului, analiza rolurilor şi restricţiilor).
Departe de a fi un inventar complet al problemelor, această listă oferă câteva direcţii importante
dintr-o diversitate destul de mare, adesea specifică proiectului şi beneficiarului. Managerul de proiect
poate numi un responsabil cu aspectele tehnice, atunci când acestea sunt tratate şi rezolvate intern.
3.3.3 STRATEGIA DE INSTRUIRE A UTILIZATORILOR

Mult prea des se relatează despre proiecte în care utilizatorii nu sunt mulţumiţi de cât au învăţat
despre noul sistem informatic, căci efectiv, numărul de ore alocat instruirii este prea mic. Deşi este
prevăzută în planul proiectului cu un număr rezonabil de ore, instruirea este neglijată adesea, mai ales că
aceste activităţi sunt programate spre finalul proiectului, când termenele impun constrângeri. De fapt, cel
mai adesea orele de instruire sunt tăiate voluntar pentru a acoperi alte capitole bugetare cu depăşiri ce nu
pot fi evitate.
În acest context am ales să scoatem în evidenţă, într-un paragraf distinct, această activitate. Şi
pentru acest subiect sunt multe surse de inspiraţie, noi dorim cel mai mult să punctăm şi să justificăm
importanţa instruirii.
Schimbarea adusă de un sistem ERP nu este nici lină, nici neînsemnată, iar instruirea contribuie la
prevenirea efectelor negative. Un sistem ERP nu schimbă doar aplicaţii, ci şi procese şi fluxuri de
activităţi. Pentru un utilizator deprins cu un program ani de zile, este supărătoare simpla înlocuire a
acestuia cu altul, de aceea noul sistem informatic va învolbura apele liniştite ale organizaţiei. Instruirea
încearcă să îl educe pe utilizator în spiritul noului sistem, ajutându-l să perceapă beneficiile şi să accepte
schimbarea.
62
Un plan de instruire atent eșalonat şi executat la timp sprijină tranziţia către noul sistem şi
adoptarea lui. Planul de instruire are menirea principală de a realiza un transfer de cunoştinţe la nivelul
funcţiunii/operaţiunilor (instruire procedurală), pentru ca utilizatorii să opereze corect în noul sistem, dar
nu numai atât.
Marele beneficiu al instruirii este, după părerea noastră, determinarea angajaţilor de a accepta
schimbarea. Sunt identificate patru stări posibile ale acestora, pe care le-am aşezat în patru cadrane (figura
3.7).
Figura nr. 3.7. Curba adoptării unui sistem nou de către utilizatorii finali
În mod firesc, utilizatorii finali trec prin cele patru stări în succesiunea: negare – rezistenţă –
explorare – angajament, într-o curbă care atinge la un moment dat punctul maxim de indignare, de revoltă
împotriva noului sistem. Printr-un plan coerent de instruire utilizatorii vor fi îndrumaţi în cadranele din
partea dreaptă a figurii. Acest lucru este posibil atunci când instruirea înseamnă mai mult decât învăţarea
unui program informatic nou şi adaptarea la un nou flux de procese, respectiv justificarea nevoii de
inovare, explicarea şi motivarea modificărilor pe care le va aduce implementarea noului sistem, a
consecinţelor acestora asupra muncii utilizatorilor.
În realitate, instruirea se desfăşoară într-o manieră mai degrabă informală, puţin riguroasă. Toată
lumea beneficiază de o prezentare generală a funcţionalităţilor modulului de program în care lucrează,
apoi se organizează o sesiune de instruire pe serverul de dezvoltare. Utilizatorii primesc un manual sau un
set de proceduri de utilizare şi se porneşte lucrul în sistemul productiv, după metoda „dacă te aruncă în
apă, trebuie să înveţi să înoţi". Din acest moment, fiecare utilizator deprinde noul sistem în ritm propriu,
beneficiind de sprijin numai atunci când îl solicită. În funcţie de profilul şi nivelul de cunoştinţe IT ale
utilizatorului, dar şi de atitudinea sa faţă de noul sistem, deprinderea va dura mai mult sau mai puţin, va
avea finalitatea dorită sau nu. Pe lângă asta, o slabă organizare a instruirii poate avea consecinţe
nefavorabile asupra proiectului atunci când utilizatorii nu lucrează în noul sistem din motive de
necunoaştere sau, mai rău, operează greşit. Se ajunge să se consume mai mult timp cu refacerea şi
corectarea tranzacţiilor şi cu discuţiile individuale, decât dacă ar fi avut loc activităţi de instruire după un
plan formal, aparent costisitor.
În opinia noastră, esenţială este implicarea şi responsabilitatea manifestate de beneficiar
(elaborarea strategiei de instruire şi alocarea de resurse suficiente) şi de utilizatorii finali (ajungerea
rapidă în faza de angajament faţă de noul sistem), astfel încât să se obţină un echilibru între furnizarea
unei instruiri de calitate şi încadrarea în costurile prevăzute în buget.
3.4 Utilizarea prototipurilor în implementarea sistemelor ERP

Activitatea de prototipizare se potriveşte foarte bine într-o implementare de ERP. Scopul ei este de a
stabili cum se vor desfăşura procesele economice pe platforma integrată, fără a căuta neapărat să se obţină
63
cea mai bună soluţie posibilă, dar oferind punctul de pornire în această direcţie. Căutarea celei mai bune
soluţii este nerealistă la momentul implementării, ea este realizabilă doar pe termen mediu sau chiar lung,
într-un mediu dinamic, care promovează îmbunătăţirea continuă a proceselor. Ce se poate face acum este
adoptarea celor mai bune practici, transpunerea lor în practici operaţionale, astfel ca procesele să genereze
ieşirile dorite. După startul productiv al noului sistem, noile cerinţe/aspecte identificate pot fi rezolvate
prin adoptarea programelor de îmbunătăţire continuă a proceselor.
În timpul activităţii de proiectare a fiecărui proces, furnizorul va cere continuu echipei de proiect să
răspundă în numele beneficiarului la întrebări precum:
o Ce doresc să realizeze?
o Care este cea mai bună cale de realizare?
o Vor să facă lucrurile în acelaşi mod în care le-au făcut până acum? Dacă da, de ce?
o Care sunt variantele de realizare posibile?
Este evident că, de cele mai multe ori nu se pot găsi răspunsuri imediate la aceste întrebări, dar pe
parcursul activităţii, procesele vor începe să semene tot mai mult cu ceea ce îşi doreşte beneficiarul. Pe de
o parte este meritul consultanţilor furnizorului, pe de alta este rezultatul experimentării.
Cu cât procesul este mai complex, cu atât este mai necesară urmărirea dezvoltărilor efectuate. Un
instrument de lucru convenabil este colajul, nimic altceva decât o foaie foarte mare de hârtie (sau mai
multe foi mici alăturate) lipite pe un perete, pe care se vor desena fluxurile definite, indicând punctele
slabe, care trebuie reanalizate.
Pe măsură ce procesul se clarifică, trebuie luate decizii legate de setările de sistem, care în final vor
constitui configuraţia finală a sistemului. Se cuvine multă atenţie la stabilirea unei setări de sistem, căci
multe dintre acestea nu mai pot fi schimbate ulterior! O decizie proastă în faza de configurare poate avea
consecinţe nebănuite.
Odată cu conturarea configuraţiei încep testările de funcţionalităţi, care pot semnala bug-uri
software. Acestea trebuie semnalate consultanţilor, care la rândul lor le raportează programatorilor.
Desigur, trebuie urmărită rezolvarea lor, iar atunci când nu se pot corecta să se găsească căi alternative de
lucru.
Pe parcursul prototipizării apar tot felul de probleme, iar pentru a le ţine sub control se poate ţine un
jurnal de înregistrare. Toţi membrii echipei pot face înregistrări, atunci când consideră că au o problemă
de semnalat. Pentru fiecare problemă se va şti cine a identificat-o, cui a fost raportată, care este termenul
de rezolvare estimat. Managerul de proiect va monitoriza regulat această listă de probleme, asigurându-se
că ele vor fi închise.
3.5 Modificarea aplicaţiilor – un compromis între procese şi funcţionalităţile software

Este bine ştiut şi unanim acceptat (cel puţin la nivel declarativ) că modificarea aplicaţiilor nu este
dezirabilă, deoarece compromite upgrade-urile viitoare. Mai ales atunci când se doresc diverse
îmbunătăţiri sau optimizări ale proceselor. Furnizorul propune iniţial o soluţie software echilibrată, bine
testată, stabilă. Modificările ulterioare pot afecta nefavorabil echilibrul iniţial. Şi să nu uităm că orice
modificare înseamnă costuri suplimentare pentru beneficiar, nu doar pentru realizarea iniţială, ci pentru
reluarea ei la fiecare din upgrade-urile viitoare.
Alegerea este, în mod clar, dilematică. Nici varianta adoptării soluţiei fără modificări nu este una
fericită. Cel mai bine este atunci când această situaţie „to be or not to be" este evitată din faza de analiză a
cerinţelor, definindu-le corect şi complet şi alegând soluţia software cea mai potrivită acestora. În aceste
condiţii, cu puţin noroc, astfel de dileme sunt generate de probleme de detaliu şi nu de fond, iar
recomandarea este să nu se modifice aplicaţiile.
64
Însă atunci când este în discuţie o funcţionalitate majoră care a fost examinată superficial, pericolul
este ca aplicaţia să nu ofere suport pentru derularea dorită a procesului vizat. În acest caz, nici una dintre
opţiuni nu este plăcută. Cea de pliere a procesului pe funcţionalitatea livrată de software nu convine din
motive evidente. Pare mai potrivită opţiunea de modificare a aplicaţiei, dar trebuie să se ştie că poate fi
costisitoare. Există totuşi şi o a treia opţiune care trebuie studiată, cea de rezolvare independentă a
problemei, manual sau printr-un software specializat (nu de puţine ori se apelează la Excel pentru
rezolvarea problemei, rezultatele fiind apoi automat importate în sistemul ERP).
În ceea ce priveşte modificarea aplicaţiilor, fiecare astfel de decizie trebuie atent cumpănită şi
justificată (modificarea este absolut necesară, beneficiile ei sunt evidente etc.) şi realizată printr-o
procedură controlată şi documentată astfel:
o descrierea modificării;
o justificarea modificării;
o cine solicită şi cine aprobă modificarea (trebuie să fie două persoane diferite);
o costurile modificării;
o beneficiile anticipate;
o timpul de realizare necesar.
Orice modificare aprobată şi efectuată trebuie recepţionată, pe baza unui document semnat de
managerul de proiect, după ce acesta primeşte din partea echipei de proiect confirmarea că modificarea a
fost testată. Lipsa unei proceduri este extrem de riscantă în proiectele mari, deoarece acestea pot prolifera,
cu efecte nefaste asupra stabilităţii soluţiei ERP şi desigur, asupra costurilor.
3.6 Startul productiv

A sosit marele moment. Utilizatorii sunt instruiţi, procesele configurate şi testate, datele au fost
transferate, iar echipamentele testate. Oare ce s-a omis? Este o întrebare deschisă, adresată tuturor, căci nu
se ştie de unde sare iepurele (un aspect minor pe care cei din echipa proiectului nu-l văd, preocupaţi fiind
de finalizarea punctelor principale).
Reușita startului productiv este dată de o lipsă. A problemelor, desigur.
3.6.1 PROBLEMELE ŞI MODUL DE REZOLVARE

Un start productiv fără probleme este o utopie. Indiferent cât de bine au decurs activităţile,
probleme pot apare, iar echipa trebuie să fie pregătită să le întâmpine, folosind un mecanism de rezolvare
deja definit. Managerul de proiect răspunde de orice problemă apare în ziua Z, dar el poate delega
răspunderea pe tipuri de probleme membrilor echipei calificaţi să le facă faţă. Când o problemă este
identificată, ea ajunge la persoana dinainte definită ca răspunzătoare, care ştie ce este de făcut pentru a o
soluţiona şi urmăreşte rezolvarea ei.
O problemă poate fi imediat soluţionată de persoana răspunzătoare, poate necesita investigaţii
suplimentare realizate de aceeaşi persoană, în urma cărora se găseşte o soluţie sau nu. În ultimul caz,
problema va fi raportată către specialiştii furnizorului, împreună cu o descriere cât mai completă (dacă este
o eroare în funcţionarea unei aplicaţii, este important ca programatorii să o poată reproduce, de aceea sunt
necesare cât de multe detalii ale contextului în care s-a produs).
Un jurnal al incidentelor în care se adaugă problema încă din faza iniţială, persoana care răspunde,
modul de tratare, un orizont de timp pentru soluţionare asigură un control mai bun. De asemenea, în jurnal
se va nota închiderea fiecărei probleme.
65
3.6.2 PRIMA LUNĂ. REVIZUIREA IMPLEMENTĂRII

Prima lună de utilizare a noului sistem va proba eficienţa acestuia din punct de vedere funcţional.
Într-o organizaţie, la fiecare sfârşit de lună au loc operaţii specifice, în principal în contabilitate. După o
primă lună de operare, pe baza cifrelor din contabilitate se pot face verificări încrucişate, care vor valida
funcţionarea sau vor scoate la iveală probleme operaţionale.
Dat fiind că într-un sistem ERP balanţa de verificare poate fi emisă oricând, nu doar la sfârşitul unei
perioade, orice observaţie de anormalitate poate fi verificată, comparând rezultatele dintr-o zonă
funcţională cu cele furnizate de rulajele ori soldul conturilor contabile. Astfel de investigaţii pot releva
configurarea greşită a unor conturi sau chiar lipsa unor conturi.
După prima lună şi corectarea eventualelor erori, undeva la 6 săptămâni sau la 2 luni de la startul
productiv, echipa de proiect împreună cu reprezentanţii furnizorului şi cu top-managerii implicaţi pot trage
concluzii importante la un prim bilanţ al implementării:
 Aplicaţiile implementate lucrează conform cerinţelor? Care sunt principalele probleme
întâmpinate în legătură cu aceasta?
 Care sunt problemele încă nerezolvate şi care sunt costurile şi orizontul de timp necesare
soluţionării lor?
 Care sunt lecţiile învăţate din această implementare? Ce putea fi făcut mai bine?
 Pot fi observate premizele pentru ca proiectul să fie considerat un succes?
Deşi o astfel de întâlnire poate părea neîntemeiată, ea este un câştig în contul proiectelor viitoare,
deoarece experienţa acumulată şi învăţarea din greşeli se vor reflecta neîndoielnic în succesul acestora.
3.7 Îmbunătăţirea continuă

Aşa cum ne place să spunem, un proiect ERP nu este o destinaţie, ci o călătorie. O organizaţie este
dinamică, în continuă schimbare şi adaptare, de aceea practic, implementarea sistemului integrat nu se
opreşte niciodată. Fie că beneficiile anticipate nu sunt realizate, că unele procese nu se ridică la înălţimea
aşteptărilor ori că se caută optimizarea de procese corecte din punct de vedere funcţional, vorbim despre
un program de îmbunătăţire continuă. Tot într-un astfel de program se încadrează şi înlocuirea
sistemului ERP existent cu un nou sistem, atunci când se decide că upgrade-urile nu mai pot ajuta.
Decizia de a schimba un sistem ERP cu un altul este dificilă şi, într-un fel, ingrată deoarece va
zgudui din nou confortul utilizatorilor finali. Totuşi, să ţinem seama că durata de viaţă a unui ERP a scăzut
de la 10 ani în anii '90 la 5 ani în prezent. Ceea ce nu înseamnă totuşi că după 5 ani trebuie să o luăm de la
capăt cu implementarea unui nou ERP. Furnizorii de soluţii sunt perfect conştienţi de această realitate şi,
pe fondul evoluţiei tehnologiilor informaţionale şi de comunicaţii, propun versiuni noi, îmbunătăţite
funcţional.
Decizia cea mai convenabilă este aceea de upgrade la o nouă versiune, deoarece se continuă o
relaţie cu un furnizor cunoscut (cu condiţia să fi fost o colaborare fericită), utilizatorii sunt deja experţi în
utilizarea aplicaţiilor, timpul de implementare este mult mai scurt, iar costurile sunt mai mici decât în
cazul înlocuirii.
Decizia de înlocuire se impune atunci când versiunea deţinută este depăşită, expirată din punct de
vedere tehnologic, astfel că upgrade-ul ar însemna de fapt o implementare nouă, dar având câteva atuuri în
implementarea proiectului. Luarea deciziei presupune punerea în balanţă a avantajelor oferite de
colaborarea cu acelaşi furnizor cu promisiunile interesante ale unui furnizor nou.
66
Îmbunătăţirea continuă este subordonată managementului calităţii şi înseamnă pentru organizaţie

parcurgerea mai multor stadii, de la cel iniţial de lipsă de control asupra activităţii la cel final, de excelenţă
în afaceri. Un sistem integrat ajută organizaţia să treacă în stadiul în care deţine controlul asupra afacerii.
Considerăm că deşi este doar primul pas spre excelenţă, este cel mai dificil pas deoarece are implicaţii
majore asupra tuturor laturilor organizaţiei.
3.8 Modele de întrebări grilă
Activitatea de prototipizare:
1. se potriveşte foarte bine într-o implementare de ERP
2. stabileşte prin simulare cum se vor desfăşura procesele economice pe platforma integrată
3. nu este necesară într-o implementare ERP
4. descoperă problemele implementării ERP
Ciclul de implementare a unei soluţii ERP poate fi împărţit în următoarele faze mari:
1. determinarea necesităţii ERP
2. corectarea furnizorului
3. implementarea propriu-zisă
4. îmbunătăţirea temporară
Instituirea nevoii de ERP

1. este rezultatul unei introspecţii atente
2. se poate constitui într-o oportunitate
3. are loc la întâmplare
4. nu reprezintă o oportunitate
Costurile unui sistem ERP variază în funcţie de:

1. mărimea întreprinderii (cifra de afaceri şi numărul de angajaţi)
2. numărul de utilizatori ai sistemului
3. numărul de module neimplementate
4. tehnologiile viitoare
Bibliografie
1. Brynjolfsson, E., Yang, S., The intangible beneﬁts and costs of computer investments: evidence from the
ﬁnancial markets. Lucrare inclusă în Proceedings of the International Conference on Information
Systems, Atlanta, SUA, 1997.
2. Donovan, R.M., Why the controversy over the ROI from ERP?, în revista Midrange ERP, ianuarie 2000
3. Fotache, D., Hurbean, L., Dospinescu, O., Păvăloaia, D., Procese organizaţionale şi integrare
informaţională. ENTERPRISE RESOURCE PLANNING, Editura Universităţii Alexandru Ioan Cuza, Iaşi,
2010
4. Gartner Group, Training: the underestimated ERP project requirement, Research Note SPA-345-1337,
publicată de Gartner Inc., 1997
5. Harwood, S., ERP: The implementation cycle, Butterworh-Heinemann, Oxford, 2003, p. 3
6. Johnston, A.K., A hacker's guide to project management, Butterworh-Heinemann, Oxford, 1995, p. 5.
7. Remenyi, D., ş.a., The effective measurement and management of IT costs and benefits, Butterworh-
Heinemann, Oxford, 2000, p. 81
67

Unitatea de Învăţare 3 Implementarea Sistemelor ERP: Cuprins

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unitatea de Învăţare 3 Implementarea Sistemelor ERP: Cuprins

Încărcat de

Drepturi de autor:

Formate disponibile

Unitatea de învăţare 3

Implementarea sistemelor ERP

3.1 Mai întâi trebuie să fie nevoia… ........................................................................................................... 42

După parcurgerea acestui capitol ar trebui să:

 înţelegeţi importanţa deciziei de implementare a unui ERP,

Timp de studiu: 4 ore

Câteva consideraţii preliminare

Tabelul nr. 3.1. Descrierea fazelor ciclului de implementare ERP

3.1 Mai întâi trebuie să fie nevoia…

3.1.1 PRIMA ÎNTREBARE: DE CE?

3.1.2 A DOUA ÎNTREBARE: CÂT COSTĂ?

o numărul de module implementate;

3.1.3 JUSTIFICAREA INVESTIŢIEI: EXPLORAREA COSTURILOR ŞI BENEFICIILOR

Figura nr. 3.1. Beneficiile intangibile

sistem nu se regăseşte în tehnologia informaţională înglobată, ci în modul în care tehnologia este

3.1.4 DEFINIREA CERINŢELOR

Figura nr. 3.2. Exemplu diagramă de procese

În practica implementărilor, după ştiinţa noastră, o astfel de analiză a cerinţelor nu se realizează

Figura nr. 3.3. Extras din caietul de sarcini. Livrabilele solicitate.

3.2 Selecţia furnizorului de ERP

3.3 Implementarea sistemului ERP într-o organizaţie

3.3.1 METODOLOGIA DE IMPLEMENTARE

Figura nr. 3.4. Planul general de implementare ERP

Figura nr. 3.5. Planul de ansamblu al unui proiect ERP

 cuantificarea severităţii fiecărui risc (impact x probabilitate);

Figura nr. 3.6. Structura unui jurnal de riscuri

3.3.2 ASPECTE TEHNICE PRIVIND INSTALAREA NOULUI SISTEM

3.3.3 STRATEGIA DE INSTRUIRE A UTILIZATORILOR

3.4 Utilizarea prototipurilor în implementarea sistemelor ERP

3.5 Modificarea aplicaţiilor – un compromis între procese şi funcţionalităţile software

3.6 Startul productiv

3.6.1 PROBLEMELE ŞI MODUL DE REZOLVARE

3.6.2 PRIMA LUNĂ. REVIZUIREA IMPLEMENTĂRII

3.7 Îmbunătăţirea continuă

Îmbunătăţirea continuă este subordonată managementului calităţii şi înseamnă pentru organizaţie

3.8 Modele de întrebări grilă

Instituirea nevoii de ERP

Costurile unui sistem ERP variază în funcţie de:

S-ar putea să vă placă și