Was ist eine ERP-Lösung?

Der Begriff „ERP-Lösung“ meint mehr als nur das Programm: Er umfasst die Software, ihre Anpassung an Ihre Prozesse, die Einführung und den laufenden Betrieb. Wir zeigen, woraus eine ERP-Lösung besteht und wann Standard schlägt Individualentwicklung.

Software ist nur ein Teil der Lösung

Eine ERP-Lösung ist das Gesamtpaket, mit dem ein Unternehmen seine Ressourcenplanung umsetzt. Dazu gehört die ERP-Software selbst, aber ebenso ihre Konfiguration, die Datenübernahme, Schnittstellen, Schulung und der Support im Betrieb. Wer nur auf den Funktionsumfang der Software schaut, übersieht oft den größeren Teil des Erfolgsfaktors: die Umsetzung.

Standardlösung oder Individualentwicklung?

Die meisten Unternehmen fahren mit einer Standardlösung am besten: Sie ist erprobt, wird vom Anbieter gepflegt und lässt sich über Konfiguration an viele Bedürfnisse anpassen. Eine vollständige Individualentwicklung ist nur in Ausnahmefällen sinnvoll – etwa bei einem echten Alleinstellungsprozess, der Wettbewerbsvorteil ist.

Ein bewährter Mittelweg ist die Standardsoftware mit gezielten Erweiterungen für die wenigen wirklich individuellen Abläufe. Das hält die Lösung wartbar und updatefähig.

Wie finden Sie die passende ERP-Lösung?

Am Anfang steht nicht die Software, sondern die Analyse Ihrer Prozesse und Anforderungen. Daraus entsteht ein Lastenheft, das die Grundlage für den Vergleich bildet. Den vollständigen Weg beschreibt die ERP-Auswahl; für die Umsetzung siehe ERP-Einführung und – bei Bedarf an externer Unterstützung – ERP-Consulting.

Die Total Cost of Ownership im Blick behalten

Wer Angebote für eine ERP-Lösung vergleicht, schaut häufig zuerst auf den Lizenz- oder Abopreis. Dieser ist jedoch nur ein Teil der tatsächlichen Kosten. Die sogenannte Total Cost of Ownership (TCO) erfasst den gesamten Aufwand über die Nutzungsdauer und umfasst neben den Lizenzen auch Einführung, Datenmigration, Schnittstellen, Schulung, laufenden Betrieb, Updates und Support. Gerade die einmaligen Projektkosten der Einführung werden oft unterschätzt – sie können je nach Komplexität die Lizenzkosten des ersten Jahres deutlich übersteigen. Eine belastbare Entscheidung entsteht deshalb erst, wenn alle diese Posten über einen Zeitraum von drei bis fünf Jahren zusammengerechnet werden.

Cloud- und On-Premise-Lösungen verteilen die Kosten dabei unterschiedlich über die Zeit. Die Cloud verlagert den Aufwand von einer hohen Anfangsinvestition hin zu planbaren laufenden Gebühren, was die Liquidität schont und die IT entlastet. On-Premise verursacht höhere Startkosten, kann sich bei sehr langer Nutzung und vorhandener IT-Mannschaft aber relativieren. Welches Modell günstiger ist, lässt sich nur im Einzelfall und über die gesamte Laufzeit beurteilen.

Der Faktor Mensch

Ein oft übersehener Bestandteil jeder ERP-Lösung ist der interne Aufwand. Mitarbeitende müssen Anforderungen klären, Daten bereinigen, das System testen und schließlich damit arbeiten. Diese Zeit ist real, taucht aber in keinem Angebot auf. Wer sie von Beginn an einplant und ausreichend Schulung vorsieht, vermeidet Frust und sichert den Erfolg der Lösung.

Vertragsgestaltung: worauf Sie achten sollten

Eine ERP-Lösung wird über Verträge geregelt, deren Gestaltung den späteren Projekterfolg stark beeinflusst. Wichtig ist, Leistungen klar und überprüfbar zu beschreiben: Welcher Funktionsumfang ist geschuldet, welche Anpassungen sind enthalten, und wer trägt die Verantwortung für Datenmigration und Schnittstellen? Unklare Formulierungen führen später zu Streit und Mehrkosten. Bei Cloud-Lösungen sollten zudem Verfügbarkeit, Wartungsfenster und Reaktionszeiten in einem Service-Level-Agreement (SLA) festgehalten werden.

Ein weiterer zentraler Punkt ist die Frage der Datenhoheit und des Ausstiegs. Wem gehören die Daten, in welchem Format und mit welchem Aufwand lassen sie sich bei einem späteren Anbieterwechsel exportieren? Solche Regelungen wirken im Moment des Vertragsabschlusses nebensächlich, entscheiden aber darüber, wie frei ein Unternehmen langfristig bleibt. Wer hier vorsorgt, vermeidet eine teure Abhängigkeit.

Pilotphase statt Vollausbau

Gerade bei größeren Vorhaben empfiehlt es sich, die Lösung zunächst in einem klar abgegrenzten Bereich zu erproben, bevor sie unternehmensweit ausgerollt wird. Eine solche Pilotphase – etwa in einer Abteilung oder an einem Standort – deckt Schwächen auf, schafft Erfahrungswerte und reduziert das Risiko eines großen Fehlstarts. Die Erkenntnisse fließen anschließend in den breiten Rollout ein. Dieses schrittweise Vorgehen kostet etwas mehr Zeit, erhöht aber die Erfolgswahrscheinlichkeit deutlich und erleichtert es, die Belegschaft mitzunehmen. Eine ERP-Lösung ist eben kein einmaliger Kauf, sondern ein Prozess, der sich über die gesamte Nutzungsdauer erstreckt.

Nach dem Go-Live: Betrieb und Weiterentwicklung

Mit dem Produktivstart beginnt nicht das Ende, sondern eine neue Phase im Lebenszyklus der ERP-Lösung. In den ersten Wochen ist eine intensive Betreuung wichtig, um Anlaufschwierigkeiten rasch aufzufangen. Danach geht die Lösung in den Regelbetrieb über, der laufende Aufgaben mit sich bringt: Updates einspielen, Berechtigungen pflegen, neue Mitarbeitende schulen und auf veränderte Anforderungen reagieren. Eine ERP-Lösung ist damit ein dauerhaftes Vorhaben, kein einmaliges Projekt.

Sinnvoll ist, von Beginn an Verantwortlichkeiten für den Betrieb festzulegen: Wer ist interner Ansprechpartner, wer pflegt Stammdaten, wer steuert die Weiterentwicklung? Viele Unternehmen etablieren einen kontinuierlichen Verbesserungsprozess, in dem regelmäßig geprüft wird, welche zusätzlichen Funktionen oder Optimierungen Nutzen stiften würden. So bleibt die Lösung über Jahre lebendig und wächst mit den Anforderungen mit, statt langsam zu veralten. Gerade dieser gepflegte Betrieb entscheidet darüber, ob sich die ursprüngliche Investition langfristig auszahlt.

Skalierbarkeit von Anfang an mitdenken

Eine ERP-Lösung sollte nicht nur zur heutigen, sondern auch zur künftigen Unternehmensgröße passen. Was für zehn Anwender gut funktioniert, kann bei fünfzig an Grenzen stoßen – sei es bei der Leistung, der Zahl der Belege oder der Abbildung zusätzlicher Standorte und Geschäftsbereiche. Wer Wachstum plant, sollte deshalb früh prüfen, wie gut eine Lösung mitwächst und welche Module sich später ergänzen lassen. Cloud-Lösungen bieten hier oft Vorteile, weil sich Ressourcen flexibel anpassen lassen. Wichtig ist auch die Erweiterbarkeit über Schnittstellen, damit neue Anforderungen ohne Systemwechsel abgedeckt werden können. Eine von Beginn an skalierbar gewählte Lösung schützt die Investition und erspart einen teuren, störungsanfälligen Wechsel zum ungünstigsten Zeitpunkt – nämlich mitten in einer Wachstumsphase.

Abhängigkeit vom Anbieter begrenzen

Eine ERP-Lösung bindet ein Unternehmen über viele Jahre an einen Anbieter – umso wichtiger ist es, diese Abhängigkeit bewusst zu begrenzen. Achten Sie darauf, dass Ihre Daten jederzeit in gängigen Formaten exportierbar sind und dass offene Schnittstellen den Austausch mit anderen Systemen erlauben. Auch die Verfügbarkeit mehrerer Implementierungspartner statt eines einzigen reduziert das Risiko, im Konfliktfall handlungsunfähig zu sein. Klären Sie vertraglich, wie ein späterer Wechsel oder Ausstieg ablaufen würde und wer welche Daten in welcher Form bereitstellt. Wer diese Punkte früh regelt, bewahrt sich Verhandlungsspielraum und Flexibilität – und vermeidet, dass eine einmal getroffene Entscheidung zur dauerhaften Falle wird.

Woraus eine ERP-Lösung wirklich besteht

Der Begriff „ERP-Lösung“ umfasst weit mehr als die Software. Zu einer vollständigen Lösung gehören die Software mit den passenden Modulen, ihre Konfiguration und Anpassung, die Integration in die bestehende Systemlandschaft, die Einführung inklusive Datenmigration und Schulung sowie der laufende Betrieb mit Wartung, Updates und Support. Wer nur den Funktionsumfang vergleicht, übersieht den größeren Teil des Erfolgsfaktors: die Umsetzung und der Betrieb über Jahre.

Standardsoftware, Individualentwicklung oder Mittelweg?

Eine zentrale Weichenstellung ist die Frage „Make or Buy“. Für die allermeisten Unternehmen ist Standardsoftware die bessere Wahl: erprobt, vom Anbieter gepflegt und über Konfiguration breit anpassbar. Eine vollständige Individualentwicklung lohnt nur bei einem echten Alleinstellungsprozess, der Wettbewerbsvorteil ist – sie ist teuer und in der Wartung aufwendig.

Der bewährte Mittelweg ist Standardsoftware mit gezielten, updatesicheren Erweiterungen für die wenigen wirklich individuellen Abläufe.

Total Cost of Ownership: die Gesamtkosten über die Laufzeit

Der Lizenz- oder Abopreis ist nur ein Teil der Kosten. Die Total Cost of Ownership (TCO) erfasst den gesamten Aufwand über die Nutzungsdauer:

• Lizenz- bzw. Abogebühren (einmalig oder laufend)
• Einführung: Projektleitung, Konfiguration, Datenmigration, Test
• Schnittstellen und Erweiterungen
• Schulung der Anwender
• Laufender Betrieb: Hosting, Wartung, Updates, Support
• Interner Personalaufwand – real, taucht aber in keinem Angebot auf

Gerade die einmaligen Einführungskosten werden oft unterschätzt und können die Lizenzkosten des ersten Jahres übersteigen. Eine belastbare Entscheidung rechnet alle Posten über drei bis fünf Jahre zusammen.

Lizenz- und Betriebsmodelle

Cloud-Lösungen werden meist als Abonnement pro Nutzer und Monat abgerechnet, On-Premise klassisch als Kauflizenz plus Wartungsvertrag. Die Cloud verlagert den Aufwand von einer hohen Anfangsinvestition zu planbaren laufenden Gebühren und schont die Liquidität; On-Premise verursacht höhere Startkosten, kann sich bei sehr langer Nutzung aber relativieren. Welches Modell günstiger ist, lässt sich nur über die gesamte Laufzeit beurteilen.

Vertrag, SLA und Ausstieg

Die Gestaltung der Verträge beeinflusst den Projekterfolg stark. Leistungen sollten klar und überprüfbar beschrieben sein; bei Cloud-Lösungen gehören Verfügbarkeit, Wartungsfenster und Reaktionszeiten in ein Service-Level-Agreement (SLA). Ebenso wichtig ist die Frage der Datenhoheit: In welchem Format und mit welchem Aufwand lassen sich die Daten bei einem späteren Wechsel exportieren? Wer das früh regelt, vermeidet eine teure Abhängigkeit.

