Kan vi undgå monopol?

På det kommunale it-område er vi ved at nå frem til en af de større milepæle. Inden udgangen af dette år skal samtlige 98 kommuner nemlig tage stilling til, om de vil tilslutte sig de kommende fælleskommunale udbud på det såkaldte monopolområde, som Kombit nu er klar til at skyde igang.

Baggrunden er følgende: KMD har igennem årtier haft - og har fortsat - monopol på en række af de it-systemer, som kommunerne er helt afhængige af. Det drejer sig bl.a. om systemer til udbetaling af kontanthjælp og sygedagpenge. Ved salget af KMD i 2009 blev der indgået en såkaldt transitionsaftale mellem KMD og KL, som fastsætter et loft over den pris, som kommunerne betaler for monopolsystemerne. Transitionsaftalen ophører imidlertid med udgangen af 2014. Hvis ikke der sker et brud på KMD's monopol på de pågældende it-systemer inden da, vil der være en meget betydelig risiko for uforholdsmæssige store prisstigninger på området fra 2015 og frem. Det er derfor nødvendigt, at processen med at bringe it-systemerne på monopolområderne i udbud påbegyndes nu, så de nye it-systemer kan være klar ved udgangen af 2014 eller umiddelbart derefter.

KL og Kombit forventer, at et monopolbrud vil føre til en prisreduktion på de omfattede systemer på mindst 25% i forhold til det der ville skulle betales, hvis KMD's monopol får lov at fortsætte efter 2014. Penge, som kommunerne sagtens kan bruge i disse trængte år.

Et meget væsentligt argument for at gennemføre monopolbruddet som et fælleskommunalt udbud, hvor samtlige 98 kommuner tilslutter sig, er, at nye leverandører kun vil finde det attraktivt at byde ind på denne type komplekse og højtspecialiserede it-systemer, der udelukkende har et marked hos de danske kommuner, hvis de på forhånd er forvissede om, at de får samtlige 98 kommuner som kunder i ét hug.

Det afføder naturligvis spørgsmålet, om der så overhovedet bliver tale om et monopolbrud?

For mig at se er der nemlig så reelt kun 2 scenarier i den proces, som vi nu kan se frem til:

1) KMD byder med deres oparbejdede ekspertise på feltet og vinder samtlige kommuner. Det betyder, at monopolet fortsætter som hidtil.

2) En anden leverandør end KMD vinder udbuddet og får samtlige kommuner som kunder. KMD's monopol er brudt, ja. Men monopolet er der stadig. Det er blot flyttet over til en anden leverandør.

Ingen af disse to scenarier fører således til reel, løbende konkurrence på det kommunale it-marked - bortset fra under selve udbudsfasen. Forhåbentlig vil selve udbuddet formå at presse prisen på de pågældende systemer med de i udsigt stillede 25%, men i den efterfølgende bindingsperiode på 10 år (!) (dette er den afskrivningshorisont, der opereres med af hensyn til nye leverandørers investeringsbyrde) vil kommunerne igen kun have én leverandør at spille bold med omkring ydelser, funktionalitet, udvikling m.m. af de pågældende systemer.......

Sagen er blot, at det er vanskeligt at se, hvordan denne problemstillling ellers skulle være grebet an. Danmark er et lille land og et lille marked; og markedet for kommunale forvaltningssystemer er en lillebitte niche med højtspecialiserede behov, som ikke kan brødføde mange leverandører. Måske kun én.

Ole Bechs billede

Kommentarer (14)

Pascal d'Hermilly

Betal for udvikling og kræv at det bliver open source.
Så bliver drift ikke nær så dyrt og man binder sig ikke til leverandøren for en årrække.
Hvis man køber endnu en closed source løsning er man naiv eller har glemt hvor meget en 10 årig investering skal give i ROI for en IT-virksomhed.

Jonas Nielsen

