KOFA 2021/1666: API-fordel og likebehandling i veilyskonkurranse

Saken gjelder: Feil i/uklart konkurransegrunnlag Innklagede gjennomførte en åpen anbudskonkurranse for anskaffelse av nytt toppsystem til kommunens gate- og veilysanlegg. Klagers anførsel om at manglende informasjon i konkurransegrunnlaget ga valgte leverandør en urimelig konkurransefordel, førte ikke frem. Heller ikke klagers øvrige anførsler førte frem. Klagenemndas avgjørelse 16. februar 2022 i sak 2021/1666 Klager: Datek Light Control AS Innklaget: Oslo kommune Klagenemndas medlemmer: Kjersti Holum Karlstrøm, Arnt Skjefstad og Elisabeth Wiik

Bakgrunn

(1)Oslo kommune ved bymiljøetaten (heretter innklagede) kunngjorde 14. juni 2021 en åpen anbudskonkurranse for anskaffelse av toppsystem (styringssystem) for kommunens gateog veilyssystem. Anskaffelsens verdi var ikke estimert. Tilbudsfrist var 9. august 2021.

(2)Innklagedes gate- og veilyssystem består av programvare i backend og frontend. Backend er den bakenforliggende programvaren der prosessene i veilysanlegget gjennomføres, mens frontend er den delen av systemet som ligger nærmest brukeren. Programvaren i frontend og backend kommuniserer med hverandre gjennom APIer (Application Programming Interface), en type grensesnitt mellom programvarene.

(3)Toppsystemet som skulle anskaffes, er frontend i veilysstyringssystemet. Ifølge kravspesifikasjonen punkt 1 «Avtalens omfang» var anskaffelsen av nytt toppsystem et ledd i den samlede fornyelsen av gate- og veilysstyringen i kommunen. Det var videre opplyst i punkt 2.1 «Bakgrunn» at backend til og med API mot frontend var ivaretatt av en annen kontrakt.

(4)Kravspesifikasjonen punkt 2.2 inneholdt opplysninger om «Dagens veilys i Oslo kommune»: «Teknisk informasjon Oslo kommune anleggsdatabase, Arcgis, for blant annet veilys inneholder rundt 75.000 belysningsarmaturer av forskjellig art samt ca. 900 fordelingskap. Av disse er rundt 60.000 armaturer definert som del av veilysanlegget og ca. 800 VTP, og del av den aktuelle API for tilknytning til toppsystem i denne omgang. Armaturer Postadresse Besøksadresse

Sentrum 5015 Bergen www.klagenemndssekretariatet.no

Armaturer som blir anskaffet i Oslo kommune skal som hovedregel kunne kommunisere mot tennskapet via Echelon PowerLine LonTalk protokoll. I de aller fleste tilfeller er dette løst med en integrert Outdoor Lighting Controller (OLC) i hver armatur som oversetter PLC bæreren til DALI videre mot driver i armaturet. Tennskap Tennskap for veilys (VTP) er utstyrt med LonTalk kompatibel server/PLS, hovedsakelig en tilpasset Echelon iLon smartserver. Denne fasiliterer kommunikasjonen mot armaturer. Hvert tennskap har også originalt et modem, som nå gjennom en pågående kontrakt byttes ut med en 4g kompatibel router løsning for kommunikasjon «opp i skyen». Kommunikasjon mot MDA All mobil kommunikasjon med VTP er definert og styrt i en MDA løsning, hvor autentisering og sikkerhet i kommunikasjonsløsningen er ivaretatt. Detaljer redegjøres ikke for her, men vil være del av orientering og underlag som blir gjort tilgjengelig for valgt leverandør. API Beskrivelse av IoT labs veilys API vil være del av orientering og underlag som blir gjort tilgjengelig for valgt leverandør. Leverandør kan basere seg på at det vil være en tilgjengelig definert API mot bakenforliggende veilysstyring gjennom hele driftsperioden for toppsystemet.»

(5)I punkt 2.3 «Topologi» var det inntatt en illustrasjon av hvordan henholdsvis eksisterende veilysanlegg og park- og idrettsbelysningsanlegg var bygget opp, og forholdet mellom disse eksisterende systemene og det nye toppsystemet.

(6)Om toppsystemet som skulle anskaffes fremgikk følgende: «Ny frontend/toppsystem Anskaffelse av nytt toppsystem for styring av utendørsbelysning i Oslo. Ved utnyttelse av definerte API mot dagens anlegg og fleksibilitet for oppsett av fremtidige APIer mot andre systemer ønskes det en felles webgrensesnitt for styring og overvåkning av alle utendørs belysningsanlegg i Oslo kommune.»

