Transformation Impact Assessment

Wie du von „Wir glauben, das die Transformation wirkt“ zu einer belastbaren Aussage kommst, ohne dich in Perfektion zu verlieren.

Transformation Impact Assessment ist der Weg, die Wirkung deiner Transformation zu bestimmen.

Transformationen sind selten das Problem. Du findest immer Initiativen. Du findest immer gute Absichten. Du findest immer Leute, die „eigentlich genau wissen“, was zu tun wäre. Das Problem ist etwas anderes: Sobald es ernst wird, taucht dieselbe Frage auf. Immer wieder. In jedem Portfolio-Meeting. In jeder Budgetrunde. In jeder Diskussion zwischen Business, IT und Finance:

„Und was bringt das jetzt konkret?“ in $$$ oder EUR oder CHF?

Manchmal wird dann hektisch nach Kennzahlen gesucht. Manchmal werden Storys erzählt. Manchmal wird mit Velocity, Durchsatz oder Zufriedenheit argumentiert. Das ist alles nicht falsch, es ist nur oft nicht stark genug, um echte Entscheidungen zu tragen oder die Finanzabteilung zu überzeugen. Wer, ausser der der Agile/Kanban/COO Community kennt schon WIP oder Littles Law? Am Ende geht es meist um „bang for the buck“. Wir zahlen Dich als Berater, was bekommen wir dafür? Denn Entscheidungsträger brauchen nicht nur Aktivität. Sie brauchen Wirkung. Und zwar so, dass man darüber diskutieren kann. So, dass man sie vergleichen kann. So, dass man sie steuern kann.

Genau darum geht es in diesem Artikel: ein pragmatisches Vorgehen, um Transformation Impact sauber zu erfassen. Schritt für Schritt. Mit einem Rollout, der nicht nur „einführt“, sondern gleichzeitig die Zurechenbarkeit (Attribution) verbessert. Also die Fähigkeit, einer Intervention deren Wirkung zuzuordnen.

Beweise!?

Kann irgendwie bewiesen werden, als kausale Folge, ob eine Intervention X die Wirkung Y hatte? Viele Organisationen behandeln Transformation ja wie ein Labor-Experiment. Sie erwarten „Proof“. Sie erwarten, dass man eindeutig, kausal, zeigen kann: Diese Maßnahme hat genau diesen Effekt verursacht.

In der Realität ist das eine Kontext-Falle, denn wir sind bei einer Transformation nicht in einem Kausalkontext sondern in einem komplexen System. In einem adaptiven psycho-sozialen System um genauer zu sein. Eines, das sich ständig verändert, nie stillsteht und sich permanent innen und aussen anpasst. Kein Ceteris paribus, kein Labor, keine klaren Wirkgrenzen. Zu viele parallele Veränderungen. Zu viele Abhängigkeiten. Zu viel Kontext. Und oft auch zu wenig saubere Daten.

Wenn du hier versuchst, „Proof“ zu liefern, endest du in Endlosdiskussionen. Oder du baust ein Reporting-Monster, das niemand pflegt. Der Ausweg aus diesem Dilemma ist ein Perspektivwechsel, der erstaunlich entlastend wirkt:

Contribution statt Proof.

Du sagst nicht: „Wir beweisen es.“ Du sagst: „Wir machen Wirkung plausibel. Mit Guardrails, Vergleichslogik, Mechanismen und mit transparenter Unsicherheit.“

Der stärkste Hebel: Phasing als eingebautes Attribution-Design.

Viele Transformationen starten (zu) breit. Beispielsweise alle Value Streams oder ARTs gleichzeitig, alle Bereiche gleichzeitig, „Big Bang“, aber bitte agil. Das klingt erst mal entschlossen, es macht aber die eine Sache kaputt die wichtig ist:

Vergleichbarkeit.

Wenn überall gleichzeitig alles geändert wird, kannst du kaum noch unterscheiden, was gewirkt hat. Du bekommst zwar maximale Bewegung, aber kaum bis kein Lernsignal.

