Produktmanagement mit iQUAVIS

Wie lassen sich strategisches Produktmanagement und modellbasierte Systementwicklung (MBSE) effektiv miteinander verbinden? Und wie kann ein Tool diese Zusammenarbeit konkret unterstützen? 

In diesem Webinar zeigen wir, dass modernes Produktmanagement und MBSE nicht nebeneinander, sondern integriert funktionieren – von der frühen Marktanforderung bis zur Systemarchitektur. Anhand des Tools iQUAVIS demonstrieren wir praxisnah, wie verschiedene Aufgaben entlang des Produktlebenszyklus unterstützt werden können: 

– Strukturierung und Nachverfolgung von Anforderungen 

– Verknüpfung von Marktanforderungen mit Systemmodellen 

– Transparente Ableitung von Funktionen und Architekturen 

– Ableitung von Varianztreibern und Feature-Roadmaps 

– Abschätzen von Kosten für Funktionen und Konfigurationen 

– Verbesserte Zusammenarbeit zwischen Produktmanagement und Entwicklung 

Das Webinar richtet sich an Produktmanager, Systemingenieure, Entwicklungsleiter und alle, die Strategie und Technik enger verzahnen möchten. 

Anmeldung

Tragen Sie sich in das Formular ein, und Sie erhalten Zugang zu der Aufzeichnung. Bitte beachten Sie, dass Sie Cookies akzeptieren müssen, um das Formular zu sehen (oranger Button unten links im Bild).

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Hinzufügen vorhandener Daten in Arbeitsblätter

Die Nutzerunterstützung beim Einfügen vorhandener Daten wurde erweitert. Beim Suchen vorhandener Daten werden diese nun auch hierarchisch dargestellt. Zudem gibt es Freitextsuche. Damit können Daten nun besser überblickt und schneller gefunden werden (Abb.1).

Suche im Baum

Es ist nun möglich Modellelemente zu suchen (und zu finden) auch wenn diese in der Baumdarstellung ausgeblendet sind. Mit der v10 kann der gesamte Pfad eines Elements im Baum über die Datenliste eingeblendet werden. Das ermöglicht eine schnellere Suche, gerade in großen Projekten. (Abb.2)

Auch diese Neuerung geht auf den Input unserer Kunden aus dem DACH-Raum zurück, die wir strukturiert an unsere japanischen Kollegen weiterleiten. Wir arbeiten sehr eng mit den Kollegen dort zusammen und tauschen uns regelmäßig aus – zuletzt hat unser IT-Experte Georg ein paar Tage in Japan in der Zentrale von DENTSU SOKEN verbracht.

Erweiterung der Historiensuche auf sämtliche Speicherstände

Neben der Historienliste, die es schon länger in iQUAVIS gibt, gibt es jetzt die „Gesamte Verlaufssuche“ (Abb. 3). Das bedeutet:

• Jeder einzelne Speicherstand ist hier aufgeführt, unabhängig davon, ob ein Historienstand erzeugt wurde oder nicht.
• Die Speicherstände lassen sich wie Historienstände öffnen und durchsuchen.

Video

Wir haben die Neuerungen auch in einem kleinen Video auf unserem YouTube-Kanal zusammengefasst:

Weitere Änderungen

Im Rahmen des v10 Updates kommen noch weitere, kleinere Updates:

• Die Update Buttons für Architektur und Projektplan sind nun zu einem Button verschmolzen.
• Strg+K funktioniert innerhalb von Tabellen auch auf für Attribute (passende Spalte wird ausgewählt)

• „Verantwortlicher“ ist im Tooltip anzeigbar
• Ablaufplan:
  • Veränderte Tasks hervorheben
  • Untergeordnete Tasks einklappen

Wann kommt die v10?

Unsere Kunden bekommen die v10 im Laufe der Monats Mai automatisch eingespielt. Haben Sie Interesse an iQUAVIS, nehmen Sie gern Kontakt auf.

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Wie Produktlinien systematisch entstehen

Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der Regel wird dabei zwischen Domänen-Engineering und Anwendungs-Entwicklung unterschieden. Doch was passiert eigentlich in diesen beiden Phasen und wie unterstützt iQUAVIS bei der Umsetzung dieses Ansatzes? 

Zwei mal zwei Perspektiven 

Im Schaubild Abb. 1 unten ordnen wir die wesentlichen Fähigkeiten von iQUAVIS ein. Das Bild ist horizontal in zwei Bereiche unterteilt: Links: Domänen-Entwicklung, die sozusagen die wiederverwendbaren Kernartefakte in den Blick nimmt. Rechts: die Anwendungs-Entwicklung, die auf ein konkretes Produkt fokussiert.

Vertikal werden zwei Ebenen unterschieden: Oben, die Marktperspektive, die Feature und Konfigurationen für die Kunden beschreibt, sowie unten die Architekturperspektive, in der es um die technische Basis geht, um ebendiese Feature realisieren zu können.

Domänen-Entwicklung: Die gemeinsame Basis schaffen 

Den methodischen Einstieg in die Domänen-Entwicklung bildet das Feature-Modell. Es repräsentiert die Marktsicht einer Produktlinie. Dabei ist ein Feature ein vom Kunden bestellbares Merkmal. Ein Feature fasst inhaltlich funktionale und nicht-funktionale Anforderungen zusammen.

Folgende Fragestellungen stehen hinter der Feature-Modellierung: 

