Fuzzy Frontend

Genau dieser im Rahmen des "Fuzzy Front End" angewandte Prozess der Ermittlung von Kundenanforderungen wird im Englischen und zunehmend auch in der deutschen Industrie mit dem Begriff „Voice of the Customer“ synonym gewertet. Im Genauen handelt es sich um eine Methode zur Ermittlung von Kundenanforderungen für ein Kundensystem. Das Ziel ist, die generellen Erwartungen und Wünsche der Kunden sowie deren Anforderungen zu einer beschriebenen Situation zu erfahren. Dies geschieht in der Regel durch strukturierte Kataloge und offene Fragen.

Damit ein Projekt am Ende ein Erfolg ist, ist die korrekte Auftragsklärung von entscheidender Bedeutung. Eine Möglichkeit, um dies zu erreichen, ist das Elizitieren von Anforderungen Das Wort Elizitieren entspricht dabei einer freien Übersetzung vom "Herauskitzeln", also jemandem etwas entlocken oder jemanden zu einer Äußerung bewegen

Hierbei werden in Kundengesprächen die Anforderungen hinsichtlich der Funktionen, Restriktionen und Leistungen, die das Systems aufweisen soll, genauer spezifiziert. Dabei werden seine Anforderungen, Bedürfnisse und generellen Wünsche an das Endprodukt beschrieben. Damit die gewünschte Detailtiefe erreicht werden kann, ist die Wahl von präzisen Fragen essenziell. Fragen wie: „Welche Stakeholder gibt es?“ werden schnell zu Missverständnissen führen können. Wird die Frage spezifiziert, gibt es weniger Spielraum für Unklarheiten: „Welche Personen bzw. Interessengruppen dürften Interesse an dem Gelingen des Projektes/Auftrages haben?“. Ein gut durchdachter Fragenkatalog ist also von signifikanter Bedeutung für eine gute Befragung des Kunden.

Voice of the Customer ist somit die Leitmethode ein "Fuzzy Front End" zu strukturieren. Ein "Fuzzy Front End" ist dabei die erste Anbahnungsphase einer möglichen Frühentwicklung, das Ergebnis von einem Voice of the Customer sollte daher ein erster Implementierungsvorschlag für eine mögliche Produktentwicklung darstellen. Faktisch lassen eine begrenzte Zahl von Innovations-Technologien ablesen, auf Basis dessen Kunden Produkte entwickeln können. Je nach Kerngeschäft lassen sich daher auch bestimmte und im Voraus definierbare "Rezepte" von "Voice of The Customer"-Prozessen definieren. Embedded Systems ist einer dieser zentralen Technologien von Innovation (innerhalb der Hauptdomäne IT, Elektronik, Software und künstlicher Intelligenz). Für allgemeine Embedded Systems, die in einem definierten Rahmen entwickelt werden, lassen sich daher auch durch das Stellen fest definierter Fragen Produkte entwickeln.

Prozessualer Kontext

Typischerweise ist ein Voice-of-the-Customer-Prozess in sieben Aspekte zu unterteilen. Innerhalb dieser Kategorien werden Informationen aus unterschiedlichen Blickrichtungen gesammelt und Ungewissheiten verringert. Jeder Aspekt wird im Folgenden genauer beschrieben.

Focus

Die Fokussierung befasst sich mit organisatorischen, verhaltensbezogenen und strategischen Fragen, um Spannungen und Probleme bei der Ressourcenzuweisung abzubauen.

Collect

Collect sammelt alle Erhebungsmethoden nach Eckdaten für Zeit und Ressourcen. Zu diesem Zeitpunkt müssen Interviewleitfäden, Protokolldateien und alle Aufzeichnungsressourcen organisiert werden. Die Interviewer werden geschult und die Erhebung wird mit den Befragten durchgeführt.

Interpretation

Unmittelbar nach der Erhebung sollten die Informationen verarbeitet werden. Die Interpretation erfolgt mit den direkt bei den Kunden erhobenen Daten und kann als Datenbasis für das Verständnis der vorliegenden Aussagen genutzt werden. Kunden geben in der Regel in der Regel vage über das, was sie erlebt haben. Außerdem neigen sie dazu Lösungen für ihre Probleme vorzuschlagen, anstatt ihre Bedürfnisse und Wünsche offenzulegen.

Structure

Eine Umformulierung der Kundenaussagen ist meist notwendig. Die Menge der Informationen muss strukturiert und auf eine überschaubare Menge von Daten reduziert werden.
Die Informationen eines einzelnen Kunden sind in der Regel recht aussagekräftig, was die aber die Analyse einer Gruppe von Kunden zeigt Muster, die sich zusammenfügen lassen. zusammengesetzt werden können.

Quantification

Es muss eine Quantifizierung durchgeführt werden, damit das Designteam verstehen kann, welche Wortlaute wichtiger sind, um ihnen die entsprechende Zuweisung von Ressourcen und Zeit zu ermöglichen. Die Frage nach der Wichtigkeit von Anforderungen ist damit essentiell an dieser Stelle. Zudem werden Anforderungen und der Implementationrahmen nach Aufwand und Kosten bewertet.

