Software (altid) et politisk valg

Transkript

1 En artikel fra KRITISK DEBAT Software (altid) et politisk valg Skrevet af: Jan Mølgaard Offentliggjort: 01. oktober 2009 I tidsskrifter og på nettet - i diskussioner rundt omkring i statslige organer og kommuner - næsten overalt, hvor den slags diskuteres, fremstilles offentlige myndigheders valg af softwareløsninger, standarder og platforme primært som et rationelt, teknisk og økonomisk valg. Det styrker denne fremstilling, at alt hvad der har med it at gøre omgærdes af specialjargon, uigennemskuelige forkortelser og - set ud fra den almindelige borgers synsvinkel - mystik, som det er op til den teknologiske præstestand at tolke og forstå. Men de valg og de forpligtelser, som valgene medfører, er alt andet end rent rationelle, når det kommer til stykket. Ligesom de processer, som leder frem til valgene heller ikke er det. Lad os tage et eksempel. Følgende beskrivelse er baseret på et helt konkret og virkeligt forløb. Men den kunne lige så godt være baseret på et andet forløb et helt andet sted. En større dansk kommune skal anskaffe et nyt såkaldt ESDH-system 1. Årsagen til at behovet dukker op er at det system, man hidtil har anvendt, ikke længere vedligeholdes af leverandøren. Og at dette system er baseret på en platform, som dels skønnes mindre anvendelig, dels strider imod de arkitektoniske standarder, som kommunen har valgt at ville følge fremover 2. Hele den diskussion, som er gået forud for valget af standarder, berøres ikke her - selvom den også i høj grad er politisk i sin karakter. Nuvel. Man hyrer et konsulentfirma. Begrundelsen er, at en proces af denne karakter er så kompleks og så krævende, at man har brug for ekstern bistand for at kunne køre den hjem efter reglerne og på den rigtige måde. Og allerede her er der foretaget et politisk valg. Hvilket vi skal vende tilbage til. Konsulentfirmaet leverer en generisk (generel) kravspecifikation 3. Som oplæg til kommunens diskussioner og det interne arbejde. Og denne kravspecifikation bearbejdes herefter i en organisation, som er bygget op til formålet. Første produkt fra denne proces er de såkaldt udbudsbetingelser, et sæt af dokumenter (herunder en annoncetekst), der kan bruges til at annoncere udbudets første fase - prækvalifikationen. I prækvalifikationsprocessen udvælges de leverandører, der får lov til at deltage i selve udbudsprocessen. Og i prækvalifikationsrunden udstikkes ligeledes dels de kriterier, som leverandørerne udvælges efter, dels de helt generelle kriterier, som udbudsforretningen styres af. I den konkrete historie stilles det for eksempel som et krav for udvælgelse, at leverandøren har referencer for løsning af tilsvarende opgaver, og at leverandøren skal have den nødvendige størrelse til også at kunne levere rådgivning og inspiration i relation til den fremtidige udvikling af it-miljøet i den pågældende kommune. Her træffes politisk valg nummer to. Stiller man den slags krav, så udelukker det helt automatisk en lang række potentielle leverandører - leverandører der typisk ville kunne have sikret en alternativ løsning baseret på andre standarder. For nylig blev det offentliggjort, at Oslo kommune havde valgt Microsoft Exchange 4 som sin fremtidige post- og kalenderplatform (digi.no 17. september 2009). En af de potentielle leverandører (IBM med et tilbud på en Open Source platform ved navn Zimbra 5 ) klagede over at være udelukket på forhånd, fordi Oslo Kommune havde krævet et 1 / 6

