Configuration Management: Stop the BOM Chaos!

Episode Summary

Configuration Management (CM) is still one of the hardest, most misunderstood problems in PLM — and this panel doesn't sugarcoat it. In this episode of The Future of PLM Podcast, Michael Finocchiaro brings together Rob Ferrone, Brion Carroll, Jim Brown, Oleg Shilovitsky, and Eric Schrader (Propel) to break down why BOMs still don't match across systems, why the industry's favorite phrase — "single source of truth" — is mostly fiction, and where AI can actually help.

The panel debates the minimum viable data model for CM (identity, effectivity, baseline, traceability), the octopus problem of CM data living in PLM, ERP, MES and everywhere in between, and why variant management, effectivity, and software-plus-firmware complexity keep breaking traditional configuration models. Expect grounded takes on 150% BOMs versus model-based approaches, as-designed vs as-built vs as-maintained control, and why AI is useless without governed data. If you work in PLM, engineering, manufacturing, or digital thread, this one is required listening.

Key themes: • Why CM ≠ BOM management • The myth of a single version of truth • Variant chaos and effectivity complexity • Why most companies still fail at adoption • AI, product memory, and the future of CM

If you work in PLM, engineering, manufacturing, or digital thread—this is a must-watch.

👇 Drop your thoughts in the comments: Where is configuration management breaking down in your org?

⸻

⏱️ TIMELINE

00:00 – Intro + panel lineup 00:09 – What is configuration management (5 definitions) 

03:12 – Biggest false beliefs about CM • “We have a single source of truth” (we don’t) • CM seen as bureaucracy vs performance lever • Methodology ≠ success (adoption is the issue)

06:47 – Minimum data model for CM • Identity, effectivity, baseline, traceability • Why data governance matters more than tools

10:22 – Where CM actually lives (PLM, ERP, MES, everywhere) • The “octopus problem” across systems

15:12 – Hardest real-world CM problems • Variant management = BOM chaos • Effectivity vs configuration confusion • Software + firmware breaking traditional models

21:53 – Debate: Effectivity (date vs serial vs lot) • Why “it depends” is unavoidable • Safety vs cost trade-offs

24:09 – Configuration rules debate • 150% BOM vs model-based approaches • Why rules drift over time

26:10 – Digital thread reality check • Why duplication is inevitable • Importance of product identity

30:09 – As-designed vs as-built vs as-maintained • Where control breaks down (hint: service) • Why “as maintained” is the weakest link

39:38 – AI in configuration management • Change impact analysis • Data structure vs AI hype • “AI is useless without governed data”

48:55 – When is the ChatGPT moment for PLM? • Simplicity vs complexity • People problem vs technology problem • Product-as-agent concept

59:10 – Final thoughts • Data governance as the core issue • Why we’re still having the same debates after 20 years

⸻

🎯 Key Takeaways • There is no single source of truth—only closest approximations • Variant + effectivity = core chaos engine • CM failure is mostly organizational, not technical • AI will help—but only if data is structured and governed • The real frontier: making CM consumable across the enterprise

⸻

📢 Follow / Connect • LinkedIn: Michael Finocchiaro • More content: DemystifyingPLM.com • Events: Threaded! Conference Series

Full Transcript

Speaker

Hello and welcome to the future of PLM podcast. I think we're live now. Um I've got this great uh panel as always uh with regulars Rob, Ryan, uh Jim and Oleg and special guest Eric Schrader. Everybody say hello. Um let's quickly go around the horn and in terms of uh the round robin uh when you say configuration management what are you actually controlling? Go Rob.

Speaker

Yeah. So I think it's um you're controlling product definition um uh across the life cycle so across time. So it's important that the product definition is um uh high integrity so everyone knows what you're building and um at what stage. Boom. Mr. Brian.

Speaker

Yes. So, I'm Brian Carroll, CEO, principal, consultant at Digital Solution Group. So, configuration management, as Rob said, should be everything. It should be what it started out, a new new product introduction, and how it went through its process. It had iterations and that's configuration, management, evolution, and then as it gets through to um manufacturing or sourcing, that should be consistent. And if somebody changes something a vendor or whatever that should be applied and as it goes down to MEES and ERP and so on in those instances if there's any change that gets required because of a sourcing limitation or a factory limitation then that should be rippled back into PLM. So configuration management should be the life cycle of that product configuration throughout uh its variant life.

Speaker

Good good summary Mr. Brown. Um so I I would say that uh it's definitely about controlling the definition of the product from design um hopefully all the way through the service asset. Um but I I think the should be is a little bit different depending on the scenario, right? I mean, you know, you have to look at the difference between a fighter jet where you're looking at uh you know, configuration management by tail number and and managing every little bit versus a consumer product like a washing machine, right? And so the should be is very different for for each of those scenarios,

Speaker

right? It's going to change quite a lot depending on that. Um Oleg.

Speaker

Yes. So I'm Alex Levitzkin, co-founder of Openbomb. Uh for me, configuration management is the product data on the record. So what we have on the record what is uh recorded has history and can be controlled. This is for me configuration management. I still don't know why someone called they use word configuration for this but configuration configuration management. It's all the data on the records that they have. Awesome. And Mr. Eric Schrader, our special guest from Propel,

Speaker

uh, I look at it as the complete product truth. So, item identity, revision, structure, quality, state, and even commercial definition connected in one record. Not files, not documents, just the product.

Speaker

Wow, that was the most succinct of the of the five. That's great. Um, okay. So, I'll throw this one open. Anybody can grab it. Um, and we'll I'll give it let's do two minutes on what is the most common false belief companies have about CM. Who wants to go first?

Speaker

Go ahead, Brian.

Speaker

