Nach dem SAP Go-Live: Betrieb, reale Kosten und versteckte Abhängigkeiten im Griff behalten

/in

Nach dem SAP Go-Live: Betrieb, reale Kosten und versteckte Abhängigkeiten im Griff behalten

Der Go-Live ist geschafft. Das Projekt gilt als erfolgreich. Die Projektleitung atmet durch, das Steering Committee applaudiert, die Berater beginnen mit dem Abbau. Und dann beginnt der Teil, über den im Projekt niemand sprechen wollte.

In nahezu jedem S/4HANA-Projekt konzentrieren sich Aufmerksamkeit, Budget und Steuerungsenergie auf drei Dimensionen: Scope, Timeline und Budget. Was dabei systematisch unterschätzt wird: Der eigentliche Lebenszyklus eines SAP-Systems beginnt erst nach dem Go-Live. Und genau dort entstehen die größten Kosten, die ernsthaftesten Risiken und die tiefsten Abhängigkeiten.

Phase 1: Hypercare – unterschätzt, oft chaotisch, entscheidend für die Akzeptanz

Die ersten Wochen nach Go-Live sind die härteste Belastungsprobe für jedes SAP-System. Nicht weil das System schlecht gebaut wurde, sondern weil der Produktivbetrieb eine andere Realität schafft als jede Testphase zuvor.

Was in dieser Phase typischerweise auftritt:

Unerwartete Prozessabbrüche. Abläufe, die in der Testumgebung problemlos funktioniert haben, scheitern plötzlich an Datenkombinationen, Volumen oder Benutzerverhalten, das im Test nicht abgebildet wurde. Die Ursachenanalyse kostet Zeit, die im laufenden Betrieb kaum vorhanden ist.

Performanceprobleme. Unter echter Last – hunderte Nutzer gleichzeitig, reale Datenmengen, parallele Hintergrundprozesse – verhält sich ein System anders als in der Qualitätssicherungsumgebung. Besonders in den ersten Wochen nach Go-Live können Antwortzeiten und Systemstabilität erheblich hinter den Erwartungen zurückbleiben.

Dateninkonsistenzen. Migrationsfehler, die im Test unentdeckt blieben, zeigen sich erst wenn Fachbereiche mit echten Geschäftsvorfällen arbeiten. Die Korrektur ist aufwändig und bindet Ressourcen, die eigentlich für die Stabilisierung gebraucht werden.

Das eigentliche Problem in dieser Phase ist struktureller Natur: Fachbereiche testen im Echtbetrieb – nicht mehr im Projekt. Anforderungen, die im Testbetrieb als erfüllt galten, werden im Arbeitsalltag plötzlich als unzureichend bewertet. Ohne ein strukturiertes Hypercare-Modell mit klaren Ticketprozessen, definierten Prioritätsstufen und eindeutigen Zuständigkeiten eskaliert diese Phase schnell – und das zu einem Zeitpunkt, an dem die Projektressourcen bereits abgebaut werden.

Phase 2: Stabilisierung – der unsichtbare Aufwand nach den ersten Wochen

Nach der akuten Hypercare-Phase beginnt die eigentliche Stabilisierungsarbeit. Sie ist weniger dramatisch als die ersten Wochen, aber langwieriger und in ihrer Gesamtbelastung oft unterschätzt.

Die typischen Aufgaben dieser Phase:

  • Prozessanpassungen: Abläufe, die konzeptionell sinnvoll waren, erweisen sich im Alltag als unpraktisch. Nutzer suchen Umgehungen, Key User melden Anpassungsbedarf, der im Projekt nicht sichtbar war.
  • Berechtigungsfeinschliff: Berechtigungskonzepte, die auf dem Papier vollständig wirkten, zeigen in der Praxis Lücken – zu restriktive Einschränkungen hier, unbeabsichtigte Zugriffsmöglichkeiten dort. Die Anpassung ist kleinteilig und zeitintensiv.
  • Reporting-Korrekturen: Berichte und Auswertungen, die im Test abgenommen wurden, liefern unter Produktivdaten abweichende Ergebnisse oder entsprechen nicht den tatsächlichen Informationsbedürfnissen der Entscheider.

Was dabei häufig passiert: Change Requests explodieren. Erfahrungsgemäß werden in dieser Phase 30 bis 50 Prozent der initialen Prozessdefinitionen angepasst. Die Gründe sind nachvollziehbar: Anforderungen waren im Projektverlauf nicht vollständig sichtbar, weil Nutzer abstrakte Konzepte erst im Arbeitsalltag wirklich verstehen. Und das tatsächliche Nutzerverhalten weicht fast immer von den Annahmen ab, die bei der Prozessmodellierung zugrunde lagen.

Ohne einen definierten Change-Management-Prozess – mit Aufwandsschätzung, Priorisierung und Freigabe – werden aus kleinen Anpassungswünschen kostspielige Folgeentwicklungen.

Phase 3: Dauerbetrieb – der größte Kostenblock im SAP-Lebenszyklus

Wer ein S/4HANA-System über fünf, zehn oder fünfzehn Jahre betreibt, stellt irgendwann fest: Die Projektkosten waren nicht der größte Posten. Der Betrieb ist es. In vielen Unternehmen entstehen 60 bis 80 Prozent der Gesamtkosten eines SAP-Systems nach dem Go-Live – verteilt auf drei zentrale Kostentreiber.

Application Management: Support, Weiterentwicklung und Release-Anpassungen

Das Application Management umfasst alles, was notwendig ist, damit ein SAP-System im Alltag funktioniert und mit veränderten Anforderungen Schritt hält: First- und Second-Level-Support für Anwenderprobleme, Weiterentwicklungen für neue fachliche Anforderungen und die kontinuierliche Anpassung an SAP-Releases und gesetzliche Änderungen.

Dieser Aufwand ist dauerhaft und wächst mit der Komplexität des Systems. Unternehmen, die ihn nicht von Anfang an in ihrer Kostenplanung verankern, sind regelmäßig überrascht.

Infrastrukturkosten – besonders bei RISE with SAP schwer transparent

Infrastrukturkosten sind im klassischen On-Premise-Betrieb gut planbar. In Cloud-Modellen – und besonders unter RISE with SAP – ist die Kostentransparenz geringer. Verbrauchsbasierte Komponenten, Add-on-Services und optionale Managed Services summieren sich zu Beträgen, die sich ohne aktives Monitoring und Kostensteuerung schwer kontrollieren lassen. Detailliertere Einblicke dazu bietet unser Beitrag zu den kritischen Herausforderungen von RISE with SAP.

Externe Abhängigkeiten: Berater, Integrationsplattformen, Add-ons

Der dritte Kostentreiber ist oft der am wenigsten sichtbare: die Abhängigkeit von externen Partnern. Beratungsunternehmen für Weiterentwicklungen, Lizenzkosten für Integrationsplattformen und Drittanbieter-Add-ons, die bei der initialen Implementierung als notwendig bewertet wurden – all das summiert sich zu laufenden Kosten, die in Budgetplanungen häufig unterschätzt oder vergessen werden.

Die größte unterschätzte Abhängigkeit: institutionelles Wissen

Es gibt eine Abhängigkeit, die in keiner Kostenaufstellung auftaucht und die dennoch zu den teuersten Konsequenzen eines SAP-Projekts gehört: der Verlust von institutionellem Wissen nach Go-Live.

In der Praxis folgt ein bekanntes Muster: Das Projektteam löst sich auf. Berater verlassen das Unternehmen. Interne Projektmitglieder kehren in ihre Linienrollen zurück oder wechseln das Unternehmen. Das Wissen über Architekturentscheidungen, Konfigurationsgründe und Sonderlösungen, das in den Köpfen dieser Menschen gespeichert war, ist damit weitgehend verloren – und häufig nicht oder nur unzureichend dokumentiert.

Was bleibt: überforderte Key User, die plötzlich als primäre Wissensträger fungieren sollen, ohne dass ihre Rolle dafür ausgestattet wurde. Und eine wachsende Abhängigkeit von externen Dienstleistern, die bei jedem Problem neu eingeführt werden müssen und deren Einarbeitungsaufwand sich direkt in Kosten niederschlägt.

