Ola Holms læringsblogg

Hva betyr kundesentrisk?

Kundeorientering er en måte å tenke på som setter kunden i sentrum for egen strategi og kultur. Målet er å skape verdi for kunden, og gjennom det lojalitet til egen merkevare. Men det er forskjell på uttalte og faktiske verdier hos dem som hevder de setter kunden i sentrum, men som ikke evner å gjøre det i praksis.

Illustrasjonsfoto av Grooveland Designs på Unsplash

Hvorfor?

Det er utfordrende å endre fokus – fra egen virksomhet, produkter og tjenester – til kundene og deres behov. En god start er å stille det grunnleggende spørsmålet: Hvem er vi til for? For svaret er – som de fleste vet – kundene (eller brukerne i offentlig sektor). Fordi sluttkunden er den ultimate mottakeren av produktene eller tjenestene som produseres i virksomheten.

Dette vet de som har kontakt med kunder eller brukere, og har derfor et bevisst kundefokus. Medarbeidere i andre og tredje linje bør også ha et like klart kundefokus, for de produserer interne tjenester som gjør dem som står i første linje – kundefronten – i stand til å levere gode tjenester til sluttkundene. Slik skapes verdier – for kundene – i en verdikjede.

Dessverre glemmer mange «hvem vi er til for», og fyller dagene med andre gjøremål som skyver kundefokuset lengre ned. Det medfører at interne gjøremål blir sidestilt, eller sågar prioritert høyere enn eksternt orienterte oppgaver. Dette skjer i overraskende mange virksomheter i dag.

Konsekvensen av manglende kundefokus over tid, er at kvaliteten på det som produseres gradvis forringes og mister relevans. Resultatet blir hyppigere feil som bidrar til redusert omdømme, og i ytterste konsekvens kroken på døren for dem som lever i et konkurranseutsatt marked.

Jeg tror kundesentriske virksomheter skaper større lønnsomhet for eierne, mer engasjerte ansatte og mer fornøyde kunder. Av samme grunn tror jeg brukersentrerte offentlige virksomheter løser samfunnsoppdraget sitt bedre, med mer engasjerte medarbeidere og fornøyde innbyggere som effekt.

Ett trekk som kjennetegner virksomheter som er virkelig kundesentrisk, er at de leverer produkter og tjenester som er designet med en dyp forståelse av kundens behov. De klarer også å fange opp hvordan behovene endres over tid – i takt med endringer i omgivelsene og konteksten kundene befinner seg i.

Hva?

Å sette kunden i sentrum – kundesentrisitet – er et tankesett, som betyr at uansett når en beslutning tas, så vurderes hvilken effekt den vil ha for sluttkundene. Det motiverer oss til å:

Fokusere på kunden – ved å segmentere og innrette tilbudet mot spesifikke, målrettede brukersegmenter.
Forstå kundenes behov – ved å investere tid i å identifisere ikke-uttalte behov og underliggende problemer.
Tenke og føle som kunden – ved å se verden fra kundens perspektiv.
Utvikle helhetlige produkter – ved å designe sammensatte løsninger for kundenes sammensatte behov.
Kjenne kundens verdi – ved å bevege oss forbi transaksjonsbasert mentalitet og heller fokusere på en tydelig forståelse av hvordan kunden får verdi fra løsningen.

Grunnlaget for å få til dette er data, som må identifiseres, samles inn og analyseres. Ikke som en innledende øvelse, utført kun én gang. Men gjennom en kontinuerlig prosess, som gjennom eksperimentering og læring, systematisk forbedres over tid. Det gjelder både prosessen, analysene og beslutningene. Da snakker vi om organisatorisk læring, hvor opparbeidet innsikt om kundene benyttes til kontinuerlig forbedring av egne produkter.

Vi kan skille mellom to typer analyser:

Markedsanalyse – for å forstå markedet og hvordan det utvikles (i sanntid og fremtid). Fokuserer på «hvem» og «hva». Vurderer hva store segmenter sier, og hva de ønsker å kjøpe. Brukes som beslutningsgrunnlag for produktstrategi.
Brukeranalyse – for å forstå brukerne og deres behov. Fokuserer på «hvordan» og «hvorfor». Vurderer hva mindre grupper gjør, hvordan de vil bruke produktet og hvilke krav som stilles. Brukes som beslutningsgrunnlag for produkt-design.

Analyse av oppdaterte data fra markedet og brukerne er viktig for alle som ønsker å bli mer kundesentriske. For her, som ellers gjelder de samme reglene: Jo mere data, og bedre datakvalitet (korrekt, fullstendig, aktuell, konsisent, anvendelig, presis, strukturert, relevant) – jo bedre og mer treffsikker blir analysen. Det er ofte her jeg, eller andre konsulenter kommer inn med spisskompetanse – for å bistå våre kunder med å få tak i relevante data, av god kvalitet, og sammenstille dem for analyse.

Digitale plattformer for deling av data mellom ulike kildesystemer, er en forutsetning for å få dette til. Videre må prosesser for innsamling og sammenstilling av data etableres. Det er også behov for strukturerte informasjonsmodeller som skal brukes til å tolke hva de ulike dataene betyr. Når dette er på plass, kan vi analysere kundebehov med en helt annen kvalitet og presisjon enn tidligere.

Målet er å utarbeide et godt beslutningsgrunnlag for å utvikle produktene slik at de skaper (mer) verdi for kundene. Når IT-infrastruktur, prosesser, modeller og metoder er på plass, starter den organisatoriske læringsprosessen med mål om kontinuerlig utforskning og forbedring av beslutningsgrunnlag og implementering av egen strategi.

Hvordan?

Design Thinking er en kundesentrisk utviklingsprosess med mål om å skape attraktive og bærekraftige produkter som kan videreutvikles og forbedres over tid, i takt med endringer i omgivelsene.

Metodikken vektlegger empati med kunden, for å forstå problemet og konteksten som søkes løst først. Deretter designes den beste løsningen på problemet. Den innarbeides så i et nytt eller eksisterende produkt, som videreutvikles kontinuerlig basert på ny innsikt og data.

