SAP Integration oder Systemwechsel: Was lohnt sich?

Ein neues Kundenportal soll Aufträge direkt ins SAP übertragen. Eine mobile Anwendung benötigt aktuelle Bestandsdaten. Oder ein Vertriebsteam arbeitet noch mit Excel, weil das vorhandene System zu unflexibel ist. Bei solchen Vorhaben stellt sich früh die entscheidende Frage: SAP Integration oder Systemwechsel? Die Antwort beeinflusst nicht nur Budget und Projektlaufzeit, sondern auch Prozessqualität, Datenhoheit und die Fähigkeit, neue digitale Produkte langfristig weiterzuentwickeln.

Ein Systemwechsel wirkt häufig wie der konsequente Neuanfang. Eine Integration erscheint dagegen als der risikoärmere Weg. Beide Annahmen können zutreffen, müssen es aber nicht. Entscheidend ist, welches Problem das Unternehmen tatsächlich lösen will und welche Rolle SAP künftig in der eigenen Systemlandschaft spielen soll.

SAP Integration oder Systemwechsel richtig einordnen

SAP ist in vielen Organisationen der zentrale Ort für Stamm-, Bewegungs- und Finanzdaten. Es steuert Beschaffung, Produktion, Logistik, Auftragsabwicklung oder Rechnungswesen. Gerade deshalb ist SAP selten das System, das man ohne Folgen ersetzt. Gleichzeitig ist es nicht automatisch die richtige Grundlage für jedes digitale Nutzererlebnis, jeden Vertriebskanal oder jeden automatisierten Fachprozess.

Eine SAP-Integration verbindet bestehende Prozesse und Daten mit einer neuen Anwendung, Plattform oder einem Drittsystem. Das kann eine Web-App für Kunden, ein Portal für Lieferanten, eine mobile Service-App oder eine spezialisierte KI-Anwendung sein. SAP bleibt dabei führend für klar definierte Daten und Transaktionen, während die neue Lösung eine moderne, auf den jeweiligen Anwendungsfall zugeschnittene Oberfläche und Logik bereitstellt.

Ein Systemwechsel ersetzt dagegen ein bestehendes System ganz oder in wesentlichen Teilen. Das kann sinnvoll sein, wenn die fachliche Basis nicht mehr passt, Betrieb und Anpassungen unverhältnismäßig aufwendig werden oder der Hersteller keine tragfähige Zukunftsperspektive bietet. Ein Wechsel ist jedoch mehr als ein technisches Migrationsprojekt. Er betrifft Verantwortlichkeiten, Datenqualität, Berechtigungen, Schulungen und etablierte Arbeitsabläufe.

Die zentrale Frage lautet daher nicht: „Was ist moderner?“ Sondern: Wo soll die geschäftskritische Wahrheit künftig liegen, und welche Architektur unterstützt die Wachstumsziele mit vertretbarem Risiko?

Wann eine SAP-Integration der bessere Weg ist

Eine Integration ist meist sinnvoll, wenn SAP fachlich stabil läuft und die Einschränkung an anderer Stelle liegt. Das ist häufig der Fall, wenn Mitarbeitende, Kunden oder Partner einen einfacheren Zugang zu Prozessen benötigen, ohne dass die zugrunde liegende ERP-Logik ersetzt werden muss.

Ein typisches Beispiel ist ein B2B-Kundenportal. Kunden sollen Verfügbarkeiten prüfen, Ersatzteile bestellen, Lieferstatus einsehen oder Rechnungen abrufen. Diese Informationen stammen oft aus SAP. Die Portal-Anwendung muss jedoch eine schnelle Suche, individuelle Rechte, verständliche Prozesse und ein konsistentes Nutzererlebnis bieten. Statt die ERP-Oberfläche nach außen zu öffnen, wird eine eigenständige Anwendung entwickelt, die über definierte Schnittstellen auf relevante SAP-Daten zugreift.

