8_REALIZAREA PROIECTULUI DE ANALIZĂ DE

SISTEM

INTRODUCERE
8.1 CICLUL DE VIAȚĂ AL PROIECTULUI DE ANALIZĂ DE SISTEM
8.2 IDENTIFICAREA OPȚIUNILOR STAKEHOLDERILOR
8.3 ASIGURAREA FEZABILITĂȚII PROIECTULUI
8.4 STRUCTURA UNUI PROIECT DE ANALIZĂ DE SISTEM
8.5 PREZENTAREA UNUI PROIECT DE ANALIZĂ DE SISTEM
8.6 ÎNTOCMIREA PLANULUI DE BENEFICII
INTRODUCERE
Un proiect de analiză este documentul cheie care rezultă în urma analizei de
sistem. Este documentul în care analiștii concentrează ceea ce au constatat şi
propun un nou curs al acţiunii pe care managementul de top din organizația
analizată trebuie să îl ia în considerare.
În acest capitol sunt prezintate scopul, structura şi conţinutul unui proiect de
analiză de sistem şi se oferă unele orientări asupra modului de asamblare a
informaţiei și cunoașterii acumulate de-a lungul activităților desfășurate şi de
prezentare a acestuia ca un produs final.
În anumite limite, un proiect este un document care este cumpărat de oamenii
care iau decizii în organizația analizată. Unele dintre regulile cheie ale vânzărilor de
succes se aplică şi în acest caz: accentuează asupra beneficiilor, nu asupra
caracteristicilor; vinde beneficiile înainte de a discuta despre costuri şi dă
“cumpărătorilor” o înţelegere asupra dimensiunii problemei – sau oportunităţilor
– înainte de a prezenta cantitatea de timp, efort şi bani care vor fi necesare pentru
a implementa o soluţie.
Ele ar trebui examinate din nou odată ce soluția a fost proiectată şi când există
mult mai multe date disponibile privind costurile schimbării.
8.1 CICLUL DE VIAȚĂ AL PROIECTULUI DE ANALIZĂ DE SISTEM
O întrebare deseori pusă referitoare la proiectul de analiză de sistem este “Când ar
trebui produs acesta?”
Acest lucru este reprezentat în figura 8.1. Cum se arată în această figură, un proiect
este un document viu şi ar trebui revizuit pe măsură ce proiectul avansează şi sunt
descoperite tot mai multe lucruri despre soluţia propusă şi costurile şi beneficiile
introducerii acesteia. În plus, desigur, sistemele şi mediul înconjurător în care
acestea funcționează nu sunt statice, astfel încât proiectul trebuie să fie menţinut
continuu la zi prin revizuire, pentru a asigura că circumstanțele schimbărilor nu îl
invalidează. Proiectul inițial rezultă adeseori în urma unui studiu de fezabilitate, în
care cerințele generale şi opțiunile sunt luate în considerare şi estimările
preliminare ale costurilor şi beneficiilor sunt dezvoltate. Cifrele preliminare trebuie,
totuşi, să fie revizuite odată ce o analiză mai detaliată este efectuată şi o imagine
mai completă asupra opțiunilor posibile este disponibilă.
Proiectul de analiză de sistem ar trebui apoi să fie revizuit înainte ca soluţia să fie
livrată, deoarece în mod sigur circumstanțele în care funcționează sistemul pot să
se fi schimbat şi putem acum să trecem la implementare.
Figure 8.1 Cazul de afaceri în ciclul de viaţa al proiectului de analiză
În final, odată ce soluţia propusă a fost pusă în funcţiune, după un anumit timp,
trebuie făcută o revizuire post-proiect pentru a determina gradul în care beneficiile
previzionate ale proiectului au fost realizate şi pentru identificarea acţiunilor de
susţinere a livrării acestor beneficii.
Figura 8.1 se referă la fiecare dintre aceste puncte de revizuire ca la “porţi
decizionale”. Acest concept, larg utilizat în managementul proiectelor de analiză de
sistem, presupune ca proiectele să treacă anumite teste – nu neapărat cele legate
de viabilitatea sistemului – înainte ca să se poată trece la următoarea etapă.
8.2 IDENTIFICAREA OPȚIUNILOR
Primul pas în realizarea unui proiect de analiză de sistem este identificarea şi
explorarea diferitelor opţiuni care există pentru rezolvarea cerinţelor sistemului.
Există, de fapt, două mari tipuri de opţiuni:
• opţiuni de afaceri, care explorează ceea ce soluţia propusă intenţionează să
atingă în termeni de afaceri – de exemplu, “Viteza de încasare a facturilor să
crească cu 50%” sau “Reduce numărul de oameni necesar pentru funcţionarea
supermarketului”;
• opţiuni tehnice, care consideră cum soluţia livrată trebuie implementată,
adeseori prin utilizarea sistemelor IT.
La un moment de timp dat se poate considera că aceste două tipuri trebuie să fie
considerate separat şi că opţiunile de afaceri trebuie să fie considerate mai întâi,
scopul fiind evitarea dificultăţilor de a rezolva în acelaşi timp şi opţiunile de afaceri
şi cele tehnice.
Acum, totuşi, multe schimbări în practica afacerilor includ utilizarea IT într-o
anumită formă şi este adeseori disponibilă tehnologia care face soluţiile de
schimbare posibile. De exemplu, un mod de a reduce necesarul de personal într-un
supermarket este să se asigure posibilitatea clienţilor de a-şi scana singuri
cumpărăturile, utilizând noul sistem de coduri de bare “inteligent”.
Din cauza aceasta este oarecum dificil să menţii complet separate opţiunile de
afaceri şi pe cele tehnice, dar rămâne adevărat că nevoile afacerii, mai mult decât
utilizarea tehnologiei, rămân cele care determină direcţia de dezvoltare.
Procesul de bază pentru dezvoltarea opţiunilor este reprezentat în figura 8.2.
Identificarea opţiunilor este probabil cel mai bine realizată folosind o anumită
formă de workshop, în care brainstormingul şi alte metode creative de rezolvare a
problemelor pot fi utilizate.
Tehnicile de modelare cum ar fi modelarea sistemului de afaceri şi modelarea
proceselor de afaceri sunt, de asemenea, utile în generarea opţiunilor. Scopul este
simplu: să se pună pe masă toate ideile posibile înainte să se treacă la alegerea
celor mai promiţătoare dintre ele.
Figure 8.2 Dezvoltarea opțiunilor proiectului

