Umgang mit Varianten

Die wichtigste Aufgabe bei der Entwicklung eines Produktes ist es, Nutzen für den Kunden zu stiften und den Kundenwunsch zu erfüllen. Doch oft wollen nicht alle Kunden das Gleiche. Und schon hat man es mit mehreren Varianten zu tun. Doch Varianten haben auch Nachteile. Die Komplexität und der Entwicklungsaufwand nehmen deutlich zu. Auch die Pflege der Produkte wird komplizierter. Grund genug, sich mit dem Thema Varianten zu beschäftigen.

Warum gibt es Varianten?

Die Anwendung eines Produktes kann sich stark unterscheiden. Insbesondere in der Medizintechnik gibt es verschiedene Nutzergruppen und damit auch Nutzungsszenarien. Was für eine Nutzergruppe ein sehr wichtiges Feature ist, kann für eine andere unwichtig sein. Dann kann es sinnvoll sein, das Produkt kundenspezifisch zu konfigurieren, um z.B. das Produkt kostengünstiger anbieten zu können.

Ein anderer Grund für Varianten, können gesetzliche Anforderungen für verschiedene Länder oder Märkte sein. Es gibt keinen einheitlichen weltweiten Standard für Medizinprodukte und so muss man sich mit allen länderspezifischen Anforderungen herumschlagen.

Varianten können auch entstehen, wenn sich ein Produkt technisch weiter entwickelt und z.B. neue Komponenten eingesetzt werden.

Vorgehen in der Entwicklung

Der erste Schritt ist immer die Variante zu hinterfragen. Kann man eine Variante vermeiden, so ist das die beste Lösung! Schließlich erhöhen Varianten den Entwicklungs- und Testaufwand, steigern die Komplexität und meist auch die Herstellkosten. Daher sollte man sich sicher sein, ob eine Variante wirklich notwendig ist, oder ob man diese weglassen oder anders realisieren kann.

Falls Weglassen keine Option ist, dann ist zu prüfen, ob eine Variante auf Software begrenzt werden kann. Auch Software-Varianten ziehen Arbeit nach sich, sind aber bei weitem nicht so aufwändig wie Varianten, die Hardware und Mechanik betreffen. Sofern möglich, sollte man die Varianten durch Software-Varianten oder Konfigurationen realisieren.

Die Architektur muss so modular gestaltet sein, dass die Grundarchitektur für alle Varianten erhalten bleibt. Es werden dann im besten Fall nur Komponenten eins zu eins ersetzt, hinzugefügt oder einfach weggelassen, um Varianten zu realisieren.

Varianten sind in der Systemarchitektur zu dokumentieren. Mit SysML können Varianten modelliert werden. An dieser Stelle kann ich das Buch “Systems Engineering mit SysML/UML” von Tim Weilkiens empfehlen. Falls sie aber noch keine Erfahrung mit SysML haben, dann rate ich Ihnen im ersten Schritt davon ab. Eine einfache Möglichkeit, wie man sich mit einer Mindmap einen Überblick über die Varianten verschaffen kann, sehen sie in der Abbildung unten. Ich verwende dazu das Werkzeug XMind.

Varianten mit Mindmap modellieren

Aus dem Grundgerät werden Varianten immer weiter aufgegliedert bis alle Varianten ersichtlich sind. Diese werden eindeutig benannt, so dass die Varianten unterscheidbar sind. In dem Beispiel ist Variante A3 eine von 7 vorhandenen Varianten. Nachdem wir alle Varianten identifiziert und benannt haben, kann man damit beginnen die Unterscheidungsmerkmale der Varianten zum Grundgerät zu dokumentieren. Hier empfiehlt sich das Muster:

  1. Was ist der Zweck dieser Variante?
  2. Wie unterscheidet sich die Variante zum Grundgerät?
  3. Ergeben sich aus dieser Variante Auswirkungen für das Risikomanagement?

Es ist wichtig zu prüfen, dass die System-Architektur für alle Varianten geeignet ist! Für die Betrachtung der Varianten kann, falls erforderlich, ein Kapitel in der System-Architektur Spezifikation verwendet werden. Teile des Systems, die variantenspezifisch sind, können graphisch hervorgehoben werden.

Anforderungen und Tests für Varianten

Für die Verwaltung von Anforderungen und Tests sind Werkzeuge notwendig. Spätestens, wenn sie Varianten verwenden, kann man Word und Excel definitiv vergessen. Denn die Varianten führen dazu, dass die Anforderungen und Tests sich für die verschiedenen Varianten unterscheiden können. Als Beispiel ist die Akkulaufzeit eines mobilen Gerätes abhängig davon, was verbaut ist. Die Varianten können auch zu einem unterschiedlichen EMV-Verhalten beitragen. Der Testaufwand kann mit den Varianten erheblich steigen. Es ist jedoch nicht notwendig und sinnvoll alles mit jeder Variante zu testen. Mit einem guten Anforderungswerkzeug kann man die Varianten als Attribut den Anforderungen und Tests zuweisen. Damit ist es einfach möglich sich die Anforderungen und Tests für jede Variante auszuleiten. Im Rahmen einer Impact-Analyse muss bewertet werden, welche Tests für welche Varianten durchzuführen sind.

Der Umgang mit Varianten kann sehr komplex werden und die Herangehensweise muss sich daran orientieren, wo sie gerade stehen und was ihnen nutzt. Es gibt Unternehmen, die bereits sehr viel Erfahrung mit dem Thema haben und eben welche, für die das Thema noch recht neu ist.

Ich freue mich sehr über Feedback und den Austausch mit ihnen. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.

Viele Grüße
Goran Madzar

Auch interessant:

Podcast über Systemarchitekten in der Medizintechnik

Ich freue mich sehr darüber, dass mich Maik Pfingsten zu einem Podcast-Interview eingeladen hat. Wir sprechen über Systemarchitekten in der Medizintechnik, eine durchaus seltene Spezies. Für mich war es eine…

Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Wir haben ein Ingenieurbüro im Innovations- und Gründerzentrum in Erlangen aufgebaut. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Getagged mit: , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.