Pasientvarmetepper til helseforetakene i Helse Vest

RFI (ikke-bindende markedsdialog) om tredjeparts enterprise-support for Microsoft-teknologier som kan erstatte eller supplere Microsoft Unified Support. Omfatter bl.a. reaktiv og proaktiv støtte, service/success management, mission-critical støtte, developer/DevOps støtte samt overgang/ onboarding fra Microsoft Unified. Forespørselen retter seg mot fire regionale helseforetak, ledet av Sykehusinnkjøp HF, og innhenter informasjon om leverandørens kapabiliteter, tjenestemodeller, SLA/SLOer, sikkerhet/compliance, overgangsplan, bærekraft og prismodeller.

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

  Dokumentasjon: Struktureres i leverandørens svar (ikke angitt egen vedleggsform).

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A(1)
• Leverandøren skal dokumentere erfaring med enterprise Microsoft-support for offentlig sektor i Norge/EEA, inkludert refererbare oppdrag av sammenlignbar størrelse/kompleksitet.

  Dokumentasjon: Refererbare engagements/oppdrag oppgis i svaret.

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A(2)
• Leverandøren skal oppgi kapasitet i forhold til volumet i denne forespørselen.

  Dokumentasjon: Kapasitetsbeskrivelse i svaret.

  Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7A(3)

• Svar skal leveres elektronisk via anskaffelses-/innkjøpsportalen som utsteder RFI.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 3 og 8
• Frist for innsending: 28. august.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 8
• Svar skal være på norsk eller engelsk.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 8
• Svarets lengde skal ikke overstige 20 sider, ekskl. vedlegg/appendices.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 8
• Svar skal være strukturert og presist, med struktur og nummerering som tilsvarer punkt 7 i RFI (A–G).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 8 og punkt 7

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

31.08.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Tjenesteområder etterspurt: reaktiv support (incident/problem, 24x7, definerte SLAs per alvorlighetsgrad), proaktive tjenester (health checks/assessments/optimization/advisory), service and success management, mission-critical/major incident support, samt developer/DevOps support.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 6
• Leverandøren skal beskrive støttemodell inkl. follow-the-sun vs regional, språkdekning (inkl. norsk/engelsk), bemanningsprofil, og muligheter for sikkerhetsklareringer.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7B(4)
• Leverandøren skal levere et service catalog som er tilpasset 'towers' nevnt i (referanse) seksjon 5, og avklare hva som er inn/ut av scope (towers står ikke gjengitt i teksten her).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7B(5)
• Leverandøren skal oppgi SLAs/SLOs: response, restore og resolutionmål per severity; målemetode; månedlig rapportering; service credits.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7B(6)
• Leverandøren skal beskrive eskaleringsløp til Microsoft (hvis relevant): når/hvordan, lead time og end-to-end accountability, samt beskrive metoder når eskalering ikke er nødvendig pga. in-house ekspertise.Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7B(7)
• Sikkerhet/compliance: beskrivelse av saksbehandling og dataresidens (hvor billetter/logg/artifakter lagres), underleverandører, tilgangskontroll og revisjonsevne (auditability).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7C(8)
• Overgang/onboarding: foreslå overgangsplan fra Microsoft Unified (eller nåværende tilstand) med risikoer, avhengigheter og tiltak (knowledge capture, SIEM/SOAR-integrasjon, runbook handover).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7D(9)
• Verktøyintegrasjoner: angi hvilke som finnes (ITSM, monitoring, CMDB, Entra ID, incident command tools).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7D(10)
• Bærekraft: hvordan tjenesten bidrar til klima/miljømål, og forslag til målbare indikatorer til senere konkurranse (inkl. referanse til FOA § 7-9 og mulig 30% standardvekt).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7E(11)
• Pris: beskrive kommersielle modeller (flat subscription, incidentbasert, SLA-bånd, hybrid), hva som inngår vs opsjonelt, samt kostdrivere og ev. insentiv-/straffemekanismer (service credits, gainshare).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7F(12)-(14)
• Verdiskaping/differensiering: eksempler på bedre utfall/fastere respons/lower TCO vs. Microsoft Unified (anonymiserte metrikker om mulig).Kilde: RFI_Third_Party_Microsoft_Support.pdf, punkt 7G(15)

