Business Models im Internet of Things

Zum (I)IoT-Geschäftsmodell in 5 Schritten

Kommentar  von Raimund Schlotmann  IDG ExpertenNetzwerk
(Industrial) Internet-of-Things-Projekte brauchen das richtige Business Model. Lesen Sie, wie Sie in 5 Schritten zum erfolgreichen IIoT-Geschäftsmodell kommen.
In der Retail-Zukunft könnten den Kunden mittels Gesichtserkennung auf ihn zugeschnittene Produkte oder Angebote präsentiert werden.
Foto: Zapp2Photo - shutterstock.com

Warum werden neue Technologie-Themen eigentlich immer mit einem Buzzword versehen? Schließlich handelt es sich dabei doch meistens um die Verlängerung oder Verstärkung von Themen, die es auch schon vorher gab. Die Begriffe leisten aber eins: Sie ändern die Betrachtungsweise und geben den Themen eine Überschrift, eine neue Richtung, einen neuen Spin. Beispiel Internet of Things (IoT): Stellen Sie sich vor, alle Dinge wären mit dem Internet verbunden. Was würde dann alles gehen? Und was würde für Ihr Unternehmen Sinn machen?

Traditionelle und vor allem technische Unternehmen beginnen die anstehende Aufgabe meist bei der Technologie. Eine zusätzliche Abteilung im IT-Bereich wird sicherlich spannende Beiträge zum Verständnis der Technologie liefern aber eines nicht: die geschäftliche Orientierung bei der Nutzung der neuen Möglichkeiten. Es ist der erste Schritt zum Erfolg, dem Reflex der technologischen Betrachtung nicht zu folgen und einen anderen Ansatz zu wählen.

1. Digitaler Wirkungsmanager

Die Beantwortung der Frage: "Welcher geschäftliche Erfolg steckt für unser Unternehmen hinter dem (I)IoT Ansatz" ist in jedem Fall eine Geschäftsleitungsaufgabe bzw. Geschäftsführungsaufgabe. Der Projektleiter sollte deshalb, zumindest zu Beginn des Projektes, direkt an die Geschäftsleitung/-führung berichten. Der Projektleiter ist nicht nur ein IT Mitarbeiter, er ist ein "Digitaler Wirkungsmanager". Seine Aufgabe ist die Definition der Wirkung von (I)IoT für die Kunden des Unternehmens und das Unternehmen selbst. Er kann eine technische oder eine betriebswirtschaftliche Ausbildung haben, aber er muss in jedem Fall übergreifend, aus Sicht des Unternehmens bzw. aus Business-Sicht denken und handeln können - und auch dürfen. Er muss ein Kommunikator sein, jemand der die Stakeholder im Unternehmen in sein Projekt einbinden kann. Und er muss "business-kreativ" denken und handeln.

Hier gehts zur Studie "Internet of Things 2019/2020"

2. Geschäftsmodell-Nukleus

Machen sie sich folgende Grundregel klar: Solange niemand mindestens einen begeisternden Anwendungsfall mit (I)IoT vollständig ausgearbeitet präsentieren kann, muss auch nicht investiert werden. Auch das immer wieder gern genommene Beispiel Predictive Maintenance ist kein Selbstzweck. Zu Beginn eines (I)IoT-Projektes sollte folgende Frage im Vordergrund stehen: Gibt es einen Business Case, der sich rechnet? Ist diese Frage geklärt, geht es daran, den passenden Projektleiter zu finden. Der Nukleus des Erfolgs mit (I)IoT beginnt meist in einem oder in wenigen genialen Köpfen. Folgende Fragestellungen können bei der Suche unterstützen:

Lesetipp: Corporate Startups - Wie Mittelständler zukunftssicher werden

Um die Ecke zu denken und Dinge neu zu denken vollbringen in der Geburtsstunde solcher Ideen eher nicht große Teams, die in alten Denkweisen feststecken und auch nicht Menschen, die von den vorhandenen Talenten des Unternehmens losgelöst als Startup agieren. Machen Sie keine Kompromisse, binden Sie in dieser Phase nicht Stakeholder ein, die diese Anforderung nicht erfüllen, nur um sie ins Boot zu holen. Holen Sie sich im Zweifelsfall externe Expertise. Die technologischen Möglichkeiten müssen verstanden werden, um auf Ideen zu kommen. Die Ideen sind allerdings Geschäftsideen und die Verantwortlichen/der Verantwortliche muss auf dieser Ebene denken.

