Anskaffelse av system for registrering og administrasjon av utstyr og inventar

Nordland fylkeskommune skal anskaffe et nytt SaaS-system for registrering, administrasjon og oppfølging av utstyr og inventar, inkludert sporing og støtte til planlegging/gjennomføring av vedlikehold og service, samt funksjoner for blant annet utlån, servicehistorikk, garantier, varsler og dokumentasjon. Kontraktsgrunnlag er Statens standardavtale for løpende tjenestekjøp over internett (SSA-L 2018).

• Skatteattest (tilbyder)

  Dokumentasjon: Skatteattest, ikke eldre enn 6 måneder regnet fra tilbudsfrist. Eventuelle restanser må begrunnes.

  Kilde: Dokument PDF, pkt. 3 Kvalifikasjonskrav / Skatteattest
• HMS-egenerklæring om systematisk HMS-arbeid og lovlig organisering

  Dokumentasjon: HMS egenerklæringskjema/egenerklæring.

  Kilde: Dokument PDF, pkt. 3 Kvalifikasjonskrav / HMS egenerklæring
• Økonomisk gjennomføringsevne

  Dokumentasjon: Leverandøren må ha tilstrekkelig økonomisk og finansiell kapasitet. Kredittverdighet uten krav til sikkerhetsstillelse anses tilstrekkelig.

  Kilde: Dokument PDF, pkt. 3 Kvalifikasjonskrav / Økonomisk gjennomføringsevne

• Leverandør må bekrefte at bilag 1 (kravspesifikasjon) er lest/forstått, og at alle absolutte krav er innfriddKilde: Dokument PDF, pkt. 4 Krav / 1 Bekreftelse fra leverandør (Response required)
• Demobruker til evalueringsformålKilde: Dokument PDF, pkt. 4 Krav / 2 Demoversjon (Response required)
• Fylle ut leverandørens deler av SSA-L-bilag som ligger vedlagt konkurransenKilde: Dokument PDF, pkt. 4 Krav / 3 Utfylling av Bilag til avtalen (Response required)
• Besvare «IKT Sikkerhetskrav» (MÅ-krav/besvare alle aktuelle punkter)Kilde: Dokument PDF, pkt. 4 Krav / 4 Sikkerhetskrav (Response required)
• Tilbyd skal leveres elektronisk i Mercell innen tilbudsfristen, med elektronisk signatur ved leveringKilde: Dokument PDF, pkt. 6.1 Innlevering av tilbud
• Ved eventuelle forbehold/avvik: oppgis som eget vedlegg og beskrives samt pris-settesKilde: Dokument PDF, pkt. 6.2 Forbehold og avvik
• Ved levering: relevante dokumenter skal ligge ved under faneblad «Dokumenter» i Mercell (bl.a. tilbud, utfylte prisskjemaer, brosjyrer) og totalsum fra prisskjema legges inn under arkfanen «produkter»Kilde: Dokument PDF, pkt. 6.3 Tilbudets utforming

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

29.06.2026

Språk

norsk

Elektronisk katalog

Ikke tillatt

