Der Masterplan

Mit dem agilen Vorgehen und einem guten Feedback-Mechanismus stehen gute Werkzeuge zur Verfügung, um auch eine Schwerpunktverlagerung zügig umzusetzen, wenn die bisherige Strategie nicht die gewünschten Erfolge bringt. Der Business Developer sollte einen Masterplan im Hinterkopf haben, den alle Parteien kennen. Dieser Masterplan enthält sowohl eine inhaltliche Festlegung in Form eine Roadmap als auch einen Arbeitsmodus und Synchronisationspunkte. Die Kunst bei der Planung eines neuen Produkts liegt in der Synchronisation der Arbeitsergebnisse. Bei jedem Iterationsschritt muss allen Beteiligten das Teilziel für die Iteration klar sein. Wer in kurzen Iterationen, zusammen mit allen zuliefernden Abteilungen und Dienstleistern, nutzbare Ergebnisse liefert, kann bereits nach kurzer Zeit wertvolles Feedback bekommen. Mit den Iterationen verkürzt man die Time-to-Feedback, also den Zeitraum bis zum ersten Feedback.

Ähnlich wie in Entwicklerteams für agile Softwareentwicklung strukturiert ein guter Business Developer die Realisierung in Sprints oder Iterationen (Time-Box). Der Business Developer verpflichtet alle beteiligten Parteien, diese Time-Boxen einzuhalten. Nur so kann es gelingen, aus mehreren voneinander abhängigen Teilzulieferungen ein nutzbares Teilergebnis zu erhalten. Viele Dienstleister und auch interne Beteiligte müssen das Arbeiten in diesem Vorgehen gegebenenfalls erst erlernen. Dann sollten sie durch Coaches unterstützt werden, die diesen agilen Ansatz vermitteln können.

Lean Management stellt die Kundenbedürfnisse ins Zentrum jeglichen Handelns. Im Lean Business Development ist das Kundenbedürfnis ein bewegliches Ziel, und der Feedback-Kanal ist das Zielfernrohr, um die Trefferwahrscheinlichkeit zu erhöhen. Die hier vorgestellte Methode soll dafür sorgen, schnell an Feedback des Kunden zu kommen. Dieser Aspekt hat bereits bei der organisatorischen Aufstellung eine wichtige Rolle gespielt - auch in den Prozessen ist er an vorderster Stelle. Im Business Development ist die erste Idee für eine Maßnahme, die ein strategisches Ziel verwirklichen soll, nicht immer die ökonomisch wertvollste. Und doch gibt es Unternehmen, die es gut verstehen, diese erste Idee zu einem erfolgreichen Produkt zu entwickeln.

Positives Beispiel eines digitalen Geschäftsmodells

Am Beispiel von Uber kann man sehr gut erkennen, wie ein digitales Geschäftsmodell konstruiert ist. Es sind typische Geschäftsmodell-Muster, wie sie auch Oliver Grassmann, Karolin Frankenberger und Michaela Csik 2013 in ihrem Buch "Geschäftsmodelle entwickeln - 55 innovative Konzepte mit dem St. Galler Business Model Navigator" beschrieben haben:

• Franchising: Uber setzt mit seinen Fahrern auf selbstständige Unternehmer, die in die Limousinen investieren und sie zur Wertschöpfung einsetzen. Uber versorgt die Franchisenehmer mit Kunden und übernimmt das Marketing. Die Franchisenehmer profitieren von der Marke.

• Layer Player: Ein großer Teil der Leistungserbringung im Geschäftsmodell von Uber findet gar nicht bei Uber statt. Aber als Vermittler zwischen Kunden mit Beförderungsbedürfnis und den Fahrern hat Uber intelligente Algorithmen entwickelt, die eine optimale Vermittlung für große Auslastung und kurze Anfahrtswege ermöglichen sollen. Uber konzentriert sich dabei nur auf die Vermittlung, die Festlegung des Preises und die Abrechnung von Kunden und Fahrern.

• Digitalization: Hier nutzt Uber das volle Spektrum. Sowohl Fahrer als auch Anforderer können durch Smartphone-Apps mit ihren Geolocations erfasst werden. Die Prozesse zur Zusammenführung von Kunde und Fahrer finden vollautomatisiert statt. Auch hohe Anfrageaufkommen werden schnell identifiziert, die Einsatzplanung ist effizient.

• Auction: Angebot und Nachfrage bestimmen den Preis. Je mehr Nachfrage an einem Ort in Relation zu den verfügbaren Limousinen existiert, desto höher ist der Fahrtpreis.

• Leverage Customer Data: Die Daten aus den Anfragen der Kunden kann Uber auf vielfältige Weise auswerten. So kennt Uber die Destination eines Kunden aufgrund seines Verhaltens und kann beispielweise Hotels in der Nähe eines Geschäftstermins anbieten. Über ein Provisionsmodell partizipiert Uber an diesen Vermittlungen.

An dem neuen Produkt UberPool wird ein wertvolles Prinzip deutlich, das in erfolgreichen Innovationen zum Tragen kommen kann: die Empirie. Mit UberPool konnte Uber in einem regional begrenzten Gebiet versuchsweise Fahrgemeinschaften vermitteln. Es gibt unzählige Beispiele, in denen solche Experimente auch zu Misserfolgen führten. Doch kein Unternehmen kann es sich leisten, die Produkt-, Prozess- oder Dienstinnovationen dem Zufall zu überlassen. Ein effektives Business Development benutzt deshalb einen strukturierten Prozess, der eine gezielte Auswertung einer Idee zulässt.

Experimentieren erlaubt

Ein solch strukturierter Prozess, der auch der Komplexität Rechnung tragen kann, ist der empirische Prozess.

