Anbudsradar
Kunngjøring av konkurranse · 2026-111363

Stasebånd til Helse Vest

OppdragsgiverSYKEHUSINNKJØP HF

Frist 19.08.2026

Oppdragsgiver
SYKEHUSINNKJØP HF
Frist
19.08.2026
Publisert
29.06.2026
Utførelsessted
Vestland (NO0A2), Norge
Dokumentportal
IVALUA

Spør om konkurransedokumentene

Still spørsmål om innholdet i konkurransedokumentene og få svar med kildehenvisning — uten å lese alle dokumentene selv. AI-svar kan inneholde feil; originaldokumentene gjelder alltid.

Bør du se nærmere på denne konkurransen?

  • Stasebånd til Helse Vest: utførelsessted Vestland (NO0A2), Norge.
  • Kvalifikasjon: Leverandør skal gi kort profil, eierskap, relevante sertifiseringer (f.eks. ISO 27001/27701, ISO 9001) samt Microsoft designasjoner/partnerstatus.
  • Innlevering: Svar skal leveres elektronisk via anskaffelsesportalen som utsteder RFI-et.
  • Særlig å merke seg: Tjenesteområder som det forventes/ønskes informasjon om: reaktiv support (incident/problem management, 24x7, definerte SLAs per alvorlighetsgrad), proaktive tjenester, service- og success management, mission critical/major incident support, developer/DevOps support, samt overgang/onboarding fra Microsoft Unified Support.

Om oppdraget

Helse Vest skal inngå rammeavtale på Stasebånd til venøs prøvetaking. Estimert antall produkter på avtalen er 57200 stk.

Tjenesteområde

  • Laboratorieutstyr, optisk, presisjon 38000000

Tilbudsstrategi

  • Sjekk tidlig at kvalifikasjonskravene kan dokumenteres uten etterslep.
  • Gå gjennom kontrollpunktene i originaldokumentene før det brukes mye tid på tilbudet.

Historikk hos oppdragsgiver

Basert på strukturerte tildelingskunngjøringer i Anbudsradar. Listen kan være ufullstendig der eldre kunngjøringer mangler leverandørdata.

Se full oppdragsgiverprofil for SYKEHUSINNKJØP HF

Tidligere tildelinger med samme CPV-kode

Leverandører oppdragsgiver ofte har tildelt kontrakter til

Vis alle leverandører

Beriket informasjon fra konkurransedokumentene

AI-basert uttrekk fra konkurransedokumentene. Kontroller alltid originaldokumentene før tilbud leveres.

Oppdragssammendrag fra dokumentene

RFI (ikke-bindende markedsdialog) om tredjeparts enterprise supporttjenester for Microsoft-teknologier, som kan erstatte eller supplere Microsoft Unified Support for fire regionale helseforetak (eventuelt via Sykehusinnkjøp HF). Formål er å innhente informasjon om leveransemodeller, SLAs/SLOs, sikkerhet/compliance, overgang fra dagens Microsoft-support, bærekraft og pris-/kommersiell modell. Eventuell senere anskaffelse kan følge.

Emneknagger
RFIMicrosoft Unified Supporttredjeparts supportSLAs og SLOssikkerhet og complianceovergang og onboardingbærekraft og miljøpris- og forretningsmodeller
Dette må kontrolleres i originaldokumentene
  • Dokumentet inneholder ikke konkrete tildelingskriterier eller vekting, ettersom dette er en RFI (forberedende markedstiltak).
  • Det fremgår ikke i teksten hvor mange/ hvilke konkrete Microsoft-lisens-/produktkomponenter som inngår i et fremtidig omfang utover at miljøet er «indicative» og at liste over tjenester/produkter er vedlagt som Appendix B.
  • Ingen konkrete krav til obligatoriske dokumentasjonstyper (bevis/attester) er spesifisert utover at leverandører skal svare strukturert på spørsmålene 1-16.
Kvalifikasjonskrav
  • Leverandør skal gi kort profil, eierskap, relevante sertifiseringer (f.eks. ISO 27001/27701, ISO 9001) samt Microsoft designasjoner/partnerstatus.

    Skriftlig beskrivelse av profil, eierskap, sertifiseringer og Microsoft partnerstatus.

    RFI, punkt 7. "Requested from Suppliers" A. Company & capability overview (1)
  • Leverandør skal dokumentere erfaring med å levere enterprise Microsoft support for offentlig sektor i Norge/EEA, inkludert refererbare oppdrag av tilsvarende størrelse/kompleksitet.

    Refererbare engasjementer med størrelse/kompleksitetsbeskrivelse.

    RFI, punkt 7 A (2)
  • Leverandør skal beskrive kapasitet med hensyn til volumet av forespørselen.

    Beskrivelse av kapasitet/ressurser for å håndtere forespurt omfang.

    RFI, punkt 7 A (3)
