Sammenhengende vaktplanlegging: La historikken følge med inn i neste måned

Mange planleggingsverktøy behandler hver uke eller måned som et eget prosjekt. Det kan fungere for en enkel ukeplan, men i praksis henger periodene sammen.

En medarbeider som hadde nattevakt 31. juli, kan trenge fri 1. august. Den som tok mange nattevakter i juli, bør ikke uten videre stå først i køen i august. Og en rytme med dagvakt, nattevakt og fri bør ikke starte på nytt bare fordi kalenderen viser en ny måned.

Sammenhengende vaktplanlegging tar hensyn til nettopp dette.

Historikken er en del av grunnlaget

Når en ny plan lages, leser systemet også tidligere vakter. Du får fortsatt bare nye tildelinger i perioden du har bedt om, men KI-en kjenner arbeidshistorikken før periodestart.

Det er viktig for regler og mål som går på tvers av uke- og månedsskifter:

• hvile etter nattevakter;
• maksimalt antall arbeidsdager på rad;
• ukentlige timegrenser;
• overlapping med vakter som går over midnatt;
• rytmer som dag, natt og fri;
• fordeling av belastende vakter;
• jevnere samlet timetall over tid.

Uten dette grunnlaget kan en plan se gyldig ut isolert sett, men fungere dårlig når den settes sammen med det medarbeiderne allerede har jobbet.

Månedsskiftet er bare en dato

Ledere planlegger gjerne én uke, to uker eller én måned om gangen. Arbeidsbelastningen nullstilles likevel ikke ved periodestart.

En søndagsnatt kan kreve fri på mandag. Fem arbeidsdager rett før den nye perioden kan allerede ha brukt opp grensen for sammenhengende arbeid. Starter planen midt i uken, gjelder fortsatt ukens timegrense. En nattevakt kan dessuten begynne før perioden og slutte inne i den.

Den valgte perioden bestemmer hvilke datoer systemet skal planlegge. For å ta gode beslutninger trenger det også informasjon om dagene før.

Tre tidsvinduer for tre ulike formål

Du kan fortsatt be om en plan for inntil 31 dager. Systemet henter automatisk inn historikk før startdatoen:

Ingen vakter opprettes, endres eller bemannes før startdatoen du har valgt. Historikken brukes bare som grunnlag for nye tildelinger innenfor planperioden.

Hvorfor skille mellom disse historikktypene?

Noen tidligere vakter gjør en ny tildeling umulig. Hvis en person jobbet natt i går og regelen krever fri i dag, må systemet behandle det som et ufravikelig forhold.

Annen historikk hjelper med å fordele arbeidet bedre. Mange nattevakter de siste to månedene taler for at en annen kvalifisert medarbeider får den neste. Det skal likevel ikke føre til at en vakt blir stående ubemannet når en gyldig tildeling finnes.

Derfor skilles det mellom:

• constraintHistory for krav som må håndheves;
• fairnessHistory for vurdering av fordelingen;
• publicHolidayFairnessContext for helligdagstimer over en lengre periode.

Det korte tidsvinduet bidrar til å hindre ugyldige tildelinger. De lengre vinduene brukes til å forbedre balansen uten å endre gamle vakter.

De siste sju dagene: Hvile, timer og overganger

Systemet leser sju dager før den valgte startdatoen, fromDate, for å kontrollere:

• hvile etter bestemte vaktmaler;
• arbeidsdager på rad;
• daglige og ukentlige timegrenser;
• overlappinger;
• nattevakter som fortsetter inn i den nye perioden;
• fleksible rotasjonsmønstre, som dag, natt og fri.

Starter planen 1. august og en medarbeider hadde nattevakt 31. juli, kan 1. august bli behandlet som en påkrevd hviledag. Julivakten blir ikke endret. Den brukes bare for å ta riktig beslutning for august.

De siste 60 dagene: Jevnere fordeling

Dette tidsvinduet brukes til vurdering og balansering av planen, blant annet:

• samlet timetall per medarbeider;
• fordelingen mellom ulike vaktmaler;
• antall nattevakter;
• om enkelte personer nylig har fått en stor andel av belastende vakttyper.

Hvis Alice har hatt mange nattevakter de siste 60 dagene, og Bob også er kvalifisert, kan systemet foretrekke Bob på neste nattevakt når det er gjennomførbart.

Det garanterer ikke en perfekt fordeling. Det gir likevel et bedre utgangspunkt enn å behandle hver måned som en helt ny start.

Helligdager krever et lengre perspektiv

Helligdagsarbeid forekommer sjeldnere enn vanlige dag- og nattevakter. To måneder sier ofte for lite. Derfor ser Shift Scheduler 365 dager tilbake og teller netto arbeidstimer på datoene i arbeidsområdets helligdagskalender.

Pauser trekkes fra, nattevakter føres på startdatoen, og arbeid ved alle arbeidssteder i arbeidsområdet tas med.

For nye medarbeidere justeres sammenligningen slik at helligdager før medarbeideroppføringen ble opprettet, ikke fremstår som dager vedkommende har sluppet å jobbe. Beregningen bruker teamets gjennomsnittlige timer på helligdagene i perioden den enkelte har vært med. For etablerte medarbeidere som faktisk har null historiske helligdagstimer, beholdes nullverdien.

Denne justerte historikken kombineres med helligdagsvakter som allerede finnes i målperioden, og med de nye tildelingene som vurderes. Først ivaretas bemanningsdekning, ufravikelige krav og timemål. Deretter forbedres helligdagsfordelingen blant løsninger som bevarer disse prioriteringene.

Bemanningsbehovet kommer først

