Bistand til utvikling av en ny webbasert versjon av IKT-læremiddelet Sarepta

Statped inviterer til åpen anbudskonkurranse om konsulentbistand for utvikling av en ny webbasert versjon av IKT-læremiddelet Sarepta (grunnleveranse). Bistanden omfatter videreføring av funksjonalitet og pedagogiske prinsipper fra dagens klientbaserte moduler Tekst og Billedbok, men etablert på en moderne teknisk plattform. Løsningen skal være en webapplikasjon publisert som åpen kildekode, lagt til rette for forvaltning/videreutvikling hos Statped etter avsluttet bistand, og tilpasset målgruppen (bryterstyring, skjermleser/talesyntese/leselist, Feide/ID-porten, universell utforming, sikkerhet og personvern). Det er planlagt kontrakt med én leverandør.

• Leverandøren skal ha ordnede forhold til skattemyndighetene (skatt og merverdiavgift).

  Dokumentasjon: Norske leverandører: skatte- og merverdiattest (ikke eldre enn 6 mnd fra tilbudsfrist). Utenlandske leverandører: attest fra tilsvarende myndighet; ev. egenerklæring om skatte-/mva.-restanser (signert) dersom attest ikke utstedes.

  Kilde: Kap. 4.1 Leverandørens betaling av skatter og avgifter
• Leverandøren skal være et lovlig etablert foretak.

  Dokumentasjon: Norske: firmaattest fra Foretaksregisteret (ikke eldre enn 6 mnd). Utenlandske: bekreftelse på registrering i foretaks-/fag-/handelsregister i hjemstaten. For selskaper under etablering: stiftelsesdokument.

  Kilde: Kap. 4.2 Leverandørens juridiske stilling
• Leverandøren skal ha tilstrekkelig økonomisk og finansiell kapasitet til å kunne utføre kontrakten.

  Dokumentasjon: Kredittvurdering basert på siste kjente regnskapstall/rating fra konsesjonspliktig kredittopplysningsvirksomhet. Oppdragsgiver kan innhente ytterligere økonomisk informasjon. Alternativt: annet egnet dokumentasjon ved saklig grunn.

  Kilde: Kap. 4.3 Leverandørens økonomiske og finansielle kapasitet
• Støtte fra andre foretak er mulig for å oppfylle kvalifikasjonskrav (finansiell/økonomisk og/eller tekniske og faglige).

  Dokumentasjon: Forpliktelseserklæring (fortrinnsvis) og dokumentasjon som viser: støttehensikt, hvilke krav det støttes på, hvilke arbeider som skal utføres (for teknisk/faglig), hvilke ressurser som stilles til rådighet. Støttende foretak må oppfylle relevante krav (inkl. skatt/mva.) og levere ESPD; solidaransvar kreves ved støtte til økonomisk/finansiell stilling (dokumentasjon ved tilbud).

  Kilde: Kap. 4.4 Støtte fra andre foretak for å oppfylle kvalifikasjonskravene
• Avvisning ved manglende oppfyllelse av kvalifikasjonskrav eller avvisningsgrunner etter FOA.

  Dokumentasjon: ESPD benyttes som foreløpig dokumentasjon; avvisningsgrunner etter FOA § 24-2 (inkl. nasjonale avvisningsgrunner) gjelder.

  Kilde: Kap. 3 (ESPD) og Kap. 4.5 Avvisning

