DWC INSIGHT 003 · DECISION GUIDE

CPQ Readiness Assessment

Warum die Vorbereitung über den Projekterfolg entscheidet

Wenn die Software bereit ist, das Unternehmen aber nicht

CPQ-Projekte beginnen häufig mit großer Zuversicht. Die Zielsetzung ist attraktiv: Angebote sollen schneller entstehen, Varianten sicher beherrscht, Preise konsistent berechnet und technische Ergebnisse ohne Medienbruch an Engineering und Produktion übergeben werden. Anbieter zeigen leistungsfähige Oberflächen, überzeugende Konfigurationsdialoge und weitreichende Integrationsmöglichkeiten. Dennoch geraten viele Vorhaben bereits in der frühen Umsetzung ins Stocken. Nicht weil die Software grundsätzlich ungeeignet wäre, sondern weil das Unternehmen für ihre wirksame Nutzung noch nicht ausreichend vorbereitet ist.

Genau hier setzt ein CPQ Readiness Assessment an. Es prüft nicht, welches System am Markt am besten bewertet wird. Es klärt, ob Portfolio, Produktlogik, Prozesse, Daten, Organisation und Systemarchitektur so weit entwickelt sind, dass eine CPQ-Lösung überhaupt sinnvoll ausgewählt und eingeführt werden kann. Readiness ist damit keine Vorstudie am Rand des Projekts. Sie ist die unternehmerische Voraussetzung dafür, aus einer Softwareinvestition eine dauerhaft tragfähige Fähigkeit zu machen.

Diese Betrachtung schließt an Insight 002 an. Dort ist beschrieben, warum die Auswahl eines CPQ-Systems keine Softwarebewertung, sondern eine Architekturentscheidung ist, und in welcher Reihenfolge Zielbild, Produktmodell und Anbieterprüfung zusammenwirken. Insight 003 setzt eine Stufe davor an. Er behandelt nicht das Vorgehen der Auswahl, sondern die Frage, ob ein Unternehmen die Voraussetzungen dafür bereits erfüllt. Die Nummerierung der Reihe folgt der Veröffentlichung, nicht der Projektlogik: Im Projekt steht die Readiness vor der Auswahl.

Die zentrale Frage lautet deshalb nicht, ob die Fachbereiche bereit sind, an Workshops teilzunehmen. Entscheidend ist, ob das Unternehmen seine Produktvielfalt beschreiben, seine Prozessklassen unterscheiden, seine Datenquellen benennen und seine Verantwortlichkeiten verbindlich festlegen kann.

Neun Dimensionen der Readiness

Ein CPQ Readiness Assessment ist kein offener Analyseauftrag. Es prüft neun Dimensionen, die gemeinsam darüber entscheiden, ob eine Konfigurationslösung wirksam werden kann. Jede Dimension trägt eine eigene Leitfrage, und Schwächen in einer Dimension lassen sich durch Stärken in einer anderen nicht ausgleichen.

Dimension	Zentrale Managementfrage
1. Portfolio und Scope	Welcher Teil des Angebots ist wiederholbar, und wo beginnt die Einführung?
2. Produkt-Prozess-Klassen	Welche Aufgabenklassen liegen vor, und wo verlaufen ihre Grenzen?
3. Produktstruktur und Datenmodell	Sind Merkmale, Regeln, Strukturen und Stücklisten eindeutig definiert?
4. Guided Selling und Nutzerführung	Lässt sich Kundenbedarf in Produktlogik übersetzen?
5. Pricing, Costing und Dokumente	Entstehen Preis, Kosten und Angebotsunterlagen regelbasiert?
6. Systemrollen und Integration	Welches System führt welches Objekt?
7. Visualisierung und Automatisierung	Sind Geometrie und Konstruktionsregeln standardisiert?
8. Betriebsmodell und Sicherheit	Welche Eingriffstiefe ist zulässig, ohne Releasefähigkeit zu verlieren?
9. Governance und Modellpflege	Wer verantwortet das Produktmodell nach dem Go-live?

Die folgenden Abschnitte behandeln diese neun Dimensionen in der genannten Reihenfolge.

Readiness ist mehr als Projektbereitschaft