Tipps für Projektleiter virtueller Teams
So kann die Zusammenarbeit gelingen
Damit Mitarbeiter auf mehreren Kontinenten oder an unterschiedlichen Standorten gut zusammenarbeiten können,sollten Führungskräfte einiges beachten. Beraterin Sonja App hat einige Tipps zusammengestellt.
1. Auswahl der Mitarbeiter
Prüfen Sie nicht nur die Fachkenntnisse, sondern auch die englischen Sprachkenntnisse der Teammitglieder bereits vor Projektstart und bieten Sie bei Bedarf Crashkurse an.
2. Kommunikation
Bereiten Sie virtuelle Meetings sorgfältig vor. Achten Sie insbesondere darauf, dass alle Teammitglieder über die erforderlichen technischen Rahmenbedingungen verfügen und mit den eingesetzten Tools vertraut sind. Planen Sie ausreichend Zeit für die Beziehungspflege mit jedem Teammitglied und regelmäßige One-to-one-Gespräche ein.
3. Persönliche Treffen
Ein Kickoff-Meeting sollte als Präsenztreffen gestaltet werden, damit sich alle Projektbeteiligten persönlich kennenlernen und Vertrauen zueinander aufbauen. Als Leiter virtueller Linienteams sollten Sie mehrere persönliche Treffen pro Jahr mit Ihren Mitarbeitern einplanen. Im Idealfall führen Sie das jährliche Beurteilungsgespräch mit jedem Teammitglied vor Ort an dessen Arbeitsplatz.
4. Interkulturelle Zusammenarbeit
Gehen Sie offen und tolerant mit fremden Ansichten und Arbeitsstilen um. Bieten Sie bei Bedarf interkulturelle Trainings an. Berücksichtigen Sie Zeitverschiebungen und Besonderheiten wie lokale Feiertage und Schulferien bei Ihrer Projektplanung. Beachten Sie den Arbeitsrhythmus Ihrer ausländischen Kollegen bei der Terminvereinbarung für Telefonkonferenzen und virtuelle Meetings.
5. Dokumentation
Stellen Sie sicher, dass alle Zielgruppen im Unternehmen die Ergebnisdokumente im richtigen Format zum richtigen Zeitpunkt erhalten. Sensibilisieren Sie Ihr Team auch für die Dokumentation von informellem Wissen. Planen Sie einen Lessons-Learned-Workshop ein und informieren Sie die Abteilungen über die Ergebnisse.
Sonja App
Managementberaterin Sonja App hat jahrelang selbst in virtuellen Teams gearbeitet. Ihre Tipps kommen aus erster Hand. Seit sechs Jahren ist sie als Beraterin für Innovation-Management, Relationship -Management und interkulturelle Kommunikation selbstständig.
Buchtipp
Ihre Erfahrungen und Ratschläge hat Sonja App in einem Buch zusammengefasst: "Virtuelle Teams" von Sonja App, Haufe Lexware, 2013, 240 Seiten.

3. Anwendungsfälle, die überzeugen

In meinem Buch habe ich das Beispiel eines Weckers beschrieben, der dank IoT die Staudaten und die Flugzeiten kennt und abhängig von diesen Daten weckt. Wie kommt ein Team auf solche Anwendungsfälle? Schaffen Sie in dieser Phase kein Team, das technisch hinterfragt, was dafür notwendig ist und wie das funktionieren könnte. Schaffen Sie ein Team, das fragt, wer dafür bezahlen würde - welche Personen also zum Beispiel einen solchen Wecker kaufen würden. In einem Produktionsprozess ist es klar, dass es vom Konzept gesehen ein Vorteil wäre, wenn Bauteile in der Produktion direkt miteinander kommunizieren könnten. Es gilt allerdings den prozessualen Vorteil zum zentralistischen Leitstandkonzept aus Business-Sicht darzulegen.

Bei der Arbeit an solchen Businesskonzepten wird klar, dass es viele (I)IoT Anwendungsfälle gibt, die sinnvoll sind aber keinen ausreichenden "Pain Point" adressieren. Wenn dem so ist wird nicht dafür bezahlt. Ein solcher Anwendungsfall könnte dann realisiert werden, wenn für ein Produkt bereits IoT-Anbindungen allgemein verfügbar sind und die Realisierung so geringe Kosten erzeugt, dass man die neuen Fähigkeiten zum bestehenden Preis anbieten könnte.