Configuration statt Customizing: der Hebel für eine wartbare Lösung

Sobald die grundsätzliche Frage geklärt ist, ob Sie auf Standardsoftware oder eine Individualentwicklung setzen, beginnt die eigentliche Feinarbeit: Wie passen Sie die einmal gewählte Lösung an Ihre Abläufe an, ohne sie auf Dauer unbeweglich zu machen? Genau hier entscheidet sich, ob Ihr System über Jahre wartbar bleibt oder zu einem teuren Sonderbau verkommt, der jeden Releasewechsel fürchtet. Dieser Abschnitt betrachtet ausschließlich die technische Umsetzungsebene innerhalb einer bereits gewählten Lösung. Die vorgelagerte Make-or-Buy-Entscheidung behandeln wir getrennt auf der Seite zur ERP-Auswahl; hier geht es darum, wie Sie eine gekaufte oder bezogene Lösung so anpassen, dass sie anpassbar bleibt.

Der Leitgedanke lautet: Configuration statt Customizing. Beide Begriffe werden im Projektalltag oft synonym verwendet, beschreiben aber grundverschiedene Eingriffstiefen mit grundverschiedenen Folgekosten. Wer den Unterschied nicht trennscharf versteht, trifft Anpassungsentscheidungen aus dem Bauch heraus und kauft sich technische Schulden ein, die erst beim nächsten Update sichtbar werden, dann aber mit Zins und Zinseszins fällig sind.

Die vier Anpassungsebenen sauber getrennt

Anpassung ist kein Schalter mit zwei Stellungen, sondern eine Treppe mit mehreren Stufen. Jede Stufe greift tiefer in die Lösung ein, kostet mehr und belastet die spätere Wartung stärker. Die vier Ebenen lassen sich klar voneinander abgrenzen:

1. Prozessanpassung an den Standard. Die ressourcenschonendste Form der Anpassung ist gar keine technische Anpassung, sondern eine organisatorische: Sie verändern den eigenen Ablauf so, dass er zum Standardprozess der Lösung passt. Wenn die Software einen Wareneingang in zwei Schritten (Anlieferung buchen, dann Qualitätsprüfung) abbildet, Ihr Betrieb das aber bislang in einem Schritt erledigt hat, ist die Übernahme des zweistufigen Standardprozesses oft die bessere Wahl, als die Software auf den Einschritt-Ablauf umzubiegen. Diese Ebene erzeugt null Code, null Konfigurationsobjekte und null Wartungslast in der Software selbst.

2. Konfiguration und Parametrisierung. Hier stellen Sie das System über vorgesehene Einstellungen ein, ohne eine Zeile Code zu schreiben. Konfiguration meint dabei eher das strukturelle Einrichten: Belegarten anlegen, Nummernkreise definieren, Workflows über mitgelieferte Bausteine zusammenstecken, Berechtigungsrollen schneiden, Pflichtfelder festlegen, Standardlayouts wählen. Parametrisierung ist die feinere Schwester davon: das Setzen einzelner Werte und Schalter innerhalb dieser Strukturen, etwa Steuerschlüssel, Bewertungsverfahren, Mahnstufen, Schwellenwerte oder Toleranzgrenzen. Beides spielt sich vollständig im dafür vorgesehenen Rahmen der Software ab. Entscheidend ist: Die Hersteller garantieren, dass diese Einstellungen einen Releasewechsel überleben, weil sie als Daten und nicht als Programmänderung gespeichert werden.

3. Erweiterung über vorgesehene Schnittstellen, Apps und Extensions. Reichen Konfiguration und Parametrisierung nicht aus, ist die nächste Stufe die Erweiterung über die vom Hersteller dafür geöffneten Mechanismen: Extensions, Add-ons, App-Marktplätze, dokumentierte APIs, Event- oder Webhook-Modelle, Plug-in-Punkte. Charakteristisch ist, dass Ihr zusätzlicher Code neben dem Standard läuft und über eine stabile, versionierte Schnittstelle andockt, statt den Standard selbst zu verändern. Der Hersteller verspricht, diese Schnittstelle über definierte Zeiträume stabil zu halten. Ihre Erweiterung bleibt damit ein klar abgegrenztes, eigenständiges Artefakt, das Sie unabhängig pflegen, testen und ausliefern können.

4. Customizing im Quellcode. Die tiefste und teuerste Stufe ist der Eingriff in den ausgelieferten Quellcode selbst: Standardobjekte werden verändert, Originalroutinen umgeschrieben, Felder mitten in Kernstrukturen ergänzt, Standardmasken direkt überschrieben. Damit verlassen Sie den geschützten Rahmen. Was vorher der Hersteller wartete, wartet ab jetzt faktisch Ihr Team. Jede Modifikation am Original ist eine Abzweigung von der Standardlinie, die bei jedem Update wieder eingefangen, geprüft und gegebenenfalls erneut angepasst werden muss.

Die saubere Trennung dieser vier Ebenen ist mehr als Begriffsklauberei. Sie ist die Grundlage jeder Entscheidung darüber, ob eine Anforderung billig und folgenlos oder teuer und langfristig belastend umgesetzt wird. Die folgende Grafik ordnet die Ebenen nach Risiko und Kosten:

Warum jede Stufe die Updatefähigkeit anders belastet

Der entscheidende Mechanismus dahinter ist die Frage, wer für die Pflege eines Anpassungsartefakts verantwortlich ist und wie es bei einem Releasewechsel behandelt wird. Auf den unteren beiden Ebenen bleibt der Hersteller in der Pflicht: Den Standardprozess und die Konfigurationslogik pflegt und aktualisiert er, Ihre Einstellungswerte werden beim Update übernommen. Sie zahlen für eine Anpassung auf diesen Ebenen praktisch keine Folgekosten über die einmalige Einrichtung hinaus.

Auf der dritten Ebene entsteht erstmals ein eigenes Artefakt, das Sie pflegen müssen. Der Aufwand ist aber kalkulierbar, weil die Erweiterung über eine definierte Schnittstelle entkoppelt ist. Solange der Hersteller diese Schnittstelle stabil hält, betrifft ein Releasewechsel Ihre Extension im Regelfall nur dann, wenn sich die Schnittstelle ändert, und solche Änderungen werden üblicherweise vorab kommuniziert und mit Übergangsfristen versehen. Die Updatefähigkeit der Gesamtlösung bleibt damit erhalten; sie ist nur an die Pflege eines klar umrissenen Zusatzbausteins gekoppelt.

Die vierte Ebene durchbricht dieses Prinzip. Eine Modifikation am Standardcode ist nicht entkoppelt, sondern verwoben. Bei jedem Update liefert der Hersteller eine neue Version genau jener Objekte aus, die Sie verändert haben. Nun müssen Ihre Änderungen und die neuen Herstellerstände manuell zusammengeführt werden, ein Vorgang, der mit jeder weiteren Modifikation und jedem übersprungenen Release komplexer und fehleranfälliger wird. Aus einem ursprünglich kleinen Eingriff wird über Jahre eine wachsende Wartungshypothek. Dieser Lebenszyklus-Effekt ist der eigentliche Grund, warum stark modifizierte Systeme irgendwann releaseunfähig werden: Nicht eine einzelne Änderung ist das Problem, sondern die kumulierte Last vieler Eingriffe, die bei jedem Versionssprung gemeinsam getestet und nachgezogen werden müssen.

Custom-Code-Schulden über den Lebenszyklus

Der Begriff der technischen Schuld ist hier wörtlich zu nehmen. Eine Code-Modifikation, die heute drei Tage Entwicklung kostet, ist nicht mit diesen drei Tagen bezahlt. Sie zieht eine Reihe wiederkehrender Verpflichtungen nach sich, die über die gesamte Nutzungsdauer anfallen:

• Wiederkehrender Merge- und Testaufwand bei jedem Release, weil die Modifikation gegen den neuen Standard geprüft und gegebenenfalls neu eingepasst werden muss.
• Wissensschuld: Jede Modifikation ist nur so wartbar wie die Dokumentation und die Person, die sie verstanden hat. Geht das Wissen verloren, wird die Anpassung zur Blackbox, die niemand mehr anzufassen wagt.
• Regressionsrisiko: Modifikationen am Standard können an unerwarteten Stellen mit neuen Herstellerfunktionen kollidieren, weil sie Annahmen über internes Verhalten treffen, die der Hersteller jederzeit ändern darf.
• Verzögerungswirkung: Je mehr Modifikationen sich ansammeln, desto teurer und riskanter wird jeder einzelne Releasewechsel, was dazu verleitet, Updates aufzuschieben, was die Schuld weiter aufstaut.

Diese Dynamik erklärt, warum manche Unternehmen über Jahre auf veralteten Versionen festsitzen: Nicht weil die neue Version schlecht wäre, sondern weil der Berg an Eigenmodifikationen den Umstieg zu teuer macht. Wer dieses Muster vermeiden will, sollte Modifikationen wie Kredite behandeln, die man nur aufnimmt, wenn der erwartete Nutzen die laufenden Zinsen klar übersteigt, und die man bei nächster Gelegenheit zurückführt, indem man sie in Konfiguration oder eine saubere Extension überführt. Diese disziplinierte Haltung zur Eingriffstiefe trägt unmittelbar zur Wartbarkeit eines ERP-Systems über seinen gesamten Lebenszyklus bei.

Konkrete Entscheidungsregeln für die Praxis

Damit die Theorie im Projektalltag trägt, braucht es überprüfbare Regeln. Die folgenden haben sich als robust erwiesen:

1. Prozess vor Software. Fragen Sie bei jeder Anforderung zuerst, ob der gewünschte Sonderweg ein echter Wettbewerbsvorteil ist oder nur gewohnte Routine. Reine Gewohnheit rechtfertigt keine technische Anpassung; hier passt sich der Prozess an den Standard an.
2. Bewahre den Standard, solange es geht. Steigen Sie nur dann auf die nächsthöhere Ebene, wenn die darunterliegende die Anforderung nachweislich nicht abdecken kann. Jede Stufe nach oben braucht eine bewusste Begründung.
3. Erweitern statt eingreifen. Wenn Code nötig ist, prüfen Sie immer zuerst, ob er sich als entkoppelte Extension neben dem Standard realisieren lässt, bevor Sie den Standard selbst verändern.
4. Modifikationen brauchen einen Eigentümer und ein Verfallsdatum. Jede Code-Modifikation wird dokumentiert, einer verantwortlichen Stelle zugeordnet und mit der Frage versehen, wann und wie sie wieder abgebaut werden kann.
5. Rechnen Sie über die Laufzeit, nicht über das Projekt. Bewerten Sie eine Anpassung nicht an den einmaligen Umsetzungskosten, sondern an den Gesamtbetriebskosten über mehrere Releasezyklen hinweg.

Diese Regeln lassen sich gut in einem Anpassungsregister festhalten, das pro Anforderung Ebene, Begründung und erwartete Folgekosten dokumentiert. Ein solches Register schafft Transparenz darüber, wie viel Sonderbau ein System bereits trägt, und ist eine wertvolle Grundlage für jedes spätere ERP-Consulting, weil es die historisch gewachsene Eingriffstiefe sichtbar macht.

Wie Extension- und Low-Code-Konzepte das Dilemma entschärfen

Das klassische Dilemma lautete jahrzehntelang: Entweder Sie bleiben starr im Standard und verzichten auf nötige Anpassungen, oder Sie modifizieren und verlieren die Updatefähigkeit. Moderne Lösungsarchitekturen haben dieses Entweder-oder spürbar entschärft, indem sie die dritte Ebene massiv ausgebaut haben. Wo früher fast jede nicht-triviale Anforderung in den Standardcode eingreifen musste, stehen heute deutlich reichhaltigere, dokumentierte Erweiterungspunkte zur Verfügung.