Chiar dacă unele dintre idei par nerealiste, ele pot constitui părţi ale soluţiei
actuale sau stimula alte persone să formuleze alte idei similare, dar care sunt
realizabile. Un alt mod de a identifica opţiunile este să se studieze ce alte
organizaţii – posibil concurente – au stabilit opţiuni similare.
Odată ce toate posibilităţile au fost identificate, ele pot fi evaluate pentru a vedea
care dintre ele ar trebui examinate în viitor. De obicei, unele idei pot fi respinse
foarte repede deoarece sunt foarte scumpe, iau prea mult timp pentru
implementarea lor sau sunt contraculturale pentru organizaţie.
Criteriile pentru evaluarea fezabilităţii unei soluţii sunt examinate mai detaliat în
continuarea acestui capitol.
Ideal este ca lista scurtă de opţiuni să fie redusă la trei sau patru, una fiind
menţinerea status-quo-ului, deci opţiunea este să nu se facă nimic.
Motivul pentru restrângerea listei la trei sau patru posibilităţi este că este destul
de nepractic, din raţiuni de timp sau cost, să examinăm mai multe în detaliu
pentru a le dezvolta în continuare în cadrul proiectului. Fiecare dintre opţiunile de
pe lista scurtă trebuie să corespundă unor elemente majore ale afacerii, dar să
ofere şi o balanţă de timp distinctă pentru implementare, cu un buget necesar
stabilit raţional şi un şir de beneficii atractive.
Uneori este posibil ca opţiunile să reprezinte variaţii ale unei singure soluţii, una
dintre acestea referindu-se la cele mai presante probleme ale afacerii, iar celelalte
oferind diferiţi factori adiţionali. Această situaţie este ilustrată în figura 8.3.
În figura 8.3 opţiunea de bază se referă doar la cea mai presantă problemă din
afacere care trebuie rezolvată cât mai repede posibil şi cu costuri minime.
Următoarea opţiune adaugă unele caracteristici adiţionale la soluţie, dar costurile
sunt mai mari şi necesită mai mult timp pentru implementare. Ultima opţiune este
o soluţie completă, dar care, de obicei, necesită cel mai lung timp şi costul cel mai
mare de implementare.
Figure 8.3 Opţiuni incrementale
O opţiune care trebuie întotdeauna considerată – şi care trebuie să se regăsească
într-un mod sau altul în cazul de afaceri considerat - este să nu se facă nimic.
Uneori este cea mai viabilă opţiune şi poate fi chiar cea mai bună alegere a
organizaţiei. Adeseori, totuşi, o astfel de opţiune nu este posibilă deoarece
problemele din organizaţie care decurg din inacţiune pot duce în final la costuri mai
mari.
În acest caz, decidenţii pot să nu fie conştienţi că acţiunea este imperativă şi astfel
să nu conştientizeze riscul şi consecinţele de a nu face nimic să devină o parte
importantă a soluției.
8.3 EVALUAREA FEZABILITĂȚII PROIECTULUI
Există multe probleme care trebuie luate în considerare atunci când evaluăm
fezabilitatea, dar toate pot fi grupate în trei clase importante, cum se arată în
figura 8.4.
Prima clasă, fezabilitatea afacerii, include criterii de apreciere dacă ipotezele
făcute se potrivesc cu obiectivele şi strategia organizaţiei şi – în cazul firmelor
comerciale – dacă ele pot fi atinse în condiţiile de piaţă curente. Există, de
asemenea, factori de apreciere a soluţiei propuse în raport cu timpul suficient
pentru livrarea soluţiei propuse şi securizarea beneficiilor dorite ale afacerii.
Propunerea trebuie să “se potrivească” cu structura managerială a organizaţiei
şi cu cultura acesteia, deoarece lipsa de cultură este una dintre cauzele care
determină ca proiectele să nu satisfacă aşteptările puse în ele. Soluţia trebuie să
fie capabilă de implementare în cadrul infrastructurii fizice a organizaţiei, chiar
dacă aceasta este o restricţie. Deşi propunerea poate fi pentru schimbarea
majoră a procesului, ea trebuie să aibă încă interfaţa cu alte procese care nu se
schimbă, astfel că compatibilitatea cu alte domenii trebuie să fie considerată .
Figure 8.4 Aspecte ale fezabilitatii
Orice este propus trebuie să fie conform competenţelor organizaţiei şi
personalului său, sau trebuie să existe un plan pentru dezvoltarea
acestor competenţe. În final, multe sectoare sunt acum înalt
reglementate şi soluţia propusă trebuie să fie una care va fi acceptabilă
pentru reglementatori şi să nu fie împotriva altor legi sau obligaţii
stabilite.
În evaluarea fezabilităţii tehnice este normal, dar nu neapărat necesar,
să se considere soluţia IT. Trebuie să evaluăm cererile organizaţiei în
funcţie de performanţele, disponibilitatea, reliabilitatea,
mentenabilitatea şi securitatea acesteia. Scalabilitatea - în sus şi în jos
– trebuie, de asemenea, să fie considerată . Organizaţia trebuie să
posede calificările tehnice necesare pentru implementarea soluţiei, sau
să suplimenteze aceste calificări cu ajutor din afară. Puţine sisteme IT
sunt acum standardizate şi apare astfel problema compatibilităţii cu alte
sisteme IT care sunt considerate. Dacă soluţia include un pachet
software achiziţionat din afară, trebuie evaluată cantitatea de
customizare care va fi necesară şi dacă acest lucru va determina
dificultăţi tehnice pentru organizația analizată.
În final, unele lucruri trebuie spuse despre soluţia propusă şi dacă aceasta se
dovedeşte unică sau dacă este alcătuită din module deja elaborate care s-au
dovedit din punct de vedere tehnologic fiabile. Multe organizaţii vor prefera o
soluţie mai puţin ambiţioasă, dar fiabilă, unei soluţii mai avansate, dar care
presupune un risc tehnologic crescut.
Fezabilitatea financiară se referă la modul în care organizaţia poate susţine
financiar soluţia propusă. Organizaţia este necesar fie să aibă fondurile necesare
disponibile, fie să poată să le împrumute. Fiecare organizaţie are unele reguli
sau proceduri pentru a evalua dacă o investiţie este acceptabilă sau nu. Chiar
dacă un proiect aduce în final anumite beneficii care să-i recupereze valoarea
investită, este necesar să existe suficient cash flow în timpul desfăşurării
proiectului. În final, toate organizaţiile specifică o perioadă de timp în care pot
să apară plăţi şi, în cazul proiectelor IT, perioadele de plată sunt deseori la
termene foarte scurte, uneori în acelaşi an contabil ca şi investiţia.
8.4 STRUCTURA UNUI PROIECT DE ANALIZĂ DE SISTEM
Organizaţiile diferă prin modul în care este prezentat proiectul de analiză, uneori
denumit și caz de afaceri. Unele preferă documente ample cu analize complete ale
propunerilor şi toate datele necesare susţinerii acestor propuneri. Altele preferă
prezentări scurte, sintetice ale principalelor puncte şi putem întâlni cazuri în care
cazurile de afaceri sunt rezumate într-o singură pagină A4. Dacă acest lucru pare
oarecum ciudat, trebuie să ne gândim că cei care audiază aceste prezentări sunt
managerii seniori, având timpul foarte limitat. Indiferent de mărimea lor, totuşi,
multe cazuri de afaceri sunt similare în ceea ce priveşte structura şi conţinutul lor.
Ele tind să include următoarele părţi componente:
• Introducere;
• Rezumatul managerial;
• Descrierea situaţiei curente;
• Opţiunea considerată ;
• Analiza costurilor şi beneficiilor;
• Evaluarea impactului;
• Evaluarea riscului;
• Recomandări;
• Anexe, cu datele şi informaţia de susţinere.
Vom examina fiecare element în continuare.
8.4.1 Introducere
Aceasta prezintă scena analizei, defineşte scopul şi obiectivele schimbărilor avute
în vedere şi explică ce caz de afaceri este prezentat. Dacă este relevant, trebuie,
de asemenea, descrise metodele utilizate pentru a examina elementele afacerii şi
se mulţumeşte oamenilor care au contribuit la studiu.
8.4.2 Rezumatul managerial
În multe privinţe aceasta este cea mai importantă parte a documentului,
deoarece poate fi singura parte pe care decidenţii seniori o vor studia atent.
Trebuie scris după ce restul documentului a fost completat şi trebuie să rezume
întregul caz de afaceri în câteva paragrafe.
Într-o situaţie ideală, trei paragrafe ar fi suficiente, acoperind:
• despre ce studiu este vorba şi ce s-a găsit despre elementele luate în
considerare;
• o trecere în revistă a opţiunilor considerate, cu avantajele şi dezavantajele sale
principale;
• o expunere clară a recomandărilor făcute şi deciziei necesare.
Dacă nu se pot realiza doar cele trei paragrafe, încearcă cel puţin să prezinţi
rezumatul managerial pe una sau două pagini.
8.4.3 Descrierea situaţiei curente
În această parte se explică situaţia curentă şi de unde apar problemele şi
oportunităţile. Atât timp cât aceasta corespunde cu explicarea acestor elemente clar,
este, de asemenea, important să se menţină această secţiune cât mai scurtă posibil,
managerii seniori adeseori plângându-se că au de citit o mulţime de pagini ca să afle
ceea ce deja ştiau.
Uneori, totuşi, problemele reale sau oportunităţile nedescoperite nu sunt ceea ce
gândeşte managementul superior atunci când studiază documentele. În acest caz,
mult spaţiu va trebui să fie alocat pentru explicarea elementelor şi explorarea
implicaţiilor pentru afacere.
8.4.4 Opţiuni considerate
În această secţiune descriem opţiunile luate în consideraţie şi explicat – cât mai scurt
cu putinţă – de ce s-au respins acele opţiuni care nu sunt recomandate. Mult spaţiu
trebuie alocat descrierii soluţiei recomandate şi de ce este ea recomandată. Cum am
văzut mai devreme – vezi figura 13.3 – pot exista o serie de opţiuni incrementale,
dintre care cea mai importantă dintre ele este prezentată în continuare.
8.4.5 Analiza costurilor şi beneficiilor
Analiza cost/beneficiu este una dintre cele mai interesante şi, în acelaşi timp, cel mai
dificil aspect ale dezvoltării cazului de afaceri.
Înainte de a examina subiectul în detaliu, trebuie totuşi menţionat faptul că este o
bună alegere psihologică să prezentăm beneficiile înaintea costurilor, deoarece
decidenţii vor aprecia atunci beneficiile înainte de a da piept cu costurile realizării
acestora. Cu alte cuvinte, ceea ce este prezentat este o analiză beneficii/costuri,
chiar dacă prin convenţie ne referim la ea ca o analiză cost/beneficii.
Deşi analiza cost/beneficii este interesantă, ea pune o serie de probleme:
• să se efectueze, în primul rând, acolo unde costurile sunt inerente şi beneficiile
pot fi aşteptate;
• să fie realistă privind beneficiile ce vor fi realizate în practică;
• să conțină estimarea unei valori ale elementelor intangibile cum ar fi
“îmbunătăţirea satisfacţiei clienţilor” şi “un moral mai bun al personalului”.
Ultimul punct adus în discuţie priveşte cu ce tipuri de costuri şi beneficii avem de-a
face în organizaţie. Costurile şi beneficiile sunt abordabile fie imediat, fie pe termen
lung. Ele sunt, de asemenea, fie tangibile, ceea ce înseamnă că o valoare credibilă –
de obicei monetară – poate fi asociată cu ele, fie intangibile, ceea ce presupune că
nu este cazul evaluării lor monetare. Combinând aceste elemente, găsim că
costurile şi beneficiile se încadrează într-una dintre categoriile ilustrate în figura
8.6.
Costurile tind să fie marea lor majoritate tangibile, în timp ce beneficiile sunt
adeseori o mixture de tangibile şi intangibile. În unele organizaţii, managerii nu iau în
considerare de loc beneficiile intangibile şi acest lucru face dificilă – sau chiar
imposibilă –construirea unui caz de afaceri corect. Cum să dăm o valoare la ceva cum
ar fi imaginea unei companii mai moderne atinsă prin adoptarea unui nou logo? În
teorie, este posibil să asociezi o valoare numerică oricărui cost sau beneficiu;
problema practică este că trebuie să ai timpul sau specialistul cu expertiză pentru
aceasta.
Dacă beneficiile intangibile sunt evaluate, este important ca ele să nu fie
supraestimate sau, mai rău, să fie stabilite la valori neglijabile. Pericolul aici este că
decidenţii nu vor acorda încredere acelor valori şi acest lucru subminează încrederea
lor în alte valori mai realist estimate. Cea mai bună politică în privinţa beneficiilor
intangibile este să se lase decidenţii să le evalueze ei înşişi.
O altă problemă în analiza costuri/beneficii este stabilirea valorilor pe baza unor
presupuneri. De exemplu, putem să auzim ceva de genul ”Dacă am putea atinge o
reducere de 20% a timpului necesar eliberării facturilor, atunci am putea obţine o
economie de 5000 de ore pe an sau o reducere a costului de 25.000 de Euro”.
Aceasta ar fi acceptabil pentru decidenţi dacă ipoteza ar fi plauzibilă. Dacă se poate,
trebuie utilizate ipoteze care sunt obişnuite în cadrul organizaţiei şi întotdeauna
trebuie luată partea celor conservatori – deci mai bine costuri subevaluate decât
supraevaluate.
Figure 8.6 Categorii de costuri şi beneficii
Având stabilite unele dintre elementele cheie, să aruncăm o privire asupra câtorva locuri
în care costurile şi beneficiile pot să apară şi a modului în care le putem cuantifica. Vom
utiliza cele patru categorii de costuri şi beneficii care au fost descrise deja.
Costuri tangibile
• Costuri de dezvoltare a personalului: în multe proiecte, în particular în cele care se
include dezvoltarea de noi procese şi sisteme IT, acestea vor fi un element de cost
important. Pentru a le stabili, este necesar să evaluăm o rată zilnică a personalului
prezent – probabil disponibilă de la Departamentul de Resurse Umane sau
Departamenul de Contabilitate – şi un plan exterior proiectului asupra resurselor care
vor fi necesare. Dacă consultanţii externi vor fi utilizaţi, atunci costurile vor fi subiect
de negociere şi contractare.
• Costuri de utilizare a personalului: acestea sunt adeseori uitate, dar pot fi
semnificative ca mărime. Personalul utilizat va trebui să fie disponibil pentru
investigarea iniţială, pentru testarea oricărui sistem inclus şi trebuie instruit în
operarea cu noul sistem şi metodele de lucru. Din nou, ratele zilnice pot fi utilizate în
combinaţie cu un plan al numărului de utilizatori incluşi.
• Hardware: acolo unde IT este inclus, există adeseori nevoia de a cumpăra noi sisteme
hardware. Pentru aceasta, estimarea sau cotaţiile pot fi obţinute de la furnizorii
potenţiali.
• Infrastructura: aceasta include lucruri ca reţele şi cabluri. Din nou, estimaţiile pot fi
obţinute de la furnizori.
• Pachete software: estimaţii obţinute de la vânzătorii de software, probabil sunt
bazate pe numărul propus de licenţe sau utilizatori. Acolo unde realizarea unui pachet
software este dorită, estimaţii ale efortului şi costului incluse pot fi, de asemenea,
necesare (trebuie analizată si posibilitatea migrării către cloud computing).
• Relocarea: aceasta poate fi destul de dificil de estimat în privinţa costului. Costurile
pot include cele legate de mutare şi închiriere, refacerea locaţiei şi noile piese de
mobilier. Există, de asemenea, costuri asociate cu supravegherea locului în care se
efectuează mutarea etc.
• Instruirea şi pensionarea personalului: pentru a realiza aceasta trebuie să cunoaştem
câţi de mulţi oameni este necesar să fie instruiţi şi ce trebuie ei să înveţe. Ideal,
aceasta necesită o formă specifică de instruire destinată analizei. Dacă nu există
suficient timp pentru aceasta, atunci se poate face o evaluare generală asupra
instruirii necesare şi multiplica timpul de livrare pentru un curs cu un factor de 10
pentru a avea o estimare aproximativă a efortului de dezvoltare a cursului.
• Costurile interne: odată ce noul sistem a fost realizat, el va necesita mentenanţă şi
susţinere, iar evaluarea acestor costuri poate fi obţinută de la vânzători.
Dacă aceasta nu este posibil, atunci o regulă empirică foarte aproximativă presupune
costuri operaţionale de 15% în primul an după instalare şi de 10% după aceea.
Totuşi, această aproximare este foarte problematică şi cotaţiile curente sunt mult
mai preferabile dacă ele pot fi obţinute.
Beneficii tangibile
• Economii de personal: acestea sunt cele mai obişnuite economii, deşi multe
organizaţii sunt acum atât de optimizate încât este greu de văzut de unde ar
mai putea veni alte economii. În calcularea economiilor, este necesar să
evaluăm costul cu angajarea personalului – inclusive lucruri cum sunt
asigurările naţionale, pensii şi alte beneficii şi, uneori, spaţiul pe care îl ocupă.
Departamentele de Resurse Umane sau cel de Contabilitate ar trebui să fie
capabile să ofere astfel de informaţii. Nu trebuie uitat că dacă există personal
redundant, aceasta va duce la apariţia de costuri suplimentare care trebuie să
fie stabilite, astfel încât să poată fi determinate reduceri care să ducă, în final,
la scăderea costurilor de personal.
• Efort redus şi viteză îmbunătăţită de lucru: dacă posturile personalului nu sunt
complet schimbate, este posibil să efectueze unele sarcini pe termen scurt,
ceea ce reduce timpul pentru alte activităţi. Acesta este un beneficiu tangibil
dacă efortul pe angajat pentru a realiza sarcina este măsurat şi comparat cu
situaţia aşteptată după schimbare.
• Răspuns mai rapid la solicitările clienţilor: din nou, va fi necesar să se
efectueze măsurători înainte de o schimbare a timpului necesar pentru a
răspunde nevoilor clienţilor pentru a cuantifica orice posibil beneficiu.
• Costuri de acomodare reduse: acestea pot fi împărţite, la rândul lor, în costul cu
personalul angajat, dar calculatoarele şi Internetul permit astăzi să se efectueze
o serie de activităţi la domiciliu o parte din timp sau permanent. Lucrul acesta
înseamnă reducerea costurilor de acomodare şi Departamentul de contabilitate
ar trebui să poată estima care sunt beneficiile organizaţiei în acest caz.
• Stocuri reduse: noile sisteme – în special sistemele “just in time” –reuşesc să
aibă nevoie de mai puţine stocuri. Experţii în finanţe şi logistică trebuie să fie
capabili să ajute în cuantificarea acestor beneficii.
• Reducerea altor costuri: reducerea muncii suplimentare, abilitatea de a evita
nivelele de bază ale numărului de personal şi reducerea timpului şi costurilor
călătoriilor între diferite locaţii, precum şi în utilizarea consumabilelor.
Beneficii intangibile
• Creşterea satisfacţiei în muncă: aceasta poate aduce beneficii tangibile cum ar
reducerea plecărilor din posture sau a absenteismului, dar problema este că nu
se poate stabili în avans dacă aceste lucruri se vor întâmpla.
• Îmbunătăţirea satisfacţiei clienţilor: aceasta este, de asemenea, intangibilă
deoarece nu putem să măsurăm precis, de exemplu, de ce clienţii se plâng de
produsele şi serviciile primite de la organizaţie.
• O mai bună informaţie managerială: este important să distingem între o mai
bună informare managerială şi simpla informaţie managerială mai bogată.
Prima conduce la decizii mai bune, dar acest lucru este dificil de evaluat.
• O mai mare flexibilitate organizaţională: acest lucru înseamnă că organizaţia
poate răspunde mai rapid la schimbări din mediul extern, deci are sisteme şi
procese mai flexibile şi membrii personalului pot trece să execute diferite
activităţi relativ mai rapid.
• Timp de rezolvare a problemelor decizionale mai mare: managerii eliberaţi
de activităţile de zi cu zi, au timp mai mult pentru a studia elemente de
strategie decizională.
• Îmbunătăţirea prezentării sau o mai bună imagine pe piaţă: noile sisteme
adeseori permit ca o organizaţie să se prezinte mai bine lumii din afară.
• Comunicaţii mai bune: mulţi oameni raportează comunicaţii slabe în cadrul
organizaţiilor lor ca o problemă, astfel că îmbunătăţirea comunicaţiilor va fi
benefică. Totuşi, din nou, cum se poate stabili o valoare pentru aceasta?
Prezentarea costurilor şi beneficiilor financiare, odată ce diferitele costuri şi
beneficii tangibile au fost evaluate, se face în aşa fel încât managerii să vadă dacă
şi când proiectul produce rezultate. Deoarece acesta este oarecum un concept
complex, este examinat separat sub titlul de “Evaluarea impactului investiţiei”.
8.4.6 Evaluarea impactului investiției
În plus faţă de costurile şi beneficiile deja menţionate, pentru fiecare opţiune este
necesar să explorăm în cazul de afaceri orice impact care ar putea apărea în organizaţie.
Unele dintre aceste impacturi pot avea costuri ataşate acestora, dar altele pot să nu aibă
acest lucru – ele pot fi lucruri care se întâmplă ca rezultat al adoptării cursului propus al
acţiunii. Exemple de astfel de impacturi includ:
• Structura organizatorică: poate fi necesară reorganizarea funcţiilor sau
departamentelor pentru a explora noile circumstanţe în mod corect, de exemplu
crearea unui singur punct de contact pentru clienţi sau roluri ale personalului mai
generale, în loc de cele specializate. Aceasta va putea fi deranjant pentru personal şi
managerii implicaţi şi un plan trebuie să fie făcut pentru a realiza această schimbare
de structură.
• Relaţiile interdepartamentale: similar, relaţiile dintre departamente se pot schimba şi
poate fi o necesitate pentru introducerea acordurilor în acest sens prin care să se
redefinească relaţiile.
• Practicile de lucru: noi procese şi sisteme inevitabil conduc la schimbări în practica de
lucru şi acestea trebuie să fie introduse atent şi sensibil.
• Stilul de conducere: uneori stilul pe care managerii îl adoptă trebuie să se schimbe.
De exemplu, dacă se înlătură anumite nivele din organizaţie şi se dă managerilor de la
nivelul de bază mai multă atenţie în a lucra cu clienţii, atunci rolurile lor manageriale
se vor schimba în mod corespunzător.
• Politica de recrutare: organizaţia poate avea nevoie să recruteze diferite tipuri
de oameni şi căuta diferite calificări.
• Criterii de apreciere şi promovare: poate este necesar să schimbăm ţintele şi
stimulentele pentru a-I încuraja să aibă diferite comportamente – de exemplu,
să fie mai mult orientate către problemele clienţilor.
• Relaţiile cu furnizorii: aceasta trebuie să fie redefinite. De exemplu, serviciile IT
externalizate vor decurge mult mai bine cu o relaţie client/furnizor cooperativă
decât cu apariţia unor situaţii de adversitate care există destul de des.
Oriunde apar astfel de impacturi, proiectul de analiză este necesar să le
expliciteze. Trebuie, de asemenea, să fie foarte clar pentru decidenţi că
schimbarea va trebui să fie făcută pentru a exploata oportunităţile disponibile
cât mai complet şi costurile acestor schimbări vor apărea inevitabil.
8.4.7 Evaluarea riscului
Nici o schimbare nu apare fără risc şi este nerealist să gândim altfel. Un proiect de analiză
de sistem este foarte puternic dacă el poate să arate că riscul potenţial a fost identificat şi că
sunt disponibile contramăsuri corespunzătoare.
Un Registru al riscurilor complet şi comprehensiv (uneori denumit şi Risk Log) nu este
probabil necesar la fiecare etapă – acesta ar trebui creat atunci când schimbarea sau
proiectul de dezvoltare începe propriu-zis – dar riscurile principale trebuie să fie
identificate. Pentru fiecare risc, următoarele elemente ar trebui menționate:
• Descrierea: cauza riscului trebuie să fie descrisă împreună cu impactul acestuia, de
exemplu “ Incertitudinea privind viitorul conduce la demisia personalului cheie, lăsând
organizația cu o lipsă de personal cu experiență”.
• Evaluarea impactului: aceasta trebuie să evalueze scala daunelor pe care organizația le-
ar suferi dacă evenimentul advers apare. Dacă măsurile cantitative pot fi utilizate,
aceasta este mult mai bine; altfel, o scală cu valorile “redus”, “moderat” sau “mare” va fi
suficientă.
• Probabilitatea: cât de probabil este ca acest risc să apară? Din nou, probabilitățile
precise pot fi calculate, dar este probabil mai bine ca să utilizăm scala “redus”, “mediu”
sau “înalt”.
• Contramăsuri: acestea se referă la un lucru important, problema fiind ce se poate face
astfel încât să se reducă probabilitatea de apariţie a evenimentului sau reducerea
impactului acestuia dacă el apare. Putem, de asemenea, să încercăm să transferăm
impactul riscului către altcineva, de exemplu să utilizăm o societate de asigurare.
• Proprietatea: pentru fiecare risc, este necesar să decidem cine va fi cel mai
bine plasat pentru a lua contramăsuri. Acesta poate include cerinţa ca
managerii seniori din organizaţie să-şi asume responsabilitatea.
Dacă rezultă că sunt mai multe riscuri asociate cu propunerea, atunci este o idee
bună să le documentăm doar pe cele mai importante – acelea care pot opri
proiectul sau distruge raţiunea afacerii – în corpul cazului de afaceri şi să le
punem pe celelalte într-o anexă.
8.4.8 Recomandări
În sfârşit, este necesar să rezumăm cazul de afaceri şi să facem cât mai clară
motivaţia pentru decizia pe care managerii seniori o vor adopta. Dacă cazul de
afaceri este realizat ca un proiect de un anumit fel, atunci o listă de cele mai
importante sarcini şi intervale de timp pentru realizarea acestora este utilă pentru
decidenţi. Aceasta este cel mai bine exprimat sub forma unui grafic Gantt cum se
arată în figura 9.7.
Figure 13.7 Graficul Gantt al unui proiect propus
8.4.9 Anexe şi informaţia suport
Acolo unde informaţie detaliată este necesar să fie inclusă în cazul de afaceri, cel
mai bine este să fie pusă într-o anexă. Aceasta separă punctele principale care
sunt incluse în corpul principal al cazului de afaceri de detaliile suport. Dacă
statistica suport trebuie să fie oferită, ea va fi, de asemenea, inclusă în anexă,
poate împreună cu grafice rezumative sau hărţi în partea principală. Calculele
detaliate cost/beneficiu pot fi, de asemenea, incluse în anexe.

