Observability platform til Sykehuspartner HF

Sykehuspartner HF (via Sykehusinnkjøp HF som innkjøpsforetak) skal anskaffe en observability-plattform med AIOps-kapasiteter for et stort, kritisk helse-ICT-miljø. Formålet er «single pane of glass» og bedre operasjonell innsikt: korrelasjon og rotårsaksanalyse på tvers av telemetry (metrics, events, logs, traces), redusert alertstøy, støtte for hybride/multicloud-miljøer (bl.a. AWS/Azure), og robusthet ved driftsavbrudd («Minimum Viable Observability»), inkl. exit-strategi for å redusere leverandørlås-in.

• Registrering i foretaksregister/profesjonsregister eller tilsvarende (etablerings-/registreringsbevis).

  Dokumentasjon: Norwegian companies: Certificate of establishment. Foreign companies: Certificate of statutory registration i staten der tilbyder er etablert. (Kap. 3.4.1)

  Kilde: Kapittel 3.4.1
• Økonomisk og finansiell kapasitet: tilstrekkelig solvens/kapasitet (kredittverdighet uten sikkerhet).

  Dokumentasjon: Siste to års finansregnskap med revisors erklæring; resultatregnskap og balanse siste 6 måneder hvis siste regnskap er eldre enn 6 mnd; kredittvurdering A eller bedre iht. AAA Soliditet eller tilsvarende; evt. alternativ dokumentasjon (f.eks. morselskapsgaranti/bankgaranti) eller forklaring hvis ikke kan fremlegges; oppgi evt. dokumentasjon om at morselskap kan overta datterselskaps forpliktelser. (Kap. 3.4.2)

  Kilde: Kapittel 3.4.2
• Teknisk og profesjonell erfaring innen observability/AIOps (leveranser/implementering/drift) relatert til spesifiserte fagområder.

  Dokumentasjon: Dokumentere erfaring innen ett eller flere områder (f.eks. korrelasjon/rotårsaksanalyse, dynamiske terskler/anomalideteksjon, change correlation, alert-noise reduction, topology/discovery/ingestion, hybrid/distributed, digital experience monitoring/synthetic testing/distributed tracing, capacity analysis/forecasting, access control/data handling, APIs/integrasjon/automatisering, license/telemetry/AI kostkontroll, access governance/audit/traceability, operational workflows/samarbeid). Inntil tre referanseleveranser fullført siste tre år, med informasjon i «Response Form: Technical and Professional Qualifications» og beskrivelse. (Kap. 3.4.3)

  Kilde: Kapittel 3.4.3
• Kapasitet for å oppfylle kontraktsforpliktelser (ressurser/organisasjonskapasitet).

  Dokumentasjon: Dokumentasjon av tilstrekkelig kapasitet basert på: gjennomsnittlig antall FTEs siste 3 år; antall FTE relevante for anskaffelsen (inkl. prosjekt-/leveranseledelse, løsningsarkitektur/teknisk design, implementering/configuration, integrasjon/automatisering, testing og QA, opplæring/knowledge transfer, support/vedlikehold, sikkerhet/personvern/databeskyttelse, operativ service management, produktutvikling); samt andel FTE forventet levert av støtte-/underleverandører. Leveres i «Response Form: Technical and Professional Qualifications». (Kap. 3.4.3)

  Kilde: Kapittel 3.4.3
• Kvalitetssystem for misjonskritiske systemer (ISO 9001 eller tilsvarende).

  Dokumentasjon: Gyldig sertifikat ISO 9001 eller ekvivalent kvalitetssystem fra uavhengig akkreditert organ; alternativ dokumentasjon ved ikke-sertifisert tilbyder. (Kap. 3.4.3)

  Kilde: Kapittel 3.4.3
• Informasjonssikkerhetsstyringssystem for misjonskritiske systemer (ISO/IEC 27001 eller tilsvarende).

  Dokumentasjon: Etablert ISMS basert på ISO/IEC 27001 eller anerkjent tilsvarende standard; dokumenteres via sertifikat eller annen dokumentasjon for tilsvarende etablert/implementert ISMS. (Kap. 3.4.3)

  Kilde: Kapittel 3.4.3