Was erfolgreiche Unternehmen nach dem Go-Live anders machen

Unternehmen, die ihren SAP-Betrieb langfristig im Griff behalten, teilen einige strukturelle Gemeinsamkeiten – und die meisten davon wurden nicht nach dem Go-Live entwickelt, sondern bereits im Projekt verankert.

Betriebsmodell vor Go-Live definieren. Wer ist nach Go-Live für was zuständig? Wie werden Support-Anfragen aufgenommen, priorisiert und bearbeitet? Welche Ressourcen stehen im Betrieb zur Verfügung, und wo beginnt die Grenze zum externen Dienstleister? Diese Fragen müssen beantwortet sein, bevor das System produktiv geht – nicht danach.

Wissen systematisch sichern. Dokumentation ist kein Luxus, sondern eine strategische Investition. Das gilt für Architekturentscheidungen ebenso wie für prozessuale Sonderfälle, Konfigurationsbegründungen und bekannte Einschränkungen. Ergänzend dazu: ein strukturiertes Key-User-Programm, das Wissen in der Organisation verankert und nicht von einzelnen Personen abhängig macht.

Klare Governance für Changes etablieren. Jede Systemänderung nach Go-Live sollte einen definierten Prozess durchlaufen: Anforderungsaufnahme, Bewertung, Priorisierung, Umsetzung, Test und Dokumentation. Was ad hoc und ohne Steuerung passiert, wird teuer und führt zu einem System, das mit der Zeit schwerer wartbar wird.

KPIs für den Betrieb definieren und messen. Was wird nicht gemessen, wird nicht gesteuert. Ticketvolumen, Durchlaufzeiten im Support, Systemverfügbarkeit, Change-Request-Backlog – wer diese Kennzahlen regelmäßig auswertet, erkennt Probleme früh und kann gegensteuern, bevor sie kostspielig werden.

Fazit: Der Betrieb entscheidet über den Projekterfolg

Der Go-Live ist kein Ziel – er ist ein Startpunkt. Was danach kommt, entscheidet darüber, ob ein SAP-Projekt langfristig als Erfolg oder als Belastung wahrgenommen wird.

Hypercare, Stabilisierung und Dauerbetrieb sind keine Randthemen für die IT-Abteilung. Sie sind strategisch relevante Phasen, die Planung, Ressourcen und Governance erfordern. Unternehmen, die das ernst nehmen, behalten Kontrolle über ihre Kosten und ihre Systemqualität. Unternehmen, die es dem Zufall überlassen, verlieren beides – schrittweise und oft unmerklich, bis der Handlungsdruck zu groß wird.

Ihren SAP-Betrieb nachhaltig und kosteneffizient aufstellen?

Wir unterstützen Sie beim Aufbau eines tragfähigen Betriebsmodells – von Anfang an. Von der Hypercare-Strukturierung über das Key-User-Konzept bis hin zur langfristigen Application-Management-Strategie begleiten wir Sie dabei, die Zeit nach Go-Live genauso professionell zu gestalten wie das Projekt selbst.

Jetzt Kontakt aufnehmen und den Grundstein für einen stabilen, kosteneffizienten SAP-Betrieb legen.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

RISE with SAP: 5 kritische Herausforderungen aus der Praxis

/in

RISE with SAP: 5 kritische Herausforderungen aus der Praxis

 

RISE with SAP verspricht Einfachheit: eine Vertragsbeziehung, ein Ansprechpartner, ein Weg in die Cloud. Die Realität in Projekten sieht differenzierter aus. Wer RISE als reines Hosting-Modell betrachtet, unterschätzt, was er tatsächlich kauft – und welche Konsequenzen das hat.

RISE ist ein Betriebsmodell. Und genau dort entstehen die Probleme, über die in Verkaufsgesprächen selten gesprochen wird.

Dieser Artikel benennt fünf kritische Herausforderungen aus der Praxis – nicht um RISE zu verteufeln, sondern um eine informierte Entscheidung zu ermöglichen.

1. Eingeschränkte technische Kontrolle: Was man aufgibt, wenn SAP den Betrieb übernimmt

In einem klassischen On-Premise- oder selbst betriebenen Cloud-Szenario hat das eigene IT-Team direkten Zugriff auf Infrastruktur, Betriebssystem und Datenbankebene. Basis-Administratoren kennen ihre Systeme in- und auswendig, können bei Problemen direkt eingreifen und Anpassungen vornehmen.

Mit RISE ändert sich das grundlegend. SAP übernimmt den Systembetrieb – und damit auch die Kontrolle über Schichten, auf die Kunden bisher Zugriff hatten. Das bedeutet konkret:

  • Kein direkter Infrastrukturzugriff: Betriebssystem, Netzwerkkonfiguration und Storage liegen in SAPs Verantwortungsbereich. Für Standardanforderungen ist das kein Problem. Für Spezialanforderungen – etwa spezifische Sicherheitsanforderungen, regulatorische Vorgaben oder besondere Integrationsarchitekturen – kann das zur echten Einschränkung werden.
  • Eingeschränkte Basis-Operationen: Bestimmte administrative Aufgaben, die On-Premise selbstverständlich waren, sind in RISE nur über SAP-Support oder definierte Service-Prozesse möglich. Das erhöht die Reaktionszeiten und erfordert ein Umdenken in der eigenen IT-Organisation.

Unternehmen mit komplexen technischen Anforderungen oder hohem regulatorischen Druck sollten diesen Punkt vor Vertragsabschluss detailliert prüfen.

2. Unklare Verantwortlichkeiten: Das Drei-Parteien-Problem

RISE with SAP bedeutet in der Praxis: SAP als Vertragspartner, ein Hyperscaler (AWS, Azure oder Google Cloud) als tatsächliche Infrastrukturplattform und der Kunde als Nutzer. Drei Parteien, ein System – und bei Problemen entsteht daraus regelmäßig eine unangenehme Frage: Wer ist eigentlich zuständig?

Bei einem Performanceproblem stellt sich die Frage, ob die Ursache im SAP-Applikationscode liegt, in der Datenbankschicht, in der Infrastruktur des Hyperscalers oder im eigenen Netzwerk. Die Antwort bestimmt, wer tätig werden muss – aber bis diese Antwort vorliegt, vergeht Zeit, die in produktionskritischen Situationen fehlt.

Bei Integrationsfehlern wird es noch komplexer. Sobald Drittsysteme, eigene Middleware oder BTP-Services ins Spiel kommen, verschwimmen die Verantwortungsgrenzen weiter. SAP verweist auf die Kundenschnittstelle, der Hyperscaler auf SAP, der Kunde sitzt dazwischen.

Was in der Praxis hilft: ein klar definiertes Service-Management-Modell vor Go-Live, mit explizit vereinbarten Eskalationspfaden und SLA-Verantwortlichkeiten für genau diese Szenarien. Wer das dem Zufall überlässt, wird es im Ernstfall lernen – aber zu einem ungünstigen Zeitpunkt.

3. Kostenstruktur: Was RISE wirklich kostet

Die Preisgestaltung von RISE with SAP ist eines der am häufigsten unterschätzten Themen in der Evaluierungsphase. Auf den ersten Blick klingt das Modell attraktiv: ein Paketpreis, der Lizenz, Cloud-Infrastruktur und bestimmte Services zusammenfasst. Auf den zweiten Blick zeigt sich ein komplexeres Bild.

Schwer kalkulierbare Gesamtkosten: Der Paketpreis deckt nicht alles ab. Zusätzliche BTP-Services, Migrationsprojekte, optionale Managed Services und der eigene Transformationsaufwand kommen hinzu. Unternehmen, die nur den RISE-Listenpreis als Budgetgrundlage nehmen, erleben regelmäßig Überraschungen.

Langfristige Vertragsbindung: RISE-Verträge laufen typischerweise über mehrere Jahre. Das schränkt die Verhandlungsposition bei späteren Anpassungen ein und bedeutet, dass Einsparungseffekte, die durch technologische Entwicklungen entstehen könnten, nicht automatisch an den Kunden weitergegeben werden.

