Onderwerp 5.4 — Enterprise resource planning (ERP)

In één zin: Enterprise resource planning is het geïntegreerde backofficesysteem — financiën, personeelszaken, salarisadministratie, inkoop en toeleveringsketen — dat fungeert als het systeem van registratie voor geld, mensen en voorraad van de organisatie, en stilletjes bijna elke werkwijze in dit boek onderbouwt.

Waarom dit ertoe doet in gezondheid en zorg#

Digitale transformatie in gezondheid en zorg krijgt haar aandacht van klinische systemen — het elektronisch patiëntendossier, het gedeelde zorgdossier, de app voor patiënten. Maar geen daarvan draait zonder de onopvallende backoffice eronder. Personeel moet worden geworven, geroosterd en betaald; leveranciers moeten worden gecontracteerd en afgerekend; geneesmiddelen, hulpmiddelen en verbruiksartikelen moeten worden besteld en gevolgd; en elk pond moet worden verantwoord tegen strak begrensde publieke budgetten. ERP is waar dat gebeurt, en wanneer het faalt zijn de gevolgen onmiddellijk: onbetaald personeel, stilgevallen inkoop, niet-afgestemde rekeningen en een financiële functie die blind vliegt.

De schaal is enorm. NHS Shared Business Services (NHS SBS), een joint venture opgericht in 2004, runt een nationaal platform voor financiën en inkoop op basis van Oracle dat miljoenen facturen verwerkt en een zeer groot deel van de totale NHS-uitgaven afhandelt voor meer dan honderd NHS-organisaties (zie Belangrijkste bronnen). ERP-beslissingen zijn dus geen niche-aangelegenheid van financiën — zij vormen het beheer van het personeel, de beheersing van publiek geld en de datakwaliteit waarvan elke analyse stroomafwaarts afhangt. Voor een directeur is ERP zowel een fundamentele mogelijk-maker als een van de risicovolste programma’s die een organisatie ooit zal ondernemen.

Kernbegrippen#

Wat ERP is. Eén enkele, geïntegreerde suite van modules voor enterprise resource planning die één database en één set stamgegevens delen en de kernprocessen van de administratie van de onderneming omvat: grootboek en financiële boekhouding, crediteuren en debiteuren, HR en personeelsadministratie, salarisadministratie, inkoop (purchase-to-pay), voorraad en toeleveringsketen en steeds vaker planning en analyse (FP&A — financial planning and analysis). Het punt van “integratie” is dat een inkooporder, een goederenontvangst en een factuur automatisch sluiten omdat het dezelfde data zijn, niet drie kopieën.

Systeem van registratie (system of record). ERP is de gezaghebbende bron voor financiële data en data over middelen — het grootboek dat accountants vertrouwen en de salarisadministratie waaruit personeel wordt betaald. Andere systemen kunnen operationele kopieën bevatten, maar het ERP is de versie van de waarheid voor geld en vaak voor het inhoudelijke HR-dossier.

Stamgegevens. De gedeelde referentiedata waarvan al het andere afhangt: het rekeningschema, kostenplaatsen, leveranciersdossiers, de artikelcatalogus en personeelsdossiers. Stamgegevens zijn de stille bepalende factor voor het succes van ERP — vuile, dubbele of inconsistente stamgegevens corrumperen rapportage, breken afstemming en ondermijnen elk proces dat erop is gebouwd.

Gangbare platforms in gezondheid en de publieke sector. In de NHS en de bredere Britse publieke sector zijn de belangrijkste ERP-platforms Oracle (dominant, grotendeels via NHS SBS en consortia als NEP), SAP, Unit4 (veel gekozen door ziekenhuizen, universiteiten en lokale overheden) en Microsoft Dynamics 365. Lokale overheden die sociale zorg voor volwassenen leveren draaien dezelfde klasse systemen voor hun financiën en inkoop. De moderne koers is cloud-ERP (software-as-a-service) in plaats van installaties op eigen servers.

Shared services (gedeelde diensten). In plaats van dat elke organisatie haar eigen ERP draait, delen velen een gemeenschappelijk platform en een gemeenschappelijke backofficeoperatie — het model van NHS SBS en NHS-consortia die gesjabloneerde Oracle Cloud-instanties runnen. Shared services ruilen enige lokale flexibiliteit in voor standaardisatie, schaalvoordelen en een kleinere collectieve last van implementatie en ondersteuning.

