Die schlechteste Build-vs.-Buy-Entscheidung im IoT ist nicht die falsche Kostenannahme. Es ist die falsche Definition des Systems. Wer IoT wie klassische Softwarebeschaffung behandelt, verliert nicht zuerst Geld, sondern Kontrolle über Updatepfade, Datenmodell, Integrationslogik und Feldbetrieb.

Genau deshalb ist build vs buy iot systemdesign keine Einkaufsfrage. Es ist eine Governance-Entscheidung über Eigentum an Systemverantwortung. In Deutschland hat sich zwar der Buy-Ansatz in IIoT-Projekten deutlich verstärkt, mit kürzerer medianer Implementierungszeit von 9 Monaten statt 16 und einem Break-even nach 12 statt 20 Monaten bei Buy-Projekten. Gleichzeitig meldeten 43 % der Buy-Nutzer kürzere Amortisationszeiten, wie in den dort zusammengefassten Ergebnissen der Bitkom-Studie beschrieben wird. Die operative Attraktivität ist real, aber sie ersetzt keine Architekturverantwortung. Das gilt besonders dann, wenn Datenhoheit, Sicherheitsmodell und Lebenszyklusfähigkeit Teil des Produkts sind. Eine saubere Einordnung dieser Verantwortung beginnt bei der Datenhoheit im IoT.

Entscheidungslogik	Build	Buy	Systemische Konsequenz
Differenzierung	Sinnvoll bei produktprägendem Verhalten	Sinnvoll bei standardisierten Basisschichten	Falsche Zuordnung zerstört Produktprofil
Lebenszyklus	Hohe interne Dauerverantwortung	Externe Abhängigkeit bleibt bestehen	Verantwortung verschwindet nie
Integration	Höchste Freiheit an Schnittstellen	Schnellere Erstumsetzung bei stabilen Grenzen	Instabile Grenzen erzeugen Reibung
Datenmodell	Volle architektonische Kontrolle	Risiko proprietärer Abstraktion	Spätere Migration wird teuer
Betrieb	Eigene Betriebsreife erforderlich	Vendor entlastet Teilbereiche	Incident-Verantwortung bleibt intern

Warum Build vs. Buy im IoT keine klassische Sourcing-Frage ist

Klassische IT-Beschaffungslogik führt im IoT systematisch in Fehlentscheidungen. Ein IoT-Produkt ist kein Bündel austauschbarer Komponenten, sondern ein gekoppeltes Betriebssystem aus Gerät, Firmware, Konnektivität, Backend und Lebenszyklusbetrieb.

Wer Enterprise-Software einkauft, bewertet meist Funktionen, Lizenzmodell und Integrationsaufwand. Wer ein vernetztes Produkt verantwortet, entscheidet über physische Geräte im Feld, über Updatefähigkeit unter Betriebsbedingungen, über Fehlersuche ohne physischen Zugriff und über Sicherheitsverantwortung über mehrere Jahre. Das ist eine andere Kategorie von Risiko.

Im IoT verschiebt sich die Build-vs.-Buy-Grenze deshalb weg von Features und hin zu Schnittstellenhoheit. Sobald Hardwareverhalten, Firmwarezustände, Telemetrie, Gerätemanagement und Serviceprozesse verbunden sind, verändert jede Layer-Entscheidung die nächste. Ein ausgelagerter Baustein bleibt nie isoliert. Er prägt Datenstruktur, Diagnosefähigkeit, Security-Maßnahmen und Supportmodell.

Das eigentliche Entscheidungsobjekt

Das Entscheidungsobjekt ist nicht die einzelne Plattform oder das einzelne Modul. Das Entscheidungsobjekt ist das integrierte Produktsystem. Dazu gehören Hardware, Embedded Firmware, Konnektivität, Device Management, Cloud-Backend, Datenmodell, Sicherheitsarchitektur, OTA-Updates, Monitoring, Support, Compliance und Lifecycle Maintenance.

Ein gekauftes Teil entlastet nur dort, wo seine Systemgrenzen stabil bleiben. Im IoT ist genau das selten. Ein Connectivity-Baustein beeinflusst Zertifizierung, Energieprofil und Feldstabilität. Ein Device-Management-Dienst beeinflusst Updatefenster, Recovery-Pfade und Incident-Abläufe. Eine Backend-Abstraktion beeinflusst, welche Daten später überhaupt auswertbar, migrierbar oder regulatorisch sauber dokumentierbar sind.

