Ist schneller wirklich immer besser?
Beinahe jede Publikation zum Thema Produktentwicklung inkludiert den Verweis auf immer kürzer werdende Produktlebenszyklen und die hohe Bedeutung der Entwicklungsgeschwindigkeit für den Markterfolg. Dabei wird jedoch oft vernachlässigt, dass Entwicklung nicht gleich Entwicklung ist und schneller sein nicht automatisch bedeutet, erfolgreicher zu sein.
Speziell wenn es um den Faktor Unsicherheit bei einem Innovationsprojekt geht, so hat dieser entscheidende Auswirkung auf den (scheinbar linearen) Zusammenhang von Entwicklungsgeschwindigkeit und Markterfolg.
Laut der aktuellen Studie „New Product Development Speed: Too Much of a Good Thing?” von Chen, Reilly und Lynn erschienen im [J PROD INNOV MANAG 2012;29(2):288–303] verhalten sich Innovationsprojekte mit hohem Unsicherheitsgrad alles andere als linear in Bezug auf Entwicklungsgeschwindigkeit und Markterfolg. Die Autoren erkennen folgenden Zusammenhang:„When turbulence or technological newness is low, faster is better, whereas when turbulence or technology newness is high, NPD teams should not pursue a blind speed strategy. In contrast, when market newness is high, faster is better, whereas moderate speed is the best under conditions of low-market newness.”
Folgende Grafik zeigt, dass es einen unmittelbaren Zusammenhang zwischen der Produktentwicklungsgeschwindigkeit und dem Markterfolg des Produktes gibt, sofern die Unsicherheiten im Entwicklungsprojekt gering sind. Bei hoher Unsicherheit hingegen, zeigt sich ein ganz anderer Zusammenhang zwischen Produktentwicklungsgeschwindigkeit und Markterfolg des Produktes. Innovationsprojekte mit hohem Unsicherheitsgrad benötigen einfach mehr Zeit um zu reifen.
Produkterfolg und Entwicklungsgeschwindigkeit
Speziell bei radikalen Innovationen zeigt sich immer wieder, dass eine zu frühe Markteinführung nicht die gewünschten Erfolge bringt. Lernschleifen müssen eingeplant werden, um technische sowie Markt- und Kundenanforderungen zu prüfen und Produktkonzepte, Prototypen sowie Geschäftsmodelle zu testen.
Geschwindigkeit ist wichtig, sollte jedoch nicht blind als Erfolgsfaktor Nummer 1 gehandelt werden. Es geht vielmehr darum den geeigneten Punkt zwischen Entwicklungsgeschwindigkeit und Markterfolg zu finden und dieser Punkt ist bei jedem Projekt ein anderer.
Scrum – Ansatz V zur Gestaltung von Innovationsprozessen
Scrum ist eine Methode des agilen Projektmanagements und stammt aus der Softwareentwicklung. Maria Tagwerker-Sturm von INKNOWAKTION hat den Artikel "SCRUM - Mögliche Anwendung als Innovations-Prozessmodell" verfasst, der sich mit der Anwendung der Erkenntnisse im Produkt-Innovationsprozess beschäftigt. Somit werden die in diesem Blog dargestellten Ansätze zur Gestaltung von Innovationsprozessen um einen wesentlichen Ansatz ergänzt.
scrum-innovationsprozess
Am Beginn steht der Releaseplan mit der Grobplanung und den Meilensteinen. Ein zweiter wesentlicher Bestandteil ist das Product Backlog, worin permanent die Anforderungen gesammelt, priorisiert und spezifiziert werden.
Die Anforderungen im Product Backlog mit hoher Priorität werden zu einem Sprint zusammengefasst und durch den Projekt-Owner oder Lenkungsausschuss freigegeben. Danach startet die Entwicklung und Umsetzung der Anforderungen. Im Sprint Backlog wird die Abwicklung gesteuert und der Fortschritt dokumentiert. Der Sprint Backlog kann eine einfache Liste mit den Anforderungen und Status (offen / in Bearbeitung / erledigt) sein. Im Weekly Scrum werden der aktuelle Projektstatus und mögliche Probleme regelmäßig im Projektteam abgestimmt.
Nach Abschluss des Sprints findet der Sprint Review statt. Hier werden die Ergebnisse durch den Projekt-Owner bzw. Lenkungsausschuss freigegeben. In der Retrospektive finden die Lessons Learned statt, um Learnings und Verbesserungspotentiale für das Gesamtprojekt abzuleiten.
Anschließend startet der nächste Sprint bis zur Produktumsetzung und dem Projektabschluss.
Die Vorteile der Methode liegen in der iterativen Vorgehensweise. Am Projektbeginn einer Neuentwicklung gibt es viele Unsicherheiten, was die Anforderungen sind, wie das Produkt am Ende aussieht und welche Schritte notwendig sind. Scrum kommt dem entgegen, indem am Beginn nur ein Grobplan (z.B. Stage-Gate) erstellt wird. Die Anforderungen werden permanent im Product Backlog gesammelt und in den Sprints schrittweise abgearbeitet.
Daher ist Scrum ideal für Forschungsprojekte und Projekt mit hohem Innovationsgrad, Risiken und Unsicherheiten, um sich schrittweise an das Ziel heranzutappen.
Siehe auch:
- http://www.inknowaction.com/blog/?p=359 (Scrum – ein neuer Ansatz für Innovationsprozesse?)
- http://www.inknowaction.com/blog/?p=410 (Was das Innovationsmanagement von der Softwareentwicklung lernen kann …)
Technologieentwicklungs- und Vorentwicklungsprojekte – Ansatz IV zur Gestaltung von Innovationsprozessen
Damit Ideen und technische Konzepte abgesichert werden können und keine "Eckigen Räder" entwickelt werden, bieten sich Technologieentwicklungs- bzw. Vorentwicklungsprojekte an.
Vorgeschaltete Technologieentwicklungs- bzw. Vorentwicklungsprojekte sind Möglichkeiten, speziell die Entwicklung technischer- und radikaler Innovationen zu ermöglichen. Neue Technologieentwicklungen sowie die Weiterentwicklung bestehender Lösungen werden dem Unternehmen zur Verfügung gestellt und fließen in die „konventionelle“ Produktentwicklung ein. Technologiestrategie, Produktstrategie oder konkrete Produktideen können Auslöser für die Initiierung von Vorentwicklungsprojekten sein. Vorentwicklungsprojekte können, müssen aber nicht, Input für den Produktentwicklungsprozess sein. Vielmehr gilt es, schon heute die Wettbewerbsfähigkeit in zukünftige Produktbereiche auszudehnen. Technologieentwicklungs- bzw. Vorentwicklungsprojekte können unabhängig von einer Produktentwicklung angestoßen oder einer konkreten Entwicklung zugeordnet sein. Eine projektunabhängige Vorentwicklung verfolgt bspw. das Ziel der Entwicklung einer neuen Technologie oder Komponente (z.B. ein neuer Sensor, der zukünftig in mehreren Geräteserien zum Einsatz kommen könnte). Eine projektabhängige Vorentwicklung verfolgt hingegen das Ziel der Schaffung einer Grundlage für ein bereits definiertes Produkt.
Im Vorentwicklungsprojekt soll weiters geklärt werden, ob die Produktideen überhaupt technisch realisierbar sind und wenn ja, unter welchen Bedingungen. Es muss überprüft werden, ob das zur Entwicklung nötige Know-how vorhanden ist und falls nicht, wo dieses beschafft werden kann. Der Prozess deckt somit die Spanne von der Technologiebewertung bis zur Machbarkeitsprüfung technischer Innovationsideen ab. Wichtige Schritte im Vorentwicklungsprozess sind:
- Gewinnung und Selektion von Ideen
- Prüfung der Machbarkeit
- Auswahl und Bereitstellung von Technologien
- Entwicklung und Test neuer Lösungsprinzipien
- Systemarchitekturen und Plattformen
Am Ende der Technologieentwicklung bzw. des Vorentwicklungsprozesses stehen Funktionsmuster, Konzeptbewertungen, Patentrecherchen, erste Prototypen und Simulationen - alles, was im Rahmen einer Entscheidung für ein Serienprojekt relevant ist, um die technische Unsicherheit zu vermindern bzw. die technische Machbarkeit zu gewährleisten. Es können verschiedene Konzepte verfolgt und dann das am besten geeignete ausgewählt werden. Dadurch können die Risiken für das Serienprojekt minimiert werden. Produktideen sollen geprüft werden, ohne an unmittelbare Wirtschaftlichkeitserwägungen gebunden zu sein. Exakte Aussagen bezüglich Zeit, Termine, Qualität und Kosten sind deshalb in dieser Phase nicht zu erwarten, ebenso wenig wie es gelingt, exakt vorauszusagen, welche Ziele tatsächlich erreicht werden, welche technischen Hindernisse auftreten und wie diese zu überwinden sind. Erste Abschätzungen sind jedoch durch die intensive Auseinandersetzung mit der Problemstellung schon möglich. Idealerweise können somit schon zu Beginn des Produktentwicklungsprozesses dank der Produktplanung und der technischen Vorklärung im Vorentwicklungsprozess relativ stabile Ziele vorgegeben werden. [1]
Das Timing der Bereitstellung von technischen Lösungen führt häufig zu folgender Fragestellung:
Muss mit der Produktentwicklung gewartet werden, bis die Technologieentwicklung abgeschlossen ist, oder kann Technik und Produkt parallel entwickelt werden?
Wird zuerst die Technik entwickelt, verlieren Unternehmen die Chance der Überlappung von Technik- und Produktentwicklung und eines insgesamt geringeren Entwicklungsaufwandes. Werden hingegen die Technologieentwicklungen in die Produktprojekte eingebettet, gehen die Unternehmen das Risiko ein, dass die Projekte an mögliche Verzögerungen in der Technologieentwicklung gekoppelt werden. Daraus ergibt sich die zentrale Entwicklungsentscheidung, wie eng Technologieentwicklung und Produktentwicklung aneinander gekoppelt werden sollen.
Tipp: Stehen sehr viele technische Lösungen zur Wahl, ist es meist besser, die Technologieentwicklung vom Projekt zu entkoppeln, um eine verfrühte Vorentscheidung für eine bestimmte Lösung zu verhindern.
Für den Produktentwicklungsprozess bedeutet das, dass ein System mindestens so variabel ist, wie die variabelste seiner Komponenten. Wenn demnach die hochvariable Technologieentwicklung in den kritischen Pfad des Projektes gelegt wird, wird der gesamte Zeitplan so unvorhersagbar, wie es die Technologieentwicklung ist. Ziele der Produktentwicklung, wie hohe Produkt-Performance bei geringen Kosten erfordern eine Lösung, die zwischen diesen beiden Extremen liegt.[2]
Während der Vorentwicklung können bereits viele Fragen bzgl. technischer Machbarkeit geklärt werden. Durch die Bereitstellung von technischen Spezifikationen des Produktes bzw. einzelnen Systemkomponenten ist die Anzahl von Änderungen bei der Serienentwicklung wesentlich geringer, was zu einem stabilen und wirtschaftlichen Entwicklungsprozess führt.
[1] Vgl. Schmelzer 2005, S. 50ff.
[2] Vgl. Reinertsen 1998, S. 128ff.
Dynamic Product Development – Ansatz III zur Gestaltung von Innovationsprozessen
Während Methoden wie Simultaneous Engineering, Concurrent Engineering oder Front Loading vorwiegend bei Produktverbesserungen eingesetzt werden, eignet sich der Dynamic Product Development Prozess vor allem für radikale Innovationen. Anders als die klassische Sichtweise, eine möglichst genaue Planung vor den ersten Entwicklungsschritten zu machen, ist die Planung in sehr kurzen Zeitabständen zu machen. Ottosson beschreibt dies wie folgt:
“Perhaps a shocking statement is that meaningful planning can only be done in very short periods of time, down to minutes in the early stages of product development when new ideas and findings can suddenly totally change the whole planning situation.”
Dynamic Product Development (DPD) basiert auf einem ganzheitlichen Ansatz. Der Prozess startet mit einem Wunsch und nicht mit einem Bedarf, wie andere Ansätze zur Gestaltung von Innovationsprozessen. Dieser Wunsch stellt eine zukünftige Situation bzw. Lösung dar.
DynamicProductDevelopment
Viele herkömmliche Ansätze von Entwicklungsprozessen starten mit Anforderungen und Bedürfnissen vom Markt. Bestehende Lösungen werden verglichen und bewertet. Erkenntnisse daraus fließen in die Modifikation der Idee mit ein, bevor ein kreativer Prozess gestartet wird. Dies hat jedoch zur Folge, dass häufig nur einzelne Details verbessert werden, völlig neue, radikale Innovationen aber nur sehr selten entstehen. Ist hingegen ein definierter und visualisierter Wunsch über zukünftige Zielvorstellungen und Lösungen Startpunkt der Entwicklung und wird basierend darauf ein kreativer Prozess gestartet, sind die Rahmenbedingungen für eine einzigartige, neue Lösung geschaffen.
Anmerkung: Ein ähnlicher Zugang bzw. eine ähnliche Vorgehensweise wurde hier auf diesem Blog bereits einmal dargestellt. Dies geschah im Rahmen der „Blue Ocean Strategy“!
Folgende Auflistung soll einen Überblick über die wesentlichen Rahmenbedingungen und Inhalte des Dynamic Product Development geben:[1]
- Eine klare Vision des erwarteten Resultats muss kommuniziert und von jedem am Produktentwicklungsprozess beteiligten Mitarbeiter verstanden werden
- Ein Konzept ist von einer eigens dafür vorgesehenen Gruppe zu erstellen - der Projektleiter ist auch in der Konzeptgruppe
- Zwischen dem Team der Produktentwicklung und der Konzeptgruppe ist ein ständiger Austausch von Informationen erforderlich
- Um auf Veränderungen und neue Möglichkeiten reagieren zu können, muss das Konzept im Zuge der Produktentwicklung kontinuierlich angepasst werden
- Die Entwicklung erfolgt in Projektteams, welche sich bei Bedarf ebenso dynamisch ändern
- Die Einbeziehung des Kunden in den Entwicklungsprozess ist entscheidend für Dynamic Product Development
- Das Pareto Prinzip (80/20- Regel) soll schrittweise bei allen Aktivitäten
adaptiert werden
- Informationsaustausch hat schnell, unlimitiert und in regelmäßigen Abständen zu erfolgen
Dynamic Product Development zeigt vor allem in den frühen Phasen des Entwicklungsprozesses klare Vorteile, setzt jedoch erfahrene Teammitglieder voraus. Erst in einer späteren Phase, wenn Detailarbeit zu leisten ist, ist der Einsatz wenig erfahrener Mitarbeiter anzuraten.
[1] Vgl. zur vollständigen Auflistung der Rahmenbedingungen und Inhalte sowie einer ausführlichen Beschreibung des Dynamic Product Development Ottosson 2002, S. 209f.
Parallelisierung: Ansatz II zur Gestaltung von Innovationsprozessen
Im Zuge der Produktentwicklung ist die Reduzierung der Entwicklungsdauer und -kosten oft wichtige Zielsetzung. Weiters sollten durch eine möglichst frühe Abstimmung verschiedener am Entwicklungsprozess beteiligter Bereiche aufwändige Änderungen vermieden und die Produktqualität in umfassendem Sinn verbessert werden. Im Entwicklungsprozess ist deshalb die simultane Entwicklung von Produkt-, Produktions- und Marketingentwicklung zu berücksichtigen.
Durch Simultaneous Engineering können beispielsweise verschiedene Produkte oder Generationen, einzelne Phasen des Entwicklungsprozesses oder lediglich Designaktivitäten auf verschiedenen Detailebenen parallel entwickelt werden.
Simultaneous Engineering
Concurrent Engineering ermöglicht beispielsweise die simultane Entwicklung aller für die Neuproduktentwicklung benötigten Prozesse und Informationen. Concurrent Engineering ist gekennzeichnet durch das Arbeiten im Team, das auch für die gesamte Entwicklung verantwortlich ist. Dieses Team trifft sich zu regelmäßigen Meetings, welche den schnellen und effizienten Austausch von Informationen ermöglichen. Kosten für Produkt- und Prozessentwicklung bei Concurrent Engineering steigen im Verhältnis zu sequentiellen Prozessen stark am Beginn der Entwicklung, da in den frühen Phasen sehr intensive Arbeit geleistet wird. Die Kosten der Produktion hingegen steigen nur langsam und sind aufgrund kurzer Iterationsschleifen für Modifikationen geringer als bei sequentiellen Prozessen. Insgesamt kann durch die Überlappung von Projektaktivitäten davon ausgegangen werden, dass bei gleicher oder sogar besserer Qualität, Entwicklungszeit und -kosten gesenkt werden können.
Front Loading hat zum Ziel, durch Transfer von problembezogenen Informationen aus früheren Projekten die Gesamtsumme an zu lösenden Problemen im Entwicklungsprozess zu reduzieren. Durch die Anwendung geeigneter Methoden und Technologien soll weiters die Geschwindigkeit der Problemlösung erhöht werden. Voraussetzung für Front Loading ist, dass ähnliche Probleme bereits früher im Unternehmen gelöst wurden und somit Informationen früher im Prozess zugänglich sind. Das ist bei inkrementalen Innovationen der Fall, sowie bei Innovationen, die auf bestehendes Markt- und Technologiewissen aufbauen.
Als besonders wichtig beim Parallelisieren von Prozessen haben sich leistungsfähige und gut funktionierende Informations- und Kommunikationswege herausgestellt. Nur durch einen raschen und unkomplizierten Datenaustausch kann ein effizientes Vorgehen gewährleistet werden.
Mögliche Einsatzbereiche:
- Bereits sehr früh im Entwicklungsprozess ist es sinnvoll, Projektaktivitäten zu parallelisieren. So kann es im Zuge der Anforderungserhebung sinnvoll sein, bereits mit Entwicklungsaktivitäten zu beginnen.
- Auch bei der Produktionsplanung ist der Einsatz von Simultaneous Engineering zweckmäßig. Sobald erste Versionen eines Produktes verfügbar sind, kann damit begonnen werden, die Produktion zu planen, während die Entwicklung parallel weiterläuft.
- Ein weiterer Einsatzbereich für Simultaneous Engineering ist die Markteinführung. Parallel zur Produktentwicklung ist diese zu planen und die Organisation ist auf die Einführung der neuen Produkte bzw. Produktfamilien vorzubereiten.
- Simultaneous Engineering kommt aber auch dann vermehrt zum Einsatz, wenn ein Hersteller mit Zulieferern oder Entwicklungsdienstleistern zusammenarbeitet. Die Herausforderungen einer folglich standortübergreifenden Entwicklung liegen im Projektmanagement, im Fehler- /Change-Management sowie im Testmanagement und in der Verwaltung aller projektrelevanten Informationen.
Mit der Parallelisierung sind jedoch auch Nachteile und Risiken verbunden. Deshalb sind Aktivitäten im Entwicklungsprozess nicht beliebig parallelisierbar. Insbesondere bei komplexen Aktivitäten mit hohem Neuheitsgrad ist zu erwarten, dass nur ein geringer Grad von Parallelisierung sinnvoll ist.