• ESPD-skjema skal leveres sammen med tilbudet som foreløpig dokumentasjon på oppfyllelse av kvalifikasjonskrav og at avvisningsgrunner ikke foreligger. Ved flere leverandører i fellesskap: separate ESPD for hver.Kilde: Kap. 3.1 Generelt om ESPD
• Evt. ESPD for støttende foretak og evt. forpliktelseserklæring for støttende foretak, hvis leverandøren støtter seg på andre foretak for kvalifikasjonskrav.Kilde: Kap. 6.1 Tilbudets utforming (punkt om kvalifikasjonsdokumentasjon) + Kap. 4.4
• Forpliktende tilbudsbrev (minimum: dato og underskrift; kontaktperson; oversikt over dokumentene; bekreftelse av vedståelsesfrist; uttømmende oversikt over eventuelle avvik).Kilde: Kap. 6.1 Tilbudets utforming
• Tilbudet skal inneholde: utfylt løsningsbeskrivelse og CV-er (SSA-B Bilag 2); utfylt prosjekt- og fremdriftsplan (SSA-B Bilag 3); utfylt prisskjema (SSA-B Bilag 5).Kilde: Kap. 6.1 Tilbudets utforming
• Tilbud skal leveres elektronisk i KGV (EU-supply). Tilbud sendt på e-post/lignende medfører avvisning.Kilde: Kap. 6 (Innlevering av tilbud) + Kap. 6.4 Rettidig levering
• Dokumentformat: dokumentasjon lastes opp som PDF-filer dersom ikke annet format er spesifisert.Kilde: Kap. 6.1 Tilbudets utforming
• Språk: tilbud på norsk; bilag med tekniske spesifikasjoner el.l. kan leveres på dansk, svensk eller engelsk.Kilde: Kap. 6.8 Språk

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

05.10.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Kontrakten reguleres av SSA-B (statens standardavtale om konsulentbistand) med bilag; omfang/beskrivelse ligger i SSA-B Bilag 1 og leveranse/leverandørspesifikasjon i Bilag 2-3 samt pris i Bilag 5.Kilde: Prosedyrebeskrivelse Kap. 1.4 og SSA-B 2026 (1.1/1.2)
• Løsningen skal være en webapplikasjon, publisert som åpen kildekode, og lagt til rette for at Statped kan forvalte og videreutvikle etter bistanden er avsluttet.Kilde: Prosedyrebeskrivelse Kap. 1.3 Anskaffelsens formål og omfang; SSA-B Bilag 1 (Ny løsning – rammer og føringer)
• Tekniske og sikkerhets-/personvernkrav: OWASP Top 10, sikker autentisering/autorisasjon, kryptert kommunikasjon; personvern by design/default (GDPR).Kilde: SSA-B Bilag 1 (Informasjonssikkerhet og personvern)
• Autentisering: Feide for elever og ID-porten for foresatte/voksenbrukere.Kilde: SSA-B Bilag 1 (Autentisering)
• Testing og overlevering: etablere test-/produksjonsmiljø i Statpeds infrastruktur (eller annen hensiktsmessig), sørge for oppsett i produksjonsmiljø, lagre all kildekode/teknisk dokumentasjon i Statpeds GitHub-organisasjon og sikre kompetanseoverføring slik at Statped kan forvalte videre.Kilde: SSA-B Bilag 1 (Gjennomføring av bistanden)
• Nøkkelpersonell: nøkkelpersonell skal fremgå av bilag 4; skifte krever kundens godkjenning; kostnader til kompetanseoverføring bæres av konsulenten.Kilde: SSA-B 2026 (5.2 Nøkkelpersonell) + Bilag 4 i SSA-B Bilag.docx
• Fakturering: etterskuddsvis per måned basert på førte timelister; krav om elektronisk faktura i godkjent standardformat (EHF) for offentlige kunder.Kilde: Prosedyrebeskrivelse/SSA-B 2026 (6.2 Fakturering)
• Budsjett-/varslingsplikt ved overskridelser: konsulenten skal varsle skriftlig ved 30%, 50% og 80% av totalrammen/budsjettforbruk med oppdatert oversikt.Kilde: SSA-B Bilag.docx (D. Overskridelser og varsling)