Gekauft wird oft Implementierung. Behalten werden muss fast immer die Verantwortung.

Das Missverständnis mit der Geschwindigkeit

Die Attraktivität von Buy ist nachvollziehbar. Standardisierte Teile reduzieren den Erstaufwand. Das ist sinnvoll, solange der zugekaufte Teil nicht zum verdeckten Eigentümer der Produktlogik wird. Genau hier kippt die Entscheidung. Sobald eine externe Lösung Zustandsmodell, Datenhoheit oder Updatepfad prägt, ist sie kein neutraler Beschleuniger mehr, sondern ein strategischer Kontrollpunkt.

Diese Trennung ist der Kern jeder belastbaren iot make-or-buy entscheidung. Wer sie nicht explizit trifft, baut keine Architektur. Er übernimmt nur fremde Annahmen.

Die zentrale Frage Welche Systemverantwortung darf ausgelagert werden?

Build vs. Buy im IoT wird an der falschen Stelle entschieden, wenn nur über Einkauf, Implementierung oder Time-to-Market gesprochen wird. Entscheidend ist, wer das Produktsystem langfristig steuert und wer im Krisenfall handlungsfähig bleibt.

Ausgelagert werden dürfen nur Leistungen, nicht die Führungsverantwortung über das System. Im IoT bleibt die Haftung für Funktion, Sicherheit, Datenverfügbarkeit, Updatefähigkeit und regulatorische Nachweise beim Hersteller oder Betreiber. Wer diese Ebenen an einen Anbieter bindet, gibt keinen Betriebsbaustein ab, sondern ein Stück Produktkontrolle.

Die eigentliche Governance-Frage lautet daher: Welche Verantwortung muss intern geführt werden, weil sie Produktverhalten, Datenhoheit, Risikosteuerung oder Exit-Fähigkeit bestimmt? Genau an dieser Stelle entscheidet sich, ob ein IoT-System beherrschbar bleibt oder später vom Lieferantenmodell diktiert wird. Für die Frage der Datenhoheit im IoT ist das der zentrale Prüfpunkt.

Verantwortung je Systemschicht

Bei Hardware und Embedded Firmware darf nur ausgelagert werden, was technisch klar abgegrenzt und strategisch austauschbar bleibt. Sobald Energieprofil, Regelverhalten, Sensorinterpretation, Safety-Logik oder Diagnosepfade das Produktversprechen prägen, muss die Architekturhoheit intern liegen. Sonst hängt die Weiterentwicklung des Produkts an fremden Roadmaps, fremden Prioritäten und fremden Freigabeprozessen.

Bei Konnektivität und Device Management ist Fremdbezug oft sinnvoll. Die Steuerung der Zustände darf trotzdem nicht nach außen wandern. Wer Provisionierung, Rechte, OTA-Regeln, Rollback-Mechanismen und Fehlerklassifikation nicht selbst definiert, verliert die operative Kontrolle über die Flotte. Im Feldbetrieb ist das kein Detail, sondern eine Führungsfrage.

Bei Cloud-Backend, Identitäten und Datenmodell liegt das höchste Langfristrisiko. Dort werden spätere Servicefähigkeit, Migration, Auditierbarkeit, Analytics und Monetarisierung festgelegt. Wenn ein Anbieter Datenstrukturen, Eventlogik oder Mandantentrennung vorgibt, prägt er die Geschäftsgrenzen des Produkts mit. Das ist keine technische Komfortentscheidung, sondern eine Weichenstellung für die nächsten Jahre.

Ein weiterer Punkt wird in vielen Programmen zu spät erkannt. Verantwortung endet nicht an der API-Grenze. Fällt ein Update aus, entsteht eine Sicherheitslücke oder fehlt ein Nachweis für ein Audit, haftet nicht der Plattformanbieter am Markt, sondern das verantwortliche Unternehmen gegenüber Kunden, Behörden und Partnern.

