FTQ: Fachliche und technische Qualifizierung

Die fachliche und technische Qualifizierung (FTQ) klärt zwei Fragen, bevor du Ressourcen in einen Deal (Verkaufsprojekt) steckst. Bedient die Lösung die Geschäftsanforderung? Und lässt sie sich in der technischen Umgebung des Interessenten umsetzen? Ein Feature (Produktfunktion), das fachlich passt, aber technisch nicht machbar ist, hat keinen Wert. Umgekehrt gilt das genauso.

In der FTQ treffen beide Blickwinkel aufeinander. Aus Discovery-Notizen wird so eine dokumentierte, bewertete Entscheidung über die Opportunity (Verkaufschance).

So läuft die FTQ ab

(öffnet in neuem Tab)

Drei Inputs, zwei Fits, eine Entscheidung. Die Scores machen aus Notizen eine Entscheidung.

Drei Inputs fließen ein: das OSD, das BANT (öffnet in neuem Tab)-Ergebnis aus der Sales Discovery (Bedarfsklärung) und das Ergebnis aus dem ORC. Du bewertest sie in zwei Blöcken, fachlicher Fit und technischer Fit. Jedes Kriterium bekommt einen Wert von 1 bis 5. Die kritischen Kriterien zählen stärker.

Dann entscheidest du. Investieren heißt: Beide Fits passen. Geh in Demo, Angebot und Roadmap. Bedingt heißt: Der Deal sieht gut aus, hat aber benannte Lücken. Schließ sie zuerst, jede mit Owner und Termin. Pausieren heißt: Ein Fit fällt durch. Steig freundlich aus und gib die Stunden einem Deal, den du gewinnen kannst.

Die Abschnitte unten gehen jeden Schritt einzeln durch.

Das OSD nutzen

Das Opportunity Scoping Document (OSD) (öffnet in neuem Tab) ist der Input für die FTQ, nicht ihre zweite Fassung. Die FTQ liest das OSD und bewertet es.

Auf der funktionalen Seite ziehst du die beschriebenen Herausforderungen und die größten Pain Points (konkrete Probleme) heraus. Zu jedem brauchst du die Auswirkungen und die Ursachen. Dazu kommen die gewünschten Ergebnisse und die Vision. Die Lösung muss beides bedienen: die heutigen Probleme und die Ambitionen.

Auf der technischen Seite ziehst du den IT-Überblick und die Architektur heraus. Daraus siehst du, welche Systeme im Spiel sind, wie sie zusammenhängen und wo Legacy-Grenzen liegen. Genauso wichtig ist der Abschnitt zu Annahmen und Lücken. Er markiert, was vor einer Zusage noch geprüft werden muss.

Die Abschnitte zu Projektpriorisierung und Business Release geben dir die Reihenfolge des Rollouts. Diese Reihenfolge bestimmt, welche Features wann kommen und wann die Infrastruktur dafür bereit sein muss.

Wie das OSD als Filter wirkt, steht im Kapitel zur Qualifizierung (öffnet in neuem Tab). Hier geht es um das Framework, das darauf aufsetzt.

Die wichtigsten Bausteine

Ein FTQ-Framework hat fünf Teile. Bau sie in dieser Reihenfolge.

Ziel und Umfang: Schreib auf, was die FTQ entscheidet. Leg dann fest, welche Teile des Geschäfts und der technischen Umgebung du bewertest.

Bewertungskriterien: Funktionale Kriterien umfassen Features, Prozessänderungen und den Nutzen, den die Lösung liefern muss. Technische Kriterien umfassen Integrationsfähigkeit, Skalierbarkeit, Nachhaltigkeit und bekannte Einschränkungen.

Ein Scoring-System: Nutze eine einfache Skala, etwa 1 bis 5. Oder gewichte die Kriterien, damit die kritischen den Gesamtscore stärker prägen. Dokumentiere jeden Score, damit die Entscheidung transparent bleibt.

Ein Bewertungsprozess: Definiere die Schritte. Erhebe die Ausgangsdaten, führe Interviews mit Stakeholdern (Beteiligten), prüfe die technische Dokumentation und bewerte dann gegen die Kriterien. Zieh Sales, Presales, Produktmanagement und Entwicklung dazu.

Ein Einführungsplan: Schul das Team und pilotiere das Framework an einigen Deals. Verfeinere es dann mit dem Feedback. Mach es zum festen Schritt im Sales-Prozess und miss, ob es wirkt. Brauchbare Kennzahlen sind die Erfolgsquote qualifizierter Opportunities, die Kundenzufriedenheit und die gesparte Zeit.

