Academia de Studii Economice, Bucureti

Facultatea de Cibernetic, Statistic i Informatic Economic

Master: Analiza Afacerilor i Controlul Performanei ntreprinderii

Sintez

Modelul decizional un cadru al logicii n afaceri,

ce conecteaz mediul business de tehnologie

Student:
Popa Emilia-Andreea
anul II, grupa 1081

Introducere

Cartea Modelul decizional trateaz un set de probleme deosebit de importante regulile

de afaceri. n mod evident, regulile de afaceri reprezint unele dintre provocrile tehnologice
majore ale secolului XXI, iar dac obiectivul pe care mul i cercettori sau antreprenori i-l
seteaz este de a crea noua generaie de sisteme de informatice de scar larg, agile, adaptabile i
previzibile, atunci este nevoie de metode reutilizabile pentru dezvoltarea coerent a regulilor de
afaceri. Astfel se nelege contribuia semnificativ a acestei cri, ce ridic problema necesit ii
cunoaterii regulilor consistente/eseniale, care guverneaz comportamentul unei companii n
diverse situaii. Prin intermediul crii, ni se descrie o abordare, cu teorie i metode, accesibil
att profesionitilor din mediul de afaceri, ct i inginerilor IT, pentru a crea seturi de reguli de
afaceri coerente. n acelai timp, abordarea propus este uor adaptabil la diversele piee,
legislaii, regulamente i tehnologii care se schimb permanent.
Autorii crii au ncercat s propun o metod simp, elegant, dar care s aib i o
rigoare matematic. ncepnd cu acest model conceptual, autorii au fost capabili s arate cum se
construiete o metodologie larg pentru captarea, analiza i utilizarea acestor reguli de afaceri, fie
pentru o mic aplicaie departamental, fie pentru o ntreag linie de afaceri.
Trebuie contientizat faptul c, n ritmul rapid al zilelor noastre, organizaiile i
ntreprinderile trebuie s fie capabile s-i defineasc seturi mari de reguli de afaceri ntr-un mod
n care regulile sunt n acelai timp clare, concise, minim redundante, i, de asemenea u or de
modificat. Totui, mediul regulilor de afaceri de astzi nu difer foarte mult de cel al bazelor de
date de acum 40 de ani. La sfritul anilor 1960, multiple abordri distincte asupra modelrii
bazelor de date concurau pentru recunoatere, cnd Ted Codd i asociaii si din IBM Research
au definit ceea ce noi numim astzi Teoria bazelor de date relaionale. Codd, un matematician
prin formare, a fost capabil s dezvolte o abordare riguroas, coerent pentru definirea seturilor
de tabele relaionale, care ar oferi seturile de rspuns necesare, consistente la nivel intern i
minim redundante. Aceast paralel, ntre modelul decizional i modelul bazelor de date
relaionale va fi des ntlnit pe parcusul crii.
Se aduce n discuie i se trateaz n profunzime una dintre cele mai importante
caracteristici ale modelului decizional prezentat, i anume faptul c este model logic,
independent de tehnologie. Modelul n sine folosete tehnologii, dar nu este dependent de ele.
Este de admirat capacitatea autorilor de a specifica modul n care metodologia regulilor
de afaceri pe care au definit-o se potrivete mpreun cu ntregul complex al tuturor
preocuprilor de afaceri sau tehnologie, inclusiv modelarea deciziilor de afaceri, a proceselor de
management de afaceri, SOA i de definire a cerinelor.
Avem de-a face, aadar, cu o carte care, prin coninutul su, ne amintete c scopul
regulilor de afaceri este de a lua o problem complex i de a o transforma ntr-o solu ie simpl,
logic.

Capitolul 1 De ce Modelul Decizional?

Modelul decizional este un nou model care impacteaz nu doar trendurile tehnologiei, ci
i practicile ntlnite n gestiunea unei afaceri, n managementul unui business. Acest model
introduce, n mulimea regulilor de afaceri, o structur bine definit, bazat pe natura intrinsec a
logicii, extins cu principiile integritii i a normalizrii. Modelul este similar, n concept, cu
ceea ce Modelul Relaional a oferit domeniului datelor.
Acest prim capitol este o introducere a motivelor pentru care a fost dezvoltat i explorat
Modelul Decizional. Debuteaz cu o perspectic istoric asupra motivelor care conduc la
folosirea unui asemenea model i continu cu o scurt trecere n revist a rolului unui model, att
ntr-o afacere, ct i n contextul tehnologiei moderne de astzi. n final, capitolul se ncheie cu
perspective asupra oportunitilor posibile oferite de adoptarea Modelului Decizional.
Odat cu apariia computerelor n anii 1950, a nceput i expansiunea constant a
funcionalitior asigurate de sistemele de afaceri computerizate. Aceast expansiune a condus la
fenomenul n cadrul cruia astfel de sisteme joac un rol central ntr-o firm. Chiar i firmele
medii, ca mrime, dein aplicaii de business. Organizaiile mari au poate mii de aplicaii, ca i
istoric, iar fiecare aplicaie ulterioar este ntotdeauna mai complex fa de cea anterioar.
Astzi, sunt foarte puine sisteme implementate ntr-o firm, care nu sunt mcar par ial
automatizate.
nainte de vnzarea comercial a calculatoarelor, un business i desfura procesele prin
efortul uman, ghidat de gndirea uman i logic. n multe cazuri, procesele critice erau
documentate ca fiind un set de aciuni i puncte de verificare/control importante, alturi de
ndrumarea n a lua decizii pe parcurs. ntr-adevr, astfel de documentaii exist astzi pentru
multe procese care sunt parial sau n ntregime desfurate i conduse de oameni. Documentaia,
mpreun cu pregtirea timpurie, asigur evoluia proceselor n timp.
n era calculatoarelor, procese de business importante, sau doar anumite pri din acestea,
au devenit subiectul ideal pentru automatizare. Secvena de pai i etape, mpreun cu logica de
business pentru a lua deciziile din spatele acelor pai, s-au transformat ntr-un cod de program.
Afacerile au avut mult de ctigat prin automatizarea proceselor de business: abilitatea de a
procesa tranzacii rapid, ntr-un volum ct mai mare, i cu mai mult consisten , toate aceste
aspecte au fcut diferena pentru majoritatea business-urilor din lume. Ctigurile i avantajele
dobndite au fost enorme, i ca i consecin, valul automatizrii afacerilor a crescut mult peste
ateptrile setate la nceput. Totodat, a crescut i dorina firmelor/afacerilor de a deine
tehnologie sofisticat i dorina oamenilor de a nelege cum sunt proiectate sistemele
automatizate. Totui, un pre a fost pltit pentru aceste progrese tehnologice. Multe firme au
pierdut controlul asupra logicii de business care este ncorporat n aceste sisteme i acesta nu
este dect rezultatul natural al modului n care proiecia i dezvoltarea sistemelor automatizate au
evoluat.

Sisteme de afaceri automatizate: nceputul

Ken Orr explic evoluia sistemelor de afaceri automatizate ca fiind o o grmad mare de noroi,
aa cum se poate vedea n figura de mai jos:

Figur 1: Modelul de sistem 'big ball of mud'

Funcionalitile erau coninute ntr-o singur arhitectur: dimensiuni precum raportarea,

baze de date, procesarea de transacii, prezentri, fluxuri de lucru, securitate i regulile afacerii.
De-a lungul timpului, aceste dimensiuni majore au fost divizate i separate, pentru a putea fi
dezvoltate i modificate independent. Dei s-au fcut progrese n a separa diferitele aspecte
ngropate n acea grmad de noroi, nu s-a nregistrat un success larg rspndit n a extrage
logica de afaceri i a o dezvolta i modela independent. n mod ironic, logica de afaceri este chiar
nucleul sistemelor de afaceri automatizate.
Logica de afaceri se descrie ca fiind un simplu set de reguli de faceri, care reprezint
elemente atomice ale condiiilor care conduc la concluzii ntr-o afacere. Logica de afaceri este
modul n care gndim atunci cnd trebuie s lum decizii importante cu privire la business.
Multe astfel de reguli de afaceri sunt configurate n codul programului sau n mintea oamenilor.
Cteodat, regulile care execut codul nu sunt ceea ce trebuie pentru a ntmpina nevoile afacerii
i nici ceea ce liderii afacerii se ateptau. Ele sunt o component important atunci cnd este
implementat schimbarea i confer afacerii agilitate. Totui, astfel de reguli opereaz astzi ca
un instrument silenios, aproape invizibil, fiind i rezistent la schimbare.

ntre anii 1960-1970, s-a nscut ideea c datele ar trebui s fie separate de proces. O
ncercare timpurie de a realiza o astfel de separare a reprezentat-o introducerea dic ionarelor de
date sau cataloagelor de date. Totui, simpla separare a datelor ntr-o list cu elemente de date nu
a fost suficient pentru a oferi avantajele i beneficiile anticipate ale unor date comune, de
calitate nalt. Successul a venit cu introducerea unui model pentru date, diferit de ce exista pn
atunci. n 1970. Dr. E. F. Codd a scris un model care a schimbat pentru totdeauna modul n care
lumea gndete, gestioneaz i se folosete de datele stocate n baze de date. Modelul lui Codd,
cunoscut sub numele de Modelul Relaional este foarte semnificativ pentru multe motive, dar
ceea ce i-a oferit rezisten n timp a fost faptul c a pus o baz tiin ific i stabil domeniului
bazelor de date. Era un model bazat doar pe natura intrinsec a datelor i nimic mai mult.
Adoptarea Modelului Relaional, alturi de tehnologie i cele mai bune practice n industrie au
mbuntit considerabil calitatea datelor stocate n bazele de date.
Rentorcndu-ne la perspectiva lui Ken Orr, ultimii ani au dovedit o redescoperire a
regulilor de afaceri ca fiind un important aspect ce trebuie reinut, capturat din grmada de
noroi. n multe cri de specialitate, s-a subliniat importana separrii regulilor de business i
crearea unei indepene proprii precum a gestiunii bazei de date, iar vendorii de software deja au
nceput s produc i s ofere pe pia sisteme de management al regulilor de business.
O ntrebare foarte simpl este pus adesea: exist un model de logic a afacerii care s fie
uor de creat, intepretat, modificat i automatizat? Exist un model tehnologic independent,
riguros, repetitiv, care s se bazeze doar pe natura intrinsec a logicii de afaceri i nimic mai
mult? Un astfel de model ne-ar furniza elementul-lips din tehnologiile disponibile astzi,
metodologii i practice n afaceri, conducnd totodat la progrese tehnologice care pstreaz
perspectiva de independen asupra logicii de afacri. Aa cum Modelul Relaional a funcionat
pentru date, un astfel de model ar permite separarea logicii de business de alte aspect, oferind o
reprezentare foarte specific pentru mentenana i automatizarea sa.
Multiple posibiliti au condus la ani de cercetare tiinific, iar Modelul Decizional a fost
testat i rafinat, conducnd la redactarea acestei cri. Structura Modelului Decizional este bazat
pe premisa c logica de afaceri are propria sa existen , independent de cum este executat, n ce
moment al business-ului este executat, i dac executarea sa este implementat n sistemele
automatizate. n graficele de mai jos se pot observa diferene vizuale ntre reprezentrile
modelului de date, modelului de process i modelului decizional.

Figur 2: Modelul de date

Figur 3: Modelul de proces

Figur 4: Modelul decizional

Cele mai importante cinci caracteristici ale Modelului Decizional sunt:

1. Definete o metod independent de tehnologie de a organiza logica de afaceri.
2. Modelul Decizional este pura reprezentare a logicii de afaceri. Posed trei caracteristici
cheie: o structur simpl, integritate optimal i natur declarativ.
3. Dei este independent de tehnologie, poate fi foarte uor implementat n tehnologie, i
transcende produse tehnologice curente i viitoare.
4. Modelul Decizional nu este niciun limbaj, nicio gramatic, ci pur i simplu un model.
Totui, limbajele i gramatica pot definite peste Modelul Decizional, ntr-un mod similar
cum limbajul SQL a fost construit peste Modelul Relaional.
5. Este un model care se adreseaz unei importante probleme nerezolvate: cum s gestionm
n mod eficient regulile de business i logica de afaceri.
Modelul Decizional are potenialul de a schimba practicile curente n managementul unui
business, dar i trendurile n tehnologiile viitoare, permind profesionitilor din lumea IT i
business s regndeasc modul n care privesc, proiecteaz, execut i guverneaz logica
afacerii. Practica indic faptul c Modelul Decizional le permite oamenilor din business, de
profil nontehnic, s interacioneze intuitive cu propria lor logic n afaceri.
Analitii industriei estimeaz creteri semnificative n arii de tehnologie precum
Arhitectur Software bazat pe Servicii (Service Oriented Architecture SOA), Managementul
Proceselor de Afaceri (Business Process Management BPM) i Managementul Deciziilor n
Afaceri (Business Decision Management BDM).
Pe baza experienei, un Model Decizional are potenialul de a genera urmtoarele schimbri:
-

metodologii de IT i gestiunea afacerii, care s promoveze decizii de business i Modele

Decizionale corespunztoare
software automatizat comercializat care suport servicii decizionale derivate din Modelul
Decizional
software de colectare a cerinelor i modelare, care permite specificarea i guvernana
Modelului Decizional din business ctre tehnologie
livrarea unei logici de afaceri specific unui domeniu, care se transform n practice
standardizate
lideri de business care vor putea vizualiza, valorifica, provoca i simula propria lor logic
de afaceri, chiar dac nu este automatizat.

Putem spune, aadar, c Modelul Decizional este un nou model care i propune s reprezinte
logica n afacderi. Este bazat doar pe caracteristicile intrinseci ale logicii de afaceri ns i. Cu
alte cuvinte, este impartial fa de alte aspecte i este foarte uor de creat i gestionat. De i pn
acum nu s-a nregistrat un success rsuntor n a extrage i a proiecta logica de afaceri, astfel
nct s poat fi dezvoltat i modificat independent de alte aspecte ale afacerii, structura
Modelului Decizional pornete de la ipoteza c logica de afaceri are propria sa existen . Mai

mult dect att, marea importan a Modelului Decizional poate consta n poten ialul de a crea
noi direcii legate i asociate cu acesta.

Capitolul 2 Prezentare general a modelului decizional

n spatele unei decizii de afaceri se afl ntotdeauna un model decizional. Modelul
decizional este un model raional pentru perceperea, organizarea i gestionarea logicii de afaceri.
Ce nelegem prin logica de afaceri este o reet pentru modul n care exper ii de afaceri doresc
s evalueze fapte, n scopul de a ajunge la o concluzie care s aib att n eles, ct i valoare
pentru afacere. Prin urmare, o decizie de afaceri este definit ca o concluzie pe care afacerea
intenioneaz s o gestioneze i la care ajunge prin intermediul logicii de afaceri.
Pentru a face logica de afaceri o practic tangibil i comun este nevoie de traducerea
gndirii afacerii ntr-o form vizibil, transmisibil, care de cele mai multe ori este reprezentat
print-un set de reguli de afaceri (business rules). Acest set de reguli poate mbrca mai multe
forme: text, abloane, tabele de decizie, arbori de decizie, propoziii care ader la o sintax
specific. Indiferent de form, acestea sunt modelate dup structura modelului de decizie i i
respect principiile.
n primul rnd, este important de neles ce nseamn definiia modelului decizional ca
fiind un ablon intelectual i logic. Ca model raional, modelul decizional este o reprezentare
logic a mediului de afaceri sau a afacerii individuale. El nu reprezint un model fizic a formei n
care logica de afaceri este pus n aplicare n tehnologii specifici i nu este nici un model despre
cum logica de afaceri este comunicat prin manuale de proceduri sau materiale de instruire. n
schimb, este un model bazat pe prezentarea riguroas i complet a logicii de afaceri. Forma lui
poate s difere n funcie de scopul predefinit: dac scopul este de automatizare, atunci modelul
decizional va fi prezentat prin una sau mai multe tehnologii int, bazate pe metodologiile de
proiectare corespunztoare. Dac scopul este de a-l da spre folosire oamenilor din business, din
mediul de afaceri, atunci modelul va fi uor de neles i utilizat.
Mai mult dect att, trebuie explorat conceptul de model din noiunea larg Model
Decizional, pentru c el este un model, i nu o simpl list. Modelul Decizional este o
reprezentare independent a logicii de afaceri, care se bazeaz pe premisa c logica de afaceri are
propria ei existen, independent de modul n care a fost executat i dac execu ia este
implementat n sisteme automatizate. Aadar, modelul decizional poate fi ancorat n oricare alte
tipuri de modele, ns este mereu independent de acestea. Aceast independen implic faptul c
modelul are o structur uor de recunoscut, dar diferit de a celorlalte modele. Astfel, Modelul
Decizional este: simplu i uor de intepretat, independent de cerinele tehnologice/de prelucrare,
optimal n integritatea asta-ceea ce nseamn c logica de afaceri este consistent n profunzimea
sa i se aliniaz direciei afacerii.