Das Extension-Modell trennt Ihren Zusatzcode physisch und logisch vom Standard. Statt eine Standardroutine zu überschreiben, hängen Sie sich an einen vom Hersteller bereitgestellten Ereignis- oder Erweiterungspunkt und ergänzen Verhalten, ohne das Original zu berühren. Der entscheidende Gewinn: Der Hersteller kann seinen Standard frei weiterentwickeln, solange die Erweiterungspunkte stabil bleiben, und Ihre Anpassung wandert unverändert mit. Damit verschiebt sich viel von dem, was früher teures Customizing war, auf die deutlich wartbarere Erweiterungsebene.

Low-Code- und No-Code-Werkzeuge setzen noch eine Ebene tiefer an: Sie ermöglichen es, Workflows, Formulare, Validierungsregeln oder kleine Anwendungen über visuelle Modellierung statt über klassischen Programmcode zu erstellen. Technisch sind diese Modelle meist als interpretierte Konfiguration umgesetzt, die der Hersteller stabil hält. Das senkt nicht nur den Aufwand, sondern verlagert viele Anpassungen, die früher Entwickler banden, in die Reichweite der Fachbereiche. Wichtig ist allerdings die nüchterne Einordnung: Low-Code ersetzt keine Architekturdisziplin. Auch ein visuell zusammengeklickter Workflow kann zur Schuld werden, wenn er undokumentiert wuchert, Logik dupliziert oder kritische Prozesse intransparent macht. Die Anpassungspyramide gilt also weiter — Low-Code verschiebt nur die Grenze, bis zu der Sie ohne klassisches Customizing auskommen, nach oben.

Für die Praxis bedeutet das: Prüfen Sie bei der Bewertung einer Lösung nicht nur deren Standardfunktionsumfang, sondern explizit die Reichhaltigkeit und Stabilität ihrer Erweiterungsschicht. Eine Lösung mit moderatem Standard, aber exzellentem Extension- und Low-Code-Konzept ist langfristig oft wartbarer als eine funktionsreichere Lösung, die jede Sonderanforderung nur über Code-Eingriffe zulässt. Diese Erweiterbarkeit ist ein zentrales Qualitätsmerkmal jeder modernen ERP-Lösung und sollte in der Vorauswahl mit demselben Gewicht bewertet werden wie der reine Leistungsumfang.

Zusammenführung: Wartbarkeit ist eine Entscheidung, kein Zufall

Ob Ihre Lösung in fünf Jahren noch beweglich ist, entscheidet sich nicht im Code, sondern in der Haltung, mit der Sie Anpassungen angehen. Wer jede Anforderung reflexhaft programmiert, sammelt eine Wartungshypothek an, die irgendwann jeden Releasewechsel blockiert. Wer dagegen die Anpassungspyramide diszipliniert von unten nach oben durchläuft — erst den Prozess, dann die Konfiguration, dann die Erweiterung und nur im begründeten Ausnahmefall den Code-Eingriff — hält die Updatefähigkeit hoch und die Betriebskosten niedrig. Configuration statt Customizing ist damit keine technische Spitzfindigkeit, sondern der wichtigste Einzelhebel, um aus einer gekauften Software eine über Jahre wartbare Lösung zu machen.

Suite oder Best-of-Breed: wie der Lösungszuschnitt das Gesamtpaket prägt

Wenn eine ERP-Lösung Gestalt annimmt, steht früh eine architektonische Grundentscheidung an, die das gesamte Paket über Jahre prägt: Soll das Unternehmen auf eine integrierte Suite eines einzigen Anbieters setzen, die nahezu alle Funktionsbereiche unter einem Dach vereint, oder auf einen Best-of-Breed-Verbund, in dem für jeden Bereich das jeweils beste spezialisierte System ausgewählt und mit den übrigen verbunden wird? Diese Frage ist nicht dasselbe wie die Abwägung zwischen Standard und Individualanpassung. Sie liegt eine Ebene darüber und betrifft die Topologie der Lösung selbst, also die Anzahl der beteiligten Systeme, ihre Hersteller und die Art, wie sie zusammenspielen. Wer die Grundzüge integrierter Systeme noch einmal nachschlagen möchte, findet sie in der Übersicht zum ERP-System; dieser Abschnitt setzt darauf auf und behandelt ausschließlich den Lösungszuschnitt.

Die Entscheidung wirkt auf den ersten Blick technisch, hat aber durchweg wirtschaftliche und organisatorische Folgen. Sie bestimmt, mit wie vielen Vertragspartnern Sie es zu tun haben, wo Ihre Daten liegen und wer sie führt, wer im Störungsfall die Verantwortung trägt, wie aufwendig Updates zu koordinieren sind und wie sich die Gesamtkosten über die Laufzeit verteilen. Eine einmal gewählte Topologie lässt sich nur mit erheblichem Aufwand wieder verändern, weil sich Schnittstellen, Verträge, Betriebsroutinen und das Wissen der eigenen Mannschaft daran ausrichten. Deshalb verdient die Grundsatzfrage eine bewusste, kriteriengeleitete Behandlung statt einer beiläufigen Festlegung.

Die integrierte Suite: ein Dach, ein Datenmodell, ein Ansprechpartner

Eine integrierte Suite ist ein zusammenhängendes Produkt eines Herstellers, das Finanzwesen, Einkauf, Vertrieb, Lagerwirtschaft, Produktion und weitere Bereiche in einem gemeinsamen Datenmodell abbildet. Der wesentliche Vorzug liegt im Wegfall der Brüche zwischen den Bereichen: Ein Beleg, der im Vertrieb entsteht, wandert ohne Übersetzung in die Lagerwirtschaft und in die Buchhaltung, weil alle Module dieselben Stammdaten, dieselben Schlüssel und dieselbe Logik teilen. Es gibt keine Schnittstelle, die gepflegt, überwacht und bei Versionswechseln nachgezogen werden müsste, denn die Verbindung ist Teil des Produkts.

Dieser durchgehende Datenfluss hat unmittelbare Konsequenzen für die Datenhoheit. In einer Suite liegen die Daten in einer einheitlichen Struktur, und das führende System für nahezu jede Datenkategorie ist dasselbe. Auswertungen über Bereichsgrenzen hinweg sind ohne Konsolidierungsschritt möglich, weil die Information nicht erst aus mehreren Quellen zusammengeführt werden muss. Auch die Verantwortlichkeiten sind klar geschnitten: Tritt ein Fehler auf, gibt es einen einzigen Hersteller, der das Gesamtprodukt verantwortet. Im englischen Sprachraum hat sich dafür das Bild der einen Kehle zum Würgen etabliert: Es gibt genau eine Adresse, an die sich das Unternehmen wendet, und niemand kann die Verantwortung auf einen Schnittstellenpartner abschieben.

Der Preis für diese Geschlossenheit ist eine geringere Funktionstiefe in den einzelnen Bereichen. Eine Suite muss in der Breite überzeugen und kann in keinem Spezialgebiet so weit gehen wie ein dediziertes System, das ausschließlich diesen einen Bereich bedient. Wer in einem Teilbereich hochspezialisierte Anforderungen hat, etwa in der Fertigungsfeinplanung, im Außenhandel oder in der Lagerautomatisierung, stößt mit dem Suite-Modul mitunter an Grenzen. Hinzu kommt eine gewisse Abhängigkeit vom Hersteller, weil dessen Roadmap, Preisgestaltung und Lebenszyklus die gesamte Lösung bestimmen.

Der Best-of-Breed-Verbund: Spezialisten an jeder Stelle

Der Gegenentwurf wählt für jeden Funktionsbereich das jeweils stärkste spezialisierte System und verbindet diese Systeme zu einem Verbund. Ein dediziertes CRM für den Vertrieb, ein hochentwickeltes Lagerverwaltungssystem, eine eigenständige Produktionsplanung und ein Finanzsystem stehen nebeneinander und tauschen über Schnittstellen Daten aus. Der Reiz liegt in der Funktionstiefe: Jedes Teilsystem bringt in seinem Gebiet eine Reife mit, die eine Suite kaum erreicht, weil sein Hersteller seine gesamte Entwicklungskraft auf genau diesen Ausschnitt richtet.

Diese Stärke erkauft sich der Verbund mit erheblichem Integrationsaufwand. Die Systeme sprechen nicht von Haus aus dieselbe Sprache, also müssen Schnittstellen gebaut, betrieben und bei jedem Versionswechsel eines der beteiligten Systeme nachgezogen werden. Datenhoheit wird zur Konstruktionsaufgabe: Für jede Datenkategorie muss bewusst festgelegt werden, welches System führt und in welche Richtung die Daten fließen, sonst entstehen widersprüchliche Versionen derselben Information. Die Frage, welche Anwendung die Stammdaten besitzt, beantwortet sich in einer Suite von selbst, im Verbund hingegen nur durch eine durchdachte Integrationsarchitektur.

Auch die Verantwortung verteilt sich. Tritt ein Fehler an einer Schnittstelle auf, ist nicht ohne Weiteres klar, ob das sendende System, das empfangende System oder die Integrationsschicht die Ursache trägt. Statt einer Kehle gibt es viele Vertragspartner, die im Zweifel aufeinander verweisen. Damit steigt die Vertragskomplexität spürbar: Mehrere Lizenz-, Wartungs- und Supportverträge mit unterschiedlichen Laufzeiten, Service-Levels und Preismodellen müssen verwaltet und aufeinander abgestimmt werden. Die Koordination der Updates wird zur Daueraufgabe, weil eine neue Version eines Systems die Kompatibilität mit den anderen gefährden kann und deshalb jeder Versionswechsel im Verbundkontext geprüft werden muss.

Der hybride Mittelweg: Core-ERP plus angedockte Spezialsysteme

In der Praxis verläuft die Entscheidung selten als reines Entweder-oder. Die verbreitetste Lösung ist ein hybrider Zuschnitt: Ein integriertes Core-ERP bildet die Mitte und deckt die transaktionalen Kernbereiche ab, also Finanzwesen, Einkauf, Bestandsführung und die grundlegende Auftragsabwicklung. An dieses stabile Zentrum werden gezielt einzelne Spezialsysteme angedockt, dort, wo die Funktionstiefe des Core-ERP nicht ausreicht und der fachliche Mehrwert eines Spezialisten den Integrationsaufwand rechtfertigt.

Der Charme dieses Modells liegt darin, dass es die Vorzüge beider Welten anteilig nutzt und ihre Nachteile begrenzt. Das Core-ERP liefert die einheitliche Datenbasis und einen klaren führenden Ankerpunkt für die wichtigsten Stammdaten; die angedockten Spezialsysteme bringen Tiefe an genau den Stellen, an denen sie gebraucht wird. Entscheidend ist die Disziplin: Der Hybrid funktioniert nur, wenn die Anzahl der Satelliten bewusst klein gehalten und jede Schnittstelle gezielt entworfen wird. Wuchert der Verbund unkontrolliert, kippt der Mittelweg in einen schwer beherrschbaren Best-of-Breed-Zustand, ohne dass dies je beschlossen wurde.

Der Hybrid verlagert einen Teil der Best-of-Breed-Komplexität, ohne sie ganz aufzulösen. Die Verantwortung im Störungsfall bleibt geteilt, allerdings auf wenige Partner konzentriert, und die Update-Koordination beschränkt sich auf die definierten Andockpunkte. Damit ist der hybride Zuschnitt für viele Unternehmen die pragmatische Antwort: Er sichert eine handhabbare Mitte und erlaubt punktuelle Spezialisierung, ohne die gesamte Lösung in einen vielteiligen Verbund zu verwandeln.

Wie Reifegrad, Branche und IT-Mannschaft die Wahl verschieben

Welcher Zuschnitt der richtige ist, hängt nicht von der abstrakten Überlegenheit eines Modells ab, sondern von der konkreten Situation des Unternehmens. Drei Faktoren verschieben die Entscheidung am stärksten, und sie wirken zusammen.