• Welche Feature werden oder sollen zukünftig am Markt angeboten werden? 
• Wo gibt es Variabilität? 
• Welche Feature bedingen sich oder schließen sich aus? 
• Welche Features sind optional oder verpflichtend? 

Das Feature-Modell beschreibt also nicht ein einzelnes Produkt, sondern die gesamte Lösungsdomäne. Es ist das zentrale Kommunikationsmittel zwischen Vertrieb, Produktmanagement und Technik. 

Die Lösungsbausteine zu dem beschriebenen Feature-Modell finden wir in der Architekturperspektive in Form von Modulen bzw. architektonischen Bausteinen. Bei der Entwicklung dieser Bausteine zielt man auf: 

• Wiederverwendbare Komponenten 
• Architekturelle Muster 
• Schnittstellen 
• technische Variationspunkte 

Jeder Baustein ist so entworfen, dass er für viele Produkte wieder verwendbar ist. Variabilität wird bewusst eingeplant – nicht als Sonderfall, sondern als Kernprinzip. Das Ergebnis der Domänen-Entwicklung ist damit: 

• ein Feature-Model für die Markt‑ und Produktsicht 
• eine Referenzarchitektur aus Modulen/Bausteinen für die technische Umsetzung 

Anwendungs-Entwicklung: Konkrete Produkte bauen 

Während die Domänen-Entwicklung sozusagen die Bühne aufbaut, beginnt in der Anwendungs-Entwicklung die konkrete Ausprägung . 

Im oberen rechten Bereich des Schaubildes sieht man die Konfigurationen. Hier wird das Feature-Modell verwendet, um konkrete Produkte zu definieren: 

• Auswahl der Feature, aus denen ein konkrete Produkt besteht
• Berücksichtigung der Einschränkungen des Feature-Modells (Varianten, Optionen etc.)

Eine Konfiguration ist damit eine gültige Auswahl aus dem Feature-Model – sie beschreibt genau ein Produkt.

Aus der Konfiguration wird auf der Architekturebene im unteren rechten Bereich die Produktarchitektur abgeleitet. Das Schaubild zeigt: 

• Die Produktarchitektur entsteht nicht neu, sie wird aus den Bausteinen oder Modulen zusammengesetzt 
• Die Konfiguration steuert, welche Bausteine wie kombiniert werden 
• Aufgabe der Produktarchitektur ist die technische Plausibilisierung, also ob die Module über ihre Schnittstellen so zusammenpassen, wie es die Konfiguration definiert

So entsteht eine konkrete, lauffähige Architektur, die genau die zuvor gewählten Features unterstützt. 

Die Domänenentwicklung liefert also die Bausteine – die Anwendungsentwicklung setzt sie zusammen. 

Die Verbindung zwischen beiden Welten 

Ein zentrales Element des Bildes sind die Verbindungen: 

• Das Feature-Modell verweise auf die architektonischen Bausteine 
• Die Bausteine werden in konkreten Produktarchitekuren verwendet
• Eine Konfiguration verweist auf eine (plausible) Kombination von Featuren und die daraus abgeleiteten Lösungselemente

Genau diese Durchgängigkeit unterscheidet Product Line Engineering von klassischer Wiederverwendung oder Copy‑&‑Paste‑Entwicklung. Die Verknüpfung von Marktanforderungen bis zur technischen Umsetzung erfolgt modellbasiert und ist die Grundlage für Kommunikation und Kooperation Produktmanagent und Technik. Entscheidend ist, dass das aufgebaute Beziehungswissen nun in den unterschiedlichen Phasen der Produktentstehung genutzt wird:

• Für die Produktroadmap werden Feature zeitlich aufgeplant
• Die Architektur berücksichtigt die bestehenden Feature und die kommenden Feature (Big Picture) und wird entsprechend ausgelegt
• Technische Entscheidungen finden nicht isoliert, sondern vor dem Hintergrund ebendieser Planung statt
• Auch technische Risiken für bestimmte Feature oder Opportunitäten, die sich aus einer neuartigen Kombination von Lösungselementen ergeben könnten, werden auf dieser Basis erarbeitet
• Qualitäts- oder Risikomethoden berücksichtigen, in welchen Konfigurationen sich eine bestimmte Funktion oder Lösung befindet kann
• Bereits abgesicherte Module können wiederverwendet werden

Diese Liste an Nutzungsmöglichkeiten ließe sich noch weiter fortführen.

Wie unterstützt iQUAVIS bei diesem Ansatz? 

iQUAVIS bietet die notwendigen Toolfunktionalitäten, um den beschriebenen Ansatz umzusetzen. Es beinhaltet die Möglichkeit, Feature-Modelle zu definieren und entsprechende Abhängigkeiten zu modellieren. Die Feature können Lösungselementen zugeordnet werden. Bedingungen wie Exclude oder Mandatory können in verschiedenen Sichten angezeigt und bearbeitet werden (vgl. Abb. 2-4).

Der VariantenManager in iQUAVIS bietet darauf aufbauend die Möglichkeit, Varianten konkret auszuprägen – natürlich unter Berücksichtigung der Bedingungen des Featurebaums.

iQUAVIS bietet auch die Möglichkeit, wiederverwendbare Architekturbausteine anzulegen. Es stellt alle gängigen Modellierungsmethoden des MBSE zur Verfügung, um die Architekturbausteine in konkreten Systemmodellen zu nutzen.

Webinaraufzeichnung: Variantenmanagement für das Product Line Engineering

