Digitale læringsressurser til grunnskolen

Rammeavtale med 1 leverandør for kjøp og levering av digitale læringsressurser/lisenser til Stavanger, Sandnes, Sola og Randaberg kommuner. Avtalen skal sikre tilgang til digitale læringsressurser fra flere forlag/leverandører, samt en webbasert løsning for bestilling/administrasjon, rapportering/statistikk, støtte og opplæring. Det stilles også krav til FEIDE-pålogging, kompatibilitet, universell utforming (WCAG), personvern/GDPR-dokumentasjon og databehandleravtale. Rammeavtalen har varighet 2 år med opsjon(er) på forlengelse.

• Oppfylle GDPR/personvernkrav ved databehandling, og bekrefte ved innlevering av tilbud at kravet vil bli overholdt i hele avtaleperioden.

  Dokumentasjon: Legges ved tilbudet under fanebladet «Dokumenter» i Mercell (sikkerhetsdokumentasjon og risikovurdering/ROS, sikkerhetspolicy, personalsikkerhet, teknisk sikkerhet inkl. penetrasjonstest, samt utfylt databehandleravtale vedlegg 3).

  Kilde: 7.1 Kravspesifikasjon, punkt 32 Behandling av personopplysninger

• Levere/legge ved elektronisk demo-program/testversjon eller oppgi passord for testbrukeradgang i webløsningen.Kilde: 7.1 Kravspesifikasjon, punkt 2 Elektronisk demo-program/testversjon
• Levere brukermanual for web-portalen på norsk elektronisk (kan være generell, men må beskrive systemtilpassede funksjoner for leveransen).Kilde: 7.1 Kravspesifikasjon, punkt 3 Brukermanual
• Fremlegge dokumentasjon for informasjonssikkerhet og GDPR-etterlevelse som del av tilbudet: sikkerhetsdokumentasjon, risikovurdering (ROS-analyse) med oppsummering og konklusjon, sikkerhetspolicy, personalsikkerhet, teknisk sikkerhet inkl. penetrasjonstest (ikke eldre enn 2 år).Kilde: 7.1 Kravspesifikasjon, punkt 32 Behandling av personopplysninger (punkter 1–2 og pkt. 3–5 i sikkerhetsdokumentasjonen)
• Databehandleravtale (vedlegg 3) skal fylles ut av leverandør og leveres sammen med tilbudet.Kilde: 7.1 Kravspesifikasjon, punkt 32 Behandling av personopplysninger (3).
• Gi dokumentasjon av oppfyllelse av universell utforming: fremlegge oppdatert og publisert tilgjengelighetserklæring (uutilsynet.no) samt dokumentere eventuelle avvik med tidsplan for retting.Kilde: 7.1 Kravspesifikasjon, punkt 33 Universell utforming

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

18.08.2026

Språk

norsk, English

Elektronisk katalog

Obligatorisk

