The product data factory: what commerce can learn from the software factory

In 1969, Hitachi did something that sounded unusual at the time: it set up a factory for software. Not a hall full of conveyor belts, but an organization of its own, meant to produce programs as predictably as other Hitachi works produced generators or locomotives.

More than fifty years later, the term is back. In platform engineering, people talk about the software factory again: teams no longer take code to production by hand, but through standardized pipelines, reusable building blocks and prepared paths. Software delivery has become a manufacturing question.

Very little of this has reached product data. In many companies, a new assortment is still created the way software was created before 1969: piece by piece, with a lot of knowledge in the heads of individual people and with Excel as the workbench.

Why do we manufacture software industrially, but still handcraft product data?

1968: When software got too big for handcraft

In October 1968, computer scientists from industry and research met in Garmisch, Germany, for a NATO conference. Its title said it all: Software Engineering. Large software projects were finished late, cost more than planned and were full of errors. The question was how to build software like engineers rather than craftsmen.

Doug McIlroy of Bell Labs proposed there that programs should not be written from scratch every time, but assembled from components that come in whole families. His most important idea: in software, mass production does not mean copying the same program a thousand times. Copying costs nothing. It means producing many variants efficiently, the way manufacturing speaks of models and sizes.

In the same year, computer pioneer Robert Bemer described the idea of a software factory in a paper on the economics of program production. The idea was in the air. The first to put it into practice was an industrial group.

1969: Why Hitachi of all companies

Hitachi was not a software house. Hitachi built power plant equipment, trains and electrical appliances, and already mainframe computers as well. Each of these computers needed operating systems and applications, and demand grew faster than experienced programmers could be found.

For a company that had been running works for decades, the answer was obvious. If a product has to be made in large numbers, reliably and with consistent quality, you build a works for it. In 1969, Hitachi opened its Software Works, the first organization in the world to be run explicitly as a software factory.

MIT management scholar Michael Cusumano has described what defined these factories: common standards for design and testing, planning and cost estimation, systematic quality control, reusable components and tools to support all of it. Others followed: System Development Corporation in the US in 1975, NEC, Toshiba and Fujitsu in 1976 and 1977.

The conveyor belt was not the point. The software factory made quality predictable and knowledge reusable, even across a wide variety of products.

The software factory today: platform and golden path

What Hitachi achieved with organization and manuals, platforms do today. In platform engineering, a platform team builds an internal platform and treats it like a product. Developers get what they need through self-service instead of writing tickets.

At its heart is the golden path: a prepared, supported route for a common task. Template, pipeline, rules and documentation come bundled. Anyone starting a new service does not have to decide how code is checked, built and shipped. The path is there, and it is the easiest one. Deviating remains possible, but it is the exception.

This turns software delivery into manufacturing: order in, stations passed, checks cleared, shipped. Always the same, always traceable.

Product data: still handcrafted

A specialist tool retailer takes on a new brand with 1,200 items. The supplier sends an Excel list with EANs and short texts and a folder full of PDF data sheets.

Then the handcraft begins. Someone looks up the manufacturer pages, reads data sheets, creates attributes that do not yet exist in the system, writes descriptions, translates them, fills in the mandatory fields for Amazon, different ones for OTTO and different ones again for the own shop. Every colleague has their own spreadsheet and their own abbreviations. After eight weeks, the first 400 items are online.

Handcraft has its value. For a one-off piece, the hand that makes it matters. For 1,200 items in five channels, it is the bottleneck.

And McIlroy's idea from 1968 fits product data remarkably well. A product is not needed once, but in many variants: for the shop, for every marketplace, for every language, for AI search. These are exactly the models and sizes he was talking about.

The product data factory: five principles

Apply the software factory to product data and you get the product data factory. It follows the same principles:

• One intake for all sources: supplier lists, PDFs, ERP data and web pages come in through one defined route, not through ten private spreadsheets.
• One blueprint instead of one-off work: a data model with attributes, categories and inheritance is the reusable component. What is defined once applies to every new product.
• Stations instead of lone workers: research, enrichment, translation and channel mapping are fixed steps every product passes through.
• Quality gates before shipping: mandatory attributes, completeness per channel and approval by people decide what goes on sale.
• Self-service for orders: whoever needs data places an order with the factory instead of waiting for someone who has time for copy and paste.

Together they form the golden path for product data: a prepared route from the supplier list to the marketplace.

People do not disappear from the factory. They move from the workbench to the control room: they place orders, decide in cases of doubt and approve.

ainavio as a product data factory

This is exactly how ainavio is built as a PIM with AI. Two features make it especially clear.

PIM Studio is the production line. You open a session and add products or source data. With Deep Research, product names, SKUs or EANs become complete products: the agent finds trusted sources, extracts attributes with a confidence score and imports the products into the PIM. With Self Onboarding, catalog texts, spreadsheets or PDFs become your data model: PIM Studio proposes attributes and categories, shows the complete list and creates them only after you confirm. Existing attributes are never overwritten. In manual mode, the AI only asks where something is unclear. Sessions keep running on the server, and your team can see them.

The stations along the line are ainavio's eight AI Agents: Research, Supplier Data, Enrichment, Translation, Media, Marketplace, Quality and Workflow. The Marketplace Agent, for example, automatically maps categories and mandatory attributes to the fields of 26 shops and marketplaces, and the Quality Agent finds gaps and duplicates before a channel does.

The MCP server is the order intake. The Model Context Protocol (MCP) is an open standard that lets AI assistants work with other systems. Through ainavio's MCP server, your AI assistant, whether Claude, ChatGPT or GitHub Copilot, starts imports, exports, AI enrichment and batch publishing directly in the PIM. It searches and counts across many products, creates reports and provides exports as CSV, Excel or PDF. Changes are saved as drafts, which you approve after a direct comparison in the chat. Every user works with exactly the permissions they have in the PIM.

For the tool retailer, this means: the category manager asks her AI assistant which cordless screwdrivers of the new brand still lack an English description, and has the missing texts added. She gets the drafts for comparison, approves them and triggers publishing. That is self-service in the platform engineering sense. The order comes in natural language, the factory works through the stations, and the quality gate stays in her hands.

Back to 1969

Hitachi did not set up its Software Works to turn programmers into assembly line workers. The goal was that good software should not depend on chance and individual talent, but on a process that stores knowledge and secures quality.

The same holds for product data. A product data factory does not take away the work that needs experience. It takes away the work that only costs time.

Handcraft is wonderful for watches. Product data needs a factory.