Hva er strukturert problemløsning?

Postet den mai 21, 2023 av Ola Holm

Svar

Strukturert problemløsning er en metode for å identifisere, strukturere og analysere et problem for å finne fram til den beste løsningen – av flere mulige alternativer. Det er et nyttig verktøy å lære seg for alle som tar beslutninger, eller ønsker å påvirke en beslutning.

Sopra Sterias metode for strukturert problemløsning

Som rådgiver bruker jeg denne metoden i møte med kunder for å forstå problemene som søkes løst, før eventuelle løsninger blir vurdert. Jeg underviser også metoden til andre rådgivere i Sopra Steria for å gi dem nyttige verktøy de kan bruke i sine kundeoppdrag.

Denne posten er ment som et hjelpemiddel og referanselitteratur for alle som deltar på kursene jeg kjører i strukturert problemløsning og kommunikasjon.

Det fins flere metoder for problemløsning å velge mellom. Denne metoden består av fire steg som kort fortalt handler om å identifisere, strukturere, analysere og kommunisere et problem og løsning. De to første stegene handler om å skape klarhet rundt problemet, mens de to siste stegene handler om å velge den beste løsningen av flere mulige, og kommunisere det på en god måte. Metoden kalles ISAK etter forbokstaven i hvert av de fire stegene.

Identifisere problemet
Strukturere problemet
Analysere mulige løsninger
Kommunisere anbefalt løsning

En klassisk feil er å hoppe rett på løsningen, uten å ha forstått hva problemet er. Det resulterer i en rekke dårlige beslutninger, som igjen medfører unødvendige kostnader og manglende måloppnåelse. Bare fordi problemet som søkes løst, ikke er forstått eller tilstrekkelig opplyst. Som regel går det også lang tid før noen oppdager og gjør noe med det. Som konsekvens fins det dessverre utallige eksempler på feilslåtte IT-prosjekter som har kostet dyrt og ikke skapt gevinstene som var forventet.

Alt dette kunne vært unngått om vi hadde brukt tilstrekkelig tid til å stille de riktige spørsmålene for å sikre oss at vi virkelig forstår problemet vi prøver å løse først.

Så hvordan går du fram for å skape mer klarhet i problemstillingen som søkes løst? Det vil de neste avsnittene gi deg svar på.

1 Identifisere

Definere problemet

For å definere problemet starter du med å stille noen åpne spørsmål til kunden for å få en klarere forståelse av hva som er konteksten problemet befinner seg i, og hva som gjør at det må løses nå.

Hva er konteksten?
Hvorfor må det løses nå?
Hvorfor trenger kunden vår hjelp?

Deretter skaffer du deg en oversikt over de viktigste interessentene hos kunden som berøres av problemstillingen.

Hvem er oppdragsgiver?
Hvem er beslutningstaker?
Hvem er påvirkere (dem beslutningstakerne lytter til)?
Er det andre interessenter som berøres av problemet og mulige løsninger?

Når du har fått oversikt over interessentene, er det tid for å undersøke hvilke beslutningskriterier som blir lagt til grunn når en avgjørelse skal tas. For eksempel en beslutning om å anskaffe et nytt IT-system eller videreutvikle og forbedre det man har.

Hva avgjør kundens valg av løsning?
Hvilke finansielle kriterier brukes? (Vekst, lønnsomhet, effektivisering)
Hvilke operasjonelle kriterier brukes? (Bedre måloppnåelse for hva eller hvem)
Er det andre kriterier som legges til grunn? (Samsvar med regelverk)

Det neste er å finne ut om det finnes noen begrensninger, som innskrenker vårt handlingsrom for valg av mulige løsninger. Dermed blir spørsmålet:

Har kunden noen føringer som vil begrense vårt handlingsrom for mulige løsninger? For eksempel: Ingen skal sies opp i prosessen med å kutte kostnader.

Så må du definere hvilket omfang den videre prosessen skal ha og kommunisere dette klart og tydelig til kunden, for å unngå misforståelser.

Hvilket arbeid skal utføres for å løse problemet?
Hva inkluderes spesifikt i arbeidet som skal utføres?
Hva inkluderes ikke i arbeidet?

