De afgelopen periode heb ik als projectleider twee implementaties mogen begeleiden van hetzelfde ECD. Eén als projectleider van de leverancier en bij de andere was ik projectleider aan de kant van de klant. Beide organisaties waren enigszins vergelijkbaar: groot qua omvang, zelfde vormen van zorg en financiering: jeugdzorg in dit geval. De projecten liepen parallel en zijn beide op tijd en binnen budget opgeleverd. En beide organisaties hadden helaas ook een eerdere implementatie achter de rug die niet succesvol was. Wat waren de overeenkomsten tussen deze twee projecten waardoor ze succesvol zijn geëindigd

Een ervaring die mij nieuwe inzichten heeft gegeven over wat wel en niet kan bijdragen aan een succesvolle implementatie. De moeite waard om te delen.

Zoals geschetst leken beide organisaties op elkaar. Beide groot en complex, maar de één was nog weer groter dan de ander. Beide leveren jeugdzorg maar daarbinnen zaten wel verschillen in het portfolio. Ook qua cultuur, organisatiestructuur, volwassenheid en governance zaten er duidelijke verschillen. Vier aspecten met verschillen waar vaak juist cruciale randvoorwaarden aan worden gesteld om een succesvol project te draaien.

Genoeg verschillen dus om een ander eindresultaat te verwachten. In de aanpak van het project zaten echter een aantal overeenkomsten waarvan bij de evaluatie is vastgesteld dat die cruciaal zijn geweest voor het welslagen van deze projecten:

1. Er waren hele duidelijke leidende principes in het project waar de aanpak en besluitvorming langs gelegd konden worden.
2. Het projectteam was dedicated, vrijgemaakt voor het project en was compact.
3. De go-live datum kon niet worden uitgesteld. Dat was absoluut geen optie.
4. De implementatieproject en het verandertraject (borging) in de organisatie waren losgekoppeld van elkaar.

Op deze vier punten ga ik hieronder verder duiden.

Duidelijke leidende principes

In beide projecten waren hele scherpe leidende principes vastgelegd. Denk aan een best-practice inrichting, aanpak van de leverancier als leidend, geen maatwerk, implementeer as is en ga niet direct ook optimaliseren. Afwijken van de best-practice kan alleen na akkoord van de stuurgroep, mandaat bij het projectteam, etc. Op basis van deze leidende principes konden veel discussies en keuzes in het project snel worden beslecht en was het ook niet nodig deze met de achterban, de organisatie, te bespreken. Deze aanpak zorgde voor meer slagvaardigheid in het project en zorgde daarmee voor een hoog tempo. Alleen bij uitzondering moest er een besluit genomen worden door de stuurgroep of moest een klankbordgroep geraadpleegd worden. Het tempo wat gerealiseerd werd hierdoor zorgde dat het deadlines gehaald werden en de aanpak gaf het projectteam ook het comfort om de keuzes te maken.

Daarnaast hielpen de leidende principes ook om de ambities realistisch te houden. Het is de natuurlijke neiging om vanuit het project het nieuwe ECD zo optimaal mogelijk neer te zetten en daarmee meer te doen dan gevraagd wordt en alle toeters en bellen van de applicatie te implementeren. Daarbij wordt soms uit het oog verloren dat de overgang naar een nieuw ECD al een hele grote verandering is voor de organisatie. Als je dan ook nog allerlei stappen gaat optimaliseren, automatiseren of veranderen loop je aan tegen de grenzen van de verandercapaciteit van de organisatie.

Zorg eerst voor de basis op orde, dat is al een hele grote stap. Maar definieer ook op voorhand al een fase 2 om wel die optimalisaties te gaan realiseren. Enerzijds zijn die nodig en bieden als het goed is meerwaarde maar creëert ook hier comfort bij het projectteam om zaken te parkeren naar een volgende fase. Als er geen perspectief is op een fase 2 is men al snel bang dat een verbeteroptie nooit gerealiseerd gaat worden. Voordeel van een fase 2 voor de optimalisaties, is ook dat de praktijkervaring met het nieuwe ECD mee kan worden genomen, wat uiteindelijk zorgt voor veel betere optimalisaties dan wat theoretisch tijdens een eerste implementatie kon worden bedacht.

Dedicated projectteam

