Fra rapporter til innsikt – SpareBank 1 Forskrings reise til å bli en data-drevet organisasjon

9 min read

Forsikring har to priser – en når du kjøper den, og en når det smeller. Kjøpte du den billigste bilforsikringen er det ikke sikkert det totalt sett er en god deal hvis vilkårene ikke dekker det du har behov for når du trenger det.

 

Hann Rygg SortebergAv Hanne Sorteberg, BI teamleder
Forsikring Datavarehus

Sparebank 1 Forsikring AS

 

 

 

Tilsvarende er det to typer kostnader for forsikringsselskaper – de faste og forutsigbare, og skadeutbetalinger som tilfeldige. Å sikre lønnsomhet krever kompetanse på å sette av tilstrekkelig med reserver for å dekke de forpliktelser man har i solgte forsikringsavtaler – aktuarfunksjonen. At en bil som kjøres mye bør koste mer å forsikre enn en bil som kjøres lite kan være innlysende, men er det slik at en rød bil innebærer større risiko enn en som er mørkeblå? Prisanalytikere vurderer de ulike forsikringobjektenes egenskaper og fastsetter hvilken pris som er riktig for selskapet og kunden.

Aktuarer og prisanalytikere er eksperter på statistiske modeller og analyser, og har bruk av data som sin kjernevirksomhet. De er av natur «datadrevne». Dette innlegget handler om hvordan resten av Sparebank 1 Forsikring gikk fra å være en reaktiv bruker av rapporter til en datadrevet organisasjon.

Et tilbakeblikk – 2011:

Alexander jobber i salgsavdelingen. Han er ansvarlig for å følge opp SpareBank 1 bankene som selger forsikring til sine kunder. Det er kommet et nytt forsikringsprodukt, og det er avgjørende å følge opp om dette har suksess, og hvordan det er mottatt i den enkelte bank.

Alexander kjenner Abilasha som jobber i Datavarehus, så det er naturlig å be henne om hjelp. «Jeg trenger en oversikt over det nye produktet – og det haster!» er bestillingen. Abilasha jobber med ETL-utvikling på SAS, og tar fatt på oppgaven. Hun bruker litt tid på å forstå hvilket produkt Alexander mener. Skal han ha dette månedlig eller ukentlig mon tro?

Etter to uker er Excel-rapporten klar, og sendes Alexander på epost. Alexander har ventet utålmodig på rapporten, og har nå kort tid til å forberede en powerpoint til ledermøte og en pdf som skal sendes de ulike bankene. Han åpner Excel-arket – og ser at det ikke er inndelt pr. bank! Rapporten er ubrukelig, og han må tilbake til Abilasha. Hun har tre saker til som haster, men våger ikke annet enn å hjelpe Alexander nå.

Hva var utfordringene i dette scenariet?

  • Brukere av datavarehus har ikke ett sted å henvende seg. Det er ingen logging, oppfølging eller prioritering av henvendelser.
  • Datavarehus leverer ”datauttrekk” som krever manuell tilpasning, distribusjon og gir mange personlige rapporteringsløsninger. De er også tidkrevende å ta frem, og lite blir automatisk generert.
  • Det er stor avstand mellom datavarehus og brukerne av data. Manglende helhetsforforståelse både hos forretning og teknisk side.
  • Uklarhet om krav, begreper og beregningsregler fører til misforståelser og dobbeltarbeid.
  • Manglende eierskap for løsningen hos forretning og datavarehus.
  • Det er ingen strategisk prioritering av ressurser – det er fokus på det som haster, og ikke nødvendigvis det som er viktig.
  • Informasjon brukes ikke aktivt til styring, kun rapportering av historiske data – som ofte er utdatert innen de er tilgjengelig.

2013 – Ny teknologi

I 2013 ble Tableau anskaffet etter en grundig testing av ulike visualiseringsverktøy. Ny teknologi har løst utfordringen med manuelle prosesser og tungvint distribusjon av data. Det er også en klar vinning at analytikere kan gjøre nye funn og bedre analyser med Tableau som verktøy. Allikevel handler alle de andre utfordringene om noe annet enn teknologi – det handler om organisering.

2015 – Ny organisering

