Equinor har allerede inngått en stor avtale med Microsoft om bruk av Azure og også andre private selskaper har anskaffet eller vil anskaffe skytjenester. Det offentlig Norge henger ikke etter de private og flere offentlige etater er nå ute med forespørsler eller er i ferd med å gå ut.
Felles for mange av forespørslene vi har sett så langt er at kundene ikke har god nok juridisk/merkantil forståelse av hvorledes en skytjeneste faktisk fungerer og dermed heller ikke hvorledes en anskaffelse av standardiserte skytjenester bør gjennomføres og reguleres. Dette gjelder spesielt innenfor det offentlige hvor det på grunn av anskaffelsesregelverket er ekstra viktig å treffe rett. En tilsvarende «bom» innenfor det private kan enkelt rettes uten å måtte avlyse en pågående konkurranse.
Felles for mange av forespørslene vi har sett så langt er at kundene ikke har god nok juridisk/merkantil forståelse av hvorledes en skytjeneste faktisk fungerer
Ut fra det vi ser baserer mange konkurransegrunnlag seg på mer tradisjonelle avtaleteknikker hvor avtaleparten må garantere for at skytjenesten skal oppfylle kundens krav i hele avtaleperioden. Avtaleparten er normalt ikke leverandør av standard skytjeneste, men snarere en integrator eller en agent/ forhandler (reseller). Dette strider mot at hele poenget med å kjøpe standardiserte skytjenester er å kjøpe en standardisert innovativ og dynamisk tjeneste som hele tiden er i utvikling/forbedring. Da må kunden åpne for at skytjenestene vil, og kommer til å endre seg. Konkurransegrunnlagene tar heller ikke hensyn til at de store internasjonale skyleverandørene som Microsoft Azure, Salesforce, Google, Oracle osv faktisk krever at kunden må akseptere standard tjenestevilkår i sin helhet for i det hele tatt å kunne motta tjenester fra disse.
Mange offentlige kunder, benytter Dataforeningens Skytjenesteavtale i sine konkurransegrunnlag, uavhengig av om det skal anskaffes SaaS eller IaaS/PaaS. Utfordringen er at denne avtalen, og langt på vei også SSA-L, kun passer for kjøp av single tennant/kundespesifikke løsninger og ikke standardiserte skytjenester (særlig ikke fra de store internasjonale leverandørene).
Vi ser allerede flere eksempler på avlysninger av konkurranser i markedet fordi kundene bommer på konkurransereglene/kontraktsteknikken og dermed kun får få tilbud eller tilbud som muligens må avvises. Spesielt for offentlige kunder skyldes dette at anskaffelsesregelverket legger begrensninger på hvilke endringer den offentlige oppdragsgiver kan gjøre i konkurransegrunnlaget etter kunngjøring. Det er et begrenset manøvreringsrom for å justere konkurransegrunnlaget etter endringsforslag/forbehold fra tilbyderne i tilbudsfasen. Det er dermed ekstremt viktig for spesielt offentlige kunder å komme riktig ut fra hoppkanten for å unngå risiko for avlysning eller unødig dårlig konkurranse som kanskje gir en løsning man egentlig ikke ønsker.
Vi ser allerede flere eksempler på avlysninger av konkurranser i markedet fordi kundene bommer på konkurransereglene/kontraktsteknikken
Hva må kundene således gjøre for å lykkes i første forsøk?
Først og fremst må kundene huske på at dersom man ønsker å kjøpe standardiserte skytjenester, hvor en får det samme som alle andre, vil og skal funksjonalitet og/eller kapabiliteter hele tiden være i endring med jevnlige oppdateringer. Kundene kan ikke da stille funksjonelle krav eller andre krav som gjør at skytjenesten ikke fritt kan videreutvikles av skyleverandør slik skyleverandør selv ønsker, Ett eksempel her er Dataforeningens Skytjenesteavtale som gjennom ordlyden krever at skytjenesten «dekker de samlede funksjoner, formål og krav som fremgår av Avtalen, gjennom hele Tjenesteperioden» i pkt. 2.1. Hvis dette er behovet så må man rett og slett vurdere noe annet enn standardiserte skytjenester.
Om man på tradisjonell måte kjøper standard programvare er ikke nevnte problematikk like relevant. Integratorer/reseller påtar seg i slike situasjoner normalt ansvaret for oppfyllelse av alle kundens krav basert på én spesifikk versjon av programvaren som implementeres. Nye versjoner og ny funksjonalitet blir normalt håndtert i en vedlikeholdsavtale. Den opprinnelige kravspesifikasjonen fra implementeringsavtalen vil ikke gjelde for slike nye versjoner, og kunden velger selv om/når kunden vil implementere den nye versjonen.
Ved kjøp av SaaS-tjenester endrer bildet seg radikalt fordi SaaS-tjenesten oppdateres for alle kunder flere ganger i året. Som eksempel vil det for Microsoft D365 komme én større oppdatering i april og én i oktober hvert år. Slike oppdateringer vil fjerne, endre og legge til funksjonalitet. Kundene har frem til nå maksimalt hatt anledning til å utsette oppgraderingen i 6 måneder, noe som nå endres til 3 måneder. Dette gjør at systemintegratorer ikke kan påta seg ansvaret for at spesifikk funksjonalitet opprettholdes i hele avtalens varighet, slik Dataforeningens skytjenesteavtale krever. Integrator kan bare garantere et øyeblikksbilde, og funksjonalitet som er viktig for kunden kan være endret endog fra tidspunkt for avtaleinngåelse og frem til kunden tar løsningen i bruk. Forhåpentligvis vil oppdateringer forbedre tjenesten, men kunder med spesielle behov vil kunne vurdere en oppdatert versjon som dårligere enn den foregående versjon.
Det er fortsatt slik at man normalt vil implementere de fleste standard programvareløsningene som leveres som SaaS med kundespesifikke konfigurasjoner, tilpasninger og egne grensesnitt. Men standardprogramvaren som sådan vil være under kontinuerlig endring, og dette vil påvirke kundens løsning slik at det også må gjøres endringer i denne. Dette er en «risiko» som kunden må være villig til å ta for å få tilgang til standardiserte og presumptivt billigere og innovative løsninger enn klassiske on-premise løsninger.
Ikke krev at avtalens krav opprettholdes i hele avtaleperioden
Med andre ord – ikke krev at avtalens krav opprettholdes i hele avtaleperioden. Innarbeid heller på en juridisk korrekt måte i konkurransegrunnlaget at:
- Integratoren/reseller må innestå for hvilke krav som kan løses ved konfigurering evt. tilpasning ut fra øyeblikksbildet når tilbudet leveres. Dette er innenfor integrators/reseller kontroll, og det er uansett viktig å sikre seg mot at integratorer/reseller «overselger» muligheter i SaaS løsningen.
- Reguler hva forpliktelsene til integratoren/reseller er ved oppdateringer i SaaS-tjenesten. Det er forutsigbart for integratoren/reseller hvor ofte oppdateringer kommer til SaaS-tjenesten, og integratoren/reseller kan trolig fastprise jobben med å følge med, informere kunden, konsekvensutrede og anbefale hva som bør gjøres av endringer i kundens tjeneste. Men man bør vurdere nøye om man som kunde er tjent med å også be om at evt. oppdateringer implementeres av leverandøren innenfor fastprisen, i alle fall når det er snakk om større konfigurasjoner som trengs for å aktivisere ny funksjonalitet, eller hvor det vil trengs endringer i tilpasninger eller grensesnitt. Dette kan fort bli langt dyrere enn å avtale pris når implementeringen skal gjøres. Men her finnes det mange varianter som kan innarbeides i en avtale.
Videre så er det trolig hensiktsmessig at kunden tydeliggjør i utkast til kontrakt at man som kunde blir bundet av tjenestevilkårene fra tjenesteleverandøren i sin helhet når en kjøper SaaS eller IaaS/PaaS-tjenester gjennom en systemintegrator/reseller. SSA-L legger for eksempel opp til dette, mens Dataforeningens Skytjenesteavtale sier i pkt. 2.2.2 det litt meningsløse at det er kun er vanhjemmels og disposisjonsrettsbestemmelsene i standard tjenestevilkår som gjelder for kunden.
De store skytjenesteleverandørene krever at tjenestevilkårene deres speiles fullt og helt mot sluttkundene ellers får ikke reseller/integrator lov til å videreselge tjenesten til denne kunden. Konsekvensen av å ikke speile tjenestevilkårene er dels at kunden risikerer at tjenesten stoppes av skyleverandøren i det øyeblikk skyleverandøren finner ut at vilkårene ikke er speilet i sin helhet, og reseller/integrator risikerer også å motta krav om erstatning fra skyleverandøren for ethvert tap skyleverandøren måtte lide som følge av dette.
Vår anbefaling er således å lage en kontrakt som åpner opp for at skytjenesteleverandørs vilkår gjelder fullt og helt også mot kunden
Vår anbefaling er således å lage en kontrakt som åpner opp for at skytjenesteleverandørs vilkår gjelder fullt og helt også mot kunden. Kunden bør først og fremst legge en plan for hvordan kunden skal få gjennomgått vilkårene for å sikre at kunden forstår ansvar og risiko, får sjekket at tjenesten er compliant med eventuelle lovkrav, får identifisert evt. andre «showstoppere» og vilkår man bør prøve å forhandle på. Det vil imidlertid ofte være svært vanskelig å få endret slike standard tjenestevilkår såfremt man ikke har veldig stor innkjøpsmakt, spesielt fordi skyleverandørene baserer seg på å levere standardtjenester og har ikke bemannet opp for å forhandle med hver kunde. Som minimum bør kunden imidlertid vurder å lage en evalueringsmodell som er egnet til å vurdere «godheten» i slike tjenestevilkår. Det er for eksempel forskjell på «godheten» i vilkår som sier at skyleverandør uten forutgående varsel kan suspendere skytjenesten ved ethvert forhold som skyleverandøren vurderer som mislighold, vs. vilkår som sier at suspensjon krever «vesentlig mislighold» og forutgående skriftlig varsel med 30 dagers frist til å utbedre.
Dersom vilkårene for en skytjeneste er svært ubalanserte sammenlignet med en av de konkurrerende løsningene, så bør kanskje de mest balanserte vilkårene komme bedre ut av konkurransen gjennom evalueringen? Om mange kunder gjør det slik, kan det også få den bieffekt at det gjennom kollektiv innsats over tid oppnås en bedre kontraktbalanse.
Kundene bør også være forsiktig med å kreve at integrator skal ta risikoen for feil i SaaS-tjenester, slik for eksempel både SSA-L gjør ifbm godkjenningsprøven (se pkt. 2.2) og Dataforeningens skytjenesteavtale i pkt. 2.2.2. En integrator har ingen tilgang til eller kontroll over kildekoden i SaaS-tjenester fra tredjeparter, og kan derfor normalt ikke akseptere et slikt ansvar uten å love mer enn man kan holde.
Noen vil kanskje tenke at dersom ikke integrator har ansvar for feil i SaaS-tjenesten som tilbys implementert, så får det ingen konsekvens å tilby dårlige produkter. Fra et kundeperspektiv er det viktig å sikre seg mot dette, men svaret er likevel ikke å lempe risikoen for feil over på integrator. Svaret er å gjøre kvaliteten til gjenstand for evaluering. Allerede i en prekvalifisering så kan man stille krav til erfaring med en dokumentert moden SaaS-tjeneste uten hyppige feil og mangler. I forlengelsen av dette oppstilles kvalitetskrav til den tjenesten man skal anskaffe. Slik kan man unngå for eksempel utestede og umodne løsninger.
Det er egentlig et paradoks at denne problemstillingen fortsatt er aktuell, da den fant sin løsning i for eksempel SSA-T pkt. 5.1 ved revisjonen av SSA avtalene i 2015. Dette i kjølvannet av at Difi i mange år var tilbakeholden med å anerkjenne at om man skulle lisensiere standard programvare (fra spesielt de store internasjonale programvareleverandørene) gjennom en reseller/integrator, så måtte man akseptere at tredjeparts standard lisens og vedlikeholdsvilkår vil gjelde. Likevel er ikke tilsvarende prinsipp ivaretatt fullt og helt i SSA-L som kom i fjor eller i det hele tatt i Dataforeningens skytjenesteavtale.
Dersom man som kunde ikke er villig til å hensynta slike forhold som vi har påpekt ovenfor, bør kunden være beredt på at man neppe vil få gode tilbud på public cloud løsninger, men at tilbudene vil basere seg på tradisjonelle on-premise løsninger driftet i tradisjonelle datasentre
Dersom man som kunde ikke er villig til å hensynta slike forhold som vi har påpekt ovenfor, bør kunden være beredt på at man neppe vil få gode tilbud på public cloud løsninger, men at tilbudene vil basere seg på tradisjonelle on-premise løsninger driftet i tradisjonelle datasentre. Dette vil ha merkbare konsekvenser for pris og muligheten til å få tilgang til best mulig funksjonalitet samt fleksibilitet og skalerbarhet. De store programvareleverandørene har f.eks uttalt at de prioriterer å legge ny funksjonalitet i sine SaaS løsninger fremfor å gjøre dette i sine on-premise versjoner av standardprogramvare som uansett kommer til å desupporteres i løpet av noen få år. SAP har for eksempel sagt at i 2025 så desupporteres on-premise-løsningene deres. Da er valget rimelig klart for de fleste kunder.
Offentlige kunder bør for øvrig benytte seg av muligheten til markedsdialog, og dele utkast til konkurransegrunnlag og kontrakt med interessenter før offisiell kunngjøring skjer, slik en får testet om dette treffer markedet. Dette før en som oppdragsgiver blir underlagt begrensningene i anskaffelsesregelverket mht hvilke endringer den offentlige oppdragsgiver kan gjøre i konkurransegrunnlaget etter kunngjøring.
Våre vurderinger ovenfor er først og fremst myntet på situasjoner hvor en kjøper IaaS/PaaS-tjenester eller SaaS-tjenester fra de store internasjonale leverandørene som Microsoft, Amazone, Google Cloud, SAP, Oracle, Salesforce o.l som en «turn key» gjennom en integrator / reseller. Dersom en kjøper skytjenester fra mindre leverandører så er fleksibiliteten ofte større. Samtidig så begrenser teknologien også mindre leverandørers handlingsrom, da man også som mindre skyleverandør ikke kan gå på kompromiss med det som gjør at det er en standardisert tjeneste/public cloud.
Ett annet viktig spørsmål er om det er rett å anskaffe standard skytjenester gjennom en integrator/reseller eller om man skal anskaffe skyløsningen separat fra en evt., integratortjeneste. Vi skal ikke gå dypere inn i dette her, men påpeke at det er flere gode argumenter for å anskaffe skytjenesten separat. Eksempler er at man har en bedre kontroll med selve avtalen, hva man forhandler på og dermed også leverandøren av standard skytjeneste ved en direkte anskaffelse. Videre kan det ofte være hensiktsmessig med en konkurranse på «integrator»-tjenesten etter noen år uten at man nødvendigvis vil bytte ut underliggende skytjeneste.
I tillegg til det som er påpekt ovenfor er det også mange andre forhold av juridisk karakter som man må være bevist på og lage en strategi rundt ved utarbeidelse av konkurransegrunnlag. For eksempel kan det være vanskelig å få en fastpris i hele avtaleperioden (i for eksempel 8 år), evt. med en KPI justering, om man skal anskaffe IaaS/PaaS-tjenester. Denne type prissikring gis som utgangspunkt ikke av IaaS/PaaS-leverandørene. En kunde skal ha rimelig store volum-bindinger før skyleverandørene er villige til å binde prisen endog i ett år eller to e.l. Dette innebærer at kundene bør tenke nøye gjennom hvordan pris og prismodell evalueres. Men slike andre utfordringer får vi vurdere å dekke i en senere artikkel.