Deshalb braucht jede Buy-Entscheidung vier harte Prüfgrößen: Wer besitzt das Zustandsmodell. Wer entscheidet über Änderungen am Datenmodell. Wer kontrolliert Eskalation und Recovery. Wer kann den Anbieter mit vertretbarem Aufwand ersetzen.

Für Vorstand, Produktleitung und Architektur gilt eine klare Regel. Auslagern kann man Implementierung und begrenzte Betriebsleistungen. Intern bleiben müssen Architekturhoheit, Sicherheitsentscheidungen, Datenverantwortung, Integrationslogik und Lifecycle-Steuerung.

Leitlinie: Wer Updatepfad, Datenmodell oder Integrationslogik nicht kontrolliert, kontrolliert das IoT-Produkt nicht.

Wo Buying sinnvoll ist – und wo es gefährlich wird

Buying ist im IoT sinnvoll, wenn die Schicht standardisiert, nicht differenzierend und sauber abgrenzbar ist. Buying wird gefährlich, sobald der zugekaufte Teil verdeckt Systemkontrolle übernimmt.

Die stärkere Präferenz für Buy in Deutschland ist rational. In den in einer Bitkom-Auswertung beschriebenen IIoT-Projekten stieg der Buy-Anteil bei Initiativen ab 2021 auf 30 %, nach 9 % zuvor. Für die ersten zwei Projektphasen lag die mediane Implementierungszeit bei 9 Monaten statt 16 Monaten im Build-Modell, der Break-even bei 12 Monaten statt 20 Monaten. 43 % der Buy-Nutzer berichteten von kürzeren Amortisationszeiten. Diese Daten sind ein valider Hinweis auf operative Entlastung, nicht auf automatische Architekturqualität. Die Werte sind in der Auswertung zu IoT-Lösungsentwicklung und Build-vs.-Buy im IIoT zusammengefasst.

Buying ist dort stark, wo die Funktion austauschbar bleiben darf. Das betrifft standardisierte Konnektivitätsbausteine, generische Infrastruktur, normierte Sicherheitsprimitive oder klar isolierte Betriebsfunktionen. Dort entsteht Tempo, ohne dass das Produkt seine Identität verliert.

Sichere Kaufzonen

Sicher ist Buy nur dann, wenn vier Bedingungen gleichzeitig gelten. Die Funktion ist nicht differenzierend. Die Schnittstellen sind stabil. Die Datenverantwortung bleibt intern klar. Und der Anbieter wird nicht zum inoffiziellen Eigentümer von Betriebslogik oder Produktzustand.

In solchen Fällen ist iot eigenentwicklung vs standardlösung keine ideologische Frage. Dann ist Standardisierung diszipliniert. Interne Teams sollten keine Zeit auf Basisschichten binden, wenn daraus keine verteidigbare Produktposition entsteht.

Gefährliche Kaufzonen

Gefährlich wird Buy bei Black-Box-Backends, proprietären Datenmodellen, opaken Edge-Komponenten und geschlossenen Device-Management-Schichten. Dort wirkt die Lösung am Anfang bequem. Später blockiert sie Migration, Diagnostik, Security-Interventionen und Serviceinnovation.

Besonders kritisch ist das dort, wo Sicherheitsarchitektur und Betriebsverantwortung ineinandergreifen. Wer den Mechanismus für Identität, Schlüsselrotation, Updatefreigabe oder Recovery nur indirekt beeinflussen kann, akzeptiert strukturelle Risiken. Die entscheidende Perspektive ist deshalb nicht Einkaufsvorteil, sondern Sicherheitsarchitektur im IoT.

Wo Building strategisch notwendig bleibt

Building ist dort zwingend, wo das Produktverhalten, die Sicherheitslage oder die Datenarchitektur den Unternehmenswert tragen. Interne Entwicklung ist kein Selbstzweck, aber in diesen Schichten nicht verhandelbar.

Strategisch notwendig bleibt Building bei allen Elementen, die den Charakter des Produkts bestimmen. Dazu gehören Embedded-Verhalten im Feld, domänenspezifische Firmware-Logik, produktprägende Datenverarbeitung, die semantische Struktur der Betriebsdaten und die Regeln, nach denen das System Entscheidungen trifft. Wer diese Ebenen auslagert, überträgt nicht Aufwand, sondern Souveränität.

