Im Jahr 2014 formulierte der damalige CEO des Beleuchtungsunternehmens Zumtobel – Ulrich Schumacher – den Plan, sich „zu einer Art Google der Beleuchtungsindustrie“ zu entwickeln. Dabei hatte er möglicherweise 2 Dinge im Kopf:

• den Wunsch, der unangefochtene Marktführer in der Beleuchtungsindustrie zu werden – so wie Google im Bereich der Websuche – im nachhinein vielleicht etwas zu ambitioniert
• die Idee,  den Kundennutzen durch den Einsatz von Software Lösungen, die ein immer wichtigerer Teil im Unternehmensportfolio werden sollten, zu steigern und sich somit „fit für die Zukunft zu machen“.

Zur damaligen Zeit hatte ich gerade als Segment-Manager bei der Tridonic GmbH – einem Tochterunternehmen der Zumtobel Gruppe – angefangen und war verantwortlich für ein großes Portfolio von Produkten zur Beleuchtungssteuerung. Der Vergleich mit Google in diesem Zusammenhang fühlte sich für mich an, als würde sich das Unternehmen selbst überheben, da es sich in der Vergangenheit in erster Linie durch seine hochwertige Beleuchtungshardware hervorgetan hatte. Außerdem hatte ich bereits während meiner vorherigen beruflichen Stationen bei Harman Automotive (jetzt Teil von Samsung) und bei Nokia mehrmals durchlebt, wie wahnsinnig schwer es traditionell hardwarezentrischen Unternehmen fällt, Softwarelösungen zu erdenken, zu entwickeln, zu vermarkten und zu verkaufen.

Ich habe viele CEOs Aussagen machen hören wie „Wir müssen jetzt ein Software-Unternehmen werden!“ Ich denke, dass eine solche Aussage für ein Unternehmen sehr irreführend oder sogar falsch sein kann – vielleicht fällt Euch im weiteren auf, dass ich diese Terminologie in diesem Blog nicht verwende, sondern dass ich über den Übergang zur Bereitstellung von Kundennutzen durch Software spreche. Ein gutes Beispiel, wo die Dinge schief liefen, war, als Nokia seine Geschäftseinheit „Services“ neben der Geschäftseinheit „Devices“ einführte und – da „Services“ eine so hoch strategische Sache waren – die Geschäftseinheit „Services“ die Geschäftseinheit „Devices“ aufforderte, keine neuen Geräte auf den Markt zu bringen, es sei denn, ein neuer Service wäre fertig entwickelt und könnte zusammen mit dem Gerät auf den Markt gebracht werden. Dies führte zu einer Situation im Unternehmen, in der der „Schwanz praktisch mit dem Hund wedelte“ und gefährdete folglich Nokias „Brot und Butter“ Geschäft. Apple hat das viel besser verstanden und durch eine Entkopplung von Hardware und Software ein perfektes Risikomanagement betrieben, indem eine neue iOS-Version nicht strikt an die Einführung eines neuen iPhones gebunden ist (in der Praxis hat Apple den Launch neuer iphone Modelle mit neuen iOS Versionen aber stets hinbekommen)

Der Übergang zu einem Unternehmen, das seinen Kunden vor allem durch Software einen Mehrwert bietet, ist keine leichte Aufgabe. Er vollzieht sich nicht über Nacht. Es ist ein Weg, der sich auf alle Bereiche des Unternehmens auswirkt, einschließlich, aber nicht beschränkt auf Produktmanagement, Technik, Finanzen, Qualität, Lieferkette und Vertrieb. Die meisten Unternehmen, die ich in einer solchen Übergangsphase beobachtet habe, waren übermäßig ehrgeizig in Bezug auf das, was sie in einem Zeitraum von 2-3 Jahren erreichen konnten. Ich halte es für vernünftig, davon auszugehen, dass innerhalb eines Zeitraums von 5 Jahren etwas erreicht werden kann, 2 Jahre sind definitiv zu kurz.

Wenn Unternehmen sich auf digitale Dienste und Software zubewegen, tun sie das häufig, ohne die Softwareentwicklung und Datenanalyse als Kernkompetenzen zu betrachten (obwohl beide Begriffe immer wieder auf den „Strategiefolien“ auftaucht). Als Produktmanager habe ich mich stattdessen in Situationen wiedergefunden, in denen die F&E-Organisation die SW-Entwicklung an viele – nicht assoziierte – kleine Unternehmen ausgelagert hat, die eher nach der Verfügbarkeit von Ressourcen und dem Preis ausgewählt wurden als nach einer strategischen Überlegung, wie die von externen Unternehmen geschaffenen Software Artefakt (eigentlich ein Flickenteppich) richtig verwaltet und später möglicherweise wieder eingelagert werden könnte. Die frühzeitige Einsetzung von System-/Softwarearchitekten und Datenanalytikern als Eigentümer eines solchen Software-Assets und Datenbasen ist von größter Bedeutung, um den Übergang erfolgreich zu meistern. Die Installation eines technischen Produktmanagers als Product Owner der Softwareplattform wird sich sehr auszahlen. Wir konnten den Erfolg beispielsweise bei Zumtobel deutlich sehen.