Målsettingen med Design Thinking er å utvikle produkter og løsninger som er:

Attraktive (Desirable) – Vil kundene ha produktet?
Gjennomførbare (Feasible) – Kan vi levere?
Levedyktige (Viable) – Skaper produktet mer verdi enn kostnaden ved å lage det?
Bærekraftige (Sustainable) – Forvalter vi produktet godt gjennom hele livssyklusen?

Produkter utvikles og forbedres kontinuerlig basert på ny innsikt (data) fra markedet og brukerne. Les gjerne smidig produktutvikling i praksis, om du vil vite mer om Design Thinking og et praktisk eksempel på hvordan metodikken kan benyttes.

Refleksjon

Jeg har opplevd mange virksomheter som er kundeorienterte. Medarbeidere som er oppmerksomme, service-innstilt, vennlige, og oppriktig interessert i å imøtekomme kundenes preferanser og behov. Kanskje ikke så rart, siden alle med erfaring fra kundebehandling har lært at kunden kommer alltid først og må behandles godt.

Men det er forskjell på å være kundeorientert og det å bli kundesentrisk som organisasjon. Tankesettet – å sette kunden i sentrum for egen strategi og kultur- er det samme. Forskjellen ligger i evnen til å implementere strategien. Til det kreves kompetanse og ressurser for å kontinuerlig utforske hva kundene vil ha, og hvordan de får verdi av å bruke egne produkter og tjenester. Det må gjøres metodisk og være basert på fakta.

Datadrevet analyse for å ta gode beslutninger, og evne til å skape kundeverdi raskt gjennom kontinuerlig produktutvikling, er helt avgjørende for å lykkes. Jeg opplever at mange virksomheter ønsker å bli mer datadrevet i sin kundetilnærming, for å bedre forstå kundene sine og hvordan de får verdi av egne produkter eller tjenester. Men de trenger hjelp til å komme i gang, og bygge evne til å gjøre det i praksis. Det er en typisk oppgave for konsulenter, og slik kommer jeg eller andre inn i bildet.

Les gjerne mer om:

Hva er endringsledelse?

Ordet endringsledelse er satt sammen av «endring» og «ledelse», og er faktisk et fag som har blitt forsket på og kan studeres ved universiteter og høyskoler. To spørsmål trer dermed frem, som denne posten vil besvare:

Hva er endringsledelse?
Er det forskjell på endringsledelse og ledelse generelt?

Aktuelt

Spørsmålene ble aktualisert i sommer i DNs portrettintervju av Nicolay Tangen, som er leder for oljefondet. I overskriften ble han sitert slik:

Endringsledelse? Et idiotisk begrep. Det er så kørka at det er helt ufattelig.
Nicolay Tangen

Et lurt journalistisk grep for å fange lesernes interesse, uten tvil! Så resulterte det også i en hel rekke reaksjoner og leserinnlegg fra fagfolk som var mer eller mindre fornærmet på vegne av faget sitt og ønsket å belære Tangen om endringsledelse og dens nødvendighet.

Men Tangens poeng var dette: For ham er det å lede endringer en selvfølge. Fordi en leder skal ta beslutninger og sørge for iverksetting og implementering av beslutningene. Noe han har helt rett i.

Problemet er bare at mange endringer IKKE blir ledet, slik en burde forvente. Derfor er det behov for endringsledelse. I tillegg er det alt for mange eksempler på dårlig ledelse som har medført at ønskede effekter av planlagte endringer har uteblitt. For noen blir løsningen å søke ekstern bistand, og slik kommer jeg eller andre inn for å bistå med kompetanse.

En viktig årsak til at endringsinitiativer feiler er motstand mot endringer, som kan forklares av høyst rasjonelle årsaker.

Illustrasjonsfoto av JESHOOTS.COM på Unsplash

Fundamentet

Kurt Lewin lanserte i 1951 en tre trinns modell for å lykkes med endringer:

Unfreeze (Tin opp)
Change (Endre)
Freeze (Frys)

Hans arbeid er regnet som fundamentet i endringsledelse. Lewins poeng var at det er viktig å skape oppfatningen om at en endring er nødvendig, for deretter å bevege seg mot det nye, ønskede atferdsnivået og til slutt befeste den nye atferden som normen. Psykologen og forskeren Lewins arbeid var en del av pensum da jeg studerte ledelse på Krigsskolen for snart 30 år siden, og står fremdeles i lærebøkene som grunnleggende teori.

Videreutviklingen

John P. Kotter, en professor ved Harvard Business School, skrev i Harvard Business Review 1995 artikkelen: «Leading Change: Why Transformation Efforts Fail». (Ledelse av endring: Hvorfor transformasjoner feiler). I 1996 ble arbeidet hans også publisert i boken «Leading Change», hvor han lanserte en «oppskrift» i 8 steg for å lykkes med endringer:

Create a sense of urgency (Skap en følelse at noe må gjøres nå)
Build a guiding coalition (Etabler nødvendig støtte)
Form a strategic vision and initiatives (Lag en strategisk visjon og initiativer)
Enlist a volunteer army (Mobiliser en frivillig hær)
Enable action by removing barriers (Muliggjør handling ved å fjerne hindringer)
Generate short term wins (Skap kortsiktige gevinster)
Sustain acceleration (Oppretthold akselerasjon)
Institute change (Gjør endringene til den nye normalen)

De fire første stegene er i realiteten en videreutvikling av det Lewin betegnet som «tin opp». I følge Kotter er feilen mange ledere gjør, å hoppe over disse trinnene og starte rett på trinn fem. Dermed oppstår motstand som en naturlig reaksjon, og medfører at endringen ikke får ønsket effekt og mislykkes.

Kultur

En årsak til motstand mot endringer er organisasjonskulturen, som i sin enkleste form handler om «hvordan vi gjør ting hos oss». Kultur kan både fremme og hemme endringer. Organisasjonskulturen består blant annet av felles verdier og grunnleggende antagelser, og hjelper medlemmene med å løse to typer problemer:

Ekstern tilpasning
Intern tilpasning

Med ekstern tilpasning menes håndtering av eksterne utfordringer. En organisasjon må tilpasse seg omgivelsene, og organisasjonskulturens rolle er å utvikle en felles forståelse for hvilken misjon, mål og midler organisasjonen har, og en enighet om hvilke kriterier som skal gjelde for prioriteringer og vurderinger av eksterne forhold.

Med intern tilpasning menes den interne samhandlingen mellom medarbeidere. For eksempel gjennom felles språk og begrepsapparat, vennskap, ideologi, belønning og straff. Organisasjonskulturen skaper et felleskap hvor man jobber sammen, for hverandre.

Denne innsikten ble først beskrevet av Edgar Schein i 1987, en forsker og forfatter som har vært en sentral bidragsyter i faget organisasjonspsykologi. Han beskrev også organisasjonskulturen som flere lag utenpå hverandre, omtrent som i en løk.

Observerbare ting
Grunnleggende verdier
Underliggende antagelser

Det ytterste laget består av ting vi kan observere, og inkluderer symboler, arkitektur, språk, teknologi, produkter, kleskode, prosesser, organisasjonskart, myter og historier,

Det mellomste laget består av grunnleggende verdier og overbevisninger. Her kan vi skille mellom uttalte og faktiske verdier, som betyr at de offisielle verdiene ikke nødvendigvis etterleves i det daglige.

Det innerste laget består av grunnleggende, underliggende antagelser. Disse har blitt formet gjennom organisatorisk læring, og representerer det sterkest kulturelementet. Med organisatorisk læring menes «Slik gjør vi det hos oss, fordi vi har lært gjennom erfaring at denne tilnærmingen gir det beste resultatet.»

Organisasjonskulturen vil påvirke atferden til organisasjonens medlemmer. Som leder er det derfor nyttig å forstå hvordan kultur skapes, opprettholdes og påvirker atferd. Forhåpentligvis kan en dermed påvirke kulturen, slik at strategier blir implementert og gjennomført, fremfor å bli møtt med motstand.

Dette var også poenget bak det berømte sitatet «Kultur spiser strategi til frokost», som ble tilskrevet «ledelse-guru» Peter Drucker av Mark Fields i 2006. Strategien er bare så god som kulturen tillater den å være. Det hjelper ikke med en god strategi, når den ikke lar seg implementere på grunn av kulturen.

Culture eats strategy for breakfast.
Peter Drucker

Les gjerne mer om strategi i en tidligere post: Strategiprosess til besvær

Hva er forskjellen?

Endringsledelse og ledelse er slik jeg ser det, to sider av samme sak, hvor ledelse er overordnet og endringsledelse underordnet. Endringsledelse handler om en metodisk tilnærming til å implementere beslutninger om endringer. For meg koker derfor endringsledelse ned til nettopp dette; en metodikk og tilnærming for å implementere strategi. Som Levins tre steg og Kotters åtte steg er eksempler på. I senere tid er det også vokst fram rammeverk og sertifiseringer innen endringsledelse som handler om det samme.

Ledelse favner bredere, og betyr for meg å vise vei, gå først og påvirke andre til å oppnå felles mål. Å lede gjennom eksempel, være en rollemodell og bry seg om mennesker er viktige personlige egenskaper for en god leder. Som alle andre, er også jeg formet av det jeg har lært gjennom min lederutdanning og praktiske erfaring fra å lede andre mennesker mot felles mål.

For meg handler ledelse om to grunnleggende ting; å løse oppdraget og ta vare på folkene sine. Endringsledelse handler om en metodisk tilnærming til å implementere strategi for å sikre at intensjonen bak, og ønsket effekt av strategien oppnås.

Hva er en digital transformasjon?

Et stort spørsmål med flere svar, som er avhengig av perspektivet til den du spør. Mitt utgangspunkt er dette: Digitalisering er transformasjonen fra at IT er et støtteverktøy i virksomheten til at det blir en del av dens DNA. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi. Denne definisjonen er utdypet i posten IT-lederens nye rolle.

Illustrasjonsfoto av Javier Allegue Barros på Unsplash

Tverrfaglige team

Det er lurt å bruke flere perspektiver, for da kan vi belyse problemstillingen fra ulike sider. Spesielt når omgivelsene er omskiftelige og behovet for smidighet og korte beslutningsveier er stort. En faktabasert diskusjon mellom kompetente personer med ulike perspektiver er verdifullt, og hovedbegrunnelsen for å sette sammen tverrfaglige team. De benevnes også som kryssfunksjonelle team – fordi teamene løser komplekse oppgaver med sammensatt kompetanse. Det er som regel slik vi finner de beste løsningene – sammen.

Kanskje er bruk av kryssfunksjonelle team det viktigste enkeltgrepet som kan gjøres for å fremme innovasjon og håndtere kompleksitet i egen virksomhet.

Bruk av kryssfunksjonelle team åpner også for å ta inn konsulenter som kan tilføre ekstern kompetanse. Slik kommer jeg inn som rådgiver og sparringspartner for ledere hos kundene våre.

Jeg tror ikke det fins noen «silver bullet» for hvordan en transformasjon bør utføres, for det kommer helt an på virksomheten og konteksten den befinner seg i. Derfor er mitt råd å styre unna alle dem som tilbyr lettvinte løsninger og «quick fix» på komplekse problemstillinger. Jeg tror mer på analytisk problemløsning, sunn fornuft og prinsippene for smidig utvikling – som du kan lese mer om i posten smidig tilnærming til utfordrende prosjekter.

Lederskap

Transformasjon er en omfattende endring som medfører stor usikkerhet, for både eiere, ledere og medarbeidere. Derfor trengs det godt lederskap og styring. Lederskap er personorientert og styring er systemorientert.

Lederskap bidrar til å angi retning, skape endring og sette mål. For meg betyr ledelse å gå først, og handler om å ivareta medarbeidere, det sosiale og mellommenneskelige forhold.

