1. Was wir aus dem Clip lernen können

Der obige Clip veranschaulicht zahlreiche Aspekte, die typisch für eine „Veränderungsillusion“ sind:

🐢 1. „Chef, wir haben die Entscheidung zur Veränderung falsch verstanden!“

„Sie sagten, wir sollten eine neue Fabrik bauen. Aber niemand hat uns genau gesagt, was die Fabrik eigentlich produzieren sollte. Also haben wir einfach alles gebaut, was uns einfiel.“

→ Kernaussage: Veränderung ≠ Umfang. Ohne konkrete Vorgaben entsteht Chaos.

🎢 2. „Die Achterbahn war Teil der ‚Produktivitätssteigerung‘!“

„Wir dachten, wenn die Sardinen schneller rutschen, würden wir mehr produzieren. Also haben wir eine Achterbahn gebaut, damit die Dosen schneller durch die Halle sausen können.“

→ Kernaussage: Wenn Entscheidungen über Veränderungen ohne klare Anforderungen getroffen werden, entstehen absurde Lösungen.

🏊 3. „Das Schwimmbecken war ein Sicherheitsziel!“

„Der Lenkungsausschuss sagte, wir bräuchten mehr Sicherheit. Also bauten wir ein Schwimmbecken, damit niemand hart auf dem Boden aufschlägt, wenn er von der Achterbahn fällt.“

→ Kernaussage: Vage Veränderungen führen zu Ergebnissen, die nichts mit dem Ziel zu tun haben.

🛶 4. „Die Dosenboote waren ein Projekt zur Prozessharmonisierung!“

„Sie sagten, wir sollten die Prozesse harmonisieren. Wir wussten nicht, welche. Also haben wir die Dosen in Boote verwandelt, damit alle Mitarbeiter denselben Weg in ihre Pause nehmen.“

→ Kernaussage: Ohne klare Ergebnisse führt „Harmonisierung“ zu absurden Interpretationen.

🐟 5. „Die fliegenden Sardinen waren ein Innovationsziel!“

„Sie sagten, wir sollten innovativ sein. Also haben wir Flügel für die Sardinen gebaut. Jetzt fliegen sie überall herum und rufen ‚Caipirinha!‘“

→ Kernaussage: Innovation ohne definierten Umfang führt zu Chaos statt zu Fortschritt.

🧨 6. „Wir haben die Entscheidung zur Veränderung schrittweise weiter ausgearbeitet … bis sie explodierte.“

„Sie sagten: Neue Fabrik. Daraus wurde dann: neue Halle → neue Maschine → neue Prozesse → neue Sicherheitskonzepte → neue Freizeitaktivitäten → neue Mitarbeiterzufriedenheit → neue Achterbahn → neues Schwimmbad → neue Schule für fliegende Sardinen.“

→ Kernaussage: Das ist die „Veränderungsillusion“: Man arbeitet die Veränderung aus, nicht den Umfang.

📦 7. „Wir hatten keine konkreten Ergebnisse, also haben wir einfach welche erfunden.“

„Niemand hat uns gesagt, was wir eigentlich liefern sollten. Also haben wir einfach alles geliefert, was uns einfiel. Sogar die Sardinenboote. Und die Sardinen-Flugschule. Und die Wartungspläne für die Achterbahn.“

→ Kernaussage: Ohne definierte Ergebnisse gerät der Umfang außer Kontrolle.

Definition:

Die „Veränderungsillusion“ ist die falsche Annahme, dass die Entscheidung für eine Veränderung automatisch den Arbeitsumfang definiert.

Sie tritt auf, wenn Organisationen eine übergeordnete Veränderung („Wir brauchen eine neue Fabrik“, „Wir brauchen mehr Sicherheit“, „Wir brauchen Harmonisierung“) so behandeln, als enthalte sie bereits die für ihre Umsetzung erforderlichen konkreten Ergebnisse.

