Klaus Mochalski
Hallo und herzlich willkommen zu einer neuen Episode von OT Security Made Simple. Ich bin Klaus Mochalski, Gründer von Rhebo. Mein Gast heute ist Madeleine Mickeleit von IoT Use Case. Erzähl uns doch mal Madeleine, was du bei IoT Use Case machst und mit welchen Problemen ihr euch dort so im Alltagsgeschäft beschäftigt.
Madeleine Mickeleit
Ja, sehr gerne. Und hallo Klaus. Vielen Dank für die Einladung heute. Ich freue mich sehr, mit dabei zu sein. Ich bin Madeleine, Gründerin und Geschäftsführerin von IoT Use Case aus Berlin. Wir haben Ende 2019 angefangen, und uns interessiert vor allem die Praxis und wie IoT wirklich in der Umsetzung funktioniert. Dafür betreiben wir eine Plattform, wo wir Lösungsbeispiele zeigen, die in der Praxis wirklich schon valide im Einsatz sind, mit einem Business Case dahinter. Und wir betreiben eine Community, wo man sich auch austauschen kann zu den Best Practices.
Klaus Mochalski
IoT Use Case. Also IoT ist ja ein sehr breit gefächertes Feld. Wir beschäftigen uns hier im Podcast vor allem mit dem Thema OT Security. OT, dazu zähle ich auch immer den Bereich IoT, also den Industriebereich der IoT. Und da haben wir auch hier im Podcast schon über Security-Herausforderungen gesprochen, zum Beispiel wie man große Flotten von Geräten, von technischen Geräten wie zum Beispiel Batteriespeichern gegen Cyberangriffe schützt. Was sind denn so die Szenarien, die ihr dort im Bereich speziell OT Security bisher gesehen habt?
Madeleine Mickeleit
Ja, also in jedem Bereich. Aber man könnte ja sagen, dass Security fast schon so ein Querschnittsthema ist, was so horizontal in jedem Projekt ein Stück weit mit drin ist. Das heißt, wir haben fantastisch viele Projekte, wo das immer ein Baustein ist. Und wir kennen es natürlich aus dem Rhebo-Umfeld. Ihr macht zum Beispiel die Anomalieerkennung in Netzwerken. Das ist natürlich auch ein sehr wichtiger Punkt, der in vielen Projekten auch mit involviert ist.
Gerade im KRITIS-Umfeld, wo viele Betreiber dann auch zum Beispiel Netzwerke-Anomalien erkennen wollen, um einfach Angriffe vorherzusehen, die man vielleicht so noch nicht kannte. Und in jedem Projekt steckt immer ein Teil Security. Aber die Ausprägungen sind auch immer ein bisschen unterschiedlich. Aber man sollte es natürlich im besten Fall immer mitdenken, was natürlich nicht immer getan wird. Aber ja, in vielen Projekten, die wir kennen, ist das immer ein Baustein davon.
Klaus Mochalski
Höre ich doch gerne. Weil es eigentlich immer wieder ärgerlich ist zu sehen, wie aufwendig und auch teuer das manchmal ist, Security nachträglich in bestehende Anlagen einzubauen. Das sehen wir vor allem im Industriebereich, wo wir mit zum Teil 10, 20 Jahre alten Bestandsanlagen konfrontiert werden. Umso ärgerlicher wäre das in so einem relativ neuen Bereich wie IoT, wenn das nicht von Anfang an mitgedacht wird, denn nie kann ich es günstiger und effizienter machen, als das gleich mit einzuplanen.
In dem Sinne hatten wir in der Vorbereitung darüber gesprochen, wie man so die Use Cases, die speziell ihr beobachtet habt, wie man die klassifizieren und kategorisieren kann. Das Feld ist sehr breit und es wird häufig so als catch all phrase genommen. Aber es ist ja tatsächlich sehr, sehr vielgestaltig. Wie kann man die aus deiner Sicht kategorisieren und klassifizieren, und wie hilft das dann auch den Anwendern und Kunden?
Madeleine Mickeleit
Um vielleicht auf den ersten Teil, was du gerade gesagt hast, nochmal einzugehen. Ich glaube, was sehr, sehr besonders bei IT-Projekten ist, ist, dass man am Anfang noch gar nicht so genau weiß, was eigentlich am Ende kommt, was vielleicht noch in Zukunft kommt und ob das dann vielleicht bestimmte Daten oder auch Geräte und Maschinen sind, die man vernetzt. Und demnach entstehen da auch gewisse Lücken. Aber vielleicht kommen wir gleich noch mal zu.
Klaus Mochalski
Security kommt immer. Das ist das Thema, was man, glaube ich, nicht aus den Augen verlieren darf. Egal was man baut. Security ist immer ein Thema.
Madeleine Mickeleit
Ja, genau. Da bist du jetzt der Experte. Aber das vielleicht so vom Projekt selber, womit wir uns beschäftigen und wie dann auch das Thema Security immer mit hinein spielt. Wir haben uns die letzten Jahre tausende Projekte angeschaut, und ich selber spreche fast pro Tag mit fünf, sechs verschiedenen Betrieben. Das sind häufig produzierende Betriebe, aber auch Betreiber von Kritischer Infrastruktur.
Und viele Betriebe setzen ja quasi verschiedene Use Cases um. Für mich ist ein Use Case – ich kann vielleicht mal so ein Beispiel bringen: Wir haben gerade so ein neues Thema reinbekommen. Da geht es um klassisches Condition Monitoring. Den Begriff kennt erstmal jeder, aber ganz konkret geht es hier zum Beispiel um die Erkennung von Bruch. In dem Fall geht es um sogenannte Energieketten, die im Einsatz sind bei einem Hafenbetreiber von bestimmten Kränen. Und diese Energieketten führen zum Beispiel Kabel. Das ist im Endeffekt wie so ein Kanal dafür. Und hier geht es sozusagen darum, eine Brucherkennung durchzuführen, [aufgrund von] zum Beispiel Zug- und aber auch Schubkräfte. Und um das zu machen, schauen wir uns halt im Endeffekt bei uns in der Datenbank an, ob wir andere Kunden haben, die vielleicht ähnlich wie dieser Hafenbetreiber sind, diese Lösung schon mal so oder so ähnlich umgesetzt haben. Das heißt, wir schauen ein bisschen nach der Branche, ob es in der Branche schon bekannte Lösungen gibt, aber auch nach verschiedenen Kriterien.
Und genau da hängt dann im Endeffekt auch so ein bisschen dran, wie man das Projekt umsetzt. Also von der Datenerfassung, von der Datenübertragung, Integration, vom Thema Security, IT, OT, aber auch von der Datenanalyse. Und wir strukturieren sozusagen diese Projekte dahinter, um einfach auch den Nutzern zu helfen, zu sagen: Hey, das Projekt gab es so oder so ähnlich schon mal! Wir gucken dann halt bei uns in die Datenbank und können dann auch mit, sag ich mal, fertigen Produkten, Lösungen und Technologien helfen, die da schon mal zum Einsatz kamen. So oder so ähnlich. Ich hoffe, das war verständlich. Ein bisschen.
Klaus Mochalski
Genau da habe ich gleich eine Folgefrage. Natürlich ist das erstmal einleuchtend. Wenn ich mich als Betreiber einer Anlage, einer Infrastruktur mit einer IoT-Lösung für ein Problem wie das von dir beschriebene Kabelüberprüfungsproblem beschäftige, dass es dann natürlich sinnvoll ist, sich anzuschauen, wie haben das andere in ähnlichen Bereichen gelöst? Es sind natürlich sehr vielgestaltige Probleme, die ich mir vorstellen kann. Und da ist die Frage, wie kann ich denn jetzt diese Lösung kategorisieren, dass die auch wirklich hilfreich ist? Dass ich also Lösungen finde, die ausreichend nah dran sind, auch wenn es natürlich in dem Bereich vielleicht keine Lösung gibt.
Also, vielleicht gibt es keinen zweiten Hafen-Anbieter, der genau das Problem schonmal gelöst hat. Aber es gibt vielleicht einen Hersteller, der eine Fabrikhalle mit Robotern betreibt, und auch dort hat er ein Kabelverschleißproblem. Das haben wir so tatsächlich auch schon gesehen und da könnte man sagen, das ist vielleicht ähnlich genug. Wie macht ihr diese Kategorisierung, um dann wirklich den Mehrwert zum Kunden zu transportieren?
Madeleine Mickeleit
Ja, genau. Also im Endeffekt schauen wir uns erst mal das Projekt von oben an und wir haben dann verschiedene Kategorien. Also das eine ist der klassische Use Case, wo dann auch im Endeffekt der geschäftliche Nutzen mit einem Eurobetrag oder auch einem Nachhaltigkeitsaspekt vielleicht dahinter steht. Dann schauen wir uns den Asset oder das Asset an, also zum Beispiel das Gerät, die Maschine oder auch andere Devices, die da vernetzt werden, weil die auch immer ähnliche Eigenschaften mit sich bringen. Zum Beispiel: Ist dieses Asset in einer bestimmten Infrastruktur, also der Energiekette, statisch oder beweglich? Zum Beispiel beim fahrerlosen Transportsystem. Das ist ja ein bewegliches Asset. Da schaut man sich auch solche Kriterien an, bis hin zu den Daten, die ich vielleicht auch brauche. Also Datentypen. In welchen Intervallen muss das gesendet werden? Ist das Echtzeit, also harte Echtzeit? Oder muss ich das vielleicht einmal die Stunde, vielleicht sogar nur einmal im Quartal senden? Diese verschiedenen Informationen schauen wir uns an.
Und was auch ganz wichtig ist: der Kunde an sich. Also, wenn ich jetzt zum Beispiel einen Hafenbetreiber habe, ist nicht nur der Use Case ähnlich, sondern auch der Asset Type, aber auch die Kundenstruktur dahinter, also ähnliche Hafenbetreiber. Und da schauen wir uns dann eben an, welche Branchen es in diesem Segment gibt. Was ist die Persona dahinter? Ist das jetzt ein klassischer Maintenance-Fall oder zum Beispiel so was wie die Frage: In welchem Funktionsbereich tritt das auf? Ist das in der Logistik, in der Supply Chain? Da sind ganz viele verschiedene Kriterien.
Und am Ende schauen wir uns diese Kriterien an, um dann passende Lösungen zu finden. Und auch Technologien, weil nicht jede Technologie unbedingt Sinn ergibt. Wenn ich Datentypen oder Daten vielleicht nur sekündlich senden will und nicht in harter Echtzeit zum Beispiel. Da gibt es ja auch Unterschiede, welche Technologien ich vielleicht anwenden möchte.
Klaus Mochalski
Das heißt, wenn ich es korrekt verstehe, habt ihr gar nicht so ein formales Kategoriensystem, was vordefiniert ist, sondern ihr schaut dann eher, wenn ihr eine neue Anforderung habt, die von einem Kunden kommt in eurer Datenbank nach, indem ihr entsprechende Filter und Suchkriterien nutzt, ob es dort ähnliche Projekte gegeben hat, aus denen man entsprechend etwas lernen kann?
Madeleine Mickeleit
Genau, ähnliche Eigenschaften, die dann auch wiederkehrend sind, wo die Probleme dahinter auch wiederkehrend sind, wo man dann passende Lösungen dazu hat. Genau.
Klaus Mochalski
Du hattest jetzt über das Beispiel des Hafenbetreibers gesprochen. Wie war denn dort die Suche nach einem ähnlichen Fall? Seid ihr dort schon an dem Punkt, wo ihr tatsächlich auch ähnliche Lösungen identifizieren konntet, die dann helfen, um dieses Projekt effizienter zu gestalten?
Madeleine Mickeleit
Ich darf den Kunden jetzt dahinter nicht nennen. Aber es gibt natürlich verschiedene Hafenbetreiber, die da auch ähnliche Herausforderungen haben. Und genau in dem Fall haben wir mit einem Partner von uns zusammengearbeitet. Das ist die Firma Igus, die bauen diese Energieketten. Und da haben wir uns eben diese Hintergründe angeschaut und haben dann tatsächlich auch überlegt, wie kann man anderen Kunden, die ähnliche Probleme haben, da auch helfen?
Und bei uns ist es ja so: Wir haben durch die Plattform verschiedene Möglichkeiten, auch Nutzer, die das zum Beispiel bei Google suchen, auf die richtigen Lösungen zu bringen. Und deswegen ist unsere Idee dahinter, diese Informationen tatsächlich auch kostenlos auf einer Seite zur Verfügung zu stellen, wo man dann diese Informationen abrufen kann. Wir planen, die Plattform weiterzuentwickeln, dass wir gar nicht mehr in die Datenbank schauen müssen, sondern dass Nutzer einfach ähnlich wie im eCommerce [suchen können] – wenn man einen weißen Adidas Sneaker mit blauen Streifen sucht, dann landet man ja auch auf einer Seite, wo man halt diese Produkte findet. Und so ähnlich geht das im IoT auch. Nur halt ein bisschen komplexer. Daran arbeiten wir entsprechend.
Klaus Mochalski
Das könnte ich mir tatsächlich super vorstellen. Das heißt, wenn ich selbst ein IoT-Problem lösen möchte, dann kann ich euren – man könnte es auch IoT Genius nennen – fragen, der dann sagt: Diese Kunden haben ähnliche Probleme gehabt. Und dann kann ich mir dort mindestens Inspiration, vielleicht auch direkte Hilfe holen.
Madeleine Mickeleit
Ja, genau. So nach dem Motto: Andere Kunden kauften auch… und so. Das ist halt im B2C-Business ein bisschen einfacher. Im IoT ist es halt einfach eine Stufe komplexer, aber es geht. Also wir haben mittlerweile echt Use Cases, die sind so klar und so wiederkehrend, da muss man echt nicht bei Null anfangen. Also das wird noch richtig spannend die nächsten Jahre, was man daraus machen kann.
Klaus Mochalski
Wenn wir jetzt mal zurückkommen zu Sicherheitsanforderungen. Die stehen ja häufig in den Anforderungen eher hinten und werden häufig als notwendiges Übel betrachtet. Weil erstmal geht es natürlich um die konkrete Funktion, die ich zur Verfügung stellen möchte, und das ist ja selten eine Security-Funktion. Sondern da geht es eben um Prozessoptimierung, um Erfassung von Daten, Werten, die ich vorher nicht erfassen konnte. Oder wie in diesem Falle hier, die Fehleranalyse von Dingen, die sich der Analyse vorher entzogen haben, weil ich nicht an den konkreten Stellen vor Ort mit entsprechender Quantität und Qualität diese Daten erheben konnte.
Trotzdem spielt aber, wie ich am Anfang ja schon gesagt hatte, Security immer eine Rolle. Kann man mit eurem Ansatz der Klassifikation auch dabei helfen, Security effizienter einzubauen? Weil das größte Gegenargument, was wir immer hören, ist, dass Security teuer ist und dass es keinen Wert produziert. Dass es sozusagen seinen Wert erst entfaltet, wenn aus dem hypothetischen Angriff ein echter Angriff wird – und ich tatsächlich mit dieser Lösung, die ich an Bord habe, zum Beispiel einen Anlagenausfall verhindern kann. Wenn der aber nicht auftritt, dann sind es erstmal nur Kosten. Könnt ihr dort helfen? Solche OT-Security-Funktionen effizienter in Projekte von Anfang an einzuplanen?
Madeleine Mickeleit
Also wir können natürlich dadurch, dass es ja relativ konkret wird, durch die Kategorien auch sagen – und da finde ich jetzt auch mal deine Einschätzung spannend – weil man ja zum Beispiel so Zug- und Schubkräfte hat, wo der Hersteller, in dem Fall der Energiekettenhersteller, erwartet, dass bestimmte Werte auftreten. Was ist denn, wenn die jetzt gehackt wird? Also wenn sich jemand da draufschaltet und genau diesen Datensatz angreift und Werte produziert, die eigentlich abnormal sind, wo man halt sagt, das läuft jetzt irgendwo hin, da sollte es auf jeden Fall nicht sein. Und die Standard-IT das vielleicht auch mit dem bisherigen Prozess nicht so realisiert.
Da können wir natürlich auch sagen: Hey, andere Nutzer haben hier eine Lösung von Rhebo eingesetzt, weil man eben weiß, dass solche Daten oder Datentypen angreifbar sind. Das spielt bei jedem Projekt eine Rolle, wo man natürlich auch eine Empfehlung aussprechen kann, weil es ja fantastische Beispiele aus eurem Kunden-Netzwerk gibt, die sowas [gemeint ist ein OT-Sicherheitsmonitoring mit Anomalieerkennung] einsetzen und demnach halt am Ende auch Kosten sparen, wenn sowas auftritt. Da würde mich deine Einschätzung interessieren.
Klaus Mochalski
Das ist tatsächlich ein Mehrwert, den wir unseren Kunden auch immer mit präsentieren. Weil auf den ersten Blick, wenn man an Cyber Security denkt, dann denkt man ja an die klassischen Hackerangriffe, die uns gerade beschäftigen. Wo es zum Beispiel eine Ransomware-Attacke gibt, wo mir Daten verschlüsselt werden. Und das kann ja durchaus auch im Industriebereich im OT-Bereich passieren, weil ich eben auch da mittlerweile zum Beispiel Windows-Systeme im Einsatz habe, die da anfällig sind und wo ich natürlich auch Daten auf Festplatten habe, die davon potenziell betroffen sein könnten. Das passiert auch häufig. Diese Art von Angriff, die du beschreibst, dass jetzt tatsächlich jemand gezielt OT- oder IoT-Daten manipuliert, um einen Prozess zu stören, das wird tatsächlich weniger als Herausforderung gesehen.
Und genau das können wir zum Beispiel mit der Anomalieerkennung, die wir anbieten, abdecken, weil wir versuchen nicht zu identifizieren, ob es sich bei einer Aktion, die wir in der Kommunikation beobachten, um eine gutartige oder bösartige Aktion handelt. Sondern wir schauen erstmal, ob die von dem normalen Bild, was wir von der Kommunikation oder vom Betrieb der Anlage haben, abweicht. Und das, was du beschreibst, dass sozusagen dort Werte übertragen werden, die deutlich höher oder niedriger ausfallen als im Tagesgeschäft, oder es werden auch diese Werteübertragungen deutlich häufiger oder viel, viel seltener durchgeführt, dann sind das auch Anomalien, die im ersten Schritt vielleicht nicht unbedingt Security-relevant sind, aber natürlich genau auf so eine Manipulation hindeuten können.
Ich würde da noch einen Schritt weiter gehen. Security bietet tatsächlich auch häufig einen Mehrwert, den man im ersten Schritt nicht sieht. Wir haben über die Jahre beobachtet, dass bei den Kunden im OT-Bereich – also wenn wir zum Beispiel digitalisierte Fertigungsanlagen anschauen, aber auch zum Beispiel die Steuerungssysteme bei Betreibern Kritischer Infrastruktur, wo wir zum Teil noch ältere Anlagen haben, die digitalisiert werden – die Kommunikationsinfrastruktur, das Netzwerk zu einem ganz wichtigen Element der Infrastruktur wird. Und du hattest eingangs von Condition Monitoring gesprochen. Das ist ja häufig auch so Machine Condition Monitoring. Also ich überwache meine Anlagen. Und wir haben das [mit dem Netzwerkmonitoring mit Anomalieerkennung] tatsächlich erweitert und haben gesagt: In solchen digitalisierten Infrastrukturen wird plötzlich das Netz, was ich für die Kommunikation brauche, um die Geräte zu steuern, eigentlich zu meiner wichtigsten Maschine. Deswegen haben wir dieses Condition Monitoring versucht zu erweitern auf Netzwerk Condition Monitoring. Und da aber nicht nur mit dem Fokus auf Security, denn wie wir alle wissen, kommt es relativ selten zu spezifischen OT-Security-Vorfällen. Es gab auch in den letzten Jahren sehr sehr wenige Angriffe gezielt auf die OT-Infrastruktur. Aber wir überwachen natürlich auch im Tagesgeschäft, ob es hier Abweichungen in den Kommunikationsmustern gibt.
Und da komme ich jetzt zurück zu deinem Hafenbeispiel. Wir hatten hier einige Kunden, die mit Kabelbrüchen zu kämpfen hatten – speziell im Industriebereich. Da werden die Kabel bewegt, durch enge Kanäle gezogen und da kommt es immer wieder mal zu mechanischen Störungen. In anderen Bereichen wurde viel mit Glasfaser gearbeitet. Die deutsche Automobilindustrie arbeitet zum Beispiel viel mit Glasfaser in der Fertigung. Und diese Glasfaser wird unter diesen harschen Bedingungen mit Temperaturwechseln über die Zeit schlechter. Dann erhöht sich die optische Dämpfung, und das musste gemessen werden. Und auch da haben wir unsere Lösung eingesetzt, um frühzeitig zum Beispiel Übertragungsfehler oder Übertragungsaussetzer zu erkennen, die auf solche Verschlechterungsprozesse hindeuten. Und damit konnten wir unseren Kunden zeigen, dass man mit so einer Security-Lösung eben auch einen echten operativen Mehrwert für die tägliche Überwachung schaffen kann.
Madeleine Mickeleit
Ja, mega spannend. Also daran sieht man ja auch, dass dieser Use Case der Brucherkennung auf jegliche Branchen und auch Funktionsbereiche anwendbar ist. Weil das Beispiel war jetzt aus dem Hafen. Das gilt natürlich genauso für die produzierende Fertigung oder, wie du schon sagst, egal wo diese Kabel beispielsweise liegen, der Use Case ist immer der gleiche und die Lösung theoretisch auch. Nur, man fängt gefühlt immer – oder viele vielleicht – bei Null an. Und da [haben wir] einfach die Empfehlung, auf vorhandenes Wissen aufzusetzen. Das ist ja auch das, was wir tun, wo wir dann ein bisschen konkreter herangehen können, weil wir wissen, dass der Use Case schon mal gelöst wurde.
Klaus Mochalski
Als du den Use Case beschrieben hast, kam mir auch gleich dieser Gedanke. Ja, natürlich kann ich jetzt überall neue Sensorik einbauen und versuchen, diese Kabelbrüche zu erkennen. Aber häufig lohnt es sich auch erst mal zu schauen: was habe ich denn schon an Daten vor Ort, die heute nicht genutzt werden, die ich aber dafür verwenden kann? Und bei dem von mir eben beschriebenen Problemen der Kabelstörung in einer Fertigungsanlage haben wir tatsächlich dann gar keine [neue] Sensorik eingebaut, sondern haben mit unseren Sensoren, die [bereits] an anderer Stelle verbaut waren, zusätzlich die Dämpfungswerte der Industrie-Switches abgefragt. Und es stellte sich nämlich heraus, dass [das Unternehmen] alle Informationen, die es dafür braucht, schon hat, dass die aber nicht ausgewertet wurden. Und da wäre es sozusagen kommerziell mehr als kontraproduktiv gewesen, neue Sensorik, neue IoT-Sensoren zu installieren. Sondern wir konnten einfach mit den existierenden Sensoren diese Datenquelle anzapfen und nutzbar machen.
Häufig sind es eben solche Lösungen, die dann Projekte auch kostengünstiger, effizienter gestalten. Und da kann ich mir vorstellen, dass so eine Plattform wie eure, wo es diesen Austausch gibt, Wunder wirken kann und am Ende eben diesen Mehrwert auch den Kunden zur Verfügung stellt.
Madeleine Mickeleit
Ja, genau. Die Infrastruktur ist natürlich entscheidend. Und ob ich dann ein Greenfield oder typisch Brownfield habe – will ich retrofit machen oder habe ich die Daten schon? – das ist dann vielleicht noch etwas, was man sich im Detail einfach anschauen muss, wie man es lösen will. Oder kaufe ich ein komplett neues Produkt, das es fertig löst? Das Problem gibt ja verschiedene Wege dafür vor.
Klaus Mochalski
Absolut. Abschließend, wenn ich jetzt als Betreiber einer Infrastruktur ein Problem habe, wo ich denke, eine IoT-Infrastruktur in irgendeiner Form ist die Lösung dafür. Was sind so eure ersten Schritte, wie ihr so einem Kunden helft?
Madeleine Mickeleit
Also im Endeffekt ist es ein Ersttermin. Das ist so eine Art Sparring, wo wir uns einfach anschauen, was ist der Use Case oder die Use Cases. Und dann schauen wir im Endeffekt, wer hat das so oder so ähnlich schon mal gelöst. Das heißt, wir setzen hier auf einen Standard bzw. vorhandenes Wissen auf, anstatt quasi von vorne anzufangen. Wir schauen uns bewährte Lösungen und Standards an und würden dann im Endeffekt auch eine Empfehlung aussprechen, wie man da vorgeht.
Bei uns ist es [dann] so, dass wir an dieser Stelle eher einen Kontakt vermitteln. Wir würden einen Termin machen mit einem anderen Anwender [aus der Community], der es schon mal so oder so ähnlich gelöst hat. Also kein Marktbegleiter, sondern einfach jemand aus einer anderen Branche, der diesen Use Case – beispielsweise was du mit der Glasfaser gesagt hast – schon mal hatte und das so gelöst hat. Da kann man auf Wissen aufbauen. Oder wir würden einfach auch schauen, wer von unseren Partnern aus dem Ökosystem das entsprechend lösen kann. Wir durchsuchen dann parallel die Datenbank, gucken uns die Kategorisierungen an, ob wir da die Ähnlichkeiten schon erkennen. Das bereiten wir dann entsprechend für den Termin vor.
Und dann hat man im Endeffekt als Ergebnis eine Liste an Lösungen und auch Ansprechpartnern. Entweder zum Best Practice Sharing mit anderen Anwendern oder einfach auch Partner, die da helfen können, diesen Use Case umzusetzen.
Klaus Mochalski
Super. Für die Zusammenfassung kann ich eigentlich nur sagen, dass ich jeden, der ein neues Projekt hat, ermuntere, sich an euch zu wenden und zu schauen, ob es dort in eurer großen Datenbank und wachsenden Datenbank, [identische] oder ähnliche Use Cases schon gibt. Als wir im Vorfeld der Episode darüber gesprochen hatten, dass wir über Kategorisierungen und Klassifikationen reden wollen, dachte ich erst: Oh, das klingt jetzt sehr trocken.
Aber der Mehrwert ist offensichtlich und das liegt ja auf der Hand, dass das eine gute Idee ist. Deswegen kann ich das allen unseren Hörern, die versuchen, in diesem Bereich ein Projekt zu starten, warm ans Herz legen. Und ich kann dir jetzt nur danken für den Beitrag. Das war auf jeden Fall sehr spannend und ein spannender Ausblick auf dieses Feld. Lass uns gerne mal austauschen über diesen konkreten Use Case, über den wir gerade gesprochen haben.
Madeleine Mickeleit
Ja, voll gerne. Also vielen Dank, dass ich heute mit dabei sein durfte. Wenn ihr Interesse habt, meldet euch gerne. Vielleicht kann man mein LinkedIn-Profil einfach in die Shownotes packen und dann freue ich mich auch auf den Kontakt. Und vielen Dank für die Session heute.
Klaus Mochalski
Vielen Dank, Madeleine, dass du heute da warst.
Madeleine Mickeleit
Danke dir. Mach's gut. Ciao. Tschüss.
Folgen Sie IoT Use Case unter https://iotusecase.com/de/.
Vernetzen Sie sich mit Madeleine Mickeleit unter https://de.linkedin.com/in/madeleine-mickeleit.
