Inte alla kan täcka alla pass

Inte alla kan täcka allt. En bytesprocess som ignorerar detta kommer förr eller senare godkänna ett byte som lämnar ett pass utan nyckelinnehavare, en tränad öppnare, eller någon kvalificerad att hantera en nödvändig uppgift.

Kvalifikationer är den minst intressanta delen av schemaläggning ända fram tills de är anledningen till att ett pass inte kan köras juridiskt eller praktiskt. Att modellera dem ordentligt är det som gör att byten kan förbli öppna och snabba utan att någon granskar varje byte för hand.

Inte alla kvalifikationer är likadana

I praktiken följer team upp flera olika begrepp under den enda rubriken ”kvalifikationer”, och de beter sig ganska olika:

• Certifieringar — ett formellt intyg med ett utgångsdatum. Livsmedelshantering, första hjälpen, ett körkort, eller en maskincertifiering.
• Tränade roller — intern kompetens utan pappersarbete bifogat. Öppnare, stängare, kassa, nyckelinnehavare.
• Behörighet — rättigheter kopplade till en roll: godkänna, makulera, öppna, eller låsa upp saker.
• Preferenser — vad någon är villig att jobba. Ingen kvalifikation, och det bör inte blockera ett byte på samma sätt.

Det vanliga misstaget är att lägga alla fyra i en enda platt lista med taggar. Preferenser beter sig då som hårda krav, medan certifieringar som går ut beter sig som permanenta egenskaper.

Resultatet är antingen att för många byten blockeras eller, värre, att ett byte godkänns utan att kolla vad passet faktiskt behöver.

Modellera passet, inte bara personen

Att tagga personer är bara halva jobbet. Den andra halvan är att registrera vad varje pass kräver — något de flesta team bär runt i en chefs huvud snarare än någonstans nedskrivet.

Ta ett enkelt exempel: en lördagsstängning kan kräva en nyckelinnehavare, en kassatränad person, och någon med aktuell första hjälpen-utbildning på plats. En enda anställd skulle kunna uppfylla två av de kraven samtidigt.

Nedskrivet blir ett föreslaget byte kontrollerbart: uppfyller schemat fortfarande varje krav efter bytet?

Lämnat oskrivet beror varje byte på att någon kommer ihåg.

“Ett byte kan se helt rimligt ut på pappret och ändå lämna ett pass utan den enda personen som kan låsa dörren.”

Det är skillnaden mellan att kolla om två personer kan byta pass och att kolla om det resulterande schemat fortfarande fungerar.

Blockera om du måste, men förklara varför

När ett byte skulle bryta ett krav är ett tyst avslag inte till mycket nytta.

En tydlig anledning är: det här passet behöver en nyckelinnehavare, och du skulle vara den enda schemalagda.

Det gör om en återvändsgränd till något den anställda kan agera på — oftast genom att hitta en annan bytespartner utan att blanda in en chef alls.

Att blockera utan förklaring lär folk att kringgå systemet. Så hamnar team tillbaka i gruppchatten, där bytet kan ske utan att någon kollar konsekvenserna.

Målet är inte att godkänna varje byte. Det är att göra anledningen till ett avslag tillräckligt tydlig så att folk kan lösa vad som faktiskt är fel.

Håll dokumentationen aktuell

Certifieringar går ut, och en utgången certifiering som fortfarande läses som giltig är värre än att inte ha någon dokumentation alls.

Två vanor räcker oftast: sätt ett utgångsdatum på allt som har ett, och granska en persons kvalifikationer när deras roll eller ansvar ändras i stället för att vänta på en årlig genomgång.

Samma sak gäller tränade roller och behörighet. Om någon slutar vara nyckelinnehavare eller tar på sig ett nytt ansvar behöver dokumentationen ändras med dem.

Gjort ordentligt är det här grundarbetet som låter dig säga ja till byten som standard.

Systemet vet vad varje pass kräver, kollar om det föreslagna bytet bevarar de kraven, och förklarar när det inte gör det — vilket också är det som gör ett godkännandebeslut snabbt att fatta.

“Chefen behöver inte hålla begränsningen i huvudet. De behöver bara kliva in när systemet hittar ett beslut som faktiskt kräver dem.”