donderdag 6 oktober 2011

Forecasting in personeelsplanning: alle roosteraars een glazen bol!

Steeds vaker kom ik de term forecasting tegen in de context van personeelsplanning in de zorg. In andere omgevingen, zoals in de retail en in call centers, heeft forecasting haar waarde ruimschoots bewezen, dus waarom niet in de zorg? Forecasting is DE manier om het ogenschijnlijk onplanbare planbaar te maken! Voor alle roosteraars is dit geweldig nieuws. Stel je eens voor, een wereld waarin we precies weten hoe de vraag naar capaciteit er morgen uit ziet! Een eind aan de onzekerheid, alle roosteraars een glazen bol!


Hoe ziet het rooster proces eruit als we de zorgvraag van morgen exact kunnen voorspellen? In die situatie weten we op elk moment exact welke patiënten / cliënten zorg behoeven, en welke zorg dat is. In een aantal simpele stappen werken we toe naar een perfecte afstemming tussen capaciteitsvraag (de zorgbehoefte) en capaciteitsaanbod (de inzet van personeel).

Stap 1 is het maken van diensten. Omdat we precies weten welke zorg geleverd moet worden, kunnen we nauwkeurig bepalen hoeveel capaciteit er op elk moment van de dag nodig is, eventueel per deskundigheid. Deze capaciteitsbehoefte kunnen we vertalen naar een aantal brokken werk (diensten), elk uit te voeren door één persoon, waarbij de diensten samen de totale capaciteitsvraag afdekken. We controleren voor de zekerheid nog even of de kosten van de gemaakte diensten passen binnen het budget dat we krijgen toegewezen op basis van de zorgzwaarte op onze unit.

Er ligt hier een gevaar op de loer. Als we niet uitkijken, dan ontstaat de volgende situatie:
  • De gemaakte diensten passen qua dienstlengte niet bij de contracten van onze medewerkers.
  • De gemaakte diensten passen qua deskundigheid niet bij onze medewerkers.
  • De gemaakte diensten passen qua hoeveelheid niet bij onze medewerkers, er is sprake van overcapaciteit.

Omdat de zorgvraag ons budget bepaalt is het zaak de formatie af te stemmen op de ideale diensten, en bij voorkeur niet andersom! We hebben een formatie nodig met precies de juiste opbouw qua omvang, ervaring en contractsoorten, aansluitend bij het diensten patroon. We controleren nog even of de formatie die nu is ontstaan overeenkomt met de formatie die op basis van de zorgzwaarte op de unit aanwezig zou moeten zijn.

Met de aangepaste formatie en de gemaakte diensten gaan we verder met stap 2, het toewijzen van de diensten. Uiteraard houden we rekening met wensen van medewerkers over werktijden, maar ook met arbeidstijdenwet, CAO, contracturen en vereist ervaringsniveau van de dienst. De perfecte toewijzing komt zo tot stand, de haalbaarheid hiervan is veilig gesteld in stap 1.

In stap 3 worden de diensten uitgevoerd. Tijdens de uitvoering komt er een kleine beer op de weg. Er worden medewerkers ziek, en zo nu en dan wil er iemand onverwachts vrij. Waar dat voorheen geen probleem was omdat er over het algemeen meer dan voldoende capaciteit beschikbaar was, ontstaat er nu direct een gat in de bezetting. Geen man over boord, voor dit soort omstandigheden roepen we hulp in van buiten, we lenen iemand in van uit de flexpool. De flexpool creëren we in dit gedachten experiment met mensen die overtollig waren in de units waar we de formatie hebben herzien. Met behulp van de flexpool lukt het om het werk uit te voeren volgens plan.

Als het werk is uitgevoerd registreren we in stap 4 eventuele afwijkingen van de planning en sluiten we de maand af met het berekenen van toeslagen en het uitbetalen van de salarissen. Voor de zekerheid controleren we nog even of de uiteindelijke kosten overeen komen met het toegewezen en werkelijke budget. Daarmee is de roostercyclus gesloten.

Het lijkt allemaal zo simpel. Maarja, we hebben ook een glazen bol, zo kunnen we het allemaal! Of is dat misschien toch niet helemaal waar? Zijn er geen situaties waar de vraag eigenlijk heel goed voorspelbaar is, of zelfs heel constant is, en waar de wereld er toch niet zo mooi uitziet als hierboven beschreven?

Het antwoord op die vraag is nadrukkelijk JA! Er zijn heel veel organisaties in de zorg waar de vraag heel goed voorspelbaar is, denk bijvoorbeeld aan de VGZ of GGZ. De vraag fluctueert nauwelijks, dus is heel makkelijk en goed voorspelbaar. Maar toch is er in de meeste organisaties absoluut geen sprake van perfecte afstemming tussen capaciteitvraag en aanbod. Wat gaat daar nog niet goed? Het antwoord is heel simpel: op alle proces stappen is vaak nog een boel aan te merken, in elke stap is om verschillende redenen sprake van snijverlies. En al die verliezen bij elkaar vormen de inefficiëntie van het personeelsplanning proces.

Het goed uitvoeren van het boven beschreven proces vraagt een grote volwassenheid van de organisatie, zowel op het vlak van procesinrichting, technologie, besturing en van de mensen in het proces. In onvolwassen organisaties is het roosteren vaak erg gericht op het registreren van gewerkte tijd ten behoeve van salariëring. Van vooruit roosteren en inzetten van personeel op precies die momenten waarop de zorg geleverd moet worden is geen sprake. In formaties zitten allerlei buffers voor eventuele verstoringen en uitval. Verstoring worden ondanks de ruime capaciteit vaak opgevangen door externe capaciteit of meerwerk dat niet binnen de budgetten past.

Enkele voorbeelden van onvolwassenheid:
  • Het roosterproces wordt uitgevoerd door medewerkers die voor het grootste deel van de tijd in het primaire proces werkzaam zijn en het roosteren erbij doen aan de randen van de dag. Goed roosteren is een vak dat zeer wordt onderschat.
  • Het roosterproces wordt ondersteund door systemen die onvoldoende in staat zijn om te gaan met de grote complexiteit van het roosterproces. Excel is nog steeds een veelgebruikt rooster systeem.
  • Diensten zijn ontworpen om aan te sluiten bij de beschikbaarheid en wensen van de medewerkers, in plaats van bij de zorgvraag.
  • Verantwoordelijkheden binnen het roosterproces zijn niet duidelijk belegd.

Hoe komt een organisatie nu van haar huidige situatie naar de gewenste toekomstige situatie? En waar in de tijd staat het professionaliseren van het forecasting proces op de roadmap? Op het eerste gezicht zou je zeggen dat goed roosteren begint met het kennen van je vraag. Dus waarom niet beginnen met het op orde brengen van de forecast? Om de volgende redenen is dat geen goed idee.

Door het inrichting van een forecasting proces en het afstemmen van diensten op de werkelijke vraag zal ten opzichte van de huidige onvolwassen situatie
  • de complexiteit van het roosterproces toenemen. Denk aan toenemend aantal diensten met verschillende kenmerken als lengte en vereiste deskundigheid.
  • de noodzaak tot flexibilisering toenemen. De buffers verdwijnen en verstoringen zullen op een andere manier moeten worden opgevangen.
  • de dynamiek van het personeelsplanningproces toenemen als gevolg van toenemende behoefte aan flexibiliteit.
  • de noodzaak tot communicatie toenemen door de toenemende dynamiek.