Das bedeutet nicht, jede Zeile selbst zu schreiben. Es bedeutet, dass Architektur, Spezifikation, Eigentum an Kernlogik und Entscheidungsgewalt intern verankert bleiben müssen. Der Unterschied ist entscheidend. Eigenentwicklung ohne klares Eigentumsmodell erzeugt nur fragile Sonderlösungen. Gesteuerte Eigenentwicklung sichert dagegen Anpassbarkeit, Servicefähigkeit und Exit-Optionen.

Unverzichtbare interne Eigentumszonen

Die erste Eigentumszone ist das Geräteverhalten. Wenn Firmware festlegt, wie das Produkt misst, reagiert, priorisiert oder degradiert, ist das kein austauschbarer Code. Es ist Produktkern.

Die zweite Eigentumszone ist die Datenarchitektur. Das umfasst Identitäten, Zustände, Ereignisse, Historisierung und die Zuordnung zwischen Gerät, Nutzer, Servicefall und Geschäftsprozess. Wer dieses Modell nicht beherrscht, kann weder Servicequalität noch Erweiterbarkeit zuverlässig steuern.

Die dritte Eigentumszone ist die Sicherheits- und Updatefähigkeit. Sicherheitsverantwortung lässt sich organisatorisch delegieren, aber nicht strategisch abgeben. Nur wer diese Schicht beherrscht, kann auf Schwachstellen, regulatorische Änderungen und Feldprobleme mit ausreichender Präzision reagieren.

Wer den Kern baut, hält nicht nur IP. Er hält Reaktionsfähigkeit unter realen Betriebsbedingungen.

Building als Disziplin, nicht als Stolzprojekt

Viele Teams verwechseln Building mit maximaler Eigenfertigung. Das ist ein Fehler. Strategisch richtig ist nicht Vollbau, sondern präzise Eigentumsdefinition. Gerade in der iot produktentwicklung build buy muss die Organisation unterscheiden zwischen Kernlogik und Commodity-Schichten.

Building ist deshalb nur dort richtig, wo externe Roadmaps, proprietäre Einschränkungen oder undurchsichtige Abstraktionen das Produkt später strukturell behindern würden. In diesen Bereichen ist eigene Kontrolle günstiger als spätere Abhängigkeit.

Die versteckten Folgekosten falscher Make-or-Buy-Entscheidungen

Die Erstkosten sind im IoT selten das Problem. Die eigentlichen Schäden entstehen durch Folgekosten über den Lebenszyklus.

Ein schlechtes Buy erzeugt keine einfache Lieferantenbeziehung, sondern mehrjährige Abhängigkeit. Ein schlechtes Build erzeugt keine Unabhängigkeit, sondern eigene technische Last ohne ausreichende Betriebsreife. Beides wird in frühen Business Cases regelmäßig unterschätzt, weil dort meist Beschaffung oder Entwicklungsaufwand bewertet werden, nicht Feldbetrieb, Security-Ereignisse, Migration, Supporttiefe und Organisationsfähigkeit.

Die belastbarsten Warnsignale liegen auf der Build-Seite. In einer 2024 zusammengefassten Studie des Fraunhofer IAO zu IIoT-Projekten in der deutschen Fertigung galten nur 26 % der rein intern entwickelten Plattformen als vollständig erfolgreich, während 60 % bereits in der Proof-of-Concept-Phase scheiterten. Für enterprise-taugliche Eigenentwicklung lagen die Kosten in mittelständischen Unternehmen oft bei über 200.000 €, ohne laufende Wartung. Hybride Buy-and-Build-Ansätze erreichten dagegen 72 % Erfolgsrate und konnten den TCO um bis zu 40 % senken. Diese Angaben sind in der Zusammenfassung zu Build-vs.-Buy bei IoT-Plattformen und Backend-Architekturen aufgeführt.

Die teuren Fehler auf der Buy-Seite

Fehlentscheidungen beim Kauf zeigen sich selten in der Einführungsphase. Sie zeigen sich in Change Requests, Integrationsausnahmen, fehlender Transparenz bei Vorfällen und in teuren Migrationsszenarien. Ein proprietäres Datenmodell kostet nicht nur Flexibilität. Es erschwert spätere Analyse, Serviceautomatisierung und regulatorische Nachweisführung.

