Kunngjøring av konkurranse · 2026-110524

KI - Turnusplanleggingsverktøy

OppdragsgiverNamsos Kommune

Frist 26.06.2026

Oppdragsgiver
Namsos Kommune
Frist
26.06.2026
Publisert
13.06.2026
Utførelsessted
Trøndelag/Trööndelage (NO060), Norge
Dokumentportal
MERCELL

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?

Om oppdraget

Konkurransen gjelder levering av KI-støttet, skybasert verktøy for turnusplanlegging innenfor helse og omsorgsområdet.Anskaffelsen gjennomføres etter anskaffelsesforskriftens del I.

Tjenesteområde

  • Programmering 72212332
  • Scheduling and productivity software package 48332000
  • Time accounting or human resources software package 48451000

Tilbudsstrategi

  • 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 Namsos Kommune

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

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.

Dette må kontrolleres i originaldokumentene
  • 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.
Viktige kontraktskrav
  • Løsningen skal holde seg oppdatert ved regelverksendringer, med strategi for løpende oppdatering.1.1.1 Generelle behov
  • Eventuelle tredjepartslisenser/utvidelser til andre systemer inngår i oppgitt pris.1.1.2 Generelle behov
  • Løsningen skal tilfredsstille til enhver tid gjeldende krav til universell utforming.1.1.6 Generelle behov
  • Løsningen er skybasert og plattformuavhengig med single sign-on (SSO) og rollebasert tilgangsstyring.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).1.4.6 IKT og tilgangsstyring
  • Leverandøren skal ha rutiner for sikkerhetskopiering etter standardiserte prinsipper.1.4.7 IKT og tilgangsstyring
  • Leverandøren skal ha definerte frister for RPO/RTO som fremgår av SLA.1.4.8 IKT og tilgangsstyring
  • Leverandøren skal ha risikovurdering dokumentert (kan fremvises), samt beredskaps- og kontinuitetsplaner i henhold til SLA.1.5.1-1.5.2 Informasjonssikkerhet

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 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.

    Uklare prestasjonsmål gjør det vanskelig å prise kapasitet, drift, implementering og eventuelle optimaliseringer.

    1.2.32
  • 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?

    Oppdragsgiver bør bekrefte om dette er et ytelses- eller funksjonskrav, og hvilke leveranser som forventes før prising/tilpasning.

    1.2.35
  • 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?

    Prioriteringslogikk påvirker både løsningsdesign og implementasjonsomfang; uklar styring gir risiko for feildimensjonering.

    1.2.28
  • 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)?

    Utydelig forventning til rapportering/dashboards påvirker utvikling, kravspesifikasjon og tilbudt funksjonalitet.

    1.2.34
  • 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?

    Manglende detalj på regelmotor/konfigurerbarhet kan medføre betydelig utviklings- og testomfang.

    1.2.40, 1.2.44
  • 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?

    Datatilgang, bruksområde og modelloppsett er avgjørende for omfang, integrasjoner og risiko.

    1.2.42 og 1.5.13–1.5.14
  • 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)?

    Integrasjons- og datamappingdetaljer påvirker både kostnad og leveranseplan; uklarhet skaper høy risiko.

    1.2.46
  • 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?

    «Alle typer» og «beste» er omfattende; oppdragsgiver må konkretisere forventet omfang og evalueringslogikk for å kunne prise riktig.

    1.2.15–1.2.16
  • 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?

    Kostnadsberegning krever klare formler og datakilder; uten spesifikasjon kan tilbudet få feil premisser.

    1.3.6
  • 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)?

    Tydelig avgrensning av kostnadsdrivere for uttrekk reduserer risiko for uforutsette tillegg.

    1.4.6

Konkurransedokumenter

Last ned dokumentpakke (23.2 KB)

Dokumentpakken er hentet automatisk fra MERCELL 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.