ID-kort for adgang og pålogging til helseforetakene i Helse Vest

RFI (ikke-bindende) om tredjeparts enterprise supporttjenester for Microsoft-teknologier, som mulig erstatning/tillegg til Microsoft Unified Support. Formålet er å innhente markedsinformasjon om leveransemodeller, SLAs/SLOs, sikkerhet/compliance, overgang fra Unified Support, bærekraft og pris-/kommersielle modeller for en mulig senere anskaffelse. Kontrakts-/tildeling fastsettes ikke i RFI, men innspill kan brukes til å forbedre krav og kontraktstruktur.

• Leverandøren skal gi kort profil, eierskap, relevante sertifiseringer (f.eks. ISO 27001/27701, ISO 9001) og Microsoft-tilknytning/partnerstatus.

  Dokumentasjon: Strukturerte svar i henhold til RFI-oppdeling (A.1).

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A.1
• Leverandøren skal dokumentere erfaring med å levere enterprise Microsoft support for offentlig sektor i Norge/EEA, samt refererbare oppdrag av tilsvarende størrelse/kompleksitet.

  Dokumentasjon: Refererbare engasjementer beskrevet i henhold til A.2.

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A.2
• Leverandøren skal oppgi kapasitet for volumet denne forespørselen gjelder (capacity).

  Dokumentasjon: Kapasitetsbeskrivelse i henhold til A.3.

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A.3

• Svar skal leveres elektronisk via anskaffelsesportalen innen 28. august.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 8 Response Format and Submission
• Svar skal være på norsk eller engelsk.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 8
• Svar skal ikke overstige 20 sider ekskl. vedlegg.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 8
• Leverandøren skal svare strukturert etter forespurt oppbygning og nummerering som i punkt 7 i RFI.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 8
• Kommunikasjon skal skje via portalen som utsteder RFI; annen kommunikasjon med involverte i beslutninger er ikke tillatt.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 3 Communication

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

28.08.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Tredjeparts support skal dekke tjenesteområder som reaktiv support (incident/problem management, 24x7 og definerte SLAs per alvorlighetsgrad), proaktive tjenester, service/success management, mission-critical/major incident, developer/DevOps support samt overgang/onboarding fra Microsoft Unified Support.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 6 + punkt 7B.5
• Det skal beskrives støtte-/tjenestemodell, inkludert f.eks. follow-the-sun vs. regional, språkdekning (norsk/engelsk), bemanningsprofil og sikkerhetsklareringstilbud.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7B.4
• Det skal beskrives SLAs/SLOs for respons, restore og resolution per severity, samt målemetode, månedlig rapportering og service credits.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7B.6
• Det skal beskrives eskaleringsveier til Microsoft (når/hvordan), lead time og end-to-end ansvar, inkludert beskrivelser der eskalering ikke er nødvendig.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7B.7
• Sikkerhet/compliance: beskrivelse av saks-/ticket-håndtering og hvor data (tickets, logger, artifacts) lagres, subprosessors, tilgangskontroll og etterprøvbarhet/auditability.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7C.8
• Overgang og service readiness: foreslått overgangsplan fra Microsoft Unified (eller nåværende tilstand) med risikoer/avhengigheter og tiltak; inkl. kunnskapsfangst og runbook handover, samt ev. integrasjoner (SIEM/SOAR).Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7D.9
• Verktøy-/integrasjonsmuligheter: hva leverandøren har/kan integrere med (ITSM, monitoring, CMDB, Entra ID-identity, incident command tools).Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7D.10
• Bærekraft: hvordan tjenesten bidrar til klima/miljømål, samt foreslå målbare indikatorer som senere kan brukes i konkurranse (FOA § 7-9 og 30% default weighting med mindre alternativ begrunnes).Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7E.11
• Pris/kommersielle modeller: leverandøren skal beskrive indikative kommersielle modeller (f.eks. flat abonnement, incident-baserte, tiered SLA bands, eller hybrid), hva som er inkludert vs opsjonelt, og kostnadsdrivere/kostnadslevers.Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7F.12-13
• Vurdering av ytelsesinsentiver/straffer: forslag til performance incentives/penalties (service credits, gainshare).Kilde: RFI_Third_Party_Microsoft_support.pdf, punkt 7F.14

• Dokumentet er et ikke-bindende RFI; det finnes ingen fastsatte tildelingskriterier, kontraktvilkår eller ytelses-/prisdetaljer som del av en pågående konkurranse.
• Ingen konkrete minstekrav til sertifiseringer, kapasitet eller språk fremgår som absolutte kvalifikasjonskrav (kun at leverandøren skal gi informasjon).
• Ingen opplysninger i teksten om juridiske kontraktbestemmelser (f.eks. varighet, opsjoner, oppsigelse, erstatningsregime) utover at det kan komme en formell anskaffelse senere.

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 punkt 2 fremgår det at konkurransen/anskaffelsen kan omfatte de fire regionale helseforetakene «enten direkte eller gjennom» et separat heleid servicesenter. Kan dere presisere hvilke av kundene (og ev. hvilke avdelinger innen kundene) som skal være faktiske kontraktparter og som skal motta tjenesteleveransen?

   Hvorfor det er verdt å spørre: Leverandøren må forstå hvem som er kontrakts- og brukersteder for å prise riktig (inkl. SLA-håndtering, rapportering og governance).

   Kilde: RFI pkt. 2 (Contracting Authorities), Appendix A