Darum ist Phasing nicht nur Rollout-Logik, Phasing wird hier zur Steuerungs- und Attribution-Logik.

Du startest bewusst in Wellen. Zum Beispiel so:

erst ART X1
dann ART X2
dann ART X3 alle im Cluster C1
danach Rollout auf den nächsten Cluster

Das Ergebnis dieses Vorgehens hat den Charm, dass man in gewisser Weise mit einen ART schon im „Treatment“ ist, während die nächsten noch temporär als „Control“ dienen. Das ist nicht perfekt. Es ist

gut genug,

um Wirkung deutlich sauberer zu diskutieren.

Was wird gemessen

Am Anfang brauchst du kein perfektes Finance-Modell. Du brauchst ein Proxy-System, das in deiner Realität gut genug ist und das in Geld-Einheiten übersetzbar wird.

Ein robustes Set, das Reiertsen (2009) empfiehlt und SAFe adaptiert hat:

Time (wie schnell kommt Wirkung an?)
Dev Expense (was kostet Delivery wirklich?)
Product Cost (was kostet Betrieb, Qualität, Support?)
Value (welcher Nutzen wird erzeugt?)
Risk (welche Risiken reduzieren wir messbar?)

Das Schöne an diesem Set ist, du kannst damit klein anfangen: Pro ART, ein kleines Dashboard, Wiederholbar für alle anderen Transformationsschritte. Du musst nicht so tun, als wären deine Zahlen von Tag 1 an perfekt. Gute Zahlen entstehen über die Zeit, man pirscht sich an diese heran.

Transferfunktionen

Das Proxy-System ist gut, aber nicht hinreichend für Finanzen. Wir müssen den Schritt vom „Reporting“ der Proxies hin zu einem und „Economic Framework“ gehen. Niemand will hören: „Time wurde besser.“ Was man in Organisationen gerne hört ist die Antwort auf die Frage: „Wenn Time besser wurde, was bedeutet das konkret in Geld?“

Das geht über Transferfunktionen:

Zeit wird über echten Cost of Delay (CoD) monetarisierbar
Dev Expense und Product Cost sind direkt monetarisierbar
Value wird über Nutzenklassen und Spannen greifbar
Risk wird über (probability x Impact) quantifizierbar

Dabei musst Du nicht angeben, als wüsstest du den CoD für jeden Epic exakt. Das kann je nach betrachteter grösse manchmal etwas komplexer werden. CoD darf am Anfang gerne eine Low/Base/High-Spanne sein. Entscheidend ist, dass du die darunter liegenden Annahmen offenlegst und das du dir die Möglichkeit gibst zu lernen wo das initiale Modell zu grob war.

Damit entsteht etwas, das in der Praxis extrem hilfreich ist:

Eine Economic Storyline: Also die Top-3 Hebel, die in deinem Kontext – hier Cluster C1 – wirklich zählen.

Achtung: CoD in SAFe und Real CoD (in Geld) sind etwas sehr Unterschiedliches. Für Transformation Impact Analysis ist der SAFe CoD (UBV + TC + RR/OE in Fibonacci Zahlen) nicht gut geeignet.

Outcomes ohne Mechanismen = Glaubenskrieg

Ein typisches Muster das entstehen kann: Die Transformation führt neue Praktiken und Regeln ein. Die Kennzahlen werden nach und nach besser. Und dann beginnt der Streit.

„War das die Transformation?“
„War das die neue Strategie?“
„War das dieses Programm ABC?“
„Oder war das das neue Produkt?“
„Oder der neue Leiter?“
„Oder einfach Glück?“

Das ist kein Zeichen von schlechter Zusammenarbeit oder Kommunikation. Es ist ein Zeichen von fehlender Erklärungsbrücke. Outcomes sind in Organisationen immer das Ergebnis vieler Einflussfaktoren. Wenn du nur Outcomes misst, diskutiert ihr zwangsläufig über Interpretationen. Interpretationen sind politisch, oder emotional, oder beides und sehr wahrscheinlich nicht hilfreich. Darum ist die wichtigste Designentscheidung in Impact Assessment diese:

Wir messen nicht zuerst Outcomes. Wir messen zuerst Mechanismen.

Ein Mechanismus ist kein „Event“ und kein „Training“. Ein Mechanismus ist eine Systemeigenschaft, die du über eine Intervention gezielt veränderst. Eine Art interne Physik der Organisation, der Arbeit, der Entscheidungen. Beispielsweise eine Regel, ein Limit, eine Policy, ein Feedback-Loop. Etwas, das das systemische Verhalten stabil beeinflusst:

WIP-Limits: Es sind weniger Dinge gleichzeitig offen. Der Flow wird sichtbarer, Blockaden auch, der Fokus in den Teams steigt.
Batch Size: Arbeit wird kleiner, damit sinken die Risiken. Feedback kommt früher, Rework sinkt, wir lernen schneller.
Cadence: Entscheidungen passieren häufiger. Work driftet weniger. CoD wird spürbar.
Policies: Was „ready“ heißt, was „done“ heißt, was „expedite“ wirklich bedeutet.

Wenn Mechanismen sauber definiert sind, kannst du eine Transformation als das beschreiben, was sie ist:

eine Veränderung im System die Wirkung entfaltet.

Mechanismen sind „Beweisanker“, bevor Outcomes sichtbar werden können

Outcomes brauchen immer Zeit. Sie sind träge, sie sind lagging indicators. Sie kommen oft erst Wochen oder Monate nach einer Intervention. Mechanismen hingegen kippen oft sofort. Das ist unser Gold in der Argumentation.

Wenn du ab Woche 1 siehst, dass WIP wirklich sinkt.
Wenn du ab Woche 2 siehst, dass Batch Sizes wirklich kleiner werden.
Wenn du ab Woche 3 siehst, dass Priorisierung wirklich und sauberer passiert.

… dann hast du ein Signal, das du vorher nicht hattest: Das System verhält sich anders. Dadurch wird die spätere Outcome-Verbesserung nicht „eine Geschichte“, sondern eine plausible Folge.

Du sagst: „Wir sehen, dass sich die Mechanik ändert. Wir erwarten X als Folge, jetzt können wir das auch prüfen.“

Outcomes ohne Mechanismen erzeugen zwei typische Fallen

Falle 1: „Cherry Picking“

Wenn du nur Outcomes hast, sucht sich jede Seite die Kennzahl, die ihre Position stützt. Das ist zutiefst menschlich, aber leider auch toxisch.

Falle 2: „Wirksamkeit wird mit Aktivität verwechselt“

Man kann vieles tun und so dermassen beschäftigt sein, das der Kalender überquillt. Hier Trainings, da Workshops und als Sahnehäubchen neue Rollen, Zertifizierungen, Jira. Dennoch: Die Wirkung ist eher mager, im System verändert sich nichts. Impact bleibt aus oder er kommt zufällig. Ohne klare Mechanismen weiss niemand, was zu wiederholen ist. Kein Lernen, keine Übertragung des Wissens wird so möglich.

Mechanismen verhindern beides. Weil sie dich zwingen, konkret zu werden:
Was genau muss sich im System ändern, damit die Proxy-Achsen kippen?

Meine Praxis: Das Impact-Epic-Template

Ich verwende ein Impact-Epic-Template das es mir erlaubt, meine Interventionen, Annahmen, Hypothesen und Ziele so zu formulieren, das sie in der Organisation anschlussfähig sind und die politische Ebene soweit reduzieren wie es aktuell geht.

Impact Epic Template

0) Meta

Epic Name: <kurz + mechanikfokussiert>
Epic Owner: <Name / Rolle>
Co-Owners: <PM / PO / RTE / Business Sponsor>
Zeitraum (Cycle Time / MVP-Laufzeit): <z. B. 8–12 Wochen>
Scope-Kontext: <ART / Value Stream / Cluster>
Attribution-Default: (α=<z. B. 0.5>) (optional)

1) Epic Hypothesis Statement