2 referencegrundlag, som leverandøren ikke kunne levere på norsk baggrund, fordi løsningen er relativt ny. Klagen blev dog afvist. I vores historie var der tilsvarende krav, også helt bortset fra at der var indirekte krav i den it-arkitekturplan, som var en del af udbudsmaterialet, hvoraf det meget klart fremgik, at vores kommune var en Microsoft-kommune. For det andet blev der i udbudsgrundlaget (og det blev siden hen gentaget) stipuleret en vægtning af de kriterier (tildelingskriterier), som ville blive lagt til grund for den endelige afgørelse. Af denne vægtning fremgik det, at økonomien spillede en ganske væsentlig rolle - faktisk så væsentlig, at hvis man forholdt sig en smule taktisk til det som leverandør stort set kunne fjernstyre udgangen af udbudsforretningen. Nå, altså. Prækvalifikationen gik, som man kunne forvente. Der blev udvalgt fire potentielle leverandører. Alle med stort set identiske løsninger. Alle baseret på Microsoft-standarder. Og alle baseret på Microsoft-snitflader. Og efterfølgende gik resten af processen så også, som man kunne forvente. Dialogerne med de potentielle leverandører og diskussionen i projektgruppen rejste spørgsmålstegn ved den overordnede strategi og ved de tildelingskriterier, som var opsat fra starten af projektet. Men hver gang man forsøgte at få taget disse nye erfaringer alvorligt, så blev der henvist til, at vores kommune var bundet juridisk af disse tildelingskriterier og af den kravspecifikation, der var udarbejdet som udbudsgrundlaget. Man havde med andre ord fraskrevet sig retten til at lære af processen. Og hver gang der blev sat spørgsmålstegn ved strategien, så blev disse spørgsmålstegn afvist med henvisning til, at man også på dette område var bundet af de procesforudsætninger, som var blevet etableret, før processen i virkeligheden var begyndt. Processen endte så med to ting, der også bliver fremstillet, som om de er neutrale og fornuftsstyrede, men ikke er det. For det første vejer man de enkelte tilbud op imod hinanden gennem et babylonisk pointsystem, hvor æbler og pærer og tordenskrald og Rundetårn alle sættes på numerisk form, tælles sammen og derefter omregnes til nogle kvotienter. Den der scorer højest er vinderen. Der er store metodiske problemer knyttet til sådanne modeller. For eksempel kan man - hvis man ikke er meget opmærksom - risikere, at man indirekte svækker for eksempel værdien af "brugsnemhed" i forhold til, om en given løsning lever op til bestemte - set fra brugerens side irrelevante - it-arkitektoniske faktorer. Eller man kan risikere at gå den modsatte vej. For det andet skal man have opgjort økonomien i projektet. Og det er heller ikke så enkelt som det lyder - og det er vigtigt, når økonomien tæller 30 % af slutresultatet. Skal der anvendes priser som grundlag? Dvs. listepriser på de leverede ydelser - eller skal man se på totaløkonomien (det der kaldes for TCO 6 i fagsproget) for hele kontraktperioden? Til ingens overraskelse blev der valgt en leverandør med den laveste licensudgift og en teknik, der stillede ultimative krav om anvendelse af Microsoft både på den strukturelle side og på snitfladesiden. Den politiske dimension i disse valg og i det endelige valg af leverandør ligger ikke så meget i slutresultatet, men der ligger så meget mere i de præmisser, som blev opfyldt undervejs og som prædestinerede valget i sidste ende. For det første kravet om en omfattende lokal referenceliste. Det er lidt som med Kaptajnen fra Köpenick. Man kan få ordrer, hvis man er leverandør af løsninger i forvejen. Og leverandør i forvejen 2 / 6