Kræv at staten/kommunerne har retten til source-koden og lav så meget så muligt af den open source, således at mindre firmaer kan byde ind med rettelser. Ansæt en person med en it-uddannelse og/eller en som har prøvet at arbejde som udvikler til at styre projektet.

Det er selvfølgelig et stort problem for leverandøren af systemet, hvis han ikke har rettigheden til source-koden, da de personer der rent faktisk udvikler systemet bare kan skifte til en konkurrerende leverandør, hvis de ikke synes de får ordenlig løn eller har ordenlige arbejdsforhold. Pga. denne konkurrence er det derfor min erfaring at en leverandør meget sjældent er interesseret i at hans program er open source (i og med at direktøren af firmaet eller projektlederen normalt ikke er udviklere selv). Men det kommer jo stort set alle andre til gode.

Thomas Johansen

Netop derfor burde KMD være forblevet stats eller kommune ejet. Så kunne kommunerne sammen styre retningen af udviklingen.

Om KMD så den gang blev ledet forkert eller andre årsager til monopolistiske høje priser for kommunerne ved jeg så ikke en disse om.

Nils Bøjden

Når man betaler for udvikling af et system skal man sikre sig at man har ejerskabet over:

Datamodellen
Interfacemodellerne
Process beskrivelserne
Sourcekoden

Så i skal skrive i jeres kontrakt at i selvfølgelig har ejerskabet til disse komponenter. De kan så genbruges til næste udbudsforretning da I jo selv ejer komponenterne.

Om det så skal OpenSovses, i Public domain eller noget andet kan i så som kunde selv beskrive, men da vi (os alle sammen ) har betalt for funktionerne kan I nok lige så godt overføre det til Public Domain.

Jens Peter Jensen

men da vi (os alle sammen ) har betalt for funktionerne kan I nok lige så godt overføre det til Public Domain.

Lige præcis! Når jeg som skatteborger er tvunget til at betale til en softwareløsning, skal koden selvfølgelig som udgangspunkt fære fuldt offentlig, dvs. tilgængelig for mig, der har betalt.

Kræv, at alt på maskinerne er Open Source.

Kræv, at funiktionalitet primært tilvejebringes, ved at bruge alment anvendelige Open Source frameworks (f.eks. Databasesystemer, web-frameworks, m.m.). Hvis de mangler funktionalitet, er opgaven at udvikle de pågældende moduler, til at kunne understøtte funktionaliteten - helst ved at få rettelserne indført i de officielle pakker (ja, deltage i det eksisterende Open Source miljø) - alternativt lave jeres eget (midlertidige?) offentligt tilgængelige fork af projektet.

Hold mindst muligt af koden for jer selv, men lad det være kommunernes/statens ejendom. De firmaer, som byder på opgaven, er ikke ejere af koden, de stiller basalt set blot udviklere til rådighed.

Forestil jer, hvis flere nationers myndigheder samarbejdede med at udvikle åben software, som de alle kunne bruge, med mindre lokale tilpasninger - der bliver immervæk brændt en del skattekroner af på softwarelicencer og des lige på verdensplan - de kunne lige så godt blive kastet i retningen af åben software, hvor meget af basissoftwaren også ville være anvendelig for de skatteborgere, som alligevel har betalt for det.

Martin Bøgelund

Når man betaler for udvikling af et system skal man sikre sig at man har ejerskabet over:

Datamodellen
Interfacemodellerne
Process beskrivelserne
Sourcekoden

Så i skal skrive i jeres kontrakt at i selvfølgelig har ejerskabet til disse komponenter. De kan så genbruges til næste udbudsforretning da I jo selv ejer komponenterne.

Præcis!

"Del og hersk" er et godt gammelt datalogisk princip - bestil modulariserede løsninger (i modsætning til ét gigantisk system) hvor komponenter kan udvikles og udskiftes uafhængigt, og sæt jer benhårdt på især interfaces (protokoller, formater mv.) som nævnes ovenfor.

