Outsourcing på dårlig grunnlag

Denne ytringen er skrevet sammen med min kollega Karl Egil Stubsjøen i A-2 Norge AS og publisert i Computerworld 28.10.2016.

Det er dyrt og krevende å hente IT-tjenester tilbake igjen til egen virksomhet. Stadig flere virksomheter tar nå konsekvensen av at kvaliteten på IT-tjenester som er satt ut til eksterne leverandører, ikke samsvarer med forventningene som lå til grunn for beslutningen om outsourcing. En viktig årsak er ofte at det forutsetter langt større innsikt og forståelse i virksomheten enn det leverandøren har mulighet for å bygge opp.

En balansert tilnærming

Ved å finne den gode balansen mellom oppgaver som skal utføres internt eller eksternt, kan man sikre både lavere kost og økt kvalitet på tjenestene. Men hva gjør man når kostnadsbesparelsene uteblir, de kulturelle forskjellene skaper uoverkommelige barrierer, kommunikasjonen er elendig, kvalitetene på tjenestene er for dårlig, innovasjonen stanser opp og den interne kompetansen på kritiske IT-løsninger har forvitret? Jo, da begynner man å hente tjenester tilbake igjen. Og det koster.

Flere sterke drivere trekker i retning av outsourcing: Tilgang på spesialkompetanse, reduksjon av produksjonsrisiko, økt økonomisk fleksibilitet, og skalering av produksjonskapasitet. Når outsourcing skal reverseres, gjelder det å sikre at de nevnte driverne i så liten grad som mulig slår negativt ut.

Både norsk og internasjonal forskning viser at det er minst like kostbart og krevende å hente tjenester tilbake som å sette dem ut. I bunn og grunn dreier problemene seg i begge tilfeller om kompetanse. Enten mangler den hos leverandøren, eller så må den bygges opp igjen internt i virksomheten.

Å gjøre mer selv

Vår erfaring tilsier at det er viktig å beholde kompetanse internt på områder hvor det skjer hyppige endringer og hvor det er vesentlig å være tett på markedet. I slike tilfeller vil man fort havne i bakevja om man ikke evner å tilpasse seg endringene rask nok.

Vi er eksempelvis skeptiske til planer om å sette ut forvaltning av faglig smale IT-systemer som er kritiske for virksomhetens leveranse av produkter og tjenester. Vi tror heller ikke alltid det er riktig å sette ut systemutvikling til f.eks. India eller Kina. Flere virksomheter har oppnådd gode resultater ved å ha utviklere «i samme rom» som egne ansatte, i motsetning til å jobbe med team som sitter på den andre siden av jordkloden, i en annen tidssone, og som sliter med å forstå både funksjonelle krav og kultur.

Dersom tjenester skal hentes tilbake anbefaler vi å vurdere alternative sourcingmodeller. Det kan lønne seg å flytte noen tjenester til naboland eller til Norge, hvor forskjellene i språk og kultur er små. Enkelte velger å flytte leverandørens medarbeidere til sine egne lokaler (riktignok med varierende hell).

Det er ikke alltid enkelt i praksis å presist definere hvilke kjerneaktiviteter og kompetanse man selv må ha kontroll på. Eksempelvis kan toppledelsen mene at IT-prosjektledelse er en kjerneaktivitet som skal beholdes internt, mens programvareutvikling kan outsources. I slike tilfeller kan det vise seg vanskelig å få utviklet gode prosjektledere med tilstrekkelig utviklingskompetanse. Virkningene og konsekvensene av å skille fagområder må derfor vurderes grundig.

Uansett må virksomheten ha den tekniske og administrative interne kompetansen som må til for å styre det området som outsources. Dette undervurderes ofte.

Ny strategi. Nye motiver

Å ensidig fokusere på kostnadsbesparelser i forbindelse med outsourcing er ikke tilstrekkelig. Mange ser at det fremdeles er mulig å redusere kostnadene, men ikke i den skala som man tidligere ofte trodde var mulig. Kostnadsfokuset må suppleres med fordeler knyttet til økt fleksibilitet og tjenestekvalitet, og beslutningen basert på inngående risikovurderinger.

Vi har god erfaring med bruk av selektive og balanserte sourcingmodeller, der man har et realistisk syn på potensielle gevinster og en meget bevisst tilnærming til valget om hva som skal settes ut og hva som skal beholdes internt. Det er etter vårt syn slik virksomheten oppnår de beste resultatene.

Reklame

Når reviderte du leverandørene dine sist?

