Vem är detta skrivet för? 

Det är skrivet för alla som vill börja jobba med analytics, vi kommer gå igenom grundläggande arbetsmetodik för att arbeta med analys (det kan vara allt från att bygga en rapport för dina KPI:er till en avancerad prediktiv modell). Vi kommer förutsätta att du har en viss förståelse för vad “agile” är men kommer ändå gå igenom hur det förhållningssättet kan appliceras på “analys”. Känns de bitarna för triviala så kan du hoppa över det. Texten är skriven från “faciliterarens” perspektiv men kan läsas av alla. 

Bakgrund – Kärt barn har många namn

Den här metodologin utvecklades i sitt första utförande under ett uppdrag för en större aktör inom försäkringsbranschen och fick då namnet “BIP!” (Behovsanalys, Information Modellering och Prototyping) men har sedan dess utvecklats och kallas numera “Agile Analytics”. Den undervisas också som del av SAS Institutes Analytics Value Training Program.

Försäkringsbolaget i fråga hade likt många organisationer utmaningen att översätta affärsbehov kring analys till faktiska rapporter som skapar affärsvärde på ett effektivt sätt. Ledtider blev ofta långa och i slutändan missades många behov trots den långa utvecklingstiden. För att åtgärda detta så skapade vi ett nytt agilt arbetssätt där vi komprimerade arbetet i korta iterationer där vi fokuserade på de mest värdeskapande behoven först. 

Syfte

Huvudsyftet med denna metodologi är att snabbt fånga affärsbehoven kring analys, omvandla till en konkret informationsmodell & prioriterade affärsfrågor, kartlägga mot källdata och bygga en prototyp för att snabbt kunna få feedback från slutanvändaren. En iteration behöver inte ta mer än några timmar om arbetet är förberett i förväg.

Behovsanalys (WS)

En behovsanalys är en öppen djupintervju i workshop format som vi genomför för att fånga nyckelkoncept, deras beskrivningar och deras interna relationer. När vi genomför denna är det viktigt att ha ett öppet sinne, då det är ett väldigt öppet format för att få kunden att berätta så mycket som möjligt. Vi arbetar i WSens tidiga fas med öppna frågor så att vi verkligen fångar vad som är viktigast för kunden. I takt med att vi börjar få en bättre bild av vad för information som täcker deras behov så kommer vi ställa fler stängda frågor för att få tydligare avstämning kring att vi har en gemensam bild. 

• Slutna frågor börjar ofta med “Har du …?” eller “Är det / Är du …?” och har som syfte att framkalla ja- och nej-svar eller konkret information.
• Öppna frågor börjar med frågeord som “Hur”, “På vilket sätt”, “Vad” eller “Berätta”. Denna typ av frågor visar att du är intresserad av hur personen tänker och känner kring samtalsämnet. Det ger personen tal- och tankeutrymme och bjuder in till att berätta om det som är aktuellt och viktigt.

Lyssna efter substantiv, verb och adjektiv, ofta översätts verben till händelser som är relevanta och substantiven till dimensioner i senare modeller. Var även vaksam efter ord som repeteras ofta, det är en stark indikation på att det är ett begrepp som betyder något viktigt för verksamheten.

Det är viktigt att låta verksamheten tala fritt under mötena, it ska inte styra samtalet eller fundera på om det verksamheten säger passar in i existerande data eller modeller. Utan låta verksamheten tala fritt, men ställa öppna frågor för att få mer insikt kring exakt vad de olika begreppen betyder.

Exempel: 

Sluten fråga:

• Behöver du det här datat?

Öppen fråga:

• Hur har du tänkt att använda det här datat?

Vad gör vem hur när och var?

Krasst så är det detta vi vill ha svar på när WS:en är över, men vi behöver ta det i bättre takt än att bara kasta ut frågan på det sättet givetvis, vi behöver förstå: 

Vad?

• Vad vill man mäta egentligen? Vad är det för fenomen/event?

Vem?

• Vem utför handlingen som orsakar fenomenet/eventet? Vem är det som är intresserad att följa? Varför?
• Vi letar samband här och motivation till varför det är intressant att mäta informationen.

Hur?