In diesem Webinar über Variantenmanagement mit iQUAVIS für das Product Line Engineering erhalten Sie einen praktischen Einblick. Beachten Sie zum Thema Varianten auch diesen Beitrag über Varianz im Systemmodell.

• 
  Produktmanagement mit iQUAVIS – Aufzeichnung
  von Sonja Feierabend
  26. Mai 2026
  Wenn Sie unser Live-Webinar über Produktmanagement mit iQUAVIS verpasst haben, erhalten Sie nun eine Chance, sich die Aufzeichnung anzusehen. Produktmanagement mit iQUAVIS Wie lassen sich strategisches Produktmanagement und modellbasierte Systementwicklung (MBSE) effektiv miteinander verbinden? Und wie kann ein Tool diese Zusammenarbeit konkret unterstützen?  In diesem Webinar zeigen wir, dass modernes Produktmanagement und MBSE nicht nebeneinander, sondern
• 
  iQUAVIS v10 – Update 2026
  von Christian Dr. Bremer
  19. Mai 2026
  Aus Japan hat uns die iQUAVIS v10 erreicht, an der wir noch einige Anpassungen für den europäischen Markt vorgenommen haben, damit iQUAVIS bei all unseren Kunden reibungslos läuft. Die wichtigsten Neuerungen der v10, die demnächst ausgerollt wird, stellen wir in diesem Blogartikel einmal vor. Hinzufügen vorhandener Daten in Arbeitsblätter Die Nutzerunterstützung beim Einfügen vorhandener Daten
• 
  Product Line Engineering mit iQUAVIS
  von Christian Dr. Bremer
  5. Mai 2026
  Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung aufzeigen. Wie Produktlinien systematisch entstehen Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Ende Januar 2026 hatte unser ITler Georg die Gelegenheit, für eine Woche nach Japan zu fliegen und dort die japanischen Kollegen, die er aus Online-Calls und Emails kannte, persönlich kennenzulernen. Er hat viele Eindrücke und Bilder mitgebracht. In einem Interview lässt er das Erlebte Revue passieren.

Arbeiten in Japan vs. Arbeiten in Deutschland: Was ist anders? 

Du hast DENTSU SOKEN „von innen“ kennengelernt. Wie würdest du die Arbeitsatmosphäre oder das Arbeiten generell im Vergleich zum Arbeiten in Deutschland beschreiben?

Was mir ziemlich schnell aufgefallen ist: In Japan sind Hierarchien deutlicher spürbar als bei uns. Entscheidungen werden sehr gründlich vorbereitet, intern abgestimmt und quasi „vorgegart“, bevor sie offiziell im Meeting landen. Wenn man dann zusammensitzt, wirkt alles extrem strukturiert und durchdacht – große Überraschungen gibt es selten. In Deutschland diskutieren wir Themen oft direkt im Termin, manchmal auch spontan oder kontrovers.

In Japan läuft das ruhiger, harmonischer und insgesamt sehr koordiniert ab. Auch der Teamgedanke ist stärker ausgeprägt. Es geht weniger darum, wer eine Idee eingebracht hat, sondern darum, dass das Ergebnis als Gemeinschaftsleistung überzeugt. Dieses „Wir vor Ich“ war deutlich spürbar.

Die Kommunikation ist ebenfalls anders: Feedback wird eher indirekt und sehr diplomatisch formuliert. Man lernt schnell, zwischen den Zeilen zu hören. Gleichzeitig ist die Professionalität beeindruckend – Pünktlichkeit, Vorbereitung und Respekt sind selbstverständlich. Meetings sind perfekt vorbereitet, Unterlagen klar strukturiert. Da merkt man schon, wie hoch der Anspruch an Qualität und Sorgfalt ist.

Das klingt nach sehr konzentriertem und fokussierten Arbeiten. Was hat dich besonders beeindruckt?

Mein Eindruck von DENTSU SOKEN war durchweg positiv. Die Atmosphäre war sehr fokussiert und respektvoll, aber keineswegs steif. Es herrschte eine angenehme Ruhe, die fast schon ansteckend war – jeder wusste, was zu tun ist, und arbeitete sehr konzentriert. Besonders spannend fand ich, wie selbstverständlich Teamarbeit dort gelebt wird. Niemand drängt sich in den Vordergrund, das gemeinsame Ziel steht klar im Fokus.
Was mich ebenfalls beeindruckt hat, war die Detailgenauigkeit. Präsentationen, Prozesse und Abstimmungen wirkten bis ins Kleinste durchdacht. Man merkt einfach, dass viel Wert auf Qualität gelegt wird. Gleichzeitig habe ich Offenheit und echtes Interesse im Austausch erlebt – auch gegenüber internationalen Partnern. Insgesamt hatte ich das Gefühl, ein Unternehmen zu erleben, das Struktur, Teamgeist und hohe Professionalität sehr konsequent miteinander verbindet.

Du hattest in Japan auch direkt mit den Entwicklerteams von iQUAVIS und i-SPiDM Kontakt. Welche Schwerpunkte werden da gesetzt und was können unsere Kunden in Europa zum Beispiel von der v10 erwarten, die demnächst ausgerollt wird?

Im Austausch mit den Entwicklerteams wurde deutlich, dass die aktuellen Schwerpunkte vor allem auf Benutzerfreundlichkeit, Performance, Schnittstellen und besserer Zusammenarbeit in Projekten liegen. Themen wie Datenmanagement, Versionsverwaltung und Nachverfolgbarkeit werden weiter ausgebaut. Von der Version 10 können unsere Kunden in Europa vor allem eine Performance-Verbesserungen sowie neue Funktionen im Bereich Collaboration und Integration in andere Systeme erwarten.