Styring er påvirkning som utøves indirekte blant annet gjennom formelle strukturer, formaliserte prosedyrer, rutiner og kontrollfunksjoner.

Begge deler er nødvendig for å få ønsket effekt. Det er ofte her jeg kommer inn som rådgiver, når en leder trenger en sparringspartner.

I Forsvaret lærte jeg at ledelse handler om to grunnleggende ting; å løse oppdraget og ta vare på folkene sine. I en digital transformasjon er oppdraget som regel gitt av eierne, representert ved styret, til daglig leder: Gjennomfør forretningsstrategien og digitaliser det som er mulig for en bedre måloppnåelse. Ofte er det mål for produksjon, vekst, lønnsomhet, bærekraft, kundetilfredshet, medarbeidertilfredshet, omdømme, og/eller samfunnsoppdrag. Les gjerne mer om daglig leders rolle i en transformasjon fra en tidligere post.

Strategi

Digitalisering er ikke et mål, men et middel for å styrke kjernevirksomheten og bygge evne til å skape verdi i framtiden. Det krever en forståelse av hvordan verdier skapes i dag og hvordan teknologi kan utnyttes for å skape verdi på en bedre, raskere, billigere eller sikrere måte. For å få det til, må vi utfordre måten vi tenker på. Det kan du lese mer om i posten strategiprosess til besvær.

Det jeg ser, er at de fleste virksomhetene har startet digitalisering, men mangler en god tilnærming og plan for hvordan digitaliseringen skal forbedre måloppnåelsen av kjernevirksomheten. Det kan du lese mer om i posten hva er en digital strategi?

Jeg har lært at strategiutvikling og -gjennomføring er like viktig som selve strategien. Fordi omgivelsene og forutsetningene endres stadig raskere, må de som gjennomfører strategien forstå intensjonen, og ha nødvendig handlefrihet til å løse oppdraget. Gjennom frihet til å nå målene, vil medarbeiderne søke etter nye og bedre måter å løse oppdrag på. Derfor er delegering av myndighet viktig.

Men frihet betyr ikke uten styring og at alle kan gjøre hva de vil. Det må være en struktur som sikrer felles forståelse av målet, hva som skal oppnås og hvorfor.

I en transformasjon kalles denne strukturen virksomhetsarkitektur, og gir daglig leder mulighet til å manøvrere endringer i organisasjon, prosesser og IT-løsninger på en helhetlig måte som understøtter strategien. Målet er å skape en integrert og samordnet virksomhetsarkitektur som muliggjør innovasjon. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi.

Arkitektur

Problemet oppstår når strategien skal omsettes til praktisk handling, og kompleksiteten i prosesser, teknologi og organisasjon trer fram. Virksomhetsarkitektur er en strukturert metodikk for å identifisere hvilke endringer som må gjennomføres for å nå forretningsmålene. Det handler om å forstå hvordan virksomheten er satt sammen, og deretter dele oppgaven med å endre den i håndterbare deler. Nesten som legoklosser.

Enkelhet er et viktig prinsipp: Å ikke dokumentere mer arkitektur enn nødvendig – men nok til å ta informerte beslutninger – er essensielt. Til det kreves evne til å prioritere hva som skal dokumenteres og holde dokumentasjonen oppdatert. Det er utfordrende for mange.

Arkitekturen kan deles inn i flere lag (forretning, informasjon, applikasjon, og teknologi). Sikkerhetsarkitektur og arkitekturstyring er gjennomgående for alle lagene, og sørger for at de henger sammen.

Sammenheng mellom strategi, virksomhetsarkitektur og løsningsarkitektur

Virksomhetsarkitektur beskriver hvordan en virksomhet er organisert, hvordan arbeidsprosesser er satt sammen og hvordan IT-løsninger utnyttes for å produsere verdi. Virksomhetsarkitektur er tett koblet til strategi gjennom mål og målbilder.

Løsningsarkitektur beskriver hvordan applikasjoner sikrer effektiv informasjonsdeling mellom mennesker og maskiner. IT-løsningene er som regel laget av forskjellige leverandører. Som konsekvens oppstår to utfordringer: Teknisk gjeld og deling av data mellom applikasjoner.

Teknisk gjeld

Teknisk gjeld er en metafor som fungerer godt til å forklare strategiske konsekvenser av ulike valg i anskaffelse og utvikling av IT-løsninger. Over tid vil manglende forståelse av slike konsekvenser resultere i operasjonelle utfordringer som hindrer effektiv måloppnåelse av strategiske mål.

Problemet med teknisk gjeld er at det påløper renter – som må betales før eller siden. Problemet vokser med tiden som effekt av renters rente. 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.

Derfor kan det lønne seg å se nærmere på hva teknisk gjeld er, og forstå hvordan den kan håndteres. Det er utdypet i posten hva er teknisk gjeld?

Deling av data

I dag har vi egne IT-løsninger 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; å koble data fra applikasjoner som befinner seg utenfor egen virksomhet. Dette gjøres gjennom standardiserte grensesnitt; Application Programming Interface (API).

Forutsetningen er god informasjonssikkerhet og tilgangskontroll. 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. Dette er utdypet og forklart i posten hva er et API?

Oppsummering

Mitt perspektiv, og svar på spørsmålet i overskriften, kan oppsummeres slik:

Digital transformasjon – er en aktiv respons og endringsprosess – for å gripe muligheter og unngå trusler – som oppstår som konsekvens av endringer i rammebetingelser – som følge av at digitalisering forskyver/forstyrrer/ødelegger maktballansen i markedet og samfunnet.

For meg er en digital transformasjon:

teknologidrevet – at IT går fra støttehjul til drivhjul for virksomheten
datadrevet – kontinuerlig læring og forbedring basert på målbare data
strukturering – samordnet og integrert arkitektur som muliggjør innovasjon
nytenkning – skape verdi for kundene og virksomheten på nye måter
endringsevne – smidig organisering i kompetente, kryssfunksjonelle team
lederskap – delegering, dyktiggjøring og desentralisert styring

