ERP-beheer na go-live: rollen, budget en regie in vier lagen

Stel u een technische groothandel voor waar het ERP-beheer na de go-live bij één functioneel beheerder is beland. Zij opent haar mailbox, en het eerste verzoek van de dag begint met “kun je even”. Een prijsafspraak die anders moet worden vastgelegd, een overzicht voor de inkoper, een gebruiker die na de recente update een veld kwijt is.

Tijdens het project was zij key user voor de orderverwerking. Toen het projectteam vertrok, bleef zij over als degene die het systeem van binnenuit kende, en zo werd zij beheerder zonder dat iemand dat ooit had besloten.

In hetzelfde voorbeeld staat het ERP-systeem in de vergadering van het managementteam (MT) als afgerond punt. De implementatie is opgeleverd, de projectbegroting is gesloten en de stuurgroep is opgeheven. Wat in die vergadering niemand hardop zegt: de baten uit de businesscase moeten nog komen, en veel daarvan zal via haar bureau moeten lopen.

Wij vinden dat dit moment een eigen fase in de levensloop van een ERP-systeem verdient. Het project had een eigenaar, een budget en een einddatum. Heeft het beheer dat erop volgt geen van de drie, dan rust de rest van de levensduur van het systeem op goede bedoelingen.

ERP-beheer is het geheel van rollen, afspraken en budget waarmee een organisatie haar ERP-systeem na de go-live bruikbaar, veilig en in lijn met de bedrijfsvoering houdt.

Deze gids beschrijft wat daarbij hoort, waar de waarde na de go-live kan weglekken, hoe u uw eigen beheer in twaalf vragen toetst en hoe u besluit wat u zelf doet en waar u ondersteuning bij zoekt. Bij elk onderdeel verwijzen wij naar een artikel dat er dieper op ingaat. Wij leveren zelf ERP-beheer, support en doorontwikkeling, en schrijven deze gids zo dat u er ook zonder ons mee verder kunt.

Wat ERP-beheer omvat: vier lagen met elk een eigen eigenaar

In deze gids onderscheiden wij vier beheerlagen: functioneel beheer, applicatiebeheer, technisch beheer en de regie over wat er verandert. Wij vinden dat die vierde laag apart aandacht verdient, omdat hij tijdens het project bij de stuurgroep ligt en na de go-live alleen een plek krijgt als iemand hem bewust toewijst.

Laag	De vraag die deze laag beantwoordt	Wie hem kan dragen	Wat er kan gebeuren als niemand hem bezit
Functioneel beheer	Doet het systeem wat de bedrijfsprocessen vandaag nodig hebben?	Een functioneel beheerder, met key users per kernproces	Wensen en vragen stapelen zich op bij wie toevallig veel van het systeem weet
Applicatiebeheer	Zijn inrichting, maatwerk en koppelingen technisch in orde en gedocumenteerd?	Een applicatiebeheerder, de implementatiepartner of de leverancier	Aanpassingen worden gedaan door wie er tijd voor heeft, en niemand kan ze later terugvinden
Technisch beheer	Draait het systeem veilig en beschikbaar, met updates op tijd getest?	De eigen IT-afdeling, een hostingpartij of de cloudleverancier	Updates schuiven door tot ze samen een klein project zijn geworden
Regie en doorontwikkeling	Wat verandert er, in welke volgorde, en wie besluit daarover?	Proceseigenaren met een beheeroverleg dat over prioriteit en budget mag beslissen	De wensenlijst wordt een loket, en wie blijft aandringen krijgt voorrang

De lagen hangen aan elkaar, maar volgens ons vragen ze verschillende mensen. Een functioneel beheerder die ook updates moet testen, koppelingen moet bewaken en de prioriteiten moet bepalen, draagt vier rollen in één functie. Dat kan een tijd goed gaan, maar het risico is een achterstand die pas zichtbaar wordt als hij er al is.

Functioneel beheer: de vertaling tussen bedrijf en systeem

Functioneel beheer is de laag die dicht bij uw mensen zit. De functioneel beheerder vertaalt een vraag uit de organisatie naar een wijziging in het systeem, of legt uit waarom die wijziging geen goed idee is. Hij of zij beheert de inrichting van de processen, de autorisaties en de stamgegevensafspraken, en vangt de vragen van gebruikers op.