Hiermee omgaan vraagt heel veel van zowel mensen, systemen besturing en processen. Zonder goed fundament onder het personeelsplanning huis is dit een niet te winnen wedstrijd. Op de roadmap moet forecasting in veel gevallen naar achteren geschoven worden. Hoeveel gemakkelijker is het om over de benodigde diensten verzameling te praten met een roosteraar die het plannen in de genen heeft en begrijpt wat de invloed is van het rooster op de uitnutting van het budget? Hoeveel gemakkelijker is het om over te gaan op een nieuwe diensten verzameling wanneer er een roostersysteem is dat hiermee zonder problemen kan omgaan? Hoeveel gemakkelijker is het om een nieuwe werkwijze te introduceren wanneer de hele organisatie gewend is om op een uniforme en gestructureerde manier te werken? En hoeveel gemakkelijker is het om te flexibiliseren wanneer er een infrastructuur is die uitwisseling van medewerkers over de afdelingen heen ondersteunt?

Een goed fundament is voorwaardelijk voor de succesvolle introductie van forecasting in het personeelsplanningsproces. Helaas zijn de meeste organisaties nog niet zover dat ze klaar zijn voor de grote stap. Uiteraard is dit ontzettend spijtig, aangezien de grote klapper in het meer efficiënt werken aan de voorkant van het proces zit, bij het goed definiëren van je werk, aansluitend op de zorgvraag.

zondag 17 juli 2011

Een stabiel plan is een goed plan

Onlangs publiceerde Aberdeen een rapport over de waarde van automatisering van het workforce planningsproces. In dit stuk wordt als onderdeel van het onderzoek volwassenheid van organisaties op dit gebied beschreven op basis van een aantal kenmerken. Een van deze kenmerken is de mate waarin een planning ongewijzigd wordt uitgevoerd, dus de stabiliteit van het plan. Hoe minder wijzigingen in het plan tussen het moment van plannen en het moment van uitvoeren, hoe beter de organisatie in control is. 

Waarom is stabiliteit belangrijk? In de eerste plaats maken we niet voor niets vroegtijdig een plan. Als we niet van zins zijn het plan te volgen, dan zouden we uberhaubt geen plan hoeven maken. Elke wijziging betekent extra inspanning (plantijd) en dus extra kosten bovenop de initiele plan kosten. 

In de tweede plaats stijgen de kosten van het plan over het algemeen als er wijzigingen plaatsvinden. Niet alleen wordt er vaak bij late wijzigingen gebruik gemaakt van meer flexibele en dus duurdere capaciteit, maar ook keuzes die gemaakt worden om de planning te repareren zijn vaak niet optimaal. Was het initiele plan een uitgebalanceerd geheel, het bijgestelde plan bevat een aantal stoplappen. Neem als voorbeeld een dienstrooster. Vaak wordt een rooster een aantal maanden vooruit gemaakt en gepubliceerd. Tussen het moment van publicatie en uitvoer zijn er allerlei redenen om het plan aan te passen. De praktijk is dat de kosten van het uitgevoerde werk veel hoger zijn dan de kosten van het initieel gepubliceerde rooster. 
Ten derde is een verandering van het plan, in elk geval als het gaat om een inzetplan voor medewerkers, een wijziging ten opzichte van de verwachting van de medeweker. Als dat veelvuldig gebeurt zal de medewerkertevredenheid hieronder lijden. 

Hoe zorg je als organisatie voor een stabiele planning? En waardoor ontstaan verstoringen eigenlijk? Een planning is niets meer dan een koppeling tussen capaciteitsvraag (uit te voeren werk, bijvoorbeeld uitgedrukt in uit te voeren taken of diensten) en capaciteitsaanbod (beschikbaarheid van medewerkers). Juist omdat een plan lang vooruit gemaakt wordt, kan er tot aan het moment van uitvoer nog veel veranderen, zowel aan de kant van de capaciteitsvraag als aan de kant van het capaciteitsaanbod. 
De capaciteitsvraag wordt ten tijde van het maken van het rooster ingeschat, en naarmate de tijd vordert, komt aanvullende informatie binnen op basis waarvan het plan eventueel aangepast moet worden. Hoe beter de voorspelling van de vraag en hoe beter de planner omgaat met de onzekerheid in die voorspelling, hoe minder aanpassingen er nodig zullen zijn. De mate waarin vraag voorspelbaar is varieert per toepassingsgebied. 
Ook aan de kant van het capaciteitsaanbod, de medewerker beschikbaarheid, is sprake van verstoring. Medewerkers worden ziek of hebben de wens om af te wijken van hun geplande werktijden en willen bijvoorbeeld ruilen met een collega. Als gevolg moet het plan worden aangepast. Hoe beter een initieel plan rekening houdt met voorspelbare (individuele beschikbaarheid en voorkeuren) en minder voorspelbare (ziekte) beperkingen, hoe minder aanpassingen nodig zullen zijn.  

Een stabiele planning ontstaat dus door gedegen voorspellingen van capaciteitsvraag en aanbod, het gebruiken van deze voorspellingen in het planproces, en door zoveel mogelijk rekening te houden met de beperkingen en voorkeuren waarvan je vroegtijdig kan weten dat ze er zijn. Een eenvoudig recept, maar iedereen die iets met planning te maken heeft weet dat het goed uitvoeren hiervan geen sinecure is, zeker wanneer er geen goede IT ondersteuning is. Precies daarom is een van de conclusies van het rapport van Aberdeen dat automatisering binnen het planproces grote waarde heeft. 



dinsdag 19 april 2011

Zonder plan geen planning

Hoe begin je als je een huis wil bouwen? Begin je met het kopen van je gereedschap of met het maken van een bouwtekening? Of denk je eerst na over waarvoor je het huis wilt gaan gebruiken? Over hoeveel kamers je nodig hebt, nu en in de toekomst? Of je alles in een keer wilt bouwen of dat je later wilt kunnen uitbouwen? Over waar het huis moet komen te staan? Het is een beetje een flauw voorbeeld, vooral omdat het zo evident is dat je geen van deze stappen kunt overslaan om uiteindelijk tevreden in je nieuwe huis te kunnen wonen. Het volgen van een logisch proces waarin je toewerkt naar de uiteindelijke bouw is de sleutel tot succes. 

Hoe begin je als je een APS systeem wilt implementeren? Is het hier net zo evident dat er een aantal stappen doorlopen moet worden om uiteindelijk een implementatie succesvol te kunnen afronden? Het antwoord is natuurlijk ja. Een implementatie begint niet met het aanschaffen van een APS systeem. Tenminste, dat zou niet zo moeten zijn... 

Ik werd laatst gebeld door de baas van een fabriek die er geen doekjes om wond. Zijn planningsproces was niet onder controle waardoor levertijden onbetrouwbaar waren. Hij zocht een scheduling oplossing waarmee hij beter zou kunnen plannen en wat zijn problemen zou oplossen. Of ik een suggestie had voor een goede tool, en wat dat geintje zou kosten. We zijn een paar maanden verder, en in plaats van een scheduling oplossing heeft hij het inzicht dat hij eigenlijk niet een scheduling oplossing maar een capaciteitsplanning oplossing zoekt, hij weet precies welk proces die oplossing moet ondersteunen, hij weet wat hij moet doen om dat proces in te richten en uit te voeren, en hij weet welk doel hij daarmee uiteindelijk zal gaan bereiken en hoe hij daarop kan sturen. Het uitkiezen en implementeren van de oplossing die hem werkelijk gaat helpen kan nu beginnen. 

Heb ik deze klant met een kluitje het riet in gestuurd? Ik denk het niet! Tijdens de eerste gesprekken werd duidelijk dat dit zijn tweede poging was om een APS systeem te implementeren. De eerste poging was gestrand omdat werd geprobeerd om de operationele planning in een te groot detail niveau in een applicatie te vangen waardoor de planning onbeheersbaar werd en de resultaten onrealistisch waren. De tweede poging was naar mijn overtuiging ook gestrand als de insteek weer was geweest om de operationele planning te ondersteunen. De werkelijke pijn zit in deze fabriek vrijwel uitsluitend op capaciteitsplanning niveau. Met een goede tactische planning als basis, kan de operationele planning op de huidige manier uitstekend zonder geavanceerde ondersteuning worden gemaakt.      

