Variantenkonfiguration (Teil 4) – Ingenieure, Programmierer und IT als agile Teams

Im zweiten Blogbeitrag sind wir virtuell mit dem Fahrrad vom Vertrieb bis zur Produktion gefahren und haben die Auftragsgewinnungs- und Auftragsabwicklungsprozesse optimiert. Wir haben gesehen, wie mit einem Konfigurator, einem Baukasten und durch Automatisierung individuelle Produkte profitabel entwickelt und hergestellt werden können. Damit dies reibungslos funktioniert, sind modulare Variantenmodelle, durchgängige Prozesse und die Integration der jeweils führenden IT-Systeme unabdingbar.

Jetzt möchten wir einen Blick auf die Architektur und die Komponenten eines integrierten Varianten-Konfigurationssystems werfen, die für die erfolgreiche Realisierung notwendig sind. In der nachfolgenden Abbildung sind die einzelnen Module für die Modellierung, Konfiguration und Automatisierung und deren Zusammenspiel exemplarisch dargestellt.

Modellierungsmethodik

Mit der Modellierung von Produktkonfiguratoren verbindet man in erster Linie die Definition von Klassen, Merkmalen, Merkmalswerten und Abhängigkeiten (High-Level-Konfiguration). Konfiguratoren mit geringer bis mittlerer Komplexität zur Vertriebsunterstützung können auf diese Weise einfach und schnell modelliert werden. Ein typisches Konfigurationsergebnis wäre eine vollständige und gültige Merkmalsbewertung als Basis für mögliche Folgeprozesse wie zum Beispiel die Preisfindung und Angebotserstellung.

Zu Beginn der Modellierung ist es sinnvoll, die geforderte Varianz und den zulässigen Lösungsraum zu beschreiben. Dabei müssen Varianten-Strukturen, Elemente, Eigenschaften, Optionen und Abhängigkeiten berücksichtigt werden. Eine Darstellung als Baumstruktur ist sehr praktikabel. Ausgehend vom Kopfknoten wird der Aufbau mit Eltern-Kind-Beziehungen abgebildet. Element-Eigenschaften werden als Merkmale definiert und können verschiedene Merkmalswerte annehmen. Domains werden als Wertelisten oder Wertebereiche definiert. Der maximale Lösungsraum wird somit vollständig definiert.

Durch die Ergänzung von Beziehungswissen wird der Lösungsraum eingeschränkt. Varianz in der Struktur besteht aus Optionen und Alternativen, das heißt, ein generisches Element kann wegfallen oder vorhanden sein und durch verschiedene Objekte realisiert werden. Varianz in der Merkmalsbewertung besteht ebenfalls aus Optionen und Alternativen, das bedeutet, ein Merkmal kann wegfallen oder vorhanden sein und die Zuweisung eines gültigen Werts erfordern. Die Konfiguration ist vollständig und gültig, wenn allen notwendigen Merkmalen erlaubte Werte und allen notwendigen Elementen passende Teile zugewiesen wurden.

Anhand eines einfachen konfigurierbaren Fahrrads mit ein paar Komponenten werden der Aufbau einer Variantenstruktur mit Elementen, Merkmalen und Werten und die damit verknüpften Abhängigkeiten beispielhaft erläutert.

Das Fahrrad besteht aus dem Rahmen, Rädern und Licht. Strukturelemente werden durch Merkmale spezifiziert. Diese Merkmale können Merkmalswerte annehmen. Das Element „Rahmen“ wird durch die drei Merkmale Typ, Material und Federung definiert. Das Merkmal „Typ“ kann die Werte City, Race oder Road annehmen. Das Element „Licht“ ist optional und ist abwählbar. Analog werden weitere Elemente, Merkmale und Merkmalswerte modelliert.

Jetzt können Abhängigkeiten definiert werden. Das Beispiel zeigt zwei Regelarten: „schließt aus“ beziehungsweise „erfordert“. Ein Race-Bike gibt es nicht mit 26-Zoll-Rädern und ein Road-Bike benötigt Licht. Das Fahrradkonfigurationsmodell ist nun komplett. Während der Konfiguration einer Fahrradvariante muss das System sicherstellen, dass alle Regeln eingehalten werden.