Wenn es um den Business Case für Produkte geht, die dem Kunden vor allem durch Software & Daten einen Mehrwert bieten, passen die bestehenden „xls-Sheets“, die typischerweise Parameter wie Bruttomarge, Deckungsbeitrag oder Kapitalwert auf der Basis von Produktkosten und Produktpreis berechnen, nicht mehr. Diese Tabellen sind in der Regel im „Besitz“ der Finanzabteilungen des Unternehmens und versuchen sicherzustellen, dass Produkte einen Gewinn erzielen, die neben den Produktkosten auch die Gemeinkosten finanzieren kann und zusätzlich Mittel abwirft, um neue Produktideen anschieben zu können. Da nun zusätzliche Investitionen in die Softwareentwicklung getätigt werden mussten, führten die Finanzzahlen nicht selten zu einer Ablehnung einer Idee und der Vizepräsident der Finanzabteilung rief im Produktmanagement an, um das „Problem zu beheben“.

Es kommt erschwerend hinzu, dass sich gute Software ständig weiterentwickelt und dem Kunden kontinuierlich weiteren Nutzen liefern soll, was im Umkehrschluss bedeutet, dass eine Softwareentwicklung „nie“ abgeschlossen ist.

Die in Hardware Unternehmen übliche Frage „Wieviel Stück verkaufe ich mehr mit einem neuen Feature?“ führt hier nicht zum Ziel, denn es ist eine Betrachtungsweise zu etablieren die eher fragt „Welche Auswirkungen hat es auf mein Geschäft, wenn ich NICHT weiter in die Weiterentwicklung eines Produktes investiere?“. Alter Muster funktionieren nicht mehr und gerade das Produktmanagement läuft oft gegen Wände, da die alten Zöpfe nicht abgeschnitten werden – oder zumindest neu geflochten werden.

Produktmanager/-innen wissen, wie äußerst wichtig es ist, Trends auszukundschaften und den Markt zu beobachten, um „IoT“, „Cloud Computing“, „Datenschutz“ und „Industrie 4.0“ zu verfolgen und sich mit ihnen vertraut zu machen, aber noch wichtiger ist es, aus diesen Trends relevante und konkrete Anwendungsfälle abzuleiten, die unserem spezifischen Kunden einen spezifischen Mehrwert bieten und für die höchstwahrscheinlich nur ein kleiner Bruchteil aller Technologien benötigt wird, die durch die oben genannten Buzzwords grob beschrieben werden.

Dieses Wissen haben Unternehmen anfangs nicht und es ergeben sich daraus zwangsweise falsche Einschätzungen zur Komplexität eines neuen Entwicklungsvorhabens mit dem Ergebnis, dass sich bald Ernüchterung allenthalben einstellt.

Kein Zweifel – die Umstellung von Hardware auf Software und digitale Dienste ist schwierig. Die Unternehmen verfügen zwar über äußerst fähige und kluge Mitarbeiter, aber kann ein Unternehmen, das im Hardware-Geschäft hervorragende Leistungen erbracht hat, organisch (d. h. mit denselben Mitarbeitern) zu einem Team heranwachsen, das den Übergang erfolgreich bewältigt?

Meine Meinung ist ein klares „NEIN“ – es bedarf mehr als nur der Ausbildung oder Qualifizierung von Mitarbeitern für die neuen Herausforderungen. Es wird notwendig sein, „frisches Blut“ mit Software-Kompetenz in das Team zu bringen. Die Umstellung muss zwar alle Bereiche/Abteilungen betreffen, aber einige Bereiche brauchen dieses frische Blut dringender als andere. Die ersten sind typischerweise F&E und Produktmanagement, aber bald werden auch Supply Chain, Finanzen und Qualität folgen, wiederum gefolgt von Vertrieb, Recht und Beschaffung.

Es gibt keinen heiligen Gral dafür, ob ein solcher Kompetenzzuwachs durch die Einstellung der besten Talente von Unternehmen, die bereits im SW-Bereich tätig sind, oder durch eine Übernahme erreicht werden kann. Beide Optionen sollten in Betracht gezogen und bewertet werden – die endgültige Entscheidung wird sehr spezifisch für jedes einzelne Unternehmen sein.

Produktmanagement-Teams sind hier in der Schlüsselposition, um die Erwartungen zu steuern. Business Cases mit moderaten Software-Investitionen und großen Umsätzen nach 2 Jahren sollten mit Vorsicht genossen werden und eher die Ausnahme als die Regel sein. Bei Zumtobel mussten wir lernen, dass eine drahtlose und IP-basierte Lichtsteuerung, die mit der Cloud verbunden ist (nichts davon hatten wir vorher gemacht), uns weit mehr Schweiß und Tränen gekostet hat als ursprünglich geplant.

Das „Not Invented Here Syndrom“ ist in einer Transformation wie dieser kein guter Ratgeber. Produktmanagement Teams mit ihrer ganzheitlichen Sichtweise sind hier aufgefordert, den Finger in die Wunde zu legen und zu sensibilisieren, inwiefern im Unternehmen die benötigten Kompetenzen vorhanden sind, um mit digitalen Produkten erfolgreich sein zu können.

