Ciclul de viață

al analizei și
proiectării
sistemelor
economice
Conf. univ. dr. Ramona Păun
ramona.paun@csie.ase.ro
 Cuprins
Introducere
1. O metoda de rezolvare a problemei

2. Modelul procesului de analiză a afacerii

2.1. Investigarea situatiei problemă

2.2. Considerarea perspectivelor

2.3. Analiza nevoilor

2.4. Evaluarea opțiunilor

2.5. Definirea cerințelor

2.6. Livrarea schimbărilor

1. O metoda de rezolvare a problemelor

v Analistul de sistem examinează sistemul şi alege o metodă raţională sau creativă pentru a dezvolta ideile și
propunerile privind soluția cea mai potrivită, care va fi adoptată în final. Rezolvarea creativă a problemei de analiză
este vitală deoarece, din ce în ce mai mult, organizațiile, indiferent de natura lor, au nevoie de idei inovatoare
pentru a putea răspunde cât mai bine la schimbările din mediul de afaceri, incluzând acţiuni ale competitorilor pe
piețele interne și externe, schimbări de legislație, acțiuni ale factorilor politici și sociali etc.

v În figura 1 se prezintă un cadru util pentru înţelegerea problemelor şi dezvoltarea de soluţii creative, mai ales
atunci când se utilizează un model pentru investigare şi analiză (spre deosebire de cazul în care sunt oferite soluţii
rapide, posibil premature).

v Modelul general prezentat, denumit și ciclul

de viață al analizei sistemelor, propune o
metodă care poate fi aplicată cu succes în
orice proiect de analiză de sistem.
Figura 1 Modelul general al procesului de analiză de sistem
1. O metoda de rezolvare a problemelor

v Primele trei etape ale ciclului de viață sunt orientate către înțelegerea problemei și includ:

1. Identificarea erorilor (mess finding), etapa cu care se începe deseori o investigare a problemei, presupune
găsirea acelor elemente care determină complexitatea situaţiei problemă. Problemele complexe, care pot să
conţină diferite viziuni şi opinii, se rezolvă prin explorare, descoperire (mod de rezolvare creativ). Multe
probleme sunt slab definite, cerințele sunt vag formulate, au mai mult un caracter ipotetic, probabilist, după
formula “ce ar fi dacă”, mijloacele, formulele de lucru nu ne conduc automat la rezultat, trebuie sa exploram, sa
inventariem mai multe căi și mijloace, iar soluția se relevă ca o descoperire. Este necesară o înţelegere a situaţiei
de ansamblu înainte de a trece la formularea de opţiuni şi soluţii.

2. Identificarea datelor este dedicată analizei opiniilor, părerilor, cunoaşterii şi ideilor nedescoperite în prima
etapă, pentru a identifica modul în care aceste informaţii pot fi cuantificate şi susţinute de datele obţinute. Este
adeseori util să se examineze imaginea de ansamblu cu ajutorul unei hărți a minţii (mind map) pentru a
clarifica ce gândesc oamenii despre respectiva situaţie. Este de o importanţă deosebită să se stabilească ce
informaţie este factuală şi care este bazată pe păreri și opinii (subiective).
1. O metoda de rezolvare a problemelor

v Primele trei etape ale ciclului de viață sunt orientate către înțelegerea problemei și ele introduc un cadru pentru a
realiza acest lucru (cont.):

3. Identificarea problemei- utilizează primii doi paşi pentru precizarea problemei care trebuie soluționată. Acum
cunoaștem complexitatea situației cu care ne confruntăm și suntem capabili să cuantificăm unele elemente, în
timp ce despre alte elemente avem culese opinii sau viziuni personale.

Trecem în revistă informațiile deținute deja pentru a înțelege cu ce problemă ne confruntăm și formulăm
problema. În general problema este compusă din simptome ce trebuie înţelese din ce în ce mai bine pentru a
găsi cauza reală a apariției acesteia.
1. O metoda de rezolvare a problemelor

v Următoarele două etape se concentrează pe dezvoltarea de soluții:

4. Identificarea ideii: analiștii încearcă să genereze mai multe idei utilizând de obicei metode de tip brainstorming
dar și alte metode care duc la stimularea apariției de idei noi, inclusiv tehnici de gândire creativă.

5. Identificarea soluției. Odată ce ideile au fost identificate, ele sunt evaluate pentru a le selecta pe cele care pot
constitui soluții ale problemei și dintre acestea, pe cea mai potrivită. De notat faptul că etapa de identificare a
soluției apare târziu în model. De obicei se așteaptă ca analistul de sistem să ofere soluții rapid dar este
important ca el să reziste la presiunea de a face acest lucru în etapele timpurii ale modelului deoarece există
multe aspecte care trebuie luate în considerare înainte de a prezenta o soluție.

v Etapa finală a modelului:

6. Acceptarea soluției găsite, care include implementarea soluției, un aspect critic pentru succesul oricărei
schimbări propuse prin proiectul de analiză de sistem, dar care adeseori este realizată cu multă dificultate.
2. Modelul de proces al analizei de sistem

v Sistemele economice existente pot fi extrem de variate şi, în cadrul unui proiect anume, analistul de sistem
poate să aplice mai multe tehnici pentru rezolvarea problemelor şi să analizeze mai multe viziuni diferite.

v Dificultatea dezvoltării unui model de proces este dată de necesitatea oferirii unui cadru suficient de flexibil care
să ajute analiştii de sistem să-şi desfășoare activitatea.

v Modelul de proces (Figura 2) stabileşte etapele cheie ale proiectului de analiză, în cazul în care sistemul abordat
este o afacere, fiecare etapă trebuind luat în considerare în mod individual și necesitând tehnici și metode
distincte.

Figura 2 Modelul procesului analizei de afaceri

2.1. Investigarea situației problemă
Ø Se identifică problemele şi elementele principale ale situației. Termenii de referinţă pentru proiect, sau posibil
un document de inițiere a proiectului (project charter) sunt necesare pentru a stabili contextul în care
activitatea de analiză va avea loc. Analistul trebuie să clarifice obiectivul studiului.

Ø În decursul perioadei iniţiale, analistul poate prezenta o formulare a “problemei”; este important să investigheze
mai multe astfel de probleme posibile pentru a determina exact care este totuși problema adevărată şi nu să
confunde simptomele problemei cu condiţiile reale ale afacerii. Este, de asemenea, vital ca analistul să nu emită
ipoteze false sau să accepte toate informațiile furnizate de beneficiar fără întrebări suplimentare.