De bemensing van een dergelijk project is vaak erg lastig, zeker met de personeelstekorten die er zijn. Om toch een brede representatie van de organisatie te krijgen wordt er een vrij omvangrijk projectteam met werkgroepen opgezet. Consequentie is dat veel mensen een beetje met het project bezig zijn. Dat gaat ten koste van de focus op wat er moet gebeuren voor het project. En heel praktisch, zaken als het plannen van afspraken is een crime en dus tijdrovend en vertragend. Ten slotte geeft een brede representatie ook meer ruimte voor uitvoerige discussies over wat de beste oplossing zou moeten worden. Hoewel die discussies goed zijn voor het draagvlak van de uiteindelijk gekozen oplossing, is de meerwaarde voor de kwaliteit van de implementatie beperkt. Het gaat namelijk niet om discussies over of iets wel of niet goed is, maar vooral welke oplossingsrichting beter is: goed, beter, best. En vaak komt er ook nog een stukje strijd bij vanuit het verleden omdat veel organisaties vanuit diverse fusies en overnames zijn gegroeid of vermeende verschillen in zorgvormen. Tijdrovende discussies die de voortgang in de weg staan, zonder dat ze dus een wezenlijke bijdrage leveren aan de kwaliteit van de implementatie.

In beide projecten is juist gekozen voor een compacter team wat (bijna volledig) vrij gemaakt was voor het project, met een beperkte representatie vanuit de organisatie. Maar met de leidende principes onder de arm, bleek dit veel slagvaardiger. Er was focus en de samenwerking in het project kon goed georganiseerd worden. Niet onbelangrijk want je moet het met elkaar doen. De rolverdeling was helderder, wat voor de projectleden meer duidelijkheid gaf over waar ze verantwoordelijk voor zijn: dus beter in staat hun rol uit te voeren en wist ze waar ze aanspreekbaar op waren. En gegeven de druk die altijd op dit soort projecten zit, hadden ze daarmee al genoeg aan hun hoofd.

Wel is het belangrijk om contact met de organisatie te realiseren: immers niet alle kennis is beschikbaar in het projectteam en draagvlak voor gemaakte keuzes moet georganiseerd worden. Afhankelijk van de aard van de beslissing kan dat bij de stuurgroep liggen. Maar op detailniveau of als er inhoudelijke kennis nodig is, is de stuurgroep niet altijd het juiste gremium. Het inrichten van klankbordgroepen waar bijvoorbeeld wekelijks in een uur de belangrijkste punten worden besproken bleek een goede werkwijze te zijn voor die besluiten waar de kennis ontbreekt en te toetsen of bepaalde gemaakte keuzes juist waren. Het projectteam kreeg comfort bij de gemaakte keuzes. De inhoudelijk toetsing borgde dat de kwaliteit en motivatie van de keuzes ook helder naar de organisatie gecommuniceerd konden worden. Het was helder waarom de zaken gedaan waren zoals ze gedaan waren. Goede documentatie hierbij is cruciaal zodat de onderbouwing begrijpelijk blijft.

Geen uitstel mogelijk

Grofweg zijn er 3 knoppen waar je in een project aan kan draaien: kwaliteit, capaciteit en tijd. Op het moment dat het spannend wordt in een project komt de onvermijdelijke vraag: aan welke van die knoppen ga je draaien? Het projectteam wil een zo goed mogelijk project opleveren. Door middel van een draai aan de kwaliteitsknop daar concessies aan doen, voelt als falen. Meer capaciteit is ook vaak om meerdere reden niet haalbaar. Als er al meer capaciteit beschikbaar te maken is, is het de vraag wat het daadwerkelijk toevoegt aan extra snelheid. Extra projectleden moeten ingewerkt worden en het projectteam dijt uit met extra of langere overleggen tot gevolg. Het bestaande projectteam harder laten werken is ook niet reëel: de werkdruk is daar vaak al maximaal gestretcht.