Auch bei mobilen Anwendungen ist dieses Modell überzeugend. Servicetechniker benötigen etwa Arbeitsaufträge, Materialinformationen und die Möglichkeit, Rückmeldungen direkt vor Ort zu erfassen. Eine App kann offlinefähig sein, Kamerafunktionen einbinden und Arbeitsschritte erheblich vereinfachen. SAP übernimmt weiterhin die Abrechnung, Materialbuchung oder Auftragsverwaltung. Die App ergänzt das System dort, wo Geschwindigkeit und Bedienbarkeit entscheidend sind.

Eine Integration schafft außerdem Raum für schrittweise Modernisierung. Statt mehrere Kernprozesse gleichzeitig anzufassen, kann ein Unternehmen zunächst einen klar abgegrenzten Anwendungsfall produktiv umsetzen. Das reduziert das Projektrisiko und liefert schneller messbare Ergebnisse. Voraussetzung ist allerdings, dass die Schnittstellen, Datenmodelle und Verantwortlichkeiten sauber geplant werden.

Integration ist kein bloßer Datenaustausch

Viele Integrationsprojekte scheitern nicht an einer fehlenden API, sondern an unklaren Regeln. Welche Anwendung darf Daten ändern? Welche Daten werden in Echtzeit benötigt, welche dürfen zeitversetzt synchronisiert werden? Wie werden Fehler erkannt und erneut verarbeitet? Was passiert, wenn SAP temporär nicht verfügbar ist?

Eine belastbare Architektur trennt die Nutzeranwendung von der SAP-spezifischen Logik. Eine Integrationsschicht oder ein Backend kann Daten aufbereiten, Berechtigungen prüfen, Prozesse orchestrieren und Zugriffe absichern. Dadurch bleibt die neue Anwendung wartbar, auch wenn sich SAP-Strukturen, externe Systeme oder Anforderungen später verändern.

Besonders relevant ist das bei skalierenden Plattformen. Wenn viele Kunden gleichzeitig auf Statusdaten zugreifen oder Bestellungen auslösen, darf die Last nicht unkontrolliert auf das ERP treffen. Caching, asynchrone Verarbeitung und klar definierte Schnittstellen sind dann keine technischen Details, sondern Voraussetzungen für verlässliche Prozesse.

Wann ein Systemwechsel gerechtfertigt ist

Ein Wechsel sollte nicht erfolgen, weil eine Oberfläche alt aussieht oder einzelne Abläufe unbequem sind. Solche Probleme lassen sich oft durch gezielte Erweiterungen, moderne Frontends oder die Neuordnung von Prozessen lösen. Ein Systemwechsel wird dann plausibel, wenn das bestehende System die fachliche Entwicklung dauerhaft blockiert.

Das zeigt sich beispielsweise, wenn zentrale Anforderungen nur mit kostspieligen Sonderlösungen abbildbar sind, Datenstrukturen kaum nachvollziehbar sind oder die Wartung einzelner Anpassungen jedes Release zum Risiko macht. Auch fehlende Herstellerunterstützung, schwer beherrschbare Sicherheitsrisiken oder erhebliche Performanceprobleme können einen Wechsel notwendig machen.

In manchen Fällen ist nicht SAP selbst der Kandidat für eine Ablösung, sondern eine historisch gewachsene Umgebung darum herum: ein separates CRM, ein Eigenbau für die Auftragssteuerung oder eine Access-Datenbank, die zu einem kritischen Fachsystem geworden ist. Gerade diese Schattenprozesse verursachen häufig Medienbrüche, manuelle Nacharbeit und widersprüchliche Datenstände.

Ein Wechsel lohnt sich vor allem dann, wenn das Zielbild klarer und einfacher ist als der Ist-Zustand. Wer ein altes System lediglich nachbaut, übernimmt oft dessen Komplexität in eine neue Technologie. Vor der Produktauswahl oder Entwicklung sollten Unternehmen deshalb klären, welche Prozesse künftig wirklich benötigt werden, welche Daten führend sein sollen und welche Sonderfälle bewusst entfallen können.