(7)Om backend i «Dagens veilysanlegg» fremgikk følgende beskrivelse: «Backend- lisensbelagt mot IoT iLon er hjernen i veilysstyringen. Alt oppsett er lagret her, lokalt så den fungerer «standalone» men også definering av oppsett av sync med database. Dette er en utgått komponent som nå også er utgått lagerført reservedel fra leverandør. Streetlight database er kjernen i backend systemet som leveres av veilysanlegget. Her er sync mot arcgis definert og sync mot alle VTP’er er satt opp. Dette er en lisensbelagt tjeneste i backend.

LonTalk PLC (over kraftkabelen uten ekstra styreledninger) kommuniserer med armaturene, LonTalk PLC oversettes til DALI i kommunikasjonsnode i armatur. Oppsett av denne com settes opp i iLon lisensperarmatur.»

(8)Om backend i «Dagens park- og idrettsbelyning» fremgikk følgende: «Backend – lisensbelagt mot Datek Ny frontend forutsettes fleksibelt for integrasjon av andre API, slik at for eksempel overvåkning av vei-, park-, og idrettsbelysning kan foregå i samme webgrensesnitt. Tjeneste i dag levert av Datek, som et totalt produkt inkludert webgrensesnitt»

(9)I punkt 2.4 «Premisser/tilknytninger eksisterende systemer» fremgikk følgende: «Arcgis Arcgis er kommunens felles GIS-objektdatabase. Alle anleggsdata registreres og vedlikeholdes i denne, og hentes/speiles til andre systemer ved behov. Integrering mot denne databasen vil være viktig, omfanget av lese/skrive behov mot database vil være gjenstand for diskusjon i prosjektet. Som utgangspunkt er det kun lesemulighet som er benyttet i dagens system. Det vil gjøres tilgjengelig standardisert API for valgt leverandør. Backbone veilys Se beskrivelser over. Andre systemer Som primærfunksjon og tilknytning er det Oslo kommune veilysstyresystem og objektdatabase for veilysstyring som skal integreres og tilpasses. Dette skal gjøres ved hjelp av definert API beskrevet annet sted. I tillegg skal toppsystem være fleksibelt for utvidelse mot andre API for visning av data/sanntidsdata fra andre systemer. Eventuelt omfang av dette er ikke definert, men de mest aktuelle systemer vil være API for park og idrettsbelysning (både lese og skrive), trafikklys (kun lese) mv.»

(10)I punkt 2.5 «Krav til nytt toppsystem - kravtabell» var det oppstilt en kravtabell som inneholdt en beskrivelse av innklagedes minimums- og evalueringskrav til leveransen. Innledningsvis presiserte innklagede følgende: «Tabellen nedenfor inneholder en beskrivelse av Kundens minimums- og evalueringskrav til leveransen. Det gjøres oppmerksom på at tilbydernes løsningsforslag (Utfyllende svar) skal ivareta dagens løsninger og grensesnitt nevnt over, i tillegg til at tabellen svares ut.»

(11)Kravtabellen var delt opp i syv deler: «A: Funksjonskrav for styring og overvåkning», «B. Funksjonskrav for webgrensesnitt», «C. Datasikkerhet», «D. Åpenhet og interoperabilitet», «E. Planlegging og samarbeid», «F. Fremdrift og levering/overtakelse» og «G. Overlevering, dokumentasjon og opplæring».

(12)I del A var det stilt to minstekrav, der det ble beskrevet flere egenskaper leverandørene måtte tilby, med fokus på fleksibilitet og muligheter det tilbudte systemet måtte ha for flere løsninger.

(13)I del B ble det først stilt to minstekrav knyttet til standardvisning av logge- og lagringsfunksjonalitet, og mulighet for å definere logging i webgrensesnitt. Deretter fulgte følgende evalueringskrav i punkt B.3: «Det skal beskrives annen funksjonalitet for webgrensesnittet. Omfang av funksjonalitet er å anse som en del av leverandørens løsning som skal beskrives i dette tilbudet, og detaljeres i en første kartleggingsfase i prosjektet. Det forventes at leverandører kjent med drift av toppsystem for veilys og kjenner og kan vurdere nødvendighet for funksjonalitet i en slik løsning og vil være en aktiv part i prosjektets fastsettelse av funksjonalitet.»

(14)I punkt D.1 var det stilt følgende evalueringskrav: «Det er viktig for oppdragsgiver at tilbudte løsninger står for en åpenhet og interoperabilitet mot andre systemer, og dette er en viktig del av kvalitetskriteriene. Leverandørene skal gi en grundig beskrivelse av fleksibilitet for utvidelser, samt åpenhet for datautveksling og eventuell integrering mot andre systemer.»

