Wat consultants echt doen: een realistisch beeld

SAP-consultants configureren, bouwen, testen en stabiliseren SAP voor een bedrijf. In de praktijk leveren ze het grootste deel van hun waarde midden in het programma. Ze maken scope helder die is afgedreven, doen de walkthroughs die niemand deed, triëren UAT-defects en stabiliseren de operatie na de go-live. Functionele consultants zijn verantwoordelijk voor de moduleconfiguratie, technische consultants voor uitbreidingen en integraties, en programma- en veranderconsultants voor oplevering en adoptie. Dit stuk is bedoeld voor leidinggevenden die overwegen externe hulp in te schakelen en voor mensen die consultancy als loopbaan overwegen. Bent u leidinggevende, dan vertelt de tabel met signalen hieronder wanneer u moet bellen. Bent u consultant, dan laten de secties over het dagelijkse werk zien wat de baan echt inhoudt.

De vraag komt elke keer op als iemand externe ondersteuning overweegt: wat doet een consultant precies wat wij zelf niet kunnen?

Het eerlijke antwoord is niet bijzonder vleiend voor de consultancysector. Het grootste deel van de waarde komt van het repareren van dingen die niet hadden mogen breken. Van het stellen van vragen die al gesteld hadden moeten zijn. En van het toevoegen van capaciteit en helderheid op het moment dat het interne team geen van beide meer heeft.

Dat is geen kritiek op interne teams. Zo verlopen SAP-programma's nu eenmaal vaak. Het interne team is overbelast. De systeemintegrator heeft eigen prioriteiten. Besluiten stapelen zich op en de scope drijft af. Zes maanden in een programma van twaalf maanden opent iemand het issuelog en vindt twintig punten met de status “nog op te lossen” die er sinds week drie staan.

Dat is meestal het moment waarop de telefoon gaat.

Sommige consultants worden tijdens de blueprint of planning ingeschakeld. Veel anderen krijgen de oproep midden in het project, vaak na twee of drie maanden trage voortgang of gemiste overdrachten. De rapporten voor de stuurgroep zien oranje. Het team werkt hard. De voortgang is traag en niemand kan precies zeggen waarom.

1. ExploreWorkshops en gapsFit-to-standard-workshops, gaps vastgelegd
2. RealizeBouw en walkthroughsConfiguratie en uitbreidingen. Midden in het project komen de recoveryoproepen meestal
3. DeployUAT-triage en cutoverGat in configuratie, proces of training? De triage beslist
4. HypercareStabilisatieDe eerste maandafsluiting en de wachtrij met issues

De typische momenten waarop consultants binnenkomen:

1. De scope is afgedreven. Wat in Explore is afgetekend, komt niet meer overeen met waar het bouwteam aan werkt. Requirements zijn informeel in workshops toegevoegd, het wijzigingslog is niet bijgehouden en niemand heeft een definitieve scopelijst.
2. Een kritieke workstream is vastgelopen. De datamigratie zit al weken op hetzelfde foutpercentage vast, zonder plan om dat te verbeteren. UAT opent meer defects dan het sluit.
3. De go-live-datum staat vast en het plan ondersteunt die niet. Het bestuur heeft de datum bepaald. Het plan is niet afgestemd op de werkelijke voortgang. De programmamanager weet dat het traject de datum mist maar heeft nog niet geëscaleerd.

In elk van deze gevallen is het werk niet om mensen aan het bestaande plan toe te voegen. Het is kijken naar wat er werkelijk gebeurt, het probleem ronduit benoemen en een weg vooruit uitstippelen. In mijn gids over SAP-projecten weer op koers brengen staat die recoveryvolgorde.

Scope en proces verduidelijken

Soms klopt de configuratie, maar is het proces eromheen kapot. Een veelvoorkomend patroon: het team heeft geconfigureerd op basis van een fit-to-standard-document uit Explore en gebruikers uit de business hebben de configuratie sinds de aftekening niet meer gezien. Er is hun verteld wat er werd gebouwd, het is hun niet getoond.

De oplossing is niet technisch. Het is een gat in het gesprek. Het werk is om gebruikers uit de business vóór UAT door de configuratie te leiden en een duidelijke lijst met wijzigingen op te stellen voordat het testen begint.

Dat is niet glamoureus. Zo ziet het werk eruit.

Vertalen tussen technische teams en de business

SAP-programma's leveren routinematig iets op dat technisch correct is maar dat de business niet kan gebruiken. Een prijsbepaling die in 90% van de gevallen werkt en stukloopt op exportorders. Een goederenbeweging die correct boekt maar een financieel document aanmaakt dat het afstemmingsteam niet herkent.

De functionele consultant dicht dat gat. Niet door de meest technische persoon in de ruimte te zijn. Maar door het systeemgedrag en de impact op de business goed genoeg te begrijpen, zodat de juiste mensen het juiste besluit kunnen nemen.

UAT-ondersteuning

