SAP-scopetemplate voor projecten: wat u vastlegt en uitsluit

Een SAP-scopetemplate voor projecten legt vast wat het programma oplevert, wat het bewust niet oplevert, wie elk onderdeel in handen heeft en hoe de scope kan veranderen. De negen onderdelen hieronder dekken dat af. De twee die het zwaarst wegen, zijn de twee die teams overslaan: expliciete uitsluitingen en de scope van de datamigratie. Vul de template in voordat de configuratie begint en laat hem ondertekenen door de sponsor en de procesowners.

Soms vullen teams een scopetemplate in en gaan ze door. Dat deel voelt makkelijk. Weken later, tijdens het ontwerp of de bouw, wijst iemand op een proces dat “verondersteld werd binnen de scope te vallen”. Het gesprek wordt ongemakkelijk. Niemand heeft het opgeschreven. Niemand wilde het weglaten. Ik heb dit te vaak gezien. Een paar ongecontroleerde aannames aan het begin brengen het project ongemerkt weken uit koers.

De taak van het scopedocument is niet om vast te leggen wat mensen in de vergaderruimte hebben gezegd. Het moet helderheid afdwingen voordat de configuratie aannames vastzet die duur zijn om terug te draaien.

Dit zijn de negen onderdelen, met wat elk onderdeel moet beantwoorden.

1. Doelstellingen

Waarom wordt dit werk gedaan, en wat ziet de business als het klaar is? Koppel elke doelstelling aan een meetbaar resultaat: de maandafsluiting met drie dagen verkorten, handmatige afstemmingen over drie entiteiten wegnemen, één beeld van de voorraad over alle vestigingen. Vage doelstellingen leveren vage succescriteria op, en het meningsverschil komt boven tijdens de gebruikersacceptatietest (UAT).

2. Scopedefinitie

Modules, juridische entiteiten, vestigingen, landen, talen, integraties en het deploymentmodel. Wees specifiek. “Finance” is geen scope. “Financiële boekhouding en controlling (FI/CO), met crediteuren, debiteuren, grootboek en kostenplaatsenboekhouding voor de juridische entiteit in de VAE op S/4HANA Cloud Private Edition” is scope.

3. Uitsluitingen

Hier schiet de meeste scopetemplate tekort. Als iets niet als uitgesloten is vastgelegd, gaat iemand ervan uit dat het erbij hoort. Uitsluitingen die u bij naam opschrijft:

1. Landen of entiteiten die naar een latere fase zijn uitgesteld.
2. Legacy-integraties die voorlopig ongewijzigd blijven.
3. Historische gegevens van vóór een vastgestelde afkapdatum.
4. Rapporten die naar een verbeterlijst voor na de go-live zijn verplaatst.
5. Wettelijke eisen die zijn uitgesteld in afwachting van juridische bevestiging.

Geef elke uitsluiting de fase waarnaar ze verschuift, als die er is. Een ondertekende uitsluiting maakt van een discussie van twee weken een kort gesprek.

4. Scope van de datamigratie

Een steeds terugkerende blinde vlek. Beantwoord drie vragen schriftelijk:

1. Wat verhuist er? Alleen openstaande posten, of ook historie? Alle klanten en leveranciers, of alleen de actieve? Materialen voor elke vestiging, of alleen voor de entiteiten die live gaan?
2. Wat zijn de afkapregels? De peildatum voor openstaande inkoop-, verkoop- en werkorders, en wat er gebeurt met lopende zaken bij de cutover.
3. Wat wordt in plaats daarvan gearchiveerd? Wettelijke bewaartermijnen voor historie, en hoe lang het legacysysteem leesbaar blijft.

Aannames die hier ongedocumenteerd blijven, worden tijdens de bouw geschillen. Mijn artikel over waarom SAP-datamigratie mislukt behandelt de planning uitgebreid.

5. Non-functionele scope

Deze vallen tijdens de planning weg en duiken laat in de testfase op als blokkades. Neem ze op in de scope:

1. Beschikbaarheid en het onderhoudsvenster. Verwijs onder RISE naar de beschikbaarheidsvoorwaarden in uw contract.
2. Prestaties bij piekbelasting, zoals de maandafsluiting.
3. Audit logging: welke transacties, en hoe lang logs worden bewaard.
4. Beveiliging en toegangsbeheer per rol.
5. Latentie van rapportages: realtime, bijna realtime of dagelijks.

