Mani pirmie iespaidi par BABOK v3


Kā jau varbūt dzirdēts, BABOK jeb biznesa analīzes vadlīnijām – A Guide to the Business Analysis Body of Knowledge® top trešā versija. Publiskais review beigsies 11.jūlijā.

Uzrakstīju savus pirmos iespaidus. Iedvesmojos no 26.jūnijā Analītiķu vakariņām par šo tēmu un Gundegas Lazdānes stāstītā. Šī nav recenzija! :-)

Liriska atkāpe – PMI ir startējis savu Professional in Business Analysis (PBA) sertifikāciju, spēcīgu konkurentu IIBA Certified Business Analysis Professional (CBAP). Vienā teikumā –

  • PMI PBA skatījumā biznesa analītiķis atbalsta projekta vadītāju, uzsvars ir uz BA lomu tieši projekta izstrādes laikā un sedz hibrīdgadījumus, kad BA un PM saplūst,
  • IIBA jeb CBAP gadījumā – BA atbalsta organizāciju, projekts ir tikai daļiņa no biznesa analīzes, skatās stratēģiskāk, plašāk, un piemērotāks klasiskiem BA.

No vienas puses man kā tipiskam hibrīdam ir žēl, ka agrāk nebija PMI PBA, bet no otras puses – pašlaik uzskatu, ka PMP + CBAP ir jaudīgāks zināšanu komplekts par vienu pašu PMI PBA.

Labi, atgriežamies pie CBAP un BABOK. Tas ir kļuvis stipri savādāks un iesaku mācības beigušajiem iespringt un nokārtot CBAP pēc v2. Eksāmeni pēc jaunā sāksies ~2015. gada pirmajā pusē.

Tātad:

  1. Mainīta Biznesa Analīzes definīcija (manuprāt, legalizēts fakts, ka biznesa analītiķis dara daudz vairāk nekā „tikai” pilda uzdevumus un paņēmienus, lai izzinātu prasības un apkopotu tās dokumentos):

BAdef

  1. Mainīta Prasības definīcija (manuprāt, uzliekot lielāku atbildību analītiķim, jo pirms tam izrietēja, ka izteicējam būtu jāspēj noformulēt, kādu problēmu tā risinās vai kādu mērķi sasniegs. Tagad prasība var būt praktiski jebkas)

ReqTab

  1. Ieviests dizaina jēdziens un definīcija, un Prasību analīze un komunikācija turpmāk būs Requirements and Design analysis, kā arī BA uzlikts par pienākumu par to domāt. Bet! Ar to nevajag saprast tehnisko projektējumu – bet to, ka līdz šim teorētiķi centās – why vs how u.c. veidi – novilkt līniju, kad beidzas prasības un sākas projektēšana. Tagad šī līnija ir izpludināta. IT projektos tas ir uzskatāmāk, bet vairāk grūtību bija cita veida projektos, piemēram, klasiskajā biznesa analīzē prasību analīzes rezultāts arī pirms tam praksē nebija „esmu secinājis, ka vajag uzzīmēt procesu X” – tāpat jau rezultātā bija uzzīmēts tas process X.

Dizaina detalizācija nav noteikta, bet ir maigi definēts vispārīgums – …might… at some level….

“Designs are usable representations that focus on both the solution and an understanding how value might be realized by a solution if it is built.”

“…business analysts are also responsible for the definition of design, at some level, in a change initiative.”

IT gadījumam ir piebilde, ka

“They define requirements to a level of technical detail that will be used as part of solution design and input into technical design.”

P.S. Tā kā par šīm robežām šķēpi tiek un tiks lauzti, pielieku ilustrācijai bildi ar piemēriem no BABOK v3 sākumversijas, cik trausla un nedefinējama ir robeža:

Req

Starp citu, pie BA vēlamajām īpašībām pievienotas:

  • Conceptual Thinking
  • Visual Thinking
  1. Veikts biznesa analīzes izpratnes un veikšanas standartizācijas mēģinājums – Business Analysis Core Concept Model (BACCM), a model of six terms that have a common meaning to all business analysts and helps them discuss business analysis using a common terminology. Katras nodaļas sākumā ir tabula ar šīs nodaļas saturu caur šo pamatkonceptu prizmu. Kā iepriekš lasījāt, tie parādās arī pašā biznesa analīzes definīcijā.

