Unsere Überzeugungen für 2026 im Rückblick

Warum ich das veröffentliche

Im Januar haben wir drei Überzeugungen zur ERP-Transformation 2026 veröffentlicht. Mutige Behauptungen sind im Januar schnell formuliert und bis Dezember leicht vergessen. Wir möchten lieber daran gemessen werden.

Hier ist also unsere Halbjahresbilanz. Eine Überzeugung bestätigt sich, und zwar schneller als erwartet. Eine andere bestätigt sich aus einem Grund, den wir nicht vorhergesehen hatten. Und eine, für die ich intern persönlich am stärksten eingetreten bin, war in der Richtung richtig, hatte aber die falsche Maßeinheit. Beim Mechanismus habe ich meine Meinung geändert.

Eine Anmerkung zur Methode: Der Januar-Beitrag argumentierte, der Markt werde nicht mehr für Anwesenheit, sondern für Belege bezahlen. Anschließend begründete er diese These mit recht wenigen eigenen Belegen. Diese Kritik ist berechtigt, und ich werde das hier korrigieren. Alles Folgende, das sich belegen lässt, ist mit Quellen versehen.

Die Bilanz

Überzeugung 1: Ergebnisbasierte Preise bestätigen sich und setzen sich schneller durch

Wir sagten, dass sich die Preise für ERP-Transformation von der Abrechnung nach Aufwand hin zu Ergebnissen verschieben würden. Davon bin ich heute stärker überzeugt als im Januar.

Überzeugt hat mich die Nachfrageseite. Unternehmen sind nicht mehr bereit, die Tagessätze von vor fünf bis zehn Jahren zu zahlen. Das ist die ganze Geschichte in einem Satz. Es ist kein philosophischer Wandel hin zu „wertbasierter Preisgestaltung“, sondern eine Budgetrealität, die Finanzvorstände längst einkalkuliert haben und die jeder Partner im Ökosystem spürt.

Wenn Ihr Tagessatz unter Druck steht und Ihre Marge davon abhängt, haben Sie drei Möglichkeiten.

Verlagerung ins Nearshore- oder Offshore-Modell. Das ist die häufigste Antwort und für sich genommen die schwächste. Sie verlagert Kosten, verändert aber nicht die Leistung pro Person. Es werden weiterhin genauso viele Stunden gebraucht, um Kontext wiederherzustellen, der zwischen Explore und Realize verloren ging. Gerade bei SAP-Projekten verbraucht der Koordinationsaufwand eines verteilten Modells oft einen beträchtlichen Teil des Kostenvorteils.

Umsetzung mit weniger Personal. Der Instinkt ist richtig, aber es funktioniert nur, wenn die Leistung pro Person steigt. Sonst wird lediglich ein langsameres Projekt als schlankeres verkauft. Kleinere Teams ohne bessere Werkzeuge sind ein Versprechen, das sich schon nach dem zweiten Sprint nicht mehr halten lässt.

Die richtigen Plattformen nutzen. Das ist die einzige der drei Möglichkeiten, die die zugrunde liegende Wirtschaftlichkeit verändert, statt sie nur umzuverteilen. Gleichzeitig ist das Ökosystem darauf am wenigsten vorbereitet.

Die Build-or-Buy-Frage, die niemand beantworten möchte

Was ich derzeit im SAP-Partnerökosystem sehe: viele Eigenentwicklungen. Beschleuniger, GPT-Wrapper, interne Dokumentgeneratoren und Prompt-Bibliotheken, die als Plattformen präsentiert werden.

Ich verstehe den Impuls. Softwaremargen wirken attraktiv, wenn Dienstleistungsmargen sinken, und jeder Partner hat einen Architekten, der innerhalb eines Quartals einen Prototyp entwickeln kann.

Trotzdem wäre ich vorsichtig. Einen internen Beschleuniger zu entwickeln und Software zu bauen, sind unterschiedliche Geschäfte. Software bedeutet eine Sicherheitsprüfung durch jeden Unternehmenskunden, eine Roadmap, die mit dem Release-Takt von SAP Schritt hält, ein Supportmodell auf ISV-Niveau und Wartungskosten, die nie auf null sinken. Die meisten Partner haben diese Fähigkeiten nicht im Haus. Die ehrlichen werden Ihnen sagen, dass der Prototyp Spaß gemacht hat, das zweite Jahr aber nicht.

