Warum Markteinführungszeitplan nicht gleich NPI-Zeitplan ist (und was dies für Test-Engineering-Teams bedeutet) 

Experten preisen die Markteinführungszeit als einen Indikator für innovative, sich schnell entwickelnde Unternehmen an. Bei NI aber hören wir aus Testmanager-Kreisen immer wieder, dass aggressive Markteinführungsziele sie und ihre Teams stark unter Druck setzen können. Wir haben unseren Spezialisten für Elektronikproduktionstests, Graham Green, gebeten, uns die Situation zu erklären und ihn gefragt, welche empfohlenen Methoden diesen Druck ein wenig verringern können.

NI: Graham, können Sie uns erklären – bevor wir uns dann den Auswirkungen zuwenden –, worin der Druck im Zusammenhang mit Markteinführungen besteht und warum er stärker zu spüren ist denn je?

GG: Kurz gesagt gibt es ihn deshalb, weil wir alle Neues wollen – und das am besten sofort. Die Rolle des Mooreschen Gesetzes bei der Beschleunigung der Prozessorleistung und der damit einhergehenden Einführung neuer Geräte auf den Markt ist gut dokumentiert. Doch es gibt noch andere Faktoren. Neue Wireless-Standards, integrierte Audioassistenten sowie die Bildschirm- und Batterietechnologie werden zu Unterscheidungsmerkmalen, bei denen es von großem Vorteil ist, als erster auf den Markt zu kommen. Ich stelle fest, dass die Geräte bei immer kürzeren Intervallen zwischen den Releases immer komplexer werden. Das setzt die Ingenieurs- und Fertigungsteams erheblich unter Druck.

NI: Wir können also davon ausgehen, dass die Entwicklungszeiten immer kürzer werden. Warum wirkt sich das besonders nachteilig auf die Tests aus?


Abbildung 1. Komprimierung im gesamten Projekt einplanen

GG: Hier ist eine Grafik, die ich seit Jahren herumzeige und die heute noch genauso zutrifft wie damals, als ich in die Branche eingestiegen bin. Sie zeigt Folgendes: Das Risiko, dass Ihr Zeitplan übermäßig unter Druck gerät, ist umso größer, je später Sie im Gesamtprozess verantwortlich sind. Es kommt selten vor, dass ich mit einem Testingenieur spreche, der nicht durch aggressive Entwicklungszeitpläne unter Druck gerät. Hinzu kommen zwei wichtige Unterschiede zwischen dem Zeitplan für die Markteinführung und dem für die Testentwicklung:

  1. Teststationen müssen lange vor der Produkteinführung bereitgestellt werden.
    Im Idealfall sind die Tester bereit für Vorproduktionsläufe, wenn eine Fertigungslinie entwickelt wird. Dies hilft dabei, Montagefehler frühzeitig zu erkennen, um den Ertrag zu maximieren, und kann Wochen oder sogar Monate vor der Produkteinführung erfolgen. Die Planer übersehen diesen Schritt manchmal.
  2. Um das Produktionsvolumen zu steigern, sind nicht nur eine, sondern viele Teststationen erforderlich.
    Man bewirkt nichts, wenn man nur eine einzelne Einheit auf den Markt bringt, sondern indem man in ausreichenden Mengen produziert, um die Marktnachfrage zu befriedigen. Der Erfolg hängt von der Fähigkeit des Testteams ab, schnell und effizient mehrere Tester zu replizieren und einzusetzen.

NI: Sehen wir uns das einmal Schritt für Schritt an. Gerade die erste Teststation zum Laufen zu bringen, scheint das Entscheidende zu sein. Was können Testingenieurteams tun, um Vertrauen dafür aufzubauen, dass sie dies zuverlässig schaffen?

GG:  Die Antwort aus dem Lehrbuch lautet, über hochproduktive Softwaretools zu sprechen oder Teamkompetenz für eine effiziente Gruppenentwicklung aufzubauen. Wenn Sie sich dafür interessieren, lesen Sie diese Ressourcen von LabVIEW- und dem Center of Excellence. Aber es gibt noch einen weniger bekannten Faktor, der die Einhaltung von Zeitplänen immens beeinflusst: die effektive Testplanung.

Die erste Planungshürde besteht darin, sicherzustellen, dass Ihre Testfälle alle Anforderungen in der Testspezifikation abdecken. Einen nicht abgedeckten Anwendungsfall erst im Nachhinein einzubeziehen, ist ausgesprochen ineffizient. Jeder von uns hat schon einmal schmerzhaft gespürt, wie es ist, Änderungen in letzter Minute vornehmen zu müssen, besonders bei hochgradig verteilten Testlinien, bei denen das Ausbalancieren der Zykluszeit entscheidend ist.