• Rammeavtale med varighet 2 år (start og sluttdato angitt som XX.XX.2026–XX.XX.2028) og opsjon på forlengelse 1 + 1 år, samt mulighet for kortere forlengelse (ikke under 6 måneder).Kilde: 1.4 Avtalens varighet
• Leverandøren skal være fast leverandør med fast kontaktperson/kundekonsulent og stedfortreder med skolefaglig kompetanse; skift krever oppdragsgivers skriftlige forhåndsgodkjenning.Kilde: 1.7 Kontaktperson; 7.1 punkt 27 Fast kontaktperson
• Leverandøren skal sikre at oppdragsgiver er prioritert kunde og tilby bistand i innkjøp/utvelgelse kostnadsfritt ved behov.Kilde: 7.1 punkt 28 Prioritert kunde
• Brukerstøtte skal være åpent og betjent alle hverdager i ordinær arbeidstid (telefon og e-post).Kilde: 7.1 punkt 29 Brukerstøtte
• Løsningen skal tilby webbasert elektronisk bestilling og administrasjon; demo/testversjon skal være tilgjengelig under evaluering (jf. innleveringskrav) og krav til funksjonalitet i avtaleperioden gjelder.Kilde: 7.1 punkt 1 Web-basert løsning
• Feide skal brukes for pålogging og gruppehåndtering; leverandøren skal ha leverandører i porteføljen med Feidepålogging.Kilde: 7.1 punkt 5 Bruk av FEIDE
• Kompatibilitet: skal fungere på Chromebook (Chrome OS/Google Workspace for Education) og på PC med Microsoft kontorpakke; utvikles i takt med Microsoft/Google.Kilde: 7.1 punkt 6 Kompabilitet
• Mulighet for sortimentskjøp uten medfølgende trykte læremidler.Kilde: 7.1 punkt 4 Sortimentkjøp uten medfølgende trykte læremidler
• Leverandøren skal tilby bredt sortiment av digitale læringsressurser (bokmål/nynorsk, progresjon m.m.) samt andre digitale verktøy/ressurser brukt i undervisningssituasjonen.Kilde: 7.1 punkt 7 Sortiment
• Portefølje: legge til rette for overføring/videreføring av eksisterende digitale læringsressurser som ikke inngår i leverandørens portefølje.Kilde: 7.1 punkt 8 Portefølje av digitale læringsressurser
• Tilrettelegge for nye digitale læringsressurser som kommer på markedet.Kilde: 7.1 punkt 9 Nye digitale læringsressurser
• Testperiode: oppdragsgiver skal gratis kunne prøve/teste digitale læringsressurser i hensiktsmessig periode og omfang inntil 4 måneder før forpliktende lisens/kjøp, forutsatt enighet.Kilde: 7.1 punkt 10 Testperiode av digitale læringsressurser
• Web-løsning skal gi informasjon/oversikt over produkter i avtalen, og støtte administrering/oversikt for kommune- og skoleadministratorer.Kilde: 7.1 punkt 11 Webside og punkt 12 Administrering av lisenser
• Brukerroller og rolletilpasset grensesnitt (kommuneadministrator, skoleadministrator, bestiller, bruker).Kilde: 7.1 punkt 13 Brukerroller
• Merkingsmuligheter (tagging) for kommunale tjenester/lisenser, synlig for bestillerrollen (bl.a. kommunelisens, databehandleravtale, support, innloggingsmetode, universell utforming og målform).Kilde: 7.1 punkt 14 Merking (tagge)
• Star(t)siden i webløsningen med oversikt for brukergrupper (lærer, elever 1.–10.) og direktelenker til tjenestene.Kilde: 7.1 punkt 15 Startside i webløsningen
• Mulighet for administratorer til å legge til egne direktelenker til andre nettbaserte tjenester.Kilde: 7.1 punkt 16 Direktelenker
• Administrering/tillegg av tjenester (lisenser) i webbasert løsning av kommune-/skoleadministrator, og/eller leverandøren kan utføre på vegne av oppdragsgiver ved begrensninger.Kilde: 7.1 punkt 17 Kommune-/skoleadministrator
• Responsiv webløsning på ulike plattformer/skjermstørrelser.Kilde: 7.1 punkt 18 Responsiv webløsning
• Distribusjon av lisenser på skolenivå og tildeling til feidegrupper/enkeltelever når innkjøpet gjøres (beskrives i webløsningen).Kilde: 7.1 punkt 19 Distribuere lisenser på skolenivå
• Distribusjon av lisenser på kommunenivå og tildeling til skoler/feidegrupper når innkjøpet gjøres (beskrives i webløsningen).Kilde: 7.1 punkt 20 Distribuere lisenser på kommunenivå
• Utvikling/tilpasning av webløsningen i avtaleperioden etter ønsker og behov innen lovverk og leverandørens tekniske begrensninger.Kilde: 7.1 punkt 21 Utvikling og tilpasning av webløsningen
• Innlogging for administratorer skal være mulig uten Feide-konto.Kilde: 7.1 punkt 22 Innlogging administrator
• Oversikt over innkjøpte lisenser og status (antall, ubrukte lisenser, fornyelsestidspunkt) for skoleeier/skoleadministrator.Kilde: 7.1 punkt 23 God oversikt
• Statistikk/rapporter i løsningen med økonomiske rapporter og kjøpsstatistikk per skole og samlet for kommunen, med filtrering.Kilde: 7.1 punkt 24 Statistikk og rapporter
• Feide-integrasjon som muliggjør henting av faggrupper for tildeling av lisenser til hele grupper.Kilde: 7.1 punkt 25 Feide-integrasjon
• Løsningen skal gi god oversikt over hvilke produkter som er tilgjengelige og gi produktinformasjon (tittel, språk/målføre, ISBN, fag, trinn/nivå, produsent, utgivingsår, WCAG-nivå, lisenstype/varighet/avgrensinger, plattform/tekniske krav, m.m.).Kilde: 7.1 punkt 26 Informasjon om produktene
• Kvalitetssikring og oppfølging: fast kontaktperson med skolefaglig kompetanse.Kilde: 7.1 punkt 27 Fast kontaktperson
• Ordrebekreftelse skal tydelig vise hvilke varer som leveres og hvilken lisensperiode som gjelder.Kilde: 7.1 punkt 30 Ordrebekreftelse
• Opplæring: leverandøren skal kunne tilby opplæring for kommuneadministratorer (4) og skoleadministratorer/bestillere fra hver skole.Kilde: 7.1 punkt 31 Opplæring
• Personvern/GDPR: behandling av personopplysninger i samsvar med GDPR/personopplysningsloven.Kilde: 7.1 punkt 32 Behandling av personopplysninger
• Universell utforming: samsvar med WCAG på relevante A- og AA-nivå.Kilde: 7.1 punkt 33 Universell utforming
• Statistikk/rapportering: leverandøren skal rapportere forbruk/leverandørstatistikk i Excel (eller konverterbare formater) uten kostnad; hyppighet hver 6./12. måned hvis ikke annet er avtalt.Kilde: 6 Statistikk
• Priser: påslag på leverandørens innkjøpspris (fritt levert brukersted) og prisene skal inkludere alle kostnader; ingen ekstra gebyrer (fakturagebyr/administrasjonsgebyr o.l.). Kampanjer/lavere markedspris skal gjelde umiddelbart for alle leveranser.Kilde: 2 Priser (generelle prisbestemmelser) og 2.1 Pris utvalgte lisenser
• Betaling/fakturering: elektronisk faktura (EHF) til kommunenes e-fakturaadresser, én faktura per ordrenummer/rekvisisjon/oppdrag; leverandøren kan ikke fakturere før leveransen er levert.Kilde: 3 Betaling og fakturering; 3.1-3.4 (kommunespesifikke bestemmelser)

