KI - Turnusplanleggingsverktøy

Behovsbeskrivelse for en skybasert turnusgenerator (KI-Turnusgenerator) som skal støtte turnus-/arbeidsplanlegging, rapportering, eksport og integrasjon mot Visma Ressursstyring, samt oppfylle funksjonelle krav og krav til sikkerhet, tilgangsstyring, universell utforming og informasjonssikkerhet.

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

26.06.2026

Språk

norsk

Elektronisk katalog

Ikke tillatt

• Løsningen skal holde seg oppdatert ved regelverksendringer, med strategi for løpende oppdatering.Kilde: 1.1.1 Generelle behov
• Eventuelle tredjepartslisenser/utvidelser til andre systemer inngår i oppgitt pris.Kilde: 1.1.2 Generelle behov
• Løsningen skal tilfredsstille til enhver tid gjeldende krav til universell utforming.Kilde: 1.1.6 Generelle behov
• Løsningen er skybasert og plattformuavhengig med single sign-on (SSO) og rollebasert tilgangsstyring.Kilde: 1.4.1-1.4.2 IKT og tilgangsstyring
• Oppdragsgiver skal ha full tilgang til egne data og uttrekk skal være kostnadsfritt (medgått tid til rådgivning/opplæring/tilpasninger kan belastes).Kilde: 1.4.6 IKT og tilgangsstyring
• Leverandøren skal ha rutiner for sikkerhetskopiering etter standardiserte prinsipper.Kilde: 1.4.7 IKT og tilgangsstyring
• Leverandøren skal ha definerte frister for RPO/RTO som fremgår av SLA.Kilde: 1.4.8 IKT og tilgangsstyring
• Leverandøren skal ha risikovurdering dokumentert (kan fremvises), samt beredskaps- og kontinuitetsplaner i henhold til SLA.Kilde: 1.5.1-1.5.2 Informasjonssikkerhet
• Leverandøren skal ha endringshåndteringsprosess som varsler kommunen ved endringer/vedlikehold som krever nedetid.Kilde: 1.5.3 Informasjonssikkerhet
• Leverandøren skal ha prosess for opplæring av egne ansatte i informasjonssikkerhet og personvern, og prosess for løpende sikkerhetsoppdatering av alle komponenter.Kilde: 1.5.4-1.5.5 Informasjonssikkerhet
• Leverandøren skal ha avvikssystem for informasjonssikkerhet og personvern.Kilde: 1.5.7 Informasjonssikkerhet
• Leverandøren skal logge forsøk på autorisert/ uautorisert tilgang samt relevante sikkerhetshendelser (sikkerhetslogger og systemlogger).Kilde: 1.5.8 Informasjonssikkerhet
• Logger skal ikke kunne slettes før etter gitt periode; det skal kunne settes opp automatisk sletting for å ivareta lagringsbegrensning.Kilde: 1.5.9 Informasjonssikkerhet
• Det skal være funksjonalitet for autoriserte til å aksessere/søke i logger.Kilde: 1.5.10 Informasjonssikkerhet
• Jevnlig sikkerhetstesting minst en gang per år med ekstern leverandør (bl.a. sårbarheter i applikasjon/webapp, system, nettverk, og sosial manipulering).Kilde: 1.5.11 Informasjonssikkerhet
• Sikkerheten skal følge anbefalinger fra NSM grunnprinsipper.Kilde: 1.5.12 Informasjonssikkerhet
• Validering og testing av KI-modellen for nøyaktighet, bias og robusthet før den tas i bruk; trening uten å kompromittere personvern (anonymisering/syntetiske data).Kilde: 1.5.13-1.5.14 Informasjonssikkerhet
• Leverandøren skal legge til rette for revisjon/kontroll: deltakere kan revidere systemet og få innsyn i hvordan det fungerer.Kilde: 1.5.15 Informasjonssikkerhet
• Leverandøren skal ha styringssystem for informasjonssikkerhet som dekker mennesker, teknologi og prosesser.Kilde: 1.6.1 Styringssystem for informasjonssikkerhet
• Oppdragsgiver skal få tilgang til nødvendig informasjon for å gjøre revisjon av informasjonssikkerheten.Kilde: 1.6.2 Styringssystem for informasjonssikkerhet
• Alle som behandler kommunens data skal ha signert taushetserklæring og være informert om taushetsplikt og konsekvenser ved brudd.Kilde: 1.6.3 Styringssystem for informasjonssikkerhet
• Prosedyre som sikrer at databehandlingsansvarlig varsles umiddelbart ved uautorisert utlevering/endring av personopplysninger eller andre sikkerhetsbrudd.Kilde: 1.6.4 Styringssystem for informasjonssikkerhet
• Leverandøren skal kunne levere teknisk skisse med beskrivelse av alle komponenter i sikkerhetsarkitekturen.Kilde: 1.6.5 Styringssystem for informasjonssikkerhet
• Løsningen skal eksportere anonymiserte data til bruk i eksterne KI-løsninger.Kilde: 1.1.12 Generelle behov
• Løsningen skal kunne eksportere data inn i Visma Ressursstyring.Kilde: 1.1.14 Generelle behov
• Løsningen skal ha fritt tilgjengelig e-læring i hele kontraktsperioden.Kilde: 1.2.53 Funksjonelle behov

