IT Lean Management?

Mir sind in jüngster Vergangenheit in auffallend vielen Computermagazinen Rezensionen über das „Praxishandbuch Lean Management” von Gorecki / Pautsch ins Auge gesprungen. Lean Management: Ein neuer Hype in der IT? Ein neues Schlagwort? Eine echte Alternative zu Agilität und klassischen Modellen? Lean, das klingt gut. Schlank sein möchte jeder. Schlank assoziieren wir mit sportlich, fit und leistungsfähig. Schlankes Management lässt uns hoffen, auf alle Formen nerviger Notwendigkeiten verzichten zu dürfen und endlich konzentriert und zielgerichtet an den eigentlichen Problemen arbeiten zu können. Erfüllt der Ansatz diese Vision: Kurz gesagt: Ja.

Cover Praxishandbuch Lean Management

Praxishandbuch Lean Management

Was ist Lean Management im Verständnis des vorliegenden Handbuchs aus der Praxis? Diese Frage ist nicht durch eine singuläre definitorische Klausel zu beantwortet. Die Autoren Pawel Gorecki und Peter Pautsch geben dem Leser stattdessen  einen knackigen historischen Abriss. Lean Management basiert demnach auf einer ganzen Reihe komplementärer Denkansätze. In chronologischer Reihenfolge werden genannt:

Die verschiedenen Denkrichtungen wurden überwiegend zunächst in japanischen Unternehmen bis zur Einsatzreife entwickelt. Dies prägte schon rein etymologisch die zugrundeliegenden Begrifflichkeiten. Und führt bis heute zur Annahme, die Lean-Philosophie sei eng mit der japanischen Kultur verknüpft und nicht auf westliche Maßstäbe übertragbar. Die Autoren widerlegen diese Annahme. Zwar bedingen alle der oben genannten Denkrichtungen den Wunsch nach permanenter Verbesserung und prozesshaftes Denken, was ihren Erfolg in ehrgeizigen und disziplinierten Staats- oder Unternehmenskulturen begünstigen dürfte. Im Kern geht es bei Lean Management indes um die Vermeidung von Leerlauf, Overhead und Verschwendung. Die Vermeidung von Verschwendung passt tatsächlich sehr gut zum Streben nach maximaler Wertschöpfung. Der Einsatz von Lean Management ist somit schlicht vernünftig (in diesem Sinne) und vollständig kompatibel zum auf Gedankengut der Aufklärung basierenden Ansatz westlicher sozialer Marktwirtschaften.

Einen seiner frühen Ursprünge hat Lean Management im Automobilbau. Die bekannteste und wahrscheinlich erfolgreichste Umsetzung eines Lean-Ansatzes ist das Toyota Production System; TPS prägte seinerseits die Vision des Lean Managements entscheidend mit. Das Praxishandbuch zeigt aufgrund dessen auch keinen Ansatz auf, Lean Management auf Software-Herstellung zu übertragen. Lean Management ist eine allgemeine Organisations- und Führungstheorie, geschaffen und erfolgreich umgesetzt im produzierenden Gewerbe. Warum also die vielen Rezensionen in IT-Fachzeitungen? Die Antwort liegt implizit in der einleitenden Metapher des Buchs:

Stellen Sie sich vor, Sie sind Produktionsleiter in einer Chemiefabrik, die in der Produktion feuergefährliche Stoffe einsetzt. Jeden Tag gibt es an irgendeiner Stelle in der Produktion Brände. Die Brände sind teils schwerwiegend und müssen sofort bekämpft werden, um größere Schäden zu vermeiden. Die Werksfeuerwehr ist gut ausgerüstet und um Umgang mit diesen Bränden geübt. Auch die Mitarbeiter sind auf die Bekämpfung von Bränden trainiert und können sofort Gegenmaßnahmen ergreifen. [...] Der Analyse der Ursache der Brände wird nur wenig Aufmerksamkeit geschenkt. Die Begründung dafür ist einfach: Wir haben keine Zeit. 1

Die Aussage dieser Metapher muss jedem IT-ler unmittelbar aus der Seele sprechen! Jeden Tag verbringen wir damit, Brände zu löschen. Schlimme Projekte eilen von einem Brand zum nächsten. Meist werden Brände nicht einmal vollständig gelöscht, sondern entfachen beim nächsten Windstoß erneut – und selbst das wird gelegentlich billigend in Kauf genommen, um schnell zum nächsten Brandherd zu eilen. Ursachen-Analyse: Fehlanzeige. Lessons Learned: Selten. Verbesserungen für die Zukunft: Lediglich durch Kopfwissen. Und der Grund: Wir haben doch keine Zeit.

Aber ist das wirklich so? Haben wir Zeit? Es gibt zwei bedeutende Unterschiede zwischen produzierenden Gewerbe und Software-Entwicklung. Erstens handelt es sich bei Software um ein semiotisches Produkt. Es besteht aus Zeichen. Als eine Konsequenz kann Software seiner Natur nach praktisch unbeschränkt und jederzeit an jeder Stelle nachträglich verändert werden. Zweitens handelt es sich Software um Entwicklungsvorhaben. Software wird in Projekten entwickelt und kann nach seiner Fertigstellung beliebig oft und praktisch kostenfrei kopiert und vervielfältigt werden. Produzierendes Gewerbe hat seine wesentlichen Herausforderungen im Ausschuss der Produktion. Software-Entwicklungsprojekte sind regelmäßig einmalige Vorhaben, zu denen glorreiche Spezialisten an einem physischen oder vermehrt virtuellen Ort zusammengezogen werden. Sie setzen das definierte Vorhaben in die Tat um.

Ich glaube, diese beiden Aspekte begünstigten in der Vergangenheit den weitgehenden Verzicht auf alle prozessqualitätssteigernden Maßnahmen aus dem Baukasten des Lean Management. Die pure Möglichkeit, auch nachträglich alles ändern zu können, verführte uns dazu es auch zu tun. Der Begriff der Technischen Schuld, wie er von Altvorderen wie Martin Fowler oder Ward Cunningham definiert wird und die Vision  des »Clean Code« von Robert C. Martin zeigen eindrucksvoll, wie falsch der Ausgang aus diesem Paradies gewesen ist. Ebenso verführt die inhärente Produktstruktur von Software-Entwicklungsvorhaben Manager und Stakeholder Software-Budgets als Projekt-Budgets zu betrachten. Eine Betrachtung im Sinne der Gesamtbetriebskosten (Total Cost of Ownership) gewinnt nur langsam an Bedeutung. Meist fehlen das technische Verständnis und eine ausreichende Visualisierung von Software- und Architektur-Problemen, um Entscheidern den Zusammenhang zwischen Projekt- und Wartungs-Budgets zu verdeutlichen. Im Zweifel greift allzu oft Paradigma Nummer Eins: Was wir im Projekt nicht schaffen, machen wir im Application Management. Und schließlich werden Software-Projekte noch immer als willkommene Option zur Kostenreduktion verstanden. Je mehr Reduzierung, desto besser. Und Kostendruck bedingt Zeitdruck im Team.

Besser im Sinne der Total Cost of Ownership wäre es dagegen, alle Software-Projekte eines Unternehmens oder einer Abteilung ganzheitlich als ein Teil der Wertschöpfung zu betrachten. Aufgaben wir die Software-Integration, Qualitätsstandards, Infrastrukturen und Prozesse zur Ablage und Versionierung von Artefakten oder auch Architektur-Guidelines können projektübergreifend erarbeitet werden und dürften nicht in jedem Projekt neu zu erfinden sein. Software-Projekte sollten sich in eine unternehmensweit abgestimmte IT-Strategie einfinden. Die Änderungen an der Systemlandschaft und die Landschaft selbst müssen jedem Mitarbeiter transparent gemacht werden, wie im Visuellen Management des Lean Management (gemäß den Autoren des Praxishandbuchs einer der Schlüsselbegriffe) vorgesehen.

Hernach kann damit begonnen werden, die Werkzeuge und Methoden des Lean Managements für die IT zu adaptieren. Nicht alles ließe sich direkt anwenden, aber vieles übertragen. PDCA-Zyklen können projektübergreifend Anwendung finden und ihre langfristige Wirkung entfalten. Der Ansatz der ständigen Verbesserung (Kaizen) etablierter Standards passt gut zur prozessorientierten Arbeitsweise der Software-Entwicklung. Er greift aber nur dann, wenn die einzelne Projekte vergleichbar bleiben und Standards projektübergreifend eingesetzt werden können. Die Erhebung von Key Performance Indicators (KPI) erlaubt unter diesen Voraussetzungen das Benchmarking von Projekten mitsamt der Ableitung von Effizienzpotentialen. Die Philosophie des Genchi Genbutsu wird IT-Managern helfen, wieder ein besseres Verständnis für Problemursachen, Mitarbeiter und Dienstleister in ihren Projekten zu entwickeln. Gorecki und Pautsch nennen dazu mit Recht die verräterische, aber gängige Attitüde des „sich berichten lassen”. Richtig und notwendig ist es, selbst zum (meta-physischen) Ort der Ursache zu gehen, um die zwangsläufigen Verfälschungen durch Informationsfilter, mehrfache Beschönigungen und das unvermeidliche »Stille-Post-Prinzip« zu verhindern.

Andere Werkzeuge des Lean Management lassen ggf. nicht auf Software-Projekte übertragen oder sollten sinnvollerweise anders gestaltet werden. Der A3-Report sollte in der IT besser computerbasiert umgesetzt werden – ohne dabei die grundlegende Idee zu vergessen, alle wirklich wesentlichen Informationen übersichtlich an einem Ort zusammen zu stellen. Werkzeuge wie Sonar2 bieten dafür schon heute einen guten Ansatz, ebenso andere Management-Cockpits. Für den 8D-Report wurden in der Software-Entwicklung leistungsfähigere Analyse-Methoden entwickelt. Anstelle eine Gruppe von Beanstandungen in einem eigenen Projektteam zu hinterfragen, werden die granularen Einzelprobleme in Bug-Reports und Tickets erfasst und sytematisch computerbasiert abgearbeitet und dokumentiert. Hier fehlt es lediglich an der Identifikation von abstrakten Fehlerursachen und in jedem Fall die Ableitung von Maßnahmen, diese Ursachen in Zukunft zu vermeiden. Das bekannteste Beispiel hierfür ist wahrscheinlich die mangelhafte Dokumentation von Anforderungen.

Es bedarf somit eines Umdenkens und eines umfangreichen Transformationsschrittes, um die Lean-Philosophie in der Welt der Informationstechnologie heimisch zu machen. Dann aber verspricht dieser seit vielen Jahren im produzierenden Gewerbe bewährte Ansatz der jungen Disziplin Software-Engineering zur dringend notwendigen Stabilität und Determinierbarkeit zu verhelfen. Notwendige Voraussetzung dazu ist indes die Beseitigung von zwei gravierenden Barrieren in unseren Köpfen. Nicht alles was möglich ist, ist auch gut und richtig. Und ein Software-Budget ist kein Projekt-Budget. IT Lean Management ist dann keine Alternative oder Konkurrenz zu agilen oder klassischen Vorgehensmodellen, sondern kann eine hilfreiche Ergänzung sein, um die Gesamtbetriebskosten von Software entscheidend zu verringern, inhärente Risiken zu reduzieren und dem verantwortlichen IT-Management das Heft des Handels endlich wieder in die Hand zurück zu geben.

_____

  1. Gorecki, Pawel; Pautsch, Peter: „Praxishandbuch Lean Management”, Carl Hanser Verlag, München 2013
  2. Werkzeug zur Messung der technischen Qualität von Source-Code, http://www.sonarqube.org/

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>