---
schema_version: "1"
id: 4694bf2a27b8f3ea2e44f2a52ad4944ec13557246b08a015599851987f2edb60
title: Kontinuierliche Verbesserung – Muster
collection: architect
version: current
locale: de-de
portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/operational-excellence-continuous-improvement-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/operational-excellence-continuous-improvement-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: d6cb0c10e6f78bcfddfacdbbfbce0a96a5d4d0c950e8e5031ed50b3c3e4f2b86
products:
  - Gut strukturiertes Framework
  - Architect Site Content Repo
---
# Kontinuierliche Verbesserung – Muster

Weitere Informationen zu Well-Architected [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) → [Continuous Improvement (Kontinuierliche Verbesserung](/docs/architect/de-de/well-architected/guide/operational-excellence.html#continuous-improvement))

## Operative Kennzahlen und DORA

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| DORA | ✅ Bereitstellungshäufigkeit wird verfolgt; die Teams mit der schnellsten Bereitstellung werden nach Bedarf bereitgestellt, oft mehrmals pro Tag |
| Plattform \| DORA | ✅ Die Vorlaufzeit für Änderungen wird vom Code-Commit bis zur Produktionsbereitstellung gemessen. Die Vorlaufzeit unter einem Tag signalisiert eine leistungsfähige Zustellung und die untere Stunde zeigt eine außergewöhnliche Kapazität an |
| Plattform \| DORA | ✅ Die Änderungsfehlerrate wird als Prozentsatz der Bereitstellungen verfolgt, die Produktionsvorfälle verursachen, die behoben werden müssen, und konstant niedrig gehalten |
| Plattform \| DORA | ✅ Die fehlgeschlagene Bereitstellungswiederherstellungszeit wird gemessen; die Wiederherstellung unter einer Stunde signalisiert die Lieferreife |
| Plattform \| DORA | ✅ Die Bereitstellungs-Nacharbeitsrate wird als Verhältnis der ungeplanten Bereitstellungen infolge von Produktionsvorfällen verfolgt |
| Plattform \| DORA | ✅ Die Kennzahlen sind nach Durchsatzfaktoren (Vorlaufzeit, Bereitstellungshäufigkeit, Wiederherstellungszeit der fehlgeschlagenen Bereitstellung) und Instabilitätsfaktoren (Änderungsfehlerrate, Nacharbeitungsrate) organisiert |
| Plattform \| Kennzahlen | ✅ DORA-Kennzahlen werden kontinuierlich gemessen und im Laufe der Zeit mit einer Verbesserungskurve, die stärker gewichtet wird als absolute Werte |
| Plattform \| Dashboards | ✅ Kennzahlen werden in operativen Dashboards verfolgt, die für die gesamte Organisation sichtbar sind, wodurch Transparenz über die operative Leistung geschaffen wird |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| DORA | ⚠️ Niedrige Bereitstellungshäufigkeit spiegelt die Vermeidung von Bereitstellungsproblemen wider, wodurch ein Teufelskreis entsteht, in dem eine seltene Bereitstellung jede Bereitstellung riskanter macht |
| Plattform \| DORA | ⚠️ Lange Vorlaufzeiten spiegeln übermäßigen Prozess-Overhead, unzureichende Automatisierung oder Organisationsstörungen wider |
| Plattform \| DORA | ⚠️ Eine hohe Fehlerrate bei Änderungen ist auf unzureichende Tests, unzureichende Bereitstellungsvalidierung oder Änderungen zurückzuführen, die ohne ordnungsgemäße Qualitätsprüfungen überstürzt wurden |
| Plattform \| DORA | ⚠️ Lange Wiederherstellungszeiten spiegeln unzureichende Bereitstellungsvalidierung, fehlende automatische Wiederherstellung oder unklare Inhaberschaft von Produktionsvorfällen wider |
| Plattform \| DORA | ⚠️ Eine hohe Überarbeitungsrate zeigt Produktionsvorfälle an, die routinemäßig Notfallbereitstellungen, Signallücken bei Vorproduktionstests, Versionsvalidierung oder Änderungsverwaltung verursachen. |
| Plattform \| Kennzahlen | ⚠️ Kennzahlen werden als Zeitpunkt-Snapshots erfasst und nicht als Trends im Laufe der Zeit, wodurch ausgeblendet wird, ob sich die betriebliche Leistung verbessert oder verschlechtert. |

## Retrospektiven und Rezensionen

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Prozess | ✅ Sprintrückblicke finden regelmäßig (jeden Sprint oder monatlich) statt und schaffen einen Rhythmus zum Nachdenken, statt auf Krisen zu warten |
| Plattform \| Prozess | ✅ Retrospektiven verwenden strukturierte Formate (Start/Stopp/Fortsetzung, Wahnsinnig/Traurig/Glücklich, Zeitachse), die zur Teilnahme und zu handlungsrelevanten Ergebnissen anregen |
| Plattform \| Prozess | ✅ Moderatoren werden rotiert, um zu verhindern, dass eine einzelne Person die Diskussion dominiert |
| Plattform \| Prozess | ✅ Retrospektive Statistiken werden in konkrete Aktionselemente mit Inhabern und Abschlussdaten konvertiert, was zu einer geringen Anzahl von Verbesserungen pro Sitzung führt |
| Plattform \| Prozess | ✅ Der Abschluss von Aktionselementen wird retrospektiv verfolgt, sodass Teams für die Weiterverfolgung verantwortlich sind |
| Plattform \| Vorgänge | ✅ Operationelle Überprüfungen bewerten die aggregierte betriebliche Gesundheit vierteljährlich oder monatlich, untersuchen Trenddaten und vergleichen sie mit Zielen |
| Plattform \| Vorgänge | ✅ Operative Überprüfungen binden die Führung ein, um Ressourcen für operative Verbesserungen zu sichern, die mit der Funktionsentwicklung konkurrieren |
| Plattform \| Vorgänge | ✅ Bewertungen enthalten betriebliche Kennzahlen: Verfügbarkeit im Vergleich zum Ziel nach Journey, Latenztrends nach Perzentil, Anzahl der Vorfälle nach Schweregrad mit mittlerer Erkennungs- und Lösungszeit, Bereitstellungshäufigkeit und Erfolgsrate sowie Betriebslast wie Anrufseiten und Arbeitszeiten |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Prozess | ⚠️ Retrospektiven warten auf Krisen, statt in einem regelmäßigen Rhythmus zu erfolgen |
| Plattform \| Prozess | ⚠️ Retrospektiven generieren lange Diskussionen, aber keine Maßnahmen, Zeitverschwendung und züchten Zynismus |
| Plattform \| Prozess | ⚠️ Aktionselemente werden ohne Inhaber oder Abschlussdatum definiert, sodass Verbesserungen diskutiert, jedoch nie implementiert werden |
| Plattform \| Prozess | ⚠️ Der Abschluss von Aktionselementen wird nie retrospektiv verfolgt, sodass die Weiterverfolgung unbekannt bleibt |
| Plattform \| Vorgänge | ⚠️ Vorgänge werden als unsichtbare Hintergrundarbeit behandelt, die nur in Krisenzeiten beachtet wird, ohne dass eine regelmäßige operative Überprüfung stattfindet |
| Plattform \| Vorgänge | ⚠️ Bei operativen Überprüfungen fehlt es an Führungsengagement, sodass Verbesserungsarbeiten bei der Funktionsentwicklung verloren gehen, wenn Ressourcen zugeteilt werden |

## Überprüfung der Betriebsbereitschaft

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Vorgänge | ✅ Überprüfungen der Betriebsbereitschaft bewerten, ob neue Funktionen oder Systeme die betrieblichen Anforderungen erfüllen, bevor die Produktion gestartet wird |
| Plattform \| Vorgänge | ✅ Überprüfungen werden vor der Produktionsaufnahme neuer Lösungen, wichtiger Funktionen oder architektonischer Änderungen mit Auswirkungen auf den Betrieb durchgeführt |
| Plattform \| Vorgänge | ✅ Der Überprüfungszeitpunkt ist ausgewogen, sodass die Implementierung vollständig genug ist, um eine Bewertung vorzunehmen, ohne dass betriebliche Bedenken zu spät eingehen, um sie zu beheben |
| Plattform \| Überwachung | ✅ Die Überprüfung bestätigt, dass genügend Kennzahlen instrumentiert sind, Warnungen für Fehlerszenarien vorhanden sind und Dashboards den Gesundheitsstatus anzeigen |
| Plattform \| Dokumentation | ✅ Die Überprüfung bestätigt, dass Runbooks für allgemeine Vorgänge vorhanden sind, die Architektur für die Antwortenden dokumentiert ist und die Eskalationsverfahren klar sind |
| Plattform \| Bereitstellung | ✅ Die Überprüfung bestätigt, dass die Bereitstellung zuverlässig ausgeführt wird, ein Rollback-Verfahren vorhanden ist und die Bereitstellung in Staging validiert wurde |
| Plattform \| Leistung | ✅ Die Überprüfung bestätigt, dass die Leistungsziele unter realistischer Last validiert werden, dass Freiräume für Wachstum vorhanden sind und dass die Risiken von Obergrenzen bewertet werden |
| Plattform \| Sicherheit | ✅ Die Überprüfung bestätigt, dass die Sicherheitsüberprüfungen abgeschlossen sind, die Überprüfungsanforderungen erfüllt sind und die Zugriffssteuerung den Anforderungen entspricht |
| Plattform \| Abhängigkeiten | ✅ Die Überprüfung bestätigt, dass externe Abhängigkeiten identifiziert werden, Integrationspartner über Service Level Agreements verfügen und Ausweichverhalten bei Abhängigkeitsfehlern vorhanden ist |
| Plattform \| Governance | ✅ Die Produktionseinführung erfolgt nach Abschluss der Überprüfung, sodass die Bereitstellungsanforderungen für betriebliche Belange und nicht für Best-Feelour-Aktivitäten gelten |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Governance | ⚠️ Neue Funktionen werden ohne Bewertung der Betriebsbereitschaft in die Produktion eingeführt, wodurch sich Betriebsschulden anhäufen, was zukünftige Betriebsexzellenz zunehmend erschwert |
| Plattform \| Vorgänge | ⚠️ Die Überprüfung wird zu spät durchgeführt, sodass betriebliche Bedenken wie Bereitstellungsblocker wirken und Druck erzeugen, Korrekturen zu überspringen |
| Plattform \| Governance | ⚠️ Die Betriebsbereitschaft wird als "beste Anstrengung" und nicht als Bereitstellungsanforderung behandelt |

## Feedbackschleifen und Lernkultur

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Kultur | ✅ Psychologische Sicherheit ermöglicht ehrliche Diskussionen über Probleme, Fehler und Beinahe-Unfälle ohne Angst vor Bestrafung |
| Plattform \| Kultur | ✅ Psychologische Sicherheit entsteht durch schuldlose Obduktionen, das Feiern von Problemen und die Verwundbarkeit von Führungsmodellen, indem ihre eigenen Fehler diskutiert werden |
| Plattform \| Kennzahlen | ✅ Die Messung macht den Betriebszustand durch betriebliche Kennzahlen, Vorfallstrends, DORA-Indikatoren und Benutzerzufriedenheitsbewertungen sichtbar und ermöglicht eine objektive Priorisierung der Verbesserungsarbeit |
| Plattform \| Vorgänge | ✅ Die technische Kapazität ist bewusst für betriebliche Verbesserungen, den Abbau technischer Schulden und Investitionen in Werkzeuge und Automatisierung reserviert |
| Plattform \| Vorgänge | ✅ Feedbackschleifen verbinden die betriebliche Erfahrung mit Designentscheidungen, sodass Vorfälle zu Verbesserungen bei der Architektur führen, die Überwachung die Optimierung vorantreibt und Bereitstellungsfehler zu Verbesserungen bei der Testabdeckung führen |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Kultur | ⚠️ Teams ohne psychologische Sicherheit blenden Probleme aus, bis sie katastrophal werden, wodurch ein frühzeitiges Eingreifen verhindert wird |
| Plattform \| Vorgänge | ⚠️ Teams verwenden alle Kapazitäten für Funktionen, ohne Zeit für operative Verbesserungen zu haben, wodurch technische und betriebliche Schulden angehäuft werden, die schließlich die Krisenreaktion erzwingen |
| Plattform \| Vorgänge | ⚠️ Die Betriebserfahrung wird nicht in das Design zurückgeführt, sodass dieselben Schwächen wiederkehren und sich die Vorgänge allmählich verschlechtern statt verbessern |