Versteckte Wechselkosten: Ein oft übersehener Kostentreiber ist der potenzielle Exit aus dem RISE-Modell. Datenmigration, technische Anpassungen und der Aufbau einer neuen Betriebsinfrastruktur können erhebliche Investitionen erfordern – auch wenn dieser Fall bei Vertragsabschluss unrealistisch erscheint.

Eine ehrliche Total-Cost-of-Ownership-Betrachtung über fünf bis sieben Jahre ist vor der RISE-Entscheidung unerlässlich.

4. Innovationsgeschwindigkeit vs. Stabilität: Der Konflikt mit Release-Zyklen

Einer der zentralen Versprechen von RISE ist der automatische Zugang zu SAP-Innovation: neue Features werden kontinuierlich bereitgestellt, ohne dass aufwändige Upgrade-Projekte notwendig sind. In der Theorie ein klarer Vorteil. In der Praxis ein zweischneidiges Schwert.

Jedes neue SAP-Release kann bestehende Prozesse, Schnittstellen oder Erweiterungen beeinflussen. In einer On-Premise-Welt hatte die IT-Abteilung die Kontrolle darüber, wann ein neues Release eingespielt wird – und damit Zeit für Tests, Kommunikation und Anpassung. In einer Managed-Cloud-Umgebung unter RISE verringert sich dieser Handlungsspielraum.

Für Unternehmen mit stabilen, hochintegrierten Prozessen und vielen Schnittstellen zu Drittsystemen ist die Frage nach der Release-Steuerung kritisch. Wer kann welche Updates wann und mit welcher Vorlaufzeit verhindern oder verschieben? Welche Testkapazitäten müssen dauerhaft vorgehalten werden, um mit der Innovationsgeschwindigkeit Schritt zu halten?

Diese organisatorischen Konsequenzen werden in RISE-Evaluierungen häufig unterschätzt.

5. Vendor Lock-in: Die strategische Abhängigkeit wächst mit jedem Jahr

Mit RISE with SAP steigt die Abhängigkeit von SAP als Technologieanbieter erheblich – und das auf mehreren Ebenen gleichzeitig: Lizenz, Infrastruktur, Support, Betrieb und Innovationspfad liegen in einer Hand. Das hat Vorteile, solange die Beziehung funktioniert. Es hat erhebliche Nachteile, wenn sich das ändern sollte.

Technologische Abhängigkeit: Je tiefer ein Unternehmen in das RISE-Ökosystem investiert – BTP-Services, SAP Integration Suite, SAP Build – desto aufwändiger wird ein späterer Wechsel zu alternativen Technologieplattformen.

Verhandlungsposition: Ein Unternehmen, das vollständig auf RISE setzt und keine realistische Exit-Option mehr hat, verliert schrittweise seine Verhandlungsposition bei Verlängerungen, Preisanpassungen und Leistungsänderungen.

Exit-Komplexität: Ein Ausstieg aus RISE ist technisch und organisatorisch aufwändig. Datenmigration, Neuaufbau der Betriebsinfrastruktur, Lizenzneuverhandlungen – all das erfordert erhebliche Ressourcen. Die Entscheidung für RISE ist deshalb keine, die man leichtfertig rückgängig machen kann.

Das bedeutet nicht, RISE zu vermeiden. Es bedeutet, die strategische Abhängigkeit bewusst einzugehen – mit einer klaren Abwägung von Nutzen und Risiko.

Fazit: RISE ist eine strategische Entscheidung, kein Standard-Einkauf

RISE with SAP ist kein „No-Brainer“. Es ist eine weitreichende strategische Entscheidung mit Konsequenzen, die über IT-Abteilungen hinausgehen und Unternehmensführung, Einkauf und Finanzplanung betreffen.

Das Modell kann für viele Unternehmen der richtige Weg sein – wenn die Anforderungen passen, die Kosten realistisch kalkuliert wurden und die Abhängigkeit bewusst und akzeptiert ist. Was es nicht ist: eine einfache Antwort auf komplexe Fragen.

Die fünf beschriebenen Herausforderungen verschwinden nicht durch Ignorieren. Sie werden handhabbar durch sorgfältige Vorbereitung, klare Vertragsgestaltung und ein realistisches Bild davon, worauf man sich einlässt.

Sie evaluieren RISE with SAP?

Wir helfen Ihnen bei einer realistischen Bewertung – jenseits der Verkaufsargumente. Von der Total-Cost-of-Ownership-Analyse über die Prüfung technischer Anforderungen bis hin zur Vertragsverhandlung begleiten wir Sie dabei, eine fundierte Entscheidung zu treffen.

Jetzt Kontakt aufnehmen und RISE with SAP unabhängig und ehrlich bewerten.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

Clean Core vs. Customizing: Was in S/4HANA wirklich noch erlaubt ist

/in

Clean Core vs. Customizing: Was in S/4HANA wirklich noch erlaubt ist

„Kein Custom Code mehr.“ Ein Satz, der in Projekten regelmäßig fällt – und sich in der Praxis so gut wie nie in dieser Absolutheit hält. Die Realität ist differenzierter, und das ist auch gut so. Denn Clean Core bedeutet nicht das Ende jeglicher Anpassung. Es bedeutet das Ende von unkontrollierter Anpassung.

Die entscheidende Frage lautet deshalb nicht: „Darf ich noch anpassen?“ Sondern: „Welches Customizing ist strategisch sinnvoll – und welches nicht mehr?“

Die drei Ebenen von SAP-Anpassungen im Clean-Core-Kontext

Um diese Frage zu beantworten, lohnt sich eine klare Unterscheidung zwischen drei Typen von Anpassungen – denn nicht alle sind gleich zu bewerten.

Ebene 1: Konfiguration – weiterhin erlaubt und notwendig

Die klassische SAP-Konfiguration im IMG (Implementation Guide) ist kein Widerspruch zu Clean Core. Im Gegenteil: Sie ist der vorgesehene Weg, um SAP-Systeme an organisatorische und prozessuale Anforderungen anzupassen.

Typische Beispiele sind:

  • Buchungskreise und Unternehmensstruktur: Organisationseinheiten, Kostenstellen, Controlling-Kreise
  • Kontenlogik und Kontenfindung: Kontenrahmenzuordnungen, automatische Buchungsregeln
  • Prozessparameter: Toleranzgrenzen, Workflow-Einstellungen, Ausgabesteuerung

Diese Art der Anpassung berührt keinen Programmcode, ist vollständig dokumentiert und wird von SAP-Releases übernommen. Sie bleibt in einem Clean-Core-Umfeld nicht nur erlaubt, sondern ist zwingend notwendig, um SAP überhaupt betriebsfähig zu machen.

Ebene 2: Erweiterungen – der bevorzugte Weg für darüber hinausgehende Anforderungen

Wenn die reine Konfiguration nicht ausreicht, sind Erweiterungen der strategisch saubere nächste Schritt. SAP bietet dafür ein breites Werkzeugspektrum:

In-App Extensibility (Key User Extensibility): Felder hinzufügen, Logiken anpassen, Formulare gestalten – direkt im System, ohne Programmieraufwand, und vollständig upgrade-sicher. Diese Werkzeuge sind bewusst für Anpassungen konzipiert, die innerhalb des SAP-Standards bleiben.

Side-by-Side-Erweiterungen auf SAP BTP: Für komplexere Anforderungen – eigene Applikationen, externe Prozesslogiken, Integrationsszenarien – bietet die SAP Business Technology Platform eine saubere Entkopplung vom Core. Die Erweiterung läuft außerhalb des SAP-Systems und kommuniziert über stabile, versionierte APIs.

Beide Wege sind Clean-Core-konform, weil sie keine direkten Eingriffe in den SAP-Standard erfordern. Der Preis: höhere Komplexität in der Architektur und ein erhöhter Initialaufwand gegenüber einem direkten Core-Eingriff. Langfristig zahlt sich dieser Mehraufwand jedoch aus – vor allem bei Upgrades und beim Wechsel auf neue SAP-Releases.