Verfication

Die Verifizierung wird mit den Kunden durchgeführt, um das codierte Verbatim für ihre Wünsche und Bedürfnisse und die ihnen zugewiesene Priorität zu bestätigen. Auf diese Weise können Fehler in Bezug auf die Informationen oder unvorhergesehene Lücken festgestellt werden.

Deploy

Schließlich wird die Umsetzung über eine Liste der Kundenanforderungen an das Entwicklungsteam durchgeführt.

Technischer Kontext

Gerade im Kontext sicherheitskritischer Software ist aufgrund der prozessualen Vorgaben eine definierte IDE oder ein definierter Compiler vorgegeben. Beispiel: Im Bahnkontext (d.h. DIN EN 5012x sind zum Beispiel Toolklassen definiert. So genannte “Werkzeuge der Klasse T3”, also Programme, die für den Code relevante und mittel oder unmittelbar beeinflussende Ausgangsdaten erzeugen, müssen an dieser Stelle genannt werden.

Herstellbarkeit und EDA-Umgebung

Nicht alle EDA-Werkzeuge sind einerseits kompatibel zueinander, andererseits sind nicht alle EDA-Werkzeuge in der Lage universell verwendbare Herstellungsdateien zu erzeugen. Gerade der Bezug zu Design Rules einzelner Hersteller und EMS-Dienstleister ist an dieser Stelle wichtig, insbesondere auch die Integration mit PLM- und EDA-Tools.

Herstellbarkeit und Schlüssel-Komponenten

In Zeiten knapper Bauteil-Verfügbarkeit ist es dringend notwendig frühzeitig Restriktionen und Konventionen bezüglich der Beschaffung und Integration von Schlüsselbausteinen wie Logik- oder Speicher-Chips auf der einen und Steckverbindern und Peripherie auf der anderen Seite festzulegen.

Quellen der Information

Grundsätzlich sind im Rahmen des Voice of the Customer sämtliche Informationen zulässig, die das System ausspezifizieren. Im Fokus stehen mündliche Informationen, Schemata wie Blockschaltbilder und Zustandsmaschinen sowie harte Anforderungen durch technisch verwandte oder verbundene Systeme. Alle die unten genannten Punkte sind daher nicht verpflichtend sondern nur mögliche Quellen von Informationen

Workshops und Klärung

In Form einer oder mehrerer Workshops sind offene oder geschlossene Fragen in strukturierten Interviews zu stellen. Das Ergebnis dieser technischen Annäherung ist nieder zu schreiben und dient dann bereits als maßgeblicher Interview für ein Voice of the Customer.

Markt des Kunden und Zielpreis

Der Kunde des Produkts oder der Dienstleistung muss sowohl den kommerziellen Anwendungsrahmen als auch mögliche Vorstellungen über den Zielpreis und die kostentechnische Erwartungshaltung teilen. Nur dann ist es möglich Zielkonflikte zu lösen und Anforderungen aus wirtschaftlicher Sicht einzuhalten.

Technische Konzepte und Technologie

Alle Grafiken, Schaubilder und systemischen Architekturen dienen der Festlegung von Ein- und Ausgangsgrößen, Schnittstellen und Verarbeitungseinheiten. Kunden einer Dienstleistung oder eines Produkts sollten einen allgemein technischen Erwartungsrahmen sowie einen grundsätzlichen Systemaufbau spezifizieren können. Dabei reicht beispielsweise schon eine grobe Beschreibung der Umgebung, in der das Endprodukt einzusetzen ist.

Verfügbare Systeme

Häufig sind Entwicklungen nicht oder nur in Teilen sprunghaft. Daher hilft ein grundsätzlicher Blick auf bereits vorhandene Systeme des Kunden und mögliche Synergien und Ähnlichkeiten. Hat ein Kunde beispielsweise bereits ein Steuergerät entwickelt, sollte der Technologiestand und die verwendeten Konzepte und Teilsysteme schriftlich festgehalten werden.

Technische Dokumentation von Zielsystem-Schnittstellen

Da Embedded Systems praktisch immer im Kontext von Sensoren, Aktoren oder verbundenen Steuergeräten und Gateways operieren, dienen Datenblätter, technische Dokumente oder Zeichnungen von verbundenen Systemen dazu, die erforderlichen Schnittstellen technisch auszuspezifizieren.

Quellen von VoC-Informationen

Zusammenfassung und Ausblick

Voice of the Customer entspricht dem Verfahren vom "Fuzzy Front End" zum konkreten Entwicklungsauftrag. Jener Prozess der Ermittlung von Kundenanforderungen für ein potentielles zu lösendes technisches Problem sollte durch strukturierte Interview, Quellen- und Dokumentenanalysen auf Basis konkreter standardisierter Fragen gelöst werden. Können darüber hinaus nicht funktionale Erwartungen in Kataloge gefasst werden, ist dies ein erster Schritt zu einem potenziellen Mission Statement, dass bei entsprechender Kontrolle in einem alle Seiten zufriedenstellenden Entwicklungsvorhaben resultiert.