De vraag of u deze rol zelf opbouwt of deels laat invullen, werken wij uit in ERP functioneel beheer: intern opbouwen of uitbesteden?. Ons advies in het kort: de kennis van uw processen hoort in huis, ook als de handen deels van buiten komen.

Applicatiebeheer en koppelingen: wat er onder de motorkap is veranderd

Applicatiebeheer gaat over de technische kant van de applicatie zelf: de configuratie, het maatwerk, de rapportages en de koppelingen met andere systemen. Deze laag kan bij een eigen applicatiebeheerder liggen of bij de implementatiepartner, bijvoorbeeld op basis van een supportcontract dat na de go-live is afgesloten.

Een risico zit in de koppelingen. Een koppeling met een webshop, een transportplanner of een magazijnsysteem kan gaan haperen zodra aan een van beide kanten iets verandert. Wie dan merkt dat er orders blijven hangen, en wie het oplost, is een beheerafspraak en geen technische eigenschap. Dat werken wij verder uit in ons artikel over ERP-integraties beheren.

Technisch beheer en updates: het ritme van de leverancier

Technisch beheer houdt het systeem beschikbaar en veilig: hosting, back-ups, beveiliging, performance en het installeren van updates. Bij een cloudoplossing kan de leverancier een deel van het technische werk overnemen; welk deel, leest u in uw eigen contract. Ook dan blijft volgens ons bij u de vraag of uw inrichting, uw maatwerk en uw koppelingen een update overleven.

Werkt u met cloud-ERP, zeker in een SaaS-variant, ga dan in uw eigen contract en afspraken na wie het ritme van de updates bepaalt en hoeveel ruimte u heeft om een update uit te stellen. Of uw organisatie er op tijd klaar voor is, bepaalt u zelf. Hoe u dat organiseert zonder elke release als een verrassing te behandelen, leest u in ERP-updates testen na go-live.

Regie en doorontwikkeling: wie besluit wat er verandert

De vierde laag is minder zichtbaar dan de andere drie, en wij vinden hem daarom extra aandacht waard. Na de go-live kunnen er wensen binnenkomen uit elke afdeling: een extra veld, een nieuw rapport, een aangepaste workflow, een koppeling met een nieuw systeem. Elke wens op zich is redelijk. Samen vormen ze een stroom die volgens ons richting nodig heeft, en die richting kan komen uit een vast overleg met mensen die over budget en prioriteit mogen beslissen.

Waar de waarde na de go-live kan weglekken

In zijn analyse “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives” doet Gartner een voorspelling die hier direct raakt. Gartner voorspelt dat meer dan 70 procent van de recent ingevoerde ERP-initiatieven de oorspronkelijke bedrijfsdoelen niet volledig haalt. Dat cijfer gaat over doelen, en zegt niets over deadlines, budgetten of afgebroken projecten. Het is bovendien een voorspelling, met een horizon tot 2027.

Wij lezen het zo, en dat is onze redenering en geen meting: veel bedrijfsdoelen van een ERP-systeem, zoals snellere orderafhandeling, betrouwbaardere voorraad of een kortere maandafsluiting, kunnen pas na de go-live worden gerealiseerd. Daarom vinden wij dat voor een groot deel in de beheerfase wordt beslist of een ERP-investering haar bedrijfsdoelen haalt: veel baten kunnen pas ontstaan als mensen het systeem dagelijks gebruiken en verbeteren. Dat maakt een helder doel vooraf niet minder belangrijk: een doel dat bij de start vaag is vastgelegd, is volgens ons ook met goed beheer later lastig binnen te halen.

Wij onderscheiden vier plekken waar die waarde kan weglekken, en dat hoeft niet in één keer te gebeuren.

De overdracht zonder ontvanger. Stel dat het projectteam elke inrichtingskeuze, elk stuk maatwerk en elke tijdelijke oplossing kent. Vertrekt het team aan het eind van het project, dan kan die kennis mee de deur uitgaan, tenzij iemand haar vooraf heeft overgenomen. Wat dan overblijft, zit alleen nog in het hoofd van de mensen die het project van dichtbij meemaakten. Waarom dat een kwetsbaarheid is en hoe u haar spreidt, leest u in ERP-continuïteit: waarom uw systeem draait op de kennis van één of twee mensen.

De uitgestelde update. Stel dat een update een keer wordt overgeslagen omdat de maandafsluiting eraan komt, en daarna nog een keer omdat er niemand is om te testen. Dan wordt de volgende update groter, omdat de wijzigingen zich opstapelen. Werkt u met cloud-ERP, ga dan in uw contract na hoeveel uitstel is toegestaan en wat er gebeurt als die ruimte op is.

