Make or Buy bei KI in der Fertigung: Wie entscheiden?

Kaufen Sie, wenn das Problem Standard ist und Ihre Beschränkung die Zeit. Bauen Sie, wenn der Prozess wirklich Ihrer ist, wenn die Daten Ihr Werk nicht verlassen dürfen, oder wenn ein Produkt den größten Teil löst und der Rest genau dort liegt, wo das Geld ist. Für die meisten mittelständischen Hersteller lautet die ehrliche Antwort beim ersten Projekt kaufen, und zwei Projekte später oft bauen. Die Entscheidung ist weder ideologisch noch endgültig.

Schwieriger als in der Software ist das in der Fertigung, weil die Beschränkungen physisch sind. Eine Anbieterdemo läuft mit deren Beleuchtung, deren Vorrichtungen und deren Teilen. Ihre Linie hat drei Maschinengenerationen, eine Beleuchtung, die seit 2019 niemand justiert hat, und eine Produktvariante aus dem letzten Quartal, die niemand erwähnt hat. In dieser Lücke, nicht im Modell, entscheidet sich Make or Buy tatsächlich.

Was bekommen Sie beim Kaufen wirklich?

Schneller ein funktionierendes System und im Störungsfall das Problem eines anderen. Für Standardaufgaben mit Standardhardware kommt eine kommerzielle Vision- oder Instandhaltungsplattform mit gelöster Kameraauswahl, Beleuchtungsempfehlung, SPS-Anbindung und Supportvertrag. Dieses Bündel ist viel wert, und Teams, die es abtun, unterschätzen meist, wie viel eines KI-Projekts nicht das Modell ist.

Aufgeben müssen Sie Passgenauigkeit und Hebel. Das System tut, was der Anbieter festgelegt hat, Ihre Fehlerklassifikation muss sich seinen Kategorien beugen, und Ihre Weiterentwicklung ist seine Roadmap. Sie erben zudem eine Abhängigkeit: Fragt die Compliance, wie eine Entscheidung zustande kam, können Sie nur aus der Dokumentation antworten, die der Anbieter herausgibt.

Was kostet Bauen wirklich?

Mehr als das Modell, und in dieser Lücke platzen Budgets. Das Modell sind oft Wochen. Das System darum herum, also Datenerfassung von Maschinen, die nie zum Teilen gedacht waren, Labeln durch Menschen mit anderen Aufgaben, Anbindung an MES oder SPS, ein Rückfall für nicht verfügbare Inferenz, Monitoring und die Person, die im neunten Monat neu trainiert, ist der Großteil der Arbeit und nahezu der gesamte laufende Aufwand.

Bauen gewinnt wirklich dort, wo diese Kosten ohnehin unvermeidlich sind. Müssen Sie die Maschinendaten so oder so erfassen, müssen Sie labeln, weil kein Anbieter Ihre Fehler kennt, und müssen Sie in ein System integrieren, das kein Produkt unterstützt, dann ist ein Großteil der Baukosten schlicht der Preis des Projekts, und Kaufen legt eine Lizenz obendrauf, ohne ihn zu senken.

Wann ist Kaufen eindeutig richtig?

In vier Situationen, und sie zu erkennen spart Monate.

• Die Aufgabe ist Standard. Etiketten lesen, Anwesenheit prüfen, Maße erfassen, Barcodes kontrollieren. Das sind gelöste Probleme mit ausgereiften Produkten, und sie nachzubauen ist technische Nostalgie.
• Sie haben noch keine Daten. Ein Produkt mit vortrainierter Basis bringt Sie in einen funktionierenden Zustand, während ein Eigenbau noch Beispiele sammelt.
• Die Linie ändert sich häufig. Viele Produktvarianten sprechen für ein konfigurierbares Produkt statt für ein Modell, das Sie jedes Mal nachtrainieren, sofern das Nachtrainieren nicht wirklich automatisiert ist.
• Niemand kann es verantworten. Das ist entscheidend und wird regelmäßig übersehen. Ein Eigenbau ohne internen Verantwortlichen verfällt still; ein Anbietersystem ohne internen Verantwortlichen hat wenigstens eine Supportnummer.

Wann ist Bauen eindeutig richtig?

In drei Situationen, enger gefasst, als den meisten Entwicklungsteams lieb ist.

• Die Fehlerklassifikation ist Ihre. Sind Ihre Qualitätskriterien spezifisch für Ihr Produkt und Ihren Prozess und bildet kein Produkt sie ab, schließt Konfiguration die Lücke nicht.
• Die Daten dürfen nicht weg. Vertragliche oder regulatorische Vorgaben, die Cloud-Inferenz ausschließen, schließen meist auch die Produkte aus, wobei immer mehr davon On-premise-Betrieb anbieten.
• Ein Produkt bringt Sie zu achtzig Prozent. Die restlichen zwanzig sind oft genau der Wert, und nur diesen Teil zu bauen und den Rest anzubinden ist meist günstiger, als den Anbieter zu ersetzen.

Wie vergleicht man beides ehrlich?

Indem man denselben Umfang auf beiden Seiten bepreist, und genau hier mogeln die meisten Vergleiche still. Die Bauschätzung umfasst typischerweise Modell und Anbindung, die Kaufschätzung die Lizenz. Keine enthält die Arbeit, die beide teilen.

Setzen Sie die gemeinsamen Kosten in beide Spalten: Maschinendaten herausholen, labeln, den Arbeitsablauf ändern, Bediener schulen und die laufende Aufmerksamkeit nach dem Start. Was übrig bleibt, ist der echte Unterschied, und der ist meist kleiner als die Ausgangszahlen nahelegten. Unser Beitrag zur ROI-Berechnung für Machine-Learning-Projekte arbeitet die Lebenszyklusbetrachtung durch, auf der dieser Vergleich beruht.

