article

Vad exakt gör en Business Analyst?

Av Henrik Attefors

Hur förklarar du för folk vad det är du gör om dagarna om du jobbar som Business Analyst? Frågan uppstår ofta på bröllop och andra sociala tillställningar när du kortfattat ska presentera dig själv för någon du aldrig träffat. Först låter det som en enkel fråga, men när man väl ska ge sig in på att förklara blir det bara krångligt. 


Så vad är det egentligen en Business Analyst (BA) gör om dagarna? En viktig syssla en BA utför är att hjälpa till att kommunicera och dokumentera komplexitet. Om vi ska anpassa det temat till frågan ovan, kan det vara till hjälp att bryta ner BA-rollen i små vettiga bitar och se vilka, om några, når fram till publiken. 

Du skulle till exempel kunna säga: 

  • Jag dokumenterar idéer, design och beslut 
  • Jag sitter i en massa möten och säger “Skulle du kunna förklara lite mer?” 
  • Jag får tillfälle till att tala många olika språk 
  • Jag möjliggör förändringar 
  • Jag leder diskussioner och förhandlar 


Att lära sig att säga “skulle du kunna förklara lite mer?”

Från verksamhetsexperter till utvecklare, portföljansvariga och processägare - ja, en BA’s repertoar av samarbetspartners är bred. 

Om vi definierar projektmiljön som en Business Analysts primära arbetsområde och sedan omger den med de viktigaste affärsom¬rådena som kan påverka projektets utformning, så ser vi att en BA behöver samarbeta med representanter från affärsverksam¬heten, den operativa verksamheten, den strategiska verksam¬heten samt IT-verksamheten. 

Att omges av experter inom respektive domän kan vara jobbigt för en oerfaren BA, speciellt i början av projektet då folk inte känner varandra och man fortfarande bygger upp relationer och förtroenden för varandra. 

Som en konsekvens kan det vara ännu jobbigare att konstant behöva ställa “dumma frågor” för att kunna ta till sig och förstå problemområdet. Men det är just förmågan att effektivt kunna säga “skulle du kunna förklara lite mer?” som en BA behöver utveckla eftersom det tillåter alla parter att samlas kring en mer fokuserad och relevant diskussion. Genom att be dessa experter att repetera och/eller förtydliga vad de sagt, så kommer de allt närmre Albert Einsteins citat, vilket blir till fördel för hela gruppen: 

“Om du inte kan förklara något på ett enkelt sätt, förstår du det inte tillräckligt väl.” 

Att prata flera olika språk 

Varför behöver en BA be intressenter att förklara sig flera gånger om? En av anledningarna är att intressenterna inte bara har olika mål, agendor och kunskaper som de vill kommunicera – de kommer också förmodligen från olika områden inom företaget och använder därför olika metoder och språk för att kommunicera. 

Om vi åter igen tittar på en BA’s primära arbetsområde, denna gång med fokus på hur planering hanteras och beskrivs inom olika angränsande domäner, upptäcker vi att affärsstrategidomä¬nen kommer att vilja definiera förändringar av verksamheten och dess övergripande arkitektur utifrån tre tidsperspektiv – lång sikt, medellång sikt och just nu. De två sista perspektiven återspeglas sedan i både projektet och verksamheten och deras planering.

Affärsdomänen är till för att balansera input från strategi- och den operativa domänen med sina egna portföljsplaneringsmål och nyckeltal.

Samtidigt baserar den tekniska domänen sin planering och sina beslut på de olika strategier de har ombetts att verkställa. 

Som Business Analyst bör man känna till och förstå syftet med varje planeringsverktyg (t.ex. TOGAF, Business Model Canvas och ITIL) och helst också den faktiska metodologin som används för att skapa leverablerna. Genom att känna till anledningen och syftet med dessa olika språk kommer en BA att kunna tolka vad varje domän behöver och hjälpa till att skapa en större förståel¬se mellan dem. 

Att agera som rådgivare och förhandlare 

Det är inte ovanligt för en BA att börja dagen i ett stående projektmöte, tillbringa tiden fram till lunch med att facilitera en workshop för användare, och eftermiddagen med att förse högsta ledningen med förslag för strategiska förändringar. I dessa möten kan en BA både representera de olika intressenter¬na och deras krav, eller själv vara en aktiv intressant, delaktig i utvecklingen av strategier och leveranser för organisationen som helhet.
 
En BA kan därför hamna i en situation där önskemålen från ett möte står i direkt konflikt med de som uppkommer i nästa möte. Särskilt vanligt är det att man måste prioritera krav-och affärsmål gentemot teknologi-principer och mål, och konflikten som ligger i att implementera förbättringar i en process eller ett system som inte ligger inom den långsiktiga eller mellansiktiga strategin. 

