In unserer modernen Arbeitswelt besteht die Arbeit vieler Menschen nicht mehr aus Handarbeit, sondern Kopfarbeit, was auch als „Wissensarbeit“ bezeichnet wird. Wissensarbeit zeichnet sich dadurch aus, dass sie nicht durch externen Druck beschleunigt werden kann. Wenn überhaupt, geht dies nur durch innere (intrinsische) Motivation der Wissenarbeiter. (mehr zum Thema Wissenarbeit). Der Artikel beschreibt, wie ein falsches System, effektive Wissensarbeit verhindert und den Arbeitsprozess verlangsamt. Außerdem wird ein simpler Weg zur Verbesserung beschrieben.
Als wir in die Organisation kamen, sah der Ablauf der Produktentwicklung folgende Schritte vor:
- Initiales Produktkonzept erstellen (Applikationsteam)
- Produktkonfiguration ausarbeiten (Applikationsteam)
- Produktdesign: 3D-Modelle, Stücklisten, Zeichnungen und Freigabe (Engineering-Team)
- Prototypenbau: Bauteilebeschaffung, Fertigung und Lieferung (Produktion)
- Messungen an den Prototypen (in mehreren Laboren)
- Voranalyse der Messergebnisse und Erarbeitung von Änderungsempfehlungen (in den Laboren)
- Gesamtanalyse der Messergebnisse und Optimierung des Produktkonzepts (Applikationsteam)
- Wenn nicht fertig, gehe nach Schritt 2
Das Management hatte sich vorgestellt, dass idealerweise der Ablauf etwa so aussehen sollte:
Das Problem
Leider war aber, durch den schnellen Rhythmus im Prototypenbau und Verzögerungen bei der Lieferung der Prototypen, die Zeit für die Designverbesserungen so kurz, dass das Anwendungsteam nicht hinterher kam und daher Änderungen zu schnell freigab. Auch bei der Analyse kamen die Teams nicht hinterher, so dass sie angefangen hatten, Prototypen-Zyklen zu überspringen. Dies ergab das folgende Bild mit einem stark erhöhtem Aufwand, erhöhtem Zeitaufwand und einer großen Unzufriedenheit bei allen.
Verbesserungen
Zur Lösung haben wir in einem ersten Schritt die Arbeitsweise nur aufgenommen, dokumentiert und auf einem Kanban-Board transparent gemacht.
Dann haben wir das das kritischste Messteam (gelb) in das Anwendungsteam integriert, um die Messungen besser zu priorisieren und die Ergebnisse früher und effektiver zu kommunizieren. Dies allein führte schon zu einer deutlichen Verbesserung der Stimmung im Team und einem leichten Geschwindigkeitszuwachs, weil sich die Anwendungsentwickler täglich direkt mit den Messtechnikern abstimmen konnten.
Nun wurde noch deutlicher, dass die Messungen und Optimierungen immer unter dem Zeitdruck entstanden, schnell einen neuen Prototyp zu designen und zu bauen zu müssen. Dieser „Heiße-Kartoffel“-Ansatz führte zu schnellen Schlussfolgerungen und Abkürzungen.
Zusammen mit dem Product-Owner des Anwendungsteams haben wir uns daraufhin entschieden, den Entwicklern ganz bewusst fast die doppelte Zeit zu geben, um einen gerade gelieferten Prototypenstand zu testen und zu optimieren (8 statt 5 Wochen). Ziel dabei war, die Qualität der Ergebnisse und der Optimierungen zu erhöhen. Zuerst haben uns alle für verrückt erklärt. Wir würden den ohnehin schon langsamen Prozess noch weiter verzögern.
Aber, bereits nach ein paar Iterationen haben wir festgestellt, dass die zusätzlich investierte Zeit zu Qualitätsverbesserungen und damit zu besseren Designs geführt haben. Dadurch wurden weniger als die Hälfte der Design-Iterationen benötigt und wir wurden insgesamt fast doppelt so schnell.
Weitere Verbesserungen
Mehr Simulation
Die Grundidee dabei ist, durch Simulation virtuelle Prototypen zu bauen. Wir stellten aber schnell fest, dass die Simulation nur so gut ist, wie das dahinterlegende Modell. Und das bedeutet häufig, dass die Erstellung des konkreten und komplexen Modells mehr Aufwand und Zeit benötigt als das Bauen und Testen eines Prototyps. Darüber hinaus bleibt die Unsicherheit, dass das Modell eben doch nicht die ganze Wahrheit abbildet.
Trotzdem ist der Simulationsweg nicht falsch. Es ist aber nötig, Simulationen mit der Wirklichkeit (der realen Prototypen) abzugleichen, um zu lernen, welche Design-Aspekte sich durch Simulationen abbilden lassen und welche nicht. Diese Validierung der Simulationsparameter benötigen mehr Zeit und stellen eine Investition in die Zukunft dar.
Set-based Design und Visual Knowledge als Königsweg
Dabei wollen wir zuerst Wissen erzeugen und visualisieren, durch Ermittlungen der Limitierungskurven. Danach wird das Wissen genutzt, um innerhalb des Lösungsraums geeignete konkrete Lösungen zu finden. Das klingt ggf. schwieriger als es ist. Häufig gibt es nämlich schon viele Daten aus früheren Messungen, die durch geeignete Darstellung genutzt werden können.
Ein Beispiel: Mit den bisher häufig gebauten Prototypen wurden Lebensdauertests durchgeführt, in dem je Entwicklungsstand mehrere Geräte im „Dauerlauf“ betrieben wurden und alle x Durchläufe performance-kritische Parameter nachgemessen wurden. Ein Kriterium dahinter wäre z.B., dass nach zwei Jahren durchschnittlicher Nutzung noch 80% der Leistung verfügbar sein sollen. Neben den hohen Kosten für Personal und Testbetrieb, kostet so etwas, selbst bei Dauerbetrieb, immer noch mehrere Monate Zeit, und genau die haben wir in der Entwicklung nicht. Bei genauerem Hinsehen stellte sich heraus, dass der grundsätzliche Verlauf der Degradation (Leistungsminderung) immer ähnlich aussieht.
Beim Vergleich der Kurven fiel nun auf, das man eigentlich gar keine vollen zwei Jahre Betrieb durchlaufen muss, da der Kurvenverlauf schon recht früh eine Tendenz aufzeigt, ob ein Design bestehen wird oder nicht. Heißt die Fragestellung gar „Ist Design A oder B besser?“, können wir dies noch einfacher und früher aus den Kurven lesen.
Liegen solche Daten aus älteren Messungen nicht vor, muss man anders vorgehen: Durch bewusst kleine Änderungen lernen wir, welche Design- und Parameteränderungen, welche Effekte erzeugen. Durch Aufzeichnung der wichtigsten Parameter und Darstellung als Limitierungskurven, erweitern wir unser Wissen.
Auf Set-based-Design und Visual-Knowledge werde ich demnächst in einem eigenen Artikel eingehen.