Het zijn geen functies. Het zijn randvoorwaarden waaraan het systeem moet voldoen. Als ze niet in de scope staan, ontwerpt niemand ervoor.

6. Rollen en verantwoordelijkheden

Elke workstream heeft een consultant als lead nodig en een businesscounterpart met beslissingsbevoegdheid, beiden met naam. De leemte die ik het vaakst zie, is het eigenaarschap van de UAT: wie kan goedkeuren dat een proces is getest en geaccepteerd? Beslis dat voordat de bouw begint, niet twee weken voor de go-live.

7. Wijzigingsbeheer

Niet “wijzigingen vereisen formele goedkeuring”. Een concreet proces: wat een wijzigingsverzoek in gang zet, wie de impact op tijd en budget beoordeelt, wie goedkeurt en wat er wordt vastgelegd. Zonder dat proces wordt “kunnen we dit erbij nemen?” al snel “we dachten dat dit erbij hoorde”, en daarna een verlenging van drie weken die niemand had gepland.

8. Regels voor uitbreidingen

Hoe maatwerkontwikkeling wordt goedgekeurd. SAP deelt uitbreidingen nu in van niveau A, uitsluitend vrijgegeven API's, tot niveau D, aanpassingen aan de core (SAP News, augustus 2025). Op Public Edition onder GROW staat het systeem alleen vrijgegeven interfaces toe. Op Private Edition onder RISE en on-premise kan de core nog altijd worden aangepast, dus de scope moet het doelniveau vermelden en wie uitzonderingen goedkeurt. Mijn clean core-gids legt de niveaus uit.

9. Aannames en beperkingen

Som de aannames achter de scope op, zodat iemand ze moet controleren. Daarna de beperkingen: wettelijke deadlines die een go-livedatum vastleggen, budgetplafonds, mensen die maar deeltijds beschikbaar zijn en uitfaseringsdata van legacysystemen.

Maatwerk is de vorm van scope creep die het langst nodig heeft om zichtbaar te worden. Eén goedgekeurd maatwerkrapport wordt er vijf. Eén uitzondering op een workflow wordt het precedent voor elk verzoek daarna.

Classificeer elk verzoek voordat u iets goedkeurt:

Categorie	Toets	Wat te doen
Essentieel	Het proces kan juridisch of operationeel niet werken zonder	Goedkeuren, met de goedkoopste uitbreiding die upgradebestendig is
Belangrijk, niet kritiek	Verhoogt de efficiëntie maar is geen showstopper	Alleen goedkeuren met een heldere kosten-batenafweging
Onnodig	Een voorkeur, of een kopie van hoe het legacysysteem werkte	Betwisten, daarna afwijzen of uitstellen

De meeste onnodige maatwerkaanpassingen bestaan omdat iemand zijn manier van werken niet wilde veranderen, niet omdat SAP het proces niet kon ondersteunen. En de bouwkosten zijn pas het begin. Elk maatwerkobject brengt test-, opleidings-, documentatie- en upgradewerk met zich mee zolang het bestaat.

Stel een change freeze in. Kies een datum, doorgaans vier tot zes weken voor de go-live, waarna er geen nieuwe verzoeken meer worden aangenomen voor de release. Alles wat later komt, gaat naar de backlog voor na de go-live. De freeze heeft de handtekening van de stuurgroep nodig. Een datum die alleen de projectmanager afkondigt, wordt ter zijde geschoven zodra een afdelingshoofd aandringt.

1. 01Verzoek ingediendWat als wijziging telt, is vooraf gedefinieerd
2. 02GeclassificeerdEssentieel, belangrijk of onnodig
3. 03Impact beoordeeldTijd en budget, door een benoemde beoordelaar
4. 04BesluitEen benoemde goedkeurder keurt goed, wijst af of stelt uit
5. 05Scopeversie bijgewerktNieuw versienummer en een lijst van wat er is gewijzigd

Na de change freeze gaan nieuwe verzoeken naar de backlog voor na de go-live

Bij analytics lopen scopegesprekken hoog op. Iedereen wil rapporten en niemand zegt hoeveel.

Spreek tijdens het ontwerp een vaste rapportlijst af. Vraag mensen wat ze nodig hebben, niet wat ze misschien willen. Markeer elk rapport als standaard SAP-uitvoer of maatwerk, en laat de lijst samen met de rest van de scope ondertekenen. Standaardrapporten kosten een fractie van maatwerkrapporten. Bepaal tegelijk de databronnen van elk rapport; een rapport dat uit drie systemen put, is een integratie-eis. Als dashboards en planning binnen de scope vallen, behandelt mijn SAP Analytics Cloud-gids wat u eerst moet regelen.

