Sunteți pe pagina 1din 39

CAPITOLUL 1.

ASPECTE TEORETICE DESPRE


INTEGRAREA APLICAIILOR INFORMATICE
Integrarea aplicaiilor informatice n cadrul companiilor a fost
mereu un subiect de actualitate n ultimii ani, conducnd la crearea unui
nou stil de lucru n domeniul software: Enterprise Application Integration.
n acest prim capitol se urmrete evoluia aplicaiilor informatice integrate
de gestiune a firmelor, problemele cu care acestea s-au confruntat inevitabil
n cadrul eforturilor de integrare.
Soluiile de tip ERP (Enterprise Resource Planning), CRM
(Customer Relationship Management), SCM (Supply Chain Management)
sunt deja considerate imperative clasice n marile companii, o condiie
important pentru meninerea avantajului competitiv. Eforturile sunt din ce
n ce mai mult ndreptate n direcia integrrii ntregului lan furnizoriorganizaie-beneficiari.
Conceptul de Enterprise Application Integration (EAI) este folosit
destul de frecvent cnd vine vorba de urmtorul pas in e-Business. EAI
definete o metodologie care s asigure comunicarea uoar ntre aplicaii
i surse de date din cadrul unei companii, astfel nct acestea s partajeze
procese de afaceri i date, chiar dac elementele integrate se schimb (de
exemplu, sistemul de management al bazelor de date). EAI pare s ofere
soluia la generaii de dezvoltare a soluiilor informatice fr existena unei
viziuni sau strategii centralizate de dezvoltare

1.1. Definiia si evoluia integrrii aplicaiilor informatice


Integrarea aplicaiilor informatice este o activitate ce reunete
oameni, echipamente, programe, dar i practici manageriale. Integrarea
aplicaiilor este o abordare strategic de a lega mai multe sisteme
informatice, la nivel de informaii i servicii, astfel nct sistemele s fie
capabile s fac schimb de informaii i s asigure o funcionare a proceselor
n timp real .
Integrarea aplicaiilor informatice n cadrul unei ntreprinderi sau
ntre mai multe ntreprinderi care colaboreaz este un subiect de mare
actualitate. Integrarea aplicaiilor informatice de ntreprindere permite
coordonarea i sincronizarea mai multor aplicaii eterogene att n interiorul

(integrarea aplicaiilor la nivel de companie), ct si n afara ntreprinderilor


(integrarea aplicaiilor Business-to-Business - B2B).
Denumit n limbajul de specialitate EAI (Enterprise Application
Integration), integrarea aplicaiilor la nivel de companie reprezint, de fapt,
noul stil de lucru n domeniul software. ntreprinderile au din ce n ce mai
puini informaticieni care concep i scriu aplicaii i din ce n ce mai muli
care integreaz aplicaii. Entitatea ce trebuie integrat nu mai este un obiect
sau o component software, ci este o aplicaie software. Prin EAI, sistemele
informatice ale ntreprinderilor se muleaz din ce n ce mai bine pe structura
procesului de afaceri.
Complexitatea problemelor legate de infrastructura informatic crete
i mai mult n cazul unei ntreprinderi virtuale, format din module (secii,
departamente, birouri etc.) cu funcionalitate extrem de divers i grad de
dispersie geografic orict de mare. Granularitatea modulelor se poate situa
pe o scar foarte cuprinztoare, depinznd n mare msur att de specificul
domeniului de activitate, ct i de posibilitile de organizare ale
ntreprinderii respective.
n contextul actual, n care informaia este privit ca o resurs
strategic a ntreprinderii, a crescut foarte mult importana integrrii
sistemelor informatice care s faciliteze utilizarea n comun a datelor i
micarea lor n cadrul ntreprinderii.
La nivelul anului 1999 s-a estimat c peste o treime din bugetul din
industria IT a avut ca destinaie proiectarea, realizarea i ntreinerea unor
soluii de integrare a sistemelor informatice. Dar, cele mai multe dintre
aceste soluii au optat pentru varianta de integrare punct la punct, i s-au
dovedit a fi mari consumatoare de resurse.
Dezvoltarea unei strategii eficiente de integrare a sistemelor
informatice la nivelul ntreprinderii este una dintre cele mai complexe
probleme ntmpinate de managerii IT. Complexitatea acestei probleme
rezult n principal din faptul c cele mai multe dintre aplicaii au fost
dezvoltate fr a se avea n vedere o anumit arhitectur a sistemelor
informatice sau o strategie de dezvoltare a acestora.
Anul 1959 poate fi considerat nceputul integrrii n domeniul IT, an
n care a aprut circuitului integrat i care a reunit i alte descoperiri cum ar
fi: tranzistorii, rezistenele i capacitorii pe un singur chip de silicon. n
1965 Gordon Moore, unul din fondatorii Intel prezicea c numrul de
tranzistori pe un microchip se va dubla la fiecare 18 luni. n mod
surprinztor, aceast lege este nc adevrat i acum, la peste 40 de ani de
la formularea ei. Acesta poate fi considerat unul din motivele pentru care
avem nevoie de integrare: pentru a ne descurca n condiiile unei
2

complexiti crescute. n acest context, merit reamintite principiile de baz


ale managementului complexitii: descompunea n pri mai mici i mai
uor de manipulat, construirea unei interfee standard pentru ca aceste pri
s comunice i apoi dezvoltarea unei structuri ierarhice unde informaia este
din ce n ce mai abstractizat odat ce urcm n ierarhie.
Informatizarea, dezvoltarea economic global, specifice nceputului
de secol XXI au accentuat tendina de organizare a sistemelor
informaionale n modele din ce n ce mai complexe. Prin integrare crete,
dupa cum s-a vazut, complexitatea, dar i calitatea, pentru c reuniunea
sistemelor presupune adugarea de componente evolutive i emergente.
Dac organizarea duce la integrare i integrarea duce la
complexitate, aceasta din urm determin la rndul ei diversificarea. Din
punct de vedere al diversitii, integrarea este efectul evoluiei ciclice i
progresive a unui mix de tehnologii i este sprijinit de performanele i de
expertiza profesionitilor.
Integrarea aplicaiilor poate lua mai multe forme, incluznd
integrarea intern a aplicaiilor: integrarea aplicaiilor la nivel de companie
sau integrarea extern a aplicaiilor: integrarea aplicaiilor Business-toBusiness. Cele dou tipuri de integrri au multe elemente comune. De
exemplu, ntotdeauna vor exista:
transformare de tehnologie care va face diferena ntre semantica
aplicaiilor;
tehnologia de router prin care se va asigura c informaia ajunge
la destinaia corect;
reguli de procesare pentru a defini comportamentul de integrare.
Strategia IT trebuie s in seama de toi factorii care influeneaz
deciziile de integrare a proceselor economice, ca de exemplu configurarea
proceselor economice, frontierele acestora i locul n care schimbarea este
cel mai probabil a se produce. nelegerea scopurilor economice, cum ar fi
strategiile de fuzionare i de achiziie sau cost i creterea eficienei,
apare ca o cheie fundamental. Trebuie stabilit o perspectiv intern i
extern comun a nucleului economic, de informaie i de procese,
pentru a nelege relaiile i interfeele ntre unitile economice, sau ntre
partenerii comerciali.
Trebuie stabilite problemele proprietii pentru aplicaii,
componente, infrastructura integratoare, interfeele externe etc. i aceasta
poate fi una dintre cele mai dificile sarcini i poate traversa frontiere
organizaionale i responsabilitile actuale. Secvenierea activitilor
trebuie s identifice serviciile care trebuie realizate primele, care dintre

servicii (nu neaprat aceleai) trebuie utilizate consistent cu restul


organizaiei i cnd anume.
O tendin n evoluia integrrii sistemelor este trecerea de la
integrarea bazat pe informaii la integrarea bazat pe servicii. Integrarea
bazat pe informaii ofer un mecanism ieftin de a integra aplicaii deoarece,
n cele mai multe cazuri, nu este nevoie ca aplicaia s fie modificat. Cu
toate c acest tip de integrare ofer o soluie funcional pentru multe
domenii ale problematicii de integrare a aplicaiilor, integrarea bazat pe
servicii ofer mai mult valoare pe termen lung.

1.2. Definiia i rolul sistemelor informatice integrate


Sistemele informatice integrate desemneaz nite sisteme complete
n cadrul crora se desfoara procese de afaceri, practici manageriale,
interaciuni organizaionale, transformri structurale i management al
cunotinelor.
Un sistem de aplicaii integrat trebuie s reprezinte soluia pentru
orice companie care necesit un sistem informatic modern, indiferent dac
acesta automatizeaz procesele interne din cadrul organizaiei, relaiile cu
clienii sau pe cele cu furnizorii i partenerii. Adoptarea unor aplicaii
disparate pentru diferite activiti ale fluxului de afaceri, poate reprezenta o
soluie bun pentru moment, dar care poate genera mari probleme legate de
fragmentarea informaiei i dezvoltarea ulterioar a sistemelor, prin
ncercarea de a integra soluii ulterioare.
Productorii de software care ofer aplicaii ce ruleaz pe multiple
surse de date sau care nu acoper toate sectoarele fluxurilor de afaceri, nu
furnizeaz pachete de soluii integrate, ci mai degrab colecii separate de
aplicaii, bune s rezolve problemele cerute de sisteme disparate, dar care nu
reuesc s funcioneze mpreun.
Problema principal a falselor pachete de aplicaii este fragmentarea
informaiei, generat de sisteme disparate. Consolidarea informaiilor venite
de la un numr mare de surse este laborioas i costisitoare. O alt mare
problem este automatizarea incomplet, care nu acoper toate procesele
afacerii, rezultnd sisteme discontinue, ce ofer funciuni analitice doar la
nivel departamental, incapabile s asigure o viziune unitar asupra
organizaiei. n aceste condiii, managerul instituiei nu are la dispoziie
dect piese dintr-un puzzle, care rareori se mbin.

Pentru a face saltul calitativ de la aciuni punctuale la procese de


afaceri, organizaiile trebuie s adopte soluii integrate i colaborative, care
s se adapteze strategiilor de distribuie i care s includ i funcionaliti
de suport decizional.
Un adevrat pachet integrat are aplicaiile proiectate de la nceput
pentru a lucra mpreun: acestea partajeaz acelai model de informaii i
informatizeaz procesele de afaceri la nivelul ntregii organizaii.
Principalele avantaje pe care o suit de aplicaii integrate trebuie s
le ofere beneficiarilor sunt:

reducerea costurilor pe termen lung;

creterea eficienei operaionale;

recuperarea rapid a investiiilor n IT;

migrarea mai rapid la modele de e-business.

Pentru a nelege rolul jucat de un sistem informatic integrat n


funcionarea unei ntreprinderi, este necesar s se porneasc de la modelul
general de organizare a unei afaceri, corespunztor majoritii
ntreprinderilor de producie, comer, servicii sau a unora din sectorul
financiar-bancar.
Conform acestui model, orice ntreprindere este constituit din dou zone:
a. Zona Back Office
Din punct de vedere informatic, aceast zon se caracterizeaz prin:
Importana fundamental a bazei de date, care poate fi situat
centralizat pe un singur server sau poate fi repartizat fizic pe
mai multe servere.
Particularitile aplicaiilor utilizate: o parte important dintre
acestea reprezint programe pentru tratarea n bloc a datelor
(de exemplu, tratarea n bloc a tuturor tranzaciilor unei zile
de lucru). O alt parte a aplicaiilor realizeaz gestiunea
tranzaciilor i au ca scop tratarea simultan a unor cereri din
partea unui numr mare de utilizatori.
Importana critic a prelucrrilor realizate, de care depinde
intreaga activitate a ntreprinderii.
Centralizarea pe un numr redus de servere pe care ruleaz
sisteme de operare dedicate.
Cea mai apreciat calitate a unui sistem de Back Office o reprezint
coerena i integritatea datelor. De asemenea, disponibilitatea continu a

sistemului i continuitatea serviciilor (chiar i n caz de cderi sau


defeciuni) sunt caracteristici eseniale ale oricrei aplicaii Back Office.
n cazul ntreprinderilor moderne, aplicaiile Back Office garanteaz
nsi funcionarea ntreprinderii, de aceea se impune existena unui sistem
de nalt securitate a datelor, att la nivel fizic, ct i la nivelul drepturilor de
acces.
b. Zona Front Office
Aplicaiile Front Office sunt acele produse pe care ntreprinderea le
ofer clienilor astfel nct s asigure servicii rapide. Principalele cerine la
care trebuie s rspund o aplicaie Front Office sunt:
Gestiunea relaiilor cu clienii (Customer Relationship
Management, CRM) cuprinde instrumente de administrare a
clienilor (consultarea dosarelor clienilor, culegerea de informaii
referitoare la operaiile efectuate de clieni pentru a le trimite spre
procesare aplicaiilor Back Office), precum i instrumente de
asistare a clienilor (evaluarea n funcie de o serie de criterii,
asisten n configurarea cererii i alte forme de asistare
interactiv a clienilor). Evaluarea clienilor dup o serie de
criterii (scoring) permite stabilirea gradului n care un client sau
un proiect poate satisface sau nu condiiile prevzute (de
exemplu, pentru acordarea unui credit). Aplicaiile de asisten n
configurarea cererii au ca scop propunerea, pe baza catalogului
furnizorului i a rspunsurilor la un set de ntrebri, variantele de
ofert cele mai adecvate la cererile exprimate de client.
Gestiunea agenilor de vnzri are ca scop gestiunea agenilor
de vnzri sub mai multe aspecte: cota din vnzrile totale,
performanele, realizarea cifrei de afeceri individuale i colective,
obinerea rezultatelor consolidate etc.
Gestiunea clienilor face parte din aplicaiile Front Office puse
la dispoziia centrelor de asisten din teritoriu i utilizeaz
tehnologii de integrare cu reeaua telefonic.
Instrumente de asistare a deciziei sun tincluse instrumente de
cutare i extragere de date, precum i aplicaii SIAD (Sistem
Interactiv de Asistare a Deciziei).
Gestiunea reelei de agenii este un complement al aplicaiilor
Back Office aprut datorit numrului mare de agenii i centre de
vnzri ale ntreprinderilor mari, mai ales multinaionale. Aceast
reea poate cuprinde sucursale proprii, cocesionari sau ali ageni
comerciali.

n ultima vreme, acestor dou zone ale ntreprinderii li s-au mai


adugat altele dou:
c. Zona Middle Office
Este o zon greu de definit la nivel fizic , care a primit n timp dou
accepiuni diferite:
ntr-o prim accepiune, aceasta reprezint zona de Back Office
prezent n cadrul fiecrei agenii sau centru de vnzri, zona
situat fizic n Front Office, dar ndeplinete funcii de Back
Office;
n a doua accepiune, aceasta reprezint componentele
intermediare ale ntreprinderii, cu rol de interfa ntre Front
Office i Back Office, pentru gestiunea reelei i transmiterea
datelor ctre aplicaiile centrale (aflate n Back Office).
Din punct de vedere informatic, aplicaiile de tip Middle Office sunt
cele care alimenteaz componentele menionate anterior. n condiiile
dezvoltrii unei arhitecturi client-server pe trei nivele (server central, servere
agenie i staii de lucru), componentele Middle Office ale sistemelor
informatice se pot gsi att pe serverele de agenie, ct i pe serverul central.
d. Zona Web Office
Mult vreme, procesarea tranzaciilor generate de serviciile la
distan s-a realizat separat de restul sistemului informatic. n prezent,
tehnologia World Wide Web a introdus o nou dimensiune a ntreprinderii,
numit generic Web Office, care completeaz Front Office i Back Office i
d posibilitatea conectrii la sistemul informatic al ntreprinderii din orice
punct de pe glob.
Prin Web Office se integreaz mai multe tipuri de aplicaii:
Aplicaii interne ale ntreprinderii destinate exclusiv
personalului din ntreprindere, accesul din afar fiind blocat n
general prin aplicaii de tip firewall. Aceste aplicaii pot
furniza servicii multiple: coordonarea i gestiunea proiectelor,
mesagerie intern, agend de grup, diverse tipuri de urmrire
la distan a activitii, videoconferin, etc. Se folosesc
tehnologii Intranet, care presupun utilizarea tehnologiilor
Internet mpreun cu produse de securitate care s protejeze
domeniul i s blocheze accesul neautorizat din interior sau din
afar.
Aplicaii accesibile partenerilor destinate partenerilor n sens
larg (furnizori, clieni, reseller-i, consultani etc.). Acestea
utilizeaz servere Extranet i ofer servicii echivalente cu

aplicaiile interne, dar destinate utilizatorilor externi ai


ntreprinderii.
Aplicaii accesibile publicului larg asigur accesul public la
serviciile ntreprinderii, serverele Internet realiznd o extindere
a activitii ntreprinderii spre staiile de lucru ale partenerilor
prin intermediul cataloagelor on-line cu imagini ale produselor,
plilor securizate prin carte de credit sau portofel electronic
etc.
Nivelul de securitate al componentelor Intranet, Extranet i Intranet
este diferit, dar nu trebuie neglijat pentru nici una dintre aceste trei zone.
Este de dorit s se asigure protecia datelor de consultat i s se identifice n
orice moment persoanele care navigheaz. Acest lucru poate fi realizat prin
oferta de abonamente pentru accesul la informaii, abonamente care pot fi
gratuite sau nu, n funcie de serviciile oferite.

1.3. Probleme ale integrrii


Problema integrrii sistemelor informatice existente n cadrul unei
ntreprinderi este greu de formalizat deoarece pleac de la situaii foarte
diferite. n principal, integrarea sistemelor informatice conduce la apariia a
dou mari tipuri de probleme:
.a Probleme tehnice
Problemele tehnice sunt datorate eterogenitii soluiilor hardware i
software i diversitii tehnologiilor utilizate de diversele sisteme
informatice din cadrul ntreprinderii. Problemele tehnice genereaz o
discontinuitate de comunicaie ntre sistemele informatice.
Pentru rezolvarea acestei probleme, companiile furnizoare de soluii
hardware i software au un aport important, acestea fiind direct interesate de
succesul integrrii propriilor produse cu produsele altor companii.
.b
Probleme informationale
Problemele informaionale sunt datorate inconsistenei datelor i duc
la apariia unei discontinuiti semantice i structurale ntre sistemele
informaionale.
Inconsistena datelor este rezultatul modului n care au fost
dezvoltate aplicaiile informatice. La realizarea acestor aplicaii s-a ignorat
c ar putea exista alte aplicaii care s necesite acces la datele create sau
ntreinute de aplicaia respectiv. Alte cauze ale inconsistenei datelor sunt
8

lipsa unei terminologii standard de definire a conceptelor i proceselor de


afaceri la nivelul ntreprinderii i faptul c sistemele care utilizeaz
tehnologii nvechite (sistemele motenite) nu au implementate mecanisme
riguroase pentru declararea i constrngerea respectrii regulilor de afaceri.
Soluionarea inconsistenei datelor presupune:
.i Identificarea discrepanelor i conflictelor posibile
Discrepanele din date apar datorit reprezentrii n mod diferit a
unor date similare n sisteme diferite, lucru care poate conduce la
conflicte. Diferenele pot fi:
Diferene de nume;
Diferene de natur i dimensiune;
Diferene de domeniu;
Diferene structurale.
.ii Politici de soluionare a inconsistenelor
Utilizarea uneia din valorile inconsistente fr avertizarea
utilizatorului;
Prezentarea tuturor valorilor inconsistente utilizatorului,
indicnd sursa informaiilor i lsnd la latitudinea
utilizatorului soluionarea problemei;
Utilizarea celei mai recente valori, pe baza unei mrci de
timp care indic momentul actualizrii informaiei;
Utilizarea informaiei din sistemul cel mai de ncredere, pe
baza evalurii gradului de ncredere al datelor din diferite
aplicaii;
Utilizarea unei mrimi agregate pe baza valorilor
inconsistente (medie aritmetic, minim, maxim etc).
O alternativ ar fi includerea n logica de acces la datele unei
aplicaii din alte aplicaii, respectiv n logica de migrare a datelor dintr-o
aplicaie n alta, a mecanismelor de tratare a conflictelor. De exemplu, pot fi
utilizate tabele de coresponden sau formule de conversie, precum i
mecanisme de implementare a politicilor de soluionare a inconsistenei
datelor .

1.4. Infrastructura de integrare