Innleveringskrav
  • Svar skal leveres elektronisk via anskaffelsesportalen som utsteder RFI-et.RFI, punkt 3 "Communication" (all communication via procurement portal) og punkt 8 "Response Format and Submission" (submit via procurement portal)
  • Frist for innlevering: 28. august.RFI, punkt 8
  • Svar skal skrives på norsk eller engelsk.RFI, punkt 8
  • Svar skal ikke overstige 20 sider ekskl. vedlegg.RFI, punkt 8
  • Svar skal være strukturert og nummerert i tråd med tema/sekvens i RFI-en (Section 7: A-G, spørsmål 1-16), med kort og presis besvarelse.RFI, punkt 8 og punkt 7 "Requested from Suppliers"
Viktige kontraktskrav
  • Tjenesteområder som det forventes/ønskes informasjon om: reaktiv support (incident/problem management, 24x7, definerte SLAs per alvorlighetsgrad), proaktive tjenester, service- og success management, mission critical/major incident support, developer/DevOps support, samt overgang/onboarding fra Microsoft Unified Support.RFI, punkt 6 "Indicative Scope of Third‑Party Support Services"
  • Leverandør bes om å beskrive SLAs/SLOs (respons, restore og resolutionmål per alvorlighetsgrad), målemetode, månedlig rapportering og service credits.RFI, punkt 7 B (6)
  • Leverandør skal beskrive eskalering til Microsoft (når/hvis) inkl. ledetid og end-to-end ansvar, samt hvordan eskalering håndteres når leverandøren ikke trenger å eskalere.RFI, punkt 7 B (7)
  • Leverandør skal beskrive sikkerhet, compliance og databeskyttelse: hvor saker/tickets, logger og artefakter lagres, underleverandører (sub-processors), tilgangskontroll og sporbarhet/auditability samt data residency.RFI, punkt 7 C (8)
  • Leverandør skal beskrive overgang-/transition-plan fra Microsoft Unified (eller nåværende tilstand) med risikoer, avhengigheter og mitigasjon (f.eks. knowledge capture, SIEM/SOAR-integrasjon, runbook handover).RFI, punkt 7 D (9)
  • Leverandør skal beskrive verktøy-/integrasjon som finnes: ITSM (f.eks. ServiceNow), overvåking, CMDB, identitet (Entra ID) og incident command tools.RFI, punkt 7 D (10)
  • Bærekraft: leverandør skal beskrive hvordan tjenesten bidrar til klima/miljømål og foreslå målbare indikatorer for senere konkurranse (inkl. henvisning til FOA § 7-9 og 30% default weighting med mindre begrunnet alternativ).RFI, punkt 7 E (11)
  • Kommersiell/prismodell: leverandør skal beskrive indicative kommersielle modeller (flat subscription, incident basert, tiered SLA-bånd eller hybrid), hva som er inkludert vs. valgfritt, samt kostdrivere/virkemidler og forslag til performance incentives/penalties (service credits, gainshare).RFI, punkt 7 F (12)-(14)

Spørsmål du bør vurdere å stille oppdragsgiver

