Das ist Teil 2 von 2. Gemeinsam mit Daniel Kocot und Florian Rademacher spreche ich über Daten als Produkt. Ihr hört Ein Geek kommt selten allein, den Podcast rund um Digitalisierung. Hallo und herzlich willkommen zu Ein Geek kommt selten allein, dem Podcast mit Geeks, für Geeks und alle, die es werden wollen. Falls du die Folge vor zwei Wochen noch nicht gehört hast, würde ich dir empfehlen, da erstmal reinzuhören, weil hier der zweite Teil ist. In dieser Folge spricht der Geek mit. Mein Name ist Daniel Kocot, ich bin Head of API Consulting bei der codecentric und beschäftige mich mit Daten und auch mit APIs natürlich. Mein Name ist Florian Rademacher, bin seit November Consultant bei der codecentric, habe mich vorher viel in der Wissenschaft getummelt und tue jetzt ähnliche Dinge bei der codecentric, beschäftige mich aber ebenso wie Daniel auch beim Kunden mit Daten. Wir hatten ja alle schon zusammen das Vergnügen. Also reden wir über Daten und nicht einfach nur so über Daten, sondern speziell über das ganze Thema Daten als Produkt. Wir haben auf einmal sehr, sehr viele Stakeholder. Also gerade wenn wir über eine gesamte Datenstrategie für ein komplettes Unternehmen reden, haben wir nicht nur von Management bis hin zu operativer Ebene, haben wir alle, die einmal durch den Stack durchgehen, sondern wir haben auch eine richtig große Breite. Und die müssen wir jetzt halt alle irgendwie mitnehmen. Und zumindest dafür, dass wir es schaffen, verschiedene Abteilungen, also Konsumenten und Bereitsteller, aber auch das Management, also auch das Doing mitzunehmen, haben wir uns ja mal zusammengesetzt und haben diese Data Product Canvas, haben wir das ja genannt, haben wir mal ein Data Product Canvas entworfen, um zu helfen, dass man in dieser Kommunikation strukturiert alle wichtigen Bereiche umfasst und nichts vergisst, wenn man versucht zu kommunizieren, was bauen wir da eigentlich gerade? Oder wofür wollen wir eigentlich gerade eine Governance erstellen? Dass man sagt, wo kommen meine Daten eigentlich her? Wer sind meine Lieferanten? Was tue ich damit? Wie speichere ich die? Wem liefere ich sie aus? Über welchen Weg? Und was machen die dann ultimativ damit? Und was kostet das vielleicht sogar noch? Vor allem auf einer Flughöhe, wo ich nicht sofort in die Technik gehen muss und wo ich mir noch keine Gedanken über sehr feingranulare Governance machen muss, wo ich aber vielleicht schon sehe, hier könnte es eventuell Probleme geben, da sollten wir mal drüber sprechen. Finde ich persönlich hilfreich, gerade auch um unterschiedliche Menschen an einen Tisch zu bringen, weil auf dieser Flughöhe kann immer noch jeder mit jedem reden, weil man nicht unbedingt super Spezialwissen braucht und das dann hinterher feiner gliedern und dann zum Beispiel in Richtung von einem Software-Design oder ähnliches gehen. Also sorry, dass ich da unterbreche, aber ich wollte nochmal diese Flughöhe an der Stelle betonen, auf der man sich da befindet und dass es wichtig ist, dass ich auf so einer Flughöhe bin, damit ich unterschiedliche Menschen an einen Tisch holen kann. Du kannst da gerne direkt weitermachen. Ich wollte nämlich fragen, was eure Erfahrung ist. Ihr habt das ja auch schon in Kundenkontexten verwendet. Und die Frage ist, welche Dinge macht es leichter? Wobei hilft es tatsächlich? Für mich, was ich da an Erfahrung gesammelt habe, ist es tatsächlich, dass es hilft, dass man sich strukturiert wirklich Gedanken darüber macht. Erstmal die Struktur, das müssen wir doch explizit machen. Und dass man sich Gedanken darüber macht, was gehört denn jetzt eigentlich alles zu so einem Data Product? Worüber muss ich eigentlich nachdenken? Weil wenn ich das jetzt nicht strukturiert vor mir sehe und ich fange einfach mal an, von oben nach unten aufzuschreiben, dann fallen mir vielleicht wieder irgendwelche Dinge ein oder ich vergesse aber auch ganz viel. Also zum Beispiel diese Geschichte mit den Success-Factors, die da drin stehen in diesem Canvas. Also ich baue ja Datenprodukte nicht zum Selbstzweck, sondern ich baue sie ja eigentlich, weil sie einen Mehrwert schaffen sollen. Und es kann ja durchaus auch valide sein, dass wenn ich so ein Data-Product-Canvas baue, dass mir auf einmal gar keine Success-Factors einfallen oder Value-Propositions. Also was bringt mir das Ganze überhaupt? Kann ja sein. Und dann stelle ich vielleicht fest, okay, ist ein Datenprodukt, könnte relevant für uns sein, im Moment schafft es aber gar keinen Mehrwert in meinem Unternehmen, dann verwerfe ich es doch eigentlich. Verwerfe ich es doch erstmal oder stelle es erstmal zurück und schaue es mir dann irgendwann nochmal an. Besser dann irgendwie einen halben Tag oder vielleicht auch zwei Stunden mit diesem Data Product Canvas zu verbringen und das festzustellen, als wenn ich jetzt ein halbes Jahr Investor habe und stelle dann fest, ich habe jetzt ein Datenprodukt, das nutzt aber überhaupt niemand. Weil alle finden das SAP-System dann doch besser, weil das kennen sie schon seit 20 Jahren und das Data Product geht einfach an den Needs meiner Customer, also meiner Kunden, die vielleicht in meinem Unternehmen sind, an den Fachabteilungen einfach vorbei. Dann lieber zwei Stunden investieren und das feststellen als sechs Monate und das dann feststellen. Das fand ich sehr gut, dieses frühzeitige Feedback tatsächlich an der Stelle und das strukturierte Denken und Herangehen. Kleine Anekdote an der Stelle. Ich hatte mal ein sehr spannendes Datenstrategie-Projekt, wo wir auch Datenprodukte mehr oder weniger entworfen haben, wo es darum ging, Entscheidungen auf einer kommunalen Ebene zu treffen. Also wir bewegen uns in einem öffentlichen Raum. Und ultimativ war das eigentlich ein Produkt, wo Kommunalpolitiker mitentscheiden sollten. Stellte sich aber raus, nachdem wir das alles fertig gemacht hatten, Kommunalpolitiker in diesem Falle entschieden, aber eher opportun nach Wählergunst und es war gar nicht so wichtig, was in diesen Daten jetzt drin stand. Wenn sie eine Chance hatten, sich zu profilieren über die Wählergunst oder über die Taten in der Wählergunst, dann haben sie das gemacht. Ich habe übrigens Folgendes hier gemacht, die Schwimmbadöffnungszeiten habe ich übrigens geregelt oder ich habe uns das eingespart. Und je nachdem, was sie gerade brauchten, und da war das relativ egal, wie das Datenprodukt aussah, und das ist, glaube ich, auch super wichtig zu verstehen, ist es etwas, was ein technisch gutes Datenprodukt ist, was uns theoretisch irgendwie helfen kann, oder ist es eines, was in der Realität gebraucht wird? Deswegen diese Auseinandersetzung mit denen, für wen stelle ich eigentlich das Datenprodukt bereit und was machen sie dann damit? Nutzen sie diese Daten, um eine Entscheidung zu treffen oder nehmen sie diese Daten zur Kenntnis, um sie zu ignorieren, weil sie eine andere Agenda haben, weil das eigentlich nur noch nice to have ist. Und dann kannst du dir die Frage stellen, wie viel Aufwand setze ich da rein, wenn sie das eh nicht benutzen für ihre Entscheidung, sondern ihre Entscheidung trotzdem treffen würden. Dann reicht es ja, wenn ich mit sehr minimalem Aufwand nur mal gucke, ob ich so eine grobe Indikation hinbekomme, weil das ist nicht relevant. Ich komme ja aus dieser Spezifikations- und Beschreibungsecke dadurch, dass man das ja auch bei den Schnittstellen ja schon hat. Und da sehe ich einfach bei dem Canvas noch einen Mehrwert, weil ich kann gewisse Dinge da nicht beschreiben. Wenn die Spezifikation sie nicht hergibt, will ich sie da vielleicht auch gar nicht drin haben, wenn ich sie hinzufügen könnte, weil es einfach an der Stelle schon unpassend ist. Durch die Spezifikation ist es schon eigentlich technisch an der Stelle und der Canvas, dadurch, dass der halt auf einem Blatt Papier virtuell oder real stattfindet, ist das halt einfach nochmal eine andere Beschreibungsform, vor allem wo ich nachher auch ablege. Und ich packe ihn nicht in irgendeinen technischen Katalog, sondern ich habe es halt einfach, stupide gesagt, in einem Confluence oder in anderen Möglichkeiten zur Ablage halt einfach drin und kann sie da wiederfinden. Und das ist so für mich, wo ich sage, das ist ein weiterer Mehrwert. Ich muss es nicht machen, wenn ich in der Organisation oder Unternehmung schon mehr auf der technischen Ebene unterwegs bin, aber wenn ich Stakeholder dabei habe, denen der Technikbezug fehlt, ist das auf jeden Fall das dicke Plus dabei, das so zu machen auf dem Weg. Das habe ich jetzt auch in einem Projekt, haben wir das jetzt auch mal durchprobiert und es funktioniert einfach. Wir haben es ja hier auch auf dem Data Day verprobt, da waren ja auch Menschen aus verschiedenen Unternehmen tatsächlich dabei und wir haben ja Teams gebildet, die auch aus diesen Menschen dann zusammengesetzt waren und auch wenn die jetzt aus komplett anderen Branchen kamen, die konnten sich trotzdem über dasselbe Datenprodukt strukturiert unterhalten. Jeder irgendwie aus seiner Erfahrungsecke hatte vielleicht noch andere Aspekte, die da eine Rolle spielten. Weiß ich nicht, ob es Legal-Themen zum Beispiel dann sind, die auf einmal da vielleicht relevant werden könnten oder Compliance-Sachen. Also Dinge, die vielleicht ein Techniker nicht sofort auf dem Schirm hat. Kannst du trotzdem diese Leute an einem Canvas zusammenbringen und die können darüber sprechen. Genau, diese Strukturiertheit an der Stelle auch sehr hilfreich und dass ich es vor allem auch einsetzen kann, Sowohl für bestehende Datenprodukte, um sie zu analysieren, oder bestehende Datenmengen, die ich irgendwie habe, Datentöpfe, aber auch für neue Sachen. Es ist beides so ein bisschen. Es ist eine Analyse und ein Entwicklungstool eigentlich. Zumindest für beide Fällen ein sehr hilfreicher erster Schritt. Eine Kategorie gibt es ja nicht bei diesem Data Product Canvas und das ist Datenqualität. Da reden alle immer drüber und sagen, ich möchte gerne gute Daten haben, mit denen ich gute Entscheidungen treffen kann. Was fällt euch zum Bereich Datenqualität ein? Dass auch genau dasselbe gilt wie bei der Governance. Sehr viele verschiedene Aspekte, die ich wahrscheinlich über die Zeit irgendwie auch unter einen Hut kriegen muss, um wirklich hochqualitative Datenprodukte entwickeln zu können. Und ich muss mir aber auch bewusst werden, dass sich die Datenqualität auch immer davon abhängt, von den Daten, die ich habe. Also das kann ich mir auch verdeutlichen, wenn ich jetzt irgendwie ein KI-Modell auf 20 Datensätzen trainiere, dann ist das qualitativ wahrscheinlich schlechter, als wenn ich dasselbe mit 200 Milliarden Datensätzen oder noch mehr tue. Das wird wahrscheinlich für den Anwendungsfall schlechter. Ungenauer oder schlechter funktionieren und das gleiche gilt eben an der Stelle auch. Das ist die Frage, weil erstmal ist es ja quantitativ nur weniger und ich kenne solche KI-Modelle, wo ich dann mein Foto hochladen kann, aus zwei Bildern interpoliert ist oder aus 30 Sekunden Stimme, interpoliert ist auf einmal meine Stimme, das heißt also die Menge an Daten ist ja nicht unbedingt das Entscheidende. Bin ich, muss ich ehrlich sagen, bin ich zu wenig an der Stelle drin, was jetzt diese KI-Geschichte angeht, aber, ich würde jetzt mal voraussetzen, dass bei sowas, also wenn ich es jetzt wirklich von Grund auf neu trainiere Ohne dass ich irgendwelche vorgelagerten Mechanismen oder andere Inputs habe, ist es wahrscheinlich schon ein Unterschied, ob ich jetzt einen kleinen Datentopf habe oder einen sehr, sehr großen. Wenn ich jetzt natürlich schon irgendwie vielleicht ein Modell vortrainiert habe und das kann dann besonders gut mit wenig Daten umgehen, okay, geschenkt. Aber wenn ich wirklich vom Scratch starte an der Stelle, glaube ich schon, dass mehr Daten da besser sind. Aber du wirfst natürlich eine wichtige Frage auf, das gilt für mich bei Datenqualität und Datenprodukten eben auch, wenn ich sehr viele schlechte Daten habe, dann ist das vielleicht nicht so gut, als wenn ich die halbe Menge dafür sehr gute Daten habe. Das ist eben auch eine Einschätzung oder eine Analyse, die ich an der Stelle fahren muss, wie viel Datenqualität kann ich überhaupt erreichen. Und das Wichtige dabei finde ich auch, dass man das transparent macht. Also man kann ja durchaus sagen, das ist das Datenprodukt, 75% aller Fälle funktioniert sehr gut, aber in 25% aller Fälle müsste man vielleicht nochmal hinterfragen, was dabei rauskommt. Also so ein gesunder Menschenverstand. Sollte vielleicht dann immer noch vorherrschen, im Sinne von, dass ich vielleicht in meiner Fachabteilung, die die Daten auswertet, auch schon Erfahrungen gesammelt habe und wenn mein Bauchgefühl mir sagt, die Daten kommen mir komisch vor, dass man dann nochmal darüber wirklich nachdenkt oder eben auch mit dem verantwortlichen Team des Datenprodukts einfach darüber spricht. Und das ist ja auch wichtig bei diesen Datenprodukten, hatten wir jetzt schon mehrmals, Ownership, Verantwortlichkeit, ich weiß, wer mein Ansprechpartner ist und kann dann auch mal nachhaken. Also Kommunikationswege werden klarer, auch wieder ähnlich wie bei Microservices. Es ist ja nichts Neues. Also ich glaube halt einfach, dass Qualität, also bei Schnittstellen haben wir das ja auch, da spricht man ja auch mal von guten oder schlechten Schnittstellen. Ich glaube aber, das ist was Subjektives, weil du hast es ja schon gesagt, das Bauchgefühl, ich muss halt wissen, ist das meine Domäne, in der ich da unterwegs bin. Ich habe auch früher in Unternehmungen gearbeitet, wo es wirklich darum ging, hochqualitative Datasets zu bauen, um die dann der Öffentlichkeit wieder zur Verfügung zu stellen oder Drittanbietern zur Verfügung zu stellen. Und das war teilweise sehr viel Bauchgefühl bzw. Wissen der Mitarbeiter, die sich um diese Daten und deren Qualität gekümmert haben, sich darauf verlassen zu können, okay, wenn wir das jetzt so und so machen, passt das zu dem und ihr trägt zu unserer Datenqualität bei. Aber es ist was, ich glaube einfach was Subjektives, weil da gibt es ja keine Normengröße, die irgendwie sagt, das ist jetzt hier qualitativ hochwertig, sondern das muss ich ja für meine Organisation und Unternehmung grundsätzlich irgendwie schon definieren. Was ist denn da Qualität an der Stelle? Ja, das ist auch wieder dieses Thema explizit machen. Also wenn ich das interne Wissen meiner Mitarbeiter irgendwie externalisieren oder explizit machen kann und dadurch auch operationalisieren kann, dann sollte ich das auf jeden Fall tun. Und das ist ja auch ein Data Mesh Gedanke ist dieses Continuous Quality Monitoring. Das heißt, ich schaue auch wirklich. Ich möchte einen gewissen Qualitätsstandard für meine Daten einhalten und schalte Mechanismen ein, die das automatisch feststellen können, wenn meine Datenqualität abweicht. Das ist natürlich jetzt schon sehr fortschrittlich, wenn man an der Stelle einmal ist, dann hat man es meinen Augen auch schon geschafft. Aber bis dahin ist eben ganz, ganz viel notwendig von gucken, was für Daten habe ich, wie qualitativ gut sind diese Daten eigentlich schon? Und wie kann ich dieses Bauchgefühl aus meinen Mitarbeitern mit 30 Jahren und mehr Erfahrung rausbekommen, um daraus einen Mehrwert zu schaffen und dann die Datenqualität an der Stelle auch sicherstellen zu können. Also es spielt sehr viel Quantitatives rein, aber auch sehr viel Qualitatives rein. Mein alter Wortfetisch kommt da immer raus, wenn ich über Qualität spreche, weil eigentlich als alter Lateiner weiß man qualis qualitatis sagt Beschaffenheit. Also diese Subjektivität, die du angesprochen hast, Daniel. Also eigentlich gibt es Qualität nicht messbar, weil du sagst einfach nur, wie ist es beschaffen? Und ich glaube, was Leute im Unternehmenskontext brauchen von qualitativ hochwertigen Daten ist transparent. Also das heißt, sind die Daten frisch und aktuell? Sind die Daten vollständig? Wo kommen die her aus einer glaubwürdigen Quelle? Sind da alle Quellen drin? Habe ich aus allen Stores die Umsatzzahlen? Oder ist es nur aus irgendeinem Shop auf dem Land, wo irgendwie wenig Umsatz getätigt wird? Ich glaube nicht, dass diese Zahlen stimmen. Also das sind so die Dinge, die ja, wenn wir an Zahlen denken, wir müssen immer dran auch denken, Daten sind nicht immer quantifizierbar. Ist die Adresse eigentlich richtig? Also hat der seine Postleitzahl richtig geschrieben oder ist der Ort irgendwie richtig erfasst? Kann ich irgendwie ein Matching machen von zwei Kundendatensätzen, die ähnlich klingen, aber irgendwie doch nicht, aber ist es doch derselbe? Also da denke ich ja drüber nach. Wie kann ich eigentlich umgehen mit meinen Daten? Wie kann ich die Beschaffenheit angucken? Und habe ich Transparenz darüber drin? Und dann kann ich mich entlanghangeln und gucken, wie kann ich diese Daten sauber machen. Und ich glaube, man kann für ein Datenprodukt nicht irgendwie einen Aspekt, und jetzt kümmere ich mich um die Qualität gehen. Das ist so wie am Ende eines Softwareentwicklungsprozesses mal einen Qualitätstest zu machen. Oder am Ende, dann kannst du halt einen Abnahmetest machen. Du kannst gucken, haben wir das, was wir uns versprochen haben, am Anfang des Prozesses haben wir das eingehalten. Aber du kannst nicht am Ende Qualität rein definieren. Und deswegen bin ich immer so ein Fan davon, Qualität nicht explizit als einen Kasten irgendwo auftauchen zu lassen, mit das gehört jetzt dem Peter, der kümmert sich bei uns um Qualität, sondern die Qualität ist eben die Beschaffenheit, die wir im Prozess brauchen. Und wie gesagt, in der Unterscheidung auch mit Stimmen, Zahlen, aber auch was ist mit den nicht quantifizierbaren, nicht den Zahlinformationen, die wir haben. Wie wollen wir denn darauf Qualität messen? Genau, also dieser Transparenzgedanke spielt für mich da Da ganz wesentlich mit rein. Denn ich kann ja schon irgendwie die Beschaffenheit, was du gerade gesagt hast, kann ich ja schon bis zu einem gewissen Grad auch messen. Kann ja zum Beispiel auch sagen, ich hole jetzt aus einer externen Quelle, hole ich mir jede Nacht Daten ab und das hat jetzt mal letzte Nacht nicht funktioniert, weil vielleicht bei mir was ausgefallen ist oder die externe Quelle irgendwie ausgefallen ist oder whatever. Vielleicht habe ich da schon ein Fallback, vielleicht interpoliere ich irgendwelche Dinge, vielleicht fehlen die Daten aber auch schlicht und ergreifend. Dann kann ich das oder sollte ich das auch wieder im Self-Service-Gedanken bei so einem Data Mesh, wenn wir jetzt darüber reden, transparent machen. Einfach den Benutzern der Daten wirklich sagen, du kannst diese Daten benutzen, aber bedenke bitte, von letzter Nacht fehlen jetzt Datensätze. Dann kann die Person, die sich das anschaut, vielleicht auch aufgrund ihrer Erfahrung wieder einschätzen, okay, aber die Daten sind immer noch gut genug. Oder, okay, das ist jetzt schlecht, das heißt, wir müssen jetzt gucken, ob wir diese Daten noch irgendwie nachgeliefert bekommen, auch wieder das Team in dem Datamash ansprechen, also die Verantwortlichen für dieses Datenprodukt und gucken, wie man mit der Situation umgeht. Aber die Transparenz ist an der Stelle eben sehr, sehr wichtig. Bin ich bei euch. Jetzt sind wir im Unternehmenskontext. Da ist ja alles noch fein. Wir hatten gerade gesagt, wir bezahlen ja nicht für diese Datenprodukte. Aber dann bewegen wir uns ein Stückchen weiter und sagen so, unsere Daten, die wir haben, stellen wir bereit auf einem Marktplatz in irgendeiner Art und Weise. Beispielsweise vielleicht monetarisieren wir sie sogar, dass jemand uns dafür entlohnt, dass wir die Daten bereitstellen. Dann wird der Qualitätsgedanke natürlich auch mal so ein bisschen schwerwiegender, sage ich mal, weil ich bezahle etwas dafür und ich habe eigentlich auch wieder so eine Art Vertrag mit ich kriege etwas geliefert und ich hoffe, dass ich das bekomme, was ich gerne möchte. Lass uns so ein bisschen in das Thema Datenmarktplätze mal eintauchen. Ja, für mich ist es aktuell wie so ein Hype-Thema. Es kommt ja mit diesen Data Spaces auch hoch. Und im Endeffekt ist es wie bei den APIs auch schon. Vor Jahren haben wir über Portale gesprochen, Kataloge. Jetzt sprechen wir dort auch von Marktplätzen. Und es ist einfach eine Sichtweise auf Dinge, wie du schon gesagt hast, wir stellen was nach außen bereit, wo es eigentlich nur darum geht, es noch expliziter für Nicht-Techniker auch darzustellen, um klarzumachen, was kriege ich da eigentlich, wenn ich das ausliefere. Aber ich denke jetzt so, Datenqualität und... Verteilen von Daten. Also ich kenne auch. Branchen und Bereiche, wo es dann auch teilweise mit Fake-Daten halt entsprechend verteilt worden ist. Weil man nämlich nicht wollte, dass jemand weiß, dass man da sehr gut aufgestellt ist, um zu sehen, was so passiert im Markt, wenn man halt Daten einfach mal weitergibt. Das ist ja auch beim Marktplatz dann nicht unbedingt für jemanden ersichtlich, dass die Qualität irgendwie hoch ist, sondern du denkst halt einfach, Okay, das sind die Daten der Unternehmung, das geht um ganz bestimmte Bereiche, die sind irgendwie nicht so ganz deckungsgleich zu dem, was ich da mache, aber ich zapfe trotzdem mal diese Quelle an, weil ich will wissen, was die dort tun. Also so ein Marktplatz ist dann glaube ich die nächste Ebene, aber da ist halt immer noch nicht wirklich Qualität gewährleistet, außer du hast dann klar in der SLA-Vereinbarung drinstehen, dass das hochqualitativ sein soll, aber da wird sich auch glaube ich keiner so wirklich drauf einlassen. Deswegen ist Marktplatz, also diese Idee dahinter, weil ich sie halt aus dem Schnittstellen-Kontext ja sehr gut kenne, ist für mich so dieser nächste Step und das ist auch, glaube ich, noch relativ alles am Anfang. Also das ist, wir sehen es bei Container X, sehen wir da schon erste Bewegungen, da gibt es ja auch mit Confinity X einen Anbieter direkt schon für eine Lösung in Richtung Marketplaces. Aber das ist so ein Beginn, weil die Leute ja auch erstmal ein Gefühl dafür kriegen müssen, dass sie mit externen wirklich Vereinbarungen treffen, um dort Dinge zu tauschen. Das hat man ja heute nicht so wirklich. Naja, streng genommen gibt es das schon. Also wenn ich an The Status denke oder ich denke an klassische, ich laufe durch die Fußgängerzone und dann fragt mich jemand, mögen Sie diesen Müsli-Riegel lieber als den? Und dann gibt irgendjemand eine Studie bereit und sagt, wir haben tausend Leute gefragt, Netflix abonnieren die gerade alle? Und dann stellt Netflix mehr Engineers ein, weil die gesehen haben, da wurde sehr, sehr viel nachgefragt. Es wurden repräsentative Studien durchgeführt mit tausend Befragten. Das Prinzip der Datenprodukte kennen wir ja schon. Also du kannst Daten einkaufen in der Welt und das seit vielen, vielen Jahren. Auch bei Versicherungen, die jetzt Sterbetafeln sich angucken und schauen, wie lang leben Leute im Durchschnitt in dieser Region. Macht es Sinn, denen eine günstige Versicherung anzubieten oder auch Krankenversicherungen? Kriegen die alle bestimmte Krankheiten? Muss ich das ausschließen aus meiner Police beispielsweise? Deswegen finde ich das sehr spannend, dass wir eigentlich an einer Stelle, wo wir jetzt Datenmarktplätze im Internet machen, Meistens im Internet. So ein bisschen ignorieren, was wir schon kennen aus anderen Bereichen, nämlich dass Datenprodukte schon lange, lange, lange existieren, die sind nur über hemmsärmelige Wege werden die tradiert und du hast nicht eine API-Ökonomie, wo du sagst, du kannst das jederzeit, auch Sonntagnacht, wenn du das möchtest, einmal ganz kurz abfragen und im schlimmsten Fall musst du irgendwo einen Fax hinschicken und dann kriegst du drei Tage später die komplette Studie zugeschickt. Aber ganz neu würde ich nicht sagen, dass es das ist, oder? Nee, also das Florian hat es ja vorhin auch schon so gesagt, das ist ja alles, also das, was wir hier tun, ist ist ja nicht neu. Wir machen Dinge, die sind teilweise schon 20 Jahre oder gar noch älter und es wird immer so ein bisschen dargestellt, das ist jetzt neu, das ist der neueste Trend oder das macht man so. Nee, das ist einfach irgendwas, was in einer anderen Darreichungsform wiederkommt, einen neuen Namen bekommt und auch wie gesagt, da hat Marktplätze, das ist ja schon Sinn, die sind ja nicht neu. Irgendwie müssen ja auch zum Beispiel Daten zu Amazon gelangen. Wenn ich dort als Händler was ausstelle. Das heißt, der eine geht mich ja auch schon auf eine Art von Kontrakt, der vielleicht nicht so aussieht, wie wir es jetzt sehen in Richtung Data Contracts und Data Project Specifications, sondern da gibt es ja auch Vereinbarungen. Wenn ich mich daran nicht halte, kriege ich auch gewissen Ärger und muss gewisse Strafen vielleicht auch noch zahlen. Es ist halt alles irgendwie schon da, aber es kriegt halt jetzt irgendwie gerade so einen anderen Drive, weil es halt, in Bereiche reingeht, also ich sehe das aus meiner Schnittstellen, aus dem, was ich mit Schnittstellen mache, wir haben teilweise Daten über Schnittstellen geteilt, wo wir nicht wussten, ob das wirklich das ist, was wir dort teilen dürfen oder a teilen sollen, weil sich niemand für diesen Inhalt verantwortlich gefühlt hat, sondern da hat man einfach nach Gusto mal eben geteilt oder Beispiele, wenn man in SAP-Kontexte guckt, wo dann mal einfach Schnittstellen erstellt werden, die so 120 Elemente verteilen, wo man sich dann fragt, braucht jemand wirklich 120. Teile eines Datensatzes oder was braucht derjenige jetzt eigentlich? Also es ist, es bewegt sich in gewisse Richtung, aber es ist halt nicht neu. Also das ist, glaube ich, das Entscheidende. Ich finde den Data Marketplace oder Datenmarktplatzbegriff an der Stelle auch überfordernd. Zumindest wenn ich jetzt darüber nachdenke, ich bin jetzt ein Unternehmen und ich will jetzt Datenprodukte machen, dann sehe ich mich mit Begriffen konfrontiert, wie wie Data Catalog, Self-Service-Plattform, Data Product an sich sowieso als Kernbegriff, klar. Und dann kommt noch jemand und sagt, wäre auch noch gut, wenn du einen Datenmarktplatz machen würdest. An wie vielen Stellen oder für mich würde ich erst mal die Frage stellen, was ist denn ein Datenmarktplatz, den ich jetzt in meinem Unternehmen tatsächlich habe? Wie unterscheidet er sich von einem Data Catalog zum Beispiel oder meinetwegen von einem Data Mesh, wo ich über irgendwie Self Service mit Dingen abrufen kann? Dann ist der Unterschied, also brauche ich an der Stelle nochmal das Konzept des Marktplatzes oder reicht mir das in meinem Unternehmen vielleicht schon, wenn ich es nach außen gebe und ich will die Daten verkaufen, okay, kann ich es Datenmarktplatz nennen, aber für mich fehlt da so ein bisschen die Begriffsbestimmung. Die Beispiele, die du genannt hast, Stephan, finde ich alle gut, gebe ich dir vollkommen recht. Aber die Frage ist halt, wenn ich das jetzt in meinem Unternehmen einführe, will ich mir dann auch noch so einen Datenmarktplatz aufhalsen, wenn ich sowieso schon mit ganz vielem anderen Kram noch konfrontiert bin und vielleicht noch nicht mal weiß, was für Daten habe ich überhaupt, wie gut sind die, was kann ich damit überhaupt tun? Also ich finde an der Stelle diese Buzzwords, die reinkommen, auch sehr überfordernd und das ist das, was Daniel auch gerade schon sagte, das ist im Moment, formiert sich so diese Data Engineering Bewegung, das ist ja auch gut, dass sie das tut, aber die steckt in meinen Augen auch noch bis zu einem guten Grad in den Kinderschuhen, wenn es darum geht, Konzepte sauber zu definieren und vor allem sie auch auf eine Business-Ebene zu hieven. Also technologisch kann ich da sicherlich viel tun und kann ich mir aus meinem Datenprodukt vielleicht eine HTML-Seite generieren und das ist dann mein Datenkatalog. Okay, das ist schön, das ist eine Spielerei, die mir auch was bringt, ja, aber was bedeutet das auf meiner geschäftlichen Ebene? Was bringt mir das wirklich? Wo ist der Mehrwert? Und will ich mir da noch so einen Datenmarktplatz ans Bein binden? Ich glaube, das ist in den meisten Fällen überhaupt gar nicht notwendig. Plakatives Statement, aber... Würde ich jetzt mal so einschätzen. Ich komme wieder von den Wörtern. Und ich finde, eigentlich brauchst du nur den Datenmarktplatz. Ah, okay, ja. Und du brauchst keinen Data-Katalog, weil der ist nicht wertvoll. Siehste. Weil vielleicht ist das nämlich, das ist ein Gedanke, der mir gerade kam, vielleicht braucht man nur deswegen Governance, weil wir keinen Product Owner haben für unsere Daten. Weil, was du gesagt hast, Daniel, mit, wir wissen gar nicht, können wir das rausgeben, was sind das da genau für Daten, was bedeuten die, sind die qualitativ gut? Viele, viele Fragestellungen, die sich ein Produktmanager, der die Studie gemacht hat, nimmt man den Lolli oder den Lolli, das weiß der, das ist sein Ding. Also wie auch immer Produktmanager dann definiert ist. Aber es braucht diesen einen, diese eine Entität, die sagt, das gehört mir, ich vermarkte das, kriege vielleicht Geld dafür zurück, vielleicht kriege ich aber auch kein Geld, sondern andere Dinge dafür zurück. Und erst in dieser, ich habe es aufbereitet und in eine wertvolle Position gebracht, dann ist es ein Marktplatz, weil auf Marktplätzen werden in der Regel Produkte hin und her getauscht, die also einen bestimmten Wert haben in einem Kontext. Und Data Catalogs, das ist halt wirklich eine Vorstufe davon. Die ist gut, die braucht man auch irgendwie, um das zu finden, aber dann wäre vielleicht ein Modell, das man fahren könnte, dass man sagt, wir machen Data Product Owner, die benennen wir für verschiedene Datenprodukte, die wir haben und die können jetzt anfangen, ihr Datenprodukt zu machen. Ob die das mit dem Data-Warehouse-Team zusammen machen, ob die ein eigenes Team dafür brauchen, weil das sehr komplex ist beispielsweise oder wie auch immer. Aber das sind diejenigen, die sagen, okay, wir sehen den Wert von dem, was wir gerade bereitstellen. Muss man sich überlegen, wenn man weggeht von den Kernprodukten, sondern so Supporting-Produkte hat, also das Consulting, ach, das Consulting sage ich, das Controlling beispielsweise, wird ja Umsatzzahlen und andere Dinge nicht als Kern sehen. Die machen vielleicht eine Bilanz am Ende des Jahres oder dergleichen wollen die eigentlich machen und die anderen Dinge sind auf dem Wege. Trotzdem sind das wertvolle Dinge, die sie bereitstellen können. Das sind so Sub-Data-Products, die eher kleiner sind als das. Den Gedanken müsste man mal weitermachen, aber das Entscheidende für mich ist, Produkte liefern den Mehrwert, deswegen sind die Marktplätze ganz spannend und die Data Catalogs per se sind eigentlich für die Architekten und Engineers, die Sachen zusammenbauen werden. Würdest du denn für die erfolgreiche Einführung des Datenprodukt Gedankens immer ein Data Marketplace oder ein Datenmarktplatz als Endpunkt sehen? Also gehört der für dich immer dazu, in jedem Fall? Ich würde gerne ein Data Product Catalog haben. Ob das Marketplace ist, weiß ich nicht, aber dass ich sehen kann, welche Datenprodukte gebietet mein Unternehmen eigentlich mir selber und anderen Leuten an. Ich glaube, das ist halt das Problem, dieses Wording. Im Endeffekt, was ich gerade mache, weil ich halt seit Jahren in dieser API-Welt unterwegs bin und wir da ja auch mal diese Portale hatten, dann gab es einen Katalog, was ist der Unterschied zwischen Portal und Katalog? Keiner wusste es. Und ich habe dann halt irgendwann angefangen zu überlegen, okay, gibt es denn einen? Nein, es ist beides, an der Stelle ist es beides sogar das gleiche. Ich habe dann halt zwischendurch angefangen zu sagen, okay, das eine ist vielleicht mehr technisch, ein Portal ist für mich mehr technisch, da geht der Techniker rein, der will Self-Service, ein Katalog, da kann auch jemand zum Beispiel draufgehen, der nicht so technisch bewandert ist. Mittlerweile würde ich, weil Portal und Katalog relativ gleich sind, sagen, der Marktplatz ist für die, die daran interessiert sind zu schauen, was gibt es für Daten in der Unternehmung, die kommen vielleicht nicht aus einem technischen Background, sehen dann aber, ach guck mal, das kann ich über Schnittstellen abfragen, das wird mir hier einfach in so ein Dashboard gegossen, kann ich direkt draufklicken. Das ist dann schon wirklich dieser Mehrwert, der da auch beschrieben wird und so weiter und so fort. Weil das ist ja dann dieser Marktplatz. Und da bin ich bei Stephan, wie gesagt, es wird irgendwann nur noch diese Marktplätze geben. Ob die intern oder extern sind, wird dann, glaube ich, sogar unerheblich sein. Dann gibt es den einfach. Aber ist das für euch dann Synonym für Self-Service-Plattform? Könnte ich das alternativ sagen? Okay, weil darum ging es mir. Das ist so ein bisschen definitiv. Also du wirst über diesen Marktplatz irgendwas auslösen können, weil da wird ja auch ein rechter Management hinterstecken müssen. Vielleicht wirst du gewisse Sachen gar nicht sehen, weil du da keinen Zugriff drauf hast, aber es ist trotzdem ein Marktplatz aller Teile einer Organisation und was dann noch für Tricktechnik dahinter steckt, ist dann nochmal wieder ein ganz anderer Zettel. Okay, aber Unternehmen 1 wird es Datenmarktplatz nennen, Unternehmen 2 nennt es Self-Service-Plattformen und Unternehmen 3 hat vielleicht noch ein anderes Wort, aber es fällt alles so irgendwie auf oder geht auf dasselbe hin letztendlich. Das meine ich mit diesem, du siehst mir so viele Begriffe konfrontiert und teilweise überschneiden die sich oder meinen sogar dasselbe. Deswegen finde ich das schwierig, da immer noch mehr Buzzwords reinzuregen. Man muss mal sehen, was sich dann hinterher wirklich halten wird davon. Du musst es aber irgendwie benennen, dass du drüber sprechen kannst. Und ich glaube, das ist auch hier mit dem Data-Product-Canvas und dergleichen. Es ist halt notwendig, dass du sehr viel Alignment schaffst. Also, dass Leute ähnliche Dinge verstehen und ob du das über ein Vokabularen bekommst, dass die Leute das Richtige sagen, ob du über Ontologien nachdenkst oder, oder, oder. Du musst irgendwie diese Gleichheit schaffen in einer super heterogenen Stakeholder-Landschaft, wo wir eben nicht nur vertikal, sondern auch horizontal einmal komplett durch das Unternehmen laufen, weil diese Daten offensichtlich irgendwie überall drin stecken und vorher war das irgendwie nur das Nerd-Thema und solange du nur eine BI-Abteilung hast, die sich um Daten kümmert, ist es ja relativ beherrschbar. Ich kriege dann auch so Fragen gestellt wie, ist denn jetzt ein Dashboard ein Datenprodukt? Mhm. Und das würde ich so nicht sagen. Also ein Dashboard kann ein Datenprodukt sein. Ein Dashboard muss aber nicht ein Datenprodukt sein. Und das daran aufzuhängen, das zu feingranulat zu machen, das würde dich als Unternehmen auch killen. Also wenn du sagst, ich habe 428.000 Datenprodukte, weil ich so viele verschiedene Dashboards habe, das macht keinen Sinn. Die Diskussion hatten wir auch bei einem Kunden, wo es dann in Richtung Enterprise Architecture auf einmal losging, wo dann gesagt wurde, ja, wenn ich das jetzt mal so runterbreche, haben wir theoretisch 100.000, 3.000 Datenprodukte. Wo sich dann alle natürlich in dem Call angucken und sagen, das sind ja keine Datenprodukte wir. Glauben das nicht. Das sind Schnittstellen was auch immer das dann an der Stelle sein kann also es ist so ein bisschen, das hast du jetzt auch gerade gesagt, das ist auch das was wir in Projekten immer mehr gerade machen ist wirklich mit Glossaren zu arbeiten und wirklich zu sagen okay, was bedeutet denn dieser Begriff gerade in der Situation, in der wir unterwegs sind verstehen wir alle das gleiche drunter oh nein, dann müssen wir vielleicht mal eine Definition finden, die kostet uns jetzt vielleicht mal eben 30 Minuten, aber die schreiben wir dann dahin und damit ist klar, wir meinen mit diesem Begriff genau das. Das ist das Datenprodukt für den Bereich, in dem wir gerade unterwegs sind. Und nein, wir reden nicht über Datenkontrakte, weil die Teil des Datenproduktes sind. Und das ist, glaube ich, gerade diese große Schwierigkeit. Wir haben super viel Wording. Wie immer super viel Missverständnis. Und das wird wiederum Jahre dauern, bis sich das Ganze aufgelöst hat. Wir haben super viele Bewegungen gesehen. Wir haben ganz lange Big Data gemacht. Aber kein Mensch weiß bis heute, was Big Data eigentlich ist. Früher haben die Leute gelacht, wenn man gesagt hat, eine Million Datensätze. Kommen wir nicht hin. Heute sind es viel, viel mehr und viel, viel höhere Zahlen. Aber keiner spricht mehr von Big Data in dem Moment, sondern das ist dann einfach so gesetzt. Das macht man dann einfach an der Stelle. Auch da wieder, weil wir jetzt schon öfter gesagt haben, wir benutzen eigentlich Dinge, die man in der Informatik schon sehr lange kennt und die sich bewährt haben. Das gemeinsame Sprache finden, der im Domain Driven Design ubiquitous language, so eine allgegenwärtige Sprache, das kann ich über ein Glossar definieren, die sich am besten auch im Quellcode irgendwie wiederfindet und so, dass wir alle über das Gleiche reden. Genau, also das ist glaube ich hier sehr wertvoll und dann heißt es am Ende vielleicht Self-Service-Plattform oder es heißt Daten-Marktplatz, aber es heißt auf jeden Fall das eine Ding in meinem Kontext und da verstehen alle dasselbe drunter. Ja, Sprache, eine gemeinsame Sprache finden, da zuckt es bei mir so. Die finden wir nicht mal mit Bayern, die sagen, Gendern ist das Schlechteste, was man machen kann. Also diese gemeinsame Sprache, ich erinnere mich an den Beginn meiner Karriere, bedingt auch sowas Technisches. Also wir sind im Bereich Datensemantik. Was bedeuten die Daten eigentlich? Und das ist total wichtig. Ich habe in Contact-Centern gearbeitet, jetzt sowohl telefoniert als auch die Reportings gemacht. Und erst eine der Kernfragen, wie bei Umsatz, ist die Frage, ab wann wartet eigentlich der Call? Dann hast du ja ganz oft diese IVAs, also diese Interactive Voice Recognition Sachen, wo du dann einen Sprachcomputer hast, der fragt dich, möchten Sie mit einem Agenten sprechen, drücken Sie die 24. Und dann ist die Frage, du bist ja schon in der Warteschlange, wo du das tust. Aus Kundensicht könntest du sagen, du wartest schon. Aber rein technisch bist du noch nicht im Warten, weil du tust ja noch was. Du wählst die 24 noch aus. Natürlich nicht die 24, weil kannst du nicht tippen, aber ihr versteht den Punkt, den ich da machen will. Mhm. Und dann ist natürlich, wenn ich gucke, wie lange hat dieser eigentlich gewartet, eigentlich nur ein Teil der Wahrheit. Weil ich müsste wissen, wie lange hat der gebraucht, bis der zum Agenten kam. Ist wieder was ganz anderes. Und wenn ich das als Wartezeit tituliere, also mein Umsatz im Kontext, der heißt Wartezeit, und er hat 20 Sekunden gebraucht. Davor ist er aber erst mal 30 Minuten durch so eine IVA, weil er da irgendwie Kreise gedreht hat. Hat das völlig andere Bedeutung. Also wie lang ist die Interaktion des Kunden mit mir als Service-Dienstleister? Ist eigentlich die Frage, die ich mir stelle. Aber die verschiedenen Abteilungen geben andere Antworten darauf. Und deswegen musst du verstehen, was bedeuten diese Daten so sehr. Was ja auch in Ordnung ist. Also deswegen meinte ich ja, du musst es, also kontextuell musst du halt eine Bedeutung festlegen. Und das kontextuell kann halt sein, Abteilung A interpretiert es eben anders als Abteilung B, ist sich aber auch darüber bewusst und ist vielleicht auch für diesen Case jetzt okay. Schreibe ich jetzt eine Software, die die eine Metrik braucht und eine Software, die die andere Metrik braucht und mache das transparent, dann ist das ja in Ordnung. Worauf ich einfach nur hinaus wollte ist, es gibt sehr viele Buzzwords, Buzzwords, die sind verfallene, Big Data und weiß ich nicht. Ich sollte mir einfach nur in meinem Unternehmen oder in meiner Abteilung oder was für einem Kontext oder Team oder wo auch immer ich unterwegs bin, einfach mir im Klaren darüber sein, dass wir alle wirklich über dasselbe sprechen und es im Zweifelsfall auch einfach irgendwo aufschreiben. Also das ist das, worauf ich da an der Stelle hinaus wollte. Jetzt haben wir drei verschiedene Perspektiven am Tisch. Wir haben so die Schnittstellen-Variante, wir haben die DDD-Variante, wir haben den, der einfach Wörter gut findet und aus Kundensicht guckt. Wie kommen wir jetzt konstruktiv dahin, dass wir Unternehmen helfen können, auf dem richtigen Weg die ersten oder die weiteren Schritte zu machen? Was sind so die Erfolgsfaktoren, wo ihr sagt, das müssten wir aus meiner Sicht mit Unternehmen tun, damit sie zu einem Ziel kommen, dass am Ende ein Datenmarktplatz steht und damit alle erfolgreich mit Daten ein besseres Geschäft machen können? Erstmal miteinander reden. Wir haben jetzt über dieses Data-Product-Canvas gesprochen. Wirklich Leute an den Tisch holen und erstmal darüber sprechen, was für Vorstellungen hat man überhaupt und wie sieht eigentlich die Realität aus. Und ich glaube, da kann so ein Canvas bei helfen, das mit einem geringen Aufwand in kurzer Zeit trotzdem zu einem guten Ergebnis zu kommen, auf dem man aufbauen kann oder wo man am Ende vielleicht auch sagt, da brauchen wir eigentlich alles noch gar nicht oder der Aufwand ist jetzt noch zu groß, müssen wir noch abwarten. Stichwort KI, wo viele eben zurückhaltend sind und sagen, da müssten wir KI für einsetzen, aber warten wir mal lieber noch, weil wir sind uns noch unsicher, das Risiko ist uns zu hoch, der Invest ist uns zu hoch, ja vollkommen okay. Aber wirklich miteinander sprechen, eine Bestandsaufnahme machen mit einem leichtgewichtigen Ansatz. Und dann eben schauen, wohin die Reise geht. Vor allem auch so eine Frage stellen, wie, wenn es denn am Ende in Richtung eines Datenmarktplatzes geht, baue ich das selber oder nehme ich Sachen, die es schon gibt von Anbietern? Weil gerade in diesem Datenbereich tut sich ja technologisch sehr, sehr viel. Und es gibt sehr große Anbieter, die sehr gute Angebote haben. Das ist dann vielleicht auch immer eine Frage. Also kaufen oder bauen würde ich an der Stelle auch immer sehr kritisch hinterfragen, weil bauen, glaube ich, brauche ich sehr viel Erfahrung, nicht nur aus Data Science Bereichen und ich muss mir auch darüber im Klaren sein, wie gut sind meine Daten. Ich kann nicht so schnell experimentieren, all diese Dinge spielen da glaube ich eine Rolle. Jetzt habe ich weit vorne angefangen und weit hinten aufgehört und Daniel, du kannst bestimmt die Mitte füllen. Kann ich bestimmt, weil wir ja im Endeffekt seit Jahren ja diese ganzen Schnittstellen machen, und wir haben immer gemerkt, okay das ist eigentlich problematisch, weil wir können diese Frage vorher nicht beantworten das ist genau was du mit dem Canvas angesprochen hast, weil das ist nicht passiert sondern hat einfach nur jemand gesagt, ja ich brauche da was und das muss jetzt rüber und, wie ihr das am besten dann in einem ganz bestimmten Format und ich glaube ganz einfach, dass man wirklich wie gesagt, erst mal damit anfängt, bevor man überhaupt in Richtung von Schnittstellen denkt oder Integration, whatever, sondern dass man wirklich zurück auf diese, sozusagen mit den Daten wirklich anfangen zu gucken, was haben wir überhaupt da? Du hast so schön Bestandsaufnahme gesagt und dann wirklich zu gucken, wo geht die Reise hin? Und make or buy oder was wir da alles an Möglichkeiten vorfinden. KI, ja, nein. Und dass man wirklich sich viele Fragen einfach beantwortet und das auch in einer etwas größeren Runde macht oder halt vielleicht auch aus der Sicht der nicht klassischen Enterprise-Architektur, also aller Elfenbein, sondern wirklich überlegt, okay, wo wollen wir denn als Unternehmung hin? Und ob jetzt dieser Datenmarktplatz das Ziel ist oder ob man einfach nur sagt, man will Teil dieser Bewegung, dieser Economy sein, die dort entsteht. Da gibt es ja auch ganz viele Begrifflichkeiten, die einem da über den Weg laufen, um halt entsprechend data-driven oder was auch immer zu sein. Ich glaube, das Wichtigste ist einfach wirklich zu gucken, dass man wirklich auf den Daten anfängt und wirklich überlegt, okay, was bringt mir das, mit wem kann ich das teilen und wirklich diesen Canvas als Startpunkt nimmt, um es nicht zu technisch zu machen. Weil das ist das, was ich sagen kann, wenn es zu technisch wird, wird es nicht schön und dann wird es auch immer schwierig, da wieder rauszukommen am Ende. Vielleicht ist das auch schon ein Punkt in dem Bereich, dass man seine Erwartungen vielleicht eher etwas niedriger ansetzt und wirklich sich als ein Ziel auf dem Weg setzt, setzt, ich will meine Daten überhaupt erst mal verstehen. Also ich will jetzt nicht sagen, ich brauche jetzt in, weiß ich nicht, einem Jahr brauche ich ein KI-Modell, das folgendes tut und das meinen Umsatz auf magische Weise verdoppelt, sondern, dass ich vielleicht wirklich erst mal mir bewusst mache, ja, ich möchte mit meinen Daten etwas Sinnvolles tun, nein, ich weiß im Moment noch nicht, was das sein könnte. Ich schaue mir das erst mal an und beantworte dann die Frage, bin ich schon an einem Punkt, wo ich meine Daten gewinnbringend einsetzen kann oder Oder was muss ich eigentlich tun, um überhaupt dahin zu kommen? Und dann auch sich eben bewusst zu sein, dass die Antwort auch durchaus sein kann, ich muss noch sehr viel tun, um meine Daten nutzbar zu machen. Aber alleine diese Erkenntnis ist ja schon an sich sehr wertvoll, weil dann habe ich mal den nächsten Schritt, den ich gehen kann. Also das wäre vielleicht an der Stelle auch nochmal hilfreich, weil viele wirklich damit strugglen, was für Daten habe ich überhaupt? Wie gut sind die? Wie passen die überhaupt zusammen? Und auch so Begrifflichkeiten auflöst, wie alle reden über das Konzept Kunde. Was ist denn überhaupt ein Kunde? Was macht den aus? Was wollen die? Also solche Dinge. Ich glaube, das wäre sehr hilfreich an vielen Stellen und vor allem diesen KI-Hype vielleicht da nicht sofort zu erliegen. Mein Lieblingsthema in dem ganzen Kontext ist das Thema Data Literacy, weil alle Daten haben wollen, aber was ist, wenn wir die Daten tatsächlich haben? Können wir damit umgehen? Also wissen wir, was wir damit tun? Das ist für mich eines der zentralen Themen, mit dem man alles hebt und angeln kann in einem Unternehmenskontext. Aber auch der Teil, der mir persönlich am meisten Spaß macht, muss ich gestehen. Also einfach, weil das eine sehr menschliche Komponente ist, die sehr viel Impact hat und wo man viel, jetzt kleiner Exkurs, wenn man Richtung Nonaka, Takeuchi, Wissensspirale, Explizierung von Wissen nachdenken würde, wo man eben Arbeit machen kann, wo man sagt, das, was du eigentlich weißt, machen wir jetzt doch mal klar und transparent. Und aber auch eine Weiterbildung natürlich, weil Data Literacy mit Daten umgehen können, zu verstehen, welche Daten sind vielleicht inkomplett, welche Daten sind vielleicht wertvoll, um sie anzuwenden, wenn wir über die Marktstudien nachdenken zum Beispiel, repräsentative Umfragen, was bedeutet das denn? Also kann ich von den Daten direkt auf die Aussage schließen? Es gehört für mich alles in diesen Bereich Data Literacy mit hinein. Habt ihr zum Schluss irgendein Lieblingsthema, wo ihr sagt, das ist eigentlich in dem ganzen Data-Kontext das Thema, was ich total gerne mache, was mir am meisten Freude bereitet oder wo Leute mal reingucken sollten, weil das einfach spannend ist, sich damit zu beschäftigen? Ich persönlich finde, aber weil ich auch vielleicht mehr auf so einer Technikerbrille tatsächlich noch darauf gucke, diese Data-Contract-Geschichte spannend. Die finde ich deswegen spannend, weil wir über Contracts und nicht über Schnittstellen reden. Das hängt da schon noch ein bisschen mehr dahinter. Das finde ich interessant, sich damit mal auseinanderzusetzen, wobei das auch eher was ist, was ich eigentlich so auch in der Mitte oder zum Ende hin meiner Reise habe. Also reife, gute Contracts, qualitativ gute Contracts zu schaffen, ist genauso wie mit den Schnittstellen. Bis ich da bin, ist es vielleicht ein langer Weg, aber wenn ich einmal da bin, dann helfen die mir sehr weiter. Also das finde ich persönlich spannend. Diese Weichenfaktoren, in Anführungszeichen, wenn ich sie mal so nenne, sich mit Leuten mal vor so einen Reißbrett zu stellen, mal so ein Canvas aufzumalen und dann mal abzuleiten, was kann euch so ein Datenprodukt überhaupt bringen? Bringt es euch überhaupt irgendwas? Und dann auch in Richtung von diesem Data Literacy, das sind so Dinge, die finde ich persönlich auch spannend. Also es ist irgendwie so am Anfang in der Mitte und am Ende irgendwie so ein bisschen, wenn man auch den Zeitstrahl skizziert. Ist bei mir nicht anders. Dadurch, dass ich jetzt gerade Projekte mit sehr starken Daten zu betreue, sehe ich halt auch immer mehr so die Themen wie Ontologien da hochkommen. Es ist auch ganz spannend einfach zu sehen, wie beschreibe ich denn überhaupt erstmal das, was ich da machen will und setze so einen Standard für meine Organisation, ohne direkt zu gucken, was ist denn der Inhalt von diesen Daten. Sondern wirklich mal beschreiben, was ist die Erwartungshaltung, wenn ich über so einen Kunden spreche, was du auch vorhin gesagt hast. Erstmal wirklich gucken, okay, wie ist der denn überhaupt aufgebaut und dann zu überlegen, okay, wie komme ich denn dahin und was steckt denn da so hinter, wo liegen vielleicht auch diese Daten. Und wie gesagt, in Richtung Contracts, das ist für mich jetzt, weil ich mehr auf der rechten Seite unterwegs bin, eine Zwischenstufe, dass ich das einfach fest, klar definiert habe, worauf läuft das hinaus und irgendwie kommt aus diesen Contracts, werden dann irgendwelche Schnittstellen entstehen, wie die auch immer aussehen, vielleicht irgendwann automatisiert. Also sprich, das ganze Autosomatisierungsthema haben wir heute ja sehr stark ausgeklammert, weil wir uns mehr auf die Produkte bezogen haben, aber das ist halt auch einfach so spannend zu sehen, wie sowas halt automatisiert vielleicht in den nächsten Jahren ablaufen könnte, was es da für Möglichkeiten gibt. Wirklich festzustellen, okay, wie komme ich denn jetzt von dieser klassischen. Beschreibung oder ich starte sogar noch tiefer bei einer Ontologie dann wirklich dahin, dass ich etwas in einen Marktplatz stelle und Menschen können es benutzen oder Maschinen, wie auch immer. Das sind doch schöne Worte zum Schluss. Das war ein Geek kommt selten allein. Vielen Dank fürs Zuhören. Großen Dank an dich, Daniel. Und großen Dank an dich. Florian. Wenn unsere Hörer euch jetzt im Netz stalken wollen und mehr von euch erfahren wollen. Wo wäre ein guter Ort? Wo könnten sie euch finden? LinkedIn. Dito, LinkedIn. Gerne anschreiben, ich freue mich. Ihr, liebe Hörer, macht es gut. Wir machen Sommerpause. Wir hören uns später im Jahr mit neuen Folgen. Und wenn ihr Feedback zu dieser Folge habt oder alte Episoden nachhören möchtet, könnt ihr das natürlich wie immer unter www.eingiekkommtseltenallein.de tun oder bei Spotify, YouTube, Apple Podcasts oder wo auch immer sonst ihr eure guten Podcasts herbekommt. Vielen Dank, macht's gut. Tschüss. Bis zum nächsten Mal. Aber es war schön. Hat Spaß gemacht.