Scheitern von Konfigurator-Projekten: 9 entscheidende Fehler

Autor: Walter Burgstaller

Mit über 10 Jahren Erfahrung und hunderten von erfolgreich umgesetzten Konfigurator Projekten können wir mittlerweile sehr genau sagen, warum solche Projekte scheitern. Auch wir hatten unsere Lernkurve und haben in der Vergangenheit alle dieser Fehler gemacht beziehungsweise zugelassen.

Mittlerweile managen wir seit vielen Jahren nicht nur die Projekte, sondern auch unsere Kund:innen – ein nicht zu unterschätzender Faktor - so, dass jedes von uns gestartete Konfigurator Projekt erfolgreich umgesetzt wird. Was nicht immer automatisch heißt, dass Kund:innen per se mit dem Konfigurator erfolgreich sind. Dazu mehr im Blog-Artikel: Umsatzsteigerung mittels Produktkonfigurator

Wann gilt ein Konfiguratorprojekt als gescheitert?

Einfach dann, wenn der Konfigurator nie online geht oder wenn, wenn ein oder mehrere Stakeholder der Kund:innen nicht zufrieden sind. Vorwiegend die Führungsebene oder der Vertrieb aber auch die Benutzer:innen – sowie intern als auch extern.

Es gibt 9 häufige Gründe – wobei bereits das Vorhandensein eines einzigen dieser Gründe ausreichen kann, um das Projekt zum Scheitern zu bringen:

1. Unklare Anforderungen
2. Es wurde nicht festgelegt, für wen der Konfigurator bestimmt ist.
3. Mangelhafte Definition des Produktumfangs
4. Es wurden nicht alle Stakeholder involviert
5. Problematische Anbindungen and Drittsysteme
6. Schlechte Browser Unterstützung
7. Fehlendes UI/UX Knowhow
8. Floating Scope
9. Auswahl der falschen Plattform

1.    Unklare Anforderungen

Wenn Kund:innen nur wissen, dass sie einen Konfigurator wollen, jedoch für sich selbst nicht genau definiert haben: 

• Für wen ist der Konfigurator?
• Was genau soll der Konfigurator können?
• Was genau ist der Projektumfang?
• Und wie sollen die daraus generierten Leads weiter behandelt werden? 

Dann kann ein Konfiguratorprojekt nicht erfolgreich werden. Diese Fragen klingen oftmals so trivial, dass sie zu schnell ignoriert werden, müssen aber unbedingt sauber vor Projektstart definiert werden.

2.    Für wen – die Personas

Wie oben erwähnt, ist das „für wen?“ so wichtig, dass es noch genauer beleuchtet werden muss. Wenn der Konfigurator mehrere Zielgruppen oder verschiedene Benutzergruppen ansprechen soll, ist es von entscheidender Bedeutung, klare Personas zu definieren. Dieser Punkt wird oft unterschätzt, da die Stakeholder häufig davon ausgehen, dass die Zielgruppen offensichtlich sind. In der Realität ergeben sich jedoch oft unterschiedliche Anforderungen. Was interne Vertriebsmitarbeiter:innen benötigen, unterscheidet sich möglicherweise erheblich von den Anforderungen eines Händlers oder potenzieller Kund:innen. Wenn diese Unterschiede nicht berücksichtigt werden, ist das Scheitern vorprogrammiert.
 

3.    Definition des Produktumfangs

Die Konfigurationsmöglichkeiten des Produkts müssen klar definiert werden. Welche Varianten und Optionen stehen zur Verfügung? Dies mag einfach klingen, ist jedoch in der Praxis oft schwieriger als gedacht. Unterschiedliche Stakeholder können uneinig darüber sein, was das Produkt bieten sollte. Es ist wichtig sicherzustellen, dass sich alle Stakeholder vor Projektbeginn auf den Produktumfang einigen. Alle Eigenschaften und Abhängigkeiten sollten visuell in einem Produktbaum dargestellt werden.
 

4.    Es sind nicht alle Stakeholder involviert

An den Personas und der Definition des Projektumfangs wird verdeutlicht, wie entscheidend es ist, alle Stakeholder von Anfang an in ein Projekt einzubeziehen. Werden Beteiligte zu spät oder sogar erst am Ende des Projektes einbezogen, führt das zwangsläufig zum Scheitern. Es zeigt sich somit, dass eine frühzeitige und umfassende Einbindung der Stakeholder einen wesentlichen Erfolgsfaktor darstellt. Das rechtzeitige Einholen von Feedback und die Berücksichtigung der Bedürfnisse und Perspektiven aller Beteiligten sind von entscheidender Bedeutung, um ein Projekt auf den richtigen Kurs zu bringen und erfolgreich abzuschließen.

5.    Anbindungen an Drittsysteme

Es muss Klarheit herrschen, welche Drittsysteme angebunden werden müssen. Ist es ein Shopsystem, ein PIM, ein ERP oder auch „nur“ Excel. Damit Daten im Konfigurator leicht und möglichst automatisiert aktualisiert werden können. Projekte können sich sehr schnell in die Länge ziehen, wenn dieser Punkt nicht sauber definiert wird. Oder wenn die IT – Stichwort Stakeholder – zu spät informiert und involviert wird.

