Back to GXP-Lifeline home page

Prozesse sind fehleranfällig, Menschen nicht

by Terry Smith, Lean Enterprise Institute | Sep 05, 2017
Wenn eine Situation schief läuft, 
sehen Sie sich Ihren Prozess an und suchen Sie nach den Ursachen.
Hier ein mögliches Anwendungsszenario: Sobald ein Problem auftritt, berufen Sie ein 5-Why-Meeting mit allen Beteiligten ein und der Meeting-Verantwortliche stellt fünfmal die Frage: "Warum ist das passiert?" Während das Team das Problem erörtert, notiert er sämtliche Antworten. Dadurch wird das Problem aus jeder Sichtweise betrachtet und die gesamte Ereigniskette lässt sich wiederherstellen.

Fall Nr. 1: Freemake
Freemake ist ein Multimedia-Start-up. Mit den Apps des Unternehmens lassen sich YouTube-Videos streamen. Im Februar 2015 fiel YouTube jedoch aus und Freemake zeigte eine Fehlermeldung anstatt der Streaminginhalte an. Also durchlief das Unternehmen eine 5-Why-Sitzung:
 
1. Frage: Warum zeigte die Freemake-Software eine Fehlermeldung an?
Antwort: Weil YouTube nicht verfügbar war.

2. Frage: Warum war der YouTube-Streamingdienst nicht verfügbar?
Antwort: Weil YouTube ausgefallen ist und uns keine Inhalte zum Anzeigen zur Verfügung standen.

3. Frage: Warum zeigte Freemake nichts an?
Antwort: Weil wir uns des YouTube-Ausfalls nicht bewusst waren und eine Standardnachricht angezeigt haben.

4. Frage: Warum wussten wir nichts von dem YouTube-Ausfall?
Antwort: Weil wir kein Warn- und Benachrichtigungssystem besitzen.
.
5. Frage: Warum besaßen wir kein Warn- und Benachrichtigungssystem für den Streamingdienst?
Antwort: Weil wir keine Qualitätssicherungstests für Notfallsituationen durchführen.
 
Die Antworten des Teams sind neutral und deutlich. Sie weisen kein Wunschdenken wie "Wir hätten zweimal überlegen müssen". Es gibt kein böses Blut und keine Schuldzuweisungen. Wenn Sie die fünfte Antwort betrachten, können Sie klar einen Prozessfehler erkennen. Der Qualitätssicherungsprozess von Freemake schlug fehl, was zu einer negativen Kundenerfahrung führte. Die Lösung? Ein System für die Nachverfolgung in Echtzeit und benutzerfreundlichere Warnmeldungen zu möglichen Streamingproblemen mussten erstellt werden. Victoria Kushner, Senior Marketing Manager bei Freemake: "Es wäre einfach gewesen, unserem Entwicklungsteam die Schuld zu geben. Doch der Ruf unseres Unternehmens hatte Schaden genommen und uns war bewusst, dass eine systematische Lösung von Nöten war."
 
White Paper
Dieser Artikel bezieht sich auf das Whitepaper
Simplifying CAPA: Seven Steps
Alle ausführlichen Informationen Anzeigen Ihr kostenloses White Paper.
 

Fall Nr. 2: Buffer

Sehen wir uns nun den Fall von Buffer an – einem Unternehmen, das einen Service für die Social-Media-Verwaltung bereitstellt. 2014 kam es bei dem Service zu einem kurzen systemweiten Ausfall. Laut eigenen Angaben des Unternehmens lief die 5-Why-Sitzung folgendermaßen ab:
 
1. Frage: Warum hatten wir einen Ausfall?
Antwort: Weil die Datenbank gesperrt wurde.

2. Frage: Warum wurde sie gesperrt?
Antwort: Weil zu viele Schreibvorgänge in der Datenbank durchgeführt wurden.

3. Frage: Warum haben wir zu viele Datenbankschreibvorgänge durchgeführt?
Antwort: Wir haben diesen Fall nicht vorhergesehen und haben vorab keine Tests dazu durchgeführt.

4. Frage: Warum wurde die Änderung nicht getestet?
Antwort: Weil wir über keinen Entwicklungsprozess verfügen, in dem festgelegt ist, wann Änderungen getestet werden müssen.

5. Frage: Warum haben wir keinen Entwicklungsprozess, in dem festgelegt ist, wann ein Lasttest durchgeführt werden muss?
Antwort: Wir haben nie umfassende Lasttests durchgeführt und erreichen momentan eine vollkommen neue Auslastung.
 
Im nächsten Schritt erarbeiteten die Teammitglieder Abhilfemaßnahmen. Einzelne Teammitglieder übernahmen anschließend die Verantwortung für die Implementierung der Abhilfemaßnahmen und neuen Aufgaben. Beachten Sie, dass jede Antwort sich auf ein Problem im Prozess bezog. Es wurden keine Antworten wie "Entwickler X hat Aufgabe Y nicht erledigt" gegeben. Das Team schweifte nicht vom Problem ab, sondern konzentrierte sich darauf, die Ursache zu ermitteln. Die letzte Antwort wies außerdem auf ein Problem mit hoher Priorität hin, und zwar die Tatsache, dass Systeme mit großem Umfang nicht getestet wurden. Dies führte zu einer Verkettung von Ausfällen, die die Kunden und das Geschäft des Unternehmens beeinträchtigten.
 
Was haben beide Fälle gemeinsam? In beiden Fällen haben Teammitglieder effektive Lösungen zur Behebung von fehlerhaften oder zur Entwicklung von nicht vorhandenen Prozessen erarbeitet. Anstatt komplizierter Untersuchungen wurden einfache und transparente Frage-und-Antwort-Meetings abgehalten. Selbstverständlich hat aber auch diese Technik ihre Grenzen. Achten Sie auf allzu häufige Antworten wie „Wir hatten nicht genug Zeit oder Ressourcen“ oder „Wir hätten zweimal überlegen sollen“. Manchmal springen Teammitglieder auch von einer Kategorie von Antworten zu einer anderen. Durch die Anwendung der 5-Why-Methode kommen Sie der Ursache von Problemen deutlich schneller auf die Schliche. Letztendlich können Sie somit früher damit beginnen, Ihr Unternehmen zu verbessern, und können Schuldzuweisungen unter Mitarbeitern vermeiden.

Neuauflage mit Genehmigung des Lean Enterprise Institute.

Terry Smith ist freiberuflicher Webentwickler. Seine Vision ist es, Freiberuflerpraktiken mit Lean-Management-Tools zu verbessern. Terry interessiert sich für Technologie und Schulungen. Er engagiert sich in der StackOverflow-Community und gibt seine Erfahrungen mit Telearbeit weiter. Folgen Sie Terry Smith auf Twitter https://twitter.com/TerrySmith226.





Leave a comment