Op zo’n moment komt uitstel van live-gang in beeld. Mijn ervaring is dat er dan een boeiend fenomeen optreedt: doordat er uitstel mogelijk is, wordt enerzijds de tijdknop naar achter gedraaid maar vaak ook de kwaliteitsknop omhoog. We stellen wel uit maar er moet wel meer gerealiseerd worden. Hierboven heb ik al uiteengezet dat het verhogen van de kwaliteit veel tijd kost, er moeten immers ingewikkelde discussies worden gevoerd en beslecht over wat de beste oplossing is. Het resultaat: wel een latere deadline, veel extra kosten en maar beperkt betere, kwaliteit. Iets wat je veel efficiënter kunt realiseren in een optimalisatie fase waarbij je een stuk praktijkervaring meeneemt.

In een scenario waar geen uitstel mogelijk is, blijft dus eigenlijk alleen het draaien aan de kwaliteitsknop over. En nee, dan hebben we het niet over het zover naar beneden draaien dat je op een ‘onvoldoende’ komt of met de hakken over de sloot. Het is het open gesprek over wat verwachten we als projectteam versus wat verwacht de organisatie. Dan blijkt dat de lat van het projectteam vaak hoger ligt dan de opdrachtgever verwacht en mogelijk ook wat de organisatie aan kan. Wat moet nu, wat kan ook later? Ik heb zoveel live-gangen gezien waarbij allerlei gerealiseerde functionaliteiten niet gebruikt werden of bepaalde optimalisatie al snel na het gebruik teruggedraaid werden. Op het moment dat je die punten duidelijk met elkaar durft te benoemen en te parkeren, creëer je lucht in het project. In die discussie hielp het sterk als de tijdsknop vaststaat. Dat bewustzijn bij het projectteam zorgde voor focus.

De daadwerkelijk verandering en borging vindt pas na het project plaats

Het ‘technisch’ neerzetten van een ECD is één, maar zorgen dat het gebruikt gaat worden zoals het is bedoeld, is twee. Veel aandacht in een project gaat uit naar communicatie en opleiding om te bewerkstellen dat de organisatie het ECD goed gaat gebruiken. Deze veranderopdracht ligt vaak ook bij het projectteam. Maar is het wel realistisch dat een projectteam van slechts enkele tientallen mensen verantwoordelijk kan zijn voor de veranderingen diep op de werkvloer bij honderden of duizenden mensen?

Natuurlijk kun je met opleiden en communicatie veel doen. Ook een servicedesk, applicatiebeheer, key-users, ECD-coaches, etc. kunnen allemaal een rol spelen. Naar mijn mening echter is primair het lijnmanagement verantwoordelijk voor de borging binnen de teams. Zij hebben de hiërarchische verantwoordelijkheid en kennen hun mensen. Bij veel ECD-implementaties gaat er te weinig aandacht uit naar de rol die operationeel managers in deze verandering moeten hebben. Juist naar deze groep medewerkers moet veel opleiding en communicatie gaan en ook zij moeten actief het ECD gaan gebruiken. Zij moeten uitgerust worden met de juiste instrumenten om in hun teams het ECD succesvol te gaan gebruiken. En dat is een traject wat niet alleen tijdens de implementatie speelt, maar vooral juist daarna. In de ‘nazorgfase’ moet veel meer aandacht gaan naar het voeden en ondersteunen van de operationeel managers zodat zij hun teams op de juiste wijze met het ECD laten werken, in plaats van dat ‘af te schuiven’ op het project of support/applicatiebeheer.

Mijn advies is om in de projectaanpak dit heel duidelijk een plaats te geven. Dat expliciet maken, zorgt bij de start van het project al voor een discussie: “oh maar dat moeten jullie als project toch doen”. Vanaf dat moment het bewustzijn creëren dat lijnmanagement hier aan zet is in plaats van het project zorgt voor een goede voorbereiding. Na live-gang is er dan nog een substantiële fase nodig om de lijnmanagers te ondersteunen bij het borgen in de organisatie met tools en kennis gestoeld op de praktijk.

Mijn advies is om in de projectaanpak dit heel duidelijk een plaats te geven. Dat expliciet maken, zorgt bij de start van het project al voor een discussie: “oh maar dat moeten jullie als project toch doen”. Vanaf dat moment het bewustzijn creëren dat lijnmanagement hier aan zet is in plaats van het project zorgt voor een goede voorbereiding. Na live-gang is er dan nog een substantiële fase nodig om de lijnmanagers te ondersteunen bij het borgen in de organisatie met tools en kennis gestoeld op de praktijk.