A captura logica afacerii, de la condiii pn la concluzii, i a o rafina pn este atomic,

precis, dezambigu i aliniat cu obiectivele afacerii-despre asta este vorba n Modelul
Decizional i n principiile care o guverneaz. El este reeta pentru modul n care afacerea ajunge
la anumite concluzii bazate pe fapte, care reprezint colectiv logica de afaceri intenionat, din
spatele unei decizii de afaceri. Aceste concluzii individuale i reprezentarea lor ntr-un Model
Decizional sunt independente de faptul c ele suport sau nu software complex customizat,
pachete software achiziionate sau procese desfurate de indivizi. n fapt, un Model Decizional
se conformeaz tuturor principiilor , indiferent de tipul de automatizare sau lipsa ei. n practic,
este indicat s se dezvolte nti Modelul Decizional i apoi s se decid dac va fi coordonat de
tehnologie sau de oameni. Dac tehnologia este soluia cea mai potrivit, atunci Modelul
Decizional poate asista n a selecta tehnologia care se potrivete cel mai bune logicii de business
din spatele deciziei de business.
Trecerea de la logica de afaceri la Model Decizional Structural
Totul ncepe cu o afirmaie legat de afacere, care se traducere ntr-un element structural al
Modelului Decizional. S presupunem c avem de-a face cu o instituie financiar care ofer
diferite tipuri de mprumuturi . Recent, numr de clieni care nu i pot plti ratele de mprumut a
crescut semnificativ, astfel nct experii n afaceri vor s rafineze logica de afaceri care
determin probabilitatea unei asemenea incapaciti de plat.
Experii se ntlnesc i poart mai multe discuii n urma crora se furnizeaz perspective asupra
logicii de afacere i se stabilete probabilitatea de neplat a unui mprumut bazat pe urmtoarele
fapte: o persoan cu experien de munc srac, ce deine o situaie ipotecar precar i care are
mai multe credite, este o persoan cu o probabilitat mare de a fi n incapacitatea de plat a
mprumutului.
Acest text se transform ntr-o reprezentare a Modelului Decizional. Elementul structural
fundamentul este un tabel bidimensional care leag condiiile de o singur concluzie
corespunztoare. Structura bidimensional se numete Familie de reguli i descrie cele 3 condiii,
pe coloane, care sunt testate, pentru a se ajunge la concluzia din coloan.

Figur 5: Familie de reguli

Rndurile din tabel sunt completate folosind dou celule. Prima celul este un operator
aplicat titlului coloanei, iar a doua celul este operandul pentru operator. De exemplu, pentru
prima coloana operatorul este Is/Este i operandul este Poor/Sarac. Acestea sunt interpretate
ca un test: dac istoricul n cmpul muncii este precar, iar testele corespunztoare celorlalte dou
coloane sunt adevrate, concluzia stabilit va fi c probabilitatea ca persoana respectiv s fie n
incapacitate de plat este mare.
Modificarea coninutului modelului decizional
S presupunem c a doua zi experii doresc s schimbe logica de afaceri i doresc s mai
adauge un nou criteriu, numit Person Outside Credit Rating. Este evident c trebuie s tim ce
valori poate lua acest criteriu, iar el este adugat ca o nou coloan condiie n tabel.

Figur 6: Adugarea unei noi condiii la Familia de reguli

Evident, ntr-un Model Decizional putem aveam nevoie de mai mult de o singur Familie de
Reguli, iar astfel se creeaz legturi ntre reguli.

Figur 7: Tabel cu 2 Familii de Reguli

Introducem i noiunea regulii tipar (rule pattern): n Modelul Decizional, un set de

rnduri dintr-o Familie de Reguli cu un set comun de celule condiii populate formeaz un tipar
de reguli.

Figur 8: Familie de Reguli populat cu 2 tipare de reguli

Prezentm i diagrama Modelului Decizional, cea care depicteaz doar structura acestuia, nu i
coninutul detaliat al Familiilor de Reguli. O diagram ca cea n exemplul de mai jos ncepe cu o
form octogonal, ce reprezint decizia de afaceri. Aceast form este legat de sarcini ale
modelelor proceselor de business i paii din fiecare studiu de caz. Aceast form se conecteaz
i cu obiectivele afacerii, tacticile i cerinele. Celelalte forme reprezint Familiile de Reguli.

Figur 9: Diagrama Modelului Decizional

Concluzionm prin a reitera faptul c orice Model Decizional se bazeaz pe principii. Aceste
principii sunt grupate n 3 categorii, unde fiecare grup susine un scop comun din lista
caracteristicilor enunate la ncepute:
Scopul I: simplitate structural-legat de principiile structurale
Scopul II: natur declarativp-legat de principiile declarative
Scopul III: integritate optimal-legat de principiile de integritate

Capitolul 3 Valoarea afacerii prin prisma Modelului Decizional

Trim ntr-o lume n care cheia succesului st n capacitatea de a lua decizii mai bune i
ntr-un timp mult mai scurt dect competiia. De altfel, viaa unei companii depinde din ce n ce
mai mult de astfel de decizii, fapt ce face imposibil de negat beneficiul adus de Modelele
Decizionale.
Capitolul 3 prezint diferite moduri tangibile prin care o decizie de afacere aduce valoare
acesteia. Capitolul integreaz sugestii pentru evaluarea afacerii i dezoltarea unui Model
Decizional corespunztor acesteia. Este cunoscut faptul c deciziile de afaceri au impact n
valoarea comercial a afacerii. Din perspectiva mediului de afacere, acest capitol exemplific
caracteristicile de baz ale Modelelor Decizionale, cu impact direct n valoarea afacerii. Natura
Modelului Decizional privind valoarea afacerii denot toate considerentele prin care acesta
contribuie la sucessul afacerii. Aceste considerente includ urmtoarele aspecte:
-

Ct de mult Modelul Decizional contribuie la dezvoltarea afacerii

Cum Modelul Decizional s-a dovedit util n situaii normale, complicate, de ameninare a
stabilitii sau pe timp de criz
Ct profit, reputaie, consisten i calitate livreaz Modelul Decizional pentru piaa de
desfacere
-

Ct valoare, expansiune i cunotere asigur Modelul Decizional

Ct de mult Modelul Decizional corecteaz deficienele practicilor curente, cum ar fi

BPM (Managementul Procesului de Afacere) i BDM (Managementul Deciziei n Afaceri).
Cele trei caracteristici importante ale Modelului Decizional se bazeaz pe contextul
operativ, impactul economic i logica de afacere. Pe scurt, contextul operativ determin cum
Modelul Decizional rezolv o problem sau asigur o oportunitate. Impactul economic este bazat
pe volum i ofer o imagine a valorii financiare a Modelului Decizional. Complexitatea logicii
de afacere asist la nelegerea costului dezvoltrii i a reuitei modelului. Pe larg:
I.

Contextul Operativ

Fiecare decizie de afacere are un context operativ care reprezint complexitatea mediului de
afacere n care decizia de afacere este fcut. Complexitatea mediului de afacere poate varia dar
valoarea Modelului Decizional trebuie s ia n considerare contextul operativ. Conceptul de
context operativ este explicat pe larg n cartea Leaders Framework for Decision Making,
autori David Snowden i Mary Boone, anul 2007. Cei doi autori definesc patru contexte
operative pentru deciziile de afacere bazate pe informaiile de intrare sau inputuri, astfel:
Contextul simplu, unde informaia de intrare const n faptul c toate prile implicate
mprtesc o nelegere a faptelor pentru a lua o decizie

Contextul complicat, face parte din domeniul experilor, munca se desfoar n instane
necunoscute cu mai mult de un rspuns corect pentru informaia de intare.
Contextul complex, cnd nu avem toate datele pe mas, iar informaia de intrare poate s
nu aib rspunsuri corecte sau prea puin corecte.
Contextul haotic, cnd informaia de intrare lipsete cu desvrire iar cel mai relevant
exemplu este evenimentul tragic din SUA, din 11 septembrie 2001 sau criza financiar din
septembrie 2008.
II.

Impactul economic

Fiecare decizie de afacere variaz n funcie de volumul impactului economic. Fiecare decizie de
afacere are de asemenea o frecven denumit volumul deciziei de afacere. Impactul economic
colectiv a deciziei de afacere este o combinaie a impactului economic i volumul acesteia.
Volumul deciziei de afacere apare adesea invers proporional fa de valoarea economic. Autorii
James Taylor i Neil Raden n cartea manifest Smart Systems, iunie 2007, vorbesc despre cum
poi s livrezi avantaj competitiv prin automatizarea deciziilor ascunse.
Acetia au subliniat importana deciziilor operaionale i nevoia de a le gestiona ct de bine
posibil cu urmtoarele argumente:
o
o
o

Organizaiile sunt percepute i evaluate prin prisma deciizilor pe care le iau i le aplic
Multe decizii mrunte se adaug la o decizie important
Toate deciziile pe care o organizaie le aplic ar trebui gestionate n mod deliberat

Mai mult dect att, deciziile operaionale pot fi i trebuie automatizate din cauza:
o
Volumului mare
o
Abordrilor tehnologice tradiionale care nu vor aduce success n automatizarea
deciziilor
o
Per total, volumul efectiv de decizii automatizate trebuie msurat, inut n eviden i
mbuntit n timp.
III.

Complexitatea logicii de afacere

Fiecare decizie de afacere variaz n funcie de complexitatea logicii de afacere. Valoarea pe care
o aduce Modelul Decizional trebuie s ia n considere complexitatea logicii i ct de uor poate fi
neleas i aplicat. Complexitatea presupune un ansamblu de piese complicate sau
interdependente. Pentru o decizie de afacere, ansamblul presupune Decizia corespunztoare
Modelului. Piesele complicate sau interdependente sunt familiile de decizii i concluzii. Prin
urmare, pentru a categorisi decizia de afacere prin prisma complexitii logicii este necesar s
nelegem cantitatea de decizii, condiii i concluzii i relaia dintre acestea n cadrul
ansamblului.
Finalmente, fiecare din cele trei caracteristici ale deciziei de afacere contribuie la valoarea
afacerii i evalueaz aspectele corespunztoare Modelului Decizional.

Capitolul 4 Schimbnd jocul: legtura dintre BPM (Managementul

Procesului de Afacere) i BDM (Managementul Deciziei n Afaceri)

Procesul de business este definit ca o serie de activiti stabilite i repetitive, care au loc
ntr-o secven planificat de actorii ce pot fi indivizi sau organizaii, cu scopul de a aduce
valoare serviciului clienilor. Un business proiecteaz procesele din interiorul su, le conduce,
monitorizeaz i optimizeaz procesele de business cu scopul de a furniza clientului produse
mbuntite sau la un cost redus. Un exemplu de proces de business poate fi n cadrul unei
companii aeriene, ntregul proces al cltoriei clientului, din momentul n care acesta ncepe s
caute zborurile potrivite pn cnd i ncheie cltoria. Acest proces implic pa i precum
cutarea orarului de zbor i al preului aferent, completarea rezervrii, timpul de a teptare n
aeroport, mbarcarea i aterizarea la sol.
n prezent exist instrumente automate de modelare care produc modele de procese de
business ce pot le simula i crea abloane pentru automatizarea acestora. Modelele ajut
stakeholderii s neleag ntregul flux al procesului de business.
Un proces de business bazat pe decizii este diferit de procesul clasic de business prin
prisma faptului c primul reprezint task-uri care sunt ndeplinite bazndu-ne pe logica de
business, iar al doilea sunt task-urile propriu-zise, zilnice, care susin ntregul flux. Un proces de
business este de natur procedural, n timp ce deciziile de business au natur declarativ.
Aceast diferen este extrem de important i totui, n general, deciziile de business sunt
considerate ca fcnd parte din procesul de business, acest lucru afectnd de multe ori ntregul
proces.
O soluie procedural specific, pas cu pas, cum ar trebui un anumit lucru s fie fcut.
Practic exist o serie de task-uri ce sunt ndeplinit ntr-o anumit secven i care rspund la
ntrebarea Cum se face?. O soluie declarativ specific doar ceea ce trebuie fcut, fr alte
detalii precum modul n care se face sau secvena de pai ce trebuie urmat, deoarece aceste
aspecte devin irelevante pentru atingerea rezultatului corect. Un model de decizie este un set de
task-uri logice neordonate i rspunde la ntrebarea Ce se face?
Principalele diferene ntre procesul i deciziile de business sunt prezentate n urmtorul tabel:
Proces de business
Natur procedural
Const n task-uri conectate printr-o secvent

Decizii de business
Natur declarativ
Const n familii de reguli conectate prin relaii
infereniale (toate independente unele de altele)
Este vorba despre CUM se realizeaz un lucru
Este vorba despre CE lucru se realizeaz
mbuntirile au ca scop creterea eficienei mbuntirile au ca scop urmrirea unei logici

muncii

inteligente de business

Figur 10:Principalele diferene ntre Procesul de Business i Deciziile de Business

Un model de proces de business nu va reu i s descrie ntreaga logic de business,

deoarece aceasta nu este direct vizibil i de multe ori va fi ascuns n unul sau mai multe dintre
task-uri. ntr-un model decizional, toat logica de business este clar reprezentat i va asigura
suportul necesar pentru schimbarea logicii de business n mod rapid i acurat, dac este cazul,
fr a fi nevoie s se revizuiasc fiecare task.
Modelele bazate pe decizii de business sunt simple, productive i reduc costurile. Prin
separarea modelelor de decizii de modelele de procese de business le face pe cele din urm s
devin mai generice i s poat fi reutilizate n alte probleme. Totui, exist situaii n care
realizarea unei secvene de decizii logice de business este relevant pentru atingerea unei
concluzii corecte. n astfel de cazuri un singur Model Decizional nu mai este suficient, ci trebuie
divizat n mai multe pri, fiecare fiind n relaie cu task-uri diferite din cadrul procesului de
business. Astfel, fiecare decizie de business va fi ncadrat ntr-un grup diferit al procesului de
afacere, aceast separare facilitnd guvernarea grupurilor distincte ale logicii de business.
Deciziile sunt luate de multe ori pentru nivele diferite: strategic, tactic i operaional, fiind astfel
necesare modele de decizii separate.
BPM (Managementul Procesului de Afaceri) este adoptat de organizaii cu scopul de a
atinge excelena operaional, adic s ofere clienilor un serviciu la un nivel de calitate ct mai
nalt, avnd costuri ct mai reduse. Procese de business nu trebuie s fie doar eficiente i
avantajoase pentru client, ci trebuie s fie i inteligente i agile. Un proces devine agil atunci
cnd deciziile declarative sunt separate de task-urile procedurale i devine inteligent atunci cnd
deciziile sunt susinute de ctre liderii de departament. BPM presupune monitorizarea
performanei deciziilor de business n raport cu obiectivele i recunoaterea acelor evenimente
care apar i care pot ridica dificulti sau chiar crea haos n contextul operativ al deciziilor de
business.
Atunci cnd liderii neleg clar logica din spatele unei decizii de afacere, impactul acelei
dezicii poate fi previzionat, organizaia putnd adopta rapid schimbri n procesul de business,
dac este cazul sau dac apar evenimente neprevzute. De exemplu, pentru o organiza ie
monitorizarea valorii produselor cu scopul de a pstra preul competitiv pe pia concomitent cu
satisfacerea clienilor prin observarea feedback-ului lor i oferirea de servicii sau produse
conforme cu acest feedback i realizarea unui profit bun reprezint un model de decizie de
business inteligent, ce face posibil msurarea performanei i e eficienei companiei.
BDM (Managementul Deciziilor de Afacero) reprezint practica de adoptare a deciziilor
inteligente i agile, fiind adesea referit i ca Managementul Deciziilor ntreprinderii. Cele trei
elemente principale ale BDM sunt motivaia de business (obiectivele setate), logica de business
(logica utilizat pentru atingerea obiectivelor) i metrica de business (msoar rezultatele n
raport cu obiectivele setate n planul de business).