Beste praktijken#

1. Behandel stamgegevens als fundament, niet als bijzaak. Zuiver en ontdubbel het rekeningschema, de leveranciersdossiers, de artikelcatalogus en de personeelsdata vóór de migratie en vestig doorlopend eigenaarschap voor databestuur. De schadelijkste mislukkingen van ERP zijn terug te voeren op slechte stamgegevens die geen goede software kan herstellen; een werkstroom voor datakwaliteit is niet optioneel.

2. Neem de standaard over; minimaliseer maatwerk. Configureer het ERP naar het standaardsjabloon van de leverancier of het consortium waar het proces werkelijk een gangbaar proces is en bewaar maatwerk voor de zeldzame echte onderscheidende factor. Zwaar maatwerk blaast kosten op, vernietigt de upgradebaarheid en voert de lokale rommel opnieuw in waaraan u wilde ontsnappen — cloud-ERP bestraft in het bijzonder het instinct “laat het eruitzien als ons oude systeem”.

3. Ontwerp de integraties bewust. ERP staat niet op zichzelf: het moet data uitwisselen met systemen voor personeel en elektronisch roosteren, klinische en apotheeksystemen (voor voorraad en kostprijs), bank en analyse. Breng elk koppelvlak in kaart, bezit de datacontracten en test ze van begin tot eind — een salarisadministratie gevoed door een kapotte roosterfeed betaalt mensen verkeerd, en dat is een falen dat het vertrouwen vernietigt.

4. Voer de vervanging van ERP uit als groot programma, met verandermanagement als kern. Een implementatie van ERP is een programma voor bedrijfsverandering dat toevallig software omvat, geen IT-project. Bezet haar met de discipline van een programma (zie Onderwerp 5.2 — Programmagestuurd werken) en een echte inspanning van verandermanagement (zie Onderwerp 8.1 — Verandermanagement), want de meeste pijn van ERP zit in mensen en processen, niet in technologie.

5. Wees eerlijk over het risico van een ERP-programma. Grote implementaties van ERP hebben een welverdiende reputatie van overschrijding van tijd en kosten en onderlevering van baten; de literatuur over falen is uitgebreid en gaat over sectoren heen. Bouw reserve in, vermijd een big-bang go-live waar een gefaseerde aanpak haalbaar is en laat een optimistische planning nooit voorgaan op paraatheid — een verschoven datum is herstelbaar, een verknoeide cut-over van salarisadministratie of grootboek niet.

6. Bescherm de go-live en de periode erna. Plan de cut-over van data, parallel draaien, afstemming en hypercare-ondersteuning in detail en weersta druk ze te verkorten. De weken rond go-live zijn wanneer leveranciers onbetaald blijven en de maandafsluiting breekt; een goed bezette stabilisatieperiode is het verschil tussen een rommelige start en een publieke crisis.

7. Gebruik ERP als systeem van registratie voor middelenbeheer — en ontwerp werkwijzen eromheen. Laat het ERP de enige bron zijn voor kostenplaatsen, budgetten, goedkeuringen van inkoop en de personele formatie, en stem uw operationele processen erop af in plaats van schaduwspreadsheets bij te houden. Schaduwsystemen voeren de fragmentatie opnieuw in die ERP moet wegnemen en laten de datakwaliteit stilletjes wegrotten.

8. Weeg shared services en cloud-ERP op hun werkelijke afwegingen. Gedeelde platforms (NHS SBS, consortia in de stijl van NEP) en cloud-ERP bieden standaardisatie, schaal, continue upgrades en een lichtere lokale last, ten koste van enige lokale flexibiliteit en een afhankelijkheid van de aanbieder. Kies bewust: voor de meeste organisaties weegt de winst van standaardisatie zwaarder dan de verloren flexibiliteit, maar het besluit moet met open ogen worden genomen en niet bij verstek.

Vragen om met uw team te bespreken#

