Digital turnusgenerator

Asker kommune ønsker en digital turnusgenerator som støtter utarbeidelse, kontroll, forklaring, justering, godkjenning og publisering av turnuser. Løsningen skal baseres på gjenbruk av grunndata og minimere manuelt arbeid/feilkilder, gi validering før generering med forståelige avvik og konsekvensvisning ved manuelle justeringer, samt ha dataflyt mot GAT for å redusere dobbeltregistrering. Kravene dekker funksjonalitet (inkl. ansattportal), brukervennlighet, IKT-arkitektur, digitalt økosystem (API/hendelser), IDM/IAM, infrastruktur/nettleser- og plattformstøtte, skytjenester, og informasjonssikkerhet/personvern/GDPR. (SSA-L Bilag 1: Kundens kravspesifikasjon).

• Leverandøren skal oppgi hvordan løsningen sikrer korrekt grunnlag for turnusgenerering (alle underpunkter beskrevet som minimum).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.1 (Id 4.1)
• Leverandøren skal oppgi og dokumentere at løsningen har en ansattportal (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.1, punkt 4.1.10
• Leverandøren skal beskrive hvordan ansattportalen sikrer at ansatte får medvirke gjennom egne ønsker (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.1, punkt 4.1.11
• Leverandøren skal beskrive hvordan validering før turnusgenerering gir tydelige varsler om feil/mangler (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.2
• Leverandøren skal beskrive hvordan løsningen sikrer korrekt, effektiv og forståelig generering (alle underpunkter som minimum).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.3 (Id 4.3)
• Leverandøren skal beskrive hvordan løsningen støtter effektiv kvalitetskontroll etter ferdig generert turnus (alle underpunkter som minimum).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.4 (Id 4.4)
• Leverandøren skal beskrive hvordan ferdigstilt turnus overføres til gjeldende turnussystem, og om det er integrasjon samt mulighet for validering ved overføring (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.5
• Leverandøren skal beskrive hvordan de vil involvere og gi kunden mulighet til å påvirke videreutvikling (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.6
• Leverandøren skal demonstrere representative oppgaver for ansatte, ledere og superbrukere for å vise intuitiv arbeidsflate (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 5.1
• Leverandøren skal demonstrere ansattfunksjoner på mobil og PC og beskrive tilgjengelige språk (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 5.2
• Leverandøren skal demonstrere relevante visninger og filtre for bemanning, ferie, fravær, helg, behov og avvik (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 5.3
• Leverandøren skal demonstrere hvordan brukskvalitet er testet og dokumentert (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 5.4
• Leverandøren skal demonstrere brukerstøtte (chatbot/KI) og hvilke brukerstøttekanaler/språk som støttes (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 5.5
• Leverandøren skal beskrive tilbyders forhold til bruk av mellomvare (Anypoint Platform/Mule lokalt) (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 6.1
• Leverandøren skal beskrive hvilke API-er løsningen tilbyr (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 6.2
• Leverandøren skal beskrive foretrukket integrasjonsarkitektur og hvordan løsning mottar/avgir data til integrerte systemer (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 6.3
• Leverandøren skal beskrive tidligere relevante integrasjoner (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 6.4
• Leverandøren skal beskrive hvordan løsningen tilbyr åpne API-er (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 7.1
• Leverandøren skal beskrive hvordan autentisering og autorisasjon sikres for API-informasjonsflyt (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 7.2
• Leverandøren skal beskrive hvilke formater (XML/JSON) som brukes for datautveksling (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 7.3
• Leverandøren skal beskrive hendelsesbasert informasjonsutveksling (WebHooks eller publish/subscribe) (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 7.4
• Leverandøren skal beskrive hvordan datautveksling krypteres (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 7.5
• Leverandøren skal beskrive hvordan brukerhåndtering kan automatiseres og integreres med kommunens IDM-plattform (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 8.1
• Leverandøren skal beskrive hvordan løsningen støtter SSO med Microsoft Entra ID eller tilsvarende (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 8.2
• Leverandøren skal beskrive hvordan krav om støttede moderne nettlesere ivaretas, samt at det ikke er behov for nettleserutvidelser (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 9.1
• Leverandøren skal beskrive eventuelle krav til sertifikater, sikre kommunikasjonsprotokoller og brannmuråpninger (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 9.2
• Leverandøren skal beskrive støttede plattformer og eventuelle begrensninger for konsistent funksjon i innebygd nettleser (iOS/Android/PC) (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 9.3
• Leverandøren skal beskrive rutiner for kompatibilitetstesting og varsling ved kjente problemer pga oppdateringer/sikkerhetsoppdateringer (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 9.4
• Leverandøren skal beskrive kommunikasjon mellom sky og lokale løsninger (dataoverføringer og integrasjoner) og legge ved skisse (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.1
• Leverandøren skal beskrive hvordan datasegregering sikres mellom kunder og mellom tjenester (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.2
• Leverandøren skal beskrive rutiner/tiltak for sikkerhetskopiering og reservedrift (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.3
• Leverandøren skal beskrive hvordan tjenesten beskyttes mot DDoS (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.4
• Leverandøren skal beskrive format, prosess og eventuelle kostnader for tilbakelevering av kundedata ved behov/kontraktsavslutning (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.5
• Leverandøren skal beskrive hvordan andre kunders aktivitet ikke medfører uakseptabel risiko (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.6
• Leverandøren skal beskrive datalokalitet (innen EU/EØS og helst Norge), underleverandører og overføringsmekanismer (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.7
• Leverandøren skal beskrive støtte for rollebasert tilgangsstyring og tiltak mot for høye privilegier (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.8
• Leverandøren skal beskrive sitt forhold til personvernregelverket (GDPR) og hvordan det implementeres (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.1
• Leverandøren skal beskrive hvordan behandling og lagring av personopplysninger er dokumentert (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.2
• Leverandøren skal beskrive innebygd personvern og standardinnstilling for personvern (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.3
• Leverandøren skal bekrefte at databehandleravtale inngås, som hovedregel etter kommunens mal (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.4
• Leverandøren skal beskrive levende styringssystem for informasjonssikkerhet (ISMS) og legge ved relevant dokumentasjon ved sertifisering (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.5
• Leverandøren skal beskrive hvordan konsekvenser ved brudd på taushetsplikt er beskrevet/kommunisert i organisasjonen (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.6
• Leverandøren skal beskrive tiltak som hindrer teknisk personell i å misbruke autorisasjon (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.7
• Leverandøren skal beskrive loggfunksjoner: logging av tilgang til personopplysninger, sikkerhetshendelser og endringer; hvem hva når; inkl. lagringstid og kontroll (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.8
• Leverandøren bør beskrive rutiner for personellsikkerhet (bakgrunnssjekk der relevant, oppfølging ved rolleendring/avslutning) (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.9
• Leverandøren bør beskrive hvordan krav til konfidensialitet, integritet og tilgjengelighet ivaretas (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.10
• Leverandøren bør beskrive hvordan personopplysninger krypteres ved lagring (BØR-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.11

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

15.10.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Databehandleravtale skal inngås mellom leverandør og kommune ved behandling av personopplysninger (MÅ i kravspesifikasjonen; også kontraktsmessig krav i SSA-L).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.4; samt SSA-L generell_avtaletekst 2026, pkt. om databehandleravtale og forrang
• Løsningen skal støtte/benytte siste versjon av moderne nettlesere (Edge, Safari, Firefox, Chrome) uten behov for nettleserutvidelser (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 9.1
• Skytjeneste: kommunikasjon mellom sky og lokale løsninger skal være ivaretatt og beskrevet (inkl. skisse) (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.1
• Skytjeneste: datasegregering mellom kunder og mellom tjenester skal sikres (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.2
• Skytjeneste: leverandøren skal ha sikkerhetskopiering og reservedrift (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.3
• Skytjeneste: beskyttelse mot DDoS (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.4
• Tilbakelevering av kundedata ved behov/kontraktsavslutning skal beskrives (inkl. format/prosess/kostnader) (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.5
• Skytjeneste: løsning skal lagre data innen EU/EØS, helst i Norge (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 10.7
• Informasjonssikkerhet/GDPR: leverandøren skal følge GDPR og implementere personvern; behandling/lagring skal være dokumentert; innebygd personvern som standard.Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.1-11.3
• ISMS: leverandøren skal ha et levende styringssystem for informasjonssikkerhet, f.eks. ISO 27001/27002, og legge ved relevant dokumentasjon ved sertifisering (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.5
• Logging: systemet skal logge tilgang til personopplysninger, sikkerhetshendelser og endringer (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 11.8
• Ansattportal: løsningen skal ha ansattportal (MÅ-krav).Kilde: Vedlegg 1 - Kundens kravspesifikasjon, kap. 4.1.10
• SSA-L: Dokumentasjon og brukerveiledning skal gis på norsk (med mindre annet er avtalt) og være datert/nyeste versjon; og leverandør skal bistå med opplæring i den grad det er avtalt.Kilde: SSA-L generell_avtaletekst_2026, pkt. 3.4 Dokumentasjon og opplæring
• SSA-L: Ved avslutning skal leverandøren tilgjengeliggjøre/tilbakelevere kundedata (inkl. sikkerhetskopier etter kundens valg) og kan ikke tilbakeholde kundens data.Kilde: SSA-L generell_avtaletekst_2026, pkt. 5.3 Avslutning av avtalen; samt punkt 7.2 Rettigheter til data

• Vedlegg 1 beskriver MÅ/BØR-krav og hva leverandør må/bør beskrive/demonstrere, men teksten viser ikke eksplisitt hvilken evalueringsvekt eller tildelingsmodell som knytter BØR til poeng.
• Krav om SLA (bilag 4) er omtalt som at leverandør skal vedlegge standard SLA, men selve SLA-kravene/kompensasjonstallene er ikke konkretisert i den utleverte teksten (kun at leverandør skal vedlegge standard SLA som vedlegg).
• For 'integrieres mot GAT' fremkommer målsetning i innledning, men konkrete IDM-/API-/integrasjonskrav mot GAT er ikke eksplisitt detaljert i den viste delen av bilag 1.
• Noen underpunkter i funksjonalitetskrav har skrivefeil/uklar ID (f.eks. 4..1.2, 4.4.3/4.4.3.1) som kan påvirke presis identifisering av alle underkrav, men overordnet innhold er synlig.

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 (Krav til funksjonalitet) pkt. 4.1–4.5 er flere krav merket «Bør», men det fremgår ikke av det utleverte materialet hvordan disse «Bør»-besvarelsene konkret vektes i evalueringen. Kan dere bekrefte/oversette «Bør»-kravene til konkrete evalueringskriterier, underkriterievekt og/eller poengberegning slik at tilbyder kan prise og prioritere riktig?

   Hvorfor det er verdt å spørre: Tilbyder må vite hvilken effekt «Bør»-oppfyllelse har på scoring for å kunne allokere kostnader og dokumentasjon riktig.

   Kilde: Vedlegg 1 - Kundens kravspesifikasjon, pkt. 4.1–4.5

2. I Bilag 4 (Tjenestenivå med standardiserte kompensasjoner) ber dere leverandør legge ved sin standard SLA, og det listes spesifikke støtte-/responstidsområder (kjernetid 08:00–15:30 og utenfor kjernetid 15:30–23:00). Kan dere opplyse hvilke eksakte kompensasjonstall/satser og beregningslogikk som skal brukes ved brudd på disse punktene (og om det finnes nivåer utover responstid/avgjørelsestid), slik at vi kan prise SLA riktig?

   Hvorfor det er verdt å spørre: Uten kompensasjonsmatrise/satser er det vanskelig å prise risiko og foreslå tjenestenivå som matcher evaluerings- og sanksjonsregimet.

   Kilde: Bilag 4: Tjenestenivå med standardiserte kompensasjoner, Serviceavtale (SLA) og kompensasjonsrammer

3. I Vedlegg 1 (pkt. 8.1–8.2) ber dere om integrasjon mot kommunens IDM og støtte for SSO med Microsoft Entra ID eller tilsvarende. Kan dere spesifisere hvilken IDM-plattform Asker kommune benytter (produkt/leverandør) og hvilke konkrete integrasjonsbehov som forventes (f.eks. hvilke bruker-/rollehendelser som skal automatiseres og forventet metode: API/fil/Webhook), samt hvilke roller/tilgangsmodeller som skal kartlegges?

   Hvorfor det er verdt å spørre: Konkrete tekniske integrasjonsforutsetninger og rolle-/datamodeller styrer både løsning, kostnad og risiko.

   Kilde: Vedlegg 1 - Kundens kravspesifikasjon, pkt. 8.1–8.2

4. I Vedlegg 1 (pkt. 6.1–7.5) er det krav om integrasjons- og datadelingsmuligheter (Anypoint/Mule som mellomvare lokalt, standardiserte grensesnitt/API-er, API-sikkerhet, formater XML/JSON, samt hendelsesbasert informasjonsutveksling via WebHooks eller publish/subscribe). Kan dere bekrefte hvilke av disse integrasjonsformene som er faktiske integrasjonskrav for denne anskaffelsen (f.eks. hvilke systemer i kommunen skal integreres med), og hvilke som kun er «Bør»/valgfritt i evalueringen?

   Hvorfor det er verdt å spørre: Det er kritisk å vite omfanget av faktiske integrasjoner og hvilke teknologisporet som er evaluert/kravlagt for å kunne dimensjonere og prise riktig.

   Kilde: Vedlegg 1 - Kundens kravspesifikasjon, pkt. 6.1–7.5

5. I Vedlegg 1 (pkt. 4.1.8) oppgir dere: «Asker kommune beregner i dag fem feriedager pr uke. Hvordan løses dette i generatoren» (Bør-krav). Kan dere bekrefte hvordan feriedager i dagens praksis regnes inn i turnusberegningen (f.eks. timer per feriedag, håndtering av deltid/variasjoner per stilling, og hvordan dette slår ut ved helge-/helligdagsmønstre), samt gi et eksempel på forventet resultat?

   Hvorfor det er verdt å spørre: Ferieberegning påvirker turnuslogikken direkte og må forstås for å levere en generator som matcher kundens lokale beregningsregler og forventninger.

   Kilde: Vedlegg 1 - Kundens kravspesifikasjon, pkt. 4.1.8

6. I Vedlegg 1 (pkt. 4.5) ber dere at ferdigstilt turnus i generatoren overføres til «gjeldende turnussystem», og at leverandør som minimum skal beskrive om det er en integrasjon og mulighet for validering ved overføring. Kan dere opplyse hvilket turnussystem Asker kommune bruker (produkt/leverandør) og hvordan overføringen forventes (API, fil, andre mekanismer), samt om dere forventer automatisert validering mot turnussystemets regler?

   Hvorfor det er verdt å spørre: Turnussystemet og overføringsmekanismen bestemmer integrasjonskost, testopplegg og hvilke valideringer som er påkrevd.

   Kilde: Vedlegg 1 - Kundens kravspesifikasjon, pkt. 4.5

7. I Bilag 3 (Plan for etableringsfasen) står at planen «med mindre Kunden har noen klare milepæler … i utgangspunktet ikke fylles ut» og at «Den endelige planen legges ved av Kunden når den er utarbeidet (etter kontraktssignering)». Kan dere bekrefte om dere forventer en etableringsfase for denne anskaffelsen (ja/nei), og i tilfelle hvilke konkrete leverings-/akseptansemilepæler som normalt vil bli lagt inn i bilag 3 etter tildeling?

   Hvorfor det er verdt å spørre: Etableringsfase og milepæler påvirker bemanning, tidsplan, risiko og prising av fastpris/oppstart.

   Kilde: Bilag 3: Plan for etableringsfasen (pkt. om etableringsfase og milepæler)

8. I SSA-L generell avtaletekst pkt. 3.3 (godkjenningsprøve) benyttes standard godkjenningsperiode på 10 virkedager dersom ikke annet avtales i bilag 3. For denne løsningen: Kan dere bekrefte om dere ønsker å avvike fra 10 virkedager og/eller definere konkrete godkjenningskriterier/feilkategorier som skal brukes i testen før «Leveringsdag»?

   Hvorfor det er verdt å spørre: Godkjenningsprøve/feildefinisjoner påvirker prosjektplan og leveringsrisiko direkte, og bør avklares før tilbud.

   Kilde: SSA-L generell_avtaletekst_2026, pkt. 3.3 godkjenningsprøve og Leveringsdag

9. I SSA-L generell avtaletekst pkt. 4.5 (prisendringer) fremgår det at pris kan endres ved årsskifte tilsvarende KPI med mindre annet er avtalt i bilag 6. Kan dere bekrefte om bilag 6 vil inneholde avvik fra KPI-indeksering (og eventuelt hvilken indeks/avgrensning), slik at løpende vederlag kan prises med korrekt fremtidssensitivitet?

   Hvorfor det er verdt å spørre: Prisendringsmekanismer påvirker totaløkonomi og behovet for risikopremie i tilbudsprisene.

   Kilde: SSA-L generell_avtaletekst_2026, pkt. 4.5 Prisendringer / Bilag 6 Samlet pris og prisbestemmelser

10. I SSA-L generell avtaletekst pkt. 5.3 og avslutning/avvikling: Leverandøren skal yte «oppfølgende bistand i inntil 30 kalenderdager» og legge til rette for overføring av data/lisenser/oversikt. Kan dere spesifisere hvilket omfang dere forventer i avslutningsperioden for en turnusgenerator (f.eks. hvor mange timer, hvem som må delta, og hvilke konkrete leveranser/format som forventes), og om dette er ment som fast inkludert i vederlaget eller om det prises via bilag 6 timepriser?

    Hvorfor det er verdt å spørre: Avviklingsforpliktelser kan være betydelige kostnadsdrivere; omfanget må avklares for å prise riktig og unngå uforutsett risiko.

    Kilde: SSA-L generell_avtaletekst_2026, pkt. 5.3 Avslutning av avtalen (oppfølgende bistand og overføring)