Interaktive Klassenprüfung

Sieben Klassen. Sieben unterschiedliche Ausgangspunkte.

Wählen Sie eine Systemklasse. Die Herkunftssignatur zeigt, welches Objekt führt, wie Wissen modelliert und gepflegt wird und welches Ergebnis das System erzeugt.

01 · SalesVertriebszentrierte CPQ-Suiten 02 · ProduktlogikIndustrielle CPQ-Konfiguration 03 · OperationsERP-nahe Variantenkonfiguration 04 · LifecycleConfiguration Lifecycle Management 05 · ProduktdefinitionPLM-nahe Variantenführung 06 · EngineeringDesign- und Engineering-Automation 07 · PlanungVisuelle und raumbezogene Konfiguration

Klasse 01

Vertriebszentrierte CPQ-Suiten

Kernobjekt

Angebot, Deal und Preisbestandteile

Wissensmodell

Produkte, Optionen, Preise, Konditionen und kommerzielle Regeln

Modellpflege

Vertrieb, Sales Operations und kommerzielle Administration

Ergebnis

Angebot, Deal, Preisbestandteile und freigegebenes Dokument

Leseregel: Die Klasse beschreibt den fachlichen Ursprung eines Systems. Zusätzliche Funktionen erweitern ihn, ersetzen aber nicht automatisch Kernobjekt, Modellierungslogik und Pflegeverantwortung.

Die Frage nach dem Anbieter kommt zu früh

Wer ein Konfigurationsvorhaben beginnt, sucht früh nach einer Liste. Welche Anbieter gibt es, welcher ist der beste, wer arbeitet im Maschinenbau, wer beherrscht komplexe Regelwerke. Diese Frage ist verständlich, denn sie verspricht schnelle Orientierung in einem unübersichtlichen Feld. Sie führt jedoch regelmäßig in die Irre, weil sie eine Vergleichbarkeit unterstellt, die es nicht gibt. Der Markt für Konfigurationssoftware besteht nicht aus vielen ähnlichen Produkten mit unterschiedlichem Funktionsumfang, sondern aus mehreren grundverschiedenen Systemarten, die aus verschiedenen Aufgabenstellungen entstanden sind und bis heute davon geprägt werden.

Dieser Beitrag liefert deshalb keine Rangliste. Er ordnet den Markt nach Systemklassen und macht die Frage beantwortbar, welche Klasse zu welcher Aufgabe passt. Wer diese Zuordnung getroffen hat, kann anschließend innerhalb einer Klasse sinnvoll vergleichen und findet dafür ausreichend Material. Wer sie überspringt, vergleicht Systeme, die für verschiedene Zwecke gebaut wurden, und trifft eine Entscheidung, die sich später nicht mehr korrigieren lässt.

Der Beitrag schließt damit eine Reihe ab, die bei einer ersten Marktkarte beginnt und über Auswahlvorgehen, Voraussetzungen, Dialoggestaltung und Durchgängigkeit bis zur vertieften Eignungsprüfung führt. Diese Herkunftsanalyse ist besonders nützlich, wenn die eigenen Anforderungen bereits beschrieben sind.

Warum Marktübersichten so wenig helfen

Wer sich einen Überblick über den Markt für Konfigurationssoftware verschaffen will, findet zunächst reichlich Material: Anbieterverzeichnisse, Vergleichsportale, Bewertungsplattformen, Marktkompendien und Analystenberichte. Diese Quellen sind für eine erste Orientierung nützlich, beantworten aber selten die entscheidende Frage: Für welche Produkt-, Prozess- und Architekturaufgabe ist ein System tatsächlich geeignet? Viele Übersichten beruhen auf Selbstauskunft, kommerziellen Platzierungsmodellen oder einer begrenzten Zahl von Bewertungen. Entsprechend unterscheiden sich nicht nur die Rangfolgen, sondern häufig bereits die berücksichtigten Anbieter.

Der strukturelle Grund liegt im Erhebungsverfahren. Werden Anbieter gebeten, ihre Fähigkeiten selbst zu beschreiben, werden auch Funktionen genannt, die über Erweiterungen, Partnerlösungen oder projektspezifische Anpassungen verfügbar sind. Auf dem Papier unterstützen damit viele Systeme nahezu dieselben Aufgaben – von der einfachen Auswahl bis zur auftragsbezogenen Konstruktion. Für eine Vorauswahl reicht diese Information nicht aus. Entscheidend ist nicht, ob eine Funktion grundsätzlich vorhanden ist, sondern ob sie zum Kern des Datenmodells gehört, im Standard betrieben werden kann und im Regelbetrieb von den vorgesehenen Fachrollen pflegbar bleibt.