Helaas gebeurt het al te vaak dat in de voorbereiding van een APS implementatie een of meerdere stappen worden overgeslagen. Het resultaat is dat er een moment komt waarop de implementatie niet soepel loopt. Als je boft is dat in het begin van de implementatie. Zo zou het kunnen gebeuren dat tijdens het testen van de applicatie blijkt dat het systeem niet alles doet wat de gebruikers ervan hadden verwacht, of dat de koppeling met omliggende systemen nog niet gerealiseerd is of dat het proces dat de applicatie ondersteunt niet helemaal overeen komt met het proces waaraan de organisatie gewend is. Als je pech hebt kom je er pas aan het einde van de implementatie achter dat er onderweg iets is fout gegaan: De applicatie draait als een zonnetje, de planners kunnen ermee lezen en schrijven, maar de verwachte resultaat verbeteringen blijven uit.  

Een goede aanpak is de sleutel tot succes. In een goede aanpak is aandacht voor de vraag welke processen je gaat ondersteunen: waarom ga je ze ondersteunen, wat ga je ermee bereiken, hoe ga je op de resultaten sturen en hoe ga je meten of je de resultaten inderdaad bereikt hebt. Daarnaast is er aandacht voor de vraag hoe de ondersteunde processen er dan uitzien: zijn het bestaande processen of moeten bestaande processen worden aangepast. Wat is de consequentie hiervan op de organisatie en de mensen in de organisatie? Hoe ga je daarmee om? Als je weet WAT je wilt ondersteunen, volgt de vraag HOE je dat wilt ondersteunen. Dat resulteert in een pakket van eisen waar je vervolgens een oplossing bij kunt zoeken. Het klinkt eenvoudig, maar de ervaring leert dat het beantwoorden van bovenstaande vragen vaak een lastig en soms pijnlijk proces is waar veel tijd voor nodig is.  

De tijd, energie en het geld dat  gaat zitten in de voorbereiding van de implementatie wordt dubbel en dwars terugverdiend in het vervolg doordat fouten voorkomen worden. Een mislukte implementatie is een drama, zowel financieel als voor het draagvlak van de gebruikers. Bij het maken van de business case, een vanzelfsprekend onderdeel van een goede aanpak, dienen de kosten van de aanloop naar de implementatie te worden meegenomen, zodat deze gezien worden als onderdeel van het succes in plaats van als additionele kostenpost naast de implementatie.   


dinsdag 5 april 2011

APS the Battle: Planning vs Agendering

Het woord planning wordt vaak gebruikt (misbruikt?) voor iets wat op planning lijkt, maar er feitelijk niet zoveel mee te maken heeft: agendering. Agendering is een proces om te komen tot een toewijzing van werk aan resources, net als planning. Maar waar bij planning gestreefd wordt naar optimaliteit, gaat het bij agendering om feasibiliteit, oftewel het zoeken naar een toegelaten oplossing ipv naar de beste oplossing.

Een voorbeeld. Ik zag laatst een demonstratie van een OK 'planning' oplossing. Het vertrekpunt was de agenda van de specialist en het OK plan. De specialist kiest een patient en een behandeling, en de applicatie geeft op basis van agenda en ok schema aan wanneer het eerst mogelijke moment is dat deze operatie uitgevoerd kan worden. Hierbij werd rekening gehouden met ervaringscijfers over snijtijd van deze specialist op deze behandeling. Tijdens de ingreep kon vervolgens allerhande informatie worden vastgelegd om fouten te voorkomen en om informatie te verzamelen voor toekomstige plan doeleinden. Niet gek! 

Maar wordt hiermee gestuurd op maximaal gebruik van de OK, bijvoorbeeld door de volgorde van operaties juist te kiezen? Wordt rekening gehouden met beschikbare ruimte op de verpleegafdeling na de ingreep? Worden ook beschikbaarheden van andere benodigde mensen en middelen (typisch relevant voor een OK) meegenomen in de keuze voor het beste tijdslot? U raadt het al, de antwoorden zijn allemaal nee. Dit zijn typisch zaken die bij planning in de werkelijke zin van het woord wel meegenomen worden.

ERP leveranciers (bijv ZIS) die claimen een planning module ingebakken te hebben hebben het vaak eigenlijk over een agendering module. Voor echte planning is een point solution nodig die bovenop het ERP zijn waarde toevoegt. En daarbij is de kennis die vastgelegd is in het ERP hard nodig.

  

zondag 20 maart 2011

Personeelsplanning op zorg en ict beurs: volgend jaar hoeft u niet meer te gaan!

Afgelopen week was de jaarlijkse zorg en ict beurs. Ik ben een middagje langsgewipt om te zien hoe de verschillende leveranciers van personeelsplanning software zich pesenteerden. Alle groten der aarde waren van de partij: Ortec met Harmony, Pink Roccade met DRP, Monaco, Planning IT met SP-Expert en Ayton. Heugelijk nieuws voor iedereen die op zoek is naar een peroneelsplanning pakket: het maakt helemaal niets uit voor welke oplossing je kiest! Het is een pot nat! Ze kunnen allemaal alles! 

Zelf roosteren, flexpool, capaciteitsplanning, automatisch plannen, ze draaien er allemaal hun hand niet voor om! Allemaal hebben ze als unique selling points de ongekende gebruiksvriendelijkheid en de integrale oplossing  van capaciteitsplanning tot uren registratie, en allemaal zijn ze over een paar jaar absoluut marktleider! Ze koppelen allemaal standaard met alle grote ecd/epd en HR systemen. Dat is dus een hele zorg minder!

Ik heb mijn conclusie wel getrokken, ik ga op zoek naar een andere baan! Op deze manier is er voor adviseurs als ik niets meer aan! Als slotakkoord een gratis advies: kies gewoon de goedkoopste, dan zit u zeker goed!

Voor de ongelovigen onder ons: mocht je nou toch eens het verschil tussen
capaciteitsplanning en capaciteitsplanning of tussen een standaard koppeling en een standaard koppeling of tussen automatisch plannen en automatisch plannen of tussen zelfroosteren en zelfroosteren willen weten, bel me dan gerust, ik zit toevallig even zonder werk!


vrijdag 11 maart 2011

Het A-team in actie

Het succes van een project is afhankelijk van vele factoren. Maar er is één factor die met kop en schouders boven de rest uitsteekt: de kwaliteit van het team. En APS implementaties zijn hierin niet anders dan andere projecten.  

Natuurlijk wordt de kwaliteit van een team voornamelijk bepaald door de kwaliteit van de individuele mensen in het team. Voor elke rol in het team wil je de beste man of vrouw. Vakbekwaamheid, ervaring, gedrevenheid, initiatief, allemaal eigenschappen die je graag ziet. Maar er is meer dan individuele kwaliteiten. Een team moet ook werkelijk een team zijn, er moet sprake zijn van een klik tussen de teamleden en teamleden moeten elkaar en elkaars rol respecteren. Onderlinge strijd of irritatie kan een behoorlijk negatief effect hebben op het resultaat en de voortgang. Het team moet ook mandaat hebben om beslissingen te nemen, voldoende tijd hebben en de middelen hebben om het werk goed uit te kunnen voeren. 

