SAP-implementatie of uitrol: de verschillen en wanneer wat past

Een SAP-implementatie bouwt het systeem op waar er nog geen is. Een uitrol neemt een SAP-systeem dat al ergens in de groep draait en breidt het uit naar een nieuw land, een nieuwe entiteit of een nieuwe bedrijfseenheid. De meeste mensen gaan ervan uit dat een uitrol gewoon een kleinere implementatie is. Die aanname veroorzaakt op deze programma's meer herwerk dan welke technische beslissing ook.

Ik heb ooit een CFO in de waan gelaten dat een regionale SAP-uitrol plug-and-play zou zijn. Ik legde de risico's uit, maar drong niet aan. We werkten met een globale template en hij ging ervan uit dat elke locatie zonder veel moeite in het gareel zou lopen. Zo werkte het niet. Eén regio had extra belastingafhandeling nodig. Een andere kende verplichte velden voor personeelsgegevens vanwege lokale wetgeving. Wat op kopiëren en plakken leek, vroeg om echt maatwerk.

De keuze bepaalt dus hoe u bemenst, begroot en het werk aanstuurt. Kiest u verkeerd, dan gaat het systeem misschien nog wel live, alleen niet zoals u had gepland.

Een implementatie begint bij nul. U bepaalt de scope, brengt processen in kaart, configureert, migreert data en bouwt koppelingen. Ze past wanneer een organisatie nog geen SAP heeft, of een verouderd systeem volledig vervangt.

Een uitrol hergebruikt een ontwerp dat al werkt: processen, configuratie, standaarden voor stamgegevens. Het werk zit in het gat tussen die template en wat de nieuwe locatie nodig heeft. Belastingen, wettelijke rapportage, valuta, talen, lokale koppelingen en de mensen die ermee gaan werken.

1. 05Lokale gebruikersTraining afgestemd op het lokale proces, in de lokale taal
2. 04Lokale koppelingenBanken, belastingaangifte en logistieke systemen in het nieuwe land
3. 03Lokale dataKlant-, leveranciers- en materiaalgegevens afgestemd op de globale standaarden
4. 02Lokale vereistenBelasting, wettelijke rapportage en verplichte velden. Alleen vereisten, geen voorkeuren
5. 01Globale templateProcessen, configuratie en standaarden voor stamgegevens die al werken

Zo verhouden de twee zich in de praktijk tot elkaar:

Onderdeel	SAP-implementatie	SAP-uitrol
Uitgangspunt	Geen SAP, of een verouderd systeem dat wordt vervangen	SAP draait al op het hoofdkantoor of bij een andere entiteit
Ontwerp	Nieuw ontwerp, fit-to-standard	Globale template met beheerste lokale afwijkingen
Gebruikelijke doorlooptijd	12 tot 24 maanden, langer voor grote groepen	6 tot 12 maanden per locatie
Belangrijkste risico	Onbekenden in elke workstream	Lokalisatie en lokale gereedheid
Data	Volledige lading vanuit verouderde systemen	Lokale data afgestemd op de globale standaarden voor stamgegevens
Testen	Volledige cyclus: unittest, integratietest, UAT, performancetest	Lokalisatie, lokale interfaces, UAT
Verandermanagement	Volledig programma vanaf nul	Bestaand materiaal aangepast aan lokale teams

Een implementatie past wanneer:

1. De organisatie nog nooit SAP heeft gebruikt.
2. Het huidige systeem tekortschiet en als geheel moet worden vervangen.
3. Een fusie, overname of nieuw operationeel model ertoe leidt dat het oude ontwerp niet meer past.
4. Voor het eerst een branche-oplossing komt, zoals SAP for Utilities of SAP for Public Sector.
5. Geen enkele bestaande template de scope dekt die u nodig hebt.

Implementaties duren langer en kosten vooraf meer. U krijgt een ontwerp dat bij uw bedrijf past en een team dat elke keuze erachter begrijpt. Bedrijven die haastig door de requirements heen jagen, zijn later 30 tot 50 procent meer kwijt aan het herstellen van fouten. Ik heb het steeds opnieuw zien gebeuren.

Een uitrol past wanneer SAP ergens in de groep al goed draait, de kernprocessen stabiel zijn en de template flexibel genoeg is om lokale vereisten op te nemen zonder te breken. Is een van die drie wankel, repareer dan eerst de template voordat u hem ergens uitrolt.

