Die Produktdaten-Factory: Was der Handel von der Software Factory lernen kann

1969 tat Hitachi etwas, das damals ungewöhnlich klang: Der Konzern gründete eine Fabrik für Software. Keine Halle mit Fließbändern, sondern eine eigene Organisation, die Programme so planbar herstellen sollte, wie andere Hitachi-Werke Generatoren oder Lokomotiven herstellten.

Gut fünfzig Jahre später ist der Begriff zurück. Im Platform Engineering spricht man wieder von der Software Factory: Teams bringen Code nicht mehr in Handarbeit in die Produktion, sondern über standardisierte Pipelines, wiederverwendbare Bausteine und vorbereitete Wege. Software Delivery ist zu einer Frage der Fertigung geworden.

Bei Produktdaten ist davon wenig angekommen. Ein neues Sortiment entsteht in vielen Unternehmen noch so, wie Software vor 1969 entstand: Stück für Stück, mit viel Wissen in den Köpfen einzelner Menschen und mit Excel als Werkbank.

Warum fertigen wir Software längst industriell, Produktdaten aber noch in der Manufaktur?

1968: Als Software zu groß für Handarbeit wurde

Im Oktober 1968 trafen sich in Garmisch Informatiker aus Industrie und Forschung zu einer Konferenz der NATO. Ihr Titel war Programm: Software Engineering. Große Softwareprojekte wurden zu spät fertig, kosteten mehr als geplant und steckten voller Fehler. Die Frage war, wie man Software ingenieurmäßig herstellt statt kunsthandwerklich.

Doug McIlroy von den Bell Labs schlug dort vor, Programme nicht jedes Mal neu zu schreiben, sondern aus Bauteilen zusammenzusetzen, die es in ganzen Familien gibt. Sein wichtigster Gedanke: Massenfertigung bedeutet bei Software nicht, dasselbe Programm tausendfach zu kopieren. Kopieren kostet nichts. Sie bedeutet, viele Varianten effizient herzustellen, so wie die Industrie von Modellen und Größen spricht.

Im selben Jahr beschrieb der Computerpionier Robert Bemer in einem Aufsatz über die Wirtschaftlichkeit der Programmherstellung die Idee einer Software Factory. Die Idee lag in der Luft. Umgesetzt hat sie als Erstes ein Industriekonzern.

1969: Warum ausgerechnet Hitachi

Hitachi war kein Softwarehaus. Hitachi baute Kraftwerkstechnik, Bahnen und Elektrogeräte, und schon damals auch Großrechner. Jeder dieser Rechner brauchte Betriebssysteme und Anwendungen, und der Bedarf wuchs schneller, als sich erfahrene Programmierer finden ließen.

Für ein Unternehmen, das seit Jahrzehnten Werke führt, lag die Antwort nahe. Wenn ein Produkt in großer Menge, verlässlich und in gleichbleibender Qualität entstehen soll, baut man dafür ein Werk. 1969 eröffnete Hitachi die Software Works, die erste Organisation weltweit, die ausdrücklich als Software Factory geführt wurde.

Der Managementforscher Michael Cusumano vom MIT hat beschrieben, was diese Fabriken ausmachte: einheitliche Standards für Entwurf und Test, Planung und Kostenschätzung, systematische Qualitätskontrolle, wiederverwendbare Bausteine und Werkzeuge, die all das unterstützen. Andere folgten: die System Development Corporation in den USA 1975, NEC, Toshiba und Fujitsu 1976 und 1977.

Das Entscheidende war nicht das Fließband. Die Software Factory machte Qualität planbar und Wissen wiederverwendbar, auch bei großer Vielfalt der Produkte.

Die Software Factory heute: Plattform und Golden Path

Was Hitachi mit Organisation und Handbüchern erreichte, erledigen heute Plattformen. Im Platform Engineering baut ein Plattformteam eine interne Plattform und behandelt sie wie ein Produkt. Entwicklerinnen und Entwickler holen sich dort per Self-Service, was sie brauchen, statt Tickets zu schreiben.

Das Herzstück ist der Golden Path: ein vorbereiteter und unterstützter Weg für eine häufige Aufgabe. Vorlage, Pipeline, Regeln und Dokumentation sind darin schon gebündelt. Wer einen neuen Service startet, muss nicht entscheiden, wie Code geprüft, gebaut und ausgeliefert wird. Der Weg steht, und er ist der einfachste. Abweichen bleibt möglich, ist aber die Ausnahme.

So wird Software Delivery zur Fertigung: Auftrag rein, Stationen durchlaufen, Prüfung bestanden, ausgeliefert. Immer gleich, immer nachvollziehbar.

Produktdaten: noch immer Manufaktur

Ein Fachhändler für Werkzeug nimmt eine neue Marke mit 1.200 Artikeln auf. Vom Lieferanten kommen eine Excel-Liste mit EANs und Kurztexten und ein Ordner voller PDF-Datenblätter.

Dann beginnt die Manufaktur. Jemand sucht die Herstellerseiten, liest Datenblätter, legt Attribute an, die es im System noch nicht gibt, schreibt Beschreibungen, übersetzt sie, füllt für Amazon die Pflichtfelder aus, für OTTO andere und für den eigenen Shop wieder andere. Jede Kollegin hat ihre eigene Tabelle und ihre eigenen Abkürzungen. Nach acht Wochen sind die ersten 400 Artikel online.