De wensenlijst zonder weging. Zonder een plek waar wensen tegen elkaar worden afgewogen, kan de functioneel beheerder de scheidsrechter tussen afdelingen worden. Dat is volgens ons een rol die niet bij die functie hoort, en er hoort dan ook geen mandaat bij.

De beheerder die het er ook nog bij doet. Ligt het beheer bij één persoon naast een andere baan, dan kan dat werken zolang er weinig verandert. Groeit de organisatie, opent zij een vestiging of gooit zij een proces om, dan kan er een achterstand ontstaan die de beheerder naast het eigen werk niet meer inhaalt. Welke specialist u in welke fase nodig heeft, beschrijven wij in ERP-capaciteitsplanning.

Een mogelijk symptoom van alle vier is het Excel-bestand naast het systeem. Houdt een afdeling een eigen lijst bij, dan kan dat erop wijzen dat het systeem iets niet doet wat zij nodig heeft, of dat de weg naar een wijziging voor haar te lang voelt.

De beheerscan: twaalf vragen in vier lagen

Met de vragen hieronder toetst u uw eigen beheer. Beantwoord ze met ja, deels of nee, bij voorkeur met de functioneel beheerder en iemand uit de IT-organisatie samen aan tafel. Tel een “deels” voor de uitkomst als een nee: volgens ons is dat het antwoord waarachter beheerproblemen schuil kunnen gaan.

Functioneel beheer

1. Is er een functioneel beheerder formeel aangewezen, met uren die in de functie zijn vrijgemaakt?
2. Heeft elk kernproces, van verkoop en inkoop tot voorraad en financiën, een key user die weet bij wie een proceswijziging moet worden goedgekeurd?
3. Komen nieuwe medewerkers via een vaste inwerkroute bij het systeem binnen, met uitleg over het waarom van de inrichting?

Applicatiebeheer

1. Zijn het maatwerk en de koppelingen vastgelegd op een plek die iemand anders dan de bouwer kan vinden en begrijpen?
2. Weet u per koppeling wie een storing als eerste opmerkt en wie hem oplost?
3. Is er een testomgeving die inhoudelijk overeenkomt met uw productieomgeving?

Technisch beheer

1. Weet u wanneer de volgende update van uw leverancier komt, en wie hem test voordat hij live gaat?
2. Zijn de updates van het afgelopen jaar op tijd geïnstalleerd, zonder dat er een is uitgesteld omdat niemand kon testen?
3. Zijn er reactietijden afgesproken met uw leverancier of hostingpartij, en weet de beheerder waar die afspraken staan?

Regie en doorontwikkeling

1. Is er een vast overleg dat over wijzigingsverzoeken beslist, met deelnemers die over prioriteit en budget mogen besluiten?
2. Staat beheer en doorontwikkeling als eigen post in de begroting, los van licenties en IT-exploitatie?
3. Kunt u in één zin zeggen welk doel uit de oorspronkelijke businesscase het systeem dit jaar dichterbij moet brengen?

Wat de uitkomst betekent

Lees de eerste drie rijen van boven naar beneden en stop bij de eerste die op u past. Vraag 12 beoordeelt u altijd apart.

Uitkomst	Wat het volgens ons betekent	Wat u kunt doen
Nee’s in drie of vier lagen, ook als het er per laag maar één is	Het beheer draait op inzet van personen in plaats van op afspraken	Begin bij laag vier: zonder regie kunnen verbeteringen in de andere lagen weer verdwijnen
Twee of meer nee’s binnen één laag	Die laag heeft feitelijk geen eigenaar, ook als er een naam in het organogram staat	Wijs per nee een eigenaar en een datum aan, en kijk of die eigenaar er ook de tijd voor heeft
Nee’s in hooguit twee lagen, met hooguit één per laag	Uw beheer is belegd. Er zijn aandachtspunten, maar geen laag zonder eigenaar	Zet de nee’s op de agenda van het beheeroverleg en herhaal de scan na de volgende grote update
Apart: nee op vraag 12	Het systeem wordt onderhouden, maar niemand stuurt op de opbrengst	Haal de businesscase erbij en kies één doel voor het komende jaar

Vraag 12 verdient volgens ons aparte aandacht. Een organisatie kan elk van de eerste elf punten op orde hebben en toch een systeem beheren dat netjes draait zonder dat iemand weet waarvoor.