Ebene 3: Modifikationen – nur in begründeten Ausnahmefällen

Klassische Modifikationen – also direkte Änderungen am SAP-Standardcode oder implizite Enhancements ohne stabile API-Grundlage – sind im Clean-Core-Ansatz das letzte Mittel, nicht das erste. Der Grund liegt auf der Hand: Jede Modifikation muss bei einem Release-Upgrade geprüft, angepasst und neu getestet werden. In Systemen mit Hunderten von Modifikationen summiert sich dieser Aufwand zu erheblichen Projektkosten.

Das bedeutet nicht, dass Modifikationen grundsätzlich verboten sind. Es bedeutet, dass sie eine bewusste Ausnahmeentscheidung sein müssen – mit dokumentierter Begründung, Lifecycle-Planung und klarer Verantwortlichkeit.

Die eigentliche Entscheidungslogik: nicht „Ist es erlaubt?“ sondern „Was kostet es uns in drei Jahren?“

Der häufigste Fehler in der Bewertung von Anpassungsentscheidungen ist die Kurzfristperspektive. Ein direkter Core-Eingriff löst das Problem heute in zwei Stunden. Die saubere Erweiterung braucht zwei Wochen. Also fällt die Entscheidung zugunsten des schnellen Wegs.

Was dabei nicht eingerechnet wird: die Folgekosten. Jede Modifikation, die heute ohne Lifecycle-Betrachtung eingebaut wird, erscheint beim nächsten Upgrade als ungebetener Gast. Und wenn es nicht nur eine ist, sondern hundert, wird aus einem technischen Problem ein strategisches.

Die richtige Entscheidungsfrage lautet deshalb: Was kostet uns diese Anpassung in drei Jahren? Das schließt Upgrade-Aufwand, Wartungskosten, Testaufwand und das Risiko ein, bei neuen SAP-Funktionen ausgesperrt zu bleiben, weil der Standard zu stark verändert wurde.

Typische Fehlentscheidungen in der Praxis

Aus Projekterfahrung lassen sich drei Muster beobachten, die immer wieder zu unnötigem Mehraufwand führen:

Kurzfristige Prozessoptimierung auf Kosten der Upgradefähigkeit. Eine Prozessverbesserung, die einen direkten Core-Eingriff erfordert, mag fachlich sinnvoll sein. Wenn sie aber dazu führt, dass das nächste SAP-Release nicht mehr eingespielt werden kann, ohne erheblichen Anpassungsaufwand, ist die Kosten-Nutzen-Rechnung oft negativ.

Fehlende Dokumentation von Erweiterungen. Erweiterungen, die ohne Dokumentation eingebaut werden, werden zum Risiko – nicht beim Einbau, sondern zwei Jahre später, wenn niemand mehr weiß, warum sie existieren und was sie tun. Gute Clean-Core-Governance beginnt mit sauberer Dokumentationspflicht.

Keine Lifecycle-Betrachtung. Jede Erweiterung sollte mit einer Antwort auf die Frage verbunden sein: Wie lange brauchen wir diese Anpassung, wer ist verantwortlich, und was passiert, wenn SAP diese Anforderung irgendwann im Standard abdeckt?

Best Practice aus S/4HANA-Projekten

Erfolgreiche Projekte, die Clean Core konsequent umsetzen, arbeiten mit drei zentralen Prinzipien:

Extension-First-Strategie: Bevor eine Modifikation beschlossen wird, muss nachgewiesen sein, dass die Anforderung sich nicht über Konfiguration oder die vorhandenen Erweiterungsmodelle abbilden lässt. Nicht die Modifikation ist die Ausnahme – sie ist der Ausschluss, wenn alles andere nicht funktioniert.

Klare Architekturprinzipien: Ein schriftlich fixiertes Regelwerk, das definiert, welche Erweiterungstypen für welche Anforderungsklassen zulässig sind, schafft Konsistenz und verhindert, dass jede Anforderung neu diskutiert werden muss. Dieses Regelwerk muss vor Projektstart existieren, nicht nach dem ersten Konflikt.

Bewertung jeder Abweichung mit Business Case: Wer eine Abweichung vom Standard beantragt, trägt die Beweislast. Nicht technisch, sondern wirtschaftlich: Was ist der Nutzen der Anpassung, was sind die langfristigen Kosten, und überwiegt der Nutzen? Diese Disziplin senkt die Zahl der Erweiterungen deutlich – ohne fachliche Anforderungen zu übergehen.

Fazit: Clean Core ist ein Governance-Thema

Customizing ist nicht das Problem. Unkontrolliertes Customizing ist es.

Clean Core ist kein technisches Verbot, sondern eine strategische Haltung gegenüber Anpassungen. Konfiguration bleibt uneingeschränkt möglich. Erweiterungen sind der bevorzugte Weg, wenn der Standard nicht ausreicht. Modifikationen sind die begründete Ausnahme, nicht die bequeme Abkürzung.

Wer das versteht, erkennt: Clean Core ist vor allem eine Frage der Governance – der bewussten, dokumentierten und lifecycle-bewussten Steuerung aller Anpassungsentscheidungen. Unternehmen, die diese Governance ernst nehmen, schaffen sich ein S/4HANA-System, das nicht nur heute funktioniert, sondern auch in fünf Jahren noch wartbar, upgradefähig und anpassbar ist.

Ihre Anpassungsstrategie Clean-Core-konform ausrichten?

Wir unterstützen Sie bei Architektur und Entscheidungsfindung. Von der Definition Ihrer Erweiterungsstrategie über die Einführung geeigneter Governance-Strukturen bis hin zur Bewertung konkreter Anpassungsszenarien – gemeinsam finden wir den richtigen Rahmen für Ihr S/4HANA-Vorhaben.

Jetzt Kontakt aufnehmen und Ihre Clean-Core-Strategie auf ein solides Fundament stellen.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

Clean Core in SAP: Realität oder Illusion? Erfahrungen aus echten S/4-Projekten

/in

Clean Core in SAP: Realität oder Illusion? Erfahrungen aus echten S/4-Projekten

„Keep the Core clean“ – wer sich mit SAP S/4HANA beschäftigt, kennt diesen Satz. Er klingt einleuchtend, fast selbstverständlich. Und doch ist Clean Core in der Praxis einer der größten Zielkonflikte, mit dem Projektteams täglich ringen. Dieser Artikel wirft einen ehrlichen Blick auf die Realität hinter dem Konzept – ohne Marketingsprache, aber mit konkreten Erfahrungen aus laufenden S/4-Projekten.

Was Clean Core wirklich bedeutet

Clean Core ist mehr als ein technisches Konzept. Es ist ein Paradigmenwechsel in der Art, wie Unternehmen SAP-Systeme betreiben und weiterentwickeln. Die Kernaussage: Statt den SAP-Standard durch direkte Codemodifikationen zu verändern, sollen Erweiterungen sauber abgekapselt werden – über definierte APIs, Side-by-Side-Erweiterungen auf der SAP Business Technology Platform (BTP) oder In-App-Extensibility-Mechanismen innerhalb des ABAP-Stacks.

Das Ziel dahinter ist nachvollziehbar:

  • Upgrade-Fähigkeit: Ein sauberer Core lässt sich einfacher auf neue SAP-Releases heben.
  • Wartbarkeit: Weniger Eigenentwicklung bedeutet weniger technische Schulden.
  • Standardkonformität: Unternehmen profitieren stärker von SAP-Innovation, wenn sie nah am Standard bleiben.

In der Theorie klingt das überzeugend. In der Praxis ist es deutlich komplizierter.

Wo Clean Core in Projekten regelmäßig scheitert

1. Fachbereiche akzeptieren den Standard nicht – und das hat oft gute Gründe