1. Hoe zeker zijn wij — met bewijs, niet met geruststelling — van de kwaliteit van de stamgegevens die wij in een nieuw ERP zouden meenemen, en wie bezit ze na go-live? Stamgegevens zijn de stille bepalende factor voor het succes van ERP, maar worden routinematig behandeld als huishoudelijke taak van de migratie en niet als het fundament dat ze zijn, dus deze vraag toetst of het team hard heeft gekeken naar het rekeningschema, de leveranciersdossiers, de artikelcatalogus en de personeelsdata of simpelweg hoopt dat ze schoon zijn. In een setting van gezondheid en zorg is de inzet concreet: dubbele leveranciersdossiers breken de afstemming van purchase-to-pay, een personeelsbestand dat niet overeenstemt met ESR betaalt mensen verkeerd en een inconsistent rekeningschema corrumpeert elk financieel rapport stroomafwaarts waarop het bestuur en accountants leunen. De spanning om te debatteren is de trek om in zijn geheel te migreren om een datum te halen tegenover de maanden onopvallend zuiveren en ontdubbelen die goede praktijk vraagt, en of iemand senior bereid is een werkstroom voor datakwaliteit te financieren die geen zichtbaar product toont. Een sterk antwoord noemt werkelijke aantallen — hoeveel dubbele leveranciers, hoeveel niet-afgestemde personeelsdossiers — in plaats van een algemeen gevoel dat “de data grotendeels in orde zijn”. Het moet ook de persoon en het bestuursmechanisme noemen die verantwoordelijk zijn voor de kwaliteit van stamgegevens na go-live, want data die eenmaal worden gezuiverd en daarna onbestuurd blijven driften gewoon terug naar wanorde.

2. Waar worden wij werkelijk verleid het ERP aan te passen om een vertrouwd proces te behouden, en is dat verschil een echte onderscheidende factor of gewoon de oude rommel waaraan wij proberen te ontsnappen? Zwaar maatwerk is de klassieke valkuil van ERP in de onderneming: het blaast kosten op, vernietigt de upgradebaarheid en voert juist de lokale fragmentatie opnieuw in die het programma moest wegnemen, en cloud-ERP bestraft in het bijzonder het instinct om “het eruit te laten zien als ons oude systeem”. Deze vraag vraagt het team specifiek te zijn over welke processen het de software zal willen buigen en elk te rechtvaardigen tegen de harde toets of het een echte onderscheidende factor is of louter comfortabele gewoonte. Het debat doet ertoe omdat in gezondheid en zorg vrijwel elk backofficeproces — grootboek, goedkeuringen van inkoop, salarisadministratie — werkelijk een gangbaar proces is, dus de eerlijke standaard moet zijn het standaardsjabloon van de leverancier of het consortium over te nemen en het proces te wijzigen, niet de software. Concrete invalshoeken zijn elk gevraagd maatwerk opsommen en vragen wie ervan profiteert, welke upgradekosten het vastlegt en of een naburig ziekenhuis op hetzelfde sjabloon het zonder redt. Een goed antwoord onderscheidt de zeldzame legitieme uitzondering van de vele verzoeken die voortkomen uit afkeer van verandering, en erkent dat de standaard overnemen een probleem van verandermanagement en leiderschap is, geen technisch. Het moet ook de langetermijnkosten onder ogen zien: elke maatwerkwijziging is een belasting die bij elke toekomstige cloudrelease opnieuw wordt betaald.

3. Hebben wij de menselijke en procesmatige kant van deze ERP-verandering eerlijk bemand — cut-over, parallel draaien, hypercare, training en integratietesten — of draaien wij haar stilletjes als IT-project? De literatuur over falen is ondubbelzinnig dat de meeste pijn van ERP in mensen en processen zit en niet in technologie, dus deze vraag onthult of het programma werkelijk een inspanning voor bedrijfsverandering is of een IT-vervanging in programmakleren. De periode rond go-live is wanneer leveranciers onbetaald blijven, de maandafsluiting breekt en personeel te laat wordt betaald, en elk daarvan is in een publiek gezondheidsorgaan geen rommelige start maar een vertrouwensvernietigend, mogelijk in het nieuws komend falen. De spanning om te debatteren is de voortdurende druk om parallel draaien te verkorten, het hypercare-team uit te dunnen en de planning samen te persen om een opgelegde datum te halen, tegenover de werkelijkheid dat een verschoven datum herstelbaar is terwijl een verknoeide cut-over van salarisadministratie of grootboek dat niet is. Nuttige invalshoeken zijn elk koppelvlak doorlopen — elektronisch roosteren, ESR, apotheekvoorraad, bank, analyse — en vragen welke van begin tot eind zijn getest en welke zijn aangenomen, en of procesverantwoordelijken in financiën, inkoop en HR werkelijk zijn gedetacheerd om hun werkstromen te herontwerpen. Een eerlijk antwoord toont benoemde middelen voor verandermanagement, training en afstemming in het plan en niet een regel die zegt “IT regelt het”, en is bereid de go-live te faseren waar een big-bang-cut-over vermijdbaar risico toevoegt. Het moet ook erkennen dat paraatheid, niet de kalender, het besluit om door te gaan moet bepalen.