Hinzu kommt, dass Konfigurationssoftware in der etablierten Analystenlandschaft häufig nur als Teil benachbarter Kategorien betrachtet wird, etwa Vertriebstechnologie, digitaler Handel oder Produktlebenszyklusmanagement. Für den Maschinen- und Anlagenbau bleiben dadurch zentrale Unterschiede in Produktlogik, Strukturauflösung und Engineering-Anbindung unscharf. Die praktische Konsequenz lautet nicht, Marktübersichten zu verwerfen. Sie müssen jedoch als Inventar verstanden werden, nicht als Eignungsnachweis. Sichtbarkeit im Markt und fachliche Passung sind zwei verschiedene Größen.

Systemklassen statt Anbieterlisten

Es gibt eine tragfähigere Ordnung. Anbieter unterscheiden sich weniger im Funktionsumfang, den sie behaupten, als in ihrer Herkunft. Jedes Konfigurationssystem ist ursprünglich gebaut worden, um eine bestimmte Aufgabe zu lösen, und diese Herkunft prägt sein Datenmodell, seinen Modellierungsansatz und seine Integrationsphilosophie dauerhaft. Funktionen lassen sich ergänzen, ein Datenmodell nicht ohne Weiteres austauschen. Was ein System im Kern beherrscht, bleibt deshalb über Produktgenerationen hinweg erkennbar.

Aus dieser Beobachtung ergibt sich eine Einteilung in sieben Systemklassen: vertriebszentrierte CPQ-Suiten, industrielle CPQ- und Produktkonfiguration, ERP-nahe Variantenkonfiguration, Configuration Lifecycle Management, PLM-nahe Variantenführung, Design- und Engineering-Automation sowie visuelle und raumbezogene Konfiguration. CLM und PLM bleiben als angrenzende Systemwelten kenntlich; sie werden dennoch als Klassen 04 und 05 geführt, weil sie dieselbe End-to-End-Architektur und Lifecycle-Durchgängigkeit prägen. Jede Klasse hat ein anderes Kernobjekt, einen anderen typischen Modellierungsansatz und damit andere Stärken und Grenzen.

Diese Einteilung ersetzt keine Auswahl. Sie leistet etwas anderes: Sie verhindert, dass Systeme miteinander verglichen werden, die für grundlegend verschiedene Aufgaben gebaut wurden. Ein Vergleich innerhalb einer Klasse ist aussagekräftig. Ein Vergleich über Klassengrenzen hinweg führt zu Bewertungsmatrizen, in denen jedes System bei den Kriterien der jeweils anderen Klasse schlecht abschneidet und am Ende alle eine ähnliche Gesamtpunktzahl erreichen.

Die sieben Systemklassen im Detail

Die interaktive Übersicht oben schafft den gemeinsamen Vergleichsmaßstab. Die folgenden Abschnitte vertiefen Herkunft, typische Eignung und fachliche Grenze jeder Klasse. Damit bleibt die Einordnung kompakt, ohne die Unterschiede in einer breiten Funktionsmatrix zu nivellieren.

Vertriebszentrierte CPQ-Suiten

Diese Klasse stammt aus der Vertriebsautomatisierung und ist meist eng an ein CRM gekoppelt oder daraus hervorgegangen. Ihr Kernobjekt ist das Angebot. Entsprechend liegen die Stärken in Preisfindung, Rabatt- und Genehmigungslogik, Angebotsdokumenten, Vertragsverlängerungen, Abonnementmodellen und der Steuerung des Vertriebsprozesses über mehrere Kanäle. Die Modellierung erfolgt überwiegend über Produktkataloge, Optionsgruppen und Regeln, die Ausschlüsse und Abhängigkeiten zwischen wählbaren Positionen abbilden.