In vielen Unternehmen wird Bereitschaft organisatorisch verstanden. Ein Projektteam ist benannt, ein Budget reserviert, ein Sponsor gefunden und ein grober Terminplan beschlossen. Das ist notwendig, reicht aber nicht aus. Ein CPQ-Projekt greift tief in die Art ein, wie Produkte beschrieben, verkauft, kalkuliert, dokumentiert und in ausführbare Aufträge überführt werden. Es verändert deshalb nicht nur einen Vertriebsprozess, sondern berührt die Produktarchitektur und die Zusammenarbeit mehrerer Funktionen.

Schwächen in einer der neun Dimensionen lassen sich durch zusätzliche Softwarefunktionen nur begrenzt ausgleichen. Eine leistungsfähige Regelengine ersetzt kein geordnetes Portfolio, und eine ausgereifte Oberfläche ersetzt keine geklärte Datenverantwortung.

Eine leistungsfähige Regelengine ersetzt kein geordnetes Portfolio. Eine ausgereifte Oberfläche ersetzt keine geklärte Datenverantwortung.

Der Nutzen der Prüfung liegt gerade darin, Unsicherheiten früh sichtbar zu machen. Ein Unternehmen muss zu Beginn nicht in allen Bereichen vollständig reif sein. Es muss aber wissen, wo belastbare Grundlagen vorhanden sind, wo Annahmen bestehen und welche Lücken vor einer Auswahl, einem Proof of Concept oder einer Einführung geschlossen werden müssen. Readiness ist deshalb kein Reifegradetikett, sondern ein Instrument zur Risikoklärung und Priorisierung.

Das Portfolio bildet den Ausgangspunkt

Jede CPQ-Initiative beginnt beim Portfolio. Ohne eine klare Sicht auf Produktfamilien, Optionen, Zubehör, Dienstleistungen und kundenspezifische Anteile bleibt unklar, was überhaupt ausgewählt, konfiguriert oder projektiert werden soll. Viele Unternehmen verfügen über umfangreiche Produktkataloge und ERP-Stammdaten, aber nicht zwingend über eine konsistente Sicht auf den kommerziell und technisch zulässigen Variantenraum.

Ein Readiness Assessment prüft daher, ob das Portfolio entlang sinnvoller Produktfamilien strukturiert werden kann und welche Teile des Angebots wiederholbar sind. Es macht sichtbar, wo Varianten marktseitig wertvoll sind und wo interne Vielfalt lediglich aus historischen Sonderlösungen, regionalen Abweichungen oder uneinheitlicher Pflege entstanden ist. Diese Unterscheidung ist wesentlich. CPQ soll wertschöpfende Vielfalt beherrschbar machen, nicht jede vorhandene Ausnahme dauerhaft digital konservieren.

CPQ soll wertschöpfende Vielfalt beherrschbar machen – nicht jede historische Ausnahme dauerhaft digital konservieren.

Ebenso wichtig ist die Frage nach dem Scope. Soll zunächst eine Produktfamilie, ein Vertriebskanal, eine Region oder ein bestimmter Prozess adressiert werden? Ein zu breiter Einstieg erhöht Datenaufwand und Abstimmungsbedarf, bevor ein belastbares Modell entstanden ist. Ein zu enger Scope kann dagegen ein lokales Werkzeug erzeugen, das später nicht skalierbar ist. Readiness bedeutet deshalb auch, einen Startpunkt zu wählen, der fachlich repräsentativ und organisatorisch beherrschbar ist.

Produkt-Prozess-Klassen verhindern falsche Vereinheitlichung

Variantenreiche Industrieunternehmen behandeln ihr Geschäft häufig zu einheitlich. Standardprodukte, auswählbare Optionen, konfigurierbare Maschinen, kundenspezifische Anpassungen und echtes Engineering-to-Order werden in denselben Angebotsprozess gedrängt. Für die Systemgestaltung ist diese Vereinheitlichung problematisch, weil die zugrunde liegenden Aufgaben grundlegend verschieden sind.

Die Produkt-Prozess-Klassen von MTS bis ETO sind in Insight 002 als Ordnungsrahmen der Auswahl beschrieben. Für die Readiness zählt eine andere Frage: ob diese Klassen im eigenen Portfolio überhaupt erkennbar sind. Besondere Aufmerksamkeit verdient dabei CTO+, die Zwischenstufe zwischen reiner Konfiguration und freiem Engineering. Der Lösungsraum bleibt hier grundsätzlich vordefiniert, einzelne Parameter oder Baugruppen werden jedoch auftragsspezifisch ausgelegt. Diese Klasse wird in der Praxis selten sauber abgegrenzt und ist genau deshalb eine häufige Ursache überdehnter Regelwerke.

