Skytjenester er en metafor og et samlebegrep for standardiserte IT-tjenester som leveres over Internett, til din enhet med Internettforbindelse. Din enhet kan enten være en PC, nettbrett, telefon eller noe annet som kan kobles til et nettverk. Så lenge du har Internettforbindelse, får du tilgang til tjenestene hvor som helst og når som helst. Du kan kjøpe skytjenester på tre ulike nivåer: Software as a Service (SaaS), Platform as a Service (PaaS) eller Infrastructure as a Service (IaaS). Mer om det litt senere.
Skytjenester er standardiserte IT-tjenester levert over Internett til din dings
I realiteten er skytjenester «Dine data på noen andres datamaskin», siden dataene er lagret og behandles på en server et eller annet sted i verden. Mest sannsynlig lagres dataene dine flere steder for å sikre redundans og tilgjengelighet – når du trenger tilgang.
Leie i stedet for å eie
Forretningsmodellen er at du som kunde leier i stedet for å eie, kostbare IT-løsninger for å behandle dine data. Fordelen er at du får tilgang til den nyeste og mest oppdaterte teknologien til en relativt rimelig pris. Siden du kun betaler for det du bruker (pay-as-you-go), slipper du å gjøre store investeringer i IT infrastruktur. Dermed slipper du også å tenke på teknisk gjeld, som oppstår over tid ved manglende vedlikehold og oppdateringer.
Endrer markedsposisjoner
Tidligere utgjorde investeringskostnadene i IT-infrastruktur en viktig inngangsbarriere i flere bransjer. En konsekvens av skytjenester er at små oppstartsselskaper nå kan konkurrere på lik linje med etablerte selskaper. For eksempel innen netthandel eller banktjenester. Derfor ser vi i stadig økende grad at nye aktører kommer inn og utfordrer eksisterende aktører og deres posisjoner i markedet. Det setter press på de eksisterende aktørene og framtvinger nødvendige endringer hos dem, blant annet til å bli mere kundesentriske, datadrevene og kosteffektive.
Betaler kun for bruk
Som kunde betaler du kun for det du bruker av tjenesten. Siden skytjenester er modulisert og standardisert, gir det muligheter for kosteffektiv utvikling og forvaltning av tjenestene. Leverandøren kan dermed fordele alle utviklings- og forvaltningskostnadene for de respektive modulene på alle kundene. I teorien betyr det at jo flere kunder som bruker tjenestene, jo lavere blir kostnadene pr kunde. Men i praksis er det leverandørens prismodell du som kunde må forholde deg til.
De beste leverandørene av skytjenester er kundesentriske og bruker sin innovasjonskraft til å kontinuerlig videreutvikle tjenestene til fordel for kundene sine, og dernest til eierne. Som effekt får du som kunde tilgang til moderne IT-tjenester – som kan leveres raskt, effektivt, pålitelig og sikkert.
Tre nivåer av tjenester
Som kunde kan du velge mellom å kjøpe applikasjon, plattform eller infrastruktur som skytjeneste.
Applikasjon – Software as a Service (SaaS) – betyr at leverandøren har laget en ferdig løsning – som du kan begynne å bruke med en gang. Dette er enklest for deg som kunde og fungerer ofte som inngangsporten til skytjenester for de fleste. Eksempel: Microsoft 365 (Office, Teams) for digital samhandling på tvers av lokasjoner og organisasjoner.
Plattform – Platfom as a Service (PaaS) som betyr at leverandøren har laget en digital plattform – som du kan kjøre flere applikasjoner på. Plattformen gir et felles rammeverk for datalagring og -utveksling mellom applikasjonene. Eksempel: Microsoft Azure, Service Now, Force.com, Amazon, Google.
Infrastruktur – Infrastructure as a Service (IaaS) som betyr at leverandøren tilbyr databehandlings-, nettverks- og lagringsressurser. Eksempel: Microsoft, Amazon, Google.
Endrer måten vi jobber på
Covid 19 pandemien skjøt fart på bruk av hjemmekontor og digital samhandling for oss med jobber som ikke krever fysisk tilstedeværelse. Men dette hadde ikke vært mulig uten skytjenester. Teams er et eksempel på en skytjeneste (SaaS) som enkelt kunne kjøpes inn, tas i bruk, og skaleres opp hurtig. Den største fordelen med skytjenester er kanskje hurtigheten – som vil si hvor kort tid det tar fra et behov oppstår til en løsninger på plass.
Mulighetene skytjenester gir oss til å jobbe mer effektivt og samhandle bedre med hverandre er uendelig store. Ikke bare internt i egen virksomhet, men også med kunder, leverandører og partnere. For så lenge du har tilgang til Internett – kan du også få tilgang til nye, innovative tjenester basert på ny teknologi.
Behovet for skytjenester er økende, og vil fortsette å vokse sammen med en stadig økende endringstakt i samfunnet.
Digitalisering betyr forenkling. Fordi dagens teknologi muliggjør forenkling gjennom redesign av tjenester med underliggende verdikjeder og prosesser som har eksistert i lang tid. Derfor er det lurt å ta utgangspunkt i behovet og ikke prosessen for å dekke behovet når du skal digitalisere og forenkle noe. Det krever en kundesentrisk tilnærming.
Et godt eksempel finner vi i helse- og omsorgssektoren, som bruker begrepet e-helse om digitalisering i egen sektor.
Helsetjenestene i Norge har høy kvalitet og er blant verdens beste. Likevel er det et stort behov for forenkling, fordi helsetjenestene er satt under press. Det er minst tre årsaker til at dette skjer:
Vi blir flere og lever lengre, som medfører økt etterspørsel av helsetjenester.
Det kommer stadig nye behandlingsmuligheter, som krever mer ressurser.
Helsetjenestene er kostbare og skalerer dårlig på grunn av menneskelig involvering.
Dersom vi ikke gjør noe med måten vi forebygger og behandler sykdom på, vil ikke helsetjenestene være bærekraftig i framtiden. Derfor er det helt nødvendig å anvende IT riktig og tenke nytt rundt forebygging og behandling.
Heldigvis er dette noe ansvarlige ledere i sektoren allerede vet. Men å omsette denne kunnskapen til praktisk handling er som kjent utfordrende, og da kan det være godt å få inn litt ekstern hjelp. Slik kom jeg inn som rådgiver for å videreutvikle produktstrategi for de nasjonale e-helseløsningene, som inkluderer helsenorge, e-respt og kjernejournal.
Problemet som søkes løst
Dagens IT systemer støtter i for liten grad opp under målsettingen om at nødvendige helseopplysninger skal følge pasienten gjennom hele pasientforløpet. Denne erkjennelsen ble beskrevet i Stortingsmelding 9 (2012-2013) Én innbygger – én journal. Der står også tre overordnede mål for IT-utviklingen i helse- og omsorgssektoren:
Helsepersonell skal ha enkel og sikker tilgang til pasient- og brukeropplysninger
Innbyggerne skal ha tilgang på enkle og sikre digitale tjenester
Data skal være tilgjengelig for kvalitetsforbedring, helseovervåkning, styring og forskning.
Disse målene er utgangspunktet for Nasjonal strategi for e-helse, hvor det blant annet står: «For å nå helsepolitiske mål om bedre kvalitet, økt pasientsikkerhet og bedre bruk av kompetanse og ressurser er det nødvendig å utnytte mulighetene som ligger i digital teknologi på en bedre måte. E-helseløsninger utfordrer eksisterende arbeidsmåter, tankesett og kultur i helse- og omsorgstjenesten. Det er derfor avgjørende med fokus på endringsledelse for å lykkes med digitaliseringen.»
Etter min oppfatning er det en god beskrivelse av hva som må gjøres på et overordnet nivå. Men som alltid er det gjennomføringen av strategien som blir avgjørende for om den er god eller ikke.
Veikart for e-helse
Strategien for e-helse er brutt ned i konkrete krav, som skal oppfylles gjennom tiltak som strekker seg fra 2019 til 2025. Veikartet beskriver krav om at:
Innbyggere skal ha mulighet for å administrere behandlingsforløp, digital dialog og innsynstjenester gjennom Helsenorge
Helsepersonell skal ha tilgang til pasientens legemiddelliste
Helsepersonell skal ha tilgang til en oppdatert og autorativ beskrivelse av kritisk informasjon
Helsepersonell skal ha tilgang til journaldokumenter uavhengig av hvor pasienten har mottatt helsehjelp
Helsepersonell skal ha tilgang til laboratorie- og radiologisvar uavhengig av hvor undersøkelsen er foretatt
Helsepersonell skal ha tilgang til dialogmeldinger og forbedrede henvisninger
Innbygger skal ha muligheter for digital hjemmeoppfølging
Veikart for nasjonale e-helseløsninger 2021 – 2025
Mange av tiltakene i veikartet for nasjonale e-helseløsninger realiseres blant annet gjennom kjernejournal. Ett av tiltakene er tidligere nevnte pasientens legemiddelliste, PLL.
Helsepersonell dokumenterer behandling som gis i en elektronisk pasientjournal (EPJ). I dag fins det mange ulike leverandører av EPJ, og helseforetakene har anskaffet ulike løsninger. Derfor er det et behov for et sentralt register – hvor helsepersonell kan slå opp og få tilgang til kritisk informasjon om pasienten. Det er her kjernejournal kommer inn.
Helsenorge
Helsenorge er innbyggerportalen, hvor alle innbyggerne kan få innsyn i opplysninger om seg selv, legge inn nye opplysninger og bestille tjenester.
Innbyggerportalen helsenorge.no
Helsenorge tar utgangspunkt i innbyggernes behov for innsyn og medvirkning til opplysninger knyttet til egen helse, og ikke eksisterende prosess. Kanskje er det derfor det har blitt en suksess målt i antall oppslag. En annen forklarring kan være at selvbetjening gjennom Internett er et relativt nytt fenomen, som det ikke eksisterte en innarbeidet prosess for.
E-resept
Resepter inneholder opplysninger om legemidler, og praksisen med å sende papirbaserte resepter mellom leger og apoteker har eksistert så lenge at den digitale utgaven – e-resept – startet ved å erstatte resepter på papir med elektroniske utgaver av de samme skjemaene. Prosessen med å behandle reseptene ble også kopiert. Dermed ble de elektroniske utgavene av skjemaet sendt mellom aktørene i verdikjeden gjennom en tjeneste kalt «reseptformidleren» – som om de fremdeles var papirdokumenter.
Men etter å ha gått gjennom dette nødvendige første steget (strøm på papir), arbeides det nå heldigvis med å utvikle Pasientens Legemiddelliste, forkortet til PLL.
Hvorfor det? Jo, fordi PLL er en mye bedre måte å utveksle informasjon om hvilke medikamenter den enkelte pasient bruker mellom alle aktører som trenger denne informasjonen. Det gjøres blant annet gjennom kjernejournal, som jeg vil komme tilbake til.
Både fastleger, legevakter, sykehus, apotek og bandasjister bruker e-resept, og i dag er omtrent 93% av alle resepter utskrevet elektronisk. Det sendes rundt 27 millioner e-resepter til reseptformidleren årlig.
Kjernejournal
Kjernejournal er et virksomhetsovergripende, behandlingsrettet helseregister som skal øke pasientsikkerheten ved å bidra til rask og sikker tilgang til strukturert informasjon om pasienten til helsepersonell på tvers av:
Omsorgsnivåer (primær- og spesialisthelsetjenesten)
Virksomheter (offentlige og private aktører)
Regioner (nord, midt, vest og sør-øst)
I kjernejournal finner du følgende informasjon:
Om pasienten (kilde: offentlige registre)
Pasientens egne registreringer
Legemidler (kilde: offentlig register)
Kritisk informasjon (kilde: helsepersonell)
Besøk i spesialisthelsetjenesten (kilde: offentlig register)
I tillegg arbeides det med å gjøre flere informasjonstjenester tilgjengelig:
Lab- og radiologisvar (offentlig register)
Digitale behandlingsplaner og egenbehandlingsplaner (helsepersonell)
Søkbare data
Utfordringen er å gå fra ustrukturerte data til strukturerte data som er lettere å søke i. Dagens situasjon er at helsepersonell skriver ustrukturerte data i form av fritekst i kliniske fagsystemer. Det er «strøm på papir», og skyldes rett og slett at vi gjør det samme som tidligere, bare digitalt.
Ønsket tilstand er strukturerte, søkbare data. Men det krever enighet om kliniske informasjonsmodeller. Et problem er at det ikke er ensartet bruk av kodeverk i sektoren. Ulike applikasjoner og løsninger har implementert ulike informasjonsmodeller. Det medfører et behov for oversettelse uten at den medisinske betydningen endres. Gamle kliniske applikasjoner ble ikke laget for å utveksle data med andre systemer. Derfor trengs det standarder som sikrer lik definisjon av medisinske data.
Standardisering
Heldigvis er dette arbeidet kommet godt i gang, og det arbeides med en rekke standarder. For eksempel er SNOMED CT den mest omfattende standarden for klinisk terminologi på det internasjonale markedet i dag, og representerer et system av rundt 350.000 begreper.
Det kommer til å ta tid før alle leverandørene av kliniske fagsystemer har oppdatert produktene sine til å kunne utveksle data i henhold til den aktuelle standarden. Det er en utfordring vi sannsynligvis må leve med en god stund fremover.
Teknisk gjeld
Leverandører av kliniske fagsystemer, herunder Elektroniske Pasient Journaler (EPJ), må adressere teknisk gjeld i sine respektive løsninger. Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.
Teknisk gjeld er også noe ledere og innkjøpere i helseforetak bør være oppmerksomme på. De bør stille følgende spørsmål til sine leverandører av kliniske fagsystemer:
Hvor mye teknisk gjeld har den aktuelle løsningen?
Hva gjør leverandøren for å nedbetale den?
Svarene du får, vil gi deg en indikasjon på hvilke leverandører som er robuste nok til å bli med videre i den digitale transformasjonen.
Refleksjon
Dersom morgendagens helsetjenester skal bli bærekraftig må vi redesigne prosesser slik at de tar utgangspunkt i pasientens og helsepersonellets behov – ikke prosessen vi har benyttet fram til i dag. Det er enklest på helt nye områder, hvor det ikke eksisterer en etablert prosess, som innbyggerportalen helsenorge. Så er det litt vanskeligere på områder det allerede eksisterer en prosess, som e-resept, hvor en har gått fra reseptformidleren til pasientens legemiddelliste.
Å løse den store utfordringen – at dagens IT systemer støtter i for liten grad opp under målsettingen om at nødvendige helseopplysninger skal følge pasienten gjennom hele pasientforløpet – krever utskifting av systemer og at det blir gjort på riktig måte. En viktig del av dette handler om hvordan vi skal bevege oss bort fra ustrukturerte data i gammeldagse, monolittiske systemer til standardiserte og strukturerte data som er søkbare og gjort tilgjenglig i digitale plattformer som kjernejournal.
Det spørsmålet hører jeg stadig oftere, for både «digital» og «plattform» kan jo bety så mangt. Så det trenger en forklaring – som er hensikten med denne posten.
En digital plattform er teknologien og programvaren som benyttes i produksjon av forretningsverdi og kundeengasjement. Plattformen har en samordnet og integrert arkitektur, og brukes som et standardisert og transparent grunnlag for utvikling av applikasjoner, prosesser og tjenester for å skape verdi.
Hvorfor?
Brukt riktig, vil en digital plattform bidra til økt innovasjon og redusert teknisk gjeld.
Innovasjon – fra leverandøren som kan overføres og bygges videre på i egen virksomhet
Teknisk gjeld – reduseres gjennom bedre oversikt, struktur og lavere kompleksitet
Her trengs det litt mer forklaring.
Innovasjon
Innovasjon betyr nyskapning, og innebærer blant annet fornyelse av produksjonsprosesser. En god plattformleverandør tilfører ekstern innovasjon gjennom standardiserte prosesser, tjenester og applikasjoner. Produktet er utviklet på grunnlag av systematisk læring fra andre kunder – som kan overføres. Men det ser ut som at mange liker å tro at de er så spesielle at de ikke kan bruke standardiserte tjenester, prosesser og applikasjoner. Nesten på instinkt eller autopilot, uten refleksjon. Til dem vil jeg si: Neida, dere er faktisk ikke så spesielle som dere kanskje vil hevde.
Min erfaring tilsier at det er smart å bygge videre på innovasjon og læring fra eksterne. Vi bør rett og slett reflektere litt oftere over hvordan ekstern innovasjon kan overføres til egen organisasjon. Men det krever som regel endring i egne prosesser og strukturer som vil generere motstand i egen organisasjon. Dermed oppstår behov for endringsledelse for å oppnå ønsket effekt og høste gevinstene.
I stedet for å gripe denne muligheten, prøver mange heller å tilpasse løsningen til eksisterende strukturer og produksjonsprosesser, med den konsekvensen at de går glipp av innovasjonspotensialet. Denne tabben gjøres overraskende ofte, faktisk så ofte at den har fått et eget, ironisk navn: Conways lov for anskaffelse av nytt IT-system.
Teknisk gjeld
Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.
Når en skal integrere data mellom to forskjellige applikasjoner – med ulike datamodeller som ikke er standardisert – blir det fort blir unødvendig komplisert og komplekst. Med konsekvens at den tekniske gjelden øker, i stedet for å reduseres. Det skjer når en anskaffer ny applikasjon uten å vurdere hvordan den skal utveksle data med andre applikasjoner.
Derfor er det aldri lurt å bytte en applikasjon med en annen applikasjon – uten å samtidig redusere kompleksitet i den helhetlige arkitekturen. Les gjerne en tidligere post hva er teknisk gjeld? – om du vil vite mer.
Problemet den løser
Plattformen består av hardware og software som gjør det mulig å kjøre flere applikasjoner som oppretter, henter og sletter data på en enhetlig måte. Data lagres samordnet i plattformen, og ikke i den enkelte applikasjon. Det er en stor fordel, fordi det reduserer kompleksitet, plunder og heft med å dele data mellom applikasjonene.
Tradisjonelle applikasjoner blir ofte betegnet som teknologisk arv, fordi de ble utviklet til ett avgrenset, funksjonelt formål. Slike applikasjoner har sitt eget datalager og regler for å opprette, lese, oppdatere og slette data. Ulempen er at de i realiteten er data-siloer. Det betyr at deling av data er komplisert, kostbart og tidskrevende. Ofte lar det seg heller ikke gjøre, uten å bygge nye databaser og gjøre endringer i applikasjonen, som igjen øker kompleksiteten. Konsekvensen er at den tekniske gjelden øker, selv når vi ønsker å redusere den.
En digital plattform er designet for å løse nettopp dette problemet; deling av data på tvers av ulike applikasjoner. Det skjer gjennom felles protokoll og rammeverk for hvordan lagring og utveksling skal foregå. Tilgjengeliggjøring av eksisterende data – til nye formål – gjøres derfor mye enklere, sikrere, billigere og raskere.
Hvordan?
Applikasjonene som kjører på en plattform er standardisert, og kan som regel tilpasses uten at koden må enders gjennom programmering. Kundene kan i stedet konfigurere løsningen selv, når den er anskaffet og klargjort til bruk. Klargjøringen består i hovedsak av konfigurasjon, opprydding av data i den gamle løsningen, migrere data til ny løsning, ta i bruk ny løsning, og etter hvert terminere den gamle løsningen.
Det er også mulig å lage helt nye applikasjoner, men innen det samme rammeverket for datautveksling som gjelder for plattformen. Slik sikres en enhetlig og samordnet arkitektur som fremmer innovasjon. Men det innebærer strategiske valg av teknologi som skal understøtte verdiskapningen helhetlig. Til det trengs en portefølje av applikasjoner som deler data og har den samme definisjonen av hva dataene representerer.
Vi snakker egentlig om interoperabilitet, som innebærer at et produkts grensesnitt er fullstendig forstått, slik at det kan arbeide sammen med andre produkter eller systemer, nåværende eller fremtidige, i en hvilken som helst implementasjon eller tilgang, uten noen restriksjoner.
100% interoperabilitet krever åpne standarder, som desverre er noe vi har for lite av i dag. Men slike standarder er under utvikling, og støtte for disse standardene implementeres som regel i de plattformløsningene som er gode og fremtidsrettet.
Bistand
Businesscaset for å knytte til seg en rådgiver og implementeringspartner, som for eksempel Sopra Steria er godt. Fordi det reduserer risiko og øker innovasjonsevnen. Redusert risko for dårlige beslutninger, som mefører teknisk gjeld, manglende interoperabilitet og dårligere måloppnåelse. Økt innovasjonesevne gjennom adopsjon av eksterne standarder og læring.
Det er slike vurderinger jeg og mine rådgiverkollegaer har praktisk erfaring med, og kan bistå beslutningstakere med, slik at de kan ta gode strategiske valg knyttet til teknologi. For det er kostbart å velge feil produkt, siden en må leve med konsekvensene av manglende interoperabilitet og teknisk gjeld – i hele produktets levetid. Selv om en enkeltstående løsning, på kort sikt fremstår som det billigste alternativet.
Feil antagelser, tapt innsikt i overleveringer og lang utviklingstid resulterer i mislykkede digitaliseringsprosjekter. Mens forventede gevinster uteblir, løper kostnadene fort – med tapte muligheter og bortkastet arbeid som resultat.
Men hva om vi lærer av feilene, og endrer tilnærming?
Det er nettopp det «Agile» eller smidig på norsk, har gjort. Smidig-bevegelsen, i mangel på et bedre navn, tilbyr en bedre og ja, mer smidig tilnærming; fra prosjekter med flere overleveringer til kontinuerlig produktutvikling og forvaltning, utført av samme team. Opparbeidet læring forsvinner ikke, og utviklingstiden reduseres radikalt fra år til uker.
Vi trenger å korte ned tiden fra idé til funksjonelt produkt, for å bekrefte eller avkrefte de antagelsene som er lagt til grunn for behovet ute hos brukerne eller kundene. Antagelsen om problemet/behovet er viktig nok til at kundene vil bruke tid og ressurser på tjenesten/produktet er helt sentralt, siden hele business-caset for prosjektet bygges på denne hypotesen og antagelsen – alene.
Videre er det lurt å teste vår andre antagelse; om at løsningen vi har valgt er riktig. Hele gevinstkorthuset bygger på at denne helt sentrale antagelsen holder. Dessverre ser vi litt for ofte at det ikke er tilfelle.
Hvis vi tidlig i utviklingsprosessen tester de grunnleggende hypotesene våre i liten skala, kan vi lære hvordan en enkel prototype av en tjeneste eller produkt blir mottatt av kundene. Det er kanskje den beste muligheten vi har for å unngå å kaste bort penger på produkter og tjenester som aldri burde vært laget.
En slik tilnærming er helt i tråd med innovasjonsprosessen Bygge – Måle – Lære, som er kjernen i hvordan kundeorienterte og datadrevne virksomheter opererer. Dette har jeg blant annet skrevet om i et tidligere innlegg strategiprosess til besvær.
Overleveringer
Et prosjekt er per definisjon tidsavgrenset, som betyr at den læringen som har skjedd underveis i utviklingsprosessen, forsvinner i det resultatet/leveransen overleveres fra utvikling til drift. Utvikling er typisk organisert i prosjekter, mens drift og forvaltning som regel utføres av linje-organisasjonen.
For å komme i mål til rett tid, har det kanskje i utviklingsprosjektet blitt gjort noen grep som har resultert i teknisk gjeld. Som regel blir ikke teknisk gjeld oppdaget før etter en tid, av den enkle årsaken at linjeorganisasjonen ikke har nødvendig forutsetninger eller tilgang på erfaringen som er opparbeidet i utviklingsprosjektet. Erfaring som går tapt når prosjektet er ferdigstilt og utviklingsteamet oppløses.
En smidig tilnærming har ingen slik overlevering fra utvikling til drift. Blant annet begrunnet med at det er lurt å betale ned teknisk gjeld fortløpende, før effekten av renters rente gjør løsningen ustabil med de konsekvensene det kan medføre for tapt produksjon.
Om du vil vite mer om teknisk gjeld, kan du lese et tidligere innlegg: hva er teknisk gjeld?
Tid
Den siste store utfordringen med klassisk prosjektgjennomføring i digitalisering er tiden det tar fra behovet oppstår til en løsning er utviklet, testet og satt i produksjon. Hvis problemstillingen er kompleks, og prosjektet stort, kan det ta opptil flere år. I løpet av så lang tid kan behovene være endret, med konsekvens at løsningen ikke lenger er relevant. Nettopp dette var kjernen i kritikken som ble reist mot Akson, et gigantprosjekt til 11 milliarder for å utvikle elektroniske pasientjournaler til kommunene, som skulle løse for mange behov – samtidig.
Siden endringstakten i samfunnet øker, blir det nærliggende å møte denne utviklingen med å jobbe i kortere sykluser og sørge for at gevinstrealiseringstidspunktet – når produktet vårt møter sluttbrukeren – kommer så tett opp til startpunktet som mulig. Helst ikke mer enn uker, og maks noen måneder.
For å få det til må sammensatte behov deles opp i mindre deler, og at vi må lære oss hvordan vi kan teste hypoteser for å redusere usikkerhet om hvordan produktet/tjenesten vil bli mottatt hos kundene. Dette er eksperimentering og læring satt i system, slik at vi kan ta gode beslutninger, understøttet av gode og oppdaterte data fra ekte kunder/brukere.
Det er her smidig kommer inn med en radikalt ny tilnærming til utvikling av programvare. Fra prosjektorganisering til produktorganisering med tverrfaglige, selvstyrte team som både utvikler og drifter tjenestene. Fordelen er åpenbar, siden smidig utviklingsmetodikk skaper verdi raskt i små steg ved å korte ned veien fra behov til fungerende kode i en digital løsning.
Smidig manifestet
Det sentrale tankegodset rundt «smidig» har rukket å bli 20 år i 2021, og kommer opprinnelig fra en gruppe utviklere som skrev Manifestet for smidig programvareutvikling. Manifestet går i korte trekk ut på å verdsette:
Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan.
Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.
Smidig prinsippene
Manifestet følges av noen sentrale prinsipper:
Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden.
Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
Forretningssiden og utviklerne må arbeide sammen daglig gjennom hele prosjektet.
Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.
Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt.
Fungerende programvare er det primære målet på fremdrift.
Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden.
Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet.
Enkelhet – kunsten å maksimere mengden arbeid som ikke blir gjort – er essensielt.
De beste arkitekturer, krav og design vokser frem fra selvstyrte team.
Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter.
Hva dette betyr
Jeg opplever at tankegodset fra smidig manifestet sprer om seg i norske virksomheter i dag. Blant annet har jeg sett at det blir stadig vanligere å kjøre korte «stand-up» møter på 15 – 30 minutter for å koordinere oppgaver i teamet – ansikt til ansikt.
Så registrerer jeg med glede at enkelte kunder allerede har organisert seg i produkt-team etter modell fra smidig. Teamene er satt sammen tverrfaglig, slik at teamet har nødvendig forretningsmessig, juridisk og teknisk kompetanse til å utvikle ny funksjonalitet og gjøre løsningen mer robust.
Jeg er så heldig at jeg får lov til å være rådgiver for produktstyring og -strategi hos en stor norsk virksomhet som leverer samfunnskritiske tjenester. Figuren under viser hvordan produktstyring og smidig organisering skaper økt nytteverdi for kundene/brukerne.
Smidig utviklingsmetodikk
At teamene er selvstyrte, innebærer at de gjør egne prioriteringer innen rammene av en overordnet produkt-kø. Den inneholder en liste over krav og behov, som er sentral i den strategiske produktstyringen. Oppgavene organiseres i en sprint-kø, som produktteamet står fritt til å fordele og løse i løpet av sprint-perioden. Normal varighet på en sprint er 1-4 uker.
Fra produktkøen velges det ut oppgaver etter en helhetlig prioritering av hva som vil gi størst mulig nytteverdi i forhold til kostnader/innsats. Det er produktteamet som gjør dette. De planlegger sprinten slik at oppgavene er spesifisert og klare til at leveranseteamet kan utvikle kode for endringer som skaper nytteverdi. Endringene blir gjort tilgjengelig umiddelbart etter sprinten er ferdig demonstrert, testet og godkjent.
For å få til dette, kreves blant annet en god løsningsarkitektur som er modulisert, standardisert og automatisert for testing. Det er typisk her jeg kommer inn som rådgiver innen smidig utviklingsmetodikk og -prinsipper. Selv lærte jeg om smidig for 10 år siden, da jeg tok en sertifisering som produkt-eier (Certified Scrum Product Owner), en innsikt jeg har hatt stor glede og nytte av siden.
Anskaffelse av et nytt IT-verktøy til en definert oppgave høres i utgangspunktet ganske enkelt ut. Men uten en klar forståelse av formålet med systemet og problemet som søkes løst, går det ofte dårlig. Manglende forståelse kan sågar forsterke problemet gjennom økt kompleksitet. Resultatet er bortkastet arbeid, frustrasjon og unødig sløsing av ressurser.
Behovene for nye IT-verktøy kan være forskjellig, men utfordringen er ofte er den samme: Mangelfull forståelse av hva som skaper verdi, medfører feil bestilling. Anskaffelsen blir dyr, og kostnadene øker i takt med antall involverte.
Bærum kommune lærte dette på den harde måten da de anskaffet et nytt økonomisystem og gikk på en 100 millioner smell. Det nye økonomisystemet skulle koste rundt 40 millioner kroner, og når det kom på plass i 2016 – fire år etter planen – var regningen kommet opp i nesten 140 millioner kroner.
Rotårsaken var ifølge en rapport fra kommunerevisjonen et forsøk på å modifisere et standardsystem slik at det minnet om det gamle systemet det skulle erstatte. Kommunerevisjonen mente de ekstremt kompliserte kravspesifikasjonene til økonomisystemet, et dokument på 700 sider, var en direkte årsak til 100-millionersmellen. Ifølge rapporten burde kommunen ha tilpasset organisasjonen til økonomisystemet. Ikke omvendt.
Dette var en dyrekjøpt erfaring og forhåpentligvis god læring for Bærum kommune som vi andre også kan lære noe av. Du finner en kortfattet oppsummering av saken her.
Det Bærum kommune gjorde er dessverre helt vanlig. Interessant nok skjer dette så ofte at fenomenet regnes som et «prinsipp» som har fått et eget navn; Conways lov. Denne «loven» sier at: Organisasjoners informasjonssystemer utformes, bevisst eller ubevisst, slik at de gjenskaper organisasjonsstrukturen. Prinsippet ble trolig først uttalt av programmereren Melvin Convay i 1967(!), og ble formulert som en «lov» i Conways navn på en konferanse året etter.
Tenk litt på det, og la det synke inn en liten stund. – Det er ganske nedslående. Conways lov kan forklare mange IT-skandaler, og den ufattelige sløsingen av ressurser slik atferd representerer. Den ubevisste atferden fremmer i hvert fall ikke innovasjon, og gjør det vanskelig å høste gevinster av IT.
Conways lov ser ellers ut til å også omfatte utvikling av organisasjoners nettsteder, hvor inndelingen av nettstedet har en tendens til å gjenspeile organisasjonskartet i stedet for å fokusere på hva brukerne faktisk ønsker å løse. Nok om det.
Så hvordan bør en gå fram for å anskaffe et nytt IT-system? Det jeg har lært, er at dersom en tar seg tid til å analysere hva systemet skal brukes til, og hva som søkes oppnådd, kan en formulere noen få, men tydelige behov. Disse kan så kommuniseres for å valideres og bekreftes. Først internt, for å bli enige om hva de faktiske behovene er på tvers av avdelinger og organisatoriske enheter. Deretter eksternt, til aktuelle leverandører. Risiko for misforståelser og feil reduseres, og sannsynligheten for at anskaffelsen blir vellykket øker. Her ligger også business-caset for å leie inn ekstern ekspertise i å analysere og formulere hva det faktiske behovet er, – og ikke er.
Min erfaring er at virksomhetsarkitektur er en nyttig metode for å forstå hva IT-systemer skal brukes til. Virksomhetsarkitektur er en strukturert metodikk som beskriver hvordan en virksomhet er organisert, hvordan arbeidsprosesser er satt sammen og hvordan IT-løsninger utnyttes for å produsere verdi for å nå forretningsmålene. Dette har jeg beskrevet i et tidligere innlegg: Verdien av virksomhetsarkitektur.
Innsikten fra arbeidet med virksomhetsarkitektur er direkte overførbart til å formulere behov for et nytt IT-system. Det sikrer en helhetlig forståelse, og reduserer risiko for sub-optimalisering som typisk skjer når en avdeling anskaffer et verktøy – til sitt behov, uten å ta innover seg at også andre avdelinger og funksjoner har avhengigheter og interesser i det nye IT-systemet, som må hensyntas.
Funksjonelle behov beskrives som «brukerhistorier», som typisk har denne oppbygningen: Som «rolle» trenger jeg «funksjonalitet» for å oppnå «effekt«.
For eksempel:
Som kunde trenger jeg å se om jeg har gyldig forsikring når jeg skal registrere en skade.
Som skadebehandler trenger jeg en definert prosess for å se hva jeg skal gjøre og hvilken informasjon og dokumentasjon jeg trenger for å behandle en skade.
Som kundeservice trenger jeg å søke i en kundedatabase for å finne kunder med gyldig forsikringspolise.
Slike brukerhistorier kommuniserer behov og ønsket effekt for interessentene. De bør ikke være for mange, og kan gjerne suppleres med prosesskart, suksessfaktorer og hvordan dette måles og rapporteres. Dette omtales gjerne som Key Performance Indicator (KPI).
I tillegg er det behov for at IT-systemet må kunne utveksle data med andre systemer gjennom standardiserte grensesnitt (API). Dette er kritisk viktig, og måten det gjøres på er en avgjørende faktor for om IT-systemet passer inn i virksomhetsarkitekturen og det strategiske målbildet. Dette har jeg skrevet om i et annet innlegg: Hva er et API?
Selve anskaffelsen er en formell prosess hvor en ber om tilbud gjennom «request for proposal» (RFP) i en anbudskonkurranse. Det beste tilbudet velges ut fra en helhetlig vurdering etter regler som er definert i konkurransegrunnlaget, som ofte er pris og kvalitet.
Slik jeg ser det, kan vi trekke følgende læring ut fra alt dette: Om du skal anskaffe et nytt IT-verktøy, vær oppmerksom på Conways lov og benytt virksomhetsarkitektur som metode for å unngå fellene så mange har gått i tidligere. For som Gro Harlem Brundtland så treffende sa: «Alt henger sammen med alt».
Betalingsgrunnlaget for å leie inn konsulenter, advokater og andre profesjonelle tjenesteytere er fakturerte timer. Fordi det er enkelt å måle og sammenligne timepriser i en anbudskonkurranse, er fakturerte timer blitt den vanligste prismodellen ved konsulentkjøp. Problemet er at det hindrer innovasjon og skaper interessekonflikt mellom kunde og leverandør. Det er ikke bærekraftig, og jeg mener vi trenger en ny prismodell for konsulenter og andre profesjonelle tjenester. Begrunnelsen får du i denne posten.
Det er flere problemer med dagens prismodellmodell, faktisk så mange at jeg har satt opp en liste over de viktigste:
Det leverandøren vil ha mer av (timer), vil kunden ha mindre av.
Det fokuseres på innsats (timer og kostnader), fremfor effekt og oppnådd gevinst.
Leverandøren får mindre betalt om oppgaven effektiviseres og løses raskere.
Kunden sitter som regel med all risiko, leverandøren har liten eller ingen risiko.
Det er ingen belønning for innovasjon, siden leverandøren får betalt for medgått tid.
Som effekt dyrkes en produksjonsmentalitet fremfor en mentalitet preget av innovasjon og nyskapning.
En av utfordringene i dag er at kostbare konsulenter i stor grad benyttes til daglige og enkle driftsoppgaver, og ikke til utviklingsarbeid og innovasjon. For produksjon bør kundene heller benytte egne ansatte eller vikarer, som er vesentlig rimeligere enn konsulenter. Dette har jeg forklart og begrunnet i et tidligere innlegg: Verdien av IT-rådgivning.
Så hva kan gjøres? Det enkle svaret er at vi trenger en ny prismodell for rådgivningstjenester, men hvordan den bør være er litt vanskeligere å svare på. Jeg drister meg likevel til et forslag, siden jeg tror åpenhet og deling er noe av nøkkelen for å løse problemet.
De første lyspærene ble laget for å vare i mange år. «Problemet» sett med produsentenes øyne var at det var dårlig butikk, fordi det ble solgt for få lyspærer. Derfor ble levetiden til lyspærene redusert for å skape behov i markedet. Det resulterte i god butikk, men også en lite bærekraftig forretningsmodell basert på bruk og kast. I dag anerkjennes manglende bærekraft som et voksende problem som må adresseres og løses. Heldigvis.
I en sirkulærøkonomi ønskes lengst mulig levetid for produktene, og materialene som benyttes skal være gjenbrukbare og resirkulerbare for å unngå overforbruk av råvarer. Sirkulærøkonomien kjennetegnes av innovative forretningsmodeller som fremmer kunde-tilgang fremfor eierskap til ressurser. Kunden betaler for bruk, gjennom å leie utstyr fra en profesjonell leverandør framfor å kjøpe det. Det kunden egentlig ønsker å kjøpe er effekten, ikke innsatsfaktoren.
I 2015 lanserte Philips «Lys som en tjeneste» i forbindelse med et samarbeid om den nye belysningen i terminalbygningene på Amsterdam Airport Schiphol. Lys som en tjeneste betyr at Schiphol betaler for lyset det bruker, mens Philips fortsatt eier alle installasjoner og inventar. Philips og installasjonspartneren Cofely er felles ansvarlige for systemets ytelse og holdbarhet, og til slutt dets gjenbruk og resirkulering etter endt levetid.
Ved å bruke energieffektive LED-lamper oppnås 50% reduksjon i strømforbruket i forhold til konvensjonelle belysningssystemer. Belysningsarmaturene som ble spesielt utviklet for Amsterdam Airport Schiphol er antatt å vare 75% lenger enn andre konvensjonelle armaturer. Armaturkomponentene kan byttes ut individuelt, noe som reduserte vedlikeholdskostnadene og medførte at bare enkelte deler av inventaret må resirkuleres ved utskiftinger og oppgraderinger.
Schiphol, Cofely og Philips laget i praksis en ny forretningsmodell for en mer bærekraftig belysning inspirert av prinsipper for sirkulær økonomi. Arbeidet var forøvrig en del av en omfattende renovering av terminalen som hadde som mål å øke passasjerkomforten og kapasiteten på Schiphol.
Jeg synes det er nærliggende å sammenligne endringsreisen Schiphol gjennomgikk med en digital transformasjon for en virksomhet, som er det jeg jobber med til daglig. Det interessante spørsmålet for vår problemstilling rundt fakturerbare timer blir dermed: Kan forretningsmodellen «Lys som en tjeneste» overføres til konsulentkjøp?
Jeg mener ja, og tror «rådgivning som en tjeneste» også kan hente inspirasjon fra sirkulærøkonomien, og en lignende forretningsmodell kan etableres. Det kan se omtrent slik ut: Mot et fast månedlig beløp får kunden tilgang til rådgivning og verktøy tilpasset kundens rammebetingelser, ønsker og behov. Det hadde vært ideelt om kunden kunne betalt for effekt og ikke innsatsfaktor, men inntil videre kan vi starte med å benytte smarte løsninger som skaper transparens og reduser unødvendig sløsing for begge parter.
Noen sentrale rammebetingelser må på plass. Både kunden og leverandøren har behov for forutsigbarhet over kostnader og ressursallokering, derfor må en tjenestekatalog som beskriver hva som kan bestilles og hvor mye det koster være på plass. Jeg tror mange vil foretrekke en relativt lav månedlig kostnad kombinert med høy fleksibilitet for når rådgivningen skal utføres. Det kan for eksempel være en avtalt pott på, la oss si 10 – 1000 timer i måneden, kombinert med tilgang til verktøy og innsikt i form av maler og dokumenter. Dersom timene ikke benyttes, overføres de automatisk til neste måned, og kan benyttes når kunden har behov og anledning til å motta rådgivning.
For fem år siden skrev jeg en kronikk om viktigheten av å kjenne kunden sin godt. Den bygget på en undersøkelse som blant annet avdekket at kunder generelt ønsker tjenester som er:
Tilpasset personlige behov
Lett å bruke
Prisgunstig i forhold til alternativer
Disse tre punktene tror jeg også gjelder kunder for rådgivningstjenester. I samtaler jeg har hatt med mine kunder, har jeg i tillegg lært at det ikke alltid er nødvendig med skreddersøm og den mest kostbare tilnærmingen, for å løse et enkelt behov. Med denne innsikten vil jeg derfor foreslå fire nivåer av rådgivningstjenester, med forskjellig pris, hvor tjenesten er en predefinert miks som kundene kan velge mellom:
Selvbetjening – til metoder og verktøy.
Avlastning – til oppdatering og feilretting
Juniorkonsulent – til kosteffektiv gjennomføring
Seniorkonsulent – til prioritering og planlegging
En selvbetjeningsløsning vil gi kunden tilgang til innsikt, verktøy og maler for diverse dokumenter som kunden kan utarbeide selv, (eksempelvis om personvern eller andre regulatoriske krav). Jeg har faktisk hatt gleden av å jobbe sammen med et innovativt advokatselskap som tilbyr enkle advokattjenester som selvbetjening for kundene sine. Gjennom kundeportalen «min side» kan advokatfirmaets kunder (snart) sette opp enkle kontrakter, klager eller testamenter. Dette tenker jeg kan overføres til våre rådgivningskunder, ved at de selv utarbeider typiske dokumenter en IT-konsulent ville laget. Det kan i prinsippet være et hvilket som helst dokument, så lenge kunden har kompetanse til å fylle dem ut selv. Dersom kunden ikke har kompetansen, som ofte er situasjonen, er noe av poenget at kompetansen skal overføres til kunden, på kundens premisser. Dette vil en selvbetjeningsløsning passe utmerket til.
Avlastning vil som navnet antyder, gi kunden avlastning på enkle og godt definerte oppgaver. Dette vil typisk være oppgaver som er tidkrevende for kunden, men tar vesentlig kortere tid å utføre for en konsulent med relevant erfaring. Sopra Steria gjør faktisk dette i dag, for rutinepregede oppgaver knyttet til forvaltning (enkel feilretting og oppdatering) av applikasjoner. Det forutsetter en viss grad av standardiserte metoder for å løse oppgavene. En konsulent som utfører oppgaven hver dag, gjør det sikrere og raskere enn kunden. I denne kategorien kreves ikke en navngitt ressurs, og oppgaven kan utføres av ledige konsulenter med nødvendig kompetanse. Det er gunstig for leverandøren, fordi restkapasitet kan utnyttes og det gir begge parter forutsigbarhet og fleksibilitet.
En navngitt juniorkonsulent vil gi kunden tilgang til en dedikert person som tilfører kapasitet til å få oppgaven gjort raskt og kosteffektivt. Det forutsetter at oppgaven er tydelig definert og planlagt før arbeidet kan påbegynnes.
En navngitt seniorkonsulent gir kunden tilgang til en diskusjonspartner for planlegging og prioritering av oppgaver. For oppgaver preget av stor usikkerhet og kompleksitet kan det være lurt å diskutere problemstillingen med en erfaren rådgiver før en definerer løsningen. Det har forhåpentligvis historien med store, komplekse og mislykkede IT-prosjekter lært oss.
Bærekraft og sirkulærøkonomiske prinsipper vokser fram på stadig flere områder. Jeg mener vi som lever av å gi kundene våre gode råd, må selv ta i bruk disse prinsippene for å innovere tjenestene våre innen IT-rådgivning. Teknologien for å skape transparens og forutsigbarhet som gjør det mulig å redusere ressursforbruk hos begge parter finnes allerede.
Kanskje er det på tide å fornye forretningsmodellen for rådgivningstjenester?
Jeg tror åpenhet, deling og tillit mellom kunde og leverandør er veien å gå, og vi må starte nå. Derfor er vi i Sopra Steria allerede i gang med eksperimentering sammen med noen av kundene våre for å lære mer. Høres det interessant ut? Ta kontakt for å bli med!
Fredag 26. februar 2021 var jeg gjest hos Avfall Norge for å snakke om digitalisering av bransjen på et webinar. Bransjen gjør avfall om til råvarer, som er helt nødvendig om Norge skal nå de ambisiøse målene om materialgjenvinning: 65% innen 2035. Det synes jeg er inspirerende å bidra til.
Digitaliseringsløft
Bransjen trenger et digitaliseringsløft for å utnytte de teknologiske mulighetene for å bidra til det grønne skiftet, mot en bærekraftig sirkulærøkonomi. Jeg var så heldig å få lov til å lede arbeidet med å komme i gang med digitaliseringsløftet. Et samarbeid i regi av Avfall Norge ledet fram til et veikart for digitalisering av avfalls- og gjenvinningsbransjen. I et intervju den 13 desember 2019 beskrev jeg oppdraget og vår tilnærming til digitaliseringsløftet.
Bransjeorganisasjon for Avfalls- og gjenvinningsbransjen
Jeg lærte mye av å jobbe sammen med dyktige mennesker i bransjen da vi laget veikartet for et år siden. Blant annet avfallspyramiden, som viser prioriteringene i norsk og europeisk avfalls- og gjenvinningspolitikk.
Avfallspyramiden
Veien til et sirkulærøkonomisk lavutslippssamfunn er lang, og det kreves nytenkning for å utnytte det fulle potensialet av teknologi. Hvordan tenke nytt, har jeg skrevet om i innlegget hva er en digital strategi? I tillegg kreves aktiv deling av data på tvers av bransjer for å lykkes, noe jeg skrev om i innlegget hva er et API?
Digitaliseringsløftet skal bidra til en sirkulær økonomi og økt bruk av resirkulerte råvarer gjennom blant annet deling av data.
Et godt utgangspunkt er å starte med en tydelig definisjon av hva digitalisering betyr for bransjen. Digitalisering er transformasjonen fra at IT er et støtteverktøy til det blir en del av bransjens DNA. Det betyr at forretningsmodeller, virksomheter og prosesser er designet for å utnytte dagens og morgendagens teknologi.
Styrke kjernen og bygge for fremtiden
Digitalisering er datadrevet innovasjon, og gjort riktig for bransjen vil det både styrke kjernen i dagens virksomhet og bygge evne til å utvikle nye tjenester for fremtiden innen avfallsinnsamling, materialgjenvinning og distribusjon for på sikt å kunne realisere visjonen om en sirkulær økonomi. Avfalls- og gjenvinningsbransjen skal digitalisere for å nå mål, skape verdi og lønnsomhet for seg selv, kunder, innbyggere og eiere. Digitalisering er ikke et mål i seg selv, med et virkemiddel for å produsere dagens tjenester på en bedre måte, og utvikle nye inntektsgivende tjenester i takt med endringer i kundenes behov og preferanser. Teknologisk utvikling er en viktig driver.
Avdekke behov og skape verdi med data
Digitalisering skal bidra til å avdekke behov og skape verdi mer effektivt og helhetlig gjennom bruk og analyse av data, som kobles sammen fra flere kilder. Avfalls- og gjenvinningsbransjen bør derfor utvikle seg til å bli mer kundeorientert, bruke data og ta flere datadrevne beslutninger for å nå målene for vekst og lønnsomhet i en sirkulær økonomi.
Hvorfor veikart?
Målet med veikartet er å samordne og inspirere bransjen i et samfunn som digitaliseres. Hensikten er å sikre at bransjens verdiskapning bidrar til det grønne skiftet. Da må bransjen bidra til å endre samfunnets syn på avfall, og selskapene må unngå Kodak-fellen før det er for sent. Derfor må ledere i de enkelte selskapene i bransjen forstå hva digitalisering er, for å møte forventningene fra innbyggerne, utnytte mulighetene og unngå truslene.
Veikartets funksjon er å samordne de enkelte selskapenes egen digitale strategi, slik at den kan påvirke virksomhetsstrategien for de enkelte selskapene i bransjen. Altså det motsatte av tankegangen rundt en tradisjonell IT-strategi, hvor IT får oppdrag av forretning. Dette har jeg forklart i et annet innlegg; IT-lederens nye rolle. Bare slik kan det fulle potensialet som ligger i ny teknologi utnyttes. Dette er noe digitale ledere vet, og en viktig del av jobben min som konsulent går ut på vise forretningsmuligheter og unngå trusler teknologi representerer for dem og selskapene deres. Dette har jeg skrevet om i innlegget: Daglig leders rolle i en transformasjon.
Det er også en annen grunn til at samordning og samarbeid er viktig. Fordi bransjen i dag preges av store forskjeller:
Digital modenhet. De beste har begynt på reisen til å bli kundeorientert og datadrevet. Mindre selskaper har ikke muskler til å gjøre store investeringer.
Forretningsmodell. Husholdningsavfall samles inn etter lovregulert selvkostprinsipp. Næringsavfall samles inn i et konkurranseutsatt marked.
Teknologisk arv. Noen har gamle og andre har nye IT-systemer. Tidligere investeringer i teknologi legger premisser og begrensninger for hva som er mulig å få til.
Geografi. Logistikk i byene og på landet byr på ulike begrensninger og muligheter. Innsamlingsruter på inntil 50 mil er utfordrende i seg selv.
Gevinstpotensialet i digitalisering er stort. Det dreier seg overordnet om mer tilpassede tjenester, forbedret innsamling og bedre produkter som vist i figuren under.
Gevinster av digitalisering
Forutsetningen er gode data, og en kulturendring i bransjen for å kunne utnytte det store potensialet som ligger i digitalisering. Basert på det jeg har lært gjennom samarbeid og diskusjoner med bransjens beste ledere og fagpersoner, tror jeg kulturendringen må inkludere tre sentrale prinsipper:
Sett kunden i sentrum
La data gjøre mer av jobben
Eksperimenter mer for å lære
Målbildet for bransjen består av fire elementer: Kundeorientering, operasjonell effektivitet, forretningsmodell og en samordnet og integrert arkitektur som muliggjør innovasjon.
Målbilde for avfalls- og gjenvinningsbransjen
Målbildet er inspirert av forskningen til Westerman, G., Bonnet, D., & McAfee, A. (2014). Leading Digital: Turning Technology Into Business Transformation. Arkitkturen viser hvordan bransjen kan samordne og standardisere prosesser, data, applikasjoner og IT-infrastruktur. Dette har jeg også skrevet om i innlegget: Verdien av virksomhetsarkitektur.
Jeg lar meg inspirere av fremsynte ledere i bransjen som har jobbet videre med digitalisering, i tråd med veikartet Avfall Norge fikk utarbeidet sammen. Godt lederskap, samarbeid og vilje til å dele er et utmerket utgangspunkt for å gi bransjen et digitaliseringsløft. Så tror jeg at vilje og evne til transformasjon vil være avgjørende for om bransjen lykkes. Dette vil jeg skrive mer om senere.
De tre bokstavene brukes stadig oftere, og ikke lenger bare av teknologer. Nesten alle som har en mening om digitalisering snakker om API. Men hva er egentlig et API, og hvilken nytteverdi har det? Det er disse to spørsmålene jeg vil besvare i denne posten.
Med API menes et standardisert grensesnitt for utveksling av data. Fra engelsk Application Programming Interface (API). Problemet det løser er at data har vært fanget inne i applikasjoner bygd for et spesifikt formål. Vi har i dag egne IT-systemer for HR, lønn, regnskap, fakturering, kundeoppfølging (CRM) og produksjon (ERP). Som ikke snakker med hverandre. Derfor registreres samme data, flere ganger, i forskjellige systemer. Enten gjennom manuell inntasting, eller overføring av filer på diskett eller minnepinne. Så nytteverdien av å koble sammen applikasjoner som brukes internt i en virksomhet synes åpenbar.
Men det virkelig store potensialet ligger i å gå ett skritt videre; å integrere applikasjoner eksternt, utenfor egen virksomhet. God informasjonssikkerhet og tilgangskontroll er en forutsetning for å gjøre dette. For når du åpner en inngangsport (API Gateway) til dine data, trenger du å ha stålkontroll på hvem som får tilgang til hva, og hvilke rettigheter de skal ha for å opprette, lese, oppdatere eller slette data. Teknologien som muliggjør dette eksisterer i dag, og kalles en integrasjonsplattform (API management system). Med identitets- og tilgangsstyring som en tjeneste eller del av plattformen. Men det er enda et godt stykke igjen før vi kommer dit at hele samfunnet er sammenkoblet, på tvers av sektorer og virksomheter, gjennom API.
Når jeg skal forklare nytteverdien og mulighetene datadeling gjennom API gir, bruker jeg ofte denne figuren:
Data er en ressurs som kan og bør gjenbrukes
Start med offentlig tilgjengelig data, fra nasjonale fellesløsninger som for eksempel Folkeregisteret, Matrikkelen eller Enhetsregistret. Digitaliseringsdirektoratet har laget en oversikt over tilgjengelige løsninger her. Det er dumt å registrere data som allerede finnes fra før, en gang til. Ikke bare fordi det er bortkastet arbeid, men også fordi det øker risiko for feil. Datakvaliteten blir dårligere når for eksempel samme person står oppført flere ganger på grunn av stavefeil, med eller uten mellomnavn, tidligere adresse og lignende årsaker som fører til dårlig datakvalitet.
Trinn to handler om å produsere egne data til eget bruk. Det er her de fleste er i dag, med IT-systemer som er designet til et bestemt formål. De sammenlignes ofte med «siloer», eller «monolitter». Men det er også behov for å skaffe nye data, fra ting som er tilkoblet nettverk (Internet of Things). Et eksempel er avfallsbeholdere med sensor som varsler når fyllingsgraden når et forhåndsdefinert nivå. Det gir avfallsselskapet mulighet til å planlegge tømmingen og optimalisere innsamlingsruten.
Trinn tre handler om å koble data fra flere kilder for å få ny innsikt. Til å gjøre den jobben bruker vi en integrasjonsplattform for sammenkobling og analyseverktøy for å omsette data til informasjon, kunnskap og læring. Å gå fra historisk rapportering av hva skjedde? Til spørring i sanntid hva skjer? Til prediksjon av hva kommer til å skje? er superspennende og høyaktuelle problemstillinger hos mange av kundene jeg samarbeider med.
Trinn fire handler om å gjøre våre data tilgjengelig for andre. Data, som ikke må være konfidensielle, både kan og bør gjenbrukes. Verdien av dataene øker ved gjenbruk, uten å forringes. I motsetning til andre råvarer blir oppbrukt. Men her trengs det nye forretningsmodeller som fanger verdien av data, slik at tilbyderen får en kompensasjon av kjøperen. Det finnes teknologi i dag for mikrobetalinger som kan anvendes til dette formålet. En mikrobetaling er som navnet antyder et veldig lite beløp som overføres i en transaksjon mellom to parter. Transaksjonskostnadene må også være tilsvarende små, om betalingsløsningen skal være bærekraftig. Datafrigjøring skrev vi en kronikk om i 2019: Frigjør våre data for en kollektiv innovasjonskraft. Personlig tror jeg dette er en forutsetning for å høste gevinster i en helt annen skala enn det vi gjør i dag. Det synes jeg er så viktig og interessant at jeg vil følge opp dette temaet i senere innlegg.
Trinn fem handler om å samle inn data for andre enn oss selv. Et eksempel jeg bruker ofte er avfallsselskaper, som dekker et geografisk område regelmessig med bilene sine. Bilene som samler inn avfall, kan bruke sensorer for å knytte kunden til avfallsbeholder, måle vekt, volum, og kvalitet på avfallet. Men hvorfor kan ikke den samme bilen like gjerne ha andre sensorer som måler veiers beskaffenhet, luftkvalitet, hus som står tomme og andre ting av interesse som kan fanges opp? Data, som samles inn lovlig og anstendig, blir en råvare til innovative tjenester. Her er det utrolig mange muligheter for tjenesteinnovasjon og næringsutvikling. Det kommer jeg tilbake til i et senere innlegg.
For de teknisk interesserte er det REST API som regnes for standarden. REST står for REpresentational State Transfer. Når et REST API kalles, vil serveren overføre en representasjon av tilstanden av den etterspurte ressursen. Dette kan være skrevet i Javascript Object Notation (JSON), eXtensionable Markup Language (XML) eller HyperTekst Markup Language (HTML) format. Med andre ord samme format som vi bruker til surfing på internett. Vi lærer oss selvbetjening, og etterhvert vil vi forvente økt funksjonalitet og tilgang til mere data. Muliggjort av API.
Ola Holms læringsblogg 