Standard versus Individualisierung ist die falsche Grundsatzfrage
In Business-Central-Projekten taucht früher oder später dieselbe Diskussion auf: Bleiben wir möglichst nah am Standard oder entwickeln wir eine Erweiterung? Häufig wird daraus beinahe eine Glaubensfrage. Dabei ist weder "Standard um jeden Preis" noch "wir bauen es passend" eine gute Strategie.
Business Central lebt gerade davon, dass Prozesse standardisiert werden können und gleichzeitig ein sauberes Erweiterungsmodell zur Verfügung steht. Die eigentliche Frage lautet deshalb: Wo schafft eine Abweichung vom Standard genug geschäftlichen Mehrwert, um die zusätzliche Komplexität dauerhaft zu rechtfertigen?
1. Welches konkrete Problem lösen wir?
Eine Anforderung wie "Wir brauchen ein zusätzliches Feld" beschreibt noch kein Problem. Vielleicht fehlt tatsächlich eine Information. Vielleicht existiert sie aber bereits in einem anderen System. Vielleicht wird sie nur deshalb benötigt, weil ein alter Prozess unverändert übernommen werden soll.
Vor jeder Entwicklung sollte deshalb zuerst der fachliche Zweck geklärt werden. Was passiert heute? Was soll künftig anders sein? Wer benötigt die Information? Und welche Entscheidung oder welcher Prozess hängt davon ab?
2. Gibt es bereits Standardfunktionalität?
Business Central entwickelt sich laufend weiter. Funktionen, für die vor einigen Jahren noch Anpassungen notwendig waren, können heute bereits im Standard verfügbar sein. Deshalb lohnt sich vor jeder Entwicklung ein aktueller Fit-Gap-Check.
Das Ziel ist nicht, den Standard um jeden Preis durchzusetzen. Aber eine bestehende Standardfunktion reduziert in der Regel Wartung, Testaufwand und Abhängigkeiten. Erst wenn sie den Prozess nicht sinnvoll abdeckt, sollte die nächste Option geprüft werden.
3. Können wir den Prozess vereinfachen statt die Software erweitern?
Historisch gewachsene Abläufe werden bei Systemwechseln gerne eins zu eins übernommen. Damit digitalisiert man jedoch häufig nicht den besten Prozess, sondern nur den bisherigen. Eine neue Anforderung ist deshalb auch eine Gelegenheit, den Ablauf grundsätzlich zu hinterfragen.
Wenn drei Freigabeschritte nur existieren, weil früher Informationen fehlten, sollte man nicht automatisch drei digitale Freigaben bauen. Vielleicht kann der Prozess heute einfacher gestaltet werden.
4. Gehört die Logik wirklich in Business Central?
Nicht jede Funktion muss im ERP liegen. Je nach Use Case kann eine Integration, eine Power-Platform-Lösung, eine externe Fachanwendung oder ein schlanker Service die sauberere Architektur darstellen. Besonders kritisch wird es, wenn Business Central beginnt, Aufgaben zu übernehmen, die fachlich eigentlich zu einem anderen System gehören.
Eine gute Solution Architecture betrachtet deshalb nicht nur BC, sondern die gesamte Systemlandschaft.
5. Wie updatefähig bleibt die Lösung?
Eine Erweiterung sollte so gebaut sein, dass sie Releases und Updates möglichst wenig behindert. Moderne AL-Extensions bieten dafür eine gute Grundlage, trotzdem entstehen Abhängigkeiten: Events können sich ändern, Drittanbieter-Apps entwickeln sich weiter und Integrationen müssen getestet werden.
Die Frage lautet deshalb nicht nur "Können wir das entwickeln?", sondern auch "Können wir es in zwei Jahren noch wirtschaftlich betreiben?".
6. Wie hoch sind die Folgekosten?
Entwicklungskosten sind nur ein Teil der Rechnung. Hinzu kommen Dokumentation, Tests, Support, Releaseprüfungen und Wissenstransfer. Eine kleine Anpassung kann über mehrere Jahre mehr Aufwand verursachen als ursprünglich erwartet.
Umgekehrt kann eine gezielte Erweiterung sehr wirtschaftlich sein, wenn sie jeden Monat viele manuelle Stunden eliminiert oder Fehler verhindert. Entscheidend ist eine nüchterne Betrachtung des gesamten Lebenszyklus.
7. Ist die Lösung verständlich dokumentiert?
Eine nachhaltige Erweiterung braucht eine klare fachliche Begründung, eine technische Beschreibung und nachvollziehbare Verantwortlichkeiten. Wenn nach zwei Jahren niemand mehr weiss, warum eine Logik eingebaut wurde, wird jede Änderung teuer.
Gute Dokumentation ist deshalb kein Nice-to-have. Sie ist Teil der Lösung.
Fazit: Keep it simple - aber nicht dogmatisch
Der Standard sollte der Ausgangspunkt sein. Wo ein klarer Business Case besteht, Prozesse sinnvoll unterstützt werden und die Lösung technisch sauber bleibt, kann eine Erweiterung absolut richtig sein.
Die beste Business-Central-Lösung ist nicht die mit den wenigsten Extensions. Es ist die Lösung, die verständlich, wartbar und wirtschaftlich bleibt - und den tatsächlichen Geschäftsprozess unterstützt.