• Tekst inneholder ikke eksplisitte tildelingskriterier, innleveringskrav eller formelle kvalifikasjonskrav (ingen slike seksjoner/krav er gjengitt i utdraget).
• Flere krav er behovs-/funksjonsbeskrivelser uten målemetode (f.eks. ‘full turnus på under 16 timer’, ‘predikere sykefravær’)—det fremgår ikke om dette er ytelseskrav eller bare ønsket funksjon.

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 Vedlegg 1 (arkfanen «Behov») punkt 1.2.32 står det at «Løsningen genererer en full turnus på under 16 timer». Hva mener oppdragsgiver med «under 16 timer» – faktisk beregningstid (CPU/queue), end-to-end svartid fra start til ferdig generert plan, eller tidsforbruk for brukeren? Ber vi om kriterier/forutsetninger (datamengde, antall ansatte per avdeling, antall vaktlinjer, turnuslengde) som «under 16 timer» skal verifiseres mot.

   Hvorfor det er verdt å spørre: Uklare prestasjonsmål gjør det vanskelig å prise kapasitet, drift, implementering og eventuelle optimaliseringer.

   Kilde: 1.2.32

2. Vedlegg 1 (arkfanen «Behov») punkt 1.2.35 beskriver en «pre-generering»/innledende sjekk før generering. Hvilke konkrete kontroller skal inngå (f.eks. manglende helgemønster/ferieinnspill, manglende kompetansetilgjengelighet, manglende vaktkoder), og hvordan skal varsler/avvik presenteres (skjerm/dashbord/rapport) og håndteres i arbeidsflyten?

   Hvorfor det er verdt å spørre: Oppdragsgiver bør bekrefte om dette er et ytelses- eller funksjonskrav, og hvilke leveranser som forventes før prising/tilpasning.

   Kilde: 1.2.35

3. Vedlegg 1 (arkfanen «Behov») punkt 1.2.28 angir en prioriteringsrekkefølge for generering («AML - Fylle bemanningsplanen- tilrettelegginger - ramme - ønsker») og at den kan «endre og vektes ulikt» og «tilpasses etter første generering». Hvordan skal dette parameterstyres i praksis (oppsett i løsning, nivåer/vekter pr. avdeling, og om oppdragsgiver kan endre uten leverandørtilpasning), og hvilke standardinnstillinger forventes ved oppstart?

   Hvorfor det er verdt å spørre: Prioriteringslogikk påvirker både løsningsdesign og implementasjonsomfang; uklar styring gir risiko for feildimensjonering.

   Kilde: 1.2.28

4. Vedlegg 1 (arkfanen «Behov») punkt 1.2.34 beskriver rekkefølge for dekning «Helger (natt, kveld, dag), ukedager (natt, kveld, dag)» og at det «lager rapport på dette eller dashboard». Hvilke rapport-/dashboardkrav gjelder konkret (f.eks. hvilke avviksdefinisjoner, hvordan graderes/kvantifiseres avvik per tidskategori, og hvilke brukerroller skal se hva)?

   Hvorfor det er verdt å spørre: Utydelig forventning til rapportering/dashboards påvirker utvikling, kravspesifikasjon og tilbudt funksjonalitet.

   Kilde: 1.2.34