De gebruikersacceptatietest (UAT) is het moment waarop de opgestapelde besluiten van een programma standhouden of uit elkaar vallen. Elke afsnijding in Explore, elke informele scope-uitbreiding en elk testscenario dat op hoofdlijnen is geschreven, komt hier aan de oppervlakte.

Goede UAT-ondersteuning betekent defects correct triëren en gaten in de configuratie scheiden van gaten in het proces en gaten in de training. Het betekent ook de temperatuur bewaken wanneer gebruikers uit de business een reeks mislukkingen meemaken die hun vertrouwen in het hele programma aantast. Zonder dat wordt elk defect in een UAT-sessie een reden om de go-live in twijfel te trekken, meestal omdat de triage zwak was en niemand had gedefinieerd wat “klaar voor go-live” betekende.

Stabilisatie na de go-live

Het minst glamoureuze werk in SAP-consultancy is hypercare. De go-live is gebeurd, de felicitatiemails zijn verstuurd, het implementatieteam begint af te bouwen. Dan komt de eerste maandafsluiting. Boekingen komen niet overeen met het afstemmingsformaat. Productieorders worden afgerond maar niet afgerekend. De helpdesk loopt vol met gebruikers die zijn opgeleid maar niet zijn voorbereid op randgevallen.

Hier wordt een groot deel van de echte waarde geleverd en hier zijn de meeste programma's onderbezet. Het hypercareteam werkt de wachtrij met issues systematisch af, scheidt systemische problemen van eenmalige fouten en herstelt het vertrouwen in het systeem.

De structuur van het werk is niet veranderd. De verdeling van de tijd wel.

Documentatie schrijft zichzelf grotendeels. SAP Joule for Consultants, sinds 2025 algemeen beschikbaar, beantwoordt configuratievragen vanuit de eigen kennisbank van SAP, inclusief SAP Notes, en legt ABAP-code uit. Op Joule gebaseerde assistenten in SAP Cloud ALM stellen requirements en testscenario's op uit workshopmateriaal. De functionele consultant besteedt minder tijd aan het typen van documenten en meer tijd aan het bevragen van workshopconclusies.

Code wordt vaker beoordeeld dan geschreven. De ontwikkelassistenten van SAP stellen code op, waaronder SAP Build Code voor Java- en JavaScript-uitbreidingen op SAP BTP. Technische consultants beoordelen, beveiligen en testen die code nu.

Hypercaredesks krijgen minder routinevragen. Joule kan routinevragen beantwoorden, zoals verlofsaldo's of de status van declaraties, binnen SAP-applicaties, wat een deel van het volume bij de hypercaredesk wegneemt. De tijd van de consultant verschuift naar procesgaten, stamgegevensproblemen en de gevallen die een mens nodig hebben.

Waarom u een consultant inschakelt, is niet veranderd. Consultants die deze tools hebben geleerd, besteden meer tijd aan oordeelsvorming, communicatie en escalatie en minder aan werk dat AI nu naar behoren in concept opstelt. SAP's eigen beschrijving van Joule for Consultants is een eerlijke samenvatting van wat het dekt.

Functionele consultants specialiseren zich in modules zoals FI, CO, SD, MM, PP, EWM of SuccessFactors. Ze configureren het systeem rond bedrijfsprocessen en dichten het gat tussen de standaard van SAP en de requirements van de klant. Hun waarde is modulediepte plus kennis van bedrijfsprocessen.

Technische consultants (ABAP-ontwikkelaars, SAP BTP-specialisten, integratiearchitecten, Basis) bouwen de uitbreidingen en integraties die configuratie niet kan dekken. Bij moderne S/4HANA-programma's duwen clean-core-principes nieuwe uitbreidingen richting SAP BTP of vrijgegeven API's, wat een andere vaardighedenset vraagt dan klassieke ABAP-modificaties.

Project- en programmamanagers zorgen voor structuur in de uitvoering: governance, risico, planning en het oplossen van issues, met zicht op het hele programma, zodat problemen worden geëscaleerd voordat ze crises worden.

Verandermanagementconsultants werken aan de mensenkant: training, communicatie, betrokkenheid en de governance die bepaalt of gebruikers het systeem overnemen of eromheen werken.

De meeste grote SAP-programma's hebben alle vier nodig. Programma's in het middensegment hebben vaak minder mensen die meerdere rollen afdekken, en daar ontstaan de gaten. De consultancyframeworks en de vaardigheden die ertoe doen in consultancy zijn voor alle vier dezelfde. Zet u als consultant uw eigen route uit door deze rollen, dan beschrijft SAPopedia loopbaanpaden en cursussen, en helpt ERPCV u die ervaring te presenteren aan recruiters.

De duurste consultancyfout is iemand te laat inschakelen. Een risicoreview vóór de cutover, vier tot zes weken voor de go-live, kan kritieke problemen vinden zolang er nog tijd is. Een recoverytraject na een mislukte cutover kost veel meer. Bovendien vindt dat plaats onder operationele druk, in een organisatie die het vertrouwen in het systeem is kwijtgeraakt.