Gerade die Grenze zwischen CTO und ETO ist entscheidend. Ein Unternehmen kann nur dann sicher konfigurieren, wenn der zulässige Lösungsraum vorab beschrieben ist. Wo eine Kundenanforderung diesen Raum verlässt, muss sie kontrolliert in einen Engineering- oder Projektprozess übergeben werden. Fehlt diese Grenze, entstehen entweder überkomplexe Regelwerke oder gefährliche Scheinsicherheit. Die Software bestätigt dann eine Konfiguration, obwohl wesentliche technische Entscheidungen noch offen sind.

Produktstruktur und Datenmodell müssen tragfähig sein

CPQ arbeitet nicht auf abstrakten Funktionen, sondern auf Produktdaten. Merkmale, Werte, Regeln, Module, Beziehungen, Preise, Kosten, Texte, Dokumente und Stücklisten bilden gemeinsam das Produktmodell. Ein Readiness Assessment untersucht, ob diese Objekte eindeutig definiert sind und ob ihre Beziehungen nachvollziehbar beschrieben werden können.

Dabei genügt es nicht, dass Informationen irgendwo vorhanden sind. Entscheidend ist, ob sie konsistent, versionierbar und für den vorgesehenen Prozess nutzbar sind. Vertriebsmerkmale können anders strukturiert sein als technische Parameter, und die Sichten von Sales BOM, Engineering BOM und Manufacturing BOM folgen unterschiedlichen Zwecken. Für die Readiness zählt weniger die formale Vollständigkeit dieser Strukturen als die Frage, ob eine gültige Maximalstruktur existiert oder ob Stücklisten heute je Auftrag neu entstehen.

Readiness zeigt sich auch in der Fähigkeit, Datenverantwortung zu benennen. Wer pflegt Merkmale? Wer genehmigt Regeln? Wo entstehen technische Dokumente? Welches System führt Materialien, Preise, Kosten und Gültigkeiten? Wo dieselben Objekte mehrfach modelliert werden, entstehen Widersprüche und hoher Pflegeaufwand. Das Assessment muss nicht bereits jede spätere Schnittstelle im Detail beschreiben. Es muss aber erkennen lassen, ob ein belastbares Zielbild für Datenhoheit und Systemrollen entwickelt werden kann.

Guided Selling beginnt bei Kundenanforderungen

Guided Selling wird häufig als benutzerfreundliche Oberfläche verstanden. Tatsächlich beginnt es früher: bei der Frage, wie Kundenbedarf so beschrieben wird, dass daraus eine geeignete Produkt- oder Lösungsauswahl entstehen kann. Ein Readiness Assessment prüft deshalb, ob relevante Anwendungsbedingungen, Leistungsanforderungen und Entscheidungskriterien bekannt sind und ob sie in eine verständliche Dialoglogik übersetzt werden können.

Nicht jede technische Eigenschaft ist eine sinnvolle Kundenfrage. Ebenso wenig kann jede Kundenformulierung unmittelbar in ein Konfigurationsmerkmal überführt werden. Zwischen Marktbedarf und Produktlogik liegt eine Übersetzungsleistung. Sie verbindet Kundensprache, Vertriebswissen, Produktmanagement und Engineering. Fehlt diese Verbindung, entsteht entweder ein technisch überladener Dialog oder eine vereinfachte Oberfläche, die nur Standardfälle sicher abdeckt.

Zur Readiness gehört daher auch die Festlegung, wer den Prozess nutzt. Interne Vertriebsmitarbeiter, Händler, Serviceorganisationen und anonyme Webnutzer benötigen unterschiedliche Führung, Berechtigungen und Ergebnistiefen. Wie diese Führung im Einzelnen gestaltet wird, behandelt Insight 004. Für die Readiness genügt die Klärung, welche Entscheidungen der jeweilige Nutzer sicher treffen kann und an welcher Stelle zusätzliche Expertise erforderlich ist.

Pricing, Costing und Dokumente sind Teil des Modells

Technische Konfiguration allein erzeugt noch kein belastbares Angebot. Verkaufspreise, Herstellkosten, Zuschläge, Rabatte, Länderlogiken, Währungen und Konditionen folgen eigenen Regeln. Ein Readiness Assessment klärt, welche dieser Logiken bereits strukturiert vorliegt und welche heute auf der Erfahrung einzelner Personen beruht.