Hinzu kommt die operative Entkopplung. Wenn Diagnose, Gerätezustände oder Updatehistorie nur über vendor-spezifische Abstraktionen sichtbar sind, verliert das interne Team seine Handlungsfähigkeit. Dann wird jeder Sicherheitsvorfall, jede Produktvariante und jede Serviceanpassung zum Verhandlungsthema.

Die teuren Fehler auf der Build-Seite

Fehlentscheidungen beim Build entstehen, wenn Unternehmen nicht differenzierende Infrastruktur selbst tragen, ohne die dafür nötige langfristige Organisation aufzubauen. Dann wachsen Wartung, Personalabhängigkeit, Dokumentationslücken und Release-Risiken. Das Ergebnis ist keine Souveränität, sondern eine selbst erzeugte Lock-in-Struktur mit internem Eigentümer.

Besonders riskant ist das im Mittelstand. Dort binden proprietäre Basisschichten knappe Engineering-Kapazität an Themen, die keinen Marktvorteil erzeugen. Gleichzeitig bleibt zu wenig Fokus für die wirklich wertstiftenden Schichten des Produktsystems.

Partner statt Komponenten: Warum IoT oft ein drittes Modell braucht

Wer im IoT nur zwischen Build und Buy entscheidet, delegiert die eigentliche Architekturfrage an den Einkauf. Das ist ein Governance-Fehler. Die tragfähige Option lautet: Systemhoheit intern halten, Umsetzungspartner strikt führen.

Dieses Modell trennt Verantwortung dort, wo sie im IoT über die Zukunft des Produkts entscheidet. Die Organisation behält die Kontrolle über Zielarchitektur, Datenmodell, Sicherheitsprinzipien, Betriebsregeln und Lifecycle-Vorgaben. Externe Partner liefern klar abgegrenzte Leistungen innerhalb dieser Leitplanken.

So entsteht keine Abhängigkeit von einem Komplettanbieter und keine interne Überlastung durch selbst gebaute Basisschichten. Es entsteht ein gesteuertes Systemdesign mit klarer Verantwortungsordnung.

Warum dieses Modell im IoT überlegen ist

IoT scheitert selten an fehlender Implementierungskapazität. Es scheitert an unklarer Systemverantwortung über Jahre hinweg. Genau dort setzt das Partnermodell an.

Firmware kann ein Spezialdienstleister entwickeln. Die Geräteanbindung kann von einem Integrator kommen. Ein externer Partner kann auch Cloud-Bausteine, Testautomatisierung oder Betriebsservices liefern. Entscheidend ist etwas anderes. Das Unternehmen selbst muss festlegen, wie diese Teile zusammenwirken, welche Daten wohin fließen, welche Sicherheitsgrenzen gelten und wer Änderungen freigibt.

Das ist keine Beschaffungslogik, sondern Architekturführung. Wer diese Führung abgibt, verliert früher oder später die Kontrolle über Produktentwicklung, Servicefähigkeit und Datenzugriff. Wer sie behält, kann Partner austauschen, Leistungen neu schneiden und das System über Markt-, Regulierungs- und Technologiewechsel hinweg weiterentwickeln.

Was intern bleiben muss

Im Partnermodell ist nicht die Frage entscheidend, wer den Code schreibt. Entscheidend ist, wer die Regeln des Systems verbindlich definiert und ändern darf.

• Architekturhoheit über Schichten, Schnittstellen und technische Abhängigkeiten

• Datenhoheit über Modell, Zugriff, Speicherung und spätere Nutzung

• Lifecycle-Steuerung für Updates, Support, Variantenpflege und Abkündigungen

• Security-Governance für Identitäten, Schlüssel, Vertrauenskette und Reaktion auf Vorfälle

• Betriebsverantwortung für Monitoring, Diagnostik, Eskalation und Servicelevel

Diese Trennung muss organisatorisch abgesichert sein. Mit Architekturentscheidungen, Vertragsgrenzen, Abnahmekriterien und klaren Exit-Regeln. Genau daraus entsteht eine belastbare End-to-End-IoT-Strategie mit klarer Systemverantwortung.

Ein Partner ersetzt fehlende Spezialkapazität. Er darf niemals der Eigentümer der Systemlogik werden.

