Bronkoskopi forbruksmateriell til helseforetakene i Helse Vest

RFI (ikke-bindende markedsdialog) om tredjeparts enterprise support for Microsoft-teknologier som kan erstatte eller supplere Microsoft Unified Support for fire regionale helseforetak i Norge (via Sykehusinnkjøp HF som prosessleder). Leverandører bes om strukturerte svar om kompetanse, tjenestemodell/SLAer, sikkerhet og compliance, overgang/overlevering fra Unified Support, bærekraft, og prismodeller. Svarfrist 28. august via anskaffelsesportalen; svar maks 20 sider ekskl. vedlegg.

• Kort profil, eierskap, relevante sertifiseringer (f.eks. ISO 27001/27701, ISO 9001) og Microsoft designasjoner/partnerstatus.

  Dokumentasjon: Strukturerte svar i henhold til RFI-omfang; leverandørens egen dokumentasjon av sertifiseringer/partnerstatus.

  Kilde: RFI, punkt A.1 (Company & capability overview)
• Erfaring med levering av enterprise Microsoft support for offentlig sektor i Norge/EEA, og refererbare oppdrag med sammenlignbar størrelse/kompleksitet.

  Dokumentasjon: Beskrivelse av relevante referanseoppdrag.

  Kilde: RFI, punkt A.2 (Company & capability overview)
• Kapasitet med hensyn til volumet av denne forespørselen.

  Dokumentasjon: Opplysninger om kapasitet (bemanning/volum).

  Kilde: RFI, punkt A.3 (Company & capability overview)

• Svar skal leveres elektronisk via anskaffelsesportalen som utsteder RFI-et innen 28. august.Kilde: RFI, punkt 8 (Response Format and Submission)
• Svar skal være på norsk eller engelsk.Kilde: RFI, punkt 8 (Response Format and Submission)
• Svar skal ikke overstige 20 sider ekskl. vedlegg.Kilde: RFI, punkt 8 (Response Format and Submission)
• Svar bør følge struktur og nummerering tilsvarende seksjon 7 i RFI-et, og gis kort og presist.Kilde: RFI, punkt 8 (Response Format and Submission)
• Kommunikasjon skal skje via innkjøpsportalen; annen kontakt med beslutningstakere er ikke tillatt.Kilde: RFI, punkt 3 (Communication)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

24.08.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Tjenesteområder det ønskes info om: reaktiv støtte (hendelse/problemhåndtering, 24x7 tilgjengelighet, definerte SLAer per alvorlighetsgrad), proaktive tjenester (helse-/vurdering/optimalisering/rådgivning), service- og suksessledelse (named service manager, rapportering, governance), støtte ved mission-critical og større hendelser, samt utvikler/DevOps-støtte og overgang/onboarding fra Microsoft Unified Support.Kilde: RFI, punkt 6 (Indicative Scope) + punkt 5/6
• Leverandør bes om å beskrive SLA/SLO-mål: responstid, gjenoppretting og løsningsmål per alvorlighetsgrad, målemetode, månedlig rapportering og service credits; samt rapportering.Kilde: RFI, punkt B.6 (SLAs/SLOs)
• Leverandør bes om å beskrive sikkerhet, compliance og databeskyttelse: hvor tickets/logs/artefakter lagres, sub-prosessorer, tilgangskontroll og revisjonsevne.Kilde: RFI, punkt C.8 (Security, compliance & data protection)
• Leverandør bes om å beskrive overgangsplan fra Microsoft Unified (eller nåværende situasjon), inkludert risikoer, avhengigheter og tiltak, samt kunnskapsfangst og runbook handover (inkl. f.eks. SIEM/SOAR-integrasjon nevnt).Kilde: RFI, punkt D.9 (Transition and service readiness)
• Leverandør bes om å beskrive eksisterende verktøy-/integrasjonsmuligheter: ITSM (f.eks. ServiceNow), overvåking, CMDB, identitet (Entra ID), og incident command tools.Kilde: RFI, punkt D.10 (Tooling integration)
• Bærekraft: leverandøren bes om å beskrive hvordan tjenesten bidrar til klima-/miljømål og hvilke målbare indikatorer som kan brukes i en senere konkurranse (30% standard vekting dersom ikke begrunnet alternativt).Kilde: RFI, punkt E.11 (Sustainability and social responsibility)
• Prising: leverandør bes om å foreslå kommersielle modeller (flat abonnement, incident-basert, SLA-bånd eller hybrid), hva som er inkludert vs. opsjonelt, kostdrivere og forslag til ytelsesinsentiver/straff (service credits/gainshare).Kilde: RFI, punkt F.12-F.14 (Pricing approach)

• Dokumentteksten inneholder ikke kontraktsutkast, faktiske tildelingskriterier eller vektede scoringparametere (RFI er markedsdialog uten anskaffelsesprosedyre i denne fasen).
• Det fremgår ikke eksplisitt hvilke konkrete SLA-nivåer som kreves; kun at leverandørene skal oppgi respon/rest/resolve-mål og rapportering per alvorlighetsgrad.
• Appendix B lister Microsoft produkter/SKUs, men ingen direkte kobling til krav/opsummerte leveranseforpliktelser i RFI-teksten.
• Det gis ikke volumtall/antall brukere/tjenestepakker/avtaletid i teksten; kun at leverandørene skal kommentere kapasitet.

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. Hvilke Microsoft “towers” (f.eks. reaktiv support, proaktiv, mission critical, developer/DevOps, transition/onboarding) ønsker dere at tilbudene skal prises og struktureres etter, og finnes det en matrise/kravspesifikasjon som angir hvilke konkrete tjenester som inngår i hver tower?

   Hvorfor det er verdt å spørre: RFI ber om service catalog aligned to towers og pris-/kostdrivere, men uten en konkret definisjon av tower-inndeling. Leverandøren trenger presis taksonomi for å prise riktig og gi konsistente svar.

   Kilde: RFI – “Service model and coverage” punkt 5 og “F. Pricing approach” punkt 13