Neste post vil komme etter sommerferien, en gang i august.

Ha en riktig god sommer!

Innovasjon i praksis

Begrep som «Design Thinking», «Lean Start-up» og «Agile» benyttes ofte i forbindelse med innovasjonsprosesser. Det er lett å bli forvirret av begrepsbruken, og spørsmålet mange stiller er: Hva betyr det i praksis, og hvordan henger de sammen? For å svare på det, utførte jeg et eksperiment – for å gjøre det praktisk og enkelt å forklare.

Utfordringen som søkes løst, er å kunne hvile samtidig som man fører en seilbåt. Problemet er at benken bak rattet er for lav i forhold til overbygget lengre frem, som medfører at sikten forsvinner når man setter seg ned.

Innovasjonsprosessen

Hensikten med en innovasjonsprosess er å komme raskt i gang med datadrevet produktutvikling for å bygge løsninger som kan testes og gi verdi etter kort tid. Jeg benytter Sopra Sterias innovasjonsprosess, som er basert på tankegodset fra Design Thinking, Lean Start-up og Agile (Smidig på norsk), i den rekkefølgen. Det kommer jeg tilbake til.

Sopra Sterias innovasjonsprosess Lean Next – Del 1

Definer mål

Vi starter med å definere mål, som i henhold til Design Thinking skal være:

Attraktivt (Desirable) (D)
Gjennomførbart (Feasable) (F)
Levedyktig (Viable) (V)

Det er skjæringspunktet mellom disse egenskapene vi er på jakt etter. Å kjøpe ny båt er ikke levedyktig (for dyrt), så vi går for å utvikle et sete som ikke sklir når vi seiler. Målet blir derfor at setet skal se bra ut, være enkelt å feste til rekken, og lar seg bygge av materialer som tåler fuktighet. Kostnadene skal holdes lave.

Generell utfordring

Innsikt/empati fasen handler om at vi «bredder ut» vår forståelse av problemet som søkes løst. Det symboliseres med (<) i modellen. Vi søker alle gode innspill som kan belyse den generelle problemstillingen. Dette er «ja-fasen» hvor alle ideer ønskes velkommen. Vi lager en brutto-liste over mulige problemstillinger som kan være relevant innen rammene av de definerte målene. Er beskyttelse mot regnvær kanskje en mer aktuell problemstilling? Hva med sikkerhet, navigasjon, og god stemning om bord? Vi oppdaterer om nødvendig målene dersom vi kommer på noe nytt.

I defineringsfasen «snevrer vi inn» brutto-listen over problemstillinger, som er symbolisert med (>) i figuren. Til sammen blir symbolene <>, en diamant. Det vi egentlig søker svar på er dette sentrale spørsmålet: «Er problemet stort/viktig nok til at det er verdt å løse?» For eksempel kan bruk av autopilot medføre at båtføreren kan sette seg et annet sted med sikt forover. Men autopilot krever strøm og kan ikke brukes over lange strekk, for da blir batteriet tomt. I tillegg er det mange båter som ikke har autopilot.

Vi oppsummerer med å utvikle hypotese 1: Dette er et problem som er verdt å løse.

Så vi går videre i prosessen.

Spesifikk utfordring

«Hvordan kan båtfører holde i rattet og samtidig sitte avslappet med god sikt forover?»

Igjen «bredder vi ut» gjennom en idéstorming, symbolisert med (<). Vi er på jakt etter å løse dette spesifikke problemet. Dette er «ja-fasen» hvor alle ideer er velkomne. Er det en stol? Hva er den laget av? Hvor stor skal den være? Hvor skal den plasseres? Hvordan skal den festes? Kan den flyttes?

Vi oppsummerer med å utvikle hypotese 2: En båtførerstol er den beste løsningen på vår problemstilling.

Prototypen lages for å skaffe oss data som gir svar på de nevnte spørsmålene. For å komme hit, har vi brukt en «dobbel diamant», fordi prosessen med å åpne og lukke har form som en diamant. Dobbel siden vi har gjort det to ganger- <> <> – Den første diamanten handler om problemet er viktig nok, og den andre diamanten om hvilket løsningskonsept (av flere mulige) som anses å være best egnet.

På bildet ser dere prototypen jeg laget til vårt formål i forgrunnen. Legg merke til festeanordning for å kunne hekte stolen fast på rekka. (I bakgrunnen kan dere også se to andre prototyper til blomsterkasse på hjul, som jeg også sysler med. Det er ellers helt vanlig å jobbe med flere prototyper samtidig)

Løsningskonsept

Nå bruker vi «Bygge – Måle – Lære» metodikken fra Lean Start-up. Vi skal teste prototypen i det miljøet den skal være i, på en ekte båt, som i dette tilfellet er vår egen.

Vi regner med å gjøre tilpasninger, så vi trenger å ta med oss nødvendig verktøy til båten.

Prototypen tilpasses miljøet den skal brukes i

Det første jeg ser når stolen kommer ombord, er at den er rett og slett for stor. Selv om den får plass, hindrer stolen bevegelse til og fra førerplassen. Jeg hadde tatt mål av tilgjengelig plass, men tenkte ikke på at vi skal bevege oss rundt i båten uten hindring av stolen. Derfor må sagen frem, og lengden kuttes med et helt bord. Siden jeg har bygget prototypen selv, vet jeg at det enkleste er å løsne skruene i bakkant på setet og kapper bærebjelkene i ønsket lengde. Så skrus setet fast i ryggen igjen.

Lengden er redusert for bedre fremkommelighet

Det neste jeg observerer er at stolen er for høy i forhold til rekken på båten. Dermed må beina kuttes. Fram med meterstokk, ta mål, tegne rett line og sage etter den.

Så observerer jeg at stolen kan skli sideveis langs rekken. For hindre at stolen sklir under seiling, velger jeg å flytte et tverrgående bord under setet, og sage en åpning som passer til den vertikale delen av rekka. Bordet jeg bruker må også kappes i bredden, siden stolryggen blir smalere, jo lengre opp en kommer.