En BA axlar ett tungt ansvar och ett stort förtroende genom att ha en sådan tydlig bild av intressenternas behov. Därför behöver man som BA lära sig hur man ska verka i en politisk miljö utan att bli en symbol för konflikten. 

För att kunna göra detta behöver man som BA agera yrkesmäs¬sigt för att framställa sig som pålitlig och förtroendeingivande. Ju högre uppsatt en BA är, desto tydligare blir detta. Vid stora organisationsförändringar sitter en BA ofta i en sits där denne starkt kan påverka slutresultatet och förstå effekten av besluten redan innan de har gjorts offentliga. 

Förhandlingsaspekten i rollen blir uppenbar när en BA får uppgiften att medla mellan olika åsikter och vara med vid framtagandet av en gångbar lösning. Med alla intressenter med vid bordet får en BA stå tillbaka med sina egna åsikter och i stället behandla alla parter och deras synpunkter på samma sätt. Det är tydligt att finkänslighet är en önskvärd egenskap hos en BA, men det är även egenskaper som respekt, integritet och god organisationsförmåga som gör en framgångsrik BA. 

Att dokumentera idéer, design och beslut 

En effektiv BA ogillar tvetydighet. På grund av detta kommer en rad olika modelleringstekniker att användas under projektets gång. Modellering förser BA med ett snabbt (och förhoppnings¬vis enkelt) sätt att bli av med tvetydigheten i vanligt språk, t.ex. i email, genom att skapa visuella representationer av det som diskuteras. 

Syftet med och utbudet av modeller är stort - från post It-lappar och whiteboards till UML-klassdiagram. 

Om vi nu åter igen tittar på BA-området, denna gång med de “saker” inom verksamheten som vi vill fånga och modellera, ser vi snabbt att BA kommer att behöva en stor verktygslåda med modeller, tekniker och notationer till hands. 

Ingen enstaka modell kan lyckas med att förklara allt. Olika intressenter har olika intressen och behöver därför olika vyer av problemdomänen för att få hjälp att förstå hur deras intressen påverkas. Modellering hjälper oss genom förenkling och abstraktion att dölja de detaljer som förhindrar att andra domäner förstår vad vi vill säga, och leder därmed till mer fokuserade diskussioner. 

Allt eftersom projektet fortskrider, förflyttas användningen och syftet med modellering från att främja förståelse till att förse oss med input till arkitekturdesign och framöver faktiska specifika¬tioner och testleverabler. 

Inom erfarna utvecklingsteam har man ofta slutat att använda skriftliga specifikationer eftersom backlogs, epics och andra agila leverabler har minskat tiden det tar att förverkliga ny funktionalitet. 

Trots detta behöver krav vara entydiga och för vissa industrier och produkter är skriftliga specifikationer ett måste för att ens påbörja utvecklingen. 

Hur kraven än är nedskrivna måste de vara testbara och därför i sin tur specifika, objektiva och mätbara. Ett krav måste vara tydligt definierat så att man i slutändan kan bevisa att det uppfyllts.

Modellering är ett väldigt effektivt sätt att uppnå detta.

Att vara den som möjliggör förändring

En Business Analyst har förmågan att möjliggöra förändring i högre grad än de flesta roller i en organisation.

Medan projektledaren förser projektet med de mekanismer som behövs för att det ska lyckas, tar du som BA ansvar för att den levererade förändringen möter intressenternas krav.

Den nya versionen av BABOK v3 speglar detta mantra genom att definiera Business Analysis som: 

”Business Analysis möjliggör förändring i en verksamhet genom att definiera behov och rekommendera lösningar som levererar värde åt intressenter”

Inte allt arbete som en BA utför hamnar under definitionen av Business Analysis ovan, och andra roller utöver BA-rollen utför absolut sysslor inom Business Analysis. Men det är “definitionen” av vad en BA gör genom facilitering, kommunikation och dokumentation som möjliggör förändring.

De viktigaste färdigheterna för framgång

Så med tanke på dessa beskrivningar av vad en BA gör, vilka specifika kompetenser borde en BA försöka förbättra?

Facilitering

Behovet av att agera som en facilitator dyker upp nästan dagligen för en Business Analyst. Därför bör detta ses som en nyckelförmåga man bör bemästra. 

En Business Analyst måste vara bekväm i rollen att sköta processerna och strukturen för en workshop eller ett möte så att man effektivt når uppsatta mål. En BA’s roll som facilitator foku¬serar på agenda, processer och dynamiken mellan deltagarna under mötet, vilket i sin tur låter deltagarna fokusera på ämnet för mötet. 

För att uppnå detta måste en Business Analyst ha inblick i: 

  • Olika intressenters personlighetstyper och hur de reagerar i en gruppmiljö
  • Olika tekniker för utfrågning och aktivt lyssnande
  • Hur tekniska hjälpmedel kan användas under både fysiska och virtuella möten

En BA behöver också en rad olika tekniker som gör det möjligt för grupper att: 

  • Identifiera känd information
  • Skapa nya idéer
  • Uppmuntra konversationer som engagerar och skapar
  • Planera
  • Prioritera
  • Lösa problem
  • Nå överenskommelser eller tydliggöra meningsskiljaktig¬heter
  • Lära sig tillsammans
  • Arbeta i större workshops

Att ge klarhet

En BA behöver dokumentera allt möjligt medan projektet går från förstudie, till planering, till utförande och in i införande-fasen. Detta görs för att skapa en tydlighet och en gemensam bild för alla intressenter.

Detta behov av klarhet ställer höga krav på en BA att förstå syftet med både vem informationsmottagaren är, vad som är viktigt för dem och hur detta står i relation till fasen som projektet befinner sig i.

Projektfaser

Förstudiefasen – definierar förändringen som möter affärsbehovet. Förstår och bedömer den nuvarande affärssituationen, definierar dess framtida situation och samlar och motiverar initiativ som levererar förändring. 

Planeringsfasen – definierar och kommunicerar projektstrukturen, bekräftar affärsbehovet samt metod för och omfattning av lösningen till berörda intressenter. 

Utförandefasen – specificerar och modellerar, organiserar och prioriterar kraven. Definierar antaganden och restriktioner, och skapar till sist en referenspunkt (baseline) samt hanterar versioner.

Utrullningsfasen – tar hand om en smidig övergång från utvecklad lösning till användning inom organisationen. Marknader och teknologier förändras snabbt så en BA behöver hålla koll på både nuvarande möjligheter och kommande tillfällen/hot, både internt och externt, som skulle kunna påverka situationen negativt eller positivt.

Organisering

BA’s behöver ha tillgång till flera verktyg. Vi har sett de olika “saker” som kan behöva modelleras och det breda utbudet av intressenter som dessa modeller skapas för. Att ha en uppsätt¬ning etablerade tekniker och modeller färdiga att använda och sedan återanvända ökar inte bara en BA’s kompetens i att använda dem utan skapar också en känsla av förtrogenhet hos intressenter som använder dem. Denna förtrogenhet ökar även intressenternas förtroende för BA’s färdigheter.

Medan en BA nödvändigtvis inte kan påverka stödet från en sponsor, så är de områden som de faktiskt kan påverka många, speciellt inom kravområdet. Att övervaka projektets omfattning, etablera effektiv kommunikation och att engagera intressenter¬na är alla nyckelfaktorer för ett projekts framgång. Dessa områden, tillsammans med hur krav identifieras, definieras, dokumenteras och leds, är del av den kravmetodik som en BA måste sätta samman.

Att ha ett organiserat och metodiskt sätt att arbeta kommer inte bara att göra det lättare och snabbare för en BA att slutföra sina sysslor utan kommer också att förbättra kvaliteten och underlätta så att leverablerna accepteras. Detta kan ske genom:

  • konsekvent kravdokumentation
  • att använda metodologier och tekniker på lämpligaste sätt
  • att se till så att miljön tillåter förändring att ske på ett kontrollerat sätt
  • en känsla av stabilitet och organisering kring kravarbetet

Sammanfattning

“Kunden vet inte vad de vill ha” – så ofta som det sägs måste det ligga lite sanning i det. Mer troligt är att kunden inte vet hur man uttrycker sina behov på ett språk som är gemensamt för dem och den som har ansvaret att agera för att uppfylla behoven.

Genom att utveckla de förmågor som diskuterats här kan en BA framgångsrikt hjälpa till i kommunikationen genom att underlät¬ta och förenkla diskussioner, framföra en djupare förståelse och möjliggöra att de rätta ändringarna utförs på ett yrkesmässigt sätt. Och genom att göra detta kan du nog också svara på frågan “vad är det du gör” lite mer självsäkert och kortfattat.

Referenser:

IIBA BABOK V3

PMI State of the Industry

PMI BA Practice Guide

Modern Analyst - Glenn R. Brûlé 

Business Analysis in Practice
– förbereder dig för certifiering och BA i praktiken

Ta del av Biners mångåriga erfarenhet av hur BA-rollen har utvecklats och förbered dig för en certifiering!

Kursen Business Analysis in Practice är på tre dagar och ger dig en fantastik inblick i hur morgondagens verksamhetsanalytiker måste förstå och behärska verksamhet, teknik, arkitektur och människor men framför allt hur dessa måste samverka. Kursen ger dig även poäng och möjlighet att certifiera dig i något av de två största internationella standarderna inom Business Analyst området, IIBA’s CBAP och CCBA samt PMI-PBA®. Under kursen går vi också igenom processen för certifiering.

Kontakta oss för mer information eller läs mer om våra utbildningar.


Kurser