Her må du selv fortelle kunden hvordan du foreslår å løse problemet. Som regel i form av et prosjekt, med foreslått tilnærming og foreslått gjennomføring.

Nå er det på tide å snakke om hvilken effekt det vil ha å løse problemet. Det kan være for virksomheten, kundene eller brukerne til virksomheten, eller samfunnet. Dermed spør du:

Hvilken effekt vil en løsning på dette problemet ha for kundens måloppnåelse?
Hvor alvorlig er problemet, og er det viktig nok til å det må løses?

Vi er nå kommet gjennom de åpne spørsmålene for å skape en klarere forståelse av hva problemet går ut på og i hvilken kontekst det eksisterer i. Dermed kan vi oppsummere det første steget med å definere problemet, og det gjør vi i form av å formulere et spørsmål, som vi kaller det det grunnleggende spørsmålet som skal besvares.

Hvordan kan det du prøver å oppnå oppsummeres i et lettfattelig og presist spørsmål?

Da er vi ferdige med første steg i ISAK metoden. Jeg har laget en sjekkliste med nøkkelord for at det skal være lett å huske.

Dette grunnleggende spørsmålet tar vi med oss til neste steg i prosessen.

2 Strukturere

Det neste vi gjør er å undersøke hvilke deler problemet består av. Store, komplekse problemstillinger kan alltid brytes ned i mindre og håndterbare deler. Kunsten er å finne ut hvilke deler som hører sammen, og hvordan de bør grupperes.

Lage problem-tre

Verktøyet du bruker til denne jobben er et logisk tre som vi i denne sammenhengen kaller et problem-tre. Det bruker du til å bryte problemet ned i mindre deler og dermed gjør det

Enklere å se logiske sammenhenger
Enklere å gruppere og flytte delområder
Enklere å kommunisere og diskutere.

Det er to typer logiske trær:

Hvorfor-tre svarer på spørsmålet hvorfor eksisterer problemet?
Hvordan-tre: svarer på spørsmålet hvordan problemet kan løses?

Et hvorfor-tre bruker du til å svare på:

Hva er vår hypotese på hva problemet er?
Hva er vår hypotese på årsaken til problemet?

Et hvordan-tre bruker du til å svare på:

Hvilke mulige løsningsalternativer fins?
Hvordan kan den foretrukne løsningen brytes ned i mindre deler?

Et godt problem-tre skal være enhetlig og dekkende. Med enhetlig menes at det fins bare ett sted for hver del. Dersom en del passer flere steder, er ikke problem-treet enhetlig, og mister da sin relevans som verktøy for å forklare hvordan problemet kan brytes ned logisk og konsistent.

Med helhetlig menes at alle relevante faktorer er dekket. Det må være rom for alle delene med relevans for problemet. For å få til dette er det ofte lurt å velge en anerkjent modell som utgangspunkt. For eksempel PTO (Prosess, Teknologi, Organisasjon) for at problem-treet skal være dekkende.

Et godt problem-tre skal ifølge Barbara Minto være MECE – som er forkortelse for Mutually Exclusive, Collectably Exhaustive. På norsk blir det «gjensidig ekskluderende, samlet uttømmende». En enklere måte å si det samme på er at problem-treet skal være konsistent, enhetlig og dekkende.

Prioritere problem-deler

Når du jobber med problemtreet, gjør du samtidig en prioritering av problemkomponentene.

Sorter fakta og ideer
Flytt komponenter opp eller ned
Benytt en kjent modell eller erfaring
Bruk Paretos 20/80 prinsipp

Husk at et problem-tre er et verktøy for å spare tid. Det skal være robust (MECE) men ikke nødvendigvis 100%. Her går mange av seg skoene i et forsøk på å gjøre problem-treet 100% MECE, men det er altså ikke hensikten. Problem-treet er verktøyet du bruker for å forstå bedre problemet som skal løses, ikke et mål i seg selv.

Formulere hypoteser

Nå er du kommet til siste del av å strukturere problemet, og er klar til å formulere hypoteser.

Hva er problemet?
Hva er årsaken?
Hvordan kan det løses?

