Practice

Black Box IoT?

Who wants to buy a pig in a poke? Especially when you are entering completely new territory with it… The first stroller, for example: you are already aware that you need it, but the decision between a small pack format or the bicycle trailer combination is more difficult.

The last time I bought a baby carriage was some time ago (now I am an expert in buying skateboards). But if you’re just about to make a choice, I recommend a dark model, because you can’t see the dirt so clearly.

An IoT system is usually not as sensitive to dirt, but its selection is all the more complex. Especially since many companies are breaking new ground with it and can already despair of the selection of the right criteria.

Here I have two good news for you. First: Which IoT solution fits is easy to try out. A Proof of Concept is a very good way to test a solution without major risks before you decide on a system. And secondly, as much as IoT offers new opportunities, smart business processes are based on good old business virtues:

Are you sure what your IoT business will look like and that it will stay that way for a long time? Probably not. IoT is a very volatile market where a lot is happening right now. So your IoT system needs to be responsive and best adaptable by the business department itself. The keyword behind this is “low code”, which means no time-consuming programming to map your processes. And if that’s not enough, the system should be so modular that you can simply “reload” additional components.
Does your IoT business emerge on the greenfield or does it expand your existing business? If the second is the case, then your IoT system should be able to talk to the rest of the IT world in your company: Spare parts orders, for example, should generally have passed through financial accounting once. Open or even certified interfaces are the most important thing here as well.
Do you manufacture industrial goods? Do you also have to do with spare parts and maintenance? Then your new best friend in IoT new territory becomes the “Digital Twin”. But only if it’ s also suitable for industrial use: it must be able to map the components of your system in detail (preferably with the corresponding 3D model), know the current parameters such as software statuses and, in particular, be able to document changes after maintenance or conversion.

To be honest, the connection of devices is usually only a question of fiddling, but usually not a fundamental problem. Step by step, standard protocols for machine-to-machine (M2M) communication such as MQTT (Message Queuing Telemetry Transport) or OPC/UA (Unified Architecture) are gaining acceptance and making life easier for everyone involved.

So: Just try it out with a Proof of Concept! If you also pay attention to the three touchstones, you’re in the running. Then the possibilities of “Analytics”, “Big Data”, “Data Driven Processes” or “Predictive Maintenance” are open to you.

Being agile or appearing agile?

When I first heard about agility years ago, I first had the impression that processes and rules should be thrown overboard in order to miraculously realize volatile requirements in the twinkling of an eye. I couldn’t imagine how this would work: agility sounded to me like an unattainable wish concert.

Initially, when our software development team started to work with Scrum – with me as the product Owner and guided by an experienced Scrum Master – I seriously dealt with the topic.

I learned that agility does not mean chaos, but quite the opposite was true:

Lesson 1: Discipline

Agile approach has rules. We learned them in the previous Scrum training, but most of all our Scrum Master advised us to strictly adhere to the Scrum rules instead of interpreting them in the way that seemed most appropriate to us. What I learned: Agility is not a laissez-faire, but requires a very disciplined approach that only works if it is lived consistently and not bent as needed.

Lesson 2: The Sense

Fixed roles and rituals are useful. We had learned them for Scrum, but real understanding grew gradually through coaching and the questions of the Scrum Master. For example, when in the process of a sprint it turned out that several of the agreed user stories would not be reached. Of course, all team members tried to do their own job in the best possible way. This would have meant that the individual user stories would only be completed to 70%. The Scrum Master, however, put up for discussion the idea of discarding one or two user stories for the sprint instead and helping to complete the others. What we learned: Results orientation and focusing on a common goal make teamwork more productive and team members more satisfied.

Lesson 3: Team Spirit

The more we internalised the meaning of the rules, roles and rituals, the more efficient the projects became. The team grew more and more together and not only a common focus on achieving the goal developed, but real cohesion. Where previously colleagues had expressed a lack of understanding for each other’s work or had blamed each other, everyone in the team now knew what the others were doing and why. They helped each other to the best of their ability and trusted each other more and more. And because sustainable learning works above all through positive emotions, this was the point at which we developed a real understanding of agility.

In the end it became clear to me that agility only comes about through the interaction of rules, people and motivation. Understanding the agile values behind the rules is crucial. Otherwise there is the danger – by picking out or bending individual rules to one’s own needs – of failing with the agile approach.

This does not mean that the agile frameworks must not be adapted or selectively applied. But you have to understand them first.

Design Thinking – Hype oder Hilfe?

Ende Januar veranstaltet CONTACT gemeinsam mit The Dark Horse, eine der führenden und bekanntesten Design Thinking Agenturen, einen exklusiven Design Thinking Workshop.

Der Hintergrund: Neue Technologien wie IoT, 3D-Druck und Virtual Reality, serviceorientierte Geschäftsmodelle und die Digitale Transformation überhaupt stellen herkömmliche Angebote infrage. Das Hasso-Plattner Institut schreibt dazu: „Design Thinking … avanciert heute zu einer ganz neuen Art, den Menschen in Bezug zur Arbeit zu sehen, das Konzept der Arbeit zu denken und zu fragen, wie wir im 21. Jahrhundert leben, lernen und arbeiten wollen. Die Strahlkraft von Design Thinking besteht darin, neue und überraschende Formen der kreativen Zusammenarbeit zu ermöglichen. Wir-Intelligenz ist das neue Schlagwort, Kollaboration wird die Grundlage für ein neues Arbeitsbewusstsein.“

„Ganz neue Art zu denken“, „21.Jahrhundert“, „Wir-Intelligenz“. Bei solchem Drang ins Esoterische gibt brand eins so richtig Contra. Individualistisch geprägte Gesellschaften sind weniger erfolgreich als kollektivistische? Kreativität gedeiht am besten in Gruppen? Nicht unbedingt, und da kann man schnell mal was falsch verstehen. Und dann noch: Der Erfolg hängt von der Exzellenz in unterschiedlichen Disziplinen ab, also holt man diese Disziplinen mit ins Boot? Produkte mache ich für Kunden und – Revolution! – frage sie also nach ihren Bedürfnissen? Als wenn es Ideen wie Human Centered Design nie gegeben hätte.

Ignorieren wir lieber die Marketingstrategen und betrachten Design Thinking ganz pragmatisch:

Der Ausgangspunkt: komplexe Produkte und Systeme in einem eher unbekannten Terrain
Die unbedingte Ausrichtung an meine Kunden untere Berücksichtigung technischer und wirtschaftlicher Zielvorgaben
Die enge Zusammenarbeit der unterschiedlichen Disziplinen, die einen Beitrag leisten
Iteratives, auch spielerisch/experimentelles Vorgehen und lernen aus Feedback und Fehlern.

Design Thinking ist also wie gemacht für die Herausforderungen der Digitalen Transformation. Deswegen sind wir mit dabei.