Das klingt nach einer sehr spannenden Herausforderung. Wäre diese so an uns herangetragen worden, hätten wir damals wohl dankend abgelehnt. Oder unser Kunde, wenn er eine Kostenabschätzung dafür gesehen hätte. Dass wir es nicht getan haben (das Ablehnen), liegt wohl mit daran, dass der Anforderungsberg erst im Laufe der Zeit so umfangreich anwuchs – und zwar zu dem Zeitpunkt, an dem der Kunde feststellte, dass die Möglichkeiten weit über seinen anfänglichen Erwartungen lagen. Doch der Weg zum fertigen Produktkonfigurator war und ist noch immer steinig. Denn “fertig” gibt es nicht und unser Kunde hat immer wieder neue Ideen, welche man in (die) Software gießen kann.

Ich durfte nun sieben Jahre lang Erfahrung mit der Entwicklung eines Systems sammeln, welches als “Konfigurator für Betonstützen” anfing und mittlerweile weite Teile des Kerngeschäfts des Auftraggebers facettenreich abbildet. Auch bei anderen Kunden begegnete mir das Thema Produktverwaltung in unterschiedlichem Umfang. Darüber könnte man Bücher schreiben, aber ich schreibe lieber Software. Daher beschränkt sich dieser Artikel auf die Frage, was ein Produktkonfigurator eigentlich ist und wo sich Schwierigkeiten in diesem Umfeld verstecken.

Was braucht unser Auftraggeber eigentlich?

Nicht von Interesse seien an dieser Stelle Standardprodukte, deren mögliche Ausprägungen sich von Vornherein auf wenige, überschaubar viele Varianten beschränken. Also vielleicht einige Tausend. Ein Produzent von bunten Holzwürfeln, die sich nur in ihrer Farbe und Holzart unterscheiden, wird keinen Produktkonfigurator, sondern einen Katalog benötigen. Jedes Online-Shopsystem und jedes ERP kann so etwas. Problem gelöst. Das muss nicht bedeuten, dass unser Auftraggeber keine anderen Probleme hätte, bei denen wir ihm behilflich sein können. Doch wie gesagt: Bücher, Software.

Für mehr Abwechslung

Softwaretechnisch interessant wird die Abbildung von Produkten, die eine gewisse Variabilität aufweisen. Diese kann verschiedener Natur sein:

Ein Hersteller von Holzquadern mit beliebigen Abmessungen und unterschiedlich gefärbten Flächen kommt mit einer endlichen Liste von Möglichkeiten nicht weit. Hier möchte man einen Katalog von Grundprodukten haben, wo festgelegte Dimensionen in einem vordefinierten Bereich variier- und validierbar sind.

Bei einem Standardprodukt mit wenigen Variablen bzw. mit solchen, die keinen großen Einfluss auf die Produktionsaufwände haben, sollte eine “Pi mal Daumen”-Abschätzung der Herstellkosten reichen, so lange diese im Jahres- oder Quartalsmittel durch die Verkaufspreise abgedeckt sind. Wichtigste Stellschraube wäre hier der Deckungsbeitrag bzw. die Marge, um aus einem Herstellpreis einen Verkaufspreis und die nötige Kennzahl für die Gehalts-Bonus-Berechnung des Verkäufers zu erhalten.

Ein solches System, bei dem aus der Variation einzelner Dimensionen relativ direkt Kostenunterschiede errechenbar sind, bezeichne ich als Produkt-Konfigurator. Produktkonfiguratoren können Endkunden-tauglich gestaltet werden. Voraussetzung ist natürlich, dass nur herstellbare Konfigurationen zulässig sind. Man findet solche Anwendungen überall online, von Autokauf (“ABS serienmäßig, aber Sitzheizung, CD-Wechsler und Farbe sind auswählbar”) bis Zustellservice (“Wie schwer ist das Paket, wie weit der Weg und soll es Standard, Express oder Overnight Delivery sein?”). Der Endkunde wählt ein Produkt aus und schraubt dann an der Ausstattung herum, bevor die Bestellung oder Preisanfrage abgesendet wird.

