Undvik inlåsning vid it-upphandling

Vissa myndigheter upplever negativa inlåsningseffekter i gamla it-avtal. För att undvika inlåsning och säkerställa deltagande på lika villkor vid it-upphandling kan myndigheter följa fem rekommendationer som tagits fram av Björn Lundell med flera i en forskningsrapport.

Fem rekommendationer för att undvika inlåsningseffekter:

1. Ställ krav på interoperabilitet i stället för kompatibilitet. Krav på kompatibilitet med en specifik programvaruapplikation bidrar till inlåsning.
2. Ställ krav på öppna it-standarder (i stället för stängda it-standarder) för att undvika inlåsning. Uttrycks krav på en sluten it-standard, kan det (av både juridiska och tekniska skäl) hindra införande av standarden i öppen programvara.
3. Ställ endast krav på en it-standard om den har implementerats av ett eller flera öppen programvaruprojekt. Om det saknas en publikt tillgänglig öppen programvaruimplementation av en specifik it-standard innebär det betydande risker för inlåsning.
4. Undvik att uttrycka krav på specifika slutna programvaruapplikationer. Att uttrycka ett krav på en specifik proprietär programvara medför risker till exempel relaterat långsiktig förvaltning och återanvändning av de digitala handlingar som upprättas och behöver förvaltas av organisationen.
5. Utveckla en effektiv exitstrategi som gör det möjligt för den upphandlande organisationen att med kort varsel kunna avsluta användningen av en programvara utan att organisationen tappar kontrollen på den egna organisationens handlingar.

Ställ krav på interoperabilitet i stället för kompatibilitet vid upphandling
I flera it-upphandlingar i Sverige ställs omfattande krav på kompatibilitet i stället för interoperabilitet. Detta utgör ett problem när kompatibilitetskrav avser proprietär programvara i form av hänvisningar till specifika leverantörer, produkter eller stängda it-standarder som exempelvis AD (Active Directory), Microsoft Office 365, EPIserver, Oracle DB, Ipad, Stratsys. Sådana krav skapar inlåsningseffekter eftersom kraven riskerar att uppfyllas av endast leverantören för den specifika produkten som kravet syftar på.

Därför rekommenderar Björn Lundell med flera att byta ut krav på kompatibilitet mot interoperabilitet.

Kompatibilitet innebär att datorer, program, filer och tjänster är utbytbara eller kan användas av ett visst annat program. I praktiken innebär det att en dator som kan köra Office-paketet kan bytas ut mot en annan dator som också kan köra Office-paketet eller att ett nytt system som upphandlas kan läsa vissa specifika filformat som exempelvis MPEG eller DWG (som inte definieras som öppna standarder) från ett befintligt system.

Interoperabilitet innebär att två eller flera program kan kommunicera med varandra och använda mottagen information utan att behöva byta format på den mottagna informationen.

Rent tekniskt kräver interoperabilitet öppna standarder för att information ska kunna mottas i ett öppet format som programvaran har utvecklats för att tolka och använda.

Exempelvis kan öppna standarder som HTML5 och protokollet HTTP kommunicera med samtliga webbläsare som till exempel Mozilla, Chrome, Edge och Opera och stänger inte ute någon applikation.

Krav på interoperabilitet öppnar för leverantörer som erbjuder en produkt som kan kommunicera med andra system i den befintliga it-miljön och senare kan ersättas med programvara från en annan leverantör. Interoperabilitet fokuserar således mer på ett systems förmåga att utbyta information än ett systems utbytbarhet. Även proprietär programvara kan uppfylla interoperabilitetskrav.

Öppen programvara kan däremot inte uppfylla kompatibilitetskrav som innehåller hänvisningar till proprietär programvara eller som innehåller krav på licensiering av patent med villkor som omöjliggör användningen av öppna programvarulicenser.

Ur ett upphandlingsrättsligt perspektiv kan en upphandlande myndighet formulera kompatibilitetskrav som exempelvis innebär att ett befintligt system eller format ska kunna användas tillsammans med ett eventuellt nytt system som upphandlas.

Myndigheten behöver däremot utreda om det överhuvudtaget är möjligt att uppställa kompatibilitetskrav som hänvisar till ett specifikt varumärke eller en standard som inte definieras som öppen. Detta eftersom sådana krav kan gynna vissa leverantörer medan andra leverantörer missgynnas.

Sker så på ett otillbörligt sätt vid en offentlig upphandling kan en leverantör få detta överprövat i domstol. Om i stället interoperabilitetskrav premieras finns ingen risk för ett otillbörligt gynnande av viss leverantör.

Ställ krav på öppna standarder
Användningen av standarder i kravställning vid upphandling är ett sätt att beskriva vilka tekniska behov som efterfrågas.

En öppen standard är förenklat en standard som produceras och underhålls i en öppen miljö av ett community och/eller företag och som är fri att användas utan kostnad. Till exempel är det vid avrop från Kammarkollegiets ramavtal för programvaror och tjänster endast tillåtet att ställa obligatoriska krav på en viss standard om den uppfyller definitionen av öppen standard enligt SOU 2009:86 och kriterierna i det europeiska interoperabilitetsramverket 1.0 (EIF 1.0).