Måske kræver det flere ressourcer up front, men på sigt undgår i monopolisering og deraf følgende opskruning af priser.

Om det så skal OpenSovses, i Public domain eller noget andet kan i så som kunde selv beskrive, men da vi (os alle sammen ) har betalt for funktionerne kan I nok lige så godt overføre det til Public Domain.

Da der ikke er noget der hedder Public Domain i dansk jura, er det ikke en mulighed. Men igen, hvis i sørger for ejerskab over især snitflader (og tilhørende specifikationer) er det jo ikke et problem at gøre dem alment tilgængelige, hvorefter en open source løsning nemt kan poppe op i en udbudsrunde...

Jens Peter Jensen

Forresten, til mit første indlæg. Fordelen ved at udvikle mest muligt som frit tilgængelig Open Source programmel, som andre (privatpersoner/firmaer) også kan bruge (alt fra åbne kontorpakker, databasesystemer til regnskabs/økonomisystemer, m.m.) er, at der så vil være væsentlig flere "nørder" derude, som vil hjælpe med at vedligeholde og udbygge jeres progrmpakker.

Mikkel Christensen

Der tror jeg nu godt man kan undgå - men bestemt ikke ved at lave endnu et kæmpeudbud. Eller ved på forhånd at stille en masse begrænsninger op af frygt for at skabe endnu et monopol.

At forfølge endnu en mega-udbuds-plan, og så forvente at der kommer andet output end en monstrøs, monolitisk, de-facto 'monopolær' løsning ud af det (som vi jo efterhånden har set mere end 1 gang) virker en kende fakta-resistent set fra mit bord.

At starte med drakoniske leverancebetingelser kommer nok heller ikke til at løse problemet - det kommer langt mere sandsynligt til at føre til en massiv risikoinddæknings-strategi fra de leverandører som ender med at turde byde (og så ender vi med endnu en omgang langtrukkent juristeri når kastanjerne skal rodes ud af ilden).

Man kunne måske med fordel i stedet anvende et standard-trick fra matematikken/fysikken som f.eks. bruges til at håndtere 'gordisk-knude' problemstillinger: redefiner problemet - herunder ikke mindst: Simplificer problemet.

Til en begyndelse kunne man gribe i egen barm og se på hvor mange af de eksisterende arbejdsgange som i virkeligheden kunne løses med standard software. Dernæst kunne man se på hvor mange af de tilbageværende arbejdsopgaver som kunne laves om så de kunne løses med standard software. Endeligt var det måske en mulighed at se på om der er (pre-digitaliserings) lovgivning som modarbejder muligheden for at bruge standard software, og som måske kunne moderniseres en anelse så det ikke var så stor en barriere.
Alt sammen noget som kan udføres uden endnu et højrisiko-udbud. Og lur mig om ikke denne proces dels vil afsløre en del lavthængende frugter, dels vil være et glimrende udgangspunkt for at angribe de tilbageværende problemstillinger - og hvordan man, i småbitte bidder, vil sætte custom-strøm til disse.
Måske endda afprøve en indkøbsmodel hvor flere leverandører faktisk leverer konkurrerende implementeringer (af de tilpas små bidder), og hvor man så kan vælge den bedste - i stedet for at lade leverandørerne konkurrere om hvem som er bedst til at besvare udbud.

…and then I woke up, but the dream was really nice…

Martin Arendtsen

Hvor vil alle de systemer skulle driftes?
Sådan som jeg forstår det i dag bliver de fleste systemer også driftet hos KMD.
Hvem vil skulle overtage driften? Skal den udliciteres eller vil kommunerne selv skulle stå for det?
Og hvis driften outsources hvad så med opbevaring af personfølsomme data som fx. CPRnummer?

Sådan som jeg ser det er det ikke kun på software siden der skal kigges.
Det er over det hele.

Nils Bøjden