In fast allen Fällen bietet sich die Nutzung bereits vorhandenen Wissens und bereits vorhandener Technologie und der Aufbau eines entsprechenden Partnernetzwerks an. Das bedeutet mitnichten, digitale Kompetenzen langfristig outzusourcen, sondern die Zeit zu nutzen, in welcher das Unternehmen noch nicht über entsprechende Kompetenzen verfügt.

Wenn Führungskräfte sagen: „Wir müssen jetzt ein Softwareunternehmen werden!“ gehen sie oft davon aus, dass sich der Umsatz des Unternehmens von Hardware auf Software verlagern sollte. Diese Auffassung ist riskant und sollte niemals implizit angenommen werden, wenn der Kundenwert durch Software geliefert wird. Noch vor einigen Jahren habe ich im persönlichen Gespräch mit Top Managern der Automobilindustrie gehört, dass man „im Jahr 2030 ein Drittel des Umsatzes mit digitalen Diensten“ machen wolle. Die heutige Situation zeigt, dass diese Einaschätzung nicht falscher hätte sein können.

Stattdessen kommt dem Produktmanagement eine Schlüsselrolle zu, wenn es darum geht, individuell zu bewerten, ob die Kundenerwartungen, der Wettbewerb und die Technologie für die Bereitstellung von digitalen Lösungen eine solche Verlagerung der Einnahmen zulassen. Selbst wenn man zu dem Schluss gekommen ist, dass dies der richtige Weg ist, muss gemäß den Anmerkungen zur Ambition weiter oben ein realistischer Zeitrahmen für eine solche Verlagerung zwischen den Beteiligten gefunden werden.

Ich möchte Produktmanagement Teams hier ermutigen, eher konservativ zu sein und sich für konservative Ziele einzusetzen. Der Nutzen, der sich aus der Erreichung dieser Ziele ergibt, ist viel größer als das Risiko, sie zu verfehlen, was häufig zu Änderungen seitens der Geschäftsleitung führt, die wiederum „bewegliche Ziele“ und Unsicherheit in der Strategie zur Folge haben. Die Produktmanager sollten nicht zögern, immer wieder zu erklären, welchen Ansatz das Unternehmen bei der Bereitstellung von Software verfolgt. Dies hat auch nichts damit zu tun, hier der „Bremser“ zu sein oder „unkoooperativ“ zu erscheinen sondern verhindert frühzeitige Enttäuschung, Desillusion und das sofortige Hinterfragen der richtigen Strategie.

Es geht um viel mehr, als nur Software statt Hardware zu verkaufen. Die gesamte Organisation muß sich der Herausforderung stellen, dass sich Geschäftsmodelle ändern – Punkt! Ohne Ausnahme. Es betrifft jede Abteilung. Der Wandel ist definitiv nicht einfach – das Produktmanagement Team ist aber in einer zentralen Position, um den Wandel zu gestalten. Als Schnittstellenfunktion haben wir Verbindungen zu allen Abteilungen und kennen deren Abhängigkeiten. Diese Position gilt es im Sinne des Unternehmens zu nutzen und beispielsweise eine funktionsübergreifende Arbeitsgruppe einberufen, die gemeinsam Fragen beantwortet wie

• Wie amortisieren wir einen SW-Entwicklungsaufwand über mehrere Produkte hinweg?
• Soll die Basis-SW-Entwicklung über alle Produkte/Lösungen des Unternehmens abgeschrieben werden und Teil der Gemeinkosten werden?
• Wie sollen wir den Aufwand für mehrere Software-Releases auf der gleichen Hardware-Plattform behandeln? Finanzcontroller fragen häufig (siehe oben): „Wie viele Geräte würden wir mehr verkaufen, wenn wir diese neue Softwareversion entwickeln würden?“ In einer Welt, in der der Wert von Lösungen mehr und mehr durch Software geliefert wird, sollte die Antwort des Produktmanagements eher lauten: „Wenn wir die Software nicht aktualisieren, werden wir bald keines unserer Produkte mehr verkaufen, da die Konkurrenz einen höheren Kundennutzen bietet“.
• Wie wollen wir Software bepreisen ?
• …

An dieser Arbeitsgruppe sollten neben dem Produktmanagement zumindest der Leiter der Finanzabteilung, der Leiter der F&E-Abteilung, der Leiter der Abteilung für Personalentwicklung und der Leiter der Verkaufsabteilung teilnehmen.

Transformationsstrategien sind oft auf sehr hohem Level formuliert und werden als „wachsweich“ empfunden. Alle Abteilungen fragen sich zurecht „was es denn nun für sie bedeutet“. Im Zentrum der Erwägungen sollte dabei stehen, wie eine digitale Strategie unseren Kunden nutzt, denn am Ende wird sie sich nur auszahlen, wenn wir Mehrwert für unseren Kunden schaffen, für den er zu zahlen bereit ist. Produktmanagement Teams sind hier aufgefordert, den Mehrwert zu beschreiben und in der ganzen Organisation immer wieder zu erklären. Gleichzeitig sollte klargemacht werden, dass ein solcher  Mehrwert über alle Abteilungen des Unternehmens erarbeitet werden kann. Er ist keine Sache der Entwicklungsabteilung, die nun statt Hardware eben Software entwickelt. Er betrifft Entwicklung, Produktmanagement, Verkauf, Betrieb, Einkauf und Controlling. Niemand hat Grund, sich zurückzulehnen.

