kim tiedemann bloghoved

Byg de offentlige udbud op igen

I mit sidste blogindlæg skrev jeg, noget provokerende, at de offentlige udbud skal brændes ned, og man skal starte forfra. Der er gået 14 dage og i perioden er SKAT kommet med nyheden om forsinkelse og fordyrelse af ejendomsvurderingssystemet på 2 milliarder og DXC og regionerne/kommunerne er gået fra hinanden ved udvikling af Praksys, som startede i 2014 og endnu ikke leveret.

Det medførte en del kommentarer - de fleste af dem var enige i mine betragtninger: At offentlige udbud fungerer dårligt og ikke nødvendigvis skaber værdi for de offentlige myndigheder, da kunden tvinges til at vælge dem, der er bedst til at skrive tilbud og ikke nødvendigvis dem, som er bedst til at lave løsningen. Det er blevet meget dyrt for kunden at lave et mere og mere omfattende udbudsmateriale og for leverandørerne at svare på på det, hvilket gør det svært for små og mellemstore leverandører at deltage i offentlige udbud. Giver det tilsvarende værdi? Og kan man få innovation og fleksibilitet gennem en udbudsdikteret kravspecifikation?

Hvorfor har vi så udbud? Det giver god mening, at offentligheden ønsker at konkurrenceudsætte indkøb af IT. Det anfægter jeg ikke behovet for. Det er helt naturligt, og det er også noget, virksomheder og privatpersoner gør hele tiden. Offentlige myndigheder skal passe på vores alle sammens penge. Samtidigt ønsker vi alle at undgå korruption, magtmisbrug, etc, og selve processen og tildelingen er af samme årsag underlagt skrappe krav, hvis formål er at skabe transparens. Når udbuddet er slut har kunden valgt det økonomisk mest fordelagtige tilbud. Det kan ske på baggrund af forskellige tildelingskriterier, som er mere eller mindre objektive. Efter min mening er det dog en en illusion, da udbuddet stadig kan skrives til en leverandør eller drejes derhen, hvor kunden ønsker det.

Er der så nogle IT-udbud, som fungerer? Efter min mening fungerer det bedst, når kunden skal indkøbe et standardsystem, som med få (meget få) konfigurationer kan bruges til at løse kundens problem. Som eksempel kan nævnes SKI02.19 - software-as-a-service, hvor det offentlige køber ind for op mod 4 milliarder kroner. På aftalen køber de standardsoftware til IT understøttelse af fx det sociale område, til sundhed, løn eller jobcenteret (Disclaimer: Jeg er CTO hos Schultz, som blandt andet sælger IT til jobcentre på netop denne aftale). Her kan kunderne købe ind gennem direkte tildeling eller ved at lave et miniudbud, og SKI har afløftet kommunernes behov for store EU-udbud, og de køber standardsoftware-as-a-service, som bruges i de pågældende forvaltninger. Det skal dog også tilføjes, at, det at lave et tilbud til selve SKI udbuddende, kan være ret udfordrende og omfattende.

Forslag til at bygge det op igen

Først og fremmest skal jeg slå fast, at jeg ikke er jurist, så jeg kan ikke vurdere om nedenstående forslag er juridisk mulige indenfor udbudsloven eller EUs direktiver. Der er i udbudsloven åbnet op for mere fleksible udbudsformer, som fx konkurrencepræget dialog og udbud efter forhandling, som måske kan bruges. På trods af min manglende juridiske indsigt, vil jeg alligevel gerne give et bud på nogle forbedringer:

Større ansvar