Med muligheten til å selv sammenstille data i Tableau vokste frem en ny rolle – Forretningsanalytiker.  Ansvaret for å hente verdi fra data ble flyttet fra datavarehus ut i forretningen. Dette var en rolle som ikke fantes tidligere, og som ble etablert gjennom ansettelser eller kompetanseheving.

For at modellen skulle fungere ble det behov for å definere en tydelig ansvarsfordeling mellom forretning og datavarehus. Det ble etablert rollebeskrivelser, samarbeidsformer og samarbeidsarenaer som utviklet seg over tid.

I dag har Alexander rollen forretningsanalytiker med ansvar for å:

  • Utarbeide kravspesifikasjon med støtte fra Datavarehus
  • Prioritere krav og endringer
  • Avklare definisjoner, begreper og beregninger, i samråd med Data Governance
  • Utvikle løsninger for anvendelse av data. Ofte er dette analyser, rapporter og dashboard i Tableau, men også input til analyseverktøy og statistiske modeller
  • Realisere gevinster av leveransen

Abilasha har rollen forretningsarkitekt i Datavarehus med ansvar for:

  • Design og utvikling av datasett i henhold til prioriterte krav
  • Aktiv forvaltning og videreutvikling av leverte datasett
  • Dokumentasjon av data, begreper og beregninger
  • Aktiv støtte til bruk av datasett

En ny BI-organisasjon

Arbeidsoppgaver og ansvarsområder i en BI-organisasjon har et stort spenn. Noen oppgaver er svært operative, feil må rettes og spørsmål besvares der og da. Samtidig skal man tenke på de store, lange linjene og utvikle seg i en retning som samsvarer med selskapets visjon og strategi.

Noen oppgaver krever dyp forretningsforståelse og detaljert forsikringsproduktkunnskap. Andre krever dyp teknisk forståelse og detaljert kunnskap om tekniske verktøy.

Det er sjelden en og samme person innehar kompetanse som dekker hele dette feltet, og selv om de har det, kan man ikke ha fokus på et så bredt spekter av oppgaver. Spesielt strategiske oppgaver salderes bort til fordel for det operative. Man gjør det som haster, ikke det som er viktig.

Å sørge for at hver stilling ikke har et sett med ansvarsoppgaver som overstiger antall timer tilgjengelig arbeidstid er en viktig faktor for å sikre fokus til den enkelte rolle.

Hvis en ansatt har oppgaver som overstiger full arbeidsbelastning, blir det ofte opp til den enkelte hvilke oppgaver som utføres på tilgjengelig tid, ikke lederens prioriteringer.

I tillegg til at datavarehus har en forretningsarkitekt med ansvar for hvert sitt forretningsområde, er det etablert et «BI Frontteam» med fire roller:

Infoservice mottar og følger opp alle henvendelser og ruter oppgaver til riktig sted (forretningsarkitekt, utviklergruppe, prosjekt, prioriteringsforum). Her overvåkes backloggen, og det tas grep for å balansere etterspørsel og ressurser

Tableau-ansvarlig forvalter Tableau og offisielle rapporter. Tilganger gis, og hun sørger for at sikkerheten ivaretas og regulatorsikre krav til datainnsyn følges. Her bygges og etterleves struktur i leveranser, dokumentasjon og datakilder.

BI-ekspert støtter forretning i bruk av BI-verktøy med kurs og faglig spisskompetanse. Forretningen har ulik grad av behov for støtte, noen trenger en sparringspartner på bruk av avanserte funksjoner, andre må få hjelp til å komme i gang med det grunnleggende. BI-eksperten er leder for analytikerforum som sikrer erfaringsutveksling på tvers, og har også som oppgave å motivere analytikere til ny bruk av datasett de har tilgjengelig. BI-eksperten er radaren for nye teknologiske trender og verktøy.

BI Leder/visjonær har ansvar for strategisk retning og prioriteringer. Hun inspirerer til ny og verdifull bruk av informasjon i de ulike forretningsområdene. BI-visjonær er radaren for bruk av BI som konkurransefortrinn i forsikringsbransjen.

Hanne Sorteberg artikkelbilde

 

Fra vannfall til smidig