SAP-Standardprozesse decken in der Regel 70 bis 80 Prozent der fachlichen Anforderungen ab. Die verbleibenden 20 bis 30 Prozent sind jedoch selten trivial. Sie umfassen häufig:

  • Regulatorische Anforderungen: Branchenspezifische Compliance-Vorgaben, länderspezifische Gesetzgebung oder interne Audit-Anforderungen, die SAP im Standard schlicht nicht vollständig abbilden kann.
  • Historisch gewachsene Prozesse: Abläufe, die über Jahre optimiert wurden und an denen ganze Organisationseinheiten hängen – inklusive Schulungsunterlagen, Berechtigungskonzepten und Schnittstellen zu Drittsystemen.
  • Wettbewerbsdifferenzierende Logiken: Prozesse, die dem Unternehmen echten Marktvorsprung verschaffen und deshalb bewusst nicht standardisiert werden sollen.

Genau an diesen Stellen entstehen Erweiterungen – und das ist oft keine Faulheit, sondern eine bewusste Geschäftsentscheidung.

2. Die Erweiterungsmodelle stoßen an ihre Grenzen

SAP bietet ein breites Spektrum an Erweiterungsmöglichkeiten: BTP-Side-by-Side-Erweiterungen, RAP (RESTFUL Application Programming Model), Key User Extensibility oder klassische Enhancement Spots. In vielen Szenarien sind diese Werkzeuge ausreichend und die richtige Wahl.

Aber es gibt Situationen, in denen sie nicht reichen:

  • Performance-kritische Prozesse: Wenn massenhaft Daten in Echtzeit verarbeitet werden müssen, kann ein Aufruf über externe APIs oder BTP-Services einen erheblichen Mehraufwand bedeuten – sowohl in der Latenz als auch in der Systemkomplexität.
  • Tiefe Eingriffe in Kernlogik: Manche fachlichen Anforderungen erfordern Eingriffe in Ablaufsteuerungen, Buchungslogiken oder Datenbankzugriffe, die sich über saubere Erweiterungspunkte schlicht nicht sauber abbilden lassen.

In diesen Fällen entsteht ein echter Zielkonflikt: Hält man den Core sauber und akzeptiert fachliche Einschränkungen – oder weicht man für das bessere Ergebnis vom Ideal ab?

3. Zeitdruck besiegt Architekturqualität

Dies ist vielleicht die unbequemste Wahrheit: Clean Core braucht Zeit. Zeit für saubere Architekturentscheidungen, Zeit für die Abstimmung mit Fachbereichen, Zeit für die Entwicklung und den Test von sauberen Erweiterungen.

Unter dem Druck eines laufenden Projekts – mit festen Go-Live-Terminen, begrenzten Budgets und parallelen Workstreams – gewinnt häufig die schnelle Lösung. Ein direkter Core-Eingriff ist in 2 Stunden umgesetzt; die saubere BTP-Erweiterung benötigt 2 Wochen Analyse, Architekturentscheid und Abstimmung.

Das Ergebnis: Technische Schulden, die sich im nächsten Upgrade-Projekt rächen.

Die unbequeme Wahrheit über Clean Core

Clean Core ist kein Zustand, den man einmal erreicht und dann gehalten hat. Es ist ein kontinuierlicher Kompromiss – zwischen dem Ideal des unberührten Standards und der Realität fachlicher Anforderungen, Projektbedingungen und wirtschaftlicher Zwänge.

Projekte, die Clean Core als absolutes Dogma behandeln, scheitern an der Realität. Projekte, die Clean Core gar nicht erst ernst nehmen, schaffen sich einen Wartungsalptraum für die nächsten Jahre.

Der Schlüssel liegt zwischen diesen beiden Extremen.

Wie Clean Core trotzdem gelingt – Erfahrungen aus der Praxis

Erfolgreiche S/4HANA-Projekte haben eines gemeinsam: Sie behandeln Clean Core nicht als Selbstzweck, sondern als Gestaltungsprinzip mit klaren Leitplanken.

Eine Erweiterungsstrategie vor Projektstart definieren

Wer erst im Projektverlauf entscheidet, wie mit Abweichungen vom Standard umgegangen wird, verliert wertvolle Zeit und riskiert inkonsistente Entscheidungen. Eine frühzeitig definierte Erweiterungsstrategie legt fest:

  • Welche Erweiterungsmechanismen grundsätzlich erlaubt sind
  • Nach welchen Kriterien über Abweichungen entschieden wird
  • Wer die Entscheidungshoheit hat (Architektur-Board, Solution Architect, etc.)

Jede Abweichung konsequent bewerten

Nicht jede Anforderung, die nicht im Standard abbildbar ist, rechtfertigt eine Erweiterung. Ein strukturierter Bewertungsprozess hilft, die wirklich notwendigen von den nur gewünschten Abweichungen zu trennen. Bewährte Fragen dabei:

  • Ist diese Anforderung regulatorisch verpflichtend oder nur „nice to have“?
  • Kann der Prozess so angepasst werden, dass er im Standard funktioniert?
  • Was sind die langfristigen Kosten dieser Erweiterung (Wartung, Upgrade-Aufwand)?

Technische Leitplanken und Governance etablieren

Clean Core braucht Governance. Das bedeutet: automatisierte Code-Checks, die direkte Modifikationen identifizieren, regelmäßige Architecture Reviews und klare Eskalationspfade, wenn Standards abgewichen werden sollen. Tools wie der SAP Custom Code Migration App oder ABAP Test Cockpit helfen dabei, den Überblick zu behalten.

Mut zur Standardisierung entwickeln

Der vielleicht wichtigste Faktor: Projektteams brauchen den Rückhalt, fachliche Anforderungen kritisch zu hinterfragen und Stakeholdern klarzumachen, dass Standardisierung kein Qualitätsverlust ist – sondern oft ein Gewinn. Das erfordert Kommunikationsstärke, Fingerspitzengefühl und manchmal auch unbequeme Gespräche.

Fazit: Clean Core als Zielbild, nicht als Dogma

Clean Core ist erreichbar – aber nicht als absolutes Ziel, sondern als kontinuierliches Streben nach der bestmöglichen Balance. Unternehmen, die es als Ideal statt als starres Regelwerk verstehen, werden erfolgreicher sein: Sie treffen bewusstere Architekturentscheidungen, akkumulieren weniger technische Schulden und halten ihre S/4HANA-Systeme langfristig upgrade-fähig.

Die Illusion ist nicht Clean Core selbst – die Illusion ist die Vorstellung, es sei einfach.

Sie planen ein S/4HANA-Projekt?

Wir helfen Ihnen, Clean Core realistisch umzusetzen. Mit einer klaren Erweiterungsstrategie, bewährten Governance-Strukturen und dem Erfahrungsschatz aus zahlreichen S/4-Projekten begleiten wir Sie dabei, die richtige Balance zwischen Standardisierung und fachlicher Anforderung zu finden.

Jetzt Kontakt aufnehmen und gemeinsam die Grundlage für ein zukunftsfähiges S/4HANA-System schaffen.

 

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

KI-Projekte in SAP: Die wahren Gründe fürs Scheitern – und ein funktionierender Umsetzungsansatz

/in

Warum viele KI-Projekte im SAP-Umfeld scheitern (und wie man es richtig macht)

Hallo zusammen,

unsere Erfahrung der letzten Monate zeigt: Die meisten KI-Projekte scheitern nicht an der Technologie. Sie scheitern an falschen Annahmen.

Gerade im SAP-Umfeld sehen wir eine wiederkehrende Dynamik:

  1. Hohe Erwartungen
  2. Schnelle Pilotprojekte
  3. Ernüchterung im Betrieb

Warum ist das so – trotz ausgereifter Technologien?

Die eigentlichen Ursachen (tiefer betrachtet)

1. Fehlende Prozessintegration

Viele KI-Lösungen laufen „neben dem SAP-System“.

Konsequenz:

  • keine Nutzung im Alltag
  • kein messbarer Impact

KI muss Teil des Transaktionsflusses sein (z. B. direkt in Fiori Apps)

2. Technische Silos (BTP vs. Core)

Typisches Muster:

  • Modell läuft auf BTP
  • SAP Core bleibt unverändert
  • Integration ist minimal

Ergebnis:

  • Medienbrüche
  • fehlende Skalierbarkeit

Erfolgreiche Projekte denken Architektur End-to-End

3. Unterschätzter Betriebsaufwand

