Best Practices für eine komplexe Business-Central-Einführung, die nicht aus einem Ratgeber stammen

Die wirksamen Best Practices für eine komplexe Business-Central-Einführung sind keine Checkliste, sondern eine Reihenfolge: erst das Fundament, dann Standard vor Custom, dann ein Pilot statt eines Big Bang. Wer diese Reihenfolge dreht, baut Tempo auf Sand. Vor jeder Konfiguration stehen genau drei Fragen: Sind die Stammdaten tragfähig, sind die Kernprozesse geklärt, ist benannt, wer bei Zielkonflikten verbindlich entscheidet. Ohne diese drei Antworten wird aus jeder Einführungswoche eine Diskussionswoche. Der Grund ist mechanisch: Eine Einführung besteht zum größten Teil aus Entscheidungen, nicht aus Konfiguration. Fehlt die Entscheidungsgrundlage, entstehen sie im Workshop unter Zeitdruck, und dann gewinnt die lauteste Stimme statt der besten Begründung. Die drei Fragen lassen sich vorab beantworten, in Wochen statt Monaten. Genau deshalb ist diese Vorarbeit kein Verzug, sondern der günstigste Teil des Projekts.

Warum kommt das Fundament zuerst?

Vor jeder Konfiguration stehen genau drei Fragen: Sind die Stammdaten tragfähig, sind die Kernprozesse geklärt, ist benannt, wer bei Zielkonflikten verbindlich entscheidet. Ohne diese drei Antworten wird aus jeder Einführungswoche eine Diskussionswoche.

Der Grund ist mechanisch. Eine Einführung besteht zum größten Teil aus Entscheidungen, nicht aus Konfiguration. Wenn die Entscheidungsgrundlage fehlt, entstehen sie im Workshop unter Zeitdruck, und dann gewinnt die lauteste Stimme statt der besten Begründung.

Die drei Fragen lassen sich vorab beantworten, und zwar in Wochen statt Monaten. Stammdaten sind messbar, Prozesse lassen sich in einem Vorprojekt aufnehmen, und die Entscheidungsverantwortung ist eine Personalentscheidung, keine Analyse. Genau deshalb ist diese Vorarbeit die günstigste Phase des gesamten Projekts, gemessen an dem, was sie später verhindert.

Warum Standard vor Custom und Pilot statt Big Bang?

Der teuerste Fehler in komplexen Projekten ist, gewachsene Sonderwege eins zu eins nachzubauen. Ein seniorer Ansatz nutzt Business Central als Heimat, prüft jeden Anpassungswunsch gegen den Standard und erlaubt Extensions nur dort, wo Sie sich echt differenzieren.

Quelle: Microsoft Learn: Development in AL

Und statt eines Big Bang geht ein repräsentativer Ausschnitt zuerst live, an echten Prozessen und echten Daten. Was dort auffällt, fällt kontrolliert auf, nicht am Go-Live-Tag über alle Bereiche gleichzeitig.

Der Pilot hat einen zweiten, unterschätzten Nutzen: Er beweist dem Fachbereich, dass das System trägt. Vertrauen entsteht an echten Belegen und einem echten Monatsabschluss, nicht in einer Präsentation. Wer den Pilot streicht, um Zeit zu sparen, verlagert damit nicht den Aufwand, sondern nur den Zeitpunkt, an dem die Probleme sichtbar werden, und zwar auf den schlechtesten.

Warum braucht es Governance von Tag eins?

Diese Artefakte klingen unspektakulär und sind der Unterschied zwischen Steuerung und Nachlauf:

• Entscheidungslog und ein priorisierter Backlog.
• Abnahmekriterien je Modul.
• Ein Data-Owner je Stammdatendomäne.
• Test und Datenmigration früh und in echten Testläufen, nicht in der letzten Projektwoche.

Reihenfolge über Geschwindigkeit: Ein realistischer Rahmen, der das Fundament respektiert, ist schneller am tragfähigen Go-Live als ein ambitionierter Plan, der es überspringt. Der letzte Punkt der Liste ist der am häufigsten verletzte: Datenmigration und Test wandern regelmäßig in die letzten Wochen, obwohl beide Erkenntnisse liefern, die den Scope beeinflussen. Wenn Sie vor einer komplexen Einführung stehen und die Reihenfolge sichern wollen, gehen wir Ihr Fundament in einem Erstgespräch durch. Die Steuerung bleibt dabei auf Ihrer Seite, mit Business Central als Heimat.

Kurz vor dem Start zählt nur noch eines: Woran erkennen Sie, dass Sie go-live-bereit sind?