Black Box IoT?

Wer kauft schon gerne die Katze im Sack? Zumal wenn damit komplettes Neuland betreten wird… Der erste Kinderwagen zum Beispiel: Man ist sich zwar schon darüber im Klaren, dass man ihn braucht, aber die Entscheidung, ob es ein kleines Packformat oder doch lieber die Fahrradanhänger-Kombi sein soll, ist da schon schwieriger.

Der letzte Kinderwagenkauf ist jetzt schon einige Zeit her (mittlerweile bin ich Experte im Kauf von Skateboards). Falls Sie aber gerade vor der Wahl stehen, empfehle ich Ihnen ein dunkles Modell, da sieht man den Dreck nicht so deutlich.

Ein IoT-System ist zwar in der Regel nicht so dreckempfindlich, seine Auswahl ist dafür aber umso komplexer. Zumal viele Unternehmen damit Neuland betreten und schon an der Auswahl der richtigen Kriterien schier verzweifeln können. 

Hier habe ich zwei gute Nachrichten. Erstens: Welche IoT-Lösung passt, lässt sich einfach ausprobieren. Ein Proof of Concept ist eine sehr gute Möglichkeit, eine Lösung ohne große Risiken zu testen, bevor Sie sich für ein System entscheiden. Und zweitens: So sehr IoT auch neue Chancen bietet – so sehr basieren smarte Geschäftsprozesse auf guten alten Tugenden:

  1. Sind Sie sich sicher, wie Ihr IoT-Geschäft aussehen wird und das es auf lange Zeit so bleibt? Wahrscheinlich nicht. IoT ist ein sehr volatiler Markt, in dem gerade eine ganze Menge passiert. Also muss Ihr IoT-System reaktionsstark sein und am besten von der Fachabteilung selbst angepasst werden können. Das Stichwort dahinter heißt „low code„, das heißt keine aufwändige Programmierung, um Ihre Prozesse abzubilden. Und wenn das nicht reicht, sollte das System so modular sein, dass man zusätzliche Komponenten einfach „nachladen“ kann.

  2. Entsteht Ihr IoT-Geschäft auf der grünen Wiese oder erweitert es Ihr bestehendes Business? Wenn Letzteres der Fall ist, dann sollte Ihr IoT-System mit der übrigen IT-Welt in Ihrem Unternehmen sprechen können: Ersatzteilbestellungen zum Beispiel sollten ja in aller Regel einmal bei der Finanzbuchhaltung vorbeigekommen sein. Offene oder sogar zertifizierte Schnittstellen sind auch hier das A und O.

  3. Stellen Sie Industriegüter her? Haben Sie auch mal mit Ersatzteilen und Wartung zu tun? Dann wird Ihr neuer bester Freund im IoT-Neuland der „Digitale Zwilling„. Aber nur, wenn er auch industrietauglich ist: Er muss die Komponenten Ihrer Anlage detailliert abbilden können (am besten mit zugehörigem 3D-Modell), die aktuellen Parameter wie Software-Stände kennen und insbesondere Veränderungen nach Wartung oder Umbau dokumentieren können.

Die Anbindung von Geräten ist ehrlich gesagt meist nur eine Frage von Fummelarbeit, in aller Regel aber kein grundsätzliches Problem. Schritt für Schritt setzen sich hier Standardprotokolle für die Machine-to-Machine (M2M)-Kommunikation wie MQTT (Message Queuing Telemetry Transport) oder OPC/UA (Unified Architecture) durch und machen allen Beteiligten das Leben leichter.

Also: Probieren Sie es mit einem Proof of Concept einfach aus! Wenn Sie dabei auch noch auf die drei Prüfsteine achten, sind Sie gut im Rennen. Dann stehen Ihnen die Möglichkeiten von „Analytics“, „Big Data“, „Data Driven Processes“ oder „Predictive Maintenance“ offen.

Agil scheinen oder agil sein?

Als ich vor Jahren das erste Mal von Agilität hörte, hatte ich zunächst den Eindruck, Prozesse und Regeln sollten über Bord geworfen werden, um volatile Anforderungen auf wundersame Weise im Handumdrehen realisieren zu können. Ich konnte mir nicht vorstellen, wie das funktionieren soll: Agilität klang für mich nach unerfüllbarem Wunschkonzert.

Erst als unser damaliges Software-Entwicklungsteam anfing nach Scrum zu arbeiten – mit mir als Product Owner und begleitet durch einen erfahrenen Scrum Master – habe ich mich mit dem Thema ernsthaft auseinandergesetzt.

Ich lernte, dass Agilität nicht Chaos bedeutet, sondern ganz im Gegenteil lautete die

1. Lektion: Disziplin

Agiles Vorgehen hat Regeln. Die lernten wir in der vorausgehenden Scrum-Schulung. Vor allem aber legte unser Scrum Master uns sehr ans Herz, die Scrum-Regeln strikt einzuhalten, statt sie so auszulegen, wie es für uns am sinnvollsten erschien. Was ich gelernt habe: Agilität ist kein Laissez-faire, sondern bedarf eines sehr disziplinierten Vorgehens, das nur funktioniert, wenn es konsequent gelebt und nicht nach Bedarf verbogen wird.

2. Lektion: Der Sinn