Nach Go-Live beginnt die eigentliche Arbeit:

  • Modell-Monitoring
  • Retraining
  • Datenpflege

Viele Business Cases ignorieren diese Kosten vollständig

4. Fehlende Ownership

Wer „besitzt“ das Modell?

  • IT?
  • Fachbereich?
  • Data Team?

Ohne klare Verantwortlichkeit:
→ kein nachhaltiger Betrieb

5. Unrealistische Erwartung an Automatisierung

KI wird oft als Ersatz für Entscheidungen gesehen.

In der Realität:

  • KI unterstützt
  • Mensch entscheidet

Erfolgreiche Projekte definieren diese Grenze klar

Ein funktionierender Ansatz aus der Praxis

Phase 1: Use Case Validierung

  • klarer Business Impact
  • Datenverfügbarkeit prüfen
  • Quick Prototyp

Phase 2: Integration

  • Einbettung in SAP-Prozesse
  • UI/UX berücksichtigen
  • Rollen & Berechtigungen definieren

Phase 3: Betrieb

  • Monitoring (Accuracy, Drift)
  • Governance
  • kontinuierliche Optimierung

Die wichtigste Erkenntnis

KI-Projekte sind keine Projekte.
Sie sind Produkte, die betrieben werden müssen.

Fazit

Wer KI wie ein klassisches SAP-Projekt behandelt, wird scheitern. Erfolgreich ist, wer Technologie, Prozesse und Betrieb gemeinsam denkt.

Sie möchten KI nicht nur pilotieren, sondern produktiv betreiben?
Wir unterstützen Sie beim Aufbau einer tragfähigen KI-Architektur im SAP-Umfeld.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

3 reale Use Cases für KI in SAP-Prozessen (Finance, Logistik, HR)

/in

KI in SAP: 3 echte Use Cases aus Finance, Logistik und HR – heute umsetzbar

Hallo zusammen,

viele KI-Demos sehen mittlerweile ja schon wirklich beeindruckend aus.
Die wenigsten überleben jedoch den Übergang in produktive SAP-Prozesse. Denn die entscheidende Frage ist nicht: Was ist technisch möglich?
Sondern: Was ist stabil, skalierbar und wirtschaftlich betreibbar?

Die folgenden drei Use Cases sind genau das – inklusive technischer Einordnung.

Use Case 1: Finance – KI-gestützte Rechnungsvalidierung

Technischer Aufbau

  • SAP S/4HANA (FI-AP)
  • Dokumentenerkennung (z. B. via SAP AI Services / OCR)
  • ML-Modell zur Anomalieerkennung
  • Integration über BTP

Was die KI konkret macht

  • Abgleich von Rechnungen mit Bestellungen (3-Way Match erweitert)
  • Erkennung von Ausreißern (Preis, Menge, Lieferant)
  • Klassifikation von Rechnungen ohne Referenz

Datenanforderungen

  • Historische Rechnungsdaten (mind. 12–24 Monate)
  • saubere Kreditorenstammdaten
  • konsistente Buchungslogik

ROI-Treiber

  • Reduktion manueller Prüfungen (30–70 %)
  • schnellere Durchlaufzeiten
  • weniger Skontoverluste

Kritischer Punkt: Trainingsdatenqualität

Use Case 2: Logistik – Demand Forecasting mit externen Einflussfaktoren

Technischer Aufbau

  • SAP IBP oder S/4 embedded PP/DS
  • Erweiterung durch ML-Modelle (z. B. auf BTP oder extern)
  • Integration externer Daten (Wetter, Markt, Events)

Mehrwert gegenüber klassischen Verfahren

  • Berücksichtigung nicht-linearer Effekte
  • dynamische Anpassung an Trends
  • bessere Erkennung von Ausreißern

Typische Herausforderungen

  • Datenintegration (intern + extern)
  • Modellpflege
  • Erklärbarkeit gegenüber Fachbereich

Ohne Akzeptanz im Planning-Team scheitert der Use Case

Use Case 3: HR – Skill-basierte Matching-Modelle

Technischer Aufbau

  • SAP SuccessFactors
  • NLP-Modelle zur Analyse von Lebensläufen
  • Skill-Ontologien / Taxonomien

Konkreter Nutzen

  • automatisches Matching von Kandidaten auf Stellen
  • Identifikation interner Talente
  • Reduktion von Time-to-Hire

Risiken

  • Bias in Trainingsdaten
  • rechtliche Anforderungen (EU AI Act)
  • mangelnde Transparenz

Governance ist hier nicht optional, sondern Pflicht

Was diese Use Cases gemeinsam haben

Erfolgreiche Implementierungen zeichnen sich aus durch:

  • klare Integration in bestehende SAP-Prozesse
  • stabile Datenpipelines
  • kontinuierliches Monitoring der Modelle
  • enge Zusammenarbeit zwischen Fachbereich und IT

Fazit

KI funktioniert im SAP-Umfeld – aber nur unter klaren Voraussetzungen. Der Unterschied liegt nicht im Algorithmus, sondern in der Integration.

Sie wollen wissen, welcher Use Case bei Ihnen wirklich funktioniert?
Wir bewerten Ihre Daten, Prozesse und Architektur – realistisch und umsetzbar.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

SAP Joule im Einsatz: Konkreter Nutzen statt großer Versprechen

/in

SAP Joule im Praxistest: Was der KI-Copilot im Alltag wirklich bringt

Hallo zusammen,

„Frag einfach Joule.“ – so klingt die neue SAP-Welt.
Doch was passiert wirklich, wenn man den Copiloten in produktiven S/4HANA-Umgebungen einsetzt?

Mit Joule positioniert SAP erstmals einen systemübergreifenden KI-Copiloten, der tief in Geschäftsprozesse eingebettet ist. Anders als frühere Assistenten (z. B. Embedded Analytics oder Chatbots) greift Joule auf:

  • SAP Business Data Cloud / Datasphere
  • semantische Geschäftsobjekte
  • Kontext aus laufenden Prozessen

zu.

Die entscheidende Frage ist daher nicht, was Joule kann, sondern:
Wo entfaltet es in realen Systemlandschaften messbaren Nutzen?

Architektur: Warum Joule anders ist

Joule basiert nicht einfach auf einem LLM-Frontend.

In der Praxis sehen wir drei relevante Ebenen:

  1. Semantische Schicht (z. B. CDS Views)
    → definiert, was Joule überhaupt verstehen kann
  2. Kontextintegration (Fiori, Prozesse, Rollen)
    → bestimmt, wann und für wen Joule sinnvoll ist
  3. LLM + Orchestrierung (SAP AI Core / Generative AI Hub)
    → generiert Antworten und Aktionen

Dies Bedeutet konkret: Ohne saubere semantische Modellierung bleibt Joule oberflächlich.

Konkrete Einsatzszenarien aus Projekten

1. Ad-hoc Analysen im Finance

Beispiel:
„Warum ist die Marge im Produktbereich X im letzten Quartal gesunken?“

Was gut funktioniert:

  • Zugriff auf vordefinierte KPIs
  • Drill-down über CDS-basierte Modelle

Was nicht funktioniert:

  • Ursachenanalyse ohne sauber modellierte Treiberlogik
  • Interpretation ohne Business-Kontext

Joule liefert Daten – keine fertigen Entscheidungen.

2. Prozessunterstützung im Einkauf

Beispiel:

  • automatische Zusammenfassung von Bestellhistorien
  • Hervorhebung von Abweichungen bei Lieferanten

Mehrwert:

  • Zeitersparnis bei Vorbereitung von Verhandlungen
  • bessere Transparenz bei operativen Entscheidungen

Grenze:

  • keine echte Bewertung von Lieferantenrisiken ohne externe Daten

3. User Enablement (Hidden Champion)

Der größte Effekt zeigt sich oft hier:

  • Reduktion von Schulungsaufwand
  • schnellere Einarbeitung neuer Mitarbeiter
  • weniger Abhängigkeit von Key Usern

Gerade in komplexen S/4-Landschaften ein echter Hebel.

Die unterschätzte Herausforderung: Berechtigungen & Governance