Das klingt ja super! Würdest du den Austausch mit den japanischen Kollegen als fruchtbar beschreiben? Was hilft dir hier in Deutschland bei deiner Arbeit?

Ja, der Austausch war auf jeden Fall sehr fruchtbar. Der persönliche Kontakt hilft sehr, Anforderungen und Probleme schneller zu klären und ein besseres Verständnis für die Produkte und die Produktstrategie zu bekommen. Für meine Arbeit in Deutschland ist besonders hilfreich, dass ich jetzt die richtigen Ansprechpartner kenne und Kundenanforderungen gezielter nach Japan kommunizieren kann. Außerdem erleichtert das Verständnis der Arbeitsweise die Zusammenarbeit im Alltag deutlich.

Welches Fazit ziehst du aus deiner Reise?

Die Reise war für mich mehr als nur ein beruflicher Termin im Kalender. Sie hat mir nochmal gezeigt, wie unterschiedlich Arbeitskulturen funktionieren können – und dass genau darin eine große Chance liegt. Wir können viel voneinander lernen: von der japanischen Gründlichkeit, dem starken Teamfokus und der beeindruckenden Professionalität – genauso wie von unserer direkten Art und unserer Diskussionsfreude.

Die Two Pillars GmbH hat ihren Sitz im ostwestfälischen Paderborn und vertreibt die MBSE-Software iQUAVIS in der DACH-Region. Unsere aktuellen Stellenausschreibungen finden Sie hier.

Einordnung in den RFLP Ansatz

Wir fokussieren uns in unserem Beitrag auf Varianz, die auf Systemebene entsteht. Betrachten wir ein Systemmodell nach dem RFLP-Ansatz, tritt Varianz typischerweise auf funktions-, logischer- und physischer Ebene auf. 

Auf Funktionsebene geht es typischerweise um mögliche alternative Funktionsumfänge, die das Produkt aufweisen kann. In diesem Zusammenhang wird an Stelle einer Funktion häufig auch der Begriff „Feature“ verwendet. Beschrieben wird, welche Funktionen oder Feature, ein Kunde wählen kann oder am Markt angeboten werden sollen.

Auf logischer Ebene wird dann zugeordnet, wie eine Funktion umgesetzt wird. Dabei findet man jedoch nicht unbedingt immer eine 1:1 Zuordnung, es wird vielmehr in Betracht gezogen, ob ein Systemelement bspw. mehrere Funktionen umsetzen kann oder ob eine Überspezifikation zugunsten einer Teileersparnis Sinn macht. Darüber hinaus kann es auch gut sein, dass Funktionen, die ähnlich klingen und vermeintlich nur geringfügige Unterschiede aufweisen, mit anderen Technologien oder unterschiedlichen Produktfamilien umgesetzt werden. Dementsprechend ergibt sich der Variantenbaum aus genannten Überlegungen und ist daher in der Regel kein einfaches Spiegelbild des Funktionsbaums.

Auf physischer Ebene wird die konkrete Umsetzung mit einem Bauteil definiert. Auf dieser Ebene spiegelt sich Varianz bspw. in Bauteilen wider, die von unterschiedlichen Zulieferern kommen, aber die gleich Spezifikation aufweisen oder an unterschiedlichen Standorten verbaut werden.

Berücksichtigung von Varianz im Systemmodell

Wie im Diagramm angedeutet, verstehen wir Varianz als Teil der Beziehungen zwischen den Modellelementen. Dabei kann diese Beziehung drei Ausprägungen annehmen:

• Variante: eine Entweder-Oder-Beziehung (XOR) zwischen verschiedenen Funktionen oder Systemelementen
• Option: eine Oder-Beziehung (OR) – eine Funktion oder ein Element ist nicht zwingend erforderlich, sondern kann in einer Konfiguration verwendet werden
• Default: Eine Funktion oder ein Element muss zwingend vorkommen

Darüber hinaus kann die Varianz in einem Modell durch Bedingungen eingeschränkt werden. Solche Bedingungen sind:

• Mandatory (oder requires): Eine Funktion oder ein Systemelement benötigt ein anderes zwingend
• Exclude: Wenn eine bestimmte Funktion oder Systemelement gewählt ist, kann ein bestimmtes anderes Element nichtmehr genutzt werden
• Wenn-Dann: Für komplexere Bedingungen können Wenn-Dann-Regeln definiert werden, die nach bspw. mehrere bedingende Funktionen oder Systemelemente beinhalten.

In iQUAVIS setzen wir Varianten-Beziehung als Teil der Hierarchiebeziehung um. Im Bild zu sehen ist das Beispiel einer Wetterstation, die bspw. über zwei verschiedene Bildschirmgrößen verfügen könnte. Mögliche Bedingungen werden mittels Abhängigkeitsbeziehung modelliert, im Beispiel zwischen der kleineren Bildschirmgröße und dem Feature, auch Wind messen zu können. Im rechten Teil des Bilds wird der Feature Baum im „Varianten Filter“ noch einmal visualisiert. Hier gibt es die Möglichkeit, mittels Checkboxen, eine bestimmte Variante oder Option auswählen und somit die Varianz des Systemmodells auszuprägen. Damit kann zum einen das Verhalten des Modells geprüft sowie zum anderen konkrete Konfigurationen erzeugt werden.

Nutzung des Systemmodells

