Schnelle Entscheidungsprozesse: Transformation beschleunigen mit Tiered Decision-Making

Das Problem, das die meisten Führungskräfte kennen — aber selten benennen

Entscheidungen, die Monate dauern, während der Markt sich in Wochen verändert – das ist das stille Killer-Problem in etablierten Unternehmen. Rahul Chillar, EVP Software bei Siemens, benennt es klar: Langsame Entscheidungsprozesse sind längst kein interner Verwaltungsthema mehr, sondern direkter Wettbewerbsnachteil. Unternehmen, die jetzt nicht handeln, verlieren strukturell.

„Bitte macht eine Entscheidung in drei Wochen. Schleppt sie nicht sechs Monate lang.”

Diese Forderung stammt nicht von einem Startup-Gründer. Sie stammt von Rahul Chillar, Executive Vice President Software bei Siemens Smart Infrastructure Buildings — einem der größten Gebäudetechnologieunternehmen weltweit, das seit 25 Jahren in der Gebäudeindustrie operiert.

Chillars Kernthese ist direkt: Langsame Entscheidungsprozesse sind kein Governance-Problem, sondern ein Wettbewerbsnachteil. Unternehmen, die digitale Transformation heute hinauszögern, werden in fünf Jahren strukturell unrentabler sein als ihre Mitbewerber — nicht wegen schlechterer Produkte, sondern wegen verlorener Entscheidungsgeschwindigkeit. Wer schnellere Entscheidungsprozesse in der Transformation implementiert, schafft einen dauerhaften operativen Vorsprung, der sich in Projektdurchsatz, Innovationsrate und Marktposition niederschlägt.

In diesem Gespräch teilt Chillar fünf operative Frameworks, die er bei Siemens eingeführt hat, um genau diese Transformation zu beschleunigen — von Tiered Decision-Making über Fail-Fast-Kulturen bis zur staffelweisen Roadmap-Planung mit flexibler Kapazität.

Die wichtigsten Erkenntnisse

• 100K-Entscheidungen gehören in eine Woche — nicht in sechs Monate. 500K-Entscheidungen in drei Wochen mit fünf Beteiligten. Jede weitere Verzögerung ist organisatorische Lähmung, keine Sorgfalt.
• Fail-Fast bedeutet iterativ scheitern, nicht blind riskieren: Wireframe für 10K, Kundenfeedback, Prototyp für 30K — nie das volle Budget auf einmal verbrennen.
• Roadmap-Flexibilität ist kein Zeichen von Planlosigkeit: Q1 zu 100% festgelegt, Q2 nur zu 50–60%, Q3+ nur zu 20% — 80% Kapazität bleibt für valide Kundenanforderungen offen.
• Gamifikation macht Transformation annehmbar: Portfolio-Benchmarking, bei dem Facility Manager ihre Performance gegeneinander sehen, erzeugt intrinsischen Wettbewerb ohne externe Bestrafung.
• Guardrails ersetzen Zentralisierung: Teams wissen ihr Segment, ihr Kundenprofil und ihr Budget — innerhalb dieser Grenzen experimentieren sie ohne Freigabepflicht.
• 75% aller Gebäude weltweit verbrauchen 30–40% mehr Energie als nötig — das zeigt, wie groß der Handlungsbedarf bei Portfolio-Managern mit mehreren Standorten ist.
• Strategische Agilität beginnt mit Sichtbarkeit: Wer nicht misst, kann nicht benchmarken — und wer nicht benchmarkt, hat keinen Startpunkt für Transformation.

Im Detail: Wie Siemens schnelle Entscheidungsprozesse in der Transformation skaliert

Während die meisten Unternehmen Transformation als Technologie- oder Kulturaufgabe behandeln, identifiziert Siemens die echte Hürde: Entscheidungsgeschwindigkeit. Wer Investitionsentscheidungen um Monate verzögert, verliert strukturelle Marktanteile. Diese Verzögerung führt nicht zu höheren Kosten, sondern zu systematischen Wettbewerbsnachteilen, die sich über Jahre verfestigen.

Das eigentliche Problem: Entscheidungsgeschwindigkeit ist ein Wettbewerbsfaktor