4. Hebben wij bij de vraag over shared services en cloud-ERP de standaardisatie die wij zouden winnen afgewogen tegen de lokale flexibiliteit die wij zouden opgeven — en dat bewust besloten en niet bij verstek? Gedeelde platforms als NHS SBS en Oracle Cloud-instanties van consortia, en cloud-ERP breder, bieden echte prijzen — schaalvoordelen, continue upgrades, een lichtere lokale last van implementatie en ondersteuning — maar kopen die met een echt verlies van lokale controle en een harde afhankelijkheid van de roadmap en releasecadans van de aanbieder. Deze vraag dwingt het team te noemen welke flexibiliteit er werkelijk toe doet en te toetsen of die de kosten waard is van het zelf draaien, patchen en afzonderlijk ondersteunen van de eigen backoffice. De spanning in een setting van gezondheid en zorg wordt aangescherpt door het feit dat het meeste backofficeproces gangbaar is, zodat de winst van standaardisatie doorgaans zwaarder weegt dan de verloren flexibiliteit — maar “doorgaans” is niet “altijd”, en afdrijven naar een gedeeld platform zonder de afweging te onderzoeken is hoe organisaties eindigen met wrok jegens een sjabloon dat zij nooit bewust kozen. Concrete invalshoeken zijn vragen welke lokale processen het team zou verdedigen en waarom, wat er gebeurt wanneer het consortium het sjabloon onder hen verandert en of de voorwaarden voor uitstap en dataportabiliteit worden begrepen vóór ondertekening. Een sterk antwoord behandelt dit als strategische keuze met open ogen gemaakt, waarbij afhankelijkheid van de aanbieder en risico van de roadmap worden afgewogen tegen schaal en verlichting van upgrades, en niet bij verstek voor de gedeelde optie kiest omdat die in de mode is of zich uit gewoonte vastklampt aan een maatwerkplatform.

5. Wat is ons eerlijke plan om te voorkomen dat schaduwspreadsheets en lokale omwegen na go-live terugkeren, zodat het ERP het enige systeem van registratie blijft en niet één bron onder velen? Het hele punt van een geïntegreerd ERP is de fragmentatie weg te nemen die schaduwsystemen creëren, en toch hebben lokale spreadsheets de gewoonte een go-live te overleven en de data die het programma moest verenigen stilletjes weer te fragmenteren. Deze vraag toetst of het team voorbij de cut-over heeft gedacht naar de duurzame bedrijfsdiscipline die kostenplaatsen, budgetten, goedkeuringen van inkoop en de personele formatie in het ERP laat leven en niet in iemands privéwerkboek. Het doet ertoe in gezondheid en zorg omdat een schaduwspreadsheet van de formatie die niet overeenstemt met de salarisadministratie, of een inkooptracker buiten het systeem, de datakwaliteit waarvan rapportage aan het bestuur en audit afhangen stilletjes laat wegrotten, en dat juist doet omdat het handig is voor degene die het bijhoudt. De spanning die aan het licht moet komen is dat schaduwsystemen gewoonlijk een reden hebben — het proces in het ERP voelde trager, of een echt gat werd nooit gedicht — dus ze simpelweg verbieden faalt tenzij de onderliggende behoefte wordt aangepakt. Nuttige invalshoeken zijn vragen welke huidige spreadsheets bij go-live moeten sterven, waarom elk bestaat en welke mogelijkheid in het systeem of wijziging van proces de verleiding zou wegnemen het opnieuw te bouwen. Een eerlijk antwoord koppelt een duidelijke verwachting dat het ERP gezaghebbend is aan een plan om de gaten te herstellen die mensen buiten het systeem drijven, en noemt wie een schaduwsysteem zal opmerken en aanspreken wanneer het terugkeert.

