Denne tekst henvender sig til ledelser og de personer, der skriver under på indkøbet af et system: sekretæren og kæmneren i forvaltningen, direktøren for et kommunalt selskab, den økonomiansvarlige direktør, virksomhedsejeren. Også til it-chefen, der forbereder udbuddet eller forespørgslen om tilbud, og som vil vide, hvad ledelsen bør være opmærksom på, inden dokumenterne godkendes.
Hvorfor opstår problemet
De fleste problemer med leverandører har deres rod hos ordregiver selv, og det længe før underskriften. Ikke af ond vilje: forberedelsen af et udbud er en opgave, som organisationen sjældent har tid og kompetencer til, og det udnytter leverandørerne gerne. De kommer med færdige beskrivelser, demoer og prisoverslag. Resultatet bliver, at ordregiver køber det, leverandøren kan sælge, i stedet for det, organisationen har brug for. Et andet problem er, at indkøbsbeslutninger meget ofte ligger hos de fagansvarlige afdelinger, mens it kun spiller rollen som sikkerhedsvogter. Manglen på standarder og en langsigtet it-strategi gør, at organisationen foretager indkøb, der ikke altid passer ind i de rammer, hvis formål er at begrænse risiko.
Jeg ser de samme fejl i både forvaltninger og virksomheder. Det, der adskiller dem, er indkøbsformen, ikke mekanismen.
Tolv fejl
- Krav formuleret ud fra én bestemt leverandørs tilbud eller præsentation. Det begrænser konkurrencen og fastlåser afhængigheden, allerede inden I har valgt leverandør. Jeg har beskrevet det nærmere i teksten om vendor lock-in i udbudsspecifikationen (SWZ).
- Manglende forretningsejer. Projektet har formelt en projektleder, men ingen med mandat fra ledelsen beslutter, hvordan processerne skal fungere.
- Manglende afleveringskriterier og testscenarier inden underskrivelsen. Afleveringen bliver en strid om fortolkning i stedet for en kontrol af, om projektets leverance opfylder succeskriterierne for implementeringen.
- Uvidenhed om, hvad der allerede findes. I køber et nyt system uden at vide, hvilke eksisterende kontrakter, licenser og funktioner der overlapper med det.
- Glemte integrationer. Hvilke data skal det nye system udveksle, med hvem, i hvilke retninger, hvilke systemer har en overordnet rolle, hvilke data og i hvilke formater, og ved leverandøren overhovedet det, og garanterer de, at de leverer de nødvendige mekanismer og tager ansvar for driftskontinuiteten?
- Datamigrering beskrevet i én sætning. Uden at fastlægge, hvilke data, fra hvilken periode, hvem der renser dem, og hvem der kontrollerer resultatet.
- Krav formuleret som en liste af funktioner i stedet for en beskrivelse af processer. Enhver leverandør vil svare "ja" på et spørgsmål om en funktion. På spørgsmålet om, hvordan den håndterer jeres konkrete case, varierer svarene.
- Sammenligning af startprisen i stedet for den samlede ejeromkostning. Licensen er kun begyndelsen. Drift, ændringer og integrationer betales år efter år. Jeg skriver om denne mekanisme i teksten om den samlede ejeromkostning (TCO) og den kogte frø.
- Manglende regler for ændring af omfang. Det er uklart, hvem der anmelder en ændring, hvem der prissætter den, og hvem der godkender den.
- Kontrakt uden exitvilkår. Ingen bestemmelser om dataeksport, dokumentation og overdragelse af drift til en anden part. Ingen værktøjer til risikobegrænsning.
- Driftskontrakt vedtaget efter leverandørens skabelon. Serviceniveauer, reaktionstider og omkostninger ved ændringer fastlægges da af den ene part alene.
- Beslutningen udskudt til sidste øjeblik før fristen. Når den lovbestemte frist eller afslutningen af support til det gamle system nærmer sig, er der ikke længere plads til at sammenligne tilbud eller forhandle.
Fejl nummer et til tre er de grundlæggende. Fjerner I dem, bliver de fleste af de øvrige synlige allerede i forberedelsesfasen og ikke først under gennemførelsen.
For rådet, bestyrelsen eller hovedkontoret er det vigtigste, om beslutningen om valg af leverandør har en dokumenteret begrundelse. De tolv punkter ovenfor er samtidig en liste over spørgsmål, det er værd at stille, inden ledelsen godkender udbudsdokumenterne.
Eksempel fra praksis
En af vores kunder fik fra leverandøren af ERP-systemet at vide, at det uden problemer ville være muligt at udveksle data om forretningspartnere med det korrespondancestyringssystem (et EZD-system til elektronisk dokument- og sagsstyring kombineret med e-Doręczenia, det polske e-Delivery-system), der var under implementering. Et korrespondancestyringssystem opbevarer som regel data om alle forretningspartnere, ikke kun dem, hvor der er sket en økonomisk hændelse, altså er blevet kunder eller leverandører. Livscyklussen for en ny forretningspartners data begynder nemlig som regel længe før, der overhovedet indtræffer nogen økonomisk hændelse.
Under implementeringen viste det sig, at omkostningerne ved at tilpasse API-grænsefladen til tovejsudveksling af data om forretningspartnere hos ERP-leverandøren udgjorde 80 % af den samlede værdi af projektet med implementering af workflowet for udgiftsbilag med integration til KSeF (det polske nationale e-fakturasystem), OCR, VIES, GUS (det polske statistiske centralbureau) og til sidst eksport af data til økonomisystemet. Denne ene integration, som ikke var blevet drøftet grundigt med leverandøren fra starten, fordoblede reelt projektets omkostninger.
Hvornår er der behov for en uafhængig rådgiver
Hvis I har et erfarent team, der allerede har forberedt flere lignende udbud, kan denne liste bruges som en kontrol. Et uafhængigt blik giver mening, når udbuddet er stort i forhold til organisationens størrelse, når kravene er opstået i kontakt med én bestemt leverandør, når beslutningen skal kunne forsvares over for en revision, et råd eller et hovedkontor, eller når ingen på ordregiversiden kender disse systemer indefra.
Jeg kan læse dokumenterne igennem, inden udbuddet offentliggøres eller forespørgslen sendes, udarbejde krav og testscenarier eller evaluere tilbud, der allerede er indkommet. I forvaltninger ser udgangspunktet lidt anderledes ud – det beskriver jeg på siden for lokale selvstyreenheder (JST – den polske betegnelse for kommuner og regioner).