Nødvendig bemanning og ønskede fridager kolliderer.
Ønskede fridager, etterspørsel per tidsrom og minimumsbemanning kontrolleres ofte manuelt samtidig.
SKIFT- OG BEMANNINGSOPTIMALISERING
Vi gjør betingelser som standard skiftverktøy ikke kan håndtere, om til en matematisk modell. Systemet lager kandidater som kan gjennomgås, slik at mennesker kan bekrefte resultatet mens de ser årsaker og unntak.
PROBLEM
Det vanskelige med å lage skiftplaner er ikke å skrive navn inn i en tabell. Det er å holde mange regler, ønsker og unntak konsistente.
Ønskede fridager, etterspørsel per tidsrom og minimumsbemanning kontrolleres ofte manuelt samtidig.
Ledere, sertifiserte medarbeidere, utstyrsoperatører eller ansvarspersoner må være til stede i bestemte tidsrom.
Nattvakter, helger, totalt antall vakter og krevende oppgaver bør ikke samles hos noen få personer.
Ett fravær eller én endring i etterspørsel kan gjøre hele tabellen ugyldig og tvinge frem sen omplanlegging.
Målet for automatisering er ikke selve regnearket. Det er den gjentatte vurderingen planleggeren gjør mens regnearket lages.
MODELLERING
Begreper som rettferdig, ikke sammenhengende, hold disse to adskilt og respekter ønskede fridager blir til data, harde betingelser, myke preferanser og en score.
Eksempel på målformel
underbemanning x 1000 + manglende kvalifikasjon x 1000 + brudd på ønske x 20 + ubalanse i arbeidsmengde x 5
Vektene er forklarende. I et reelt prosjekt settes harde betingelser og prioriteringer gjennom intervjuer og sammenligning med faktiske vaktplaner.
Ansatte, tilgjengelighet, ønskede fridager, kvalifikasjoner, nødvendig bemanning og gjeldende vaktplaner.
Regler som ikke bør brytes, som nødvendig bemanning, kvalifikasjoner og hvilegrenser.
Ønsker som bør respekteres når mulig, som fridager, foretrukne vakter og rettferdighet.
Vaktplankandidater, ikke oppfylte betingelser, årsaker, måltall og endringseffekt.
INTERAKTIV DEMO
Endre forretningsscenario, nødvendig bemanning, kvalifikasjonsdekning, preferanser, rettferdighet og grense for sammenhengende arbeid. Vaktplankandidaten, måltallene og gjennomgangsloggen oppdateres samlet.
Dette er en sidedemo med en enkel heuristikk. Den er ikke en driftsklar optimaliseringsmotor.
Bemanningsdekning
Kvalifikasjonsdekning
Ønsker oppfylt
Tildelingsforskjell
| Ansatt | Man | Tir | Ons | Tor | Fre | Lør | Søn |
|---|
REGELBIBLIOTEK
Eksemplene nedenfor modelleres trinn for trinn. Ikke alle betingelser bør implementeres samtidig; prioritet og tilgjengelige data avgjør første omfang.
COV-01
Hard regel
Sett minimums- og ønsket bemanning etter dag, tidsrom, lokasjon, avdeling og rolle.
COV-02
Preferanse
Øk anbefalt bemanning med salgsprognoser, reservasjoner, beboere, produksjonsvolum eller henvendelser.
LAB-01
Hard regel
Representer grenser for sammenhengende arbeid, hvile etter natt og interne intervallregler som er bekreftet.
LAB-02
Hard regel
Ta med ukentlige eller månedlige timer, grenser etter ansettelsestype og overtidsrammer.
SKL-01
Hard regel
Plasser nødvendige kvalifikasjoner, ansvarlige medarbeidere eller utstyrskompetanse i hvert tidsrom.
SKL-02
Preferanse
Unngå tidsrom med bare nye personer ved å pare dem med instruktører eller erfarne medarbeidere.
PRF-01
Preferanse
Skill utilgjengelighet fra ønskede fridager, og sett prioritet etter viktighet.
PRF-02
Preferanse
Reduser ubalanse i nattvakter, helger, senvakter, totalt antall tildelinger og tunge oppgaver.
PRF-03
Preferanse
Ta med kundekontinuitet, teamkompatibilitet og sterke kompetanseområder i tildelingspoengene.
SKREDDERSYDDE REGLER
Regler som aldri vises i generelle eksempler, er ofte grunnen til at skreddersydd modellering er nyttig.
RESULTATER
Et nyttig skiftsystem stopper ikke ved en vaktplantabell. Det forklarer hva som ble endret, hva som ikke kunne oppfylles, og hva mennesker bør sjekke.
Returner flere kandidater med ulike avveiinger i stedet for ett ugjennomsiktig svar.
Vis manglende dekning, ikke oppfylte ønskede fridager og betingelser som ikke kunne oppfylles.
Forklar hvorfor en person ble tildelt: kvalifikasjon, ønske, lavere nåværende belastning eller dekningsprioritet.
Når ett fravær oppstår, lås det som bør stå fast og beregn berørt område på nytt.
BRANSJEEKSEMPLER
En god vaktplan betyr ulike ting på ulike arbeidsplasser. Modellen bør bruke begrepene og prioriteringene driften allerede bruker.
Åpning, stenging, travle dager, butikkgulvkompetanse og rettferdighet i helger.
Dag- og nattvakter, sertifiserte medarbeidere, omsorgskontinuitet og hvileintervaller.
Utstyrskvalifikasjoner, produksjonsvolum, linjetildeling og skiftrotasjon.
Tilgjengelighet i felt, støttedekning, beredskap og reisebegrensninger.
BYGGE ELLER KJØPE
Skreddersydd utvikling er ikke alltid riktig svar. Beslutningen bør avhenge av regelkompleksitet, datamodenhet og verdien av forklarbare kandidater.
Hvis en ferdig tjeneste kan løse problemet godt, sier vi det. Et dedikert system foreslås bare når forretningsverdien av skreddersydde betingelser sannsynligvis overstiger kostnaden.
Når en ferdig tjeneste er nok
Standard skiftmønstre, begrensede regler og et lite team kan ofte komme raskere i gang med en eksisterende tjeneste.
Når et skreddersydd system er berettiget
Mange kvalifikasjoner, lokale regler, håndtering av endringer og behov for forklaring er sterkere grunner til å bygge en dedikert modell.
DATA
En ryddig database er ikke nødvendig første dag. Eksisterende Excel-filer, papirskjemaer for ønsker og ansattlister kan gjøres om til den første datakontrakten.
Ansattnavn eller ID-er, kompetanse, kontraktstimer, tilgjengelighet og ønskede fridager er nok til en første modell.
Etterspørsel etter dag, tidsrom, lokasjon, avdeling og rolle definerer dekningsmålet.
Skill regler som aldri må brytes, fra ønsker som bør respekteres når mulig.
Gjeldende vaktplaner og manuelle rettelser hjelper med å sammenligne de genererte kandidatene med faktisk praksis.
PROSESS
Det første målet er ikke å erstatte hele driften. Det er å teste om planleggingsreglene kan representeres og om den genererte kandidaten er nyttig.
01
Gjennomgå dagens regneark, innsamling av ønsker og manuelle rettelser.
02
Skill harde regler, preferanser, evalueringsmål og beslutninger som bare mennesker tar.
03
Bygg en liten beregningskomponent med representative data.
04
Sammenlign genererte kandidater med eksisterende vaktplaner og planleggerkommentarer.
05
Først etter at egnethet er bekreftet, kobles beregningen til arbeidsflyt, redigering og tillatelser.
PROTOTYPE
Bruk dagens vaktplan og kjernebetingelser til å sammenligne automatiske kandidater med dagens plan. Beslutning om full utvikling tas etter at gjennomførbarhet og verdi er synlig.
Liten verifikasjonspakke
298 000 JPY / ekskl. skatt
Forutsetter én organisasjon, én vaktplantype og et begrenset sett med hovedbetingelser. Formelt estimat følger etter avklaring av omfang.
NESTE BEVIS
Gå fra skiftproblemet til neste ressurs som hjelper teamet å beslutte.
Sammenlign denne skiftsiden med andre demoer for planlegging og tildeling.
Bruk kundecaser for å se hvordan vi beskriver evidens uten å overdrive resultater.
Gå gjennom hvordan filer, regneark og diagnoser håndteres før eksempler deles.
VANLIGE SPØRSMÅL
Disse svarene klargjør hva sidedemoen kan vise, hva en prototype bekrefter, og hva som fortsatt er en menneskelig beslutning.
Nei. Sidedemoen er en enkel heuristikk for å forklare ideen. Et reelt prosjekt velger løser eller søkemetode etter at regler, skala og krav til responstid er forstått.
Ja. En første gjennomgang kan vanligvis starte fra dagens vaktplan, ansattliste, ønskede fridager og et kort regelnotat.
Nei. Systemet bør vise vaktplankandidater, ikke oppfylte betingelser og tildelingsårsaker, slik at et menneske kan bekrefte den endelige planen.
De behandles som preferanser med mindre organisasjonen markerer dem som obligatoriske. Resultatet bør vise hvilke ønsker som ikke ble oppfylt og hvorfor.
En prototype kan først teste én organisasjon, én vaktplantype og hovedreglene. Full arbeidsflyt, redigering, tillatelser og integrasjoner avgjøres etter den dokumentasjonen.
NESTE HANDLING
Del dagens Excel-vaktplan og reglene som er absolutte krav eller bare preferanser. Vi skiller hva som kan modelleres, hvilke data som mangler, og hvor en liten prototype bør starte.