(15)I del F «Fremdrift og levering/overtakelse» var det stilt tre evalueringskrav: «F.1. Dialog og kartlegging. Prosjektet vil starte med en prosess for dialog og kartlegging. Dette er en prosess som forutsettes administrert av leverandør i forhold til planlegging og innkalling til nødvendige arbeidsmøter. Antatt fremdrift er satt til 1 måned. F.2. Utvikling av løsning/software Etter en ferdigstillelse av «dialog og kartlegging» er det forutsatt en definert fremdrift for utvikling av software for å tilfredsstille de satte krav. Om leverandør benytter denne perioden for en «on-air» stegvis utvikling av toppsystem med en brukermedvirkning slik at steg 3 «testperiode» blir en integrert del eller om disse er helt atskilt er opp til leverandør å beskrive. Leverandørens plan om dette skal komme klart frem av løsningsbeskrivelse. Det er forventet at en slik utviklingsperiode ikke vesentlig overskrider 3 måneder. F.3 Testperiode Ved ferdigstillelse av system for igangsettelse, forventes det en periode med prøvedrift med full funksjonalitet i 3 måneder. Det vil her kunne forekomme innspill om ønskede endringer i funksjonalitet før aksept av endelig overlevert system. Om leverandør ønsker dette oppdelt i forskjellige faser med tilbakemelding og rekonfigurasjon av løsning er opp til leverandør å beskrive i sin løsningsbeskrivelse.»

(16)Det fremgikk av konkurransegrunnlaget at innklagede ville velge tilbudet med det beste forholdet mellom pris og kvalitet, basert på tildelingskriteriene «Pris» (vektet 40 prosent) og «Kvalitet» (vektet 60 prosent).

(17)Priskriteriet skulle evalueres på bakgrunn av fire priselementer, «Utvikling av løsning/software», «Testperiode», «Overlevering, dokumentasjon og opplæring» og «Lisenser». De tre første priselementene skulle oppgis som fastpris.

(18)I prisskjemaet var det presisert følgende om prisposten «Utvikling av løsning/software»: «Merk: Prisposten «Utvikling av løsning/software» skal også inkludere dialog, kartlegging og annet som kreves for å få på plass løsningen».

(19)Priselementet «Lisenser» var delt opp i «Lisenskostnader» og «Timepriser for drift og støtte». Timeprisene for drift og støtte skulle volumjusteres ut fra en antatt bruk på 800 timer i kontraktsperioden. Lisenskostnadene skulle angis som en fastpris for lisens og drift av 30 000 armaturer per år for årene 2022, 2023, 2024 og 2025. I tillegg skulle det gis et påslag for innføring av til sammen 10 000 armaturer. Om drifts- og lisenskostnader for 2021 ble det presisert følgende: «Merk: Kostnader knyttet til eventuell lisens og drift i 2021 skal inkluderes i prisen for «Utvikling av løsning/software» i fanen «Priser».»

(20)Tildelingskriteriet «Kvalitet» ville bli evaluert på bakgrunn av underkriteriene «Kompetanse», «Kapasitet og organisering» og «Oppdragsforståelse og løsningsbeskrivelse». Underkriteriet «Oppdragsforståelse og løsningsbeskrivelse» var inndelt i samme underpunkter som kravspesifikasjonen.

(21)Innen tilbudsfristen kom det inn flere spørsmål til anskaffelsen. Under emnet «Eksisterende arkitektur og viderebygging av eksisterende anlegg» ble det stilt følgende spørsmål: 1.) Dere overtok i 2008 lysanlegget ifra Hafslund Nett, ønsker dere å bygge videre på denne plattformen? 2.) Hvis nei på pkt.1 hva er grensesnittet / arkitekturen tilgjengelig for toppsystemet? 3.) Savner generelt teknisk informasjon om anlegget som det skal koples opp imot, kan den eksisterende dokumentasjonen deles? 4.) Hvilke andre grensesnitt utover lys vil toppsystemet kommunisere med? 5.) Hva er antallet «tags» forventer toppsystemet vil ha?

(22)Innklagede ga følgende svar: «Svar på spørsmål 1): Det stemmer, BYM tok over anleggene fra Hafslund i 2008. Det er ikke snakk om å bygge videre på den plattformen i den anskaffelsen vi har ute nå, det er kun snakk om tilknytning via API til systemet som allerede ligger der. Det som ligger tilgjengelig er en tilknytning til API via back-bone som vil bli tilgjengelig til valgt leverandør. Svar på spørsmål 2): Det skal ikke endres noe, det skal tilknyttes via definert API (Arcgis). Svar på spørsmål 3): Nei (Ref. tidligere kommentarer om Arcgis). Svar på spørsmål 4):