Kammarkollegiet har som ett stöd tagit fram en lista med it-standarder som bedömts uppfylla EIF 1.0 ramverkets kriterier och därigenom bedömts utgöra öppna standarder. Även Sveriges Kommuner och Regioner (SKR) påtalar att öppna standarder och öppen programvara bör användas vid anskaffning och upphandling. Ett avsteg från sådant användande bör vara väl motiverat.

Ur ett konkurrensperspektiv är öppna it-standarder ett verktyg för att minska leverantörsberoende och skapa interoperablitet genom att vara en motvikt till de dominerande stängda dokumentformat som skapats av enskilda företag.

Dessutom minskar kostnaderna för byte mellan olika programvaror vid användandet av öppna it-standarder eftersom alla leverantörer som erbjuder programvara som är interoperabel med myndighetens övriga it-miljö kan nyttjas. Det blir också möjligt att använda information till andra ändamål än vad som kanske först avsågs.

Ställ krav på öppen programvaruimplementation av varje it-standard
Om krav ställs på öppna it-standarder vid en upphandling är det viktigt att säkerställa att standarden har implementerats av ett eller flera öppna programvaruprojekt. Om det saknas en publikt tillgänglig öppen programvaruimplementation av en specifik it-standard kan det innebära betydande risker för inlåsning.

En standard som inte tidigare har implementerats i öppen programvara kan tyda på att det finns juridiska eller tekniska problem med standarden som på något sätt förhindrat tidigare användande.

Undvik att exkludera öppen programvara
Om en upphandlande myndighet vill skapa förutsättningar för anbud av leverantörer som erbjuder öppen programvara behöver kravställningen vara utformad så att leverantörer av öppen programvara inte exkluderas.

För att inte oavsiktligt utestänga anbud av öppen programvara bör myndigheter undvika att ställa krav i form av hänvisningar till proprietär programvara och dess filformat som ägs eller licensieras av en specifik leverantör.

Tidigare använda kravspecifikationer bör därför alltid ses över innan en upphandling annonseras för att motverka att kravspecifikationen inte är riktad mot en viss programvara och därigenom skapar inträdesbarriärer för nya leverantörer.

I stället bör öppna standarder användas om sådana finns. Alternativt bör krav formuleras som funktionskrav för att skapa en neutralitet i kravställningen. Funktionskrav beskriver vad ett program ska uppnå för resultat i verksamheten, i stället för hur programmet ska fungera.

Genom att beskriva de identifierade behoven via funktionskrav kan myndigheten undvika att beskriva ett befintligt program och således undvika inlåsningseffekter mot en specifik programvara.

Tillgång till en hållbar exitstrategi
För att säkerställa en hållbar exitstrategi när ett avtal upphör behöver det i avtalet regleras vad som ska hända med myndighetens data och hur övergången från befintlig leverantör till ny ska genomföras. Ofta är en risk- och sårbarhetsanalys ett bra verktyg för att synliggöra och analysera riskerna med en bristande exitstrategi och dess eventuella effekter och kostnader.

Det kan förekomma att befintlig leverantör är ointresserad av att föra över data till en övertagande konkurrent. Ett avtal bör därför alltid innehålla en reglering som ålägger leverantören en skyldighet att assistera vid flytt av data.

Avtalet bör även innehålla en reglering som ger myndigheten en rätt att förlänga avtalsperioden, med ett visst antal månader, om det bedömts nödvändigt för att slutföra avveckling och överlämning. En sådan reglering bör även gälla leverantören som ska se till att tillhandahålla programvaran till samma pris och på i övrigt samma villkor under förlängningsperioden, till dess att en ordnad övergång till ny leverantör är möjlig.

Om det saknas tekniska möjligheter för upphandlande myndighet att hämta hem data eller flytta data till en ny leverantör efter avtalsslut kan det innebära stora merkostnader. Att kravställa och avtala om användandet av öppna standarder är ett effektivt verktyg för att minska risken för de inlåsningseffekter som kan uppstå om myndigheten gjort sig beroende av leverantörsspecifika format för data eller dataöverföringsprotokoll (API).

Öppna standarder sänker tröskeln och kostnaderna vid byte av leverantör eftersom chansen ökar för att det finns andra leverantörer på marknaden som kan använda samma öppna format som befintlig leverantör.

Mårten Nyström Holm och Lina Nyman
Jurister Adda Affärsconcept
Johan Linåker
Forskare vid Lunds universitet och Rise, Research Institutes of Sweden

Artikelserien om upphandling och öppen programvara består av fyra delar:
Del 1: https://inkopsradet.se/upphandling/dela-kostnader-och-undvik-inlasningar/
Del 2: https://inkopsradet.se/upphandling/hitta-oppen-kallkod-som-klarar-kraven/
Del 3: https://inkopsradet.se/utvecklas-och-forvaltas-tillsammans/