Jedes einzelne System in einer typischen Unternehmenslandschaft – ERP, CRM, HR, Payroll, Dokumentenmanagement, Reporting – erfüllt für sich betrachtet seinen Zweck. Das Problem entsteht nicht in den Systemen, sondern in den Zwischenräumen: doppelt gepflegte Stammdaten, manuelle Exporte von einem System ins andere, Funktionen die in zwei Anwendungen parallel existieren.

Vier Fragen, die ich für jede Anwendung stelle

Bei einer Bestandsaufnahme einer Applikationslandschaft prüfe ich für jedes System dieselben vier Punkte: Welche Aufgabe erfüllt es heute tatsächlich – nicht ursprünglich gedacht, sondern real genutzt? Gibt es funktionale Überschneidungen mit einem anderen System? Ist es strategisch im Einsatz, oder existiert es hauptsächlich, weil es historisch gewachsen ist und niemand die Ablösung angegangen ist? Und: Wie hoch sind die tatsächlichen Gesamtkosten, wenn man Betrieb, Support, Schnittstellen und das nötige Fachwissen mit einrechnet – nicht nur die Lizenz?

Die letzte Frage liefert regelmässig die grösste Überraschung. Ein System, das auf dem Papier günstig wirkt, kostet oft ein Vielfaches an Integrationsaufwand und internem Wissen, das nur eine einzige Person im Haus wirklich hat.

Standardisierung heisst nicht: alles in ein System

Nicht jede Konsolidierung bedeutet, alles in eine einzige Plattform zu zwingen. Entscheidend ist, dass für jede Aufgabe klar definiert ist, welches System sie übernimmt, wo die Daten geführt werden, und wie die Verbindung zu den anderen Systemen aussieht. Zwei oder drei gut abgestimmte Systeme mit klaren Zuständigkeiten sind oft wirkungsvoller als eine einzelne Plattform, die versucht, alles selbst zu können, und dafür an mehreren Stellen kompromittiert.

Wann sich Individualentwicklung wirklich lohnt

In Business Central entwickle ich selbst regelmässig Erweiterungen in AL – und genau deshalb bin ich vorsichtig damit, Individualentwicklung vorschnell zu empfehlen. Die Frage, die vor jeder Erweiterung stehen sollte, ist nicht "können wir das bauen", sondern "deckt der Standard das nicht bereits ausreichend ab, und was verlieren wir an Wartbarkeit, wenn wir vom Standard abweichen".

Eine Erweiterung, die heute sinnvoll erscheint, wird bei jedem künftigen Update zu einem Punkt, der geprüft werden muss. Das heisst nicht, dass Individualentwicklung falsch ist – manche Anforderungen lassen sich anders schlicht nicht abbilden. Es heisst, dass die Entscheidung bewusst getroffen werden sollte, mit dem vollen Bild der langfristigen Kosten, nicht nur des kurzfristigen Nutzens.

Migration ist der beste Zeitpunkt für Bereinigung

Bei einer ERP- oder CRM-Modernisierung besteht die grösste Versuchung darin, jede bestehende Anpassung eins zu eins ins neue System zu übertragen. Das ist selten die richtige Entscheidung. Viele dieser Anpassungen sind über Jahre entstanden, ohne dass je geprüft wurde, ob sie noch gebraucht werden. Eine Migration ist der seltene Moment, in dem man ohne grossen Zusatzaufwand fragen kann: Brauchen wir das wirklich noch, oder reicht der Standard inzwischen aus? Diese Frage bei jeder einzelnen Anpassung zu stellen, kostet Zeit – spart aber über die folgenden Jahre deutlich mehr, weil jede unnötig migrierte Altlast bei jedem künftigen Update wieder Aufwand verursacht.

Kurz gefasst

  • Das Problem liegt selten in einzelnen Systemen, sondern in den ungeklärten Zwischenräumen.
  • Vier Prüffragen pro System: tatsächliche Aufgabe, Überschneidungen, strategischer Wert, echte Gesamtkosten.
  • Standardisierung heisst klare Zuständigkeit, nicht zwingend ein einziges System für alles.
  • Eine Migration ist der beste Moment, um alte Anpassungen kritisch zu hinterfragen statt sie automatisch mitzunehmen.

Eine erste Einschätzung, wo in Ihrer Applikationslandschaft die grössten Doppelspurigkeiten liegen, lässt sich oft schon in einem kompakten Gespräch skizzieren.