Historikken skal ikke føre til at nødvendige vakter står tomme bare for å få penere fordelingstall.

Første beregningstrinn fyller så mange vakter som mulig innenfor de ufravikelige kravene. Rettferdighet vurderes deretter. Historikken kan altså påvirke hvem som får en vakt, uten at en vakt som lar seg bemanne, bevisst blir stående ledig av fordelingshensyn.

Etter at dekningen er ivaretatt, kan systemet også arbeide mot et konkret timemål. Hvis du for eksempel oppgir 7,5 timer per virkedag, kan det legge til vakter utover de ledige plassene for å nå tallet for hver medarbeider. Se guiden om timemål per måned.

Ufravikelige krav setter rammene for en gyldig plan. Bemanningsdekningen er det viktigste driftsmålet. Historikken bidrar til en bedre fordeling innenfor disse rammene.

Hvordan bruker CP-SAT historikken?

Shift Scheduler beregner planene med CP-SAT. Motoren vurderer blant annet hvem som kan ta hver vakt, hvilke vakter som overlapper, tilgjengelighet, timetall, hvile, fordeling og rotasjoner.

Historikken utvider grunnlaget med det som nylig har skjedd. Spørsmålet blir dermed: «Hvem kan ta denne vakten, gitt det de allerede har jobbet?»

Eksempel: Nattevakter over to måneder

Anta at Alice hadde åtte nattevakter i juli og Bob hadde to. Begge kan jobbe natt, og det er fire nye nattevakter som skal fordeles i august.

Hvis juli ignoreres, kan de bli behandlet som om belastningen var lik ved inngangen til august. Med historikk ser systemet at Alice nylig har tatt en større andel. Når reglene tillater det, kan flere av de nye nattevaktene gå til Bob eller andre kvalifiserte medarbeidere.

Det reduserer risikoen for at de samme personene opplever å få de belastende vaktene om og om igjen.

Eksempel: Hvile over månedsskiftet

Si at regelen er:

Etter en nattevakt skal medarbeideren ha minst én dag fri.

Alice jobber 31. juli kl. 19.00–07.00, og en dagvakt må bemannes 1. august. Ser systemet bare på august, kan det overse nattevakten. Med sjudagershistorikken ser det at Alice må ha fri, og lar være å tildele henne dagvakten.

Eksempel: En plan som starter på onsdag

Når den nye planen begynner midt i uken, kan medarbeiderne allerede ha jobbet mandag og tirsdag. Disse timene må telle mot den samme ukesgrensen.

Historikken gjør det mulig å kontrollere uken samlet og unngå at timegrensen overskrides fordi planperioden starter på en annen dag. Det er særlig relevant der arbeidstid reguleres av lovverk eller avtaler, som innen helse, servering og handel.

Hva funksjonen ikke gjør

Historikken brukes ikke til å fylle vakter før den valgte startdatoen, og gamle vakter skrives ikke om. Datagrunnlaget består av ordinære vakter, ikke selve fraværssøknadene.

Funksjonen løser heller ikke alle tenkelige rotasjonsoppsett. Nøyaktige gjentakende mønstre uten et fastlagt startpunkt krever støtte for uttrykkelige ankerdatoer i en senere versjon. Dagens løsning håndterer først og fremst fleksibel videreføring, der tidligere arbeid for eksempel utløser hvile i den nye perioden.

Planperioden er fortsatt begrenset til 31 dager. Historikkvinduene er ekstra informasjon til beregningen, ikke flere dager det planlegges vakter på.

Dette betyr det i praksis

Du velger perioden som før. Systemet henter sju dagers historikk for krav og begrensninger, 60 dager for fordeling av timer og vakttyper og 365 dager for helligdagsarbeid. Nye tildelinger opprettes bare innenfor perioden din.

Dermed kan reglene og fordelingen følge medarbeiderne gjennom uke- og månedsskifter, uten at du må beskrive de siste vaktene på nytt hver gang.

Ofte stilte spørsmål

Hva er sammenhengende vaktplanlegging?

Det betyr at tidligere vakter brukes som grunnlag når en ny plan lages. Regler og fordelingshensyn videreføres på tvers av uker og måneder i stedet for å starte på nytt hver periode.

Hvorfor trenger KI-planleggingen historikk?

Hviletid, ukentlige timegrenser, nattarbeid og rotasjonsmønstre går ofte over periodegrensene. Uten historikk kan en plan se gyldig ut alene, men bli urimelig eller bryte krav når tidligere arbeid tas med.

Planlegger Shift Scheduler mer enn 31 dager om gangen?

Nei. Den valgte planperioden kan være inntil 31 dager. Historikken før perioden er bare beregningsgrunnlag, ikke ekstra planleggingsdager.

Kan systemet opprette vakter før startdatoen?

Nei. Historiske vakter leses som bakgrunnsinformasjon. Nye tildelinger opprettes bare innenfor perioden du har bedt om.

Hvordan hjelper historikken med å fordele nattevakter?

Systemet ser hvem som nylig har hatt mange nattevakter. Når flere kvalifiserte personer kan ta den neste, kan det foretrekke noen med færre nattevakter i den siste tiden.

Hvilken beregningsmotor brukes?

Shift Scheduler bruker CP-SAT, en motor for optimering med begrensninger. Den egner seg godt til å beregne vaktplaner med krav til blant annet hvile, timetall og rettferdig fordeling.

Bedre sammenheng, samme enkle forespørsel

Du trenger fortsatt bare å velge perioden du vil planlegge. Ved å ta med relevant historikk får systemet et mer realistisk grunnlag for å følge reglene og fordele arbeidet bedre over tid.