Diese Illusion führt dazu, dass Teams die Veränderung selbst ausarbeiten – indem sie Ideen, Interpretationen und Annahmen hinzufügen –, anstatt die tatsächlichen Ergebnisse zu definieren. Infolgedessen wird der Aufwand auf der falschen Ebene geschätzt, der Umfang gerät außer Kontrolle und Projekte versinken im Chaos.

3. Die Festlegung des Projektumfangs (Umfangsausarbeitung) anstelle der Festlegung der Leistungen (Leistungsausarbeitung)

Das Problem bei diesen Workshops besteht darin, dass sie nicht auf die Ergebnisse, sondern vielmehr auf den Umfang eingehen.

3.1. Warum „Fit-to-Standard“-Workshops Veränderungen definieren

Auf den ersten Blick scheinen „Fit-to-Standard“-Workshops klassische Anforderungsworkshops zu sein, doch aus methodischer Sicht verfolgen sie einen völlig anderen Ansatz. Sie definieren nicht den angestrebten Geschäftszustand, sondern untersuchen vielmehr, inwieweit der bestehende Ist-Zustand an den SAP-Standard angepasst werden kann. Der Fokus liegt nicht auf der Frage „Was wollen wir erreichen?“, sondern auf der Frage „Wie müssen wir unseren aktuellen Zustand ändern, damit er mit dem Standard übereinstimmt?“ Dies beschreibt nicht den Zielzustand, sondern die Änderung am aktuellen Zustand – also eine Änderung. Die Diskussion dreht sich um Prozessvarianten, Systemverhalten, Konfigurationsoptionen und Abweichungen vom Standard. Sobald eine Lücke identifiziert wird, ergibt sich automatisch eine Änderung: eine Entscheidung darüber, wie der Ist-Zustand angepasst werden soll. „Fit-to-Standard“ ist daher keine Anforderungsdefinition, sondern vielmehr die systematische Ausarbeitung von Änderungen, die sich aus der Entscheidung „Wir führen SAP ein“ ergeben.

3.2. Warum technische RICEFW-Workshops Änderungen ausarbeiten

Auch die technischen Workshops, die sich mit RICEFW-Objekten befassen, behandeln keine Anforderungen, sondern die konkrete Ausgestaltung der zuvor im „Fit-to-Standard“-Prozess identifizierten Änderungen. Eine Anforderung würde den geschäftlichen Nutzen beschreiben, den ein Bericht, eine Schnittstelle oder ein Formular bieten soll. In den RICEFW-Workshops liegt der Fokus jedoch nicht auf dem Nutzen oder dem Zielzustand, sondern auf der technischen Umsetzung: Datenfelder, Tabellen, Funktionsbausteine, Zuordnungslogik, Triggerpunkte und benutzerdefinierter Code. Hierbei handelt es sich um reine Änderungsausarbeitung. Die Workshops klären, wie die zuvor getroffenen Änderungsentscheidungen technisch umgesetzt werden sollen. Sie definieren nicht die betriebswirtschaftlichen Anforderungen, sondern vielmehr die technischen Änderungen am System. Somit sind RICEFW-Workshops ein Paradebeispiel dafür, wie SAP-Projekte direkt in die Umsetzung einsteigen, ohne jemals den angestrebten betriebswirtschaftlichen Zustand zu formulieren.

3.3. Warum und wie Workshops Änderungen ausarbeiten

