Einstieg: Die Tür nach 2030

Die Idee, die liegen blieb

Daraus wurde eine Idee. Wenn ich in einer Schulung erklären kann, wie man zwei Datentypen sinnvoll gegeneinander aufträgt, dann folgt das einer Regel. Und wenn es einer Regel folgt, müsste man Zusammenhänge aus strukturierten Datensätzen auch automatisiert ableiten und so aufbereiten können, dass ein Mensch das Muster sofort erkennt. Künstliche Intelligenz war zu dem Zeitpunkt etwas für Techies, nichts, was man einem Mittelständler hingestellt hätte.

Ich habe die Idee einem befreundeten Professor erzählt. Er fand den Gedanken interessant, jedoch hielt er ihn für technisch nicht machbar. Den Algorithmen fehle der Kontext. Ich habe dagegengehalten: Auf einer Meta-Ebene seien die Zusammenhänge doch immer dieselben, je nachdem, welche Arten von Daten man miteinander kombiniert. Er winkte ab.

Dann habe ich mich auf sein Urteil verlassen und meine Gedanken erst einmal als “fixe Idee” abgestempelt. Es gab noch ein paar zaghafte Versuche, aber meine Programmierkenntnisse reichten nicht weit genug, Mitstreiter fand ich keine, und kurz darauf zog die Post-Merger-Integration den gesamten Fokus auf sich. Die Idee blieb liegen.

Jahre später saß ich bei “AI in the Forest”, einem Treffen aus dem Umfeld des Industrial AI Podcast. Dort ging es unter anderem um ein Forschungsvorhaben namens TabPFN, ein Modell für tabellarische Daten aus der Gruppe um Frank Hutter. Ich hörte zu und erkannte Elemente meiner Hypothese wieder: weiter gedacht, sauber(er) formuliert und mathematisch unterlegt.

Aus dem Forschungsvorhaben wurde ein Unternehmen. Prior Labs, gegründet Ende 2024, sammelte im Februar 2025 neun Millionen Euro Pre-Seed ein.¹ Gut ein Jahr später kündigte SAP die Übernahme an, verbunden mit der Ansage, über vier Jahre mehr als eine Milliarde Euro zu investieren.²

Mein Konzept war bei weitem nicht so weit wie das erste der Gründer, und deren Expertise auf diesem Feld ist ungleich größer. Ob ich zu früh dran war oder schlicht nicht reif genug, ist inzwischen egal. Für mich bleibt ein anderer Punkt: Ich habe einen Experten gefragt, statt einen Prototyp zu bauen. Er hat Nein gesagt, und das hat gereicht.

Zwischen einer Idee und einem Produkt liegt Arbeit, die jemand anfangen muss. Ich habe sie nicht angefangen. Davon handelt dieses Buch.

Ein Zielbild für 2030

2030, irgendwo in Deutschland: In einer Fabrik laufen Qualitäts- und Prozessdaten während der Schicht zusammen, nicht erst Wochen später im Bericht. Die Linie zeigt eine Abweichung. Das System regelt nach, oder es stoppt. Ohne Hektik, weil die Grenzen vorher feststehen.

Im Leitstand sitzt jemand mit Entscheidungsrecht. Diese Person versteht das System, kennt die Guardrails und entscheidet im Zweifel. Kein Flaschenhals, der jede Freigabe abzeichnet.

Zur gleichen Zeit im Service: Ein Kunde bekommt eine schnelle Lösung oder eine saubere Übergabe. Menüs und Warteschleifen sind die Ausnahme geworden.

Ein Zielbild, zugegeben. Aber eines, das nah genug ist, um heutige Entscheidungen daran zu messen: Datenflüsse, Verantwortlichkeiten, Eskalationswege, Lernzyklen.

Darum geht es in diesem Buch: was sich im Betrieb verändert. Über 2030 entscheiden Schichtpläne, Schnittstellen und Eskalationswege. Strategiedecks entscheiden gar nichts.

