Willkommen bei IT-Verbistnis. Ich bin Mirko Peters. Wir arbeiten als IT-Dienstleister für den Mittelstand und hier geht es nicht um Marketing-Hype, sondern um echte Entscheidungen in der IT.
Wir sprechen über Infrastruktur, Cloud Migration und Security aus der Praxis.
Wenn Sie Verantwortung für die IT-Tragen oder Dienstleister bewerten müssen, sind Sie hier genau richtig.
Vernetzen Sie sich auch gerne mit mir auf linken, denn ich schätze den direkten Austausch über reale Projekte sehr.
Lassen Sie uns kurz das Rauschen ausblenden. Wenn wir über KI in der Fertigung sprechen, reden fast alle über Modelle oder Kupiloten.
Erstaunlich wenige, sprechen dagegen über Ausschuss, Stillstand und den massiven Aufwand im Betrieb, der nach dem Pilotprojekt erst richtig anfängt, genau dort versteckt sich aber das eigentliche Risiko für ihr Budget.
In dieser Folge schauen wir uns an, wo KI in der Fabrik wirklich Geld verdient und wo sie nur Kapital bindet.
Wir blicken dabei bewusst auf die Realität im Mittelstand, also auf Brownfield-Anlagen, knappe Personalresourcen und eine laufende Produktion ohne Spielraum für Experimente.
Bleiben Sie kurz dran, denn der teuerste Fehler passiert oft schon, bevor Sie überhaupt ein Tool auswählen.
Warum KI-Projekte in der Fertigung oft am Budget scheitern?
Sein wir ehrlich, in den meisten Fällen sprengt nicht die KI-Technik an sich das Budget.
Die Rechnung beginnt viel früher bei einer schlechten Ausgangslage, die man beim Projektstart gerne ignoriert, weil die Däme auf den Folien so sauber wirkt.
Was dann in der Realität fehlt, ist selten nur ein schlaues Modell.
Es fehlt am sauberen Datenzugriff und an einer klaren Architekturverantwortung.
Wenn Maschinendaten lokal liegen und Prozessdaten in einem anderen System stecken, während wichtige Infos in Exel gepflegt werden, bauen sie kein tragfähiges Vorhaben.
Sie bauen stattdessen teure Umwege, die später jeden kleinen Schritt im Betrieb massiv erschweren.
Das sehen wir in Fertigungsumgebungen ständig.
Eine Anlage liefert Werte in einem speziellen Format, das MES nutzt eine eigene Logik und das ERP kennt zwar den Auftrag, aber nicht den technischen Zustand der Maschine.
Dazwischen sitzen dann manuelle Schnittstellen und Skripte, die auf Einzelwissen basieren.
Auf dem Papier wirkt das alles verbunden, aber im täglichen Betrieb ist diese Konstruktion extrem brüchig.
Jetzt wird es interessant, denn hier liegt der Unterschied über den Anbieter ungeansprechen.
Im Labor funktioniert fast alles reibungslos, weil die Bedingungen dort künstlich sauber gehalten werden.
Es gibt definierte Datensätze, keine Schichtwechsel und keine Störung aus dem echten Werkalltag.
In der Fabrik sieht die Welt anders aus. Da Kameras verschmutzten, Teile variieren und Anlagen, nicht exakt so stehen wie im Testaufbau.
Entscheidungen müssen hier in einen laufenden Prozess passen und nicht in eine schicke Präsentation.
Damit wird aus einer technischen Idee sehr schnell ein Handfest des Betriebsproblemen.
Es geht plötzlich nicht mehr darum, ob ein Modell grundsätzlich etwas erkennt, sondern ob das Ergebnis in der Früschicht genau so brauchbar ist wie nachts um 2 Uhr.
Sie müssen wissen, ob ein Anlagenstellstand korrekt erfasst wird und ob ihre Mitarbeiter verstehen, warum das System heute anders entscheidet als noch letzte Woche.
Klar Text. Das ist keine Technikfrage, das ist eine Architekturfrage.
Wenn zwischen Maschine, EAP und diversen Schattenlisten eine Frankenstein-Integration entsteht, zahlen sie nicht nur bei der Einführung drauf.
Sie zahlen jeden Monat im Betrieb weiter, weil jede kleine Änderung sofort hohen Folge aufwandt nach sich zieht.
Jede neue Linie braucht dann wieder eine eigene Sonderlogik und jeder Standort kocht sein eigenes Sübchen.
Hier beginnt das, was viele in der Kalkulation schlicht unterschätzen. Die Day 2 Operations.
Das ist alles, was nach dem Go-Life niemand mehr spannend findet, aber zuverlässig Geld kostet. Modelle müssen überwacht und die Datenqualität muss permanent geprüft werden.
Wenn sich Produkte oder Prozesse ändern, kann das ein komplettes Retraining nötig machen. Dazu kommen Support, Security und die Dokumentation, die oft sträflich vernachlässigt wird. Überlegen Sie mal.
Ein KI-System ist kein klassisches Stück Software, das man einmal installiert und dann einfach vergisst.
Wenn sich die Datenbasis verändert, sinkt auch die Güte ihres Modells. Wenn niemand diesen Betrieb sauber organisiert, läuft das Projekt nur scheinbar stabil, bis die Fachbereiche anfangen, eigene Workerowns zu bauen.
Dann bricht das Vertrauen in die Lösung langsam aber sicher weg. Besonders teuer wird es in der typischen POC-Falle.
Ein kleiner Pilot an einer einzelnen Linie liefert einen guten Effekt und alle sind erst einmal zufrieden. Wenn sie dann aber skalieren wollen, zeigt sich das Problem.
Die Schnittstellen wurden nur lokal gebaut und die Datenbegriffe sind zwischen den Werken überhaupt nicht einheitlich.
Der Pilot war also kein Einstieg in eine echte Lösung, sondern nur ein teurer Sonderfall ohne Zukunft. Wenn sie ihr Budget schützen wollen, reicht technische Begeisterung allein nicht aus.
Sie müssen Anwendungsfälle wählen, bei denen der wirtschaftliche Schmerzreal ist und die technische Grundlage nicht schon beim ersten Rollout auseinanderfällt.
Architektur schlägt Tools. Stellen Sie deshalb zuerst die harten Fragen, bevor Sie den nächsten Vertrag unterschreiben. Wo die niedrigen Früchte wirklich hängen. Wenn Sie mit KI in der Fertigung starten wollen, dann bitte nicht dort, wo das Projekt intern am modernsten klingt.
Gehen Sie dort hin, wo heute schon jeden Monat Geld verloren geht, weil Fehler zu spät erkannt werden, Abläufe unnötig manuell sind oder wissen im Betrieb zu lange gesucht werden muss.
Sein wir ehrlich. Die meisten Unternehmen suchen zuerst die große Vision und übersehen dabei die sauberen kleinen Hebel direkt vor der eigenen Nase.
Der erste Bereich liegt meist sehr nahe, die visuelle Qualitätsprüfung. Das ist nicht interessant, weil Kameras neu wären, sondern weil der wirtschaftliche Schmerz hier absolut klar ist.
Die Schuss kostet Material, Maschinenzeit und am Ende oft auch das Vertrauen beim Kunden. Danach arbeite Personal bindet, dass ein anderer Stelle fehlt, entstehen schnell engpässe in der gesamten Linie.
Reglamationen kommen zu dem gern erst dann zurück, wenn der eigentliche Verursacher im Prozess längst nicht mehr sauber nachvollziehbar ist.
Eine KI gestützte Sichtprüfung kann hier stabil helfen, sofern Sie ein klar abgegrenztes Merkmalprüfen und das Ergebnis nahrtlos in den Ablauf passt.
Der Vorteil ist banal aber wirksam. Das System prüft gleichförmig, es kennt keine müde Spätschicht und keinen hektischen Schichtwechsel. Genau das macht solche Fälle oft wirtschaftlich.
Direkt daneben liegt ein zweites Feld, das gern so groß gedacht wird, predictive maintenance.
Viele Staaten gedanklich sofort bei der komplett vorausschauenden Instandhaltung über das ganze Werk, was im Strategie-Papier zwar ordentlich klingt, für den Einstieg aber oft der falsche Weg ist.
Sinfola ist hier eine "Predictive maintenance light". Nehmen Sie wenige kritische Anlagen, bei denen ein ungeplanter Ausfall wirklich wehtut und arbeiten Sie dort gezielt mit anomalia Kennung.
Also nicht gleich die perfekte Ausfallvorhersage für das nächste Jahr anstreben, sondern erst einmal die saubere Frage klären.
Verhalten sich, Schwingung, Temperatur, Stromaufnahme oder Laufzeit, gerade ungewöhnlich.
Das ist deutlich pragmatischer, technisch einfacher umzusetzen und im harten Betriebsalltag meist belastbarer. Ein drittes Feld wird oft unterschätzt, weil es nicht nach klassischer Fabrika-E aussieht, Assistenz am Schopflor.
Dabei liegt hier erstaunlich viel Potenzial, gerade in Werken mit hoher Variantenvielfalt, Schichtbetrieb und knappen Fachkräften.
Überlegen Sie mal, wie viel Zeit verloren geht, wenn ein Mitarbeiter erst fünf Ordner, alte Tickets und PDF-Dateien durchsuchen muss, um ein wiederkehrendes Fehlerbild einzuordnen.
Die digitale Arbeitsanweisung, die Kontext bezogen die richtige Information zeigen oder Schichtprotokolle, die nicht nur abgelegt, sondern auswertbar werden, lösen dieses Problem.
Das Spart vielleicht nicht spektakulär in einer einzelnen Minute, aber im laufenden Betrieb somiert sich genau dieser Reibungsverlust massiv.
Und noch wichtiger, sie machen sich ein Stück Unabhängiger von individuellem Einzelwissen.
Auch in der Logistik und Materialfluss hängen einige der niedrigsten Früchte. Die Etikettenerkennung ist dafür ein gutes Beispiel.
Das klingt unspektakulär hat aber oft eine sehr klare Wirkung, weil Prozesse im Waren-Eingang bei der Zuordnung oder bei internen Umläufen dadurch sauberer und schneller laufen.
Dazu kommen Vollständigkeitsprüfungen und einfache Klassifikationen etwa bei Behältern, Teilen oder Dokumenten.
Solche Anwendungen sind selten Pristiespräjekte, aber genau deshalb sind sie interessant.
Sie berühren einen eng umrissenen Prozess, liefern schnell messbare Ergebnisse und greifen meist weniger tief in die Produktionssteuerung ein, als große Automatisierung vorhaben.
Ein weiterer Bereich ist die Planung, aber bitte im kleinen Rahmen. Rechnen sie nicht sofort die komplette Fabrik neu und kaufen sie nicht direkt den größten Optimierer am Markt ein.
Schauen sie lieber auf ihre Engpassanlagen und fragen sie sich, ob einfache Reihenfolgevorschläge helfen können, Rüstwechsel zu senken oder Störungen besser abzufedern.
Wenn eine KI-Logik an einer Engpassstelle bessere Vorschläge liefert, dann sehen sie den Effekt relativ direkt in den Zahlen.
Das ist etwas anderes als der Versuch, auf einen Schlag die gesamte Produktionsplanung intelligenter zu machen, da sich dort sonst schnell mehr Komplexität als echter nutzen versteckt.
Die eigentliche Auswahl ist am Ende ziemlich nüchtern. Gute Einstiegsfälle haben fünf klare Eigenschaften.
Erstens hohe Wiederholung.
Wenn ein Vorgang ständig vorkommt, lohnt sich die Verbesserung fast immer. Zweitens Messbare Kosten. Wenn sie Ausschussprüfzeit oder Störungsfolgen nicht bezufahren können, wird der Nutzen schnell zur reinen Glaubensfrage.
Drittens. Vorhandene Daten oder zumindest Daten, die sich ohne Groß-Umbau erfassen lassen.
Viertens. Ein begrenzter Prozess, der nicht sofort das halbe Werk berührt. Und fünftens. Ein möglichst geringer Eingriff in die OT.
Sie wollen schließlich nicht schon im ersten Pilotprojekt an Freigaben, Netzgrenzen und der Maschinenlogik scheitern.
Wenn ihnen das bekannt vorkommt, sie sind nicht allein. Und es ist löstbar. Genau dort, bei den greifbaren Problemen, würde ich beginnen.
Aber ein brauchbarer Use-Case-Alein löst das Problem noch nicht. Sobald zwischen Shop-Flor und IT die Grundlage wackelt, wird selbst die sinnvollste Idee unnötig teuer.
Die Architekturfrage, die vor jedem KI-Projekt geklärt sein muss. Bevor sie über Modelltypen, Anbieter oder Plattformen sprechen, gehört eine andere Frage auf den Tisch.
Wo entstehen die Daten eigentlich? Wehm gehören sie im Betrieb und wer darf sie für welchen Zweck nutzen.
Das klingt zunächst nach Governance und damit nach einem trockenen Nebenkriegschaubplatz. In der Praxis entscheidet aber genau, dass darüber, ob ein KI-Vorhaben sauber läuft,
oder schon bei der ersten Abstimmung zwischen Produktion, IT und Dienstleister hängen bleibt.
Klartext, Architektur schlägt Tools, denn Shop-Flor und klassische IT folgen nicht denselben Regeln.
In der OT zählt zuerst die Verfügbarkeit, die Anlage soll stabil und ohne unnötige Eingriffe laufen.
In der IT hingegen ist Veränderung völlig normal, sei es durch Updates, Neuschnitzstellen oder neue Auswertungen.
Dazu kommt ein Zweiterkonflikt, Safety gegen Änderungsdruck.
In der Produktion kann eine unbedachte Anpassung reale, physische Folgen haben, während dieselbe Anpassung in der IT oft als Routine gilt.
Wenn diese beiden Welten ohne klare Betriebsmodell auffeinander treffen, entsteht Reibung statt Fortschritt.
Im Mittelstand verschärft sich das durch das Thema Brownfield. Wir reden hier von Anlagen, die über Jahre gewachsen sind, mit alten Steuerungen, propräitären Protokollen und lokalen Sonderwegen.
Diese sind oft aus einer pragmatischen Entscheidung heraus entstanden und dann einfach geblieben. Das ist kein Ausnahmefall, sondern vielerorts der normal betrieb.
Nur wird daraus schnell ein Problem, wenn ein KI-Projekt plötzlich durchgängige Datenflüsse erwartet, die es real so nie gegeben hat.
Da versteckt sich das Risiko für jedes Budget.
Was sich in solchen Umgebungen bewährt, ist kein großes Zukunftsbild mit maximaler Zentralisierung.
Tragefähig ist meist ein einfaches Muster, Maschine, Kopplungsschicht, Datenplattformen.
Die Maschine bleibt dort, wo sie hingehört, während die Kopplungsschicht sammelt, puffert, übersetzt und sauber trennt.
Erst danach landen die Daten auf einer Plattform, auf der sie sie auswerten, verknüpfen und für KI nutzen können.
Das ist deutlich vernünftiger, als jede Quelle direkt an irgendeinen Clouddienst zu hängen und später überrascht festzustellen, dass man weder Übersicht noch Kontrolle hat.
Lassen Sie uns das kurz zerlegen. Die Kopplungsschicht ist nicht nur Technik zum Verbinden, sie ist auch ein Schutzmechanismus.
Dort legen sie fest, welche Daten überhaupt herausdürfen, in welchem Takt, in welchem Format und mit welcher Absicherung.
Gerade bei älteren Anlagen ist das Goldwert, weil sie die Produktionswelt nicht jedes Mal umbauen müssen, nur, weil auf der IT-Seite ein neuer Anwendungsfall auftaucht.
Betrachten sie es wie ein Haus, das renoviert wird.
Sie wollen nicht bei jedem neuen Lichtschalter die gesamte Startig angreifen müssen.
Genau an dieser Stelle sitzt auch das Sicherheitsthema.
KI darf keine Seiten-Tür ins Produktionsnetz werden. Wenn sie neue Sensorik, Gateways oder externe Dienst da einführen, öffnen sie potentiell neue Angriffsflächen für Schadsoftware.
Das lässt sich beherrschen, aber nicht mit dem Reflex, einfach alles blind zu verbinden, was irgendwie Daten liefert.
Sie brauchen segmentierung, klare Netzgrenzen und saubere Rechte.
Anders gesagt, der Wunsch nach mehr Datenzugriff darf nie wichtiger werden als die Stabilität des Werks.
Dazu kommt ein Punkt, der oft unterschätzt wird. Rohdaten allein haben wenig Wert.
Ein Stromwert, ein Kamerabild oder eine Temperaturkurve ist ohne Kontext nur ein Signal im Rauschen.
Erst wenn sie diese Daten mit dem Auftrag der Charge der Maschine oder einer konkreten Störung zusammenbringen, entsteht etwas nutzbares.
Sonst trainieren sie bestenfalls auf Mustern, die technisch interessant wirken, fachlich aber keine belastbarer Aussage liefern.
Genau deshalb scheitern viele Vorhaben nicht an zu wenig Daten, sondern an zu wenig Kontext.
Darum würde ich die Architektur immer vor die Toolauswahl stellen, nicht weil Tools unwichtig wären, sondern weil einfache, wiederholbare Bausteine auf Dauer mehr tragen als fünf Spezialösungen.
Wenn diese jeweils nur für einen Einzelfall optimiert wurden, ergeben sie zusammen kein Gesamtbild, sondern eine Frankenstein-Integration.
Wenn sie heute schon wissen, dass ein erfolgreicher Pilot später auf weitere Linien oder Standorte ausgerollt werden soll, dann bauen sie von Anfang an mit derselben Logik.
Gleiche Schnittstellen, gleiche Datenbegriffe, gleiche Verantwortung.
Sobald diese Grundlage steht wird die Diskussion sachlicher. Dann reden sie nicht mehr über KI als Wageschlagwort, sondern über einen konkreten Nutzen auf einer belastbaren Basis.
Und genau dann lohnt es sich, den nächsten Schritt sauber zu rechnen und klein zu starten, statt groß zu versprechen.
Sprechen sie mit ihrem Team, bevor sie unterschreiben. Stellen sie zuerst die Harten-Fragen, nicht die bequem.
So rechnen sie ROI ohne sich selbst etwas vorzumachen.
Sobald die Architekturfrage halbwegs sauber beantwortet ist, kommen wir zu dem Punkt, an dem sich die Spräu vom Weizen trennt.
Hier entscheidet sich, ob ihr Projekt auf einem Solidenfundament steht oder ob sie sich in die eigene Tasche lügen.
Wir reden über die Wirtschaftlichkeit und die beginnt eben nicht mit den bunten Hochrechnungen aus einem Anbieter Deck, sondern mit einer knallharten Baseline aus ihrem eigenen Betrieb.
Sie müssen zuerst einmal wissen, was der ist, zustand sie heute wirklich kostet.
Wie viel Zeit fließt in manuelle Prüfungen, wie hoch ist die Ausschussquote tatsächlich und wie oft müssen Teile in die Nacharbeit.
Überlegen sie mal, welche Stillstandszeiten sie so richtig Geld kosten und was Reklamationen am Ende der Kette für ihren Ruf und ihr Budget bedeuten.
Ohne diese nackten Ausgangswerte lässt sich jeder Pilotversuch wunderbar schön rechnen, weil am Ende niemand belegen kann, ob die Verbesserung real ist oder nur gut präsentiert wurde.
Genau deshalb ist es ein Fehler, den Nutzen abstrakt für das ganze Werk zu kalkulieren.
Rechnen sie lieber Prolinie, Pro Engpass oder Profehlerklasse.
Wenn eine ganz bestimmte Fehlerart regelmäßig die Nacharbeit befeuert, dann ist das ihr Bezugspunkt.
Wenn eine einzelne Anlage bei jeder kleinen Störung den gesamten Materialfluss ausbremst, dann setzen sie dort an. Alles andere klingt zwar auf dem Papier strategische Wertvoll, hilft ihnen bei einer harten Investitionsentscheidung aber kein Stück weiter.
Dann gibt es noch einen zweiten Teil, den sie sauber trennen müssen.
Carpex und Obags. Also die einmaligen Investitionen gegen die laufenden Kosten.
Die ersten Gruppe gehören typischerweise die Hardware, Kameras, Edgegeräte und die Integration in ihre bestehenden Systeme. Auch Anpassungen an Schnittstellen oder externe Berater fallen hier runter.
Zur zweiten Gruppe zählen die Zänsten der laufende Support, das Monitoring und die Wartung der Modelle.
Vergessen sie dabei nicht den internen Aufwand, der im Alltag gerne mal unter den Tisch fällt.
Wenn diese beiden Blöcke in einer einzigen Sammelzahl verschwinden, fehlt ihnen später jede Grundlage, um den Betrieb ehrlich zu bewerten. Klartext.
Gerade bei KI-Projekten liegen die verdeckten Kosten selten dort, wo man zuerst hinschaut.
Ein klassischer Kostentreiber ist das Labeling. Jemand muss die Daten sichten, markieren und für das Training überhaupt erst brauchbar machen.
Dazu kommt die Datenaufbereitung, denn Rohdaten aus der Fertigung kommen selten fertig sortiert aus der Maschine.
Sie müssen bereinigt, zugeordnet und fachlich eingeordnet werden, bevor sie einen Wert haben.
Dann folgen noch Freigabeprozesse, Schulungen und Security-Brüfungen.
Oft kommen noch Abstimmungen mit der Qualitätssicherung oder den Betriebsrad dazu.
Das ist kein lästiges Beiverg, sondern das gehört fest in die Kalkulation.
Ein weiterer Denkfehler sitzt oft bei den Personalkosten.
Viele Business-Cases tun so, als würden eingesperrte Minuten automatisch zu einem echten Personal abbaufhören.
In der Praxis passiert meistens etwas ganz anderes. Die Mitarbeiter werden verlagert, fangen Ausnahmen ab oder übernehmen die Kontrolle des neuen Systems.
Oft arbeiten sie auch einfach Rückstände auf die vorherliegen geblieben sind. Das kann wirtschaftlich absolut sinnvoll sein, nur eben anders als es auf der bunten Marketingfolie stand.
Wenn sie diese Verschiebung als volle Einsparung ansetzen, bauen sie sich die Enttäuschung für das nächste Jahr direkt mit ein.
Viel belastbarer wird ihre Rechnung, wenn sie auf die vermiedenen Kosten schauen.
Weniger Ausschuss, weniger Nacharbeit und stabile Prozesse sind harte Währungen.
Wenn an einer kritischen Stelle weniger Störungen auftreten, lässt sich das im Fertigungsumfeld meist deutlich ehrlicher greifen als pauschale Aussagen über die allgemeine Produktivität.
Das gilt besonders dann, wenn sie den Nutzen über einige Monate gegen den echten Ausgangswert halten und nicht gegen eine optimistische Erwartungshaltung, dazu gehört auch, dass sie einen Piloten nicht als Prestige-Projekt aufsetzen, sondern als echte Entscheidungsvorlage.
Das bedeutet, ein kurzer Zeitraum, ein Klabegrenz das Gop und ein deutige KPIs.
Legen sie vorab eine Abbruchregel fest. Wenn der Effekt unter einer bestimmten Schwelle bleibt, stoppen sie das Ganze.
Wenn die Datenqualität nicht ausreicht oder der Eingriff in den Betrieb größer wird als geplant, ziehen sie die Reisleine oder verkleinern den Skop.
Das klingt vielleicht unspektakulär, schützt aber ihr Budget und vor allem ihre Glaubwürdigkeit im Unternehmen.
Am Ende des Tages brauchen sie keine große KI-Erzählung für den Geschäftsbericht. Sie brauchen eine nüchterne Rechnung, die dem harten Alltag im Werk stand hält.
Und genau daraus ergibt sich dann fast von selbst die nächste Frage. Wie setzen sie so ein Vorhaben praktisch auf?
Ohne das aus einem sauberen Pilotprojekt wieder ein loses Sammelsurium aus teuren Sonderwegen wird?
Ein pragmatischer Fahrplan für den Mittelstand.
Wenn sie das Thema jetzt angehen wollen, brauchen sie keinen Masterplan mit 20 Arbeitspaketen, sondern eine vernünftige Reihenfolge. Erstens wählen sie einen Prozess mit echtem Schmerzfaktor, einem klaren verantwortlichen und einem begrenzten Umfang.
Schreiben sie nicht.
Qualität verbessern über das Projekt, sondern suchen sie sich eine konkrete Prüfstelle oder eine Anlage aus, deren Ausfall regelmäßig hohe Folgekosten verursacht.
So lange niemand fachlich wirklich den Hut aufhat, wird das Vorhaben in endlosen Abstimmungsrunden versanten. Der zweite Schritt ist deutlich nüchterner als viele IT-Begeisterte hoffen.
Prüfen sie die Datenlage, bevor sie überhaupt über Lösungen sprechen. Welche Daten gibt es wirklich, wie steht es um die Qualität und wer hat technisch oder rechtlich Zugriff darauf?
Zwischen der Aussage, die Daten liegen theoretisch vor und sie sind produktiv nutzbar, liegt in vielen Werken eine erstaunlich große Lücke.
Wenn Zeitstempel nicht zusammenpassen oder Verantwortlichkeiten für die Datenquelle unklassend, wird aus einem kleinen Piloten ganz schnell ein riesiges Aufräumprojekt.
Danach sollten sie das Zielbild festlegen und dieses bewusst eng stecken.
Wollen sie ein Assistent-System, das den Menschen besser informiert? Geht es um die reine Erkennung von Fehler oder Abweichungen?
Wollen sie eine Prognose für die Zukunft erstellen? Oder geht es tatsächlich um die volle Automatisierung?
Alles gleichzeitig zu wollen ist meistens der Anfang vom Ende. Jede dieser Richtung bringt völlig andere Anforderungen an dem Betrieb, das Risiko und die Eingriffstiefe mit sich.
Im vierten Schritt setzen sie den Piloten so auf, dass ihr Betrieb nicht zum Versuchslabor wird. Eine Linie, ein Merkmal, ein KPI und ganz wichtig, planen sie einen Fallback ein, falls das Ergebnis im Alltag nicht trägt.
Dieser Plan B ist in der Fertigung lebensnotwendig. Wenn die KI-Unterstützung ausfällt oder unsauber arbeitet, muss der Prozess trotzdem sicher weiterlaufen können.
Sonst erzeugen sie intern genau das Mistrauen, das ihnen spätere Rollouts komplett blockiert.
Richtig interessant wird es beim fünften Punkt, den viele Teams viel zu spät klären.
Wer betreibt das Ganze eigentlich nach dem Piloten? Jemand muss die Ergebnisse überwachen, Qualitätsverluste erkennen und Änderungen am Modell oder am Prozess dokumentieren.
In diese Fragen erst nach dem Go-Life-Auftauchen landet das Thema irgendwo im Niemandsland zwischen Fachbereich, IT und dem externen Dienstleister.
Dann fühlt sich jeder nur noch halbzuständig und genau an diesem Punkt wird es richtig teuer.
Der sechste Schritt betrifft die Skalierung aber eben erst, wenn das Fundament steht. Rollen sie die Lösung nicht aus, nur weil der Pilot technisch irgendwie funktioniert hat.
Skalieren sie nur dann, wenn die Architektur das auch sauber hergibt.
Das bedeutet gleiche Schnittstellen, gleiche Datenlogik und eine einheitliche Governance.
Sobald jede weitere Linie wieder zu einem Sonderfall wird, haben sie keine Lösung gebaut, sondern eine Sammlung lokale Ausnahmen mit einem gemeinsamen Etiquette.
Lassen Sie mich zum Schluss dieses Fahrplans noch einen ganz nüchternden Punkt ansprechen.
Manche Prozesse sind für KI-Schlichtweg noch nicht reif. Das liegt oft nicht an der fehlenden Technologie, sondern daran, dass der Prozess selbst zu unernheitlich oder schlecht dokumentiert ist.
In solchen Fällen bringt eine saubere Standardisierung erst einmal deutlich mehr als jedes neuronale Netz.
Das wirkt zwar weniger modern, ist aber oft der ehrlichere und wirtschaftlichere nächste Schritt.
Genau daran entscheidet sich am Ende der Wert eines Vorhabens.
Es geht nicht darum, ob das Kürzel KI im Projektplan steht, es geht darum, ob die Lösung im Werk unter realen Bedingungen zuverlässig ihren Nutzen bringt.
Sprechen Sie mit Ihrem Team und stellen Sie diese harten Fragen, bevor Sie den nächsten Vertrag unterschreiben.
Gute KI beginnt nicht bei Modell, das war IT für Business für heute. Wenn Sie aus diesem Gespräch einen Gedanken mitnehmen, dann hoffentlich diesen.
Echte KI-Erfolge in der Fertigung hängen nicht am neuesten Modell.
Es geht vielmehr um saubere Prozesse, belastbare Daten und eine Architektur, die auch morgen noch trägt.
Suchen Sie sich mit Ihren Leuten einen konkreten Prozess aus, bei dem Ausschuss oder Stillstand heute schon echtes Geld verbrenden.
Bevor Sie Staaten müssen Sie die harten Fragen stellen. Klären Sie genau, woher die Daten kommen, wer später den Betrieb verantwortet und wo Ihre Sicherheitsgrenzen verlaufen.
Rechnen Sie den R&E nicht dann durch und legen Sie fest, wann Sie einen Piloten auch mal konsequent abbrechen.
Falls Sie gerade eine Modernisierung oder die Kopplung von OT und IT-Planen sprechen Sie zuerst über die Architektur.
Der teuerste Fehler versteckt sich fast nie im KI-Projekt selbst, sondern in der Infrastruktur, die darunterliegt. Wir hören uns in der nächsten Folge.