Arbeidsplanverktøy

Nord universitet skal anskaffe et felles arbeidsplan- og ressursstyringssystem for vitenskapelig ansatte. Løsningen skal understøtte planlegging, fordeling og oppfølging av arbeidsoppgaver samt gi oversikt og styringsinformasjon for kapasitet/arbeidsbelastning. Det planlegges avtale etter SSA-Lille Sky (IT-sky) med estimert verdi ca. 200 000 NOK eks. mva per år, og det er ikke adgang til deltilbud.

• Leverandøren skal være registrert i foretaksregister, faglig register eller handelsregister i den staten leverandøren er etablert (firmaattest for norske, dokumentasjon for utenlandske).

  Dokumentasjon: Firmaattest (norske selskaper) / godtgjørelse på registrering i foretaksregister/faglig register/handelsregister (utenlandske).

  Kilde: Konkurransegrunnlag.pdf, pkt. 4.1 Leverandørens registrering, autorisasjon mv.
• Norske leverandører skal ha ordnede forhold med hensyn til betaling av skatt, arbeidsavgift og merverdiavgift.

  Dokumentasjon: Skatteattest, ikke eldre enn 6 måneder regnet fra tilbudsfristen.

  Kilde: Konkurransegrunnlag.pdf, pkt. 4.2 Skatteattest

• Tilbudet skal leveres elektronisk via KGV innen tilbudsfrist (absolutt frist; ingen innlevering/endring etter frist).Kilde: Konkurransegrunnlag.pdf, pkt. 5.1 Tilbudsfrist og innlevering av tilbud
• Alle filer skal lastes opp som PDF (eller annet alminnelig tilgjengelig format) og navngis slik at filnavn viser innhold.Kilde: Konkurransegrunnlag.pdf, pkt. 5.1 Tilbudsfrist og innlevering av tilbud
• Tilbudsbrev skal fylles ut i henhold til bilag C (Tilbudsbrev-mal).Kilde: Konkurransegrunnlag.pdf, pkt. 5.2 Tilbudsbrev
• Dokumentasjon på oppfylte kvalifikasjonskrav og dokumentasjon på tildelingskriteriene.Kilde: Konkurransegrunnlag.pdf, pkt. 5.3 Kvalifikasjonskrav og tildelingskriterier
• Databehandleravtale: Tilbyder må fylle ut vedlagt databehandleravtale fra Nord universitet og levere den sammen med tilbudet.Kilde: Konkurransegrunnlag.pdf, pkt. 5.4 Databehandleravtale

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

02.10.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Avtaletype: SSA-Lille Sky (tilgang til skytjenester levert på standardvilkår) og avtaleinngåelse med én leverandør.Kilde: Konkurransegrunnlag.pdf, pkt. 1.3 Kontraktstype og omfang; ssa-lille_sky-generell-avtaletekst_2026_bok.docx (SSA-Lille Sky-konsept)
• Leverandøren skal levere skytjenester som del av et systemlandskap, og ved manglende oppfyllelse av krav skal avvik beskrives i leverandørens bilag (Bilag 2).Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, avsnitt «Avtalens omfang»
• Godkjenningsprøve: Når skytjenestene er klare, skal Leverandøren gi melding og Kunden verifiserer tilgang og at løsningen fungerer som forutsatt. Godkjenningsperiode: 10 virkedager (med standard antagelse om godkjenning med mindre skriftlig avvik meldes).Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, «Kundens Godkjenningsprøve»
• SLA/tjenestenivå: Standardvilkår for skytjenestene (inkl. SLA) framgår av bilag 10 og er bindende for levering av skytjenestene.Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, «Standardvilkår»
• Personvern/datatilrettelegging: Databehandleravtale skal være inngått før behandling av personopplysninger påbegynnes.Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, punkt «Plikt til å inngå databehandleravtale»
• Opphør/avslutning: Leverandøren skal tilgjengeliggjøre data i et egnet format (maskinleselig) ved avtalens opphør og slette egne kopier (med mindre annet fremgår).Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, «Rettigheter til data»
• Sikkerhet: Leverandøren skal iverksette forholdsmessige tiltak for informasjonssikkerhet (tilgjengelighet/konfidensialitet, beskyttelse mot utilsiktet endring/sletting og skadevare, samt dataskille).Kilde: ssa-lille_sky-generell-avtaletekst_2026_bok.docx, «Informasjonssikkerhet – Generelle krav»
• Tekniske/IKT-krav (fra Bilag 13): SaaS-modell, høy tilgjengelighet, robust sikkerhet, pålitelig backup, åpent standardisert API, nettleser- og plattformkompatibilitet, støtte for Entra ID/Feide, SSO og MFA, rolle-/tilgangsstyring og revisjonsmuligheter, skalerbarhet og vedlikeholdsplan, eksport av all informasjon ved avslutning.Kilde: Bilag 13 - Krav Digitalisering og IKT.pdf (samlet)