Die Kernthese für den “German Way”

“The German Way”, was soll das sein? Ich verstehe darunter einen Betriebsmodus: schnell lernen, sauber skalieren, mit klaren Planken und klaren Ownern. Dazu eine Frage, die in jedes Prozess-, Monats- oder Quartals-Review gehört: Was ändert sich durch die datenbasierte Erkenntnis im Betrieb? Silicon Valley zu imitieren, wie dies lange Jahre probiert wurde, steht nicht auf der Liste.

Und genau hier bremsen wir uns selbst. Denn an Substanz fehlt es nicht: industrielle Kompetenz, Prozesswissen, Ingenieurdenken, Mittelstand, Umsetzungshärte. Uns fehlt digitale Betriebsdisziplin. Also eine Organisation, die aus Daten Entscheidungen macht, aus Vorfällen Lernzyklen und aus Piloten Standards, die es danach gilt flächendeckend einzuführen und Skalierung erlebbar zu machen.

Deshalb möchte ich vorne weg klar und unmissverständlich sein. Es geht mir weder um Kulturkampf (USA gut, Europa schlecht, oder umgekehrt), noch um Tool-Listen, die in zwei Quartalen schon wieder veraltet sind oder gar um Innovationstheater, das auf Bühnen gut klingt und im Kerngeschäft nichts verändert. Ich setze den Fokus auf Entscheidungen, die man messen kann, gepaart mit Rollen, die nicht nur berichten, sondern handeln dürfen und ein Operating Model, das Tempo ermöglicht, ohne Verantwortung zu verlieren.

Zur Einordnung: Die Szenen zu 2030 in diesem Kapitel sind als Zielbild oder Nordstern geschrieben, nicht als Prognose.

Warum die Reise bei 2030 beginnt

Wir reden in Deutschland gerne über 2035, 2040, 2050. Bequem für Visionen. Für Entscheidungen ist es eine elegante Form der Vertagung.

2030 ist nah genug, dass heutige Architektur-, Daten- und Rollenentscheidungen bis dahin harte Folgen haben. Und vielleicht auch in den Vertragszeitraum der entsprechenden Unternehmenslenker fallen. Gleichzeitig ist 2030 weit genug weg, dass wir Strukturen, Schnittstellen und Routinen noch umbauen können. Wenn wir heute anfangen.

Dieses Buch startet beim Betrieb. Ob Systeme später teilautonom laufen, ob Service schneller wird, ob Daten zwischen Bereichen nutzbar sind: Das entscheidet sich lange vor dem Modell und lange vor dem Tool. Es entscheidet sich bei Guardrails, Ownership, Interoperabilität und Lernzyklen.

Drei Prinzipien, die sich durch das ganze Buch ziehen

1) Guardrails statt Null-Fehler-Illusion

Viele Organisationen verwechseln Sicherheit mit Stillstand. Absicherung ersetzt dann Steuerung: Entscheidungen kommen zu spät, Verantwortung diffundiert, Lernen wird zur Ausnahme.

Guardrails legen fest, was niemand verletzen darf. Dadurch entsteht Tempo. Wer die verbindlichen Grenzen kennt, entscheidet innerhalb dieser Planken schneller. Bei jedem Abfahrtsrennen ist es genauso: die blauen Markierungen im Schnee weisen auf die beste Linie hin. Abweichungen haben teils schwerwiegende Folgen.

Bei Künstlicher Intelligenz (KI) in risikobehafteten Anwendungen steht das auch im Gesetz. Der EU AI Act verlangt für High-Risk-AI wirksame menschliche Aufsicht: Zuständige müssen das System verstehen, Anomalien erkennen, Ergebnisse übergehen oder umkehren und das System in einen sicheren Zustand bringen können.³

