Funktionale & technische Discovery

In der Discovery-Phase decken Presales und Sales die Pain Points (konkrete Probleme) des Kunden auf. Dazu gehören auch seine Geschäftsziele, seine Organisationsstruktur und seine Wert-Hypothese. Dafür führen sie gründliche Discovery-Sessions und Meetings mit dem Kunden. Ziel ist, seine Bedürfnisse genau zu verstehen. Dann seht ihr, wie euer Produkt oder Service sie erfüllt.

Ziele der Phase

Finde heraus, wie du gewinnst, und entwickle einen "Coach". Deck die Pain Points, Geschäftsziele und Organisationsstruktur des Kunden auf. Damit rahmst du das Wertversprechen der Lösung.

Best Practices

• Den Hintergrund verstehen: Versteh zuerst das Geschäft des Interessenten, seine Position in der Branche und seine Geschäftsziele. Nutze das BANT-Formular und besprich das erste Meeting mit dem Interessenten.
• Die technische Umgebung erkunden: Schau dir die aktuelle technische Infrastruktur des Interessenten an. Dazu gehören bestehende Lösungen, Tech Stack (eingesetzte Software) und Pläne für die Zukunft. So verstehst du, wie deine Lösung bestehende Systeme integriert oder ersetzt. Nutze einen strukturierten Fragebogen oder das OSD, um zu verstehen, was gebraucht wird.
• Die wichtigsten Pain Points finden: Finde die großen Herausforderungen, die der Interessent mit seinem aktuellen Setup hat. Schau auf die Haupt-Pain-Points und auf verwandte Nebenprobleme, die deine Lösung lösen könnte. Nutze einen strukturierten Fragebogen oder das OSD, um zu verstehen, was gebraucht wird.
• Die Auswirkung beziffern: Hilf dem Interessenten, die Folgen seiner Pain Points in Kosten, Produktivität und operativer Effizienz zu beziffern. Mit diesen Zahlen begründest du deine Lösung.
• Den Lösungs-Fit herstellen: Sprich über konkrete Fähigkeiten deiner Lösung, die zu den Bedürfnissen des Interessenten passen. So verknüpfst du das Discovery-Gespräch mit Ergebnissen und Vorteilen, die dem Interessenten wichtig sind.
• Das erweiterte Umfeld bewerten: Geh über den unmittelbaren Bedarf hinaus. Erkunde angrenzende und betroffene Bereiche im Unternehmen des Interessenten, die von deiner Lösung profitieren könnten. So findest du weitere Chancen für dein Angebot.
• Vision Reengineering: Ermutige den Interessenten, sich einen künftigen Zustand mit deiner Lösung vorzustellen. Sprich über die Wirkung auf seine Workflows. Zeig, wie er seine Geschäftsprozesse für bessere Ergebnisse neu gestalten kann.
• Implementierung und Adoption besprechen: Sprich über den Implementierungsprozess, erwartete Herausforderungen und darüber, wie dein Team den Übergang begleitet. Besprich auch, wie die Organisation die Lösung annimmt. So wird sie nach dem Go-live wirklich genutzt.
• Einen Mutual Action Plan erstellen: Entwickle einen Plan mit den nächsten Schritten, die beide Seiten nach der Discovery-Session gehen. Er enthält Zeitpläne, wichtige Meilensteine und Verantwortlichkeiten. So bleibt der Schwung bis zur Entscheidung erhalten.
• Erkenntnisse dokumentieren und teilen: Fass die Ergebnisse der Discovery (Bedarfsklärung) zusammen und teile sie mit deinem Interessenten. So bestätigt ihr gemeinsam das Verständnis und seid abgestimmt. Dieses Dokument ist die Basis für alle weiteren Schritte. So arbeiten beide Seiten mit demselben Stand. Mehr darüber, wie Discovery funktioniert (öffnet in neuem Tab)
• Details gründlich dokumentieren: Halte alle technischen Details, Systemanforderungen und Gespräche sorgfältig im OSD fest.
• Auf Geschäftsergebnisse fokussieren: Verknüpf deine technische Discovery mit Geschäftsergebnissen, die dem Interessenten wichtig sind. Versteh, welche Key Performance Indicators (KPIs) für ihn zählen. Kläre auch, wie deine Lösung diese Kennzahlen verbessert.
• Use Cases und Szenarien: Bitte den Interessenten um konkrete Use Cases (Anwendungsfälle) oder Szenarien. Wo reichen seine aktuellen Systeme nicht? So richtest du deine Präsentation auf reale Situationen aus, die dem Interessenten wichtig sind.
• Stakeholder Mapping: Finde alle wichtigen Stakeholder (Beteiligte) im Kaufprozess. Versteh ihre Rollen, ihren Einfluss und ihre eigenen Pain Points. So passt du Gespräche und Demos an die Anliegen jedes Stakeholders an.

