ZorgThuis: terugkerende uitval bij een SaaS-roosterpakket
ZorgThuis levert thuiszorg met 1.200 medewerkers en ongeveer 8.000 cliëntbezoeken per week. Het roosteren gebeurt in een SaaS-pakket; planners werken dagelijks in de ochtendpiek van 6 tot 9 uur. Het contract vermeldt 99,5 procent beschikbaarheid per maand en een releasekalender met twee releases per jaar. In vijf weken tijd waren er drie storingen: vier uur, zes uur en twee uur, alle drie in de ochtendpiek. Planners werkten met telefoonlijsten en papieren uitdraaien; cliënten kregen in elf gevallen een vervangende kracht zonder vaste gezicht. De leverancier meldt dat het om een bekende fout gaat, dat de oorzaak nog niet vaststaat en dat het structurele herstel in de release van oktober meegaat. Een tussentijdse hotfix is technisch mogelijk. De functioneel beheerder heeft de storingen als incidenten afgemeld zodra de dienst weer liep. Het hoofd Planning eist dat 'dit nooit meer gebeurt' en wil de leverancier laten boeten.
1. Bepaal of dit probleemmanagement of incidentafhandeling vraagt en welke eisen je aan de leverancier stelt. Onderbouw met de SLA en met de bedrijfsimpact.
Read the worked answer
Dit vraagt probleemmanagement. Drie storingen in vijf weken met dezelfde bekende fout, een onbekende oorzaak en een structureel herstel dat maanden weg is: dat is de definitie van een probleem. De incidenten zijn afgehandeld zodra de dienst liep, maar daarmee is de oorzaak niet weg. Door alleen incidenten af te melden, heeft de functioneel beheerder het patroon onzichtbaar gemaakt voor het contractgesprek.
Rekenen met de SLA. 99,5 procent van een maand van ongeveer 730 uur betekent 3,65 uur toegestane uitval per maand. Twaalf uur in vijf weken is een forse overschrijding, en de impact is zwaar omdat de uitval precies in de planningspiek valt. Dit is geen theoretische norm maar een meetbare tekortkoming.
Eisen aan de leverancier.
- Een rootcause-analyse met eigenaar en datum, niet 'bekend' zonder inhoud.
- Een tijdelijke mitigerende maatregel die vóór de volgende piek werkt, bijvoorbeeld een fallback-export die planners zelf kunnen draaien.
- Wekelijkse rapportage over beschikbaarheid, oorzaak en voortgang, met vaste contactpersoon.
- Nakoming van de contractuele gevolgen: credits of gesprek over vergoeding, en escalatie naar de accountmanager.
- Een verbetering van de releasekalender: een structurele fout mag niet standaard wachten op een halfjaarlijkse release als de impact zo hoog is.
Koppel elke eis aan een termijn en een eigenaar. 'Nooit meer' is geen eis; 'beschikbaarheid van 99,9 procent in de piek vanaf 1 november, gemeten en gerapporteerd' wel.
2. De leverancier biedt een tussentijdse hotfix aan buiten de releasekalender. Geef een advies aan het change advisory board met de afwegingen en de voorwaarden.
Read the worked answer
Advies: de hotfix accepteren onder voorwaarden, mits getest en terugdraaibaar.
Baten. Minder kans op uitval in de ochtendpiek, minder handmatig plannen, minder cliëntimpact en herstel van vertrouwen bij de planners. Wachten op oktober betekent nog maanden risico bij een aanbieder die de oorzaak zelf nog niet kent.
Risico's. Een hotfix buiten de kalender is per definitie minder getest; regressie in roosterberekeningen of in de koppeling met de loonverwerking is mogelijk. Er kan een nieuwe fout ontstaan die pas in de piek zichtbaar wordt. De leverancier kan de hotfix bovendien gebruiken om de druk van de structurele oplossing af te halen.
Voorwaarden.
- Eerst testen in de acceptatieomgeving met representatieve weekroosters en met de koppeling naar de loonverwerking.
- Een geschreven rollbackprocedure en een terugvalscenario dat dezelfde dag uitvoerbaar is.
- Doorvoeren buiten de piek, in een afgesproken change window, met de key-users van Planning als acceptanten.
- Gefaseerde uitrol als dat kan, met monitoring op fouten en op responstijden gedurende de eerste week.
- Schriftelijke bevestiging dat de hotfix geen vervanging is van de structurele oplossing, en dat de rootcause-analyse en de release van oktober op koers blijven.
- Een evaluatiemoment binnen twee weken, met de vraag of de fout echt weg is.
Laat het CAB dit besluit nemen en vastleggen met eigenaar, datum en evaluatie. Zo blijft de hotfix een beheerste stap en geen sluipende release.