Auch Migrationsworkshops erscheinen oft als geschäftsorientierte Sitzungen, doch auch sie befassen sich mit der Ausarbeitung von Änderungen. Die Migration selbst ist eine Änderung: die Entscheidung, den aktuellen Zustand der Daten zu verändern, um sie in das neue System zu übertragen. Die Workshops definieren nicht die geschäftlichen Anforderungen an die Daten, sondern vielmehr, wie die vorhandenen Daten transformiert werden müssen, damit sie in SAP funktionieren. Der Schwerpunkt liegt auf Zuordnung, Bereinigung, struktureller Anpassung und technischer Übertragung. Dies ist keine Definition von Anforderungen, sondern vielmehr die Ausarbeitung einer Veränderung, die bereits im Projektleitfaden festgehalten ist: „Wir migrieren unsere Daten in SAP.“ Die Workshops klären die Umsetzung dieser Veränderung, nicht den angestrebten geschäftlichen Zustand hinsichtlich Datenqualität oder Datenprozessen. Somit sind Migrationsworkshops ebenfalls Teil der Ausarbeitung von Veränderungen – und nicht Teil der Anforderungserfassung.

3.4. Warum organisatorische Workshops Veränderungen konkretisieren

Auf den ersten Blick scheinen die Organisationsworkshops – die sich auf Unternehmensstrukturen, Berechtigungen und Sicherheitskonzepte konzentrieren – strategischer und technischer Natur zu sein. Allerdings definieren auch sie keine Anforderungen, sondern vielmehr die strukturellen Veränderungen, die erforderlich sind, um SAP überhaupt nutzen zu können. Die Definition von Buchungskreisen, Werken, Vertriebsorganisationen oder Rollenprofilen ist keine Beschreibung eines Sollzustands, sondern vielmehr eine Entscheidung darüber, wie der aktuelle Zustand des Unternehmens im System abgebildet werden soll. Diese Entscheidungen verändern die Organisation – und sind somit Veränderungen. Die Workshops klären nicht, was das Unternehmen aus geschäftlicher Sicht erreichen möchte, sondern vielmehr, wie es sich strukturell verändern muss, um SAP nutzen zu können. Auch hier wird kein Produktumfang definiert; stattdessen liegt der Fokus auf der Formulierung der Veränderungsentscheidung: „Wir führen SAP ein.“ Die aus diesen strukturellen Veränderungen resultierenden Ergebnisse werden erst später sichtbar – in Form von Organisationsmodellen, Rollenmatrizen, Sicherheitskonzepten und Systemkonfigurationen.

4. Ein vorläufiges Projekt als Lösung?

4.1. Warum eine zweite Aufwandsschätzung unbedingt erforderlich ist

Erst nach den Workshops ergibt sich erstmals ein realistisches Bild der tatsächlichen Änderungen. Erst jetzt ist dem Projekt bekannt, welche Prozessanpassungen, Erweiterungen, Schnittstellen, Datenmigrationen und organisatorischen Veränderungen tatsächlich erforderlich sind. Die ursprüngliche Aufwandsschätzung basiert jedoch fast immer auf der Änderungsentscheidung aus der Charta – also auf einer groben Vorstellung wie „Wir führen SAP ein“ oder „Wir harmonisieren Prozesse“. Diese Schätzung ist zwangsläufig ungenau, da sie nicht auf konkreten Leistungen basiert. Eine zweite Aufwandsschätzung wäre daher nicht nur sinnvoll, sondern methodisch unerlässlich: Erst nach der Workshop-Phase liegen tatsächlich die Informationen vor, die für eine korrekte Ermittlung des Aufwands erforderlich sind. Ohne diese zweite Schätzung plant das Projekt auf der Grundlage einer Illusion – und stößt an eine Wand, weil die tatsächlichen Leistungen nie bewertet wurden.

4.2. Warum ein Vorprojekt die einzig sinnvolle Lösung wäre

Ein Vorprojekt würde genau das leisten, was die SAP-Methodik auslässt: Es würde den Rahmen schaffen. Es würde den angestrebten Geschäftszustand definieren, die Ergebnisse identifizieren, die Änderungen bewerten und die Outcome Delivery Structure vorbereiten. Ein Vorprojekt wäre die Phase, in der die „Veränderungsillusion“ ausgeräumt wird und die Ergebnisse sichtbar werden. Erst dann könnte ein Projekt ordnungsgemäß geplant werden. In der Praxis wird dieser Schritt jedoch fast immer übersprungen. Anstatt ein Vorprojekt durchzuführen, stürzen sich die Beteiligten direkt in die Workshops – und damit direkt in die Phase der Veränderungsausarbeitung. Das Projekt beginnt mit der Lösung, noch bevor das Problem definiert wurde. Ein Vorprojekt wäre die methodisch korrekte Antwort auf die „Veränderungsillusion“, wird jedoch selten durchgeführt, da es Zeit, Geld und Klarheit erfordert – drei Dinge, die in frühen Projektphasen oft als „verzögernde“ Faktoren wahrgenommen werden.