Ø Analiza sistemului necesită, de asemenea, o apreciere a contextului afacerii, în particular ale strategiei şi
obiectivelor generale ale afacerii pentru organizaţie sau unitatea de afaceri. Este important ca acestea să fie deja
stabilite în cursul etapei de investigare astfel încât analiștii să înțeleagă contextul afacerii pentru activitatea pe
care o vor întreprinde. Odată ce analistul a început să înțeleagă situaţia, o anumită formă de descriere va fi
conturată; mai întâi, acesta va fi o înregistrare a rezultatelor investigaţiei ca atare, şi apoi ea îi va face pe ceilalţi
membri ai echipei să înțeleagă situația problemă.
2.1. Investigarea situației problemă
Ø Tehnici de investigare: Există multe tehnici şi metode de investigare pe care analistul de afaceri le poate utiliza ce
depind de nivelul de detaliere cerut în cursul acestei etape, care poate varia considerabil.
o Dacă analistul încearcă să obţină o apreciere generală asupra domeniului afacerii, ex. să identifice stakeholderii
cheie şi să înţeleagă viziunile şi opiniiile acestora asupra naturii activităţii pe care o întreprinde, atunci tehnicile
utilizate sunt cele care permit obţinerea unei perspective generale: interviul, observaţia şi workshopul.
o Dacă activitatea este orientată către elicitarea mai multor informaţii detaliate, cum ar fi necesarul de date sau
fluxul procesului de afaceri, atunci cele mai potrivite tehnici sunt analiza scenariului sau prototiparea. Multe
informaţii obţinute aici pot fi subiective şi pot necesita o analiză mai detaliată și în acest caz, tehnici cum ar fi
chestionarul sau înregistrarea convorbirilor pot fi utile pentru a cuantifica unele informaţii deja existente.
Ø Documentarea situației de afaceri: Există un număr de tehnici utile pentru documentarea investigației inițiale a
unui sistem de afaceri. De regulă, o viziune generală asupra situației va fi necesară în cursul investigației inițiale, mai
ales dacă elementele sunt complexe şi influențate de cauze diferite. O imagine bogată poate fi utilizată pentru a
surprinde esenţa unei situații şi o metodă alternativă, dar similară cu aceasta, este harta minții, care oferă și un grad
de structurare a informației.
2.1. Investigarea situației problemă
Ø Rezumatul etapei de investigare a situației
o Procedura:
i. Studiul materialului de bază: documentul de iniţiere a proiectului, termenii de referinţă.
i. Efectuarea investigaţiei iniţiale asupra stakeholderilor cheie.
ii. Documentarea rezultatelor investigaţiei utilizând rapoartele de întâlniri (minutele) plus diagrame.
o Inputuri:
• Termenii de referință sau documentul de iniţiere al proiectului
• Obiectivele și strategia de afaceri
o Outputuri:
• O descriere a situației existente a afacerii, incluzând rapoarte de întâlniri și diagrame, cum ar fi imagini
bogate, hărţi ale minții și diagrame Fishbone (Os de pește).
• Lista elementelor/problemelor
• Lista preliminară a nevoilor afacerii
o Tehnici și metode utilizate:
• Tehnici de investigare calitative cum sunt: interviul, observarea şi workshopurile
• Tehnici de investigare cantitative cum ar fi: chestionarele, eşantionul şi analiza documentelor
• Imagini bogate, Hărți ale minții, Hărți spaghetti, Diagrame Fishbone (Ishikawa sau Os de pește)
2.2. Considerarea perspectivelor
Ø Etapa constă în analiza stakeholderilor şi a perspectivelor acestora asupra situaţiei. Mulţi stakeholderi au viziuni
foarte clare asupra problemelor pe care le are sistemul de afaceri. Acolo unde apar diferenţe între viziunile
stakeholderilor este important ca ele să fie explorate şi, dacă este posibil, să se ţină cont de recomandările făcute de
aceştia în etapele următoare.

Ø Identificarea şi analiza stakeholderilor

o Fiecare situație problemă va afecta un număr de indivizi şi organizaţii cu interese şi putere diferite. Unii
stakeholderi vor fi direct afectaţi şi pot avea păreri foarte clare asupra modului în care sistemul trebuie să se
schimbe. Alţii pot fi afectaţi indirect şi, chiar dacă au opinii, pot fi mai puţin preocupaţi de natura noului sistem.

Ø Perspectivele stakeholderilor
o Stakeholderii au adeseori viziuni diferite asupra ceea ce este mai important în sistemul analizat şi asupra
îmbunătăţirilor care sunt necesare. Aceste viziuni sunt adeseori contradictorii şi pot conduce la agende ascunse,
conflicte şi priorităţi greşite. Este important ca analistul de sistem să fie conştient de potenţialul de conflict şi să fie
alertat de astfel de situaţii şi unde pot ele să apară.
2.2. Considerarea perspectivelor
Ø Modelarea activității de afaceri
o Perspectivele stakeholderilor pot fi analizate în continuare considerând activităţile care sunt necesare pentru a
realiza o perspectivă particulară. Această metodă, dezvoltată de Checkland (1981), permite analiștilor să
construiască un model conceptual al unui sistem economic din perspectiva unui anumit stakeholder.

o De exemplu, acolo unde un manager crede că o organizaţie trebuie să se orienteze pe calitate, ar trebui să se pună
accent pe activități cum ar fi:
i) Dezvoltarea staff-ului de înaltă calificare;
ii) Introducerea proceselor orientate pe client;
iii) Monitorizarea nivelelor de satisfacție ale clienților.
2.2. Considerarea perspectivelor
Ø Rezumatul etapei
o Obiectivul acestei etape este să se înregistreze perspectivele stakeholderilor despre sistemul aflat în investigare.
Aceste perspective pot fi apoi analizate în funcţie de valorile şi credinţele stakeholderului şi apoi dezvoltate în modele
ale sistemului.