Modelul conceptual al unei organizaii cuprinde:
9


arhitectura sistemului de afaceri (operaional i strategic),

arhitectura sistemului informaional i

arhitectura sistemului informatic.


Lipsa unei arhitecturi de integrare a sistemelor informatice a fcut ca
adesea cerinele de integrare s fie rezolvate prin stabilirea unor interfee
individuale ntre dou sisteme (integrare punct la punct). Cum numrul de
aplicaii care trebuie integrate crete n permanen, se ajunge inevitabil la o
reea de perechi de conexiuni, foarte dificil de ntreinut i dezvoltat.
Aceast soluie este uor de implementat, deoarece necesit o
abstractizare redus a datelor i proceselor. Dar, pe termen lung, integrarea
punct la punct nu asigur flexibilitatea necesar adaptrii la cerine noi
care pot s apar. Soluiile izolate i punctuale, rezolv o situaie de
moment, chiar printr-o tehnologie inovatoare, dar pe termen lung conduc la
rigiditatea ntreprinderii datorit complexitii soluiei care devine dificil de
implementat i gestionat.
Pentru ca comunicarea i colaborarea ntre aplicaii s se poat
dezvolta eficient este necesar dezvoltarea unei infrastructuri de integrare a
sistemelor la nivelul ntreprinderii. Aceast infrastructur trebuie s
promoveze metode care s permit sistemelor partajarea de informaii far
s mai fie nevoie ca fiecare sistem s fie conectat cu toate celelalte.
Alegerea unei soluii care evit utilizarea integrrii punct la punct
i asigur un management centralizat al integrrii va conduce la reducerea
efortului de realizare i ntreinerii a infrastructurii de integrare a sistemelor
informatice.
Aadar, infrastructura de integrare a aplicaiilor asigur un cadru
centralizat, scalabil, gestionabil pentru integrarea tuturor sistemelor din
cadrul ntreprinderii, independent de caracteristicile tehnologice ale
aplicaiilor, bazelor de date sau sistemelor de operare. Infrastructura de
integrare va permite ntreprinderii s gestioneze sisteme informatice
complexe, s adapteze sau s mbunateasc ntr-un timp scurt aplicaiile i
s reduc costurile de ntreinere a infrastructurii tehnice la nivel de
ntreprindere [MATT99][DONN 99] .
Eficiena soluiei de integrare este furnizat de scalabilitatea sa i de
uurina de gestionare n cazul adugrii/modificrii sau eliminrii de
sisteme n cadrul acestei infrastructuri .
Pentru a evita apariia unor situaii neprevzute i asumarea unor
riscuri importante, se recomand o abordare incremental n implementarea
i testarea infrastructurii de integrare la nivelul ntreprinderii.
n lipsa unei metodologii de elaborare a infrastructurii de integrare
se va impune ca cerin minim respectarea urmtoarelor etape:
10

a. Definirea scopului integrarii


Identificarea acestui scop presupune definirea problemei de afaceri
care trebuie rezolvat. Scopul integrrii sistemelor informatice trebuie s fie
definit la nivelul ntreprinderii, nu al sistemelor individuale. La realizarea
planului de integrare trebuie s inem seama n primul rnd de obiectivele de
afaceri i prioritatea acestora. Planurile de integrare trebuie s in cont de
probleme pe termen lung, cum ar fi implicaiile modificrii sistemelor
existente asupra soluiei de integrare.
b. Definirea strategiei de integrare
Definirea strategiei de integrare a sistemelor informatice la nivelul
ntreprinderii trebuie s in cont de nevoia de flexibilitate n momentul
adugrii/modificrii/eliminrii uneia dintre
aplicaiile integrate. De
asemenea, aplicaiile existente trebuie s fie ct mai puin afectate de
procesul integrrii, mai ales dac este vorba despre sisteme operaionale cu
cerine speciale de performane i siguran.
O soluie complet de integrare a sistemelor informatice la nivelul
ntreprinderii trebuie s includ tehnologii att pentru integrare la nivelul
datelor, ct i la nivelul proceselor de afaceri. Despre diferitele tipuri de
integrare i tehnologii utilizate pentru realizarea acestora se va vorbi n
capitolul 2.
Datorit utilizrii unei infrastructuri strategice de integrare a
sistemelor informatice, ntreprinderea poate beneficia de o viziune complet
asupra datelor operaionale sau suport de decizie din toate bazele de date,
aplicaiile i sistemele, de la cele motenite pn la platformele de
integrare. O arhitectur de integrare ofer puterea de transformare, controlul
interfeelor i scalabilitatea necesar pentru a elimina haosul din reeaua de
interfee i a oferi o flexibilitate real n implementarea proceselor de
afaceri.
c. Definirea soluiilor de integrare a sistemelor motenite
Integrarea sistemelor motenite, care utilizeaz o tehnologie
nvechit trebuie tratat distinct, prin interfee formate din componente
configurabile, capabile s asigure metodele pentru acces la tranzaciile i
datele de pe mainframe-uri. De obicei, mijloacele necesare pentru aceste
interfee sunt oferite de productorii de soluii de integrare. Exist trei tipuri
de interfee:

Interfa obiect, numit wrapping, pentru tranzaciile i


datele de pe mainframe. Se recomand pentru integrarea
aplicaiilor operaionale cu aplicaii Web.

11

Maparea metodelor de acces specifice mainframe-lui la o


interfa extern cu ajutorul metadatelor. Un exemplu l
constituie interfeele care folosesc tehnologia XML.

Interfee standard de acces la baze de date, de exemplu SQL


sau ODBC. Se recomand pentru conectarea aplicaiilor
mainframe cu aplicaiile client-server pe dou niveluri.
Pentru o ntreprindere de mari dimensiuni, se recomand o strategie care s
combine toate cele trei abordri.
Problema central n cazul sistemelor motenite provine din faptul c
acestea au fost proiectate pentru a procesa cereri n mod secvenial sau la
cerere. Ele nu au fost construite pentru un mediu eterogen de execuie
distribuit. Ca urmare, va fi necesar gsirea unui mod de simulare a
notificrii evenimentelor specifice sistemelor bazate pe schimburi de
mesaje.

1.5. Evoluia aplicaiilor integrate de gestiune a firmelor


Schimbrile tot mai rapide din mediul de afaceri i creterea n
complexitate a activitilor din cadrul unei companii necesit o adaptare
permanent, ntr-un ritm alert, care, adeseori, pune la ncercare capacitile
de efort i analiz ale factorului uman. Sistemele ERP (Enterprise Resource
Planning) au fost create ca soluie la aceste provocri, fiind capabile s
proceseze un volum foarte mare de date i informaii agregate n scopul
optimizrii i eficientizrii proceselor. Ideea central n evoluia sistemelor
de aplicaii pentru ntreprindere este caracterul evolutiv. Punctul de plecare
n evoluia actualelor aplicaii pentru ntreprindere l constituie anii 60 i
apoi, pe parcursul a patru decenii, urmnd ndeaproape dezvoltrile din
domeniul sistemelor hardware i software, a continuat evoluia pn la
sistemele ERP.
Anii 60 se caracterizeaz prin faptul c majoritatea ntreprinderilor
realizau aplicaii centralizate, prin fore proprii, ceea ce presupune c
proiectarea, dezvoltarea i implementarea lor era fcut inhouse. Cele mai
multe aplicaii se axau pe controlul stocurilor i automatizarea gestiunii, dar
se ncerca i crearea aplicaiilor pentru calculul automat al salariilor i
pentru contabilitate general. Ca i limbaje de programare folosite n acea
perioad menionm COBOL, ALGOL i FORTRAN.
n anii 70, urmeaz conturarea sistemelor Material Requirements
Planning (MRP). n literatura de specialitate [FOHU04], aceste aplicaii
sunt considerate ca un set de tehnici care utilizeaz inventarul, datele despre
12

stocuri i programul de producie pentru calculul necesarului de materiale,


lansarea aprovizionrii i asigurarea acesteia pe parcursul procesului de
fabricaie. Vzute prin prisma trecerii timpului i a evoluiei de la aplicaiile
simple de control al stocurilor, aplicaiile MRP au reprezentat metamorfoza
sistemului de control al stocurilor sub influena calculatorului i a
aplicaiilor acestuia.
Odat cu maturizarea sistemelor MRP-uri, anii 80 au marcat
evoluia spre MRP II sau Manufacturing Resource Planning care este
conceput n jurul ideii de optimizare a proceselor de fabricaie prin
sincronizarea necesarului de materiale cu cerinele produciei. Zonele de
aplicaie a acestor sisteme s-au extins mult peste departamentul produciei i
au ajuns s aib aplicabilitate i departamentele: financiar, resurse umane,
distribuie, vnzare, gestiunea proiectelor.
La acel moment, MRP II era soluia pentru planificarea eficient a
tuturor resurselor ntreprinderii i asigura planificarea operaional a
necesarului care susine procesele de producie, planificarea financiar i
elaborarea de scenarii de tipul ce ar fi dac?. Funciunile integrate ale
acestor sisteme vizau: planificarea produciei, planul de vnzri,
programarea produciei, planificarea necesarului de materiale, planificarea
capacitilor de producie, ca i urmrirea execuiei aprovizionare,
fabricaie, vnzare. Deosebit de importante sunt ieirile oferite de aceste
sisteme: rapoarte financiare, plan de vnzri, plan de aprovizionare, proiecii
de stocuri, buget de expediie i transport.
Pe baza acestor ctorva caracteristici prezentate, putem afirma faptul
c MRP II nu este doar un instrument de planificare i urmrire a produciei,
el fiind un sistem mult mai complex care a evoluat ctre ceva i mai
cuprinztor i anume, Enterprise Resource Planning. n [FOHU04] se
arat c la acel moment s-a propus un alt nume, care a funcionat pentru un
timp: BRP (Business Resource Planning), denumire care subliniaz faptul
c este mai mult dect un sistem care se adreseaz exclusiv produciei.
Potrivit
resurselor
de
pe
internet,
i
anume
site-ului
www.technologyevaluation.com , cei care au introdus conceptul de ERP
sunt cei de la Gartner Group.
Deci, sfritul anilor 80 i anii 90 au fost marcai de apariia
sistemelor ERP, ele fiind rezultatul extinderii funcionalitii suitelor
MRPII. Avnd ca i punct de plecare, fundaia tehnologic a MRP II,
sistemele ERP integreaza toate procesele economice: producie, distribuie,
contabilitate, financiar, personal, stocuri, service i ntreinere, logistic i
gestiune proiecte, asigurnd consistena informaional, accesul i
vizibilitatea n ntreaga organizaie.