I 2011 var datavarehus preget av store prosjekter. Konsulenter hadde rollen som prosjektleder og utviklere. En lang kravspesifiseringsfase med bred involvering av interessenter ble etterfulgt av en utviklingsfase på over et år i «isolasjon». Da testfasen begynte, innså man ofte at kravspesifiseringen ble en for teoretisk øvelse. Det er først når man ser data og skal arbeide med dem, at man forstår hva man egentlig trengte. Overraskelser dukket opp i form av dårlig datakvalitet i kilden, ytelsesutfordringer og sprikende definisjoner. Når konsulentene var reist, var det for sent å justere på leveransen, og det fulle potensialet av prosjektet ble ikke hentet ut.

I 2015 kjøres datavarehusleveransene som en interativ prosess. Kravene jobbes frem gjennom prototyping, der man tidlig henter ut data fra kildene, for å bli kjent med dataene og kvaliteten. Slik kan man tidlig verifisere hva som skal være innholdet i leveransen. Deretter blir det definert kortere faser på noen uker som leverer innhold av verdi for hver fase. Det settes av en ansvarlig fra forretning (forretningsanalytiker) og fra datavarehus (forretningsarkitekt) som følger utviklingen fra krav til forvaltning.

Fra tilfeldig til prioritert

Alle henvendelser fra forretning blir i dag mottatt av Infoservice. Infoservice er både en epostboks, og et fjes som er kjent i organisasjonen. Infoservice vurderer oppdraget og basert på omfanget er det ulike prosesser for prioritering:

Prosjekter: BI Prioriteringsforum er et forum satt sammen av representanter fra hvert forretningsområde. Her defineres den strategiske retningen for datavarehuset, og store utviklingsoppgaver prioriteres.

Endringer og justeringer: Forretningsområdene har hver sin forretningsanalytiker som i hyppige møter med datavarehusets forretningsarkitekt på dette området blir enige om hvilke krav som skal utvikles og hvilken prioritet de skal ha.

Mindre oppdrag løses direkte av utviklingsressurser Infoservice disponerer.

Det enkle er ofte det beste – dokumentasjon og styringsverktøy

Dokumentasjon og oversikt er vanskelig. Tidligere ble det ivrig dokumentert i prosjektfasen, med kravrapporter og statusrapporter. Problemet var at etter at papirdokumentene ble plassert i hylla, var de utdatert. Dokumentasjon av endringer i forvaltning, og oversikt over hva som var tilgjengelig av datasett, ble til en viss grad neglisjert. Noen ganger er det beste det godes fiende. For omfattende dokumentasjon gjør at man ikke orker vedlikeholde den. Det finnes verktøy som støtter, men noen ganger er det verktøyet som definerer prosessen, og ikke omvendt.

Vi har satset på enkle verktøy og maler tilpasset oss, og har lagt ambisjonsnivået på et nivå som er mulig å holde oppdatert, og som allikevel er godt nok.

  • Confluence benyttes som dokumentasjon av leverte løsninger. Et standardisert oppsett gjør det lett å finne frem til feltdefinisjoner, sikkerhetsløsninger og forvaltningsrutiner.
  • JIRA benyttes til alle oppdrag, små og store. Her følges sakene fortløpende, og for ad hoc-oppdrag er det her all kode dokumenteres og lagres.
  • For at organisasjonen skal få oversikt over hvilke datasett som er tilgjengelig i datavarehuset, er det laget en Datasettoversikt i Tableau. Tableau brukes også til å rapportere bruk av rapporter.

Hva har vi oppnådd?

Forsikring er alltid datadrevet – utviklingen har gått mot at hele organisasjonen har tilgang til innsikt, ikke bare rapporter.

Ny organisering har skapt en mer effektiv BI-funksjon. Det er tydelig hvordan man kommer i kontakt med Datavarehus. Infoservice gir alltid svar, og følger opp underveis. Vi har etablert tydelige roller, ansvar og prioriterings- og beslutningsprosesser.

Iterativ utvikling gir raskere verdi og mer treffsikre løsninger.

Vi har med ny organisering og bedre struktur fått overskudd til å proaktivt vise frem verdien av data. Data som hjelper oss å ta riktigere beslutninger.

Ha en fin dag.

Hilsen Hanne.

About Arne Rosness

Arne er redaktør av BI-blogg.