Beratung von Kitesurfern und Wingfoilern und Unternehmen der Kite-, Foil- und Wing-Branche

Quick Release:

Ein Quick Release ließ sich nicht auslösen oder hat überraschend von alleine ausgelöst. Somit war die Sicherheit nicht mehr gewährleistet. Zur Untersuchung der Ursachen für die Fehlfunktion des Quick Release wurde ein Ursache-Wirkungs-Diagramm verwandt.

Aufbauend auf der Ursachen-Analyse wurden Konzepte entwickelt, die fehlertoleranter gegenüber Abweichungen in der Fertigung sind, die Materialien verwenden, welche die zu erwartenden Beanspruchungen mit  einem Sicherheitsfaktor über die Nutzungzeit überstehen, die toleranter gegenüber Verschmutzungen sind und eine Fehlbedienung ausschließen. Dazu war auch eine Abschätzung der Auslösekräfte der Mechanik notwendig, bevor die Prototypen auskonstruiert und gebaut werden konnten.

Neue Bar:

Für die Entwicklung einer neuen Bar sind die wirkenden Lasten entscheidend. Um die realen Lasten auf eine Bar und die Leinen zu ermitteln, wurde in einem Vor-Entwicklungsprojekt ein Konzept entwickelt, wie Messtechnik möglichst platzsparend in eine Bar integriert werden kann, damit Tests auf dem Wasser durchgeführt werden können. Unsere Lösung ist dazu die Verwendung von Dehnmessstreifen und die Aufzeichnung der Kräfte mit einem Data-Logger. Gleichzeitig soll mit einer mitgeführten Kamera die Bar gefilmt werden. Über die Zeitmessung werden die Aufzeichnung der Kräfte und das Bar-Video synchronisiert. Für die wirkungsvolle Applizierung der Dehnmessstreifen wurde ein spezielles Bar-Ende konstruiert.

Die mit den speziellen Bar-Enden, Sensoren und sonstiger Messtechnik bestückte Bar wurde auf einem Prüfstand mit Zugversuchen kalibriert und dann auch unter realen Bedingungen im Wasser erfolgreich getestet.

Linksflieger:

Warum fliegen manche Kites ohne aktiven Steuerimpuls zu einer Seite? Weil sie bereits bei gleich verteiltem Zug auf der linken und rechten Steuerleine eine Torsion der Fronttube aufweisen. Diese Torsion der Fronttube bewirkt eine Verformung der gesamten Kitestruktur. Auf der unteren Skizze ist eine Torsion der Fronttube und die zugehörige Verformung des Kites in roten Umrißlinien eingezeichnet, bei der das linke Tip entgegen der Strömungsrichtung nach vorne geschoben ist und das rechte Tip nach hinten geschoben ist. Diese Verformung läßt den Kite nach links fliegen.

Als Ursachen für das ungewollte automatische Fliegen des Kites zu einer Seite kommen in Frage:

• Fehler in der Konstruktion
• mangelhafte Konstruktionsdaten
• Fehler in der Produktion
• Überschreitung der Fertigungstoleranzen
• Verwendung von ungeeignetem oder fehlerhaftem Material liegen, das sich unter Belastung anisotrop verhält

Die Untersuchung hat ergeben, dass die alte sogenannte "Balance-Beam-Methode" Ergebnisse liefert, die nicht mit der tatsächlichen Flug-Performance korrelieren. Für die finale Qualtitätskontrolle in der Produktion wurde deshalb eine neue Methode entwickelt, die leicht anzuwenden ist und wirklich aussagekräftige Ergebnisse liefert. Ich habe sie "Torsion Test" benannt. Die Skizze unten erläutert das Prinzip.

Fußschlaufen-/Pad-System:

Ein Fußschlaufen-/Pad-System sollte dahingehend verbessert werden, dass durchschnittliche Füße insbesondere beim Barfußfahren mehr Halt finden. Barfuß ist man sehr leicht mit der Ferse auf dem Pad hin und her und dann auch komplett aus der Schlaufe gerutscht. Außerdem mußte die Passform der Fußschlaufe optimiert werden ohne dabei die Konstruktion mit dem Verstellmechanismus stark zu verändern.

Produktentwicklungsprozess:

Durch kurze Produktlebenszyklen und definierte Budgets für die Entwicklung neuer Produkte verschafft ein ausgefeilter Produktentwicklungsprozess Wettberwerbsvorteile. Basierend auf Best Practices aus anderen Branchen (Automobil, Elektronik, Software...) wurde ein Produktentwicklungsprozess entwickelt, der in Kiteboading-Unternehmen sehr gut durchführbar ist. Unten ist ein Ausschnitt aus einem Swim-Lane-Diagramm zu sehen, der diesen Prozess beschreibt.

Basierend auf dem oben gezeigten Entwicklungsprozess lässt sich eine Work-Breakdown-Structure erzeugen, die wiederum unter Berücksichtigung der Ressourcen die Basis für den Zeitplan der Aktivitäten ist. Der Zeitplan wird mit Hilfe von Tools wie MS-Project oder ähnlichem erzeugt und ermöglicht die Planung, Steuerung und Überwachung der Produktentwicklung.

Problem-Management:

Für die kontinuierliche Verbesserung der Produkte und auch für die Kundenzufriedenheit ist es äußerst wichtig, dass Probleme schnell bearbeitet und gelöst werden. Selbstverständlich bekommen schwerwiegende Probleme eine höhere Priorität als Probleme, die nur sporadisch auftreten und nur ein wenig stören, aber die Funktion insgesamt nicht behindern. Bereits die Problem-Kategorien müssen definiert werden, aber auch der Prozess des Problem-Managements im Allgemeinen. Der Garantie-Prozess ist dem untergeordnet. Untenstehendes Swim-Lane-Diagramm zeigt ausschnittweise einen Problem/Garantie-Prozess unter Verwendung einer Issue-Management-Software (Jira).

Wie im oben stehenden Diagramm gezeigt, gibt es die Rolle/Funktion der Problem-Koordinatoren / Garantie-Manager, die dafür sorgen, dass Probleme nicht unter den Tisch fallen und die Verantwortlichen mit der Lösung beauftragt werden. Über eine Webform werden die Probleme erfasst. Nach dem automatischen Import in das Issue-Managment-System werden die Koordinatoren /Warranty-Manager über die neuen Issues benachrichtigt. Sie prüfen dann die Angaben und vervollständigen sie nötigenfalls. Handelt es sich um ein bekanntes Problem, für das bereits eine Lösung existiert, wird es von ihnen zu statistischen Zwecken gelabelt (einer Problemkategorie zugeordnet). Dem Kunden wird nach dem Standard für dieses Problem geholfen. Beispielsweise wird ein fehlerhaftes Teil gegen eine verbesserte Variante ausgetauscht oder falls nötig eine Reparatur veranlasst. Handelt es sich um ein neues Problem,  beauftragen die Problem-Koordinatoren im System die Verantwortlichen mit der Erarbeitung einer Lösung und versuchen den Kunden auf eine andere Art zu entschädigen. Beispielsweise wird ein anderes Produkt angeboten.

Im untenstehenden Eingabefenster setzen sie den Status der Garantiefall-Bearbeitung.

Da es sich bei dem Issue-Management-System (Jira) um ein Work-Flow-System handelt, ist jederzeit für Berechtigte nachvollziehbar, welche User gerade mit welchen Aktivitäten beschäftigt sind.

Management, Entwickler, Koodinatoren können sich jederzeit über geeignete Reports in Echtzeit im System (Jira) über den aktuellen Stand informieren. Untenstehend ist ein Issue-Calendar zu sehen, der genau anzeigt, an welchem Tag welche neuen Probleme erfasst wurden. Jedes farbige Rechteck stellt genau ein Problem dar. Wenn man mit dem Cursor darüber fährt, wird der Problem-Titel und die Problem-Nummer angezeigt. Beim Draufklicken gelangt man direkt zum Problem mit allen vorhandenen Informationen einschließlich detaillierter Beschreibung, Fotos und Bearbeitungsstand. Rote Rechtecke markieren schwerwiegende Probleme. Schwerwiegende Probleme mit Produkten sind Probleme, die einen Stopp der Produktion oder sogar einen Produktrückruf notwendig machen können und mit oberster Priorität sofortiges Handeln erfordern.

Untenstehendes Tortendiagramm aus einem Jira-Report zeigt die Problemkategorien, die am häufigsten auftreten. Jedes Tortenstück entspricht einer Problemkategorie. Eine Problemkategorie kann die Menge von verwandten Problemen eines Produktes sein, aber auch ein Produkt selber. Durch einen Mausklick gelangt man in Jira zu allen offenen Problemen bzw. Problemen für die noch keine Lösung entwickelt wurde.  Allen Berechtigten ist es damit möglich, in Echtzeit eine genau Auskunft über alle Probleme, die es mit den eigenen Produkten gibt, und deren Verantwortlichen zu bekommen. Dem Management gibt das die Möglichkeit die Ressourcenplanung entsprechend anzupassen.