Cartea Minune

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/289980375
Platforme integrate pentru afaceri. ERP
Book · September 2013
CITATIONS READS
3 1,539
4 authors:
Doina Fotache Luminita Hurbean

Universitatea Alexandru Ioan Cuza West University of Timisoara
59 PUBLICATIONS 165 CITATIONS 40 PUBLICATIONS 143 CITATIONS
SEE PROFILE SEE PROFILE
Vasile Daniel Pavaloaia Octavian Dospinescu

Universitatea Alexandru Ioan Cuza Facultatea de Economie si Administrarea Afacerilor
50 PUBLICATIONS 117 CITATIONS 60 PUBLICATIONS 253 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
World IT Project - Case of Romania View project
ie2018 - The 17th International Conference on Informatics in Economy, May 17 – 20, 2018, Iași, Romania View project
All content following this page was uploaded by Doina Fotache on 09 December 2020.
The user has requested enhancement of the downloaded file.

Luminiţa HURBEAN Doina FOTACHE

Vasile-Daniel PĂVĂLOAIA Octavian DOSPINESCU
Platforme integrate pentru afaceri

ERP

Referenţi ştiinţifici:
prof. univ. dr. Dinu AIRINEI
prof. univ. dr. Doina DĂNĂIAŢĂ
Redactor:
Carmen ŢĂRANU
Copertă:
Adriana POPESCU
Revizie text:
Daniela DUMITRESCU
Tehnoredactare computerizată:
Alexandra Irina TUDORICĂ
Descrierea CIP a Bibliotecii Naţionale a României

Platforme integrate pentru afaceri ERP / Luminiţa Hurbean, Doina Fotache,
Vasile-Daniel Păvăloaia, Octavian Dospinescu. – Bucureşti: Editura Economică, 2013
Bibliogr.
ISBN 978-973-709-673-9
I. Hurbean, Luminiţa
II. Fotache, Doina
III. Păvăloaia, Vasile Daniel
IV. Dospinescu, Octavian
336

Luminiţa HURBEAN Doina FOTACHE

Vasile-Daniel PĂVĂLOAIA Octavian DOSPINESCU
Platforme integrate pentru afaceri

ERP

ISBN 978-973-709-673-9
Copyright © Editura Economică, 2013
Autorii sunt responsabili de clarificarea dreptului de utilizare

a informaţiilor cuprinse în lucrare.

Cuprins

Un altfel de început ................................................................................................................................................... 9

Capitolul 1. Apariţia şi dezvoltarea Enterprise Resource Planning ........................................... 11
1.1. Evoluția sistemelor informaționale – de la automatizare la integrare............................... 12
1.2. Rădăcinile ERP: sistemele MRP............................................................................................................ 14
1.3. Managerii aleg sistemele ERP ............................................................................................................... 19
1.4. Definirea Enterprise Resource Planning. Generalizarea acronimului ERP ........................ 21
1.5. Abordarea structurală tehnologică a sistemelor ERP ................................................................ 24
1.6. Caracteristici, avantaje, dezavantaje şi riscuri .............................................................................. 28
1.7. Dinamica şi reconfigurarea pieței ERP ............................................................................................. 33

Capitolul 2. Procese economice, modelare şi integrare prin platforme integrate........... 43
2.1. Despre funcțiuni şi procese economice............................................................................................ 44
2.1.1. Funcțiuni şi arii funcționale într‐o organizație ................................................................. 44
2.1.1.1. Funcțiunea contabilă .................................................................................................... 46
2.1.1.2. Funcțiunea financiară................................................................................................... 48
2.1.1.3. Funcțiunea de marketing............................................................................................ 50
2.1.1.4. Funcțiunea de producție ............................................................................................. 52
2.1.1.5. Funcțiunea de personal ............................................................................................... 55
2.1.2. Structura funcțională a unei întreprinderi.......................................................................... 58
2.2. Trecerea de la abordarea funcțională la orientarea pe proces în sisteme
informaționale............................................................................................................................................. 59
2.3. Importanța workflow‐ului...................................................................................................................... 61
2.4. Modelare şi fluxuri de procese ............................................................................................................. 75
2.5. Aspecte privind modelarea proceselor de afaceri în aplicația SIMPLE BET.................... 79
2.5.1. Proces şi procedură....................................................................................................................... 79
2.5.2. Fluxul unui proces.......................................................................................................................... 80
2.5.3. Exemplu de modelare a unui proces de afaceri în SIMPLE BET................................ 82
2.5.4. Prezentarea unui proces integrat la nivel de întreprindere, modelat
în SIMPLE BET.................................................................................................................................. 87

Capitolul 3. Implementarea sistemelor ERP .........................................................................................105
3.1. Mai întâi trebuie să fie nevoia… .........................................................................................................107
3.1.1. Prima întrebare: de ce?..............................................................................................................107
3.1.2. A doua întrebare: cât costă? ....................................................................................................107
3.1.3. Justificarea investiției: explorarea costurilor şi beneficiilor.....................................111
3.1.4. Definirea cerințelor .....................................................................................................................115
3.2. Selecția furnizorului de ERP ................................................................................................................119
3.2.1. Prospectarea pieței......................................................................................................................121
3.2.2. Crearea listei scurte de furnizori potențiali .....................................................................121
3.2.3. Restrângerea listei de furnizori potențiali........................................................................122
3.2.4. Selecția finală .................................................................................................................................123
3.2.5. Contractul de implementare a sistemului informatic integrat ................................128

6 Platforme integrate pentru afaceri. ERP
3.3. Implementarea sistemului ERP într‐o organizație....................................................................130
3.3.1. Metodologia de implementare ...............................................................................................131
3.3.1.1. Organizarea proiectului.............................................................................................132
3.3.1.2. Planul de proiect...........................................................................................................134
3.3.1.3. Relația cu furnizorul soluției ERP .........................................................................136
3.3.1.4. Managementul riscurilor ..........................................................................................137
3.3.2. Aspecte tehnice privind instalarea noului sistem..........................................................139
3.3.3. Strategia de instruire a utilizatorilor...................................................................................140
3.3.3.1. Fazele procesului de instruire ................................................................................141
3.3.3.2. Definirea obiectivelor instruirii.............................................................................141
3.3.3.3. Planificarea instruirii..................................................................................................142
3.3.3.4. Bugetul instruirii ..........................................................................................................143
3.3.3.5. Evaluarea instruirii......................................................................................................143
3.4. Utilizarea prototipurilor în implementarea sistemelor ERP ............................................................144
3.5. Modificarea aplicațiilor – un compromis între procese şi funcționalitățile
software ........................................................................................................................................................145
3.6. Migrarea datelor .......................................................................................................................................146
3.7. Startul productiv.......................................................................................................................................147
3.7.1. Problemele şi modul de rezolvare ........................................................................................147
3.7.2. Prima lună. Revizuirea implementării................................................................................148
3.8. Îmbunătățirea continuă.........................................................................................................................148

Capitolul 4. Cultura integrării şi mediul organizaţional................................................................151
4.1. Integrarea informațională în organizații şi consecințele acesteia......................................152
4.2. Redefinirea culturii organizaționale în noua economie..........................................................155
4.2.1. Cultura organizațională .............................................................................................................155
4.2.2. NTI – catalizatorul schimbărilor organizaționale..........................................................157
4.2.3. Relația cultură organizațională‐tehnologii informaționale.......................................159
4.3. Transformările organizaționale. Rolul managementului schimbării................................162
4.4. Transformările culturale şi profesionale: de la rezistența la schimbare
la stimularea creativității.....................................................................................................................167

Capitolul 5. Platformele Customer Relationship Management – de la automatizare
la strategie de afaceri ..............................................................................................................175
5.1. Revoluție în marketing ..........................................................................................................................176
5.2. Evoluția platformelor CRM ..................................................................................................................179
5.3. CRM – definire şi motivații...................................................................................................................181
5.3.1. Definirea CRM ................................................................................................................................182
5.3.2. Motivații şi opțiuni de implementare a CRM....................................................................184
5.4. Taxonomia aplicațiilor CRM ................................................................................................................187
5.5. Piața CRM.....................................................................................................................................................192
5.5.1. CRM în oferta marilor case de software.............................................................................193
5.5.2. Platforme CRM open source .....................................................................................................197

Capitolul 6. Managementul lanţului de aprovizionaredesfacere prin platforme
Supply Chain Management ....................................................................................................201
6.1. Evoluție şi delimitări teoretice SCM.................................................................................................203
6.1.1. Repere istorice...............................................................................................................................203
Cuprins 7
6.1.2. Delimitări conceptuale...............................................................................................................204
6.1.3. Definiții SCM ...................................................................................................................................205
6.2. Concepte de bază ale SCM.....................................................................................................................205
6.3. Zonele funcționale şi taxonomia SCM..............................................................................................208
6.4. Relația ERP‐SCM .......................................................................................................................................211
6.5. Riscurile implementării SCM...............................................................................................................213
6.6. Impactul IT în SCM...................................................................................................................................215
6.6.1. Evoluția şi rolul tehnologiilor informaționale în SCM .................................................215
6.6.2. Tehnologii informaționale utilizate în SCM ......................................................................216
6.6.3. Avantajele utilizării tehnologiilor informaționale în SCM .........................................218
6.7. Prezența aplicațiilor SCM pe piața națională şi internațională............................................219
6.8. Tendințe şi provocări SCM ...................................................................................................................226

Capitolul 7. Enterprise Application Integration – integrarea fără frontiere. SOA............229
7.1. Tehnologii integratoare.........................................................................................................................230
7.2. EAI – evoluția conceptului...................................................................................................................232
7.2.1. EAI – istoric, tendințe şi evoluție...........................................................................................233
7.2.2. Ce este EAI?.....................................................................................................................................233
7.2.3. Obiectivele, rolul şi etapele EAI .............................................................................................236
7.2.4. Nivelurile integrării EAI ............................................................................................................238
7.2.5. Avantajele şi dezavantajele integrării EAI ........................................................................239
7.2.6. Tehnici şi modele de implementare a EAI.........................................................................240
7.2.6.1. Tehnici de implementare a EAI..............................................................................240
7.2.6.2. Modele de rețele EAI...................................................................................................243
7.2.7. Costurile EAI...................................................................................................................................245
7.3. Factori de risc în implementarea EAI şi capcanele EAI ...........................................................246
7.4. Oferta de soluții EAI ................................................................................................................................248
7.5. Tehnologii utilizate în aplicațiile de întreprindere ...................................................................251
7.6. SOA – arhitectura bazată pe servicii ................................................................................................255
7.7. Discuții finale privind EAI.....................................................................................................................261

Capitolul 8. Business Intelligence – noua generaţie de sisteme de asistare
a deciziilor ......................................................................................................................................263
8.1. Definirea conceptului de Business Intelligence şi a beneficiilor sale..................................264
8.2. Arhitectura şi componentele unui sistem BI................................................................................268
8.2.1. Componentele unei soluții BI..................................................................................................268
8.2.2. Locul depozitelor de date într‐un sistem BI.....................................................................271
8.2.2.1. Definire şi caracteristici ............................................................................................272
8.2.2.2. Arhitecturi pentru depozite de date ....................................................................278
8.2.3. Analiza multidimensională ......................................................................................................281
8.2.4. Tehnologii OLAP ...........................................................................................................................287
8.3. Câteva considerații privind implementarea sistemelor Business Intelligence ..............291
8.4. Oferta de soluții Business Intelligence..............................................................................................296
8.4.1. Principalii ofertanți .....................................................................................................................296
8.4.2. Piața mondială de aplicații de Business Intelligence, aplicații analitice
şi de management al performanțelor ..................................................................................299
8.5. Direcții de evoluție a Business Intelligence....................................................................................300

Capitolul 9. Aplicaţiile mobile – suport pentru platforme ERP dinamice............................303
9.1. Prezentare generală a aplicațiilor mobile .....................................................................................304
9.1.1. Definire, istoric şi componentele principale ....................................................................304
9.1.2. Avantaje şi riscuri.........................................................................................................................306
9.1.3. Principalii actori pe piața aplicațiilor mobile pentru afaceri....................................308
9.2. Arhitecturi de servicii mobile pentru afaceri...............................................................................317
9.2.1. Funcționalitățile unui portal de servicii mobile .............................................................317
9.2.2. Propunere de arhitectură pentru servicii mobile ..........................................................318

Capitolul 10. Platforme tehnologice revoluţionare în secolul XXI...........................................321
10.1. Revoluția bio în NTI ..............................................................................................................................322
10.2. Grid computing .......................................................................................................................................324
10.3. Cloud computing ....................................................................................................................................326
10.4. De la externalizare, la Software as a Service în ERP................................................................328
10.4.1. Externalizarea serviciilor – concepte de bază............................................................328
10.4.2. Externalizarea serviciilor informatice...........................................................................331
10.4.3. Software as a Service (SaaS) ...............................................................................................332
10.4.4. SaaS şi SOA.................................................................................................................................336
10.4.5. Furnizorii de soluții SaaS.....................................................................................................337

Bibliografie ...............................................................................................................................................................341

Un altfel de început

Fiecare carte ascunde un proiect, ambiții (cel mai adesea se adresează unui
domeniu profesional de nişă), documentare, muncă, discuții, negocieri şi încredere.
Totodată, fiecare carte poartă în ea (oricât de profesională ar fi) şi ceva din sufletul
autorului sau autorilor ei, iar în cazul celei de față şi amprenta mai multor generații
de studenți şi masteranzi. De aceea fiecare carte este o călătorie. La fel este şi
aceasta, pe care am prezentat‐o într‐o variantă de proiect în 2010 şi a fost supusă
atenției colegilor care pregătesc specialişti pe domeniul informaticii economice. Iaşi‐
Bucureşti‐Cluj‐Timişoara a fost traseul distribuției profesionale.
Cartea noastră este de asemenea o călătorie poate nu în sensul propriu al
cuvântului, ci în sensul temporal al traversării perioadei în care am lucrat pe
subiectul Enterprise Resource Planning în întâlnirile noastre cu studenții de la
Facultatea de Economie şi Administrarea Afacerilor din Iaşi. De asemenea,
considerăm că este o călătorie şi pentru că am lucrat împreună Iaşi‐Timişoara,
pentru că primul autor, Luminiţa Hurbean, face parte din colectivul Facultăţii de
Economie şi de Administrare a Afacerilor de la Universitatea de Vest din Timişoara.
Desprinsă din colectivul de la Iaşi, unde cronologic s‐a ținut pentru prima dată un
curs de acest gen în curricula specializării informatică economică, Luminița a
continuat să colaboreze cu echipa pe acest subiect şi..., profesional, dar mai ales
spiritual, nu s‐a desprins de colegii de la Iaşi. Lucrăm împreună şi asta este o
bucurie.
Platforme integrate pentru afaceri. ERP este de asemenea o călătorie pentru
că reuneşte două generații diferite de autori: doamnele fac parte din generația
1989‐1990, domnii sunt absolvenți de studii 1998‐2000. Cu toții am absolvit aceeaşi
facultate, sunt zece ani diferență de pregătire, opinii, cultură profesională, dar care
au generat o colaborare afectuoasă prin sportivitate profesională. Toți patru am
simțit din plin provocările lucrului în echipă şi putem să afirmăm, în acest moment,
că am lucrat împreună elegant, în toate etapele colaborării noastre. În această
călătorie am avut ocazia să lucrăm cu cel puțin şapte promoții de studenți de
informatică economică şi masteranzii specializării sisteme informaţionale pentru
afaceri. Curiozitatea şi implicarea lor ne‐au determinat să ne perfecționăm mereu;
mărturisim că pregătirea şi coordonarea lucrărilor de diplomă şi de disertație,
prezentările pregătite pe echipe la cursuri şi susținerea prelegerilor în public ne‐au
ajutat să modelăm didactic materialul şi să punctăm cele mai importante idei. Dacă
studenții sunt buni, atunci profesorii sunt şi ei în continuă pregătire, iar cursurile
devin o rampă pentru cercetare şi descoperire continuă.
Titlul Platforme integrate pentru afaceri. ERP este ambițios şi l‐am propus
pentru a veni cât mai bine în întâmpinarea cerințelor de pregătire şi informare
profesională pentru specialiştii din domeniul economic şi nu numai. Prin subiectele
abordate am avut în vedere acoperirea întregului domeniu de studiu, aşa cum l‐am
găsit şi în programele unor universități de prestigiu care oferă acest curs.
Prin structura acestei cărți ne‐am dorit în acelaşi timp conturarea unei culturi
a domeniului, astfel încât cititorul să opereze cu uşurință cu nenumăratele sintagme,
termeni de specialitate şi prescurtări, dar să aibă şi o bună cunoaştere a pieței
internaționale şi în mod special a celei din România. De aceea veți găsi numeroase
exemple cu surse de pe internet – pentru a putea reconstitui cu uşurință demersul
nostru de informare. Cartea nu se adresează numai studenților unei facultăți de
economie şi administrarea afacerilor sau masteranzilor oricărei şcoli de afaceri, ci şi
nivelului managerial din România. Managerii şi oamenii de afaceri vor găsi în
lucrarea noastră suportul necesar pentru (măcar) inițierea unui proiect de
implementare de sisteme integrate.
Probabil că vă puteți imagina cât de greu este să scrii paginile de început,
prezentarea unei cărți în care s‐a pus la cale atât de mult suflet. Introducerea de față
preia din cartea de proiect Procese organizaţionale şi integrare informaţională.
Enterprise Resource Planning o parte din Mărturisirea de început. Atunci, în final, îi
mulțumeam profesorului Dinu Airinei de la Iaşi pentru mentoratul din anii timpurii
ai pregătirii noastre profesionale. De data aceasta, gândul nostru se îndreaptă, cu
recunoştință către profesorul univ. dr. Ion Gh. Roşca. Dumnealui a fost primul care
a avut încredere în publicarea unei cărți pe subiectul ERP (volumul Soluţii
informatice integrate pentru gestiunea afacerilor. ERP, publicat în colecția „Societatea
Informațională” la Editura Economică în anul 2004) într‐o editură prestigioasă cu
prezență națională şi ne‐a oferit suport nelimitat (lansarea a avut loc la Târgul
național de carte din 2004, Teatrul Național Bucureşti). Ultima corespondență pe
care am purtat‐o cu domnul profesor a avut ca subiect publicarea ediției actuale la
Editura Economică. Dedicăm memoriei domnului profesor ediția 2013, Platforme
integrate pentru afaceri. ERP, cu recunoştință.
În încheiere..., aşteptăm sugestiile dumneavoastră (la pagina de descriere a
autorilor aveți adresele noastre de e‐mail) pentru că, sigur, se poate şi mai bine. Și
dorim să încheiem cu o trimitere la afirmația lui Constantin Brâncuşi: „Trebuie să
încerci necontenit să urci foarte sus, dacă vrei să poţi să vezi foarte departe”, pentru că
vrem să călătorim în continuare pe acelaşi drum al cunoaşterii, împreună sau
separat, nu mai contează... Tot ce rămâne şi valorează este încrederea cititorilor
noştri şi sperăm să o câştigăm prin ediția de față. Într‐un interviu recent,
academicianul Valeriu D. Cotea (celebrul oenolog de la Iaşi), întrebat fiind „Ce fel de
vin vă place?”, răspundea:
– „Vinul prieteniei.”
Cartea Platforme integrate pentru afaceri. ERP este, dincolo de toate, cartea
prieteniei. Noroc bun!

Autorii
Iaşi‐Timişoara, iulie 2013

CAPITOLUL 1
Apariţia şi dezvoltarea Enterprise
Resource Planning

După parcurgerea acestui capitol ar trebui să:
& cunoaşteţi evoluţia tehnologică a soluţiilor informatice integrate
pentru afaceri;
& fiţi familiarizaţi cu acronimele domeniului: ERP, CRM, SCM, BI, EAI, ESB,
ENS, BPM, SOA;
& aveţi o viziune completă asupra necesităţii integrării informaţionale a
proceselor de afaceri prin platformele de tip Enterprise Resource
Planning;
& identificaţi tehnologiile din „spatele” platformelor;
& puteţi detalia avantajele, dezavantajele şi riscurile implementării ERP;
& cunoaşteţi piaţa şi să identificaţi dinamica acesteia.

1.1. Evoluţia sistemelor informaţionale – de la automatizare
la integrare

Managementul modern al secolului XXI promovează eficienţa şi flexibilitatea în
contextul unui mediu de afaceri instabil, afectat de crize economice şi are la bază
principiul schimbării, care are în vedere faptul că, în afaceri, orice soluție este
temporară. Cuvântul „schimbare” este de fapt o prescurtare pentru schimbarea
organizațională generată de temporalitatea soluțiilor. În consecință, managementul
schimbării1 se concentrează asupra unei tranziții încununate de succes de la o stare
la alta. Astfel, managerul de succes trebuie să conducă în spiritul stabilităţii pe
termen scurt şi schimbării pe termen lung – uşor de ilustrat în cuvinte, dar foarte greu
de pus în practică.
Peter Drucker, în cartea sa2, arată nevoia de a conduce o afacere nu prin a o
subordona unei singure valori, ci prin a echilibra între variate nevoi şi obiective, aşa
cum o cere momentul, prezentul. Spunând că „Viitorul sa petrecut deja”, celebrul
autor arată că istoria ne învață şi ne îndrumă acțiunile (celebrul proverb anonim:
Cine nu are bătrâni să şii cumpere).

Discuții şi exemple
Celebrul industriaş Henry Ford a construit în America începutului de secol XX un sistem de
producţie atât de bine gândit, încât în anul 1918 jumătate din maşinile din America erau
produse la fabrica sa. Strategia sa poate fi cel mai bine descrisă chiar prin vorbele sale „Any
customer can have a car painted any color that he wants so long as it is black”. Timp de 19
ani, Henry Ford a produs şi vândut acelaşi model T, ajungând în anul 1927 la finalul
producţiei acestui model la maşina numărul 15.007.034. Încăpăţânarea sa de a nu se
adapta prin introducerea de opţiuni şi oferte de cumpărare în rate la costat şi a dat şanse
competitorilor, mai precis companiei General Motors, condusă la începutul anilor ’30 de
Alfred P. Sloan. Un manager raţional, dar ager şi subtil, Sloan a adus un nou model
organizaţional, orientat către client. Sloan a înţeles că trebuie să dea clienţilor un motiv bun
să cumpere de la GM, altul decât preţul mai mic sau insuccesul unui model al competiţiei.
Prin introducerea de schimbări în rutina proiectării, GM lansează „modelul anului", iar
Sloan lansează sloganul „A car for every purse and purpose". Managementul său a făcut din
General Motors cea mai mare companie industrială din lume la vremea ei, care a rămas
numărul 1 în industria auto timp de 70 de ani!

Managerii buni trebuie să ştie nu doar să învețe, ci şi să se dezvețe de
sistemele vechi şi apoi să învețe altceva – aceste aptitudini sunt critice pentru a
supraviețui într‐o lume dominată tot mai mult de principiul schimbării. În acest
sens, credem că în lumea contemporană niciun manager nu îşi mai permite să ignore
importanța tehnologiei informației şi comunicațiilor.

1 R. Newton, Managementul schimbării pas cu pas, Editura All, Bucureşti, 2009.
2 P. Drucker, Despre profesia de manager, Editura Meteor Press, Bucureşti, 1998.
12

Apariţia şi dezvoltarea Enterprise Resource Planning 13
În economia globală de astăzi o organizație nu poate lucra eficient dacă nu
are o soluție informatică integrată cu care să gestioneze toate ariile funcționale.
Chiar dacă teoria a marşat pe ideea integrării activităților, această idee a devenit
fezabilă şi a putut fi pusă în practică abia în anii ’90. Actualele sisteme integrate
pentru afaceri Enterprise Resource Planning (ERP, abreviere consacrată, în traducere
motàmot planificarea resurselor întreprinderii) au evoluat sub influența urmă‐
torilor factori: progresul tehnologiei informaționale (puterea şi viteza de calcul,
memoria, comunicațiile), fundamentarea teoretică a viziunii sistemelor informatice
integrate, redefinirea organizației şi a sistemului său informațional prin înlocuirea
abordării funcționale cu orientarea pe procese economice.

După dominaţia mainframeurilor din anii ’60, anii ’70 aduc apariţia microprocesoarelor şi
creşterea semnificativă a performanţelor calculatoarelor electronice. Progresul rapid al
tehnologiei informaţionale este ilustrat de Legea lui Moore, care a identificat trendul de
creştere: numărul de tranzistori de pe un cip se dublează la fiecare 18 luni, ceea ce
înseamnă dublarea puterii unui sistem de calcul. Dacă primul microprocesor (1970) avea
câteva mii de tranzistori, faimosul Pentium 4 al firmei Intel din 2000 avea peste 80 de
milioane de tranzistori.
Evoluţia echipamentelor de calcul a determinat progrese corespunzătoare în software. Chiar
dacă teoria a consacrat modelul relaţional de organizare a datelor încă din 1970, el a fost
transpus în practică în anii ’70, dar realizări comerciale semnificative pentru bazele de date
relaţionale au urmat abia în anii ’80. Un aspect important de precizat în legătură cu timpul
scurs până la materializarea ideilor se referă la costurile tehnologiei informaţionale – în
anii ’60 şi ’70 costurile mari ale echipamentelor au limitat răspândirea soluţiilor
informatice propuse de specialişti.
Anii ’80 sunt anii de consacrare a microinformaticii, anii în care PCul cunoaşte succesul atât
pentru utilizatorii individuali, cât şi în mediul de afaceri. Managerii devin conştienţi atât de
utilitatea unui PC pe birou, cât şi de importanţa datelor stocate de acesta. Marea provocare
în deceniul nouă a fost partajarea electronică a informaţiilor între utilizatori. Apar primele
reţele locale de calculatoare, care partajează datele şi echipamentele periferice între
utilizatorii conectaţi.
La sfârşitul anilor ’80 erau disponibile principalele resurse informatice necesare dezvoltării
sistemelor ERP: calculatoare rapide, reţele, sisteme de gestiune a bazelor de date.
Tehnologia bazelor de date a avut un rol hotărâtor în concretizarea iniţiativei sistemelor
integrate. Volumul de date care trebuie stocat, prelucrat şi manipulat întro organizaţie este
foarte mare – SGBDurile relaţionale sau dovedit a fi mijlocul adecvat de management al
datelor.

În ultimul deceniu al secolului XX, existau modele de sisteme informatice
integrate, profesionişti care să le proiecteze, precum şi mijloacele informatice de
realizare a acestora. Pentru țările dezvoltate din punct de vedere tehnologic, ERP
constituie încununarea evoluției de peste cinci decenii a tehnicilor de gestiune
economică beneficiare ale suportului tehnologiilor informaționale. Provocarea
13

principală constă în integrarea tuturor proceselor economice şi optimizarea

resurselor disponibile. În consecință, evoluția validează în practica afacerilor
integrate o nouă generație de pachete ERP, generaţia Service Oriented Architecture
(SOA).
La nivelul țării noastre însă, lucrurile stau cu totul altfel. Despre o tradiție
românească în dezvoltarea sistemelor informatice putem discuta, deşi fără prea
mare entuziasm. Dar, dacă ne propunem să căutăm practica integrării acestora,
atunci chiar trebuie să fim discreți. Elementele lipsă erau înțelegerea şi acceptarea
lor de comunitatea de afaceri. Cei mai mulți manageri nu au încă viziunea potrivită şi
nu înțeleg beneficiile integrării informaționale, astfel că nu sunt dispuşi să
investească în dezvoltarea de sisteme ERP (cu regret trebuie să observăm din nou
această realitate şi în primul deceniu al secolului XXI, dar la noi toate se fac mai
greu...).

1.2. Rădăcinile ERP: sistemele MRP

Anii ’60 au adus prezența comercială a sistemelor electronice de calcul.
Cristalizarea conceptuală a fişierelor de date şi dezvoltarea limbajelor de
programare de generația a III‐a (cu precădere COBOL, ALGOL şi FORTRAN) au
antrenat crearea primelor aplicații de gestiune – cele mai noi vizau automatizarea
gestiunii şi controlul stocurilor, calculul salariilor sau contabilitatea generală, fiind
realizate „in house”, cu forțe proprii. Între acestea se numără BOMP (Bill of Material
Processor), aplicație pentru calculul necesarului de materiale. Ele s‐au răspândit în
anii următori (unii dau 1965 drept anul naşterii lor) sub denumirea generală de
sisteme MRP (Material Requirements Planning), desemnând un set de tehnici care
utilizează inventarul, datele despre stocuri şi programul de producție pentru
calculul necesarului de materiale, lansarea aprovizionării şi asigurarea acesteia pe
parcursul procesului de fabricație. În această perioadă, IBM a progresat în definirea
propriului concept de sistem integrat de management al producției şi stocurilor.
Totuşi, în 1970 numărul de implementări din firmele americane era mic. Implicarea
Asociației Americane de Producție şi Control al Stocurilor (cunoscută mai mult sub
acronimul APICS – American Production and Inventory Control Society) a generat o
creştere semnificativă a implementărilor de sisteme MRP în anii ’70. În acei ani au
apărut şi dezvoltări, în sensul încorporării aplicațiilor de planificare a capacităților
de producție (CRP – Capacity Requirements Planning) şi a celor de planificare a
operațiilor şi a vânzărilor (SOP – Sales and Operations Planning) – această extindere
s‐a impregnat şi în denumirea acestor sisteme, care a devenit MRP cu buclă închisă
(closed loop MRP). Merită amintită aici şi publicarea de către Joseph Orlicky în 1975
a conceptelor definitorii ale MRP, deoarece a contribuit la extinderea şi acceptarea
validității acestor sisteme în practica de afaceri.
MRP a avut un rol determinant în dezvoltarea conceptului de sistem
informatic integrat, deoarece a fost prima tentativă reuşită de a metamorfoza
14

aplicațiile informatice rudimentare de control al stocurilor sub influența progreselor
tehnologice menționate mai sus. Pentru o firmă care are multe produse în portofoliu,
multe componente de tip materii prime şi diverse resurse de producție, o astfel de
proiecție a aprovizionării n‐ar fi fost posibilă în absența unui computer care ține
evidența tuturor intrărilor.

Majoritatea firmelor mari şi medii recurg la planificarea3 cererii de materiale (MRP – Material
Requirement Planning), modulul principal al sistemelor de planificare a resurselor de
fabricaţie (MRP II – Manufacturing Resources Planning). MRP elaborează şi menţine un
program valid de producţie pe baza unui set de reguli euristice, aplicate potrivit unei logici
ce are ca obiectiv reducerea costului cu gestiunea stocurilor şi creşterea eficienţei operării
la nivel de proces de producţie. MRP preia cerinţele de produse finite şi permite generarea
comenzilor de producţie şi de aprovizionare. Sistemul complet de planificare şi control
presupune şi funcţiuni adiţionale, rezultând MRP II. Au fost astfel incluse: planificarea
necesarului de capacitate (CRP – Capacity Requirements Planning), planificarea
capacităţilor brute (RCCP – Rough Cut Capacity Planning), controlul stocurilor (SC – Stock
Control), costurile de producţie (PC – Product Costing), controlul atelierului de producţie
(SFC – Shop Floor Control), controlul activităţii de producţie (PAC – Production Activity
Control), finanţe, marketing, alte funcţiuni tehnice şi de personal.
Mecanismul central al MRP parcurge următorii paşi:
stabilirea procesului de planificare şi a intervalelor elementare de programare;
calculul timpului necesar pentru fiecare articol al unui produs complex: în acest scop se
ţine cont de durata de procesare şi de pregătire, precum şi de timpul de transfer şi de
aşteptare între posturile de lucru, între ateliere şi secţii şi încadrarea în intervalele
elementare de programare;
desfăşurarea cantităţilor necesare de articole pentru fiecare ramură din structură,
potrivit procesului de planificare şi cumularea articolelor de acelaşi fel pe fiecare
interval elementar: în această etapă se calculează necesarul de articole dependente
(cantităţitermene) pentru comenzi ferme;
aplicarea unor politici de planificare, care să stabilească termenele finale: acestea pot fi
de tip lot pentru lot sau cantităţi comandate periodic, se urmăreşte obţinerea unui
inventar zero la sfârşitul intervalului de planificare în cazul unor comenzi externe
pentru care nu există perspectiva de a se repeta;
determinarea cantităţilor de articole de fabricaţie pentru termene de lansare în avans,
cu un număr de intervale elementare corespunzător timpului de producţie al fiecărui
articol.
În cazul apariţiei unor probleme pe parcursul procesului de planificare, procedura de
planificare poate fi reluată în noile condiţii. Planul elaborat presupune verificarea
capacităţilor disponibile.

3 D. Popescu, A. Popa, A. Mihalache, „Opțiuni în stabilirea strategiilor de control al producției”, Revista
Română de Informatică şi Automatică, 1998, http://www.ici.ro/RRIA/ria1998_1/art01.html
15

Următoarea realizare pe scara evoluției s‐a produs la începutul deceniului
nouă, când apare ideea de a lărgi aria de cuprindere şi a încorpora toate resursele
necesare producției.
MRP II a reprezentat o metodă pentru planificarea eficientă a tuturor
resurselor unei întreprinderi industriale. Acest sistem asigura planificarea
operațională a necesarului care susține procesele de producție, planificarea
financiară şi elaborarea de scenarii şi simulări „ce‐ar fi dacă”. Funcțiunile integrate
au vizat: planificarea producției, planul de vânzări, programarea producției,
planificarea necesarului de materiale, planificarea capacităților de producție,
precum şi urmărirea execuției (aprovizionare, fabricație, vânzare). Ca ieşiri,
sistemele ofereau rapoarte financiare, cum ar fi planul de vânzări, planul de
aprovizionare, proiecții de stocuri, bugete de expediție şi transport.
Se cuvine să‐l amintim aici pe Oliver Wight4, cel care a definit Manufacturing
Resource Planning (răspândit sub acronimul MRP II), dorind ca în centrul atenției să
rămână producția. Contribuția sa la dezvoltarea acestor sisteme a fost esențială, iar
expertiza şi experiența sa sunt astăzi oferite de firma internațională de consultanță
şi educare Oliver Wight pentru excelența în afaceri5. Scăderea costurilor tehnologiei
şi creşterea performanțelor acesteia au concurat la emanația succesivă a sistemelor
MRP II. Ar fi totuşi de menționat că extinderea orizontului a dus inevitabil la nevoia
de modificare a funcționalităților de bază livrate – apar primele eşecuri de
implementare.
Mai mult decât atât, se ivesc provocări noi, grație noilor tehnologii
complementare care intră în scenă, precum JustInTime, Computer Aided Manufac
turing sau Total Quality Management. Nevoia de integrare este tot mai pregnantă.

În 1978, International Standards Organization publică modelul de referinţă OSI (Open
Standards Interconnection), cu intenţia de a oferi un cadru de dezvoltare a standardelor
pentru toate comunicaţiile de date. La vremea aceea, companiile mari precum General
Motors sau Boeing deţineau mii de componente tehnologice izolate şi se luptau cu
incompatibilitatea dintre ele şi costurile mari pentru a le face să comunice între ele.
Folosind modelul de referinţă OSI, în 1985 ele au finalizat şi publicat protocoale de
comunicaţie (Manufacturing Automation Protocol la GM). Existenţa modelului de referinţă
sa dovedit salutară pentru dezvoltările care au urmat: Ethernet, Token Ring, TCP/IP ş.a.

Sistemele MRP erau proiectate şi dezvoltate de organizațiile beneficiare.
Funcțiile lor erau realizate de calculatoare mari (cunoscute sub denumirea de
mainframe) prin prelucrarea datelor stocate în fişiere secvențiale. Unele
implementări au folosit şi tehnologia EDI (Electronic Data Interchange), prin care
sunt schimbate direct între calculatoare documente standard în format electronic în

4 O. Wight, The Executive's Guide to Successful MRP II, Oliver Wight Limited Publications, 1983.
5 http://www.oliverwight.com/
16

faza de aprovizionare (comenzi, facturi, alte documente cu format prestabilit). EDI a
reprezentat un ingredient valoros al sistemelor MRP, determinând reducerea
costurilor şi economii de timp față de varianta transmiterii clasice a documentelor
pe hârtie.

Electronic Data Interchange a fost o tehnologie declarată de mulţi specialişti ca un vârf de
lance în dematerializarea societăţii. Sintagma a fost lansată în jurul anului 1975 în SUA şi a
reprezentat „un mijloc de transmitere, de la calculator la calculator, a datelor normalizate
(standardizate) şi preagregate, prin intermediul unei reţele de telecomunicaţii”. Altfel spus,
EDI reprezintă schimburile dintre sistemele informatice, pe cale electronică, a datelor
structurate, organizate în mesaje normalizate. Comunicarea prin EDI presupunea un acord
prealabil încheiat între părţile interesate, acord cu caracter juridic, în care se precizează
clar caracteristicile mesajelor transferate reciproc: datele comunicate, structura şi
îmbinarea lor, procedurile de control/validare. Acest acord defineşte, deci, un standard de
comunicare. Standardele pot fi bilaterale, când se instituie numai între doi parteneri,
respectiv universale, atunci când sunt acceptate şi utilizate de o paletă largă de
întreprinderi/organizaţii.
În 1997/1998, un nou concept şia făcut apariţia legat de aceste două tehnologii.
EFI (schimbul de formulare informatizate) sau WebEDI presupune un demers extrem de
simplu: partenerul se conectează la un site WEB (internet) pentru a efectua o operaţie prin
intermediul unui formular predefinit. Serverul produce astfel o tranzacţie de tip EDI, care va
utiliza direct un interpretor EDI pentru emiterea ordinelor. Cu soluţia WebEDI, utilizatorul
final are acces la toate serviciile oferite de global intranet. Serverul Web realizează legătura
între utilizatori, baza de date, lumea EDIFACT (standard documente financiare) şi X400
(standard reţele de calculatoare). Baza de date conţine toate tipurile de formulare, profilul
utilizatorilor şi drepturile lor de acces, mesajele sosite şi cele care au fost transmise, arhivele
şi jurnalele de informaţii ale managerilor. WebEDI integrează un interpretor EDI, pentru
administrarea formularelor şi mesajelor, şi comportă un modul de comunicaţie X400 pentru
schimburile cu „liderii” comunităţii. Odată cu evoluţia serviciilor web şi a limbajelor XML sa
trecut la raportarea XBRL în afaceri.
eXtended Bussiness Reporting Language este un standard internaţional pentru publicarea,
schimbul şi analiza financiară a datelor raportate. XBRL simplifică pregătirea şi publicarea
documentelor financiare. Ideea este de a colecta date o singură dată şi de a le converti în
mai multe formate, prin prelucrare automată. Standardul XBRL reprezintă pentru mediul
de afaceri mondial ceea ce a reprezentat protocolul TCP/IP pentru internet. XBRL este un
standard internaţional creat de XBRL International, un consorţiu cu mai mult de 400 de
membri din toată lumea, reprezentând companii publice şi private, agenţii guvernamentale
şi agenţii de reglementare. Adoptarea XBRL în România ar reduce semnificativ costurile cu
colectarea şi validarea informaţiilor din raportări, conversia, diseminarea, precum şi
schimbul acestora.

Într‐un context tehnologic tot mai bun, maturizarea sistemelor MRP instalate
a determinat evoluția acestora, prin integrarea de noi funcționalități economice.
Astfel, la începutul anilor ’80, a prins contur Manufacturing Resource Planning
17

(MRP II), care s‐a concentrat asupra optimizării proceselor de fabricație prin
sincronizarea necesarului de resurse cu cerințele producției. Astfel, zonele acoperite
au depăşit limitele producției: financiar, resurse umane, distribuție, vânzare prin
magazine proprii, gestiunea proiectelor.
MRP II a constituit mai mult decât un instrument de planificare şi urmărire a
producției, astfel că a evoluat firesc către un sistem mai cuprinzător, care se
adresează şi altor tipuri de întreprinderi. În aceste condiții, el a fost redenumit
Enterprise Resource Planning. Conform unor surse, „paternitatea” acestui concept
este revendicată de Gartner Group. Astfel, în 1990, Gartner Inc., o companie
americană de consultanță în domeniul tehnologiilor pentru afaceri, propune
termenul ERP pentru a desemna generația următoare de sisteme MRP II. În
descrierea acestor sisteme se pun în evidență: arhitectura client/server şi interfața
grafică utilizator, configurația standard sau extinsă cu funcționalități suplimentare,
independența hardware şi software6.
Extinderea funcționalității suitelor MRP II a determinat apariția primelor
sisteme ERP, la sfârşitul anilor ’80, consacrând ideea coordonării şi integrării inter‐
funcționale în întreprindere. Primele sisteme ERP nu aduceau foarte multe noutăți
funcționale; esențiale şi decisive au fost noutățile tehnologice menționate, cea mai
însemnată fiind arhitectura client/server.
Bazate pe fundația tehnologică a MRP II, sistemele ERP integrează toate
procesele economice: producție, distribuție, contabilitate, financiar, personal,
stocuri, service şi mentenanță, logistică, gestiune proiecte, oferind accesibilitate,
vizibilitate şi consistență informațională în întreaga organizație. În anii ’90 furnizorii
ERP au adăugat suitelor lor noi module şi funcționalități, ceea ce a generat apariția
conceptului ERP extins. Extensiile cuprind aplicații precum APS (Advanced Planning
and Scheduling), soluții e‐business pe zona relațiilor cu clienții – CRM (Customer
Relationship Management) sau pe furnizori‐aprovizionare – SCM (Supply Chain
Management).
Pe fondul extinderii acoperirii funcționale, asigurată adesea de alți furnizori
decât de cei care au oferit modulele ERP de bază, problema integrării a devenit tot
mai spinoasă. Dacă la început integrarea se realiza punctual, prin interfețe
programate individual, proliferarea funcțională a impus adoptarea unor standarde
de interfețe (cum sunt Open Database Connectivity – ODBC pentru baze de date şi
Universal Description, Discovery and Integration – UDDI pentru interconectivitate pe
internet). Anii 2000 au adus preocupări legate de integrarea platformelor,
concretizate în evoluția aplicațiilor middleware de tip Enterprise Application
Integration (EAI), Enterprise System Bus (ESB) şi Enterprise Nervous System (ENS).
Problematica integrării în contextul aplicațiilor ERP extinse – cunoscute sub
denumirea de ERP II – este tratată pe larg în capitolul 7. O schemă simplificată a
evoluției ERP este cea din figura 1.1.

6
www.gartner.com, citat în S. Harwood, ERP: the implementation cycle, Butterworth‐Heinemann,
Oxford, 2003, pp. 10‐11.
18

Putem aprecia că desfăşurarea cronologică a ERP a urmat îndeaproape

dezvoltările din domeniul sistemelor hardware şi software. În acest sens, merită să
menționăm un ultim reper, nu atât în evoluția, cât în reconfigurarea ERP: arhitectura
SOA, care promite un set unitar de servicii şi componente pentru infrastructura de
proces pentru construirea, desfăşurarea şi administrarea de interplatforme
integrate. Furnizorii de soluții au îmbrățişat imediat această oportunitate.
Sursa: Prelucrare şi adaptare după Hossain, L., Patrick, J.D., Rashid, M.A., Enterprise Resource Planning:
global opportunities and challenges, Idea Group Publishing, 2002, p. 4.
Figura 1.1. Evoluţia soluţiilor informatice de gestiune a firmelor

1.3. Managerii aleg sistemele ERP

Pe plan mondial, anii ’90 au debutat în contextul unei scăderi economice,
greutățile întâmpinate determinând multe companii să opereze concedieri şi să se
reorganizeze. Aceste transformări au favorizat dezvoltarea ERP, concept promovat
prin ideea de eficientizare a activității. Analiza realistă a evidențiat slăbiciunile
modelului funcțional de organizare, utilizat multe decenii, cu succes putem spune, în
economia americană, atâta timp cât competiția a fost limitată.
Aşa cum se observă în figura 1.2, acest model de organizare transmite
informațiile vertical, către top‐manageri, fără ca ele să fie partajate orizontal între
ariile funcționale.
Modelul funcţional de organizare se dovedeşte ineficient pentru o organizație
care doreşte să aibă succes pe o piață dinamică, unde se cer flexibilitate şi decizii
prompte odată cu schimbările din mediu. Structura unei organizații orientate pe
procesele economice schimbă direcția fluxurilor de informații de pe verticală pe
orizontală (vezi figura 1.3), traversând ariile funcționale, ca şi fluxurile de materiale,
de oameni şi produse.
Dincolo de polemicile pe care le‐a născut, organizarea bazată pe procese a
devenit unanim acceptată ca punct de pornire al analizei şi reproiectării afacerii,
19

devenind o componentă nelipsită într‐un proiect de implementare a unui sistem

integrat ERP. Importanța acestui subiect ne determină să‐i alocăm mai mult spațiu
(capitolul 2).

Top management
C

O
i i i N
i
P R
n n n T n
R V E
f f f A f
O Â S.
o o o B o
D N
r r r I r
U Z U
m m m L m
C Ă M
a a a I a
Ț R A
ț ț ț T ț
I I N
i i i A i
E E
i i i T i

E
Fluxuri de materiale şi produse

Sursa: Monk, E., Wagner, B., Concepts in Enterprise Resource Planning, Thompson Course Technology,
2006, p. 22.
Figura 1.2. Fluxurile de materiale, produse şi informaţii
întro organizare funcţională

Top‐management
Financiar & Contabilitate Resurse umane

Marketing & Vânzări
F C
U L
Aprovizionare Producție Logistică
R I
fluxuri de informații E
N
I N
Z Sunt asigurate Ț
Sunt prelucrate Sunt stocate şi
O I
livrate
R
fluxuri de materiale, resurse umane şi produse
I

Sursa: Monk, E., Wagner, B., Concepts in Enterprise Resource Planning, Thompson Course Technology,
2006, p. 22.
Figura 1.3. Fluxurile de materiale, produse şi informaţii în organizarea
bazată pe procese
20

Aşa cum vom arăta şi în paragraful următor, deşi ERP este referit ca un sistem
software, el este implementat în strânsă legătură cu procesele economice, din care
decurg cerințele şi funcțiunile dorite de beneficiari. Sistemele ERP sprijină şi
facilitează schimbările de proces care să ducă la aşteptata eficiență operațională.
Astfel, o soluție ERP autentică încorporează aşa‐numitele best practices (trad. cele
mai bune practici), adică viziunea furnizorului soluției asupra celui mai eficace mod
de a desfăşura procesele economice vizate. A adopta soluția ERP aşa cum o livrează
furnizorul înseamnă schimbarea proceselor în organizație, în condițiile unei
implementări mai rapide şi mai puțin costisitoare sub aspectul configurării,
documentării, testării şi instruirii. În plus, firmele care se încadrează în anumite
categorii sunt constrânse să adopte cerințe impuse de lege precum IFRS, Sarbanes‐
Oxley sau Basel II, iar un ERP autentic le va asigura alinierea la aceste cerințe. În fine,
trebuie să mai precizăm că adoptarea celor mai bune practici este un pas important
pe calea adoptării standardelor de calitate (cum ar fi ISO 9000 şi ISO 14001).
Încheiem precizând că în proiectele reale aceste bune practici sunt „perfect”
aplicabile sau potrivite doar pentru unele firme. Fiecare firmă are caracteristicile
sale particulare şi credem că se cer pricepere şi talent pentru a evita „uniformizarea”
şi a găsi echilibrul între adoptarea practicilor care vin cu soluția ERP şi menținerea
unicității organizației.

1.4. Definirea Enterprise Resource Planning. Generalizarea
acronimului ERP

În anii ’90, Enterprise Resource Planning a devenit un subiect extrem de popular:
numeroase cărți, articole, studii, prezentări, promovări şi versiuni demonstrative
încearcă să convingă comunitatea de afaceri de binefacerile implementării aplicațiilor
integrate de gestiune a firmelor. Dezvoltarea în contextul societății informaționale şi a
globalizării afacerilor a generat un nou avânt pentru industria de software şi a creat
noi oportunități de carieră, în special în zona consultanței şi implementării acestor
sisteme în organizații. Aşa cum a anticipat Davenport, adoptarea sistemelor ERP de
companii s‐a evidențiat ca fiind cea mai importantă expresie în domeniul tehnologiei
informaționale pentru afaceri în anii ’90.
Precizăm existența site‐urilor specializate 7, a forumurilor de discuții şi
blogurilor de specialitate unde acest subiect este de larg interes. În lume, sunt
derulate programe de instruire şi certificare ERP, care atestă cunoştințele
fundamentale pentru implementarea şi întreținerea aplicațiilor. Şi mediul de afaceri
din România desfăşoară proiecte de acest tip.
Într‐o definiție orientată tehnologic, ERP reprezintă un sistem informațional
de gestiune bazat pe interfețe grafice utilizator, baze de date relaționale, limbaje de
generația a IV‐a, instrumente CASE şi arhitectură client/server. Totuşi, a fost
unanimă opinia că, deşi tehnologia este esențială în realizarea ERP, definiția trebuie

7 www.intelligententerprise.com, www.intelligenterp.com, www.technologyevaluation.com, www.erp.com,
www.2020software.com etc.
21

să reliefeze ariile funcționale acoperite: contabilitate, financiar, producție, vânzare,

aprovizionare, stocuri etc.
Astfel, sistemele ERP sunt pachete de aplicații formate din mai multe module
care sprijină toate ariile funcționale: planificare, producție, vânzare, marketing,
distribuție, contabilitate, financiar, resurse umane, gestiunea proiectelor, stocuri,
service şi întreținere, logistică şi e‐business. Arhitectura sistemului facilitează
integrarea transparentă a modulelor, asigurând fluxul transversal al informațiilor
între toate funcțiunile întreprinderii. Alegerea sistemului ERP potrivit permite
beneficiarului să implementeze un sistem integrat unic, care aduce la un numitor
comun sistemele funcționale existente.
O altă definiție scurtă, dar cuprinzătoare, este: „o soluție software completă şi
atotcuprinzătoare pentru o întreprindere”8, ea relevând faptul că ERP este o suită de
aplicații, mai ales în ochii utilizatorilor finali.
American Production and Inventory Control Society defineşte sistemele ERP
astfel: „un cadru pentru organizarea, definirea şi standardizarea proceselor econo‐
mice pentru a asigura planificarea eficientă şi controlul într‐o organizație, astfel
încât aceasta să poată utiliza cunoaşterea internă pentru a găsi avantaje externe”9.
În lucrarea sa, publicată în Harvard Business Review10, T. Davenport arată că
ERP este: „un pachet de aplicații care promite integrarea completă a tuturor
fluxurilor informaționale din cadrul unei organizații […]”. Acest concept este ilustrat
în figura 1.4.

Rapoarte pt.
conducere
F
Financiar
C Vânzări şi U
distribuţie Contabilitate
L R
I N
E Baza de date Producţie I
Service unică
N postvânzare Z
Ţ O
Stocuri
I R
I
Personal-
Aplicaţii „front-office” Aplicaţii „back-office”
salarizare
Sursa: Adaptare după Hossain, L., Patrick, J.D., Rashid, M.A., Enterprise Resource Planning: global
opportunities and challenges, Idea Group Publishing, 2002, p. 3.
Figura 1.4. Schema conceptuală a unui sistem ERP

8 T. Anderegg, ERP: AZ Implementer's guide for success, Resource Publishing, 2000, p. 5.
9 http://www.apics.org/dictionary/dictionary‐information?ID=1294
10 T.H. Davenport, „Putting the Enterprise into the Enterprise System”, Harvard Business Review,
July–August, 1998, pp. 121‐131.
22

O imagine simplificată se desprinde şi din definiția lui Tadjer: „o bază de date,
o aplicație, o interfață unificată în întreaga întreprindere” 11.
În fine, merită citată şi definiția lui O’Leary, care apreciază că ERP reprezintă
sisteme computerizate care asigură prelucrarea integrată şi în timp real a tuturor
tranzacțiilor din întreprindere şi optimizează întregul lanț de activități, de la
planificare la service postvânzare.
Concluzionăm, corelând toate definițiile prezentate, prin formularea
următoare: Enterprise Resource Planning (ERP) reprezintă sisteme bazate pe
arhitectura client/server dezvoltate pentru prelucrarea tranzacţiilor şi
facilitarea integrării tuturor proceselor, din faza planificării şi dezvoltării
producţiei, până la relaţiile cu furnizorii, clienţii şi alţi parteneri de afaceri.
În ceea ce priveşte acronimul ERP, putem afirma cu certitudine că a declanşat
pe piața sistemelor informaționale integrate pentru gestiunea afacerilor o adevărată
modă, de la an la an intrând în uz tot mai multe acronime. Între zecile de exemple, le
menționăm pe cele mai uzitate:
CRM – Customer Relationship Management, managementul relațiilor cu
clienții;
SCM – Supply Chain Management, managementul lanțului de aprovizionare‐
desfacere;
BI – Business Intelligence, platforme analitice pentru expertiza datelor;
EAI, ESB, ENS – Enterprise Application Integration, Enterprise Service Bus şi
Enterprise Nervous System, platforme middleware pentru integrare;
BPM – Business Process Management, platforme pentru managementul
proceselor de afaceri;
SOA – Service Oriented Architecture, tip de arhitectură software care
presupune distribuirea funcționalității aplicației în unități mai mici,
distincte, numite servicii, care pot fi distribuite într‐o rețea şi pot fi utilizate
împreună.

În România, acronimul ERP începe să fie cu adevărat cunoscut odată cu introducerea
cursurilor în programele facultăţilor de economie şi administrarea afacerilor la
specializările de informatică economică şi contabilitate şi informatică de gestiune, cu presa
care este din ce în ce mai „vocală” prin susţinerea necesităţii acurateţei informaţionale.
Publicaţiile de gen, economice sau informatice: Business Magazin, Market Watch,
Computerworld, Networkworld, PC World, Ziarul Financiar, Tribuna Economică etc.,
precum şi siteurile furnizorilor de soluţii interni şi internaţionali popularizează integrarea
informaţională prin platforme ERP. În acest moment (aprilie 2010), o simplă căutare după
ERP, criteriu de căutare: numai pagini în limba română, afişează 259.000 de rezultate.

11 R. Tadjer, „Enterprise Resource Planning”, Internetweek, Manhasset, aprilie, 1998.
23

1.5. Abordarea structurală tehnologică a sistemelor ERP

Elementele ilustrate în figura 1.5 sunt considerate componente de bază din
structura unui sistem ERP. Astfel, datele generate de tranzacțiile economice zilnice
sunt culese şi stocate în baze de date, oferind informațiile necesare conducerii
întreprinderii. Prelucrarea cade în sarcina programelor, iar comunicarea este
absolut necesară pentru valorificarea informațiilor generate. Remarcăm delimitarea
funcțională concretizată în module de aplicații şi integrarea, caracteristică esențială
şi deziderat al implementării ERP.

BAZE DE DATE PROGRAME

R E
Comunicare
Culegere
Stocare A
R Prelucrare
E G
N T DATE
I FUNCŢIONALITĂŢI
Figura 1.5. Elementele unui sistem ERP

Datele reprezintă fundația unui sistem ERP. Baza de date reprezintă un
depozit central pentru stocarea şi organizarea datelor. Oferta de baze de date
comerciale este mai restrânsă în comparație cu oferta suitelor integrate: sunt 20 de
platforme de baze de date la sute de aplicații. Puțini sunt furnizorii ERP care au avut
succes în dezvoltarea propriilor platforme de baze de date. Această strategie este
mai rar întâlnită, deoarece presupune un efort susținut pentru a contracara
avantajele oferite de platformele dezvoltate de firme specializate, deja testate şi
cunoscute pe piață.
Diversitatea tehnologică face ca abordări „tradiționale” din domeniul bazelor
de date să fie îmbunătățite şi diversificate. Astfel, la ora actuală există un trend
cunoscut sub acronimul imDB (In Memory DataBase), o tehnologie prin care datele
nu mai sunt stocate „la distanță”, ci chiar în memoria aplicației de tip ERP. Probabil
că momentul definitoriu l‐a constituit anul 2001, când McObject a creat eXtremeDB,
primul sistem de tip imDB care era destinat dispozitivelor electrice şi electronice.
Ulterior acestui moment, piața de profil a devenit efervescentă şi au apărut produse
precum Terracotta, TimeTen (achiziționat de Oracle), Altibase HDB (Altibase),
solidDB (IBM).
La ora actuală, posibilitățile de stocare a informațiilor sunt din ce în ce mai
diversificate, iar eterogenitatea tot mai accentuată a datelor primare determină
dezvoltatorii de sisteme ERP să ia în calcul structuri precum depozitele de date. În
sens larg, un depozit de date reprezintă o bază de date care este întreținută separat
24

de bazele de date operaționale ale organizației. Datele din sistemele‐sursă sunt
extrase, curățate, transformate şi stocate în depozite speciale în scopul sprijinirii
proceselor decizionale. Depozitele de date sprijină procesarea informațiilor,
furnizând o platformă solidă de consolidare a datelor istorice pentru analiză. Printre
cele mai cunoscute motoare pentru depozite de date sunt Teradata, Oracle
DataWarehouse, Microsoft Analysis Services, IBM DataWarehousing and Analytics. De
altfel, conform studiilor recente12, aceste motoare pentru depozite de date ocupă cea
mai mare parte din piața mondială de profil.

Încă din anul 2008, SAP a investit în dezvoltarea infrastructurii middleware, sub forma unei
platforme de date în timp real bazată pe tehnologia bazelor de date inmemory, iar în 2011
a lansat HANA13. Cu ajutorul tehnologiei inmemory, încorporată în aplicaţie, HANA
explorează şi analizează în timp real baze de date uriaşe (ceea ce în limbaj IT numim astăzi
big data). Clienţii mari ai SAP se întreabă dacă trebuie să înlocuiască actualele baze de date
relaţionale cu această nouă tehnologie. Bazele de date inmemory oferă informaţii în timp
real, răspunzând în termen de nanosecunde, în loc de milisecunde, citind miliarde de date, cu
o viteză de accesare şi prelucrare a informaţiilor de până la 100.000 de ori mai mare decât
în prezent…
Conform declaraţiilor companiei, platforma SAP pentru gestiunea datelor în timp real reduce
din gradul de complexitate a sistemelor de baze de date şi furnizează capacităţi de stocare
imense pe zona de aplicaţii big data şi analitice, oferind în acelaşi timp suport pentru
integrarea cu aplicaţii în cloud sau mobile14.

Programele realizează legătura dintre bazele de date şi funcționalitățile
deservite. Altfel spus, funcționalitatea este atinsă prin interacțiunea dintre programe
şi bazele de date. Programele asigură culegerea datelor, validarea, prelucrarea şi
transferul lor, precum şi exportul datelor către alte medii.
Pentru a obține informațiile cerute, programele preiau date din bazele de date
create prin alte programe, dar şi din alte surse. Astfel, datele pot fi introduse de
operatori, de la tastatură ori prin preluare directă (scanarea codurilor de bare, spre
exemplu, sau preluarea datelor direct prin RFID, RadioFrequency Identification,
identificare prin frecvență radio). Interfețele devin tot mai importante, odată cu
dezvoltările tehnologice, deoarece asigură comunicarea mai uşoară între diferite
medii. Prin interfețe adecvate, programele pot prelua date şi din alte surse: internet,
XBRL, echipamente de producție, alte programe de aplicații.
Incontestabil, tehnologia internet a avut un important impact asupra
aplicațiilor ERP. Orice furnizor cu o cotă de piață de peste 1% a adoptat o strategie

12 http://www.informationweek.com/software/information‐management/gartner‐ranks‐data‐
warehousing‐leaders/229215658?pgno=1, accesat în decembrie 2012.
13 http://www.computereconomics.com/article.cfm?id=1732, accesat în decembrie 2012.
14 Vezi și http://itchannel3.itchannel.ro/sap‐nominalizata‐cel‐mai‐dinamic‐furnizor‐pe‐piata‐sistemelor‐
pentru‐gestiunea‐bazelor‐de‐date/, accesat în decembrie 2012.
25

internet proprie15, în funcție de măsura în care suita sa de aplicații foloseşte
tehnologiile internet. Niciun producător nu‐şi mai poate permite să nu țină seama de
această tehnologie şi consecințele sale.
Firmele care au volume mari de date care provin din procesul de fabricație au
realizat interfețe ale ERP cu echipamentele de producţie. Cele mai performante
asigură raportarea cantităților fabricate în timp real, conform instrucțiunilor din
sistemul ERP şi la cererea acestuia. Interfețele sunt adaptate specificului fiecărei
întreprinderi.
În prelucrarea datelor, programele se bazează pe reguli. Acestea sunt
interpretate, programate şi se regăsesc în codul‐sursă. Ele constau în funcții logice,
operatori de comparare şi valori. Aplicațiile ERP sunt realizate cu ajutorul
instrumentelor CASE16, care simplifică munca programatorilor, preluând regulile şi
generând automat codul‐sursă. Avantajele sunt: reducerea timpului de dezvoltare şi
obţinerea unui produs de calitate, prin minimizarea erorilor. În plus, utilizarea
instrumentelor CASE sprijină consistența aplicațiilor şi standardizarea sub aspect
funcțional. După elaborarea codului‐sursă, prin compilare, se obține programul în
format executabil. Acesta are avantajul unei viteze de execuție superioare. După
compilare, obiectul executabil obținut, denumit în general program, este inclus în
structura aplicației şi ataşat într‐un meniu de unde este apelat şi lansat în execuție
de utilizator.
Rezultatele prelucrării sunt oferite utilizatorilor sub formă de rapoarte, fie
afişate pe ecranul monitorului (display‐uri), fie tipărite la imprimantă, dar şi sub
formă de fişiere, care pot fi exportate şi prelucrate cu ajutorul altor medii de lucru.
Prima modalitate de furnizare a rezultatelor – pe ecran – are avantajul
interactivității: actualele sisteme ERP au dobândit tot mai multă flexibilitate.
Informațiile afişate pe ecran sunt diferite în funcție de tipul de utilizator care le
solicită şi pot fi chiar personalizate pentru fiecare utilizator în parte. Astfel, după
delimitarea câmpurilor de date solicitate, pot fi operate selecții asupra acestora, sunt
posibile sortări după criterii diferite şi pot fi stabilite niveluri de sumarizare
(totaluri, alte calcule). Pe de altă parte, afişarea diferențiată a informațiilor pe
categorii de utilizatori este un aspect impus de politica de securitate a datelor în
cadrul organizației. În sistemele ERP de ultimă generație sunt incluse form‐uri
(formulare) care afişează informațiile într‐o interfață grafică, având un mod simplu
şi intuitiv de operare. Utilizatorul poate obține ad hoc şi interactiv informațiile
dorite. Din punct de vedere tehnic, este vorba în primul rând despre programarea
soft, care a înlocuit programarea hard. Aceasta permitea scrierea de programe fixe
ca funcționalitate, în care opțiunile sunt limitate la cele avute în vedere inițial.
Programarea soft a devenit posibilă odată cu generalizarea interfețelor grafice
utilizator şi se combină cu programarea vizuală şi cea dirijată de evenimente. În

15 T. Anderegg, op. cit., 2000, p. 20.
16 Acronim pentru Computer Aided Systems Engineering, proiectarea sistemelor cu ajutorul
calculatorului. Sisteme computerizate pentru îmbunătățirea eficienței, corectitudinii, proiectării,
realizării şi întreținerii sistemelor informaționale (Sursa: D. Oprea, Premisele şi consecinţele
informatizării contabilităţii, Editura Graphix, Iaşi, 1994, p. 201).
26

acest mod a fost îmbunătățită flexibilitatea aplicațiilor, nu numai pentru ieşiri, ci şi
pentru intrări şi prelucrări de date: acelaşi program poate fi operat în mod diferit de
utilizatori diferiți.
În ceea ce priveşte rapoartele, pe lângă posibilitatea de parametrizare a
acestora, sistemele ERP pot include un generator de rapoarte, cu ajutorul căruia pot
fi construite noi rapoarte, care nu au fost prevăzute în cerințele inițiale. Cel mai des
întâlnit este formatul tabelar (Excel, în principal), care poate fi salvat şi exploatat
mai apoi cu ajutorul spreadsheet‐ului (pentru analize complexe asupra datelor,
calcule suplimentare, grafice). Această opțiune de export este deosebit de
importantă în sporirea funcționalității de ansamblu a sistemelor ERP, deoarece
elimină cererile de modificare ulterioară a aplicațiilor din partea beneficiarilor.
În fine, sistemele ERP pot genera ca ieşiri diferite documente, cu formă şi
conținut standard: facturi, avize de expediție, NIR‐uri, comenzi etc. Dacă în primele
sisteme ERP nu era posibilă configurarea documentelor de ieşire în forma dorită
(firmele fiind nevoite să modifice formatele), sistemele actuale oferă diverse soluții
pentru obținerea ieşirilor în formatul dorit. Sunt utilizate instrumente de proiectare
thirdparty pentru flexibilitate în definirea ieşirilor. Majoritatea oferă facilități
grafice, pentru utilizarea însemnelor firmei (logo/antet specific).
Un alt element conceptual de bază al sistemelor ERP îl constituie fluxurile de
procese sau fluxuri de tranzacții (workflow). Ele ilustrează desfăşurarea unui
anume proces funcțional, spre exemplu: calculul, înregistrarea şi plata salariilor.
Fluxurile de procese se pot clasifica în: funcţionale (specifice unei funcțiuni) şi inter
funcţionale, care implică activități ce se regăsesc în două sau mai multe funcțiuni.
Utilizarea unei soluții workflow sprijină abordarea pe procese, considerată
superioară celei funcționale, deoarece activitățile se desfăşoară nu doar în cadrul
unei funcțiuni, ci adesea „traversează” mai multe domenii funcționale.
Printr‐o soluție workflow se analizează şi proiectează un flux de procese
economice dintr‐o arie funcțională, în concordanță cu logica impusă de aplicația ERP
instalată. În cea mai simplă accepție17, workflow defineşte, creează şi supraveghează
execuția fluxurilor de procese prin intermediul unui software specializat. Cea mai
importantă caracteristică este flexibilitatea, care permite reconfigurarea fluxurilor
proceselor economice din organizație. Unele sisteme ERP includ un modul
funcțional pentru stabilirea şi gestionarea fluxurilor de activități specifice fiecărei
organizații.
Revenind la reprezentarea din figura 1.5, ideea de bază a unui sistem ERP este
redată de următoarea formulă:
ERP = funcționalitate + integrare.
O implementare ERP înseamnă o sumă de cerințe funcționale care se vor
regăsi în noul sistem informatic de o manieră integrată. Partea funcţională a unui
sistem ERP asigură desfăşurarea proceselor economice din cadrul fiecărei funcțiuni.
Astfel, în cadrul unei suite ERP se regăsesc de la câteva până la zeci de module

17 D. Fotache, Groupware. Metode, tehnici şi tehnologii pentru grupuri de lucru, Editura Polirom, Iaşi,
2002, p. 165.
27

funcționale (contabilitate generală, debitori, salarii, stocuri, aprovizionare, logistică,
planificarea producției, comenzi şi vânzare etc.). Prezentarea generică a acestora
este subiectul capitolului 2. Integrarea asigură conectivitatea dintre fluxurile de
procese economice funcționale. Ea poate fi gândită ca o tehnică de comunicare.
Câteva modalități18 obişnuite prin care comunicarea are loc prin şi pentru integrare
sunt: codulsursă, reţele locale şi extinse de calculatoare, internet, email, workflow,
instrumente de configurare automată, protocoale, baze de date.

1.6. Caracteristici, avantaje, dezavantaje şi riscuri

Foarte multe firme, în special cele de dimensiuni medii‐mari, au sisteme ERP.
Practica a arătat că nu este atât de dificil să implementezi un pachet integrat de
aplicații, cât să obții şi să beneficiezi de toate avantajele pe care le generează.
Aceasta se datorează, pe de o parte, complexității sistemelor ERP, iar pe de
altă parte, neînțelegerii principiilor de lucru la nivel managerial. În plus,
funcționarea optimă a sistemului este posibilă doar prin armonizarea cu activitățile
funcționale zilnice din cadrul organizației.
Potențialul oferit de un sistem ERP pentru crearea de valoare este cel mai bine
sistematizat în prezentarea lui O’Leary, prin următoarele caracteristici19:
ERP aduce la un loc toate activităţile firmei, deoarece procesele
„traversează” mai multe arii funcționale, ceea ce constrânge firma să iasă din
tiparele clasice (ca să nu spunem demodate) ale aplicațiilor funcționale. Astfel,
datele care în varianta veche rezidă în mai multe aplicații specializate eterogene
sunt acum integrate într‐un sistem unic;
sistemele ERP promit utilizarea celor mai bune practici, ele înglobând
analiza a mii de procese de afaceri şi expertiza specialiştilor. Succesul scontat al
implementării unui ERP este strâns legat de măsura în care aceste bune practici sunt
adoptate, în scopul de a îmbunătăți operațiile la nivel funcțional;
ERP sunt un activant pentru standardizarea organizaţională. Prin
implementarea unui sistem integrat toate componentele organizaționale sunt aduse
la un numitor comun. Acest lucru este resimțit cel mai mult de firmele în a căror
structură sunt mai multe puncte de lucru sau altfel de unități organizatorice, adesea
dispersate teritorial. Un ERP va determina alinierea proceselor acestora şi va face
posibil ca firma să ofere în exterior o imagine unică, de ansamblu. Pe de o parte,
standardizarea măreşte eficiența operațională, iar pe de altă parte, retuşează şi
rafinează imaginea firmei în exterior;
ERP elimină asimetriile informaţionale, deoarece pune toate datele într‐un
acelaşi, unic, sistem de baze de date care alimentează toate aplicațiile. Implicațiile
acestei caracteristici sunt majore, începând cu obținerea unui control operațional
mai riguros, continuând cu asigurarea accesului la date pentru toți cei interesați.

18 T. Anderegg, op. cit., p. 39.
19 D. O’Leary, Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk,
Cambridge University Press, 2000, pp. 7‐9.
28

Efectele se resimt în rândul managerilor, care primesc oportun informațiile de care
au nevoie, ceea ce contribuie la îmbunătățirea procesului de luare a deciziilor, dar şi
la nivelul utilizatorilor obişnuiți, care sunt în aceeaşi măsură informați – se vorbeşte
în acest context despre fenomenul de „aplatizare" a organizației;
ERP oferă informaţii oriunde (online), în timp real. Dacă în sistemele
tradiționale informația circula între departamente cel mai adesea în formă tipărită,
acum ea este disponibilă direct tuturor utilizatorilor care au nevoie de ea, imediat ce
a fost introdusă în sistem la sursă, acolo unde a fost generată;
ERP oferă acces simultan, concurenţial, la aceleaşi date, pentru planificare şi
control. După cum se ştie (dar ne place să repetăm), un ERP foloseşte o bază de date
unică, în care informația este introdusă o singură dată şi doar o singură dată (o altă
aserțiune predilectă a specialiştilor ERP). Împreună cu avantajele care decurg din
caracteristica anterioară, putem proclama superioritatea netă a sistemelor integrate
în desfăşurarea unei planificări consistente şi a unui control riguros;
ERP facilitează comunicarea şi colaborarea intraorganizaţională. Nu suntem
siguri dacă le facilitează sau le instituie ca un nou mod de viață. Considerăm că este
un avantaj care decurge din cele prezentate anterior şi că ar fi o nesăbuință să nu
profiți de el;
ERP facilitează comunicarea şi colaborarea interorganizaţională. Nu
surprinde pe nimeni această aserțiune, venită firesc în continuarea celei de mai sus.
Într‐adevăr, materializarea ei depinde exclusiv de strategia fiecărei organizații, cert
este că ERP se constituie în temelia unui demers interorganizațional sau scheletul pe
care se pot grefa uşor componentele unui sistem colaborativ.
În mod greşit, există ideea preconcepută că implementarea unui sistem ERP
înseamnă rezolvarea „de la sine” a tuturor problemelor organizației şi creşterea
productivității „peste noapte”. Aşteptările formulate în ceea ce priveşte reducerea
costurilor şi îmbunătățirea activității depind de măsura în care sistemul ERP ales se
potriveşte funcționalităților organizaționale şi de cât de bine se adaptează procesele
(re)definite şi configurate în structura, cultura şi strategia organizației. În acelaşi
timp, rata de recuperare a unei astfel de investiții este mai greu de calculat din cauza
dificultății în cuantificarea beneficiilor intangibile şi a celor strategice. Tabelul 1.1
prezintă beneficiile principale aduse de implementarea acestor sisteme.

Tabelul 1.1
Avantajele sistemelor ERP
Avantaj Mod de concretizare
Informaţii de calitate Bază de date unică (date consistente şi corecte), rapoarte
îmbunătățite
Evitarea redundanţei datelor Baza de date unică elimină operațiile repetitive de
şi operaţiunilor actualizare (introducere şi modificare)
Scăderea timpului de Rapoarte şi informații ad hoc oferite de sistem
răspuns
Adaptabilitate Schimbările în procesele economice se reconfigurează uşor
în sistemul ERP
29

Avantaj Mod de concretizare
Scalabilitate Structura modulară a sistemului facilitează adăugarea de
noi componente
Sistem de întreţinere Contractul de întreținere pe termen lung cu furnizorul ERP
îmbunătăţit nu este facultativ, ci face parte din proiectul ERP
Dimensiune colaborativă Module precum CRM sau SCM extind şi deschid sistemul
către furnizori şi clienți
Deschidere către ebusiness Arhitectura sistemelor ERP permite integrarea noilor
tipuri de aplicații e‐business

Cum întotdeauna există şi un revers al medaliei, literatura de specialitate
abundă în exemple de implementări nereuşite. Precizăm câteva dintre aşa‐zisele
dezavantaje, în tabelul 1.2.
Tabelul 1.2
Dezavantajele sistemelor ERP

Dezavantaj Mod de combatere/diminuare
Proiecte consumatoare de timp Implicarea activă a managementului, obținerea
consensului şi acceptului general
Costuri mari Dificil şi nerecomandat
Neconformitatea modulelor Alegerea unui sistem ale cărui arhitectură şi
componente corespund proceselor economice, culturii
şi obiectivelor strategice ale organizației
Dependenţa de furnizor Analiza atentă a celor două alternative: furnizor unic
sau mai mulți furnizori, prima însemnând implicarea
furnizorului pe termen lung, a doua oferind şansa
alegerii soluțiilor „best of breed"
Complexitate Selectarea doar a modulelor care sunt absolut necesare
Necesitatea extinderii şi Poate fi eliminată, dar va reduce potențialul strategic al
dezvoltării ulterioare a sistemului, care va deveni la un moment dat un banal
sistemului sistem operațional

În majoritatea cazurilor publicate, eşecul implementării unui pachet de
aplicații integrate a fost rezultatul problemelor organizaționale. Într‐un top 10 al
motivelor am putea include (ordinea este oarecare):
1) tratarea ERP ca pe un sistem software;
2) lipsa implicării reale a managerilor executivi (top‐manageri);
3) aşteptări nerealiste în privința duratei de implementare;
4) utilizarea sistemelor ERP pentru colectarea, prelucrarea datelor şi
obținerea informațiilor;
5) neimplicare şi neacceptare din partea utilizatorilor;
6) instruirea insuficientă a utilizatorilor;
7) lipsa pregătirii psihologice corespunzătoare a utilizatorilor;
8) comunicare defectuoasă între membrii echipei de proiect;
30

9) implementări realizate de consultanți şi specialişti externi;
10) proiectul nu a fost pregătit corespunzător ori resursele necesare
dezvoltării sale au fost insuficiente.
Deşi nu este un instrument magic, alternativa integrării informaționale
interne, în afara soluțiilor Enterprise Resource Planning, nu există.
În condițiile în care organizațiile se confruntă zilnic cu o multitudine de surse
şi factori de risc, cunoaşterea şi managementul riscurilor, având la dispoziție
platforme integrate, reprezintă un suport important.
Riscul20 este definit ca probabilitatea apariţiei unor evenimente cu efecte
negative asupra unei afaceri sau unei activităţi. Astfel spus, sunt avute în vedere
acele evenimente care, în caz că s‐ar produce, ar cauza pierderi, pagube financiare,
cheltuieli suplimentare neprevăzute sau chiar pierderea parțială sau integrală a
profitului aşteptat. Ca să poată fi ținute sub control, riscurile trebuie identificate.
Elementele identificării riscului sunt21:
Identificarea expunerilor la risc (ex.: expunerea la risc a resurselor umane,
expunerea la risc a proprietăților – activele tangibile şi intangibile ale instituției,
expunerea la riscul de răspundere civilă legală etc.);
Identificarea surselor de risc pentru organizaţie (ex.: mediul fizic‐natural,
mediul sociocultural, mediul politico‐legislativ, mediul intern al firmei, mediul
economic etc.);
Identificarea consecinţelor posibile ale riscurilor (ex.: consecințe fizice,
consecințe funcționale, consecințe financiare etc.).
Am prezentat aceste informații pentru că în cazul implementării sistemelor
integrate putem identifica riscuri generale şi riscuri ale managementului proiectului
de implementare ERP, dat fiind că riscul nu poate fi definit decât prin raportare la
obiectivele proiectului şi cele ale organizației în ansamblu (în capitolul 3 vom trata
managementul proiectului ERP şi managementul riscurilor proiectului ERP). De
asemenea, având în vedere şi faptul că riscurile nu pot fi tratate toate deodată (este
importantă stabilirea priorităților pentru canalizarea eficientă a eforturilor),
managementul riscurilor poate avea în vedere o structurare pe etape:
1) descrierea contextului – la acest nivel se are în vedere specificul afacerii şi
mediul în care se desfăşoară procesele economice;
2) identificarea riscurilor la nivel macroeconomic, dar şi la nivel
microeconomic; la nivel organizațional şi interorganizațional;
3) evaluarea, analiza şi ierarhizarea riscurilor;
4) elaborarea planului de management al riscurilor;
5) stabilirea responsabilităților şi implementarea efectivă a planului de
management al riscurilor;
6) monitorizarea rezultatelor şi corecțiile necesare.

20 S.G. Anton, Gestiunea riscurilor financiare. Abordări teoretice şi studii de caz, Editura Universității
„Alexandru Ioan Cuza”, Iaşi, 2009, p. 17.
21 B. Anastasiei, Managementul riscului, managementul riscului organizaţional, Editura Tehnopress, Iaşi,
2010, citat şi în V.‐P. Măzăreanu, Economia şi managementul riscurilor, Editura Tehnopress, Iaşi, 2010,
p. 67.
31

Importanța unei situații de risc poate fi tratată din două puncte de vedere:
cel al impactului asupra mediului organizațional în ansamblu şi cel al probabilității
de a se produce (avem în vedere în acest caz managementul evenimentelor
declanşatoare). Prin realizarea combinațiilor probabile între cele două, rezultă o
matrice prin care pot fi ținute sub control efectele negative.
La nivel organizațional, cel mai important risc este cel de respingere a noului,
de a refuza colaborarea de‐a lungul implementării şi de a bloca desfăşurarea
proceselor specifice implementării.
Analiza literaturii de profil22 oferă posibilitatea conturării unui model de
clasificare a riscurilor în care se ține cont de sursa acestora (tabelul 1.3).

Tabelul 1.3
Sinteză privind clasificarea riscurilor

Sursa de risc Clasificare Exemple

Factorul • Riscuri provenite din • Incapacitatea de a termina o
uman comportamentul uman sarcină la timp, slaba calitate a
• Riscuri provenite din trăsăturile personalului
psihologice ale persoanei • Aşteptări nerealiste, accent pe
• Riscuri provenite din activități detalii şi pierderea din vedere a
individuale obiectivelor
• Riscuri provenite din nivelul de • Comunicare neeficientă cu
implicare şi pregătire al utilizatorul, training insuficient al
utilizatorului utilizatorului final
Organizaţia • Strategice: riscuri legate de • Riscuri care țin de capitalul
strategia firmei intelectual al firmei, de schimbările
• Operaţionale: riscuri ce afectează care au loc la nivel macroeconomic
activitatea curentă a companiei • Frauda, resurse insuficiente,
• Financiare: riscuri care au eşecuri în reproiectarea proceselor
legătură directă cu fluxurile de afaceri
financiare ale firmei • Lipsa de lichidități, neachitarea
• De hazard: evenimente obligațiilor contractuale ale
imprevizibile (naturale) partenerilor
• Catastrofele naturale, incendiile
Stilul de • Riscuri provenite din • Lipsa sprijinului conducerii
conducere inconsistențe în politica de executive
conducere • Schimbări în cerințe, leadership
• Riscuri provenite din activitățile slab
şi controalele managementului • Eşec în atragerea de personal
• Riscuri la nivel de aptitudini ale calificat, cunoştințe insuficiente
conducerii organizației
Mediul extern • Riscuri provenite din • Condiții de piață în schimbare,
organizaţiei circumstanțe economice, sociale acțiuni dăunătoare ale competiției,
politice şi de mediu aplicații software depăşite

22 Sintetizată excelent în teza de doctorat a domnului Valentin Măzăreanu: V.‐P. Măzăreanu, op. cit.,, pp.
70‐73, dar şi pe site‐ul întreținut de acelaşi autor http://www.managementul‐riscurilor.ro/
32

Sursa de risc Clasificare Exemple

Resursele • Riscuri provenite din probleme • Documentare inadecvată,
tehnologice şi tehnice şi tehnologice aplicații implementate fără a
informaţio • Riscuri provenite din modul de îndeplini cerințele inițiale, know
nale ale proiectare şi implementare a how inadecvat
organizaţiei aplicației software • Instabilitatea tehnologiei
• Riscuri provenite din modul de curente, imposibilitatea de
administrare a informației conectare cu sistemul moştenit
• Neînțelegerea cerințelor de
schimbare, neintegrarea
sistemelor din organizație
Relaţia cu • Riscuri provenite din relațiile • Performanța inadecvată a
terţe părţi legale şi contractuale terțelor părți, protecție inadecvată
• Riscuri care provin din afectarea a proprietății intelectuale, tensiuni
populației între clienți şi contractori
• Încălcări sau neconformitate cu
legislația
Sursa: preluare după Măzăreanu, V.‐P., Economia şi managementul riscurilor, Editura Tehnopress, Iaşi,
2010, pp. 71‐72.

Putem aprecia, pe ansamblul organizațional, având în vedere dezavantajele
prezentate în cadrul acestui subcapitol, că riscurile sunt cu atât mai mari cu cât:
proiectul durează mai mult;
creşte intervalul de timp dintre faza de planificare şi faza de execuție;
experiența managerului de proiect, a echipei de proiect sau a organizației,
este mai restrânsă;
metodologia sau tehnologia la care se face apel pentru implementarea
proiectului este mai nouă şi mai puțin cunoscută.

1.7. Dinamica şi reconfigurarea pieţei ERP

Piața de platforme integrate, cunoscute sub acronimul ERP, a crescut
fulminant, cu rate alarmant de mari, pe fondul dezvoltărilor majore în IT, al cererii
crescute de aplicații şi al oportunităților valorificate de noii intrați. Am asistat la
atingerea unui nivel de venituri care părea ireal la început şi la înmulțirea numărului
de ofertanți odată cu amplificarea interesului pentru aceste aplicații.

SAP (la început Systemanalyse und Programmentwicklung, apoi Systeme, Anwendungen und
Produkte in der Datenverarbeitung), înfiinţată în 1972 în Mannheim de cinci ingineri de
sistem, foşti angajaţi IBM, actualmente cu sediul în Walldorf (Germania), este astăzi:
a treia companie de software din lume ca mărime şi cea mai mare companie din lume
în domeniul produselor software interenterprise;
33

oferta pentru o gamă vastă de produse: soluţii integrate interenterprise, soluţii de
colaborare ebusiness pentru toate categoriile de industrie şi pentru toate pieţele
majore;
o companie globală, care deţine laboratoare în: SUA, Bulgaria, Franţa, Israel, India şi
Japonia;
listată la mai multe burse, printre care Frankfurt Stock Exchange şi New York Stock
Exchange, cu simbolul SAP.
Alte repere SAP:
2002 – deschiderea reprezentanţei din România, însă colaborarea cu SAP AG a
început încă din anul 1995, când soluţiile SAP au fost promovate prin parteneri locali;
SAP România se află pe primul loc în clasamentul furnizorilor de aplicaţii de afaceri,
cu o cotă de piaţă de 22,7% în anul 2008 în România, arată studiul IDC 2009 pentru
piaţa EAS – Enterprise Aplications Software;
SAP R/3 a fost cea mai cunoscută soluţie din portofoliul de produse SAP. Datând din
anii ’70, R/3 este soluţia care a adoptat ideea reunirii mai multor funcţii de afaceri
întro singură aplicaţie, rulând pe o singură bază de date;
SAP foloseşte în programare un limbaj propriu: ABAP (Advanced Business
Application Programming).
SAP în cifre:
38 de ani de experienţă în domeniul dezvoltării soluţiilor ERP;
peste 82.000 de clienţi în 120 de ţări şi peste 300 de clienţi în România;
mai bine de 12 milioane de utilizatori zilnic;
42.750 de angajaţi în mai mult de 50 de ţări;
peste 5.400 de dezvoltatori în întreaga lume;
peste 106.000 de implementări;
2.000 de consultanţi pentru suport tehnic;
peste 10.000 de consultanţi SAP;
180.000 de consultanţi din partea partenerilor SAP;
8.000 de dezvoltatori;

77 de centre de training.

Piața a înregistrat continuu mutații în ceea ce priveşte oferta, ajungând la faza
de maturitate în ultimii ani, în urma numeroaselor fuziuni şi achiziții.
Tabelul 1.4
Istoricul şi dinamica furnizorilor ERP

An
Companie Ţara Preluată de Anul Observaţii
înfiinţare
1972 SAP Germania
1975 DataWorks SUA Epicor 1999
1977 JD Edwards SUA Peoplesoft 2006
1977 Oracle SUA
1978 Baan Olanda Invensys (UK) 2000
SSA GT (SUA) 2003
1979 QAD SUA
1979 Tetra Marea Sage 1999
Britanie
1981 JBA Marea Geac (Canada) 1999
34

An
Companie Ţara Preluată de Anul Observaţii
înfiinţare
Britanie
1981 SSA GT SUA Infor Global 2006
Solutions
1983 Damgaard Danemarca Microsoft 2002 Interesul
Data A/S achiziției a fost
suita ERP Axapta
1983 IFS Suedia
1984 Intentia Suedia
1987 Peoplesoft SUA Oracle
2000 Navision Danemarca Microsoft 2002 Navision
Software Software „se
trage” din firma
PC&C ApS
(1984)

Primele dezvoltări de platforme economice (anii ’60) au avut loc în cadrul
marilor companii, care aveau propriile departamente IT, cu specialişti proprii, care
lucrau la realizarea de aplicații. Primele case de software apar în anii ’70 (detalii în
tabelul 1.4). În 1978 IBM lansează unul dintre primele pachete MRP pe piața IT:
MAPICS (Manufacturing, Accounting and Production Information Control Systems)23
– el a fost primul bestseller în materie de pachete de aplicații de afaceri, dominând
piața peste zece ani. Succesul MAPICS a determinat alte mari companii americane să
iasă pe piață cu produsele dezvoltate in house, dar s‐a dovedit mai târziu că această
categorie de programe necesită o atenție specială, devenind apanajul caselor de
software. Aşa cum se observă din tabelul 1.4, în această perioadă s‐a pus piatra de
temelie a marilor case de software de pe piața ERP de astăzi.
În ceea ce priveşte volumul vânzărilor pe piața globală, acestea au avut o
evoluție lentă până la jumătatea anilor ’90, atingând un nivel fulminant în anul 2000.
Este relevantă în acest sens evoluția veniturilor liderului mondial SAP, prezentată în
figura 1.6, cu mențiunea că acelaşi ritm de creştere l‐au înregistrat toți furnizorii de
ERP în acea perioadă. Explicațiile rezidă în contextul economic favorabil care a
permis investiții în IT, în corelație cu nevoia de creştere a eficienței operaționale şi
mai apoi teama de implicațiile nefaste ale problemei anului 2000 la sistemele
electronice de calcul (Y2K).
La momentul anului 2000 topul furnizorilor ERP se cristalizase, având pe
primele locuri pe SAP, Oracle, Peoplesoft, JD Edwards şi Baan. Practic, după anul
1997, care a consemnat cea mai mare creştere de până atunci a pieței, cei cinci au
menținut o cotă mai mare de 50% din piața totală (se poate observa evoluția
veniturilor în figura 1.7). În această perioadă se produce şi segmentarea pieței,

23 MAPICS nu a dispărut, fiind şi astăzi pe piața de ERP. După ce a fost vândut de IBM firmei MARCAM în
1993, aceasta l‐a comercializat şi dezvoltat până în 2005, când firma a fost cumpărată de Infor Global
Solutions.
35

primii cinci fiind denumiți generic furnizori de nivel 1 (Tier I), a căror bază de clienți
cuprinde marile corporații din toată lumea. Furnizorii de la nivelul 2 (Tier II) – la
momentul acela QAD, SSA sau IFS – ținteau către piața de mijloc, a firmelor medii şi
mari. A existat dintotdeauna şi un nivel 3, al celor care şi‐au îndreptat atenția către
firmele mici, deşi aici au ajuns soluții informatice mai simple, nu întotdeauna de talia
unui ERP.

milioane euro

Sursa: Site‐ul SAP AG Germania.
Figura 1.6. Creşterea veniturilor SAP în anii ’90

Succesul înregistrat în perioada de glorie i‐a costat destul de scump pe unii –
cel mai elocvent caz este Baan, care de pe culmile gloriei a ajuns în pragul
dezastrului, cu grave probleme financiare – la fel s‐a întâmplat şi cu multe alte firme,
mai mari sau mai mici. În aceste condiții, au avut loc numeroase fuziuni, preluări
prietenoase sau forțate, care au salvat de la dispariție multe pachete ERP de pe piață
(vezi coloana „Preluată de” din tabelul 1.4).
Furnizorii care şi‐au menținut succesul şi supremația au fost aceia care au
investit în cercetare‐dezvoltare, fiind vorba despre procente consistente din cifra lor
de afaceri (între 10 şi 20%). Menținerea pasului cu evoluțiile tehnologice s‐a dovedit
cheia succesului pe această piață; cei care nu au investit în actualizarea aplicațiilor
lor după o strategie bine gândită, în sensul de a lansa oportun pe piață versiunile noi,
au pierdut. Se pare că în domeniul software nu se aplică remarca mai bine mai târziu
decât niciodată.
36


milioane dolari
Sursa: Harwood, S., ERP: The implementation cycle, Butterworh‐Heinemann, Oxford, 2003, p. 46.
Figura 1.7. Piaţa mondială de ERP în perioada 19952000

Totuşi, nu a fost prea târziu pentru Microsoft, intrată pe piaţa ERP după anul 2000. Strategia şi
investiţiile realizate iau asigurat o clasare onorabilă pe locul 3 în topul ERP.
Microsoft Dynamics Nav face parte dintro suită de soluţii pentru administrarea afacerilor de
la Microsoft denumită Microsoft Dynamics, situate pe niveluri (tiere) diferite sau care
deservesc domenii diferite (ERP sau CRM). Navision a fost achiziţionat în 2002 de Microsoft.
A trecut prin etape succesive de integrare în portofoliul de soluţii Microsoft. De la Navision,
The way to grow la Microsoft Business Solutions Navision, şi apoi la actualul nume
Microsoft Dynamics NAV, acest proces a însemnat şi o aliniere strategică a produsului. În
Navision este utilizată ca tehnologie C/SIDE (Client/Server Integrated Development
Environment) şi ca limbaj de programare C/AL (Client Application Language).
În prezent, suita Microsoft Dynamics este formată din următoarele soluţii:
Microsoft Dynamics NAV – pentru companiile medii şi filiale de companii
multinaţionale;
Microsoft Dynamics AX – ERP pentru companii mari;
Microsoft Dynamics CRM – soluţia de administrare a relaţiilor cu clienţii;
Microsoft Dynamics GP – soluţie ERP indisponibilă în România;
Microsoft Dynamics SL – soluţie ERP indisponibilă în România.
Navision în cifre:
peste 50.000 de companii beneficiare din întreaga lume;
peste un milion de utilizatori;
37

peste 1.600 de parteneri certificaţi;
peste 1.000 de soluţii addon dezvoltate de parteneri;
peste 40 de versiuni localizate ale aplicaţiei;
vânzări în peste 130 de ţări.
Navision sa dovedit a fi o alegere inteligentă în domeniul universitar datorită politicii de
licenţiere academică a companiei Microsoft. În plus, Microsoft şi partenerii asociaţi sunt
realmente interesaţi de formarea profesională a noilor generaţii. Facilitarea certificărilor
de Navision, prin vouchere acordate gratis studenţilor specializării „informatică econo
mică”, îi motivează pe aceştia să investească în dezvoltarea lor profesională. Acesta este şi
motivul pentru care aplicaţiile din această carte vor fi prezentate pe această platformă.

Aşa cum remarcam, în anul 2000, piața ERP era „aşezată”, matură în mare
măsură. Ea şi‐a menținut însă caracterul dinamic consemnând intrarea unor nou‐
veniți (atât novici, cât şi versați) şi schimbarea de orientare a firmelor existente.
Cum cererea de ERP‐uri la nivelul corporațiilor era satisfăcută, marile case de
software şi‐au redefinit strategia, țintind către piața de mijloc, unde potența
financiară este mai mică, dar numărul clienților este foarte mare. Piaţa de mijloc a
devenit noul teren de luptă al ofertanților.

Pe siteurile publicaţiilor electronice de profil se derulează o continuă dezbatere pe tema
adoptării ERP de firmele mici şi mijlocii (IMM), pornind de la legitima întrebare: pot
beneficiile recompensa eforturile (costurile) implementării ERP? În ansamblu privind, toată
lumea este de acord că beneficiile ERP au fost atinse, dar au fost înregistrate şi multe
nemulţumiri ori obiective neîndeplinite (sau pe jumătate realizate). Aşa cum o
demonstrează practica, în cazul beneficiilor nu există nicio garanţie că implementarea va
materializa beneficiile anticipate/aşteptate. Cu atât mai mult, în cazul unui risc crescut,
deoarece cheltuiala, raportată la veniturile şi numărul de angajaţi, este mai mare faţă de
cea dintro implementare la o firmă de dimensiuni mari.
Totuşi, alegerea unui ERP se poate dovedi o carte câştigătoare în partida cu piaţa şi competiţia.
Multe firme cu potenţial sunt încetinite de un sistem informatic lent şi ineficient, incapabil
să susţină creşterea afacerii. Implementarea unui ERP poate determina dobândirea unor
practici mai bune şi mai clar definite, cu efecte imediate în eficienţa operaţională, obţinerea
şi utilizarea de informaţii în timp real, pe care nu leau avut înainte, cu efecte pozitive în
procesul de luare a deciziilor.
În acest context şi pe fondul multor dezbateri în triunghiul furnizorispecialiştibeneficiari sa
conturat o creştere a pieţei ERP pe segmentul IMMurilor. Dacă la început marii furnizori de
soluţii sau autoexclus prin politica de preţuri, ulterior, ei au gândit oferte speciale pentru
acest segment. Profilul clientului vizat ar fi o firmă de dimensiuni medii, de preferinţă
încadrată întrun domeniu de activitate industrial, căreia îi pot oferi o soluţie specializată,
care înglobează expertiza acumulată în acea verticală şi pe care o pot implementa la un
cost rezonabil, folosind o metodologie de implementare rapidă.

38

O altă particularitate a ofertei ERP după anul 2000 a fost specializarea, în
sensul adaptării unei suite ERP pe o anume verticală de industrie (de exemplu,
industria chimică, industria farmaceutică sau cea alimentară) sau domeniu de
activitate (sectorul public sau comerțul cu amănuntul). Această strategie şi‐a arătat
roadele pentru unii furnizori, care în felul acesta şi‐au valorificat experiența unor
implementări specifice într‐o ofertă cu greutate şi cărora li s‐a recunoscut
dominarea pe o anume verticală.
Evoluția ERP, aflată într‐o nouă fază în anii 2000, a produs mutații şi pe piața
furnizorilor. Clienții şi‐au schimbat optica asupra operațiunilor, dorindu‐le orientate
către exterior, năzuind la crearea unui sistem mai apropiat, interactiv, cu clienții şi
furnizorii. Pe fondul avântului tehnologic, al expansiunii telecomunicațiilor şi al
creşterii comerțului electronic, au apărut două direcții de înaintare. Pe de o parte,
s‐au ivit mulți furnizori specializați, cu oferte de SCM – aplicații de management al
lanțului de aprovizionare (i2 Technologies, Manugistics) sau de CRM – aplicații de
management al relațiilor cu clienții (Vantive, Siebel). Ei au avut meritul de a propulsa
aceste aplicații inovative, chiar dacă s‐a dovedit mai apoi că nu le pot susține (cei mai
mulți au sfârşit prin a fi preluați de firmele puternice din sfera ERP24).
Cea de‐a doua direcție au susținut‐o casele de soluții ERP, liderii de piață, care
au inițiat la rândul lor proiecte de cercetare şi dezvoltare care să susțină noile
platforme de aplicații. Atingerea unui nivel de maturitate a suitelor ERP pe care le
dețin le‐a permis acestora să se reinventeze, pentru a îngloba funcționalitățile
extinse în ofertele lor ERP. Puține au fost cazurile în care un mare furnizor a ales
alianța cu un furnizor de nişă – dacă inițial au fost propuse ca alianțe, în final peştele
mare l‐a înghițit pe cel mic (vezi nota de subsol nr. 25). Cei mai mulți au preferat să
dezvolte propriile aplicații CRM, SCM şi de e‐commerce, adesea prin preluarea unor
firme mici cu inițiative software în aceste domenii.

A fost o vreme25 când producătorii de soft au vândut mult şi pe mulţi bani. Vremurile noi
presupun schimbări „pregătite”. Deşi proiectele mari, de valori ameţitoare, vor rămâne pe
zona serviciilor publice, în zona companiilor private nevoia de calitate şi utilitate la preţuri
optime a început săşi spună cuvântul. Anunţul26 de a creşte costurile de mentenanţă, lansat
la sfârşitul anului 2009 de SAP, a provocat o reacţie normală din partea clienţilor (la care
sar fi aşteptat oricine în plină criză) deşi, ulterior, SAP a revenit cu declaraţii
surprinzătoare: „Am făcut o greşeală”. Putem însă, ca muritori de rând, să ne întrebăm

24 Manugistics a fost achiziționată în 2006 de rivala JDA Software Group, iar i2 Technologies, o
companie cu state vechi (1998), lider pe piața SCM, a rezistat până în 2010, când a fost preluată de
aceeaşi JDA Software Group. Vantive (1990), lider pe piața CRM până atunci, a fost cumpărată de
Peoplesoft în 1999, iar Siebel (1993) s‐a înclinat în fața mamutului Oracle, care a preluat‐o în 2005.
25 Discuțiile sunt preluate de pe site‐ul fanilor SAP din România (vezi http://www.sapfans.ro/
author/andrei/).
26 Vezi povestea completă pe http://www.nytimes.com/2010/02/09/technology/companies/ 09sap.html
39

dacă: A fost o greşeală sau o strategie? Noi, românii, suntem obişnuiţi cu astfel de creşteri,
făcute doar pentru a te bucura de scăderea la valoarea anterioară. Cam acelaşi lucru se
poate spune şi despre această tactică aplicată cu succes întrun moment în care toţi clienţii
încercau să negocieze la sânge orice contract în derulare. Pentru domeniul universitar
putem povesti din propria experienţă (Universitatea „Alexandru Ioan Cuza” Iaşi, Facultatea
de Economie şi Administrarea Afacerilor) că furnizorii locali de produse SAP (în speţă The
Red Point Iaşi) au refuzat să sprijine mediul universitar în afara plăţii serviciilor de
întreţinere. Serviciile de întreţinere în acest caz nu presupuneau upgrade pentru aplicaţii, ci
asigurarea funcţionalităţii pachetului şi întreţinerea serverului SAP. Cum oamenii trebuiau
plătiţi, nu au mai asigurat suport domeniului universitar şi cum şi universitatea a fost lovită
de criză, contractul de sponsorizare sa încheiat. Nouă, specialiştilor independenţi, care
doar familiarizează studenţii cu aceste platforme, nu nea rămas decât să ne orientăm spre
alte soluţii, mai „prietenoase”.
Revenind la strategii, mutarea tehnologiilor „în cloud” este gândită şi dezvoltată de ani buni
deja, prefigurânduse următorul boom în industrie, condiţia reuşitei fiind utilitatea şi
fiabilitatea noilor tehnologii. ORACLE, IBM, MICROSOFT, SAP, dar şi producătorii consacraţi
de hardware (HP) duc o luptă acerbă de câştigare a unei felii din noul trend. Erodate de
suprasaturarea pieţei, de criza financiară care a pus stăpânire pe clienţi, dar şi de lupta
dintre ele pentru controlul unor cote cât mai mari, profitând de lăcomia guvernelor,
funcţionarilor, dar şi a angajaţilor firmelor private, marile companii producătoare de
software caută o nouă cale pentru a ajunge la inima şi buzunarul clienţilor. Pe lângă noile
tehnologii, sunt necesare schimbări profunde, noi oameni şi direcţii noi de dezvoltare.

Un rol important în dezvoltarea pieței de ERP revine integratorilor de
sisteme. Chiar dacă nu au meritul de a fi dezvoltat suitele ERP, lor le revine
misiunea anevoioasă a implementării suitelor ERP.
Apariția unei terțe părți, interpusă între dezvoltatorul de software şi client,
este specifică pieței ERP încă din anii ’90. Clientul va cumpăra licențele software de
la furnizor, iar costul implementării şi al suportului postimplementare va fi plătit
integratorului de sistem. De multe ori, acesta oferă şi echipamentele necesare
pentru realizarea proiectului, dar şi personalizarea (customizare27) aplicațiilor, ceea
ce înseamnă că adaugă valoare acestora. Din acest ultim motiv, ei sunt numiți şi
revânzători cu valoare adăugată (în original Value Added Resselers – VARs).
Cel mai adesea, integratorii de sisteme sunt parteneri ai furnizorilor de ERP,
ceea ce le oferă acestora din urmă avantajul unor capacități de implementare
sporite, ca şi cel al accesului pe piețe noi. Expansiunea geografică şi creşterea
veniturilor marilor furnizori se explică astfel, iar cel mai bun exemplu este SAP, care
la sfârşitul anului 2009 avea nu mai puțin de 2.400 de parteneri certificați în
întreaga lume28.
Prezentarea pieței de ERP nu se poate încheia fără a aduce la rampă o
categorie aparte de actori: consultanţii. Este adesea pusă la îndoială finalizarea cu

27 Customizare – cuvânt preluat din limba engleză (to customize) în vocabularul utilizat în
implementările ERP, traducerea adecvată a termenului în limba română este personalizare. Deşi
preferăm utilizarea termenului personalizare, în lucrarea de față veți întâlni ambele variante.
28 Cifre oferite de SAP AG, vezi http://www.sap.com/about/investor/inbrief/index.epx
40

succes a unei implementări realizate de un integrator de sisteme. Deşi temerile nu
sunt întotdeauna justificate, căci o alegere atentă, cu verificarea referințelor şi a
bonității acestuia, poate elimina riscul ca proiectul să eşueze din motive ca lipsa de
experiență sau instabilitatea financiară. Un mod sigur de a atenua şi chiar elimina
riscurile este solicitarea serviciilor unei firme de consultanță independente.
Consultanții vin cu experiență, expertiză şi idei din proiectele trecute şi din alte
companii şi industrii. Cu sute de alte proiecte în spate şi o experiență prețioasă în a
lucra cu o mulțime de situații şi personalități, ei furnizează idei noi şi imparțiale.
Consultantul este interfața dintre echipa tehnică şi utilizatorii noului sistem. El
este un membru important al echipei de implementare, cu atribuții din faza inițială
de prezentare a sistemului şi analiză, până la startul productiv şi predarea
sistemului. Un bun consultant ERP este cel care ştie:
să asculte şi să înțeleagă nevoile clientului;
să exprime clar şi concis ideile şi recomandările sale;
să‐şi exprime dezacordul atunci când este cazul, fără însă a periclita relația
cu clientul;
să se adapteze la diversele culturi organizaționale şi stiluri de management
pe care le întâlneşte.
Un consultant respectat va spune că nu este suficient să ai dreptate atunci
când propui/analizezi ceva, ci trebuie să fii util, iar o astfel de percepție stabileşte o
punte de încredere cu clientul, astfel încât atunci când consultantul propune sau
semnalează o problemă să fie ascultat şi luat în serios.
Ca mod de abordare a consultanței, putem discuta două posibilități. În prima
variantă, clientul cere o soluție şi o adoptă. Consultantul discută în acest caz cu
clientul şi trebuie să înțeleagă întreaga activitate a acestuia, propunând o soluție
unică, adaptată nevoilor celui din urmă. După ce clientul analizează şi acceptă soluția
propusă de consultant, pe parcursul implementării, rolul acestuia este de a îndeplini
toți paşii necesari impuşi de consultant. De exemplu, alegerea celei mai potrivite
soluții ERP este un proces care se poate rezolva în acest mod de abordare.
În varianta a doua, consultantul poate acționa, dimpotrivă, ca un angajat al
clientului pe o anumită activitate/domeniu. Consultantul devine astfel „mâna
dreaptă” a clientului, implementând deciziile acestuia, răspunderea pentru deciziile
luate revenind în întregime clientului. Practic, consultantul implementează soluția
aleasă de client, aplicând cunoştințele şi experiența sa în domeniul respectiv.
Indiferent de modul de abordare, comunicarea permanentă între client şi
consultant este foarte importantă. Tocmai pentru a nu se crea confuzii care pot fi
dezastruoase pentru succesul misiunii de consultanță, deci şi pentru client, stabilirea
cu exactitate a rolului care urmează a fi îndeplinit de consultant şi implicit a rolului
clientului se impune a fi făcută încă de la începutul relației. Cu atât mai mult cu cât
astfel de servicii sunt costisitoare, iar la nivelul firmelor de consultanță de top
prețurile serviciilor sunt de‐a dreptul exorbitante.

41

42

CAPITOLUL 2
Procese economice, modelare şi integrare
prin platforme integrate

& fiţi familiarizaţi cu funcţiunile şi procesele economice dintro afacere;
& puteţi explica funcţiunile contabilă, financiară, de marketing, de
producţie, de salarizare şi management al resurselor umane;
& aveţi la îndemână un exemplu de funcţiune din oferta de pe piaţa ERP
din România;
& aveţi cunoştinţă despre trecerea de la abordarea funcţională la
orientarea pe proces în sisteme informaţionale;
& recunoaşteţi importanţa workflow;
& puteţi detalia elementelecheie workflow şi să puteţi face comparaţii
între tipuri diferite de workflow;
& fiţi familiarizaţi cu noţiunea de modelare a proceselor şi să faceţi
exerciţii de modelare pentru un proces pe care îl cunoaşteţi, după
modelul prezentat pe procese de vânzări.

2.1. Despre funcţiuni şi procese economice

Un proces economic reprezintă o colecţie de activităţi care preiau una sau mai
multe intrări şi creează o ieşire care prezintă valoare pentru client. Un proces de
afaceri presupune intersectarea mai multor funcții într‐o companie.
De exemplu, putem avea un departament numit „contabilitate” sau o funcție
denumită „salarizare”. Deşi fiecare funcție presupune existența proceselor de
afaceri, aceste funcții nu sunt bazate pe procese.
Un proces de afaceri mai amplu, de exemplu, „de la comandă la numerar”
presupune toți paşii, începând cu comanda clientului şi terminând cu livrarea
banilor în contul companiei. Acesta este un mod mult mai eficient de a privi aceste
procese şi modul lor de funcționare în cadrul unei companii.
Conceptul de management al procesului trebuie detaliat având în vedere atât
managementul calității, cât şi latura pur tehnică a procesului, privind lucrurile strict
din acest punct de vedere. Managementul proceselor de afaceri presupune
managementul detaliilor tehnicoeconomice ale procesului în sine, luând în calcul şi
factorii de risc care intervin în derularea unui proces. De asemenea, dacă, din punct
de vedere funcțional, procesele au o componentă statică şi una dinamică, se pune
problema cum şi când pot să transform o componentă în alta cu un consum
minimum de resurse şi energie. De aici încep discuțiile despre flexibilitatea
procesului şi impactul schimbării asupra activității.
Platformele pentru afaceri sprijină operarea eficientă a proceselor economice
prin integrarea activităților dintr‐o organizație. O soluție ERP trebuie să
îmbunătățească modul de desfăşurare a activităților economice. ERP înseamnă să
găsim armonia dintre software şi procesele economice din fiecare organizaţie.
Aşa cum am mai spus, ca să înțelegem ERP, trebuie să cunoaştem foarte bine
modul de funcționare a unei organizației economice.

2.1.1. Funcţiuni şi arii funcţionale întro organizaţie

Se poate vorbi despre o afacere (denumită întreprindere, firmă, organizație,
companie etc.) atunci când aceasta oferă produse ori servicii clienților săi:
o întreprindere industrială operează în zona producției, fabricând bunuri
pe care le vinde altor întreprinderi sau clienților individuali;
un angrosist achiziționează cantități mari de bunuri, pe care le distribuie
comercianților;
comercianții vând clienților individuali bunuri achiziționate de la
producători ori angrosişti;
firmele de servicii oferă clienților (individuali ori alte firme) diverse
servicii.
Indiferent de profilul său, o firmă are anumite cheltuieli pentru a obține
produsele ori serviciile pe care le oferă clienților şi pe baza cărora realizează
venituri. Atunci când veniturile obținute sunt mai mari decât cheltuielile, firma
înregistrează profit, în situația inversă, ea lucrează în pierdere.
Procese economice, modelare şi integrare prin platforme integrate 45
De precizat că nu toate firmele lucrează pentru profit. Excepție fac
organizațiile nonprofit, care‐şi folosesc veniturile pentru a‐şi desfăşura şi îmbunătăți
activitatea: şcoli, spitale, biserici, agenții guvernamentale.
Toate firmele funcționează într‐un mediu economic, în care se manifestă
diverşi factori:
economici, care determină, printre altele, puterea de cumpărare;
juridici, care stabilesc cadrul juridic, legal, ce reglementează activitatea
firmelor;
culturali şi sociali, care influențează caracteristicile bunurilor şi serviciilor
de pe piață;
de competiţie, care determină oferta şi influențează prețurile produselor şi
serviciilor.
În ultimii ani, am asistat la globalizarea afacerilor, motiv pentru care efectele
acestor factori depăşesc granițele unei singure țări: afacerile internaționale trebuie
să aibă în vedere aspectele economice, legale, culturale, din diferitele regiuni în care
îşi desfăşoară activitatea1.
Funcționarea întreprinderii se concretizează în activități circumscrise mai
multor funcțiuni. Cunoaşterea lor este importantă, întrucât ele se concretizează
diferit în funcție de tipul întreprinderii, influențând esențial organizarea ei.
În evoluția organizației se observă tendința evidentă de integrare funcțională
a activităților prin înlănțuirea tuturor elementelor unei întreprinderi în jurul aşa‐
numitei „baze de date unice”, deziderat devenit posibil în urma spectaculoasei
dezvoltări tehnologice din ultimii 30 de ani.
Precizăm că divizarea sistemului informaţional pe criterii funcţionale este
criticată în multe lucrări din literatura de specialitate. Anii ’90 au dus la apariția unui
curent de opinie care susține că întreprinderea îşi va desfăşura activitatea prin
procese economice orientate spre client2. Realitatea spargerii barierelor dintre
compartimente (producție, desfacere, contabilitate şi personal, toate aceste
funcțiuni încadrându‐se în procese organizaționale) a fost verificată deja în ultimii
ani. În acest sens, Steve Alter prezintă o structură combinată procese‐funcțiuni a
sistemului informațional dintr‐o întreprindere (vezi tabelul 2.1). El delimitează trei
categorii de procese economice:
cele care solicită eforturi coordonate din partea mai multor arii funcționale;
specifice fiecărui compartiment funcțional;
subprocese şi activități care se desfăşoară în toate ariile funcționale.

1 R. Nickerson, Business and Information Systems, Prentice Hall, 2001.
2 S. Alter, Information Systems, Benjamin/Cummings Publishing Co., 1996, p. 59, citat şi de L. Fînaru, în
Contribuţii privind sistemele informatice în gestiunea financiară a societăţilor comerciale, teză de
doctorat, Iaşi, 1999.

Tabelul 2.1
Procese economice şi structura funcţională a întreprinderii

Procese economice care solicită eforturi coordonate din partea mai multor arii
funcţionale
crearea unui produs nou
crearea unui plan de afaceri pentru o acțiune
îndeplinirea cerințelor clienților/consumatorilor
Procese economice specifice fiecărui compartiment funcţional
Desfacere şi Cercetare Financiar Resurse
Producţie
marketing dezvoltare contabilitate umane
9 achiziția 9 identificarea 9 identificarea 9 înregistrarea 9 stabilirea
de materii clienților de noi metode tranzacțiilor necesarului
prime potențiali de producție 9 întocmirea de personal
9 fabricarea 9 studii de piață 9 inovații rapoartelor 9 angajare
produsului 9 identificarea 9 identificarea financiar‐ 9 pregătire
9 service oportunităților de posibilităților de contabile şi dezvoltare
pe piață îmbunătățire a 9 identificarea şi 9 rezolvarea
9 promovarea produselor plata taxelor conflictelor
produselor 9 investiții
9 urmărirea 9 diverse
vânzărilor operațiuni
financiare
Subprocese şi activităţi care se desfăşoară în toate ariile funcţionale
comunicarea dintre indivizi
analiza datelor
motivarea personalului
planificarea sarcinilor
urmărirea modului de desfăşurare a activității
controlul
Sursa: Prelucrare după Alter, S., Information Systems, Benjamin/Cummings Publishing Co., 1996, p. 60.

2.1.1.1. Funcţiunea contabilă

Funcţiunea contabilă este responsabilă cu înregistrarea tuturor tranzacțiilor
şi raportarea informațiilor financiare ale întreprinderii. Reflectarea în contabilitate
are în vedere atât bunurile întreprinderii, averea acesteia (clădiri, echipamente,
lichidități), cât şi datoriile acesteia. Contabilitatea3 oferă un sistem de informații
corelat şi verificat, nelăsând loc subiectivismului în economie şi promovând
rigurozitatea în reflectarea fenomenelor economice sociale. Astfel, sunt înregistrate
cu fidelitate toate veniturile şi cheltuielile. Sintetizând toate informațiile,
contabilitatea oferă periodic rapoarte despre situația financiară a întreprinderii.
Contabilitatea este considerată limbajul afacerilor, deoarece reprezintă un
mijloc de comunicare a informațiilor operaționale şi financiare privind activitatea
economică a tuturor celor interesați. „Produsele" contabilității (rapoarte şi situații)

3 H. Bouquin, Contabilitate de gestiune, Tipografia Moldova, Iaşi, 2004, pp. 5, 19.
sunt realizate pentru două grupuri principale de utilizatori, cu interese, nevoi şi
puncte de vedere diferite. Primul grup este exterior întreprinderii şi este preocupat
de puterea financiară şi performanțele întreprinderii, iar al doilea grup este format
în principal de managerii situați pe diferite niveluri ale conducerii. Pentru a putea
răspunde cererii de informații a diferitelor categorii de utilizatori, contabilitatea se
grefează pe dualismul contabil:
contabilitatea financiară, numită şi contabilitate sintetică sau generală, care
asigură cadrul general al reflectării patrimoniului, are la bază normele unitare
prevăzute în Legea contabilității şi regulamentele aprobate, cu caracter obligatoriu
pentru toate întreprinderile;
contabilitatea managerială sau de gestiune internă (analitică), ce este
organizată de fiecare întreprindere, în funcție de specificul activității şi necesități. În
contabilitatea de gestiune sunt aplicate metode de lucru desemnate drept tehnici
care pot fi modelate fidel prin platformele informatice. Resursele globalizate nu sunt
numai financiare şi reprezintă procesele, sistemele de management, personalul
format, capacitățile de inovare, moralul, suplețea culturală şi chiar fidelitatea
clienților, putând fi clasate drept resurse strategice, competențe fundamentale sau
capital intelectual.

Charisma ERP – http://www.charisma.ro/solutiisisistemeerp/contabilitate/
Modulul „Contabilitate” este o soluţie software robustă, care adună datele din toate modulele
operaţionale ale sistemului Charisma ERP şi le integrează întro formă contabilă. Indiferent
de structura, dimensiunea, cadrul internaţional, limba, moneda sau planul de conturi al
companiei, modulul are capacitatea de a furniza centralizat datele financiare, informaţii
esenţiale despre poziţia financiară a companiei, despre rezultatele şi evoluţia performanţei
financiare în timp.
Funcţionalităţi Charisma ERP Contabilitate:
asigură managementul paralel al locaţiilor companiei sau al celorlalte societăţi, fie că
sunt părţi ale unui holding, fie că sunt total independente;
permite definirea exerciţiilor financiare urmărite de sistem şi a perioadelor contabile,
asigurând securitatea datelor atât la nivel operaţional, cât şi contabil;
permite urmărirea simultană a mai multor sisteme contabile – interne sau externe: RAS,
IAS, USGAAP, de grup, IFRS etc.), bancare sau de grup. Fiecare tranzacţie operaţională
va fi evaluată contabil diferit, pe baza contării. Configurarea iniţială a sistemului va
permite obţinerea instantanee a rezultatelor în oricare dintre sistemele prezentate;
oferă o soluţie cu privire la reglementările BNR referitoare la raportarea CRB în privinţa
debitelor pe care clienţii le înregistrează la companiile de tip IFN;
asigură un grad înalt de configurabilitate – se pot configura cele mai importante entităţi
adaptate pe specificul companiei: planuri de conturi pe fiecare sistem contabil, centre de
cost pentru alocarea veniturilor şi cheltuielilor, modele de contare pe fiecare tranzacţie
operaţională, clasificări conturi, cote de TVA;
permite lucrul simultan în două perioade distincte (luni, ani). Astfel, înainte de
închiderea contabilă a unei luni se poate deja lucra curent în luna următoare. La

sfârşitul anului se vor putea face modificări în datele lunii decembrie până la terminarea
bilanţului. Orice modificare se va transmite corespunzător în datele fiecărei luni a anului
următor;
este multivalută – permite înregistrarea datelor în orice valută, simultan cu trecerea lor
întro monedă de referinţă, alta decât cea legală (LEU, BGN, RUR, LEK etc.). Urmând
tratamentul specific contului respectiv (monetar sau nemonetar), rapoartele se obţin
instantaneu în orice valută;
realizează contările în mod automat a documentelor operaţionale, pe baza unor modele
de contare configurate la iniţializarea sistemului. Toate înregistrările contabile
automate devin instantaneu valide şi apar efectiv în rulajele conturilor;
integrează managementul riscului – sistemul previzionează şi uniformizează veniturile
companiei prin calculul de provizioane standardizate;
permite introducerea de note contabile manuale în cazul unor situaţii speciale fie prin
folosirea unor machete predefinite, fie direct, de un utilizator avizat;
ataşează fiecărei note contabile (automată sau manuală) mai multe dimensiuni de
analiză (departamente, proiecte, contracte etc.), permiţând obţinerea de rapoarte (fişe
de cont, balanţe etc.) filtrate pe aceste dimensiuni;
permite consolidarea rezultatelor anuale contabile pentru societăţile parte a unui
holding, pe baza unui plan de consolidare predefinit;
asigură toate rapoartele legale (locale, reglementate de băncile naţionale sau de
Uniunea Europeană) şi o gamă largă de rapoarte uzuale: Registruljurnal general,
cartea mare, cartea mareşah, fişe de cont (multiperioadă, multivalută); Jurnalul de
vânzări; Jurnalul de cumpărări; Declaraţia de TVA; VIES, Intrastat; balanţa contabilă
configurabilă (sintetică, analitică, pe mai multe niveluri, cu diverse tipuri de coloane, cu
excluderi de conturi etc.); raportări de TVA, impozite şi taxe către buget; situaţia
patrimoniului, contul de profit şi pierdere, cât şi anexe conform bilanţului românesc;
oferă utilizatorului posibilitatea creării de rapoarte folosind baza de date şi generatorul
de rapoarte;
permite configurarea rapoartelor speciale cumulate (de tip bilanţ, profit şi pierderi,
cashflow etc.) întrun mod extrem de simplu şi intuitiv. Pot fi memorate şi utilizate
ulterior oricâte astfel de rapoarte;
beneficiază de funcţii de export/import al datelor contabile necesare raportărilor sau

provenite din surse externe.

2.1.1.2. Funcţiunea financiară

Funcţiunea financiară asigură obținerea resurselor financiare necesare
întreprinderii şi planificarea utilizării acestor resurse. Sursele financiare sunt:
vânzarea bunurilor şi serviciilor, investițiile realizate de întreprindere, împrumuturi
obținute de la bănci sau alte instituții. Atunci când întreprinderea obține bani, ea îi
poate folosi în operațiunile curente (pentru desfăşurarea activității de bază) sau îi
poate investi pe termen lung.
Funcțiunea financiară reuneşte activitățile de determinare şi asigurare a
resurselor financiare necesare realizării obiectivelor întreprinderii, de utilizare
eficientă şi profitabilă a acestor resurse, în scopul obținerii celor mai favorabile
rezultate pe termen lung4. Situațiile financiare reflectă sintetic toate efectele
deciziilor trecute ale managementului şi sunt guvernate de reglementări care
urmăresc reflectarea justă în contabilitate a fiecărei tranzacții, respectând
următoarele principii5:
tranzacțiile sunt înregistrate în contabilitate la valori istorice (de intrare);
ajustările acestor valori se fac numai în cazul în care se înregistrează o
depreciere a acestora;
veniturile şi cheltuielile sunt recunoscute la data angajării acestora şi nu la
data încasării/plății lor;
echilibrul periodic între venituri şi cheltuieli se realizează prin intermediul
reportărilor (ex.: rezultatul reportat), amânărilor (impozit pe profit amânat) sau al
repartizărilor contabile (cheltuieli înregistrate în avans);
reducerile de valoare în cazul deprecierilor se realizează atât prin
reducerea valorii activului respectiv, cât şi a profitului (prin intermediul cheltuielii),
fiind afectat, de obicei, nivelul capitalurilor proprii ale companiei.
Aceste reguli contabile lasă o marjă importantă în interpretarea situațiilor
financiare anuale, în consecință, activitățile circumscrise funcțiunii de analiză se
concretizează în gestiunea financiară a întreprinderii (sau management financiar,
după sursele anglo‐saxone). În cursul derulării procesului de analiză, situațiile
financiare, bazele de date şi alte surse informaționale sunt utilizate în vederea
formulării unor concluzii pertinente despre trecut, prezent şi condițiile de derulare
pe viitor a activității, precum şi despre eficiența managementului unei afaceri.

Charisma ERP – http://www.charisma.ro/solutiisisistemeerp/financiar/„Financiar”
Modulul asigură funcţionalităţi în concordanţă cu reglementările interne şi de grup,
monitorizând fluxurile de bani prezente şi viitoare din cadrul unei companii, pe ansamblul
ei sau pe subunităţi componente.
Funcţionalităţi Charisma ERP Financiar:
monitorizează creanţele şi datoriile partenerilor financiari:
– gestionează toate sumele încasate/plătite prin submodulele „Bancă” şi „Casă”, în lei sau
în orice valută. Toate sumele sunt repartizate pe parteneri şi facturi (sau documente
echivalente);
– oferă funcţionalităţi pentru compensări între facturi, între creanţe şi datorii,
multipartener şi multivalută;
– reglări de facturi;
– realocări de încasări şi plăţi, manual sau în mod automat, pe bază de reguli de alocare;
– reevaluare automată a creanţelor şi datoriilor în valută, păstrând şi cursul istoric iniţial
al documentelor, reducând astfel timpul necesar gestionării acestora;

4 C. Hurbean, Sisteme informatice pentru managementul firmei, Editura Mirton, Timişoara, 2001, p. 32.
5 E. Helfert, Tehnici de analiză financiară. Ghid pentru crearea valorii, Editura BMT, Bucureşti, 2006,
pp. 18, 33.

– utilizează toate tipurile de documente bancare (OP, chitanţă, bon fiscal, CEC, bilet la
ordin, carte de credit etc.), fiecare cu tratamentul său specific;
gestionează rapid şi eficient avansurile plătite/încasate. Pentru companiile cu un număr
mare de parteneri şi operaţiuni financiare, sistemul dispune de închidere automată a
avansurilor cu facturile apărute ulterior;
permite prelucrarea încasărilor şi plăţilor internaţionale – se pot defini un număr
nelimitat de valute, astfel că, pe baza cursului valutar al zilei, se pot face raportări în
oricare dintre valutele alese. Sistemul determină automat toate diferenţele de curs la
operaţiile desfăşurate în valută;
include managementul decontărilor cu angajaţii sau cu terţe persoane;
facilitează comunicarea cu băncile şi conturile de încasări şi plăţi – este compatibil cu
extrasele bancare electronice (multicash) furnizate de diferite bănci; exportă şi importă
plăţi şi încasări diverse pe conturile companiei şi realizează legături automate cu
facturile din sistem pe baza unor reguli configurabile;
identifică tendinţe ale evoluţiei financiare:
– colectarea şi prelucrarea datelor istorice prezente;
– calculul principalilor indicatori financiari şi analiza lor în funcţie de specificul şi
sezonalitatea activităţii societăţii la momentul prezent sau pe perioade anterioare;
urmăreşte online toate creanţele şi datoriile, indiferent de natura lor. Se urmăresc
plăţile la furnizori şi repartizarea lor pe facturi primite, respectiv încasările de la clienţi
şi repartizarea pe facturi;
asigură un sistem automat de generare a plăţilor aflate la scadenţă, utilizând modurile
de plată dorite, banca şi contul dorit;
include evidenţa valorilor mobiliare;
asigură toate rapoartele legale şi o gamă largă de rapoarte uzuale, cum ar fi registre de
bancă şi de casă, facturi clienţi/furnizori neînchise, balanţe de parteneri pe vechime,
legături între facturi şi plăţi, avansuri neînchise etc.;
rulează rapoarte referitoare la situaţia financiară a societăţii:
– situaţii complete şi diverse privitoare la creanţe şi datorii, prezentate pe parteneri,
perioade, agenţi, locaţii etc.;
– formulare de evidenţiere a situaţiei financiare;
– formulare definite în funcţie de specificul şi necesităţile societăţii;
simplifică şi uşurează comunicarea cu auditorii sau cu grupul din care face parte
compania, printro imagine integrată şi uniformă a finanţelor;
este integrat nativ cu modulele de bază din suita Charisma ERP: Financiar, Vânzări,
Achiziţii, Mijloace Fixe, Gestiunea bugetelor, Gestiunea stocurilor, Comerţul exterior,

Gestiunea asigurărilor şi a contractelor de finanţare.

2.1.1.3. Funcţiunea de marketing

Funcţiunea de marketing este denumită şi de vânzare tocmai pentru că are
ca principal obiectiv vânzarea bunurilor şi serviciilor. Activitățile circumscrise
acestei funcțiuni vizează:
stabilirea produselor care vor fi vândute şi prețurile acestora;
promovarea produselor prin publicitate, campanii de vânzare sau alte mijloace;
vânzarea propriu‐zisă, inclusiv distribuția şi transportul acestora.
Dimensiunile funcțiunii de marketing dintr‐o organizație sunt diferite, fiind

determinate în principal de profilul acesteia. Spre exemplu, cele care operează în
zona comerțului au această funcție bine dezvoltată, pe când cele de producție au mai
puține preocupări specifice marketingului, mai ales dacă îşi vând produsele prin
distribuitori sau un număr mic de angrosişti.
Funcția de marketing a căpătat şi ea valențe sporite în condițiile accentuării
competiției dintre firme. Astfel, se discută despre elemente precum cotă de piață,
canale de distribuție, campanii de promovare şi analiza eficienței acestora, politici
de atragere şi fidelizare a clienților mai mult decât oricând. Ar mai fi de menționat
aici că în vechile structuri de la noi activitățile acestei funcțiuni se regăseau în
funcțiunea comercială, însărcinată cu contractarea şi vânzarea, mai mult decât cu
promovarea produselor.
Concret, activitățile de cercetare şi studiu întreprinse sunt:
cercetarea pieței, interesată să identifice natura, compoziția şi preferințele
pieței actuale sau potențiale;
studiul comportamentului consumatorului;
studiul competitorilor;
cercetarea produselor, mai ales în cazul creării de noi produse, pentru a
asigura că ele, caracteristicile lor (inclusiv prețurile) se potrivesc cu cele cerute de
piață;
studiul distribuției, întreprins pentru a identifica eficacitatea diverşilor
distribuitori sau agenți;
toate acestea se combină cu cercetarea economică şi socială, care identifică
tendințele din mediu şi impactul acestora asupra politicii de marketing.
În consecință, direcţiile principale în cercetarea de marketing6 se referă la
analiza vânzărilor, a dimensiunilor pieţei (capacitate şi potenţial), evaluarea
conjuncturii de piaţă, măsurarea cotelor de piaţă, segmentarea pieţei, analiza
comportamentului consumatorului, teste de produs, analiza preţurilor, a campaniilor
promoţionale, teste de amplasament etc.

Charisma ERP – http://www.charisma.ro/solutii‐si‐sisteme‐erp/vanzari/
Modulul „Vânzări” oferă suport pentru execuţia strategiei comerciale, folosind mai eficient
fiecare resursă internă pentru deservirea şi creşterea numărului de clienţi, indiferent de
sectorul de activitate în care activaţi. Modulul automatizează şi centralizează cererile de
ofertă, ofertele, comenzile, facturile, avizele, campaniile de discounturi sau promoţii, target
uri, tipurile de clienţi, zonele de vânzare sau zonele de livrare.
Funcţionalităţi Charisma ERP Vânzări:
îmbunătăţeşte gestiunea clienţilor şi a contractelor comerciale;
permite multiple clasificări ierarhizate de clienţi sau produse cu scopul raportării;

6 C. Munteanu, E. Maxim, C. Sasu, Ş. Prutianu ş.a., Marketing – principii, practici, orizonturi, Editura
Sedcom Libris, Iaşi, 2006, p. 24.

gestionează fluxul complet de documente din ciclul unei vânzări (cerere de ofertă, ofertă,
comandă client, confirmare comandă client, aviz de însoţire, factura de vânzare etc.);
satisface particularitatea organizaţiei prin facturarea în formatul specific companiei,
ţării sau grupului;
permite facturare pe loturi, simultan pentru mai mulţi clienţi (de ordinul miilor) pe baza
condiţiilor specificate în contract şi pe baza activităţii realizate cu respectivii clienţi întro
anumită perioadă;
beneficiază de un motor de preţuri bazat pe o politică de tip comercial cu un grad mare
de configurabilitate (permite discounturi şi promoţii aplicate separat sau simultan pe
produs, client, termen plată, agent, grupă de produse, grupă de clienţi etc.);
permite utilizarea de liste de preţuri multiple în lei sau în valută;
clasifică clienţii în portofolii per agent sau în zonă comercială;
asigură credit control din perspectiva datoriei şi a zilelor de întârziere, cu posibilitatea
de blocare sau avertizare la momentul vânzării;
permite gestionarea targeturilor pe clienţi, agenţi, zone, precum şi urmărirea realizării
acestor targeturi cu calcul automat de bonusuri;
permite scăderea automată a stocului pe baza configurărilor realizate la nivel de
tranzacţie (aviz, factură);
beneficiază de funcţionalitatea de „rezervare stoc”, permanentă sau temporară, pe
documentul „Comandă client”;
lucrează cu documente în regim de emitere sau înregistrare concomitent;
realizează încărcarea automată a veniturilor pe centre de cost;
defineşte operaţii automate: realizarea de facturi de vânzare pe baza avizelor de
expediţie emise anterior, de avize pe baza confirmărilor de comenzi etc.;
permite vânzarea în mai multe unităţi de măsură şi împachetări, indiferent de unitatea
de măsură în care a fost achiziţionat produsul;
oferă funcţionalităţi multinaţionale cuprinzând procesare şi managementul facturilor
multivalută şi al TVA internaţionale;
suportă cerinţe specifice la nivel guvernamental, servicii, educaţie, asistenţă medicală etc.;
beneficiază de un pachet puternic de rapoarte de vânzări atât operaţionale, cât şi
manageriale: situaţii de vânzări pe clienţi, articole, perioade (până la nivel orar), agenţi,

zone de vânzare.

2.1.1.4. Funcţiunea de producţie

Funcţiunea de producţie este responsabilă cu fabricarea bunurilor, începând
de la achiziția materiilor prime, materialelor ori semifabricatelor şi gestiunea
acestora în depozit, continuând cu procesul de producție propriu‐zis, până la
obținerea produselor finite, inclusiv controlul de calitate şi stocarea acestora.
Trebuie să asigure fluiditatea procesului de producție şi eficiența acestuia, în
principal din perspectiva costurilor.
Această funcțiune apare doar în întreprinderile care operează în diferite
ramuri industriale, complexitatea fiind dată de dimensiunile organizațiilor. În alte
tipuri de întreprinderi această funcțiune nu există. Ea poate apărea însă în alte
forme: spre exemplu, în sfera serviciilor există o dimensiune operaţională care
urmăreşte activitățile prin care se oferă servicii clienților (fluxul tehnologic este
înlocuit de un flux operațional).
Funcțiunea de producție este în principal de natură tehnică, ea vizând, aşa
cum am arătat, fabricația sau exploatarea, controlul tehnic de calitate, întreținerea şi
repararea utilajelor, producția auxiliară. Dar nu exclusiv, pentru că, pe lângă aceste
activități, se regăsesc şi cele de aprovizionare, de la calculul necesarului de
aprovizionat, la studiul şi alegerea furnizorilor. De asemenea, în momentul începerii
producției are loc un proces7 fundamental de transformare:
o parte a numerarului este utilizată pentru plata periodică a salariilor sau a
diferitelor cheltuieli curente;
materiile prime şi materialele sunt eliberate din stoc şi sunt utilizate în
procesul de producție;
stocurile sunt refăcute pe baza extinderii creditului furnizor;
o parte a necesităților de producție cum ar fi energia şi combustibilul sunt
obținute pe credit, fiind finanțate temporar prin datoriile către aceşti furnizori;
utilizarea fabricii şi a echipamentelor din cadrul producției este reflectată
sub forma cheltuielilor cu amortizarea, care devine o parte a costului procesului de
transformare a materiilor prime în produse vandabile;
pe măsură ce produsele sunt definitivate, sunt transportate în depozit, iar
costul acestora este adăugat stocurilor de produse finite;
în lipsa unei comenzi ferme de la clienți, procesul de producție continuă să
transforme numerarul, materiile prime, cheltuielile neplătite şi creditul comercial
într‐un volum de produse finite în creştere;
costul activelor se reflectă parțial în costul stocurilor.
Creşterea volumului de produse finite aflate în stoc nu poate dura la nesfârşit
şi veniturile din vânzările produselor realizate devin surse esențiale pentru
reconstituirea numerarului necesar pentru achitarea obligațiilor scadente ale
companiei.
Funcţiunea de producţie are în vedere planificarea şi managementul aspectelor
tehnice de producţie, dar şi procesele operaţionale care oferă suport pe ansamblu. Este
o funcțiune foarte dificil de modelat prin aplicații informatice, de aceea suportul
platformelor integrate este absolut obligatoriu, pentru că este mai mult decât
necesară (aşa cum s‐a observat deja) legătura funcțională dintre toate funcțiunile
unei afaceri.

Charisma ERP – http://www.charisma.ro/solutiisisistemeerp/productie/
Charisma Producţie integrează fluxul de producţie în gestiune completă a resurselor şi a
afacerii companiei, oferind avantaje competitive majore, cum ar fi reducerea costurilor,
creşterea calităţii produselor fabricate, răspuns mai rapid la schimbările apărute în
procesele de achiziţie şi vânzare şi creşterea satisfacţiei clienţilor.

7 E. Helfert, op. cit., pp. 51‐54.

Charisma Producţie este un produs destinat companiilor producătoare de materiale, produse
finite şi semifabricate, indiferent de tipul acestora. Parcurgând toate etapele de producţie,
de la lansarea tehnologică şi antecalcul, urmărirea producţiei, şi până la postcalcul,
funcţionalităţile modulului acoperă producţia pe comenzi (serie mică), pe stoc (serie mare),
sau producţia de unicate. Soluţia acoperă producţia de tip asamblare (workshop), dar şi
producţia de tip flux de procese (workflow).
Beneficii financiare şi operaţionale:
defineşte şi urmăreşte eficient structura organizatorică – centrele tehnologice ale
societăţii (secţii, ateliere, puncte de lucru), capacităţile de producţie;
defineşte produsele şi tehnologiile utilizate – definire arborescentă a produselor, alocare
a fiecărui subansamblu la operaţiile specifice, setare şi urmărire a timpilor necesari
fiecărei operaţii;
reduce timpul de producţie pe produs/comandă prin integrarea nativă cu soluţia de
planificare a resurselor pentru producţie (MRP);
reduce costurile de producţie şi optimizează activitatea de aprovizionare:
– diminuarea stocurilor neutilizate, prin achiziţionarea de materii prime sau
subansambluri la momentul potrivit şi în funcţie de capacităţile de producţie;
– evaluarea comenzilor cu ajutorul costului antecalculat bazat pe tehnologia de realizare
a produsului (BOM, reţetă, rută);
– evaluarea costurilor se realizează cu ajutorul postcalculului, acesta folosind o structură
a costului complet configurabilă: alocare cheltuieli pe centre de cost, pe bază de chei de
repartizare, maparea cheltuielilor indirecte în costuri directe, urmărirea cheltuielilor vs.
venituri pe centre de cost;
– generarea comenzilor de achiziţie fie manual (prin introducerea articolelor în cadrul
comenzilor), fie automat (prin preluarea materiilor prime sau subansamblurilor
necesare ordinelor de producţie lansate în execuţie);
eficientizează procesul de producţie prin planificarea producţiei în funcţie de comenzile
clienţilor, capacităţile de producţie, precum şi a performanţelor demonstrate,
raportarea producţiei realizate sau în curs de execuţie, gestionarea deşeurilor şi
asigurarea calităţii;
optimizează timpul de producţie prin identificarea din timp a întârzierilor, prin
urmărire şi control permanente;
reorganizează rapid producţia în vederea optimizării proceselor de producţie (secţii noi,
tehnologii noi, dotări noi);
creşte performanţa angajaţilor, dar mai ales a echipei implicate direct în producţie,
datorită înţelegerii mai profunde a rolului şi a atribuţiilor postului de angajaţii
companiei;
planifică în întregime procesul de producţie prin definirea planurilor de producţie la
diverse niveluri de management, planificarea comenzilor, programarea liniilor de
producţie, descrierea structurii fiecărei comenzi (date de identificare ale comenzii
interne, produse înregistrate în cadrul acelei comenzi şi ordinele de producţie necesare
executării fiecărei comenzi), prin planificarea pe puncte de lucru critice în fluxul de
producţie şi prin urmărirea fluxului cu ajutorul rapoartelor de producţie;
urmăreşte producţia pe diverse dimensiuni (capacităţi de producţie, termene de livrare,
niveluri de calitate etc.) sau pe întregul proces de producţie (de la primirea comenzii
până la livrare);
urmăreşte eficient comenzile pe parcursul fazelor de producţie – lansare (generare
ordine de producţie specifice fiecărui produs), aşteptare, terminare, anulare, suspendare

temporară.

2.1.1.5. Funcţiunea de personal

Funcţiunea de personal (sau resurse umane, cum a fost denumită în ultimii
ani) are în vedere angajarea, instruirea (pregătirea), salarizarea şi recompensarea
angajaților unei organizații. Într‐o succesiune logică, activitățile vizează selecția şi
recrutarea salariaților, evaluarea pregătirii şi competențelor acestora pentru
posturile disponibile. Pentru salariații firmei, vor fi calculate lunar drepturile băneşti
cuvenite, se vor reține şi vira la bugetul statului reținerile conform reglementărilor
în vigoare. De asemenea, este deosebit de important să se asigure un nivel optim al
pregătirii personalului, printr‐un sistem de educație continuă (cursuri ori seminarii
de instruire). Firma trebuie să aibă definit un sistem de recompense şi premii,
pentru stimularea şi cointeresarea personalului. În fine, pe baza prevederilor legale
şi a procedurilor interne, se desfăşoară activități specifice în cazul terminării
contractelor de muncă prin demisie, concediere ori pensionare.
Această funcțiune există în orice tip de firmă, indiferent de profil ori
dimensiune. Desigur, în marile companii, această funcțiune este mult mai complexă.
Este din ce în ce mai acceptat faptul că în managementul firmei resursa umană
determină succesul şi prosperitatea lui 8. Cât pot dura o bună politică de tip
comercial şi una financiară sănătoasă, dacă angajații desfăşoară în magazine, ateliere
şi hale o muncă de slabă calitate, dacă aceştia se fac că muncesc, dacă‐şi petrec
timpul de muncă într‐un mediu conflictual sau dacă sabotează afacerea? Resursa
umană este greu de stăpânit, de condus, dacă nu‐i sunt cunoscute dimensiunile care
îi afectează performanța. Managementul resurselor umane presupune existența
unei politici de personal coerente, care înseamnă mult mai mult decât angajare,
salarizare şi încheiere de contracte de muncă. Ne referim aici la un sistem de
recompense şi la instruirea continuă a personalului.

BORG Salarizare şi personal – http://www.transart.ro/borgerp/financiar/
Modulul de salarizare şi personal din ERPul firmei TRANSART este special conceput pentru
rezolvarea tuturor problemelor de calcul salarial, în conformitate cu legislaţia din România,
indiferent de tipul de activitate şi numărul de angajaţi ai firmei. Pentru o gestionare corectă
a problemelor complexe, la acest capitol, aplicaţia asigură:
calculul salariilor în acord sau regie pe baza unui model de calcul salarial care poate fi
selectat dintro listă extinsă (normă întreagă, normă fracţionară, convenţii civile,
contract management, cenzor);

8 A. Prodan, Managementul de succes. Motivaţie şi comportament, Editura Polirom, Iaşi, 1999, p. 13.

un sistem flexibil de culegere, ajustare şi evidenţă a elementelor care intră în calculul
salarial: pontaje, zile de concediu (de odihnă, medical, fără plată), sporuri şi reţineri;
evidenţa contractelor de muncă ale salariaţilor, inclusiv istoricul anexelor la aceste
contracte, care conţin decizii de modificare a cuantumului salariilor;
calculul automat al indemnizaţiilor aferente concediilor medicale (defalcarea sumelor pe
angajator, respectiv fondul de sănătate);
calculul contribuţiilor la buget şi la fondurile naţionale: de şomaj, sănătate şi asigurări
sociale (pentru angajator şi angajat);
calculul deducerii personale şi a impozitului pe venit;
o listă extinsă de rapoarte operative şi declaraţii:
– fişe fiscale pentru angajaţi;
– declaraţii: BASS – pentru Casa de Asigurări Sociale de Stat; FNUASS – centralizatorul
privind evidenţa obligaţiilor de plată ale firmei la FNUASS (Anexa 1) şi lista nominală a
asiguraţilor care au beneficiat de concedii şi indemnizaţii (Anexa 2); listele nominale cu:
asiguraţii (Anexa 2a), coasiguraţii (Anexa 2b) şi centralizatorul (Anexa 2c) pentru Casa
de Asigurări de Sănătate; declaraţia de şomaj, care se depune la AJOFM, şi Declaraţia
ITM (declaraţie fiscală privind stabilirea comisionului), care se depune la Inspectoratul
Teritorial de Muncă;
– state de plată: avans, lichidare, prime;
– rapoarte operative şi situaţii referitoare la angajaţi (sume salariaţi, contracte de muncă,
foaie de prezenţă, pontajeconcedii, sume reportate) pe bază de şabloane predefinite
extensibile, cu posibilităţi de grupare şi filtrare după un set de criterii specific (perioadă,
tip contract, loc de muncă, profesie, vechime, mod de plată). Sistemul permite definirea şi
adăugarea de noi şabloane şi rapoarte în funcţie de nevoile specifice, rapoarte care
permit adăugarea/afişarea unor atribute suplimentare – naţionalitate, cetăţenie, limbi
străine, cont bancar etc.;
generarea şi exportul notelor contabile specifice salarizării şi importul acestora în
modulul de contabilitate. Modul în care sunt generate notele contabile poate fi definit
explicit din interfaţa aplicaţiei;
facilităţile extinse de administrare, care permit ajustarea parametrilor de lucru ai
salarizării, asigură un grad ridicat de flexibilitate şi adaptare la nevoile organizaţiei şi la
modificările legislative care pot surveni pe parcursul exerciţiului financiar. De exemplu,
cei peste 100 de parametri de lucru care pot fi actualizaţi lunar sunt grupaţi în zece
categorii distincte: generale, impozitdeduceri, pensieFAAMBP, sănătate, ITM, PHN –
persoane cu handicap, şomaj – fd garantare, declaraţie şomaj, rotunjiri şi caracteristici

firmă.

La început, funcția de personal‐salarizare se limita la administrarea curentă a
personalului, ea a evoluat datorită importanței acordate factorului uman în asigurarea
succesului competițional al firmelor. Ea a dobândit o dimensiune strategică şi un rol
esențial de animare şi mobilizare a inițiativei membrilor organizației. În acest sens,
discutăm despre activităţi complexe de planificare a resurselor umane (prin analiza
posturilor de muncă, previziunea cererii şi ofertei de personal), de recrutare,
selecţionare, orientare şi dezvoltare a personalului, de evaluare a performanţelor şi
recompensare (prin salarii, stimulente, facilităţi sociale, sisteme de promovare, scheme
de carieră), de asigurare a securităţii muncii şi sănătăţii personalului, de creare a unor
relaţii de muncă stimulative pentru participarea creativă a oamenilor la realizarea
obiectivelor organizaţiei. Toate aceste activități – realizate prin contribuțiile
managerilor de pe liniile ierarhice, ale specialiştilor în resurse umane şi ale tuturor
angajaților firmei – formează conținutul noțiunii de management al resurselor umane.
Asistăm la transformări importante în domeniu, resursele umane devenind capitalul
uman al organizației.

mySAP ERP Human Capital Management (mySAP ERP HCM) – http://www.marketwatch.ro/
articol/906/Integrarea_angajatilor_cu_strategia_si_procesele_de_afaceri_ale_companiei_Solut
ia_mySAP_HR_oferita_de_catre_IBM/pagina/2
Platforma mySAP ERP HCM urmăreşte creşterea valorii celui mai important activ al unei
companii: capitalul uman. Pentru aceasta, aplicaţia permite identificarea şi alinierea
aptitudinilor, activităţilor şi beneficiilor angajaţilor cu obiectivele şi strategiile de afaceri.
De asemenea, mySAP ERP HCM oferă şi instrumentele necesare administrării, măsurării şi
răsplătirii contribuţiilor individuale sau în echipă ale angajaţilor. Prin implementarea
instrumentelor integrate din mySAP ERP HCM, compania poate să identifice cei mai buni
oameni să le dezvolte capacităţile, să le ofere trainingul optim, dar şi să alinieze eforturile
acestora cu obiectivele firmei sau săi păstreze pe cei cu rezultate de top.
Aplicaţia oferă funcţionalităţi integrate care acoperă orice aspect din activitatea unei
companii:
automatizează procesele HCM şi le integrează în operaţiunile globale;
oferă acces la informaţii de ultimă oră pentru accelerarea deciziilor legate de forţa de
muncă;
facilitează numirea oamenilor potriviţi la timpul potrivit pentru proiectele potrivite;
sprijină atât angajaţii, cât şi managerii dea lungul vieţii active;
permite angajaţilor să administreze procesele întrun mediu colaborativ.
Proiectat pentru afaceri globale, mySAP ERP HCM oferă funcţii de salarizare, îndeplineşte
cerinţele legislaţiei şi conţine cele mai bune practici din peste 50 de ţări. Poate fi integrat cu
orice sistem de gestiune a companiei şi poate fi personalizat conform oricăror cerinţe. Peste
9.000 de companii din toată lumea se bazează pe mySAP ERP HCM pentru administrarea a
mai bine de 54 de milioane de angajaţi. Cu mai mult de 175.000 de consultanţi şcolarizaţi la
cel mai înalt nivel, IBM Global Services este pregătită să asiste orice companie pentru
implementarea la timp şi în buget a soluţiilor SAP. În biroul IBM Business Consulting
Services din România activează peste 50 de consultanţi, dintre care peste 30 cu expertiza
SAP. Cunoştinţele lor se reflectă în peste 30 de proiecte SAP, pentru clienţi din cele mai
variate domenii de activitate, unele dintre acestea reprezentând referinţe importante
pentru Europa Centrală şi de Est.

Alte funcțiuni importante dintr‐o organizație sunt:
cercetaredezvoltare, care vizează crearea de noi produse şi chiar tipuri
de servicii, coordonarea activităților pe plan tehnic, omologări, asimilări de produse

noi, înregistrarea programelor de investiții şi inovații, propunerea de noi
documentații tehnice şi tehnologice;
informatică sau de IT (prelucrarea datelor sau oficiul de calcul în firmele
de la noi), care oferă servicii informatice în organizație (întreținerea aplicațiilor, a
calculatoarelor şi a celorlalte echipamente, instruirea personalului etc.).

2.1.2. Structura funcţională a unei întreprinderi

O vedere simplificată asupra organizației discută despre patru mari arii
funcționale care grupează activitățile funcțiunilor descrise anterior (vezi tabelul
2.2): contabilitatefinanciar, marketingvânzări, producţie şi resurse umane. Cele mai
multe organizații economice se bazează pe o structură funcțională, concretizată în
departamente specializate pentru fiecare arie. Aceasta este o structură ierarhică şi
are ca principal avantaj eficiența internă, datorită specializării şi controlului
centralizat.

Tabelul 2.2
Arii funcţionale şi operaţiuni/activităţi economice

Arii Contabilitate şi Marketing şi Producţie Resurse

funcţionale financiar vânzări umane
Contabilitate Marketing de Achiziția de Recrutare şi
financiară produs materii prime şi angajare
materiale
Operațiuni/ Alocarea şi Preluarea de Recepția Instruire
Activități controlul comenzi bunurilor
economice costurilor achiziționate
Planificare Service Transport şi Salarizare
financiară postvânzare logistică
Bugetare Managementul Planificarea Managementul
relațiilor cu producției carierelor
clienții
Managementul Previzionarea Producția
trezoreriei vânzărilor propriu‐zisă
Publicitate Gestiunea
stocurilor

Aşa cum vom arăta în continuare, nu doar funcțiunile, dar şi ariile funcționale
sunt interdependente, iar eficiența la nivelul organizației creşte prin integrarea
activităților din diferite arii funcționale.

2.2. Trecerea de la abordarea funcţională la orientarea
pe proces în sisteme informaţionale

De o vreme încoace, managerii şi‐au schimbat modul de abordare şi gândesc în
termeni de procese economice. În definiția de la începutul capitolului am spus că un
proces economic înseamnă o succesiune de activități care preiau una sau mai multe
intrări şi creează o ieşire care prezintă valoare pentru client. Se impune aici
precizarea că prin client ne gândim atât la tradiționalul client extern, cel care
cumpără produsul final, cât şi la diverşi clienți interni, beneficiari ai ieşirilor, altele
decât cele clasice, de genul produse ori servicii (de exemplu, un coleg dintr‐un
departament poate prelua ca intrări ieşirile din alt departament).
Abordarea din perspectiva proceselor înseamnă până la urmă abordarea din
perspectiva clientului. Dacă discutăm procesul de vânzare prezentat generic în
tabelul 2.3, observăm că acesta implică trei dintre cele patru arii funcționale.
Spunem că este o abordare din perspectiva clientului, a celui care cumpără de la
firma noastră, deoarece procesul este definit astfel încât să răspundă cât mai bine
aşteptărilor clientului. Acesta doreşte să obțină cât mai repede produsul necesar, la
un preț cât mai bun şi să aibă asistență postvânzare 24/7.

Tabelul 2.3
Procesul de vânzare: ariile funcţionale implicate

Intrare/aria funcţională
Prelucrare Ieşire
responsabilă
Comandă cumpărare/ Prelucrare date comandă şi Factură
marketing şi vânzări facturare
Factură/ contabilitate‐ Înregistrare creanță Documente financiar‐
financiar contabile specifice
Factură/ producție Scădere gestiune (stocuri) şi Produs expediat
livrare produs
Solicitare service/ marketing Preluare şi rezolvare Solicitare rezolvată
şi vânzări solicitare prin help line

În secolul XX, companiile au fost organizate şi conduse conform modelului
orientat pe funcțiuni, eforturile de creştere a eficienței şi eficacității s‐au concentrat
asupra creşterii performanțelor diferitelor funcțiuni economice. În condițiile unui
mediu economic tot mai dinamic, în care primează orientarea pe client, eficiența
vechii organizări funcționale se diminuează dramatic. Exemplul următor este grăitor
în acest sens.
Biroul de aprovizionare al unei firme de producție poate să obțină importante
reduceri de cost dacă achiziționează megacantități de materii prime (necesare la un
moment dat procesului de fabricație). Dacă analizăm această situație izolat, sigur că
identificăm economii, obținute datorită negocierii unui preț de achiziție mic. Dacă
analiza se face în contextul întregii activități, se va observa că aşa‐zisele economii
obținute prin reducerea prețului vor fi depăşite de cele necesare stocării acestora în

bune condiții. De multe ori se întâmplă ca, până la introducerea lor în procesul de
fabricație, respectivele materii prime să se altereze, să devină învechite sau să se
piardă ori fure. Dincolo de costurile presupuse, riscurile asociate depozitării
contribuie la pierderea avantajelor obținute prin cumpărarea unor volume foarte
mari. În abordarea pe procese, aprovizionarea reprezintă doar o verigă din fluxul de
activități (engl. workflow) – decizia de aprovizionare nu poate fi considerată separat,
ci este generată de o cerere din partea producției. Sincronizarea dintre funcțiuni
este dificil de realizat în absența unui sistem informatic performant, utilizat în
contextul reorganizării întreprinderii.

Procesul comandă client

Funcțiunea Funcțiunea Funcțiunea Funcțiunea Funcțiunea
„Vânzări” „Contabilitate” „Aprovizionare” „Producție” „Logistică”
Procesul comandă materiale

Figura 2.1. Exemplu de interconexiune între procese economice

Abordarea funcţională Abordarea pe procese
Focus „ce” „cum”
Structură verticală, lanț de comandă orizontală, pe fluxuri
Caracter static; decupaj‐în‐timp dinamic
Orientare pe sarcină (task) pe client
Profil utilizatori individual, specialist echipă, generalist
Acoperire local global, de ansamblu
Figura 2.2. Abordarea funcţională vs. abordarea pe procese
Partajarea efectivă şi eficientă a datelor în cadrul şi între funcționalități
conduce la procese economice eficiente. Sistemele informatice care sunt astfel
proiectate încât să permită partajarea datelor sunt sistemele integrate.

2.3. Importanţa workflowului

Afirmația „Prea multă informație ucide informația” sintetizează într‐o simplă
propoziție importanța tehnologiilor workflow. Tehnologia workflow realizează
automatizarea unui proces economic (tranzacţii, grup de operaţiuni), integral sau
parţial, în timpul căruia documentele, informaţiile sau sarcinile circulă de la un
participant la altul, în conformitate cu un set de reguli prestabilite9. Dintre toate
tehnologiile colaborative pentru afaceri, workflow‐ul se detaşează ca fiind cel mai
puternic mediu de automatizare a proceselor de lucru. Dacă, de regulă, sistemul
informațional este considerat a fi sistemul nervos al organizației, atunci tot în
aceeaşi măsură putem considera tehnologia workflow ca fiind cel mai consistent
suport al informatizării acestuia. Nu întâmplător, în literatura de specialitate,
workflow se detaşează ca tehnologie destinată mediului informațional prin imaginea
sa de coloană vertebrală a sistemului informațional.
Sfârşitul anilor ’80 a consacrat din punct de vedere tehnologic aceste aplicații
pentru întreprindere. Este perioada în care marile companii au început să se
restructureze organizațional, să regândească procesele interne pentru a creşte
productivitatea în ansamblu, pentru a transforma compania astfel încât să devină
mai profitabilă şi mai competitivă. Necesitatea creşterii eficienței proceselor de
afaceri a necesitat schimbarea mentalităților şi a culturii organizaționale. Printre
promotori s‐au numărat şi celebrii Hammer şi Champy, care au enunțat principiile
Business Process Reengineering (BPR). Delimitările teoretice, împreună cu suportul
oferit de noile tehnologii informaționale, în special al tehnologiilor workflow, pot
crea premisele succesului. Mutația esențială constă în înlocuirea aplicațiilor
orientate funcțional cu aplicații orientate pe procese.
În prezent, produsele workflow asigură infrastructura pentru automatizarea şi
ameliorarea fluxurilor de lucru şi încadrarea sarcinilor în cadrul proceselor
desfăşurate la nivelul organizației. Informal, sunt circumscrise toate specificațiile
necesare desfăşurării unui set complet de activități care presupun diverse niveluri
de coordonare şi reflectă procesele de afaceri din interiorul unei organizații.
Workflow desemnează un ansamblu de hărţi organizaţionale de sarcini şi
activităţi desfăşurate de un număr de persoane sau de diverse entităţi.
Noțiunea de workflow management este astfel sinonimă cu administrarea şi
automatizarea proceselor de afaceri. Datorită acestei funcționalități, tehnologia a
fost preluată în aplicațiile integrate de gestiune a firmelor, mult discutatele sisteme
ERP devenind unele dintre piesele grele ale acestora.

9 Definiția Workflow Management Coalition (WfMC), citată în D. Fotache, Groupware. Metode, tehnici şi
tehnologii pentru grupuri de lucru, Editura Polirom, Iaşi, 2002, pp. 153‐174.

E‐business a deschis multiple oportunități de dezvoltare tehnologiilor de

întreprindere. Toate acestea au căpătat un caracter extern, vectorul principal fiind
rețelele de calculatoare. Globalizarea afacerilor a dus tehnologiile workflow în
această zonă şi se observă integrarea lor în toate tehnologiile importante. Două
exemple sunt cel puțin edificatoare: Supply Chain Management şi Customer
Relationship Management. Conştiente de avantaje (tabelul 2.4), în prezent
majoritatea companiilor se orientează spre aceste tehnologii.

Tabelul 2.4
Avantajele utilizării tehnologiilor workflow

Avantaje tangibile Avantaje intangibile
• reducerea costurilor de operare a • ameliorarea serviciilor: timp de lucru
tranzacțiilor şi acumularea experienței redus, erori puține, informații on‐line cu
privind automatizarea proceselor privire la procesele în curs de desfăşurare şi
• creşterea productivității prin răspuns în timp real la solicitările clienților
automatizarea sarcinilor repetitive, astfel • condiții mai bune pentru angajați,
încât procesele sunt executate 24 de ore personalul este degrevat de sarcinile de
pe zi (posibilitate extrem de importantă rutină, plictisitoare
pentru organizații cu operațiuni globale şi • management eficient al schimbărilor
prezență pe web) • îmbunătățirea comunicării interne,
• timpi scurți de procesare datorită datorată publicării informațiilor despre
execuției automate a proceselor şi a sarcinile de serviciu, şi a celei
posibilității de evitare a pierderilor interorganizaționale
datorate mecanismelor de avertizare • sprijinirea proceselor decizionale datorată
• elimină orice situație de unei performante baze informaționale
indisponibilitate a unui document • ameliorarea proceselor de planificare
• reducerea şi chiar eliminarea stocurilor • posibilități multiple de adoptare a noilor
oportunități tehnologice

La modul cel mai simplu, workflow este sinonim cu informatizarea proceselor
pe care le desfăşurăm zilnic la locul de muncă. Aplicația automatizează toate
acțiunile, activitățile sau sarcinile presupuse de un proces. Nu necesită structurare,
iar principala sa funcție constă în sprijinirea execuției proiectelor de o echipă.
Aplicaţiile workflow responsabilizează indivizii şi grupurile de lucru care îşi
desfăşoară activitatea în diverse medii (structurate sau nestructurate) şi modelează cu
ajutorul calculatoarelor toate procesele reale desfăşurate în diverse sisteme
informatice (figura 2.3).
Modelul procesului descrie structura organizației din „lumea reală” (sunt
avute în vedere procesele întreprinderii, cultura colectivă şi tehnologiile existente).
Fiecare proces este detaliat şi transpus în modele workflow cu ajutorul instanțelor.
Rezultatul constituie baza pe care va fi implementat produsul workflow. Modelarea
este realizată în cadrul etapei de concepție.
Potrivit principiului GIGO (GarbageInGarbageOut), dacă datele care intră în
sistem nu sunt corespunzătoare, şi rezultatul prelucrării lor va fi, de asemenea, prost.

PROCESE REALE CALCULATOR
Modelul procesului Modelul workflow
Instanţă Instanţă
Proces Workflow

Sursa: Leymann, F., Roller, D., Production workflow. Concepts and techniques, 2000.
Figura 2.3. Procese şi workflow

Structural, elementele de bază (figura 2.4) ale unui sistem workflow sunt:
operaţia. Un workflow este descompus în operații elementare. Operația
reflectă prelucrarea suferită de informație la intrarea în sistem şi valoarea pe care o
are adăugată la ieşire;
actorul. Este persoana responsabilă de execuția operației. Uneori, o sarcină
poate fi încredințată mai multor utilizatori, dar şi un singur utilizator poate realiza
mai multe sarcini;

Actorul
Resursa
Operaţia Reguli Circuitul Operaţia
Informaţia

Sursa: Courbon, J.‐C., Tajan, S., Groupware et intranet, Dunod, Paris, 1999, p. 97.
Figura 2.4. Elemente de bază ale unui sistem workflow

reguli. Operația se desfăşoară în condiții optime dacă este definit un set de
reguli care vor fi respectate în procesul de prelucrare şi pe parcursul operațiilor
următoare. Spre deosebire de procesele manuale, unde indivizii aplică singuri
procedurile impuse, în cadrul sistemului workflow, regulile sunt programate şi
declanşarea lor are loc automat;
circuitul. Un motor de transport care face legătura între activitățile
urmărite. Reduce la minimum timpii de tranzit dintre operațiuni;

informaţia. Este un alt factor‐cheie workflow. Informațiile implicate sunt

definite în prealabil.
Descrierea elementelor de bază descoperă o sumă întreagă de probleme
tehnice, legate în special de implementarea regulilor, a motorului de transport şi a
managementului informațiilor. Traseul informațional în cadrul unui sistem
workflow poate fi organizat secvențial, paralel sau condițional (figura 2.5).

SECVENŢIAL
PARALEL
Da
CONDIŢIONAL
Nu
Da
Nu

Sursa: Courbon, J‐C., Tajan, S., Groupware et intranet, Dunod, Paris, 1999, p. 98.
Figura 2.5. Modele de circuit din cadrul workflow

Traseul secvențial este cel mai simplu, prin cel paralel, conținutul
documentelor poate fi afectat, iar cel condițional este cel mai complex (presupune
respectarea regulilor stabilite la definirea cerințelor sistemului workflow).
Piața oferă numeroase produse care susțin că încorporează caracteristici
workflow. În opinia noastră, un produs poate fi considerat soluție workflow dacă are
următoarele caracteristici:
oferă posibilități de proiectare a formularelor electronice (pentru fiecare
sarcină descrisă în diagramă);
deține instrumente de proiectare a diagramelor workflow;
pot să comunice cu alte aplicații externe;
cuplează formularele electronice la bazele de date ale întreprinderii;
colectează la nivelul fiecărei activități desfăşurate informații cu privire la
executarea sarcinilor;
la nivelul fiecărei activități, informațiile care descriu intrări pot fi
descompuse pe sarcini componente, la nivel de detaliu;
în diagrama workflow pot fi incluse şi traseele condiționale;
există un monitor pentru urmărirea desfăşurării proceselor workflow;
există posibilități de evaluare a procesului workflow pe ansamblul lui;
permite simulări şi testări de comportamente;
sprijină un grup mare de utilizatori;
suportă multiple platforme.
Exemplul 1: Publicarea unui document (figura 2.6)
Avem în vedere unele dintre cele mai des întâlnite sarcini din cadrul birourilor (de orice fel), şi
anume crearea, manipularea şi diseminarea documentelor. Evoluţia tehnologiilor biroului
modern a apropiat publicul de autor, iar publicarea documentelor sa dovedit a fi extrem de
eficientă prin intermediul world wide webului. Procesarea unui document presupune
desfăşurarea unui set de sarcini către mai multe persoane. Procesul de publicare se află
situat pe un nivel superior şi are în vedere sarcinile de creare, revizuire şi formatare, fiecare
dintre acestea fiind repartizate unei persoane anume care este autorul, redactorul şi
editorul. Pe tot parcursul procesului mai intervin şi alte persoane (reprezentăm cu linii
punctate posibilitatea de acces a acestora) şi diverse programe specializate (procesoare de
texte sau produse desktop publishing). Săgeţile şi liniile continue reprezintă dependenţele
dintre activităţi. Cercul de după activitatea de creare reflectă decizia potrivit căreia
procesul va fi continuat prin opţiune între revizuirea (corecţia) şi formatarea lui. Decizia
este dependentă de activitatea de creare a documentului.
Exemplul 2: Un proces de angajare (figura 2.7)
Obiectivul procesului de angajare este recrutarea unei persoane care corespunde criteriilor
unui post vacant. Sunt implicate persoanele (sau grupurile) următoare: personalul – în
momentul angajării unui candidat, serviciul personal care trebuie să verifice contractul de
muncă, istoricul candidatului, fixează data plăţii etc.; şeful de recrutare care coordonează
membrii echipei sale, care sau întâlnit cu solicitantul postului, verifică referinţele, salariul
de angajare etc.

editor
Publicarea unui document
formatare
autor redactor
creare revizuire
documente software

Sursa: Prelucrare după Borghoff, U.M., Schlichter, J.H., ComputerSupported Cooperative Work, Springer,
Berlin, 2000, p. 329.
Figura 2.6. Exemplul 1 – workflow

FAX
START Personal
Filtrează CV-urile
Personal Intervievator
Deschiderea şi completarea Fixează întâlnirea şi plasează

dosarului cu descrierea postului, fişa de evaluare în dosar
fişa de evaluare, calendarul activităţilor
Şef cu recrutarea Intervievator
Evaluează dosarul, consultă Lansează procesul de angajare

fişele de evaluare, formulează şi candidatul este reţinut.
recomandări Clasează toate fişele interviurilor
Sursa: Prelucrare după Khoshafian, S., Buckiewicz, M., Groupware & workflow, InterEditions, Paris,
1998, p. 229.
Figura 2.7. Exemplul 2 – workflow

Toate procesele afacerii sunt transpuse în circuite workflow şi reprezentate
tridimensional. Cele trei dimensiuni pot fi reprezentate grafic sub forma unui cub
(figura 2.8).

Procese logice
Organizaţia
Infrastructură IT

Figura 2.8. Reprezentarea tridimensională workflow
Prima dimensiune a cubului o reprezintă procesele logice. Acestea descriu

condițiile în care activitățile pot fi executate, realizează descompunerea acestora pe
secvențe şi le scot în evidență pe cele care trebuie să suporte modificări. Fiecare
program este corespunzător unui proces, având în vedere legăturile cu alte procese,
subprocesele componente şi relația cu alte companii. Săgețile arată sensul trecerii
controlului de la o activitate la alta, control care poate fi secvențial sau paralel. Dacă
este secvențial, activitățile sunt realizate prin procese care se desfăşoară unul după
altul; dacă este paralel, două sau mai multe activități pot fi realizate în acelaşi timp,
reducându‐se, pe ansamblu, timpul.
A doua dimensiune a cubului este reprezentată de dimensiunea organizaţio
nală, care descrie, din punct de vedere organizațional, structura companiei, deta‐
liind departamentele acesteia, rolurile şi salariații implicați. Informația rezultantă
arată cu claritate cine este responsabil de realizarea unei activități şi la ce nivel de
performanță trebuie să fie acesta. O interogare în sistem poate determina care sunt
persoanele potrivite pentru o sarcină neproductivă. Workflow management system
scoate în evidență deficiențele şi indică grupul care poate remedia situația.
A treia dimensiune a cubului este generată de infrastructura tehnologiilor
informaţionale implicată în desfăşurarea proceselor logice, la nivel organizațional,
prin care se delimitează resursele IT necesare desfăşurării fiecărei activități, la nivel
de execuție.
În concluzie, tripletul real al proceselor de afaceri: activitateutilizatorresurse IT
presupune aceeaşi reprezentare tridimensională şi în spațiul workflow prin
modelarea: cecinecum.
Alegerea unui produs workflow trebuie să fie precedată de analiza profundă a
naturii lucrărilor desfăşurate şi de nivelul de automatizare posibil sau necesar. În
acest scop se întocmesc diagrame de flux, care descriu toate resursele implicate în
proces: echipamente periferice, personal, sarcini de lucru, planificări etc.

SocrateOpen – http://www.socrateopen.ro/meniu/produs/platforma/workflow.html (accesat
la data de 30/06/2010)
Fluxul activităţilor (workflow) este de obicei definit ca „etape care implică oameni".
Administrarea proceselor de afaceri este de obicei definită ca „fluxul şi sistemul
activităţilor”. SocrateOpen sprijină în totalitate administrarea proceselor de afaceri şi se
bazează pe Workflow Management Coalition pentru managementul fluxurilor şi
standardele OMG. În continuare vom folosi termenul flux de activităţi, care include şi
administrarea proceselor de afaceri.
Spre deosebire de aplicaţiile ERP/CRM cunoscute, SocrateOpen implementează fluxurile întro
abordare de jos în sus. Fluxul activităţilor este motorul managementului tranzacţiilor în
sistem. Aceasta înseamnă că toate procesele SocrateOpen se bazează pe această
caracteristică a programului, ceea ce le face uşor de extins şi de modificat. Fluxul
activităţilor fiind un proces complet integrat, fluxurile sistem sunt mai uşor de administrat şi

oferă o funcţionalitate mai bună faţă de funcţionalităţile adăugate unor sisteme ERP/CRM
tradiţionale.
SocrateOpen oferă trei tipuri de fluxuri de activităţi (figura 2.9):
• flux general de activităţi. Oferă ghidare şi instrucţiuni pas cu pas pentru realizarea unei
sarcini. Exemple: instrucţiunile de instalare sau procedurile de sfârşit de lună utilizatorul
le accesează din meniu;
• fluxul de procesare a documentelor. Lansat în momentul procesării oricărui document.
Acest flux poate fi extins întrun sistem de gestiune/aprobare a documentelor. Exemplu:
aprobarea specială pentru comenzile care depăşesc o anumită valoare, aprobare plăţi etc.;
• fluxul documentelor de evaluare. Fluxul de lucru este lansat automat în momentul
îndeplinirii de o entitate a unei condiţii cerute de utilizator. Exemplu: începerea aprobării
procedurii de credit pentru un terţ.

e‐mail
Orice
proces
Orice
raport
Creare Procesare
document document
Workflow
engine

Sursa: http://www.socrateopen.ro/meniu/produs/platforma/workflow.html
Figura 2.9. Fluxuri de activităţi în SocrateOpen

Produsele workflow asistă utilizatorii în execuția sarcinilor de lucru şi oferă
imagini de ansamblu asupra proceselor desfăşurate. Se obțin avantaje dacă sunt
respectate următoarele recomandări:
înainte de a concepe diagramele de flux, trebuie conturat un model
informațional care delimitează problema luată în calcul. Modelul informațional
descrie structural diferitele obiecte implicate în procedurile, procesele şi proiectele
întreprinderii, fiind util pentru delimitarea atributelor formularelor, a structurii
documentelor şi a grupurilor de obiecte (dosare, arhive etc.);
crearea şi realizarea unui model al departamentelor existente, al rolurilor
şi al utilizatorilor sistemului workflow din cadrul acestora. Această etapă poate fi
înglobată în modelul informațional (în acest sens, reprezentarea lui este extinsă cu
toate documentele, formularele şi grupurile implicate). Este foarte importantă
identificarea participanților la workflow, deoarece sarcinile, aprobările interne şi

nivelurile de securitate sunt stabilite pe tipuri de utilizatori. În consecință, în cazul
modelelor pe departamente, este necesară identificarea utilizatorilor, a atribuțiilor
şi a rolurilor acestora;
analiza circuitului real, simularea acestuia şi desenarea schemei sale. Etapa
presupune recurgerea la analiza orientată pe obiect şi la instrumentele de proiectare
pentru identificarea relațiilor dinamice care au loc între obiecte. Analiza orientată pe
obiect examinează cerințele în funcție de obiectele sau clasele de obiecte existente.
În final, furnizează, schematic şi detaliat, necesarul real al implementării soluției
(prin diagrame de clase, de obiecte, procese şi fluxuri informaționale etc.);
odată depăşită faza de concepție, etapele următoare constau în evaluarea
opțiunilor workflow. După această etapă nu mai rămâne decât să se aleagă efectiv
soluția cea mai potrivită.
Aşa cum reiese din prezentările anterioare, orice sistem workflow este
orientat pe proces. Un sistem workflow defineşte, creează şi supraveghează execuția
fluxurilor de lucru prin intermediul unui software specializat. Acesta rulează pe unul
sau mai multe motoare workflow, poate să interpreteze definiția procesului, să
interacționeze cu participanții workflow şi să gestioneze schimbările intervenite, să
înştiințeze utilizatorii de noile sarcini care le vor fi atribuite şi, acolo unde este
necesar, invocă folosirea instrumentelor IT şi a aplicațiilor.
Pentru configurarea procesului, sistemul workflow foloseşte un modul de
editare grafică prin care sunt definite sarcinile, utilizatorii, documentele care vor fi
accesate, destinația şi modul lor de utilizare şi timpul necesar de desfăşurare a
fiecărei sarcini.
Definiția procesului constă în identificarea activităților componente şi a
relațiilor dintre ele. Activitatea este asociată unui pas logic din cadrul unui proces şi
poate fi manuală sau automatizată. Chiar dacă sunt definite toate, un sistem
workflow execută numai activitățile automatizate. O activitate poate fi alcătuită din
una sau mai multe sarcini care sunt atribuite unuia sau mai multor participanți
workflow. Sarcinile pot fi executate în serie sau în paralel. La nivelul serverului,
motorul workflow este cel care rulează execuția procesului şi declanşează
instanțierea procesului. Instanța de proces se referă la o singură rulare a procesului,
deci un proces poate avea mai multe instanțe pentru că poate fi rulat de mai multe
ori. În momentul declanşării unei instanțe, motorul workflow citeşte definiția
procesului şi declanşează prima activitate. După finalizarea ei, motorul apelează din
nou definiția, pentru a decide ce trebuie să facă în continuare.
Organizarea eficientă a unui sistem workflow depinde de combinarea
următoarelor trei elemente‐cheie:
procesul, care, aşa cum am precizat, conține una sau mai multe activități,
pentru fiecare activitate fiind precizate fluxul de date şi aplicațiile aferente;
organizaţia – este definită prin rolurile membrilor pe niveluri de
autorizare;
infrastructura – resurse IT.

Pornind de la clasificările existente în literatura de specialitate, pot fi realizate
mai multe reprezentări ale taxonomiei aplicațiilor workflow. Cele mai frecvente
clasificări au în vedere structura, tipul de modelare pe care îl suportă afacerea, tipul
de circuit informațional invocat de persoanele implicate (formal sau informal), ce
rezultate sunt aşteptate din partea tehnologiei workflow şi în ce domeniu este
aplicat (industrial, administrativ, service etc.).
Am optat pentru o schemă (figura 2.10) realizată de GIGA Information Group,
care clasifică aplicațiile workflow în funcție de valoarea afacerii, nivelul ei de
automatizare şi de frecvența cu care se realizează aceasta.
Nivelul de automatizare
automatizare completă
ţintă (focus)
orientare resurse umane
Ad hoc Administrativ Frecvenţa
Valoarea afacerii Colaborativ Producţie

Figura 2.10. Clasificarea aplicaţiilor workflow în funcţie de valoarea afacerii, frecvenţa
şi nivelul de automatizare a proceselor

Valoarea afacerii defineşte importanța workflow‐ului în activitatea companiei,
procesele cu valoare ridicată constituind nucleul firmei (figura 2.11). Prin modelare
se urmăreşte eliminarea necunoscutelor organizaționale.

Valoarea
afacerii
înalt
Colaborativ Producţie
Tehnic Cereri aprobate

documentare Credite aprobate
creare Contabilitate
Imaginea firmei
Ad hoc Administrativ
Analize-Întâlniri-Aprobări Rapoarte cheltuieli

Certificări circuite de transport
informaţionale Situaţia impozitelor şi taxelor
redus
Frecvenţă
redus înalt

Figura 2.11. Clasificarea aplicaţiilor workflow în funcţie de valoarea afacerii
şi frecvenţa ei

Cele mai complexe aplicații sunt workflow‐urile de producţie şi cele ad hoc.
Între aceste două soluții sunt încadrate cele semistructurate (workflow adminis
trativ), care acoperă procesele flexibile (tabelul 2.5).

Tabelul 2.5
Comparaţie între tipuri diferite de workflow

workflow de workflow
workflow ad hoc
producţie semistructurat
proces nivel înalt de parțial structurat parțial structurat
structurare (au loc schimbări
dinamice)
tip de activitate descrisă în avans parțial descrisă în nu este descrisă în
avans avans
relaţia dintre este cunoscută parțial cunoscută necunoscută
activităţi
dependenţa dintre poate fi planificată parțial planificată planificare
activităţi în avans inexistentă
atribuirea stabilită din start parțial prestabilită determinată
responsabilităţilor dinamic
Sursa: Borghoff, U.M., Schlichter, J.H., ComputerSupported Cooperative Work, Springer, Berlin, 2000, p.
336.

Workflow‐ul de producție este cea mai complexă formă şi se caracterizează
prin următoarele:
este domeniul esențial al BPR (Business Process Reengineering);
permite atingerea celor mai înalte nivelurile de calitate şi precizie, prin
executarea unor sarcini repetitive, de obicei, în regim non‐stop;
administrează procese complexe de mare amplitudine;
este integrat în aplicații de mare anvergură de tip ERP, SCM, CRM;
urmând evoluția tehnologiilor actuale, capătă dimensiuni din ce în ce mai
inteligente, fiind inclus în aplicații de tip Business Analytics;
se comportă ca un motor de reguli şi acoperă (datorită „inteligenței” lui)
aproape toate aspectele informale.
De exemplu, în cazul Senior ERP, integrarea componentei de workflow în ERP
(figura 2.12) permite redefinirea în orice moment a proceselor de afaceri, în
condițiile respectării stricte a fluxurilor nou‐create. Beneficiul clientului se traduce
prin eficiența crescută a proceselor de afaceri pe ansamblul întregii companii şi
implicit în economii de timp şi bani.

Sursa: Site‐ul firmei, http://www.seniorerp.ro/, accesat la data de 30/06/2010.
Figura 2.12. Integrarea componentei de workflow în Senior ERP

La nivel operațional, integrarea workflow aduce valoare adăugată soluțiilor
SeniorERP prin:
creşterea eficienţei operaţionale. Un sistem complex, de tip ERP, devine
mai uşor de asimilat şi de operat prin generarea unui flux intuitiv de lucru.
Abstractizează situațiile concrete de lucru într‐un flux logic, permite o mai bună
înțelegere a modului de lucru şi implică creşterea eficienței de lucru;
configurări mai simplu de realizat prin proiectări rapide de fluxuri de
lucru şi modificarea imediată a unui flux, conform cu nevoile procesului;
lucru integrat. La nivel intuitiv, reprezentarea proceselor în cadrul
sistemului implică respectarea şi însuşirea naturală a workflow‐ului. Elaborarea
fluxului de procese presupune posibilitatea de integrare cu alte sisteme pentru a
asigura funcționalități suplimentare, care să acopere toate cerințele unui proces de
afaceri.

Sursa: Site‐ul firmei, http://www.seniorerp.ro/
Figura 2.13. Workflow în SeniorERP

În sinteză, prin integrarea Windows Workflow Foundation, clientul final Senior
ERP are flexibilitate decizională:
în momentul implementării, existența unui workflow presupune creşterea
compatibilității între ERP şi aria de afaceri/fluxul de activități/organigrama
clientului, perioada de acomodare a utilizatorilor cu noul sistem se reduce;
presupune reducerea costurilor prin exploatarea funcționalităților dispo‐
nibile ERP;
suport decizional puternic pentru administrarea şi controlul performanțelor
proceselor de management;
identificarea rapidă a nodurilor şi punctelor critice din procese şi alocarea
de noi resurse după necesități.

Aşa cum workflow‐ul de producție poate fi integrat în alte aplicații, este
posibilă şi descompunerea lui în două segmente:
soluţii workflow autonome (independente), funcționale în mod
independent, fără soft adițional, cu excepția sistemelor de gestionare a bazelor de
date şi a celor de mesagerie electronică. Au interfață utilizator individuală şi
comunică, în vederea accesului la date, cu alte aplicații; acoperă o arie largă de
aplicații;
soluţii workflow integrate, încapsulate în alte aplicații de mai mare
anvergură: ERP, SCM sau CRM (observabile în exemplul precedent). Funcționalitatea
sistemului workflow integrat este exploatată la nivelul unui program adițional.
Componentele workflow execută controlul strict al funcțiilor aplicației, rezolvă
cozile de aşteptare şi sprijină procesarea excepțiilor.

Charisma Workflow – http://www.charisma.ro/Workflow/ (accesat la data de 30/06/2010)
Charisma Workflow permite organizaţiilor de orice dimensiune să construiască procese
complexe în mod rapid, fie prin accesul unei interfeţe de browser web, fie direct în sistemul
client al utilizatorului de backoffice. Totodată, soluţia permite definirea şi automatizarea
procesele de business, revizuirea fluxurilor de activităţi şi automatizarea activităţilor legate
de modulele Charisma ERP 2010.
Funcţionalităţi Charisma Workflow:
realizează fluxuri noi doar prin configurare, în mod vizual, fiind eliminat efortul
dezvoltărilor suplimentare şi serveşte unui spectru larg de nevoi de business;
gestionează complet toate elementele incluse în procesul de configurare a procesului de
lucru – actori, grupuri de actori, entităţi (documente şi taskuri), intrări şi ieşiri, metode
de interacţiune şi control etc.;
stabileşte şi administrează eficient metodele de evitare a blocajelor, incluzând delegarea
şi tratarea erorilor şi asigurând continuitatea şi buna funcţionare a sistemului;
defineşte workflowuri independente specifice pe fiecare tip de activitate în cadrul
organizaţiei; creează fluxuri de lucru în ore şi în zile;
gestionează şi urmăreşte evoluţia listelor de todo pe utilizatori (actori) sau grupuri de
utilizatori; include funcţionalitatea aprobării multiuser pentru diferite taskuri ale
fluxului;
asigură suportul decizional prin implementarea etapelor de execuţie, condiţionărilor şi a
restricţiilor de timp alocate execuţiei;
include managementul taskurilor cu ajutorul cărora utilizatorii (actorii)
interacţionează cu fluxul la un moment dat, incluzând responsabilul, fluxul generator,
documentele ataşate, acţiunile şi entităţile afectate, prioritate, status (standby, working,
finished, cancelled); urmărirea acţiunilor desfăşurate de utilizatori este gestionată cu
ajutorul checklisturilor;
notifică automat fiecare actor din cadrul fluxului în legătură cu paşii neexecutaţi sau în
planul apropiat;
automatizează procesele de business şi activităţile uzuale legate de aplicaţii;
oferă o imagine actualizată, în timp real, referitoare la activităţile din cadrul fluxului de
lucru, precum şi planul de execuţie;
asigură managementul userilor şi mecanismului de securitate; include şi partea de
delegare şi transferul responsabilităţilor şi al drepturilor utilizatorilorsursă către
utilizatoruldestinaţie;
generează o raportare detaliată la nivel de companie;
măsoară performanţa unui flux sau a unei activităţi specifice cu ajutorul unor indicatori
extensibili, folosiţi în diverse statistici şi rapoarte:
– numărul de instanţe pe perioadă (ex.: luna) a unui flux;
– durata minimă, medie, maximă a rulării complete a fluxului;
– link dintre flux şi task, pentru indicatorii: durata minimă, medie, maximă a rulării,

număr de taskuri per user pe perioadă (ex.: luna) etc.

2.4. Modelare şi fluxuri de procese

Aşa cum s‐a precizat deja în debutul acestui capitol, un proces de afaceri
constă dintr‐un set de activități coordonate într‐un mediu organizațional cu suportul
tehnologiilor informaționale. Activitățile presupun atingerea obiectivelor de afaceri.
Fiecare proces poate fi configurat pentru o singură organizație şi poate interacționa
cu procese de afaceri care sunt generate de interacțiunea cu alte organizații.
Managementul proceselor de afaceri include concepte, metode şi tehnici‐suport
pentru proiectarea, administrarea, configurarea şi analiza proceselor de afaceri. La
baza managementului proceselor de afaceri stă reprezentarea explicită a proceselor
cu activitățile specifice şi validarea restricțiilor dintre ele. Odată ce procesul este
definit, poate deveni subiectul analizei, îmbunătățirii şi configurării. Ciclul de viață
(figura 2.14) al unui proces presupune descrierea fazelor de dezvoltare şi a relațiilor
dintre acestea într‐o structură ciclică ce prezintă şi dependențele logice.
Responsabilitatea asupra proceselor de afaceri este purtată de mai mulți
specialişti (economişti, ingineri) care au cunoştințe, experiențe diferite şi practică
diverse tipuri de expertiză.
Modelarea proceselor are loc în urma etapei de analiză a sistemului
informațional. Principalele elemente10 supuse analizei în timpul studierii sistemului
existent sunt: informaţiile de ieşire obţinute din actualul sistem; datele de intrare în
sistem; modul cum sunt stocate, memorate şi păstrate datele în sistem şi procesele de
prelucrare la care sunt supuse datele.

10 D. Oprea, G. Meşniță, F. Dumitriu, Analiza sistemelor informaţionale, Editura Universității „Alexandru
Ioan Cuza”, Iaşi, 2005, p. 332.

Evaluare
Exploatarea proceselor
Monitorizarea activităților
de afaceri

Design
Identificarea şi
modelarea proceselor de
afaceri
Montare
Manageri
Operațiuni Analiză
şi acționari
Monitorizare Validare
Simulare
Mentenanță
Verificare

Configurare
Selecția sistemului
Implementare
Testare şi dezvoltare

Sursa: Weske, M., Business Process Management. Concepts, languages, architectures, Springer Verlag,
Berlin, Heidelberg, 2007.
Figura 2.14. Ciclul de viaţă al proceselor

Un rol important în analiza sistemului îl are analiza proceselor de prelucrare,
care se bazează pe studierea evenimentelor care au loc într‐o anumită perioadă de
timp. Pentru modelarea proceselor, este necesară descrierea detaliată a fiecărei etape
din proces prin completarea de formulare de actorii implicaţi (tabelul 2.6). Astfel, în
faza de analiză, modelarea logicii proceselor, ca şi diagramele, trebuie să fie realizate
cât mai detaliat şi mai complet posibil.
Modelele care se construiesc au rolul de a asigura comunicarea eficientă între
cei care participă la implementarea sistemului sau sunt afectați de el. Procesul de
modelare poate fi considerat ca un proces de învăţare, pentru că, pe măsura creării
modelului, echipa de analiză învaţă tot mai mult despre sistemul informaţional,
modelele fiind revizuite împreună cu utilizatorii pentru a le verifica, dacă este cazul
corecta şi completa.
Platformele integrate din categoria ERP au un anumit nivel general de
modelare a proceselor, a evenimentelor repetitive care nu se înscriu în categoria
evenimentelor specifice ramurii în care îşi desfăşoară activitatea organizația
respectivă.

Tabelul 2.6
Exemplu de formular de descriere a proceselor

Numele procesului: proces Managerul responsabil de proces:
dezvoltare producţie ing. Năstase Matei
De la: Cerințe Tip: Dezvoltare proiect
La: Finalizare
Intrări proces: Procese furnizor:
Documente inventariere cerințe Procese de planificare a producției
Plan proiect, plan de buget, prototipuri Procese de inovare
Procese rezultate: Procese clienţi:
Testarea completă a produsului şi Managementul comenzilor
documentarea completă Procese de service postvânzare
Sursa: Schmerzer, H., Sesselmann, W., Practical Use of Business Process Management, Hanser, citați în
Weske, M., Business Process Management. Concepts, languages, architectures, Springer Verlag, Berlin,
Heidelberg, 2007, p. 46.

Iată pe scurt fluxuri de procese, descrierea proceselor pe arie de afaceri şi
detalierea operațiunilor de afaceri pe exemplul SAP. Pentru gestiunea vânzărilor în
cadrul unei firme, avem în vedere ca arie de afaceri: procese de vânzări, detaliem
procesele de vânzări şi operațiunile de afaceri aferente (tabelul 2.7).

Tabelul 2.7
Exemplu de fluxuri de procese: arie de afaceriprocese de vânzări

Arie de
Proces de afaceri Operaţiuni de afaceri
afaceri
Procese Cerere de ofertă şi Prelucrare cerere de ofertă
de vânzări oferta Prelucrare ofertă
Poziții stoc

Preluare comenzi Prelucrare comanda de vânzare standard
client Comanda de vânzare cu client fictiv
Prelucrare comandă de vânzare în numerar
Prelucrare comanda urgentă
Comenzi externe client‐livrare directă
Comanda de vânzări şi facturare pentru poziție
negestionată în stoc

Livrare client Prelucrare livrare

Factură client Prelucrare factură

Prelucrare reclamații client
Reclamații client Prelucrare comanda de retur client
Prelucrare notă credit şi debit

Introducere plată
Gestionare credit Prelucrare blocare livrare client

Întreținere registru client
Întreținere date de Întreținere date determinare preț automat
vânzare
Sursa: Documentație SAP.

Documentația descriptivă a unei arii de afaceri este o modalitate de

comunicare între toți cei implicați în desfăşurarea operațiunilor. Modelarea recurge
în plus la o combinație între formele descriptive şi grafice pentru redarea proceselor
şi operațiunilor într‐o manieră uşor de înțeles (figura 2.15). În figura 2.16
prezentăm un exemplu de diagramă mult mai detaliată pentru gestiunea cererilor de
ofertă.

VÂNZĂRI ŞI DISTRIBUȚIE

1) înregistrări 2). Înregistrări 3). Definire clasificare
date principale de condiţie şi lot/ strategie de căutare
alocări lot

Înregistrare de bază Condiţie propunere Definire
client poziţie după caracteristici de
Date generale departament de vânzări lot
Date cod companie Definire poziţii de
material şi cantităţi şi
Alocare la clasă
Date arie de vânzări de loturi
alocare implicită la
registru clienţi

Definire clasă de
Condiţie rabat în natură
Înregistrare de
după departament vânzări, loturi
Alocare la registru
bază
client şi material
Definire poziţii material şi materiale imagine
Date generale,
Date cod
cantităţi aferente client clasificatoare
după schemă de client
companie, Date
alocată în registrul de
arie de vânzări
clienţi
Definire strategie de
căutare lot după
Condiţie determinare automată client şi/sau material
Strategie implicită de
preţ după material şi client
Definire înregistrări de condiţie căutare lot definită
pt. soluţie după dată
pt. terţ de bază,
sconturi/majorări, transport şi expirare material
taxe. Schemă determinare preţ
automată alocată în registru
clienţi

Creare comandă Creare livrare de ieşire din Ridicare Date
de vânzări după comandă de vânzări şi livrare operative
client Livrare creată pt. punct de ieşire vânzări şi
Definire poziţii expediţie determinat din registru de bunuri şi distribuţie
de material şi materiale şi de clienţi factură
cantităţi

Figura 2.15. Diagrama „Vânzări şi distribuţie”

Chiar dacă există la ora actuală foarte mulți implementatori şi dezvoltatori de
produse integrate, procesele au o oarecare similaritate, în sensul că schema
anterioară este implementată şi de alte soluții ERP.
VÂNZĂRI ŞI DISTRIBUȚIE

Gestiune cereri de ofertă vânzări
Recomandare Proces reclamație
Client
Cerere de ofertă Cerere comandă Bunuri şi facturi la

modificare date Plată client client
client de vânzare client client
client
Comenzi de
Birou de
vânzări
vânzări
Proces
Proces cerere de Determinare tip Întreținere date de
determinare preț
ofertă comandă vânzări bază client
client
Comenzi de
Birou de
vânzări
Comandă vânzări Comandă vânzare Comandă de vânzări

vânzări
Comandă vânzare Comandă vânzare Comandă vânzări

standard (din stoc externă (livrare achiziționată (specifică
în numerar urgentă pentru client) retururi
general) directă la clienți)
Puncte de
vânzare
Prelucrare livrare
Proces de Prelucrare retururi
de ieşire
achiziție
/puncte de
VÂNZĂRI
vânzare
BIROU
Prelucrare factură
CONTABILITAT
E CLIENȚI
Introducere proces Plăți Prelucrare blocare Prelucrare credit‐

de plăți finanțe livrare client debit memo

Figura 2.16. Diagrama „Cereri de ofertă vânzări”

Indiferent de abordare şi/sau implementare, modelarea proceselor economice
este foarte importantă pentru reuşita implementării sistemelor integrate, motiv
pentru care, în paragraful următor, este prezentat modul concret de realizare a
modelării de proces. Am ales instrumentul SIMPLE BET11, în principal
disponibilitatea sa, fiind o soluție open source.

2.5. Aspecte privind modelarea proceselor de afaceri
în aplicaţia SIMPLE BET

2.5.1. Proces şi procedură

În vederea modelării cu succes a proceselor de afaceri, deşi suntem convinşi
că cititorii cărți sunt familiarizați cu noțiunile şi diferența dintre proces şi procedură,
în cele ce urmează vom descrie succint cele două concepte. Astfel, procesul poate fi
văzut ca o suită de activități care preiau o intrare, îi adaugă valoare prin consum de

11 SIMPLE este o aplicație informatică de modelare organizațională, dezvoltată de Avantera. SIMPLE,
sigla SIMPLE constituie mărci comerciale şi proprietate intelectuală Avantera.

resurse şi produc o ieşire aşteptată. Procedura este un document care deține o
structură reglementată (intern, prin standarde sau prin acte normative) şi descrie
un proces organizațional. Din punct de vedere taxonomic, în aplicația SIMPLE BET,
procesele pot fi:
1) procese generale, generice şi specifice:
procesul general este acel proces în care există cel puțin un actor generic
care ar putea aparține oricărei unități organizaționale din organigramă.
Desfăşurarea procesului s‐ar putea produce pe întreg teritoriul organizației. De
exemplu, procesul de „Angajare personal” este un proces general pentru orice
organizație;
procesul generic conține cel puțin un actor generic care ar putea aparține
unui număr oarecare de unități organizaționale din organigramă, dar nu oricărei
unități. Desfăşurarea procesului nu s‐ar putea produce pe întreg teritoriul
organizației, ci doar pe o parte a acestui teritoriu. Grupul de procese „Implementare
proiect de investiții pentru creşterea capacității de producție” se poate desfăşura în
oricare dintre unitățile de producție ale unei organizații, dar cu siguranță putem fi în
situația de a nu implica în execuție orice unitate organizațională într‐un asemenea
proiect;
în cadrul procesului specific, toți agenții sunt precizați ca agenți structurali
(nu există niciun agent generic). Cele mai multe procese se încadrează în această
ultimă categorie;
2. procese principale şi procese secundare:
procesele principale sau de bază sunt considerate acele procese care
servesc direct obiectul de activitate al unei UO12 sau care ocupă un procent
semnificativ din capacitatea acesteia;
pe de altă parte, există activități care nu au legătură directă cu obiectul de
activitate al unei organizații şi care nu ocupă un procent important din capacitatea
acesteia. În această categorie se încadrează procesele secundare sau auxiliare.

2.5.2. Fluxul unui proces

Procesele în SIMPLE sunt descrise prin răspunsul dat următoarelor întrebări:
Ce se face? Cine face? (resurse umane, agenți); Ce alte resurse (materiale, mijloace
de producție‐instrumente, informaționale‐informatice, financiare, de altă natură)
sunt utilizate‐consumate în execuția a ceea „ce se face”? Ce relații se stabilesc între
activități şi resurse?
Elementele descriptive rezultate din răspunsurile date la întrebările de mai
sus sunt obiecte în baza de date. Astfel, răspunsul la întrebarea „ce se face” este de
fapt „fluxul” procesului. Fluxul, paşii de urmat, succesiunea de activități (deşi nu este
o succesiune liniară şi nu este alcătuită doar din activități), cursul activității,

12 Dintr‐o abordare managerială, pentru un director de unitate organizațională (UO), există activități
considerate a fi mai importante fie pentru că sunt direct legate de obiectul de activitate al UO, fie pentru
că ocupă un procent semnificativ din capacitatea de lucru a acesteia.
„mersul” lucrurilor (best practice) sunt elementele componente ale unui flux de
procese. SIMPLE propune următoarele obiecte13 care pot fi folosite pentru a contura
cât mai bine fluxul unui proces:
activităţi – ansamblu de acțiuni, operații, decizii realizate prin participarea
unui grup de agenți, care nu necesită detaliere suplimentară în raport cu nivelul de
pregătire profesională al agenților sau cu alte criterii (de exemplu, necesitatea de a
cunoaşte acele detalii care diferă de la participant la participant în funcție de rolul
îndeplinit în cadrul fluxului de proces). De reținut că, pentru denumirea activităților
în SIMPLE BET, se vor folosi următoarele principii:
– o activitate începe întotdeauna cu un substantiv provenit din verb
(extragere, eliminare, spargere, monitorizare, realizare, studiere etc.);
– se foloseşte exprimarea telegrafică în care se renunță la articulare,
prepoziții şi se utilizează faptul că relația dintre resursă şi activitate este
„standardizată” şi precizată de aplicația informatică SIMPLE;
interfaţa de proces indică necesitatea execuției procesului denumit între
elementul de flux predecesor şi elementul de flux succesor al interfeței. Ea:
– poate indica o intrare dinspre sau o ieşire spre alt proces descris sau o
ieşire spre alt proces cu întoarcere după execuția acelui proces în procesul curent;
– permite modularizarea reprezentării informației despre procese;
eveniment – poate constitui o stare, schimbare de stare, situație, context.
Evenimentul nu este o activitate, nu consumă resurse, nu are durată, ci este
caracteristic unui moment în timp. Distingem următoarele tipuri de evenimente:
– declanşator – întâmplare care presupune inițierea unei anumite activități
sau începerea execuției unui proces, stare inițială care ar necesita declanşarea
execuției unui proces. Exemplele îmbracă două forme: „s‐a primit o petiție”, „s‐a
prezentat un pacient la unitatea de primire urgențe”, „s‐a prezentat un client la
recepția hotelului”, „s‐a produs o scurgere de material inflamabil” (a se remarca
utilizarea timpului trecut în exprimare) respectiv „în fiecare luni”, „în a treia
săptămână din lună”, „15 ianuarie”, „lunar, în prima săptămână a lunii”, atunci când
evenimentul este asociabil clar unui moment de timp şi eventual are o periodicitate
dată;
– finalizator – marchează finalizarea unei anumite activități sau proces care
constată o stare finală. Exemple: „s‐a semnat procesul‐verbal de recepție” (a se
remarcă utilizarea timpului trecut în exprimare) sau „15 ianuarie”, „ultima zi din
lună”, atunci când de fapt marcăm o dată de finalizare, un deadline;
– discriminatoriu – întotdeauna precedat de operatorul „SAU EXCLUSIV”,
care presupune execuția unei anumite secvențe de activități (fir de activități)
specifice acelei situații – acelui context; de exemplu, acele evenimente discrimi‐
natorii care fac distincția între două cazuri ce se exclud reciproc;
– descriptor – întotdeauna precedat de operatorul „ŞI” ori „SAU”;
evenimentul denumeşte sintetic firul de activități ce‐i succede (este foarte util să

13 Definițiile sunt prelucrate după manualul modelatorului disponibil la adresa https://www.
avantera.ro/bet/v1.6.1/manual.pdf

putem vedea dintr‐o privire ce urmează să facem dacă alegem un fir de activitate
care succede operatorului „ŞI”, respectiv „SAU”, operatorul „SAU” este o situație rar
întâlnită);
operatorul poate fi un multiplicator‐demultiplicator al relației de
precedență şi are următoarea taxonomie14:
– operator de ramificație. O interfață de proces poate avea mai multe fire de
activitate de tip succesor, discriminate cu ajutorul unor evenimente prin intermediul
unui operator de ramificare a firului de activități. În acest caz, se vor folosi
operatorii: SAU – pentru execuția oricărei combinații de fire ce‐i succed, dar trebuie
să existe cel puțin un fir (se denumesc O1, O2, ... – de la OR); SAU EXCLUSIV – pentru
execuția exclusivă a unuia dintre firele care succed operatorul (se denumesc cu X1,
X2,... – de la XOR; ȘI – pentru execuția obligatorie, paralelă, a firelor care succed
operatorul (se denumesc cu A1, A2, ... – de la AND);
– operator de confluență. O activitate sau o interfață de proces poate avea
mai mulți predecesori prin intermediul unui operator de confluență (se denumesc
cu J1, J2, ... – de la JOIN).
În reprezentarea proceselor, din dorința ca procedurile să poată fi citite şi
înțelese cu uşurință, toate punctele de intrare în proces se leagă la un operator
numit START. De obicei, acesta este un operator de tip SAU EXCLUSIV, dar ar putea fi
şi de tip SAU sau chiar ŞI (dacă am fi în situația în care două evenimente
declanşatoare trebuie să aibă loc simultan pentru a demara execuția procesului).
Conform aceluiaşi raționament, toate punctele de ieşire din proces sunt legate la un
operator numit STOP, care însă este întotdeauna un operator de confluență.
Aşadar, dacă punem cap la cap informațiile prezentate mai sus, putem contura
definiția fluxului unui proces. Astfel, fluxul poate constitui un grup de activități,
evenimente, operatori, interfețe de proces care sunt legate între ele prin relații de
precedență temporală:
precedate de operatorul SAU întrucât primul, al doilea sau ambele
evenimente ar putea declanşa execuția procesului;
succedate de un operator de „confluență” pe care‐l putem denumi J1 (de la
„join”) pentru că activitățile care urmează celor două evenimente sunt aceleaşi.

2.5.3. Exemplu de modelare a unui proces de afaceri
în SIMPLE BET

În vederea exemplificării modului în care poate fi modelat un proces de afaceri
în aplicația SIMPLE BET, propunem o variantă simplificată a procesului de angajare.
Astfel, după autentificarea în cadrul aplicației (diponibilă în varianta cloud la
adresa https://www.avantera.ro/bet/demo), cu ajutorul tabului Administrare
proces/Adaugare proces, se introduc datele de identificare ale procesului de angajare
(denumire proces, UO, participanții, tip proces şi roluri), surprinse în figura 2.17.

14 Idem, nota 13.

Figura 2.17. Completarea datelor iniţiale ale procesului şi salvarea

După salvarea procesului, acesta va putea fi editat din cadrul tabului Listă
procese, prin operațiunea de selectare a numelui acestuia. Odată selectat, procesul
este deschis în cadrul tabului Tabel sintetic. Figura 2.18 prezintă reperele paginii
(tabel sintetic) şi informațiile introduse pentru demararea procesului de modelare
privind un proces simplu de angajare.
O succintă analiză a informațiilor prezentate în cadrul tabelului sintetic
relevă elementele fluxului de proces care însoțeşte angajarea. Astfel, se observă că
s‐au folosit şase obiecte de tip activitate, un eveniment şi un proces, la care se
adaugă operatorii START(Sau), STOP(Confluență), X1(Sau exclusiv), J1(Confluență).
Butoanele poziționate în partea superioară stângă a ecranului permit adăugarea în
fluxul procesului a elementelor descriptive necesare (butoanele şi
adaugă operatorii necesari începerii şi, respectiv, finalizării procesului; butonul
facilitează adăugarea unui eveniment, butonul adaugă o activitate nouă în fluxul
procesului, butonul adaugă o interfață de proces (stabilişte legătura cu un alt
proces, creat anterior şi disponibil în lista de modele), butonul permite
adăugarea unui operator, iar butonul permite adăugarea unui obiect pentru
mai multe tipuri de activități). De asemenea, în figura 2.18 se observă în coloanele
Predecesor şi Succesor modalitatea de subordonare a elementelor care țin de fluxul
procesului (coloana a doua). În ultima coloană (nu este cuprinsă în captura
prezentată) sunt adăugate informații suplimentare sub forma unor documente, care
susțin activitatea sau evenimentul respectiv.


Figura 2.18. Informaţiile paginii „Tabel sintetic” şi completarea procesului
de angajare

Vizualizarea diagramei de flux aferentă procesului de angajare modelat se
poate realiza în două moduri (ambele disponibile prin acționarea pictogramelor
situate în colțul stânga sus al tabelului sintetic – vezi figura 2.18). Astfel:
butonul afişează pe ecran diagrama pasivă a procesului modelat.
Această diagramă nu permite efectuarea de modificări (figura 2.19);
1. START
2. E > A fost identificată necesitatea efectuării unei angajări
3. A > Întocmire comisie de evaluare
4. A > Stabilirea datei interviului
5. A > Verificare plan anual de angajări
6. X1
9. A > Angajarea era prevăzută în planul anual de angajări 7. A > Angajarea era prevăzută în planul anual de angajări
8. P > Actualizare plan anual de angajare
10. J1
Succesor J1
11. A > Derularea etapelor angajării
12. STOP

Figura 2.19. Diagrama statică a procesului modelat (Angajare)

butonul afişează pe ecran diagrama interactivă a procesului modelat.
Aceasta permite efectuarea de ajustări prin tehnica drag & drop (vezi figura 2.20).
Astfel, pentru exemplificare am inclus în partea stângă a figurii diagrama parțială a
procesului, precum şi o simulare a modificării fluxului de activități a procesului
modelat (în partea dreaptă) – prin adăugarea activității de stabilire a datei
interviului înaintea activității de întocmire a comisiei de evaluare. Operațiunea drag
& drop asupra segmentelor de flux produce o rearanjare a succesiunii obiectelor,
procedură care se dovedeşte utilă în cazul proceselor complexe, întrucât facilitează
verificarea corectitudinii procesului şi corecția rapidă;
butonul permite vizualizarea hărții interfețelor de proces pentru
procesul activ.

START START
E > A fost identificată necesi‐ E > A fost identificată necesit‐

tatea efectuării unei angajări atea efectuării unei angajări
A > Stabilirea datei
A > Întocmire comisie de AA > Întocmire comisie
A > Întocmire comisie de
> Întocmire comisie de interviului
evaluare de evaluare
evaluare
A > Stabilirea datei A > Stabilirea datei
interviului interviului
A > Verificare plan anual A > Verificare plan anual
de angajări de angajări
X1 X1
A > Angajarea nu era A > Angajarea nu era A > Angajarea era prevăzută

A > Angajarea era prevăzută prevăzută în planul anual
prevăzută în planul anual în planul anual de angajări în planul anual de angajări
de angajări de angajări
P > Actualizare plan anual J1
P > Actualizare plan anual J1 de angajare
de angajare
Succesor: J1
Succesor: J1
A > Derularea etapelor
A > Derularea etapelor
angajării
angajării

Figura 2.20. Diagrama interactivă (parţială) a procesului modelat (Angajare)

Documentația care însoțeşte procesul modelat poate fi exportată cu ajutorul
pictogramelor localizate în dreapta sus a ecranului. Astfel, fişierul obținut poate fi de
tip pdf, doc sau arhivă zip. Pe baza informațiilor stocate în baza de date,
aplicația SIMPLE BET permite includerea în raportul generat în format .pdf toate
informațiile relevante cu privire la procesul modelat, respectiv procedura acestuia.
Categoriile de informații respectă cerințele formulate în ISO 10013. Aplicația
generează, în cadrul arhivei ZIP, atât procedura, cât şi alte fişiere asociate precum
formulare, diagrama de flux, instrucțiunile de lucru, versiuni etc. Un exemplu de
documentație, pe modelul procesului de angajare exemplificat în cadrul acestui
paragraf, este prezentat în anexa 2.1.
În concluzie, fluxul unui proces ne ajută să răspundem la întrebarea „ce se
face” (în cazul unei angajări – conform procesului succint modelat de noi),
permițându‐ne să abordăm toate variantele de execuție a activităților, cauzele

declanşatoarele şi stările finale. Ne oferă totodată posibilitatea reprezentării
modulare a informației prin utilizarea interfețelor de proces.

2.5.4. Prezentarea unui proces integrat la nivel de întreprindere,
modelat în SIMPLE BET

Structura de bază a procesului integrat de întreprindere pe care dorim să‐l
modelăm în aplicația SIMPLE BET este evidențiat în figura 2.21. Se observă că
modelul reuneşte cinci submodele, relaționate prin intermediul interfațări de
procese. Astfel, un subproces poate constitui o intrare sau o ieşire dintr‐un alt
subproces. Prin intermediul utilizării obiectelor specifice instrumentului SIMPLE
BET, s‐a reuşit implementarea celor cinci subprocese independente şi relaționarea
lor prin intermediul obiectului interfaţă de proces. În figura 2.23 este prezentată
captura de ecran care prezintă interacțiunile din procesul de vânzare şi celelalte
patru procese care formează procesul integrat de întreprindere. Astfel, din cadrul
opțiunilor procesului de vânzare, s‐a optat pentru butonul , care permite
vizualizarea hărții interfețelor de proces.
În cazul ilustrat în figura 2.23, procesul de vânzare este elementul principal
întrucât harta interfețelor de proces a fost apelată din cadrul acestui proces. Prin
intermediul săgeților ataşate automat proceselor modelate, aplicația precizează
pentru fiecare proces rolul de intrare sau ieşire pentru procesul aflat pe nivelul
ierarhic superior. Spre exemplu, se observă că procesul de vânzare apelează două
procese externe (livrare şi cerere de producție), ambele având rol de ieşire pentru
procesul aflat pe nivel ierarhic superior (Vânzare). În această manieră, harta
interfețelor de proces, aşa cum menționează şi descrierea pentru obiectul interfaţa
de proces indică necesitatea execuției procesului denumit între elementul de flux
predecesor şi elementul de flux succesor al interfeței. În cazul prezentat mai sus,
interfețele asigură ieşiri din procesul de vânzare către procesele de livrare şi cerere
de producție, cu întoarcere după execuția acelor procese în procesul curent. Mai
multe detalii sunt vizibile în figura 2.22, care prezintă diagrama statică (stânga) şi
diagrama interactivă (dreapta) ale procesului de vânzare.

Proces de vânzare
Proces de cerere Proces de livrare
producție
Proces de achiziție Proces de producție
materii prime

Figura 2.21. Componentele procesului integrat la nivel de întreprindere

Proces de vânzare Vânzare
1. START
1. START
E > oportunitate de vânzare
E > oportunitate de vânzare
A > Primirea comenzii ferme A > Primirea comenzii ferme de cumpărare de la client
de cumpărare de la client
A > Crearea şi trimiterea cererii de vânzare
A > Crearea şi trimiterea
cererii de vânzare
A > Recepția comenzii ferme de cumpărare de la client
A > Recepția comenzii ferme
de cumpărare de la client
A > Crearea comenzii de vânzare
A > Crearea comenzii de
vânzare 7. X1
X1
8. E > Există produse pe stoc 11. E > Nu există produse pe stoc
E > Există produse pe stoc E > Nu există produse pe stoc 9. P > Proces de Livrare 12. P > Proces de cerere de producție

Succesor: STOP
P > Proces de livrare
P > Proces de cerere de
producție 10. STOP
Succesor: STOP
STOP

Figura 2.22. Diagramele interactivă şi statică ale procesului de vânzare

Proces de vânzare
Proces de livrare Proces de cerere de
producție
Proces de producție Proces de vânzare
Proces de cerere de Proces de achiziție materii Proces de livrare

producție prime
Proces de achiziție materii
Proces de vânzare Proces de producție
prime
Proces de cerere de Proces de producție
producție

Figura 2.23. Harta interfeţelor de proces aferente procesului de vânzare

În figura 2.24 este prezentat fluxul obiectelor implicate în modelarea
procesului de vânzare. Astfel, s‐au folosit următoarele obiecte:
operatorul START de tip SAU a fost folosit pentru toate punctele de intrare
în cadrul celor cinci procese modelate în exemplul de față, din dorința de a facilita
citirea şi înțelegerea procedurilor procesului modelat;
evenimentul intitulat Oportunitate vânzare reprezintă o situație, un context
pentru care apare evenimentul modelat. Menționăm că am implementat acest
element sub forma unui eveniment şi nu a unei activități, deoarece evenimentul nu
este consumator de resurse, nu are o durată precisă şi caracterizează un anumit
moment de timp;
urmează o succesiune de patru activităţi15 care dau consistență procesului
modelat. Acestea sunt duse la îndeplinire printr‐un ansamblu de acțiuni, operații,
decizii realizate prin participarea angajaților întreprinderii;
verificarea existenței pe stoc a produselor care fac obiectul vânzării impune
utilizarea unui operator de tip SAU EXCLUSIV, denumit X1 (de la XOR – eXclusive
OR), care permite execuția exclusivă a unuia dintre firele care succed operatorul.
Este vorba despre situațiile prezentate prin două evenimente distincte:
– evenimentul „există produse pe stoc” şi
– evenimentul „nu există produse pe stoc”;
situația descrisă prin evenimentul „există produse pe stoc” este continuată
prin intermediul unei interfeţe de proces care nu este doar un simbol într‐o diagramă
SIMPLE, ci are asociată o hiperlegătură care facilitează navigarea efectivă între
proceduri pentru a înțelege mai uşor ansamblul activităților modelate. Această
ramură este finalizată prin utilizarea operatorului de confluență STOP, descris la
finalul enumerării;
revenim la cea de‐a doua ramură generată de operatorul X1, respectiv la
situația descrisă prin evenimentul „nu există produse pe stoc”. Folosind o logică
firească, atunci când nu avem suficientă producție, se impune să parcurgem paşii
necesari unui proces de cerere de producţie. Întrucât acest proces a fost implementat
anterior, vom folosi o interfață de proces care va lega, printr‐o hiperlegătură,
evenimentul de procesul de cerere de producţie. Ca finalitate a acestei ramuri, se
impune editarea obiectului interfață de proces în scopul adăugării unui obiect
succesor, respectiv operatorul de confluență STOP descris în cele ce urmează;
toate punctele de ieşire din procesele modelate sunt legate la un operator
denumit STOP, care însă este întotdeauna un operator de confluență (întrucât
permite existența mai multor predecesori concretizați în obiectele precedente,
precum evenimente, activități, interfețe de proces etc.).

15 Primirea comenzii ferme de cumpărare de la client, crearea şi trimiterea cererii de vânzare, recepția
comenzii ferme de cumpărare de la client, crearea comenzii de vânzare.


Figura 2.24. Fluxul obiectelor utilizate în modelarea procesului de vânzare

Deşi toate cele cinci procese sunt de o importanță egală în exemplul ilustrat în
cadrul acestui paragraf, continuăm prezentarea detaliată a procesului integrat de
întreprindere cu finalizarea procesului de vânzare, respectiv valorificarea producției
prin procesul de livrare.
Astfel, figura 2.25 surprinde diagramele interactivă (stânga) şi statică (dreapta)
ale procesului de livrare, care sunt generate automat din cadrul tabelului sintetic care
arată fluxul obiectelor procesului de livrare modelat (detalii în figura 2.26).

Proces de livrare Proces de livrare
2. P > Proces de producție
P > Proces de producție
3. P > Proces de vânzare
P > Proces de vânzare
4. A > Pregătirea livrării (ambalare şi încărcare)
A > Pregătirea livrării
(ambalare şi încărcare)

Figura 2.25. Diagramele interactivă şi statică ale procesului de livrare

Figura 2.26. Tabelul sintetic al procesului de livrare

Fluxul de obiecte prezentat în captura de ecran din figura 2.26 ilustrează
succesiunea logică ce însoțeşte modelarea de proces. Astfel, modelarea procesului
începe prin adăugarea unui operator de tip SAU intitulat START, după care urmează
adăugarea a două interfețe de proces care leagă procesul curent de procesele de
producție şi vânzare, care constituie intrări în cadrul procesului modelat. Odată
parcurse etapele impuse de procesele de producție şi vânzare, se revine în procesul
curent şi se parcurg următoarele elemente:
activitatea denumită pregătirea livrării, în care au loc ambalarea
produselor şi pregătirea pentru încărcarea acestora în containere/mijloace de
transport;
activitatea denumită sugestiv livrare, în care are loc expedierea propriu‐
zisă a produselor către client;
adăugarea operatorului de confluenţă STOP permite stabilirea finalității
procesului modelat.
Limitările de spațiu şi similitudinea logicii folosite în modelarea proceselor
cerere producţie, achiziţie materii prime şi producţie ne obligă să exportăm din
cadrul proceselor toate componentele şi să le includem în anexa 2.2.
Considerăm că instrumentul SIMPLE comercializat de firma Avantera este
unul extrem de folositor în demersul de modelare a proceselor de afaceri. Astfel,
produsul constituie prima aplicație de modelare a proceselor organizaționale
(business process modelling) realizată de o companie românească, oferind o soluție
pentru optimizarea funcționării proceselor de afaceri prin utilizarea unui
instrument inteligent, accesibil, de înaltă productivitate, destinat cu precădere
modelării organizaționale. Aplicația este disponibilă on‐line16, fiind instalată pe
serverul companiei, iar toți utilizatorii o pot accesa atât prin intranet, cât şi pe
internet. Alături de modelarea proceselor, aplicația permite şi alte facilități precum
managementul dosarului personal al angajaților, managementul fişelor de post,
raportarea internă şi managementul performanței proceselor organizaționale.

16 www.avantera.ro
Anexa 2.1
Angajare

Informaţii generale despre proces

Tip proces: specific
Domeniul de aplicare: HR, DG

Tabelul sintetic al procesului:

Agenţi Documente,
D > – decident instrumente,
Flux
C > – coordo cunoştinţe
A > – activitate
nator [I] – înre
Prede E > – eveniment
Nr. Succesor E > – executant gistrări
cesor P > – interfaţă de
B > – contri [IS] – instru
proces
butor mente
Ai, Xi, Oi, Ji – operatori
T > – transmite [K] – cunoş
către tinţe
1 START
2 START E > A fost identificată
necesitatea efectuării
unei angajări
3 A > Întocmire comisie Membrii
de evaluare comisiei –
CV‐uri
4 A > Stabilirea datei
interviului
5 A > Verificare plan
anual de angajări
6 X1
7 X1 A > Angajarea nu era
prevăzută în planul
anual de angajări
8 P > Actualizare plan J1 Planul anual
anual de angajare al angajărilor
9 X1 A > Angajarea era J1
prevăzută în planul
anual de angajări
10 J1
11 A > Derularea etapelor STOP
angajării
12 STOP

Informații detaliate:

1. Operator: START (Sau)
2. Eveniment: A fost identificată necesitatea efectuării unei angajări
3. Activitate: Întocmire comisie de evaluare
: membrii comisiei ‐ CV‐uri (Tip document ‐ de lucru; Global ‐ Da; Model ‐ Fise
PostaferenteCIM.pdf)
4. Activitate: Stabilirea datei interviului
5. Activitate: Verificare plan anual de angajări
6. Operator: X1 (Sau exclusiv)
7. Activitate: Angajarea nu era prevăzută în planul anual de angajări
8. Interfaţă de proces: Actualizare plan anual de angajare (Bidirectional)
: Planul anual al angajărilor (Tip document ‐ de lucru; Livrabil ‐ Principal; Global
‐ Da; Model – planulanualdeangajari.docx)
: DG (UO ‐ Director General)
9. Activitate: Angajarea era prevăzută în planul anual de angajări
10. Operator: J1 (Confluenţă)
11. Activitate: Derularea etapelor angajării
12. Operator: STOP (Confluenţă)

Tip Număr An Titlu
Nume şi prenume Unitatea organizațională Etapa Data Semnătura
Procedura documentată de Daniel Păvăloaia
Versiune Dată salvare Persoană modificare Unitate organizațională

Anexa 2.2
Documentaţia procesului integrat de întreprindere,
modelat în SIMPLE BET
A2.2.1. Proces de cerere de producţie


Tip proces: general
Domeniul de aplicare: MF, RD


Agenţi Documente,
Flux D > – decident instrumente,
A > – activitate C > – coordo cunoştinţe
E > – eveniment nator [I] – înre
Prede
Nr. P > – interfaţă de Succesor E > – executant gistrări
cesor
proces B > – contri [IS] – instru
Ai, Xi, Oi, Ji – butor mente
operatori T > – tran [K] – cunoş
smite către tinţe
1 START
2 START P > Proces de vânzare
3 E > Solicitare de
achiziție transmisă
către MAGAZIE
4 A > Cerere de
fabricație a
produsului
5 E > Solicitarea de
producție transmisă
către FABRICAȚIE
6 A > Autorizare
producție
7 X2
8 X2 E > Există materii
prime necesare
producției
9 P > Proces de STOP
producție
10 STOP
11 X2 E > Nu există materii
prime necesare
producției
12 P > Proces de achiziție STOP
materii prime

Informaţii detaliate şi diagrama statică:

2. Interfaţă de proces: Proces de vânzare (Intrare)
3. Eveniment: Solicitare de achiziţie transmisă către MAGAZIE
4. Activitate: Cerere de fabricaţie a produsului
5. Eveniment: Solicitarea de producţie transmisă către FABRICAŢIE
6. Activitate: Autorizare producţie
7. Operator: X2 (Sau exclusiv)
8. Eveniment: Există materii prime necesare producţiei
9. Interfaţă de proces: Proces de producţie (Ieşire)
11. Eveniment: Nu există materii prime necesare producţiei
12. Interfaţă de proces: Proces de achiziţie materii prime (Ieşire)

1. START
2. P > Proces de vânzare
3. E > Solicitare de achiziție transmisă către MAGAZIE
4. A > Cerere de fabricație a produsului
5. E > Solicitarea de producție transmisă către FABRICAȚIE
6. A > Autorizare producție
7. x2
8. E > Există materii prime necesare producției 11 E > Nu există materii prime necesare

producției
9. P > Proces de producție 12. P > Proces de achiziție materii prime

Succesor: STOP
10. STOP
Succesor: Nu există materii prime necesare
producției

A2.2.2. Proces de achiziţie materii prime


Tip proces: general
Domeniul de aplicare: COM, MK


Agenţi
D> –
decident Documente,
Flux C > – coor instrumente,
A > – activitate donator cunoştinţe
Prede Succe
Nr. E > – eveniment E > – execu [I] – înregistrări
cesor sor
P > – interfaţă de proces tant [IS] – instru
Ai, Xi, Oi, Ji – operatori B > – contri mente
butor [K] – cunoştinţe
T > – trans
mite către
1 START
2 START P > Proces de cerere de
producție
3 E > Se identifică necesitatea
achiziției de materii prime
necesare producției
4 A > Creare cerere de
cumpărare de către
MAGAZIE
5 A > Crearea şi trimiterea
comenzii de aprovizionare
cu materii prime
6 A > Recepția şi înregistrarea
primirii materiilor prime
7 P > Proces de producție STOP
8 STOP

Informaţii detaliate şi diagrama statică:

1. Operator: START (Sau exclusiv)
2. Interfaţă de proces: Proces de cerere de producţie (Intrare)
3. Eveniment: Se identifică necesitatea achiziţiei de materii prime necesare producţiei
4. Activitate: Creare cerere de cumpărare de către MAGAZIE
5. Activitate: Crearea şi trimiterea comenzii de aprovizionare cu materii prime
6. Activitate: Recepţia şi înregistrarea primirii materiilor prime
7. Interfaţă de proces: Proces de producţie (Ieşire)

#12 Proces de achiziție materii prime

A2.2.3. Proces de producţie


Tip proces: general
Domeniul de aplicare: MF


Agenţi
D > – deci
Documente,
Flux dent
instrumente,
A > – activitate C > – coordo
cunoştinţe
E > – eveniment nator
[I] – înre
Nr. Predecesor P > – interfaţă de Succesor E > – execu
gistrări
proces tant
[IS] – instru
Ai, Xi, Oi, Ji – opera B > – contri
mente
tori butor
[K] – cunoştinţe
T > – trans
mite către
1 START
2 START P > Proces de cerere
de producție
3 P > Proces de achiziție
materii prime
4 E > Solicitare de
transmitere materii
prime către MAGAZIE
5 A > Recepție materii
prime
6 E > Transmitere
cerere de producție
către FABRICĂ
7 A > Creare produse
8 A > Obținerea
producției
9 E > Transmitere
produse finite către
MAGAZIE
10 P > Proces de livrare STOP
11 STOP

Informaţii detaliate:

2. Interfaţă de proces: Proces de cerere de producţie (Intrare)
3. Interfaţă de proces: Proces de achiziţie materii prime (Intrare)
4. Eveniment: Solicitare de transmitere materii prime către MAGAZIE
5. Activitate: Recepţie materii prime
6. Eveniment: Transmitere cerere de producţie către FABRICĂ
7. Activitate: Creare produse
8. Activitate: Obţinerea producţiei
9. Eveniment: Transmitere produse finite către MAGAZIE
10. Interfaţă de proces: Proces de livrare (Bidirecţional)

#11 Proces de producție
1. START
2. P > Proces de cerere de producție
3. P > Proces de achiziție materii prime
4. E > Solicitare de transmitere materii prime către
MAGAZIE
5. A > Recepție materii prime
6. E > Transmitere cerere de producție către
FABRICĂ
7. A > Creare produse
8. A > Obținerea producției
9. E > Transmitere produse finite către MAGAZIE
10. P > Proces de livrare
11. STOP

Harta interfeţelor de proces:

Proces de cerere de producţie Proces de cerere de producție
Proces de vânzare Proces de producție Proces de achiziție materii prime
Proces de livrare Proces de cerere de producție
Proces de cerere de producție Proces de achiziție materii prime Proces de livrare
Proces de cerere de producție Proces de producție

101

Proces de achiziţie materii prime
Proces de achiziție materii prime
Proces de cerere de producție Proces de producție
Proces de vânzare Proces de producție Proces de achiziție materii

prime
Proces de livrare Proces de cerere de producție

102

Proces de producţie

Proces de producție
Proces de vânzare Proces de producție Proces de achiziție materii prime
Proces de livrare Proces de cerere de producție Proces de cerere de producție Proces de producție

103


CAPITOLUL 3
Implementarea sistemelor ERP

& î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 propriuzisă 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.).

Câteva consideraţii preliminare
Mottoul 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 să 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 Harwood1, 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ă (postimplementare).
Tabelul 3.1 prezintă structura demersului nostru. Ultima coloană face
trimitere la paragrafele unde sunt prezentate subiectele respective.

Tabelul 3.1
Descrierea fazelor ciclului de implementare ERP
Faza Are în centrul atenţiei Activităţi Paragraf
Determinarea Ö Necesitatea unui ERP Se determină necesitatea (de 3.1.1
nevoii de ERP ce?)
Ö Costuri & beneficii Se creează bugetul estimativ; 3.1.2,3.1.3
se evaluează beneficiile
Ö Cerințele Sunt adunate cerințele 3.1.4
noului sistem
Selecția Ö Ofertele de la furnizori Planificarea şi desfăşurarea 3.2
furnizorului procesului de selecție;
semnarea contractului
Ö Crearea condițiilor pentru derularea proiectului 3.3.1.1
Implementarea 3.3.1.2
propriu‐zisă şi urm.
Ö Desfăşurarea planului de implementare 3.5, 3.6
3.3.2,
Ö Instruirea utilizatorilor 3.3.3
Ö Startul productiv 3.7
Îmbunătățirea Ö Performanța Îmbunătățirea proceselor 3.8
continuă proceselor
Cunoaşterea Ö Piața IT&C Urmărirea tendințelor, Cap. 1
pieței IT&C înțelegerea noilor tehnologii
şi a impactului asupra
afacerii, cunoaşterea
principalilor furnizori

1 S. Harwood, ERP: The implementation cycle, Butterworh‐Heinemann, Oxford, 2003, p. 3.
Implementarea sistemelor ERP 107
Î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
despre prima implementare a unui sistem integrat sau despre 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 scontate a fi
obținută în cadrul proceselor din întreprindere şi a impactului pozitiv al
schimbărilor organizaționale rezultate din implementarea sistemului.

3.1.1. Prima întrebare: de ce?

Cineva, undeva, decide că este 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ă2:
– 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 upgrade;
– 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 managerilor ş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ții3 estimează că implementarea sistemului ERP va costa de până la şase
ori mai mult ca licențele software. Altfel spus, pentru un leu investit în software se
cheltuiesc între trei şi şase 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:
– mărimea întreprinderii (cifra de afaceri şi numărul de angajați);
– numărul de utilizatori ai sistemului;
– numărul de module implementate;
– componentele adăugate şi schimbările realizate la cererea beneficiarului.
Conform aprecierilor analiştilor de piață americani, prețul pe utilizator
variază între 1.000 şi 8.000 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 preconfigurat,
preinstalat şi cu preț fix, atractiv desigur.

Numărul 1 mondial, SAP AG, a văzut încă de acum şapteopt ani oportunitatea de a
implementa soluţii ERP la firmele mici şi mijlocii. Şi cum nu le putea propune SAP
Enterprise, a ales să dezvolte SAP Business AllInOne, care asigură funcţionalităţile

2 S. Harwood, op. cit., p. 54.
3 Ne referim la articolele publicate pe site‐urile de specialitate: www.technologyevaluation.com;
www.intelligententerprise.com; www.erp.com, dar şi la publicațiile MIS Quarterly, Management

Information Systems sau Commnunication of ACM, pe care le‐am studiat de‐a lungul anilor.
principale bazate pe cele mai bune practici pentru afaceri şi conţine procese economice
predefinite, ceea ce are ca rezultat o perioadă de implementare relativ scurtă, datorită
scenariilor de preconfigurare incluse. Iată mai jos un extras din broşura de promovare a
acestei soluţii4.

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;
– costurile induse de nedesfăşurarea unor activități sau costurile suplimentare
presupuse de desfăşurarea lor în alte condiții;
– costurile din deplasări legate de proiect (vizite la furnizori/clienți, instruire);
– costuri suplimentare presupuse de extinderea activității departamen‐
tului 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 cinci ani). Specialiştii apreciază

4 Sursa: http://www.sap.com/romania/solutions/smb/pdf/SAP_BAIO.pdf

că după această perioadă organizația ajunge într‐un moment de revizuire a
sistemului, optând pentru un upgrade sau pentru extinderea lui. Un sumar al
costurilor este prezentat în tabelul 3.2.
Marele pericol al bugetării este subestimarea costurilor şi relevarea unor
costuri neprevăzute, mai ales dacă escaladarea costurilor are loc în plină desfăşu‐
rare a proiectului. Sunt sensibile în acest sens costurile de customizare/persona‐
lizare. 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.

Tabelul 3.2
Structura costurilor totale ale unui proiect ERP

Costuri
Costuri
Categorie de cost continue
iniţiale
(pe an)

Directe Echipamente 5‐10%
Licențe software:
module ERP 25‐30%
sistemul de gestiune al bazei de date
terțe aplicații
Integrator Implementare (analiză, configurare,
testare, lansare, întreținere) 20‐25% 15‐25%

Costuri de dezvoltare 5‐10%
customizare aplicații
dezvoltare de interfețe
Instruire 5%

Indirecte Personalul intern: 10% 5%
management de proiect
angajați permanent
angajați cu jumătate de normă
contracte temporare de prestări servicii
Sursa: Harwood, S., ERP: The implementation cycle, Butterworh‐Heinemann, Oxford, 2003, p. 56.

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.

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 este cum să măsori
cât mai corect, dată fiind natura investiției.
Chiar dacă par mai palpabile, nu există nicio 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 nivelul
cheltuielilor asociate stocurilor, pe de altă parte (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
supraaglomerare. 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 la
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 mai mult.
Exemplu de calcul al beneficiilor cuantificabile
Pentru exemplificarea calculului beneficiilor cantitative ale implementării
ERP, considerăm o firmă cu activitate de producție, cu o cifră de afaceri de 25 de
milioane de lei. Firma are solduri importante la conturile de stocuri şi
creanțe/debitori. Partea de activ a balanței de verificare, cu imobilizările, arată ca
în tabelul 3.3. Dacă raportăm economiile realizate la valoarea totală a imobilizărilor,
observăm o reducere consistentă de 17,45%.
Tabelul 3.3
Economii determinate de ERP asupra imobilizărilor
Valoare curentă Economii
Denumire Îmbunătăţire
(mii lei) (mii lei)
Disponibilități 125
băneşti
Debitori 500 18% 90
Stocuri 750 20% 150
Mijloace fixe 750
Total imobilizări 1.375 240

Dacă dorim să vedem cum se reflectă beneficiile ERP în contul de profit şi
pierdere, trebuie să avem în vedere veniturile şi cheltuielile aferente acestora.
Pentru majoritatea firmelor de producție, costurile se ridică la 70‐75% din vânzări.
Beneficiile ERP descrise mai sus influențează valorile indicatorilor, generând
aproape dublarea profitului brut (vezi tabelul 3.4). Aşa cum am demonstrat deja,
îmbunătăţirile sunt:
– reducerea cu 5% a cheltuielilor materiale, datorată optimizării activității de
aprovizionare;
– reducerea cu 10% a cheltuielilor cu personalul, prin creşterea producti‐
vității şi eliminarea timpilor morți;
– reducerea cheltuielilor administrative este asociată reducerii nivelului
stocurilor – ne referim aici la cheltuielile aferente stocării, care au o pondere de
aproximativ 25% din cheltuielile de stocuri (25% din economiile de 1.500.000
reprezintă 375.000 de lei);
– creşterea cu 10% a veniturilor nu este luată în calculul următor, dar
aceasta va duce, în mod evident, la ridicarea nivelului profitului.
Tabelul 3.4
Economii determinate de ERP asupra contului de profit şi pierdere

Valoare curentă Economii
Denumire Îmbunătăţire
(mii lei) (mii lei)
Venituri din vânzări 2.500 10%
Cheltuieli materiale 1.125 5% 56,25
Cheltuieli cu forța de 250 10% 25,00
muncă
Cheltuieli indirecte 50
Total cheltuieli 1.875
Cheltuieli administrative 500 37,50
Profit brut 125 118,75

Nivelul total al economiilor anuale estimate se ridică la 358.750 de lei.
Dacă realizăm o estimare brută a costurilor sistemului ERP de 1.250.000 de lei (5%
din cifra de afaceri), este evidentă recuperarea totală a investiției în mai puțin de
patru ani, fără a lua în calcul creşterea cifrei de afaceri, care va avea loc cu siguranță
în următorii ani.
Aceste calcule rămân totuşi un simplu exercițiu matematic, un punct de
referință, util desigur pentru justificarea investiției; el permite anticiparea unor
rezultate, dar materializarea lor va depinde exclusiv de finalizarea implementării în
termenii stabiliți de timp şi bani şi în concordanță cu obiectivele definite.
Beneficiile necuantificabile sau nonfinanciare 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ă introdu‐
cerea 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 finan‐
ciare 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 care
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).
Aşa cum bine au observat unii specialişti5, beneficiile importante nu vin din
utilizarea efectivă a ERP, 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ţionale6. S‐a dovedit că valoarea
unui sistem nu se regăseşte în tehnologia informaţională înglobată, ci în
modul în care tehnologia este utilizată7, atunci când ea devine un mijloc de
realizare a unei strategii.

Beneficii intangibile
Curente Viitoare
Eficienţa Satisfacţia Previziuni mai Adaptare şi

operaţională clienţilor valoroase flexibilitate
Procese Calitate Pieţe Produse noi

Fluxuri de activităţi Timp de livrare Produse Servicii
Informaţii în timp real Suport postvânzare Achiziţii Clienţi
Creşte dificultatea de măsurare

Figura 3.1. Beneficiile intangibile

5 R.M. Donovan, „Why the controversy over the ROI from ERP?”, Midrange ERP, ianuarie, 2000.
6 E. Brynjolfsson, S. Yang, „The intangible benefits and costs of computer investments: evidence from
the financial markets”, lucrare inclusă în Proceedings of the International Conference on Information
Systems, Atlanta, SUA, 1997.
7 D. Remenyi ş.a., The effective measurement and management of IT costs and benefits, Butterworh‐
Heinemann, Oxford, 2000, p. 81.
3.1.4. Definirea cerinţelor

Această activitate se dovedeşte în multe cazuri una anevoioasă şi consuma‐
toare 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țelor identificate în noul sistem operațional va avea loc peste câtva timp (şase
luni, chiar şi un 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 fi în niciun
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 departamente 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 are
expertiza necesară, dar este străină 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 este sursa
intrărilor şi care este 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ă.

Date stocuri
Date stocuri

Sursa: Adaptare după Harwood, S., ERP: The implementation cycle, Butterworh‐Heinemann, Oxford,
2003, p. 59.
Figura 3.2. Exemplu de diagramă de procese

Î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ță;
– 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.

Oferta va cuprinde:
• arhitectura sistemului propus (software şi hardware);
• descrierea aplicațiilor care compun sistemul informatic integrat, precum
şi a infrastructurii software;
• descrierea soluției hardware;
• descrierea soluției de comunicații;
• metodologia de implementare şi managementul proiectului;
• descrierea modului în care se va asigura instruirea utilizatorilor şi
mentenanța SII postimplementare;
• datasheet‐uri ale aplicațiilor şi echipamentelor oferite;
• răspunsul punct cu punct la cerințele detaliate exprimate în caietul de
sarcini;
• manualele de utilizare, în limba română, pentru toate componentele
software ofertate;
• prezentarea echipei de implementare, însoțită de CV‐uri;
• certificate ISO 9001 ale ofertantului şi ale eventualilor membri în
consorțiu;
• referințe naționale şi internaționale ale componentelor soluției propuse;
• oferta financiară.
Sursa: http://www.radiocom.ro/uploads/media/Caiet_sarcini_ERP.pdf
Figura 3.3. Extras din caietul de sarcini. Livrabilele solicitate

Diagramele de procese pot face parte din caietul de sarcini, dar majoritatea
solicitanților se mulțumesc să descrie cerințele la nivel funcțional (vezi figura 3.4).

Ea trebuie să gestioneze informația despre furnizori, să înregistreze în sistem
facturile de la furnizori, precum şi alte tranzacții (note de debit, credit, plăți în
avans etc.), să asigure procesul de aprobare a facturilor pentru plată, să efectueze
plățile şi să reconcilieze plățile cu extrasul de cont bancar.
Contabilitatea furnizorilor trebuie să asigure instrumente eficiente de control
asupra plăților, pentru a optimiza planificarea acestora.

Contabilitatea furnizorilor trebuie să fie integrată în întreg sistemul
informațional; informația referitoare la tranzacțiile efectuate urmează să fie
transmisă în contabilitatea generală, fiind înregistrată în conturile
corespunzătoare.
Figura 3.4. Extras din caietul de sarcini referitor la managementul furnizorilor

Î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 (vezi figura 3.5).

Cerințe funcționale
1) Să definească furnizorii în sistem:
• cod;
• denumire;
• adresă;
• persoane de contact;
• nr. din Registrul Comerțului;
• termen de plată;
• codul taxei;
• codul de plătitor TVA.
2) Să permită ca un furnizor să aibă mai multe adrese.
3) Să permită fuzionarea mai multor furnizori.
4) Să permită ca un furnizor să fie în acelaşi timp client.
5) Să asigure introducerea şi gestionarea în sistem a facturilor de la furnizori.
Vor fi gestionate diversele tipuri de facturi: facturi standard, plăți în avans,
note de debit şi credit.
Figura 3.5. Extras din caietul de sarcini. Cerinţe funcţionale legate
de managementul furnizorilor

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 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 bestofbreed, 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 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 addon‐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
addon‐uri. Ele sunt concret module construite pe platforma pusă la dispoziție de
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, addon‐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 bestofbreed 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 cinci moduri în care se
realizează selecția8:
– alegerea la noroc (dat cu banul);
– alegerea pe bază de „cunoştințe”;
– alegerea celei mai „titrate” soluții;
– subcontractarea activității de implementare;
– 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ă aceasta garantează succesul. Este
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:
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;
proiectul ERP nu este un proiect IT, ci unul economic, specialiştii IT nu
trebuie să predomine numeric;
toți managerii‐cheie, din ariile funcționale vizate, trebuie să participe la
selecție;
încercând un demers democratic, se poate ajunge în extrema constituirii
unei echipe prea numeroase, ceea ce poate îngreuna acest proces;
includerea unui consultant extern se face cu precizarea clară a rolului său în
echipă, adică de consultanță, nu de decizie;
participarea managerului general poate aduce echilibru, atâta vreme cât
acesta îşi menține obiectivitatea;
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: 1) prospectarea pieței;

2) crearea listei scurte de furnizori potențiali; 3) restrângerea listei; 4) selecția finală.
Durata acestui proces, aşa cum reiese ea din practica proiectelor ERP, este între patru
şi şase săptămâni, depinzând de gradul de cunoaştere a 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.

3.2.1. Prospectarea pieţei

Piața abundă în oferte de soluții ERP, deci crearea unei liste preliminare
presupune o documentare simplă pentru găsirea tuturor candidaților. Sursele de
informare pot fi diverse. În ultimii ani, cele mai multe s‐au mutat pe web, după cum
urmează:
site‐urile furnizorilor de ERP, generate în rezultatele căutărilor;
publicațiile de specialitate în versiune electronică;
blogurile utilizatorilor, consultanților sau ale altor specialişti;
forumurile de discuții.
Pe lângă acestea, ar mai fi: participările la diverse evenimente (târguri,
prezentări etc.), presa clasică sau chiar discuțiile informale. Trebuie analizată cu
atenție situația soluțiilor ERP promovate prin parteneri. Spre exemplu, soluția ERP
Navision este dezvoltată de Microsoft, însă nu ei sunt şi cei care o implementează, ci
partenerii – documentarea în această direcție va permite alegerea acelor firme
partenere care pot intra în competiție. Lista inițială poate include până la 30‐40 de
nume, deoarece la momentul acesta nu se verifică şi relevanța funcțională a soluției.

3.2.2. Crearea listei scurte de furnizori potenţiali

Scopul acestei activități este obținerea unei liste de furnizori. Ea ar trebui să
conțină măcar trei opțiuni, maximul fiind cinci după unii, zece, după alții. Pornind de
la lista inițială, sunt evaluați toți furnizorii pe baza unui număr relativ mic de criterii
(cinci‐zece). Această activitate necesită doar în cazuri speciale contactarea directă a
furnizorilor; evaluarea se face ca la prima fază, preponderent prin documentare pe
internet. Iată o listă de posibile criterii de evaluare:
prezenţa furnizorului pe piaţa românească. Dacă furnizorul este străin,
atunci trebuie ca el să aibă activități operaționale în România, fie direct, fie prin
parteneri. În această fază trebuie eliminați cei care nu îndeplinesc această condiție;
orientarea soluţiei ERP către domeniul de activitate al clientului. Dacă
soluția ERP promovată de un furnizor merge pe domeniul producției, dar nu este
proiectată şi pentru producția discretă, atunci este descalificată din start;
cerinţe funcţionale sau tehnice specifice. Dacă există cerințe particulare,
care ies din tiparele funcționale sau anume cerințe tehnice (utilizarea unei anume
baze de date, de exemplu), este momentul să fie eliminați cei care nu le întrunesc;
numărul de implementări din domeniul de activitate vizat. Acest
criteriu poate să aibă şi o limită de timp, în sensul de a analiza activitatea în ultimii

trei ani. Este un criteriu relevant, deoarece demonstrează experiența furnizorului în
domeniul de activitate respectiv. Dacă nu are nicio implementare finalizată, poate fi
un semnal de alarmă şi un motiv de respingere a lui;
mărimea organizaţiei, văzută sub aspectul numărului de angajați şi al
cifrei de afaceri, este un indicator al încrederii care poate fi acordată furnizorului, cu
care clientul va intra într‐o relație pe termen lung;
situaţia financiară a furnizorului. Consultarea rapoartelor anuale ajută la
formarea unei imagini asupra situației de ansamblu a firmei furnizorului de soluții –
orice informație financiară din alte surse contează în formarea unei opinii proprii;
prima impresie. Deşi nu este o necesitate, o întâlnire preliminară este
relevantă după părerea multor manageri, care îşi folosesc şi flerul în afaceri pentru a
face această preselecție.

3.2.3. Restrângerea listei de furnizori potenţiali

În această fază se procedează la o analiză detaliată a celor rămaşi pe listă, în
scopul de a restrânge lista la doi‐trei furnizori, între care se va da lupta finală. Un
număr suficient de mare de criterii va asigura o imagine concludentă asupra fiecărui
candidat, un profil argumentat care trebuie să releve punctele tari şi punctele slabe.
Este sugerată utilizarea unui set coerent de criterii, care să acopere cât mai multe
aspecte şi să ofere un suport serios pentru selecție. O propunere în acest sens este
inclusă în tabelul 3.5.
Tabelul 3.5
Criterii de selecţie a furnizorului de ERP

Criteriu Argumentare Indicatori

Funcționalitate Determină potrivirea între Funcționalități de bază şi module;
cerințe şi soluția furnizată, la interfețe; baza de date; platforma
nivel de aplicații şi hardware
echipamente
Metodologia de Existența unei metodologii de Documentație furnizor
implementare implementare şi calitatea ei
reduc riscul eşecului
implementării
Costuri Evaluarea costurilor este Costurile pe categorii (licențe,
indispensabilă pentru echipamente, bază de date,
compararea cu bugetul implementare, mentenanță)
disponibil
Credibilitate Arată gradul de maturitate a Date despre înființare şi evoluție;
firmei, deoarece parteneriatul număr salariați; cifra de afaceri
cu aceasta va fi pe termen lung (dinamica pe mai mulți ani); cursul
acțiunilor la bursă etc.
Experiența în Implementările anterioare (ca Statistici de implementare; date de
domeniu număr şi finalitate) în domeniul la clienții existenți; analize
de activitate în discuție independente
înseamnă experiență şi
Criteriu Argumentare Indicatori

expertiză acumulate
Suportul Este extrem de important să se Tipurile de suport acordat (e‐mail,
postimple‐ poată bizui pe disponibilitate şi call center, forum, mesagerie
mentare o bună expertiză instantă)
Reputație Contribuie la obținerea Referințe de la clienți; rapoarte ale
succesului analiştilor de piață; (de ce nu)
informații informale (bârfe, zvonuri)
Strategie O viziune, o strategie pe termen Date de la furnizor; comunicate de
mediu‐lung indică intenții şi presă
direcții viitoare de dezvoltare
Sursa: Adaptare după Harwood, S., ERP: The implementation cycle, Butterworh‐Heinemann, Oxford,
2003, p. 3.

Criteriile de selecție analizate în acest stadiu pot fi aprofundate în stadiul
următor, prin implicarea mult mai activă a furnizorilor. În acest stadiu se poate
merge pe analiza informațiilor de pe site, a celor oferite de clienții actuali şi a
rapoartelor elaborate de firmele de cercetare specializate. Dacă pe plan
internațional acest gen de rapoarte este uşor de procurat (începând de la celebrul
Gartner Group până la firme mai noi, cum este Panorama Software, există o ofertă
foarte bogată, excesivă chiar, de rapoarte ale pieței de ERP), în România aceste
analize au început să se facă de mai puțin timp, iar actorii sunt în principal tot firme
străine de consultanță9.
În anumite cazuri, în particular acolo unde funcționalitățile dorite sunt
importante şi deosebite, se pot realiza în această fază şi prezentări/demonstrații ale
suitelor ERP aflate pe listă (unele firme oferă deschis, pe site‐ul propriu, versiuni
demonstrative ale soluțiilor lor). Oportunitatea acestora este decisă la nivelul
echipei beneficiarului, iar modalitatea de realizare este una informală, cu scop de
„inspectare” a aplicațiilor oferite de fiecare furnizor. În acest stadiu, credem că este
precumpănitor răspunsul dat de fiecare furnizor la întrebarea generală „de ce am
alege soluția dumneavoastră?", urmând ca sondarea funcțională să îi diferențieze pe
primii clasați, în ultima fază a procesului de selecție.

3.2.4. Selecţia finală

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

9 Pierre Audoin Consultants (PAC) este un grup internațional cu o istorie de peste 30 de ani, fondat în
1976 la Paris. Prin birourile deschise în ultimii 15 ani la München, Londra, New York şi Bucureşti, PAC
oferă analize de piață şi consultanță pentru companiile din industria de soft şi servicii informatice din
21 de țări. De zece ani, PAC are un birou regional la Bucureşti, echipa de consultanți din România fiind
responsabilă de regiunea Europa Centrală şi de Est (Cehia, Polonia, România, Rusia, Slovacia, Ungaria).
Cele mai importante studii PAC în România sunt SITSI (Software and IT Services Industry) şi ERP
România. Vezi mai multe informații pe https://www.pac‐online.com/

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 care vor urma, cu responsabilitate. Dacă nu sunt consultați, iar
ulterior vor apărea 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 cu o bună pregătire din partea beneficiarului, se poate cere ca demon‐
strația să se realizeze 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:
folosirea agendei comune asigură comparabilitatea dintre soluțiile analizate;
demonstrarea funcționalităților cu datele proprii va fi confortabilă pentru
utilizatori şi îi va ajuta să înțeleagă mai bine procesele prezentate;
implicarea cât mai multor utilizatori finali înseamnă identificarea
eventualelor slăbiciuni, vizibile doar pentru cei familiarizați cu un domeniu
funcțional anume;
examinarea rezultatelor obținute din centralizarea fişelor 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.
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:
în partea I să participe utilizatorii finali şi să evalueze funcționalitățile şi
interfața grafică utilizator din punctul lor de vedere,
î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 apărea î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 din cauza 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ă:
metodologia are o abordare structurată;
sunt definite clar etapele de parcurs, fiecare etapă fiind divizată în activități
clare şi neambigue;
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 care pot apărea î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 meto‐
dologie 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 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 postimplementare:
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 care vor fi alocați 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ă golive,
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 minimum 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;
costuri cu sistemul de operare;
costuri de licențiere pentru SGBD;
costuri de licențiere a modulelor ERP;
costuri de licențiere pentru alte aplicații necesare;
costuri de integrare între modulele ERP, alte aplicații necesare şi/sau
aplicațiile existente;
costuri de personalizare;
costuri de conversie a datelor din vechiul sistem;
costuri aferente managementului de proiect;
costuri de consultanță;
costuri de instruire;
costuri de deplasare;
costuri de mentenanță pentru primul an.
Pe lângă aceste costuri, care alcătuiesc bugetul proiectului, trebuie să se
discute şi să se negocieze costurile care apar postimplementare:
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 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 semnificative10. 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 utilizate11, î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ă este o firmă de top, cu experiență

10 Vezi L. Hurbean, D. Fotache, „New approaches in enterprise applications’ implementation”, publicat
în volumul Education, Research & Business Technologies, Editura ASE, Bucureşti, 2009, pp. 596‐601;
subiectele sunt prezentate în capitolul 8.
11 Vezi şi L. Hurbean, „Factors Influencing ERP Projects Success in the Vendor Selection Process”,
publicat în Proceedings of International Conference on Business Information Systems, Editura
Universității „Alexandru Ioan Cuza” , Iaşi, 2007, pp. 402‐410.

bogată, este o garanție a expertizei sale. Dacă este o firmă mai mică, ambiția de a
creşte o poate motiva să se implice cu seriozitate în proiect. Ambele alegeri pot fi
corecte, ambele au un anume grad de risc încorporat;
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 mediulung. 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 parte‐
neriate 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 sa;
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ă este simplă, dar şi pentru că este 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ă este 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 ori cred că au ceva de spus. O să încheiem
cu un sfat pentru managerii care 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.

3.2.5. Contractul de implementare a sistemului informatic integrat

După alegerea unui furnizor şi, implicit, a unei soluții, semnarea contractului
pare o chestiune de rutină. Desigur, vom spune că nu este aşa. Despre negociere s‐au
scris cărți întregi, iar cele scrise se aplică la fel de bine şi aici. În cele ce urmează,
vom reliefa câteva aspecte importante în opinia noastră:
cunoaşterea partenerului. La acest moment al proiectului, ar fi de dorit să
fie deja cunoscute o mulțime de lucruri despre furnizorul ales. Cu cât mai multe, cu
atât mai bine. Cu cât au loc mai multe discuții şi se pun multe întrebări, cu atât mai
puține pot fi surprizele. Este clar că până la finalizarea acestei faze nu este prea
târziu să renunți şi să cauți din nou;
răbdare şi atenţie la detalii. Un astfel de contract trebuie să detalieze
toate aspectele discutate. El va fi stufos, iar durata de negociere poate ajunge la
câteva săptămâni sau chiar o lună. Beneficiarul va suferi dacă nu va fi foarte atent la
ce se discută şi la cum sunt formulate înțelegerile în contract, căci verba volant,
scripta manent. Se va întâmpla aşa cum scrie în contract, orice înțelegere verbală nu
are nicio valoare;
circumspecţie la formele „standard” de contract. Mulți furnizori încep
negocierile propunând o formă de contract, cu justificarea că este un standard în
domeniu. Dacă se acceptă această formă ca punct de pornire, este recomandat să fie
citit cu foarte mare grijă, căci sigur va conține multe formulări în favoarea
furnizorului. O consultație de specialitate este bine‐venită şi în această fază a
proiectului. În principiu, nu există un contract standard, ele diferă de la un furnizor
la altul. Capitolele principale care sunt incluse în acest tip de contract sunt:
– definiții;
– prețuri şi condiții de plată;
– livrarea;
– instruirea;
– copyright şi transferul de proprietate;
– licențele software;
– alte licențe;
– echipamentele;
– răspunderea părților;
– garanții;
– erorile software;
– asistența;
– versiunile noi;
– anularea licențelor.
Întreg conținutul contractului trebuie atent citit şi verificat, se pot realiza mai
multe versiuni succesive, pe baza amendamentelor făcute. Semnificația termenilor
folosiți trebuie să fie clară, pentru a elimina ambiguitățile;
anticipare şi conduită preventivă. În conținutul contractului trebuie
stipulate toate detaliile şi trebuie prevăzute şi evenimente incerte, dar posibile, care
pot afecta bunul mers al implementării. De exemplu:
– ce se întâmplă dacă un bug (eroare) software ține pe loc implementarea
unei funcționalități?
– cine furnizează echipamentele necesare proiectului şi ce se întâmplă dacă
ele pot fi procurate din altă parte la un preț mai mic la momentul respectiv?
– care sunt penalitățile pentru erorile din baza de date la preluarea datelor
din vechiul sistem?
– în cât timp se obligă furnizorul să asigure resursa umană necesară, în cazul
pierderii angajaților pe parcursul implementării?

Acestea ar fi câteva indicii. Proiectul este expus multor riscuri, iar anticiparea
şi reglementarea prin contract a diverselor situații de risc sunt pentru client o plasă
de siguranță. Repetăm: dată fiind valoarea unui proiect ERP, niciun tarif de
consultanță în domeniul contractelor nu poate fi prea mare, comparat cu pierderile
care se pot obține cu un contract defectuos.

3.3. Implementarea sistemului ERP întro 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ței12 a indicat faptul că rezultatele implementărilor de MRP II se
caracterizează prin:
51% dintre ele au durat mai mult decât a fost planificat;
28% au avut depăşiri semnificative ale bugetelor stabilite;
în 68% din cazuri au fost modificate aplicațiile (personalizări);
56% au avut probleme operaționale la startul productiv din cauza instruirii
insuficiente;
25% nu au obținut beneficiile aşteptate;
28% nu ştiau exact care sunt beneficiile pe care le vor obține după
implementare!
În ciuda acestor semnale, în anii care au urmat, cu proiecte de integrare ERP,
mai vaste şi mai complicate decât MRP II, s‐au repetat multe dintre 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 căzând de acord că problemele tehnice au
rezolvare (uşoară ori anevoioasă), pe când cele legate de oameni sunt 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ă;

12 Benchmark Research Ltd., MRP II Implementation Satisfactory Survey, 1994, citat în S. Harwood, op.
cit., p. 93.
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 benefi‐
ciarului ş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, cât şi
culturi care le frânează ori chiar le resping. Dar despre toate acestea şi altele în plus
vom vorbi în capitolul 4.
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ă
premisele 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 topmanager
(director general sau altă denumire pentru funcția cea mai înaltă 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ționale13, î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 putând 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, deoarece va elabora planul proiectului şi va
înregistra progresul acestuia şi sub aspect birocratic. Însuşirile şi aptitudinile unui
manager de proiect sunt:
bun cunoscător al organizației şi membrilor acesteia;
educat în domeniul software şi tehnologii informaționale;
abilități de comunicare;
diplomat şi negociator priceput;
persoană organizată;
onest şi leal organizației;
rezistent la presiune şi greutăți (şi „cu obrazul gros", cum spune românul);
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.

13 Subiectul schimbare organizațională şi rezistență la schimbare este dezvoltat în capitolul 4.
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 apărea
conflicte asupra priorității: proiectul este important, trebuie respectate termene, dar
aceasta 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 succes14 se obține prin: eliminarea individua‐
lităț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ă orice 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 cinci şi zece membri, fiecare reprezentând
un departament:
Vânzări şi marketing;
Producție;
Aprovizionare;
Financiar;
Contabilitate;

14 Vezi şi E. Wang, H.W. Chou, J. Jiang, „The impacts of charismatic leadership style on team
cohesiveness and overall performance during ERP implementation”, International Journal of Project
Management, nr. 3/2005, pp. 173‐180, disponibil la http://www.sciencedirect.com/science?_
ob=ArticleURL&_udi=B6V9V‐4F14YTR‐2&_user=3839915&_coverDate=04%2F30%2F2005&_rdoc=&_
fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1332154767&_rerunOrigin=go
ogle&_acct=C000061509&_version=1&_urlVersion=0&_userid=3839915&md5=1d48ad0542ba7ffa1c0
bc9fe3c33fefd

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 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ă este 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 la acele şedințe la care opiniile sale
sunt necesare.
Î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 cum15,
fiind rezultatul discuțiilor dintre 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, fiind indispensabil în
desfăşurarea proiectelor complexe.

15 A.K. Johnston, A hacker's guide to project management, Butterworh‐Heinemann, Oxford, 1995, p. 5.

Sursa: Adaptare după Harwood S., ERP: The implementation cycle, Butterworh‐Heinemann, Oxford,
2003, p. 106.
Figura 3.6. Planul general de implementare ERP

Ipotetic, am conturat un plan general de implementare în figura 3.6. În această
variantă el este util în faza de organizare a proiectului şi constituie punctul de
plecare în planificarea de detaliu. În figura 3.7 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 3.7. Planul de ansamblu al unui proiect ERP

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 care descriu performanța: timpul, costul şi livrabilele. Unii autori sunt de
părere că ar trebui măsurate şi beneficiile16, 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 a 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 pe acela de suveran al proiectului ERP. Pe lângă importanța stabilirii unor
relații cordiale ca 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
acestuia. 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ă este vorba despre
disfuncționalități software, probleme tehnice, sau solicitarea tardivă a unor
modificări. Dacă nu sunt stipulate într‐o clauză din contract, este necesar un
document oficial în acest sens. De regulă, se stabilesc următoarele:
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ță;
incidentele trebuie raportate în scris;
î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ță”);
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 (cei mai importanți factori sunt 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 acesta 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
combatere17.
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 şi 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:
– tip (tehnic sau nontehnic);
– impactul asupra timpului, calității şi costului proiectului, cât şi asupra
reputației;
– probabilitatea de a se produce (0‐100%);
– impactul general asupra desfăşurării proiectului (0‐100%);
cuantificarea severității fiecărui risc (impact × 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.8 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.
Aşa cum se observă din figura 3.8, severitatea unui risc poate fi pusă în
evidență şi vizual, colorând valorile care solicită atenție. Este vorba despre 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.


Figura 3.8. Structura unui jurnal de riscuri

3.3.2. Aspecte tehnice privind instalarea noului sistem

Cele spuse anterior, cum că în ERP este vorba despre 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 care 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.
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.9).

Figura 3.9. Curba adoptării unui sistem nou de 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ționa‐
lităț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ţiale sunt 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.3.3.1. Fazele procesului de instruire

Primii care beneficiază de instruire sunt membrii echipei de proiect şi
administratorul de sistem, urmează apoi managerii şi utilizatorii finali. Natura şi
conținutul instruirii diferă pentru fiecare grup de cursanți. Din punct de vedere
formal, pentru fiecare grup‐țintă, instruirea înseamnă parcurgerea a cinci faze:
definirea obiectivelor, stabilirea conținutului, planificarea, livrarea şi evaluarea
activității.
Prin elaborarea strategiei de instruire, se configurează programul de instruire.
În acest scop, după identificarea grupurilor‐țintă, sunt creionate cele cinci faze
pentru fiecare, cu scopul de a realiza bugetul acestei activități şi a avea cadrul
general de desfăşurare a acesteia.

3.3.3.2. Definirea obiectivelor instruirii

Obiectivele desemnează ce va fi capabil cursantul să facă după participarea
la instruire, în principal competențele dobândite pentru a lucra în anumite module
software. Membrii echipei proiectului trebuie să dobândească abilități şi
cunoştințe care să le permită să analizeze, să dezbată şi să plănuiască utilizarea

funcționalităților pentru startul productiv. Pe baza cunoştințelor dobândite, ei sunt
cei care vor valida procesele şi fluxurile pentru noul sistem, ei vor sesiza eventualele
discrepanțe astfel încât să poată fi rezolvate până la pornirea în productiv. Mai mult
decât atât, abilitățile dobândite prin instruire, împreună cu expertiza lor în domeniul
funcțional pe care îl reprezintă, îi transformă pe utilizatorii‐cheie instruiți în tutori ai
utilizatorilor finali din aria lor de cunoaştere. Ei nu pot înlocui instructorii şi
cursurile de instruire stabilite, dar vor oferi un sprijin prețios în perioada imediat
următoare startului productiv.

3.3.3.3. Planificarea instruirii

Această activitate configurează modul de desfăşurare a instruirii, stabilind
următoarele:
– tipuri – delimitarea clară între instruirea echipei de proiect şi a
administratorilor de sistem, care trebuie să acopere o tematică largă într‐un timp
relativ scurt, deci o curbă de învățare abruptă şi instruirea managerilor şi a
utilizatorilor finali, care se derulează pe o perioadă mai lungă de timp, în etape,
având o curbă a învățării mai lină;
– instructorii – se vor forma două categorii de instructori (traineri în
limbajul proiectelor IT): consultanții furnizorului şi acei membri ai proiectului care,
după ce parcurg anumite faze de instruire, devin ei înşişi instructori pentru ceilalți
utilizatori;
– cine – se desemnează audiența, urmărind, pe lângă nominalizare, şi
descrierea lor: care este nivelul lor de educație IT, ce abilități de utilizare a
calculatorului şi programelor de gestiune au, care le sunt capabilitățile de învățare,
dacă există cerințe speciale etc.;
– unde – se poate organiza la sediul firmei sau la furnizor (ori o locație terță,
amenajată în acest scop). În practică, datorită costurilor reduse, se preferă instruirea
la sediul firmei; problema este distragerea atenției, care se reflectă direct în
rezultatul instruirii. Dacă se optează pentru celelalte variante, trebuie luate în calcul
costurile de deplasare;
– resurse (infrastructura) – se stabileşte disponibilitatea pe tipuri de
resurse, atunci când instruirea are loc la firmă: calculatoarele şi alte echipamente
necesare, infrastructura de rețea (internet), tablă, flip‐chart, video‐proiector, smart‐
board;
– resurse (materiale) – se definesc materialele de curs, care pot fi prezentări
proiectate sau listate, documentații de proces şi/sau scenarii predefinite (pe hârtie
sau pe suport electronic);
– cursuri – se definesc structura şi conținutul cursurilor, fără a intra în
detalii. Scopul este stabilirea tuturor temelor de prezentat pentru a le putea organiza
în cursuri sau sesiuni de instruire;
– timp – se calculează necesarul de timp pentru desfăşurarea planului de
instruire propus şi se compară cu timpul disponibil. Atenție! Recalcularea timpului
alocat în funcție de disponibil în sensul reducerii poate afecta succesul instruirii şi
influența negativ finalitatea implementării;
– metode – se au în vedere cele mai bune abordări pentru a obține rezultatele
dorite. Având în vedere că scopul principal este deprinderea utilizării aplicațiilor,
metoda de instruire este bazată în principal pe utilizarea unei stații de lucru echipate
corespunzător. Prezentările proiectate ori demonstrațiile sunt trebuincioase până la
un punct, cea mai bună metodă de învățare este „văzând şi făcând”. Nu trebuie omise
exercițiile, jocurile şi, mai mult, testele, deoarece acestea din urmă confirmă atingerea
scopului, evidențiind eventualele aspecte neclare. De asemenea, trebuie analizată
oportunitatea lucrului în echipe versus lucrul individual, întrucât ambele pot fi
utilizate cu succes.

3.3.3.4. Bugetul instruirii

În bugetul elaborat sunt incluse cheltuielile asociate cu:
– instruirea propriu‐zisă, care include costul pentru fiecare curs, dat de
tariful/oră, cheltuielile de deplasare ale instructorilor, eventual cazare şi masă;
– materialele de curs;
– infrastructura necesară (dacă nu este disponibilă la sediul firmei);
– personalul de suplinire a lipsei de la locul de muncă a celor care
beneficiază de instruire;
– băuturi răcoritoare etc.
În multe situații din practica implementărilor ERP nu se întocmeşte un buget
al instruirii, deoarece se negociază includerea costurilor aferente acestei activități în
costul total al proiectului. Aspectul nefavorabil constă în minimizarea importanței
acestei activități şi desfăşurarea ei fără o planificare coerentă. Aparentele economii
din nebugetarea instruirii se dovedesc false, întrucât utilizatorii neinstruiți pot
genera cheltuieli mai mari decât cele care ar fi trebuit alocate instruirii lor.
Conform recomandărilor Gartner18, bugetul instruirii ar trebui să
reprezinte 10% din totalul bugetului proiectului. Deşi pare o cifră mare, analiza
pieței cursurilor de formare ne arată că nu este aşa. Dimpotrivă, subdimensionarea
ori reducerea acestor cheltuieli se va întoarce împotriva firmei.

3.3.3.5. Evaluarea instruirii

Dat fiind că susținem ideea alocării de resurse pentru instruire, dorim să
subliniem şi importanța evaluării acestei activități, în sensul atingerii obiectivelor
propuse. Au devenit persoanele instruite utilizatori competenți ai sistemului? Au
înțeles ei nu doar cum să facă, ci şi de ce să facă acel ceva? Evaluarea instruirii, într‐o
formă sau alta, trebuie realizată.

18 Gartner Group, Training: The underestimated ERP project requirement, Research Note SPA‐345‐1337,
publicată de Gartner Inc., 1997.

Testarea transferului de cunoaştere la finele primei faze de instruire, la care
participă echipa proiectului, este relevantă deoarece o parte din persoanele instruite
devin în faza a doua instructori pentru utilizatorii finali.
Pentru nivelul operațional se poate solicita testarea participanților la sfârşitul
unei sesiuni de instruire, derulată practic, pe diferite operațiuni de realizat în noul
sistem. La nivelul managerilor se pot utiliza şi chestionare, cu niveluri diferite de
aprofundare, iar răspunsurile date să indice un anume nivel de competență în
cunoaşterea sistemului.
De asemenea, prezintă relevanță evaluarea sesiunilor de instruire din
perspectiva celor care învață. Prin completarea unor formulare de evaluare, ei pot
evidenția aspecte negative, care pot fi corectate în următoarele sesiuni de instruire.

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ă 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, transpu‐
nerea 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:
Ce doresc să realizeze?
Care este cea mai bună cale de realizare?
Vor să facă lucrurile în acelaşi mod în care le‐au făcut până acum? Dacă da,
de ce?
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 bug19‐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 găsirea unor 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‐urile20 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 dintre 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.
Î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, niciuna 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

19 Un bug este un termen uzitat în comunitatea programatorilor, care descrie o eroare, o greşeală într‐un
program care produce un rezultat greşit sau neaşteptat sau determină un comportament anormal al
programului (cum ar fi blocarea sau părăsirea bruscă, neintenționată, a acestuia). Dacă cercetăm
etimologia acestui termen, se pare că la începuturile informaticii a existat într‐adevăr o insectă (bug, în
engleză) captivă într‐un calculator, care ar fi blocat funcționarea acestuia.
20 Termenul upgrade a fost de asemenea preluat ca atare în domeniul proiectelor IT. În domeniul
software el se referă la înlocuirea unui produs cu o versiune nouă a acestuia, de regulă mai bună,
menită să actualizeze sistemul ori să‐l îmbunătățească.

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:
descrierea modificării;
justificarea modificării;
cine solicită şi cine aprobă modificarea (trebuie să fie două persoane
diferite);
costurile modificării;
beneficiile anticipate;
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. Migrarea datelor

Datele reprezintă „materia primă” a oricărui sistem informațional; ele sunt
peste tot, stocate pe harddiskuri, pe CD‐uri ori stick‐uri de memorie şi chiar pe
suport de hârtie. Ele sunt valoroase deoarece prin preluarea şi prelucrarea lor se
obțin informațiile, iar acestea, la rândul lor, sunt suportul principal în luarea
deciziilor. Indiferent cât de performante şi sofisticate sunt programele de prelucrare
a datelor, rezultatele vor fi nule atunci când datele sunt incorecte (celebrul principiu
„garbage‐in, garbage‐out”).
La momentul implementării unui sistem integrat toate datele din sistemul
vechi trebuie preluate corect, fără erori. Dificultatea vine din faptul că nu se
realizează o simplă copiere, ci este o operațiune de import. De succesul acestei
operațiuni depinde integritatea noului sistem şi funcționarea sa impecabilă, aşa cum
şi‐ar dori orice organizație. Câteva date greşite într‐un sistem ERP nu înseamnă o
singură eroare funcțională, ci propagarea erorii în toate modulele funcționale
conectate. Mai mult decât atât, este posibil ca eroarea să treacă neobservată până la
producerea ulterioară a unui eveniment, cum ar fi închiderea de lună. O consecință
nefastă a preluării greşite de date este şi scăderea încrederii în noul sistem şi
recurgerea la credinciosul şi de‐acum clasicul Excel pentru a realiza diverse
prelucrări.
Există două metode fundamentale de realizare a importului de date: manuală
şi automată. Metoda manuală are dezavantajul de a fi consumatoare de timp şi efort
şi nu garantează corectitudinea (datele sunt verificate înainte de a fi introduse, dar
erorile pot apărea tocmai la introducerea manuală). Metoda automată este clar mai
rapidă şi fără erori de preluare şi este singura convenabilă pentru volume mari de
date.
În realitate, sunt mai multe aspecte de luat în considerare pentru a alege o
metodă sau alta. Primul este legat de formatul în care sunt stocate datele în vechiul
sistem – dacă acesta nu este compatibil cu cel nou, importul direct nu este tehnic
posibil. În al doilea rând, sunt rare cazurile în care datele se preiau ca atare, ele sunt
supuse conversiilor sau reformatării, ori trebuie completate cu noi câmpuri adiționale.
De aceea migrarea datelor este un proces complex, iar metoda este adesea una mixtă.
Reuşita acestei activități contribuie şi ea la succesul proiectului, de aceea trebuie
planificată şi monitorizată cu atenție, urmărind să se finalizeze la timp. Problemele
care trebuie discutate în faza de planificare a migrării datelor includ:
definirea tuturor datelor necesare în noul sistem, identificarea lor în
vechiul sistem, stabilirea posibilității de import automat;
identificarea datelor care nu există în vechiul sistem şi a posibilelor surse
de preluare, stabilirea metodei de import;
clasificarea datelor în statice (nomenclatoarele de toate tipurile) şi
dinamice (datele din tranzacții) şi planificarea preluării în funcție de aceasta (dacă
datele din nomenclatoare se pot prelua în timp, cele tranzacționale trebuie
transferate după ce se încheie utilizarea vechiului sistem);
planificarea resurselor şi a timpului pentru desfăşurarea importului;
stabilirea unei metode de validare a datelor preluate, pentru a proba
corectitudinea lor.
Această activitate este practic realizată de specialiştii furnizorului; experiența
acestora din implementările anterioare este capitală. Cunoscând importanța acestei
activități, unii furnizori preferă să nu rişte şi subcontractează unei terțe firme. În
multe cazuri se apelează la prietenosul format Excel – datele se exportă din vechiul
sistem în format .xls şi se importă cu uşurință în noul sistem. Această metodă
permite şi desfăşurarea unor proceduri de validare a datelor înainte de a le prelua în
sistemul nou.

3.7. 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.7.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 apărea, 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ă specialiştilor
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.

3.7.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 şase săptămâni
sau la două 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 princi‐
palele probleme întâmpinate în legătură cu acestea?
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 premisele 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.8. Î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 zece ani în anii ’90 la cinci ani în
prezent. Ceea ce nu înseamnă totuşi că după cinci 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.
Î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 fațetelor organizației.


CAPITOLUL 4
Cultura integrării şi mediul organizaţional

& identificaţi consecinţele integrării informaţionale în organizaţii;
& înţelegeţi relaţia cultură organizaţionalătehnologii informaţionale;
& identificaţi transformările organizaţionale datorate implementării
pachetelor integrate de tip ERP;
& recunoaşteţi transformările culturale şi profesionale din mediul
organizaţional;
& recunoaşteţi simptomele rezistenţei organizaţionale şi individuale la
schimbare;
& cunoaşteţi câteva metode manageriale pentru realizarea
managementului schimbării;
& aveţi cunoştinţe despre metodele de stimulare a creativităţii
personalului.

4.1. Integrarea informaţională în organizaţii şi consecinţele
acesteia

În ultimele decenii, investițiile în noile tehnologii informaționale (NTI) au
marcat profund viața organizațiilor, dincolo de diferențele mari în ceea ce priveşte
gradul de informatizare a fiecărei organizații în parte. Deşi proliferarea investițiilor
în NTI nu a avut, pe termen scurt şi mediu, efectele scontate legate de performanța
financiară şi organizațională, trendul acestora rămâne ascendent, iar preocuparea
pentru dezvoltarea şi implementarea de noi tehnologii rămâne asociată imaginii de
„vârf de lance” în aproape orice domeniu.

Relaţia „investiții în NTI–performanțe obținute” este comprimată în celebrul paradox al
productivităţii (paradoxul lui Solow): „Putem vedea era calculatoarelor peste tot, cu
excepţia statisticilor asupra productivităţii”. Solow1 contrazice presupunerea că utilizarea
pe scară largă a calculatoarelor va influenţa direct şi radical productivitatea.
Cercetările au demonstrat că, deşi tehnologia este unul dintre cei mai importanţi factori care
influenţează productivitatea şi că, cel puţin teoretic, toate ţările au acces egal la inovaţia
tehnologică, de fapt, productivitatea este influenţată de mulţi alţi factori precum
acumularea de capital fizic şi uman, infrastructura, structura pieţei, evoluţiile demografice,
gradul de concurenţă etc. NTI au schimbat în mod radical domeniul afacerilor, implicit
cultura organizaţională, însă această schimbare nu poate fi echivalată cu eficienţă sporită
sau cu un spor de bunăstare. Astăzi se vorbeşte peste tot despre integrare informaţională, în
consecinţă putem vorbi şi despre o cultură a integrării.
Din considerente legate de complexitatea temei şi de limitarea unghiului de vedere asupra
relaţiei culturăsocietatetehnologii informaţionalecultură organizaţională ne vom referi
mai mult la integrarea informaţională şi la incidenţa acesteia asupra mediului
organizaţional.

Integrarea informaţională este deci mai mult decât obligatorie în secolul
XXI pentru afacerile care vor să reziste pe piaţă! Definirea relațiilor de
cauzalitate dintre cultura organizațională şi tehnologie, pe de o parte, şi impactul lor
asupra performanței, pe de altă parte, şi verificarea practică a acestor definiri şi
determinări au rămas pe terenul disputelor şi speculațiilor. Specialişti din domeniul
tehnologiei informaționale consideră că organizațiile n‐au reuşit deocamdată să
dezvolte o cultură care să exploateze la nivel maxim oportunitățile oferite de aceste
tehnologii. Atunci când analizăm impactul tehnologiilor informaționale nu trebuie să
facem abstracție de faptul că este destul de dificil să realizăm o evaluare obiectivă a

1 J.W. Orlikowski, Learning from Notes: Organisational Issues in Groupware Implementation, 1992 citat
în M. Danileț, D. Fotache, „Transforming Organisational Culture through the Impact of Information
Integration”, în volumul Informatics in Knowledge Society. The Proceedings of the Eigth International
Conference in Informatics in Economy, Editura ASE, Bucureşti, 2007.
Cultura integrării şi mediul organizaţional 153
acestuia, atâta timp cât suntem deja afectați de societatea în care trăim şi de
tehnologia pe care o studiem.
Integrarea completă este un obiectiv major al managementului resurselor
informaționale, din ce în ce mai complexe şi numeroase. Aplicațiile şi datele sunt
combinate în entități integrate care asigură nu numai accesul la informații, ci şi
gestiunea proceselor economice. Supusă presiunilor mediului economic, dar mai ales
celor tehnologice, organizația de astăzi trebuie să se lupte şi cu sarcinile complexe,
scumpe şi mari consumatoare de muncă ale integrării sistemelor. Şi aceasta pentru că,
din nefericire, sistemele informaționale au tendința de a acumula mereu noi
componente, în loc să le înlocuiască pe cele vechi. Derularea unui proiect de integrare
informațională, fie că se referă la procese de afaceri, fie la relații interne, reprezintă o
adevărată provocare tehnologică, deoarece un astfel de mediu trebuie să asigure o
gamă largă de funcționalități, prin numeroase instrumente şi componente de
integrare. Ideal este ca proiectarea şi configurarea sistemelor informatice să ofere
suport utilizatorilor şi săi ajute în muncă, nu să le complice modul de realizare a
sarcinilor de lucru, iar acest proces constituie o adevărată artă. Această artă poate fi
recunoscută cu uşurință în oferta marilor case producătoare de software.
Dincolo de aceste considerente generale, la modul concret, putem discuta
despre mai multe niveluri de integrare informațională. Figura 4.1 reconstituie patru
niveluri cu avantaje şi consecințe indiscutabile.
Sintetizăm consecinţele integrării informaţionale prin afirmațiile următoare:
conturarea unei noi culturi în cadrul organizației;
reorganizarea şi reconfigurarea proceselor de afaceri conferă flexibilitate şi
adaptabilitate în afaceri;
posibilitatea de a face față în timp util presiunilor concurenței;
schimbarea trebuie privită ca un proces de adaptare şi evoluție pentru
fiecare angajat în parte, deoarece afectează întreg mediul organizațional.
Secolul XXI prefigurează o economie bazată pe cunoştințe. Oamenii şi
cunoştințele lor fac diferența în cursa competitivității. Valoarea produselor şi
serviciilor este dată de cantitatea de informații conținute de acestea şi de justețea
deciziilor luate în baza acestor informații. Fie că sunt informații despre necesitățile
actuale şi aspirațiile clienților, informații despre piață şi mediul macroeconomic,
informații despre competiție, informații despre noile tehnologii şi evoluțiile din alte
industrii, dar şi informații despre eficacitatea şi eficiența activităților interne,
înglobarea lor eficientă în produse şi servicii generează valoare adăugată. De vreme
ce cultura organizațională reprezintă credințele, valorile şi semnificațiile împărtă‐
şite, atunci ea are o componentă informațională importantă şi beneficiază de
suportul tehnologiilor informaționale, iar contextul globalizării sporeşte în fiecare zi
importanța acestui suport tehnologic.

Obiective Consecinţe
• Apropierea electronică a • Dezvoltarea unui mediu
personalului pentru colaborativ şi suport pentru
Nivelul 1 realizarea obiectivelor învățarea continuă
Integrare • Reproiectarea organizațională • Interfață şi instrumente
informațională prin prin cuantificarea sarcinilor „prietenoase”, reducerea
tehnologii individuale şi definirea timpului de învățare
colaborative, sarcinilor colective • Creşterea eficienței angajaților
groupware • Integrarea echipelor • Controlul activităților şi mediu
disparate geografic, de lucru transparent
eliminarea limitelor impuse • Cunoaşterea comunității şi a
de distanțe pieții globale
• Coordonare globală şi
competitivitate sporită
• Costuri operaționale reduse • Disponibilitate continuă în
Nivelul 2 motivate de caracterul mediul de afaceri (24 de ore pe
Integrarea informa‐ deschis al arhitecturii zi, 7 zile pe săptămână)
țională prin tehnologii • Integrare flexibilă şi facilă cu • Flexibilitate în accesarea
de tip portal clienții şi furnizorii informațiilor
Enterprise Information • Securitate avansată datorată • Acces securizat la resurse
Portal conceptului singlesignon • Coerență informațională internă
şi externă
• Organizația urmăreşte • Viziune unică pentru întreaga
tranziția de la informații afacere, strategie de afaceri
Nivelul 3 partajate între aplicații, la corelată cu cerințele pieței
Integrarea internă a gestiunea fluxului • Sistem informațional coerent şi
proceselor informațional între module de unic
de afaceri aplicații ale unui pachet • Standardizarea şi automatizarea
Enterprise Resource integrat realizată în jurul unei proceselor din cadrul
Planning baze de date unice întreprinderii
• Gestiunea completă a • Creşterea eficienței şi
resurselor întreprinderii responsabilității angajaților,
posibilitatea implicării la nivel
decizional
• Investiții în calitatea
profesională a resurselor umane
• Afacerea este complet • Reducerea la minim a
Nivelul 4 transformată prin conectarea personalului implicat în activități
Integrarea proceselor directă a clienților şi de vânzări şi marketing datorată
de afaceri externe furnizorilor la sistemul magazinelor virtuale şi a
Customer Relationship operațional al firmei posibilității de interacționare
Management directă cu clienții
Supply Chain • Integrare Total Quality
Management Management şi Business Process
Management
Figura 4.1. Model de integrare informaţională în mediile organizaţionale actuale

4.2. Redefinirea culturii organizaţionale în noua economie

4.2.1. Cultura organizaţională

La nivel elementar, cultura organizațională poate fi definită prin
personalitatea organizaţiei. Cultura este cuprinsă între valorile, normele, etica,
arhiva emoţională, tradiţia, limbajul şi comportamentul membrilor unei organizaţii.
Cultura organizațională a devenit un termen de actualitate (a apărut mai întâi în
literatura de limbă engleză în anii ’60 şi a intrat în limbajul comun prin cartea lui
Peters şi Waterman, In Search of Excellence2). Cultura organizațională este acea
„programare mentală colectivă care deosebeşte membrii unei organizații de
membrii altei organizații”.
Deşi nu există o definiție standard a conceptului, majoritatea specialiştilor
recunosc următoarele caracteristici ale culturii organizaționale:
holistică – un tot este mai mult decât suma părților componente;
determinată istoric – reflectă evoluția organizației;
fundamentată din punct de vedere social – este creată şi păstrată de un
grup de oameni;
greu de modificat.

Figura 4.2. Cultura organizaţională

Într‐o abordare sistemică, în cultura organizațională sunt identificate:
intrările, care includ informațiile preluate din societate, profesiile angajate,
sistemul legislativ, servicii, dar şi poveşti, eroi, rezultate în competiții etc.;
procesele, care se bazează pe asumarea valorilor şi normelor
organizaționale, a valorilor financiare, a timpului, facilităților, spațiului şi a
personalului;
ieşirile sau efectele culturii, care sunt date de comportamente organizațio‐
nale, strategii, imagine, produse, servicii, angajamente etc.
În acest context, cultura integrării înseamnă:
calitate in toate procesele companiei, lucru făcut bine din prima, defecte
zero, risipă zero!;

2 T.J. Peters, R.H. Waterman, In Search of Excellence: Lessons from America’s Bestrun Companies, Harper,
New York, 1982.

îmbunătățirea continuă a calității bunurilor şi a serviciilor livrate cu

participare de la toate nivelurile, a tuturor funcțiunilor organizației;
toate procesele unei organizații, din fiecare fază a spiralei calității, sunt
corelate şi implicate în realizarea şi îmbunătățirea integrării informaționale;
îmbunătățirea continuă a proceselor şi a rezultatelor acestora.
Toate acestea se regăsesc în conceptul Total Quality Management (în
traducere exactă, managementul total al calității).

Una dintre cele mai importante inovaţii ale sfârşitului de secol XX este sistemul de management
numit managementul total al calităţii. În anii ’80, conceptul3 de Total Quality Management
(TQM) a fost pe buzele a numeroşi oameni de afaceri sau cercetători, care au căutat o nouă
metodă de îmbunătăţire continuă a produselor şi serviciilor.
TQM desemnează un mod de conducere a organizaţiei, centrat pe calitate, bazat pe
participarea tuturor membrilor acesteia şi care vizează un succes pe termen lung prin
satisfacerea clientului, precum şi avantaje pentru toţi membrii organizaţiei şi pentru
societate4. Baza TQM o reprezintă ameliorările continue: identificarea modalităţilor prin
care creşte satisfacţia beneficiarilor, calitatea produselor sau a serviciilor. Procesul se
desfăşoară prin evaluarea continuă a rezultatelor, astfel încât să se desprindă câştigurile
înregistrate dea lungul timpului.
Dezvoltat iniţial în Japonia, în anii ’80, conceptul a fost adoptat în SUA şi în Europa de Vest.
Interesate au fost în special companiile care trebuiau să reziste concurenţei puternice de pe
piaţa internaţională (companiile britanice: Unilever, British Airways, Jaguar etc.; compania
americană IBM). Premiile de calitate acordate firmelor performante în statele capitaliste
dezvoltate (premiul Baldridge în SUA, premiul Deming în Japonia, premiul pentru calitate în
UE, premiile de excelenţă pentru menţinerea calităţii la nivel de top peste cinci ani în
Japonia) constituie un puternic stimulent pentru perfecţionarea sistemului de realizare şi
asigurare a calităţii în firme.
TQM este un mod nou organizaţional bazat pe mecanisme de coordonare cooperativă care
sporeşte eficienţa firmei prin ameliorarea calităţii produselor şi serviciilor. Coordonarea
cooperativă se bazează pe interesele convergente ale tuturor partenerilor întreprinderii.
Caracteristicile specifice unei firmei şi ale mediului în care aceasta îşi desfăşoară activitatea
favorizează dezvoltarea TQM şi demonstrează că beneficiile induse de performanţă sunt
superioare costului implementării sale. Productivitatea şi calitatea devin filtrele viabilităţii
întreprinderilor. Organizarea priveşte structuri flexibile de tip matricial sau reţea, iar
controlul este orientat pe proces şi nu pe produs, prin standardizarea sistemelor de
fabricaţie şi a procedurilor de lucru în cadrul sistemelor de asigurare a calităţii.
Teoria managementului total al calităţii5 priveşte organizaţia ca un set de procese cu furnizori
şi clienţi interni şi externi orientate spre îndeplinirea cererilor clienţilor externi.
Formula propusă de TQM constă în înglobarea calităţii în etapele primare şi nu în activităţile
finale de inspectare, control sau de asigurare a calităţii. Filosofia de bază a teoriei este

3 D. Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi, 1999,
p. 500.
4 Managementul calităţii şi asigurarea calităţii. Vocabular, Specificații ISO 8402: 1995, citat în
http://ro.wikipedia.org/wiki/TQM
5 D.W. Rees, Arta managementului, Editura Tehnică, Bucureşti, 1996, pp. 57‐58.
preventivă şi nu curativă: înglobarea calităţii în produs/serviciu şi nu corectarea defectelor
după ce acestea au apărut deja. În aceste condiţii, importanţa acordată consumatorului
este covârşitoare.
Avantajele potenţiale ale TQM includ creşterea veniturilor, mărirea pieţei şi reducerea
cheltuielilor generate de activităţile de control şi remediere. Avantajele sunt obţinute numai
dacă se adoptă măsuri corespunzătoare în plan investiţional şi organizatoric. Condiţiile
cheie ale succesului în acest domeniu sunt următoarele:
implicarea hotărâtă a topmanagementului;
accentul puternic pus pe comunicarea cu resursa umană proprie;
îmbunătăţirea şi restructurarea comunicării şi cooperării în plan orizontal între
compartimente;
mecanisme solide de implicare a angajaţilor;
sprijinul şi asistenţa corespunzătoare oferite angajaţilor;
identificarea standardelor de calitate specifice;
formularea unui program pentru îndeplinirea tuturor obiectivelor firmei;
dezvoltarea unor aptitudini specifice domeniului relaţiilor cu publicul etc.
Întreţinerea calităţii ridicate (standardizarea) este posibilă numai prin schimbarea
mentalităţii. Calitatea de vârf, excelenţa, sau a produce la nivel mondial, înseamnă de fapt a
produce mai bine, mai repede, mai ieftin şi împreună (participare, inclusiv a clientului şi
furnizorului), pentru a se asigura încântarea clientului, deci mai mult decât doar satisfacţia
sa prin funcţiile produsului şi preţ.

4.2.2. NTI – catalizatorul schimbărilor organizaţionale

În secolul XXI învățarea organizațională şi modificarea esențială a relației om‐
muncă sunt în strânsă corespondență cu avantajele adoptării noilor tehnologii
informaționale (NTI):
NTI favorizează dezvoltarea socială prin îmbunătățirea sentimentului de
valoare personală, echipele sunt structurate în funcție de competențe
pluridisciplinare (şi nu pe ierarhie), iar întreprinderea‐rețea devine realitate;
NTI facilitează procesul de învățare colectivă, ameliorează performanțele şi
expertizele individuale şi de grup, stimulează reactivitatea şi inovarea, participă la
formarea organizației care învață;
NTI îmbunătățesc organizarea firmei prin desfăşurarea unor procese
transversale generate de relația comunicare‐coordonare‐cooperare: calitatea
clientului, performanțele şi competitivitatea firmei.
NTI facilitează partajarea informațiilor şi optimizează fluxurile informaționale
sau de cunoştințe. Datorită lor au apărut forme de management bazate pe
cunoaştere şi inteligență colectivă (excelența în afaceri, sistemul de management
prin obiective, managementul total al calității, reengineering‐ul etc.). Evoluția a fost
posibilă datorită:
tehnologiilor pentru integrarea informațională şi gestiunea integrată a
organizațiilor: platforme groupware, aplicații de tip portal;
apariției unui set de noi concepte: capitalizarea, managementul şi gestiunea
strategică a cunoştințelor, inteligența colectivă, întreprinderea care învață,
managementul cunoştințelor;

dezvoltării unor instrumente specifice: knowledge resource center, rețele de
competență, managementul pe proiecte etc.
Deşi NTI sprijină alinierea întreprinderilor şi a clienților dispersați geografic,
ele creează în acelaşi timp şi probleme pe care organizațiile care doresc să treacă la
„economia virtuală” trebuie să le rezolve. Spre exemplu, comerțul electronic permite
unei firme să ajungă la orice altă firmă sau client din lume. Obținerea acestui avantaj
a fost posibilă după rezolvarea problemelor legate de conceperea site‐ului web, de
integrarea sistemelor de securitate aferente plăților electronice şi partajului
informațional.
În noul context socioeconomic de mobilitate şi interdependență, o întreprindere
care se doreşte competitivă trebuie să‐şi regândească organizarea, să‐şi mobilizeze
competențele umane şi să‐şi redefinească strategiile. Celor trei unități de loc, de timp
şi de acțiune li se substituie organizaţiile în reţea, cu procese care traversează toate
structurile, desincronizează activitățile, dematerializează schimburile, oferind un plus
de autonomie actorilor.
Caracteristicile şi condiţiile de funcţionare ale organizaţiei în reţea pot fi
rezumate în două idei principale:
1) organizația se defineşte în raport cu finalitățile, proiectele sale şi prin
raportare la structurile pe care le deține. Dacă este partajată prin actori, finalitatea
organizației devine un factor integrator mai puternic decât capacitatea sa
operațională. Adeziunea individului la organizația în rețea se face prin partajarea
proiectului şi a comunității de interese;
2) pilotarea organizației abandonează vechile formalisme pentru apropierea a
doi factori structuranți: proiectul, care este motorul de acțiune şi de convergență
între actori, şi metodologiile care asigură coerența acțiunii. Prin urmare, cunoaşterea
şi inteligența nu mai sunt centralizate, ci sunt distribuite pe ansamblul organizației.
Mai mult, fluiditatea schimburilor informaționale şi de cunoştințe sporeşte şi se
creează un limbaj şi o cultură comune.
O altă dezvoltare în organizație, din ce în ce mai vizibilă în ultimul timp, este
apariția unor structuri tot mai aplatizate în care angajații capătă puteri sporite. Noi
tipuri de organizații încep să apară, după cum arăta Charles Handy6, unul dintre cei
mai importanți şi influenți gânditori în business: „Apariţia noilor tipuri de organizaţii
a devenit o schimbare perceptibilă despre care se vorbeşte tot mai mult. Organizaţiile
vor fi percepute ca fragmente gigantice de inginerie, cu mari colective umane
interşanjabile. Astăzi se discută tot mai mult despre cultură şi reţele, echipe şi coaliţii,
influenţă şi putere, chiar mai mult decât control sau leadership.”
„Motorul” organizației clasice, bazat pe articularea mijloacelor, este înlocuit cu
cel bazat pe competențe şi cunoştințe. Capitalizarea cunoaşterii are toate
caracteristicile unui proces de transformare a informațiilor, cunoştințelor şi ideilor
în experiență, reguli şi metodologii. Rezultatul constituie un câştig pentru modelele
de acțiune viitoare.

6 C. Handy, Pelerina goală. O gândire pentru o lume nouă, Editura CODECS, Bucureşti, 2007.
Contrar principiilor tradițional admise de organizațiile industriale, nevoile,

metodele şi instrumentele de lucru nu pot fi definite în avans în cazul organizației
bazate pe cunoaştere. Organizația trebuie să fie capabilă să producă unele cunoştințe
şi să‐şi mobilizeze inteligența în mod permanent, să răspundă competitiv în fața
problemelor noi şi imprevizibile care pot apărea. Aceste obiective pot fi atinse numai
prin procesul de învățare organizațională.
În cadrul organizației, mediul de lucru şi, implicit, cultura organizațională vor
suferi transformări importante. Tehnologia oferă angajaților suport pentru
valorificarea creativității, posibilități de ierarhizare a volumului informațional şi de
creare a unor rețele, atât personale, cât şi de afaceri. Important este ca aceştia să
înțeleagă beneficiile noului sistem şi să accepte schimbarea cu profesionalism.
Managementul schimbării este o parte importantă a proiectelor de implementare a
noilor tehnologii informaționale.

4.2.3. Relaţia cultură organizaţionalătehnologii informaţionale

În mass‐media, tehnologiile informaționale sunt prezentate ca simple
instrumente, chiar şi atunci când reprezintă combinații complexe de echipamente
variate, reguli‐roluri‐resurse şi practici reale şi organizaționale, cum este cazul
pachetelor de integrare informațională. În opinia noastră, ele ar trebui privite ca
sisteme7 tehnico‐sociale, sisteme complexe, interdependente, care cuprind:
oamenii care interacționează cu diverse platforme informatice, îndeplinesc
roluri, angajează relații profesionale şi‐şi desfăşoară activitatea potrivit culturii
organizaționale proprii firmei;
echipamente (calculatoare, rețele de calculatoare, periferice);
platforme software (aplicații de bază, platforme pentru rețele, aplicații de
tip portal, pachete de gestiune a afacerii, de management al relațiilor cu clienții,
platforme pentru e‐commerce şi e‐business etc.);
modele de management modern – schimbările rapide din domeniul
tehnologiei au avut un impact deosebit în gestiunea afacerilor. Managerii, cunoscând
aşteptările clientelei, cercetează care sunt ambițiile personalului firmei şi
favorizează elaborarea unor noi structuri organizaționale, capabile să dezvolte
responsabilitatea şi inițiativa şi să lărgească aria individuală de competențe;
resursesuport – aşa‐numitele organizații „care învață” trebuie să‐şi
adapteze stilul de management numeroaselor remanieri structurale, prin evoluția
către o formă de coaliție orizontală sau o structură transversală a organizației.
Învățarea organizațională se dezvoltă „în şi prin” schimburi informaționale între
salariații întreprinderii, independent de nivelul lor ierarhic sau de funcția pe care o
ocupă;
structuri informaţionale – conținut, reguli şi norme, integrare şi integritate
informațională, controlul accesului şi securitatea sistemului informațional;

7 D. Fotache, M. Danileț, op. cit.

inovare continuă – tehnologia oferă angajaților suport pentru valorificarea
creativității, oferă posibilități de selectare şi interpretare a volumului exploziv de
date, permite crearea rețelelor informaționale profesionale şi de afaceri. Integrarea
informațională oferă coerență analizelor, asigură un suport real procesului
decizional, susține succesul în contextul globalizării afacerilor.
Enumerarea anterioară duce cu gândul mai curând către un „model
sociotehnic”, capabil să genereze cel puțin performanțele aşteptate odată cu
investițiile în NTI. În fapt, aceste elemente nu sunt configurate la modul „ideal
proiectat”, sunt mereu interconectate într‐o matrice de interdependențe sociale şi
tehnice, iar efectele generate sunt adesea imprevizibile.
Aşa cum precizam în debutul acestui capitol, definirea relațiilor de cauzalitate
între cultura organizațională şi tehnologie, a impactului lor asupra performanței,
validarea practică a acestor definiri şi determinări sunt încă puternic disputate. În
practică, cele două concepte „cultură organizaţională” şi „performanţă”, sunt dificil
de definit şi descris de o manieră coerentă. Cultura şi performanța funcționează ca
procese în care „nu este totul observat şi nu este totul observabil”.
Tehnologia, mai permisivă când vine vremea observațiilor şi măsurătorilor
din punctul de vedere al valorii investițiilor, suscită dispute 8 şi speculații similare în
contextul mai larg al impactului asupra productivității, asupra performanței
organizaționale şi asupra „bunelor practici” dintr‐o organizație.
Se observă imediat că infrastructura tehnologică vine cu o raționalitate
diferită de raționalitatea limbajelor umane şi, de aceea, oricât de perfecționată ar fi,
ea nu poate îmbunătăți, direct, practicile de comunicare. Semnificațiile, deci
mesajele, sunt create de oameni, şi nu de maşini. Ele pot crea doar oportunități de
comunicare, nu neapărat o comunicare mai bună; oportunități pentru creşterea
performanței, nu neapărat o performanță sporită. Paradoxul lui Solow, menționat
deja, confirmă acest lucru prin trimiterea la datele furnizate de statisticile din SUA.
Mai mult decât atât, dacă tehnologia este relativ sigură şi previzibilă, oamenii
sunt schimbători, imprevizibili în esența lor, capabili de reacții neprogramate, iar
comunicarea dintre ei, mediată sau nu de mijloace artificiale, îşi păstrează caracterul
„autogenerator”, „autospecific”, conform modelului unic de interacțiune dintre
participanți.
Dacă revenim la oportunitățile oferite de investițiile în NTI şi la evoluția
caracteristicilor culturale ale diverselor grupuri (de la națiuni, până la organizații
sau chiar până la gaşca de pe stradă), vom remarca o mai accentuată „contaminare
culturală”, o exacerbare a procesului de uniformizare a valorilor, a credințelor, a
preferințelor şi a comportamentelor.
În acelaşi timp însă, creşte şi instabilitatea acestor caracteristici culturale. De
la o vreme, cultura pare să aibă mai multe în comun cu moda decât cu tradiția
durabilă. Instabilitatea ei creşte pe măsură ce valorile sunt preluate mai degrabă
prin ecranul televizorului sau monitorului decât prin modelele în carne şi oase. Este

8 S. Chirică, Psihologie organizaţională. Modele de diagnoză şi intervenţie, Casa de Editură şi Consultanță
„Studiul Organizării”, Bucureşti, 1996.
mult mai uşor şi mult mai puțin riscant să trădezi televizorul sau calculatorul, decât
să‐ți trădezi părinții, prietenii sau mentorii.
„Amenințările” induse de NTI, adică reversul medaliei în dezvoltarea umană,
includ depersonalizarea (prin standardizare şi neimplicare), diminuarea capacității
de relaționare directă, degenerarea simțurilor, creşterea agresivității (este ştiut deja
că, psihologic, poți ucide mai uşor prin apăsarea unui buton, fără să‐ți vezi victima,
decât atunci când se află în fața ta), bulimia informațională, minciuna (cele mai
multe minciuni credibile se spun la telefon şi pe internet), retragerea în anonimat.
O selecție de definiții date culturii şi elementelor care o compun ar depăşi cu
mult spațiul pe care îl putem aloca subiectului, de aceea reținem principalele zone
de atenție pentru descoperirea culturii:
zona stărilor mentale, ce reflectă diferențele culturale prin diferențele de
manipulare a registrului senzorial (unii suntem mai sensibili la culoare, alții, la
sunete, alții, la mirosuri etc.; pe unii frigul îi omoară, pe alții abia îi provoacă);
zona comportamentelor cotidiene: obiceiurile, ritualurile de fiecare zi,
gesturile „mici” sunt primele indicii folosite pentru „caracterizarea” culturală;
zona aşazisului savoirfaire: calitatea, filosofia meşteşugurilor, a meseriilor,
capacitatea de a asimila noi tehnologii, grija pentru lucrul bine făcut (sau lipsa ei),
maniera de comunicare cu celălalt instaurează deja primele contururi culturale;
zona produselor, ca rezultate ale zonei precedente: arhitectura casei,
dispunerea străzii, linia maşinii, statuia ridicată în piață, grădina pot marca „granițe”
culturale;
zona instituţiilor şi a modurilor de organizare colectivă: structura
instituțiilor publice şi private, calitatea oamenilor care activează în această zonă,
răspunsurile pe care le poți primi în această zonă, mirosurile care te întâmpină la
intrare îți pot spune foarte clar unde te afli.
Evoluția NTI a depăşit însă mai toate previziunile secolului trecut. A ajuns
suficient de departe pentru a ne influența preferințele senzoriale (câte ore petrecem
în fața calculatorului?), pentru a schimba comportamentele cotidiene (care este
raportul dintre numărul saluturilor prin strângerea mâinilor şi numărul saluturilor
pe monitor?), pentru a transforma asimilarea de noi tehnologii într‐o provocare
aproape perpetuă. Zona „produselor” şi „modurile de organizare colectivă” aproape
că nu pot fi disociate de modelele create în zona NTI.
Cu toate astea, relația cauză‐efect între cultura organizațională şi NTI rămâne
sub semnul întrebărilor. Potrivit literaturii de specialitate 9, putem enumera câteva
dintre posibilele cauze ale eşecurilor în schimbarea culturii organizaționale:
organizațiile repetă structura familială şi practicile comportamentale ale
culturii în care sunt integrate;
„narcisismul” grupului intern, împărțirea în „noi” şi „ei” până la „noi contra
lor” sunt constante ale ființelor umane (şi ale altor animale);

9 H. Levinson, Diagnosis for organizational change. Methods and models, Guilford, New York, 1994,
pp. 27‐52.

organizațiile sunt, prin definiție, organisme vii. Prin urmare, au etape de
dezvoltare şi evoluează conform unor modele de adaptare care au de‐a face cu
diferite niveluri de complexitate;
toate organismele vii parcurg un proces continuu de schimbare, atât în
interiorul lor, cât şi în cadrul mediului în care îşi desfăşoară activitatea;
toate grupurile urmează un conducător. Grupuri diferite, în momente
diferite, necesită stiluri diverse de conducere, dar politicile, practicile şi structura
organizațională ale conducătorului fondator sunt adesea cele mai rezistente în timp.
Schimbarea culturii organizaționale odată cu introducerea NTI întâmpină
aceleaşi obstacole. Dacă schimbarea are loc în sensul succesului sau dacă va duce la
eşec depinde de armonizarea considerațiilor tehnologice cu cele sociale.

4.3. Transformările organizaţionale. Rolul managementului
schimbării

Mediile organizaționale au în structura lor cinci componente majore:
structura şi cultura organizaţională, strategia, procesele afacerii, rolurile
individuale şi tehnologiile informaţionale. Mediul extern, compus din factori
sociali, economici şi forțe politice, influențează şi el organizația. Dacă mediul extern
nu‐şi schimbă structura, echilibrul lui nu influențează stabilitatea mediului
organizațional; dacă acesta este însă instabil, mediul organizațional va avea de
suferit.
Modificarea strategiei de afaceri provoacă schimbarea structurii organiza‐
ționale. Componentele interne interacționează şi sunt dependente unele de altele.
Organizațiile instabile trebuie să calculeze supraviețuirea şi nu pot să ignore
destabilizarea componentelor. În acest scop, elaborează strategii pe termen lung
care au în vedere atât rutina zilnică, precum şi activitățile critice şi analiza acestora.
Companiile sunt forțate să‐şi adapteze modelul de generare a ofertei, de
lansare de noi produse şi servicii pe piață. În contextul actual de globalizare a
afacerilor, producătorii nu mai urmăresc în primul rând vânzarea produsului ori
serviciului, ci satisfacerea cerințelor clienților şi consumatorilor. În acelaşi timp,
modificarea modelului de afaceri este determinată de înființarea aşa‐numitelor
rețele de confederații ale jucătorilor din lanțul de distribuție, care înlocuiesc
modelul lanțului de distribuție liniar. O altă mutație se produce prin schimbarea
accentului de pe calitate şi valoare adăugată asupra practicilor de consultanță şi
ofertei de servicii.
Impactul implementării aplicaţiilor Enterprise Resource Planning asupra
mediului organizaţional poate fi comparat cu cel al unui seism, schimbările în modul
de desfăşurare a activităţii şi cele care ţin de organizarea întreprinderii constituind un
motiv important de panică al firmelor care demarează astfel de proiecte. Un alt aspect
care‐i surprinde pe manageri are în vedere durata acestui angajament, care nu se
încheie la finalizarea proiectului ERP propus. Dacă simpla adoptare a unui pachet
integrat pare a fi soluția tuturor problemelor la început, mai târziu se dovedeşte a fi
doar un prim pas către crearea unei infrastructuri competitive, conectată în
permanență la tehnologiile informaționale. Sesizăm, de asemenea, trecerea de la
tactic la strategic, ca viziune globală asupra sistemului informațional „acoperit” prin
soluția ERP adoptată. Altfel spus, se produce inversarea structurii activității
întreprinderii. Dacă, tradițional, structura a fost verticală, transformarea se va
produce în sensul aplatizării ei – ea va deveni din ce în ce mai mult orizontală.
Activități care au fost organizate în interiorul organizației devin din ce în ce mai
transparente şi sunt rezolvate din exterior, pentru a satisface cerințele clienților.
În cadrul organizației, mediul de lucru suferă transformări importante. În
contextul actual, mediul organizaţional se va confrunta cu cel puţin unul dintre
următoarele tipuri de transformări: tehnologice; culturale – valori, opinii, credinţe; ale
proprietăţii; în responsabilităţi; ale fluxurilor proceselor; manageriale; în viziunea şi
misiunea firmei; abilităţile personalului.
Organizațiile trebuie să descopere şi să‐şi analizeze potențialul permanent la
toate nivelurile, să dezvolte noi moduri de operare pe care să le configureze cu
flexibilitate. Capacitatea de inovare este deosebit de importantă, iar cea de învățare
continuă este primordială. Suportul oferit acestui proces de integrare informațională
prin platforme de tip groupware sau portal este deosebit de important.
Majoritatea companiilor simt la un moment dat că a venit clipa schimbărilor
radicale, când se porneşte de la o foaie albă de hârtie un amplu proces de
restructurare şi reproiectare organizațională (în proiectele ERP Business Process
Reeingineering este o metodă de realizare a acestei schimbări).

REENGINEERINGul organizaţional
Michael Hammer10 a supus atenţiei specialiştilor o nouă teorie care se referă la ideea de
reproiectare radicală a proceselor, a organizării şi mentalităţii din întreprinderi, fenomene
incluse în sintagma (la modă şi în zilele noastre) de REENGINEERING. O comparaţie
generică a caracteristicilor în abordarea tradiţională şi cea bazată pe reengineering este
cuprinsă în tabelul următor.

Abordare tradiţională Abordare bazată pe reengineering
Piaţa (cererea) Cerere excesivă, producătorul Clientul devine figuracheie: necesită
este figuracheie pe piaţă, abordare individuală, solicită produse
consumătorul cumpără tot cei unice.
oferă furnizorul. Oferta este excesivă.
Concurenţa Concurenţă valorică (a preţurilor) Creşterea concurenţei internaţionale,
şi nonvalorică. globalizarea afacerilor.
Tipologia Localizarea businessului. Schimbări radicale, revoluţionare,
schimbărilor Schimbări treptate, evolutive. generate de dezvoltarea tehnologiilor
informaţionale.

10 M. Hammer, „Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review,
July/August, 1990, pp. 104‐112.

Abordare tradiţională Abordare bazată pe reengineering
Managementul Orientarea strategică a afacerii Orientarea strategică a afacerii este
schimbărilor este produsul/serviciul. clientul.
Caracteristicacheie a Caracteristicacheie a întreprinderii:
întreprinderii: organizator al organizaţie intelectuală, bazată pe
producţiei şi vânzărilor. cunoaştere.
Informaţia este discretă. Informaţia este rezultat al activităţii
creative, cunoaşterii, dezvoltării.

Michael Hammer şi colaboratorul său James Champy au devenit celebri odată cu publicarea
lucrării „Reengineering the Corporation”11, care oferea o viziune total nouă asupra modului
în care trebuie să fie organizate şi conduse întreprinderile, dacă vor să reuşească şi să
supravieţuiască în anii ’90 şi dincolo de pragul secolului.
Reengineeringul nu caută să îmbunătăţească activitatea întreprinderilor prin perfecţionări
treptate – mai rapid cu 10 procente întrun loc, mai ieftin cu 20 de procente în alt loc.
Obiectivul este un salt calitativ în performanţe – îmbunătăţiri de 100% şi chiar de zece ori
mai mult, care se pot obţine prin procese şi structuri cu totul noi.
Cheia acestui fenomen constă în abandonarea majorităţii noţiunilor de bază pe care este
construită o întreprindere modernă. Lucrătorii şi managerii de azi sunt prizonierii unei
teorii învechite cu privire la organizarea muncii – teorii care datează de la începuturile
revoluţiei industriale. Aceste idei: diviziunea muncii, necesitatea controalelor meticuloase,
ierarhia managerială – nu mai sunt valabile întro lume de competiţie globală şi în continuă
schimbare. Hammer şi Champy introduc noţiunea de orientare spre procese, concentrare
asupra activităţilor care creează valoare pentru client şi regândirea lor de la început la
sfârşit. „Reengineering the Corporation” reprezintă un adevărat manifest pentru
revoluţionarea întreprinderilor. Particularitatea esenţială a BPR constă în utilizarea
esenţială a tehnologiilor informaţionale în scopul ameliorării produselor şi serviciilor firmei.
Obiectivele Business Process Reengineeringului pot fi sintetizate astfel:
creşterea satisfacţiei clientului este principalul obiectiv al demersului. Clientul este privit
ca un utilizator final al produsului sau serviciului şi ca un adevărat partener al
întreprinderii. Relaţiile cu clienţii şi furnizorii înseamnă parteneriat. Acest punct este
fundamental în „filosofia” reengineeringului. Organizaţia nu există decât pentru a servi
nevoile prezente şi viitoare ale clienţilor;
reducerea costurilor este, de asemenea, un obiectiv important, deoarece costurile mari
slăbesc competitivitatea întreprinderii pe piaţă. Vocaţia reengineeringului este să pună
pe picioare organizaţii rentabile;
îmbunătăţirea calităţii produselor şi serviciilor este cea mai bună modalitate de a
satisface clientul. Cel mai adesea, volumul vânzărilor este dependent de calitatea şi
preţul produselor. Întro organizaţie bazată pe structuri funcţionale, responsabilităţile
sunt pasate de la o divizie la alta, constituind un veritabil obstacol în obţinerea calităţii;
utilizarea optimă a competenţelor este încă un factor de competitivitate gestionat
deficitar de întreprindere. Organizaţiile marcate de linii ierarhice puternice nu
exploatează toate resursele de competenţă, de cunoştinţe şi expertiză ascunse în spatele
structurilor sale;
reducerea întârzierilor. Regrupând procesele cu aceeaşi finalitate, utilizând tehnologiile
informaţionale şi comunicaţionale, se poate optimiza fluxul informaţional, sarcinile fiind

11 M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution, Harper
Business Press, 1993.
executate în paralel; întreprinderea reduce astfel considerabil întârzierile în toate
activităţile sale;
ameliorarea valorii adăugate presupune identificarea şi eliminarea sarcinilor fără plus
de valoare, favorizate de structura organizatorică tradiţională.
Creşterea puterii de reacţie este o consecinţă directă a reengineeringului. Acest obiectiv
permite accelerarea proceselor decizionale graţie eliminării liniilor ierarhice orizontale şi
utilizării structurilor orizontale de tip echipe de proiect.
Lumea revoluţiei industriale lasă locul unei ere a economiei globale a tehnologiilor informatice
şi a schimbărilor necontenite. Astfel, profesioniştii tehnologiilor informaţionale au un rol
cheie în orice proces managerial.

În ansamblu, schimbarea organizațională presupune respectarea celor opt
principii de management al calităţii12 (ediția ISO 9000:2000):
1) orientarea către client: înțelegerea tuturor nevoilor şi aşteptărilor clienților
cu privire la produse şi servicii, caracteristicile acestora; asigurarea unui echilibru
între modul de abordare a nevoilor clienților şi ale celorlalte părți interesate (proprie‐
tari, personalul organizației, furnizori, comunitatea locală, societatea în general);
comunicarea acestor nevoi şi aşteptări în întreaga organizație; evaluarea satisfacției
clienților pentru îmbunătățirea continuă a rezultatelor; managementul relațiilor cu
clienții;
2) leadershipul – liderii corelează scopul şi orientarea strategică a
organizației, creează şi stimulează mediul intern în vederea implicării totale a
personalului în realizarea tuturor obiectivelor, presupunând: persoane care sunt
antrenate şi orientate profesional şi cultural de lideri; abilitatea de a recurge la
diverse forme de exercitare a puterii decizionale pentru a influența membrii
grupului în comportamentul lor şi în desfăşurarea activităților;
3) implicarea personalului – angajații de la toate nivelurile reprezintă
elementul central al unei organizații, implicarea lor totală permițând ca abilitățile lor
să fie valorificate pentru maximizarea beneficiilor organizației şi presupunând:
asumarea răspunderii în rezolvarea problemelor; implicarea activă în identificarea
oportunităților de îmbunătățire; valorificarea competențelor, cunoştințelor şi
experienței; concentrarea cu precădere asupra satisfacerii nevoilor clienților;
4) abordarea bazată pe procese – atunci când toate activitățile şi resursele
organizației sunt conduse ca procese, rezultatele vor fi optime prin: definirea
proceselor şi identificarea datelor de intrare şi ieşire; identificarea interferențelor
proceselor cu entitățile funcționale ale organizației; evaluarea riscurilor posibile, a
consecințelor şi impactului proceselor asupra clienților, furnizorilor şi altor părți
interesate; stabilirea clară a responsabilităților privind managementul proceselor;
5) abordarea managementului ca sistem – presupune identificarea, înțelegerea
şi conducerea sistemului de procese intercorelate ale organizației în realizarea
obiectivelor stabilite;
6) îmbunătăţirea continuă a produselor şi serviciilor este obiectivul permanent
şi este posibilă numai prin îmbunătățirea continuă a proceselor organizației, din

12 E. Maxim, Calitatea şi managementul calităţii, Editura Sedcom Libris, Iaşi, 2007, pp. 153‐157.

fiecare etapă a ciclului de viață al produsului/serviciului, începând cu studiile de
marketing pentru identificarea cerințelor clienților şi până la asigurarea utilizării
corespunzătoare a produselor/serviciilor. Angajații trebuie să se preocupe perma‐
nent de îmbunătățirea activităților pe care le desfăşoară;
7) abordarea bazată pe fapte în luarea deciziilor, deoarece deciziile eficiente se
bazează pe analiza datelor şi informațiilor, începând cu etapa identificării clienților
şi a cerințelor de produs şi până la evaluarea satisfacției acestora;
8) relaţii reciproc avantajoase cu furnizorul, prin politica sa în domeniul
calității, organizația trebuie să‐şi definească „principiile coordonatoare” pe care le
promovează în relațiile cu toți partenerii săi, în încercarea tuturor părților de a
genera plusvaloare.
Transformarea sau schimbarea organizațională este un proces complex care
presupune o anumită conduită managerială (aşa cum am prezentat deja, adoptarea
Total Quality Management) şi parcurgerea următoarelor etape:
diagnoza procesului de schimbare organizațională, motivarea importanței
şi necesității;
formularea obiectivelor schimbării;
identificarea forțelor schimbării;
propunerea de măsuri de reducere a rezistenței la schimbare;
indicarea agenților schimbării şi a rolului lor în implementarea schimbării;
alegerea tehnicilor adecvate de schimbare organizațională;
analiza strategiei propuse din punctul de vedere al implicațiilor etice ale
acesteia.
În mod evident, prima etapă este foarte importantă şi presupune, în vederea
acurateței diagnozei, recurgerea la următoarele modele de diagnosticare/
investigare13:
modelul sistemelor deschise: organizația este un sistem deschis pentru că
are legături cu mediul extern prin intrările şi ieşirile desfăşurate. Cunoaşterea şi
analiza acestor legături ajută specialistul să identifice corect modul de lucru al
sistemului organizațional, atuurile şi disfuncționalitățile şi să caute măsuri raționale
de îmbunătățire;
modelul diagnosticării organizaţiei pe niveluri ierarhice: nivelul 1: strategia,
organizarea structurală, organizarea procesuală; nivelul 2: departamentele şi
relațiile dintre ele; nivelul 3: munca fiecărui individ. Diagnosticarea poate avea loc la
toate nivelurile sau numai la unul dintre acestea. Este foarte importantă
determinarea modului în care fiecare nivel le influențează pe celelalte;
modelul Nadler şi Tushman porneşte de la mai multe variabile care trebuie
analizate, la cele trei niveluri reprezentate de intrări, procese de transformare şi
ieşiri. De exemplu, la nivel de intrări, se ține cont de clasele de variabile: mediu,
resurse şi istorie; la nivelul clasei „Mediu de piață”, competiție, guvern şi furnizori;

13
E. Burduş, G. Căprărescu, A. Androniceanu, M. Miles, Managementul schimbării organizaţionale,
Editura Economică, Bucureşti, 2003, pp. 75‐81.
modelul Weisbord se axează pe un diagnostic intern al organizației prin
intermediul unor variabile între care există o interdependență (misiune, structură,
recompense, mecanisme utilizate, relaţii şi intrări din mediu). Autorul consideră că
analiza‐diagnostic a unei organizații trebuie să țină seama de influența variabilelor
din mediul ambiant extern, pe care le evidențiază în model sub forma intrărilor. În
funcție de acestea, un leadership eficace asigură analiza principalelor elemente de
caracterizare a organizației, reprezentate de strategia acesteia, de sistemul de
recompense, de mecanismele utilizate în procesele organizaționale şi de relațiile
care s‐au stabilit şi caracterizează organizația.

4.4. Transformările culturale şi profesionale: de la rezistenţa
la schimbare la stimularea creativităţii

În organizațiile tradiționale operează un mediu relativ stabil, rolurile
individuale sunt bine determinate, iar complexitatea afacerii este controlată prin
transmiterea sarcinilor de lucru în sens descendent, pe scala ierarhică, spre
structurile componente (de la organizații către diviziunile componente ale acesteia).
La orice nivel, managerii stabilesc planuri şi urmăresc îndeplinirea graduală a
activităților sub controlul lor direct, alocă şi monitorizează resursele şi prevăd
sumele‐limită acordate unităților operaționale.
În mediul de lucru din zilele noastre acest model de management s‐a perimat;
supraviețuirea organizației depinde de cât de bine sunt definite stilurile de lucru, de
eficiența comunicării şi de înțelegerea corespunzătoare a interdependențelor dintre
membrii organizațiilor. La prima vedere, imaginea este de haos. Dacă mai adăugăm
un fapt deloc de neglijat, în opinia noastră, şi anume acela că fiecare membru al
organizației îşi stabileşte propriile reguli de lucru, potrivit sarcinilor pe care le are
de îndeplinit, practică un autocontrol continuu şi are responsabilități sporite, tabloul
devine complet. Organizația este deschisă celor educați, cu o cultură evolutivă şi cu
posibilități de formare profesională continue. Drucker recomandă reorientarea
educaţiei, de la concentrarea exclusivă pe „învăţarea extensivă” a tineretului, spre
„învăţarea continuă a adulţilor”. Acumularea permanentă este răspunsul sectorului
public la confruntarea dintre forța de muncă şi economia globală. Astfel, cunoaşterea
este exploatată ca o resursă. Informația devine un activ „nou”, disponibil în mod
liber pentru toți.
În cazul proiectelor ERP, organizarea pe echipe de proiect eclipsează modurile
clasice de organizare (pe canale valorice). Principala dificultate, în acest caz, constă
în formarea echipelor. Managerii îşi revizuiesc stilul, stabilesc un echilibru între
asigurarea celei mai bune execuții şi autonomia grupurilor de lucru. Flexibilitatea
devine un obiectiv imperativ în cadrul întreprinderilor care trebuie să facă față unei
cereri fluctuante. Raționamentul axat pe „portofoliul cunoştințelor” începe cu
ştergerea straturilor ierarhice. Individul este poziționat în cadrul organizației în
funcție de calificarea şi de cunoştințele pe care le deține. El poate evolua apoi,
progresiv, devenind şef de proiect. Managerii cunosc aşteptările clientelei,
cercetează ambițiile personalului firmei şi favorizează elaborarea unor noi structuri

organizaționale, capabile să dezvolte responsabilitatea şi inițiativa şi să lărgească
aria individuală de competențe.
Majoritatea companiilor simt că managementul schimbării reprezintă piesa
de rezistență a eşafodajului ERP. Este o ironie faptul că, deşi se afirmă a fi doritori de
progres, tocmai utilizatorii finali şi salariații companiilor manifestă rezistență la
schimbare, fenomenul provocând cele mai complexe probleme întâlnite în
implementările de acest gen.
Rezistenţa organizaţională la schimbare este determinată de una sau mai
multe dintre următoarele cauze:
amenințările asupra puterii şi influenței unor persoane – se ştie că
redefinirea responsabilităților este o chestiune delicată, la fel şi predarea ştafetei –
mulți manageri suferă în urma restabilirii centrelor decizionale;
o structură organizatorică înalt formalizată, ce reprezintă o frână în calea
schimbărilor;
resursele limitate de capital, timp, personal calificat sau mijloace financiare;
imobilizarea capitalului în clădiri, maşini, terenuri conduce la imposibili‐
tatea transformării rapide a acestor resurse;
acordurile interorganizații impun managerilor obligații care pot influența
negativ comportamentul lor vizavi de schimbare (de exemplu, angajamentele scrise
față de furnizori, obligațiile guvernamentale etc.).
În ceea ce priveşte rezistenţa individuală la schimbare, aceasta se manifestă
ca efect următoarelor aspecte şi caracteristici:
atenția şi memoria individuală selectivă – lipsa informațiilor necesare
(oamenii citesc şi se informează din rutină, aceleaşi publicații, urmăresc aceleaşi
emisiuni);
rutina, obiceiurile – apar din cauza comportamentului profesional;
dependența exagerată față de alte persoane – de regulă, față de persoanele
superioare ierarhic;
frica de necunoscut, față de noile responsabilități;
rațiunile economice, din teama că posibilitatea diminuării performanței
profesionale va antrena o scădere a veniturilor;
securitatea, stabilitatea, care asigură fiecăruia o viață „fericită”.
Astfel devin necesare modificări în natura posturilor de lucru dintre care
menționăm:
schimbarea unităţii de lucru de la departamente funcţionale la echipe de
proiecte. Procesele şi activitatea echipelor înlocuiesc vechea structură a
departamentelor. Echipele sunt grupuri împuternicite organizațional să participe la
luarea deciziilor, să exercite influență în legătură cu atingerea obiectivelor şi să
stabilească obiective;
modificarea postului de lucru de la sarcini simple la lucrări multidimen
sionale. Membrii echipelor partajează responsabilitățile, se autoevaluează şi învață
sistematic. Munca desfăşurată devine un veritabil instrument de perfecționare.
Cercetătorii au constatat că indivizii posedă o capacitate de integrare informațională
superioară atunci când se găsesc în contextul lor obişnuit, decât atunci când trebuie
să urmeze stagii de formare profesională;
rolul salariaţilor se schimbă, ei nu mai sunt controlaţi, ci împuterniciţi, şi au
putere de decizie. Îşi stabilesc propriile reguli de lucru, astfel că intervenția
supervizorilor nu poate decât să provoace neplăceri şi să deranjeze bunul mers al
lucrărilor. Viziunea transversală a întreprinderii permite fiecărui individ să‐şi
aprecieze valoarea contribuției personale în efortul colectiv;
pregătirea postului de lucru de la instruire la educaţie. Dacă prin instruire se
învață cum se face un lucru, prin educație se învață care sunt motivele pentru care se
procedează la rezolvarea respectivă, sunt căutate subtilitățile şi alternativele;
măsura performanţelor şi acordarea compensaţiilor se concentrează pe
rezultate, şi nu pe activităţi desfăşurate. Nu execuția activităților izolate, ci
contribuția şi valoarea adăugată constituie baza recompensărilor;
schimbarea criteriilor de avansare profesională de la performanţă la abilităţi
profesionale. Dacă o lucrare bine făcută este recompensată printr‐un bonus,
avansarea profesională se realizează în funcție de abilitățile pe care le are o
persoană în domeniul respectiv. Performanța este remunerată, iar crearea de noi
deprinderi este încurajată;
valorile nu mai sunt protejate excesiv, ele devin productive. Reproiectarea
proceselor provoacă schimbări în structura şi cultura organizațională. Angajații
trebuie să creadă în munca lor şi să conştientizeze că nu lucrează pentru şefii lor, ci
pentru clienții firmei, implicit pentru prosperitatea acesteia;
statutul managerilor se modifică de la supervizori la antrenori;
structura organizaţională devine, din ierarhică, heterarhică. Este genera‐
lizată munca în echipă. Formalizarea liniilor de comunicare devine absolut necesară,
deoarece salariații comunică oricând, cu oricine. Îndrumarea devine o funcție
distributivă. Distorsiunile comunicaționale apar atunci când structura întreprinderii
marginalizează comunicațiile de tip informal, în loc să le integreze în funcționarea
reală a întreprinderii. Poate fi blocată dezvoltarea procesului de informare laterală
între indivizi situați pe acelaşi nivel ierarhic, dezvoltând circuite comunicaționale de
tip „diagonal”, care unesc indivizi situați pe diferite niveluri ierarhice, care au
calificări diferite;
schimbarea rolului executivului – top‐managerii nu se mai ocupă numai de
înregistrarea rezultatelor („țin scorul”), ci intră în categoria liderilor.
Managementul schimbării este conceput pentru a susține o tranziție
eficientă a organizației şi angajaților săi de la situația curentă către o etapă viitoare,
ajutând managerii să gestioneze eficient procesul pentru a adopta cu succes
schimbările necesare obținerii rezultatelor propuse. Managementul schimbării
furnizează elementele conceptuale şi practice pentru ca indivizii, echipele şi cultura
organizațională să se îmbine fericit pentru a realiza schimbarea.
Astfel, managementul schimbării organizaţionale este definit formal prin
ansamblul proceselor de prevedere, organizare, coordonare, antrenare şi control al

unor măsuri de înlocuire, modificare, transformare sau prefacere în formă şi conţinut
a organizaţiei, cu scopul creşterii eficienţei şi competitivităţii acesteia14.
În viziunea lui John Kotter15, reputat profesor la Harvard Business School şi
aflat între primii 50 cei mai influenți gânditori globali de business, conform
clasamentului Thinkers50 (www.thinkers50.com), parcursul normal al managemen‐
tului schimbării înseamnă parcurgerea a opt paşi:
1) crearea senzației de necesitate a schimbării;
2) alcătuirea echipei de coordonare a schimbării;
3) elaborarea viziunii şi strategiei schimbării;
4) comunicarea schimbării şi câştigarea încrederii în implementarea ei;
5) împuternicirea unor agenți ai schimbării pentru a acționa;
6) câştigarea de victorii pe termen scurt;
7) perseverență (menținerea ritmului);
8) crearea unei noi culturi organizaționale.
Între metodele manageriale de gestionare a schimbării organizaționale se
numără:
managementul prin obiective – urmăreşte exercitarea funcțiilor manage‐
mentului prin corelarea obiectivelor organizaționale cu interesele managerilor, prin
recurgerea la stimulente strâns legate de nivelul de realizare a obiectivelor;
managementul prin excepţii – presupune identificarea şi comunicarea
selectivă de către managerii de pe diferite niveluri ierarhice numai a acelor
informații care sunt absolut necesare intervenției lor;
managementul proiectelor – constă într‐un set complet de sarcini, tehnici,
instrumente desfăşurate în timpul execuției proiectelor de o echipă condusă de un
manager de proiect. Timpul, costul, calitatea şi performanțele sunt constrângeri
pentru proiect;
managementul prin bugete – presupune folosirea bugetului ca principal
mijloc de exercitare a funcțiilor managementului în cadrul unei organizații, într‐o
anumită perioadă de timp;
delegarea – presupune distribuirea sarcinilor şi responsabilităților.
Schimbarea mentalității asupra autorității şi a puterii, asupra managerului care
trebuie să se transforme într‐un lider, asupra subordonatului care devine colabo‐
rator, este esențială în procesul de integrare informațională. Recunoaşterea
reciprocă, respectul şi încrederea în colaboratori, satisfacția comună reprezintă
elemente psihologice puternice de susținere a delegării;
metode de stimulare a creativităţii. Stimularea permanentă a factorilor
creativi şi aplicarea neîntârziată a ideilor generatoare de nou pot transforma radical
orientarea unei organizații aflate în schimbare, dacă managementul înțelege şi
acceptă ideea că potențialul de creație poate fi amplificat mereu cel puțin pe
următoarele două căi: educație permanentă, învățare şi utilizarea instrumentului

14 E. Burduş, G. Căprărescu, A. Androniceanu, M. Miles, op. cit., pp. 75‐81.
15 Cărțile lui Kotter, un veritabil guru al managementului schimbării şi leadership‐ului, au fost traduse
şi publicate în România de Editura Publica: Forţa schimbării sau delicioasa fabulă Aisbergul nostru se
topeşte şi de Meteor Press: Ce fac liderii cu adevărat – ele sunt recomandate managerilor care vor să
pornească ori să rămână pe drumul succesului.
metodologic prin care este stimulată soluționarea creativă, în grup, a problemelor
organizaționale.
O planificare bine pusă la punct este o parte vitală a unei transformări, însă
aceasta din urmă nu poate avea loc fără ca planul să fie susținut şi de o combinație
de idei şi energie creativă. Cu atât mai mult cu cât cea mai mare parte a nereuşitelor
unei transformări organizaționale nu sunt consecința planificării defectuoase, ci a
problemelor de implementare. Multe proiecte promițătoare eşuează din cauza lipsei
de idei, în timp ce altele se împotmolesc din cauza scăderii progresive a interesului
celor implicați.

Considerăm că metodele de stimulare a creativităţii16 sunt foarte importante şi trebuie să fie
cunoscute managerilor:
metoda brainstorming – a fost concepută de Alex Osborne în 1957 şi are la bază
stimularea unui grup restrâns de persoane pentru a descoperi idei noi. Termenul provine
din limba engleză şi poate fi tradus prin „furtună în creier”. Alte denumiri în literatură:
asaltul de idei, cascada ideilor, metoda Osborne17, filosofia marelui DA, evaluarea
mânată. Câteva dintre regulile impuse de această metodă sunt:
– eliminarea oricărui argument de evaluare în timpul şedinţei;
– propunerile trebuie să fie scurte, eliminarea discursurilor lungi;
– încurajarea participanţilor să emită idei noi pornind de la cele deja emise;
– programarea şedinţei la o oră la care participanţii sunt odihniţi;
– acordarea libertăţii de conduită şi în exprimare a participanţilor;
– desfăşurarea şedinţei întrun loc cu aspect plăcut;
– înlăturarea rigidităţii şi menţinerea unei atmosfere destinse;
– înregistrarea exactă şi completă a discuţiilor şi în special a ideilor emise;
– grupul să fie format din 612 persoane cu pregătire cât mai diferită;
metoda Delbecq – urmăreşte obţinerea de idei noi în vederea soluţionării unor
probleme pe baza maximizării participării membrilor grupului. Problema de soluţionat
este percepută ca o diferenţă între situaţia actuală şi cea ideală. Câteva dintre regulile
impuse de această metodă sunt:
– participanţii trebuie să posede cunoştinţe despre problema abordată;
– participanţii trebuie să fie motivaţi să participe la soluţionarea problemei;
– problema abordată nu trebuie să fie nici prea îngustă dar nici prea vastă;
– participanţii formulează idei doar în perioadele stabilite în acest scop;
– stabilirea unui moderator al grupului;
– alegerea unui secretar care să înregistreze ideile participanţilor formulate ca modalităţi
de trecere de la situaţia reală la cea ideală;
metoda managereconomistsociolog ARMENIA – MESA – porneşte de la ipoteza că în
orice organizaţie problemele pot fi rezolvate mai bine. Pentru aceasta este necesară o
abordare specială a procesului creativ, divizat în runde distincte de dezbatere la care să

16 E. Burduş, G. Căprărescu, A. Androniceanu, M. Miles, op. cit., pp. 402‐438.
17
A.F. Osborn, Applied Imagination: Principles and Procedures of Creative ProblemSolving, Third
Edition, Charles Scribner’s Sons, New York, 1963.

participe persoane reprezentative din organizaţie şi din domeniul în care se încadrează
problema de analizat sau situaţia decizională (persoane şi consultanţi din afara
mediului organizaţional). Reuniunea MESA nu se încheie odată cu identificarea soluţiei
sau deciziei optime, ci continuă cu aplicarea procesului, în care pot apărea noi variabile
cu influenţă asupra conţinutului variantei finale. Câteva dintre regulile impuse de
această metodă sunt:
– alegerea temei se face cu cel puţin opt zile înainte de derularea reuniunii;
– alegerea unui coordonator al reuniunii cu profil de creativitate;
– precizarea clară a datei, orei şi locului de desfăşurare a reuniunii;
– stabilirea judicioasă a persoanelor care vor participa la reuniune;
– limitarea duratei dezbaterilor la o oră;
– întreruperea dezbaterilor este posibilă numai în situaţii excepţionale;
– asigurarea resurselor necesare implementării ideilor rezultate în urma evaluării;
sinectica – elaborată de William Gordon, are la bază următoarele postulate:
– creativitatea există sub formă latentă în fiecare individ;
– creativitatea este mult mai apropiată de procesul emoţional decât de intelect sau
raţiune;
– oamenii cu moral scăzut sunt mai puţin creativi;
– creaţia de grup este guvernată de aceleaşi legi ca cea individuală.
Mecanismele operaţionale sunt: transformarea necunoscutului în familiar, transformarea
familiarului în ceva obişnuit, ignorarea oricăror legi prin atribuirea acestora de semnificaţii
diferite de cele obişnuite;
metoda carnetului colectiv – se bazează pe îmbinarea creativităţii dezvoltate în cadrul
unui colectiv cu competenţa individuală. Etape:
– constituirea unui grup de creativitate, fiecare membru primeşte un carnet în care va
scrie problema de studiat;
– pe parcursul unei luni, fiecare membru va nota ideile personale;
– întocmirea la sfârşitul lunii a unui rezumat care va cuprinde cea mai bună idee;
– predarea carnetului coordonatorului de grup;
– distribuirea carnetelor cu rezumatele întocmite de coordonator membrilor grupului de
creativitate;
– organizarea de discuţii în grup, în care se vor alege cele mai bune idei;
tehnica Phillips 66 – dezvoltată de Donald Phillips, presupune participarea la şedinţa
de creativitate a 30 de persoane care vor dezbate problema timp de două ore. Etape:
– 30 de participanţi vor fi împărţiţi în grupe de şase persoane, dintre care una va fi
reprezentant;
– animatorul discuţiei generale va prezenta problema care urmează a fi rezolvată;
– fiecare microgrup se va retrage pentru a discuta problema timp de şase minute,
reprezentantul va nota ideile exprimate;
– microgrupurile se vor reuni întro şedinţă comună în care fiecare reprezentant va
prezenta opiniile notate;
– în final se vor selecta ideile cele mai interesante;
metoda morfologică – a fost elaborată de F. Zwinchy, profesor de astrofizică timp de 42
de ani. Este o metodă ce reprezintă un mod de căutare a soluţiilor care se înscriu în
limitele anumitor restricţii ce pot fi tehnologice, financiare, comerciale etc.;
matricea descoperirilor – este o tehnică ce foloseşte un tabel în care, atât pe
orizontală, cât şi pe verticală, sunt înscrise diferite variabile care se pot asocia şi
combina sugerând în final o idee asupra unui produs, procedeu sau asupra unei noi
necesităţi care poate fi satisfăcută;
concasajul – este o tehnică la baza căreia stă ideea potrivit căreia imaginea noastră
despre lumea exterioară ne apare atât de obişnuită, încât o considerăm de neschimbat.
Concasajul constă în „spargerea” problemelor în elemente componente şi înscrierea lor

întro matrice pentru analiză.

În mod cert, cheia succesului este deţinută de echipa de implementare.
Practica a demonstrat că, de fapt, nu vorbim numai despre o echipă, ci de cel puțin
trei:
1) echipa de consultanţi (profesionişti) care a consiliat firma în alegerea celei
mai potrivite soluții. În preambulul licitației, consultanții au pregătit studii de caz,
au analizat evoluția altor afaceri asemănătoare şi au conturat tendințele de
desfăşurare pentru anii următori. Consultanții provin fie din interiorul firmei, fie de
la firme de consultanță (nume celebre sunt Pricewaterhouse Coopers, Deloitte &
Touche, KPMG, Ernst & Young, IDC, Gartner Group);
2) echipa formată prin combinarea personalului intern IT cu specialiştii
furnizorului. Această echipă cunoaşte teritoriul informațional al firmei şi necesarul
tehnologic care urmează a fi completat potrivit cerințelor sistemului ales. Dintre
modalitățile de colaborare enumerăm dialogul, relațiile amiabile, frontul comun în
fața problemelor şi ajutorul reciproc;
3) echipa managerilor formată din managerii „de la vârf” şi şefii principalelor
servicii şi compartimente antrenate în proiect.
Personalul firmei trebuie să se pregătească pentru a face față cu succes
necesităților informaționale cerute de proiect. Aplicațiile ERP sunt generatoare de
formări profesionale continue. Primul pas în pregătirea specialiştilor îl reprezintă
organizarea de sesiuni de instruire. Aceste întâlniri se pot organiza în cadrul
organizației, la furnizori sau la firme specializate. Uneori, cursurile pot fi deosebit de
costisitoare. Observăm totuşi că în negocierile desfăşurate cu un furnizor de pachete
integrate pot fi incluse şi aceste servicii. Nivelurile minime de formare profesională
sunt următoarele:
instruirea personalului IT în următoarele domenii: administrare baze de
date; gestiune electronică a documentelor (GED); administrare aplicații distribuite
în rețea; platforme de operare; instrumente de tip developer; aplicații de întreținere
şi securitate a sistemului; cunoştințe hardware pentru întreținerea echipamentelor;
noi tehnologii informaționale din categoria aplicațiilor de gestiune: Customer
Relationship Management, Supply Chain Management, Mobile Business, Bussines
Process Outsourcing, E‐Procurement etc.;
instruirea personalului IT şi a utilizatorilor finali, familiarizarea cu
platforma ERP aleasă;
instruirea specialiştilor din zona economică pentru operațiunile sofisticate
de analiză, familiarizarea acestora cu tablourile de bord, instrumentele de tip DSS sau
Business Intelligence, CRM, SCM, E‐procurement, Product Lifecycle Management
(managementul ciclului de viață al produsului), managementul proiectelor;

instruirea managerilor cu analizele multimensionale OLAP, simulările,

scenariile şi prognozele, în special a managerilor din zona economică.
La toate aceste tipuri de cursuri se adaugă şi disponibilitatea de a lucra cu
documentațiile scrise sau help‐ul contextual din soluția software respectivă. Cum
specificațiile pe module sunt, de multe ori, personalizate după cerințele
utilizatorilor, cunoaşterea informațiilor care descriu în amănunt operațiunile este
deosebit de importantă. Un produs de tip ERP este atât de complex, încât şi
documentațiile sunt de mai multe tipuri:
documentația completă a proceselor în curs;
documentația pentru descompunerea proceselor complexe în procese
elementare;
documentația proceselor în devenire, majore şi elementare;
înțelegerea proceselor noi cu ajutorul consultanților;
planul actualizării proiectelor.
Dacă o organizație se aşteaptă ca implementarea unui produs integrat să
reducă incertitudinea asociată proceselor economice, este la fel de posibilă şi
apariția reversului medaliei: creşterea incertitudinii. În aceste condiții, compatibi‐
litatea pachetului de aplicații cu specialiştii proprii trebuie să fie perfectă.
Completarea cunoştințelor profesionale se transformă astfel în obişnuință.
Soluția electronică ce sprijină realitatea pregătirii continue se numeşte e
learning. Studii recente indică faptul că nu mai există practic nicio activitate socială
(educație, cercetare, cultură, economie, transporturi sau divertisment) care să nu fie
secondată de o prezentare în format electronic concretizată în pagini web pe
internet, baze de date multimedia, prezentări interactive etc. Adoptarea de
organizațiile cu scop lucrativ a soluțiilor e‐learning permite o pregătire mult mai
eficientă a propriilor angajați, în contextul în care informația devine elementul
fundamental pentru orice afacere. Dintre avantajele e‐learning menționăm:
economii consistente de bani (cursurile „clasice” din zona IT sunt costisitoare),
creşterea productivității, sporirea gradului de satisfacție a angajaților, creşterea
creativității, îmbunătățirea muncii în echipă prin creşterea gradului de colaborare şi
interactivitate între cursanți, schimbarea rolului instructorului/profesorului,
reducerea intimidărilor şi a frustrărilor printre cursanți, accesul simultan la diverse
surse de învățare, posibilități de învățare controlată şi de măsurare a eficienței
programului. În final, dorim să mai spunem un singur lucru: internetul a schimbat
pentru totdeauna modul în care companiile produc, operează, comunică şi (de
ce nu?) învaţă.

CAPITOLUL 5
Platformele Customer Relationship
Management – de la automatizare la strategie
de afaceri

& înţelegeţi ce presupune revoluţia marketingului în
secolul XXI;
& cunoaşteţi cum au evoluat şi ce înseamnă platformele CRM;
& aveţi cunoştinţă despre motivaţiile implementării;
& puteţi descrie platformele pe funcţionalităţi;
& faceţi cunoştinţă cu SocialCRM;
& aveţi cunoştinţe despre piaţa proprietară şi cea open source.

5.1. Revoluţie în marketing

Mutațiile structurale produse în economie de la jumătatea secolului XX au
aşezat clientul în centrul atenției organizațiilor. Tehnologiile internet au oferit
nenumărate posibilități de desfăşurare a politicilor de marketing, asigurând practic
transferul relațiilor cu clienții în mediul electronic. „Clientul nostru, stăpânul
nostru!” – această „mantra”, deşi este o expresie des întâlnită, nu a fost pusă în cu
adevărat practică decât din anii ’90 ai secolului XX.
Afirmația potrivit căreia mediul extern devine tot mai turbulent este probabil
unul dintre cele mai banale enunțuri. Din nefericire însă, este adevărată – zona de
confort a marketingului a luat sfârşit odată cu tehnologiile sfârşitului de secol XX, în
principal acționând revoluția internet. Pe multe piețe, vechea abordare a
marketingului1 nu mai funcționează. Trebuie luate în calcul mai multe elemente –
mai multe canale, toate posibilitățile media sau mai multă tehnologie2. Din mai multe
puncte de vedere se petrece trecerea de la epoca analogică a marketingului la cea
digitală. Revoluţia în marketing presupune combinarea celor mai bune elemente din
marketing, vânzări şi servicii, de oriunde în lume, pentru a transforma marketingul şi
pentru a răspunde provocărilor unui secol care se anunţă imprevizibil, în care timpul
este consumat cu o viteză dusă la extrem.
Interesul profund asupra eficacității marketingului3 se bazează parțial pe
faptul că multe companii îşi dau seama că trebuie să câştige lupta pentru clienții
valoroşi. Cu alte cuvinte, trebuie să se concentreze asupra celor 10‐20% dintre
clienți, care fac diferența. Diferența dintre liderul de piață şi locurile 2 şi 3 se reduce
adesea la un grup foarte restrâns de clienți valoroşi. Un brand leader găseşte
întotdeauna modalități de a relaționa mai bine cu aceştia, iar suportul oferit de
platformele de baze de date, depozite de date şi instrumente analitice, este
considerabil în acest sens. Totuşi, existența datelor nu determină automat obținerea
unui avantaj strategic. Corelarea lor şi analiza după criterii multiple, elaborarea de
scenarii „Cear fi dacă?” sunt apanajul platformelor Customer Relationship
Management, completate de instrumente de tip Business Intelligence. Cu cât afacerea
este mai complexă, cu atât necesitatea unei platforme sofisticate de gestiune a
datelor despre clienți şi concurență este mai mare.
Ştiința de a vinde include conceptul fundamental al mixului de marketing.
Mixul de marketing reprezintă ansamblul de instrumente tactice de marketing
controlabile, pe care firma le combină pentru a produce pe piața‐țintă reacția
dorită4. Niel Borden, părintele acestui concept, a identificat inițial 12 elemente ale
mixului de marketing prin care companiile acționează pe piață: produsul, prețul,
marca, distribuția, vânzarea personală, publicitatea plătită, promovarea vânzărilor,

1 P. Gamble, A. Tapp, A. Marsella, M. Stone, Revoluţia în marketing. O abordare radicală pentru o afacere
de succes, Editura Polirom, Iaşi, 2008.
2 Y. Claeyssen, A. Deydier, Y. Riquet, Marketing direct multicanal. Prospectarea, fidelizarea şi
recâştigarea clientului, Editura Polirom, Iaşi, 2009.
3 M. Bruhn, Marketing. Noţiuni de bază pentru studiu şi practică, Editura Economică, Bucureşti, 1999.
4 P. Kotler, Principii de marketing, Editura Teora, Bucureşti, 2008.
Platformele Customer Relationship Management – de la automatizare la strategie de afaceri 177
ambalajul, modul de prezentare, serviciile postvânzare, logistica şi cercetarea de
marketing. Modelul a fost simplificat de Jerome McCarthy 5 la patru componente, cei
4 P (Product, Price, Place, Promotion – produsul, prețul, distribuția, comunicarea). În
ultima vreme, mai mulți autori6 au dezbătut ideea că vizarea doar a celor patru
componente este insuficientă pentru a realiza cu succes obiectivele organizaționale,
susținând că populaţia, element de bază şi cel mai de succes ingredient al
amestecului, cercetarea, determinarea naturii componentelor şi dozarea ameste
cului, reprezintă puncte importante ale mixului de marketing, care sunt ignorate de
teoria celor 4P7. Oricât de interesante ar fi, polemicile despre rețeta cea mai
potrivită a mixului de marketing nu răspund nici pe departe problemei funda‐
mentale ale companiilor: modalitatea de evaluare a raportului costuri‐rezultate
obținute pentru activitățile depuse de marketeri. Mai mult, odată cu răspândirea
tehnologiilor informaționale şi a internetului, evaluarea rezultatelor a devenit şi mai
dificilă.
Una dintre teoriile care stau la baza revoluției marketingului este cea a
orientării spre client, susținută la începutul anilor ’90 de însuşi Kotler – ea a
contribuit la trecerea de la marketingul tranzacțional, orientat pe termen scurt, la
marketingul relaţional, de creare, dezvoltare şi menținere a relațiilor cu toți
stakeholderii organizației (clienți, furnizori, distribuitori, angajați, alte organizații
interesate). Totodată, trecerea la marketingul relațional aduce în centrul
preocupărilor reținerea celor mai profitabili clienți. Calcule clare au arătat că
valoarea netă actualizată a fluxului de numerar generat de un client pe parcursul
duratei relației sale cu o firmă este un indicator mult mai relevant decât simpla
valoare a vânzărilor către acel client 8. Într‐o lucrare dedicată marketingului
relațional, I. Gordon9 găsea şase direcții ale acestuia:
scopul de a crea şi oferi valoare pentru clienți;
rolul‐cheie al clientului în definirea doleanțelor sale;
cooperarea permanentă dintre vânzător şi cumpărător;
proiectarea şi alinierea proceselor, tehnologiei şi a resurselor umane
pentru a crea şi creşte valoarea pentru client;
recunoaşterea şi măsurarea valorii „duratei de viață” a relației cu un client;
crearea de legături cu toți stakeholderii organizației.
După E. Gummesson10, sunt patru valori fundamentale ale marketingului
relațional:

5 Citat de Ş. Prutianu, C. Munteanu, C. Caluschi, Inteligenţa marketing plus, Editura Polirom, Iaşi, 1998,
pp. 103‐105.
6 I. Cătoiu, C. Bălan, G. Orzan ş.a., Cercetări de marketing, Editura Uranus, Bucureşti, 2002; P. Amerein,
F. Rouard, D. Barczyk ş.a., Manual de marketing strategic şi operaţional, Editura Teora, Bucureşti, 2002.
7 C. Munteanu, E. Maxim, C. Sasu ş.a., Marketing – principii, practici, orizonturi, Editura Sedcom Libris,
Iaşi, 2006, p. 26.
8 C. Bălan, „Managementul relațiilor cu clienții: valențe strategice, operaționale şi analitice”, în Revista
de Marketing Online, vol. 1, nr. 3, 2008, p. 7.
9 I. Gordon, Relational Marketing, John Wiley & Sons, Ontario, 1998, citat în C. Bălan, op. cit., p. 8.
10 E. Gummesson, Total Relationship Marketing, Butterworth‐Heinemann, Woburn, 2002, p. 16.

marketingul să se cuprindă şi desfăşoare prin toate departamentele

organizației, considerând că toți membrii acesteia pot contribui la îndeplinirea
obiectivelor de marketing;
marketingul se dezvoltă pe baza colaborării pe termen lung şi a unei
atitudini de parteneriat şi câştig reciproc;
toate părțile se implică activ, relațiile sunt interactive – se aşteaptă din
partea clienților să inițieze cereri de îmbunătățire ori schimbare a unui
produs/serviciu;
nu în ultimul rând, clienții trebuie văzuți şi abordați fiecare în parte, şi nu
ca o masă, trebuie tratați ca o sursă de venit, şi nu cheltuieli de marketing, iar
organizația are misiunea de a crea valoare pentru client, şi nu de a câştiga pe seama
acestuia.
Implementarea marketingului relațional în sistemul informatic al organizației
s‐a materializat în noul concept de management al relațiilor cu clienții, a cărui
paternitate poate fi atribuită lui Thomas Siebel, fondator în 1993 al companiei care îi
purta numele şi care va domina piața CRM în anii ’90.
Mai departe, odată cu propagarea tehnologiilor internet pe scară largă,
transformarea funcțiunii marketingului a continuat şi am asistat la apariția de noi
categorii specifice:
emarketing – este o formă deosebit de eficientă în cercetarea de marketing
deoarece furnizează informații suplimentare despre consumator, obiceiurile de
consum şi comportamentul lui declarat, efectiv, prin numeroase artificii tehnice care
colectează date extrem de prețioase despre target: cookie‐uri, spyware, log‐urile din
baza de date etc. Majoritatea afacerilor au dimensiune globală, se desfăşoară la scară
globală, celebra țesătură de păianjen fiind „vinovată” de comunicarea fără frontiere;
marketing virtual – reprezintă noua formă de marketing prezentă în cadrul
lumilor virtuale 3D. Toate brandurile importante şi‐au deschis reprezentanțe în
lumile virtuale, cum ar fi Second Life. Marketingul în Second Life este eficient dacă iau
în calcul utilizatorii şi interesele acestora, dacă le oferă soluții şi comunică deschis,
instaurând un dialog permanent şi benefic de ambele părți, dar mai ales dacă le
oferă experiențe care nu pot fi replicate în onlineul clasic, bidimensional;
marketing viral – este o formă similară marketingului electronic, întâlnită
mai ales în cadrul rețelelor sociale prezente pe internet (facebook, twitter, linkedin
etc.), principiul de funcționare fiind simplu: companiile îşi încurajează clienții să
promoveze produsele printre cunoştințele lor din rețelele sociale. Denumirea „viral”
i‐a fost atribuită acestui tip de marketing pentru că răspândirea rezultatelor acestuia
este asemănătoare răspândirii unui virus într‐o comunitate.
Managementul relațiilor cu clienții (ca un concept de marketing) reprezintă un
întreg proces care ajută la identificarea şi analiza comportamentului şi a
necesităților clienților în vederea dezvoltării unor relații cât mai solide cu aceştia. În
contextul afacerilor actuale, caracterizate prin hiperconcurență şi globalizare, acest
concept de marketing oferă suport pentru transformarea unei organizații obişnuite
într‐una centrată pe client. Clienții fideli reprezintă cel mai puternic avantaj
competitiv al unei companii, deoarece reprezintă o parte inaccesibilă concurenților,
dacă sunt gestionați eficient. Studiile realizate de PIMS 11 (Profit Impact of Marketing
Strategy – organizație profesională care se ocupă cu studiul comunicării firmelor cu
clienții, desfăşoară cercetări prin proiecte care acoperă perioade mari de timp;
primele date colectate sunt din 1960) au demonstrat că, în medie, un client
nemulțumit va povesti experiența sa negativă unui număr de şapte‐zece persoane, în
timp ce un client mulțumit va recomanda compania unui număr de trei‐patru
cunoscuți. Dacă avem în vedere şi aplicarea regulii lui Pareto, care arată că 20%
dintre clienți aduc 80% din vânzări, importanța segmentării clienților şi cultivarea
unei culturi orientate spre fidelizarea clienților este motivată ca importanță.
Volumul mare de date care trebuie analizate şi procesate a necesitat intervenția
suportului informatic şi acesta este specializat prin suportul platformelor Customer
Relatioship Management.

5.2. Evoluţia platformelor CRM

Din punct de vedere tehnologic, prin acronimul Customer Relationship
Management (CRM) este acoperit ansamblul aplicațiilor care aşază clientul în inima
organizației şi‐l transformă în partener activ. Explozia de informații datorată
internetului a permis consumatorului să compare caracteristicile şi prețurile
produselor şi serviciilor la nivel global şi a dus la scăderea loialității lui. În spatele
unui utilizator de internet se ascunde o persoană sofisticată, care adesea
relaționează cu alți oameni cu nevoi cel puțin la fel de diverse ca ale sale şi împreună
pot distribui informații şi, de ce nu, deveni sursă de inspirație. Web 2.0 şi
platformele sociale au declanşat o adevărată revoluție şi în lumea clienților.
Managementul relațiilor cu clienții a oferit instrumentele necesare supraviețuirii în
noul context de afaceri.

Scurt istoric CRM
La începutul anilor ’90, trei companii californiene, inspirânduse din manifestul reproiectării
(Champy & Hammer, prezentat în capitolul 4), au dezvoltat o viziune similară pentru
aplicaţiile frontoffice, prin integrarea conceptelor reproiectării proceselor economice.
Principalele obiective urmărite au fost:
eliminarea barierelor departamentale;
concentrarea asupra clientului;
sprijinirea personalului din zona vânzărilor/marketing, astfel încât clienţii să fie serviţi
întro manieră nouă, totodată eficientă şi prietenoasă.
Cele trei companii erau Clarify, Scopus şi Vantive. Mai apoi, Scopus a fost inspirat cumpărată de
Siebel (1998), care în acest fel sa aşezat solid pe piaţa aplicaţiilor CRM, iar Clarify a fost
achiziţionată (1999) de Nortel Networks. În fine, Peoplesoft a cumpărat Vantive,

11 http://pimsonline.com/about_pims_db.htm

completânduşi în acest fel suita ERP, reconsiderată şi redefinită sub influenţa tehnologiilor
internet.
La sfârşitul anilor ’90, în nebunia dotcom, care a cuprins lumea afacerilor, mai mulţi mici
producători de soft au găsit nişa aplicaţiilor CRM şi şiau concretizat ideile novatoare: de la
îmbunătăţirea experienţei online a clienţilor, la crearea de portaluri orizontale şi verticale,
analiza performanţelor angajaţilor şi efectuarea de previziuni. Pe de altă parte, au luat
atitudine şi marii furnizori ERP, adăugând suitelor lor facilităţi CRM sau chiar module noi,
prin achiziţia unei firme mici, specializate (exemplul Peoplesoft de mai sus nu este singular).
Istoric vorbind, conceptul de CRM sa concretizat iniţial în aplicaţiile Sales Force Automation
(SFA – automatizarea forţei de vânzări). La început, acestea au fost aplicaţii utilizate de
agenţii de vânzări şi, totodată, de managementul departamentului de vânzări pentru
coordonarea activităţii acestora. Integrarea în CRM a însemnat un salt calitativ, deoarece
vânzătorii au acum la dispoziţie un volum mare de informaţii detaliate despre clienţi, din
surse diverse.

În viziunea clasică, aplicațiile CRM înseamnă automatizarea proceselor de
vânzare, marketing, service postvânzare, în general a relațiilor cu clienții. Concret,
din punct de vedere operațional, funcţionarea unei soluţii CRM urmăreşte patru
paşi:
1) informarea clientului;
2) tranzacția (comanda);
3) livrarea bunului/serviciului;
4) asistența postvânzare.
Într‐un timp relativ scurt, acest concept a evoluat mult, iar experiența
acumulată a demonstrat că esența CRM şi motivul pentru care se regăseşte în
configurația sistemului informatic al firmelor reprezintă abilitatea de a face mai
uşoară experiența cu clienții, în sensul de a atrage şi a păstra clienții, de a creşte şi
menține profitabilitatea firmei pe termen lung. Practic, vorbim despre adăugarea
de noi funcţionalităţi prin care:
este facilitat accesul clientului la informații despre produsele şi serviciile
de care poate beneficia;
este simplificată tranzacția sau urmărirea comenzii clientului;
este îmbunătățit timpul de răspuns la cererile clientului;
clientul este ajutat să beneficieze la maximum de produsul ori serviciul
cumpărat.
Pe plan conceptual, evoluția CRM este mai mult decât o extindere de
funcționalități. Aşa cum se arăta în 2004 în studiul publicat de Gartner Group, CRM
devine o strategie de afaceri susținută de TI&C, cu scopul de a creşte veniturile şi
profitabilitatea firmei (valoare pentru firmă), la fel de mult ca satisfacția clienților
(valoare pentru clienți). Evoluția acestor platforme din 2004 până în prezent a
demonstrat că deciziile luate la nivel managerial se bazează (în cazul existenței
acestor platforme, în mod ideal, combinate cu platforme ERP) pe informații precise
şi reale privind contactele şi conturile clienților, prețurile produselor şi serviciilor,
campaniile de promovare desfăşurate, precum şi cercetările şi optimizările la nivel
de brand. Suportul oferit la nivel organizațional permite gestionarea corectă a
ciclului de viață al clienților şi optimizarea proceselor de marketing. Totodată,
continuă dezvoltarea la nivel de integrare informațională, prin adoptarea tehnolo‐
giilor Business Intelligence (BI), datele stocate în depozite de date sunt
transformate în informații în timp real, generându‐se rapoarte necesare procesului
decizional. Dincolo de evoluția generală a platformelor integrate pentru afaceri,
evoluția tehnologiilor sociale şi mobile şi‐a pus amprenta şi asupra managementului
relațiilor cu clienții, acesta adaptându‐se constant în funcție de comportamentul
consumatorilor. Succesul rețelelor de socializare a determinat furnizorii de CRM să
se integreze în acest trend, rezultând conceptul de SocialCRM (sCRM), dispozitivele
mobile au generat apariția MobileCRM (mCRM), combinația tehnologiilor sociale cu
cele mobile: MocialCRM, iar integrarea mediului online cu strategiile de marketing
conferă un nou sens managementului relațiilor cu clienții, şi anume Electronic CRM
(eCRM).

5.3. CRM – definire şi motivaţii

La fel ca multe alte concepte, CRM este unanim considerat interesant, fără a
ajunge la un consens al definirii sale. Aşa cum am arătat anterior, a apărut pe fondul
expansiunii ERP şi a abordării transfuncționale, a transformării marketingului şi
implementării unei strategii orientate pe client. Se spune foarte inspirat că astăzi
clientul este o „țintă în mişcare”, pe o piață dinamică şi tot mai puțin structurată, cu
segmente şi nişe în schimbare, motive pentru care se ajunge la dezvoltarea unei
relații cu fiecare client în parte12. Tehnologia informației a susținut reconfigurarea
activității organizaționale în jurul doleanțelor şi satisfacției clienților. Astfel, bazele
de date adună la fiecare interacțiune cu clienții, în oricare departament şi prin
diferite canale de comunicare, date privitoare la fiecare client, sursă excelentă de
dezvoltare a unei relații consistente, pe termen lung, cu acesta.
Deşi relativ tânăr, conceptul CRM continuă să evolueze. J. Curry, consultant
CRM pentru firmele mici13, consideră că cel care a inventat acest concept este însuşi
Peter Drucker, în 1954, prin afirmația „cea mai importantă activitate a oricărei
companii este atragerea şi păstrarea clienților”. Concluzionând, CRM desemnează
procesul de atragere, păstrare şi dezvoltare a clienţilor, măsurat prin numărul de
clienţi, profitabilitatea lor, comportamentul consumatorilor şi satisfacţia acestora,
transformând organizaţia întruna orientată şi centrată pe client. Obiectivul urmărit
la nivel organizațional prin adoptarea acestor platforme îl reprezintă creşterea
valorii clienților în întreprinderea centrată pe client.

12 C. Bălan, op. cit., p. 8.
13 Citat de www.technologyevaluation.com, Guru roundtable 2: Thinking in the round, 2002.

5.3.1. Definirea CRM

Numeroase studii au relevat la începutul anilor 2000 procentul foarte mare de
eşecuri (peste 70%) al proiectelor CRM14, relevând numeroase dificultăți, atât de
ordin organizațional, cât şi tehnologic. META Group, una dintre cele mai renumite
organizații pentru anchetele desfăşurate în domeniul sistemelor informatice,
avertiza la începutul anului 2000 asupra riscurilor asociate proiectelor CRM.
Previziunea pesimistă s‐a bazat pe o anchetă în rândul a peste 2.000 de societăți
internaționale (câteva exemple: Sprint, Nortel Networks, Eastman Kodak sau PNC
Bank) şi a demonstrat că majoritatea organizațiilor cercetate nu au avut un plan de
acțiune concret şi nu au acordat suficiente fonduri în acest scop. Proiectele CRM s‐au
dovedit a fi extrem de fragmentate şi nu au privilegiat clienții, ceea ce a însemnat
îndepărtarea de scopul inițial: satisfacerea lor. Pentru susținerea concluziei sale,
META Group a mai făcut publice şi următoarele rezultate:
64% dintre organizațiile cuprinse în studiu nu stabiliseră metrici pentru
cuantificarea proiectelor CRM;
mai puțin de 10% şi‐au recuperat investiția inițială în aceste tehnologii;
mai puțin de 30% au inițiat proiecte concrete pentru adoptarea unui mediu
CRM operațional şi analitic;
deşi piața a demonstrat importanța web‐ului ca modalitate de contact cu
clientul, metodele tradiționale (vânzarea prin corespondență sau cea față‐în‐față) au
continuat să predomine (95%);
subiecții nu erau familiarizați cu tehnologia, s‐au primit explicații diverse,
contradictorii chiar şi cel mai adesea, incomplete; procentual, numai 78% dintre
aceştia au considerat CRM un imperativ major pentru succesul afacerii, iar restul de
22% nu erau convinşi de importanța tehnologiei.
Aceste cifre susțin necesitatea înțelegerii clare a conceptului CRM, formularea
răspunsului la întrebarea „în ce constă exact CRM, când şi cum se realizează
implementarea sa?”. Ca primi paşi spre înțelegere sunt găsirea şi citirea definițiilor
propuse de analişti şi consultanți (o selecție în tabelul 5.1).
Parcurgerea definițiilor din tabelul 5.1 susține ideea subliniată la începutul
paragrafului, şi anume: CRM poate înseamna altceva pentru fiecare în parte
(afirmație subliniată şi în literatura de specialitate 15), cu argumentul că în acest
concept se regăsesc elemente din marketing, management şi sisteme informaționale,
ceea ce face ca definiția să fie orientată spre filosofia marketingului, strategie sau
tehnologie informațională. Într‐un articol publicat în 201116 s‐a realizat un studiu
asupra definițiilor (eşantionul a fost de 23) şi s‐a constatat că 48% sunt orientate
spre strategie, 22%, spre tehnologie, 17%, spre filosofia de marketing, iar restul sunt
combinații ale acestora. Într‐o interesantă unificare a definițiilor, CRM este definit ca

14 J.C. Hoekstra, Direct Marketing, Wolters‐Noordhoff, Groningen, 2001.
15 F. Buttle, Customer Relationship Management: Concepts and Tools, Elsevier, Oxford, 2004.
16 K. Rababah, „A unified definition of CRM towards the successful adoption and implementation”,
Academic Research International, vol. 1, nr. 1, 2011, p. 222.
o filosofie care stă fundament pentru definirea strategiei şi aplicarea tehnologiilor
informaționale17. Dincolo de caracterul vag al acestei definiții, ea sugerează ideea de
a combina abordările. Totodată, deşi pe locul 2 între abordările CRM, credem că o
definiție tehnologică este cel mai puțin inspirată. În opinia noastră, CRM nu este o
soluție informatică, aceasta este doar componenta‐suport pentru implementarea
unei strategii de dezvoltare a relațiilor cu clienții pe termen lung, pe fondul filosofiei
unui marketing relațional reinventat continuu.

Tabelul 5.1
Definiţii CRM 18

Gartner Group: CRM face parte din categoria strategiilor de afaceri, destinată să
optimizeze profitabilitatea întreprinderii pe baza sporirii satisfacției clientului. Pentru a
pune în practică această strategie o organizație trebuie să‐şi ajusteze comportamentul şi
să implementeze procese şi tehnologii care să sprijine interacțiunea controlată cu clienții,
prin toate canalele de comunicare.
CRMguru.com: CRM este o strategie de afaceri prin care se selectează şi se gestionează
clienții în vederea optimizării valorii acestora pe termen lung. CRM necesită o cultură
managerială centrată pe client, care să susțină procese eficiente de marketing, vânzări şi
service. Aplicațiile CRM pot contribui la eficientizarea relațiilor cu clienții, în condițiile în
care organizația dispune de conducerea, strategia şi cultura potrivite.
Paul Greenberg (analist englez): CRM este un sistem complet care: 1) furnizează un mijloc
şi o metodă de a îmbunătăți experiența unui client particular, astfel încât acesta să rămână
un client fidel; 2) furnizează mijloace atât tehnologice, cât şi funcționale, pentru a
identifica, atrage şi reține clienții; 3) furnizează o imagine unitară a clientului în cadrul
întregii organizații.
Helmar Rudolph, consultant CRM: „Toată lumea vede CRM‐ul legat de vânzări încrucişate,
vânzări în sus, vânzări în jos, vânzări, vânzări, vânzări… Răspunsul este nu. CRM nu este
despre vânzări. Este vorba, de fapt, despre reumanizarea relației dintre companie şi client,
despre a afla de ce anume are nevoie acesta şi, mai cu seamă, de ce nu are nevoie.”
Yurong Xu: CRM este o strategie de afaceri cu scopul de a îmbunătăți interacțiunea fiecărui
client cu organizația, ceea ce, cu puțin noroc, duce la obținerea satisfacției acestuia, care
determină loialitatea lui, iar aceasta aduce vânzări noi. Valoarea interacțiunii cu clientul se
măsoară prin creşterea capacității de înțelegere a clientului de organizație.
Ranjit Bose: CRM înseamnă utilizarea TI pentru achiziția, analiza şi folosirea cunoştințelor
despre clienți cu scopul de a înțelege mai bine nevoile şi doleanțele lor. Termenul de client
trebuie lărgit față de înțelesul clasic, pentru a cuprinde şi furnizorii, partenerii comerciali
sau de distribuție.

17 C.D. Pedron, A.Z. Saccol, „What lies behind the concept of Customer Relationship Management?
Discussing the essence of CRM through a phenomenological approach”, Brazilian Administration
Review, vol. 6, nr. 1, 2009, pp. 34‐49.
18 Definiții citate în D. Fotache, L. Hurbean, Soluţii informatice pentru gestiunea afacerilor. ERP, Editura
Economică, București, 2004, p. 102, dar și în R. Bose, „Customer relationship management: key
components for IT success”, Industrial Management & Data Systems, vol. 102, nr. 1/2, 2002, p. 89 și X.
Yurong, C. Y. David, L. Binshan, C. David „Adopting customer relationship management technology”,
Industrial Management & Data Systems, vol. 102, nr. 8, 2002, p. 442.

Ilustrarea grafică simplificată a unui sistem CRM este redată în figura 5.1.
Ideea este că organizațiile de astăzi trebuie să interacționeze cu clienții prin multiple
canale de comunicație: web sau poştă electronică, centre de apel, vânzări directe sau
prin rețele de distribuție.

Web/e-mail
Call Center Baza de Aplicaţii
Clienţi Vânzări directe date back-office
Reţele de CLIENŢI
distribuţie

Figura 5.1. Structura simplificată a unui CRM clasic

Cum se vede din figura 5.1, tehnic vorbind, CRM nu pare greu. Atunci de ce
proiectele CRM încă dau greş? Explicația ar fi aceea că succesul nu depinde de
tehnologie şi sistemul de aplicații ales, ci de filosofia de management al
marketingului şi de modul de concretizare a acesteia într‐o strategie de cucerire a
clienților.
Avantajele oferite de soluțiile informatice CRM în condițiile unei noi strategii
de marketing sunt:
reducerea costurilor de publicitate;
axarea politicii firmei pe nevoile clienților,
constatarea rapidă a eficienței unei campanii de marketing;
posibilitatea rivalizării cu principalii concurenți nu numai la nivel de
prețuri, ci şi prin serviciile oferite;
evitarea cheltuielilor excesive presupuse de clienții puțin rentabili şi
reorientarea resurselor către clienții cu înaltă rentabilitate;
depăşirea întârzierilor din dezvoltarea şi comercializarea unui produs
(optimizează ciclul de comercializare);
optimizarea canalelor comerciale şi a contactelor cu clienții.

5.3.2. Motivaţii şi opţiuni de implementare a CRM

Conform unui sondaj realizat în Marea Britanie19 în rândul organizațiilor care
au implementat aplicații CRM, motivaţiile acestora sunt legate în principal de
îmbunătățirea relațiilor cu clienții (vezi figura 5.2). Răspunsurile sunt notate pe o
scară de la 1 la 5, unde 1 înseamnă neimportant, iar 5 foarte important. Nu scăderea
costurilor, ci creşterea satisfacției clienților este prima pe listă, la egalitate cu
furnizarea de informații strategice şi urmată de sporirea numărului de clienți.

19 www.conspectus.com/2010/march

Sursa: www.conspectus.com, martie, 2010.
Figura 5.2. Motivaţiile implementării de aplicaţii CRM

Aşa cum am mai precizat, existența unui sistem ERP în organizație nu trebuie
să fie ruptă de a CRM‐ului. Fără a fi nevoie ca ele să provină de la aceeaşi casă de
software, ele pot să comunice între ele, deşi merită spus că CRM‐ul este cel care are
nevoie de datele pe care un ERP le gestionează şi mai puțin invers. Cu cât fondul de
date al CRM‐ului este mai mare, cu atât acesta poate furniza mai multe informații, în
special cele pe care să se croiască strategia firmei legată de creşterea satisfacției
clienților. Totuşi, de multe ori în practica de afaceri CRM‐ul funcționează
independent, lucru relevat în acelaşi studiu menționat mai sus (vezi figura 5.3).

Sursa: www.conspectus.com, martie, 2010.
Figura 5.3. Aprecierea beneficiilor CRM de beneficiari

Sigur că primul pas firesc ar fi implementarea unei platforme integrate ERP,
care se extinde apoi natural cu alte module, între care se înscrie şi CRM. Ideal este
atunci când cele două soluții se integrează nativ, ceea ce se realizează când ele
provin de la acelaşi furnizor, dar practica relevă că această situație nu este cea mai
întâlnită. Credem că firmele care au soluții ERP costisitoare preferă să aleagă un
CRM de la un alt furnizor, care are o ofertă mai avantajoasă ca preț, dar poate fi cazul
că firmele au un ERP oarecare, dar doresc un CRM performant (cum sunt cele din
domeniul distribuției sau de logistică). În fine, mai putem extrage din acel studiu o
idee pe care managerii sistemelor informatice trebuie să o aibă în vedere la
demararea unui proiect CRM: multe implementări CRM se fac independent de ERP,
iar ulterior se relevă utilitatea şi nevoia de a integra cele două platforme (17% din
managerii intervievați au declarat că s‐ar dori integrarea CRM‐ERP).
Din punctul de vedere al acoperirii funcţionale a relaţiilor cu clienţii, distingem
următoarele trei mari subansambluri care se au în vedere la implementarea unui
CRM de tip operațional sau operațional strategic:
Sales Forces Automation – SFA (automatizarea forței de vânzări) care
oferă echipelor de vânzări instrumente de urmărire a clienților, prospecte de piață,
scheme de calcul al prețurilor şi reducerilor, informații despre acțiuni promoționale
şi chiar despre stocuri şi lanțul de aprovizionare. O aplicație SFA are la bază un
planificator de activități care funcționează în regim individual, pentru fiecare client
şi la nivel de grup. Agenții planifică interacțiunile cu clienții, coordonează acțiunile
din zona vânzărilor, stabilesc legături cu departamentul de marketing, cel de service
şi de asistență publică. De asemenea, la aplicațiile SFA o caracteristică definitorie
este mobilitatea, căci ele pot fi utilizate pe teren cu sprijinul dispozitivelor portabile
(PDA, laptop, dar şi smartphone);
Marketing Automation, prin care sunt definite segmentele şi tipologia
clienților, precum şi controlul campaniilor de promovare a produselor şi serviciilor,
urmate de măsurarea rezultatelor. Intervin aplicații care susțin selectarea şi
segmentarea bazei de clienți, urmăresc contactele cu clienții şi eventual evaluează
rezultatele contactelor pentru a determina grupuri țintă, adecvate pentru viitoarele
campanii. Dincolo de facilitățile operaționale la nivelul activității de marketing,
această componentă poate să deservească şi nivelul destinat managementului
strategic. La acest nivel este necesară o viziune integratoare (comunicare cu
platforma ERP), pentru că trebuie să cuprindă, alături de informațiile actuale şi
istorice legate de clienți, şi informațiile provenind din celelalte departamente, cum
ar fi cel financiar‐contabil, cel de producție, dezvoltare etc. Posibilitățile de analiză
strategică sporesc odată cu integrarea unor date externe, cum ar fi cele demografice
sau cele provenind din studii de piață. La acest nivel, datele sunt integrate în
depozite de date;
asistenţă şi service după vânzarea produsului/serviciului, prin care se
oferă suport nelimitat clienților.
Relația marketing‐CRM este deosebit de strânsă, iar o implementare CRM
trebuie corelată cu strategia de marketing a organizației. După ţinta pe care o
vizează, vorbim despre patru tipuri de tehnologii CRM:
pentru recuperarea şi păstrarea clienţilor. Focus: clienți care au avut
intenția de a achiziționa un produs sau un serviciu, dar au renunțat în ultimul
moment, ori s‐au răzgândit pentru că au fost atraşi de altă ofertă. De regulă, acest
segment scapă atenției departamentului de marketing;
de fidelizare. Focus: segmentul cel mai stabil din masa clienților firmei.
Prin tehnologiile CRM sunt învățate gusturile şi preferințele, sunt cunoscute
doleanțele, se acordă bonusuri şi premii;
diversificarea şi îmbunătăţirea ofertei. Focus: întreaga masă de clienți.
Sunt popularizate noutățile, se fac testări şi se desfăşoară campanii de marketing;
prospectarea pieţei. Focus: clienții posibili şi segmentele de piață nou‐
descoperite.
Din punct de vedere tehnologic, procesele CRM rulează numai date
informatizate. Principala problemă tehnică este legată de administrarea bazei de
date care să integreze logic şi operațional toate datele, pentru că practic sunt mai
multe baze de date care trebuie aduse la un numitor comun.
O tehnologie care se regăseşte tot mai mult în sistemele CRM este cea a
depozitelor de date şi cele asociate acestora. Depozitele de date pot oferi informații
valoroase despre performanța vânzărilor, profitabilitatea clienților, dar şi la nivel de
produs sau linie de produse, precum şi alți indicatori calculați cu ajutorul tehnicilor
OLAP, data mining, drilldown etc. Practic, vorbim despre tehnologii Business
Intelligence care se regăsesc sub formă de aplicații analitice în sistemele CRM (vezi
taxonomia CRM din paragraful următor).
În diverse formule practice şi cu diferite tehnologii, CRM reuneşte aplicațiile
care promovează interacțiunea directă dintre clienți şi furnizori, prin intermediul
angajaților şi proceselor presupuse, pe întreaga durată a ciclului de viață al
clientului. Pachetul de aplicații presupune o viziune cuprinzătoare, integrată, asupra
clientului, care este aşezat în centrul preocupărilor, şi mai înseamnă integrarea
(sub)funcțiunilor întreprinderii (vânzări, marketing, servicii postvânzare, garanție şi
service), toate subordonate efortului de a creşte satisfacția şi mulțumirea clientului,
ceea ce diferențiază firma față de competitorii săi şi duce în final şi la creşterea
vânzărilor.

5.4. Taxonomia aplicaţiilor CRM

CRM înseamnă construirea unei forțe de vânzări care gândeşte în spiritul
clientului, nu în cel al produselor şi serviciilor oferite 20. Tehnologia generează o
adevărată cultură a clientului, care presupune nu numai implementarea aplicațiilor
CRM, ci şi schimbări organizaționale şi de mentalitate.
Evoluțiile tehnologice şi extinderea preocupărilor în sfera relațiilor cu clienții
au transformat CRM într‐un „spațiu software” sau „un ecosistem”, în care sunt
reunite concepte precum service postvânzare, autoservice (nu pentru maşini!),
analize de marketing, e‐commerce colaborativ, portaluri pentru angajați, depozite şi

20 C.P. Smalley, CRM: Now what?, www.technologyevaluation.com, 2002.

magazii de date, date despre date (metadate), inteligență economică (ne referim aici
la aplicații Business Intelligence), OLTP şi OLAP şi altele. Toate acestea se regăsesc în
cele trei subdomenii ale sistemului, adică: CRM operațional, CRM analitic şi CRM
colaborativ (vezi figura 5.4).

Arhitectură
Arhitectură workflow
Workflow
d CLIENT
d
Forţa de
vânzare
suport
vânzări
Centrală
automată E-mail
Web / eBiz
Web Form
Web
Chat
VoIP IVR Fax Posta
Poştă
Mesagerie integrată / rutare inteligentă CRM colaborativ
Canale de
Canale de Centru
Centru
vânzare Vânzări Marketing
vanzare interacţiune
interactiune
clienţi
clienti
CRM operaţional Baze de date CRM

CRM analitic
Conturi Service Campanii Gestiunea
clienţi clienţi cunoştinţelor
Depozit de date
Inteligenţa economică
Producţie
Producţieşişi Financiar-
Financiar- - analiza profitabilităţii
Logistică
logistică Contabilitat
contabilitate - performanţa angajaţilor
ERP, SCM - eficienţa campaniilor
e-Procurement - acceptarea produsului,
Extragere, transformare şi încărcare a datelor

Sursa: Garland, R., CRM is busting out of its britches, www.technologyevaluation.com, 2001.
Figura 5.4. Structura aplicaţiilor CRM

1) CRM operaţional este inima unei aplicații CRM întrucât:
include componentele care interacționează cu aplicațiile operaționale
(backoffice) – în principal ERP, dar şi e‐Procurement sau SCM, în scopul de a realiza
vânzarea;
automatizează sau sprijină sarcinile zilnice ale echipelor de vânzare,
marketing şi service;
facilitează fluxul informațional dintre echipe şi transmiterea informațiilor
în exterior către departamentele financiar şi logistică.
Simplificând, putem să considerăm CRM operațional ca fiind CRM intern,
tactic, dar trebuie să se înțeleagă clar că este vorba despre interacțiunea cu clienții,
dar şi partea care nu se vede, din spatele cortinei.
Componenta centrală în interacțiunea dintre clienți şi organizație este centrul
de apel21 (call center). Termenul evocă în principal telefonia, dar semnificația actuală
cuprinde toate canalele prin care clientul intră în contact cu organizația, motiv
pentru care unii preferă termeni care să evite confuzia folosind denumiri precum
centru de comunicare sau centru de contact. Oricum s‐ar numi, ideea este că,
indiferent dacă este vorba despre un apel telefonic, un mesaj e‐mail, o interacțiune
prin site‐ul web, o scrisoare clasică, un fax etc., aici se face identificarea clientului,
redirecționarea (dacă este cazul) spre persoana sau serviciul potrivit şi este reținut
istoricul operațiunii. Identificarea clientului se realizează pe baza numărului
apelant, prin intermediul Computer Telephony Integration (CTI).
Evoluția acestui tip de aplicații se observă şi din înlocuirea termenului
Customer Support Center cu Customer Interaction Center, ceea ce extinde
preocupările din sfera vânzărilor în cea a marketingului.
2) CRM analitic este un subset din aplicațiile de Business Intelligence ale
organizației, care vizează reunirea tuturor datelor cu relevanță pentru zona
clienților/vânzărilor, analiza şi transformarea lor în informații şi furnizarea acestora
la momentul oportun. CRM analitic este o piesă importantă în puzzle‐ul inteligenței
economice la nivelul întreprinderii, concentrată asupra interacțiunii cu clienții şi
satisfacției acestora.
Măsurând reacțiile clienților şi interacțiunile cu aceştia, analiza furnizează
informații despre:
succesul campaniilor de marketing;
indicatorii de vânzări şi performanțele echipelor de vânzări;
profitabilitatea clienților, în funcție de costurile de vânzare şi service;
succesul liniilor de produse;
previziunile vânzărilor etc.
O analiză mai specială este „web clickstream” prin care se desprind informații
privind conținutul site‐ului web al companiei (opiniile vizitatorilor, ce apreciază şi
ce nu, aşteptările lor ş.a.m.d.). Analizele sunt posibile datorită noilor tehnologii în
timp real bazate pe magazii de date, instrumente OLAP şi interfețe utilizator de tip
„tablou de bord”. Rezultatele sunt oferite prin portaluri informaționale pe web, cu
acces intern, acces numai pentru clienți sau combinat.
3) CRM colaborativ (eCRM) vizează eforturile cooperative din sfera CRM,
concretizate în: conferințe pe web, gestiunea formularelor web, gestiunea automată
a e‐mailurilor, gestiunea unificată a mesajelor şi rutarea inteligentă a acestora,
instrumente de asistență web, precum Live Chat sau Voice over IP (VoIP), cât şi
navigarea colaborativă şi serviciul Call Me Now. Tendința de a crea noi şi noi
mijloace de interacțiune cu clientul prezintă riscul creşterii semnificative a
cheltuielilor postvânzare. În plus, este vorba despre metode impersonale de

21 M. Sârbu, „CRM – un termen la modă”, Net Report, mai, 2002, pp. 24‐28.

interacțiune cu clienții. Dar, dacă mulțumirea clienților contează destul, iar creşterea
bugetului nu este o problemă pentru firmă, implementarea aplicațiilor e‐CRM este
oportună.
4) CRM social – adăugarea unei strategii de mass‐media pentru socializare la
inițiativele unui CRM este deosebit de importantă pentru a rezista în mediul de
afaceri din secolul XXI. Oamenii fac afaceri cu cei pe care îi plac şi în care au
încredere. Dar cum ajungi să‐i convingi pe oameni să te placă şi să aibă încredere în
tine într‐o lume web 2.0? Consumatorii vor căuta să găsească din ce în ce mai multă
informație de care au nevoie pentru a lua decizii corecte, decât să aştepte ca
informația să fie trimisă sau împinsă către ei. Clientul „sociabil” al secolului XXI mai
degrabă recurge la Google atunci când caută o informație, decât să verifice căsuța de
mesaje primite. Importantă este şi informația rezultată în cercetarea raportului
Technorati 2009 State of the Blogosphere22, realizat de oameni de afaceri şi bloggeri
americani, potrivit căruia există 22,6 milioane de bloggeri şi 94,1 milioane de cititori
de bloguri numai în America. De aici rezultă importanța acestei populații şi de aceea
platformele CRM vor fi transformate în ideea cuprinderii segmentului „social” actual
(figura 5.5).

CRM TRADIȚIONAL CRM SOCIAL

• Axat pe informație şi procese • Axat pe conținut şi comunicare
• Accent pe nivelul operațional • Accent pe oameni şi comunități
• Focus: oameni, procese şi tehnologii • Focus: automatizare, analiză conținut
şi încredere

Sursa: Leary, B., CRM Essentials, www.BrentLeary.com
Figura 5.5. CRM tradiţional versus CRM social

Pentru a înțelege cum vor evolua platformele actuale către includerea
segmentului social, prezentăm în figura 5.6 câteva elemente definitorii potrivit
Ghidului de înţelegere Social CRM publicat de Chess Media Group23 în iunie 2010 – un
grup de consultanți în afaceri din SUA care au competențe pe dezvoltarea Social‐
CRM, Enterprise 2.0 şi strategii media sociale.

22 http://technorati.com/blogging/article/state‐of‐the‐blogosphere‐2009‐introduction/
23 Chess Media Group, Guide to understanding Social CRM, June, 2010, disponibil la http://www.
chessmediagroup.com/wp‐content/uploads/resource/95dd4dd11f5def709a3683f4efd97d26.pdf

Sursa: Chess Media Group, Lieberman, M., Understanding Social CRM, June, 2010.
Figura 5.6. Evoluţia CRM spre CRM social

5) CRM integrat – sistem CRM care combină variatele aplicații descrise mai
sus: vânzări, marketing, service, e‐CRM, SFA ş.a.

În 2010 Business Software a dat publicităţii raportul Top 10 Social CRM Software, disponibil
odată cu încărcarea raportului Top 40 CRM Software Vendors la adresa: http://www.
businesssoftware.com/crmevaluation/top40crmvendors.php. În acest top se regăsesc
Microsoft Dynamics CRM, Salesforce.com, NetSuite, SAP CRM, Sage CRM, SalestrackCRM etc.
La începutul anului 2010, SAP anunţa24 integrarea în versiunea 7.0 CRM a unei serii de
funcţionalităţi social media, în principal twitter, dar se vor adăuga probabil şi altele.
Mişcarea este surprinzătoare pentru un furnizor ca SAP, care, cel puţin pe partea de ERP,
este foarte adânc ancorat în termeni precum conservator şi enterprise. Pe scurt, utilizatorii
vor avea posibilitatea să interacţioneze cu clienţii pe twitter şi să monitorizeze activitatea
acestora, să identifice oportunităţi pe baza mesajelor, să desfăşoare campanii de marketing
pe twitter etc. Un demo privind generarea unei campanii de marketing pe twitter în SAP
CRM puteţi urmări pe youtube la adresa: http://www.youtube.com/watch?v=Qn6JAiNjwSM&
feature=player_embedded.

24 Sursa: http://www.crmreview.ro/?p=370

5.5. Piaţa CRM

Pe piața platformelor integrate pentru managementul relațiilor cu clienții,
întâlnim mici producători specializați pe unele aplicații CRM, dar şi furnizori care
livrează sisteme integrate CRM. În cazul acestei piețe putem vorbi despre oferte
competitive ale furnizorilor consacrați şi despre oferte de tip open source. De
asemenea, alternativa SaaS este eficientă în cazul acestor platforme şi este practicată
astăzi şi de furnizorii de top. Conform studiului realizat de Gartner, Market Share
Analysis: Customer Relationship Management Software, Worldwide, 201225 (publicat
pe 18 aprilie 2013), piața CRM a urcat de la 16 miliarde de dolari la 18 miliarde de
dolari cu o rată de creştere de 12,5% din 2011 până în 2012. În ceea ce priveşte
ponderea pe piața CRM a soluțiilor onpremise în comparație cu cele ondemand este
apreciată la 60% şi 40%, cele din urmă având o evoluție spectaculoasă.
Pe piața CRM sunt prezenți principalii furnizori de platforme ERP consacrați
pe plan mondial. Observăm ofensiva platformelor CRM open source în cadrul
companiilor, o ofensivă confirmată de studiile de piață realizate în ultima perioadă,
care demonstrează că din ce în ce mai multe companii iau în calcul această opțiune,
în ideea de a beneficia de avantajele utilizării unui CRM la costuri cât mai reduse.
Putem vorbi despre categorii diferite de platforme de management al relațiilor
cu clienții, în funcție de metodologia de implementare, mecanismele de întreținere şi
de rulare a proceselor de afaceri, după cum se observă în continuare:
onpremise CRM – se poate traduce „la sediu”, cunoscut şi ca soluție on
site sau inhouse CRM este o platformă găzduită de beneficiar şi administrată de
propriul departament IT. Suportul este asigurat conform contractului de mente‐
nanță, iar personalul IT intern este responsabil de tot ce nu este prevăzut în
contractul cu furnizorul/implementatorul soluției CRM legat de instalarea
componentelor hardware şi software, integrarea soluției cu sistemele existente,
precum şi administrarea ei;
hosted CRM sau ondemand CRM – soluție CRM găzduită sau „la cerere”,
cunoscută şi ca web based CRM26, presupune că toate componentele software şi
hardware sunt achiziționate, instalate, testate şi întreținute de un furnizor de
servicii de la distanță. Furnizorul este responsabil şi de administrarea şi găzduirea
datelor. Companiile nu au nevoie decât de acces web printr‐un browser obişnuit
pentru a accesa şi a beneficia de serviciile platformei CRM, plătind lunar utilizarea
acesteia. Pentru platformă se plăteşte un abonament care poate fi extins şi la resurse
hardware, dacă acestea nu sunt suficiente în organizația‐client. Conform studiilor de
piață27, CRM‐ul este principalul beneficiar al modelului Software as a Service (SaaS).
Un studiu Forrester Research (decembrie 2009) arată că oferta CRM în model SaaS

25 http://www.forbes.com/sites/louiscolumbus/2013/04/26/2013‐crm‐market‐share‐update‐40‐of‐
crm‐systems‐sold‐are‐saas‐based/
26 Pentru o prezentare comparativă a variantelor ondemand şi onpremise vezi şi
http://www.business‐software.com/crm/hosted‐crm/hosted‐crm.php
27 R. Ghițulescu, „O altfel de abordare a ofertei CRM în regim SaaS”, Martket Watch, nr. 121, 12 ianuarie
2010, disponibil la adresa: http://www.marketwatch.ro/articol/5551/O_altfel_de_abordare_a_ofertei_

CRM_in_regim_SaaS/
înregistrează o creştere susținută la nivel mondial, din ce în ce mai mulți actori, de la
furnizori consacrați de soluții on‐premise la start‐up‐uri, diversificând oferta
existentă pe piață. Un alt studiu comparativ realizat de Gartner (tot la finele anului
2009) în Germania, Franța şi Marea Britanie, pe subiectul utilizării aplicațiilor în
mod SaaS în cele trei țări, demonstrează că soluțiile CRM sunt cea mai utilizată
aplicație în model SaaS. Conform clasamentului Gartner, francezii sunt cei mai mari
consumatori de aplicații în regim SaaS, englezii sunt pe aproape, iar nemții, ultimii;
enterprise CRM – o soluție completă, integrată cu ERP‐ul, care acoperă
atât zona frontoffice cât şi backoffice şi include toate segmentele acoperite de
managementul integrat al relațiilor cu clienții: sales force, marketing, contact center
şi help desk, coordonează şi consolidează toate procesele dispersate şi repetitive.
Departamentele de vânzări, marketing, service şi suport au instrumente solide de
analiză a datelor, de elaborare a rapoartelor‐suport pentru procesul decizional;
mobile CRM – acel tip de soluție care permite angajaților, reprezentanților
de vânzări, departamentului de personal şi suport să acceseze şi să interacționeze cu
clienții, în mişcare, cu ajutorul telefoanelor mobile, PDA‐urilor, Blackberry,
tabletelor şi a altor dispozitive wireless care sunt conectate la internet. Utilizatorii
pot să extragă, să actualizeze şi să gestioneze informațiile legate de consumatori şi
procesele de vânzare la fel de uşor ca în birou.
O categorie de CRM care s‐a conturat mai bine în ultima perioadă este cea
menită să deservească firmele mici şi mijlocii, i‐am putea spune CRM simplu (CRM
lite, în engleză), care oferă funcționalitatea dorită, dar fără complexitatea şi costurile
cerute marilor companii. Concret, un CRM simplu este menit unei firme care nu are
mai mult de 500 de clienți şi/sau mai puțin de 50 de angajați în domeniul relațiilor cu
clienții (vânzări, marketing şi service postvânzare). Sau ar putea fi o soluție bună
pentru diviziile specializate separate din cadrul marilor companii cu maximum 100 de
utilizatori CRM. Un CRM simplu este focusat pe facilități de management al
contactelor, care să‐i sprijine pe utilizatori în activitățile specifice, şi nu pe funcțiuni cu
acoperire transdepartamentală. Ca mod de livrare a acestor soluții, există oferte de
implementare clasică, la sediul beneficiarului, dar cele mai multe sunt sisteme bazate
pe web, livrate la cerere (on‐demand). Această opțiune de implementare concură la
asigurarea unui TCO redus, astfel ca CRM‐ul să fie perceput ca interesant şi convenabil
sub aspectul costurilor (se elimină investiția în echipamente, nevoia de personal
specializat şi implicit costurile aferente, precum şi costurile de mentenanță).
Pentru fiecare dintre aceste tipuri de CRM există o ofertă bogată pe piață – de
la SAP CRM la mini‐CRM – şi un număr semnificativ de furnizori, aşa cum se va arăta
în paragrafele următoare.

5.5.1. CRM în oferta marilor case de software

Prezentarea pieței CRM nu este tocmai simplă, deoarece este fragmentată de
interesul clienților, de talia şi profilul lor, cât şi de caracteristicile mediului de afaceri
corespunzător, astfel că s‐au dezvoltat chiar şi soluții verticale de CRM. De
asemenea, putem analiza piața din perspectiva tipurilor de platforme CRM ofertate.

Pe această piață, lider incontestabil pe ansamblu rămâne SAP CRM. SAP CRM
permite furnizarea de servicii de suport clienților prin intermediul unor canale
multiple – centre de interacțiune, centre de servicii web, managementul serviciilor şi
solicitărilor, administrarea bazei de clienți. Platforma dezvoltată specific, cu
funcționalități pentru întregul ciclu de relaționare cu clienții, asigură administrarea
eficientă a activităților de marketing, vânzări, servicii, analiză, activități pe teren,
centre de interacțiune, comerț electronic şi relația cu partenerii, ca şi pe verticală,
unde se bucură de o bună apreciere în rândul specialiştilor. Totuşi, deşi în 2008 şi
2009 a rămas în fruntea clasamentului, se observă că SAP CRM a pierdut teren
considerabil în fața competitorilor săi Oracle, Microsoft şi Salesforce.com, motiv
pentru care în 2010 a lansat o nouă versiune a produsului său, care a primit
referințe excelente din partea analiştilor.

Forrester Research, una dintre cele mai cunoscute companii de cercetare de piaţă în
domeniul tehnologiei, a confirmat poziţia de lider a soluţiei SAP CRM 7.0 în studiul
său intitulat The Forrester Wave: CRM Suites For Large Organizations, care a
cuprins 18 soluţii de la producători diferiţi. Soluţia CRM 7.0 de la SAP permite o
utilizare mai uşoară cu ajutorul interfeţei web, în timp ce asigură durate şi costuri
de implementare mai mici, respectiv costuri totale de deţinere îmbunătăţite,
performanţe remarcate de Forrester. „Odată cu lansarea SAP CRM 7.0, compania
oferă un produs complex pentru managementul vânzărilor, al marketingului şi al
serviciilor, dar şi managementul partenerilor”, se arată în argumentaţia din
raportul Forrester. „Compania oferă de asemenea un nou pachet de servicii şi
aplicaţii, denumit Rapid Deployment of SAP CRM, care asigură o perioadă rapidă de
implementare de şaseopt săptămâni a acelor funcţionalităţi esenţiale de vânzări,
marketing şi servicii”, se arată în raportul Forrester, care subliniază în repetate
rânduri calitatea interfeţei de utilizare28.

Oracle are de asemenea o poziție privilegiată pe piața CRM, întărită
semnificativ prin fuziunea cu Siebel29, obținând mai multă notorietate şi acaparând
un segment de piață format mai ales de companii mici şi mijlocii.

28 Sursa: http://www.marketwatch.ro/articol/6947/Forrester_apreciaza_pozitiv_solutia_CRM_de_la_S
AP/ (publicat în 21/07/2010).
29 Siebel CRM Systems a fost fondată în 1993 de Thomas Siebel, având ca obiect exclusiv de activitate
proiectarea, dezvoltarea şi implementarea de aplicații CRM. Primele produse lansate au fost aplicații
SFA, apoi au trecut la dezvoltarea de sisteme complete CRM. La sfârşitul anilor ’90 Siebel Systems era
numărul 1 pe piața CRM, ajungând la o impresionantă cotă de 45% în 2002. Pe 12 septembrie 2005,
Oracle a anunțat fuziunea prin cumpărare cu Siebel pentru suma de 5,8 miliarde de dolari. Vezi mai
multe pe http://en.wikipedia.org/wiki/Siebel_Systems
În ianuarie 2006, Oracle a achiziţionat compania Siebel30, completânduşi oferta soluţiilor CRM
cu funcţionalităţi de top. În 2008, compania a început certificarea unor parteneri locali de
Siebel – Novensys, Ness, Omnilogic/SDC, Vector Software, care vor adresa cu preponderenţă
industrii precum sectorul public, telecomunicaţii, servicii financiare, utilităţi, retail şi
distribuţie. Toate aceste eforturi sau concretizat în încheierea în România a unor contracte
pentru soluţii Siebel la sfârşitul anului 2007 şi în 2008. Conform studiului EAS IDC, piaţa
românească de CRM în 2008 a fost de 3,63 milioane de dolari, ocupând 6,8% din piaţa
totală de aplicaţii. Soluţiile pentru managementul vânzărilor au atins o valoare de 2,53
milioane de dolari şi au fost urmate de soluţiile pentru callcenter în valoare de 0,71
milioane de dolari, aplicaţii de marketing la 0,34 milioane de dolari şi service pentru clienţi
la 0,05 milioane de dolari. În 2009 piaţa a înregistrat o scădere apreciată între 2% şi 6%,
declin care a continuat şi în 2010. Revenirea care a început odată cu 2011 a fost timidă,
piaţa nemaiatingând ritmul de creştere din 20072008.

Din 2009, Microsoft începe să culeagă roadele optimizărilor realizate la nivel
de interfață pentru Microsoft Dynamics CRM, mulți dintre clienții Dynamics optând
pentru această soluție.

Microsoft Dynamics CRM este o soluţie de management al relaţiilor cu clienţii (CRM), care oferă
instrumentele şi funcţionalităţile necesare creării şi menţinerii unei imagini clare asupra
clienţilor, de la primul contact, până la achiziţie şi, ulterior, la procesele postvânzare, cu
ajutorul modulelor pentru vânzări, marketing şi servicii pentru clienţi. Platforma este
rapidă, flexibilă şi garantează îmbunătăţiri considerabile ale fiecărui proces de afaceri. Prin
configurarea unor relaţii mai strânse cu clienţii pot fi atinse noi niveluri de rentabilitate.
Chiar şi în cazul companiilor cu cele mai complexe procese de vânzări, Microsoft Dynamics
CRM oferă funcţionalităţi uşor de utilizat, pentru a optimiza modul în care departamentele
de vânzări şi marketing atrag clienţi noi, administrează campaniile de marketing,
gestionează activităţile de vânzări.
Microsoft Dynamics CRM este modul cel mai rapid şi mai accesibil de a adăuga funcţionalităţi
CRM în orice organizaţie care utilizează aplicaţiile sistemului Microsoft Office, inclusiv
Microsoft Office Outlook. Deoarece a fost conceput pentru a fi compatibil cu Office Outlook,
permite costuri de instruire reduse, o rată crescută de adoptare de utilizatori, un număr
mai mic de aplicaţii necesare, productivitate superioară şi un randament crescut al
investiţiei.
Prin intermediul Office Outlook, Microsoft Dynamics CRM le asigură angajaţilor accesul direct
la informaţiile despre clienţi de care au nevoie, indiferent dacă se află la serviciu sau în
deplasare.
În consecinţă, Microsoft Dynamics CRM garantează:
integrare perfectă cu Microsoft Office şi Office Outlook;
acces rapid şi eficient la date;

30 Sursa: http://www.oracle.com/global/ro/corporate/pressroom/bucuresti‐6mai08.html

spaţii de lucru personalizate;
calendar de service;
instrumente puternice de raportare şi analiză;
asistenţă excelentă pentru aplicaţii mobile.
Modulul CRM Mobile Express le permite utilizatorilor săi să vizualizeze, să creeze şi să modifice
instantaneu datele de pe orice dispozitiv cu conectare la internet. Mai mult, CRM Mobile
Express utilizează un browser web care nu necesită instalarea altor aplicaţii software.

O poziție importantă în topul general al furnizorilor de platforme CRM este
ocupată de Salesforce.com, o companie‐pionier a conceptului software as a service,
model de distribuție în care accesul se face pe baza unei subscripții la un site şi a
unui abonament lunar sau anual. Compania a avut succes datorită nişei pe care
activează şi nu operează decât pe modelul SaaS. Multe dintre afacerile mici şi mijlocii
nu‐şi puteau permite achiziționarea unui CRM performant şi mai ales întreținerea
costisitoare. Salesforce.com oferă clienților săi acces nelimitat la resursele software
în funcție de nevoile companiei şi update‐uri constante. Avantajele principale sunt
reducerea masivă a timpului de implementare a sistemului şi scalabilitatea. Alianța
cu Google (anunțată în primăvara 2008) pentru integrarea completă dintre plat‐
forma Salesforce.com şi Google Apps cântăreşte greu în concurența cu Microsoft.
Lider al pieței CRM în model SaaS, Salesforce.com nu este prezent oficial în România.
Încercăm acum o prezentare comparativă, prin mai multe caracteristici, a
câtorva dintre numele mari ale pieței CRM (figura 5.7).

Sursa: Top 40 CRM Software Vendors, raport 2010 Business Software, http://www. business‐
software.com/crm‐evaluation/top‐40‐crm‐vendors.php
Figura 5.7. Soluţii CRM – prezentare comparativă
În afară de numele de furnizori menționate, de notorietate şi neclintite din
topul CRM, aşa cum am precizat la începutul paragrafului, gama de furnizori este
deosebit de variată. Unii dintre ei sunt axați pe soluții integrate CRM, alții, pe
funcțiuni specifice precum Marketing Automation sau Customer Service, alții sunt
specializați pe aplicații call center sau sales force automation, pe care le oferă în
varianta clasică sau găzduite, sunt soluții care se adresează marilor companii şi
altele pentru afaceri mici şi mijlocii.
Aşa cum recomandă specialiştii din practica CRM, există o ofertă consistentă
de soluții CRM, astfel că printr‐o justă identificare a cerințelor şi o analiză atentă,
orice firmă poate să aibă soluția CRM cea mai potrivită.

5.5.2. Platforme CRM open source

Principalul argument al furnizorilor opensource legat de costul de achiziție,
considerabil mai mic comparativ cu cel al platformelor proprietare, sporeşte
atractivitatea soluțiilor opensource.
Există însă numeroase studii care demonstrează că TCO‐ul unei soluții open
source nu este unul chiar atât de mic şi că independența software clamată de
partizanii OS este destul de costisitoare pentru acele firme care nu dețin expertiza
tehnică necesară customizărilor, iar costurile contractelor de mentenanță nu pot fi
evitate.
Practica a demonstrat că slăbiciunea sistemelor ERP/CRM mari derivă chiar
din avantajele lor majore, şi anume flexibilitatea şi faptul că pot fi adaptate la
specificul clientului. Astfel de customizări determină costuri relativ mari de
implementare, proporțional cu dimensiunea organizației. Şi tocmai companiile mari
sunt cele care au mai multă nevoie de un ERP/CRM flexibil. De aici s‐ar putea deduce
că un open source este menit firmelor mici şi mijlocii. O deducție bună, aplicabilă
acum zece ani, dar astăzi open source este o soluție şi pentru marile companii, în
condițiile în care:
există furnizori de servicii de implementare specializați pe verticală;
partenerii de dezvoltare şi implementare ai ERP/CRM OS oferă extensii
preconfigurate pentru anumite verticale (domenii de activitate), astfel încât soluția
să rămână flexibilă, dar mai uşor adaptabilă unei industrii/ramuri de activitate.
Alte argumente pro open source au venit odată cu maturizarea acestui
concept31:
actualizările sunt disponibile foarte rapid;
sprijinul acordat în cadrul comunităților OS este excelent, deşi se pune
întrebarea „Cine garantează nivelul de expertiză al celor care oferă sfaturi şi
soluții?”.
Un ultim dar solid argument este legat de puterea exemplului notoriu: Coca‐
Cola Enterprise a optat pentru soluția open source sugar professional ondemand şi

31 Argumente preluate din articolul R. Ghițulescu, „Tertium non datur, oferta CRM OS în variantă
locală”, revista Market Watch nr. 114, 1 Mai 2009, http://www.marketwatch.ro/articol/4757/
Tertium_non_datur_oferta_CRM_OS_in_varianta_locala/pagina/2

reprezintă o dovadă în sprijinul creşterii credibilității ofertei CRM OS. Acest exemplu
nu este singular, dar cum aceste exemple notorii nu sunt suficient promovate,
necunoaşterea lor elimină acest beneficiu de imagine al OS.
SugarCRM este liderul pieței CRM OS, urmat de Compiere (şi el lider al zonei
ERP OS).
SugarCRM este una dintre cele mai importante platforme CRM de pe piață,
având nu una, ci un portofoliu de soluții şi o evoluție de‐a dreptul fulminantă către
poziția dominantă. Funcționalitățile principale acoperă: automatizarea forței de
vânzări, managementul campaniilor de marketing, asistență pentru clienți, cola‐
borare, CRM mobil (aplicații suportate de 90% dintre tablete şi smartphone‐uri),
CRM social (integrare cu linkedin, twitter, facebook, InsideView, LotusLive, WebEx,
GoToMeeting şi Google Docs) şi un modul de raportări. Soluția, lansată la sfârşitul lui
2004, a crescut rapid, cu numeroase versiuni care s‐au succedat, având astăzi peste
11 milioane de descărcări şi peste 10.000 de companii client. Compania cu acelaşi
nume are astăzi o cifră de afaceri de aproape 100 de milioane de dolari şi 350 de
angajați.
SugarCRM se poate implementa în patru variante: soluție pe modelul SaaS în
Sugar Cloud, soluție onpremise cu protecție prin firewall (versiunea comercială
Enterprise, unde licențele se plătesc), soluție în cloud la unul dintre partenerii lui
SugarCRM ori soluție în cloud‐ul public (se poate alege între Amazon Elastic
Compute Cloud, Windows Azure Services Platform, Rackspace Cloud ori IBM
SmartCloud Enterprise). SugarCRM oferă şapte zile gratuite pentru testarea soluției.
Date fiind opțiunile de implementare şi extensiile third‐party de pe site‐ul Sugar
Exchange, SugarCRM a ajuns să concureze cu soluțiile comerciale gen Siebel ori SAP
CRM. Totuşi, popularitatea sa se datorează ofertei ca software liber şi foarte bine pus
la punct sub aspect funcțional în cei peste opt ani de evoluție.
Compiere este preferatul nostru la primul loc în clasamentul celor mai
frumoase denumiri de soluții (a realiza, a îndeplini – în limba italiană), este o soluție
open source care combină ERP şi CRM, având ca țintă firmele mici şi mijlocii cu
obiect de activitate din distribuție, comerț, servicii şi producție. Ne oprim puțin
asupra ei deoarece este o soluție pe care o găsim şi în oferta românească prin
SocrateOpen.
Având peste 1,35 milioane de descărcări, Compiere se poate considera printre
cele mai răspândite soluții informatice de afaceri din lume. Avantajele pe care le
anunță sunt implementare rapidă, adaptabilitate bună şi un TCO scăzut.

Noutăţi pentru piaţa românească de ERP open source de la BitSoftware la începutul anului
2013: SocrateCloud 13.01 este disponibil pentru firme de orice mărime.
SocrateCloud, sistemul ERP&CRM dezvoltat de BITSoftware a ajuns la versiunea 13.01, a treia
versiune (după 12.12 şi 12.11) care rulează deja în cloud. Dezvoltat să se muleze pe diferite
industrii, SocrateCloud include funcţionalităţi specifice şi şabloane preconfigurate pentru
servicii profesionale, agricultură, telecomunicaţii, distribuţie etc., făcând implementarea
soluţiei mult mai uşoară pentru organizaţiile care activează în aceste domenii.
SocrateCloud are la bază o arhitectură modulară, care furnizează scalabilitate şi
adaptabilitate sporite şi suportă servere multiple, tranzacţii mari de date şi un număr
foarte mare de utilizatori şi este independent de cloud şi platformă.
(Sursa: http://www.bitsoftware.eu/ro/stiri/newsdetails/article/socratecloud1301estedisponibil/)

Pentru a arăta diversitatea ofertei mondiale de CRM open source, iată alte
câteva exemple32:
ConcourseSuite, soluția CRM completă a veteranilor de la Concursive (fosta
Centric CRM), ocupă locul doi pe piața soluțiilor open source de management al
relațiilor cu clienții, având un portofoliu de clienți impresionant, chiar dacă este
majoritar format de firme din categoria IMM;
Daffodil CRM, soluție CRM completă, care include un modul puternic de
campanii pe e‐mail şi instrumente de filtrare şi automatizare performante;
CentraView, soluție CRM browser‐based cu funcționalități dezvoltate de
Contact Management şi Salesforce Automation (SFA);
Hipergate, o altă soluție CRM web‐based care include funcționalități de
intranet CRM, sales automation, customer service, e‐mail marketing, content
management, bug tracker, project management, groupware, calendar, forum etc.;
SourceTap, aplicație CRM focalizată pe un modul SFA foarte flexibil şi
dezvoltat (pe lângă standardul SFA, sunt incluse funcționalități puternice de lead,
account şi opportunity management);
SellWin, o altă soluție CRM Sales application, construită pe arhitectură
multi‐tier (tehnologie Java), care permite customizări în detaliu;
openCRX, soluție CRM completă (account management, leads/opportunities
tracking, quotes/sales orders, invoices, territory management, product
pricing/discounting, activity/task management etc.), care include multe alte
funcționalități pe lângă cele clasice, precum instrumente de securitate internă, de
audit etc.
La cele de mai sus se adaugă soluțiile mixte ERP‐CRM precum cele din familia
Compiere, dar şi OFBiz Neogia, sau ERP‐CRM‐SCM ca Adempiere, iar lista continuă
cu multe alte soluții CRM open source speciale/specializate, cum ar fi Anteil
(arhitectură web, dezvoltare exclusiv cu instrumente open source), Mpower Open
(pentru organizații nonprofit), SplendidCRM (o soluție solidă, cu facilități analitice
avansate, scrisă în C# pe platformă .NET şi cu bază de date SQL Server) şi chiar un
mini‐CRM, scris cu PHP/mySQL pentru IMM‐uri33.
În România, dacă, în cazul soluțiilor proprietare, se poate vorbi despre o ofertă
variată, în cazul aplicațiilor CRM open source oferta este ca şi inexistentă, raportat la
abundența soluțiilor proprietare existente. Excepția o reprezintă aceeaşi firmă BIT
Software, cu soluția SocrateOpen, care are la bază oferta Compiere, fiind o aplicație
mixtă ERP/CRM Open Source. În rest, singurele referiri la soluțiile CRM OS sunt în

32 Informații preluate de la http://www.crmreview.ro/?p=216
33 O listă cuprinzătoare, documentată și comentată de comunitatea open source, am găsit pe site‐ul
ostatic.com

legătură cu oferta Sugar CRM, aplicația fiind prezentă în portofoliul de produse al
câtorva companii locale, dar fără vreo referință la implementările realizate la clienți.
În concluzie, apreciem că există o ofertă destul de consistentă în domeniul
CRM OS, însă se pare că atractivitatea soluțiilor open source este destul de scăzută pe
piața locală – atât în rândul potențialilor clienți, cât şi în rândul posibililor parteneri.
O situație care poate servi drept explicație ambelor părți, fiecare putând invoca, la
rândul său, lipsa ofertei, respectiv a cererii.

CAPITOLUL 6
Managementul lanţului de aprovizionare
desfacere prin platforme Supply Chain
Management

& cunoaşteţi aspectele definitorii ale unui lanţ de aprovizionare
desfacere;
& vă familiarizaţi cu privire la zonele funcţionale ale SCM;
& identificaţi riscurile implementării unui SCM;
& aveţi informaţii despre piaţa internă şi internaţională a produselor
SCM;
& înţelegeţi mecanismele de funcţionare şi relaţiile dintre ERP şi SCM;
& aflaţi care sunt principalele tehnologii informaţionale utilizate în
sistemele SCM;
& cunoaşteţi care sunt provocările şi cum se prefigurează viitorul
lanţurilor de aprovizionaredesfacere.

SCM este acronimul ce provine de la Supply Chain Management, iar în
traducere înseamnă managementul lanțului de aprovizionare‐desfacere. În esență,
SCM se referă la gestionarea unei rețele interconectate de întreprinderi care sunt
implicate în toate etapele necesare furnizării unui produs sau serviciu solicitat de un
consumator final. SCM acoperă deci circulația şi depozitarea materiilor prime,
activități de inventariere şi livrarea produsului final de la origine până la punctul de
dare în consum. În esență, SCM integrează şi sincronizează cererea cu oferta în
interiorul unei companii şi între companie şi partenerii săi de afaceri (figura 6.1).

• Previzionare
cerere şi necesar • Recepţie, • Management flux • Management
aprovizionare • Identificare surse • Planificare şi împachetare şi achiziţii, flux livrări retururi
• Proiectare reţea de aprovizionare programare pregătire comenzi • Management flotă • Reutilizare
logistică • Management • Asamblare şi pentru livrare auto • Recondiţionare
• Management furnizori ambalare • Management stocuri • Reciclare
furnizori servicii • Management depozit
logistice

Sursa: Prelucrare după: ***, Sustainable Supply Chain Logistics Guide, http://www.buysmartbc.
com/supply_chain_guide.pdf
Figura 6.1. SCM – acoperire funcţională

O definiție atotcuprinzătoare a acestui termen este oferită de Dicționarul
APICS . Astfel, în viziunea The Association for Operations Management, noțiunea de
1
SCM se referă la „proiectarea, planificarea, execuţia, controlul şi monitorizarea
activităţilor lanţului de aprovizionare, având ca obiective principale crearea de
valoare netă, construirea unei infrastructuri competitive, îmbunătăţirea logisticii la
nivel mondial, sincronizarea ofertei cu cererea şi măsurarea, în general, a
performanţei lanţului de aprovizionare la nivel global. ”

1 APICS – Advancing Productivity, Innovation and Competitive Succes – www.apics.org
202

Managementul lanţului de aprovizionare-desfacere prin platforme SCM 203
6.1. Evoluţie şi delimitări teoretice SCM

În secolul XXI, coordonatele care caracterizează lanțurile de aprovizionare
sunt complexitatea şi larga răspândire la nivel mondial, iar cea mai mare provocare
în gestionarea activităților specifice unui supply chain o constituie globalizarea.

6.1.1. Repere istorice

Inițial, conceptul de lanț de aprovizionare (supply chain) a fost utilizat cu
înțelesul de traseu al bunurilor şi serviciilor, de la furnizor până la beneficiar. Pe
parcursul evoluției, lanțurile de aprovizionare au cunoscut îmbunătățiri datorită
aportului de idei şi tehnologii noi, aspecte care au produs schimbări ample în
activitățile specifice. Ne amintim că în urmă cu 200 de ani forța de muncă a fost
înlocuită cu maşini, în scopul uşurării operațiunilor din halele de producție.
Electrificarea, căile ferate şi noile metode de comunicație au dus la extinderea
piețelor, înlesnind creşterea vitezei cu care se face aprovizionarea şi reducerea
costurilor implicate. În anul 1982, doi consultanți, Keith R. Oliver şi Michael D.
Webber, au abordat pentru prima dată conceptul de Supply Chain Management. Ei
considerau că activitățile precum coordonarea materialelor, informațiilor şi
resurselor financiare vehiculate în interiorul unei companii multinaționale sunt
provocări recompensatorii.
Totuşi, cercetările în domeniul coordonării şi integrării diferitelor unități
funcționale au început cu mult înaintea anului de referință menționat şi au putut fi
detectate în domenii precum: logistica, marketingul, managementul operațional,
teoria organizațională şi cercetarea organizațională. Printre contribuțiile cele mai
importante în dezvoltarea conceptului de lanț de aprovizionare regăsim:
W. Anderson (1957) – cercetarea canalului de aprovizionare;
D. Bowerox (1967) – colaborarea şi cooperarea;
F. Hanssmann (1959) – localizarea şi controlul inventarului în rețeaua de
producție‐distribuție;
J. Forrester (1958) – efectul bici în sistemul de producție‐distribuție;
A. Hax şi H. Meal (1957) – planificarea producției într‐un mod ierarhic.
Unii autori afirmă că originea SCM datează din anii ’50, când reputatul
specialist J. Forrester a studiat dinamica sistemelor industriale de producție şi
distribuție. Astfel, conceptul de SCM era văzut ca o combinaţie între artă şi ştiinţă, cu
scopul principal de îmbunătăţire a procesului de aprovizionare cu materii prime şi
materiale necesare fabricării unui produs, conceperii acestuia şi livrării către
beneficiari.

203

6.1.2. Delimitări conceptuale

În literatura românească de specialitate2, conceptul de supply chain
management este utilizat sub denumirea de managementul lanţului de distribuţie
sau managementul lanţului de aprovizionare şi desfacere şi se referă la procesul
economic dintro întreprindere, care debutează cu obţinerea necesarului de materii
prime şi se încheie cu distribuirea către clienţi a serviciilor sau produselor finite.
Dezvoltarea SCM s‐a desfăşurat pe baza funcțiilor logisticii: transport, achiziții,
distribuție, gestiune furnizori, bazându‐se pe ideea obținerii cu o mai mare uşurință
a transparenței informațiilor, dar şi pe minimizarea costurilor lanțului de distribuție
şi a ciclurilor de timp.
Până la jumătatea anilor ’50, stocurile de materii prime şi materiale erau în
responsabilitatea marketingului, iar producția şi prelucrarea comenzilor aparțineau
departamentului de vânzări sau contabilitate, situație care genera numeroase
conflicte. Din acest motiv, începând cu anii ’60, se acceptă faptul că logistica este
metoda cea mai bună de reglementare a situației, bazele organizării interne fiind
stabilite până în anii ’70, iar, odată cu instalarea foametei din Etiopia, din anii ’80, a
devenit posibilă aplicarea logisticii şi în alte segmente, neatinse până atunci, precum
sectorul alimentar. Anii 2000 au fost dominați de integrarea tehnologiilor
informaționale şi creşterea utilizării comerțului electronic, toate acestea concurând
la dezvoltarea SCM.
Prin implementarea SCM, logistica este legată de întreaga rețea de comunicații
a întreprinderii şi de personalul acesteia. Efectul este crearea unei rețele de
distribuție ce are ca atribuții achiziția de resurse, transformarea acestora în produse
finite şi livrarea lor către clienți la locul, timpul, dar şi prețul potrivit. Rezultă de aici
faptul că prin utilizarea SCM întreprinderea înregistrează creşterea eficienței, în
principal datorită reducerii costurilor, asigurând totodată creşterea nivelului de
servire al clienților.
Lanţul de aprovizionare reprezintă un grup de întreprinderi direct conectate
în amonte şi în aval, de unul sau mai multe fluxuri de produse, servicii, bani, cât şi de
informații, de la origine până la clientul final. Gestionarea3 proceselor unui lanț de
aprovizionare constituie de fapt managementul lanțului de aprovizionare.
Lanțul de aprovizionare facilitează furnizarea materiilor prime şi materialelor
necesare, la locul potrivit, în momentul solicitat, iar profitul este considerat a fi
scopul principal al acestei activități. Conceptul de lanț de aprovizionare este la fel de
vechi precum comerțul însuşi; totuşi, noile tehnologii au transformat radical lanțul
de aprovizionare din zilele noastre şi au dus la reducerea costurilor, creşterea
calității şi îmbunătățirea vitezei de lucru.
În prezent, SCM‐urile pot fi îmbunătățite printr‐o bună prelucrare şi
gestionare a informațiilor, care au ca sursă datele care vin pe multiple canale din

2 Facem această precizare deoarece specialiştii din practica implementării de sisteme informatice
preferă să utilizeze termenul original SCM în detrimentul traducerilor posibile pe care le‐am menționat.
3 J.T. Mentzer ş.a., „Defining Supply Chain Management”, în Journal of Business Logistics, vol. 22, nr. 2,
2001, pp. 1‐25.
204

sistemele ERP ale membrilor lanțului de aprovizionare‐desfacere. Companiile

adoptă noile tehnologii precum telecomunicațiile wireless şi rețelele virtuale, pentru
îmbunătățirea procesului de livrare şi a serviciilor. Prin intermediul unor sisteme
sigure de intranet şi a unor platforme de comerț online B2B (businesstobusiness),
interesul se manifestă asupra îmbogățirii managementului integrat al informației
prin relațiile cu partenerii externi.

6.1.3. Definiţii SCM

Din dorința de a clarifica conceptul de SCM, considerăm util a enunța câteva
definiții edificatoare:
în definiția lui Mentzer4, Supply Chain Management are în vedere
coordonarea sistemică şi strategică a funcţiilor economice tradiţionale şi tacticile
implicate în cadrul acestor funcţii întruna sau mai multe întreprinderi în cadrul
lanţului de aprovizionare, având ca scop îmbunătăţirea performanţei întreprinderilor
şi a lanţului de aprovizionare pe termen lung;
în viziunea reputatului autor Lambert5, SCM se referă la integrarea
principalelor procese economice din cadrul lanţului de aprovizionare, urmărind în
mod esenţial obţinerea de valoare atât pentru clienţi, cât şi pentru ceilalţi participanţi
din cadrul procesului de aprovizionare;
potrivit CSCMP – Council of Supply Chain Management Professionals6 –, SCM
cuprinde planificarea şi gestionarea tuturor activităţilor presupuse de identificarea
furnizorilor, aprovizionarea, producţia şi logistica. De asemenea, include componen‐
tele esențiale destinate coordonării şi colaborării cu partenerii (de canal) respectiv
furnizorii, intermediarii, furnizorii de servicii terțe, precum şi clienții. În sinteză,
managementul lanțului de aprovizionare integrează şi gestionează cererea şi oferta
din cadrul şi dintre întreprinderi.

6.2. Concepte de bază ale SCM

Lanțul de aprovizionare‐desfacere (numit şi lanț de distribuție) începe şi se
termină cu clientul, indiferent dacă acesta este o verigă intermediară a lanțului de
aprovizionare‐desfacere sau consumatorul final. Tot acest traseu cuprinde o serie de
componente indispensabile lanțului de aprovizionare: producţia, înmagazinarea,
distribuţia şi plata. Un lanț de aprovizionare de calitate nu este dependent nici de
mărimea şi nici de numărul intermediarilor. Totuşi, este preferabil ca lanțul să fie cât
mai scurt şi practic, pentru a nu conduce la majorarea costurilor care se reflectă în
prețul produselor.

4 J.T. Mentzer ș.a., op. cit.
5 D.M. Lambert (ed.), Supply Chain Management: Processes, Partnerships, Performance, Sarasota, Florida
2008, pp. 1‐20.
6 http://cscmp.org
205

Dincolo de integrarea segmentelor unui lanț de aprovizionare‐desfacere, este
posibilă integrarea unui lanţ valoric, concept care desemnează procesul prin care mai
multe întreprinderi abordează colaborativ planificarea, implementarea şi gestiunea
fluxurilor de bunuri, servicii şi informaţii.
Un lanț de distribuție se transformă într‐un lanţ valoric dacă:
lanțul este extins de la consumatori până la furnizori;
integrează operațiunile backoffice cu cele de frontoffice;
devine orientat pe client;
este proiectat proactiv de membrii lanțului, concretizând conceptul de
„întreprindere extinsă”, ceea ce creează valoare pentru clienții săi prin colaborare
interîntreprinderi.
În contextul e‐business, acest tip de colaborare este denumit şi collaborative
commerce. Filosofia ccommerce consideră că peisajul competitiv contemporan a
depăşit stadiul „unul împotriva celuilalt”, trecând la cel de „un grup de companii
împotriva altui grup”. Lanțul de distribuție oferă imaginea modului în care sunt
cuplați partenerii de afaceri.
Lanțul de distribuție este compus din trei părți distincte:
1) în amonte – furnizorii de primul nivel (care pot fi, la rândul lor,
producători şi/sau asamblori) şi furnizorii lor;
2) intern – toate procesele desfăşurate în cadrul companiei pentru transfor‐
marea intrărilor în ieşiri, acoperind intervalul de timp de la intrarea materialelor în
organizație până la ieşirea produselor spre clienți;
3) în aval – procesele care au loc de la livrarea produsului până la consuma‐
torii finali.
Abordarea clasică a lanțului de aprovizionare începe de la veriga inițială –
previzionarea cererii –, urmată de celelalte verigi: procurarea materiilor prime,
logistica spre producătorii de componente, care vând spre asamblarea finală şi apoi
distribuie produsele în aval spre clienți. Astfel, produsele tranzitează depozite şi
sunt livrate prin intermediul distribuitorilor şi retailerilor spre consumatorul final.
Acest canal de distribuție poate include legături multiple pe toată lungimea sa.
Totodată, întreprinderea este responsabilă de administrarea legăturilor cu furnizorii
din amonte, care pot include sute de întreprinderi de‐a lungul verigilor care
formează canalul de distribuție.
Într‐un lanț de aprovizionare‐desfacere, performanța se poate realiza numai
dacă există o strânsă legătură între procesele esențiale. Se observă la nivelul
organizațiilor o tendință de a nu ține cont de componentele intermediare ale
lanțului, ceea ce are ca efect creşterea extensivă a prețurilor, ca urmare a apariției
costurilor suplimentare cu depozitarea stocurilor neeficiente, prelucrarea acestora,
transportul de la un intermediar la altul şi a creşterii timpului de livrare mult peste
termenele stabilite.
Conform opiniilor din literatura de specialitate, principalele activități pe care
le gestionează un sistem SCM sunt: producţia, depozitarea, distribuţia, livrarea şi
plata, ele fiind descrise pe scurt în cele ce urmează.
206

Activitatea de producţie include toate operațiunile, de la cea de alegere a
furnizorilor, până la stabilirea cantității optime pentru produsele comandate. Pentru
a fi menținută pe parcursul unei perioade de timp cât mai îndelungate, relația cu
partenerii de afaceri trebuie să fie bazată pe încredere şi cooperare.
În ceea ce priveşte activitatea de depozitare, locul în care sunt amplasate
depozitele, modalitatea de aşezare a mărfurilor şi cantitatea depozitată sunt printre
cele mai importante elemente de luat în considerare în cadrul procesului de gestiune
a stocurilor. Fiecare întreprindere trebuie să cunoască permanent cantitatea optimă
de aprovizionat, pentru a nu supraîncărca depozitele în mod inutil. Mai mult,
gestiunea stocurilor trebuie să se realizeze pe categorii sau clase de produse, pentru
a facilita procesul de livrare a bunurilor.
Distribuţia este activitatea care se referă la livrarea produselor către client.
Tot în cadrul acestei activități se gestionează mijloacele de transport, precum şi
selectarea corectă a depozitelor din care se efectuează livrarea. Scopul acestei
activități constă în punerea la dispoziția consumatorului final, în condiții optime şi la
costuri minime, a produselor comandate. În principiu, comenzile primite de la clienți
trebuie procesate după metoda prima comandă primită–prima comandă livrată. În
acest mod, se asigură onorarea la termenul stabilit a tuturor comenzilor. Ca în orice
relație de parteneriat, există şi excepții, respectiv relații preferențiale pentru
anumiți clienți. Ne referim aici la situațiile în care există clienți care au termene
prestabilite de onorare a comenzii sau la clienții permanenți ale căror comenzi au
prioritate.
Distribuția include şi activitatea de retur, respectiv returnarea unei cantități
de produse care sunt defecte, depăşite de unele mai noi (în cazul articolelor de
îmbrăcăminte) sau care au ajuns mai târziu decât termenul stabilit.
Livrarea asigură transportul coletelor la destinatar, iar plata are în vedere
achitarea contravalorii produselor achiziționate de la furnizori, precum şi încasarea
valorii comenzilor clienților. În ultimii ani, şi în țara noastră a cunoscut o mare
dezvoltare plata prin internet, care elimină contactul direct cu partenerul de afaceri
sau cu banca. Folosirea metodelor moderne de plată implică o serie de avantaje,
printre care amintim: creşterea vitezei de derulare a operațiunilor financiare,
maximizarea competitivității şi simplificarea procedurilor de plată.
Una dintre metodele moderne de plată‐încasare cele mai utilizate este B2B
(businesstobusiness), fiind folosită de mii de companii care au descoperit că
internetul nu oferă doar posibilitatea de a pune la dispoziție produse financiare 24
de ore pe zi, ci şi o cale rapidă de a ajunge mult mai uşor la furnizori şi clienți. B2B
este un sistem securizat, care controlează accesul la resurse, criptează comunicarea
şi asigură, în general, eficiența tranzacțiilor financiare efectuate.
Cunoscuta firmă de consultanță PricewaterhouseCoopers a enunțat o serie de
principii7 care sunt recomandate a fi respectate atunci când se proiectează un lanț
de aprovizionare‐desfacere:

7 G. Knolmayer, P. Mertens, A. Zeier, Supply Chain Management auf der Basis von SAPSystemen,
Springer‐Verlag, Berlin, 2000.
207

maximizarea valorii oferite clienţilor, consumatorilor şi propriei firmei

constituie obiectivul principal al unui lanț de aprovizionare. Acest deziderat poate fi
dus la îndeplinire prin furnizarea unui nivel de calitate ridicat la un preț cât mai mic;
optimizarea costurilor şi a calităţii serviciilor oferite trebuie urmărită în
mod constant în cadrul lanțului de aprovizionare;
adăugarea unor soluţii complexe de management ar putea produce o
majorare a costurilor;
informaţiile privind calitatea serviciilor trebuie partajate în amonte, cu
minimum de distorsiuni;
sincronizarea cererii cu oferta este esențială pentru îndeplinirea
obiectivelor de reducere a costurilor şi de îmbunătățire a calității serviciilor oferite;
capacitatea lanţului de aprovizionare trebuie organizată şi din punct de
vedere strategic;
operaţiunile flexibile din cadrul SCM sunt esențiale în sincronizarea
activităților din cadrul SCM;
performanţele SCM sunt direct proporționale cu activitatea de cercetare‐
dezvoltare, respectiv cu crearea de noi produse şi lansarea lor pe piață.
Menționăm că, în strictă legătură cu principiul al patrulea, poate fi amintit
efectul de bici (cunoscut în literatura anglo‐saxonă sub denumirile de bullwhip sau
whipsaw effect). Această noțiune se referă la faptul că fluctuații relativ mici în
schimbarea cererii clienților pot fi amplificate dramatic de‐a lungul lanțului de
aprovizionare şi pot cauza distorsiuni semnificative în sistemul de aprovizionare. Un
val mic la un capăt al lanțului de aprovizionare‐desfacere se poate transforma într‐un
tsunami la celălalt capăt.

6.3. Zonele funcţionale şi taxonomia SCM

De‐a lungul existenței sale, o întreprindere dezvoltă sau achiziționează mai
multe aplicații, decizii impuse fie de reorganizare, fie de extinderea activității. Cele
mai populare aplicații achiziționate de întreprinderi sunt cele destinate susținerii
activităților financiar‐contabile sau a altor activități din zona operațională.
Principalul motiv pentru care se încearcă utilizarea unui sistem integrat îl constituie
identificarea unei soluții optime care să susțină buna desfăşurare a activității
întreprinderii.
Zonele funcţionale ale lanţului de aprovizionaredesfacere care pot fi
informatizate prin aplicații specifice SCM sunt:
planificarea. Aceasta este componenta strategică a managementului
lanțului de distribuție, prin care se defineşte strategia de gestionare a tuturor
resurselor şi de acoperire a cererii clienților pentru produsele/serviciile firmei;
gestiunea furnizorilor. Această activitate dezvoltă un set de procese
destinate alegerii, livrării şi achitării contravalorii comenzilor furnizorilor,
monitorizează relațiile cu partenerii prin intermediul unor indicatori specifici. Tot în
208

cadrul acestei activități sunt reunite procesele de gestiune a stocurilor şi a serviciilor
primite de la furnizori, inclusiv recepția, verificarea, transferul către locațiile de
producție sau autorizarea plăților;
producţia. Are în vedere programarea activităților de producție, testarea/
verificarea, ambalarea şi pregătirea pentru livrare;
livrarea sau logistica. În cadrul acestei activități se coordonează recepția
comenzilor de la clienți, se asigură buna funcționare a rețelei de depozite, gestiunea
transportului şi a sistemului de facturare în vederea încasării;
returul. Asigură gestiunea produselor returnate de clienți din diferite
motive (defecte, plusuri etc.) şi relațiile cu clienții care au întâmpinat diverse
probleme legate de produsele livrate.
Aceste zone pot fi considerate segmente de piaţă pentru aplicaţiile SCM,
deoarece fiecare dintre acestea constituie un domeniu foarte important din
activitatea unei întreprinderi care are nevoie de o soluție inovatoare pentru
rezolvarea problemelor interne şi pentru o mai bună gestionare a resurselor de care
dispune. Ele se regăsesc în categoria aplicațiilor de execuție SCM, căci piața
aplicațiilor din domeniul SCM acoperă două categorii:
aplicaţii destinate planificării activităţilor lanţului de aprovizionare
desfacere, aplicații care utilizează algoritmi matematici în scopul îmbunătățirii
fluxurilor din cadrul SCM;
aplicaţii destinate execuţiei activităţilor lanţului de aprovizionaredesfacere,
respectiv automatizarea etapelor specifice SCM.
Rezultatul obținut prin implementarea de aplicații SCM constă în optimizarea
şi automatizarea tuturor proceselor economice de la nivelul întreprinderii, începând
cu aprovizionarea cu materii prime şi procesele de producție, finalizând cu
transportul şi distribuția produselor finite, devenite mărfuri.
Într‐o altă clasificare, aplicațiile informatice care susțin managementul
lanțului de aprovizionare‐desfacere sunt:
supply chain replenishment – reaprovizionare;
collaborative planning – planificare colaborativă;
elogistics – logistică electronică;
collaborative product development – dezvoltare colaborativă a produselor;
web supply – aprovizionare prin web;
eprocurement – achiziții electronice.

Prezentăm în tabelul următor situaţia comparativă a opţiunilor în construirea de sisteme SCM
a celor doi mari producători mondiali, Oracle şi SAP.

209

ORACLE SAP
Advanced iProcurement, iSupplier Procurement Strategic Sourcing Purchase,
Procurement Portal Payables, Order Processing, Invoicing
Purchasing, Purchasing
Intelligence, Sourcing,
Supplier Network
Logistics & Landed Cost Management, Transportation Freight Management,
Transportation Transportation Planning & Dispatching,
Management, Warehouse Rating & Billing & Settlement,
Management, Mobile Driver & Asset Management,
Supply Chain, RFID, Network Collaboration
Inventory Management
Manufacturing Discrete Manufacturing, Manufacturing Production Planning &
Flow Manufacturing, Detailed Scheduling,
Manufacturing Operations Manufacturing Visibility &
Center, Process Execution & Collaboration,
Manufacturing, Shop Floor MRP based Detailed
Management Scheduling
Supply Chain Advanced Planning, Supply Chain Strategic Supply Chain
Planning Command Center, Visibility, Supply Design, Supply Chain
Advanced Supply Chain Network Analytics, Supply Chain Risk
Planning, Collaborative Collaboration, Management, Sales &
Planning, Demantra Supply Chain Operations Planning, Supplier
Demand, Management, Management Collaboration, Customer
Demand Signal Repository, with Duet Collaboration, Outsourced
Demantra RealTime Sales Manufacturing, Demand
and Operations Planning, Planning in MS Excel
Global Order Promising,
Inventory Optimization,
Production Scheduling,
Service Parts Planning,
Strategic Network
Optimization
Order Order Management, Order Sales Order Processing,
Fulfillment Advance Pricing, Deal Fulfillment Billing, Service Parts Order
Management Fulfillment
Configurator, Global Order
Promising

Pentru furnizorii de aplicații pentru zona SCM este foarte important, am putea
spune chiar vital, să ofere produse noi sau funcționalități inovatoare. Acest lucru le
va permite în primul rând să‐şi mențină segmentul de clienți, iar în al doilea rând,
să‐şi atragă noi segmente de piață, deoarece şi aici concurența este acerbă.
Într‐o anumită măsură, viitorul acestor aplicații este strâns legat de tendințele
actuale manifestate pe „tărâmul” informaticii şi al tehnologiei. Îmbunătățirea
aplicațiilor constă în adoptarea şi implementarea noilor tehnologii cum ar fi sateliții
sau dispozitivele de identificare cu frecvență radio (RFID).
Integrarea aplicațiilor SCM în pachetele ERP (cu furnizor unic) este apreciată
drept soluția ideală, însă este mulțumitoare şi situația de integrare prin interfețe a
210

ERP‐ului existent cu un sistem SCM de la alt furnizor. Considerăm că este util să
amintim că ERP permite:
integrarea cu furnizorii prin Supply Chain Management şi cu activitățile de
marketing, vânzări şi servicii oferite clienților;
schimbul de informații cu sistemele ERP ale partenerilor prin EDI sau web
services.

6.4. Relaţia ERPSCM

Multe aplicații ale managementului lanțului de aprovizionare‐desfacere se
bazează pe informațiile disponibile în cadrul unui sistem integrat ERP, cel care
centralizează, deține şi distribuie toate informațiile din cadrul tuturor departa‐
mentelor întreprinderii.
Deşi atât sistemele ERP, cât şi cele SCM dețin avantaje precum: centralizarea,
reducerea costurilor de producție, creşterea vitezei de lucru, flexibilitatea, accesul de
la distanță, uşurință în mentenanță şi administrare, precum şi performanță ridicată, la
nivelul anului 2002, în Europa, doar 12% din marii producători aveau soluții SCM (fie
ele Oracle, SAP sau Ariba, Commerce One, i2 Technologies ori Just Enough), în
comparație cu un procent de 50% care dețineau soluții ERP. Complexitatea acestor
sisteme, dar şi cea de a integra ERP cu SCM pot explica aceste cifre.
Comparându‐le, observăm că soluțiile SCM oferă o multitudine de module
destinate diferitelor funcțiuni ale lanțului de aprovizionare‐desfacere, la fel ca în
cazul soluțiilor ERP, ambele sprijinind coordonarea resurselor. Aceste două sisteme
prezintă şi diferenţe, astfel:
în sistemele ERP analiza se poate realiza atât în trecut, cât şi în prezent;
în sistemele SCM se analizează prezentul şi viitorul.
În plus, la sistemele ERP, abordarea este tranzacţională, diferenţiinduse astfel de
soluţiile SCM, în care abordarea este preponderent interactivă sau simulativă. Mai mult,
sistemele ERP sunt axate pe managementul datelor şi integrare, iar managementul
lanţului de aprovizionaredesfacere are în vedere controlul şi sincronizarea.
ERP este forța care integrează toată informația dintr‐o întreprindere într‐o
singură aplicație, oferă integritate datelor, acces la o bază de date unică şi
consolidează mai multe sisteme diferite, inițial incompatibile. Prin integrarea
aplicațiilor SCM în aceste sisteme, vor fi valorificate toate avantajele ERP şi vor
putea ține pasul cu informația.
După unele opinii8, este preferabil ca modulele SCM să fie integrate în
sistemele ERP, întrucât interacționează optim cu alte funcții ale platformei software.
Astfel, marii producători de soluții ERP au întrevăzut perspectivele SCM şi au inclus
în ofertele lor şi module destinate managementului lanțului de aprovizionare‐
desfacere. Totuşi, în cazul în care o întreprindere are implementat un sistem ERP
care nu conține un modul destinat SCM, poate fi adăugat un astfel de modul de la un
alt producător software, însă există riscuri.

8 D. Mateescu, „SCM – un instrument puternic pentru Departamentul de aprovizionare‐desfacere”,
http://news.totalsoft.ro/www/citeste‐mai‐departe....html*articleID_74‐articol
211

Compania TotalSoft, producătoare a sistemului ERP Charisma Enterprise, susţine că este posibil
ca o soluţie SCM livrată de un dezvoltator să fie integrată în soluţia ERP de la alt
producător software. Însă dacă este cazul unei firme de distribuţie, atunci SCM se poate
considera chiar core business (termen consacrat, care desemnează afacerea principală a
unei firme), iar, în absenţa sa, ERP sar ocupa doar de elaborarea bugetelor, de centrele de
cost şi de zona contabilităţii. Reprezentanţii TotalSoft afirmă că este recomandat ca atât
soluţia ERP, cât şi cea de SCM să fie integrate şi să provină de la acelaşi furnizor. În acest
mod se evită probleme legate de compatibilitatea documentelor. Pe exemplul României, din
zona de distribuţie consumatoare de SCM, cel mai puternic dezvoltate sunt distribuţia de
medicamente, băuturi, lanţurile de magazine şi supermarketuri, precum şi reţelele de
distribuţie a telefoanelor mobile.

În condițiile economice actuale, se fac eforturi constante pentru construirea
unei afaceri suple care să fie flexibilă, reacționând rapid la cerințele pieței şi care să
se concentreze pe crearea de valoare.
Aşa cum am amintit anterior, situaţia ideală este reprezentată de momentul
în care aplicaţiile SCM sunt integrate în pachetele ERP. Aplicațiile care doar
automatizează aspectele de logistică ale SCM sunt mai puțin dependente de
informațiile din cadrul întreprinderii şi tind să fie independente de deciziile ERP.
Însă, la un moment dat, există posibilitatea nevoii de comunicare cu un sistem de
planificare a resurselor întreprinderii, fiind importantă de asemenea şi integrarea
aplicațiilor în mediul internet. În cazul construirii unui site web în vederea
comunicării cu clienții şi furnizorii, este permis accesul la informații din cadrul
sistemului ERP şi la aplicațiile SCM pentru a prezenta simultan informații actualizate
referitoare la comenzi, plăți, stadiul producției şi livrării unor produse.
Integrarea dintre SCM şi sistemele ERP oferă o mai mare eficiență şi avem
în vedere avantajele tehnologice, cele care derivă din dezvoltarea interfețelor şi
comunicarea mecanismelor sistemelor, avantaje organizaționale sau manageriale,
precum şi beneficiile obținute din partajarea unor funcții specifice celor două
sisteme. Există anumite soluții arhitecturale care permit integrarea ERP‐urilor cu
aplicațiile SCM în următoarele forme:
integrarea offline, în care sistemul SCM se ocupă de toți paşii ciclului de
producție şi planificare. Din punct de vedere tehnologic, această soluție este
considerată simplă, însă impune anumite constrângeri cu privire la sincronizarea
celor două sisteme;
integrarea addon este o integrare clasică, în timp real, în care fiecare
funcționalitate SCM poate fi lansată din cadrul platformei sistemului ERP.
În ultimii ani, sistemele ERP şi SCM au cunoscut o creştere a popularității în
diverse segmente ale industriei electronice. Sistemele ERP asistă întreprinderile, în
sensul integrării funcțiilor sistemelor informatice, în timp ce sistemele SCM reduc
costurile tranzacțiilor şi facilitează interacțiunea furnizor‐client.

212

Epicor Software, lider în furnizarea soluţiilor software de afaceri din România, anunţă că a
testat şi analizat eficienţa sistemului şi recomandă utilizarea aplicaţiilor integrate de tip
ERP. Producătorul mai sus amintit va lansa soluţia Epicor Mobile Field Service care dispune
de instrumente de tip workflow, simplu de utilizat, suport pentru sistemul de poziţionare
globală (GPS) şi posibilităţi de ataşare de documente.
Totalsoft, furnizorul unei soluţii SCM „secondtier” inclusă în sistemul ERP Charisma, a
înregistrat venituri din zona ERP de peste zece milioane de euro. Acesta oferă, prin
intermediul soluţiei ERP Charisma Entreprise, o soluţie SCM completă care acoperă întreg
fluxul de aprovizionare şi livrare a unei întreprinderi de distribuţie: replenishing (cu cât
trebuie să se aprovizioneze o firmă pentru a avea stocuri optime), managementul
achiziţiilor, managementul logistic al aprovizionării, managementul depozitelor, logistica
livrării până la client şi managementul ambalajelor.

Integrarea aplicațiilor specifice managementului lanțului de aprovizionare în
pachetele ERP conduce la creşterea productivității, îmbunătățirea performanțelor,
fluidizarea procesului de aprovizionare şi eliminarea, în general, a punctelor slabe
ale SCM. În concluzie, modalitatea principală de a obține venituri ridicate şi un profit
corespunzător constă în sincronizarea cererii şi ofertei în timp real. În acest sens,
sistemele ERP contribuie prin colectarea şi stocarea în baza de date a informațiilor
necesare pentru monitorizarea componentelor lanțului de aprovizionare.
În general, aplicațiile SCM sunt integrate într‐un sistem ERP şi în puține cazuri
funcționează ca aplicații independente. Sistemele integrate nu se referă doar la
planificarea resurselor unei întreprinderi, ci au ca scop dezvoltarea unei
întreprinderi integrate, respectiv a unui sistem în care toate zonele funcționale
(finanțe, producție, contabilitate, resurse umane etc.) ale întreprinderii să fie
integrate în cadrul unui sistem informatic unic, care va servi nevoilor fiecărui
departament în parte, precum şi celor ale întreprinderii în ansamblu.9

6.5. Riscurile implementării SCM

Riscurile implementării SCM sunt văzute din două perspective, şi anume:
riscuri sistemice, care se regăsesc în interiorul întreprinderii, şi riscuri nonsiste
mice, ce reprezintă macrofactori care afectează întregul mediu economic.
Riscurile sistemice apar în cadrul întreprinderii şi sunt, de cele mai multe ori,
neglijate de conducere. În sprijinul afirmației noastre, specificăm faptul că managerii
de vârf nu acordă suficientă atenție instruirii personalului, o condiție esențială în
implementarea şi, ulterior, utilizarea sistemelor integrate dintr‐o întreprindere.

9 C. Madu, C. Kuei, ERP and Supply Chain Management, Chi Publisher, Fairfield, 2004, p. 5.
213

Pentru exemplificare, putem aminti cazul unui hacker renumit, Kevin Mitnick, autor al unor
atacuri asupra companiilor Sun Mycrosystems, Motorola, Nokia, Nec, Fujitsu şi Novell.
Acesta a profitat de lipsa de pregătire profesională a personalului şi a reuşit să obţină
informaţii valoroase din interiorul companiilor mai sus menţionate. Din nefericire, acest caz
nu este singular.

O altă sursă de riscuri sistemice, apărute în cadrul întreprinderilor, o
constituie managerii întreprinderii. Aceştia consideră că simpla implementare a
unui sistem SCM rezolvă toate problemele existente în activitatea întreprinderii şi,
mai mult decât atât, în unele cazuri, aceştia nu țin cont de indicațiile specialiştilor.

Un exemplu relevant este cel al companiei Nike, care, în martie 1999, a decis implementarea
unei soluţii SCM prin intermediul i2. Deşi se afla la a doua tentativă de implementare a unui
astfel de sistem, Nike nu respectă recomandările specialiştilor şi renunţă la serviciile oferite
de implementator pe durata procesului de analiză, continuând dezvoltarea proiectului prin
forţe proprii. Rezultatul obţinut a fost departe de cel scontat, întrucât soluţia software
elabora previziuni lipsite de acurateţe.

Cea de‐a doua categorie de riscuri, cele nonsistemice, afectează manage‐
mentul întregului lanț de aprovizionare‐desfacere. Dintre acestea, amintim:
numărul mare de participanți în cadrul SCM;
întârzierile de producție şi de distribuție;
riscuri asociate cu volumul stocurilor;
riscuri aferente retururilor;
riscul legat de redundanța datelor, în cazul utilizării sistemelor informatice
independente;
viabilitatea participanților din cadrul lanțului de aprovizionare‐desfacere;
factori financiari precum rata de schimb şi presiunea pieței;
factori de mediu precum catastrofele naturale, vremea;
evenimentele geopolitice nefaste, atacurile teroriste, instabilitatea politică;
alți factori precum fluctuația cererii clienților, acțiunile revendicative
sindicale etc.
Menționăm că identificarea factorilor de risc nu este suficientă pentru
eliminarea sau minimizarea efectelor acestora. La fel ca la celelalte proiecte
informatice de anvergură, soluția constă în implementarea unor instrumente care să
favorizeze managementul eficient al riscurilor.
Printr‐o bună planificare, distribuirea produselor este optim programată,
înlăturându‐se astfel riscul apariției întârzierilor de producție şi de distribuție. În
cazul retururilor de către clienți, se pot pierde date semnificative, care conduc la
214

apariția de neconcordanțe între produsele returnate şi sumele de bani înapoiate. Nu
în ultimul rând, prin preluarea online a comenzilor, riscul care provine din
redundanța datelor este eliminat. Un avantaj al aplicațiilor SCM îl constituie
partajarea datelor referitoare la comenzile de onorat, care sunt introduse în sistem
în mod direct, de client.

Iată, spre exemplificare, cazul Dell. La momentul actual, compania Dell este lider pe piaţă în
ceea ce priveşte vânzarea directă a produselor către consumatori. Acest lucru sa datorat, în
principal, implementării unui SCM care a condus la următoarele: eliminarea
intermediarilor, pe de o parte, precum şi satisfacerea cerinţelor consumatorilor prin
livrarea întrun timp scurt, pe de altă parte. Pe baza aceluiaşi exemplu, existenţa
instrumentelor SCM a permis minimizarea riscurilor care provin din volumul
necorespunzător al stocurilor, a celor legate de întârzierile de producţie şi distribuţie, de
retururi, precum şi a riscurilor legate de redundanţa datelor. Astfel, prin implementarea
SCM, Dell a reuşit obţinerea unor previziuni cât mai exacte asupra necesarului de
aprovizionat, deoarece, pe baza informaţiilor oportune legate de cererile clienţilor, îşi
modifică stocurile în direcţia dorită.

6.6. Impactul IT în SCM

Implementarea unui sistem SCM promite obținerea unui avantaj competitiv
durabil, mai ales dacă se bazează pe adoptarea tehnologiilor informaționale de
ultimă oră, care îmbunătățesc considerabil managementul lanțului de aprovizionare.
Noile tehnologii informaționale (NTI) contribuie la realizarea unui control eficient al
activităților lanțului de aprovizionare, care, în zilele noastre, au devenit extrem de
complexe. Prin implementarea NTI în tehnologia SCM se vizează optimizarea
lanțului de aprovizionare prin reducerea duratei ciclului, îmbunătățirea eficienței şi
livrarea în timp util a produselor către clienți.

6.6.1. Evoluţia şi rolul tehnologiilor informaţionale în SCM

În ultimii ani, rolul NTI în managementul lanțului de aprovizionare s‐a
schimbat foarte mult. Inițial, în cadrul SCM, transmiterea majorității informațiilor
interorganizaționale se realiza prin poştă sau fax. Ulterior, în perioada anilor ’80‐’90,
a fost utilizat schimbul electronic de date prin tehnologia EDI, cu un impact deosebit
asupra fluxurilor informaționale din cadrul unui lanț de aprovizionare‐desfacere.
Astăzi, predomină tehnologiile bazate pe internet, iar viitorul în acest domeniu se
preconizează a fi aplicațiile WEB‐SCM.
Tehnologii precum EDI, intranet, extranet, internet etc. au contribuit simțitor
la integrarea partenerilor de afaceri, cumpărători şi vânzători. Un impact
semnificativ al tehnologiilor informaționale se referă la calitatea informațiilor
215

disponibile în lanțul de aprovizionare. Companiile pot dezvolta aplicații bazate pe
tehnologiile web sau intranet pentru a disemina informații. În acest fel, toți
partenerii din cadrul lanțului de aprovizionare vor fi incluşi şi, în consecință, toate
informațiile aferente. Astfel, prin utilizarea în mod corespunzător a informațiilor are
loc eficientizarea managementului lanțului de aprovizionare şi diminuarea
riscurilor.

6.6.2. Tehnologii informaţionale utilizate în SCM

Managementul eficient al lanțului de aprovizionare are ca principale
obiective: optimizarea livrării cantităţii de bunuri şi servicii în funcţie de locaţie,
perioada de timp, cantitatea solicitată şi preţ10. Implementarea eficientă a aplicațiilor
SCM depinde în mare măsură atât de strategiile alese pentru fiecare dintre
componente, cât şi de mărimea lanțului de aprovizionare. O privire spre viitorul SCM
relevă cel puțin două tendințe: Green Supply Chain Management, ce are în vederea
identificarea şi respectarea laturii ecologice din cadrul tuturor proceselor din SCM,
şi utilizarea SOA.
Implicarea tehnologiilor informaționale în gestionarea achiziţiilor din cadrul
lanțului de aprovizionare s‐a îmbunătățit simțitor în ultimii zece ani. Studii recente
arată că NTI sunt utilizate într‐o varietate de aplicații destinate atât domeniului
public, cât şi comercial, în scopul îmbunătățirii comunicării cu furnizorii, verificării
şi actualizării listelor de prețuri şi sprijinirea activității de achiziție directă, pe baza
cataloagelor furnizorilor. Prin utilizarea NTI în activitatea de achiziţie au fost
optimizate procesele de negociere cu furnizorii, de soluționare a garanțiilor privind
bunurile returnate şi a celor avariate şi de procesare a comenzilor, aspecte care au
ca rezultat imediat reducerea simțitoare a costurilor. În ceea ce priveşte utilizarea
NTI în logistică, afirmăm că acestea permit prestatorilor de astfel de servicii să se
asigure că transportatorii auto pe care îi au în subordine respectă termenele de
livrare. De asemenea, oferă managerilor informațiile de care au nevoie pentru a
informa operatorii de transport în legătură cu întârzierile de expediere, imediat cum
acestea apar, astfel încât are loc o reducere a duratei de informare până când
măsurile corective care trebuie luate devin disponibile.
În producție şi logistică, tehnologiile informaționale au permis coordonarea
tuturor activităților desfăşurate pentru îndeplinirea cerințelor unui client în care
sunt implicați: producătorul, furnizorii de piese şi subansambluri, managerii de
logistică, transportatorii, reprezentanți ai serviciilor cu clienții, reprezentanții de
asigurare a calității etc.
În continuare sunt descrise câteva dintre NTI care se regăsesc în aplicațiile
SCM11.

10 D. Fotache, L. Hurbean, „Supply Chain Management: from Linear Interactions to Networked
Processes”, articol în Informatica Economică, nr. 4 (40)/2006, p. 74.
11 R.K. Mishra, Role of Information Technology in Supply Chain Management, în Indian online MBA
publications, la adresa http://www.indianmba.com/Faculty_Column/FC461/fc461.html
216

Comerţul electronic descrie un spectru larg de instrumente şi tehnologii
utilizate în scopul desfăşurării activității într‐un mediu fără hârtie. Ca urmare,
comerțul electronic include tehnologii precum EDI, e‐mail şi sprijină activități
precum transferul electronic al fondurilor, publicarea electronică a înştiințărilor,
procesarea imaginilor, găzduirea unui centru de buletine electronice, distribuirea
bazelor de date, introducerea magnetică/optică a datelor în sistem.
Electronic Data Interchange – EDI se referă la schimbul de informații, într‐un
format standard, de la un calculator la altul. EDI descrie atât capabilitatea, cât şi
practic de comunicare a informațiilor dintre două întreprinderi în manieră
electronică, în locul schimbului tradițional realizat prin poştă, curierat sau fax.
Beneficiile utilizării EDI sunt:
procesarea rapidă a informațiilor;
îmbunătățirea relațiilor cu partenerii de afacere;
diminuarea activității datorită eliminării hârtiei;
creşterea productivității;
îmbunătățirea procesului de urmărire a expediției coletelor;
eficientizarea costurilor;
îmbunătățirea activității de facturare;
obținerea de avantaje competitive.
Prin adoptarea tehnologiei EDI, partenerii din cadrul lanțului de aprovizionare
pot depăşi distorsiunile şi exagerările caracteristice cererii şi ofertei, prin
îmbunătățirea tehnologiilor care sprijină distribuția în timp real a informației
referitoare la cerere şi ofertă.
Utilizarea codurilorbară este cea mai vizibilă în activitățile unui supermarket,
pentru verificarea termenului de valabilitate, a prețului produselor la raft, dar mai
ales în momentul achitării, la ieşirea din magazin. Codul‐bară conține o multitudine
de informații legate de produs, precum denumirea, conținutul, greutatea,
producătorul, țara de origine etc. Această tehnologie este folosită deopotrivă şi în
alte ramuri decât comerțul, precum industria constructoare de maşini, a
calculatoarelor (în special în fazele de asamblare) etc.
Tehnologia depozitelor de date influențează benefic aplicațiile de tip SCM prin
consolidarea unei baze de date prin obținerea de informații din diferite sisteme
separate ale întreprinderii (vezi detalii despre depozitele de date în paragraful 8.2).
Este cunoscut faptul că majoritatea întreprinderilor dețin mai multe baze de date. În
cadrul acestora, depozitul de date este organizat cu precădere în jurul informației şi
mai puțin al proceselor economice. Informațiile din depozitul de date sunt
dependente de timp şi permit agregarea datelor istorice.
Unul dintre aspectele cele mai costisitoare ale lanțurilor de aprovizionare este
reprezentat de gestionarea eficientă a stocurilor. În consecință, cele mai populare
utilizări ale NTI în domeniul SCM sunt cele care sprijină activitatea de comunicare de
informații cu privire la epuizarea stocurilor, notificarea privind existența produselor
similare şi sugerarea substituirii acestora în lipsa produsului original, posibilitatea
transmiterii de informații cu privire la timpul de livrare şi calcularea costurilor
217

aferente, precum şi a eventualelor întârzieri pricinuite de transport. În cazul
integrării aplicației SCM în cadrul unui sistem integrat, sistemul de notificări poate fi
susținut de o componentă a sistemului ERP.

6.6.3. Avantajele utilizării tehnologiilor informaţionale în SCM

Beneficiile aduse de tehnologiile informaționale managementului lanțului de
furnizori sunt dintre cele mai diverse. Tehnologiile internet au exercitat un impact
deosebit de puternic, motiv pentru care vom detalia, în continuare, avantajele lor.
O rațiune semnificativă pentru utilizarea aplicațiilor bazate pe internet, de
comunicare businesstobusiness, este axată pe reducerea cheltuielilor. Activitatea
partenerilor poate fi eficientizată prin utilizarea NTI într‐un mediu de achiziție
electronică. Astfel, furnizorii pot afişa variante online ale cataloagelor, însoțite de
diferite funcții de căutare care permit cumpărătorilor să compare ofertele
furnizorilor pentru acelaşi produs sau serviciu. Desfăşurarea activității în varianta
online conduce la reducerea costurilor produselor, cât şi la diminuarea cheltuielilor
cu forța de muncă, clădirile şi cele aferente stocării.
Utilizarea sistemelor tradiționale EDI reclamă folosirea diferitelor pachete
software şi a tehnologiilor de rețea, conexiuni complexe în vederea comunicării cu
partenerii. Această tehnologie bazată pe infrastructură include mai multe platforme,
protocoale de rețea şi rutine de conversie a datelor. Lipsa de date standard şi
cerințele de comunicare cresc foarte mult complexitatea şi costurile de menținere a
acestor sisteme. Spre deosebire de aceasta, tehnologia internet oferă un singur canal
pentru comunicarea businesstobusiness, fără a solicita costuri suplimentare
semnificative. Pentru a deveni conforme cu tehnologia EDI, întreprinderile trebuie
să angajeze investiții semnificative în componente hardware şi software, în timp ce
internetul este instalat cu uşurință şi nu necesită tehnologii adiționale sofisticate.
Accesul la internet este relativ ieftin şi, în majoritatea cazurilor, nu solicită plata
unor taxe suplimentare asociate frecvenței şi duratei transferului de informații.
Utilizarea, în activitățile de gestionare a lanțului de aprovizionare, a
tehnologiilor bazate pe internet poate conduce la o mai mare transparență a pieței.
Datorită costurilor scăzute asociate cu instalarea şi întreținerea sistemelor de
achiziții bazate pe platformele internet, încurajează întreprinderile mici să adopte
astfel de sisteme.
Considerăm că internetul oferă o alternativă viabilă, care susţine reducerea
costurilor şi sprijină schimbul de informaţii dintre partenerii de afaceri, întrun timp
redus şi întrun mediu transparent. Mai mult, resursele necesare finalizării
tranzacțiilor specifice pot fi minimizate, menținând în acelaşi timp un mediu care
promovează transferul coerent de informații pentru fiecare dintre părțile implicate.
Tehnologiile informaționale au devenit în ultimul deceniu parte integrantă a
managementului lanțului de aprovizionare. În aceste condiții, se înregistrează o
creştere a numărului întreprinderilor, de diferite mărimi, care apelează la aplicații
informatice în vederea obținerii de beneficii în relațiile cu partenerii de afaceri.
Tehnologiile bazate pe platforma internet sunt recunoscute ca puternice
instrumente de sprijinire a activităților specifice lanțului de aprovizionare.
218

6.7. Prezenţa aplicaţiilor SCM pe piaţa naţională
şi internaţională

În România, marile companii au recurs la implementarea produselor software
în vederea informatizării activităților lanțului de aprovizionare‐desfacere. Tendința
arată că această situație este într‐o continuă evoluție, pe măsura intrării de noi firme
pe piață şi în condițiile maturizării firmelor existente.
Piața aplicațiilor şi serviciilor pentru gestiunea activităților lanțului de
aprovizionare‐desfacere a crescut de la an la an, oferind şi o „garanție” în ceea ce
priveşte durata şi calitatea acestora. În aceste condiții, afirmăm că soluțiile SCM s‐au
bucurat de un real succes şi în România, deoarece cu ajutorul acestor aplicații se
încearcă deschiderea de noi alternative către mediul de afaceri, răspuns cât mai
prompt cerințelor pieței, precum şi adaptarea la diferite situații neprevăzute. Printre
punctele forte ale aplicațiilor SCM raportate de beneficiarii lor enumerăm:
modernizarea modalităților de desfacere;
automatizarea procesului de achiziție;
integrarea fluxurilor operaționale.
Întreprinderile mari au informatizat deja activitățile specifice manage‐
mentului lanțului de aprovizionare‐desfacere şi studiile arată că se păstrează
trendul de creştere în acest sens. În ceea ce priveşte întreprinderile mici din
România, adoptarea soluțiilor SCM se află într‐un stadiu incipient din cauza puterii
de finanțare scăzute. În România, cel mai cunoscut furnizor de soluții SCM destinat
întreprinderilor mijlocii şi mari este Epicor.
Pachetele SCM distribuite de Oracle şi SAP acoperă peste 60% din oferta de pe
piață şi oferă mai multe module destinate diferitelor funcțiuni ale lanțului de
aprovizionare‐desfacere, din care companiile le selectează şi implementează pe cele
care se potrivesc cel mai bine pe modelul afacerii lor. Pe lângă aceste nume
consacrate, principalii producători autohtoni de soluții informatice pentru afaceri au
inclus în oferta lor şi componente specifice pentru SCM – Siveco, TotalSoft, Wizrom,
Crisoft, EBS Romania, Transart sau Senior Software sunt doar câteva exemple
semnificative. Spre deosebire de piața internațională, în România nu au fost până
acum oferte de aplicații SCM de la furnizori specializați exclusiv în acest domeniu
(cum sunt i2 Technologies sau Ariba). Dată fiind achiziția Ariba de către SAP în anul
2013, ar putea să apară de acum încolo şi pentru piața românească. Am putea
preciza în acest context că nici i2 Technologies nu mai există, fiind preluată de JDA
Software – locul 3 în topul mondial SCM (2012), care, la rândul ei, a fost preluată în
anul 2013 de o altă companie americană, RedPrairie.
Conform unui studiu Gartner, publicat în mai 2013, topul mondial al
furnizorilor de aplicații SCM, veniturile înregistrate (exprimate în milioane de
dolari) şi cota lor de piață (%) din anul 2012 sunt prezentate în tabelul 6.1. Se
observă că analiza efectuată este una comparativă şi priveşte anii 2011‐2012 – ea
determină evoluția înregistrată în perioada 2011‐20012 sub formă de procent. Se
219

observă astfel că majoritatea furnizorilor au înregistrat creşteri, pe fondul unei
creşteri consistente de 20,3% a întregii piețe de soluții SCM (însumează acum
peste opt miliarde de dolari), după ce în perioada 2008‐2011 s‐a cifrat în jurul
valorii de şase miliarde de dolari12.

Tabelul 6.1
Piaţa mondială de soluţii SCM (în milioane de dolari)

Cota de piaţă Cota de Diferenţa

Venit total Venit total
Producători 2012 piaţă 2011 20112012
în 2012 în 2011
(%) (%) (%)
SAP 1.721,.2 20,8 1.542,8 19,9 +0,9
Oracle 1.453,3 17,5 1.296,9 16,7 +0,8
JDA Software 426,0 5,1 430,4 5,6 +0,5
Ariba 319,2 3,8 366,9 4,7 +0,9
Manhattan As. 160,1 1,9 141,5 1,8 ‐1,1
Alții 4.216,0 50,9 3.114,5 51,3 ‐0,4
Total 8.295,8 100,0 6.893,0 100,0
Sursa: Gartner Press Release, 20 mai 2013, http://www.gartner.com/newsroom/id/2488715

Dacă anul 2008 a marcat o creştere lentă a pieței, de o singură cifră, cum le
place analiştilor să spună, 2009 a adus scăderea anticipată (2%). Lucrurile (şi
investițiile în IT, pe cale de consecință) au revenit pe făgaşul cel bun în anul 2010,
care a readus două cifre (10%) la procentul de creştere. Gartner previzionează că în
următorii ani piața soluțiilor SCM va înregistra o creştere anuală de peste 8,7%. La
această rată de creştere, piața acestor soluții se va dubla în mai puțin de zece ani13.
Topul mondial al primelor cinci firme (care dețin împreună aproape 50% din
venituri) este acelaşi de câțiva ani (SAP are în jur de 20% din piață, iar Oracle circa
17%), şi pe această piață înregistrându‐se consolidări prin achiziții – JDA Software,
după o evoluție remarcabilă în 2010, preia veteranul i2 Technologies şi se întăreşte
pe a treia poziție. Anul 2013 va aduce schimbări de nume în top de la locul 3 încolo,
căci Ariba a fost preluată de SAP, iar JDA Software, de compania RedPrairie.

Tabelul 6.2
Topul furnizorilor de soluţii SCM şi oferta lor pe categorii de soluţii

Producător SCP WMS MES TMS

1 SAP x x x x
2 Oracle x x x x
3 JDA Software x x
4 Manhattan Associates x x x
5 RedPrairie x x x

12 Mai multe informații relevante la nivelul anului 2013 sunt în Raportul Gartner, disponibil la
http://www.gartner.com/resId=2482418
13 ***, Gartner Announces Rankings of its 2012 Supply Chain Top 25, disponibil la
http://www.bloomberg.com/article/2012‐05‐22/afqd5VzmHZzw.html
220

Producător SCP WMS MES TMS

6 Epicor x x x
7 Descartes x
8 Servigistics x x x
9 Kewill Systems x
10 IBS x x x x
11 Totvs x x x
12 Logility x x x
13 Lawson Software x x x x
14 Retalix x x x
15 IBM x
16 Infor x x x x
17 GTNexus x x
18 HighJump x x
19 Quintiq x x x
20 Accellos x x
SCP – Supply Chain Planning; WMS – Warehouse Management System; MES – Manufacturing Execution
System; TMS – Transportation Management System.
Sursa: http://mmh.com/images/site/MMH1207_SpRpt_Top20Software.pdf

Aşa cum se observă în tabelul 6.2, în topul primilor 20 de producători
specializați în aplicații SCM, lăsând deoparte cele două „gorile” din vârf, sunt
jucătorii vechi (JDA Software, Manhattan Associates, Descartes sau RedPrairie), dar şi
apariții noi precum Epicor, Lawson Software şi gigantul IBM. Remarcăm din nou că
nume sonore, din perioada pionieratului SCM, au dispărut, firmele fiind asimilate de
alți jucători (Ariba, Commerce One, i2 Tehnologies, Manugistics).
Firma SAP, lider mondial pe piața mondială a soluțiilor software pentru
afaceri, conduce şi în sfera aplicațiilor SCM. Dacă până acum câțiva ani vorbeam
dspre mySAP SCM şi SAP SCM 4.0, cu pachetele SAP APO (SAP Advance Planning &
Optimization), SAP EM (SAP Event Management) şi SAP ICH (SAP Inventory
Collaboration Hub), astăzi, harta soluțiilor SCM este mult mai ofertantă, după cum
vom arăta în continuare în lista realizată14.
Integrated Sales and Operations Planning – S&OP. Este utilizată pentru
planificarea mai rapidă şi eficientă a producției şi vânzărilor, prin integrare cu
fişierele master, planificarea şi raportarea generate de soluția ERP asigurând
sincronizarea dintre aprovizionare şi necesar.
Manufacturing and Supply Planning. Creşte profitabilitatea lanțului
aprovizionare‐desfacere, printr‐un control sporit asupra cererii şi aprovizionării,
prin strângerea relațiilor cu furnizorii şi prin incursiunea în timp real în procesele
de fabricație. Lanțul de aprovizionare‐desfacere va putea fi operat pornind de la
cererea prognozată, dar având în vedere datele efective ale cererii.

14 Documentare realizată pe site‐ul SAP (http://www54.sap.com/solution/lob/scm/software/
overview/highlights.html).
221

Demand Management. Previzionează mai bine cererea, găseşte cel mai bun
raport față de aprovizionare şi estimează cu precizie reacțiile clienților la prețurile
viitoare şi la promoții. Soluția vizează cultivarea relațiilor cu clienții şi întărirea
acestora pe termen lung.
Service Parts Management. Asigură firma că va avea piesele necesare în
locul potrivit la momentul potrivit, pentru un management eficient al pieselor,
oferind inclusiv suport pentru RFID şi strategii avansate de logistică a acestora.
Collaborative Response Management. Îmbunătățeşte comunicarea cu
furnizorii, contractorii şi clienții, pentru a face mai eficientă colaborarea, a reduce
erorile şi a reduce costurile operaționale. Această soluție ajută la reducerea nivelului
stocurilor, printr‐o mai bună administrare a variațiilor în cerere şi aprovizionare.
Warehouse Management. Creşte eficiența activității depozitelor, optimi‐
zează operațiunile, printr‐un control mai strâns şi capabilități de automatizare.
Transportation Management. Planifică şi consolidează operațiunile de
expediție, oferind permanent informații despre constrângerile sau restricțiile
apărute, despre costuri şi penalizări. Sunt generate planuri de transport flexibile,
care se adaptează schimbărilor de proces sau noilor condiții.
Track and trace. Asigură vizibilitatea şi trasabilitatea materiilor prime şi
produselor în rețeaua de distribuție, cu scopul de a obține produse finite de calitate
maximă.
Mobile Solutions for the Supply Chain. Oferă soluții mobile pentru procesele
şi informațiile lanțului de distribuție (utilizatorii au acces mobil în condiții de
siguranță la aplicațiile şi informațiile de care au nevoie), urmărind creşterea
productivității şi a agilității pe o piață tot mai competitivă.
Ondemand Solutions for Supply Chain. Oferă soluții la cerere, cu scopul de a
răspunde rapid la schimbările pieței printr‐un lanț de distribuție care îmbunătățeşte
colaborarea şi potriveşte proactiv cererea cu oferta.
RapidDeployment Solutions for Supply Chain. Implementează soluții ori
servicii preconfigurate, cu funcționalități şi prețuri fixe, ceea ce permite
implementarea rapidă, perdictibilitatea duratei şi costului proiectului, precum şi
integrarea lină cu alte soluții SAP.
Supply Chain Sustainability. Vizează siguranța produselor şi concordanța cu
reglementările în vigoare, controlând impactul asupra mediului. Sunt permanent
urmărite standardele de siguranță şi dinamica reglementărilor legale, pentru a
redefini strategic modul de proiectare şi fabricare a produselor.
Manufacturing Integration and Intelligence. Integrează sistemele comerciale
cu cele operaționale pentru a dobândi vizibilitate în timp real asupra datelor de
producție, de la comenzi, la materiale şi la calitate. Oferă informațiile necesare
angajaților din zona producției, sub formă de rapoarte, dar şi alerte şi măsurători de
KPI. Sprijină inițiativele de îmbunătățire a proceselor, inclusiv Six Sigma şi Lean
Manufacturing.
Business Suite and Enhancement Packages. Oferă acoperire pentru toate
procesele economice, inclusiv cele specifice SCM, într‐o soluție complet integrată
care rulează pe baza de date dorită de client, inclusiv SAP HANA.
222

Beneficiile implementării aplicaţiei SAP SCM în cadrul activităţii întreprinderii BrownForman
Corporation15, care activează în sectorul produselor de larg consum, sunt următoarele
(conform afirmaţiilor beneficiarului16):
reducerea cu 40% a stocurilor de produse finite;
reducerea cu 20% a stocurilor de materii prime şi materiale;
reducerea cu 40% a stocurilor totale, cu excepţia celor asociate produsului de bază,
neîmbuteliat;
reducerea erorilor previzionale cu 33%;
intrarea pe piaţa vânzărilor la nivel global;
majorarea numărului de produse comercializate prin menţinerea aceluiaşi nivel al

stocurilor şi serviciilor.

Compania americană de software Oracle are peste 74.000 de angajați şi, pe
plan local, deține una dintre cele mai puternice echipe de specialişti în domeniu.
Conform propriei filosofii17, în ultimii 20 de ani, nici un domeniu de afaceri nu
s‐a schimbat mai mult decât cel al lanțului de aprovizionare, iar eficientizarea
operațiilor interne (backoffice) nu mai este suficientă pentru a putea a fi competitiv.
Transformarea lanțurilor de aprovizionare în lanțuri de valori, care până acum nişte
ani apărea doar în cărțile de specialitate, poate fi astăzi susținută de marii furnizori
de soluții. Oracle oferă o abordare unică pentru Value Chain Management, bazat pe
informații, în vederea dezvoltării soluțiilor care sprijină companiile să realizeze
crearea lanțului de valori.
Compania oferă atât soluții proprii din pachetul Oracle eBussines Suite, şi
anume Oracle Supply Chain Management, precum şi soluții obținute prin fuziune
de la alte companii, şi anume: PeopleSoft Enterprise Supply Chain Management,
JD Edwards EnterpriseOne Supply Chain Management, JD Edwards World
Manufacturing Management. De asemenea, în aplicațiile propuse se regăsesc
knowhow‐ul şi expertiza aduse de soluțiile achiziționate (Agile, Demantra,
360Commerce). Merită amintit aici şi faptul că Oracle a câştigat în anul 2007 numele
de „Best Supply Chain Management System” în Intelligent Enterprise 2007 Readers’
Choice Awards. Multe companii, din domenii diferite, au constatat că Oracle Supply
Chain Management este ideal pentru activitatea lor. Compania Oracle şi‐a
transformat chiar şi propriile operații cu ajutorul aplicațiilor Oracle, pentru
implementarea schimbărilor la nivelul practicilor de afaceri la divizia Sun, pe o
perioadă de doisprezece luni.
Cel mai complet pachet de aplicații destinate lanțului de aprovizionare, Oracle
Supply Chain Management, este alcătuit din: Value Chain Planning, Value Chain
Execution, Product Lifecycle Management, Advanced Procurement, Oracle Fusion

15 http://www.brown‐forman.com
16 http://www.sap.com/romania/about/events/Eficientizarea_proceselor/SAP_for_Food_and_Beverage.pdf
17 http://www.oracle.com/ro/solutions/scm/index.html
223

Applications, Asset Lifecycle Management, Order Fulfillment şi Manufacturing. Clienții
Oracle pot adopta întregul pachet sau aplicații individuale din cadrul acestuia. Acest
lucru le permite organizațiilor să identifice calea către transformarea lanțului de
valori prin finanțare proprie, deoarece succesul financiar al implementărilor inițiale
alimentează inițiativele viitoare.
Soluțiile SCM ale firmei Oracle transferă întreprinderilor abilitatea de a
previziona cerințele pieței, de a răspunde prompt la condițiile volatile ale pieței şi
conduc la alinierea operațiunilor din întreaga rețea globală. Oracle SCM oferă soluții
specifice domeniului, bazate pe cele mai bune practici, care se referă la dezvoltarea
produsului, managementul cererii, planificarea vânzărilor şi operațiilor, manage‐
mentul transporturilor şi managementul aprovizionării18. Producătorul se mân‐
dreşte cu faptul că soluţiile sale din domeniul SCM sunt realizate pe o arhitectură
deschisă, completă, bazată pe respectarea standardelor din domeniu. Mai mult, Oracle
afirmă că aplicațiile sale oferă capacitatea de a detecta, modela şi îndeplini cererea
cu cel mai bun management din domeniu, prin planificarea în timp real a vânzărilor
şi operațiilor, dispunând de componente pentru managementul global al transportu‐
rilor şi al aprovizionării.

Siteul web al firmei Oracle România prezintă câteva dintre rezultatele benefice obţinute de
clienţii din portofoliul aplicaţiilor SCM ale firmei:
Ingersol Rand: productivitate mai mare cu 50%, sarcina de asistenţă a furnizorului
redusă cu 75%, cheltuieli de întreţinere şi reparaţii reduse cu 20%;
UPenn: 77,5 milioane de dolari economii de cheltuieli documentate;
Sandia National Laboratories: economie de peste 11 milioane de dolari, timp de
procesare redus cu 25%;
VeriSign: reducerea ratelor de eroare cu peste 80% şi creşterea productivităţii cu 230%;
TUI: compania de logistică şi călătorii turistice a economisit 20 de milioane de euro cu
aprovizionarea şi până la 25% la bunurile indirecte;
Boeing: creşterea rabatului de volum cu 5%;
UPS: scurtarea ciclului cu 75%;
Pella: scurtarea ciclului cu 86%;
Aloca: reducerea costurilor de procesare a achiziţiilor cu 89%.

Pe plan național, multe întreprinderi româneşti acționează încă în maniera
tradițională, manifestându‐şi reticența în implementarea SCM şi se mulțumesc doar cu
utilizarea funcționalităților de bază (backoffice), incluse în soluția ERP aleasă. Evo‐
luția SCM‐urilor pe plan local devine vizibilă doar pe fondul reluării progresului
economic, datorită concurenței acerbe pe piața locală, a pătrunderii pe piața Uniunii
Europene şi alinierii la standardele impuse de aceasta, precum şi a investițiilor cu
capital străin realizate şi a mediatizării beneficiilor obținute prin implementarea

18
Prezentare pdf descărcată de la http://www.oracle.com/us/products/018526.pdf?ssSourceSiteId
=ocomro
224

acestor soluții. Astfel, conform studiilor realizate de IDC19, piața totală de aplicații
Enterprise Aplications Software (EAS) din țară a avut o evoluție bună până la anul
2009, când a început declinul. Ultima scădere s‐a înregistrat în 2011, fiind de 3,5%,
față de 2010, la un nivel de 78,33 milioane de dolari. Soluțiile de administrare a
resurselor unei companii (Enterprise Resource Management – ERM) reprezintă 56,1%
din veniturile EAS realizate în 2011, urmate de soluțiile de tip CRM, cu 16,4% şi de
supply chain management (SCM), cu 12,6%. Numele care se afirmă pe piața
românească includ bineînțeles SAP şi Oracle, la care se adaugă Epicor, Microsoft
(pentru ERP‐ul Axapta), Siveco sau Total Software. Şi celelalte firme autohtone
manifestă în ultimii ani interes pentru SCM (vezi exemplul Senior Software în caseta
următoare).

România, anul 201220. În interval de câteva luni, firma Senior Software anunţă lansarea mai
multor soluţii care vor ajunge să contureze la final suita SCM destinată managementului
lanţului logistic: aprovizionare, stocare şi livrare.
Prima a fost SeniorFMS (Fleet Management System), soluţie destinată managementului
parcului auto, care are în acoperire: gestionarea documentelor aferente maşinilor şi
şoferilor, respectiv localizarea şi urmărirea flotei auto.
A urmat lansarea SeniorWMS, dedicată gestiunii depozitelor, care automatizează toate
activităţile şi fluxurile de lucru specifice. Soluţia foloseşte cele mai noi tehnologii de
manipulare a mărfurilor (coduri de bare, terminale mobile wireless, picking pe bază de
indicatori vizuali, voce sau frecvenţă radio), asigurând o acurateţe de 100% în
trasabilitatea mărfurilor.
Soluţia SeniorINVENTORY completează suita SCM, promiţând o reducere cu până la 85% a
timpului de planificare a stocurilor. Sistemul asigură recuperarea în cel mai scurt timp a
investiţiei datorită economiilor făcute în procesul de aprovizionare, prin stocarea unei
cantităţi optime de marfă şi acoperirea eficientă a comenzilor de client. Sistemul de
planificare a stocurilor oferit de Senior Software calculează cantitatea care trebuie
reaprovizionată pentru fiecare articol în parte prin analiza istoricului vânzărilor pentru
perioade de până la patru ani.
Noua suită de gestiune a lanţului logistic, SeniorSCM, permite automatizarea şi optimizarea
proceselor, promiţând următoarele avantaje tangibile:
scăderea cu 85% a timpului dedicat planificării;
reducerea în siguranţă a stocurilor cu până la 40%;
înregistrarea a cu 30% mai puţine situaţii în care nu există stoc;
costuri de expediţie reduse cu 15%;
vânzări cu 512% mai mari;
creşterea vitezei de rotaţie a stocurilor;
îmbunătăţirea cashflowului.

19 Romania Enterprise Application Software 2012–2016 Forecast and 2011 Vendor Shares
(http://cl.exct.net/?qs=000d4d5485e19ae962d550756aa1552ee6dfd678a78768df72b7187973da0b8
14ea4331bd8822f9e).
20 Informații culese de pe site‐ul companiei: http://www.seniorerp.ro/media_room/
225

Din cele menționate, se observă că, la ora actuală, oferta soluțiilor SCM este
destul de vastă, întreprinderile putând opta pentru aplicațiile care îndeplinesc cel
mai bine obiectivele şi strategiile de afaceri. Totodată, ca urmare a progresului
economic, a schimbării mentalității întreprinderilor (în dorința de afirmare şi de a
rezista mediului concurențial în care îşi desfăşoară activitatea), precum şi datorită
aderării la Uniunea Europeană, tot mai multe întreprinderi vor căuta să‐şi
îmbunătățească soluțiile informatice deținute sau să‐şi implementeze soluții SCM
performante. Sub aspect financiar, se observă că piața produselor SCM este
dominată şi sunt preferați producătorii care au în ofertă şi sistemele ERP, că aplicații
open source nu există, iar opțiunile de tipul externalizării sau Software as a Service
sunt limitate ca număr şi arie de acoperire.

Specialiştii în domeniu sunt optimişti şi consideră că piaţa SCM din România este în continuă
creştere. Astfel, Adrian Anculete, membru al Association of Operations Management – APICS
(SCM Solution Area Leader EE&CIS, Oracle), declară, conform studiilor efectuate, că piaţa
SCM cunoaşte o creştere medie anuală de 20%, adică de circa zece milioane de dolari şi
atribuie acest fapt aderării României la Uniunea Europeanã. Dorin Babeş, specialist în
cadrul IBM, susţine de asemenea că segmentul soluţiilor SCM este foarte bine definit, având
o creştere semnificativă în piaţa din România şi acest lucru se datorează faptului că tot mai
multe companii caută modalităţi inovatoare de a deschide căi alternative de afaceri, de
îmbunătăţire a proceselor existente, pentru a răspunde cât mai rapid cerinţelor unei pieţe
atât de dinamice. Integrarea fluxurilor operaţionale, automatizarea proceselor de achiziţie
şi modernizarea modalităţilor de desfacere sunt doar câteva aspecte ale modelului SCM
vizate cu preponderenţă de companiile româneşti.
Cu toate că piaţa aplicaţiilor SCM a cunoscut un real succes în ultimii ani, putem oare să ne
mândrim cu performanţe româneşti din domeniu? Conform studiului realizat de compania
EastEuroLink, în cadrul conferinţei CEE Supply Chain Management 2009, răspunsul la
această întrebare este unul afirmativ. Studiul amintit a avut ca scop principal analiza
posibilei creşteri a pieţei SCM la nivelul Europei Centrale şi de Est. Robin Martens, directorul
general Archicom, a declarat că România ar putea deveni centru SCM în regiunea centrală
şi esteuropeană, cu condiţia să continue lupta pentru îmbunătăţirea infrastructurii
(autostrăzi, parcuri industriale). Menţionăm că studiul a analizat 250 de companii
internaţionale, cărora li sau cerut să numească cele mai bune locaţii din regiunea
menţionată pentru ca acestea săşi desfacă produsele, România fiind preferată de
majoritatea companiilor chestionate.

6.8. Tendinţe şi provocări SCM

În următorii ani, industria soluțiilor SCM va fi modelată de unele tendințe
externe care nu vor mai putea fi controlate de aceasta. În consecință, acest lucru nu
trebuie neglijat, iar întreprinderile şi distribuitorii trebuie să acorde importanță
meritată influenței acestor factori asupra desfăşurării propriei afaceri şi să
determine mijloacele prin care pot interveni eficient în rezolvarea problemelor
226

apărute. Printre tendinţele viitoare, le enumerăm pe cele economice, ecologice,
demografice şi noile tendințe tehnologice.
Tendinţele economice fac referire la noile piețe care se vor dezvolta din ce în
ce mai mult, precum şi la schimbările intervenite în identificarea surselor locale şi
globale în balanța condițiilor economice. Potrivit unui studiu pe 2010, Germania
ocupă locul I din 155 de economii evaluate prin LPI – indicatori privind performanța
în logistică.
Tendinţele ecologice pun accentul pe reducerea resurselor naturale.
Companiile vor trebui să‐şi desfăşoare activitatea cu respectarea aspectelor
ecologice atât pentru a păstra portofoliul de clienții, cât şi pentru a găsi noi soluții
pentru a conserva resursele de energie, apă etc. (aspecte legate de această tendință
sunt prezentate în cadrul Revoluției BIO din capitolul 10, cât şi în noțiunea de Green
Supply Chain Management din acest capitol).
Tendinţele demografice fac referire la urbanizare. Țările din vest vor
continua procesul de urbanizare, astfel că variațiile demografice vor fi într‐o
permanentă modificare.
Tendinţele tehnologice se referă în mare parte la explozia informațională,
iar răspunsul firesc la întrebarea „Ce nu aveau lanţurile de aprovizionare în trecut şi
au astăzi?” este tocmai accesul la informaţii. Astfel, prin utilizarea eficientă a
informației, s‐a obținut reducerea efectului de bici, perfecționarea sistemului de
plăți, precum şi reducerea costurilor. Acestea au condus la creşterea productivității
şi obținerea unor rezultate economice durabile. Noile tehnologii precum sateliții sau
dispozitivele de identificare cu frecvență radio (tehnologia RFID), senzorii de
temperatură, sistemele GPS vor continua pe viitor să îmbunătățească lanțul de
aprovizionare‐desfacere. Big Data a reprezentat una dintre cele mai importante
tendințe21 din IT în anul 2012. Combinarea şi utilizarea datelor oferite de partenerii
din lanțul de aprovizionare, precum şi analiza acestor date pentru a reacționa în
timp util, solicită mari capacități de stocare şi procesare a datelor. Soluțiile Big Data
combinate cu sisteme complexe de procesare a evenimentelor (Complex Event
Solutions) vor fi utilizate mai mult ca oricând în următorii ani pentru a putea digera
cantitatea impresionantă de date brute şi a le transforma în date exacte. Utilizarea
tehnologiilor BI reprezintă o altă tendință tot mai accentuată în ultimii ani. Aceste
tehnologii oferă suport în sintetizarea volumului uriaş de date înregistrat, facilitând
transformarea informațiilor în acțiuni de îmbunătățire a lanțului de aprovizionare‐
desfacere şi atingerea unor obiective precum creşterea eficienței operațiunilor şi
reducerea costurilor, sau îmbunătățirea relațiilor strategice cu partenerii de afaceri.
BI aplicate în SCM au dat Supply Chain Analytics, soluții care sunt folosite în
realizarea unor activități simple precum clasificarea costurilor operațiunilor din
cadrul lanțului până la nivel granular, dar şi în realizarea unor activități complexe de
analiză drill down, pentru detectarea celor mai mici deficiențe.
Cele mai importante provocări lansate de Supply Chain Management sunt:

21 S. Riley, „Five Supply Chain Trends that shaped 2012”, www.scmr.com/article/five_supply_chain
_trends_that_shaped_2012
227

extinderea lanțurilor de aprovizionare în afara granițelor țării;
îmbunătățirea inventarierii, precum şi răspunsul prompt şi personalizat la
schimbările neaşteptate ale cererii şi ofertei;
implementarea pe scară largă a tehnologiilor noi precum RFID;
creşterea complexității lanțului de aprovizionare.
Viitorul aplicațiilor SCM este legat de utilizarea tehnologiilor Radio Frequency
Identification (RFID), creşterea rolului soluțiilor de Warehouse Management (WMS)
şi Transportation Management Systems (TMS)22. De asemenea, evoluția spectacu‐
loasă a tehnologiilor mobile şi a serviciilor de cloud computing îşi va pune amprenta
şi pe piața SCM, crescând oferta de soluții pe bază de abonament (în regim SaaS).
Unul dintre vicepreşedinții Gartner, Chad Eschinger, consideră că în viitor
aproximativ 70% din soluțiile SCM din topul actual vor fi disponibile în cloud.
Dincolo de aspectele tehnologice şi metodologice enunțate, cea mai mare
provocare SCM constă în depăşirea mentalității că o întreprindere în mod individual
poate deține supremația, rețeta absolută, respectiv cel mai eficient model al lanțului
de distribuție. Realitatea este că întreprinderile trebuie să conlucreze şi să se
sprijine reciproc pentru a înregistra succes. Fiecare componentă a lanțului este o
verigă importantă, iar un lanț puternic este unul format din verigi solide. Compo‐
nentele fragile cauzează disfuncționalități în întreg lanțul de distribuție, cu efecte
resimțite până la consumatorul final.

22 B. Trebilcock, „Supply Chain Technology: What’s happening in the innovation economy image”,
Supply Chain Management Review, iunie 2010, disponibil la http://logistics.about.com/
gi/o.htm?zi=1/XJ/Ya&zTi=1&sdn=logistics&cdn=b2b&tm=42&f=00&tt=14&bt=1&bts=1&zu=http%3A
//www.scmr.com/article/CA6591248.html%3Findustryid%3D48316
228

CAPITOLUL 7
Enterprise Application Integration – integrarea
fără frontiere. SOA

& cunoaşteţi principalele tehnologii de integrare;
& vă familiarizaţi cu obiectivele, rolul şi etapele EAI;
& aveţi informaţii despre oferta EAI şi furnizorii de soluţii EAI;
& înţelegeţi factorii de risc în implementarea EAI şi capcanele integrării;
& aveţi cunoştinţe legate de integrarea prin SOA.
7.1. Tehnologii integratoare

Pentru ultima decadă a secolului XXI, schimbarea a fost singura constantă,
generând pentru mediul de afaceri surse continue de oportunități. Pasul
schimbărilor sociale, financiare şi tehnologice este unul rapid, având un impact
puternic atât asupra afacerilor mari, cât şi asupra celor medii, mici şi mijlocii din
întreaga lume. Analiza specialiştilor1 a demonstrat că, dacă fluxul schimbărilor este
constant, pasul de adaptare la schimbare al companiilor fluctuează. Întotdeauna vor
exista companii care adoptă aceste modificări înaintea majorității şi companii care
vor fi rezervate. De asemenea, evoluția globală spectaculoasă a lanțurilor de afaceri
a generat complexitate în lanțul de valori. Astfel, a fost necesară dezvoltarea unui set
de tehnologii de integrare2 (sau tehnologii integratoare) care să optimizeze fluxurile
informaționale şi să gestioneze corect volumul de date, dintre care face parte şi
Enterprise Application Integration (EAI). Vom prezenta în cele ce urmează aspecte
privind tehnologiile de integrare Electronic Data Integration (EDI), EAI şi web
services, avantaje şi dezavantaje, precum şi necesitatea acestora.
EDI a fost o tehnologie utilizată în trecut pentru a intermedia schimbul
electronic de documente, în manieră calculator‐calculator, între organizații sau în
interiorul acestora (mai multe informații despre această tehnologie au fost
prezentate în capitolul 1). Deşi tehnologiile EDI facilitează integrarea datelor, le
lipseşte abilitatea de a integra procese şi nu oferă flexibilitatea cerută de aplicațiile
moderne.
EAI a apărut din necesitatea de a depăşi limitele sistemelor integrate ERP.
Astfel, prin EAI se urmăreşte integrarea aplicațiilor insulare în aplicații compatibile
care facilitează funcționarea optimă a proceselor economice şi schimbul de
informații dintre aplicații. Mai multe detalii despre acest concept vor fi prezentate în
capitolul de față.
Web services a apărut ca element de noutate la nivelul anului 2005. În esență,
această tehnologie permite aplicațiilor, indiferent de platforma sub care au fost
implementate sau de limbajul cu care au fost dezvoltate, să fie integrate şi să
funcționeze într‐o manieră facilă, cu costuri mai reduse decât în cazul altor
tehnologii. Există totuşi probleme în ceea ce priveşte adoptarea tehnologiei
serviciilor web precum: lipsa experienței în arhitectura serviciilor web, multitudinea
standardelor de implementare, imaturitatea tehnologiei şi problemele de securitate.
Din dorința de a compara cele trei tehnologii, apelăm la rezultatele analizei
elaborate de Khoumbati ş.a., în care sunt luate drept etalon caracteristicile
tehnologiei EAI, iar apoi sunt comparate cu cele ale celorlalte tehnologii. Rezultatele
sunt prezentate în tabelele 7.1 şi 7.2.

1 ***, Clash of the titans, an independent comparison of SAP, Oracle and Microsoft Dynamics, http://panorama‐
consulting.com/resource‐center/clash‐of‐the‐titans‐sap‐vs‐oracle‐vs‐microsoft‐dynamics/
2 K. Khoumbati, M. Themistocleous, Z. Irani, „Integration Technology Adoption in Healthcare
Organisations: A Case for Enterprise Application Integration”, Proceedings of the 38th Annual Hawaii
International Conference on System Sciences (HICSS'05), 2005, p.149a.
Enterprise Application Integration – integrarea fără frontiere. SOA 231
Tabelul 7.1
Avantaje şi dezavantaje ale tehnologiilor de integrare

Tehnologia Avantaje Dezavantaje

EDI • Îmbunătățeşte relațiile cu furnizorii • Reclamă investiții inițiale
• Oferă răspuns rapid partenerilor de majore de capital şi
afaceri echipamente compatibile de
• Reduce erorile de introducere a ambele părți
datelor • Implementare dificilă
• Creşte eficiența economică • Cuantificare dificilă a
• Elimină sarcinile intensive de muncă beneficiilor
EAI • Îmbunătățeşte relațiile cu partenerii • Investiții ridicate
de afaceri • Ridică probleme complexe
• Asigură rentabilitatea investiției • Necesită competențe tehnice
• Maximizează performanțele lanțului specifice
de aprovizionare‐desfacere • Integrare confuză a
• Focus pe integrarea proceselor tehnologiilor
economice
Web • Reduce timpul de dezvoltare • Necesită grad ridicat de
Services • Costuri scăzute de implementare customizare
• Minimizează costurile de întreținere a • Nu deține suport pentru
sistemelor tranzacții
• Nu necesită competențe avansate de • Performanțe imature
programare • Nu deține interfață utilizator
• Risc minim de eşec al proiectului • Probleme de securitate
Sursa: Adaptare după Khoumbati, K., Themistocleous, M., Irani, Z., „Integration Technology Adoption in
Healthcare Organisations: A Case for Enterprise Application Integration”, Journal of Management
Information Systems, volume 22, issue 4, number 4/Spring 2006, pp. 69‐108.

Tabelul 7.2
Analiză comparativă a caracteristicilor tehnologiilor de integrare

Tehnologie
Caracteristica analizată
EAI EDI Web Services
Adaptabilitate – permite schimbări ulterioare care nu D D
afectează componentele sistemului
Flexibilitate – în funcționare, în modificare şi în D
utilizare
Scalabilitate – abilitatea de a oferi performanțe ridicate D D D
şi în condițiile creşterii numărului de utilizatori
Portabilitate – permite unei soluții dezvoltate pe o D D
platformă să ruleze şi pe o altă platformă
Reutilizare – utilizarea componentelor sau a soluției D D D
software pentru a dezvolta noi aplicații
Maturitate – se referă la maturitatea tehnologiei de D D
integrare
Complexitate – tehnologia conduce la dezvoltarea de D D
soluții simple sau complexe

Tehnologie
Caracteristica analizată
EAI EDI Web Services
Performanţă – la nivel de integrare D
Nivele de integrare – distribuirea informațiilor între D
echipamente şi aplicații diferite
Suport pentru tranzacţii în timp real D D
Securitate D D
Acces concurent D D
Sursa: Adaptare după K. Khoumbati, M. Themistocleous, Z. Irani, „Integration Technology Adoption in
Healthcare Organisations: A Case for Enterprise Application Integration”, Journal of Management
Information Systems, volume 22, issue 4, number 4/Spring 2006, pp. 69‐108.

Analiza realizată mai sus, în cadrul celor două tabele, indică o bună
poziționare a tehnologiei EAI față de celelalte două. Analiza caracteristicilor stă la
baza deciziei referitoare la tipul de tehnologie selectată în vederea integrării
aplicațiilor dintr‐o anumită industrie sau sector de activitate.

7.2. EAI – evoluţia conceptului

În contextul sistemelor de tip ERP, conceptul de integrare a aplicațiilor,
respectiv EAI, poate apărea în următoarele situații:
integrarea dintre modulele ERP. Există exemple de soluții integrate în care
modulele interacționează prin intermediul unui sistem de mesaje, implementat cu
ajutorul metodologiei EAI. Este cazul integrării ESB (Enterprise Service Bus), care
ține de SOA (Service Oriented Architecture). Menționăm ca exemplu produsul NEXT,
dezvoltat de JXEE LAB;
integrarea sistemului ERP cu alte aplicaţii de întreprindere sau cu alte
sisteme ERP. Spre exemplu, întreprinderile care dețin un sistem ERP de a cărui
funcționalitate sunt mulțumite şi doresc să implementeze o aplicație de tip SCM sau
CRM de la un alt furnizor constituie un caz de integrare a sistemului ERP cu o altă
aplicație (în cazul de față, o soluție CRM sau SCM), cel mai probabil dezvoltată pe o
platformă diferită, motiv ce reclamă intervenția tehnologiilor EAI în vederea
integrării.

Enunţăm exemplul integratorului de soluţii pentru întreprinderea NESS România, care
foloseşte următoarele tehnologii integratoare de tip EAI: SAP Netweaver, Oracle, BEA. Cu
ajutorul acestora, NESS oferă soluţii EAI centrate pe crearea unor platforme de
infrastructură software care au ca scop principal simplificarea conectivităţii între aplicaţii
eterogene şi sisteme economice diferite. Astfel, firma amintită anunţă că integrează şi
potenţează investiţiile clientului în sistemele curente şi transformă întreprinderea,
permiţând aplicaţiilor săşi asume noi responsabilităţi în timp ce distribuie informaţia
dincolo de graniţele întreprinderii.
Secretul succesului firmei stă în cunoaşterea diferenţelor existente între aplicaţii, precum şi
între structurile datelor şi selecţia unei platforme de integrare fiabilă şi de cea mai bună
calitate.

7.2.1. EAI – istoric, tendinţe şi evoluţie

Enterprise Application Integration costituie unul dintre acele cuvinte tehnice,
foarte des vehiculate în domeniul IT, care se referă la integrarea aplicațiilor din
întreprindere în vederea partajării informațiilor şi proceselor specifice3.
Această noțiune este cunoscută specialiştilor încă din perioada apariției
mainframe‐urilor, iar pentru prima dată a fost introdusă de firma IBM. La mijlocul
anilor ’90, s‐a conturat pentru prima dată ca o categorie distinctă de aplicații software.
Delimitarea clară a venit însă la sfârşitul deceniului, în anii de explozie a pieței ERP,
când aceste suite de aplicații şi integrarea informațională au atins un nivel maxim de
interes. EAI s‐a consacrat atunci ca soluție integratoare A2A (Applicationto
Application), pentru conectarea noilor aplicații în sistemele existente.
EAI cuprinde un set de tehnologii care permit circulația şi schimbul de
informații între aplicații şi diferite procese de afaceri în interiorul şi între
organizații. Este, de exemplu, o modalitate de a integra sisteme separate în timpul
punerii în aplicare a unei inițiative CRM.
Pe următoarea treaptă evolutivă post‐A2A, EAI a luat forma B2B (Businessto
Business), unde aplicațiile au fost utilizate în spațiul de integrare interîntreprinderi şi
ca tehnologie de suport pentru aplicațiile B2B. Succesul inițiativelor e‐bussines, care
se manifestă tot mai pregnant în noul mileniu, depinde în cea mai mare măsură de
reuşita integrării cu sistemele deja funcționale în organizațiile beneficiare…, şi aceasta
întrucât e‐business înseamnă mai mult decât site‐uri web cu design deosebit, care
impresionează vizitatorul. Informațiile transmise prin aplicațiile e‐business trebuie să
ajungă în sistemul central de administrare al organizațiilor pentru a contribui la
imaginea completă a tuturor proceselor din întreprindere precum situația stocu‐
rilor, a operațiunilor de vânzare‐cumpărare sau a proceselor de producție. Pentru ca o
aplicație e‐business să‐şi poată atinge adevărata valoare, trebuie să existe integrare
între aplicații.
Ca tendință evolutivă, menționăm că noul nivel EAI este atins astăzi de SOA,
concept de care ne vom ocupa în finalul capitolului.

7.2.2. Ce este EAI?

Organizațiile încearcă să‐şi susțină activitatea prin combinarea de aplicații
care lucrează de cele mai multe ori pe platforme hardware diferite şi care nu
realizează o comunicare cu pachetele software din afara domeniului lor. Adesea,
compania recurge la angajarea unei echipe de consultanți care au sarcina de a

3 D.S. Linthicum, Enterprise Application Integration, Addison‐Wesley Professional, 1999, p. 18.

parcurge procesul lung şi costisitor în vederea determinării fezabilității sistemelor şi
de a proiecta integrarea. Această din urmă etapă are ca scopuri dezvoltarea şi
implementarea procedurilor de realizare a integrării. Multe dintre aceste proiecte
sunt sortite eşecului, din multiple motive, precum renunțarea la integrare din
pricina costurilor, a duratei prea mari de timp sau abandon cauzat de lipsa
perspectivei de succes. EAI înseamnă o abordare diferită în procesul de rezolvare a
problemelor, bazată pe un set de semantici pentru integrarea aplicațiilor şi a datelor.
EAI reprezintă setul de tehnologii care permite circulația şi schimbul de
informații între diferite aplicații şi procese de afaceri în cadrul şi între organizații,
este o modalitate de a integra sisteme dispersate în timpul punerii în aplicare a
noilor inițiative software.
Opiniile vizavi de modalitatea de implementare a integrării şi de oportunitate
a acesteia sunt împărțite. Însă, referitor la conceptul EAI, următoarea formulă4 este
certă:
EAI = ERP2ERP + B2B + Workflow + EDI + BPM
EAI are în vedere planurile, metodele şi instrumentele care vizează moder‐
nizarea, consolidarea şi coordonarea aplicațiilor insulare dintr‐o întreprindere. Prin
integrare se poate dezvolta o viziune nouă de afaceri, la nivelul unei organizații, care
vizează în principal aplicațiile sale.
EAI promite soluții eficiente şi efective. Indiferent de tipul aplicațiilor care
trebuie integrate, EAI oferă organizației oportunitatea de a implementa o interfață
comună, care să faciliteze integrarea tuturor aplicațiilor şi gestiunea fluxurilor de
date, stabilind un mediu în care să poată fi adoptate viitoarele inițiative tehnologice,
în condițiile remodelării sau definirii de noi procese economice.
Unii autori văd în EAI o asigurare de viaţă pentru sistemul informatic al
întreprinderii. Există însă analize care indică ezitări serioase din partea companiilor
în privința proiectelor EAI:
un studiu efectuat de Consultants Advisory arată că jumătate din managerii
chestionați nu au dezvoltat un plan real de integrare informațională pentru
organizațiile pe care le conduc, în principal din cauza costurilor, imaturității pieței
EAI sau chiar neînțelegerii conceptului EAI;
site‐ul britanic www.conspectus.com a publicat rezultatele unui studiu în
care un număr foarte mic de firme consideră că rezultatul integrării a fost benefic
pentru organizație5.
Văzut ca proces de integrare a aplicațiilor în cadrul unei companii, EAI
reprezintă „ansamblul de instrumente software utilizate pentru implementarea şi
automatizarea legăturilor dintre aplicaţiile backoffice, frontoffice şi aplicaţiile
partenerilor de afaceri”.

4 D. Fotache, L. Hurbean, Soluţii informatice integrate pentru gestiunea afacerilor. ERP, Editura
Economică, Bucureşti, 2004.
5 C. Leach, „Making EAI happen in the real world”, disponibil la www.conspectus.com/2005/
october/article7.asp
Fiind un concept cu o largă acoperire, EAI poate fi privit şi definit din mai multe
perspective:
un proces de integrare a aplicațiilor de la toate nivelurile unei companii;
o metodă de legătură performantă a diverselor aplicații eterogene,
asigurând comunicarea între acestea, care înglobează fluxul de informații specific
unei organizații;
un pachet de aplicații informatice şi metodologii de modelare a proceselor,
care ajută organizația să se adapteze uşor şi rapid la schimbările pieței;
un ansamblu de instrumente, aplicații şi metode care reunesc şi integrează
activitățile unei companii, oferind sprijin nelimitat managementului;
un set de tehnologii pentru conectarea aplicațiilor într‐o platformă unică ce
susține procesele economice, indiferent dacă este software proprietar sau dezvoltat
inhouse;
un sistem de notificare între diverse aplicații, legate într‐o platformă unică,
ce sprijină generarea, derularea şi managementul proceselor.
Interesul pentru integrarea aplicațiilor este din ce în ce mai mare, mai ales
datorită apariției sistemelor frontoffice (CRM) şi a celor colaborative (SCM). Acestea
nu îşi pot atinge obiectivele prin funcționare independentă, ci numai în strânsă
legătură cu aplicațiile de bază din sistemul backoffice al organizației. Integrarea din
cadrul companiilor presupune eforturi şi consum de resurse, financiare şi umane. În
acest context, investițiile în aplicații CRM şi SCM trebuie să ia în calcul şi costul
integrării, care asigură corelarea proceselor frontoffice şi backoffice.
Tehnologiile EAI sunt încă în curs de dezvoltare şi nu există un consens pentru
rețeta ideală de abordare sau setul de tehnologii care trebuie adoptat de o companie.
Cel mai des întâlnită greşeală constă în folosirea altor tehnologii proprietare care
sunt declarate ca fiind deschise şi extensibile, dar care în fapt determină clientul să
devină dependent de vânzător.
Apreciem că în viitor EAI se poate împărți în două zone: strategică şi tactică.
Într‐o descriere succintă, soluţia EAI strategică asigură gestiunea şi supervizarea
proceselor transversale, bazate pe schimburi de date între servicii, filiale, entități
interne şi externe. Varianta EAI tactică pune în funcțiune fluxuri tehnice care
acoperă transportul, rutarea şi transformarea datelor, în scopul sincronizării,
consolidării şi replicării acestora. Diferența este vizibilă şi în modul în care este
abordată problema integrării informatice:
un demers topdown, în cazul soluțiilor strategice, ceea ce implică o
reconstruire aproape totală a sistemului de informații, pornind de la definițiile
proceselor de afaceri, sau
un demers bottomup, în care, într‐o fază inițială, în cadrul unui EAI sunt
integrate aplicațiile existente, urmând ca ulterior să fie extins progresiv perimetrul
EAI, pe măsura evoluției sistemului informatic.
Conform unui studiu Forrester Research 2008, 25% din companiile
participante la sondaj au afirmat că au renunțat la integrarea EAI, optând pentru o

soluție ESB (Enterprise Service Bus)6. Practic, conceptul ESB nu inventează nimic
nou, însă aduce valoare prin interfețele standard Web Services, ceea ce îl diferențiază
de soluțiile EAI proprietare. Se confirmă astfel tendința manifestată în zona
integrării ERP prin SOA.

7.2.3. Obiectivele, rolul şi etapele EAI

Integrarea semantică realizată prin EAI diferențiază această variantă de mai
simplele soluții de conectare a aplicațiilor la nivelul fluxurilor (integrare workflow).
În cadrul procesului de integrare a aplicațiilor de întreprindere, organizația
beneficiară trebuie să urmărească atingerea următoarelor obiective:
abilitatea de a extrage şi de a importa date la nevoie;
capacitatea de a comunica informații prin intermediul protocoalelor
internet, acoperind cerințele specifice protecției şi securității datelor;
posibilitatea dezvoltării de noi procese economice, în mod dinamic.
Rolul principal al EAI constă în intermedierea schimbului de informații dintre
aplicațiile eterogene ale unei organizații, precum şi cu aplicațiile clienților sau
furnizorilor.
Scopul EAI constă în asigurarea funcționării optime a unui set de aplicații,
servind ca mediator care facilitează comunicarea cu toate tipurile de aplicații. Astfel,
prin proiectele EAI, sistemele şi entitățile disparate vor fi regândite şi modelate
împreună pentru atingerea obiectivelor organizației şi sunt astfel aduse la un
numitor comun. Piesele supuse combinării pot fi formate din: variate platforme şi
sisteme de operare, o paletă largă de aplicații (dezvoltate inhouse sau achiziționate,
ce funcționează individual sau integrate în suite ERP), baze de date şi sisteme de
gestiune specifice, unități organizatorice dispersate teritorial etc.
În literatura de specialitate sunt descrise patru stadii distincte ale procesului de
integrare a sistemelor7 (fiecare dintre acestea se definesc individual şi dețin
proprietăți, aspecte şi grade de complexitate diferite):
interconectivitatea. Este etapa elementară şi formează infrastructura
celorlalte. Presupune analiza modalităților prin care echipamente şi tehnologii
diferite lucrează împreună. Sunt incluse aici aplicații de partajare a perifericelor,
transferurile de fişiere, stabilirea canalelor de comunicare dintre diversele
componente. Aplicațiile de bază şi modul lor de funcționare, legăturile aferente
următoarelor stadii ale integrării se stabilesc tot în această etapă;
interoperabilitatea. Este etapa în care o aplicație şi tehnologia aferentă
ajung să comunice cu un alt produs, exploatând funcționalitățile ambelor platforme.
Interoperabilitatea este deosebit de importantă mai ales în domeniul bazelor de

6 Prezentare Larry Fulton (ESB Lessons learned‐2008), disponibilă la http://download.
progress.com/5331/open/sonic/webcasts/20080417_ESB_Lessons_Learned/index.htm
7 D.S. Linthicum, op. cit.; G. Ruhe, G. Du, „Strategic planning of enterprise application integration”,
http://www.releaseplanner.com/Downloads/papers/ C04c_EAI_final_paper.pdf
date, unde aplicațiile sunt complexe şi se cere compatibilitate maximă între
platforme;
consistenţa semantică. Este etapa integrării semantice, legată de imple‐
mentarea sistemelor de gestiune a bazelor de date şi a sistemelor avansate de
analiză şi raportare managerială. O importanță deosebită se acordă accesibilității
datelor şi minimizării erorilor umane în procesul de creare a definițiilor standard şi
a formatelor pentru date. În vederea realizării integrării semantice, simpla imple‐
mentare a sistemelor de gestiune a bazelor de date nu este suficientă. Datele trebuie
să fie supuse unui proces de raționalizare, în vederea utilizării cu acuratețe a
acestora;
convergenţa integrării. Constituie etapa cea mai avansată şi este
dependentă de parcurgerea etapelor anterioare. Această etapă reprezintă mai mult
decât integrarea tehnologiilor, aplicațiilor şi raționalizarea bazelor de date partajate.
Integrarea sistemelor este kilometrul zero al dezvoltării de noi forme organizaţionale
(întreprinderea virtuală) şi naşterea unor procese noi de afaceri. Această etapă
antrenează integrarea tehnologiilor cu procesele de afaceri, cu performanțele şi
cunoştințele umane. Specialiştii din domeniu consideră că în cadrul procesului de
integrare putem vorbi despre şapte direcții:
1) integrare hardware – interconectivitate;
2) integrare software – interoperabilitate;
3) integrarea datelor şi a depozitelor de date – integrare semantică;
4) integrarea rețelelor de comunicații – interconectivitate, interoperabilitate
şi integrare semantică;
5) descrierea şi integrarea noilor procese de afaceri cu noi performanțe
tehnologice;
6) încorporarea cunoaşterii în cadrul noilor procese de afaceri, precum şi în
noile tehnologii informaționale;
7) integrarea performanțelor personalului în procesele electronice de afaceri.
Procesul de integrare se consideră finalizat când, în mediul economic al
organizației, tehnologiile, performanțele umane şi procesele de afaceri funcționează
într‐un ansamblu armonios.
Cunoscut fiind faptul că un proiect EAI are ca obiectiv principal asigurarea
capabilității sistemelor complexe de a comunica şi schimba informații în modul cel
mai eficient posibil şi că trăim într‐o lume orientată pe servicii, putem privi EAI în
două contexte:
furnizor de servicii. Din această perspectivă se doreşte un serviciu uşor de
implementat şi de actualizat;
consumator/beneficiar de servicii. În această calitate este de dorit ca un
serviciu să fie uşor de accesat, disponibil, complet funcțional şi stabil pe o perioadă
de timp nedeterminată.
Pentru a satisface aceste două perspective, EAI promite deschiderea de noi
oportunități de afaceri, care includ aplicațiile web, tehnologiile intranet/extranet şi
tehnologiile mobile. Soluțiile EAI schimbă statutul clienților şi furnizorilor: din
outsideri devin parte componentă a mediului organizațional extins.

În concluzie, îndeplinirea obiectivelor EAI trebuie să atingă următoarele

scopuri principale:
integrarea datelor – asigură consistența informației în sisteme multiple şi
contribuie la conectarea proceselor între aplicații;
integrarea proceselor – integrează procesele de afaceri ale aplicațiilor;
independenţa faţă de furnizor – stabileşte distincția dintre politicile
economice şi regulile aplicațiilor (de exemplu, modificarea datelor unui furnizor nu
trebuie să conducă la reconstrucția aplicației);
interfaţă unică – asigurarea unei interfețe unice în vederea accesării
diferitelor aplicații integrate.
Apreciem că utilizarea eficientă a tehnologiilor EAI adaugă valoare investi‐
țiilor concretizate în aplicații dezvoltate/achiziționate deja de organizație. Mai mult,
prin integrare se pot furniza produse noi, superioare, uşor de utilizat, cu multiple
destinații, precum cele clasice care se referă la îmbunătățirea relațiilor cu furnizorii
şi clienții sau în scopul raționalizării operațiunilor unei organizații. Utilizată în
companii, EAI simplifică substanțial interacțiunile cu alte aplicații de întreprindere,
prin adoptarea unei abordări standard în vederea integrării pe termen lung a
aplicațiilor.

7.2.4. Nivelurile integrării EAI

Problema integrării aplicațiilor de întreprindere vizează cel puțin două
aspecte:
integrarea funcțiilor şi cerințelor aplicațiilor componente,
integrarea tehnologiilor informaționale pe care sunt fundamentate aplicațiile.
Reputatul autor Meinadier8 a realizat o clasificare a nivelurilor de integrare
astfel:
1) nivelul integrării funcţionale între sistemele informatice, ca rezultat al
evoluției acestora spre integrarea activităților de dezvoltare;
2) nivelul integrării tehnice.
Acelaşi autor vorbeşte despre integrarea sistemelor informaționale din
perspectivă semiotică pe trei niveluri: pragmatic, semantic şi sintactic.
Un alt specialist, Schmidth9, în lucrarea „Enabling Next‐Generation
Enterprises”, a realizat o clasificare a nivelurilor evolutive de integrare a aplicațiilor,
astfel:
nivelul 1 – integrarea punctlapunct (PointtoPoint Integration) implică
stabilirea unei infrastructuri de bază a schimbului de date între aplicații;
nivelul 2 – integrarea structurală (Structural Integration). La acest nivel,
organizația utilizează instrumente middleware avansate în scopul standardizării şi

8 J.P. Meinadier, Ingéniérie et intégration des systèmes, Hermes, Paris, 1998.
9 J. Schmidt, „Enabling Next‐Generation Enterprises”, EAI Journal, July/August 2000, pp. 76‐77,
disponibil și la http://infothink.com.ne.kr/download/EnablingNextGeneration.pdf
controlului schimbului de informații dintre aplicații. Se utilizează aici o magistrală
(bus) şi reguli de funcționare specifice afacerii (Business Rules);
nivelul 3 – integrarea proceselor (Process Integration). La acest nivel,
organizațiile realizează tranziția de la partajarea informațiilor între aplicații la
gestionarea reală a fluxului dintre aplicații;
nivelul 4 – integrarea externă (External Integration). La acest nivel, se
realizează integrarea sistemului informațional al organizației cu cele ale partenerilor
de afaceri.

7.2.5. Avantajele şi dezavantajele integrării EAI

Avantajele pot fi sistematizate astfel:
accesul la informaţii în timp real. Avantajul este datorat în principal bazei
de date unice. Fiecare compartiment al organizației poate introduce date noi în
sistem şi, implicit, să colecteze informații calitative şi cantitative în timp real, din alte
aplicații;
fluxurile raţionalizate de informaţii. Prin implementarea EAI, fluxurile de
date sunt controlate, organizate şi agregate. Întreaga organizație se poate bucura de
un acces rapid şi uşor la informații valoroase şi coerente;
posibilitate de customizare. Cerințele specifice domeniului de activitate pot
fi integrate cu uşurință în aplicații. În funcție de structura organizatorică, mărimea
întreprinderii, necesități, aplicațiile vor fi personalizate astfel încât să răspundă cu
promptitudine tuturor nevoilor şi cerințelor;
flexibilitate. Platformele EAI facilitează reconfigurarea proceselor afacerii,
odată cu modificarea strategiei firmei;
creşterea eficienţei organizaţionale a proceselor de afaceri. Prin
automatizarea proceselor, creşte eficiența în cadrul compartimentelor, angajații au
mai puține atribuții de execuție, iar posibilitatea de apariție a erorilor este mult mai
mică (deoarece este redusă frecvența apariției erorii umane);
menţinerea integrităţii informaţiilor prin sisteme multiple. Acest lucru se
realizează cu ajutorul criptografiei, utilizând protocoale, rețele private virtuale,
semnături virtuale, certificate etc.
În ciuda numeroaselor avantaje pe care le prezintă, implementarea unei
soluții de integrare EAI prezintă şi unele dezavantaje, care limitează utilizarea
acesteia:
costuri de implementare semnificative, mai ales pentru IMM‐uri. Integrarea
aplicațiilor necesită resurse financiare semnificative deoarece acest serviciu este
asigurat de o firmă specializată care, prin echipa de experți, va parcurge mai multe
etape până la implementarea propriu‐zisă. Soluțiile IT sunt costisitoare, mai ales ca
urmare a faptului că aplicațiile trebuie integrate exclusiv pe specificul firmei în
cauză, aspect care ridică nivelul costurilor;
implementarea EAI necesită timp îndelungat şi multe resurse. În funcție de
specificul organizației, de activități, procese, structura organizațională, implemen‐
tarea diferă de la o organizație la alta;

dinamism. Prin natura lor, programele EAI sunt dinamice şi necesită
implicarea unor manageri spontani pentru a administra implementarea şi
dezvoltarea integrării;
numărul scăzut de experţi în acest domeniu, din cauza faptului că aceste
aplicații presupun cunoştințe vaste şi gestionarea iscusită a aspectelor tehnice;
complexitate. Numeroase proiecte de integrare a aplicațiilor la nivelul unei
firme demarează prin conectări punct‐la‐punct între programe, care devin în scurt
timp imposibil de manevrat, datorită numărului în creştere a aplicațiilor;
limite. Realizarea integrării informațiilor este o artă, iar utilizarea soluțiilor
EAI nu este întotdeauna suficientă.
Studiile din literatură arată că avantajele sunt superioare dezavantajelor şi,
deşi există eşecuri ale integrării aplicațiilor de întreprindere, când situația o cere,
este bine să se aloce un buget corespunzător pentru ca rezultatul să fie de partea
beneficiarului.

7.2.6. Tehnici şi modele de implementare a EAI

Pe măsură ce tehnologia depozitelor de date s‐a maturizat, EAI a venit în
completarea acesteia, oferind o soluție viabilă pentru integrarea datelor la nivel de
întreprindere10. În majoritatea cazurilor, funcționarea unui sistem de întreprindere
este îmbunătățită semnificativ atunci când primeşte răspuns prompt de la alte
sisteme, la formularea unor solicitări de date. De exemplu, un sistem destinat
gestionării inventarului ar putea fi mult mai receptiv dacă ar avea acces instant la
datele furnizate de punctele de vânzare (POS), astfel încât să poată monitoriza
mişcarea în timp real a produselor. O bancă comercială ar putea autoriza un
împrumut unui client în timp ce acesta poartă o discuție cu un ofițer de credite. În
acel timp, sistemul ar putea efectua o analiză în timp real pentru a verifica volumul
şi calitatea relațiilor de afaceri desfăşurate de client cu banca, tipul său de conduită
pe linia creditării, precum şi evaluarea activelor furnizate. O astfel de capabilitate
impune îmbunătățirea performanțelor diferitelor sisteme de întreprindere vechi,
deținute de aceasta, printr‐o serie de măsuri precum: suplimentări hardware,
achiziția de sisteme de operare, baze de date, astfel încât acestea să interacționeze
între ele şi să schimbe informații în timp real.

7.2.6.1. Tehnici de implementare a EAI

Ideea principală a EAI este ca sistemele să interacționeze fără a necesita
schimbări nici asupra aplicațiilor, nici asupra structurii datelor. Concret, la apariția
unui eveniment din cadrul unei aplicații, acesta este trimis prin intermediul unui
mecanism de tipul publish/subscribe (publicare/abonare) către alte aplicații sau
sisteme ce ar putea fi interesate de acel eveniment. În aceeaşi manieră, un sistem
poate solicita date din cadrul altuia, în timp real, printr‐un mecanism de

10 http://www.gravic.com/shadowbase/uses/enterpriseapplicationintegration.html
cerere/răspuns. Există cel puțin trei tehnici pentru punerea în aplicare a EAI11:
adaptori, middleware orientat pe mesaje (MOM) şi replicarea datelor. Toate
tehnicile menționate mai sus permit transformarea datelor într‐un format comun
care urmează să fie utilizat de toate sistemele din întreprindere.
Adaptorii sunt interfeţe specializate între diferite aplicaţii care facilitează
comunicarea directă. Serviciile oferite de adaptori trebuie definite prin intermediul
unui format unitar, destinat schimbului de date, la care se vor conforma toate
sistemele în scopul comunicării (vezi figura 7.1). Ca urmare, utilizarea adaptorilor
este o metodă invazivă pentru aplicații. Fiecare aplicație implicată în comunicarea
cu o alta trebuie să fie modificată în sensul utilizării unui format unitar al datelor
pentru trimiterea şi receptarea mesajelor.

Sursa: Adaptare după: w
www.gravic.com/shadowbase/uses/enterpriseapplicationintegration.html
Figura 7.1. Implementare EAI cu adaptori

Această tehnică este îngreunată de faptul că există formate proprietare în
cadrul aplicațiilor, iar furnizorii acestora ar putea refuza colaborarea. Prin urmare,
serviciile adaptori sunt cel mai adesea implementate de furnizorii aplicațiilor
întreprinderii sau în strânsă colaborare cu aceştia. Mai mult, fiecare aplicație trebuie
să fie modificată astfel încât să poată selecta evenimentele care merită a fi transmise,
procesa evenimentele recepționate de la aplicațiile accesate de la distanță (remote)
şi răspunde la solicitările venite de la aceste aplicații. Această tehnică este extrem de
specializată şi fiecare aplicație reclamă propriul adaptor care se conectează la
adaptorul rețelei de calculatoare şi care translatează interfața aplicației şi formatul
datelor în formate comune, recunoscute de adaptorul rețelei. De aceea, sunt puține
aplicațiile care pot participa la o rețea EAI interconectată prin intermediul
adaptorilor.
Middlewareul orientat pe mesaje (MOM) furnizează un mecanism pentru
trimiterea asincronă de mesaje între aplicații. Mesajele sunt lăsate în aşteptare şi apoi
sunt transmise către destinație când aceasta devine disponibilă (vezi figura 7.2). MOM

11 http://www.gravic.com/shadowbase/uses/enterpriseapplicationintegration.html

este utilizată pentru a plasa în aşteptare mesajele care descriu evenimente din sistem
şi a le trimite spre aplicații accesate de la distanță, care acționează pe baza
evenimentelor.

Sursa: Adaptare după: www.gravic.com/shadowbase/uses/enterpriseapplicationintegration.html
Figura 7.2. Implementare EAI cu MOM

Utilizarea acestei tehnici comportă multe dintre problemele cu care se
confruntă adaptorii. La fel ca aceştia, MOM este şi ea considerată invazivă pentru
aplicațiile întreprinderii. Similar cazului adaptorilor, MOM solicită ca formatul de
bază al datelor să fie implementat între toate sistemele, astfel încât acestea să poată
percepe şi facilita comunicațiile din cadrul lor. Aplicațiile trebuie să fie modificate
pentru a se conforma formatului datelor atunci când încearcă să comunice cu alte
aplicații. Suplimentar, aplicațiile trebuie modificate pentru a şti când să transmită
mesaje şi cum să răspundă mesajelor primite de la alte aplicații. În consecință, MOM
deține o utilizare marginală în cadrul integrării aplicațiilor de întreprindere.
Motoarele de replicare a datelor facilitează schimbul datelor între sisteme
la nivelul bazei de date. Datele pot lua forma evenimentelor generate de un sistem în
vederea consumului de către alte sisteme sau pot prelua cereri de la un sistem către
alte sisteme, precum şi răspunsurile la aceste cereri. Trebuie precizat faptul că
această tehnică nu se adresează integrării datelor la nivelul aplicației, ci la nivelul
bazei de date. Replicarea intervine fără nicio modificare a aplicației, iar aceasta nici
nu este conştientă de faptul că operația are loc. Singurele modificări aduse aplicației
sunt cele impuse de implementarea unor eventuale funcțiuni noi, care țin seama de
informațiile preluate din cadrul unor sisteme externe.
Motorul de replicare monitorizează modificările aduse bazei de date dintr‐un
sistem. Acesta este coordonat de un jurnal de modificări sau de către declanşatoare ale
bazei de date. Pe baza normelor incluse în motorul de replicare, anumite modificări
ale bazei de date identificate în jurnalul schimbărilor sunt trimise către alte sisteme
din rețeaua aplicației (vezi figura 7.3). Alternativ, declanşatoarele din baza de date
furnizează modificări critice motorului de replicare în scopul transmiterii lor către alte
sisteme. Aceste modificări sunt plasate în tabelele sistemelor vizate şi sunt utilizate de
noile aplicații ale întreprinderii, care pun în aplicare noi funcționalități. Din cele
expuse, reiese că această tehnică nu prezintă dezavantajul invazivității, deținut de
primele două tehnici, dimpotrivă. În al doilea rând, această tehnică nu este afectată de
disfuncționalitățile rețelei sau ale unui alt sistem. Sincopele de comunicare la nivelul
rețelei nu produc tulburări ale procesului de replicare a datelor, întrucât se poate
utiliza o versiune locală a bazei de date.

Figura 7.3. Implementare EAI prin replicarea datelor

Replicarea datelor mai aduce şi alte avantaje:
exploatarea locală a bazei de date. Aplicația nu va mai căuta datele în toată
rețeaua de calculatoare şi îşi va îmbunătăți dramatic performanțele;
simplificarea semnificativă a securității. Tehnicile adaptorilor şi MOM
impun securizarea interfeței aplicației prin intermediul criptării. Motoarele de
replicare a datelor prezintă o singură interfață care trebuie securizată. Manage‐
mentul securității este simplificat, fiind redus şi numărul locațiilor expuse atacurilor.
În concluzie, deoarece replicarea datelor evită problemele specifice asocierii
aplicațiilor cu adaptoare şi MOM, acest mecanism a devenit o tehnică frecvent aleasă
în scopul integrării aplicațiilor de întreprindere.

7.2.6.2. Modele de reţele EAI

O rețea EAI poate fi implementată sub două forme: rețea de tip plasă sau hub.
Într‐o reţea de tip plasă, fiecare sistem este potențial conectat la orice alt sistem al
rețelei. În rețeaua de tip hub, toate sistemele comunică prin intermediul unui hub
central care facilitează transferul datelor către sistemele țintă (vezi figura 7.4).
O problemă frecventă în rețeaua de tip plasă este legată de numărul de
conexiuni posibile. Astfel, dacă există n sisteme în rețeaua EAI, poate exista un
număr potențial de n(n‐1)/2 conexiuni, dacă toate sistemele trebuie să comunice cu
toate celelalte sisteme. În cazul în care un sistem nou este adăugat la rețea, poate fi

necesară implementarea de n conexiuni noi, câte una pentru fiecare dintre sistemele
existente. Numărul conexiunilor adaugă un grad ridicat de complexitate a rețelei,
care devine aproape imposibil de gestionat în contextul dezvoltării acesteia.

Figura 7.4. Modelul reţelei EAI de tip plasă

Reţeaua de tip hub elimină problemele cu care se confruntă rețeaua de tip
plasă. Astfel, fiecare sistem este conectat doar la hub, şi nu între ele (vezi figura 7.5).
Hub‐ul primeşte mesaje de la fiecare sistem şi le direcționează către sistemele‐țintă.
Totuşi, nici această rețea nu este lipsită de probleme. Astfel, inconvenientul utilizării
hub‐ului este legat de faptul că un eşec de comunicare poate perturba schimbul de
mesaje din întreaga rețea. Astfel, toate beneficiile aduse de EAI pot fi eliminate în
timpul unei opriri temporare a funcționalității hub‐ului.
O altă diferență între cele două tipuri de rețele este faptul că într‐o rețea de tip
plasă fiecare sistem trebuie să cunoască formatul de date al celorlalte sisteme din
rețea. Aşadar, fiecare sistem trebuie să fie în măsură să‐şi transforme formatul
propriu de date în formatele celorlalte sisteme. În a doua formă de implementare a
unei rețele EAI, hub‐ul preia responsabilitatea transformării datelor. Ca urmare,
sistemele trebuie să cunoască doar formatul de date impus de hub.
Aceste modele sunt considerate de literatura de specialitate ca fiind modele
tradiționale de implementare a EAI. Unii autori prezintă modelul hub sub denumirea
de model agent cu avantajele şi dezantajele prezentate anterior. Acest model s‐a
dovedit a fi unul dificil de implementat, întrucât vizează integrarea unor produse
proprietare şi include subseturi tehnologice specifice diverşilor furnizori de
aplicații. Ca urmare, aceste dezavantaje pot prezenta probleme într‐un scenariu de
integrare care implică aplicații produse de mai mulți furnizori, sisteme dezvoltate
intern (inhouse) sau produse mai vechi, care nu mai dețin suport tehnic din partea
producătorilor.


Figura 7.5. Modelul reţelei EAI de tip hub

Practica arată că modelul agent folosit în implementarea EAI a fost utilizat cu
succes de unele companii, însă marea majoritate a proiectelor au eşuat. Lipsa unor
standarde clare cu privire la arhitectura EAI, coroborată cu faptul că aplicațiile vechi
erau proprietare, au generat produse EAI extrem de scumpe, dificil de implementat
şi care uneori nu au funcționat aşa cum s‐a dorit. Excepție au făcut doar sistemele
omogene.
În aceste condiții, s‐au creat premisele dezvoltării unui nou model de
implementare: Enterprise Service Bus (ESB). Arhitectura cu magistrală (bus) a fost
creată pentru a micşora povara funcționalității plasate pe o singură componentă
(agentul/hub‐ul) din modelele precedente, prin distribuirea unor sarcini de
integrare în mai multe zone ale rețelei. Componentele responsabile de sarcinile
integratoare pot fi apoi grupate în diverse configurații, prin intermediul fişierelor de
configurare, gestionând eficient orice scenariu de integrare. Componentele
magistralei ar putea fi găzduite oriunde în cadrul infrastructurii sistemului sau ar
putea fi multiplicate în vederea asigurării scalabilității, pentru cazul unui sistem
extins pe regiuni geografice mari.
Pe măsură ce arhitectura de tip magistrală EAI a evoluat, un număr de alte
funcții necesare au fost identificate, respectiv: procesarea tranzacțiilor de securitate,
tratarea erorilor şi altele. Aceste caracteristici nu impun codificări suplimentare ale
logicii centrale destinate integrării12, ci sunt incluse în funcții care sunt înglobate în
componente separate.

7.2.7. Costurile EAI

Costurile aferente implementării unei infrastructuri EAI pot fi împărțite în trei
categorii:
arhitectura. Acestei categorii îi revin aproximativ 80% din costul alocat
implementării. Dată fiind ponderea semnificativă, costurile de arhitectură sunt
considerate costuri esențiale şi sunt corelate cu cheltuielile inițiale de dezvoltare, de

12 Joined up Thinking – Integrating Information Across the Enterprise, White Paper, Sage, 2007.

execuție şi cele aferente altor operațiuni. Sunt incluse aici şi costurile platformelor
de operare/servere necesare pentru rularea în condiții optime a infrastructurii (plus
eventuale costuri de modernizare a echipamentelor IT existente); costuri de
instalare a echipamentelor hardware şi componentelor software (instalare,
monitorizare, ajustare etc.). Costul arhitecturii este proporțional cu complexitatea
cerințelor de integrare şi este ridicat dacă se optează pentru o soluție EAI
personalizată. Deşi costul arhitecturii prezintă ponderea cea mai mare în bugetul
proiectului, trebuie menționat că el reprezintă de fapt o investiție de capital care
poate reduce costul mediu al proiectelor de integrare pe termen lung;
dezvoltarea softului. Aici se includ costurile aferente dezvoltării aplicațiilor
de integrare. Sunt luate în calcul şi cheltuielile legate de pregătirea utilizatorilor
aplicației. Motorul principal al costurilor de dezvoltare este dat de numărul
interfețelor necesare integrării. Aceste costuri pot fi capitalizate şi asociate cu
cererea de adaptoare specifice integrării. În vederea minimizării costurilor asociate
dezvoltării softului, este indicată folosirea unui set de adaptoare comune. O mare
parte din costurile de integrare vin din necesitatea firească de a construi diferite
tipuri de mesaje care facilitează comunicarea dintre aplicații;
operaţiuni. Costul operațiunilor reflectă cheltuielile cauzate de lucrările de
întreținere şi de suport ale platformelor de integrare. Costurile de operare sunt
cheltuieli în curs care includ operarea şi întreținerea platformei EAI.

7.3. Factori de risc în implementarea EAI şi capcanele EAI

În anii ’90, mulți dintre directorii de companii au achiziționat diverse
programe informatice destinate gestiunii resurselor şi operațiunilor firmelor lor,
rezolvându‐şi problemele pentru acel moment. Deşi acestea funcționau individual,
aplicațiile insulare nu comunicau între ele sau, dacă acest lucru se întâmpla, era
numai datorită unor intervenții suplimentare. În majoritatea cazurilor, comunicarea
dintre sisteme oferea informații inconsistente şi irelevante. Astfel, apariția EAI a
constituit colacul de salvare pentru multe organizații.
Prima soluție de integrare s‐a implementat prin integrarea PointtoPoint, care
nu permitea conectarea a mai mult de două aplicații şi, în plus, dacă o aplicație era
modificată, acest lucru genera inconveniențe. Soluțiile actuale – Middlewarebased
integration – oferă, pe lângă facilitatea de schimbare a aplicațiilor, servicii de
mentenanță a sistemului.
Achiziționarea unei soluții EAI presupune costuri destul de mari pentru o
organizație, de aceea este necesar să se cunoască riscurile pe care le poartă o
asemenea investiție. Majoritatea furnizorilor de soluții consideră că riscurile vin din
partea clienților, şi nu din partea lor.
La nivelul țării noastre, dacă s‐ar ține cont de aspectele menționate în
literatura de specialitate, lucrurile s‐ar îmbunătăți vizibil. Fiecare întreprinzător
privat ar trebui să se documenteze foarte bine înainte să achiziționeze o aplicație
nouă, care trebuie integrată în sistemul informatic existent. La fel ca la selecția
furnizorului de aplicații economice, trebuie prospectată şi piața de EAI, pentru a afla
care este reputația furnizorilor, ce implementări şi ce clienți au, solicitând oferte şi
discutând eventual cu fiecare în parte despre soluțiile pe care le oferă. De asemenea,
nu trebuie scăpat din vedere faptul că o aplicație prea sofisticată ar necesita costuri
mai ridicate cu educarea personalului decât una mai uşor de utilizat, dar la fel de
eficientă şi suficient testată. În urma achiziției pachetului EAI, un manager informat
ar şti cât de importante sunt instruirea angajaților şi comunicarea dintre membrii
echipei care vor utiliza aplicația, şi ar acționa în consecință.
Specialiştii recomandă ca înainte de achiziționarea unei soluții EAI, să se
definească exact cerințele, nevoile şi intențiile: ce trebuie integrat, de ce trebuie
integrate aplicațiile, care sunt intențiile viitoare şi care este cea mai bună abordare.
Nu trebuie uitat nici faptul că integrarea poate fi una internă (procese economice
intraorganizaționale) sau externă (unde intervin serviciile de la mai mulți furnizori).
Este foarte important ca abordarea integrării să fie una realistă.
Bernie Hopkins, analist la Sopra Group13 (firmă de consultanță britanică)
opinează că realizarea unui proiect EAI trebuie să aibă următoarele premise:
abordarea pragmatică a proiectelor;
solicitarea îndrumărilor şi consultanței profesionale;
definirea clară a cerințelor;
dezvoltarea unei strategii de îndrumare;
adoptarea unei abordări iterative;
demararea proiectului imediat ce apare nevoia.
Capcanele EAI sunt de fapt eşecurile generate de probleme specifice
managementului organizației. Prezentăm în continuare cele mai relevante dintre
acestea, cu scopul de a preîntâmpina apariția lor:
numărul redus de specialişti din domeniul EAI – reprezintă o problemă
majoră care nu trebuie neglijată, având în vedere faptul că tehnologia evoluează pe
zi ce trece, iar pentru a realiza nevoile nou‐apărute trebuie să existe specialişti în
rezolvarea acestor probleme, mai bine zis, cât mai mulți specialişti;
tehnologia în continuă schimbare – determină firmele să‐şi schimbe
frecvent componentele sistemului, să le actualizeze, ceea ce antrenează organizația
atât din punct de vedere al timpului, cât şi al resurselor de natură financiară;
specialiştii IT – nu pot determina corect doleanțele clienților şi, din această
rațiune, nu pot satisface toate cerințele acestora;
alegerea inadecvată a tehnologiei, alta decât cea potrivită pentru activitatea
de bază a întreprinderii (acest lucru este consecința unei insuficiente informări cu
privire la tipul tehnologiei necesare integrării aplicațiilor din organizație, poate din
cauza unor informații eronate cu privire la tehnologia pe care aceasta urmează să o
achiziționeze);
lipsa înţelegerii aspectelor legate de procesele economice – acest lucru este
cauzat de faptul că nu toți specialiştii în IT dețin cunoştințe din domeniul economic.
Pentru a rezolva această situație, se recomandă colaborarea specialiştilor IT cu
economiştii din organizație, pentru a se obține un produs final cât mai bun şi fiabil;
standarde neacceptate unanim – furnizorii EAI vor analiza şi alege metoda
cea mai potrivită.

13 www.sopragroup.com/

Deşi există numeroase capcane legate de integrarea EAI, poate mai multe
decât cele surprinse aici, acestea nu depăşesc nicidecum beneficiile aduse prin
integrare.

7.4. Oferta de soluţii EAI

Estimările pentru anul 201314 apreciază valoarea pieței EAI la valoarea de
11,5 miliarde de dolari. Din punct de vedere regional, după SUA, Europa constituie a
doua zonă de creştere EAI. Soluțiile EAI sunt formate din mai multe produse, fiecare
adresându‐se unui anumit sector sau unui anumit tip de probleme de integrare. EAI
reprezintă o investiție strategică pe termen lung, întrucât beneficiile sale apar în
timp. Sistemele întreprinderii vor beneficia de pe urma reducerii costurilor de
actualizare a aplicațiilor, fiind eliminate costurile conectării punct‐la‐punct dintre
programe. Totodată, este maximizată eficiența organizațională şi tehnologică şi
creşte valoarea mediului IT. Printre cele mai populare şi frecvent utilizate
tehnologii‐suport pentru integrare se numără:
COM, DCOM de la Microsoft;
Microsoft Host Integration Server;
Microsoft SQL Server™;
Windows core services, care includ:
– XML Web services;
– Microsoft Data Access Components (MDAC);
– COM+ application services;
integrarea prin tehnologia bazelor de date;
tehnologia Java;
sisteme middleware orientate pe mesaje/notificări;
instrumente de automatizare a fluxurilor şi proceselor.
Aşa cum s‐a precizat, soluțiile EAI sunt pachete formate din mai multe produse.
Fiecare soluție EAI se adresează unui anumit tip de problemă de integrare. Astfel,
există soluții EAI middleware, integrare de procese, adaptoare EAI, mesagerie/rutare
EAI. În acest context, putem realiza o segmentare a pieţei EAI astfel:
furnizori de platforme de integrare: IBM, Microsoft, Oracle, Tibco Software;
furnizori de mesagerie/rutare EAI: Mercator, NEON;
integratori A2A: Vitria, webMethods;
integratori B2B: Extricity, webMethods, Cyclone.
Vom prezenta în continuare succint particularitățile ofertelor EAI, pornind de
la exemplul de integrare descris în continuare şi încheind cu un alt exemplu de
integrare.

14 ***, Enterprise Application Integration (EAI) Market Opportunities, Strategies, and Forecasts, 2007 to
2013, http://www.reportlinker.com/p0153974‐summary/Enterprise‐Application‐Integration‐EAI‐Market‐
Opportunities‐Strategies‐and‐Forecasts‐to.html
Utilizarea platformei webMethods în domeniul medical
Integrator: Softima
Client: Parkway Group Health – este una dintre cele mai reprezentative organizaţii medicale
din lume. Aceasta deţine o reţea de spitale în toată lumea, dar cu precăderea în Asia. Din
punct de vedere IT, organizaţia se mândreşte cu nivelul investiţiilor efectuate în tehnologiile
de ultimă oră, inclusiv ERP, utilizate în activitatea sa.
Context: Clientul deţine trei mari spitale în Singapore şi, pentru fiecare dintre acestea, rulează
aplicaţii diferite pentru informatizarea activităţii din cadrul departamentelor. Organizaţia
a dezvoltat inhouse o parte din aplicaţii, iar restul au fost achiziţionate de la diferiţi
dezvoltatori. Una dintre aplicaţii a fost creată pentru a transmite date din cadrul sistemelor
către aplicaţia SAP (modulul Health Care), care este utilizat ca sistem central de toate
departamentele organizaţiei.
Scopul15 integrării a constat în înlocuirea motorului de interfaţare prin platforma de integrare
webMethods întrun cadru unitar integrator (1) şi reproiectarea motorului de interfaţare
prin aplicarea standardelor HL7 specifice sistemului de sănătate (2).
Soluţia a venit de la Softima, un experimentat integrator şi dezvoltator de soluţii informatice
integrate. Cei de la webMethods au ales Softima ca integrator de sisteme şi au colaborat în
cadrul primei faze a proiectului, urmând ca a doua fază să fie derulată exclusiv de Softima.
Prima fază a inclus integrarea aplicaţiilor care informatizează activitatea laboratoarelor
(aplicaţia Cerner) şi a radiologiei (aplicaţia IRIS) cu modulul de sănătate de la SAP.
Formatul datelor în vederea comunicării a fost HCM (pentru SAP) şi HCL7 (pentru IRIS şi
Cerner). În urma recepţiei datelor din sistem, webMethods parsează, validează, jurnalizează
şi livrează mesajele către destinatari. Protocoalele utilizate au fost TCP/IP şi SAP RFC.
A doua fază a proiectului a implicat integrarea farmaciei (aplicaţia Merlin) cu modulul SAP,
destinat gestiunii activităţilor specifice sistemului de sănătate prin intermediul webMethods
ca motor de interfaţare. Formatul datelor este HCM (SAP), HL7 şi mesagerie personalizată
(Merlin). Protocoalele utilizate au fost TCP/IP, SAP RFC şi SAP BAPI.

În ceea ce priveşte implementarea, în figura16 de mai sus se poate observa, întro manieră
comparativă, arhitectura sistemului ante (stânga) şi postintegrare (dreapta). Se observă

15 http://softima.com/pdf/SAP_EAI_Implementation1.pdf
16 Prelucrare după http://softima.com/pdf/SAP_EAI_Implementation1.pdf

că platforma de integrare webMethods implementată de Softima soluţionează cu succes
problema comunicării celor trei aplicaţii specializate (Cerner, IRIS şi Merlin) cu modulul de
management al activităţilor de sănătate din aplicaţia SAP.

IBM propune ca bază a soluțiilor de integrare pentru întreprindere platforma
Websphere, cu ajutorul căreia procesele de afaceri pot fi simulate, optimizate şi
modelate vizual17. Infrastructura oferită de această platformă asigură atât
modelarea proceselor economice existente, precum şi dezvoltarea şi implementarea
unor procese noi. Asigură, de asemenea, o viziune completă asupra legăturilor dintre
resursa umană, aplicații şi date. Websphere asigură monitorizarea proceselor în
vederea îmbunătățirii controlului, creşterii eficienței deciziilor şi maximizează
performanța organizației beneficiare. Fluxurile informaționale dintre parteneri sunt
gestionate eficient, deoarece această platformă asigură acoperirea şi dincolo de
granițele companiei.
Platforma Websphere permite dezvoltarea portalurilor B2B, B2C sau B2E.
Dezvoltarea paginilor se realizează prin intermediul portlet‐urilor, componente
vizuale care facilitează prezentarea informației. Portalurile astfel construite şi
instalate beneficiază de tehnologii de securitate, adaptate la un volum sporit de
tranzacții. Protejarea conectării clienților, furnizorilor sau angajatorilor este
intermediată de serviciile de autentificare şi control al accesului.
Tibco Software este un alt furnizor important de pe piața aplicațiilor de
integrare, care, prin soluțiile oferite, asigură o platformă destinată partajării
informațiilor şi a proceselor din întreaga companie, facilitează comunicarea între
diverse sisteme şi coordonarea proceselor economice. Tibco propune familia de
produse Active Enterprise, care asigură infrastructura e‐business care permite
companiilor automatizarea proceselor economice. O altă soluție propusă de Tibco
este TIBCO Adapter, care permite bazelor de date şi pachetelor de aplicații să devină
participanți activi la fluxul de informații al companiei. Prin abordarea configurării
bazate pe integrare, Tibco Adapter certifică automat cartografierea tehnologiilor
incompatibile şi a formatului datelor. Oferă o gamă largă de adaptoare pentru baze
de date şi pachete de aplicații.
SeeBeyond a fost un alt nume important pe piața EAI a anilor 2000, până în
2005, când compania a fost cumpărată de Sun Microsystems. Produsul lor stindard
(Integrated Composite Application Network Suite) a fost redenumit Sun Java
Composite Application Platform Suite (Java CAPS). Mai apoi, în 2010, Oracle a preluat
Sun Microsystems şi o nouă versiune de Java CAPS, cu amprenta Oracle, lansată în
201118.
Soluțiile descrise mai sus au scopul de a creşte performanțele companiilor
prin integrarea tuturor aplicațiilor din cadrul companiei. În această manieră se
asigură partajarea informațiilor şi automatizarea proceselor economice din întreaga
organizație. Utilizând soluțiile EAI, o organizație poate gestiona mai bine fluxurile de
informații interne şi cu partenerii de afaceri.

17 L. Gavin ş.a., An EAI Solution using WebSphere Business Integration (V4.1), International Business
Machines Corporation, 2003.
18 http://www.oracle.com/us/technologies/java/overview/index.html
Soluţia Oracle AIA în domeniul telecomunicaţiilor mobile
Client: Vodafone Albania, companie a grupului Vodafone, este lider pe piaţa telecomunicaţiilor
mobile din Albania având o acoperire de 99% prin reţeaua 3G. Are 1,8 milioane de clienţi,
acoperă o mare varietate de servicii de voce şi comunicaţii de înaltă calitate, asigurânduşi
clienţii de folosirea celor mai actuale reţele de telecomunicaţie şi oferindule acces la
ultimele noutăţi din domeniu.
Context: Vodafone Albania a depus o solicitare către Cognity privind implementarea sistemului
CRM de la Siebel şi a arhitecturii de integrare a aplicaţiilor – AIA de la Oracle – cu scopul de
a informatiza vânzările, procesele de marketing şi service ale companiei, plasarea clientului
în centrul preocupărilor companiei şi sprijinirea strategiilor CRM ale organizaţiei.
Implementarea acoperă vânzările directe, serviciulsuport pentru clienţi, managementul
comenzilor, portalul pentru parteneri, serviciul de portabilitate a numerelor de telefonie
mobilă şi Analytics.
Rezultat: Cognity a reuşit implementarea la compania Vodafone Albania a aplicaţiei Siebel
Comunication CRM şi a unui proces complex de integrare bazat pe Oracle Application
Integration Architecture. Astfel, proiectul a informatizat:
centrul de relaţii cu clienţii, inclusiv integrarea cu Genesys CTI şi IVR;
automatizarea proceselor de vânzare şi vânzarea directă;
managementul comenzilor, inclusiv modelarea şi configurarea produselor;
Oracle AIA, inclusiv agentul de asistare a facturării pachetul de integrarea a proceselor
de comandă şi facturare;
Analytics pe baza Oracle Business Intelligence (OBIEE) şi a altor aplicaţii specifice
specializate.
Vodafone Albania este mulţumită19 de rezultatele implementării şi integrării realizate de Cognity.
Integratorul a utilizat în implementarea Siebel CRM şi AIA cele mai bune practici din domeniul
industriei telecomunicaţiilor, introducând personalizări minime care vor asigura funcţionarea
fără impedimente şi actulizări pentru Vodafone Albania. Acest exemplu de dezvoltare şi
integrare a servit ca model pentru alte implementări din cadrul grupului Vodafone, sistemul
livrat de Cognity demonstrând o abordare corectă a problemelor şi respectând standardele
din domeniu.

7.5. Tehnologii utilizate în aplicaţiile de întreprindere

Integrarea EAI se realizează prin aducerea laolaltă a mai multor tehnologii,
instrumente şi module, între care: programare orientată‐obiect, platforme de
comunicare, aplicații integrate de tip ERP pentru a corespunde obiectivelor privind
conținutul şi transmiterea datelor la nivel de întreprindere, utilizarea bazelor de
date standard şi a standardelor puse în aplicare prin utilizarea XML, middleware,
businesstobusiness (B2B) şi altele.
XML (Extensible Markup Language) reprezintă un set de reguli de crip‐
tare/codificare a documentelor transmise prin mijloace electronice şi îşi propune

19 http://www.cognity.gr/cs‐soa‐vfal.html

sublinierea simplității, generalității şi larga răspândire a utilizării internetului. XML

este un profil de aplicare a standardului ISO 8879:1986 SGML. Deşi proiectarea XML
se concentrează pe documente, acesta este utilizat pe scară largă în reprezentarea
structurilor de date, de exemplu, în servicii web. Există mai multe interfețe de progra‐
mare pe care dezvoltatorii de software le pot utiliza pentru a accesa date XML şi mai
multe scheme de sisteme proiectate să ajute la definirea limbajelor bazate pe XML.
Middleware este o tehnologie care a evoluat semnificativ, astfel că, în prezent,
este capabilă să susțină interoperatibilitatea şi trecerea la arhitecturi distribuite,
utilizate de cele mai multe ori pentru a sprijini şi simplifica aplicațiile complexe
distribuite. Middleware lucrează concomitent cu API (Application Programing
Interface) – software utilizat pentru a solicita şi efectua servicii de nivel inferior duse
la îndeplinire de sistemul de funcționare a computerului sau de sistemul de operare
a unui sistem de telefonie.
Un middleware EAI mediază aplicațiile în diverse moduri, cel mai adesea fiind
vorba despre transformarea şi direcționarea datelor şi organizarea fluxurilor
specifice proceselor întreprinderii. O platformă middleware constă într‐un set de
servicii care permit desfăşurarea mai multor procese concomitent. Această
tehnologie a apărut din necesitatea de a oferi sprijin în realizarea unor arhitecturi
distribuite. Sunt incluse aici serverele web, serverele de aplicații şi instrumentele
similare care permit dezvoltarea şi livrarea aplicațiilor. Middleware‐ul este folosit în
special în cadrul tehnologiilor moderne bazate pe XML, SOAP, servicii Web, SOA.
Middleware‐ul se situează în centrul aplicațiilor software şi poate funcționa în
sisteme de operare diferite. Este similar stratului mijlociu al unei arhitecturi cu trei
straturi, cu excepția faptului că acesta realizează legături cu multiple sisteme şi
aplicații, nu doar cu cele de pe stratul inferior, respectiv cel superior. Fiind un
software care face legătura între aplicații diferite, middleware‐ul mai este întâlnit
sub denumirea de „instalație”, deoarece conectează aplicațiile şi face posibilă
transmiterea datelor între acestea. Middleware permite ca datele conținute de o
bază de date să poată fi accesate prin intermediul alteia. Comerțul electronic oferă o
perspectivă nouă asupra acestui termen. Ȋn cadrul acestuia, middleware‐ul
supraveghează desfăşurarea rapidă şi în condiții de maximă siguranță a tranzacțiilor
care se realizează prin interacțiunea cu cele mai diverse medii electronice.

Prezentăm câteva repere istorice relative la evoluţia în timp a EAI şi Middleware:
este utilizat pentru prima dată în anul 1968, întrun raport NATO;
termenul de „middleware” este unul relativ nou intrat în peisajul informaticii. El a căpătat
o oarecare popularitate în anii ’80, fiind soluţia la problema conectării unor aplicaţii noi
cu sistemele moştenite. El se referea şi la modalitatea conectării mai multor aplicaţii, cu
scopul creării unei dimensiuni superioare, în principal cu ajutorul internetului;
începând cu anii ’90, aplicaţiile de tip ERP au devenit o prezenţă din ce in ce mai
pregnantă în viaţa întreprinderii, accentuând necesitatea prelevării aplicaţiilor existente
şi datelor în sistemele ERP, fapt ce a fost posibil doar prin introducerea EAI;
secolul XXI a adus după sine preocupări noi în acest domeniu, atenţia fiind concentrată
asupra managementului lanţului de aprovizionare, businesstobusiness integration,
integrarea aplicaţiilor web şi, în general, aplicaţii EAI cât mai performante;
indiferent de perioada pe care o avem în vedere, middlewareul şia demonstrat utilitatea
(fapt confirmat şi de valoarea vânzărilor înregistrate pe piaţa EAI). Studiile actuale
motivează importanţa domeniului. Un studiu 2013 PRWeb: SOA Middleware Market &
IBM Software Innovation Market Shares, Strategies, and Forecasts, Worldwide, 2013
to 2019 New Research Report, disponibil pe Researchmoz.us, confirmă că preocupările

furnizorilor de soluţii continuă, şi piaţa cere soluţii de acest gen.

Aplicaţiile businesstobusiness (B2B) reprezintă un segment al comerțului
electronic care acoperă zona de afaceri dintre întreprinderi. B2B poate avea loc între
un cumpărător şi un vânzător, între mai mulți cumpărători şi un vânzător (licitația
de vânzare pe internet), între un cumpărător şi mai mulți vânzători (licitația de
cumpărare pe internet), între mai mulți cumpărători şi mai mulți vânzători (cazul
bursei comerciale pe internet).
Businesstobusiness descrie tranzacțiile comerciale între întreprinderi, cum ar
fi între un producător şi un angrosist, sau între un angrosist şi un comerciant cu
amănuntul. S‐au dezvoltat, de asemenea şi termenii B2C (businesstoconsumer, care
vizează tranzacțiile comerciale între întreprinderi şi consumatorii finali) şi B2G
(businesstogovernment, care descriu tranzacțiile comerciale între întreprinderi şi
instituțiile statului).
Volumul operațiunilor B2B este mult mai mare decât volumul tranzacțiilor
B2C deoarece într‐un lanț de aprovizionare tipic există multe tranzacții business
tobusiness care au ca obiect componente (subansambluri) sau materii prime şi
doar o singură tranzacție businesstoconsumer, la vânzarea produsului finit
clientului final. De exemplu, un producător de autovehicule derulează multe
tranzacții B2B, cum ar fi cumpărarea de anvelope, oglinzi laterale şi componente
materiale. În schimb, vânzarea unui autoturism reprezintă tranzacția finală (o
singură tranzacție de tip B2C).
Cunoaşterea şi aplicarea metodologiilor EAI asigură întreprinderii un avantaj
competitiv, esențial în condițiile economice actuale. Apariția standardelor pentru
comunicare, conectivitate, transformare, portabilitate şi securitate în mediul
organizațional a simplificat eforturile de integrare şi a găsit rezolvări problemelor
middleware.
Enterprise Service Bus (ESB) contribuie la integrarea aplicațiilor
organizației printr‐o structură software inovatoare, realizând inventarierea
standardelor. ESB este infrastructura de întreprindere (literatura de specialitate
foloseşte şi termenul de coloană vertebrală a întreprinderii), bazată pe standarde şi
orientată pe servicii, capabilă să conecteze sute şi chiar mii de aplicații. Specialiştii
sunt de părere că ESB este rezultatul evoluției treptate a standardelor
organizaționale. ESB îşi propune alegerea celor mai potrivite standarde în vederea
integrării proceselor din interiorul unei întreprinderi, sistemelor colaborative
precum şi soluțiilor economice distribuite.

ESB este rezultatul evoluției unor standarde aparținând diverselor domenii,

cum ar fi:
standarde de comunicare. Menționăm aici Java Message Service ca principal
standard, la concurență cu IBM WebSphere MQ;
standarde de conectivitate. XML este standardul pentru serviciile web şi
este considerat limbajul afacerilor moderne;
standarde de transformare. XSLT (eXtensible Stylesheet Language
Transformation), care transformă documentele XML dintr‐o schemă în alta;
portabilitate. Limbajul Java este utilizat pentru conceperea aplicațiilor
portabile de întreprindere şi a celor middleware. Astfel de aplicații nu depind de
sistemul de exploatare inițial, folosit la proiectare. Tehnologiile moderne de tip
middleware implementează un nucleu Java în cadrul tuturor platformelor hardware
şi al sistemelor de operare, inclusiv Windows, mainfraime‐uri şi sisteme medii;
securitate. Lightweight Directory Access Protocol este un instrument unic
utilizat în identificarea informațiilor precum numele utilizatorilor, adresele de e‐mail
etc. dintr‐o bază de date, în condiții de maximă siguranță. Secure Sockets Layer este un
protocol deschis care se află situat între protocolul de aplicație şi cel de conectare,
care se ocupă de securizarea comunicațiilor de date în rețea. SSL asigură
autentificarea serverului, integritatea mesajelor, criptarea datelor şi autentificarea
clientului.
ESB are la bază topologia de tip rețea, distribuind procesele prin aşa‐numitele
containere de servicii. Fiecare container poate conține unul sau mai multe servicii,
identificabile oriunde în cadrul magistralei ESB. Pentru definirea ordinii de
parcurgere (sub formă de hartă) a serviciilor şi proceselor pe care o cerere trebuie
să le parcurgă pentru a finaliza un anumit proces, ESB pune la dispoziția
utilizatorilor un instrument de rutare inteligent, care poartă denumirea de
itinerariu.
Printre avantajele utilizării ESB menționăm:
conectivitatea extinsă. ESB oferă conectivitate sistemelor, făcând posibile
atât comunicarea sincronă, cât şi cea asincronă. Sunt încorporate standarde pentru
mesageria electronică, schimbul de date realizându‐se în principal online;
flexibilitate în dezvoltarea aplicaţiilor, într‐o arhitectură bazată pe servicii.
Prin asamblarea mai multor servicii cu ajutorul SOA se obțin multiple sisteme
complexe;
reducerea costului total al proprietăţii prin reutilizarea serviciilor;
optimizarea intervalului de timp pentru apariţia pe piaţă şi creşterea
productivităţii prin faptul că serviciile şi componentele pot fi reutilizate, iar
aplicațiile pot fi dezvoltate cu uşurință.
Considerăm oportună evaluarea arhitecturii ESB şi hub/magistrală, într‐o
manieră comparativă, pentru a evidenția punctele tari şi cele slabe (tabelul 7.3).

Tabelul 7.3
Evaluarea comparativă a celor două arhitecturi EAI

Parametru Arhitectura bus/magistrală
Arhitectura hub
evaluat Soluţii proprietare ESB
Instalare Efort redus în Efort moderat Efort moderat
comparație cu
arhitectura bus
Administrare Uşor de Administrarea poate Administrarea poate fi
administrat fi complexă, lucru complexă, lucru care
datorită hub‐ului care depinde de depinde de sistemele care
central sistemele care sunt sunt integrate
integrate
Cost Ridicat Ridicat Scăzut (nu utilizează
formate proprietare, nu
impune servicii)
Scalabilitate Ridicată când Foarte ridicată Foarte ridicată
arhitectura este
respectată
Standarde Standarde de bază Standarde de bază Standarde de bază
sau formate sau formate
proprietare proprietare interne
interne aplicației aplicației
SOA Susține Susține Susține implementarea
implementarea implementarea orientată pe servicii
orientată pe orientată pe servicii
servicii

7.6. SOA – arhitectura bazată pe servicii

Arhitectura sistemelor informatice a cunoscut o evoluție spectaculoasă, al cărei
început s‐a prefigurat în jurul anilor ’70, odată cu prelucrarea pe loturi. Viitorul, aşa
cum reiese şi din figura 7.6, este marcat de arhitectura bazată pe servicii – SOA
(Service Oriented Arhitecture).
Există multe definiții20 pentru acest concept, însă reținem că arhitectura
bazată pe servicii reprezintă modalitatea de proiectare, dezvoltare şi administrare a
infrastructurii programelor informatice, în cadrul căreia aplicaţiile sunt organizate în
unităţi economice de lucru care sunt accesibile prin intermediul reţelei de
calculatoare, iar serviciile au o interfaţă de nivel înalt, care primeşte, în cadrul etapei
de proiectare, aceeaşi atenţie ca bazele de date şi aplicaţiile. În cadrul acestei
arhitecturi, caracteristicile serviciilor calitative (securitate, tranzacții, performanță,
stil de interacțiune a serviciului) sunt identificate în mod explicit, infrastructura
software devine activ responsabilă de administrarea accesului şi execuției
serviciilor, serviciile şi metadatele sunt catalogate în cadrul unui depozit şi sunt

20 R. Heffner, L. Fulton, Forrester Research, Topic Overview: ServiceOriented Architecture, 2005.

puse în valoare prin intermediul instrumentelor de dezvoltare şi administrare.
Protocoalele şi structurile din cadrul arhitecturii sunt predominante, dar nu exclusiv
fundamentate pe standardele specifice domeniului.

Figura 7.6. Evoluţia arhitecturii sistemelor informatice

Aşadar, SOA nu reprezintă doar un set de standarde de servicii web destinate
integrării mai facile a aplicațiilor, ci devine un element‐cheie care stă la baza
transformărilor strategice ale întreprinderii21. În acest sens, serviciile care au la bază
SOA permit implementarea modulară, într‐un format digital al aspectelor economice
ale întreprinderii, permițând conectarea cu orice client, furnizor, angajat, sau alt
partener de afaceri în orice moment şi în orice loc 22. Abilitatea SOA de a aduce
economii la bugetul IT şi de a construi un flux flexibil al circuitului economic a
condus la un grad ridicat de adoptare.
Specialiştii23 anticipează că piața SOA va atinge 15,1 miliarde de dolari în
2019. Valoarea este calculată pe baza ritmului de creştere 2010‐2012: în 2010
WinterGreen Research a calculat valoarea pieței SOA la patru miliarde de dolari, iar
în 2012, la 7,1 miliarde de dolari.
Arhitectura bazată pe servicii poate fi utilizată într‐un set de scenarii
economice extrem de variate şi considerăm că orice întreprindere trebuie să
investigheze acest subiect pentru a vedea unde şi cum poate beneficia de pe urma
implementării acestui concept. Din punct de vedere economic şi tehnologic,
literatura de specialitate precizează un set de obiective pe care arhitectura SOA îşi
propune să le încorporeze (tabelul 7.4).

21 V.D. Păvăloaia, Integrarea tehnologiilor informaţionale în analiza financiară, Editura Universității
„Alexandru Ioan Cuza”, Iaşi, 2008, p. 135.
22 D. Fotache, L. Hurbean, op. cit.
23
***, Services Oriented Architecture (SOA) Middleware Market Shares, Strategies, and Forecasts,
Worldwide, 2013 to 2019, http://wintergreenresearch.com/reports/SOA%20 Engines.html
Tabelul 7.4
Obiectivele economice şi tehnologice ale arhitecturii SOA

Obiective economice Obiective tehnologice
Adaptarea sistemului la procese şi nu invers Reducerea personalizărilor prin
configurarea corectă a cerințelor
sistemului
Îmbunătățirea rulării aplicațiilor Adoptarea standardelor pentru reducerea
costurilor de integrare
Furnizarea de analitice relevante Îmbunătățirea interfețelor pentru
utilizatorii finali
Conexiuni la date şi servicii externe Flexibilitate maximă pentru bestofbreed
şi aplicații compozite
Îmbunătățirea celor mai bune practici şi
obținerea celor mai relevante cunoştințe
Sursa: Wang, R., Teleconference Eleven Entry Points To SOA: „How to Prepare for Upcoming Enterprise
Application Trends and a World Of SOA”, Forrester Research, aprilie 2006, p. 15.

Arhitectura orientată spre servicii are o serie de caracteristici definitorii care
pot fi considerate ca avantaje oferite întreprinderilor:
independenţa faţă de platformele aplicaţiilor: SOA limitează dependența de
platformă a aplicațiilor prin utilizarea XML, ceea ce reduce complexitatea integrării
şi procesele de actualizare;
reutilizarea aplicaţiilor: logica programelor este divizată în unități de
servicii mai mici, care pot fi mai apoi reutilizate când este cazul. Un bun exemplu ar
fi cazul unei aplicații ce redă şi raportează date dintr‐o bază de date de resurse
umane. Aceasta poate fi folosită ca serviciu şi de sistemele de management al
identității, portaluri pentru angajați sau alte programe, evitând astfel rescrierea
codului;
scalabilitatea: aplicația are capacitatea de a suporta schimbări importante
fără mari dificultăți, cu costuri modice, păstrând serviciile deja existente;
standardizarea: mesajele circulă în interiorul aplicației pe baza unor
standarde general acceptate.
Un exemplu de integrare SOA propusă de iWay este exemplificat în figura 7.7.
Modelul foloseşte adaptoare de servicii pentru a permite integrarea SOA, care
descătuşează funcționalități blocate în sisteme ERP, SCM, CRM, precum şi în aplicații
dezvoltate pe platforme J2EE (Java) şi .NET.
Având în vedere caracteristicile acestor tipuri de arhitecturi, se poate spune că
SOA furnizează o serie de servicii economice complexe şi bine definite. Astfel de
servicii țin cont de cele mai bune practici în conducerea afacerilor, respectiv business
process management. Pentru o implementare eficientă, conform principiilor SOA,
trebuie îndeplinite o serie de condiții tehnice referitoare la infrastructură cum ar fi:
existența componentelor necesare pentru dezvoltarea aplicațiilor
personalizate: servicii de date, autentificare şi audit, platforme de căutare şi
notificare;

platforme de securitate care permit autorizarea şi autentificarea

utilizatorilor;
servicii de integrare date pentru suportul SOA ;
servicii de tip portal pentru interacțiunea utilizatorilor;
servicii prezente în mod obişnuit într‐o companie precum: e‐mail, LDAP
(protocol de aplicație folosit pentru interogarea şi modificarea serviciilor de
directoare prin intermediul TCP/IP).

Sursa: http://www.iwaysoftware.com/soa‐service‐oriented‐architecture.html
Figura 7.7. Model de integrare SOA de la iWay

Nu trebuie ignorat rolul pe care îl are Enterprise Service Bus în SOA. Acesta
oferă o interfață de programare a aplicației care poate fi folosită pentru dezvoltarea
serviciilor, favorizând interacțiunea acestora într‐un mod eficient. Din punct de
vedere tehnic, ESB constituie un canal de comunicare ce realizează conversia
protocoalelor, transformarea formatului mesajelor, acceptarea şi transmiterea
mesajelor de la diferite servicii şi aplicații care sunt conectate cu aceasta.
Referitor la cele menționate anterior, în prezent există o multitudine de
tehnologii de implementare a arhitecturilor orientate pe servicii, care pot fi
grupate în: obiecte distribuite, aplicații middleware, platforme B2B, servicii web.
Vom vorbi în continuare despre fiecare dintre acestea.
obiecte distribuite: CORBA, J2EE, COM/DCOM
– CORBA este un standard care permite componentelor software bazate pe
limbaje diferite să colaboreze pe platforme multiple. Printre avantaje regăsim:
standard deschis scalabil, securitatea sporită, facilitează transmiterea sincronă a
mesajelor şi a comunicării de grup;
– J2EE (Java 2 Platform Enterprise Edition) este una dintre principalele

platforme utilizate actualmente pentru dezvoltarea soluțiilor economice cu ajutorul
serviciilor web. Platforma Java este un mediu de dezvoltare bazat pe limbajul de
programare Java divizat în două platforme, în afară de Enterprise: J2SE (Java 2
Platform Standard Edition) creată pentru aplicațiile de desktop, J2ME (Java 2
Platform Micro Edition) orientată către aplicațiile care funcționează pe dispozitive
mobile. J2EE are avantajul de a fi oferită de cei mai importanți furnizori IT şi există o
comunitate importantă de dezvoltatori;
– COM/DCOM – Component Object Model/Distributed Component Object Model
sunt tehnologii Microsoft care permit comunicarea între componentele software din
cadrul unei rețele de calculatoare. DCOM este o extensie a COM şi oferă față de cel
din urmă: serializare – procesul prin care este transformată reprezentarea unui
obiect într‐un format de date potrivit pentru depozitare şi transmitere –, garbage
collection distribuit – prin care se administrează memoria limitată a sistemului,
acesta încearcă să elimine din memorie obiectele care nu mai sunt utilizate de
program;
aplicaţii middleware: WebSphere MQ
Un bun exemplu în acest caz este WebSphere MQ, despre care am amintit şi în
cadrul furnizorilor EAI, ce reprezintă un sistem de mesagerie fiabil pentru
arhitecturile orientate pe servicii, disponibil pe mai toate platformele sistemelor de
operare şi asigură o magistrală principală de mesagerie (Universal Messaging
Backbone) pe platformele distribuite, pentru conectarea la aproape orice sistem IT
comercial;
platforme BusinesstoBusiness: ebXML, RosettaNet
– ebXML se referă la sintagma Electronic Business using eXtensible Markup
Language. Acest concept are la bază o serie de standarde a căror misiune este să
furnizeze o infrastructură bazată pe XML, care să permită utilizarea la nivel global a
informațiilor referitoare la afacerile electronice într‐un mod sigur, interoperabil şi
consecvent, de toți partenerii de afaceri. Arhitectura ebXML este orientată către
concepte şi metodologii care să permită utilizatorilor să implementeze într‐un mod
eficient soluțiile e‐bussines;
– RosettaNet aparține unui consorțiu nonprofit al cărui scop este stabilirea şi
implementarea unui standard pentru procesele de partajare a informațiilor business
între lanțurile de furnizori la nivel global. Acesta este bazat pe XML şi favorizează
colaborarea între companii prin definirea interfețelor pentru procesele business şi
prin implementarea platformelor pentru interacțiunea dintre organizații. Este
răspândit în special în industria semiconductoarelor, a componentelor electronice
dar şi în telecomunicații şi logistică.
Platformele Business‐to‐Business sunt ideale pentru implementarea SOA pentru
că sunt bazate pe XML şi favorizează schimbul asincron de documente, oferă o serie
întreagă de mecanisme integrate care asigură securitatea şi integritatea serviciilor
oferite, dar şi monitorizarea şi administrarea eficientă a acestora;

servicii web
În prezent SOA se bazează în mare măsură pe serviciile web, deoarece acestea
au posibilitatea să ducă la îndeplinire cerințele de funcționare şi implementare.
Platformele web sunt flexibile şi se adaptează uşor, fiind ideale pentru o mare gamă
de aplicații.
Serviciile web oferă o serie de avantaje majore pentru implementarea SOA, în
primul rând pentru că sunt independente de platformă, de sistemele de operare sau
de browserele web. Apoi, pentru că furnizează un protocol pentru transmiterea
documentelor (HTTP), ce reprezintă un mecanism eficient de transfer al datelor,
acestea putând de asemenea să proceseze şi să înțeleagă mesajele în format XML şi
să returneze un rezultat dacă acest lucru este necesar.
Arhitecturile orientate pe servicii, prin tehnologiile de implementare implicite,
oferă un avantaj competitiv organizațiilor beneficiare. Caracteristicile acestei
arhitecturi conduc la îmbunătățirea semnificativă a calității serviciilor, reducerea
costurilor datorate distribuirii eficiente a informațiilor în cadrul organizațiilor, dar
şi între partenerii de afaceri. Se poate spune că SOA facilitează inovația, în condițiile
în care evoluția acesteia nu se opreşte la stadiul actual al performanțelor
tehnologiilor de implementare, oferind companiilor posibilitatea de a alinia
serviciile IT la obiectivele strategice.

Oferta SOA de la SAP. SAP permite dezvoltarea unor aplicaţii flexibile, prin intermediul
următoarelor soluţii de integrare24:
1) Serviceoriented architecture:
Enterprise Services Workplace – permite o viziune consolidată, de ansamblu, a serviciilor
disponibile din întreprindere;
Enterprise Services Wiki – permite colaborarea pe baza unui portofoliu de scenarii
economice care sunt deschise către SOA;
Enterprise Services Community – oferă experienţa şi feedbackul a peste 100 de companii
membre cu privire la integrarea SOA;
Industry Value Network – permite colaborarea bazată pe dezvoltarea inovativă a
soluţiilor economice;
Business Process Expert community – permite stabilirea unei legături între zona
economică şi IT.
2) SAP NetWeaver technology platform
3) SAP BusinessObjects portfolio

24 http://www.sap.com/platform/soa/standards.epx
7.7. Discuţii finale privind EAI

EAI vs. SOA vs. ESB
SOA aduce întreprinderilor soluții eficiente, reutilizabile în cadrul altor
proiecte şi care nu sunt mari consumatoare de timp. Opinăm că EAI şi SOA vor mai
coexista pentru o perioadă lungă de timp. Serviciile web şi SOA nu pot gestiona
singure aplicații de întreprindere complexe şi securizate şi, dacă din punct de vedere
tehnologic, lucrurile nu se vor opri, atunci acest decalaj nu va putea fi depăşit.
ESB permite integrarea la costuri reduse şi această opțiune va fi din ce în ce
mai utilizată de societățile care dețin resurse IT limitate şi care activează în medii ce
implică folosirea unui cumul de sisteme care gestionează un volum moderat de
tranzacții economice. Soluțiile livrate sub forma pachetelor EAI vor fi fundamentate
pe principiile SOA şi vor continua să fie utilizate pentru integrarea la scară largă de
întreprinderile care au număr mare de sisteme dintre cele mai diverse şi
tranzacționează volume mari de date. Soluțiile EAI ale viitorului vor folosi din ce în
ce mai mult SOA, pentru a furniza soluții fiabile, securizate, flexibile şi la costuri
scăzute.
În ceea ce priveşte sistemele ERP şi EAI, problemele generate de practica
integrării ar putea fi abordate în principal pe două căi: EAI şi/sau ERP şi integrare
prin servicii web. În continuare, vom încerca să expunem opiniile noastre, succint.
Viitorul conceptului EAI – Web Service Integration Adapters?
Noțiunea de servicii web în contextul unui proiect de integrare a aplicațiilor
întreprinderii se referă la setul de aplicații modulare sau servicii care pot fi accesate
în cadrul unei rețele (de exemplu, internet, intranet sau extranet) prin intermediul
unei interfețe standard, de obicei XML. Considerat de unii ca următoarea generație
de EAI, sau chiar un posibil înlocuitor pentru acesta, serviciile web reprezintă o
încercare de a conecta resurse şi sisteme disparate, prin intermediul unui limbaj şi
cadru universal25.
ERP sau EAI?
Spre deosebire de ERP, EAI este considerat a fi produsul software descris ca
middleware şi care sprijină aplicațiile moştenite şi cele specializate dintr‐un sistem
informatic, facilitându‐le comunicarea. Deşi există opinii conform cărora EAI este
mai ieftin decât ERP, sunt destul de multe voci care afirmă contrariul. Astfel, când se
compară costul implementării unui nou sistem ERP cu cel al integrării vechilor
aplicații, există pericolul ca adevăratul cost al uneia dintre cele două acțiuni să fie
determinat incomplet. În mod cert, în cazul sistemelor ERP costurile pot fi uşor de
observat, însă nu acelaşi lucru se poate spune despre beneficii. În cazul EAI, costurile
sunt legate doar de prețul de achiziție al aplicațiilor middleware şi de cel al
dezvoltării interfețelor26.

25 http://www.iwaysoftware.com/eai‐enterprise‐application‐integration.html
26 M. Roberts, „Enterprise Resource Planning or Enterprise Application Intergration”, disponibil la
http://it.toolbox.com/blogs/neustro/erp‐or‐eai‐29253

Cum specialiştii au opinii separate vizavi de cea mai bună alternativă de
adoptat în desăvârşirea sistemului informatic integrat al întreprinderii, doar după
analiza cerințelor sistemului şi a condițiilor specifice întreprinderii o echipă bine
pregătită poate decide care este cea mai bună soluție.

CAPITOLUL 8
Business Intelligence – noua generaţie
de sisteme de asistare a deciziilor

& înţelegeţi oportunitatea sistemelor de Business Intelligence;
& puteţi formula o definiţie pentru Business Intelligence;
& înţelegeţi arhitectura acestor sisteme;
& cunoaşteţi principalele instrumente şi tehnologii folosite;
& ştiţi care sunt numele furnizorilor de top şi care sunt tendinţele pe
această piaţă.
Activitatea economică generează un „ocean de date” (sau, cum le place altora
să spună, „suntem aşezați pe un munte de date” – „ce este mai mare: oceanul sau
muntele?” rămâne să aleagă fiecare). Fiecare dată reprezintă o părticică a afacerii şi
se găseşte în diferite locații ori departamente, uneori în mai multe regiuni
geografice. Adesea, este captivă pe un hard disk dezafectat sau într‐o arhivă prăfuită.
În afaceri, adevărul – adică slăbiciunile, punctele tari şi tendinţele – este în date. Prin
sistemele Business Intelligence sunt adunate toate datele, acestea sunt prelucrate în
informații, care bine analizate, pot fi utilizate în luarea deciziilor şi în final puse în
acțiune1.
În condițiile actualului mediu de afaceri, calitatea şi promptitudinea
informațiilor reprezintă pentru firmă nu o alegere între profit şi pierdere, ci o
chestiune de supraviețuire sau faliment. Beneficiile unui sistem Business Intelligence
(BI) sunt evidente – analiştii sunt optimişti, arătând că în anii care vin milioane de
oameni vor folosi zi de zi instrumente vizuale de analiză şi BI. Piața este deja
saturată în ceea ce priveşte oferta de aplicații analitice dintre cele mai diverse, care
pot efectua tot soiul de analize în sprijinul procesului decizional la toate nivelurile.
În jurul acestui concept s‐au lansat alți termeni legați de analiza
performanțelor organizaționale, precum BPM – Business Performance Management,
CPM – Corporate Performance Management, EPM – Enterprise Performance
Management, BA – Business Analytics, cât şi BAM – Business Activity Monitoring,
Balanced Scorecards sau Performance Dashboards, unele incluse în BI, altele râvnind
să‐l înlocuiască.

8.1. Definirea conceptului de Business Intelligence
şi a beneficiilor sale

Rădăcinile acestui concept se găsesc în anii ’70 în sistemele de raportare ale
mainframe‐urilor, când rapoartele erau statice, bidimensionale şi fără facilități
analitice. Dorința şi cererea de sisteme de raportare dinamice, multidimensionale,
cu suport pentru decizii predictive, au determinat dezvoltarea BI, care a devenit
realitate odată cu emergența noilor tehnologii. Analistul Howard Dresner, de la
Gartner Group, a propus utilizarea termenului BI2 în 19893. La momentul acela, puțini
au înțeles ce a vrut să spună Dresner, termenul a rămas un timp într‐un grup select
de dezvoltatori, în timp ce vocile opoziției au spus despre el că este un oximoron4.
Evoluția din anii ’90 a extins şi perfecționat domeniul BI şi a confirmat previziunea

1 E. Vitt, Business Intelligence: Making better decisions faster, Microsoft Press, 2002.
2 La momentul respectiv, se utilizau mai ales termenii legați de tipologia sistemelor informaționale: DSS
(sisteme de asistare a deciziilor) sau EIS (sisteme informaționale executive). Dresner a propus
termenul Business Intelligence pentru a defini un sistem informatic bazat pe analiza cantitativă a
datelor, care oferă rezultatele în diverse forme de prezentare.
3 Vezi referirile la http://www.computerworld.com/s/article/266298/BI_at_age_17
4 Şi disputa pe această temă continuă, părerile sunt în continuare împărțite; vezi http://blogs.techrepublic.
com/decisioncentral/?p=142 sau http://www.informationweek.com/blog/main/archives/2008/07/

business_ intell_2.htm
Business Intelligence – noua generaţie de sisteme de asistare a deciziilor 265
lui Dresner, conform căreia „BI va deveni parte integrantă a sistemului
informațional al întreprinderii"5.
Înainte de a defini BI, o să spunem ce nu este şi ce nu face BI, adică prelucrarea
tranzacțiilor. Cele mai comune aplicații economice se regăsesc în sistemele de
prelucrare a tranzacţiilor. Acestea au menirea de a înregistra „tot ce mişcă” într‐o
întreprindere şi de a întreține bazele de date operaționale. Modulele ERP de bază
lucrează în acest fel, ca şi unele componente ale sistemelor SCM ori CRM. Un sistem
de prelucrare a tranzacțiilor (SPT) este un sistem informatic în care calculatorul
răspunde imediat cererilor utilizatorului6. Fiecare cerere este considerată o
tranzacţie şi se va materializa prin înregistrarea unui eveniment concret, precum o
intrare de bunuri în depozit sau plata unui furnizor. Cu alte cuvinte, o tranzacție
determină adăugarea de date în una sau mai multe tabele ale bazei de date de o
manieră completă, pe baza unor reguli şi validări prestabilite. Pe cât de eficient
lucrează un SPT la întreținerea bazelor de date ale întreprinderii, pe atât de greu îi
este să răspundă interogărilor ad hoc şi să analizeze datele stocate. Bătrânele
mainframe‐uri ajunseseră să fie numite „găuri negre”, căci înghițeau volume imense
de date, dar greu puteai scoate ceva înapoi, cu excepția rapoartelor predefinite,
obținute periodic. Odată cu arhitectura client/server, sistemele ERP au adus sisteme
de raportare mai prietenoase, dar limitele s‐au menținut, astfel că s‐au căutat noi
soluții software care să‐i mulțumească pe utilizatorii manageri. S‐a dorit şi s‐a
realizat trecerea de la OLTP la OLAP, prin depozite de date, analiză
multidimensională şi aplicații analitice, ajungând în noul mileniu la consacrarea
termenului de business intelligence.
Pornind de la acest context de apariție, unii autori7 definesc BI ca sisteme
informaţionale care îi asistă pe manageri şi alţi utilizatori în analiza activităţilor
trecute şi curente şi în previziunea evenimentelor viitoare. Spre deosebire de SPT, BI
nu sprijină activitățile operaționale precum înregistrarea comenzilor sau
prelucrarea mişcărilor de stocuri, ci oferă suport managerial prin informare, analiză,
planificare şi control8.
Într‐o altă definiție9, business intelligence constituie o arhitectură şi o colecţie
de aplicaţii şi baze de date operaţionale integrate, precum şi de sisteme de asistenţă a
deciziilor, care furnizează utilizatorilor acces mai uşor la datele despre afacere.
Aplicațiile BI de asistare a deciziilor facilitează multe activități, incluzând şi analiză
multidimesională, data mining, capacitatea de previziune, analiza afacerii, facilități
de interogare, raportare, realizare a graficelor, analiză geospațială, managementul
cunoştințelor etc.

5 H. Dresner, Why enterprises must make business intelligence an imperative, 2001, raport disponibil la
http://www.gartnergroup.com
6 Termenul original care descrie aceste sisteme este Online Transaction Processing (OLTP).
7 D. Kroenke, D. Auer, Database concepts, Pearson Education, 2008, p. 350.
8 D. Airinei, D. Homocianu, „DSS vs. Business Intelligence”, The Proceedings of the International
Economic Conference: Integrative Relations between the European Union Institutions and the Member
States, Lucian Blaga University Publishing House, Sibiu, 2008.
9 L. Moss, S. Atre, Business Intelligence Roadmap, Addison‐Wesley Professional, 2003, p. 14.

Deşi este legat de aplicațiile de întreprindere, în opinia noastră BI nu este un
produs sau un sistem, ci este un conceptumbrelă10, care „adăposteşte” arhitecturi,
aplicaţii şi baze de date. Menirea sa este accesul cât mai simplu la date al
utilizatorilor dintr‐o organizație prin accesarea interactivă şi în timp real a datelor,
manipularea şi analiza acestora. Prin analiza datelor istorice, BI realizează o
valoroasă introspecție asupra activităților şi situațiilor de afaceri, iar managerii sunt
sprijiniți concret în luarea deciziilor prin informații de esență, inclusiv cele de
comportament şi de previziune.
Cheia înțelegerii BI stă în înțelegerea modului în care datele sunt prelucrate în
informații şi cum sunt ele apoi analizate şi în încadrarea acestor procese în
arhitectura, instrumentele şi aplicațiile BI. Trebuie lămurit faptul că BI nu produce
date, ci utilizează datele produse de aplicațiile de întreprindere: ERP, CRM, SCM etc.
În ultimele două decenii, în special în anii ’90, în organizații s‐au adunat
volume imense de date în cadrul nou‐implementatelor sisteme ERP, bazate pe OLTP.
A urmat firesc nevoia de a reorganiza aceste date în vederea valorificării lor: s‐au
construit depozite de date şi magazii de date, au fost implementate instrumente ETL
(extragere‐transformare‐încărcare) pentru exploatarea acestora. Totuşi, specialiştii
sunt de părere că, şi în aceste condiții, prea puține date au fost transformate în
informații, iar cele efectiv utilizate ca suport decizional au fost şi mai puține. Cauza?
Lipsa instrumentelor potrivite pentru găsirea şi analiza datelor. BI a acoperit această
lipsă.
„Drumul” de la datele aflate în sistemele informatice ale organizației la decizia
luată de omul de afaceri, trecând prin depozite de date, instrumente ETL şi
instrumente de raportare şi analiză specifice, este ilustrat în figura 8.1, într‐o
adaptare după W.A. Giovinazzo11.
Astăzi, vorbim deja despre sisteme „tradiționale” de business intelligence,
livrate prin implementări clasice client/server şi sisteme moderne, cu implementare
bazată pe web şi oferită utilizatorului prin conexiuni internet sau intranet, precum şi
aplicații BI optimizate pentru dispozitive mobile, pentru smartphone sau e‐mail.
Cele mai importante domenii de aplicare a soluţiilor BI sunt:
raportări generale;
analiza vânzărilor şi marketing;
planificare şi previziune;
consolidare financiară;
bugetare;
analiza profitabilității.
Efectele instalării unui sistem BI sunt uimitoare, deoarece acesta produce
informația care trebuie la momentul la care aceasta este necesară, asigurând unul
dintre ingredientele succesului în afaceri. BI este arta de a şti şi de a valorifica
informațiile, câştigând avantaje competiționale. BI poate oferi răspunsuri la

10 Ideea de termen „umbrelă” îi aparține lui M. Raisinghani, autor al uneia dintre primele cărți de succes
în domeniul BI: Business Intelligence in the digital economy (The Idea Group, 2004).
11 W.A. Giovinazzo, Internet – Enabled Business Intelligence, Prentice Hall, 2002, p. 23.
problemele esențiale ale unei organizații, ajutând‐o să ia decizii pentru rezolvarea
acestora. Găsirea răspunsurilor se bazează pe analiza şi compararea datelor istorice,
atât a celor create în cadrul organizației, cât şi a datelor din surse externe. Adunarea
şi analiza acestor date permit înțelegerea tendințelor afacerii, a punctelor tari şi a
slăbiciunilor, analiza competitorilor şi a situației de pe piață.

Sursa: Măzăreanu, V., „«Inteligență» în Business Intelligence”, Analele Ştiinţifice ale
Universităţii Alexandru Ioan Cuza, Iaşi, Tomul LII/LIII, 2005/2006, p. 362.
Figura 8.1. De la date din sistemele operaţionale la strategii de afaceri

Beneficiile utilizării sistemelor BI pot fi sistematizate astfel:
rapoarte mai corecte, obținute mai rapid;
îmbunătățirea procesului decizional;
apropierea de clienți;
venituri mai mari;
economii de costuri IT şi non‐IT.
Sondajele de opinie (OLAP 3 Report, disponibil la adresa www.survey.com/olap)
asupra beneficiilor BI sunt încurajatoare: 60% dintre companiile care au
implementat un sistem BI spun că şi‐au atins obiectivele, iar 19%, chiar că le‐au
întrecut (vezi şi tabelul 8.1). Într‐un alt studiu, realizat de Eckerson 2003, pe primele
locuri s‐au situat: economia de timp (60%), obținerea unei singure versiuni a
adevărului (59%), strategii şi planuri mai bune (57%) şi un proces decizional
îmbunătățit (56%). Aşa cum se poate observa, multe dintre beneficiile BI sunt
intangibile, motiv pentru care nu se recomandă o analiză de fezabilitate sub raportul
costurilor în cazul acestor proiecte.
Beneficiarii soluțiilor BI sunt unanimi în privința rezultatelor implementării
acestora vizavi de implementarea altor soluții din familia ERP. Beneficiile sunt
apreciate ca fiind mai mari şi vizibile mai rapid. Totuşi, trebuie să arătăm că
beneficiile BI se clădesc pe cele ale ERP – acestea oferă datele necesare constituirii
depozitelor de date. Aşa cum am mai arătat, BI scot la iveală informațiile esențiale

din sistemele ERP, oferind un excelent suport decizional, dar nu ar avea nicio şansă
dacă depozitele nu ar fi corect alimentate cu toate datele organizației.
Tabelul 8.1
Beneficiile BI conform OLAP 3 Report

Beneficii % companii care leau realizat
Rapoarte mai rapide şi mai corecte 81
Proces decizional îmbunătățit 78
Relații cu clienții îmbunătățite 56
Venituri mai mari 49
Economii de costuri non‐IT 50
Economii de costuri IT 40

Promovarea acestui nou tip de „inteligență economică” nu i‐a lăsat indiferenți
pe managerii organizațiilor. Un aspect este deosebit de important în ceea ce priveşte
achiziția unui sistem BI: nefiind un produs „cu mărime universală”, nu se potriveşte
la fel tuturor beneficiarilor, fiecare organizație este unică în privința proceselor
economice şi a regulilor de afaceri. Simpla personalizare sau localizare a aplicațiilor
nu este suficientă pentru a implementa un sistem BI eficient.
Alegerea şi implementarea sistemului BI potrivit trebuie să aibă în vedere
cerințele funcționale şi nevoile utilizatorilor, aspectele tehnice, precum şi bugetul.
Convergența dintre nevoile organizației şi caracteristicile sistemului ales este
esențială pentru succesul proiectului.

8.2. Arhitectura şi componentele unui sistem BI

Dacă primele sisteme de BI erau alcătuite în principal din depozitul de date, în
jurul căruia se brodau diverse instrumente de analiză, astăzi ele au o arhitectură
mult mai complexă. Prezentarea noastră se concentrează asupra componentelor
principale ale acesteia şi detaliză într‐un paragraf distinct depozitul de date, care
rămâne piesa centrală a unui sistem de BI.

8.2.1. Componentele unei soluţii BI

Un sistem BI are patru componente importante:
depozitul de date, care este sursa de date a sistemului;
aplicaţii analitice (business analytics), o colecție de instrumente pentru
manipularea, mineritul şi analiza datelor din depozitul de date;
business performance management (BPM) pentru monitorizarea şi analiza
performanței;
interfaţa utilizator.
Relația dintre aceste componente este ilustrată în figura 8.2. Se poate observa
că există o zonă tehnică ce cuprinde depozitul de date, crearea şi întreținerea lui, o
zonă a analizei în care activează utilizatorii curenți, şi o a treia zonă de performanță
şi strategie, în care top‐managerii stau de regulă în fața unui tablou de bord.


Sursa: Adaptare după Eckerson, W., Smart companies in the 21st Century: the secrets of creating successful
Business Intelligence solutions, The Data Warehousing Institute, 2003, p. 32.
Figura 8.2. Arhitectura unui sistem Business Intelligence

Într‐un sistem BI se regăseşte o combinație de arhitecturi şi tehnologii
software. În structura specifică BI12, sunt reunite următoarele instrumente (vezi
figura 8.3): depozite şi magazii de date (Data Warehouse, Data Mart), ETL (Extract
Transfer Load), instrumente de interogare şi raportare (Reporting and Query),
instrumente de vizualizare (data visualization), tabloul de bord (dashboard), OLAP
(OnLine Analytical Processing), minerit de date (Data Mining), sisteme de alertare şi
notificare (alerting and notification systems), care vor fi analizate pe scurt în
continuare.
Depozite de date. Diversele surse de date (OLTP, ERP, CRM, SCM, alte
aplicații de întreprindere, surse externe) înseamnă efectiv baze de date diferite, cu
formate şi structuri de date specifice. Reunirea acestora este deosebit de importantă,
de aceea depozitul de date (DD), care asigură captarea şi unificarea datelor, este
considerat jucătorul numărul 1 în sistemul BI, cel mai însemnat şi mai costisitor.
„Păstrătorul” tuturor datelor sprijină procesul de luare a deciziilor pentru
conducerea tactică şi operațională căreia îi oferă variante multiple de vizualizare şi
analiză a datelor, dar se mulează şi pe cerințele informaționale ale top‐managerilor.
Datele extrase din depozit la nivel departamental sunt adunate în aşa‐numita
magazie de date (data mart), ce asigură accesul mai rapid şi mai simplu (exemple:
date marketing, date producție, date vânzări etc.). Uneori, se confundă DD şi
funcțiunile BI. Diferența este că DD poate funcționa în afara sistemului BI. Invers nu
se poate. Apare firesc întrebarea „de ce mai avem nevoie de BI?”. Pentru că valorifică
la maximum potențialul DD – infrastructura BI este completă, oferind, pe de o parte,
flexibilitatea de a alege între diferite instrumente, iar pe de altă parte, asigurarea
finalității, prin valorificarea informațiilor obținute.

12 C. Kelley, „Navigating Business Intelligence – An Architected Data Approach”, 2004, disponibil la
http://www.businessintelligence.com

Explorare
Instrumente
Data Mining
CRM
DD
ETL
CPM
ETL
ETL
BSC
Sisteme-sursă
Sisteme sursă BDO Cunoaştere
(baze de date
operaţionale)
Tablou de bord
Figura 8.3. Vedere structurală asupra sistemelor Business Intelligence

Instrumente ETL. Procesul de populare a DD se realizează prin activitățile
ETL: extragere, transformare, încărcare, ce constituie de fapt trei funcțiuni distincte.
Prima, extragerea, citeşte datele dintr‐o sursă şi extrage setul de date dorit. Apoi,
funcțiunea de transformare lucrează cu datele extrase – utilizând reguli ori tabele de
căutare şi creând combinații cu alte date – converteşte datele în forma dorită. În fine,
încărcarea scrie datele obținute în baza de date‐țintă, asigurând conversia între
bazele de date şi migrația de pe o platformă pe alta.
Instrumente de raportare şi vizualizare. Una dintre funcțiunile principale
ale BI, raportarea, desemnează procesul de accesare a datelor, formatarea acestora
şi livrarea lor sub formă de informații. Rapoartele şi cererile sunt obținute cu
ajutorul limbajului de interogare SQL. Instrumentele de vizualizare îi ajută pe
utilizatori să „vadă” mai clar datele. Forma preferată o constituie reprezentările
grafice. Cu ajutorul acestor instrumente sunt interpretate informațiile şi relațiile
dintre date. Pot fi combinate reprezentări diferite de seturi de date multiple, se pot
obține vederi multiple ale unui singur set de date.
Business Performance Management prin Balanced Scorecards. Instru‐
mentele BSC sunt menite să‐l ajute pe utilizator să pună strategia în practică. Este
vorba despre un sistem de măsurare a performanțelor, derivat din obiectivele şi
strategia organizației, ce reflectă cele mai importante aspecte ale afacerii. BSC poate
fi văzut ca o listă centrală de numere predefinite, fiecare corespunzătoare unei
componente‐cheie a succesului afacerii. BSC se concentrează asupra nivelului
strategic al obiectivelor managementului; prin intermediul acestui instrument,
managerii de la toate nivelurile monitorizează rezultatele în zonele‐cheie ale
afacerii.
Tabloul de bord (dashboard). Oferă o viziune comprehensivă asupra

performanței organizației, prin intermediul unui set de indicatori de măsurare
specifici (KPI – key performance indicators), cât şi prin semnalarea tendințelor şi a
excepțiilor. Un dashboard integrează informații din toate ariile de business şi le
oferă în formă grafică, arătând evoluțiile efective în comparație cu cele dorite, ceea
ce indică dintr‐o privire „starea de sănătate" a firmei.
OLAP. Această componentă (prelucrare analitică online, din engl. online
analytical processing) permite utilizatorului extragerea şi prezentarea facilă şi
selectivă a datelor, din diferite puncte de vedere. Această analiză este posibilă doar
în baze de date multidimensionale. Elementul principal este serverul OLAP, situat
între client şi SGBD. Instrumentele OLAP permit analiza pe diferite dimensiuni a
datelor multidimensionale şi se utilizează frecvent în mineritul de date (data
mining).
Minerit de date (MD). Denumirea acestor instrumente indică clar scopul lor,
iar comparația este reuşită: adesea trebuie să „sapi” destul de mult pentru a ajunge
la informațiile utile. Instrumentele MD extrag informațiile ascunse în bazele de date
şi pot căuta după diferite şabloane în bazele de date tranzacționale. Diferența față de
OLAP se poate exprima astfel: dacă OLAP răspunde întrebărilor care i se pun, MD
răspunde şi întrebărilor care nu i se pun. Instrumentele de data mining „excavează”
în volume imense de date tranzacționale pentru a scoate la iveală posibile legături
interesante precum obiceiurile de consum individuale şi nivelul cheltuielilor în
restaurante, de exemplu. Se utilizează tehnici ale analizei statistice sau de inteligență
artificială, care permit descoperirea de corelații, reguli şi cunoştințe utile sprijinirii
deciziilor.
Sisteme de alertare şi notificare. Acestea funcționează proactiv, oferind
utilizatorilor informații pe baza unor criterii prestabilite, odată ce se produc
evenimentele. Utilizatorii sunt continuu la curent cu producerea evenimentelor
importante – mesajele le parvin la birou, acasă sau pe drum, prin e‐mail sau alte
tehnologii wireless.

8.2.2. Locul depozitelor de date întrun sistem BI

Depozitele de date au fost definite în foarte multe moduri, astfel încât este
destul de dificil de formulat o definiție riguroasă. În sens larg, un depozit de date
reprezintă o bază de date care este întreținută separat de bazele de date
operaționale ale organizației. Datele din sistemele‐sursă sunt extrase, curățate,
transformate şi stocate în depozite speciale în scopul sprijinirii proceselor
decizionale. Depozitele de date sprijină procesarea informațiilor, furnizând o
platformă solidă de consolidare a datelor istorice pentru analiză. Un depozit de date
este o sumă de date consistentă din punct de vedere semantic, care serveşte la o
implementare fizică a unui model de date pentru sprijinirea deciziei şi stochează
informații pe care o organizație le solicită în luarea deciziilor strategice.

8.2.2.1. Definire şi caracteristici

După W.H. Inmon, părintele conceptului de data warehouse, „un depozit de
date este o colecție de date orientate pe subiecte, integrate, istorice şi persistente,
destinată sprijinirii procesului de luare a deciziilor manageriale”13. Această definiție
exprimă caracteristicile majore ale depozitelor de date: orientarea pe subiecte,
integrarea, caracterul istoric, persistența datelor.
Orientarea pe subiecte. Un depozit de date este organizat în sensul unor
subiecte majore cum ar fi: clienți, furnizori, producție, vânzări etc. Mai curând decât
a concentra procesarea operațiilor şi tranzacțiilor zilnice într‐o organizație, un
depozit de date se focalizează pe modelarea şi analiza datelor pentru luarea
deciziilor. Din acest motiv, depozitele de date oferă, în mod tipic, o viziune simplă şi
concisă relativă la un subiect particular, excluzând datele care nu sunt utile în
procesul de sprijinire a deciziei.
Integrarea. Un depozit de date este, în mod uzual, construit prin integrarea
unor multiple surse eterogene: baze de date relaționale, fişiere, înregistrări privind
tranzacții online etc. Tehnicile de curățare a datelor (data cleaning) şi de integrare
sunt aplicate pentru a asigura concordanța în convențiile de atribuire a numelor, de
codificare a structurilor, de atribuire a valorilor etc.
Caracterul istoric. Datele sunt stocate pentru a furniza informații în
perspectivă istorică (ex. 5‐15 ani în urmă). Astfel, decidenții pot consulta valorile
succesive ale aceloraşi date pentru a determina evoluția în timp şi a calcula
tendințele anumitor indicatori.
Persistenţa datelor. Datele dintr‐un depozit sunt permanente şi nu pot fi
modificate. O actualizare a depozitului de date, ca urmare a modificărilor efectuate
în datele‐sursă înseamnă adăugare de date noi fără a modifica sau şterge datele
existente. Un depozit de date este întotdeauna memorat separat, din punct de
vedere fizic, de datele transformate din alte aplicații. Datorită acestei separări, un
depozit de date nu necesită mecanisme de procesare a concurenței; în mod uzual
solicită numai două operațiuni: încărcarea inițială a datelor şi accesul la date.
În legătură cu depozitele de date, o noțiune frecvent utilizată este cea de data
warehousing, care desemnează procesul de construire şi utilizare a depozitelor de
date. Construirea unui depozit de date necesită integrarea datelor, curățarea şi
consolidarea datelor. Utilizarea unui depozit de date necesită adesea o colecție de
tehnologii de asistare a deciziilor. Alți autori utilizează termenul de data
warehousing pentru a se referi numai procesul de construire a depozitului de date,
în timp ce termenul de „warehouse DBMS” este folosit pentru construirea şi
utilizarea depozitului de date14.

13 W.H. Inmon, Building the Data Warehouse, John Wiley & Sons, New York, 1996, p. 3.
14 J. Han, M. Kamber, Data Mining: Concepts and Techniques, Morgan Kaufman Publishers, San Francisco,
2001, p. 41.
În privința utilizării datelor din depozitele de date, trebuie precizat că multe
organizații folosesc aceste informații pentru sprijinirea luării deciziilor în diferite
domenii de activitate cum ar fi:
sporirea focalizării pe clienți, care include analize ale vânzărilor (preferințe,
periodicitate, cicluri bugetare, apetit pentru cumpărare, factori de influență a actului
de cumpărare etc.);
reorientarea producției şi gestionarea portofoliului de produse, comparând
performanțele vânzărilor pe trimestre, ani, zone geografice, în ordinea celor mai
bune strategii de producție;
analiza operațiilor şi căutarea surselor de profit;
gestionarea relațiilor cu clienții.
Data warehousing este, de asemenea, foarte util din punctul de vedere al
integrării surselor de date eterogene. Multe organizații colectează, în mod obişnuit,
diferite tipuri de date şi întrețin baze de date mari din surse de informații multiple,
eterogene, autonome şi distributive. Integrarea acestor date şi obținerea unui acces
eficient la ele este lucrul cel mai dorit. Multe eforturi au fost depuse în industria
bazelor de date şi în comunitățile de cercetare pentru îndeplinirea acestui scop.
În concepția bazelor de date tradiționale, integrarea bazelor de date eterogene
este realizată de „wrappers” şi integratori (integrators) sau mediatori (mediators)
asupra bazelor de date multiple (ex.: IBM Data Joiner, Informix Data Blade). Când o
interogare este adresată unui site server, un dicționar de metadate este utilizat la
transformarea interogării în interogări corespunzătoare site‐urilor eterogene
implicate. Aceste interogări sunt atunci mapate şi transmise proceselor locale de
interogare. Rezultatele primite de la diferite site‐uri sunt integrate în răspunsul
global.
Acest concept de interogare necesită procese complexe de filtrare şi integrare,
care concurează la resursele de procesare. Este ineficient şi potențial scump pentru
interogări frecvente, în special pentru interogări care solicită agregări. Data
warehousing furnizează o alternativă interesantă la conceptul tradițional de
integrare a bazelor de date eterogene; folosind conceptul de „update‐driven”, în care
informațiile din surse multiple, eterogene, sunt interogate în avans şi stocate în
depozitul de date pentru integrare directă şi analiză. Spre deosebire de bazele de
date cu procesare online, depozitele de date nu conțin întotdeauna informațiile cele
mai proaspete. Cu toate acestea, un depozit de date determină o performanță înaltă
prin integrarea datelor eterogene, întrucât datele sunt copiate, preprocesate,
integrate, adnotate, însumate şi restructurate într‐o colecție semantică de date
(semantic data store). În plus, procesul de interogare din depozitul de date nu
interferează cu procesele din sursele locale.
În sinteză, scopurile unui depozit de date sunt următoarele15:
să furnizeze utilizatorilor accesul sporit la date;
să furnizeze o singură versiune a adevărului;
să înregistreze cu acuratețe trecutul;

15 D. Airinei, Depozite de date, Editura Polirom, Iaşi, 2002, pp. 21‐22.

să „jongleze” cu nivelurile de acces sinteză/detaliu la date;
să separe prelucrările de nivel operațional şi analitic.
Accesul sporit la date pentru utilizatori. Depozitul de date furnizează
accesul la datele integrate ale întreprinderii, anterior blocat prin interfețe neprie‐
tenoase, rigide. Utilizatorii trebuie să poată stabili, cu un minim efort, o conexiune
garantată la depozitul de date prin intermediul unui microcalculator. Securitatea
este sporită prin the warehouse frontend application, prin serverul bazei de date sau
prin ambele.
O singură versiune a adevărului. Datele din depozitele de date sunt
consistente şi au calitatea asigurată înainte de a fi puse la dispoziția utilizatorilor
finali. În măsura în care se utilizează o sursă comună de date, depozitele de date pun
capăt dezbaterilor privind veridicitatea datelor utilizate sau citate în şedințele de
lucru. Depozitul de date începe să fie resursa comună de date pentru nivelurile
decizionale din organizații. Menționăm că „o singură versiune a adevărului” este
adesea posibilă numai după multe discuții şi dezbateri asupra termenilor utilizați în
organizație. De exemplu, termenul de „client rău‐platnic” poate avea mai multe
înțelesuri: client care nu plăteşte la timp, client care nu plăteşte decât parțial, client
care nu plăteşte niciodată etc. Ar putea fi stabilită şi o altă accepție: clienți care au
datorii mai vechi de o lună. În mod sigur, aceste accepții au influență asupra
proceselor decizionale şi asupra persistenței deciziilor.
Înregistrarea cu acurateţe a trecutului. Multe date primite de manageri nu
sunt semnificative, dacă nu sunt comparate cu datele anterioare. De exemplu,
rapoartele care compară performanțele actuale ale companiei cu cele din anul
precedent sunt comune. Rapoartele care arată performanțele companiei pentru
fiecare lună din ultimii trei ani pot fi foarte interesante pentru decidenți. Sistemele
operaționale permit mai greu obținerea unor astfel de informații. Un depozit de date
va fi utilizat pentru înregistrarea cu acuratețe a trecutului, lăsând sistemele OLTP
libere pentru a realiza focalizarea pe înregistrarea corectă a tranzacțiilor. Datele
istorice sunt încărcate şi integrate cu alte date în depozit pentru un acces rapid.
Acces combinat sinteză/detaliu la date. Rapoartele dinamice şi instru‐
mentele de interogare OLAP permit utilizatorilor să vizualizeze informațiile din
depozitul de date sub diferite unghiuri şi la diferite niveluri de detaliere. Aceste
disponibilități oferite de depozitele de date reduc timpul şi efortul necesar pentru
colectarea, formatarea şi filtrarea informațiilor, plecând de la date.
Separarea prelucrărilor de nivel operaţional şi analitic. Procesele
decizionale şi procesele operaționale sunt totalmente divergente arhitectural. În
încercarea de a se reuni în acelaşi sistem, informațiile decizionale şi operaționale
determină ca întreținerea sistemului să devină o problemă.
O comparaţie între bazele de date şi depozitele de date este în măsură să
ofere o imagine coerentă privind rolul depozitelor de date în organizații, precum şi
raporturile cu alte tipuri de sisteme informatice. Atât bazele de date, cât şi
depozitele de date conțin mari cantități de date structurate care pot fi consultate
rapid datorită structurilor de acces optimizate şi se bazează, în majoritatea
cazurilor, pe tehnologii relaționale. Totuşi, ele nu au fost proiectate pornind de la
aceleaşi obiective şi se diferențiază prin numeroase aspecte.
Bazele de date din sistemele operaționale conțin date curente, detaliate, care
trebuie actualizate şi interogate rapid, în condiții de deplină securitate, constituind
suportul sistemelor informaționale de prelucrare a tranzacțiilor.
Depozitele de date sunt concepute special pentru sprijinirea luării deciziilor.
Interogările obişnuite într‐un depozit de date sunt mai complexe şi mai variate decât
cele din sistemele de gestiune a bazelor de date. Ele se aplică unor volume foarte
mari de date şi presupun calcule complexe (analiza tendinței, medii, dispersii etc.),
care necesită adesea agregări. Deosebirile majore între OLTP (baze de date) şi OLAP
(depozite de date) sunt sintetizate în tabelul 8.2 şi iau în considerare mai multe
trăsături.
Tabelul 8.2
Comparaţie între sistemele OLTP şi OLAP

Trăsătură OLTP (BD) OLAP (DD)

Destinația Procese operaționale Procese informaționale
Orientarea sistemului Tranzacții Analize
Utilizatori Funcționari, Specialişti, manageri executivi,
administratori BD, analişti
profesionişti BD
Funcții Operații zilnice Cerințe informaționale pe termen
lung, asistarea deciziei
Instrumente folosite în Diagrame E‐R Modelarea star/snowflake
proiectare
Caracterul datelor Curente, noutate garantată Istorice, precizie menținută în
timp
Nivelul de sinteză Primitive, detaliere Sintetizare, consolidare
ridicată
Unitatea de lucru Scurtă, tranzacții simple Interogări complexe
Scheme de acces Read/Write Aproape întotdeauna Read
Focalizare Culegere date Furnizare informații
Număr de înregistrări Zeci Milioane
accesate
Număr de utilizatori Mii Sute
Mărimea bazei de date 100 MB – GB 100 GB – EB
Priorități Performanțe ridicate, Flexibilitate ridicată, autonomie
disponibilitate ridicată utilizatori finali
Sistem de evaluare Tranzacții culese Interogări culese, timp de răspuns

Un sistem OLTP este orientat pe client şi este utilizat pentru procesarea
tranzacțiilor şi interogărilor. Un sistem OLAP este orientat spre piață şi este utilizat
de manageri, analişti şi specialişti. Din punctul de vedere al datelor conținute, un
OLTP gestionează date curente care, în mod obişnuit, sunt destul de detaliate pentru
a fi uşor utilizate în luarea deciziilor curente. Un sistem OLAP gestionează volume
mari de date istorice, furnizând facilități pentru sintetizare şi agregare, precum şi

pentru stocarea şi gestionarea informațiilor cu diferite niveluri de granularitate.
Aceste aspecte fac ca datele să fie uşor utilizate de decidenți, mai ales în domeniile
tactic şi strategic. De asemenea, un sistem OLTP este focalizat în principal pe datele
curente dintr‐o organizație sau dintr‐un departament, fără a face referire la date
istorice sau date din alte organizații. În constrast, un sistem OLAP cuprinde date
istorice şi date care provin de la diferite organizații, integrând informații din surse
eterogene.
De ce nu se execută procesări analitice online (OLAP) direct pe bazele de date
existente, decât a cheltui timp şi resurse pentru a construi separat un depozit de
date? Este o întrebare pertinentă, iar răspunsul poate explica şi fundamenta
investiția într‐un depozit de date. Argumentul forte pentru această separare este
promovarea performanței ridicate în ambele sisteme.
O bază de date relațională este proiectată şi adaptată pornind de la sarcini şi
activități cunoscute cum ar fi indexarea, utilizarea cheilor primare, căutarea unor
înregistrări specifice, optimizarea interogărilor. Pe de altă parte, interogările unui
depozit de date sunt adesea complexe. Ele implică efectuarea de calcule asupra unor
grupuri mari de date, cu totalizări pe diferite niveluri, care pot necesita utilizarea de
metode speciale de organizare a datelor, de acces şi implementare bazate pe viziuni
multidimensionale. Procesând interogările OLAP într‐o bază de date operațională,
s‐ar degrada substanțial performanțele sarcinilor operaționale. De altfel, o bază de
date operațională sprijină procesarea concurentă a tranzacțiilor multiple. Controlul
concurenței şi mecanismele de verificare sunt necesare pentru a asigura consistența
şi robustețea tranzacțiilor. O interogare OLAP are nevoie adesea de acces read‐only
la înregistrări pentru sumarizare şi agregare. Mecanismele de control al concurenței
pot încetini execuția tranzacțiilor concurente şi astfel să reducă substanțial
performanța unui sistem OLTP.
În final, separarea dintre bazele de date operaționale şi depozitele de date se
bazează pe structuri, conținut, utilizatori şi date diferite. Luarea deciziilor necesită
date istorice, pe când bazele de date operaționale nu conțin, în mod obişnuit, date
istorice. În acest context, datele operaționale, deşi abundente, sunt departe de a fi
suficiente pentru luarea deciziilor. Asistarea deciziei solicită consolidarea datelor
(totalizări şi agregări) din diferite surse, rezultând date de înaltă calitate, curate şi
integrate. În contrast, bazele de date operaționale conțin numai date neprelucrate
(primare), detaliate, cum sunt tranzacțiile care trebuie consolidate înaintea
analizelor. Dat fiind faptul că cele două sisteme au funcționalități diferite şi necesită
tipuri diferite de date, este necesar să le menținem în baze de date separate. Totuşi,
mulți vânzători de SGBD‐uri operaționale au început optimizarea acestor sisteme,
aşa încât ele suportă interogările OLAP. Pe linia acestui trend, separarea dintre
sistemele OLTP şi cele OLAP este de aşteptat să scadă.
Discuțiile despre depozitele de date conduc, în mod natural, la magazine de
date (Operational Data Stores – ODS), care la prima vedere nu se deosebesc de
depozitele de date. Deşi ambele tehnologii sprijină decidenții, ele sunt diferite,
deoarece au scopul de a acoperi anumite tipuri de cerințe informaționale.
Inmon şi Battas definesc un ODS ca „o construcție arhitecturală unde este
stocată o colecție integrată de date operaționale”. ODS poate fi definit, de asemenea,
ca o colecție de baze de date proiectate pentru sprijinul controlului operațional. Spre
deosebire de bazele de date din aplicațiile OLTP (care sunt operaționale sau
orientate pe funcții), ODS cuprind date orientate pe subiecte din întreprinderi mari.
Spre deosebire de depozitele de date, datele din ODS sunt volatile şi detaliate. ODS
furnizează o viziune integrată asupra datelor din sistemele operaționale.

Tabelul 8.3
Depozite de date şi magazine de date

Data Warehouse Operational Data Store
Scopuri Sprijinirea deciziilor strategice Control operațional
Asemănări Date integrate Date integrate
Orientare pe subiecte Orientare pe subiecte
Deosebiri Date statice Date volatile
Date istorice Date curente
Date sintetice Detaliere ridicată

Literatura de specialitate prezintă mai multe situații în care un depozit de date
este oportun pentru rezolvarea problemelor apărute16: insuficienta partajare a
informațiilor, grupuri diferite care produc rapoarte contradictorii, proces foarte
anevoios în privința realizării rapoartelor, rapoarte statice care nu favorizează stilul
de interogare ad hoc.
Insuficienta partajare a informaţiilor. De exemplu, serviciile sau
departamentele care au aceiaşi clienți nu comunică informațiile între ele. Ca urmare,
se pierd oportunitățile referitoare la stabilirea profilului real al clienților. De
asemenea, clienții pot fi plictisiți sau agasați de faptul că departamente din cadrul
aceleiaşi organizații le solicită de mai multe ori aceleaşi informații. Rezolvarea
acestei probleme, prin tehnologia depozitelor de date, duce la următoarele avantaje:
pot fi luate decizii mai eficiente în domeniul gestiunii clienților;
clienții sunt tratați ca entități individuale;
pot fi explorate noi oportunități de afaceri.
Grupuri diferite care produc rapoarte contradictorii. Datele din sistemele
operaționale diferite conduc la informații diferite despre acelaşi subiect. Folosirea
inconsistentă a termenilor duce la reguli diferite pentru acelaşi subiect. Astfel,
faptele sunt interpretate diferit, iar în organizație vor exista mai multe versiuni ale
„adevărului”. Decidenții trebuie să analizeze date conflictuale şi îşi pot pierde
credibilitatea în fața clienților, furnizorilor sau autorităților statului. Soluția
depozitelor de date conduce la următoarele beneficii:
o viziune consistentă asupra operațiunilor întreprinderii;
decizii mai bune, bazate pe analize corecte.

16 M. Humpries, M. Hawkins, M. Dy, Data Warehousing. Architecture and Implementation, Prentice Hall
PTR, Upper Saddle River, New Jersey, 1999, pp. 55‐57.

Procesul de creare a rapoartelor este foarte anevoios. Rapoartele de

importanță critică necesită prea mult timp pentru a fi produse, ceea ce face ca,
atunci când sunt disponibile, să nu mai fie necesare. Preluarea datelor într‐un raport
complex din mai multe sisteme operaționale poate conduce la inconsistențe sau
erori. Ca urmare, deciziile luate pe baza acestor rapoarte pot fi eronate. Analiştii din
organizație pierd prea mult timp cu colectarea datelor de care au nevoie, iar pentru
analiza propriu‐zisă le rămâne prea puțin timp. Concurenții care nu au asemenea
probleme beneficiază în mod clar de un avantaj competitiv. Rezolvarea acestei
probleme conduce la următoarele rezultate pozitive pentru organizație:
procesul de creare a rapoartelor este în mod vizibil îmbunătățit;
rămâne mai mult timp pentru analiza efectivă a datelor;
decidenții nu sunt nevoiți să lucreze cu date „învechite”.
Rapoartele nu sunt dinamice şi nu favorizează stilul de interogare ad
hoc. Acest lucru înseamnă că rapoartele prezentate managementului superior nu
sunt dinamice şi nu au capacitatea de a oferi facilități drilldown pentru detalierea
datelor. Ca urmare, când un raport prezintă o situație de alarmă sau de excepție,
decidentul nu poate vedea mai multe detalii despre situația respectivă. Odată
rezolvată această problemă, decidenții pot obține mai multe detalii atunci când au
nevoie, iar analizele referitoare la tendințe şi la relații cauzale vor fi posibile.
Rapoartele care necesită date istorice sunt dificil de realizat. Există cazuri
când datele istorice despre clienți, produse şi operațiuni financiare nu sunt stocate
în sistemele operaționale. Încercarea de a încorpora datele mai vechi în noile
rapoarte se poate lovi de impedimentul nepotrivirii vechilor structuri cu cele
actuale. Ca urmare, rapoartele nu pot fi produse la timp sau chiar deloc, iar
decidenții nu vor avea posibilitatea de a efectua analize de trend de‐a lungul unei
perioade de timp mai mari. Organizația nu va fi capabilă să anticipeze evenimentele
şi schimbările de comportament; cererile consumatorilor vor veni ca o adevărată
surpriză, iar organizația va trebui să se forțeze pentru a le satisface.

8.2.2.2. Arhitecturi pentru depozite de date

Succesul unui proiect de tip data warehouse depinde foarte mult de tipul de
arhitectură pentru care se optează. Astfel, implementatorul va avea posibilitatea să
opteze pentru o arhitectură simplificată sau pentru una cu mai multe straturi. Vom
prezenta spre ilustrare primul tip, arhitectura simplificată a unui depozit de date17
care este reprezentată în figura 8.4.
În depozitul de date întâlnim mai multe tipuri de date care corespund
diferitelor cerințe informaționale ale utilizatorilor: date detaliate, date agregate,
metadate. Metadatele descriu datele conținute în depozitul de date şi modul în care
ele sunt obținute şi stocate. Prin intermediul metadatelor se precizează structura
datelor, proveniența lor, regulile de transformare, de agregare şi de calcul.

17 Preluare din D. Airinei, O. Dospinescu, „Depozite de date”, în volumul Sisteme informaţionale pentru
afaceri, Editura Polirom, Iaşi, 2002, pp. 312‐313.
Metadatele joacă un rol esențial în alimentarea depozitului de date; ele sunt utilizate
în toate etapele de încărcare a datelor şi sunt consultate şi actualizate pe parcursul
întregului ciclu de viață al depozitului. Includerea datelor agregate în depozit, deşi
determină o creştere a redundanței datelor, este necesară deoarece în acest fel se
poate asigura un timp mediu de răspuns cât mai redus.

Date externe
Depozit de
date
Instrumente pentru accesare şi utilizare

Metadate
Date puternic agregate Datamart
Date interne
Date uşor agregagte
Datamart
Date detaliate
Datamart
Date vechi
arhivate

Figura 8.4. Arhitectura simplificată a unui depozit de date

Sursele de date pentru depozitele de date sunt: bazele de date operaționale
curente, bazele de date vechi arhivate, precum şi baze de date externe. Construirea
depozitului de date presupune parcurgerea următoarelor etape:
un proces de extragere a datelor din bazele de date operaționale sau din
surse externe, urmat de copierea lor în depozitul de date. Acest proces trebuie cel
mai adesea să transforme datele în structura şi formatul intern al depozitului.
un proces de curăţare a datelor, pentru a exista certitudinea că datele sunt
corecte şi pot fi utilizate pentru luarea deciziilor;
un proces de încărcare a datelor corecte în depozitul de date;
un proces de creare a unei multitudini de agregări ale datelor: totaluri
precalculate, subtotaluri, valori medii etc. care se preconizează că vor fi cerute şi
folosite de utilizatori.
Depozitele de date sunt destinate managerilor, analiştilor şi specialiştilor
angrenați în luarea deciziilor strategice privind dezvoltarea şi viitorul organizațiilor.
Pentru aceasta, ei au nevoie de instrumente performante de accesare şi utilizare a
datelor din depozite, instrumente asigurate prin software‐ul asociat depozitului de
date. Întreaga gamă de instrumente software asociate depozitelor de date este
prezentată în figura 8.5. Pe de o parte, regăsim instrumente necesare utilizatorilor
care au nevoie de acces rapid la informații punctuale, care includ un limbaj de

interogare gen SQL sau generatoare de rapoarte ce transpun informațiile în formate
adecvate. Pe de altă parte, sunt instrumente specializate pentru asistarea deciziilor,
care transformă informațiile în forma cerută de decidenți (grafice, diagrame,
organigrame, simulări previzionale vizuale) sau oferă posibilitatea analizei
tendințelor, corelațiilor şi interpretarea acestora. În această categorie se încadrează
instrumentele de tip OLAP şi data mining.

Instrumente de Tehnologii Instrumente de
extragere şi Warehouse accesare şi utilizare
transformare
Date sursã OLAP
Conectivitate cu
alte sisteme Report Writers
Extragere Data
Warehouse
DSS
Transformare
Data Mining
Asigurarea calitãţii
Metadate
Încãrcare date Sisteme de alertã

transformate

Figura 8.5. Componentele software ale depozitelor de date

Din punctul de vedere al ariei de cuprindere, se întâlnesc trei modele de
depozite de date: depozite de întreprindere, data mart‐uri şi depozite virtuale.
Un depozit de întreprindere (Enterprise Warehouse) colectează toate
informațiile despre subiecte care privesc întreaga organizație. El furnizează un volum
extins de date; conține date detaliate, dar şi date agregate, iar ca ordin de mărime
porneşte de la câțiva GB, putând ajunge la sute de TB sau mai mult. El se
implementează pe superservere performante sau pe platforme cu arhitecturi paralele.
Un depozit de întreprindere necesită cheltuieli foarte mari pentru modelare şi
perioade îndelungate (uneori chiar ani) pentru proiectare şi implementare.
Un data mart conține un subset al volumului de date din organizație, specific
unui grup de utilizatori, domeniul fiind limitat la subiecte specifice. De exemplu, un
data mart pentru marketing limitează subiectele la clienți, articole, vânzări. Datele
conținute într‐un data mart sunt de obicei agregate. Data mart‐urile sunt, în mod
curent, implementate pe servere departamentale mai ieftine care se bazează pe Unix
sau Windows. Ciclul de implementare a unui data mart este mai curând măsurat în
săptămâni decât în luni sau ani. Ca atare, un data mart poate fi considerat un
subansamblu al unui depozit de date mai uşor de construit şi întreținut şi mai puțin
scump.
Un depozit virtual (Virtual Warehouse) este constituit dintr‐un set de viziuni
(views) asupra bazelor de date operaționale. Pentru eficiența procesării
interogărilor, numai unele dintre viziunile de agregare pot fi materializate. Un
depozit virtual este uşor de construit, dar necesită capacități suplimentare pe
serverele de baze de date.

8.2.3. Analiza multidimensională

Globalizarea, evoluțiile economice tot mai dificil de anticipat, acțiunile
neaşteptate ale concurenților, schimbarea preferințelor consumatorilor, evoluțiile
tehnologice tot mai accentuate pun managerii în situații din ce în ce mai dificile în
privința adoptării unor decizii corecte, care să conducă organizațiile pe un drum
optim. Perioada empirismului în management a trecut de mult timp, însă chiar şi
tehnicile şi metodele clasice de analiză a mediului de afaceri încep să nu mai dea
rezultatele scontate. Una dintre cauzele determinante o constituie cantitatea uriaşă
de date cu care trebuie să se confrunte managerii de la diferite niveluri şi care
devine sufocantă, nepermițând decidenților să vadă esențialul problemei apărute.
Bazele de date tradiționale, în marea lor majoritate relaționale, permit
sprijinirea procesului de luare a deciziilor într‐o anumită măsură, mai ales în
privința problemelor de tip cantitativ: Care este media încasărilor lunare? Care este
primul client?
Însă economia concurențială actuală obligă managerii să rezolve mai ales
probleme de tip calitativ: De ce o parte a clienților preferă un anumit produs, iar
ceilalți nu? De ce într‐o anumită regiune campaniile promoționale nu dau rezultate?
Sistemele de prelucrare a tranzacțiilor nu au fost proiectate pentru a înlesni
rezolvarea acestui tip de probleme şi, ca urmare, nu pot furniza în timp util un
răspuns corect managerilor. Decidentul este nevoit să piardă timp pentru a deriva
informația de care are nevoie din sistemul de rapoarte pe care îl are la dispoziție, iar
cei din departamentul IT sunt nevoiți să obțină rapoarte ad hoc din sistemele
operaționale de procesare a tranzacțiilor. De cele mai multe ori, datele solicitate
pentru raportul respectiv sunt „împrăştiate” în mai multe sisteme operaționale, ceea
ce implică în prealabil integrarea lor. Întârzierile nu sunt doar consumatoare de
timp, dar pot afecta serios activitatea organizației; când raportul este în sfârşit
obținut, este posibil ca datele să fie inconsistente sau incorecte.
Între activitățile operaționale şi activitățile de luare a deciziilor la nivel
strategic există o serie de diferențe majore18, sintetizate în tabelul următor.
Organizațiile încearcă să răspundă provocărilor prin mijloace diverse, în
funcție de cultura pe care o au şi de resursele disponibile. Un curent la modă, cu
numeroase implementări practice, este cel al depozitelor de date bazate pe
conceptul de date multidimensionale. În strânsă legătură cu depozitele de date, s‐a
cristalizat modelarea multidimensională a datelor.

18 E. Thomsen, OLAP Solutions. Building multidimensional information systems, Wiley Computer
Publishing, SUA, 2000, p. 9.

Tabelul 8.4
Operaţional versus strategic

Activităţi (decizii) la nivel operaţional Activităţi (decizii) la nivel strategic
Frecvență mare Frecvență redusă
Previzibile Imprevizibile
Volum redus de date interogate Volum mare de date interogate
Necesită îndeosebi date curente Necesită date trecute, prezente şi previziuni
Puține derivări complexe Multe derivări complexe

Sistemele de procesare a tranzacțiilor folosesc de obicei standardul relațional,
bazat pe normalizare. Structurile normalizate permit sistemelor operaționale să
înregistreze şi să stocheze sute de mii de înregistrări, tranzacții individuale, fără a
exista riscul pierderii sau alterării datelor. Deşi bazele de date normalizate sunt
eficiente pentru sistemele OLTP, ele provoacă probleme atunci când sunt utilizate în
sistemele decizionale complexe. Să presupunem exemplul din figura 8.6. Dacă un
manager are nevoie de un raport cu vânzările de produse pe fiecare cumpărător în
parte, programul de interogare trebuie să acceseze tabelele Clienți, Conturi, Tip cont,
Ordine, Linii ordine, Produse, pentru a calcula totalurile dorite. Clauza WHERE din
fraza SQL va fi destul de simplă, dar foarte lungă; înregistrările din diferite tabele
trebuie să fie relaționate pentru a furniza rezultatul corect (vezi figura 8.7).

Tip cont
Clienţi Conturi Ordine
Linii ordine
Tip produs Produse

Figura 8.6. Exemplu de structură normalizată


Vânzările de produse pe clienţi
Data: 28 septembrie 2012

Client Denumire produs Valoare vânzări

Client A Produs X 3.400
Produs Y 7.600
Client B Produs X 2.000
… … …
Figura 8.7. Raportul vânzărilor de produse pe clienţi

Pentru a înlesni munca de obținere a datelor, se foloseşte modelarea
dimensională, care oferă tehnici de denormalizare a structurii bazei de date pentru
a crea scheme care sunt convenabile pentru sprijinirea procesului decizional. În
modelarea dimensională sunt utilizate două tipuri de tabele: tabele de fapte şi tabele
de căutare (tabele dimensionale).
Tabelele de fapte sunt folosite pentru a înregistra faptele reale ale afacerii.
Faptele sunt valori numerice pe care utilizatorii le analizează şi le sintetizează
pentru a înțelege mai bine diverse aspecte ale afacerii. Pentru diferite domenii de
afaceri pot fi evidențiate exemple de tabele de fapte:
comerț cu amănuntul: numărul de unități vândute, valoarea vânzărilor;
telecomunicații: durata convorbirilor în minute, numărul mediu de apeluri;
bănci: valoarea tranzacțiilor, numărul mediu de tranzacții;
asigurări: valoarea despăgubirilor;
transport aerian: prețul biletelor, greutatea bagajelor.
Tabelele de căutare (dimensionale) au rolul de a stabili contextul faptelor;
ele conțin câmpuri care descriu faptele. Din punctul de vedere al viziunii naturale pe
care o are managerul asupra faptelor, putem spune că tabelele de căutare definesc
spațiul în care se realizează orientarea. Exemple de tabele de căutare pentru aceleaşi
domenii de afaceri:
comerț cu amănuntul: denumirea magazinului, codul poştal al magazinului,
denumirea produsului, categoria produsului, ziua săptămânii;
telecomunicații: originea apelului, destinația apelului;
bănci: numele clientului, numărul contului, data, domeniul de activitate al
clientului, numele administratorului de cont;
asigurări: tipul poliței de asigurare, bunurile asigurate;
transport aerian: numărul zborului, destinația zborului, clasa de călătorie.
Când un manager cere un raport care să prezinte încasările pentru magazinul
X, în luna Y, pentru produsul Z, el foloseşte dimensiunile Magazin, Timp şi Produs
pentru a descrie contextul încasărilor (faptele).
Vizual, o schemă multidimensională are o arhitectură de tip stea, în care
tabelele de fapte se află în centru, iar tabelele de căutare sunt dispuse în jurul lor. În
figura 8.8, dimensiunile sunt Client, Timp, Produs şi Magazin. Câmpurile din aceste
tabele sunt folosite pentru a descrie faptele din tabela de fapte Vânzări.


Figura 8.8. Exemplu de arhitectură tip stea

Unul dintre principiile‐cheie ale modelării multidimensionale este folosirea
tabelelor de fapte în formă normalizată, împreună cu tabelele de căutare în formă
denormalizată. În exemplul din figura 8.8, datorită faptului că tabelele de căutare
sunt denormalizate, schema nu mai cuprinde şi alte tabele. În contrast, o dimensiune
Produs pe deplin normalizată au tabelele adiționale din figura 8.9.

Grupa Subgrupa Categorie Produs
produs produs produs

Figura 8.9. Tabele Produs normalizate

Tabelele normalizate sunt cauza dificultății cu care un utilizator navighează
prin ele pentru a găsi informațiile de care are nevoie. Prin denormalizarea
dimensiunilor, printr‐o singură tabelă, utilizatorul găseşte informațiile dorite. Ca
rezultat al denormalizării dimensiunilor, fiecare dimensiune va conține ierarhii
care implică gruparea şi structurarea. După cum se arată în figura 8.10, dimensiunea
Timp are o ierarhie ZiLunăTrimestruAn. Similar, dimensiunea Magazin are ierahia
OraşJudeţRegiuneTotal magazine, iar dimensiunea Produs are ierarhia Produs
Categorie produsGrupă produsTotal Produse.

Figura 8.10. Ierarhii dimensionale

Când utilizatorii depozitului de date navighează prin el pentru a afla informații
cu diferite niveluri de detaliere, ei de fapt se poziționează la un anumit nivel din
fiecare ierarhie. De exemplu, un utilizator poate să dorească inițial un raport al
vânzărilor cu totalul vânzărilor pentru fiecare regiune în fiecare an. Pentru un astfel
de raport, utilizatorul se poziționează la nivelul 1 al ierarhiei Timp, la nivelul 2 al
ierarhiei Magazin şi la nivelul 1 al ierarhiei Produs (vezi figura 8.11).

Figura 8.11. Interogare prin poziţionare în cadrul ierarhiilor

În urma interogării prin poziționare în cadrul ierarhiilor se poate obține uşor
raportul dorit, ilustrat în figura 8.12.

Figura 8.12. Raport obţinut prin poziţionarea în cadrul ierarhiilor

Gradul de detaliere poate fi modificat prin operațiunile de drilldown (mai
analitic) sau drillup (mai sintetic). De exemplu, prin drilldown efectuat asupra
dimensiunii Timp se poate obține un raport detaliat pe trimestre (vezi figura 8.13).

Figura 8.13. Raport obţinut prin operaţiunea drilldown

Un aspect important îl reprezintă gradul de granularitate, care indică nivelul
de detaliere stocat în tabela de fapte. Granularitatea tabelei de fapte depinde direct
de gradul de detaliere pe care îl au dimensiunile sale. De exemplu, dacă fiecare
înregistrare Timp reprezintă o zi, fiecare înregistrare Produs reprezintă un produs şi

fiecare înregistrare Magazin reprezintă un magazin, atunci „granula” tabelei de
fapte Vânzări, care are dimensiunile menționate, este: vânzări pe produs pe zi pe
magazin. Faza de analiză a granularității unui depozit de date trebuie să fie efectuată
foarte atent, deoarece o granularitate la un nivel prea sintetic nu permite obținerea
de informații suplimentare, în timp ce o granularitate accentuată, cu detaliere
pronunțată, poate creşte exponențial spațiul ocupat de depozitul de date.
Agregarea este unul dintre cele mai importante concepte din lumea depozitelor
de date. Utilizarea corectă a agregărilor conduce la o creştere importantă a
performanțelor depozitului de date în privința timpului de răspuns la interogări. O
agregare este o valoare precalculată stocată în depozitul de date, de obicei într‐o
schemă separată. Calculul valorilor agregate se face pe baza valorilor de la nivelul cel
mai analitic (în exemplul nostru, nivelul 4 la fiecare dimensiune, cu valorile: Zi, Oraş,
Produs). Avantajul agregării constă în faptul că utilizatorul, pentru a obține informații
cu caracter sintetic, poate lansa interogări asupra valorilor agregate, în loc să solicite
sistemul cu interogări la nivelul înregistrărilor elementare.
Agregările au mai puține înregistrări decât schemele care conțin nivelurile de
bază. În exemplul nostru, se iau în considerare Timp, Produs, Magazin şi următoarele
caracteristici:
granula tabelei de fapte este Produs pe Magazin pe Săptămână;
sunt zece Magazine;
sunt 100 de Produse pentru fiecare Marcă;
există cel puțin o Vânzare pe Produs pe Magazin pe Săptămână.
Pe baza acestor premise putem calcula numărul de înregistrări de fapte care
sunt necesare pentru fiecare interogare:

Dacă o interogare necesită… Atunci trebuie manipulate
un Produs, un Magazin, o Săptămână doar o înregistrare din schemă
un Produs, Toate magazinele, o Săptămână 10 înregistrări din schemă
un Marcă, un Magazin, o Săptămână 100 înregistrări din schemă
un Marcă, Toate magazinele, un An 52.000 înregistrări din schemă

Dacă agregările ar fi calculate şi stocate astfel încât fiecare înregistrare
agregată ar conține faptele pentru o marcă pe magazin pe săptămână, a treia
interogare din cele de mai sus ar necesita doar o înregistrare în loc de 100. În mod
similar, a patra interogare ar necesita doar 520 de înregistrări în loc de 52.000.
Câştigul de timp obținut este evident.
Un depozit de date poate conține simultan mai multe scheme de tip stea, adică
mai multe tabele de fapte. Fiecare schemă este proiectată pentru a servi un anumit
necesar informațional. De asemenea, este firesc ca o dimensiune (tabelă de căutare)
să fie folosită în mai multe scheme de tip stea.
În concluzie, se poate spune că modelarea multidimensională oferă câteva
concepte puternice care îi conferă o serie de calități care o vor promova în sistemele
moderne de sprijinire a proceselor decizionale:
este simplă. Oferă posibilitatea proiectanților de depozite de date să
creeze scheme pe care utilizatorii să le poată înțelege şi controla uşor. Nu este
necesar un efort mare pentru a învăța cum se citesc diagramele, deoarece
dimensiunile imită perfect viziunea multidimensională pe care utilizatorii o au
asupra afacerii;
promovează calitatea datelor. Schemele de tip stea păstrează integritatea
referențială în interiorul depozitului de date, prin modul de concepere a cheii tabelei
de fapte;
asigură optimizarea performanţelor prin agregare. Pe măsură ce
mărimea depozitului creşte, răspunsurile la interogări se obțin tot mai greu.
Agregările reprezintă una dintre cele mai la îndemână modalități de a creşte
performanța sistemului de interogare.

8.2.4. Tehnologii OLAP

În anul 1993, E.F. Codd, creatorul modelului relațional pentru bazele de date, a
introdus termenul OLAP (On Line Analytical Processing)19. Codd considera la acel
moment că bazele de date relaționale folosite pentru a gestiona procesarea
tranzacțiilor şi‐au atins performanța maximă în ceea ce priveşte dimensionalitatea
viziunilor asupra datelor disponibile pentru utilizatorul final. El a concluzionat că
datele operaționale şi implicit bazele de date operaționale pur şi simplu nu erau
potrivite pentru a răspunde întrebărilor din categoria celor adresate de regulă de
manageri.
Tehnologia OLAP presupune oferirea de posibilități multiple în ceea ce
priveşte manipularea analitică a datelor (tabele, grafice, sintetizări, analize etc.) şi se
bazează de regulă pe utilizarea unui depozit de date în format multidimensional.
Principalele operațiuni OLAP necesare unui decident sunt următoarele20:
drillup;
drilldown;
dice;
slice;
pivot (rotate).
Operațiunea drillup, denumită şi rollup de unii producători, execută agregări
pe cubul de date, prin escaladarea ierarhiei pentru o dimensiune sau prin reducerea
dimensiunii. Când drillup este executat prin reducerea dimensiunii, unul sau mai
multe niveluri ierarhice sunt şterse din dimensiune. Drilldown este opusul
operațiunii drillup; parcurgerea ierarhiei se face de la cel mai puțin detaliate
niveluri până la cele mai detaliate (analitice). Drilldown poate fi realizat prin
parcurgerea descendentă a ierarhiei pentru o dimensiune sau prin introducerea de
dimensiuni suplimentare.

19 Observații preluate din G. Marakas, Decision Support Systems in the 21st Century, 2nd Edition, Prentice
Hall, New Jersey, 2003, pp. 329‐330.
20 D. Airinei, op. cit., pp. 51‐56.

Operațiunea slice execută o selecție pe o dimensiune a unui cub dat, rezultând
un subcub, în timp ce dice defineşte un subcub prin mai multe dimensiuni. Pivot
(rotate) este o operație care roteşte axele de vizualizare a datelor în ordinea cerută
de alternativa prezentării lor.
Analizând operațiile principale definite de conceptul OLAP, opinia noastră este
că, la ora actuală, dată fiind eterogenitatea surselor de date (audio, video, text, web,
dispozitive mobile), din punctul de vedere al utilizatorului, este mai puțin important
mediul de stocare a datelor sau tipurile de structuri de date pe care se mapează
interfața utilizator. Aşadar, considerăm că tehnologia OLAP trebuie să se refere cu
precădere la posibilitatea implementării în interfeţele grafice a elementelor adecvate
utilizatorilor de sisteme de asistare a deciziilor. Cu alte cuvinte, predominante pentru
tehnologia OLAP vor fi bibliotecile de controale vizuale capabile să execute în mod
eficient operaţiunile descrise anterior. Gridurile adaptabile, combo‐box‐urile
dinamice, tehnologia ajax, graficele multidimensionale controlabile de utilizator,
precum şi sistemele de prelucrare a vocii decidentului, vor constitui cu siguranță
miezul OLAP‐ului în următoarea perioadă de timp.
De regulă, instrumentele OLAP sunt incluse în produse de generare a
interogărilor şi rapoartelor şi extrag datele primare dintr‐un depozit de date. Într‐o
astfel de arhitectură (vezi figura 8.14), scopul depozitului de date este să integreze
datele din surse eterogene: baze de date operaționale, sisteme moştenite, baze de
date de pe web, baze de date publice. O altă posibilitate este ca aplicația să aibă un
modul OLAP special pentru generarea interogărilor care sunt apoi transmise unui
generator de rapoarte.

Sisteme
moştenite
Interogãri
OLAP
Extragere & integrare
Date
publice
Rapoarte
OLAP &
DEPOZIT DE Server
Sursã grafice
Baze de date DATE raport
operaţionale
Baze de
Rezultate
date web (dataseturi)

Sursa: Kimball, R., Ross, M., The Data Warehouse Toolkit, John Wiley & Sons, 2002, p. 67.
Figura 8.14. Arhitectură OLAP bazată pe depozit de date

Un sistem de asistare a deciziilor trebuie să ofere managerilor mai multă
informație decât există deja în depozitul de date. Instrumentele de tip data mining
sunt incluse într‐o clasă care oferă posibilități de descoperire automată a cunoaşterii
şi permit evidențierea informațiilor ascunse. Analistul uman este ajutat să înțeleagă
datele prin descoperirea unor modele, reguli şi relații care în mod normal nu sunt
vizibile în datele depozitului. Metodele de tip data mining pot fi clasificate în câteva
categorii de bază21:
asocieri, care sunt folosite pentru a descoperi reguli de comportament în
marketing (de exemplu, dacă un client cumpără bere, atunci probabilitatea de a
cumpăra şi cârnați este de 35%);
clustering, care este folosit pentru a grupa datele şi a reuşi construirea sau
evidențierea de noi clase specifice;
similarităţi pentru serii de timp, care presupun găsirea secvențelor
similare în serii de timp (această metodă este folosită mai ales pentru evidențierea
sezonalității în diverse domenii de interes pentru decident);
modelare secvenţială, care combină avantajele asocierilor cu cele ale
similarității seriilor de timp;
detectarea deviaţiilor, care constă în evidențierea anomaliilor din seturile
de date şi eventual a cauzelor care au determinat aceste anomalii.
Data mining este un concept complex bazat pe tehnici şi metode din diverse
domenii de studiu: statistică, sisteme de gestiune a bazelor de date, depozite de date,
modelare matematică, recunoaşterea modelelor etc. În literatura de specialitate se
consideră că folosirea data mining presupune analiza şi explorarea datelor22.
Utilizatorul are nevoie să „traverseze” în mod flexibil printr‐o bază de date, să
selecteze orice porțiune relevantă din datele existente, să le analizeze la diferite
grade de granularitate şi să prezinte rezultatele în formate diverse.
Astfel, prin combinarea celor două concepte referitoare la depozite de date şi
la OLAP, obținem un nou concept deosebit de puternic: OLAM, ceea ce înseamnă On
Line Analytical Mining. Adeseori este foarte dificil de previzionat de ce fel de
cunoaştere va avea nevoie utilizatorul. Prin integrarea tehnologiilor OLAP cu
funcționalitățile oferite de conceptul data mining, OLAM oferă flexibilitate pentru
utilizatori să selecteze funcțiile data mining şi să efectueze în mod dinamic
„mineritul datelor”.
Pentru sistemele de asistare a deciziilor, o arhitectură mai completă trebuie să
conțină şi un modul de tip data mining care să fie capabil să comunice cu un server
OLAP şi cu un depozit de date, ca în figura 8.15.

21 http://otn.oracle.com/products/oracle9i/htdocs/o9idm_faq.html, http://research.microsoft.com/dmx/,
http: //courses.cs.deu.edu/cse572/presentations/
22 J. Han., M. Kamber, op. cit., 2001, p. 48.

Interfaţa utilizator
OLAP Componentã
Server Data Mining
Depozit de date
Sursa de Sursa de Sursa de

date 1 date 2
... date n

Figura 8.15. Arhitectura OLAM

Într‐o astfel de arhitectură, componenta data mining se comportă ca o bază de
modele: în funcție de alegerea utilizatorului, date din depozitul de date sunt
procesate în conformitate cu modelul de analiză curent selectat şi rezultatele sunt
apoi prezentate prin intermediul unei interfețe vizuale. Se observă că utilizatorul
poate să interogheze depozitul de date în mod direct, prin serverul OLAP, iar
serverul accesează apoi modele corespunzătoare stocate în modulul OLAM. În final,
rezultatul vine de la componenta data mining, care a fost aplicată datelor din OLAP.
Avantajul conceptului OLAM provine din faptul că decidentul poate folosi
oportunitățile OLAP cu noua cunoaştere oferită de tehnicile data mining. Problema
existentă la ora actuală în piața produselor de acest gen este că producătorii nu
agreează un model standard; fiecare companie doreşte să implementeze propria
arhitectură şi propria tehnologie şi în felul acesta este foarte dificil de obținut un
standard OLAM. Piața produselor care sunt comercializate şi folosite ca instrumente
OLAM este dominată în prezent de mărcile prezentate în tabelul 8.5.
Tabelul 8.5
Produse OLAM

Producător Denumire produs
Oracle Corporation Darwin
Microsoft SQL Analysis Manager
IBM Intelligent Miner
SurfAid Analysis
SPSS Inc Clementine
Cognos (Oracle) Scenario
Salford Systems MARS
CART
SAS Institute Inc. Enterprise Miner
Deşi tehnologiile depozitelor de date şi OLAP sunt relativ noi, ele tind să se
combine, astfel încât rezultatul obținut să fie mai puternic decât suma părților.
Conceptul OLAM este deja implementat într‐o serie de produse software, dar un
standard uniform încă nu există din pricina intereselor comerciale şi complexității
domeniului. Considerăm că viitorul apropiat va transforma OLAM într‐o tehnologie
cu adevărat matură şi utilă pentru manageri şi organizații.

8.3. Câteva consideraţii privind implementarea sistemelor
Business Intelligence

Ținta inteligenței economice nu este limitată la companiile mari, ci include la
fel de bine firmele mici şi medii: oricine are nevoie de informații de calitate la
momentul oportun. Există pe piața aplicațiilor marii jucători, care se adresează
clienților mari, dar şi furnizori de soluții pentru firmele mijlocii şi mici, precum şi
oferte de instrumente de analiză pentru diverse funcțiuni, ca alternativă la BI, care
acoperă întreg spectrul funcțional al organizației23.
Spre deosebire de tradiţionalul ERP, aplicaţiile de Business Intelligence oferă un
mediu în care utilizatorii primesc mai uşor informaţiile dorite, corecte, consistente şi
pe înţelesul lor. Nevoia de a înțelege dincolo de cifrele din rapoarte şi de a explica
anumite situații, bune sau rele, este acoperită de BI, aplicații care s‐au dovedit nici
scumpe, nici greu de implementat, devenind o necesitate pentru procese decizionale
întemeiate.
Dacă în cazul ERP sau CRM, aria utilizatorilor este destul de clară, în cazul BI
se pune întrebarea despre categoriile de utilizatori care ar avea nevoie sau ar
beneficia de pe urma acestor aplicații. În tabelul 8.6 sunt corelate instrumentele şi
aplicațiile BI, cu toate tipurile posibile de utilizatori dintr‐o firmă.
Tabelul 8.6
Utilizatorii BI

Categorii de Număr de Valoare

Instrumente şi aplicaţii BI
utilizatori utilizatori strategică
IT Câțiva Dezvoltare de aplicații, definire metadate, Mare
managementul datelor, securitate
Utilizatori Zeci Interogări ad hoc, rapoarte OLAP, data Mare
specialişti mining, analize multidimensionale
Manageri Zeci Rapoarte, foi de calcul, vederi OLAP, Medie
funcționali business activity monitoring, business
performance management
Top‐manageri Câțiva Tablou de bord, BSC (balanced Mare
scorecard), rapoarte personalizate,
business performance management
Utilizatori Sute/mii Rapoarte, foi de calcul Scăzută
ocazionali

23 O.
Thompson, „BI Approaches of Enterprise Software Vendors”, 2004, disponibil la http://www.
technologyevaluation.com/research/articles/bi‐approaches‐of‐enterprise‐software‐vendors‐17218/

Categorii de Număr de Valoare

Instrumente şi aplicaţii BI
utilizatori utilizatori strategică
Parteneri şi Sute/mii Rapoarte Mare
clienți
Sursa: Adaptare după Turban, E., s.a., Decision Support and Business Intelligence Systems, Pearson
Education, New Jersey, 2007, p. 197.

Aşa cum se observă din tabelul 8.6, implementarea unui BI poate atrage
utilizatori de toate tipurile (într‐o clasificare exotică, Imhoff şi Pettit24 identifică
următoarele categorii: fermieri, turişti, operatori, exploratori şi mineri), unii
orientați spre arii operaționale, alții, către cele strategice.
Pe lângă selectarea celui mai potrivit produs, succesul unui proiect BI depinde
de mai mulți factori interni, care țin de politica firmei. Deşi implementarea
produsului la nivelul unui singur departament este mai simplă, sistemele fragmen‐
tate ce rezultă vor fi dificil de integrat mai apoi. În plus, experiența demonstrează, ca
în cazul altor tipuri de aplicații de întreprindere, valoarea superioară a proiectelor
interdepartamentale, față de cele de la nivelul unui singur departament.
De asemenea, succesul proiectului depinde esențial de măsura în care este
urmărit interesul utilizatorilor: aplicațiile trebuie să răspundă nevoilor acestora şi
să fie uşor de utilizat.
Criteriile cel mai frecvent luate în discuție la alegerea produsului sunt:
funcționalitatea;
integrarea cu aplicațiile existente;
uşurința de utilizare pentru utilizatorul final;
prețul;
performanțele;
facilitățile de creare de noi aplicații.
BI valorifică avantajul aplicațiilor de întreprindere (ERP, CRM, SCM) deja
instalate, ceea ce maximizează beneficiile investițiilor IT. BI extrage informațiile
prețioase din bazele de date tranzacționale ale firmei. Marile companii, care au
investit enorm în construirea de depozite de date, pot face pasul următor prin
implementarea unui sistem BI, care desăvârşeşte eforturile investiționale.

Următorul studiu de caz se referă la un operator de telecomunicaţii lider mondial, cu peste 91
de milioane de clienţi, prezent în 220 de ţări, pe cinci continente. Această organizaţie are
190.000 de angajaţi şi oferă o gamă completă de servicii de telecomunicaţii: locale,
internaţionale, telefonie mobilă, internet şi multimedia, transport de date şi transmisie TV
prin cablu.
De câţiva ani, organizaţia a folosit sistemul informaţional ca o armă strategică importantă în
lupta cu alţi operatori de telecomunicaţii. Una dintre iniţiativele majore a fost reducerea

24 C. Imhoff, R. Pettit, „The critical shift to flexible Business Intelligence”, Intelligent Solutions, 2004, p. 32.
inconsistenţei datelor şi distribuirea informaţiei mult mai eficient în diferite zone ale
organizaţiei, prin implementarea de standarde pentru administrarea programelor
informatice. Soluţiile software alese au fost: BusinessObjects, pentru extragerea şi analiza
datelor, aplicaţii Oracle, pentru financiarcontabilitate, PeopleSoft CRM şi Genesys, pentru
CRM, PeopleSoft HR, pentru resurse umane, webMethods, pentru aplicaţii globale integrate
şi Documentum, pentru administrarea documentelor.
În prima fază, implementarea BI sa realizat la nivel de departamente, fiind iniţiate peste 140
de proiecte cu produse BusinessObjects. Topmanagerii au înţeles că procesele de business
intelligence joacă un rolcheie în extragerea şi analizarea datelor din resursele corporaţiei.
Dezvoltarea unei platforme de BI la nivelul întregii companii a fost o decizie firească.
Compania a ales tot Business Objects ca standard BI corporativ şi a semnat un contract pentru
70.000 de licenţe, pentru a fi implementate în toate ariile organizaţiei: resurse umane,
management financiar, marketing, vânzări şi distribuţie. Două dintre motivele importante
pentru care sa ales Business Objects au fost gradul înalt de implementare în cadrul
organizaţiei şi satisfacţia utilizatorilor în folosirea sa.
Odată cu decizia de a realiza standardizarea cu Business Objects, cheia succesului acestui
proiect a constat în calitatea suportului oferit managerilor de proiect şi utilizatorilor. A fost
creat un centru de excelenţă în BI format din patru persoane, responsabile să supervizeze
implementările de BI. Este datoria lor să asigure şi să păstreze consistenţa proiectelor care
implică soluţii de BI şi să se asigure de fiecare dată că echipe diferite împărtăşesc cele mai
bune practici.
Lecţiile învăţate: nevoia de pragmatism şi de comunicare puternică. Pragmatismul a constat
în punerea în valoare a celor 140 de implementări de BI existente în cadrul companiei, care,
asociat cu gradul înalt de satisfacţie a utilizatorilor, a crescut considerabil şansa de succes a
proiectului de standardizare BI. Iar o comunicare puternică a fost necesară pentru a
convinge executivul că proiectul este util şi reprezintă o oportunitate pentru ei.
Beneficiile. Compania are acum un mediu de lucru standard carei acoperă toate nevoile de BI.
Compania a realizat economii la taxele pentru licenţe rezultate din achiziţia la nivel de
corporaţie, şi nu pe fiecare proiect în parte. Alegerea unei singure soluţii de BI a permis
reducerea substanţială a costurilor legate de instruirea şi suportul utilizatorilor.
Dezvoltarea profesională a devenit mai uşoară datorită folosirii aceloraşi instrumente în
diferite zone ale organizaţiei, iar aplicaţiile au devenit mai uşor de implementat, de
upgradat şi de întreţinut, rezultând economii de timp şi bani.
(Sursa: http://www.businessobjects.ro/produs_detail.php?id=37)

Totuşi, nu dorim să se înțeleagă de aici că implementarea unui BI este o
decizie uşoară, bazată pe enunțarea unui set coerent de avantaje indubitabile.
Practicienii şi consultanții din sfera BI recomandă şi aici utilizarea unei metodologii
de implementare (una dintre cel mai bine apreciate este cea propusă de Gartner 25).
Aceasta descompune activitățile de planificare şi execuție la nivel de organizație,
afacere, funcționalități şi componente de infrastructură. La nivelul afacerii şi al
organizației, se porneşte de la obiectivele strategice şi tactice ale implementării,
pentru a stabili dacă există competențele şi infrastructura necesare atingerii acelor

25
Inc. Gartner, Using Business Intelligence to gain a competitive edge. A special Report, 2004,
www.gartner.com

obiective. Top‐managerilor le revine sarcina de a armoniza cultura organizațională

cu inițiativa BI, pentru a sădi entuziasmul necesar succesului acestui proiect.
Un alt aspect fundamental pentru succesul unei implementări BI este
integrarea acestuia în sistemul informatic al organizației, în care există deja alte
aplicații şi sisteme: diverse baze de date, suite ERP, aplicații CRM sau SCM, aplicații
moştenite, aplicații e‐business – toate furnizoare de date pentru noul sistem BI.
Situația în care toate aplicațiile (sau majoritatea) provin de la un singur furnizor este
cea mai fericită din punctul de vedere al efortului de integrare.
Nu în ultimul rând, o chestiune spinoasă, mult disputată, este cea a utilizării
efective a aplicaţiilor de BI implementate. Există o diferență uriaşă între
prognoza de utilizare a tehnologiilor BI şi folosirea lor efectivă. Se reproşează
adesea lăsarea „pe dinafară” a utilizatorilor obişnuiți, iar cauzele identificate26 sunt:
dificultatea de a utiliza datele furnizate;
lipsa de timp a utilizatorilor obişnuiți pentru a‐şi dezvolta abilitățile la un
nivel mai ridicat decât cel rudimentar;
nivelul de educație tehnologică al utilizatorilor este limitat;
furnizorul de soluții BI a exagerat în privința uşurinței de utilizare a soluției
implementate;
instruirea a fost prea puțină, inadecvată, fără sprijin din partea organizației
(cum ar fi centrul de competență în BI);
problemele de afaceri sunt prea complexe pentru utilizatorul obişnuit.
Utilizarea „pe scară largă” a aplicațiilor BI presupune o abordare diferită de
cea din proiectele mici, departamentale. Ea cere o abordare holistică, obiective
stabilite la nivel de organizație şi depunerea de eforturi pentru crearea unei
infrastructuri BI de care să beneficieze toată lumea.
Nu toate inițiativele de tip BI sunt realizate cu succes, iar cele care sunt sortite
eşecului aduc pierderi însemnate organizațiilor. Ca orice proiect de anvergură, şi
acesta comportă anumite riscuri. Riscurile tipice unui proiect de implementare a
unei soluții Business Intelligence bazate pe tehnologia depozitelor de date sunt
prezentate în continuare.
Riscurile organizaţionale. Susținătorii proiectului trebuie să provină din
zona conducerii strategice a afacerii, şi nu din zona strategică IT. Având în vedere
dimensiunea şi scopul, o inițiativă Business Intelligence trebuie să fie orientată pe
afacere, altfel organizația va considera întregul efort ca fiind un experiment
tehnologic. Susținătorul proiectului trebuie să fie o persoană care va utiliza
depozitul de date şi care îşi poate asuma responsabilitatea inițiativei. Riscurile
organizaționale provin şi de la utilizatorii finali care pot obstrucționa, intenționat
sau nu, evoluția proiectului. În funcție de cunoştințele tehnice pe care le au şi de
cultura organizațională, utilizatorii trebuie abordați cu atenție în toate fazele
proiectului.

26 M. Biere, The New Era of Enterprise Business Intelligence: Using Analytics to Achieve a Global
Competitive Advantage, IBM Press, 2010, p. 15.
Riscurile tehnologice. În această categorie se încadrează folosirea inadecvată
a tehnologiilor data warehouse, calitatea scăzută a sistemelor operaționale
existente, instrumente nepotrivite pentru utilizatorul final. Folosirea inadecvată a
tehnologiilor depozitelor de date apare atunci când se încearcă utilizarea lor în
scopul rezolvării problemelor operaționale ale organizației sau pentru a se
implementa soluții în timp real. De asemenea, utilizarea mai multor minidepozite de
date disparate nu poate constitui un factor de succes sigur, deoarece sistemul
informațional din cadrul organizației trebuie să funcționeze într‐un cadru unic.
Calitatea scăzută a sistemelor operaționale poate determina echipa de dezvoltare a
depozitului de date să‐şi concentreze atenția mai mult pe „curățarea” şi verificarea
datelor de intrare, neglijând esențialul depozitului de date. În acelaşi timp, un sistem
operațional defectuos va ridica probleme la extragerea, transformarea şi încărcarea
datelor în depozitul de date. Utilizatorii potențiali ai depozitului de date nu‐l vor
apela dacă informațiile pe care le oferă sistemul sunt eronate sau dubioase. Ceea ce
contează foarte mult este percepţia asupra calității datelor, indiferent dacă datele
sunt corecte sau nu. În fine, oferta largă de instrumente pentru utilizatorii finali
trebuie bine analizată înainte de a decide ce instrument va folosi fiecare categorie de
utilizatori.
Riscuri legate de managementul proiectului. Unul dintre aceste riscuri este
determinat de definirea nerealistă a anvergurii proiectului. Literatura de specialitate
recomandă ca un astfel de proiect să înceapă cu o etapă‐pilot şi apoi depozitul de
date să fie dezvoltat incremental. Specialiştii consideră că organizațiile care mizează
pe proiecte monolitice de amploare foarte mare vor întâmpina dificultăți în
gestionarea situațiilor care apar şi vor avea şanse foarte mici de a termina cu bine
ceea ce au început. În contrast, dezvoltarea incrementală reduce riscurile şi
minimizează pierderile.
Multe proiecte data warehouse au eşuat din cauza subestimării timpului
necesar operațiunilor de extragere, integrare şi transformare a datelor. Deşi poate
părea neobişnuit, este realist ca pentru aceste operațiuni să se aloce un timp
important din durata întregului proiect. Practica a dovedit că pentru operațiunile
back‐end (extragere, integrare, verificare calitate, agregare, încărcare) trebuie să se
aloce între 60 şi 80% din durata proiectului, iar pentru operațiunile front‐end
(instrumente OLAP, rapoarte, interogări), între 20 şi 40% 27. Echipa de dezvltare
trebuie să se concentreze atent pe partea de back‐end, deoarece pe ea se sprijină
cealaltă componentă, care nu poate fi implementată până când nu este funcțională
prima.
Managementul proiectului trebuie să se preocupe şi de ceea ce se întâmplă
dincolo de implementarea depozitului de date: utilizatorii noi care au acces la
funcționalitățile depozitului trebuie instruiți, utilizatorii vechi trebuie înştiințați
despre modificările care apar şi, de asemenea, se recomandă monitorizarea
activității depozitului de date în primul an (contorizare înregistrări frecvente,

27 M. Humpries, M. Hawkins, M. Dy, op. cit., p. 65.

statistici despre căutările care se efectuează) pentru a optimiza structura şi
interogările.
Riscuri legate de proiectarea depozitului de date. Echipa tehnică trebuie să
fie bine pregătită, iar experiența din zona bazelor de date se poate dovedi inutilă. În
timp ce sistemele OLTP relaționale mizează pe normalizarea relațiilor şi pe înregis‐
trarea eficientă a tranzacțiilor, depozitul de date trebuie gândit ca un cub de date
multidimensional care conține tabele denormalizate, agregări, variabile etc. O greşeală
frecventă care se face constă în alegerea greşită a gradului de granularitate. Depozitul
de date conține atât date atomice, cât şi date sintetice. O granularitate prea mare nu
permite obținerea rapoartelor detaliate de care au nevoie managerii, în timp ce un
grad scăzut de granularitate conduce la necesitatea efectuării unui număr mare de
agregări şi la capacități sporite de stocare.

8.4. Oferta de soluţii Business Intelligence

Piața de aplicații business intelligence a trecut prin transformări importante în
ultimii patru ani, cea mai notabilă fiind consolidarea ei. Dacă în primii ani ai lansării
acestor soluții vorbeam despre o piață fragmentată între numeroşi furnizori mici,
specializați şi independenți, astăzi avem una dominată de cei patru fantastici: SAP,
Oracle, IBM şi Microsoft (în unele prezentări se vorbeşte despre The Big Five, care
adaugă în top şi SAS Institute – cei cinci dețin peste 75% din piața BI).

8.4.1. Principalii ofertanţi

Business Objects, Cognos, Hyperion, SAS şi MicroStrategy au creat primele
aplicații de BI, le‐au perfecționat de‐a lungul anilor (toți având cel puțin 15 ani pe
piața BI în anul 2007) şi au dominat piața de BI la începutul anilor 200028. Doar SAS
şi MicroStrategy au rezistat asaltului marilor case de software şi au rămas furnizori
independenți.
Business Objects era în 2005 o companie cu o cifră de afaceri de un miliard
de dolari care opera exclusiv în domeniul BI. Deşi are un nume pur englezesc,
compania este de origine franceză, fiind înființată la Paris, în 1990. Primul său client
mare a fost France Telecom, iar în 1994 era prima companie franceză listată la bursa
din New York. Platforma ei de BI se numeşte BusinessObjects şi a cunoscut
numeroase versiuni de la lansarea în 1994. BusinessObjects XI este o suită completă
de BI, de la raportare şi interogare, la facilități avansate de management al
performanței. BO are 46.000 de clienți în întreaga lume. Peste 80% dintre
companiile din topul „Fortune 500” sunt clienți Business Objects. Pe 7 octombrie
2007, SAP AG a anunțat achiziția BO, pentru 6,8 miliarde de dolari. Business Objects
a devenit o divizie SAP, iar numele platformei a devenit „SAP BusinessObjects”. Prin
această mişcare, SAP a devenit numărul 1 mondial şi pe piața BI.

28 Business Objects, Cognos, Hyperion au format topul primilor trei furnizori de soluții BI în perioada
2000‐2005.
Hyperion Solutions a fost o companie americană care a activat predilect în

zona aplicațiilor de Business Process Management, având şi celelalte aplicații pentru
o platformă completă de BI. Anul 2007 i‐a adus recunoaşterea Gartner, care a
plasat‐o în cadranul de lideri, dar a însemnat şi sfârşitul unei epoci, deoarece la 18
aprilie 2007 s‐a finalizat achiziția ei de către Oracle, pentru 3,3 miliarde de dolari.
Spre deosebire de cazurile SAP şi IBM, Oracle are propria ofertă de soluții BI
(Oracle BI Suite Enterprise Edition şi multe pachete de aplicații analitice cu
specializare funcțională – de exemplu, Oracle Sales Analytics), fiind liderul
incontestabil al pieței depozitelor de date. Marele avantaj vine din faptul că soluțiile
sale BI se integrează cu orice sistem de baze de date din lume, în firme de orice
dimensiune. Succesul său în domeniul BI este evident: zece din primele zece bănci
din lume, 20 din primele 20 de companii de telecomunicații şi zece din primele zece
universități din lume sunt clienți Oracle.
Cognos a fost o companie canadiană, cu vechime pe piața aplicațiilor pentru
afaceri (1969). În cea mai bună perioadă a sa avea 3.500 de angajați şi 23.000 de
clienți în întreaga lume, iar cifra de afaceri se apropia de un miliard de dolari în
2007. Pe 31 ianuarie 2008 s‐a finalizat achiziția de către IBM pentru suma de 4,9
miliarde de dolari, marcând înfrângerea ultimei redute de software BI
independent29. Cognos a devenit parte a diviziei IBM Information Management.
Ultima versiune lansată (2005) este Cognos 8, la care s‐a adăugat, din 2009, Cognos
Express, un pachet integrat de planificare şi analiză gândit special pentru firmele
medii.
În ianuarie 2010, IBM a finalizat reorganizarea pe zona de software, creând o
nouă divizie denumită Business Analytics, care include ofertele Cognos şi cele de
programe de analiză statistică SPSS, deoarece în iulie 2009 IBM a cumpărat şi SPSS
Inc. pentru 1,2 miliarde de dolari.
SAS Institute este un producător de software cu vechime pe piața americană
(1976), fiind inițial orientat spre dezvoltarea de sisteme de analiză statistică. Astăzi,
oferta sa de aplicații depăşeşte cu mult aceste limite, dar a preferat să mențină
numele, care a căpătat notorietate în urma succesului primelor programe statistice.
SAS este lider incontestabil pe domeniul aplicațiilor analitice (business analytics) şi
este cel mai mare furnizor independent din sfera BI. Are peste zece mii de angajați
(fericiți, se pare, căci în 2010 SAS a fost pe primul loc în clasamentul „100 Best
Companies to Work For”, realizat de revista Fortune Magazine) şi peste 45.000 de
clienți în peste 100 de țări (91 dintre primele 100 de companii din topul 2010
FORTUNE Global 500 folosesc aplicații SAS).
Cu zece ani în urmă, Microsoft a revoluționat aplicațiile BI30, făcând
instrumentele OLAP şi data mining accesibile profesioniştilor IT direct în bazele de

29 Este bine de ştiut că aceste mişcări de fuziuni şi achiziții au avut loc permanent pe piața BI, dar la
valori mult mai mici decât cele trei achiziții de răsunet. Însuşi Cognos este campion la cumpărarea de
firme mici: 4Thought, Relational Matters, LEX2000, Interweave, DecisionStream, NoticeCast, Adaytum,
Frango, Databeacon şi Celequest, iar în 2007 a cumpărat Applix, un jucător mai mare de pe piața BI
(vezi detalii la http://www.bi‐verdict.com/fileadmin/FreeAnalyses/ consolidations.htm).
30 Vezi mai multe detalii la http://en.wikipedia.org/wiki/Microsoft_Analysis_Services

date relaționale (OLAP Services, inclus în SQL Server 7). Platforma sa de BI31 se
bazează pe SQL Server, Microsoft Office şi SharePoint pentru infrastructura întregii
platforme, iar strategia sa actuală32 este răspândirea Business Intelligence în întreaga
organizație. Un Business Intelligence invaziv, care este disponibil tuturor, va fi oferit
printr‐o suită bazată pe instrumentele cu care utilizatorii sunt obişnuiți zi de zi
(Office) şi nu o suită cu instrumente specializate, care să necesite o nouă instruire.
Concret, această ofertă poartă numele Microsoft Dynamics GP Business Intelligence.
Dezvoltarea platformei Microsoft BI se face într‐o echipă virtuală, din care fac
parte lideri şi dezvoltatori de Office, SharePoint şi SQL Server. Business Intelligence
Development Studio (BIDS) este mediul de dezvoltare integrat utilizat pentru a
dezvolta aplicații de analiză a datelor şi aplicații BI, utilizând Microsoft SQL Server
Analysis Services, Reporting Services şi Integration Services. Se bazează pe mediul de
dezvoltare Microsoft Visual Studio, customizat cu servicii şi extensii ale SQL Server.
Viziunea Microsoft are în centru lărgirea bazei de adoptare într‐o firmă (de la
o rată de utilizare între 10 şi 20% indicată de rapoarte la 40, 60 şi chiar 80% din
utilizatorii din firmă) şi încurajarea utilizării. Ea se bazează pe bogatul ecosistem de
parteneri Microsoft, care pot construi şi livra soluții specializate şi nu doar o
platformă generală cu instrumente specializate.
Argumentarea acestei strategii porneşte de la o întrebare simplă: cine ia
deciziile în firmă? Dacă, la prima vedere, doar persoanele din vârful ierarhiei (CEO,
director, preşedinte) trebuie să ia decizii eficiente care să aducă succesul în
organizație, în fapt, planurile eficiente dezvoltate de conducerea de la vârf pot eşua
tocmai din cauza deciziilor greşite luate de persoane din părțile inferioare ale
ierarhiei în procesul de implementare sau în cel de execuție. Microsoft
argumentează astfel ideea că deciziile eficiente trebuie luate de toți cei din
organizație, indiferent de nivelul ierarhic.
MicroStrategy este o firmă americană fondată în 1989, care s‐a impus pe
piața BI cu aplicații OLAP şi de raportare, având realizări notabile în domeniul
bazelor de date multidimensionale, bazate pe arhitectura ROLAP (Relational OLAP).
Firma se mândreşte să aibă clienți precum: Lowe’s, McDonald’s, Universal Studios
Hollywood, DHL Express sau Priceline.com. Având o cifră de afaceri de 377 milioane
de dolari (2009) şi operațiuni în 23 de țări, nu este o amenințare reală pentru marii
furnizori. Ultima versiune a suitei lor este MicroStrategy 9, lansată în 2009, dar
interesant de urmărit va fi pachetul MicroStrategy Mobile, lansat în iulie 2010, care
mută aplicațiile BI pe iPhone şi iPad.
Pe lângă aceşti furnizori de top, pe piața BI mai găsim furnizori de nişă (cu
specializare strictă) şi vizionari (cei care propun soluții inovatoare). De asemenea,
găsim furnizori cu oferte de BI on demand, bazate pe modelul SaaS sau cloud
computing, precum şi oferte de soluții BI open source.

31 http://www.microsoft.com/bi/productsbi/#
32 Informațiile sunt culese dintr‐un interviu publicat în SQL Server Magazine pe 24 martie 2010,
disponibil la adresa http://www.sqlmag.com/article/business‐intelligence/tom‐casey‐on‐microsoft‐s‐
bi‐strategy.aspx
Soluţiile BI open source au câştigat teren în ultimii patru‐cinci ani. Ele nu au
complexitatea celor proprietare, dar cuprind toate funcționalitățile definitorii
pentru BI. Pentaho, unul dintre jucătorii importanți33 oferă Pentaho Open BI Suite,
care include: ETL, raportare operațională şi analitică, data mining şi analize OLAP,
tablou de bord într‐o ofertă de implementare flexibilă, cu plata pe baza unui
abonament anual. O altă ofertă vine de la Jaspersoft34, o firmă cu o creştere
importantă în 2009: JasperSoft Business Intelligence Suite, realizat pe baza
JasperReports, cea mai populară soluție open source Java de reporting, care cuprinde
o gamă largă de produse Business Intelligence, furnizând raportări robuste, raportări
interactive, analize de date şi capacitatea de integrare a datelor. Din cercetările
noastre reiese că Jaspersoft ofertează şi pe piața românească prin intermediul unui
partener local35.

8.4.2. Piaţa mondială de aplicaţii de Business Intelligence, aplicaţii
analitice şi de management al performanţelor

Conform rapoartelor Gartner (dintre care vom prezenta mai multe idei şi cifre
în continuare36), piața de soluții BI a fost într‐o continuă creştere, chiar şi în anii
2009 şi 2010, aferenți crizei. Anul 2011 a adus o creştere semnificativă de 17%, ea
temperându‐se în 2012 la nivelul de 7%, depăşind 13 miliarde de dolari. La fel ca
celelalte categorii de aplicații pentru afaceri, nici BI nu au rămas imune în fața
recesiunii, creşterea continuă arată că proiectele BI nu au fost abandonate. Conform
raportului (vezi toate cifrele în tabelul 8.7), SAP deține locul 1 cu 22,1% (în uşoară
scădere față de 2008‐2009, dar în creştere față de 2011), urmat de Oracle (cu
aproape 15%), apoi IBM şi SAS Institute (fiecare cu 12%) şi la oarecare distanță (dar
în creştere) Microsoft (9,1%).
Tabelul 8.7
Piaţa mondială de soluţii BI (în milioane de dolari)

Venit total în Cota de piaţă Venit total Diferenţa 2012

Producători
2012 2012 (%) în 2011 faţă de 2011 (%)
SAP 2.902,5 22,1 2.884,0 +0,6
Oracle 1.952,1 14,9 1.913,5 +2,0
IBM 1.625,0 12,4 1.478,8 +9,9
SAS 1.599,7 12,2 1.542,9 +3,7
Microsoft 1.189,3 9,1 1.059,9 +12,2
Alții 3.861,9 29,3 3.416,0 +13,0
Total 13.131,1 100.0 12.295,1 +6,8%
Sursa: Gartner Press Release, 6 iunie 2013, http://www.gartner.com/newsroom/id/2507915

33 The Pentaho BI Project a fost pornit în 2004 de un grup de veterani ai industriei de Business
Intelligence. Vezi mai multe pe site‐ul firmei: http://www.pentaho.com/
34 http://www.jaspersoft.com/
35 Vezi http://www.apal.ro/
36 Disponibile la http://www.gartner.com/newsroom/id/2507915

Pe segmente de piață (vezi structura în figura 8.16), liderii sunt diferiți: SAP
conduce pe platforme de BI, Oracle este lider pe CPM (managementul performanței),
iar SAS este numărul 1 în sfera aplicațiilor analitice – la fel ca şi până acum. Noutatea
vine de la IBM, care a venit puternic din spate în toate cele trei segmente
menționate.

Sursa: http://www.gartner.com/it/page.jsp?id=1357514, aprilie 2010.
Figura 8.16. Structura pieţei de Business Intelligence

Dacă în 2010, Gartner estima că în 2014 piața de BI va ajunge la 13 miliarde de
dolari, iată că acest nivel a fost deja depăşit în 2012. Ei au apreciat o creştere
similară, de 7% şi pentru anul 2013, iar pe termen lung, o valoare de 17 miliarde de
dolari în 201637. În opinia analiştilor, există o orientare serioasă către ofertele de
cloud computing sau SaaS, ca şi cele open source. De asemenea, se aşteaptă cu interes
răspunsul pieței la ofertele de BI mobil. Primele implementări s‐au realizat în 2007,
pe echipamente BlackBerry, iar acum s‐au extins şi la iPhone şi iPad, în condițiile
interesului tot mai mare al oamenilor de afaceri către echipamentele mobile Web
2.0, prin care se pot conecta permanent pentru a‐şi conduce firmele. Noul val
tehnologic este fără îndoială internetul mobil şi va avea un impact de zece ori mai
mare asupra firmelor decât internetul clasic. Argumentul? Există peste şase miliarde
de utilizatori de telefoane mobile38, față de un miliard de utilizatori de PC‐uri. Se
aşteaptă o avalanşă de aplicații pentru echipamentele mobile, iar BI este categoria la
care se aşteaptă o creştere formidabilă.

8.5. Direcţii de evoluţie a Business Intelligence

Business Intelligence a cunoscut dezvoltarea la cote neaşteptate pentru că a
depăşit faza de rapoarte tipărite sau grafice prezentate pe ecran. Rândurile unui
raport de vânzări, spre exemplu, pot conține informații detaliate şi exacte, dar nu

37 http://www.gartner.com/newsroom/id/2340216
38 http://mobithinking.com/mobile‐marketing‐tools/latest‐mobile‐stats/a#subscribers
reprezintă o soluție de Business Intelligence până când nu sunt puse într‐un format
care poate fi uşor înțeles şi interpretat de o persoană de decizie în vederea stabilirii
unei soluții eficiente pentru o situație particulară întâlnită în activitatea curentă. Un
aspect important pentru evoluția sistemelor BI l‐a constituit menținerea
performanțelor acestor sisteme în contextul creşterii utilizării lor. Din ce în ce mai
multe companii au început să folosească sistemele de BI, ceea ce a făcut ca avantajul
competițional dobândit să fie fragil şi efemer. Soluțiile Business Intelligence se
concentrau pe oferirea de înțelegere asupra datelor şi nu dispuneau de
instrumentele necesare pentru implementările de schimbări operaționale. În ultimii
ani, BI s‐a dezvoltat tocmai prin apariția unui nou tip de BI: aplicațiile de
management al performanței (BPM/CPM) şi aplicațiile analitice, bazate pe metode
statistice şi econometrice, deosebit de atrăgătoare pentru realizarea de previziuni.
Aceste noi direcții ale BI au permis crearea unui model de afacere care
permite companiilor să‐şi alinieze scopurile cu activitățile zilnice de derulare a
afacerii. Soluțiile de BI s‐au dezvoltat prin orientarea spre tipuri de afaceri, un
interes mare revenind tablourilor de bord şi instrumentelor de „descoperire a
datelor”, cu o vizualizare uşoară, atractivă şi rapidă a rezultatelor.
Credem că se pot formula două mari direcţii de evoluţie pe piața BI, aflată în
continuare sub o zodie norocoasă, dat fiind că BI rămâne pe primul loc pe lista de
priorități tehnologice ale organizațiilor contemporane:
1) consolidarea ofertelor de platforme BI ale primilor cinci furnizori din top
(tendință observată din 2009, când platformele au început să înlocuiască suitele de
aplicații BI);
2) conturarea unui segment consistent de utilizatori BI ondemand, care nu
pot depăşi bariera costurilor şi complexității unei soluții BI onpremise. Cloud
computing va influența radical implementarea sistemelor informatice şi, împreună
cu SaaS, se constituie într‐o alternativă atractivă pentru firmele mici şi mijlocii,
ținute până acum departe de barierele de costuri şi complexitate.


CAPITOLUL 9
Aplicaţiile mobile – suport pentru platforme
ERP dinamice

& cunoaşteţi principalele componente ale unei aplicaţii mobile;
& înţelegeţi avantajele, dar şi factorii de risc în implementarea
aplicaţiilor mobile;
& aveţi informaţii despre piaţa aplicaţiilor mobile pentru afaceri;
& vă familiarizaţi cu arhitecturile de servicii mobile;
& înţelegeţi portalurile de servicii mobile.
9.1. Prezentare generală a aplicaţiilor mobile

Aplicațiile mobile reprezintă în continuare o provocare pentru lumea
dezvoltatorilor de software, deşi primele încercări au dat rezultate încă de acum
câțiva zeci de ani. Evoluția tehnologică a mutat însă această industrie dintr‐o zonă
exclusivistă către una pur comercială, care suscită interesul marilor companii
producătoare de instrumente hardware şi software din domeniu. Prin prezentul
capitol vom încerca să evidențiem arhitecturile generale care vor fi utilizate pentru
aplicații mobile, precum şi avantajele şi dezavantajele fiecăreia dintre ele.

9.1.1. Definire, istoric şi componentele principale

Ideea de a putea utiliza dispozitive şi aplicații care să se bazeze pe tehnologii
fără fir a atras dezvoltatorii încă de la apariția rețelei ARPANET, în anul 1969, ca
precursor al internetului. Existența unei infrastructuri radio, care s‐a cristalizat
începând cu anii ’20, a condus la dorința de a combina cele două tipuri de tehnologii
pentru a genera una capabilă să ruleze aplicații distribuite în medii wireless mobile.
Primele încercări de acest gen au fost realizate în 1974, când Motorola a produs
primul pager comercial (Motorola Pageboy 1), de dimensiunea unui pachet de țigări.
Dispozitivul în cauză nu făcea decât să emită un semnal sonor care îl înştiința pe
proprietar că trebuie să sune de urgență la serviciu. Următorii paşi au constat în
producerea pagerelor de tip tone‐voice, care transmiteau şi un mesaj vocal
destinatarului, iar mai apoi, în producerea pagerelor digitale, cu afişaj pe un ecran
încorporat. Tehnologia pagerelor digitale a fost dominantă pe piață până la
începutul anilor ’90, când apariția telefoanelor mobile a dus la scăderea dramatică a
vânzărilor de dispozitive de tip pager.
În acest timp, evoluția internetului a dus la definirea limbajului HTML ca
standard pentru serviciile furnizate de aplicațiile web. Întâlnirea dintre tehnologia
deja existentă pe „clasicul” web şi noile dispozitive mobile nu a fost tocmai fericită,
deoarece acestea din urmă au o serie de caracteristici care le fac inadecvate pentru
modelul internet1:
puterea generată de baterie este relativ redusă, ceea ce le împiedică să
apeleze la procesoare foarte puternice;
puterea de calcul este limitată;
capacitatea locală de stocare este nesemnificativă;
posibilitățile de afişare sunt destul de reduse atât din punctul de vedere al
dimensiunii, cât şi al performanțelor calitative.
Pe măsura evoluției tehnologice, aceste limitări vor fi în mod sigur ameliorate,
însă ele au impus inițial apelarea la un nou standard care să fie potrivit pentru
constrângerile dispozitivelor mobile. Acest standard s‐a numit HDML (Handled
Device Markup Language) şi nu a avut succesul scontat, însă a constituit punctul de
pornire în realizarea şi impunerea WAP (Wireless Application Protocol). Dezvoltate

1 A. Wigley, P. Roxburgh, Building .NET applications for mobile devices, Microsoft Press, 2002, pp. 20‐25.
Aplicaţiile mobile – suport pentru platforme ERP dinamice 305
în urma colaborării dintre Nokia, Ericsson, Motorola şi Unwired Planet, specificațiile
WAP includ WML (Wireless Markup Language) şi WMLScript (un limbaj de scripting
asemănător cu JavaScript).
Aplicațiile mobile au în prezent o multitudine de valențe, cele mai utilizate
referindu‐se la posibilitatea de a accesa internetul de pe dispozitive mobile, la
servicii de autentificare la distanță, precum şi la o serie de servicii grupate sub
titulatura Rich Voice, care cuprind de fapt transmiterea informațiilor de tip text,
audio şi video.
Principalele componente şi entități care intră în alcătuirea unei arhitecturi
pentru aplicații mobile sunt următoarele:
operatorul de servicii pentru transmisiuni wireless;
furnizorii de echipamente hardware;
furnizorii de medii de dezvoltare software specializate;
dezvoltatorii de aplicații;
integratorii de sisteme.
Operatorul de servicii pentru transmisiuni wireless are rolul de a asigura
funcționarea infrastructurii de realizare a comunicațiilor fără fir, fiind echivalentul
furnizorilor de servicii internet pentru aplicațiile web. Ca factor de bază al
arhitecturii generale, operatorul poate impulsiona dezvoltarea pieței aplicațiilor
mobile prin reducerea costurilor de conectare şi prin lățimea de bandă din ce în ce
mai mare, care va fi disponibilă pentru utilizatori.
Furnizorii de echipamente hardware au rolul de a sigura o parte importantă a
infrastructurii fizice, prin dezvoltarea terminalelor inteligente care să utilizeze
aplicații mobile. Creşterea puterii de procesare, a capacității de stocare şi a duratei
de viață a bateriilor de alimentare a dispozitivelor mobile vor fi un alt factor
determinant pentru evoluția industriei aplicațiilor mobile.
Rolul‐cheie în elaborarea aplicațiilor mobile îl are totuşi componenta software,
care este sprijinită de furnizorii de medii de dezvoltare specializate şi de
dezvoltatorii de aplicații. La ora actuală, diversele standarde de comunicație şi
mediile de dezvoltare din ce în ce mai productive constituie un atu al industriei din
domeniu. WAP, XML, VXML, .NET, J2SE, J2EE asigură transferul de date, legătura cu
bazele de date distribuite, accesul la rapoarte sintetice, transmiterea de informații
multimedia.
Arhitectura generală simplificată care stă la baza rulării aplicațiilor mobile
poate fi reprezentată conform figurii 9.12.
Avantajele unei astfel de arhitecturi sunt numeroase:
procesarea operațiunilor se realizează pe serverul web, fără a solicita
capacitatea de procesare a terminalelor mobile;
integrarea cu aplicațiile deja existente este relativ uşoară, având în vedere
că trebuie adaptată doar comunicația wireless;
actualizarea datelor se poate realiza cu aceeaşi viteză cu cea a internetului
„clasic”.

2 D. Tipper, „Mobile Applications Architectures”, public presentantion, University of Pittsburgh, 2005.

Client
mobil
Baze de
date Server Client
Gateway mobil
WEB
INTERNET
wireless Releu
Baze de
date
Client
mobil
Figura 9.1. Arhitectura generală a infrastructurii aplicaţiilor mobile

Dezavantajele arhitecturii tind să fie ameliorate în viitorul nu prea îndepărtat
prin mărirea lățimii de bandă şi prin realizarea de dispozitive mobile capabile să
realizeze operațiuni complexe şi să prezinte date în formate grafice avansate.

9.1.2. Avantaje şi riscuri

Este clar că succesul aplicațiilor mobile depinde în mare măsură de
disponibilitatea conexiunii dintre dispozitivul mobil şi serverul de prezentare sau
serverul de aplicații. Deşi în literatura de specialitate sunt prezentate numeroase
tipuri de arhitecturi, considerăm că viitoarele aplicații mobile se vor baza pe una
dintre următoarele arhitecturi specifice3:
arhitectura în trei straturi cu conexiune continuă;
arhitectura în trei straturi cu conexiune întreruptă.
Arhitectura cu conexiune continuă presupune existența unei legături
neîntrerupte între clientul mobil şi server, toate operațiunile tranzacționale
desfăşurându‐se pe serverul de aplicații (vezi figura 9.2).
Această arhitectură are o serie de avantaje:
operațiunile tranzacționale sunt realizate pe serverul de aplicații sau pe
serverul de baze de date şi, ca atare, aplicațiile pot beneficia din plin de puterea de
calcul existentă pe aceste componente hardware;
tranzacțiile realizate de un client care face parte din această arhitectură
sunt receptate imediat de toți ceilalți clienți, prin intermediul serverului de
prezentare şi al conexiunii continue;
în principiu, costul clientului mobil este redus la costul unui browser.

3 V. Lee, H. Scheinder, R. Schell, Mobile Applications: Architecture, Design and Development, Prentice Hall
PTR, 2004, p. 168.
De asemenea, arhitectura care se doreşte a fi bazată pe conexiune continuă
are şi unele dezavantaje:
costul folosirii aplicației poate creşte direct proporțional cu durata de
utilizare şi cu prețul conexiunii pe unitatea de timp;
în cazul în care conexiunea devine indisponibilă, clientul mobil nu va avea
nicio posibilitate de a beneficia de datele existente pe partea de server.

CLIENT Server
MOBIL Server Server baze de
prezentare aplicaţii date
Browser Baza
de date
Conexiune
neîntreruptă

Figura 9.2. Arhitectura bazată pe conexiune continuă

Arhitectura cu conexiune întreruptă presupune existența unui client mult
mai complex față de cel din arhitectura anterioară.

CLIENT Server
MOBIL
Server Server baze de
P
D
Bază
de date
prezentare aplicaţii date
A locală Baza
de date
Conexiune
întreruptă

Figura 9.3. Arhitectura bazată pe conexiune întreruptă

Astfel, clientul nu mai este doar un browser care solicită datele de la serverul
de prezentare, ci este el însuşi dotat cu un motor pentru prezentare, aplicații şi baze
de date (vezi figura 9.3). În cazul în care conexiunea este întreruptă, lucrul pe client
presupune folosirea datelor din baza de date locală şi realizarea tranzacțiilor local.
Salvarea tranzacțiilor în baza de date centrală se realizează în momentul restabilirii
conexiunii.
Avantajele unei astfel de arhitecturi sunt următoarele:
clientul mobil este parțial funcțional, chiar în condițiile în care conexiunea
este temporar întreruptă;
în cazul în care costul unei conexiuni neîntrerupte este mare, se poate
utiliza aplicația în mod deconectat, urmând a se folosi conexiunea doar pentru

salvarea tranzacțiilor pe server sau pentru actualizarea periodică a bazei de date
locale.
Arhitectura bazată pe conexiune întreruptă are şi o serie de dezavantaje:
clientul mobil devine mai scump decât în arhitectura precedentă, ca urmare
a încorporării de elemente software capabile să‐i asigure o autonomie temporară;
serverul trebuie proiectat astfel încât să fie capabil să prelucreze seturi de
tranzacții efectuate off‐line pe diverşi clienți deconectați;
apare posibilitatea existenței la un moment dat a mai multor imagini
diferite ale bazei de date pe care le au clienții deconectați.

9.1.3. Principalii actori pe piaţa aplicaţiilor mobile pentru afaceri

Companiile care manifestă interes pentru domeniul aplicațiilor mobile au
dezvoltat instrumente şi aplicații competitive, încercând să‐şi impună propriul
standard de facto. Cu toate acestea, nu se poate spune la ora actuală că există un
câştigător net pe această piață. Astfel, IBM propune o suită compusă din Websphere,
Lotus, DB2 şi Tivoli, care combină serviciile web, bazele de date şi instrumentele
colaborative wireless pentru realizarea de aplicații robuste. Investițiile în tehnologia
de tip grid pe care le‐a realizat IBM în ultima perioadă, precum şi suportul pentru
Linux, conferă avantaje reale în competiția pentru piața aplicațiilor mobile.
Platforma Microsoft .NET este un alt exemplu de tehnologie pusă în slujba
aplicațiilor mobile, prin integrarea cu suita formată din SQL Server, Biztalk Server şi
standardele de comunicare RosettaNet, CIDX, HIPPA4. Platforma .NET permite, de
asemenea, integrarea cu uşurință a vechilor aplicații ale întreprinderii, astfel încât
noile arhitecturi preiau din mers realizările trecute.
Există trei versiuni ale sistemului de operare Microsoft Windows Mobile
(fiecare dintre aceste versiuni fiind adresată anumitor dispozitive smart)5:
Windows Mobile Standard – este destinat telefoanelor mobile cu funcții
avansate (engl. smartphone) precum: e‐mail, mesaje text, browser internet etc.
(fiind o versiune cu mai puține funcționalități decât variantele Classic sau
Professional);
Windows Mobile Classic – este destinat dispozitivelor smart PDA (engl.
Personal Digital Assistant) care nu îndeplinesc şi funcția de telefon mobil. Spre
deosebire de smartphone, aceste dispozitive au ecran senzitiv cu o rezoluție de cel
puțin 240 × 320 pixeli, tastatură cu mai mult de 12 taste, procesor mult mai
performant, memorie de capacitate ridicată, adaptor de rețea wireless etc.
Versiunea sistemului de operare destinat acestor dispozitive oferă inclusiv
facilitățile Microsoft Office Mobile;

4 A. Troelsen, Visual Basic .NET and the .NET Platform. An Advanced Guide, Apress, USA, 2002, pp. 971‐991.
5 O. Dospinescu, V. Iftode, Aplicaţii mobile pe platforma .NET, Editura Universității „Alexandru Ioan
Cuza”, Iaşi, 2007, p. 22.
Windows Mobile Professional – este destinat dispozitivelor smart PDA care
îndeplinesc şi funcția de telefon mobil. Versiunea sistemului de operare destinat
acestor dispozitive încorporează toate funcțiile oferite de celelalte versiuni.
Datorită competiției acerbe din partea iOS şi Android, Microsoft a generat o
nouă platformă pentru aplicații mobile, intitulată WindowsPhone 6, care are în
vedere integrarea pe scară largă a sistemelor şi aplicațiilor. La ora scrierii acestui
material, versiunea 8.0 se dovedeşte a fi una de succes, cu impact semnificativ la
public, atât pe partea de utilizatori individuali, cât şi pe zona de corporații.
Alți competitori însemnați, Sun Microsystems Inc. şi Symbian, promovează
mediul Java ca suport software pentru aplicațiile mobile 7. Pe lângă J2EE, noua
arhitectură propusă de SUN include şi JCA (Java Connector Architecture), JMS (Java
Message Service) şi JAAS (Java Authentication and Authorization Service).
Deşi este în continuă modificare, considerăm că o imagine a cotelor de piață
este relevantă în vederea creionării unei impresii asupra marilor jucători de pe piața
sistemelor mobile (figurile 9.4 şi 9.5).
BlackBerry
4%
Windows Phone
3%

Figura 9.4. Piaţa platformelor de operare pentru telefoane inteligente8

Figura 9.5. Cota de piaţă a primilor furnizori de telefoane smart9

6 http://developer.windowsphone.com/en‐us, accesat în iunie 2013.
7 J. Allin, „Java, Symbian and the Wireless Market: Questions and Answers”, http://www.developer.
com/ws/other/article.php/1574201, accesat în februarie 2008.
8 http://www.research2guidance.com/apple‐and‐android‐account‐for‐82‐of‐all‐app‐downloads‐but‐2013‐
might‐be‐the‐turning‐point‐of‐the‐dominance‐for‐both‐platforms/, accesat în iunie 2013.

Cea mai mare parte a jucătorilor mici au continuat să construiască
parteneriate pentru a‐şi îmbunătăți poziția pe piață. Cu dominanța în creştere a
Android şi iOS ca platforme de operare pentru telefoanele inteligente, diferențierea
dispozitivelor devine din ce în ce mai dificilă. Aceasta ar putea deschide uşa pentru
noi sisteme de operare, care vor fi lansate în următoarele perioade.
Piața dispozitivelor şi aplicațiilor mobile este foarte efervescentă, generând
noi platforme şi noi alegeri: Microsoft, BlackBerry, Firefox, Ubuntu sau Jolla au venit
cu noi platforme de aplicații, care vor provoca cei doi lideri de pe piață. Unii au
susținere financiară, alții au noi concepte şi soluții interesante. Totul pare să atragă
o cotă destul de mare de piață, indicând faptul că piața este dispusă să încerce şi
altceva pe lângă „clasicii” iOS şi Android. Creşterea importanței platformelor de
sisteme de operare pe parcursul ultimilor ani a fost determinată de creşterea
telefoanelor inteligente, consumatorii căutând interfețe şi tehnologii intuitive şi
inovatoare, dar, de asemenea, şi o gamă largă de aplicații mobile pentru a creşte
domeniul de aplicare a ceea ce poate face dispozitivul pentru utilizator. Cu ratele de
penetrare a telefoanelor inteligente care se aşteaptă să crească puternic, sistemul de
operare s‐a cimentat ca unul dintre factorii‐cheie de decizie de cumpărare pentru
consumatori.
După cum am văzut în studiul precedent, în prezent există câțiva jucători mari
pe această piață competitivă10: Apple cu iOS, Google cu Android, Microsoft cu
Windows Phone, Research in Motion cu BlackBerry. Fiecare dintre aceştia se
străduieşte să facă tot posibilul să poată oferi dezvoltatorilor cele mai bune
instrumente pentru a crea aplicații pentru platforma lor. Odată cu diversificarea şi
progresul tehnologiei dispozitivelor mobile, a crescut şi cererea pentru aplicații
mobile, acestea avansând într‐un mod accelerat din stadiul experimental, la folositor
în aspectele esențiale ale afacerilor.
Pe lângă valoarea economică obținută de pe urma aplicațiilor, există
consecințe diferite pentru industrii şi indivizi în ceea ce priveşte modul în care
acestea influențează viața de zi cu zi. Aplicațiile mobile revoluționează afacerile,
reuşind să creeze rapid locuri de muncă, în ciuda unui context economic dificil.
Având în vedere modurile în care aplicațiile au redefinit societatea, este uşor de
constatat că piața aplicațiilor nu a ajuns încă la saturație, fiind aşteptată în
continuare o extindere a acesteia.
Conform cercetătorilor de la Berg Insight, numărul de aplicații mobile
descărcate în întreaga lume s‐a dublat în anul 2012, crescând de la 29,5 miliarde în
2011, la 60,1 miliarde11. Un total de 1,6 miliarde de aplicații iOS şi Android au fost

9 http://www.research2guidance.com/apple‐and‐android‐account‐for‐82‐of‐all‐app‐downloads‐but‐2013‐
might‐be‐the‐turning‐point‐of‐the‐dominance‐for‐both‐platforms/, accesat în iunie 2013.
10 E. Duval, G. Parra, Comparative study of tools for crossplatform mobile application development,
http://thesis12.bertouttier.be/wp‐content/uploads/2012/11/literature‐study‐Bert‐Outtier.pdf
11 ***, „108 billion mobile applications will be downloaded in 2017”, http://www.berginsight.com/
News.aspx, accesat în martie 2013.
descărcate numai între Crăciun şi seara Anului Nou (25‐31 decembrie), recordul de
328 de milioane fiind înregistrat în ziua de Crăciun12. Datorită faptului că telefoanele
inteligente, tabletele şi alte dispozitive mobile sunt din ce în ce mai căutate, se
aşteaptă ca piața aplicațiilor mobile să crească, de asemenea, ajungând la 108
miliarde descărcări până în anul 2017.
Veniturile din aplicații, incluzându‐le pe cele directe şi pe cele provenite din
reclamele din cadrul aplicațiilor, au totalizat aproximativ 8,4 miliarde de dolari în
2012. La nivel mondial, se estimează o rată de creştere anuală de 17%, pentru a
ajunge la venituri de 18,6 miliarde de dolari în 2017 13. Magazinele de aplicații Apple
pentru sistemul de operare iOS, Google Play pentru Android şi cele ale unor părți
terțe au fost principalii responsabili pentru creşterea explozivă a descărcărilor de
aplicații în 2012, Android fiind platforma‐lider.
În ceea ce priveşte extensiile mobile ale sistemelor integrate de tip ERP, piața
a devenit foarte efervescentă în ultimii doi‐trei ani şi produsele inovative nu au
întârziat să apară. Astfel, sistemul integrat Microsoft Navision beneficiază de
extensia NAVMobile14, care oferă utilizatorilor posibilitatea de a controla întregul
sistem de la distanță, prin intermediul unui dispozitiv mobil pe care rulează
Windows Mobile sau Android.

Figura 9.6. NAVMobile – extensie pentru Navision ERP

12 P. Farago, „Holiday 2012 Delivers Historical Worldwide App Downloads”, http://blog.flurry.com/
bid/92809/ Holiday‐2012‐Delivers‐Historical‐Worldwide‐App‐Downloads, accesat în aprilie 2013.
13 E. Nathan, „Mobile App Downloads to Hit 108 Billion in 2017”, http://www.eweek.com/mobile/
mobile‐app‐downloads‐to‐hit‐108‐billion‐in‐2017, accesat în iunie 2013.
14 http://www.dynamicsmobile.com/resources/view/17/NAVmobile‐product‐overview; http://wiki.
mobilefordynamics. com, accesate în iunie 2013.

Sistemul NAVMobile (figura 9.6) permite introducerea de date în sistem prin
intermediul conexiunilor wireless, precum şi obținerea de rapoarte parametrizate în
funcție de opțiunile utilizatorului curent. Transmisia de date se realizează prin
intermediul serviciilor web şi în acest fel aplicația client este degrevată în mare
măsură de efortul de procesare complexă a datelor. Venită ca o extensie naturală a
„clasicului” sistem integrat Navision, NAVMobile reprezintă de fapt o adaptare la
trendul momentului în materie de sisteme integrate în medii mobile.
SAP, cel mai mare jucător de pe piața sistemelor integrate, oferă şi el extensia
SAP Mobile15, care rulează pe o multitudine de dispozitive mobile şi sisteme de
operare (vezi figura 9.7).

Figura 9.7. SAP Mobile – extensie pentru SAP ERP

Modulele din varianta mobilă16 sunt foarte asemănătoare cu cele din aplicația
ERP, care este implementată în companii. Astfel, de pe dispozitivele mobile pot fi
accesate module pentru CRM, SFA, BI, Warehouse, Financial etc.

15 http://www54.sap.com/pc/tech/mobile/software/solutions/applications/overview.html, accesat în
iulie 2013.
16 http://www54.sap.com/pc/tech/mobile/software/solutions/platform/overview.html, accesat în
iunie 2013.

Figura 9.8. Funcţionalităţi SAP CRM Mobile

Pe piața din România există jucători care au produs extensii mobile
importante pentru sisteme integrate. Astfel, Charisma Mobile Solutions17 produsă de
compania TotalSoft cuprinde produsele Analyzer, Cell Monitor, Portfolio
Management, Medical Software şi EMR, care oferă conectare permanentă la sursele
de date ale organizației şi reprezintă o bază excelentă de decizie sau de informare la
nivel managerial, totul datorită integrării native cu suita de soluții de business
Charisma sau cu orice alt sistem de gestiune a resurselor companiei. Soluțiile mobile
combină puterea analitică a aplicațiilor software cu cea mobilă a gadgeturilor,
permițând vizualizarea rapidă a indicatorilor de performanță, navigarea uşoară prin
datele care stau la baza acestor indicatori, generarea de statistici pe baza unor surse
de date diferite, care pot fi sisteme ERP, sisteme de Contract Management sau soluții
software de gestiune a unităților medicale. Informațiile preluate din diverse surse
de date se sincronizează automat, utilizatorul având acces la date, analize,
previzionări actualizate şi la agenda de întâlniri. Datorită actualizării permanente,
pe baza oricăror modificări în sistemul informatic integrat al organizației, dar şi
datorită posibilităților extinse de conectare online, top‐managementul sau
persoanele autorizate pot consulta în timp real orice indicator de performanță
financiară sau nonfinanciară. Dispozitivul foloseşte tehnologii de ultimă generație,
care extrag, analizează şi afişează informații relevante pe baza celulelor situaționale
comparative. Soluțiile Mobile Charisma sunt aplicații bazate pe iOS care se pot
instala atât pe dispozitivele iPhone, iPodTouch, cât şi pe tabletele iPad. Din suita de
funcții puse la dispoziție de SDK‐ul iOS (kitul de dezvoltare software), soluțiile
mobile furnizate de TotalSoft fac uz de:

17 http://www.charisma.ro/solutii‐mobile, accesat în iulie 2013.

multitouch;
overtheair sync (3G/WIFI);
multitasking;
pushnotifications.
Conform specificațiilor producătorului18, sistemele Charisma dispun de un
modul de procesare date server‐side, care face disponibile rapoartele către aplicația
mobilă prin intermediul unui serviciu web. Astfel, prin intermediul unei conexiuni
3G sau WIFI, utilizatorul actualizează baza de date de la distanță, la cerere sau
conform unui program de actualizare (update) prestabilit. Canalul de comunicare
este securizat şi criptat, pentru a îmbunătăți factorul de protecție a datelor.
În ceea ce priveşte analiza avansată a datelor, Charisma Mobile Analyzer19 este
o soluție mobilă de analiză şi prelucrare avansată a indicatorilor de performanță, de
tip Business Intelligence, care permite obținerea de rapoarte şi tablouri de bord
detaliate, într‐un mod grafic intuitiv, pe baza oricăror indicatori de performanță
necesari susținerii deciziilor strategice (vezi figura 9.9). Charisma Mobile Analyzer se
adresează tuturor sectoarelor de activitate (vânzări, producție, logistică, servicii,
financiar‐bancar, construcții), oferind suport în previzionarea şi calibrarea
operațiunilor oricărui tip de organizație.

Figura 9.9. Charisma Mobile Solutions

AlfaSoftware oferă de asemenea o variantă mobilă pentru produsul său
integrat ASIS. Nevoile managerilor de a avea informații în timp real de oriunde din
lume s‐au concretizat în soluția pentru telefoane mobile – ASiSmobile Manager.
Această aplicație20 este destinată accesului de pe smartphone‐uri care suportă

18 http://www.charisma.ro/solutii‐mobile/de‐ce‐solutii‐mobile, accesat iulie 2013.
19 http://www.charisma.ro/solutii‐mobile/mobile‐analyzer, accesat în iulie 2013.
20 http://www.asw.ro/produse‐alfa‐software/asismobile/181‐asismobile‐manager, accesat în iunie
2013.
Android/IOS ca sistem de operare şi poate fi configurată în funcție de nevoile de
informații pe care le au utilizatorii.

Figura 9.10. Exemple utilizare ASISmobile

În orice moment, managerii pot primi rapoarte precum cele de cash‐flow,
situații pe terți, balanța contabilă, situații de vânzări, care să le uşureze luarea
deciziilor (vezi figura 9.10). Rapoartele sunt grupate pe categoriile definite în ASiS
ERP, ceea ce face regăsirea lor extrem de uşoară. Toate aceste rapoarte au ca punct
de pornire datele introduse şi prelucrate în celelalte aplicații, RIA sau desktop, ale
sistemului integrat ASiS şi oferă managerilor o imagine clară asupra afacerii lor, în
timp real.
Mai mult, toate criteriile de filtrare ale unui raport, aşa cum au fost ele
configurate în ASiS ERP, se pot utiliza şi de pe telefonul mobil. Conform drepturilor
primite, un utilizator poate accesa doar rapoartele pentru care a primit drept de
vizualizare, iar aceste rapoarte vor fi filtrate pe centre de profit/gestiuni conform
regulilor de filtrare pentru acel utilizator. Fiecare raport permite alegerea perioadei,
formatului, precum şi precizarea filtrelor interactive pentru restrângerea datelor de
vizualizat. Astfel, fişa clienților poate fi extrasă, centralizată pe facturi sau detaliată
la nivel de documente primare, poate fi filtrată pe un client/agent/rută etc.
Selectarea criteriilor de filtrare este interactivă şi optimizată pentru o interfață de
tip mobile/touch screen.
De asemenea, ASIS ERP are şi o extensie mobilă pentru automatizarea forței
de vânzare21. ASiSagent sprijină procesul de automatizare a forţei de vânzare,
oferind agenților de vânzare informații în timp real asupra clienților pe care îi
vizitează (vezi figura 9.11). Cu ajutorul acestei aplicații, orice agent, de pe un
smartphone sau o tabletă pe care rulează sistemul Android/IOS, are acces la baza de
date ASiS/ASiSmag. În funcție de drepturile de utilizare setate, el poate consulta
informații privind soldurile clienților, stocurile existente pentru un anumit produs,
comenzile efectuate în dreptul unui client etc. Toate câmpurile disponibile în
ASiSmobile sunt configurabile.

21 http://www.asw.ro/produse‐alfa‐software/asismobile/149‐asisagent, accesat în iunie 2013.


Figura 9.11. ASiSagent – extensia mobilă pentru SFA

În materie de Sales Force Automation (SFA), o prezență extrem de bine
conturată pe piața din România este SeniorSFA ca extensie a SeniorERP. SeniorSFA22
face parte din ultima generație de aplicații mobile disponibile pe Android, destinate
managementului calității proceselor de vânzare şi a echipelor de teren, acoperind
următoarele tipuri de activități: vânzări tranzacționale şi consultative, merchan‐
dising, marketing, training, service şi gestionarea obiectivelor (vezi figura 9.12).

Figura 9.12. SeniorSFA – extensie mobilă pentru SeniorERP

Indiferent dacă este vorba despre telefon sau tabletă, interfața SeniorSFA este
optimizată pentru fiecare tip de dispozitiv mobil, oferind productivitate şi confort
încă de la prima utilizare. Pe lângă costurile reduse ale platformei Android, aplicația
poate fi integrată cu sisteme deja existente în companie, ERP şi/sau CRM.
Selectarea unei anumite arhitecturi sau tehnologii pentru dezvoltarea aplica‐
țiilor mobile continuă să fie o sarcină destul de dificilă, ținând cont de faptul că nu

22 http://www.seniorerp.ro/sfa, accesat în iulie 2013.
există un standard unanim acceptat în domeniu, iar modificările şi inovațiile au loc
în ritm alert. Analiza felului în care vor fi dezvoltate aplicațiile mobile trebuie să țină
cont de o serie de factori: sistemul de operare utilizat, instrumentul de dezvoltare
propus, capabilitățile serverului de aplicații, costul procesării tranzacțiilor pe
dispozitivele mobile şi pe server, integrarea cu vechile aplicații, precum şi felul în
care sunt afectate procesele de lucru ale întreprinderii.

9.2. Arhitecturi de servicii mobile pentru afaceri

Cu mai bine de 15 ani în urmă, John Naisbitt scria: „În epoca informațională a
secolului XXI, toate mijloacele de comunicare, de care este posibil să avem nevoie, se
vor afla pe biroul nostru, în maşina noastră sau chiar în palmă”23. Astăzi, această
afirmație este verificată.
Prezentul subcapitol este o analiză exploratorie a stadiului actual în ceea ce
priveşte aplicațiile şi serviciile mobile pentru întreprinderi, realizările din domeniu,
şi propune un model de arhitectură pentru servicii mobile pornind de la
funcționalitățile necesare identificate pentru un portal de servicii mobile. Pe lângă
arhitectura generală a unui portal de aplicații mobile pentru întreprinderi, este
propus şi un set de funcționalități minimale pentru implementare, astfel încât să se
asigure promovarea şi utilizarea serviciilor.

9.2.1. Funcţionalităţile unui portal de servicii mobile

Având în vedere că serviciile mobile pentru întreprinderi emulează serviciile
„fizice” ale furnizorului către client, putem considera că relația care se stabileşte
între client şi furnizor este una similară cu cea de tip față‐în‐față. Ca atare, în
varianta cea mai simplă, un client va folosi serviciile unui furnizor, eventual contra
cost. Există însă mai multe aspecte şi ipoteze de lucru care trebuie avute în vedere
de ambele părți implicate într‐un astfel de proces:
clientul nu cunoaşte întotdeauna furnizorul înainte de a apela la serviciile
sale;
clientul are nevoie doar de un anumit serviciu sau gamă de servicii;
un furnizor de servicii mobile nu poate satisface toate cerințele
potențialilor clienți (din motive de calitate a serviciilor, cost, timp de răspuns etc.);
între client şi furnizor pot exista diferențe culturale în ceea ce priveşte
limbajul, percepția asupra termenilor contractului, aşteptările față de partener;
furnizorul trebuie să obțină de la client plata pentru serviciile prestate.
Mai mult decât atât, este foarte posibil ca, temporar, din diverse motive, un
serviciu oferit de un anumit furnizor să nu fie funcțional din motive tehnice
(indisponibilitatea resurselor, oprire temporară pentru intervenții tehnice) sau
chiar furnizorul în sine să nu fie disponibil (prea multe cereri de la clienți,
întreruperea conexiunilor din motive tehnice).

23 J. Naisbitt, Global Paradox, Nicholas Breadley Publishing, London, 1995, p. 55.

Având în vedere elementele precizate anterior, considerăm că, în cadrul unei
arhitecturi bazate pe servicii mobile pentru întreprinderi, trebuie să fie disponibile
următoarele funcționalități:
posibilitatea clientului de a căuta furnizorul care să‐i ofere serviciile mobile
de care are nevoie, eventual în anumite condiții de calitate şi preț;
obținerea de către client a unei „liste de rezerve” cu furnizorii şi serviciile
care pot fi apelate în cazul în care furnizorul sau serviciul inițial devine indisponibil
temporar;
posibilitatea furnizorului de a accepta/respinge solicitările unui client în
ceea ce priveşte un anumit serviciu;
trimiterea de client a cererii ferme către furnizor, prin oferirea datelor şi
elementelor necesare efectuării serviciului;
posibilitatea transferului de bani în condițiile stabilite prin contractul
dintre cei doi parteneri: înainte de efectuarea serviciului, simultan cu efectuarea
serviciului sau după realizarea serviciului;
în cazul în care un client alege un furnizor de servicii mobile, să fie cât mai
sigur de faptul că eventualele diferențe culturale dintre ei vor afecta relația
contractuală într‐o măsură cât mai redusă.

9.2.2. Propunere de arhitectură pentru servicii mobile

Pornind de la funționalitățile necesare pentru serviciile mobile pentru
întreprinderi, propunem o arhitectură care să se bazeze pe conceptul general de
portal de servicii (vezi figura 9.13). De fapt, acest portal îndeplineşte rolul de broker,
atât pentru client cât şi pentru furnizor.

Furnizor de Furnizor de Furnizor de

servicii mobile servicii mobile ... servicii mobile
Ofertã
Cerere
Internet mobil
Gestiune cerere/ofertã
Portal servicii mobile
Management cereri
Internet mobil
Cerere Rãspuns
Client serviciu Client serviciu ... Client serviciu

mobil mobil mobil

Figura 9.13. Arhitectura pe bază de portal pentru servicii mobile pentru întreprindere
Considerăm că arhitectura propusă poate fi împărțită în două componente
distincte, în funcție de entitatea cu care interacționează portalul de servicii mobile:
interfața cu clienții şi interfața cu furnizorii. Pe baza funcționalităților identificate,
portalul trebuie să suporte mai multe tipuri de comenzi prezentate în tabelele 9.1
şi 9.2.
Tabelul 9.1
Comenzile din categoria „requests management”

Tip comandă Explicaţie
Find a service Portalul va căuta în lista de servicii mobile disponibile pe cel care
corespunde criteriilor specificate de client: calitate, preț, timp de execuție
etc. Este recomandat ca această comandă să returneze şi o „listă de
rezerve” cu serviciile care pot fi apelate în cazul în care primul devine
indisponibil din diverse motive.
Request Portalul va pune în legătură clientul solicitant cu furnizorul ales în urma
connection unei comenzi de tip „find a service”. Portalul va înştiința furnizorul de
dorința clientului de a‐i folosi serviciile. În cadrul acestei comenzi,
portalul poate să ofere datele de identificare ale clientului sau poate cere
serviciul în nume propriu, urmând să‐l ofere mai departe clientului în
mod transparent.
Execute Portalul va solicita executarea serviciului de furnizor, în condițiile
service stabilite în urma executării cu succes a comenzii „request connection”.
Execute next Această comandă ar trebui să se execute în condițiile în care serviciul sau
service from furnizorul inițial devine temporar indisponibil.
list

Tabelul 9.2
Comenzile din categoria „offers management”

Tip comandă Explicaţie
Register the Portalul va înscrie în lista de servicii disponibile noul serviciu oferit de
service in the list furnizorul care execută comanda. Această comandă va avea parametri
care vor descrie numele serviciului, tipul său, funcționalitățile
serviciului, costurile, timpul de execuție şi alte date tehnice care ar fi
de interes pentru client.
Accept La fel ca în cazul comenzii „request connection”, furnizorul va accepta
connection tranzacția fie direct cu clientul, fie cu portalul ca intermediar de
servicii mobile pentru întreprindere. În primul caz, plata va fi primită
de la client, iar în cel de‐al doilea, de la portal, ca agent de
intermediere.
Execute service Portalul va solicita executarea serviciului de furnizor, în condițiile
stabilite în urma executării cu succes a comenzii „request connection”.

În funcție de gradul de dezvoltare a portalului, acesta ar trebui să execute
comenzile de tip „find a service”, încercând să atenueze pe cât posibil eventualele
diferențe culturale dintre client şi furnizor. Acest lucru ar însemna ca, dintr‐o listă
de servicii disponibile care sunt identice, portalul să sugereze mai întâi clientului pe
cea care este cea mai apropiată de cultura acestuia. În această situație, portalul ar

trebui să implementeze şi funcționalități de identificare a ariei culturale a clientului,
pe baza datelor de identificare ale acestuia.
Pe lângă comenzile prezentate în listele anterioare, portalul poate implementa
opțional şi comenzi de tip „bill” sau „payment”, în funcție de modalitatea aleasă
pentru transferul banilor în contul serviciului efectuat. Aceste opțiuni pot fi extinse
pe un model de tip abonament, în care un client îşi face un abonament la un portal
de servicii mobile şi poate beneficia într‐o perioadă de timp de mai multe comenzi
de tip „execute a service”.
Considerăm că pentru creşterea flexibilității unui astfel de portal ar fi indicată
implementarea unei comenzi de tip „negociate”, care să permită unui client să
negocieze cu furnizorul diverşi termeni ai relației contractuale (preț, timp de
execuție, parametri de execuție). În acest caz, presupunând că furnizorul acceptă
termenii negocierii, pe portal va fi disponibil un nou serviciu, care inițial nu apărea
în lista de servicii disponibile.

CAPITOLUL 10
Platforme tehnologice revoluţionare
în secolul XXI

& înţelegeţi ce înseamnă revoluţia bio pentru noile tehnologii
informaţionale;
& aflaţi că prima tehnică de punere în comun a puterii calculatoarelor a
fost tehnica clustering;
& cunoaşteţi câte ceva despre grid computing;
& aflaţi că puteţi plăti pentru resursele informatice atât cât consumaţi;
& vă familiarizaţi cu „moda” cloud computing şi să înţelegeţi ce înseamnă
un nor informaţional;
& descoperiţi Software as a service ca ultima modă în externalizarea
proceselor de afaceri;
& aflaţi dacă firmele de top ERP au ofertă competentă SaaS.

10.1. Revoluţia bio în NTI

Începând cu al optulea deceniu al secolului XX, în mass‐media s‐a propovăduit
revoluţia internet. Datorită fenomenului internet, viața noastră are din ce în ce mai
multe trăsături globale, desfăşurându‐se într‐un spațiu al interferențelor multiple:
culturale, educaționale, sociale, geopolitice, tehnologice, informaționale etc., venite
din toate direcțiile, un spațiu numit, cu mult timp în urmă, sat global1. Tehnologia
informatică este principalul vector al globalizării şi aplatizării descrise magistral de
Thomas Friedman în celebra sa lucrare Pământul este plat. Scurtă istorie a secolului
XXI2. Aplatizarea lumii globale înseamnă crearea unei platforme globale care să
genereze numeroase modalități de a împărți cu ceilalți munca, cunoaşterea,
resursele şi divertismentul. Platformele securizate web au deschis era magazinelor
online, cu furnizori globali, clienți globali şi concurență globală. Platformele fluxului
de lucru (workflow) au permis organizațiilor să dezmembreze orice loc de muncă şi
să‐l atribuie prin contract unui centru aflat oriunde pe Glob, care poate îndeplini cel
mai eficient şi cel mai ieftin sarcina respectivă (fenomen cunoscut sub denumirea de
externalizare). Viteza la care se desfăşoară afacerile se datorează faptului că fiecare
dintre noile tehnologii devin din ce în ce mai uşoare, mai mici, mai personale, mai
mobile, digitale şi virtuale.
Totuşi, resursele planetei nu sunt nelimitate, iar balanța fragilă a ecosistemului
planetei este amenințată de o poluare din ce în ce mai mare. Cu toţii suntem chiriaşii
acestei planete, iar testul actualei generaţii de pământeni este dacă va fi în stare să o
transmită urmaşilor întro stare la fel de bună sau mai bună decât cea în care a fost
preluată de la generaţiile precedente. Cu această grijă în spate, oamenii s‐au îndreptat
spre cercetarea salvării resurselor actuale, tezaurizarea lor pentru generațiile viitoare
şi astfel revoluţia bio a devenit noua mişcare a secolului XXI. Ca soluții bio3 au fost
identificate: oferirea de stimulente materiale angajaţilor pentru reducerea consumului
de energie, monitorizarea consumului de energie, închiderea staţiilor de lucru când nu
sunt utilizate sau achiziţia de laptopuri bio, garantarea conexiunii între platformele
pentru afaceri, investiţii în cercetarea arhitecturilor de recunoaştere a datelor,
indiferent de formatul acestora, investiţii în companii smart grid, închirierea puterii de
procesare nefolosite, cedarea puterii de procesare pentru cercetare, proiecte care privesc
viitorul şi sănătatea omenirii sau calculul vitezei de schimbare a climei la nivel planetar.

1 M. McLuhan, The Gutenberg Galaxy: The Making of Typographic Man, University of Toronto Press,
1962.
2 T. Friedman, Pământul este plat. Scurtă istorie a secolului XXI, Editura Polirom, Iaşi, 2007.
3 ***, Smart Grid Definition, http://www.smartgrids.eu/?q=node/163; ***, The European Electricity
Grid Initiative (EEGI) Roadmap 2010‐18 and Implementation Plan 2010‐12, http://www.smartgrids.
eu/documents/EEGI/EEGI_Implementation_plan_May%202010.pdf
Platforme tehnologice revoluţionare în secolul XXI 323
După un an de la iniţierea campaniei naţionale Amprenta de carbon – află cât risipeşti din
viitorul tău, asociaţia „Generaţia Verde” anunţă rezultatele oficiale cu privire la media
reală a emisiilor de carbon din România: 28.320 de persoane şiau calculat dea lungul
unui an amprenta de carbon
La 5 iunie 2010, de Ziua mediului, sa împlinit un an de când asociaţia „Generaţia Verde”,
alături de Ministerul Mediului, Ambasada Marii Britanii, Centrul de Informare ONU
România şi Universitatea Ecologică Bucureşti, a demarat campania naţională „Amprenta de
carbon – află cât risipeşti din viitorul tău”, campanie care stă la baza studiului naţional
desfăşurat în cadrul UEB, cu privire la media reală a emisiilor de CO2 ale populaţiei la nivel
naţional. Componenta principală a campaniei a fost calculatorul de CO2, acesta fiind bazat
pe studii legate de impactul CO2 al activităţii umane în România. El calculează emisiile de
CO2 anual la nivel personal (amprenta personală), emisiile locuinţelor noastre (amprenta
locuinţei), precum şi amprenta aparaturii pe care o folosim pentru confortul nostru
(amprenta aparaturii).
Amănunte despre „Generaţia Verde” din România: http://www.generatiaverde.ro/?option=com_
content&view=article&id=55

Dezvoltarea afacerilor în mediul virtual şi informatizarea lanțurilor de afaceri
au necesitat investiții uriaşe în platforme hardware sofisticate. În satul global al lui
McLuhan există un parc uriaş de maşini de calcul de talie mare (supercalculatoare şi
mainframe) şi de calculatoare de toate tipurile şi arhitecturile, mai mult sau mai
puțin miniaturizate. Acest parc este folosit la întreaga capacitate doar într‐un sfert
din timpul de lucru. Cercetătorii au căutat soluții pentru această ineficiență şi s‐au
îndreptat spre internet, ale cărui tehnologii s‐au maturizat şi care deține
infrastructura necesară salvării resurselor informatice actuale. Astfel, tot ce
înseamnă putere de calcul, spaţiu de stocare şi software va coexista la un
moment dat exclusiv pe internet, întro reţea complexă şi imensă de servere,
care le va furniza utilizatorilor sub formă de servicii, accesibile pe nişte
dispozitive banale de navigare web4. Dacă la început a fost inventată tehnica de
clustering, evoluția a însemnat grid computing şi s‐a finalizat cu cloud computing,
care a devenit cap de afiş în cercetările actuale (figura 10.1), fenomen asociat în
lumea afacerilor cu practica Software as a Service (SaaS).

4 Afirmație preluată pe forumuri, bloguri personale sau profesionale din România: http://www.alex‐
popescu.ro/?p=185; http://devirusare.com/2010/07/20/panda‐cloud‐antivirus‐1‐1‐2‐final/; http://www.

clubkiaromania.ro/forum/electronica‐f295/telefonie‐mobila‐t595‐90.html etc.


Sursa: Adaptare după Janakiram, M., Demystifying the Cloud, http://janakiramm.ulitzer.com/
node/1071479
Figura 10.1. Evoluţie tehnologică spre Cloud Computing

Repede, dar sigur, cloudul se impune şi în România5, evoluţia pozitivă este dictată de la
cartierele generale ale multinaţionalelor. 55% dintre companiile mari din România folosesc,
sub diverse forme, tehnologii din categoria cloud computing, arată studiul „Cloud Adoption
2012”, realizat la cererea CIO Council (Asociaţia Directorilor de Tehnologia Informaţiilor şi
Comunicaţii din România) de compania Consult Blue, în perioada 2125 mai 2012, pe baza
răspunsurilor date de membrii asociaţiei. La studiu au participat 29 de companii. 55%
dintre companiile analizate au peste 500 de angajaţi.
Rezultatele arată că tehnologiile cloud au trecut şi în România de ceea ce se numeşte „point of
no return”, punctul de unde întoarcerea nu mai este posibilă, iar gradul de adopţie va creşte
în următorii ani. Mai mult, 52% dintre companiile respondente au în plan să investească în
tehnologii cloud în următoarele 12 luni.
Studiul mai arată că, deşi companiile mari au înţeles că adevărata putere a cloud stă în
serviciile de cloud public, încă se concentrează pe dezvoltarea propriului cloud. Raţiunile
sunt de multe ori mai puţin obiective, legate de confidenţialitate sau, eventual, de securitate
sau disponibilitate. 20% dintre participanţii la studiu folosesc cloud public în asociere cu cel
privat şi doar 10% utilizează exclusiv cloud public.

10.2. Grid computing

În anii ’90 a apărut conceptul de megacomputing, prin care erau descrise
proiectele în care erau interconectate toate centrele care dețineau superservere, în
ideea de a cumula puterea acestora de procesare. În aceeaşi perioadă s‐a trecut
tehnologic la tehnica de clustering. La modul general, un cluster înseamnă o grupare
de elemente care au caracteristici apropiate. Tehnica este folosită în foarte multe

5 Preluare după V. Bîrzoi, „Jumătate din companiile mari din România folosesc deja cloud computing‐
ul”, http://www.businesscover.ro/30‐05‐2012‐jumatate‐din‐companiile‐mari‐din‐romania‐folosesc‐
deja‐cloud‐computingul/
domenii, cel mai des întâlnit este cel de matematică şi algoritmică de tip
computațional. Ideea de bază este crearea unei resurse comune la nivel global. În
cazul calculatoarelor, tehnica oferă posibilitatea virtualizării serverelor şi permite
configurarea calculatoarelor cu ajutorul unor protocoale speciale, astfel încât
acestea să comunice între ele. Scopul urmărit a presupus echilibrarea sarcinii de
lucru între mai multe maşini, împărțirea în mai multe unități şi distribuirea pe mai
multe procesoare. Astfel, s‐a ajuns la „ferme” de servere şi a fost posibilă apariția
centrelor de date. Virtualizarea serverelor6 permite însă ameliorarea calității
aplicațiilor critice prin soluțiile de distribuire a resurselor (realocare dinamică), ce
pot fi parametrizate în funcție de importanța aplicațiilor. Maşinile virtuale pot fi
transferate automat de pe un server fizic pe un altul, nu doar în cazuri de pană, ci
ținând cont de criterii mult mai complexe precum gradul de încărcare a capacității
de procesare, memorie etc. Astfel, prin intermediul acestor instrumente, dacă un
server care execută o aplicație critică se apropie de nivelul de saturare, acesta va fi
transferat pe un server mai puternic şi/sau cu mai multe resurse disponibile.
În paralel, a apărut noțiunea de grid ca metaforă pentru o rețea distribuită
care are capacitatea de a oferi resurse în funcție de necesitățile utilizatorilor.
Conceptul7 de grid computing a trecut din lumea ştiințifică şi a cercetărilor în lumea
afacerilor prin investiția unor mari companii precum IBM, Oracle, HP, Dell, Microsoft
etc., care s‐au implicat şi în proiecte de acest gen. Prioritatea cercetărilor este
orientată către sistemul de securitate, crucial în vederea reuşitei gridului. Crearea
unei resurse comune la această scară implică multe dificultăți la nivelul imple‐
mentării şi al securității, mai ales dacă ținem cont de faptul că resursele aparțin unor
persoane şi instituții diferite şi că au diverse domenii administrative, rulează
platforme diferite şi au politici de acces şi de securitate diferite. O altă preocupare
ține de managementul eficient al resurselor, prin care să se evite gâtuirea traficului
în rețea şi, implicit, timpii morți.
Datorită vitezei mari de procesare la care s‐a ajuns în ultimii ani, grid
computing are un impact real nu doar în mediul academic şi în cercetare, ci şi la
nivelul întreprinderilor. Enterprise Grid Alliance (EGA) este o alianță a unui grup de
furnizori IT (printre care se regăsesc şi IBM, Microsoft, Oracle), care cercetează
importanța tehnologiei grid computing pentru platformele:
comerciale – sisteme integrate: ERP, CRM, şi BI;
de analiză de portofoliu din sectorul financiar.
Dintre ofertanții8 grid computing amintim: IBM, Sun, Oracle, Microsoft şi
Hewlett Packard.

6 R. Ghițulescu, „Cum să demarezi un proiect de virtualizare a serverelor”, Market Watch, nr. 116, iunie
2009, disponibil la http://www.marketwatch.ro/articol/5012/Cum_sa_demarezi_un_proiect__de_

virtualizare_a_serverelor/
7 C. Tena, „Grid Computing – ultima frontieră”, Market Watch, nr. 72, iunie 2005, disponibil la
http://www.marketwatch.ro/articol/574/Grid_Computing‐ultima_frontiera/
8 P. Plazsczak, R. Wellner, Grid Computing – The Savy Manager’s Guide, Morgan Kaufmann Publishers,
San Francisco, 2006.

La capitolul beneficii enunțăm sporirea vitezei de calcul şi reducerea duratei
de procesare, alături de posibilitatea dezvoltării proiectelor de cercetare la costuri
reduse.
Provocarea pentru structurile de tip grid se referă la implementarea
platformelor de legătură (middleware) pentru integrarea depozitelor de date,
rețelelor şi a calculatoarelor. De asemenea, implementarea de clustere, confundate
uneori cu grid, ridică, o problemă importantă. Principala diferență9 între cele două
tehnologii constă în modul de gestionare a resurselor. În cazul clusterelor, alocarea
resurselor este realizată de un centru sau de mai multe centre. Toate însă lucrează
cooperativ ca o singură resursă unitară. Grid computing presupune existența unor
centre care îşi gestionează independent resursele şi nu se urmăreşte obținerea unei
imagini unitare.
De asemenea, deoarece gridul nu poate funcționa fără suportul furnizorilor de
resurse, dezvoltarea structurii depinde de implicarea comunităților, care trebuie să
colaboreze prin partajarea resurselor. Astfel, apar probleme tehnice şi sociale care
privesc securitatea rețelelor, metodele de plată pentru acces şi prioritatea în
utilizare. Alte obstacole sunt: dimensiunea mare a sistemului, eterogenitatea şi
numărul mare al programelor executate în paralel, variații de încărcare a sistemului,
coordonarea simultană a unor componente independente structurii grid.
Soluțiile sunt aşteptate din partea mai noului val cloud computing sau prin
rezolvarea prin cercetare şi proiecte‐pilot a problemelor legate de securitate.

10.3. Cloud computing

Cloud computing este un nou brand în lumea dezvoltatorilor de software, care
descrie cam cum va arăta lumea informatică în viitor şi reprezintă una dintre
componentele fundamentale ale web 3.0. Cel mai des întâlnită analogie a
conceptului este cea cu energia electrică: aşa cum ne‐am obişnuit să consumăm
energie electrică la cerere de la o priză electrică, putem accesa aplicații informatice
şi servicii de stocare la cerere, plătind doar resursele consumate. Principalul
beneficiu10 promis de această tehnologie este reducerea costurilor, prin plata
eşalonată, investițiile în infrastructură fiind evitate.
O problemă majoră a cloud‐ului este conferită de confuzia care domneşte pe
fundalul nenumăratelor definiții. Acesta este şi motivul diferențelor de opinii11 în
ceea ce priveşte costul real al serviciilor furnizate, pentru că tehnologia are costuri
ascunse referitoare la transformarea sistemului actual al companiei, implementarea
integrării, instruirea personalului, reproiectarea arhitecturii şi a proceselor
implicate.

9 ***, Grid Computing Info Center – Frequently asked questions, disponibil la http://www.
gridcomputing.com/gridfaq.html
10 N. Ward‐Dutton, „The Seven elements of Cloud Computing’s Value”, http://www.ebizq.net
/blogs/softwareinfrastructure/2009/08/the_seven_elements_of_cloud_co.php
11 C. Curran, „Beware Cloud Computing’s hidden costs”, http://www.cio.com/article/506719/
Beware_Cloud_Computing_s_Hidden_Costs
Soluția cloud este ca un balon de oxigen pentru întreprinderile mici şi mijlocii
în lupta de supraviețuire pe piață, în contextul accesului la o infrastructură
complexă și evitarea implementării şi administrării efective a acesteia. Deloc de
neglijat sunt şi mobilitatea şi ubicuitatea tehnologiei, deoarece permite accesul la
datele companiei de oriunde şi oricând.
Provocarea principală este generată de fapt de problemele şi riscurile
internetului în general: disponibilitatea datelor, securitatea mediului‐suport,
imprevizibilitatea performanțelor şi dependența față de furnizor. Aceeaşi
vulnerabilitate apare şi în contextul transferului de date personale sau confidențiale
prin e‐mail sau în cazul conversațiilor de messenger. Astfel, angrenarea
tehnologiilor cloud computing în activități de afaceri are ca principale impedimente
lipsa controlului asupra datelor, dependența față de furnizor sau intermediari şi
insecuritatea mediului.
Totuşi avem şi exemple de companii‐pionier în domeniu: Salesforce.com în
gestionarea relațiilor cu clienții prin CRM, Dropbox pentru servicii de stocare a
datelor, de sincronizare, backup şi Amazon Elastic Computing Cloud pentru
capacitate de calcul personalizată.
Literatura de specialitate prezintă şase modele cloud computing12:
1) public cloud, cloud extern sau multichiriaş, pune la dispoziție o
infrastructură IT pentru un centru fizic de date şi se caracterizează prin
infrastructură omogenă, chiriaşi cu interese comune şi model de cost‐cheltuieli
operaționale;
2) private cloud, cunoscut şi sub numele de cloud intern sau cloud‐on‐
premise limitează în mod intenționat accesul la resursele sale pentru consumatorii
de servicii la o singură organizație. Se caracterizează prin infrastructură eterogenă,
politici personalizate, resurse dedicate, infrastructură inhouse, modelul de cost‐
cheltuieli de capital şi control continuu;
3) community cloud – mai multe organizații au cerințe similare şi sunt
interesate să folosească aceeaşi infrastructură. De obicei, regulile sunt stricte, acest
lucru implicând costuri importante, dar se obține un nivel înalt de securitate. Un
exemplu de acest gen este Google Gov. Cloud;
4) hybrid cloud – este un model compus din două sau mai multe modele din
cele prezentate anterior, care rămân entități unice; a devenit posibil datorită
standardizării; asigură portabilitatea datelor şi aplicațiilor;
5) dedicated cloud, hosting cloud sau virtual private cloud reprezintă medii
cloud găzduite şi gestionate dedicat pentru un tip de afacere, un proiect sau o
cercetare de amploare. Este o soluție destinată mediilor private de afaceri;
6) intercloud presupune interconectarea la nivel global pentru a oferi o
colecție masivă de servicii în colum de rețele de parteneri de afaceri.
Cloud computing este asociat cu SaaS pe piața afacerilor.

12 K. Staten, How to Build a Hybrid Cloud Computing Strategy, http://local.clevescene.com/
Building_a_Hybrid_Cloud_Computing_Strategy_Euclid_OH‐r1277269‐Euclid_OH.html; P. Mell, T. Grance, „The
NIST Definition of Cloud Computing Strategy”, http://www.rationalsurviva bility.com/blog/?p=870

Soluţia ERP Open Source a companiei Compiere (una dintre cele mai populare soluţii OSS la ora
actuală la nivel mondial) este disponibilă şi sub oferta cloud computing, fiind migrată pe
platforma Amazon dedicată (EC2). Prin această ofertă, Compiere oferă companiilor
posiblitatea de a accesa pe internet modulele de contabilitate, achiziţii, gestiune a
comenzilor, producţie şi stocuri, dar şi soluţia CRM integrată. Compiere nu a făcut public
încă preţul abonamentului (prezentat de oficiali drept foarte mic). Oferta completă pentru
Compiere ERP Cloud Edition include soluţia software, serverul de aplicaţii şi baza de date, la
care se adaugă gama de servicii Compiere, toate dezvoltate pe platforma Amazon EC2.
Principalul beneficiu al acestei oferte rezidă în facilitatea implementării şi dezvoltării
aplicaţiei, partea de infrastructură, customizare, mentenanţă, upgrade etc. rămânând în
sarcina Compiere, dar nu este de neglijat nici avantajul plăţii la consum, unul dintre atuurile
esenţiale al ofertelor cloud computing.
Prin această ofertă, cei de la Compiere speră să poată concura cu actori consacraţi ai pieţei
ERP, precum SAP sau Oracle, care au întârziat să intre în zona cloud, atrăgând clienţi din
zona IMM (Rămâne de văzut cum va reuşi Compiere să reducă reticenţa acestora faţă de un
concept încă nebulos...).
De menţionat că Socrate Open, ERPul oferit de compania BIT Software (unul dintre puţinii
ofertanţi de soluţii informatice complexe open source de pe piaţa locală), este construit pe
baza soluţiei Compiere ERP/CRM Open Source.
(Sursa: Ghiţulescu, R., „ERP‐ul Compiere este disponibil în varianta Cloud Edition”, Market
Watch, martie 2009, disponibil la http://www.marketwatch.ro/articol/4437/ERPul_Compiere_
este_ disponibil_in_varianta_Cloud_Edition/)

10.4. De la externalizare, la Software as a Service în ERP

În economia globală, serviciile oferite mediului de afaceri au fost în
permanență un segment caracterizat printr‐o creştere rapidă. Unul dintre factorii
care au favorizat dezvoltarea acestui sector îl constituie şi deschiderea spre
externalizare13. Zona IT nu a fost ocolită nici de această tendință, extrem de benefică
de altfel. În acest context, externalizarea se referă la procedura de transferare a unei
activități (secundare) din cadrul companiei către o altă firmă, în scopul vădit de
maximizare a performanțelor, întrucât outsourcer14‐ul deține o expertiză superioară
în sectorul de activitate contractat.

10.4.1. Externalizarea serviciilor – concepte de bază

Din punctul de vedere al beneficiarului externalizării, scopul principal al
subcontractării de servicii este de a transfera un proces operaţional sau o funcţiune
unei entităţi/organizaţii cu experienţă specifică întrun anumit domeniu, în vederea
obţinerii unei economii de costuri operaţionale şi îmbunătăţirii calităţii şi valorii

13 În limba engleză, outsourcing.
14 Agenția/firma care furnizează servicii solicitate de o altă companie.
produselor/serviciilor oferite partenerilor. Subcontractarea serviciilor se poate face

prin apelarea la serviciile unei entități economice situate în aceeaşi piață (onshore
outsourcing), în piețe apropiate din punct de vedere geografic sau cultural
(nearshore outsourcing) sau în străinătate (offshore outsourcing), aşa cum reiese din
tabelul 10.1.
Tabelul 10.1
Formele outsourcingului

Localizarea întreprinderii
În economia În economia
Transferul
naţională internaţională
activităţii către
întreprinderea nonafiliată Externalizare Offshore
(interîntreprindere) locală/domestică outsourcing/offshoring
(Onshore outsourcing)
întreprinderea afiliată Externalizare captivă/în Delocalizare captivă
(intraîntreprindere) cadrul întreprinderii (Offshoring captiv)
(Onshore outsourcing
captiv)
Surse: Adaptare după Olsen, K.B., Productivity Impacts of Offshoring and Outsourcing: A Review, OECD,
2006, p. 9, http://www.oecd.org/sti/working‐papers şi Friedman, L‐T., Pământul este plat, Editura
Polirom, Iaşi, 2007, pp. 112‐130.

Din perspectivă conceptuală, prin externalizare înţelegem procesul prin care o
activitate este transferată pentru a fi realizată de o altă întreprindere. Din punct de
vedere strategic, externalizarea trebuie considerată ca o activitate pe termen lung,
menită să asigure nu doar supraviețuirea, ci şi prosperitatea întreprinderii. Pe
termen scurt, externalizarea este o tactică (neloială față de angajați) folosită în
scopul reducerii locurilor de muncă, a costurilor cu salariile sau eliminării
condițiilor şi drepturilor obținute de angajați prin negocierile colective15.
Din punct de vedere istoric, modelele de externalizare au evoluat în sensul
asigurării funcționalității tuturor proceselor şi funcțiilor economice ale
întreprinderii. Aşa cum reiese din figura 10.2, la început, în anii ’60, externalizarea a
vizat distribuirea componentelor hardware şi software. În anii următori au fost
externalizate aplicații specifice, orientate mai mult pe procese decât pe tehnologie,
iar în cadrul celor de ultimă generație, componentele IT şi tehnologice au scăzut în
intensitate, acordându‐se o mai mare importanță funcționalităților economice din
cadrul întreprinderii.
În momentul de față, în privința externalizării, noutatea constă în amploarea
deosebită înregistrată în cadrul serviciilor de orice tip, dar mai ales în rândul
serviciilor financiare şi informatice. Mult timp sectorul serviciilor a fost considerat
impenetrabil de concurența internațională, însă, odată cu îmbunătățirea tehnologiei
comunicațiilor şi mai ales a internetului, serviciile pot trece granițele politice prin

15 V.D. Păvăloaia, Integrarea tehnologiilor informaţionale în analiza financiară, Editura Universității
Alexandru Ioan Cuza”, Iaşi, 2008, pp. 99‐100.

intermediul conexiunilor specifice şi al rețelelor, obținându‐se astfel beneficii

concretizate în accesul la forță de muncă ieftină, dar bine pregătită16.

Sursa: Adaptare după Gewald, H., Konig, W., Predicting the adoption of BPO. The role of preceived
risk and technology acceptance, Institut für Wirtschaftsinformatik, Frankfurt, 2005, p. 5.
Figura 10.2. Evoluţia în timp a modelelor de externalizare

Deşi ar fi de aşteptat ca externalizarea serviciilor să aducă beneficii pe termen
lung, ar putea exista şi o serie de costuri de ajustare17, sub forma pierderilor de
locuri de muncă, proces vizibil mai ales la nivel microeconomic, întrucât chiar şi în
țările avansate procesul de externalizare a serviciilor este la început de drum.
Concret, beneficiile18 ce revin întreprinderii prin externalizarea serviciilor IT
sunt, în linii mari, aceleaşi ca în cazul externalizării serviciilor de alt tip. Există totuşi
o serie de particularități, motiv pentru care prezentăm în continuare avantajele de
bază ale externalizării (în principal, reducerea costurilor), combinate cu avantajele
specifice externalizării serviciilor IT19:
beneficiul obținut datorită utilizării, pe termen scurt, a unor competențe
tehnice de nivel înalt (accesul, pentru perioade scurte de timp, la resurse software şi
umane calificate, precum şi la o infrastructură tehnică avansată);
accesul la proceduri de lucru şi tehnologii inexistente în cadrul
întreprinderii;
transferul riscurilor asociate soluției tehnice şi implementării sistemului;
stabilirea unui nivel al serviciilor IT şi transferul total către furnizorul
extern al tuturor responsabilităților aferente nivelului;
concentrarea totală a angajaților asupra activităților de bază ale
organizației pentru care dețin avantaje competitive;
optimizarea financiară (simplificarea bugetului destinat cheltuielilor IT
prin alocarea unor sume periodice specificate în contracte multianuale ca, de

16 Comisia Națională de Prognoză, „Măsurarea procesului de externalizare internațională a serviciilor”,
articol susținut în cadrul conferinței The effects of relocation on economic activity: An EU perpective,
www.cnp.ro, p. 1.
17 C. Ferrusi Ross, „Topic Overview: Outsourcing”, Forrester Research, 8 aprilie 2008, www.forrester.com
18 V.D. Păvăloaia, op. cit., p. 165.
19 C. Hristea, „Externalizarea serviciilor IT în administrația publică și ITIL pentru performanța
serviciilor IT”, PM Solutions, București, 2008.
exemplu, asocierea cu parteneri în scopul utilizării infrastructurii de echipamente.
Se înlocuiesc astfel investiții importante cu plata unor chirii);
flexibilitate în adăugarea unor noi servicii;
posibilitatea controlului contractual asupra calității serviciilor furnizate.

În domeniul externalizării serviciilor IT, Eastman Kodak este considerată de literatura de
specialitate ca pionier, întrucât a fost prima companie care a apelat la externalizarea
serviciilor informatice şi de telecomunicaţii. Astfel, în anul 1989, Eastman Kodak şia
externalizat toate activităţile IT firmelor IBM şi DEC, pentru o perioadă de zece ani. Când
Katherine Hudson, având funcţia de CIO la Kodak, a anunţat vestea externalizării, colegii săi
au considerat că aceasta şia pierdut minţile. Timpul a lucrat însă în avantajul acestei
decizii, întrucât a permis companiei Kodak să se concentreze asupra competenţelor de bază,
pentru care deţinea cea mai înaltă expertiză. Nu a durat mult până când exemplul
companiei Kodak a fost urmat de alte companii importante, care au înţeles că nu este
necesar să deţii tehnologia pentru a accesa informaţiile necesare.
(Surse: www.ephorie.de/wunderwaffe_ohne_wunderwirkung.htm şi http://scm.ncsu.edu/public/
facts/facs060531.html)

Strict legate de latura întunecată a externalizării, evidențiem în continuare
câteva dintre dezavantajele acestui proces:
dificultăți sub aspectul comunicării între părți şi diferențe sub aspectul
standardelor aplicate;
pierderea controlului asupra activității externalizate privind calitatea,
corectitudinea şi timpul acordat în rezolvarea cerințelor formulate de contractorul
de servicii;
diferențe culturale şi percepții opuse cu privire la anumite aspecte şi
interpretări;
lipsa expertizei furnizorului de servicii;
supraaglomerarea furnizorului de servicii.
Dincolo de avantaje şi dezavantaje, externalizarea serviciilor nu mai poate fi
tratată cu superficialitate, întrucât a devenit o parte componentă a activității oricărei
organizații ghidate după principiul: dacă nu poţi desfăşura în mod optim o activitate,
apelează la experţi!

10.4.2. Externalizarea serviciilor informatice

Externalizarea aplicațiilor informatice vizează de fapt externalizarea servi‐
ciilor informatice ITO – Information Technology Outsourcing şi constituie o problemă
de mare actualitate. Astfel, întreprinderile apelează la externalizarea aplicațiilor
informatice mai mult ca niciodată şi au la dispoziție o paletă foarte amplă de

furnizori şi tipuri de servicii. O serie de autori afirmă că unele întreprinderi plasează
aplicațiile IT pe locul 1 în cadrul activităților externalizate20.
În încercarea de a defini semnificația noțiunii desemnate prin acronimul ITO,
evidențiem opinia autorilor Ray şi Ganguli21, care afirmă că ITO se referă la utili‐
zarea furnizorilor externi în scopul dezvoltării întreținerii sau reproiectării
arhitecturii IT din cadrul unei întreprinderi.
Printre serviciile IT cel mai frecvent externalizate, regăsim managementul
aplicațiilor informatice (inclusiv dezvoltarea aplicației, testarea, implementarea,
întreținerea şi asistența), managementul infrastructurii IT, serviciile help‐desk
pentru asistența utilizatorilor, serviciile de testare şi validare a aplicațiilor
informatice, managementul operațiunilor din cadrul centrelor de calcul,
implementarea şi activitățile de întreținere a rețelelor, serviciile destinate
supravegherii şi securității IT, serviciile de recuperare a datelor ş.a.
La nivelul externalizării serviciilor IT, remarcăm conceptul de cosourcing,
care face referire la faptul că, în sarcina prestatorului serviciului externalizat, cade şi
controlul parțial sau total al infrastructurii IT. Un alt concept este cel de găzduire
(hosting) a aplicațiilor informatice, caz în care întreprinderea care preia serviciul
externalizat furnizează infrastructura de rețea şi tehnologiile destinate serverului de
aplicații. În astfel de circumstanțe, clientul rămâne proprietarul aplicațiilor sale, iar
furnizorul trebuie să probeze un nivel ridicat de confidențialitate22.

Compania multinaţională General Motors, cel mai mare nume din industria mondială de
autoturisme, este o mare consumatoare de produse şi servicii IT. În 1998, conducerea a
decis ca toate operaţiunile IT ale companiei să fie externalizate. Beneficiile obţinute în urma
externalizării constau în faptul că General Motors şia redus bugetul destinat achiziţiilor IT
de la cinci la trei miliarde de dolari în perioada 19982003. În anul 2004 sa organizat o
nouă licitaţie în vederea externalizării IT la care au fost invitate numeroase firme de
prestigiu din zona IT, iar valoarea consolidată a acestui contract de externalizare a fost
cifrată la aproximativ 15 miliarde de dolari.
(Sursa: http://www.icmrindia.org/casestudies/catalogue/IT%20and%20Systems/ITSY046.htm)

10.4.3. Software as a Service (SaaS)

În contextul externalizării serviciilor IT, este necesar să abordăm conceptul de
software ca serviciu (SaaS), în care aplicațiile sunt găzduite de un furnizor şi puse
la dispoziția clienților prin intermediul internetului. Deşi această noțiune este relativ

20 B. Martorelli, „Topic Overview: Applications Outsourcing”, Forrester Research, octombrie, 2007,
www.forrester.com, p. 1.
21 M. Ray, J. Ganguli, Global Technology Guide (GTAG) 7: Information Technology Outsourcing, The
Institute of Internal Auditors, 2007, www.theiia.org/technology
22 V.D. Păvăloaia, op. cit., p. 102.
recentă, implicațiile acestui model nu sunt noi industriei software, din moment ce pe
piață existau şi înainte câteva modele similare (ASP – Application Service Provider şi
Serviceondemand). Larga răspândire a SaaS este justificată şi de faptul că atât
tehnologiile care susțin serviciile web, cât şi arhitectura sofware bazată pe servicii
(SOA) sunt într‐o continuă dezvoltare, iar noile modalități de abordare devin tot mai
populare în rândul organizațiilor beneficiare.
Eforturile întreprinse de providerii de servicii internet – ISP 23, de a mări
lungimea de bandă, de a utiliza microprocesoare puternice şi de a oferi o platformă
uriaşă privind proiectarea, valorificarea, desfăşurarea şi folosirea de produse
software pentru toate domeniile de afacere, sunt valorificate din plin de aplicațiile
SaaS.
Aplicațiile SaaS impun necesitatea interacționării cu date şi platforme diferite,
motiv pentru care SaaS se înrudeşte cu cel puțin două modele de transmitere:
1) modelul de management al aplicației găzduite, similar cu modelul de
furnizare de servicii ale programelor ASP (găzduieşte produsul software şi îl
livrează beneficiarilor prin intermediul internetului);
2) modelul Softwareondemand, în care furnizorul acordă clienților acces în
rețea la o singură copie a aplicației, personalizată conform preferințelor acestora.
Arhitectura aplicațiilor bazate pe SaaS are în vedere sprijinirea lucrului
utilizatorilor în mod concurent. Acest aspect diferențiază de altfel conceptul SaaS de
ASP – furnizorul de servicii de tipul aplicațiilor client‐server.
Strict legat de costul serviciilor SaaS, clientul poate opta pentru două variante:
1) achitarea unui abonament lunar sau anual;
2) plata contravalorii unui anumit număr de ore pe parcursul cărora s‐a
accesat aplicația.
Tot legat de costurile accesării, furnizorii SaaS au o politică de prețuri bazată
pe numărul utilizatorilor care accesează serviciul. Pe lângă acesta, există şi costuri
adiționale aferente folosirii serviciilor de tip help desk, lățimii de bandă şi
depozitării informațiilor. Inițial, fluxurile de venituri recepționate de furnizorul de
servicii SaaS sunt mai mici decât nivelul costurilor de licență, însă această problemă
se remediază în timp, printr‐un management eficient al clienților.
Printre caracteristicile de bază ale aplicațiilor SaaS menționăm:
accesul aplicațiilor prin intermediul internetului, din orice locație;
livrarea aplicațiilor pe sistemul 1‐la‐multe, opus modelului tradițional 1‐la‐1;
centralizarea aplicațiilor şi oferirea de actualizări.
În ceea ce priveşte adresabilitatea, serviciile de tip SaaS au înregistrat o
popularitate ridicată, cu precădere în rândul companiilor mici şi mijlocii, datorită
costurilor reduse şi a flexibilității în utilizare.
Din ce în ce mai multe companii apelează la serviciile SaaS pentru aplicații de
întreprindere în vederea gestionării diferitelor activități precum relațiile cu clienții
(CRM). În acest sens, avantajul oferit de modelul SaaS este de a asigura organizația
că toate locațiile folosesc aceeaşi versiune şi că formatul datelor înregistrate şi

23 ISP – Internet Service Provider.

transmise este curent, compatibil şi corect. Responsabilitatea aplicațiilor este

plasată providerul SaaS şi, datorită acestui fapt, companiile îşi reduc povara aferentă
administrării şi gestionării propriilor programe (licențe, actualizări de software,
întreținere etc.). SaaS oferă şi servicii privind înregistrarea în loguri a tuturor
tranzacțiilor efectuate în cadrul sesiunii de lucru. Succint, printre beneficiile aduse
prin adoptarea softwareului ca serviciu regăsim:
uşurință şi eficiență în administrare;
automatizarea procesului de actualizare software şi servicii de manage‐
ment al patch‐urilor;
accesibilitate globală a aplicației (poate fi accesată de oriunde atâta timp
cât există acces la internet);
compatibilitatea datelor şi gradul ridicat de colaborare datorită lucrului
tuturor utilizatorilor cu aceeaşi versiune a aplicației.
În tabelul 10.2 sunt prezentate, comparativ, avantajele aduse de SaaS atât
furnizorilor, cât şi clienților.

Tabelul 10.2
Situaţie comparativă a avantajelor SaaS

Beneficiile aduse de SaaS:
clienţilor furnizorilor
• Reducerea timpului de implementare: • Mediul de operare: furnizorul este
durează câteva minute, spre deosebire de o proprietarul domeniului. Acesta deține
implementare pe etape, care ar putea dura controlul complet în vederea optimizării
luni de zile infrastructurii cerințelor specifice aplicației
• Disponibilitatea globală: se referă la SaaS, aspect care generează economii
disponibilitatea aplicațiilor de a fi accesate financiare
de oriunde, condiția, accesul la internet • Venituri previzionabile: modelul de
• Infrastructura zero: cheltuielile generale abonament asociat cu SaaS îi determină pe
reduse datorită găzduirii aplicației de clienți să plătească un program recurent.
furnizorul de servicii. Investițiile Dacă acest ciclu este suficient de flexibil, se
costisitoare în infrastructură nu mai sunt poate obține o prognoză asupra veniturilor
necesare. Toate investițiile inițiale mari • Creşteri previzibile: la fel ca în cazul
prilejuite de achizițiile hardware, licențe, anterior, dar aici ne referim la volumul de
baze de date şi alte cheltuieli generate de subscrieri, care poate fi previzionat
angajarea şi formarea personalului IT, • Concentrarea pe upgradeuri mici în
softwareul şi întreținerea hardware şi locul implementărilor de patchuri:
upgrade‐urile sunt gestionate de furnizor echipele de dezvoltare se pot concentra în
• Ofertele de o calitate mai bună la totalitate asupra funcționalității aplicației,
costuri mai mici: cu cât sunt mai mulți combaterii bug‐urilor şi îmbunătățirii
clienți, cu atât costurile de funcționare funcțiilor elementare implementate
continuă să scadă pentru fiecare client. • Vânzările devin customer relationship
Acest lucru oferă furnizorului de SaaS management: este important ca furnizorul
capacitatea de a oferi reducerea costurilor, să dețină o echipă care să se ocupe de
în timp real distribuția aplicațiilor – adică abonații să
• Libertatea de alegere: facilitează stea la uşă – dar forța reală a noii vânzări şi
trecerea uşoară de la un furnizor de soluții marketing în Saas constă în managementul
Beneficiile aduse de SaaS:
clienţilor furnizorilor
la altul. Acest lucru este posibil deoarece relațiilor cu clienții. Ecuația devine destul
clientul nu este blocat în investiții în de simplă: se păstrează rata de retenție mai
infrastructura IT (servere, software sau mare decât rata de pierdere a clienților şi se
sisteme de securitate). Această libertate de concentrează pe atragerea de noi clienți
schimbare funcționează ca un motivator
pentru a oferi caracteristici cât mai bune şi
pentru a asigura o performanță optimă
Sursa: Adaptare după http://www.teamwox.com/en/teamwox/tutorials/71, http://www.parallels.
com/eu/products/saas/benefits/ şi http://www.cloudtweaks.com/2010/08/advantages‐of‐saas‐software‐
as‐a‐service/

Literatura de specialitate24 indică faptul că, prin maturizarea pieței aplicațiilor
SaaS, furnizorii înregistrează evoluția sintetizată pe trei „valuri” (figura 10.3).
1) Primul val, perioada 20012006, versiunea Saas 1.0: presupune înlocuirea
aplicațiilor vechi – la început, furnizorii de soluții SaaS au transformat aplicațiile
depăşite în soluții moderne, care răspundeau noilor cerințe. Focus: livrare de
produse software la un cost acceptabil.
2) Al doilea val, perioada 20052010, versiunea Saas 2.0: utilizează conceptul
SaaS pentru rezolvarea de probleme noi, care nu puteau fi soluționate de aplicațiile
vechi. Odată cu apariția pe piață a primelor implementări SaaS, organizațiile au
întrevăzut avantajele modelului SaaS, care îşi propune soluționarea unei mari
varietăți de probleme printr‐o arhitectură nouă, centrală. Focus: soluţii integrate de
afaceri.
3) Al treilea val, perioada 20082014, versiunea Saas 3.0: se referă la adăugarea
de noi servicii SaaS în vederea obținerii unor aplicații cu valoare ridicată. În acest
mod, datele colectate pot fi folosite în vederea generării de rapoarte care oferă
clienților o viziune nouă atât asupra performanțelor organizației, cât şi asupra pieței
în general. Focus: activarea/implementarea tehnologiilor Workflow.

24 M. West, M. Koenig, Three Waves of Change: SaaS Beyond the TippingPoint, mai 2007,
http://www.saugatech.com şi B. McNee, SaaS: Beyond the Tipping Point, Saugatuck Technology, iunie,
2007, http://jcwiki.jamcracker.com/wiki/images/3/3f/Sandhill_Study_on_SaaS.pdf


Surse: http://jcwiki.jamcracker.com/wiki/images/3/3f/Sandhill_Study_on_SaaS.pdf şi http://www.slideshare.
net/digitallibrary/saas‐and‐the‐third‐wave?src=embed
Figura 10.3. Cele trei valuri evolutive SaaS

Specialiştii preconizează25 că Valul al treilea va include ecosisteme de afaceri
care includ platforme verticale pe tipuri de industrii, colaborări interorganizaţii,
infrastructura ca serviciu (IaaS–InfrastructureasaService) şi utilizarea masivă a
tehnologiei web 2.0.

10.4.4. SaaS şi SOA

La fel ca în cazul altor produse software şi aplicațiile dezvoltate după modelul
SaaS pot beneficia de pe urma avantajului comunicării între aplicații, impus de SOA.
În acest context, fiecare serviciu software poate acționa la rândul său ca un furnizor
de servicii, punând la dispoziția altor aplicații propriile funcționalități prin diverse
forme. Mai mult, poate juca rolul de solicitant de servicii, încorporând astfel datele şi
funcționalitățile altor servicii. Furnizorii de soluții ERP implementează

25 http://www.limitlesstechnology.com/cms/content/limitless‐technology‐blogs
funcționalitățile SOA în oferta lor de soluții SaaS. Un exemplu în acest sens este SAP
Business ByDesign a producătorului german SAP AG26.
În aceste condiții, de la externalizare la SaaS în cadrul sistemelor integrate
ERP nu este decât un pas, deoarece SaaS este asociat cu aplicații de tipul CRM,
recrutare personal, salarizare şi alte zone informatizate prin sisteme ERP. Faptul că
sistemele ERP sunt aplicații complexe, atât prin structura modulară, cât şi prin
impactul major asupra modului de lucru dintr‐o organizație, face ca aceste sisteme
să nu fie, sau cel puțin să nu pară, cel mai potrivit tip de aplicație livrabilă în regim
SaaS. Totuşi, în ultimii ani, au existat suficiente colaborări cu soluțiile ERP care să‐i
convingă pe cârcotaşi să‐şi schimbe opinia vizavi de faptul că tandemul SaaSERP
nu este viabil. Inevitabil, un ERP în regim SaaS va dispune de mai puţine
funcţionalităţi decât o implementare clasică, pentru că furnizorul va încerca să
standardizeze cât mai mult aplicaţia, pentru a o distribui unei mari varietăţi de clienţi.
Cu toate acestea, majoritatea aplicaţiilor dispun de un set suficient de funcţionalităţi
pentru a acoperi cerinţele de bază ale oricărui client din sectorul IMM27.
În ceea ce priveşte dezvoltarea soluțiilor ERP de tip SaaS, discuțiile inițiale
dintre producătorii de ERP şi furnizorii SaaS au vizat găzduirea aplicațiilor într‐un
centru de date, care asigură obținerea de economii, întrucât clientul va fi scutit de
investițiile aferente echipamentelor şi întreținerii acestora. Ulterior s‐a adaptat
modelul de afacere pe tiparul SaaS şi s‐a recurs la plata unui abonament lunar care
includea un set standard de funcționalități şi servicii minime, fără însă a vinde
licențe clientului28.

10.4.5. Furnizorii de soluţii SaaS

Furnizorii de soluții SaaS, prin utilizarea tehnologiilor moderne, pot reduce
timpul de promovare pe piață a produselor şi pot diminua costul de convertire a
unui produs tradițional într‐o soluție SaaS. Conform opiniei specialiştilor Microsoft,
arhitecturile aplicațiilor SaaS pot fi clasificate într‐unul dintre cele patru niveluri de
maturitate, aşa cum se observă în tabelul 10.3.

Tabelul 10.3
Niveluri de maturitate ale aplicaţiilor SaaS

Nivelul 1 – nivelul ad hoc/nivelul Nivelul 2 – nivelul configurabil/nivelul
haosului haosului controlat
Fiecare client deține o versiune unică, Sunt incluse programe mult mai flexibile
preferențială, a aplicației, rulată de pe datorită posibilității de confirgurare a
serverele furnizorului. Migrarea unei metadatelor. Clienții pot utiliza separat
aplicații pe o rețea netradițională solicită instanțele aceleiaşi aplicații. În acest mod,
un efort minim şi se reduc costurile de furnizorul poate satisface nevoile variate ale

26 V. Singla, „The Overlapping Worlds of SaaS and SOA: How SaaS and SOA will enable «IT as a Service»,
Cloud Computing Journal, iulie, 2009, http://cloudcomputing.sys‐con.com/?q=node/1047073
27 G. Vasile, „Cât de aplicabil este conceptul SaaS la ERP?” Market Watch, nr. 120, noiembrie, 2009.
28 Idem nota 23.

operare prin consolidarea harware a clienților şi facilitează procesul de
serverului de aplicații. Pe scurt, adăugarea întreținere şi dezvoltare a aplicației.
unui client nou presupune adăugarea unei
noi instanțe software.
Nivelul 3 – nivelul eficienţei clienţilor Nivelul 4 – nivelul maturităţii scalabile/
multipli/high rise nivelul utopiei
Permite adăugarea de clienți multipli la Scalabilitatea este adăugată printr‐o arhi‐
nivelul anterior. Ca rezultat, un singur tectură multitreptată capabilă să suporte
program poate servi simultan toți clienții programe identice care funcționează pe o
aplicației. Astfel se pot utiliza în mod varietate de servere. Capacitatea sistemului
eficient resursele serverului, fără nicio poate fi mărită sau micşorată în mod
diferență vizibilă pentru utilizatori. Acest dinamic pentru a se potrivi cu solicitările
nivel este însă limitat în ceea ce priveşte venite din partea clienților, fără a fi necesară
capacitatea sa la un anumit număr de modificarea arhitecturii aplicației.
utilizatori.
Sursa: Adaptare după: Chong, F., Carraro, G., Architecture Strategies for Catching the Long Tail,
Microsoft Corporation, http://msdn.microsoft.com/en‐us/library/aa479069.aspx şi Chong, F., Multi
tenancy and Virtualization, http://blogs.msdn.com/b/fred_chong/archive/2006/10/23/multi‐tenancy‐
and‐virtualization.aspx şi http://www.saas‐attack.com/saasmaturitymodel.aspx

Cele patru niveluri de maturitate din tabelul 10.3 şi caracteristicile fiecăruia
sunt surprinse grafic în figura 10.4 de specialiştii Microsoft, conform sursei
http://msdn.microsoft.com/en‐us/library/aa479069.aspx

Sursa: Chong, F., Carraro, G., Architecture Strategies for Catching the Long Tail,
Microsoft Corporation, http://msdn.microsoft.com/en‐us/library/aa479069.aspx
Figura 10.4. Cele patru niveluri de maturitate specifice soluţiilor SaaS

Analiza la nivel mondial, efectuată în perioada 2008‐2010 şi surprinsă în
figura 10.4, ilustrează structura cererii de aplicații SaaS pe zone funcționale, pe
diferite regiuni geografice. Constatăm astfel că, la nivel mondial, în anul 2010,
primele trei zone cel mai frecvent informatizate prin aplicații SaaS sunt:
1) sistemele colaborative (Email, Conferinţe Web) – 66,8%;
2) aplicaţii destinate CRM (Customer Relationship Management) şi SFA (Sales
Force Automation) – 58,9%;
3) soluţii de informatizarea de tip Payroll – 45,8%.
În figura 10.5 observăm că, spre deosebire de anul 2008, în 2010 are loc o
modificare a clasamentului pentru locurile 4‐6 privind zonele informatizate. Astfel,
în 2010, clasamentul evidențiază următoarea structură:
aplicații destinate gestionării resurselor umane – 45,%;
soluții destinate platformelor verticale pe tipuri de industrii – 41,7%;
sisteme care implementează tehnologia Business Inteligence – 40,7%.

Sursa: Saugatuck Technology, SaaS Survey Research 2008, http://www.saugatech.com/
Figura 10.5. Cererea de soluţii SaaS, pe zone funcţionale şi geografice

În ceea ce priveşte piața locală, prima soluție concretă de SaaS pentru ERP‐urile
româneşti a fost lansată de SeniorSoftware în cadrul aplicației SeniorERP. Alți
producători la nivel național şi soluțiile lor sunt: TotalSoft, cu aplicația Charisma
Enterprise, Wizrom, cu soluția WizPro SaaS, Sysgenic Group, cu produsul ERP iBS.

Prezenţa pe piaţa locală a soluţiilor SaaS
SeniorSoftware (prin aplicaţia SeniorERP) are o ofertă care vizează companiile de distribuţie
cu cel mult zece utilizatori, care nu sunt dispuse să investească sume importante în
infrastructura hardware şi nu deţin personal dedicat pentru administrarea unei soluţii ERP.
Soluţia ERP este livrată pe baza unui abonament lunar cifrat la un preţ de 69 de euro per
utilizator. SeniorSoftware a atacat agresiv piaţa, introducând, la doar două luni după

lansare, o versiune aproape gratuită a produsului (SeniorExpress, versiune gratuită pentru
mai puţin de trei utilizatori). Unii ar considera că o asemenea atitudine sar putea dovedi
sinucigaşă, însă, dacă este urmată de o strategie coerentă de vânzare pe acelaşi canal a
unor servicii şi produse complementare sau chiar a unei versiuni superioare a aceluiaşi
produs, ar putea crea efecte pozitive.
TotalSoft a anunţat un viitor parteneriat cu Romtelecom pentru comercializarea aplicaţiei
Charisma Enterprise pe bază de abonament lunar.
Wizrom a lansat soluţia WizPro SaaS la sfârşitul anului 2008, tot în varianta achitării unui
abonament lunar. Acesta include licenţa şi întreţinerea aplicaţiei, precum şi infrastructura
de servere şi sisteme de operare. Wizrom atestă existenţa a peste 350 de utilizatori găzduiţi
întrun centru de date profesional.
Compania Sysgenic Group, deţinătoarea produselor iBS, anunţă soluţia ERP iBS în variantă
SaaS. Conform producătorului, procesul de dezvoltareimplementare a aplicaţiei iBS Saas se
derulează rapid, graţie presiunii exercitate de criză asupra bugetelor IT, dar şi a experienţei
acumulate în cele peste 35 de implementări.
(Sursa: Vasile, G., „Cât de aplicabil este conceptul SaaS la ERP?”, Market Watch, nr. 120,
noiembrie, 2009, http://www.marketwatch.ro/articol/5454/Cat_de_aplicabil_este_
conceptul_ SaaS_la_ERP)

În concluzie, apreciem că piaţa soluţiilor integrate se îndreaptă cu paşi mari spre
externalizare (SaaS, cloud computing) în defavoarea implementării propriuzise în
organizaţii (este vorba cu precădere despre companiile mici şi mijlocii). O „găselniță” la
modă constă în utilizarea metodelor de implementare cloud hybrid prin care furnizorii
oferă soluții de tranziție ca, de exemplu, de la HR SAP la o soluție de tip SaaS sau de la
un sistem ERP tradițional la unul de tip SaaS. Acestea sunt însă valabile doar pentru
IMM‐uri, nu şi pentru marile corporații. Chiar şi în cazul implementării platformelor
ERP în organizații, tendința manifestată este de trecere la aplicații de tip ERP II, în care
integrarea se realizează la nivel de organizații. Timpul este o problemă din ce în ce mai
acută, transferată asupra activității angajaților care simt nevoia lucrului, respectiv a
accesării aplicațiilor, din alte locații decât biroul firmei şi de pe alte dispozitive decât
calculatorul. În acest context, apariția echipamentelor mobile care permit instalarea
platformelor ERP vine ca un răspuns firesc la nevoia de eficientizare a activității unei
organizații.

Bibliografie

Airinei, D., Depozite de date, Editura Polirom, Iaşi, 2002
Airinei, D., Homocianu, D., „DSS vs. Business Intelligence”, The Proceedings of the International
Economic Conference: Integrative Relations between the European Union Institutions and the Member
States, Lucian Blaga University Publishing House, Sibiu, 2008
Alter, S., Information Systems, Benjamin/Cummings Publishing Co., 1996
Amerein, P., Rouard, F., Barczyk, D. ş.a., Manual de marketing strategic şi operaţional, Editura Teora,
Bucureşti, 2002
Anastasiei, B., Managementul riscului, managementul riscului organizaţional, Editura Tehnopress, Iaşi,
2010
Anderegg, T., ERP: AZ Implementer's guide for success, Resource Publishing, 2000
Anton, S.G., Gestiunea riscurilor financiare. Abordări teoretice şi studii de caz, Editura Universității
„Alexandru Ioan Cuza”, Iaşi, 2009
Bălan, C., „Managementul relațiilor cu clienții: valențe strategice, operaționale şi analitice”, Revista de
Marketing Online, vol. 1, nr. 3, 2008
Biere, M., The New Era of Enterprise Business Intelligence: Using Analytics to Achieve a Global
Competitive Advantage, IBM Press, 2010
Bose, R., „Customer relationship management: key components for IT success”, Industrial Management
& Data Systems, vol. 102, nr. 1/2, 2002
Bouquin, H., Contabilitate de gestiune, Tipografia Moldova, Iaşi, 2004
Bruhn, M., Marketing. Noţiuni de bază pentru studiu şi practică, Editura Economică, Bucureşti, 1999
Brynjolfsson, E., Yang, S., „The intangible benefits and costs of computer investments: evidence from
the financial markets”, în Proceedings of the International Conference on Information Systems,
Atlanta, SUA, 1997
Burduş, E., Căprărescu, G., Androniceanu, A., Miles, M., Managementul schimbării organizaţionale,
Editura Economică, Bucureşti, 2003
Buttle, F., Customer Relationship Management: Concepts and Tools, Elsevier, Oxford, 2004
Cătoiu, I., Bălan, C., Orzan, G. ş.a., Cercetări de marketing, Editura Uranus, Bucureşti, 2002
Chirică, S., Psihologie organizaţională. Modele de diagnoză şi intervenţie, Casa de Editură şi Consultanță
„Studiul organizarii”, Bucureşti, 1996
Claeyssen, Y., Deydier, A., Riquet, Y., Marketing direct multicanal. Prospectarea, fidelizarea şi
recâştigarea clientului, Editura Polirom, Iaşi, 2009
Davenport, T.H., „Putting the Enterprise into the Enterprise System”, Harvard Business Review, July–
August, 1998
Donovan, R.M., „Why the controversy over the ROI from ERP?”, Midrange ERP, ianuarie, 2000
Dospinescu, O., Tehnologii informaţionale în sprijinul managementului organizaţiilor, Editura
Tehnopress, Iași, 2009
Dospinescu, O., Iftode, V., Aplicaţii mobile pe platforma .NET, Editura Universității Alexandru Ioan Cuza”,
Iaşi, 2007
Drucker, P., Despre profesia de manager, Editura Meteor Press, Bucureşti, 1998
Fînaru, L., Contribuţii privind sistemele informatice în gestiunea financiară a societăţilor comerciale, teză
de doctorat, Iaşi, 1999
Fotache, D., Danileț, M., „Transforming Organisational Culture through the Impact of Information
Integration”, în Informatics in Knowledge Society. The Proceedings of the Eigth International
Conference in Informatics in Economy, Editura ASE, Bucureşti, 2007
Fotache, D., Groupware. Metode, tehnici şi tehnologii pentru grupuri de lucru, Editura Polirom, Iaşi, 2002
Fotache, D., Hurbean, L., Soluţii informatice pentru gestiunea afacerilor. ERP, Editura Economică,
București, 2004
Fotache, D., Hurbean, L., „Supply Chain Management: from Linear Interactions to Networked
Processes”, Informatica Economică, nr. 4 (40)/2006
Friedman, T., Pământul este plat. Scurtă istorie a secolului XXI, Editura Polirom, Iaşi, 2007
Gamble, P., Tapp, A., Marsella, A., Stone, M., Revoluţia în marketing. O abordare radicală pentru o afacere
de succes, Editura Polirom, Iaşi, 2008
Gartner Group, Training: The underestimated ERP project requirement, Research Note SPA‐345‐1337,
Gartner Inc., 1997
Gavin, L. ş.a., An EAI Solution using WebSphere Business Integration (V4.1), International Business
Machines Corporation, 2003
Ghițulescu, R., „O altfel de abordare a ofertei CRM în regim SaaS”, Market Watch, nr. 121, 12 ianuarie
2010
Ghițulescu, R., „Tertium non datur, oferta CRM OS în variantă locală”, Market Watch, nr. 114, 1 mai 2009
Giovinazzo, W.A., Internet – Enabled Business Intelligence, Prentice Hall, 2002
Gummesson, E., Total Relationship Marketing, Butterworth‐Heinemann, Woburn, 2002
Hammer, M., „Reengineering Work: Don’t automate, obliterate”, Harvard Business Review, Juy/August,
1990, pp. 104–112
Hammer, M., Champy, J., Reengineering the Corporation: A Manifesto for Business Revolution, Harper
Business Press, 1993
Han, J., Kamber, M., Data Mining: Concepts and Techniques, Morgan Kaufman Publishers, San Francisco,
2001
Handy, C., Pelerina goală. O gândire pentru o lume nouă, Editura CODECS, Bucureşti, 2007
Harwood, S., ERP: The implementation cycle, Butterworth‐Heinemann, Oxford, 2003
Heffner, R., Fulton, L., Forrester Research, Topic Overview: ServiceOriented Architecture, 2005
Helfert, E., Tehnici de analiză financiară. Ghid pentru crearea valorii, Editura BMT, Bucureşti, 2006
Hoekstra, J.C., Direct Marketing, Wolters‐Noordhoff, Groningen, 2001
Hossain, L., Patrick, J.D., Rashid, M.A., Enterprise Resource Planning: global opportunities and challenges,
Idea Group Publishing, 2002
Hristea, C., „Externalizarea serviciilor IT în Administrația Publică și ITIL pentru performanța serviciilor
IT”, PM Solutions, București, 2008
Humpries, M., Hawkins, M., Dy, M., Data Warehousing. Architecture and Implementation, Prentice Hall
PTR, New Jersey, 1999
Hurbean, C., Sisteme informatice pentru managementul firmei, Editura Mirton, Timişoara, 2001
Hurbean, L., „Factors Influencing ERP Projects Success in the Vendor Selection Process”, în Proceedings
of International Conference on Business Information Systems, Editura Universității Alexandru Ioan
Cuza”, Iaşi, 2007
Hurbean, L., Fotache, D., „New approaches in enterprise applications’ implementation”, în Education,
Research & Business Technologies, Editura ASE, Bucureşti, 2009
Imhoff, C., Pettit, R., „The critical shift to flexible Business Intelligence”, Intelligent Solutions, 2004
Inmon, W.H., Building the Data Warehouse, John Wiley & Sons, New York, 1996
Johnston, A.K., A hacker's guide to project management, Butterworh‐Heinemann, Oxford, 1995
Khoumbati, K., Themistocleous, M., Irani, Z., „Integration Technology Adoption in Healthcare
Organisations: A Case for Enterprise Application Integration”, în Proceedings of the 38th Annual
Hawaii International Conference on System Sciences (HICSS'05), 2005
Knolmayer, G., Mertens, P., Zeier, A., Supply Chain Management auf der Basis von SAPSystemen,
Springer‐Verlag, Berlin, 2000
Kotler, P., Principii de marketing, Editura Teora, Bucureşti, 2008
Kroenke, D., Auer, D., Database concepts, Pearson Education, 2008
Lambert, D.M. (ed.), Supply Chain Management: Processes, Partnerships, Performance, Sarasota, Florida,
2008
Lee, V., Scheinder, H., Schell, R., Mobile Applications: Architecture, Design and Development, Prentice
Hall, PTR, 2004
Levinson, H., Diagnosis for organizational change. Methods and models, Guilford, New York, 1994
Linthicum, D.S., Enterprise Application Integration, Addison‐Wesley Professional, 1999
Madu, C., Kuei, C., ERP and Supply Chain Management, Chi Publisher, Fairfield, 2004
Marakas, G., Decision Support Systems in the 21st Century, 2nd Edition, Prentice Hall, New Jersey, 2003
Maxim, E., Calitatea şi managementul calităţii, Editura Sedcom Libris, Iaşi, 2007
Bibliografie 343
Măzăreanu, V.P., Economia şi managementul riscurilor, Editura Tehnopress, Iaşi, 2010
McLuhan, M., The Gutenberg Galaxy: The Making of Typographic Man, University of Toronto Press, 1962
Meinadier, J.P., Ingéniérie et intégration des systèmes, Hermes, Paris, 1998
Mentzer, J.T. ş.a., „Defining Supply Chain Management”, Journal of Business Logistics, vol. 22, nr. 2, 2001
Mishra, R.K., Role of Information Technology in Supply Chain Management, în Indian online MBA
publications, pe site‐ul http://www.indianmba.com/
Monk, E., Wagner, B., Concepts in Enterprise Resource Planning, Thompson Course Technology, 2006
Moss, L., Atre, S., Business Intelligence Roadmap, Addison‐Wesley Professional, 2003
Munteanu, C., Maxim, E., Sasu, C., Prutianu, Ş. ş.a., Marketing – principii, practici, orizonturi, Editura
Sedcom Libris, Iaşi, 2006
Naisbitt, J., Global Paradox, Nicholas Breadley Publishing, London, 1995
Newton, R., Managementul schimbării pas cu pas, Editura All, Bucureşti, 2009
Nickerson, R., Business and Information Systems, Prentice Hall, 2001
O’Leary, D., Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk,
Cambridge University Press, 2000
Olson, D., Kesharwani, S., Enterprise Information Systems. Contemporary Trends and Issues, World
Scientific Publishing, 2010
Oprea, D., Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi, 1999
Oprea, D., Premisele şi consecinţele informatizării contabilităţii, Editura Graphix, Iaşi, 1994
Oprea, D., Airinei, D, Fotache, M. (coord.), Sisteme informaţionale pentru afaceri, Editura Polirom, Iaşi,
2002
Oprea, D., Meşniță, G., Dumitriu, F., Analiza sistemelor informaţionale, Editura Universității „Alexandru
Ioan Cuza”, Iaşi, 2005
Osborn, A.F., Applied Imagination: Principles and Procedures of Creative Problem Solving, Third Edition,
Charles Scribner’s Sons, New York, 1963
Păvăloaia, V.‐D., Integrarea tehnologiilor informaţionale în analiza financiară, Editura Universității
„Alexandru Ioan Cuza”, Iaşi, 2008
Pedron, C.D., Saccol, A.Z., „What lies behind the concept of Customer Relationship Management?
Discussing the essence of CRM through a phenomenological approach”, Brazilian Administration
Review, vol. 6, nr. 1, 2009
Peters, T.J., Waterman, R.H., In Search of Excellence: Lessons from America’s Bestrun Companies, Harper,
New York, 1982
Plazsczak, P., Wellner, R., Grid Computing – The Savy Manager’s Guide, Morgan Kaufmann Publishers,
San Francisco, 2006
Popescu, D., Popa, A., Mihalache, A., „Opțiuni în stabilirea strategiilor de control al producției”, Revista
Română de Informatică şi Automatică, 1998
Prodan, A., Managementul de succes. Motivaţie şi comportament, Editura Polirom, Iaşi, 1999
Prutianu, Ş., Munteanu, C., Caluschi, C., Inteligenţa marketing plus, Editura Polirom, Iaşi, 1998
Rababah, K., „A unified definition of CRM towards the successful adoption and implementation”,
Academic Research International, vol. 1, nr. 1, 2011
Rees, D.W., Arta managementului, Editura Tehnică, Bucureşti, 1996
Remenyi, D. ş.a., The effective measurement and management of IT costs and benefits, Butterworh‐
Heinemann, Oxford, 2000
Sârbu, M., „CRM – un termen la modă”, Net Report, mai 2002
Schmidt, J., „Enabling Next‐Generation Enterprises”, EAI Journal, July/August 2000
Tadjer, R., „Enterprise Resource Planning”, Internetweek, Manhasset, aprilie, 1998
Tena, C., „Grid Computing ‐ ultima frontiera”, Market Watch, nr. 72, iunie, 2005
Thomsen, E., OLAP Solutions. Building multidimensional information systems, Wiley Computer
Publishing, SUA, 2000
Tipper, D., „Mobile Applications Architectures”, public presentantion, University of Pittsburg, 2005
Trebilcock, B., „Supply Chain Technology: What’s happening in the innovation economy image”, Supply
Chain Management Review, iunie 2010
Troelsen, A., Visual Basic .NET and the .NET Platform. An Advanced Guide, Apress, USA, 2002
Turban, E. ş.a., Decision Support and Business Intelligence Systems, Pearson Education, New Jersey, 2007
Vasile, G., „Cât de aplicabil este conceptul SaaS la ERP?”, Market Watch, nr. 120, noiembrie, 2009
Vitt, E., Business Intelligence: Making better decisions faster, Microsoft Press, 2002
Wang, E., Chou, H.W., Jiang, J., „The impacts of charismatic leadership style on team cohesiveness and
overall performance during ERP implementation”, International Journal of Project Management, nr. 3/
2005
Wight, O., The Executive's Guide to Successful MRP II, Oliver Wight Limited Publications, 1983
Wigley, A., Roxburgh, P., Building .NET applications for mobile devices, Microsoft Press, 2002
Yurong, X., David, C.Y., Binshan, L., David, C., „Adopting Customer Relationship Management
Technology”, Industrial Management & Data Systems, vol. 102, nr. 8, 2002

Cele mai frecventate resurse web:
http://www.avantera.ro
http://www.charisma.ro
http://www.computerworld.ro
http://www.conspectus.com
http://www.ibm.com
http://www.microsoft.com
http://www.oracle.com
http://www.panorama‐consulting.com
http://www.sap.com
http://www.technologyevaluation.com
http://www.wikipedia.com

View publication stats

Cartea Minune

Încărcat de

Informații document

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

Cartea Minune

Încărcat de

Drepturi de autor:

Formate disponibile

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Platforme integrate pentru afaceri. ERP

Book · September 2013

Doina Fotache Luminita Hurbean

SEE PROFILE SEE PROFILE

Vasile Daniel Pavaloaia Octavian Dospinescu

SEE PROFILE SEE PROFILE

World IT Project - Case of Romania View project

The user has requested enhancement of the downloaded file.

Luminiţa HURBEAN Doina FOTACHE

Platforme integrate pentru afaceri

Descrierea CIP a Bibliotecii Naţionale a României

Luminiţa HURBEAN Doina FOTACHE

Platforme integrate pentru afaceri

Copyright © Editura Economică, 2013

Autorii sunt responsabili de clarificarea dreptului de utilizare

principală constă în integrarea tuturor proceselor economice şi optimizarea

Putem aprecia că desfăşurarea cronologică a ERP a urmat îndeaproape

devenind o componentă nelipsită într‐un proiect de implementare a unui sistem

să reliefeze ariile funcționale acoperite: contabilitate, financiar, producție, vânzare,

BAZE DE DATE PROGRAME

Sursa de risc Clasificare Exemple

Sursa de risc Clasificare Exemple

Dimensiunile funcțiunii de marketing dintr‐o organizație sunt diferite, fiind

Arii Contabilitate şi Marketing şi Producţie Resurse

E‐business a deschis multiple oportunități de dezvoltare tehnologiilor de

PROCESE REALE CALCULATOR

Modelul procesului Modelul workflow

Operaţia Reguli Circuitul Operaţia

 informaţia. Este un alt factor‐cheie workflow. Informațiile implicate sunt

Deschiderea şi completarea Fixează întâlnirea şi plasează

Şef cu recrutarea Intervievator

Evaluează dosarul, consultă Lansează procesul de angajare

Prima dimensiune a cubului o reprezintă procesele logice. Acestea descriu

identificarea participanților la workflow, deoarece sarcinile, aprobările interne şi

orientare resurse umane

Ad hoc Administrativ Frecvenţa

Valoarea afacerii Colaborativ Producţie

Tehnic Cereri aprobate

Analize-Întâlniri-Aprobări Rapoarte cheltuieli

Documentația descriptivă a unei arii de afaceri este o modalitate de

Cerere de ofertă Cerere comandă Bunuri şi facturi la

Comandă vânzări Comandă vânzare Comandă de vânzări

Comandă vânzare Comandă vânzare Comandă vânzări

Introducere proces Plăți Prelucrare blocare Prelucrare credit‐

E > A fost identificată necesi‐ E > A fost identificată necesit‐

A > Angajarea nu era A > Angajarea nu era A > Angajarea era prevăzută

permițându‐ne să abordăm toate variantele de execuție a activităților, cauzele

E > Există produse pe stoc E > Nu există produse pe stoc 9. P > Proces de Livrare 12. P > Proces de cerere de producție

Proces de cerere de Proces de achiziție materii Proces de livrare

8. E > Există materii prime necesare producției 11 E > Nu există materii prime necesare

9. P > Proces de producție 12. P > Proces de achiziție materii prime

Proces de vânzare Proces de producție Proces de achiziție materii prime

Proces de cerere de producție Proces de achiziție materii prime Proces de livrare

Proces de vânzare Proces de producție Proces de achiziție materii

Proces de cerere de producție Proces de achiziție materii prime Proces de livrare

Proces de cerere de producție Proces de achiziție materii prime Proces de livrare

Proces de vânzare Proces de producție Proces de achiziție materii prime

Proces de livrare Proces de cerere de producție Proces de cerere de producție Proces de producție

www.intelligententerprise.com; www.erp.com, dar şi la publicațiile MIS Quarterly, Management

Eficienţa Satisfacţia Previziuni mai Adaptare şi

Procese Calitate Pieţe Produse noi

Creşte dificultatea de măsurare

– identificarea solicitantului (descrierea firmei, structura organizatorică,

informaţia. Este un alt factor‐cheie workflow. Informațiile implicate sunt

îmbunătățirea continuă a calității bunurilor şi a serviciilor livrate cu

instruirea managerilor cu analizele multimensionale OLAP, simulările,

marketingul să se cuprindă şi desfăşoare prin toate departamentele

maximizarea valorii oferite clienţilor, consumatorilor şi propriei firmei

platforme de securitate care permit autorizarea şi autentificarea