So, I think I think the uh the false belief is that it's accurate. I hate to say this, but the fact is you got PLM, you've got ERP, you've got sourcing, you've got MEES, and all these systems have a variant of what the bill of material is. And if you don't have upstream and downstream intimation which I call intelligently integrated right not just push it but intimate it uh then you can have variances that u one version of the truth there is no version of the truth because by the time it goes everywhere it's been changed so many times that what it originally was it's the it's like the whisper around uh to each individual in a room uh by the time it comes back to you you know you said can you pass me the water and by the time it gets back to It says you killed your little brother and you know it's really kind of like a weird transformation but I think that's the thing is they believe it's true when actually it's not.

Speaker

Okay. So it's sort of the single most closest source of truth and single source of change like Mr. Hushand would say. Um Oleg you wanted to raise your hand too. Uh yes for me the uh story of configuration management is like we are running out of words that's why we use the word configuration and many people jumping on this and saying it's about product configurations and this is where you start. So this is like the entire story of me around this configuration management is always like how your configuration management is managing my configurations.

Speaker

There you go. That's that's that's that's in my eyes the confusion and problem on this.

Speaker

Let me ask Scott one.

Speaker

Yeah. I think next in the um the hands queue. So I think the um one of the biggest false beliefs is that it's a burden or that it's administrative, it's bureaucratic. Um and you you see this a lot with um you know the post from Martin where he talks about um a lot about the perception of CM. However, it's actually um a business performance enhancer.

Speaker

Interesting. Eric, I think you wanted to just speak.

Speaker

I was going to say uh I think uh a common false belief is that the right methodology will save you. It won't. Uh companies with the most rigorous CM processes uh also often have the most chaos because of either poor rigor or uh manual process that people aren't using. So I think the enemy is non-adoption. I think uh not the perfect methodology.

Speaker

Thanks Eric. And Jim, you had a last comment.

Speaker

Yeah. I mean I think I think mine is um one one size does not fit all. I mean configuration management means a lot of different things to different people and and I I think that for some people you just need to have tight control from getting engineering to manufacturing or especially if it's outsource manufacturing. Um but you know so many companies are waking up to the you know the potential in the service life cycle and really staying with their product and making money on the back end and in that in that case you need to really uh connect it out to SLM. So that I think it's just a very different thing depending on your business needs. Um so one size does not fit all.

Speaker

So let me segue on on exactly that comment. Thank you Jim to the next section which is more on like the object model right when we're trying to model this in our PLM and our mees in our AP our system we're obviously this group is going to be favoring the PLM uh vision of the world what is the minimum set of primitives for doing configuration management item identity configuration rules effectivity baseline traceability what's like the minimum that almost every industry we're going to touch is going to going to need anybody want Grab that one first.

Speaker

Go ahead, Brian.

Speaker

So, um, you put out a list and I like the list item identific configuration rules, effectivity, baseline as built, traceability. Um, it depends on as as Jim brought up what you're trying to manage. If you're trying to manage the clothing, then there's a little what happens because you're, you know, outsourcing the manufacturing in most cases. But if you're doing something that you know enjoins you with manufacturing then all the aspects of uh the configuration even the rules by which a change variant can be applied or how that data gets conformed to fit manufacturing and that coming back up as something that is you know a purchasable thing during like grease or machine oil right so I think all those things that you mentioned are required if they apply to as Jim brought up the business that you're running.

Speaker

Rob, you had your hand up.

Speaker

Yeah. So in terms of MVP, I think there's, you know, things that people always associate with configuration management like effectivity and baselining, but ultimately I think Eric touched on this earlier on when he he talked about um the methodology. You actually need you know like like PLM, you need you need people, the culture, the um you know the human component of this, you need the technology component of this in terms of where does the data exist and how you capturing it. you need the the pro workflows and the processes associated with it and then obviously the data itself. So it's it's the usual kind of holistic challenge that we see with um PLM too.

Speaker

Great. Anybody else want to jump in or do should I move on to the next part of this one? Go ahead, Jim.

Speaker

I'll sort of jump on to what Rob said. I think data governance um you know I think uh you know you need to have processes you need to understand what you're doing but you also need to understand the data across the spectrum of the systems that you're using and how things fit in what a revision means and what an effectivity date means in engineering versus what it's going to mean in your ERP versus what it's going to mean in when you dispatch it to me can be very different so I think that uh you know in addition to the people in process you need to really understand how the data flows across Yeah, exactly. So, yeah, I think the there's quite a there's a lot of industry specific stuff here, right? Whether you're doing engineered order or built to stock or configured order or anything in process industries is going to be quite variable. Um that said, um where should it live? Like should it live on the on the bomb uh inside the part? Should it live inside the bomb structure? Uh is it just live in the rules? Does it live just in the requirement management system or the software feature flags? It's just kind of all over the place, right? That's sort of one of the issues that makes it kind of a ugly, sticky, messy, hard to control kind of monster, right? Sort of a big octopus. It ends up, you know, touching almost everything in the system somehow. So, so I'd like to just note that I think any system, we call them silo systems like PLM, ERP, e-commerce, whatever, all of those that have an effect to need to see the configuration have right to be configuration management delivered, right? So, if you're manufacturing something, the configuration should go into your ERP system and based on the line structure, your mees, right? If you're outsourcing manufacturing, they may just need top level assembly or content like fabric if you're doing garments. So it just has to go wherever a uh the visibility of that configuration is necessary for that silo system to function. I I would I would jump and say that whatever can be on the record and it I'm agree with Brian like whatever on the record we can store this information and this information formally represents the product that's where it will be storing and if it's a document management system like some companies do and if it's BLM system it's any other system where the system will be on the record they will give you configuration item and baseline it will be fine Yeah, I I would I would add to that basically that it's everywhere that it's needed but anchored by one uh item identity. I think you know it's it's a it's a bit of a mistake to make bomb the configuration you know kind of the configuration truth but I but I think that feature flags and software versions and are are now configuration items too. So if CM can't handle that uh you know a firmware version then uh then there's a gap right and so I think we're we're having it challenged by how whole product is defined across mechanical electrical and now software and I think that that uh is is a challenge in CM.

Speaker

Yeah.

Speaker

Let me just jump in. You you said if software can't find its way into a mechanical bomb then we have a problem right and that's where I think you said that the firmware