8.5 PREZENTAREA UNUI PROIECT DE ANALIZĂ DE SISTEM

Există două modalităţi de bază în care proiectul de analiză poate fi prezentat şi
adeseori este nevoie de amândouă. El poate să apară ca un document scris şi ca o
prezentare faţă în faţă. În ambele cazuri, modul în care proiectul este prezentat
poate avea adeseori un impact major asupra acceptării lui sau nu. Există unele
reguli simple care se aplică în ambele situaţii:
• Din cine este formată audienţa: cititorii rapoartelor şi asistenţii de la
prezentare au o varietate de interese şi atitudini. Unii preferă să aibă toate
detaliile, iar alţii preferă un rezumat. Cât mai mult posibil se încearcă să se
comunice rezultatul final factorilor decizionali din raport sau prezentare.
• Fiţi cât mai conciși: trebuie utilizate mijloace de vizualizare de tipul slide-urilor
pentru a putea prezenta cât mai pe scurt ideile principale din expunere. Deşi uneori
cazul de afaceri este un document lung, el trebuie expus cât mai scurt.
• Ia în considerare structura: trebuie stabilită structura de bază pentru scrierea
cazului de afaceri. Pentru ca o prezentare să aibă cât mai mult succes este foarte
important să se respecte următoarele reguli:
- Prezintă ceea ce vor cei din audienţă să audă;
- Prezintă esenţialul, evitând amănuntele şi divagaţiile;
- Prezintă concluzia în mod logic, începând cu situaţia curentă şi conducând la
decizia cea mai bună care trebuie luată.
• Ia în considerare aparenţele: din nou, trebuie să se utilizeze slide-uri cât mai
sugestive, imagini şi diagrame, în loc de tabele şi trebuie să se utilizeze culori cât
mai sugestive.
9.6 MANAGEMENTUL ȘI REALIZAREA BENEFICIILOR
În ultimii ani, organizaţiile au devenit interesate din ce în ce mai mult de
managementul beneficiilor şi realizărilor, care poate fi rezumat ca fiind realizarea
de proiecte care sunt capabile să ofere beneficiile prezise şi, după ce proiectul a
fost implementat, să permită verificarea progresului în atingerea beneficiilor şi
luarea oricărei acţiuni care necesită susţinerea livrărilor acestora. Metoda de bază
este arătată în figura 8.8.
Figure 8.8 Benefits realisation approach
Când un proiect este elaborat, unele dintre beneficii sunt prezentate ca şi cum ar fi
măsurate. Pentru unele beneficii tangibile, acest lucru nu este prea dificil: de
exemplu, fie avem economiile de costuri așteptate, fie nu.
Totuși, chiar dacă sunt anumite probleme, cum ar fi problema analizei efectelor
acestui proiect faţă de alte proiecte care pot să aibă efecte în acelaşi timp. Sau cum
ne ajustăm la schimbările mediului extern, de exemplu o creştere sau o descreştere
generală a vânzărilor? Pentru beneficiile instabile, obstacolele sunt chiar mai mari:
cum putem să măsurăm o schimbare în moralul personalului, de exemplu? Oricare
af fi dificultăţile, totuşi, unele lucruri este necesar să fie introduse sub formă de
măsurători. Aceasta poate include supravegherea situaţiei înainte ca schimbarea să
aibă loc, astfel ca situaţia după schimbare să poată fi comparată cu aceasta.
Beneficiile nu vor apărea ele însele, simplu ca un rezultat al aplicării proiectului de
schimbare. Acolo unde un proiect are componente tehnice mari – cum sunt cele
care includ utilizarea IT – este o tendinţă naturală pentru planificare să se
concentreze în principal sau chiar exclusiv pe elemente tehnice; schimbările din
afaceri care sunt necesare să securizeze beneficiile trebuie, de asemenea, să fie
planificate. Trebuie apreciat, totuşi, că o astfel de planificare nu este, în general,
responsabilitatea managerului de proiect, a cărui atenţie este concentrată pe
aspecte tehnice; mai mult, este responsabilitatea sponsorului de proiect, care poate
obliga un manager al schimbării afacerii să elaboreze un plan de lucru detaliat.
Planificarea paşilor necesari pentru securizarea beneficiilor poate lua forma
construcţiei unei hărţi a beneficiilor, cum se arată în Figura 8.9.
Figure 8.9 Un examplu de hartă a beneficiilor
O hartă a beneficiilor este creată de la dreapta la stânga, începând cu obiectivele de
afaceri generale pe care proiectul de schimbare este destinat să le atingă. Vom
merge apoi înapoi la mulţimea de beneficii care vor contribui la aceste obiective.
Apoi vom considera ce schimbări ale afacerii vor fi necesare pentru a securiza aceste
beneficii şi, în final, vom identifica schimbările necesare care vor conduce la
schimbările în afacere.
Ca un exemplu, în figura 8.9, cel puțin un flux de schimbări ale afacerii reprezintă
aspecte tehnice ale proiectului, dar alte fluxuri se referă la schimbări care nu au
legătură cu IT, care vor fi necesare dacă beneficiile generale şi obiectivele sunt atinse.
Trebuie să observăm că săgețile de la obiectivele inițiale către beneficii (de la dreapta
la stânga) indică dependențele, în timp ce alte săgeţi merg de la stânga către dreapta
pentru a indica secvența de schimbări ale afacerii şi beneficii ale afacerii.
Avantajul construirii unei hârți a beneficiilor ca cea din figura 8.9 este că ea ne obligă
să considerăm întregul proces, nu doar ceea ce este legat de dezvoltarea sistemelor
IT, care sunt necesare pentru atingerea beneficiilor proiectului de schimbare a
afacerii. Ea ajută, de asemenea, la identificarea celor care au responsabilitatea
pentru fiecare flux. Fluxul tehnic, legat de dezvoltarea website-ului, de exemplu, este
evident responsabilitatea managerului de proiect, în timp ce fluxul legat de
îmbunătăţirea imaginii prin presă este responsabilitatea funcţiei de PR sau, dacă
organizaţia nu are aşa ceva, a departamentului de marketing.
Întorcându-ne acum la figura 8.8, observăm că o săgeată de la criteriile de evaluare
merge înapoi către proiectul de schimbare însuşi. Aceasta arată necesitatea de a
încerca şi conduce proiectul în aşa fel încât să fie maximizată speranţa de a obţine
beneficiile urmărite. De exemplu, permiţând o mulţime de schimbări poate
conduce la costuri mari ale proiectului şi deci la extinderea perioadei de timp
pentru obţinerea beneficiilor şi chiar la anularea tuturor câştigurilor ce s-ar obţine.
Procesele manageriale sunt necesare pentru a asigura că beneficiile sunt revăzute
în două circumstanțe:
• Revizuiri programate: la fiecare dintre cele două “Porți decizionale”, arătate în
figura 8.1 la începutul acestui capitol, beneficiile așteptate trebuie să formeze o
parte importantă a revizuirii. La fiecare etapă considerații atente trebuie făcute
pentru a vedea dacă beneficiile așteptate sunt încă disponibile şi dacă ele sunt
suficiente pentru a compensa, de exemplu, creșterea așteptată a proiectului. În
lumina acestei revizuiri, poate fi necesar să se redefinească scopul proiectului
pentru a îmbunătăți perspectivele securizării beneficiilor maxime.
• Revizuiri neplanificate: acestea trebuie să fie declanşate ori de câte ori un
eveniment semnificativ apărut ar putea să afecteze beneficiile aşteptate.
Schimbările propuse sunt un exemplu evident pentru aceasta, deoarece ele pot
cauza ca proiectul să coste mai mult, să necesite o perioadă mai lungă de timp
şi toate acestea să afecteze beneficiile urmărite.
Proiectul de analiză de sistem trebuie revizuit frecvent în cursul elaborării sale pentru a
verifica dacă beneficiile prevăzute pot fi încă atinse şi pentru a identifica orice schimbare
necesară a proiectului pentru a permite ca acele beneficii să fie livrate.
Principala evaluare, totuşi, are loc după ce proiectul a fost terminat. Trebuie oferite
estimări ale timpului necesar pentru ca beneficiile așteptate să apară.
Depinzând de tipul sau scala proiectului, pot să fie necesare luni sau chiar ani după ce se
termină proiectul pentru ca să apară beneficiile. Evaluarea va fi atunci orientată către
analiza progresului în atingerea beneficiilor şi stabilirea oricăror acţiuni necesare pentru a
permite atingerea beneficiilor.
În final, un raport de realizare a beneficiilor, care prezintă clar şi precis dacă beneficiile
prevăzute au fost sau nu atinse, va fi elaborat. Acest raport are patru destinaţii
importante:
• De ce beneficiile estimate nu au fost atinse şi ce măsuri adiţionale se impun pentru a
încerca să le obţinem totuşi. De exemplu, dacă organizația nu obţine avantajele
complete de la noul sistem, se poate considera că este necesară o instruire adiţională a
acestora.
• Se poate reasigura decidenţii superiori şi întreaga organizaţie că timpul, efortul şi
costul proiectului au fost justificate.
• Poate să constituie un input pentru viitoarele proiecte pentru a le face mai de succes.
• Poate să permită organizaţiei, în timp, să aleagă mai bine ce proiecte vor fi elaborate
în continuare.