Pricing und Costing dürfen dabei nicht vermischt werden. Der Verkaufspreis kann marktorientiert, kundenbezogen oder vertragsabhängig sein. Herstellkosten ergeben sich aus Materialien, Arbeitsgängen, Standorten, Beschaffung, Losgrößen und Engineering-Aufwand. Gerade bei CTO+ und ETO müssen Unsicherheiten und projektspezifische Risiken berücksichtigt werden. Ein System kann Preise schnell berechnen und dennoch keine belastbare Aussage zur Marge liefern.

Auch Dokumente sind ein Readiness-Thema. Angebote, technische Spezifikationen, Datenblätter, Zeichnungen und Freigabeunterlagen benötigen kontrollierte Inhalte und klare Auslöser. Wenn Texte, Leistungsdaten und Ausschlüsse nur in individuellen Vorlagen oder persönlichen Dateien liegen, wird die Dokumentenerzeugung zum eigenen Transformationsprojekt. Dokumente sind Ergebnis des Produkt- und Prozessmodells, nicht kosmetischer Abschluss.

Integration folgt der fachlichen Rollenverteilung

Die Integrationsdiskussion beginnt häufig zu früh mit Schnittstellenlisten und technischen Protokollen. Zunächst muss geklärt werden, welches System welche Aufgabe übernimmt. CRM, PIM, PLM, CPQ, CAD und ERP besitzen unterschiedliche Rollen. Kein System sollte allein deshalb führend werden, weil es bereits vorhanden ist oder eine bestimmte Funktion ebenfalls anbietet.

Ein Readiness Assessment prüft, ob die fachliche Rollenverteilung grundsätzlich beschreibbar ist. Wo entsteht Produktlogik? Wo werden Preise gepflegt? Wo liegt die gültige Stückliste? Welches System erzeugt das vertriebliche Ergebnisobjekt, und welches übernimmt es in Auftrag, Konstruktion oder Fertigung? Erst aus diesen Antworten lassen sich sinnvolle Integrationen ableiten.

Besondere Aufmerksamkeit verdient die Vermeidung von Doppelmodellierung. Werden Merkmale und Regeln parallel in mehreren Systemen gepflegt, entstehen neben technischem Aufwand auch unterschiedliche Freigabezyklen, Verantwortlichkeiten und Interpretationen. Eine gewisse Redundanz kann erforderlich sein, muss aber bewusst gestaltet werden. Readiness liegt vor, wenn das Unternehmen die Konsequenzen seiner Architekturentscheidungen erkennen und verantworten kann.

Visualisierung und Automatisierung brauchen ein belastbares Fundament

Dreidimensionale Visualisierung, automatisierte Zeichnungen und Design Automation gehören zu den sichtbarsten Versprechen moderner CPQ-Lösungen. Für die Readiness-Betrachtung ist entscheidend, ob Geometrie, Parameter und Produktregeln ausreichend standardisiert sind. Wo CAD-Modelle nicht parametrisch aufgebaut, Schnittstellen nicht stabil oder Konstruktionsregeln nur personengebunden vorhanden sind, wird Automatisierung zum eigenständigen Entwicklungsprojekt.

Nicht jede Produktfamilie benötigt denselben Automatisierungsgrad. Für manche Aufgaben genügt eine regelbasierte Auswahl vorhandener Dokumente, in anderen Fällen ist die automatische Erzeugung auftragsspezifischer Geometrien wirtschaftlich sinnvoll. Readiness bedeutet, diese Fälle zu unterscheiden und den erwarteten Nutzen gegen Modellierungs-, Test- und Pflegeaufwand abzuwägen. Eine eindrucksvolle Demonstration ist noch kein Nachweis für einen nachhaltig betreibbaren Prozess.

Betriebsmodell und Releasefähigkeit bestimmen die Lebensdauer des Modells

Betriebsmodell und Sicherheit erscheinen zunächst als IT-Themen. Für die Readiness sind sie es nicht, denn sie entscheiden darüber, wie lange ein einmal aufgebautes Produktmodell tragfähig bleibt. SaaS, Private Cloud und On-Premises unterscheiden sich nicht nur im Betrieb, sondern in der Frage, wie tief ein Unternehmen in das Modell eingreifen darf, ohne die Aktualisierbarkeit der Plattform zu verlieren.