Vi skal ha mulige, fortrinnsvis leserettigheter, til systemer for å vise i front-end, men dette er ikke noe vi ser for oss at skal skreddersys i første omgang. Dette kommer i en driftsfase (og er noe av bakgrunnen for at vi spør om timepriser). Mest åpenbare aktuelle systemer er etatens trafikklys og idrettsbelysning. Svar på spørsmål 5): BYM ønsker ikke å gå i detalj på antall tags. Vi forventer at leverandørene legger sine forutsetninger for hvor komplekst dette skal være, og bruker det som en forutsetning i sitt tilbud.»

(23)En leverandør stilte spørsmål om «I hvilken grad settes det krav til sanntidslogging og fremvisning?», der innklagede svarte: «Det er et viktig element i toppsystemet at vi har tilgang til å hente ut loggrapporter, men alt dette vil foregå i back-bone, og det vil være uthenting av informasjon der. Vi forventer ikke en detaljering av dette i tilbudsfasen. Vi forventer at leverandørene tar antagelser i sine tilbud.»

(24)Videre skrev en leverandør at «Det er ingen spesifikasjoner for tekniske krav i konkurransegrunnlaget, når vil dette være tilgjengelig?

(25)Innklagede svarte: «Det stemmer – vi vil heller åpne for det som blir løsningsbeskrevet fra leverandøren».

(26)En leverandør spurte videre: «Hvilke andra datakilder og systemer (i henhold til A2 og D1 i SSA-L vedlegg 1 kundespecifikasjon) skal top systemet vaere kompatibelt med?»

(27)På dette spørsmålet svarte innklagede: «Svar på spørsmål 2: Integrasjon mot andre systemer som omtalt i SSA-L Bilag 1 punkt A2 og D1 er ikke konkrete systemer som skal integreres ved oppstart av systemet, men et krav/ønske om toppsystemets åpenhet og interoperabilitet for en slik integrasjon i fremtiden (driftfase). Det er derfor viktig for BYM sin forståelse av tilbudt løsning at tilbudt systems muligheter for dette omtales og beskrives for å svare ut disse punktene.»

(28)Den 29. juni avholdt kommunen tilbudskonferanse, der et av temaene var kravspesifikasjonen.

(29)Det fremgår av referatet at innklagede her redegjorde for at man ikke ville dele detaljert oversikt over API i eksisterende backend i konkurransen, men at APIet ville gjøres tilgjengelig for valgt leverandør. Videre fremgikk det: «Det presiseres at vi har laget en åpen kravspesifikasjon. Det er ikke satt tekniske krav, og vi har i utgangspunktet ikke tenkt til å legge noen restriksjoner på hva leverandørene kan tilby. Vi ønsker leverandørene sine beste løsninger til å løse oppgaven. Vi ønsker en leverandør som har kompetanse og erfaring med denne type styring. Det presiseres at vi ønsker en løsningsbeskrivelse der leverandører kommer med sine meninger om hva systemet bør inneholde. Når vi har tildelt kontrakt vil vi gå videre med mer detaljer, samt videre fase hvor initiell programmering og utarbeidelsesfasen blir diskutert og der man kommer til enighet med BYM.

- Dette er en kontrakt for front-end systemet – ikke komponenter som skal ut i felt, og det skal ikke gjøres om på styresystemet som Oslo Kommune har ute i felt i dag. Det presiseres at det ikke forventes at leverandørene skal gå helt i materien og skreddersy kommunikasjon med det som alt er ute, men skal tilpasses back-bone som er der i dag. - Det vil tilgjengeliggjøres API mot backbone til valgt leverandør. Kompleksiteten vil være opp til hvordan leverandøren tilbyr at den skal være. - Det presiseres videre at den andre konkrete sammenknytning om kan være aktuell er BYMs anleggsdatabase. Alle objekter som BYM drifter ligger her. Backbone speiler nødvendig data fra Arcgis og det antas at det er samme løsningen for frontend. Det foreligger en ferdig definert API som vil tilgjengeliggjøres for valgt leverandør. (…)»

(30)Innen tilbudsfristen mottok innklagede tilbud fra fem leverandører, herunder Datek Light Control AS (heretter klager). I tildelingsbrev av 1. september 2021 orienterte innklagede om at IoT Labs AS (heretter valgte leverandør) hadde levert det beste tilbudet.

(31)På tildelingskriteriet «Kvalitet» fikk klager ti poeng på underkriteriene «Kompetanse» og «Kapasitet og organisering», og 7,44 poeng på «Oppdragsforståelse og løsningsbeskrivelse». Klager hadde høyeste score på alle underkriteriene.

