Denne teksten er for ledelsen og personene som står bak beslutningen om å kjøpe et system: kommunesekretæren og kommunekasserereren i en kommuneadministrasjon, daglig leder i et kommunalt selskap, økonomidirektøren, bedriftseieren. Den er også for IT-lederen som forbereder en anskaffelsesprosess eller en forespørsel om tilbud, og som vil vite hva ledelsen bør være oppmerksom på før den godkjenner dokumentene.
Hvorfor dette problemet oppstår
De fleste problemene med leverandører har sin opprinnelse hos oppdragsgiveren selv, og det lenge før kontrakten signeres. Ikke av vond vilje: å forberede en anskaffelse er et arbeid organisasjonen sjelden har tid og kompetanse til, og leverandørene hjelper gjerne til med å lette byrden. De kommer med ferdige beskrivelser, demonstrasjoner og prisoverslag. Resultatet er at oppdragsgiveren kjøper det leverandøren er god til å selge, ikke det de faktisk trenger. Et annet problem er at innkjøpsbeslutninger svært ofte forblir hos fagavdelingene, mens IT kun får rollen som sikkerhetsvakt. Mangel på standarder og en langsiktig IT-strategi fører til at organisasjonen gjør innkjøp som ikke alltid passer inn i rammeverket som skal begrense risiko.
Jeg ser de samme feilene i både offentlige etater og private virksomheter. Det som skiller dem er innkjøpsprosedyren, ikke mekanismen.
Tolv feil
- Krav skrevet med utgangspunkt i ett bestemt tilbud eller én presentasjon. Dette begrenser konkurransen og befester avhengigheten allerede før dere har valgt leverandør. Jeg har skrevet mer om dette i teksten om leverandørbinding i konkurransegrunnlaget (SWZ).
- Mangel på en forretningseier. Prosjektet har formelt en prosjektleder, men ingen med mandat fra ledelsen avgjør hvordan prosessene skal fungere.
- Mangel på overtakelseskriterier og testscenarioer før signering. Overtakelsen blir en tvist om tolkning i stedet for en kontroll av om prosjektets leveranse oppfyller suksesskriteriene for implementeringen.
- Manglende kjennskap til det dere allerede har. Dere kjøper et nytt system uten å vite hvilke eksisterende avtaler, lisenser og funksjoner som overlapper med det.
- Utelatte integrasjoner. Hvilke andre systemer skal det nye systemet utveksle data med, i hvilke retninger, hvilket system som er overordnet, hvilke data det gjelder, i hvilke formater, og om leverandøren er klar over dette og garanterer at de leverer de nødvendige mekanismene samt tar ansvar for at de fungerer kontinuerlig.
- Datamigrering beskrevet i én eneste setning. Uten å avklare hvilke data, fra hvilken periode, hvem som vasker dem, og hvem som kontrollerer resultatet.
- Krav i form av en funksjonsliste i stedet for en beskrivelse av prosessene. Enhver leverandør vil svare «ja» på spørsmål om en funksjon. På spørsmålet om hvordan de håndterer deres konkrete tilfelle, vil svarene variere.
- Sammenligning av startpris i stedet for total kostnad. Lisensen er bare begynnelsen. Vedlikehold, endringer og integrasjoner betaler man for i årevis. Jeg skriver om denne mekanismen i teksten om total eierkostnad (TCO) og den kokte frosken.
- Mangel på regler for endring av omfang. Det er uklart hvem som melder inn en endring, hvem som priser den, og hvem som godkjenner den.
- Avtale uten exitvilkår. Ingen bestemmelser om eksport av data, dokumentasjon eller overføring av drift til en annen aktør. Ingen verktøy for risikoreduksjon.
- Vedlikeholdsavtale basert på leverandørens standardmal. Da fastsetter kun den ene parten servicenivåer, responstider og kostnad for endringer.
- Beslutningen utsatt til siste liten før fristen. Når en lovpålagt frist eller slutten på support for det gamle systemet nærmer seg, er det ikke lenger rom for å sammenligne tilbud eller forhandle.
Feil nummer én til tre er kildefeilene. Fjerner dere disse, blir de fleste av de øvrige synlige allerede i forberedelsesfasen, ikke under gjennomføringen.
For styret, kontrollkomiteen eller konsernledelsen er det viktigste spørsmålet om beslutningen om å velge 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 leverandøren av ERP-systemet om at det ikke ville være noe problem å utveksle data om forretningspartnere med det nye systemet for dokument- og saksbehandling (EZD) med e-Doręczenia (det polske e-leveringssystemet) som skulle innføres. Et system for dokument- og saksbehandling lagrer som regel data om alle forretningspartnere, ikke bare dem det oppstår økonomiske hendelser med, altså dem som blir kunder eller leverandører. Livssyklusen til en ny forretningspartners data starter rett og slett som regel lenge før det oppstår noen økonomisk hendelse.
Under implementeringen viste det seg at kostnadene ved å tilpasse API-grensesnittet for toveis utveksling av data om forretningspartnere, på ERP-leverandørens side, utgjorde 80 % av hele verdien til prosjektet for innføring av arbeidsflyt for kostnadsbilag med integrasjon mot KSeF (det polske e-fakturasystemet), OCR, VIES, det sentrale statistikkregisteret (GUS) og til slutt eksport av data til økonomisystemet. Denne ene integrasjonen, som ikke var grundig avklart med leverandøren fra starten av, doblet i praksis prosjektets kostnader.
Når det er behov for en uavhengig rådgiver
Har dere et erfarent team som allerede har forberedt flere lignende anskaffelser, kan denne listen brukes som en sjekk. Et uavhengig blikk er nyttig når anskaffelsen er stor i organisasjonens målestokk, når kravene har blitt utformet i kontakt med én bestemt leverandør, når beslutningen må forsvares overfor en revisjon, et styre eller konsernledelsen, eller når ingen på oppdragsgiverens side kjenner systemene innenfra.
Jeg kan lese gjennom dokumentene før anskaffelsen kunngjøres eller forespørselen sendes ut, utarbeide krav og testscenarioer eller vurdere tilbud som allerede er levert inn. For offentlige etater ser utgangspunktet litt annerledes ut; det beskriver jeg på siden for kommuner og fylkeskommuner (JST, lokale forvaltningsenheter).