KJØP AV STANDARDISERTE IT-TJENESTER

AHO skal anskaffe en primær IKT-driftspartner gjennom konkurranse med forhandlinger (SSA-D for løpende drift). Behovet er mer robust, sikker og bærekraftig drift av generisk IKT med profesjonell service management, bedre kompetanse/dokumentasjon og styrket sikkerhet/tilgjengelighet. AHO vil beholde strategisk styring, tjenesteeierskap, arkitekturpremisser, prioritering og brukeropplevelse, mens driftspartner har operativt ansvar innen avtalt RUN, koordinerer avhengigheter og leverer tekniske L2/L3-aktiviteter samt bidrar i kritiske perioder. Dokumentet understreker at Felles IAM/RapidIdentity er obligatorisk premiss, og at løsningen skal skille tydelig mellom RUN, CHANGE og større investeringer (særlig nettverk), samt ha fleksibilitet/exit, dataportabilitet og transparens i prismodellen.

• Leverandøren skal belyse tjenestemodell, arkitektur, ansvarsdeling og samhandling (inkl. ITSM/PureService eller alternativer), NaaS, sikkerhet, kritiske perioder, fleksibilitet og pris, samt hva leverandøren ville gjort annerledes enn AHOs foreløpige utgangspunkt.Kilde: Kapittel 18: Særskilte tema AHO ønsker belyst i forhandlingene
• Leverandøren skal presentere strukturert besvarelsesoppsett i fast struktur (del 1–10) for å sikre sammenlignbare tilbud, inklusive forslag til operasjonsmodell, tjenesteomfang per tjenesteområde, NaaS/lokasjoner, ITSM/ESM og sikkerhet, kritiske perioder, prismodell og alternative anbefalinger.Kilde: Kapittel 18.1 Anbefalt struktur for leverandørens besvarelse
• Leverandøren skal eksplisitt identifisere områder der leverandøren anbefaler en annen tilnærming enn AHOs foreløpige utgangspunkt, og begrunne konsekvenser (kvalitet, sikkerhet, brukeropplevelse, oppetid, kostnad, risiko, fleksibilitet og exit).Kilde: Kapittel 18.2 Alternative anbefalinger fra leverandøren

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

30.09.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Felles IAM/RapidIdentity er obligatorisk sektorarkitektur og skal legges til grunn; leverandøren skal integrere og skal ikke foreslå alternativ IAM som erstatter Felles IAM.Kilde: Executive summary / Kapittel 8 IAM
• AHO skal ha én samlet og tydelig brukerinngang til IKT- og servicerelaterte henvendelser (støttemodell differensieres mellom ansatte/studenter/kritiske perioder), med service management-kapabilitet som sikrer saksflyt, historikk/dokumentasjon, konfidensielle saker, rapportering/dashboards, dataeierskap og exit.Kilde: Kapittel 9 Brukerstøtte og service management; Prinsipper P5–P6
• Kontrakten skal skille tydelig mellom RUN, CHANGE og større investeringer/etablering (særlig nettverk), og prisfaktorer for lokasjoner, kritiske perioder og exit skal kunne styres og sammenlignes.Kilde: Kapittel 3 Anskaffelsesform, forhandlinger og avtalestruktur; Kapittel 3.2 Prismal og kommersiell struktur
• Leverandøren skal beskrive og prise exit/bistand ved leverandørbytte, inkludert dataeksport, dokumentasjon, overføring til ny leverandør og eventuell overtakelse/videreleie/buyout av relevant utstyr/tjenestekomponenter.Kilde: Kapittel 3.2.1 Hovedprinsipper for prising (Exit) samt Kapittel 17 Fleksibilitet, exit
• Sikkerhetsleveranse skal være forankret i NSM grunnprinsipper og operasjonaliseres iht. ISO/IEC 27001/27002; leverandøren skal kunne etablere scope for overvåkning/deteksjon/respons, sårbarhetsstyring, hendelseshåndtering og samspill med Sikt/eduCSC.Kilde: Kapittel 7.8 Sikkerhet, SOC og beredskap (B7.8.1–B7.8.4); Prinsipp P6
• Restore-testing for kritiske tjenester ligger fast som prinsipp, med frekvens/omfang avklart i forhandlingene; scope og RPO/RTO skal konkretiseres for backup/DR.Kilde: Kapittel 7.9 Backup, kontinuitet og katastrofegjenoppretting (B7.9.1–B7.9.2)
• Universell utforming: brukerrettede flater i leveransen (f.eks. selvbetjenings-/servicedesk-portal) skal oppfylle gjeldende krav til universell utforming (WCAG).Kilde: Kapittel 14 Universell utforming (B14.1)
• AHO eier eller har ubegrenset bruks- og exitrett til dokumentasjon som beskriver AHOs miljø, konfigurasjoner, integrasjoner, tjenesteoppsett, runbooks, CMDB/asset-data og arkitektur for leveransen (med begrensning for proprietære metoder/forretningshemmeligheter mindre det er nødvendig for drift/kontroll/exit).Kilde: Kapittel 7.11 Tjenestekatalog, CMDB og dokumentasjon (B7.11.2)

