Reading List System

Sikt (på vegne av biblioteks- og forskningsinstitusjoner i Norge) skal kjøpe et skybasert leseliste-system (SaaS) for et konsortium på 28 institusjoner. Systemet skal være i full drift hos andre ved oppstart, ha forventet levetid minst 10 år, støtte API- og eventbasert integrasjon, sentral bulk-konfigurasjon, DEIA, og håndtere flere medietyper. Løsningen må også støtte generativ/AI-funksjonalitet (med krav om etisk/transparent bruk og mulighet for å slå av) samt klima- og miljøkrav for underliggende datasenterinfrastruktur. Kontrakten inngås som SSA-L (internettbaserte løpende tjenester) med SLA- og implementerings-/deploy-appendiks, først 5 år, deretter rullerende oppsigelse.

• Leverandøren må være lovlig registrert i Norge (norskregistrert virksomhet) OR registrert i foretaks-/handelsregister i etableringslandet.

  Dokumentasjon: Selskapsregistreringsbevis/attest. For ikke-norske leverandører: bekreftelse på registrering i relevant register i etableringslandet (kildedokumentert oppgitt som “Company registration certificate” / “Confirmation that Supplier is registered in a trade register…”).

  Kilde: 01 Tender regulations, pkt. 4 (Company registration)
• Leverandøren må ha tilstrekkelig økonomisk og finansiell kapasitet til å oppfylle kontrakten i hele kontraktsperioden.

  Dokumentasjon: Årsregnskap for de siste to årene (inkl. balanse) eller alternativ dokumentasjon ved “reasonable cause” (f.eks. morselskapsgaranti eller bankgaranti på forespørsel).

  Kilde: 01 Tender regulations, pkt. 4 (Economic and financial capacity); også ESPD omtale i pkt. 3

• ESPD selvdeklarasjon (del av kvalifiserings-/konkurranseinnsendelse) i TendSign som foreløpig bevis på oppfyllelse av kvalifikasjonskrav.Kilde: 01 Tender regulations, pkt. 4 (Qualification Requirements) og pkt. 3 (ESPD)
• Kvalifikasjonsforespørsel skal leveres elektronisk via EU Supply-portalen (EU Supply/CTM).Kilde: 01 Tender regulations, pkt. 6 (Delivery of qualification request)
• Kvalifikasjonsforespørsel skal inneholde dokumenter: (1) registreringsbekreftelse (trade register/foretaksregister), (2) dokumentasjon på finansstyrke, (3) søknadsbrev (Application letter – dokument 08), (4) ESPD- erklæring om oppfyllelse av kvalifikasjonskrav (utfylles i EU Supply), (5) erklæring om forpliktelse (Declaration of Commitment – dokument 09 per underleverandør).Kilde: 01 Tender regulations, pkt. 6 (Structure of the qualification request)
• Tilbud (for kvalifiserte og inviterte) skal leveres via EU Supply-portalen CTM: https://eu.eu-supply.com/login.asp?B=DFOKilde: 01 Tender regulations, pkt. 7 (Delivery of the tender)
• Tilbudsstruktur (innsendingsdokumenter): (1) Tender letter (dokument 10), (2) Supplier’s response to Requirement Specification (dokument 03), (3) Supplier’s completed Price Matrix (dokument 04), (4) Data Processing Agreement draft (dokument 07).Kilde: 01 Tender regulations, pkt. 7 (Structure of the tender documents)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