Die bewerteten Abschnitte decken meist ab:

• die Zusammenfassung aus dem BANT und aus dem ORC
• strategische Passung und Unternehmensinformationen
• technische Anforderungen und Kompatibilität
• Workflow- und Prozessanalyse
• Pain Points und Bedürfnisse
• den Entscheidungsprozess
• Wettbewerb und Differenzierung
• Recht und Compliance
• Implementierung und Adoption
• Nutzen und ROI (öffnet in neuem Tab) (Rendite einer Investition)
• künftiges Wachstum und Skalierbarkeit
• kulturelle und organisatorische Passung
• lösungsspezifische Fragen wie Volumina und Module

Opportunity Review Call (ORC)

Im ORC kommt das Urteil der anderen Abteilungen in die FTQ. Das Ergebnis wird einer der bewerteten Abschnitte: Deal-Wert, Beleg, Nutzen, Gewichtung und Score.

Halte den ORC wöchentlich ab, damit die Opportunities im Blick bleiben. Nicht jeder Deal braucht einen Slot. Bring die Deals, bei denen der fachliche oder technische Fit offen ist. Bring auch die, die 90 % der Anforderungen erfüllen. Für die fehlenden 10 % brauchst du Zusagen anderer Abteilungen.

Trage vor dem Call alle wichtigen Opportunities zusammen. Lass Teammitglieder beim Moderationsteam einen Slot anfragen. Teile ein ausgefülltes OSD vorab, dazu eine kurze Übersicht, was besprochen wird und wer dabei sein muss.

Der Call folgt einer festen Ordnung. Geh die Action Items der letzten Session durch. Kläre die offenen Punkte. Besprich dann zwei bis drei Opportunities im Detail. Ein Solution Consultant (öffnet in neuem Tab) stellt jede anhand des OSD vor, mit Zusammenfassung, zentralen Themen und Lösungsvorschlag.

Ein benannter Moderator führt durch die Diskussion. Er hält sie auf Kurs, macht Notizen und erfasst die Action Items. Jede Opportunity verlässt den Call mit klaren Maßnahmen, einer verantwortlichen Person pro Maßnahme und einem Zeitplan.

Versende danach die Notizen mit allen Maßnahmen und Verantwortlichen. Setze Deadlines und hake vor dem nächsten Call nach. Ohne dieses Nachhalten wird der ORC ein Gesprächskreis statt ein Qualifizierungs-Gate.

Die Presales-Perspektive

Die FTQ ist eine erste Skizze. Eine Opportunity, die sie besteht, verdient deinen weiteren Aufwand.

Als Nächstes kommt die Demo-Vorbereitung. Jede Folie, jeder Klick und jedes Beispiel sollte die Umgebung des Interessenten spiegeln. Zeig, warum jede Funktion für diesen Kunden zählt. Führ die Demo als Workshop. Frag, hör zu und räum Bedenken sofort aus.

Danach bündelt das Proposal alles. Es verbindet die technische Spezifikation, die Integration in die bestehenden Systeme, mögliche Customizations und die Herausforderungen, die du schon siehst. Dazu gehört die Ressourcenschätzung: Zeit, Personal und Hardware, ehrlich benannt. Eine Implementierungs-Roadmap mit Meilensteinen, Zeitplänen und Deliverables hält beide Seiten im Gleichschritt.

Ein Proof of Concept (öffnet in neuem Tab) ist nicht immer nötig. Wo Zweifel bleiben, gibt er dem Interessenten einen Vorgeschmack und klärt die Frage. Danach folgt vielleicht ein RFX (öffnet in neuem Tab)-Prozess und dann die Verhandlung. Behandle die Verhandlung als Zusammenarbeit über den Punkt, an dem Nutzen und Investition zusammenpassen.

Wer die FTQ überspringt, zahlt später. Manche Teams stecken Discovery, Demos und Lösungsarbeit in unqualifizierte Deals. Am Ende bauen sie Dinge, die sie nicht liefern können.

Die wichtigsten Punkte

Zwei Fragen, ein Gate: Die FTQ fragt, ob die Lösung zur Geschäftsanforderung passt und ob sie umsetzbar ist. Beides muss bestehen.

Bewerten: Ein dokumentiertes Scoring macht die Entscheidung objektiv und wiederholbar. Begeisterung im Sales zählt nicht als Score.

Der ORC füttert die FTQ: Der Input der anderen Abteilungen wird ein bewerteter Abschnitt der FTQ.

Qualifizierung ist der Anfang: Nach der FTQ kommen Demo, Proposal, Ressourcenschätzung, Roadmap und Abschluss.