• Dokumentet oppgir at detaljert kravspesifikasjon, servicenivåer og prismodell konkretiseres etter forhandlinger (endelige tilbud).
• Endelig volum/omfang er foreløpig: antall klienter (PC/Mac), system/tjenester, antall lokasjoner (midlertidige), og restomfang on-premise er ikke endelig bekreftet.
• Tjenestekatalog og CMDB/innholdsnivå (minimumskrav) beskrives som behov, men detaljer avklares i forhandlingene.
• Virksomhetsoverdragelse er foreløpig ikke lagt til grunn; juridisk/HR-faglig avklaring og endelig posisjon kan påvirke leveransemodell.
• Exact rolle-/grenseflater og ansvar for tredjepart/sector services (inkl. når partner skal koordinere vs kun informeres) må konkretiseres i forhandlingene.
• For sikkerhetsoperasjon (SOC/MDR/XDR) og endelig samspill/scope mot sektorleverandører (Sikt/eduCSC) er detaljnivå ikke fastsatt.
• Resttjenester ved avvikling/migrering av on-premise og tidsplan/kostnadsdeling er ikke endelig definert.
• Nettverksinvesteringer: modell for leasing/investering/amortisering/restverdi og konsekvenser ved lokasjonsendringer/exit må avklares i forhandlingene.

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. B3.1: Kan dere beskrive deres anbefalte modell for å skille og prise RUN (fast månedlig) versus CHANGE (separat), inkludert tydelige regler/terskler for hva som faktureres som henholdsvis RUN-endring og CHANGE?

   Hvorfor det er verdt å spørre: Leverandøren må forstå hvor kostnadsdrivere ligger (og unngå at løpende vedlikehold faktureres som “endringer”), for å kunne prise riktig og levere sammenlignbare tilbud.

   Kilde: 3.2.1 Hovedprinsipper for prising / B3.1 (RUN vs CHANGE) / 3.2.4 Særskilt om RUN/CHANGE-grense

2. B3.4: For å sikre transparens ved etablering, investeringer, amortisering/restverdi, opsjonsår og exit—hva er deres konkrete anbefaling for håndtering av nettverksinvesteringer (særlig investerings-/leasing-/buyout- eller videreleiemodell), og hvilke elementer må prises separat fra grunnperiodens RUN?

   Hvorfor det er verdt å spørre: Nettverk ser ut til å bli en stor kostnadsdriver. Leverandøren trenger et konkret kommersielt oppsett for restverdi/avskrivning, samt hvordan exit håndteres ved leverandørbytte.

   Kilde: B3.4 / 3.2.3 Særskilt om nettverksinvesteringer / 3.2 Hovedprinsipper for prising

3. B7.1.6: Hvordan anbefaler dere at M19 (planlagt avvikling okt. 2027) og Akersbakken (jan. 2029) håndteres i NaaS-kommersielt og operativt—inkludert hva som kan gjenbrukes, hva som bør avvikles, og hvordan pris justeres ved midlertidige lokaler eller endret arealbruk?

   Hvorfor det er verdt å spørre: Lokasjonsendringer påvirker både investeringsbehov og løpende drift. Leverandøren må prise fleksibelt og med realistiske forutsetninger om gjenbruk/restkost.

   Kilde: 7.1.6 (M19 og Akersbakken) / 3.2.1 Hovedprinsipp nr. 4 (lokasjoner) og nr. 7 (exit) / B17.7

4. B7.3.3 og B7.5.2: For studentenes BYOD—hvilke konkrete forventninger har dere til partnerens rolle og leveranse (f.eks. AHO-konto/tilgang, Feide, wifi/eduroam, lisenser, print/plott, samt veiledning/selvhjelp når brukere installerer fagprogramvare)? Og hva regnes som ren teknisk feil som partner skal ta, vs brukerfeil som skal håndteres via FAQ/opplæring?

   Hvorfor det er verdt å spørre: BYOD-delen påvirker både omfang, bemanning og kostnadsmodell for “selvhjelp vs partnerinvolvering”. Uten tydelig grense blir det vanskelig å prise support- og oppgavetyngde korrekt.

   Kilde: 7.3.3 (studentstøtte BYOD) og 7.5.2 (distribusjon/support + selvhjelp) / RACI kap. 9 (brukerstøtte)

