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.