• Tjenesten skal leveres som løpende tjenester «as a service» over internett (SaaS) og baseres på Kundens kravspesifikasjon (bilag 1) samt Leverandørens beskrivelse (bilag 2).Kilde: SSA-L generelle avtaletekst, pkt. 1.1 Avtalens omfang
• Leverandøren skal levere tjenesten i henhold til krav/ beskrivelser i bilag 1 og 2 innen frister i bilag 3; leverandøren har ansvar for tjeneste i henhold til tjenestenivå i bilag 4. Drift er inkludert i vederlaget.Kilde: SSA-L generelle avtaletekst, pkt. 2.1 Leverandørens ansvar for tjenesten
• Godkjenningsprøve: dersom ikke annet avtales i bilag 3 skal kunden undersøke i 10 virkedager etter leveransemelding; leveringsdag bestemmes av godkjenning/underkjenning.Kilde: SSA-L generelle avtaletekst, pkt. 3.3 godkjenningsprøve og Leveringsdag
• Dokumentasjon/opplæring: Standard produkt-/brukerdokumentasjon skal leveres (norsk med mindre annet avtales) og være datert/siste versjon; levering senest ved oppstart godkjenningsprøve hvis ikke annet avtales. Leverandør skal bistå med nødvendig opplæring hvis avtalt.Kilde: SSA-L generelle avtaletekst, pkt. 3.4 Dokumentasjon og opplæring
• Oppgradering/vedlikehold etter leveringsdag: standardoppgraderinger og alminnelig vedlikehold inngår i vederlaget med mindre annet er angitt; leverandøren skal teste nødvendige standardoppgraderinger i avtaleperioden.Kilde: SSA-L generelle avtaletekst, pkt. 3.5 Oppgradering/vedlikehold av tjenesten etter Leveringsdag
• Personopplysninger: dersom leverandøren behandler personopplysninger skal leverandøren beskrive hvordan tilfredsstillende behandling oppnås (bilag 2/evt. vedlegg databehandleravtale) og behandlingen skal følge personvernregler; databehandleravtale må være inngått før behandling.Kilde: SSA-L generelle avtaletekst, pkt. 6.2 Personopplysninger og bilagstekst pkt. 6.2
• Informasjonssikkerhet: leverandøren skal iverksette forholdsmessige tiltak for konfidensialitet, at data ikke kommer på avveie, mot utilsiktet endring/sletting og mot virus/skadevare; krav om atskillelse av data og påse sikring hos tredjepartsleverandører.Kilde: SSA-L generelle avtaletekst, pkt. 6.1 Informasjonssikkerhet
• Fakturering og betaling: betaling forfaller etter faktura per 30 kalenderdager; leverandøren skal bruke elektronisk faktura i godkjent standardformat (EHF).Kilde: SSA-L generelle avtaletekst, pkt. 4.2 Faktureringstidspunkt og betalingsbetingelser
• Varighet/fornyelse/avbestilling: avtale trer i kraft ved signering; standard varighet 3 år fra leveringsdag hvis ikke annet i bilag 5; fornyes automatisk 1 år om gangen med oppsigelsesvarsler (kunde 3 mnd før fornyelse; leverandør 12 mnd). Kunden kan avbestille med 3 mnd skriftlig varsel.Kilde: SSA-L generelle avtaletekst, pkt. 5.1 Varighet og 5.2 Avbestilling
• Sanksjoner ved leverandørmislighold: leverandør skal avhjelpe; ved gjentatte forsøk uten å lykkes kan kunden kreve forholdsmessig prisavslag; dagbot ved forsinkelse (0,15% av avtalt vederlag per dag i inntil 100 dager, detaljer i bilag 3).Kilde: SSA-L generelle avtaletekst, pkt. 9.2.1 Avhjelp og prisavslag og pkt. 9.2.3 Dagbot ved forsinkelse
• Heving: kan skje ved vesentlig mislighold; ved vesentlig forsinkelse kan kunden heve hele/deler etter varsel og frist; funksjonstap i tredjepartsleveranser som kvalifiserer som kritisk/vesentlig feil kan gi rett til heving.Kilde: SSA-L generelle avtaletekst, pkt. 9.2.5 Heving