(32)Det avgjørende for konkurransen var at valgte leverandør med en tilbudspris på 1 399 000 kroner oppnådde ti poeng på tildelingskriteriet «Pris», mens klager med en pris på 4 290 000 kroner fikk 1,43 poeng. Innklagede opplyste i meddelelsesbrevet at det var størst sprik i postene som gjaldt utvikling av løsning/software og lisenskostnader. Valgte leverandør oppnådde en totalsum på 8,30 vektede poeng, og klager ble nummer to i konkurransen med 6,57 vektede poeng.

(33)Den 10. september 2021 oversendte klager en klage på tildelingen. I brev 30. september 2021 opprettholdt innklagede tildelingsbeslutningen.

(34)Klagen ble brakt inn for Klagenemnda for offentlige anskaffelser 5. oktober 2021.

(35)Kontrakt ble inngått med valgte leverandør 20. oktober 2021.

(36)Nemndsmøte i saken ble avholdt 7. februar 2022.

Anførsler

Klager har i det vesentlige anført

(37)Klager anfører at valgte leverandør i egenskap av å være eksisterende leverandør av backend av veilysstyringssystem, har hatt en urettmessig konkurransefordel som innklagede hadde plikt til å utjevne.

(38)Konkurransegrunnlaget kan ikke forstås på annen måte enn at toppsystemet måtte tilpasses eksisterende backendløsning, herunder APIer. Valgte leverandørs detaljkunnskap om systemene og gjeldende API har muliggjort en spisset løsning inn mot eksisterende system, som antakelig har fått uttelling på kvalitetskriteriet. Den manglende informasjonen om API i backend har uansett hatt betydning for prisingen av tilbudene. Uten tilgang til slik informasjon, har klager måttet gjøre en rekke antakelser om systemet i backend, og tilbudsprisen reflekterer denne usikkerheten. Innklagede kunne enkelt ha

utlignet konkurransefordelen ved å gi leverandørene informasjon om gjeldende APIer eller oversikt over datastrukturen i backend med tilhørende parametere. Når dette ikke er gjort, utgjør det et brudd på de grunnleggende prinsippene i loven § 4.

(39)Det er heller ikke riktig at innklagede har avhjulpet konkurransefordelen ved at utvikling og integrering av tilbudt løsning mot den eksisterende backend-delen av veilysstyringen skulle faktureres som regningsarbeider. Dette kan ikke leses ut av konkurransegrunnlaget, og en naturlig forståelse av prisskjemaet tilsier tvert imot at dette skulle prises som fastpris i posten «Utvikling av løsning/software».

(40)Valgte leverandørs langvarige konsulent- og leverandørrolle overfor kommunen innebærer uansett at valgte leverandør for alle praktiske formål må anses likestilt med å ha deltatt i forberedelse av konkurransen. Dette har medført en konkurransevridning som ikke avhjelpes, og valgte leverandør skulle derfor vært avvist, jf. FOA § 24-1(1)(d).

(41)Valgte leverandør skulle uansett vært avvist som følge av at det ikke var levert forpliktelseserklæring for to underleverandører som valgte leverandør støttet seg på for å oppfylle kvalifikasjonskravene.

(42)Innklagede har heller ikke gitt en tilstrekkelig begrunnelse for tildelingen, ved at det ikke er redegjort for de relative forskjellene mellom tilbudene under underkriteriet «Oppdragsforståelse». Siden avstanden i poengscore mellom tilbudene er relevant for utfallet av konkurransen, innebærer dette et brudd på regelverket.

(43)Innklagede har videre blandet sammen evalueringen av tildelingskriteriene «Pris» og «Kvalitet», da de i tildelingsbrevet til valgte leverandør har henvist til den tilbudte prisen ved evalueringen av kvalitetskriteriet.

Innklagede har i det vesentlige anført

(44)Innklagede bestrider at valgte leverandør har hatt en konkurransefordel.

(45)Det bestrides at konkurransegrunnlaget skal forstås slik at toppsystemet skulle tilpasses eksisterende backend-løsning. Det gir ikke mening å skulle anskaffe et nytt system som skal være teknisk begrenset av en backend-løsning som nærmer seg slutten av forventet levetid. Leverandørene var isteden bedt om å levere en løsning som forutsatte et API i backend med alle de elementene som leverandørene selv mente var nødvendige for et optimalt styresystem for veilys. Konkurransedokumentene plasserte dermed risikoen for at ikke alle funksjonene i toppsystemet ville kunne realiseres på grunn av begrensninger i de bakenforliggende systemene på innklagede. Kunnskap om gjeldende API i backend var derfor ikke en konkurransefordel for valgte leverandør. Det forelå følgelig ikke brudd på likebehandlingsprinsippet i lovens § 4, eller på forskriften § 24-2 (1) bokstav d.

