# P-DRIVEN: Arbeitsbuch **Ein Vorgehensmodell zum Umgang mit Unsicherheit in Notfällen und Krisen** | | | |---|---| | **Autor** | Rico Kerstan | | **Version** | 1.0 | | **Datum** | 05.05.2025 | | **Lizenz** | CC BY-NC-ND 4.0 | | **Website** | [p-driven.org](https://p-driven.org) | **Zitiervorschlag:** Kerstan, R. (2025). *P-DRIVEN: Arbeitsbuch. Ein Vorgehensmodell zum Umgang mit Unsicherheit in Notfällen und Krisen.* Version 1.0. Verfügbar unter: https://p-driven.org --- ## Zweck und Geltungsbereich dieses Arbeitsbuchs Dieses Arbeitsbuch dient als kodifizierte Wissensbasis von P-DRIVEN. Sein Zweck ist es, die korrekte und disziplinierte Anwendung von P-DRIVEN als Vorgehensmodell zum Umgang mit Unsicherheit in Notfällen, Krisen und dynamischen Lagen zu ermöglichen. Es erläutert die zugrunde liegende Logik des Problemlösungs-P, das zugehörige Führungs- und Teammodell sowie die Nutzung unterstützender Werkzeuge. Das Arbeitsbuch richtet sich an alle potenziellen Anwender von P-DRIVEN. Es kann sowohl von Personen genutzt werden, die für eine einzelne Domäne verantwortlich sind, als auch von Personen, die das Notfall- und Krisenmanagement innerhalb einer Organisation gestalten, organisieren oder überwachen. Vorerfahrung mit P-DRIVEN ist nicht erforderlich. Dieses Dokument ist die maßgebliche Referenz für die korrekte Anwendung von P-DRIVEN außerhalb einer akuten Lage. Es ersetzt keine Schulung, Zertifizierung oder Lizenzierung, kann aber für all dies als grundlegende Basis dienen. Das Arbeitsbuch ist ausdrücklich nicht für den Einsatz während eines aktiven Notfalls oder einer aktiven Krise konzipiert. Sein Zweck liegt in Lernen, Vorbereitung, Reflexion und organisatorischem Transfer. ## Verwendung dieses Arbeitsbuchs Seine Struktur folgt der Logik des P-DRIVEN-Vorgehensmodells. Im Zentrum steht das Problemlösungs-P. Das Arbeitsbuch organisiert die Inhalte deshalb in drei Ebenen: Erstens schafft es die Grundlage für die korrekte Anwendung außerhalb einer laufenden Lage: Zweck, Geltungsbereich und die Beziehung zu *P-DRIVEN: Leitfaden für die Lage*. Zweitens erläutert es das Problemlösungs-P selbst. Die Schritte des Problemlösungs-P werden in der genauen Abfolge dargestellt, die durch *P-DRIVEN: Leitfaden für die Lage* definiert ist. Für jeden Schritt erläutert das Arbeitsbuch Zweck, erwartete Ergebnisse und typische Verwässerungsmuster, die zu Wirksamkeitsverlust führen. Diese Erläuterungen unterstützen die korrekte Anwendung; sie führen keine Alternativen oder zulässigen Varianten ein. Drittens zeigt es, wie dasselbe Problemlösungs-P auf unterschiedliche Problemgrößen skaliert. Das Arbeitsbuch unterscheidet zwischen Notfällen und Krisen nicht als verschiedene Methoden, sondern als unterschiedliche operative Maßstäbe, die eine andere Tiefe, ein anderes Tempo und andere Koordination erfordern, während dieselbe Schrittfolge und Logik erhalten bleiben. Unterstützende Werkzeuge und Dokumentationspraxis werden als inhärente Ermöglicher disziplinierter Ausführung behandelt, nicht als optionale Zusätze. Leser können dieses Arbeitsbuch auf verschiedene Weise nutzen: * sequenziell, um ein vollständiges Verständnis von P-DRIVEN aufzubauen, * selektiv, um einen bestimmten Schritt, eine bestimmte Rolle oder ein bestimmtes Werkzeug zu klären, * oder als Referenz für Trainings, Übungen, Nachbereitung und organisatorischen Transfer. ### Leseempfehlung nach Rolle Nicht jeder Leser muss das gesamte Arbeitsbuch lesen. Die folgende Orientierung gibt einen empfohlenen Leseweg anhand der Rolle, die die jeweilige Person einnehmen wird: | Rolle | Empfohlene Lektüre | Fokus | |------|-------------------|-------| | **Facilitator** | Gesamtes Arbeitsbuch | Vollständiges Verständnis jedes Schritts, jeder Veto-Situation und jeder Tafel. Der Facilitator muss die Methode besser beherrschen als jede andere Person im Team. | | **Owner** | Teil I, II, III | Rollenprofil, vollständiges Problemlösungs-P und die Skalierungslogik. Teil V wird empfohlen, um Prozessabweichungen zu erkennen. | | **Domain Owner** | Teil I, II, III | Wie beim Owner, mit besonderem Augenmerk auf das Prinzip der Personenidentität und die CMT-/DRT-Schnittstelle. | | **Supporter** | Teil I, II | Rollenprofil, Problemlösungs-P, Tafellogik, Berichtsstruktur und Umfang der Befugnisse. Für wirksames Arbeiten im Zyklus ist ein Verständnis des Gesamtablaufs erforderlich. | | **System­verantwortlicher** | Gesamtes Arbeitsbuch | Muss die vollständige Methode verstehen, um Dokumentation zu pflegen, Übungen zu planen und kontinuierliche Verbesserung voranzutreiben. Die Roadmap zur Einführung in Teil VI, Kapitel 2, ist die primäre Referenz. | | **Geschäfts­führung / Vorstand** | Teil I, Teil VI | Überblick über das Vorgehensmodell, Voraussetzungen, Grenzen und die Schnittstelle zwischen Leitung und Krisenstruktur. | Dieses Arbeitsbuch ist nicht für den operativen Einsatz in Echtzeit vorgesehen. In aktiven Notfällen und Krisen gilt *P-DRIVEN: Leitfaden für die Lage*. Leser, die nicht unmittelbar eine Aktivierungsrolle ausfüllen – etwa Personen, die P-DRIVEN in einer Organisation einführen, Trainingsprogramme entwickeln oder die Methode bewerten –, finden häufig die folgenden Lesewege hilfreicher: ### Leseempfehlung nach Lesertyp | Lesertyp | Empfohlene Lektüre | Fokus | |---|---|---| | **System­einführer** (führt P-DRIVEN in die eigene Organisation ein) | Zuerst Teil VI, dann Teil I und II | Die Roadmap zur Einführung in Teil VI, Kapitel 2, ist die primäre Referenz. Teil I und II beschreiben die Methode, auf die hingearbeitet wird. | | **Trainings- / L&D-Planer** | Teil I, IV, VI | Rollenprofile und Qualifikationsanforderungen, Übungs- und Trainingshinweise sowie Voraussetzungen. | | **Akademischer / methodischer Evaluator** | Teil I, II, V, VI | Methodenarchitektur und Gestaltungsprinzipien, Schrittlogik, Einordnung und Grenzen. Glossar und Zitierkopf sind die wichtigsten Anker. | ## Verhältnis der Dokumente P-DRIVEN wird durch zwei unterschiedliche, aber logisch aufeinander abgestimmte Artefakte dargestellt: *P-DRIVEN: Leitfaden für die Lage* und dieses Arbeitsbuch. *P-DRIVEN: Leitfaden für die Lage* ist ein separates, eigenständiges Dokument, das ausschließlich für die Anwendung während aktiver Notfälle und Krisen vorgesehen ist. Er ist bewusst knapp, strikt sequenziell und frei von Erläuterungen oder Theorie. Sein Zweck ist die Unterstützung disziplinierter Ausführung unter Zeitdruck. *P-DRIVEN: Leitfaden für die Lage* ist maßgeblich. Er definiert die maßgebliche Abfolge und Logik des Problemlösungs-P. Er enthält außerdem die praktischen Artefakte, die während einer Aktivierung benötigt werden: Tafelvorlagen für Tafel 1, 2 und 3, eine Vortragsstruktur für den Lagevortrag, eine Schnellreferenz für den Facilitator mit Aktivitäten und Veto-Auslösern je Schritt, Formulare zur Auftragsübermittlung und Dokumentationschecklisten. Diese Vorlagen und Checklisten werden in diesem Arbeitsbuch nicht reproduziert – sie gehören in den operativen, nicht in den erläuternden Kontext. Dieses Arbeitsbuch verändert, erweitert oder uminterpretiert diese Logik nicht. Es dient ihrer Erläuterung. Wo das Arbeitsbuch ein Werkzeug, eine Tafel oder ein Verfahren beschreibt, stellt *P-DRIVEN: Leitfaden für die Lage* die entsprechende einsatzbereite Vorlage bereit. Erläuterungen, Kontext und Reflexionen sind bewusst aus *P-DRIVEN: Leitfaden für die Lage* entfernt, um Klarheit und Nutzbarkeit in operativen Umgebungen zu wahren. Wenn Unterschiede in Wortlaut oder Schwerpunktsetzung zwischen *P-DRIVEN: Leitfaden für die Lage* und diesem Arbeitsbuch auftreten, hat die Logik von *P-DRIVEN: Leitfaden für die Lage* Vorrang. *P-DRIVEN: Leitfaden für die Lage* ist verfügbar unter [p-driven.org](https://p-driven.org). ## P-DRIVEN auf einen Blick P-DRIVEN strukturiert Problemlösung über vier Phasen, sechzehn Schritte, vier Aktivierungsrollen, drei Tafeln und bis zu drei Teamebenen. **Vier Phasen:** - **Initiierungsphase** – aktiviert die Struktur (Alarmierung, Erstbewertung) - **Planungsphase** – schafft gemeinsames Verständnis und definiert Ziele (6 Schritte) - **Umsetzungsphase** – setzt um und überwacht (6 Schritte) - **Lernphase** – sichert Ergebnisse und bereitet den nächsten Zyklus vor (Debriefing, Strukturiertes Feedback) **Vier Aktivierungsrollen:** Owner · Facilitator · Domain Owner · Supporter **Drei Tafeln:** - Tafel 1: Probleme und Prioritäten - Tafel 2: Lösungsstrategien - Tafel 3: Ziele und Umsetzung **Drei Teamebenen:** - IMT (Incident Management Team; offizieller deutscher Begriff: Notfallteam) – operative Ebene - DRT (Domain Response Team; offizieller deutscher Begriff: Notfallteam) – Domänenebene unter einem CMT - CMT (Crisis Management Team; offizieller deutscher Begriff: Krisenteam) – strategische Ebene **Fünf Strukturprinzipien:** 1. Die Abfolge ist nicht verhandelbar. 2. Jedes Team hat eine doppelte Führung: Owner und Facilitator. 3. Der Facilitator verfügt über ausdrückliche Veto-Rechte zum Schutz der Prozessintegrität. 4. Domain Owner im CMT sind identisch mit den Incident Ownern ihrer DRTs (Prinzip der Personenidentität). 5. Abweichungen von der definierten Methode sind bewusste Abweichungen und keine Varianten. # Teil I – Einführung: Anwendung von P-DRIVEN außerhalb der Lage ## P-DRIVEN als Vorgehensmodell zum Umgang mit Unsicherheit P-DRIVEN ist ein Vorgehensmodell zum Umgang mit Unsicherheit in komplexen Problemlagen wie Notfällen, Krisen und dynamischen operativen Umfeldern. Es bietet einen disziplinierten Ansatz zur Problemlösung unter Bedingungen unvollständiger Information, Zeitdruck und erheblicher Konsequenzen. P-DRIVEN stützt sich nicht auf vordefinierte Szenarien oder Best Practices. Stattdessen schafft es eine stabile Problemlösungslogik, die in unterschiedlichen Kontexten, Organisationen und Komplexitätsgraden angewendet werden kann. Im Kern verbindet P-DRIVEN drei untrennbare Elemente: * das Problemlösungs-P, * ein dazu passendes skalierbares Führungs- und Teammodell, * sowie einen Satz inhärenter Werkzeuge, die disziplinierte Ausführung unterstützen. Diese Elemente sind darauf ausgelegt, gemeinsam zu funktionieren. Das Entfernen, Umstellen oder selektive Anwenden einzelner Elemente schwächt das Vorgehensmodell als Ganzes. P-DRIVEN ist auf operative Nutzbarkeit ausgelegt. Es kann mit minimaler Vorbereitung und ohne umfangreiche organisatorische Voraussetzungen angewendet werden. Gleichzeitig bleibt es robust genug, um von lokal begrenzten Problemlagen bis zu organisationsweiten Krisen zu skalieren, ohne seine innere Logik zu verändern. ## Was P-DRIVEN ist – und was es nicht ist P-DRIVEN ist ein klar definiertes Vorgehensmodell. Sein Geltungsbereich und seine Zielsetzung sind bewusst begrenzt. P-DRIVEN ist: * ein disziplinierter Ansatz zur Problemlösung unter Unsicherheit, * ein Vorgehensmodell für Notfälle und Krisen, * eine Methode, die Prozess, Rollen und Werkzeuge zu einem kohärenten Ganzen verbindet. P-DRIVEN ist nicht: * ein Rahmenwerk, das beliebig angepasst oder erweitert werden kann, * ein Managementsystem, * eine Sammlung von Best Practices, * ein Werkzeugkasten, aus dem Elemente selektiv kombiniert werden können. Es gibt nur ein P-DRIVEN. ## Notfälle und Krisen: Anwendungsbereich P-DRIVEN gilt sowohl für Notfälle als auch für Krisen. Diese Begriffe beschreiben Unterschiede im Maßstab und in den organisatorischen Auswirkungen, nicht unterschiedliche Methoden. Eine Krise ist ein Bündel von Problemen, das die Fähigkeit einer Organisation gefährdet, ihre strategischen Ziele zu erreichen, weil die Widerstandsfähigkeit ihrer Gesamtprozesse und Ressourcen überschritten wird. Krisen betreffen die Organisation als Ganzes und erfordern zentrale Koordination und Entscheidungsfindung. Ein Notfall ist ein Bündel von Problemen, das die Fähigkeit eines definierten Teils einer Organisation – etwa einer einzelnen Domäne, Funktion oder eines Standorts – gefährdet, seine operativen Ziele zu erreichen, weil die Widerstandsfähigkeit seiner Prozesse und Ressourcen überschritten wird. Anders als eine Krise bedroht ein Notfall nicht die strategischen Ziele der Organisation insgesamt, überschreitet aber bereits die routinemäßige operative Bewältigung im betroffenen Bereich. Aus Sicht von P-DRIVEN bilden mehrere gleichzeitige Notfälle eine Krise. Parallele, unabhängig gesteuerte Problemlösungsstrukturen sind mit diszipliniertem Krisenmanagement nicht vereinbar. Zentrale Koordination wird zwingend, sobald die Gesamtwiderstandsfähigkeit der Organisation gefährdet ist. ## Disziplin, Abfolge und Nichtverhandelbarkeit von P-DRIVEN P-DRIVEN beruht auf der disziplinierten Ausführung des definierten Problemlösungs-P. Seine Wirksamkeit hängt nicht von individueller Brillanz, Erfahrung oder Seniorität ab, sondern von der Einhaltung einer gemeinsamen Logik unter Bedingungen von Unsicherheit. Die Abfolge des Problemlösungs-P ist nicht verhandelbar. Jeder Schritt baut auf den Ergebnissen des vorherigen auf. Schritte auszulassen, umzustrukturieren oder zusammenzulegen verändert die Logik des Prozesses und bricht seine innere Konsistenz. Solche Abweichungen sind keine neutralen Abkürzungen. Sie verringern systematisch die Qualität von Entscheidungen und die Fähigkeit der Organisation, sich an eine verändernde Lage anzupassen. Methodische Disziplin in P-DRIVEN spielt eine ähnliche Rolle wie formale Regeln in der Buchführung. Buchführung wird nicht durch Erfahrung oder Intuition richtiger. Sie wird durch Einhaltung einer definierten Struktur richtig. Erfahrung kann Tempo oder Sicherheit verbessern, ersetzt aber nicht die zugrunde liegende Logik. Dasselbe gilt für disziplinierte Problemlösung unter Unsicherheit. P-DRIVEN begrenzt individuelle Handlungsfreiheit bewusst zugunsten kollektiver Verlässlichkeit. Diese Begrenzung ist keine Einschränkung, sondern ein Stabilisierungsmechanismus. In unsicheren und dynamischen Lagen ist Prozesskonsistenz wertvoller als Flexibilität in der Auslegung. Die Nichtverhandelbarkeit des Problemlösungs-P schließt Urteilskraft und Verantwortung nicht aus. Sie schafft einen stabilen Rahmen, innerhalb dessen Urteilskraft ausgeübt werden kann, ohne Koordination, Priorisierung oder Lagebewusstsein zu untergraben. Disziplin sorgt dafür, dass Entscheidungen vergleichbar, erklärbar und mit neuen Informationen revidierbar bleiben. Abweichungen von der definierten Abfolge erzeugen bewusste Abweichungen vom Vorgehensmodell. Solche Abweichungen können in bestimmten Kontexten funktionieren, ihre Wirksamkeit darf jedoch nicht vorausgesetzt werden. Innerhalb von P-DRIVEN gewährleistet nur die disziplinierte Einhaltung des definierten Prozesses vorhersehbare Leistungsfähigkeit über unterschiedliche Lagen, Teams und organisatorische Umgebungen hinweg. ## Rollen, Führungsstruktur und domänenbasierte Teamzusammensetzung ### Zweck des Teammodells Das P-DRIVEN-Teammodell ist darauf ausgelegt, disziplinierte Problemlösung unter Unsicherheit sicherzustellen und zugleich über unterschiedliche Wirkungsebenen und organisatorische Reichweiten hinweg skalierbar zu bleiben. Das Modell trennt die Verantwortung für *Inhalte und Entscheidungen* von der Verantwortung für *Prozess und Methode*. Diese Trennung ist bewusst gewählt. Sie verhindert, dass individuelle Erfahrung oder Hierarchie strukturierte Problemlösung dominieren, und stellt sicher, dass Koordination, Priorisierung und Anpassung auch bei wachsender Komplexität möglich bleiben. Teamstrukturen in P-DRIVEN werden nicht über Größe oder Hierarchie definiert, sondern über Geltungsbereich, Kopplung und Wirkung. Dieselbe Organisationsform wird über alle Ebenen hinweg wiederholt und konsistent verwendet. ### Kernteam: Owner und Facilitator Jedes P-DRIVEN-Team ist um ein Kernteam aus zwei Rollen aufgebaut: Owner und Facilitator. Der Owner trägt die fachliche Verantwortung für den Problembereich, den das Team bearbeitet. Je nach Maßstab wird diese Rolle durch einen Incident Owner oder einen Crisis Owner wahrgenommen. Der Owner entscheidet an definierten Entscheidungspunkten, vertritt das Team gegenüber der Linienorganisation und trägt Verantwortung für die erzielten Ergebnisse. Die Rolle ist mit einem Projektleiter oder Product Owner vergleichbar: Die Entscheidungsbefugnis ist ausdrücklich gegeben, die Problemlösung selbst bleibt jedoch eine kollektive Leistung. Der Facilitator ist für die Methode verantwortlich. Diese Rolle schützt die Abfolge, Disziplin und Integrität des Problemlösungs-P, seiner Strukturen und der sachgerechten Nutzung der Werkzeuge. Der Facilitator stellt sicher, dass keine Schritte ausgelassen oder vertauscht werden und dass Werkzeuge wie vorgesehen eingesetzt werden. Der Facilitator hat keine Befugnis, den Prozess zu verändern, und keine Pflicht, inhaltlich beizutragen. Er kann generalistische Beobachtungen anbieten oder Annahmen im Sinne eines *advocatus diaboli* hinterfragen, darf jedoch niemals die Rolle eines Domänenexperten übernehmen. Sobald der Facilitator domänenspezifische Inhalte beiträgt, endet die Prozessdurchsetzung, und die strukturelle Trennung, die das Veto-Recht legitimiert, wird kompromittiert. Die Beziehung zwischen Owner und Facilitator folgt einer Checks-and-Balances-Logik. Der Owner besitzt die Entscheidungsbefugnis innerhalb des Prozesses. Der Facilitator hält ausdrückliche Veto-Rechte, wenn die Prozessintegrität gefährdet ist. Keine der beiden Rollen kann die andere ersetzen. Diese doppelte Führungsstruktur besteht in jedem P-DRIVEN-Team, unabhängig vom Maßstab. ### Skalierungslogik P-DRIVEN nutzt eine einzige Organisationsform, die durch Replikation und nicht durch Neugestaltung skaliert. Auf strategischer Ebene wird ein CMT eingerichtet, wenn Probleme Domänengrenzen überschreiten oder wenn strukturelle Eskalationsregeln greifen. Das CMT wird von einem Crisis Owner geführt und durch einen dedizierten Crisis Facilitator unterstützt. Domain Owner bilden die permanente Unterstützungsstruktur des CMT und vertreten jeweils eine definierte organisatorische Domäne. Der Crisis Owner ist kein Domain Owner; er besitzt die Krise. Auf operativer Ebene werden Notfälle oder Krisen durch Incident Management Teams (IMT) bearbeitet. Ein IMT bearbeitet einen definierten Bereich wie Funktion, Domäne, Standort oder Region. Das IMT wird von einem Incident Owner geführt und durch einen dedizierten Incident Facilitator unterstützt. Treten Notfälle innerhalb einer definierten Domäne unter einem bestehenden CMT auf, wird das entsprechende Team als Domain Response Team (DRT) bezeichnet. Ein DRT ist keine andere Organisationsform. Es ist ein IMT, das innerhalb von Domänengrenzen unter strategischer Koordination arbeitet. Der Domain Owner im CMT übernimmt für das DRT die Rolle des Incident Owner. Andere Bezeichnungen wie Site Response Team oder Regional Response Team folgen derselben Logik: Der Name spiegelt den Geltungsbereich wider, nicht die Struktur. Skalierung folgt klaren Strukturregeln. Mehrere aktive IMT innerhalb einer einzelnen Domäne erfordern die Bildung eines DRT. Mehrere aktive IMT über verschiedene Domänen hinweg erfordern die Bildung eines CMT. Grundsätzlich werden parallele Problemlösungsstrukturen mit überlappendem Geltungsbereich vermieden. Eine Ausnahme gilt, wenn mehrere IMT parallel ohne inhaltliche, zeitliche oder ressourcenbezogene Kopplung und ohne Auswirkung auf strategische Ziele arbeiten. In solchen Fällen ist die Bildung eines CMT nicht zwingend, bleibt aber eine bewusste Managemententscheidung und keine bloße Unterlassung. Über alle Ebenen hinweg wird Priorisierung nicht hierarchisch verordnet. Ziele werden auf der jeweils passenden Ebene gesetzt und in die entsprechenden Teams eingebracht, wo die Priorisierung innerhalb des Problemlösungs-P selbst erfolgt. ### Rollen und Verantwortlichkeiten P-DRIVEN definiert vier Aktivierungsrollen: Owner, Facilitator, Domain Owner und Supporter. Jede Rolle hat definierte Verantwortlichkeiten, Befugnisse, Kompetenzanforderungen und Ziele. Die folgenden Rollenprofile gelten über alle Teamebenen hinweg – von einem einzelnen IMT über DRT und CMT bis zu Local Response Teams (LRT) und Operational Response Teams (ORT) in skalierten Konfigurationen. Wo sich Verantwortlichkeiten oder Befugnisse zwischen Ebenen unterscheiden, wird dies ausdrücklich benannt. ### Rollenprofil: Owner Der Owner trägt die fachliche Verantwortung für den vom Team bearbeiteten Problembereich. Auf DRT-Ebene ist dies der Incident Owner, auf CMT-Ebene der Crisis Owner. Die strukturelle Rolle ist identisch, der Geltungsbereich unterscheidet sich. Der Owner ist die letzte Entscheidungsinstanz innerhalb des Teams. Entscheidungen werden an definierten Punkten im Problemlösungs-P getroffen, nicht ad hoc. Der Owner führt über Ziele, Koordination und klare Verantwortungszuweisung. Er steuert die Ausführung nicht unmittelbar und führt keine operativen Aufgaben selbst aus. Der Owner vertritt das Team gegenüber der Linienorganisation, gegenüber Geschäftsführung oder Vorstand auf CMT-Ebene und gegenüber benachbarten oder übergeordneten Strukturen. Wenn eine Eskalation von einem Notfall zu einer Krise erfolgt, stellt der Owner sicher, dass die Facilitator-Rolle im Ursprungsteam umgehend neu besetzt wird. **Verantwortlichkeiten:** - Fachliche Führung des Teams - Entscheidungen an definierten Punkten im Problemlösungs-P (Lagebewertung, Entscheidungsfindung, Zieldefinition, Deaktivierung) - Vertretung des Teams gegenüber der Linienorganisation und auf CMT-Ebene gegenüber Geschäftsführung oder Vorstand - Zuweisung und Koordination von Supportern auf DRT-/LRT-/ORT-Ebene oder Domain Ownern auf CMT-Ebene - Verantwortung für Fortschritt und Ergebnisse innerhalb des Geltungsbereichs des Teams - Erklärung des Aktivierungsstatus und seiner Beendigung, vorbehaltlich des Veto-Rechts des Facilitators - Auf CMT-Ebene: Auflösung von Entscheidungsblockaden zwischen Domänen; Sicherstellung einer einheitlichen externen Kommunikationslinie **Befugnisse:** - Weisungsbefugnis gegenüber allen an der Aktivierung beteiligten Personen innerhalb des Geltungsbereichs des Teams - Befugnis zur Vergabe von Ad-hoc-Aufträgen ohne vorgelagerte Freigabeketten - Budgetbefugnis für Ad-hoc-Ausgaben bis zu einer vorab durch die Organisation festgelegten Grenze - Befugnis, die Teamzusammensetzung zu erweitern oder zu reduzieren - Befugnis, Infrastruktur innerhalb des Geltungsbereichs des Teams abzuschalten oder außer Betrieb zu nehmen - Recht auf direkte Eskalation an Geschäftsführung oder Vorstand - Recht auf Zugang zu allen aktivierungsrelevanten Informationen - Recht auf Zugang zu allen für die Aktivierung relevanten Einrichtungen **Kompetenzanforderungen:** - Starke Führungs- und Entscheidungsfähigkeit unter Unsicherheit - Solide Kenntnis des Problemlösungs-P – ausreichend, um ihm ohne Widerstand zu folgen und Abweichungen zu erkennen - Vertrauen in die Prozessautorität des Facilitators - Kommunikations- und Koordinationsfähigkeit über Organisationsgrenzen hinweg - Belastbarkeit, Durchsetzungsvermögen und Verantwortungsbewusstsein - Mindestübungshäufigkeit: zweimal pro Jahr in der Rolle des Owners - Bereitschaft zur Teilnahme an Rufbereitschaften **Ziele:** - Begrenzung von Schäden und Auswirkungen - Schnelle Wiederherstellung eines stabilen operativen Zustands - Wirksame und konsistente Lagebearbeitung innerhalb des Geltungsbereichs des Teams - Auf CMT-Ebene: kohärente, lageangemessene und durchsetzbare strategische Entscheidungen ### Rollenprofil: Facilitator Der Facilitator trägt die methodische Verantwortung für das Team. Auf DRT-Ebene ist dies der Incident Facilitator oder Domain Facilitator, auf CMT-Ebene der Crisis Facilitator. Die strukturelle Rolle ist über alle Ebenen hinweg identisch. Der Facilitator ist mit einem Scrum Master im agilen Projektmanagement vergleichbar: ein Methodenexperte, der den Prozess moderiert, die Zusammenarbeit strukturiert und Disziplin durchsetzt. Er kann generalistische Beobachtungen anbieten oder Annahmen im Sinne eines *advocatus diaboli* hinterfragen, bringt während der Aktivierung aber keine Domänenexpertise ein. Sein Wert liegt in der Prozessdurchsetzung, nicht im domänenspezifischen Inhalt. Der Facilitator verfügt über ein ausdrückliches Veto-Recht gegenüber Entscheidungen oder Handlungen des Owners, die gegen etablierte Methodik, definierte Verfahren oder formale Befugnisse verstoßen. Das Veto ist kein Vorschlag. Es ist dokumentiert und bindend, bis der Owner es mit ausdrücklicher, schriftlicher Begründung überstimmt. Der Facilitator hat außerdem ein besonderes Veto-Recht gegen verfrühte Deaktivierung. **Referenz für Veto-Auslöser** Das Veto-Recht des Facilitators wird im Problemlösungs-P in fünf ausdrücklich benannten Situationen ausgelöst: 1. **Erstbewertung** – wenn der Owner die Lage trotz begründeter Einwände des Facilitators als weder Notfall noch Krise einstufen will, obwohl die Aktivierungskriterien erfüllt sind. 2. **Lagevortrag** – wenn der Vortrag ausgelassen wird, so weit verkürzt wird, dass seine Funktion verloren geht, oder wenn wesentliche Teilnehmer fehlen. 3. **Entscheidungsfindung** – wenn eine Entscheidung außerhalb des definierten Prozesses, ohne tafelgestützte Bewertung oder unter hierarchischem Druck getroffen wird, der die Bewertung umgeht. 4. **Zielzuweisung** – wenn Ziele ohne Dokumentation auf den Tafeln oder ohne Anwesenheit der Domain Owner zugewiesen werden. 5. **Vorbereitung Lagevortrag** – wenn die Aktivierung ohne abgeschlossenen Debriefing-Plan oder entgegen den definierten Deaktivierungskriterien für beendet erklärt wird. **Dokumentation:** Bei Ausübung des Vetos dokumentiert der Facilitator schriftlich Zeitpunkt, Prozessschritt, Art des Verstoßes und Reaktion des Owners. Dieser Eintrag wird Teil der Aktivierungsdokumentation. Wenn eine Eskalation von einem Notfall zu einer Krise erfolgt, wird der Facilitator des aktiven IMT zum Crisis Facilitator des neu aktivierten CMT. Das IMT muss dann einen neuen Facilitator alarmieren und zuweisen, um seine eigene Prozessdisziplin aufrechtzuerhalten. Facilitators können domänenübergreifend eingesetzt werden – sie sind nicht an ein einzelnes Team gebunden. **Verantwortlichkeiten:** - Methodische Führung und Moderation des Problemlösungs-P - Strukturierung der Zusammenarbeit aller Beteiligten unter Zeitdruck - Sicherstellen, dass alle Beteiligten die definierten Prozesse, Werkzeuge und Entscheidungsverfahren verstehen und anwenden - Aktive Überwachung der Einhaltung von Abfolge und Methoden - Ausübung des Veto-Rechts bei Gefährdung der Prozessintegrität - Dokumentation der Aktivierung: fotografische Tafelprotokolle an definierten Punkten, Protokollierung von Aktivierungs- und Deaktivierungsentscheidungen, Dokumentation der Debriefing-Ergebnisse - Pflege von Tafel 3 als führendem Instrument zur Nachverfolgung der Umsetzung – nur der Facilitator bewegt Karten auf Tafel 3 - Vorbereitung jedes Lagevortragszyklus - Einweisung und Onboarding neuer Teammitglieder während einer Aktivierung - Sicherstellung klarer Kommunikation im Team - Verbleib im Krisenstabsraum oder Notfallraum während der Umsetzungsphase **Befugnisse:** - Veto-Recht bei Verstößen gegen etablierte Methodik, definierte Verfahren oder formale Befugnisse - Veto-Recht gegen verfrühte Deaktivierung - Befugnis, die Nutzung definierter Methoden und Werkzeuge einzufordern - Zugang zu allen relevanten Informationen und Dokumentationen - Befugnis, Teammitglieder auf methodische Anforderungen hinzuweisen und bei Nichteinhaltung einzugreifen - Teilnahme an allen Lagevorträgen, Entscheidungsrunden und Dokumentationsprozessen - Zugriff auf alle relevanten Systeme und Dokumentationsplattformen **Kompetenzanforderungen:** - Ausgeprägte Moderations- und Strukturierungsfähigkeit - Solide Kenntnisse der Krisen- und Notfallmanagementmethodik - Fähigkeit, einen strukturierten Prozess auch gegenüber hierarchisch höherstehenden Personen unter erheblichem Druck durchzusetzen - Fähigkeit zum Umgang mit Gruppendynamik in Hochstresssituationen - Neutrale und methodische Konfliktlösung unter Zeitdruck - Kommunikations- und Vermittlungsfähigkeit - Belastbarkeit, Durchsetzungsvermögen und methodische Konsequenz - Mindestübungshäufigkeit: zweimal pro Jahr in der Rolle des Facilitators - Abgeschlossene Qualifikation für die Facilitator-Funktion - Bereitschaft zur Teilnahme an Rufbereitschaften - Bereitschaft zum Einsatz über Domänen und Teamebenen hinweg **Ziele:** - Sicherstellung der methodischen Qualität und Konsistenz des Problemlösungs-P - Strukturierte und zielgerichtete Problemlösung unter Druck - Vollständige und nachvollziehbare Dokumentation aller Entscheidungen - Minimierung von Prozessrisiken und methodischen Fehlern ### Rollenprofil: Domain Owner Domain Owner vertreten feste funktionale Domänen im CMT. Sie bilden die strukturelle Brücke zwischen der strategischen Koordination des CMT und der operativen Umsetzung innerhalb ihrer Domäne. Der Domain Owner ist kein Berater, sondern trägt Verantwortung für Kohärenz, Machbarkeit und Durchhaltefähigkeit innerhalb der Domäne. Durch das Prinzip der Personenidentität ist der Domain Owner im CMT dieselbe Person wie der Owner des entsprechenden DRT. Diese Doppelfunktion beseitigt eine Kommunikationsschnittstelle: Dieselbe Person, die an der Planung im CMT teilnimmt, übersetzt CMT-Ziele in die Umsetzung auf Domänenebene und bringt den Status aus der Domäne zurück in das CMT. Domain Owner sind ausdrücklich befugt, CMT-Ziele im Kontext ihrer Domäne zu interpretieren. Wenn die operative Realität eine andere Priorisierung oder Taktung verlangt als vom CMT festgelegt, passt der Domain Owner an – muss die Abweichung aber offen an das CMT zurückmelden. Diese Interpretation von unten nach oben ist eine ausdrückliche Befugnis und kein Workaround. Standarddomänen: Operations, IT und technische Infrastruktur, HR, Finanzen und Verwaltung, Kommunikation. Sales kann eine eigene Domäne sein oder mit Kommunikation zusammengefasst werden. **Verantwortlichkeiten:** - Vertretung domänenspezifischer Perspektiven im CMT während der Planungsphase - Übersetzung von CMT-Zielen in Koordination auf Domänenebene - Führung des entsprechenden DRT - Bidirektionaler Informationsfluss zwischen CMT und DRT - Koordination nachgeordneter Reaktionsstrukturen innerhalb der Domäne - Verantwortung für Kohärenz und Machbarkeit der Domäne - Offene Rückmeldung von Abweichungen von CMT-Zielen an das CMT - Sicherstellung der Nachfolge in der Rolle des Domain Facilitator bei Eskalation **Befugnisse:** - Weisungsbefugnis gegenüber allen an der Aktivierung beteiligten Personen innerhalb der Domäne - Befugnis, CMT-Ziele innerhalb der Domäne auf Basis der operativen Realität zu priorisieren oder neu zu takten - Budgetbefugnis für Ad-hoc-Ausgaben innerhalb der Domäne bis zu einer definierten Grenze - Befugnis, das DRT zu erweitern oder zu reduzieren - Befugnis, Infrastruktur innerhalb der Domäne abzuschalten oder außer Betrieb zu nehmen - Recht auf Zugang zu allen domänenrelevanten Informationen - Recht auf direkte Eskalation an Geschäftsführung oder Vorstand in domänenspezifischen Fragen **Kompetenzanforderungen:** - Tiefe Domänenexpertise und Verständnis der operativen Realität der Domäne - Starke Führungs- und Entscheidungsfähigkeit - Fähigkeit zur Übersetzung zwischen strategischer und operativer Perspektive - Kommunikations- und Koordinationsfähigkeit - Belastbarkeit und Fähigkeit zum Umgang mit Doppelrollenanforderungen - Mindestübungshäufigkeit: zweimal pro Jahr - Bereitschaft zur Teilnahme an Rufbereitschaften **Ziele:** - Sicherstellung der operativen Handlungsfähigkeit der Domäne während der Aktivierung - Begrenzung der Auswirkungen innerhalb der Domäne - Schnelle Wiederherstellung der Funktionsfähigkeit der Domäne - Schutz der Organisation vor operativer Überlastung innerhalb der Domäne ### Rollenprofil: Supporter Supporter sind situative Mitglieder eines DRT, LRT oder ORT. Auf CMT-Ebene existieren sie nicht – die Unterstützungsstruktur des CMT besteht aus Domain Ownern. Supporter werden entsprechend den konkreten Anforderungen der Lage zugewiesen und unterstützen das Kernteam aus Owner und Facilitator, indem sie Verantwortung für definierte Maßnahmenpakete übernehmen. Supporter führen operative Aufgaben nicht selbst aus. Ihre Rolle besteht darin, die Umsetzung in ihrem Bereich zu koordinieren, Informationen zu strukturieren, Rückmeldungen zu verdichten und Fortschritte an das Team zu berichten. Sie agieren als Zielverantwortliche: Jeder Supporter verantwortet einen definierten Satz von Zielen auf Tafel 3. Über das Prinzip der Personenidentität kann ein Supporter, der Verantwortung für ein hinreichend komplexes Maßnahmenpaket übernimmt, zum Owner eines nachgeordneten Teams werden. Dadurch verschachtelt sich P-DRIVEN nach unten. Die Zahl der Supporter ist bewusst begrenzt. Ein DRT sollte nicht mehr als drei Supporter umfassen. Diese Grenze spiegelt Aspekte der Führungsspanne wider: Jedes zusätzliche Teammitglied erhöht den Kommunikationsaufwand und verringert die Entscheidungsgeschwindigkeit. Das Team ist ein Führungselement – es koordiniert, es führt nicht aus. **Verantwortlichkeiten:** - Koordination definierter Maßnahmenpakete im eigenen Bereich - Strukturierung und Verdichtung von Informationen, die für ihre Ziele relevant sind - Rückmeldung zu Machbarkeit, Fortschritt, Hindernissen und Nebenwirkungen - Proaktive Erkennung entstehender Probleme im eigenen Bereich - Keine direkte operative Ausführung – Supporter steuern Maßnahmen, sie setzen sie nicht selbst um **Befugnisse:** - Im Regelfall keine eigenständige Weisungsbefugnis - Weisungsbefugnis nur bei ausdrücklicher Delegation durch den Owner für ein bestimmtes Maßnahmenpaket - Befugnis, für die zugewiesenen Ziele erforderliche Informationen anzufordern - Beratungsfunktion: Recht, Maßnahmen vorzuschlagen und Vorgehensweisen zu empfehlen **Kompetenzanforderungen:** - Tiefe Fachkenntnis im jeweiligen technischen oder funktionalen Bereich - Fähigkeit, Probleme schnell zu analysieren und Informationen unter Druck zu strukturieren - Gute Kommunikations- und Kooperationsfähigkeit mit Owner und Facilitator - Flexibilität und Anpassungsfähigkeit an wechselnde Anforderungen - Verständnis von Tafellogik und Berichtsstruktur **Ziele:** - Operative Unterstützung und domänenspezifischen Input für das Team bereitstellen - Zur schnellen und wirksamen Problemlösung innerhalb der zugewiesenen Ziele beitragen - Beobachtungen und Erfahrungen für die Lernphase sammeln ### Qualifikationsübersicht nach Rolle | Rolle | Zentrale Kompetenz­anforderungen | Mindestübungs­häufigkeit | Qualifikations­voraussetzungen | |---|---|---|---| | **Owner** | Beherrschung des Problemlösungs-P, Entscheidungen an definierten Punkten, Führen über Ziele | Zweimal pro Jahr | *P-DRIVEN: Arbeitsbuch* abgeschlossen; Teilnahme an mindestens einer strukturierten Übung | | **Facilitator** | Vollständige Methodenbeherrschung, Prozessdurchsetzung, Veto-Autorität, Tafelmoderation, Stressresistenz | Zweimal pro Jahr | Abgeschlossene Qualifikation für die Facilitator-Funktion | | **Domain Owner** | Eigene Domänenexpertise, Verständnis der CMT-/DRT-Schnittstelle, Prinzip der Personenidentität | Zweimal pro Jahr | Owner-Qualifikation auf DRT-Ebene; Vertrautheit mit dem Prinzip der Personenidentität | | **Supporter** | Tafellogik, Berichtsstruktur, Umfang der Befugnisse im Team | Kein fester Mindestwert | *P-DRIVEN: Arbeitsbuch* abgeschlossen; Orientierungseinweisung | ### Teamstrukturen #### Incident Management Team (IMT) / Domain Response Team (DRT) Ein IMT oder DRT ist eine P-DRIVEN-Problemlösungsstruktur für Notfälle innerhalb eines definierten Bereichs. Wenn sie unter einem CMT innerhalb von Domänengrenzen arbeitet, wird sie DRT genannt. Die Organisationsform ist identisch. Das Team ist als Führungs- und Koordinationselement konzipiert. Es führt operative Aufgaben nicht selbst aus; es steuert Problemlösung und Umsetzung über Ziele und Koordination. ![*Incident Management Team (IMT) / Domain Response Team (DRT) – Kernteam mit Owner, Facilitator und Supportern*](svg/imt-drt-structure-de.pdf){width=90%} #### Crisis Management Team (CMT) Das Crisis Management Team ist die strategische P-DRIVEN-Problemlösungsstruktur für organisationsweite Krisen. Es arbeitet mit breiterem Geltungsbereich und längerem Planungshorizont und koordiniert, wenn eingerichtet, mehrere nachgeordnete Reaktionsstrukturen. Wie das IMT ist auch das CMT ein Führungs- und Koordinationselement. Es ersetzt nicht das operative Management und setzt Maßnahmen nicht direkt selbst um. ![*Crisis Management Team (CMT) – Doppeltes Führungskernteam mit Domain Ownern und DRTs*](svg/cmt-structure-de.pdf){width=90%} Das CMT wird von einem Crisis Owner geführt und von einem Crisis Facilitator moderiert. Domain Owner bilden die permanente Unterstützungsstruktur und vertreten jeweils eine definierte organisatorische Domäne. Der Crisis Owner ist kein Domain Owner – der Crisis Owner besitzt die Krise. #### Standarddomänen Die folgenden Domänen bilden die Standardzusammensetzung des CMT. Jede Domäne wird von einem Domain Owner geführt. #### Domäne Operations Die Domäne Operations repräsentiert die operativen Kern- und wertschöpfenden Tätigkeiten der Organisation. Ihre primäre Perspektive ist die Fähigkeit, operative Prozesse unter Krisenbedingungen fortzuführen, anzupassen, auszusetzen oder wiederherzustellen. Die Domäne bewertet, wie sich die Lage auf laufenden Betrieb, Leistungserbringung, Produktion, Projekte und Abhängigkeiten wie Lieferanten oder Partner auswirkt. Sie bringt operative Machbarkeit und Nebenwirkungen in die strategische Entscheidungsfindung ein und übersetzt CMT-Ziele in koordinierte operative Reaktionen. Die Domäne Operations stellt sicher, dass Informationen aus betroffenen operativen Einheiten verdichtet in das CMT zurückfließen und Entscheidungen klar in nachgeordnete Reaktionsstrukturen kommuniziert werden. #### Domäne IT und technische Infrastruktur Die IT-Domäne repräsentiert Informationstechnologie, operative Technologie und technische Infrastruktur, die für die Handlungs- und Kommunikationsfähigkeit der Organisation erforderlich sind. Ihre Perspektive umfasst Verfügbarkeit, Integrität und Wiederherstellbarkeit von Systemen, Daten und technischen Services. Die Domäne koordiniert IT-bezogene Reaktionsmaßnahmen, bewertet technische Risiken und Beschränkungen und stellt sicher, dass technische Abhängigkeiten in der strategischen Planung berücksichtigt werden. In enger Abstimmung mit der Kommunikationsdomäne sichert die IT die technische Fähigkeit zur internen und externen Kommunikation während der gesamten Krise. #### Domäne HR Die HR-Domäne repräsentiert alle personalbezogenen Aspekte, die die Belegschaft der Organisation betreffen. Ihr Fokus liegt auf Personalverfügbarkeit, Fürsorgepflicht, rechtlichen und vertraglichen Beschränkungen sowie den Auswirkungen der Lage auf Arbeitsbedingungen und Personaleinsatz. Die Domäne bewertet, wie sich krisenbedingte Maßnahmen auf Beschäftigte auswirken, und unterstützt die Entwicklung tragfähiger personalbezogener Reaktionen. HR stellt die Ausrichtung auf Arbeitsrecht, Tarifverträge und Mitbestimmungsanforderungen sicher und koordiniert die Umsetzung innerhalb der Personalstrukturen der Organisation. #### Domäne Finanzen und Verwaltung Die Domäne Finanzen und Verwaltung repräsentiert finanzielle, administrative, rechtliche und einrichtungsbezogene Perspektiven, die nicht ausdrücklich anderen Domänen zugewiesen sind. Ihr Fokus liegt auf finanzieller Tragfähigkeit, rechtlicher Umsetzbarkeit, Beschaffung, vertraglichen Verpflichtungen sowie Verfügbarkeit und Schutz physischer Vermögenswerte und Einrichtungen. Die Domäne bewertet Beschränkungen, die sich aus Budget, Recht oder Verwaltung ergeben, und koordiniert ermöglichende Maßnahmen wie Beschaffung, Vertragsgestaltung oder Zugangskontrolle. Finanzen und Verwaltung bilden das querschnittliche Rückgrat, das andere Domänen befähigt, innerhalb zulässiger und tragfähiger Grenzen zu handeln. #### Domäne Kommunikation Die Domäne Kommunikation repräsentiert interne und externe Kommunikationswirkungen und -anforderungen. Ihre Perspektive fokussiert auf Glaubwürdigkeit, Konsistenz, Timing und adressatengerechte Kommunikation. Die Domäne koordiniert Botschaften an interne Stakeholder, Kunden, Partner, Behörden sowie gegebenenfalls Öffentlichkeit und Medien. Kundennahe Kommunikation wird dieser Domäne zugeordnet, wenn die Interaktion mit Kunden kritisch wird. Wo erforderlich, kann diese Perspektive organisatorisch getrennt werden, während sie funktional an die Kommunikationsdomäne angebunden bleibt. Die Domäne stellt sicher, dass Kommunikation mit Lagebewusstsein, Entscheidungsfindung und verfügbarer Information ausgerichtet ist und die Kommunikationsfähigkeit während der gesamten Krise erhalten bleibt. #### Domäne Sales Die Domäne Sales repräsentiert kundenbezogene kommerzielle Beziehungen und umsatzkritische Interaktionen. Ihre Perspektive fokussiert die Auswirkungen der Krise auf Kunden, Verträge, Leistungszusagen und Umsatzströme. Die Domäne bewertet Risiken im Zusammenhang mit Kundenbindung, vertraglichen Verpflichtungen, Vertragsstrafen und Eskalationsdynamiken in Schlüsselkundenbeziehungen. Sales stellt sicher, dass kundenspezifische Auswirkungen systematisch in die strategische Problemlösung einfließen und dass kommerzielle Erwägungen mit operativer Machbarkeit und Kommunikationsstrategie abgestimmt sind. Die Domäne koordiniert kundenbezogene Maßnahmen innerhalb der vom CMT gesetzten Grenzen und sichert Konsistenz über Kunden und Regionen hinweg. #### Zusammenlegung von Domänen P-DRIVEN definiert einen Standardsatz von Domänen, um sicherzustellen, dass alle relevanten Perspektiven bei Problemlösung auf Krisenebene vertreten sind. Diese Domänen spiegeln funktionale Bedürfnisse wider, nicht Organigramme. In Organisationen mit geringerer Komplexität, begrenztem Personal oder in Lagen, in denen der Umfang der Krise keine vollständige Differenzierung erfordert, können Domänen zusammengelegt werden. Diese Zusammenlegung ist eine strukturelle Entscheidung, die die Problemlösungsfähigkeit unter eingeschränkten Bedingungen erhalten soll. Die Zusammenlegung von Domänen verändert die zugrunde liegende Logik von P-DRIVEN nicht. Alle Perspektiven der Standarddomänen bleiben erforderlich und müssen ausdrücklich berücksichtigt werden, auch wenn sie durch weniger Rollen repräsentiert werden. Typische und zulässige Zusammenlegungen sind: * Kommunikation mit Sales * Finanzen und Verwaltung mit HR * Operations mit IT und technischer Infrastruktur Die Zusammenlegung darf nicht dazu führen, dass Perspektiven entfallen. Wenn eine Domäne zusammengeführt wird, bleiben ihre Verantwortlichkeiten vollständig im Geltungsbereich und müssen in der Entscheidungsfindung aktiv vertreten werden. Mit zunehmender Komplexität, Reichweite oder Kommunikationsintensität sollten zusammengelegte Domänen wieder getrennt werden, um Überlastung, Verlust von Lagebewusstsein oder verzögerte Koordination zu vermeiden. ![*CMT mit zusammengelegten Domänen – Domain-Owner-Struktur in Krisenkonfiguration*](svg/cmt-consolidated-de.pdf){width=90%} ## Vom Lernen zur Anwendung: Vorbereitung auf den Einsatz in realen Lagen P-DRIVEN konzeptionell zu verstehen, erzeugt nicht automatisch operative Handlungsfähigkeit. Dieses Arbeitsbuch erläutert die Logik des Vorgehensmodells, die Struktur der Rollen und die disziplinierte Abfolge des Problemlösungs-P. Ob P-DRIVEN in realen Lagen wirksam angewendet werden kann, hängt davon ab, ob diese Elemente in organisatorische Praxis übersetzt werden. Vorbereitung beginnt mit struktureller Klarheit. Rollen müssen formal definiert, Befugnisse zugewiesen und Domänengrenzen ausdrücklich bestimmt werden. Die doppelte Führungsstruktur muss vor Eintritt einer Lage etabliert sein. Insbesondere Facilitators benötigen vorherige Qualifikation, da methodische Integrität unter Druck nicht improvisiert werden kann. P-DRIVEN ist darauf ausgelegt, mit minimaler Vorbereitung zu funktionieren. Es benötigt keine komplexen Simulationen oder umfangreichen Szenariobibliotheken, um nutzbar zu werden. Strukturierte Schulungen und Übungen verbessern jedoch die Qualität der Anwendung erheblich. Teams, die die disziplinierte Abfolge des Problemlösungs-P geübt haben, entwickeln typischerweise differenziertere Optionen, erkennen Abhängigkeiten früher und vermeiden verfrühte Verengung auf Einzellösungen. Übungen sollten sich auf Prozessdisziplin und nicht auf Szenariorealismus konzentrieren. Ziel ist nicht, bestimmte Ereignisse zu proben, sondern die Abfolge, Entscheidungspunkte und Koordinationslogik des P-DRIVEN-Modells zu verinnerlichen. Zur Vorbereitung gehört auch, dass das Vorgehensmodell in der Organisation verankert wird. Schnittstellen zu Geschäftsführung oder Vorstand, Kommunikationskanäle und Dokumentationspraxis müssen im Vorfeld geklärt sein. Der Übergang vom Regelbetrieb in ein formelles IMT oder CMT sollte strukturell definiert sein. P-DRIVEN bildet dafür den übergreifenden Rahmen. Für eine schrittweise Roadmap zur Einführung – vom ersten Mandat über Rollenzuweisung, Ausstattung und erste Übungen – siehe Teil VI, Kapitel 2. # Teil II – Das Problemlösungs-P ## Logik und Zweck des Problemlösungs-P Im Kern von P-DRIVEN liegt das strukturierte Problemlösungs-P. Die visuelle und konzeptionelle Idee des P ist vom „Planning P“ des Incident Command System (ICS) inspiriert. Das Planning P veranschaulicht eine disziplinierte Abfolge von Briefing, Planung, Entscheidungsfindung und operativer Ausführung im Notfallmanagement. P-DRIVEN übernimmt diese strukturelle Klarheit, wendet sie aber auf einen breiteren organisatorischen Kontext an und erweitert sie zu einem allgemeinen Vorgehensmodell für den Umgang mit Unsicherheit in Notfällen und Krisen. ![*Das Problemlösungs-P – 16-Schritte-Prozess mit Initiierungs-, Planungs-, Umsetzungs- und Lernphase*](svg/problem-solving-p-de.pdf){width=90%} Das Problemlösungs-P bildet eine definierte Schrittfolge ab, die kollektives Denken und koordiniertes Handeln strukturiert. Es stellt sicher, dass Teams diszipliniert und transparent von Lageverständnis zu Entscheidungsfindung und abgestimmter Umsetzung gelangen. Die Struktur des Problemlösungs-P ist in vier Phasen gegliedert: **1) Initiierungsphase** Die Initiierungsphase stellt die Kontrolle über die Lage her. Sie klärt, ob eine formale Problemlösungsstruktur erforderlich ist, definiert Geltungsbereich und Verantwortung und schafft das anfängliche gemeinsame Verständnis, das für das weitere Vorgehen notwendig ist. Ziel ist nicht Vollständigkeit, sondern Stabilität und Orientierung. **2) Planungsphase** Die Planungsphase strukturiert Analyse und Strategieentwicklung. Das Team klärt das Problem, definiert Ziele, entwickelt alternative Handlungsoptionen und bewertet deren Konsequenzen. Diese Phase trennt Denken bewusst von Ausführung, um verfrühte Lösungsfixierung zu vermeiden. Ein Kernziel ist die Erweiterung des Entscheidungskorridors. **3) Umsetzungsphase** Die Umsetzungsphase übersetzt Entscheidungen in koordiniertes Handeln. Ziele werden delegiert, Fortschritt wird überwacht und bei Bedarf angepasst. Die Ausführung bleibt mit den in der Planung definierten Zielen und Annahmen verbunden. **4) Lernphase** Die Lernphase verdichtet die während der Umsetzung gewonnenen Erkenntnisse. Annahmen, Entscheidungen und Ergebnisse werden überprüft, um organisationale Resilienz zu stärken und künftige Leistungsfähigkeit zu verbessern. Lernen ist kein optionaler Zusatz, sondern integraler Bestandteil disziplinierter Problemlösung. Die Abfolge des Problemlösungs-P ist nicht willkürlich. Jede Phase erzeugt definierte Ergebnisse, die als Grundlage für die nächste dienen. Phasen zu überspringen oder umzuordnen bricht diese Logik und schwächt die Verlässlichkeit von Entscheidungen. Das Problemlösungs-P ist skalierbar. Dieselbe Struktur gilt im IMT, im DRT oder im CMT. Unterschiede liegen in Geltungsbereich, Tiefe und Zeithorizont, nicht in der Logik des Prozesses. Das Problemlösungs-P ist weder Kreativitätstechnik noch lineare Checkliste. Es ist ein Koordinationsmechanismus, der Entscheidungsfindung unter Unsicherheit stabilisiert. In P-DRIVEN sind Führung, Teamzusammensetzung und Werkzeugnutzung auf diese Struktur ausgerichtet. Das Problemlösungs-P bildet damit das strukturelle Rückgrat des gesamten Vorgehensmodells. ### Zeitreferenz für eine Iteration Die folgende Tabelle enthält Orientierungswerte für die Dauer der einzelnen Schritte des Problemlösungs-P. Es handelt sich um Referenzwerte und nicht um starre Vorgaben. Die tatsächliche Dauer hängt von der Komplexität der Lage, der Größe des Teams, der Teamebene und dem Reifegrad der Organisation ab. ORT und DRT mit konkreten domänenspezifischen Problemen bewegen sich eher am unteren Ende, Zyklen auf CMT-Ebene eher am oberen. | Phase | Schritt | Dauer | |-------|------|----------| | **Initiierung** | Alarmierung | Variabel | | | Erstbewertung | 5–15 Min | | **Planung** | Lagevortrag | 5–10 Min | | | Lagefeststellung (Tafel 1) | 5–15 Min | | | Lagebewertung (Tafel 1) | 5–10 Min | | | Entscheidungsfindung (Tafel 2) | 15–60 Min | | | Zieldefinition (Tafel 3) | 5–15 Min | | | Zielzuweisung (Tafel 3) | 5–10 Min | | **Planungsphase gesamt** | | **ca. 45–120 Min** | | **Umsetzung** | Lage einfrieren | 5 Min | | | Auftragsübermittlung | 5–10 Min | | | Auftragsbearbeitung | IMT/DRT: 2–8 Stunden; CMT: 4–72 Stunden | | | Auftragsnachverfolgung | Fortlaufend | | | Fortschreibung der Lage (Tafel 3) | Fortlaufend | | | Vorbereitung Lagevortrag | 5 Min | | **Lernen** | Debriefing | 15–30 Min | | | Strukturiertes Feedback | 2–4 Stunden | Die Umsetzungsphase sollte nicht zu knapp bemessen werden. Auf IMT- und DRT-Ebene sollte sie in der Regel zwischen zwei und acht Stunden dauern. Auf CMT-Ebene liegt das sinnvolle Zeitfenster bei vier bis 72 Stunden, da der Planungshorizont breiter ist und nachgeordnete Teams Zeit brauchen, ihre eigenen Iterationen abzuschließen, bevor sie zurückmelden. Gerade in der ersten Iteration bestehen Rückmeldungen häufig noch nicht aus abgeschlossenen Ergebnissen. Typisch sind zunächst Rückmeldungen zu Aktivierungsfortschritt, Restriktionen, ersten Wirkungen und neu erkannten Problemen. Der Facilitator ist dafür verantwortlich, die Taktung der Iteration auf jeder Ebene entsprechend festzulegen. Die Initiierungsphase findet pro Aktivierung nur einmal statt, nicht pro Iteration. Die Lernphase findet ebenfalls nur einmal statt, nach der Deaktivierung. ## Initiierungsphase ### Schritt 1: Alarmierung #### Zweck des Schritts Die Alarmierung befähigt die Organisation, ohne Verzögerung zu reagieren, sobald definierte Eskalationskriterien erfüllt sind. Zweck dieses Schritts ist die schnelle und strukturierte Aktivierung der benannten P-DRIVEN-Rollen. Die Alarmierung stellt sicher, dass eine formale Problemlösungsstruktur – entweder ein Incident Management Team oder ein Crisis Management Team – eingerichtet ist, bevor informelle Koordination oder unkontrollierte Eskalation eintreten. Die Alarmierung wird über eine definierte Triagestelle ausgelöst, sobald ein vorab festgelegtes Aktivierungskriterium erfüllt ist. Ziel ist nicht die vertiefte Analyse der Lage, sondern die Einleitung einer disziplinierten Struktur. #### Beabsichtigtes Ergebnis Der Schritt ist abgeschlossen, wenn: - eine definierte Problemlösungsstruktur formell aktiviert ist, - die erforderlichen Rollen alarmiert wurden und mindestens eine qualifizierte Person pro Rolle Verantwortung übernommen hat, - ein definierter Besprechungsort aktiviert ist, - die Organisation von informeller Reaktion zu strukturierter Problemlösung übergegangen ist. Für jede Teamebene müssen Alarmierungsprozesse vorab definiert sein. Dazu gehören: - klare Aktivierungskriterien, - definierte Rollenlisten je Team, - ein gepflegtes Alarmierungssystem, - ausreichende Redundanz zur rechtzeitigen Übernahme jeder Rolle. Die Alarmierung muss immer sowohl die fachliche Führungsrolle als auch den zugehörigen Facilitator erreichen. Die doppelte Führungsstruktur muss von Beginn an aktiviert sein. Die Zahl der Personen pro Rolle sollte eine hohe Wahrscheinlichkeit rechtzeitiger Übernahme sicherstellen. Wo kein formales Bereitschaftssystem besteht, müssen mehrere qualifizierte Personen pro Rolle im Voraus benannt werden. #### Typische Missverständnisse und frühe Abweichungen **Telefonketten und einzelne Ausfallpunkte** Auf sequenziellen Telefonketten basierende Alarmierungsmechanismen schaffen strukturelle Fragilität. Wenn Aktivierung davon abhängt, dass eine Person die nächste erreicht, wird der gesamte Prozess anfällig für Verzögerung oder Ausfall. Eine einfache Zeitberechnung zeigt das Risiko: Fünf Rollen sequenziell mit zehn Anrufversuchen à 30 Sekunden zu alarmieren, verbraucht bereits mehrere Minuten, noch ohne erfolgreiche Gespräche, Rückrufe und Koordination. Unter Zeitdruck sind solche Verzögerungen operativ relevant. Alarmierung muss parallelisiert und systemgestützt erfolgen. Redundanz ist eine Designanforderung und kein Notbehelf. **Unzureichende Rollenredundanz** Rollen auf eine kleine Gruppe von Führungskräften zu begrenzen, schafft künstliche Engpässe. P-DRIVEN-Rollen sind funktionale Rollen und keine Statusrollen. Die Fähigkeit, als Incident Owner oder Crisis Facilitator zu handeln, hängt von Qualifikation und Prozessdisziplin ab, nicht von hierarchischer Position. Organisationen, die diese Rollen exklusiv an Spitzengremien binden, riskieren verzögerte Aktivierung und strukturelle Überlastung. **Zögern beim Ausrufen des Notfalls** Eine häufige Abweichung ist verzögerte Aktivierung aus Zögern, Unsicherheit oder Sorge um Reputationswirkungen. Diese Zurückhaltung führt zu informellen Koordinationsversuchen, bevor formale Strukturen etabliert sind. P-DRIVEN toleriert frühe oder sogar unnötige Aktivierung. Der nachfolgende Bewertungsschritt bietet einen strukturierten Mechanismus zum Herunterskalieren oder Deaktivieren. Verzögerte Aktivierung hingegen reduziert die Stabilisierungsfähigkeit und erhöht unkontrollierte Eskalation. **Überpersonalisierung der Alarmierung** An konkrete Personen statt an definierte Rollen geknüpfte Alarmierung erzeugt Verwirrung, wenn sich Verfügbarkeiten ändern. Rollen müssen strukturell definiert und mit mehreren qualifizierten Personen hinterlegt sein. Alarmierung richtet sich immer an Rollen, nicht an Personen. **Aktivierung ohne strukturelle Einsatzbereitschaft** Alarmierung ohne vordefinierte Treffpunkte, Kommunikationskanäle oder klare Rollendefinitionen auszulösen, führt sofort zu Momentumverlust. Alarmierung ist nicht bloß Benachrichtigung – sie ist der Übergang vom Regelbetrieb zur strukturierten Problemlösung. **Eskalation ohne formale Erklärung** Teams beginnen mitunter domänenübergreifende Koordination, ohne die Aktivierung eines IMT oder CMT formell zu erklären. Das schafft parallele Entscheidungswege, unklare Befugnisse und inkonsistente Kommunikation. Strukturelle Aktivierung muss domänenübergreifender Koordination vorausgehen. #### Aktivitäten des Facilitators in diesem Schritt - Verfügbarkeit über das Alarmierungssystem bestätigen. - Unverzüglich in den Krisenstabsraum oder Notfallraum gehen. Wenn der Facilitator vor dem Owner eintrifft, den Raum vorbereiten: drei Tafeln aufbauen, Moderationskarten und Marker auslegen, Kommunikationsmittel prüfen. - Prüfen, ob das Alarmierungssystem alle erforderlichen Rollen erreicht hat. Wenn kritische Rollen unbestätigt bleiben, mit dem Owner die Eskalation an Ersatzpersonen abstimmen. - Die Struktur für die Erstbewertung vorbereiten: Orientierungsfragen bereithalten, Uhr für die Zeitvorgabe vorbereiten. ### Schritt 2: Erstbewertung #### Zweck des Schritts Die Erstbewertung stellt unmittelbar nach der Alarmierung ein erstes strukturiertes Verständnis der Lage her. Ihr Zweck ist es, innerhalb des aktivierten Teams ein gemeinsames Lagebild zu schaffen, festzustellen, ob formal ein Notfall oder eine Krise vorliegt, und unmittelbare Stabilisierungsmaßnahmen zu definieren. Ziel ist Orientierung und strukturelle Klarheit. Der Schritt zielt nicht auf Vollständigkeit. Das Team tritt ohne Verzögerung zusammen, physisch oder virtuell. Die Erstbewertung markiert den Übergang von der Aktivierung zur disziplinierten Problemlösung. #### Beabsichtigtes Ergebnis Der Schritt ist abgeschlossen, wenn: - ein gemeinsames vorläufiges Lagebild hergestellt wurde, - Geltungsbereich und potenzielle Auswirkungen der Störung umrissen sind, - unmittelbare Stabilisierungsmaßnahmen identifiziert und gegebenenfalls eingeleitet wurden, - eine formale Entscheidung getroffen wurde, ob die Lage einen Notfall oder eine Krise darstellt, - der nächste Koordinationspunkt terminiert wurde, - Kommunikationswege und Stakeholder-Benachrichtigungen geklärt sind. Die Erstbewertung konzentriert sich auf wesentliche Orientierungsfragen, etwa: - Welche Prozesse, Organisationseinheiten, Systeme oder Services sind betroffen oder potenziell betroffen? - Welche Dauer der Störung wird derzeit erwartet? - Welche Abhängigkeiten oder Kaskadeneffekte sind plausibel? - Welche Auswirkungen auf Kernbetrieb oder strategische Ziele sind absehbar? - Mit welchem Maß an öffentlicher oder stakeholderbezogener Sichtbarkeit ist zu rechnen? Die Entscheidung, ob formal ein Notfall oder eine Krise vorliegt, trifft der zuständige Owner innerhalb des Teamrahmens. Der Facilitator dokumentiert die Entscheidung einschließlich Zeit, Teilnehmer und Bewertungsgrundlage. Die Erstbewertung soll schnell abgeschlossen werden. Als Leitgedanke ist die Phase auf ein kurzes, vorab definiertes Zeitfenster ausgelegt. Das Ergebnis ist ein strukturierter Ausgangspunkt für die Planungsphase. Wenn absehbar ist, dass die Lage den anfänglichen operativen Zeithorizont überschreitet, wird die Aktivierung von Folgeschichten im Rahmen der Erstbewertung eingeleitet. Ziel ist die Sicherstellung kontinuierlicher Problemlösung ohne Struktur- oder Qualitätsverlust. Durchhaltefähigkeit erfordert die frühzeitige Vorbereitung von Ersatzpersonal, bevor Ermüdung, kognitive Überlastung oder Koordinationsbrüche eintreten. Schichtvorbereitung wird ausgelöst, wenn: - eine längere Dauer zu erwarten ist, - vordefinierte Zeitschwellen erreicht werden, - oder die Kontinuität mit dem aktuellen Team nicht gesichert werden kann. Folgepersonal wird vorab alarmiert und bleibt bis zur Übergabe in Bereitschaft. Schichtwechsel sind strukturiert und gestuft. Verantwortung wird schrittweise und nicht gleichzeitig übertragen. Typischerweise beginnt der Wechsel beim Owner, gefolgt vom Facilitator und dann den unterstützenden Rollen. Zu keinem Zeitpunkt sollten mehrere kritische Rollen gleichzeitig übergeben werden. Eine Übergabe ist erst abgeschlossen, wenn die eingehende Rolle vollständiges Lageverständnis und operative Bereitschaft bestätigt. Der Übergabepunkt wird ausdrücklich dokumentiert. Schichtvorbereitung und Übergabe sind keine administrativen Tätigkeiten. Sie sind Teil der Sicherung operativer Handlungsfähigkeit. #### Typische Missverständnisse und frühe Abweichungen **Verwechslung von Erstbewertung und Vollanalyse** Teams versuchen in diesem Schritt häufig, Vollständigkeit herzustellen. Das verzögert die strukturierte Planung und verbraucht Zeit, ohne die Stabilität zu verbessern. Die Erstbewertung dient Orientierung und Struktur; vertiefte Analyse gehört in die Planungsphase. **Vermeidung formaler Einstufung** Zögern, einen Notfall oder eine Krise formell auszurufen, führt zu Unklarheit bei Befugnissen und Kommunikation. Strukturelle Klarheit erfordert eine ausdrückliche Entscheidung. Eine Überklassifizierung kann später korrigiert werden; eine Unterklassifizierung untergräbt die Koordination. **Unmittelbare Lösungsfixierung** Unter Druck springen Teams oft direkt zu technischen oder operativen Gegenmaßnahmen, ohne Geltungsbereich und Abhängigkeiten zu klären. Ad-hoc-Maßnahmen zur Stabilisierung sind zulässig, dürfen aber die strukturierte Bewertung nicht ersetzen. **Unkontrollierte Kommunikation** Wenn externe Anfragen, interne Eskalationswünsche oder Medienfragen die Erstbewertung unterbrechen, destabilisiert das das Team. Nach Aktivierung müssen IMT oder CMT ihre Arbeitsfähigkeit schützen und in definierten Intervallen oder auf Basis validierter Informationen kommunizieren. **Parallele Seitenkoordination** Informelle domänenübergreifende Koordination außerhalb der formalen Teamstruktur während der Erstbewertung erzeugt inkonsistente Informationsflüsse und unklare Befugnisse. Alle strukturellen Entscheidungen müssen im aktivierten Team getroffen werden. **Übermäßige Orientierung an vordefinierten Kriterien** Formale Kriterien für die Feststellung von Notfällen oder Krisen unterstützen die Entscheidung, sind aber nicht abschließend. Mechanische Anwendung ohne Lageurteil kann zu Fehlklassifikationen führen. Kriterien leiten die Entscheidung, sie ersetzen Verantwortung nicht. **Verspätete Vorbereitung von Folgeschichten** Teams verschieben Schichtplanung oft, bis Ermüdung oder Überlastung sichtbar werden. Das führt zu sinkender Entscheidungsqualität, Strukturverlust und chaotischen Übergängen. Schichtvorbereitung muss früh beginnen und nicht erst dann, wenn die Leistungsfähigkeit bereits sinkt. #### Aktivitäten des Facilitators in diesem Schritt - Die Erstbewertung moderieren, das Team durch die Orientierungsfragen führen und die Zeitvorgabe durchsetzen. - Die formale Aktivierungsentscheidung dokumentieren. - Die drei Tafeln für den ersten Zyklus der Planungsphase vorbereiten. - Den Zeitpunkt des ersten Lagevortrags mit dem Owner abstimmen. - Bei ausgelöster Schichtvorbereitung sicherstellen, dass Folgepersonal alarmiert und die Übergabe dokumentiert wird. - **Veto-Situation:** Wenn der Owner die Lage trotz begründeter Einwände des Facilitators als weder Notfall noch Krise einstufen will, obwohl die Aktivierungskriterien erfüllt sind, greift der Facilitator ein: „Die Aktivierungskriterien sind erfüllt. Wir stufen die Lage als Notfall oder Krise ein und setzen den Prozess fort.“ Wenn der Owner darauf besteht, übt der Facilitator das Veto-Recht aus und dokumentiert es. ## Planungsphase Die Planungsphase überführt ein erstes Verständnis der Lage in strukturierte, zielorientierte Problemlösung. Sie markiert den Übergang vom Reagieren auf ein Ereignis zum aktiven Gestalten seiner Bewältigung. In vielen Organisationen ist diese Phase von unstrukturierten Diskussionen, verfrühter Entscheidungsfindung oder unmittelbaren Sprüngen in die Handlung geprägt. Dadurch vermischen Teams häufig Fakten mit Annahmen, Lösungen mit Problemen und Handlungen mit Absichten. Das führt zu Ineffizienzen, Fehlsteuerungen und vermeidbaren Fehlern. P-DRIVEN begegnet dem, indem es eine strikte methodische Trennung zwischen Lageverständnis, Problemidentifikation und -priorisierung, Entwicklung von Lösungsoptionen und Vorbereitung der Umsetzung erzwingt. Um dies zu erreichen, folgt die Planungsphase der **Drei-Tafel-Methode**, die den gesamten Prozess in drei getrennte und sequenzielle Visualisierungen gliedert. ### Die Drei-Tafel-Methode Die Drei-Tafel-Methode teilt die Planungsphase in drei klar getrennte Arbeitsräume: - **Tafel 1 – Probleme und Prioritäten** Fokus auf Lageverständnis, Problemidentifikation und Priorisierung. - **Tafel 2 – Lösungsstrategien** Strukturierung der Erzeugung und Bewertung möglicher Lösungsstrategien. - **Tafel 3 – Ziele und Umsetzung** Übersetzung ausgewählter Lösungen in konkrete, handlungsfähige Schritte mit Verantwortlichkeiten und Fristen. Diese Trennung ist nicht optional. Sie ist der Kernmechanismus, der Klarheit, Disziplin und Wirksamkeit im Problemlösungs-P sicherstellt. Jede Tafel beantwortet eine grundsätzlich andere Frage: - **Tafel 1:** Was sind unsere Probleme? - **Tafel 2:** Was können wir dagegen tun? - **Tafel 3:** Wie setzen wir es um? Durch diese Trennung verhindert die Methode typische Fehlmuster, zum Beispiel: - zu Lösungen zu springen, bevor das Problem verstanden ist, - operative Aufgaben mit strategischen Entscheidungen zu vermischen, - oder Prioritäten aus dem Blick zu verlieren. Der Facilitator ist dafür verantwortlich, das Team durch die Tafeln zu führen und sicherzustellen, dass jeder Schritt abgeschlossen ist, bevor der nächste beginnt, dass Ergebnisse klar dokumentiert sind und keine Phase ausgelassen oder zusammengelegt wird. ### Visualisierung der Drei-Tafel-Methode ![*Die Drei-Tafel-Methode – sequenzielle Logik von Problemidentifikation bis Umsetzung*](svg/three-board-method-de.pdf){width=90%} ### Schritt 1: Lagevortrag #### Zweck des Schritts Der Lagevortrag schafft zu Beginn der Planungsphase ein gemeinsames und strukturiertes Verständnis der aktuellen Lage. Er dient als kontrollierter Input für Tafel 1. Ziel ist nicht, alles Bekannte zu berichten, sondern nur die Informationen bereitzustellen, die nötig sind, um relevante Probleme zu identifizieren und zu formulieren. Der Vortrag wird durch den Owner gehalten und folgt einer vorgegebenen Struktur, um Vollständigkeit, Konsistenz und Vergleichbarkeit über Iterationen hinweg sicherzustellen. Die Verwendung einer festen Vortragsstruktur ist verpflichtend. Sie erzwingt Disziplin, reduziert Mehrdeutigkeit und verhindert, dass kritische Informationen ausgelassen werden. Die konkrete Struktur kann organisationsspezifisch variieren, muss aber mindestens aktuelle Lage, Ursache und Konsequenzen, die strategische Absicht der übergeordneten Führung, die Analyse möglicher weiterer Entwicklung und Risiken, offene Ziele und Restriktionen sowie die eigene Absicht des Owners für die nächste Iteration abdecken. Der Lagevortrag findet zu Beginn jedes Planungszyklus und nach relevanten Lageänderungen statt. #### Beabsichtigtes Ergebnis Am Ende des Lagevortrags teilen alle Beteiligten ein gemeinsames und abgestimmtes Verständnis davon, - was geschehen ist und warum, - welche Folgen bereits eingetreten sind oder als Nächstes eintreten könnten, - welche Risiken daraus resultieren, - welche Ziele offen sind, welche Restriktionen bestehen und welche Maßnahmen bereits laufen, - was die strategische Absicht der übergeordneten Führung ist, - und was die eigene Absicht des Owners für die nächste Iteration ist. Das Ergebnis ist nicht der Vortrag selbst, sondern eine **strukturierte Grundlage für die Problemidentifikation auf Tafel 1**. Das Team ist bereit, - Informationen in klar definierte Probleme zu übersetzen, - redundante Faktendiskussionen zu vermeiden, - und unmittelbar in die strukturierte Analyse überzugehen. Der Vortrag ist knapp und mit einer Zeitvorgabe versehen. Fragen werden im Anschluss kontrolliert durch den Facilitator geklärt. Während des Lagevortrags werden keine Entscheidungen getroffen. Entscheidungsfindung beginnt erst, nachdem Probleme ausdrücklich definiert und priorisiert wurden. #### Typische Missverständnisse und frühe Abweichungen **Der Vortrag als Berichtsritual** Teams behandeln den Lagevortrag häufig wie ein Status- oder Berichtswesen. Das führt zu übermäßiger Detailtiefe, Fokusverlust und sinkender Aufmerksamkeit. Der Lagevortrag dient nicht der Vollständigkeit, sondern der Relevanz für die Problemlösung. Ergebnisse früherer Iterationen – insbesondere Inhalte, die bereits auf den drei Tafeln sichtbar sind, vor allem auf Tafel 3 – müssen nicht erneut im Detail wiederholt werden. Abgeschlossene Ziele sollten nur dann angesprochen werden, wenn sie neue Probleme, Abhängigkeiten oder Klärungsbedarf erzeugen. Redundantes Berichten verringert die Effizienz, ohne die Entscheidungsqualität zu erhöhen. **Unstrukturierte oder inkonsistente Durchführung** Ohne feste Struktur werden Vorträge inkonsistent, unvollständig und zwischen Iterationen schwer vergleichbar. Kritische Informationen können fehlen, während irrelevante Details Zeit verbrauchen. **Vermischung von Information und Interpretation** Fakten, Annahmen und Interpretationen werden häufig ohne Unterscheidung dargestellt. Das erzeugt Verwirrung und führt zu fehlerhaften Problemdefinitionen. Der Vortrag muss verifizierte Informationen klar von Annahmen trennen. **Verfrühte Diskussion und Entscheidungsfindung** Teilnehmer unterbrechen den Vortrag häufig mit Fragen, Vorschlägen oder Entscheidungen. Das stört den Fluss und führt zu fragmentiertem Verständnis. Diskussion muss bis nach dem Vortrag zurückgestellt werden. **Überladung des Vortrags** Zu viele Details oder zu viele Aspekte führen zu kognitiver Überlastung. Der Vortrag muss knapp bleiben und sich auf das konzentrieren, was für den nächsten Schritt erforderlich ist. **Auslassen des Vortrags in Folgezyklen** Teams lassen den Lagevortrag in späteren Iterationen mitunter aus, weil sie gemeinsames Verständnis unterstellen. Das führt zu Divergenz, verborgenen Annahmen und Koordinationsproblemen. Jeder Zyklus verlangt erneute Ausrichtung. **Den Vortrag als Selbstzweck behandeln** Der kritischste Fehler ist, den Vortrag nicht in Probleme zu übersetzen. Information, die nicht in Problemstellungen überführt wird, hat innerhalb von P-DRIVEN keinen operativen Wert. #### Aktivitäten des Facilitators in diesem Schritt - Den Lagevortrag eröffnen, die Zeit nennen und bestätigen, wer anwesend ist. - Die Zeitvorgabe durchsetzen und dem Owner signalisieren, wenn die Zeit knapp wird. - Sicherstellen, dass der Owner der vorgegebenen Struktur folgt. - Unterbrechungen während des Vortrags verhindern. Fragen, Kommentare und Vorschläge werden erst danach gesammelt. - Nach dem Vortrag eine kontrollierte Fragerunde moderieren und Fragen auf sachliche Klärung begrenzen. - **Veto-Situation:** Wenn der Owner oder ein Teammitglied versucht, die Lagefeststellung zu überspringen und direkt zu Lösungen überzugehen, greift der Facilitator ein und führt auf Tafel 1 zurück. Wenn der Owner darauf besteht, übt der Facilitator das Veto-Recht aus, dokumentiert es und setzt die definierte Abfolge fort. ### Schritt 2: Lagefeststellung #### Zweck des Schritts Der Zweck der Lagefeststellung besteht darin, das gemeinsame Lageverständnis in einen strukturierten Satz ausdrücklich benannter Probleme zu übersetzen. Dieser Schritt markiert den Übergang von Information zu Analyse. Er stellt sicher, dass das Team nicht auf vagen Eindrücken arbeitet, sondern auf klar formulierten Problemstellungen. Die Lagefeststellung findet auf **Tafel 1** statt und wird als fokussierte, zeitlich begrenzte Aktivität durchgeführt. Sie bündelt individuelle Perspektiven zu einem kollektiven Problemraum. Ziel ist nicht Vollständigkeit, sondern Relevanz. Berücksichtigt werden nur Probleme, die handlungsrelevant sind oder potenziell operative Auswirkungen haben. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts hat das Team erzeugt: - einen konsolidierten Satz klar formulierter Probleme, - gruppiert in sinnvolle Cluster, - ohne Redundanzen oder Mehrdeutigkeiten. Das Ergebnis bildet sowohl aktuell beobachtbare Themen als auch antizipierte Probleme ab, die in naher Zukunft wahrscheinlich auftreten werden. Dieser strukturierte Problemsatz bildet die Grundlage für die Priorisierung im nächsten Schritt. Problemstellungen sollen knapp, spezifisch und frei von impliziten Lösungen sein. Eine gut definierte Problemstellung beantwortet typischerweise: - **Was** ist das Problem? - **Wo** tritt es auf? - **Wann** tritt es auf oder könnte es auftreten? - **Wer** oder was ist betroffen? - **Welche Auswirkungen** hat es aktuell oder erwartbar? Der Prozess folgt einer strikten Abfolge: 1. **Individuelles Brainstorming** mit Zeitvorgabe. 2. **Sammeln der Probleme** auf Tafel 1. 3. **Clustern und Verdichten** durch den Facilitator. Das Ergebnis ist eine gemeinsame und reduzierte Darstellung der Problemlandschaft. #### Typische Missverständnisse und frühe Abweichungen **Lagen statt Probleme beschreiben** Teams wiederholen häufig Fakten aus dem Lagevortrag, anstatt Probleme zu formulieren. Eine Lage wird erst dann handlungsrelevant, wenn sie als Problem ausgedrückt wird. **Während des Brainstormings zu Lösungen springen** Teilnehmer schlagen häufig Maßnahmen vor, statt Probleme zu identifizieren. Das unterbricht die Logik der Methode und führt zu verfrühter Konvergenz. Lösungen werden ausschließlich auf Tafel 2 behandelt. **Mangel an Zeitdisziplin** Wenn das Brainstorming nicht strikt mit Zeitvorgabe erfolgt, entstehen Diskussionen und dominante Stimmen übernehmen. Das reduziert die Vielfalt der Beiträge und verlangsamt den Prozess. **Fehlende Antizipation zukünftiger Probleme** Teams fokussieren sich häufig nur auf aktuelle Probleme und vernachlässigen absehbare Entwicklungen. Das führt zu reaktivem Verhalten. Antizipation ist ein notwendiger Bestandteil wirksamer Problemidentifikation. #### Aktivitäten des Facilitators in diesem Schritt - Individuelles Brainstorming anstoßen und die Zeitvorgabe setzen. - Alle Karten nach Ende der Zeit einsammeln. - Karten sichtbar auf Tafel 1 clustern, Duplikate entfernen und bei Bedarf abstrahieren. - Karten mit Lösungen sichtbar trennen und für Tafel 2 vermerken. - Bei zu vagen Karten eine präzisere Problemformulierung verlangen. - Nach dem Clustern das Team die Tafel überprüfen und fehlende Probleme ergänzen lassen. - Den Abschluss der Lagefeststellung bestätigen, bevor zur Lagebewertung übergegangen wird. ### Schritt 3: Lagebewertung #### Zweck des Schritts Der Zweck der Lagebewertung besteht darin, die identifizierten Problemcluster strukturiert und transparent zu bewerten und zu priorisieren. Dieser Schritt stellt sicher, dass das Team nicht versucht, alle Probleme gleichzeitig zu lösen, sondern sich auf diejenigen mit der höchsten operativen Relevanz konzentriert. Die Lagebewertung findet auf **Tafel 1** statt und ist der letzte Schritt, bevor von der Analyse zur Lösungsgestaltung übergegangen wird. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts hat das Team eine begrenzte Zahl von **Top-Prioritäten** identifiziert, die in den folgenden Schritten bearbeitet werden. Die Bewertung folgt einem strukturierten zweidimensionalen Ansatz: - **Dringlichkeit** - **Wichtigkeit** Jede Person trägt zur Bewertung bei, indem sie je Dimension eine feste Anzahl von Stimmen vergibt. Die Ergebnisse werden in die **Eisenhower-Matrix** übertragen. Die endgültige Priorisierung wird bestimmt durch: 1. die Position des Problems in der Matrix, 2. die Zahl der erhaltenen Stimmen. Auf dieser Grundlage werden die **Top-5-Probleme** für die weitere Bearbeitung ausgewählt. Wenn die Rangfolge unklar ist, trifft der Owner die letzte Entscheidung. #### Typische Missverständnisse und frühe Abweichungen **Vermeidung von Reduktion** Teams zögern häufig, die Zahl der Probleme zu verringern, und versuchen zu viele Themen gleichzeitig zu bearbeiten. Das führt zu Fokusverlust und schwacher Umsetzung. Priorisierung verlangt bewussten Ausschluss. **Verwechslung von Dringlichkeit und Wichtigkeit** Unmittelbarer Druck wird oft überbewertet, strukturell kritische Probleme dagegen unterschätzt. Die Methode trennt diese Dimensionen ausdrücklich, um genau dieser Verzerrung entgegenzuwirken. **Hierarchie statt strukturierter Bewertung** Ohne disziplinierte Abstimmung kann Seniorität die Priorisierung unverhältnismäßig prägen. Die Abstimmungslogik soll verteilte Expertise aggregieren, nicht Hierarchie verstärken. #### Aktivitäten des Facilitators in diesem Schritt - Das Abstimmungsverfahren vorab erklären. - Abstimmungsmaterialien verteilen. - Ruhe während der Abstimmung durchsetzen. - Stimmen zählen, Probleme in die Eisenhower-Matrix übertragen und die Priorisierung laut vorlesen. - Bei Gleichständen die betroffenen Probleme dem Owner zur finalen Entscheidung vorlegen. - Die Top 5 mit dem Team bestätigen und sichtbar auf Tafel 1 markieren. ### Schritt 4: Entscheidungsfindung #### Zweck des Schritts Der Zweck der Entscheidungsfindung besteht darin, tragfähige Lösungsstrategien für jedes priorisierte Problem zu entwickeln und auszuwählen. Dieser Schritt markiert den Übergang von Analyse zu Entscheidungsfindung. Er stellt sicher, dass Maßnahmen nicht intuitiv oder verfrüht abgeleitet werden, sondern auf einer strukturierten Erkundung von Alternativen beruhen. Die Entscheidungsfindung findet auf **Tafel 2** statt. Sie erzwingt bewusstes Denken, indem sie mehrere Lösungswege verlangt, bevor eine Festlegung erfolgt. Ziel ist nicht die perfekte Lösung, sondern ein tragfähiger und rechtzeitiger Handlungsweg unter Unsicherheit. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts hat das Team **für jedes priorisierte Problem mindestens eine ausgewählte Lösungsstrategie** definiert. Der Prozess folgt einer strikten Sequenz: 1. **Erzeugung von Lösungsstrategien** Für jedes priorisierte Problem definiert das Team **drei unterschiedliche Lösungsstrategien**. Diese Anforderung ist verpflichtend. 2. **Strukturierte Bewertung von Optionen** Alle Strategien werden kurz nach Machbarkeit, Wirksamkeit, Risiken und Nebenwirkungen, Synergien und Abhängigkeiten bewertet. 3. **Auswahl der Strategie** Das Team wählt die geeignetste Strategie pro Problem im Konsens oder per Mehrheitsentscheidung. Ausgewählte Strategien werden auf **Tafel 2** klar markiert und bilden den direkten Input für **Tafel 3 – Ziele und Umsetzung**. #### Typische Missverständnisse und frühe Abweichungen **Zu wenige Lösungsoptionen definieren** Teams gehen häufig direkt zu einer bevorzugten Lösung über, ohne Alternativen ernsthaft zu prüfen. Das senkt die Lösungsqualität und erhöht das Risiko von blinden Flecken. Die Anforderung von drei Strategien soll genau diesem Muster entgegenwirken. **Nur oberflächliche Varianten bilden** Drei Variationen derselben Idee zu liefern, statt grundlegend verschiedener Ansätze, untergräbt den Zweck des Schritts. Echte Alternativen müssen sich in Logik oder Herangehensweise unterscheiden. **Ohne Reflexion auf Standardverfahren zurückfallen** Teams greifen mitunter reflexhaft auf bekannte Playbooks zurück, ohne zu prüfen, ob sie zur konkreten Lage passen. Etablierte Verfahren sind zulässige Optionen, müssen aber dennoch neben Alternativen bewertet werden. #### Aktivitäten des Facilitators in diesem Schritt - Das Team von Tafel 1 zu Tafel 2 führen und Zeitvorgabe ankündigen. - Für jedes priorisierte Problem drei unterschiedliche Lösungsstrategien einfordern. - Strategien auf Tafel 2 notieren und sichtbar dem jeweiligen Problem zuordnen. - Die kurze Bewertung jeder Strategie moderieren. - Verfrühte Konvergenz unterbrechen und auf echte Alternativen bestehen. - Bei Bedarf die Zeitvorgabe ausdrücklich verlängern. - Die ausgewählten Strategien mit dem Team bestätigen. - **Veto-Situation:** Wenn der Owner die Strategieentwicklung überspringen will und direkt in die Auftragsvergabe geht, greift der Facilitator ein und dokumentiert im Konfliktfall das Veto. ### Schritt 5: Zieldefinition #### Zweck des Schritts Der Zweck der Zieldefinition besteht darin, ausgewählte Lösungsstrategien in konkrete Ziele zu übersetzen, die zugewiesen, umgesetzt und nachverfolgt werden können. Dieser Schritt markiert den Übergang von der Entscheidung darüber, *was* getan werden soll, zur Definition dessen, *was genau* erreicht werden muss. Er operationalisiert Strategie, ohne in unstrukturierte Aufgabenlisten zu verfallen. Die Zieldefinition findet auf **Tafel 3** statt. Sie schafft die Grundlage für koordinierte Umsetzung und spätere Nachverfolgung. Ziel ist nicht Aktivität, sondern klar definierte Ergebnisse. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts hat das Team für jede ausgewählte Lösungsstrategie ein oder mehrere **SMART-Ziele** definiert. Ziele müssen so formuliert sein, dass sie Ausführung und Steuerung ermöglichen. Jedes Ziel sollte sein: - **Spezifisch** - **Messbar** - **Erreichbar** - **Relevant** - **Terminiert** Ein gut definiertes Ziel beantwortet: - Was muss erreicht werden? - Woran erkennen wir den Erfolg? - Bis wann muss es erreicht sein? - Welche Ressourcen oder Beschränkungen sind relevant? Ziele müssen kurz und präzise sein. Sie sollen so formuliert werden, dass sie auf eine einzelne Karte passen, ohne an Klarheit zu verlieren. Alle Ziele werden auf **Tafel 3** übertragen, die als Umsetzungs- und Nachverfolgungsebene dient. #### Typische Missverständnisse und frühe Abweichungen **Strategien als Ziele verwenden** Einer der häufigsten Fehler besteht darin, Lösungsstrategien direkt auf Tafel 3 zu übertragen, als wären sie Ziele. Strategien sind konzeptionell und breit; Ziele müssen konkret und operativ sein. **Strategien direkt in Aufgaben übersetzen** Teams springen häufig von der Strategieauswahl unmittelbar in die Aufgabenvergabe. Dadurch wird die notwendige Abstraktionsebene der Ziele übersprungen und die Umsetzung fragmentiert. **Tätigkeiten statt Ziele definieren** Aussagen wie „Lieferanten anrufen“ oder „Systemstatus prüfen“ beschreiben Tätigkeiten, keine Ziele. Ziele müssen ausdrücken, was erreicht werden soll. #### Aktivitäten des Facilitators in diesem Schritt - Das Team von Tafel 2 zu Tafel 3 führen. - Für jede ausgewählte Strategie nach konkreten Zielen fragen. - Jedes Ziel auf eine Karte schreiben und in die Spalte „offen“ setzen. - Ziele gegen die SMART-Kriterien prüfen und bei vagen Formulierungen nachschärfen. - Sicherstellen, dass Ziele Ergebnisse und keine Tätigkeiten beschreiben. - Prüfen, dass jedes Ziel unter den aktuellen Bedingungen realistisch ist. ### Schritt 6: Zielzuweisung #### Zweck des Schritts Der Zweck der Zielzuweisung besteht darin, definierte Ziele verantwortlichen Rollen und erforderlichen Ressourcen zuzuordnen und die Ausführung transparent und handhabbar zu machen. Dieser Schritt übersetzt Ziele in koordiniertes Handeln, indem er sie mit Verantwortlichkeit, Kapazität und Umsetzungsstatus verknüpft. Die Zielzuweisung findet auf **Tafel 3** statt, die als strukturierte Umsetzungstafel fungiert. Sie stellt sicher, dass alle Aktivitäten über das Team hinweg sichtbar, nachvollziehbar und steuerbar sind. Ziel ist nicht nur die Vergabe von Arbeit, sondern die Herstellung eines gemeinsamen operativen Bildes darüber, wer was mit welchen Ressourcen und in welchem Status bearbeitet. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts sind alle Ziele: - einer klar definierten verantwortlichen Rolle zugeordnet, - mit den erforderlichen Ressourcen verknüpft, - und in einen definierten Umsetzungsstatus eingeordnet. Jedes Ziel wird als visuelles Element auf **Tafel 3** dargestellt und ermöglicht damit einen gemeinsamen und fortlaufend aktualisierten Überblick. Ressourcen werden ausdrücklich gesteuert: - Es dürfen nur Ressourcen zugewiesen werden, die verfügbar und in die Lage eingebunden sind. - Jede Ressource kann jeweils nur einmal gleichzeitig zugewiesen werden. - Wenn erforderliche Ressourcen nicht verfügbar sind, muss ein eigenes Ziel zu ihrer Beschaffung oder Aktivierung angelegt werden. Die Tafel muss so gepflegt werden, dass **Übergabefähigkeit jederzeit** gegeben ist. Jede neu eintretende Rolle muss den aktuellen Stand der Umsetzung ohne zusätzliche Erläuterung verstehen können. Zur Nachvollziehbarkeit sollten Ziele klar ihrer jeweiligen Iteration zugeordnet werden, etwa durch Farbcodierung oder Zeitstempel. #### Typische Missverständnisse und frühe Abweichungen **Unklare oder fehlende Verantwortlichkeit** Ziele ohne klar zugewiesene verantwortliche Rolle führen zu Verantwortungsdiffusion und verzögerter Umsetzung. Jedes Ziel muss genau einen rechenschaftspflichtigen Verantwortlichen haben. **Mehrere Verantwortliche zuweisen** Geteilte Verantwortung führt häufig dazu, dass faktisch niemand verantwortlich ist. Verantwortlichkeit muss ausdrücklich und eindeutig sein, auch wenn mehrere Personen beitragen. **Ressourcenbeschränkungen ignorieren** Teams weisen Ziele häufig zu, ohne die Ressourcenverfügbarkeit zu prüfen. Das führt zu Überlastung, Konflikten und unrealistischer Planung. Ressourcenzuweisung muss ausdrücklich und begrenzt erfolgen. **Doppelte Zuweisung von Ressourcen** Dieselbe Ressource gleichzeitig mehreren Zielen zuzuweisen, erzeugt verdeckte Engpässe und Verzögerungen. Ressourcennutzung muss transparent und exklusiv sein. **Nicht verfügbare Ressourcen nicht steuern** Teams gehen häufig stillschweigend davon aus, dass Ressourcen schon verfügbar werden. Fehlt eine Ressource, muss dies als Problem für die nächste Iteration oder als eigenes Ziel behandelt werden. **Die Tafel als Dokumentation statt als Steuerungsinstrument behandeln** Tafel 3 ist kein passives Protokoll. Wenn sie nicht aktiv zur Steuerung der Umsetzung genutzt wird, ist sie schnell veraltet und irrelevant. **Inkonsistente oder veraltete Statuspflege** Wenn der Status von Zielen nicht fortlaufend aktualisiert wird, verliert die Tafel ihre Funktion als Koordinationsinstrument. Der Status muss jederzeit die Realität abbilden. **Fehlende Übergabefähigkeit** Tafeln, die nur vom aktuellen Team verstanden werden können, schaffen erhebliche Risiken bei Schichtwechseln. Die Struktur muss so gestaltet sein, dass jedes eingehende Team die Lage unmittelbar erfassen kann. **Die Tafel überkomplizieren** Zu viele Status, Kategorien oder visuelle Elemente verringern die Klarheit. Die Tafel muss einfach, strukturiert und unter Druck schnell lesbar bleiben. #### Aktivitäten des Facilitators in diesem Schritt - Für jedes Ziel auf Tafel 3 sicherstellen, dass genau eine verantwortliche Person zugewiesen ist. Bei Unklarheit den Owner fragen: „Wer ist für dieses Ziel verantwortlich?“ - Auf Ressourcenkonflikte prüfen: Weder Personen noch Ressourcen dürfen mehreren Zielen gleichzeitig zugewiesen sein, ohne dass dies ausdrücklich anerkannt wird. Doppelzuweisungen markieren. - Prüfen, dass für alle Ziele Fristen gesetzt sind und diese innerhalb des aktuellen Planungshorizonts liegen. - Den Zeitpunkt des nächsten Lagevortrags festlegen. Er bestimmt die Länge der Iteration. Dies dem gesamten Team klar mitteilen. - Bestätigen, dass Tafel 3 vollständig ist: Jedes Ziel hat einen Verantwortlichen, eine Frist und den Status „offen“. Die Tafel als Schlussbestätigung laut vorlesen, bevor das Team in die Umsetzungsphase übergeht. - **Veto-Situation:** Wenn der Owner zur Umsetzung übergehen will, ohne die Zuweisung abzuschließen, greift der Facilitator ein: „Ziele ohne klare Verantwortlichkeit und Fristen können nicht nachverfolgt werden. Wir schließen die Zuweisung ab, bevor die Umsetzung beginnt.“ ## Umsetzungsphase ### Schritt 1: Lage einfrieren #### Zweck des Schritts Der Zweck von „Lage einfrieren“ besteht darin, die Planungsphase formell abzuschließen und einen stabilen Bezugspunkt für die Umsetzung zu schaffen. Der Schritt markiert den Übergang von strukturierter Entscheidungsfindung zu dezentraler Umsetzung. Indem der aktuelle Stand aller drei Tafeln eingefroren wird, stellt das Team sicher, dass die Umsetzung auf einem klar definierten, gemeinsamen und dokumentierten Plan beruht. „Lage einfrieren“ verhindert, dass während der Umsetzung ständig weiterdiskutiert wird, und schützt die Integrität der Planungsergebnisse. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts: - sind alle drei Tafeln abgeschlossen und dokumentiert, - ist eine klare Ausgangsbasis für die Umsetzung hergestellt, - und ist der Start des nächsten Planungszyklus festgelegt. Die Dokumentation erfolgt typischerweise durch vollständige visuelle Erfassung aller Tafeln, etwa per Foto. Sie dient als formaler Nachweis der Arbeit und Entscheidungsfindung des Teams. Die Dokumentation muss die Rekonstruktion ermöglichen von: - Lage und Problemstruktur, - den ausgewählten Strategien, - sowie den definierten Zielen einschließlich Verantwortlichkeiten und Ressourcen. Ein konkreter Zeitpunkt für den nächsten Lagevortrag wird gesetzt. Dadurch wird die Umsetzung zeitlich gerahmt und in einen neuen strukturierten Planungszyklus überführt. Nach dem Einfrieren: - beginnt die Umsetzung sofort, - wechseln die Teammitglieder in ihre jeweiligen operativen Rollen, - und arbeiten auf Grundlage der definierten Ziele weiter. Der Facilitator bleibt verantwortlich für die Pflege der dokumentierten Lage und die Vorbereitung der nächsten Iteration. #### Typische Missverständnisse und frühe Abweichungen **Während der Umsetzung weiterplanen** Teams verändern nach Beginn der Umsetzung häufig informell den Plan weiter. Das führt zu Inkonsistenzen, Verlust gemeinsamer Ausrichtung und unklaren Prioritäten. Nach dem Einfrieren müssen Änderungen in den nächsten Planungszyklus verschoben werden. **Dokumentation auslassen** Wenn die Tafeln nicht dokumentiert werden, geht Nachvollziehbarkeit verloren, und Entscheidungen können nicht rekonstruiert werden. Dokumentation ist nicht optional – sie ist der einzige verlässliche Nachweis strukturierter Entscheidungsfindung. **Kein definierter nächster Planungszyklus** Ohne einen klar gesetzten Zeitpunkt für den nächsten Lagevortrag wird die Umsetzung offen und unstrukturiert. Regelmäßige Iteration ist essenziell, um die Kontrolle zu halten. **Das Einfrieren als administrative Last behandeln** „Lage einfrieren“ wird mitunter als unnötige Bürokratie wahrgenommen. Tatsächlich ist es ein zentrales Steuerungsinstrument, das die Umsetzung stabilisiert und teamübergreifende Koordination ermöglicht. **Unvollständiger oder inkonsistenter Tafelstand** Wenn Tafeln vor dem Einfrieren nicht vollständig aktualisiert sind, beginnt die Umsetzung auf unklarer oder veralteter Grundlage. Das Einfrieren verlangt einen sauberen, konsistenten und vollständigen Stand. **Fehlende Trennung zwischen Planungs- und Umsetzungsraum** Wenn Teams im selben Setting bleiben und weiterdiskutieren, verwischt die Trennung zwischen Planung und Umsetzung. Physische oder logische Trennung stärkt Rollenklarheit und Fokus. **Der Facilitator verlässt den Krisenstabsraum oder Notfallraum** Wenn der Facilitator sich an der Umsetzung beteiligt, leiden Dokumentation und Koordination. Der Facilitator muss auf Strukturpflege und Vorbereitung des nächsten Zyklus fokussiert bleiben. #### Aktivitäten des Facilitators in diesem Schritt - Eine Fotodokumentation aller drei Tafeln anfertigen. Das ist der erste Dokumentationspunkt des Zyklus. - Bestätigen, dass der Zeitpunkt des nächsten Lagevortrags festgelegt und kommuniziert ist. - Im Krisenstabsraum oder Notfallraum bleiben. Der Facilitator verlässt ihn während der Umsetzungsphase nicht. - Beim Aufbruch in die Umsetzung sicherstellen, dass jede Person ihre zugewiesenen Ziele und den Berichtsrhythmus bestätigt. #### Der Facilitator während der Umsetzungsphase Nach „Lage einfrieren“ leert sich der Krisenstabsraum oder Notfallraum. Teammitglieder gehen in die Umsetzung ihrer Ziele. Der Facilitator bleibt. Das ist der längste zusammenhängende Abschnitt der Iteration und kann täuschend ruhig wirken – ist aber keine Leerlaufzeit. Die Arbeit des Facilitators folgt in dieser Phase einem konstanten Rhythmus: **Die ersten 15 Minuten nach „Lage einfrieren“:** Tafel-Fotos abschließen. Prüfen, dass Aufträge übermittelt werden, und zwar schriftlich, nicht nur mündlich. Mit jedem Teammitglied den Berichtsrhythmus bestätigen, bevor es den Raum verlässt. Den vereinbarten Zeitpunkt des nächsten Lagevortrags im Raum sichtbar notieren. **Fortlaufend während der Umsetzung:** Eingehende Statusmeldungen beobachten. Jede Meldung löst eine Aktualisierung von Tafel 3 aus – Karten von „offen“ nach „in Bearbeitung“, von „in Bearbeitung“ nach „abgeschlossen“ oder nach „blockiert“ bewegen. Den Grund für blockierte Ziele direkt auf der Tafel vermerken. Nachhalten, wer bereits berichtet hat und wer nicht. Wenn eine geplante Rückmeldung ausbleibt, proaktiv einmal nachfragen. Wiederholtes Ausbleiben ist selbst ein Befund für die nächste Lagefeststellung. **Zwischen den Rückmeldungen:** Den aktuellen Tafelstand prüfen. Muster erkennen: Sind mehrere Ziele durch dieselbe Ursache blockiert? Sind Fristen angesichts der Meldungen realistisch? Gibt es Abhängigkeiten zwischen Zielen, die in der Planung nicht sichtbar waren? Beobachtungen für das Debriefing notieren. Mental den nächsten Planungszyklus vorbereiten: Welche Probleme dürften entstehen? Welche Strategien von Tafel 2, die nicht ausgewählt wurden, könnten relevant werden? **Fünf Minuten vor dem nächsten Lagevortrag:** Die Vorbereitung Lagevortrag einleiten. Ab diesem Punkt werden keine neuen Informationen mehr angenommen. Tafel 3 abschließen. Das zweite Foto des Zyklus anfertigen. Bestätigen, dass der Owner für den Vortrag bereit ist. Das Team wieder zusammenführen. Der Facilitator löst während der Umsetzungsphase keine Probleme. Er koordiniert die Ausführung nicht. Er pflegt die Tafeln, nimmt Informationen entgegen, wahrt Nachvollziehbarkeit und bereitet den nächsten Zyklus vor. Die Disziplin, im Krisenstabsraum oder Notfallraum zu bleiben und dem Impuls zu widerstehen, operativ einzugreifen, ist einer der schwierigsten und zugleich wichtigsten Aspekte der Rolle. ### Schritt 2: Auftragsübermittlung #### Zweck des Schritts Der Zweck der Auftragsübermittlung besteht darin, definierte Ziele in ausführbare Anweisungen zu übersetzen und sie formell den verantwortlichen Ressourcen zuzuweisen. Dieser Schritt stellt sicher, dass Ziele nicht abstrakt bleiben, sondern innerhalb der jeweiligen Verantwortungsbereiche in klar verstandene und handlungsfähige Aufträge überführt werden. Er schafft Klarheit an der Schnittstelle zwischen Koordinationsteam und ausführenden Einheiten. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts sind alle Ziele in **klar definierte Aufträge** übersetzt, die den verantwortlichen Ressourcen formell übermittelt wurden. Jeder Auftrag muss strukturiert und eindeutig dokumentiert sein. Eine vollständige Auftragsbeschreibung enthält: - **Ziel** – Was soll erreicht werden? - **Verantwortlichkeit** – Wer ist für die Ausführung verantwortlich? - **Ressourcen** – Welche Mittel stehen für die Ausführung zur Verfügung? - **Frist** – Bis wann muss das Ziel erreicht werden, und wann werden Rückmeldungen erwartet? - **Kommunikation** – Wie und wann wird Fortschritt berichtet? Aufträge werden typischerweise schriftlich übermittelt, um Nachvollziehbarkeit und Konsistenz sicherzustellen. Mündliche Kommunikation kann ergänzen, ersetzt die schriftliche Übermittlung aber nicht. Das Ergebnis ist ein Satz klar zugewiesener und verstandener Aufträge, der dezentrale Umsetzung ohne dauernde Nachsteuerung ermöglicht. #### Typische Missverständnisse und frühe Abweichungen **Unklare oder unvollständige Auftragsbeschreibungen** Aufträge, denen Klarheit über Ergebnis, Verantwortlichkeit oder Fristen fehlt, führen zu Verzögerungen, Missverständnissen und Nacharbeit. Jeder Auftrag muss in sich verständlich sein. **Mehrere verantwortliche Personen zuweisen** Geteilte Verantwortung schafft Unklarheit und schwächt Rechenschaft. Jeder Auftrag muss genau einen verantwortlichen Eigentümer haben. **Auf Tätigkeiten statt Ergebnisse fokussieren** Aufträge werden oft als Aktionen formuliert statt als Ergebnisse. Das entkoppelt die Umsetzung vom ursprünglichen Ziel und erschwert die Bewertung. **Kommunikationserwartungen fehlen** Wenn Berichtsintervalle und Kanäle nicht definiert sind, werden Rückmeldungen inkonsistent oder verspätet. Das mindert die Steuerungsfähigkeit. **Aufträge überladen** Mehrere Ziele in einem einzigen Auftrag zu bündeln, verringert die Klarheit und erschwert die Fortschrittsnachverfolgung. Aufträge sollten fokussiert bleiben. **Rein mündliche Auftragsvergabe** Sich ausschließlich auf mündliche Anweisungen zu verlassen, führt zu Informationsverlust und mangelnder Nachvollziehbarkeit. Schriftliche Übermittlung ist erforderlich. **Implizites Verständnis unterstellen** Teams nehmen häufig an, Empfänger würden Aufträge wie beabsichtigt interpretieren. Ohne explizite Formulierung entstehen unterschiedliche Verständnisse und damit inkonsistente Umsetzung. **Aufträge neu zuweisen, ohne die Tafel zu aktualisieren** Änderungen in Verantwortlichkeit oder Umfang werden bisweilen informell kommuniziert, aber nicht auf Tafel 3 abgebildet. Das erzeugt Widersprüche zwischen Planung und Umsetzung. #### Aktivitäten des Facilitators in diesem Schritt - Jede Auftragsbeschreibung vor der Übermittlung auf Vollständigkeit prüfen. - Sicherstellen, dass jedem Auftrag auf Tafel 3 genau eine rechenschaftspflichtige Person zugewiesen ist. - Prüfen, dass Aufträge Ergebnisse und nicht Tätigkeiten beschreiben. - Bestätigen, dass jeder Auftrag schriftlich übermittelt wurde. - Tafel 3 so aktualisieren, dass alle zugewiesenen Aufträge als „offen“ mit verantwortlicher Person sichtbar sind. ### Schritt 3: Auftragsbearbeitung #### Zweck des Schritts Der Zweck der Auftragsbearbeitung ist die Umsetzung der zugewiesenen Ziele durch die verantwortlichen Ressourcen innerhalb ihrer jeweiligen Verantwortungsbereiche. Nach der Auftragsübermittlung verlagert sich die Ausführung außerhalb des koordinierenden Teams. Die zugewiesenen Ressourcen – interne Mitarbeitende, externe Dienstleister oder andere benannte Stellen – arbeiten selbstständig an ihren Zielen innerhalb des Rahmens, der in der Planungsphase gesetzt wurde. Während dieses Schritts sollten sich die Teammitglieder physisch oder logisch trennen, um ohne gegenseitige Störung an ihren jeweiligen Aufträgen zu arbeiten. Ein direkter Austausch zwischen Teammitgliedern ist während der Ausführung im Regelfall nicht erforderlich. Die Planungsphase hat klar definierte Ziele hervorgebracht, und jede verantwortliche Person verfolgt diese eigenständig. Der Facilitator bleibt im Krisenstabsraum oder Notfallraum, um die Tafeln zu pflegen, Statusmeldungen entgegenzunehmen und Nachvollziehbarkeit zu sichern. Diese Trennung ist bewusst gewählt. Wenn alle Teammitglieder während der Umsetzung im selben Raum bleiben, nehmen Ablenkung, unstrukturierte Diskussion und die Versuchung zu, außerhalb der Methode neu zu planen. Unter Stress erhöhen gleichzeitige Telefonate und Seitengespräche den Lärmpegel und untergraben Konzentration. Das koordinierende Team steuert die Ausführung nicht im Detail. Es hält Lagebewusstsein aufrecht, nimmt strukturierte Rückmeldungen entgegen und bereitet den nächsten Planungszyklus vor. #### Beabsichtigtes Ergebnis Am Ende des Umsetzungsintervalls: - wurde an allen zugewiesenen Zielen in den jeweiligen Verantwortungsbereichen aktiv gearbeitet, - berichten Ressourcen in vereinbarten Intervallen und über definierte Kanäle an die zuständigen Teammitglieder, - stellen die Teammitglieder sicher, dass Statusmeldungen – einschließlich Verzögerungen oder Hindernissen – rechtzeitig kommuniziert werden, - werden neue Entwicklungen nicht ad hoc bearbeitet, sondern für die nächste Iteration notiert, sofern keine sofortige Stabilisierung erforderlich ist. #### Typische Missverständnisse und frühe Abweichungen **Auf jedes eingehende Update sofort reagieren** Unter Druck reagieren Teams dazu, auf jede neue Information unmittelbar zu antworten. Das unterbricht den disziplinierten Zyklus aus Planen, Umsetzen und Überprüfen und führt zu fragmentiertem Handeln. Neue Information liegt per Definition bereits in der Vergangenheit. Strukturierte Iteration, nicht permanente Reaktion, erhält die Koordinationsqualität. **Teammitglieder bleiben im selben Raum** Alle Teammitglieder während der Umsetzung in einem Raum zu halten, führt zu informellen Diskussionen, gegenseitiger Ablenkung und spontaner Neuplanung außerhalb des definierten Prozesses. Physische oder logische Trennung schützt Fokus und Methodendisziplin. **Umfang über die zugewiesenen Ziele hinaus erweitern** Ressourcen dehnen mitunter den Umfang ihrer Arbeit aus, ohne zurückzumelden. Das erzeugt Koordinationslücken und kann mit parallelen Aktivitäten oder anderen Zielen kollidieren. Jede wesentliche Abweichung muss kommuniziert werden. **Hindernisse bis zum nächsten Planungszyklus zurückhalten** Während Routine-Statusmeldungen festen Intervallen folgen, müssen Hindernisse und kritische Entwicklungen dem Facilitator ohne Verzögerung gemeldet werden. Der Facilitator bewegt die entsprechende Karte auf Tafel 3 nach „blockiert“. **Informelle Koordination unter Umgehung der Teamstruktur** Direkte Abstimmung zwischen Ressourcen außerhalb der definierten Struktur führt zu Fragmentierung. Die in der Planung festgelegten Kommunikationswege müssen auch in der Umsetzung gelten. #### Aktivitäten des Facilitators in diesem Schritt - Im Krisenstabsraum oder Notfallraum bleiben. Der Facilitator beteiligt sich nicht an der Ausführung. - Eingehende Statusmeldungen beobachten und Tafel 3 entsprechend aktualisieren. - Berichtsintervalle nachhalten. Wenn eine geplante Rückmeldung ausbleibt, proaktiv einen Status anfordern. - Bei gemeldeten Hindernissen die entsprechende Karte auf Tafel 3 sofort nach „blockiert“ verschieben und den Grund notieren. - Keine neue Koordination einleiten und den Auftragsumfang nicht verändern. - Das Umsetzungsintervall nutzen, um den nächsten Planungszyklus vorzubereiten. ### Schritt 4: Auftragsnachverfolgung #### Zweck des Schritts Der Zweck der Auftragsnachverfolgung besteht darin, den Fortschritt zugewiesener Ziele während des Umsetzungsintervalls fortlaufend zu überwachen. Jedes Teammitglied verfolgt den Fortschritt der Ziele, die ihm zugewiesen sind. Die verantwortlichen Ressourcen liefern regelmäßige Statusmeldungen, die dokumentiert werden. Diese Meldungen schaffen einen klaren Überblick über den Bearbeitungsstand und helfen, Transparenz und Nachvollziehbarkeit zu erhalten. Die Auftragsnachverfolgung ist keine eigene Besprechung und kein Einzelereignis. Sie ist eine laufende Tätigkeit während der Umsetzungsphase. Sie stellt sicher, dass das koordinierende Team Lagebewusstsein behält und entstehende Probleme erkennt, bevor sie eskalieren. #### Beabsichtigtes Ergebnis Am Ende des Umsetzungsintervalls: - hat jedes Teammitglied einen aktuellen Überblick über den Status seiner zugewiesenen Ziele, - sind Statusinformationen kommuniziert und dokumentiert, - hat der Facilitator genügend Informationen erhalten, um Tafel 3 korrekt zu halten, - sind entstehende Hindernisse oder Abweichungen erkannt und markiert. Je nach Komplexität kann es notwendig sein, zusätzliche Nachverfolgungsmechanismen zu führen, etwa nachgeordnete Kanban-Boards. Diese dürfen jedoch nicht mit Tafel 3 verwechselt oder vermischt werden, die das maßgebliche Nachverfolgungsinstrument des koordinierenden Teams bleibt. #### Typische Missverständnisse und frühe Abweichungen **Auftragsnachverfolgung mit aktiver Steuerung der Ausführung verwechseln** Das koordinierende Team beobachtet und verfolgt nach – es mikrosteuert nicht. Die ausführenden Ressourcen sind für ihre Arbeit selbst verantwortlich. Nachverfolgung sorgt für Sichtbarkeit, nicht für operative Kontrolle. **Bis zum nächsten Lagevortrag warten, um Hindernisse zu melden** Kritische Statusänderungen, insbesondere blockierte Ziele oder erhebliche Umfangsabweichungen, müssen dem Facilitator sofort gemeldet werden. Verzögerte Meldung mindert die Reaktionsfähigkeit. **Statusmeldungen nicht dokumentieren** Mündliche Statusmeldungen, die nicht festgehalten werden, verringern die Nachvollziehbarkeit und schaffen Informationslücken bei Schichtwechseln oder in der Vorbereitung des nächsten Zyklus. **Zu viel berichten und Rauschen erzeugen** Häufige, unstrukturierte Statusmeldungen überlasten den Facilitator und verdecken relevante Entwicklungen. Berichte müssen den festgelegten Intervallen folgen, sofern keine kritische Änderung eintritt. #### Aktivitäten des Facilitators in diesem Schritt - Eingehende Statusmeldungen verdichten und sicherstellen, dass sie auf Tafel 3 abgebildet sind. - Zwischen routinemäßigen Fortschrittsmeldungen und eskalationswürdigen Hindernissen unterscheiden. - Bei mündlichen Meldungen sicherstellen, dass dokumentiert wird. - Im Blick behalten, für welche Ziele noch kein Status gemeldet wurde. - Fortschritte nicht über das Berichtete hinaus interpretieren oder bewerten. Der Facilitator verfolgt Status, der Owner bewertet Ergebnisse. ### Schritt 5: Fortschreibung der Lage #### Zweck des Schritts Der Zweck der Fortschreibung der Lage besteht darin, Tafel 3 während der gesamten Umsetzungsphase aktuell zu halten, indem alle Statusänderungen unmittelbar abgebildet werden. Tafel 3 ist das maßgebliche Instrument zur Nachverfolgung der Umsetzung. Sie muss jederzeit den aktuellen Stand aller Ziele korrekt wiedergeben. Die Fortschreibung der Lage ist kein termingebundenes Ereignis, sondern eine laufende, auslösungsbezogene Aktivität: Immer wenn sich der Status eines Ziels ändert, wird Tafel 3 entsprechend aktualisiert. Statusänderungen, die eine Aktualisierung auslösen, sind etwa: - ein Ziel wechselt von „offen“ zu „in Bearbeitung“, - ein Ziel wechselt von „in Bearbeitung“ zu „abgeschlossen“, - ein Ziel wechselt von „in Bearbeitung“ zu „blockiert“, - oder jeder andere Übergang, der den Umsetzungsstatus verändert. Karten auf Tafel 3 dürfen ausschließlich vom Facilitator bewegt werden. So bleibt die Information konsistent und verlässlich. #### Beabsichtigtes Ergebnis Zu jedem Zeitpunkt während der Umsetzung: - bildet Tafel 3 den aktuellen Status aller Ziele korrekt ab, - hat der Facilitator alle gemeldeten Änderungen eingearbeitet, - kann jedes neu hinzukommende Teammitglied Tafel 3 lesen und den Umsetzungsstand ohne zusätzliche Einweisung verstehen, - sind blockierte Ziele sichtbar markiert und für die nächste Iteration vorbereitet. Die Fortschreibung der Lage dient außerdem als Grundlage für die Vorbereitung Lagevortrag. Wenn der Facilitator den nächsten Zyklus vorbereitet, muss Tafel 3 bereits aktuell sein. #### Typische Missverständnisse und frühe Abweichungen **Die Tafel als periodische Dokumentationsaufgabe behandeln** Tafel 3 wird nicht in festen Abständen aktualisiert. Sie wird bei jeder Statusänderung aktualisiert. Eine periodische Pflege verringert ihren Wert als Echtzeit-Koordinationsinstrument. **Mehrere Personen aktualisieren die Tafel** Wenn andere Teammitglieder als der Facilitator Karten bewegen, entstehen Inkonsistenzen und konkurrierende Versionen des Umsetzungsstands. Der Facilitator ist die einzige Autorität für Tafel 3. **Blockierte Ziele nicht sichtbar markieren** Blockierte Ziele, die auf Tafel 3 nicht klar gekennzeichnet sind, werden im nächsten Planungszyklus nicht adressiert. Hindernisse müssen visuell eindeutig sein. **Die Tafel bei Aktualisierungen überfrachten** Zu viele Details, Anmerkungen oder Statuskategorien verringern die Lesbarkeit unter Druck. Die Tafel muss einfach, strukturiert und schnell lesbar bleiben. #### Aktivitäten des Facilitators in diesem Schritt - Karten auf Tafel 3 sofort bewegen, wenn eine Statusänderung gemeldet wird. - Sicherstellen, dass blockierte Ziele visuell eindeutig markiert sind. - Versuche zurückweisen, dass Teammitglieder Karten selbst bewegen. - Die Tafel lesbar halten: Ziel, verantwortliche Person und aktueller Status genügen. - Tafel 3 als Echtzeitinstrument pflegen. Jede Verzögerung verschlechtert die Koordinationsqualität. ### Schritt 6: Vorbereitung Lagevortrag #### Zweck des Schritts Der Zweck der Vorbereitung Lagevortrag besteht darin, sicherzustellen, dass zum Zeitpunkt des nächsten Lagevortrags alle relevanten Informationen strukturiert und vorbereitet vorliegen. Dieser Schritt markiert den Übergang von der Umsetzungsphase zurück in die Planungsphase. Die Vorbereitung beginnt zu einem definierten Zeitpunkt vor dem terminierten Lagevortrag, typischerweise fünf Minuten vorher. In diesem Fenster schließt der Facilitator Tafel 3 ab, indem letzte Statusänderungen eingearbeitet werden. In diesem Schritt werden keine neuen Informationen eingeführt. Es werden keine neuen E-Mails gelesen und keine neuen Anrufe angenommen. So bleibt die erfasste Datenlage konsistent und bildet eine stabile Grundlage für den nächsten Vortrag. Sobald die letzte Aktualisierung von Tafel 3 abgeschlossen ist, erstellt der Facilitator eine fotografische oder digitale Sicherung des Tafelstands. Gleichzeitig bereitet der Owner den Lagevortrag vor. Alle Teammitglieder nutzen diese Zeit, um Probleme zu sammeln, die sie während der Umsetzung beobachtet haben und in die nächste Lagefeststellung einbringen wollen. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts: - ist Tafel 3 abgeschlossen und dokumentiert, - ist der Owner auf den Lagevortrag vorbereitet, - haben alle Teammitglieder Beobachtungen und Probleme für die nächste Lagefeststellung gesammelt, - ist das Team wieder zusammengeführt und bereit für die nächste Planungsphase. Zur Vorbereitung Lagevortrag gehört außerdem eine kritische Prüfung durch den Owner, ob der Notfall oder die Krise noch andauert. Der Owner bewertet die aktuelle Lage und entscheidet, ob die Aktivierungskriterien weiterhin erfüllt sind. Ein Notfall oder eine Krise kann für beendet erklärt werden, wenn: - die betroffenen Prozesse, Systeme oder Services stabilisiert wurden, - die ursprünglichen Aktivierungskriterien nicht mehr erfüllt sind, - kein akuter Bedarf an weiteren koordinierten Maßnahmen besteht, - der Regelbetrieb ohne wesentliche Beeinträchtigung wieder aufgenommen werden kann. Bevor der Owner das Ende einer Aktivierung erklärt, besitzt der Facilitator ein ausdrückliches Veto-Recht. Dieses Veto ermöglicht es ihm, die Entscheidung anzufechten und eine erneute Bewertung zu verlangen, wenn die Voraussetzungen für die Beendigung noch nicht vollständig erfüllt sind. Das Veto wird dokumentiert. Wird die Aktivierung für beendet erklärt, erfolgt die Bekanntgabe im Lagevortrag, und der Prozess wechselt in die Lernphase. Alle offenen Ziele und verbleibenden Probleme müssen ausdrücklich an die Linienorganisation übergeben werden. Wird die Aktivierung fortgesetzt, beginnt mit dem Lagevortrag eine neue Planungsphase. In der anschließenden Lagefeststellung werden Probleme aus der vorherigen Iteration zunächst auf ihre weitere Relevanz geprüft, bevor neues Brainstorming beginnt. Bestehende Probleme, die weiterhin aktuell sind, benötigen neue Karten, um eine erneute Bewertung und Priorisierung ohne Ankereffekt zu ermöglichen. #### Typische Missverständnisse und frühe Abweichungen **Das Vorbereitungsfenster überspringen** Direkt von der Umsetzung in den Lagevortrag zu springen, ohne definierte Vorbereitung, führt zu unvollständigen Tafelständen, unvorbereiteten Vorträgen und fehlenden Problembeobachtungen. Das Fünf-Minuten-Fenster ist nicht optional. **Während der Vorbereitung neue Informationen zulassen** Neue Anrufe anzunehmen oder neue Nachrichten zu lesen, untergräbt die Konsistenz des dokumentierten Tafelstands. Das Vorbereitungsfenster ist ein kontrollierter Schnitt für eine stabile Ausgangsbasis des nächsten Zyklus. **Nicht prüfen, ob die Aktivierung fortgesetzt werden muss** Teams gehen mitunter in den nächsten Planungszyklus, ohne ausdrücklich zu prüfen, ob der Notfall oder die Krise die Aktivierungskriterien noch erfüllt. Das führt zu unnötigen Iterationen oder umgekehrt zu verfrühter Deaktivierung ohne formale Bewertung. **Während der Umsetzung keine Probleme sammeln** Wenn Teammitglieder in die nächste Lagefeststellung kommen, ohne während der Umsetzung Beobachtungen und Probleme notiert zu haben, sinkt die Qualität des Brainstormings. **Problemkarten aus der vorigen Iteration wiederverwenden** Alte Problemkarten ohne Neuerstellung weiterzuverwenden, erzeugt Ankereffekte. Probleme, die relevant bleiben, müssen auf frischen Karten neu erfasst und erneut bewertet werden. #### Aktivitäten des Facilitators in diesem Schritt - Fünf Minuten vor dem terminierten Lagevortrag das Vorbereitungsfenster einleiten. - Tafel 3 abschließen und danach eine fotografische oder digitale Sicherung des Tafelstands erstellen. - Bestätigen, dass der Owner für den Lagevortrag bereit ist. - Sicherstellen, dass alle Teammitglieder zurückkehren und ihre Beobachtungen sowie Probleme für die nächste Lagefeststellung gesammelt haben. > **Veto-Situation – verfrühte Deaktivierung:** Bevor der Owner das Ende einer Aktivierung erklärt, prüft der Facilitator ausdrücklich, ob die Voraussetzungen für die Beendigung erfüllt sind. Wenn er feststellt, dass die Lage nicht ausreichend stabilisiert ist, Aktivierungskriterien weiterhin gelten oder offene Ziele nicht angemessen übergeben wurden, übt er das Veto-Recht aus. Das Veto wird dokumentiert. Die Aktivierung wird mit der nächsten Planungsphase fortgesetzt. ## Lernphase Die Lernphase ist der strukturierte Abschluss jeder P-DRIVEN-Aktivierung. Sie dient zwei unterschiedlichen Zwecken: der unmittelbaren Sammlung von Rückmeldungen nach der Deaktivierung und der späteren strukturierten Analyse zur Ableitung organisatorischer Verbesserungen. Die Lernphase ist nicht optional. Sie ist integraler Bestandteil des Problemlösungs-P. Wird sie ausgelassen, entfällt der Mechanismus, durch den die Organisation die Erfahrungen der Aktivierung sichert und anwendet. Die Lernphase wird ausgelöst, wenn der Owner im Lagevortrag das Ende des Notfalls oder der Krise erklärt. Das Team bleibt versammelt und beginnt sofort mit dem ersten Schritt. ### Schritt 1: Debriefing #### Zweck des Schritts Das Debriefing dient der unmittelbaren Sammlung von Beobachtungen, Eindrücken und ersten Erkenntnissen direkt nach Abschluss der Aktivierung. Es findet statt, solange das Team noch versammelt ist – bevor die Beteiligten den Krisenstabsraum oder Notfallraum verlassen. Zweck ist es, das Frische festzuhalten: unmittelbare Reaktionen, Beobachtungen dazu, was funktioniert hat und was nicht, sowie erste Ideen für Verbesserungen. Das Debriefing ist keine Analyse. Es ist eine strukturierte Sammlung roher Rückmeldung in dem Moment, in dem Erinnerung am stärksten ist. Das Debriefing wird vom Facilitator moderiert. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts: - haben alle Mitglieder des Kernteams ihre unmittelbaren Beobachtungen eingebracht, - sind zentrale Eindrücke dazu dokumentiert, was gut funktioniert hat und was nicht, - wurden erste Verbesserungsvorschläge ohne vertiefte Analyse gesammelt, - liegt das dokumentierte Ergebnis als Eingang für das nachfolgende strukturierte Feedback vor. Das Debriefing bleibt kurz und fokussiert. Es sollte 15 bis 30 Minuten nicht überschreiten. Die Leitfragen lauten: - Was hat während der Aktivierung gut funktioniert? - Was hat nicht gut funktioniert oder Schwierigkeiten verursacht? - Was sollte beim nächsten Mal anders gemacht werden? - Gab es Situationen, in denen die Methode nicht eingehalten wurde? Was war die Folge? Die Dokumentation wird vom Facilitator schriftlich erfasst. Sie muss nicht ausführlich sein – strukturierte Notizen genügen. #### Typische Missverständnisse und frühe Abweichungen **Das Debriefing wegen Erschöpfung auslassen** Nach langen Aktivierungen sind Teams häufig erschöpft und möchten den Raum schnell verlassen. Genau dann drohen die wertvollsten Beobachtungen verloren zu gehen. Das Debriefing muss unmittelbar stattfinden, solange die Erfahrung noch präsent ist. **Das Debriefing als Schuldzuweisung durchführen** Wenn Beteiligte das Debriefing als Bewertung persönlicher Leistung erleben, werden sie sich nicht offen einbringen. Der Facilitator muss ausdrücklich klarstellen, dass es um strukturelle und methodische Nachbesprechung geht und nicht um persönliche Bewertung. **Das Debriefing in eine Vollanalyse verwandeln** Das Debriefing sammelt Beobachtungen; es analysiert sie nicht. Ausgedehnte Diskussion, Root-Cause-Analyse oder detaillierte Verbesserungsplanung gehören in das strukturierte Feedback. **Ergebnisse nicht dokumentieren** Mündliche Rückmeldungen, die nicht schriftlich festgehalten werden, haben keinen bleibenden Wert. Der Facilitator muss die Erkenntnisse schriftlich erfassen. #### Aktivitäten des Facilitators in diesem Schritt - Die Debriefing-Sitzung moderieren und den Rahmen ausdrücklich setzen. - Das Team nacheinander durch die vier Leitfragen führen und sicherstellen, dass jede Person einen Beitrag leistet. - Alle Beobachtungen schriftlich festhalten. Strukturierte Notizen genügen. - Die Zeit steuern und Diskussionen umlenken, wenn sie in vertiefte Analyse übergehen. - Sicherstellen, dass das dokumentierte Ergebnis erhalten bleibt und für das nachfolgende strukturierte Feedback verfügbar ist. ### Schritt 2: Strukturiertes Feedback #### Zweck des Schritts Das strukturierte Feedback ist die systematische, detaillierte Auswertung der Aktivierung nach dem unmittelbaren Debriefing – typischerweise innerhalb weniger Tage, nicht Wochen. Sein Zweck ist die systematische Analyse der Aktivierung, die Ableitung konkreter Lehren und die Definition konkreter Verbesserungsmaßnahmen. Anders als das Debriefing, das unmittelbare Eindrücke sammelt, ist das strukturierte Feedback eine moderierte, gründliche Überprüfung der gesamten Aktivierung. Es betrachtet jede Phase des Problemlösungs-P, die Wirksamkeit der Rollen und Teamstrukturen, die Qualität der Entscheidungen sowie die Richtigkeit der zugrunde liegenden Annahmen. Das strukturierte Feedback wird durch den Facilitator oder, wo verfügbar, durch einen qualifizierten externen Moderator moderiert. #### Beabsichtigtes Ergebnis Am Ende dieses Schritts hat das Team eine dokumentierte Auswertung erstellt, die Folgendes umfasst: - **Rückblick auf die Aktivierungsphasen:** Das Team geht die Aktivierung von der Initiierung bis zur Umsetzung durch und prüft jede Phase auf Methodentreue, Ausführungsqualität und beobachtete Abweichungen. - **Qualität der Entscheidungen:** Welche zentralen Entscheidungen wurden getroffen, auf welcher Grundlage und mit welchem Ergebnis? Welche Annahmen wurden bestätigt, welche erwiesen sich als falsch? - **Prozesstreue:** Wo wurde dem Problemlösungs-P diszipliniert gefolgt? Wo traten Abweichungen auf, und welche Wirkung hatten sie? - **Team und Rollen:** Wie hat die Führungsstruktur funktioniert? Waren Owner und Facilitator wirksam? Waren Domänenperspektiven ausreichend vertreten? - **Werkzeuge und Infrastruktur:** Haben Tafeln, Alarmierungssysteme, Kommunikationskanäle und Dokumentationsprozesse wie beabsichtigt funktioniert? - **Vorbereitung:** Welche Faktoren der organisatorischen Bereitschaft haben die Reaktion unterstützt oder begrenzt? - **Konkrete Verbesserungsmaßnahmen:** Welche spezifischen Maßnahmen, strukturellen Änderungen, Verfahrensanpassungen oder Trainingsanforderungen ergeben sich aus dieser Aktivierung? Verbesserungsmaßnahmen müssen als konkrete, handlungsfähige Punkte formuliert sein, nicht als vage Beobachtungen. Jede Maßnahme sollte benennen, was sich ändern muss, wer verantwortlich ist und bis wann dies umzusetzen ist. Das Ergebnis des strukturierten Feedbacks wird dokumentiert und an die Organisationsleitung sowie die für die Pflege des Notfall- und Krisenmanagementsystems verantwortliche Person kommuniziert. Erkenntnisse, die organisatorische Reaktion erfordern, müssen nachverfolgt werden und dürfen nicht im Archiv verschwinden. #### Typische Missverständnisse und frühe Abweichungen **Das strukturierte Feedback auf unbestimmte Zeit verschieben** Die Auswertung auf „später“ zu terminieren, bedeutet häufig, dass sie nie stattfindet. Das strukturierte Feedback sollte innerhalb weniger Tage nach der Deaktivierung erfolgen – nah genug für genaue Erinnerung, aber mit ausreichend Abstand für Reflexion. **Die Teilnahme auf Führungsrollen beschränken** Wer operative Beteiligte ausschließt, verliert die detailliertesten Beobachtungen. Diejenigen, die Ziele umgesetzt haben, haben oft den klarsten Blick darauf, wo der Prozess funktioniert hat und wo nicht. **Einen Bericht statt Lernen zu produzieren** Ein schriftlicher Bericht, der archiviert wird, ohne konkrete Maßnahmen auszulösen, hat keinen organisatorischen Wert. Das strukturierte Feedback muss zu nachverfolgten Verbesserungsmaßnahmen führen. **Die Auswertung ohne Struktur durchführen** Eine unstrukturierte Diskussion über „das, was passiert ist“ erzeugt keine vollständige Abdeckung und fokussiert meist auf dramatische Ereignisse statt auf systematische Muster. Die Auswertung sollte den Phasen des Problemlösungs-P folgen. **Nur Fehler erneut betrachten** Wer nur untersucht, was schiefgelaufen ist, verpasst die Chance, wirksame Praktiken zu erkennen und zu stärken. Das strukturierte Feedback muss Stärken und Schwächen behandeln. **Verbesserungsmaßnahmen nicht nachverfolgen** Empfehlungen ohne Verantwortlichkeit, Fristen und Nachverfolgung verändern nichts. Das strukturierte Feedback ist nur so wertvoll wie die Umsetzung seiner Erkenntnisse. #### Aktivitäten des Facilitators in diesem Schritt - Die Sitzung zum strukturierten Feedback moderieren oder ko-moderieren. - Die Auswertung entlang der Phasen des Problemlösungs-P strukturieren, um systematische Abdeckung sicherzustellen. - Sicherstellen, dass sowohl Stärken als auch Schwächen behandelt werden. - Vage Verbesserungsvorschläge hinterfragen. - Sicherstellen, dass das dokumentierte Ergebnis einschließlich konkreter Verbesserungsmaßnahmen an Organisationsleitung und Systemverantwortlichen kommuniziert wird. - Prüfen, dass Verbesserungsmaßnahmen verantwortlichen Personen zugewiesen und in ein Nachverfolgungsinstrument eingetragen werden. --- # Teil III — Anwendung des P: Notfälle und Krisen Teil II hat das Problemlösungs-P als Schrittfolge beschrieben. Dieser Teil behandelt, wie derselbe Prozess auf unterschiedliche Aktivierungsgrößen angewendet wird – vom Notfall in einer einzelnen Domäne bis zur Krise über mehrere Standorte – und was sich mit wachsendem Umfang und steigender Komplexität verändert und was gerade nicht. Die zentrale Aussage dieses Teils lautet: **P-DRIVEN skaliert durch Verschachtelung, nicht durch Modifikation.** Die Schrittfolge, Rollenstruktur und Methodendisziplin bleiben auf jeder Ebene identisch. Was sich verändert, sind Planungstiefe, Zahl der parallel laufenden Problemlösungs-P-Zyklen und der Koordinationsaufwand zwischen ihnen. ## Anwendung von P-DRIVEN auf Notfälle Ein Notfall ist eine Lage, die die Ziele einer einzelnen organisatorischen Einheit gefährdet, aber mit den Ressourcen, Prozessen und Befugnissen dieser Einheit bewältigt werden kann. Es ist keine organisationsweite Koordination oder Sonderbefugnis erforderlich. ### Teamstruktur Die reagierende Struktur ist ein einzelnes **Incident Management Team (IMT)**, im Kontext einer konkreten Domäne auch als **Domain Response Team (DRT)** bezeichnet. Die Mindestbesetzung ist: - **Incident Owner**: trifft Entscheidungen, hält den Lagevortrag, trägt Verantwortung für Ergebnisse. - **Incident Facilitator**: moderiert das Problemlösungs-P, pflegt die Tafeln, erzwingt Methodendisziplin und hält die Veto-Rechte. Je nach Lage kann der Owner **Supporter** hinzuziehen – Personen mit spezifischer Domänenexpertise, die während der Umsetzungsphase Verantwortung für definierte Ziele übernehmen. Supporter sind keine permanenten Teammitglieder, sondern werden bei Bedarf aktiviert und wieder entlassen. ### Wie das Problemlösungs-P läuft Das vollständige Problemlösungs-P läuft genau wie in Teil II beschrieben. Kein Schritt wird verkürzt, ausgelassen oder zusammengelegt. Der Unterschied zur Krise liegt in: - **Planungshorizont:** Stunden bis Tage statt Tage bis Wochen. - **Iterationsgeschwindigkeit:** Zyklen sind kurz. Eine vollständige Iteration dauert typischerweise zwei bis vier Stunden. - **Tafelkomplexität:** weniger Probleme, weniger Ziele, weniger Ressourcen. Die Tafeln sind schlanker, ihre Struktur bleibt identisch. - **Teamgröße:** typischerweise zwei bis vier Personen. Der Koordinationsaufwand ist gering. ### Aktivierung und Deaktivierung Die Aktivierung eines IMT folgt der Erstbewertung. Der Owner entscheidet anhand vordefinierter Kriterien, ob die Lage im Geltungsbereich des Teams einen Notfall darstellt. Wenn ja, wird das IMT formell aktiviert und der erste Lagevortrag vorbereitet. Die Deaktivierung folgt derselben Logik wie in Teil II unter „Vorbereitung Lagevortrag“: Der Owner prüft, ob die Aktivierungskriterien noch erfüllt sind. Wenn die Lage stabilisiert ist, die ursprünglichen Kriterien nicht mehr gelten und keine weiteren koordinierten Maßnahmen erforderlich sind, erklärt der Owner den Notfall für beendet. Der Facilitator hält darauf das Veto-Recht. Danach folgt unmittelbar die Lernphase. ### Eskalation Wenn die Lage die Leistungsfähigkeit des IMT überschreitet – weil mehrere Domänen betroffen sind, verfügbare Ressourcen überfordert sind oder Befugnisse außerhalb des Teamrahmens benötigt werden –, eskaliert sie auf Krisenniveau. Die Eskalation folgt einer definierten Übergabesequenz: 1. Der Facilitator des aktiven IMT wird zum Crisis Facilitator im neu aktivierten CMT. Vor dem Wechsel übergibt er an den eingehenden IMT-Facilitator den aktuellen Stand aller drei Tafeln, den Iterationstakt, die gesamte Dokumentation und offene Punkte. Der eingehende Facilitator bestätigt seine Bereitschaft. 2. Der Owner des aktiven IMT löst die Alarmierung für einen Ersatz-Facilitator im IMT aus. Das IMT pausiert seine aktuelle Iteration bei Bedarf, bis der neue Facilitator verfügbar ist. Ein IMT ohne Facilitator darf das Problemlösungs-P nicht fortführen. 3. Wenn zum Zeitpunkt der Krisenerklärung kein IMT aktiv war, wird die Rolle des Crisis Facilitator durch die erste qualifizierte Person besetzt, die über das Alarmierungssystem erreicht wird. Der Übergang von Notfall zu Krise ist kein Bruch des Prozesses. Er ist eine Erweiterung der Koordinationsstruktur, während das Problemlösungs-P weiterläuft. ## Anwendung von P-DRIVEN auf Krisen Eine Krise liegt vor, wenn die Lage die Organisation als Ganzes gefährdet oder wenn eine einzelne organisatorische Einheit über ihre eigene Reaktionsfähigkeit hinaus überlastet ist. Mehrere Probleme ohne Standardlösung bestehen gleichzeitig. Die Organisation kann ihre volle operative Leistungsfähigkeit nicht aufrechterhalten. ### Teamstruktur Die reagierende Struktur besteht aus zwei Ebenen: - einem **Crisis Management Team (CMT)** zur domänenübergreifenden Koordination, - einem oder mehreren **Domain Response Teams (DRT)** zur Umsetzung innerhalb ihrer jeweiligen Domänen. Das CMT ist als doppelte Führungsstruktur organisiert: - **Crisis Owner**: Gesamtentscheidungsinstanz und Schnittstelle zur Organisationsleitung. - **Crisis Facilitator**: methodische Autorität, Prozessmoderation und Veto-Rechte. Ergänzt wird das CMT durch **Domain Owner** – je einen pro Domäne. Jeder Domain Owner ist **dieselbe Person**, die zugleich als Owner des entsprechenden DRT fungiert. Diese Personenidentität ist ein strukturelles Prinzip, nicht nur eine Erleichterung. Sie beseitigt eine Kommunikationsschnittstelle, die sonst ausdrücklich gesteuert werden müsste. Das CMT kann zeitweise **Berater** für spezifische Expertise enthalten. Diese verbessern Lagebewertung und Entscheidungsqualität, nehmen aber keine ständigen Rollen ein. ![*CMT mit zusammengelegten Domänen – Domain-Owner-Struktur in Krisenkonfiguration*](svg/cmt-consolidated-de.pdf){width=90%} ### Wie das Problemlösungs-P läuft Sowohl das CMT als auch jedes aktive DRT durchlaufen ihr eigenes Problemlösungs-P. Diese Zyklen sind **verschachtelt und miteinander verzahnt**: - Das CMT läuft auf der strategischen Koordinationsebene. Seine Tafel 3 enthält Ziele, die Domänen zugewiesen sind – nicht deren interne Aufgaben. - Jedes DRT läuft auf der domänenspezifischen Ausführungsebene. Seine Tafel 3 enthält die internen Ziele, die aus der Zuweisung des CMT abgeleitet sind. - Der Domain Owner trägt Ziele aus dem CMT in das DRT und bringt Statusmeldungen aus dem DRT wieder in das CMT zurück – innerhalb derselben Person. Das CMT sieht und steuert die internen Tafeln der DRTs nicht. Es weist Ziele zu, erhält Status und iteriert seinen eigenen Plan. DRTs entscheiden nicht selbständig über Themen, die andere Domänen oder die Organisation insgesamt betreffen. Sie handeln innerhalb ihres Rahmens und eskalieren über den Domain Owner, wenn dieser überschritten wird. ![*Verschränkte Problemlösungs-Ps – Zyklen von CMT und DRT in hierarchischer Koordination*](svg/interlocked-ps-de.pdf){width=90%} ### Planungshorizont und Iteration Das CMT arbeitet typischerweise mit einem Planungshorizont von Tagen bis Wochen. Seine Iterationen sind länger als die der DRTs. Ein CMT-Planungszyklus kann mehrere DRT-Zyklen umfassen. Die DRTs arbeiten auf kürzerem Horizont – Stunden bis Tage – und iterieren schneller. Sie können mehrere Problemlösungs-P-Zyklen abschließen, während das CMT noch in einer einzigen Umsetzungsphase ist. Diese unterschiedliche Zyklusgeschwindigkeit ist beabsichtigt und erfordert keine zeitliche Synchronität. Der Synchronisationspunkt ist der Domain Owner, der im jeweiligen Planungszyklus des CMT den aktuellen Stand seines DRT einbringt. ### Aktivierung von DRTs DRTs werden nicht automatisch mit jeder Krise aktiviert. Ihre Aktivierung ist bedarfsgetrieben. Der Domain Owner im CMT beurteilt anhand der seiner Domäne zugewiesenen Ziele, ob zusätzlicher personeller, organisatorischer oder fachlicher Unterstützungsbedarf besteht. Wenn ja, richtet der Domain Owner eigenständig ein DRT ein. War ein DRT bereits vor Einrichtung des CMT aktiv, etwa aus einem eskalierten Notfall heraus, entscheidet der Domain Owner nach der Aktivierung des CMT, ob das DRT weiterhin erforderlich ist oder ob seine Aufgaben in andere Strukturen überführt werden. ### Deaktivierung Der Crisis Owner erklärt das Ende der Krise im Lagevortrag, vorbehaltlich des Veto-Rechts des Facilitators. Alle offenen Ziele und verbleibenden Probleme werden ausdrücklich an die Linienorganisation übergeben. Die Lernphase folgt unmittelbar. DRTs können vor dem CMT deaktiviert werden, wenn ihre domänenspezifischen Ziele abgearbeitet sind. Die Entscheidung liegt beim jeweiligen Domain Owner. ## Skalierung derselben Logik: Unterschiede in Tiefe, nicht in Abfolge Der Übergang vom Notfall zur Krise verändert Koordinationsstruktur, Teamgröße, Planungshorizont und Zahl paralleler Problemlösungs-P-Zyklen. Er verändert nicht Abfolge, Rollen, Tafeln oder Methode. | Dimension | CMT (Krise) | IMT (Notfall) | DRT (Domäne innerhalb einer Krise) | ORT (Operational Response Team) | |---|---|---|---|---| | Abfolge des Problemlösungs-P | Identisch | Identisch | Identisch | Identisch | | Rollenstruktur | Crisis Owner + Crisis Facilitator + Domain Owner | Owner + Facilitator | Owner + Facilitator | Owner + Facilitator | | Tafelstruktur | Tafel 1, 2, 3 | Tafel 1, 2, 3 | Tafel 1, 2, 3 | Tafel 1, 2, 3 | | Planungs­horizont | Tage bis Wochen | Stunden bis Tage | Stunden bis Tage | Stunden | | Iterations­geschwindigkeit | Stunden bis ein Tag | Stunden | Stunden | Stunden | | Parallele Problemlösungs-P-Zyklen | Einer | Einer | Einer pro DRT | Einer pro ORT | | Verbindung zur Ebene darüber | — | — | Domain Owner im CMT | Supporter im DRT wird ORT-Owner | | Koordinations­aufwand | Minimal | Über Domain Owner gesteuert | Über Kette persönlicher Identität gesteuert | Über Kette persönlicher Identität gesteuert | Die Tabelle zeigt drei Ebenen, doch das Muster endet nicht dort. Jede Ebene kann darunter ORTs aufbauen und folgt dabei derselben Struktur: dieselbe Abfolge des Problemlösungs-P, dieselbe Rollenlogik, dieselbe Tafellogik und dasselbe Prinzip persönlicher Identität. ### Das Prinzip der Personenidentität Der strukturelle Mechanismus, der Skalierung ohne Informationsverlust ermöglicht, ist **Personenidentität über Ebenen hinweg**. Das bedeutet: Die Person, die eine Domäne im CMT vertritt, ist dieselbe Person, die das DRT dieser Domäne führt. Und weiter: Ein Supporter innerhalb eines DRT kann zum Owner eines darunter eingerichteten ORT werden. Jede Instanz persönlicher Identität **eliminiert eine Kommunikationsschnittstelle**. Wo sonst zwei unterschiedliche Personen dieselbe Information übergeben müssten – mit den typischen Risiken von Verzögerung, Verzerrung und Verlust –, trägt eine Person sie selbst von einer Ebene zur nächsten. Das ist kein Komfortmerkmal, sondern ein tragendes Strukturprinzip. Wenn Personenidentität unterbrochen wird – wenn also der Domain Owner im CMT nicht zugleich der Owner des entsprechenden DRT ist –, entsteht eine ausdrückliche Kommunikationsschnittstelle, die aktiv gesteuert, dokumentiert und überwacht werden muss. Jede solche Schnittstelle erhöht Aufwand und Risiko. Die Fortsetzung dieses Prinzips folgt einem konstanten Muster: 1. Der **Domain Owner** im CMT **ist** der **Owner** des DRT seiner Domäne. 2. Ein **Supporter** im DRT kann **zum Owner** eines darunterliegenden ORT **werden**. 3. Auf jeder weiteren Verschachtelungsebene gilt dasselbe Muster. So skaliert P-DRIVEN strukturell: nicht durch zusätzliche Koordinationsprotokolle, sondern durch verlängerte Ketten persönlicher Identität über Ebenen hinweg. Je weniger Schnittstellen, desto geringer der Informationsverlust. Je stärker sich Ebenen auf Personenidentität stützen, desto robuster die Koordination. ### Verschachtelte und verschränkte Problemlösungs-Ps Wenn ein CMT und ein oder mehrere DRTs gleichzeitig aktiv sind, laufen **mehrere Problemlösungs-Ps parallel**. Jedes Team durchläuft seinen eigenen vollständigen Zyklus auf seinen eigenen Tafeln. Die Verschränkung funktioniert über den Domain Owner: - In der Planungsphase des CMT werden Ziele definiert und über Tafel 3 an Domänen zugewiesen. - Der Domain Owner trägt diese Ziele in das DRT, wo sie Input für die eigene Planungsphase des DRT werden. - Das DRT durchläuft sein eigenes P und kehrt wieder zum Anfang zurück. - Status, Abschlüsse und Hindernisse fließen über den Domain Owner aus dem DRT zurück in das CMT und werden dort im nächsten Planungszyklus eingebracht. Die Problemlösungs-P-Zyklen auf unterschiedlichen Ebenen müssen nicht zeitgleich laufen. Das CMT kann in seiner Umsetzungsphase sein, während ein DRT bereits wieder plant. Synchronisiert wird nicht über eine gemeinsame Uhr, sondern über die Meldung des Domain Owner im jeweiligen Planungszyklus des CMT. DRTs sind ausdrücklich befugt, vom CMT zugewiesene Ziele neu zu priorisieren oder umzutakten, wenn die Lage auf Domänenebene dies erfordert. Diese Befugnis besteht, weil DRTs über Detailwissen und Lagebewusstsein verfügen, das das CMT nicht in Echtzeit besitzt. Jede Abweichung von CMT-Zielen ist jedoch **verpflichtend** an das CMT zurückzumelden. Lautlose Abweichung ist ein Prozessverstoß. ### Verschachtelungstiefe: Das Muster setzt sich nach unten fort Das Verschachtelungsmuster endet nicht bei zwei Ebenen. Ein DRT, das innerhalb seiner Domäne ausreichende Komplexität bewältigen muss, kann ein oder mehrere **Operational Response Teams (ORT)** darunter einrichten. Jedes ORT läuft mit eigenen Tafeln, eigenem Owner, eigenem Facilitator und eigener Iteration. Der Mechanismus ist identisch mit der Beziehung zwischen CMT und DRT: 1. Ein **Supporter** im DRT erhält Verantwortung für einen Teilbereich von Zielen. 2. Dieser Supporter **wird zum Owner** eines ORT, das diesen Teilbereich bearbeitet. 3. Das ORT durchläuft sein eigenes P. Sein Owner meldet Status zurück an das DRT – im Kontext des DRT als Supporter, im Kontext des ORT als Owner. 4. Wenn das ORT selbst hinreichende Komplexität aufweist, kann ein Supporter darin wiederum ein weiteres ORT aufbauen – und das Muster wiederholt sich. Es gibt keine theoretische Grenze für die Tiefe der Verschachtelung. Praktisch erhöht jede zusätzliche Ebene den Koordinationsaufwand. Organisationen sollten daher nur dann weitere Ebenen ergänzen, wenn die Komplexität auf einer Ebene das übersteigt, was dort mit Supportern allein koordiniert werden kann. #### Planungshorizonte über Ebenen hinweg Je tiefer die Verschachtelung, desto kürzer wird typischerweise der Planungshorizont auf jeder Ebene, und desto schneller wird die Iteration. Das ist strukturell folgerichtig: Tiefere Ebenen bearbeiten konkretere, unmittelbarere Probleme mit engerem Befugnisrahmen. | Ebene | Typischer Planungs­horizont | Typische Iteration | Geltungs­bereich | |---|---|---|---| | **CMT** | Tage bis Wochen | Stunden bis ein Tag | Organisationsweit, strategisch | | **DRT** | Stunden bis Tage | Stunden | Domänenspezifisch, taktisch | | **ORT** | Stunden | Stunden | Aufgabenspezifisch, operativ | | **Weitere Ebenen** | Zunehmend kürzer | An die Ebene darüber angepasst | Zunehmend enger | Der Planungshorizont jeder Ebene muss innerhalb der Iteration der darüberliegenden Ebene liegen. Wenn der Planungshorizont eines DRT über die Iteration des CMT hinausreicht, plant das CMT den nächsten Zyklus ohne aktuellen DRT-Status – und der Sinn der Verschachtelung geht verloren. Der Facilitator jeder Ebene ist dafür verantwortlich, die Iteration so zu takten, dass die darunterliegende Ebene mindestens einen Zyklus abschließen und zurückmelden kann. ### Skalierung über Standorte Wenn eine Krise mehrere geografische Standorte betrifft, muss sich die Koordinationsstruktur horizontal ausdehnen. Dadurch entsteht ein zusätzliches Strukturelement: das **Location Response Team (LRT)**. Ein LRT ist strukturell einem DRT gleichwertig – es durchläuft sein eigenes Problemlösungs-P mit derselben Rollenstruktur und derselben Tafellogik. Der Unterschied besteht darin, dass sein Geltungsbereich geografisch und nicht funktional definiert ist. #### Zwei Ansätze für geografische Skalierung Es gibt zwei strukturelle Möglichkeiten, LRTs aufzubauen. Organisationen müssen bewusst entscheiden, welchen Ansatz sie je nach verfügbarer Personalausstattung und Lagecharakter wählen. **Option 1: Domänenspezifische LRTs (empfohlen)** Jede betroffene Domäne richtet an jedem betroffenen Standort ein eigenes LRT ein. Die IT-Domäne hätte also etwa ein eigenes IT-LRT an Standort A und ein weiteres an Standort B. Dieser Ansatz erhält die Kette persönlicher Identität: - Der Domain Owner IT im CMT **ist** der Owner des IT-DRT. - Ein Supporter im IT-DRT **wird** zum Owner des IT-LRT an Standort A. - Das IT-LRT an Standort A meldet über seinen Owner an das IT-DRT zurück, das wiederum über den Domain Owner IT in das CMT meldet. Jede Kommunikationsverbindung wird von Personenidentität getragen. Keine Übersetzung, keine Zwischeninstanz. **Vorteile:** - Klare domänenspezifische Verantwortung auf jeder Ebene. - Kein Informationsverlust durch domänenübergreifende Übersetzung. - Konsistent mit der bestehenden DRT-Verschachtelungslogik. - Domain Owner im CMT erhalten direkte funktionale Rückmeldungen von jedem Standort. **Nachteil:** - Höherer Personalbedarf. Jede Domäne an jedem Standort benötigt mindestens einen Owner und einen Facilitator. **Option 2: Standortübergreifende LRTs (ressourcenbegrenzte Abweichung)** Ein einziges LRT pro Standort bearbeitet alle Domänenaktivitäten dieses Standorts. Der LRT-Owner repräsentiert den gesamten Standort in der Koordinationsstruktur. Dieser Ansatz durchbricht die Kette persönlicher Identität zwischen Domain Ownern und Umsetzung auf Standortebene. Der LRT-Owner ist ein geografischer Koordinator und kein Domänenspezialist. Information muss zwischen funktionaler und geografischer Perspektive übersetzt werden. Zum Ausgleich müssen **Domain Owner Standorten ausdrücklich zugeordnet werden**, damit strukturierte Rückmeldung möglich bleibt. Jeder Domain Owner erhält Statusmeldungen aus den LRTs für seinen fachlichen Bereich – aber über den LRT-Owner als Mittler. **Vorteile:** - Geringerer Personalbedarf. - Eine einzige Schnittstelle pro Standort. **Nachteile:** - Durchbricht das Prinzip der Personenidentität. Jede Verbindung zwischen LRT und Domain Owner wird zu einer ausdrücklichen Kommunikationsschnittstelle, die aktiv gesteuert werden muss. - Informationsverlust und Übersetzungsverzerrung sind strukturelle Risiken. - Der LRT-Owner muss über erheblich breitere Qualifikation verfügen. - Domain Owner tragen eine Doppelbelastung aus CMT-Funktion und Standortberichterstattung. **Bewertung:** Option 1 entspricht der strukturellen Logik von P-DRIVEN. Sie skaliert das bestehende Verschachtelungsmuster, ohne neue Elemente oder Schnittstellen einzuführen. Organisationen, die domänenspezifische LRTs personell besetzen können, sollten dies tun. Option 2 ist ein ressourcengetriebener Kompromiss. Sie ist keine Variante von P-DRIVEN, sondern eine **bewusste Abweichung** von der strukturellen Logik, die bestimmte Risiken in Kauf nimmt. Organisationen, die Option 2 wählen, müssen die Schnittstellen ausdrücklich steuern, die das Prinzip der Personenidentität sonst beseitigen würde. ## Typische Belastungspunkte beim Hochskalieren Die Skalierung vom Notfall zur Krise – oder von einer Krise an einem Standort zu einer Mehrstandortkrise – bringt Koordinationsherausforderungen mit sich, die auf IMT-Ebene nicht auftreten. Sie sind keine Fehler der Methode, sondern Folgen gesteigerter Komplexität. Wer sie früh erkennt, verhindert strukturelle Erosion. ### Das CMT trifft operative Detailentscheidungen Wenn das CMT beginnt, Entscheidungen zu treffen, die in die DRTs gehören – also festlegt, *wie* Ziele erreicht werden sollen, statt *welche* Ziele verfolgt werden –, verlieren die Domänenteams ihre operative Autonomie. Der Planungszyklus des CMT ist für operative Details zu langsam. Entscheidungen, die domänenspezifisches Lagebewusstsein erfordern, müssen auf Domänenebene bleiben. Der Indikator ist klar: Wenn auf der Tafel 3 des CMT Aufgaben statt Ziele stehen, hat das CMT die Grenze überschritten. ### DRTs berichten nicht mehr oder am Domain Owner vorbei Wenn Mitglieder eines DRT direkt an das CMT berichten und dabei ihren Domain Owner umgehen, bricht der strukturierte Informationsfluss zusammen. Das CMT erhält ungefilterte, unstrukturierte Informationen, die es in seinem eigenen Planungszyklus nicht verarbeiten kann. Zugleich verliert der Domain Owner den Überblick über die eigene Domäne. Alle Meldungen aus einem DRT an das CMT laufen über den Domain Owner. Das ist keine Bürokratie, sondern der Mechanismus, der Information zwischen Ebenen konsistent hält. ### Domain Owner verlassen das CMT während der Planungsphase Domain Owner sind gleichzeitig die Owner ihrer DRTs. Während der Planungsphase des CMT müssen sie im CMT anwesend sein. Während der Umsetzungsphase des CMT wechseln sie in die Führung ihrer DRTs. Wenn Domain Owner das CMT während dessen Planungsphase verlassen, um Domänenthemen direkt zu steuern, verliert das CMT die Perspektiven, die es für fundierte Entscheidungen braucht. Der Facilitator muss Anwesenheitsdisziplin durchsetzen. ### Problemlösungs-P-Zyklen zwischen Ebenen sind nicht aufeinander abgestimmt CMT und DRTs müssen nicht synchron laufen. Das CMT muss seine eigenen Planungszyklen aber in Kenntnis der Taktung der DRTs setzen. Wenn das CMT eine neue Planungsphase beginnt, bevor DRTs ihre aktuellen Ziele bearbeiten und zurückmelden konnten, plant das CMT auf veralteter Information. Der Facilitator steuert dies, indem er Lagevorträge so terminiert, dass Domain Owner aktuellen DRT-Status in das CMT einbringen können. ### Tafeln werden zwischen Ebenen vermischt Wenn DRT-interne Aufgaben auf der Tafel 3 des CMT auftauchen oder Ziele auf CMT-Ebene in Tafel 1 eines DRT erscheinen, kollabiert die Trennung der Koordinationsebenen. Jedes Team führt seine eigenen Tafeln. Die Tafel 3 des CMT verfolgt Ziele, die Domänen zugewiesen sind. Die Tafel 3 des DRT verfolgt Ziele, die innerhalb der Domäne Ressourcen zugewiesen sind. Das sind unterschiedliche Abstraktionsebenen und dürfen nicht vermischt werden. ### Unkontrollierte Aktivierung von DRTs oder LRTs Wenn DRTs oder LRTs ohne klare Aktivierungsentscheidung eingerichtet werden, verliert das CMT den Überblick über seine eigene Koordinationsstruktur. Jede Teamaktivierung ist eine bewusste Entscheidung des zuständigen Domain Owner, wird dokumentiert und an das CMT kommuniziert. ### Geografische Skalierung ohne strukturelle Klarheit In Mehrstandortkrisen ist der häufigste Fehler Unklarheit darüber, welche strukturelle Option verwendet wird. Wenn einige Standorte domänenspezifische LRTs und andere standortübergreifende LRTs haben, ohne dass das CMT die Berichtsstruktur ausdrücklich festgelegt hat, werden Informationen unvollständig, inkonsistent und verspätet. Bevor LRTs eingerichtet werden, muss das CMT entscheiden: domänenspezifisch oder standortübergreifend. Gemischte Strukturen erzeugen Koordinationslücken, die unter Druck kaum beherrschbar sind. ### Die Kette persönlicher Identität ist unterbrochen, ohne dass dies ausgeglichen wird Wenn die Person im CMT nicht dieselbe ist wie die Person, die das entsprechende DRT führt – etwa wegen Personalmangel, Schichtwechsel oder Organisationsentscheidung –, entsteht eine Kommunikationsschnittstelle. Wird diese nicht ausdrücklich gesteuert, verschlechtert sich Information an jedem Ebenenübergang. Jeder Bruch in der Kette persönlicher Identität muss identifiziert, anerkannt und mit ausdrücklichen Koordinationsmechanismen ausgeglichen werden. Lautlose Brüche gehören zu den häufigsten Ursachen für Koordinationsversagen in skalierten Aktivierungen. --- # Teil IV — Unterstützende Elemente und Arbeitshilfen P-DRIVEN ist darauf ausgelegt, mit minimaler Infrastruktur zu funktionieren. Die Methode selbst – Problemlösungs-P, Drei-Tafel-Methode, Rollenstruktur – benötigt keine Spezialsoftware, keine proprietären Werkzeuge und kein aufwendiges Dokumentationssystem. Das ist Absicht. In einem Notfall oder einer Krise können die Systeme, auf die eine Organisation sich sonst stützt, beeinträchtigt, kompromittiert oder nicht verfügbar sein. Jede Methode, die für ihr Funktionieren auf bestimmte Technologie angewiesen ist, ist genau dann fragil, wenn sie gebraucht wird. Der Leitgedanke lautet: **Methode vor Technologie**. Der strukturierte Prozess und die Kompetenz der Menschen, die ihn ausführen, sind die primären Vermögenswerte. Werkzeuge unterstützen die Methode – sie bilden sie nicht. Dieser Teil beschreibt die minimalen Arbeitshilfen, die eine wirksame Anwendung von P-DRIVEN unterstützen, wie Dokumentation ohne zusätzlichen Aufwand erfolgt, wie Methodendisziplin unter Stress erhalten wird und wie P-DRIVEN an bestehende organisatorische Strukturen anschließt. ## Minimale Arbeitshilfen und ihr Zweck Arbeitshilfen in P-DRIVEN erfüllen drei Funktionen: Information erfassen, Information visualisieren und Kommunikation ermöglichen. Sie führen keine neuen Prozesse ein. Sie unterstützen die bereits durch das Problemlösungs-P und die Drei-Tafel-Methode definierten Prozesse. Die in diesem Abschnitt beschriebenen Arbeitshilfen orientieren sich am Bedarf von Organisationen, die IT-bezogene Notfälle und organisatorische Krisen bewältigen. Organisationen außerhalb des IT-Kontexts sollten Elemente jenseits der drei Tafeln und grundlegender Kommunikationsmittel als kontextabhängig betrachten. Kernanforderung bleibt in jedem Kontext: gemeinsamer visueller Arbeitsraum, verlässliche unabhängige Kommunikation und ein definierter Krisenstabsraum oder Notfallraum. ### Die drei Tafeln Die Drei-Tafel-Methode ist die zentrale Arbeitshilfe. Sie erfordert: - drei beschreibbare Flächen, - ausreichend Moderationskarten, - Marker in mehreren Farben, - Magnete oder Klebematerial. Die Tafeln müssen groß genug sein, damit das Team sie aus normalem Arbeitsabstand lesen kann. Sie müssen sich in dem Raum befinden, in dem das Team seine Planungsphase durchführt. Digitale Äquivalente können genutzt werden, wenn und nur wenn sie dieselben Anforderungen erfüllen: für das gesamte Team gleichzeitig sichtbar, in Echtzeit bearbeitbar und ohne Abhängigkeit von der primären IT-Infrastruktur der Organisation nutzbar. Wenn das Organisationsnetz Teil des Problems ist, stehen digitale Tafeln nicht zur Verfügung. Physische Tafeln haben keine Abhängigkeiten. ### Kommunikationsmittel P-DRIVEN-Teams müssen miteinander, mit Ressourcen in der Umsetzung und mit der Linienorganisation kommunizieren können. Kommunikationsmittel müssen **unabhängig von der Infrastruktur sein, die vom Notfall oder von der Krise betroffen sein könnte**. Dazu gehören typischerweise: - **Dedizierte Mobiltelefone** mit separaten Nummern und SIM-Karten, - **dedizierte E-Mail-Konten** bei einem vom Primärsystem der Organisation unabhängigen Anbieter, - **eine mobile Internetverbindung**, die unabhängig vom Organisationsnetz ist, - **ein Alarmierungssystem**, das Mehrkanal-Benachrichtigung, Verfügbarkeitsbestätigung, automatisierte Konferenzschaltungen und Eskalationslogik beherrscht. Optional, aber empfehlenswert: - **PMR-Funkgeräte** für lokale Kommunikation, - **eine Standby-Website** bei einem separaten Anbieter für externe Kommunikation. ### Der Krisenstabsraum oder Notfallraum Der Krisenstabsraum oder Notfallraum ist der physische oder virtuelle Raum, in dem das Team seine Planungsphase durchführt. Anforderungen: - Platz für das vollständige Team, - die drei Tafeln sichtbar und zugänglich, - ein Tisch für Arbeit und Briefing, - ausreichende Stromversorgung, idealerweise mit USV oder mobiler Stromquelle. Während der Umsetzungsphase verlassen Teammitglieder den Raum, um an ihren Zielen zu arbeiten. Der Facilitator bleibt. Das bedeutet, dass die Organisation mindestens einen zusätzlichen Arbeitsplatz benötigt, an dem der Owner ungestört arbeiten kann. Der Raum muss vor Unterbrechungen geschützt sein. Externe Besucher, Routineanfragen und nicht beteiligte Mitarbeitende müssen während einer Aktivierung ferngehalten werden. ### Dokumentationsausstattung - eine **Kamera** für die fotografische Dokumentation der Tafeln, - **Notizbücher und Stifte** – möglichst frisch je Aktivierung, - ein **Drucker** für schriftliche Anweisungen, falls erforderlich. ### Laptops Dedizierte Laptops, die unabhängig von der Domäneninfrastruktur der Organisation funktionieren, stellen sicher, dass das Team arbeitsfähig bleibt, auch wenn die IT-Systeme der Organisation kompromittiert sind. Sie müssen mit Basissoftware, Zugriff auf dedizierte E-Mail-Konten und einem Passwortmanager für administrative Zugangsdaten ausgestattet sein. ### Administrative Zugänge Das Team muss sofortigen Zugriff auf administrative Konten für kritische Systeme haben. Dazu gehören Administratorzugänge, SSH-Schlüssel, Zertifikate und sonstige Zugangsdaten, die für Wiederherstellungsmaßnahmen erforderlich sind. Diese müssen sicher, aber unabhängig von den möglicherweise betroffenen Systemen zugänglich aufbewahrt werden. ### Was nicht benötigt wird P-DRIVEN benötigt nicht: - spezielle Krisenmanagementsoftware, - aufwendige Dokumentationsvorlagen, - einen permanent eingerichteten Krisenraum. Die Gesamtkosten für die Ausstattung eines P-DRIVEN-Teams bleiben überschaubar. Es ist keine Investition in Technologie, sondern in Unabhängigkeit von Technologie, die ausfallen könnte. ## Dokumentation ohne Bürokratie Einer der häufigsten Einwände gegen strukturierte Prozesse ist der vermutete Dokumentationsaufwand. P-DRIVEN begegnet dem mit **integrierter Dokumentation**: Die Methode erzeugt die Dokumentation als Nebenprodukt ihrer Ausführung. Es ist keine separate Dokumentationsrolle erforderlich. ### Wie Dokumentation entsteht Die Dokumentation einer P-DRIVEN-Aktivierung besteht aus: 1. **Fotodokumentationen der Tafeln** an zwei definierten Punkten jeder Iteration: - bei **Lage einfrieren**, - bei **Vorbereitung Lagevortrag**. 2. **Dem Protokoll des Alarmierungssystems**, das Aktivierungszeiten, Verfügbarkeitsbestätigungen und initiale Kommunikation erfasst. 3. **Schriftlichen Auftragsübermittlungen**, die dokumentieren, was wem mit welchem Umfang und welcher Frist übertragen wurde. 4. **Debriefing-Notizen** und dem **Bericht zum strukturierten Feedback**, die Beobachtungen und Verbesserungsmaßnahmen nach der Deaktivierung festhalten. Diese Gesamtheit aus Tafel-Fotos, Alarmierungsprotokollen, Auftragsübermittlungen und Dokumentation der Lernphase liefert eine vollständige, rekonstruierbare Darstellung der Aktivierung, ohne dass jemand parallel Protokoll führen muss. ### Die Rolle des Facilitators in der Dokumentation Der Facilitator ist verantwortlich für: - Sicherstellung der Fotodokumentation an den definierten Punkten, - Pflege von Tafel 3 als maßgeblichem Nachverfolgungsinstrument, - Dokumentation des Debriefings, - Sicherstellung, dass Aktivierungs- und Deaktivierungsentscheidungen festgehalten werden. Dies ist keine Sekretariatsfunktion. Es ist Teil seiner Prozessverantwortung. Dokumentation ist Folge von Methodendisziplin, nicht Zusatzaufgabe. ### Was nicht dokumentiert werden sollte Zu vermeiden sind: - wörtliche Protokolle von Diskussionen, - detaillierte Logs jedes Telefonats oder jeder Statusmeldung, - retrospektive Berichtsschreibung während der Aktivierung. Ziel ist eine Dokumentationsspur, die **für Rekonstruktion, Rechenschaft und Lernen ausreicht**, nicht ein Vollarchiv aller Ereignisse. ## Aufrechterhaltung von Methodendisziplin unter Stress Das Problemlösungs-P ist für Lagen entworfen, in denen kognitive Last hoch, Information unvollständig und Zeitdruck real ist. Die Methode funktioniert gerade deshalb, weil sie Verhalten auf eine Weise begrenzt, die typische stressbedingte Fehler verhindert. Genau derselbe Stress, der die Methode notwendig macht, erschwert aber auch ihre Einhaltung. ### Warum Disziplin erodiert Unter Stress neigen selbst erfahrene Praktiker dazu, auf intuitive Entscheidungsfindung zurückzufallen. Das zeigt sich etwa als: - **Auslassen der Lagefeststellung**, - **direktes Springen zu Lösungen**, - **Aufgabe der Tafeln**, - **Zusammenfall der doppelten Führung**, - **endlos verlängerte Planungsphase**, weil das Team noch mehr Information haben möchte. Jede dieser Abkürzungen fühlt sich im Moment effizient an. Jede von ihnen verschlechtert Koordinationsqualität, Nachvollziehbarkeit von Entscheidungen und Teamabstimmung. Die Rollenbeschreibung des Facilitators mit Prozessautorität und Veto-Recht existiert genau, um diesen Tendenzen entgegenzuwirken. ### Das 80-Prozent-Prinzip Eine wiederkehrende Herausforderung im Krisenmanagement ist das Streben nach vollständiger Information vor dem Handeln. In der Praxis gibt es vollständige Information nie. Entscheidungen in Notfällen und Krisen werden immer unter Unsicherheit getroffen. P-DRIVEN bildet diese Realität strukturell ab: Die Iteration sorgt dafür, dass jede Entscheidung im nächsten Zyklus überprüft wird. Eine 80-Prozent-Lösung jetzt ist besser als eine 100-Prozent-Lösung, die zu spät kommt. Das bedeutet nicht unbedachtes Handeln, sondern die Akzeptanz, dass unvollkommene Handlung in einem strukturierten Prozess bessere Ergebnisse erzeugt als verzögertes Handeln in Hoffnung auf perfekte Information. ### Training und Qualifikation Methodendisziplin unter Stress lässt sich nicht allein durch Lesen erreichen. Sie erfordert Übung. - **Facilitators** benötigen die intensivste Qualifikation. - **Owners** müssen das Problemlösungs-P so gut verstehen, dass sie ihm ohne Widerstand folgen können. - **Supporter** müssen Tafellogik, Berichtsstruktur und den Umfang ihrer Befugnisse verstehen. Regelmäßige Übungen – mindestens zweimal pro Jahr pro Rolle – sind essenziell. *P-DRIVEN: Arbeitsbuch* vermittelt Verständnis. Übungen erzeugen Kompetenz. Beides ist notwendig; keines genügt allein. Ein eigenes P-DRIVEN-Trainings- und Übungsprogramm ist separat verfügbar und nicht Teil von *P-DRIVEN: Arbeitsbuch*. ## Schnittstellen zu bestehenden Organisationsstrukturen P-DRIVEN ersetzt die bestehenden Managementstrukturen einer Organisation nicht. Es aktiviert sich neben ihnen, wenn eine Lage die Routinekapazität übersteigt. Dadurch entstehen Schnittstellen, die ausdrücklich gesteuert werden müssen. ### Verhältnis zu Geschäftsführung oder Vorstand Geschäftsführung oder Vorstand behalten die Gesamtverantwortung für die Organisation, auch im Notfall oder in der Krise. Die P-DRIVEN-Teamstruktur arbeitet als **besondere Aufbauorganisation** unter ihrer Autorität. Der Crisis Owner handelt als delegierte operative Leitungsinstanz. Er: - handelt im Auftrag der Organisationsleitung, - vertritt deren strategische Interessen im operativen Prozess, - stellt sicher, dass Entscheidungen kohärent, lageangemessen und durchsetzbar sind. Geschäftsführung oder Vorstand sind nicht in die P-DRIVEN-Teamstruktur eingebettet. Während einer Krise übernehmen sie nicht delegierbare Aufgaben wie Vertretung gegenüber Regulatoren, Aufsichtsgremien oder politischen Stakeholdern, strategische Kommunikation und den Schutz der Gesamtinteressen der Organisation. Diese Trennung verhindert operative Überlastung und schützt den operativen Prozess vor strategischer Einmischung. Die Schnittstelle ist strukturiert: Der Crisis Owner erarbeitet Entscheidungsvorlagen für die Organisationsleitung und erhält strategische Leitplanken zurück. Die Organisationsleitung nimmt nicht an der Planungsphase teil und greift nicht in die Tafelentscheidungen ein. ### Verhältnis zur Linienorganisation Während einer Aktivierung arbeiten P-DRIVEN-Struktur und Linienorganisation parallel. Die Linienorganisation funktioniert in allen nicht betroffenen Bereichen weiter. Die Schnittstellen sind: - **Domain Owner** verbinden die P-DRIVEN-Struktur mit den funktionalen Bereichen der Linienorganisation. Sie tragen Information in beide Richtungen. - **Supporter** stammen aus der Linienorganisation. Ihre temporäre Zuordnung in ein P-DRIVEN-Team muss gegenüber ihrer Linienführung kommuniziert und akzeptiert sein. Dafür braucht es organisatorische Regelungen zur Freistellung von Personal. - **Übergabe bei Deaktivierung:** Wenn die Aktivierung endet, müssen alle offenen Ziele und verbleibenden Probleme ausdrücklich an die Linienorganisation zurückgegeben werden. Diese Übergabe liegt in der Verantwortung des Owners und muss dokumentiert werden. ### Verhältnis zu bestehenden Plänen und Verfahren Organisationen unterhalten typischerweise verschiedene Pläne: Business-Continuity-Pläne, Disaster-Recovery-Pläne, szenariospezifische Playbooks oder Kommunikationspläne. P-DRIVEN ersetzt diese nicht. Es stellt den **Entscheidungs- und Koordinationsrahmen** bereit, innerhalb dessen diese Pläne aktiviert, angepasst oder verworfen werden. Ein Playbook beschreibt, was in einem bestimmten Szenario zu tun ist. P-DRIVEN beschreibt, wie entschieden wird, was zu tun ist, wenn das Szenario unklar ist, mehrere Szenarien überlappen oder das Playbook die Lage nicht abdeckt. Beides ergänzt sich: - In der Lagefeststellung können bekannte Playbooks die Problemidentifikation unterstützen. - In der Entscheidungsfindung können etablierte Verfahren eine der bewerteten Lösungsstrategien sein. - In der Zieldefinition können in Playbooks definierte Handlungen zu Zielen auf Tafel 3 werden. Aber der Problemlösungs-P regiert. Wenn ein Playbook der Lagebewertung des Teams widerspricht, hat die Lagebewertung des Teams Vorrang. Playbooks sind Hilfen, keine Befehle. ### Organisatorische Voraussetzungen Damit P-DRIVEN wirksam funktioniert, müssen bestimmte organisatorische Voraussetzungen gegeben sein: - **Befugnisrahmen:** Die besondere Aufbauorganisation muss definierte Befugnisse haben. - **Freistellungsregelung für Personal:** Übungen und Aktivierungen erfordern die Freistellung von Mitarbeitenden aus ihren Regelaufgaben. - **Übungen haben denselben Stellenwert wie reale Aktivierungen:** Übungsteilnahme muss organisatorisch als Kernaufgabe gelten. - **Kultur der frühen Aktivierung:** Die Alarmierung des Teams darf nicht als Vorwurf oder Zeichen des Scheiterns verstanden werden. - **Jährliche Überprüfung:** Rollen, Pläne, Ausstattung und Kontaktdaten müssen mindestens einmal jährlich überprüft werden. Diese Voraussetzungen sind nicht Teil von P-DRIVEN selbst. Sie sind der organisatorische Boden, auf dem P-DRIVEN wirksam werden kann. --- # Teil V — Typische Fehler, Verwässerungsmuster und Fehlanwendungen P-DRIVEN ist kein sich selbst ausführendes System. Sein Wert hängt davon ab, mit welcher Treue es angewendet wird. In der Praxis treten bestimmte Fehlmuster organisationsübergreifend wiederholt auf. Sie zu verstehen, ist keine optionale Vertiefung, sondern Teil operativer Vorbereitung. Dieser Teil beschreibt die häufigsten Weisen, in denen P-DRIVEN in der Praxis scheitert: durch Brüche in der Abfolge, Methodenvermischung, Planungsfehlformen und strukturelle Rollenkonfusion. ## Die Abfolge brechen Das Problemlösungs-P ist ein sequenzieller Prozess. Seine Phasen und Schritte folgen aus strukturellen Gründen aufeinander: Jeder Schritt erzeugt Ergebnisse, die der nächste benötigt. Lagefeststellung erzeugt die Problemliste, die Lagebewertung priorisiert. Priorisierung erzeugt den Input für die Entscheidungsfindung. Entscheidungsfindung erzeugt die Strategie, die Zieldefinition in konkrete Zuweisungen übersetzt. Schritte auszulassen oder umzustellen spart keine Zeit – es entwertet nachgelagerte Ergebnisse. ### Direkt zu Lösungen springen Der häufigste Bruch der Abfolge besteht darin, vom Lagevortrag direkt in die Lösungsdiskussion zu springen. Das Team hört die aktuelle Lage und beginnt sofort zu diskutieren, was zu tun ist. Lagefeststellung und Lagebewertung werden übersprungen. Die Folgen: - Nicht alle Probleme werden sichtbar. - Es findet keine Priorisierung statt. - Es erfolgt keine strukturierte Bewertung von Lösungsstrategien. Die Abkürzung fühlt sich effizient an. Unter Stress übt die erste einfallende Lösung starken Sog aus – besonders dann, wenn sie in einer ähnlichen Lage schon einmal funktioniert hat. Genau diese kognitive Falle soll die strukturierte Abfolge verhindern. ### Die Lagefeststellung vollständig auslassen Ein verwandtes Muster besteht darin, die Lagefeststellung für unnötig zu erklären, weil „wir die Probleme ohnehin schon kennen“. Das tritt besonders bei wiederkehrenden Lagen auf. Der Fehler liegt darin, dass Begleitprobleme, die die Umsetzung später erschweren, nicht sichtbar werden. ### Die Tafeln mitten in der Aktivierung aufgeben Unter anhaltendem Druck geben Teams die Tafeln manchmal mitten in einer Aktivierung auf. Die ersten Zyklen werden noch auf Tafeln geführt, später wird auf verbale Koordination zurückgefallen. Damit verschwindet der gemeinsame dokumentierte Zustand. Jede Person arbeitet mit ihrem eigenen mentalen Modell der Lage. Koordinationslücken öffnen sich still. Ist die Tafelpflege erst einmal aufgegeben, gibt es keinen sauberen Rückweg ohne bewussten Neustart. Der Facilitator muss dies ausdrücklich benennen, den Tafelstand so gut wie möglich rekonstruieren und den formalen Prozess erneut herstellen. ### Mehrere Schritte zu einem zusammenziehen Unter Druck versuchen Teams mitunter, Lagefeststellung, Lagebewertung und Entscheidungsfindung gleichzeitig laufen zu lassen – Problem benennen, sofort bewerten und direkt entscheiden. Damit werden drei strukturell unterschiedliche Schritte mit unterschiedlichen kognitiven Anforderungen in ein undifferenziertes Gespräch zusammengezogen. Die Abfolge ist keine Bürokratie. Sie ist der Mechanismus, durch den der Prozess unter kognitiver Belastung verlässliche Ergebnisse erzeugt. ## P-DRIVEN mit anderen Methoden vermischen Organisationen arbeiten häufig gleichzeitig mit mehreren Rahmenwerken – Governance-Frameworks, agilen Praktiken, ITSM-Prozessen oder ad hoc gewachsenen Krisenprotokollen. Wenn eine P-DRIVEN-Aktivierung beginnt, verschwinden diese Muster nicht. Praktiker bringen ihre Gewohnheiten mit. Das Ergebnis ist Methodenvermischung. ### Parallele Prozesse betreiben Ein häufiges Muster besteht darin, P-DRIVEN zu aktivieren und gleichzeitig einen separaten War Room oder parallelen Eskalationsprozess laufen zu lassen – meist, weil P-DRIVEN von Senior Stakeholdern noch nicht vollständig akzeptiert ist. Zwei Strukturen erzeugen zwei Entscheidungswege. Wenn sich diese überschneiden oder widersprechen, leidet die Umsetzung. P-DRIVEN kann nicht mit einer parallelen Entscheidungsautorität über denselben Geltungsbereich koexistieren. Entweder P-DRIVEN ist die Entscheidungsstruktur der Aktivierung oder es ist es nicht. ### Agile Rituale importieren Teams mit agilem Hintergrund versuchen manchmal, Stand-ups, Sprint Reviews oder Retrospektiven in P-DRIVEN einzubauen. Diese Muster sind nicht kompatibel. Stand-ups sind für stabile, laufende Arbeit gedacht; P-DRIVEN für instabile, dringliche Lagen. Während einer Aktivierung ersetzt P-DRIVEN solche Routinen. ### Checklisten auf den Prozess pfropfen Vorhandene Checklisten und Playbooks sind nützliche Inputs für P-DRIVEN. Problematisch werden sie, wenn sie als der Prozess selbst behandelt werden. Ein Team, das während der Lagefeststellung eine Checkliste abarbeitet, führt keine Lagefeststellung durch – es hakt Felder ab. Checklisten verankern Aufmerksamkeit auf Erwartetes. Unerwartete Probleme stehen nicht darauf. ## Überplanung und verfrühte Lösungsentwürfe Iterative Planung unter Unsicherheit verlangt Handeln, bevor vollständige Information verfügbar ist. Genau dieser Grundsatz erzeugt zwei gegenläufig wirkende Fehlmuster, die beide wirksame Reaktion verzögern. ### Die Planungsphase endlos verlängern Die Planungsphase hat einen definierten Umfang. Ein häufiges Versagen besteht darin, sie zu verlängern, weil das Team vor einer Festlegung noch mehr Information will. Zusätzliche Briefings werden angefordert, Lagefeststellung wird wieder geöffnet, Entscheidungsfindung wird verschoben, weil „die Lage sich noch entwickelt“. In Notfällen und Krisen entwickelt sich die Lage immer weiter. Die Planungsphase ist nicht dazu da, Gewissheit zu erzeugen, sondern eine koordinierte Reaktion auf das beste aktuell verfügbare Verständnis. ### Lösungen schon in der Problemaufnahme entwerfen Das Gegenmuster ist vorzeitige Lösungsentwicklung: Das Team beginnt bereits während der Lagefeststellung, Lösungen zu bauen. Sobald eine Lösung früh vorgeschlagen ist, neigt das restliche Verfahren dazu, nur noch diese Lösung zu stützen, statt die Lage offen zu untersuchen. Die Lagefeststellung muss abgeschlossen sein, bevor Lösungsdiskussion beginnt. Jeder Lösungsvorschlag, der während der Lagefeststellung auftaucht, ist außerhalb der Abfolge und muss für die Entscheidungsfindung geparkt werden. ### Mit höherer Auflösung planen als nötig Ziele auf Tafel 3 müssen klar und zuweisbar sein. Sie müssen nicht vollständig bis ins Detail spezifiziert werden. Ein häufiger Fehler besteht darin, Ziele so granular zu definieren, dass die Planungsphase eher einen Projektplan als einen Satz von Zielen erzeugt. Geplant wird auf der Ebene dessen, was erreicht werden muss und bis wann – nicht auf der Ebene jedes einzelnen Ausführungsschritts. ## Rollenkonfusion und Führungsdrift Die doppelte Führungsstruktur – Owner und Facilitator – ist in der Praxis das beständig missverstandene Element von P-DRIVEN. Die Trennung von Entscheidungsautorität und Prozessautorität widerspricht der Logik vieler Organisationen. Der Widerstand dagegen zeigt sich in vorhersehbaren Mustern. ### Der Owner übernimmt zusätzlich die Rolle des Facilitators Der häufigste strukturelle Zusammenbruch besteht darin, dass der Owner beide Rollen gleichzeitig ausüben will. Das geschieht typischerweise, wenn kein qualifizierter Facilitator verfügbar ist oder ein Owner den Facilitator als zu langsam oder zu methodisch empfindet. Der Owner beginnt dann zugleich Tafeln zu führen, Diskussionen zu moderieren und Entscheidungen zu treffen. Das scheitert aus strukturellen Gründen. Facilitation erfordert volle Aufmerksamkeit auf den Prozess. Entscheidungsfindung erfordert volle Aufmerksamkeit auf den Inhalt. Beides gleichzeitig verschlechtert beides. Ein Owner ohne qualifizierten Facilitator sollte entweder die Aktivierung stoppen und einen solchen beschaffen oder die Abweichung ausdrücklich dokumentieren und anerkennen, dass die Qualitätsgarantien von P-DRIVEN damit geschwächt sind. ### Der Facilitator wird zum Domänenexperten Das komplementäre Fehlmuster ist ein Facilitator, der während der Problemlösungsphasen beginnt, Domänenexpertise einzubringen. Besonders häufig geschieht das, wenn der Facilitator selbst tiefes technisches Wissen über die betroffene Domäne hat. Sobald der Facilitator in den Inhalt eintritt, endet die Prozessdurchsetzung. Die Tafeln erhalten weniger Aufmerksamkeit, Zeitdisziplin erodiert und die Legitimität des Veto-Rechts wird untergraben. Der Facilitator darf generalistische Einwände einbringen – Annahmen hinterfragen, Lücken markieren, als *advocatus diaboli* auftreten. Domänenspezifische Expertise darf aber nicht sein primärer Beitrag werden. Sobald er für eine konkrete technische oder operative Lösung argumentiert, zerfällt die Rollentrennung. ### Domain Owner verlassen das CMT In skalierten Aktivierungen bilden Domain Owner die Unterstützungsstruktur des CMT. Sie halten die Verbindung zwischen strategischer Planung im CMT und operativer Umsetzung im DRT. Wenn Domain Owner das CMT während dessen Planungsphase physisch verlassen, um Domänenthemen direkt zu steuern, veraltet das Lagebild des CMT. Domain Owner sind während der Planungsphase des CMT dort, um Entscheidungen auf CMT-Ebene zu informieren und Ziele zurück in ihre DRTs zu tragen. Sie setzen in dieser Phase nicht auf Domänenebene um. ### Hierarchische Übersteuerung des Prozesses In Organisationen mit stark ausgeprägter Rang- und Autoritätskultur kann es zu hierarchischer Übersteuerung kommen: Eine ranghohe Person betritt den Raum, umgeht den strukturierten Prozess, erteilt direkte Anweisungen und verschwindet wieder. Der Schaden ist strukturell: Die Tafeln repräsentieren nicht mehr das autoritative Lagebild. Der Crisis Owner ist dafür verantwortlich, das Team vor solcher Übersteuerung zu schützen. Die in Teil IV beschriebene Schnittstelle zur Organisationsleitung existiert genau zu diesem Zweck. Abweichungen davon sind als strukturelle Vorfälle zu behandeln und nicht stillschweigend zu absorbieren. --- # Teil VI — Transfer und Grenzen von P-DRIVEN P-DRIVEN wurde für Organisationen entwickelt, die eine verlässliche und skalierbare Struktur für das Management von Notfällen und Krisen benötigen – vor allem in organisatorischen und IT-bezogenen Kontexten. Dieser Teil behandelt, wie die Methode in unterschiedliche organisationale Umfelder übertragen werden kann, welche Voraussetzungen ihre Wirksamkeit stützen, wo ihre Grenzen liegen und wann sie nicht eingesetzt werden sollte. ## Übertragung von P-DRIVEN in unterschiedliche Organisationskontexte P-DRIVEN ist nicht sektorspezifisch. Sein Kern – Problemlösungs-P, Drei-Tafel-Methode, doppelte Führungsstruktur und Prinzip der Personenidentität – lässt sich überall anwenden, wo Teams unter Unsicherheit und hohen Einsätzen koordinierte Entscheidungen treffen müssen. Die Methode wurde in IT-Incident-Response, organisatorischem Krisenmanagement und standortübergreifenden Betriebsstörungen angewendet. Transfer erfordert jedoch bewusste Anpassung. Nicht Anpassung der Methode – ihre Prinzipien sind nicht verhandelbar –, sondern Anpassung ihrer Einführung: Maßstab, Nomenklatur, Schnittstellen und Aktivierungsschwellen. ### Maßstab Eine große Organisation mit mehreren Geschäftsbereichen, geografischer Verteilung und Tausenden Mitarbeitenden benötigt typischerweise eine CMT–DRT–ORT-Struktur mit sorgfältiger Aufmerksamkeit für Ketten persönlicher Identität und Synchronisation zwischen Ebenen. Ein mittelgroßes Unternehmen aktiviert für die meisten Notfälle vielleicht nur ein einzelnes DRT und braucht nur selten ein CMT. Eine kleine Organisation kann mit einem einzelnen Team von vier bis sechs Personen arbeiten, das das Problemlösungs-P ohne formale Mehr-Ebenen-Struktur nutzt. Die Methode skaliert nach unten ebenso wie nach oben. Ein Zweierteam, das mit einer einzelnen Tafel einen strukturierten Problemlösungszyklus durchläuft, wendet P-DRIVEN an. Die Struktur ist minimal, aber die Kernlogik bleibt erhalten. Konkret gilt: - **Skaliert nach unten:** Die Zahl der Tafeln kann reduziert werden. Eine kleine Gruppe, die ein einzelnes Problem bearbeitet, kann mit einer Tafel auskommen, die Problemidentifikation, Strategiewahl und Zielverfolgung bündelt. Die Zahl der Domänen kann auf eine reduziert werden. Der Lagevortrag kann auf eine knappe verbale Zusammenfassung reduziert werden. Die Iteration kann kürzer werden. - **Skaliert nicht nach unten:** Die doppelte Führung aus Owner und Facilitator ist das strukturelle Minimum. Eine einzelne Person kann nicht gleichzeitig Owner und Facilitator sein, ohne die Struktur zu kompromittieren. Die Abfolge des Problemlösungs-P ist unabhängig von der Teamgröße nicht verhandelbar – Schritte dürfen schneller laufen, aber nicht entfallen. Das Veto-Recht bleibt bestehen. - **Ausdrücklich als degradierter Zustand:** Wenn eine Organisation P-DRIVEN ohne getrennten Facilitator betreibt, ist das eine bewusste Abweichung. Veto-Mechanismus und Prozessdurchsetzung sind strukturell geschwächt. Für sehr kleine Teams mag dies ein vertretbarer Tausch sein, er muss aber bewusst dokumentiert werden. Die Regeln zur Domänenzusammenlegung aus Teil I geben zusätzliche Orientierung für kleine Organisationen, die nicht alle Domänen separat besetzen können. ### Nomenklatur P-DRIVEN spezifiziert Rollen- und Teambezeichnungen aus seiner eigenen Logik heraus. Organisationen mit etablierter Begriffswelt – etwa „Incident Commander“, „Gold Team“ oder „Krisenzelle“ – können ihre Sprache auf die P-DRIVEN-Struktur abbilden, statt sie aufzugeben. Diese Zuordnung muss ausdrücklich und dokumentiert erfolgen. Was Organisationen vermeiden müssen, ist eine Benennung, die die strukturelle Logik verfälscht. Einen ranghohen Manager „Owner“ zu nennen, obwohl diese Person dem Problemlösungs-P nicht folgen wird, stiftet Verwirrung ohne Nutzen. Wichtiger als der Name ist die Struktur. ### Regulatorische und Compliance-Kontexte Einige Organisationen arbeiten unter regulatorischen Anforderungen, die bestimmte Incident-Management-Strukturen vorschreiben. P-DRIVEN ist damit kompatibel, ersetzt aber nicht die formalen Melde- und Dokumentationspflichten. Die Aktivierung von P-DRIVEN erzeugt als Nebenprodukt des Prozesses Dokumentation, die regulatorische Anforderungen unterstützen kann. Wo regulatorische Rahmenwerke bestimmte Eskalationsschwellen oder Meldefristen vorschreiben, werden diese zu Aktivierungskriterien und externen Schnittstellenanforderungen der P-DRIVEN-Struktur – nicht zu deren Ersatz. ### Externe Unterstützung und Coaching Organisationen, die P-DRIVEN erstmals einführen, sollten nicht erwarten, bereits nach der ersten Übung voll einsatzfähig zu sein. Die Methode verlangt geübte Kompetenz, insbesondere in der Rolle des Facilitators. Das Lesen von *P-DRIVEN: Arbeitsbuch* erzeugt Verständnis. Übungen unter realitätsnahen Bedingungen erzeugen Können. Wo noch keine qualifizierten internen Facilitators verfügbar sind, ist es für erste Übungen und die ersten realen Aktivierungen dringend zu empfehlen, einen externen methodischen Coach einzubinden. Ein externer Facilitator kann den Prozess führen, während interne Kräfte beobachten und eigene Kompetenz aufbauen. Das ist eine Übergangslösung, keine dauerhafte Auslagerung. ## Roadmap zur Einführung Die Einführung von P-DRIVEN ist ein Projekt. Sie erfordert ein Mandat, definierte Verantwortlichkeiten, Ressourcen und eine strukturierte Schrittfolge. Die folgende Roadmap beschreibt den typischen Weg von der Einführungsentscheidung bis zur operativen Einsatzbereitschaft. Die Roadmap ist kein starres Projektmodell. Organisationen unterscheiden sich in Größe, Reife und Risikoprofil. Die Abfolge ist dennoch wichtig: Jeder Schritt baut auf Ergebnissen des vorherigen auf. Wer Schritte überspringt, erzeugt Lücken, die in der ersten realen Aktivierung sichtbar werden. ### Schritt 1: Mandat und Projektstart Die Einführung beginnt mit einem ausdrücklichen Mandat durch die Organisationsleitung. Ohne dieses Mandat fehlt dem Projekt die Autorität, Rollen zu definieren, Befugnisse zuzuweisen und bereichsübergreifend Anforderungen zu setzen. ### Schritt 2: Struktur und Rollen definieren In diesem Schritt werden Geltungsbereiche, Domänen, Teamstrukturen, Rollenprofile, Befugnisse und Schnittstellen festgelegt. Die doppelte Führungsstruktur muss ausdrücklich in die Organisation übersetzt werden. ### Schritt 3: Erste Schulung und erste Übungen Sobald Struktur und Rollen stehen, beginnt die Qualifikation. Facilitators brauchen die intensivste Vorbereitung. Owners und Supporter müssen die Logik der Methode einüben. Erste Übungen sollten früh erfolgen, auch wenn noch nicht alle Elemente perfekt ausgebildet sind. ### Schritt 4: Ausstattung und Dokumentation Mit der Prozessstruktur ausgestattet, rüstet sich die Organisation für die Aktivierung: 1. **Krisenstabsraum oder Notfallraum:** Raum identifizieren und vorbereiten. 2. **Tafeln:** Drei beschreibbare Flächen beschaffen und aufbauen. 3. **Kommunikationsmittel:** Dedizierte Mobiltelefone, dedizierte E-Mail-Konten, mobile Internetverbindung und Alarmierungssystem beschaffen. 4. **IT-Ausstattung:** Dedizierte Laptops unabhängig von der Domäneninfrastruktur beschaffen und konfigurieren. 5. **Dokumentation:** Zwei Kerndokumente erstellen: - *P-DRIVEN: Leitfaden für die Lage* als kompakte Referenz für aktive Einsätze, - ein **Organisationshandbuch** für Notfall- und Krisenmanagement als strukturelles Grunddokument. 6. **Playbooks:** Für wiederkehrende Szenarien knappe Playbooks erstellen. Diese sind Inputs für P-DRIVEN, nicht sein Ersatz. **Ergebnis dieses Schritts:** Ausgestatteter Raum, Kommunikations- und IT-Ausstattung vorhanden, *P-DRIVEN: Leitfaden für die Lage* und Organisationshandbuch erstellt, erste Playbooks verfügbar. ### Schritt 5: Übungen und kontinuierliche Verbesserung Das System ist nun strukturell vollständig. Operativ wird es durch konsequente Übung und Pflege: 1. **Übungsprogramm:** Regelmäßige Übungen etablieren. Minimum: zweimal pro Jahr pro Rolle. Sinnvolle Startformate: - **Monatliche Tabletop-Übungen** mit geringem Aufwand, - **quartalsweise Funktionsübungen** mit externem Coaching. 2. **Verbesserungszyklus nach Übungen:** Jede Übung erzeugt Debriefing und strukturiertes Feedback. Deren Ergebnisse müssen nachverfolgt werden. 3. **Jährliche Systemüberprüfung:** Einmal jährlich alle Komponenten überprüfen: Rollen, Kontaktlisten, Ausstattung, Aktivierungskriterien, Befugnisse, Playbooks und *P-DRIVEN: Leitfaden für die Lage*. 4. **Übergang zur Selbstständigkeit:** Wurde externes Coaching genutzt, sollte die Organisation innerhalb des ersten Jahres dazu übergehen, vollständige Übungen ohne externe Unterstützung durchführen zu können. **Ergebnis dieses Schritts:** Laufendes Übungsprogramm, etablierter Verbesserungszyklus, terminierte Jahresüberprüfung. ### Der Systemverantwortliche Die Einführung von P-DRIVEN ist ein Projekt. Die Pflege von P-DRIVEN ist eine Daueraufgabe. Organisationen benötigen eine benannte Person, die das System zwischen den Aktivierungen verantwortet. Diese Rolle wird als **Systemverantwortlicher** bezeichnet. Der Systemverantwortliche ist keine Aktivierungsrolle. Er erscheint nicht in der Teamstruktur während eines Notfalls oder einer Krise, auch wenn dieselbe Person zusätzlich eine Aktivierungsrolle innehaben kann. Er ist der Friedenszeit-Verantwortliche des gesamten Notfall- und Krisenmanagementsystems. **Verantwortlichkeiten:** - Administrative Pflege und Weiterentwicklung des Notfall- und Krisenmanagementsystems - Pflege und Aktualisierung aller Dokumente - Planung, Durchführung und Nachbereitung von Übungen - Organisation von Schulungs- und Qualifizierungsmaßnahmen - Regelmäßige Berichterstattung an die Organisationsleitung - Beratung der Domänen in Fragen des Notfall- und Krisenmanagements - Koordination jährlicher und ereignisbezogener Systemüberprüfungen - Nachverfolgung von Verbesserungsmaßnahmen aus Übungen und realen Aktivierungen **Befugnisse:** - Zugang zu allen Informationen und Dokumenten, die für das System relevant sind - Befugnis, Beiträge aus allen Domänen anzufordern - Befugnis, auf Basis eines von der Organisationsleitung genehmigten Plans Übungen und Überprüfungen einzuleiten - Recht, an CMT- oder DRT-Sitzungen während Aktivierungen teilzunehmen - Recht, der Organisationsleitung Anpassungen und Verbesserungen vorzuschlagen **Kompetenzanforderungen:** - Solide Kenntnisse des Notfall- und Krisenmanagements einschließlich relevanter Standards - Qualifikation als Facilitator - Fähigkeit zu systematischer Dokumentations- und Prozesspflege - Organisatorische und kommunikative Kompetenz - Fähigkeit, Übungen zu moderieren und zu unterstützen - Integrität, Diskretion und Beharrlichkeit **Ziele:** - Sicherstellen, dass das Notfall- und Krisenmanagementsystem aktuell, wirksam und transparent ist - Organisatorische Resilienz durch geübte und dokumentierte Prozesse fördern - Eine Kultur kontinuierlicher Verbesserung etablieren - Zur Risikominimierung und organisatorischen Bereitschaft beitragen Der Systemverantwortliche ist häufig die Person, die das Einführungsprojekt angestoßen hat. Die Rolle erfordert in den meisten Organisationen keine Vollzeitstelle, wohl aber ausdrückliche Beauftragung, geschützte Zeit und organisatorische Rückendeckung. ## Voraussetzungen für wirksame Nutzung P-DRIVEN kann ohne bestimmte organisatorische und persönliche Grundlagen nicht wirksam werden. Diese sind keine ergänzenden Anforderungen, sondern strukturelle Voraussetzungen. Eine Organisation, die P-DRIVEN ohne sie installiert, hat ein dokumentiertes, aber kein einsatzfähiges System. ### Qualifiziertes Personal Alle Aktivierungsrollen erfordern Qualifikation durch Übungen, nicht nur durch Lesen. Die Tiefe dieser Qualifikation variiert je Rolle – Facilitators benötigen die intensivste Vorbereitung, Owners müssen den Prozess verinnerlichen, Supporter Tafellogik und Befugnisrahmen verstehen. Mindestübungshäufigkeit: zweimal pro Jahr je Rolle. Das ist nicht optional. ### Organisatorische Autorisierung P-DRIVEN arbeitet als besondere Aufbauorganisation mit Befugnissen, die von der Linienorganisation abweichen. Diese Befugnisse müssen vor einer Aktivierung formell definiert sein. Eine Organisation, die Budgetbefugnisse, Weisungsbefugnisse und Entscheidungsautonomie des Krisenteams nicht vorab autorisiert hat, wird feststellen, dass jede wesentliche Entscheidung außerhalb des Teams eskaliert werden muss – und damit der Sinn der Struktur entfällt. ### Offene Fehlerkultur Die Lernschleife von P-DRIVEN erzeugt nur dann Verbesserung, wenn Beteiligte Beobachtungen ohne Angst vor persönlicher Sanktion einbringen können. In Organisationen, in denen Fehlerbenennung als Schuldzuweisung gilt, produziert die Lernphase bereinigte Ergebnisse, die Menschen schützen, aber das System nicht verbessern. Eine offene Fehlerkultur ist kein kultureller Luxus, sondern Voraussetzung dafür, dass die Lernschleife funktioniert. ### Systempflege Das P-DRIVEN-System muss zwischen Aktivierungen gepflegt werden. Rollenbesetzungen ändern sich, Kontaktdaten veralten, Ausrüstung muss geprüft und aktualisiert werden, Playbooks müssen an die aktuelle operative Realität angepasst werden. Mindeststandard ist eine jährliche Überprüfung aller Rollen, Kontaktdaten, Ausrüstung und Pläne. Ereignisbezogene Überprüfungen folgen auf jede reale Aktivierung, jede Übung und jede wesentliche strukturelle Veränderung in der Organisation. ## Ausdrückliche Grenzen von P-DRIVEN ### P-DRIVEN liefert keine Lösungen P-DRIVEN ist ein Rahmen für Entscheidungsfindung und Koordination. Es liefert Struktur dafür, wie ein Team eine Lage verarbeitet, Entscheidungen trifft und die Umsetzung nachverfolgt. Es sagt dem Team nicht, *was* konkret zu tun ist. Die Qualität der innerhalb von P-DRIVEN getroffenen Entscheidungen hängt vollständig von Domänenwissen, technischer Kompetenz und Lagebewusstsein der beteiligten Personen ab. Eine Organisation, deren Fachpersonal einen IT-Infrastrukturausfall nicht beheben kann, wird dies nicht allein durch P-DRIVEN schneller können. Die Methode verbessert Koordination und reduziert Entscheidungsfehler unter Stress – sie ersetzt keine fehlende Expertise. ### P-DRIVEN benötigt hinreichend Aktivierungszeit Das Problemlösungs-P benötigt Zeit für seine Durchführung. Die erste Iteration der Planungsphase erfordert typischerweise zwischen 30 und 60 Minuten. Das ist keine Schwäche, sondern die notwendige Investition, um koordinierte und nachvollziehbare statt fragmentierter und unkoordinierter Umsetzung zu erzeugen. Es bedeutet aber auch, dass P-DRIVEN nicht für Situationen geeignet ist, in denen sofortiges reflexhaftes Handeln notwendig ist. Für zeitkritische Erstmaßnahmen – erste Eindämmung, Notabschaltungen, Erste-Hilfe-Entscheidungen – aktiviert sich P-DRIVEN im Anschluss an diese Maßnahmen, nicht an ihrer Stelle. ### P-DRIVEN managt die Lage nicht von allein Die Tafeln, die Struktur und die Iteration erzeugen ohne menschliches Urteil kein Ergebnis. Lagefeststellung erzeugt nur dann eine brauchbare Problemliste, wenn Beteiligte sorgfältig denken und offen sprechen. Lagebewertung erzeugt nur dann eine belastbare Priorisierung, wenn das Team Auswirkungen und Dringlichkeit ehrlich bewertet. Zieldefinition erzeugt nur dann handlungsfähige Ziele, wenn das Team klar benennen kann, was erreicht werden muss. P-DRIVEN liefert Struktur. Es hebt die Notwendigkeit klaren Denkens nicht auf. ### Informationsprobleme werden durch den Prozess nicht gelöst Krisen sind durch ein doppeltes Informationsproblem gekennzeichnet: gleichzeitig zu wenig verlässliche Information und zu viel unzuverlässige Information. Die iterative Struktur von P-DRIVEN geht damit besser um als viele Alternativen, weil Entscheidungen regelmäßig überprüft und aktualisiert werden. Sie hebt Informationsknappheit aber nicht auf. Organisationen, die in Umgebungen mit schlechter Informationsinfrastruktur arbeiten – also dort, wo Systeme keine brauchbare Telemetrie liefern, Schlüsselpersonen nicht verfügbar sind oder externe Abhängigkeiten nicht schnell kontaktiert werden können –, erleben dieses Problem besonders stark. P-DRIVEN steuert Unsicherheit, beseitigt sie nicht. ### Empirische Grundlage P-DRIVEN beruht auf Praktikererfahrung und strukturierter Designlogik, nicht auf kontrollierten empirischen Studien. Seine Gestaltungsentscheidungen greifen etablierte Konzepte aus Notfallmanagement, Organisationsgestaltung und Entscheidungswissenschaft auf. Die Methode wurde durch reale Anwendung in Notfall- und Krisenmanagement über mehrere Organisationen hinweg entwickelt und geschärft. *P-DRIVEN: Arbeitsbuch* dokumentiert die Methode in ihrer gestalteten Form. Empirische Beobachtungen, Fallstudien und praktische Einführungserfahrungen werden auf [p-driven.org](https://p-driven.org) veröffentlicht. ## Wann P-DRIVEN nicht eingesetzt werden sollte ### Situationen, die unmittelbare Reflexhandlung erfordern Einige Lagen verlangen die sofortige Ausführung vordefinierter Reaktionsverfahren: Feueralarm löst Evakuierung aus, ein technischer Alarm löst ein automatisiertes Eindämmungsskript aus, ein medizinischer Notfall löst einen Erste-Hilfe-Prozess aus. Das sind keine Lagen für P-DRIVEN. Das sind Lagen für trainierte Reflexe und vorab autorisierte Verfahren. P-DRIVEN aktiviert sich, nachdem die erste Reflexhandlung erfolgt ist und die Organisation bewerten, koordinieren und eine Reaktion aufrechterhalten muss. ### Situationen, die vollständig durch bestehende Verfahren abgedeckt sind Wenn eine Lage vollständig durch ein bestehendes Verfahren abgedeckt ist – das Playbook beschreibt den Zustand präzise, Reaktionshandlungen sind eindeutig, verantwortliche Personen klar benannt und keine domänenübergreifende Koordination ist nötig –, dann fügt P-DRIVEN Aufwand ohne Nutzen hinzu. In diesem Fall sollte das Verfahren angewendet werden. P-DRIVEN ist für Lagen gedacht, in denen unklar ist, welches Verfahren greift, mehrere Szenarien überlappen, domänenübergreifende Koordination nötig ist, das Playbook nicht passt oder die Lage die Routinekapazität übersteigt. ### Situationen, in denen die doppelte Führung nicht besetzt werden kann P-DRIVEN ohne qualifizierten Facilitator ist strukturell geschwächt. Wenn kein qualifizierter Facilitator verfügbar ist und auch kein externer Coach hinzugezogen werden kann, liegt eine echte Fähigkeitslücke vor. Unter diesen Bedingungen mit P-DRIVEN fortzufahren, ist möglich, aber Veto-Mechanismus, Prozessdurchsetzung und Dokumentationsqualität sind kompromittiert. Die ehrliche Entscheidung ist in diesem Fall, die Lücke ausdrücklich anzuerkennen, statt so zu tun, als sei die Methode intakt. ### Routinekoordination und normales Projektmanagement P-DRIVEN ist für Lagen entworfen, die die Routinemanagementkapazität überschreiten: hohe Unsicherheit, hoher Einsatz, bereichsübergreifende Koordination, Zeitdruck und unvollständige Information. Es ist keine allgemeine Koordinations- oder Projektmanagementmethode. Organisationen, die P-DRIVEN für Routinekoordination, kleine Störungen innerhalb normaler Reaktionsfähigkeit oder Projektmanagementaufgaben aktivieren, setzen Aufmerksamkeit falsch ein und erzeugen schlechte Gewohnheiten. Die Methode muss mit den Bedingungen verbunden bleiben, für die sie entworfen wurde. P-DRIVEN sollte für Lagen reserviert bleiben, die es wirklich erfordern. Die Aktivierungsschwelle muss bedeutungsvoll bleiben. --- # Glossar | Begriff | Bedeutung | |---|---| | **Aktivierung** | Die formelle Erklärung, dass eine Notfall- oder Krisenmanagementstruktur operativ ist. Aktivierung schafft ausdrückliche Autorität, Rollenzuweisung und Prozessdisziplin. Sie wird durch die Erstbewertung ausgelöst und endet mit der Deaktivierungsentscheidung des Owners, vorbehaltlich des Vetos des Facilitators. | | **Advocatus Diaboli** | Eine Rolle, die der Facilitator innerhalb des Problemlösungs-P vorübergehend einnehmen kann: Annahmen bewusst herausfordern, Schlüsse hinterfragen und alternative Interpretationen einbringen, ohne domänenspezifische Inhalte beizusteuern. | | **Tafel 1 (Problemtafel)** | Das visuelle Instrument für Lagefeststellung und Lagebewertung. Es erfasst identifizierte Probleme als Einzelkarten, clustert sie und priorisiert sie mit einer Eisenhower-Matrix. | | **Tafel 2 (Strategietafel)** | Das visuelle Instrument für die Entscheidungsfindung. Für jedes priorisierte Problem von Tafel 1 werden mindestens drei unterschiedliche Lösungsstrategien entwickelt, bewertet und ausgewählt. | | **Tafel 3 (Umsetzungstafel)** | Das visuelle Instrument der Umsetzungsphase. Es verfolgt alle Ziele mit verantwortlichen Personen und Status. Nur der Facilitator bewegt Karten auf Tafel 3. | | **CMT (Crisis Management Team)** | Das strategische Koordinationsteam, das aktiviert wird, wenn die Lage die Kapazität einer einzelnen Domäne überschreitet. Das CMT koordiniert über Domänen hinweg und setzt strategische Richtung. Es besteht aus Crisis Owner, Crisis Facilitator und Domain Ownern. | | **Krisenstabsraum / Notfallraum** | Der definierte physische oder virtuelle Ort, an dem das Team während einer Aktivierung zusammenkommt. Ausgestattet mit Tafeln, Kommunikationsmitteln und Dokumentationswerkzeugen. Der Facilitator bleibt während der Umsetzungsphase dort. | | **Deaktivierung** | Die formelle Erklärung, dass Notfall oder Krise beendet sind und die Aktivierungsstruktur aufgelöst wird. Sie wird durch den Owner entschieden, vorbehaltlich des Vetos des Facilitators, und löst die Lernphase aus. | | **Domain Owner** | Ein Teammitglied, das für einen bestimmten funktionalen Bereich innerhalb des CMT verantwortlich ist. Über das Prinzip der Personenidentität fungiert der Domain Owner zugleich als Owner des entsprechenden DRT. | | **DRT (Domain Response Team)** | Ein taktisches Team, das innerhalb einer bestimmten Domäne unter Koordination des CMT arbeitet. Geführt durch Domain Owner und Domain Facilitator. Das DRT durchläuft das Problemlösungs-P eigenständig innerhalb seines Domänengeltungsbereichs. | | **Eskalation** | In P-DRIVEN bezeichnet Eskalation ausdrücklich den formellen, strukturellen Übergang vom Notfallmanagement auf Krisenniveau: Ein IMT wird zum CMT eskaliert, wenn der Problemumfang Domänengrenzen überschreitet oder strategische Ziele gefährdet sind. | | **Facilitator** | Die für methodische Führung verantwortliche Person. Moderiert das Problemlösungs-P, pflegt die Tafeln, erzwingt Methodendisziplin und hält das Veto-Recht. Besitzt keine Entscheidungsautorität über Inhalte. | | **Bewusste Abweichung** | Eine bewusste Abweichung von den definierten Strukturen, der Abfolge oder den Prinzipien von P-DRIVEN. Sie ist keine Variante, sondern eine ausdrücklich anerkannte Abweichung. Die Beweislast für ihre Wirksamkeit liegt bei der Organisation, die sie übernimmt. | | **IMT (Incident Management Team)** | Das Team, das für einen Notfall innerhalb einer einzelnen Domäne aktiviert wird. Wenn kein CMT existiert, arbeitet das IMT selbstständig. Strukturell ist es einem DRT gleich, nur ohne übergeordnete CMT-Koordination. | | **Iteration** | Ein vollständiger Durchlauf von Planungsphase → Umsetzungsphase → nächster Planungsphase. Die Länge wird in der Zielzuweisung festgelegt und bestimmt den Takt der Aktivierung. Typische Dauer auf DRT-Ebene: zwei bis vier Stunden. | | **LRT (Location Response Team)** | Ein Team, das die Krisenreaktion an einem bestimmten geografischen Standort koordiniert. LRTs sind in Mehrstandortkrisen dem CMT nachgeordnet und durchlaufen das Problemlösungs-P eigenständig innerhalb seines geografischen Geltungsbereichs. | | ***P-DRIVEN: Leitfaden für die Lage*** | Das kompakte, maßgebliche Referenzdokument für aktive Notfälle und Krisen. Es enthält Prozessschritte, Tafelvorlagen, Vortragsstrukturen, Rollenzusammenfassungen und Checklisten. Bewusst frei von Erläuterungen. | | **ORT (Operational Response Team)** | Ein Unterteam eines DRT, das gebildet wird, wenn der Umfang einer einzelnen Domäne das übersteigt, was ein Team alleine steuern kann. ORTs bearbeiten spezifische operative Teilbereiche und berichten an das DRT. | | **Owner** | Die für die fachliche Führung verantwortliche Person. Trifft Entscheidungen an definierten Punkten, hält den Lagevortrag und trägt Verantwortung für Ergebnisse. Auf DRT-Ebene: Incident Owner. Auf CMT-Ebene: Crisis Owner. | | **Prinzip der Personenidentität** | Das Strukturprinzip, nach dem dieselbe Person sowohl Domain Owner im CMT als auch Owner des entsprechenden DRT ist. So bleiben strategische Entscheidung und taktische Umsetzung über eine einzelne verantwortliche Person verbunden. | | **Problemlösungs-P** | Der strukturierte Prozess im Kern von P-DRIVEN. Er besteht aus vier Phasen: Initiierung, Planung, Umsetzung und Lernen. Sein Name leitet sich aus der P-förmigen visuellen Darstellung seines iterativen Verlaufs ab. | | **Supporter** | Eine Person mit spezifischer Domänenexpertise, die vorübergehend in ein DRT, LRT oder ORT integriert wird, um an definierten Zielen zu arbeiten. Auf CMT-Ebene existieren Supporter nicht. Sie haben keine eigenständige Weisungsbefugnis, außer diese wurde ausdrücklich durch den Owner delegiert. | | **Systemverantwortlicher** | Die Friedenszeitrolle, die für die Pflege des Notfall- und Krisenmanagementsystems verantwortlich ist: Dokumentation, Ausstattung, Übungen, Rollenbesetzungen und kontinuierliche Verbesserung. Keine Aktivierungsrolle. | | **Drei-Tafel-Methode** | Das visuelle Planungs- und Nachverfolgungssystem innerhalb des Problemlösungs-P. Es besteht aus Tafel 1, Tafel 2 und Tafel 3. Die drei Tafeln bilden eine nachvollziehbare Kette von Problemidentifikation über Strategiewahl bis zur Zielverfolgung. | | **Veto-Recht** | Die ausdrückliche Autorität des Facilitators, Entscheidungen oder Handlungen des Owners zu blockieren, wenn diese gegen etablierte Methodik, definierte Verfahren oder formale Befugnisse verstoßen. Das Veto wird dokumentiert und bleibt bindend, bis der Owner es mit ausdrücklicher, schriftlicher Begründung überstimmt. |