Produktmanagement Teams müssen durch ihre Nähe zu Markt und Kunde helfen, die Brücke zu bauen zwischen digitalen Strategien und nutzenstiftenden sowie umsetzbaren Kundenanforderungen und Anwenderszenarien – „Was hat unser Kunde denn davon?“ Eine Digitalstrategie ist kein Selbstzweck und keine Modeerscheinung. Als Produktmanagement Team sind wir aufgefordert, auch Änderungen in anderen Abteilungen anzustoßen, wenn dadurch Kundennutzen entsteht. Das wird anderen Abteilungen helfen, die Strategie umzusetzen – beispielsweise indem im Vertrieb Anwendungsexperten für die neuen Lösungen etabliert werden.

Es bedeutet aber auch, Zusammenhänge im Unternehmen immer wieder zu erklären und beispielsweise auch unsere Anstrengungen für die Schulung unserer Vertriebskollegen zu intensivieren. Ob man es nun glauben will oder nicht – für jemanden, der 30 Jahre lang Hardware Produkte vertrieben hat, ist die Promotion und die Erklärung eines digitales Services eine riesige Veränderung.

Der Bedarf an „frischem Blut“ ist natürlich auch im Produktmanagement vorhanden. Ich bin überzeugt, dass ein Gruppe von Hardware-Produktmanagern eine Umstellung auf Software besser bewältigen kann, wenn Expertise von außen mit dazu geholt wird über eine(n) neue(n) Kollegen/in, der/die bereits Erfahrungen mit digitalen Lösungen mitbringt.

Aber es müssen nicht nur neue Kompetenzen in  Teams eingebracht werden – das neue Team muss auch in eine geeignete Organisation eingebettet werden. Eine solche Organisation – auch wenn es sich anfangs schmerzhaft anfühlen mag – muss darauf achten, dass das „SW-Team“ die nötige Freiheit bekommt, um zu agieren und nicht völlig in die Prozesse eines Hardware-Unternehmens eingesperrt wird. Das Gegenteil sollte angestrebt werden: Das funktionsübergreifende „SW-Team“, welche das Softwareangebot des Unternehmens vorantreibt, muss ausdrücklich dazu ermutigt werden, die zukünftigen Prozesse des Unternehmens mit zu entwerfen.

Gleichzeitig bin ich kein Freund einer vollständigen Trennung von Hardware- und Softwaregruppen, da dies die Abstimmung auf der Arbeitsebene erschwert und zu einer „Software gegen Hardware“-Kultur führen kann. Wie eine solche Zusammenarbeit auf Arbeitsebene aussehen kann, hat unser Kollege Ulf Greiner in unserem Webinar „Brücke zwischen den Welten – Verbindung digitaler und physischer Produktstrategien“ beschrieben, welches auch auf unserer Website verfügbar ist.

Sehr wichtig ist mir dabei zu betonen, dass Organisationen mit Bedacht angepasst werden müssen. Jede Änderung birgt Komplexität und Probleme. Zu viele gleichzeitige Änderungen können Organisationen „überfordern“. Das Motto „Wir machen jetzt alles anders“ hat noch sehr selten funktioniert.

Die Erfahrungen, die ich im Laufe meiner Karriere gemacht habe, stimmen recht gut mit dem überein, was die Boston Consulting Group bereits 2008 in einem virtuellen Interview mit 3 CEOs zum unserem Thema  veröffentlicht hat. Für mich ist es ein „Deja-vu“ dessen, was ich im Laufe der Jahre erlebt habe, und ich empfehle allen, diese Lektüre zu genießen.

Natürlich haben nicht nur die virtuellen Unternehmen von BCG den Übergang erfolgreich gemeistert, denn es gibt tonnenweise Beispiele für Marktteilnehmer, die den Übergang gut gemeistert haben, darunter Cisco, IBM, Apple, Harman, Automobilhersteller wie BMW oder Mercedes-Benz, „klassische“ Kopiergerätehersteller wie Kyocera oder Minolta.

Es gibt also guten Grund für die traditionellen Hardware-Akteure zuversichtlich zu sein, dass sie diesen Beispielen folgen können, auch wenn es vielleicht länger dauert als ursprünglich erwartet. Und wer ganz genau hinsieht, der bemerkt sogar, dass viele grosse Software Unternehmen begonnen haben, in Hardwareprodukte zu investieren … Google’s Pixel Familie, Meta’s Quest oder aber Microsoft’s Surface Produkte sind gute Beispiele dafür.

von Thomas Moder
Produktmanagement-Enthusiast und PMM-Trainer und -Mentor