Revisjon høres kanskje litt tørt og kjedelig ut, men det trenger det absolutt ikke være. I min verden handler det om å sjekke at leverandørene faktisk gjør det de har forpliktet seg til å gjøre. I Statens standardkontrakter (SSA) ligger det inne flere muligheter til å følge opp kontraktforpliktelsene. Men dette er noe som en kunde bør legge inn i kontrakten med leverandøren uansett. I den nylig oppdaterte SSA-D (driftsavtalen) formuleres det på følgende måte:

«Kunden har rett til å foreta revisjon og verifikasjon av at Leverandøren overholder avtalte forpliktelser for driftstjenesten … Leverandøren skal yte bistand hvis Kunden har behov for å involvere Leverandøren i gjennomføring av kvalitetsrevisjoner … Med mindre annet er avtalt … kan revisjon maksimalt gjennomføres én gang per år … Kunden kan oppnevne tredjepart til å utføre revisjon og verifikasjon etter denne bestemmelse … Hvis de påviste avvikene er av vesentlig karakter, eller kan bebreides Leverandøren som uaktsomt, plikter Leverandøren å refundere Kundens nødvendige kostnader til gjennomføring av revisjonen … Dersom Kunden ønsker å gjennomføre en revisjon hos Leverandørens underleverandør, plikter Leverandøren å samarbeide med Kunden for å få gjennomført en slik revisjon.»

Dette innebærer at kunden har en sterk rett til å gå dypere inn i leverandørens arbeidsmetodikk enn det den tradisjonelle SLA-rapporteringen innebærer. Mange kunder burde være mye mer aktive og benytte den muligheten som en kontrakt kan gi. Slike gjennomganger kan normalt gjennomføres i løpet av et par dager, riktignok avhengig av kontraktens omfang og problemstillingene som skal adresseres.

Jeg pleier å bruke samme tilnærming som ved en ISO 9001-revisjon og kategorisere funnene i tre grupper: A: Avvik, M: Merknad og F: Forbedringspunkt. Alle funn skal begrunnes og knyttes til et punkt i kontrakten. Basert på funnene skal aktiviteter beskrives, med en tidsfrist for når det skal være korrigert.

For en kunde som skal gjennomføre en anskaffelse gir det en ekstra trygghet å vite at leverandøren skal revideres. Mange har en gjennomgang hos leverandørene før en kontrakt inngås, men færre gjør det i ettertid. Erfaringsmessig er det mye vanskeligere å finne «feil» hos en leverandør før kontrakten inngås enn etterpå. Når man har erfaring med både løsning og samarbeid er det lettere å utføre en målrettet gjennomgang.

Som ISO 9001-sertifisert kvalitetsrevisor har jeg gjort dette mange ganger, og uten unntak kommer det opp forhold som må utbedres. Og som regel setter faktisk også leverandøren pris på denne muligheten til å forbedre sine tjenester.

Det er ofte kravene som er feil, ikke løsningen

To av mine gode kolleger i A-2 Norge har skrevet en artikkel i Ukeavisen ledelse om tre grep for å få mer vellykkede IT-prosjekter i offentlig sektor. Dette gjenspeiler dyp erfaring fra en rekke IT-prosjekter vi har fulgt over mange år. Jeg vil her ta tak i ett av momentene de tar opp og spinne videre på det, nemlig selve utgangspunktet:

• Hvilke behov det er som skal dekkes?
• Hvilke krav er beskrevet?
• Er det en fare for at en ny løsning bygges ut i fra noe som er svakt fundert?

Som kvalitetsikrer av store IT-prosjekter undersøker vi alltid selve fundamentet for prosjektet. Det har å gjøre med behovsanalyse, kravformulering, organisatorisk forankring, ledelsens engasjement, teknologivalg, samt ikke minst om det er utarbeidet en dekkende business case. Gjentatte ganger har vi sett at dette fundamentet er ustabilt. Behov og krav kan være beskrevet med varierende presisjon og ikke minst på veldig ulikt detaljeringsnivå. Jeg opplever ikke at det er teorien det er noe galt med. Å utarbeide en behovsanalyse eller beskrive overordnede behov før kravene blir detaljert ut er fornuftig. Men praksisen derimot, den kan man innvende mye mot.

Jeg har konkludert med at fem sentrale forhold må være på plass for å gi IT-prosjektet et solid fundament når det gjelder behov og krav, både før prosjektet starter og underveis i gjennomføringen. Det er lett å nikke til disse punktene, men det er ikke dermed sagt at de er enkle å realisere. Og overraskende mange kunder og ikke minst leverandører med mye erfaring viser manglende forståelse for hva som må til for å gjennomføre dette i praksis. De fem punktene er:

1. Riktig kompetanse. De som beskriver behov og krav må kjenne virksomheten, primært arbeidsprosesser og regelverk, meget godt. Jeg har ofte sett at kompetente folk bare har vært med sporadisk og i en tidlig fase av arbeidet. Det holder ikke.
2. Solid forankring gjennom både arbeidet med å lage en kravspesifikasjon og ikke minst under gjennomføringen av prosjektet. Dette er ikke et «one man show». Som er krevende når store løsninger med hundrevis av krav skal innføres. Det tar tid å forankre, ikke minst for de det skal forankres hos. Når disse ikke har den tiden, bytter jobb internt eller slutter kan man lett få et vakuum – som lett kan føre til at man skyver på vanskelige avklaringer til senere i prosjektet.
3. Tenk nytt, ikke bare kopier funksjonaliteten i en gammel løsning. Overraskende mange går i denne fella. Man snakker om å optimalisere arbeidsprosesser og tenke smart i en ny løsning, men når alt kommer til alt ender man opp med at den nye løsningen blir for mye av det gamle, laget på en ny teknisk plattform. Og gjerne unødvendig komplisert.
4. Visualiser løsningen så tidlig som mulig. Det er mye mer effektivt å kommunisere ved bruk av skjermbilder kontra beskrivelser. Når et krav er at løsningen skal ha «et moderne og effektivt brukergrensesnitt», må man så tidlig som mulig konkretisere hva det i praksis betyr. Da blir visualisering helt avgjørende. Både for at kunde og leverandør skal bli enige om en felles forståelse, men også fordi tidlige designvalg kan bli veldig arbeidskrevende å endre senere i prosjektet. Går det helt til akseptansetesten kan man også risikere store økonomiske krav i form av endringsordre.
5. Dynamisk samarbeid i et konstruktivt klima. Begge parter bør være innstilt på at endringer i krav vil komme. Ingen kunde klarer å definere krav så presist at man bare kan designe og bygge uten videre. I tillegg kan (og bør) standard funksjonalitet i mange applikasjoner også påvirker realiseringen av krav. Dette skal normalt dekkes i kontrakten, men ofte ser man det ikke godt nok før prosjektet er i gang. Da blir det viktig med en åpen og fleksibel samarbeidsform. Dessverre ser jeg for ofte at kunden «står på krava», både fordi man er er usikre (kompetanse) og forankringen er vanskelig å få til, samt at viljen til å tenke nytt ikke er nok til stede (her kan man også være bundet av det offentlige reglementet for anskaffelser, men det gjelder jo ikke i privat sektor).

La meg snu på det: Hvis man bygger et IT-system hvor kravene er laget av noen som ikke kjenner virksomheten inngående, det har vært dårlig forankring i linjen eller forretningen underveis i prosjektet, man er mest opptatt av å kopiere det bestående (hvis det finnes), ingen ser demo av løsningen før langt ute i prosjektet, og det er rigide fronter mellom partene – da er det en sikker oppskrift for at det blir nok et mislykket prosjekt.

IT-skandalene i offentlig sektor

Difi-sjefen Ingelin Killengreen skriver i sitt innlegg 19/12-2014 i DN (Hvordan unngå IT-skandalene) om viktige, men samtidig ganske generelle og opplagte virkemidler for å gjøre ledelsen i det offentlige dyktigere til å forstå IT-strategi og gjennomføre prosjekter. Temaer det har blitt snakket om i årevis. Det er to forhold som ikke påpekes, som jeg mener har en meget stor betydning for pengebruk og suksessrate:

For det første: Regelverket i det offentlige er ofte meget komplisert med mange sære regler og unntak. Når man skal digitalisere dette i IT-løsninger, blir jobben kompleks og omfattende både å bygge og vedlikeholde. Da trenger man mange konsulenter, noe DN gjennom søkelyset på NAV sine IT-kostnader effektivt har påvist. Det som dessverre sjelden utføres er en kritisk gjennomgang med mål om forenkling av regelverket før et IT-prosjekt starter. Da mister man en unik mulighet til forenkling og effektivisering.

Videre kan regimet for offentlige anskaffelser være direkte kostnadsdrivende. Dette har også blitt påvist gjennom en rekke artikler i DN. La oss håpe at forslagene fra Forenklingsutvalget (levert i juli i år) blir iverksatt. Det vil i det minste hjelpe noe.

Men uten forenklede arbeidsprosesser og regelverk vil IT-prosjektene fortsette å være store og kompliserte og med høy risiko for både tids- og kostnadssprekk.

To prosjekter: Så like, men likevel tar det ene tre ganger mer tid …

Noen ganger kan prosjekter tilsynelatende se ganske like ut, men vise seg å bli veldig forskjellig å gjennomføre. Eksempelet jeg skriver om her handler om to virksomheter som begge skulle skifte ut sine økonomisystemer. Den ene er en dynamisk, mellomstor privat bedrift («BEDRIFTEN») og den andre en litt større statlig etat («ETATEN»). Begge hadde et ganske likt utgangspunkt med en eksisterende ERP-løsning som måtte skiftes ut.