• Kun deler av SSA-L-betingelsene er gjengitt; detaljer i bilag 3 (plan for etableringsfase og frister), bilag 4 (tjenestenivå/kompensasjoner), bilag 5 (administrative bestemmelser) og bilag 7/8 er ikke synlig i teksten, utover at de skal/kan fylles ut og regulerer sentrale forhold (f.eks. SLA, etableringsfrist, representanter/varsler, avbestillingsgebyr, prisendringsdetaljer).
• Kravene til evalueringsgrunnlag for demoversjon samt nærmere metode for poengsetting/uttak utover hovedvekter er ikke fullt spesifisert i den gjengitte teksten.
• IKT sikkerhetskrav er kun delvis gjengitt (skjemaet inneholder mange punkter, men ikke utfylt svar/avkrysning i teksten).
• Ingen eksplisitte kvalifikasjonskrav (annet enn skatteattest, HMS-egenerklæring og økonomisk kapasitet) er oppgitt som dokumentasjonskrav utover disse; eventuelle øvrige kvalifikasjonskrav i konkurransegrunnlaget er ikke synlige i den vedlagte teksten.

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 kravspesifikasjonen punkt 1.8–1.9 (brukerprovisjonering via Entra ID) og punkt 1.10 (federering med OpenID Connect/OAuth2.0 eller SAML 2.0), ber vi om at dere avklarer hvilken av disse godkjenningene som er «alternativer» og hvilken som er «i kombinasjon». Er det krav om at alle fylkeskommunens brukere *må* leveres via Entra ID, og at systemet *i tillegg* må støtte begge (OIDC/OAuth2.0 og SAML 2.0), eller holder det å støtte én av protokollene (OIDC/OAuth2.0 *eller* SAML 2.0) samtidig som Entra ID brukes?

   Hvorfor det er verdt å spørre: Vi må vite om vi skal prise og implementere én eller flere autentiserings-/federeringsmodeller for å oppfylle kravene og unngå avvik.

   Kilde: Bilag 1, krav 1.8–1.10

2. I kravspesifikasjonen punkt 1.6 står det at det er ønskelig med import av eksisterende data fra andre systemer, og at det per d.d. benyttes Facilit FDV. Kan dere bekrefte (1) hvilke datasett som skal importeres fra Facilit FDV (f.eks. inventar/utstyr, plassering, garantier, servicehistorikk, dokumentasjon), (2) forventet volum (antall utstyr/inventar, antall historikkposter, størrelser på dokumenter), og (3) om importen skal være én gangs oppstart-import eller løpende/delta-import?

   Hvorfor det er verdt å spørre: Vi mangler konkret omfang og volum for å prise etablering/import og for å planlegge teknisk metode (engang/delta).

   Kilde: Bilag 1, krav 1.6

3. I kravspesifikasjonen punkt 1.11 (utlån av utsyr) og 1.12 (varslinger e-post og SMS), ber vi om at dere presiserer for begge funksjonene: (1) hvilke utlåns- og tilbakeleveringshendelser som skal utløse varsler, (2) hvilke mottakere/roller som skal varsles (f.eks. bruker som låner, administrator, serviceteam), og (3) om dere har krav til SMS-leverandør/telefonnummertilgang eller om dette kan løses via standard SMS-tjeneste hos leverandør.

   Hvorfor det er verdt å spørre: Varslingslogikken og SMS-kravene påvirker både funksjonsomfang og integrasjoner, og dermed kost/risiko.

   Kilde: Bilag 1, krav 1.11 og 1.12

4. I kravspesifikasjonen punkt 2.8–2.9 (brukere legger inn varsel/hendelser/oppgaver og administrator får varsel hvis frister ikke overholdes), ber vi om at dere avklarer: (1) hvilke typer oppgaver/varsler som forventes (minimumskategorier), (2) hvordan «frist» skal håndteres (dato/tid, påminnelser, eskalering), og (3) hvem som skal motta eskaleringsvarsel når fristen passeres (rolle-/regelbasert).

   Hvorfor det er verdt å spørre: Utydelig forretningsregel for frister/eskalering gir risiko for feil leveranse og feil prising.

   Kilde: Bilag 1, krav 2.8 og 2.9

