Warum Konfigurator-Projekte nicht fertig werden
Wenn wir mit einem Hersteller über einen Konfigurator sprechen, ist es selten das erste Mal. Meistens gab es schon einen Anlauf. Und meistens klingt die Geschichte gleich.
Die Software wurde ausgewählt, die Lizenz gekauft, ein Pilot aufgesetzt. Der Pilot lief. Danach sollte die eigentliche Modellierung beginnen: die Produktlogik, die Regeln, die Preisbildung. Diese Aufgabe ist bei jemandem gelandet, der ohnehin ausgelastet war. Nach neun Monaten deckte der Konfigurator einen Teil des Sortiments ab. Nach zwei Jahren war er im Vertrieb nicht mehr in Gebrauch.
Das ist kein statistischer Befund, sondern ein Verlauf, den wir in dieser Form mehrfach geschildert bekommen haben.
Die Lizenz läuft in manchen Fällen bis heute.
Der Konfigurator ist nicht gescheitert. Er wurde nie fertig.
Dieses Muster ist kein Einzelfall und keine Erfindung des Vertriebs. Die Forschungsliteratur zu Konfiguratorprojekten beschreibt genau diesen Verlauf: Projekte scheitern regelmäßig daran, dass der Konfigurator nie vollständig entwickelt wird oder die Anwender am Ende nicht so unterstützt, wie es gedacht war. Als besonders anspruchsvoll gelten dabei nicht die technischen Fragen, sondern die Erhebung des Produktwissens, die Abgrenzung des Projektumfangs und die Modellierung selbst.
Wer das einmal gesehen hat, erkennt die Zwischenstände wieder. Der Konfigurator kann die Standardvarianten. Die Hälfte der Anfragen fällt aber nicht unter die Standardvarianten. Der Vertrieb legt für diese Fälle wieder eine Tabelle an. Sobald es zwei Wege gibt, gewinnt der schnellere und das ist die Tabelle.
Von da an ist der Konfigurator ein Zweitsystem. Zweitsysteme werden nicht gepflegt, und was nicht gepflegt wird, ist nach zwei Preisrunden falsch.
Das ist ein anderer Befund als "die Software hat nicht funktioniert". Und er führt zu einer anderen Konsequenz, nämlich nicht zu einem anderen Produkt, sondern zu einem anderen Vorgehen.
Das Problem ist die Definitionsarbeit, nicht das Werkzeug
Die verbreitete Erklärung lautet, das Wissen stecke in den Köpfen erfahrener Leute und lasse sich nicht herausholen. Ein Teil der Forschung hält diese Erklärung für zu einfach. Der nüchternere Befund: Das Produktwissen ist über Abteilungen, Zeichnungen und bestehende Systeme verteilt. Es zusammenzutragen, widerspruchsfrei zu machen und freizugeben ist möglich aber deutlich mehr Arbeit, als bei der Beschaffung angenommen wurde. Die Wissenserhebung gilt in der Literatur nicht ohne Grund als eigene Herausforderungskategorie.
Was dabei zusammenkommt, ist selten sortiert. Es gibt Konstruktionsregeln, die in Zeichnungen stehen. Es gibt Fertigungsregeln, die niemand aufgeschrieben hat, weil die Werkstatt sie ohnehin kennt. Es gibt Preisregeln, die teils kalkuliert und teils Erfahrung sind. Und es gibt Ausnahmen, die je nach Kunde unterschiedlich gehandhabt werden.
Diese Punkte lassen sich klären. Aber sie zu klären ist ein Projekt, kein Nebenprodukt. Es verlangt Interviews, Widerspruchsauflösung, Entscheidungen darüber, welche Ausnahme künftig gilt, und eine Freigabe durch jemanden, der für diese Entscheidungen einstehen kann.
Genau diese Arbeit ist in den meisten Projekten niemandem zugewiesen. Sie fällt der fähigsten Person im Haus zu, zusätzlich zu deren eigentlicher Aufgabe. Diese Person ist auch die, die im Tagesgeschäft am wenigsten entbehrlich ist.
Ein Konfiguratorprojekt scheitert selten an einer Entscheidung. Es scheitert daran, dass die Modellierung immer die zweitwichtigste Aufgabe einer Person bleibt, deren wichtigste Aufgabe jeden Tag dringend ist.
Eine verbreitete Antwort auf Engineer-to-Order lautet: werden Sie erst Configure-to-Order
Viele Konfigurationsplattformen spielen ihre Stärken bei Configure-to-Order aus. Das Produkt steht architektonisch fest, der Kunde wählt aus vordefinierten Bausteinen, und das System erzeugt daraus Stückliste und Preis. Für Hersteller, die so arbeiten, funktioniert das gut. Es gibt auch Konfiguratoren, die ausdrücklich für Engineer-to-Order ausgelegt sind; die Frage ist nicht, ob es sie gibt, sondern wie gut sie zu Ihrem Sortiment und Ihrem Aufwand passen.
Sehen Sie sich an, was Plattformanbieter Engineer-to-Order-Herstellern öffentlich empfehlen. Häufig lautet die Empfehlung, den Produktbaukasten zu standardisieren und den Anteil echter Einzelkonstruktion zurückzuführen. Diese Richtung ist nicht allein Anbieterinteresse: Auch in der Forschung zu ETOUnternehmen wird eine höhere Standardisierung des Angebots als Weg beschrieben. Nur ändert das nichts daran, was sie ist.
Für manche Hersteller ist das ein vernünftiger strategischer Schritt. Nur ist es kein Softwareprojekt. Es ist ein Umbau des Produktprogramms, der Konstruktion und teilweise des Vertriebsversprechens, und er wird als Softwarebeschaffung eingekauft. Deshalb dauert die Modellierung so viel länger als geplant: Bevor irgendetwas abgebildet werden kann, muss erst entschieden werden, was es künftig geben soll.
Wenn Ihr Geschäft darin besteht, dass jede Anlage anders ist, dann ist dieser Umbau nicht immer der richtige Weg. Manchmal ist die Variantenvielfalt genau das, wofür Ihre Kunden Sie bezahlen.
Zwischen "alles konfigurierbar" und "alles Einzelkonstruktion" liegt der Fall, der für ETO-Hersteller meist der realistische ist: Ein Teil des Produkts wird konfiguriert, ein anderer Teil bleibt Konstruktionsarbeit. Der Konfigurator erzeugt dann nicht das fertige Produkt, sondern den konfigurierbaren Anteil samt einer sauberen Anforderungsliste für den Rest. Das ist kein Kompromiss aus Bequemlichkeit es ist die Bauform, die zu einem Sortiment passt, das aus festen und freien Anteilen besteht. Die Frage an jeden Anbieter lautet deshalb nicht, ob er Ihr Produkt vollständig konfigurieren kann, sondern wie er mit dem Teil umgeht, der sich nicht konfigurieren lässt.
Fragen Sie früh, ob Sie eine Software einführen oder Ihr Produktprogramm umbauen. Beides kann richtig sein. Nur sind es zwei verschiedene Projekte mit zwei verschiedenen Laufzeiten.
Ein Regelwerk ist kein Projekt, sondern ein Bestand
Produktwissen ändert sich laufend. Zulieferer wechseln, Normen werden aktualisiert, Preise bewegen sich, eine Baureihe kommt hinzu. Jede dieser Änderungen muss im Regelwerk nachgezogen werden, sonst driftet der Konfigurator von der Wirklichkeit ab. Und ein Konfigurator, dem der Vertrieb nicht mehr traut, wird nicht diskutiert, sondern umgangen.
Deshalb ist die Frage nach der Pflege keine Betriebsfrage für später, sondern eine Frage der Wirtschaftlichkeit vor der Entscheidung. Wer pflegt das Regelwerk in zwei Jahren? Mit welchem Zeitanteil? Und was passiert, wenn diese Person das Unternehmen verlässt?
Wenn die Antwort auf die erste Frage dieselbe ausgelastete Person ist, die schon die Erstmodellierung machen sollte, kennen Sie den weiteren Verlauf bereits.
Wir liefern nicht das Werkzeug, sondern das fertige System
Wir verkaufen Ihnen keine Plattform, in der Sie anschließend Ihr Produkt selbst modellieren. Die Modellierung ist der Auftrag, nicht Ihre Hausaufgabe danach.
Wir schreiben Ihre Regeln auf, Sie zeichnen sie frei
Materialregeln, Fertigungsgrenzen, Zuschläge, die Ausnahmen, die Ihr Vertrieb nach Gefühl gewährt. Das wird dokumentiert, Ihnen vorgelegt und von Ihnen freigegeben. Der Nebeneffekt ist oft wertvoller als die Software: Zum ersten Mal steht an einer Stelle, wie Ihr Haus eigentlich kalkuliert.
Das Produkt wird erzeugt, nicht ausgewählt
Wir bilden nicht einen Katalog vormodellierter Varianten ab, sondern erzeugen das Produkt zur Laufzeit aus seinen Bestandteilen Profile auf Länge, Anbauteile gesetzt, Modell zusammengebaut. Die Regeln darunter prüfen die Baubarkeit: Kombinationen, die als nicht herstellbar hinterlegt sind, lassen sich nicht auswählen. Wie weit das trägt, hängt davon ab, wie vollständig Ihre Fertigungsgrenzen erfasst und gepflegt sind auch das gehört zur Definitionsarbeit.
Wir werden am sechsten Monat gemessen, nicht an der Abnahme
Der Maßstab ist nicht, ob das System abgenommen wurde, sondern ob es ein halbes Jahr später noch täglich benutzt wird. Deshalb klären wir die Pflegefrage vor dem Angebot und nicht danach.
Wir bauen für ETO und MTO, wie sie sind
Wir setzen nicht voraus, dass Sie Ihr Sortiment vorher vereinheitlichen. Wenn eine Standardisierung sinnvoll ist, sagen wir das aber als eigenes Thema, nicht als versteckte Vorbedingung.
Fünf Fragen an jeden Anbieter, uns eingeschlossen
Wenn die Antwort eine Person in Ihrem Haus ist, klären Sie, wie viele Stunden pro Woche dafür freigestellt werden und wer deren laufende Arbeit übernimmt.
Nicht das Sortiment, sondern die tatsächlichen Anfragen. Der Rest bestimmt, ob die Tabelle im Vertrieb bleibt.
Wenn ja, gehört dieser Aufwand in dieselbe Rechnung wie die Lizenz.
Und was kostet diese Pflege, wenn wir sie nicht selbst leisten wollen?
Anteil der Angebote aus dem System, Durchlaufzeit von Anfrage zu Angebot, Zahl der Nacharbeiten. Vor Projektbeginn festlegen, nicht danach.
Wenn bei Ihnen bereits ein Anlauf gescheitert ist, ist die dokumentierte Modellierung aus diesem Projekt kein verlorener Aufwand. Sie ist häufig der brauchbarste Ausgangspunkt für den zweiten Versuch - unabhängig davon, mit wem Sie ihn unternehmen.
Dreißig Minuten, ein echter Vorgang.
Bringen Sie eine Anfrage mit, die Ihr Vertrieb tatsächlich bearbeitet hat. Wir gehen sie durch: welche Regeln darin stecken, welche davon dokumentiert sind und welche nicht. Danach wissen Sie, wie groß die Definitionsarbeit bei Ihnen wirklich ist auch wenn Sie mit jemand anderem weitermachen.
Sie führen die Fabrik. Die Software überlassen Sie uns.