o Procedura:
(i) Identificarea stakeholderilor cheie ale căror perspective sunt importante pentru proiectul de analiză a
afacerii.
(ii) Investigarea valorilor, credinţelor şi priorităţilor stakeholderilor cheie.
(iii) Dezvoltarea şi analiza perspectivelor stakeholderilor.
(iv) Construirea modelelor conceptuale ale activităților care corespund perspectivelor stakeholderilor.
(v) Explorarea şi rezolvarea conflictelor între perspectivele stakeholderilor.
(vi) Sinteza modelelor conceptuale într-unul corespunzând sistemului de afaceri dorit.
2.2. Considerarea perspectivelor
Ø Rezumatul etapei
o Inputuri:
- Termenii de referință sau documentul inițial al proiectului
- Obiectivele și strategia de afaceri
- Identificarea stakeholderilor (din documentația sistemului de afaceri existent)
o Outputuri:
- Perspectivele stakeholderilor
- Modelele activităților bazate pe perspectivele stakeholderilor individuali
- Modelul unic al sistemului agreat de stakeholderi
o Tehnici:
- Tehnici de investigare şi negociere
- Identificarea şi analiza stakeholderilor
- Analiza perspectivelor stakeholderilor
- Modelarea activităților din sistem
2.3. Analiza nevoilor

Ø Scopul acestei etape este să identifice unde pot fi făcute îmbunătăţiri în sistemul analizat. Metoda utilizată este
cunoscută sub numele de “Analiza Decalajului” (Gap Analysis) deoarece o viziune actuală sau “as is” este
comparată cu una dorită, viitoare sau “to be”.

Ø Metoda contrastează cu metoda tradiţională, mai sistematică, de îmbunătăţire a sistemelor sau afacerilor, unde noi
caracteristici sunt adăugate unei mulţimi existente de proceduri sau unui sistem IT existent.

Ø În cadrul analizei decalajului, accentul este pus pe înţelegerea a ceea ce am dori să fie, plecând de la situația
curentă şi identificând ce nevoi de schimbare există pentru a ajunge la situația dorită.
2.3. Analiza nevoilor
Ø Analiza activităţilor

o Dacă am dezvoltat un model al activităților sistemului din perspectiva stakholderilor, acesta poate fi utilizat pentru
a efectua o analiză detaliată a sistemului respectiv, examinând fiecare activitate în parte. Această analiză ne va
permite să identificăm elementele care trebuie să fie abordate în orice soluție care va fi recomandată.

o Deoarece modelul conține o imagine conceptuală a activităților dorite, el permite analistului de sistem să vadă
unde este deficitar sistemul curent.

o Când examinăm modelul, decalajele identificate vor varia de la o activitate la alta. Unele activități există şi
funcționează satisfăcător, altele pot fi inadecvate pentru sistemul actual sau chiar să nu existe.

o Identificarea decalajelor la acest nivel ne va ajuta să determinăm potenţialul de schimbare al sistemului analizat şi
măsura în care acest lucru este cerut. Modelul procesului de analiză de sistem poate identifica un şir de domenii ce
trebuie considerate în lumina situației economice curente. Totuşi, este posibil ca unele aspecte să fie dincolo de
scopul activităţii de analiză de sistem.
2.3. Analiza nevoilor

Ø Analiza proceselor de afaceri

o Un alt obiectiv al analizei decalajului se concentrează pe procesele existente în sistemul respectiv. În timp ce
activităţile modelate de modelul general prezintă o viziune conceptuală asupra activităților care trebuie incluse în
cadrul sistemului dorit, modelele proceselor de analiză permit să vedem ce face fiecare activitate în parte.

o Un proces de afaceri este declanșat de un eveniment de afaceri şi se termină când scopul procesului a fost atins.

o Metoda utilizată presupune modelarea procesului de afaceri existent şi apoi considerarea schimbărilor posibile ale
procesului, urmată de proiectarea procesului cerut. Deci, dezvoltăm mai întâi un model “as is” care constituie baza
pentru dezvoltarea modelului cerut sau modelul “to be”.

