Frygten for fejl holder udbuds-cirkus i gang - ikke paragrafferne

Man kan sagtens lave bedre udbud med dialog undervejs med de nuværende regler, fastslår it-advokat. Problemet er lige nu traditioner og frygt for fejl.

Der er god plads til forbedringer, når danske offentlige kunder sender it-opgaver i udbud, også uden at ændre en eneste paragraf.

Problemet er nemlig ikke kun den danske fortolkning af EU-reglerne om udbud, men i lige så høj grad nogle fastgroede idéer om, hvordan man skriver en kravspecifikation, og frygten for at havne i en klagesag.

Sådan lyder det fra it-advokat Nicolai Dragsted, der er partner i advokatfirmaet Bender von Haller Dragsted.

»Vi har en tradition i Danmark for at skrive en helt detaljeret kravspecifikation. Udbudsreglerne bliver forstået som om, at man skal have defineret løsningen helt entydigt. Men det er ikke nødvendigt, hverken i forhold til udbudsreglerne eller kontraktuelt, så vi skal have vendt den tradition,« siger advokaten til Version2.

Samtidigt er det nemt at klage over et udbud, for eksempel hvis en leverandør føler sig forbigået, og det er med til at gøre hele processen mere tung og forsigtig.

»Der bliver indgivet rigtig mange klager, og det kan medvirke til en tendens, hvor reglerne bliver fortolket meget restriktivt. Så kræver det en meget stor indsats som leverandør at undgå at begå fodfejl,« siger Nicolai Dragsted.

Generelt er de offentlige kunder heller ikke ret modige og foretrækker at køre udbud på den måde, som de kender, så risikoen bliver så lille som mulig.

»Der er en lav vilje hos de offentlige kunder til at afprøve grænserne for reglerne. Der er - forståeligt nok - en vis risikoaversion og tradition for, at vi lægger meget stor vægt på at overholde alle regler og ligge på den sikre side. Men problemet er, når den risikoaversion fører til kontrakter og kravspecifikationer, der forhindrer, at gevinsterne realiseres, og ikke sjældent giver en forøget risiko for et kuldsejlet projekt, « fastslår Nicolai Dragsted.

Resultatet er en dyr proces for kunde og leverandør - der hurtigt skræmmer mindre leverandører væk - men også løsninger, der ender med at blive både dyre og dårlige, fordi alt har været hugget ud i sten fra starten af.

I stedet for den klassiske kravspecifikation skal de offentlige kunder og deres rådgivere hellere prøve at ryste traditionerne ud af hovedet og tænke mere på alt det, de kan lære undervejs i projekterne, lyder rådet. Her hjælper det at bruge de agile projektmodeller.

Ender med alt for mange krav

Første faldgrube er, når kunden sætter sig ned og skriver kravspecifikationen.

»Ethvert projekt har et forretningsmæssigt formål. Det kan være ganske få og meget konkrete fordele, man vil opnå - men de bliver som regel konverteret til en kravspecifikation med alt for mange krav. Processen sker gerne i en sort boks med nogle få personer, der beslutter, at alle disse krav er nødvendige for at opfylde formålet, men det er som regel vanskeligt at se, hvorfor alle de mange krav er vigtige, og om de er formuleret fornuftigt,« siger it-advokaten.

I stedet skal kunden først og fremmest beskrive formålet med it-projektet og rammerne for det. Her er det naturligt at tage udgangspunkt i business casen, man har lavet først.

»Det skal skrives, så det tydeligt fremgår for hvert eneste krav, hvordan kravet skal hjælpe til med at opnå det forretningsmæssige mål. Ellers kan kravet smides væk, for så er det nok overflødigt. Med den vinkel i kravskrivningen har man allerede en kommunikation i sit materiale,« siger Nicolai Dragsted.

Når kravspecifikationen er klar, skal udbuddet skrives sådan, at man ikke blot køber en komplet løsning hos leverandøren, men i stedet lægger mere vægt på at købe kompetencer og arbejdskraft til projektet.

»Man køber hjælp til at køre projektet, og det indebærer, at man undervejs sammen afdækker, hvilke punkter, det omfatter. Og så skal kontrakten hjælpe til, at man få mest muligt ud af den tid, man køber hos leverandøren,« forklarer Nicolai Dragsted.

Den store fordel er, at kunde og leverandør sammen kan finde frem til en langt bedre løsning, der giver den ønskede effekt, end hvis projektet var kørt helt traditionelt, med fokus på at realisere kravspecifikationens detaljerede tekniske krav.

»Ved at sætte fokus på det i kontrakten, kan man få udbytte af alle de opdagelser, der kommer undervejs i processen. Leverandøren lærer langt mere om kundens forretningsmæssige situation og arbejdsgange, og den dialog udmønter sig så i en it-løsning,« siger it-advokaten.

Kravspecifikationen skal så bruges til at sikre enighed om spillereglerne og formålet med projektet, men der er yderst sjældent behov for en forudgående specificering af den endelige løsning i de mindste detaljer.

»Der er ikke noget i udbudsreglerne, som forhindrer dette her. Det er bare et spørgsmål om at fastlægge, at genstanden, man anskaffer sig, er arbejdstid. Og man har stadig rammerne, der sikrer juridisk, at man får et godt resultat, uden at man skal specificere det hele,« forklarer Nicolai Dragsted.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Heisterberg

Det fornuftigste som længe er skrevet om offentlige it-udbud.

Desværre MANGLER artiklen økonomien ! De agile metoder FORUDSÆTTER evne og vilje til at gennemføre flere iterationer. Det bliver ikke nødvendigvis dyrere, men det er bliver anderledes.
Det betyder, at der ikke er tale om fast pris, men måske en prisramme.
Og DET har offentlige kunder vanskeligt ved at håndtere.

Så nye budgetmodeller og -godkendelser hører med til konceptet.

OG så skal ledelsen lytte til brugererfaringerne. Seneste omtale af et Politi-system (Polvagt) er et fremragende eksempel på manglende lydhørhed.

  • 1
  • 0
Morten Korsaa

Tak til Nicolai for et konstruktivt bidrag. Jeg vil nu fastholde at det ikke burde være nødvendigt at skulle kæmpe med et kontraproduktivt regelsæt ;-) Men når det nu er der,....

I Finland/Australien har de knækket koden, og lavet et rigtigt godt koncept ud af det. Hvis man oven i Nicolais tanker lægger muligheden for at handle på "størrelsen" af software'en, fuldstændig som man bruger kvadratmeter som en basis enhed i hus handler/byggerier.
Så kan man gå i udbud med de overordnede forretningsmæssige krav, en forventet størrelse, og så handle på prisen/ størrelsesenhed, og afregne pr leveret enhed! Lyder det bekendt?

På den måde fordeles ansvaret for den forretningsmæssige udnyttelse af systemet hos kunden, og ansvaret for den effektive udvikling af systemet hos leverandøren. Lyder det også bekendt?

Når disse sunde principper for professionel udvikling og handel sættes sammen til et koncept der også virker for it udvikling kaldes det SCOPE management. Det finske justitsministerium har med det nedbragt deres udgifter til systemudvikling til en trediedel! Og de har ikke specielt favorable vilkår.

En nøglemetode er brugen af Function Points som størrelsesenheden. Og hvis du, som mange, har dårlige erfaringer med dem, så skal du vide at der er kommet nye standarder (FISMA, NESMA,..), som er uffatteligt mere operationelle end dem vi kendte i 90'erne (Ifpug). Frygt ej, alle kan lære f.eks FISMA Function Points på en formiddag. Og det er lige så nyttigt som en tommestok for en tømrer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize