Slowware oder Quickware?13 | 06 | 18
Entwickeln Sie eigentlich Slowware oder Quickware?
Neue Produktentwicklungsprozesse brauchen neue Qualitätsinstrumente.
Der Blick darauf, wie wir Produkte entwickeln, muss sich grundlegend ändern. Um unterschiedliche Arten von Entwicklungsprozessen zu charakterisieren, eignete sich früher die klassische Differenzierung zwischen Hard- und Software. Heutzutage sind es Produktkategorien, für die wir neue Begriffe benötigen, wie z. B. Slowware und Quickware und für deren Entwicklung jeweils unterschiedliche und auch neue Prozesse erforderlich sind.
Der wichtigste Treiber des notwendigen Perspektivwechsels: Zunehmend kombinieren Produkte sowohl Hard- als auch Softwarekomponenten. Das Ergebnis: Die Produkte werden immer komplexer. Während das klassische Slowware-Produkt ausgereift an die Kunden übergeben wird, erhält der Kunden die Quickware unfertig. Erst im Betrieb wird sie dann vom Hersteller kontinuierlich weiterentwickelt und aktualisiert. Die Entwicklungsprozesse von Quick- und Slowware unterscheiden sich deutlich. Slowware entsteht im klassischen Produktentwicklungsprozess, Quickware in neuartigen agilen Entwicklungsprozessen. Doch die neue Komplexität der Produkte ist kaum noch beherrschbar. Beide Verfahren bergen erhebliche Risiken, die die Anforderungen an die Qualitätssicherung signifikant verändern. Anders gesagt, die Qualitätssicherung funktioniert für die Slowware nicht mehr gut genug und für die Quickware noch nicht gut genug. Doch nun der Reihe nach.
Der klassische Produktentwicklungsansatz für Slowware – alles im Griff
Über viele Jahrzehnte haben sich beste Praktiken herausgebildet, wie Unternehmen komplexe Produkte unter Beteiligung von Lieferanten entwickeln. Die Produktentwicklungsprozesse vieler Unternehmen, die physische Produkte entwickeln, sind deshalb einander recht ähnlich.
Die Automobilbranche steht hierbei sicherlich vor einer der komplexesten Koordinierungsherausforderungen. Sie ist deswegen als Beispiel gut geeignet, zumal sich viele andere Branchen an ihr orientieren. Sie hat ausgefeilte Regelwerke entwickelt, denen die Lieferanten folgen müssen. Dazu gehören beispielsweise PPAP (Production Part Approval Process) und APQP (Advanced Product Quality Planning). Beides sind Core-Tools der IATF 16949, des für die Lieferanten verbindlichen Qualitätsmanagementstandards im Automotive-Bereich. Die zugrundeliegenden Prozesse und Methoden sind jahrzehntealt. Sie sind geprägt durch die Ansätze der Fehlerprävention und der Reifegradabsicherung. Sie wurden entwickelt, als Automobile fast ausschließlich Hardware waren, Mechanik und ein wenig Elektrik. Das konnten Ingenieure basierend auf Erfahrungswissen auslegen und berechnen. Sie haben diese komplizierten Systeme sehr weitgehend beherrscht, sie hatten alles im Griff. Dann kam die Mechatronik, die Software, die Vernetzung. Nur ein Teil der Hardware blieb Slowware, aus dem größten Teil aber wurde Quickware, mit steigender Tendenz. Und auf einmal ist alles anders, nicht nur komplizierter, vor allem um ein Vielfaches komplexer.
Die Vielzahl komplexer Systeme, aus denen das Gesamtsystem Automobil besteht, lässt sich offensichtlich nicht mehr in allen Aspekten auslegen und berechnen, das ist eine von mehreren Ursachen für die enorm gestiegenen Rückrufzahlen der Branche. Erschwerend kommt hinzu, dass die Entwicklungsdauer von Automobilen drastisch von über sechs auf unter drei Jahre verkürzt wurde.
Steigende Komplexität bei gleichzeitig verkürzter Entwicklungszeit? Für echte Slowware, die ihre Zeit zum Reifen benötigt, ist das paradox. Eigentlich sind hier Quickware-Prozesse und -methoden erforderlich.
Der agile Entwicklungsansatz für Quickware– alles im Fluss
Die Entwicklung von Software hat sich zunächst einmal grundsätzlich an den damals etablierten Entwicklungsprozessen orientiert. Vor über 20 Jahren entstand dann eine revolutionäre Bewegung, die außerhalb der Softwareentwicklung viele Jahre nahezu unbeachtet voranschritt, die agile Softwareentwicklung. Ihre vier Paradigmen und 12 Prinzipien, dargelegt im Manifest für die agile Softwareentwicklung, haben Softwareentwicklungsprozesse grundlegend verändert. SCRUM und IT-Kanban setzen diese Prinzipien methodisch und prozessual um. Dies war die Geburtsstunde der heute als Hype erlebbaren Diskussion um Agilität und der Agilisierung zunächst von Produktentwicklungsprozessen und dann ganzer Organisationen.
Die Softwareentwicklung war gerade deshalb prädestiniert für derartige Methodenwechsel und Prozessveränderungen, weil sie sehr schnell und ohne exorbitante Investitionen funktionierende Prototypen erzeugen und auf Basis des Kundenfeedbacks revidieren kann. Kunden mussten immer schon hinnehmen und haben sich daran gewöhnt, dass Software die Eigenschaften von Quickware hat, unfertig ausgeliefert und im Betrieb verbessert.
In Quickware-Entwicklungsprojekten greifen die agiles Prinzipien besonders gut:
- Inkrementell-iteratives Arbeiten:
Es ist riskant, gestützt auf Lasten- und Pflichtenheft Produkte zu entwickeln. Zwischen Start und Ziel reißt der Kundenkontakt weitgehend ab. Viele bedeutende Funktionen und Qualitätsmerkmale ergeben sich erst mit zunehmender Produktreife. Die agilen Methoden begünstigen den Test einzelner Features am Kunden, binden den Kunden insgesamt besser in den Entwicklungsverlauf ein. Dadurch entstehen besser kundenorientierte Produkte. Die Entwicklung ist auch insgesamt innovativer, da die frühen Tests es leichter machen, ins Nichts führende Entwicklungspfade zu verlassen und neue Lösungsansätze zu suchen. - Subsidiarität:
Im Entwicklungsprozess sind viele grundlegende Entscheidungen zu treffen. Eine weiterreichende Entscheidungsvorbereitung durch die Projektteams verringert das Risiko abgehobener, kundenferner Entscheidungen und erleichtern eine Revision von sich als problematisch erweisenden Entscheidungen auf der Basis von frühen Kundenfeedbacks. - Kundenbedürfnisorientierung:
Über die Sammlung der Kundenanforderungen hinaus erfolgt eine tiefgehende Analyse fundamentaler emotionaler Kundenbedürfnisse. Deren Verständnis ist Grundlage für ganz neue, innovative Lösungsansätze. Agile Methoden erleichtern es, bisherige Entwicklungspfade zugunsten von Innovationen zu verlassen.
Agilisierung ist 1. nicht so einfach und 2. nicht überall sinnvoll…
Die Agilisierungsbestrebungen zahlreicher Unternehmen setzen im Wesentlichen auf den Erfahrungen der Softwareentwickler mit neuen Methoden und neuen, teilweise digitalisierten Prozessen aber auch mit Start-up-Kulturen und Enthierarchisierungsexperimenten auf. Viele entwickelnde Industrieunternehmen, müssen als klassische Hardwareproduzenten aber dabei erfahren, dass auf Hardwareentwicklung nicht einfach übertragbar ist, was für Software und im Start-Up funktioniert. Und dass Erfahrungen mit der Agilisierung in der Entwicklung noch längst nicht auf alle anderen Bereiche sinnvoll zu übertragen sind. Sie müssen sich überlegen, ob ihre zunehmend komplexen Mischprodukte aus Hard- und Software zukünftig den Entwicklungsprämissen von Slowware oder von Quickware folgen sollen. Für viele Produkte sind agile Quickwareentwicklungsprozesse schlichtweg nicht sinnvoll.
…richtig eingesetzt aber ist Agilität ein Entwicklungsturbo –mit Risiken.
Dennoch sind die agilen Entwicklungsmethoden inzwischen weit in den Bereich der Slowware-Produkte vorgedrungen. Sie haben geholfen, Entwicklungsprozesse enorm zu beschleunigen und Produkte noch viel kundennäher zu gestalten. Aber sie haben den klassischen Fehlerpräventionsansatz weiter zurückgedrängt. Je komplexer die Produkte wurden – wie zum Beispiel ein heutiges Automobil oder Smartphone– desto zahlreicher wurden seine Funktionen. Je mehr interagierende Teilsysteme ein Produkt umfasst, je zahlreicher seine Funktionen sind, desto mehr Fehler und Fehlerursachen entstehen. Darüber hinaus erwarten viele Kunden auch eine Aufrüstung bereits genutzter Produkte mit weiteren Funktionen.
Sehr viele Effekte des Zusammenwirkens der immer zahlreicheren komplexen Teilsysteme eines Produktes, darunter sicherheitsrelevante, lassen sich im Rahmen der kurzen, agilen Entwicklungsprozesse nicht mehr antizipieren. Deshalb haben einige Hersteller Meisterschaft darin entwickelt, sofort auf Vorkommnisse im Feld zu reagieren, sie schnellstmöglich zu analysieren und in Hochgeschwindigkeit Patches („Flicken“), Upgrades (Weiterentwicklungen) und Updates (Aktualisierungen) online aufzuspielen. Das ist hochriskant, wie der Fall Samsung gezeigt hat, als 2017 Akkus des neuen Modells explodierten und sein Quickware-Entwicklungsprozess dem Unternehmen einen mehrere Milliarden Dollar kostenden Schaden und Reputationsverlust bescherte.
Quickware oder Slowware?
Jedes Unternehmen, das hybride Produkte aus Hard- und Softwaresystemen entwickelt, muss von nun an die strategische Entscheidung treffen, ob es Quickware oder Slowware entwickelt. Es muss beschließen, ob es seine Entwicklungsprozesse auf akribische Fehlerprävention oder auf blitzschnelle Fehlerkorrektur anlegt oder welcher Mix aus beidem angemessen ist. Für das Qualitätsmanagement stellt der Wechsel von der Präventation zur Korrektur einen zunächst irritierenden Paradigmenwechsel dar. Sie hat schließlich vor Jahrzehnten den genau anders gerichteten Paradigmenwechsel von Korrektur auf Prävention vollzogen und jahrzehntelang die Prävention propagiert.
Doch der Marktdruck hin zu kurzen Entwicklungszeiten ist sehr groß. Die Fehlerrisiken sind aber eklatant. Die Verantwortung ist groß, Menschen und Sachwerte nicht zu gefährden. Es gilt deshalb auch ganz klar zu erkennen, dass es nicht sinnvoll ist, echte Slowware mit hochgradig agilen Entwicklungsprozessen und zu schnell und zu agil zu entwickeln. Die große Herausforderung liegt in der enorm angewachsenen Komplexität vieler Produkte. Müssen wir uns etwa eingestehen, dass wir sehr komplexe Produkte schon längst nicht mehr präventiv absichern können, dass wir uns in einer regelwerkgestützten Scheinsicherheit bewegen? Was bedeutet das für unsere aus der Welt wenig komplexer Slowware stammenden, klassischen Regelwerke und Methoden, für PPAP und APQP, für FMEA und FTA?
Welche Qualitätssicherung wird der neuen Komplexität und Geschwindigkeit gerecht?
Doch so oder so, präventiv oder reaktiv-korrektiv. Wir müssen uns damit befassen, dass unsere klassischen Entwicklungsprozesse nicht mehr gut genug und die neuen noch nicht gut genug funktionieren. Und wir dürfen keine Blindleistung erbringen, indem wir Methoden abspulen, die keine verwertbaren Beiträge mehr leisten, keinen geeigneten Platz im Prozess mehr haben. Die agile, inkrementelle und iterative Entwicklung von Quickware bietet z. B. keinen Raum mehr für die klassische FMEA. Das dem Kunden überreichte Produkt, z. B. das Smartphone, ein millionenfach kundenindividuelles Zusammenspiel aus Hunderten Hardware- und Softwaresystemen in zusätzlicher Verbindung mit dutzenden Dienstleistungen, umfasst tausende unerkannter und vorab in ihrer Vielzahl unerkennbarer Fehlermöglichkeiten.
Qualitätssicherung heißt hier, Online-Feedbacks zu konzipieren, zu analysieren und sehr schnelle Reparaturprozesse zu organisieren. Doch nicht nur Smartphones, auch Autos sind mögliche Quickwareprodukte, die im Feld upgegradet werden. Zum einen sind auch sie so komplex, dass nicht alle Fehlermöglichkeiten präventiv erfasst werden können. Und sie sind heute ans Internet angebunden. Bestimmte Arten von Hardwareproblematiken können also auch hier bereits durch Softwareupdates kompensiert werden.
Die DGQ sucht nach neuen Qualitätssicherungsansätzen für Slowware und Quickware
Das sind spannende und herausfordernde Zeiten für Qualitätsmanager und für unser Fachgebiet. Der DGQ geht es zunächst einmal darum, die Problematik der sich verändernden, noch längst nicht ausreichend qualitätsgesicherten Entwicklungsprozesse zu verstehen und zu beschreiben. Die neuen Begriffe Quickware und Slowware sollen dabei helfen. Anschließend geht es darum, die schon eingesetzten neuen Qualitätssicherungsansätze im Kontext der neuen Settings zu bewerten, bestehende weiterzuentwickeln und weitere neue zu entwickeln. Wer dazu betragen kann und möchte, ist herzlich eingeladen.
Über den Autor: Benedikt Sommerhoff
Comments are closed.