Artikel av Hans Jonasson, CBAP, PMP
Författare av ”Determining Project Requirements” en källa för BABOK 2.0
Project Management Institute (PMI) startade för över fyrtio år sedan med målet att förbättra projekthantering
samt att skapa ett gemensamt språk för projektledaryrket. Sedan dess har projektledare runt om i världen
gått från att endast ha en biroll i företagets verksamhet till att ha blivit en erkänd och efterfrågad yrkesgrupp
med egen identitet och egen karriär. Hittils har över 300 000 projektledare framgångsrikt genomgått PMI:s
certifieringsprocess och därmed förbättrat sin professionella status och sin enskilda karriär.
News and Features
Business Analysis –
Vad är det och hur påverkar det oss?
Så vad var det PMI gjorde? De definierade och standardiserade de processer och tekniker som använts
för att leda projekt för att ta fram eller förbättra produkter och tjänster. De hjälpte till att förbättra tidsplaner,
kostnadsplaner och kvaliteten på projekten. Det finns givetvis ett värde i detta, men om produkten som
tillverkades var fel eller inte mötte kundkraven hade man bara lyckats göra fel sak fortare, billigare och med högre
kvalitet. Det är här Business Analysis blir relevant för projektledaren; Business Analysis handlar just om att skapa
rätt produkt –vilket ger ännu större värde i det långa loppet. Det är business analystens jobb att dokumentera,
samla in och analysera vad som är rätt sak (produkt eller tjänst).
År 2003 bildades The International Institute of Business Analysis (IIBA). Starten kom i slutet av en
projektledarkonferens i Toronto när några av organisatörerna diskuterade konferensen och dess resultat.
De insåg att ett stort antal av deltagarna inte var projektledare utan business analysts, men det fanns ingen
passande konferens eller organisation för dem. Så IIBA skapades och har idag har de runt 18 000 medlemmar
världen över och över 1200 är Certified Business Analysis Professionals (CBAP).
Låt oss börja med att definiera Business Analysis och jobbet som en Business Analyst gör. Business Analysis är
ett uttryck som används för olika arbetsuppgifter, vilket kan skapa förvirring. Det handlar om de arbetsuppgifter
och tekniker som används när vi vill förstå en organisations struktur, dess verksamhet och kultur för att kunna
rekommendera lösningar som låter organisationen nå sina mål inom fastställda ramar. En Business Analyst
arbetar för att samla in information och krav från omgivningen, organisationen och intressenter. Business
Analysten organiserar och dokumenterar sedan sina fynd och ser till att kraven kan spåras till ett affärsbehov
samt att alla lösningar matchar de identiferade kraven.
IIBA:s mål är att förbättra och standardisera business analysis metoder och att informera om arbetsområdet.
De gör detta genom att identifiera de huvudsakliga kunskapsområden som är en del av business analysis och
identifierar ”best practices” för dessa områden. Detta borde avsevärt hjälpa business analysterna i deras dagliga
arbeten. Kunskapsområdena har blivit dokumenterade i “A guide to the Business Analysis Body of Knowledge”,
ofta förkortat till ”the BABOK guide”.
Varje kunskapsområde täcker mycket material och det skulle gå att fylla en bok om vart och ett av dem. Målet
med denna artikel är att ge en översyn av områdena som en introduktion.
Copyright ©ESI International 2011
1
News and Features
1. Business Analysis Planning and Monitoring (Planering och översyn av Business Analysis)
I detta kunskapsområde ser IIBA på planeringen av alla business analysis aktiviteter samt överser hur de
genomförs. Vilken business analysis riktning skall organisationen ta med hänsyn till intressenterna och typen av
aktiviteter? För vissa organisationer kan det finnas ett behov av en total företagsanalys, för andra kan det räcka
med intervjuer om systemkrav. Det kan också finnas anledning att utvärdera om business analysis aktiviteterna i
huvudsak skall ligga inom projektarbetet eller inom de funktionella områdena.
Ytterligare en del av detta kunskapsområde är kommunikationsplanering och hantering av ändringsbegäran.
Detta låter som traditionell projektledning, men här ligger fokus på produktomfattning och kravrelaterade
aktiviteter. Det finns dock definitiva överlappningar mellan projektledaren och business analysten. Om vi använder
kommunikationsplanen som ett exempel så kan vi se det som att projektledaren är huvudansvarig, men det är
business analysten som är ansvarig för den delen av planen som handlar om kommunikation för produkten och
för kravutveckling.
2. Enterprise Analysis (Företagsanalys)
IIBA ser detta område i huvudsak som förarbete för projektarbete. Här undersöker vi vad organisationens behov
är, vilka strategiska och taktiska mål som har blivit satta, och vi försöker förstå vilka kunskaper och förmågor
vi har inom företaget. Detta leder i sin tur till att vi utvärderar riktningen av potentiella initiativ. Skall vi fokusera
på processutveckling? Ett nytt IT system? Eller behöver vi ändra organisationens struktur? Vi tittar här även på
omfattningen av eventuella nya produkter och tjänster.
Den sista delen av analysen är en utvärdering av lösningen för att se om den har värde för organisationen. Vi gör
en total beräkning av nytta jämfört med kostnad och rekommenderar de mest gynnsamma lösningarna.
3. Elicitation (Insamling)
Översättning av “elicitation” är svårt. Ordlistan säger locka fram, ta fram men det beskriver bara en del av
detta kunskapsområde. Insamling av krav kan ske på många sätt. Intervjuer, workshops, frågeformulär och
observation är några av dem. Dessa tekniker för insamling av krav är kanske det vi främst tänker på när vi pratar
om business analystens jobb, men det krävs mer. Valet av insamlingsteknik är kopplat till intressentanalysen,
vilken kommer från ”Business Analysis Planning and Monitoring”. Så trots att varje kunskapsområde är
väldefinierat och unikt, så är de nära relaterade och beroende av de andra kunskapsområdena. Vi kommer att
dyka lite djupare in i insamlingstekniker i en kommande artikel.
4. Requirements Analysis (Kravanalys)
En av de största svårigheterna efter att kraven blivit insamlade är att dokumentera och strukturera dem. Detta
måste göras på ett sätt så att kraven enkelt kan förstås av de olika intressenterna oavsett om de behöver
detaljinformation eller en generell överblick. Olika intressenter har olika krav och de ser ofta produkten från olika
synvinklar, företagsledningen har andra förväntningar än vad produktanvändarna har. Vi kan hantera detta genom
att strukturera kraven. Ett exempel på en kravstruktur är:
• Affärskrav
• Regelverkskrav
• Intressentkrav
• Produkt eller tjänst krav – vilka ytterligare kan delas in i:
o Funktionella (Vad produkten gör)
o Icke funktionella (Till exempel prestation eller säkerhetskrav)
o Installation (Vad behövs för att göra organisationen klar för produkten)
Kategorisering hjälper intressenterna att fokusera på olika områden som i sin tur kan hjälpa att att avgöra vilka
krav som är viktigast.
2
Copyright ©ESI International 2011
5. Solution Assessment and Validation (Utvärdering och validering av lösningen)
Detta kunskapsområde handlar om att utvärdera lösningen för att se hur väl den matchar kraven. Det finns
alltid skillnader - krav som inte kunde mötas, eller som endast delvis uppfylldes. Dessa skillnader måste
dokumenteras.
Dessutom handlar detta område om hur man identiferar vad som måste göras för att implementera produkten
eller tjänsten. Det kan behövas utbildning, organisationsändringar, infrastruktur, och annat. Många projekt som
levererat en utmärkt produkt har misslyckats för att organisationen inte var redo för den.
News and Features
Detta kunskapsområde diskuterar också modellering av krav. Modeller hjälper oss att få en överblick
av produkten och kan vara ett bra kommunikationshjälpmedel. Exempel av modeller som IIBA ser på är
datamodeller, processmodeller och användarmodeller.
6. Requirements Management and Communication (Kravhantering och kommunikation)
Det är viktigt att kunna spåra utformandet av en projektlösning tillbaka till intressentkraven och till projektmålen.
Detta är ett av fokusområdena för detta kunskapsområde.
En organisation har ofta olika produkter men delvis samma intressentkrav. Det är ”best practice” att försöka
återanvända krav så mycket som möjligt. Det sparar tid och hjälper med standardisering.
En annan del av detta kunskapsområde handlar om vetskapen att olika intressenter har olika
kommunikationsbehov. Vi löser detta genom att skapa kravpaket som fokuserar på intressenternas behov. Trots
att vi har ett otalt kravpaket så betyder inte det att alla intressenter måste se och förstå alla krav. Ledningen
behöver inte se detaljer av användarkrav och användare måste inte alltid förstå alla gränssnittskrav.
7. Underlying Competencies (Grundläggande kompetenser)
Detta är det sista kunskapsområdet, men på inget sätt det minst viktiga. En bra business analyst måste ha mjuka
kunskaper och färdigheter inom kommunikation, förhandling och facilitering. De måste också vara duktiga på
problemlösning samt ha en god affärsförståelse. Dessutom kan de behöva kunskaper i mjukvara för att hantera
modellering och dokumentering.
Så vad är framtiden för business analyst yrket?
Genom standardisering från IIBA och certifiering av business analyst, Certified Business Analysis Professional
(CBAP), så kommer business analyst rollen troligen växa och bli mer formell inom organisationer. Om man tittar
på PMI:s bakgrund och tillväxt och jämför den med IIBA så kan man ana ett kommande och växande krav från
kunder och företag på välutbildade business analyster. Det handlar ju trots allt om att se till att projekt gör rätt
saker och möter rätt krav och det är naturligtvis något som alla bör vara positivt inställda till.
Vill du veta mer eller bli involverad så kan du få mer information hos ESI (www.esi-intl.se)
och IIBA (www.theIIBA.org).
Copyright ©ESI International 2011
3