Pentru adoptarea celor mai bune practici ale BDM, din perspectiv organizaional sunt
necesare urmtoarele apte consideraii:
1. Recunoaterea deciziilor de business ca fiind principalul conductor al ntregului proces.
Aceste decizii trebuie s fie explicite i agreate de toti stakeholderii importan i ai unei
companii;
2. Adoptarea modelului de decizii ca o reprezentare separat a logicii detaliate din spatele
deciziilor de business;
3. Definirea rolului activ al oamenilor de afaceri n crearea, schimbarea i conducerea
modelelor de decizii;
4. Utilizarea BDMM (Model de maturitate al managementului deciziilor de business) pentru
consruirea unei hri n implementarea BDM. Acest lucru ajut la reducerea riscurilor i
maximizarea profitului unei investiii;
5. Stabilirea unui centru de excelen a BDM pentru conturarea metodologiilor, livrabilelor,
standardelor i training-urilor;
6. Evoluarea strii curente a cerinelor afacerii prin includerea modelelor de decizii;
7. Pregtirea tehnologiei i investirea n instrumente computerizate de modelare pentru
crearea modelelor de decizii i pentru evaluarea performanei companiei.
Analitii de business sunt cei care n majoritatea cazurilor observ i capteaz logica de
business i creeaz Modelul Decizional, n general pentru un proiect particular. Un instrument
foarte bun pentru oferirea de suport n acest proces l reprezint Ghidul Regulilor de la New
Wisdom Software, LLC. Acesta conine o familie de reguli cu multiple coloane i rnduri.
Fiecare rnd este o regul de business ce poate fi pstrat separat. Tool-ul ofer facilitri de
pstrare a unui glosar de termeni de sunt relevani pentru logica de business precum versiunea,
statusul i motivaia de afacere.
Un analist de business poate crea o diagram ce reprezint un model de decizie prin
utilizarea unor instrumente specifice precum Microsoft Visio, ns acestea nu conin i familii de
reguli sau metadate. Aadar, analistul poate introduce o familie de reguli n tool-ul Ghidul
Regulilor pentru a coordona mai bine coninutul acestuia i aduga metadate relevante.
Principalul avantaj al acestui instrument este ofer o funcionalitate specific modelelor de
decizii i familiilor de reguli, fiind astfel superior utilizrii hrtiei i a pixului, a foilor Excel sau
a diferitelor extensii ale altor tool-uri.
Pentru oamenii de afacerii, care sunt ntre analitii de business i persoanele tehnice,
utilizarea instrumentelor specifice pentru modelarea deciziilor ofer avantajul c pot crea modele
simple de afaceri i cerine, fr a avea nevoie s posede cunotin e speciale pentru a putea
ndeplini o astfel de sarcin i fr a mai fi necesar pentru ei prezena unui analist sau a unui
suport tehnic.
Un alt tip de instrument pentru modelarea deciziilor este cel pentru arhitec ii afacerii.
Aceast aplicaie integreaz modelarea deciziillor cu alte tool-uri pentru modelarea proceselor de
afaceri, precum EA (Enterprise Architecture). Astfel, arhitectul se poate plima prin modelele de

procese de business, prin task-urile de decizii i prin modelele de decizii i familiile de reguli
corespunztoare. Un EA ofer posibilitatea de a urmri deciziile luate n raport cu obiectivele de
afaceri i de a msura gradul n care scopul a fost atins.
n cadrul acestor instrumente, modelele de decizii i grupurile de reguli sunt conectate cu
alte aplicaii ce pot conine cod executabil, oferind suport pentru traducerea modelelor de procese
de business si a modelelor de decizie n livrabile pentru SOA (Service Oriented Architecture).

Capitolul 5 SOA (Service Oriented Architecture) i Modelul Decizional

Capitolul 5 prezint arhitectura software bazat pe servicii (SOA), mpreun cu rolul Modelului
Decizional n cadrul acestui tip de arhitectur. Capitolul debuteaz cu definiia i importana
SOA, continu cu semnificaia serviciului i explicarea celor 4 nivele (layere) n SOA, mpreun
cu diferitele roluri ale serviciului, iar n cele din urm evideniaz maniera n care Modelul
Decizional mbuntete practicile SOA.
Service Oriented Architecture - SOA
SOA (Service Oriented Architecture-Arhitectur software bazat pe servicii) este un tip de
arhitectur software care presupune distribuirea funcionalitii aplicaiei n uniti mai mici,
distincte-numite servicii-care pot fi distribuite ntr-o reea i pot fi utilizate mpreun pentru a
crea aplicaii destinate afacerilor. Capacitatea mare cu care pot fi reutilizate aceste servicii n
aplicaii diferite este o caracteristic a arhitecturilor software bazate pe servicii.
Serviciul SOA
Serviciul reprezint o unitate distinct, individual, a unei funcionaliti specifice unui produs
software, ce devine disponibil prin intermediul unui contract de servicii (service contract). Un
service-contract include toate interaciunile dintre consumatorul serviciului i furnizorul de
servicii.
Importana SOA
SOA are capacitatea de a aduce o valoare semnificativ n cadrul business-ului prin consisten ,
generalitate, modularitate i flexibilitate, deconectare i capacitate de management.
Arhitectura SOA
O arhitectur SOA este mprit n mai multe niveluri. Se definesc patru astfel de niveluri:
Procese de business (orientate pe afaceri), Servicii de business (orientate pe servicii), Servicii
integrate (orientat pe servicii) i Resurse operaionale (orientate pe resurse).
Inventarul de servicii SOA (service inventory)

Baza de organizare a SOA este inventarul de servicii (service inventory), utilitatea SOA fiind
direct proporional cu capacitatea de organizare a acestui inventar. n momentul proiectrii unui
SOA, este foarte important crearea inventarului de servicii. Este necesar ca inventarul de
servicii s fie folositor i pe nelesul tuturor prilor implicate n crearea i gestionarea acestuia.
Determinarea inventarului adecvat trebuie s in cont de mrimea, capacitatea de administrare,
volatilitatea i reutilizarea modelului de decizie.
Rolul SOA
Autorul prezint trei aspecte care definesc SOA, fiecare aspect fiind asociat unui rol (service
role): sarcini de lucru (pentru aciuni procedurale), proceduri de decizie (pentru logic de afaceri)
i entiti de lucru (pentru accesarea datelor i actualizarea acestora).
Importana Modelului Decizional n cadrul SOA
SOA combinat cu Modelul Decizional permite separarea logicii de afaceri de alte aspecte ntr-o
manier n care alte arhitecturi nu o pot face. Separarea logicii de afaceri n servicii discrete ofer
agilitate maxim.

Capitolul 6 Cum mbuntete Modelul Decizional cerinele, analiza de

afaceri i testarea

n lumea IT n care trim, observm c mai mult de jumtate din funcionalitile

dezvoltate sunt rar sau deloc utilizate i c proiectele sunt des ntrziate sau declarate fr succes.
Una dintre cauzele acestor fapte este lipsa comunicrii dintre clieni i echipa de implementare,
precum i o formulare defectuoas a cerinelor.
Cerinele pot fi definite ca fiind condiii necesare astfel nct clientului s i se satisfac
anumite nevoi. Ele pot avea valoare de business, reflectnd n mod direct informaii despre o
nou funcionalitate ce se vrea a fi implementat cerine func ionale sau pot include
informaii despre restriciile pe care le poate avea sistemul (performan a, de exemplu) cerin e
nonfuncionale. Accentul este pus, n cadrul capitolului 6, pe prima categorie.
Modelul Decizional este stabil i poate funciona independent de tehnologia aleas,
ajutnd analitii de afaceri s defineasc cerinele ntr-un mod clar i cuprinztor, avnd la baz
un model clar definit al logicii de afaceri. Modelele reprezint un instrument care ne permite s
vizualizm ceva ce nu poate fi observat n mod direct. Acestea pot fi o reprezentare a realit ii i
ne permit s efectum operaii ntr-o manier mai simpl, ieftin i sigur fa de cum ar fi fost
dac le executam direct n realitate.
n ceea ce privete modelele folosite pentru generarea cerinelor, putem spune c exist
mai multe tipuri de modele legate ntre ele prin intermediul unor puncte de legtur i metadate.

Modelul de luare a deciziilor reflect logica de afaceri, fiind ntr-o strns legtur cu alte
modele folosite pentru formularea cerinelor precum: modele ce reflect planuri strategice i
operaionale, modele ce evideniaz flow-ul activitilor din sistem i ce persoane le execut,
modele semantice ce conin totalitatea termenilor i structura datelor logice, precum i modelele
ce reflect poziiile fizice ale stakeholderilor i ale sistemelor relevante.
Un mod i mai puin abstract dect modelele sau studiile de caz este reprezentat de
prototipuri. Utilizatorii afacerii pot vizualiza cum va arta interfaa software-ului i cum va
reaciona sistemul n diferite ipostaze, n funcie de input-ul primit. Prototipurile pot fi
considerate i ele un model al interfeei cu utilizatorul.
Modelul Decizional ne ofer oportuniti n ceea ce privete crearea unor scenarii de
testare astfel nct procesul de testare s urmreasc ntrutotul logica afacerii. Modelul de luare a
deciziilor poate scurta etapele de dezvoltare i testare semnificativ. O modalitate eficient de
testare a funcionalitilor unui sistem reprezint testarea scenariilor. Aceasta nu testeaz logica
de afaceri n mod direct, ci testeaz ntreagul proces de afaceri implementat pentru un anumit set
de valori date.
Deoarece n lumea IT conceptul Agile i metodologiile folosite n Agile Software
Development au devenit din ce in ce mai rspndite, acest capitol i propune s analizeze dac
Modelul Decizional se potrivete i ntr-o astfel de organizare agil. Cnd vine vorba despre
modul de lucru agil, preluarea cerinelor nceteaz s mai fie doar prima etapa din durata de via
a unui proiect. Cnd vine vorba despre un proiect complex, identificarea ini ial a tuturor
cerinelor ntr-un mod detaliat este aproape imposibil. Tocmai de aceea, Agile ntoarce procesul
de comunicare la 90 de grade, introducnd ideea de iteraii scurte, preluarea cerinelor fcndu-se
la nceputul fiecrei iteraii ca urmare a unei discuii directe ntre utilizatori i toat echipa de
dezvoltatori i analiti. Dezvoltatorii capt i ei, pe aceast cale, rolul de designeri, avnd
dreptul de a veni cu idei de implementare a soluiilor. Cte o parte de software func ional este
livrat la sfritul fiecrei iteraii. Avantajul acestei abordri este acela c software-ul este livrat
rapid, pe baza prioritilor, i feedback-ul clientului este oferit imediat, att la nceputul itera iei
(edina de planificare), ct i la sfritul iteraiei (edina de demonstarare a func ionalit ilor
noi).

Capitolul 7 Modelul Decizional n practic

Modelul decizional a fost aplicat cu succes n mai multe corporaii, avnd ca scop
primordial livrarea unor decizii de business ntr-o form concret i uor de gestionat. Chiar i
ntr-o form restrns, acesta stabilete scena pentru o gndire strategic de afaceri, creativitate i
originalitate. Utilizarea acestor principii trebuie s conduc la o productivitate sporit i la
ndeplinirea unor obiective care au rmas evazive nainte de a aplica Modelul Decizional.

Abordarea acestui capitol se ntocmete pornind de la un proiect fic ional prin intermediul cruia
se vor parcurge paii necesari iniierii i completrii procesului decizional aferent proiectului.
Paii care trebuie urmai cu strictee sunt:

ndeplinirea unui ordin executiv de management

Construirea unei echipe de proiect cu abiliti n elaborarea unui Model
Decizional
Definirea unui scop precis al Modelului Decizional
Dezvoltarea unei decizii n urma analizei efectuate
Crearea, testarea i rafinarea unei decizii nainte de punerea n aplicare
Automatizarea Modelului Decizional n sisteme curente
Planificarea pentru sisteme viitoare: SOA (System-Oriented Architecture),
BRMS (Business Rules Management System), BPMS (Business Process Management
System) sau Guvernana Modelului Decizional.

Pasul 1: ndeplinirea unui ordin executiv de management

Situaia iniial prezint o companie fictiv de asigurri specializat n asigurri
comerciale care este interesat de viabilitatea serviciilor de asigurri auto furnizate de aceasta.
Profitul obinut se bazeaz pe venituri generate din emiterea de noi poli e de asigurare sau
rennoirea celor care expir. Activitatea companiei este susinut n prezent de un set de sisteme
motenite i dezvoltate acum multe decenii.
Echipa de management executiv dorete s creasc numrul de polie noi i rennoite n
urmtoarele ase luni, emind un mandat prin care 75% din cele dou tipuri de polie trebuie s
fie intermediate prin sisteme automatizate. De asemenea, se dorete creterea satisfacerii
clienilor i a veniturilor cu 15%.
Pasul 2: Construirea unei echipe de proiect cu abiliti n elaborarea unui Model Decizional
Dup emiterea mandatului de ctre echipa de management executiv, se alege un manager
de proiect care are cunotine n domeniul asigurrilor auto i al tehnologiei informa iilor. Scopul
acestuia implic regndirea logic a procesului de afaceri pentru a distinge politicile adecvate
automatizrii comparativ cu prelucrarea uman. Coninutul noului Model Decizional va fi testat
i reglat pn cnd se vor atinge obiectivele enunate mai sus. Echipa de proiect va trebui s
dein aptitudini de modelare i decizionale.

Figur 11: Organigrama echipei de proiect

Pasul 3: Definirea unui scop precis al Modelului Decizional

Domeniul de aplicare al modelului de decizie include o list a obiectivelor de afaceri, a
riscurilor implicate, a resurselor umane, a rezultatelor obinute i a bugetului necesar. Astfel, se
pot ntocmi ase aspecte unice pentru a define scopul Modelului Decizional:

Scopul procesului de afaceri al modelului

Scopul deciziilor
Prioritizarea tranzaciilor de afaceri pentru deciziile definite
Propunerea unei liste de pi pentru definirea logicii de business
Indicatorii de performan ai afacerii
Estimrile modelului decizional

Pasul 4: Dezvoltarea unei decizii n urma analizei efectuate

Echipa de proiect dezvolt iniial diagramele Modelului Decizional. n cazul n care
aceasta a petrecut suficient timp pe un model de proces de afaceri pentru poli e noi i rennoite,
echipa a realizat c cele dou procese se aseamn astfel nct se pot combina ntr-unul singur,

mai generic. De fapt, este o mare probabilitate ca cele dou procese s se fi unit pn ntr-un
anumit punct, ca apoi cele dou scenarii s depind de tranzacia efectuat: nou sau
regenerabil. Figura de mai jos ilustreaz al treilea nivel de detaliere al Modelului Decizional.

Figur 12: Nivelul trei de detaliere al Modelului Decizional

Pasul 5: Dezvoltarea unei decizii n urm analizei effectuate

ndat ce echipa de proiect ajunge la un consens cu privire la modelul de proces de
afaceri, aceasta confirm ce grupuri interesate vor beneficia de Modelul Decizional i felul n
care o vor face. Prile interesate de acest studiu pot fi clien i, ageni de vnzri sau manageri
regionali. n acest moment, echipa trebuie s nceap s dezvolte diagrama modelului de decizie,
iar membrii echipei s cad de acord asupra anumitor standarde ce vor fi urmate n cadrul
dezvoltrii modelului decizional. Aceste standarde includ denumirea conveniilor pentru deciziile
de afaceri i un set valid de operatori utilizabili n diagrama Familiei de Reguli.
Astfel, trebuie explorate urmtoarele situaii:

Care dintre aciunile utilizate n sistemele curente ar trebui folosite n viitorul model?

Pentru a atinge obiectivele i indicatorii de performan ai afacerii, ce alte tipuri de

aciuni reprezint un interes?

Ce tipuri de fapte reprezint interes pentru prile implicate?

Ar trebui s existe un mecanism prin care un expert s disting diferen ele dintre
automatic i manual?

Exist specificaii legate de regiune?

Ce informaii legate de noile aciuni propuse sunt disponibile n acest punct al

procesului?

Paii 6-7: Crearea, testarea i rafinarea unei decizii nainte de punerea n aplicare
Atunci cnd sunt dezvoltate urmtoarele aciuni de implementat, persoanele responsabile
de IT ar trebui s ruleze de mai multe ori rapoartele ntr-un mediu de testare pentru a stabili
modul n care tranzaciile curente vor fi tratate n modelul decizional. Astfel, se ofer o imagine

despre modul n care se va efectua logic afacerii nainte c modelul de decizie s fie pus n
aplicare n codul programului.
Pasul 8: Automatizarea modelului decizional n sisteme curente
Atunci cnd modelul de decizie i familiile de reguli ating un status acceptabil, echipa le
va prezena grupului de IT. De asemenea, se vor dezvolta cazurile de testare pentru a verifica
logic de afaceri n implementarea modelului decizional. Acest grup va determina ulterior unde
n sistemele de motenire se vor produce schimbri, oamenii de afaceri vor testa aceste
modificri, iar schimbrile vor fi aduse n producie.
Pasul 9: Planificarea pentru sisteme viitoare SOA, BRMS, BPMS i Guvernana
n cazul n care este primul model decizional elaborat, acesta va fi relevant pentru SOA,
BRMS, BMPS i guvernana asupra logicii de afaceri. Grupul de IT poate utiliza diagramele
modelului de decizie pentru a evalua aplicabilitatea unui BRMS, astfel nct logica afacerii s fie
separat de alte afaceri i de problemele tehnice. De asemenea, pentru a evalua tehnologia BPMS
se poate gestiona fluxul de lucru al tranzaciilor prin prile procedurale ale procesului de afaceri.

Capitolul 8 Principiile Structurale ale Modelului Decizional

Principiile structurale permit crearea unui Model Decizional care este uor, intuitiv i care nu
poate crea confuzie deoarece este uor de interpretat.
Scopul pricipiilor este de a minimiza complexitatea i maximiza n elegerea Modelului
Decizional. Acestea au rolul de a uniformiza structura acestuia astfel nct modelul s fie
ntotdeauna reprezentat ntr-un singur mod.
Principiile 1 4 definesc structura de baz.
1.
2.
3.
4.

Forma tabular ( tabel)

Capul tabelului
Celule
Rnduri

Principiile 5 6 se refer la nvturile trase din model, n timp ce principiul 7 se refer la

conexiunile folosite.
5. Concluzii
6. Condiii
7. Conexiuni
Principiul 1 se refer la forma generala a unui model. Acesta are forma unui tabel cu dou
dimensiuni: capul de tabel i corpul tabelului. Aceast form se mai numete i Familia de
Reguli. Aezarea n spaiu a celor dou dimensiuni poate fi orizontal sau vertical, ns
ntodeauna capul tabelului este prima dimensiune.

Figur 13: Tabel cu aezare orizontal

Figur 14: Tabel cu aezare vertical

Principiul 2 conine o informaie general ( clasificare ) legat de con inutul coloanei pe care se
afl(ex: ani, vrst, etc.). n tabelul de mai jos se poate vedea un model care se refer la istoricul
n cmpul muncii al unei persoane.

Figur 15: Set de reguli de familii pe coloane

Principiul 3 se refer la celulele unui tabel. O celul este reprezentat de intersec ia unui rnd cu
o coloan. Informaia coninut n celul trebuie s se refere la capul de tabel i s con in un
operator i un operand. Tabelul urmtor arat istoricul prezentat mai sus sub forma unui scoring
pentru clasificarea unui potenial angajat.

Figur 16: Familie de Reguli posibil, cu operatori i valori

Opratorii folosii sunt Is Less Than/E mai puin de i Is Greater Than/E mai mare de, n
vreme ce operanzii conin o singur valoare 1, 3, 8, i Good sau Poor..
Principiul 4 se refer la conceptul dependenei funcionale. Aceasta nseamn c valorile unei
celule sau set de celule determin valorile altei celule din aceeai Familie de Reguli.

Figur 17: Concluzie de tip fapt bazat pe o condiie de tip fapt

Principiul 5 se refer la concluzia tras din analiza modelului. Concluzia este generat din
informaiile coninute de Familia de Reguli. Aceasta nu poate genera dect o concluzie.

Figur 18: Familie de Reguli cu o singur concluzie

n tabelul de mai sus, o concluzie referitoare la rating-ul creditului persoanei este dat de cele
dou informaii Person Employment History i Person Debt.
Principiul 6 se refer la infomaiile de tip condiie dintr-o Familie de Reguli. Toate celulele care
conin informatii de tip condiie trebuie s fie adevrate pentru a ajunge la o concluzie adevarat
(celulele conin informaie de tip AND pentru a ajunge la concluzie; nu sunt permise condi ii de
tip OR pentru a ajunge la o concluzie pozitiv).

Figur 19: Regul tipar unde concluzia este dependent de ambele condiii

Principiul 7 se refer la conexiunile dintre Familiile de Reguli. Asta nseamn c aceast

conexiune este o legtur logic ntre concluzia unei Reguli de Familii i condiia unei alte
Familii de Reguli. Pe scurt, concluzia tras din informaia coninut de o Familie de Reguli poate
servi ca i condiie ntr-o alt Familii de Reguli.

n tabelul de mai sus concluzia Person Credit Rating rezultat din primul model este folosit ca
i conditie n cel de-al doilea model.
Aceste 7 principii pot fi folosite n ordinea lor pentru a construi un Model Decizional de baz.
Acest model poate fi mai trziu modificat sau adaptat pentru a include sau scoate informa ii din
el.

Capitolul 9 Principiile Declarative ale Modelului Decizional

Un model decizional ar trebui s fie declarativ i independent de tehnologie i alte
considerente deoarece n acest fel furnizeaz stabilitate i flexibilitate n design-ul i
managementul propriei logici de afaceri. O soluie declarativ este diferit de cea procedural

deoarece aceasta implic tot ceea ce trebuie realizat, pe cnd cea procedural se refer la modul
n care/cum se realizeaz ceva.
n cazul unui Model Decizional, munca efectuat determin concluzia unei soluii de
business, ca apoi structura declarativ pentru un model decizional s specifice doar ce anume
trebuie fcut pentru determinarea concluziei ntr-o decizie de business. Cu alte cuvinte, structura
declarativ reprezint doar logica business-ului necesar obinerii rezultatului unei decizii de
afaceri, dar nu i modul n care aceasta este executat/implementat.
O structur procedural pentru un model decizional va specifica pas cu pas, cum se va
implementa logica afacerii cu scopul de a determina concluzia unei decizii de afaceri. Cu alte
cuvinte, Modelul Decizional procedural va aborda aceleai condiii i concluzii ca n cazul
structurii declarative, dar aranjate ntr-o secven de execuie deliberat. Deci, n general, o
abordare procedural pentru a atinge un obiectiv este o progresie pas cu pas cu scopul de a
ajunge la el. Pe cnd abordarea declarativ este independent de aceast progresie deoarece paii
sunt irelevani n atingerea obiectivului.
Chiar dac se cunoate foarte bine abordarea declarativ, este ntotdeauna o provocare s
descoperi structura declarativ pentru un model de decizie particular. De exemplu, experii n
afaceri cunosc foarte bine logica business din cadrul unui proces decizional. Poate c ei tiu s-l
realizeze pas cu pas sau poate c acetia tiu cum sistemele de susinere efectueaz logica de
afaceri printr-o implementare pas cu pas. Deci abordarea naturii declarative a unui model
decizional chiar i atunci cnd se lucreaz cu oameni care tiu logica de afaceri curent este de
obicei o activitate de nvare iterativ. Activitatea are ca scop depirea gndirii curente
procedurale i devine un exerciiu de regndire a afacerii.
Faptul c un model decizional sprijin independena logicii afacerii nseamn c acesta
permite schimbri n modul n care logica afacerii este stocat fizic, accesat i executat, fr a
fi nevoie de schimbri n modul n care logica afacerii este perceput de ctre public. Modelul
Decizional aduce aceast distincie n prim plan, iar practicienii vor livra dou modele diferite:
un model de proces de afaceri procedural i un model decizional declarativ. Un model decizional
declarativ funcioneaz corect indiferent de cine sau ce sistem l proceseaz i n care secven
este fcut procesarea. O structur a unui Model Decizional adernd la principiile declarative, nu
se bazeaz pe o anumit secven de prelucrare. Orice metod de prelucrare a rezultatelor duce la
o concluzie corect. Atunci cnd se ntmpl acest lucru, modelul este reutilizabil i constituie
punctul de plecare pentru multe tehnologii, chiar i dac tehnologia se maturizeaz n timp.
Aplicarea principiilor declarative nseamn eliminarea constrngerilor inutile din struncturile
Modelului Decizional deoarece acestea impun o secven inutil. Aceasta nseamn livrarea unui
Model Decizional lipsit de limitri secveniale atunci cnd nu este nevoie de acestea. n acest
sens exist cteva principii declarative care abordeaz natura declarativ a anumitor aspecte din
cadrul modelului decizional:
Titlul declarativ (Principiul 8)

 Corpul declarativ (Principiul 9)

Relaiile declarative (Principiul 10)

Titlul declarativ
Acest principiu elimin constrngerile procedurale inutile din titlul unei familii de reguli.
Tipurile de fapte din titlurile unei familii de reguli sunt neordonate. (Sau, n mod informal, nu
exist nicio secven implicit la coloanele unei familii de reguli). Acest principiu prevede c nu
trebuie s existe nicio ordine implicit n secvena tipurilor de fapte n titlul unei familii de
reguli. Cel mai important lucru este faptul c nu exist nicio semnificaie ascuns n spatele
secvenei coloanei dintr-o familie de reguli. De exemplu, tabelul urmtor arat o familie de reguli
cu dou coloane avnd fiecare cte o condiie.

Figur 20: Diagrama familiiei de reguli n care secvena condiiilor este irelevant

Principiul 8 ne informeaz c tabelul de mai sus nu sugereaz faptul c, coloana din stnga din
cadrul Conditions trebuie evaluat nainte ca cea de-a doua coloan din cadrul Conditions s
fie evaluat. Concluzia corect este atins indiferent dac un sistem sau o persoan evalueaz
Person Years at Current Employer nainte sau dup ce a evaluat Person Number of Jobs n Past
Five Years.
Corpul declarativ
Acest principiu elimin constrngerile procedurale inutile din componena unei familii de reguli.
Intrrile n componena unei familii de reguli sunt neordonate (sau informal, nu exist nicio
secvena implicat ntr-o familie de reguli). Principiul prevede c nu poate exista o ordine
implicit sau un sens ascuns n spatele unei secvene a rndurilor dintr-o familie de reguli.
Rndurile nu trebuie s fie evaluate sau interpretate ntr-o secven specificat. Nu exist niciun
neles ascuns n spatele unei secvene a rndurilor.
De exemplu, familia de reguli n Tabelul 20 arat 2 rnduri ntr-o secven particular unde
primul rnd este superior, iar al doilea rnd este mai jos. Acest principiu avertizeaz faptul c
tabelul nu este menit s sugereze c trebuie evaluat rndul superior. De fapt, nu exist nicio

diferen dac un sistem sau o persoan evalueaz rndul superior, al doilea sau al treilea rnd.
Tabelul ar fi putut avea rndurile n orice alt ordine.
Deoarece acest principiu prevede c secvena de rnduri nu conteaz, modelul decizional trebuie
s aib un mod de a diferenia fiecare linie de alt nedepinznd de secvena rndurilor.
Principiul 9 rezult n structur cu rnduri declarative, ceea ce nseamn c secven a de rnduri
nu are nicio semnificaie. De fapt, un rnd este unic identificat, nu prin pozi ia sa, ci prin cheile
condiionale. Prin urmare, acest principiu ofer reguli care pot fi implementate n una sau mai
multe tehnologii chiar dac o tehnologie execut rndurile ntr-o secven , alt tehnologie le
execut n alt secven i o alt tehnologie determin dinamic secvena rndurilor. Acest lucru
se ntmpl deoarece, n mod logic, secvena de evaluare a rndurilor nu provoac nicio
diferen. Aplicarea acestui principiu n practic este de obicei simpl. Este folositor s vezi
rndurile ntr-o anumit secven cum ar fi gruparea tuturor rndurilor mpreun pentru un
anumit model de reguli.
Relaii infereniale declarative
Acest principiu elimin constrngerile procedurale inutile din relaiile inferen iale din cadrul
familiilor de reguli - Nu exist nicio secven implicat n familia regulilor relatat prin rela ii
infereniale.
Principiul 10 prevede c nu poate exista nici o interpretare ascuns n spatele secven ei, de la
stnga la dreapta sau de sus n jos, cu privire la modul n care deduc ia familiilor de reguli
nrudite sunt descrise ntr-o diagram a modelului de decizie. n plus, familiile de reguli nu
trebuie s fie aplicate sau executate n ordinea n care apar n diagrama.
Ca un exemplu, Figura 21 conine un set de familii de reguli pentru a determina suma redus
pentru nchirierea unei maini. Aceste dou condiii conin familii de reguli care sunt legate
printr-o relaie inferenial. Coloana concluzie a familiei de reguli 1 apare ca o coloan de
condiie n familia de reguli 2. Dei familia de reguli 1 este etichetat ca "Familie de reguli 1"
apare n partea de sus a diagramei, i are, de asemenea, o concluzie care pare a fi introducere
pentru familia de reguli 2, aceast schema neimplicnd o secven particular de procesare.
Aceast diagrama nu implic faptul c familia de reguli 1 trebuie s fie evaluat nainte de
familia de reguli 2. Nu exist nicio diferen dac un sistem sau o persoan evalueaz familia de
reguli 1 prima data sau familia de reguli 2. Figura ar putea la fel de uor s arate familiile
regulilor din diferite locaii pe diagrama. Relaia inferenial n orice diagrama va implic
ntotdeauna rating-ul creditului.
La prima vedere, poate prea c singur secvena n care, pentru a procesa familiile regulilor
nseamn a procesa familia de reguli 1 prima, urmat de familia de reguli 2. Dar acest lucru nu
este singura soluie posibil.

Figur 21: Familii de reguli ce descriu relaiile infereniale

Principiul 10 susine c relaiile dintre familiile de reguli sunt conexiuni logice. Nu numai c
autodefinirea relaiei infereniale este bazat pe structura logicii de sine, dar aceasta nu implic o
anumit implementare fizic pentru a sprijini aceast conexiune (de exemplu pointeri, indexare,
stocare n secvena potrivit). n acest fel, natura declarativ a relaiei infereniale permite variaii
n implementare, pstrnd n acelai timp structura logic original.
Principiul 10 rezult n deducia legat de familiile de reguli ale cror relaii inferen iale sunt
declarative. Relaiile familiei de reguli nu trebuie parcurse n secvena de sus n jos sau de la
stnga la dreapt. Acest lucru nseamn c secvena n care sunt evaluate familiile de reguli nu
are nicio semnificaie: secvena este nemrginit. Relaiile familiei de reguli inferen iale sunt
importante pentru c structura ntregului model decizional poate fi evaluat n orice secven.
Aplicarea Principiului 10, n practic, este de obicei simpl, odat ce se cunoa te faptul c
modelul decizional nu are un nceput sau un final prescris. Acesta are un scop i anume concluzia
unei decizii de afaceri.
Obiectivul unui Model Decizional este concluzia unei decizii de afaceri. n realitate, el poate fi
atins urmrind nite pai n cteva secvene. Principiile Declarative relev faptul c aceti pai i
secvena lor ar trebui s fie invizibili i irelevani atunci cnd are loc crearea i nelegerea logicii
de afaceri pur a unui model decizional. Paii i secvena lor, n cazul n care ntr-adevr sunt

invizibili, pot fi schimbai fr a schimba funcionalitatea modelului decizional. Modelul

decizional va determina ntotdeauna rezultatul unei decizii de afaceri pe baza unor criterii de
afaceri specificate de ctre experii n afaceri.
Desigur, un anumit set de pai pentru navigarea ntr-o structur a modelului decizional i
secvena lor pot avea implicaii enorme pentru performan. Dar performana este legat de
tehnologie, de date specifice i de volume de date tranzacionate. Modelul decizional nu trebuie
s se limiteze la tehnologie, volume de date tranzacionate sau la o singur cale de procesare. n
cazul n care acesta rmne fr restricii, va rezista la maturizarea tehnologiei, precum i la
creterea volumelor i direciilor n ceea ce privete afacerile.

Capitolul 10 Principiile Integritii ale Modelului Decizional

Acest capitol introduce principiile Modelului Decizional, care abordeaz aspecte
suplimentare ale integritii pentru a asigura c logica de afaceri are sens. Integritatea modelului
de decizie este definit ca fiind proprietatea care msoar dac coninutul acestuia are sens.
Exist trei moduri n care coninutul unui model de decizie ar trebui s aib sens: structural
(redundant minima), logic (consistent i complet), i businesswise (influeneaz performan
afacerii).
Scopul principiilor de integritate este de a minimiza anomaliile logicii de business n
coninutul modelului de decizie.

Figur 22: Aspecte ale Integritii Modelului Decizional

Principiul 11: Regula principiului condiiilor modelului tranzitiv

