Denne teksten er for styrer og personer som står bak beslutningen om kjøp av et system: kommunesekretæren og kemneren i kommunen, daglig leder i et kommunalt selskap, finansdirektøren, bedriftseieren. Den er også for IT-lederen som forbereder en anskaffelse eller en forespørsel om tilbud, og som vil vite hva ledelsen bør se etter før dokumentene godkjennes.
Hvorfor problemet oppstår
De fleste problemene med leverandører har opphav hos oppdragsgiveren selv, og det lenge før kontrakten signeres. Ikke av vond vilje: å forberede en anskaffelse er arbeid som organisasjonen sjelden har tid og kompetanse til, og leverandørene hjelper gjerne til. De kommer med ferdige beskrivelser, demonstrasjoner og prisoverslag. Resultatet blir at oppdragsgiveren kjøper det leverandøren er god til å selge, ikke det organisasjonen faktisk trenger. Et annet problem er at innkjøpsbeslutninger svært ofte ligger hos fagavdelingene, mens IT bare har rollen som sikkerhetsvokter. Manglende standarder og en langsiktig IT-strategi fører til at organisasjonen gjør innkjøp som ikke alltid passer inn i rammene som skal bidra til å redusere risiko.
De samme feilene ser jeg både i offentlig forvaltning og i private virksomheter. Det som skiller dem, er anskaffelsesformen, ikke selve mekanismen.
Tolv feil
- Krav skrevet med utgangspunkt i én leverandørs tilbud eller presentasjon. Begrenser konkurransen og befester avhengigheten før dere i det hele tatt har valgt leverandør. Jeg har beskrevet dette nærmere i teksten om vendor lock-in i anbudsspesifikasjonen (SWZ).
- Manglende forretningseier. Prosjektet har formelt en prosjektleder, men ingen med mandat fra ledelsen bestemmer hvordan prosessene skal fungere.
- Manglende overtakelseskriterier og testscenarioer før signering. Overtakelsen blir en tolkningstvist i stedet for en kontroll av om prosjektets leveranse oppfyller suksesskriteriene for implementeringen.
- Manglende oversikt over det som allerede finnes. Dere kjøper et nytt system uten å vite hvilke eksisterende avtaler, lisenser og funksjoner som overlapper med det.
- Glemte integrasjoner. Hva skal det nye systemet utveksle data med, i hvilke retninger, hvilke systemer skal være overordnede, hvilke data, i hvilke formater, og vet leverandøren om dette og garanterer de nødvendige mekanismer samt ansvar for driftskontinuiteten?
- Datamigrering beskrevet i én setning. Uten avklaring av hvilke data, fra hvilken periode, hvem som renser dem og hvem som kontrollerer resultatet.
- Krav formulert som en funksjonsliste i stedet for en beskrivelse av prosesser. Enhver leverandør vil svare «ja» på spørsmål om en funksjon. På spørsmålet om hvordan de vil håndtere deres konkrete tilfelle, blir svarene forskjellige.
- Sammenligning av kun startpris i stedet for total kostnad. Lisensen er bare begynnelsen. Drift, endringer og integrasjoner betales i årevis. Jeg skriver om denne mekanismen i teksten om total kostnad ved eierskap (TCO) og den kokende frosken.
- Manglende regler for endring av omfang. Det er uklart hvem som melder en endring, hvem som prissetter den og hvem som godkjenner den.
- Kontrakt uten exit-vilkår. Ingen bestemmelser om dataeksport, dokumentasjon eller overføring av drift til en annen leverandør. Ingen verktøy for å redusere risiko.
- Vedlikeholdsavtale akseptert fra leverandørens mal. Da fastsetter én part alene servicenivåer, responstider og kostnad for endringer.
- Beslutningen utsatt til siste øyeblikk før fristen. Når en lovfestet frist eller slutten på støtte for det gamle systemet nærmer seg, er det ikke lenger rom for å sammenligne tilbud eller forhandle.
Feil nummer én til tre er de grunnleggende. Fjerner dere dem, blir de fleste av de øvrige synlige allerede i forberedelsesfasen, ikke først under gjennomføringen.
For styret, kontrollkomiteen eller sentraladministrasjonen er det viktigste spørsmålet om beslutningen om valg av leverandør har en dokumentert begrunnelse. De tolv punktene ovenfor er samtidig en liste med spørsmål det er verdt å stille før ledelsen godkjenner anskaffelsesdokumentene.
Eksempel fra praksis
En av våre kunder fikk beskjed fra sin ERP-leverandør om at det ikke ville være noe problem å utveksle kundedata med et samtidig innført system for korrespondansehåndtering (EZD/e-Doręczenia). Et system for korrespondansehåndtering lagrer som regel data om alle forretningsforbindelser, ikke bare dem det faktisk oppstår transaksjoner med, altså de som blir kunder eller leverandører. Livssyklusen til en ny forretningsforbindelses data starter som regel lenge før det skjer noen transaksjon.
Under implementeringen viste det seg at kostnadene ved å tilpasse ERP-leverandørens API for toveis datautveksling om forretningsforbindelser utgjorde 80 % av den totale verdien av prosjektet for innføring av kostnadsbilagshåndtering integrert med KSeF, med OCR, VIES, det sentrale foretaksregisteret og til slutt eksport av data til økonomi- og regnskapssystemet. Denne ene integrasjonen, som ikke var gjennomdrøftet med leverandøren på forhånd, doblet i praksis kostnadene for hele prosjektet.
Når det trengs en uavhengig rådgiver
Har dere et erfarent team som allerede har forberedt flere lignende anskaffelser, kan denne listen brukes som en kontroll. En uavhengig gjennomgang gir mening når anskaffelsen er stor i forhold til organisasjonens størrelse, når kravene har blitt til i dialog med én bestemt leverandør, når beslutningen må kunne forsvares overfor revisjon, styret eller sentraladministrasjonen, eller når ingen på oppdragsgiversiden kjenner disse systemene innenfra.
Jeg kan lese gjennom dokumentene før en anskaffelse kunngjøres eller en forespørsel sendes ut, utarbeide krav og testscenarioer eller evaluere tilbud som allerede er levert inn. For kommuner ser utgangspunktet litt annerledes ut – jeg beskriver det på siden for kommuner og fylkeskommuner (JST).