3 bliver man, hvis man får ordrer i det nødvendige omfang. Stiller man krav af den karakter, der formelt set er begrundet i, at man skal have bevist, at man kan håndtere en ordre af dette omfang, så udelukker man automatisk en masse potentielle og mere spændende leverandører, fordi de endnu ikke har leveret i tilstrækkeligt omfang. For det andet i den svinebinding, der knytter sig til de juridiske regler omkring en udbudsproces. Hvis man ikke helt fra starten er klar på sine præmisser - og hvis man undervejs igennem processen måske bliver klogere - så hænger man alligevel på disse præmisser. Og den leverandør, der er taktisk klog nok, forstår selvfølgelig at udnytte sådan en situation. I realiteten er kunden eller rekvirenten den, der står med den ringeste, juridiske beskyttelse. Og det skyldes naturligvis, at udbudsjuraen er lavet med et bestemt formål. Hvad har det så med Open Source Software 7 (OSS) at gøre? I det konkrete eksempel (og i sagen fra Oslo) fandtes der og findes der alternativer baseret på åben kildekode. ESDH-alternativet kunne for eksempel hedde Alfresco 8 og alternativet til MS Exchange kunne for eksempel hedde Zimba. Vælger man Microsoft eller leverancer baseret på Microsoft-standarder, så vælger man licenseret, krypteret software, hvor ændringer i kundens forretningsmæssige behov helt automatisk vil udløse store ekstraudgifter til softwareændringer, og hvor man mere eller mindre slavisk bliver bundet til en multinational koncerns prioriteringer vedrørende versionsudskiftninger og krav til det underliggende maskinel og operativsystemer. Det bliver med andre ord ikke kunden, der længere træffer beslutninger om ændringer. Det bliver i meget høj grad leverandøren. Enten ved at lave krævede opgraderinger (eller for eksempel sikkerhedsrettelser) eller ved at stille helt urimelige krav til finansieringen af omlægninger. Man får selvfølgelig en form for garanti for vedligeholdelse og fejlretning samtidig, dvs. garantier for driftsstabilitet, men man sælger samtidig sin frihed til selv at beslutte, hvordan et givet administrationsområde grundlæggende skal fungere. Vælger man derimod OSS-baserede løsninger, så vinder man i fleksibilitet, tilpasningsduelighed og variationsmulighed. Men taber i den forstand, at man som bruger eller brugerorganisation selv skal tage sig af en række af de opgaver, som ellers leveres af totalleverandøren. Vælger man krypteret 9 software, så fravælger man med andre ord også i vidt omfang sin selvbestemmelse. Vælger man krypteret software, så fravælger man også i vidt omfang den demokratiske selvbestemmelse i for eksempel den kommunale administration. I offentligheden er OSS ofte gjort synonymt med f. eks. en kontorsuite som Open Office 10. Men ideen rækker langt længere end det. Open Office er blot en kontorpakke (vedligeholdt af softwarefirmaet SUN og en række frivillige), der kan hentes og installeres gratis og hvis kildekode frit kan redigeres af brugerne. Men OSS derimod er et princip. Ikke alt software leveret som OSS er licensfrit eller gratis. Men det helt afgørende er, at kildekoden 11 leveres med løsningen og kan redigeres frit af brugeren. I modsætning til de mange såkaldt krypterede løsninger, hvor kildekoden er pakket ind - kompileret 12 - således at funktionerne står til licenstagerens rådighed uden at koden kan åbnes. Vælger man som kunde en løsning baseret på OSS, så betyder det en række ting: 1. Man kan på et hvilket som helst tidspunkt gå ind og ændre eller få en frit valgt leverandør til at ændre i koden, så den tilpasses forandrede forretningsmæssige behov. 3 / 6