• Hur inträffar fenomenet/eventet? Hur många? Hur ofta? Hur mycket?

Var?

• Var händer fenomenet/eventet? Detta är relevant om du har den typen av händelse

När?

• När inträffar det? Med vilken frekvens?

Viktig fråga som verksamheten behöver ta med sig: Varför behöver vi svar på de här frågorna? Vad är affärsnyttan för detta? Vad ska verksamheten göra med informationen?

Verktyg du kommer använda: Om det är fysiskt, post-its, om det virtuellt verktyg som miro eller Lucidspark. 

Output från mötet:

1. Grov skiss på informationsmodell på “postit-nivå” 
2. En prioriterad lista på deras viktiga affärsfrågor som ska vara specifika nog för att kunna skapa visualiseringar kring

Checklista inför & under mötet: 

1. Kom förberedd, var påläst på vad kundens affär är
2. Inled mötet med att dela med dig av din uppfattning av vad scopet för mötet är, du kan provtrycka det extra genom en negerande fråga av typen “Vad i denna presentation av scoopet tycker ni inte stämmer?” Detta tvingar kunden att tänka till. 
3. Glöm inte: Assumption is the mother of all fuck-ups, anta inte att du kan deras affär bättre än de, troligtvis kan du inte det så var öppen och undvik att ankra kundens tankebana i din egen när du leder WS:en. 

Informationsmodellering

Detta är en aktivitet vi gör internt, men vi använder första WS:en för att börja förstå detta. Men vad är en informationsmodell och hur skiljer den sig mot Begreppsmodeller och Datamodeller? 

Nedan bild beskriver de olika modelleringstyperna, deras syfte och hur det dokumenteras. Det enda jag personligen skulle vilja lägga till på denna strikta definition är att en informationsmodell också är ett kommunikationsverktyg och inte enbart ett kravställningsverktyg. 

Informationsmodellens byggstenar och notation

• Entiteter
  — Våra huvudobjekt, under intervjuerna så framgår dessa ofta som substantiv som repeteras ofta under samtalet. 

• Relation
  — Relationen mellan olika entiteter, under intervjuerna så framgår dessa ofta som verben i relation mellan de olika entiteterna.

• Attribut
  — Egenskaper som entiteterna har, under intervjuerna så framgår dessa ofta som adjektiv som beskriver de ofta förekommande substantiven

Hur vi dokumenterar en informationsmodell: 

Det finns lite olika sätt att göra det på, men tydlighet och enkelhet är viktigast för en informationsmodell, kund som aldrig sett en IM tidigare ska snabbt kunna förstå hur sin verksamhets information hänger ihop.

Output från denna aktivitet: 

1. En digital version av informationsmodellen du började bygga under första WS:en
2. Renskrivna och tydliggjorda affärsfrågor, du kan behöva att ta kortare samtal med kunden för att bekräfta att du förstått rätt. 

Checklista under denna aktivitet: 

1. Är du osäker på något, ring kund. Sannolikt har kunden inte varit tydlig och kan behöva hjälp att definiera
2. Acceptera inte vagheter i definitioner, om du gör det så kommer det bli ett problem senare när du blir tvungen att kartlägga mot data. Det kan vara så att kunden inte lyckas ge en skarpare definition, då behöver du göra en anteckning av detta för att under den prototypande fasen visa hur olika definitioner ger olika utfall. 
3. Agilt mindset hela tiden, behöver inte vara perfekt, vi ska ha en iterativ och experimentell tillvägagångssätt för att skapa så mycket värde som möjligt på kortast tid.

Kartläggning mot datakällor (WS)

I detta läge så har du idealt en hyfsat bra informationsmodell, du behöver absolut inte ha alla attribut men de viktigaste attributen som hjälper till att svara på den prioriterade listan av affärsfrågor bör finnas och du måste ha en god uppfattning om vad de olika entiterna, attributen och relationerna betyder. 

Syftet med denna WS som “affären” egentligen inte behöver vara med på, är att kartlägga vilka datakällor, tabeller och kopplingar vi behöver göra för att kunna svara på affärens viktigaste frågor. 