• Prosedyrebeskrivelsen viser estimert maksimalramme på 2,0 mill. kr ekskl. mva., men det er uklart om dette er totalramme for alle opsjoner/tilleggsleveranser eller kun grunnleveransen (tilleggsleveranser kan bestilles senere).
• SSA-B Bilag.docx viser innhold i bilagene, men konkrete krav i kontraktsvedlegg (f.eks. detaljer i Bilag 2 og Bilag 3) er ikke inkludert som utfylt eksempel; kravene i prosedyredokumentet er derfor mer detaljerte enn kontraktsbilagenes utfylte form.
• Tildelingskriteriet 'Kvalitet 70%' inneholder underpunkter; dokumentet sier at evaluering avhenger av innleverte beskrivelser/CV-er, men det finnes ikke en eksplisitt poeng-/tærskelmodell utover poengskala 0-10.
• Miljøvurdering er angitt som 'uvesentlig' for kontraktens hovedelement; det er uklart om det foreligger ytterligere konkrete miljøkrav/egenrapportering.

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 prosedyrebeskrivelsen (punkt 1.3) oppgis estimert maksimalramme på 2,0 mill. kroner ekskl. mva. for «grunnleveransen», og det fremgår samtidig at Statped kan bestille tilleggsleveranser senere. Kan Statped bekrefte om 2,0 mill. kr er en totalramme som gjelder kun grunnleveransen (uten tilleggsleveranser), og hvordan eventuelle tilleggsleveranser vil pris- og rammeavgrenses/avtales i praksis?

   Hvorfor det er verdt å spørre: Avklaring av ramme-/prislogikk er kritisk for å prise riktig omfang og risiko, og for å unngå at leverandøren priser inn forhold som kan komme som opsjoner/tilleggsleveranser.

   Kilde: Prosedyrebeskrivelse punkt 1.3 «Anskaffelsens formål og omfang»

2. I tildelingskriteriet «Kvalitet (70 %)» vises underpunkter og at evaluering skjer på en poengskala 0–10, men dokumentet beskriver ikke en eksplisitt vektings-/tærskelmodell. Kan Statped beskrive hvilken samlet evalueringslogikk som legges til grunn (for eksempel hvordan løsningsbeskrivelsen (35 %), teamkompetanse (50 %) og fremdriftsplan (15 %) faktisk omsettes til poeng innenfor 70 %), og om det finnes minstekrav som må oppnås for å få uttelling?

   Hvorfor det er verdt å spørre: Utydelig evaluering kan gi feil prioritering i tilbudet og økt risiko for at leveransen ikke treffer det oppdragsgiver vektlegger.

   Kilde: Prosedyrebeskrivelse punkt 5.2 «Kvalitet» og punkt 5 «Tildelingskriterier»

3. I krav-/behovsbeskrivelsen (Bilag 1) står det at teknologier som Statped har kompetanse på (Python/Django og React) skal være utgangspunktet, men at alternative teknologivalg kan foreslås og må godkjennes. Hvilke «beslutningspunkter» gjelder for godkjenning (for eksempel ved valg av arkitektur før utviklingsstart, og/eller ved endringer underveis), og hvordan dokumenteres og kommuniseres eventuelle godkjenninger?

   Hvorfor det er verdt å spørre: Leverandøren trenger forutsigbarhet for scope, tidsplan og risiko knyttet til teknologivalg og eventuelle endringsprosesser.

   Kilde: SSA-B bilag 1 «Tekniske rammer – Teknologi og teknisk arkitektur»

4. Bilag 1 beskriver at løsning skal baseres på containerteknologi med Docker, og at alternative løsninger kun kan tas i bruk etter begrunnelse og godkjenning. Kan Statped presisere hvilke minimumsforutsetninger som gjelder for Docker (f.eks. målarkitektur for utvikling/test/produksjon, bruk av konkrete komponenter eller CI/CD), og om det forventes at leverandøren leverer ferdige Docker-oppsett for test- og produksjonsmiljø?

   Hvorfor det er verdt å spørre: Dette påvirker både leveranseinnhold og kostnadsestimat (oppsett, driftshåndtering, dokumentasjon og test), og dermed leverandørens prising.

   Kilde: SSA-B bilag 1 «Tekniske rammer – Containerteknologi» samt «Gjennomføring av bistanden» om test- og produksjonsmiljø

5. I Bilag 1 fremgår det at oppdraget inkluderer etablering av test- og produksjonsmiljø i Statpeds servermiljø eller annen infrastruktur, og at all kildekode/teknisk dokumentasjon skal lagres i Statpeds GitHub-organisasjon. Hvilke konkrete miljøforutsetninger gjelder hos Statped (for eksempel tilgjengelige plattformer, nettverks-/tilgangskrav, standarder for secrets, og forventet fremgangsmåte for å gi leverandøren tilgang til GitHub og infrastrukturen)?

   Hvorfor det er verdt å spørre: Manglende kjennskap til tekniske forutsetninger kan gi vesentlige avvik i fremdrift, sikkerhet og ressursbruk, og kan i verste fall gjøre leveransen dyrere enn forutsatt.

   Kilde: SSA-B bilag 1 «Gjennomføring av bistanden» (etablering av test-/produksjonsmiljø og lagring i Statpeds GitHub-organisasjon)