• Sanksjoner – erklæring om ikke-russisk involvering: forbud mot å tildele/implementere kontrakter med enheter omfattet av restriksjoner.

  Dokumentasjon: Vedlegget «Declaration of non-Russian Involvement» skal leveres komplett sammen med søknaden. (Kap. 3.2)

  Kilde: Kapittel 3.2
• ESPD som foreløpig egen-erklæring i KGV (Kvalifikasjonskrav oppfylt og ingen eksklusjonsgrunner).

  Dokumentasjon: Fullføre ESPD i KGV/Ivalua for relevant underleverandør. Oppdragsgiver kan be om underbyggende dokumentasjon på et senere tidspunkt. (Kap. 3.3)

  Kilde: Kapittel 3.3
• Mulighet til å støtte seg på andre virksomheter for å oppfylle kvalifikasjonskrav.

  Dokumentasjon: ESPD-uttalelse også for støttende virksomhet; dokumentere hvordan støtten gis/områder støtten gjelder; ved støtte til økonomisk/finansiell kapasitet: solidaransvar dokumenteres med «Declaration of commitment»; ved støtte fra morselskap: «parent company guarantee» vedlegges. (Kap. 3.4.5)

  Kilde: Kapittel 3.4.5

• Søknad om deltakelse skal leveres via innkjøpssystemet KGV/Ivalua innen frist; ikke mulig å endre etter frist (ny søknad kan leveres frem til frist).Kilde: Kapittel 3.1
• Innleveringspakke for søknad (filnavn/struktur): Application letter; etablerings-/registreringsbevis; finansregnskap og kredittvurdering; Response Form: Technical and Professional Qualifications; Declaration of non-Russian involvement; Declaration of commitment (hvis relevant); parent company guarantee/bankgaranti (hvis relevant).Kilde: Kapittel 3.6
• Response Form skal fylles ut uten endring av struktur, og innen angitte ord-/tekstgrenser; overskridelse evalueres ikke.Kilde: Kapittel 3.6.1
• Referansebeskrivelser: maks 1000 ord per referanse; total ferdig response form maks 4000 ord (ekskl. forside og uttrykkelig tillagte vedlegg); «Other documentation» maks 100 ord per kategori; referansemapping kun med avkryssinger og presise sidereferanser.Kilde: Kapittel 3.6.1
• Søknadsspråk og dokumentasjonsspråk: norsk eller engelsk.Kilde: Kapittel 3.7

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

07.10.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Valgt avtaleform: SSA-L (Agreement concerning Ongoing Purchase of Services via the Internet) basert på DFØs standard IT-anskaffelsesvilkår.Kilde: Kapittel 1.5
• Varighet (SSA-L): 3 år fra leveringsdato; automatisk fornyelse med 1 år av gangen med 3 mnd oppsigelsesfrist før fornyelse (Kunden); leverandør kan si opp med 12 mnd før fornyelse.Kilde: Kapittel 1.6
• Databehandleravtale: skal etableres i tråd med GDPR; kunden foretrekker egen mal (vedlegg).Kilde: Kapittel 1.5
• Skatteattest ved behov (norsk leverandør): VAT- og skatteattest, ikke eldre enn 6 måneder ved forespørsel, fra kontraktstildelingsvarsel.Kilde: Kapittel 2.3
• Ansattes/lønn- og arbeidsvilkår: krav om lønns- og arbeidsvilkår iht. relevante allmenngjorte tariffavtaler eller nasjonale kollektive avtaler; dokumentasjon ved forespørsel.Kilde: Kapittel 2.4
• IKT-sikkerhet/IS: SSA-L krever «appropriate measures» for informasjonssikkerhet; data skal sikres mot uautorisert tilgang, endring/sletting, og malware; datadeling/segmentering for å holde kundedata separat fra tredjepartsdata. (Overordnet kontraktstekst i SSA-L)Kilde: SSA-L (Kapittel 6.1 i avtaletekst)
• Personvern/GDPR: hvis leveransen behandler personopplysninger, skal dette beskrives; databehandlerforhold skal reguleres; databehandleravtale før behandlingsstart; begrensninger for videre databehandler uten skriftlig tillatelse.Kilde: SSA-L (Kapittel 6.2 i avtaletekst)