Joule greift auf sensible Daten zu. In Projekten entstehen schnell Fragen wie:

  • Welche Daten darf Joule kontextübergreifend aggregieren?
  • Wie werden Berechtigungen in generativen Antworten berücksichtigt?
  • Wie verhindert man „Halluzinationen“ in kritischen Reports?

Ohne sauberes IAM- und Governance-Konzept wird Joule schnell zum Risiko.

Wann sich Joule wirklich lohnt

Aus Projektsicht lohnt sich Joule vor allem bei:

  • hoher Prozesskomplexität
  • vielen Gelegenheitsnutzern
  • bereits vorhandener semantischer Datenmodellierung

Nicht sinnvoll ist es bei:

  • stark fragmentierten Datenlandschaften
  • schlechter Datenqualität
  • fehlender Prozessstandardisierung

Fazit

Joule ist kein Gamechanger auf Knopfdruck.
Aber: In gut strukturierten SAP-Landschaften kann es Usability und Entscheidungsfindung spürbar verbessern. Der wahre Hebel liegt nicht im Copiloten – sondern in der Vorbereitung des Systems darauf.

Sie möchten Joule sinnvoll in Ihre SAP-Architektur integrieren – ohne teure Experimente?
Wir zeigen Ihnen, welche Voraussetzungen wirklich entscheidend sind.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team

Process Mining trifft RPA und SAP: Wie datengetriebene Automatisierung 2026 zum Erfolgsfaktor wir

/in

Warum klassische Automatisierung allein nicht mehr ausreicht

Hallo zusammen,

viele Unternehmen setzen bereits auf RPA und SAP, um ihre Geschäftsprozesse effizienter zu gestalten. Doch in der Praxis zeigt sich häufig ein zentrales Problem:
Automatisiert wird, ohne die Prozesse wirklich zu verstehen.

Die Folge:

  • Bots automatisieren ineffiziente Abläufe

  • SAP-Prozesse bleiben intransparent

  • Projekte liefern weniger ROI als erwartet

Genau hier kommt ein Thema ins Spiel, das 2026 zunehmend an Bedeutung gewinnt: Process Mining als Grundlage für intelligente Automatisierung.

Für IT-Beratungshäuser mit Fokus auf RPA, SAP und Projektmanagement eröffnet sich damit ein entscheidender Wettbewerbsvorteil.

Was ist Process Mining – und warum ist es aktuell so relevant?

Process Mining analysiert reale Prozessdaten aus Systemen wie SAP und visualisiert, wie Geschäftsprozesse tatsächlich ablaufen – nicht, wie sie dokumentiert sind.

Statt Annahmen zu treffen, basiert die Optimierung auf:

  • Log-Daten aus SAP

  • System-Events

  • realen Prozessdurchläufen

Das Ergebnis: vollständige Transparenz über Durchlaufzeiten, Bottlenecks und manuelle Eingriffe.

Gerade in SAP-getriebenen Unternehmen ist das ein Gamechanger, da SAP als zentrale Prozessplattform enorme Datenmengen liefert, die für Optimierungen genutzt werden können.

Die neue Automatisierungsstrategie: Erst Process Mining, dann RPA

1. Transparenz über End-to-End-Prozesse schaffen

In vielen Unternehmen sind Prozesse historisch gewachsen. Dokumentationen sind veraltet oder lückenhaft.
Process Mining zeigt:

  • Medienbrüche

  • manuelle Workarounds

  • ineffiziente Schleifen im SAP-System

2. Automatisierungspotenziale gezielt identifizieren

Nicht jeder Prozess eignet sich für RPA.
Mit datenbasierter Analyse lassen sich ideal automatisierbare Prozesse erkennen, z. B.:

  • Rechnungsverarbeitung

  • Stammdatenpflege in SAP

  • Bestellprozesse

  • Reporting und Datentransfers

Das verhindert typische Fehlentscheidungen in Automatisierungsprojekten.

3. RPA-Bots strategisch statt isoliert einsetzen

Ohne Analyse werden Bots oft punktuell implementiert.
Mit Process Mining hingegen entsteht:

  • eine skalierbare Automatisierungs-Roadmap

  • ein klarer Business Case

  • messbarer ROI

SAP + RPA + Process Mining: Die perfekte Kombination

Unternehmen, die SAP im Einsatz haben, profitieren besonders stark von diesem Zusammenspiel.

Zentrale Vorteile im Überblick

1. Datenbasierte Prozessoptimierung
SAP liefert strukturierte Prozessdaten, die direkt für Process Mining genutzt werden können.

2. Höhere Automatisierungsquote
Durch die Identifikation von Standardprozessen können deutlich mehr Prozesse automatisiert werden.

3. Reduzierte Fehlerquoten
RPA übernimmt repetitive Aufgaben, während SAP als stabile Systembasis dient – eine Kombination, die Fehler signifikant reduziert.

Bereits heute zeigen viele Automatisierungsinitiativen, dass die Verbindung von SAP und RPA Prozesse schneller, effizienter und nachvollziehbarer macht.

Auswirkungen auf das Projektmanagement in Automatisierungsprojekten

Ein oft unterschätzter Faktor: die Rolle des Projektmanagements.

Moderne Automatisierungsprojekte sind keine reinen IT-Projekte mehr, sondern Transformationsprojekte.
Mit Process Mining verändert sich auch die Projektstruktur:

Klassischer Ansatz (veraltet)

  • Workshops

  • Interviews

  • Prozessannahmen

  • Implementierung

  • Nachbesserung

Datengetriebener Ansatz (Best Practice 2026)

  • Prozessanalyse via Mining

  • Priorisierung nach Business Impact

  • Agile RPA-Implementierung

  • Kontinuierliches Monitoring

Das reduziert Projektrisiken erheblich und sorgt für eine höhere Akzeptanz in den Fachabteilungen.

Typische Herausforderungen – und wie Beratungshäuser sie lösen können

1. Unklare Prozesslandschaften

Lösung: Systemische Prozessanalyse auf SAP-Datenbasis

2. Fehlende Automatisierungsstrategie

Lösung: End-to-End-Automatisierungs-Roadmap statt Einzellösungen

3. Widerstand in Fachabteilungen

Lösung: Transparente Visualisierung von Ist-Prozessen (Change Management)

Ein strukturierter Beratungsansatz ist hier entscheidend, da technologische Expertise allein nicht ausreicht – Prozessverständnis und Projektmethodik sind gleichermaßen notwendig.

Konkrete Praxisbeispiele für datengetriebene Automatisierung

Besonders großes Potenzial zeigt sich in:

  • Finance & Controlling (z. B. Rechnungsprüfung in SAP)

  • Supply Chain Management

  • Einkauf & Logistik

  • Stammdatenmanagement

  • HR-Prozessen

Hier lassen sich durch die Kombination aus SAP, RPA und Process Mining nicht nur Effizienzsteigerungen, sondern auch strategische Wettbewerbsvorteile realisieren.

Warum 2026 der richtige Zeitpunkt für diesen Ansatz ist

Die Digitalisierung entwickelt sich von reiner Automatisierung hin zu intelligenter, datenbasierter Prozesssteuerung.
Während RPA lange als Einstiegstechnologie galt, entsteht jetzt die nächste Evolutionsstufe: Hyperautomation mit datengetriebener Entscheidungsbasis.

Unternehmen, die diesen Schritt früh gehen:

  • vermeiden Fehlinvestitionen in falsche Automatisierungen

  • steigern ihren ROI nachhaltig

  • schaffen skalierbare Prozessstrukturen

Fazit: Von der Automatisierung zur intelligenten Prozessoptimierung

Die Zukunft der Automatisierung liegt nicht mehr im reinen Einsatz von Bots, sondern in der intelligenten Kombination aus:

  • SAP als Daten- und Prozesskern

  • RPA als Automatisierungstechnologie

  • Process Mining als strategische Entscheidungsgrundlage

Für IT-Beratungshäuser bedeutet das eine klare Chance:
Wer datengetriebene Automatisierung strategisch begleitet, positioniert sich als langfristiger Digitalisierungspartner statt als reiner Implementierungsdienstleister.