Grundlæggende synes jeg, at offentlige myndigheder skal tage et større ansvar: Et ansvar for deres forretning, og hvordan de bruger IT til at understøtte den. Det går ikke at forsøge at udlicitere det hele og endda få konsulenter til at drive et udbud. Hos kunden skal der være domænespecialister, som ved ALT om forretningen og forretningslogikken. Og der skal være IT-arkitekter, som kan gennemskue om løsningen som tilbydes og udvikles kan løse deres behov, og om man får en løsning af god teknisk kvalitet, som kan vedligeholdes fremadrettet. Leverandører er gode til at bygge IT-løsninger, de kender håndværket, og de ved, hvordan en god udviklingsproces skal skrues sammen, så man får en effektiv udviklingsorganisation. Det gør de, fordi de ikke laver andet for mange forskellige kunder. Men forretningen og det overordnede tekniske ansvar skal ligge hos kunden og kan ikke outsources.

Prøv det af...

Mit ene forslag er at offentlige kunder inviterer 2-3 leverandører ind og lader dem lave en mini-MVP (Minimum Viable Product), som de betaler for. Så får kunden testet Leverandørens tanker om projektet, og - lige så vigtigt - om samarbejdet kan fungere. Det offentlige har købt IT-projekter til flere hundrede millioner kroner baseret på et udbudsmateriale og et tilbud, som leverandørerne til tider kun får 40 dage til at skrive. Turde du bruge så mange penge baseret på de to ting? Det er meget svært at forestille sig, at der i sådan en proces kan skabes et bare nogenlunde ens billede af projektet mellem kunde og leverandør. Og vi har desværre også set eksempler på IT-projekter der er endt i hegnet (bla. EFI, Polsag, KOMBIT KY og KOMBIT støttesystemer) uden at skabe værdi for hverken kunde eller leverandør. Det er nemlig en anden ting, som er vigtigt ved offfentlige udbud. Det skal kunne skabe værdi for begge parter. Ellers ender man i en "skæv" situation, hvor enten kunden føler sig snydt eller Leverandøren taber penge. Ingen af delene er særligt sjove, og man ender i evige kontraktdiskussioner.

Det agile setup

En anden mulighed er et agilt setup, hvor offentlige kunder køber leverandøren ind til at levere konsulenter og en agil udviklingsmetode. Det er altså en simpel kontrakt og et simpelt udbudsmateriale, hvor kunden køber navngivne konsulenter med en relevante kompetencer samt leverandørens agile udviklingsmetode, som er gennemprøvet og kan levere kvalitetssoftware. Kunden stiller med Product Owner og i samarbejde mellem kundens og leverandørens arkitekter designes løsningen. Hvordan sikrer kunden sig, at de får hvad de har betalt for? 1) De får løbende løsningen at se, da de er dybt involveret i processen og 2) hvis de ikke får det, så skal de kunne smide leverandøren på porten med meget kort varsel. Det giver samtidigt mulighed for, at man kan ændre scope undervejs, da kunden ikke har købt en løsning på en kravspecifikation, men i stedet en leverandørs evne til at levere software.

Fordelen er at udbudsmaterialet kan holdes meget simpelt, og man fokuserer på at skabe løbende værdi.

Hos Schultz har vi sammen med Københavns universitet arbejdet i et meget agilt setup, som jeg har beskrevet i et tidligere blogindlæg. Styrelsen for Arbejdsmarked og Rekruttering har også med succes arbejdet på denne måde i deres udvikling af hele deres projektportefølje.

Hvad gør vi nu?

Jeg har i ovenstående givet nogle forslag til forbedring af udbudsprocessen. Næste år skal Folketinget diskuttere udbudsloven og Tommy Ahlers har taget handsken op. Jeg håber at det offentlige får mulighed for større fleksibilitet i udbud og vi får lejlighed for at samarbejde baseret på mere tillid, mindre kontrakt og fokus på software der kommer i drift.

Lets get to work

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Heisterberg

Ja, en alt-vidende, alt-styrende, Product Owner er da en fremragende ide. Spørgsmålet er så, at en sådan (eller et team af sådanne) kan findes ?

Der er jo, også helt nye,eksempler på et totalt misforhold mellem ide og realitet: Statens famøse inddrivningssystem, som starter med under 20 gældstyper, og ender med 400+.
Men jeg er enig i, at det måske kunne være afdækket i en MVP-proces, eller måske ikke aligevel ?

