Den här texten är för ledningar och de personer som sätter sin signatur på köpet av ett system: kommunsekreteraren och skattmästaren (skarbnik) på myndigheten, vd:n för det kommunala bolaget, finanschefen, företagsägaren. Den är också för IT-chefen som förbereder upphandlingen eller offertförfrågan och vill veta vad ledningen bör uppmärksamma innan den godkänner dokumenten.
Varför detta problem uppstår
De flesta problem med leverantörer har sitt ursprung hos den upphandlande organisationen, och det långt innan avtalet skrivs under. Inte av illvilja: att förbereda en upphandling är ett arbete som organisationen sällan har tid och kompetens för, och leverantörerna hjälper gärna till att underlätta det. De kommer med färdiga beskrivningar, demonstrationer och offerter. Resultatet blir att den upphandlande organisationen köper det som leverantören är bra på att sälja, inte det den faktiskt behöver. Ett annat problem är att köpbeslut mycket ofta ligger kvar hos de fackansvariga enheterna, medan IT-avdelningen bara har rollen som säkerhetsvakt. Avsaknad av standarder och en långsiktig IT-strategi gör att organisationen genomför inköp som inte alltid passar in i de ramar vars uppgift är att minska risken.
Jag ser samma misstag på myndigheter som i företag. Det som skiljer är upphandlingsformen, inte mekanismen.
Tolv misstag
- Krav skrivna utifrån en enda leverantörs erbjudande eller presentation. Det begränsar konkurrensen och befäster ett beroende redan innan ni valt leverantör. Jag har beskrivit detta mer utförligt i texten om vendor lock-in i tenderspecifikationen (SWZ).
- Avsaknad av en affärsägare. Projektet har formellt en projektledare, men ingen med mandat från ledningen bestämmer hur processerna ska fungera.
- Avsaknad av godkännandekriterier och testscenarier före undertecknandet. Godkännandet blir en tvist om tolkning i stället för en kontroll av om projektets resultat uppfyller de fastställda framgångskriterierna för genomförandet.
- Okunskap om vad som redan finns. Ni köper ett nytt system utan att veta vilka befintliga avtal, licenser och funktioner som överlappar med det.
- Förbisedda integrationer. Med vad ska det nya systemet utbyta data, i vilka riktningar, vilka system har den överordnade rollen, vilka data, via vilka format, och vet leverantören om detta och garanterar denne att leverera nödvändiga mekanismer samt ta ansvar för att de fungerar kontinuerligt.
- Datamigrering beskriven i en enda mening. Utan att fastställa vilka data, från vilken period, vem som rensar dem och vem som kontrollerar resultatet.
- Krav i form av en funktionslista i stället för en beskrivning av processer. Varje leverantör svarar "ja" på frågan om en funktion. På frågan hur de hanterar ert konkreta fall skiljer sig svaren åt.
- Att jämföra startpriset i stället för den totala kostnaden. Licensen är bara början. Underhåll, ändringar och integrationer betalar man för i åratal. Jag skriver om den mekanismen i texten om total ägandekostnad (TCO) och den kokande grodan.
- Avsaknad av regler för omfångsändringar. Det är oklart vem som anmäler en ändring, vem som prissätter den och vem som godkänner den.
- Ett avtal utan villkor för att lämna det. Avsaknad av bestämmelser om dataexport, dokumentation och överlämnande av förvaltningen till en annan part. Avsaknad av riskreducerande verktyg.
- Ett underhållsavtal accepterat från leverantörens mall. Servicenivåer, svarstider och kostnad för ändringar bestäms då av enbart den ena parten.
- Beslutet uppskjutet till sista stund före en deadline. När en lagstadgad tidsfrist eller slutet på supporten för det gamla systemet är nära finns det inte längre utrymme för att jämföra erbjudanden eller förhandla.
Misstag ett till tre är de grundläggande. Om ni eliminerar dem blir de flesta övriga synliga redan under förberedelsefasen, inte under genomförandet.
För fullmäktige, styrelsen eller huvudkontoret är det viktigaste om beslutet att välja leverantör har en dokumenterad motivering. De tolv punkterna ovan är samtidigt en lista med frågor värda att ställa innan ledningen godkänner upphandlingsdokumenten.
Exempel från praktiken
En av våra kunder fick av sin ERP-leverantör beskedet att det "inte skulle vara några problem" att utbyta leverantörsdata med det system för ärende- och korrespondenshantering (EZD/e-Doręczenia) som höll på att införas. Ett system för korrespondenshantering lagrar oftast uppgifter om alla motparter, inte bara dem för vilka ekonomiska händelser faktiskt uppstår, det vill säga blir kunder eller leverantörer. Livscykeln för en ny motparts data börjar helt enkelt oftast långt innan några ekonomiska händelser äger rum.
Under genomförandet visade det sig att kostnaden för att anpassa ERP-leverantörens API-gränssnitt för tvåvägs datautbyte om motparter uppgick till 80 procent av hela värdet för projektet att införa hantering av kostnadsdokument integrerat med KSeF, med OCR, VIES, GUS och slutligen export av data till ekonomi- och redovisningssystemet. Denna enda integration, som inte diskuterades noggrant med leverantören från början, fördubblade praktiskt taget projektets kostnader.
När behövs en oberoende rådgivare
Om ni har ett erfarna team som redan förberett flera liknande upphandlingar kan den här listan fungera som en kontroll. Ett oberoende perspektiv är meningsfullt när upphandlingen är stor i förhållande till organisationens storlek, när kraven tagits fram i kontakt med en enda leverantör, när beslutet kommer att behöva försvaras inför en revision, fullmäktige eller huvudkontor, eller när ingen på den upphandlande sidan känner till dessa system inifrån.
Jag kan läsa igenom dokumenten innan upphandlingen publiceras eller offertförfrågan skickas ut, ta fram krav och testscenarier eller utvärdera redan inkomna anbud. För myndigheter ser startpunkten lite annorlunda ut – jag beskriver den på sidan för kommuner och regioner (JST).