Jetzt ist der ideale Zeitpunkt, Automatisierungsprojekte neu zu denken – strukturiert, datenbasiert und eng verzahnt mit SAP und professionellem Projektmanagement.

Bis bald und viel Erfolg!
Euer amotIQ solutions Team

Ereignisgesteuerte Prozesse in SAP: Vom reaktiven zum proaktiven Handeln

/in

Hallo zusammen,

viele SAP-Prozesse funktionieren nach einem bekannten Muster: Ein Schritt wird abgeschlossen, dann folgt der nächste – oft angestoßen durch manuelle Aktionen oder zeitgesteuerte Jobs. Das hat lange gut funktioniert, stößt aber in einer zunehmend dynamischen Geschäftswelt an seine Grenzen.

Genau hier kommen ereignisgesteuerte Prozesse ins Spiel. Sie ermöglichen es, SAP-Prozesse in Echtzeit auszulösen und deutlich flexibler zu gestalten.

Was das konkret bedeutet und warum dieser Ansatz immer wichtiger wird, schauen wir uns in diesem Beitrag an.

Was sind ereignisgesteuerte Prozesse?

Bei ereignisgesteuerten Prozessen wird ein Ablauf nicht mehr manuell oder zeitgesteuert gestartet, sondern durch ein konkretes Ereignis (Event).

Typische SAP-Ereignisse sind zum Beispiel:

  • eine neu angelegte Bestellung,

  • eine freigegebene Rechnung,

  • eine Statusänderung in einem Geschäftsobjekt.

Sobald das Ereignis eintritt, wird automatisch eine Folgeaktion ausgelöst – ohne Verzögerung.

Event-driven Architecture im SAP-Umfeld

Im modernen SAP-Umfeld spricht man dabei häufig von einer Event-driven Architecture (EDA). Systeme reagieren nicht mehr auf Abfragen, sondern senden aktiv Informationen, sobald sich etwas ändert.

SAP unterstützt diesen Ansatz zunehmend, insbesondere:

  • in SAP S/4HANA,

  • in Kombination mit Cloud-Architekturen,

  • über die SAP BTP als zentrale Plattform.

So lassen sich Prozesse lose koppeln und systemübergreifend orchestrieren.

Warum ereignisgesteuerte Prozesse immer wichtiger werden

Der Wechsel von klassischen zu ereignisgesteuerten Prozessen bringt mehrere Vorteile:

  • Schnellere Reaktionszeiten durch Echtzeitverarbeitung

  • Mehr Flexibilität, da Prozesse nicht starr vorgegeben sind

  • Bessere Skalierbarkeit in komplexen Landschaften

  • Weniger Abhängigkeiten zwischen Systemen

Unternehmen können damit deutlich schneller auf Veränderungen reagieren – intern wie extern.

Zusammenspiel mit Automatisierung und RPA

Besonders spannend wird es, wenn ereignisgesteuerte Prozesse mit Automatisierung kombiniert werden. Ein SAP-Event kann zum Beispiel:

  • automatisch einen Workflow starten,

  • einen RPA-Bot auslösen,

  • ein externes System informieren.

So entstehen End-to-End-Prozesse, die ohne manuelle Eingriffe funktionieren und trotzdem flexibel bleiben.

Vom Reagieren zum Agieren

Ein großer Vorteil dieses Ansatzes ist der Schritt vom reaktiven zum proaktiven Prozessmanagement. Probleme, Verzögerungen oder Abweichungen werden frühzeitig erkannt und automatisiert adressiert – bevor sie eskalieren.

Fazit

Ereignisgesteuerte Prozesse sind ein zentraler Baustein moderner SAP-Architekturen. Sie ermöglichen Echtzeitreaktionen, flexible Prozesssteuerung und eine enge Verzahnung von Integration und Automatisierung.

Für Unternehmen, die ihre SAP-Prozesse zukunftssicher aufstellen wollen, lohnt sich ein genauer Blick auf diesen Ansatz.

Habt ihr Fragen oder möchtet wissen, wie ereignisgesteuerte Prozesse sinnvoll in eure SAP-Landschaft integriert werden können?
Dann meldet euch gerne bei uns.

Bis bald und viel Erfolg!
Euer amotIQ solutions Team

SAP BTP als Integrationsplattform: Mehr als nur Erweiterungen

/in

Hallo zusammen,

wenn es um moderne SAP-Landschaften geht, fällt ein Begriff inzwischen fast immer: SAP Business Technology Platform, kurz SAP BTP. Häufig wird sie dabei als Plattform für Erweiterungen oder als „Cloud-Zusatz“ zu SAP S/4HANA beschrieben.

Aber ist das wirklich alles?
Oder steckt in der SAP BTP deutlich mehr Potenzial – gerade wenn es um Integration, Automatisierung und zukunftsfähige Architekturen geht?

In diesem Beitrag schauen wir uns an, warum die SAP BTP heute weit mehr ist als nur eine Erweiterungsplattform und welche Rolle sie als zentrale Integrationsdrehscheibe in SAP-Systemlandschaften spielt.

Was ist die SAP Business Technology Platform eigentlich?

Ganz einfach gesagt: Die SAP BTP ist die technologische Basis, auf der SAP moderne, cloudbasierte Lösungen bündelt. Sie vereint mehrere zentrale Bereiche auf einer Plattform, darunter:

  • Integration von SAP- und Non-SAP-Systemen

  • Erweiterungen nach dem Side-by-Side-Prinzip

  • Daten & Analytics

  • Automatisierung von Prozessen

  • KI-gestützte Services

Das Ziel: Unternehmen sollen ihre SAP-Landschaft flexibel erweitern und integrieren können, ohne den SAP-Kern unnötig zu verkomplizieren.

Warum Integration heute eine zentrale Rolle spielt

Die Realität in vielen Unternehmen sieht so aus:
SAP ist das Rückgrat – aber längst nicht das einzige System. Cloud-Anwendungen, Speziallösungen und externe Services gehören genauso dazu.

Genau hier spielt die SAP BTP ihre Stärken aus:

  • Systeme lassen sich standardisiert anbinden,

  • Schnittstellen werden zentral verwaltet,

  • Prozesse können systemübergreifend abgebildet werden.

Statt vieler punktueller Integrationen entsteht eine saubere, skalierbare Architektur.

SAP BTP und Clean-Core-Strategie

Ein weiterer wichtiger Punkt ist der Zusammenhang zwischen SAP BTP und dem Clean-Core-Ansatz. Individuelle Anforderungen werden nicht mehr direkt im SAP-System umgesetzt, sondern als Side-by-Side-Extensions auf der BTP realisiert.

Das bringt klare Vorteile:

  • SAP bleibt updatefähig,

  • individuelle Logik ist sauber entkoppelt,

  • Innovationen lassen sich schneller umsetzen.

Gerade mit Blick auf regelmäßige SAP-Releases und Cloud-Strategien ist das ein entscheidender Faktor.

Automatisierung auf einer Plattform bündeln

Neben Integration bietet die SAP BTP auch eine starke Basis für Prozessautomatisierung. Workflows, regelbasierte Entscheidungen oder RPA lassen sich zentral steuern und nahtlos in SAP-Prozesse integrieren.

So entsteht eine Plattform, auf der:

  • Prozesse automatisiert,

  • Daten sinnvoll genutzt,

  • und neue Lösungen schnell umgesetzt werden können.

Fazit

Die SAP Business Technology Platform ist deutlich mehr als nur eine Plattform für Erweiterungen. Sie bildet das technologische Fundament für Integration, Automatisierung und Innovation in modernen SAP-Landschaften.

Unternehmen, die SAP BTP strategisch einsetzen, schaffen die Basis für stabile, flexible und zukunftssichere Geschäftsprozesse.

Habt ihr Fragen zur SAP BTP oder möchtet wissen, wie sie sinnvoll in eure bestehende SAP-Landschaft integriert werden kann?
Dann sprecht uns gerne an – wir unterstützen euch von der Konzeption bis zur Umsetzung.

Bis bald!
Euer amotIQ solutions Team