Praktisch und konkret heißt das: In der Produktion braucht es definierte Schwellen, bei denen das System nachregelt, stoppt oder eskaliert. Im Service braucht es Fälle, in denen Automatisierung endet und Verantwortung sichtbar an einen Menschen übergeht. Im Datenmanagement braucht es klare Governance-Regeln für Zwecke, Zugänge und Verantwortlichkeiten, festgelegt beim Entwurf und nicht im Nachtrag.⁴

Die Management-Konsequenz: Wenn du Tempo willst, definiere zuerst die Stop-Kriterien. Wenn du Sicherheit willst, entwirf den Eskalationsweg. Alles andere führt zu der typisch deutschen Kombination aus großer Vorsicht und erstaunlich wenig Kontrolle.

2) Ownership statt Organigramm

“Niemand ist zuständig” ist ein Betriebsmodell. Ein schlechtes, aber eines, das jeden Tag läuft.

Je vernetzter und datengetriebener Systeme werden, desto härter wird die Frage: Wer entscheidet im Moment der Wahrheit? Stop oder weiter? Rollback oder Hotfix? Eskalation oder Freigabe?

Die Antwort darauf kann nicht dauerhaft “das Gremium” sein. Gremien sichern ab. Sie führen aber keinen Betrieb.

Eine moderne Organisation braucht Rollen mit End-to-End-Verantwortung für Betrieb, Monitoring und Eskalation. In der Softwarewelt kennen wir diese Logik als DevOps. In industriellen Umgebungen entsteht gerade etwas Ähnliches, langsamer als nötig. Ich nenne es in diesem Buch Production Operations (ProdOps) Engineer: eine Eskalations- und Betriebsrolle für teilautonome Produktionssysteme.

Der Begriff ist austauschbar, die Zielsetzung und Idee nicht. Jemand trägt Verantwortung für den laufenden Betrieb teilautonomer Systeme, nicht nur für den Projektstart. Dies sorgt für Identifikation, Empowerment und Motivation. Ein regulatorisches Beispiel hierfür: Ein strukturierter Ansatz wie der NIST AI RMF hilft dabei, KI-Risiken systematisch zu managen, für Individuen, Organisationen und Gesellschaft.⁵

Die Rolle des ProdOps Engineers ist IT, OT und Qualität in einem oder einfach gesagt: eine Funktionsbezeichnung mit ausgewiesenem Entscheidungsrecht. So wird Ownership real, wenn jemand stoppen, ein Rollback anordnen und Standards erzwingen darf. Und wenn die Führung diese Person an Wirkung misst, dann ist der erste Schritt umgesetzt und “live”.

3) Interoperabilität ist Management, nicht IT

Wenn Daten nicht miteinander sprechen, ist das fast immer ein Führungsproblem. Das Tool kommt erst danach.

Welche Begriffe gelten? Welche Schnittstellen sind verbindlich? Wer entscheidet bei Konflikten? Welche Minimal-Norm gilt für alle, auch wenn die perfekte Lösung später kommt?

Politisch und industriell ist die Richtung gesetzt: Die EU baut auf Common European Data Spaces als vertrauenswürdige und sichere Umgebungen für Zugang, Sharing und Wiederverwendung von Daten.⁶ Gleichzeitig benennt der Data Act die Bremsen ungewöhnlich offen: Data Silos, schwaches Metadatenmanagement und fehlende semantische und technische Standards.⁷

Interoperabilität ist damit Management-Arbeit. Leider unglamourös und wenig Blumentöpfe zu gewinnen, denn sie entscheidet darüber, ob Daten je zusammenfinden.

Eine Daumenregel für die Praxis: Interoperabilität beginnt mit fünf Führungsfragen, lange vor dem ersten Datenkatalog.

1. Welche 20 Begriffe müssen im Kerngeschäft eindeutig sein?
2. Welche Schnittstelle ist verbindlich, und für wen?
3. Wer ist Owner des Standards, und was darf diese Person entscheiden?
4. Wie wird Abweichung sichtbar und was passiert dann?
5. Was ist die Minimal-Norm in den nächsten 90 Tagen?

