Lean IT: eine Informatik, die liefern kann!

 

ducks-2000586_1920

„Wir haben eine sehr industriell aufgestellte Informatik“, das haben mir oft Leiter von IT-Abteilungen gesagt, die mit mir über Lean IT sprechen wollten. Oft war ich sehr neugierig darauf, mit ihnen ihre Teams zu besuchen, um dort ihre Entwicklungsmethodik zu sehen.

Ich erkannte sehr schnell, dass „Industrialisierung“ zwar eine Organisationsform beschreibt, aber sehr unterschiedlich ist zwischen einer Fabrik und einer Informatik-Abteilung. In einer Fabrik, vor allem einer Lean Fabrik, bewegt sich das Produkt: Es bewegt sich von einem Arbeitsplatz zum nächsten, in einem regelmäßigen Rhythmus, und gewinnt dabei an Wert. Es erreicht schnell den Ort der Auslieferung, den ihm dort zugewiesenen Platz und wird versandt. Das Verhältnis zwischen „Herstellungszeit“ und „Verweilzeit“ in der Fabrik ist sehr nahe bei 1. Ich habe Stoßstangen gesehen, die innerhalb 24 Stunden hergestellt wurden, vom Plastik-Granulat bis zum Versand, und jede Stoßstange unterschied sich dennoch von ihrem Vorgänger und ihrem Nachfolger.

So routiniert es in einer Fabrik abläuft, so angespannt und aufgeregt ist es oft in typischen IT-Abteilungen. Die kleinste Anfrage stößt dort einen gut definierten Prozess an – und dennoch wird nichts zeitig geliefert, oder nur sehr langsam!

Anlässlich von Lean-IT-Besuchen bitte ich regelmäßig darum, wie in einer Fabrik, die zuletzt ausgelieferten Produkte zu sehen: Oft findet man nur sehr wenige, die innerhalb einer Woche ausgeliefert wurden. Seien es Lösungen von Calls, Bereitstellung von Arbeitsplätzen oder Serverinstallationen. Und wenn man das Datum der Anfrage ansieht, liegt dieses oft Wochen oder Monate zurück. Ich habe Teams gesehen, die „Geburtstage“ von Calls gefeiert haben: ein Jahr nach Öffnung des Calls ….

Das Verhältnis zwischen „Herstellungszeit“ und „Verweilzeit“ ist in diesen Bereichen sehr niedrig:

  • einige Stunden um einen Server zu installieren, gegenüber 5 Monaten um ihn bereitzustellen, oder
  • einige Minuten um einen Flux CFT zu schaffen gegenüber 25 Tagen um ihn auszuliefern.

Wenn man die Entwicklung einer neuen Funktionalität verfolgt, kann das sehr überraschend sein: Im Falle eines meiner Besuche dauerte das Einfügen eines simplen Feldes in ein Business Intelligence Tool 24 Monate. Von der Anforderung bis zur Auslieferung und Integration in ein „Projekt“, von der Realisierung und seiner Produktion, vergingen 2 Jahre! Da versteht man besser die Verzweiflung anderer Bereiche gegenüber ihrer Informatik.

Wie kann eine Organisation, die sich eine industrielle Organisation nennt, eine so unterschiedliche Performance zwischen Fabrik und IT akzeptieren?

Lean IT liefert eine gute Perspektive, um auf diese Frage zu antworten. Diejenigen IT-Abteilungen, die ich über ihre „Industrialisierung“ befragt habe, erklärten mir, dass sie zunächst im Detail die Tätigkeiten und die Arbeitsergebnisse definiert hatten, die bei jedem Schritt zu erreichen waren (Dokumente, Daten etc….). Man kümmerte sich um die Präzision der Ergänzungen an jedem Übergabepunkt und um die Nachvollziehbarkeit dieser Schritte. Wenn das erfolgt war, ging es nur noch darum, die Ressourcen bereitzustellen, um die Arbeit zu erledigen.

Aber nichts verläuft wie vorgesehen. Weil diese Vorgehensweise völlig das erste Erfolgsprinzip einer Industrialisierung vergessen hatte: Nicht der Prozess muss kontrolliert werden, sondern die Variablen müssen gemeistert werden! Das gestaltet dann einen industriellen Prozess robust und effizient.

Aber die Variablen werden in Informatik-Prozessen oft negiert. Jeder kontrolliert auf seinem Arbeitsplatz die Qualität der Informationen und Produkte, die er bekommt: Im Falle eines Fehlers wird die Anfrage oder das Produkt dem Verursacher zurückgegeben, und man wartet, dass er ad hoc Korrekturen anbringt.

Die gute Praxis des Lean IT verlangt dagegen, Anfragen, die nicht dem Üblichen entsprechen, zu verstehen, anstatt sie abzuweisen. Nichts als eine einzige Idee ist vorherrschend: Den Kunden völlig zufriedenzustellen und ihm zu liefern, was er möchte.

Das ist eine ständige Herausforderung. Und zu verstehen, was dem entgegensteht, dafür eine Notwendigkeit.

Ein Beispiel: Ein Team, das bei einem großen Operator virtuelle Rechner entwickelt, versetzt die ganze IT-Abteilung in Schwierigkeiten: Es gibt keine Auslieferungen mehr. Es wird also auf höchster Ebene eine Krisen-Task Force eingesetzt, das Ergebnis ist eindeutig: Die Kunden senden nur Anfragen, die als unrealisierbar betrachtet werden, weil sie nicht den Konformitätsanforderungen entsprechen. Worüber beklagen sie sich also? Es wird also eine deutliche Antwort für das Reporting nach oben vorbereitet.

Durch Zufall treffe ich da den für die virtuellen Rechner zuständigen Manager und schlage ihm vor, das Problem nicht in seinen PP-Slides, sondern in seinem Team anzusehen.

Wir gehen also durch die Korridore: Der erste Entwickler-Raum ist leer. Wo ist das Verstärkungs-Team, das helfen soll, mehr output zu liefern? Wir stellen fest, dass das Team, 16 Tage nach seiner Ankunft, immer noch keine funktionierenden Arbeitsplätze hat und deshalb spazieren geht. Wir gehen dann in den Bereich, in dem das übliche Team arbeitet. Der Verantwortliche dort zeigt uns den Stapel von Anfragen, die er seit einer Woche an seine Kunden zurückgesandt hat. Er und der Manager zeigen mir, wie groß der Stapel ist: Die Kunden schießen sich demnach also Kugeln in die Füße, indem sie nicht-konforme Anfragen senden.

OK, aber was sind die Non-Konformitäten? Ich bitte den Manager, die erste abgelehnte Anfrage vorzulesen. Er kann nicht feststellen, warum sie abgelehnt wurde, aber der Teammanager erläutert: Der Nachfrager will Windows 8 installieren und verlangt 60 GB Festplattenspeicher. Ende der Story. Als Lean Coach bedanke ich mich und bitte darum, die nächste Anfrage anzusehen. Der Manager identifiziert ganz alleine den Irrtum: Windows 8 und 60 GB Festplatte. Er liest daraufhin ein Dutzend von Anfragen, alle aus dem gleichen Grund abgelehnt. Es folgt eine kurze Diskussion zwischen dem Manager und dem Teamverantwortlichen: Danach werden die abgelehnten Anfragen wiederaufgenommen, die 60 GB werden durch 80 GB ersetzt (der Manager übernimmt die Verantwortung) und man liefert die Rechner aus.

Nachdem sich die Angelegenheit beruhigt hatte, versuchte man zu verstehen, woher diese Fabel der 60 GB kam. Und man fragte sich sogar, warum man von den Kunden Expertenwissen über die Größe von Festplatten usw. verlangen kann.

Das zeigt, warum Informatik und Industrie unterschiedlich sind: In einer Fabrik kennt man sich mit Abweichungen und Änderungswünschen aus, weil man den Kunden sehr ernst nimmt.

Kurz gesagt, eine Lean Aktivität für eine IT Abteilung zu beginnen bedeutet nicht, seine Prozesse nochmals zu beschreiben. Selbst wenn sie überall vorhanden sind. Sondern im Gegenteil eine Verbesserungskultur zu implementieren, in der jeder abweichende Wünsche erkennt, die richtigen Methoden weiß um sie zu verstehen und zu bearbeiten, und sich persönlich dafür einsetzt, Abweichungen zu reduzieren.

Lohnt das den Aufwand? Ja, sofern man ein Lächeln auf dem Gesicht des Kunden sehen möchte. Und gleichzeitig dabei die Lieferverspätungen um den Faktor 10 reduziert und die Produktivität um den Faktor 2 steigert.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s