Principiul 11 elimin redundanele ntr-un model de reguli prin eliminarea dependenelor
funcionale dintre condiiile sale, reducndu-se astfel un model de reguli din a dou form
normal la una n a treia form normal. Acest principiu se adreseaz de fapt unui model de
decizie cu form normal 3. Scopul acestei forme este de a elimina dependenele funcionale
dintre condiii. Form normal 3 nseamn c, la fiecare rnd, nu exist condiii care conduc la o
concluzie cu privire la o alt condiie.
Principiul 11 prevede c nu poate exista nici un subset de condi ii cheie al unui model de reguli
care conduce la o concluzie cu privire la un subset al lui de condiii cheie. Atunci cnd o parte
dintr-o condiie cheie determin n mod logic o alt parte, concluzia nu este determinat n mod
direct de subset. Principiul 11 asigur c sunt ndeplinite condiiile dintr-o condiie cheie sunt cu
adevrat independente unul fa de cellalt.
Un model de reguli, cu o dependen funcional ntre condiii poate fi ntotdeauna
descompus, fr a pierde intenia sa, ntr-un set de modele de reguli, fiecare dintre ele neavnd
dependene funcionale ntre condiii. Principiul 11 conduce la descompunerea unui model de
reguli n mai multe modele de reguli prin eliminarea redundanei, i nu pierde inten ia structurii
originale. Aplicnd Principiul 11 n practic nseamn a cuta dependene inferen iale ntr-o
condiie cheie i se poate face n 5 etape.
Principiul 12: Familia de reguli i Rolul principiului modelului de consisten
Acest principiu elimin neconcordanele ntr-un model de reguli i printre care se
suprapun modele de reguli. O familie de reguli ar trebui s fie liber de neconcordan e n cadrul
fiecrui model de reguli i ntre modele de reguli. n esen, Principiul 12 prevede ca logica de
afaceri ntr-un model de reguli i familie de reguli nu poate conine erori logice involuntare.
Principiul 12 prezint apte subprincipii care au fost aplicate i s-au dovedit utile n absena unui
software sofisticat:
Principiul 12a: n general, o regul de model ar trebui s rezulte n cel mult o valoare concluzie
pentru orice set al valorilor de intrare valide pentru tipurile de condi ii. Acest subprincipiu
prevede c, n general, executarea unei reguli model ar trebui s conduc la o concluzie sau la
nicio concluzie; aceasta nu ar trebui s conduc la concluzii multiple. Acest subprincipiu afirm
pur i simplu c un anumit model regul ntr-o familie de reguli nu trebuie s conduc la o
valoare concluzie pentru valorile de intrare valide, deoarece un alt model regul poate face acest
lucru.
Principiul 12b: Principiul modelului regul condiiei cheie de acoperire-Condiiile unui model
regul trebuie s acopere doar subsetul tipurilor de condi ii dominate care se ncadreaz n
domeniul de aplicare. Acest subprincipiu afirm c, n timp ce condiiile dintr-o regul de model
trebuie s reprezinte este care sunt consistente cu tipul de stare care st la baz, condi iile nu
trebuie testate pentru toate valorile posibile de domeniu pentru orice tip de condiie de stare. n

schimb, o regul model poate avea un scop care se limiteaz la un subset al domeniilor de tip
stare i de aceea trebuie s acopere numai subsetul. Acest subprincipiu pur i simplu arat c,
condiiile unei reguli model trebuie s abordeze doar valorile de intrare pentru condiiile n care
regul model este de ateptat s proceseze.
Principiul 12c: Principiul modelului regul de suprapunere a condi iei cheie de acoperire
-ntr-o singur regul de model, o suprapunere a condiiei cheie de acoperire nseamn c exist
inconsisten n regul modelului. Acest subprincipiu se refer la o situa ie care conduce la un
singur model regul care rezult n mai mult de o singur concluzie.
Principiul 12d: Principiul regulei de familie de suprapunere a condi iei cheie de acoperirePeste dou reguli model n aceeai familie de reguli, o suprapunere de multe ori a condi iei cheie
de acoperire nseamn c exist inconsisten n familia de reguli. n cele mai multe cazuri,
atunci cnd mai mult de o valoare concluzie este posibil de la executarea regulii model
suprapunnd condiia cheie de acoperire, exist o inconsisten logic n regul familiei.
Principiul 12e: Principiul familiei de reguli a valorilor de concluzie minime-O familie de
reguli trebuie s conduc la cel puin o valoare concluzie pentru orice set de valori de intrare
valide pentru tipurile de condiii fapt. n capitolul 8, principiul 7 prevedea c o familie de reguli
nu poate avea celule de concluzie goale, deoarece celul concluzie prevede legtur care
conecteaz reguli de familie. n cazul n care o celul concluzie este goal, conexiunea nu este
cunoscut, iar model de decizie este rupt. Acelai lucru este valabil i n cazul n care o regul de
familie nu are nicio celul goal de concluzie, dar condiiile sale sunt de aa natur nct nicio
condiie-cheie nu evalueaz corect pentru un set de valori valide de intrare. n acest caz, nu se
ajunge la o concluzie. Acest lucru are acelai efect c o concluzie goal. Legtura care
conecteaz familiile de reguli este rupt.
Principiul 12f: Principiul familiei de reguli a valorilor de concluzie maxime-O familie de
reguli poate avea ca rezultat mai mult de o valoare concluzie pentru orice set de valori de intrare
valabile pentru tipurile de condiii de fapt. Acest subprincipiu afirm c o familie de reguli, spre
deosebire de o regul model, poate avea ca rezultat mai mult de o valoare concluzie.
Principiul 12g: Principiul familiei de reguli a concluziei cheie de acoperire-Concluziile dintro familie de reguli trebuie s fie acoperite de un singur subset de concluzii care sunt n
concordan cu scopul. n capitolul 8, principiul 3 prevedea c fiecare celul ntr-o familie de
reguli este conform cu tipul de fapt. Aceasta include celula concluzie. Cu toate acestea,
concluziile din familiile de reguli nu trebuie s conduc la valori care s acopere toate valorile de
domeniu posibile pentru tipul de concluzie fapt. n schimb, o familie de reguli poate avea un
scop care se limiteaz la un subset al domeniilor de tip fapt i deci trebuie doar s acopere acel
subgrup. Pe scurt, acest subprincipiu exprim pur i simplu, c concluziile unei familii de reguli
este necesar s se adreseze numai valorilor pentru concluziile la care este de a teptat s se
ajung.

Principiul 12 elimin inconsistena din coninutului modelului de decizie prin care descrie
situaii ntr-un model de decizie n care inconsisten n logic de business poate fi ascuns, dar
ele nu pot fi evidente. Prin descoperirea unor astfel de situaii, principiul 12 ajut la identificarea
locurilor n modelul de decizie unde concluziile nu sunt cum erai de ateptat.
Principiul 13: Principiul Condiiilor Tranzitive ale Familiilor de reguli
Principiul 13 elimin redundanele n rndul familiilor de reguli n acelai mod n care principiul
11 elimin redundanele printre condiiile regulii model. Principiul 11 i Principiul 13 rezolv
dependene infereniale tranzitive. Principiul 13 prevede c nu pot exista dependene tranzitive
ntre familii de reguli. O dependen tranzitiv este una n care o concluzie de tip fapt ntr-o
singur regul de familie servete ca un tip de condiie de fapt n alte dou familii de reguli; de
asemenea, concluzia tipului de fapt ntr-una dintre aceste din urm familii de regul servete
drept condiie de tip fapt n cealalt. Dependenele tranzitive n rndul familiilor de reguli devin
evidente, de obicei, ntr-o diagrama de model de decizie.
Principiul 13 elimin redundane prin descoperirea dependenelor infereniale ascunse printre
familii de reguli. Ca i la Principiul 11, eliminarea acestor redundane simplific ntre inerea i
reduce riscul de erori de logic n afaceri.
Principiul 14: Principiul integritii deductibile
Acest principiu asigur desvrirea relaiilor deductibile n Familia de reguli. O familie de
reguli auxiliar este o familie de reguli a crei concluzie este o contitie pentru o alt familie de
reguli. Principiul 14 presupune faptul c fiecare valoare a unei concluzii a familiei de reguli
auxiliare ar trebuie acoperit de condiia corespunztoare din Familia de reguli dependent. Dac
un Model de Decizie nu este n acord cu Principiul 14 nseamn c acesta con ine cel pu in o
familie de reguli auxiliar care nu este n corespondena cu Familia de reguli dependent.
Principiul 14 asigur faptul c toate relaiile deductibile din Modelul Decizional sunt complete.
Acesta conduce ctre un coninut complet dintr-o perspectiv logic i nu rateaz nici o logic
evident.
Principiul 15: Principiul alinieri de afaceri
Acest principiu presupune faptul c un Model de Decizie, ca un livrabil coeziv, trebuie s fie
utilizat ca o prghie pentru afaceri, servind ca un mijloc de a ob ine un rezultat dorit. Principiul
15 este, probabil, cel mai important principiu. Acesta dezvluie importana relativ a fiecrui
Model de Decizie. Astfel, dezvoltarea i meninerea fiecrui Model de Decizie poate fi
prioritizat i tehnologia adecvat poate fi selectat n funcie de valoarea adugat anticipat.
n practica general, un Model de Decizie este proiectat ctre o direcie specific. Acestea pot fi,
strategii la nivel nalt, tactici intermediare sau obiective specifice. Principiul 15 asigur faptul c
un Model de Decizie indic o logic a afacerii de la care se ateapt s aduc o performan a
afacerii ateptat.

n practic, Principiul 15 este aplicat n mai muli pai de-a lungul unui proiect. Primul pas este
acela de a recunoate o oportunitate de afacere sau o provocare a crei soluie este ascuns parial
n Modelul de Decizie. Al doilea pas este acela de a identifica parametrii specifici de msurare a
directivelor afacerii. Exist muli pai adiionali, cum ar fi dezvoltarea modelelor de procesare a
afacerii i identificarea deciziilor de afacere care se aplic n modele.

Capitolul 11 Modelul Decizional i Modelul Relaional

Analiza asemnrilor i deosebirilor dintre modelul decizional i modelul relaional este una
interesant. Pentru a face acest exerciiu, trebuie luate n calcul ase observaii:
1.
Fiecare model definete un mod netehnologizat de organizare al unui bun intelectual al
unei afaceri (date versus logic de business)
2.
Fiecare model poate fi implementat cu ajutorul unei tehnologii, dei acesta nu descrie o
tehnologie
3.

Fiecare model este o soluie la o problem uzual nerezolvat

4.
Fiecare model are urmtoarele caracteristici: structur simpl, natur declarativ i
integritate optimal
5.

Fiecare model reprezint baza unei soluii tehnologice

6.

Cele dou modele sunt similare dar diferenele dintre ele sunt interesante.

Asemnrile i deosebirile dintre cele dou modele au legtur cu zece caracteristici care fac ca
aceste modele s fie unice. Cele zece caracteristici sunt urmtoarele:
1.

Fundaie structural

2.

Caracterul declarativ

3.

Coninut

4.

Principiul de organizare primar

5.

Prima form normalizat

6.

Dependine funcionale

7.

Identificatori

8.

Conexiuni

9.

A dou form normalizat

10.

A treia form normalizat

Impactul Modelului Relaional a fost foarte mare deoarece acesta este unul dintre cele mai
importante modele din aria informaticii. naintea lui, datele pentru sistemele automate erau
stocate n dosare secveniale sau n baze de date tehnologice. Fiecare tehnologie avea modaliti
specifice de stocare a datelor, incompatibile cu alte sisteme.
Scopul designului bazei de date a fost s maximizeze viteza de procesare a datelor i s
micoreze spaiul de stocare. O organizare logic a datelor standardizeaz designul bazei de date,
acesta devenind compatibil cu mai multe tehologii. Dei de-a lungul timpului au fost diverse
invenii i descoperiri n domeniu, Modelul Relaional a supravieuit deoarece la baza lui stau
teorii matematice, calcule relaionale i algebrice i conceptul normalizrii. Aadar, Dr. Codd este
cunoscut ca fiind cel care a definit cele trei forme de normalizare.
n zilele noastre, Modelul Relaional este ntlnit peste tot n sfera informaticii, bazele de date
nerelaionale nemaifiind folosite. Modelul Relaional descrie relaiile, dependenele funcionale,
normalizarea, domeniile, cheile primare, cheile externe, entitatea, integritatea referenial i
operaiile de manipulare a datelor. Acest model i tehnologiile referitoare la acesta i-a fcut pe
oameni s reorganizeze modul de structurare, organizare, accesare, design i implementare al
datelor ca i bun al unei afaceri. De fapt, modelul relaional al datelor a dus la concepte precum
data warehousing, data marts, business intelligence, data stewardship, calitatea datelor.
Impactul Modelului Relaional nu a constat numai ntr-o generaie nou de software, dar a
deschis o nou er informaional. Cea mai evident diferen dintre Modelul Rela ional i
Modelul Decizional este c fiecare model folosete o resurs diferit: Modelul Relaional
folosete date, iar Modelul Decizional este un model al logicii de afacere (set de reguli). Datele
implic existena unor lucruri care exist n lumea real, unele dintre ele nefiind legate de o
anumit afacere (ex: numele unei persoane). Totui, o parte din date sunt create de afacere (data
livrare, cantitate livrat, etc)
Modelul Decizional este un model al concluziilor din lumea real (evaluri, clasificri,
determinri ale afacerii) pe care afacerea este interesat s le stocheze. Modelului de business din
lumea real i corespund constrngeri, calcule i scenarii condiionate. Logica de business
presupune analiza mai multor aspecte, precum venitul anual al unei persoane i ratingul de
creditare al acesteia ce duc la concluzii despre alte fapte, precum posibilitatea unei persoane de a
acces un credit.
Cele dou active, datele i logica de afaceri, sunt fundamental diferite, avnd scopuri i
caracteristici diferite. Cea mai mare asemnare dintre cele dou modele este faptul c ambele
constituie template-uri intelectuale pentru organizarea logic i riguroas a unui bun intangibil.
Analiz detaliat a celor dou modele:
1.
Fundaie structural Ambele modele au o fundaie structural bidimensional, simplu
de interpretat i de ntreinut.

2.
Caracterul declarativ Ambele modele sunt declarative prin natura lor, fiind
independente de orice tehnologie sau alte aspecte. Caracterul declarativ al modelului este
independent de limitrile secveniale.
Aadar, atributele unei relaii pot aprea n orice secven, fr c acestea s fie adiacente. Acest
caracter face ca datele s fie independente: chiar dac modul de stocare al datelor sau al logicii
de business se schimb, user-ul nu va sesiza acest lucru.
3.
Coninutul Coninutul Modelului Relaional este reprezentat de un set de date
(atribute), iar coninutul modelului decizional este reprezentat de un set de reguli de afaceri. O
nregistrare/logic de afacere reprezint un atribut individual/o expresie logic individual care
fac parte din acelai tot unitar, dup cum spune Modelul Relaional/Modelul Decizional.
4.
Principiul de organizare primar Principiul de organizare primar pentru ambele
modele este prima form normalizat. O relaie i un set de reguli sunt prin defini ie n aceast
form.
Normalizarea n modelul relaional const n analiza i descompunerea structurilor de date ntrun nou set de date mai uniforme, mai stabile i care au mai multe propriet i n comun. n
modelul decizional, normalizarea acioneaz la fel, doar c de data aceasta, n locul setului de
date avem un set de logici de afacere.
5.
Prima form normal dei se dorete obinerea unei forme ct mai mari de
normalizare, prima form este necesar n ambele modele pentru o minim integritate structural.
n ambele modele, prima form impune o disciplin a coninutului, simplificndu-l, astfel nct
modelul s fie reprezentat i interpretat ntr-un singur mod.
Prima form normalizat poate fi aplicat n mai multe situaii:

Pe atribute simple ex: Numele unei persoane are o singur valoare la intersec ia unei
coloane cu o linie

Pe atribute compuse ex: numrul de telefon al unei persoane. Dei apare ca un singur
atribut, acesta stocheaz mai multe informaii: codul rii, codul judeului i alte numere, acestea
putnd fi de interes ca i informaii separate. Aadar, un atribut n prima form normalizat ar
trebui s conin cte o coloan pentru fiecare informaie de interes, aceasta putnd fi accesat
printr-un nume.

Pe un set de atribute De exemplu, un atribut ar putea conine numele copiilor unei

persoane, informaii ce ar putea fi de interes i individual. Ca s normalizm, dac ar fi s crem
cte o coloan pentru fiecare nume al copilului, ne-ar fi greu, deoarece nu am ti de la nceput
care este numrul maxim de copii pe care l poate avea o persoan. De aceea, prin normalizare,
putem creea cte o linie pentru fiecare copil, astfel nct modificrile ulterioare s fie u or de
fcut.