Speaker

I just said there's there's now feature flags uh and software versions that are configuration items and those aren't necessarily always handled uh in a in a change order and in a revision. Sometimes they're handled and expressed in a specific uh instance that the customer has. Right? So there's

Speaker

there's uh it is a more a more complex problem as you as you add in kind of the complexities of software

Speaker

overtheair updates uh you know feature flags that you can turn on and off. These are all uh they they all go into um kind of system design but but also uh you know kind of make it a bit more complex from a CM perspective.

Speaker

So so let me just add one thing Michael. I just want to I want to bring Jim and Eric together. Jim was talking about as service, right? Service bomb. And the more we get into SAS regulating uh what's going on in a delivered product like a lawnmower or a car and firmware needs to be downloaded to update it on this car but not that car blah blah blah. That software should find its way into the as service configuration management side. If it does then what you're talking about begins to fall away as an issue and become more amalgamated right combined as a solution right you would think

Speaker

sure if your system can handle that right so if your process

Speaker

agre great

Speaker

I think what we're doing is we're talking about what is and then what what should be right the asb so sometimes we need to make clear it's the 2B we're talking about which many people don't have and the asis is what they're struggling with. Right.

Speaker

Exactly.

Speaker

Rob, you want to get a word in?

Speaker

Yeah. Sorry.

Speaker

Excuse me a minute. Um, do we do we all agree that the let's say the lens or the view of um configuration shifts over time according to where we are in the life cycle. So that you know when for example we the the development is done and the man manufacturing is running and the products are in field then the focus is more about what's the configuration of the the products in the field. Um so that there's you know kind of peaks of fidelity where you need to be really really accurate at every stage and for example while you're doing your engineering maybe the manufacturing definition doesn't have to be absolutely perfect because you're not there yet. Um, however, when when you get to there, you do need to be um bang on.

Speaker

I'm gonna change um to the next uh section because we're a quarter of the way in and we still got four sections to um let's talk about variance, options, and effectivity sort of the core uh the DNA of of configuration management. Um round robin uh what's the hardest configuration management problem in the real world? Is it options? Is it effectivity? alternates and substitutes, supplier changes, or software and firmware, which we just talked about a second ago. Thank you, Brian. Uh, rapid fire. So, why don't we go we go the other way, Eric, and then Jim and then Brian and Rob. We'll go the because that's how my screen ended up.

Speaker

So, go ahead, Eric. What's for you, what's the hardest one?

Speaker

Uh, I mean, I think PDM certainly answers, you know, what files exist and who who has the latest and CM is really about what's the approved product definition, right? and when is and when is it valid

Speaker

the effectivity

Speaker

I think the variant uh management is is which configuration is right for a specific customer the market or an order so I I think that's a slightly different question and I think you know most companies have PDM some have CM almost none have variant management in the context of both and that's where bomb chaos I think actually lives

Speaker

someone got the title of the podcast for for that.

Speaker

Oh, he definitely gets extra points. Good job, Oleg.

Speaker

Yes. I think the biggest I think the biggest challenge is discrepancy because between different uh structures and the definitions of the product and we coming from the three directions here. Engineering is simple. If I have revision A, I know what is included and the structural element. Now the manufacturing is getting more complex because if this is a date but I'm still using the previous revision and this is where all the place of effectivity. Now when we go into varants it's getting more messy because sometimes the configur variant effectivity used the same words. This is where people are getting like it's a unit effectivity variant effectivity date effectivity but then it comes to variance and we say there's different configurations of the product. So some people use variance. Now you cannot definitely say what is included because you can have configured structure and you can have a resolved structure. I think all these things together enough to create chaos. So you ask to use word chaos. I think when you trying to put them all together you get chaos.

Speaker

Jim,

Speaker

it's just it's just chaos. I mean that's all.

Speaker

So

Speaker

why are you on this call, man? Come on.

Speaker

I don't um need to manage it. I think the key thing is actually people um you know and all of the all of the issues that uh everybody bringing up are true right I mean there's you know the software software you know mechanical electrical um Eric I love that you brought up like the actual you know inuse configuration swi switches like feature switches and stuff like that it's gotten incredibly more complex but as it's done that you got so many different domains that are responsible you know you've got you've got a service domain you've got different engineering disciplines and then on the back end now you know as Eric you started talking about that that's sales right that's somebody subscribing to a service and all of a sudden you've got sort of a a a salesoriented CRM ERP system that's in involved in it and so trying to get those people to all align on doing something the right way um and not owning their part of it um and having it expand I I I think it's the it's the carbon it's the carbon not the silicon Nice. That's a good quotable. That'll show up on my viral quotable.

Speaker

And and it's chaos. And it's chaos.

Speaker

That's book endless book end. You're getting you're getting what you ask for, right?

Speaker

Brian, um,

Speaker

keep it short. Keep it short.

Speaker

So, it's about a 20-minut statement I want to make.

Speaker

You can handle. So, so the thing is I think it all depends on the PLM and ERP system and so on that you have. We've talked about in prior sessions that overloading the link is a way in which to exclude or include a parent child relationship. Right? So if you're able to do variances in PLM associated by CAD even variance could even include it could include could include color it could include location channel anything effectivity right if you're able to do that then all of these depending on who you are looking at it whether you're the I'm the e I'm the ERP person or I'm the you know supply chain management person or I'm the sales configuration management person any of them would have the ease of being able to look at what is their content and ignore all other content. So if that exists within the PLM system, then none of these become issues. If it doesn't exist, then depending on what it is, I'd say variance, especially by channel, um would be the hardest to maintain uh of all those things you just brought up. Rob.

Speaker

