“Toyota Kata” von Mike Rother

Ich habe das Buch Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results von Mike Rother gelesen.

Es beleuchtet das TPS bzw. Kaizen noch mal aus einer anderen Perspektive. Es geht hier weniger um die Werkzeuge, sondern um die Systematik, wie man prinzipiell an die kontinuierliche Verbesserung heran geht und wie diese gelehrt wird.

Der Autor beschreibt das Improvement Kata und das Coaching Kata. Der Begriff Kata meint, so habe ich ihn verstanden, eine oder mehrere immer wiederkehrende Übungen, die dem Lernenden helfen, eine neue Gewohnheit oder “Art des Tuns” zu entwickeln, z.B. wiederkehrende Bewegungsabläufe in Kampfsportarten.

Die Improvement Kata meint die “Routine”, nach der man Verbesserungen herbei führt, die Coaching Kata das Vorgehen bei der Weitergabe des Improvement Kata.

Sehr anschaulich beschreibt Mike Rother, dass man bei Toyota für die Herbeiführung von Verbesserungen (Improvement Kata) folgende Routine (fünf Fragen) durchläuft:

• was ist der Zielzustand?
• was ist der Istzustand?
• welche Probleme verhindern, dass wir jetzt den Zielzustand erreichen? Um welches davon will ich mich jetzt kümmern?
• was ist mein nächster Schritt (Start des nächsten PDCA-Zyklus’)?
• wann können wir (vor Ort) sehen, was wir von diesem Schritt gelernt haben?

Mike Rother betont in seinem Buch, dass man bei der Auswahl des Problems, das man lösen will, nicht zwingend das schwerwiegendste auswählen muss, sondern einfach eines wählen kann, das “schwerwiegend genug” ist.

Eine weitere wichtige Botschaft ist, dass man bei einer Improvement Kata jeweils nur  den nächsten Schritt festlegt. Nachdem man diesen Schritt getan hat, ist “die Sicht nach vorne” etwas besser, und so wird der nächste Schritt eher einer in die richtige Richtung.

Bei der Coaching Kata geht es, grob zusammengefasst, darum, dass der Lehrende selbst auch Lernender war/ist, also die Improvement Kata beherrscht, und die Improvement Kata selbst wiederum auf das Lehren anwendet, also gewissermassen rekursiv.

Mir hat das Buch noch mal wichtige, neue Impulse gegeben und ich fand es sehr lesenswert. Der Autor hat eine Webseite, auf der er die beiden Katas gut beschreibt.

Personal Kaizen: das Now & Later Board für elektronische Notizen

Seit langer Zeit benutze ich an meinem Arbeitsplatz den Windows-Texteditor Wordpad als elektronischen Notizzettel. Bei der Anmeldung in Windows wird über den Autostart gleich die Datei notizen.rtf geladen, in die ich alles hinein schreibe, dass ich mir kurzfristig aufheben möchte. Die angeboteten RTF-Formatieroptionen reichen mir dabei völlig aus.

Verschiedene Notizen trenne ich im Editor meist durch mehrere Leerzeilen, gefolgt von einer Zeile mit ein paar Minuszeichen für den Beginn einer neuen Notiz. Was mich schon immer etwas gestört hat, war die “Vermischung” von Notizen zu der Aufgabe, die ich gerade bearbeite, und Notizen, die diese Aufgabe nicht betreffen, die ich aber dennoch aufnehmen muss, weil beispielsweise jemand anruft oder bei mir vorbei kommt und mir etwas mitteilt.

Ich bin, als ich mir das Programm Vitamin-R ansah, über die offensichtliche Lösung für mein Problem gestolpert: das Now & Later Board. das im Wesentlichen ein Editor mit mehreren Tabs ist.

In Java habe ich mir diese Funktionalität nachprogrammiert.

Neben einfachen Formatierungsmöglichkeiten habe ich noch eine Funktion für das Leeren eines Notizblattes implementiert:

Alle Informationen zur aktuell bearbeiteten Aufgaben notiere ich auf dem Notizblatt jetzt, alles, was ich später noch erledigen muss, auf dem Notizblatt später, und den Rest auf dem Notizblatt Schmierzettel. Zwischen den verschiedenen Notizblättern kann ich mit Hotkeys wechseln. Um die Bedienung einfach zu halten, erfolgt das Laden und Speichern der drei Notizblätter automatisch.

Ich nutze mein Now & Later Board nun seit einigen Tagen und überlege, welche Funktionen ich noch einbauen könnte, um meinen “Notiz-Workflow” zu verbessern.

 

Personal Kaizen: der Stau

Ich stand heute – mal wieder – im Stau, ohne die Ursache zu kennen. Auf meiner Strecke gibt es oft Staus wegen Überlastung, also ohne Unfall oder ähnliches.

Aus Sicht des Lean-Managements könnte man sagen, dass die Überlastung der Autobahn (Muri) durch die Unausgeglichenheit (Mura) der “Produktion” entsteht, sprich: alle wollen in der Rush Hour zur gleichen Zeit die Kapazität der Autobahn nutzen.

Irgendwann stand ich schließlich mit abgeschaltetem Motor auf der mittleren von drei Spuren hinter einem LKW. Ich las den RSS-Feed auf meinem iPhone, um mir die Zeit zu vertreiben. Mir fiel auf, dass sich der Verkehr auf den anderen beiden Spuren langsam weiter bewegte, der Sattelschlepper vor mir jedoch keinen Zentimeter, was ich mir nicht so recht erklären konnte.

Die Stau-App meines iPhones verriet mir, nachdem ich alle meine Feeds “abgearbeitet” hatte, dass sich vor mir ein Unfall ereignet hat und die Autobahn ein Stück weiter noch ca. zwei Stunden vollgesperrt war. Ich fuhr dann schließlich auf die rechte Spur, an dem LKW vorbei, und stellte fest, dass der Fahrer ein Päuschen machte, denn die Fahrzeuge vor ihm fuhren langsam weiter. Später sah ich noch andere LKW-Fahrer, die es ihm gleich taten.

Als ich dann darüber nachdachte, wie ich das zukünftig besser machen kann  (Hansei), habe ich für mich folgende Verbesserungsmöglichkeiten für mein Verhalten im Stau gefunden:

• ich ziehe in Erwägung, dass ein LKW, der vor mir in einem Stau steht, sich deshalb nicht bewegt, weil der LKW-Fahrer eine Pause macht, und nicht zwingenderweise, weil er nicht weiter fahren könnte
• ich muss stets genug Abstand zwischen meinem Wagen und dem Fahrzeug davor lassen, so dass ich mich problemlos in den laufenden Verkehr auf einer anderen Fahrspur einfädeln kann, falls es einem LKW-Fahrer vor mir einfällt, einfach stehen zu bleiben
• der “Vorrat” an RSS-Feeds reicht möglicherweise nicht aus, die Wartezeit im Stau zu überbrücken. Ich sollte daher, als Beifahrer, meinen Kindle einpacken.

Personal Kaizen: Behandlung des E-Mail-Posteingangs nach längerer Abwesenheit

Nach längerer Abwesenheit (mehrere Tage oder Wochen) finde ich, wie wahrscheinlich viele Angestellte, stets einen prall gefüllten Posteingang in Outlook in der Firma vor.

Bisher habe ich meinen Fokus nach meiner Rückkehr erst einmal immer darauf gerichtet, alle Mails im Posteingang abzuarbeiten (teilweise mehrere Stunden), und erst danach mit der “normalen” Arbeit zu beginnen. Da dies aufgrund vielfältiger Störungen aber nicht immer durchzuhalten ist, habe ich die Bearbeitung meines Posteingangs umgestellt.

