Episode Summary
This episode of the Future of PLM podcast confronts a deceptively simple question that has resisted resolution for thirty years: why does the translation from Engineering BOM (EBOM) to Manufacturing BOM (MBOM) still happen in spreadsheets? The panel features the regular cast — Brian Carroll, Ken Hartman, Jonathan Scott, Oleg Shilovitsky, and Yoss Ben-Shachar — joined for the first time by David Schultz of Markstackworks, who brings a rare perspective from the manufacturing operations management side, the world of ISA-95, MES, and shop floor execution. David walks the panel through the Purdue Reference Architecture layers that most PLM practitioners have never had to think about: physical process, sensing and control, SCADA and PLCs, manufacturing operations management, and ERP/PLM at the top.
The panel identifies three root causes for the persistent Excel gap. First, organizational fragmentation: engineering, manufacturing, and service are siloed organizations with separate P&L targets, separate systems investments, and no shared owner of the full lifecycle. Second, data ownership as a business model: every PLM and ERP vendor has historically competed on locking customers into their proprietary BOM structure, creating deliberate incompatibility that spreadsheets fill by default. Third, liability and auditability: Oleg Shilovitsky makes the counterintuitive observation that manufacturers sometimes prefer Excel precisely because it creates a clear, timestamped audit trail — when you send a contractor your CAD-system BOM directly, you take on liability for their interpretation errors; when you send an Excel file, the artifact and the timestamp are yours. Brian Carroll argues that modern PLM platforms have long had the technical capability to manage EBOM-to-MBOM transitions through parent-child link overloading, filtered views, and effectivity attributes — the gap is not a technology problem but a change management and organizational alignment problem.
The episode closes with a forward-looking discussion on whether AI agents can finally bridge what decades of integration projects could not. Ken Hartman sketches an agentic workflow where SysML physical structures are automatically tagged with reusable PLM part classifications, generating the first EBOM instance from MBOM-agnostic system models with no user interface. Oleg draws a parallel to Google's original insight: rather than requiring the world to organize its data before indexing it, AI can traverse fragmented, heterogeneous data landscapes and construct coherent views bottom-up. The next episode will build on this with a dedicated discussion on product memory — the emerging concept that AI agents can maintain a living, contextual record of every product decision across the full lifecycle.
Full Transcript
Michael FinocchiaroAnd we're live. Welcome to this edition of the EBOM MBOM from the Future of PLM Podcast. We are sponsored now by AWS Marketplace. There'll be a link in the description field down there to download a cool white paper from AWS Marketplace about agentic AI and all that kind of stuff, which doesn't enter into this discussion exactly, but who knows? With EBOM and MBOM, you never know where it's going to go, right?
Michael FinocchiaroWe have an extremely diverse and interesting panel today. Some of the regulars, of course, Brian and Ken and Dr. Patrick and Yoss and Oleg, but Jonathan Scott, who we've had the pleasure of welcoming at least twice so far. And I would like first to introduce David, who is our manufacturer, David Schultz from Markstackworks. And David, you come really from the execution side of engineering, right?
David SchultzYeah, it's all manufacturing, all process control, factory automation. I live in what's known as the manufacturing operations management domain. So all the things that the crazy engineers have come up to say, we need to make this, we figure out how to actually execute that work. That's what I do.
Michael FinocchiaroCan you talk about your company too? Because obviously it's first time on your podcast and people don't know you yet.
David SchultzYeah. So Markstackworks, Marco Donovan and I, we formed it here back at the beginning of the year. We both come from 20 to 30 years of manufacturing experience and we focus on, as I mentioned earlier, the manufacturing operations management domain. You know, our claim to fame is we use a standards-based MOM built on a modern technology stack. The company really comes in three different flavors. It's the consulting piece that we really help companies figure out what is it that they want to do, what should they do, what do they do next, then it's also the solutions architecture of how do we build all the different technologies that we could fit, how do we get that all to fit together, and then finally we can do the execution of the work as well. Our focus is around that manufacturing operations management of getting what we need to make from our ERP, what we call the level four system, and execute the work on the plant floor.
Michael FinocchiaroI'm not sure if the other people on the panel know what ISA-95 is and the five layers. David, if you take like 30 seconds, you can explain that stack because we don't really have that on our side of the world.
David SchultzYeah, so ISA-95 is a standard that started probably mid 90s. I think its first iteration was around 2000, but really the idea was that we wanted to integrate our business system — your ERP, that's your enterprise resource planning — with your control systems. And in there was what we came out of now, the four levels. It was originally part of one of the Purdue enterprise reference architectures. So we always talk about the physical process — that's level zero. You'll have your sensing elements, control elements — that's level one. So those are like you know anything about your thermostat on your wall. Then level two, your SCADA, PLCs, exactly. And then level three is gonna be that manufacturing operations management and finally level four. That's all your business systems. I would call that your ERP and your PLM, which I think is what we're gonna talk about today. But the whole purpose of the standard is to find a common way to exchange that information.
Michael FinocchiaroSo who on the engineering side wants to define EBOM? Patrick, maybe you give us the academic definition you give to your students every semester.
Patrick HillbergSure. My background is first factory robotics and then manufacturing planning and then exporting. EBOM exports to the manufacturer, to either ERP or MES. Let's see, I'm gonna go back to my time at Dassault, specifically Delmia, which is their manufacturing process. So they were very big on product, process and resource — PPR. So the EBOM fits into the product space, but then we need processes to build all that stuff together and our processes need to work on resources. A lot of this came out of the 787 project. And the way it was described to me is that products fly away on the airplane and resources stay on the ground — all our machines. And I make the point that really though, before the bill of materials, you need to think about the bill of equipment. I have to have machines in order to build the product. If you design something that can't be built, your design doesn't matter. In a quick brief recap, the BOM — which would be the product — and the processes and the resources all need to work together in order to get the product out the factory door.
JosFirst an objection to the beginning, Michael. We are not just engineers. We are PLM guys and we cover the whole life cycle. And then coming back to eBOM, MBOM — not every company needs an eBOM, MBOM. And we also have to realize that if you are a typical engineering-to-order, you already engineered it to be manufactured directly. So there is not a split. You only would think about eBOM, mBOM if there is a disconnect in your specification phase, which needs to be stable. And you have flexible manufacturing possibilities afterwards, like for example, multiple plants that have to stay alive for many years and the suppliers might change. So if you look at the e-bomb discussion in the early days when I was working with Smart Team, often when I talked with the customer about the BOM, they thought the BOM in SAP. Because only SAP has the BOM and the rest in what happens in front. You have to upload your drawings and the BOM didn't exist. Only later when PLM systems became more mature, we start to say we're going to have a BOM in our PDM or PLM system. And by adding an M-BOM to the capabilities to the data model, it looked like we were doing something manufacturing also. But like Patrick also said, you need to also manage the resources. You need to know the equipment for your plant. You cannot just define an M-BOM if you don't know for which plant you are designing. That's where a little bit my position on the eBOM — it's the most popular, one of the most popular blog posts since 2008. I think it's called the importance of eBOM and MBOM in PLM. So it's a hot topic.
Oleg ShilovitskyI will use it just to show the book which goes back before — you know this book, right? So that book even before what you said about SAP, this book was saying like we need to get one BOM. So this is where I started. And like not about engineering, not about manufacturing, but the whole idea said we need to have one BOM and then it somehow started to translate it to, wait a second, what comes from engineering, it's what comes from drawings. This is where so many people, when they come to this point, they say, no, no, no, no, that's not the BOM, this is the part list that engineers sending and it's in the drawings, okay? So I think in the later stages when this conversation between PLM and ERP domains started to emerge, I think it was a topic that I got introduced many, many years ago, somewhere back in Smart Team days, is that there is a concept that called "throw it over the manufacturing wall." So what you throw over the manufacturing wall, it's called engineering BOM. And then if they will make it, then it's going to be something real.
Richard Kenn HartmanI'm not sure that any of the major PLM providers have a consistent long-term strategy for what to do with the BOM when all it talks about is moving to a single BOM. I'm not sure that anyone has sat down as a committee to decide how PLM should be reconstructed to enable a more agentic eBOM environment and be able to exploit AI in the process. So until that is done, I'm just trying to figure out how to interconnect the data model between PLM, SysML and ERP to create a more objective environment. And as I look at all the opportunities for doing that, I asked myself the question, how on earth would AI ever be able to do this? If we interconnect our data model. So for example, if we go into PLM and we take the part classification, parametric part classification tree out, filter it down for all those things you wouldn't use as a physical block in SysML, and then export that tree with all the parametric attributes and use that to derive your physical library in SysML. Well, now I can, when all those required attributes are filled out on a SysML block, I can run a script that automatically searches for and tags the block with a reusable part. If it doesn't find a part, I can create the correct part type and classify that part. And now because we're building the BOM as a physical structure in SysML and all those parts are attached to it digitally linked, I can now generate the first instance of eBOM from SysML — the earliest instance of eBOM. Now I can extend that example to how we then take that and automatically attach the component characteristics, the start part, automatically launch the material properties into the start part. All that can be done agentically with no user interface.
Jonathan ScottYeah, so let me back up to the definition you asked about earlier, because I think that feeds into that answer. From my perspective, eBOM is the specified elements and quantities of the product, right, as they need to exist at delivery to the customer. So there's a moment in time that that definition applies. And that's what engineering is doing. Manufacturing BOM, it's got a different purpose, a different definition. I think of it as the elements and quantities of raw, in-process, and finished materials in groupings of how they get combined to meet that spec of the EBOM. So there's two different points of view. And I think it gets right to your question. Why do we still have Excel in the middle of all this? And I think the answer is because that translation from one to the other is not simple. And depending on the organization, there's tons of rules, and then there's tons of preferences that get applied. And all of that is really hard to codify. So it ends up that people are like, well, I need a digital tool to do it, to put my own rules and preferences in. And they end up with Excel. To me, that's what I hear.
Michael FinocchiaroWell, is it a mindset thing? Is it just because we're still thinking in terms of the 80s and 90s UXs that we've gone to this place?
Brion CarrollLet me just give you an example of EMC. They're high-end storage systems. And so, yeah, they had the most volatile transition of an EBOM to an MBOM where they would take, and you could just visualize that you've got this system with a bunch of slots and you've got screws that are holding boards into slots. And in the engineering drawing, you'd see the screws actually in position, right? It would be a visual of what that was, but in manufacturing, they would baggie the screws. So you're taking from a BOM the screws that are at a certain point in the hierarchy, the sub-assembly, and you're taking all of them and you're putting them into a baggie and you're dropping that baggie at some point along the manufacturing work cells, right? And so the manufacturing BOM dispositioned those and manufacturing wanted to know how can we take these screws, put them in a baggie, and if you do something in engineering, we knew which screw they took out or changed. On the relationship, we would put that value. So now if somebody was to do something in engineering, we could look at, now I found it, it's in baggie number three. That used to be the child. Now I'm going to swap it out for another part. And so even back in, I think it was 96, we were able to do this between using Windchill. And it was not difficult. It was very easy. The only way to do that is to label that this is for the M-BOM. The M-BOM says the quantity is zero here. Now over here in a baggie, the quantity is one and it's new and it's for the M-BOM. So if you filter your view using the characteristics that are contained on the link, then you would filter out anything that wasn't the E-BOM or filter out anything that was in the M-BOM or even filter out what was not applicable to ECO 1475 or what was on the effectivity date. All those things can be interpreted by the BOM viewer if it had enough intelligence to know what content was on the links. And people could use that to kind of spin the dial. It's almost like I want to see what's being built today and swing. I want to see what's being built next month. I don't see the complexity of this. I've checked all the major players and they all have this ability to contain content on the parent-child relationship, which will thin out, expand or change or morph the BOM based on what your intelligence of attribute data is on the link.
Oleg ShilovitskyI want to start to go back to what Ken said. I think what we're dealing with is something that is not a technological problem. So there is a structural problem which is called fragmentation. The way products are built, the organizations are fragmented and everything is fragmented, and no single system, if you have multiple systems, has the entire picture. So this is where yours came with the ideas when the MRP2 was the only system that was a question how to have one BOM in that system. But then the systems became more systems and PDM systems came, manufacturing systems came and other systems. No single system sees the full picture. And then what we are dealing with is that we are dealing with the handoffs, like every handoff between those systems creates a gap. And that's the gap that is filled by Excel. 30 seconds. So what actually happens is that because of the business model of all vendors is data locking. No one wants to agree that we have a single picture of data because we will lose the business. ERP systems want to own the data. PLM systems want to own the data. Everyone wants to own the data because this is how seats were sold. It's actually changing, separate conversation. But this is where the problem is created. There is a fragmentation, there is a handoff and the interest of every single one to own this. And this is the place where spreadsheets exist — not because technologically it's impossible to, spreadsheets exist because this is the natural way to fill these gaps in an easy way. And this is how we come in. It's not UI and UX problem. It's not the data model and data assumption problem. It's the filling the gaps between systems that everyone holds their position and no one has the entire picture.
JosOkay, so I think with eBOM and mBOM we are just focusing on part of the information stream in an organization, purely on the parts. I think Oleg already said most of it. We use Excel because it's a way to transmit information from one division to another division. And in good old Smart Team days, I had a project where we created an export in Excel. And then we had created, and on the other side, they created the import in ERP. And then after some months, people in the ERP said, why do we need to manually every time upload this Excel? Because the data was correct. There was trust in the process. But coming back to the discussion also with Brian, I think all these technology discussions on parts and children and parents, actually you should see it as a network of data, connected data, because it's not only the BOM structures, it's all connected data in a certain context. And the better you're able to represent this in a user interface, people understand it. And I think that's the challenge we are also facing. Openness, and access to data elements from different environments.
Michael FinocchiaroSo is it a problem of pride and ownership? Like we want to own the M-BOM and we want to own the E-BOM or is it a problem of UX where Brian says, hey, all the capabilities are there, we're just not using them. Why are we even having the conversation? Why isn't it just obvious that all these systems are already working together?
Patrick HillbergI don't know that the parent of a child in the engineering BOM is the same parent in the M-BOM. The parent of a child in the engineering BOM, the child's parent may be different than what it is in the M-BOM. And I don't see how you can overload the links for that. You need to create different parents. I'll give a specific example on this — it goes to the service BOM. This is floating airports, right? And they're full of pumps and in the EBOM, we say we need a motor for this pump. Well, the pump automatically comes with a coupling. In the service phase, couplings wear out far faster than pumps do. The EBOM does not include the coupling because it automatically comes with the pump. However, the service BOM needs to recognize that we need to provision couplings because the couplings are going to wear out. So what I'm getting to is there's different semantic context. The way engineers think about something — developing engineering intent — is different from manufacturers who look at this in terms of manufacturing intent. There's certainly a BOM reconciliation that needs to occur.
Oleg ShilovitskyI want to start to go back. I think what we're dealing with is something that is not a technological problem. The fragmentation happens at the organizational level. And the way to address this, I'm going to make an analogy. When Google asked everyone, we don't care what you put on your website, we will index it. And then we will be able to align this information. Now, full 20 years forward to what is happening now. We have, speaking of AI, agentic capabilities to access any browser and do any work in this way. So, pulling information, organizing information, making alignment logically is becoming much more easier bottom up. And that's the only way that we'll be able to capture information, align this information, and program the tools that in the field that no one wants to change. Because if someone invested in PLM 15 years ago, millions of dollars, they don't want to change it. And the ERP system doesn't want to change it. Now the economics of this becoming possible and the indicator that this is possible to build it bottom up, it's because the stocks of the system of records are going down. Why? Because all the system of records now is becoming dumb databases. And before we thought it's a smart database, a single system of records, and now we're becoming dumb databases. And this is where we are coming to the way how we can pull this data and to make something smart — product memory, if we already want to say this word.
David SchultzYeah, these are all great questions and we get asked this a lot around ISA-95 and even around using this agentic AI — how can we take that standard and then use it and consume it. And really it's more of an art than it is a science. So when you talk about having the engineering BOM, what are we going to work at is how do we now actually translate that to how we actually make things in this factory versus that factory? And they could be very different. So that's where we get into the art of how do we want to go about not just taking the resources — those are the physical things that are going to exist on that BOM, that bill of materials — but now how do we work that through using all of our activity models. And where you get into work instructions, it really all depends on where do you want that to maintain. So just a couple of comments going back is we talk about the data model — something that we do at Markstackworks is we abstract that data model and we call it master data management or master data modeling — we want that to be in its own separate system. So regardless of what you're using, that whatever system you're choosing to use, it doesn't own it. And the reason why we don't want that owned in a proprietary system is because if you decide to change that system, now all of a sudden you're beholden to it. Where we really get the magic within the standard itself is on that exchange of information. Is there a mechanism that EBOM to MBOM to SBOM to work instructions — how do we actually make that happen in a way that is seamless and common? Because everybody wants their own sandbox and nobody wants to play well with others. And we run into that a lot.
Jonathan ScottSome of what's behind all this — what's causing it — I have an opinion. I think it's about a fundamental problem we have in PLM today. We call it the product lifecycle. And we only handle the engineering piece primarily. We touch on quality, we touch on manufacturing, but I'll give you an example of what I mean. We still call it engineering change, right? I think what it needs to be is enterprise change, or I would call it product change. We're changing the product. Okay. But in that concept, we have this legacy CM idea of engineering release. Engineering release is a moment. It's a point in time that matters to the organization. I totally agree. But that's not really what you need to get the product out the door. Which is why we have these debates about ECOMCO, engineering change, manufacturing change, and we don't have the enterprise change we're talking about. Not to say systems aren't capable of it, like Oleg said. Technology, it's possible. But what I see in a lot of organizations is they're stuck in that mindset of engineering release is the moment in time. Well, if that's the way you think of it, of course you're going to have a gap to the manufacturing side and the execution side. Similarly with service, if that's part of your business. But if you look at the whole process and you don't think it ends at engineering release, then you think about how do you get this data from one stage to another. To me, that's got a lot to do with the gap we see.
Brion CarrollSo, all I do is your distributed factory issue and, know, keep them lean, mean fighting machines, send them Excel. You know, I did something back in the early 2001 to 2005, where we built a product called Flex PLM. And my company sold it in the technology to PTC in 2005. That product had to deal with a whole slew of distributed manufacturing, right? Especially for footwear, because whoever manufactures the shoe is the company who has the last in their possession. You know, the last comes first. The last is the actual foot form. Then they wrap things around it. So the factories in Flex PLM actually had to build the BOM because they're the only ones that know what the BOM's going to be. They're provided an image and they wrestle with that back and forth, but no engineering is done by the boot or shoe designers except defining its last, which then targets the factory. On the apparel side, it's totally different. The apparel side could have two, three, four different manufacturing facilities. And every time you do a BOM, you could have one colorway of the shirt. One colorway goes to one factory. But because it's going to go to another factory, they have a different supplier for that material. It's the same material, different supplier. So the BOM in Flex had to be able to take into account the variances of these different manufacturers. All I'm saying to you is if you want to harmonize what you're doing, you can infiltrate the factories into the system and have them work on the BOM, or you can push out the BOM in a tech pack like in apparel. So PLM can be used in that thing, but we talked about the isolation silo of organizations. That is an impediment. If you're in the same company, your engineering and your manufacturing should say, hello, we're over here. Can we use the same system? Yeah. Don't disturb my stuff. I'll set up protection so that you can only do certain things. All I'm saying is it can be done. And yet, because we're still dealing with the gray hairs — they don't want to change. They want to have that barrier of liability. But you could have AI rumbling through these BOM structures to automate the EBOM to MBOM transition by flavoring the links on some rule-based process and have manufacturing people change that later but set it up for them. You could do that too, right?
Patrick HillbergThe Ford family built more aircraft than Boeing could imagine. I mean, in the amount of time that they had. However, they didn't care what happened after the plane left this factory. And we're moving into new societal norms where customers, governments, and society expect the OEM to maintain continuity throughout the entirety of the product life cycle. And PLM is not up to this job. PLM is an important piece at the beginning of it, but it's only a small piece of this job. And I'll bring us back to the conversation that many people in this group had on the 737 MAX, where Boeing was not big enough to keep the Boeing planes flying. They were relying on their airlines to do proper maintenance and their airlines to do proper pilot training. So as we start looking at the entirety of the life cycle, we've got to talk about digital threads. PLM is not capable of accomplishing what society is expecting out of its products. Society expects a lot more than what society expected in World War II. When you introduce a new product, you need to introduce the thread — you need to introduce the entirety of the thread from lust to dust, from the first concept of why we want to build this product till when all the final products come out of service. We need to build an IT infrastructure that can manage the entirety of that lifecycle, and that would be the thread. And then at this point, the different BOMs — the thing that we happen to be talking about today — are views into that thread. So engineers have a view into the thread which is specific to their purpose. Manufacturers have a view into that thread which is specific to theirs. Service people have it specific to theirs, et cetera. I kind of wrap up with that and say, I mean, this is a useful conversation at the beginning of the life cycle, but we've got to build the thread first.
JosThanks Patrick, because I wanted to react on Jonathan's engineering change management and engineering release importance. I think also Patrick you already said the important thing that from the beginning for me also PLM was about the full life cycle and it was not the linear process of pushing something to the market. It should also have feedback loops. And one of the lessons I learned even in the 90s, previous century, is that the engineering release is not important. It's about a stable engineering definition so manufacturing can build upon it and to have the product release. I think from the beginning there was always this discussion, okay, engineering is stable, now let's start with the manufacturing definition. That's the old traditional linear process. In a modern approach you have already manufacturing looking and contributing to engineering reviews. We were not able to do that in the old ways because we had our own systems and we waited till it's ready. But historically, for me, always the intent in discussions was it's an enterprise process. And it's the same for configuration management. Some people think configuration management is only an engineering job. And that's where you come back with your story, Patrick, about the life cycle of a product, how important it is.
Oleg ShilovitskyYes, thank you. I was listening, but here's my observation is that we have no doubt have technical capability to organize this information in the way so it will be connected and logically organized. And there are many examples of products that were built 20 years ago and now it's all possible. So the reality is that fragmented organizations have no power to pull everyone top down to organize it. This is what I've seen many times. The reality in the field is that when you need to send something to a contractor, Excel will be used. The reality between ERP and another engineering system, when they need to do it, they will pull Excel. I mean, this is the reality. So now what I want to bring — now we can try to organize everyone, that people do not like to be organized top down and engineers don't like to be organized even more. When you have two engineers, you have three opinions on how to send this BOM. So that's the problem. But I want to bring kind of observation from the market and what other companies were doing. When Google asked everyone, we don't care what you put on your website, we will index it. And then we will be able to align this information. Now, full 20 years forward to what is happening now. We have agentic capabilities to access any browser and do any work in this way. So pulling information, organizing information, making alignment logically is becoming much more easier bottom up. And that's the only way that we'll be able to capture information, align this information, and program the tools that in the field that no one wants to change. Now the economics of this becoming possible, and the indicator that this is possible to build it bottom up, is that the stocks of the system of records are going down. Because all the system of records now are becoming dumb databases. And this is where we are coming to the way how we can pull this data and make something smart. Product memory, if we already want to say this word.
Michael FinocchiaroI really had a good time on this discussion. I hope you guys had a good time too. That was fun. Next time, it'll be in a week. We'll have a discussion on the topic that Oleg, a very timely man, brought up, which is product memory — which is sort of a somewhat new concept that was thrown around by Oleg and presumably by other people. But Rob McEvaney, the CTO of Aras, mentioned it at ACE last week. Rob will be actually joining us as a special guest, which would be really cool. David Schultz of TCS will also join us to give us more of a from the field experience because his consultants are working with customers every day on these kinds of things. So it should be a really good talk next week. Many thanks to my panel. It sounds like we didn't quite get to a conclusion. So maybe the EBOM, MBOM thing can take it from another angle, another time in the future. What do you guys think?
Brion CarrollYeah, I think that's a good idea.
JosIt's something from the past.
Oleg ShilovitskyLet's try M-BOM to E-BOM. Let's try it the other way around.
Michael FinocchiaroOkay, we'll go the other way. Thanks everybody. We'll talk to you next week. And thanks again for another great podcast of the Future of PLM. Ciao everybody.
Oleg ShilovitskyTake care, everyone.
Brion CarrollLeave it there, guys.
David SchultzThank you. See you.