Wie sieht die hybride Option aus?

Häufig die stärkste Antwort und die am wenigsten besprochene. Kaufen Sie, was Commodity ist, bauen Sie, was Ihres ist. In der Praxis heißt das eine kommerzielle Kamera mit Beleuchtung und ein eigener Klassifikator, oder eine Anbieterplattform für die Datenerfassung mit Ihrer Logik darauf, oder ein fertiges Modell, nachtrainiert auf Ihren Fehlerbildern.

Der Hybrid lohnt sich, weil er Ihre Entwicklungsarbeit dorthin lenkt, wo Ihre Differenzierung liegt, und alles andere einkauft. Er kostet mehr Integrationsaufwand als beide reinen Optionen, was der ehrliche Kompromiss ist, und er braucht jemanden, der die Architektur halten kann. Das ist oft die eigentliche Beschränkung, ob er Ihnen offensteht.

Welcher Fehler ist teurer?

Zu früh bauen, mit Abstand. Ein verfrühter Eigenbau verbraucht ein Jahr, erzeugt ein System, das auf einen inzwischen veränderten Prozess zugeschnitten ist, und hinterlässt eine interne Wartungspflicht, die niemand eingeplant hat. Zu früh kaufen kostet eine Lizenzperiode und etwas Integrationsaufwand, und Sie behalten die Daten und das Prozesswissen.

Diese Asymmetrie spricht dafür, zuerst zu kaufen, wenn die Antwort wirklich unklar ist, und dann zu bauen, sobald Sie genau wissen, wo das Produkt zu kurz greift. Das Wissen aus dem Betrieb eines gekauften Systems ist ein erheblicher Input für einen späteren Bau, und anders ist es nicht zu bekommen. Wie wir in Predictive Maintenance: wann sie funktioniert und wann nicht dargelegt haben, sind die enttäuschenden Projekte meist jene, die vor den Voraussetzungen gestartet wurden.

Wie wirkt sich der EU AI Act auf die Entscheidung aus?

Weniger, als die meisten Hersteller befürchten, aber er verschiebt, wer die Pflichten trägt. Kaufen macht Sie in der Regel zum Betreiber, der leichteren Rolle: bestimmungsgemäße Verwendung, kompetente menschliche Aufsicht, Logs aufbewahren, betroffene Beschäftigte informieren. Bauen macht Sie zum Anbieter, mit technischer Dokumentation, Risikomanagement und Konformitätslast.

Zwei Punkte zum Mitdenken. Ein Anbietermodell auf eigenen Daten nachzutrainieren oder umzuetikettieren kann Sie ohne bewusste Entscheidung in Anbieterpflichten bringen. Und übernimmt die KI eine Sicherheitsfunktion in Maschinen, gilt die Maschinenverordnung ab dem 20. Januar 2027 mit erforderlicher benannter Stelle, was in beiden Fällen eine Beschaffungsfrage ist. Das ganze Bild steht in EU AI Act für produzierende KMU.

Die ehrliche Zusammenfassung

Kaufen Sie, wenn die Aufgabe Standard ist, wenn Sie noch keine Daten haben, oder wenn intern niemand ein Eigenbausystem verantworten wird. Bauen Sie, wenn die Fehlerklassifikation Ihre ist, wenn die Daten nicht weg dürfen, oder wenn ein Produkt fast bis ans Ziel bringt und der Rest der Wert ist. Vergleichen Sie beides, indem Sie denselben vollen Umfang auf beiden Seiten bepreisen, einschließlich alles Gemeinsamen, denn genau darin unterscheiden sich ehrliche Vergleiche von überzeugenden.

Bleibt die Antwort wirklich unklar, ist das eine Information: Meist bedeutet es, dass der Anwendungsfall nicht eng genug beschrieben ist, um überhaupt etwas zu vergleichen. Ein strategisches Audit für mittelständische Fertiger klärt das, bevor ein Weg festgelegt wird, und die Seite zur Fertigungspraxis beschreibt, wo wir üblicherweise beginnen.

Häufige Fragen

Können wir mit einem Anbieter starten und später bauen?

Ja, und oft ist das die günstigste Abfolge. Der Betrieb eines gekauften Systems zeigt Ihnen genau, wo es zu kurz greift, und das ist die Spezifikation, die ein späterer Bau braucht. Behalten Sie ab dem ersten Tag eine eigene Kopie der Bilder und Labels, denn diese Daten sind das Gut, das den Wechsel möglich macht, und manche Verträge sind beim Eigentum daran unklar.

Wie bewerten wir eine Anbieterdemo fair?

Bestehen Sie darauf, dass sie auf Ihren Teilen, Ihrer Beleuchtung und Ihren schlechtesten Fällen läuft, nicht auf deren Mustern. Fragen Sie nach der Leistung bei den seltensten Fehlerarten, denn dort unterscheiden sich Produkte am stärksten. Ein Anbieter, der Ihre unangenehmen Fälle nicht testen will, hat die Frage beantwortet.

Braucht Bauen ein Data-Science-Team?

Für ein erstes Projekt nicht. Nötig ist jemand, der das System nach dem Start verantwortet, und genug Entwicklungskapazität für die Anbindung. Teams, die Spezialisten einstellen, bevor der erste Anwendungsfall validiert ist, haben am Ende meist teure Leute und kein definiertes Problem.

Was, wenn der Anbieter das Produkt einstellt?

Ein reales Risiko bei kleineren Lieferanten und einzupreisen. Abhilfe schaffen eigene Daten, standardisierte statt proprietärer Schnittstellen und das Wissen, wie der Ausstieg aussieht, vor Vertragsschluss statt während einer Störung.