• Konkurransegrunnlaget viser ikke eksplisitt konkrete terskel-/avvisningskrav utover generell avvisning ved vesentlige avvik (FOA § 24-8 (1) b); detaljer om hvilke avvik som anses vesentlige fremgår ikke av utdraget.
• Tildelingsscoremetode utover beskrivelsene for kvalitet (0-6) og pris (lavest får 6) er ikke fullstendig beskrevet; prisens øvrige scoringsformel er ikke angitt.
• Konkrete SLA-krav (tjenestenivå/kompensasjon) er henvist til bilag 10/5/7, men disse bilagene er ikke vedlagt i tekstuttrekket.
• Det finnes et bilag «Bilag B Forbehold og avvik» med mal for utfylling av avvik, men ingen konkrete avvik/forbehold er oppgitt i 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 Bilag 1B (nr. 5.1.1–5.1.5) ber dere tilbydere beskrive hvordan løsningen løser bl.a. "automatisk datafangst fra relevante kildesystemer" og "autoritative systemer". Kan dere presisere hvilke kildesystemer (f.eks. SAP, FS, Entra/Feide, IAM/RapidIdentity, ev. timeplansystem og økonomisystem utover det som står i Systemlandskap) som skal levere data automatisk i denne anskaffelsen, og hvilke dataelementer/objekter som forventes synkronisert automatisk (samt eventuelt hvilke som kan gjøres via manuell registrering styrt av roller)?

   Hvorfor det er verdt å spørre: For å prise riktig (og utforme avvik/tilpasninger) må leverandøren vite hva som faktisk forventes som automatisk integrasjon versus manuell håndtering og hvilke datagrunnlag som inngår.

   Kilde: Bilag 1B – Integrasjoner og datautveksling (1.5.1, 1.5.2 og 1.5.4) samt Bilag 1A kap. 6

2. I Bilag 1B pkt. 1.5.4 står det: "Hvor ofte oppdateres informasjon fra autoritære systemer i løsningen. - Beskriv hvordan dette er løst." Hvilke konkrete frekvenser/oppdateringsintervall forventes for hvert integrert autoritativt system (minimum/ønsket nivå), og er det krav til sanntidsnær oppdatering for noen data (f.eks. tilgang/roller via IAM/Entra/FEIDE)?

   Hvorfor det er verdt å spørre: Pris og løsningsdesign påvirkes kraftig av om det kreves batch, near-real-time eller sanntid for ulike datatyper.

   Kilde: Bilag 1B – Integrasjoner og datautveksling (1.5.4)

3. I Bilag 1B pkt. 1.7.14 bes det om "en beskrivelse av leverandørens støtteapparat og behandling av kritiske feil" og at leverandøren kan legge ved foreslått SLA. Kan dere bekrefte hvilke SLA-krav som gjelder i konkurransen (hvilke respons-/oppetid-/feilrettelseskrav og evt. standardiserte kompensasjoner), og i hvilket bilag dette er spesifisert (bilag 5/7/10 nevnes i konkurransegrunnlaget, men innholdet er ikke synlig i utdraget)?

   Hvorfor det er verdt å spørre: Leverandøren må vite faktiske SLA-krav/kompensasjoner før tilbud og for å unngå vesentlige avvik.

   Kilde: Bilag 1B – Teknisk løsning, sikkerhet og forvaltning (1.7.14) og Konkurransegrunnlag kap. 5/6 (henvisning til bilag 5/7/10)

4. I SSA-lille sky standardavtalen (som dere legger til grunn) reguleres "Kundens Godkjenningsprøve" med varighet 10 virkedager og at mangler kan medføre heving dersom mangler ikke er rettet innen 60 kalenderdager. Kan dere beskrive forventet innhold om "hver ny Skytjeneste og/eller hver gang nye funksjoner/moduler skal tas i bruk" i denne anskaffelsen, og om Bilag 4 (leveringsplan og kriterier for godkjenningsprøve) vil spesifisere trinnvis godkjenning per modul/fakultet?

   Hvorfor det er verdt å spørre: Trinnvis implementering (fakultetvis) kan gi flere godkjenningsprøver og påvirker risiko for forsinkelse/mislighold som igjen påvirker prising og prosjektplan.

   Kilde: SSA-lille sky – punkt 2.4 (Godkjenningsprøve) samt Konkurransegrunnlag kap. 1.2/1.5 og Bilag 1B (1.7.9) som nevner trinnvis implementering

