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... 

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. 

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:

http://www.digitalezorg.nl/digitale/capgemini-ortec-en-ipse-slaan-handen-ineen/

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!

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.