• Dokumentet mangler enkelte konkrete verdier (f.eks. avtalenummer 2026/xxxxx og start/slutt dato er angitt som XX.XX.2026/XX.XX.2028).
• Konkurranse-/tilbudsinnleveringskrav utover kravspesifikasjonens dokumentasjonskrav er ikke gitt i teksten (f.eks. øvrige Mercell-krav, evalueringsmodell/tildelingskriterier mangler).
• Tekniske detaljer om «pris for tjenesten» og implementeringskostnader i webløsningen er oppført som utelatt/ufylt (kr -).
• Følgende felter er ikke utfylt: navn/e-post/telefon for partenes kontaktpersoner og leverandørens representant/stedfortreder (placeholder «SETT INN NAVN»).

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 avtaledokumentet står det at avtalen har start- og sluttdato som «XX.XX.2026» og «XX.XX.2028». Kan dere bekrefte konkrete datoer (inkl. tidspunkt) for avtalestart og avtalens utløp, samt dato/tid for når opsjonsår kan starte?

   Hvorfor det er verdt å spørre: Leverandøren må kunne time oppstart av webløsning, drift, eventuelle demo-/testoppsett og prismodell (årlig lisensvarighet) korrekt i tilbud og gjennomføring.

   Kilde: 1.4 Avtalens varighet

2. I punkt 1.1 og 1.7 er flere felter angitt som «SETT INN NAVN»/placeholder. Kan dere sende til hvilket konkrete navn/roller og kontaktopplysninger som skal inn i avtalen (oppdragsgivers partsrepresentant og leverandørens representant), eller avklare om leverandøren skal fylle inn sitt eget personale alene mens oppdragsgiver fyller inn resterende?

   Hvorfor det er verdt å spørre: Avklaring reduserer risiko for formelle avvik før signering og sikrer at kontraktsforpliktelser om faste kontaktpersoner blir korrekt.

   Kilde: 1.1 Parter og 1.2 Partenes kontaktpersoner

3. Tabell 2.1 «Pris utvalgte lisenser» og «Pris for elektronisk bestillings- og administrasjonsløsning - Webløsning» inneholder flere «kr -»/ufylte prisfelter i utdraget. Kan dere bekrefte hvilke priser som skal fylles ut i tilbudet (og om dere forventer påslag i prosent eller kroner for hver kategori/bunt), og om alle oppførte lisenskategorier og web-typer må prises?

   Hvorfor det er verdt å spørre: Ufylt prismal i utdraget gjør at leverandøren må få presis avklaring på utfyllingsomfanget for å prise riktig og unngå avvisnings-/urettmessige tilbud.

   Kilde: 2 Priser (2.1 Pris utvalgte lisenser) samt «Pris for elektronisk bestillings- og administrasjonsløsning - Webløsning»

4. Det står at pris skal oppgis som «påslag på leverandørens innkjøpspris», og at det «fritt levert det enkelte brukerstedet». Kan dere presisere hva som menes med «innkjøpspris» i praksis (f.eks. netto innkjøpspris fra forlag/produsent), og hvordan dere forventer at leverandøren dokumenterer/rapporterer innkjøpsgrunnlaget ved innsynskrav og evt. revisorbekreftelse?

   Hvorfor det er verdt å spørre: For å kunne prise og kontraktsmessig underbygge «reelle innkjøpspriser» trenger leverandøren klarhet i beregningsgrunnlaget og dokumentasjonsprosessen ved kontroll.

   Kilde: 2 Priser (avsnitt om påslag, reelle innkjøpspriser og innsyn)