Yeah. I I think um effectivity is a really big challenge uh depending on which industry you're in, whether it's washing machines or fighter jets. But um if you I I think the the real challenge is um status accounting uh for for products that need to be um managed and serviced for for many many years, especially where you haven't maybe had the technology all those years ago to document what's on the product. So you have, you know, battleships coming back into um, you know, be maintained and they don't even know what's on there. And so you have to spend two years first of all understanding what the product is before you can even then think about, you know, making repairs and overhauling it. So I think um you know and whether it's wind turbines or cars you know cars it doesn't matter so much you know if you change the tires but there's there's certainly you know things that do need to be controlled and you know maintenance people aren't incentivized by you know properly documenting the changes they make then you know they in in the case of the fence they've got bombs flying over their heads and they just need to get this thing back on the ground and fighting against. So, they're not going to like fill out forms to say what they swapped.

Speaker

Okay. I want to try something different. I want to um have a a mini debate. Two minutes max. Let's call let's just say Rob and Jim on effectivity. Should it be on Should you do effectivity, date based, lot based, unit assetbased? Boom. Two minutes. Who wants to go first?

Speaker

All right. Rob, you start and I'll tell you why you're wrong.

Speaker

Go for it. 30 seconds for Rob starting now. Go.

Speaker

Yeah. So, I um I think it has to be um a business-based decision based on the um type of products that you're manufacturing and the the types of costs involved. So, and the sensitivity. So, for example, if you need to use up uh the stock in all the places where it's being used, you probably want to then um make it about the um the production cutting point. I don't think dates ever work. Um, and in most cases, I think if especially where you're tracking the assets, then it has to be serialized. That's my perspective.

Speaker

Jim, you're you're uh your rebuttal.

Speaker

Yeah, you made it hard to argue with you, Rob, but uh I would say that

Speaker

I'm trying to cover as many bases like

Speaker

I know exactly. No, I think dates are but I'm going to pick on the one thing. I think dates are important. I think that they're just a guideline. I think you need to think about when you're going to try and cut in a change. You you know, understanding understanding when you may want to because not all changes are quality issues, right? Some of them are actually introducing new features. Um, so I I think there that the date is a is a good place to start. Um, but as you said, the business is going to drive. If it's if it's safety critical, um, you're going to do it right away. You're not going to care about the the inventory implications of it, right? If it's uh, but you know, if it's if it's something that's a either a minor enhancement or a minor defect or something like that, hey, you know what? you know, you're gonna you're going to push that out uh you know, at a time where it's low risk. Um the supply chain can catch up, you can use up your inventory and that sort of thing. So, it's got to be just a collaborative decision, but I do think data is important as a as a starting point, especially if it's a feature.

Speaker

Okay, let's do the same thing this time between Eric and Oleg.

Speaker

Oh, you didn't get a rebuttal. That's good.

Speaker

No, no, we're going to move on because we got to keep it moving. Um between

Speaker

I'll be happy to start. I mean I would say that

Speaker

No, but I I was gonna give you a different question.

Speaker

Give you the question.

Speaker

I'm gonna give you the question. So

Speaker

So you guys got to debate debate and it was a great debate. I mean there was a lot of good input. So uh now between Eric and Oleg it's going to be on configuration rules. Uh do you go with 150% bomb explicit variant bombs or model based uh modelbased approaches? You know model based engineering whatever which uh which configuration rules do you prefer? Go Eric. I mean, I I think the 150% bomb plus rules approach is a power is it's pretty powerful in theory, but in maintenance, it's it's basically a nightmare from a practice perspective. The rules drift and nobody owns them and in two years the rules engine says here's what the product is is valid and then the shop floor knows that it can't be built that way, right? So I think um tying the variance to to commercial SKUs is is a way to align a commercial team and an engineering team with what is being sold. And I think uh as you can if you can do that that helps prevent chaos.

Speaker

Good one. Oleg. What do you this going to be a tough one to to debate but I'm sure you can do it. all those gray hairs.

Speaker

It's actually very it's actually very simple to debate. Uh first of all, I don't think there is a right or wrong. Second, it remind me the old debates about first, second and the third normal forms in databases and which one is right? Oh, you know you can go to third normal form but then you will have a nightmare in everything else and then you can duplicate your data and then you go with some other data modeling approaches and it will work fast. So which is the right one? You go based on what your data is, how you want to configure and what do you want to how do you want to maintain. If you will go go away with the options, great. If you go with if you go away with 150%, great. If you need rules,

Speaker

you need rules. Just only remember what Albert Einstein said. You need make things simple, but not simpler.

Speaker

So, I don't know if it was a debate or agreement, but that's that's where I think it is.

Speaker

Let's talk about digital thread reality. Um so when we talk about configuration management across the thread um you started touching on it because you mentioned duplication because there is this problem that we're duplicating the universe across CMMS PLM ERP MEES. We got tons of copies all over the place. So what um what do you think is the cleanest handshake we can do uh between these different systems that are always going to exist so that we don't end up with uh you know several copies of the truth so we end up with a single source of change Brian

Speaker

um so passing data from PLM to say ERP there is core key data that is identical and should remain identical as it goes into ERP. P and ERP has its own need for data for its operating function in the way that it wants. Same thing with PIM where it outputs to ecom or to big box stores or wherever um or supply chain management if you're trying to regulate uh purchasing or trying to get around tariffs or whatever you try to do. So the data there's a core set of data that's always the same. And I think we brought up the I think Oleg brought up this thing product memory which I really like because it becomes the instance of data that is from all these systems aggregated correctly so that you can put AI on it. Um that kind of form is if you're sending it to ERP there's a core set of data then let it add what it wants. You're sending it to CMS or some other place there's a core set of data plus whatever they add. And so it really isn't a lot of repeat data, but it's aggregate together. It's a whole group of data. The key question is if you were to take that data like ERP and CMS and PIM and whatever, how much unique data would you really want or need to put into product memory so that overall you show the life cycle of a product as it goes everywhere and are managing that change. That's a minute 30 seconds.

Speaker

Who's up next?

Speaker

I'll jump in. Go ahead.

Speaker

