Chrome-Extension Pomodoro Daisuki

Pomodoro Daisuki ist eine Extension für den Chrome-Browser, die ein Kanban-Board mit der Pomodoro-Technik verbindet.

Die Extension bietet die Möglichkeit, sich ein einfaches Kanban-Board zu bauen und darauf einfache Kanban-Karten in vier verschiedenen Farben zu platzieren. Über  Buttons am oberen Rand kann man einen Pomodoro oder eine kurze oder lange Pause starten.

Wer ein einfaches Kanban-Board benötigt und den Chrome-Browser verwendet, sollte sich diese Extension einmal ansehen.  Die Pomodoro-Funktionalität wird für mich allerdings dadurch eingeschränkt, dass man angefangene Pomodori und Pausen nicht abbrechen kann. Ich hoffe, dass der/die Programmierer hier noch eine entsprechende Option einbauen.

Die Extension lässt sich über den Chrome Web Store kostenlos installieren.

 

SMED im IT-Betrieb

SMED ist eine Methode aus der Lean Production und ist die Abkürzung für Single Minute Exchange of Die.

Ziel von SMED ist, die Umrüstzeiten von Maschinen für verschiedene Produkte zu minimieren. Je kürzer die Umrüstzeiten sind, desto schneller kann die Maschine zwischen verschiedenen Produkten wechseln, wodurch kleinere Losgrössen wirtschaftlicher werden. Dies kommt dem Ziel des “Single-Piece-Flow” entgegen.

Um die Umrüstzeiten zu verringern, geht man folgendermassen vor:

• die Umrüsttätigkeiten, die auch bei laufender Maschine durchgeführt werden können (externe), werden von denen, die nur bei stillstehender Maschine durchgeführt werden können (interne), separiert.
• interne werden möglichst in externe Umrüsttätigkeiten umgewandelt
• Umrüsttätigkeiten werden vereinfacht, standardisiert, automatisiert, parallelisiert und im besten Fall eliminiert

Ein Beispiel für eine externe Tätigkeit ist die Bereitstellung des benötigten Werkzeugs für die Umrüstung, die parallel zur laufenden Maschine erfolgen kann, ein Beispiel für eine interne Tätigkeit der Wechsel einer Komponente der Maschine.

Die Idee des SMED lässt sich auch im IT-Betrieb anwenden. Im grösseren Maße wird diese Idee schon seit langer Zeit mit “kalten”, “warmen” und “heißen” Rechenzentren in unterschiedlicher Intensität praktiziert.

Auch beim Austausch von PCs oder Peripheriegeräten lässt sich diese Methode umsetzen und wird auch üblicherweise in Teilen praktiziert. So werden PCs vorab mit Software versorgt, bevor sie am Arbeitsplatz aufgebaut werden. Auch auf Software lässt sich die Methode anwenden, z. B. bei der Migration von Datenbeständen zwischen Alt- und Neusystemen.

Einige Beispiele für externe “Umrüsttätigkeiten” im Desktop-Umfeld sind:

• Bestückung von Druckern mit Tinte bzw. Toner und Fotoleitertrommel vor dem Aufbau
• Funktionstest von Druckern vor dem Aufbau (z. B. Testseite bei einem Drucker vor dem Aufbau drucken und prüfen)
• Konfiguration von Druckern vor dem Aufbau (Netzwerk-Einstellungen, Emulation, Schriftgrösse, Schriftart, etc.)
• Funktionstests von PCs vor dem Aufbau (Netzwerkverbindung, Domänen-Anmeldung, Funktion gewisser Anwendungen)
• Konfiguration von Faxgeräten vor dem Aufbau (Sendekennung, eigene Faxnummer, Wahlverfahren, etc.)

Um SMED im IT-Betrieb anzuwenden, empfiehlt sich folgendes Vorgehen:

• IT-Tätigkeit(en) identifizieren, bei denen SMED lohnenswert erscheint
• eine Prozessbeschreibung für den Ist-Ablauf erstellen, falls nicht vorhanden
• den Prozess gemäß der oben genannten Schritte verbessern
• eine Prozessbeschreibung für den Soll-Ablauf erstellen
• den Soll-Ablauf testen und gegebenenfalls weitere PDCA-Zyklen durchlaufen
• Soll-Ablauf zur neuen Standard Operating Procedure machen

“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.

Der Umgang mit Fehlern in MS Access

Ein Programm sollte so konzipiert sein, dass es auf auftretende Fehler möglichst sinnvoll reagiert, diese am besten jedoch verhindert (Pokal Yoke).

Programmfehler