Grup de attribute repetitive Soluia gsit anterior este un exemplu de grup de atribute
repetitive, n care fiecare rnd corespunztor unui copil poate fi manipulate individual. Dac
ordinea n care copiii au fost nscui conteaz, se poate adauga o coloan cu ordinea n care au
fost nscui.
Prima form de normalizare este important deoarece, mpreun cu principiile informa ionale,
arat o unic modalitate de interpretare i manipulare a datelor. mpreun conduc la o structur
simpl care are nevoie de un singur set de operatori.
Prima form de normalizare n Modelul Decizional reprezint punctul de plecare pentru formele
mai nalte de normalizare. Totui, n acest model, forma de normalizare are un alt scop dect cel
pe care l are n modelul relaional. Dei se dorete gsirea unei singure modalit i de
reprezentare i interpretare a logicii de afaceri, diferena vine din variabilele care se iau n calcul
(nregistrri versus logici de business). Dac pe de-o parte, o nregistrare relaional este o
colecie de atribute individuale care mpreun transmit informaia, pe de alt parte, n modelul
decizional, o logic de business este o colecie de expresii logice care mpreun, duc la o
concluzie.
innd seama de cele prezentate mai sus, pentru un set de reguli de business, dac nicio linie nu
poate fi descompus n mai multe, atunci acesta este n prima form normalizat. Dac o logic
de afaceri bidimensional duce la dou concluzii diferite, aceasta ar trebui separate pe dou linii
diferite (toate condiiile se vor pstra pe ambele linii).
Un alt caz n care putem aplica prima form normalizat este situaia n care avem condi ii care
se leag cu sau, caz n care putem face interpretri greite. n cazul n care avem astfel de
condiii, putem crea mai multe linii astfel nct s eliminm sau-ul.

6.
Dependena funcional are rolul de a lega atributele din relaii cu expresiile logice
din Familia de Reguli.
n Modelul Relaional- dependena funcional semnifica c valoarea unui atribut (sau unui set
de atribute) dintr-o relaie determin n mod unic valoarea unui alt atribut din cadrul aceleea i
relaii.
n Modelul Decizional dependena funcional semnific faptul c valoarea unei condi ii (sau
unui set de condiii) determin n mod unic valoarea unei alte celule, i anume, celula
concluzional: valoarea unor condiii determin n mod unic valoarea unei concluzii.
7.

Identificatorii ajut n distingerea unei instane n cadrul unei structuri fundamentale.

n Modelul Relaional un identificator este numit cheie candidat (candidate key) i reprezint
un atribut (sau un set de atribute) care identific n mod unic o instan a unei rela ii. Dac exist
doi identificatori pentru o relaie, ei trebuie s conduc ctre aceeai instan a rela iei. Astfel,

putem spune c o relaie poate avea mai multe chei candidate care identific n mod unic o
instan a relaiei. O astfel de cheie nu poate avea valori nule.
n Modelul Decizional un identificator este numit cheie condiional (condition key) i
identific n mod unic o instan din Familia de Reguli. Cheile condiionale nu trebuie s
identific neaprat aceeai instan. Putem spune astfel c Modelul Decizional permite unei
familii de reguli (Rule Family) s aib mai multe chei condiionate, care pot conduce ctre
concluzii diferite pentru acelai input. O astfel de cheie poate avea valoare nul dac exist un
singur model de reguli (Rule Pattern) ntr-o familie de reguli (Rule Family), concluzia fiind n
acest caz necondiionat.
8.
Conexiuni o conexiune reprezint legtura logic care conecteaz structurile
fundamentale nrudite. n Modelul Relaional o conexiune este numit cheie extern (foreign
key). n cadrul unei relaii, atributele cheii primare reprezint cheia extern, care conecteaz
relaiile nrudite. n Modelul Decizional o conexiune este numit cheie inferen ial / deductiv
(inferenial key). ntr-o familie de reguli (Rule Family), aceast cheie este reprezentat de
coloana concluziei neidentificabil, i explic cum sunt conectate ntre ele structurile logice de
afaceri.
9.
A dou form normal ajut la eliminarea dependenelor funcionale care implic
doar o parte dintr-un identificator.
n Modelul Relaional a doua form normal definit pentru un astfel de model se ocup de o
cheie primar care este irelevant n determinarea valorii unui atribut neidentificat din cadrul
unei relaii, fiecare atribut non-cheie fiind dependent n totalitate de cheia primar. O cheie
primar reprezint un set de atribute care identific n mod unic o instan ntr-o rela ie. Astfel,
toate atributele neidentificate sunt dependente n totalitate de cheia primar.
Aceasta asigur faptul c toate atributele non-cheie sunt dependen e de ntreaga valoare a cheii
primare. Atributele non-cheie care depind doar de o parte a cheii primare sunt mutate ntr-o
relaie separat alturi de acea parte a cheii primare.
n Modelul Decizional a dou form normal se ocup de o cheie condiional (condition key)
care este de asemenea irelevant n determinarea valorii unei concluzii n cadul regulei de familie
(Rule Family). Fiecare concluzie dintr-un model de reguri (Pattern Rule) este total func ional
dependent de cheia condiionat. Astfel, putem spune c toate concluziile sunt dependen e de
cheia condiional.
10.
A treia form normal ajut la eliminarea dependenelor tranzitive ascunse
mpreun cu atributele non-cheie din modelul relaional, i alturi de condiii n cazul modelului
decizional.
n Modelul Relaional a treia form normal semnific eliminarea dependenelor funcionale
alturi de atributele non-cheie (altele fa de atributele alternative). Aceasta asigur faptul c nu

sunt incluse valori ale atributelor non-cheie care sunt dependente de valoarea altor atribute noncheie, caz n care ar fi necesar crearea unei noi relaii.
n Modelul Decizional a treia form normal semnific eliminarea dependen elor func ionale
alturi de condiiile din cadrul modelului de reguli. Modelul de reguli este redus la a treia form
normal prin tergerea condiiilor care duc la alte condiii, mutndu-le ntr-o nou structur n
familia de reguli (Rule Family).

Capitolul 12 Modelul Decizional definit n mod formal

Principii ale Modelului Decizional - Aceste principii pot fi mprite n mai multe categorii
dup cum urmeaz:

a) Principii structurale

Principiu Tabular scop: rigoare aplicat pe forma familii de reguli

enun: Structura fundamental a unui model de decizie se numete
familie de reguli i are dou dimensiuni: una reprezentat de titlu, iar cea de-a doua de
corp

Principiul Titlului scop: rigoare aplicat pe titlul familiei de reguli

enun: Titlul unei familii de reguli este un set
de tipuri de aciuni

Principiul celulei scop: accentul pus pe celula unei familii de reguli

enun: Coninutul fiecrei celule a familiei de reguli este o expresie
logic, atomic, n conformitate cu titlul

Principiul rndului scop: accent pus pe rndul unei familii de reguli

enun: Celulele populate joac rolul unor
condiii ce deduc celulele corespunztoare cu rol de concluzie.

Principiul concluziei scop: accent pus pe concluzia unui tip de aciune al familiei de
reguli
enun: O familie de reguli are doar o concluzie pentru tipul de
aciune

Principiul condiiilor scop: accent pus pe un tip de aciune condiionat a unei familii
de reguli
enun: Toate celulule populate condiionat trebuie s fie
adevrate pentru ca celula concluzionat s fie adevrat. O cheie condiionat a unei

reguli tipar poate fi inexistent dac exist o singura regul tipar ntr-o familie de reguli.
O concluzie a regulei tipar ar trebui sa nu depind de o cheie condiionat parial.

Principiul conexiunii scop: accent pus pe conexiunile dintre familiie de reguli

enun: O familie de reguli este ntr-o relaie inferenial cu alt
regul atunci cnd concluzia unui tip de aciune aferent primei regulei servete ca o
condiie pentru un tip de aciune n cea de-a doua

b) Principii declarative

Principiul titlului declarativ elimin toate constrngerile procedurale din titlul unei
familii de reguli

Principiul Corpului declarativ elimin toate constrngerile procedurale din corpul

unei familii de reguli

Principiul relaiilor declarative infereniale elimin toate constrngerile

procedurale din aceste relaii

c) Principii de integritate

Principiul condiiilor tranzitive ce in de regula modelului elimin redundana

dintre condiii

Principiul familiilor de reguli i al consecvenei regulei modelului elimin

inconsistena dintre aceste reguli

Principiul condiiilor tranzitive ce in de familiile de reguli elimin redundana

dintre reguli

Priincipiul integritii familiale asigur un caracter complet al relaiilor infereniale

dintre familiile de reguli

Principiul alinierii n afaceri ataeaz modelului decizional responsabiliti i

msuri pentru rezultatele tangibile ale afacerii

I.

Formele normale n modelul decizional

Exist trei formele normale ale modelului decizional. Prima form presupune ca
fiecare familie de reguli s nu poate fi descompus n mai mult de un rnd pentru a ajunge la
concluzie. A doua form se refer la cazul n care concluzia este total dependent funcional pe

ntreaga condiie cheie. Ultima form este atunci cnd niciuna din condiiile formei a doua este
dependent funcional de alte condiii.
II. Diagrama modelului decizional
Diagrama modelului decizional este compus din patru forme (sau simboluri) i se
bazeaz pe componente majore ale acestui model. Acestea sunt forma deciziei de afaceri, forma
conector a deciziei de afaceri, forma familiei de reguli i linia rela iilor infereniale. Forma
deciziei de afaceri este un octogon, ce afieaz o etichet cu numele de deciziei de afaceri sub
form de text. Conectorul deciziei de afaceri realizeaz conexiunea ntre forma deciziilor de
afaceri (prezint o sgeat la acest capt) i forma familiei de reguli.
III.

Un tabel al familiei de reguli este o vizualizare detaliat a acesteia, reprezentat de o structur

populat, cu dou dimensiuni, format din coloane i rnduri cu o poziie pentru fiecare coloan.
Titlul unei coloane semnific un tip de aciune i pot fi de la 0 la mai multe coloane de condi ii.
Corpul unei coloane reprezint un operator i este o afirmaie cu privire la tipul aciunii
specificat.
Operatorul este acela care ofer un sens afacerii pentru tipul de aciune, i operandul
este o valoare luat din domeniu pentru fiecare tip de aciune/ o formul de calcul. Interpretarea
unui rnd se realizeaz astfel: valorile de adevr ale afirmaiilor din coloanele de condiii conduc
la valoarea de adevr din coloana concluzie.
O regul a modelului este un set de rnduri din familia de regului, ce au populate tipuri de
aciuni comune, n coloanele condiie. Aceasta este considerat a fi complet atunci cnd toate
valorile condiiei (necesare pentru a ti concluzia) sunt prezente n familia de reguli.

Capitolul 13 Architectura ntreprinderii complexitatea i gestionarea

schimbrilor
Cadrul Zachman este smn a, nucleul original din care s-a dezvoltat disciplina
Arhitectura ntreprinderii. n acest capitol, John Zachman urmrete procesul pe care l-a
desfurat pentru descoperirea principiilor generale ale arhitecturii ntreprinderii.
n prezent, Arhitectura ntreprinderii este un concept extrem de neneles n rndul managerilor.
Cu toate acestea, originile conceptului provin din cartea lui Robert Anthony, Planificarea i
controlul sistemului: un cadru de analiz (Anthony, 1965); Jay Forrester Dinamici industriale
(Forrester, 1961); Tehnici de analiz financiara Eric Helfert (Helfert, 1962); Peter Drucker
Practica managemnetului (Drucker,1954); George Steiner Planificarea general manageriala
(Steiner, 1972); i mai recent, Peter Senge A cincea disciplin (Senge, 1990).

Arhitectura se definete ca fiind o colecie de principii, reguli, standarde, modele i strategii

pentru design, construcia i dezvoltarea proceselor de business, resurse i tehnologia informaiei
din cadrul ntreprinderii. Una dintre cele mai importante realiti ale ntreprinderilor actuale este
c ele se confrunt cu un mediu n continu schimbare, n timp ce previziunile pe termen lung
tind s rmn ntr-o proporie tot mai mare sub semnul incertitudinii. Pentru a se adapta acestei
transformri, ntreprinderile trebuie s se dezvolte i s fie reactive, astfel nct schimbarea i
adaptarea s devin o stare dinamic i nu doar ceva ocazional forat de ctre ntreprindere.
Printre implicaiile acestor observaii se numr complexitatea ntreprinderii, care va continua s
creasc. n epoca industrial, ideea de baz a fost de a obine un produs sau un serviciu bun i
apoi a gsi o mulime de clieni crora s l vinzi. Implicit, clientul trebuie s se ocupe de
complexitatea "integrrii" produselor ntreprinderii sau serviciilor. n schimb, ideea de baz a
epocii informaiei este de a gsi un client stabil i apoi a identifica i a oferi orice produse sau
servicii sunt necesare pentru a pstra acel client. Din punctul de vedere al clientului, aceast lucru
nseamn c produsele ntreprinderii sunt integrate.
n cazul serviciilor, ntreprinderea nsi trebuie s se integreze. n cazul Erei Informa iei,
ntreprinderea este cea care trebuie s se ocupe de complexitatea integrrii. Se cunoate faptul c
fiecare client dorete s vad produsele ntreprinderii personalizate n interesul lui.
Un alt aspect n ce privete schimbarea jocului este reducerea timpului pie ei. Aceasta
nseamn c timpul de cnd ntreprinderea primete o comand pn cnd aceasta poate fi
satisfcut trebuie s fie din ce n ce mai mic. n ceea ce privete complexitatea, n cazul n care
oricare ar fi produsul n cauz, el devine att de complex nct nu i poi aminti totul la un
moment dat, ci trebuie s nvei cum s-l descrii nainte de a-l putea crea. .
Reprezentrile descriptive (arhitectura) se ncadreaz ntr-un sistem de clasificare
bidimensional, i anume:
1) Dimensiunea Interogativ:
DIN CE este produsul fabricat: compoziia materialului, prile care au s fie n inventar pentru
a crea produsul, materialele;
CUM funcioneaz produsul: transformarea materiei prime i a energiei, specificaii funcionale
CINE - CE LUCRU FACE: instruciunile de utilizare
CND SE NTMPL LUCRURI: ciclurile de maini, diagramele de sincronizare
DE CE SE NTMPL: obiectivele de proiectare tehnic
Dimensiunea audienei:
DOMENIUL DE APLICABILITATE: stabilirea limitei, limitele fiecrei abstractizri
PROPRIETARUL: conceptele necesare rezultatului final, cerinele
DESIGN-UL: logica sistematic necesar pentru a realiza concepte, scheme
CONSTRUCTORUL: tehnologia necesar pentru a construi produsului
SUB-CONTRACTORUL: configuraia instrumentelor de producie
OPERATORUL: rezultatul- acest scop nu mai este arhitectura (adic o descriere); este o instan
a produsului, rezultatul final.

Capitolul 14 Oportuniti n Arhitectura de afaceri

Tehnicile Enterprise Architecture conduc la descompunerea unei afaceri, la identificarea
locurilor conduse de logic de business i la determinarea punctelor n care este nevoie de
implementarea unui model decizional. Un model de decizie este considerat elementul cheie n
evoluia tehnologiei informaionale. Oportunitatea adus n acest caz este apariia unui software
destinat crerii i meninerii modelelor de decizie, astfel, un model de decizie creat cu ajutorul
unei interfee user- friendly, este apoi transformat i stocat sub form de cod. Transformarea
include bucle feedback, menite s msoare rezultatele i obiectivele afacerii, ajustnd n acela i
timp logica de afaceri pe baza creia a fost construit modelul respectiv. Acest proces se numete
adaptive control and optimization i aparine practicilor BDP (Business decision management).
O arhitectur este definit ca fiind elementul fundamental n organizarea unui sistem, fiind o
componen a elementelor acestuia i a relaiilor n i dintre componente precum i a principiilor
care guverneaz evoluia i design-ul acestuia. Pentru a nelege mai bine fiecare aspect al unei
afaceri au fost elaborate tehnicile EA.
n cadrul acestor tehnici, un sistem este cel mai bine reprezentat n contextul unui business
operaional. Scopul EA este de a defini o afacere operaional decompunnd-o n elementele
fundamentale, de a determina legtura dintre acestea i de a defini paii pe baza crora
elementele funcioneaz independent.
Modelul decizional n framework-ul Zachman
Framework-ul elaborat de Zachman, rmne unul dintre referinele principale n cadrul
arhitecturii unei afaceri (Enterprise Architecture-EA). Datorit longevitii i utilitii pe care a
dovedit-o, acesta efectueaz o descompunere perfect a unui business din dou perspective:

perspectiva interogrii (cine, ce, unde, cum, cnd i de ce)

