axel kellermann bloghoved

3 udfordringer i it-udbud i det offentlige

Efter at have været igennem to processer med udbud af it-systemer i det offentlige kan jeg se, at der er flere udfordringer, der skal ses på, hvis budgetterne skal bruges fornuftigt.

De udfordringer jeg ser er inden for følgende felter:

• Prioritering af parametre i udbuddet.

• Hvad er konkurrenceudsættelse?

• Bureaukrati i udbuddet.

Prioritering

Det, der har slået mig meget i den sidste proces, jeg har været med i, er, hvad der egentlig har været vigtigst i processen for de øverst ansvarlige, der ikke er med i selve projektformuleringen. Umiddelbart er de øverste prioriteter:

  1. Konkurrenceudsættelse

  2. Beskyttelse mod kritik

Konkurrenceudsættelsen er et mantra der overskygger alt. Dette betyder, at alle generelle krav der er til software eller leverandør, er en begrænsning i konkurrencen og dermed mulighed for kritik. Disse bliver ofte et udvælgelseskriterium i stedet.

Når man som fagperson skal vælge et system, vil følgende prioritering være hensigtsmæssigt:

  1. Funktionalitet

  2. Drift – kompleksitet og økonomi

  3. Videreudvikling af systemet – behov der opstår under driften og hvor lang tid forventer vi systemet skal operere

  4. Pris

Det kan selvfølgelig diskuteres om prisen er på 4. pladsen, men de tre andre er i hvert fald højt prioriteret.

Hvad er konkurrenceudsættelse?

Hvordan får man de rigtige virksomheder til at byde på en opgave, frem for dem der primært er gode til at svare på udbudsbetingelser frem for at udvikle gode systemer?

Umiddelbart skal man gøre noget ved bureaukratiet omkring udbudsprocessen.

Når man vælger at ændre et krav til en udvælgelsesparameter opfattes det som en mulighed for at få tilbud fra en bredere skare af virksomheder.

I realiteten er det, at føre virksomhederne bag lyset og spilde deres tid og penge på et udbud de ikke har en chance for at vinde. Dette gør at budprocessen bliver mere bureaukratisk, da der er flere parametre på buddet der skal dokumenteres.

Bureaukrati

I de processer jeg har været tilknyttet, har tilgangen til projektet egentlig været, at det skulle være en agil proces. Vi har alligevel brugt rigtigt mange timer på at definere projektet meget detaljeret til udbuddet. Mange af disse processer skal man igennem igen
når den endelige leverandør er valgt, da det er den måde leverandøren kommer til at kende kunden og projektet på.

Efter min opfattelse skal man finde en metode hvor forberedelserne kan minimeres, således at man ikke skal processen igennem 2 gange. Udover at man skal processen igennem vil processen også resultere i noget andet, da målet har flyttet sig siden og så kan man komme ud i kontraktslige udfordringer.

Det må kunne gøres smartere.

Måske er problemet også at projektformuleringen finder sted på et forkert niveau i organisationen for langt fra der hvor systemet skal anvendes!?

Debatten

Jeg kan konstatere at der har været en del artikler om problematikken over sommeren, både med erfaringer fra udlandet, samt med personer i staten, der er centrale i udbudsprocessen.

De signaler synes jeg er meget positive og jeg glæder mig meget til at disse ændringer siver ned ad i organisationen, så IT-udviklingen kan blive bedre.

De væsentligste forbedringer i udbudsprocessen vil være:

• afbureaukratisering af processen, således at flere virksomheder vil synes at det er interessant at byde på opgaverne

• større bevidsthed om hvilke prioriteter der er væsentlige

• mindre berøringsangst for at stille krav frem for at bruge udvælgelseskriterier, herunder krav til udvidet brugeradgang eller open source.

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

Nu har jeg også været inde over resultatet af en del større udbud, og efter min mening så er der meget lille fokus på hvad det egentlig var der skulle løses.
Udbudsprocessen burde KUN være, fokus på hvad der skal løses (dvs. funktionelt - ikke bureakratisk eller politiske krav) - og så viser diverse erfaringer fra England (der åbenbart har set lyset og haft success), at man er nødt til at have folk der er rigtigt dygtige teknikere til at styre processen FRA STARTEN AF.