Waren er meer aspecten die mee hebben geholpen? Ongetwijfeld. Zo weet ik niet of het gunstig is geweest dat er sprake was van een eerdere mislukte implementatie van een ECD. Wordt men daar kritischer van? Of luistert men juist beter naar de leverancier die vaker een ECD implementatie heeft gedaan? Beide organisaties kenmerkten zich door een goede zelfreflectie op hun eigen rol bij de vorige implementaties. Die volwassenheid heeft mogelijk ook een rol gespeeld.

Het bericht Case Study: Wat maakt dat de ene ECD/ EPD implementatie succesvoller is dan de andere? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Grip op de zorg: een mission impossible? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Hoe eng is blockchain technologie? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Wat wil Be-Better bereiken met het inzetten van een blockchain oplossing? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Dat klink als een no-brainer. Als iets efficiënter is, veiliger met data omgaat en passendere zorg biedt, dan maakt het niet meer uit wie het meest profiteert. Bekijk bijgaande video wat het in de praktijk betekent.

Het bericht Wie uiteindelijk de winnaar bij keten optimalisatie? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Wat is de business case achter ketenoptimalisatie in de zorg en het sociaal domein? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

De oorzaken zijn divers en gaan van contractering tot en met de facturatie en het proces is vaak maar beperkt geautomatiseerd. Kloppen de contracten tussen hoofd- en onderaannemer? Wat is er precies afgesproken over een specifieke cliënt? Matched de factuur met de daadwerkelijk geleverde zorg en hoe verhoudt de geleverde zorg zich tot de afspraken met de zorgfinanciers (gemeente, zorgverzekeraar, zorgkantoor)? En hoe toon je vervolgens de kwaliteit en rechtmatigheid van de zorg aan naar deze zorgfinanciers?

Ook gemeenten onderkennen inmiddels deze problematiek. Daarom heeft de VNG onlangs KPMG onderzoek laten doen naar hoofd- en onderaannemersschap in het sociaal domein.  Dat onderzoek heeft geleid tot een afwegingskader hoofd- en onderaannemerschap sociaal domein. Een interessant rapport waarin door KPMG een aantal duidelijke aanbevelingen wordt gedaan. In essentie zijn die terug te brengen tot twee kernpunten: uniformeren en transparantie. Wat mij betreft hele logische aanbevelingen maar ik ben ook in de overtuiging dat als dat eenvoudig te realiseren was geweest, dat de sector dat ook allang gedaan had.

Welke obstakels zijn er?

Er bestaan dus duidelijk obstakels om de benodigde uniformiteit en transparantie te bewerkstellen. Belangrijke redenen daarvoor zijn onder andere de autonomie van de verschillende partijen, de verscheidenheid aan financiers, de grote variatie aan zorg- en contractvormen en de verschillende rollen welke een zorgaanbieder kan hebben: dan weer hoofdaannemer dan weer onderaannemer.  Uniformeren leidt dan al snel tot een grote verscheidenheid aan geüniformeerde schakels. En door de verschillende verantwoordelijkheden in de verschillende situaties ontbreekt ook vaak de regie.

Vanuit Be-Better hebben we ons, samen met onze klanten, afgevraagd hoe we dit ketenprobleem zouden kunnen oplossen? Hoe kunnen we dit proces zodanig faciliteren dat er transparantie en vertrouwen ontstaat in de samenwerking? Waarmee de kwaliteit en rechtmatigheid van de geleverde zorg goed kan worden aangetoond, ook naar de initiële opdrachtgevers zoals een gemeente of zorgverzekeraar? En waarmee de zorgaanbieders worden geholpen om zo veel mogelijk uniform te werken. Een belangrijke randvoorwaarde die daarbij gesteld werd, is oog hebben voor de realiteit: immers de verschillen in identiteit, werkwijzen, contractvormen, etc. die zijn er gewoon. De oplossing moet dus zodanig werken dat de zorgaanbieders worden gefaciliteerd om binnen deze verscheidenheid met zo min mogelijk inspanning en kans op fouten te kunnen werken.