o Când reproiectăm un proces, putem efectua mici schimbări care afectează unul sau doi pași ai procesului, sau
putem decide să proiectăm un întreg nou proces.
2.3. Analiza nevoilor
Ø Rezumatul etapei
o Obiective: Obiectivele acestei etape sunt să explorăm diferenţele dintre situaţiile curente şi cele dorite şi să
identificăm oportunităţile de schimbare ale afacerii analizând aceste decalaje sau “gapuri”.

o Procedura
i. Examinează activităţile din cadrul modelului activităţilor de afaceri.
ii. Evaluează cât de bine sunt realizate aceste activităţi în sistemul de afaceri actual şi cât de bine sunt susţinute
de sistemele informaţionale ale organizaţiei.
iii. Identifică evenimentele de afaceri cheie care pot avea loc în sistemul de afaceri şi dezvoltă modele ale
proceselor de afaceri “as is” pentru fiecare dintre acestea.
iv. Dezvoltă modele ale proceselor de afaceri “to be” pentru evenimentele de afaceri cheie.
v. Analizează decalajul dintre situaţia existentă şi cea dorită. Utilizează această analiză ca o bază pentru a
identifica îmbunătăţirile potenţiale ale sistemului de afaceri.
2.3. Analiza nevoilor
Ø Rezumatul etapei
o Inputuri:
Modelul activităţii de afaceri agreat
Viziunea asupra sistemului de afaceri existent
Obiectivele şi strategia afacerii
o Outputuri:
Analiza activităţilor, incluzând identificarea punctelor slabe
Modelele proceselor de afaceri “as is” şi “to be”
Lista potenţialelor îmbunătăţiri ale sistemului de afaceri
o Tehnici:
Analiza decalajului
Analiza activităţii
Modelarea proceselor de afaceri
2.4. Evaluarea opțiunilor

Ø În această etapă, schimbările sunt definite în general, deci nu vor fi suficient de detaliate astfel încât să fie dezvoltat
un caz de afaceri care să conţină recomandări şi să constituie o bază pentru luarea deciziilor. Odată ce activitatea de
definire a schimbărilor începe să capete contur, pot să apară noi opţiuni de schimbare legate de acestea.

Ø Identificarea opţiunilor potenţiale

o Primul pas în identificarea potenţialelor opţiuni este determinarea locurilor în care pot fi făcute schimbări şi
identificarea celor care vor determina beneficiile potenţiale cele mai mari.

o Odată ce un număr de opţiuni a fost identificat, acestea pot fi reduse la o listă scurtă a celor care vor fi dezvoltate
în continuare. Obiectivele şi strategia de afaceri sunt considerate ca o parte a dezvoltării şi evaluării opţiunilor,
deoarece ele trebuie să fie susţinute de orice schimbare.
2.4. Evaluarea opțiunilor
Ø Asigurarea fezabilităţii

o Toate opţiunile care vor fi considerate în detaliu vor fi evaluate din punct de vedere al fezabilităţii tehnice,
financiare şi în afaceri.

o În plus, aspecte cum ar fi impactul unei opţiuni asupra organizaţiei şi riscurile care pot fi asociate cu fiecare opţiune
sunt, de asemenea, considerate.

o Această etapă are drept scop examinarea îmbunătăţirilor potenţiale identificate mai sus, dezvoltarea unor opţiuni
de schimbare şi evaluarea lor pentru a fi acceptate şi fezabile.

o Analiza decalajului dintre sistemul existent şi cel dorit este acum orientată către transformarea acestor idei în
opţiuni de afaceri. Acestea pot să includă opţiuni de schimbare în domenii precum: schimbări ale proceselor de
afaceri, rolurilor joburilor, structurii de conducere sau a sistemelor IT.
2.4. Evaluarea opțiunilor
Ø Rezumatul etapei
o Obiectivul acestei etape este să culeagă toate potenţialele schimbări în pachete de acţiuni de îmbunătăţire. Aceste
pachete formează baza pentru dezvoltarea unui set de opţiuni care sunt apoi dezvoltate şi documentate în detaliu.
Ele sunt prezentate managerului afacerii pentru a fi luate în considerare.