6. Zijn wij werkelijk eerlijk over het risico van een ERP-programma — het trackrecord van de sector van overschrijding en onderlevering — en hebben wij onze planning, reserve en go-live-aanpak rond die werkelijkheid gebouwd in plaats van rond een optimistisch plan? Grote implementaties van ERP hebben een welverdiende reputatie, over sectoren heen, van overschrijding van tijd en kosten en onderlevering van baten, en deze vraag vraagt of het team die literatuur over falen heeft verinnerlijkt of stilletjes aanneemt dat het de uitzondering zal zijn. De inzet in een publiek gezondheidsorgaan is meedogenloos: een verschoven datum is herstelbaar, maar een verknoeide cut-over van salarisadministratie of grootboek is een gebeurtenis die in het nieuws komt en vertrouwen vernietigt, met gevolgen in het Parlement en de pers, dus optimisme dat paraatheid terzijde schuift is geen moed maar roekeloosheid. De spanning om te debatteren is de voortdurende druk — van opgelegde data, gezonken kosten en de wens voortgang te tonen — om de planning samen te persen, de reserve uit te dunnen en een big-bang-go-live te verkiezen boven een gefaseerde die veiliger maar trager zou zijn. Concrete invalshoeken zijn vragen wat het plan aanneemt dat goed zal gaan, waar de reserve werkelijk zit, of een gefaseerde cut-over haalbaar is en wat de expliciete criteria zijn om de go-live uit te stellen als paraatheid ontbreekt. Een goed antwoord noemt de specifieke risico’s die dit programma draagt in plaats van naar het risico van ERP in het algemeen te gebaren, bouwt echte reserve en een verdedigbaar besluit over fasering in en behandelt een op data gebaseerd “nog niet” als een legitieme en verwachte uitkomst en niet als een gebrek aan moed.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een algemeen NHS-ziekenhuis draait een vijftien jaar oud systeem voor financiën en inkoop op eigen servers dat de leverancier binnenkort niet meer zal ondersteunen. Rapportage kost dagen, purchase-to-pay is zwaar handmatig en de personele formatie leeft in een kluwen van spreadsheets die nooit helemaal overeenstemt met de salarisadministratie. Het ziekenhuis besluit over te stappen op een cloud-ERP geleverd via de gesjabloneerde Oracle Cloud-instantie van een regionaal NHS-consortium, samen met naburige aanbieders.

De financieel directeur weerstaat de verleiding dit als een IT-vervanging te behandelen. Er wordt een programma opgezet met een executive sponsor, een voltijds programmamanager en — cruciaal — een werkstroom voor datakwaliteit die maanden besteedt aan het zuiveren van het rekeningschema, het ontdubbelen van twaalfduizend leveranciersdossiers en het afstemmen van het personeelsbestand op ESR (het elektronisch personeelsdossier van de NHS) vóór enige migratie. Procesverantwoordelijken in financiën, inkoop en HR worden gedetacheerd om hun werkstromen te herontwerpen naar het sjabloon van het consortium in plaats van het oude systeem te repliceren.

Het ziekenhuis kiest een gefaseerde go-live: financiën en inkoop eerst, personeel en rapportage in een latere golf, met parallel draaien over twee maandafsluitingen en een goed bemand hypercare-team in paraatheid. Koppelingen met elektronisch roosteren, de bank en het analysewarehouse worden in kaart gebracht en van begin tot eind getest. De go-live is niet pijnloos — in de eerste week bouwt zich een achterstand in leveranciersbetalingen op die twee weken nodig heeft om weg te werken — maar omdat afstemming en hypercare behoorlijk waren bemand, wordt geen personeel te laat betaald en sluit de maand op tijd af.