Genau hier liegt die kritische Abwägung. Jede Sonderentwicklung, die das Standardmodell umgeht, erhöht kurzfristig die Passgenauigkeit und senkt langfristig die Releasefähigkeit. Ein Produktmodell, das nur mit einem eingefrorenen Softwarestand funktioniert, verliert seinen Wert in dem Moment, in dem der Anbieter weiterentwickelt. Readiness bedeutet deshalb, die zulässige Eingriffstiefe vorab zu bestimmen, und zwar aus dem Produktmodell heraus, nicht aus einer allgemeinen IT-Präferenz.

Die Nutzungssituation konkretisiert diese Entscheidung. Eine interne Anwendung für wenige Vertriebsingenieure stellt andere Anforderungen als eine globale Plattform für Tochtergesellschaften, Händler und anonyme Webnutzer. Welche Produkt-, Preis- und Kostendaten das Unternehmen verlassen dürfen, ist keine nachgelagerte Sicherheitsfrage, sondern eine Vorgabe an die Architektur.

Governance entscheidet über den Betrieb nach dem Projekt

Viele CPQ-Initiativen konzentrieren sich auf Auswahl und Einführung. Der spätere Betrieb wird als nachgelagerte Aufgabe betrachtet. Tatsächlich beginnt die dauerhafte Arbeit erst mit der produktiven Nutzung. Produktmodelle verändern sich, neue Optionen entstehen, Preise werden angepasst, Länder kommen hinzu und Regelwerke müssen getestet werden. Ohne Governance verliert selbst ein technisch gutes System schnell an Verlässlichkeit.

Ein Readiness Assessment untersucht daher Rollen und Entscheidungswege. Fachliche Modellverantwortung, Datenpflege, Qualitätssicherung, Freigabe, Releaseplanung und Support müssen organisatorisch verankert werden. Die IT verantwortet Plattform, Sicherheit und Betrieb, kann aber die fachliche Produktlogik nicht dauerhaft allein tragen. Produktmanagement, Engineering, Vertrieb und Pricing müssen ihre jeweiligen Verantwortungen übernehmen.

Auch die verfügbare Kapazität ist realistisch zu betrachten. Werden Modelle ausschließlich neben dem Tagesgeschäft gepflegt, entstehen Verzögerungen und lokale Umgehungslösungen. Readiness bedeutet nicht, bereits eine große neue Organisation aufzubauen. Es bedeutet, die dauerhaften Aufgaben anzuerkennen und ein Betriebsmodell zu entwerfen, das zur Größe, Veränderungsdynamik und Internationalität des Unternehmens passt.

Neun Fragen zur ersten Selbsteinschätzung

Die folgenden Fragen ersetzen kein CPQ Readiness Assessment. Sie verdeutlichen jedoch schnell, in welchen der neun Handlungsfeldern bereits belastbare Antworten vorliegen und wo noch wesentliche fachliche Entscheidungen ausstehen. Wo eine Frage nicht klar beantwortet werden kann, liegt in der Regel kein Softwareproblem vor, sondern eine offene fachliche Entscheidung.

1. Portfolio und Scope: Können Sie benennen, welcher Anteil Ihres Angebots wiederholbar konfigurierbar ist und welcher projektspezifisch entsteht?
2. Produkt-Prozess-Klassen: Lässt sich Ihr Portfolio den Klassen zuordnen, und ist beschrieben, wo Konfiguration endet und Engineering beginnt?
3. Produktstruktur und Datenmodell: Existiert eine gültige Maximalstruktur, oder entstehen Stücklisten heute je Auftrag neu?
4. Guided Selling und Nutzerführung: Können Vertriebsmitarbeiter Kundenanforderungen ohne Rückfrage an die Technik in Produktmerkmale übersetzen?
5. Pricing, Costing und Dokumente: Ist der Angebotspreis regelbasiert nachvollziehbar, und kennen Sie zum Angebotszeitpunkt die Herstellkosten?
6. Systemrollen und Integration: Können Sie für Merkmale, Regeln, Preise und Stücklisten jeweils genau ein führendes System benennen?
7. Visualisierung und Automatisierung: Sind Ihre CAD-Modelle parametrisch aufgebaut und Konstruktionsregeln dokumentiert, oder liegen sie personengebunden vor?
8. Betriebsmodell und Sicherheit: Wissen Sie, welche Produkt-, Preis- und Kostendaten Ihr Unternehmen verlassen dürfen und welche Eingriffstiefe Sie sich leisten wollen?
9. Governance und Modellpflege: Ist benannt, wer nach dem Go-live das Produktmodell fachlich verantwortet, und mit welcher Kapazität?