Im Mittelpunkt des empirischen Vorgehens steht das Experiment, mit dem zuvor aufgestellte Hypothesen geprüft werden (sh. Abb. 3). Anschließend an das Experiment vergleicht man die Erwartungswerte mit den tatsächlichen Ergebnissen aus dem Experiment - die Hypothesen werden so verifiziert oder falsifiziert. Aus dem Gesamtergebnis lässt sich eine Lehre ziehen, und Hypothesen werden gegebenenfalls neu aufgestellt oder angepasst - um dann ein neues Experiment durchzuführen.

Einen Weg, um schnell in die Phase des Experimentierens zu kommen, eröffnet das Minimal Viable Product (MVP). Die Erstellung des MVP fällt vielen Business Developern oder Produktmanagern schwer. Denn das MVP enthält nur die Kernelemente des künftigen Produkts und verzichtet auf alle weiteren Features. Ein gutes MVP liegt dann vor, wenn die Entfernung eines beliebigen weiteren Features dazu führen würde, dass das Produkt keinen sinnvollen Nutzen mehr liefert.

Wurde im Entwicklungs- oder Veränderungsprozess ein MVP realisiert, können das Produkt, die Dienstleistung oder die Prozessveränderung zum ersten Mal getestet werden - und der Feedbackprozess lässt sich in Gang setzen (siehe Abb. 2).

Der empirische Prozess bildet also den Rahmen für die schrittweise Produktentwicklung. Der wesentliche Zweck dieses Prozesses ist es, Hypothesen zu validieren. Hinter allen Veränderungsideen stehen immer implizite oder explizite Hypothesen. Die expliziten Hypothesen sind schnell dokumentiert. Die impliziten Hypothesen können unter Nutzung des Business Plans aus den Annahmen und Prognosen abgeleitet werden (sh. Abb. 4). Hier sollte man besondere Sorgfalt walten lassen, denn alle implizit angenommenen Hypothesen können später - als blinder Fleck im Sichtfeld des Business Developers - eine Eigendynamik entwickeln, die dem Geschäftsmodell schadet, aber trotzdem lange unentdeckt bleibt.

Ohne Kennzahlen geht nichts

Der nächst Schritt ist die Definition der Kennzahlen, die für jede Hypothese aufgestellt werden. Diese Kennzahlen müssen messbar gestaltet sein, um in der späteren Auswertung bewertbar zu werden. Mit den Erwartungswerten für jede Kennzahl definiert der Business Developer die Schwellen- oder Grenzwerte, mit denen sich Erfolg oder Misslingen des Experiments prüfen lassen.

Nun folgt die Durchführung des Experiments. Hier gilt es, auf die Wechselwirkungen der einzelnen Hypothesen zu achten. Wenn zu viele Themen in einem Experiment geprüft werden, kann es bei der Auswertung der Messergebnisse zu Unschärfen kommen. Dann ist plötzlich nicht mehr klar, ob ein Messwert wegen der einen oder der anderen Veränderung den Schwellenwert zum Erfolg übersteigen konnte.

Je nach Geschäftsmodell sind zur Auswertung der Messdaten Werkzeuge notwendig, die eine Aggregation der Daten vornehmen, eine Aufteilung über Vertriebsregionen abgrenzen oder unterschiedliche Beobachtungszeiträume unterscheiden. In vielen Unternehmen existiert eine eigene Abteilung - oftmals in der IT -, die sich auf die Auswertung von Geschäftszahlen spezialisiert hat. Solch eine auf Business Intelligence ausgerichtete Abteilung kann bei Messung und Transformation der Messdaten unterstützen. Die Definition der Kennzahlen aber lässt sich nur aus dem Geschäftsmodell ableiten, weshalb diese Leistung durch das Business Development oder die an der Veränderungsumsetzung beteiligten Fachbereiche zu erbringen ist.

Durch die Auswertung der Daten und den Vergleich mit den Erwartungswerten lassen sich neue Erkenntnisse über Benutzerverhalten, Optimierungserfolge oder Umsatzwachstum gewinnen. Diese Erkenntnisse dienen dazu, durch neue Hypothesen und Anpassungen am Produkt die Effektivität der Maßnahmen zu verbessern oder die Umsetzungsstrategie anzupassen.

Messergebnisse zur Planung heranziehen

Das wissenschaftliche Arbeiten mit dem empirischen Vorgehen erfordert viel Disziplin, es ermöglicht aber zielgenauere Prozesse und Ergebnisse. Folgende Ziele sollte die Produktentwicklungspipeline unterstützen:

• Design for Change - Änderungen sollen strukturiert in die Produktentwicklung einfließen. Veränderungen werden zum Standard, nicht zur Ausnahme.

• Angemessene Reaktionszeiten bei Änderungen und Produktanpassungen. Wie viel Zeit für Anpassungen kann ich meinen Kunden zumuten?

• Verkürzung der Time-To-Feedback, zur Bestätigung von Hypothesen und zum Eröffnen von Lernpotenzialen.

• Iterationen im Produktentwicklungsprozess erbringen testfähige Lieferinkremente.

• Die Synchronisierung der Ergebnislieferung muss auch über unterschiedliche Zulieferer hinweg gewährleistet werden.

• Der Business Developer kennt den Wert der agilen Methoden und kann sie in die Strukturen des Veränderungsprozesses integrieren.

In Konzernen und mittelständischen Unternehmen sind die Veränderungen hin zu digitalen Geschäftsmodellen teilweise massiv. Daraus resultiert ein enormer Veränderungsbedarf in der Organisationsstruktur und in den Prozessen. Darum weiß der Business Developer, dass ein effizientes Change Management nötig ist, wenn er die digitale Transformation zum Erfolg führen soll. (bw)