Fehler Nummer 1 – Was ist mein Use Case?

Das Projektbudget ist eingeplant, drei Studien zu IIoT-Tools sind angefertigt und die neue Abteilung mit Schwerpunkt Digitalisierung ist gegründet. Aber was soll eigentlich digitalisiert werden? Schritt Eins, die Anwendungsfälle müssen klar definiert sein. Es reicht nicht aus „Daten Analyse“ oder ähnliche Buzzwords als Anwendungsfall niederzuschreiben und loszulegen. Insbesondere beim Start neuer Projekte ist es enorm wichtig klar definierte Zielsetzungen zu haben. Buzzwords und ähnlich schwammige Begriffe dienen uns später dazu unsere Anwendungsfälle in Kategorien zu gliedern. Die Anforderungen an einzelne Kategorien wiederum leiten sich dann aus den spezifischen Bedürfnissen der einzelnen Use Cases ab.

Wie wird ein Use Case definiert?

Hierfür gibt es sicherlich kein genormtes Vorgehen, trotzdem würde ich immer empfehlen die Anwendungsfälle gemeinsam mit unterschiedlichen Fachabteilungen zu definieren (z.B. Instandhaltung, Qualität, Intralogistik etc.). Es bietet sich an mit der Hilfe von Kreativtechniken Probleme aus den jeweiligen Bereichen zu sammeln, zu strukturieren und zu bewerten (Hier ein paar Tipps). Das notwendige Fachwissen aus den Bereichen IT, Data Science und Cloud sollten natürlich nicht fehlen.  Klar ist, nur da wo Probleme sind kann auch optimiert werden. Ein guter Use Case hat immer eine User Story, diese gliedert sich in drei Fragen: Wer? Was? Warum? Beispielsweise: Ich als Instandhalter, möchte, vor dem Ausfall der Pumpe notifiziert werden, umso schneller reagieren zu können und die Anlagenverfügbarkeit um 2% zu steigern.

Das Vorgehen Zusammengefasst

  1. Use Cases sammeln und priorisieren
  2. Kategorien bilden
  3. Anforderungen ableiten
Google Podcast
Apple Podcast

 

 

 

 

Fehler Nummer 2 – Protokolle sind nicht alles, Payloads sind der Schlüssel

Allseits bekannt ist das Problem unterschiedlicher Protokolle in einer heterogenen Fertigungslandschaft. Gremien und Konsortien probieren dem entgegen zu wirken und schaffen Standards für die Greenfield Szenarien von morgen und IIoT- bzw. Industrie 4.0 Gateways etablieren sich immer mehr am Markt, um die Bedürfnisse der aktuellen Brownfield Welt abzudecken.

Aber Protokolle sind ungleich Payloads. Man kann sich das so vorstellen wie in einem Loriot Sketch. Mann und Frau sprechen die gleiche Sprache, glauben sich zu verstehen, tun es aber nicht. Ich kann aber in einer Bar in Shanghai sitzen und trotz Sprachdefizit Bier bestellen, denn Payloads sind der Schlüssel.

Payloads sind die Nutzdaten, die innerhalb einer Übertragungseinheit, übertragen werden. Nehmen wir MQTT (Message Queuing Telemetry Transport) als Beispiel (Hier klicken für Erklärungen zu MQTT). Ein Sensor publisht die aktuelle Temperatur auf das Topic „Temperatur“. Der Client, ausgestattet mit einer Software für Auswertungen, hat sich auf diesem Topic subscribt und erhält die Nutzdaten „21“ vom MQTT Broker. Ist der Payload nun nicht vorher definiert worden, also Sensor und Software haben sich auf ein Format geeinigt wie Temperaturwerte darzustellen sind, können unsere Nutzdaten zwar von unserer Software empfangen werden aber nicht verarbeitet. Protokoll und Payloads müssen in Industrie 4.0 Projekten immer zusammen betrachtet werden.

Fehler Nummer 3 – Gefangen im Proof of Concept (PoC)

Es gilt grundsätzlich: „Starten > Planen“! Dennoch, für einen erfolgreichen PoC ist es wichtig die Phase nach dem PoC zu bedenken. Anderenfalls gilt das Industrie 4.0 Projekt nicht als erfolgreich, auch wenn alle funktionalen Anforderungen erfüllt sind. Ich unterscheide hier nicht zwischen Proof of Concept, Protoype oder Pilot auch wenn das natürlich formal nicht korrekt ist. Während des Proof of Concepts sind mindestens folgende Aspekte zu betrachten:

  • Skalierbarkeit der Software
  • IT-Bebauungsplan/Architektur
  • Software-Lebenszyklus
  • Schulungen für Endbenutzer und Helpdesk-Unterstützung
  • Zeit- und Ressourcenplan für den RollOut des neuen Systems
  • Sicherheitskonzept
  • Datenschutzkonzept

Fehler Nummer 4 –  On-Premise schützt mein Know-How

Das Know-How muss geschützt werden! Kann das nur On-Premise geschenen? Meine Antwort lautet: Nein! Die Cloud wird immer weiterwachsen und viele On-Premise Szenarien verdrängen oder zumindest verändern. On-Premise Szenarien scheinen kurzfristig für fertigende Unternehmen der sichere Hafen zu sein, denn alle Daten bleiben im eignen Haus. Dabei ist schon lange klar On-Premise ist nicht automatisch sicher, auch hier müssen entsprechende Sicherheitskonzepte immer mitbetrachtet werden. Der primäre Grund für das langfristige Wachstum von Cloud-Szenarien sind die Kosten. Es ist langfristig schlicht viel günstiger Cloud Szenarien zu nutzen. Sicherheit darf keine Ausrede für Unternehmen werden den anstrengenden Veränderungsprozess zu starten.  Cloud-Technologien, Sicherheit und Schutz des Know-Hows schließen sich mit den richtigen Konzepten nicht aus. Wer Cloud richtig nutzt spart Geld, ist schneller und innovativer.