Qualifizierungskriterien

Qualify In (Nächste Phase: Teach/Prove) (öffnet in neuem Tab)

• Discovery-Meetings sind abgeschlossen und die nächsten Schritte geplant.
• Klares Bild der Pain Points des Kunden und davon, wie wir Wert und ROI (Rendite einer Investition) liefern
• Organigramm und Power-Base-Chart sind erstellt, der Entscheider ist bekannt.
• Der Evaluierungsplan ist bestätigt, mündlich oder schriftlich.

Qualify Out (Eventuell in Long-Term Development verschieben) (öffnet in neuem Tab)

• Der Interessent will keine Discovery-Meetings oder liefert nötige Informationen nicht.
• Keine Beziehung zum Management und kein klarer Coach
• Kein klares Verständnis der Pain Points, Ziele und des Entscheidungsprozesses des Kunden

Functional & Technical Qualification Framework

Grundlagen

FTQ Framework (öffnet in neuem Tab)

Kurs Functional Technical Qualification (FTQ)

(öffnet in neuem Tab)

Vorlage Functional Technical Qualification herunterladen

FTQ-Vorlage (öffnet in neuem Tab)

Do's and Don'ts

Do

• Stell in der Discovery offene Fragen, sammle Informationen zur Organisationsstruktur und bestätige den Evaluierungsplan.

Don't

• Die Discovery überspringen, Annahmen über die Bedürfnisse des Interessenten treffen oder wichtige Stakeholder nicht einbinden.
• Demos zeigen, ohne den Pain zu kennen.

Verantwortlichkeiten und Aufgaben

Sales (ASD/SD)

• Informiere den Solution Consultant über die neue Opportunity (Verkaufschance)
• Aktualisiere das OSD mit dem Situation Sheet (Critical Business Issues, Problems & Reasons, Capabilities, Delta und Value Realization Event). Teile Erkenntnisse und Informationen über den Interessenten. So versteht das Presales-Team seine Bedürfnisse und Erwartungen besser.
• Führe Discovery-Meetings durch, bind wichtige Stakeholder ein und entwickle ein genaues Verständnis der Bedürfnisse des Interessenten.
• Erstelle ein Organigramm (versteh, wer Champion, Entscheider, Coach, Störer usw. ist)
• Bind den AVP Sales früh ein, um eine Beziehung aufzubauen
• Festige den Coach und befähige ihn, unsere Lösung intern zu verkaufen
• Führe Discovery-Meetings durch, um Pain Points und Geschäftsziele des Kunden zu verstehen.
• Nutze wirksame Fragetechniken (z. B. das SPIN-Framework), um die Bedürfnisse des Kunden zu verstehen.
• Arbeite mit Presales und Product Management zusammen, um passgenaue Lösungen für den Kunden zu entwickeln.
• Erstelle eine Schätzung / einen groben Preisrahmen,

Presales (SC)