De technische kant wordt meestal op tijd afgerond. De vertraging komt van mensen en van aannames die in het nieuwe land niet kloppen.

Een template die lokale teams wordt opgelegd

Wat goed werkte voor Noord-Amerika schiet in Azië of het Midden-Oosten misschien tekort. Belastingstructuren, goedkeuringsworkflows en regels voor gegevensinvoer verschillen. Ik werkte ooit met een bedrijf dat dacht dat zijn Europese template ook in het Midden-Oosten zou werken. Het leidde tot vertraging, herschrijfwerk en veel spanning. De bedrijfsprocessen waren simpelweg te verschillend.

De oplossing is om de nieuwe locatie een business owner te geven met de bevoegdheid om beslissingen te nemen. Wanneer teams op het hoofdkantoor processen bepalen voor plaatsen die ze niet kennen, ontstaan ontwerpen die het contact met lokale gebruikers niet overleven.

Lokalisatie die pas tijdens het testen opduikt

Belastingafhandeling, wettelijke rapporten en verplichte gegevensvelden moeten zijn bevestigd voordat het ontwerp begint. Ik heb ooit een klant ondersteund bij wie een klein verschil in belastingconfiguratie de go-live met ruim een maand vertraagde. Het ging niet om technologie. Niemand had de lokale behoeften vroeg genoeg gevalideerd.

Stamgegevens die niet aansluiten

Productcodes, klantnummers en leveranciersclassificaties moeten overeenkomen met de globale standaarden. Afwijkingen die u na de go-live ontdekt, zijn duur om te herstellen en verstoren de geconsolideerde rapportage. Stem lokale data tijdens het ontwerp af op het globale model, niet in de UAT.

Training die het globale systeem uitlegt, niet het lokale

Bij uitrol wordt vaak de training van de oorspronkelijke implementatie hergebruikt. Dat materiaal legt uit hoe het systeem op het hoofdkantoor werkt. Het legt de lokale aanpassingen niet uit. Gebruikers die niet begrijpen waarom hun versie anders is, gaan omwegen bouwen.

Het kader hierboven blijft gelden. Het implementatiemodel van de template verandert wel een deel van de economie en de regels voor uitbreidingen.