Der Reifegrad der Organisation ist der erste Faktor. Ein Unternehmen, das seine Prozesse noch ordnet und vereinheitlicht, profitiert von der Geschlossenheit einer Suite, weil sie einen vorgezeichneten Rahmen liefert und die Zahl der beweglichen Teile niedrig hält. Eine reife Organisation mit klar verstandenen, differenzierten Prozessen kann hingegen gezielt entscheiden, an welchen Stellen ein Spezialsystem echten Vorsprung bringt, und besitzt die Kraft, den entstehenden Integrationsaufwand zu tragen. Best-of-Breed setzt organisatorische Reife voraus, es verstärkt sie nicht.

Die Branchen-Spezifika bilden den zweiten Faktor. In Branchen mit hochspezialisierten, wettbewerbsentscheidenden Abläufen, etwa in der variantenreichen Fertigung, im komplexen Projektgeschäft oder in stark regulierten Bereichen, kann ein generisches Suite-Modul den fachlichen Bedarf nicht decken, und ein spezialisiertes System wird unverzichtbar. In Branchen mit standardnahen Abläufen, in denen kein Bereich einen entscheidenden Unterschied macht, ist die Funktionstiefe eines Spezialisten dagegen ein Vorteil, den niemand benötigt, während sein Integrationsaufwand voll zu Buche schlägt. Wer hier eine fundierte Abwägung sucht, findet in einer strukturierten ERP-Auswahl den Rahmen, um Funktionstiefe und Integrationsaufwand gegeneinander zu gewichten.

Die IT-Mannschaft ist der dritte und oft unterschätzte Faktor. Ein Best-of-Breed-Verbund verlangt dauerhaft Kompetenz im Schnittstellenbetrieb, in der Versionspflege mehrerer Systeme und in der Koordination mehrerer Hersteller. Fehlt diese Kapazität, wird die theoretische Stärke des Verbunds im Alltag zur Belastung, weil die Schnittstellen nicht gepflegt und die Updates nicht koordiniert werden. Eine schlanke IT-Organisation fährt mit einer Suite oder einem eng gefassten Hybrid sicherer, weil dort weniger laufende Eigenleistung anfällt. Mittelständische Unternehmen mit begrenzten internen Ressourcen sollten diesen Aspekt besonders sorgfältig prüfen; die spezifischen Rahmenbedingungen dafür beleuchtet die Betrachtung zu ERP im Mittelstand.

Gesamtkosten über die Laufzeit richtig einordnen

Die Kostenwirkung des Lösungszuschnitts zeigt sich erst über die gesamte Laufzeit, nicht in der Anschaffung. Eine Suite bündelt Lizenzen, Wartung und Support oft in einem überschaubaren Vertragswerk, was die Gesamtkosten kalkulierbar macht; der Gegenwert ist die Abhängigkeit von der Preis- und Roadmap-Politik eines einzelnen Anbieters. Ein Best-of-Breed-Verbund verteilt die Lizenzkosten auf mehrere Hersteller und fügt einen dauerhaften, leicht zu übersehenden Posten hinzu: den Bau, den Betrieb und die fortlaufende Anpassung der Schnittstellen. Dieser Integrationsaufwand ist keine einmalige Investition, sondern eine wiederkehrende Last, die mit jedem Versionswechsel eines beteiligten Systems erneut anfällt.

Wer die Gesamtkosten seriös vergleicht, darf daher nicht bei den Lizenzpreisen stehenbleiben. In die Betrachtung gehören der Aufwand für Integration und deren Pflege, der Koordinationsaufwand über mehrere Verträge hinweg, das Risiko ungeklärter Verantwortung im Störungsfall und der Aufwand, mehrere Update-Zyklen aufeinander abzustimmen. Diese Posten fallen beim Verbund deutlich höher aus und werden in oberflächlichen Vergleichen regelmäßig unterschlagen. Umgekehrt kann ein Suite-Modul, das fachlich nicht ausreicht, versteckte Kosten in Form von Workarounds und manueller Nacharbeit erzeugen, die ein Spezialsystem vermieden hätte.

Am Ende ist der Lösungszuschnitt eine Abwägung zwischen Geschlossenheit und Spezialisierung, zwischen kalkulierbarer Einfachheit und maximaler Funktionstiefe. Es gibt keine allgemein richtige Antwort, nur eine zur Situation passende. Die meisten Unternehmen landen aus guten Gründen in der Mitte, mit einem stabilen Core-ERP und einigen bewusst gewählten Spezialsystemen. Entscheidend ist, dass die Wahl bewusst getroffen wird, ihre Folgen für Integration, Datenhoheit, Verantwortung, Verträge und Kosten von Anfang an mitgedacht werden und die Topologie zur Reife, zur Branche und zur eigenen Mannschaft passt. Eine Lösung, deren Zuschnitt diese drei Größen ignoriert, wird über die Laufzeit teurer und fragiler, als jeder Lizenzvergleich vermuten lässt.

Wer liefert was: Rollen und Verantwortung im Liefermodell einer ERP-Lösung

Eine ERP-Lösung ist kein Produkt, das Sie an einer Kasse abholen und danach allein betreiben. Sie ist ein Bündel aus Software, Anpassung, Infrastruktur und laufendem Betrieb, das im Regelfall mehrere Parteien gemeinsam erbringen. Sobald die Lösung im Wirkbetrieb läuft, stellt sich nicht mehr die Frage, welches System Sie wählen oder wie Sie es einführen, sondern die nüchterne Frage des Alltags: Wenn morgens um acht eine Schnittstelle hängt, wer ist eigentlich zuständig? Dieser Abschnitt betrachtet ausschließlich die dauerhafte Liefer- und Betriebskonstellation einer ERP-Lösung, also das Zusammenspiel der beteiligten Dienstleister im laufenden Betrieb. Die vorgelagerte Frage, wie Sie überhaupt das richtige System und den richtigen Partner auswählen, behandeln wir getrennt auf den Seiten zur ERP-Auswahl und zum ERP-Consulting; hier geht es um die Konstellation, die danach über Jahre bestehen bleibt.

Der Grund, warum dieses Thema so oft unterschätzt wird, liegt in einer trügerischen Annahme: Viele Unternehmen denken, sie hätten einen Lieferanten. In Wahrheit haben sie eine Kette. Und in jeder Kette entscheidet nicht die Stärke des stärksten Glieds über die Belastbarkeit, sondern die Sauberkeit der Übergänge zwischen den Gliedern. Genau an diesen Übergängen, den Schnittstellen zwischen den Rollen, entstehen die teuersten und ärgerlichsten Betriebsstörungen.

Die vier Grundrollen im Liefermodell

Im Betrieb einer ERP-Lösung lassen sich vier Grundrollen unterscheiden, die jeweils einen klar umrissenen Leistungsteil verantworten. In kleinen Konstellationen können mehrere Rollen in einer Hand liegen; in größeren Mittelstandsumgebungen sind sie typischerweise auf verschiedene Organisationen verteilt. Entscheidend ist, dass jede Rolle einen eigenen Verantwortungsbereich, eigene Aufgaben und eigene Haftungsgrenzen mitbringt.

1. Der Softwarehersteller. Er liefert das Produkt selbst: das Standardprogramm, die regelmäßigen Releases, Patches und Korrekturen sowie die Produktdokumentation. Seine Verantwortung endet grundsätzlich an der Grenze des ausgelieferten Standards. Funktioniert eine dokumentierte Standardfunktion nachweislich nicht wie beschrieben, ist das sein Fehler; verhält sich dagegen eine Anpassung, die ein Dritter gebaut hat, fehlerhaft, ist das nicht sein Problem. Der Hersteller stellt außerdem die Lizenz- oder Abonnementbedingungen, garantiert die Stabilität seiner Erweiterungsschnittstellen über definierte Zeiträume und gibt vor, welche Versionen er noch wartet. Mit ihm haben Sie es im Alltag selten direkt zu tun; sein Einfluss wirkt mittelbar über die anderen Rollen.

2. Der Implementierungspartner beziehungsweise Systemintegrator. Diese Rolle übersetzt das Standardprodukt in Ihre konkrete Lösung. Sie verantwortet die Einrichtung, die Konfiguration, etwaige Erweiterungen und das Verbinden mit Ihren Umsystemen. Im laufenden Betrieb bleibt der Partner für die von ihm gebaute Lösungslogik zuständig: für die Pflege seiner Erweiterungen, für Fehler in der von ihm umgesetzten Konfiguration und häufig für den fachlichen Second-Level-Support. Hier liegt eine besonders heikle Grenze, denn der Partner verantwortet das, was auf dem Standard aufsetzt, nicht den Standard selbst. Tritt ein Fehler auf, ist die erste, oft strittige Frage, ob er aus dem Produkt oder aus der Anpassung stammt.

3. Der Hosting- und Betriebsdienstleister. Er stellt die Plattform bereit, auf der die Lösung läuft: Rechenzentrum oder Cloud, Server, Betriebssystem, Datenbank, Netzwerk, Backups, Monitoring und je nach Modell auch das Einspielen technischer Updates. Seine Verantwortung ist primär technisch und an Verfügbarkeit, Wiederherstellbarkeit und Reaktionsgeschwindigkeit gebunden. Ob ein Buchungslauf fachlich korrekt rechnet, interessiert ihn nicht; ob die Datenbank antwortet und das Backup von gestern Nacht wiederherstellbar ist, sehr wohl. Wie genau die einzelnen Schichten zwischen Ihnen und diesem Dienstleister aufgeteilt sind, hängt stark vom Betriebsmodell ab und ist der Kern des Shared-Responsibility-Problems, das wir gleich gesondert betrachten.

4. Das interne Team. Die vierte Rolle wird im Liefermodell am häufigsten vergessen, obwohl ohne sie nichts funktioniert. Ihr internes Team stellt die fachliche Hoheit über die Prozesse, betreibt den First-Level-Support für die Endanwender, pflegt Stammdaten und Berechtigungen im Rahmen der eingerichteten Lösung und stellt vor allem die Key-User, also jene Fachexperten, die ihren Bereich im System wirklich verstehen. Diese Rolle ist das Scharnier zwischen Anwendern und Dienstleistern: Sie entscheidet, ob eine Störung sauber qualifiziert und an die richtige externe Stelle weitergegeben wird oder ungefiltert im Eskalationschaos landet.

Aufgaben- und Haftungsgrenzen sauber verstehen

Jede der vier Rollen bringt eine implizite Haftungsgrenze mit, und genau diese Grenzen kollidieren im Störungsfall. Der Hersteller haftet für seinen Standard, der Partner für seine Anpassung, der Betreiber für die Plattform, Sie für Daten und Bedienung. Das klingt sauber getrennt, ist es im Ernstfall aber selten, weil die Symptome einer Störung nicht verraten, aus welcher Schicht sie stammen. Eine langsame Maske kann an einer schlecht konfigurierten Erweiterung (Partner), an einer überlasteten Datenbank (Betreiber), an einem Produktfehler (Hersteller) oder an einem fehlerhaft gepflegten Stammdatensatz (intern) liegen. Vier Verantwortliche, ein Symptom.

Daraus folgt die wichtigste Erkenntnis dieses Abschnitts: Haftungsgrenzen sind nur dann nützlich, wenn vorher geklärt ist, wer die Ursache feststellt. Ohne eine eindeutig benannte Stelle für die Erstanalyse und Zuordnung einer Störung verbringen die Beteiligten mehr Zeit damit, die Verantwortung voneinander wegzuschieben, als das Problem zu lösen. Dieses Phänomen des gegenseitigen Verweisens, im Volksmund das Schwarze-Peter-Spiel, ist der häufigste Grund dafür, dass an sich kleine Störungen zu tagelangen Ausfällen werden.

Das Problem der geteilten Verantwortung im Cloud-Betrieb

