Lean vs. Six Sigma

Zwei Managementphilosophien: Lean und Six Sigma

Da ist es nun, das Zauberwort: Lean Six Sigma. Die Verschmelzung zweier Denkweisen, man könnte sagen, zweier Managementphilosophien, um weniger Gutes kundenfokusiert besser zu machen. Da geht es also um das Planen, Leiten und Führen oder allgemein um das geschickte Bewerkstelligen von etwas (Management) und das dem zugehörige Streben nach Erkenntnis (Philosophie). Was heisst das praktisch? Das eine, LEAN, stellt Konzepte, Methoden und Werkzeuge bereit

• damit Kunden ihre bestellten Produkte und Serviceleistungen schnell und den jeweiligen Spezifikationen entsprechend bekommen
• Änderungswünsche (im schlimmsten Fall 'last minute requirements') flexibel und schnell einfließen können
• Die Preise für die Produkte und Serviceleistungen dem entsprechen, was an Wertschöpfung tatsächlich geleistet wurde (added value, nur dafür wollen Kunden bezahlen!).

Das andere, SIX SIGMA, stellt Konzepte, Methoden und Werkzeuge bereit

• um die Kundenzufriedenheit zu erhöhen, indem man
• Kundenprobleme oder Probleme der beteiligten Prozesse mit Hilfe von (statistischen) Daten analysiert und nachhaltig löst.
• Prozesse visualisiert und optimiert oder neue optimale Prozesse schafft
• Fehlertrends erkennt und Fehler frühzeitig eliminiert
• Risiken aufzeigt und Gefahren besser abschätzbar macht
  

Lean und Six Sigma ergänzen einander. Und sie stellen, je nach Zielsetzung und Umfang des Verbesserungsvorhabens, mehr oder weniger aufwändige Vorgehensmodelle und Werkzeuge dafür bereit. 
Dabei gilt: Je höher die Methodenkomplexität, desto höher die Anforderungen an die Methodenexpertise der betroffenen Mitarbeiter. Quick Wins und Low Hanging Fruits kann man auf Mitarbeiter- oder Teamebene schon innerhalb eine Monats erfolgreich ernten. Gelegentlich auch schon innerhalb einer Woche - oder eines Tages! 