Flytter et bord slik at det hindrer glidning under seiling

Nå er det på tide med en brukertest, som jeg utfører selv. Testresultatene er lovende. Stolen sitter fast og er ikke til hinder for bevegelse rundt om i båten. Sikten forover er god, og rattet nås fint med den ene hånden.

Akseptansetest av løsning. Resultat: Godkjent.

Vi har nå en fungerende prototype av en båtførerstol som kan videreutvikles og eventuelt produseres i et større antall. Dermed er vi klare for neste fase, som handler om å stabilisere løsningen og skalere opp ved behov. Til dette benytter vi «Agile» eller Smidig på norsk.

Sopra Sterias innovasjonsprosess Lean Next – Del 2

En viktig del av smidig produktutvikling er produktkøen, som er en totalliste over behov for ny funksjonalitet, skalering og stabilisering. (Symbolisert med en stabel av behov, til venstre i figuren). Produktet utvikles i sprinter med varighet 1-4 uker. En sprint planlegges av et produkt-team som prioriterer hvilke oppgaver som skal utvikles. Hver sprint avsluttes med en demonstrasjon av hva som er laget, og det gjennomføres en læringssløyfe kalt retrospektiv ved jevne mellomrom. Vi benytter «Bygge – Måle – Lære» i kombinasjon med «Idé – Produkt – Data» for videreutvikling i gjentagende øvelser.

Poenget er å ta vare på all læring for å kontinuerlig forbedre og videreutvikle produktet. Det er her DevOps kommer inn, et ord som er sammensatt av «Development» (utvikling) og «Operations» (drift). Konseptet går ut på å ta vare på opparbeidet innsikt i en kontinuerlig læringssløyfe mellom utvikling og drift. I motsetning til prosjekter som overleveres fra utvikling til drift hvor innsikten går tapt i overleveringen.

Vårt produkt er ikke en digital løsning, men det kan likevel videreutvikles på flere måter. For eksempel pusset jeg over med sandpapir for å jevne harde kanter. Så bør den males i en farge som passer båten den skal stå på. Videre bør det vurderes om materialbruken kan reduseres for å spare kostnader. For eksempel ved å bruke mindre dimensjon på reisverket. Dette er elementer som går inn i produktkøen. Produktstyringen utføres av produkteier eller produktansvarlig, som avgjør hva som skal produseres i neste sprint.

Innovasjonsprosessen er kundeorientert og datadrevet for å gjøre oss i stand til å skape verdi raskt. For det er markedet som avgjør etterspørselen, og gjennom den behovet for å skalere opp og stabilisere produksjonen. Ikke ledelsen. Deres ansvar er å legge til rette for smidig produktutvikling, med alt det innebærer av transformasjon i egen organisasjon.

Les gjerne min tidligere post Smidig tilnærming til utfordrende prosjekter om du vil vite mer om hvor tankegodset til smidig kommer fra.

Smidig tilnærming til utfordrende prosjekter

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.

Illustrasjonsfoto av jana müller på Unsplash

Antagelser

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.

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.

Strategiprosess til besvær

En av utfordringene med digitalisering er å utvikle en god strategi, som ikke havner i skuffen når strategi-seminaret er over. En strategi skal være realistisk, gjennomførbar og bør introduserer nye måter å tenke verdiskapning på. Hensikten må være å transformere virksomheten og høste gevinstene av digitalisering. For å lykkes må ansvarlige ledere i virksomheten forstå trusselen, nøkkelpersoner må involveres i prosessen og mulighetene digital teknologi representerer må presenteres, analyseres og gripes. Det er avgjørende at både de som tar beslutninger og de som skal gjennomføre strategien, forstår at digitalisering ikke er et mål i seg selv, men et middel for å styrke kjernevirksomheten og bygge verdier for fremtiden.

Illustrasjonsfoto av Jamie Street på Unsplash

Involvering

Strategiutvikling er en prosess som skal sikre en felles forståelse for intensjonen om hva som søkes oppnådd (styrke kjernen og bygge for fremtiden). Fordi en plan sjelden overlever det første møtet med uforutsigbare omgivelser, er involvering av dem som skal gjennomføre planen helt nødvendig, Derfor er strategiprosessen slik jeg ser det, minst like viktig som selve strategien. For den som kjenner intensjonen i en plan, det vil si hva som søkes oppnådd, har bedre forutsetninger for å løse oppgaver for å nå målene, selv om grunnleggende antakelser må endres underveis. Denne innsikten er dokumentert mange ganger opp gjennom historien. Mest kjent er kanskje Eisenhowers sitat: «Plans are nothing, planning is everyting». Han var øverstkommanderende for de allierte styrkene under andre verdenskrig, og senere president i USA,

Min erfaring tilsier at det er styrets oppgave å beslutte om strategien skal være konserverende eller transformerende. Som regel kommuniseres denne ambisjonen som styringssignaler til daglig leder, som er den som eier strategien. Jeg mener forøvrig at forretningsstrategi og digitaliseringsstrategi er to sider av samme sak.

Daglig leder kan velge å delegere oppgaven med å holde i digitaliseringen til en i ledergruppen, ofte en som også har rollen Chief Digital Officer, Chief Information Officer eller Utviklingsdirektør. Ledergruppen må bruke tid på digitalisering, og synligjøre dette gjennom aktiv styring av den strategiske utviklingsporteføljen. Her kommer jeg ofte inn som sparringspartner for ansvarlig leder for å diskutere hvilke strategiske initiativer utviklingsporteføljen skal inneholde.

Utviklingsporteføljen er helt sentral for å realisere strategien, og skal være tett knyttet til daglig produksjon i kjerneprosessene. En felle som mellomledere bør være oppmerksom på, er at dersom de er for langt unna den praktiske produksjonen av tjenester for eksterne brukere eller kunder, vil deres verdibidrag, som i stor grad er administrativt og består av (unødvendig) møtevirksomhet, reduseres i takt med innføring av digitale løsninger for ressursplanlegging, produksjon og rapportering.