5. I Bilag 1B pkt. 1.7.10 ber dere tilbydere beskrive hvordan Microsoft Copilot/AI kan brukes i/mot løsningen. Hvilke konkrete AI-bruksområder vurderer Nord universitet å ta i bruk (f.eks. støtte for arbeidsplanlegging, forslag til oppgaver/estimat, søk i arbeidsplandata, skrive-/oppsummeringsstøtte), og hvilke datatyper kan (eller ikke kan) inngå som grunnlag for AI?

   Hvorfor det er verdt å spørre: AI-bruk påvirker både personvern-/sikkerhetsvurdering, integrasjoner og arkitektur, og må avklares for å gi et riktig og akseptabelt løsningsforslag.

   Kilde: Bilag 1B – Teknisk løsning, sikkerhet og forvaltning (1.7.10) samt Bilag 13 – Generelle krav (API, SLA, sikkerhet) og Personvern/Sikkerhet i Bilag 13

6. I Bilag 1B pkt. 1.6.3 ber dere om historikk/endringslogg/kommentarer og sporbarhet «i tråd med NSMs grunnprinsipper». Hvilke konkrete sporbarhetskrav er mest kritiske (f.eks. audit på hvem/bruker/rolle, endringsgrunnlag, tilgang til filer/dokumenter, revisjonsnivå, logging av godkjenningsflyt), og hvilke minimumskrav forventes for logglagring/oppbevaringstid?

   Hvorfor det er verdt å spørre: Sporbarhet og logging er ofte en hoveddriver for kost og teknisk kompleksitet, og leverandøren trenger minimumskrav for å vurdere løsning og risiko.

   Kilde: Bilag 1B – Brukere, fleksibilitet og sporbarhet (1.6.3)

7. I Bilag 1A pkt. 6 og Bilag 1B pkt. 1.5.3 omtales eksport til videre bruk i BI/analyse. Kan dere spesifisere: (1) hvilke eksportformater dere forventer som minimum (f.eks. CSV/JSON/XML/PowerBI-kildefiler), (2) om dere krever historiske snapshots eller kun siste tilstand, og (3) hvilke datadomener/objekter som skal være med (individ, emne, program, aktivitet, prosjekt, tidsperioder)?

   Hvorfor det er verdt å spørre: Uten konkrete krav til eksportformat og omfang blir prising av dataflyt/ETL og gjennomføring vanskelig og risikofylt.

   Kilde: Bilag 1A kap. 6 og Bilag 1B – Analyse, rapportering og styringsinformasjon (1.4.3, 1.4.5) samt Integrasjoner og datautveksling (1.5.3)

8. Pris evalueres etter årlig gjennomsnittspris over 3 år, men konkurransegrunnlaget viser kun "Total tilbudssum år 1" i prismatrisen (Bilag 7). Kan dere bekrefte hvordan pris skal fylles ut for år 2 og år 3 (om det finnes flere ark/kolonner i prismatrisen), og om implementerings-/integrasjons-/opplæringsposter engangskostnader skal fordeles eller inngår fullt i år 1?

   Hvorfor det er verdt å spørre: Leverandøren må forstå evalueringsgrunnlaget og hvordan prismatrisen faktisk skal fylles for å gi riktig tilbud.

   Kilde: Konkurransegrunnlag kap. 6 (Pris 40% og evalueres etter årlig gjennomsnittspris over 3 år) samt Bilag 7 – Prismatrise

9. I Bilag 13/krav om universell utforming (1.7.11) og teknisk tilgjengelighet (universell uforming/testbase) ber dere beskrive hvordan dette ivaretas. Hvilken standard/tilgjengelighetsnivå forventes (f.eks. WCAG-nivå), og skal dette dokumenteres gjennom leverandørens tilgjengelighetserklæring/testresultater ved tilbud?

   Hvorfor det er verdt å spørre: Tilgjengelighetsnivå må være tydelig for å kunne svare presist og unngå avvik eller etterfølgende krav som kan gi merkost.

   Kilde: Bilag 1B – Teknisk løsning, sikkerhet og forvaltning (1.7.11) og Bilag 13 (universell utforming)