13.07.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Kontraktstype: SSA-L (Government Standard Contract for løpende nettbaserte tjenester) med vedlegg for implementering/deploy og service levels (SLA). Kontrakten anses akseptabel for leverandør med mindre det tas tydelige forbehold i tilbudet; Sikt kan avvise tilbud med substansielle reservasjoner.Kilde: 01 Tender regulations, pkt. Choice of contract
• Kontraktsperiode og oppsigelse: initialt 5 år. Deretter rullerende oppsigelsesstruktur: Kunden kan si opp med 12 måneders skriftlig varsel; leverandør kan si opp med 24 måneders skriftlig varsel før terminering.Kilde: 01 Tender regulations, pkt. Choice of contract
• Krav om operativt system: produktet som tilbys må være i fullskala drift hos andre institusjoner ved oppstart (tidlig adopterer i utvikling oppfyller ikke).Kilde: 01 Tender regulations, pkt. Procurement objective / 01 Tender regulations, s. 4
• Valgt leverandør må dokumentere oppfyllelse av kvalifikasjonskrav etter kontraktsinngåelse (ESPD brukes som foreløpig bevis).Kilde: 01 Tender regulations, pkt. 3 (About ESPD)

• Dokumentteksten inneholder ikke eksplisitt selve innholdslisten for alle kvalifikasjonskrav utover to punkter (selskap/registrering og økonomisk/finansiell kapasitet); andre kvalifikasjonskrav kan ligge i øvrige deler, men fremgår ikke i utdraget gitt.
• I kravspesifikasjonen er det svært mange M/D/E-krav; utdraget slutter i kapittel 20.2/20.1 og gir ikke full oversikt over alle tjeneste-/SLA-/end-of-contract-krav og alle kontraktsmessige forpliktelser.
• Vektlegging av klima- og miljø i tildelingen er beskrevet som håndtert via obligatoriske krav i kravspesifikasjonen; vekten (minst 30%) nevnes generelt i tenderreglene, men det fremgår ikke om det finnes alternative oppsett i andre dokumenter enn tenderreglene.
• Dokumentet oppgir flere datoer og at noen datoer kan endres; konkrete frister for enkelte faser er derfor “subject to change” etter første innsending.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I krav 008 står det at løsningen skal være multi-tenant med at hver institusjon har «egen adskilt instance» innenfor en multi-tenant-struktur. Kan dere presisere hvordan dere teknisk sikrer slik isolasjon (f.eks. separate databaser/skjema, container/namespace-separasjon, tilgangsstyring) og hvordan dere verifiserer at ingen data/konfigurasjon kan leses på tvers av institusjoner?

   Hvorfor det er verdt å spørre: Leverandøren må forstå faktisk isolasjonsmodell for å kunne prise og designe riktig drift, sikkerhet og revisjon/operasjonell kontroll.

   Kilde: Krav 008 (6 Operations and platform)

2. I krav 009 beskrives failover-capabilities og single points of failure (beskrivelseskrav). Hvilke tilgjengelighetsmål og gjenopprettingstider (RTO/RPO) gjelder dere for denne tjenesten, og hva er antatt løsning for failover dersom en sone/region eller komponent feiler?

   Hvorfor det er verdt å spørre: RTO/RPO påvirker kostnader og bemanning/arkitekturvalg, og er nødvendig for korrekt tilbudsprising.

   Kilde: Krav 009 (6 Operations and platform)

3. I krav 010 kreves «reliable data backup and disaster recovery plan». Kan dere bekrefte hvilke backup-/DR-kriterier oppdragsgiver forventer (f.eks. backupfrekvens, retention-periode, restore-testintervaller, og om restore skal kunne gjennomføres innenfor spesifikke mål), samt om kravene gjelder alle institusjonsdata og konfigureringer?

   Hvorfor det er verdt å spørre: DR/backup-omfang og testkrav er typisk kostnadsdrivende og må avklares for å prise riktig.

   Kilde: Krav 010 (6 Operations and platform)

4. I krav 013 og 014 ber dere levere beskrive arkitektur og «list of supported open-standard protocols and standard export formats». Kan dere spesifisere hvilke integrasjoner/standarder dere forventer at leverandøren primært skal støtte i denne anskaffelsen (utover det som er nevnt i Appendiks B), og om det er noen «must»-standarder blant protokoller/eksportformater dere legger til grunn i evalueringen?

   Hvorfor det er verdt å spørre: Uklart hvilke standarder som vektlegges/forventes gjør at tilbyder kan feilprioritere integrasjonsarbeidet eller underprise tilpasning.

   Kilde: Krav 013–014 (7 System Architecture)