13

Meninnd caracterul evolutiv, productorii de soluii ERP, au


adugat suitelor lor, noi module i funcionaliti, i s-a produs astfel
trecerea la o nou etap n evoluia sistemelor ERP i anume ERP extins.
Anii 2000 sunt caracterizai prin aplicaii precum APS (Advanced Planning
and Scheduling), soluii e-business pe zona relaiilor cu clienii CRM
(Customer Relationship Management) sau pe furnizori-aprovizionare
SCM (Supply Chain Management). Tot n acest perioad au aprut i
concepte noi, cum sunt BPI (Business Process Integration), EAI (Enterprise
Application Integration), ENS (Enterprise Nervous System).
Pentru a ilustra grafic evoluia sistemelor ERP de-a lungul celor 4
decenii, prezentm, n continuare, urmtoarea figur:

Figura 1.1 Evoluia aplicaiilor integrate de gestiune a firmelor


( prelucrare i adaptare dup [FOHU04] )

1.6. ERP (Enterprise Resource Planning)


1.6.1. Ce este un sistem ERP?
Un ERP, considerat expresia cea mai fidel a iterdependenei dintre
economic i tehnologia informaional, reprezint o infrastructur software, multimodulara ce ofer suport de gestiune i coordonare a diferitelor structuri i procese
din companie, n vederea realizrii obiectivelor de afaceri [FOHU04]. Scopul
unui sistem ERP (sistem de gestiune integrat a proceselor de afaceri) este
realizarea unei mai bune comunicri n companie, mbuntirea cooperrii i
interaciunii dintre diferite departamente precum cele de planificare a produciei,
14

achiziii, producie, vnzri i relaii cu clienii. Pe scurt, un sistem de gestiune a


companiei de tip ERP reprezint planificarea celor 4 factori determinani pentru o
afacere de succes: factorul uman, financiar, tehnic i de resurse (cei 4 M - Man,
Money, Machines i Materials), dupa sursa http://www.cio.com/research/erp/.
Davenport T.H., specialist de renume n domeniile de management i
sisteme informaionale pentu afaceri propune ca definiie pentru ERP: un pachet
care promite integrarea complet a tuturor informaiilor din cadrul unei
oraganizaii [FOHU04]. Acest concept este ilustrat n Figura 1.2.
Vnzri i
distribuie

CLIENT

Financiarcontabilitate
Baz de date
unic

Figura

Service front-office
Aplicaii
postvnzar
1.2 Schema
conceptual
e

FURNI
ZORI
Productie
Aplicaii back-office

unui sistem ERP


[RASH02]
Stocuri

ERP integreaz toate procesele economice: producie, distribuie,


contabilitate, finaciar, personal, stocuri, service i mentenan, logistic,
gestiune de proiecte, oferind accesabilitate, vizibilitate i consistena
informaional n ntreaga organizaie. ERP nseamn integrarea tuturor
aplicaiilor ntr-o soluie global, care acoper toate procesele intercorelate
prin care concretizeaz activitatea organizaiei, eliminnd graniele dintre
departamente i delimitrile funcionale, ca i pe cele ale organizaiei cu
mediul i oferind posibiliti de lucru multiutilizator, multiscop i
multispatiu.
Prin definiie, un sistem de tip ERP reprezint o soluie software
complex, bazat pe arhitectura client-server ale crei elemente sunt
integrate ntr-o platform comun, pentru gestionarea resurselor companiei,
prelucrarea tranzaciilor i facilitarea integrarii tuturor procelor necesare n
cadrul unei afaceri, centralizndu-le, facilitnd mprtirea datelor i
eliminnd redundana [FOHU04]. Fiecare pachet ERP ofer funcionaliti
diferite pentru industrii diferite.
Provocarea principal const n integrarea tuturor proceselor
economice i optimizarea resurselor disponibile.
Sistemele ERP actuale realizeaz integrarea tuturor funciilor de
conducere ale unei companii, plecnd de la :
planificare;
asigurarea stocului de materii prime i materiale;
15

definirea tehnologiilor;
coordonarea proceselor de producie;
gestiunea financiar- contabil, a resurselor umane, a stocurilor
de produse finite;
dezvoltarea i meninerea relaiilor cu clienii i partenerii de
afaceri.
Un astfel de sistem permite factorilor de decizie realizarea unor
analize complete asupra realizrii planului de afaceri. Prin opiunile de
simulare a activitilor i prin caracterul flexibil i dinamic al aplicaiilor se
pot realiza :
planuri de previziune;
evaluri i predefiniri ale tendinelor de evoluie ale industriei
din care face parte compania;
analize calitative;
integrarea cu noile tehnologii e-business;
comunicare on-line.
La implementare, sistemele ERP includ o serie de caracteristici de
baz. Sunt instalate pe un sistem de gestiune a bazelor de date.
Platformele de baze de date folosite cel mai frecvent sunt: Oracle, DB2,
Informix, MS SQL Server, SQL Base i Sybase. Baza de date necesit o
setare iniial conform proceselor organizaiei i trebuie sa asigure acces
direct la informaii n timp real (avantajul bazelor de date unice) pentru toi
membrii organizaiei. Odat terminat instalarea, utilizatorii introduc datele,
informaiile fiind transferate prin intermediul proceselor la alte module. n
final, sistemele ERP includ instrumente de raportare periodice sau realizate
ad-hoc.
Aplicaiile ERP sunt realizate cu ajutorul instrumentelor CASE,
care simplific munca programatorilor, prelund regulile i genernd
automat codul surs. Avantajele sunt:reducerea timpului de dezvoltare i
obinerea unui produs de calitate, prin minimizarea erorilor. n plus,
utilizarea instrumentelor CASE sprijin consistena aplicaiilor i
standardizarea sub aspect funcional.
Sub o form simplificat un sistem ERP poate fi definit prin prisma
a dou proprieti fundamentale: funcionalitatea i integrarea.

16

Figura 1.3 Reprezentarea simplificat a unui sistem ERP


Cele dou pri se condiioneaz reciproc.
Integrarea asigur conectivitatea ntre fluxurile de procese economice
funcionale. Ea poate fi gndit ca o tehnic de comunicare.Cteva modaliti
obinuite prin care comunicarea are loc prin i pentru integrare sunt: codul surs,
reele locale i extinse de calculatoare, Internet, e-mail, workflow, instrumente de
configurare automat, protocoale, baze de date. Putem spune c integrarea este
realizat prin comunicare, iar comunicarea este realizat prin integrare.
Partea funcional a unui sistem ERP asigur fluxurile de procese
economice din cadrul fiecrei funciuni. Astfel, n cadrul unei suite ERP se
regsesc de la cteva, pn la zeci de module funcionale (contabilitate general,
debitori, salarii, stocuri, aprovizionare, planificarea produciei, logistic, comenzi
i vnzare) [FOHU04].
1.6.2 Arhitectura unui sistem ERP
Sistemul aplicaiilor de ntreprindere se implementeaz pe o
arhitectura de tip client-server care creeaz premisele unui mediu de
prelucrare descentralizat. Dup cum este prezentat i n lucrarea [FOHU04],
modelul de arhitectura implementat de ctre sistemele ERP este cel cu trei
straturi, ilustrat n figura urmtoare:

17

Figura 1.4 Arhitectura cu trei niveluri a unui sistem ERP


Caracterizarea funciunilor celor trei niveluri ale arhitecturii:
Nivelul prezentare const n interfaa grafic utilizator sau
programul de navigare (browser) pentru accesarea funciilor sistemului.
Nivelul aplicaie cuprinde regulile afacerii, logica i funciunile
sistemului, programele care asigur transferul datelor de la / la serverele de
baze de date.
Nivelul bazei de date - asigur gestiunea datelor organizaiei,
inclusiv a metadatelor; cel mai adesea se regsete aici un SGBD relaional
dintre cele standardizate industrial, care include i modulul SQL.
Aceast structurare logic permite ca interfaa sistemului ERP s
ruleze pe calculatorul utilizatorului, prelucrarea s se realizeze pe nivelul de
mijloc al serverelor de aplicaii, iar sistemele de baze de date s
funcioneze pe al treilea strat, al serverelor specializate.
1.6.3. Componentele principale ale unui sistem ERP
Analiznd sistemele ERP dezvoltate pana n prezent, pot fi
evideniate o serie de componente care intr n componena acestora :

18


Nomenclatoare (fiiere de baz) de clieni, furnizori, personal
sub forma unor fiiere care reunesc toate datele de descriere a acestora i
interfaeaz cu oricare modul care se servete de aceste date.
Contabilitate general sau componenta financiar-contabil.
Componenta asigur conducerea evidenei contabile i gestiunea financiar.
Funcionalitaile acestei componente vizeaz: automatizarea nregistrrii
informaiilor financiar-contabile preluate din documentele primare, cu
preluarea automat a datelor din alte aplicaii ale sistemului ERP i
realizarea evidenei contabile complete, la nivel sintetic i analitic. De cele
mai multe ori, componenta acopera doar cerinele contabilitaii financiare,
asigurnd n primul rnd obinerea documentelor contabile de sintez cerute
de legislaia n vigoare i poate fi completat printr-o component de
analiz, tip tablou de bord, care ofer informaii privind performanele
firmei.

ncasri-pli. Aceast componet poate aprea sub forma a


doua module: Debitori i Creditori, care gestioneaz i nregistreaz
creanele i datoriile ntreprinderii.

Salarizare. Component legat adesea de componenta resurse


umane, avnd ca obiect calculul i evidena salariilor. Sunt automatizate
calculul taxelor, al contribuiei la bugetul statului i asigurrilor sociale.

Resurse umane. Componenta care sprijin crearea unei politici


de personal, susinnd activitaile de recutare i selecie a personalului;

Imobilizri. Gestioneaz mijloacele fixe, dar i obiectele de


