Sunnfjord kommune
Trykte læremiddel, rammeavtale
Konkurransen gjelder rammeavtale for trykte skolebøker med tilhørende produkter.
Anskaffelsens verdi anslås til: NOK 5.000.000,- eks. mva per år. Maksimalverdi for hele avtaleperioden, inkludert eventuelle opsjoner og forventet prisstigning: NOK 30 000 000,- eks mva. Behovet er usikkert. Volumet kan variere både opp og ned, og vil i avtaleperioden være avhengig av blant annet oppdragsgivers behov, aktiviteter, budsjettsituasjon og andre rammefaktorer.
For nærmere informasjon viser vi til anskaffelsesdokumentene.
Oppdragsgiver har vurdert anskaffelsen opp mot anskaffelsesloven § 5h, og konkludert med at det ikke stilles krav til lærlinger i denne anskaffelsen da anskaffelsen er en vareanskaffelse, jf. anskaffelsesloven § 5h 1. ledd.
Del 1: Kjøper
Del 2: Prosedyre
Del 5: Delkontrakt
Del 8: Virksomheter
Kunngjøringsinformasjon
Sammendrag
Anbudsradar
Dokumentene omhandler rammeavtale for trykte læremidler (og tilknyttede digitale læremidler/ordnings-/bestillingsportal). Videre beskrives krav til universell utforming, personvern og informasjonssikkerhet, tilgangsstyring/autentisering, teknisk drift (HA/redundans), logging/revisjon, API og datadeling/åpne grensesnitt samt krav til dokumentasjon, testing, sikkerhetsoppdateringer og databehandling/avslutning. Det finnes også veiledning for leverandørers innlevering av tilbud i Tendsign/Mercell, samt veileder for sladding/innsyn i tilbud etter tildeling.
Krav til tilbudet
Anbudsradar
- Levering av tilbud i tide er leverandørens ansvar; oppdragsgiver/Innkjøpskontoret AS har ikke ansvar ved manglende levering før tilbudsfrist. (Råd knyttet til tidsrisiko: strømbrudd, PC-krasj, internettutfall, forsinkelser med avklaring/etterspurte svar.)Kilde: Viktig om innlevering av tilbud.pdf / «Om tilbudsinnlevering – les dette først»
- Tilbud kan leveres og trekkes tilbake så mange ganger som ønsket frem til tilbudsfrist; ved siste informasjonsbit kan tilbyderen trekke, endre og levere på nytt.Kilde: Viktig om innlevering av tilbud.pdf / «1. Spar ventingen til slutt»
- Dersom leverandør må bruke underleverandører/støttevirksomheter: les konkurransegrunnlaget for hva som kreves (forpliktelseserklæring/skatteattest/ESPD). Hovedleverandør må fylle ut ESPD for underleverandør/støttevirksomhet dersom det kreves.Kilde: Viktig om innlevering av tilbud.pdf / «4. Underleverandører eller støttevirksomheter?»
- Digital signatur: tilbudet må signeres via invitasjon til signerende person; signatur må mottas tilbake før tilbudet kan leveres.Kilde: Viktig om innlevering av tilbud.pdf / «5. Digital signatur»
- Ved signering: etter at signerende er lagt inn må tilbyder trykke på grønn «V»-knapp for å initiere signering (ellers feilmelding om at mottaker og signeringsdokument kreves).Kilde: Viktig om innlevering av tilbud.pdf / «Har du trykket på den grønne knappen?»
Innleveringsvilkår fra kunngjøringen
- Frist for forespørsel/tilbud
- 19.10.2026
- Språk
- norsk, English
- Elektronisk katalog
- Tillatt
Tildelingskriterier
Anbudsradar
| Kriterium | Vekt | Beskrivelse |
|---|---|---|
| Priser og kostnader | 30 % | - |
| Service og kompetanse | 20 % | - |
| Sortiment og bestillingsløsning | 20 % | - |
| Klima og miljø | 30 % | - |
Viktige kontraktskrav
Anbudsradar
- Universell utforming: løsning/leveransen skal oppfylle krav i forskrift om universell utforming av IKT-løsninger; automater i samsvar med automatstandarder (jf. § 4d eller tilsvarende); dokumentasjon for oppfyllelse skal være tilgjengelig for kunden.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.1 Universell Utforming
- Personvern og informasjonssikkerhet: innebygget personvern (GDPR art. 25), ivaretakelse av konfidensialitet/integritet/tilgjengelighet; leverandør skal tilgjengeliggjøre dokumentasjon nødvendig for kundens ROS og DPIA; etterlevelse av personopplysningsloven og GDPR; støtte for normkrav for helse- og omsorgstjenester.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.2 Personvern og informasjonssikkerhet
- API/grensesnitt: standardiserte og åpne grensesnitt; sikret gjennom autentisering/autorisasjon; åpne API skal være kjent/publisert, ha åpen dokumentasjon (gratis) og følge åpne formater (OpenAPI/FHIR Capability Statement eller tilsvarende); vilkår for datadeling skal være langsiktige, transparente og ikke-diskriminerende; komplett API-dokumentasjon inkl. eksempelkode, feilhåndtering, tilgangsstyring/sikkerhetsmekanismer, testmuligheter, tilgjengelighet/vedlikehold, begrensninger, lisensiering/kostnader, bruksvilkår for data, levetid/versjonering.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.3 Programmeringsgrensesnitt (API)
- Tilgangsstyring og autentisering: støtter SSO (pålogging via Feide/Active Directory og Azure-AD) og robust tilgangskontroll; mulighet for sikker pålogging fra eksterne nettverk og flerfaktorautentisering; audit/etterprøvbarhet av identifisering, autentisering, autorisering og administrasjon.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.4 Tilgangsstyring og autentisering
- Teknisk løsning/drift: høy tilgjengelighet, redundans og feiltoleranse; kapasitet for god ytelse/brukeropplevelse; sikker og stabil drift slik at data ikke forsvinner og tjenesten er tilgjengelig i avtalt tidsrom; dokumenterte rutiner for logging/monitorering og beskyttelse av logger; forhindring av uautorisert tilgang; kundens rett til revisjon/innsyn i revisjonsrapporter.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.5 Teknisk løsning
- Sikkerhet: styringssystem for informasjonssikkerhet (ISO27001 eller tilsvarende), rutiner for underleverandørers inkludering, definert ansvar/roller, fysisk sikring, anerkjent drifts-/forvaltningsmetodikk; sikkerhetsovervåkning og varsling; beredskaps-/kontinuitets-/katastrofeplan; jevnlig sikkerhets-/penetrasjonstesting; prosess for endringshåndtering; årlige (min.) risikovurderinger og opplysningsplikt om alvorlige sikkerhetsbrudd; mulighet for kunden å kreve sikkerhetstester; dokumentert prosess for sikkerhetsoppdateringer; segregering av kundedata; prosess for kryptering og krypteringsnøkkel-håndtering; backup og test av gjenoppretting; dokumentert sletteprosess og sikring mot gjenoppretting/avveie ved utskifting/fornyelse.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.6 Sikkerhet
- Forvaltning/leveranse: videreutvikling i tråd med rammeverk/lover/forskrifter/standarder; endringer dokumenteres og systemdokumentasjon oppdateres; test- og sertifiseringsopplegg for integrasjon/tilkobling; hendelseshåndtering og brukerforum; bistand ved avslutning og dataoverføring til kunden/angitt tredjepart; kundens eierskap til kundedata etter avslutning; opplæring/kompetanseheving i personvern og informasjonssikkerhet; leveranser i tråd med norske lover og regler.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 1.7 Forvaltning
- Bestillings- og løsningen i praksis (utdrag fra behov): tilbytte læremidler etter gjeldende læreplan; innlogging til bestillingsportal skjer gjennom Feide; tilpasning til universell utforming; kapasitet til å håndtere bestillingsmengder; fleksible søkemuligheter; gjennomsyn av bøker uten kostnad og uten kjøpsforpliktelse; brukervennlig nettbutikk på norsk; punchout-løsning kan overføres til handlekurv i Visma Enterprise plus; retur av skadde/feiltrykk/utilfredsstillende innbinding uten kostnad for oppdragsgiver; ingen kostnader for dataeksport ved avtaleopphør.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 2 Behov / 2.1 Generelle behov
- Kvalitet/levetid (utdrag): læremidler tåler normal slitasje; trykte læremidler har garantert levetid på 4 år ved normal bruk og slitasje; leverandør kan plaste bøker på kundens bestilling.Kilde: Vedlegg 1 Behovsbeskrivelse - 090926.xlsx / 2 Behov / 2.2 KVALITET
Forbehold ved utdraget
Anbudsradar
- Ingen eksplisitte kvalifikasjonskrav eller tildelingskriterier fremgår av den medfølgende tekst (kun innleverings-/innsynsveiledning og behovs-/kravsbeskrivelse).
- Dokumentutdraget inneholder ikke direkte tilbudsfrist, evalueringsmodell eller konkrete dokumentasjonskrav for leverandørens kvalifikasjoner (disse kan ligge i andre deler av konkurransegrunnlaget som ikke er med her).
- Prisskjemaet (Prisskjema 090926.xlsx) viser rabatt/volum og totaler, men det er ikke oppgitt evalueringsmåte for tildeling i det medfølgende tekstgrunnlaget.
Verdt å avklare med oppdragsgiver
Anbudsradar
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.
Pkt. 1.1.1–1.1.4 om universell utforming beskriver at løsningen oppfyller forskrift om universell utforming av IKT-løsninger på leveringstidspunktet, og at automater skal utformes i samsvar med «ti automatstandarder» i § 4d. Kan dere bekrefte om bestillingsportalen skal evalueres som «nett-/app-løsning», «automatløsning» og/eller «annen IKT», og hvilket test-/samsvarsdokumentasjon dere forventer at leverandør leverer (f.eks. erklæring/rapport)?
Hvorfor det er verdt å spørre: Ulik forståelse av hvilke IKT-typologier som gjelder og hvilken type dokumentasjon som forventes kan gi feil kostnadsberegning og mangelfull tilbudsdokumentasjon.
Kilde: Behovsbeskrivelse – 1.1 Universell Utforming (1.1.1–1.1.4)Pkt. 1.2.4 krever dokumentasjon som er nødvendig for kundens ROS og DPIA. Hvilke konkrete maler/format og minimumsinnhold forventer dere at leverandøren leverer (f.eks. DPIA/ROS-underlag, datakartlegging, behandlingsgrunnlag, datalagring/sletting), og hvordan skal dokumentasjonen leveres (som egen rapport, excel/tekst, eller via spesifikk dokumentmal)?
Hvorfor det er verdt å spørre: Kravet påvirker både omfanget av personvernarbeidet og hvordan leverandøren skal planlegge leveranse og kostnader.
Kilde: Behovsbeskrivelse – 1.2 Personvern og informasjonssikkerhet (1.2.4)Pkt. 1.3 (programmeringsgrensesnitt) stiller detaljerte krav til åpne API-er, herunder dokumentasjon i «OpenAPI Specification»/«FHIR Capability Statement» og at test av bruk av API bør være gratis. Kan dere spesifisere om bestillingsportalen/rammeavtalen krever «åpne» API-er som tredjepart kan teste uavhengig av leverandør, eller om kravet primært gjelder integrasjon mellom partene (kunde/leverandør) – og i så fall hvilke API-er som inngår?
Hvorfor det er verdt å spørre: En konkret avklaring av omfanget (åpent tredjeparts-API vs. partstilgang/integrasjon) er avgjørende for kost/risiko og riktig tilbudsinnsats.
Kilde: Behovsbeskrivelse – 1.3 Programmeringsgrensesnitt (1.3.1–1.3.13)Pkt. 1.4.1–1.4.3 beskriver Feide pålogging i behovsarket og single-sign-on med Active Directory/Azure-AD samt støtte for flerfaktorautentisering fra eksterne nettverk. Kan dere bekrefte hvilken autentiseringsløsning som er «styrende» for denne anskaffelsen (Feide vs. AD/Azure-AD), og hvilke krav dere har til MFA (frekvens/kravnivå), samt hvem som er ansvarlig for konfigurasjon i kundens identitetsplattform?
Hvorfor det er verdt å spørre: Kravene kan peke i ulike retninger (Feide og AD/Azure-AD). Feil forutsetning kan gi både forsinkelse og feil prising av leveranse-/driftskostnader.
Kilde: Behovsbeskrivelse – 1.4 Tilgangsstyring og autentisering (1.4.1–1.4.3) samt Behov – 2.1 Generelle behov (2..1.3)Pkt. 2.1.1–2.1.2 og punkt om bokgrupper (2..1.1–2..1.3 samt Prisskjemaet) omtaler levering i henhold til «gjeldende læreplan», og at det kan leveres bøker i bokgruppe 1 og 8 «i henhold til bokavtale». Kan dere bekrefte hvilke bokgrupper og eventuelle underkategorier dere forventer at leverandøren priser/leverer under rammeavtalen, inkludert om «bokgruppe 8.2 og 8.9» i prisskjemaet fullt ut dekker kravene dere har definert for bokgruppe 8 i behovsbeskrivelsen?
Hvorfor det er verdt å spørre: Prisskjemaets bokgruppeinndeling må samsvare med leveransekravene, ellers kan tilbudet bli uforenlig med avtalens pris-/leveranseforutsetninger.
Kilde: Behov – 2.1 Generelle behov (2..1.1–2..1.2) og Prisskjema (Bokgruppeinndeling / «Bokgruppe 8.2 og 8.9»)Pkt. 2.1.5 om kapasitet i hovedbestillingsperiodene: Hvilke konkrete volumtopper/innkjøpsperioder legger dere til grunn (f.eks. antall ordrelinjer/antall enheter per uke), og er det forventet beredskap/ekstra bemanning i bestemte perioder som leverandør skal prise?
Hvorfor det er verdt å spørre: Uten konkrete volumtopper blir det vanskelig å dimensjonere bemanning, lager/logistikk og systemkapasitet korrekt.
Kilde: Behov – 2.1 Generelle behov (2..1.5)Pkt. 2.1.7 beskriver fleksible søkemuligheter i portalen (temasøk, alderstrinn, «hva er populært», tilbud til skolebibliotekene). Kan dere spesifisere hvilke av disse søke-/filtreringsdimensjonene som er «must-have» (skal fungere i portalens UI i det som leveres), og hvilke som eventuelt kan løses via administrasjon/bakgrunnslogikk uten egen synlig funksjon?
Hvorfor det er verdt å spørre: Kostnaden avhenger av om kravene gjelder brukergrensesnitt/parametere i søk i første leveranse eller kan løses mer indirekte.
Kilde: Behov – 2.1 Generelle behov (2..1.7)Pkt. 2.1.8–2.1.9: dere beskriver kostnadsfritt gjennomsyn og at nettbutikken har en «brukervennlig nettbutikk». Hva er forventet prosess for gjennomsyn (hvordan bestilles, tidsfrist for retur/tilbakelevering, hvem betaler frakt, og begrensninger på antall titler/eksemplarer per bestilling), og hvordan skal dette inn i nettbutikk/portalløsning?
Hvorfor det er verdt å spørre: Prosessdetaljer påvirker direkte kostnader (logistikk/administrasjon) og hvor omfattende funksjonalitet leverandøren må bygge/operasjonalisere.
Kilde: Behov – 2.1 Generelle behov (2..1.8–2..1.10)Pkt. 2.1.12 og prising: «Bøker kan returneres ... uten kostnad for oppdragsgiver» når skadet/feiltrykk/utilfredsstillende innbinding. Kan dere angi hvilke kostnadselementer dere forventer at leverandør dekker (frakt tur/retur, svinn, administrasjon, ombytting vs. tilbakebetaling), og hvilke returfrister/krav til dokumentasjon dere forventer?
Hvorfor det er verdt å spørre: Retur- og reklamasjonslogikk er ofte en av de største kostnadsdriverne, og må avklares for korrekt prising.
Kilde: Behov – 2.1 Generelle behov (2..1.13)
Kurs og rådgivning fra redaksjonen
Gratis fagmøte – 30 minutter digitalt om aktuelle anskaffelsestemaer.
Se datoer →Kurs: Hvordan vinne anbud – praktisk kurs for deg som skriver tilbud.
Les mer →Rådgivning
Ta kontakt →