Besonders verschärft wird die Lage durch den Cloud-Betrieb, weil dort die Grenze zwischen dem, was der Dienstleister leistet, und dem, was bei Ihnen verbleibt, je nach Modell an völlig unterschiedlicher Stelle verläuft. Dieses Prinzip der geteilten Verantwortung, im Fachjargon Shared Responsibility, ist kein Detail, sondern der zentrale Risikomechanismus moderner Betriebsmodelle. Die Faustregel lautet: Je mehr der Anbieter übernimmt, desto höher liegt die Trennlinie, und desto weniger bleibt in Ihrer Hand, aber desto weniger Kontrolle haben Sie auch.

Bei einem reinen Infrastrukturmodell (IaaS) liefert der Anbieter Rechenleistung, Speicher und Netzwerk; Betriebssystem, Datenbank, die ERP-Software, deren Updates und die Datensicherung auf Anwendungsebene bleiben in Ihrer beziehungsweise der Verantwortung Ihres Partners. Bei einem Plattformmodell (PaaS) übernimmt der Anbieter zusätzlich Betriebssystem und teils Datenbank, sodass sich Ihre Restverantwortung nach oben verschiebt. Bei einem vollständigen Software-as-a-Service-Modell (SaaS) betreibt der Anbieter nahezu den gesamten Stapel; bei Ihnen verbleiben im Wesentlichen nur noch Ihre Daten, die Konfiguration im vorgesehenen Rahmen, die Benutzerverwaltung und die Zugangssicherheit.

Die folgende Tabelle zeigt, wie sich die Trennlinie über die Modelle verschiebt. Sie macht sichtbar, dass auch im scheinbar sorglosen SaaS-Modell ein harter Kern an Verantwortung bei Ihnen bleibt:

Der gefährlichste Irrtum im Cloud-Betrieb ist die Annahme, mit dem Wechsel in die Cloud sei auch die Verantwortung für Datensicherung und Zugangssicherheit vollständig abgegeben. In den meisten Modellen ist das nicht der Fall. Der Anbieter sorgt für die Verfügbarkeit seiner Plattform und oft für deren technische Redundanz, aber die Sicherung Ihrer fachlichen Daten gegen versehentliches Löschen, fehlerhafte Massenänderungen oder kompromittierte Konten liegt regelmäßig weiter bei Ihnen. Wer diese Grauzone nicht ausdrücklich klärt, entdeckt die Lücke erst, wenn sie schmerzt. Die Verlagerung in die Cloud ist deshalb keine Frage des reinen Bezugsmodells, sondern eine bewusste Architektur-Entscheidung des gesamten ERP-Systems, deren Verantwortungsverteilung Sie kennen müssen, bevor der erste Buchungssatz geschrieben wird.

Eskalations- und Schnittstellenrisiken bei mehreren Parteien

Mit jeder zusätzlichen beteiligten Partei wächst die Zahl der Übergabepunkte überproportional. Bei zwei Parteien gibt es genau eine Schnittstelle, bei vier bereits sechs mögliche Paarbeziehungen. Jede dieser Beziehungen ist ein potenzieller Reibungspunkt, an dem Tickets liegen bleiben, Zuständigkeiten unklar sind oder Informationen verloren gehen. Die typischen Schnittstellenrisiken lassen sich klar benennen:

• Die Ursachen-Streitfrage: Eine Störung tritt auf, aber kein Beteiligter erkennt sie als die seine an. Ohne eine festgelegte Stelle für die Erstdiagnose dreht sich das Ticket im Kreis.
• Der Zeitverlust an der Übergabe: Ein korrekt diagnostiziertes Problem wird von einer Partei zur nächsten gereicht, wobei jede Übergabe neue Wartezeit, neue Rückfragen und einen erneuten Kontextaufbau erzeugt.
• Die uneinheitlichen Service-Zeiten: Wenn Hersteller, Partner und Betreiber unterschiedliche Erreichbarkeits- und Reaktionszeiten zusagen, ist die Gesamtlösung nur so schnell wie ihr langsamstes Glied in der Kette, nicht so schnell wie das beste Einzelversprechen.
• Die fehlende Gesamtsicht: Keiner der externen Beteiligten überblickt zwangsläufig das Gesamtsystem. Diese Gesamtsicht muss eine benannte Stelle aktiv herstellen, sonst entsteht sie nicht von selbst.

Der wirksamste Hebel gegen diese Risiken ist eine eindeutig benannte Eskalations- und Koordinationsstelle, die den Überblick über alle Beteiligten behält und im Störungsfall die Fäden zieht. Diese Rolle kann beim internen Team liegen, an einen der Dienstleister vergeben oder einem Generalunternehmer übertragen werden, der die übrigen Parteien steuert. Wichtig ist nicht, wo sie liegt, sondern dass sie überhaupt eindeutig existiert und über die Befugnis verfügt, eine Störung verbindlich der richtigen Stelle zuzuordnen. Wie eng die zugesagten Reaktions- und Verfügbarkeitszeiten dabei zu schneiden sind, ist ein eigenes Thema, das wir auf dieser Seite an anderer Stelle vertiefen; hier zählt nur, dass diese Zeiten zwischen den Parteien aufeinander abgestimmt sein müssen.

Verantwortlichkeiten vertraglich sauber schneiden: das RACI-Prinzip

Damit aus einer diffusen Erwartungshaltung eine belastbare Zuordnung wird, braucht es ein Instrument, das für jede Aufgabe eindeutig festhält, wer was tut. Bewährt hat sich dafür das RACI-Modell, das jeder Aufgabe vier mögliche Rollen zuweist: Responsible (führt aus), Accountable (trägt die Endverantwortung und entscheidet), Consulted (wird vorher gefragt) und Informed (wird nachher informiert). Die zentrale Regel lautet: Für jede Aufgabe gibt es genau eine verantwortliche Endinstanz (Accountable). Geteilte Endverantwortung ist keine Verantwortung; sie ist eine Einladung zum gegenseitigen Wegducken.

Übersetzt auf das ERP-Liefermodell bedeutet das, für die wesentlichen Betriebsaufgaben eine Matrix anzulegen: Wer ist accountable für die Datensicherung, wer für das Einspielen von Patches, wer für die Pflege der Erweiterungen, wer für die Erstdiagnose einer Störung, wer für die Stammdatenqualität? Diese Matrix gehört nicht in eine Schublade, sondern als verbindliche Anlage in die Verträge mit den Dienstleistern. Erst wenn die Vertragswerke der einzelnen Parteien dieselbe Zuordnung spiegeln, ist die Verantwortung lückenlos und überschneidungsfrei geschnitten. Eine sorgfältig erstellte RACI-Matrix deckt zudem schon beim Erstellen die Stellen auf, an denen sich niemand zuständig fühlt oder an denen sich mehrere überlappen, also genau die Lücken, die sonst erst im Schadensfall sichtbar würden.

Zwei vertragliche Vorkehrungen ergänzen die Matrix sinnvoll. Erstens ein definierter Eskalationspfad, der festlegt, über welche Stufen und in welchen Fristen eine ungelöste Störung nach oben gereicht wird. Zweitens eine Regelung zur Mitwirkungspflicht, die alle Parteien verpflichtet, an der Ursachenklärung mitzuwirken, auch wenn am Ende eine andere Partei verantwortlich ist. Ohne diese Mitwirkungspflicht kann sich ein Dienstleister auf den formalen Standpunkt zurückziehen, das Problem liege nicht in seinem Bereich, und jede gemeinsame Diagnose verweigern.

Subunternehmer und Partnerketten: die verdeckte Tiefe der Kette

Eine Komplikation bleibt selbst bei sauberem RACI-Schnitt bestehen: Die Parteien, mit denen Sie Verträge schließen, erbringen ihre Leistung oft nicht vollständig selbst. Der Implementierungspartner zieht für spezielle Erweiterungen einen Spezialisten hinzu, der Betreiber bezieht seine Rechenleistung von einem Hyperscaler, der Hersteller lagert Teile seines Supports aus. Aus Ihrer scheinbar überschaubaren Vier-Rollen-Konstellation wird so eine mehrstufige Kette, deren tiefere Glieder Sie vertraglich gar nicht erreichen.

Das birgt zwei konkrete Risiken. Zum einen das Durchgriffsproblem: Versagt ein Subunternehmer, haben Sie keinen direkten Vertrag mit ihm und müssen sich darauf verlassen, dass Ihr Vertragspartner seine Subunternehmer wirksam steuert und für deren Leistung einsteht. Zum anderen das Konsistenzproblem: Die Service-Zusagen, die Ihr Partner Ihnen gibt, sind nur belastbar, wenn er sie nach unten an seine Subunternehmer durchreicht. Sagt Ihnen Ihr Partner eine Reaktion binnen vier Stunden zu, hat aber mit seinem eigenen Cloud-Lieferanten nur acht Stunden vereinbart, ist seine Zusage an Sie im Ernstfall nicht haltbar. Worauf Sie deshalb achten sollten:

1. Transparenz über die Kette: Lassen Sie sich offenlegen, welche wesentlichen Leistungsteile an Subunternehmer vergeben werden. Eine Kette, deren Glieder Sie nicht kennen, können Sie nicht bewerten.
2. Durchgereichte Service-Zusagen: Stellen Sie sicher, dass die Ihnen gegebenen Zusagen vertraglich nach unten gespiegelt sind, sodass kein Subunternehmer eine schwächere Verpflichtung hat als das, was Ihnen versprochen wurde.
3. Haftung des Hauptauftragnehmers: Vereinbaren Sie, dass Ihr direkter Vertragspartner für das Verschulden seiner Subunternehmer wie für eigenes einsteht. Sonst verpufft die Haftung an der ersten Kettengrenze.
4. Wechselfähigkeit und Datenzugriff: Klären Sie, ob und wie Sie im Konfliktfall einen Subdienstleister wechseln können und ob Sie jederzeit ungehinderten Zugriff auf Ihre eigenen Daten behalten, unabhängig davon, wo in der Kette sie physisch liegen.

Gerade im Mittelstand, wo selten ein eigenes großes IT-Team alle Rollen intern abdeckt, ist diese Kettentiefe der Regelfall und nicht die Ausnahme. Die bewusste Steuerung dieser Liefer- und Betriebskonstellation ist damit ein Dauerthema, das weit über die Einführung hinausreicht; sie prägt, ob eine ERP-Lösung über Jahre verlässlich verfügbar bleibt oder zur Quelle wiederkehrender Reibung wird, besonders in Umgebungen, in denen die ERP-Auswahl für den Mittelstand ohnehin mit knappen internen Ressourcen geplant werden muss.

Zusammenführung: Verantwortung ist die eigentliche Lieferung

Wer eine ERP-Lösung betreibt, kauft nicht nur Software, sondern eine über Jahre tragfähige Verantwortungsarchitektur. Die vier Grundrollen, Hersteller, Implementierungspartner, Betriebsdienstleister und internes Team, müssen so zusammenspielen, dass an jeder Schnittstelle klar ist, wer ausführt, wer entscheidet und wer im Störungsfall den ersten Blick wirft. Das Shared-Responsibility-Modell des Cloud-Betriebs verschiebt die Grenze zwischen Ihnen und dem Anbieter je nach Bezugsmodell, beseitigt aber nie den harten Kern an Verantwortung, der bei Ihnen bleibt. Eine durchdachte RACI-Matrix, abgestimmte Service-Zeiten, ein definierter Eskalationspfad und Transparenz über die Subunternehmerkette verwandeln eine fragile Lieferantenkette in ein belastbares Betriebsmodell. Die eigentliche Lieferung einer ERP-Lösung ist damit nicht der Programmcode, sondern die saubere, lückenlose Zuordnung von Verantwortung über alle Beteiligten hinweg.

Service-Level richtig schneiden: SLA, Reaktionszeiten und Verfügbarkeit verstehen