Weite Bereiche dieser Problemdomäne sind mit Hilfe von E-Commerce- und ERP-Systemen abbildbar. Auch ließe sich ihre Logik noch halbwegs erträglich in einer Excel-Datei abbilden, was viele unserer Kunden genau so tun. Leider bleiben sie meist auch dabei, wenn die Komplexität weiter steigt und sich in den Tabellen viel verstecktes Wissen und Logik angesammelt hat, die niemand mehr überblickt. Dann tut der Umstieg auf eine produktivere Plattform unnötig weh.

Lego für Erwachsene

Eine besondere Art des Produktkonfigurators, welche ich hier als Produkt-Baukasten bezeichnen möchte, spiegelt das bei vielen Herstellern – beispielsweise in der Automobilindustrie – verwendete Baukastenprinzip in der Produktion wieder. Wo vordefinierte Komponenten konzeptionell oder physikalisch in verschiedenen Kombinationen zu einem komplexen Endprodukt zusammengesetzt werden können, ist eine flexible Produktgestaltung bei gleichzeitig hohem Standardisierungsgrad auf Komponentenebene möglich.

Ab einem gewissen Umfang werden Produkt-Optionen bzw. -Komponenten aber unweigerlich mit einander in Wechselwirkung treten. Optionen können einander bedingen oder ausschließen und sich in ihren Abmessungen oder anderen Dimensionen beeinflussen. Dieser Effekt wird umso stärker, je weniger die physikalische Produktionskette auf das Baukasten-Prinzip ausgelegt ist.

Die große Herausforderung bei der Entwicklung eines Produktbaukastens besteht darin, diese Wechselwirkungen zwischen einzelnen Produktaspekten oder -Komponenten wartbar und nachvollziehbar abzubilden. Hier bietet sich ein Spektrum an Lösungsmöglichkeiten, deren Extreme sich meiner Ansicht nach folgendermaßen darstellen.

Alles Ausprogrammieren

Alles, was über ein Produkt und den internen Abhängigkeiten zwischen seinen Aspekten bekannt ist, wird nach OO-Prinzipien in Code abgebildet. Ich betone hier die Objektorientierung, weil diese meiner Meinung nach den konzeptionellen Sprung von jeder Excel-Lösung hin zu einem funktionierenden System darstellt.

Vorteil einer komplett ausprogrammierten Lösung wird immer sein, dass man eine hundertprozentige Kontrolle über jedes Detail der Implementierung hat und jeden Kundenwunsch grundsätzlich umsetzen kann. Der Nachteil aus Sicht des Kunden dürfte aber darin bestehen, dass die Umsetzung schnell aufwendig und damit kostenintensiv werden kann. Dazu kommt die Notwendigkeit ständiger Entwicklungsaufwände bei jeder Änderung am Produkt selbst oder seines Herstell-Prozesses und damit gerne auch die langfristige Bindung an seinen entwickelnden IT-Dienstleister.

Konfigurieren

Vielfach könnte unserem Kunden bereits mit einem System geholfen sein, welches ihm erlaubt, ein abstraktes Komponenten- oder Feature-Modell zu konfigurieren, dessen kalkulatorischen Aspekte er selbst analog zu seiner früheren Excel-Lösung implementieren kann. Je nach Kundenanforderungen sollten sich zu jedem Feature die benötigten Dimensionen, deren Wertebereiche und Default-Werte sowie Materialbezüge und grundsätzliche Feature-Kollisionen konfigurativ festlegen lassen. Für komplexere Berechnung z.B. von Default-Werten würde man eine Formel-Engine verwenden, welche für sämtliche ernstzunehmenden Programmiersprachen verfügbar sind.

Systeme dieser Art können zwar im Kern relativ generisch gehalten werden, bringen aber erst durch Berücksichtigung der Fachdomäne des Produktherstellers einen Mehrwert. Hier können allenfalls Branchenspezifische ERP-Systeme in einem gewissen Rahmen noch punkten. Daher stellt dieser Ansatz für Unternehmen, die unter Schmerzen mit Excel und ihrem ERP leiden, einen exzellenten und erprobten Einstieg in die Entwicklung einer Individualsoftware dar. Wenn die Schmerzen nachgelassen haben, finden sich erfahrungsgemäß bald wie von selbst viele Anknüpfungspunkte für weitere softwaregestützte Geschäftsoptimierungen.

Rührei mit Speck und Wolle.

Ein wirklich spannendes Projektumfeld stellt aber erst der nächste Schritt in der Evolution dar, den man als Produkt-Designer bezeichnen könnte. Solche Systeme haben nicht nur die Aufgabe, vorgegebene Varianten zu erfassen, sondern übernehmen ihrerseits einen Teil des Engineerings. Hierbei kann es sich um die (automatische) Dimensionierung von Bauteilen unter Berücksichtigung ästhetischer Kundenvorgaben, rechtlicher Rahmenbedingungen und physikalischer Gesetzmäßigkeiten gleichermaßen handeln. Solche Systeme erfordern eine umfangreiche Kenntnis bzw. ein Modell der Umgebung, in der das Produkt hergestellt und eingesetzt werden soll. Sie bilden viele oder alle Sichtweisen auf ein Produkt ab, von Herstellkosten-Kalkulation bis Planerstellung. Hier bewegen wir uns mit dem eingangs erwähnten System. Produkt-Designer sollten (und können) nur dann entwickelt werden, wenn sich der Produkt-Fabrikant davon massive Kostenersparnisse durch Personaleinsparung, Umsatzsteigerung oder Fehlerminimierung verspricht: wenn sie also sein umsatzstärkstes Kerngeschäft abdecken.

Was ist ein Produkt? Oder: Worauf konzentriere ich mich?

Um dem Endkunden ein realistisches Angebot über ein relativ hoch variables Produkt geben zu können, sollte der Fokus optimalerweise auf einer möglichst realistischen Abschätzung der Herstellkosten liegen. Nur(?) so lässt sich der tatsächliche finanzielle Spielraum der Verkaufsabteilung feststellen. Dazu muss der Herstellprozess in vernünftigem Maße bekannt und bei Änderungen möglichst auch kurzfristig anpassbar sein. Daraus folgt unmittelbar die Notwendigkeit zweier Modelle: dem Modell der Produktstruktur selbst und dem Modell des Produktionsprozesses. Dabei spielt es keine Rolle, ob man die eigene Produktion als Black-Box analog zu einem externen Dienstleister betrachtet oder die Produktionsstraße in voller Detailfülle abbildet: Kernvoraussetzung ist, dass sich zu “jeder” möglichen/sinnvollen Produktausprägung automatisch eine Zeit oder ein Preis (diese lassen sich über die Formel Zeit = Geld in einander umrechnen) finden lässt. Stellen, an denen Einzelverhandlungen mit Zulieferern während des Konfigurationsprozesses notwendig sind, schränken die Möglichkeiten eines solchen Systems drastisch ein.

Der konzeptionelle Kern

Unserem Auftraggeber wird nicht von Anfang an klar sein, was seine Kernanforderung an eine von uns zu entwickelnde Softwarelösung ist. Alle Aspekte eines Produktes lassen sich mit vertretbarem Aufwand wohl nie in Software abbilden, daher sollte der Kern, um den sich alles dreht, möglichst früh im Laufe der Anforderungsanalyse erkannt werden.

Dies ließ sich schön am Beispiel des eingangs erwähnten Projektes erleben: bevor wir mit der Lösung des Problems beauftragt wurden, hatten bereits zwei andere Unternehmen sich der Aufgaben angenommen: Ein CAD-Hersteller hatte natürlicherweise die konstruktiven Aspekte des Produktes in den Mittelpunkt gestellt und versucht, den CAD-Kern der Anwendung um kostenkalkulatorische Aspekte und einen Angebotsprozess zu erweitern. Dieser Ansatz ist bereits nach überschaubarer Zeit gescheitert, scheint aber aktuell in einem ähnlich gelagerten Projekt bei einem Kooperationspartner Früchte zu tragen. Ein weiterer Versuch wurde mit einem Anbieter von ERP-Lösungen angepeilt. Hier wäre zwar eine Umsetzung aller kaufmännischen Prozesse mittels Standardsoftware möglich gewesen, aber das abzubildende Produkt (Beton-Fertigstützen) war in seinen Ingenieurs- und Konstruktionsanforderungen so komplex, dass man keinen sinnvollen Lösungsweg mit den verfügbaren Mitteln sah.

