Wie baut man ein Global Template für den ERP-Rollout auf?

Ein Global Template entsteht in drei Schritten: Erstens die Kernprozesse und Stammdatenregeln festlegen, die in jedem Land identisch gelten. Zweitens die erlaubten lokalen Abweichungen benennen, meist Steuer, Meldewesen und Zahlungsverkehr. Drittens eine Instanz einsetzen, die jede weitere Ausnahme genehmigen muss. Ohne diesen dritten Schritt zerfällt jedes Template im ersten Rollout-Jahr.

Was gehört in das Template und was nicht?

In das Template gehört, was das Geschäftsmodell trägt: der Auftrag-zu-Rechnung-Prozess, der Einkauf-zu-Zahlung-Prozess, die Stammdatenregeln für Artikel, Kunden und Lieferanten, der Kontenrahmen auf Konzernebene und die Dimensionslogik für das Berichtswesen. Diese Elemente entscheiden später darüber, ob Zahlen über Länder vergleichbar sind.

Nicht in das Template gehört, was ein Land rechtlich oder faktisch nicht ändern kann: lokale Steuerlogik, gesetzliches Meldewesen, Zahlungsformate, Archivierungspflichten. Wer diese Punkte zentral erzwingen will, produziert teure Sonderlocken an der falschen Stelle.

• Konzernweit verbindlich: Kernprozesse, Stammdatenregeln, Kontenrahmen-Logik, Dimensionen, Berechtigungsmodell
• Lokal erlaubt: Steuer, Meldewesen, Zahlungsverkehr, Sprache, gesetzliche Belege
• Immer entscheidungspflichtig: alles, was ein Land zusätzlich möchte

Der Grenzfall ist die dritte Kategorie, und dort entscheidet Governance statt Technik.

Wie verhindert man, dass Ausnahmen das Template aushöhlen?

Jede Länderorganisation hat gute Gründe für ihre Sonderwünsche, und einzeln betrachtet ist fast jeder plausibel. Die Erosion entsteht durch die Summe. Deshalb braucht das Template einen Eigentümer mit Entscheidungsrecht: eine Person oder ein kleines Gremium, das jede Abweichung gegen eine einfache Frage prüft: rechtlich nötig, geschäftlich zwingend oder nur gewohnt?

In der Praxis bewährt sich eine Ausnahme-Quote als Frühwarnsignal. Steigt der Anteil länderspezifischer Anpassungen über etwa ein Fünftel des Templates, ist das kein Lokalisierungs-Thema mehr, sondern ein Governance-Thema. Dann entscheidet faktisch nicht mehr das Template über die Länder, sondern die Länder über das Template.

Wirksam ist dabei nicht das Verbot, sondern der Preis. Wenn jede Ausnahme mit ihren Folgekosten für Test, Dokumentation und Release-Pflege beziffert wird, entscheidet sich der Großteil von selbst. Länder verzichten freiwillig, sobald der Aufwand sichtbar in ihrem eigenen Budget landet.

In welcher Reihenfolge entsteht ein tragfähiges Template?

Der verlässlichste Weg führt über ein Pilotland, das repräsentativ ist, aber nicht das komplexeste. Dort wird das Template real bewiesen: mit echten Daten, echten Nutzern und echtem Monatsabschluss. Erst danach wird skaliert. Wer das Template am Reißbrett fertigstellt und im größten Markt startet, testet Theorie unter Maximaldruck.

Nach dem Piloten gilt: Erkenntnisse einarbeiten, Template einfrieren, dann ausrollen. Jede Welle darf das Template präzisieren, aber nicht neu verhandeln. Das unterscheidet einen Rollout von zwölf Einzelprojekten.

Der häufigste Fehler ist, das Template vor dem Piloten für fertig zu erklären. Ein Template auf dem Papier beschreibt, wie es laufen soll, nicht wie es läuft, und der Unterschied zeigt sich erst an echten Belegen und einem echten Monatsabschluss.