4.3. Warum diese Lösung systematisch abgelehnt wird

Die Ablehnung einer zweiten Aufwandsschätzung oder eines Vorprojekts ist kein Zufall, sondern ein strukturelles Muster. Organisationen wollen schnelle Entscheidungen, klare Budgets und feste Zeitpläne – lange bevor klar ist, was tatsächlich umgesetzt werden muss. Eine zweite Schätzung würde offenbaren, dass die ursprüngliche Planung unrealistisch war. Ein Vorprojekt würde zeigen, dass die Änderungsentscheidung nicht mit den Anforderungen übereinstimmt. Beides würde die Illusion zerstören, dass das Projekt „unter Kontrolle“ sei. Deshalb wird die methodisch korrekte Lösung abgelehnt: Sie würde Transparenz schaffen, wo bisher nur Hoffnung herrschte. Die Illusion der Veränderung ist angenehm, weil sie den falschen Eindruck von Planungssicherheit vermittelt. Die Realität der zu erbringenden Leistungen ist unbequem, weil sie Aufwand, Risiko und Komplexität offenlegt. Genau deshalb wird die fundierte Lösung systematisch verhindert.

4.4. Warum Projekte ohne diese Lösung unweigerlich scheitern

Fehlt die zweite Aufwandsschätzung und wird kein Vorprojekt durchgeführt, basieren die Projektpläne auf der „Veränderungsillusion“. Änderungen werden als Umfang verkauft, obwohl der Umfang nur auf der Ebene der Teilergebnisse existiert. Der Aufwand wird auf der Ebene der Änderungen geschätzt, obwohl sich der Aufwand ausschließlich aus den Ergebnissen ergibt. Risiken werden unterschätzt, da die Ergebnisse unbekannt sind. Abhängigkeiten werden übersehen, da die Ergebnislieferungsstruktur (Outcome Delivery Structure) nicht definiert wurde. Und die Umstellung verläuft chaotisch, da POD → OD nur funktioniert, wenn Ergebnisse vorhanden sind. Das Projekt scheitert nicht, weil die Beteiligten schlechte Arbeit leisten, sondern weil die Methodik den Rahmen nie festgelegt hat. Ohne die zweite Schätzung und ohne ein Vorprojekt verharrt das Projekt im Dunkeln – und gerät unweigerlich aus der Bahn, da es nie wusste, wo der Rahmen tatsächlich lag.

4.5. Warum die Lösung nur funktioniert, wenn die Arbeitsergebnisse zunächst aus den ausgearbeiteten Änderungen abgeleitet werden

Damit eine zweite Schätzung und eine Zeitaufwandsschätzung überhaupt funktionieren können, muss zwischen der Ausarbeitung der Änderungen und der Planungsphase ein Schritt eingefügt werden – ein Schritt, der in SAP-Projekten fast immer fehlt: die Ableitung der Arbeitsergebnisse. Erst wenn klar ist, welche Arbeitsergebnisse sich aus den identifizierten Änderungen ergeben, kann ein Projekt realistisch bewertet werden. Die Workshops liefern lediglich die Änderungsentscheidungen – also die Beschreibung, wie der Ist-Zustand verändert werden soll. Aufwand, Risiko und Komplexität ergeben sich jedoch nicht aus der Änderungsentscheidung selbst, sondern vielmehr aus den Auslieferungsgegenständen, die sich aus dieser Entscheidung ergeben. Eine Lücke im „Fit-to-Standard“ ist kein Element des Projektumfangs, sondern ein Hinweis darauf, dass ein Ergebnis erstellt werden muss. Eine Erweiterung ist kein Aufwandsfaktor, sondern vielmehr ein Bündel von Ergebnissen wie Spezifikationen, Entwicklungsartefakte, Testfälle, Dokumentation und betriebliche Genehmigungen. Eine Datenmigration ist keine Aufgabe, sondern eine Vielzahl von Ergebnissen wie Zuordnungstabellen, Bereinigungsregeln, Transformationsskripte, Testläufe und Abnahmeberichte.