Ein MBSE Modell, das Varianz beinhaltet, kann als Grundlage zur Kommunikation und Kooperation mit anderen Projektbeteiligten genutzt werden.

• Varianz kann bewusst geplant werden, insb. in Abstimmung zwischen Produktmanagement und Entwicklung, die auf Basis einen Modells ihr gemeinsames Verständnis sicherstellen
• Auf Basis der modellierten Varianz können konkrete Konfigurationen definiert werden, sei es, um in der Entwicklung bestimmte Konfigurationen fokussiert zu analysieren, Kundenkonfigurationen zu dokumentieren oder alle denkbaren Konfigurationen auszuleiten
• Die Integration von Varianz in das Systemmodell sichert die Traceability von Anforderungen über Funktionen bis zur Lösung. So kann insb. im Fall von Änderungen der Impact festgestellt werden.

Die Informationen zur Varianz im Systemmodell bilden die Basis für verschiedene aufbauende Aktivitäten. Eine Plausibilitätsprüfung kann sicherstellen, dass die modellierte Variantenlogik frei von Widersprüchen ist. Das Product Line Engineering benötigt die Möglichkeit, Varianz auf Systemebene darzustellen, die sie sowohl für die Beschreibung der Produktlinie als auch der Produktfamilie relevant ist.

In iQUAVIS setzt das Thema Varianz mit dem VariantenManager um. Mehr dazu erfahren Sie auf der Seite zum Variantenmanagement mit iQUAVIS.

Mehr zum methodischen Hintergrund der Methode CONSENS finden Sie in unserem separaten Beitrag zu CONSENS.

Übersicht zur CONSENS Methode

Die CONSENS Methode ist gegliedert in zwei Phasen: Die Analyse- und die Synthese-Phase. In der ersten Phase arbeitet der Anwender mit Anwendungsszenarien, Umfeldelemente und Anforderungen. In der zweiten Phase sind es hauptsächlich Funktionen, Lösungselement und ggf. Verhalten. In iQUAVIS bieten sich Baumansichten an, um die Übersicht über die Phasen und die Traceability zwischen den Modellelemente zu überblicken.

Neben den reinen Daten gibt CONSENS auch Bearbeitungsschritte vor, nämlich die schrittweise Erarbeitung der einzelnen Partialmodelle. iQUAVIS ermöglicht die Umsetzung solcher Vorgaben in der Prozesstabelle. Hier werden Aufgaben (standardisiert) definiert. Zu jeder Aufgabe gehören Sichten, in die der Nutzer direkt springen kann um so die Inhalte zu erarbeiten. Diese Sicht richtet sich daher an alle Nutzer und wird als Absprungebene in die einzelnen Aktivitäten genutzt.

Umsetzung der Partialmodelle

Die Partialmodelle von CONSENS werden in verschiedene Sichten in iQUAVIS umgesetzt. Für die Darstellung von Wirkstruktur und Umfeldmodell werden die Entity-Block-Diagramme verwenden. Für die Funktionshierarchie wird mit einer Baumansicht gearbeitet. Wie in CONSENS beabsichtigt, arbeitet iQUAVIS dabei auch mit starken optischen Unterscheidungselementen: So sind bspw. alle lösungsbehafteten Elemente (in iQUAVIS „Entity“) mit rechtwinkligen Ecken versehen. Lösungsneutrale Modellelemente wie bspw. Funktionen haben abgerundete Ecken. Auch mit Farben für Elemente oder Beziehungen kann gearbeitet werden.

Die Verhaltensmodellierung wird ebenfalls mit den entsprechende Diagrammtypen ermöglicht. In den Bildern zu sehen sind die Sequenz-, Aktivitäts- und Zustandsdiagramme.

Traceability und Nutzung der Methode CONSENS in iQUAVIS

Die in CONSENS angefertigten Partialmodelle stehen nicht für sich alleine, sondern ergeben ein konsistentes Ganzes. Dazu werden die Modellelemente zueinander verknüpft. Beispielsweise ergeben sich Anwendungsszenarien oder Use Cases aus Umfeldelementen; Funktionen werden durch Systemelemente realisiert; Anforderungen werden mit Testfällen abgesichert.

In der unten stehenden Grafik haben wir versucht, das so entstehende Systemmodell zu veranschaulichen. Insbesondere die Querbeziehungen bilden später die Grundlage für aussagekräftige Auswertungen:

• Ein Systemelement ändert sich – welche Funktionen und Anforderungen müssen nun neu geprüft werden?
• Wir können eine Anforderung nicht erfüllen, woher kam die eigentlich und gibt es andere Wege, den Kundenwunsch umzusetzen?
• Wer entwickelt eigentlich welches Systemelement und wann werden z.B. Informationen von anderen Kollegen dafür benötigt

Wir haben dem Aufbau des Systemmodells einen eigenen Beitrag gewidmet: Das Systemmodell mit iQUAVIS

Anpassung des CONSENS Profils

Die CONSENS Methode ist gut geeignet um einen Einstieg in das Thema MBSE zu ermöglichen. Sobald man jedoch als Nutzer die ersten Projekterfahrungen gesammelt hat und Schritt für Schritt tiefer in das Thema einsteigt, stellt man in der Regel fest, dass es weitergehende Anforderungen an die Methode gibt. Beispielsweise werden weitere Anforderungsklassen notwendig, oder neue Sichten werden benötigt für bestimmte (bereits etablierte) Methoden. Diese Situation ist unser Erfahrung nach die Regel, denn letztlich gibt es immer unternehmensspezifische Aspekte, die der Branche, der Art der Projekte oder den Unternehmensstruktur geschuldet sind. Hier bietet iQUAVIS intuitiv zu bedienende Tools für die Erweiterung an. Neue Modellelement-Klassen oder neue Attribute können direkt im Tool erzeugt werden.