Ik heb veel APS projecten gezien waar aan het begin van het project veel aandacht werd besteed aan de team samenstelling. De beste mensen uit de organisatie werden vrijgemaakt om hun bijdrage te leveren, en voor rollen die niet vanuit de organisatie zelf konden worden ingevuld, werden externe adviseurs aangetrokken. De beste mensen op de juiste plek, geen vuiltje aan de lucht. Het resultaat van deze projecten liet dan ook vaak weinig te wensen over. Tenminste, in eerste instantie...

Een project heeft een kop en een staart, en dus heeft een projectteam ook een eindig bestaan. Aan het einde van een implementatie project wordt het team ontbonden, gaat de geimplementeerde applicatie in beheer, en is het aan de organisatie om het geimplementeerde proces uit te voeren. De A-team leden gaan weer over tot de orde van de dag of starten nieuwe projecten, het B-team doet haar intrede. En daar gaat het vaak mis. 

Sleutelposities zoals key-users, applicatiebeheerders, worden in de post-project fase vaak ingevuld door mensen die het op vele fronten afleggen tegen de oorspronkelijke A-team leden. Ze hebben het project niet of minder intensief meegemaakt en zijn dus niet op de hoogte van het hoe en waarom van belangrijke ontwerpbeslissingen, ze hebben niet het aantal vlieguren en ze zijn vaak minder emotioneel betrokken. Hoe goed de overdracht ook is, je ziet toch vaak een terugval in de kwaliteit van het gebruik van applicaties, het naleven van het afgesproken proces, etc. En hoe langer hoe meer wordt er afgedwaald van wat oorspronkelijk het plan was, en verdwijnen doelen steeds verder uit zicht. Een paar jaar na de implementatie is er vaak weinig over van de ambities en kijken gebruikers geirriteerd terug op alles wat er is fout gegaan.

Betekent dat dat een projectteam nooit ontbonden kan worden? Nee, natuurlijk niet, dat zou niet realistisch zijn. Het is wel van belang om dit risico te onderkennen bij de start van het project, en continuiteit zoveel mogelijk te borgen, door onder meer op tijd te beginnen met het overdragen van kennis en lange termijn afhankelijkheid van individuele medewerkers te voorkomen. Maar het aller belangrijkste is om tijdens de implementatie een mechanisme in te richten om de kwaliteit van het planproces in uitvoering te monitoren en daarmee te kunnen bijsturen zodra de klad erin dreigt te komen. Een goede toets om te ontdekken of je werkelijk het A-team hebt opgelijnd is even checken of dit goed geregeld is... 


zondag 27 februari 2011

Een voor allen, allen voor een!

Ik was laatst in een ziekenhuis en het gesprek kwam op personeelsplanning op de verpleegafdelingen. Ik kreeg een anekdote te horen die me fascineerde en die ik jullie niet wil onthouden. Dit is de perfecte illustratie van het fenomeen dat locale optimalisatie tot grote globale inefficienties leidt. De anekdote ging over de bezetting van de verpleegafdeling chirurgie tijdens de vakantieperiode. 

De vakantieplanning wordt als volgt gemaakt. Per afdeling wordt een minimale bezetting per dag bepaald. Iedereen mag zijn vakantiewensen aangeven, en er krijgen net zoveel mensen vakantie tot de minimale bezetting is bereikt. Met de rest wordt in overleg een alternatieve vakantiedatum afgesproken.

Nu is natuurlijk de hamvraag: hoe wordt de minimale bezetting bepaald? Ik zal niet uitweiden over de manier waarop dat in dit ziekenhuis gebeurde, ik wil het wel over het effect ervan hebben. Op een andere afdeling, de OK afdeling, had ook een vakantieplanning plaatsgevonden. Het resultaat daarvan was dat in een bepaalde populaire vakantieweek van de 16 OK's er 8 gesloten werden, dus de OK afdeling draaide op halve capaciteit. In diezelfde week was op de verpleegafdeling chirurgie door de vastgestelde minimale bezetting ongeveer 80% van het normale personeel aanwezig. De gevolgen laten zich raden: er werden veel potjes geklaverjast. 

Vol ongeloof ging ik met de planners van deze afdelingen in gesprek. Ik kon me niet voorstellen dat niemand had bedacht dat de OK activiteit, het kloppend hart van het ziekenhuis, bepalend is voor de capaciteitsbehoefte op de verpleegafdelingen. Gelukkig werd ik niet teleurgesteld, de planners waren zich hier terdege van bewust. Maar waarom wordt daar met de vakantieplanning -en ik neem voor het gemak maar even aan dat het in de rest van het jaar niet veel beter is- dan geen rekening mee gehouden?

De uitleg was dat zelfs als je weet hoe het OK schema eruit ziet (welk specialisme heeft wanneer toegang tot de OK) je niets kan zeggen over de bijbehorende beddencapaciteit. De specialisten bepalen namelijk zelf welke patienten ze op een dag gaan behandelen, en per ingreep verschilt de daarop volgende verpleegduur enorm. En die specialisten doen dit ongetwijfeld met de beste bedoelingen: ik ga er blind vanuit dat op deze manier de OK tijd op zijn voordeligst wordt gebruikt. 

Bovenstaand voorbeeld illustreert hoe locale optimalisatie tot enorme inefficienties voor het hele ziekenhuis leidt. In dit voorbeeld gaat het over de personele resources, maar er zijn natuurlijk ook legio vergelijkbare voorbeelden te geven over andere capaciteiten, zoals bijvoorbeeld diagnostische afdelingen. 

Zolang sturing op locale doelstellingen geen plaats maakt voor integraal capaciteitsmanagement zal dit fenomeen blijven bestaan. Het is opmerkelijk dat ziekenhuizen in dit opzicht jaren achterlopen op productiebedrijven die met zeer vergelijkbare uitdagingen kampen, en daar overigens uitstekende oplossingen voor hebben gevonden. Wat is er nodig om dit tij te keren?


vrijdag 18 februari 2011

De business case van beter roosteren: het geld ligt op straat!

Het geld ligt op straat, zeker daar waar geroosterd wordt. Er zijn voldoende organisaties die dit aanvoelen en er wordt dan ook driftig geïnvesteerd in software om het roosterproces te ondersteunen. Bij aanvang van een implementatieproject lijken de bomen tot in de hemel te groeien. De business case, zoals voorgerekend door de leverancier of zoals becijferd op een druilerige namiddag is zo evident, dat moet wel een doorslaand succes worden. En toch valt het achteraf vaak tegen.


Hoe ziet de batenkant van de business case voor beter roosteren er uit? Heel hoog over kun je stellen dat goede dienstroosterplanning leidt tot hogere medewerkertevredenheid, hogere clienttevredenheid, lagere risico's, hogere efficientie en lagere operationele kosten, hogere kwaliteit van dienstverlening en lagere administratieve lasten en plantijd. Dit is natuurlijk een mooi rijtje, maar om de baten ook daadwerkelijk te verzilveren moet er veel gebeuren. In de blog volwassenheid van planning gaf ik al aan dat voor een volwassen planfunctie zowel de proceskant, de menskant als de technologiekant op orde moet zijn. Daaraan kan je ook nog de besturingskant toevoegen.           

Ik bezocht recentelijk een organisatie die een fors aantal jaren geleden investeerde in professionele software om het dienstrooster planningsproces te ondersteunen. Er werd nagedacht over het roosterproces, over de rollen en verantwoordelijkheden binnen het proces, en er werd voldoende aandacht besteed aan opleiding van de spelers. De software werd goed ingericht en werd in productie genomen. Vrijwel direct na live-gang ging het fout. Veel medewerkers vonden het toch lastig om over te gaan op de nieuwe werkwijze en bleven doen wat ze de jaren ervoor ook deden. De kwaliteit van het  roosterproces werd volledig afhankelijk van de inzet en kunde van individuele medewerkers, en niet van het ingerichte proces. Er zijn in de jaren die volgden werd door steeds weer nieuwe managers nog een aantal pogingen gedaan om het project nieuw leven in te blazen, maar tevergeefs. Vandaag de dag, een klein decenium later, wordt de software nog steeds gebruikt, echter de doelen die ooit gesteld waren en daarmee de financiele baten zijn nooit gerealiseerd. 