Teile und herrsche

Unser Ansatz bestand darin, das Produkt vorerst als Abstraktes, aus Einzelkomponenten bestehendes Modell zu betrachten und die verschiedenen konstruktiven, kaufmännischen und fertigungstechnischen Anforderungen möglichst komponentenweise zu beleuchten.

Es fing mit vier Hauptkomponenten an: eine Stütze hat einen Mittelteil, welcher aus Stahl und Beton besteht und eine Raumhöhe überbrückt; ein Kopf- und ein Fußdetail, welche aus verschiedenen Stahl- oder Betonelementen bestehen und deren wesentliche Aufgabe in der Krafteinleitung aus der Decke in die Stütze hinein bzw. umgekehrt am Boden wieder heraus besteht; daneben gibt es weitere Zusatzkomponenten (“Einbauteile” oder “Optionen”), welche den Herstellpreis beeinflussen. Dieses einfache Modell wurde sehr bald erheblich verfeinert. Ein Kopfdetail kann beispielsweise verschiedene aufgeschweißte Platten und Eisenstangen enthalten, die einander bedingen oder ausschließen. Diese Abhängigkeitsregeln lassen sich gut in einem von finanziellen, zeichnerischen oder produktionstechnischen Eigenschaften unabhängigen Vokabular formulieren. Wir nannten dieses abstrakte Gebilde unser “Zentrales Komponentenmodell”, von dem alles andere abhängt.

Die Erzeugung von Artefakten, wie z.B. CAD-Plan, Nachweisdokumente oder Kostenkalkulationen, stellt in den folgenden Schritten eine Außensicht auf das eigentliche Produktmodell dar und sollte daher auch in Architektur und Code so behandelt werden.

Selbstverständlich beeinflussen Details des Herstellprozesses, rechtliche Bestimmungen, Kundenwünsche und Lieferbarkeit von Rohmaterialien die im konkreten Fall möglichen Produkteigenschaften. Aber allein die konkrete Implementierung dieser Beschränkungen von den strukturell möglichen Kompositionen zu trennen, ermöglicht einen Fokus entweder auf deren konkrete Implementierung oder die logische Vollständigkeit des Modells. Das ist wichtig, weil genau bei diesen Detailberechnungen üblicherweise die Expertise des Kunden liegt. Nur schafft dieser es dann nicht, die Vielzahl der konkreten Berechnungsdetails in ein funktionierendes, wartbares Gesamtkonstrukt zu überführen (auch nicht mit noch so vielen Excel-Dateien).

Leider ist doch alles kompliziert

Während sehr viele Aspekte bzw. Dimensionen eines Produktes sich lokal, d.h. losgelöst von anderen Aspekten/Dimensionen lösen lassen (z.B. einfache Default-Werte, auch in Abhängigkeit anderer Werte), gilt das nur bis zu einem gewissen Komplexitätsgrad. Je mehr Dimensionierungsverantwortung die Software selbst übernehmen soll, wenn der Benutzer als Entscheider mit Gesamtüberblick also mehr und mehr wegfällt, desto weniger lassen sich Produktaspekte isoliert betrachten.

Eigenschaften hängen gerne auch rekursiv von einander ab. Hier muss dann im Rahmen der Anforderungsanalyse detailliert entschieden werden, wo die Rekursion durchbrochen werden kann oder muss, bzw. welche Eigenschaften Vorrang vor anderen haben. Ein triviales Beispiel aus der Welt der Stützen: die Summe aller Komponentengewichte ergibt das Gesamtgewicht einer Stütze, welches die Mindestabmessung der benötigten Hebe-Anker vorschreibt, deren Gewicht wiederum (rein formal) das Stützengewicht mitbestimmt. Während hier eine einfache Ausnahmeregelung (“vernachlässige das Gewicht von Ankerkomponenten”) ausreicht, gibt es komplexere Zusammenhänge, die unter Umständen sogar erst kurz vor der eigentlichen Produktion definitiv aufgelöst werden können.