• Versteh die funktionale und technische Umgebung und die Anforderungen des Kunden, um relevante Erkenntnisse zu liefern.
• Qualifiziere, ob und wie du den Deal (Verkaufsprojekt) gewinnst.
• Halte dein Wissen über das Produktportfolio und seine Anwendungen aktuell.
• Arbeite eng mit Sales zusammen, um angepasste Produktdemos zu erstellen, die den Wert der Lösung zeigen.
• Führe die Look & Feel Demo durch
• Aktualisiere das OSD mit dem Situation Sheet (Critical Business Issues, Problems & Reasons, Capabilities, Delta und Value Realization Event)
• Stell die Opportunity bei Lücken PS/PM vor (Opportunity Review Call (ORC)

Professional Service (PS)

• Liefere Einblicke zu Implementierung, Integration und Anpassungsmöglichkeiten.
• Versteh das Projekt
• Arbeite mit Sales und Presales zusammen, um die Anforderungen des Kunden zu verstehen und die Implementierung zu planen.
• Nutze Erkenntnisse aus den Discovery-Meetings für einen detaillierten Projektplan zur Umsetzung der Lösung.
• Unterstütze Sales und Presales bei Kundenbedenken zu Implementierung und Service-Erbringung.

Product Management (PM)

• Arbeite mit Presales zusammen, um den Produkt-Fit sicherzustellen
• Qualifizierung (ORC)
• Nutze Feedback von Sales und Presales, um das Produktangebot zu schärfen und Kundenbedürfnisse zu erfüllen.
• Arbeite mit Sales und Presales an passgenauen Lösungen, die zu den Zielen des Kunden passen.
• Unterstütze die Discovery mit produktspezifischem Wissen und Expertise.

Cheatsheet: Functional & Technical Discovery

(öffnet in neuem Tab)

Zusätzliche Materialien

Informationen

Discovery-Grundlagen (öffnet in neuem Tab)

Discovery Guidebook

Guidebook (öffnet in neuem Tab)

FTD-Vorlage

FTD-Vorlage (öffnet in neuem Tab)

FTQ-Vorlage (Download)

FTQ-Vorlage (öffnet in neuem Tab)

Functional & Technical Discovery

(öffnet in neuem Tab)

Best Practices für Functional & Technical Discovery

(öffnet in neuem Tab)

Die Discovery-Zusammenfassung / Opportunity Scoping Document (OSD)

(öffnet in neuem Tab)

Vorlage Functional Technical Discovery

Situation Sheet (intern)

Teilnehmer (Name und Rolle)

"Bevor wir anfangen: Wie bist du bei [Kundenname] in diese einflussreiche Position gekommen?"

Demografie

Erzähl mir von deinem Team. Wie viele Leute sind es? Wo sitzen sie? Wie lange arbeiten sie schon bei [XX]? Wie ist das Unternehmen organisiert? Welche Standorte gibt es? Wie sieht die Geschichte kurz aus?

Zusammenfassung der Sales Discovery

"[Herr oder Frau Kunde], mein Kollege Mike hat mir schon etwas Hintergrund zum Projekt gegeben. Ich verstehe, dass ihr XYZ erreichen wollt. Ich präsentiere euch unsere Lösung vor Ort. Deshalb möchte ich mir ein paar Minuten nehmen und noch einige Fragen stellen. So stelle ich sicher, dass ich technisch genau verstehe, was ihr sucht. Dann nutzen wir eure Zeit bei der Demo vor Ort bestmöglich. Ist das für euch ein guter Ansatz?"

"Mike hat mir erzählt, dass ihr XYZ vorhabt. Kannst du mir in deinen eigenen Worten einen Überblick über das Projekt in 30 oder 60 Sekunden geben? Nur damit wir auf demselben Stand sind."

Workflows

Wie viele verschiedene Workflows habt ihr? Wo laufen sie? Sind die einzelnen Teile verteilt oder an einem Standort? Sind die Workflows physisch (z. B. rein auf Papier), voll digital oder hybrid? Wie lange gibt es diese Workflows schon? Wie viele Personen sind beteiligt? Frag nach der Erfahrung und dem Hintergrund dieses Teams. Sind die Leute erfahren in ihrem Handwerk oder ungelernt? Wer (oder was) sind die Kunden dieser Workflows, und was sind die Inputs?

Lösungslandschaft

(ERP-Systeme, WMS, GTM) Wie sieht die aktuelle Software-Infrastruktur deines Interessenten aus, also sein "Tech Stack"? Und was plant er für die Zukunft? Hat die Organisation schon Erfahrung mit anderen Werkzeugen oder Lösungen wie unserer? Falls ja, wie lief es? Falls es gescheitert ist, warum?

Situation Sheet (extern)

(öffnet in neuem Tab)

Critical Business Issue

Halte die größte Herausforderung der Person fest. Oft ist das ein Quartals-, Jahres- oder Projektziel, das in Gefahr ist.

Problems / Reasons

Halte fest, warum es für die Person heute ein Problem ist. Warum ist das Ziel schwer zu erreichen? Und wie arbeitet die Person heute?

Specific Capabilities

Beschreib die Fähigkeiten, die der Interessent zur Lösung seines Problems braucht, aus seiner Sicht.

Delta

Nutze die Zahlen des Interessenten und ermittle den Wert der Veränderung gegenüber der heutigen Arbeitsweise.

Critical Date / Value Realization Event (V.R.E.)

Bestimme ein Datum, bis zu dem der Interessent eine Lösung braucht (und warum). Finde das Ereignis, das den ersten Erfolg mit deiner Lösung zeigt. Das kann eine manuelle Aufgabe sein, die jetzt automatisiert ist, oder ein Report, den es vorher nicht gab.

Volumen, Kultur, Prozess

Volumen und Kennzahlen

(Anzahl Produkte, Partner, BOM, Komplexität, Standorte, Produktionsstätten, wichtigste Länder im Scope)

Kultur

"Gibt es etwas, das euch als Unternehmen einzigartig macht? Woran merkt ihr, dass die neue Software ein Erfolg ist? Wollen wir ein paar kleine 'Wins' durchgehen, die dafür stehen könnten? Was wäre für euch ein früher Erfolg, sobald ihr mit den neuen Listen und Services arbeitet? Wird das Problem schlimmer? Wie hat es sich in den letzten XX [Tagen, Wochen, Monaten usw.] verändert?"

Prozess, Zeitpläne, Budget usw.

"Was passiert, wenn ihr nichts tut? Wie lange ist 'eine Weile'? Warum könnt ihr so weitermachen wie bisher? Was braucht es für die Veränderung, was muss passieren? Steht ihr noch am Anfang eurer Suche nach XX, oder sucht ihr schon aktiv eine Lösung? Gibt es ein Datum, bis zu dem ihr eine Lösung braucht?"

Dann fragst du: "Und was treibt diesen Bedarf?"

Ein Critical Date oder Critical Event ist ein Datum, bis zu dem der Interessent eine Lösung braucht. Dazu gehört eine Erklärung, warum das Datum wichtig ist.

"Was hat euch dazu gebracht, uns anzusprechen? Wir sprechen jetzt schon eine Weile über eure Situation, und ich glaube, ich verstehe sie ganz gut. Aber sag mal: Warum habt ihr euch überhaupt bei mir gemeldet? Gibt es konkrete Ziele, die ihr erreichen müsst oder die in Gefahr sind? Welche Kennzahlen gibt es heute?"

Demo-Meeting

Teilnehmer, Rollen und Ort des Meetings

Wer nimmt teil? Welche Rollen haben die Teilnehmer? Sind es Anwender, technische Verantwortliche, Management, Entscheider usw.? Wie sieht die Logistik des Meetings aus? Ist die Umgebung abgesichert? Habe ich Internetzugang? Treffen wir uns in einem Konferenzraum oder in einem Büro?

Nach der Discovery

Haben wir eine Lösung für ihre Probleme? Verstehen wir das Kernproblem, und was ist es?

Die Lösung im Scope und die wichtigsten Punkte

Lücken