Die Grenze dieser Klasse liegt in der technischen Tiefe. Mehrstufige Produktstrukturen, parametrische Auslegung, Stücklistengenerierung über mehrere Ebenen und die Übergabe fertigungsrelevanter Daten sind selten die ursprüngliche Aufgabe gewesen. Wo sie unterstützt werden, geschieht das häufig über Erweiterungen oder Partnerlösungen. Für Unternehmen mit überwiegend auswählbaren und kombinierbaren Produkten ist die Klasse gut geeignet, insbesondere wenn Preisgestaltung, Vertriebssteuerung und die Anbindung eines internationalen Händlernetzes im Vordergrund stehen.

Die typische Fehlanwendung besteht darin, ein solches System für ein technisch anspruchsvolles Portfolio zu wählen, weil es im Konzern bereits vorhanden ist oder weil die Angebotsoberfläche überzeugt. Die technische Konfiguration wird dann in Erweiterungen nachgebaut, und der Aufwand dafür übersteigt regelmäßig die Ersparnis aus der vorhandenen Lizenz. Die Entscheidung wirkt zudem über die Laufzeit fort, weil jede Portfolioänderung denselben Sonderweg erneut durchlaufen muss.

Industrielle CPQ- und Produktkonfiguration

Diese Klasse ist im Investitionsgütergeschäft entstanden und darauf ausgelegt, technisch komplexe Erzeugnisse regelbasiert zu bestimmen. Ihr Kernobjekt ist das Produktmodell, nicht das Angebot. Charakteristisch sind ein leistungsfähiges Beziehungswissen, die Fähigkeit zu mehrstufigen Strukturen, die Generierung von Stücklisten und Arbeitsplänen sowie eine ausgeprägte Integration in ERP- und PLM-Landschaften. Angebotsdokumente, Kalkulation und technische Datenblätter werden aus demselben Modell erzeugt, was Konsistenz zwischen kaufmännischer und technischer Aussage sichert.

Innerhalb dieser Klasse ist die Art der Wissensmodellierung das wichtigste Unterscheidungsmerkmal, und sie wird in Auswahlverfahren selten geprüft. Regelbasierte Systeme werten gerichtet aus und eignen sich für prozedural beschreibbare Abhängigkeiten. Constraint-basierte Systeme werten ungerichtet aus, beherrschen den Lösungsraum als Ganzes und können Konflikte in der Regel benennen, was für die Begründung unzulässiger Kombinationen erheblich ist. Entscheidungstabellen bündeln strukturgleiche Regeln und sind für Fachabteilungen gut pflegbar, stoßen aber bei stark vernetzten Abhängigkeiten an Grenzen. Viele Systeme kombinieren mehrere Ansätze, doch der jeweils dominierende prägt Modellierungsaufwand, Pflegbarkeit und Erklärfähigkeit dauerhaft.

Die Grenze dieser Klasse liegt üblicherweise dort, wo vertriebliche Zusatzfunktionen erwartet werden, die aus dem CRM-Umfeld vertraut sind: Kampagnensteuerung, Opportunity-Management, mehrstufige Genehmigungsprozesse über Organisationseinheiten hinweg. Diese lassen sich anbinden, sind aber nicht der Ursprung. Für variantenreiche Maschinen und Anlagen ist diese Klasse in aller Regel der fachlich passende Ausgangspunkt, und die relevante Frage lautet dann nicht mehr, ob ein technischer Konfigurator geeignet ist, sondern welcher Modellierungsansatz zur Struktur des eigenen Beziehungswissens passt.

ERP-nahe Variantenkonfiguration

Nahezu jedes größere ERP-System bringt eine eigene Variantenkonfiguration mit. Ihr Vorteil liegt auf der Hand: Die Konfiguration findet dort statt, wo Materialstämme, Stücklisten, Arbeitspläne, Preise und Aufträge ohnehin geführt werden. Die Übergabe entfällt, weil es keine Übergabe gibt. Für Unternehmen mit stark ERP-zentrierter Landschaft und überwiegend interner Nutzung ist das ein gewichtiges Argument, insbesondere wenn die Fertigungsstruktur der eigentliche Engpass ist und nicht die Angebotserstellung.

Die Grenzen zeigen sich an zwei Stellen. Zum einen sind Oberflächen und Dialogführung dieser Lösungen traditionell auf geschulte interne Anwender ausgelegt und eignen sich selten unmittelbar für Händler oder Endkunden. Zum anderen ist die Modellierung häufig anspruchsvoll und liegt faktisch in der Verantwortung der IT, was der Anforderung entgegensteht, das Produktwissen in der Fachabteilung zu pflegen. Als Reaktion darauf ist ein eigenes Marktsegment entstanden: Werkzeuge, die auf der ERP-Variantenkonfiguration aufsetzen und ihr eine bedienbare Modellierungs- und Vertriebsoberfläche voranstellen.