Solange diese Ergebnisse nicht sichtbar sind, tappt das Projekt im Dunkeln. Die Änderungsausarbeitung liefert lediglich die Idee der Änderung, nicht jedoch die Arbeit selbst. Erst die Ableitung der Arbeitsergebnisse zeigt, was tatsächlich entwickelt, getestet, dokumentiert und übergeben werden muss. Ohne diesen Schritt ist jede Aufwandsschätzung zwangsläufig falsch, da sie auf einer Governance-Entscheidung basiert und nicht auf den Arbeitsergebnissen, die den Produktumfang ausmachen. Die zweite Schätzung kann daher erst erfolgen, sobald die Ergebnisse klar definiert sind – und nicht vorher. Es handelt sich dabei nicht um eine „Korrektur“ der ersten Schätzung, sondern vielmehr um die erste realistische Schätzung überhaupt, da sie auf der Outcome Delivery Structure basiert und nicht auf der „Änderungsillusion“.

Genau aus diesem Grund wäre ein Vorprojekt so wertvoll: Es würde die Ergebnisse aus den Änderungen ableiten, bevor das eigentliche Projekt beginnt. Da dieser Schritt jedoch Zeit, Geld und Transparenz erfordert, wird er in der Praxis oft abgelehnt. Das Unternehmen verlangt frühzeitig Budgets, Zeitpläne und Zusagen, obwohl die Ergebnisse noch gar nicht bekannt sind. Dadurch wird die „Veränderungsillusion“ aufrechterhalten: Es wird ein Projekt geplant, dessen Umfang nie definiert wurde. Die Lösung liegt daher auf der Hand: Leiten Sie zunächst die Ergebnisse aus den ausgearbeiteten Veränderungen ab, schätzen Sie dann Aufwand und Zeit – und entscheiden Sie erst dann, ob das Projekt in dieser Form überhaupt realisierbar ist.

5. Warum SAP Activate den wichtigsten Schritt bei der Projektplanung nicht berücksichtigt

5.1. SAP Activate ist eine Implementierungsmethodik, keine Methodik zur Festlegung des Projektumfangs

SAP Activate wurde nie dazu konzipiert, den Geschäftsumfang zu definieren. Activate ist eine Beschleunigungsmethodik, die davon ausgeht, dass der Umfang bereits klar ist – auch wenn dies in der Realität nie der Fall ist. Die Methodik setzt voraus, dass das Unternehmen weiß, was es erreichen möchte, und dass sich die Ergebnisse bereits implizit aus dem SAP-Standard ableiten lassen. Doch das trifft nicht zu. Activate geht von der Lösung (dem SAP-Standard) aus, nicht vom Problem (der Anforderung). Deshalb fehlt der Schritt der Ableitung der Ergebnisse: Die Methodik geht davon aus, dass der Umfang „im Standard verankert“ ist und nicht erst sichtbar gemacht werden muss. Dies ist ein methodischer Kurzschluss, der in der Praxis zu Illusionen hinsichtlich des Umfangs führt.

5.2. SAP Activate basiert auf der Annahme, dass der Standard den Umfang definiert