(46)Innklagede erkjenner at integrasjon mot eksisterende systemer via API er en viktig del av leveransen. Kunnskap om eksisterende API innebar imidlertid ikke en fordel i konkurransen, da tilknytning via API skulle leveres basert på timepris tilbudt i konkurransen.

(47)Innklagede bestrider videre at valgte leverandørs manglende levering av forpliktelseserklæringer skulle medført avvisning eller poengtrekk. Valgte leverandør oppfylte selv kvalifikasjonskravene, og trengte derfor ikke å levere forpliktelseserklæring.

(48)Innklagede bestrider også at begrunnelsen ikke tilfredsstiller forskriften § 25-1. Det utslagsgivende for valg av leverandør var pris, noe som fremgår klart av begrunnelsen. Begrunnelsesplikten medfører ikke noe krav om en full sammenligning mellom samtlige tilbud.

(49)Innklagede bestrider videre at det er gjort en sammenblanding av tildelingskriteriene ved evalueringen. Det vises til evalueringsmatrisen hvor det fremgår klart at hvert underkriterium er evaluert hver for seg.

Klagenemndas vurdering

(50)Klager har deltatt i konkurransen, og har saklig klageinteresse, jf. forskrift om klagenemnd for offentlige anskaffelser § 6. Klagen er rettidig. Konkurransen gjelder anskaffelse av styringssystem for gate- og veilys, som er en tjenesteanskaffelse. I tillegg til lov om offentlige anskaffelser 17. juni 2016 nr. 73 følger anskaffelsen forskrift om offentlige anskaffelser 12. august 2016 nr. 974 del I og III, jf. forskriften §§ 5-1 og 5-3. Mangelfullt konkurransegrunnlag

(51)Spørsmålet for klagenemnda er om konkurransegrunnlaget er utformet i strid med de generelle prinsippene om likebehandling og forutberegnelighet i loven § 4, ved at det ikke er inntatt opplysninger om eksisterende API i backend.

(52)Kravene til likebehandling og etterprøvbarhet i loven § 4 innebærer at konkurransegrunnlaget må utformes slik at det for en alminnelig aktsom tilbyder fremstår som klart hva det skal inngis tilbud på og hvordan dette skal gjøres, og at det må inneholde tilstrekkelige opplysninger til at tilbyderne har et forsvarlig grunnlag for å inngi tilbud. Se blant annet EU-domstolens sak C-19/00 (SIAC Construction) og klagenemndas avgjørelse i sak 2020/64 avsnitt (31).

(53)Anskaffelsen gjaldt levering og drift av toppsystem for veilysstyring for en periode på fire år. Toppsystemet skulle som en del av utviklingsfasen integreres mot eksisterende backend og kommunens anleggsdatabase (ArcGIS), mens eventuell integrasjon mot annen programvare var forutsatt håndtert i driftsfasen.

(54)Det er ikke bestridt at funksjonaliteten i toppsystemet avhenger av hvilke muligheter som ligger i de bakenforliggende løsningene, herunder hvilke APIer som benyttes i disse. APIet i backend vil dermed påvirke hvilken funksjonalitet som kan nyttiggjøres i toppsystemet.

(55)Hvorvidt informasjon om APIene var nødvendig for å utarbeide et konkurransedyktig tilbud, avhenger imidlertid av om tilbudt toppsystem skulle være tilpasset grensesnittet i de bakenforliggende systemene, eller om toppsystemet skulle utvikles uavhengig av eventuelle begrensninger i backend. Dette beror på en tolkning av konkurransedokumentene.

(56)Utgangspunktet for tolkningen av konkurransegrunnlaget er hvordan det fremstår for alle rimelig opplyste og normalt påpasselige leverandører, se til sammenligning klagenemndas avgjørelse i sak 2019/731, avsnitt 39, med videre henvisning til EU-domstolens avgjørelse i sak C-42/13 Cartiera dell'Adda.

(57)Det fremgikk av konkurransegrunnlaget at anskaffelsen av toppsystemet var et ledd i den samlede fornyelsen av gate- og veilyssystemet i kommunen, hvor også de bakenforliggende systemene var på vei til å bli utdaterte. Formålet var å etablere et felles system for styring og overvåking av alle utendørsbelysningsanlegg i Oslo kommune. Det nye toppsystemet skulle som en del av anskaffelsen integreres mot eksisterende backend via API som er omfattet av et annet kontraktsforhold med valgte leverandør. Samtidig skulle systemet være fleksibelt for oppsett av fremtidige APIer mot andre systemer, herunder ny backendløsning. Selv om det ikke fremgår uttrykkelig i konkurransegrunnlaget, må det ha vært forståelig for leverandørene at toppsystemets tilbudte funksjonalitet ikke skulle være tilpasset til, eller begrenset av, de mulighetene som lå i den eksisterende programvaren i backend. At det var slik konkurransedokumentene skulle forstås ble også bekreftet i spørsmål og svarrunden, der innklagede presiserte at leverandørene ikke skulle bygge videre på den eksisterende plattformen i veilysanlegget. I den grad eksisterende løsning i backend begrenset muligheten til å utnytte funksjonaliteten i det nye systemet i driftsfasen, plasserte konkurransegrunnlaget etter nemndas syn risikoen for dette hos innklagede.