Ein Service-Level-Agreement, kurz SLA, ist der Teil des Vertragswerks, der nicht beschreibt, was die Software kann, sondern wie verlässlich sie betrieben und betreut wird. Es übersetzt das Versprechen eines reibungslosen Betriebs in messbare, einklagbare Zusagen: wie schnell jemand auf eine Störung reagiert, wie lange die Behebung dauern darf, zu welchen Zeiten überhaupt Hilfe verfügbar ist und wie oft das System ausfallen darf, ohne dass die Zusage verletzt wird. Wer eine ERP-Lösung beschafft, prüft die fachliche Eignung meist gründlich, behandelt das SLA dagegen oft als Anhang, den man unterschreibt, ohne seine Mechanik verstanden zu haben. Genau in dieser Mechanik liegen aber die Beträge, die im Störungsfall über Stillstand oder Weiterarbeit entscheiden.

Dieser Abschnitt bleibt streng auf der Ebene der Service-Qualität. Es geht nicht um die Frage, wer im Liefermodell welche Rolle übernimmt, und nicht um die Wartung als Lebenszyklus-Thema, sondern allein darum, wie die Güte des laufenden Betriebs messbar formuliert, geprüft und durchgesetzt wird. Die Begriffe wirken auf den ersten Blick selbsterklärend, doch fast jeder von ihnen birgt eine definitorische Falle, die ein scheinbar starkes SLA im Ernstfall entwertet. Wer die Lösung als Ganzes bewertet, sollte das SLA mit derselben Sorgfalt lesen wie die Funktionsliste; die übergeordnete Einordnung dazu liefert die Betrachtung der ERP-Lösung als Gesamtpaket.

Reaktionszeit, Reaktion und Lösungszeit: drei Begriffe, die nicht dasselbe meinen

Der häufigste und teuerste Irrtum betrifft das Wort Reaktionszeit. Viele Leser verstehen darunter intuitiv die Zeit, bis ein Problem behoben ist. Vertraglich bedeutet sie fast immer etwas völlig anderes: die Zeit, bis der Anbieter den Eingang einer Meldung bestätigt und mit der Bearbeitung beginnt. Eine zugesicherte Reaktionszeit von einer Stunde garantiert also nur, dass sich innerhalb einer Stunde jemand der Sache annimmt, nicht, dass das System nach einer Stunde wieder läuft. Diese Unterscheidung klingt formal, entscheidet aber im Ernstfall über die Erwartung des Betriebs.

Sauber geschnittene SLA trennen deshalb drei Größen klar voneinander. Die Reaktionszeit ist die Frist von der qualifizierten Meldung bis zur Eingangsbestätigung und zum Beginn der Bearbeitung. Die Lösungszeit ist die Frist bis zur endgültigen Behebung der Ursache, also bis das Problem dauerhaft beseitigt ist. Dazwischen liegt eine dritte, oft unterschätzte Größe: die Workaround-Zeit oder Umgehungszeit, also die Frist, bis eine behelfsmäßige Lösung den Betrieb wieder arbeitsfähig macht, auch wenn die eigentliche Ursache noch offen ist. Für den Anwender ist diese mittlere Größe häufig die wichtigste, denn sie entscheidet, wie lange tatsächlich nicht gearbeitet werden kann.

Bei der Lösungszeit lauert eine weitere Falle. Anders als die Reaktion liegt die endgültige Behebung nicht immer vollständig in der Hand des Anbieters, etwa wenn ein Hersteller-Patch nötig ist oder die Ursache in einem Drittsystem liegt. Seriöse Verträge sichern deshalb häufig keine harte Lösungszeit zu, sondern eine Workaround-Zeit kombiniert mit einer Bearbeitungspflicht nach bestem Bemühen. Wer dagegen eine feste Lösungszeit in den Vertrag schreibt, ohne die Abhängigkeiten zu klären, erhält eine Zusage, die der Anbieter nicht halten kann und die im Streitfall ins Leere läuft. Die Kunst des SLA-Schnitts besteht darin, die richtige der drei Größen mit einer Frist zu belegen, die wirklich beeinflussbar ist.

Servicezeiten und Supportfenster: wann die Uhr überhaupt läuft

Jede Frist ist nur so gut wie das Zeitfenster, in dem sie zählt. Die Servicezeit oder das Supportfenster definiert, wann der Anbieter überhaupt erreichbar und zur Reaktion verpflichtet ist. Ein klassisches Fenster lautet 8 mal 5, also acht Stunden an fünf Werktagen, ein erweitertes 12 mal 5 oder 12 mal 7, der höchste Ausbau 24 mal 7, also rund um die Uhr an allen Tagen. Diese Angabe ist deshalb so folgenreich, weil die zugesicherten Fristen in aller Regel nur innerhalb der Servicezeit laufen. Die Uhr pausiert außerhalb des Fensters.

Daraus ergibt sich ein Effekt, den viele unterschätzen. Fällt das System Freitagabend nach Ende eines 8-mal-5-Fensters aus, beginnt die zugesicherte Reaktionszeit von einer Stunde erst am Montagmorgen zu laufen. Aus einer auf dem Papier sehr kurzen Frist wird real ein ganzes Wochenende Stillstand, ohne dass das SLA verletzt wäre. Ein Unternehmen, das auch außerhalb klassischer Bürozeiten produziert, im Versand arbeitet oder international tätig ist, muss die Servicezeit deshalb an seinen tatsächlichen Betriebszeiten ausrichten, nicht an einer Standardvorlage. Die Servicezeit ist der stille Multiplikator jeder Frist, und ein knappes Reaktionsversprechen in einem schmalen Fenster ist weniger wert als eine moderate Frist in einem breiten Fenster.

Prioritätsklassen: warum nicht jede Störung gleich behandelt wird

Ein flaches SLA mit einer einzigen Frist für alle Vorfälle ist entweder zu teuer oder zu schwach. Zu teuer, wenn jede Kleinigkeit mit der höchsten Dringlichkeit behandelt werden muss; zu schwach, wenn ein vollständiger Ausfall dieselbe Frist erhält wie ein kosmetischer Anzeigefehler. Deshalb staffeln tragfähige Vereinbarungen die Vorfälle in Prioritäts- oder Severity-Klassen, üblicherweise vier, von P1 bis P4. Jeder Klasse werden eigene Reaktions- und Workaround-Zeiten zugeordnet, sodass die knappen, teuren Fristen für die wirklich kritischen Fälle reserviert bleiben.

Entscheidend ist, dass die Einstufung anhand der Geschäftsauswirkung erfolgt, nicht anhand der technischen Symptomatik. Maßgeblich ist, wie viele Anwender betroffen sind, ob ein Geschäftsprozess vollständig steht und ob es eine zumutbare Umgehung gibt. Ein Systemausfall, der die gesamte Auftragsabwicklung lahmlegt, ist P1, weil das Geschäft steht; ein Fehler in einem selten genutzten Auswertungslauf bleibt P3 oder P4, auch wenn er technisch komplex ist. Mindestens ebenso wichtig wie die Klassen selbst ist die Festlegung, wer die Einstufung vornimmt. Definiert allein der Anbieter die Priorität, kann er teure Fälle herabstufen; definiert allein der Kunde, droht eine Inflation der höchsten Stufe. Bewährt hat sich eine gemeinsame Einstufung mit klaren, im Vertrag verankerten Kriterien und einem Eskalationsweg für den Streitfall.

Verfügbarkeit: was die Neunen real bedeuten

Die Verfügbarkeit ist die am häufigsten beworbene und zugleich am häufigsten missverstandene Kennzahl. Sie gibt den Anteil der Zeit an, in dem das System nutzbar sein muss, und wird in Prozent mit einer wachsenden Zahl von Neunen ausgedrückt. Der Sprung von einer Neun zur nächsten klingt klein, verändert die zulässige Ausfallzeit aber dramatisch. Bei 99 Prozent, den sogenannten zwei Neunen, sind über ein Jahr gerechnet rund drei Tage und sechzehn Stunden Ausfall erlaubt. Bei 99,9 Prozent, drei Neunen, schrumpft dieser Spielraum auf knapp neun Stunden, also etwa einen langen Arbeitstag. Bei 99,99 Prozent, vier Neunen, bleiben über das ganze Jahr nur noch rund zweiundfünfzig Minuten. Jede zusätzliche Neun reduziert die erlaubte Ausfallzeit ungefähr um den Faktor zehn und treibt den Betriebsaufwand entsprechend in die Höhe.

Aus dieser Mechanik folgt eine nüchterne Einsicht: Mehr Neunen sind nicht automatisch besser, sondern vor allem teurer. Die Frage ist nicht, welche Verfügbarkeit technisch maximal möglich ist, sondern welche der Geschäftsbetrieb wirklich braucht. Ein Unternehmen, dessen ERP-Lösung im Schichtbetrieb durchläuft, hat einen anderen Bedarf als eines, das ausschließlich zu Bürozeiten arbeitet. Es lohnt sich, die geforderte Verfügbarkeit gegen die Kosten ihrer Absicherung abzuwägen, statt reflexhaft die höchste Stufe zu verlangen. Diese Abwägung gehört in eine fundierte ERP-Auswahl, weil sie unmittelbar auf Architektur und Betriebskosten der Lösung durchschlägt.

Mindestens so wichtig wie die Prozentzahl ist die Definition ihrer Bezugsgrößen. Über welchen Zeitraum wird gemessen, über den Monat oder das Jahr? Eine monatliche Messung ist strenger, weil ein einzelner langer Ausfall sich nicht über ein ganzes Jahr verdünnen lässt. Zählt nur die Servicezeit oder die volle Kalenderzeit? Werden geplante Wartungsfenster aus der Berechnung herausgerechnet? Und was genau gilt als verfügbar – reicht es, dass die Anmeldemaske erscheint, oder müssen die geschäftskritischen Funktionen tatsächlich nutzbar sein? Ohne präzise Antworten auf diese Fragen ist eine Verfügbarkeitszusage eine Zahl ohne Aussagekraft.

Wartungsfenster: geplante Unterbrechungen sauber abgrenzen

Kein System läuft ohne planmäßige Unterbrechungen für Updates, Sicherungen oder Infrastrukturarbeiten. Diese Wartungsfenster werden in nahezu allen SLA aus der Verfügbarkeitsberechnung herausgenommen, weil sie angekündigt und kontrolliert stattfinden. Das ist sachlich richtig, schafft aber ein Einfallstor, wenn die Fenster nicht eng definiert sind. Ein SLA, das geplante Wartung ausnimmt, ohne deren Häufigkeit, Dauer, Vorankündigungsfrist und Lage zu begrenzen, lässt dem Anbieter die Möglichkeit, faktische Ausfallzeit als Wartung zu deklarieren und die Verfügbarkeitsstatistik damit zu schönen.

Belastbare Vereinbarungen schreiben deshalb fest, wann Wartung stattfinden darf, etwa in verkehrsarmen Nachtstunden oder am Wochenende, wie lange sie maximal dauern und mit welcher Frist sie anzukündigen ist. Ebenso gehört geregelt, wie mit dringenden, ungeplanten Sicherheitsmaßnahmen umgegangen wird, die sich nicht in das reguläre Fenster legen lassen. Erst diese Begrenzung verhindert, dass das Wartungsfenster zur stillen Hintertür der Verfügbarkeitszusage wird.

Pönalen und Service-Credits: die Zusage mit Konsequenz hinterlegen

Eine Zusage ohne Folge bei Nichterfüllung ist eine Absichtserklärung, kein Service-Level. Damit ein SLA Wirkung entfaltet, müssen Verletzungen Konsequenzen haben. Üblich sind Service-Credits, also Gutschriften auf die Servicegebühr, die mit dem Ausmaß der Unterschreitung steigen, oder Pönalen im Sinne von Vertragsstrafen. Ihr Zweck ist nicht in erster Linie der finanzielle Ausgleich des Schadens – dafür sind die Beträge meist zu gering –, sondern die Steuerungswirkung: Sie geben dem Anbieter einen messbaren Anreiz, die zugesagten Werte einzuhalten, und sie machen die Zusage überhaupt erst ernst.