inventar sau activele necorporale. Gestiunea acoper ntreaga durat de
utilizare a activului i se poate afla n orice moment care este starea acestuia
i operaiile efectuate asupra lui (intrare, modernizare, modificare,
reevaluare, scoatere din funciune, casare). Ofer multiple posibilitai de
calcul i ntregistrare a amortizrii (liniar, degresiv, accelarat). Deosebit
de utile sunt rapoartele generate, impuse de legislaia n vigoare sau
necesare conducerii.

Planificare-producie.
Planificarea
vizeaza
executantul,
termenul, articole de realizat, costul programat i detaliile tehnice.

Urmrire producie (uneori livrat ntr-o singur component


mpreun cu Planificarea). ntregistreaz preluarea notelor de predare i a
rapoartelor de lucru, analizeaz i compar comenzile lansate, ofer rapoarte
cumulate ori detaliate ale produciei, pe faze sau pe produse/lucrri, precum
i rapoarte de costuri.

Gestiune date tehnice. Componenta stocheaz definiiile i


caracteristicile tehnice ale produselor i tehnologiilor de fabricaie.
19


Planificare necesar de materiale. Cu ajutorul acestei
componente se determin automat cantitile de materiale necesare, pe baza
datelor despre procesul de fabricaie i a planului de producie aprobat.

Planificare i urmrire consumuri i costuri. Componenta


ntocmete bonurile de consum i preia datele despre consumuri de la
magazii, centralizeaz aceste date pentru calculul costurilor, genereaz
rapoarte detaliate sau centralizate cu privire la consumurile planificate si
realizate.

Managementul proiectelor. Componenta are ca obiect proiectele


de investiii, activitile interne sau lucrrile efectuate de teri: planificarea
(bugetarea), finanarea i urmrirea executrii acestora.

Stocuri. Componenta permite gestiunea cantitativ i calitativ a


stocurilor i generarea automat a documentelor contabile.

Gestiunea depozitelor (inclus adesea n modulul de Stocuri).


Componenta definete din punct de vedere organizatoric unitile de stocare:
tipurile de inventar i subinventar, depozite, magazii, locaii, modul de
localizare al stocurilor.

Aprovizionare (Furnizori). Componenta depsete atribuiile


unei aplicaii de gestiune, fiind un instrument de optimizare a aprovizionrii,
care poate determina realizarea de economii. Modulul Aprovizionare se
leag de componenta Stocuri.

Vnzri. Componenta gestioneaz activitaile specifice


procesului de vnzare.

ntreinerea echipamentelor (mentenana). Aceast component


rezolv gestiunea tehnic i urmrirea modului de utilizare a
echipamentelor, permite planificarea resurselor i costul lucrrilor. Foarte
important este istoricul activitailor de ntreinere i reparaii.

Transport (Logistic). Aceast component permite planificarea


i gestionarea activitailor logistice din procesele de vnzare i distribuie.

Service/Servicii. Aceast component urmrete garaniile i


serviciile postvnzare.

Analiza (Business Intelligence). Modulul preia datele din baza


de date, realizeaz diferite analize i furnizeaz informaiile n forma dorit
de utilizator. Cele mai puternice opiuni sunt analizele multidimensionale(OLAP), simulrile, scenariile i prognozele.

Soluii specifice fiecrei industrii

Generatorul de rapoarte. Acest instrument permite utilizatorilor


obinerea rapoartelor dorite n cadrul fiecrui modul funcional folosind
datele din baza de date a sistemului ERP.
20

1.6.4. Implementarea unui sistem ERP


Adoptarea unui sistem ERP este o decizie dificil pentru orice
organizaie. Succesul unui proiect ERP nu depinde de ans. Alegerea celei
mai potrivite soluii, instruirea personalului i planificarea resurselor
sunt trei din cele condiiile eseniale pentru implementarea reuita i
utilizarea n condiii de eficien maxim.
A. Decizia de implementare a unui sistem ERP trebuie s fie
fundamentat pe baza unui set de criterii foarte precise de selecie i analiz
comparativ a mai multor variante de aplicaii, cum ar fi:

obligativitatea respectrii cadrului legal al fiecrei ari, dar i


alinierea la legislaia i normele europene;

posibilitatea operarii n moned naional, implementarea


monedei unice europene, dar i lucrul facil cu alte valute;

prelucrri n timp real;

structura modular a software-ului aplicativ care s permit


implementarea etapizat i extinderea ulterioara a ariei funcionale
acoperite;

independena de platforma hardware;

caracteristicile funcionale;

asigurarea unui nivel nalt al securitaii i integritaii datelor;

minimizarea riscurilor, avantajele directe i posibilitatea


justificrii clare a investiiei.
Integrarea este principalul deziderat al unui proiect ERP. n teoria
oraganizaional integrarea definete nivelul de colaborare ntre indivizi, ca
i ntre entiti. ntr-o organizaie, indivizii i formeaz un mod particular
de abordare, gndire i rezolvare a sarcinilor de lucru, corespunztor
educaiei i experienei fiecruia. Abordrile pot fi uneori conflictuale, de
aceea se ateapt ca integrarea s asigure coordonarea i colaborarea
ntre indivizi prin instrumente specifice.
B. Dup decizia de adoptare a unui sistem ERP, urmeaz cea de
selecie a celei mai potrivite soluii, ilustrat sub forma unei scheme logice n
Figura 1.4. Alegerea celei mai potrivite soluii pentru o organizaie
constituie o decizie semi-structurat, ntruct numai o parte a problemei
poate fi tratat prin intermediul unei proceduri clar definite. Nu exist o
procedur formal unanim acceptat pentru acest proces decizional. Pe lng
dificultile procesului de evaluare, o alt problema este analiza celor mai
21

adecvate criterii de selecie. Criteriile de selecie pot fi ncadrate n cteva