In der Praxis müssen auch sehr große Konfigurationsmodelle modelliert werden können. Dann ist es sinnvoll, die Variantenstruktur zu zerlegen und modular aufzubauen. Für die Abbildung von Beziehungswissen steht heute ein großer Baukasten praxisbewährter Werkzeuge und Funktionen zur Verfügung. Ein modernes Varianten-Konfigurationssystem sollte möglichst viele verschiedene leistungsstarke Modellierungsmethoden und Regelarten unterstützen. Für die Abbildung komplexer Produkt-, System- und Lösungskonfiguratoren werden viele verschiedene Methoden, Objekte, Daten und Regelwerke in Kombination eingesetzt.

Ein Variantenbaukasten basiert auf einer Objektbibliothek mit Wiederholteilen (ATO), Konfigurationsobjekten (CTO) und Engineering-Templates (ETO). Diese Objekte und deren Beziehungen können auch mehrstufige modulare Variantenstrukturen abbilden (Low-Level-Konfiguration). Als Konfigurationsergebnis entsteht nun zusätzlich zur Merkmalsbewertung auch eine Produktstrukturvariante als Basis für weitere Folgeprozesse wie zum Beispiel die Generierung von Stücklisten, Arbeitsplänen, Ersatzteillisten und Visualisierung.

Komplexe Konfigurationsprojekte müssen modularisiert werden. Dies sind die typischen Module: Produktkatalog, Guided Selling, Anforderungsspezifikation, Produktvergleich, Konfiguration und Automatisierung der Folgeprozesse. Aus IT-Sicht ist es einfacher, diese Module auf Basis eines durchgängigen übergeordneten Konfigurationssystems zu integrieren, als komplexe Schnittstellen zwischen vielen Systemen implementieren zu müssen.

Auf dem aktuellen Stand der Technik können Konfigurationsmodelle jeder Komplexitätsstufe modelliert, getestet und ausgerollt werden. Diese können aus allen Grunddaten, High-Level- und Low-Level-Regelwerken, Ableitungen von anwenderspezifischen Benutzeroberflächen und der Integration von externen Systemen auf Basis eines modularen Configuration-Frameworks mithilfe einer integrierten Entwicklungsumgebung (IDE) bestehen.

Modellierungsumgebung

Die integrierte Modellierungsumgebung stellt eine Vielzahl komfortabler Funktionen zur Verfügung: Projektdefinition und Struktur, Klassen- und Objektsystem, Dateneingabe und bearbeitung, Import und Export, Modellierung des Regelwerks, Ablaufsteuerung sowie Benutzeroberflächen. Darüber hinaus gibt es automatisierbare Verwaltungs- und Integrationsprozesse für die Versionierung, das Testmanagement und die Modellgenerierung bis hin zur Auslieferung in die Laufzeitumgebung. Viele weitere Funktionen stehen als IDE-Plugins zur Verfügung.

Die Konfiguratormodellierung kann mit unterschiedlichen Arbeitsweisen erfolgen:

• „Modellorientierte“ Methoden: Diese Arbeitsweise ist beispielsweise gut für Ingenieurinnen und Ingenieure geeignet. Die Modellierung erfolgt beispielsweise in Form von Mindmaps, Tabellen arithmetischen und logischen Ausdrücken. Modellorientierte Werkzeuge sind leicht und schnell erlernbar. Programmierkenntnisse sind vorab nicht erforderlich. Allerdings gibt es Grenzen hinsichtlich der abbildbaren Komplexität.
• „Codebasierte“ Methoden: Diese Arbeitsweise ist für IT- und softwareaffine Personen geeignet. Die Modellierung erfolgt typischerweise in einer domainspezifischen Sprache (DSL) oder mittels Scripting. Codebasierte Werkzeuge haben eine steilere Lernkurve. Grundlegende Programmierkenntnisse sind hilfreich. Der analytische Ansatz ermöglicht jedoch die Abbildung beliebig komplexer Modelle.

Bei beiden Ansätzen ergeben sich typische Herausforderungen:

• Etwaige Abstimmungen zwischen Fachbereichen und Implementierung sind schwierig
• Die Datenerstellung und Regelmodellierung sind üblicherweise sehr zeitaufwändig
• Die Pflege der Daten und Regeln erfordert regelmäßig zusätzlichen Arbeitsaufwand
• Die grafische Modellierung stößt bei komplexen Sachverhalten schnell an Grenzen
• Coding oder Scripting ohne Programmierkenntnisse gefährdet die Qualität

Diese typischen Herausforderungen können heute gut gemeistert werden. Eine moderne Modellierungsumgebung auf dem aktuellen Stand der Technik unterstützt verschiedene Arbeitsweisen auf einem einheitlichen Datenmodell. Dadurch ist es möglich, dass Fachleute aus unterschiedlichen Fachbereichen mithilfe angepasster Methoden und Werkzeuge gemeinsam an den Konfigurationsprojekten arbeiten. Die Zusammenarbeit in Disziplin-übergreifenden Teams ermöglicht die effiziente und effektive Modellierung und Pflege und den Betrieb von Konfigurationsmodellen mit jeder Komplexitätsstufe.

Mit einer modernen Modellierungsumgebung werden sehr einfach Konfigurationsprojekte mit vordefinierten Ordnerstrukturen angelegt und die gewünschten Modelldateien auf Basis von Templates erzeugt, editiert und validiert. Konfigurationsmodelle werden als modulare Projekte versioniert und verwaltet. Zur Bearbeitung der Modelldaten werden verschiedene Editoren mit alternativen Benutzeroberflächen genutzt. Somit können Fachleute im Engineering und Softwareentwickelnde im Development mit ihren vertrauten Werkzeugen entsprechend ihren Expertisen sehr gut im Team zusammenarbeiten.

In der nachfolgenden Abbildung ist das Datenmodell schematisch dargestellt.

Für Expertinnen und Experten im Engineering ist es möglich, die fachliche Modellierung vorzugsweise mittels Mindmaps, Tabellen und Regelfditoren umzusetzen. Für Softwareentwickelnde im Development ist wie gewohnt auch die codebasierte Entwicklung möglich. Eine integrierte Modellierungsumgebung mit alternativen Editoren und Werkzeugen ermöglicht eine flexible und agile Zusammenarbeit von Fachleuten, Entwickelnden und Programmiererinnen und Programmierern.

Ein freigegebenes Paket der Modelldaten im Konfigurationsprojekt ist die Wissensbasis für die Ausleitung einer ausführbaren Knowledge Base (KB). Diese enthält alle relevanten Daten, Regeln und externen Verweise zur Generierung Daten-getriebener Benutzeroberflächen. Daraus ergeben sich viele Vorteile und große Flexibilität in der Frontend-Gestaltung. Eine Standardoberfläche zum Testen des Konfigurators kann vollautomatisch erzeugt werden. Optionales UI-Customizing ermöglicht angepasste Benutzeroberflächen für verschiedene Endanwenderrollen.

Interaktive Konfiguration

Nach Modellierung, Test und Freigabe des Konfigurationsmodells wird die KB ausgeleitet. Startet eine Anwenderin oder ein Anwender die Konfiguration, initialisiert die Laufzeitumgebung die passende Knowledge Base, erzeugt die dynamische Produktstruktur, führt das High-Level- und das Low-Level-Beziehungswissen aus, aktualisiert das Modell und generiert die dynamische Benutzeroberfläche. Jede Interaktion des Anwenders triggert einen Round-Trip: Das Modell wird neu ausgewertet und das Frontend aktualisiert.

Dabei wird zwischen zwei unterschiedlichen Bedienkonzepten unterschieden:

• „Abgesicherte“ Konfiguration: Dieses Bedienkonzept ist insbesondere für ungeschulte Anwenderinnen und Anwender eine gute Basis. Gestartet wird mit einer gültigen Ausgangskonfiguration. Das Regelwerk wird zur Vermeidung von Konflikten genutzt. Die Bedienung ist einfach und sicher, allerdings kann die Konfiguration in eine Sackgasse laufen. Dies bedeutet, dass, bedingt durch vorab gewählte Optionen und Abhängigkeiten, später gewünschte Optionen eventuell nicht mehr zur Verfügung stehen. Dann muss der User einen oder mehrere Konfigurationsschritte zurückgehen und seine Auswahl korrigieren, bevor die Konfiguration fortgesetzt werden kann.