Her er sjekklisten med stikkord som oppsummerer del to i ISAK metoden.

3 Analysere

Nå er vi klare for å analysere oss fram til den beste løsningen av flere mulige på problemet.

Planlegge analysen

Du starter med å planlegge analysen for å avkrefte eller bekrefte hypotesene. Sentrale spørsmål er

Hvilke data trengs for å verifisere hypotesene?
Hvor finner vi relevante data?
Hvem bør vi snakke med?
Hva forventer vi å finne?

Litt avhengig av problemstillingen kan du nå velge en av to alternativer:

Enten: Lag et storyboard. (For enkle problemstillinger)
Eller: Lag en analyseplan. (For komplekse problemstillinger)

Du skal uansett lage et storyboard i trinn fire, så dersom problemstillingen er enkel og oversiktlig, kan du begynne på et storyboard, som du får beskrevet nærmere i trinn fire. Dermed kan du hoppe over analyseplanen, og i stedet konsentrere deg om hvordan du vil presentere hovedbudskapet ditt og hvordan du skal få det underbygget med data.

Dersom du likevel skal lage en analyseplan, er det en tabell med følgende innhold:

Del fra problem-treet som trenger bevis
Datakilder
Hypotese for hva vi tror vi finner?
Hvem som skal utføre del-analysen og når?
Hvordan skal del-analysen presenteres?

Samle og analysere data

Nå er du klar for å samle og analysere data. Det gjør du ved å

Gjennomføre intervjuer
Sammenstille data
Oppdatere hypoteser

Identifisere og prioritere svar

Det neste steget er å identifisere og prioritere svar – på det grunnleggende spørsmålet som skal besvares – og som du definerte i trinn 1. Verktøyet du benytter til dette er løsnings-treet du laget i trinn 2. Dette løsnings-treet skal

Vise mulige løsningsalternativer
Fordeler og ulemper
Bryte ned den foretrukne løsningen i mindre deler.

Du kommer mest sannsynlig opp med flere tiltak som løser problemet. I så fall er det nyttig å bruke en prioriterings-matrise som gir en oversikt over hvor stor effekt og hvilken innsats som kreves for hvert av de mulige tiltakene.

Hvor stor effekt vil det enkelte tiltaket ha for virksomhetens måloppnåelse? (Lav, middels, høy)
Hvor stor innsats krever tiltaket? (Tid, kost, vanskelighetsgrad)

For tiltak med høy effekt og lav innsats, anbefaler du å gjøre tiltaket nå. Tiltak med lav effekt og høy innsats anbefaler du ikke å gjøre noe med. For alle andre tiltak med rundt middels effekt og middels innsats anbefaler du at de utredes nærmere og vurderes gjennomført på lengre sikt.

Da er du ferdig med å analysere løsninger, og klar til å begynne med forberedelsene til å kommunisere.

Sjekkliste for å analysere mulige løsninger

4 Kommunisere

Oppdatere storyboard

I denne fasen skal du lage eller oppdatere et storyboard påbegynt i en tidligere fase, for å formidle hva du har kommet fram til. Et storyboard er en fortelling og en disposisjon over de lysbildene og tekstelementene du vil bruke for å formidle et hovedbudskap. Hvert lysbilde må også ha et tydelig budskap, som skal kunne leses i overskriften.

Overskriften skal være handlings-orientert og bestå av en fullstendig setning. Bruk bare ord med høy informasjonsverdi, og kutt unødige ord.
Innholdet skal understøtte budskapet i overskriften. Du bruker data som «bevis» på at hovedbudskapet i overskriften stemmer. Lag et hensiktsmessig format for å vise dataene du har samlet inn. Enten i form av kulepunkter, og da skal det være ett poeng for hvert kulepunkt. Eller vis dataene i et diagram eller tabell dersom det er mer hensiktsmessig.
Få overskriftene til å henge sammen, dersom du leser teksten i overskriftene etter hverandre. Fjern eller legg til lysbilder for å gjøre historien logisk, presis, relevant og forståelig. Sørg for at budskapet er tydelig og noe som er verdt å få med seg for mottakerne.