Sundhedsplatformen havde jo både test, pilot og begrænset Go-Live, men er endt i en situation med fatale fejl (medicinering), og udbredt utilfredshed (var det 65% af lægerne, for eksempel).

Dette sidste eksempel understrejer bare, som POLSAG, at systemer der har karakter af processtøtte,sagsstyring, og lignende, er ekstremt komplicerede - fordi menneskelige processer involveres.

Måske er et godt udgangspunkt at LÆSE og FORSTÅ de forskelige rapporter som findes - desværre følges anbefalingerne sjældent.

Desuden er der ingen erstatning for at FORSTÅ hvad det handler om - og det kræver insider-viden; det kan aldrig blive ekstern konsulent-viden.
Vejdirektoratet har ifølge det oplyste succes med at levere til tiden og til prisen - men de har også egne medarbejdere gennem mange år.
Er det her nøglen skal findes ?

  • 0
  • 0
Povl H. Pedersen

Jeg tror at en stor forskel til det private er, at i det private med så store systemer, der udvikler man selv, og har selv ansvaret. Man hyrer nok konsulenter ind, og som vi ser hos Coop, så siger de i dag om bemandingen, at det er 1/3 IT folk, 1/3 konsulenter, og 1/3 forretning.

Hvor mange offentlige IT projekter har samme sammensætning ? Dvs 1/3 eksterne når det går højt ? INGEN.

Det offentlige har ikke hånd i hanke med projekterne. De har sendt for stor en del ud til leverandøren. De er vel heldige hvis de får 1/3 interne ressourcer på i en periode. Og dermed har man ikke fingeren på pulsen, og alting glider. Der skal træffes beslutninger hele tiden. Hvilke genveje skal tages ? Hvilken teknisk gæld kan man leve med ? Trækker den renter, eller afskriver den sig selv ? Hvad er nice have og hvad er must have.

  • 5
  • 0
Kim Bjørn Tiedemann Blogger

Ja, en alt-vidende, alt-styrende, Product Owner er da en fremragende ide. Spørgsmålet er så, at en sådan (eller et team af sådanne) kan findes ?

Nok ikke i en person hvis projektet er stort. Men et kollegium af PO vil efter min mening (og erfaring) også fungere. Det drejer sig mest af alt om at tage ansvar for sin kerneforretning og hvordan IT bruges i denne.

Sundhedsplatformen havde jo både test, pilot og begrænset Go-Live, men er endt i en situation med fatale fejl (medicinering), og udbredt utilfredshed (var det 65% af lægerne, for eksempel).

Sundhedsplatformen var ikke et traditionelt IT projekt. Her var der nærmere tale om, at man tager et standard system (og fordi der er til det amerikanske sundhedsvæsen minder det mest af alt om et ERP system) og så vrider man i det for at få det til at understøtte en dansk klinisk proces. Jeg var involveret i de tidlige (2004) EPJ projekter og der havde man faktisk mange gode tanker om IT understøttelse af den kliniske proces baseret på forløb.

Vejdirektoratet har ifølge det oplyste succes med at levere til tiden og til prisen - men de har også egne medarbejdere gennem mange år.
Er det her nøglen skal findes ?

Ja, viden om og ansvar for egen forretning.

  • 0
  • 0
Kim Bjørn Tiedemann Blogger
  • 0
  • 0
Thomas Knudsen

Hvilken teknisk gæld kan man leve med ? Trækker den renter, eller afskriver den sig selv

Povl, hvad vil det sige at en teknisk gæld "afskriver sig selv"? Jeg kan forestille mig det tilfælde hvor den tekniske gæld ligger i kode der alligevel (af andre årsager) vil blive udfaset, men er der i så fald tale om egentlig teknisk gæld (set i det aktuelle projekts perspektiv)?

Er der andre oplagte tilfælde af "teknisk gæld, der afskriver sig selv"?

  • 0
  • 0
Log ind eller Opret konto for at kommentere