Feste Rollen und Rituale sind nützlich. Wir hatten sie für Scrum zwar gelernt, aber echtes Verständnis wuchs erst nach und nach über das Coaching und die Fragen des Scrum Masters. Beispielweise wenn sich im Lauf eines Sprints herauskristallisierte, dass mehrere der vereinbarten User Storys nicht erreicht werden würden. Alle Teammitglieder versuchten natürlich, ihre eigene Aufgabe bestmöglich zu erledigen. Das hätte dazu geführt, dass die einzelnen User Storys zu nur 70% fertig werden würden. Der Scrum Master stellte zur Diskussion, stattdessen ein oder zwei User Storys für den Sprint zu verwerfen und bei der Fertigstellung der anderen mitzuhelfen. Was wir gelernt haben: Ergebnisorientierung und Fokussierung auf ein gemeinsames Ziel machen das Teamwork produktiver und die Teammitglieder zufriedener.

3. Lektion: Teamgeist

Je mehr wir den Sinn der Regeln, Rollen und Rituale verinnerlichten, desto effizienter wurden die Projekte. Das Team wuchs immer stärker zusammen und es entwickelte sich nicht nur ein gemeinsamer Fokus darauf das Ziel zu erreichen, sondern echter Zusammenhalt. Wo vorher Kollegen Unverständnis über die Arbeit der jeweils anderen geäußert hatten oder sich in Schuldzuweisungen übten, wusste nun jeder im Team, was die anderen machten und warum. Man half sich gegenseitig nach Kräften und vertraute einander immer mehr. Und da nachhaltiges Lernen vor allem über positive Emotionen funktioniert, war dies der Punkt, an dem wir wirkliches Verständnis für Agilität entwickelten.

Am Ende wurde mir klar, dass Agilität erst durch das Zusammenspiel von Regeln, Menschen und Motivation entsteht. Die hinter den Regeln stehenden agilen Werte zu verstehen, ist entscheidend. Sonst besteht die Gefahr – durch das Herausgreifen oder Zurechtbiegen einzelner Regeln auf die eigenen Bedürfnisse – mit dem agilen Ansatz zu scheitern.

Was nicht heißt, dass man die agilen Frameworks nicht anpassen oder selektiv anwenden darf. Aber erst, wenn man sie verstanden hat.

UX geht alle an

Beruflich wie privat ist die Arbeit am Computer sowie der Umgang mit Apps und anderen digitalen Werkzeugen ganz alltäglich geworden. UX sorgt für eine möglichst einfache Bedienung und stellt die „User Experience“ in den Fokus. Das bedeutet, dass digitale Produkte intuitiv und verlässlich sind sowie im besten Fall auch noch Spaß machen.

Warum ist eine UX-Strategie wichtig?

Ziel von UX ist es, die Schnittstelle zwischen Mensch und Maschine so komfortabel wie möglich zu gestalten.Dazu gehören das „Look & Feel“ des jeweiligen Tools. Ebenso wichtig ist, dass der Anwender die Bedienung möglichst schnell erlernen und effizient arbeiten kann. Um das zu erreichen, hilft es, den Anwender schon im Entwicklungsprozess stärker zu berücksichtigen.

Insbesondere bei der Entwicklung komplexer Produkte, wie zum Beispiel Unternehmenssoftware, sind häufig viele Personen an der Entwicklung beteiligt – und die setzen alle unterschiedliche Schwerpunkte. Dadurch ist es häufig schwer, die „User Experience“ im Entstehungsprozess kontrolliert zu beeinflussen.

Mithilfe einer UX-Strategie erhält die Gestaltung der „User Experience“ eine Richtung. Es wird ein Fokus gesetzt, sodass Produktmanager, Konzepter und Entwickler wissen, was in puncto UX wichtig ist und wohin die Reise gehen soll.

Aber wie sieht so eine UX-Strategie aus?

Strategie heißt zunächst, ein Ziel zu formulieren und eine Vorstellung davon zu entwickeln, mit welchen Maßnahmen und Mitteln dieses Ziel erreicht werden soll. Dabei können etablierte Frameworks helfen. Das UX Strategy Blueprint des UX-Veteranen Jim Kalbach ist so eine Hilfe. Wir haben es im CONTACT UX-Team erfolgreich verwendet, um eine UX-Strategie für das Unternehmen zu formulieren. Im Juni berichtete ich auf der UXStrat Europe Konferenz von unseren Erfahrungen mit dieser Methode und sprach auch im UXStrat-Podcast darüber.

Im Rahmen der Strategie werden viele Neuerungen angestoßen – zugunsten einer besseren UX. Zum Beispiel das erste Mal ein Mockup-Tool verwenden und Bedienkonzepte erproben, lange bevor die erste Zeile Code geschrieben wird. Das ist zunächst anstrengend, aber es lohnt sich!

Wie lebt man UX? Und was hat das mit mir zu tun?

Eine UX-Strategie allein bringt erst mal nichts – man muss sie leben. Dazu ist es sinnvoll, bereits im Entstehungsprozess der Strategie auch Kolleginnen und Kollegen aus der Entwicklung und dem Produktmanagement einzubinden.

Eine gute „User Experience“ wird an allen Ecken und Enden gestaltet, vom Plattform-Baustein bis zur Formularkonfiguration im Kundenprojekt. UX-Spezialisten können aber nicht überall mitwirken. Wir gehen voran, geben die Strategie vor und unterstützen – in der Umsetzung ist dann jeder gefragt. Unterstützung heißt bei uns, den Kolleginnen und Kollegen die richtigen Werkzeuge, Ressourcen und Beispiele an die Hand zu geben. So kann jeder selbstständig zu einer State-of-the-Art-UX beitragen und ein positives Nutzungserlebnis für den Anwender entwickeln.

Und wenn am Ende leistungsfähige und anwenderfreundliche Produkte herauskommen, profitieren alle davon.