4 2. Man er ikke bundet til at følge leverandørens eventuelle opgraderinger eller skift i licensregler subsidiært prisstruktur. 3. Man kan på et hvilket som helst tidspunkt tilføje ny funktionalitet via de åbne og dokumenterede snitflader i produktet. 4. Man kan frit arbejde videre med de data, som produktet fanger eller genererer. Data og dataadgang er lige så åbne som selve koden. 5. Man kan frit dele sin løsning med andre eller gå fælles med andre om at udvikle forretningsspecifikke løsninger, der uden videre kan indføjes i ens løsning efter behov. Ingen af delene kan garanteres, såfremt man vælger krypteret software. Har man for eksempel behov for at lave ændringer i den måde, som et Microsoft produkt virker på, så er det Microsoft der bestemmer, hvordan det skal og kan laves. Leverandøren har måske (eller måske ikke) stillet nogle snitflader 13 til rådighed, men selve programmet er skjult for brugeren og kan ikke ændres. Dette er en del af licensvilkåret. Vælger man løsninger baseret på lukket kode (modsat OSS), så fraskriver man sig muligheden for selv at definere ændringer uden mellemkomst af enten den primære softwareleverandør eller en af ham udvalgt tredjepart. Vælger man løsninger baseret på lukket kode, så fraskriver man sig også retten til selv at bestemme, i hvilken takt (om overhovedet) man ønsker at følge leverandørens opgraderingskrav. Vælger man løsninger baseret på lukket kode, så er det leverandøren der bestemmer, hvordan data skal håndteres og struktureres. Og det er således i sidste ende også leverandøren, der bestemmer, om en given forretningsmæssig praksis kan indføres og anvendes eller ej. Argumenterne for alligevel at vælge denne type software er som regel følgende: 1. Man ved hvad man får 2. Service på ens programmel påhviler leverandøren og det kan man betale sig fra 3. Man vælger - hvis man for eksempel vælger Microsoft - en de facto markedsstandard, det vil sige at man kan kommunikere uden problemer med mellem 60 og 80 procent af de øvrige aktører i ens område 4. Fremtidig udvikling og forfinelse - herunder stram versionsstyring og et højt niveau for aftestning og fejlfrihed - påhviler leverandøren og er garanteret Men alt dette er sandheder med mange modifikationer. 1. Man ved rent faktisk ikke altid, hvad man får. Når man ikke kender programlogikken, så har man ingen muligheder for at teste om de data, som leveres fra løsningen, rent faktisk er korrekte og retvisende. Børssystemer baseret på lukkede programstandarder har givetvis en del af skylden for nogle af de fluktuationer i aktie- og kreditmarkedet, som vi har set de seneste år. 2. Service er i denne sammenhæng et temmelig elastisk begreb. De store producenter af licenseret, lukket software vil altid forsøge at rette sig ind efter en mellemproportional på brugerbehovssiden. Og det betyder ganske ofte, at et specialbehov der egentlig burde tilgodeses via service ikke altid kan imødekommes. Og service er ligeledes en genstand for indtjening. Hvorfor det i sidste ende ikke er behovet men betalingsevnen, der afgør om et behov tilgodeses. 3. Vælger man for eksempel Microsoft, så vælger man ganske vist et sæt af standarder, der gør at man uden problemer kan kommunikere med alle andre, der har valgt de samme standarder. Men samtidig skaber man en række problemer i relation til de brugere, der har valgt et andet standardsæt. Man kan udveksle Word med Word (blot der ikke er for langt imellem versionerne). Men man kan ikke udveksle Word frit. 4. Man er garanteret fortsat udvikling, det er korrekt. Men man er ikke garanteret den udvikling, som man efterspørger - i hvert fald ikke nødvendigvis. Til gengæld er man garanteret 4 / 6