Das lässt sich vermeiden, indem man bei der Durchführung der Abdeckungsanalyse eng mit den Entwurfsteams zusammenarbeitet und Testfälle aus der Testspezifikation mit den Produktanforderungen verknüpft. „Enge Zusammenarbeit“: Natürlich ist das leichter gesagt als getan. Der schwierige Teil ist, sie im Unternehmen mit Leben zu erfüllen.

Wenn Sie sich einen gleichberechtigten Platz am Tisch sichern möchten, müssen Sie zeigen, wie die Einbeziehung der Testtechnik anderen Teams zugutekommt. Spezifikationsänderungen verursachen (gerade in späteren Stadien) normalerweise die größte Reibung. Damit sollte man anfangen. Die gemeinsame Festlegung eines Änderungsmanagementprozesses sowohl für Anforderungen als auch für Testspezifikationen sorgt für gemeinsamen Erfolg, was zu einer weiteren Zusammenarbeit führen kann. NI hat viel Erfahrung damit und unsere Teams beraten Sie gerne.  

NI: OK, nehmen wir an, Sie haben sich also auf eine Testspezifikation geeinigt, wie können Sie dann eine effiziente Entwicklung planen?

GG: Bevor wir auf etwas aufbauen, müssen wir uns auf unsere Ausgangsposition verlassen können. Wir möchten die Wahrscheinlichkeit minimieren, dass Informationen über vorhandene Ressourcen oder Funktionen fehlerhaft sind. Testingenieure lieben es, das Rad immer wieder neu zu erfinden – schließlich sind wir in die Technik gegangen, weil wir gerne Dinge herstellen. Mangelndes Vertrauen in die Korrektheit und Aktualität der Testanlage oder der Code-Bibliothek: Es könnte kaum einen besseren Vorwand geben, um einen neuen Programmcode zu schreiben.

Ich habe das immer wieder bei Ingenieuren erlebt, die sich weigern, Standardbibliotheken zu verwenden, weil sie davon überzeugt sind, dass sie es besser können. Es braucht nur ein paar fehlgeschlagene Versuche, um das Vertrauen in das neue System zu erschüttern und zu den alten Methoden zurückzukehren. Hat sich dieses Verhalten einmal verfestigt, ist es schwierig, in einem Unternehmen Änderungen voranzutreiben, so nötig sie auch sein mögen.

Bewährte Praktiken diktieren wieder einmal eine sorgfältige Prozessverwaltung. Ist in Ihrem Unternehmen geregelt, wer informiert werden bzw. abzeichnen muss, bevor die Hardware auf einer Teststation oder ein Stück wiederverwendbarer Software geändert wird? Wissen alle Beteiligten, wo diese Informationen gespeichert sind und wie diese Informationen aktualisiert werden? Zwar gibt es Softwareprodukte, die all dies im Auge behalten, doch um Erfolg zu haben, brauchen Sie die nötige Dynamik und die aktive Unterstützung durch alle Beteiligten. Dann ist es entscheidend, dass Sie diese Bibliothek pflegen, um Vertrauen zu schaffen, dass der Bestand aktuell und von hoher Qualität ist.

NI: Wie funktioniert diese Strategie in der Praxis? Können Sie uns ein Beispiel nennen?

GG: Ja, sicher. Bei der Arbeit an Ultraschallprodukten für Philips haben Neil Evans und sein Team genau das gemacht. Sie bauten eine Bibliothek von Softwaremodulen mit gut geschriebenem, verifiziertem Programmcode auf. Ihre Architektur ist von Grund auf Wiederverwendung ausgelegt.

Die bedeutendste Investition in die Standardisierung erfolgt durch ein Kernteam, das den anfänglichen Rahmen festlegt. Sobald dieser steht, ist das Hinzufügen von Updates und die Pflege von Codebasen einfacher, da zu diesem Zeitpunkt Teams aus verschiedenen Organisationen lokal mitwirken können.

-Neil Evans, Senior Manager bei Philips

Evans Team sorgte für eine probate Dokumentation des Funktionsumfangs und Anwendungsfalls jedes Moduls und ermutigte die Ingenieure zum korrekten Gebrauch. Aus dem ersten Erfolg erwuchsen natürlich Akzeptanz und Zusammenarbeit, und das Projekt gewann an Dynamik. Insgesamt erzielte das Team gegenüber vergleichbaren früheren Projekten eine 80-prozentige Reduzierung von Entwicklungsaufwand und -zeit bei der Einführung neuer Produkte (NPI) (berechnet in Ingenieurstunden pro Projekt).

NI: Bisher haben wir darüber gesprochen, die erste Teststation reif für die Freigabe zu machen. Wie sieht es mit der Skalierung von Systemen auf die entsprechenden Fertigungsvolumen aus? Wie können wir hier die Markteinführungszeit verbessern?