• Tildelingskriterier og vekting er ikke oppgitt, fordi dette er en RFI uten påfølgende konkurransekrav i dokumentet.
• «Towers» nevnes som referanse (seksjon 5), men seksjon 5 inngår ikke i den gjengitte teksten her, så scope-/tower-oversikten er ikke tilgjengelig.
• Ingen konkrete juridiske/kontraktsmessige forpliktelser (særlige kontraktsvilkår) er oppgitt i utdraget; dokumentet er ikke-bindende og sier at det kan bli en senere anskaffelse.
• SLA-/SLO-målnivåer er etterspurt, men faktiske kravsnivåer (minimumskrav) er ikke oppgitt i teksten; leverandøren skal foreslå/oppgi egne mål og målemetoder.

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 6 «Indikative scope» ber dere om «defined SLAs per severity» for reaktive tjenester. Hvilke konkrete severitetsnivåer (f.eks. P1–P4) ønsker dere at tilbyderne skal legge til grunn, og hvordan defineres «incident», «problem» og «major/missions-critical» i denne anskaffelsen?

   Hvorfor det er verdt å spørre: For å kunne prise riktig må tilbyderne vite hva som ligger i severitet og hendelsestyper som påvirker responstid, bemanning og støtteprosesser.

   Kilde: 1.6 «Indicative Scope of Third‑Party Support Services» (Reactive support og major incident support)

2. I punkt 7 «Service catalog aligned to the towers in section 5»: Kan dere bekrefte hva som ligger i «towers in section 5» (selve tower-oversikten/kravstrukturen), og eventuelt dele relevant tabell/vedlegg slik at tilbyderne kan avgjøre in/out of scope per tower?

   Hvorfor det er verdt å spørre: Uten tilgjengelig tower-inndeling er det vanskelig å strukturere tilbudet korrekt og prise riktig dekningsgrad per delområde.

   Kilde: 7 (pkt. 5/6) «Requested from Suppliers» punkt 5 «Service catalog aligned to the towers in section 5»

3. I punkt 7A (pkt. B3) ber dere om «Capacity with respect to the volume of this request». Kan dere oppgi et volumestimat dere ønsker at tilbyderne skal prise mot (f.eks. forventet antall tickets per måned/år, andel P1/P2, og eventuelt antall miljøer/tenant(er))? Hvis dere ikke har konkrete tall, hvilke nøkkelantakelser ønsker dere at vi skal bruke?

   Hvorfor det er verdt å spørre: Supportvolum er en sentral kostdriver for 24x7, eskalering og bemanning, og tilbyderne trenger et felles prismessig referansenivå.

   Kilde: 7 «Requested from Suppliers» (A. Company & capability overview, punkt 3) «Capacity with respect to the volume of this request»

4. I punkt 7B (pkt. 4) ber dere om «language coverage incl. Norwegian/English» og sikkerhetsklarering. Hvilke språkkrav vil bli lagt til grunn (f.eks. krav om norsk i alle kanaler eller kun ved visse severiteter), og hvilke typer sikkerhetsklareringer/tilganger forventer dere at leverandøren skal kunne stille til rådighet?

   Hvorfor det er verdt å spørre: Språk og klarerings-/tilgangskapasitet påvirker bemanning og leveransemodell, og må avklares før leverandør priser og tilbyr riktig organisering.

   Kilde: 7 «Requested from Suppliers» (B. Service model and coverage, punkt 4)