Als Produktmanager bin ich es gewohnt, Segmentierungsmodelle für alle möglichen Märkte zu erstellen, um Produktchancen, Ansprache und Maßnahmen besser einschätzen und priorisieren zu können. Für mich fühlt sich das als etwas Logisches und Natürliches an. Doch in Unternehmen kann das natürlich komplett anders empfunden werden. Gerade vertriebs- und projektorientierte Organisationen, in denen maßgeschneiderte Kundenlösungen für individuelle Anfragen und Anforderungen entwickelt werden tun sich schwer mit dem „Aufteilen des Markts“.

Vergangene Woche hatte ich eine sehr interessante Diskussion mit einem Team von Ingenieuren aus einem Unternehmen, das sich mit genau solchen maßgeschneiderten Lösungen beschäftigt. Das Unternehmen hatte festgestellt, dass seine Kostenstruktur bei weitem nicht ideal war.
Zusätzlich machte es auch das optimierte Setup fürs Projektgeschäft schwer bis unmöglich, die entwickelten Dinge (die in der aktuellen Aufstellung im Wesentlichen das Knowhow und die Erfahrung der Mitarbeiter waren) breiter am Markt zu skalieren.
Als ich ihnen ein einfaches zweidimensionales Segmentierungsmodell vorschlug, um die Menge ihrer potentiellen Kunden besser zu strukturieren, rief das einige – was soll ich sagen – „interessante“ Reaktionen in der Gruppe hervor. Diese würde ich als typisch für Unternehmen bezeichnen, die sich vom reinen Projektgeschäft in Richtung Produktgeschäft entwickeln wollen. In diesem Blog möchte ich diese Reaktionen teilen und Hilfestellung geben, wie damit umgegangen werden kann.

Die erste und stärkste Reaktion war ANGST – konkret die Angst, eine Vertriebsgelegenheit mit einem Kunden zu verpassen, der sich nicht exakt einem der von mir vorgeschlagenen Segmente zuordnen ließ.

Das Bild, dass ich gezeichnet hatte, sah in etwa wie folgt aus:

Für die Kollegen aus der Entwicklung und dem Projektmanagement sah das Ganze eher aus wie ein löchriges Fischernetz eines Fischers, der es doch aber gewohnt war, selbst den kleinsten Fisch in seinem Netz zappeln zu sehen. Ihr Unbehagen erwuchs aus der Sorge, dass jede Menge Fische – darunter potenziell auch sehr wertvolle – durchs Netz schlüpfen würden. Wie konnte ich also ihre Bedenken ausräumen? Denn ich verglich meine abgeleiteten Segmente eher mit einem Satz von Fliegenklebern – mit unterschiedlichen Farben und Düften, an denen jeweils ganz bestimmte Gruppen von Insekten kleben bleiben. Oder – um in der Analogie des Fischers zu bleiben – die Segmente als ein Satz unterschiedlicher Köder zu verstehen, die jeweils eine ganz bestimmte Sorte von Fischen anlocken sollten. Dabei habe ich die Köder natürlich nicht zufällig gewählt. Nein – meine Wahl beruhte auf jeder Menge an Erfahrung und Wissen, dass bestimmte Köder eben von ganz bestimmten Fischen bevorzugt werden. Die Wahl der Köder war somit eine ganz bewusste Entscheidung, die ich auf Basis der von mir bevorzugten Fische traf. Denn ich möchte schließlich diejenigen fangen, die am besten schmecken oder – um in Business Terms zu sprechen – die größten Umsätze oder Margen für mich bringen.

Sogar die Mitarbeiter stimmten mir zu. Denn auch sie hielten natürlich gerne nach den größeren Fischen (oder schmackhafteren?) Ausschau und sie bejahten, dass sie durchaus wüssten, welches diese größeren Fische wären.
Trotzdem waren sie zögerlich, Unterschiede zwischen verschiedenen Gruppen von Fischen (Kunden) zu machen, innerhalb jeder Gruppe eine Ähnlichkeit der Kundenanforderungen oder Kundenprobleme (speziell im B2B Bereich) festzustellen und typische Lösungen anzuerkennen, die gerade die Probleme dieser Gruppe löst. Es könnte ja schließlich ein wichtiger Kunde dabei sein, auf den die Lösung nicht passt. Einen Teil ihrer Bedenken konnte ich ausräumen, indem ich ihnen versicherte, dass wir die meisten Segmente bewusst um die großen Fische herum bauen würden, die sie in der Vergangenheit gefangen hatten. Eine allgemeine Lösung für ein solches Kundensegment wäre in der Regel auch attraktiv für ihre bestehenden großen Kunden, auch wenn sie vielleicht nicht zu 100% ihre Anforderungen treffen würden. Ein gewisses und angemessenes Level an Personalisierung oder Customisation in die DNA einer solchen – generischen – Lösung einzubauen, bringt uns dann einen weiteren Schritt voran, um projektgetriebenen Teams ihre Skepsis gegenüber Marktsegmentierungsmodellen zu nehmen. Wir investieren nämlich an dieser Stelle in einen gemeinsamen Lösungsbestandteil (nennen wir ihn „Plattform“ oder „Referenz-Design“ oder …), welcher für alle Kunden dieses Segmentes attraktiv ist und erweitern das ganze dann noch um die Flexibilität, daraus kundenspezifische Anpassungen abzuleiten. Die Gemeinsamkeiten möglichst früh im Entwicklungsprozess zu finden, ist der Schlüssel hier.

