Herausforderung den Use Case von IoT zu bestimmen
Das Internet of Things ist geprägt durch die technische Anbindung von Geräten und Systemen an das Internet. Diese Anbindung ist zwar der Startpunkt vieler IoT-Projekte, hinsichtlich der Umsetzung jedoch in den meisten Fällen, nach der sorgfältigen Betrachtung der verfügbaren Optionen, mit relativ geringem Aufwand realisierbar.
Die bloße technische Nutzung von IoT erzeugt jedoch erst einmal per se keinen Wert für das Produkt, den Prozess oder das Unternehmen als Produkt- oder Prozesseigner.
Eine der Herausforderungen, die damit gerade zu Beginn eines Projektes Beachtung finden muss, ist somit die Definition des sogenannten Use Cases. Der Use Case beschreibt unter anderem die Möglichkeiten als Nutzer oder externes System mit dem jeweils betrachteten System zu interagieren.
Diese Interaktionen sollten dabei zu einem entsprechenden unternehmerischen Ziel konvergieren, denn einen Wert erhält die IoT-Anwendung im Produkt oder im Prozess dann durch die spätere Applikation. Diese Applikation wird basierend auf dem technischem Fundament, wie den Daten oder den neuen Kommunikationsmöglichkeiten, aufgebaut. Die grundsätzlichen Kategorien in denen IoT-Anwendungen einen Wert erzielen können und wie dieser quantifiziert werden kann, werden wir in einem zukünftigen Beitrag behandeln.
In der Praxis steht die Use Case Definition für IoT häufig vor der Herausforderung zwischen der Technologie-Perspektive und der Anwendungsperspektive zu wechseln und die Ideen, was man mit einem Sensor, einer Sensorkombination oder einer Auswertung der erhobenen Daten erreichen könnte, zu systematisieren. Der vorliegende Beitrag enthält einen methodischen Vorschlag, wie das Hin und Her von der Technologie zur Anwendung sowie von der Anwendung zur Technologie in der Ideenphase systematisiert bei der Use Case Definition genutzt werden kann.
Was ist „if this then that“?
Bereits 2010 ging in den USA der Dienstanbieter IFTTT an den Markt. IFTTT bedeutet „if this then that“, zu deutsch „wenn dies dann das“, und beschreibt ein einfaches Regelwerk mit sogenannten Rezepten, die basierend auf einem Eingangsereignis („if this“) mit bestimmten Aktionen reagieren („then that“). Die Applikation wurde in den Medien hoch gelobt, was höchstwahrscheinlich auf der Einfachheit des Aufbaus der Regelwerke beruht. Einfache Automatisierungsaufgaben können damit schnell gelöst werden, wobei vor allem die Anbindung diverser Systeme unterschiedlichster Hersteller über Trigger und Aktionen möglich ist.
So kann die Erkennung einer Person durch die Kameras von Anbieter A das Licht im Haus über Anbieter B anschalten. SWMS hat IFTTT aus technischer Sicht bereits in einem früheren Beitrag beleuchtet. Doch wie hilft der Denkansatz hinter IFTTT bei der Use Case Definition für IoT-Systeme?
Das Denkmuster „IFTTT“ für die Use Case Findung
Für die Use Case Findung, die in der Praxis im Spannungsfeld von technologischen Möglichkeiten und zu erzielenden Aktionen oder Werten stattfindet, hilft der einfache Aufbau des Denkmusters hinter IFTTT weiter. Wichtig ist, dass wir hier nur dem einfachen Denkmuster folgen sollten und uns zunächst von der tatsächlichen Technologie frei machen. Es geht nur darum grundsätzlich festzulegen, dass bestimmte technische Voraussetzungen alleine oder in Kombination zu Aktionen führen, die dann den Wert von IoT für das Produkt oder den Prozess determinieren.
Der häufig einfachste Fall, um zu starten, ist dabei die Aufnahme des Status Quo hinsichtlich erfasster Daten und eingesetzten Sensoren, denn in den meisten Fällen sind IoT-Projekte dadurch gekennzeichnet, dass ein bereits bestehendes System oder ein bestehender Prozess „digitalisiert“ und weiter automatisiert werden soll. Starten Sie daher damit, sich den aktuellen Aufbau Ihres betrachteten Systems klar zu machen. Dabei ist relativ unabhängig, ob es sich um ein Produkt oder einen Prozess handelt, den Sie betrachten. Ein Produkt nutzt beispielsweise für die interne Steuerung schon diverse Sensoren und schaltet damit Aktoren, wie beispielsweise im skizzierten Swimmingpool. In einem Prozess werden ggf. schon Start- und Endzeiten, Qualitätskriterien oder bestimmte Maschineneinstellungen erfasst, wenn auch manuell und ggf. nur sporadisch.
Von der Technologie zur Anwendung
Aus dieser Sammlung heraus können nun nach der einfachen Idee der Rezepte à la IFTTT, Ideen für neue Anwendungen der physischen Messungen und der erhobenen Daten abgeleitet und formuliert werden. Wichtig ist dabei, dass mögliche technische Hürden hierbei konsequent ignoriert werden. Es geht nicht darum, die Spezifikation im Detail zu bestimmen sondern grundsätzlich und systematisch eine Idee zu formulieren, die auf der „if this“-Seite beschreibt welche technische erfasste Situation auf der „then that“-Seite welche Aussage und mögliche Aktion zu Folge haben soll. Ein einfaches Beispiel am Beispiel Swimmingpool: „Wenn die Außentemperatur > 26 °C, dann schalte die Heizung aus“. Selbstverständlich wir hier das Potenzial von IoT längst nicht ausgeschöpft, Sie können Ihren Use Case aber ohne komplexere Regeln nach selbigem Schema modellieren. Beispiel: „Wenn die Chlorkonzentration niedrig und die Besucheranzahl hoch und die letzte Chlorbestellung x Tage her ist, dann bestelle automatisch neues Chlor“. Hier wird der Wert der Automatisierung des Geschäftsprozesses und des Services wesentlich deutlicher, denn die technischen Parameter werden in Kombination dazu genutzt diesen Wert zu erzeugen: Nämlich ein vereinfachtes und automatische Bestellsystem, welches dem Betreiber eine Aufgabe signifikant vereinfacht und gleichzeitig einem Poolbauer ein After Sales Geschäft ermöglicht.
Von der Anwendungsidee zur Technologie
Nun kann die Anwendungsidee in Unternehmen ebenfalls die initiale Rolle einnehmen. Bleiben wir beim Beispiel des Pools. Ein Poolbauer kann sich natürlich zuerst die Frage stellen, wie er seine Kunden beispielsweise nach dem Verkauf und der Errichtung des Pools an sich bindet und mag ebenfalls auf die Idee kommen, dass unter anderem die kontinuierliche Belieferung seiner Kunden mit Chlor ein interessantes Geschäft wäre. Er ist zudem davon überzeugt, dass er seine Kunden dazu bringen kann, bei ihm kontinuierlich Chlor zu bestellen, wenn es ihm gelingt die für den Kunden lästige Regelung, Kontrolle und Bestandsführung zu automatisieren. „Dafür haben wir doch alle notwendigen Daten, oder?“, ist damit die zentrale Fragestellung, die mit Hilfe der „if this then that“-Modellierung ebenfalls methodisch so genutzt werden kann, dass die Ereignistrigger („if this“) mit den notwendigen technischen Gegebenheiten aus der Aktion heraus (Belieferung mit Chlor, „then that“) definiert werden können. Häufig sind es die Stakeholder, d.h. Kunden, interne Servicemitarbeiter, Produktentwicklung, etc., die Ideengeber oder Adressaten dieser Aktionen sind.
Die wahre Stärke – Drittsysteme und mehr
Der Erfolg des Anbieters IFTTT liegt unseres Erachtens vor allem in der Tatsache, dass herstellerunabhängige Anbindungen gewährleistet wurden. Damit können schier unendliche Kombinationen von Regelwerken erstellt werden, ohne das große technische Einschränkungen durch den Funktionsumfang einzelner Hersteller bestehen. Auch bei der Modellierung des IoT-Systems über diese geborgte Methodik, sollte man sich bewusst sein, dass frühzeitige technische Einschränkungen zu vermeiden sind. In beiden Fällen gilt somit, dass Zusammenhänge auch vage formuliert werden können, d.h. zum Beispiel „wenn Anomalien im Vibrationssensor an der Pumpe über die Zeit zunehmen, dann schicke eine Meldung an das angebundene ERP-System“.
Alles was zudem an Datenquellen oder Ereignissen denkbar ist, ist zur Definition der Use Cases geeignet. Vor allem externe Datenquellen und Systeme bieten hierbei sogar ein unglaubliches Potenzial zu innovativen Ansätzen. Quellen sind beispielsweise
- Drittsysteme, z.B. Tweets über das Unternehmen, Social Media-Daten
- Bestandssysteme, z.B. Meldungen über das ERP-System, Events aus dem SCADA-System, SPS-Daten
- Fremddaten, z.B. Wettermeldungen, Umgebungswerte aus der Gebäudetechnik
- Open Data, z.B. Verkehrsdaten, Markdaten, Statistiken, …
- etc.
Fazit
Der Begriff „Methode“ ist fast zu weit gefasst, aber wir haben in diesem Beitrag ein einfaches Vorgehen vorgestellt, mit dem von der technischen Möglichkeit („if this“) die Anwendung und Aktion („then that“) systematisch abgeleitet und vor allem dokumentiert werden kann.
Dabei ist zudem der zweite Weg von der Anwendungsidee („then that“) zu den notwendigen technologischen Voraussetzungen („if this“) genauso möglich. Eingebettet in die Beschreibung des Status Quos, bestehend aus
a) dem Produkt bzw. Prozess, welches „digitalisiert“ werden soll,
b) den technischen Fähigkeiten bzw. Daten, die es bisher besitzt und
c) den Stakeholdern, die an den Aktionen interessiert sind,
führt dieses Vorgehen zu einer einfachen Beschreibung möglicher Use Cases und somit zur Möglichkeit der Ableitung der Use Cases, die im Rahmen eines IoT-Projekts weitere Betrachtung finden.