• Konkurransens faktiske tildelingsvekter/priss-/kvalitetsformel er ikke angitt i utdraget (kun at endelig «best price/cost and quality ratio» fastsettes under dialogen).
• Krav til dokumentasjonsspesifikke detaljer (f.eks. eksakt filformat, nøyaktige frister i kalender) mangler; frister refererer til «se procurement system» eller «TBD».
• Kontrakts- og leveransekrav utover varighet/avtaleform (f.eks. SLA, standardiserte misligholdssatser, implementeringsmilepæler) finnes ikke i detalj i vedlagt tekstutdrag.

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 konkurransen står det at endelige tildelingskriterier, underkriterier og evalueringsmetode for «best price/cost and quality ratio» fastsettes i dialogen. Kan dere bekrefte at dere senest i «Invitation to final tender» vil publisere: (i) endelig vektfordeling mellom pris/kost og kvalitet, (ii) konkrete underkriterier og hvilke deler av løsningen/scenarioene som inngår, og (iii) hvordan poeng/kalkyle beregnes (inkl. eventuelle cap-er, normalisering og hvordan klima/ miljøeventuelt slår ut)?

   Hvorfor det er verdt å spørre: Leverandøren må kunne prise og dimensjonere leveransen riktig, og planlegge dokumentasjon på en måte som samsvarer med faktisk evaluering.

   Kilde: 5.3 Award criteria and evaluation / «Final award criteria… will be decided during the dialogue phase…»

2. Kan dere avklare hvordan dere ser på og vekter integrasjoner/automatisering og ITSM/CMDB-flyt opp mot «observability/AIOps»-plattformens kjernefunksjoner i evalueringen? Henviser dere i praksis til spesifikke deler av scenarioene (f.eks. Scenario 01/03 for ITSM-overføring, og Scenario 05/06 for CMDB/topologi), og kan dere dele en foreløpig vurderingsmatrise eller hvordan dere typisk allokerer poeng på disse delene i dialogen?

   Hvorfor det er verdt å spørre: Krav og pris påvirkes sterkt av hvor stor del av løsningen som må leveres som integrert helhet vs. leveres som plattformkapabilitet.

   Kilde: 5.3.1 Quality samt «Customer’s needs and requirements»/scenarioene (f.eks. Scenario 01, 05, 06)

3. Vi ber om en presisering av forventet «Minimum Viable Observability» og exit strategy (for å redusere vendor lock-in): Hvilke konkrete leveranser/kapabiliteter forventes i kontrakten for at exit skal være «klar og feasible» (f.eks. eksportformater, varighetskrav for datatilgang, tilbakesleping av konfigurasjon, migrasjonsstøtte), og hvilke deler er minimumskrav versus dialog-/tilbudselementer?

   Hvorfor det er verdt å spørre: Dette kan innebære betydelig kostnad og risiko, særlig for datautlevering og hvor mye som må dokumenteres og garanteres kontraktsmessig.

   Kilde: 1.3.2 Scope («Minimum Viable Observability… clear and feasible exit strategy to reduce vendor lock-in») samt SSA-L kapittelvalg/dokumentasjonskrav i vedleggene (Appendix 4/andre)

4. Kan dere konkretisere datakostnads-/lisensprisingsmodellene dere ønsker at leverandørene skal prise i dialogen/til sluttinnlevering, gitt at dere forventer pris-/kostkomponenter knyttet til (i) lisens/abonnement, (ii) datainntak, (iii) lagring/retensjon og (iv) «AI-based analysis»? Spesifikt: hvilke måleparametere vil være styrende (f.eks. ingest rate/GB per dag, antall kilder, retention-lengde per datatyper, total telemetry volume, antall brukere/teams, eller AIOps-«compute»)?

   Hvorfor det er verdt å spørre: Uten tydelig prisingsdrivers vil leverandøren kunne ende med feil kostnadsestimater og uriktig tilbud.

   Kilde: 5.3.2 Price/cost («Licensing and subscription… Data ingestion, retention and storage… AI-based analysis…»)