Stellt euch vor, ein wichtiger Kunde beklagt sich bitter über die "blöde Software, die man so nicht installieren kann!". Mehr erfahren wir erstmal nicht, außer, "er habe alles so gemacht wie es im Installationshandbuch steht!" Wir beratschlagen das Thema mit dem Entwickler der Installationsroutine und stellen, nach dem Code-Review, fest: alles super! Kein Fehler - funktioniert doch!
Nein, wir schimpfen jetzt nicht über den Kunden, dass er zu *** ist um die Software zu installieren (Achtung: mindset), sondern fragen Nelly, unsere Marketingexpertin die keinerlei Erfahrung mit dieser Software hat, ob sie mal machen könnte? Nelly macht...und: Peng, Fehler!
Nelly hat alles richtig gemacht. Sie ist dem Installationshandbuch gefolgt - bis zu der Stelle, wo der neu eingebaute Betriebssystemparameter auf '1' gesetzt werden muss. Dieser Passus allerdings fehlt im Installationshandbuch (aus Gründen die noch erforscht werden müssen) und so führte diese fehlende Information, gepaart mit der unverständlichen Parametereinstellung ('was zur Hölle... bedeutet '1'?), schnurstracks ins Kaos. Am nächsten Tag war die Usability, die kundenfreundliche Handhabung der Software, über eine hoch priorisierte Fehlerbehebung (Hot Fix) verbessert und die Dokumentation korrigiert, Nelly widmete sich wieder dem Marketing, und der Kunde war zufriedengestellt (zum einen über die Qualität der Lösung, zum anderen über die Effizienz der Problembehebung). 
Maßnahmedauer: 1 Tag. Aufwand: 12 Personenstunden. Die strukturierte Ursachenanalyse als Teil der Methoden KVP und die Fault-Slip-Through (FST) Analyse, dürfte allerdings noch ein zwei Tage in Anspruch nehmen. Wichtig dabei: wir fragen nicht danach Wer Schuld hat! Danach implementieren und standardisieren wir die (mehr oder weniger aufwändig) gefundene Verbesserung, indem wir etwa die Kommunikation zwischen Entwickung und Dokumentation strukturieren und zusätzlich die Prüfung der Usability und des Installationshandbuches in unser Testverfahren integrieren.

Mitarbeiter und Team KVP werden am häufigsten angewendet (80% [8]) und bilden sozusagen 'das KVP Tagesgeschäft', denn Quick Wins und Low Hanging Fruits, sind relativ einfach zu pflücken. Kleinere Probleme treten im Alltag andauernd auf und
Lösungen dafür liegen oftmals geradezu 'auf der Hand'. Warum also nicht zugreifen?

Methodenerfolg

Methoden KVP und Six Sigma Projekte sind anspruchsvoller. Lösungen werden mithilfe (wissenschaftlichen) Methoden strukturiert erarbeitet, erprobt und standardisiert. Deshalb bieten sie auch einen höheren Nutzen. Aber sie stellen auch höhere Anforderungen an die Fähigkeiten und Kenntnisse der beteiligten Personen: die Methoden müssen bekannt sein (oben war es die FST-Analyse, andere Probleme verlangen andere Vorgehensweisen: 5S? Das kennt ihr bestimmt, und SMED? Vielleicht. Ppk? Bei nicht normalverteilten Daten? "Aber eine Prozessfähigkeitsanalyse ist doch hier für unser Problem gar nicht notwendig!", wendest du ein. "Ja, da hast du recht. Mit Kanonen auf Spatzen zu schießen, nur weil wir Kanonen haben, und gerne schießen... macht keinen Sinn!").

Dennoch: Wir benötigen Experten der Methodik. Einen erfahrenen Lean Manager oder einen Lean Six Sigma Green Belt oder Black Belt (falls die nicht normalverteilten Daten eben doch eine Rolle für unsere Analyse spielen) oder Master Black Belt, falls die Komplexität des Verbesserungsprojektes ausufert und beispielsweise Firmenbereiche an verschiedenen Standorten erfasst. Dann kommen vermutlich auch multikulturelle Aspekte ins Spiel, nationalitätenspezifische Verhaltensweisen (Umschreiben wir unangenehme Tatsachen höflich und verbeugen uns oder knallen wir die Fakten mit einem lautstarken 'Leute so nicht!' direkt auf den Tisch?) oder Zeitzonenunterschiede (gemeinsame Conference Calls, Meetings zwischen Teams in Frankfurt/Main (Deutschland), Chennai (Indien) und Sao Paulo (Brasilien), sind da manchmal etwas früh für den Einen oder zu spät für den Anderen - blöd, aber irgendwie dann doch machbar).  

Und wann sollten wir ein Six Sigma Projekt aufsetzen? Sicher nicht, wenn Nelly zur Lösung innerhalb eines Tages beitragen könnte und der Umfang nur einige wenige Personentage beträgt. Für Projekte die ein Black Belt (BB) leitet, man nennt sie sie BB-Projekte oder kurz BB's, haben sich in der Praxsis folgende Kriterien herauskristallisiert [08]: BB's sollen... 

1. der Erhöhung der Kundenzufriedenheit dienen (und kein Selbstzweck sein)
2. mindestens 20% Verbesserung in Zeit und Qualität erbringen (On Time On Quality Delivery: OTOQD >= 20%)
3. mindestens 150.000 € pro Jahr einsparen (das hängt von der Firmengröße ab)
4. maximal 6 bis 8 Monate dauern (ich denke 3 bis 6 Monate wären ein gutes Maß)
5. ein eigenes Projektteam aufweisen (3-5 Personen als Kernteam)
6. das Vorgehensmodell DMAIC verwenden

DMAIC bzw. DMAIC(R) steht dabei für die Projektphasen Define - Measure - Analyze - Improve - Control (Reinforce). Die Definition des Problemes - das feststellen / messen des aktuellen Zustandes (IST-Zustand) - die Analyse der Abweichungen, bezogen auf den IST-Zustand - die kreative Erarbeitung von Verbesserungsmaßnahmen und Prototypen, gerne auch kostengünstiger durch Simulation (der SOLL-Zustand) - die Einführung, Übergabe und Standardisierung der gewählten Verbesserung und die Sicherstellung des Projekterfolges, abgeschlossen mit einer schönen ehrlichen Feier.

Mit steigender Komplexität steigen auch die Projektlaufzeiten (schnell ist ein Jahr vorbei). Achtet darauf, den Projektinhalt, den Scope, stabil und im Rahmen zu halten! Besser zwei, drei kleinere Projekte mit Erfolgen in diesem Jahr, als ein riesengroßes mit einem Vielleicht-Erfolg in zwei Jahren! Kleinere Projekte sind überschaubarer und inhaltlich wesentlich einfacher an gegebenen Umstände anzupassen. von diesem Gedanken zehrt auch PDCA, Plan - Do - Check - Act, als kontinuierliche Problemlösungstrategie bei der man zur Problemlösung ein (wissenschaftlich orientiertes) Experiment plant (Plan), es ausführt (Do), die Ergebnisse analysiert (Checkt) und abhängig davon reagiert (Act). Entweder man implementiert und standardisiert dann die Lösung und feiert ... oder man stößt auf ein weiteres Problem das gelöst werden muss; mit anderen Worten: 'Gehe nicht über Los', ernte keine Früchte, lerne und springe direkt nach P wie Plan, um einen neuen PDCA-Zyklus zu starten.

Bis dann...
Thomas