iQUAVIS bietet dazu ein separates Administrationstool, mit dem Vorlagen und Profile zentral editiert und an alle Nutzer ausgerollt werden können. So kann auch dauerhaft sichergestellt werden, dass alle Nutzer mit den selben Modellelementen arbeiten und die Modelle so vergleichbar und standardisiert weiterverwendbar werden.

Ihre Fragen?

Haben Sie noch Fragen zur Methode CONSENS und wie iQUAVIS sie umsetzt? Fragen Sie uns gern über die Kommentarfunktion oder melden Sie sich für eine kostenlose Live Demo am Beispiel Ihres Use Cases an! Wir freuen uns auf Ihre Anfrage! Mehr über iQUAVIS erfahren Sie außerdem auf dieser Seite.

MBSE, Two Pillars und iQUAVIS

In diesem Jahr haben wir gleich zwei TÜV-Zertifikate erhalten: Zum einen sind wir als Unternehmen zertifiziert nach ISO 27001 und zum anderen hat unser MBSE-Tool iQUAVIS über unseren Mutterkonzern DENTSU SOKEN die ISO 26262 erhalten. Wir freuen uns sehr darüber und sind stolz darauf. In diesen beiden Blogartikeln haben wir die Zertifizierungen jeweils thematisiert: Two Pillars ist ISO 27001 zertifiziert und iQUAVIS ist TÜV-zertifiziert mit ISO 26262.

Webinare: MBSE lernen

Über das Jahr verteilt haben wir verschiedene Webinare angeboten – auch zu Themen, die über den Einstieg ins MBSE (mit iQUAVIS) hinausgingen. Wir wollen das Thema Systems Engineering fördern und vertiefen und natürlich Ihnen näher bringen. Insgesamt waren die Themen sehr gefragt – das haben wir auch auf dem TdSE wieder gesehen, als unser Tool Vendor Project sehr gut angenommen wurde und gut besucht war.

Unsere Webinare und Tutorials finden Sie auch auf unserem YouTube-Kanal. Einige Webinare sind nicht öffentlich, aber Sie erhalten den Link, wenn Sie sich registrieren, zum Beispiel für das Webinar Entwicklungsbegleitendes Qualitätsmanagement mit iQUAVIS.

Das Webinar Alles über Systems Engineering können Sie direkt anschauen. Unser Geschäftsführer Dr. Christian Tschirner lädt Sie darin zu einer Einführung in das Thema Systems Engineering ein. Es richtet sich an Neulinge in der Thematik und an alle, die ihr Wissen auffrischen wollen.

Unsere kommenden Webinare und Veranstaltungen sehen Sie hier – beachten Sie auch das Get Together Ende Januar!

MBSE lernen

Systems Engineering und MBSE sind komplexe und abstrakte Felder. Die Arbeit eines Systems Engineers findet zum großen Teil in einem theoretischen Denkraum statt, was für viele Einsteiger zunächst eine Hürde darstellt. Daher sind wir von Two Pillars immer bemüht, nicht nur den praktischen Nutzen, sondern auch die praktische Anwendung von Systems Engineering im Allgemeinen und iQUAVIS im Besonderen aufzuzeigen – durch Webinare, aber auch durch fachliche Artikel.

In diesem Rahmen haben wir auf unserem Blog einige neue Beiträge veröffentlicht:

Anwendung und Integration des Application Lifecycle Managements im Produktlebenszyklus – Studie

11 Freunde – Rollen im Systems Engineering

Produktentwicklung mit iQUAVIS: Die 3 Säulen des Systemmodells

Fallbeispiel: MBSE Einführung bei der Palfinger AG

Zusätzlich freuen wir uns, wenn unsere Kunden uns bestätigen: So hat Dr. Christian Zingel von der Palfinger AG in der Zeitschrift konstruktionspraxis ein Interview gegeben, in dem er auch über Systems Engineering und iQUAVIS spricht. Um den Artikel zu lesen, reicht ein kostenloser Account: „Systems Engineering ist das Werkzeug, um mit Komplexität umzugehen“. Unter anderem sagt er in diesem Interview:

„Das Tool iQUAVIS bietet im Gegensatz zu den bekannten SysML-Editoren wesentlich mehr Möglichkeiten, das Modell darzustellen, wie beispielsweise Baumstrukturen von Datenartefakten, die man verknüpfen kann.“

Dr. Christian Zingel im Interview mit der konstruktionspraxis

Schnittstellen in iQUAVIS

Unsere Entwicklung hier in Paderborn hat in diesem und dem vergangenen Jahr ganze Arbeit geleistet: Damit iQUAVIS sich optimal in die Toolkette unserer Kunden einfügt, haben wir hier Schnittstellen entwickelt, die unseren Kunden die Arbeit deutlich erleichtern und Prozesse vereinfachen und beschleunigen.

Inzwischen sind für Jira, Codebeamer und Polarion Schnittstellen entstanden, die wir unseren Kunden als optionales Add-On anbieten. Mehr über die Schnittstellen erfahren Sie hier.

Neues Tool: i-SPiDM

