Japan, 1950s. In the ruins of a post-war Toyota factory, engineers encountered a strange problem.
The people who built cars, the people who inspected them, and the people who ordered parts were all calling the same component by different names.
The design drawing said "front right brake disc." The warehouse called it "Brake Plate Type A." The procurement ledger recorded it as "12-inch friction material." All the same object. But no one could tell at a glance.
When one part ran out, the entire production line stopped. No one had a complete picture of what part was used where, and how many were needed. The factory was running — but barely, held together day by day.
How BOM Changed the Factory
The solution that Toyota and other manufacturers found was elegantly simple: give every part a number.
But it wasn't just a label. Every piece of information was connected to that number — which vehicle model it belonged to, how many were needed, which process used it, which supplier provided it. Designers, assemblers, quality inspectors, and procurement teams all began speaking the same number.
This was BOM — Bill of Materials.
Once BOM arrived, the factory's language unified. "Line 3 is out of P-4471" meant procurement immediately placed an order, quality checked alternative specs, and design assessed impact range. One number became the common language connecting the entire organization.
Why Doesn't Software Have This?
When you first encounter the BOM story from manufacturing, a natural question arises.
Why doesn't software have something like this?
Software is also made of countless "parts." Login screen. Sign-up process. Payment flow. Admin dashboard. These are clearly identifiable units. The planner calls them by screen ID. The developer calls them by file path. QA calls them by test case number. Everyone is pointing at the same function — but nobody uses the same number.
The exact problem Toyota faced in the 1950s is still happening in software, every single day.
One counterargument: "But software already has ticket numbers. Jira issue numbers, GitHub issue numbers." True — but those are numbers for tasks to be done. When the work is finished, the ticket closes. They are not numbers that permanently identify the components of the software itself.
A car's brake disc still has a part number after the car is sold. The same number is used at the repair shop years later. But once the "sign-up screen" ticket is closed in Jira, that function is no longer identified by any number at all.
Software Where Parts Disappear
The gap this creates is larger than it seems.
Six months after a project ends, the client asks: "That email verification step in the sign-up flow — was it properly tested last time?" To answer this question, where do you look? The Jira ticket from back then? Git commit logs? The test results spreadsheet? Or do you have to track down whoever was responsible?
Without a part number, every piece of history for that function exists in scattered fragments. There is no thread to connect them.
In manufacturing, it would be different. The quality inspection records, delivery dates, and design change history for brake disc P-4471 are immediately traceable through one number. The software "sign-up screen" cannot do this. It has a name — but no number.
Seeing Software as Business Units
The lesson BOM offers is not just a numbering system.
The fundamental unit of a BOM is relentlessly a business unit. The factory's language is "3mm stainless steel screw" — not "metal atom cluster." It uses the real things people actually handle on the floor as its reference point.
What if we applied this to software quality management? Change the reference unit from code files and classes to the units that people actually recognize: "login screen," "password change process," "admin menu." These become the "parts" of the software.
Then assign numbers to these parts. Connect planning, development, testing, and documentation under the same number — from the very beginning.
This is the core idea SOM borrowed from manufacturing's BOM.
The Simpler the Idea, the Stronger It Is
Looking back, the BOM idea itself is strikingly simple. "Give every part a number." That's it. And yet that simple principle became the foundation of modern manufacturing.
Perhaps software quality is the same. No complex algorithm needed. Change the reference unit. Assign numbers to those units. That simple starting point is SOM.