Was an den 2030-Szenen real ist und was Zielbild bleibt

Produktion: Die Richtung ist klar, die Arbeit leider auch

Plattform Industrie 4.0 beschreibt seit Jahren die intelligente Vernetzung von Maschinen und Prozessen sowie die Kombination und Analyse von Produktionsdaten.⁸ Die acatech-Empfehlungen haben die strategische Richtung früh benannt und dabei die deutsche Stärke in Automation und eingebetteten Systemen hervorgehoben.⁹

Die Idee trägt. Es hakt bei der Übersetzung in den Alltag. Aus einem strategischen Zielbild wird keine Betriebsrealität, solange Datenkompetenz, Informationssysteme und organisatorische Fähigkeiten nicht mitwachsen.¹⁰

Auch Robotik-Trends taugen als Makroindikator für zunehmende Automatisierung.¹¹ Prozessarbeit im Werk ersetzen sie nicht. Ein Roboter macht noch kein Operating Model, zehn oder hundert übrigens auch nicht.

Service und Verwaltung: Anspruch ja, Heilsversprechen nein

Für Services steht die Richtung ebenfalls auf dem Papier. Das Digital Decade Policy Programme beschreibt bis 2030 digitale, effiziente, vertrauenswürdige und personalisierte Services, bei gleichzeitiger Aufrechterhaltung von Offline-Zugänglichkeit während des Übergangs.¹²

Das räumt mit zwei Fehlern auf einmal auf: mit dem Glauben, alles bleibe wie es ist, und mit der Vorstellung, alles werde vollautomatisch, friktionsfrei und für jeden Fall gleich gut.

Der Management-Anspruch lautet: Warteschleifen sind nicht mehr unser Default. Wer null Warteschleifen für alle verspricht, verkauft eine Folie.

Daten: Governance ist keine Bremse, sondern Architektur

Sobald Daten zwischen Bereichen, Partnern oder Systemen fließen sollen, wird Governance konkret. Der Data Governance Act macht klar, dass dadurch keine neue Rechtsgrundlage für die Verarbeitung personenbezogener Daten entsteht; im Konfliktfall hat Datenschutzrecht Vorrang.¹³

Wer das für Bürokratie hält, denkt zu kurz. Es ist eine Architekturbedingung. Gute Datenräume entstehen dort, wo Teams Regeln in praktikable Mechanismen übersetzen. Wegwünschen hat noch keine Schnittstelle gebaut.

Catena-X zeigt, dass das mehr ist als Theorie: ein kollaboratives Datenökosystem im Automotive-Kontext, das Standards und Governance zusammendenkt.¹⁴

Die neue Eskalationsrolle: ProdOps Engineer

Wer ein System teilautonom laufen lässt, ohne vorher festzulegen, wer im Ernstfall eingreift, hat die Autonomie nicht zu Ende gedacht.

Ein ProdOps Engineer verantwortet in diesem Buch den laufenden Betrieb teilautonomer Produktionssysteme, samt Monitoring, Incident Response und Eskalation. Die Rolle ist die betriebliche Schaltstelle zwischen OT, IT, Qualität und Führung. Wer nur beobachtet und abnimmt, füllt sie nicht aus.

Drei Dinge sind dafür nicht verhandelbar:

1. Kompetenz Die Rolle muss Datenfluss, Systemgrenzen, typische Failure Modes und die Grenzen der Automatisierung verstehen.

2. Autorität Die Rolle muss entscheiden dürfen: stoppen, rollbacken, freigeben, eskalieren.

3. Lernzyklus Ein Vorfall gehört zurück ins System, in Regeln, Parameter, Sensorik oder Standards. Eine Präsentation ist kein Lernzyklus.

Der einfache Test für jede Organisation lautet daher:

• Darf diese Rolle stoppen?
• Darf sie rollbacken?
• Darf sie Standards erzwingen?
• Und wird sie an Lösungszeit, Wiederholrate und Stabilität gemessen, oder nur daran, möglichst wenig zu stören?

Wenn die Antworten ausweichen, ist die Rolle noch kein Betriebselement. Dann ist sie Dekoration.

Wie aus einem Vorfall ein Lernzyklus wird

Zurück zu der Linie vom Kapitelanfang, an der Stelle, an der das System gestoppt hat. Dort entscheidet sich der Rest.

Keine Kette aus Abstimmungsrunden. Die zuständige Eskalationsrolle hat Zugriff auf die relevanten Daten, kennt die definierten Grenzen und entscheidet: Rollback auf die letzte stabile Parametrisierung, danach ein kontrollierter Neustart.

Am nächsten Tag hat der Vorfall Spuren im System hinterlassen: eine neue Plausibilitätsprüfung, einen zusätzlichen Sensor, eine klarere Eskalationsschwelle. Dokumentiert ist er auch, aber das ist der kleinere Teil.

So entsteht operative Verbesserung: kurze Lernzyklen unter klarer Verantwortung. In den meisten Organisationen endet dieselbe Szene mit einem Protokoll und einem Termin.

Ampel-Check

Den Selbstcheck zu diesem Kapitel (5 Dimensionen, Grün/Gelb/Rot) findest du gebündelt im Anhang: Selbstcheck.

KI im Einsatz

Hebel: KI macht Abweichungen schon während der Schicht sichtbar und schlägt Entscheidungen vor, statt sie in spätere Berichte zu verschieben.

Guardrail: Klare Eskalation an eine menschliche Rolle mit Autorität (ProdOps); keine unprüfbare Autonomie in kritischen Entscheidungen.

Erster Schritt: Einen realen Prozess wählen und festlegen, welches Signal KI in Echtzeit sichtbar machen soll.

Takeaways

Der Maßstab für dieses Kapitel: 2030 entsteht aus betriebsfähigen Entscheidungen im Hier und Jetzt.

• 2030 ist ein Management-Test für heutige Entscheidungen, kein fernes Leitbild.
• Guardrails sind die Voraussetzung für Geschwindigkeit.¹⁵
• Ohne klaren Owner wird jede Autonomie zur organisierten (und tolerierten) Unverbindlichkeit.
• Interoperabilität ist zuerst eine Führungsaufgabe und erst dann ein Tool-Thema.¹⁶¹⁷
• Datenräume ohne Governance bleiben Folklore.¹⁸
• Eine Eskalationsrolle wie der ProdOps Engineer verbindet Verantwortung und Lernfähigkeit im Betrieb.
• KI skaliert dort, wo Betrieb, Daten und Entscheidungen zusammenfinden. Die Technologie ist selten der Engpass.

Die Zukunft kommt ohnehin. Interessant ist, ob dein Betrieb mit ihr arbeiten kann. Dafür ist die folgende Checkliste gedacht.

Und dann kommt die Frage, an der sich alles Weitere entscheidet: Woran merkt ihr eigentlich, ob die Digitalisierung bei euch wirkt? Damit beginnt das nächste Kapitel.

Checkliste (Do this tomorrow)

• Wähle 1 End-to-End-Flow aus Produktion, Service oder Verwaltung, für den du Lösungszeit oder Stillstandszeit sichtbar messen kannst.
• Definiere 1 Guardrail, das Iteration ermöglicht: Was darf auf keinen Fall passieren?
• Benenne 1 Owner für den Flow, mit explizitem Entscheidungsrecht.
• Identifiziere 1 Interoperabilitätsblocker und setze eine pragmatische Minimal-Norm für die nächsten 90 Tage.
• Entwirf deinen Eskalationspfad: Wer greift wann ein, und wie wird aus einem Vorfall innerhalb von 7 Tagen eine sichtbare Systemverbesserung?