Eine Manufaktur hat ihren Wert. Für ein Einzelstück zählt die Hand, die es fertigt. Für 1.200 Artikel in fünf Kanälen ist sie der Engpass.

Dabei passt McIlroys Gedanke von 1968 erstaunlich gut auf Produktdaten. Ein Produkt wird nicht einmal gebraucht, sondern in vielen Varianten: für den Shop, für jeden Marktplatz, für jede Sprache, für die KI-Suche. Genau das sind die Modelle und Größen, von denen er sprach.

Die Produktdaten-Factory: fünf Prinzipien

Überträgt man die Software Factory auf Produktdaten, entsteht die Produktdaten-Factory. Sie folgt denselben Prinzipien:

• Ein Wareneingang für alle Quellen: Lieferantenlisten, PDFs, ERP-Daten und Webseiten kommen über einen geregelten Weg herein, nicht über zehn private Tabellen.
• Ein Bauplan statt Einzelanfertigung: Ein Datenmodell mit Attributen, Kategorien und Vererbung ist das wiederverwendbare Bauteil. Was einmal definiert ist, gilt für jedes neue Produkt.
• Stationen statt Einzelkämpfer: Recherche, Anreicherung, Übersetzung und Kanal-Mapping sind feste Arbeitsschritte, die jedes Produkt durchläuft.
• Qualitätstore vor dem Versand: Pflichtattribute, Vollständigkeit je Kanal und eine Freigabe durch Menschen entscheiden, was in den Verkauf geht.
• Self-Service für Aufträge: Wer Daten braucht, gibt einen Auftrag an die Fabrik, statt auf jemanden zu warten, der Zeit für Copy-and-paste hat.

Zusammen ergeben sie den Golden Path für Produktdaten: einen vorbereiteten Weg von der Lieferantenliste bis zum Marktplatz.

Die Menschen verschwinden dabei nicht aus der Fabrik. Sie wechseln von der Werkbank in den Leitstand: Sie geben Aufträge, entscheiden in Zweifelsfällen und geben frei.

ainavio als Produktdaten-Factory

Genau so ist ainavio als PIM mit AI gebaut. Zwei Funktionen machen das besonders deutlich.

PIM Studio ist die Fertigungsstraße. Sie legen eine Session an und geben Produkte oder Quelldaten hinein. Mit Deep Research werden aus Produktnamen, SKUs oder EANs vollständige Produkte: Der Agent findet vertrauenswürdige Quellen, liest Attribute mit einem Vertrauenswert aus und importiert die Produkte ins PIM. Mit Self Onboarding wird aus Katalogtexten, Tabellen oder PDFs Ihr Datenmodell: PIM Studio schlägt Attribute und Kategorien vor, zeigt die vollständige Liste und legt sie erst nach Ihrer Bestätigung an. Bestehende Attribute werden nie überschrieben. Im manuellen Modus fragt die KI nur dort nach, wo etwas unklar ist. Sessions laufen auf dem Server weiter, und Ihr Team sieht sie.

Die Stationen der Straße sind die acht AI Agents von ainavio: Research, Supplier Data, Enrichment, Translation, Media, Marketplace, Quality und Workflow. Der Marketplace Agent etwa ordnet Kategorien und Pflichtattribute automatisch den Feldern von 26 Shops und Marktplätzen zu, der Quality Agent findet Lücken und Dubletten, bevor ein Kanal sie findet.

Der MCP-Server ist der Auftragseingang. Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Assistenten mit anderen Systemen arbeiten. Über den MCP-Server von ainavio startet Ihr KI-Assistent, ob Claude, ChatGPT oder GitHub Copilot, Importe, Exporte, KI-Anreicherung und Batch Publishing direkt im PIM. Er sucht und zählt über viele Produkte hinweg, erstellt Berichte und stellt Exporte als CSV, Excel oder PDF bereit. Änderungen landen als Entwurf, den Sie nach einem direkten Vergleich im Chat freigeben. Jeder Nutzer arbeitet dabei mit genau den Rechten, die er auch im PIM hat.

Für den Werkzeughändler heißt das: Die Kategoriemanagerin schreibt in ihren KI-Assistenten, welche Akkuschrauber der neuen Marke noch keine englische Beschreibung haben, und lässt die fehlenden Texte ergänzen. Sie bekommt die Entwürfe zum Vergleich, gibt frei und stößt die Veröffentlichung an. Das ist Self-Service im Sinne des Platform Engineering. Der Auftrag kommt in natürlicher Sprache, die Fabrik arbeitet die Stationen ab, und das Qualitätstor bleibt in ihrer Hand.

Zurück zu 1969

Hitachi hat seine Software Works nicht gegründet, um Programmierer zu Fließbandarbeitern zu machen. Das Ziel war, dass gute Software nicht vom Zufall und vom Talent Einzelner abhängt, sondern von einem Prozess, der Wissen speichert und Qualität sichert.

Für Produktdaten gilt dasselbe. Eine Produktdaten-Factory nimmt Ihrem Team nicht die Arbeit weg, die Erfahrung braucht. Sie nimmt ihm die Arbeit ab, die nur Zeit kostet.

Eine Manufaktur ist wunderbar für Uhren. Für Produktdaten brauchen Sie eine Fabrik.