Verktyg du kommer använda: Om det är fysiskt, whiteboard där du ritar upp den digitala informationsmodellen (underskatta inte värdet av att ha den uppritad) , om det virtuellt verktyg som miro eller Lucidspark. 

Output från mötet:

1. Lista på datakällor
2. Mappning om möjligt mellan KPI:er och datakällor och dataset
3. Eventuella integrationer vi kommer att behöva implementera

Checklista inför och under denna aktivitet: 

1. Kom förberedd, var påläst på vad kundens affär är.
2. Inled mötet med att dela med dig av din uppfattning av vad scopet för mötet är, du kan provtrycka det extra genom en negerande fråga av typen “Vad i denna presentation av scopet tycker ni inte stämmer?” Detta tvingar kunden att tänka till. 
3. Skapa dig en uppfattning om vilka system som datat du behöver få svar på ligger i, detta görs enklast 
4. Be kundens IT-team skicka över datamodeller för de system som du tror är relevanta för att kunna svara på affärsfrågorna du har listat tillsammans med kund.

Prototyping

När du väl har ditt data inne, så kan du snabbt bygga upp en prototyp på datat, i det här läget har du de prioriterade affärsfrågorna, informationmodellen, definierat de första KPI kandidaterna och har en idé kring vad för data som kommer krävas för att skapa visualiseringarna. När du prototypar dashboarden så kommer du troligtvis upptäcka att du behöver göra justeringar, vilket blir ännu mer kännbart under nästa steg när du sitter med mottagaren.

Såhär vet du vilken typ av graf som (brukar) passar vilken typ av data:

Detta utgör basen, sedan finns det mer avancerade typer av grafer som kan passa mer snäva användningsområden såsom wordclouds, heatmaps, diverse kartor och sankey-diagram. Detta kan vara överkurs i en första iteration då du vill hålla det så enkelt som möjligt, kom ihåg det viktiga är att få feedback snabbt kring om vi arbetar med rätt data, KPI:er och definitioner då det är dessa som kommer vara mest tidskrävande att bygga data-transformationer för. 

Presentation & Feedback session (WS)

Under denna session så är det fokus för “affären” att ge feedback på den prototyp vi byggt tillsammans. 

Syftet med denna WS är att identifiera om vår prototyp duger som en första MVP att gå i produktion med, samt vad för nästa steg vi bör genomföra förutom produktionssättning.

Verktyg du kommer använda: Om det är fysiskt, skärm, whiteboard där du ritar upp den digitala informationsmodellen (underskatta inte värdet av att ha den uppritad) och skriver upp affärsfrågorna som fångades under behovsanalysen, om det virtuellt verktyg som miro eller Lucidspark. 

Output från mötet:

• Är prototypen good enough att gå över till produktion med som en MVP? Om nej, vad behöver vi förändra / förbättra / lägga till? 
• Skapa några nya “next step” som vi kan lägga till i backlogen för utveckling efter att MVPn är implementerad.

Checklista inför och under denna aktivitet: 

Viktiga frågor att lyfta upp under denna workshop är: 

• Svarar dashboard-prototypen på de affärsfrågor som vi identifierade under behovsanalyssteget? Om nej, vad har vi missat? 
• Kan vi identifiera lågt hängande frukter redan nu i termer av förbättringar? Håll utkik efter saker som är lätt att implementera direkt i visualiseringsverktyget och enklare affärsregler, segment eller liknande som skulle kunna läggas till. 
• Ibland kan det bli så att när affären ser sitt data så får de
• Nya idéer på vad de skulle vilja se implementerat, fånga upp dessa och prioritera de på plats. 
• De inser att just det som de bad om kanske inte var så viktigt ändå men om de bara fick X så skulle det bli värdeskapande. 

Avslutningsvis

Vi har sett en metodologi här som kan användas för att på ett agilt sätt faktiskt fånga och utveckla analysbehov. Mycket av framgången i arbetssättet kommer bero på faciliterarens förmåga att både engagera och avgränsa. Det är viktigt för alla parter att ha fokus på vad som är viktigast att lösa just nu, typiskt sätt så är det bra att försöka fånga lågt hängande frukt som skapar mycket värde för affären, spara de mer komplicerade kraven till senare.