5. I kravspesifikasjonen punkt 2.10 står det at det evalueres positivt med integrasjon mot økonomisystemet (Visma Enterprise) og at tilbyder må beskrive om integrasjon er mulig og ev. utvikles særskilt. Ber vi om å avklare: (1) om integrasjonen er en faktisk leveranse som må inngå i tilbudsprisen for å få poeng, eller kun et tilbudt «alternativ/opsjon», (2) forventet integrasjonsretning (f.eks. overføring av kostnader fra systemet til Visma, eller import av regnskapsdata/FDV-kost fra Visma), og (3) om dere kan beskrive hvilke datatyper som er kritiske å få på plass (kontoplan/koststed, beløp, periodisering, dokumentreferanser).

   Hvorfor det er verdt å spørre: Siden dette er «BK» men skal evalueres, trenger vi å forstå hva som faktisk forventes levert og hvordan vi skal prise integrasjonen.

   Kilde: Bilag 1, krav 2.10

6. I kravspesifikasjonen punkt 3.5–3.6 og 3.11–3.12 ber vi dere avklare: (1) hvilke rapport-/eksportformater som dere legger til grunn (kun Excel/CSV eller også andre), (2) om eksporten må inkludere alle felter/detaljnivå eller kun definerte felter, og (3) om dere har krav til hvor mange samtidige eksport/rapporter brukerne vil ha (volum/frekvens).

   Hvorfor det er verdt å spørre: Eksport-/rapportkrav og ytelsesforventninger påvirker både løsning og drift/kapasitetspris.

   Kilde: Bilag 1, krav 3.5–3.6 og 3.11–3.12

7. I kravspesifikasjonen punkt 4.1–4.3 om support ber vi om at dere presiserer hva som menes med «tilgjengelig i ordinær arbeidstid» og om det gjelder både (1) nye henvendelser (ticket/brukerstøtte) og (2) feilretting. Videre: har dere forventninger til responstid og løsningstid per feiltype (f.eks. A/B/C) knyttet til SLA/bilag 4, eller skal vi legge til grunn at dette fullt ut fremgår av bilag 4?

   Hvorfor det er verdt å spørre: Vi må vite hvordan supportnivå skal knyttes til avtalte tjenestenivåer for å prise korrekt og levere riktig prosess.

   Kilde: Bilag 1, krav 4.1–4.3; samt henvisning til bilag 4

8. Vi ser at SSA-L viser til bilag 3 (Plan for etableringsfasen) for «leveransefrist» og eventuelle godkjenningsprøver/andre frister, og til bilag 4 for tjenestenivå og satser. Siden disse bilagene ikke er gjengitt i utdraget: Kan dere oppgi (1) planlagt tilgjengelighet/leveringsdag, (2) godkjenningsprøvens varighet og kriterier (hvilke typer feil regnes som A/B/C i praksis for denne løsningen), og (3) hvilke dagbot-milepæler som eventuelt skal betales ved forsinkelse?

   Hvorfor det er verdt å spørre: Uten konkrete milepæler og godkjenningsregler kan vi ikke prise risiko for forsinkelse og kostnader ved test/aksept.

   Kilde: SSA-L, punkt 3.2–3.4 og 9.2.3; samt henvisning til bilag 3 og bilag 4

9. I SSA-L punkt 6.1 for informasjonssikkerhet fremgår det at tilbyder skal besvare vedlegget «Sikkerhetskrav». Vi har bare sett at det henvises til dette vedlegget, men ikke hele sikkerhetskrav-vedlegget. Kan dere oversende fullstendig «Sikkerhetskrav»-vedlegg og eventuelt et sikkerhetskravskart som viser hvilke punkter som er relevante for denne SaaS-løsningen (og hvilke dere forventer at ikke er aktuelle med begrunnelse)?

   Hvorfor det er verdt å spørre: Vi kan ikke kvalitetssikre samsvar eller utforme avvik/begrunnelse uten komplett sikkerhetskravdokument.

   Kilde: SSA-L, punkt 6.1 og Bilag 1, punkt 6.1-henvisning