5. I punkt 2.1 «Påslag på øvrig sortiment» er det oppgitt 0% for kategori 1–4. Skal dette forstås som faste påslag i hele avtaleperioden (og at disse ikke skal prises/tilbys), eller gjelder de bare dersom leverandøren ikke foreslår noe annet i tilbudet?

   Hvorfor det er verdt å spørre: Leverandøren må forstå om disse kategoriene er endelig fastsatt eller om det finnes en fleksibilitet i tilbudsutfyllingen som påvirker totaløkonomi og risiko.

   Kilde: 2.1 Påslag på øvrig sortiment

6. Av punkt 30 «Ordrebekreftelse» følger det at det tydelig skal fremkomme «hvilken periode lisenser/produkter kjøp på denne rammeavtalen gjelder for». Kan dere avklare forventet format og hvilke felter som må vises (start/sluttdato, lisensvarighet, evt. fornyelses-/aktiveringsdato) for ulike lisentyper (f.eks. skolelisens vs kommunelisens)?

   Hvorfor det er verdt å spørre: Korrekt ordrebekreftelsesinnhold er nødvendig for å unngå avvik og forsinkelser i avrop/leveranse, og påvirker også fakturering og styring av lisensvarighet.

   Kilde: 7.1 D. Levering og service (30 Ordrebekreftelse)

7. I faktureringsbestemmelsene varierer enkelte vilkår mellom kommunene (f.eks. Stavanger har avtalenummermerking og «kan ikke fakturere før leveransen er levert», mens Sandnes/Sola/Randaberg har egne detaljer). Kan dere beskrive hvordan leverandøren skal håndtere «en faktura per ordrenummer» dersom samme avrop inneholder flere digitale ressurser/lisenser og eventuelle separate leveransetidspunkter?

   Hvorfor det er verdt å spørre: Leverandøren trenger en praktisk faktureringsoperasjon for å sikre korrekt EHF-merking, unngå refusjon og minimere risiko for kompensasjon ved feil.

   Kilde: 3 Betaling og fakturering (innledende tekst) samt 3.1–3.4

8. I 7.1 C «Web-løsning for kjøp, oversikt og administrasjon av lisenser» er flere krav formulert som «ønskelig» og «leverandøren bes beskrive i hvilken grad … åpner for dette». Kan dere presisere hva som er obligatoriske krav (må-krav) versus tilbudte/opsjonelle «ønskelig»-krav, og om oppfyllelsesgrad på «ønskelig»-punktene påvirker evalueringen?

   Hvorfor det er verdt å spørre: Utydelig skille mellom kravtyper påvirker leverandørens investerings- og løsningsvalg samt hvordan man bør beskrive modenhet for å møte evalueringens forventninger.

   Kilde: 7.1 Kravspesifikasjon i avtaleperioden (særlig avsnitt C, punkter 12–26 med «ønskelig»)

9. Punkt 32 krever omfattende sikkerhets-/GDPR-dokumentasjon, inkludert «bekreftelse på utført penetrasjonstest (ikke eldre enn to år)» og «ROS-analyse … system og tjeneste som skal brukes i transport av brukerne». Kan dere bekrefte om dere forventer at leverandøren kan levere disse dokumentene som utdrag/sammendrag (uten sensitiv teknisk detalj), og hvilke minimumskriterier dere legger til grunn for at dokumentasjonen skal anses tilstrekkelig?

   Hvorfor det er verdt å spørre: Leverandøren må planlegge dokumentproduksjon og eventuelt NDA/tilgang til underleverandørers dokumentasjon for å oppfylle kravene uten uforholdsmessig teknisk sensitivitet.

   Kilde: 7.1 E. Personvern og informasjonssikkerhet + universell utforming (32 Behandling av personopplysninger)

10. I 7.1 A/B/C er det krav om FEIDE-bruk og kompatibilitet (Chromebook/Chrome OS/Google Workspace for Education og PC/Microsoft sin kontorpakkeløsning). Kan dere avklare hvilke konkrete FEIDE-tilknytninger/integrasjonsmetoder dere bruker (f.eks. SAML/OIDC) og hvilke identitetsobjekter dere forventer at leverandøren håndterer (bruker, gruppe, klasse/faggruppe), slik at vi kan beskrive korrekt funksjonalitet og testing?

    Hvorfor det er verdt å spørre: Identitetsintegrasjon er ofte kompleks; presisjon på integrasjonsforutsetninger er nødvendig for å kunne levere riktig løsning og for å kunne prise/planlegge implementering og testing.

    Kilde: 7.1 A. Generelle krav (5 Bruk av FEIDE…) og 6 Kompabilitet samt 25 Feide-integrasjon