Op RISE with SAP (Private Edition) voegt elk nieuw land gebruikers toe aan een abonnement op basis van full user equivalents (FUE's). U krijgt voorspelbare kosten en minder infrastructuurwerk. De kosten lopen ook na de go-live door, dus vergelijk de opties over meerdere jaren en niet alleen over het eerste jaar.

Op GROW with SAP (Public Edition) controleert u eerst of SAP een lokale versie voor het land levert. SAP vermeldde per februari 2024 lokale versies voor 59 landen en regio's. Voor andere landen laat SAP's lokalisatie als selfserviceprogramma partners een klantspecifieke lokale versie bouwen met de Configuration Localization Tool, momenteel via een early-adopterroute (SAP Learning). Geldt geen van beide, dan hebt u een scopingprobleem, geen uitrol.

Clean core geldt voor elke lokale afwijking. Public Edition accepteert uitbreidingen alleen via vrijgegeven interfaces. Op Private Edition is het een keuze in de governance, maar elke lokale aanpassing die u toestaat is een extra object dat bij elke upgrade opnieuw getest moet worden, vermenigvuldigd met elk land. De discipline waar ik op aandring is eenvoudig: belastingwetten, wettelijke rapportage en regelgeving rechtvaardigen een afwijking. Lokale voorkeuren niet.

Voordat u een datum vastlegt voor het volgende land, wilt u op elk van deze punten een ja. Elk punt heeft een eigenaar.

1. Lokale business owner (nieuw land): benoemd, met de bevoegdheid om het lokale ontwerp goed te keuren.
2. Belasting- en juridisch adviseur: belasting, wettelijke rapportage en verplichte gegevensvelden gedocumenteerd voordat het ontwerp begint.
3. Template-eigenaar (hoofdkantoor): lijst met voorgestelde afwijkingen, elk gemarkeerd als vereiste of voorkeur.
4. Datalead: lokale klant-, leveranciers- en materiaalgegevens afgestemd op de globale standaarden.
5. Integratielead: lokale systemen die gekoppeld moeten worden, zoals banken, belastingaangifte of logistiek, geïdentificeerd en afgebakend.
6. Changelead: training afgestemd op het lokale proces, in de lokale taal, met lokale voorbeelden.
7. Programmadirecteur: één locatie tegelijk, met lessen van de vorige go-live meegenomen naar de volgende.

Mijn gids voor een scopetemplate helpt bij punt 3, en de gids voor het projectcharter laat zien hoe u beslisbevoegdheden op papier zet.

Een greenfield-implementatie in Egypte. Een regionaal productiebedrijf in Egypte zat vast aan oude, losstaande systemen en veel handwerk. Toeleveringsketen, productievolging en financiële rapportage communiceerden niet met elkaar. Het bedrijf implementeerde SAP S/4HANA vanaf nul en verbond financiën, inkoop en productie in één systeem. Het zette geautomatiseerde planning van de toeleveringsketen op en trainde ruim 5.000 medewerkers in vier landen voordat het live ging. Het haastte zich niet. Het verlaagde de operationele kosten met 25 procent en de voorspellingsfouten met 35 procent.

Een uitrol naar 15 markten. Een retailbedrijf had SAP S/4HANA al draaien op het hoofdkantoor en had het nodig in 15 nieuwe markten. Elke markt kende andere belastingregels, valuta en bedrijfsgewoonten. Het begon bij een globale template, paste die per locatie aan, rolde in fasen uit over twee jaar in plaats van alles tegelijk, en bouwde training voor elke regio. Het resultaat was snellere financiële consolidatie, realtime voorraadvolging in alle winkels en 20 procent nauwkeurigere rapportage op groepsniveau.

Het ene was het bouwen van iets dat nog niet bestond. Het andere was het uitbreiden van iets dat werkte. Geen van beide was plug-and-play. Staat u aan het begin van de eerste soort, dan is mijn gids over hoe u een SAP-implementatie goed begint de plek om te beginnen.

Wat is het verschil tussen een SAP-implementatie en een SAP-uitrol?

Een implementatie bouwt SAP vanaf nul op: requirements, procesontwerp, configuratie, datamigratie, integratie, testen en go-live. Een uitrol breidt een bestaand SAP-systeem en de globale template daarvan uit naar een nieuw land, een nieuwe entiteit of een nieuwe bedrijfseenheid. Het werk bij een uitrol is het gat tussen de template en de lokale behoeften: belasting, wettelijke rapportage, taal, lokale koppelingen en training.

Wanneer kiest een bedrijf beter voor een implementatie dan voor een uitrol?

Kies voor een implementatie wanneer er geen SAP is om uit te breiden of wanneer een verouderd systeem als geheel wordt vervangen. Het is ook de betere route wanneer het bedrijfsmodel zo is veranderd dat het bestaande ontwerp niet meer past, of wanneer geen enkele template de vereiste scope dekt. Een uitrol met de verkeerde template afdwingen veroorzaakt meer herwerk dan een schoon ontwerp.

Hoe lang duurt een SAP-uitrol in vergelijking met een implementatie?

Een implementatie duurt doorgaans 12 tot 24 maanden, langer voor grote groepen. Een uitrol duurt doorgaans 6 tot 12 maanden per locatie, afhankelijk van lokalisatie, koppelingen en data. De grootste variabele is hoe goed de lokale vereisten zijn gevalideerd voordat het ontwerp begon.

Wat zijn de grootste uitdagingen bij een SAP-uitrol in meerdere landen?

Vier komen steeds terug. Templates die aan lokale teams worden opgelegd zonder hun inbreng. Lokalisatievereisten die tijdens het testen opduiken. Stamgegevens die niet overeenkomen met de globale standaarden. Training die het globale systeem uitlegt in plaats van het lokale. De meeste hiervan zijn problemen van mensen en planning, geen technische.

Is een SAP-uitrol altijd goedkoper dan een volledige implementatie?

Meestal wel, omdat het ontwerp al bestaat en zich heeft bewezen. De besparing krimpt wanneer een land complexe belasting- of salarisregels kent, meerdere lokale koppelingen vraagt of slechte data heeft. Onder RISE with SAP loopt het abonnement voor elk nieuw land na de go-live door, dus vergelijk de kosten over meerdere jaren.

Hoe werkt een globale template bij een SAP-uitrol?

De globale template is het gedocumenteerde, geconfigureerde SAP-ontwerp voor de standaardprocessen van de groep. Elke uitrol begint daarbij en voegt alleen de lokale wijzigingen toe die echt vereist zijn. Elke afwijking schept een onderhoudsverplichting bij elke upgrade, dus beheers ze: vereisten zoals belastingwetgeving rechtvaardigen een afwijking, voorkeuren niet.