Faren for å bli overflødig stiger tilsvarende med at mellomledernes faktiske verdibidrag blir mer synlig i en transparent verdikjede. Så mitt råd til mellomledere for å holde seg relevant, er å unngå denne fellen ved å involvere seg aktivt i verdiskapningen og sørge for å være «hands-on» i tjenesteproduksjonen.

Smidig tankesett og tilnærming

Endringsevne er også nødvendig i skiftende omgivelser. «Agile» eller smidig på norsk, er et fremvoksende tankesett for å fremme innovasjon i virksomheter med opprinnelse fra IT-utviklere som skrev dokumentet Agile manifesto. Poenget ifølge smidig tankesett, er å ikke ha for omfattende planer, men i stedet fokusere på en langsiktig visjon, ha tydelige mål og delegere ansvar til selvstyrte team som realiserer strategien. «Agile» virksomheter henter inspirasjon fra det samme tankegodset som Eisenhower: Det hjelper ikke med detaljerte planer i en omskiftelig verden som snur opp ned på de grunnleggende forutsetningene som planen bygger på.

I en virksomhet som har tatt i bruk smidig prinsipper, søkes det i stedet for omfattende planer, heller å teste ut noe i liten skala først. Hensikten er å lære hvordan en tjeneste eller produkt blir mottatt av kundene, og bruke denne innsikten til å forbedre produktet, før det skaleres opp og distribueres til markedet i stort omfang. Eventuelt trekke produktet, dersom dataene tilsier at kundene ikke vil ha det. På den måten forhindres store og bortkastede investeringer. Denne tilnærmingen og tankegodset bygger på Eric Rice sin «Lean Startup» filosofi, beskrevet i boken hans med samme navn. Innovasjonsprosessen Bygge – Måle – Lære er kjernen i hvordan en kundeorientert og datadrevet virksomhet opererer. Denne filosofien må derfor inn i strategien, og erstatte omfattende planer.

Trusler

Mange virksomheter opplever at digitalisering forstyrrer og ødelegger (disruption på engelsk) de grunnleggende forutsetningene i markedet, slik vi har kjent dem. Et eksempel på dette skrev jeg om i en kronikk i Dagens Næringsliv i 2018: slik vil teknologi endre banktjenestene. Globalisering, digitalisering og forbrukerorientering driver frem bedre, raskere og billigere finansielle tjenester.

Rimelig teknologi levert som skytjenester gjør det praktisk mulig for enhver bedrift å tilby enkle banktjenester. Banknæringens historisk høye inngangsbarrierer rives ned, og bankene må posisjonere seg mot nye aktører som behersker data og har egne økosystemer.

Dagens digitalbank ligner i stor grad de papirbaserte kontoutskriftene vi tidligere fikk i posten. Selv om bankene har vært innovative, har vi ikke sett radikal innovasjon med dagens mobil- og nettbank.

Å sette strøm på papir er ikke god digitaliseringsstrategi. Derfor tror jeg bankene må tenke nytt og utvikle nye, sammenkoblede tjenester basert på finansteknologi og sikker datautveksling gjennom API. Om du vil vite mer om datadeling og sammenkoblede tjenester, les gjerne min tidligere post; hva er et API?

Tenke nytt

I en digitaliseringsstrategi er målet å styrke kjernevirksomheten ved å utnytte ny teknologi. Gjennom kontinuerlig utvikling og læring bygges nye kapabiliteter (evne til å produsere verdi) for å forbli relevant for kunder, brukere og eiere også i framtiden.

Teknologi gjør det altså mulig å skape verdi på nye måter, både for kunder, brukere og eierne. Men for å forstå og utnytte det fulle potensialet kreves nytenking om egen virksomhet. Dette gjøres ved å re-definere hvordan verdier skapes i selskapet, re-tenke verdikjeden, re-tenke kundekontakten, og som konsekvens av dette, re-bygge organisasjonen. I den rekkefølgen, og ikke starte med omorganisering. Det er en klassisk feil som desverre gjøres altfor ofte, med unødvendige konflikter og maktkamper som resultat.

Strategiprosess for å re-tenke verdiskapning (S.Gupta, HBR, 2019)

Dette krever godt lederskap for å lykkes, og som figuren over viser, er lederskap navet i strategiprosessen. Det er ofte her jeg kommer inn som rådgiver for å bistå i strategiutviklingen. Med min bakgrunn som teknolog og leder, faller det ofte naturlig å utfordre eksisterende antakelser og «sannheter» om både forretning og IT – på en konstruktiv måte. Jeg har erfart at de beste strategiene er enkle å forstå, med tydelig definerte mål som kan kommuniseres og omsettes i tiltak som skaper målbare resultater og effekter.

Om du vil vite mer om å re-tenke verdiskapning og Harvard modellen for strategiutvikling, har jeg skrevet en tidligere post om dette: hva er en digital strategi?

Nytt IT-system og Conways lov

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.

Verktøy illustrasjonsfoto av Matt Artz på Unsplash

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».

Fakturerbare timer til besvær

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

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?

Hva er teknisk gjeld?

Teknisk gjeld er en metafor som fungerer godt til å forklare strategiske konsekvenser av valg i utvikling og anskaffelse av IT-systemer. Over tid vil mangelfull forståelse av slike konsekvenser resultere i operasjonelle utfordringer som hindrer effektiv måloppnåelse av strategiske mål. Derfor kan det lønne seg å se nærmere på hva teknisk gjeld er, og forstå hvordan den kan håndteres. Spesielt for virksomheter med ambisiøse mål og IT-systemer som ikke innfrir.

Renter på teknisk gjeld gir økte kostnader og hindrer vekst

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.