Zelf doen, combineren of laten ondersteunen: per laag beslissen

De vraag “intern of uitbesteden?” kan uitmonden in een alles-of-niets-discussie. Wij vinden het zinvoller om het per laag te beslissen, want de lagen verschillen in hoeveel kennis van uw organisatie ze vragen en hoe gelijkmatig het werk binnenkomt.

Laag	Wat u bij voorkeur in huis houdt	Wat u goed kunt laten ondersteunen	Waar u bij ondersteuning op let
Functioneel beheer	De procesrol, de contacten met de afdelingen en het oordeel over wat een wens waard is	Pieken in het werk, vervanging bij afwezigheid en specialistische kennis van een module	Dat de kennis die de ondersteuner opdoet, in uw eigen documentatie terechtkomt
Applicatiebeheer	Het overzicht van maatwerk en koppelingen, en de eigen beslissing over wijzigingen	De bouw, het onderhoud van maatwerk en de bewaking van koppelingen	Dat de partij die bouwt niet ook als enige beoordeelt of de bouw goed is
Technisch beheer	De afspraken en de controle daarop	Hosting, monitoring, back-ups en het technische deel van updates	Reactietijden die passen bij uw bedrijfskritische momenten, zoals de maandafsluiting
Regie en doorontwikkeling	Het besluit over prioriteit en budget: dit hoort altijd bij u	Voorbereiding, een onafhankelijke blik op de roadmap en het bewaken van de samenhang	Dat de adviseur geen belang heeft bij de keuzes die u maakt, ook als die adviseur ERP Company is

Drie vragen helpen bij het besluit:

• Is de stroom aan wijzigingen groot en gelijkmatig genoeg om iemand een volledige werkweek bezig te houden?
• Zit de kennis van uw systeem nu bij één persoon, en wat gebeurt er als die een aantal weken weg is?
• Wie beoordeelt de kwaliteit van het werk dat u laat doen?

Is het antwoord op die derde vraag “dezelfde partij die het werk doet”, dan heeft u een controle nodig die daar los van staat.

Hoe zo’n combinatie wordt ingericht, verschilt per organisatie.

Het eerste jaar na go-live: drie overgangen

Wij delen het eerste jaar na de go-live op in drie overgangen. Elke overgang heeft een eigen moment waarop de verantwoordelijkheid verschuift, en bij elke overgang kan er iets verloren gaan als niemand dat moment bewust markeert.

Van project naar hypercare. Staat het projectteam direct na de go-live nog klaar om meldingen op te vangen, spreek dan vooraf af wie meldingen aanneemt, hoe ze worden geprioriteerd en wanneer de hypercare stopt. Leg dat eindpunt vast als criterium en koppel het aan een meetbare situatie, bijvoorbeeld als het aantal nieuwe blokkerende meldingen een aantal weken achter elkaar laag blijft en de eerste maandafsluiting in het nieuwe systeem goed is verlopen.

Van hypercare naar de staande organisatie. Dit is het moment van de overdracht. Een goed overdrachtsdossier bevat volgens ons de inrichtingskeuzes met hun reden, het maatwerk, de koppelingen, de openstaande punten en de tijdelijke oplossingen die tijdens het project zijn ingevoerd. Let vooral op die tijdelijke oplossingen: een handmatige tussenstap die als tijdelijke oplossing bedoeld was, kan anders nog lang in een werkinstructie blijven staan die niemand meer kent. Hoe zulke tijdelijke maatregelen kunnen ontstaan als een traject onder druk staat, beschrijven wij in Uw ERP-implementatie loopt uit.

Van de staande organisatie naar doorontwikkeling. Zodra het systeem stabiel is, kan de vraag verschuiven van “werkt het?” naar “wat kan het nog meer?”. Dat is volgens ons het moment voor een eerste roadmap voor het systeem: welke wensen bundelt u, welke verbeteringen brengen een doel uit de businesscase dichterbij, en wat laat u bewust liggen.

ERP-beheer begroten zonder vuistregel

In een eerdere versie van dit artikel noemden wij een vaste vuistregel voor het jaarlijkse beheerbudget, uitgedrukt als percentage van de implementatiekosten. Die vuistregel hebben wij geschrapt, net als een onderzoekscijfer en een aantal trajecten uit die versie, omdat wij die niet tot een controleerbare bron konden herleiden. Wij publiceren geen eigen praktijkcijfers, en een percentage dat los staat van uw situatie geeft schijnzekerheid: een organisatie met veel maatwerk en koppelingen heeft waarschijnlijk een ander beheer nodig dan een organisatie die dicht bij de standaard is gebleven.