Ferdigstille materialet

Du er nå klar for å ferdigstille materialet. Det gjøres etter pyramideprinsippet, som er en måte å strukturere ideer slik at de blir enklere å forstå. Prinsippet sier at den mest effektive måten å kommunisere et budskap på, er å gi svaret eller den anbefalte løsningen først, og deretter begrunne det med argumenter som er strukturert i en logisk rekkefølge, og underbygget med data som bekrefter at det du fremlegger er sant.

Det er fire regler som følger av pyramideprinsippet:

Start med svaret. Kommuniser svaret, konklusjonen eller anbefalingen umiddelbart, ikke på slutten. (Bottom Line Up Front: BLUF)
Lag en kontekst. Sett budskapet (svaret) i en kontekst gjennom fire faste punkter: Situasjon, Komplikasjon, Spørsmål og Svar
Grupper argumentene: Grupper lignende innsikt i det samme argumentet, og tenk gjennom hvilken rekkefølge de bør komme
Støtt argumentene med data: Sørg for at du har data som støtter hvert argument slik at de ikke kan bestrides

Vekk interessen hos mottakeren for det du ønsker å formidle med en god problemstilling og hvorfor den er verdt å løses nå. Ved å lage et innledende sammendrag i form av en kort historie, setter du konteksten for hovedbudskapet, og forbereder mottakerne på det du vil fortelle dem. Innledningen består av fire faste punkter:

Situasjon: Nåværende omstendigheter som alle er enige i
Komplikasjon: Forstyrrende hendelse som gjør at den nåværende situasjonen er uakseptabel, og må gjøres noe med.
Spørsmål: Det grunnleggende spørsmålet som må besvares
Svar: Din foreslåtte handlingsplan for å løse problemet.

På engelsk forkortes Situation, Complication, Question, Answer til huskeregelen SCQA. De to siste punktene kan slås sammen, slik at spørsmål og svar blir til den foreslåtte løsningen og det som er hovedbudskapet ditt. Dermed blir strukturen: Situasjon – Komplikasjon – Løsning.

Et lite tips: Bruk SCQA om du skal fortelle noen hva du gjør i jobben din og hvordan du skaper verdi for kundene og organisasjonen du er ansatt i. Det er en god trening i å praktisere strukturert problemløsning og kommunikasjon, både for deg selv og for dem du skal kommunisere med. Som konsulenter skaper vi verdi av å løse problemer sammen med kundene, og verdien for kunden øker dersom vi blir flinkere til å skape klarhet i problemet som skal løses før vi begynner å snakke om løsningen.

Presentere anbefalt løsning

Når du har storyen på plass og lysbilder som understøtter det du skal si, er du klar for den siste delen, som går ut på å øve fremføring, slik at du kan presentere budskapet med overbevisning og autoritet.

Det er viktig å ha gode lysbilder og øve seg på å fremføre budskapet, fordi kvaliteten på arbeidet vi utfører ofte blir bedømt ut fra det som presenteres i dokumenter eller møter, og du får bare en sjanse til å gi et førsteinntrykk.

Her er sjekklisten for alle fire stegene i ISAK metoden for strukturert problemløsing og kommunikasjon.

Til slutt vil jeg anbefale deg å ta i bruk disse verktøyene i daglig arbeid, siden det har liten nytteverdi å kjenne teorien, uten å praktisere det i hverdagen. Metoden for strukturert problemløsning og kommunikasjon vil hjelpe deg til å bli en bedre rådgiver slik at du kan jobbe mer effektivt og skape større verdi i arbeidet du legger ned i kundeprosjekter og ellers.

Hva er en digital plattform?

Postet den september 23, 2021 av Ola Holm

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.

Illustrasjonsfoto av JJ Ying på Unsplash

Hva?

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.

Fakturerbare timer til besvær

Postet den april 13, 2021 av Ola Holm

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.

Illustrasjonsfoto av Diego PH på Unsplash

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!

Verdien av IT-rådgivning

Postet den mars 12, 2021 av Ola Holm