De tabel toont de signalen en de hulp waar elk signaal om vraagt.

Signaal	Wat het meestal betekent	Hulp om in te schakelen	Wat zij in twee weken moeten opleveren
Issuelogpunten die langer dan vier weken openstaan zonder oplossingsdatum	Een governanceprobleem, geen technisch probleem	Onafhankelijk programmaadviseur	Een besluitenlijst met eigenaren en data
Go-live binnen 60 dagen en geen cutover-repetitie	Een niet-geteste cutover; verrassingen bij de go-live zijn niet in real time te herstellen	Cutover- of programmalead	Een gerepeteerd cutoverplan en go/no-go-criteria
Business owners komen niet meer opdagen	UAT mislukt zonder bewuste interventie	Change lead plus een functionele lead	Walkthroughs met key users en een plan om hen weer te betrekken
Eén workstream zit wekenlang op hetzelfde foutpercentage vast	Grondoorzaak niet gevonden	Specialist in die workstream	Een grondoorzaakanalyse en een herstelplan
De rapportage van de SI is het enige zicht op de gezondheid van het programma	Geen onafhankelijke controle	Adviseur aan de kant van de klant	Een eerlijke gezondheidscheck voor de sponsor

Wat doen SAP-consultants echt in een project?

Ze analyseren business requirements, configureren SAP om die te ondersteunen en dichten het gat tussen de standaardinstellingen van SAP en wat de business nodig heeft. In Explore leiden ze fit-to-standard-workshops en leggen ze gaps vast. In Realize bouwen ze configuratie en werken ze met ontwikkelaars aan uitbreidingen. In Deploy ondersteunen ze UAT, beheren ze defects en bereiden ze de cutover voor. In de hypercare lossen ze issues na de go-live op. Wat in functieomschrijvingen ontbreekt, is het triëren van de gaten tussen fasen en het bewaken van de uitvoeringsdiscipline onder druk.

Wanneer heeft een organisatie echt een consultant nodig?

Drie situaties dekken de meeste opdrachten. Programmarecovery, wanneer de scope is afgedreven, een workstream is vastgelopen of de go-live-datum gevaar loopt. Specialistische capaciteit, wanneer het team een module of technische vaardigheid mist, zoals PP-PI-configuratie of integratie op SAP BTP. En governance, wanneer de organisatie onafhankelijk toezicht wil op een programma dat door een systeemintegrator wordt uitgevoerd. Wachten tot het slechter gaat voordat u belt, is het meest voorkomende patroon en het duurste.

Wat is het verschil tussen een functionele en een technische SAP-consultant?

Functionele consultants configureren SAP om bedrijfsprocessen te ondersteunen in modules zoals FI/CO, SD, MM, PP of EWM en werken rechtstreeks met gebruikers uit de business aan requirements. Technische consultants bouwen wat configuratie niet kan: ABAP- en BTP-uitbreidingen, integraties en systeembeheer via Basis. Clean-core-principes verschuiven technisch werk van ABAP-modificaties in het systeem naar BTP-uitbreidingen en vrijgegeven API's.

Hoe weet u of een consultant waarde toevoegt?

Drie indicatoren. Ze brengen aannames aan het licht die nooit zijn getest en besluiten die zijn uitgesteld, in plaats van bestaande meningen te bevestigen. Besluiten die wekenlang vastzaten, worden weer genomen. En het issuelog wordt korter doordat grondoorzaken worden aangepakt, niet doordat punten zonder oplossing worden gesloten. Een log dat ondanks alle activiteit even lang blijft, betekent dat de problemen systemisch zijn of dat de oplossingen de oorzaak niet bereiken.

Wat is het moeilijkste aan consultancywerk?

Problemen benoemen die de klant al kent maar waar hij niets mee heeft gedaan: de afgedreven scope, de niet-geschreven testscenario's, de sponsor die zich terugtrok. Daarvoor is genoeg vertrouwen nodig om gehoord te worden, genoeg geloofwaardigheid om geloofd te worden en genoeg directheid om vervelende dingen te zeggen. Consultants die de relatie beschermen ten koste van de diagnose zijn dure instemming.

Waarom een onafhankelijke consultant inhuren als de klant al een SI heeft?

De systeemintegrator is verantwoordelijk voor het opleveren van de gecontracteerde scope. Een onafhankelijke consultant is tegenover de klant verantwoordelijk voor het resultaat. Dat zijn verschillende taken. De adviseur aan de kant van de klant bevraagt ontwerpaannames en valideert of het ontwerp aan de behoeften van de business voldoet. Die beschermt de commerciële positie van de klant in het wijzigingsbeheer en geeft het management een beeld van de gezondheid van het programma dat niet is gefilterd door de rapportage van de integrator. Dat is een structureel belangenconflict, geen kritiek op integratoren.