Diese Konstellation verdient besondere Aufmerksamkeit, weil sie architektonisch attraktiv wirkt und zugleich das Risiko der Doppelmodellierung erhöht. Wo ein vorgelagertes System eigene Merkmale und Regeln führt und das ERP dieselben Sachverhalte ein zweites Mal beschreibt, entsteht genau die Konstellation, die als Hauptursache für Brüche zwischen Vertrieb und Produktion gilt. Die Frage, welches der beiden Systeme das führende Produktmodell hält, muss vor der Einführung beantwortet sein und nicht während der Modellierung.

Configuration Lifecycle Management

Configuration Lifecycle Management hält Variantenräume, Regeln, Gültigkeiten und Baselines über Entwicklung, Vertrieb, Fertigung und Service konsistent. Das Kernobjekt ist nicht das Angebot oder die einzelne Stückliste, sondern die Beziehung zwischen mehreren fachlichen Modellen über ihren Lifecycle. Diese Klasse wird als angrenzende Systemwelt geführt, weil sie CPQ, PLM und ERP nicht ersetzt, deren Zusammenspiel aber wesentlich prägt.

Die kritische Frage lautet, ob CLM bestehende Modelle kontrolliert verbindet oder ungewollt ein weiteres Produktmodell erzeugt. Ohne klare Datenhoheit, definierte Übergaben und ein gemeinsames Gültigkeitsverständnis verschiebt sich die Inkonsistenz lediglich in eine zusätzliche Schicht.

PLM-nahe Variantenführung

PLM-nahe Variantenführung ordnet Optionen, technische Sichten, eBOM, Dokumentstände, Gültigkeiten und Engineering-Änderungen nahe an der Produktdefinition. Ihre Stärke liegt in technischer Datenhoheit und Lifecycle-Nachweis. Verkaufssicht, Pricing, Guided Selling und Quote-Prozess bleiben dagegen eigenständige Aufgaben, die über CPQ oder CRM angebunden werden müssen.

Entscheidend ist die Trennung zwischen technischer Wahrheit und abgeleiteter Verkaufssicht. Wird dieselbe Logik in PLM und CPQ unabhängig modelliert, entsteht Doppelpflege. Wird das PLM dagegen zum alleinigen Vertriebswerkzeug erklärt, fehlen häufig Nutzerführung, kaufmännischer Prozess und schnelle Modellpflege durch marktnahe Rollen.

Design- und Engineering-Automation

Systeme dieser Klasse stammen aus der Konstruktion und sind eng mit CAD-Umgebungen verbunden. Ihr Kernobjekt ist die Geometrie. Sie erzeugen aus einer Parametrierung automatisch dreidimensionale Modelle, Zeichnungen, Blechabwicklungen, Fertigungsdaten und die zugehörigen Stücklisten. Wo Produkte tatsächlich konstruiert und nicht nur kombiniert werden, verkürzen sie die Durchlaufzeit erheblich und entlasten eine Konstruktionsabteilung, die andernfalls mit wiederkehrender Variantenarbeit ausgelastet ist.

Die Voraussetzungen sind allerdings anspruchsvoll. Die CAD-Modelle müssen durchgängig parametrisch aufgebaut, die Konstruktionsregeln dokumentiert und die zulässigen Änderungsräume definiert sein. Wo diese Grundlagen fehlen, wird die Automatisierung zu einem eigenständigen Entwicklungsprojekt mit erheblichem Pflegebedarf. Zudem decken diese Systeme den kaufmännischen Teil des Angebotsprozesses meist nicht ab und werden deshalb häufig hinter einem vorgelagerten Vertriebskonfigurator betrieben.

Für Unternehmen mit hohem konstruktivem Anteil, insbesondere im CTO+- und ETO-Bereich, ist diese Klasse oft der wirksamste Hebel. Sie ersetzt jedoch keinen Vertriebskonfigurator, sondern ergänzt ihn. Die Frage lautet in der Praxis selten, ob das eine oder das andere gewählt wird, sondern wie die Schnittstelle zwischen beiden verläuft und welches System welchen Teil des Produktwissens führt.

Visuelle und raumbezogene Konfiguration