5. Krav 019–024 gjelder API-suite, real-time APIs og performance metrics (respons time og eventuelle rate limits). Kan dere opplyse hvilke konkrete ytelses-/rate-limitmål dere forventer at API-ene skal håndtere (f.eks. maksimal requests/second per tenant, samtidighet, og/eller mål for p95/p99 responstid), og hvilke transaksjonstyper dere ser som mest kritiske (f.eks. import/oppdatering, søk/visning, LTI-kall)?

   Hvorfor det er verdt å spørre: Performance- og rate-limitforventninger påvirker kapasitet, skalering og kost, og er nødvendig for å gi korrekt estimat.

   Kilde: Krav 024 (9 Integrations)

6. I krav 031 beskriver dere «hva som er needed» for integrasjonen mot Bolk, inkludert «reusability of metadata from Leganto to create requests» og «display/upload of files from Bolk into Leganto». Kan dere bekrefte hvilke konkrete fil-/metadatafelter og flyter som skal støttes (særlig for mapping av ISBN/page range og hvordan dette håndteres når status er «Approved» vs «Action Required»), og om dere forventer synkron eller asynkron statusoppdatering mot Bolk?

   Hvorfor det er verdt å spørre: Appendix C viser en konkret flyt og API-endepunkter, men tilbyder må vite hvilke end-to-end krav som gjelder i denne anskaffelsen for å kunne prise integrasjonsarbeidet riktig.

   Kilde: Krav 031 (9 Integrations) + Appendix C – Bolk (Bolk-integrasjon)

7. Krav 032 sier «It MUST be possible to import courses from FS or from a file.» Kan dere avklare om import fra fil gjelder samme filformat/parameterstruktur som i Appendix F (FS import file format), eller om det finnes et alternativt filformat dere forventer at leverandøren skal støtte?

   Hvorfor det er verdt å spørre: Omfanget av import-støtte (formatvariant, validering, feilhåndtering) påvirker utviklings- og kvalitetssikringskost.

   Kilde: Krav 032 (9 Integrations) + Appendix F (FS import file format)

8. Krav 034 krever mulighet for «test job before courses are actually rolled over and/or created». Kan dere beskrive hvilke testresultater logg må inneholde (utover at antall og feil/manglende elementer vises), og om «test job» skal simulere alt end-to-end inkludert validering mot bibliografiske data/eksterne systemer eller kun FS-mapping?

   Hvorfor det er verdt å spørre: Hvilket nivå testjobben skal kjøre i praksis påvirker både arkitektur og tidsbruk, og dermed tilbudspris.

   Kilde: Krav 034–035 (9 Integrations)

9. I krav 042 kreves støtte for «LTI v.1.3» og i krav 040 at «reading list directly into an external webpage» skal kunne vises. Kan dere opplyse hvilke konkrete LTI-scenarier dere forventer (f.eks. IMS LTI Deep Linking/placement, hvilke roller/payload dere bruker, og hvordan reading list identifiseres i launch), og om «external webpage»-visning primært betyr embedding via URL/permalink eller også formater for full visning i iframe/JS?

   Hvorfor det er verdt å spørre: LTI- og embedding-krav er detaljerte i implementasjon og kan gi store avvik i innsats dersom scenariene er tolket ulikt.

   Kilde: Krav 040–042 (9 Integrations)

10. I krav 118 kreves at leverandøren skal dekke «daily fines» fra tilsynsmyndigheter ved ikke-oppnådd WCAG/WAD-kompliance. Kan dere presisere hvordan dere legger til grunn at leverandøren skal håndtere slike bøter (f.eks. hvem som varsles, hva som er «deadline for rectification», og om det er en caps/egenandel eller et maksimalt ansvar)?

    Hvorfor det er verdt å spørre: Kontraktuell risikofordeling for bøter kan være betydelig, og tilbyder må vite konkret ansvarsramme før man prissetter.

    Kilde: Krav 118 (16 Accessibility)