BEDRIFTEN brukte under ett år på et forprosjekt, utarbeide en kravspesifikasjon, gjennomføre en tilbudskonkurranse og et prosjekt og ta i bruk løsningen. ETATEN er fortsatt ikke i mål etter tre år. Hvorfor blir det slik? Er det noen tydelige indikatorer som kan fortelle hvorfor noe som er ganske likt tar så mye lenger tid i ETATEN enn hos BEDRIFTEN? Ja, jeg tror det.

Jeg har satt opp noen viktige parametere og gjort en liten vurdering av de to prosjektene opp imot disse:

• Kontrakttype: Statens standard for begge.
• Ledelsen engasjement: Høy for begge.
• Løsningens kompleksitet: Høyere for ETATEN.
• Grad av tilpasning: Mye høyere for ETATEN.
• Rammebetingelser: Mer krevende for ETATEN.
• Tidspress: Mye høyere for BEDRIFTEN.

ETATEN er pålagt å følge og benytte statens regelverk for IT-anskaffelser, men også BEDRIFTEN valgte å benytte denne prosessen og kontrakt – riktignok med mulighet for en helt annen fleksibilitet enn ETATEN kan gjøre. Og uten den gjennomsyrende frykt i det offentlige for å gjøre noe feil i prosessen. Etter mitt syn viser det at både prosessen og kontrakten er god, men regelverket som staten må følge er meget rigid. Gjør man en liten feil kan hele prosessen bli underkjent. Rykk tilbake til start! Det risikerte man ikke i BEDRIFTEN og kunne derfor kjøre en rask og smidig prosess, men uten å gå på kompromiss med etiske normer. Flere av tilbyderne sa i ettertid at de hadde satt pris på den ryddige og profesjonelle prosessen som var gjennomført. ETATEN derimot, brukte mye tid på å sikre seg at alt gikk riktig for seg, og hadde gjennomgående mye lengre frister på alt enn BEDRIFTEN. Så der BEDRIFTEN brukte 6 måneder på å få en avtale på plass, brukte ETATEN halvannet år. Det samme gjaldt gjennomføringen.

Ser man på ETATEN er det tilsynelatende ikke noen spesielt skremmende faktorer som spiller inn. Likevel tar det altså så mye lenger tid. Jeg tror BEDRIFTEN kom bedre ut primært av tre grunner:

1. Valg av standard løsning fremfor skreddersøm
2. Større grad av fleksibilitet i gjennomføringen
3. Stort tidspress

BEDRIFTEN bestemte seg tidlig for å velge en standard løsning og gjøre så få tilpasninger som mulig på denne. De var villige til å endre sin måte å jobbe på i tråd med systemets standard prosesser hvis det var nødvendig. De tok utgangspunkt i en løsning hvor man kunne jobbe interaktivt hele tiden og se systemet live og legge inn sine regler fortløpende, uke for uke. Prosjektteamet jobbet kontinuerlig med detaljdesign, dialog med utviklerne, testing og evaluering. ETATEN, derimot, jobbet på en tradisjonell måte med mye lenger avstand mellom sine prosjektdeltakere, utviklerne hos leverandøren og selve løsningen. De var veldig opptatt av å få ting på sin måte, og hadde enkelte krav som var meget kompliserte å realisere.

Dette, sammen med en dynamisk holdning til de kravene som var utarbeidet, gjorde at BEDRIFTEN gjennom prosjektgjennomføringen hele tiden tilpasset seg og tok mange små beslutninger som ga trygghet på at de var på riktig vei. Dette kunne ikke ETATEN gjøre, deres krav var «hellige», enten de var fornuftige eller ikke. Det sto jo i kontrakten og var en del av evalueringsgrunnlaget.

Og så kan man ikke komme unna tidspresset. Av forskjellige grunner måtte BEDRIFTEN bli ferdig på ett år, mens ETATEN ikke på langt nær hadde det samme presset fra ledelsen. Når presset reduseres akseptere man mye lettere at «ting tar tid». For BEDRIFTEN var det ingen nåde: Eierne var veldig tett på ballen, og alle visste akkurat hva som var forventet av dem.

Begge løsningene kommer sikkert til å bli bra for virksomhetene. Men det er skremmende at et prosjekt i det offentlige skal tvinges gjennom rammebetingelser og forutsetninger som gjør at det tar så mye lenger tid og dermed også blir betydelig dyrere (for oss skattebetalere). Hvor mye dyrere? Vet ikke sikkert, men tipper at vi snakker om en faktor på 10 til slutt. Da begynner vi å snakke om mye penger.