Dette vet ledere som har en viss teknologisk forståelse, og det er i disse virksomhetene jeg ofte kommer inn som rådgiver, arkitekt og sparringspartner. For spørsmålet mange vil ha svar på er: Hvordan oppstår teknisk gjeld, og hva kan vi gjøre for å begrense omfanget? Her opplever jeg at det er store forskjeller hos ulike virksomheter. Noen toppledere og styremedlemmer er oppdatert og har kunnskap nok til å stille disse spørsmålene. Andre klarer ikke å sette ord på problemet, selv om de aner at det eksisterer.

Teknisk gjeld er gapet mellom nåværende IT-system/produkt og det som ansees å være nødvendig systemkvalitet for produktet, gitt formålet det benyttes til. Her trengs det litt mer forklaring på hva som menes med systemkvalitet.

Det er utviklet en standard modell for å evaluere produktkvalitet til en IT-løsning. (IEC/ISO 25000 Software and data quality). Kvalitetsmodellen benyttes til å bestemme hvilke kvalitetskarakteristikker som skal tas i betraktning når egenskapene til et IT-produkt vurderes. Dette omfatter blant annet interessentenes behov for funksjonalitet, ytelse, sikkerhet, vedlikeholdsevne osv. Kvalitetsmodellen kategoriserer produktkvaliteten i egenskaper og underegenskaper, som vist i tabellen under.

I likhet med gjeld i penger, løper det renter på teknisk gjeld. Effekten av renters rente medfører et behov for å betale ned gjelden før den blir uhåndterlig stor. Men litt teknisk gjeld kan faktisk være positivt, for å komme i mål med en leveranse på tid og kost, for eksempel hensynet til å nå en frist. Det forutsetter at ansvarlige ledere vet hva de gjør og tar tak i den tekniske gjelden på en systematisk måte etter prosjektet er levert. Her syndes det ofte, blant annet på grunn av manglende kunnskap om systemkvalitet.

Opparbeidelse av teknisk gjeld kan være utilsiktet eller foregå med vitende vilje. Videre kan teknisk gjeld betraktes som et resultat av handlinger med eller uten innsikt. Jeg velger å kalle det innsiktsløst og innsiktsfullt. Dette gir oss to akser (tilsiktet – utilsiktet), og (innsiktsløst – innsiktsfullt) som vi benytter i en firefelts-tabell. Av en eller annen grunn blir jeg lykkelig når komplekse ting kan brytes ned i slike firefeltstabeller.

Fire årsaker til hvordan teknisk gjeld oppstår

I feltet nede til venstre opparbeides teknisk gjeld tilsiktet og innsiktsløst. Det som er betegnende for slik atferd er «Vi har hverken tid eller råd til bedre løsningsdesign». Knapphet på tid og penger, kombinert med manglende forståelse av nytteverdien av arkitektur og design er dessverre en veldig vanlig årsak til at teknisk gjeld oppstår.

I feltet oppe til venstre opparbeides teknisk gjeld tilsiktet og innsiktsfullt. Det som er betegnende for slik atferd er: «Vi må levere nå, men starter med feilretting umiddelbart». Denne tilnærmingen brukes i stadig større omfang, og handler om kontinuerlig leveranse og kontinuerlig forbedring av kode i IT-produktet. For å få dette til, kreves blant annet automatisering av omfattende tester av nye kodelinjer for å unngå utilsiktede feil ved planlagte endringer. I dette tilfellet er teknisk gjeld kalkulert, og nedbetales kontinuerlig.

I feltet nede til høyre oppstår teknisk gjeld som konsekvens av handlinger som er innsiktsløs og utilsiktet. Rotårsaken er manglende kunnskap, og det som betegner slik atferd er «Hva er løsningsdesign og lagdelt arkitektur?». Jeg har sett dette hos virksomheter som har vokst kraftig, og hvor behovene for ytelse og skalering av IT-produktet har endret seg tilsvarende. Det som før var en tilstrekkelig IT-løsning, har virksomheten rett og slett vokst fra. Men den tekniske gjelden gjør videre vekst vanskelig.

Ofte kommer ikke problemene til overflateten før etter en tid, og omfattende strukturelle endringer må vurderes for løse problemene. For eksempel å skifte fundamentale deler av løsningsarkitekturen som nytt kjernesystem. Dette er strategiske vurderinger som har høy risiko og krever styrebehandling. Det er gjerne slike vurderinger som blir bedre når en samarbeider med et konsulenthus som for eksempel Sopra Steria, siden selskapet kan tilby bredde og dybde av nødvendig kompetanse for å ta ned risiko i gjennomføringen av en digital transformasjon. Mange nisje-aktører kan gi råd og lage strategiplaner, men desverre er det betydelig færre aktører som har praktisk erfaring i å implementere planene. Det vet jeg, fordi jeg har møtt flere kunder med en fin glossy plan i PowerPoint, som ikke er gjennomførbar i praksis.

I feltet oppe til høyre, som er den kvadranten de fleste ønsker å befinne seg i, oppstår teknisk gjeld som konsekvens av handlinger som er innsiktsfull og tilsiktet. Rotårsaken kan forklares som læring underveis i prosessen med å ha anskaffet eller utviklet løsningen. «Nå forstår jeg hvordan vi burde gjort det» uttrykker en evne til refleksjon og læring som er forbilledlig og bør fremdyrkes i alle lærende organisasjoner. Det er også et viktig argument for smidig tilnærming – i motsetning til omfattende planer og store IT-prosjekter som for eksempel prosjekt Akson som skal anskaffe felles journalsystem for kommunene.

Begrepet teknisk gjeld ble først lansert av Ward Cunningham i 1992. Martin Fowler utypet senere begrepet og beskrev de fire kvadrantene for hvordan gjelden oppstår. Begge er medforfattere av Agile manifesto – opphavet til smidig bevegelsen, som nå er et fremvoksende tankesett for å fremme innovasjon i virksomheter. Dette vil jeg skrive mer om i et senere innlegg.

Om du lurer på hvorfor jeg bare har skrevet om løsningsarkitektur og ikke har nevnt hvordan det henger sammen med virksomhetsarkitektur, er det fordi at det har jeg skrevet om i et annet innlegg: Verdien av virksomhetsarkitektur.