SAP-werkomschrijving (SOW): wat erin moet staan

Een SAP-werkomschrijving (statement of work, SOW) is het contractdocument dat zegt wat de partner levert, met welke inspanning, door wie en hoe dat kan veranderen. Ze moet de scope dekken, gedetailleerde aannames en uitsluitingen, inspanning per fase en rol, deliverables met acceptatiecriteria, resources met naam en wijzigingsbeheer.

De meeste SOW's beschrijven de scope redelijk. Wat klanten vaak weglaten, zijn gedetailleerde aannames en uitsluitingen, en dat is het onderdeel dat bepaalt wat u uiteindelijk betaalt.

Dit artikel is een onderdeel van mijn gids over hoe u een SAP-implementatiepartner kiest. De SOW is de laatste stap van dat proces, na de RFP voor een SAP-partner en de presentaties. Voor een uitgewerkt voorbeeld van een SOW-review vóór ondertekening leest u mijn casestudy over onderhandelen over een ERP-contract.

Een goede SAP-SOW leest als een bedieningshandleiding voor het programma. Iedereen aan uw kant moet haar kunnen openen en drie vragen kunnen beantwoorden: wat krijgen we, waarvan hangt het af, en wat gebeurt er als er iets verandert.

Dit zijn de onderdelen die ze nodig heeft, en wat er misgaat als er een ontbreekt:

Onderdeel	Wat erin moet staan	Wat er gebeurt als het mager is
Scope	Processen, modules, bedrijfscodes, vestigingen, landen en gebruikers binnen de scope	Elke workshop opent opnieuw de vraag wat erin zat
Aannames	De voorwaarden waarvan de prijs afhangt, elk met een gevolg als ze niet kloppen	De partner dient wijzigingsverzoeken in die u niet kunt aanvechten
Uitsluitingen	Wat de partner niet doet, en wie het in plaats daarvan doet	Werk valt tussen u en de partner in, en niemand is er eigenaar van
Aanpak en fasen	De methode, het faseplan en de kwaliteitspoorten	Geen afgesproken punt waarop een fase klaar is
Inspanning	Geschatte inspanning per fase en rol	U kunt niet zien of het verbruik volgens plan loopt
Deliverables en acceptatie	Benoemde documenten en resultaten, acceptatiecriteria, goedkeuringstermijn	Facturen worden betaald voor half werk
Resources	Sleutelpersonen met naam, rollen, inzet en vervangingsregels	Het team dat u bij de presentaties zag, is niet het team op locatie
Verantwoordelijkheden van de klant	Wat uw mensen moeten aanleveren, en wanneer	Vertragingen aan uw kant worden wijzigingsverzoeken van de partner
Wijzigingsbeheer	Hoe een wijziging wordt ingediend, beoordeeld, geprijsd en goedgekeurd	Wijzigingsverzoeken worden een tweede inkomstenbron
Governance	Stuurgroep, rapportage, escalatie	Problemen komen laat boven, als ze duur zijn

Schrijf de scope zelf op voordat u om prijzen vraagt, zodat partners uw scope prijzen en niet die van henzelf.

Dit is het onderdeel dat klanten vaak weglaten. Zonder dit onderdeel rust de prijs op voorwaarden die niemand aan uw kant heeft gelezen of goedgekeurd.

Een aanname is een voorwaarde waarop de partner zijn prijs heeft gebaseerd. Een uitsluiting is werk dat de partner helemaal niet heeft geprijsd. Beide moeten zo specifiek zijn dat een derde kan nagaan of ze standhielden.

Soorten aannames om op te schrijven

Elke aanname heeft een gevolg nodig. „Als dit niet klopt, gaat de wijziging via wijzigingsbeheer met een impactanalyse” maakt van een aanname geen versiering meer, maar een beheersmaatregel.

Dit zijn de categorieën die een SAP-SOW moet dekken:

1. Organisatorische scope. Het aantal bedrijfscodes, vestigingen, verkooporganisaties, landen en juridische entiteiten dat de prijs dekt.
2. Processcope. De bedrijfsprocessen binnen de scope, met naam, en de SAP-standaardprocessen die de partner verwacht dat u overneemt.
3. WRICEF-volume. Het aantal workflows, rapporten, interfaces, conversies, uitbreidingen en formulieren, per complexiteit. Budgetten worden geraakt in de Explore-fase terwijl deze lijst groeit, dus het uitgangsaantal hoort in het contract.
4. Data. De dataobjecten die gemigreerd worden, de hoeveelheid historie, het aantal proefladingen, en wie de data opschoont.
5. Integraties. Elke interface met naam, met het systeem aan de andere kant en wie dat systeem aanpast.
6. Testen. Het aantal testcycli, wie de scripts schrijft, wie ze uitvoert en wie de defecten oplost.
7. Beschikbaarheid van de klant. Welke van uw mensen nodig zijn, voor welk deel van hun tijd, en hoe snel beslissingen genomen moeten worden.
8. Omgevingen en licenties. Wie systemen, tools en toegang levert, en wanneer.
9. Locatie en taal. Waar het team werkt, de verhouding onshore en offshore, reizen, en de talen voor documenten en training.
10. Training en hypercare. Het trainingsmodel, het aantal op te leiden trainers, en de duur en exitcriteria van hypercare.

Het WRICEF-uitgangsaantal doet er voor het budget het meest toe. Het eigen cursusmateriaal van SAP beschrijft de Explore-fase als een fit-to-standard-analyse, waarin goedgekeurde deltavereisten aan de productbacklog voor de Realize-fase worden toegevoegd (SAP Learning). Elke goedgekeurde delta kan nieuwe WRICEF-inspanning worden, dus u heeft het startaantal nodig om de groei aan af te meten.

Soorten uitsluitingen om op te schrijven

Uitsluitingen moeten noemen wie het werk in plaats daarvan doet. „Uitgesloten” zonder eigenaar is een gat dat tijdens de cutover gevonden wordt.

Dit zijn de gebruikelijke categorieën:

1. Opschonen en verrijken van data in de legacysystemen, vaak een taak van de klant.
2. Wijzigingen in systemen van derden en legacysystemen aan de andere kant van een interface.
3. Softwarelicenties en abonnementen, die in uw contract met SAP zitten, niet in de SOW.
4. Infrastructuur en hosting, tenzij de partner die uitdrukkelijk beheert.
5. Het geven van eindgebruikerstrainingen, als de partner alleen uw trainers opleidt.
6. Organisatorisch verandermanagement buiten wat is opgesomd.
7. Ontwerp van beveiliging, rollen en autorisaties, als een andere partij daar eigenaar van is.
8. Performance-, penetratie- en regressietesten buiten de benoemde cycli.
9. Landen, entiteiten of lokalisaties die niet in de organisatorische scope staan.
10. Applicatieondersteuning na hypercare, wat een apart contract is.

Lees de twee lijsten naast elkaar door met uw programmadirecteur. Alles wat in geen van beide lijsten staat, is de plek waar een wijzigingsverzoek vandaan komt.

Het commerciële model dat ik voor een SAP-implementatie aanbeveel, is nacalculatie (time and materials), met de inspanning gekwantificeerd. Dat betekent dat de geschatte inspanning per fase en per rol in het contract staat, zodat u de werkelijke inspanning er elke maand mee kunt vergelijken.

Een vaste prijs ziet er voor een raad van bestuur veiliger uit. In de praktijk ligt de prijs alleen vast zolang elke aanname standhoudt, en een SAP-programma toetst de meeste daarvan vóór het eind van Explore. Mijn aantekeningen over de kosten van een SAP-implementatie behandelen wanneer een fase met een vaste prijs toch zinvol kan zijn.

Zo verhouden de twee modellen zich in de SOW:

Vergelijkingspunt	Vaste prijs	Nacalculatie met gekwantificeerde inspanning
Wat het contract vastlegt	De prijs, zolang de aannames standhouden	De tarieven, en de geschatte inspanning per fase en rol
Waar het risico ligt	De partner prijst het in als onvoorzien	Bij u, maar elke maand zichtbaar
Als de scope verschuift	Elke wijziging wordt een onderhandeling	De inspanning verschuift, en u ziet het naast de schatting
Wat u kunt volgen	Mijlpalen en wijzigingsverzoeken	Werkelijke inspanning tegenover het plan, per fase en rol
Wat u beschermt	Strakke aannames en uitsluitingen	Strakke aannames, uitsluitingen en rapportage over de inspanning

Gekwantificeerde inspanning maakt van nacalculatie geen blanco cheque meer, maar een beheerst budget. Vraag om de schatting als tabel van fasen tegen rollen, in mensdagen, en maak maandelijkse rapportage tegen die tabel een contractuele verplichting.

Laat de tarieven zich niet verstoppen in de inspanning. Controleer de rolverdeling tegen markttarieven met mijn gids over de planning van resources voor SAP-projecten.

Een plan met veel seniordagen aan het begin en juniordagen later is gebruikelijk. Het omgekeerde vraagt om uitleg.

Een deliverable is een benoemd resultaat met een definitie van gereed. „Ondersteuning bij het ontwerp” is geen deliverable. Een getekend solution-designdocument voor record to report, beoordeeld aan de hand van afgesproken criteria, is dat wel.

Koppel acceptatie aan kwaliteitspoorten

SAP Activate loopt in zes fasen: Discover, Prepare, Explore, Realize, Deploy en Run. SAP beschrijft formele kwaliteitspoorten na elke fase, die controleren of de deliverables van de fase volledig zijn voordat het project verdergaat (SAP Learning).

Gebruik die poorten in de SOW. Zet per poort de verwachte deliverables op een rij, de acceptatiecriteria en het aantal dagen dat u heeft voor de beoordeling. Koppel betaling aan geaccepteerde deliverables, niet aan de kalender.

Iemand aan uw kant moet die documenten kunnen beoordelen. Dit is een van de drie momenten waarop ik aanraad een onafhankelijke consultant in te schakelen: tijdens de contractering, voor het ontwerp, en voor de beoordeling van de deliverables van de partner. Mijn artikel over SAP-partner of onafhankelijke consultant legt uit hoe de twee rollen samenwerken.

Noem de mensen, en controleer ze

Zwakke kwaliteit van de voorgestelde resources is een van de twee dingen die mij laten afhaken bij een inschrijving. Het andere is een partner die de architectuur en het plan niet kan uitleggen.

De SOW moet de solution architect, de programmamanager en elke functionele en technische lead bij naam noemen. Leg hun inzet vast, uw recht om vervangers te interviewen, en uw goedkeuring voor elke vervanging. De casestudy over onderhandelen over een ERP-contract laat de clausule over resources met naam in de praktijk zien.

Controleer certificeringen in plaats van een cv op zijn woord te geloven. SAP geeft certificeringsbadges uit via Credly, dat realtime verificatie ondersteunt (SAP Learning). Onder het stay-certified-proces van SAP vervalt een certificering als de houder de verplichte toets mist (SAP Learning).

Deze clausule doet er meer toe dan ze lijkt. Ik heb tijdens een programma een partner vervangen, en de aanleiding was dat de partner geen goede resources kon leveren. Mijn gids over het halverwege wisselen van een SAP-partner behandelt wat u veiligstelt voordat het zover komt.

Wijzigingsbeheer is waar een magere SOW duur wordt. Zijn de aannames vaag, dan kan bijna alles als wijziging worden bestempeld.

Een werkbaar hoofdstuk over wijzigingsbeheer heeft deze elementen nodig:

1. Een aanleiding. Een wijziging bestaat alleen als een aanname niet klopt, een uitsluiting binnen de scope wordt gebracht of u om iets nieuws vraagt.
2. Een impactanalyse. Scope, inspanning per rol, planning en kosten, schriftelijk, voordat het werk begint.
3. Een tariefkaart. Wijzigingen worden geprijsd tegen contracttarieven, zonder spoedtoeslag tenzij afgesproken.
4. Een goedkeuringsniveau. Wie aan uw kant wijzigingen tot welk bedrag mag goedkeuren, met de CFO boven een vastgestelde drempel.
5. Een logboek. Elke wijziging, goedgekeurd of afgewezen, gerapporteerd aan de stuurgroep met het lopende totaal.
6. Een koppeling aan de nulmeting. Nieuwe WRICEF-objecten worden afgezet tegen het aantal in de aannames.

De partner zal terechte wijzigingen indienen. SAP-programma's ontdekken dingen die bij de contractondertekening niemand wist. Het doel is dat elke wijziging zichtbaar, geprijsd en goedgekeurd is voordat iemand het geld uitgeeft.

In de 21 SAP-programma's die ik heb geleid of gered, is de grootste fout die ik zie dat er aan het begin niet goed wordt gepland. De SOW is waar die planning bindend wordt, en de tijd die u eraan besteedt, is goedkoop naast betwiste wijzigingsverzoeken.

De concrete volgende stap: neem de SOW die voor u ligt en zet elke aanname en uitsluiting op één pagina. Schrijf naast elke regel wat er gebeurt als die niet klopt en wie betaalt. Kunt u die kolom niet invullen, dan is de SOW niet klaar om te tekenen.

Wilt u een onafhankelijke beoordeling van een SAP-werkomschrijving vóór ondertekening, dan help ik klanten daarbij tijdens de contractering. U kunt hier contact met mij opnemen.

Wat moet er in een SAP-werkomschrijving staan?

Scope, gedetailleerde aannames, uitsluitingen, aanpak en fasen, geschatte inspanning per fase en rol, deliverables met acceptatiecriteria, resources met naam, verantwoordelijkheden van de klant, wijzigingsbeheer en governance. Het deel dat het vaakst mager blijft, zijn de aannames en uitsluitingen, en dat is het deel dat de eindkosten bepaalt.

Wat is het verschil tussen aannames en uitsluitingen in een SAP-SOW?

Een aanname is een voorwaarde waarop de partner zijn prijs heeft gebaseerd, zoals het aantal bedrijfscodes of WRICEF-objecten. Een uitsluiting is werk dat de partner helemaal niet heeft geprijsd, zoals het opschonen van legacydata. Elke aanname moet zeggen wat er gebeurt als ze niet klopt, en elke uitsluiting moet noemen wie het werk in plaats daarvan doet.

Is een vaste prijs of nacalculatie beter voor een SAP-implementatie?

Ik raad nacalculatie aan met de inspanning gekwantificeerd: de geschatte inspanning per fase en rol in het contract, en maandelijks gevolgd. Een vaste prijs houdt alleen stand zolang elke aanname standhoudt, en een SAP-programma toetst de meeste aannames tijdens de Explore-fase.

Hoe stelt u acceptatiecriteria op voor SAP-deliverables?

Benoem elke deliverable, beschrijf hoe volledig eruitziet en stel een beoordelingstermijn voor uw team vast. Koppel ze aan de kwaliteitspoorten van SAP Activate aan het eind van elke fase, en geef betaling pas vrij als de deliverable is geaccepteerd.

Moet de SAP-SOW de consultants bij naam noemen?

Ja, voor de sleutelrollen: solution architect, programmamanager en de functionele en technische leads. Voeg hun inzet toe, uw recht om vervangers te interviewen en uw goedkeuring voor elke vervanging. Verifieer certificeringen via de SAP-badges op Credly in plaats van op het cv te vertrouwen.

Wie moet de SAP-werkomschrijving schrijven?

De partner stelt haar op, maar de scope en de aannames moeten van u komen. Schrijf uw scope op voordat u de markt opgaat, en laat iemand die onafhankelijk is van de partner de aannames, uitsluitingen en deliverables beoordelen vóór ondertekening.