Entscheidungslogik für Build vs. Buy im IoT-Systemdesign

Eine tragfähige Entscheidung entsteht im Boardroom nicht aus Funktionslisten, sondern aus Governance-Kriterien. Jede Schicht des Systems muss gegen dieselben strategischen Prüfgrößen bewertet werden.

Die richtige Logik ist kompakt. Sie muss aber zwingend tiefer gehen als Beschaffung, Teamgröße oder Time-to-Market. Wer diese Perspektive schärfen will, findet in den Überlegungen zu Hilfe bei komplexen Make-or-Buy-Fragen eine nützliche Ergänzung. Für IoT reicht allgemeine Make-or-Buy-Methodik allein jedoch nicht aus. Das vernetzte Produktsystem verlangt zusätzliche Bewertung entlang von Betrieb, Feldrisiko und langfristiger Austauschbarkeit.

Die formale Verankerung solcher Kriterien gehört in die technische Governance und in zentrale Architekturentscheidungen im IoT. Nur dann bleibt die Entscheidung reproduzierbar und unabhängig von kurzfristigem Liefer- oder Projektstress.

Entscheidungsregel: Gekauft werden dürfen standardisierte Fähigkeiten. Behalten werden müssen kritische Abhängigkeiten.

• Strategische Differenzierung: Schichten, die Produktverhalten, Servicequalität oder künftige Geschäftsmodelle prägen, bleiben unter eigener architektonischer Kontrolle.

• Integrations- und Lifecycle-Kritikalität: Komponenten mit hoher Änderungsfrequenz, tiefer Kopplung oder zentraler Rolle im Feldbetrieb dürfen nicht als Black Box in die Architektur gesetzt werden.

• Daten- und Sicherheits-Souveränität: Alles, was Identität, Zustandsmodell, sensible Datenpfade, OTA-Fähigkeit oder Reaktionsfähigkeit bei Vorfällen beeinflusst, braucht interne Entscheidungsgewalt.

• Betriebliche Abhängigkeit und Ausfallfolge: Je höher die operative Konsequenz eines Fehlers, desto geringer darf die Abhängigkeit von intransparenten Fremdschichten sein.

• Ersetzbarkeit und Exit-Kosten: Wenn eine Komponente realistisch nicht austauschbar ist, muss sie entweder zum bewusst akzeptierten Lock-in erklärt oder architektonisch zurückgeschnitten werden.

Diese Logik ersetzt keine Produktstrategie. Sie zwingt sie in eine belastbare Form.

Build vs. Buy entscheidet über die Zukunftsfähigkeit des IoT-Produkts

Build vs. Buy entscheidet im IoT nicht über Einkaufsmodell, sondern über Systemsouveränität. Wer diese Entscheidung delegiert, delegiert die Zukunftsfähigkeit des Produkts.

Ein IoT-Produkt bleibt nur dann steuerbar, wenn die Organisation weiß, welche Schichten sie selbst beherrschen muss und welche sie bewusst standardisiert. Buy aus Bequemlichkeit führt in strukturelle Abhängigkeit. Build aus technischer Eitelkeit führt in unnötige Eigenlast. Beides ist vermeidbar.

Der Maßstab ist klar. Gekauft werden dürfen austauschbare Fähigkeiten mit stabiler Grenze. Gebaut oder intern geführt werden müssen alle Schichten, in denen Differenzierung, Datenverantwortung, Sicherheitslage, Feldverhalten und Betriebslogik zusammenlaufen. Das gilt besonders in Märkten, in denen IoT bereits mit datengetriebenen Optimierungsmodellen verschmilzt. Einen praxisnahen Blick auf diese Verbindung liefert der Beitrag Energieaudit365 GmbH erklärt KI-Einsatz, weil dort sichtbar wird, wie stark Wertschöpfung an Daten- und Systemkontrolle hängt.

IoT ist damit kein Beschaffungsfall mit technischer Nacharbeit. Es ist ein Architekturentscheid mit wirtschaftlicher Langzeitwirkung. Am Ende bleibt nur eine belastbare Schlussfolgerung: Im IoT ist Build vs. Buy eine Entscheidung über Systemsouveränität und langfristige Produktkontrolle.