For <Zielgruppe / Einheiten / Value Stream>
who <Pain: beobachtbares Problem in Systembegriffen>
the solution <Intervention: Mechanismus-Änderung, kein Aktivitätskatalog>
is a <klarer Betriebsmodus / Policy / Regelwerk>
that <was soll sich dadurch konkret verändern (Systemverhalten)>
unlike <Status quo / bisherige Muster / typische „Bypässe“>
our solution <warum ist dieser Eingriff anders / fokussierter / minimal-invasiv>

2) Business Outcomes

Wenn <Mechanismus> greift, erwarten wir:

Time: <z. B. Median Lead Time ↓, P85 ↓, Aging ↓>
Dev Expense: <z. B. weniger Rework / weniger externe Peaks>
Product Cost: <z. B. Incidents ↓, Tickets ↓, Ops-Last ↓>
Value: <z. B. Nutzenklasse X ↑, bessere Realisierung>
Risk: <z. B. (p\times Impact) sinkt für Risiko A/B>

3) Leading Indicators

Diese Indikatoren müssen sich früh bewegen, sonst ist die Hypothese falsch oder nicht durchsetzbar.

Wähle 3–6. Sie müssen mechaniknah sein.

Beispiele (bitte anpassen):

Eingangskanäle: <n> → 1 definierter Eingang
WIP: sinkend und begrenzt
Queue Length: stabilisiert
Unplanned Work Anteil: signifikant sinkend
Kontextwechsel / Woche: deutlich sinkend
Flow Efficiency: steigend

Messcadence:

Leading: wöchentlich ab Woche 1
Outcomes: monatlich + PI-Ende (optional)

4) Nonfunctional Requirements (NFRs) / Guardrails

Welche Leitplanken müssen gelten, damit das Epic nicht kippt?

Beispiele (bitte anpassen):

Keine technischen Umbauten (MVP bleibt organisatorisch)
Sponsorship für Schutzmechanismen ist gesichert
Transparenz darf keine versteckte Individual-Performance-Bewertung ermöglichen
<weitere Governance-Regeln: Entscheidungsrechte, Eskalationspfade, Compliance>

5) MVP zur Hypothesenprüfung

Ziel des MVP:
<eine Zeile: was wird geprüft, ohne „groß zu bauen“>

MVP Scope

Zeitlich: <z. B. 10 Wochen>
Inhaltlich (nur was nötig ist, um Mechanismus zu testen):
- <Policy / Regel>
- <WIP-Limit + Durchsetzung>
- <Priorisierungsinstanz>
- <Protect-Mechanismus + „keine Ausnahmen ohne Entscheidung“>
- <Transparenz-Board: Queue/WIP/Blocker/Durchlaufzeiten>

Nicht Teil des MVP (explizit!)

Keine Architektur- oder Systemänderungen
Keine neuen Tools
Keine Skalierung auf weitere ARTs
Keine Optimierung außerhalb des Fokusbereichs

6) Decision Rules: Verifiziert / Falsifiziert

Die Hypothese gilt als verifiziert, wenn:

<Outcome-Signal 1> (z. B. Lead Time messbar sinkt)
<Outcome-Signal 2> (z. B. Flow wird stabiler)
<Mechanismus-Signal> (z. B. Schutzmechanismen werden eingehalten)
<Akzeptanz-Signal> (z. B. Business versteht Trade-offs>)

Die Hypothese gilt als falsifiziert, wenn:

<Mechanismus nicht durchsetzbar>
<Priorisierung wird unterlaufen>
<Outcome bleibt trotz Mechanismus-Shift aus>

Wichtig: Verifiziert oder falsifiziert ist beides ein valides Ergebnis. Es steuert die nächste Wave.

7) Mini-Readout für den Auftraggeber

Status Mechanismus: <grün/gelb/rot + 1 Satz>
Leading Indicators: <Top 3, Trend>
Outcomes: <Proxy-Achsen, Trend, grobe CHF-Story falls vorhanden>
Decision: <Continue / Adjust / Stop>
Learnings: <1–3 Bullet>
Next: <Wave-Entscheid / nächste Hypothese>

Rolloutstrategie