Der Kern von Activate ist „Fit-to-Standard“. Dies setzt implizit voraus, dass der SAP-Standard den Umfang vorgibt. Wenn der Standard den Umfang vorgibt, besteht theoretisch kein Bedarf an einer Ableitung von Arbeitsergebnissen – da der Umfang ja bereits definiert wäre. In der Realität ist der Standard jedoch nur ein Ausgangspunkt. Jede Abweichung führt zu Änderungen, und jede Änderung führt zu Leistungen. Activate überspringt diesen Schritt, da die Methodik davon ausgeht, dass die Abweichungen geringfügig sind und dass sich die Leistungen „von selbst ergeben“. Dies ist eine Illusion. In realen Projekten entstehen Hunderte von Leistungen, die niemals benannt, niemals geschätzt und niemals geplant werden. Activate ignoriert diesen Schritt, da die Methodik den Umfang im Standard verortet – nicht im Projekt.

5.3. SAP Activate vermeidet bewusst alles, was den Aufwand sichtbar macht

Ein weiterer Grund ist politischer Natur: Die Ableitung von Ergebnissen würde sofort offenbaren, wie groß das Projekt tatsächlich ist. Es würde zeigen:

  • wie viele Erweiterungen entwickelt werden müssen
  • wie viele Testfälle erstellt werden
  • wie viele Datenobjekte migriert werden
  • wie viele Rollen definiert werden müssen
  • wie viele Dokumente erstellt werden müssen

Mit anderen Worten: Dies würde den tatsächlichen Aufwand offenlegen.

Activate umgeht diesen Schritt, da er die Illusion zerstören würde, dass SAP-Implementierungen schnell, schlank und „Best Practice“ sind. Die Methodik ist darauf ausgelegt, Projekte verkaufsfähig zu machen – nicht planbar. Die Ableitung von Leistungen würde die Komplexität offenlegen und somit die Vertriebslogik der Activate-Methodik untergraben. Aus diesem Grund wird dieser Schritt systematisch ausgelassen.

5.4. SAP Activate konzentriert sich auf die Ausarbeitung von Veränderungen statt auf die Definition von Leistungen

Der wichtigste Punkt ist methodischer Natur: „Activate“ konzentriert sich vollständig auf die Ausarbeitung von Veränderungen.

„Fit-to-Standard“ ist die Ausarbeitung von Veränderungen. RICEFW-Workshops sind die Ausarbeitung von Veränderungen. Die Datenmigration ist die Ausarbeitung von Veränderungen. Die Organisationsstruktur ist die Ausarbeitung von Veränderungen.

Activate definiert, wie der Ist-Zustand verändert wird – niemals jedoch, wie das daraus resultierende Ergebnis aussehen wird.

Die Methodik verfügt über keine Struktur zur Lieferung von Ergebnissen. Sie enthält keine Liste von Ergebnissen. Sie hat keinen Produktumfang. Sie befasst sich ausschließlich mit Veränderungen.

Deshalb fehlt der Schritt der Ableitung von Ergebnissen: „Activate“ ist eine Methodik, die sich ausschließlich mit Veränderungen befasst – und Ergebnisse als „implizit vorhanden“ betrachtet, auch wenn diese in der Realität zunächst sichtbar gemacht werden müssen.

Kurz gesagt:

SAP Activate überspringt die Ableitung von Ergebnissen, da die Methodik davon ausgeht, dass der Umfang bereits im Standardsystem definiert ist, dass die Änderungen den Arbeitsaufwand bestimmen und dass sich die Ergebnisse daraus ganz natürlich ergeben. In der Realität ist dies jedoch falsch – und genau deshalb geraten SAP-Projekte aus der Bahn.

Aktualisierung

Dieser Artikel bietet eine vereinfachte Einführung in die behandelten Konzepte. Eine erweiterte Fassung mit formalen Definitionen, der Outcome Delivery Structure (ODS), den Transitional Deliverables (TD), dem Cutover Deliverable Flow und dem Change-Illusion-Modell ist verfügbar im Change Illusion Journal

List of terms