Für das Unternehmen bedarf es einer bewussten Entscheidung, ob sie einen solchen Arbeitsmodus aufnehmen wollen. Er bedeutet gerade am Anfang des Entwicklungsprozesses mehr Zeit und Investitionen (die Gemeinsamkeiten von Kundenanforderungen auszuloten). Diesem Aufwand steht dann jedoch auch die Chance gegenüber, das Geschäft schneller und profitabler zu skalieren. Projektgetrieben Unternehmen tun sich erfahrungsgemäß sehr schwer mit einem solchen Schritt. Oft ist es ein geeigneter Kompromiss, die Vorgehensweise erst mal in einem abgegrenzten Teil ihres Geschäftes aufzusetzen, während der große Teil des Geschäfts nach den bekannten Mustern weiterläuft.
Immer noch nicht überzeugt? Tatsächlich sah ich in den Augen einiger Mitarbeiter immer noch die Angst, dass einiges an kleinen Fischen durchs Netz flutschen und für immer (oder zumindest für die nächste Zeit) verloren wären. Nun, in diesem Fall war es nun an mir, einige Beispiele aufzulisten. Denn Lösungen, die wir gezielt für ein ganz bestimmtes Kundensegment entwickelt hatten, haben in der Regel auch eine gewisse Attraktivität für Kunden, die sich eben nicht genau diesem Segment zuordnen lassen.
Nehmen wir die Automobilindustrie als Beispiel. Für wen wurde der VW Caddy wohl ursprünglich entwickelt? Und wer kauft ihn heute? Für wen war das iPhone ursprünglich gedacht? Und wer sind die Kunden heute?

Gut! Wenn die Argumentation an dieser Stelle immer noch keine Früchte trägt, dann macht es tatsächlich auch Sinn, die Ambition eines Unternehmens, aus dem reinen Projektgeschäft herauszutreten, zu hinterfragen. Vielleicht ist das Unternehmen dann tatsächlich noch nicht reif genug, einige Risiken einzugehen, um danach mit einem stark wachsenden Geschäft belohnt zu werden. In diesem Fall ist es vielleicht besser, beim bekannten Modell zu bleiben – oder wie wir Deutschen auch gerne sagen: „Schuster, bleib bei Deinen Leisten“.

Die zweite Reaktion des Teams war nicht direkt Angst, sondern eher ein Gefühl der Unsicherheit oder Bedenken. Meine Gegenüber forderten mich heraus und fragten „Wie kannst Du sicher sein, dass die Achsen, die Du gewählt hast – erinnert Euch an das Beispiel der Weinkäufer vorne – die richtigen sind?“ An der Stelle erklärte ich ihnen, dass es kein reines „Richtig“ oder „Falsch“ gibt, um die richtigen Achsen im Rahmen eines Segmentierungsmodelles zu finden. Das Vorgehen entspricht dabei eher einer Mischung aus Wissenschaft und Erfahrung. „Aber wenn wir andere Achsen wählen, dann kommen wir ja zu komplett anderen Segmenten und woher wissen wir dann …“ war ihr nächster Einwand.
In der Denke der Kollegen aus R&D und Projektmanagement (und ich glaube, das ist ganz typisch), waren sie auf der Suche nach der 100% Lösung. Um die Bedenken hier zu zerstreuen, hilft es, von der Theorie in die konkrete Praxis zu wechseln. Ich forderte das Team auf, Vorschläge zu den Dimensionen (Achsen) einer möglichen Segmentierung in ihrem Bereich zu machen. Die Vorschläge müssten geeignet sein, um Kundensegmente in einer relevanten Art und Weise voneinander abzugrenzen – relevant in Sinne typischer Kundenanforderungen oder Kundenprobleme (eine Abgrenzung aufgrund des Alters des Einkaufsleiters wäre wohl nicht relevant in unserem Sinne 😊). Danach sollten sie an einer Reihe von Möglichkeiten arbeiten, zwei der potentiellen Achsen miteinander zu kombinieren und in das resultierende Koordinatensystem einige typische Kundensegmente einzuzeichnen.

Um beim Beispiel des Fischers und der Fische zu bleiben, könnten ihre Segmentierungsmodelle in etwa wie die folgenden ausgesehen haben.

An dieser Stelle stellen die Leute dann in der Regel fest, dass es mehrere Optionen gibt, die in ihrem spezifischen Kontext Sinn ergeben. Aber es kristallisiert sich immer eine Option, die für ihre Zwecke und für ihr Business am besten passen würde. Diese Möglichkeit lässt sich (in der Regel) nicht über einen Algorithmus finden, der die spezifische Natur des Geschäfts, in dem man tätig ist, nicht berücksichtigt. Ja – es kann extrem hart sein, an dieser Stelle Entscheidungen zu treffen. Und das Team ist vielleicht in Versuchung, ein 10-dimensionales Segmentierungsmodell zu entwerfen (mit 587 Segmenten – die am Ende einen Kreis um jeden einzelnen Kunden reflektieren – also genau das Geschäftsmodell wiedergibt, dem das Unternehmen aktuell folgt).