Fout	Gevolg	Zo voorkomt u het
Doelstellingen niet meetbaar	Discussies in de UAT over wat “werkend” betekent	Stel aan het begin meetbare resultaten vast
Uitsluitingen niet vastgelegd	Werk wordt zonder goedkeuring opgevangen	Som op wat buiten de scope valt, bij naam
Scope datamigratie vaag	Verkeerde volumes, uitgestelde cutover, herwerk	Leg vast wat verhuist, de afkapmomenten en de archivering
Non-functionele eisen ontbreken	Audit- en prestatieproblemen bij de go-live	Neem beschikbaarheid, prestaties, logging en beveiliging op in de scope
Geen benoemde UAT-eigenaren	Testen sleept voort, niemand kan goedkeuren	Benoem personen met bevoegdheid
Geen wijzigingsbeheer	Informele toevoegingen, ingekorte tests	Neem het wijzigingsproces op in de scope
Geen ondertekening	Scope wordt later aangevochten zonder verantwoording	Sponsor en procesowners tekenen
Analytics voor later bewaard	Rapportverzoeken twee weken voor de go-live	Spreek de rapportlijst af tijdens het ontwerp
Deploymentmodel of regels voor uitbreidingen open	De discussie loopt door in de bouwfase	Besluit over beide voordat de scope wordt ondertekend

Beoordeel de scope bij elke fasepoort van SAP Activate en na elke goedgekeurde wijziging, met een versienummer en een lijst van wat er is gewijzigd. De scope hoort bij verwijzing in het projectcharter, zodat beide documenten hetzelfde verhaal vertellen.

Wat moet een SAP-scopetemplate voor projecten bevatten?

Negen onderdelen: doelstellingen met meetbare resultaten, scopedefinitie (modules, entiteiten, landen, integraties, deploymentmodel), expliciete uitsluitingen, scope van de datamigratie, non-functionele eisen, benoemde rollen, wijzigingsbeheer, regels voor uitbreidingen en aannames met beperkingen. Uitsluitingen zijn het onderdeel dat het vaakst ontbreekt.

Hoe voorkomt u scope creep in SAP-projecten?

Leg uitsluitingen expliciet vast, laat elke wijziging via een formeel verzoek lopen met een impactbeoordeling en een benoemde goedkeurder, classificeer maatwerk voordat u het goedkeurt en stel vier tot zes weken voor de go-live een ondertekende change freeze in. Het doel is niet om alle verandering te weigeren. Het doel is om verandering zichtbaar, beoordeeld en geautoriseerd te maken.

Wat is de scope van de datamigratie in een SAP-project?

De definitie van welke data naar SAP verhuist en onder welke regels: welke objecten (klanten, leveranciers, materialen, openstaande orders, historie), de afkapdata en wat in plaats van migreren wordt gearchiveerd. Ze bepaalt de inspanning en de doorlooptijd, en ze bepaalt hoe lang legacysystemen toegankelijk moeten blijven.

Wat is non-functionele scope in SAP-projecten?

De randvoorwaarden waaraan het systeem moet voldoen, in tegenstelling tot de processen die het ondersteunt: beschikbaarheid, prestaties bij piekbelasting, audit logging, beveiliging en toegangsbeheer, en latentie van rapportages. Ze blijven vaak buiten de scope en worden dan pas in de testfase ontdekt. In gereguleerde sectoren is audit logging een wettelijke verplichting.

Hoe moet maatwerk in de scope worden behandeld?

Classificeer elk verzoek als essentieel, belangrijk of onnodig. Leg bij elk goedgekeurd verzoek vast wat de eis is, waarom standaard SAP er niet aan voldoet, de inspanning, de impact op het testen, de onderhoudskosten en de uitbreidingsaanpak. Vermeld bij Private Edition en on-premise het beoogde clean core-niveau en wie uitzonderingen goedkeurt.

Wanneer moet de scope van een SAP-project worden herzien?

Bij elke fasepoort van SAP Activate, na elk goedgekeurd wijzigingsverzoek en telkens wanneer budget, capaciteit of planning verandert. Bewaar elke versie met een datum, een versienummer en een samenvatting van wat er is gewijzigd. Die geschiedenis beschermt het team wanneer de scope later wordt aangevochten.