Zeitlich lohnt sich diese Reihenfolge doppelt: Was der Pilot aufdeckt, wird einmal korrigiert und gilt dann für alle folgenden Wellen. Wer den Piloten überspringt, korrigiert dieselbe Sache in jedem Land erneut.

Welche Rolle spielt die Datenbasis im Template?

Das unterschätzte Fundament. Prozesse lassen sich je Land nachschärfen, eine auseinandergelaufene Datenbasis nicht. Wenn Artikelnummern, Kundenstrukturen und Dimensionen je Land eigene Wege gehen, ist die Konsolidierung dauerhaft Handarbeit und jede spätere Automatisierung, auch mit KI, baut auf Sand.

Deshalb gehört die Stammdaten-Governance in das Template selbst: wer legt an, nach welchen Regeln, mit welcher Pflichttiefe. Die Datenbasis bleibt, Systeme und Länder kommen dazu. Steuerung bleibt dabei auf Ihrer Seite, mit Business Central als Heimat.

Praktisch heißt das: Die Stammdatenregeln gehören in dieselbe Freigabe wie die Prozesse, nicht in einen Anhang. Und sie brauchen einen benannten Verantwortlichen je Datenobjekt, denn eine Regel ohne Eigentümer ist eine Empfehlung.

Der Prüfstein nach der zweiten Welle ist einfach: Lassen sich Artikel und Kunden über alle Gesellschaften hinweg mit derselben Logik auswerten? Wenn nicht, ist die Datenbasis bereits auseinandergelaufen, und jede weitere Welle vergrößert den Abstand.

Was ist bei Business Central anders als bei SAP-Templates?

Fast alles, was man über Global Templates liest, stammt aus der SAP-Welt und beschreibt ein Modell, das es in Business Central nicht gibt. Der Unterschied verändert den Aufbau grundlegend.

• Keine Kern-Modifikation, sondern Extensions: In Business Central wird der Standard nicht verändert, Erweiterungen liegen als eigene Apps daneben. Ein Template ist deshalb kein eingefrorener Systemzustand, sondern ein Set aus Konfiguration und Apps.
• Konfigurationspakete statt Transportaufträge: Einstellungen und Stammdaten werden über Konfigurationspakete verteilt, nicht über eine Transportkette. Das macht den Rollout leichter, verlangt aber Disziplin bei der Versionierung.
• Laufende Cloud-Updates: Microsoft liefert zwei größere Releases pro Jahr. Ein Template, das einmal definiert und dann eingefroren wird, ist nach einem Jahr veraltet.

Das Business-Central-Template besteht aus drei getrennt gepflegten Teilen: dem Regelwerk mit Prozessen, Stammdatenregeln und Kontenlogik, den Konfigurationspaketen je Rollout-Welle und dem Extension-Set, getrennt in konzernweit und länderspezifisch.

Wie hält man das Template über die Releases hinweg lebendig?

Der Punkt, an dem die meisten internationalen Business-Central-Programme leise auseinanderlaufen. Wenn niemand die halbjährlichen Releases gegen das Template prüft, testet jedes Land für sich, und aus einem Template werden über zwei Jahre zwölf leicht unterschiedliche Systeme.

Dagegen hilft eine schlichte Routine: ein benannter Eigentümer für das Template, ein fester Prüftermin je Release, ein Satz automatisierter Testfälle für die Kernprozesse und ein kurzer Änderungsbericht an alle Länder. Der Aufwand liegt bei wenigen Tagen pro Release, verglichen mit dem Aufwand, zwölf auseinandergelaufene Länder wieder zusammenzuführen.

Diese Pflege ist der eigentliche Unterschied zwischen einem Template, das nur eingeführt wurde, und einem, das nach fünf Jahren noch trägt. Business Central als Heimat bedeutet nicht Stillstand, sondern regelmäßige, geplante Bewegung.