Beispiel rekursive Abhängigkeiten

Ein konkretes Beispiel unseres Betonstützenherstellers wäre der Zusammenhang zwischen Herstellmethode, Beton-Rezept, statischer Belastbarkeit der Stütze, Schalungsauswahl und Querschnittsform.

Initial wählt der Benutzer die Länge, benötigte Tragfähigkeit, Form und Abmessungen der Stütze aus: diese wird normalerweise vom Architekten vorgegeben. Anschließend kann, muss aber nicht, eine Herstellmethode (“Schleuderbeton”, SB, oder “Selbstverdichtender Beton”, SCC) ausgewählt werden. Mittels Schleuderverfahren hergestellte Stützen sind innen hohl, besitzen also aufgrund der geringeren Querschnittsfläche eine niedrigere Belastbarkeit (dafür eine glattere, dichtere Oberfläche). SCC-Stützen können, abhängig von der verfügbaren Schalung (=“Guss-Form”, also das Behältnis, welches den Beton bis zum vollständigen Abbinden stützt), nur bis zu einer gewissen Länge hergestellt werden. Dafür können quasi beliebig viele unterschiedliche SCC-Schalungen parallel befüllt werden, während die Schleuder-Anlage nur eine Form, dafür aber eine mit 30m Länge auf einmal aufnehmen kann. Die Herstellmethode schränkt die Menge der möglichen Betonrezepte (=Mischungsverhältnisse von Sand, Kies, Zement, weiteren Zuschlagsstoffen etc.) ein. Außerdem kann ein Betonrezept ausgewählt werden, muss aber nicht. Dieses gibt die Herstellmethode und die Festigkeit des Betons vor. Man kann auch nur eine gewünscht Betonfestigkeit vorgeben. Eine höhere Festigkeit wirkt sich negativ auf den Brandwiderstand, aber positiv auf die Tragfähigkeit aus. Anschließend kann, muss aber nicht, eine Anzahl Bewehrungseisen ausgewählt werden. Je mehr Eisen in einer Stütze enthalten sind, desto höher wird ihre Tragfähigkeit, aber desto (signifikant) teurer auch die Herstellung.

Mit diesen Angaben sollte das System nun die kostengünstigste Basis-Stütze dimensionieren, bei der alle nachfolgenden Bedingungen erfüllt sind:

  • garantierte Tragfähigkeit gemäß normiertem Traglastnachweis
  • geforderte Brandwiderstandsklasse wird eingehalten
  • Stützenlänge <= Schalungslänge
  • Betonfestigkeit ist maximal so hoch wie gefordert

Es sollte jedoch nicht nur die kostengünstigste Stützenkonfiguration ermittelt werden, sondern auch Alternativ-Vorschläge für den Benutzer zur Auswahl gestellt werden: Wenn ein SB-Querschnitt funktioniert, dann funktioniert auch ein SCC-Querschnitt mit ansonsten gleichen Parametern. Verschiedene Eisenanordnungen können kalkulatorisch ähnlich teuer, aber von der Herstellung her effizienter sein. Solange dem System diese Erfahrungswerte nicht “beigebracht” werden können und nur als unausgesprochene Erfahrungswerte im Raum stehen, ist eine systematische Lösung dieses Problems unnötig erschwert.

Das Gesamt-Problem stellte sich letzten Endes als überwiegend UI-technischer Natur heraus, da eine Überparametrisierung des Modells zu einfach möglich ist. Manche Anforderungen ließen sich zum Glück auch wegdiskutieren, nachdem erwiesen war, dass das System konsistentere und zuverlässigere Entscheidungen trifft, als die Menge aller Benutzer. Andere wurden gelöst, indem die Erfahrungswerte systematisch hinterfragt und formalisiert wurden.