Een betrouwbaarder begroting bouwt u op vanuit uw eigen beheer. Vijf posten zijn daarbij volgens ons bepalend:

1. De interne uren. De functioneel beheerder, en de uren die key users aan beheer besteden. Neem de uren van key users bewust mee, ook als ze in een andere functie worden geboekt.
2. De contracten. Support van de implementatiepartner, hosting en de afspraken met de leverancier. Licenties horen hier niet bij: dat is exploitatie en geen beheer.
3. De testcapaciteit per update. Reken met het aantal updates per jaar en de uren die een goede test per keer vraagt, inclusief de key users die moeten aftekenen.
4. De doorontwikkeling. Een budget per kwartaal voor wijzigingen die het beheeroverleg goedkeurt. Zonder vaste post wordt elke verbetering een losse aanvraag, en losse aanvragen lopen het risico het te verliezen van de waan van de dag.
5. De reserve voor het onverwachte. Een wijziging in wetgeving, een nieuwe vestiging of een overname kan aanpassingen vragen die in geen enkele planning stonden.

Gebruik bijvoorbeeld het afgelopen halfjaar als vertrekpunt: hoeveel wijzigingsverzoeken kwamen er binnen, hoeveel daarvan zijn uitgevoerd, en hoeveel liggen er nog? Zulke getallen uit uw eigen beheer zeggen volgens ons meer over uw beheerbehoefte dan een percentage van wat het project ooit kostte.

Wanneer moet u actie ondernemen?

Herkent u hieronder twee of meer signalen, dan verdient het beheer nu aandacht:

→ Afdelingen houden eigen lijsten of spreadsheets bij naast het ERP-systeem, en niemand weet precies welke versie leidend is.

→ De functioneel beheerder is ook de vraagbaak voor het hele systeem, prioriteert de wensen en test de updates.

→ Er is in het afgelopen jaar een update uitgesteld omdat er niemand was om hem te testen.

→ Nieuwe medewerkers leren het systeem door mee te kijken bij een collega, inclusief diens omwegen.

→ De implementatiepartner is na de go-live alleen nog bereikbaar via een ticketportaal, en niemand weet wat er in het supportcontract staat.

→ Het overleg dat de stuurgroep zou opvolgen, is er na de go-live nooit gekomen.

→ U kunt niet zeggen welk doel uit de businesscase het systeem dit jaar dichterbij moet brengen.

Loop in dat geval de beheerscan hierboven met een paar mensen samen door.

Wanneer is een beheerscan juist niet nodig?

Een beheerscan heeft volgens ons weinig toegevoegde waarde als uw systeem nog in de hypercare zit. Is het projectteam dan nog aan boord, dan zeggen de meldingen vooral iets over hoe de go-live verliep. Wacht dan tot de eerste maandafsluiting achter de rug is.

Hij is ook niet nodig als u de scan het afgelopen jaar heeft gedaan, de nee’s een eigenaar hebben gekregen en er sindsdien niets wezenlijks is veranderd in uw organisatie of uw systeem. Herhaal hem dan na de volgende grote update of organisatiewijziging.

En staat de vervanging van het systeem al vast, met een datum en een budget, dan richt u de aandacht beter op een goede uitfasering dan op een beheerorganisatie die over een jaar weer verdwijnt. Daarover schreven wij in Uw oude ERP-systeem na go-live: waarom uitfaseren een bestuurlijk besluit is.

Waarom goed beheer voor ons meer is dan een dienst

Wij vinden dat beheer na de go-live meer over mensen gaat dan over technologie. Het voorbeeld aan het begin van dit artikel laat zien waarom: de functioneel beheerder maakt daar elke dag kleine beslissingen die mede bepalen of haar collega’s het systeem vertrouwen. Ons werk is mensenwerk, en in de beheerfase geldt dat heel letterlijk: het systeem is af, de mensen die ermee werken moeten nog bij elke verandering worden meegenomen.

Daarom kijken wij bij beheer eerst naar wie het draagt, en pas daarna naar wat er technisch moet gebeuren. Een goed ingerichte beheerorganisatie kan de beheerder haar werkweek teruggeven en haar collega’s een systeem waar ze op durven te bouwen.