Ich lasse nun über Regeln in Outlook 2003 die eingehende Post mit farbigen Fahnen versehen. Dabei tagge ich jeweils thematisch oder personell zusammengehörige E-Mails mit der gleichen Farbe anhand von Absendern oder Schlüsselwörtern in Betreff oder Nachrichtentext.

Weiterhin habe ich mir für den Posteingang eine entsprechende Ansicht definiert, in der ich nach der Farbe der Fahnen sortieren lasse (sie enthalten eine implizite Reihenfolge/Hierarchie). Zweites Sortierkriterium ist das Datum in absteigender Reihenfolge.

Wenn ich nun nach längerer Abwesenheit wieder zurück komme, sieht meine neue Standard Operating Procedure für E-Mail-Rückstände nun folgendes Vorgehen vor:

• alle eingegangenen E-Mails werden zu Beginn in den Unterordner Backlog des Posteingangs verschoben
• im Unterordner Backlog werden die E-Mails in der durch die definierte Ansicht festgelegten Reihenfolge von oben nach unten abgearbeitet (und danach aus dem Backlog-Unterordner entfernt), so wie es die Arbeitssituation zulässt. Möglichst werden dabei immer ganze Pomodori pro “Sitzung” aufgewendet.
• es werden soviele Iterationen durchlaufen, bis das Backlog geleert ist
• die nach der Rückkehr neu eingegangenen E-Mails werden nicht in den Unterordner Backlog verschoben, sondern “normal” bearbeitet

Durch dieses Vorgehen stelle ich sicher, dass ich für den E-Mail-Rückstand verfügbare Zeit jeweils auf die wichtigsten E-Mails verwende.

Eine erste Anwendung nach einwöchiger Abwesenheit war erfolgreich, ich bin gespannt, wie die nächste Interation dieses Vorgehens aussieht.

Personal Kaizen: morgendliche Stau-Prüfung mit dem Smartphone

Eine ganze Weile lang hatte ich bei Fahrten zwischen Wohnort und Arbeitsplatz mein mit TMC ausgestattetes Navigationssystem in Betrieb, um rechtzeitig über Staus informiert zu werden.

Um keine Einladung für Diebe zu bieten, habe ich das Gerät bei Fahrtantritt immer im Auto montiert (Stromversorgung via Zigarettenanzünder hergestellt, Halterung an Frontscheibe mittels Saugnapf befestigt, TMC-Empfänger eingesteckt) und bei Fahrtende abmontiert.

Mit der Zeit ist der Stecker der Stromversorgung via Zigarettenanzünder leider etwas “ausgeleiert”, so dass ich das Navi seit einigen Monaten nur noch installiere, wenn ich es tatsächlich zur Navigation benötige.

Nachdem ich dieser Tage am Morgen einen Stau durch die “Nachwehen” einen Unfalls “geniessen” durfte, habe ich meine morgendliche Routine erweitert. Bevor ich losfahre, prüfe ich nun über mein Smartphone, das ich standardmässig sowieso anschalte, ob es Stau gibt. Hierfür nutze ich die Anwendung iVerkehr.

Kaizen: Prozessbeschreibungen und Checklisten

Vor einer Weile habe ich in der Firma angefangen, Prozessbeschreibungen zu erstellen. Auslöser war die Erfahrung, dass vor allem nicht so häufige Arbeitsabläufe und “Practices” nicht wirklich sauber dokumentiert waren, wenn überhaupt, sondern man sich das Wissen “zusammenrecherchieren” musste und dann beim nächsten – seltenen – Auftreten die Informationsbeschaffung erneut los geht (z. B. Freischalten von Roaming im Ausland für UMTS-Karten).