5. Vedlegg 1 (arkfanen «Behov») punkt 1.2.40 og 1.2.44 beskriver styring av «mønstre»/tilrettelegging og «helger» samt mulighet for manuell styring av «enkelte datoer» og andre tilrettelegginger. Kan oppdragsgiver spesifisere hva som menes med minimum sett av støttede mønstertyper/regler (f.eks. partallsuker/dager, langvakter/ikke langvakter, faste helgemønstre), og om oppdragsgiver forventer at alle mønstre skal konfigureres uten leverandørutvikling?

   Hvorfor det er verdt å spørre: Manglende detalj på regelmotor/konfigurerbarhet kan medføre betydelig utviklings- og testomfang.

   Kilde: 1.2.40, 1.2.44

6. Vedlegg 1 (arkfanen «Behov») punkt 1.2.42 «Løsningen kan predikere sykefravær» og 1.5.13–1.5.14 omfatter testing og trening av KI-modell. Hvilket prediksjonsgrunnlag forventes (hvilke historiske sykefraværsdata, tidsoppløsning, hvor lenge historikk), og skal prediksjonen brukes som anbefaling ved planlegging eller som automatisk input i generering?

   Hvorfor det er verdt å spørre: Datatilgang, bruksområde og modelloppsett er avgjørende for omfang, integrasjoner og risiko.

   Kilde: 1.2.42 og 1.5.13–1.5.14

7. Vedlegg 1 (arkfanen «Behov») punkt 1.2.46 beskriver at løsningen henter ansatte fra «Visma Ressursstyring» og tar med innstillinger som AML avtale, stillingsprosent, kompetanse/stillingskode og avtalt F3 beregning. Hvilke eksakte datapunkter/ID-er er nødvendig (feltnavn/logiske datatyper), og hvordan skal det sikres mapping ved endringer i kildesystemet (f.eks. versjonering/kontraktsmessig stabilitet)?

   Hvorfor det er verdt å spørre: Integrasjons- og datamappingdetaljer påvirker både kostnad og leveranseplan; uklarhet skaper høy risiko.

   Kilde: 1.2.46

8. Vedlegg 1 (arkfanen «Behov») punkt 1.2.15 («Løsningen kan lage alle typer turnuser…») og punkt 1.2.16 (fritt valg av alternative turnuser basert på input). Hvilke konkrete turnustyper og eksempler på «input» og «beste turnus»-kriterier forventer oppdragsgiver (f.eks. definert maks avvik, minimer vakante linjer, helgebelastning), og hvordan skal det måles/legges til grunn for valg mellom alternativer?

   Hvorfor det er verdt å spørre: «Alle typer» og «beste» er omfattende; oppdragsgiver må konkretisere forventet omfang og evalueringslogikk for å kunne prise riktig.

   Kilde: 1.2.15–1.2.16

9. Vedlegg 1 (arkfanen «Behov») punkt 1.3.6 «Løsningen kan kostnadsberegne den genererte turnusen». Hvilke kostnadselementer skal inngå (f.eks. lønnssatser pr. kompetanse, overtid/tillegg, helgetillegg, matpause, vikar-/stillingsøkning), hvilke kildesystemer og satser skal benyttes, og hvem eier/leverer satstabeller?

   Hvorfor det er verdt å spørre: Kostnadsberegning krever klare formler og datakilder; uten spesifikasjon kan tilbudet få feil premisser.

   Kilde: 1.3.6

10. Vedlegg 1 (arkfanen «Behov») punkt 1.4.6 sier at «Uttrekk er kostnadsfritt bortsett fra medgått tid til rådgivning, opplæring og tilpasninger». Hvilke typer uttrekk forventes (omfang/frekvens), og hvordan defineres «medgått tid» og «tilpasninger» ved uttaksforespørsler (f.eks. standardrapporter vs. ad-hoc behov)?

    Hvorfor det er verdt å spørre: Tydelig avgrensning av kostnadsdrivere for uttrekk reduserer risiko for uforutsette tillegg.

    Kilde: 1.4.6