5 tvangsopgraderinger med mellemrum, hvis frekvens og omfang man ikke er herre over. Summa summarum: Som oftest favoriserer den forudgående proces de markedsdominerende leverandører og standarder. Og det der fremstilles som et omhyggeligt styret, rationelt begrundet og fornuftsbaseret projekt, der leverer objektive valgkriterier som grundlag for den endelige beslutning, er i realiteten et maskeret forhindringsløb for alle alternativer. Den fornuftige konklusion er ikke fornuftig, men maksimalt forsvarlig. Det, der udelukkes, er de reelle økonomiske og tekniske alternativer. De udelukkes med uigennemskuelige tildelingskriterier, juristeri og ren manipulation. Det, der er konsekvensen, er at kommunerne og de statslige organer i vidt omfang spændes for en monopoliseringsvogn og bindes til at betale for meget for løsninger, der kun i en markedsføringsverden er bedre eller mere stabile. Valg af OSS-baserede løsninger bevarer beslutningsmyndigheden hos den købende kommune. Dette valg betyder også, at ansvaret for vedligeholdelse og videreudvikling kommer til at belaste brugeren. Men til gengæld herfor får man løsninger, der er langt mere fleksible, langt bedre til hurtige omstillinger og langt billigere både på det korte og på det lange sigt. Politisk står valget altså imellem om man ønsker at sælge sin selvstændighed til en softwareleverandør frem for at ville bevare den. Økonomisk står valget imellem om man vil prioritere sin service frem for sin forsyningssikkerhed. Og imellem om man ønsker - reelt ønsker - at bruge lidt flere penge på at vedligeholde selv - eller om man vil bruge mange flere penge på at fraskrive sig ansvaret sammen med selvstændigheden. Det valg har det vist sig, er tilsyneladende sværere at træffe i de danske kommuner, end man skulle tro. Kilder for eksempel: sopgraderinger Noter 1 ESDH står for Elektronisk Sags og Dokument Håndtering og er en systemløsning som sikrer systematisk registrering og lagring af alle de dokumenter, som produceres i en administration. 2 IT-arkitekturen beskriver de standarder og de snitfladevalg, som en given installation har besluttet sig for at anvende for at sikre, at data og informationer kan tilgås og udveksles efter behov. 3 Kravspecifikationen er det dokument, som danner grundlaget for leverandørernes tilbud. Alle leverandører skal svare på alle krav i dokumentet. Og disse svar er så dels kommunens garanti for, at den får et produkt, der kan bruges, dels et juridisk grundlag for en eventuel senere sag, hvis det viser sig, at det leverede ikke lever op til kravene. 4 Exchange er Microsoft Corporations bud på en post og kalenderplatform - typisk anvendes MS Qutlook eller et andet Windows-klientprogram til af brugeren at læse post, revidere kalender osv. 5 Zimbra ( er et Open Source alternativ (dvs. med åben kildekode), der rummer den samme funktionalitet som f. eks. MS Exchange eller Lotus Domino. 5 / 6

6 6 TCO står for Total Cost of Ownership og omfatter alle direkte og afledte omkostninger - herunder også timeforbrug og eventuelle nødvendige hardwareinvesteringer - ved driften af en given løsning. 7 Open Source Software er software med såkaldt åben kildekode. Brugeren af løsningen har adgang til hele kodedelen i en OSS-baseret løsning og kan gøre med den, hvad han vil. Ikke at forveksle med Freeware. Typisk er OSS licensfri (dvs. gratis) og freeware er det altid. Men ikke al OSS er freeware. 8 Alfresco / Sugar er et OSS-baseret såkaldt CRM-system, der kan løse de samme opgaver som det ESDH-system, som blev valgt i vores eksempel. Se mere for eksempel her: 9 Krypteret software er software, der er pakket sammen i en form, hvor man ikke som bruger har direkte adgang til softwarekoden. Typisk leveres Microsofts (og en række andre leverandørers) softwareløsninger i denne form for at sikre leverandøren imod kopiering uden licensbetaling. 10 Open Office er en såkaldt kontor- eller officesuite, der rummer tekstbehandling, regneark, præsentationssoftware og databasesoftware meget lig for eksempel Microsoft Office. Men Open Office er licensfri og Open Source baseret. 11 Kildekoden er de kodelinjer, der gør, at et program kan udføre forskellige operationer - slå op i en database, sortere data og præsentere dem på skærmen. 12 At kompilere kode betyder at fortolke den og pakke den, således at koden overfor brugeren præsenteres for eksempel som en EXE-fil - et program, der udfører en eller flere funktioner. 13 Snitflader er sæt af kommunikationsstandarder, der gør, at man kan kalde et program med en bestemt, fastlagt syntaks og derefter forvente, at programmet svarer på en bestemt måde med velbeskrevne data. 6 / 6