• „Offene“ Konfiguration: Dieses Bedienkonzept für geschulte Anwenderinnen und Anwender und Fachleute kann mit einer leeren, unvollständigen, gültigen oder ungültigen Konfiguration starten. Dies ermöglicht eine ausgeprägte interaktive Anwendung. Das Regelwerk wird zur Erkennung und Darstellung möglicher Fehlerzustände genutzt. Funktionen für eine geführte oder automatische Konfliktbehebung oder eine zielgerichtete Optimierung können den User im Prozess unterstützen. Dieses Bedienkonzept ist deutlich anspruchsvoller, jedoch können alle Komplexitätsgrade abgebildet werden.

Es gibt wesentliche Erfolgsfaktoren der beiden Bedienkonzepte: Die Benutzeroberfläche muss an die jeweiligen Enduser (Kunde, Partner, Vertrieb, Projektierung, Konstruktion, Planung, Fertigung, Service) bestmöglich angepasst und intuitiv bedienbar sein.

Die vertriebliche Konfiguration wird häufig durch mitlaufende dynamische Preisfindung und Lieferterminierung unterstützt. Darüber hinaus sind dynamische 2D- oder 3D-Viewing-Modelle sehr interessant. Der User sieht jederzeit eine individuelle Darstellung seiner aktuellen Konfiguration. Diese zusätzlichen attraktiven Vertriebs- und Marketing-Funktionen können die finale Kaufentscheidung des Kunden maßgeblich unterstützen.

Zum Abschluss liegt das Konfigurationsergebnis vor, das für den Wiedereinstieg gespeichert oder zur Anfrage oder Bestellung in den Warenkorb gelegt bzw. weiterversendet werden kann. Auf dieser Basis können automatisierte Folgeprozesse angestoßen werden, zum Beispiel Preisfindung und Angebotserstellung für den Kunden oder die Generierung von Daten und Dokumenten für die interne Auftragsabwicklung bis hin zur Inbetriebnahme und zum Service.

Ein Varianten-Konfigurationssystem ist keine Insellösung

Die Integration in die bestehende Systemlandschaft ist ein überaus wichtiger Faktor. Das Konfigurationssystem muss auf Informationen in den angebundenen IT-Systemen zugreifen und erzeugte Ergebnisse dort speichern. In der teil- oder vollautomatisierten Generierung aller notwendigen Daten und Dokumente für die Auftragsabwicklungsprozesse steckt erhebliches Digitalisierungs- und damit Zeiteinspar- und Kostensenkungspotenzial. Medienbrüche und redundante manuelle Datenerfassung müssen abgebaut werden.

Wie geht es weiter?

In diesem Blog-Beitrag haben wir die typische Architektur eines integrierten Varianten-Konfigurationssystems und die Teilbereiche Modellierung und Konfiguration besonders betrachtet. Im nächsten Beitrag legen wir den Fokus auf die Automatisierung der Folgeprozesse. Klassische Big-Bang-Ansätze waren selten erfolgreich. Dies ist eine äußerst komplexe Aufgabenstellung. Wir werden zeigen, wie durch den Einsatz innovativer Automation-Workflow-Technologien eine schrittweise agile Umsetzung erreicht werden kann. Es lohnt sich, die erheblichen Ratio-Potenziale einer digitalen Auftragsabwicklung zu heben. Bei Interesse zu diesem Thema freuen wir uns über eine direkte Kontaktaufnahme.

Ihr möchtet erfahren, mit welchen Themen wir unsere Kunden im Bereich Manufacturing Industry bei adesso konkret unterstützen? Dann werft auch einen Blick auf unsere Website.

Die Blog-Serie im Überblick:

• Variantenkonfiguration Teil 1 - Wie belegte Baguettes helfen, Variantenkonfiguration zu verstehen
• Variantenkonfiguration Teil 2 - Mit einem Fahrrad von Vertrieb bis Produktion
• Variantenkonfiguration Teil 3 - Was nachhaltiges Heizen mit Digitalen Assistenten und einer Anwendungsarchitektur zu tun hat
• Variantenkonfiguration Teil 4 – Ingenieure, Programmierer und IT als agile Teams