When you when you got a left to right flow, when it goes in that direction, it's not too bad because you're kind of cascading information and and it and like like I say, the focus will shift and the fidelity will shift. Um I think when you are, you know, whether it's um you know, making changes, etc., launching new features, up continually updating product. Then you need really really robust uh control, but ultimately the um the baseline is the the product data model that you've all agreed and you say we know what information has to exist where in which systems etc. And then it's just about making sure that you're not just doing um change control to the product itself, but also to make sure that the information flows to all the different places in the organization where it needs to.

Speaker

Nice. Anyone want to add to that?

Speaker

Yeah, I just want to jump.

Speaker

Go ahead.

Speaker

I just want to I think uh Brian hit a very important point is related to identifications. I think the like systems can go out of sync but if you focus on identification that will prevent it. I will give you one just simple example. One day we got a customer came to us and said why you cannot do materials? I said because you don't have part numbers. He said but my cut system can work without part numbers. Why do you need it? Everything called part one. He said the cut system can work with this. I great for cat system but we cannot do anything without this. Like that's that's the point. So you need to identify things then they can go connected. If you don't have it eventually things will be disconnected. So when we talk about this also we we always have this idea of the the different phases right as you go from as designed to as planned to as built to as maintained. Um anybody want to pick let's get one of one of each of you to pick the to defend as designed as planned as built as maintained. Uh and then let's uh talk about which is the most fragile and what energy what you know what what uh should the industry standardize on? Who wants to take as built? It's a chaos. No.

Speaker

No. Who wants to do as as designed? Sorry. We'll start with as designed.

Speaker

Is that more of an as planned then as designed then as built then as maintained. Isn't as planned first?

Speaker

Well, as planned is ambiguous because it's there should be actually as um

Speaker

required.

Speaker

As required. Exactly. There should have been required in the front.

Speaker

Um anybody want to pick up on that? They're just uh I thought that would be fun to have each

Speaker

I'll take as required. I'll take the first one and we somebody take the second one and the third and then somebody else is gonna go I'll take on the back end chaos go 30 seconds

Speaker

as as required really is something that has to take in the normaly and the activity of what is uh applied to the kind of products they build. If it's a motor like the fan above my head hey yo that fan hunter fan that has a certain motor size a certain blade size and housing and material type. So as required should as best it can comply with what may be derable from what a company already has or already exists within the part structures or sub assembly structures of what a company already has. So that's as required. Ding. Next

Speaker

as built. Was that you Jim or is that Rob?

Speaker

As designed.

Speaker

As designed. Sorry. What are you saying?

Speaker

Design it's not a problem at all. I mean this is how engineers see the system design. So that's the structure.

Speaker

I'm not sure you're as required.

Speaker

Really having a hard time finding that as designed and fitting with my as required.

Speaker

So I guess between the two of those you've got your model monitor based system engineering that should be the digital code between them, right? You should be able to go from requirement logical physical uh uh lo sorry f uh functional logical physical to get that

Speaker

that's a different one Michael I think it's not this this required design engineering manufacturing right

Speaker

right but I'm saying that if you're using an MBSSE approach you get the requirements flow into the design right the design is the functional logical physical piece

Speaker

in my opinion and then you go up the other side of the V which is the as planned for the pro the process planning and then as produced right when you build it cuz I there and the there's actually a lively debate in the comments and our friend Patrick uh our analyst most of the time is saying remember manufacturing planning and I think that's how when I think of ask plan I think of that

Speaker

right

Speaker

I think you need to look at it I mean the you know modelbased you have to think about modelbased enterprise right it's not just about the design it really is that that life cycle and how do you take that information and you know expand it down the down on the life cycle, but then open it up for change, right? And I think the the further away you get from engineering, the harder it is to keep data under control. And I love the example of, you know, I think it was Robly said, you know, you got missiles going off above your head, you're probably not filling out that service form. But that's true everywhere. When you get to as maintained, a lot of that information is still on paper, right? A lot of it is service tickets that uh people are supposed to put in at the end of their shift and that sort of thing. And you know, as companies are trying to eek money out of that service life cycle, um there's a lot of value and a lot of potential of uh of fixing that as maintained, but I do think it's the hardest

Speaker

I do see the hands up. I I just wanted to throw in that I think that that's one of the reasons that um data and it have to be separated organizationally because if it's then it's going to be PLM owns it. No, no, no. ERP owns it. No, no, no. It's not about the data anymore. It's just about ownership and power. But if you're just talking about data and it's each organization has a data custodian and a data owner that's making sure that the data is flowing and it doesn't end up piled on a desk, as you were saying, Jim, then I think that goes a long way to to fixing that. Sorry. Whose hand was up?

Speaker

Go ahead.

Speaker

Go ahead.

Speaker

I think Rob has his hand up and then Brian.

Speaker

Okay.

Speaker

Sorry. Go ahead, Rob.

Speaker

Sorry. This has all got a bit chaotic. Where are we now? Uh, Michael, what is it we're doing?

Speaker

We were talking about the as design stuff and we had like one more minute to wrap that up and then we're going to go on to the future of configuration management.

Speaker

Okay. So, it's this am I picking um as produced then and you're in the manufacturing side already.

Speaker

Yeah. So, as built and I'm saying why it's the most important or

Speaker

Yeah.

Speaker

Anyway, so it's it's the most important because everything else um up until then has been a dream. It's a fantasy. It's a desire. It's an aspiration. But until you actually make it, that's when physical things come together. And that's when you see the magic of the product coming into the real world and and either functioning in the way you thought it would do or not. Um and and uh these products are going to go out to customers. So the that is the most important phase for configuration.

Speaker

And Eric, you want to pick up the ased? Uh yeah, I mean I I I agree with Jim that the asbuilt to as maintained is the most fragile. Uh and and that as maintained is it it it's not really under governance. It it's it's it's u that field asset record that can be changed uh over the course of time. And so, you know, as we think about how to to um kind of control that, it's it's understanding what updates have been done over the course of time at at a specific uh you know uh serialized uh number of of product that's out in the field and then how that can be linked back to the product definition so that it can be understood. So, so that is I think where it's it's a fragile transition because you're you're starting to lose control. But if you can manage that work order process from a service perspective, that's where as Jim was pointing out, more and more product companies are getting most of their revenue post initial PO and these this understanding this service problem from a configuration perspective and maintenance perspective and and like how impact uh of current designs is going to ripple out to your customer is is a is kind of a key problem to solve. But it is I think the most challenging.