(58)Slik konkurransen er lagt opp, er det dermed i utgangspunktet ikke nødvendig med kjennskap til innholdet i bakenforliggende system for å tilby et toppsystem som svarer til innklagedes behov slik de er beskrevet i konkurransedokumentene. Dette underbygges også av at klagers tilbudte løsning scoret best på samtlige kvalitetsparametre.

(59)Som nevnt omfattet imidlertid anskaffelsen også integrering av det nye toppsystemet mot gjeldende systemer. Klager har i den forbindelse anført at kjennskap til eksisterende API i backend og mot ArcGIS ga valgte leverandør en urimelig konkurransefordel ved prisingen av tilbudet. Det er vist til at manglende kjennskap til innholdet i disse APIene gjør det vanskelig å estimere integrasjonsarbeidets omfang og kompleksitet, og at risikoen for dette måtte kalkuleres inn i avtalens fastpriselementer.

(60)Innklagede har på sin side anført at arbeidet med å integrere toppsystemet mot bakenforliggende systemer ikke inngikk i anskaffelsens fastpriselement, men skulle faktureres etter medgåtte timer som «Drift og støtte». Risikoen knyttet til integreringsarbeidets omfang og kompleksitet lå dermed hos innklagede, ikke hos leverandørene.

(61)Slik prisskjemaet er bygget opp, skilles det mellom fasen frem til og med overlevering av systemet, som skal prises som fastpris, og driftsfasen, som skulle prises med fastpris for lisenser og timepris for drift og støtte. Klagenemnda kan ikke se at det for en normalt påpasselig tilbyder var forståelig at fastpriselementet ikke skulle omfatte integrering mot eksisterende backend, som nødvendigvis ville måtte skje i implementeringsfasen. Dette underbygges ytterligere av at prisskjemaet hadde en merknad om at fastpriselementet «Utvikling av løsning/software» også skulle inkludere dialog, kartlegging og annet forarbeid som kreves for å få på plass løsningen. Leverandørene måtte dermed legge til grunn at fastprisen inkluderte integrering mot eksisterende backend og ArcGIS.

(62)At valgte leverandør hadde informasjon om de relevante APIene i egenskap av å være eksisterende leverandør av backend, utgjør dermed en konkurransefordel ved prisingen av posten «Utvikling av løsning/software».

(63)Oppdragsgiver kan i visse tilfeller ha en aktivitetsplikt for å redusere og eventuelt utjevne en konkurransefordel som en tilbyder har i kraft av å være eksisterende leverandør, se for

eksempel Eidsivating lagmannsretts dom i sak LE-2015-149169. Denne aktivitetsplikten er utledet av de grunnleggende prinsippene om konkurranse og likebehandling. Om og i hvilken utstrekning oppdragsgiver har plikt til å redusere et konkurransefortrinn, beror på en konkret vurdering. Relevante momenter i denne vurderingen er blant annet hvor enkelt og rimelig det er å redusere konkurransefortrinnet, og om en reduksjon innebærer en tilsidesettelse av eksisterende leverandørs rettigheter, se for eksempel EU-domstolens avgjørelse i sak T-345/03 (Evropaïki Dynamiki), avsnitt 76. Oppdragsgiver plikter imidlertid ikke å utjevne enhver forskjell.

(64)Klager har anført at de store prisforskjellene mellom tilbudene i seg selv tilsier at valgte leverandør hadde en fordel som innklagede hadde plikt til å utjevne, og at klager med mer informasjon om løsningen i backend kunne ha levert en billigere løsning spisset inn mot disse systemene.

(65)Slik klagenemnda ser det, ville det vært enkelt for innklagede å utjevne valgte leverandørs konkurransefordel ved å inkludere ytterligere informasjon om APIene. Samtidig har innklagede forklart at man bevisst valgte å ikke gi slik informasjon, nettopp fordi man ikke ønsket en situasjon der leverandørene forsøkte å tilpasse løsningen til eksisterende system. Dette fordi man anså eksisterende løsning som konkurransehemmende og utdatert.