perspectiva indivizilor (planificator, proprietar, designer, constructor, subcontractor i

operator).
Beneficiile ncadrrii modelului decizional n EA
naintea conceptului descris de Zachman, sistemele erau concepute astfel nct s satisfac doar
nevoi specifice din cadrul afacerii ignornd scopul principal al acesteia. Conceptul lui Zachman
demonstreaz c o afecere nu este doar suma departamentelor componente, ci c aceasta
funcioneaz ca un sistem integrat care se poate optimiza doar n cazul n care este tratat ca un tot
unitar.
n ultimii 20 de ani, impactul modelului lui Zachman a crescut. Majoritatea afacerilor din
domenii precum tehnologia informaiei au fost mai bine nelese folosind acest framework. Prin

reprezentarea modelului decizional din perspectiva lui Zachman, logica unui business devine
interconectat cu planul de business, procesele i ontologia unei afaceri.
Modelul decizional i alte abordri ale EA
Pe lng modelul lui Zachman, exist i alte metodologii EA practicate, care difer prin aten ia
pe care acestea o acord prii de implementare i prin modul n care descompun afacerea. Un
model EA cuprinztor este alctuit din:

O infrastructur pentru descompunerea companiei n dimensiuni i view-uri.

Un set de specificaii pentru model standarde pentru livrabilele dimensiunilor i viewurilor.

Conceptul elaborrii arhitecturii as-is

Conceptul analizrii arhitecturii as-is i elaborarea unui plan pentru arhitectura to-be
bazat pe prioriti.

Capitolul 15 Architecturi orientate pe servicii

Ce sunt arhitecturile orientate pe servicii?
Arhitecturile orientate pe servicii (SOA) reprezint n mod clar arhitectura urmtorului
deceniu, aa cum arhitecturile Web au predominat n anii 2000. Arhitecturile orientate pe servicii
ofer o cale mai bun, mai modular i mai flexibil de a contrui solu ii entreprise, n special
pentru a susine procesele de afaceri. Dei arhtecturile orientate pe servicii se vor dezvolta
oricum, acestea vor genera valoare adiional senificativ atunci cnd seriviile sunt reutilizate n
mai multe procese de afaceri. Marile companii dezvoltatoare de pachete software au reuit s
aplice acest principiu n suita lor de produse, ns multe altele au euat. Printre multiplele cauze
ale posibilului eec se numr lipsa de organizare n companiile IT i lips nelegerii rela iei
dintre servicii, decizii i procese.
Din punct de vedere arhitectural, SOA este un stil arhitectural ce promoveaz conceptul
de serviciu enterprise aliniat la afacere ca unitate fundamental de proiectare i construire a
proceselor i soluiilor pentru afaceri.
O problem major este faptul c ntreprinderile doresc s foloseasc sistemele existente
i s le includ n procese noi de afaceri, ns de multe ori aceste sisteme IT sunt extrem de
complexe, dezvoltate de-a lungul anilor i folosesc diferite tehnologii i platforme. Serviciile
web au potenialul de a rezolva aceast problem, dar simpla utilizare a acestora sau interfa area
aplicaiilor existente cu servicii Web nu se calific precum SOA.
Arhitecturile orientate pe servicii trebuie s permit ntreprinderii s construiasc colec ia
optim de servicii, adevrata valoarea adus de SOA venind atunci cnd servicii reutilizabile
relaioneaz pentru a crea procese de afacere agile i flexibile.

Pentru ca aceste serviicii s poat relaiona este necesar s mprteasc o serie de caracteristici
precum :

s aib dimensiune, form i funcionalitate similar

s fie conform standardelor ntreprinderii

s comunice la nivel tehnic

s comunice la nivel semantic

s susin scopurile i strategia ntreprinderii

Arhitecturi orientate pe servicii stratificate

BPM ofer o abstractizare facil n construirea sistemelor de afaceri, ns foarte des BPM este
folosit pentru a implementa aplicaii eficient de nivel nalt, dar neflexibile sau agile. Aici intervin
regulile, deciziie i arhitectura SOA. SOA ofer platforma aplicaiei pentru a sus ine deciziile de
afaceri , o punte ntre procesele de afaceri, deciziile i resursele opera ionale. La nivelul
proceselor de afaceri, ofer interfee ce asigur suportul n execuia sarcinilor i deciziilor de
proces. La nivelul resurselor operationale, SOA expune capabilit ile existente prin servicii de
interfaare noi. mpreun, BPM i SOA ofer combinaia perfect de dezvoltare a solu iilor
pentru afaceri.
Caracteristicile serviciilor - Serviciile au caracteristici specifice:

modularitate i glanuralitate n SOA, procesele de afaceri sunt mpr ite n servicii

modulare sau pot fi compuse din servicii modulare, acestea putnd fi amestecte i legate n
funcie de nevoia de a cre noi servicii compuse

encapsulare aceasta ascunde detalii legate de implementarea serviciului intern i

structura datelor de interfeele publice operaionale, precum i de modelul semantic

cuplaj slab cuplarea descrie gradul de dependen dintre un consumator de servicii i

client, serviciile cu cuplaj slab avnd puine dependene puine, bine cunoscute i abordabile

izolarea responsabilitilor serviciile sunt responsabile pentru sarcini discrete sau

administrarea unor resurse specifice

autonomia este caracteristica ce permite serviciilor de a fi implementate, modificate, i

meninute independente una fa de cealalt i fa de soluiile ce le folosesc

reutilizarea mpreun, modularitatea, encapsularea, cuplajul slab, izolarea

responsabilitilor, i autonomia permit serviciilor s fie combinate n procese de afaceri multiple
sau accesate de multipli consumatori de servicii din multiple locaii i n contexte multiple


descoperirea dinamic i obligatorie serviciile pot fi descoperite la momentul
proiectrii, prin utiizarea unui depozit de servicii

lipsa unei stri serviciile de operaii nu au stare, ele netiind ultimul lucru ce le-a fost
cerut s fac, nici care este urmtorul

autodescriere contractul unui serviciu ofer o descriere complet a interfe ei acestuia,

operaiile sale, parametru de input i output, precum i schema serviciului

compunerea serviciile pot fi compuse din alte servicii, i combinate cu alte servicii

guvernarea de politici relaiile dintre consumatorii i furnizorii de servicii sunt

guvernate de politici i SLA-uri.

independena de locaie, limb, protocol serviciile sunt concepute s fie transparente n

ceea ce privete locaia i s fie independente de protocol sau platform

Tipuri i dimensiuni ale serviciilor

n orice sistem sau mediu complex, putem ntlni o gam larg de tipuri de sevicii:

procese de afaceri ale ntreprinderii

servicii de afaceri
servicii domeniu
servicii utilitare
servicii de integrare
servicii externe
servicii fondatoare

Capitolul 16 Specificaii, standarde, practici i Modelul Decizional

Standardele i specificaiile sunt considerate principiile care demonstreaz cum se realizeaz un
lucru. Standardele pot fi oficiale, publicate de un organism interna ional, sau standarde na ionale,
ca de exemplu ISO, IEC sau ANSI. Un alt tip de standarde este standardul de facto, acesta este
promovat de un singur furnizor, dar este practicat pe scal larg fiind acceptat ca norm, de
exemplu SQL.
Pe de alt parte, specificaiile reprezint publicaii fcute de ctre un grup industrial sau
consoriu n scopul adoptrii lor de ctre organismele de standardizare, sau de a deveni standarde
de facto. Un exemplu de consoriu este OMG (Object Management Group).
Modelul Decizional joac un rol important n diferite practici ce acoper domenuil de
management al afacerii. n cadrul acestui capitol vor fi prezentate ase astfel de practici:

Practica 1: Planificarea afacerii

Planificarea afacerii este o activitate desfurat n scopul de a influen a viitorul unei organiza ii
n ndeplinirea obiectivelor prilor interesate, innd cont de resursele i constrngerile sale.
Pentru c planificarea afacerii are drept scop producerea unei foi de parcurs pentru succesul
afacerii, BMM (The Business Motivation Model) ofer un set de concepte care ajut la
atingerea scopurilor prin diferite mijloace. Diagrama arat conceptele majore organizate astfel :

Viziunea ,Obiectivul ce alctuiesc mpreun REZULTATUL FINAL

Misinuea, cursul aciunii ce furnizeaz MIJLOACELE

Evaluarea, ce ia o hotrre cu privirea la rezultatul final pe baza mijloacelor i a

impactului factorilor de influen.
Practica 2: Modelarea proceselor de afaceri
Modelarea proceselor de afaceri reprezint modelarea i reprezentarea grafic a proceselor de
afaceri n scopul mbuntirii procesului, a nelegerii comune i a planificrii
afacerilor.Abordarea include simboluri pentru reprezentarea diferitelor tipuri de activit i i
diverse opiuni pentru secvenierea acestora. Exist numeroase metodologii i notaii pentru
reprezentarea activitilor de business.
Practica 3: Modelarea informaional
Modelele de informaii sunt utilizate pentru o serie de scopuri (sau public), cel mai popular scop
fiind designul bazei de date. Sunt diverse stiluri i preferine pentru a reprezenta substantivele,
expresiile/frazele i conexiunile dintre acestea ntr-un model. Stilurile difer mai ales n trei arii:
audiena vizat, scopul principal care servete acea audien i modul n care fiecare stil
reprezint factele, spre ndeplinirea scopului. Cele mai comune tipuri de modele informa ionale:
modelul de fapte. modelul de date, modelul obiectului de business.
Practica 4: Logica de afaceri i modelarea afacerilor prin reguli
Practicarea logicii n afaceri i modelarea afacerilor prin reguli de activitate trebuie s se uneasc
sub aceeai entitate. Pentru asta, au nevoie de un mecanism comun pentru crearea unei structuri
normalizate a comenzilor i regulilor de business. Este nevoie, de asemenea, de un mecanism
comun pentru articularea instanelor acelor structuri normalizate ntr-un manier acceptabil n
mas.
Practica 5: Sistemele informatice. Abordri de dezvoltare
Complexitatea dezvoltrii sistemelor informatice nu a primit nc o vizibilitate i importan
adecvat pentru logica de business ce st la baz lor. Cele mai multe metodologii conven ionale
se refer la "reguli de business", dar acestea sunt fie dezvoltate timpuriu cnd se colecteaz
cerinele (deci este nevoie de o lung perioad de timp) sau sunt dezvoltate ulterior, deoarece

acestea sunt percepute ca fiind detalii ale designului. n ambele cazuri, acestea sunt de obicei
create dintr-o interaciune ntre dezvoltatorul de software i un om de afaceri.
Practica 6: Modelul de decizie i metode de transformare a sistemelor
Transformarea sistemului este procesul de reinventare a unui sistem de afaceri. Uneori, nevoia de
transformare a sistemului provine dintr-un efort de reinventare a afacerii care recomand o
schimbare semnificativ n capacitile de sistem. Uneori, aceasta este doar mi carea unui sistem
existent de la o platform de tehnologie nvechit la o alta mai modern. Oricare ar fi motivul,
transformarea sistemului este o aciune complex care necesit mai mult efort dect a fost
necesar pentru crearea sistemului. Asta pentru c implic nelegerea sistemului original nainte
de a se reinventa n ceva mai bun.

Capitolul 17 Integrarea modelului de decizie prin BPMN

BPMN (Business Process Modelling Notation) reprezint un limbaj standard utilizat n
modelarea proceselor de afaceri curente i descrie toate etapele unui proces prin intermediul unei
secvene de sarcini. BPMN nu definete logica de afacere din cadrul fiecrei sarcini i nici alte
detalii referitoare la implementarea sarcinii, ci subliniaz modul n care sarcinile sau
evenimentele relaioneaz n timp unele cu celelalte.
Managementul proceselor de afaceri (BPM) reprezint o perspectiv de descriere i gestionare a
afacerii, nu n termeni de funcii individuale sau sisteme IT, ci n termeni de etape ale proceselor
end-to-end care trec de acele limite funcionale, organizaionale i de sistem. BPM const ntro secven de activiti ce pornesc dintr-un punct bine stabilit i se ndreapt ctre unul sau mai
multe puncte de finalizare ale procesului respectiv. Fiecare activitate reprezint o etap din
proces, o parte de munc efectuat.
n BPMN, toate notaiile au o anumit semnifica ie i con in reguli referitoare la posibilitatea
conectrii cu alte procese. Rolul BPMN este de a descrie procesul de comunicare cu
evenimentele externe (clieni, furnizori, etc.) precum i modul de manifestare al procesului n
cazul apariiei unor evenimente (anulare comand, depirea unui temen, etc.).
BPMN definete 2 tipuri de activiti de proces: sarcin-care nu deine alte subactivit i i
subprocesul care poate fi mai departe descris prin expansiunea unui proces format din alte sarcini
i activiti. Notaiile folosite sunt difereniate prin butoane cu anumite forme n interiorul lor:
utilizator-semnifica o sarcin uman sau serviciu-semnifica o sarcin automat. Toate acestea
creeaz o diagrama de proces clar i permite o implementare corespunztoare a fiecrui tip de
sarcin. Poarta de decizie este n form de romb i definete o separare n proces bazat pe datele
existene. Fiecare cale din poarta de decizie are o condiie asociat sau o regul iar decizia
trebuie luat ntr-o sarcin anterioar porii de decizie.

Omisiunea unei astfel de sarcini de decizie este o greeal destul de frecvent. De exemplu, n
figur de mai jos este primit o comand i se trece imediat la etapa de decizie: dac este valid
procesul trece ctre aciunea A, iar n caz contrar ctre aciunea B. Astfel, nu este efectuat
niciun fel de munc, pentru c poarta nu poate lu o decizie, poarta fiind o logic de rutare puractiveaz drumuri n diagram bazate pe o expresie a datelor din proces.

.
Figur 23: Folosirea incorect a porii de decizie

Corect este ca n momentul primirii unei comenzi s fie testat validitatea acesteia (sarcin de
decizie). Astfel, dac aceast comand este valid, procesul merge mai departe ctre sarcina A,
iar n caz contrar ctre sarcina B.
n figura de mai jos, sarcina Valideaz Comanda invoc o decizie definit n modelul de
decizie. Multe alte procese, precum alte tipuri de comenzi, pot conta pe acelai model decizional.
Figurapermite logicii modelului decizional s modifice fr s afecteze procesul pe care l-a
provocat. Astfel, modelul poate folosi un set de reguli mult mai complex dect o simpl poart de
decizie.

Figur 24: Folosirea corect a porii de decizie

Capitolul 18 Modelul fizic de decizie

Catalogarea activelor de decizie
Pentru a trece de la modelul logic de decizie la cel fizic este nevoie s fie respecta i c iva pa i.
Inventarierea activelor i crearea unui glosar cu numele i descrierea fiecruia este un pas
important. Acesta este util pentru a extrage valoarea de business i pentru a identifica sursele de
date n scopul crerii unor convenii de nume (acestea se vor respecta n ntreg modelul).
Modelul fizic este o reprezentare a modului de procesare al deciziilor.
MDM i modelele de decizie
Metodologia pentru dezvoltarea modelelor logice de decizie a fost rafinat de-a lungul timpului.
Pentru includerea atributelor din modelul logic n modelul fizic este nevoie de anumite structuri
i notaii suplimentare. Dezvoltarea modelului fizic de decizie poate fi fcut dup, n timpul sau
naintea constituirii clasificrii Master Data Management.
Metadate decizionale
Acestea nu sunt date despre date, ci date despre decizii. Acestea descriu dependenele logice ale
deciziilor i resursele necesare deciziilor. Asemntor inventarierii MDM, metadatele decizionale
pot fi identificate din sursele existente de date sau pot fi definite abstract n timpul crerii
modelului logic.
Legarea modelelor decizionale
Modelele fizice de decizie integreaz proprieti i valoare suplimentar fa de cele logice.
Acestea nglobeaz regulile ntr-un context unic. Ele includ de asemenea i aspecte referitoare la
deployment-uri care pot afecta procesul bazat pe decizii (performan, actualizare, securitate).
Modele Fizice de Decizie pot fi constituite din dou direcii:
-Fie pornind de la strategie i cerine
-Fie pornind de la sistemele deja existene.
Modelele de Decizie, fie logice sau fizice, se potrivesc foarte bine cu eforturile existen e ale
companiilor de a deine controlul datelor sale.

Capitolul 19 Gestionarea deciziilor ntr-o ntreprindere

EDM (Enterprise Decision Management) este o abordare pentru automatizarea i mbuntirea
deciziilor operaionale de volum mare. Definiia elementar se bazeaz pe cinci elemente
cruciale. Se concentreaz pe decizii operaionale, dezvolt servicii de decizii folosind reguli ale