Es sollte nicht allzu schwierig zu argumentieren sein, dass wir einige Vereinfachungen anwenden müssen, damit unser Modell verständlich („ich versteh’s auf den ersten Blick“) und die Anzahl der Segmente überschaubar bleibt. Mit statistischen Methoden lässt sich (bei Verfügbarkeit von sehr vielen Daten) dann eine Reduktion von Segmenten durch „Clustering“ erreichen. Das wird jedoch in den meisten Fällen absolut overengineered und auch zu teuer sein. Am Ende wollen wir unser Business besser strukturieren und Entscheidungen treffen über Investitionen, die mehr als einen einzigen Kunden glücklich zu machen können.

Nachdem wir uns geeinigt hatten, an einigen unserer Entwürfe für ein Segmentierungsmodell weiter zu tüfteln, folgte Reaktion Nummer 3: „Was sagt uns das jetzt? Was machen wir jetzt damit? Welchen Impact macht das Modell jetzt?“

Ganz ehrlich – das hätte mir nicht passieren sollen und offensichtlich hatte ich einen miserablen Job gemacht. Meine Aufgabe war es doch, vorab ausreichend zu motivieren, warum wir ein solches Segmentierungsmodell erarbeiten sollten, wie es uns helfen kann unser Geschäft voranzubringen und wozu wir es konkret nutzen würden. Nehmt es also als „Best Practice“, nicht zu viel Wissen über das Thema Marktsegmentierung oder Kundensegmentierung vorauszusetzen. Verwendet mehr Zeit am Anfang – mehr als ihr Euch vorstellen könnt – um Sinn und Zweck einer solchen Segmentierung ausführlich zu erklären. Dies hätte eigentlich meine erste Priorität sein sollen und ich hätte die Basics besser erklären sollen, bevor die weiteren Diskussionen im konkreten Umfeld dann folgen. Was wären also meine Antworten auf die Fragen „Was sagt uns das jetzt? Was machen wir jetzt damit? Welchen Impact macht das Modell jetzt?“ gewesen?

Gegenüber Kollegen oder Teams, die es gewohnt sind in einzelnen Kundenprojekte zu arbeiten, können Euch die folgenden Erklärungen nützen:

1. Das gemeinsame Ziel verdeutlichen

Am Anfang sollten wir nochmal klarstellen, dass wir alle das gemeinsame Ziel haben, unser Business zu skalieren. Unser Ziel ist, vorausschauend Entwicklungen vorantreiben, die Nutzen stiften oder Probleme lösen für mehr als einen einzelnen Kunden. Im Wesentlichen sollte es darum gehen, Liefer- oder Lösungsbestandteile anzuvisieren, die wir einmal entwickeln, aber mehrfach verkaufen können.

2. Bisherige Vorgehensweisen hinterfragen

Ist das erst mal geschafft, dann fragt (und dokumentiert die Antworten) in die Runde „Was hat uns in der Vergangenheit denn abgehalten, genau das zu tun?“ und mit hoher Wahrscheinlichkeit werdet ihr Antworten wie die folgenden bekommen.

• „Der Zeitplan des (späteren) Kunden B hat sich gebissen mit dem Zeitplan des (früheren) Kunden A …“
• „Nun, im Prinzip wollte Kunde B was ähnliches wie Kunde A, aber das wussten wir ja nicht, als wir die Lösung für Kunde A entwickelt haben, weil die Anfrage von B kam erst viel später …“
• „Weil wir die Anforderungen von Kunde B bei der Entwicklung für Kunde A nicht berücksichtigt haben, konnten wir auch nicht einfach Teile aus der Lösung für A herausschneiden und sie mit weiteren Teilen für B anreichern …“

Stellt sicher, dass solche Dinge auf den Tisch kommen. Das Team sollte sich einig sein, dass die Vorgehensweise „Lass uns mal sehen, was wir für Kunde A entwickelt haben und checken, ob wir was davon auch für Kunde B, C, D oder E brauchen können …“ NICHT zielführend ist. Sollte so etwas je funktioniert haben, dann ist es eher eine Sache reinen Zufalls in einem projektgetriebenen Markt.
Alle im Team sollten kurz reflektieren, warum in der Vergangenheit kein besserer Ansatz gefunden wurde (vielleicht hat man es einfach nicht versucht …)

3. Gemeinsamkeiten identifizieren

Wenn wir also tatsächlich wegkommen wollen von einem Ansatz reiner „maßgeschneiderter“ Lösungen für einzelne Kunden, müssen wir zwingend ein besseres Verständnis entwickeln über die Gemeinsamkeiten zwischen unseren potentiellen Kunden sowie ihren Anforderungen und Problemen. Die Identifikation dieser Dinge wird uns Zeit und Vorab-Investitionen abfordern für Markt- und Kundenrecherche.

4. Kundensegmente ordnen