2. Punkt 5 og Appendix B beskriver «indikativt» Microsoft-miljø og lisenser/tjenester. Kan dere angi om tredjepartsupporten skal dekke alle produktene i Appendix B, og i så fall bekrefte om det finnes et avgrenset «tårn-/produktsett» som faktisk inngår i en fremtidig anskaffelse?

   Hvorfor det er verdt å spørre: Pris og tjenestekatalog avhenger av nøyaktig hvilke produkter og volum/omfang som skal støttes.

   Kilde: RFI pkt. 5 og pkt. 6 samt Appendix B

3. I punkt 6 listes tjenesteområder (reaktiv, proaktiv, service/success management, mission critical/major incident, developer/DevOps, transition/onboarding). Kan dere bekrefte hvilke av disse områdene som typisk vil bli ansett som «must have» i en eventuell senere konkurranse, og hvilke som kan bli «opsjonelle»?

   Hvorfor det er verdt å spørre: Leverandøren trenger forventet vekt/obligatorisk omfang for å utvikle et kostnads- og leveranseoppsett som matcher forventet etterspørsel.

   Kilde: RFI pkt. 6 (Indicative Scope of Third‑Party Support Services)

4. Punkt 6 og pkt. B.6–B.7 ber leverandøren beskrive SLAs/SLOs per alvorlighetsgrad (response, restore, resolution), målemetode, månedsrapportering og service credits, samt eskalering til Microsoft. Kan dere gi deres ønskede «severity»-definisjoner (f.eks. nivå 1–4) og hvordan dere i dag måler/klassifiserer saker?

   Hvorfor det er verdt å spørre: Uten felles severity-ramme blir det vanskelig å gi riktige SLA-tall og sammenlignbar rapportering.

   Kilde: RFI pkt. B (6. SLAs/SLOs) og (7. Escalation pathways)

5. I pkt. B.4 ber dere om språkdekning (norsk/engelsk), follow-the-sun vs. regional dekning og sikkerhetsklarering. Kan dere presisere hvilke deler av supporten som må kunne leveres på norsk, og hvilke former for sikkerhetsklarering dere forventer (om noen), samt om leverandørens personell må ha klarering før oppstart eller om det er aksept for gradvis tilgang?

   Hvorfor det er verdt å spørre: Språk- og klareringskrav kan påvirke bemanning, oppstartstid og kostnader betydelig.

   Kilde: RFI pkt. B.4 (Service model and coverage), pkt. B.8 (transition kan også påvirkes)

6. I pkt. C.8 ber dere beskrive hvor tickets/logs/artifacts lagres, subprosessorer, tilgangskontroll og auditabilitet. Kan dere spesifisere hvilke krav dere forventer til datalagring/residens (f.eks. Norge/EØS eller konkrete skyplattformer), og om dere har konkrete krav til logging/retain-tider og revisjonsformat som bør legges til grunn?

   Hvorfor det er verdt å spørre: Dataplassering og auditabilitet er ofte styrende for teknisk løsning og kostnadsdrivere (inkl. underleverandører).

   Kilde: RFI pkt. C (Security, compliance & data protection), punkt 8

7. I pkt. D.10 ber dere om verktøy-/integrasjonsmuligheter (ITSM, monitoring, CMDB, Entra ID, incident command tools). Hvilket ITSM- og overvåkingsverktøy brukes i dag i kundens miljø (navn på systemer), og er det et spesifikt CMDB- / katalogoppsett dere ønsker integrasjon mot?

   Hvorfor det er verdt å spørre: Integrasjonsarkitektur og innsats avhenger av dagens verktøykjede og datamodell.

   Kilde: RFI pkt. D.10 (Tooling integration already available)

8. I pkt. D.9 ber dere om overgangsplan fra Microsoft Unified Support med risiko/avhengigheter/mitigering (bl.a. kunnskapsfangst, SIEM/SOAR-integrasjon, runbook handover). Kan dere beskrive hvilke eksisterende SIEM/SOAR-løsninger og eventuelt SOC-prosesser dere bruker i dag, slik at leverandørene kan vurdere integrasjons- og overdragelsesbehov?

   Hvorfor det er verdt å spørre: Krav til SIEM/SOAR og runbook-handover påvirker både leveransemassasje og kostnader.

   Kilde: RFI pkt. D.9 (Proposed transition plan…)

9. I pkt. F.12–F.13 ber dere om pris- og kommersielle modeller og kostnadsdrivere (volum, omfangstårn, timer, dekning, dedikerte ingeniører, mission critical). Kan dere opplyse om et forventet omfangs-/volumanslag (f.eks. antall brukere/tenants, ca. antall saker per måned og historiske toppperioder) som dere vil legge til grunn i en eventuell senere prising?

   Hvorfor det er verdt å spørre: Uten historisk volumutgangspunkt blir det vanskelig å gi riktig prisegrunnlag og sammenlignbare tilbud.

   Kilde: RFI pkt. F (Pricing approach), særlig 12–13

10. Punkt 8 sier at RFI-svar sendes inn via portal innen «28th of August». Kan dere bekrefte om dette gjelder et bestemt år og hvilken tidszone (CET/CEST/UTC) som fristen følger, og om det er lov å levere korte «foreløpige» svar for deler av punktlisten dersom leverandøren ikke kan komplett besvare alt?

    Hvorfor det er verdt å spørre: Leverandøren må sikre korrekt innlevering og risiko for avvisning/diskvalifikasjon knyttet til frist og formatpraksis.

    Kilde: RFI pkt. 8 (Response Format and Submission)