Mange selskaper føler et press for å bli datadrevet og vurderer en investering i en dataplattform. Ofte hører man om selskaper som har brukt mye penger på avanserte løsninger bare for å ende opp med “dashboards ingen ser på” eller en datasjø med lite brukt data. Hvordan kan man unngå dette? I denne artikkelen ser vi på en pragmatisk tilnærming til en datasatsing der virksomheter kan komme i gang med data uten å kjøpe en større dataplattform først.
Vi ser på hvordan du kan identifisere et mindre forretningsbehov, teste verdi gjennom pilotprosjekt, velge fleksible teknologier og legge en plan for skalering. Vi må også være obs på feil og utfordringer og så vi ser på det med et eksempel.
Start med et mindre forretningsbehov som utgangspunkt
Det første steget i en datasatsing er å definere hvorfor dere gjør det. I stedet for å samle “masse data først og håpe på verdi senere”, bør dere ta utgangspunkt i et konkret forretningsbehov eller bruksområde. Spør dere selv hvilket problem ønsker vi å løse, eller hvilken mulighet vil vi utnytte ved hjelp av data?
Ved å knytte data initiativet til et forretningsmål sikrer man at prosjektet har reell nytte. Verdien oppstår først når data tas i bruk for å forbedre beslutninger og prosesser, og derfor må forretningsmålet være riktig og viktig. Start med et høyt prioritert use case som har tydelig potensial, som f.eks for å øke inntekter, kutte kostnader eller redusere risiko og deretter kan dere trekke inn de dataene som trengs for dette formålet.
Prosjektet må også være forankret i virksomhetens strategi og ledelse så sørg for at dere involverer de riktige interessentene på tvers av forretning og teknologi fra dag en og at alle er enige om hvor man starter. Velg et bruksområde som ikke er for stort i omfang, men samtidig viktig nok til å få lederstøtte.
Dette første use caset danner grunnlaget og skal bevise verdien av datasatsingen i praksis.
Test verdien gjennom pilotprosjekt(er)
Når et konkret behov er identifisert bør neste steg være å teste i liten skala før man gjør store investeringer. Dette gjøres typisk gjennom et avgrenset prosjekt som har som mål å bekrefte at en ide eller teknologi faktisk fungerer slik det er tenkt. En pilot går et steg lenger, da det er en mindre utrulling av løsningen i et realistisk miljø som for eksempel i en avdeling eller på et begrenset datasett. Hensikten er å prøve ut løsningen under virkelige forhold for å se hvilken verdi den faktisk leverer.
Piloten skal ha kort varighet og lav kostnad så prøv å tenke på piloten som en mindre versjon av løsningen som gir deg akkurat nok til å måle effekt og samle lærdom. Definer tydelige suksesskriterier på forhånd, hva skal til for at dere sier “ja, dette var verdt det”! Det kan være måltall som f.eks. 10% raskere rapportering, 5% salgsløft i en produktkategori, eller halvering av tiden brukt på manuell datahåndtering.
Under pilotprosjektet gjelder det å ha tett samarbeid med brukerne. Involver de som skal bruke løsningen (analytikere, ledere, saksbehandlere etc) og få deres tilbakemeldinger fortløpende. Et pilotprosjekt skal ikke bare levere tall, men også gi innsikt i hvordan løsningen fungerer i praksis. Typiske mål i en pilot er å teste ytelse og integrasjoner, justere løsningen basert på erfaringer, samt hente inn tilbakemeldinger. Kanskje oppdager man at dataflyten må optimaliseres, eller at rapportene bør visualiseres annerledes og slike justeringer er enklere å gjøre i en pilotfase.
En annen viktig gevinst ved pilot tilnærmingen er at man kan levere verdi raskt. I stedet for å bruke mange måneder på å bygge “den perfekte” plattformen, får man noe opp å stå på uker. Generelt sett så burde man innen noen uker fra oppstart ha noen nye datadrevne muligheter som kan testes av brukere. Dette skaper begeistring internt og bygger en business case for videre satsing. Pilotresultatene, enten det er kostnadsbesparelser, tidsbesparelser eller bedre beslutninger vil være beviset dere kan bruke for å få grønt lys (og budsjett) til neste steg.
Teknologivalg med lav kostnad og høy fleksibilitet
Et fint sted å starte er å velge velge teknologi som har lav inngangsbarriere både kostnadsmessig og i kompleksitet. Unngå fristelsen til å kjøpe de største og mest avanserte systemene fra dag en og i stedet kan dere benytte moderne skytjenester eller kanskje eksisterende systemer dere allerede eier.
Skyløsninger er ofte ideelle for en myk start og de største skyplattformene (Azure, AWS, Google Cloud) tilbyr tjenester der man betaler per forbruk uten store forhåndsinvesteringer. Det betyr at man kan begynne i liten skala til lav kost og så la forbruket og kostnaden øke først når verdien materialiserer seg over tid. Det er fortsatt viktig å forstå hvordan skyløsninger sine kostnader fungerer, men uansett så er et generelt råd om man skal bygge ny infrastruktur å se til skyen først.
På teknologisiden bør man også tenke enkelt fremfor komplisert. Det er lett å anta at man trenger noe som kan håndtere veldig store mengder data eller avansert analyse, men de fleste selskaper har ikke egentlig så store datavolumer og ofte er det snakk om gigabyte eller noen få terabyte med relativt velstrukturert informasjon. Da kan velprøvde løsninger som en relasjonsdatabase (SQL), enkle ETL verktøy (dbt) og et visualiseringsverktøy (Power BI) gjøre jobben utmerket.
Dette handler om fremtidige ambisjoner og det å ha fleksibilitet langsiktig. Velger man et enklere oppsett nå som er enkelt å justere så kan man gjøre forandringer mens man lærer underveis. For noen kan det være smart med et modulært oppsett som kan byttes ut eller skaleres opp, fremfor en større løsning fra en enkelt leverandør. Kostnaden og kompleksiteten ved verktøy som
Kostnaden og kompleksiteten ved verktøy som fungerer for mindre datamengder har gått mye ned de siste årene, så dere kan komme langt med enkle midler før dere eventuelt må ta i bruk tyngre plattformer.
Plan for skalering og bygge videre uten å starte på nytt
Når pilotprosjektet begynner å vise verdi kommer fort neste spørsmål om hvordan går vi fra en liten løsning til en bredere datasatsing i hele virksomheten. Nøkkelen er da å planlegge for skalering helt fra begynnelsen av, slik at dere kan bygge videre på det dere allerede har gjort i stedet for å starte forfra eller gå et par steg tilbake hver gang behovet vokser.
En god metafor er å se for seg datasatsingen som byggeklosser. Først bygger dere en første kloss som er pilotprosjektet med sin løsning. Deretter vil dere bygge flere klosser som er nye use caser med tilhørende data, men det gjelder å sette dem sammen til en større helhet etter hvert. Dette krever at man har tenkt ut en overordnet arkitektur eller retning på forhånd. Det betyr ikke at man må designe alt i detalj, men man bør ha en visjon eller et rammeverk for hvordan ulike dataløsninger skal passe sammen på sikt. Dette kan beskrives som å tenke helhetlig og da ha en formening om hvor data skal lagres, hvordan det flyter, hvilke teknologier som inngår, slik at de små stegene dere tar peker mot samme mål. En slik rød tråd gjør at inkrementelle forbedringer gradvis kan danne et robust fundament og kan justeres underveis i takt med at dere blir klokere av læringen.
I stedet for å lage en større dataplattform for hele virksomheten kan man lage mindre “datamoduler” for hvert behov og knytte disse sammen gradvis til et samlet økosystem. Dette ligner på en smidig fremgangsmåte kontra en fossefallsmetode og fordelen er at hver del leverer verdi underveis og man kan justere kursen fortløpende. Mange erfarne dataarkitekter argumenterer for at dette er en mer vellykket vei til en større dataplattform enn å forsøke alt på en gang. Det agile prinsippet om evolusjonær arkitektur passer godt her så bygg litt, lær, juster arkitektur, bygg videre.
Selv om dere starter med noe midlertidig i pilotfasen så prøv å tenke gjenbruk og skalerbarhet fra dag en. Har dere laget en ny rapport for en avdeling så tenk på om strukturen kan gjenbrukes for andre avdelinger med minimale endringer.
Skalering handler om å bevare momentet fra tidlige suksesser uten å miste fleksibiliteten. Man må finne en balanse mellom struktur og agilitet. På den ene siden viser beste praksis at mangel på en overordnet arkitektur fort kan bli en snubletråd når man vokser så litt strategisk arkitekturarbeid i forkant “betaler seg” når man skal utvide til flere områder. På den andre siden må ikke arkitekturplanleggingen være så rigid at den stopper utvikling og innovasjon.
Vanlige utfordringer ved plattformvalg
La oss se på noen vanlige utfordringer som kan oppstå når man investerer i en større dataplattform før behovet egentlig er der. Mange har erfart at slike feilvalg kan bli både kostbare og tidkrevende å rette opp i senere.
- Manglende forretningsforankring: Den største risikoen er å ende opp med en dataplattform som ikke løser reelle forretningsutfordringer. Uten et tydelig definert bruksområde risikerer man at plattformen ikke leverer som forventet, verken for brukerne eller ledelsen.
- Underutnyttelse og “hyllevare”: Kjøper man en stor løsning med mange funksjoner fra start, vil store deler av funksjonaliteten typisk stå ubrukt i lengre tid. Man betaler altså for mer enn man trenger.
- For høy kompleksitet: Større plattformer fører ofte med seg mer kompleksitet som kan forsinke oppstarten. Oppsett, integrasjoner og opplæring tar tid, og i mellomtiden kan forretningsbehovene ha endret seg. Mange slike prosjekter overskrider både tid og budsjett, og i verste fall blir de aldri ferdigstilt. Start derfor enklere, og bevis verdien først så kan man gradvis øke kompleksiteten.
- Låsing og lite fleksibilitet: Ved å binde seg tidlig til en stor plattform risikerer man leverandøravhengighet og lavere fleksibilitet. Kanskje støtter ikke plattformen fremtidige datakilder eller integrasjoner eller den passer dårlig med andre verktøy. Da kan man ende opp med ekstra kostnader for tilpasninger eller måtte forkaste deler av investeringen.
- Organisatorisk motstand: Til slutt er det verdt å nevne at en toppstyrt plattformanskaffelse kan møte motstand blant de ansatte. Hvis de tvinges på et komplekst nytt system de ikke ser behovet for kan adopsjonen bli lav. Det skaper en ond sirkel der ledelsen lurer på “hvorfor får vi ikke gevinst av dataplattformen” mens ansatte kanskje fortsatt bruker sine gamle Excel ark fordi de synes det funker bedre. En gradvis tilnærming med brukerinvolvering gjennom mindre prosjekter skaper eierskap og entusiasme.
Den største feilen er å kjøpe før man har prøvd. Unngå den ved å snu rekkefølgen så prøv først i det små, kjøp eller bygg mer når det faktisk trengs. Da unngår dere å falle i fellene som så mange andre har gjort.
Eksempelscenario - Fra pilot til plattform i praksis
La oss illustrere denne pragmatiske tilnærmingen med et tenkt eksempel. Tenk deg Ali SkoButikk AS som er en mellomstor detaljhandelskjede. Ledelsen i Ali SkoButikk AS ønsker å bli mer datadrevet og de har hørt om konkurrenter som bruker data for å optimere lager, salg og kundetilbud og vil ikke havne bakpå.
1. Avgrenset behov - Ali SkoButikk AS er en mellomstor detaljhandelskjede som ønsker å bli mer datadrevet. I stedet for å kjøpe en kostbar dataplattform med en gang starter de med to konkrete problemer: overlager og utsolgte varer. Målet er å redusere varelagerverdien med 15 % uten å øke utsolgt andelen. Dette er forankret i selskapets strategi og både logistikksjefen og butikksjefene støtter tiltaket.
2. Pilotprosjekt - De starter en pilot i fem butikker. Salgs og lagerdata fra ERP systemet lastes opp i Google Sheets. En analytiker lager et dashboard i Excel for å visualisere hvilke varer som selger godt og hvilke som står på lager for lenge. Etter to uker har butikksjefene tilgang til en enkel løsning som gir umiddelbare innsikter og i løpet av seks uker reduseres lagerverdien, og tilgjengeligheten på nøkkelvarer øker. Tilbakemeldinger brukes til å justere løsningen underveis som de blir mer vant til å bruke løsningen.
3. Teknologi og kompetanse - Teknologivalgene er bevisst enkle og rimelige. De bruker eksisterende data, skylagring og verktøy de allerede har lisens på og ingen nye investeringer er gjort. Analytikeren kjenner datakildene, butikksjefene er komfortable med Excel så dette gjør adopsjonen enkel og gir rask effekt.
4. Skalering - Når piloten viser gode resultater, utvides løsningen til alle 50 butikker og IT-avdelingen setter opp en enkel database i skyen, og dashboardet flyttes til Power BI for automatisk oppdatering og distribusjon. De legger til flere datakilder underveis uten å måtte endre arkitekturen og med Office 365 på plass er dette både rimelig og praktisk.
5. Eierskap og videreutvikling - Løsningen blir nå en del av den faste driften. Driftssjefen tar eierskap, det etableres faste rutiner for oppfølging, og nye analyser kan enkelt bygges videre inn i løsningen.
Avslutning
Å starte en datasatsing behøver ikke være skremmende eller kostbart, men hemmeligheten ligger i fokus og fleksibilitet. Begynn i det små, lær fort, og skaler det som funker. Da vil datareisen deres være både kostnadseffektiv og bærekraftig og dere unngår å ende opp med et dyrt dataslott som ingen bruker.
Vil du komme i gang med datasatsing på en smart og bærekraftig måte? Ta kontakt for en prat hvor vi kan sammen se på hvordan dere kan starte med små skritt som gir stor verdi og unngår de klassiske fellene som mange gjør.