In diesem Jahr haben wir unsere Produktpalette um das SPDM-Tool i-SPiDM erweitert. Auch i-SPiDM stammt aus dem Hause DENTSU SOKEN aus Japan. Es ist ein leichtgewichtiges Tool, mit dem Sie Ihr Simulationsdatenmanagement auf das nächste Level heben. Wir stellen i-SPiDM auf dieser Seite genauer vor.

Partnerschaften

Wir, bzw. unser Mutterkonzern DENTSU SOKEN ist eine Partnerschaft mit AVL eingegangen. iQUAVIS ist seitdem auch in der AVL Experience Cloud vertreten. Wir sagen danke!

Reisen und persönliche Begegnungen

Neben all den Errungenschaften und der Arbeit als solcher sind es doch die persönlichen Begegnungen, die einem im Gedächtnis bleiben. Wir haben in diesem Jahr wieder einiges erlebt, waren unterwegs oder haben Gäste hier in Paderborn bei uns an der Zukunftsmeile empfangen.

Das Jahr begann mit einem Get Together Ende Januar 2025. Im Mai besuchte unser MBSE-Experte Matthias Greinert, der auch viele unserer Webinare hält und als Consultant für unsere Kunden da ist, die MESCONF in München und auf dem MBSE Summit in Österreich. Unser Geschäftsführer Dr. Christian Tschirner besuchte die prostep ivip in Berlin und im November das AVL Symposium in Wiesbaden, wo er auch einen Vortrag gehalten hat.

Im Juni fand dann das systems.camp der GfSE hier in Paderborn statt und Christian Tschirner ist nach Japan geflogen.

Anfang Juli ging es weiter mit unserem Key User Meeting bei unserem Kunden BAUER. Darüber haben wir in diesem Blogbeitrag berichtet: Persönliche Begegnung statt KI-Chatbot: Key User Meeting in Schrobenhausen – Two Pillars.

Das Highlight zum Ende des Jahres war der TdSE in Salzburg, der aus unserer Sicht zu einem der gelungensten der letzten Jahre gehört. Unter dem Motto „Zukunft mit System“ haben wir den Austausch wieder sehr genossen. Unser Kunde PALFINGER hatte den Stand neben uns, was

Im kommenden Jahr wird der TdSE in Dortmund stattfinden – für uns natürlich ein Heimspiel, auf das wir uns schon sehr freuen!

Eine Auswahl von Bildern sehen Sie hier in der Galerie:

Ausblick 2026

Im kommenden Jahr werden wir unseren Weg weiterhin konsequent verfolgen – wir planen natürlich hinter den Kulissen schon einiges. Bleiben Sie dran, indem Sie uns auf LinkedIn folgen!

Im Januar und Februar werden wir wieder einige Webinare veranstalten – die Termine und Anmeldelinks folgen in Kürze!

• 15.1. – MBSE mit iQUAVIS
• 23.1. – Alles über MBSE
• 29.1. – i-SPiDM
• Entwicklungsbegleitendes Qualitätsmanagement mit iQUAVIS
• Projektmanagement mit iQUAVIS
• RFLP – Idee, Konzepte, Lösungen, Nutzen

Außerdem findet am 29.1.2026 wieder ein Get Together statt. Mehr Informationen dazu finden Sie hier.

Sie finden unsere Veranstaltungen und Webinare alle auf dieser Seite.

Nun wünschen wir Ihnen zum Abschluss schöne Feiertage und eine gute Landung im Jahr 2026.

Die ISO 26262 

Die ISO 26262 definiert ein Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten („work products“) sowie anzuwendenden Methoden in Entwicklung und Produktion. Dabei deckt sie unter anderem auch die Konzeptphase oder Produktentwicklung auf Systemlevel ab. 

Damit betrifft die Norm auch Aktivitäten, die in iQUAVIS durchgeführt werden. iQUAVIS ist mit den bekannten Sichten und Modellierungsmöglichkeiten bestens geeignet, die geforderten Methoden umzusetzen – das hat nun auch der TÜV Rheinland bestätigt. Mit der Zertifizierung erhalten Nutzer die Sicherheit, dass iQUAVIS die Methoden verlässlich umsetzt und iQUAVIS somit auch für sicherheitsrelevante Risikoanalysen wie der HARA geeignet ist.  

iQUAVIS: Die Zertifizierung 

Die iQUAVIS Version 9, wurde durch den TÜV Rheinland für ISO 26262 für die Kapitel 3 -6, 8, 11 und 12 zertifiziert. Für die Umsetzung stellen wir in iQUAVIS geeignete Vorlagen zur Verfügung – sprechen Sie uns gern darauf an! 

Den Wortlaut des Zertifikats haben wir hier übersetzt: 

iQUAVIS ist ein Softwaretool, das die Anforderungen des Tool Confidence Level (TCL) 1 für ASIL D gemäß ISO 26262-8 erfüllt. iQUAVIS unterstützt während des gesamten Entwicklungsprozesses eine Vielzahl von Aufgaben, darunter Systemdesign, Projektmanagement, Risikomanagement und Änderungsmanagement. Dazu gehören Aktivitäten wie Konzeptdesign, Systemdesign, Hardwareentwicklung und Softwareentwicklung für Automobilprodukte und -komponenten. iQUAVIS erleichtert die Erstellung der in ISO 26262 Teile 3 – 6, 8, 11 und 12 geforderten Arbeitsprodukte. 

Das Zertifikat mit dem Originaltext auf Englisch steht hier zur Einsicht bereit.

Arbeiten mit iQUAVIS und der ISO 26262 