Die siebte Klasse stammt aus digitalem Handel, Planung und visueller Interaktion. Ihr Kernobjekt ist eine 2D- oder 3D-Szene beziehungsweise das Nutzererlebnis. Diese Systeme erzeugen fotorealistische oder dreidimensionale Darstellungen in Echtzeit, unterstützen räumliche Planung, lassen sich in Webshops einbinden und sind auf intuitive Nutzung ausgelegt. Für erklärungsbedürftige Produkte mit hohem visuellem Anteil und für Endkunden- oder Händlerkanäle sind sie ausgesprochen wirksam.

Ihr Regelwerk ist typischerweise auf gültige Kombinationen, Geometrie und Platzierung ausgelegt, nicht auf technische Auslegung oder mehrstufige Fertigungsstrukturen. Preisberechnung erfolgt meist positionsbezogen, eine belastbare Kostenaussage ist selten vorgesehen. Für die interne Auftragsabwicklung reichen die erzeugten Daten häufig nicht aus, weshalb diese Systeme meist als Kanal vor einer industriellen Produktkonfiguration eingesetzt werden.

Problematisch wird es, wenn die visuelle Überzeugungskraft die Auswahlentscheidung dominiert. Eine beeindruckende Demonstration sagt nichts darüber aus, ob das System eine 150-%-Struktur über fünf Stufen auflösen und einen variantenabhängigen Arbeitsplan erzeugen kann. Die Prüfung dieser Fähigkeiten gehört in einen Proof of Concept mit realen Daten, nicht in eine Präsentation.

Mischformen, Zukäufe und Plattformstrategien

Die Klassengrenzen sind in Bewegung. Anbieter erweitern ihr Portfolio, Softwarehäuser werden übernommen und in Plattformen integriert, und in Produktbeschreibungen verschwimmen die Herkunftsprofile. Ein technischer Konfigurator erhält eine Visualisierungskomponente, eine Vertriebsplattform kauft einen Regelmotor hinzu, ein Konstruktionsautomatisierer ergänzt eine Angebotsstrecke. Parallel verschiebt sich der Markt von lokal betriebener Software zu Plattformangeboten mit festen Releasezyklen, und Assistenzfunktionen auf Basis lernender Verfahren ergänzen zunehmend die Bedienung.

Für die Beurteilung ist entscheidend, ob eine Erweiterung auf demselben Datenmodell arbeitet oder ein zugekauftes System mit eigenem Modell daneben betrieben wird. Im ersten Fall wächst die Fähigkeit, im zweiten wächst die Zahl der zu pflegenden Modelle. Von außen ist das an Produktbroschüren nicht erkennbar. Erkennbar wird es an einer einfachen Prüffrage: Wo wird ein neues Merkmal angelegt, und an wie vielen Stellen muss es gepflegt werden, bis es in allen Modulen wirksam ist. Dieselbe Frage entlarvt auch, ob eine Assistenzfunktion auf dem Produktmodell aufsetzt oder ein zweites, unabhängiges Wissensmodell erzeugt.

Ebenso relevant ist die Frage der Eingriffstiefe. Plattformlösungen entwickeln sich in festen Zyklen weiter, was für die langfristige Betriebsfähigkeit vorteilhaft ist, zugleich aber die zulässige Anpassung begrenzt. Wer sein Produktmodell nur mit tiefgreifenden Sonderentwicklungen abbilden kann, erkauft Passgenauigkeit mit dem Verlust der Aktualisierbarkeit. Diese Abwägung sollte vor der Klassenwahl beantwortet sein, weil sie sich später nur mit erheblichem Aufwand revidieren lässt.

Welche Klasse zu welcher Aufgabe passt

Die Zuordnung von Systemklassen zu Produkt-Prozess-Klassen ergibt ein klareres Bild als jede Funktionsmatrix. Wo Produkte im Wesentlichen ausgewählt und kombiniert werden und der Schwerpunkt auf Preisgestaltung, Vertriebssteuerung und Kanalabdeckung liegt, sind vertriebsorientierte Plattformen und visualisierungsgetriebene Konfiguratoren die naheliegende Wahl. Der technische Anteil ist beherrschbar, der kaufmännische überwiegt.