Eine Lösungsmöglichkeit kann das Aufbrechen des Definitionsprozesses in eine zeitliche Abfolge (“Wizard”) sein, wo z.B. früher gemachte Angaben immer Vorrang zu später gemachten Angaben haben. Dieser Schritt allein reicht aber nicht unbedingt aus. Am Ende muss irgendwie festgelegt werden, welche Angaben zum Produkt unveränderliche “must-have”-Vorgaben sind und welche Aspekte das System selbständig variieren darf, um eine konsistente Lösung zu finden.

Generell lässt sich wohl sagen, dass sich die Art der Interaktion mit einem Produktmodell durchaus auf dessen Aufbau auswirkt: Eine Batch-weise, automatisierte Dimensionierung stellt weit höhere Anforderungen an dessen Vollständigkeit, als eine iterative Interaktion mit dem Entscheidungen treffenden Anwender.

Eine weitere, sehr wichtige und immer wieder zu treffende Abwägung lautet: Dient das System primär der Vermeidung von Fehlern (durch Unachtsamkeit, Unwissen oder den Montagmorgen) oder der Unterstützung eines Experten, der jeden einzelnen Wert bewusst überschreiben können möchte? Beide Ansätze sind absolut valide, aber nur schwer auf einem Weg miteinander vereinbar. Hier sind schlaue™ UX-Konzepte und eine regelmäßige Analyse der tatsächlich gemachten Fehler und deren Gesamtkosten gefragt. Doch das ist genug Stoff für einen eigenen Artikel.

Erkenntnis

Erschreckende oder erstaunliche Momente ergeben sich manchmal, wenn beim Ausprogrammieren von Produktaspekten Zusammenhänge zu Tage treten, die noch nicht einmal die Ingenieursabteilung des Herstellers bedacht oder erkannt hat. Ursächlich sind diese manchmal in der unterschiedlichen Denk- und Arbeitsweise von Ingenieuren und Naturwissenschaftlern oder Informatikern begründet. Vereinfachende Annahmen, die in vielen verwendeten Formeln getroffen werden, helfen zwar dem klassischen Ingenieur bei der Arbeit mit Tabellen und Taschenrechner, können aber andere Arten der Implementierungskomplexität schaffen (vergleiche Multi-Tabellen-Lookup mit Lösen eines linearen Gleichungssystems).

Und nicht nur das. Oft verstecken sich in Ingenieursformeln viele Sicherheitsfaktoren, die ein Verlassen des zulässigen Wertebereiches der vereinfachten Berechnungsmodelle verhindern sollen. Solche Stellen zu identifizieren und, wo dies (Normen-)rechtlich zulässig ist, durch ein realitätsnäheres, optimalerweise geschlossenes Formelsystem zu ersetzen, kann dem Kunden, z.B. durch höhere Materialauslastung, Kostenvorteile bringen.

Der gleiche Effekt tritt aber auch umgekehrt in Erscheinung: Als Informatiker erkennt man gerne Abhängigkeiten und Problemkategorien, von denen man schon an der Uni gelernt hat, dass diese nicht (effizient) lösbar sind. Die Tatsache, dass unser Kunde dennoch in der Lage ist, sein Produkt zu bemessen und herzustellen, sollte uns als Softwareentwickler gelegentlich daran erinnern, dass nicht jede formale Abhängigkeit auch für den Kunden relevant ist. Das obige Beispiel mit den Hebeankern für Stützen sollte dies verdeutlichen.

Und dann?

Wenn eine Produktdesign-Anwendung einmal ausgereift genug ist, dass am Ende die Verkäufer nur noch verkaufen müssen und die Ingenieure und Konstrukteure die interessanten 20% der Ausnahmefälle konstruieren brauchen, ergeben sich durchaus auch mal neue Vertriebskanäle und Prozessoptimierungen: Den Endkunden gleich selbst die Arbeit der Produkterfassung zu überlassen, welcher mit einem instantanen Kostenvoranschlag belohnt wird (Kundenportal, Online-Bestellung), ist gerade für mittelständische produzierende Unternehmen noch immer komplettes Neuland. Weil nicht nur unser eingangs erwähnter Kunde diesen Schritt aber zu wagen versucht, steckt dieses Umfeld auch nach Jahren noch voller interessanter Herausforderungen.

TAGS