Bruk av konsulenter er kostbart, men nyttig når kompetansen ikke finnes i egen virksomhet. Siden timeprisen er høy, bør det stilles krav til kvalitet og riktig bruk av konsulenter. Aftenposten avdekket kritikkverdig samrøre mellom PwC og Direktoratet for e-helse, som medførte at direktøren sluttet. En pågående debatt aktualiserer spørsmålet: Hvilke oppgaver bør IT-konsulenter benyttes til?

Innovasjon og effektiv ressursbruk

Kanskje var det derfor Aftenposten stilte finansminister Jan Tore Sanner spørsmål om konsulentbruk i Staten på generelt grunnlag. Finansministeren svarte; «konsulenttjenester benyttes blant annet for å ha midlertidig tilgang til oppdatert spisskompetanse, f.eks. i forbindelse med IKT-prosjekter.»

Sanner utdypet svaret: – «For staten, i likhet med kommuner og mange private virksomheter, vil det ikke være mulig eller bli svært dyrt å ha fast ansatte med all spisskompetanse som trengs i IKT-prosjekter. Generelt kan bruk av konsulenter bidra til innovasjon og effektiv ressursbruk i staten, og til å hindre budsjettoverskridelser på store investeringer.»

Jeg er enig med finansministeren. Men gevinster forutsetter god rolleforståelse og riktig bruk av konsulenter på områder som styrker kjernen og bygger for fremtiden. Da snakker vi om utviklingsoppgaver og tilførsel av spisskompetanse som utfyller og kompletterer egen kompetanse. Det jeg har erfart gjennom mange år som konsulent, er at rolleforståelsen og samspillet mellom konsulenten og oppdragsgiveren er avgjørende for å oppnå suksess.

En god rådgiver skal ikke bare løse oppdraget, men også utfordre oppdragsgiver i å formulere problemstillinger. Det sikrer fokus på å løse de riktige problemene, ikke bare fokus på å løse problemet riktig. Dette er omstridt, fordi noen betrakter konsulenter som rene leverandører og ikke rådgivere. Jeg opplever også at det er stor forskjell på konsulenter. Noen er «leverandører» som gjør en jobb på bestilling, mens andre er «partnere» som løser større oppdrag sammen, gjennom samarbeid i tverrfaglige team fra begge parter.

Tillit er et ord som staves likt begge veier, og en helt nødvendig forutsetning for vellykket IT-rådgivning. Jeg tror tillitsbaserte samarbeidsformer gir mer verdi for begge parter. Men tillit må bygges, og spørsmålet er hvordan? Jeg tror svaret kommer an på hvilke oppgaver vi som konsulenter blir satt til å gjøre. Som del av rådgivningen må vi faktisk bidra til dette selv. Det som er bra for kundene, er også bra for oss. Dessverre tenker ikke alle slik, noe saken med PwC og Direktoratet for e-helse demonstrerer.

Operasjonell og strategisk rådgivning

For å synliggjøre hva jeg tror er en god utnyttelse av IT-konsulenter, har jeg laget en firefeltstabell. (Ja, jeg liker firefelts-tabeller). Hvis vi deler inn oppgavene etter hvor komplekse de er og hvor stor effekt de har, får vi to akser. Den ene viser kompleksitet (lav – høy), og den andre viser effekt (lav – høy).

I feltet nede til venstre har oppgavene lav kompleksitet og lav effekt. Her mener jeg det er feil å bruke konsulenter med høy timepris. En bedre løsning vil være å la oppgavene ligge, omdisponere egne ressurser, eller leie inn en vikar fra et vikarbyrå. Dette vil være langt billigere, og mer kosteffektiv ressursbruk. Jeg har dessverre opplevd litt for ofte at veldig dyktige (og kostbare) konsulenter blir satt til enkle oppgaver, noe som ikke er bra for kunden eller konsulenten. Effektiv ressursutnyttelse er det definitivt ikke.