Wo Abhängigkeiten zwischen Komponenten die eigentliche Schwierigkeit darstellen und aus der Konfiguration mehrstufige Stücklisten, Arbeitspläne und technische Dokumente entstehen müssen, führt der Weg zur industriellen CPQ- und Produktkonfiguration oder zur ERP-nahen Variantenkonfiguration. Die Entscheidung zwischen diesen beiden hängt weniger vom Funktionsumfang ab als von der Frage, wo das Produktwissen künftig gepflegt werden soll und welche Nutzergruppen außerhalb des Unternehmens Zugriff benötigen.

Wo Produkte tatsächlich auftragsspezifisch konstruiert werden, ist keine einzelne Klasse ausreichend. Der CTO+-Anteil verlangt eine Kombination: industrielle CPQ- und Produktkonfiguration für den vordefinierten Lösungsraum und Design- und Engineering-Automation für den auszulegenden Teil, verbunden durch eine klare Grenze zwischen beiden. Bei überwiegendem ETO-Anteil verschiebt sich der Schwerpunkt endgültig. Nicht die Konfiguration ist dann das Kernproblem, sondern die verlustfreie Übergabe der Spezifikation an das Engineering und die Rückführung der tatsächlich konstruierten Struktur.

Klassenprüfung

Vier Fragen zeigen die Herkunft eines Systems

01Kernobjekt

Welches Objekt steht im Zentrum: Angebot, Produktmodell, Material, Geometrie oder Nutzererlebnis?

02Wissensmodell

Wie werden Regeln, Constraints, Tabellen, Formeln und Strukturbedingungen ausgedrückt?

03Modellpflege

Welche Fachrolle kann das Modell pflegen, testen, freigeben und im Regelbetrieb weiterentwickeln?

04Ergebnis

Was verlässt das System: Merkmale, Positionen, Stücklisten, CAD-Daten oder lediglich ein Dokument?

Prüfregel: Diese vier Antworten sagen meist mehr über die tatsächliche Eignung aus als eine lange Funktionsliste.

Die Klasse entscheidet mehr als der Anbieter

Aus dieser Betrachtung folgt eine praktische Reihenfolge. Zuerst wird bestimmt, welche Produkt-Prozess-Klassen das eigene Portfolio tatsächlich enthält und in welchem Verhältnis sie zueinander stehen. Daraus ergibt sich, welche Systemklasse oder welche Kombination von Klassen überhaupt in Frage kommt. Erst innerhalb dieser Auswahl ist ein Anbietervergleich sinnvoll, und erst dort liefern Funktionslisten, Referenzen und Demonstrationen brauchbare Unterschiede.

Wird diese Reihenfolge übersprungen, entsteht der in der Praxis häufigste Verlauf: Eine Longlist versammelt Systeme aus drei verschiedenen Klassen, die Bewertungsmatrix mittelt deren unvergleichbare Stärken zu ähnlichen Gesamtpunktzahlen, und die Entscheidung fällt schließlich nach Preis, Sympathie oder vorhandener Konzernlizenz. Das Ergebnis ist kein schlechtes System, sondern ein System aus der falschen Klasse. Dieser Fehler lässt sich später weder durch Anpassung noch durch Erweiterung korrigieren, weil er im Datenmodell liegt und nicht in der Konfiguration der Software.

Bemerkenswert ist, dass die Klassenzugehörigkeit in Anbieterunterlagen kaum je benannt wird. Kein Hersteller beschreibt sich als vertriebsorientierte Plattform mit begrenzter technischer Tiefe. Die Herkunft ist dennoch feststellbar, und zwar an vier Fragen: Welches Objekt steht im Zentrum des Datenmodells? Wie wird Beziehungswissen ausgedrückt? Wer pflegt das Modell im Regelbetrieb? Was genau verlässt das System nach Auftragseingang? Wer diese vier Fragen in einem Anbietergespräch stellt und auf konkreten Antworten besteht, erfährt in einer Stunde mehr über die Eignung als aus jeder Marktübersicht.

Insight 201 ordnet die Systemtypen ein. Insight 202 beschreibt das Auswahlvorgehen. Insight 203 klärt die Voraussetzungen. Insight 204 zeigt, wie fachliche Grundlagen in einen strukturierten Entscheidungsdialog überführt werden. Insight 205 führt diese Entscheidungen bis in Fertigung und Service weiter. Insight 206 schließt die Reihe mit einer Systemklassen-Methode, innerhalb derer Anbieter anschließend sachgerecht verglichen werden können.