Manchmal fühlen sich die Systeme, in denen wir Tag für Tag unterwegs sind, ungefähr so an:
(Bildquelle: Wikipedia)
Es funktioniert, aber nur gerade so. Da muss man mal einen richtigen Transporter anschaffen, oder?
Aus der Fertigung kennt man das Prinzip des Kaizen (wörtlich: Veränderung zum Besseren). Statt alle paar Jahre alles komplett umzukrempeln und eine neue Anlage zu bauen, macht man kontiniuierlich viele kleine Verbesserungen am Produktionsprozess. Im Laufe der Zeit kann das zu spektakulären Ergebnissen führen: Sekunden und Handgriffe, die hier und da eingespart werden, summieren sich, Abläufe werden vereinfacht, Fehler werden vermieden usw.
Nun kann man vielleicht denken, dass sich das Prinzip der kontinuerlichen Verbesserung auf Wissensarbeit, insbesondere IT-Projekte, nicht übertragen lässt. Schließlich steht der Wissensarbeiter nicht am Band, sondern macht jeden Tag etwas anderes. Und ein Projekt gehört ja per definitionem nicht zum sich wiederholenden Tagesgeschäft.
Trotzdem gibt es überall Ansatzpunkte für Verbesserungen, denn Vieles ist eben doch nicht so einmalig. Ein paar Beispiele für Softwareentwicklungs-Projekte:
Bei all diesen Themen lassen sich in kleinen Schritten Verbesserungen erzielen. Das ist entscheidend: Statt einer großen Hauruck-Aktion (für die wir nie die Zeit finden) machen wir viele kleine Schritte.
Woher kann man die Zeit dafür nehmen?
Wer hofft, dass die Zeit für diese Verbesserungen sich schon irgendwie finden wird, wird enttäuscht. Es geht nicht ohne explizite Reservierung von Kapazität. Es gibt viele Varianten, in denen das praktiziert wird:
Woher das Geld dafür nehmen?
Die meisten Verbesserungen sollten kostenlos (abgesehen von etwas Arbeitszeit) bzw. sehr billig sein. Beispiel: Einen neuen Server-Cluster anzuschaffen, um die Unit-Tests schneller zu machen, fällt nicht unter “kontiniuierliche Verbesserung”. Sich die 10 langsamsten Tests vorzunehmen und sie mindestens zweimal schneller zu machen, schon.
Es gibt so viel zu verbessern, wie kann man das priorisieren?
Am einen Ende des Spektrums ist die einfache Regel “Fix what bugs you!”, also ungefähr “Stelle ab, was Dich nervt”. Man vertraut den Leuten, dass sie selbst wissen, was sinnvoll ist.
Priorisierung nach erwartetem ROI bzw. Verzögerungskosten wäre das andere Ende des Spektrums. Der Aufwand dafür ist meist unverhältnismäßig, weil die eingesetzte Kapazität so klein ist. Lieber die Verbesserung erstmal umsetzen, wenn es dann nicht das erwartete Ergebnis bringt, haben wir nur wenig Zeit (30 Minuten?) verloren.
Man kann für einige Themen eine grobe Richtung vorgeben, beispielsweise “Wir wollen den Release-Overhead von 2 Wochen pro Release auf eine Woche pro Release senken”. Dann kann man ungefähr abschätzen, welche Schritte zuerst gemacht werden sollten.
Soll es dafür Prämien geben?
Nein, denn kontiniuierliche Verbesserung ist Teil des Jobs, so wie die eigentliche Arbeit auch.
Kann es nicht auch Verschlechterungen geben?
Ja, aber weil es kleine Schritte sind, kann man sie auch einfach wieder rückgängig machen.
Welche Rolle spielen Führungskräfte dabei?
Führungskräfte sollen eine Umgebung schaffen, in der kontinuierliche Verbesserungen gefördert werden:
Das Thema Kaizen ist überraschend vielschichtig – abgesehen von den gerade beschriebenen taktischen Gesichtspunkten (Was, wie und mit wem sollen wir verbessern?) hat das Prinzip auch strategische Bedeutung. Darüber vielleicht später mehr.
Matthias Berth