5. I punkt 7B (pkt. 6) ber dere om «SLAs/SLOs: response, restore, and resolution targets per severity; measurement method; monthly reporting; service credits». Hvilke målverdier forventer dere som minimum/«baseline» i en fremtidig anskaffelse (dersom dere har interne forventninger), og hvordan ønsker dere at «measurement method» skal dokumenteres (f.eks. ITSM-metrikker, definisjoner for start/stopp)?

   Hvorfor det er verdt å spørre: Dere ber om at tilbyderne skal foreslå SLAs, men leverandørene trenger å vite om det finnes interne minimumsforventninger og hvilke målepunkter som faktisk vil evalueres.

   Kilde: 7 «Requested from Suppliers» (B. Service model and coverage, punkt 6)

6. I punkt 7B (pkt. 7) ber dere om eskalering «to Microsoft Unified/Premier on our behalf» med «lead time and accountability model end to end». Forventer dere at leverandøren skal ha en egen modell/avtale for å eskalere til Microsoft (herunder eventuelle kostnader), eller er dette ment som en beskrivelse av leverandørens prosess uten at dere påfører oss Microsoft-relaterte kostnader?

   Hvorfor det er verdt å spørre: Det påvirker både pris og risiko (f.eks. hvem bærer evt. Microsoft-eskaleringskostnader og hva som er leverandørens faktiske forpliktelser).

   Kilde: 7 «Requested from Suppliers» (B. Service model and coverage, punkt 7)

7. I punkt 7C (pkt. 8) ber dere om «where tickets, logs, and artifacts are stored; sub processors; access control; auditability» og dataresidens. Har dere preferanser eller konkrete krav til datalagring (f.eks. Norge/EØS, eventuelle regioner) og hvilke minimumskrav stilles til underleverandører/sub-processors?

   Hvorfor det er verdt å spørre: For å kunne vurdere compliance og prise riktig (konfigurasjon, kontrolltiltak og ev. kostnader) må leverandøren kjenne til forventede føringer for dataresident og subprosessorstyring.

   Kilde: 7 «Requested from Suppliers» (C. Security, compliance & data protection, punkt 8)

8. I punkt 7D (pkt. 9–10) ber dere om «transition plan» og om verktøyintegrasjon (ITSM, monitoring, CMDB, Entra ID, incident command tools). Kan dere beskrive hvilke ITSM-/monitoreringsverktøy og integrasjoner dere i dag bruker (nåværende tooling/versjoner), og hvilke integrasjonspunkter som er «must have» i overgangsperioden?

   Hvorfor det er verdt å spørre: Overgang og integrasjoner er typiske kostnadsdrivere og risikoområder; leverandøren trenger å vite dagens verktøykjede for å foreslå en realistisk plan og riktig ressursbruk.

   Kilde: 7 «Requested from Suppliers» (D. Transition and service readiness, punkt 9 og 10)

9. I punkt 7E (pkt. 11) ber dere tilby «measurable indicators» for klima/miljø og nevner «30% default weighting unless well justified alternatives». Kan dere bekrefte om 30% vekting faktisk gjelder i den kommende konkurransen (dersom dere går videre), og hvilke datakrav dere forventer at leverandøren skal kunne dokumentere (f.eks. baseline, metodikk for travel reduction/near shoring, rapporteringsfrekvens)?

   Hvorfor det er verdt å spørre: Miljøvekting og dokumentasjonskrav påvirker leverandørens tilbudte metrikker, rapporteringsrutiner og kostnadsbilde.

   Kilde: 7 «Requested from Suppliers» (E. Sustainability and social responsibility, punkt 11)

10. I punkt 7F (pkt. 12–13) ber dere om prising (flat abonnement, incident-basert, SLA-bands, hybrid) og «cost drivers» knyttet til «scope towers». Hvis dere ikke har endelig volum/tower-omfang i denne fasen, kan dere angi hvilke prismessige komponenter dere forventer at leverandørene skal gi separate priser på (f.eks. per tower, per dekningsvindu, 24x7/9x5, mission-critical add-on)?

    Hvorfor det er verdt å spørre: For å sammenligne tilbud og for å kunne gi konsistente enhetspriser trenger leverandøren å forstå hvilke prismodul-komponenter som vil etterspørres.

    Kilde: 7 «Requested from Suppliers» (F. Pricing approach, punkt 12 og 13)