afacerilor pentru a automatiza acele decizii, adaug puncte de vedere analitice acelor servicii
folosind analitic predictiv i permite mbuntiri continue ale lurii de decizie prin control
adaptabil i optimizare. Cele cinci elemente definitorii ale defini iei despre care se vorbe te n
acest capitol sunt: Decizii operaionale, Servicii de decizii, Reguli ale afacerilor, Analiz
predictiv i Control adaptabil i Optimizare.
Servicii de decizii - Arhitectur Orientat spre Servicii (SOA- Service-Orientated
Architecture) este cea mai eficient abordare spre generarea EDM-ului. Un serviciu de decizii
poate fi definit ca o component de sine stttoare cu o viziune a tuturor condi iilor i ac iunilor
care trebuie luate n considerare pentru a lua o decizie operaional ntr-o afacere. Aceste servicii
folosesc datele i perspectivele derivate din acestea pentru a lua decizii n mod automat. Totodat
ele izoleaz logica din spatele deciziilor operaionale, separnd-o pe aceasta de procesele afacerii
i de operaiunile mecanice ale codului aplicaiilor procedurale.
Reguli ale afacerilor- folosirea lor este datorat necesitii gestionrii logicii n serviciile
de decizii. Pentru ca acestea s fie uor de gestionat:
-trebuie s fim capabili s le formulm ntr-o asemenea manier nct s fie independente de
altele dar i distincte
-trebuie s fim capabili s administrm un numr foarte mare de reguli; gestionarea acestor
numere mari nseamn s fim api s le diversificm, s controlm accesul la ele i s urmrim
schimbrile astfel nct s tim cum am ajuns la regulile pe care le avem
-ele trebuie s fie reprezentate astfel nct att utilizatorii afacerii ct i cei tehnici s poate
interaciona cu aceste reprezentri; ambele grupuri trebuie s fie capabile s citeasc, s editeze,
creeze i s tearg regulile astfel nct afacerea i echip de IT s poat colabora la
administrarea acestor reguli ntr-un mod eficient
-pentru desfurarea acestor reguli, departamentul de IT necesit tehnologie pentru a le converti
n codurile executabile care ruleaz n arhitectur aplicaiei noastre
Modele predictiv analitice- sunt proiectate pentru a face preziceri despre un anume
client, produs sau tranzacie precum i despre posibilitatea tranzaciei de a fi frauduloas, despre
un client ce poate sau nu accept o propunere sau despre o livrare ce poate ajunge trziu.
Reprezentate ca modele matematice / ecuaii, ele sunt combinate cu regulile afacerii pentru
luarea unei decizii.
Controlul adaptabil i Optimizarea- cel mai de baz element al controlului adaptabil este
abordarea de tip competitor/campion, care implic dezvoltarea unui competitor al unei decizii de
tip campion. Un procent mic de tranzacii sunt procesate prin intermediul programului de tip
competitor. Dac aceast abordare d rezultate mai bune, o putem promova la stadiul de nou
campion. Se pot dezvolta noi competitori i astfel s provocm i s testm la nesfr it varianta

campion. Astfel, ni se permite s mbuntim constant deciziile cu risc minim. Scopul acestor
particulariti cutate este de a menine un rspuns optim n circumstane schimbtoare.
Deciziile operaionale - pot fi luate prin intermediul EDM-ului sau prin Modelul de
Decizie. Caracteristici ale unei decizii care cntresc spre alegerea unei abordri de tip EDM:
volumul, latena, variabilitatea, conformitatea, once and done, riscul managerial,
nesupraveghere, personalizarea i auto-soluionarea.
Folosirea Modelului Decizional alturi de EDM - dei folosirea unui model de decizie
poate fi foarte eficient n contextul de EDM, un este un substitut pentru acesta, la fel cum nici
EDM-ul nu este un substitut pentru folosirea modelelor de decizii.
Procesul - nainte de a detalia cum Modelul de decizii i EDM-ul pot fi folosite
mpreun dintr-o perspectiv a procesului, trebuie s lum n considerare procesul de baz al
unui EDM.: ndeprtarea deciziilor din aplicaii, analiz deciziilor pasibile de mbuntire,
automatizarea celor mai importante decizii operaionale, aplicarea analizei predictive i de
decizii, acordarea controlului utilizatorilor businessului, pstrarea simplitii pe msur ce
inteligena crete, concentrarea pe cerinele de performan a produciei i dirijarea schimbrii
i evoluia.
Gsirea deciziei corecte pentru EDM - Una din cele mai mari provocri n folosirea
EDM este aceea de a identifica deciziile dintr-o aplicaie, a le detalia i a le gestiona. O alt
utilizare a modelului decizional n cadrul EDM este estimarea potenialului ROI care crete odat
cu mbuntirea i automatizarea modelului decizional. Potenialul ROI crete direct
proporional cu creterea numrului de reguli dintr-un model decizional i cu schimbarea ct mai
deas a regulilor.
Modelul decizional ca tehnic de analiz - Modelul decizional este foarte bun pentru a
identifica dac ntr-un EDM au fost definite regulile corecte, datorit tehnicilor sale de verificare
a coerenei i integralitii. De asemenea, regulile definite cu ajutorul modelului decizional pot fi
foarte uor transformate n reguli de business, ca parte a proiectului de dezvoltare EDM.
Controlul utilizatorului asupra modelului decizional - Una dintre cerinele principale ale
EDM este aceea c logica i regulile de business trebuie expuse utilizatorilor de business a a
nct acetia s le poat nelege, s le gestioneze i s le poat evolua, cerin pe care modelul
decizional o ndeplinete cu succes.
Modelul decizional i controlul adaptiv - Aceast este o alt cerin crucial a EDM-ului
i anume mbuntirea continu a procesului decizional prin provocarea constant a abordrii
iniiale. Controlul adaptiv ajut la gestionarea ct mai bun a deciziilor care se afl ntr-o
continu schimbare deoarece definiia de cel mai bun sau corect se schimb constant.

Capitolul 20 Introducere n modelul decizional matur

Este uor ca un proces complex s furnizeze deliverabile de o calitate inferioar. Acest lucru se
ntmpl adesea cnd procesul nu este bine definit, bine comunicat, bine n eles, sau nu este
evaluat corespunztor din punct de vedere al calitii. Un model de maturitate furnizeaz
ndrumri pentru aceste tipuri de procese.
Ce este un model de maturitate? Un model de maturitate este un model de mbunt ire a
procesului utilizat de organizaii pentru a identifica cea mai bun practic, pentru a mbunt i
execuia procesului i pentru msurarea acestor mbuntiri. Cnd procesul este mbuntit ntrun anumit mod predefinit, acesta devine mai matur.
Deja exist un model de maturitate care abordeaz managementul regulilor n afaceri, care s-a
dovedit folositor n practic. Acesta se numete Rule Maturity Model (RMM). Scopul RMM este
de a oferi o foaie de parcurs pentru a avansa procesul de management al regulilor n afaceri de la
stadiul de slab gestionat la stadiul de proces bine gestionat. RMM are ase niveluri de maturitate
asemenea altor modele de maturitate. Acestea sunt numerotate de la 0 la 5.
Nivelul 0: Neadministrat
Nivelul 1: Vizibil
Nivelul 2: Agil
Nivelul 3: Aliniat
Nivelul 4: Predictiv
Nivelul 5: Autonom

Capitolul 21 Modelul Decizional, alturi de instrumentele i serviciile

Enterprise 2.0
Modelul de decizie a fost acceptat de organizaii ca aducnd plus de valoare, ns nc nu se
contientizeaz pe deplin beneficiile pe care un astfel de model le aduce, dou motive stnd n
spatele acestui fapt: lipsa competenelor necesare pentru a reprezenta cerin ele ntr-un format
care s faciliteze analiza att de ctre departamentele de business, ct i de cele IT, precum i
structura organizaional care mpiedic realizarea unei comunicri i cooperri eficiente.
n scopul obinerii unei colaborri ntre zona de business i IT s-a dovedit utilitatea utilizrii unor
platforme precum BRMS (Business Rule Management Systems) i BPMS (Business Process
Management Systems), nefiind suficient ncercarea ntreprinderilor de a redefinii metodologiile
de lucru i businessul.

Aspecte care ntresc necesitatea unor astfel de platforme precum cele men ionate sunt
strns legate de dezvoltarea Web 2.0 i a Enterprise 2.0, care presupun o mai bun organizare a
colaborrii, descentralizare i distribuie a resurselor. n acest sens, modelul de decizie ar fi putea
fi cheia pentru a depii carenele actuale.
Discrepana din perspectiva de afaceri
n ce privete discrepana n afaceri, un aspect problematic este abordarea centrat pe
afacere i omiterea aspectelor ce in de IT, din cauza dificultii de a modela procesele complexe,
ntlnirile pentru a dezbate i analiza realizndu-se pe concepte simple, la nesfrit, prin reluarea
acestora pe alte subiecte.
n urma modelrii, realizrii analizei i a documentrii, pasul urmtor este de a potrivi
regulile cu cerinele de business, alturi de cei de la IT, ceea ce poate fi dificil dac caietul de
sarcini de business nu se aseamn cu caietul de sarcini IT, colaborarea fiind vizibil afectat.
Conform CIO Magazine, analitii raporteaz c 71% dintre proiectele ce implic utilizarea de
aplicaii software au fost un eec n primul rnd din cauza unui management slab al cerinelor.

Discrepana din perspectiva IT

Din perspectiva IT, omiterea aspectelor ce in de business, n graba de a integra Business
Rule Engine (BRE) i a porni executarea regulilor ct mai repede posibil, conceptele de business,
n ce privete limbajul i procesele, nefiind nelese n totalitate, este o problem frecvent,
denumit Blestemul soluiilor unui singur proiect. Acest lucru se traduce prin realizarea unui
focus pe un singur proiect, fr a ncerca s se organizeze anumite standarde, o anumit
procedur de lucru, o consisten a colaborrii la nivel de ntreprindere, ceea ce duce la solu ii
multiple care nu se aseamn ntre ele. De aici, n cel mai ru scenariu, pot s apar reguli
redundante sau duplicate pe diferite platforme de-a lungul ntregii companii.
Pentru companiile mici i mijlocii, costul investiiei n achiziionarea, implementrii i
ntreinerea unor platforme de tipul BRMS sau BPMS poate fi o barier. Acest cost ns poate s
nu fie cel mai dificil obstacol de trecut, ulterior obinerii platformei fiind necesar analiza i
documentarea regulilor, iar complexitatea i importana realizrii acestora ar putea implica
costuri ridicate cu propunerea unor experi externi care s asigure suport i mentorat pentru
ntregul proces.

Discrepana din perspectiva Organizaional

Dup cum am amintit anterior, singura form de comunicare ntre aria de business i IT
care permite reducerea discrepanei sunt cerinele, care sunt rareori ntr-un format ce poarte fi
neles de ambele pri.

Din acest motiv a devenit necesar s existe aceti, aa-zii, purple people care se refer
la acele persoane ce au cunotine suficiente pentru a exprima regulile ntr-un format logic pentru
o persoan de IT i care dein cunotine solide n domeniul de business.
n plus, foarte multe organizaii se restructureaz permanent n ncercarea de a se regsi.
Se creeaz astfel partiii cu granie artificiale care pot deveni permanente ceea ce duce la cteva
probleme referitoare la cum i de ctre cine sunt tratate schimbrile ntre silozuri, relevan a
informaiilor pentru experi i n afara sistemului i consistena informaiilor transmise.

Ce poate realiza Modelul de Decizie pentru noi

Avnd un cadru bine definit i, implicit, o abordare structurat a managementului
deciziilor de business, se pot evalua i nelege mai bine aspectele ce in de procesele de
business, deciziile necesare pentru susinerea acestora, regulile din spate i cerinele de
management ale regulilor. Modelul de decizie ne prezint i un mod de colaborare, servind ca un
model eficient de generare de cerine. Cu toate acestea vor fi necesare cursuri, suport i servicii
care s asigure planificarea i implementarea acestei iniiative.
mpreun cu Enterprise 2.0, modelul de decizie poate s preia i s men in informa ia
sub un format care s permit accesul i muli ani mai trziu, ducnd la creterea unei companii
de tip mic i mijlocie (SME). n plus, o abordare de tip business/decision on demand, folosind o
arhitectur de tip SOA (Service Oriented Architecture) ar permite automat i accesul clien ilor la
acest serviciu atunci cnd au nevoie, crescnd astfel agilitatea micilor companii care nu ar
necesita investiii mari pentru software i servicii.

Capitolul 22 Modelul Decizional din perspectiva managementului

Modelul Decizional i tehnicile sale sunt cu un pas nainte pentru afaceri i regulile de afaceri.
Regulile de afaceri, dac sunt formulate corect, pot mbunti calitatea solu iilor automatizate i
reduc costurile. Una din problemele frecvente ce duceau la necesitatea de a corecta erori este
creat de comunicarea slab, cerine neadecvate i reguli de business vagi.
Ce aduce modelul decizional pentru business?

Vizualizare a logicii de business i a regulilor de business: mbuntete abilitatea de a

identifica reguli lips sau eronate.

Eficien mbuntit a abordrii unei reguli de business: modelul de decizie este doar o
unealt din set i totui aduce claritate i predictabilitate oricrui rezultat al unei ini iative de
regul de business. Acest singur livrabil poate asigura c business-ul i programatorii vor ajunge
la aceeai concluzie identic.

O nelegere comun n cadrul ntreprinderii: intenia este de a exprim regulile ntr-o

form n care este neles de ctre toi angajaii.


Evaluare uoar asupra impactului schimbrii n management. Schimbarea unei reguli
aduce automat un impact asupra mai multor modele, iar acest impact este mai uor de neles.

Un set ntreg de Familii de reguli pentru o decizie de business data i rela iile dintre ele:
o reprezentare grafic a structurii i a informaiei necesare n luarea unei anumite decizii ce este
foarte util managementului cnd nu vor s vad regulile detaliate, ci mai degrab o privire de
ansamblu.

O structur uor de neles din care pot fi construite cazuri de teste logice: fiecare rnd
dintr-un tabel decizional reprezint un set de condiii i o singur concluzie, toate rndurile au
aceeai concluzie.

Rezultate de testare mbuntite: modelul va reduce efortul de testare, va mbunt i

rezultatele i reduce costul de testare.

Capitolul 23 Mai bine! Mai ieftin! Mai rapid!

Cele mai multe proiecte de dezvoltare a sistemelor care nu utilizeaz Modele decizionale sunt
predispuse unui set de probleme, n pofida calitii livrabilelor i a experienei staffului de
dezvoltare. nvarea despre Modelele decizionale n fazele timpurii ale proiectului poate
mbuntii n mod significant rata de success a proiectelor de dezvoltare a sistemelor.
n ultimul capitol este descris modul n care s-au aplicat principiile Modelului decizional n
faze trzii ale proiectului, cu beneficii importante.
Cele mai importante idei din acest capitol sunt urmtoarele:
S-a lucrat vreme de 3 ani la un proiect strategic, global n cadrul cruia s-au completat cerin e
cuprinztoare i optat pentru o firm care ofer servicii BPM de calitate.
Au fost angajai cei mai experimentai consultani pe care i-a avut firma respectiv, ns dup
doi ani de dezvoltare i testare, produsul nu a fost finalizat i au fost ntmpinate
dificulti/provocri importante.
A fost desfurat o activitate de cercetare pentru a descoperi rspunsurile la problemele
ntmpinate. Modelul decizional a constituit cheia pentru a adresa multe dintre problemele cu
care se confrunt proiectul.
Decizia de a utiliza tehnologia BPM a fost cu siguran cea mai bun alegere pentru acest
proiect, dei echip de dezvoltare n continuare nu reuea s in pasul cu shimbarile, adugrile
i regulile de complexitate.
A fost realizat un editor de reguli de business care oferea staffului de business abilitatea de a
actualiza deciziile de business i regulile de business fr a fi necesar c aplicaia s treac printrun ciclu de dezvoltare. Aceast experien a demonstrat valoarea Modelului de decizie cu toate
c acesta nu a fost proiectat n vederea testrii acestui model.

 Ceea ce lipsea era un Model decizional care s acopere i restul sistemului. Descoperirea
Modelului de decizie ca modalitate de exprimare a unor reguli de business ntr-o manier
independent de platform constituia componenta lips.
n momentul n care s-a actualizat o poriune mare de program cu func ionalit i noi, s-a
realizat i o separare a regulilor de business n Modele decizionale, ajungndu-se la o reducere
de 10- 25% a timpului de dezvoltare, concomitent cu mbuntirea calitii. Prin utilizarea
Modelelor decizionale de la bun nceput s-ar fi putut reduce necesitile i timpul de dezvoltare
cu pn la 50%.