Um dieses Wissen zu konservieren, wird in Word eine Prozessbeschreibung, ggfs. incl. Checkliste, erstellt und als HTML-Datei auf einem Groupshare abgelegt. Bei Bedarf visualisiere ich die Prozesse noch mit der kostenlosen Java-Anwendung Aris Express und generiere eine entsprechende PDF-Datei. Auf einer Übersichtsseite, die man über den Browser öffnet, erhält man dann eine Liste aller verfügbaren Prozessbeschreibungen und kann sie per Klick anzeigen lassen.

Als Ergänzung dazu habe ich nun angefangen, auch reine Checklisten zu erstellen. Begonnen habe ich mit Checklisten für den Rollout von PCs.

Heute habe ich mit einem Kollegen angefangen, bisher anders genutzte Räume für die Bereitstellung von mehreren dutzend Arbeitsplätzen mit PCs und Telefonen vorzubereiten (Verkabelung, Geräteaufbau). Die Räume befanden sich nicht gleichen Gebäude wie mein Büro. Es kam, wie es kommen musste, ich hatte ein paar Kleinigkeiten, die hilfreich gewesen wären, vergessen, z. B. eine Zange/Schere, um Kabelbinder aufzutrennen oder Aufkleber und Filzstifte, um Geräte temporär zu beschriften. Das war kein grosses Problem, denn zwischen meinem Arbeitsplatz und diesen Räumen lagen nur wenige Minuten Fußweg. Dennoch hat mich dieses Erlebnis inspiriert, eine Checkliste für die tatsächliche Durchführung von Arbeitplatz-Installationen/Umzügen zu erstellen.

Kaizen: Teilautomatisierung der Datenmigration beim PC-Rollout

In der Firma werden die Benutzerprofile – mit Ausnahme einiger Daten, wie z. B. der Favoriten des (Internet-)Explorers – der Windows-Systeme lokal gehalten, sind also bei der Anmeldung an einem anderen PC nicht verfügbar. Wenn ein Anwender seinen Rechner gewechselt, sichern wir dessen Benutzerprofil sowie weitere individuelle Einstellungen auf einem Share im Netz und übertragen diese Daten dann auf das andere System.

Um den Transfer zu vereinfachen und Fehler (=Nicht-Sichern bestimmter Dateien) zu vermeiden, habe ich nun ein kleines WSH-Script geschrieben, dass die Sicherung und Wiederherstellung der Benutzerdaten übernimmt.

Durch die Standardisierung und Teilautomatisierung der Sicherung (z. B. Übertragung von programmspezifischen Konfigurationsdateien, die nicht im Benutzerprofil liegen und das Suchen und Sichern von Outlook-Archivdateien von der gesamten Festplatte) wird mit fortlaufender Verbesserung des Scripts die Fehlerquote hoffentlich immer weiter sinken und die von uns dafür aufgewendete Arbeitszeit auch.

In das Script habe ich auch ein bisschen Pokal Yoke (z. B. Prüfung, ob das zur Sicherung angegebene Benutzerprofil überhaupt existiert; Prüfung, ob das Share für die Datensicherung online ist; Auswertung der zurück gegebenen Statuscodes von Robocopy) sowie eine automatische Drosselung der Kopier-Geschwindigkeit in Abhängigkeit von der Netzwerkanbindung des PCs) eingebaut. Für die Rücksicherung habe ich ebenfalls ein entsprechendes Script geschrieben.

Single Piece Flow vs. Batch beim PC-Rollout

Wir wollten neulich in der Firma in einer Abteilung die PCs durch neuere Geräte ersetzen.

Wie sich bei einer ersten Kontrolle heraus stellte, war auf den PCs eine veraltete Version der wichtigsten Fachanwendung installiert. Dieser Fehler war für das geschulte Auge noch relativ offensichtlich. Wir sorgten für die Installation der korrekten Version, die Anmeldung an der Anwendung funktionierte, und alles schien in Ordnung.