In der jetzigen frühen Phase der Technologie werden Anwendungsfälle benötigt, bei denen sozusagen "kein Auge trocken bleibt". Die also einen so großen Vorteil bieten, dass dafür bezahlt wird. Akzeptieren Sie keine anderen Anwendungsfälle.

4. Härtung per Stakeholder

Das betreffende Geschäftsmodell und die grundsätzliche Machbarkeit von überzeugenden Anwendungsfällen ist klar und die Ideen begeistern und sind erstklassig aufbereitet. Erst jetzt ist es Zeit, die Stakeholder in Ihrem Unternehmen einzubeziehen. Die Beteiligung der Stakeholder an dem Härten der Ideen macht gleichzeitig Betroffene zu Beteiligten. Stakeholder können alle intern betroffenen Abteilungen wie Vertrieb, Produktion oder IT - abhängig vom Thema sein. Auch die Einbindung von Pilotkunden als Stakeholder ist möglich. Gemeinsam mit den Stakeholdern gilt es nun, die Ideen zu "härten". Es gibt bei solchen konzeptionellen Diskussionen immer zwei Varianten:

Personen, die im bisherigen Prozess, Produkt oder Vorgehen verhaftet sind und denen Paradigmenwechsel schwerfallen, sollten zwar noch nicht am Anfang des Prozesses beteiligt sein, aber in dieser Phase sind diese Menschen Gold wert. Die "Härtung" von Ideen bedeutet sie zu hinterfragen, zu prüfen und zu erweitern. An diesem Punkt kann geklärt werden, ob bei der Entwicklung des Geschäftsmodells und bei dem Entwurf des Anwendungsfalls an alles gedacht wurde. Zudem können die Stakeholder in dieser Phase ergänzende Ideen anbringen.

Lesetipp: Tipps für kreative Einfälle und Produkte

Es ist wichtig, dass dabei die Verantwortungen klar geregelt sind. Es muss klar sein, dass die präsentierten Ideen nur mit wirklich überzeugenden Argumenten zu Fall gebracht werden können. Es muss heißen "Wir werden so etwas in dieser Art machen, Ihr seid gefragt, daran mitzuarbeiten." Erlauben Sie allerdings ein Vorgehen nach der "Versuch und Irrtum-Methode". Gute Ideen sehen am Anfang meist nicht so aus, wie das Endergebnis. Erlauben Sie Richtungsänderungen im gesamten Projekt und im Go-To-Market-Zeitraum, wenn sich neue Erkenntnisse ergeben.

15 Probleme beim Projektmanagement
1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen.
2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia.
3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv.
4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt.
5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet.
6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann.
7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht.
8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software.
9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist.
10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat.
11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3.
12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen.
13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren.
14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes.
15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden.
15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.

5. Erfolgsgrundlage schützen

Ist der gesamte Business Case inklusive Technik im Sinne eines Lasten- oder Pflichtenheftes beschrieben, beginnt die Umsetzungsphase. Der Wirkungsmanager wird nun zum internen Kunden des Umsetzungsteams, die Geschäftsleitung zum Lenkungskreis.

Die Führung des Projektes erfolgt aus Wirkungssicht, nicht nur technisch. Hierbei hilft die Denkweise eines Startups, in die investiert wird. Die Frage, ob diese Unternehmung vielleicht wirklich besser ein Startup auf der anderen Straßenseite sein sollte, hängt davon ab, wie groß und wie disruptiv die Änderung ist. In jedem Fall muss verhindert werden, dass Veränderungsaversion dazu führt, dass das Projekt scheitert. Auf der anderen Seite ist die beste Version immer, wenn Neues aus dem entsteht das heute erfolgreich ist, also der bisherige Erfolg in die Zukunft überführt wird. Besteht die heutige Entwicklung z.B. vornehmlich aus mechanischer Entwicklung und liegt die zukünftige Differenzierung in Software, so liegt eine Trennung aber schon allein aus der Betrachtung der unterschiedlichen Prozesse auf der Hand. Halten Sie den Aufbau des neuen Konzeptes soweit getrennt wie notwendig, um keine Bedrohung durch die Kräfte der bisherigen Erfolgsgrundlage zu erlauben und gleichzeitig so integriert wie möglich.

Beendet ist das Projekt, wenn das neue Geschäftsmodell, bzw. der neue Anwendungsfall geschäftlich erfolgreich ist, nicht vorher. Entlassen Sie alle Beteiligten erst dann aus der Verantwortung. (bw)