Lag het aan het proces? Aan de mensen? Aan de technologie? In dit geval was het waarschijnlijk vooral de aansturing waar het fout ging. In deze organisatie waren de sponsoren van het project duidelijk niet in staat geweest om de verantwoordelijkheid voor de business case in de lijn te beleggen. Gevolg was dat iedereen zonder consequenties zijn gang kon gaan en kon afwijken van de afspraken die gemaakt waren. De mate van navolging van het proces en de kwaliteit van het resultaat van de planning werd niet gemeten, en daarmee werd niet gestuurd in de richting van een volwassen planfunctie en dus in de richting van het realiseren van de business case.  


Het realiseren van de business case is iets waar een organisatie de tijd voor moet nemen en gedurende langere tijd energie in moet steken. Om te sturen in de richting van een positief resultaat is inzicht nodig in hoe de organisatie presteert. Vaak zijn er grote verschillen in prestatie tussen afdelingen, regio's, plangroepen of andere doorsnedes. De ene keer zit de pijn bij het planproces, de andere keer bij de mensen, de technologie of de besturing. Door goed te meten ben je in staat de vinger op de zere plek te leggen en actief op verbetering te sturen. Goede business intelligence is daarbij onontbeerlijk.


Dat geeft direct wat inzicht in de kostenkant van de business case die voor het gemak vaak niet of onvolledig in kaart wordt gebracht. Het goed implementeren van een dienstroosterplanning proces is meer een organisatie transformatie dan een technische implementatie. De kosten zitten naast de ICT investering dan ook vooral in het inrichten en uitvoeren van het verander proces. 


Betekent dit dat ik niet geloof dat er met beter roosteren veel geld kan worden verdiend? Integendeel! Ik geloof dat het geld weldegelijk op straat ligt! Het wrange is echter dat ik voortdurend tegen organisaties aanloop waar het geld gewoonweg niet wordt opgeraapt. De investering in de ICT wordt gedaan, maar  de organisatie transformatie krijgt al dan niet bewust onvoldoende aandacht. En daarmee wordt de volwassenheid die nodig is om de business case te realiseren nooit bereikt. 



maandag 7 februari 2011

APS the battle: APS vs Business Analytics

In de reeks APS - the battle komt een aantal begrippen voorbij die allemaal iets met APS te maken hebben. Maar hoe verhouden deze begrippen zich tot APS? In deze blog: APS vs Business Analytics.

Business analytics, een ogenschijnlijk kleine stap van de vorige APS - the battle blog, waarin ik APS met Business Intelligence vergeleek. Immers, de term BI is uit, tegenwoordig dien je over BA te spreken, ook als je het over een doorsnee dashboard hebt. De voor de hand liggende conclusie zou zijn: APS = BI = BA.

Maar zo gemakkelijk maak ik me er niet vanaf. Ik heb me namelijk voor deze battle laten inspireren door het marketing apparaat van IBM. De woordkunstenaars hebben Business Analytics tegenwoordig opgesplitst in drie categorieen: descriptive analytics, predictive analytics en, jawel, prescriptive analytics. 

Descriptive analytics is de nieuwe term voor wat we vroeger BI zouden hebben genoemd. Predictive analytics kennen we onder een heleboel verschillende namen waaronder Advanced Analytics en Business Analytics. Prescriptive analytics was echter nieuw voor mij. Ik ken het alleen onder de naam... APS... 

"Prescriptive Analytics: A set of mathematical techniques that computationally determine a set of high-value alternative actions or decisions given a complex set of objectives, requirements, and constraints, with the goal of improving business performance." (www.ibm.com)

Nou ja, het dekt in elk geval een stuk af van wat ik APS zou noemen. Prescriptive analysis heeft een duidelijke focus op mathematische optimalisatie, wat zowel blijkt uit de beschrijving als uit de software invulling die ze eraan geven (ILOG). En daarmee verdient het wat mij betreft het predicaat APS net niet. 

APS gaat naast het mathematisch optimaliseren ook over het ondersteunen van beslissingen, simpelweg door inzicht te verschaffen aan de planner, door business rules te evalueren. Gewapend met de juiste data feiten is een planner vaak prima in staat om een goede planbeslissing te nemen, ook als er niet direct een optimum berekend wordt. En ook forecasting, als input van de wat meer lange termijn planningen, behoort wat mij betreft tot het domein van APS.

Je zou dus kunnen zeggen dat APS naast prescriptive analytics ook bestaat uit descriptive analytics en predictive analytics. Met andere woorden: APS = descriptive analytics + predicitve analytics + prescriptive analytics = business analytics. Het moet niet gekker worden...     

       

vrijdag 4 februari 2011

Volwassenheid in planning

"Life is what happens to you while you're busy making other plans". De planningliefhebbers onder ons zullen het over een ding snel eens zijn: John Lennon was een waardeloze planner. 

Een goede planner is goud waard. De logistiek manager van een transportbedrijf waarvoor ik werkte zei eens tegen mij dat een goede planner bij hem best een ton mag verdienen. Dat was overigens wel voor de crisis. Maar is een goede planner nu werkelijk de sleutel tot succes?

Hoe meet je de volwassenheid van een organisatie als het gaat om de planningsfunctie? Ben je volwassen als je tevreden personeel hebt? Of als je je resources een hoge utilisatie hebben? Of gaat het juist om de kwaliteit van het eindproduct dat je levert? Of moeten we juist kijken naar de manier waarop de planning tot stand komt? Ben je volwassen als je voor het maken van de planning een mooi softwarepakket hebt aangeschaft?

Volwassenheid kent vele vormen. Natuurlijk zijn alle bovenstaande zaken indicaties van volwassenheid, maar het gaat om meer dan dat. Volwassenheid in planning gaat over drie assen: het planningsproces, de mensen in het planningsproces, en de technologische ondersteuning van het planningsproces. Een volwassen organisatie is volwassen op alle drie de assen. 

Een volwassen organisatie heeft een uniform planproces, onafhankelijk van wie de planning maakt. De planner heeft de kennis en middelen om dit proces uit te voeren. De rol van planner wordt serieus genomen en wordt ingevuld door medewerkers die de capaciteiten hebben om te komen tot een goede planning. Een "goede planning" is gedefinieerd en wordt gemeten aan de hand van prestatie indicatoren. Uiteraard voldoet de planning aan wet en regelgeving, en houdt, indien van toepassing, rekening met de individuele wensen van  medewerkers. De resultaten van het planningsproces worden op het juiste moment in de juiste vorm gecommuniceerd naar alle stakeholders, waaronder andere systemen zoals een HRM, CRM of ERP systeem. De tijd die de planner nodig heeft om te komen tot een planning is beperkt door de verregaande automatisering van de planning.  

Het is belangrijk om te realiseren dat het efficient benutten van schaarse middelen en daarmee het bereiken van organisatiedoelstellingen gemakkelijker gaat met een volwassen planningsfunctie. Daarom is het nastreven van volwassenheid een doel op zich. Maar volwassen worden gaat helaas niet van de ene op de andere dag. De tijd die hiervoor nodig is, is afhankelijk van de draagkracht en flexibiliteit van de organisatie. De route hiernaartoe kan echter wel in de tijd worden uitgezet, en hierop kan gericht worden gestuurd. Hiervoor is natuurlijk wel een volwassen planner nodig.   