Wir wollen Ihnen die Arbeit möglichst erleichtern und stellen für Ihren Prüfprozess geeignete Vorlagen zur Verfügung.  

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Two Pillars auf dem TdSE

Der TdSE findet in diesem Jahr vom 29. bis 31. Oktober im Kongresszentrum in Salzburg statt. Sie finden uns an Stand 13, direkt neben unserem Kunden, der PALFINGER AG, an Stand 15.

Von Two Pillars werden unsere beiden Geschäftsführer, Dr. Christian Tschirner (LinkedIn) und Dr. Christian Bremer (LinkedIn) und unser MBSE-Experte und Consultant Matthias Greinert (LinkedIn) vor Ort sein. An unserem Stand kommen wir gern mit Ihnen ins Gespräch und stellen Ihnen unsere Lean Engineering Tools iQUAVIS und – NEU! – i-SPiDM vor.

iQUAVIS ist unser SysML-freies MBSE-Tool, das wir für DENTSU SOKEN Inc. in der DACH-Region vertreiben. Neu in unserem Programm ist seit diesem Jahr das SPDM-Tool i-SPiDM. Unser Consultant Matthias Greinert hat es im Frühjahr in diesem Webinar vorgestellt. Mehr dazu erfahren Sie demnächst hier auf dem Blog.

Workshops und Vorträge

Auf einige Programmpunkte freuen wir uns schon sehr: Wir veranstalten ein „Tool Vendor Project“ (TVP), Dr. Christian Bremer wird gemeinsam mit Palfinger einen Vortrag halten, UND Christian Tschirner gibt gemeinsam mit Luca Weik von der Palfinger AG ein Live-Webinar vom TdSE! Hier der Überblick:

Klassentreffen?

Neben dem fachlichen Austausch und dem Kennenlernen neuer Gesichter ist der TdSE immer eine schöne Gelegenheit, bekannte Gesichter wiederzusehen. Der TdSE fühlt sich immer ein bisschen wie ein Klassentreffen an, und wir freuen uns, dass wir auch einige unserer iQUAVIS-User persönlich treffen werden. Unser letztes Key User Meeting ist ja noch nicht lange her, aber wir ergreifen gern die Chance, um uns auszutauschen und auch den Anwender:innen die Möglichkeit zu geben, sich untereinander zu vernetzen.

Der Tag des Systems Engineering (TdSE) wird von der Gesellschaft für Systems Engineering (GfSE) jährlich an einem anderen Ort veranstaltet. Die offizielle Website des TdSE ist https://tdse.org.

Voneinander und miteinander lernen

Die iQUAVIS-Community ist schon großartig: Die Kunden kommen aus verschiedenen Branchen und entwickeln unterschiedliche Produkte, doch in der Anwendung von iQUAVIS sind sie geeint. Der persönliche Austausch wird jedes Mal als wertvoll betrachtet. Man hilft sich gegenseitig, gibt sich Tipps und tatsächlich sind schon über die Begegnung Freundschaften entstanden.

Die Atmosphäre ist meist sehr entspannt und bringt so manchem Teilnehmenden ein Aha-Erlebnis. Uns gibt das Key User Meeting die Chance, auf Fragen und Probleme zu reagieren. Wir nutzen auch die Gelegenheit, ein Update zu iQUAVIS und unseren neuen Produkten wie i-SPiDM zu geben.

Key User Meeting bei BAUER Offshore Technologies

Das diesjährige Key User Meeting wurde von unserem Kunden BAUER Offshore Technologies organisiert. Unter der Leitung von Philip Porten, den wir hier vor einiger Zeit interviewt haben, bekamen die Teilnehmenden zunächst eine Werksbesichtigung. Anschließend gab es eine Kennenlernrunde, bei der die Teilnehmer Einblicke in ihren derzeitigen Stand und die aktuellen Herausforderungen gewährten. Außerdem wurden die kommenden iQUAVIS-Updates präsentiert.

Die für den Nachmittag geplanten parallelen Workshops zu den Themen „Variantenmanagement in iQUAVIS“ und „Req-Tools und iQUAVIS“ sind zu Gunsten des Austausches etwas knapper ausgefallen. Das Thema Variantenmanagement mit iQUAVIS bieten wir regelmäßig als Webinar an. Hier gelangen Sie zu einer Aufzeichnung, und hier sehen Sie unsere kommenden Veranstaltungen und Webinare.

Nach dem fachlichen Austausch fand das Key User Meeting bei einem gemeinsamen Abendessen einen würdigen Ausklang.

Two Pillars und das Key User Meeting

Wir kennen viele unserer Kunden seit vielen Jahren. Da wir nicht nur Tool-Vendor, sondern auch Berater und Partner sind, sind wir mit vielen Kunden bereits einen langen, gemeinsamen Weg gegangen.

Regelmäßige und persönliche Treffen für den gemeinsamen Austausch anzubieten, gehört für uns mit dazu. Wir leben Systems Engineering und Systems Engineering ist auch die Kunst der Interdisziplinarität: Gemeinsamkeiten finden, eine gemeinsame Sprache sprechen. In einer Zeit, in der andere auf Kundenbetreuung durch KI-Chatbots setzen, sind wir selbstverständlich für Sie da. Persönlich.

Unser besonderer Dank gilt abschließend Philip Porten und BAUER Offshore Technologies, das sie dieses Treffen möglich gemacht haben – herzlichen Dank und herzlichen Dank an alle Teilnehmer:innen.

Die Bilder dieses Beitrags stammen von Matthias Greinert.