Een typisch ketenprobleem vraagt om een ketenoplossing en daarmee ligt blockchain-technologie als deel van de oplossing voorhanden. Een ketenprobleem ook dat niet alleen in de zorg en het sociaal domein voorkomt, maar in tal van andere sectoren. Samen met onze technologie partner Ledger Leopard heeft dat geresulteerd in BB4HAOA. Een oplossing specifiek voor de zorg, maar wat gebruik maakt van een platform dat breder ingezet wordt om het proces tussen hoofd- en onderaannemers te faciliteren.

Hoe hebben we het probleem opgelost?

Belangrijk in een ketenoplossing is om te zorgen voor transparantie, eenduidige informatie, eenmalige vastlegging en autonomie in het gebruik van de eigen systemen (ECD’s veelal). Oftewel samen waar het kan en iets oplevert.

De kern van BB4HAOA bestaat uit vier bouwstenen: contractafspraken (de PDC (= Product Diensten Catalogus)), toewijzingen, geleverde zorg en facturatie. Deze vier bouwstenen zijn cruciaal voor het goed doorlopen van het gezamenlijke proces en moeten dus juist, uniform en transparant zijn. Door deze 4 bouwstenen in een gezamenlijke administratie te zetten ontstaat deze benodigde transparantie en uniformiteit.

De contractafspraken vormen daarbij de basis, daarin staan immers de afspraken tussen hoofd- en onderaannemer over zaken als welke producten, tarieven, volumes, etc. De overige drie bouwstenen worden vervolgens stap voor stap toegevoegd aan BB4HAOA gedurende het operationele proces, idealiter vanuit het aangesloten ECD. Iedere stap wordt daarbij getoetst aan de contractafspraken en de informatie uit de andere bouwstenen. Zo stapelt zich de informatie op tot een betrouwbare en transparante set aan informatie en afspraken voor de keten. Deze informatie wordt vervolgens ook gebruikt voor de onderlinge facturatie waarbij er 100% aansluiting is tussen wat is afgesproken, wat is geleverd en wat is gefactureerd.

</br>

Geen onduidelijkheid meer over wat er is afgesproken en of dat correct is. De informatie is daarbij voor beide partijen gelijk en direct beschikbaar. Geen onderlinge verschillen meer tussen wat in het ECD van de hoofdaannemer staat en wat er bij de onderaannemer bekend is. Kortom we lossen de informatiestroom op tussen hoofd- en onderaannemer. De blockchain-technologie zorgt dat dit veilig gebeurt en dat deze informatie transparant en betrouwbaar is voor beide partijen. Zo is ook direct de rechtmatigheid geborgd richting hoofdaannemer en de zorgfinancier.

Wat maakt deze oplossing uniek?

Er zijn een aantal elementen die BB4HAOA bijzonder maken. De eerste is dat BB4HAOA het probleem oplost voor een netwerk van zorginstellingen en niet alleen het probleem van één hoofdaannemer en zijn onderaannemers. Immers dan heb je als onderaannemer alsnog met allerlei verschillende oplossingen te maken en los je het probleem niet wezenlijk op.

Als zorgaanbieder kun je bij het gebruik van BB4HAOA grotendeels in je eigen ECD werken. Het is niet noodzakelijk om in BB4HAOA te werken, het kan wel maar hoeft niet. Middels slimme koppelingen met het ECD is een eenvoudig werkproces mogelijk en blijft er sprake van eenmalige vastlegging.

Het lost ook een probleem op richting de zorgfinanciers. Zij krijgen eenvoudiger zicht op de kwaliteit en rechtmatigheid van de geleverde zorg. Daarmee bespaart het ook tijd en kosten voor de productieverantwoording richting de zorgfinanciers.

Het belangrijkste echter is dat de administratieve keten tussen hoofd- en onderaannemer gedigitaliseerd worden: transparant, uniform, versnelt en betrouwbaar.

Nieuwsgierig geworden? Neem dan contact met ons op!

Het bericht Zorg in onderaanneming: een administratieve nachtmerrie opgelost verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Waarom is optimalisatie in de zorgketen nodig? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Het bericht Waar staat Be-Better voor? verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.

Wil je dit webinar terugkijken? We hebben een kort samenvatting gemaakt waarin de belangrijkste punten naar voren komen.

Het bericht Terugkijken: Webinar Ketenoptimalisatie voor complexe zorgprocessen verscheen eerst op Welkom bij Be-Better • Innovations 2 Be-Better.