(66)Slik saken er opplyst for klagenemnda, er det ikke holdepunkter for at kostnadene knyttet til selve integrasjonen mot de bakenforliggende systemene er bakgrunnen for den store prisforskjellen mellom tilbudene. Integrasjonskostnadene utgjør bare en del av prisposten «Utvikling av løsning/software», og klager har ikke klart å synliggjøre at den risikoen man måtte kalkulere inn i fastprisen er høyere enn det man som ny leverandør må regne med av integrasjonskostnader. Toppsystemet skulle for øvrig være fleksibelt for utvidelse mot andre APIer, og de to APIene toppsystemet skulle integreres mot som en del av fastprisen, er etter det opplyste standardiserte.

(67)Slik klagenemnda ser det, synes prisforskjellene i tilbudene i hovedsak å være en konsekvens av at klager har levert et system med mer funksjonalitet til en høyere pris, mens valgte leverandør har levert en løsning som i liten grad har funksjonalitet utover minstekravene i konkurransen. Innklagede har dermed lagt opp konkurransen på en måte som ikke gjenspeiler det uttalte formålet om å anskaffe et toppsystem med funksjonalitet utover det som er mulig i dagens løsning. Basert på minstekravene i konkurransen og tildelingskriterienes relative vekt, må det likevel ha fremstått klart for leverandørene at det bare ville lønne seg å tilby økt funksjonalitet i den grad kvaliteten kunne veie opp for de prismessige fordelene ved å tilby en minimumsløsning. I lys av dette kan ikke klagenemnda se at valgte leverandørs kjennskap til APIene utgjorde en konkurransefordel som innklagede hadde plikt til å utjevne.

(68)Klagenemnda har etter dette kommet til at det ikke var i strid med regelverket at konkurransegrunnlaget ikke inneholdt opplysninger om eksisterende API i backend.

(69)Klagenemnda bemerker i tillegg at det ikke er anført konkrete forhold knyttet til rådgivning eller ved utforming av konkurransedokumentene som tilsier at valgte leverandørs rolle som eksisterende leverandør av backend kan likestilles med at de har deltatt ved forberedelsen av konkurransen, jf. forskriften § 24-2 bokstav d. Tilbudsevalueringen

(70)Klager anfører for det første at innklagedes tilbudsevaluering av underkriteriet «Oppdragsforståelse» ikke viser til de relative forskjellene mellom tilbudene, og således er i strid med forskriften § 25-1 (2).

(71)Etter forskriften § 25-1 (2) skal begrunnelsen inneholde navnet på den valgte leverandøren og en redegjørelse for det valgte tilbudets egenskaper og relative fordeler i samsvar med tildelingskriteriene. Begrunnelsen skal gjøre det mulig for leverandørene å etterprøve om tildelingen er i samsvar med tildelingskriteriene og om den ellers er i samsvar med regelverket om offentlige anskaffelser.

(72)Innklagede har sendt et eget meddelelsesbrev til klager. Brevet viser til den underliggende evalueringsmatrisen med poenggiving for hvert kriterium og underkriterium. I tillegg følger en redegjørelse for evalueringen av tilbudet opp mot de andre tilbudene, der det sentrale momentet er at valgte leverandør har klart lavest pris. Etter klagenemndas syn gir begrunnelsen uttrykk for de svake og sterke sidene ved tilbudet, og redegjør for relevante forskjeller mellom tilbudene. Redegjørelsen er i tråd med lovens § 25-1 (2).

(73)For det annet anfører klager at innklagede har blandet sammen pris- og kvalitetskriteriet, da de i tildelingsbrevet til valgte leverandør har vist til oppfyllelsen av kravspesifikasjonen i redegjørelsen for evalueringen av priskriteriet.

(74)Anførselen kan klart ikke føre frem. Tildelingsbrevet viser til evalueringsmatrisen med score for hvert underkriterium, og det er gitt en nærmere redegjørelse for hvert punkt. Henvisningen til kravspesifikasjonen under priskriteriet kan ikke forstås som annet enn en bekreftelse på at valgte leverandørs lave pris sammenlignet med konkurrentenes ikke har innebåret at innklagede har sett bort fra kravene i kravspesifikasjonen. Manglende forpliktelseserklæring

(75)Klager har anført at innklagede ikke har levert forpliktelseserklæringer for to underleverandører som valgte leverandør støttet seg på for å oppfylle kvalifikasjonskravene. Innklagede har forklart at de vurderte det slik at valgte leverandør basert på den innleverte dokumentasjonen oppfylte kvalifikasjonskravene uten bruk av underleverandørene og at forpliktelseserklæringene ikke var nødvendige. Klagenemnda har ingen rettslig innvendinger mot denne fremgangsmåten.

Konklusjon

Oslo kommune har ikke brutt regelverket for offentlige anskaffelser.

For Klagenemnda for offentlige anskaffelser, Kjersti Holum Karlstrøm