Denne tekst henvender sig til direktioner og de personer, der skriver under på indkøbet af et system: kommunesekretæren og kommunekassereren i en offentlig myndighed, direktøren for et kommunalt selskab, CFO'en, virksomhedsejeren. Også til it-chefen, der forbereder udbuddet eller forespørgslen, og som gerne vil vide, hvad direktionen bør være opmærksom på, før dokumenterne godkendes.
Hvorfor problemet opstår
De fleste problemer med leverandører har deres oprindelse hos ordregiveren selv, og det længe før kontrakten underskrives. Ikke af ond vilje: at forberede et udbud er et arbejde, som organisationen sjældent har hverken tid eller kompetencer til, og det gør leverandørerne gerne lettere for jer. De kommer med færdige beskrivelser, demoer og tilbud. Resultatet er, at ordregiveren køber det, leverandøren er god til at sælge - ikke det, organisationen faktisk har brug for. Et andet problem er, at indkøbsbeslutninger meget ofte ligger hos de fagansvarlige afdelinger, mens it kun spiller rollen som sikkerhedsvagt. Manglen på standarder og en langsigtet it-strategi betyder, at organisationen foretager indkøb, som ikke altid passer ind i de rammer, hvis formål er at begrænse risiko.
De samme fejl ser jeg både i offentlige myndigheder og i virksomheder. Det, der adskiller dem, er indkøbsformen - ikke mekanismen.
Tolv fejl
- Krav skrevet med udgangspunkt i én leverandørs tilbud eller præsentation. Det begrænser konkurrencen og fastlåser afhængigheden, allerede før I har valgt leverandør. Jeg har skrevet mere udførligt om det i teksten om vendor lock-in i udbudsspecifikationen (SWZ).
- Ingen forretningsejer. Projektet har formelt en projektleder, men ingen med mandat fra direktionen beslutter, hvordan processerne skal fungere.
- Ingen leveringskriterier og testscenarier fastlagt før underskrift. Overtagelsen bliver en tvist om fortolkning i stedet for en kontrol af, om projektets leverance opfylder succeskriterierne for implementeringen.
- Manglende viden 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 systemer skal det nye system udveksle data med, i hvilke retninger, hvilke systemer har den overordnede rolle, hvilke data i hvilke formater - og ved leverandøren overhovedet det, og garanterer de, at de leverer de nødvendige mekanismer og tager ansvar for, at de fortsat fungerer?
- 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 over funktioner i stedet for en beskrivelse af processer. Enhver leverandør svarer "ja" på spørgsmålet om en funktion. På spørgsmålet om, hvordan de vil håndtere jeres konkrete case, er svarene forskellige.
- Sammenligning af startprisen frem for den samlede omkostning. Licensen er kun begyndelsen. Vedligeholdelse, ændringer og integrationer betaler I for i årevis. Den mekanisme beskriver jeg i teksten om den samlede ejeromkostning (TCO) og den kogte frø.
- Ingen regler for ændring af omfang. Det er uklart, hvem der indmelder en ændring, hvem der prisfastsætter den, og hvem der godkender den.
- Kontrakt uden exit-vilkår. Ingen bestemmelser om eksport af data, dokumentation eller overdragelse af vedligeholdelsen til en anden part. Ingen redskaber til at begrænse risiko.
- Vedligeholdelseskontrakt accepteret ud fra leverandørens standardskabelon. Serviceniveauer, reaktionstider og prisen på ændringer fastsættes så af den ene part alene.
- Beslutningen udskudt til sidste øjeblik før fristen. Når den lovbestemte frist eller udløbet af support på det gamle system nærmer sig, er der ikke længere plads til at sammenligne tilbud eller forhandle.
Fejl et til tre er de grundlæggende. Fjerner I dem, bliver de fleste af de øvrige synlige allerede i forberedelsesfasen - ikke først under gennemførelsen.
For byrådet, tilsynsrådet eller hovedkontoret er det vigtigste, om beslutningen om at vælge leverandør har en dokumenteret begrundelse. De tolv punkter ovenfor er samtidig en liste over spørgsmål, det er værd at stille, før direktionen godkender udbudsdokumenterne.
Eksempel fra praksis
En af vores kunder fik at vide af sin ERP-leverandør, at det uden problemer ville være muligt at udveksle data om samarbejdspartnere med det system til dokument- og sagsstyring (EZD/e-Doręczenia), der var ved at blive implementeret. Et system til dokument- og sagsstyring gemmer som regel data om alle samarbejdspartnere - ikke kun dem, hvor der sker økonomiske hændelser, altså hvor de bliver til kunder eller leverandører. Livscyklussen for data om en ny samarbejdspartner begynder ganske enkelt oftest langt tidligere, end de økonomiske hændelser indtræffer.
Under implementeringen viste det sig, at omkostningerne ved at tilpasse API-grænsefladen til tovejsudveksling af data om samarbejdspartnere hos ERP-leverandøren udgjorde 80 % af den samlede projektværdi for implementeringen af workflowet for omkostningsbilag i integration med KSeF, med OCR, WIES, GUS og til sidst med 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 en uafhængig rådgiver nødvendig
Har I et erfarent team, der allerede har forberedt flere lignende udbud, kan denne liste bruges som tjekliste. En uafhængig vurdering giver mening, når udbuddet er stort i forhold til organisationens størrelse, når kravene er blevet til i kontakt med én bestemt leverandør, når beslutningen skal kunne forsvares over for en kontrolinstans, byrådet eller hovedkontoret, eller når ingen på ordregiverens side kender disse systemer indefra.
Jeg kan gennemgå dokumenterne, før udbuddet offentliggøres eller forespørgslen sendes, udarbejde krav og testscenarier eller vurdere allerede indsendte tilbud. I offentlige myndigheder ser udgangspunktet lidt anderledes ud - det beskriver jeg på siden for lokale myndigheder (JST).