Die Frage für einen Partner-CEO im Jahr 2026 lautet also nicht: Können wir das bauen. Sie lautet: Wird uns ein selbst entwickeltes Werkzeug vom Wettbewerb abheben oder unsere Umsetzungskompetenz? Für die meisten ist es Letzteres. Darin liegt die Chance, und deshalb halte ich das Partnerökosystem für einen Markt, nicht für einen Wettbewerber.

Noch ein Punkt, weil er im Januar-Beitrag nicht deutlich genug war: Ergebnisbasierte Preise sind kein Argument gegen Beratungen. Sie belohnen denjenigen, der bei vertretbarer Qualität am meisten leistet. Wer das schafft, erhöht seine Marge. Bestraft werden nur Unternehmen, deren Modell davon lebt, dass die Uhr weiterläuft.

Wo ich weiterhin falsch liegen könnte: bei der Zuordnung von Verantwortung. Wenn die Einführung scheitert, weil das Change Management des Kunden schwach war, wer trägt das? Niemand hat das sauber gelöst. Es ist der wichtigste einzelne Grund dafür, dass ergebnisbasierte Preise seit zwanzig Jahren vorhergesagt werden, ohne sich vollständig durchzusetzen. Neu ist heute, dass endlich die Werkzeuge existieren, um zu belegen, wer was geleistet hat. Das ist notwendig. Ob es ausreicht, weiß ich noch nicht sicher.

Überzeugung 3: Governance bestätigt sich, aus einem unerwarteten Grund

Im Januar argumentierten wir, dass KI nur unter unternehmenstauglicher Kontrolle Einzug in die ERP-Umsetzung halten würde: klare Datengrenzen, minimale Berechtigungen, Prüfprotokolle, Versionierung und deterministische Ergebnisse.

Das gilt alles weiterhin. Inzwischen sind es jedoch Grundvoraussetzungen. Jeder ernstzunehmende Anbieter erfüllt sie. Sie erklären also nicht mehr, warum Unternehmen zögern.

Das eigentliche Hindernis 2026 ist finanzielle Planbarkeit.

SAP hat KI auf eine verbrauchsbasierte Preisgestaltung umgestellt. Christian Klein sagte es im März deutlich: „Es wäre töricht, weiterhin auf Abonnementbasis abzurechnen, denn KI ist so leistungsfähig, dass sie viele Aufgaben automatisieren wird.“¹ Seit Juli 2026 sind nutzungsbasierte KI-Preise das Standardmodell für Cloud-Vertragsverlängerungen.² Die Richtung von SAP halte ich für richtig. Aber schauen wir uns an, was das für das Budget eines CIO bedeutet.

Bei AI Units wird ein großer Teil des Verbrauchs durch Hintergrundprozesse statt durch ausdrückliche Nutzeraktionen ausgelöst. Agentische Workflows verbrauchen erheblich mehr als interaktive: Ein agentischer Genehmigungsprozess mit hohem Volumen kann in einer Woche mehr Einheiten verbrauchen als eine abfragebasierte Bereitstellung in einem Monat.² Mehrverbrauch wird außerhalb des üblichen Abrechnungszyklus in Rechnung gestellt. Und Unternehmen haben praktisch keine institutionelle Erfahrung darin, solche Ausgaben zu prognostizieren.

Darüber spreche ich tatsächlich mit Kunden. Nicht darüber, ob es sicher ist. Sondern: Was wird mich das im nächsten Quartal kosten, und was hat mir das vergangene Quartal dafür gebracht?

Deshalb würde ich die Überzeugung neu formulieren. Governance ist 2026 nicht nur ein Kontrollproblem, sondern auch ein Prognoseproblem. Ein Governance-Modell, das die Kostenfrage nicht beantworten kann, ist unvollständig, unabhängig von der Qualität seines Prüfprotokolls.

Daraus ergeben sich zwei Konsequenzen.

Erstens ist SAP zu Recht vorsichtig. Das sage ich als jemand, dessen Unternehmen wirtschaftlich davon profitieren würde, wenn SAP schneller vorginge. Agenten, die mit produktiven Unternehmensdaten arbeiten, also echten Stammdaten und Finanzbuchungen, sind eine schwierige Aufgabe. Die Reputationsschäden eines Fehlers in der Größenordnung von SAP wären unverhältnismäßig hoch. Vorsicht ist hier kein Konservatismus, sondern die richtige Reihenfolge.

