QRM Kernelement 4 – Quick Response Enterprise

Bild 1: QRM für ein «High-Mix-Low-Volume»-Umfeld

QRM wurde in den 80er Jahren des 20. Jahrhunderts von Rajan Suri an der University of Wisconsin in Madison, USA entwickelt. Siehe dazu auch den früheren Blogartikel „Born in the USA“.

Wertfabrik AG bietet in der Schweiz exklusiv QRM an, und zwar unter dem Brand Q-Time. Q-Time ist in der Schweiz alleiniges Mitglied im internationalen Netzwerk „QRM-Institute“.

QRM besteht aus den folgenden vier Kernelementen (Bild 2):

Bild 2: Die vier Kernelemente von QRM

Im den ersten drei Blogs der Reihe bin ich bereits auf die Elements „Zeit richtig sehen“, „Flexibilität organisieren“ und „Variabilität managen“ eingegangen. In diesem letzten Beitrag der Reihe teile ich mit Ihnen meine Gedanken zum vierten Kernelement.

Obwohl in QRM für Quick Response Manufacturing steht, heisst das nicht, dass QRM ausschliesslich in der Produktion eingesetzt werden kann. Im Gegenteil, bei vielen Unternehmen bildet die Produktion nur noch ein kleiner Anteil. Viel mehr Ressourcen werden in administrativen Bereichen wie Auftragsabwicklung, Planung, Steuerung, Entwicklung, Verkauf, Marketing, Controlling, IT oder Human Resources eingesetzt. Entsprechend gross sind auch die Potentiale in diesen Bereichen in Bezug auf die MCT bzw. die Durchlaufzeiten. Wie bei Lean die Lean Enterprise streben wir im QRM-Umfeld die Quick Response Enterprise an.

Anhand zweier Beispiele möchte ich Ihnen im folgenden zeigen, wie der QRM-Ansatz in indirekten Unternehmensbereichen erfolgreich angewendet werden kann.

Die traditionelle Kostenrechnung beinhaltet einige Probleme, die dazu führen können, dass falsche Entscheide gefällt werden. Zu den Problemen gehören:

• Die Kosten eines hohen Lagerbestands und eines hohen WIPs (Ware in Arbeit) werden ignoriert.
• Der Overhead wird proportional zu den direkten Kosten zugeteilt. Eine Erhöhung der direkten Kosten führt damit zu höheren Overheadkosten.
• Eine Reduktion von Lagerbestand und WIP führt zu finanziellem Verlust.

Es darf nicht unterschätzt werden, welche Kosten ein hoher Lagerbestand erzeugt.
Eine Aufstellung dazu ist in folgender Tabelle ersichtlich:

Tabelle 1: Kosten durch hohen Lagerbestand

Können wir dank QRM die Durchlaufzeiten massiv reduzieren, dann benötigen wir weniger Lagerbestände und weniger Ware in Arbeit. Damit reduzieren wir direkt auch Kosten.

Klassisch wird der Overhead proportional zu den direkten Kosten zugeteilt.

Bild 3: Klassische Zuteilung der indirekten Kosten

Das heisst, die Produkte mit hohen Stückzahlen tragen am meisten Overhead. In der Realität ist das aber genau anders. Die Produkte mit hohen Stückzahlen benötigen weniger administrativen Aufwand, als diejenigen Produkte mit geringen Stückzahlen. Klassisch „subventionieren“ damit die Standardprodukte mit hohen Stückzahlen diejenigen mit geringen Mengen. Das kann zu falschen Schlussfolgerungen und falschen Entscheiden führen. QRM geht hier einen anderen, korrekteren Weg. Dank der Bildung von QRM-Zellen in der Administration (sog. Q-ROCs, siehe Blogbeitrag 2), kann ein Grossteil der indirekten Kosten als direkte Kosten den entsprechenden Produkten zugeteilt werden. Nur noch ein geringer Anteil verbleibt als allgemeiner Overhead.

Bild 4: Korrekte Zuteilung der indirekten Kosten dank QRM-Zellen

Wer in der Entwicklung von neuen Produkten oder von neuen Dienstleistungen zu lange braucht, gerät in Gefahr, in einen Teufelskreis zu kommen, aus dem ein Ausbrechen ungeheuer schwierig wird.

Bild 4: Teufelskreis einer langen Time-to-Market

Bei einer langen Entwicklungszeit muss das Marketing die Anforderungen an das neue Produkt weit voraus voraussagen. Im Lauf der Entwicklungszeit ändern sich die Marktanforderungen unter Umständen bereits wieder, sodass die Spezifikationen angepasst werden müssen. Ein Redesign ist notwendig und die Entwicklung verliert wertvolle Zeit. Aufgrund des Redesigns verlängert sich die bereits lange Entwicklungszeit noch mehr, und der Teufelskreis ist Tatsache geworden. Die Softwareentwickler haben diese Problematik schon lange erkannt. Die Lösung dazu in der Softwareentwicklung ist die SCRUM-Methodik, welche allerdings in der Hardwareentwicklung nicht ohne weiteres 1:1 angewendet werden kann.

Ein ähnlicher Teufelskreis kann übrigens auch in der Beschaffung aufgezeichnet werden. Lange Beschaffungszeiten führen zu grossen Bestellmengen, die ihrerseits beim Lieferanten zu langen Lieferzeiten führen.

Wie können wir mit QRM-Methoden den Teufelskreis langer Entwicklungszeiten vermeiden oder durchbrechen? Vor allem durch starke Fokussierung auf die Entwicklungs-MCT. Dies gelingt mit folgenden Ansätzen:

• Vermeidung von (immer) negativem Multitasking. Bei jedem Wechsel der Tätigkeit (von einem Projekt auf ein anderes) fällt eine geistige „Rüstzeit“ an. Je öfter von einem Projekt auf ein anderes gewechselt wird, desto mehr Zeit geht verloren.
  
  

  Bild 5: Einfluss von negativem Multitasking auf die Entwicklungszeit

• WIP-Reduktion durch serielle anstelle von parallelen Aktivitäten (bei gleichen Ressourcen), d.h. Projekte hintereinander abwickeln und nicht parallel. Damit werden sie einerseits früher fertig (Time-to-Market) und benötigen andererseits auch weniger Zeit (Kosten).

  
  Bild 6: Einfluss von zu vielen parallelen Projekten auf die Entwicklungszeit

  

  Bild 7: Kürzere Entwicklungszeiten dank WIP-Reduktion.

• Limitiere der Anzahl Projekte und gleichzeitiger Aktivitäten pro Ingenieur. Die Engineering-Produktivität nimmt mit zunehmender Anzahl von Projekten massiv ab. Die optimale Anzahl Projekt pro Ingenieur ist abhängig von der Projektgrösse. Als Faustregel gilt: Maximal soll ein Ingenieur nicht mehr als zwei grosse oder drei kleine Projekte bearbeiten.

  

  Bild 8: Engineering Produktivität in Abhängigkeit der Anzahl Projekte

• Vermeidung des häufigen Zeitfressers „Warten auf Entscheidung“ durch Delegation der Entscheidungskompetenz an Projektleiter und Projektteam (QRM-Zelle). Die Vorteile von klar zugeteilten Ressourcen mit entsprechenden Kompetenzen für ein Projekt liegen auf der Hand:

  > Weniger Koordinationsaufwand.
  > Weniger Störungen durch andere Projekte.
  > Mehr Fokus.
  > Mehr Ownership und Eigenverantwortung.
  > Weniger Ressourcenkonflikte zwischen Projekten.
  > Einfachere Planung.

• Funktionsübergreifende Entwicklungsteams; frühzeitige Einbindung der Produktion.
• Frontloading, das heisst zu Beginn des Projektes möglichst alle Abklärungen treffen.

  
  Bild 9: Frontloading, d.h. möglichst alle Abklärungen zu Beginn

• Fokus zuerst auf Langläufer und risikobehaftete Komponenten.
• Übergebe Zeichnungen einzeln in die nächste Phase und nicht als Satz aller Zeichnungen.
• Mehrere kleinere inkrementelle Produkteinführungen anstelle einer grossen (analog SCRUM).
• Fokus auf vorhandene Komponenten und vorhandenes Wissen.
• Beschleunigung der Prototypen- und Testphase durch vorzeitige Reservierung von Kapazitäten in Produktion und bei Lieferanten.

Die meisten dieser Massnahmen werden auch im Lean Development angewendet.