zondag 30 januari 2011

APS the battle: APS vs Business Intelligence

In de reeks APS - the battle komt een aantal begrippen voorbij die allemaal iets met APS te maken hebben. Maar hoe verhouden deze begrippen zich tot APS? In deze blog: APS vs Business Intelligence. 

APS en Business Intelligence (BI), voor sommigen ogenschijnlijk verschillende werelden, voor anderen onlosmakelijk met elkaar verbonden. Een definitie van BI geven valt niet mee, en ik zal me er ook zeker niet aan wagen. Maar over een aantal eigenschappen van BI zullen we het snel eens zijn. BI gaat over het verzamelen van gegevens. BI gaat over het analyseren en interpreteren van gegevens. BI gaat over patroonherkenning, over het modelleren van de wereld op basis van de data. BI gaat over het presenteren van gegevens en van resultaten van analyses. BI is een continu proces dat zich afspeelt in een omgeving waarin "een gebruiker" behoefte heeft om zijn omgeving op een overzichtelijke manier gepresenteerd te krijgen om op basis van dat inzicht op elk moment op de juiste manier te kunnen reageren en de juiste beslissing te kunnen nemen om zo zijn doel te kunnen realiseren. Van belang is dat de voornoemde "gebruiker" iemand is die beslissingen neemt binnen een bepaalde business context. Juist de inbedding in een dagelijks proces maakt dat binnen het BI veld beslissingen op alle niveaus worden ondersteund. Bovenstaande laat zich samenvatten in het volgende model. 

Bron: Arnout Arnzt, Capgemini

Laten we eens proberen om bovenstaand model toe te passen op APS. Neem als beinvloeder een planner die als doel heeft een planning te maken waarbij hij enkele KPI's als richtlijn voor de kwaliteit van zijn planning beschouwt. Wat hij van een APS systeem mag verwachten is dat alle relevante informatie vanuit omliggende systemen, naar ook vanuit de omgeving real time aan hem wordt getoond (observeren, verzamelen, presenteren), dat voorstellen worden gedaan voor zijn planbeslissingen (analyseren, interpreteren, presenteren), en dat regels of business rules zijn gemodelleerd en worden geevalueerd (verwerken van externe informatie en interpreteren en evalueren). Wat een APS systeem niet voor je doet is beslissingen nemen en executeren, tenzij de beinvloeder deze beslissing expliciet heeft gedelegeerd aan het systeem. Een APS systeem levert dus de informatie aan aan een beinvloeder op basis waarvan de juiste beslissing kan worden genomen die bijdraagt aan het bereiken van een doel. Als dat geen business intelligence is... 

vrijdag 21 januari 2011

Als het past, dan past het...

...en zo niet, dan niet! 


APS pakketten komen in verschillende soorten en maten. Deze wereld is grofweg op te delen in drie soorten. Ten eerste zijn er de kant en klare pakketten, dan zijn er de maatwerk oplossingen, en ten slotte zit daar tussenin nog iets wat je frameworks, bouwpakketten of toolbox oplossingen kunt noemen. Elk type systeem heeft voor en nadelen die in ogenschouw dienen te worden genomen bij het selecteren van een APS systeem. 

Het kiezen van een APS systeem is geen gemakkelijke opgave, er zijn veel factoren waarmee rekening moet worden gehouden. Het systeem moet de gewenste functionaliteit afdekken, moet gebruiksvriendelijk zijn, moet goed onderhoudbaar zijn, moet goed kunnen aansluiten op anderen systemen, moet zich bewezen hebben in vergelijkbare situaties, en ga zo maar door. Ook de leverancier speelt een belangrijke rol. Deze moet financieel gezond zijn, een toekomstvisie hebben die aansluit bij jouw visie en moet betrouwbaar zijn. En natuurlijk speelt de prijs een belangrijke rol. Maar zelfs als je weet wat je belangrijk vindt bij het maken van je keuze is het nog niet eenvoudig om een goede keuze te maken, simpel weg omdat elke leverancier haar uiterste best zal doen om aan te tonen dat haar product aan alle criteria voldoet. En vanuit functioneel perspectief is dat in veel gevallen ook niet ver bezijden de waarheid. Echter, de tijd en energie die het kost om een oplossing werkend te krijgen kan sterk verschillen. Om te voorkomen dat een implementatie onnodig veel tijd, energie en geld kost is het zaak om in elk geval een type oplossing te kiezen dat past bij jouw situatie. En dat is relatief eenvoudig.  

Elk van de type oplossingen heeft zijn voor en nadelen. Pakket oplossingen hebben het voordeel dat ze sterk gestandaardiseerd zijn. Elke gebruiker heeft dezelfde installatie en daarmee dezelfde functionaliteit. Je kan er dus vanuit gaan dat als er veel gebruikers zijn de software ook voldoende getest is en de kinderziektes eruit zijn. De keerzijde hiervan is de beperkte flexibiliteit. Als je iets wilt wat niet in de software zit is het vaak een kostbare en tijdrovende aangelegenheid om het toch voor elkaar te krijgen. Kortom: als het past dan past het, zo niet, dan niet. En dan zijn er alternatieven.

Het extreme andere uiterste is de maatwerk oplossing. Je begint met en blanco vel en gaat van de grond af aan iets opbouwen. Je hebt alle gelegenheid om precies voor elkaar te krijgen wat je wilt. Echter, vaak is het helemaal niet zo eenvoudig om compleet te zijn in je wensen, je moet verdomde goed weten wat je voor ogen hebt. Veel tijd gaat zitten in het specificeren van de functionaliteit, het realiseren hiervan en vervolgens het testen. 

Tussen de maatwerk oplossing en het pakket zit de framework oplossing. Deze kan gezien worden als een bouwpakket met allemaal handige bouwblokken die eenvoudig gestapeld kunnen worden om tezamen een werkend systeem te vormen. Hiermee kan veel sneller ontwikkeld worden dan in een maatwerkomgeving, en de flexibiliteit is vergelijkbaar. Toch zijn de frameworks ook niet de heilige graal, de nadelen van maatwerk oplossingen gelden ook voor de frameworks. Oplossingen zijn uniek, dus niet bewezen en gevoelig voor fouten. Ook de ontwerpuitdaging is vergelijkbaar.  

Een standaardpakket implementatie kan relatief snel plaatsvinden. De uitdaging zit in dit geval vooral in de organisatie zelf: zijn de processen op orde, is data beschikbaar en van goede kwaliteit, zijn gebruikers voldoende capabel.  Een maatwerk implementatie is vaak heel tijdrovend, met name door de vele iteraties die nodig zijn om te komen tot een volledig ontwerp en een foutloos systeem. De framework oplossingen hebben de voordelen van beide extremen, maar ook enkele nadelen. Met name het noodzakelijke specificeren en testen kan een implementatie fors uit de hand laten lopen. Ook de onderhoudbaarheid laat vaak te wensen over, en de kwaliteit van het eindresultaat is heel sterk afhankelijk van de kundigheid en ervaring van het team dat het systeem ontwikkelt. Dit traject is alleen aan te raden als de pakket implementatie echt geen optie is. Conclusie: past een pakket, zoek niet verder. Zijn wensen of processen zo speciefiek dat pakketten niet passen, kijk dan naar de frameworks. Als dat om wat voor reden dan ook tot niets leidt (vaak is prijs een issue), grijp dan eventueel naar maatwerk. 