Wenn wir dann aber tatsächlich Gemeinsamkeiten/Ähnlichkeiten in Kundenbedürfnissen oder Kundenproblemen gefunden haben, können wir diese Kunden auch einem „Kundensegment“ zuordnen. Haben wir dann den Markt in solche Segmente aufgeteilt, haben wir einen perfekten Startpunkt um gemeinsame Lieferbestandteile (Lösungsbestandteile, Assets, Plattformen, …) zu entwickeln, die für alle Kunden eines Segmentes attraktiv sind. Investitionen können somit über mehrere Kunden geteilt werden und müssen nicht innerhalb eines einzelnen Kundenengagements monetarisiert werden (Was vermutlich unseren Angebotspreis in die Höhe treibt und eventuell zum Verlust des Kunden führt).

5. „Sanity Check“ für das Segment durchführen

Für jedes abgeleitete Segment sollten wir einen „Sanity Check“ machen. Ist das Segment homogen, nachhaltig, groß genug, profitabel und für uns adressierbar? Versucht hierbei z.B. mit einer Top-Down oder Bottom-Up-Analyse das realistische Potenzial in den einzelnen Segmenten abzuschätzen.

6. Segmente priorisieren

Dass wir nun in unserem Markt eine Anzahl von Segmenten identifiziert haben, bedeutet nicht automatisch, dass wir auch alle diese Segmente mit unserem Angebot bedienen müssen. An dieser Stelle sind wir gefordert, NEIN zu sagen zu bestimmten „Business Opportunities“ zugunsten von langfristig besseren Business Opportunities. Es mag gute Gründe geben, ein Segment zu adressieren und ein anderes dafür zu vernachlässigen. Das können zum Beispiel die große Kundennähe oder die verfügbare Technologie für ein Segment sein oder aber fehlender Vertriebskanal, Support Organisation oder Entwicklungskapazitäten auf der anderen Seite. Unser Anliegen muss es sein, Investitionen dahin zu leiten, wo sie uns den größten Erfolg versprechen. Damit sollten wir für jedes Segment auch verstehen, welchen Teil des Marktes (in %, € oder $) es repräsentiert.

7. Das Segmentierungsmodell konsequent anwenden

Es gibt viele Antworten auf die Frage „Ja, und was machen wir jetzt mit dem Segmentierungsmodell? Ist das nicht nur Theorie?“

• A) Der wichtigste Grund wurde bereits genannt – wir nutzen es, um zu verstehen und zu entscheiden, auf welche Kunden wir unser Angebot abzielen.
• B) Wir sollten das Modell kontinuierlich heranziehen um gesamtheitlich über unseren Investitionsfokus zu entscheiden – in R&D, Vertrieb, Marketing, Produktion, Support usw. Das Wissen über Bedürfnisse und Probleme der Segmente wird uns nicht nur helfen zu entscheiden, WO (in welches Segment) wir investieren wollen, sondern WAS (Plattformen, …) wir schaffen wollen über Vorab-Investitionen in Lösungen, welche die von uns ermittelten Kundenbedürfnisse und -probleme adressieren.
• C) Wann immer wir im Zweifel sind, ob wir uns auf ein bestimmtes Kundenengagement einlassen sollen, können wir das Modell heranziehen, um zu beurteilen, ob der Kunde und seine Anfrage zu dem passen, was die Kunden aus unseren Zielsegmenten typischerweise fordern. Falls nein, bewegen wir uns wahrscheinlich in eine Sackgasse und die Lösung kann nur einmal verkauft werden.
• D) Unser Modell unterstützt den Rest der Organisation, unseren Kundenfokus zu verstehen und die richtigen Kommunikationskanäle und Botschaften zu wählen. Den Vertriebskanälen hilft es, einem Kunden ein passendes Angebot zu machen, dass mit hoher Wahrscheinlichkeit, ein Bedürfnis oder Problem des Kunden adressiert als der Ansatz – und glaubt mir ich sehe das viel zu oft – „Lass uns dem Kunden mal alles erzählen, was wir in der Vergangenheit so gemacht haben …“
• E) Unser Segmentierungsansatz hilft uns, unser Angebot und unsere Lösungen in einer strukturierten Art und Weise innerhalb und außerhalb des Unternehmens zu kommunizieren. Den Startpunkt bildet dabei immer Das Segment und dessen Bedürfnisse oder Probleme und von dort bilden wir die Brücke zu den Lösungen, die wir speziell für dieses Segment konzipiert und entwickelt haben. Eine solche Vorgehensweise verspricht größere Erfolge als der allzu oft verwendet „One Size Fits All“ Approach.

Die Reaktionen #1 bis #3 stellen ein durchaus übliches Szenario dar in Unternehmen, die vom Projektgeschäft ins Produktgeschäft streben. Eine Wandlung im „Mindset“ solcher Unternehmen ist dabei genauso notwendig, wie der Aufbau von Marktwissen und Prognosen über zukünftige Geschäftsaussichten. Ein Segmentierungsmodell ist dabei ein wertvoller Bestandteil, die Sicht auf den Markt zu strukturieren und Entscheidungen über zukünftige Vorab-Investitionen zu treffen.

Thomas Moder – ProduktManageMentor Trainer und Mentor