o Procedura:
(i) Identificarea unor opțiuni de afaceri.
(ii) Explorarea acceptabilității opțiunilor şi reducerea lor la o listă scurtă.
(iii) Dezvoltarea şi documentarea fiecărei opțiuni de pe lista scurtă în detaliu.
(iv) Dezvoltarea unui caz de afaceri, incluzând prezentarea opțiunilor şi recomandări pentru managerii
afacerilor.
2.4. Evaluarea opțiunilor
Ø Rezumatul etapei
o Inputuri:
- Documentul de inițiere al proiectului
- Obiectivele și strategia de afaceri
- Lista cu potențialele îmbunătățiri ale sistemului de afaceri
o Outputuri:
- Lista scurtă cu opţiunile de afaceri
- Cazul de afaceri, incluzând opţiuni, asigurarea fezabilităţii şi recomandările pentru managerul afacerii
o Tehnici:
- Identificarea opțiunilor de afaceri
- Analiza cost/beneficiu, incluzând cuantificarea costurilor şi beneficiilor şi tehnicile de evaluare a investițiilor
necesare
- Analiza de impact
- Analiza de risc
2.5. Definirea cerințelor
Ø Această etapă este orientată către obţinerea şi documentarea cerinţelor detaliate pentru schimbări în sistemele de
afaceri. Aceste schimbări pot fi într-unul (sau în toate) dintre cele patru aspecte ale sistemului de afaceri:
procese de afaceri, sisteme suport IT, oameni care realizează activităţi sau structura organizatorică.
Ø Analiştii de sistem au responsabilitatea de a defini cerinţele complet şi precis, deoarece documentarea
va forma baza pentru dezvoltarea sistemului. Dacă cerinţele nu sunt documentate clar, atunci pot
apărea probleme în cursul dezvoltării sistemului, dar şi atunci când acesta va fi implementat. Este foarte
important, deci, ca cerinţele să poată fi legate direct de nevoile afacerii şi să susţină obiectivele afacerii.
Ø Ingineria cerinţelor
o Metoda ingineriei cerinţelor a fost dezvoltată ca un răspuns la lipsa de rigoare, adeseori regăsită în documentaţia
cerută. Ingineria cerinţelor propune un cadru care să ajute pe analist să îmbunătăţeasca munca de definire a
cerinţelor prin utilizarea unei analize proactive, organizare, documentare şi management al cerinţelor stabilite.
2.5. Definirea cerințelor

Ø Modelarea sistemelor IT

o Există multe tehnici de modelare disponibile pentru analiştii de sistem. Aceste tehnici provin, în principal, din analiza
de sistem şi din metodele de proiectare, cum ar fi UML. Fiecare tehnică de modelare conţine un anumit aspect
particular al IT. De exemplu, tehnicile cum sunt modelarea claselor obiect şi modelarea entităţilor relaţionale conţin
mijloace clare şi neambigue de documentare în ceea ce priveşte datele referitoare la sistemul analizat.

o Analiştii de sistem găsesc aceste tehnici extrem de utile când explorează cerinţele, deoarece ele ajută în
introducerea rigorii în activitatea de analiză a cerinţelor.