mari categorii:
Dimensiunea afacerii i amploarea proiectelor viitoare ;
Infrastructura tehnologica si necesarul de investiii impus de
acest proiect;
Specificul activitii desfsurate este unul dintre cele mai
importante criterii. Presupune cercetarea cazurilor similare de pe
piaa. Prezena aplicaiilor verticale (sau dedicate) care au fost
scrise special pentru un domeniu de activitate nu va fi neglijat. Se
poate opta pentru verticale pentru c ofer avantajul coninutului
mare de cunotine ncorporate (experiena companiilor care au
,,deminat terenul" i au avut succes);
Gradul de dispersie geografic, astfel nct, dac investiia se
dovedete a fi deosebit de costisitoare, se poate opta pentru
sistemul implementrii n cascad, caz n care vorbim de o
structurare IT/ERP pe dou niveluri. Aceast structurare ofer
avantajul unui mecanism perfect de funcionare pentru companiile ce
dezvolt relaii la nivel transnaional: un nivel superior
corespunztor filialelor mari i locaiei principale, acoperit de
aplicaii puternice ERP (ex. SAP R/3 Systems, Oracle Applications)
i nivelul inferior acoperit de soluii flexibile care ofer garania
competitivitii la un cost sczut de achiziie i ntreinere, destinate
filialelor mici (ex. Scala, Siveco);
Structura aplicaiilor existente vizeaz un complex de probleme
dintre care amintim: redundana i inconsistena datelor, dificultatea
accesului la bazele de date, fenomenele de izolare a datelor,
complexitatea deosebit a actualizrilor, problemele de securitate i
de integritate a datelor, imposibilitatea, inflexibilitatea n fa
modificrilor curente i modelarea corect a afacerii.

22

Figura 1.5 Modelarea deciziei de selecie [RASH02]


C. Activitile de selectare i implementare a unui sistem ERP se
constituie
ntr-un
mediu
de
(re)construire
a
valorilor
organizaiei.Urmtoarele principale activiti se succed n implementarea
ERP [FOHU04]:
Educarea managerilor i acionarilor - cunoaterea fenomenelor
tehnologice, a specificului i avantajelor ERP creeaza o atitudine
pozitiv fa de proiect.
Formarea echipei proiectului - n cazul unui buget limitat se poate
merge pe o soluie mixt, care s combine cunotinele experilor cu
avantajul terenului propriu al specialitilor firmei. Figura 1.6
prezint o posibil configuraie de echip ERP.

23

Figura 1.6 Configuraia unei echipe ERP [ANDE2000]


Analiza cerinelor - este procesul care determin cerinele
informaionale
ale
oraganizaiei,
adresndu-se
tuturor
caracteristicilor funcionale majore.
Planul de integrare al afacerii - este realizat n mai multe sesiuni
de lucru, combinnd cerinele informaionale stabilite cu
specificaiile funcionale (curente i pe termen lung) necesare
strategiei afacerii. Echipa proiectului gndete i stabilete ce poate

24

software-ul s rezolve i cum anume(far a intra n detalii de


implementare).
Stabilirea viziunii i obiectivelor proiectului - vizunea arat
asteptrile organizaiei, innd seama de interaciunea sistemului
ERP cu funciunile afacerii.
Pregtirea i instruirea echipei proiectului - constituie extensia
activitilor premergtoare de educare. n aceast faz poate fi
ntocmit un plan detaliat al proiectului.
Studiul ofertei de soluii ERP - presupune solicitarea de
informaii, direct sau prin parcurgerea ofertelor.
Fezabilitatea economic a proiectului este dat n principal de rata
de recuperare a investitiei (ROI-Return On Investment) i reprezint
analiza deciziei de invetiie a unor sume importante ntr-un sistem
nou.
Cererea de oferta adresat furnizorilor de ERP - reunete ntrebri
concrete care privesc funcionalitatea sistemului. Acurateea i
descrierea detaliat a cerinelor sunt eseniale pentru ntocmirea
cererii de ofert.
Evaluarea resurselor hardware - este un proces complex, deosebit
de important. Cea mai frecvent modalitate de lucru este
completarea de chestionare primite de la furnizorii ERP.
Vizitele de lucru ale furnizorilor ERP - constituie o oportunitate
pentru ca acetia s nteleag modul de desfurare a activitii
economice a firmei.
Demonstraii ale soluiilor software - permit managerilor i
acionarilor firmei s-i formeze opinii mai clare, s pun ntrebri
i s nteleag modul de funcionare a soluiilor.
Sesiunile de planificare anticipat - Stabilesc informaii detaliate
despre domeniul acoperit, timpul i resursele necesare pentru a
implementa soluia unui anume furnizor ERP. Sunt alese modulele
de implementare i se discut timpul i resursele necesare.
Procesul de luare a deciziei - implic managerii i acionarii firmei
care evalueaz informaiile adunate. Decizia poate fi luat n
unanimitate, dac toat lumea voteaza aceeai soluie sau poate fi
controversat, dac sunt susinute dou sau mai multe soluii.
ntocmirea i semnarea contractului ntre firma beneficiar i
furnizorul ERP - semnarea contractului (pot fi contracte individuale
pentru resurse hardware, software i service sau un singur contract

25

ce reglementeaz situaia tuturor resurselor) legifereaz acordul


formal ntre cele dou prti de implementare a noului sistem .
Planificarea proiectului - punctul de pornire este planul ntocmit n
sesiunea de planificare anticipat, acesta fiind acum reevaluat,
extins i completat. Rezultatul acestei faze se constituie n intrare
pentru faza urmtoare.
Planificarea de detaliu - planul descrie modulele funcionale i
planul de instalare, cu termene de realizare concrete. Dup
detalierea tuturor componetelor, planul poate fi transpus n format
electronic, cu ajutorul unei aplicaii de management al proiectelor.
Cel mai adesea se obine o Diagrama Gantt ce ilustreaz calendarul
proiectului.
Activitile de instruire ERP - orele de instruire ERP au ca scop
ntelegerea specificului unui sistem ERP de ctre membrii echipei
din punct de vedere funcional i modul concret n care
interacioneaz cu funciunile economice.
Configurarea aplicaiilor - este sarcina furnizorului ERP, care se
informeaz asupra modului de desfurare a activitii.
Administrarea ntrebrilor se poate face n trei moduri: manual,
semiautomat i automat. Pentru succesul implementrii este
esenial ca echipa proiectului i utilizatorii s fie edificai asupra
soluiei ERP, iar furnizorii asupra specificului firmei i activitilor
economice.
Stabilirea politicii de proiect - urmrete crearea unui cadru
director pentru tratarea conflictelor, ntr-un document sunt
specificate toate procedurile formale(regulile).
Discutarea rapoartelor - se concretizeaz n comparaii ntre
rapoartele curente i cele generate de noul sistem, din trei puncte de
vedere: selecia datelor, ordonarea i afiarea lor. n cazul
reproiectrii proceselor economice, modificrile de fluxuri
genereaz schimbri n partea de raportare . Sunt discutate
modificrile i este stabilit noul format.
Maparea funcional au loc activiti cu un caracter interactiv i
presupun mai multe discuii; este necesar vizualizarea
modificrilor i a rezultatelor pe parcurs prin reprezentarea grafic
a fluxurilor.
Prototipizare i testare- sunt preluate rezultatele fazei de mapare
funcional pentru a stabili dac pachetul de programe acoper harta
funcional schiat.
26

Modificarea i adaptarea cerintelor - asigur extinderea


caracteristicilor funcionale ERP. Modificrile sunt operate dup ce
maparea funcional i prototipizarea au demonstrat c aplicaia nu
poate realiza funcia respectiv.
Conversia datelor - este una dintre cele mai sensibile faze ale
proiectului, datorit dificultaii de a prelua datele din bazele de date
curente n noul sistem. Se opereaz, de regul, cu dou modalitai
de conversie: introducerea manuala (dei consumatoare de timp, are
avantajul asigurrii integritii datelor prin testare, ceea ce nu se
ntmpl la conversia electronic) i introducerea automat
(conversia automat). Se pot folosi utilitare de conversie a bazelor
de date dac este cert integritatea datelor din baz de date a firmei.
Asigurarea integritii este foarte important deoarece absena ei
poate compromite funcionalitatea aplicaiei, iar haosul din
bazele de date poate dura luni de zile (innd cont de numrul mare
de elemente interdependente ale bazei de date).
Planurile de urgena - se refer la situaiile de criz (coruperea
bazei de date n faza de lansare a sistemului, pierderea suportului
conducerii executive ori a sprijinului financiar, apariia de probleme
tehnice insurmontabile n faza de prototipizare etc.).O importan
deosebit este acordat erorilor din partea final a proiectului.
Documentaia proiectului - este unul dintre cele mai importante
mijloace de comunicare. Documentarea fazelor tempereaza elanul
membrilor echipei, care trebuie s gndeasc i s exprime n scris
activitile derulate.
Instruirea utilizatorilor finali se realizeaz n funcie de zona
funcional acoperit, fiecare nvnd funcionalitile pe care le va
utiliza. Sunt oferite utilizatorilor manuale de instruire.
Auditarea - este activitatea desfurat n paralel cu proiectul.
Scopul su este asigurarea derulrii proiectului conform planurilor,
respectarea termenelor i ncadrarea n buget. Exist cteva
momente cheie, importante pentru auditare: preimplementare,
implementarea si postimplementare. De obicei, responsabilitatea
auditului cade n sarcina echipei proiectului, chiar dac furnizorul
ERP i consultanii externi ofer asistent.
Suportul postimplementare - include toate activitile care susin
exploatarea noului sistem. Asistena este necesar datorit erorilor
sau nesincronizrilor care apar n funcionalitatea aplicaiilor
(adesea generate de programele de conversie a datelor).

27

Instruirea continu i ntreinerea sunt menite s protejeze


investiia n noul sistem. ntreinerea continu este o concretizare a
suportului postimplementare. Instruirea are loc, n primul rnd n
cadrul firmei, prin instruire ncruciat i chiar rotaia cadrelor.

D. Motivaia fiecrei organizaii pentru alegerea ERP


influeeaz strategia de implementare. [FOHU04] pune n eviden trei
mari categorii de motive:
Tehnice - aplicaii izolate, platforme nvechite fa de prezentul
tehnologic (vechile aplicaii din ce n ce mai greu de ntreinut, mai
ales datorit costurilor mari, trebuie nlocuite cu o platforma IT
comun, care asigur integrarea sistemului).
Operaionale - mbunirea proceselor, vizibilitea informaional,
reducerea costurilor operaionale (adopate de ctre organizaiile care
sunt dispuse s opereze modificri ale proceselor economice).
Strategice - mbuntirea relaiilor cu clienii, restructurarea
afacerii, standardizarea multilocaie, nevoia de eficien i integrare
(aceast abordare poate asigura organizaiei obinerea de avantaje
competitive, care i mbuntaesc poziia pe pia).
Primele studii privind implementarea proiectelor ERP au delimitat
dou tipuri iniiale de abordri: strategia ,,Big Bang" i strategia pe faze,
iar ulterior s-au conturat alte strategii [FOHU04]. n continuare sunt
prezentate, pe scurt, cteva strategii de implementare ale sistemelor ERP:
1. Proiectele de avengur aleg, de regul, strategia cu riscuri
minime. Presupune parcurgerea tuturor pailor i activitilor descrise pe
parcursul unei perioade de timp extinse (aproximativ 2 ani).
2. Strategia de buget urmreste implementarea noului sistem cu un
buget ct mai mic, numrul activitilor fiind redus datorit faptului c sunt
eliminate activitile consumatoare de resurse. Nu constituie o prioritate
implementarea rapid, ci ncadrarea ntr-un anumit buget.
3. Strategia Big Bang este o metodologie rapid, uoar i
presupune costuri minime. Reunete doar elementele de baz, eliminnd
multe activiti din dorina de a reduce timpul de implementare i costurile.
Conversia datelor se face de obicei manual, pentru a nu se pierde timpul cu
elaborarea de programe de conversie electronic. Aceast strategie este
aleas atunci cnd se au n vedere implementri rapide.
4. Strategia cu fore proprii presupune folosirea echipei proprii de
specialiti (analiti i programatori) pentru a dezvolta un sistem ERP de la
zero. Numrul de activiti este mic, dar se regsesc activitile specifice
dezvoltrii sistemelor ERP: cele de analiz, mapare funcional,
28

prototipizare i modificare a aplicaiilor. Succesul depinde n mare msur


de priceperea i cunotinele echipei de specialiti.
5. Strategia la cheie are aceeai structur i secvent de activiti
ca i strategia riscurilor minime. Diferena apare la planificarea i derularea
propriu-zis a activitilor care sunt realizate cu resurse externe. Apar
probleme la punerea n funciune i preluarea sistemului de catre utilizatori.
6. Strategia de parteneriat se deosebete de alte strategii prin
faptul c responsabilitile proiectului sunt partajate de beneficar i de ctre
partenerii si. Proiectul beneficiaz astfel de cunoaterea i experiena
acumulate de firmele partenere de implementare, iar pe de alt parte,
organizaia beneficiar este implicat activ n activitile proiectului
E. Una dintre preocuparile majore ntr-un proiect ERP se refer la
modalitatea concret de nlocuire a sistemului existent cu noul sistem. Este
o chestiune ndelung dezbtut de practicienii ERP. Practica
implementrilor a consacrat mai multe posibilitti de realizare a tranziiei de
la vechi la nou: integral, pe faze, paralel sau hibrid.
n alegerea strategiei de tranziie trebuie s se porneasca de la o idee
fundamental, accea c implementarea ERP este sprijinit pe 3 factori:
procesele, tehnologia i oamenii, toi la fel de importani pentru succesul
proiectului [FOHU04].
a. Strategia integral, presupune nlocuirea complet a vechiului
sistem cu sistemul nou la un moment dat. Funciunile ndeplinite de
aplicaiile vechi trec simultan i complet n sarcina noilor aplicaii. Este o
strategie mai putin utilizat i nu este recomandat de furnizorii i
implementatorii ERP. Strategia integral implic multe resurse, care
trebuiesc atent planificate pentru succesul operaiunilor. Se remarc o
reducere a costurilor punerii n funciune prin absena programelor de
tranziie care asigur intefaa ntre vechile aplicaii i cele noi.
Abordarea este aplicabil implementrilor rapide, atunci cnd exist o
dat limit, la care sistemul trebuie s funcioneze. De asemenea, are
succes n cazul proiectelor mici, unde se poate mentine cu uurin
controlul asupra activitailor.
b. Strategia pe faze (numit i modular sau secvenial)
implementeaz modulele rnd pe rnd. Acest mod de tranziie presupune
utilizarea unor programe de interfa, care acoper ,,golul" dintre vechile
aplicaii i cele noi, pna cnd acestea devin complet funcionale. De
asemenea, sunt utilizate programe de conversie a datelor.
Procesul ncepe cu punerea n funciune a unui modul (de
exemplu: Financiar-Contabil), celelalte funciuni fiind acoperite de

29

aplicaiile vechi. Urmeaz apoi secvential celelalte module, n ordinea


considerat oportun de beneficiar.
Multe organizaii consider aceast abordare mai confortabil i
lipsit de riscuri dect altele, resursele solicitate fiind rezonabile. Sunt
necesare resurse tehnice, n spe programe de tranziie, de conversie i
preluare a datelor. Un dezavantaj important este durata lung a acestei
perioade de tranziie.
c. Strategia paralel menine n funciune ambele sisteme ntr-un
interval de timp. Perioada variaz n intervalul: o zi - cteva luni. Avantajul
major al acestei abordri este posibilitatea recuperrii n situaia eecului
noului sistem. ntruct ambele sisteme lucreaz n paralel, activitatea
organizaiei nu va fi perturbat n cazul n care apar disfuncionalitti n noul
sistem ERP. Strategia n paralel este caracterizat de riscuri minime,
realizndu-se n plus validarea sistemului implementat, prin compararea
rezultatelor prelucrrilor n cele 2 sisteme.Volumul mare de resurse angrenat
e(aceleai date prelucrate i preluate de dou ori) reprezint un dezavantaj
major. De asemenea, pot aprea erori datorate confuziei utilizatorilor, care nu
interacioneaz corect cu noile aplicaii. Strategia paralel este adecvat
situaiilor n care este esenial stabilitatea noului sistem ERP, pentru firmele
n care disfuncionalitile acestuia ar fi fatale desfurrii activitii.
1.6.5. Avantajele utilizarii ERP
A. Analiza din punct de vedere al funcionalitilor oferite
Dup cum se precizeaz n [OLEA00], principalele avantaje ale
folosirii unui ERP n cadrul unei companii sunt :
Informaia este introdus n sistem o singur dat ntr-o baz
de date foarte complex;
Oblig la folosirea "celor mai bune practici" din industrie;
Permite personalizri;
Funcioneaz pe o structur fiabil de fiiere;
Furnizeaz funcionaliti pentru interaciunea cu alte module;
Furnizeaz instrumente pentru interogri i rapoarte ad-hoc.
Sistemele ERP furnizeaz informaii pentru conducere i analize pentru
organizaii, iar cele cinci beneficii majore ale sistemelor ERP sunt:

informaii on-line/n timp real pentru toate ariile funcionale ale


unei organizaii;
30

standardizarea datelor i acuratee la nivel de ntreprindere;


aplicaiile includ cele mai bune practici din industria respectiv;
eficiena pe care o nregistreaz compania;
analizele i rapoartele ce pot fi folosite la planificri pe termen

lung.
Conform
sursei
http://www.cio.com/research/erp/edit/erpbasics.html#erp_abc sunt cinci motive
majore pentru care companiile doresc s preia ERP-ul:
1. Integrarea informaiilor financiare
n timp ce managerii ncearc s nteleag performana global a
companiei, poate gsi diferite versiuni ale realitii. Departamentul Financiar are
un set de valori reprezentnd venitul, Departamentul Vnzri un cu totul altul i
alte diferite departamente pot avea fiecare o versiune diferit despre propria
contribuie la venitul total al companiei. Sistemul ERP creeaz o singur versiune
a realitii pe care nimeni nu o poate contesta pentru c toi folosesc acelai sistem.
2. Integrarea informaiilor corespunztoare comenzii clientului
Sistemul EPR poate deveni locul unde comanda clientului este nregistrat,
trimis de CSR (Customer Service Representative) la Departamentele Financiar i
Comercial, genernd emiterea unei facturi corespunztoare care va ajunge n
final la CSR. Avnd aceast informaie ntr-un singur sistem, n loc s fie cutat
n diferite alte sisteme care nu pot comunica ntre ele, companiile pot ine evidena
i urmri stadiul unei comezi mult mai uor, putnd coordona producia, inventarul
i direcionarea informaiei ctre mai multe departamente n acelai timp.
3. Standardizarea i eficientizarea procesului de producie
Companiile de producie se afl de multe ori n situaia ca diferitele
departamente ale companiei s ajung la rezultate diferite folosind sisteme i
metode computerizate diferite. Sistemele ERP implic un sistem care conine
metode standardizate pentru automatizarea unora dintre paii efectuai n procesul
de producie. Standardizarea acestor procese i folosirea unui singur sistem
integrat poate conduce la o utilizare mai eficient a timpului, creterea
productivitii i reducerea erorilor umane.
4. Reducerea inventarului
Un sistem ERP ajut ca desfurarea unui proces de producie s se fac
mult mai uor. Acesta poate conduce la diminuarea inventarului corespunztor
personalului folosit n procesul de producie (inventar al muncii n proces) i poate
ajuta utilizatorii sistemului s planifice mai bine ndeplinirea comenzilor,
reducnd inventarul bunurilor care au trecut prin ntreg stadiul produciei, aflnduse n cadrul stocurilor existente. Pentru a mbuntai cu adevarat flexibilitatea
reelei de aprovizionare i distribuire, este nevoie de un software reea, iar ERPul ajut la acest lucru.
31

5. Standardizarea informaiilor din Departamentul de resurse umane


Mai ales n interaciunile cu alte diferite departamente din cadrul
companiei, Departamentul de resurse umane poate s nu aib o metoda simpl
pentru gsirea angajailor i pentru a comunica cu ei despre servicii i beneficii.
Sistemul ERP poate mbuntai acest lucru.
Producia este cel mai important proces n lanul valorii ntr-o ntreprindere
productoare, iar calitatea i competitivitatea pe pia a produselor rezultate din
procesul de producie este esenial. Pentru ndeplinirea acestor deziderate este
esenial eficiena sistemului informatic de gestiune a activitii. Numai
implementarea unei soluii informatice perfect modelate pe specificul activitilor
unei ntreprinderi productoare poate asigura premisele competitivitii acesteia.
Avantajul cel mai important al unui sistem informatic integrat (ERP)
const n gestionarea n mod unic a tuturor categoriilor de date i a
informatiilor specifice beneficiarului.

Figura 1.7 Fluidizarea schimbului de date ntre departamentele


unei ntreprinderi prin intermediul unui ERP
B. Analiza din punct de vedere al costurilor si riscurilor implicate

32

Foarte muli beneficiari se plng de depirea bugetelor iniiale


aprobate pentru achiziionarea soluiei ERP. Dac implementarea are loc
fr ntrzieri care s presupun alocarea de noi resurse umane i materiale,
atunci, de cele mai multe ori, putem vorbi despre costuri ascunse(hidden
fees) .
Exist preri care susin c apariia acestor costuri ascunse este
cauzat de lipsa concordanei dintre poziia de la negociere i cea din timpul
implementrii. Cu alte cuvinte, la negociere, cerinele clientului sunt
minime cu scopul scderii preului de achiziie, ns n timpul implementrii
solicitrile sunt maxime, n discordana cu negocierea iniiala. Ca atare, vom
vorbi i despre costuri de analiz a afacerii respective, despre costurile de
personalizare a aplicaiei, despre licena modulelor, despre cerinele tehnice
ale aplicaiei (licene de utilizatori, investiii n hardware) i despre
ntreinerea acesteia (armonizarea cu legislaia local, suport tehnic,
actualizri). Toate aceste costuri alctuiesc TCO (Total Cost of
Ownership), care nu ar trebui s fie ascuns de ctre furnizorii de ERP ci,
din contr, ar trebui expus nc de la primele discutii.
n al doilea rnd, este vorba de costul licenelor, respectiv al
serviciilor de configurare impuse de software-ul adiional (reea, baz de
date etc.) pe care furnizorul de ERP nu le declar de la nceput, pentru c el
consider c nu fac parte din costul ERP. Nu sunt declarate nici necesitile
de upgrade al hardware-ului necesar pentru a rula soluia, fa de care
furnizorul consider c echipamentele nu sunt problema lui.
n al treilea rnd, pe parcursul implementrii, odat cu nelegerea
mai adnc a aplicaiei beneficiarului, furnizorul gsete alte rezolvri sau
necesiti care atrag costuri suplimentare.
Astfel, soluiile ERP cost ntre 400.000 $ i 300 milioane $
(conform unui studiu Meta Group), n funcie de:
mrimea firmei;
specificul de activitate;
gradul de dispersare geografic;
infrastructura tehnologic.
Aadar, un sistem ERP este scump pentru orice tip de afacere
Investiiile sunt de multe ori adevrate bombe cu ceas pentru
bugetele companiilor. Totui, firmele care au implementat pachete
Enterprise Resource Planning (ERP) trebuie s recunoasc faptul c unele
cheltuieli sunt supraevaluate, n timp ce altele sunt subestimate.
Principalii "devoratori" de buget n implementarea pachetelor
ERP sunt :

33

a. Instruirea
Instruirea este o component neglijat n procesul de
implementare, att ca etap, ct i la nivel bugetar. Astfel,
costurile sunt subestimate, cel mai adesea pentru c se pierde din
vedere faptul c majoritatea angajailor au de nvaat un nou set
de procese i nu doar o noua interfaa software.
b. Integrareaitestarea
Testarea combpatibilitii pachetelor ERP cu alte programe
software este o alt cheltuial de care nu se prea ine seama n
procesul de implementare. O companie standard de producie
poate avea aplicaii add-on pentru partea de logistic, taxe,
planificarea produciei i codurile de bare. Dac la toat aceast
list se adaug i personalizarea funciilor de baz din pachetul
ERP, costurile de integrare, testare i mentenan a sistemului vor
arunca n aer bugetul. n ceea ce priveste instruirea, testarea
integrrii ERP trebuie fcut din perspectiva procesului.
c. Conversiadatelor
Transferul datelor, de tipul informaiilor referitoare la clieni i
furnizori, sau la designul produsului, de pe vechile sisteme pe
cele ERP, este o operaiune costisitoare. Dei puini manageri
sunt dispui s admit, multe din datele existente n sistemele
primite motenire nu sunt foarte importante. Companiile neag
de multe ori redundana datelor pe care le dein, cel puin pn n
momentul n care trebuie s le fac transferul n noile setri
client/server necesare pachetelor ERP. i, din nou, companiile
subestimeaz costurile, de aceast dat pe cele necesare
transferului.
d. Analizadatelor
De multe ori datele din sistemele ERP trebuie combinate cu
datele din sistemele externe pentru a putea permite realizarea de
analize. Utilizatorii care efectueaz analize n mod curent ar
trebui s aib n vedere n bugetul alocat implementarii ERP-ului
i depozitul de date, dar i efortul necesar pentru a-l pune pe
picioare. Utilizatorii sunt pui n dificultate n acest moment:
reactualizarea zilnic a tuturor datelor ERP dintr-un imens
depozit de date, dintr-o corporaie este dificil, iar sistemele ERP
nu ajut prea mult la identificarea acelor date care s-au modificat
de la zi la zi, fcnd actualizri selective.
e. Consultaniad-infinitum
Pentru a evita notele de plat kilometrice ctre consultani,
34

f.

g.

h.

i.

companiile trebuie s identifice clar obiectivele ctre care


partenerii de consultan trebuie s i orienteze pe angajai.
Activitatea consultanilor trebuie s poat fi evaluat, iar pentru
aceasta este necesar s le fie stabilit un "plafon" n activitatea lor:
de exemplu, un anumit numr de angajai care s poat trece cu
brio un test de management de proiect.
Specialitii
Cei mai multi analiti susin c succesul unui sistem ERP
depinde de echipa care lucreaz la implementarea lui. Softwareul este prea complex i schimbrile din zona de business prea
dramatice pentru a lsa un astfel de proiect pe mna unor
amatori. Vestea proast este c, la finalul proiectului, companiile
trebuie s fie pregtite s nlocuiasc muli dintre specialiti.
Echipeledeimplementare
Multe companii tind s trateze implementrile de ERP ca pe
orice alt proiect software. Odat ce programul software a fost
instalat, gndesc ei, echipa va fi dizolvat i fiecare i va relua
postul iniial cu tot cu atribuiile ce i revin. Dup o
implementare de sistem ERP ns, membrul echipei nu se poate
rentoarce la vechile atribuiuni pentru c este mult prea valoros
pentru companie - ajunge s tie mai multe lucruri despre
procesul de vnzri i de producie chiar dect agentul de
vnzri, respectiv agentul de producie nsui. Companiile nu i
prea pot permite s trimit pe vechile posturi participanii la
proiect, ntruct exista multe lucruri de fcut dup instalarea
ERP-ului. Doar crearea de rapoarte pentru a extrage informaii
din noul sistem ERP ine echipa ocupat cel puin un an de zile.
Din pcate, puine companii au n vedere etapa post-instalarii i
chiar i mai puine o prevd n planificarea bugetar prealabil
implementarii.
nateptareabeneficiilor
n managementul de proiecte software tradiionale, companiile se
ateapt s vad rezultatele imediat ce instalarea aplicaiei s-a
ncheiat, lucru imposibil n cazul ERP. Majoritatea sistemelor
ERP i relev eficiena dup o perioad mai ndelungat de la
implementare, iar echipa de proiect la rndul su nu primete
recompensa dect dup amortizarea investiiei.
Depresiapost-ERP
Conform unui studiu efectuat de o firma de consultan, una din
patru companii intervievate a suferit o scdere a performanei
35

imediat dup implementarea sistemului ERP. Motivul este acela


c totul funcioneaz i arat altfel dect pn atunci, iar cnd
angajaii nu tiu exact cu ce lucreaz se panicheaz, acest lucru
afectnd ntregul business.
C. Factorii de risc
n privina riscurilor, se ntmpla adesea ca bugetele alocate i/sau
termenele prevzute s fie cu mult depsite unii analiti apreciaz c
aproximativ jumtate din proiectele ERP nu reuesc s ating obiectivele
propuse. Cazuri celebre precum Boeing, Panasonic sau Siemens ilustreaz
eecul proiectelor, n sensul ratrii obiectivelor propuse ori depairii
nepermise a bugetelor.
n majoritatea cazurilor publicate eecul implementrii unui pachet
de aplicaii integrate s-a datorat problemelor organizaionale. ntr-un top al
motivelor se regsesc:
tratarea ERP ca pe un sistem software;
lipsa implicrii managerilor executivi (top-manageri);
concentrarea eforturilor pe instalarea software-ului i pe
invtarea acestuia;
ateptri nerealiste n privina duratei de implementare;
utilizarea sistemelor ERP pentru colectarea, prelucrarea datelor
i obinerea informaiilor;
neimplicare i neacceptare din partea utilizatorilor;
implementri realizate de consultani i specialiti externi;
lipsa pregtirii psihologice corespunztoare a utilizatorilor;
comunicare defectoas ntre membrii echipelor de proiect;
proiectul nu a fost pregtit corespunztor ori resursele necesare
dezvoltrii sale au fost insuficiente.
Dezavantaj
Proiecte
consumatoare
timp
Costuri mari
Dependena
furnizor

Mod de combatere/diminuare
de

Implicarea activ a managementului, obinerea


consensului i acceptului general;
Dificil i nerecomandat ;

de

Analiz atent a celor dou alternative:furnizor


unic, sau mai muli furnizori, prima nsemnnd
implicarea furnizorului pe termen lung, a doua
36

oferind ansa alegerii soluiilor best of breed;


Complexitate

Selectarea doar a modulelor care sunt absolut


necesare;

Necesitatea
extinderii i
dezvoltrii
ulterioare a
sistemului

Poate fi eliminat, dar va reduce potenialul


sistemului, care va deveni la un moment dat
ineficient.
Tabelul 1.1 Factori de risc n proiecte ERP

Avnd n vedere costurile destul de mari pe care le implic


achiziionarea unui ERP, era firesc s ntrebm ce riscuri presupune
investiia ntr-o asemenea soluie. Extrem de interesant este punctul de
vedere al furnizorilor, aproape toi considernd c riscurile vin din partea
clientului i nu dinparteacompaniilorcareseocupdeimplementare.
SAP este de prere, de exemplu, c principalul risc ine de
necunoaterea domeniului i de neglijarea anumitor criterii de alegere a
soluiei ERP. Muli manageri urmresc exclusiv preul de achiziie, fr s
in seama de ali factori. De aceea, exist riscul de a alege o soluie
nepotrivit necesitailor companiei, o soluie care nu poate susine, pe
termen lung, creterea afacerii, o soluie insuficient testat care poate
genera probleme de stabilitate, funcionalitate sau extindere.
Primul pas pentru o implementare de succes este alegerea unei
soluii performante, apropiat de specificul de activitate al clientului astfel
ncat nivelul de configurare s fie minim, o soluie care s fie confirmat de
referine pe piaa romneasc. Printr-o comunicare adecvat ntre cele dou
echipe de proiect, problemele legate de implementare pot fi evitate.
Pe lng situaiile n care managementul companiei-client nu
susine proiectul sau efii de compartimente nu se implic suficient n
implementarea i utilizarea soluiei sau personalul nu cunoate i nu
nelege necesitatea i beneficiile trecerii de la aplicaiile individuale la
soluiile integrate, au fost identificate i o serie de puncte critice care apar
pe parcursul implementrii unei soluii ERP:
n primul rnd nu se acord suficient atenie procesului de
analiz a nevoilor, adevratele necesiti aprnd mult mai
trziu, pe parcursul implementrii.
n al doilea rnd, se ateapt ca verificarea rezultatelor s se
fac de ctre implementator, ceea ce este complet greit;
37

fiecare utilizator final trebuie s verifice rezultatele activitii


de care rspunde.
nu n ultimul rnd, tergiversarea renunrii la aplicaiile
vechi: dei nu este indicat s se lucreze n paralel mai mult de
dou luni de zile, clienii continu aceast practic pn la
jumatatedean.
Deosebit de important este faptul c euarea unei implementri nu
nseamn numai pierderea investiiei materiale n soluia ERP. Efectele
negative se resimt n deteriorarea relaiei cu clienii, cu angajaii sau n
pierderea cotei de piaa i de imagine. De aceea se recomand alegerea unui
partener cu experien, capabil s prevad i s combat aceste riscuri.
Reticena clientului la sugestiile furnizorului de ERP constituie un
risc deloc de neglijat. Se presupune ca o companie serioas deine un
backgroud solid pentru a putea propune practici eficiente de afaceri i
modaliti de mbuntire a mediului de lucru . ns, n condiiile n care
clientul nu este deschis la propunerile furnizorului, exist riscul ca practicile
greoaie utilizate pn n acel moment s se perpetueze n noul sistem,
sczndu-i valoarea.
Dac echipa care realizeaz implementarea nu nelege sau nu are
capacitatea
de
a
raspundenecesitailorclientului,soartaERPuluiachiziionatpoatefiuneec.

38

CAPITOLUL 1. ASPECTE TEORETICE DESPRE INTEGRAREA


APLICAIILOR INFORMATICE.................................................................1
1.1.
Definiia si evoluia integrrii aplicaiilor informatice...................1
1.2.
Definiia i rolul sistemelor informatice integrate.........................4
1.3. Probleme ale integrrii.........................................................................8
1.4. Infrastructura de integrare...................................................................9
1.5. Evoluia aplicaiilor integrate de gestiune a firmelor........................12
1.6. ERP (Enterprise Resource Planning).................................................14
1.6.1. Ce este un sistem ERP?..............................................................14
1.6.2 Arhitectura unui sistem ERP........................................................17
1.6.3. Componentele principale ale unui sistem ERP..........................18
1.6.4. Implementarea unui sistem ERP.................................................21
1.6.5. Avantajele utilizarii ERP............................................................30
1.7. CRM (Customer Relationship Management). .Error! Bookmark not
defined.
1.7.1. Conceptul CRM..........................Error! Bookmark not defined.
1.7.3. Implementarea CRM...................Error! Bookmark not defined.
1.7.4. Avantajele utilizarii CRM...........Error! Bookmark not defined.
1.7.5. Modelul CRM-ul Operaional n cadrul unui grup bancar Error!
Bookmark not defined.
1.8. SCM (Supply Chain Management)....Error! Bookmark not defined.
1.8.1 Definire i componente................Error! Bookmark not defined.
1.8.2 Decizii pe trei niveluri.................Error! Bookmark not defined.
1.8.3 Relaia ERP - SCM.....................Error! Bookmark not defined.
1.8.4 Dificulti ntmpinate de aplicaiile SCMError! Bookmark not
defined.
1.9. EAI ( integrarea aplicaiilor corporative)........Error! Bookmark not
defined.

39