Een jaar later sluit het ziekenhuis zijn boeken in dagen in plaats van weken, worden goedkeuringen van inkoop in het systeem afgedwongen en stemt de formatie eindelijk overeen met de salarisadministratie. Het gedeelde platform van het consortium betekent ook dat de volgende upgrade arriveert als routinematige cloudrelease in plaats van nog een meerjarig project.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid draait zelden een volledig ERP; zij knoopt cloud-SaaS-instrumenten aan elkaar — een lichte boekhoudapplicatie, een app voor HR en salarisadministratie, een paar spreadsheets — omdat een zware geïntegreerde suite buiten verhouding is voor een team van dertig. De discipline van het systeem van registratie doet er toch toe: zelfs in de seedfase voorkomen één schoon rekeningschema en één gezaghebbende bron voor salarisadministratie de chaos van afstemming die investeerders tijdens due diligence afschrikt. De juiste zet is de stack eenvoudig, integreerbaar en goed bestuurd te houden en een “echt” ERP uit te stellen tot schaal het werkelijk vraagt. Het risico van de startup is het spiegelbeeld van dat van de grote onderneming — niet overmatig maatwerk maar wildgroei: een dozijn losse apps zonder eigenaar van stamgegevens en niemand die verantwoordelijk is voor de cijfers.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis, een thuiszorgorganisatie of een kliniek met één vestiging — draagt het volle gewicht van financiële plichten, salarisadministratie en inkoop met vrijwel geen toegewijd financieel of IT-vermogen, dus een zwaar ERP is buiten bereik maar de discipline van het systeem van registratie is niet optioneel. Het praktische antwoord is een kleine, goed geïntegreerde set cloudpakketten — boekhouding, salarisadministratie en voorraad — zo gekozen dat één rekeningschema en één gezaghebbende bron voor salarisadministratie gelden, want een verzorgingshuis dat personeel te laat betaalt of een apotheek waarvan voorraad en grootboek niet overeenstemmen staat voor dezelfde gevolgen voor regelgeving en liquiditeit als een groot ziekenhuis maar zonder backofficeteam om ze op te vangen. De verleiding om het bedrijf te runnen op de spreadsheet van een oprichter is hier het sterkst en het gevaarlijkst, omdat er zelden iemand is die opmerkt wanneer de cijfers afdrijven. Waar een beroepsorganisatie, franchise of lokaal netwerk een gedeeld of gestandaardiseerd financieel platform aanbiedt, is het overnemen ervan doorgaans de verstandige zet: het koopt de standaardisatie en ondersteuning die de organisatie zelf niet kan bemensen. De discipline is de stack eenvoudig te houden en bestuurd te laten worden door wie het geld bezit, en maatwerkomwegen te weerstaan die alleen die ene persoon begrijpt.

Grote onderneming#

Een groot ziekenhuis of bedrijf in health-tech draait een volledig geïntegreerd ERP als bedrijfskritisch systeem van registratie, en het vervangen ervan is een van de risicovolste programma’s die het ooit zal ondernemen. De verleiding voor de grote onderneming is zwaar maatwerk om vertrouwde legacyprocessen te behouden; de discipline is het standaardsjabloon over te nemen, een serieuze werkstroom voor datakwaliteit te bemensen en de go-live te draaien met parallel draaien en een goed bezette hypercare-periode. Koppelingen vermenigvuldigen zich — elektronisch roosteren, ESR, apotheekvoorraad, bank, analyse — en elk is een vertrouwensvernietigend falen als het stilletjes de salarisadministratie of maandelijkse afstemming breekt. Omdat de meeste pijn in mensen en processen zit en niet in technologie, wordt het programma van de grote onderneming gewonnen of verloren bij verandermanagement (zie Onderwerp 8.1 — Verandermanagement). Verantwoording aan een bestuur en accountants maakt een verknoeide cut-over van grootboek of salarisadministratie tot een bestuurlijk incident, niet slechts een IT-tegenslag.

Overheid#