Um aufgetretene Fehler zu behandeln, bietet Access den On Error-Befehl an. Er bietet zum einen die Möglichkeit, im Fehlerfall zu einer Marke in der Sub/Function zu springen und den dortigen Code zur Fehlerbehandlung abzuarbeiten (On Error GoTo  Sprungmarke), als auch die Option, den Fehler zu ignorieren und mit dem nächsten Kommando weiter zu machen (On Error Resume Next). Im Fehlerfall wird ein Objekt Err erzeugt, über das man ein paar Informationen zum aufgetretenen Fehler erhält.

Für die Fehlerbehandlung in Formularen kann man die Sub Form_Error im jeweiligen Formular verwenden, die eine Fehlernummer bereit stellt.

Ich formuliere “gefahrengeneigten” Code meistens in Funktionen und melde als Rückgabewert den Fehlerstatus (0=kein Fehler, alle anderen Werte sind Fehler). In der aufrufenden Sub/Function kann dann gegebenenfalls auf den zurück gegebenen Fehlercode entsprechend reagiert werden, ohne dass der Programmlauf abgebrochen wird.

Ich verwende eine allgemeine Fehlerbehandlungsroutine, die im Fehlerfall jeweils aufgerufen wird und den Fehler in vereinheitlichter Form ausgibt, z. B. über eine Messagebox.

Zusätzlich werden die aufgetretenen Fehler noch in ein Fehlerprotokoll geschrieben, so dass ich ggfs. noch eine Post-Mortem-Analyse durchführen kann. Leider werden Fehler ja auch nicht immer von den Anwendern gemeldet, so dass die gefühlte und die reale Fehlerhäufigkeit voneinander abweichen können. Durch die Protokollierung der Fehler ist ggfs. auch eine statistische Auswertung der Fehler möglich, um die “Hot Spots” zu erkennen, in denen die meisten Fehler auftreten und wo die Entwickler-Zeit am sinnvollsten investiert werden sollte.

Ich habe drei Fehlerkategorien definiert. Die erste führt zum Programmabbruch nach Fehlermeldung und -protokollierung, die zweite zeigt den Fehler an und protokolliert ihn (ohne Programmabbruch) und die dritte protokolliert einen Fehler “still”.

Bei Anwendungen im betrieblichen Umfeld muss man hinsichtlich der Protokollierung den Aspekt der Leistungs- und Verhaltenskontrolle beachten.

Plausibilitätsprüfungen

Neben der Behandlung aufgetretener Fehler sollte  nach meinem Verständnis auch die Vorbeugung von Fehlern implementiert werden. Ich baue daher Plausibilitätsprüfungen in meine Programme ein, die bei Auftreten von nicht prozesskonformen Werten oder Wertekombinationen einen Hinweis ausgeben oder ggfs. selbsttätig korrigieren (Jidoka).

Ein Beispiel dafür ist, dass ich z. B. das Erledigt-Flag in einer Erfassungsmaske automatisch setzen lassen, wenn ein Erledigungsdatum von Anwender eingegeben wurde. Ein anderes Beispiel ist die Prüfung eines Datumswertes mit der IsDate-Funktion auf Gültigkeit.

Je besser die Plausibilitätsprüfungen sein sollen, desto besser muss man natürlich den abgebildeten Prozess kennen und verstehen. Bei Prozessänderungen müssen die Plausibilitätsprüfungen jeweils angepasst werden.

Gerade in Formularen bietet Access bereits eingebaute Möglichkeiten zur Gültigkeitsprüfung für einzelne Eingabefelder an.

Je nach Schwere der verletzten Plausibilitätskriterien kann man es bei einer Meldung über die Plausibilitätsverletzung (Messagebox vom Typ vbInformation) belassen, die Plausibilität per Programmlogik herstellen, oder man erzwingt die Eingabe von plausiblen Daten (z. B.  lässt sich vorher das Eingabeformular nicht schließen).

Hier muss die Balance zwischen der Datenkonsistenz und der “Freiheit des Anwenders” gefunden werden.

Weitere Massnahmen

Um Fehlbedienungen/Falscheingaben zu minimieren, bietet es sich an, möglichst nur die gerade relevanten Programmoptionen anzuzeigen. Ich blende beispielsweise je nach Programmsituation in Access-Formularen Optionen oder Buttons aus bzw. ein.

Neben der Behandlung von technischen und logischen Fehlern spielt auch die Benutzerfreundlichkeit eine wichtige Rolle, z. B. durch erwartungskonformes Verhalten des Programms.

Ein Programm sollte Idealerweise so gestaltet sein, dass der Anwender es gerne nutzt, auch wenn sich dies in der Praxis nicht immer umsetzen lässt.

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.