Wenn du das zusammensetzt, entsteht eine Rollout-Logik, die nicht nur ausrollt, sondern lernt. Hier als Beipiel:

Wave 0: ART X als Pilot
Vorher-Fenster. Interventionen. Mechanismen ab Woche 1. Outcomes ab Woche 4–6.
Wave 1: ART Y startet erst, wenn 1–2 Mechanismen stabil sind
Bis dahin ist ART Y deine Vergleichsfläche.
Wave 2: XYZ (Andere ARTS, Solutions, Value Streams) folgen mit derselben Logik

Economic Policy Pack

Economic Policy Pack sind die Regeln, die Impact in Entscheidungen übersetzen. Sobald du Impact messen kannst, passiert etwas Spannendes und etwas Gefährliches.

Das spannende ist, Du kannst endlich über Trade-offs sprechen, mit Zahlen, mit Spannen und mit Hypothesen, die falsifizierbar sind.

Das gefährliche ist, ohne klare Regeln wird jede Zahl zur Verhandlungsmasse. Dann wird jedes Portfolio-Meeting zur Arena. Dann entscheidet nicht der Net-Impact, sondern die Lautstärke, Hierarchie oder die Angst.

Genau deshalb braucht ein Transformation Impact Assessment immer auch ein Economic Policy Pack.

Nicht als „Governance um der Governance willen“. Sondern als Entscheidungs-Rahmen (Guardrails).
Das Economic Policy Pack ist ein kleines Set an Regeln, das immer gilt. Damit man nicht jedes Mal neu diskutieren muss, wie man entscheidet. Somit definiert das Economic Policy Pack:

wie ihr Investitionen begrenzt und steuert
wie ihr Time, Cost, Value und Risk gegeneinander abwägt
wann ihr stoppt, wann ihr startet, wann ihr eskaliert
und wie ihr Unsicherheit behandelt (Spannen statt Fake-Genauigkeit)

Man kann es sich vorstellen wie Leitplanken auf einer kurvigen Passstraße:

Die Leitplanken machen die Fahrt nicht langsamer. Sie machen sie sicherer und manchmal überhaupt erst möglich.

1. Investment Guardrails

Der erste Block beantwortet eine einfache Frage:

„Wie viel dürfen wir in Wirkung investieren, bevor wir neu entscheiden müssen?“

Typische Guardrails:

Cap pro ART / pro PI: z. B. „Max. X% Kapazität für Transformation Experiments“
Cap pro Epic: z. B. „Impact Epics dürfen max. 8–12 Wochen MVP-Laufzeit haben“
WIP-Budgetierung: z. B. „Max. N parallele Impact Epics pro Cluster“

Das verhindert, dass Transformation unendlich „weiterläuft“, ohne dass jemals ein Decision Point kommt. Es schützt auch den operativen Betrieb damit Product Cost und Risk nicht explodieren.

2. Trade-off-Regeln

Trade-off-Regeln sind vorab festgelegte Entscheidungsregeln, die sagen, wie Zielkonflikte aufzulösen sind.

Beispiele für Trade-off-Regeln:

Regel A: Time gegen Cost

„Wir kaufen Geschwindigkeit nur, wenn der Real CoD höher ist als die Mehrkosten.“

Das klingt erst mal logisch und banal, jedoch machen viele Organisationen das Gegenteil. Sie kaufen Geschwindigkeit reflexartig oder sie sparen reflexartig. Beides kann sehr falsch sein.

Mit einer Regel wie dieser wird die Diskussion besser:

CoD-Spanne (Low/Base/High)
Mehrkosten (Dev Expense)
Entscheidung: Fast Lane (Expedite) ja oder nein

Regel B: Product Cost hat Vorrang vor Delivery-Speed in stabilitätskritischen Bereichen

„Wenn Ops-Last, Incidents oder Ticketdruck über Schwelle X liegen, priorisieren wir Stabilisierung.“

Das ist die Übersetzung von „Sustainability“ in eine echte Regel.

Regel C: Risiko-first bei Compliance oder existenziellen Risiken

