Wissensportal Mittelstand


// Antworten auf aktuelle Fragestellungen der Digitalisierung
- Anzeige -

Auftragsstau reduziert

Wie Recaro mit Kanban Zeit spart

Michael Schweizer ist freier Autor in München.
Die Fachbereiche beim Flugzeugsitze-Hersteller Recaro konnten ihre Anforderungen an die Entwickler nicht IT-gerecht ausdrücken. Diese wiederum benötigten zu lange für die Umsetzung. Um das zu ändern, führten Director IT Andreas Hitzig und seine Mitarbeiter Kanban ein.

In der SAP- und der PLM-Abteilung innerhalb der IT von Recaro Aircraft Seating ist vieles anders als beim Kanban-Entwickler Toyota (siehe Kasten): Lagerhaltung und Zulieferer spielen in der Softwareentwicklung keine Rolle. Die Entwicklungsaufträge, die die Fachbereiche an die IT herantragen, sind individuell, reichen von kleinen Änderungen bis zu kompletten Zusatzentwicklungen und lassen sich schlechter planen als eine standardisierte Fertigung.

Ein Problem, mit dem Toyota kämpfte, war allerdings auch Recaro vertraut: der Auftragsstau. So kamen Andreas Hitzig und der Leiter der PLM-Abteilung Lucijano Horvat auf die Idee, Kanban für die Bedürfnisse der Entwicklungsabteilungen im Firmenhauptsitz in Schwäbisch Hall zu adaptieren. Dort ist die Mehrzahl der über 40 IT-Spezialisten des Unternehmens beschäftigt. International hat Recaro Aircraft Seating mehr als 2.000 Mitarbeiter, davon ungefähr 1.300 IT-Benutzer.

"Zu viele parallele Aktivitäten"

Mit Hilfe der externen Beratung Loop analysierten Hitzig und Horvat die gewohnten Abläufe: "Wir hatten zu viele parallele Aktivitäten." Zu viele Aufträge gleichzeitig waren nicht abgeschlossen, die Durchlaufzeit betrug im Durchschnitt 200 Tage. Das lag in der Hauptsache an zwei Flaschenhälsen. Der erste war der Anforderungsprozess: Die Fachbereiche schafften es in der Regel nicht, ihre Wünsche so genau zu formulieren, dass die Entwickler umstandslos an die Arbeit gehen konnten. Der zweite Flaschenhals fand sich am anderen Ende der Arbeitskette: die Validierung. Die Fachbereiche ließen sich häufig zu lange Zeit, um die gelieferten Entwicklungen zu testen.

Die Kanban-Methode

Kanban ist eigentlich nicht IT-getrieben und entstand ursprünglich auch nicht zur Lösung von Problemen bei der Software-Entwicklung. Taiichi Ohno ersann 1947 beim japanischen Autohersteller Toyota die Urversion von Kanban mit dem Ziel, weniger Rohmaterial und Halbfertigprodukte lagern zu müssen. Zur Informationsweitergabe dienten papierne Karten – Kanban bedeutet Karte, Schild oder Beleg, mittlerweile ist auch der Begriff Ticket üblich –, von denen manche dem Material und den Produkten beigelegt wurden.

Andere wurden auf einem schwarzen Brett, dem Kanban-Board, angebracht. Auf den Karten stand, was geliefert worden und was zu produzieren war. War der Auftrag abgeschlossen, wanderte, auch auf dem Kanban-Board, die zugehörige Karte weiter - erst dann durfte und musste neues Material geliefert werden. Am Kanban-Board konnte jeder sehen, wie weit die Arbeiten fortgeschritten waren und wer für weitere Aufträge frei war. In dieser Form eignet sich Kanban für eine stark standardisierte Fertigung mit stabiler Nachfrage und wenigen Sonderwünschen. Gebraucht werden schnell und präzise arbeitende Zulieferer. Taiichi Ohno führte 1950 bei Toshiba auch die Just-in-Time-Fertigung ein.

Kanban half, diese Schwierigkeiten zu beheben. Die Phase "Anforderungsanalyse" wurde eingeführt, und das Testen der Entwicklungsergebnisse wurde proaktiv durch Koordinatoren aus der PLM- und SAP-Abteilung organisiert und begleitet. Beide Stationen finden sich auf dem Kanban-Board wieder, die Anforderungsanalyse links unter der Rubrik "Backlog", die Tests am rechten Rand unter "Validation".

Solange sich in einer Rubrik zu viele Tickets stauen, holen sich die dortigen Mitarbeiter keine neuen Aufgaben (Pull-Prinzip). Die Maßeinheit für dieses "zu viele" sind die Work-in-Progress-(WiP-)Limits: Für jede Phase wurde, zuerst nach Gefühl, dann justierend, festgelegt, wie viele Aufträge gleichzeitig zu schaffen sind, anders gesagt: wie viele Karten hier auf dem Board höchstens stecken dürfen.

Kanban bald auch für den Bildschirm

Vor demKanban-Projekt entwickelte die Recaro-IT nach dem Wasserfallmodell, jetzt auch agil. Die flexiblen Rücksprachen mit den Fachbereichen, die zu Präzisierungen und Änderungen ihrer Aufträge führen können, entsprechen nicht der reinen Kanban-Lehre der Reihenfertigung, sind aber das Richtige für Recaro: Ein Auftrag dauert durchschnittlich statt 200 Tagen jetzt 50. Damit sind die Fachbereiche sehr zufrieden "und wir haben jetzt Zeit, um neue Technologien für die Fachbereiche einzuschätzen", so Hitzig.

Papier und Schreibstift machen zwar den Charme von Kanban aus. Hitzig möchte aber auch diese Tradition für Recaro modifizieren: Kanban soll digital werden. Auch die IT-Mitarbeiter und Fachbereiche, die nicht in der Schwäbisch Haller Zentrale tätig sind, sollen bald ein Kanban-Board vorfinden - auf ihren Bildschirmen.

Projektsteckbrief

Name des Projekts:Einführung von Kanban in der IT
Projektart: Prozessoptimierung in der Entwicklung
Branche: Flugzeugzulieferindustrie
Zeitrahmen: Dezember 2014 bis Juni 2015
Stand heute: In PLM- und SAP-Entwicklung abgeschlossen
Umfang: Ca. 40 IT-Mitarbeiter, Fachabteilungen
Aufwand: Ca. 20 Projektmitarbeiter, externe Beratung
Produkte: Papier, Schreibstifte, Kanban-Board
Ergebnis: Kürzere Durchlaufzeiten, mehr Zeit für innovative Themen
Herausforderung: Zwei Flaschenhälse
Nächster Schritt: Digitalisierung

Lesen Sie mehr über die preisgekrönten IT-Projekte des "CIO des Jahres 2015"


AMG CIO Breyer beschleunigt mit SAP
Bionorica teilt das Wissen der IT-Abteilung mit jedem Mitarbeiter
Über die Digitalisierung des Bundeswehr-Fuhrparks
Beharrliche Überzeugungsarbeit zahlt sich aus
Umsatzdaten in Echtzeit bei LLOYD Shoes
So sieht der Universal-Arbeitsplatz der KUVB aus

Zur Startseite