Beim Schnitt dieser Klauseln kommt es auf mehrere Punkte an. Die Credits sollten gestaffelt sein, also mit dem Grad der Verfehlung wachsen, damit kleine und große Verletzungen nicht gleich behandelt werden. Sie sollten an die wirklich geschäftskritischen Kennzahlen geknüpft sein, nicht an leicht erfüllbare Nebengrößen. Und es muss geklärt sein, ob sie automatisch gewährt werden oder vom Kunden aktiv geltend gemacht werden müssen – eine Gutschrift, die nur auf ausdrückliche Anforderung gewährt wird, verfällt in der Praxis häufig. Wichtig ist zugleich ein realistischer Blick: Service-Credits ersetzen keinen Schadenersatz und schon gar nicht den entgangenen Geschäftswert eines langen Ausfalls. Sie sind ein Steuerungsinstrument, kein Versicherungsschutz.

Reporting: messbar und prüfbar statt gefühlt

Ein Service-Level, dessen Einhaltung niemand misst, existiert nur auf dem Papier. Deshalb gehört zu jedem belastbaren SLA ein Reporting, das die zugesagten Kennzahlen regelmäßig und nachvollziehbar ausweist: erreichte Verfügbarkeit im Berichtszeitraum, Zahl der Vorfälle je Prioritätsklasse, eingehaltene und verfehlte Reaktions- und Workaround-Zeiten sowie eine Übersicht der Wartungsfenster. Entscheidend ist, dass die Datenquelle und die Messmethode definiert sind und idealerweise vom Kunden eingesehen oder unabhängig nachvollzogen werden können. Misst allein der Anbieter mit eigenen Werkzeugen und ohne Einblick für den Kunden, bleibt die Einhaltung eine Behauptung.

Damit Kennzahlen prüfbar werden, müssen sie nach dem bekannten Grundsatz spezifisch, messbar und mit einem klaren Bezugszeitraum versehen sein. Eine Formulierung wie „schnelle Reaktion auf kritische Störungen“ ist wertlos, weil weder schnell noch kritisch definiert ist. Prüfbar wird sie erst als: Reaktion innerhalb von dreißig Minuten auf P1-Vorfälle, gemessen vom Zeitpunkt der qualifizierten Meldung über das definierte Ticketsystem, innerhalb der vereinbarten Servicezeit, ausgewiesen im monatlichen Bericht. Jede dieser Komponenten – Frist, Klasse, Startpunkt der Messung, Kanal, Zeitfenster, Berichtsrhythmus – muss benannt sein, sonst lässt sich die Einhaltung weder feststellen noch durchsetzen.

Teure Lücken: was im SLA gern fehlt

Die größten Risiken eines SLA liegen selten in einer zu langen Frist, sondern in dem, was es nicht regelt. Eine erste, regelmäßig teure Lücke sind ausgenommene Drittsysteme. Eine ERP-Lösung läuft kaum isoliert; sie hängt an Netzwerk, Datenbank, Betriebssystem, an Schnittstellen zu angedockten Systemen und oft an externen Diensten. Wenn das SLA nur die ERP-Anwendung im engeren Sinne abdeckt und alles darunter oder daneben ausnimmt, kann der Anbieter im Störungsfall auf die nicht abgedeckte Schicht verweisen, während der Betrieb steht. Wo viele Systeme zusammenwirken, etwa in einem Verbund aus Spezialanwendungen, muss das SLA die Verantwortungsgrenzen entlang der gesamten Wirkungskette ziehen; die Architektur dahinter behandelt die Betrachtung zum ERP-System und seinem Zusammenspiel.

Eine zweite, oft folgenschwere Lücke betrifft die Wiederherstellung nach einem Datenverlust. Verfügbarkeitszusagen beschreiben, wie selten das System ausfallen darf, aber nicht, wie schnell und mit welchem Datenstand es nach einem schweren Vorfall wieder läuft. Dafür braucht es zwei eigene Kennzahlen: die RTO (Recovery Time Objective), also die maximal tolerierte Zeit bis zur Wiederherstellung, und die RPO (Recovery Point Objective), also den maximal tolerierten Datenverlust, gemessen als Zeitspanne zwischen letzter brauchbarer Sicherung und dem Ausfall. Fehlen RTO und RPO, kann ein Anbieter die Verfügbarkeit formal einhalten und nach einem Datenverlust dennoch tagelang mit veraltetem Datenstand wiederanlaufen, ohne das SLA zu verletzen. Gerade für mittelständische Unternehmen, die einen längeren Stillstand wirtschaftlich kaum tragen, sind diese beiden Werte zentral; die spezifischen Rahmenbedingungen dafür beleuchtet die Betrachtung zu ERP im Mittelstand.

Eine dritte Lücke entsteht durch unklare Eskalations- und Meldewege. Ein SLA, das nicht festlegt, über welchen Kanal eine Meldung als qualifiziert gilt, wer sie entgegennimmt und wie ein nicht behobener Vorfall die nächste Verantwortungsstufe erreicht, lässt die Fristen ins Leere laufen, weil schon der Startpunkt der Messung strittig ist. Wer ein SLA prüft, sollte daher nicht mit den großzügig beworbenen Verfügbarkeitsprozenten beginnen, sondern mit den Definitionen: Was zählt als Vorfall, wann startet die Uhr, in welchem Fenster läuft sie, was ist ausgenommen und was geschieht nach einem Datenverlust. Erst wenn diese Begriffe trennscharf geklärt sind, gewinnen die Zahlen darüber ihre Bedeutung – und erst dann beschreibt das SLA wirklich die Qualität, mit der die Lösung im Alltag betrieben und betreut wird.

Releasewechsel und Wartung: die Lösung über Jahre lebendig halten

Mit dem Go-Live ist eine ERP-Lösung nicht fertig, sondern gerade erst geboren. Was danach beginnt, ist ein Betriebszyklus, der so lange läuft, wie die Lösung im Einsatz ist: ein steter Wechsel aus Korrekturen, Funktionszuwächsen, größeren Versionssprüngen und dem unausweichlichen Auslaufen alter Stände. Wer diesen Zyklus unterschätzt, betreibt seine Lösung wie ein Auto, das nach dem Kauf nie wieder in die Werkstatt kommt. Es fährt eine Weile, doch irgendwann steht es, und dann ist die Reparatur teurer als jede regelmäßige Wartung gewesen wäre. Dieser Abschnitt betrachtet ausschließlich den wiederkehrenden Betriebszyklus nach dem Go-Live: das Lebenszyklus-Management der Gesamtlösung über Jahre. Die Erstimplementierung selbst, also der einmalige Weg ins produktive System, ist ein eigenes Thema, das wir auf der Seite zur ERP-Implementierung behandeln; hier geht es um alles, was danach in nie endender Wiederholung folgt.

Der Grund, warum dieses Thema in der Auswahlphase so leicht übersehen wird, ist psychologischer Natur. Vor dem Projekt steht die Frage der Funktion und des Preises im Vordergrund; die Frage, was es kostet und bedeutet, eine Lösung fünf, acht oder zwölf Jahre lang aktuell zu halten, wirkt abstrakt und fern. Doch genau diese laufende Pflege summiert sich über die Lebensdauer zu einem erheblichen Teil der Gesamtkosten und entscheidet darüber, ob eine Lösung mit dem Unternehmen mitwächst oder zu einem starren Klotz erstarrt, an dem sich jede Veränderung bricht.

Die drei Release-Arten: Patch, Minor, Major

Jeder Softwarehersteller liefert nach dem ursprünglichen Verkauf einen fortlaufenden Strom an Aktualisierungen. Diese lassen sich in drei Kategorien einordnen, die sich in Umfang, Risiko und Planungsaufwand grundlegend unterscheiden. Das Verständnis dieser Dreiteilung ist die Grundlage jeder vernünftigen Wartungsstrategie, weil jede Art einen anderen Umgang verlangt.

Der Patch ist die kleinste Einheit. Er behebt einen konkreten Fehler oder schließt eine Sicherheitslücke, ohne neue Funktionen einzuführen oder bestehendes Verhalten absichtlich zu verändern. Patches erscheinen häufig und in kurzen Abständen, sind in der Regel risikoarm und sollten zeitnah eingespielt werden, besonders wenn sie sicherheitsrelevant sind. Das verbleibende Risiko liegt nicht im Patch selbst, sondern darin, dass ein vermeintlich harmloser Fix unbeabsichtigte Nebenwirkungen in Ihren spezifischen Anpassungen entfaltet.

Das Minor-Release bringt neue Funktionen und Verbesserungen, hält dabei aber die grundlegende Architektur und meist auch die Schnittstellen weitgehend stabil. Solche Releases erscheinen periodisch, etwa halbjährlich oder jährlich, und erfordern bereits eine bewusste Planung: Neue Funktionen wollen bewertet, geschult und getestet werden, und vereinzelt ändert sich das Verhalten bestehender Abläufe. Der Aufwand ist überschaubar, aber nicht null.

Das Major-Release schließlich ist ein Versionssprung, der die Architektur, das Datenmodell oder die technische Plattform tiefgreifend verändern kann. Es ist kein Update, sondern ein eigenes Projekt mit Vorbereitung, Migration, umfassendem Test und oft erneuter Schulung. Hier steht das größte Risiko dem größten Nutzen gegenüber: Major-Releases bringen die substanziellen Neuerungen, brechen aber häufig mit alten Annahmen, sodass eigene Erweiterungen und Schnittstellen angepasst werden müssen. Wer ein Major-Release wie ein Minor-Release behandelt, unterschätzt es systematisch.

Cloud versus On-Premise: kontinuierlich oder schubweise

Die vielleicht wichtigste Weichenstellung für den Wartungszyklus ist die Frage, ob Sie die Lösung kontinuierlich aktualisiert bekommen oder selbst über den Zeitpunkt jedes Sprungs entscheiden. Diese Unterscheidung folgt im Kern aus dem Betriebsmodell und prägt den gesamten Rhythmus des Lebenszyklus.

Im Cloud-Modell mit Continuous Delivery liefert der Anbieter Aktualisierungen in einem festen, vom Anbieter vorgegebenen Rhythmus. Updates kommen regelmäßig und oft verpflichtend: Sie können einzelne Wellen meist nur begrenzt verschieben, aber nicht dauerhaft aussitzen. Der große Vorteil ist, dass Sie nie weit vom aktuellen Stand entfernt sind und das gefürchtete Einfrieren auf einer Uraltversion praktisch ausgeschlossen ist. Der Preis dafür ist ein dauerhafter, getakteter Pflichtrhythmus: Sie müssen kontinuierlich testen, weil jede Welle Ihr produktives System berührt, ob es Ihnen gerade passt oder nicht. Wartung wird hier zur Daueraufgabe in kleinen, häufigen Portionen.

Im On-Premise-Modell mit planbaren Upgrades entscheiden Sie selbst, wann Sie welchen Stand einspielen. Das verschafft maximale Kontrolle über den Zeitpunkt und erlaubt es, Upgrades um kritische Geschäftsphasen herum zu legen. Der Preis ist gegenläufig: Updates kommen nicht in kleinen Portionen, sondern schubweise in großen Sprüngen, und genau hier lauert die Versuchung, einen Sprung immer wieder zu verschieben, bis die Differenz zwischen Ihrem Stand und der aktuellen Version so groß geworden ist, dass das nächste Upgrade einem Neuprojekt gleicht. Welches Bezugsmodell für Ihr Haus das richtige ist, hängt von vielen Faktoren ab und ist auch eine Frage der grundsätzlichen ERP-Auswahl; für die Wartung zählt vor allem, dass beide Modelle eine Daueraufgabe erzeugen, nur in völlig unterschiedlichem Takt.