Speaker

Awesome.

Speaker

So, so,

Speaker

so Michael, I just want to bring up a point since we've gone around the horn and we gotten into as service. Data governance, I think, is the organization that you were talking about that owns the data, right? And I think let's go back to requirements. I require that it be ABCDE based on what's reasonable. If it does not to you know to Rob's point it doesn't run at a certain speed then that requirement was not met which means you should send that back and say uncheck because it didn't work which would tell the requirements world don't ask for it again or you're going to get the same answer as the definition of stupid is doing the same thing twice for the same reason expecting different results. So if it bounces up and down, data governance being the organization, if it goes from what Eric was talking about through to what Jim was talking about, to what Oleg was talking about, what Rob was talking about, to what I'm talking about, then data consistency, data governance maintains the accuracy of that content to the level possible in the system it's coming from or going to.

Speaker

Great. Uh, Oleg, you go ahead. You had a statement. I think the biggest challenge here that's where I think I disagree with the I I disagree with the question I think there is not a question of what is more complex because uh every uh organization or person or responsible can organize structure in the way they want and this is where it all comes like who wants requirements organize them who wants engineering organize them who wants maintenance to organize whereas the problem is is when you need to connect them together this is where it hits the nerve because everyone is trying to put it in the same Excel and it doesn't fit. So, and this is where I care start because and this is the thing that I see a lot recently because companies are starting as a services and not selling product but selling services. maintenance is becoming extremely important for all of them and I see people struggling to connect the engineering and maintenance and this is really really really becoming hard for them because they want to say I have this tail of my whatever they produce or whatever serial number I want to understand what is inside and I'm installing updates there and I'm doing maintenance and I put software there all these things start to get connected together this is where it start to hit hard everyone and not like I can make my Excel of everything but start connecting it's very hard.

Speaker

Well, let's talk about connections and talk about the the future of uh configuration man. We invited Eric on because I think I give uh Propel credit for having been the first agentic PLM to at least to announce right back in March of 2025 if my memory. So how uh Eric have uh have you looked at that um in terms of I know you're leveraging the agentic platform of of Salesforce called agent force and how are you using this modern approach to to using agents in order to resolve some of these issues. I it would just I just want to understand how that how that worked.

Speaker

I I mean I think a great example can be kind of change impact analysis. So having AI basically scan your entire bomb to understand all of the open quality issues, any sort of supply chain data and surface those things so that the you know and and understand that this that this change is going to affect you know 47 downstream assemblies or you know or you know what active customer orders might it impact. So this is where I think AI can really help us and before so the engineer doesn't even have to ask but is it you know can take these uh elements into consideration on positive change and and making the best decision for the company. So I think you know that's that's a great example of where I think AI can be you know used from a configuration management perspective is to to essentially inform and look around the corner because it is a mountain of data that is that is uh that needs to be processed uh when you're trying to you know affect any sort of change.

Speaker

Um I know you've got your hand hands raised I wanted to ask Oleg because Oleg also has a product called open bomb and he's made some AI announcements as well. How is uh open bomb using AI to resolve some of these issues that we've just talked about on configuration management?

Speaker

Um again Michael I probably will disagree with the question but uh let me let me just bring a little bit history. I mean the AI is just technology. So like 30 years ago we get SQL databases that were abroad with the same idea make analysis of impact and data and connections and everything and today we say AI can magically do it. I mean AI can do something that relational database cannot do it and there are bunch of technology in between that we are doing different things some of them different way. So I think the real thing is not if we have a magic technology if we can make a data uh adapted to technology and uh work uh to fulfill the needs so technology can work with the data. Let's put this way. AI is amazing technology but if you cannot tokenize your data your AI is pointless. Now if you can dump all your bombs in the text file but you won't understand the relationships. The AI scanning this text files will give you nothing besides it will hallucinate and will tell you very confidently that something that you will have to disagree. So will AI solve this problem? Oh yeah, if you will structure the data so AI will understand it

Speaker

and you will create a model that will be able to fulfill it then then yes will it be possible to do it and this is where the key okay on this one because I I think that uh data governance is a big part of getting the right answer out of any sort of agentic work that you do and so uh I mean this topic is is uh feeds right into you know readiness from an AI perspective uh for a lot of companies, I think.

Speaker

Yep. We had Brian and uh Jim that had their hands up.

Speaker

So, I'm just going to I'm going to jump back in on the product memory just for a second. I'm starting my little time my little stopwatch here. Um and so AI as Eric brought up to kind of go through and look for oops oops oops and report those alerts so that people can take action that's a very important thing right so it is Oleg said depending on the structure of the data can AI actually traverse it and find things that have cause and effect relationships but one of the things that I see AI agents doing in in C in the CM world is as people are doing things as they are having ECR meetings or as they're doing things in relationship to email back and forth or messaging back and forth or even on a phone call that can be transcribed. This data being brought into both PLM and as it makes value product memory or we talk about product memory as this this area of the world that anything can go in and AI can lay on it. those agents can come right out of this product memory pool and go into ERP, PLM, PIM and so on and pull data as it's actually delivered effective and put it into uh product memory so that in the end AI and product memory and all of your silo systems are all working in a cooperative way.

Speaker

Well, in the same graph, right?

Speaker

I saw a thumbs up, bro. telling every saw there's a response by those

Speaker