Die meisten Diskussionen über digitale Transformation konzentrieren sich auf Technologie oder Kulturwandel. Chillar verlagert den Fokus: Die kritische Variable ist Entscheidungsgeschwindigkeit.

Er belegt das mit einem konkreten Kostenvergleich. Wenn ein Mitbewerber heute 100K in digitale Transformation investiert und dein Unternehmen dieselbe Entscheidung sechs Monate verzögert, läuft die Differenz nach fünf Jahren in strukturell niedrigere Margen. Nicht wegen höherer Kosten — sondern weil der Mitbewerber früher lernt, früher skaliert und früher Kundenfeedback integriert.

„Quick decision-making and risk-taking appetite: if it’s a 100K loss or 100K investment, make a decision quick — make it in one week and run with it. If it’s 500K, bring in five more people, make a decision in 3 weeks, but please make a decision in 3 weeks. Don’t drag it for 6 months.” — Rahul Chillar, EVP Software, Siemens Smart Infrastructure Buildings

Das Tiered Decision-Making Framework, das Chillar bei Siemens implementiert hat, strukturiert Entscheidungsbefugnisse nach Investitionsgröße:

• Bis 100K: Teamentscheidung, Zeitrahmen eine Woche, keine Eskalation
• 100K–500K: Fünf-Personen-Komitee, Entscheidung in drei Wochen
• Ab 250K: EVP-Sichtbarkeit, aber nicht automatisch EVP-Entscheidung — das Vertrauen liegt beim Team
• Unter Budgetschwellen: Volle Team-Autonomie, keine zentrale Freigabe

Der entscheidende Mechanismus: Die Schwelle für EVP-Sichtbarkeit liegt bei 250K — aber Sichtbarkeit bedeutet nicht Entscheidungshoheit. Chillar weiß, was in seinem Portfolio passiert, greift aber nur ein, wenn KPIs signalisieren, dass Korrekturbedarf besteht.

Fail-Fast-Kultur: Scheitern mit 10K statt 100K

Viele Organisationen sprechen von Fail-Fast — meinen aber entweder grenzenloses Experimentieren ohne Kontrolle oder Risikovermeidung unter dem Deckmantel von Agilität. Chillars Ansatz ist präziser.

Das Go-Kart-Modell für iterative Produktentwicklung zerteilt ein 100K-Budget in drei Phasen:

1. Phase 1 (10K): Wireframe bauen, zu vier bis fünf Kunden tragen, Frage stellen: „Würdest du das fahren?” Noch kein Produkt — nur eine Hypothese in visueller Form.
2. Phase 2 (30K): Nach Kundenkonfidenz den Wireframe in einen Bare-Bones-Prototypen überführen. Erneutes Kundenfeedback mit funktionierender Engine.
3. Phase 3 (Restbudget): Vollentwicklung nur nach validierter Nachfrage von mehreren Kunden.

„After you build the first wireframe — consuming only 10K out of the 100K — go take it to a customer. If they say yes, go ask another customer. After you’ve got confidence from four, five customers, invest the next 30K and transfer your wireframe into a Bare Bones prototype. You don’t fail with the full 100K down the drain; you fail with a smaller amount and then learn and pivot.” — Rahul Chillar

Der Vorteil ist mathematisch: Scheitern mit 10K kostet neunzig Prozent weniger als Scheitern mit 100K. Die iterative Kundenfeedback-Integration in der Produktentwicklung eliminiert den häufigsten Grund für Fehlinvestitionen — Annahmen über Kundenbedarf, die nie validiert wurden.

Gleichzeitig gilt eine Zeitregel: Experimente müssen in zwei Monaten scheitern oder Fortschritt zeigen. Nicht in zwei Jahren, nicht in zwölf Quartalen. Die Fail-Fast-Kultur funktioniert nur, wenn der Fehlschlag-Zyklus kurz genug ist, um aus ihm zu lernen und das nächste Experiment zu starten.

Guardrails statt Zentralisierung: Autonomie mit klaren Grenzen

Ein häufiger Einwand gegen dezentralisierte Entscheidungsfindung lautet: „Wie behältst du strategische Konsistenz, wenn Teams eigenständig handeln?” Chillars Antwort sind klare Guardrails — nicht als Kontrollmechanismus, sondern als Spielfeld-Definition.