Zweitens erklärt dies, warum so viele Unternehmen noch in der Pilotphase stecken. Sie zweifeln nicht an der Wirkung. Die meisten Führungskräfte, mit denen ich spreche, sind überzeugt, dass KI die ERP-Umsetzung erheblich verändern wird. Sie können aber noch keinen Business Case aufstellen, weil sie weder die Kosten begrenzen noch den Nutzen zuordnen können. Solange die Ausgaben nicht prognostizierbar sind, lassen sie sich nicht genehmigen. Deshalb wird aus dem Pilotprojekt kein Programm.

In den nächsten zwölf Monaten werden diejenigen Anbieter gewinnen, die den Verbrauch nachvollziehbar machen: welche Ausgaben für welches Arbeitsergebnis und welche Entscheidung angefallen sind und was sie ersetzt haben.

Überzeugung 2: Arbeitsergebnisse zuerst – wo ich meine Meinung geändert habe

Diese Überzeugung würde ich umschreiben.

Im Januar behaupteten wir, leistungsstarke Programme würden Workshops bis Ende 2026 als letztes Mittel ansehen, weniger Besprechungen durchführen und mehr Arbeitsergebnisse pro Woche erstellen. Der Grundgedanke war richtig: In der Discovery verlieren ERP-Programme Zeit, und die manuelle Aufbereitung verschwendet Aufwand.

Aber die Maßeinheit war falsch.

Der Engpass in Explore ist nicht das Erstellen des Arbeitsergebnisses. Es ist die Bestätigung, also zu prüfen, ob eine dokumentierte Anforderung die geschäftliche Absicht tatsächlich wiedergibt, und die Prozessverantwortlichen dazu zu bringen, dafür einzustehen. Dieser Teil ist komplex, politisch und wird nicht kürzer, nur weil das Dokument schneller erstellt wurde. Wer nur die Menge der Arbeitsergebnisse optimiert, produziert mehr Dokumente, die dieselbe mühsame Validierung brauchen. Die Warteschlange wurde damit nur verschoben, nicht verkürzt.

Ich habe außerdem einen strukturellen Punkt unterschätzt. Mehr Arbeitsergebnisse zu produzieren bringt wenig, wenn sie an voneinander getrennten Orten landen. Genau das ist das Problem der SAP-Landschaft: Die geschäftliche Absicht steckt in Workshops und Transkripten, die Architektur in SAP LeanIX, Prozesse in SAP Signavio und Anforderungen, Backlogs sowie Testfälle in SAP Cloud ALM. SAP baut zwischen diesen drei Werkzeugen eine Integrated Tool Chain mit einem einheitlichen Metamodell auf. Diese Richtung ist richtig.³ Die Werkzeuge einzuführen ist aber nicht dasselbe, wie die Begründungszusammenhänge zu verbinden, die sich durch sie ziehen.

Was ich heute glaube

Die Einheit des Fortschritts ist nicht das Arbeitsergebnis, sondern die verknüpfte, nachvollziehbare Entscheidung.

Die geschäftliche Absicht muss mit ihrer tatsächlichen Komplexität erfasst, in die bereits vorhandenen Werkzeuge der SAP-Toolchain übertragen, um den Kontext realer Geschäftsfähigkeiten ergänzt und über jede Phase hinweg nachvollziehbar gehalten werden. So kann sechs Monate später jeder fragen: Warum wurde diese Entscheidung getroffen, auf welcher Grundlage und von wem? Und die Antwort kommt in Sekunden, statt eine aufwendige Spurensuche zu erfordern.

Diese Ebene fehlt heute. Die einzelnen Werkzeuge sind leistungsfähig und zunehmend eigenständig. Die verbindende Schicht, die Absichten aufnimmt, Entscheidungen durchgängig nachvollziehbar macht und Belege liefert, schafft den eigentlichen Wert. Keines dieser Werkzeuge wird sie allein abdecken.

Dahinter steht auch eine Verschiebung der Verantwortung. Diese Art von Nachvollziehbarkeit lag bisher beim Systemintegrator: in seiner Methodik, seinen Vorlagen und den Köpfen seiner Mitarbeitenden. Unternehmen wollen sie zunehmend selbst besitzen. Sie möchten die Entscheidungshistorie im eigenen System haben, für sich sichtbar und über das Ende eines Auftrags oder den Wechsel des Projektteams hinaus verfügbar. Ich halte das nicht für eine Absage an Beratung. Es ist eine Absage daran, dass der Kontext das Haus verlässt, sobald der Vertrag endet.