I feltet oppe til venstre har oppgavene lav kompleksitet og høy effekt. Det handler om punktvis forbedring, hvor kundene har behov for en spesifikk spisskompetanse. Her finner vi de aller fleste konsulentoppdragene. Typiske oppgaver er etablering og innføring av tiltak av typen «Lean» prosessforbedring, IT-rammeverk, informasjonssikkerhet, personverntiltak, anskaffelse av nye IT-systemer osv. For en konsulent med den aktuelle spisskompetansen, er oppgavene relativt enkle. For kunden er et oppdrag tidsavgrenset, har lav risiko, og kan avsluttes om det ikke gir de forventede effektene. Leveransen er ofte en rapport med noen anbefalinger. Så blir det opp til kunden å implementere tiltakene og realisere gevinster. IT-rådgivning i denne kvadranten er operasjonell, og gevinster er hovedsaklig knyttet til resultatmål.

I feltet oppe til høyre har oppgavene høy kompleksitet og høy effekt. Det handler om transformasjon fra en tilstand til en ny, og krever koordinerte endringer i teknologi, kompetanse, prosesser og organisasjon. Ofte samles disse prosjektene i en portefølje under ett strategisk program med et fiffig navn («Virksomheten 2.0» eller lignende), og havner i kategorien «digital transformasjon». De kjennetegnes av høy usikkerhet og risiko, fordi det er kostbart og vanskelig å forutse hvordan endring ett sted påvirker andre elementer et annet sted. Min erfaring er at det er nødvendig å bruke virksomhetsarkitektur som verktøy for å dele opp problemstillingen i mindre deler. Dette har jeg skrevet om i et tidligere innlegg: Verdien av virksomhetsarkitektur. Behovet for ledelse er åpenbart, og det har jeg også skrevet om i et tidligere innlegg: Daglig leders rolle i en transformasjon. IT-rådgivningen i denne kvadranten er strategisk, og gevinster knyttes til måloppnåelse av programmets effektmål og reduksjon av operasjonell risiko for virksomheten, ikke bare IT.

I feltet nede til høyre har oppgavene høy kompleksitet og lav effekt. Det handler om sanering av utdaterte systemer og integrasjoner som skaper unødvendig kompleksitet. Det har høy risiko, på grunn av kompleksitet som gjør det vanskelig å forutse konsekvens av å endre eller fjerne deler en ikke helt forstår, eller har oppdatert dokumentasjon over. Derfor unngår mange å sanere utdaterte IT-systemer, selv om de nok har en viss forståelse av at det bør gjøres. Teknisk gjeld bygges over tid, og må nedbetales før rentene løper løpsk. Effekten av renters rente gjør det nødvendig å sanere gammel IT-infrastruktur og utdaterte applikasjoner før den operasjonelle risikoen blir uakseptabel. Teknisk gjeld har jeg også beskrevet i et tidligere innlegg: Hva er teknisk gjeld? IT-rådgivning i denne kvadranten er strategisk og gevinster knyttes til reduksjon av operasjonell risiko.

Verdien av IT-rådgivning er stor for en kunde som ikke har spisskompetansen selv. Effekten av rådgivningen øker i takt med omfanget av endringer som iverksettes som resultat. Endringer er nødvendig for å gripe muligheter, men medfører også risiko.

Jeg mener en god operasjonell IT-rådgiver skal bidra til konkret, målbar forbedring innen et avgrenset område hos kunden. En god strategisk IT-rådgiver skal bidra til konkrete strategiske valg, og belyse muligheter og risiko knyttet til alternativene. IT-rådgivning skal bidra til å gjøre risikoen håndterbar for kunden slik at transformasjonen kan gjennomføres med en akseptabel risiko.

For å lykkes som IT-rådgiver, tror jeg det er viktig at vi tenker nytt for å utnytte det fulle potensialet i digital teknologi. Det betyr at vi må både forstå og utfordre eksisterende verdiskapning hos kundene våre på en konstruktiv måte. Det gjør vi gjennom en god dialog preget av relevant innsikt som resulterer i læring for både oppdragsgiver og rådgiver.

Å tenke nytt for å utnytte det fulle potensialet i ny teknologi har jeg også skrevet om i et tidligere innlegg: Hva er en digital strategi?

Ola Holms læringsblogg

Uferdige ideer og spissformulerte problemstillinger

Stikkordarkiv: IT-rådgivning