6. Bilag 1 fastsetter autentisering med Feide for elever og ID-porten for foresatte/voksne, samt at én elevbruker kan være knyttet til én eller flere voksenbrukere og at tilknytninger skal kunne etableres/endres/fjernes «på en kontrollert måte». Kan Statped beskrive ønsket flyt og krav for: (1) hvordan Feide/ID-porten-mapping til brukere håndteres, (2) hvilke kontrollregler som skal gjelde ved tilknytning (samtykke, tidsbegrensning, validering), og (3) hvilke brukerroller/tilganger som skal gjelde ved endringer?

   Hvorfor det er verdt å spørre: Autorisasjons- og brukerflyt er ofte en hovedårsak til kompleksitet og risiko i slike løsninger, og må forstås før teamet kan prise riktig og levere riktig funksjonalitet.

   Kilde: SSA-B bilag 1 «Autentisering» og «Brukertyper» (Elevbruker/Voksenbruker/Admin)

7. Bilag 1 angir at administrator (ansatt i Statped) ikke skal ha tilgang til innhold opprettet av eller gjort tilgjengelig for elev-/voksenbrukere, og at administrator skal kunne administrere brukere og tilganger samt deaktivere/slette brukere og sørge for sletting av tilhørende innhold. Kan Statped presisere hvordan dette skal løses teknisk/regelmessig (f.eks. tilgang til metadata vs. innhold, og hvilke slettemønstre som skal støttes – «hard delete» vs. anonymisering), og hvilken dokumentasjon som forventes ved avslutning?

   Hvorfor det er verdt å spørre: Dette påvirker både informasjonssikkerhet, personvern og omfanget av design/implementasjon, og dermed leverandørens risiko og kostnad.

   Kilde: SSA-B bilag 1 «Brukertyper – Administrator»

8. Bilag 1 beskriver testing «regelmessig» under utviklingen, bruk av Statpeds fagpersoner, og avsluttende test når løsningen vurderes ferdig. Kan Statped angi et minimum av testomfang/acceptansekriterier (for eksempel type tester, regressjonsnivå, tilgjengelighetstester mot NVDA, og hva som regnes som «ferdig utviklet»)?

   Hvorfor det er verdt å spørre: Uklare acceptansekriterier kan føre til rework og uforutsigbarhet i sluttleveransen innen Q1 2027.

   Kilde: SSA-B bilag 1 «Testing av løsningen» (samt referansen til ferdigstillelse innen Q1 2027 i bilag 3)

9. I Bilag 3 ber Statped leverandøren angi fremdriftsplan og estimert prosentvis fordeling av tidsbruk per ressurs, og at det skal være «mest mulig selvgående» fra leverandøren. Kan Statped spesifisere forventet medvirkningsnivå i praksis (eksempelvis antall timer/rolle per uke til testing, avklaringer, og fagfokus), og hvordan dette vil bli fulgt opp/oppdatert i løpet av prosjektet?

   Hvorfor det er verdt å spørre: Tidsestimat og ressursallokering avhenger av faktisk medvirkning; uten klare forventninger blir tilbudsprising og planrisiko høy.

   Kilde: SSA-B bilag 3 «Konsulenten skal også redegjøre for forventet medvirkning…»

10. SSA-B (generell avtaletekst) punkt 2.4/5.2 og bilag 4 viser at nøkkelpersonell skal være navngitt og skifte må godkjennes. Kan Statped bekrefte hvilke avvik/utskiftningsrom som aksepteres i prosjektperioden (for eksempel ved sykdom/turnover), og om det er begrensninger knyttet til tidspunkt (før/etter milepæler) eller krav til erstatterens senioritet utover «minst tilsvarende»?

    Hvorfor det er verdt å spørre: Krav til nøkkelpersonell og godkjenning ved utskiftning kan utgjøre betydelig kommersiell risiko ved drift i et utviklingsprosjekt.

    Kilde: SSA-B generell avtaletekst punkt 5.2 «Nøkkelpersonell» samt SSA-B bilag 4 «Ved utskiftning…»