so I mean I think a lot of what our data is showing right now is in terms of AI um the value is coming in keeping it simple um there's definitely room for Gentics there's definitely room for a lot of other things um but some of the some of the lowhanging fruit around configuration management is being able to pull that information together across the different systems and across the different stages of the life cycle And I think that's where if you can find information, consolidate it, and look for look for errors and inconsistencies, that might be a that might be an easy place to start. Um, I've got an answer for what does it look like, you know, 5 10 years down the road that's very different. But right now, I think just being able to uh to pull data, put it in one place together, um, so you can identify errors is a a big issue. I think on our list for the this call we had conf configuration classification part normalization nobody mentioned that yet option compatibility checks we didn't mention that either configuration validity auditing that's sort of what Eric said right impact prediction um it was also one Eric mentioned and then automatic automated baselining reconciliation between systems that's the one you just talked about Jim so anybody want to mention

Speaker

I'd like the part classification just for a People talk about smart numbering and I know Oleg, you know, with all due respect, he talks about part intelligent part numbering, but I think that part classification is one of the most powerful ways to make it so that you can find what you've done. You can find based on characteristics and you can only do so so much with numbering that gets you to the point where it's not an 85digit number like a VIN of a car, right? And so part classification allows you the ability to search for and to respond back with and to find data about uh parts subasssemblies and top level assemblies based on characteristics not based on a number structure. So I just want to put that out there. It's out there in the field the abyss people enter part classification is good part numbering is not. So we're done.

Speaker

Okay. Um, anybody? Uh, Rob, you haven't talked in a while. You're usually quite loquacious by this point. So, what do you

Speaker

That's a good word. Good word.

Speaker

No, I'm all good. I think we've talked a lot about the different use cases within configuration management. Um, it's uh it's all good. And we've got 10 minutes left and I know there's a lot of questions in the chat as well. So, I want to make sure we have time to talk to the engage with the listeners. Um yeah well it's a lot of a lot of discussion about um part numbering and it data effectivity people are greeting with Rod that doesn't work um uh but what there was one question about MCPS which makes me want to ask you know in the last 10 minutes and it gets you guys each all five of you at least a minute to expose on it like when in terms of uh you know we had the open AI moment right in 20 November 2022 to you suddenly had this incredible chatbased U AI people even even your grandma could write down and and create a purple elephant if she wanted to right because it was just writing text it was it was I mean it was a pivotable moment it was another uh what was a tipping point it was a tipping point for AI when will we have a tipping point for PLM and configuration management is it coming are we there are we is it 10 years away I I'll let we'll go through each of us we'll get like one minute each. Um, who wants to start? Brian, you had your hand up.

Speaker

Yeah, I'd like to say that, um, and I've been tipping on it. Uh, grandma being able to talk to an LLM and get an answer back so that she doesn't feel lonely is really good. So, that's going to be what we classify as the standard, you know, non-industrial market, right? LLM's being able to keep people company or go to dinner with somebody. It's really weird, but nevertheless, that's happening. I think that if we can move on as industry leaders, this product memory uh profile where we have a metal layer language that says if I'm storing stuff like with Eric's agents running around all over the place, if I'm storing stuff in product memory, then it should follow some norm like what are key values in the in the JSON structure or whatever, right? If we can do that, then I think by 2027, we'll have selective companies that have the vision to move forward with a product memory environment that is a collection of all things coming of relevant value from each one of these silo systems so that AI can create an aggregative business insight based on this profile data. So that's 1 minute 7 seconds.

Speaker

Thank you for that precision. I'm timing me, man. I'm timing me.

Speaker

Oleg is up next, I think. Yeah, his hand up. And then Rob and then Jim. And then Eric, our special guest.

Speaker

I think I think there are two things. And I will start probably with your question about Chad GPT. I mean, what happened with Chad GPT? Simplicity.

Speaker

Mhm.

Speaker

Hit the nerve. People can do something simple. You said grandma can do it. Yeah. So an average grandma cannot do configuration management. It's just way too complex. So cannot do it. So the the the the when we will be able to deliver simplicity and the data is a complex like we cannot we cannot we can I'm I'm pretty sure we agree this the data is complex. So when we will be able to achieve the simplicity moment then the adoption will come. Complexity has a very tough time to win in this world. And as many times as we explained that you cannot type on the phone without buttons and everyone believed into this and keep doing buttons. It was nice but for very small group of people and the moment of time we deliver the

Speaker

tapping on the screen the problem was solved. So the same is here once we will be able and I promise not to do marketing so I will not. So once you will be able to achieve the simplicity of Excel,

Speaker

thanks for that.

Speaker

Then people will start using it exactly like people started to use JPT because it was simple and before that we get what like 20 years of artificial intelligence that everyone was trying to understand what is about and distant from this conversation they said I'm I'm I'm not as smart as you know to participate in this conversation. So simplicity will win

Speaker

rather. So um like you you saw u the Patrick professor Patrick's comments recently why are we having the same conversations for the last 20 years I talked to um I you seen the post from like Chad Jackson recently about the research she's done where he said it's uh you know it's not technology it's the people need I spoke to her early on today she's pulling her hair out and saying I can't believe we're still having the conversation around you know like or change management and why why have we not um you know figured out how to get implement technology. And um so it really for me it's not about the technology, it's about the people. But as we've seen um no one's yet come up with a solution for how to solve the people part of the equation yet either. And you know humans have proved that um we we've we've evolved but we haven't evolved you know the human behavior that has been embedded uh for all these years and we're still behaving you know in very individualistic ways. And so I think it's um doesn't matter how much AI you're going to throw at this, but you need human change. And human change is we haven't yet figured out how to make that happen.

Speaker

Jim,

Speaker

so Rob, you never you never watched Terminator. There's a way to solve the uh the whole people.

Speaker

Um and actually it kind of ties into one,

Speaker