Is het met deze vuistregel op zak nu duidelijk in welke hoek de ideale oplossing gezocht moet worden? Het antwoord is helaas nee. De vraag die nog beantwoord moet worden is: past het of past het niet? En juist bij de beantwoording van die vraag werken leveranciers vaak niet mee. De maatwerkleveranciers zullen namelijk altijd alles in het werk stellen om aan te tonen dat jouw situatie werkelijk uniek is (ook als dat niet zo is), terwijl de pakketleveranciers alles zullen doen om aan te tonen dat jouw wereld precies aansluit op wat het pakket kan (ook als dat niet zo is). De framework leverancier zal argumenteren dat elke organisatie uniek is, en dat jouw interpretatie van regelgeving en specifieke business rules die alleen gelden in jouw organisatie maken dat je echt niet blij gaat worden van die standaard pakketten die niet flexibel zijn en je dwingen om je proces aan te passen aan de keuzes is in de software gemaakt zijn. De pakketleverancier zal beargumenteren dat de software zo flexibel en goed parametriseerbaar dat ze nog nooit hebben meegemaakt dat ze een proces niet kunnen ondersteunen. En natuurlijk ligt de waarheid in het midden. 

Tijdens een implementatie van een standaardpakketoplossing ga je ongetwijfeld wel eens een concessie moeten doen, bijvoorbeeld aan de manier waarop een planning grafisch wordt gepresenteerd. De vraag die je je moet stellen is of die specifieke zaken die afwijken van wat bij al die andere gebruikers van de software anders gaat werkelijk bijdragen aan het maken van een betere planning en daarmee bij het bereiken van de organisatiedoelstellingen. Als het antwoord niet overtuigend JA is, is mijn advies om vooral te kiezen voor de standaard oplossing. Als het antwoord echter wel JA luidt, twijfel dan ook niet, en kies eieren voor je geld.   

Standaardisatie is prima. Ondanks dat alle organisaties met een planningsuitdaging in beginsel uniek zijn, is het voor een aantal planningsprocessen  heel wel mogelijk om te standaardiseren. Best practices zijn er om te worden hergebruikt, en standaardisatie leidt ook tot optimalisatie, zolang gebruikers kritische blijven. Een heel duidelijk voorbeeld van een standaard planningsproces waar maatwerk of frameworks echt de verkeerde keuze zijn is dienstroosterplanning. Een rooster is een rooster is een rooster is een rooster. Dienstroosters maken is moeilijk, en er komen heel veel regels bij kijken die goed door een systeem moeten worden ondersteund. Bestaande standaardpakketten hebben over de afgelopen 10 tot 20 jaar ervaring opgebouwd en hun oplossing verfijnd. Het is niet realistisch om in korte tijd iets te bouwen van vergelijkbare kwaliteit. Ik heb meerdere voorbeelden van mislukte implementaties van DRP systemen, en een van de oorzaken is altijd dat er te weinig functionaliteit standaard beschikbaar is.

Tot slot: Het verschil tussen standaard pakketten en frameworks wordt langzaam kleiner. Frameworks werken aan verticals of industry solutions, deeloplossingen waarop kan worden voortgeborduurd. Een goede stap, maar de volwassenheid van deze verticals haalt het over het algemeen niet bij die van de standaard pakketten. De pakketleveranciers werken op hun beurt hard aan de flexibiliteit van hun systemen, om nog beter te kunnen aansluiten bij de klant die steeds veeleisender wordt. Bij het maken van je keuze, laat je goed informeren en laat je geen zand in de ogen strooien. En onthoud: als het past, dan past het, en zo niet, dan niet. 

zondag 16 januari 2011

Schoenmaker, houd je bij je leest!

Een bakker bakt broden, een houthakker hakt hout. Niet dat een houthakker geen brood kan bakken, maar het brood van de bakker zal vast sneller en goedkoper gemaakt zijn en lekkerder smaken. Mensen doen waar ze goed in zijn en wat ze leuk vinden zodat niet iedereen zich in alles hoeft te bekwamen. Het leven is eenvoudig. Of toch niet? Wanneer het gaat over wat ingewikkelder producten lijkt de natuurlijke neiging tot specialisatie opeens niet meer zo vanzelfsprekend. Het zal u niet verbazen, in de wereld van APS wordt nog wel eens lichtzinnig omgegaan met dit principe. 
Aan de ene kant komt het nogal eens voor dat organisaties die aan planning doen maar in het primaire proces niets met software hebben zich hieraan schuldig maken: Ze besluiten zelf een applicatie te bouwen om een planningsproces mee te ondersteunen terwijl er voldoende keus is tussen software leveranciers die zich  hierin specialiseren. Aan de andere kant zijn het diezelfde software leveranciers die op hun beurt buiten hun boekje gaan door zich te begeven op het vlak van de organisatieadviseurs en naast het maken van software ook organisaties gevraagd en ongevraagd van advies voorzien over de inrichting van hun planningsprocessen en de organisatieverandering die hiermee gemoeid is. 

Voor een goed verlopende APS implementatie zijn drie partijen onmisbaar. 
  • De klant: voor het inbrengen van alle organisatiekennis, proces kennis, organisatiedoelstellingen en visie
  • De software leverancier: voor het leveren van state of the art planningssoftware
  • De organisatieadviseur: voor het organiseren, begeleiden, en het inbedden in de organisatie.      
Een voorbeeld van een organisatie die dit concept helemaal heeft begrepen en succesvol haar ambities waarmaakt:


donderdag 13 januari 2011

Dienstroosterplanning in de zorg: op welke grond selecteer je een pakket?

Een interessante forum discussie over pakket selectie voor een DRP oplossing eindigt met de conclusie dat het functioneel niet zoveel uitmaakt welk van de top x pakketten je kiest, ze ondersteunen allemaal bij het maken van een goed rooster. Ortec Harmony, RostarCas of RostaFlex van Paralax, Monaco, SP-Expert, het zijn allemaal prima oplossing. Er zijn echter wel een aantal niet functionele aspecten die in ogenschouw moeten worden genomen bij het selecteren van een roosteroplossing. Om er een paar te noemen:
  • De stabiliteit van de leverancier. Hoe ziet de roadmap van de productontwikkeling eruit, sluit dit aan bij de roadmap van de organisatie? Is de leverancier financieel gezond? Hoeveel medewerkers heeft de leverancier (zegt iets over de beschikbaarheid en flexibiliteit tijdens de implementatie).
  • De implementatie strategie van de leverancier. Een goede implementatie is essentieel om te komen tot een tevreden gebruikersgroep. De meeste leveranciers hebben zelf een professional services organisatie met consultants die de implementatie verzorgen. Echter, de focus is vrijwel zonder uitzondering op de techniek. Als de applicatie het doet dan is het goed, ondergeschikt is het gebruik, het realiseren van de doelen, kwaliteit van data, kwaliteit van koppeling met andere systemen, etc. Een implementatie van een DRP systeem heeft grote impact op de organisatie, niet alleen IT, maar ook voor het proces en de mensen, en zeer belangrijk is dus aandacht voor het veranderproces. Er zijn leveranciers die dit onderkennen en samenwerken met adviseurs / implementatiepartners die de inbedding in de organsatie begeleiden.
  • Architectuur van de oplossing. Er zijn leveranciers die standaard 90 tot 100% van de functionaliteit bieden die nodig is zonder dat daar noemenswaardige aanpassing / inrichting nodig is, en leveranciers die een bouwdoos aanbieden waarmee je een applicatie samenstelt. Beide hebben voor en nadelen: flexibiliteit vs snelheid en stabiliteit. Kies voor de oplossing die past bij jouw organisatie.

De verschillen tussen de leveranciers op de genoemde punten zijn levensgroot, ook (of misschien wel juist) onder de grootste spelers!


Tot slot: met technologie alleen kom je er niet, het gaat minstens zoveel om de kwaliteit van het roosterproces en de roosteraars als om de IT ondersteuning. IT als enabler van een proces! Bezint eer gij begint!

