Das Lastenheft fürs Konfigurator-Projekt: was hineingehört und was man weglassen kann
Welche Punkte in ein Konfigurator-Lastenheft gehören, welche Kapitel Ballast sind und warum das Regelwerk wichtiger ist als die Featureliste.
· 7 Min. Lesezeit
Es gibt zwei Sorten gescheiterter Lastenhefte für Konfigurator-Projekte. Die erste ist zwei Seiten dünn und besteht aus dem Satz: Wir wollen sowas wie der Wettbewerber X, bitte Angebot. Die zweite ist sechzig Seiten dick, von einer Unternehmensberatung nach IEEE-Vorlage strukturiert, und beantwortet trotzdem keine der drei Fragen, an denen solche Projekte tatsächlich hängen. Beide führen zum selben Ergebnis: Angebote, die nicht vergleichbar sind, weil jeder Anbieter die Lücken anders füllt. Dieser Artikel beschreibt, was wirklich hineingehört, und, mindestens so wichtig, was man sich sparen kann.
Die drei Kapitel, an denen das Projekt hängt
Erstens: die Entscheidungen des Kunden. Nicht die Featureliste des Konfigurators, sondern die fachliche Frage: Welche 8, 12 oder 20 Entscheidungen trifft der Nutzer, bis eine gültige Variante feststeht? Baugröße, Antriebsart, Werkstoff, Anbauteile, in welcher Reihenfolge, mit welchen Vorbelegungen. Diese Liste ist das Herz des Lastenhefts, und sie kann nur der Hersteller selbst schreiben. Aus unserer Projekterfahrung ist genau hier der Lackmustest: Wer diese Liste nicht in einer Woche aufstellen kann, ist noch nicht angebotsreif, sondern braucht erst einen internen Klärungsworkshop.
Zweitens: das Regelwerk, ehrlich beziffert. Kein Anbieter erwartet im Lastenheft alle Abhängigkeiten, aber er muss die Größenordnung kennen. Sind es 15 Ausschlussregeln oder 400? Gibt es Preisformeln mit Maßbezug oder nur Festaufpreise? Fünf bis zehn konkrete Beispielregeln in Klartext, etwa Hohlwelle nur bei Baugröße 2 und 3, Lebensmittelausführung schließt Lackierung Standard aus, sagen mehr über den Projektumfang als jedes Diagramm. Wichtig ist auch die Gegenrichtung: ausdrücklich benennen, was der Konfigurator nicht entscheiden soll, weil es Beratung bleibt.
Drittens: der Verbleib der Konfiguration. Das am häufigsten fehlende Kapitel. Der Nutzer hat konfiguriert, und dann? Anfrage per Mail an den Vertrieb, strukturierter Datensatz ins CRM, Angebots-PDF zum Herunterladen, teilbarer Link, Übergabe ans ERP? Jede dieser Antworten ist legitim, aber die Auswahl verändert Angebotspreise erheblich. Ein Konfigurator, der qualifizierte Anfragen erzeugt, ist ein anderes Projekt als einer, der Aufträge direkt in die Auftragsabwicklung schreibt, auch wenn beide auf der Website gleich aussehen.
Was noch hineingehört, in Kurzform
- Produkte und Priorität: Mit welchem Produkt wird gestartet, welche folgen? Ein Pilotprodukt mit Folgeliste ist besser als fünf Produkte gleichzeitig.
- CAD-Ausgangslage: Formate (STEP, IGES, nativ), typische Teilezahl, und ob Modelle Know-how enthalten, das nicht ins öffentliche Web darf. Ein Beispielmodell als Anlage beilegen.
- Preislogik und Preisanzeige: Listenpreis plus Aufpreise? Mengenstaffeln? Und: Wer darf Preise sehen, alle Besucher oder nur eingeloggte Kunden?
- Einsatzorte: eigene Website, Händlerseiten per Einbettung, Messe-Tablet offline? Jeder Ort bringt eigene Anforderungen an Branding und Performance.
- Sprachen und Märkte: Welche Sprachen zum Start, welche später? Nachrüsten ist möglich, aber billiger ist es, wenn die Struktur es von Anfang an vorsieht.
- Messbare Ziele: Woran wird nach zwölf Monaten Erfolg festgemacht? Anfragen pro Monat, Angebotsdurchlaufzeit, Fehlbestellungen. Ohne Zielgröße lässt sich später nichts bewerten.
- Betrieb und Pflege: Wer ändert nach dem Go-live Preise und Optionen? Der Hersteller selbst über eine Verwaltungsoberfläche oder der Dienstleister pro Änderungsauftrag?
Was man getrost weglassen kann
Technologie-Vorgaben. Kapitel, die Framework, Programmiersprache oder Rendering-Verfahren vorschreiben, stammen meist aus kopierten Vorlagen und engen die Anbieterauswahl ein, ohne Risiko zu senken. Was der Hersteller legitim fordern kann, ist das Ergebnisverhalten: läuft im Browser ohne Installation und ohne Plugin, auch auf Tablets, bedienbar ab mittlerer Mobilfunkverbindung. Wie der Anbieter das erreicht, ist seine Aufgabe, und genau dafür gibt es das Pflichtenheft als Antwortdokument.
Ebenfalls verzichtbar: seitenlange Mockups jeder Einzelansicht. Ein Konfigurator ist ein geführter Prozess, kein Screendesign-Projekt; zwei, drei Referenzen mit dem Hinweis, was daran gefällt, reichen völlig. Und die berüchtigte Wunschliste der Phase 3, also AR-Ansicht, KI-Berater, Portal-Anbindung, Onlineshop, gehört, wenn überhaupt, in einen klar abgetrennten Ausblick. Alles, was im Hauptteil steht, wird mit angeboten und mit bezahlt, ob es je gebaut wird oder nicht.
Wer liefert was? Beistellungen ehrlich einplanen
Ein Kapitel, das in Vorlagen fehlt und in Projekten regelmäßig Termine kostet: die Beistellungen des Herstellers. CAD-Modelle, Preislisten, Optionstexte, Produktfotos fürs Umfeld, die Freigabe der Beispielregeln durch den Vertrieb. All das muss jemand im Haus liefern, und dieser Jemand hat ein Tagesgeschäft. Ins Lastenheft gehört deshalb eine Zeile pro Beistellung mit Verantwortlichem und Zeitfenster. Klingt bürokratisch, verhindert aber das häufigste Verzögerungsmuster überhaupt: Der Dienstleister wartet sechs Wochen auf die finale Preisliste, während intern niemand weiß, dass er dran ist. Wer beim Schreiben merkt, dass für eine Beistellung kein Verantwortlicher benennbar ist, hat übrigens einen wertvollen Frühindikator gefunden, und zwar vor der Beauftragung statt in Projektwoche neun.
Woran erkennt man am Lastenheft einen guten Anbieter?
An den Rückfragen. Ein Anbieter, der auf ein solides Lastenheft mit einem Festpreis ohne einzige Rückfrage antwortet, hat entweder nicht gelesen oder kalkuliert die offenen Punkte als spätere Änderungsaufträge ein. Gute Anbieter fragen nach den Beispielregeln, wollen das CAD-Beispielmodell testen und hinterfragen die Preisanzeige-Entscheidung. Es ist auch ein gutes Zeichen, wenn ein Anbieter Positionen aus dem Lastenheft aktiv streicht, weil seine Engine sie standardmäßig mitbringt; bei config-getriebenen Systemen wie Configro sind etwa PDF-Angebot, teilbare Konfigurations-Links, Optionsregeln und die white-label-Einbettung per iframe Bestandteil der Engine und keine Einzelentwicklung. Solche Streichungen unterscheiden ein Produkt mit Anpassung von einem Neubau, und das ist am Ende die wichtigste Preisstellschraube des ganzen Projekts.
Ein letzter Rat zur Reihenfolge: erst die Demo, dann das Lastenheft fertigstellen. Wer vor dem Schreiben zwei, drei Konfiguratoren am Markt selbst durchspielt (frei zugängliche Beispiele gibt es etwa unter configro.de/demo), schreibt konkretere Anforderungen und erkennt, welche Wünsche Standard sind und welche echte Sonderlocken. Das kostet einen Nachmittag und spart erfahrungsgemäß die eine Angebotsrunde, die sonst nur der Begriffsklärung dient.
Häufige Fragen
Wie umfangreich sollte ein Lastenheft für einen Produktkonfigurator sein?
Für ein typisches Mittelstandsprojekt reichen 8 bis 15 Seiten. Es kommt weniger auf die Länge an als darauf, ob die drei Kernkapitel belastbar sind: die Entscheidungen des Kunden, das Regelwerk dahinter und der Verbleib der fertigen Konfiguration. Ein 60-Seiten-Dokument mit Featurelisten ersetzt keines davon.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft beschreibt, was der Auftraggeber braucht und wofür. Das Pflichtenheft ist die Antwort des Auftragnehmers, wie er es umsetzt. Beim Konfigurator-Projekt gilt: Der Hersteller kennt sein Produkt, der Dienstleister die Technik. Das Lastenheft sollte deshalb produktfachlich stark und technisch zurückhaltend sein.
Müssen alle Produktregeln schon im Lastenheft stehen?
Nein, aber ihr Umfang muss ehrlich beziffert sein: Wie viele Optionen, wie viele bekannte Abhängigkeiten, wie viele Preisbestandteile. Die Regeln selbst werden im Projekt in Workshops erhoben. Was ins Lastenheft gehört, sind fünf bis zehn konkrete Beispielregeln, an denen der Anbieter die Komplexität einschätzen kann.
Welche Angaben zu den CAD-Daten braucht das Lastenheft?
Format (STEP, IGES, natives Format), typische Dateigröße und Teilezahl je Produkt, und ob die Modelle Fertigungsdetails enthalten, die nicht öffentlich sichtbar sein dürfen. Ein Beispielmodell als Anlage sagt mehr als eine Seite Beschreibung und erlaubt dem Anbieter einen realistischen Machbarkeitstest.