Standardele de Analiză de Business, o lectură necesară pentru Managerii de Proiect – Episodul 2 din 3

Analiza de BusinessAșa cum arătam în episodul anterior, apariția Business Analysis for Practitioners – a Practice Guide de la PMI și a certificării PMI-PBA (Professional in Business Analysis), a însemnat un moment important de (re)considerare a însemnătății de prim rang a cerințelor bine definite (reprezentând corect și complet nevoile de business și fezabile) pentru succesul proiectului.

În cele ce urmează, vom trece în revistă prin plasare în paralel, două perspective actuale în standardizarea Analizei de Business:  Business Analysis for Practitioners – a Practice Guide (prescurtat de aici încolo BAPPG) aflat la prima versiune, de la PMI, și Business Analysis Body of Knowledge (prescurtat de aici încolo BABOK) aflat la cea de a treia versiune, de la IIBA.

Definirea Analizei de Business

BAPPG v.1BABOK v.3
Analiza de business înseamnă aplicarea de cunoștințe, abilități, instrumente și tehnici, pentru a:

  • determina probleme și a identifica nevoi ale business-ului;

  • identifica și recomanda soluții viabile pentru a adresa aceste nevoi;

  • obține, documenta, și gestiona cerințele stakeholder-ilor în vederea îndeplinirii obiectivelor de business și de proiect;

  • facilita implementarea cu succes a produsului, serviciului sau rezultatului final ale unui program sau proiect.
  • Analiza de business este practica de activare a schimbării într-o organizație prin definirea nevoilor și recomandarea de soluții care să livreze valoare stakeholder-ilor.

    Deși analiza de business este mai degrabă tratată în BAPPG ca având legătură cu proiectul (și conceptul este dezvoltat integrat în filosofia PMI legată de organizația orientată pe proiecte, programe, portofoliu – vezi standardele emise de către PMI cu aceste subiecte, alături de OPM3), vom vedea că spectrul este mai larg, cuprinzănd și perioadele pre și post proiect. BABOK v.3, laconic, ridică discuția la nivelul schimbării organizaționale, considerând că modalitatea efectivă de implementare a acestei schimbări – inițiativă, proiect, program, etc. este secundară față de domeniul analizei de business și derivănd din magnitudinea și diversitatea ariilor adresate de către schimbare, ambiguitatea soluției, complexitatea mediului. Cele două perspective nu se exclud una pe cealaltă, ci doar reliefează punctul de focus.

    Ce este o cerință?

    BAPPG v.1BABOK v.3
    O condiție sau capabilitate ce se cere a fi prezentă într-un produs, serviciu sau rezultat, pentru a satisface un contract, sau o altă specificație impusă în mod formal.
  • poate adresa o nevoie de business sau a unei persoane sau a unui grup de persoane.
  • O reprezentare utilizabilă a unei nevoi. Cerințele se focalizează pe înțelegerea a ce fel de valoare poate fi livrată dacă o cerință este îndeplinită.

    Așa cum am arătat în episodul 1 al acestei serii de articole, prima definiție a cerințelor a fost dată de către standardul IEEE-610.12, 1991, arătând ambivalența termenului: pe de o parte cerința ca o condiție sau o capabilitate necesară stakeholder-ului pentru a rezolva o problemă sau atinge un obiectiv, pe de altă parte, ca fiind o condiție sau capabilitate a soluției ce rezolvă problema sau ajută la atingerea obiectivului. BAPPG, referindu-se în principal la proiecte, înțelege cerința doar în cea de a doua ipostază, suprapunând noțiunea de livrabil al proiectului (produs, serviciu, sau rezultat) peste noțiunea de soluție. Cu alte cuvinte, soluția în viziunea PMI este livrabilul proiectului, ceea ce este corect, în măsura în care înțelegem tot ceea ce se livrează fiind întru rezolvarea problemei de business (sisteme, proceduri, elemente de tranziție, etc). BAPPG revine însă în capitolul Needs Assessment (dorit ca un gen de arie de cunoștințe) specifică Analizei de Business și desfășurată la nivelul organizației, denumind cerințe și nevoile exprimate (business requirements, stakeholder requirements). Mult mai pe scurt, BABOK v.3, deși în versiunile anterioare reluaseră definiția IEEE, arată că o cerință este o reprezentare utilizabilă a unei nevoi (de business). Acest atribut, „utilizabil”, provine din definiția dată de Juran satisfacției, ca fiind ”fitness for use”, cu alte cuvinte, soluția trebuie să folosească rezolvării problemei clientului, dincolo de conformitatea cu cerințele. Chiar PMI adoptase la un moment dat (PMBOK Guide v.3) înțelegerea respectării triplei constrângeri (timp, cost, conținut), ”within customer satisfaction”, ceea ce ducea la o preocupare de rezolvare a problemei clientului, dincolo de granițele, câteodată rigide, ale triunghiului.

    Tipuri de cerințe

    BAPPG v.1BABOK v.3
    • Business• Business
    • Stakeholder• Stakeholder
    • Solution:
         • Functional;
         • Non-functional.
    • Solution:
         • Functional;
         • Non-functional.
    • Transition• Transition
    • Project (acțiuni, procese, sau alte condiții pe care proiectul trebuie să le îndeplinească – aceste cerințe sunt legate deci de proiect, arătând moduri particulare cerute pentru desfășurarea acestuia și nu pentru soluție).
    • Quality (condiție sau capabilitate ce va fi folosită pentru a evalua conformitatea, prin validarea acceptabilității unui atribut privitor la calitatea unui rezultat – aici PMI distinge cerințe legate de organizare, acțiuni, resurse, etc. în cadrul proiectului și care sunt legate de conformitatea cu standarde, alte documente formale impuse).                                    

    Deși definirea primelor tipuri de cerințe este similară în cele două standarde, așa cum se poate observa, BAPPG v.1 consideră în plus față de BABOK v.3 două tipuri de cerințe care nu constituie preocuparea analistului de business, ci, a managerului de proiect. BAPPG v.1 are o grija deosebită pentru înțelegerea corectă a relației dintre managerul de proiect (PM) și analistul de business (BA), indicând, oriunde are ocazia, puncte de posibilă colaborare sau de posibil conflict.

    Cine este Analistul de Business?

    BAPPG v.1BABOK v.3
    În rolul BA sunt reprezentate toate rolurile (indiferent de funcția persoanei) care sunt responsabile să realizezei sarcinile de analiză de business în cadrul propriei organizații și în mod specific, sarcinile de analiză de business în proiecte și programe.Orice persoană care realizează analiză de business, indiferent de funcție sau rol organizațional.

    Înainte ca PMI să își aleagă propria perspectivă în legătură cu analiza de business, a existat o comisie formată din specialiști proveniți din ambele asociații (PMI și IIBA) care au urmărit armonizarea celor două standarde (PMBOK, BABOK) și realizarea unui model pentru înțelegerea relației dintre PM și BA.

    Cine este Analistul de Business

    Relația nu este una simplă. Dacă în cadrul domeniului de business analizat BA este ”avocatul” Business Owner-ului, răspunzând acestuia și urmărind transpunerea nevoilor în cerințe ale soluției, odată ce apare proiectul ca modalitate de livrare a soluției, BA este subordonat PM-ului, acesta fiind la rândul său subordonat Sponsorului. Cum în analiza de business constrângerile sunt considerate tot cerințe (de business, tehnice, etc), rezultă faptul că în cadrul unui proiect se construiește acea soluție permisă de constrângerile impuse, fapt care poate duce, în cazul lipsei de flexibilitate)  la conflict și insatisfacție.

    Ce este un Stakeholder?

    BAPPG v.1BABOK v.3
    Un stakeholder este o persoană, grup sau organizație care pot afecta, fi afectate sau se percep a fi afectate de către o decizie, activitate, sau efect al unui program sau proiect.Un grup sau o persoană aflat în relație cu schimbarea, nevoia, sau soluția.

    Observăm că BAPPG este tributar  unor definiții stabilite în PMI Lexicon of Project Management Terms v.3 și prezente în toate standardele PMI actualizate. În ce măsură cele două viziuni (PMI, IIBA) concordă sau doar se suprapun parțial,  ce efecte pot apărea de aici, putem detalia într-un articol viitor.

    Domenii/Arii de cunoștințe

    Păstrând denumirile în limba engleză, domeniile abordate de către BAPPG pot fi puse în corespondență cu ariile de cunoștințe prezentate în BABOK, după cum urmează:

    BAPPG v.1BABOK v.3
    • Needs Assessment.• Strategy Analysis.
    • Business Analysis Planning.• Business Analysis Planning and Monitoring.
    • Requirements Elicitation and Analysis.• Elicitation and Collaboration;
    • Requirements Analysis and Design Definition.
    • Traceability and Monitoring.• Requirements Life Cycle Management.
    • Solution Evaluation.• Solution Evaluation.

    După cum se poate observa, structura domeniului Analizei de Business, așa cum a mai fost abordat și de către alte foruri de standardizare (IREB – International Requirements Engineering Board, de exemplu) este cvasi-identică, denumirile putând ușor să difere și reflectând viziunea specifică a acestor foruri. Needs Assessment, de exemplu, reprezintă activitatea de analiză de business realizată pentru a evalua problema (sau oportunitatea) curentă de business. Aici se evaluează mediile interne și externe, capablitățile curente pentru a se determina opțiuni de soluții viabile care, atunci când sunt urmate, vor ajuta organizația să își atingă starea viitoare dorită. Cum problemele nu pot fi rezolvate doar local, izolat, fără a avea efecte la nivelul organizației, pe termen mediu și lung, denumirea aleasă pentru același domeniu de către IIBA, Strategy Analysis, nu pare a fi deplasată.

    În episodul următor vom detalia aceste domenii/arii de cunoștințe și vom vedea în ce măsură PMI a înțeles Analiza de Business și de ce pentru un Manager de Proiect procesul elaborării cerințelor este important a fi cunoscut.

    Nota:
    Prtima parte a acestui articol poate fi citita aici:
    Standardele de Analiză de Business, o lectură necesară pentru Managerii de Proiect – Episodul 1 din 3

    Rating: 4.9/5. From 8 votes.
    Please wait...
    Voting is currently disabled, data maintenance in progress.

    Leave a Reply

    Your email address will not be published. Required fields are marked *