zaterdag 1 januari 2011

Workforce optimalisatie in de zorg: de kosten omlaag en kwaliteit omhoog

Kwaliteit van zorg is in grote mate afhankelijk van de kwaliteit en beschikbaarheid van verplegend en verzorgend personeel. Er zijn twee ontwikkelingen die de kwaliteit van zorg in gevaar brengen: De druk op de kosten van de zorg en de schaarste op de arbeidsmarkt. Aangezien personeelskosten een belangrijke component vormen van de totale uitgaven van zorginstellingen en medewerkertevredenheid een belangrijke indicatie is voor het kunnen aantrekken en behouden van kwalitatief goede medewerkers, verdient het aanbeveling om op een zorgvuldige manier om te springen met personeel. Zorgvuldig heeft in deze context twee betekenissen, namelijk efficiënt en met oog voor de medewerker. En deze twee zaken staan vaak met elkaar op gespannen voet.


Workforce optimalisatie gaat over het zo goed mogelijk benutten van schaarse medewerker capaciteit, en het daarbij vinden van de juiste balans tussen organisatiebelangen en medewerkerbelangen. Zaken die typisch van belang zijn voor een zorginstelling zijn cliënt gericht werken en kwalitatief goede zorg leveren binnen beperkt budget. Voor medewerkers zijn bijvoorbeeld flexibiliteit en balans tussen werk en privé van groot belang. Deze belangen komen bij elkaar in dienstroosters waarin wordt vastgelegd wie, op welk moment, welk werk uitvoert.

In de meest eenvoudige vorm ziet het dienstrooster planningproces er als volgt uit. Het begint met het vaststellen van de formatie. De ideale formatie kan betaald worden uit het beschikbare budget, heeft tezamen voldoende contract tijd om de zorgzwaarte te kunnen afdekken en heeft een mix van verschillende competenties en ervaringsniveaus die aansluit bij de zorgvraag. Bovendien dient de formatie voldoende flexibel te zijn in termen van type arbeidscontracten. Met de juiste formatie is het in principe mogelijk om gedurende een langere periode roosters te maken waarin zorgvraag en aanbod elkaar gaan vinden. De volgende stap is het vaststellen van de capaciteitsbehoefte op elk moment van de dag. Capaciteitsbehoefte wordt bepaald door de zorgzwaarte te bepalen, en hier een ervaringsfactor bij op te tellen voor onvermoede uitval door bijvoorbeeld ziekte. Vaak is het nodig om onderscheid te maken tussen soorten capaciteit: een verpleger kan immers niet hetzelfde als een arts. Vervolgens worden diensten gedefinieerd die tezamen de capaciteitsbehoefte zo goed mogelijk afdekken. Daarbij dient rekening gehouden te worden met regelgeving, bijvoorbeeld minimale en maximale dienstlengte en verplichte pauzes, maar ook met de mogelijkheden die arbeidscontracten en medewerkerafspraken bieden. Tot slot worden de gedefinieerde diensten toegewezen aan individuele medewerkers. Hierbij wordt gezorgd dat elke medewerker per periode zoveel werk krijgt toegewezen als volgens contract is afgesproken, dat een medewerker de kwalificaties heeft die nodig zijn voor het uitvoeren van de dienst, en dat aan regelgeving wordt voldaan.

Het maken van dienstroosters verwordt door het balanceren tussen verschillende belangen tot een bijzonder complex proces. De kwaliteit van de beslissingen die worden genomen in elk van de stappen, in boven beschreven proces, is zeer bepalend voor de mate waarin organisatiedoelstellingen worden bereikt. Neem het definiëren van de te werken diensten. Wanneer ochtend diensten standaard om 8 uur starten omdat medewerkers dat nou eenmaal zo gewend zijn, wordt mogelijk voorbij gegaan aan het feit dat er tussen 8 en 9 eigenlijk maar werk is voor 1 medewerker, en dat pas vanaf 9 uur 4 man nodig is. Door middel van optimalisatie van deze processtap valt vaak veel efficiëntie te winnen. Echter, een geoptimaliseerde diensten set is niet perse goed voor de werksfeer. Het zou zo maar eens kunnen zijn dat starten om 9 uur heel slecht past in de inrichting van het privéleven van de medewerkers. In dit geval is het de vraag wat voor de organisatie zwaarder weegt: efficiëntie of medewerkertevredenheid. Het belang van de medewerker krijgt steeds meer aandacht waardoor uitsluitend sturen op efficiëntie niet langer gewenst is. Het zogenaamde individueel roosteren of zelfroosteren is in opkomst. Bij individueel roosteren oefent de medewerker op verschillende manieren invloed uit op wanneer gewerkt wordt. De meest eenvoudige vorm is het toestaan van dienstruilingen. Iets verder gaat het rekening houden met opgegeven voorkeuren of afkeuren voor bepaalde werktijden. In de meest verregaande vorm kiezen medewerkers hun eigen diensten uit een set gedefinieerde diensten, bijvoorbeeld door gebruik te maken van een biedsysteem, of stemmen collega’s zelfs onderling vast wie wanneer werkt, rekening houdend met de zorgbehoefte. De uitdaging is hier om een werkbare mix te vinden van medewerkerbelang en andere organisatiedoelen.

Het optimaliseren van de workforce betekent vaak een ingrijpende organisatieverandering. Het raakt mensen, processen en in veel gevallen ook technologie. Zonder goede IT ondersteuning is het ondoenlijk voor organisaties van enige omvang om deze slag te maken. Gelukkig zijn er goede dienstrooster planningoplossingen op de markt die het optimalisatieproces uitstekend kunnen faciliteren. Het zomaar aanschaffen van een dienstrooster planningoplossing als middel om te veranderen is echter geen goed idee. Een succesvolle transformatie begint met het scherp definiëren, prioriteren en meetbaar maken van doelstellingen. Vervolgens dient het planningproces te worden heroverwogen en afgestemd op de doelstellingen. Onderdeel hiervan zijn de rollen en verantwoordelijkheden binnen het proces. Daarna wordt de vraag beantwoord welk deel van het proces ondersteund kan worden door een IT systeem. Pas als duidelijk is wat van een software oplossing verwacht wordt, het zogenaamde programma van eisen, kan een weloverwogen keuze worden gemaakt voor de technologie, als enabler van de transformatie. De menskant van de transformatie moet ook niet worden onderschat. Naast het leren omgaan met nieuwe software zullen medewerkers zich moeten conformeren aan het nieuwe proces, hun nieuwe rol of nieuwe verantwoordelijkheid. Vaak ontstaan er tijdens een dergelijke transitie inzichten die er niet eerder waren, en komen bijvoorbeeld verworven rechten aan het licht die strijdig zijn met de nieuwe doelstellingen. Hierdoor kan weerstand ontstaan die het welslagen van de verandering in gevaar brengt.

Dienstrooster planning is een complex proces, dat vaak niet de aandacht krijgt die het verdient. Het maken van dienstroosters wordt te vaak overgelaten aan medewerkers die daarvoor niet de nodige tijd en middelen ter beschikking hebben, of niet de capaciteit hebben om verschillende belangen tegen elkaar af te wegen. Het eindproduct is in die gevallen desastreus voor het organisatie resultaat. Doordat roosteraars geen duidelijke doelstellingen meekrijgen en op de kwaliteit van roosters niet wordt gestuurd (en niet gemeten), blijft dit effect vaak verborgen. Juist door de grote invloed die de dienstroosters hebben op de mate waarin organisatiedoelen worden behaald, dient het dienstrooster planningproces en daarmee workforce optimalisatie gezien te worden als een strategisch in plaats van een administratief proces.