AI-genererte forslag basert på konkurransedokumentene. Still spørsmålene i spørsmålsrunden i konkurransegjennomføringsverktøyet før tilbudsfrist. Vurder selv hvilke som er relevante for ditt tilbud.

  • I RFI-en ber dere om «security clearance options» i punkt 4. Kan dere presisere hvilke sikkerhetsklareringer dere forventer/krever for leverandørens personell som skal håndtere tickets og/eller ha tilgang til logg- og driftsdata (f.eks. norsk nivå, evt. krav til konkret type klarering)?

    Dette påvirker bemanning, tildeling av roller og kost/risiko, og dere bør bekrefte forventet klareringsnivå før leverandøren anslår kapasitet og pris.

    Del B punkt 4 (Service model and coverage)
  • I punkt 6 ber dere om SLAs/SLOs «per severity», inkludert «measurement method» og «service credits». Hvordan definerer dere severity-nivåene dere bruker i dag (f.eks. P1/P2/P3 eller tilsvarende), og hvilke hendelsestyper skal kobles til hver severity?

    Leverandøren må vite hvordan dere kategoriserer hendelser for å kunne gi sammenlignbare SLA-forslag og riktig prissetting.

    Del B punkt 6 (SLAs/SLOs)
  • I punkt 7 ber dere om «escalation pathways to Microsoft» og «when/if you engage Microsoft Unified/Premier … on our behalf». Ber dere om at leverandøren selv håndterer/videresender eskalering til Microsoft på vegne av dere, eller skal leverandøren kun beskrive prosessen og hvem som eventuelt initierer kontakt? Kan dere bekrefte hvem som har kommersiell og operasjonell beslutningsmyndighet for Microsoft-eskalering?

    Utydelig ansvarsmodell kan gi feil forventninger til leverandørens rolle, tidsbruk og kostdriver.

    Del B punkt 7 (Escalation pathways to Microsoft)
  • I punkt 8 ber dere om «where tickets, logs, and artifacts are stored» samt sub-processors og tilgangskontroll/auditability. Hvilke konkrete datakategorier må behandles som «sensitive» i denne anskaffelsen (f.eks. helse-/personopplysninger, autentiseringsdata, diagnostiske logger), og hvilke databehandlingskrav forventer dere at leverandøren dokumenterer i en senere konkurranse?

    Krav til datalagring og etterlevelse styrer løsning, arkitektur, underleverandører og sikkerhetskost, og bør avklares før leverandøren designer svar/rammer.

    Del C punkt 8 (Case handling and data residency)
  • I punkt 9 ber dere om en «proposed transition plan from Microsoft Unified … with risks, dependencies, and mitigation» og nevner «runbook handover» og «SIEM/SOAR integration». Kan dere beskrive hvilket SIEM/SOAR- og ITSM-miljø dere bruker i dag (navn/leverandør, og om det finnes eksisterende integrasjoner mot nåværende Microsoft Support)?

    Leverandøren må vite eksisterende verktøy og integrasjonsbilde for å prise overgang og minimere risiko for driftsbrudd i et fremtidig tilbud.

    Del D punkt 9 (Proposed transition plan)
  • I punkt 10 ber dere om «Tooling integration already available: ITSM (e.g., ServiceNow), monitoring, CMDB, identity (Entra ID), and incident command tools». Er det primært én bestemt ITSM/monitorering/CMDB dere ønsker at leverandøren skal støtte, eller skal leverandøren kunne støtte flere parallelle verktøy/versjoner på tvers av de fire regionene?

    Omfanget av verktøystøtte (én standard vs. flere) påvirker implementeringskost og driftbarhet betydelig.

    Del D punkt 10 (Tooling integration already available)
  • I punkt 12 ber dere om «indicative commercial models» og hva som er inkludert vs. valgfritt. Har dere et ønsket prisingsformat dere vurderer for en kommende konkurranse (f.eks. per «user/base spend» og/eller per «tower»/tjenesteområde), eller ønsker dere at markedet foreslår fritt og dere vurderer deretter?

    Leverandøren trenger å vite om dere ønsker en bestemt priskonstruksjon for å kunne gi nyttige markedsinnspill og sammenlignbare indikasjoner.

    Del F punkt 12 (Indicative commercial models)
  • I punkt 13 ber dere om «Cost drivers and levers (volume, scope towers, hours, coverage windows, dedicated engineers, mission critical options)». Kan dere gi et overordnet omfang/estimat av dagens support-volum og/eller forventet volum (f.eks. antall tickets pr. måned, andel major/mens critical, samt hvilke dekningsvinduer dere har i dag)?

    Uten volumanslag blir prisindikasjoner og bemanningsmodeller svært usikre og lite beslutningsrelevante.

    Del F punkt 13 (Cost drivers and levers)
  • I punkt 11 ber dere om klima-/miljøbidrag og foreslår indikatorer (energi, reise, near shoring, lifecycle emission reporting). Hvilket «baseline»-scenario sammenligner dere eventuelle indikatorer mot i en senere konkurranse (f.eks. videreføring av Microsoft Unified vs. dagens tredjepartsmodell/egen drift)?

    Valg av baseline påvirker hvordan leverandørene kan foreslå og måle indikatorer på en måte som faktisk kan evalueres.

    Del E punkt 11 (Sustainability and social responsibility)
  • I punkt 5 ber dere om «Service catalog aligned to the towers in section 5» og at leverandøren skal identifisere in/out of scope. Kan dere bekrefte at «towers» i deres kommende konkurranse følger de samme tjenesteområdene som opplistingen i «Indicative Scope of Third‑Party Support Services» (reaktiv, proaktiv, service/success management, mission‑critical/major incident, developer/DevOps, transition/onboarding), eller finnes det en annen tower-inndeling dere vurderer?

    Feil tower-inndeling kan gi avvik i scope og pris (inkl./ekskl. arbeid og tjenestebeskrivelser), og bør avklares før leverandøren svarer strukturert.

    Del B punkt 5 (Service catalog aligned to the towers in section 5)

Konkurransedokumenter

Last ned dokumentpakke (386.2 KB)

Dokumentpakken er hentet automatisk fra IVALUA og samlet som ZIP-fil.

Registrer interesse i den opprinnelige dokumentportalen hvis konkurransen er aktuell. Da får du endringer, spørsmål og svar og eventuell supplerende informasjon direkte fra oppdragsgiver.

Åpne original dokumentportal

Egen dokumentvisning og automatisk dokumentanalyse rulles ut per dokumentportal. Originaldokumentene gjelder alltid ved tilbudsarbeid.

Logg inn

Arbeidsflaten åpnes etter innlogging.