Zusammen verändert das die Wirtschaftlichkeit an einem bestimmten Punkt: beim Verhältnis von Software- zu Implementierungsausgaben. Heute fließt ein unverhältnismäßig großer Anteil des Transformationsbudgets in menschliche Arbeit, die Informationen zusammenträgt, abgleicht und erneut erklärt, obwohl ein vernetztes System sie vorhalten sollte. Wird ein Teil dieser Ausgaben in Software verlagert, die Absichten, Verbindungen und Nachvollziehbarkeit bewahrt, und werden Experten für die Entscheidungen eingesetzt, bei denen sie unersetzlich sind, entsteht mehr Transformation pro Euro. Nicht durch den Verzicht auf Experten, sondern dadurch, dass sie keine verlorenen Zusammenhänge mehr rekonstruieren müssen.

Darauf setzen wir. Fehlerhaft ist der Teil des traditionellen SAP-Beratungsmodells, der nach Anwesenheit abrechnet und die Zusammenhänge in den Köpfen Einzelner bewahrt. Qorelo wurde entwickelt, um genau diesen Teil zu ersetzen, direkt auf der SAP-Toolchain statt daneben.

Was ich ERP-Verantwortlichen für den Rest des Jahres 2026 raten würde

Verhandeln Sie über Leistung statt über Tagessätze. Wer Tagessätze drückt, ohne die Arbeitsweise zu verändern, bekommt lediglich ein unerfahreneres Team. Fragen Sie Ihren Partner, wie viel jede Person pro Woche leistet und wie er das belegt.

Machen Sie den KI-Verbrauch vor der Skalierung prognostizierbar. Benennen Sie einen Verantwortlichen. Berichten Sie monatlich über den Verbrauch je Anwendungsfall. Trennen Sie fest zugesagte Ausgaben vom Risiko durch Mehrverbrauch. Wer nach Juli 2026 ohne diese Grundlage verlängert, akzeptiert einen unbegrenzten Kostenposten.²

Fragen Sie, wo Ihre Entscheidungshistorie liegt. Lautet die Antwort „in der Methodik des Partners“, gehört Ihnen Ihre Transformation nicht. Sie mieten sie.

Kaufen Sie keine Werkzeuge mehr, die sich nicht verbinden lassen. Ein eigenständiges Werkzeug, das schöne Arbeitsergebnisse in ein Silo liefert, schafft eine zusätzliche Abstimmungsaufgabe. Kaufen Sie für die Übergänge.

Zum Abschluss

Zwei unserer drei Überzeugungen aus dem Januar bestätigen sich. Eine davon aus einem Grund, den wir nicht vorhergesehen haben: Bei Governance geht es um Prognosen, nicht nur um Kontrolle. Bei der dritten war meine Diagnose richtig, meine Empfehlung aber falsch. Das Problem in Explore ist nicht die Menge der Arbeitsergebnisse, sondern die Verknüpfung nachvollziehbarer Entscheidungen über eine Toolchain hinweg, die noch nicht miteinander kommuniziert.

Im Januar veröffentlichen wir die Jahresbilanz, einschließlich allem, worin wir bis dahin noch falsch liegen.

Quellen

1. Klein, C., Bloomberg-Interview, 18. März 2026, zitiert in SAP stellt auf verbrauchsbasierte KI-Preise um, während Agenten das SaaS-Umsatzmodell bedrohen, ERP Today.
2. SAPs Wechsel zu nutzungsbasierten KI-Preisen: Was jeder Unternehmenseinkäufer vor Juli 2026 verstehen muss – zur Funktionsweise von AI Units, zum Verbrauch durch Hintergrundprozesse und Agenten, zur Abrechnung von Mehrverbrauch und zu Anforderungen an die Verbrauchssteuerung.
3. SAP Integrated Tool Chain – SAP LeanIX, SAP Signavio und SAP Cloud ALM: Wem gehören welche Daten in der agentengesteuerten Toolchain?, SAP Community; sowie Integration von SAP LeanIX, SAP Signavio und SAP Cloud ALM für ein einheitliches Metamodell, SAP Learning.
4. Unsere Überzeugungen zur ERP-Transformation 2026, Qorelo, Januar 2026: der Beitrag, dessen Aussagen dieser Artikel bewertet.