„Wenn Risk (p×Impact) eine definierte Schwelle überschreitet, hat Risk-Reduction Priorität vor Value.“ Das verhindert z.B. späteres Theater und es macht wahrscheinlich Audit und Management ruhiger.

4. Stop/Start-Regeln

Das sind die Regeln die euch vor Selbstbetrug schützen und meist der Teil, den viele Berater und Manager scheuen. Genau deshalb sind diese Regeln so wertvoll und gleichzeitig politisch schwierig.

Das Policy Pack sollte festlegen: Wann stoppen wir ein Experiment? Nicht, weil es „schlecht aussieht“. Sondern weil es messbar keine Wirkung erzeugt oder weil es den Mechanismus nicht kippt.

Beispiele:

Kill-Kriterium 1: Mechanismus kippt nicht

„Wenn Leading Indicators nach 3–4 Wochen keine klare Bewegung zeigen, stoppen oder redesignen wir.“

Damit verhinderst du das Du Monate auf Outcomes wartest, während der Mechanismus in Wahrheit nie gegriffen hat.

Kill-Kriterium 2: WIP Aging eskaliert

„Wenn Aging über Schwelle X steigt, stoppen wir neue Starts und reduzieren WIP.“

Das schützt Flow und reduziert die „Verstopfung“, das so viele Organisationen lähmt.

Kill-Kriterium 3: Restaufwand / Nutzen kippt negativ

„Wenn Expected Net Impact unter Null fällt (auch im Low/Base Case), stoppen wir.“

Warum noch Geld ausgeben wenn keine Wirkung mehr erzielt wird? Klings banal, wird aber sehr häufig beobachtete: Abteilung X hat noch Budget, also raus damit.

Start-Regel: wann darf die nächste Wave starten?

„Wave 1 startet erst, wenn 1–2 Mechanismen aus Wave x-1 stabil sind.“

Das koppelt die Transformation an Lernen und nicht an den Kalender.

5. Priorisierungsregeln

Damit Portfolio-Entscheide nicht aus dem Bauch passieren brauchen wir klare Regeln.

Wir müssen WSJF (mit real CoD, nicht die Fibonacci Variante) nicht „glauben“. Wir müssen eine eine Regel haben, die wiederholbar ist.

Das Policy Pack kann z. B. festlegen:

Maximize Net Impact: wählt die Items mit größtem ΔI (ΔI = Impact der Transformationsintervention)
Maximize Impact Rate: wählt größtes (ΔI / Duration) (Geld pro Woche)
Risk-first: wenn Compliance/Existenzrisiko, dann zuerst Risk-Reduction
Capacity Split: z. B. 70% Value Delivery, 20% Product Cost, 10% Experiments

Das Entscheidende ist: Wir definieren vorher, welche Logik gilt. Dann sind die Diskussionen kürzer.

6. Confidence & Kommunikation

Ein Economic Framework lebt von Spannen, von erwachsener Unsicherheit und nicht von Pseudo-Genauigkeit die mit hohen Grenzkosten erreicht wird.

Darum gehört in ein Policy Pack auch:

Confidence Levels (z. B. Low/Medium/High)
Regeln, wann Alpha erhöht werden darf

α = Attribution = welche Wirkung wird der Transformation zu welchem Teil zugerechnet

Welche Evidenz zählt: Mechanismus-Shift + Vergleichslogik + stabile Trends

So kann Finance mitarbeiten, ohne dass ihr Wissenschaft simuliert.

Warum alles das für Transformation Impact Assessment entscheidend ist

Weil Impact-Messung ohne Policy Pack nur zu noch mehr Diskussion führt. Das Policy Pack ist der Schritt von „Messen“ zu „Führen“ und damit das Steuerungswerk für die Transformation mit echter Wirkung und nicht nur Change Theater

Mit Policy Pack erreichen wir :

Impact wird vergleichbar
Entscheidungen werden schneller
Experimente werden mutiger, weil Stop-Regeln Sicherheit geben
und das Portfolio wird steuerbar, statt nur dokumentiert