Engineering organizations have become extraordinarily good at keeping data. CAD files are stored. BOMs are managed. Revisions are controlled. Changes are approved. Purchase orders are recorded. Supplier information lives in ERP. Production schedules, quality records, emails, spreadsheets, and meeting notes accumulate continuously.
And yet, ask a seemingly simple question about a product:
Are all the parts actually going to be ready when we need them?
Suddenly, having all the data is not enough. Someone needs to understand whether engineering released the part, whether procurement selected the supplier, whether the purchase order was issued, what the lead time is, whether the latest deviation was accepted, whether inventory is available, and when production actually needs it.
Every piece of information may exist. But the understanding exists somewhere else.
Engineering doesn’t necessarily lose data. It loses memory.
The Systemic Gap Is Patched by Excel, or Hope
A recent LinkedIn conversation with Rob Ferrone, founder of Quick Release, gave me a great real-world example of this problem.
Rob referred to something sometimes called Plan for Every Part. At Quick Release, they called it Business Timing and Release Scheduling, or BTRS. His observation caught my attention:
“We encountered [it] on almost every engagement, so eventually developed a service supported product called QRonos which covered the systemic gap that was being patched by Excel, or hope.”
Think about that phrase for a moment. Excel, or hope.
These weren’t organizations missing CAD, PLM, ERP, purchasing, or scheduling systems. The problem existed in the gaps between them.
Quick Release describes one engagement with a global vehicle manufacturer ramping up new vehicle programs at a US plant, where every minute of line stoppage cost tens of thousands of dollars. When QR investigated the lost production units, 35 percent were attributable to late parts. On one program, just seven late parts accounted for 80 percent of the lost units. Their conclusion was straightforward: macro-level program planning is not sufficient. The critical path has to be understood at the individual part level.
Another example from the same story is even more interesting. At the QRonos launch, Quick Release showed an animation assembled from 200 different Excel spreadsheets tracking part data: the original release plan, the plan as it was updated over time, and the actual release curve achieved.
They also discovered that the BTRS process being used tracked only the middle 14 percent of the tasks required to move a part from concept to delivery. Problems developing earlier in the process remained invisible until much later, when their downstream consequences were already disrupting the program.
This is a perfect illustration of the problem I have been thinking about. The organization didn’t lack data. It lacked continuity.
The BOM Alone Is Not Enough
When Rob first shared the example, my immediate reaction was that it represents another form of the same reconciliation problem I see repeatedly in engineering and manufacturing.
A BOM can tell you what parts are expected to be in the product. But building a product requires much more than a BOM. For every part, multiple dimensions need to converge: product definition, design maturity, engineering release, sourcing, purchase orders, supplier lead times, inventory, logistics, deviations, production requirements, and timing. None of these dimensions exists in isolation.
Rob described it well in his follow-up comment:
“QR was pulling together data related to product definition, build planning, ordering, stock, logistics, purchase orders, lead times, design release, deviations and more. It’s an intricate web, and constantly changing.”
I think intricate web is exactly the right description.
Consider a single component. PLM may say the design is released. ERP may say a purchase order exists. Procurement may know the supplier promised a different delivery date yesterday. Engineering may have an open deviation. Manufacturing may need the part three days earlier because the production sequence changed.
All five pieces of information can be individually accurate, and the program can still be in trouble. The important information doesn’t reside in any single record. It resides in the relationships between the records.
Product Data Describes States. Product Memory Preserves Continuity Between Them.
For decades, engineering software has been designed primarily to manage states. CAD tells us what the design looks like. PDM tells us which file and revision to use. PLM tells us the lifecycle state and product structure. ERP tells us what was purchased, received, or consumed. MES tells us what is happening in manufacturing.
These systems solve important problems. We cannot run modern engineering and manufacturing organizations without them. But they organize information around objects and transactions, and the most interesting questions cross those boundaries.
Why hasn’t this part been ordered? Was the supplier waiting for engineering release? Did engineering release it but later introduce a deviation? Did that deviation change the promised delivery date? Which production build depends on it? What was the original plan, and what changed since then?
These questions require something more than retrieving the latest state. They require continuity across time and systems.
This leads me to an important distinction:
Product data describes states. Product Memory preserves continuity between states.
Memory is not another copy of the current information. Memory allows us to understand how today’s situation emerged.
Memory Is Not Only About the Past
When we hear the word memory, we naturally think about history. Why did engineering select this material? Why was supplier A replaced with supplier B? Why did we approve this deviation? These are important questions, especially when experienced people leave and the reasoning behind earlier decisions disappears with them.
But the BTRS example shows that Product Memory needs to represent something broader. Memory is also operational.
Imagine that six months ago a part was expected to be released on June 1. Later, engineering moved the release to June 15. Procurement adjusted the supplier schedule. A design problem moved the date again. A deviation allowed manufacturing to use an earlier configuration for the first twenty units. The supplier changed the delivery date. Production moved its build sequence to compensate.
What matters today is not only the latest date stored in a database. We need to understand what was originally planned, what changed, why it changed, what decisions followed, which dependencies were affected, and what the current consequence is.
That sequence is memory. The Quick Release animation demonstrates it visually: original plan, updated plan, and actual performance over time. The value isn’t just knowing where we are. It is understanding how we got here.
Thinking about the BTRS example, I now see at least three kinds of Product Memory that engineering organizations need:
Decision memory. Why did we do this? What alternatives were rejected, and under what conditions should the decision be revisited?
Operational memory. What was planned, what changed, and where are we now?
Dependency memory. What else is affected because this changed?
Traditional discussions of knowledge loss focus almost entirely on the first one. The Plan for Every Part story shows that the second and third are just as critical, and they decay much faster.
Physical Production Forces Digital Truths to Reconcile
Rob made another observation that I find particularly important:
“This digital to physical transition was the most challenging part of product development, and often where the first real problems become visible.”
While the product remains digital, fragmentation can stay hidden for surprisingly long periods. Engineering operates in CAD and PLM. Procurement operates in ERP and supplier systems. Program managers maintain schedules. Manufacturing prepares production plans. Everyone can continue working with a slightly different interpretation of reality.
Then someone needs to build the physical product, and reality becomes much less forgiving. The part either arrived or it didn’t. The deviation either applies to this configuration or it doesn’t. The assembly either has every required component or production stops.
Physical production is where disconnected digital truths are forced to reconcile.
This is why many information problems first become painfully visible at the boundary between engineering and manufacturing. The fragmentation existed earlier. The physical product simply exposed it.
People and Spreadsheets Become the Memory Layer
Why do organizations end up with 200 spreadsheets? Usually not because they lack enterprise software. Spreadsheets appear because someone needs to maintain a relationship the formal systems don’t maintain well enough.
A program manager builds a spreadsheet connecting engineering release with supplier timing. Procurement builds another connecting purchase orders with production requirements. Engineering tracks deviations separately. Manufacturing creates a shortage list. Someone else builds a master spreadsheet attempting to reconcile all of them.
The spreadsheets become a temporary contextual layer, and people become the integration mechanism. The experienced program manager knows which spreadsheet matters. The procurement person knows the ERP delivery date is outdated. The engineer knows the deviation was verbally approved but not fully reflected in the system yet.
These people don’t merely know facts. They carry the missing relationships between facts. This is why organizational knowledge can disappear even when every enterprise database remains intact.
But there is an even more annoying observation. Organizational forgetting doesn’t require people to leave. It can happen while everyone is still sitting in the building. When context is distributed across systems, spreadsheets, messages, and people’s heads, the organization can possess all the necessary information while still being unable to assemble it into a coherent understanding quickly enough to act.
Better Documentation Was Never Going to Fix This
The obvious reaction to everything above is: we need better documentation. Companies have been acting on that reaction for thirty years. Mandatory ECO comment fields. Knowledge-management portals. Wikis. SharePoint sites. Design rationale templates. Meeting notes.
These help at the margins, but they keep failing for the same two reasons.
First, the knowledge is relational. The valuable information is not “Supplier B was selected.” It is that Supplier B was selected because Supplier A had a quality problem, after manufacturing observed a specific failure, under a cost constraint, for revision C, with an accepted engineering tradeoff. That knowledge lives in the connections between records, people, and events, and a text field attached to one record cannot hold a network.
Second, capture is manual and the economics are wrong. Documentation asks the busiest person in the process to stop working and write context for a future reader who may never arrive. Engineers didn’t fill in rationale fields in 2005, and no amount of process enforcement has changed that since. What gets written is the minimum required to close the workflow.
Not Everything Experts Know Can Be Documented
Martijn Dullaart recently raised another important challenge to the Product Memory idea. In his How Do YOU CM2? series, he points to tacit knowledge: the experience and pattern recognition that experts use but often cannot fully explain.
An experienced engineer may look at a tolerance, material choice, supplier decision, or manufacturing process and immediately sense that something is wrong. Ask why, and the answer may be based on twenty or thirty years of accumulated experience rather than a specific calculation or document.
Martijn summarizes the limitation nicely: “A reasoning record is a tool, not a brain transplant.”
I agree. Product Memory should not be understood as an attempt to extract everything a person knows and put it into a database. That is neither realistic nor necessary.
But I think there is an important distinction between capturing everything an expert knows and preserving the context in which expert knowledge influences a product.
Imagine an experienced engineer saying during a design review: “I don’t like this tolerance. We had problems with similar assemblies before.” The engineer may not be able to formalize thirty years of experience into a rationale record. But we can preserve the configuration being reviewed, the concern that was raised, who raised it, the alternatives discussed, the decision that followed, and eventually what happened in manufacturing.
We may never capture the complete reasoning inside the engineer’s head. But we can preserve much more of the context surrounding that reasoning.
That context becomes part of Product Memory.
So organizational forgetting is not simply a discipline problem, and it will not be solved by asking people to write more. Some context is too relational for conventional documentation. Some is too expensive to capture manually. And some human knowledge can never be completely articulated.
The challenge is not to document everything. It is to preserve enough context around products, events, decisions, and human judgment so that the organization can continue to understand what happened and reason about what happens next.
Digital Thread Connects Records. It Doesn’t Preserve Meaning.
The industry has spent years developing the idea of a Digital Thread, and I strongly support it. We need to connect engineering, manufacturing, procurement, suppliers, and service. The Quick Release experience reinforces the point: their work with Reaction Engines used QRonos to drive closer integration of procurement and engineering, replacing spreadsheet-based coordination with a shared source of information.
But connecting information raises another question: what happens to the context created by those connections over time?
Suppose PLM tells ERP that a part has been released. Later, an engineering change modifies it. A supplier responds with a lead-time impact. Procurement selects an alternative. Engineering approves a deviation. Manufacturing changes the build sequence.
A Digital Thread can help connect these events. But the organization also needs to preserve their meaning: what changed, why it changed, what was known at the time, who participated, what dependencies were affected, and what happened afterward.
A thread connects information. Memory preserves the evolving context of those connections.
AI Makes the Missing Memory Visible
Modern AI tools and agents can potentially access CAD information, PLM records, ERP transactions, purchasing data, manufacturing information, emails, and many other enterprise sources. Technologies such as APIs and MCP make that access increasingly straightforward. This is an important development.
But access isn’t the same as memory.
Imagine asking an AI agent: why is part 123 going to delay production next Tuesday?
To answer accurately, the agent might need to connect design release, an approved deviation, a supplier commitment, a purchase order, a lead time, incoming inventory, an assembly dependency, and the production schedule. If those relationships have already been preserved as context, the reasoning problem becomes manageable. If they haven’t, the AI must reconstruct the story from disconnected records every time. Sometimes that will work. Sometimes it won’t.
But AI also changes something more fundamental than visibility. It changes the economics of capture.
But AI also changes something more fundamental than visibility. It changes the economics of capture.
Previous attempts to preserve context depended heavily on people documenting it manually, and people rarely did enough of it. AI is the first technology that can consume context and capture much of it as a byproduct of work: observing a change as it happens, connecting it to affected records, capturing conversations and decisions, and preserving relationships without asking an engineer to stop and fill in another form.
AI will not capture everything an experienced engineer knows. Tacit knowledge remains a human reality. But it can dramatically reduce how much context disappears simply because nobody had the time, incentive, or mechanism to preserve it.
The reason preserving organizational memory has been so difficult for thirty years was partly the cost of capture. That cost is now collapsing.
This is why I increasingly believe the future of AI in engineering won’t be determined only by giving models access to more enterprise data. It will depend on how well we organize and preserve the context across that data.
Product Memory Is the Next Layer, Not the Next Database
CAD digitized engineering design. PDM organized files and revisions. PLM expanded control across lifecycle information and processes. Digital Thread began connecting information across organizational and system boundaries.
I believe the next challenge is to preserve the accumulated understanding of the product across all those systems. I call this Product Memory.
Product Memory is not another database, and it is not simply a collection of documents. It is a way to preserve relationships between product information, people, decisions, events, evidence, dependencies, and time.
The Plan for Every Part example makes the need very tangible. Product definition, release, sourcing, orders, inventory, logistics, deviations, manufacturing, people, decisions, timing. Every individual record can exist somewhere. But unless the relationships between them are maintained, the organization is constantly forced to reconstruct what is happening.
And eventually somebody creates another spreadsheet. Or calls the one person who remembers. Or simply hopes.
If you want to test where your own organization stands, try a simple diagnostic. Pick one part that slipped last quarter and ask: how many systems, spreadsheets, and people would we need to reconstruct why? If the answer is more than one, you have found your memory gap.
Engineering organizations already store more information than at any time in history. The next challenge isn’t storing more. It is preserving the relationships that give the data meaning.
The data remains. The organization forgets.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
