Antifragil in der VUKA-Welt: Digitale Transformation zwischen Regulierung und Realität🔥 Archiv
94 Episoden
1 Stunde 4 Minuten
Tom Hohenadel ist Geschäftsprozessmanager in einem Scale-Up, frisch gebackener Doktor und Mitgründer eines Tools, das Prozessdokumentation endlich für alle zugänglich machen soll. Im Gespräch räumen er und Christof mit einem hartnäckigen Missverständnis auf: Prozessdokumentation ist kein Selbstzweck. Ob man für den Auditor, für die Automatisierung oder als Erklärmodell dokumentiert, macht einen riesigen Unterschied für Tiefe, Format und Aufwand. Wer das nicht trennt, produziert Waste in beide Richtungen.
Key Takeaways:
Ziel zuerst, Modell dann. Wer für den Auditor dokumentiert, braucht kein BPMN mit 150 Symbolen. Wer automatisieren will, muss viel tiefer rein. Beides gleichzeitig zu versuchen ist Ressourcenverschwendung.
Prozesse gehören in den Fachbereich, nicht ins BPM-Kämmerlein. Wer die Sprache des Fachbereichs nicht kennt, baut Modelle, die niemand versteht. Der Fachbereich soll seine Prozesse selbst dokumentieren, mit leichter Begleitung.
BPMN-Regeln brechen ist manchmal richtig. Wenn ein formal falsches Modell im Fachbereich besser ankommt und nicht für Automatisierung genutzt wird, ist es das bessere Modell.
Input-Output-Management ist unterschätzt. Viele Unternehmen haben sauber dokumentierte Einzelprozesse, aber dysfunktionale Übergaben dazwischen. SIPOC (oder der von Tom bevorzugte POC-SIP-Ansatz) macht Mismatches sichtbar.
Prozessmanagement unter 200 Leuten braucht ihr wahrscheinlich nicht. Direkte Abstimmung und ein gemeinsames Dokument reichen. Kein BPMN-Tool nötig.
Schatten-IT ist ein Motivationsindikator, kein Problem. Wenn Leute sich eigene Lösungen bauen, weil die Standard-Tools nicht reichen, zeigen sie Engagement. Null Schatten-IT bedeutet oft: Null Eigeninitiative.
Prozesse so abstrakt wie nötig, so konkret wie möglich. Vor allem in wachsenden Unternehmen: Was sich ständig ändert, nicht statisch dokumentieren. Was fix sein muss, genau festhalten.
Links & Ressourcen:
Tom Hohenadel auf LinkedIn https://www.linkedin.com/in/thohenadl/https://www.linkedin.com/in/thohenadl/
BPMN (Business Process Model and Notation) – Standardnotation für Prozessmodellierung: https://www.bpmn.org
Camunda – Workflow Engine mit BPMN-Unterstützung und Zeitvisualisierung: https://camunda.com
Makigami-Diagramm – Lean-Methode zur Prozessanalyse mit Zeitebenen
SIPOC – Supplier Input Process Output Customer, Methode zur Prozessabgrenzung
Palantir – Im Gespräch erwähnt als Beispiel für Datennormalisierung aus vielen Quellen: https://www.palantir.com
In höchster Not – Bergrettung in Bayern – Toms Content-Empfehlung, ARD Mediathek: https://www.ardmediathek.de
Key Takeaways:
Ziel zuerst, Modell dann. Wer für den Auditor dokumentiert, braucht kein BPMN mit 150 Symbolen. Wer automatisieren will, muss viel tiefer rein. Beides gleichzeitig zu versuchen ist Ressourcenverschwendung.
Prozesse gehören in den Fachbereich, nicht ins BPM-Kämmerlein. Wer die Sprache des Fachbereichs nicht kennt, baut Modelle, die niemand versteht. Der Fachbereich soll seine Prozesse selbst dokumentieren, mit leichter Begleitung.
BPMN-Regeln brechen ist manchmal richtig. Wenn ein formal falsches Modell im Fachbereich besser ankommt und nicht für Automatisierung genutzt wird, ist es das bessere Modell.
Input-Output-Management ist unterschätzt. Viele Unternehmen haben sauber dokumentierte Einzelprozesse, aber dysfunktionale Übergaben dazwischen. SIPOC (oder der von Tom bevorzugte POC-SIP-Ansatz) macht Mismatches sichtbar.
Prozessmanagement unter 200 Leuten braucht ihr wahrscheinlich nicht. Direkte Abstimmung und ein gemeinsames Dokument reichen. Kein BPMN-Tool nötig.
Schatten-IT ist ein Motivationsindikator, kein Problem. Wenn Leute sich eigene Lösungen bauen, weil die Standard-Tools nicht reichen, zeigen sie Engagement. Null Schatten-IT bedeutet oft: Null Eigeninitiative.
Prozesse so abstrakt wie nötig, so konkret wie möglich. Vor allem in wachsenden Unternehmen: Was sich ständig ändert, nicht statisch dokumentieren. Was fix sein muss, genau festhalten.
Links & Ressourcen:
Tom Hohenadel auf LinkedIn https://www.linkedin.com/in/thohenadl/https://www.linkedin.com/in/thohenadl/
BPMN (Business Process Model and Notation) – Standardnotation für Prozessmodellierung: https://www.bpmn.org
Camunda – Workflow Engine mit BPMN-Unterstützung und Zeitvisualisierung: https://camunda.com
Makigami-Diagramm – Lean-Methode zur Prozessanalyse mit Zeitebenen
SIPOC – Supplier Input Process Output Customer, Methode zur Prozessabgrenzung
Palantir – Im Gespräch erwähnt als Beispiel für Datennormalisierung aus vielen Quellen: https://www.palantir.com
In höchster Not – Bergrettung in Bayern – Toms Content-Empfehlung, ARD Mediathek: https://www.ardmediathek.de
50 Minuten
Oliver Ulbrich arbeitet als Sparringspartner für Datenstrategie mit einem klaren Fokus: Klarheit statt Komplexität. Im Gespräch mit Christof geht es darum, warum gut gebaute Dashboards trotzdem niemand nutzt, wie Prototyping den Unterschied macht und weshalb das teuerste Problem in Reporting-Projekten nicht die Daten sind, sondern die Meetingkultur rund ums Verschieben von Entscheidungen. Beide sind sich einig: Wer nicht weiß, welche Entscheidung er treffen will, braucht kein Dashboard, sondern zuerst eine klare Frage.
Key Takeaways
Bevor du ein Dashboard baust, kläre welche Entscheidung damit getroffen werden soll. Alles andere ist Dekoration.
Das teuerste Missverständnis in Reporting-Projekten sind die Meetings, in denen dieselben Fragen immer wieder vertagt werden, weil die entscheidenden Dinge vorher nicht festgelegt wurden.
Prototyping spart Zeit und Geld, aber nur rund 10 % der Unternehmen machen es konsequent. Der Hauptgrund: Es wird keine Zeit dafür eingeplant.
Die Abweichung ist wichtiger als der absolute Wert. Wer nur weiß, dass der Umsatz 2,5 Millionen beträgt, hat keine Information. Wer weiß, dass er 300.000 unter Plan liegt, muss handeln.
KPIs entstehen oft durch Politik und Gewohnheit, nicht durch strategische Überlegung. Gewachsen ist das häufigste Wort in diesem Kontext.
Weniger KPIs können mehr leisten. Ein Unternehmen mit 10 sauber definierten Kennzahlen ist oft besser gesteuert als eines mit 200 halbgaren.
Real-Time-Daten sind selten so notwendig wie behauptet. Die entscheidende Frage ist: Was würdest du in diesem Moment anders tun, wenn du die Zahl jetzt siehst?
Links & Ressourcen
Oliver Ulbrich auf LinkedIn (Stichwort: Klarheitspartner, Datenstrategie)
Buch-Empfehlung von Oliver: „Kompass für die Seele" – So bringen Sie Erfolg in ihr Leben
DORA Report (Google / DevOps Research and Assessment) – State of DevOps
Konzept: Least Burdensome Principle (FDA) – im Gespräch erwähnt im Kontext regulierter Umgebungen
Begriff: Not-To-Do-Liste – von Christof als Leseempfehlung erwähnt
Key Takeaways
Bevor du ein Dashboard baust, kläre welche Entscheidung damit getroffen werden soll. Alles andere ist Dekoration.
Das teuerste Missverständnis in Reporting-Projekten sind die Meetings, in denen dieselben Fragen immer wieder vertagt werden, weil die entscheidenden Dinge vorher nicht festgelegt wurden.
Prototyping spart Zeit und Geld, aber nur rund 10 % der Unternehmen machen es konsequent. Der Hauptgrund: Es wird keine Zeit dafür eingeplant.
Die Abweichung ist wichtiger als der absolute Wert. Wer nur weiß, dass der Umsatz 2,5 Millionen beträgt, hat keine Information. Wer weiß, dass er 300.000 unter Plan liegt, muss handeln.
KPIs entstehen oft durch Politik und Gewohnheit, nicht durch strategische Überlegung. Gewachsen ist das häufigste Wort in diesem Kontext.
Weniger KPIs können mehr leisten. Ein Unternehmen mit 10 sauber definierten Kennzahlen ist oft besser gesteuert als eines mit 200 halbgaren.
Real-Time-Daten sind selten so notwendig wie behauptet. Die entscheidende Frage ist: Was würdest du in diesem Moment anders tun, wenn du die Zahl jetzt siehst?
Links & Ressourcen
Oliver Ulbrich auf LinkedIn (Stichwort: Klarheitspartner, Datenstrategie)
Buch-Empfehlung von Oliver: „Kompass für die Seele" – So bringen Sie Erfolg in ihr Leben
DORA Report (Google / DevOps Research and Assessment) – State of DevOps
Konzept: Least Burdensome Principle (FDA) – im Gespräch erwähnt im Kontext regulierter Umgebungen
Begriff: Not-To-Do-Liste – von Christof als Leseempfehlung erwähnt
5 Minuten
Dashboards gibt es überall. Genutzt werden die wenigsten. Oliver Ulbrich sagt fast täglich Führungsteams, dass sie KPIs weglassen sollen – nicht hinzufügen. Was das teuerste Missverständnis in Reporting-Projekten ist und warum Prototyping trotzdem kaum jemand macht, das gibt es in der vollen Folge – ab nächstem Freitag im ChaosHacker-Talk.
42 Minuten
Toni Garcia, Global CIO at Neuraxpharm and former CISO, comes with a clear position: agility and pharma compliance are not opposites — you just need to know which parts of a project require waterfall and which can be agile. He's equally direct about cybersecurity: people are not the weakest link, they are the strongest layer of defense. The conversation moves between hacker mindset, C-level leadership reality, and what actually makes teams perform under pressure.
Key Takeaways
Agile works in pharma if you split the project correctly: URS creation and validation follow waterfall, implementation can be agile.
Security and digital transformation are not enemies — they share the same path and depend on each other to succeed.
Hackers are agile by default: they try, fail, and adapt. IT departments need to learn the same behavior.
People are the solution to cybersecurity, not the problem. No firewall stack replaces a well-trained, alert team.
The most important KPI for a high-performing team is not a metrics dashboard — it's whether the team experiences decisions and priorities as clear and fair on a daily basis.
Perfect does not mean error-free. Zero-day vulnerabilities can hit anyone. Accepting that imperfection is part of the equation is what allows you to act at all.
As a CIO, the real job is giving the team time, budget, and good decisions — not solving every problem yourself.
Links & Resources
DORA (DevOps Research and Assessment) – Google Cloud research program on software delivery performance: https://cloud.google.com/devops
DORA State of DevOps Report 2024 (: https://dora.dev/research/2024/dora-report/
ISO 27001 – Information Security Management System (mentioned by Toni as the most valuable framework): https://www.iso.org/isoiec-27001-information-security.html
Neuraxpharm (Toni's current organization): https://www.neuraxpharm.com
Book Accelerate by Nicole Forsgren, Jez Humble, Gene Kim – scientific foundation of DORA metrics: link not found, please search separately (ISBN: 9781942788331)
Key Takeaways
Agile works in pharma if you split the project correctly: URS creation and validation follow waterfall, implementation can be agile.
Security and digital transformation are not enemies — they share the same path and depend on each other to succeed.
Hackers are agile by default: they try, fail, and adapt. IT departments need to learn the same behavior.
People are the solution to cybersecurity, not the problem. No firewall stack replaces a well-trained, alert team.
The most important KPI for a high-performing team is not a metrics dashboard — it's whether the team experiences decisions and priorities as clear and fair on a daily basis.
Perfect does not mean error-free. Zero-day vulnerabilities can hit anyone. Accepting that imperfection is part of the equation is what allows you to act at all.
As a CIO, the real job is giving the team time, budget, and good decisions — not solving every problem yourself.
Links & Resources
DORA (DevOps Research and Assessment) – Google Cloud research program on software delivery performance: https://cloud.google.com/devops
DORA State of DevOps Report 2024 (: https://dora.dev/research/2024/dora-report/
ISO 27001 – Information Security Management System (mentioned by Toni as the most valuable framework): https://www.iso.org/isoiec-27001-information-security.html
Neuraxpharm (Toni's current organization): https://www.neuraxpharm.com
Book Accelerate by Nicole Forsgren, Jez Humble, Gene Kim – scientific foundation of DORA metrics: link not found, please search separately (ISBN: 9781942788331)
6 Minuten
Toni Garcia has been CISO and CIO at the same time — in one of the most regulated industries in the world. In this teaser, he tackles three uncomfortable questions: Are security and transformation really opponents? Can agile actually work in pharma? And when does a hacker decide to become a manager?
More at Friday
More at Friday
55 Minuten
Viele Unternehmen behandeln Labore wie ein weiteres IT-System.
Genau da fängt das Problem an.
In dieser Folge spreche ich mit Marc darüber, warum Digitalisierungsprojekte im Labor so oft scheitern - und warum das nichts mit fehlender Technologie zu tun hat.
Die eigentliche Ursache liegt tiefer: falsche Denkmuster, fehlende Trennung von IT und OT, und der Versuch, komplexe physische Prozesse mit klassischen IT-Methoden zu erschlagen.
Wir reden über reale Beispiele - von Produktionsausfällen durch simple IT-Mechanismen bis hin zu absurden Sicherheitskonzepten, die in der Praxis nicht funktionieren.
Und wir gehen dahin, wo es spannend wird:
Wie sieht eine Architektur aus, die wirklich funktioniert?
Welche Rolle spielen Standards wie SILA oder OPC UA?
Und warum ist „Compliance“ oft selbstgemachtes Chaos?
Am Ende bleibt eine unbequeme Erkenntnis:
Digitalisierung im regulierten Umfeld scheitert selten an Technik - sondern fast immer an Entscheidungen.
Key Takeaways
Labore sind keine klassische IT-Umgebung
Wer sie so behandelt, produziert Probleme - technisch, organisatorisch und wirtschaftlich.
Das größte Missverständnis: Alles ist „IT“
In Wahrheit reden wir über physische Prozesse, Automatisierung und Operational Technology.
Digitalisierung scheitert am Anfang - nicht am Ende
Wenn Anforderungen nicht vom Ergebnis her gedacht werden, baut man am Bedarf vorbei.
Security ist nicht gleich Security
In der IT zählt oft Vertraulichkeit und Integrität.
Im Labor und in der Produktion dominiert Verfügbarkeit.
Standards sind notwendig - aber nicht ausreichend
SILA, OPC UA & Co. helfen - aber sie lösen nicht das Gesamtproblem.
Netzwerksegmentierung ist kein „Nice-to-have“
Sondern die Grundlage, um unterschiedliche Sicherheitsniveaus überhaupt betreiben zu können.
Die wichtigste Ressource fehlt oft: Übersetzer
Menschen, die sowohl IT als auch Labor/Produktion verstehen.
Compliance ist kein Naturgesetz
Wenn sie Prozesse blockiert, wurde sie falsch implementiert - nicht falsch vorgeschrieben.
DevOps gehört ins Labor
Versionierung, Automatisierung, Security Checks - alles gelöste Probleme. Werden nur oft ignoriert.
Entscheidungen sind immer unsicher
Wer wartet, bis alles sicher ist, trifft keine Entscheidungen mehr.
Inhalte & Referenzen aus der Episode
„The Mythical Man-Month“ - Frederick P. Brooks Jr.
Klassiker über IT-Projektmanagement - erschreckend aktuell, obwohl aus den 70ern.
SILA (Standardization in Lab Automation)
Framework zur Standardisierung von Gerätekommunikation im Labor
OPC UA (inkl. LADS)
Industriestandard für sichere Maschinenkommunikation - zunehmend relevant im Laborumfeld
Allotrope / AnIML
Standards für strukturierte Labordaten und Ergebnisformate
️ DevOps & Git-basierte Workflows
Grundlage für „Compliance by Design“ und reproduzierbare Prozesse
Genau da fängt das Problem an.
In dieser Folge spreche ich mit Marc darüber, warum Digitalisierungsprojekte im Labor so oft scheitern - und warum das nichts mit fehlender Technologie zu tun hat.
Die eigentliche Ursache liegt tiefer: falsche Denkmuster, fehlende Trennung von IT und OT, und der Versuch, komplexe physische Prozesse mit klassischen IT-Methoden zu erschlagen.
Wir reden über reale Beispiele - von Produktionsausfällen durch simple IT-Mechanismen bis hin zu absurden Sicherheitskonzepten, die in der Praxis nicht funktionieren.
Und wir gehen dahin, wo es spannend wird:
Wie sieht eine Architektur aus, die wirklich funktioniert?
Welche Rolle spielen Standards wie SILA oder OPC UA?
Und warum ist „Compliance“ oft selbstgemachtes Chaos?
Am Ende bleibt eine unbequeme Erkenntnis:
Digitalisierung im regulierten Umfeld scheitert selten an Technik - sondern fast immer an Entscheidungen.
Key Takeaways
Labore sind keine klassische IT-Umgebung
Wer sie so behandelt, produziert Probleme - technisch, organisatorisch und wirtschaftlich.
Das größte Missverständnis: Alles ist „IT“
In Wahrheit reden wir über physische Prozesse, Automatisierung und Operational Technology.
Digitalisierung scheitert am Anfang - nicht am Ende
Wenn Anforderungen nicht vom Ergebnis her gedacht werden, baut man am Bedarf vorbei.
Security ist nicht gleich Security
In der IT zählt oft Vertraulichkeit und Integrität.
Im Labor und in der Produktion dominiert Verfügbarkeit.
Standards sind notwendig - aber nicht ausreichend
SILA, OPC UA & Co. helfen - aber sie lösen nicht das Gesamtproblem.
Netzwerksegmentierung ist kein „Nice-to-have“
Sondern die Grundlage, um unterschiedliche Sicherheitsniveaus überhaupt betreiben zu können.
Die wichtigste Ressource fehlt oft: Übersetzer
Menschen, die sowohl IT als auch Labor/Produktion verstehen.
Compliance ist kein Naturgesetz
Wenn sie Prozesse blockiert, wurde sie falsch implementiert - nicht falsch vorgeschrieben.
DevOps gehört ins Labor
Versionierung, Automatisierung, Security Checks - alles gelöste Probleme. Werden nur oft ignoriert.
Entscheidungen sind immer unsicher
Wer wartet, bis alles sicher ist, trifft keine Entscheidungen mehr.
Inhalte & Referenzen aus der Episode
„The Mythical Man-Month“ - Frederick P. Brooks Jr.
Klassiker über IT-Projektmanagement - erschreckend aktuell, obwohl aus den 70ern.
SILA (Standardization in Lab Automation)
Framework zur Standardisierung von Gerätekommunikation im Labor
OPC UA (inkl. LADS)
Industriestandard für sichere Maschinenkommunikation - zunehmend relevant im Laborumfeld
Allotrope / AnIML
Standards für strukturierte Labordaten und Ergebnisformate
️ DevOps & Git-basierte Workflows
Grundlage für „Compliance by Design“ und reproduzierbare Prozesse
70 Sekunden
Labore gehören zur IT-Landschaft?
Klingt logisch. Ist aber falsch.
In diesem Teaser sprechen wir über genau diesen Denkfehler - und warum er einer der Hauptgründe ist, warum Digitalisierungsprojekte im regulierten Umfeld scheitern.
Außerdem:
Warum Cybersecurity in kleinen Unternehmen oft zu spät kommt
Wieso viele Digitalisierungsinitiativen schon am Anfang kippen
Und warum „mehr Digitalisierung“ nicht immer die richtige Antwort ist
Ein kurzer Vorgeschmack auf die kommende Episode - mit ein paar unbequemen Wahrheiten.
Die komplette Folge erscheint nächste Woche.
Klingt logisch. Ist aber falsch.
In diesem Teaser sprechen wir über genau diesen Denkfehler - und warum er einer der Hauptgründe ist, warum Digitalisierungsprojekte im regulierten Umfeld scheitern.
Außerdem:
Warum Cybersecurity in kleinen Unternehmen oft zu spät kommt
Wieso viele Digitalisierungsinitiativen schon am Anfang kippen
Und warum „mehr Digitalisierung“ nicht immer die richtige Antwort ist
Ein kurzer Vorgeschmack auf die kommende Episode - mit ein paar unbequemen Wahrheiten.
Die komplette Folge erscheint nächste Woche.
54 Minuten
IT Asset Management hat ein Imageproblem.
Klingt nach Inventarliste, Excel und Verwaltung. Also genau nach dem Zeug, das keiner freiwillig anfasst.
Im Gespräch mit Alexander van der Steeg wird ziemlich schnell klar:
Das Thema ist alles andere als „nice to have“.
Es ist die Grundlage dafür, ob du dein Unternehmen überhaupt unter Kontrolle hast.
Wir sprechen darüber,
warum fehlende Transparenz der eigentliche Risikotreiber ist
weshalb Excel-Listen in regulierten Umfeldern brandgefährlich werden
und warum viele Unternehmen genau an der Stelle scheitern, bevor es überhaupt losgeht
Spoiler:
Nicht die Technologie ist das Problem. Sondern die Entscheidung, sich wirklich damit auseinanderzusetzen.
Podcast Empfehlung:
UNF#CK YOUR DATA - Christian Krug
Gesprächspartner:
Alexander van der Steeg und Christof Layher
Klingt nach Inventarliste, Excel und Verwaltung. Also genau nach dem Zeug, das keiner freiwillig anfasst.
Im Gespräch mit Alexander van der Steeg wird ziemlich schnell klar:
Das Thema ist alles andere als „nice to have“.
Es ist die Grundlage dafür, ob du dein Unternehmen überhaupt unter Kontrolle hast.
Wir sprechen darüber,
warum fehlende Transparenz der eigentliche Risikotreiber ist
weshalb Excel-Listen in regulierten Umfeldern brandgefährlich werden
und warum viele Unternehmen genau an der Stelle scheitern, bevor es überhaupt losgeht
Spoiler:
Nicht die Technologie ist das Problem. Sondern die Entscheidung, sich wirklich damit auseinanderzusetzen.
Podcast Empfehlung:
UNF#CK YOUR DATA - Christian Krug
Gesprächspartner:
Alexander van der Steeg und Christof Layher
55 Minuten
Wir reden ständig über Daten, KI und Automatisierung.
Aber wir übersehen das Fundament: Sprache.
In dieser Folge spreche ich mit Tom Winter über ein Problem, das in fast jedem Unternehmen existiert – und selten sauber adressiert wird:
Wir verwenden die gleichen Begriffe, meinen aber unterschiedliche Dinge.
Was harmlos klingt, wird im Kontext von KI richtig teuer.
Denn Large Language Models arbeiten genau mit diesen Begriffen. Wenn die Bedeutung unscharf ist, skaliert die KI nicht Wissen – sondern Missverständnisse.
Wir sprechen darüber, warum Terminologie mehr ist als ein „Wörterbuch“, wie Taxonomien und Ontologien daraus echte Entscheidungsgrundlagen machen und warum viele aktuelle KI-Ansätze genau hier an ihre Grenzen stoßen.
Und wir schauen auf eine unbequeme Wahrheit:
Digitale Transformation scheitert nicht an Technologie – sondern an fehlendem gemeinsamen Verständnis.
Key Takeaways
Gleiche Begriffe bedeuten nicht automatisch das Gleiche – Kontext entscheidet
Terminologie ist die Grundlage für saubere Kommunikation und Datenverarbeitung
Taxonomien und Ontologien machen Bedeutung strukturiert und maschinenlesbar
Klassische KI-Ansätze (z. B. RAG) stoßen bei Mehrdeutigkeit schnell an Grenzen
Ohne semantische Klarheit steigt das Risiko von Fehlinterpretationen und Halluzinationen
Unternehmen brauchen keine zentrale Datenbank für alles – aber eine zentrale Referenz für Bedeutung
Datensilos sind nicht das Problem – fehlende Verbindung zwischen ihnen schon
Eine saubere semantische Basis ist Voraussetzung für skalierbare, agentenbasierte KI-Systeme
Sprache ist kein „Soft-Thema“, sondern kritische Infrastruktur für Digitalisierung
Links aus der Episode
Buch: Fuzzy Thinking
Verein: Deutscher Terminologietag (DTT)
Aber wir übersehen das Fundament: Sprache.
In dieser Folge spreche ich mit Tom Winter über ein Problem, das in fast jedem Unternehmen existiert – und selten sauber adressiert wird:
Wir verwenden die gleichen Begriffe, meinen aber unterschiedliche Dinge.
Was harmlos klingt, wird im Kontext von KI richtig teuer.
Denn Large Language Models arbeiten genau mit diesen Begriffen. Wenn die Bedeutung unscharf ist, skaliert die KI nicht Wissen – sondern Missverständnisse.
Wir sprechen darüber, warum Terminologie mehr ist als ein „Wörterbuch“, wie Taxonomien und Ontologien daraus echte Entscheidungsgrundlagen machen und warum viele aktuelle KI-Ansätze genau hier an ihre Grenzen stoßen.
Und wir schauen auf eine unbequeme Wahrheit:
Digitale Transformation scheitert nicht an Technologie – sondern an fehlendem gemeinsamen Verständnis.
Key Takeaways
Gleiche Begriffe bedeuten nicht automatisch das Gleiche – Kontext entscheidet
Terminologie ist die Grundlage für saubere Kommunikation und Datenverarbeitung
Taxonomien und Ontologien machen Bedeutung strukturiert und maschinenlesbar
Klassische KI-Ansätze (z. B. RAG) stoßen bei Mehrdeutigkeit schnell an Grenzen
Ohne semantische Klarheit steigt das Risiko von Fehlinterpretationen und Halluzinationen
Unternehmen brauchen keine zentrale Datenbank für alles – aber eine zentrale Referenz für Bedeutung
Datensilos sind nicht das Problem – fehlende Verbindung zwischen ihnen schon
Eine saubere semantische Basis ist Voraussetzung für skalierbare, agentenbasierte KI-Systeme
Sprache ist kein „Soft-Thema“, sondern kritische Infrastruktur für Digitalisierung
Links aus der Episode
Buch: Fuzzy Thinking
Verein: Deutscher Terminologietag (DTT)
50 Minuten
Daten sind überall.
Nur bringen sie erstaunlich selten etwas.
Warum?
Weil Unternehmen glauben, das Problem sei technisch.
Ist es nicht.
In dieser Folge spreche ich mit Thomas Gengler (Head of BI Services bei der Phoenix Group) über das, woran Dateninitiativen wirklich scheitern:
Unterschiedliche Definitionen statt gemeinsames Verständnis
„Wir brauchen alle Daten“ statt klarer Use Cases
KI-Hype ohne Datenbasis
Excel-Schattenwelten trotz moderner BI-Tools
Und ja - auch über das, was funktioniert.
Darum solltest du reinhören
Wenn du Verantwortung trägst für:
IT
Daten
digitale Transformation
oder einfach Entscheidungen
Dann kennst du diese Situationen.
Und wahrscheinlich auch den Frust dahinter.
Was du mitnimmst
Warum Datenintegration selten ein Technikproblem ist
Wieso „alle Daten“ der Anfang vom Ende ist
Wie echte Datenprodukte entstehen (nicht nur Reports)
Warum Self-Service kein Risiko ist - sondern Pflicht
Wieso Datenkultur kein Buzzword ist, sondern harte Führungsarbeit
Und ein Satz, der hängen bleibt:
KI skaliert deine Datenqualität.
Nicht deine Intelligenz.
Praxis aus einem regulierten Umfeld
Wir reden nicht über Startups.
Sondern über:
internationale Strukturen
regulatorische Anforderungen
heterogene Systemlandschaften
Also genau die Realität, in der die meisten Organisationen stecken.
Empfehlung aus der Folge
Lean Startup von Eric Ries
Nicht wegen des Buzzwords.
Sondern wegen einer unbequemen Wahrheit:Du kannst ein Jahr lang etwas perfekt bauen -und trotzdem komplett am Bedarf vorbeiarbeiten.
Christof Layher
Thomas Gengler
Seine Bücher
Zum Mitnehmen
Daten schaffen keinen Wert.
Die Entscheidung, die du damit triffst, schon.
Wenn du das Gefühl hast, dein Unternehmen diskutiert noch über Tools statt über Wirkung:
Dann solltest du diese Folge hören.
Nur bringen sie erstaunlich selten etwas.
Warum?
Weil Unternehmen glauben, das Problem sei technisch.
Ist es nicht.
In dieser Folge spreche ich mit Thomas Gengler (Head of BI Services bei der Phoenix Group) über das, woran Dateninitiativen wirklich scheitern:
Unterschiedliche Definitionen statt gemeinsames Verständnis
„Wir brauchen alle Daten“ statt klarer Use Cases
KI-Hype ohne Datenbasis
Excel-Schattenwelten trotz moderner BI-Tools
Und ja - auch über das, was funktioniert.
Darum solltest du reinhören
Wenn du Verantwortung trägst für:
IT
Daten
digitale Transformation
oder einfach Entscheidungen
Dann kennst du diese Situationen.
Und wahrscheinlich auch den Frust dahinter.
Was du mitnimmst
Warum Datenintegration selten ein Technikproblem ist
Wieso „alle Daten“ der Anfang vom Ende ist
Wie echte Datenprodukte entstehen (nicht nur Reports)
Warum Self-Service kein Risiko ist - sondern Pflicht
Wieso Datenkultur kein Buzzword ist, sondern harte Führungsarbeit
Und ein Satz, der hängen bleibt:
KI skaliert deine Datenqualität.
Nicht deine Intelligenz.
Praxis aus einem regulierten Umfeld
Wir reden nicht über Startups.
Sondern über:
internationale Strukturen
regulatorische Anforderungen
heterogene Systemlandschaften
Also genau die Realität, in der die meisten Organisationen stecken.
Empfehlung aus der Folge
Lean Startup von Eric Ries
Nicht wegen des Buzzwords.
Sondern wegen einer unbequemen Wahrheit:Du kannst ein Jahr lang etwas perfekt bauen -und trotzdem komplett am Bedarf vorbeiarbeiten.
Christof Layher
Thomas Gengler
Seine Bücher
Zum Mitnehmen
Daten schaffen keinen Wert.
Die Entscheidung, die du damit triffst, schon.
Wenn du das Gefühl hast, dein Unternehmen diskutiert noch über Tools statt über Wirkung:
Dann solltest du diese Folge hören.
59 Minuten
In dieser Folge des Chaos Hacker Talk spreche ich mit Oliver Schacht, dem Geschäftsführer von Life Science Nord und langjährigen CEO börsennotierter Biotech-Unternehmen. Wir beleuchten, warum die deutsche Biotech-Szene besser ist als ihr Ruf und wie man in einem hochregulierten Umfeld agil bleibt, ohne die Bodenhaftung zu verlieren.
Der Standort-Vorteil Europa: Warum der EU-AI-Act und die MDR/IVDR keine Innovationsbremsen sind, sondern verlässliche Rahmenbedingungen schaffen, die uns international abheben.
KI in der Life Science: Ein Blick zurück auf 30 Jahre Machine Learning – von Support Vector Machines 1999 bis hin zu modernen prädiktiven Modellen für Antibiotika-Resistenzen.
Führung & Fehlerkultur: Warum das Ausbleiben von Fehlern ein Warnsignal für mangelnde Innovation ist und wie man Teams in haftungskritischen Bereichen (PRRC) psychologische Sicherheit gibt.
Kapitalmarkt vs. Regulierung: Der Umgang mit „Moral Hazard“ und warum es im Business keine Abkürzungen (Shortcuts), wohl aber effiziente Wege gibt.
Strategischer Kostenvorteil: Ein überraschender Vergleich – warum High-Tech-Entwicklung in Deutschland bis zu 2,5-mal günstiger sein kann als in den USA.
Über den Gast:
Oliver Schacht ist ein „erfahrener Hase“ der Biotech-Branche. Er begleitete mehrfache Börsengänge (IPOs), ist im Vorstand der Bio Deutschland aktiv und leitet heute das Cluster-Management Life Science Nord.
Empfehlungen:
Buch/Content-Tipp: Podcast-Serie „Willing to Win“ von Christian Rados.
Das Gelassenheitsgebet: Olivers persönlicher Anker für pragmatische Entscheidungen.
Vernetzung: Oliver Schacht auf LinkedIn.
Der Standort-Vorteil Europa: Warum der EU-AI-Act und die MDR/IVDR keine Innovationsbremsen sind, sondern verlässliche Rahmenbedingungen schaffen, die uns international abheben.
KI in der Life Science: Ein Blick zurück auf 30 Jahre Machine Learning – von Support Vector Machines 1999 bis hin zu modernen prädiktiven Modellen für Antibiotika-Resistenzen.
Führung & Fehlerkultur: Warum das Ausbleiben von Fehlern ein Warnsignal für mangelnde Innovation ist und wie man Teams in haftungskritischen Bereichen (PRRC) psychologische Sicherheit gibt.
Kapitalmarkt vs. Regulierung: Der Umgang mit „Moral Hazard“ und warum es im Business keine Abkürzungen (Shortcuts), wohl aber effiziente Wege gibt.
Strategischer Kostenvorteil: Ein überraschender Vergleich – warum High-Tech-Entwicklung in Deutschland bis zu 2,5-mal günstiger sein kann als in den USA.
Über den Gast:
Oliver Schacht ist ein „erfahrener Hase“ der Biotech-Branche. Er begleitete mehrfache Börsengänge (IPOs), ist im Vorstand der Bio Deutschland aktiv und leitet heute das Cluster-Management Life Science Nord.
Empfehlungen:
Buch/Content-Tipp: Podcast-Serie „Willing to Win“ von Christian Rados.
Das Gelassenheitsgebet: Olivers persönlicher Anker für pragmatische Entscheidungen.
Vernetzung: Oliver Schacht auf LinkedIn.
1 Stunde 2 Minuten
Hast du schon mal versucht, AWS, SAP oder Microsoft wirklich zu auditieren?
Und trotzdem laufen deine kritischen Prozesse genau dort.
In dieser Folge spreche ich mit Robert Geiger-Lebailly, Product Owner für GxP Compliance bei SAP, über eine Frage, die viele IT- und Compliance-Verantwortliche im regulierten Umfeld beschäftigt - aber kaum jemand offen diskutiert:
Wie qualifiziert man große Cloud-Anbieter risikobasiert - ohne regulatorische Scheinsicherheit zu erzeugen?
Wir sprechen über:
Warum „kritischer Lieferant“ nicht automatisch „Vor-Ort-Audit“ bedeuten muss
Wieso 30 Jahre alte Regularien moderne Cloud-Architekturen nur unzureichend abbilden
Das Missverständnis rund um Begriffe wie Quality Management oder User Access Management
Warum 85 Prozent aller Supplier Questionnaires identisch sind - und trotzdem am Ziel vorbeigehen
Wie ein SOC 2 Plus GxP-Ansatz echte Transparenz schaffen könnte
Was der Finanzsektor mit DORA vormacht - und was Life Sciences daraus lernen kann
Es geht nicht darum, Compliance abzuschaffen.
Es geht darum, sie intelligent zu gestalten.
Wenn du als CIO, IT-Leiter, QA-Verantwortlicher oder Geschäftsführer mit Cloud-Strategien im regulierten Umfeld unterwegs bist, bekommst du hier Impulse für:
effizientere Lieferantenqualifizierung
belastbarere Risikoabschätzung
weniger Audit-Theater
mehr echte Transparenz
Und trotzdem laufen deine kritischen Prozesse genau dort.
In dieser Folge spreche ich mit Robert Geiger-Lebailly, Product Owner für GxP Compliance bei SAP, über eine Frage, die viele IT- und Compliance-Verantwortliche im regulierten Umfeld beschäftigt - aber kaum jemand offen diskutiert:
Wie qualifiziert man große Cloud-Anbieter risikobasiert - ohne regulatorische Scheinsicherheit zu erzeugen?
Wir sprechen über:
Warum „kritischer Lieferant“ nicht automatisch „Vor-Ort-Audit“ bedeuten muss
Wieso 30 Jahre alte Regularien moderne Cloud-Architekturen nur unzureichend abbilden
Das Missverständnis rund um Begriffe wie Quality Management oder User Access Management
Warum 85 Prozent aller Supplier Questionnaires identisch sind - und trotzdem am Ziel vorbeigehen
Wie ein SOC 2 Plus GxP-Ansatz echte Transparenz schaffen könnte
Was der Finanzsektor mit DORA vormacht - und was Life Sciences daraus lernen kann
Es geht nicht darum, Compliance abzuschaffen.
Es geht darum, sie intelligent zu gestalten.
Wenn du als CIO, IT-Leiter, QA-Verantwortlicher oder Geschäftsführer mit Cloud-Strategien im regulierten Umfeld unterwegs bist, bekommst du hier Impulse für:
effizientere Lieferantenqualifizierung
belastbarere Risikoabschätzung
weniger Audit-Theater
mehr echte Transparenz
1 Stunde 10 Minuten
In dieser Episode des Chaos Hacker Talk begrüßt Christof den erfahrenen Life-Science-Leader Daniel Rupprecht (Head of EHSQ, BASF Grenzach). Gemeinsam hacken sie die Herausforderungen der VUCA-Welt im hochregulierten Umfeld. Die Diskussion spannt den Bogen von der notwendigen Psychological Safety in Qualitätsorganisationen über den Unterschied zwischen reiner Compliance und echtem Qualitätsmanagement bis hin zur Integration von EHSQ-Prozessen. Daniel Rupprecht plädiert leidenschaftlich für Intrapreneurship und erklärt, warum Führungskräfte in der Pharma- und Chemieindustrie heute eher „Leader“ als reine „Fachexperten“ sein müssen, um die digitale Transformation erfolgreich zu meistern.
Key Takeaways
Psychologische Sicherheit als Qualitätsfaktor: Eine offene Fehlerkultur ist im GxP-Umfeld essenziell; nur wenn Mitarbeiter keine Angst vor Sanktionen haben, werden Risiken rechtzeitig transparent.
Quality vs. Compliance: Während Compliance die gesetzlichen Leitplanken markiert, bedeutet Qualität, interne Prozesse so zu steuern, dass sie sowohl sicher als auch wettbewerbsfähig sind.
Intrapreneurship im Konzern: Mitarbeiter benötigen echte Entscheidungsfreiheit und ein unternehmerisches Mindset, um agilen Methoden wie Scrum oder agiler Prozessgestaltung Leben einzuhauchen.
Die Falle der Tool-Explosion: Digitalisierung scheitert oft an einer redundanten IT-Landschaft. Echter Mehrwert entsteht nur, wenn Tools Prozesse vereinfachen, statt Mitarbeitern Doppeleingaben in Silo-Systemen abzuverlangen.
Leadership-Shift: In einer komplexen Welt ist die Fähigkeit, diverse Teams zu führen und Verantwortungen zu delegieren, wichtiger als die tiefste fachliche Detailkenntnis des Vorgesetzten.
Frühe Einbindung der Qualität: Um Kosten zu senken, muss Quality bereits in der R&D-Phase integriert sein, anstatt Fehler erst in der Marktphase „gesundbeten“ zu wollen.
Links & Ressourcen aus der Episode
Buch-Empfehlung: Turn the Ship Around! von David Marquet
Daniel Rupprecht
Christof Layher
Key Takeaways
Psychologische Sicherheit als Qualitätsfaktor: Eine offene Fehlerkultur ist im GxP-Umfeld essenziell; nur wenn Mitarbeiter keine Angst vor Sanktionen haben, werden Risiken rechtzeitig transparent.
Quality vs. Compliance: Während Compliance die gesetzlichen Leitplanken markiert, bedeutet Qualität, interne Prozesse so zu steuern, dass sie sowohl sicher als auch wettbewerbsfähig sind.
Intrapreneurship im Konzern: Mitarbeiter benötigen echte Entscheidungsfreiheit und ein unternehmerisches Mindset, um agilen Methoden wie Scrum oder agiler Prozessgestaltung Leben einzuhauchen.
Die Falle der Tool-Explosion: Digitalisierung scheitert oft an einer redundanten IT-Landschaft. Echter Mehrwert entsteht nur, wenn Tools Prozesse vereinfachen, statt Mitarbeitern Doppeleingaben in Silo-Systemen abzuverlangen.
Leadership-Shift: In einer komplexen Welt ist die Fähigkeit, diverse Teams zu führen und Verantwortungen zu delegieren, wichtiger als die tiefste fachliche Detailkenntnis des Vorgesetzten.
Frühe Einbindung der Qualität: Um Kosten zu senken, muss Quality bereits in der R&D-Phase integriert sein, anstatt Fehler erst in der Marktphase „gesundbeten“ zu wollen.
Links & Ressourcen aus der Episode
Buch-Empfehlung: Turn the Ship Around! von David Marquet
Daniel Rupprecht
Christof Layher
1 Stunde 2 Minuten
Cybersecurity endet nicht im Rechenzentrum.
In dieser Folge des ChaosHacker-Talks sprechen wir über die Systeme, die wirklich kritisch sind: Produktionsanlagen, Steuerungen und industrielle Automatisierung.
Mein Gast ist Sarah Fluchs, Automatisierungsingenieurin, Security-Expertin für industrielle Systeme und Mitglied der Cyber Resilience Act Expert Group der EU-Kommission.
Wir schauen gemeinsam auf eine Realität, die viele Unternehmen unterschätzen:
Während IT-Security inzwischen relativ etabliert ist, stehen viele Produktionsumgebungen erst am Anfang.
Dabei geht es hier nicht nur um Daten.
Es geht um Ventile, Motoren, Produktionslinien – und im Life-Science Umfeld letztlich um Patientensicherheit.
Ein zentraler Teil der Diskussion ist der Cyber Resilience Act (CRA) der EU.
Er verpflichtet Hersteller erstmals dazu, Security bereits im Produktdesign zu berücksichtigen.
Für Unternehmen bedeutet das:
Produkte ohne Security-Konzept werden künftig nicht mehr verkäuflich sein
Betreiber müssen stärker verstehen, was in ihren Anlagen wirklich passiert
und Security muss früh im Engineering-Prozess beginnen – nicht kurz vor Go-Live.
Wir sprechen außerdem über:
die Unterschiede zwischen IT und OT
warum viele erfolgreiche Angriffe auf banalen Basics beruhen
warum Security oft an der falschen Stelle diskutiert wird
und warum eine saubere Risikoanalyse eines der mächtigsten Werkzeuge überhaupt ist.
Kurz gesagt:
Wenn Digitalisierung Produktion verändert, muss Security mitdenken.
Und zwar von Anfang an.
OT-Security ist nicht gleich IT-Security
Produktionssysteme haben andere Anforderungen – etwa Echtzeitfähigkeit, deterministische Kommunikation und lange Lebenszyklen.
Der Cyber Resilience Act verändert die Spielregeln
Hersteller müssen künftig Security-Anforderungen erfüllen, um digitale Produkte überhaupt verkaufen zu dürfen.
Security by Design statt Security als Nachgedanke
Sicherheitsanforderungen müssen bereits in Engineering- und Designprozessen berücksichtigt werden.
Viele Angriffe nutzen simple Schwachstellen
Offene Ports, fehlende Netzwerksegmentierung oder mangelnde Transparenz sind häufig die eigentlichen Probleme.
Risikoanalyse ist ein Entscheidungswerkzeug
Sie hilft zu priorisieren, wo Security wirklich relevant ist – und wo nicht.
Security darf keine Angstkommunikation sein
Ziel ist nicht, Nutzer einzuschüchtern, sondern Systeme so zu gestalten, dass Menschen sicher arbeiten können.
Ein gutes Systemverständnis ist der Schlüssel
Wer seine Prozesse, Systeme und Abhängigkeiten nicht versteht, kann auch keine wirksame Security aufbauen.
Cyber Resilience Act (EU)
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Konferenz: Security unter Kontrolle
https://security-unter-kontrolle.de
Buch: Countdown to Zero Day – Kim Zetter
https://www.penguinrandomhouse.com/books/318336/countdown-to-zero-day-by-kim-zetter/
Buch: Sandworm – Andy Greenberg
https://www.penguinrandomhouse.com/books/561678/sandworm-by-andy-greenberg/
Norm für OT-Security: IEC 62443
Key TakeawaysLinks aus der Episode
In dieser Folge des ChaosHacker-Talks sprechen wir über die Systeme, die wirklich kritisch sind: Produktionsanlagen, Steuerungen und industrielle Automatisierung.
Mein Gast ist Sarah Fluchs, Automatisierungsingenieurin, Security-Expertin für industrielle Systeme und Mitglied der Cyber Resilience Act Expert Group der EU-Kommission.
Wir schauen gemeinsam auf eine Realität, die viele Unternehmen unterschätzen:
Während IT-Security inzwischen relativ etabliert ist, stehen viele Produktionsumgebungen erst am Anfang.
Dabei geht es hier nicht nur um Daten.
Es geht um Ventile, Motoren, Produktionslinien – und im Life-Science Umfeld letztlich um Patientensicherheit.
Ein zentraler Teil der Diskussion ist der Cyber Resilience Act (CRA) der EU.
Er verpflichtet Hersteller erstmals dazu, Security bereits im Produktdesign zu berücksichtigen.
Für Unternehmen bedeutet das:
Produkte ohne Security-Konzept werden künftig nicht mehr verkäuflich sein
Betreiber müssen stärker verstehen, was in ihren Anlagen wirklich passiert
und Security muss früh im Engineering-Prozess beginnen – nicht kurz vor Go-Live.
Wir sprechen außerdem über:
die Unterschiede zwischen IT und OT
warum viele erfolgreiche Angriffe auf banalen Basics beruhen
warum Security oft an der falschen Stelle diskutiert wird
und warum eine saubere Risikoanalyse eines der mächtigsten Werkzeuge überhaupt ist.
Kurz gesagt:
Wenn Digitalisierung Produktion verändert, muss Security mitdenken.
Und zwar von Anfang an.
OT-Security ist nicht gleich IT-Security
Produktionssysteme haben andere Anforderungen – etwa Echtzeitfähigkeit, deterministische Kommunikation und lange Lebenszyklen.
Der Cyber Resilience Act verändert die Spielregeln
Hersteller müssen künftig Security-Anforderungen erfüllen, um digitale Produkte überhaupt verkaufen zu dürfen.
Security by Design statt Security als Nachgedanke
Sicherheitsanforderungen müssen bereits in Engineering- und Designprozessen berücksichtigt werden.
Viele Angriffe nutzen simple Schwachstellen
Offene Ports, fehlende Netzwerksegmentierung oder mangelnde Transparenz sind häufig die eigentlichen Probleme.
Risikoanalyse ist ein Entscheidungswerkzeug
Sie hilft zu priorisieren, wo Security wirklich relevant ist – und wo nicht.
Security darf keine Angstkommunikation sein
Ziel ist nicht, Nutzer einzuschüchtern, sondern Systeme so zu gestalten, dass Menschen sicher arbeiten können.
Ein gutes Systemverständnis ist der Schlüssel
Wer seine Prozesse, Systeme und Abhängigkeiten nicht versteht, kann auch keine wirksame Security aufbauen.
Cyber Resilience Act (EU)
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Konferenz: Security unter Kontrolle
https://security-unter-kontrolle.de
Buch: Countdown to Zero Day – Kim Zetter
https://www.penguinrandomhouse.com/books/318336/countdown-to-zero-day-by-kim-zetter/
Buch: Sandworm – Andy Greenberg
https://www.penguinrandomhouse.com/books/561678/sandworm-by-andy-greenberg/
Norm für OT-Security: IEC 62443
Key TakeawaysLinks aus der Episode
26 Minuten
Heute probiere ich im ChaosHacker-Talk mal etwas Neues.
Ich habe mir vier Podcasts vorgenommen, die ich in den letzten Wochen selbst gehört habe – und kommentiere sie aus meiner Perspektive als jemand, der täglich mit Digitalisierung, Datenprojekten und Regulierung im Life-Science-Umfeld zu tun hat.
Statt einer klassischen Podcastfolge gibt es diesmal eine Meta-Session: vier spannende Diskussionen aus der Community – plus meine Einordnung, wo ich zustimme, wo ich ergänzen würde und was Unternehmen daraus mitnehmen können.
Die vier Themen:
1. Enterprise Architecture und Business Architecture
Warum Architektur mehr ist als ein Framework – und warum sie besonders wichtig wird, sobald Prozesse, Daten und Organisation zusammenkommen.
https://www.youtube.com/watch?v=FtmtWDVYfoQ&t=2619s
2. Power BI vs. Qlik / ClickView
Ein spannender Blick auf BI-Tools – und die Erkenntnis, dass viele Tools am Ende ähnliche Probleme lösen. Die entscheidende Frage ist oft nicht das Tool, sondern der Kontext.
https://www.youtube.com/watch?v=vd1r02bj9Qk&t=1542s
3. Freelancing im Life-Science-Umfeld
Wann externe Experten sinnvoll sind – und warum Zusammenarbeit nur funktioniert, wenn Unternehmen intern die richtigen Ansprechpartner haben.
https://open.spotify.com/episode/7bkOvfQb9VGkShhZs5AM18?si=BCuzwyxhTdmbdRh47EYUXg
4. Warum KI-Projekte scheitern
Vom berühmten POC Prison bis zu falschen Problemdefinitionen: Warum viele KI-Initiativen nie aus der Pilotphase herauskommen.
https://www.youtube.com/watch?v=3ddzmntIkJA&t=2173s
Was mich an allen vier Gesprächen fasziniert hat:
Am Ende geht es immer wieder um dieselben Dinge - klare Entscheidungslogik, gute Kommunikation und echte Verantwortung für Daten und Systeme.
Oder anders gesagt:
Die meisten Probleme in Daten- und Digitalprojekten sind keine Technologieprobleme.
Ich habe mir vier Podcasts vorgenommen, die ich in den letzten Wochen selbst gehört habe – und kommentiere sie aus meiner Perspektive als jemand, der täglich mit Digitalisierung, Datenprojekten und Regulierung im Life-Science-Umfeld zu tun hat.
Statt einer klassischen Podcastfolge gibt es diesmal eine Meta-Session: vier spannende Diskussionen aus der Community – plus meine Einordnung, wo ich zustimme, wo ich ergänzen würde und was Unternehmen daraus mitnehmen können.
Die vier Themen:
1. Enterprise Architecture und Business Architecture
Warum Architektur mehr ist als ein Framework – und warum sie besonders wichtig wird, sobald Prozesse, Daten und Organisation zusammenkommen.
https://www.youtube.com/watch?v=FtmtWDVYfoQ&t=2619s
2. Power BI vs. Qlik / ClickView
Ein spannender Blick auf BI-Tools – und die Erkenntnis, dass viele Tools am Ende ähnliche Probleme lösen. Die entscheidende Frage ist oft nicht das Tool, sondern der Kontext.
https://www.youtube.com/watch?v=vd1r02bj9Qk&t=1542s
3. Freelancing im Life-Science-Umfeld
Wann externe Experten sinnvoll sind – und warum Zusammenarbeit nur funktioniert, wenn Unternehmen intern die richtigen Ansprechpartner haben.
https://open.spotify.com/episode/7bkOvfQb9VGkShhZs5AM18?si=BCuzwyxhTdmbdRh47EYUXg
4. Warum KI-Projekte scheitern
Vom berühmten POC Prison bis zu falschen Problemdefinitionen: Warum viele KI-Initiativen nie aus der Pilotphase herauskommen.
https://www.youtube.com/watch?v=3ddzmntIkJA&t=2173s
Was mich an allen vier Gesprächen fasziniert hat:
Am Ende geht es immer wieder um dieselben Dinge - klare Entscheidungslogik, gute Kommunikation und echte Verantwortung für Daten und Systeme.
Oder anders gesagt:
Die meisten Probleme in Daten- und Digitalprojekten sind keine Technologieprobleme.