Support-Ende und die n-1-Politik: das Risiko des Einfrierens

Jeder Softwarestand hat ein Verfallsdatum. Der Hersteller wartet eine bestimmte Version nur über einen definierten Zeitraum, danach erreicht sie das Wartungs- und Supportende, im Fachjargon das End-of-Life. Ab diesem Stichtag liefert der Hersteller keine Fehlerkorrekturen mehr, und, was schwerer wiegt, keine Sicherheitspatches. Ein produktives System ohne Sicherheitspatches ist eine offene Tür, die sich über die Zeit immer weiter öffnet, weil neu entdeckte Schwachstellen nicht mehr geschlossen werden.

Viele Hersteller fassen ihre Supportzusagen in einer sogenannten n-1-Politik: Gewartet werden in der Regel die aktuelle Version und die unmittelbar vorhergehende, ältere Stände fallen aus dem Support. Diese Politik gibt Ihnen einen Korridor vor, innerhalb dessen Sie sich bewegen müssen, ohne den Anschluss zu verlieren. Wer dauerhaft mehr als eine Version zurückliegt, betreibt sein System auf eigenes Risiko und ohne Sicherheitsnetz.

Das eigentliche Drama heißt Einfrieren. Es entsteht selten durch eine bewusste Entscheidung, sondern durch wiederholtes Verschieben. Jedes einzelne Aufschieben eines Upgrades wirkt für sich genommen vernünftig, weil gerade andere Prioritäten drängen. In Summe aber wächst der Abstand zur aktuellen Version, die eigenen Anpassungen entfernen sich immer weiter vom unterstützten Standard, und irgendwann ist das Nachholen so aufwendig und riskant geworden, dass es niemand mehr anpacken will. Das System ist eingefroren: technisch noch lauffähig, aber ohne Support, ohne Sicherheits-Updates und unfähig, neue gesetzliche oder geschäftliche Anforderungen aufzunehmen. Aus einer wartbaren Lösung ist eine Altlast geworden, deren spätere Ablösung um ein Vielfaches teurer ist als regelmäßige Pflege gewesen wäre. Genau deshalb ist eine wartungsfreundlich gebaute Lösung, die ihre Anpassungen über die Konfiguration statt über tiefes Customizing löst, im Lebenszyklus so viel wert: Sie verträgt Versionssprünge, ohne bei jedem Schritt aufzubrechen.

Regressionstests und Testautomatisierung als Rückgrat der Wartung

Jede Aktualisierung birgt dieselbe Grundgefahr: Etwas, das gestern noch funktionierte, funktioniert nach dem Update nicht mehr. Diese unbeabsichtigte Verschlechterung heißt Regression, und der Test, der sie aufspürt, ist der Regressionstest. Sein Zweck ist nicht, neue Funktionen zu prüfen, sondern sicherzustellen, dass die bestehenden, geschäftskritischen Abläufe nach der Änderung weiterhin korrekt arbeiten. Der Auftragseingang, der Lagerabgang, der Rechnungslauf, die Schnittstelle zum Versanddienstleister: All das muss nach jedem Patch und jedem Release wieder genauso laufen wie zuvor.

Hier zeigt sich der entscheidende Unterschied zwischen den Betriebsmodellen in der Praxis. Im kontinuierlichen Cloud-Rhythmus kommen die Updates so häufig, dass ein vollständig manueller Regressionstest bei jeder Welle schlicht nicht mehr zu bewältigen ist. Wer halbjährlich oder häufiger ein verpflichtendes Update erhält, muss seine Kernprozesse so testen können, dass es nicht jedes Mal Wochen kostet. Die Antwort darauf ist Testautomatisierung: Die wichtigsten Geschäftsprozesse werden als automatisierte Testfälle hinterlegt, die per Knopfdruck durchlaufen und melden, ob etwas abweicht. Eine solche Test-Suite ist eine Investition, die sich erst über viele Updatezyklen amortisiert, aber im kontinuierlichen Modell von der Kür zur Pflicht wird.

Sinnvoll ist ein abgestufter Testumfang, der zum Risiko des jeweiligen Updates passt. Die folgende Tabelle zeigt diese Abstufung:

Unverzichtbar für jeden dieser Tests ist eine vom Produktivsystem getrennte Test- oder Staging-Umgebung, die dem produktiven Stand möglichst nahekommt. Ein Update direkt im Produktivsystem zu testen heißt, das Experiment am offenen Herzen durchzuführen. Erst wenn eine Aktualisierung in der Testumgebung sauber durchgelaufen ist, gehört sie ins Wartungsfenster der produktiven Lösung.

Update-Governance: Wer entscheidet, wann was eingespielt wird

Wartung darf kein Zufallsprodukt sein, das mal der eine, mal der andere nach Gutdünken anstößt. Sie braucht eine Update-Governance, also klar geregelte Verantwortlichkeiten und Abläufe für die Frage, welche Aktualisierung wann, von wem und nach welcher Prüfung in das produktive System gelangt. Ohne diese Regeln entsteht entweder Stillstand, weil sich niemand zuständig fühlt, oder Wildwuchs, weil Änderungen ungetestet eingespielt werden.

Eine belastbare Governance beantwortet mindestens vier Fragen verbindlich. Erstens: Wer sichtet eingehende Patches und Releases und bewertet ihre Relevanz und Dringlichkeit? Zweitens: Nach welchem Verfahren werden Aktualisierungen freigegeben, und wer erteilt diese Freigabe? Drittens: In welchen Wartungsfenstern werden sie eingespielt, abgestimmt auf umsatzschwache Zeiten? Viertens: Wie wird im Fehlerfall zurückgerollt, und ist dieser Rückweg vorher geprobt? Diese vier Punkte gehören in einen einfachen, aber verbindlichen Prozess:

1. Sichten und bewerten: Eingehende Updates werden erfasst und nach Dringlichkeit eingestuft, Sicherheitsbezug zuerst.
2. In der Testumgebung prüfen: Die Aktualisierung läuft zunächst gegen die Regressionstests in der getrennten Umgebung.
3. Freigeben: Eine benannte Stelle entscheidet auf Basis des Testergebnisses über die produktive Übernahme.
4. Im Wartungsfenster einspielen: Die Übernahme erfolgt geplant, mit vorbereitetem Rückfallplan.
5. Nachkontrollieren: Nach dem Einspielen wird der korrekte Betrieb der Kernprozesse aktiv bestätigt.

Wer diese Verantwortung trägt, hängt vom Liefermodell ab und überschneidet sich eng mit der Frage, wer im Betrieb welche Rolle ausfüllt. Wichtig für die Wartung ist allein, dass die Update-Governance als wiederkehrender Prozess existiert und nicht bei jedem Release neu erfunden wird.

Eigene Erweiterungen über Versionssprünge pflegen

Kaum eine Lösung läuft im reinen Auslieferungszustand. Fast immer gibt es eigene Erweiterungen, individuelle Schnittstellen oder spezielle Auswertungen, die genau auf das Unternehmen zugeschnitten sind. Diese Eigenanteile sind im laufenden Betrieb der heikelste Punkt jedes Versionssprungs, denn der Hersteller wartet seinen Standard, nicht Ihre Erweiterungen. Ändert ein Major-Release die zugrunde liegende Struktur, müssen Ihre Anpassungen nachgezogen werden, und genau dieser Aufwand wird bei der Budgetierung gern vergessen.

Der entscheidende Hebel liegt darin, wie eng eine Erweiterung mit dem Standard verwoben ist. Erweiterungen, die über klar definierte, vom Hersteller stabil gehaltene Schnittstellen andocken, überstehen Versionssprünge meist mit überschaubarem Aufwand. Erweiterungen dagegen, die tief in den Kern eingreifen und dessen Innenleben verändern, brechen bei jedem größeren Sprung und müssen aufwendig repariert werden. Welche Bauweise vorliegt, ist eine Architekturentscheidung, die im Detail auf der Seite zur wartbaren Lösung über Configuration behandelt wird; für den Wartungszyklus zählt die Konsequenz: Jede tief eingreifende Anpassung ist eine wiederkehrende Belastung bei jedem Versionssprung, die dauerhaft eingeplant werden muss. Praktisch bewährt sich ein gepflegtes Verzeichnis aller Eigenanteile, das festhält, was jede Erweiterung tut, woran sie andockt und wer sie pflegt. Eine Erweiterung, von der niemand mehr weiß, warum es sie gibt und woran sie hängt, wird beim nächsten Major-Release zur teuren Blackbox.

Laufende Wartung budgetieren: die Daueraufgabe einplanen

Die letzte und am häufigsten unterschätzte Konsequenz aus allem Vorhergehenden ist finanzieller Natur. Wartung ist keine einmalige Position, die mit dem Projektbudget abgegolten ist, sondern eine Daueraufgabe, die über die gesamte Lebensdauer der Lösung jährlich wiederkehrt. Wer den laufenden Wartungsaufwand nicht von Beginn an als festen Posten einplant, finanziert ihn später aus Notbudgets und unter Zeitdruck, was beides teurer und schlechter ist.

In ein realistisches Wartungsbudget gehören mehrere Komponenten, die über das Jahr verteilt anfallen. Dazu zählen die laufenden Lizenz- oder Abonnementkosten, der Aufwand für das Sichten, Testen und Einspielen von Patches und Minor-Releases, die Pflege und Anpassung der eigenen Erweiterungen über Versionssprünge hinweg, der Betrieb und die Pflege der Testautomatisierung, sowie ein gesondert ausgewiesener, größerer Posten für die periodisch anfallenden Major-Upgrade-Projekte. Gerade dieser letzte Posten ist tückisch, weil er nicht jedes Jahr anfällt, sondern in mehrjährigen Abständen, und deshalb gern aus der laufenden Planung verschwindet, bis er plötzlich als großer Brocken zurückkehrt.

Hilfreich ist es, den Wartungsaufwand gedanklich in zwei Schichten zu teilen: in einen gleichmäßigen Grundbetrag für die kontinuierliche Pflege, der jedes Jahr ähnlich ausfällt, und in eine Rücklage für die periodischen Großereignisse wie Major-Upgrades. Diese Zweiteilung verhindert, dass die ruhige Wartungsphase über die wartungsarmen Jahre den Blick auf das nächste teure Projekt verstellt. Besonders im Mittelstand, wo IT-Budgets knapp sind und selten ein großes internes Team alle Aufgaben abfedert, entscheidet diese vorausschauende Planung darüber, ob die Lösung über Jahre gepflegt mitwächst oder zwischen den Budgetrunden langsam veraltet.

Zusammenführung: Lebendig bleibt, was bewusst gepflegt wird

Eine ERP-Lösung bleibt nicht von selbst auf der Höhe der Zeit; sie wird es nur durch bewusste, wiederkehrende Pflege. Die drei Release-Arten verlangen je eigenen Umgang, vom risikoarmen Patch bis zum projektartigen Major-Sprung. Das Betriebsmodell bestimmt den Takt: kontinuierlich und getaktet in der Cloud, schubweise und selbstbestimmt on-premise, doch in beiden Fällen als Daueraufgabe. Das Wartungs- und Supportende und die n-1-Politik markieren die harten Grenzen, innerhalb derer Sie sich bewegen müssen, um das schleichende Einfrieren zu vermeiden. Regressionstests und ihre Automatisierung sind das Rückgrat, das jeden Sprung absichert; eine klare Update-Governance gibt ihm einen verlässlichen Ablauf; die bewusste Pflege der eigenen Erweiterungen verhindert, dass jeder Versionssprung zur Reparaturorgie wird. Und über allem steht das nüchterne Eingeständnis, dass dies alles Geld kostet, jedes Jahr aufs Neue. Wer die laufende Wartung von Anfang an als festen Posten budgetiert und nicht als Störung des Tagesgeschäfts begreift, hält seine Lösung über Jahre lebendig, statt sie still zu einer Altlast werden zu lassen.

Häufige Fragen