5. B7.6.1: Kan dere spesifisere forventet ansvarsdeling for print/plott i kritiske perioder (hvem eier beslutning og plan—AHO, partner eller printleverandør; hvem utfører teknisk feilsøking; og hva er on-site/lokal støtte vs ekstern leverandørkoordinering), inkludert grenseflate mot Canon/andre tredjepartsleverandører?

   Hvorfor det er verdt å spørre: Print/plott er daglig bruk og kritisk ved diplom/eksamen. Leverandøren trenger tydelig grense for ansvar og arbeid som kan gi store kostnads- og leveranserisikoer.

   Kilde: 7.6.1 / RACI kap. 19.4 (Print/plott og AV/streaming) / 7.6 Print, plott og produksjonskritisk støtte

6. B7.8.2–B7.8.4: For sikkerhet (SOC/MDR/XDR) og hendelseshåndtering—hvordan ønsker dere at scope, respons og eskalering skal fordeles mellom AHO, primær driftspartner og sektor (Sikt/eduCSC)? Inkluder gjerne eksempler på hva partner gjør ved (1) identitets-/MFA/Conditional Access-feil, (2) nettverksavvik, og (3) hendelser i sky-/SaaS.

   Hvorfor det er verdt å spørre: Sikkerhetsscope og grenseflater mot sektorleverandører er avgjørende for både kapasitet, pris og risiko (feil forventningsstyring kan gi underbemanning eller “gratis” arbeid).

   Kilde: 7.8.2, 7.8.4 / 10. Styrings- og samhandlingsmodell / RACI kap. 19.1 Incident management

7. B7.9.1: Kan dere opplyse ønsket/realistisk RPO/RTO-nivåer for “kritiske tjenester” (og hvilke tjenester dere vil anse som kritiske), samt hvordan dere forventer at restore-testing faktisk skal gjennomføres og rapporteres (hvem utfører, hvem godkjenner, og hvilke dokumentasjonskrav gjelder)?

   Hvorfor det er verdt å spørre: Backup/DR er et område der leverandører må prise både teknologi, operasjon og testregime. Uten konkrete nivå og ansvar blir tilbudsprising og kapasitetsplan mer usikker.

   Kilde: 7.9.1–7.9.2 / RACI kap. 19.1 / B13.1–B13.2 (servicenivå og måling)

8. B9.3 og B9.4: Når en sak overføres mellom AHO, primær driftspartner og interne seksjoner—hva må bevares i praksis (f.eks. statusoverganger, vedlegg, kommunikasjon, konfidensialitet, auditlogg og historikk), og hvordan forventer dere at AHO får full eksport/exitrett til service management-data (formater, omfang og tidsbruk)?

   Hvorfor det er verdt å spørre: Dette påvirker valg av ITSM/ESM-modell og kostnader for migrasjon/exit, samt leverandørens kontroll på prosesser og dokumentasjon som er kritisk ved leverandørbytte.

   Kilde: 9.1 og B9.3–B9.4 / 3.2.2 Priskategori 11 (Service management/ITSM/ESM) og 12 (Exit)

9. B17.1 og B17.6: For exit—hvilke konkrete gjenstander skal dere ha ut i exit (innhold, konfigurasjoner, dokumentasjon, integrasjoner, CMDB/asset-data og tjenesteoppsett), og hvilke minimumsformat/kategorier forventes levert? Videre: hvordan ønsker dere at grunnperiode/opsjonsår settes opp kommersielt for å støtte exit ved leverandørbytte (kostnadsfri/ikke-kostnadsfri bistand, timepris eller fastpris)?

   Hvorfor det er verdt å spørre: Exit-krav påvirker både ressursbruk, planlegging og prising i opsjonsår. Leverandøren trenger et operasjonelt og kommersielt målbilde for å levere realistiske kostnader.

   Kilde: 17.1, 17.6 / 3.2.2 Priskategori 12 (Exit og leverandørbytte) og 13 (Opsjonsår) / B7.11.2

10. B16.3: Overgangen skal håndteres mens AHO samtidig gjennomfører andre endringer—hvilke typer endringer anser dere som “ikke påvirker ordinær drift” (og hvilke unntak aksepteres), og hvordan vil dere konkret vurdere endringsfrys/minimumsendringer i overgangsperioden?

    Hvorfor det er verdt å spørre: Overgang/risko er ofte største usikkerhetsdriver. Leverandøren trenger tydelig styringspraksis for endringsomfang for å planlegge bemanning, hypercare og faseplan uten å ta uforutsett risiko.

    Kilde: 16. Overgang, implementering og opplæring / B16.1–B16.3

11. B13.2: Hvilke måleparametere ønsker dere å bruke for SLA/SLO og hvilke type konsekvenser/servicekreditter er aktuelle ved brudd for de mest kritiske tjenestene (NaaS, print/plott i kritiske perioder, AV/streaming, restore-test)?

    Hvorfor det er verdt å spørre: Leverandøren må forstå konsekvenslogikken og målehierarkiet for å kunne dimensjonere leveranse og prise risiko riktig.

    Kilde: 13. Servicenivå - behov og rammer / B13.1–B13.2 / B7.5–B7.10 (relevante tjenesteområder)