OPC Ein-Mann-Unternehmen in der Ära von AIoT: Neudefinition der Überlebensregeln
In letzter Zeit hat die Diskussion über OPC (One Person Company, Ein-Mann-Unternehmen) Fahrt aufgenommen. Das „Aktionsplan für die Schaffung eines führenden Startup-Ökosystems für künstliche Intelligenz in OPCs in Shenzhen (2026 - 2027)“ wurde herausgegeben. Darin ist festgelegt, dass bis Ende 2027 über 10 OPC-Communities mit einer Fläche von jeweils mindestens 10.000 Quadratmetern, deutlichen Agglomerationseffekten und führender Position im ganzen Land errichtet werden sollen, und über tausend wachstumsstarke AI-Startup-Unternehmen gefördert werden sollen. Auf nationaler Ebene haben auch Städte wie Peking, Shanghai, Hangzhou und Nanjing in enger Folge OPC-Förderpolitikmaßnahmen veröffentlicht.
Plötzlich scheint das OPC zur sexiesten Startup-Geschichte der AI-Zeit geworden zu sein. Alle reden darüber, mit Claude Code zu schreiben, mit Midjourney Bilder zu erstellen und mit Cursor ein ganzes SaaS-Produkt allein auf die Beine zu stellen.
Als ein in der AIoT-Branche jahrelang tätiger Beobachter und Investor muss ich jedoch eine Frage stellen: Kann in der atomaren Welt wirklich ein Ein-Mann-Unternehmen wie in der digitalen Welt entstehen?
Schauen wir uns zunächst eine aufschreckende Datenlage an. Die Misserfolgsrate von Internet der Dinge (IoT)-Projekten war in der Anfangsphase sehr hoch. Die Branche geht allgemein davon aus, dass etwa drei Viertel der Projekte nicht als vollständig erfolgreich angesehen werden können. Die Lage der AI-Startup-Unternehmen ist noch schlimmer, mit einer Misserfolgsrate von 80% bis 90%, weit höher als die von herkömmlichen Technologieunternehmen, die bei etwa 70% liegt (siehe untenstehendes Bild). Noch schlimmer ist, dass die mittlere Lebensdauer von AI-Startup-Unternehmen nur etwa 18 Monate beträgt. Danach schließen sie entweder die Türen oder wagen es, sich auf eine Umstellung zu konzentrieren.
Kann das OPC wirklich einen Weg durchbrechen, wenn AIoT in diese beiden hochriskanten Bereiche fällt?
Dies ist keine Entmutigung, sondern eine Realität, der man sich stellen muss. Das OPC in der Internet-Softwarebranche ist im Wesentlichen die Spitze der Effizienz. Mit AI ersetzt man die menschliche Arbeitskraft und komprimiert die Arbeit, die ursprünglich von zehn Personen erledigt werden musste, auf eine Person. Ein Full-Stack-Entwickler zusammen mit der Kombination von Claude, GPT, Notion AI und N8N kann tatsächlich in wenigen Wochen ein ansehnliches SaaS-Produkt erstellen. Nachdem der Code geschrieben ist, kann man mit einem Klick deployen und sofort auf globale Benutzer zugreifen. Diese reibungslose Erfahrung ist wirklich verlockend.
Aber die AIoT-Branche ist eine ganz andere Welt.
Im Bereich der Hardware ist der Code nur die Spitze des Eisbergs. Die Auswahl von Chips, das PCB-Design, die Bauformwerkzeugherstellung, das Supply Chain-Management, die Zuverlässigkeitstests, die On-Site-Deployment und die langfristige Wartung... jeder dieser Schritte kann zu einem tödlichen Strudel werden. Noch schlimmer ist, dass Softwareprodukte schnell iteriert und in Graustufen veröffentlicht werden können, und die Benutzer können Fehler tolerieren. Bei Hardwareprodukten kann der Rückrufpreis jedoch direkt zum Bankrott des OPC führen, sobald das Produkt ausgeliefert wird.
Also lautet meine Antwort: Ja, aber es muss ein anderer Lebensstil gewählt werden.
Das OPC in der AIoT-Branche muss im Wesentlichen die Neuorganisation der "Verbindungen" sein. Es geht nicht darum, dass eine Person alles allein erledigt, sondern dass eine Person ein komplexes System organisieren kann. Wenn man AI nur als Effizienzwerkzeug sieht und denkt, dass man jetzt alleine die Arbeit von zehn Personen erledigen kann, dann kann man kein AIoT-OPC betreiben, sondern nur ein ermüdenderer Hardwareingenieur werden.
Basierend auf der neuesten Branchenentwicklung und meinen Überlegungen möchte ich drei Ansichten vorstellen, um die Überlebenslogik des OPC in der AIoT-Branche zu erläutern. Diese drei Ansichten hängen eng zusammen: Die erste beantwortet, warum ein gewöhnliches OPC in der AIoT-Branche scheitert, die zweite, wie es überleben kann, und die dritte, wie es aussehen sollte.
Warum scheitert das OPC im allgemeinen Sinne in der AIoT-Branche?
Um die Überlebensregeln des AIoT-OPC zu verstehen, muss man zunächst die Realität in diesem Bereich konfrontieren.
Der Arbeitsablauf eines Software-OPC ist relativ linear: Code schreiben, deployen, Feedback sammeln, iterieren. Der Reibungskoeffizient der gesamten Kette ist nahezu Null, und mit einem Klick kann man auf globale Benutzer zugreifen.
Aber die AIoT-Kette ist ein komplexes System mit mehreren Ebenen. Hardware, eingebettete Software, Cloud-Services, AI-Algorithmen und Anwendungsfälle haben jeweils ihre eigene Technologiebasis, Lieferantenökosystem und Lieferstandards. Wenn ein Schritt fehlschlägt, bricht das gesamte System zusammen.
Noch tödlicher ist der Unterschied in den Lieferstandards. Die Benutzer von Softwareprodukten können Fehler tolerieren, da diese in der nächsten Version behoben werden können. Die Lieferstandards für AIoT-Produkte sind jedoch, dass sie mindestens drei Jahre lang funktionieren müssen. Wenn ein Sensor, der in einem industriellen Umfeld installiert ist, nach sechs Monaten ausfällt, bekommt das OPC keine Chance zur Iteration, sondern wird einfach von den Kunden in die Lieferanten-Schwarze Liste aufgenommen.
Daraus ergeben sich drei tödliche Fallstricke für das AIoT-OPC.
Der erste Fallstrick ist die Komplexität der Lieferung.
Die Zuverlässigkeit von Hardware bedeutet nicht nur, dass es funktioniert, sondern dass es mindestens drei Jahre lang ohne Probleme funktionieren muss. Temperatur, Luftfeuchtigkeit, Vibration und elektromagnetische Störungen können alle dazu führen, dass die Geräte ausfallen. Die Stabilität der Software betrifft eine Reihe von technischen Herausforderungen wie OTA-Updates, Edge Computing und die Wiederaufnahme der Datenübertragung nach einem Netzausfall, die in einem Labor nur schwer vollständig simuliert werden können. Die langfristige Wartung bedeutet, dass der Kundenservice nicht nur ein Service ist, sondern auch eine kontinuierliche Kostenfalle. Die Kosten für die Anpassung an die Anwendungsfälle sind ebenfalls unendlich, da jeder Kunde denkt, dass seine Anforderungen einfach sind und nur etwas angepasst werden müssen. Selbst wenn das Produkt sehr schön ist, kann das OPC während der Lieferphase einfach unter der Last zusammenbrechen.
Der zweite Fallstrick ist die Cashflow-Situation.
Der Kapitalumschlagszyklus von Hardware-Startups ist viel länger als der von Software-Startups. Die Rückzahlung der Rechnungen hängt von der Prüfung, der Zahlungszielsetzung und der Freigabe der Garantiesumme ab. Ein Zeitraum von drei bis fünf Monaten ist schon kurz, und sechs Monate bis ein Jahr ist auch sehr üblich. Ein hoher Grad an Individualisierung bedeutet, dass jeder Auftrag möglicherweise individuell ist, und die Wiederverwendbarkeit von Code und Formen ist sehr gering. Die Grenzkosten können nicht gesenkt werden. Die Kosten für den ersten Auftrag sind besonders hoch, wie die Herstellung von Formen, Muster und Zertifizierungen. Man hat schon viel Geld ausgegeben, bevor man überhaupt einen Cent an Einnahmen erzielt hat. Viele AIoT-Startup-Unternehmer scheitern nicht an mangelnder Technologie, sondern an einem Cashflow-Bruch.
Der dritte Fallstrick ist das Vertrauen.
Dies ist das Problem, das von Startup-Unternehmern mit technischem Hintergrund am leichtesten übersehen wird, aber auch am tödlichsten ist. B2B-Kunden in der Industrie vertrauen natürlicherweise nicht einem Einzelnen. Ihre Risikobereitschaft ist sehr gering, und sie bevorzugen eher Lieferanten, die von einer Firma gesichert werden. Die Stabilität eines Einzelnen oder einer kleinen Gruppe ist an sich ein systemisches Risiko.
An diesem Punkt ist die Art und Weise, wie ein Ein-Mann-Unternehmen im allgemeinen Sinne in der AIoT-Branche scheitert, bereits sehr klar. Die Kette ist zu lang, um sie von einer Person abzudecken; die Reibung ist zu hoch, um alle Probleme von einer Person zu beheben; die Lieferung ist zu aufwändig, um die Verantwortung von einer Person zu tragen; und das Vertrauen ist zu gering, um Aufträge von einer Person zu erhalten. Die Strategie des Software-OPC funktioniert hier überhaupt nicht.
Heißt das, dass es in der AIoT-Branche keinen Platz für OPCs gibt?
Nein. Aber wir müssen neu definieren, was ein für die AIoT geeignetes OPC ist.
Ein für die AIoT geeignetes OPC bedeutet nicht, dass eine Person alles allein erledigt, sondern dass eine Person ein System organisieren kann. Das OPC muss nicht ein Alleskönner sein, aber es muss ein Systemorganisator sein. Der Unterschied zwischen diesen beiden Rollen bestimmt, ob das OPC überleben kann oder ein weiteres Opfer des AI-Hardware-Startups wird.
Ein für die AIoT geeignetes OPC muss drei feste Merkmale aufweisen
Da das gewöhnliche Ein-Mann-Unternehmen-Modell in der AIoT-Branche nicht funktioniert, was für ein OPC kann dann überleben? Ich denke, es müssen drei Kernmerkmale vorhanden sein. Diese drei Regeln sind sowohl Auswahlkriterien als auch Überlebensregeln. OPCs, die diese drei Regeln nicht erfüllen, sollten besser nicht in den Markt eintreten.
Das erste Merkmal: Das OPC ist ein Systemarchitekt, nicht ein technischer Arbeiter.
Hardwareingenieure mit hervorragender technischer Kompetenz können kein OPC betreiben. Warum? Weil sie eher im "Prozess"-Denken sind, nicht im "System"-Denken. Sie sind daran gewöhnt, sich auf die Arbeit zu konzentrieren und einen technischen Punkt bis in die Spitze zu perfektionieren, aber sie fehlt die Fähigkeit, Ressourcen auf Systemebene zu koordinieren.
Eine Person, die für ein AIoT-OPC geeignet ist, muss eine Kernfähigkeit aufweisen: Wissen, welche Module selbst entwickelt werden müssen und welche ausgelagert werden können; die Schnittstellen, Standards und Liefergrenzen definieren können; und ein komplexes System in zusammenarbeitbare Teil-Systeme zerlegen können.
Das OPC ist ein Systemorganisator, nicht ein technischer Arbeiter. Um zu entscheiden, ob eine Person für ein AIoT-OPC geeignet ist, schaut man auf seine erste Reaktion, wenn er mit einem komplexen Projekt konfrontiert wird: Ob er seine Ärmel hochkrempelt und selbst loslegt oder zunächst ein Architekturdiagramm zeichnet, Schnittstellen definiert und externe Partner sucht. Der erste Typ ist ein Ingenieur, der zweite ist ein OPC.
Also ist die richtige Haltung eines AIoT-OPC: Es ist nicht klein und komplett, sondern eng und tief. Das OPC muss sich als eine API, sei es eine Software-API oder ein Hardwaremodul, in die Supply Chain einer großen Unternehmung einfügen. Das heißt, das OPC soll das kritische Bauteil sein, das die Großkonzerne nicht interessiert, nicht tief genug entwickeln können, aber dennoch benötigen.
Die traditionelle Unternehmenslogik lautet: Wenn ein Unternehmen einen intelligenten Roboter bauen möchte, muss es fünfzig Personen einstellen, um sich jeweils um das Fahrwerk, die Optik, die Navigation und den Roboterarm zu kümmern. Die Logik des OPC ist völlig anders: Das OPC entwickelt nur einen Greifalgorithmus für eine dexter Hand basierend auf taktiler Rückmeldung plus ein spezielles Sensormodul. Dann perfektioniert es diese Fähigkeit bis in die Spitze und macht daraus eine Blackbox, die über eine Standard-API und Hardware-Schnittstellen an alle Unternehmen verkauft wird, die Roboter bauen. Das OPC muss nicht das Fahrwerk verstehen, muss nicht die Navigation verstehen, sondern muss nur in seinem Bereich unersetzlich sein.
Das zweite Merkmal: Das OPC ist ein Langschläferjäger, nicht ein Anbieter von Standardprodukten.
Das größte Problem in der IoT-Branche ist die Fragmentierung. Es gibt Tausende von nicht-standardisierten Anforderungen in industriellen Umgebungen und Hunderttausende von individuellen Anforderungen in der medizinischen Rehabilitation... Diese kleinen Anwendungsfälle haben zu hohe Grenzkosten, um sie skalierbar zu replizieren.
Das Auftauchen von AIoT-OPCs könnte die Langschläfermärkte wirtschaftlich machen.
Warum? Weil AI die Grenzkosten der Individualisierung nahezu auf Null senkt. Nehmen wir als Beispiel einen OPC-Startup-Unternehmer, der mit einem AI-Agenten automatisch auf eine PCB-Prototypenplattform zugreifen, die BOM-Materialliste automatisch optimieren, die 3D-Druckdateien für das Gehäuse automatisch generieren und den Firmware-Code-Rahmen automatisch erstellen kann. Was früher einen Monat dauerte, kann jetzt möglicherweise in einer Woche erledigt werden. Das bedeutet, dass ein Geschäft, das früher erst ab zehntausend Bestellungen lohnend war, jetzt schon ab hundert Bestellungen profitabel sein kann. Dies ist eine strukturelle Veränderung, keine schrittweise Verbesserung.
Deshalb sollte das AIoT-OPC nicht in den überfüllten Roten Ozean der Standardprodukte eintreten. Die Mission des OPC ist es, die kleinen Anwendungsfälle aufzusammeln, und zwar mit einer AI-"Staubsauger".
Welche kleinen Anwendungsfälle lohnen sich? Beispielsweise ein AI-Visionssortierer, der speziell für die Ernte einer bestimmten Baumwollart in Xinjiang entwickelt wurde. Der Marktvolumen in ganz China beträgt möglicherweise nur einige hundert Geräte, aber die Gewinnmarge kann über 60% betragen; ein Rehabilitations-Exoskelett, das speziell für eine seltene Krankheit entwickelt wurde. Es gibt möglicherweise nur einige tausend potenzielle Benutzer weltweit, aber der Endpreis kann Hunderttausende von Yuan betragen...
Das AIoT-OPC kann mit der Kombination von AI und flexibler Fertigung die bisher unwirtschaftlichen nicht-standardisierten Anpassungen in hochprofitablen Nischenmärkten verwandeln.
Das dritte Merkmal: Das OPC ist ein Netzwerkknoten, nicht ein einsamer Held.
Die Kernfähigkeit des OPC muss durch Zusammenarbeit verstärkt werden können, nicht in einem eigenen Kopf eingeschlossen bleiben.
Obwohl das OPC von einer Person oder einer kleinen Gruppe betrieben wird, ist es nicht ein Hardware-Arbeiter, der jedes Projekt von Grund auf individuell entwickelt, und auch nicht ein hochspezialisierter Auftragsdienstleister, der nur einem einzigen Kunden dient. Die richtige Haltung des OPC sollte sein, dass seine Kernfähigkeit modular ausgegeben werden kann, dass es gleichzeitig mehreren Anwendungsfällen dienen kann und dass es als Standardkomponentenlieferant fungieren kann. Wenn andere Unternehmen sich an der Zusammenarbeit beteiligen, wird die Fähigkeit des OPC stärker, nicht geschwächt.
Dies bestimmt auch, dass der Wachstumspfad des AIoT-OPC völlig anders ist als der traditionellen Startup-Unternehmen. Der Pfad der traditionellen Startup-Unternehmen ist die Finanzierung, die Expansion und die Verwaltung. Man geht davon aus, dass das Einstellen von Mitarbeitern eine Pflicht ist und