Op nationale schaal en schaal van shared services is ERP een instrument van standaardisatie: NHS Shared Business Services en Oracle Cloud-instanties van consortia bestaan om veel organisaties één gesjabloneerd platform te geven en ruilen lokale flexibiliteit in voor schaalvoordelen en continue upgrades. Verantwoording aan de overheid voegt toetsing van openbare aanbesteding (concurrerende raamwerken, zekerheid van waar voor geld) toe aan elke grote ERP-beslissing, en een falende nationale cut-over heeft gevolgen in het Parlement en de pers. De echte hefboom van het centrum is bijeenroepen — gedeelde platforms verplicht stellen of stimuleren zodat tientallen ziekenhuizen en lokale overheden niet elk hun eigen backoffice runnen, patchen en afzonderlijk laten falen. De bepalende spanning is die tussen nationale standaardisatie en lokale autonomie: duw het sjabloon te hard en adoptie stokt in wrok; te zacht en de fragmentatie die ERP moet wegnemen blijft stilletjes bestaan.

Veelvoorkomende faalpatronen#

• Vuile stamgegevens in hun geheel gemigreerd. Oude duplicaten en inconsistenties worden meegenomen naar het nieuwe systeem en corrumperen de rapportage vanaf dag één. Oplossing: zuiver en bestuur stamgegevens vóór de migratie en bezit ze daarna.
• Aanpassen om het oude systeem te repliceren. Maatwerk gemaakt om verandering van proces te vermijden blaast kosten op en vernietigt de upgradebaarheid. Oplossing: neem het standaardsjabloon over; verander het proces, niet de software.
• ERP als IT-project uitgevoerd. Het als technologische vervanging behandelen laat de inspanning voor verandering, training en herontwerp van processen verhongeren. Oplossing: draai het als programma voor bedrijfsverandering met echt verandermanagement (Onderwerp 8.1).
• Optimistische big-bang-go-live. Samengeperste planningen en één enkele cut-over maken gewone problemen tot publieke crises. Oplossing: faseer waar haalbaar en ruil paraatheid nooit in voor een datum.
• Kapotte koppelingen. Een niet-geteste feed van roosteren naar salarisadministratie of van inkoop naar grootboek betaalt mensen verkeerd of breekt de afstemming. Oplossing: breng elk koppelvlak in kaart, bezit het en test het van begin tot eind.
• Schaduwspreadsheets overleven. Lokale omwegen blijven naast het ERP bestaan en fragmenteren de data opnieuw. Oplossing: maak het ERP het enige systeem van registratie en schaf de schaduwen af.

Volwassenheidsmodel#

Checklist#

• Het rekeningschema en de stamgegevens van leveranciers, artikelen en personeel zijn vóór de migratie gezuiverd en ontdubbeld.
• Doorlopend eigenaarschap en bestuur van stamgegevens zijn toegewezen en gefinancierd.
• De implementatie is afgebakend en bemand als programma voor bedrijfsverandering, niet als IT-project.
• Maatwerk is geminimaliseerd; het standaardsjabloon van de leverancier of het consortium is overgenomen voor gangbare processen.
• Elk koppelvlak (roosteren, salarisadministratie/ESR, klinisch/apotheek, bank, analyse) is in kaart gebracht, bezeten en van begin tot eind getest.
• De aanpak van go-live (gefaseerd versus big bang) is gekozen op paraatheid, niet op een opgelegde datum.
• Cut-over van data, parallel draaien, afstemming en een hypercare-periode zijn gepland en bemand.
• Verandermanagement, training en herontwerp van processen zijn expliciet bemand (zie Onderwerp 8.1).
• Opties voor shared services en cloud-ERP zijn beoordeeld op hun werkelijke afwegingen tussen standaardisatie en flexibiliteit.
• Het ERP is gevestigd als het enige systeem van registratie, en schaduwspreadsheets zijn afgeschaft.

Belangrijkste bronnen#

• NHS Shared Business Services (NHS SBS) — de nationale shared service voor financiën en inkoop op basis van Oracle voor NHS-organisaties. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — schaal van het nationale financiële platform van de NHS. https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP-consortium — gesjabloneerd Oracle Cloud-ERP voor NHS-leden. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP voor NHS-ziekenhuizen, lokale overheden en universiteiten. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — financiële processen die ERP onderbouwt. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — het personeels- en salarissysteem van de NHS waarmee ERP moet integreren. https://www.electronicstaffrecord.nhs.uk/
• Zie ook Onderwerp 5.2 — Programmagestuurd werken, Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM) en Onderwerp 8.1 — Verandermanagement.

Referenties#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/