o Construind şi comparând modelele unui sistem, analiștii vor ajuta să se genereze întrebări adiţionale şi să se
descopere omisiuni, erori şi inconsistențe.
2.5. Definirea cerințelor
Ø Rezumatul etapei
o Obiectivul acestei etape este să producă un document cu cerinţe bine formulate pentru noul sistem considerat.
Acest document trebuie să include clar descrieri textuale ale cerinţelor şi informaţie suficientă pentru a trasa fiecare
cerinţă de la origini până la rezolvarea sa completă. Tehnicile de modelare pot fi utilizate pentru a reprezenta
procesul şi datele asociate sub formă de diagrame şi deci pentru a îmbunătăţi rigoarea definirii cerinţelor.
o Procedura:
(i) Obţinerea cerinţelor:
Elicitarea şi analiza cerințelor pentru noul sistem proiectat.
Documentarea şi managementul cerinţelor.
Validarea cerinţelor documentate.
(ii) Documentarea cerinţelor pentru noul sistem proiectat, incluzând:
Modele ale proceselor din sistem;
Catalogul cerinţelor;
Modele ale prelucrării IT şi ale datelor;
Glosarul de termeni.
2.5. Definirea cerințelor
o Inputuri:
Opţiuni selectate pentru sistemul revizuit
Obiectivele şi strategia urmată
Termeni de referinţă/documentul de iniţiere a proiectului
o Outputuri:
- Modelele de proces “to be”
- Definiţiile joburilor
- Structura organizatorică revizuită
- Documentul cu cerinţele validate, incluzând: Catalogul cerinţelor, Modele ale procesului de afaceri şi
cerinţelor de sistem, Glosarul de termeni
o Tehnici:
- Modelarea proceselor de afaceri
- Proiectarea joburilor
- Tehnici de investigare
- Elicitarea, analiza şi validarea cerinţelor
- Documentarea şi managementul cerinţelor
- Tehnici de modelare ale sistemelor IT
2.6. Livrarea schimbărilor
Ø Odată ce analiştii de sistem au considerat şi analizat situaţia problemă, au dezvoltat opţiuni pentru îmbunătăţirea
acesteia şi au definit cerinţele ce vor fi livrate, este important să se considere modul în care aceste cerinţe vor fi
livrate, schimbările implementate şi beneficiile de afaceri realizate. În esenţă, această activitate nu este
responsabilitatea analiştilor de afaceri, dar aceştia trebuie să realizeze anumite sarcini şi să ofere suport pentru
echipa de proiect.

Ø Figura 4.3 arată o versiune extinsă a modelului procesului de analiză a afacerilor, incluzând şi etapa în care analiştii
de afaceri sprijină livrarea schimbărilor.
2.6. Livrarea schimbărilor

Ø Cerinţele trebuie să fie transformate în soluţia de schimbare a afacerii. Această soluţie poate include procese,
oameni, schimbări organizationale şi în sistemul IT.

Ø Ciclul de viaţă şi metoda ce va fi adoptată pentru a dezvolta şi livra schimbările vor fi bine stabilite. Această decizie
va avea un impact important asupra rolurilor din echipa de proiect, livrabilelor ce vor fi produse şi tehnicilor care vor
fi utilizate.

ØImplementarea schimbărilor în afacere

o Implementarea schimbărilor în afacere consideră aspecte cum ar fi: cultura organizaţiei, impactul emoțional al
schimbării şi realizarea de beneficii din afacere. Din nou, analistul de afaceri nu va fi cel responsabil de această
activitate, dar va susţine implementarea schimbărilor şi va evidenţia beneficiile de orice fel atrase de
implementarea soluţiei.
2.6. Livrarea schimbărilor
Ø Rezumatul etapei
o Procedura:
(i) Decide ciclul de viaţă şi metoda ce va fi adoptată pentru a dezvolta şi livra schimbările.
(ii) Dezvoltă soluţia de schimbare a afacerii.
(iii) Planifică implementarea:
- Consideră mediul pentru schimbare.
- Consideră cultura organizational.
- Defineşte metoda de învăţare şi dezvoltă materialele de învăţare necesare.
(iv) Revizuieşte beneficiile prevăzute.
(v) Identifică orice acţiune necesară pentru realizarea beneficiilor.
o Inputuri:
- Procesul de schimbare a afacerii şi proiectare organizatională
- Soluția software IT
- Cazul de afaceri
2.6. Livrarea schimbărilor
Ø Rezumatul etapei
o Outputuri:
- Planul de schimbare a afacerii
- Planul de comunicare
- Metoda de învăţare şi materialele necesare
- Rolurile joburilor revizuite şi descrierea acestora
- Documentul de revizuire post-implementare
- Planul de realizare a beneficiilor

o Tehnici:
- Analiza de putere/impact a stakeholderilor
- Analiza web şi culturală a organizației
- Analiza 7-S a lui McKinsey
- Modelul de adoptare bazat pe constatări.