5. SSA-L benyttes, men endelig SLA (Appendix 4) og eventuelle «standardised damages» må ferdigstilles. Kan dere avklare (i) om dere forventer at tilbyder skal levere sin standard SLA i konkurransen, eller om dere kun skal svare på en kundedefinert SLA-tabell, og (ii) hvilke SLA-områder (uptime, responstider, support, feilretting, veiledning/training) dere forventer at «standardised damages» kobles til i denne anskaffelsen?

   Hvorfor det er verdt å spørre: SLA-krav og mislighold/kompensasjon påvirker både leverandørens risiko og prising.

   Kilde: 1.5 Agreement (SSA-L basert på DFØ) og 5.3.1/5.3.2 samt «Appendix 4: Service level with standardised damages»

6. For etableringsfase/leveransedato og akseptansetest: Kan dere bekrefte hvilken forventet frist det er for «service shall be available» og hvilke konkrete kriterier som inngår i «approval test» (herunder hva som regnes som kritisk vs. øvrige feil), samt om 10 business days-grensen i SSA-L for investigating/approval er relevant i denne konkurransen?

   Hvorfor det er verdt å spørre: Leverandøren må kunne planlegge bemanning og leveransemilepæler, og beregne risiko for forsinkelser og akseptansefeil.

   Kilde: SSA-L_Appendices_2026.docx Appendix 3 (cl. 3.1–3.3) samt «Clause 3.2… Delivery deadline» og «Clause 3.3… Approval testing and delivery day»

7. Dere angir at SSA-L varighet er 3 år med automatisk fornyelse 1 år og oppsigelse med hhv. 3 og 12 måneders varsel. Kan dere samtidig avklare om det planlegges opsjoner/utvidelser i tillegg (til avtaleverdi mellom 100–200 MNOK), og i så fall hvordan opsjonslogikken vil påvirke plikt-/leveranseomfang og prisformel (f.eks. indeksregulering, volum, datamengde)?

   Hvorfor det er verdt å spørre: Langsiktig økonomisk planlegging og kostnadsdrivere avhenger av om det finnes reelle opsjoner eller volumforutsetninger.

   Kilde: 1.3.3 Estimated total procurement value samt 1.6 Duration of the agreement

8. Krav til tilgangsstyring og revisjon: Scenario 09–12 beskriver rollebasert tilgang, datamasking/redaction og at admin/retensjon kan styres «without vendor involvement». Kan dere bekrefte hvilke konkrete persondata-/sensitivitetsforutsetninger dere legger til grunn (f.eks. om innsamlede logger/traces typisk inneholder PII) og hvilke mekanismer som må leveres kontraktsmessig (masking i ingestion, retensjonsstyring, audit-loggingens detaljeringsgrad og varighet)?

   Hvorfor det er verdt å spørre: Teknisk og juridisk etterlevelse rundt behandling av sensitive data og tilgangsstyring påvirker både løsningens design og kostnader.

   Kilde: 1.3.2 Scope (data governance/robustness) samt Scenarios 09–12 og SSA-L (Kap. 6.1/6.2)

9. Om vi støtter oss på andre virksomheter i kvalifikasjonsfasen: kan dere avklare hvordan dere praktiserer «solidarity responsible» ved bruk av andre selskaper (f.eks. hvilken rolle de får i leveransen), og hvilke dokumenter dere forventer i «Declaration of commitment» (innholdskrav) og om dere krever parent company guarantee også i andre tilfeller enn parent-selskap?

   Hvorfor det er verdt å spørre: Feil forståelse av sikkerhet/forpliktelser ved bruk av underleverandører kan gi kvalifikasjonsrisiko og påvirke tilbudets organisering og prising.

   Kilde: 3.4.5 Using other businesses to fulfil qualification requirements og 3.4.5 (solidarity responsible)