Nach der Installation des ersten Rechners beim Anwender stellte sich heraus, dass ein wichtiges Feature der Anwendung nicht nutzbar war. Wir haben darauf hin dort wieder den bisher genutzten PC angeschlossen. Wie sich heraus stellte, muss für dieses Feature die IP-Adresse des betreffenden PCs auf einem bestimmten Server-System frei geschaltet werden. Dies war nicht der Fall (die neuen Rechner hatten teilweise andere IP-Adressen als die alten), liess sich aber nachholen.

Wenn wir alle Rechner in einem Rutsch (Batch), z. B. an einem Wochenende, ausgetauscht hätten, wären danach auf einen Schlag etliche Arbeitsplätze nicht benutzbar gewesen. Durch die Auslieferung von jeweils einzelnen Rechnern (Single-Piece-Flow) haben wir den Fehler früher bemerkt, und es wurde nur ein defektes “Produkt” an unseren internen Kunden ausgeliefert.

Welche Lehren haben wir daraus gezogen?

• der Single-Piece-Flow (vs. Batch) hat uns in diesem Fall eine Menge Arbeit erspart
• mit einem standardisierten Prüfprozess/Checkliste (vs. “mal kurz anmelden”) hätte sich das Problem  möglicherweise vor Auslieferung des ersten PCs finden lassen. Unser aktueller “Prüfprozess” für diesen Roll-Out besteht nun darin, dass der Anwender den Rechner vor der Installation erst mal bei uns testet.
• ein definierter Prozess (Standard Operating Procedure) für den Rollout dieses Arbeitsplatz-Typs hätte möglicherweise dafür gesorgt, dass die beschriebenen Probleme gar nicht erst aufgetreten wären.

Folgende Verbesserungen leite ich nun daraus ab:

• neue PCs werden möglichst sukzessive, also Gerät für Gerät, ausgerollt
• vor dem Roll-Out einer größeren Menge von gleichartig installierten PCs überlegen wir uns, ggfs. gemeinsam mit einem Anwender aus der Fachabteilung, ein Testverfahren (Checkliste), der die neuen Geräte zumindest stichprobenartig, besser jedoch vollständig, unterzogen werden. Die Testverfahren für die einzelnen Arbeitsplatztypen/Anwendungen werden dokumentiert und gepflegt, so dass man sie für zukünftige Roll-Outs nutzen kann.
• ich werde endlich das ITILv3-Buch, das schon Monate ungelesen bei mir zu Hause herumliegt, endlich mal lesen, um mich davon “inspirieren” zu lassen

Personal Kaizen: die vorgehende Pendeluhr

Ich habe eine mechanische Pendeluhr, die nicht dazu bewegen kann, genau zu gehen. Dies ist ärgerlich, da sie an zentraler Stelle hängt und von mir daher bei entsprechender Genauigkeit häufig genutzt werden würde.

Um das Problem zu lösen, habe ich nun das Justieren der Uhr in meine morgendliche Routine eingebaut. Ich vergleiche nun jeden Morgen die Zeitanzeige meines iPhones mit der Anzeige der Pendeluhr und justiere dann nach. Die über einen Tag auflaufende Ungenauigkeit ist zu klein, als dass sie stören würde.

Personal Kaizen: Trockene Haferflocken

Ich bereite mir morgens ein Müsli zu. Die Haferflocken befinden sich in einer Papierverpackung.

Gelegentlich kam es vor, dass der Bereich der Arbeitsplatte, auf dem ich die Haferflocken abgestellt hatte, feucht war. Ich habe dann, um Schimmel zu vermeiden, die Packung Haferflocken den Tag über immer auf die Seite gelegt, damit die Feuchtigkeit an der Unterseite der Verpackung trocken kann, konnte sie also erst am Abend wieder in den Schrank räumen.

Meine Verbesserung: ich stelle die Packung mit den Haferflocken jetzt auf einem anderen Teil der Arbeitsplatte ab, der weniger “feuchtigkeitsgeneigt” ist und vergewissere mich vor dem Abstellen des Paketes immer erst, ob die Fläche tatsächlich trocken ist.