BACCM

  1. Līdz šim BABOK-am pārmests, ka tas vairāk asociējās ar IT risinājumiem. Lai BABOK un biznesa analīzi padarītu vispārīgāku, pievilcīgāku, lasāmāku plašākai auditorijai – mārketingam, korporāciju stratēģiskajām analīzēm, dažādiem IT u.t.t., ieviestas t.s. perspektīvas, kurām biznesa analītiķi pievieno vērtību, un aprakstīts, kā lasīt BABOK nodaļu saturu caur šo perspektīvu prizmu.

Piemēram, ja Tu esi IT BA, tad Tavā gadījumā:

  • Strategy Analysis – lasi ar domu, ka Tev tas palīdzēs izanalizēt, kā organizācijas izmaiņas ietekmēs IT sistēmas, kā tās tiek pašlaik izmantotas, kā sadarbojas un kā būt nākotnē,
  • Requirements Analysis and Design Definition – izvirzīt prasības risinājumam un veikt ne-tehnisku projektēšanu jeb dizainu: piemēram, raksturot, kādus biznesa datus šī sistēma apstrādā,
  • Solution Evaluation – novērtēt, vai izmaiņas IT sistēmā saderēs ar uzņēmuma procesiem.

Perspektiva

  1. Iepriekšējā versijā smagnējā un ne visai intuitīvi saprotamā Enterprise analysis nodaļa (mēdzām to voluntāri interpretēt kā projekta uzsākšanas priekšdarbus), kā rezultāts bija neiztulkojamais Business Case, tagad nomainīta uz Strategy (dažās v3 iterāciju redakcijās pat bija Situation) Analysis un beidzot ir skaidrs, ka attiecināma uz praktiski jebkādu analīzi:

„…can be conducted on the enterprise on the whole, or at any level or on any component of the enterprise. Every change, no matter how large or small, must be driven by a strategy…”

kā arī rezultātu loks paplašināts – var būt plāns, arhitektūra, vīzija, TO-BE procesu modelis u.c.)

  1. Cauri vijas palielināta savstarpējas cilvēku sadarbības (collaboration) nozīme. Pirms tam bija uzsvars vairāk uz izzināšanu, iztaujāšanu un rezultātu apkopošanu, tagad ir uz sadarbību. Tas parādās arī niansēs, piemēram, no komunikāciju prasmēm izņemts Teaching, bet pievienots Non-Verbal Communication un Listening. Pie sadarbības prasmēm pievienots Teaching unNegotiation and Conflict Resolution. Lai attīstītu sadarbību, ieviesti jauni paņēmieni – Personas, Collaborative Games.
  1. Kopumā pievērsta ievērojami lielāka uzmanība izmaiņu pārvaldībai un glosārijā ieviesta definīcija: “A controlled transformation of the enterprise.”
  2. Papildināts un pārskatīts paņēmienu jeb tehniku saraksts – izmaiņu ir daudz. Bija 34, tagad ir 46. Jaunās vai mainītās:
    • Backlog Management
    • Balance Score Card
    • Business Capability Analysis
    • Business Model Canvas
    • Collaborative Games
    • Glossary (izdalīts ārā no Data Dictionary)
    • Decision Modeling
    • Item Tracking
    • Problem Tracking
    • Reviews
    • Risk Analysis and Management
    • Roles and Permissions Matrix
    • Scenarios (izdalīts ārā no Use Cases)
    • Stakeholder List, Map, or Personas
    • Workshops (bija Requirements Workshops)

Tagad BABOK kā lasāmgabals ir kļuvis lasāmāks, jo pirms tam jau tepat blogā kreņķējos, ka BABOK nepieradušam lasītājam patiešām var šķist visai garlaicīgs.

Bet vai un kā tas līdzēs personīgajā izaugsmē un eksāmenā – ceru, ka par to pastāstīs tie, kuri mācīsies un kārtos pēc jaunā. Lai izdodas! :-)

Advertisements

Mans viedoklis:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: