Lean-Management in der Unternehmens-IT

Für IT- und Business-Seite gilt gleichermaßen, dass alles, was von der Idee zu einer IT-Unterstützung bis zu ihrer Produktivsetzung passiert, so schnell wie möglich passieren sollte. Was in diesem Prozess nicht direkt der Bereitstellung der Lösung dient, ist Verschwendung. Dazu gehören auch
viele Wartezeiten, zu frühe Abstimmungen von (unwichtigen) Details und große Formalitäten in der Projektetablierung. Hier vergeht in vielen Unternehmen zu viel Zeit zwischen Idee und Produktivsetzung, sodass zu viele Anforderungen in zu großen Projekten gebündelt werden und ein entsprechender Mehraufwand entsteht. Die Lösung für dieses Problem der Häufung scheint daher in möglichst kleinen Anforderungseinheiten zu liegen, die nachweislich Geschäftswert generieren.

Partner müssen mit ins Boot

Auf der IT-Seite schließlich gibt es reichlich Potenzial für Verschwendung. Werden externe Leistungen in Anspruch genommen, gehören aufwändige Einkaufsprozesse, kompliziertes Vertragsmanagement oder eine große Menge zu koordinierender Lieferanten dazu. Ein gezieltes Partnermanagement mit wenigen gut qualifizierten, zuverlässigen und flexiblen Partnern ist letztlich wirtschaftlicher, als überall nach dem Schnäppchen zu suchen. Wenn Sie konsequent lean arbeiten wollen, dann müssen auch Ihre Lieferanten lean sein. Um diese Anforderung auf beiden Seiten zu erreichen, hat Toyota beispielsweise schon eigene Leute zur Optimierung der Prozesse bei den Partnern entsandt.

Bei der Softwareentwicklung ist wiederum die Durchlaufzeit zu betrachten – von der eingeplanten Anforderung bis zu ihrer Produktivstellung.

Es ist Verschwendung, wenn Entwickler zu stark arbeitsteilig arbeiten und dadurch aufwändig ihre einzelnen Arbeitsergebnisse integrieren müssen. Stattdessen sollte diese Integration in kleinen Schritten so häufig wie möglich erfolgen.

Es ist Verschwendung, wenn unfertige, nicht einsetzbare Software existiert. Das lässt sich während der Entwicklung nicht immer vermeiden, aber der unfertige Anteil sollte so gering wie möglich gehalten werden, was nur über häufiges Ausliefern und Produktivsetzen erreicht werden kann.

Es ist Verschwendung, wenn Entwickler Technologie auf Vorrat einbauen, wenn Sie aus eigenem Interesse neue Frameworks verwenden und wenn für noch nicht existierende Anforderungen aufwändige technische Lösungen erdacht und umgesetzt werden. Solche Lösungen verlängern und verteuern die Softwareerstellung, ohne dass genau klar wäre, ob sie wirklich benötigt werden. Und wenn sie benötigt werden, dann können sie immer noch zu diesem (späteren) Zeitpunkt erstellt werden. Allerdings setzt dies – genauso wie die Arbeit in kleinen Schritten (Inkrementen) – voraus, dass die Software immer erweiterbar und anpassbar bleibt. Dieses Qualitätskriterium ist heute eigentlich selbstverständlich, fällt aber in vielen Organisationen so mancher Deadline zum Opfer.

Übrigens ist es auch Verschwendung, wenn Mitarbeiter sehr viele unterschiedliche Aufgaben oder parallel zu bearbeitende Projekte haben, denn die ständigen Kontextwechsel gehen zu Lasten der Produktivität.

Es bleibt noch zu diskutieren, warum Testen, Tests, Abstimmungsmeetings, direkter Kontakt zwischen späteren Anwendern und Entwicklern keine Verschwendung sind. Das Testen und die Tests sind notwendig zur Qualitätssicherung, dazu mehr im nächsten Abschnitt. Abstimmungsmeetings laufen in der Tat Gefahr, zur Verschwendung zu werden, wenn sie unvorbereitet sind, ohne Agenda durchgeführt werden und einen zu weiten Teilnehmerkreis haben. Dies gilt aber letztlich auch für das Management selbst. In Maßen ist es sinnvoll, zu viel davon wird Verschwendung. Die direkte Kommunikation zwischen späteren Anwendern und Entwicklern schließlich ist eine sehr effektive Art, Details zu klären – aber erst dann, wenn sie tatsächlich geklärt werden müssen.

Qualität einbauen

Qualität ist wichtig, denn IT, die nicht funktioniert, nützt nichts und behindert den Wertschöpfungsprozess. Deshalb betreiben viele Organisationen auch großen Aufwand für die Qualitätssicherung. Betrachten wir zu Beginn die Probleme nachgelagerter Qualitätssicherung: Zum einen kann nur getestet und überprüft werden, ob das, was man vorher an Anforderungen beschrieben hatte, im System entsprechend umgesetzt worden ist. Wenn man also während des Entwicklungsprozesses zu neuen Erkenntnissen gekommen ist, müssen diese auch für den Test berücksichtigt werden. Viel schwerer wiegt aber, dass Fehlerbehebungen teurer werden, je später der Fehler entdeckt wird. Das leuchtet ein, weil sich gegebenenfalls andere Teile auf das eigentlich fehlerhafte Verhalten stützen und die Entwickler außerdem bereits mit neuen Dingen beschäftigt sind und es von Tag zu Tag schwieriger wird, sich an den Kontext der Erstellung zu erinnern.

Lean betrachtet wollen wir also so früh wie möglich testen und dabei so wenig Fehler wie möglich finden. In der Lean Production wird hierfür die so genannte Reißleine verwendet, die das Produktionsband stoppt. Es wird dann nach der Ursache des Problems gesucht, und erst wenn diese beseitigt ist, wird die Produktion fortgesetzt. In diesem Sinne sollten Qualitätsstörungen auch in IT-Projekten oberste Priorität bekommen, damit die gesamten Lösungserstellungsprozesse daran ausgerichtet werden können. Erschreckenderweise haben wir uns inzwischen in Bezug auf Software daran gewöhnt, dass diese Fehler enthält. Dabei gibt es heute softwaretechnische Ansätze wie automatisiertes Testen, testgetriebene Entwicklung und automatisierte Akzeptanztests, die die Qualität von Software deutlich verbessern.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.