Diese Fragen erzeugen keine Punktzahl. Ihr Wert liegt darin, dass die Antworten unmittelbar erkennen lassen, ob eine Dimension geklärt ist oder ob sie bisher lediglich als Annahme mitgeführt wurde.

Vom Assessment zur belastbaren Roadmap

Aus den Befunden muss eine umsetzbare Reihenfolge entstehen. Nicht jede Lücke ist vor Projektbeginn vollständig zu schließen. Einige Themen sind jedoch voraussetzungskritisch: ein klarer Scope, belastbare Produkt-Prozess-Klassen, eindeutige Kernobjekte und eine verantwortbare Zielarchitektur. Andere Aspekte können bewusst im Pilot vertieft werden, sofern ihre Risiken transparent sind.

Eine belastbare Roadmap verbindet fachliche Vorarbeiten, Datenaufbereitung, Systemauswahl, Proof of Concept, Pilot und Roll-out. Sie berücksichtigt Abhängigkeiten zwischen Produktmodell, Integration und Organisation und verhindert, dass technische Arbeit beginnt, bevor fachliche Entscheidungen getroffen wurden. Damit wird Readiness nicht zum Verzögerungsargument, sondern zum Mittel, unnötige Schleifen zu vermeiden.

Der Maßstab ist nicht maximale Vorbereitung. Der Maßstab ist ausreichende Klarheit für die nächste irreversible Entscheidung. Genau dadurch bleibt das Vorhaben handlungsfähig, ohne wesentliche Risiken in die Implementierung zu verschieben.

Der richtige Ausgangspunkt für Auswahl und Pilotierung

Das Ergebnis eines CPQ Readiness Assessments ist ein differenziertes Bild aus belastbaren Grundlagen, kritischen Lücken, Abhängigkeiten und Prioritäten. Daraus entsteht die Entscheidung, welche Vorarbeiten vor der Softwareauswahl erforderlich sind und welche Themen bewusst in einen Proof of Concept oder Pilot überführt werden können.

Ein Proof of Concept ist dann sinnvoll, wenn architekturkritische Fragen mit realen Daten nachgewiesen werden sollen: mehrstufige Produktstrukturen, komplexe Regelbeziehungen, regionale Varianten, Pricing- oder Costing-Logik, Dokumente und Übergaben an andere Systeme. Wie Longlist, Shortlist und Proof of Concept methodisch aufgebaut werden, beschreibt Insight 002. Die Readiness liefert dafür die Voraussetzung: ein Zielbild, an dem Anbieter überhaupt gemessen werden können.

Readiness schafft Entscheidungsfähigkeit

Ein CPQ Readiness Assessment soll keine zusätzliche Analysephase ohne Konsequenz erzeugen. Sein Wert liegt in der Entscheidungsfähigkeit. Es zeigt, ob das Unternehmen bereits sinnvoll auswählen kann, ob zunächst Produkt- und Datenarbeit erforderlich ist oder ob der geplante Scope angepasst werden muss. Ebenso kann es zu dem Ergebnis führen, dass kein neues CPQ-System benötigt wird, sondern bestehende Strukturen, Rollen oder Werkzeuge besser genutzt werden sollten.

Die wichtigste Erkenntnis lautet: CPQ-Erfolg entsteht nicht durch die Einführung eines Konfigurators. Er entsteht aus dem Zusammenspiel von Portfolio, Produktarchitektur, Prozessklassen, Produktstruktur, Datenmodell, Pricing, Dokumenten, Systemrollen und Governance. Software macht dieses Zusammenspiel ausführbar. Sie schafft es nicht von selbst.

Unternehmen, die ihre Readiness früh prüfen, verschieben die zentrale Arbeit nicht nach hinten. Sie schaffen vor der Auswahl Klarheit über Aufgabe, Grenzen und Zielarchitektur. Dadurch werden Ausschreibungen präziser, Proofs of Concept aussagekräftiger und Einführungen beherrschbarer. Vor allem aber verhindert die Vorbereitung, dass ein technisch leistungsfähiges System auf eine Produktlogik trifft, die noch nicht entschieden ist.

Während Insight 001 die Systemtypen einordnet und Insight 002 das Auswahlvorgehen beschreibt, klärt dieser Beitrag die Voraussetzungen. Damit schließt Insight 003 die Vorbereitung auf eine belastbare Systementscheidung ab. Insight 004 zeigt anschließend, wie diese fachlichen Grundlagen im Guided Selling in einen strukturierten Vertriebsdialog überführt werden.

© Dr. Wüpping Consulting GmbH