6.    Browser Unterstützung

Für E-commerce Kund:innen stellt sich diese Frage gar nicht. Aber B2B Kund:innen, vor allem bei CPQ Lösungen, reichen auch Non-Browser Lösungen, da der Konfigurator ja „nur“ vertriebsintern verwendet wird. Wir sind oft in der engeren Auswahl mit reinen IT Konfigurator Lösungen, welche keine oder nur eine sehr limitierende Browser UI zur Verfügung stellen. Jeder Konfigurator unserer Kund:innen geht irgendwann online. Unsere Empfehlung: Planen Sie von Anfang an eine volle Browserunterstützung ein. Apropos Browser – es wird von Kund:innen nach wie vor unterschätzt wie wichtig es ist, auch eine Mobile Phone Unterstützung zu haben – und bei sehr umfangreichen Produkten durchaus nur in einer limitierten Form. Dies aber erst nachträglich zu implementieren kann eine Herausforderung werden.

7.    UI/UX

Ein erfolgreicher Konfigurator muss eine gute UI/UX (Benutzerschnittstelle und ihr Verhalten) haben, ansonsten wird er nicht zur Umsatzsteigerung führen. Hier können oftmals scheinbar kleine Änderungen den Unterschied machen. Was ist das Ziel des Konfigurators? Wer bedient den Konfigurator? Stichwort Personas. Leider werden oft bereits bei der grundlegenden Herangehensweise Fehler gemacht, insbesondere wenn die Innensicht die Gestaltung der Benutzeroberfläche und Benutzererfahrung definiert und wenig bis gar nicht die Bedürfnisse der Benutzerinnen und Benutzer berücksichtigt werden. 
 

8.    Floating scope

Einer der gefährlichsten Fehler ist ein ständiges Anpassen und Ändern der Anforderungen während der Projektumsetzung. Auch wenn dies immer verlockend ist, neue Ideen und Anforderungen reinzubringen, bringen diese immer unerwartete Seiteneffekte mit sich. Sie verzögern die Geschwindigkeit der Projektumsetzung (Laufzeit) oder verändern die User Experience. Eine zügiger Go-Live und das Sammeln von Erfahrungen sind wichtiger als alles sofort beim ersten Versuch umzusetzen. Je länger ein Projekt läuft, desto höher ist die Wahrscheinlichkeit, dass sich der Scope ändert – oftmals auch aus realistischen Gründen. Einfach oft auch, weil sich das Verkaufsprodukt während der Verzögerung auch in der Realität verändert hat.
 

9.    Auswahl der richtigen Plattform

Sind alle Anforderungen bekannt, sollte nochmals geprüft werden, ob die Plattform mit der man den Konfigurator umsetzen will, auch die optimale Lösung ist. Ist die Plattform auf die Anforderungen optimiert oder müssen hier „Workarounds“ gemacht werden oder gar Abstriche in Kauf genommen werden. Im Umkehrschluss sagen wir es unseren Kund:innen auch, wenn unsere Konfigurator Plattform nicht zu ihren Anforderungen passt. Sieh Blogartikel „Wann ist Combeenation nicht geeignet?“
 

Zusammenfassung

Wie bei jedem Projekt ist eine sorgfältige Planung von großer Bedeutung. Durch das Vermeiden dieser 9 Fehler legt man den Grundstein für einen erfolgreichen Konfigurator und ebnet den Weg zum Erfolg.
 

Der Combeenation Weg

Viele der oben genannten Probleme vermeiden wir durch eine Konzept Phase – siehe „Warum ein Workshop vor dem Kauf eines Konfigurators notwendig ist.“ – da werden folgende Punkte sichergestellt:

• Klare Anforderungen sowie Ziel des Konfigurators definieren
• Definition der Personas aller Konfigurator-Benutzer:innen
• Schriftliche Definition des Produktumfangs
• Alle Stakeholder werden von Anfang an involviert
• Schnittstellen an Drittsysteme werden geklärt – meist zusammen mit der IT
• Browser Unterstützung sowie Mobile Unterstützung werden geklärt und definiert
• Gut definierte UI im Corporate Design der Kund:innen und einer UX von unseren UX Expert:innen

Zur Projektumsetzung sind hier unsere persönlichen „secrets“:

• Projekte werden nur dann gestartet, wenn alle Daten von den Kund:innen da sind – das verhindert sehr viele Probleme während der Projektumsetzung.
• Wir lassen keinen „Floating scope“ zu. Nur Änderungen aufgrund von Showstoppern werden akzeptiert – alles andere wird nach dem ersten Go-Live hinten angestellt. Natürlich immer in Abstimmung mit den Kund:innen.

Geben Sie uns gerne Feedback zu Ihren bisherigen Konfiguratorprojekten. Oder planen Sie ein Konfiguratorprojekt? Gerne sehen wir uns Ihr Projekt an und geben Ihnen Feedback.