Dat wij dit advies kunnen geven zonder eigen agenda, heeft een eenvoudige reden. Wij verkopen geen licenties en zijn aan geen enkel platform gebonden, of uw organisatie nu met SAP, Dynamics 365, Exact, Oracle of AFAS werkt. Wij leveren wel beheercapaciteit, en juist daarom zeggen wij het hardop: de procesrol en het besluit over prioriteit horen bij u. Met onze eigen ERP-specialisten kunnen wij een laag tijdelijk of structureel ondersteunen, maar het doel van die ondersteuning is dat uw eigen organisatie het systeem beter in handen krijgt.

Wat u hierna kunt doen

Loop de twaalf vragen van de beheerscan door met uw functioneel beheerder en iemand uit de IT-organisatie. Zet de nee’s op een rij, en kijk per laag of er een eigenaar is met de tijd om er iets aan te doen. Dat gesprek alleen kan al een helderder beeld geven van waar uw beheer staat.

Wilt u de uitkomst laten toetsen, of de scan samen met een onafhankelijke specialist doorlopen? Dan kunt u bij ons een beheerscan op uw eigen situatie aanvragen. Wij lopen de vier lagen door met de mensen die het beheer dragen, met als doel per laag een beeld van wat er goed is belegd, wat een eigenaar mist en wat u zelf kunt oppakken. Wat de beheerscan inhoudt, leest u op onze pagina over ERP-beheer, support en doorontwikkeling.

Alle artikelen over ERP-beheer op een rij

Deze gids is het startpunt voor ons werk over beheer na de go-live. Per onderwerp gaan de volgende artikelen dieper:

• ERP functioneel beheer: intern opbouwen of uitbesteden? Over de procesrol, wat u in huis houdt en wanneer ondersteuning loont.
• ERP-continuïteit en de sleutelpersoon Over kennis die bij één of twee mensen zit, en hoe u haar spreidt.
• ERP-updates testen na go-live Over het ritme van de leverancier en wie een wijziging accepteert die u niet zelf heeft besteld.
• ERP-integraties beheren Over de koppelingen tussen uw systemen en wie ze na de go-live bewaakt.
• ERP-capaciteitsplanning Over de juiste specialist op het juiste moment, ook na de go-live.

Veelgestelde vragen

Wat is ERP-beheer?

ERP-beheer omvat alle rollen, afspraken en middelen die een ERP-systeem na de go-live werkend, veilig en afgestemd op de bedrijfsprocessen houden.

In deze gids delen wij het op in functioneel beheer, applicatiebeheer, technisch beheer en de regie over wat er verandert. Elke laag vraagt volgens ons een eigen eigenaar, ook als een deel van het werk wordt ondersteund door een externe partij.

Wat is het verschil tussen functioneel beheer en applicatiebeheer?

Functioneel beheer zorgt dat het ERP-systeem doet wat de bedrijfsprocessen nodig hebben, en applicatiebeheer zorgt dat inrichting, maatwerk en koppelingen technisch in orde zijn.

De functioneel beheerder spreekt de taal van de afdelingen en beoordeelt wensen. De applicatiebeheerder voert technische wijzigingen uit en houdt ze gedocumenteerd. Doet in uw organisatie één persoon beide, dan blijven het twee verschillende rollen.

Wat kost ERP-beheer per jaar?

ERP-beheer kost per jaar wat uw eigen wijzigingsstroom, updates, maatwerk en key-useruren samen vragen, en laat zich daarom volgens ons niet betrouwbaar uitdrukken als percentage van het project.

Begroot bijvoorbeeld vanuit het afgelopen halfjaar: hoeveel wijzigingen kwamen er binnen, hoeveel zijn uitgevoerd en hoeveel liggen er nog. Een vaste vuistregel noemen wij bewust niet, omdat die uw eigen situatie negeert.

Kunt u ERP-beheer uitbesteden?

U kunt een groot deel van het ERP-beheer laten ondersteunen, maar de procesrol en het besluit over prioriteit horen volgens ons bij uw eigen organisatie.

Denk bij ondersteuning aan technisch beheer, het onderhoud van maatwerk en pieken in functioneel beheer. Neem dat besluit per beheerlaag. Let er bij ondersteuning op dat de opgedane kennis in uw eigen documentatie terechtkomt, en dat de partij die het werk doet niet als enige beoordeelt of het goed is.