Teams bei Siemens kennen:

• Ihr Zielsegment und ihr Kundenprofil
• Ihr Gesamtbudget (z. B. fünf Millionen, drei Millionen, 15 Millionen)
• Die KPIs, nach denen ihre Ergebnisse gemessen werden

Innerhalb dieser Grenzen haben sie volle Autonomie, um Produkte zu entwickeln, Kundenvalidierung zu betreiben und Ressourcen zu allozieren. Was sie nicht tun: zentrale Freigaben für jede Iteration einholen.

„We’ve established some guard rails: we’re going to go after this segment with this type of business and customer profile. Teams know they can innovate, but it needs to be within the guard rail. I’ve given budget down to the organization — you have five million, you have three, you have 15, you have 20 — and within that they experiment and we measure on KPIs and returns.” — Rahul Chillar

Die Kombination aus PMO-Steuerung und dezentralisierter Entscheidungsfindung löst einen der häufigsten Koordinationskonflikte in großen Portfolios: entweder zu viel Kontrolle (Bottleneck oben) oder zu wenig Kontrolle (strategischer Drift unten). Guardrails schaffen die dritte Option — definiertes Spielfeld, freies Spiel.

Staffelweise Roadmap-Planung: Der Lunar Landing Approach

Strategische Agilität und operative Planbarkeit werden oft als Gegensätze behandelt. Chillar zeigt, dass sie kompatibel sind — wenn Roadmaps nach Zeithorizont differenziert werden.

Das Lunar Landing Framework (Staffelweise Roadmap-Planung mit abnehmender Fixierung) funktioniert so:

Der Effekt: Kundenanforderungen, die valide, wiederholbar und skalierbar sind, können in Q2 und Q3 integriert werden, ohne die unmittelbare Lieferfähigkeit zu gefährden. Teams können auf Marktveränderungen reagieren, ohne die strategische Kontinuität zu verlieren.

„I lock my road maps for one quarter in stone, but four months out for the second quarter, only 50–60% is locked in stone. That means 40% is flexible. If a customer demand comes in and is valid, repeatable, and scalable, we have capacity to address it.” — Rahul Chillar

Die Metapher, die Chillar für diesen Ansatz verwendet, ist präzise: „Ich möchte zum Mond. Der Mond ist direkt da drüben. Lass uns ins Raumschiff steigen. Es wird mich fünf Tage dauern, und ich werde unterwegs steuern. Ich muss nicht die gesamte Flugbahn an Tag 1 kartieren.” Wer zwei Jahre damit verbringt, den perfekten Plan zu erstellen, verliert die Zeit, die der Mitbewerber bereits für Lernzyklen genutzt hat. Strategische Agilität und operative Planung schließen sich nicht aus — sie brauchen unterschiedliche Planungshorizonte.

Portfolio-Benchmarking mit Gamifikation: Sichtbarkeit erzeugt Verhalten

Transformation scheitert häufig nicht an fehlender Strategie, sondern an fehlender Verhaltensänderung auf Ebene der Ausführenden. Chillar adressiert dieses Problem mit einem kombinierten Ansatz aus innerem Benchmarking und Gamifikation.

Das Prinzip: Alle Gebäude eines Portfolios erscheinen auf einer gemeinsamen Scorecard mit Metriken wie Energieverbrauch, Betriebskosten, Nachhaltigkeit, Sicherheit und Luftqualität. Jeder Facility Manager sieht seine eigene Performance und die seiner Peers — transparent und vergleichbar.

„Step one is simply reporting: how are you performing? Then you benchmark building one against building two against building three. Building one is managed by facility manager Jose, building two by Mike, building three by Rahul — and it looks like Mike is not performing very well. Her building energy consumption is too high. They’re benchmarking internally and gamifying across their portfolio.” — Rahul Chillar

Der psychologische Mechanismus ist bekannt aus Spieltheorie: Menschen spielen seit der Kindheit Spiele und reagieren auf Scoreboards. Der Wettbewerb entsteht intrinsisch — kein Manager möchte der schlechteste auf dem Board sein. Das treibt Verhaltensänderung ohne externe Strafen oder bürokratische Kontrollmechanismen.

Für Portfolio-