Die Kosten eines Wechsels realistisch bewerten

Die Lizenz- oder Entwicklungskosten sind nur ein Teil der Rechnung. Hinzu kommen Datenbereinigung, Migration, Testaufwand, Change Management, Schulungen und der parallele Betrieb während der Umstellung. Kritisch wird es, wenn implizites Wissen ausschließlich bei langjährigen Mitarbeitenden oder externen Dienstleistern liegt.

Gleichzeitig darf der Status quo nicht als kostenlos gelten. Manuelle Korrekturen, langsame Bearbeitungszeiten, Ausfälle und schwer verfügbare Fachkenntnisse verursachen ebenfalls laufende Kosten. Eine fundierte Entscheidung betrachtet daher nicht nur das Projektbudget, sondern die Gesamtbetriebskosten über mehrere Jahre sowie die wirtschaftlichen Folgen entgangener Digitalisierungsmöglichkeiten.

Ein Entscheidungsrahmen für die Praxis

Für die Bewertung empfiehlt sich kein pauschales Entweder-oder, sondern eine strukturierte Analyse entlang weniger Fragen. Wenn mindestens mehrere dieser Punkte kritisch ausfallen, sollte ein Systemwechsel oder eine größere Neuordnung ernsthaft geprüft werden:

• Unterstützt das bestehende System die Kernprozesse fachlich noch ohne dauerhafte Workarounds?
• Sind die benötigten Daten über dokumentierte und wartbare Schnittstellen verfügbar?
• Ist klar definiert, welches System für Kunden-, Produkt-, Auftrags- und Finanzdaten führend ist?
• Lassen sich neue digitale Angebote entwickeln, ohne den stabilen ERP-Betrieb zu gefährden?
• Sind Wartung, Sicherheitsupdates und Weiterentwicklung auch in drei bis fünf Jahren realistisch planbar?

Fällt die Bewertung überwiegend positiv aus, spricht viel für eine SAP-Integration. Dann liegt der größte Hebel meist in einer gut konzipierten Anwendung und einer sauberen technischen Anbindung. Fällt sie negativ aus, reicht eine zusätzliche Oberfläche nicht aus. Dann sollte die Organisation zunächst ein belastbares Zielbild für Prozesse, Daten und Systemverantwortung entwickeln.

Der hybride Weg ist oft der wirtschaftlichste

In der Praxis besteht die beste Lösung häufig aus beidem: SAP bleibt das ERP-System für stabile Kernprozesse, während neue Anwendungen einzelne Bereiche modernisieren. Ein Kundenportal, eine Service-App oder ein Workflow-System kann dabei unabhängig wachsen. Alte Ergänzungssysteme werden nach und nach abgelöst, sobald ihre Funktionen kontrolliert in die neue Architektur überführt wurden.

Dieser Ansatz vermeidet den großen Umstellungstag und ermöglicht es, Veränderungen anhand realer Nutzung zu priorisieren. Gleichzeitig braucht er eine klare Architektur-Governance. Ohne verbindliche Schnittstellenstandards, Datenverantwortung und technische Dokumentation entstehen schnell neue Insellösungen.

Entscheider sollten deshalb nicht allein fragen, ob eine Schnittstelle technisch möglich ist. Wichtiger ist, ob die Integration dauerhaft betreibbar ist, ob sie die Fachbereiche entlastet und ob sie spätere Veränderungen erleichtert. entrecode begleitet solche Vorhaben von der Prozessanalyse und Architekturentscheidung bis zur Entwicklung, Integration und langfristigen Weiterentwicklung.

Die richtige Entscheidung entsteht nicht aus der Wahl zwischen „alt“ und „neu“. Sie entsteht aus einem Zielbild, in dem jedes System eine klare Aufgabe hat und Technologie den Geschäftsprozess messbar besser macht.