Og hvis driften outsources hvad så med opbevaring af personfølsomme data som fx. CPRnummer?

Dette kan driftes over alt i EU, hvis leverandører giver garanti for at data ikke forlader EU. Om man så stoler på leverandøren er en helt anden sag. F.eks er det nok usikker om et amerikansk firma kan undsige sig Patriot Act. Og mit gæt er at Kinesiske, indiske, russiske eller filippinske firmaer (og andre for den sags skyld) ej heller kan modstå et tryk fra deres regeringer / efterretningstjenester om udlevering af data.

Men en god kryptering (+2048, med nøglen i Danmark) kan selvfølgelig løse en del af de problemer.

Klavs Klavsen

Ligesom de vist laver med det nye bibliotekssystem - hvor koden er oprettet i et projekt, og andre kommuner kan hente koden - og tage del i udviklingen.

På den måde vil det en kommune laver - kunne bruges og videreudvikles af andre kommuner til deres behov - og inden længe skulle projekterne gerne have commit'ere fra div. kommuner der har behov for ændringer, og sikkert flere kommuner som brugere - der kan bruge det som det er.

Sørger man for at tænke oversættelse ind - kunne kommuner i andre lande, sikkert også bruge nogen af systemerne - og det ville kun gøre det hele mere fleksibelt og fremtidssikret for alle.

Ægte Open Source handler IKKE kun om at koden er der - men om måden man gør tingene på :)

Peter Lange

Som det er fremhævet er det danske marked lille, så det kan være svært at undgå en solo-leverandør situation hvis bare der skal være lidt stordriftsfordel. Men det kunne man vel også leve med hvis man får testet priserne gennem gen-udbud hver 4.-6. år og får et sekventielt monopol.

Kunsten i den model er at skabe porterbarhed og sikre at skiftet fra den første leverandør til det næste er med i kontrakten med den første leverandør. Sådan at den første leverandør ikke har opfyldt sine kontratuelle forpligtelser før der er bestået en afleveringsprøve til den næste leverandør.

Solo-leverandør situationen er god til at skabe kritisk masse og lav initiel pris. Man skal bare ikke blive i situationen årti efter årti. Der skal være fokus på governance, specifikationer og leverandørstyring.

Jeg er måske mere spændt på hvilke tiltag der kan gøres for at få et bredt ansøgerfelt der kan magte opgaven. Indeholder kravspecifikationen f.eks. beskrivelse af hvordan man udregner ydelserne, eller vil man kun fokusere på dem der har sådan en ekspertise, for så er der nok ikke nogen over eller ved siden af KMD. Går man efter eet stort udbud, eller udbyder man f.eks. først platform, derefter tilpasning og så drift?

Rune Juhl-Petersen

Jeg tror ikke at det umiddelbart er muligt at bryde KMD's monopol. Heller ikke hvis systemerne bliver open source og overholder standarder. Problemet som jeg ser det er ikke af teknisk karakter, men af politisk. Ud over krav specifikationerne til systemerne følger der også en bunke lovtekster som skal overholdes. Det giver komplekse systemer fordi lovgivning sjældent er logisk funderet og bare lægger til hvad der var i forvejen. Jeg kan huske at Ny Alliance gerne ville have indkomst skat på 40% til alle og afskaffe fradrag. Det er sådan nogen tiltag der skal til for at gøre det offentlige simplere og muliggøre uafhængighed af leverandører.

Peter Lange

Det er en rigtig god kommentar. Der synes at være en vis politisk forståelse for at effektiv digitalisering kan have en sammenhæng til regelforenkling. For nyeligt er underskriftskravet blev ændret så Digital Post har samme vægt som fysisk post. Men der skal jo endnu mere til af den slags. Hvis man f.eks. tror at folkepension er enkelt, så skal man blot tage fat i brøkpension for at se et patchwork af overgangsordninger, ændringer mv.

Log ind eller opret en konto for at skrive kommentarer

IT Businesses