På den måde kan der spares mange penge, fordi dygtige teknikere (der rent faktisk kan programmere selv, og rent faktisk har erfaring i store driftsmiljøer), kan kende skidt fra kanel, og ved hvornår det bare er varm luft, eller som jeg ofte ser - når noget faktisk bare burde tage 1 dag - og ikke den halve eller hele million buddet angiver.

Så fokus på teknisk kompetance helt fra starten af process - især når den er nødt til at være fokuseret på agilitet.. man ved aldrig hvor man ender - og man er nødt til at kunne ændre løsningen efterhånden som man bliver klogere.

Idag bliver de ændringsbehov der altid kommer, bare til en blanko-check til den der har budt på opgaven - de ved udenmærket hvordan de skal formulere det - så staten/kommunen betaler gildet (også selvom det efter min erfaring ikke er særligt imponerende tekniske kompetancer leverandørerne besidder - og jeg har personligt mange gange måtte løse problemer på 15 minutter, som de har bokset med i dagevis).

Så fokus på at have den nødvendige ekspertise til at styre teknikken fra start af - og en erkendelse af at "fast pris" på "løse formuleringer" (som udbud faktisk er - uanset hvor præcis man har forsøgt at være) ikke findes, og man derfor bør dele opgaver op i mindre opgaver, der er til at overskue og man dermed faktisk kan få en fast pris der kan holde (jvf. englands erfaringer mht. samme).

  • 4
  • 0
Claus Jacobsen

Du har som sådan ret Klavs - desværre er det bare "utopi" at tro det vil kunne komme til at ske. Alene på grund af punkt 2 i Axels indlæg - nemlig beskyttelse mod kritik. Tovholdere og projektejere er på ingen måde tekniske men derimod djøffere ansat på tilskudsordninger (fordi der ikke er noget normalt arbejde til dem. Og jeg undskylder. Det er hårdt sagt, men desværre i mange tilfælde også alt for sandt) Og derfor må der på ingen måde falde nogen kritik tilbage på dem og alt bliver kørt juridisk og man vil derfor aldrig kigge på løsninger, men dækning af fejl i stedet. Det er en mentalitetsændring der skal til før vi ser forandringer, men som det er lige nu, så ser jeg ikke noget som helst tegn på at vi går i den retning. Tværtimod.

  • 2
  • 0
Jonas Høgh

Hvad er forskellen på krav og udvælgelseskriterier?
Der er sikkert en indforstået bureaukratisk forståelse for forskellen mellem et krav og et udvælgelseskriterium. Men for os der arbejder i den del af virkeligheden, der ikke indebærer offentlige udbud, kunne det være rart med en 3D-model i bølgepap.


Uden at være ekspert i offentlige udbud, gætter jeg på at udvælgelseskriterier er de parametre udfra hvilke leverandøren vælges, fx "Prisen vægtes 50%", "Leverandørens modenhed på en skala fra 1 til N ifølge den og den model vægtes 20%" og lignende.

Et krav er blot et simpelt "Systemet skal gøre X". Har leverandøren et krav, kan et givent tilbud ikke godkendes, med mindre det opfylder kravet.

  • 0
  • 0
Julian Hollingbery

Udbudsprocessen burde KUN være, fokus på hvad der skal løses (dvs. funktionelt - ikke bureakratisk eller politiske krav)

Det er meget naivt at forestille sig at dette kan lade sig gøre, al den stund at Det Offentlige er en organisation som dels er for stor til at det kan undgås, og dels åbent bekender sig til at være politisk styret. Det er et vilkår, som man som tekniker gør bedst i at indrette sig efter. Min erfaring er, at de bedste tekniske løsninger opnås hvis teknikere tilegner sig et minimum af politisk sans, særligt hvis det kan kombineres med at løsningsejerne har et minimum af respekt for eller endda indsigt i teknikken.

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