Feb
19
Automotive Agile: Kanban im Fehlermanagement
Der Impulsartikel hatte das Ziel Kanban im Automotive Bereich einzuführen. Hier folgt ein Beispiel zu einem Kanban-Board im Bereich des Fehlermanagement. Dabei zeige ich, wie so ein Kanban-Board umgesetzt werden kann. Ich möchte mit einfachen Beispielen beginnen, dabei aber auch die Skalierung nicht aus den Augen verlieren.
Fehlermanagement ist ein Prozessbereich der in dem Prozessverbesserungsmodell Automotive SPICE(R) als SUP.9 “Problem Resolution Management” existiert. Auch ITIL kennt mit Problem Management und Incident Management ähnliche Prozesse. Bei CMMI ist es etwas schwieriger, da es den Prozess so in der Art nicht gibt. Teile davon werden dennoch in anderen Prozessen angesprochen.
Es ist nicht verwunderlich, dass Fehler einen gewissen Stellenwert in diesen Modellen einnehmen – denn Fehler zu machen ist menschlich und gehört zu einem kontinuierlichen Lernen und Verbessern dazu. Ich habe das Fehlermanagement deshalb gewählt, da ein Verständnis für Fehler allgemein vorhanden ist. Die Prozesse zur Behandlung der Fehler sind oft übersichtlich und es gibt eine gute Toolunterstützung.
Doch betrachten wir zunächst einmal wie Fehler bis heute behandelt werden. In großen Organisationen gibt es in der Regel immer eine Toolunterstützung, die es ermöglicht Fehler entgegen zunehmen. Ein adminsitratives und rechtegesteuertes Backend erlaubt die entsprechende Konfiguration. Die Tools haben einen Workflow, der bestimmte Eingabe an den Problem-Berichten (auch -Tickets oder -Reports) erfordert und erwartet. Irgendwann hat so ein Problem-Report dann den Workflow durchlaufen, das Problem wurde behoben und das Ticket geschlossen. Ein bekanntes Open Source Tool ist bspw. Bugzilla. Bei kleineren Unternehmen findet sich oft die klassische Excel-Liste und alles ist mehr informell.
Umsetzung mit Kanban
Bei einer Umsetzung mit Kanban ist es wichtig, dass Sie den bisherigen Prozess nachbilden. Das bedeutet, dass der bislang gelebte Prozess auf ein entsprechendes Board übertragen wird. Um ein Gefühl dafür zu bekommen ist es hilfreich hier mit einem Prototyp zu arbeiten und sich den Prozess zu visualisieren. Dabei ist es von entscheidender Bedeutung, dass Sie sich wirklich Zeit nehmen und einmal den Prozess betrachten. Holen Sie sich Stakeholder herbei und diskutieren Sie den Lauf durch den Prozess. Unheimlich hilfreich ist es ein mögliches Ticket zu beschreiben (oder gar ein existentes aus dem aktuellen Prozess zu nehmen) und das Station für Station durchzuschieben.
Als Beispiel möchte ich Ihnen einen fiktiven Prozess vorstellen. Ohne Umschweife will ich Ihnen den Prozess auch gleich einmal zeigen:
Der vorgestellt Prozess ist einfach: Ein Backlog, eine Entwicklung, der Test und die fertigen Aufgaben. Natürlich gibt es Prozesse die umfangreicher sind. Ist Ihr Prozess anders aufgebaut, dann nutzen Sie die Zeit nach dem Artikel und versuchen Sie ihn doch gleich einmal zu visualisieren!
In diesem Prozess gibt es sogenannte Puffer. Diese Puffer werden immer dann gefüllt, wenn die Akzeptanzkriterien erreicht sind. Bei Ihnen im Tool könnten das z.B. auch Kriterien, Kategorien oder bestimmten Ursachen und Beschreibungen sein, die ausgefüllt sein müssen. Vorher darf dieses Ticket sich nicht bewegen. Die Zahlen oben in den Kreisen sind die WiP Limits – mehr Karten als die Zahl dürfen sich in dem Schritt nicht befinden. Wahrscheinlich wird die Diskussion über die WiP Limits für die größte Diskussion sorgen.
Was ist der Unterschied zum bisherigen Verfahren?
Wenn der gelebte Prozess nachgebildet wird, woran liegt dann genau der Vorteil von Kanban und dem Kanban-Board? Die Frage wird mir öfters gestellt und ich zeige zum Verständnis gerne ein triviales Beispiel. In praktisch allen mir bekannten Umsetzungen des Fehlermanagement mit Toolunterstützung, gibt es Probleme im Schritt Bearbeitung. Diesen Schritt haben alle Tools, denn dort werden die Fehler gelöst. Betrachten Sie dazu linke Abbildung. Tickets werden nach einer Sichtung im System (Kategorisierung oder ähnliche Bezeichnungen) wandern diese in den Schritt Bearbeitung (oder ähnlich), wo sich Entwickler um die Lösung des Problems kümmern.
Die Bearbeitung stellt in der Regel das Problem dar. Wenige Experten bekommen zu viele Tickets. Zu bestimmten Meilensteinen wie Abgaben, SOP oder QA-Reviews fallen diese Punkte dann zwar auf, allerdings kann und wird dann wenig geändert. Weitere Probleme treten dann im Zusammenspiel mit dem Kunden auf. Welche Tickets werden nun noch bearbeitet und welche nicht? Welche werden vorgezogen? Müssen die internen vielleicht nicht sogar zuerst bearbeitet werden?