you know, one of the things that I think is is and I don't know it's five years. Um, but one of the tipping points I see is right now we've got all of these companies with big databases trying to track a product and understand what a product, especially once it's out in the field, is doing. And you've got multiple systems and then this system, this company gets acquired by this other system. So somehow for this product that's running around, you know, my car or whatever it is, it's running out in the real world. Um, all of the data is sitting in all of these different places, manufacturer, service people, um, whoever sold it, a dealer, that kind of thing. Here's my thought. Um, give the product itself information and agency. So, the there's an agent on the product. Um, probably multiple agents, and that agent is looking out for the product. Um, maybe we're getting into a little too too much Terminator, but you know, the the car knows what it needs to be serviced and it knows its own configuration. Whether you can look it up in any combination of systems, the product knows, the asset knows and asks for a service appointment and orders the right part, um, orders the right download. So that that to me, if you want to look at the chat GPT moment, um I think that's the moment where you're going to say, "All right, we're not trying to keep information all around the outside and everywhere. We're putting the information, giving in intelligence and agency to the product itself.

Speaker

Unless you're changing a tire, I'm not sure it's going to be able to change its own tire, but

Speaker

Well, that's why you got the the Terminator robot in the trunk.

Speaker

Ah, Terminator trunk. I got you. That's the new option, Eric. I mean I I I will uh maybe uh take it slightly different. I think that now I think the the when is now. I think the the how is maybe more as a consumer. So I think a lot of this uh information needs to get to 10 times as many people as govern the data. And so I think when you think about um CM and making some of this data available, it's really needed across the enterprise. And so I think I think it's now where you can make uh information available in a chat interface through a slack interface through a team's interface that says what's what's the configuration what's the active configuration that I need to to worry about now so that you can and so I think uh I would say now from a consumer perspective and from a consumption of CM uh perspective so I think that's that's really here now I think, you know, it it is uh you know, we talked a little bit about kind of uh all the other things that AI can do from a CM perspective, and I think those are on on the precipice as well. But I think we should think about it as like making it simple for for uh your mom to to do the purple elephant. It's making it simple for the rest of the organization to understand what is the active product, what is the product and in a in a in a point in time. And I think that is is achievable.

Speaker

So actually it's interesting because I remember at um prove it the on the manufacturing side it was all about contextualizing the the data coming off the PLC's and really we're talking about the the moment is when we get all that context that's brought into whatever we're working on without having to explicitly say what life cycle phase I'm working on. It should just be able to give me the context. Right. That's sort of what you're saying.

Speaker

Uh yeah, we got two more minutes. So I think you had a couple more people. Go ahead, Rob.

Speaker

Just I think the thing is you you often need complexity in order to create simplicity. And so I think that's that's the challenge.

Speaker

Brian, you had your hand up.

Speaker

Yeah. I think to Eric's point, you should see the product as per your viewpoint. So if I'm a customer and I have a serialized part or a serialized car, I will see that assembly if you show that per my perspective. But if I'm in manufacturing and I have serialized parts or serialized products coming off the the line, I should see what is the effective bill of material. If I'm in engineering, I should see what is the engineered material bill of material. So that goes back to the viewing of a bill of material with effectivity on the relationship between the parent and child which I call overloading the link right characterizing those links as traverse me when the following is true you want to see what's in this serialized part you want to see what's in this uh the source factory you want to see whatever right so I think serializing is one thing but the key key is allowing the viewer to view through that lens that's characterized by the relationship between the parent and the child.

Speaker

Thanks, Brian. Anybody any any parting comments? I've just got one thing to say, but I want to give space to to Brian uh sorry uh Jim, Eric, and Oleg about what is active was really uh confusing here because what is active for me it's an engineer is different. what is active for me is the main

Speaker

exactly

Speaker

yeah context again

Speaker

right

Speaker

Jim

Speaker

yeah no I think I think it comes down to the data the data data governance and data quality I mean I think the you know what you should be able to do and having multiple views and that sort of thing is is extremely limited by actually the data that's getting into the systems especially further downstream from engineering

Speaker

so I wanted to thank everybody I I want to say also this is one of our best attended podcasts I saw up to 30 35 people uh live. So that's awesome. Thank you everybody. There are lots of questions. I think all my panelists will be very glad after this to get on jump on LinkedIn and answer some of those questions because I did wasn't able to bring them all back into the conversation. I also wanted to say that um uh we're going to do uh the next conversation we're going to talk about why uh most Ebomb inbomb stuff is still done in Excel and not in an MEES or PLM. I think it'll be an interesting one. We'll have a a special guest for that as well. Um well actually maybe I have two special guests. Uh I wanted to get uh Jeff Nunan of the uh on the manufacturing side of Rise manufacturing hub uh and as well as um David Schultz who has a very very deep experience on the MS side because you know we're the future of PLM but ultimately on the when it hits manufacturing PLM and MES are supposed to be to work together and I think there's a bit of improvement that is possible in the the current word uh state of affairs. I think I see Jim agreeing with me. So that I must be on the right track. Um so that'll be the next call. It'll be in in a couple of weeks. Uh if you guys are if anybody's in the UK, I'll be in Warick for uh Threaded Live on my first AI startup conference up there. Um and uh anybody else going to be in V viewable in the public the next couple of weeks? You guys want to pitch anybody conferences coming up for you guys?

Speaker

Nope.

Speaker

Nope. Ace Ace is in the 13th of April. Yep. Everyone else will be there.

Speaker

Yeah, look at

Speaker

Sorry, Eric.

Speaker

Propulsion is May 11th.

Speaker

There you go.

Speaker

It's in Denver.

Speaker

Okay.

Speaker

I was just going to mention the uh the Prostep EVIP which is happening in the next couple of weeks in Frankfurt, I think.

Speaker

Oh, nice. And there's Shar PLM coming in the month of May.

Speaker

It's in May.

Speaker

Yeah, that's gonna be fun. Okay. Well, thanks everybody. Uh we'll we'll see you guys on the next podcast. It'll be some of the regulars and some new ones as usual. Thank you once again, Eric. It was awesome having you. I really loved your perspective. You're welcome back anytime. Everybody cool with Eric coming back sometime.

Speaker

Yep.

Speaker

Yeah,

Speaker

of course. I'll be the father.

Speaker

Okay, see you guys next time on the next podcast. Thank you.

Speaker

Thank you everyone. Thank you. Bye everyone. Bye.

Speaker

Stop. Awesome. Oh crap.