GG: Traditionell muss ein Kompromiss gefunden werden zwischen der Zeit, die für die Konsolidierung eines Entwurfs vor der Replikation aufgewendet wird, und der Zeit, die für die Aktualisierung replizierter Teststationen mit erst spät im Prozess eingebrachten Überarbeitungen gebraucht wird. Wenn Sie nicht in einer stark regulierten Branche (wie in der Medizingeräteindustrie) arbeiten, in der die Zertifizierung früh eine endgültige Festlegung des Entwurfs erzwingt, bedeutet ein agilerer Testansatz, dass Sie diesen Kompromiss nicht eingehen müssen.  

Wie hat man sich diese Agilität vorzustellen? Zunächst entwerfen Sie eine Teststation mit minimaler Funktionsfähigkeit für chassisbasierte modulare Instrumente, damit Sie Ihre I/O erweitern können, ohne den Platzbedarf oder das Rack-Layout zu ändern. Als nächstes verbinden Sie Ihre Teststationen per Software miteinander, um die Systemkonfiguration, die Softwareversionierung und die Daten zu verwalten. Auf diese Weise können Sie Aktualisierungen per Fernzugriff durchführen und so die Softwarebereitstellung und -wartung mit persönlicher Anwesenheit reduzieren.

Die Überbrückung der Lücke zwischen der Betriebstechnik der Teststationen und der IT-Infrastruktur wird seit langem den Testingenieuren aufgebürdet, wie häufig beklagt wird. In den meisten Fällen sind Testingenieure keine Experten für Netzwerkkommunikation, Datenbank- und Visualisierungstechnologie, was die Teams bei der Entwicklung und Wartung belastet und sie von der Arbeit an der Qualitätssteuerung im Testbereich abhält. Wenn kommerziellere Standardlösungen wie die NI SystemLink-Software in diesen Markt eintreten, können Ingenieure nicht nur immer wieder neue Iterationen des Testcodes ohne Bedenken bereitstellen, sondern erhalten auch andere Vorteile wie die Überwachung des Systemzustands, Daten zur Nutzung von Testhardware und ganzheitlichere Testdatenanalyse.

NI: Eine agile Bereitstellung und Entwicklung von Teststationen klingt gut, aber können Sie ein Beispiel dafür geben, wo dies tatsächlich geschieht?

GG: Natürlich. Nehmen wir das Team eines führenden Geräteherstellers. Ihre Fähigkeit, Testrevisionen aus der Ferne bereitzustellen und zu verwalten, rechtfertigte ihre Investition in unternehmensweite Software zur Verwaltung von Teststationen. Darüber hinaus bringt ihr erweiterter Zugriff auf Datenvisualisierungen täglich viele neue Prozessverbesserungen mit sich, was die Entwicklung weiter verkürzt und die betrieblichen Kennzahlen verbessert. Ihr Team unterhält über 170 Teststationen. Der Gruppenleiter sagt:

Indem wir SystemLink für den Prozess aus ordnungsgemäßem Herunterfahren, Installation und Neustart nutzten, konnten wir die Bereitstellungszeit für eine ganze Produktionslinie von 30 Minuten pro System auf 3 Minuten reduzieren.

-Test Engineering Manager

 

NI: Wie geht es nun weiter mit der Verbesserung der Markteinführungs- und NPI-Zeit?

GG: Ich freue mich darauf, mit maschinellem Lernen zu arbeiten, um besser zu bestimmen, was und wie wir testen, und um unsere Arbeitsabläufe zu automatisieren. Datenanalysen, die jeden Tester untersuchen, können kritische Bereiche identifizieren, die strenge Tests erfordern, sowie überversorgte Bereiche, die wir optimieren können. Wir gewinnen weiter an Wert, wenn wir mithilfe von Analysen Prozesse über alle verbundenen Tester und Anlagen hinweg einsetzen. Ich gehe beispielsweise davon aus, dass zukünftige Testprogramme automatisch über ein intelligentes, datengesteuertes System generiert werden. Wenn dies erst einmal Realität ist, können Testingenieure schnell über Entwürfe iterieren und diese optimieren. Nicht eingehaltene NPI-Zeitpläne werden dann der Vergangenheit angehören.

Erfahren Sie mehr über die Lösungen von NI für Funktionstests oder laden Sie zur vertiefenden Lektüre über Komponenten und Produkte die Lösungsbroschüre herunter. Haben Sie spezielle Fragen zu Ihrer Teststrategie oder einem bevorstehenden Teststationsprojekt? Sprechen Sie noch heute mit uns.

 

©2020 National Instruments. Alle Rechte vorbehalten. National Instruments, NI, ni.com und LabVIEW sind Marken von National Instruments Corporation. Andere erwähnte Produkt- und Firmennamen sind Marken oder Handelsmarken der jeweiligen Unternehmen. NI Partner sind eigenständige und von NI unabhängige Unternehmen; zwischen ihnen und NI besteht keine gesellschaftsrechtliche Verbindung und auch kein Auftragsverhältnis.