2. Kan dere bekrefte hvilke SLAs/SLOs som dere forventer at leverandørene skal oppgi per alvorlighetsgrad (response, restore, resolution): hvilke severity-nivåer skal brukes (f.eks. Sev1/Sev2/Sev3/Sev4) og om dere har foretrukket tidsenheter og definisjoner (når starter klokken, og hva regnes som “restore” vs “resolution”)?

   Hvorfor det er verdt å spørre: RFI antyder at SLAs skal oppgis, men uten konkrete severity-definisjoner og målepunkter. Dette er avgjørende for korrekt tilbudsprising og sammenlignbarhet.

   Kilde: RFI – “SLAs/SLOs” punkt 6

3. Når dere ber om “measurement method” og “monthly reporting” knyttet til SLA/SLO, hvordan ønsker dere at rapporteringen skal gjøres (f.eks. dashboard/CSV/ITSM-rapport), og hvilke minimumsmål forventes (tilgjengelighet, MA time to respond, % innen mål, backlog, trend)?

   Hvorfor det er verdt å spørre: Utydelig rapporteringskrav kan gi store kostnadsavvik. Leverandøren må vite hva dere forventer av måle-/rapporteringsleveranse.

   Kilde: RFI – “SLAs/SLOs” punkt 6

4. Når dere beskriver “escalation pathways to Microsoft”, gjelder kravet både der dere ønsker at leverandøren selv eskalerer og der dere (kunden) har in-house kompetanse: hvem har endelig eierskap og ansvar fra start til slutt, og er det forventet at leverandøren tar kostnad/ledetid ved eventuell Microsoft-kontakt?

   Hvorfor det er verdt å spørre: Ansvars- og kostnadsdeling ved eskalering påvirker risikobildet og prisingen av leveransemodell.

   Kilde: RFI – “Escalation pathways to Microsoft” punkt 7

5. Kan dere utdype hvordan dere ser for dere “Transition and onboarding from Microsoft Unified” (prioritertrekk): hvilke aktiviteter forventes levert av third party (f.eks. knowledge capture, runbook handover, integrasjoner, opplæring), og hvilke leveranser ønsker dere beskrevet som minimum for at overgangen skal anses “service ready”?

   Hvorfor det er verdt å spørre: Transition punkt 9 er tematisk, men uten klare leveranse-/milepælskriterier. Leverandøren trenger dette for å dimensjonere bemanning og kostnader.

   Kilde: RFI – “Transition and service readiness” punkt 9

6. Hvilke databehandler-/sikkerhetsforventninger vil dere mest sannsynlig legge til grunn i et framtidig kontraktsutkast for: (1) hvor case tickets/logs/artifacts lagres, (2) hvilke sub processors som kan benyttes, og (3) krav til tilgangskontroll og auditability for Helseforetakene?

   Hvorfor det er verdt å spørre: RFI punkt 8 ber om informasjon, men leverandøren trenger å forstå hvilke sikkerhets-/compliance forventninger som faktisk styrer kravene i en kommende anskaffelse.

   Kilde: RFI – “Security, compliance & data protection” punkt 8

7. Er det forventet at leverandøren leverer “security clearance options” og eventuelt hvilke nivåer dere legger til grunn (og for hvilke roller/funksjoner), samt om dette skal gjelde for både Norge og ev. “follow the sun” bemanning?

   Hvorfor det er verdt å spørre: Krav til klarering og rolleomfang kan påvirke bemanningsmodell og leveringskost. Leverandøren må avklare om sikkerhetsklarering er en forutsetning i fremtidig kontrakt.

   Kilde: RFI – “Description of support model” punkt 4

8. Når dere ber om kapasitet “with respect to the volume of this request”, har dere et forventet volumgrunnlag dere kan dele på et aggregert nivå (f.eks. antall brukere, antall samtidige tickets, forventet ticket-rate per måned, og andel mission critical), selv om dette er en RFI?

   Hvorfor det er verdt å spørre: Uten volum og arbeidsbelastning er det vanskelig å prise 24x7, staffing, og responstider realistisk. Leverandøren bør be om aggregerte nøkkeltall for kostnadsberegning.

   Kilde: RFI – “Capacity with respect to the volume of this request” punkt B.3

9. Hvilke verktøy-/integrasjoner forventer dere at leverandøren skal ha standard støtte for ved oppstart (ITSM, monitoring, CMDB, Entra ID, incident command), og er det dere som stiller med eksisterende plattformer/tilkoblinger eller forventes det at leverandøren leverer integrasjonsarbeid?

   Hvorfor det er verdt å spørre: Punkt 10 lister verktøy, men sier ikke hvem som leverer/installerer og om det er forventet integrasjonsarbeid. Dette kan være en betydelig kostnadsdriver.

   Kilde: RFI – “Tooling integration” punkt 10

10. Kan dere bekrefte hvordan dere planlegger å bruke “sustainability and social responsibility” i en eventuell senere konkurranse (f.eks. om dere vil vektlegge 30% direkte som nevnt i RFI, og hvilke leveransekrav dere da vil stille for energi-/reise-/near-shoring-/emissionsindikatorer)?

    Hvorfor det er verdt å spørre: RFI nevner en mulig 30% default weighting uten kontrakts-/evalueringsdetaljer. Leverandøren trenger avklaring for å forstå hva som faktisk må dokumenteres for å konkurrere.

    Kilde: RFI – “Sustainability and social responsibility” punkt 11