The Great BOM Debate: Engineering, Manufacturing, Service and AI

Episode Summary

The BOM debate is not going away. In this Future of PLM panel — part two of an ongoing conversation — Michael Finocchiaro hosts Christine Longwell, Gus Quade (Autodesk), Brion Carroll, Patrick Hillberg, David Schultz, and Oleg Shilovitsky to argue out one of PLM's most persistent problems: how engineering, manufacturing, ERP, MES, service, supply chain and now AI should connect around the Bill of Materials.

The panel wrestles with whether the M-BOM is a separate object or just a view, whether ERP should own the "real" BOM, how service and as-maintained configurations feed back into engineering, and what happens when AI is asked to orchestrate lifecycle data that is still fragmented across departments. Expect provocations on product memory, Conway's Law, S-BOM (service, software, or simulation?), whether STEP or IFC has a product-data equivalent yet — and predictions on which BOM belief the industry will prove wrong within five years.

Is the M-BOM a separate object, a different view, or an artifact of organizational silos?

Should ERP own the “real” BOM?

Can PLM natively understand manufacturing logic?

What happens when service, as-maintained configurations, circular economy requirements, and product memory enter the conversation?

And if AI is supposed to orchestrate all this, what happens when the underlying data is still fragmented, inconsistent, and owned by different departments?

Featuring Christine Longwell, Gus Quade, Brion Carroll, Pat Hillberg, David Schultz, Oleg Shilovitsky and Michael Finocchiaro.

Timeline:

00:00 Introduction and why the BOM debate needed a part two 00:54 Christine Longwell introduces her background in mechanical engineering, automotive and competitive intelligence 01:29 Gus Quade introduces his work at Autodesk across data and process management 02:20 MaintainX, Autodesk and the service connection 03:00 Jörg Fischer’s provocation: does the BOM even exist? 04:30 ERP, MRP and why manufacturing data cannot live only in ERP 05:31 Engineering defines the product, manufacturing defines the action 08:04 Why BOM discussions vary by industry 09:14 Fashion, tech packs, supplier collaboration and material definition 12:29 Is the M-BOM a different view or a different object? 14:55 Product memory, digital twin continuity and real-time BOM mutation 15:58 Oleg Shilovitsky on people, organizations, systems and ownership 19:21 Brion Carroll on product memory and lifecycle-wide product context 22:04 Pat Hillberg on durable goods, service, circularity and lifecycle responsibility 24:02 Why as-maintained data needs to feed back into engineering 25:36 Aircraft examples, digital twins and recording manufacturing events 27:30 Christine Longwell on organizational silos and AI orchestration 28:29 PLM, MES and the missing visibility between systems 30:11 David Schultz on end-to-end supply chain and service data 31:04 What does S-BOM mean: service, software, simulation or something else? 32:31 Why data normalization must precede AI 33:58 Conway’s Law and whether product structure mirrors organizational structure 35:54 Can any database or AI overcome lifecycle dysfunction? 38:24 Was there ever just one BOM? 39:31 When does the product become “real”? 40:50 Maintenance, MES and the need to look beyond one discipline 43:01 Ownership, user experience and why PLM, MES, ERP and service systems remain disconnected 44:38 Autodesk’s approach to a shared data model underneath multiple systems of engagement 45:06 PTC Orbit, Jetstream and the digital thread question 47:16 Should product memory belong to the CIO, CDO or lifecycle organization? 48:36 Master data models, systems of record and common exchange methods 49:26 Why product data needs its own equivalent of STEP or IFC 51:01 Closing question: what BOM belief will be proven wrong within five years? 51:27 Oleg on data misalignment, unit-of-measure errors and organizational disagreement 54:44 Gus on the false choice between CAD-optimized and ERP-optimized structures 57:37 David on abstracted models, point-to-point integration and manufacturing ontology 59:14 Brion on role-based views, shared ontology and AI-enabled product memory 1:01:16 Pat on digital thread adoption and why change may be slow until it suddenly is not 1:02:50 Christine on BOM as product definition and the coming PLM/ERP convergence 1:03:57 Why there may need to be a part three

This is part two of an ongoing Future of PLM conversation on BOMs, manufacturing data, product memory and the future architecture of PLM.

Subscribe for more discussions on PLM, digital thread, industrial AI, engineering software, manufacturing systems and the future of product development.

#PLM #DigitalThread #BOM #EBOM #MBOM #Manufacturing #ERP #MES #ProductLifecycleManagement #IndustrialAI #EngineeringSoftware #ProductMemory #FutureOfPLM

---

Full Transcript

Speaker

And we're live.

Speaker

So, welcome to another edition of the uh future of PLM webcast. Uh today we're doing sort of a part two of a one we did was it six eight weeks ago about mbomb that was lively to say the least and in fact we never actually got to the end of it so we decided to do it all again. Um I don't have exactly the same host of uh well group of characters uh and peanuts and wise guys and wise women on this call. Um in fact I have two new people. So I'm welcoming Christine Longwell and Gus Quaid uh on this call. Um why don't you two introduce yourselves first and I'll throw out the first question and we'll get started. So Christine, do you want to start?

Speaker

Sure. Christine Longwell. I am a mechanical engineer, been following the industry since 1998 when I got started with Solid Works and became a blogger and worked in the industry, worked in the automotive industry, worked for Ford, work for Chrysler as powertrain engineer, and I've started up some electric bus companies, which was super fun. Um, but I I've been studying the industry um as a competitive intelligence analyst. I've been behind the scenes uh up until the point that I was the director of research at Sim Data and now you know out here having some fun

Speaker

and uh oh my turn. Hi, I'm Gus Quaid. I'm a solutions engineer at Autodesk. I I cover anything inside of data and process management for our manufacturing customers here. Uh which PLM is probably the the biggest one I get to touch on. Uh my background is as a mechanical engineer. I I worked in biotech and robotics. uh designed ice machines for a little bit. That was cool. Haha. Uh but I used a whole bunch of different design and data and process management tools, experienced companies that were pretty buttoned up and others that were maybe a little messy. And now at Autodesk, I get to meet with companies like the ones I used to work for and about 200 a year. And I get to hear what's good and bad, where they want to get to and I help map that to our solutions and by way of PLM a lot. And uh bombs come up a lot too. Mbombs come up a lot too. So, I I'm excited for this conversation.

Speaker

I suppose that soon you'll have a little bit more on sbombs thanks to the uh awesome acquisition you did of Maintenance X. Congratulations. That is an absolutely fabulous company and you're lucky.

Speaker

I don't know what I'm allowed to officially say about that besides just like good move. I'm excited about that one. Yeah, maintain.

Speaker

They paid a premium price for it. We can say that because it definitely wasn't worth 3.6, but

Speaker

they're number one and I guess the price tag shows. [laughter] No, it was exciting because I I was had the privilege of meeting them and interviewing them at uh prove it in February and I was fairly blown away by by what they were doing already. So, congratulations. I just wanted to get that out there. Um so, today we're going to talk about the embomb already. There's been controversy on the uh on on the chat for this call because our our mutual friend because a lot of us know Mr. York Fisher, this guy. Um, and he's already uh throwing in the [laughter]

Speaker

No, he's always, you know, he's always like this with all his photos, you know, like this. Um, and he threw out there that uh this is old school. Mbomb doesn't exist. What you usually refer to as MCAD bomb and the relevant only bomb, of course, this is a SAP guy talking. The only one that exists is the MRP uh bomb which is bomb segments that have to be supplied to the correct locations in the ERP system. That's the correct structure. No discussion needed. Um anybody react to that? I think that's

Speaker

and that comment I mean that post got 50 comments. The post [laughter] that said we do not need to discuss this got 50 comments. I [laughter] got 1,700 interactions. So

Speaker

wow that's a lot. fighting. [laughter]

Speaker

So, who wants to who wants to pick who wants to debate virtually Mr. Fischer because I invited him. Let's I invited him on the podcast. He did not answer, but we did invite him here. So, it's

Speaker

he said he was teaching. He was teaching today.

Speaker

He was teaching right now.

Speaker

Yeah. You got to you got to put students in front of everybody else, right?

Speaker

All right. Well, we'll uh we'll bring him on for part three if if any of us survive after. Well, Rob's supposed to be here. The one that took the fixture of us fighting and hit us. So,

Speaker

[laughter]

Speaker

Anyhow, I don't know. Uh, you want to start, Christine?

Speaker

Do you think it's

Speaker

I'm I totally agree with them, so I could just drop off right now. [laughter]

Speaker

No,

Speaker

you know, I I'm gonna I'm gonna raise my hand and and take the stab at it being the ISD95. So, I want to pre preface my answer by the fact that I don't really run into the concept of an Mbomb very often. It's something that appears to be very discreet manufacturing oriented. So, if I'm in batch or any kind of a uh

Speaker

continuous

Speaker

a continuous process, if I'm using or you know doing something that's similar to an embomb, we're going to call it like a uh there's there's a recipe that's associated with it or a specification or a you know SOC. There's a nod of different ways that it gets answered, but you know, the short version of this is yes, the ERP has a certain amount of information, but where all the detailed design occurs out on the plant floor and what's actually going to happen, that's going to be in something that exists like the MBond. So, you know, my position is if you think of all of this is going to exist and they say, P, I I got a whole load of MEES software to sell you that disagree. So,

Speaker

there there's my my parting shot. Go ahead, Christina. The important thing that you said is what is going to happen.

Speaker

What is going to happen is an action. It it doesn't deal with the materials. So what manufacturing cares about is how we put this whole thing together. What engineering cares about is what the thing is, what the recipe is, what the product looks like. Um, and in between those two things, of course, you you can't have this conversation without going through the supply chain. You can't create the action to make the thing unless you have the stuff to make the thing.

Speaker

Yeah. Yeah. And so within when I say just, you know, the action of that, it's, you know, S95 or I say 95 has what's called the definition land or, you know, the definition this is the what it includes the materials. It includes the the equipment. Those are the it's the role base of equipment where I'm going to do that. They often get conflated or what the CMS would call the asset itself. But IS95 has something called a physical asset. It's more like the tooling. So if I'm making pizza dough and every time my stamp cycles I make four balls of dough or five balls of dough, that's that's the physical asset that's done on the equipment. And then finally, there's personnel. So yes, all of the materials are there. Even though there's an inventory component to S95, we're really looking at when does the material hit the shop floor or what does that look like once I get into the action, but absolutely that entire bill of process, MBOP, all of the work instructions, you know, all of that is contained. And I've just never seen that level of granularity that's required in an ERP. And frankly, I don't think it should. So, I'm going to disagree that the MBOM needs to exist, but that's that's my take. Wait, wait. You're saying that the MOAM does not need to exist or you're saying that no absolutely needs to ex it needs

Speaker

not just an ERP. It cannot be only owned by ERP.

Speaker

Correct. The ERP is going to provide a lot of the guidance, but this is when I go actually the definition of what things get made. I just don't think the ERP should contain it. It's more of your enterprise resource planning. Christina, it gets back to your supply chain comment of where am I getting this material? What are the specifications for it? when I receive the material what are the quality tests anything that of is of that nature yes that is part of that supply chain but once I am now I I still have to define how it's going to actually flow through that um the material process what are the quality checks that are internal to the manufacturing process that has to go along with it so um yes

Speaker

another side um debate that we had um and and Brian you come from this background of of fashion it's also sort of industry specific right I mean David, you just said that in the process continuous world, it's a different thing as you're doing with recipes, formulations, specifications. In the high in the fashion world,

Speaker

we may or may not be manufacturing. We might just be sending a spec and some third world country is actually making whatever it is.

Speaker

Um, you know,

Speaker

yeah, Michael, I think, you know, I'm listening to this stuff and it does differ based on industry, right? If we can't agree it differs based on industry, you might as well unplug the electronic devices and go home.

Speaker

So, no, but you'd risk having your head cut off by the fan. So, we don't want to do that.

Speaker

There are similar similarities though. They are all different like the the recipe versus mbomb in the process versus discrete manufacturing. That one's a really easy line to draw. And if you can't agree on that one, let's unplug everything. Fashion and let's say like a consumer product like, you know, I'm an electric fan above my head. Oh, or the fan above your head. There you go. Watch out. Exactly. Uh they they both might actually have pretty

Speaker

actually similar like ways of managing the the definition of the product where they just kind of draw something up and throw it over to something overseas. Let me just add manage that box.

Speaker

Let me let me just add one thing then you guys can carry on down the road. Is that when you get into fashion and you get into retail as in the garments we're wearing and the ones that Pat just swapped, right? is that [laughter]

Speaker

well's not aware I just took off the t-shirt studio ax and you did whatever you got to do. So the thing is that the fabric is key as an ingredient to the design. So you would never have a designer plus developer of a of a garment ignore what the material was right down to the feel and touch which means it is like a recipe except the fact is that you know you're not giving freedom to the factory to do anything they want. You're saying this is the material, this is the supplier, this is the color. It's a button or a zipper. It's this season, this size with this [clears throat] color or not.

Speaker

Okay, this little plastic part here though, I'm going to give that same definition to my contract manufacturer though. I'm going to say like using this material. I'm sourcing, you know, my raw pellets from that person over there. I want to have this sort of like glossy finish on it. I chose from a catalog of like a hundred different little glossy finishes. So, I'll actually say like there's probably more similarities, too. Well, the thing is you can say it's factory sourced if you have trust in the factory and it could be like a zipper as Feno was saying. You know, I can always tell a product by its zipper. The zipper goes, I know the product sucks. So [laughter] the the fact is the fact is that each industry may have freedoms and non-involvement by uh suppliers in the definition in the ebomb because if I'm looking at somebody doing apparel, those sources are right in. If I'm looking at somebody doing footwear, that factory is right in the PLM system. They're right in there forming the whatever around the last and they're determining yield in the Ebomb and then it comes through as a spec as Fenos said it becomes through as a spec that is a tech pack that could be off to other factories right so there are so many different uh methodologies that are used whether it's a recipe that delivers batches and then gets logged so that you can recall a batch if something screws up Or it's things like the product above my head that's spinning that has only variances on the blades and maybe the housing color and that's it. But that means a different blade because it's painted differently for the black one versus the brown one versus the silver one. Right? So Mbomb has to exist and it is different than the Ebomb because the Ebomb may be only one for that fan and the Mbomb is five different fans. It could be that way. Okay. So, I'll I'll back off and get back into the balcony where I generally want.

Speaker

Brian, what if someone will come? What if someone will come and say, "No, no, no, no, no. I want to have five configurations of this uh fan and it's I want it in the engineering."

Speaker

Well, then you I'm not saying it. Oh, here you go. Thank you.

Speaker

I I believe you. You and I have had this discussion since 1804, right? I think

Speaker

I think the PLM system should have the Ebomb, the MBOM, the as manufactured, the as the as shipped. All of them should be No, I'm just asking based on different views.

Speaker

Okay.

Speaker

Okay. Overloaded.

Speaker

Brian, can I ask you having worked in fashion?

Speaker

Yeah. Um, I didn't find that a lot of the suppliers were actually in PLM, but everything that got conveyed was conveyed inside the tech pack. The tech pack was really that the thing that by which you would contract against and somebody would then send the things back. What's in the tech pack is a bill of materials, but it's also a m material specification. But who owns the tech pack? Sourcing. The thing is the product that my group built, Flex PLM,

Speaker

Yeah.

Speaker

suppliers were right in there. I mean, right in there.

Speaker

Sure.

Speaker

When it came to lab dips, when it came to fabric, uh, you know, shipments of samples,

Speaker

they were right in there. They were going banan. So, by the time that tech went out, it wasn't sourcing figures it out. Sourcing was in the system sorting it out.

Speaker

Right. So

Speaker

right

Speaker

different products have different limitations. Ours didn't. We had factories in. We had material suppliers in. We had, you know, the tech pack was done after developers and designers sometimes validated that that supplier was going to actually do the right color on the right fabric based on its construct and blah blah blah blah blah. I don't want to get into that detail, but

Speaker

I'm just saying PLM should. I use that word should include everyone otherwise you bifurcate meaning rip apart the Ebomb from the Mbomb and it could be multiple Mbombs if you're manufacturing in multiple factories holy crap you're like a you know chasing the rabbit in the yard if you make a change in Ebon you got to go oh yeah right I got to update all these people well I hope they got it if they didn't you don't know what you're shipping until it gets returned because it's crap

Speaker

so

Speaker

but but to that point I wanted to ask There's actually a question in the chat from Kershhat Oaksu. I hope I didn't pronounce your name wrong. Um, in the future PLM, if the future of PLM relies on an absolute digital twin continuity or as OAG, you like to say product memory, right? Uh, why are we still treating the MBOM as a separate downstream static package rather than a real-time algorithmic mutation of the Ebomb driven directly by production floor kinematics and tooling streams? Not a bad question. here. Here 1049 here. [laughter] I like that. Oh, you want to pick that one?

Speaker

I I I don't [laughter]

Speaker

I think what what what I wanted uh to mention again maybe we can we can take this this this question later. I I I think what what I was listening now and also I think it was very good comment from yours this morning speak about uh two different dimensions and I I will come to product memory ideas but the two different dimensions one of them is people and organization and the and the second are systems so in every place where I've seen the I would not call it fight fina but I appreciate the kind of marketing works. So you need to call it fight. But where in every place I've seen it those discussions and I've seen in many implementations it all comes around what people how people want to work uh and then what systems they have in place. So, and that's very connecting to Christine what you said about you know you put it you you put it in startup in one way and you put it some companies in a different way and I think Brian it goes to the point of you know tech park or if it sits inside of your flex PLM system or some other systems and it's also related I think to the questions about MEES and some others that were asking I think those are great questions to me what I've seen in in in many implementations people coming and I have engineers wants this, I have my procurement wants something else and I have someone else in maintenance wants something third and those are kind of introducing the organization and responsibilities and people really wants to own it. So this is where it first comes on the point like why I want to and then systems and this is where uh Mr. Fisher uh ideas and I had this conversation with him a year ago already. Who owns what? I mean if SAP needs to own everything, I'm fine. I mean this is this is this is okay like put everything in SAP if it works with your organizations. So those are but those are two dimensions and your argument about convey law that you know everything is following the organizational structure. It's absolutely right. If organizational have engineering and manufacturing and manufacturing wanted don't move my cheese. I want this embomb to structure like this and engineering saying don't touch it because I made this structure in you know for the sake of this conversation in solid works and that's how they want to do it this is fine these two dimensions always I've seen them in all conversations and how to call them you know call it orange black and blue you know when we getting our examples of different bombs we saying call it yellow bomb blue bomb red bomb just to make everyone live in peace I mean that's just my perspective maybe simplify it now the questions that are coming around product memory and I certainly take a blame and saying that everyone understand word memory differently. So I need to probably put a little bit more explanations but this is this is a context that can connect between them. So we somehow we need to connect because something that exists in engineering and how reasoning engineering and why they put their things needs to relate it to somehow to logic that exist in manufacturing. And this is where uh Dr. Fischer came completely right. He said without uh without details of manufacturing in logistics you cannot do it but you need to respond and correlate it to uh to engineering. And then I've seen many questions many comments to this morning in LinkedIn people say like how you connect those transactions together and how keep them how you keep them together. So it just what product memory just don't don't argue the term but this something that connects all these pieces together and the logic together should exist.

Speaker

Let me let me I want to add to what you just said. Okay. So product memory in my mind should not exclude anything about the product. What that means is the ebomb as formed are transactions when ready go to product memory. embomb in my mind should just be a different view of the same bill of material. So you don't say I didn't know what engineer had because it's in the freaking engineering bomb. So if you can set up the view for the mbomb then you're adding additional components or adding sourcing content or adding

Speaker

already want to disagree with you. I just see [laughter]

Speaker

making I tell you now

Speaker

all of our all of our boxes turn blue because we're all talking. [laughter]

Speaker

Um I would go with what Brian just said. If we get rid of the Ebomb,

Speaker

we need to adopt design for manufacturing and we need the engineers to design their product such that the manufacturing system can build it.

Speaker

I agree.

Speaker

Okay, there we go.

Speaker

So, but but that still doesn't mean that's not the Ebomb. It just happens to be the E/MBbound, right? I mean, what what why we're building walls that have a letter and as Oleg said, it could be the blue and the yellow and the red. I don't give a right? But the fact is that it should be that everyone that can use the utility. Now, it depends on the system.

Speaker

Yes,

Speaker

some systems don't allow you to do variances like Oleg system open allows you to put up different views wrapping it around like it's a 360. Ooh. Is it is a different bomb a different view or is it its own thing? I had this debate for like hours.

Speaker

It's own thing. Yeah.

Speaker

Well, it is its own thing. But that means you turn down the view for MBOM.

Speaker

Why? Why? I don't I you know I'm the customer wants certain capabilities in their product.

Speaker

The customer wants certain capabilities in their product and the manufacturing system has a different set of capabilities.

Speaker

I know. And somehow we need to align those things.

Speaker

Yes. Do do

Speaker

and those people don't talk to each other.

Speaker

Engineers are sitting in their office talking at lunch.

Speaker

Yeah.

Speaker

But I'm gonna talk about Oleg's bomb open bomb. I'm just going to give him a plug. Why not? He's sitting right there. His system [clears throat] as it is defined allows you to turn on different views. It's what I call overloading the link saying the relationship between this parent and this child exists only for manufacturing visibility. Why? because I want it. I don't give a crap. Engineering said no.

Speaker

Let me I'm sorry. Let me expand on this a little bit because I think I think we're moving into a new So, first our manufacturing methods were largely de I mean they originally developed kind of for the Model T and then they really took off during the World War II arsenal of democracy and we're still doing stuff that's about 75 years old. But customers and society and I'm I'm going to that level are beginning to b demand you new new things. And we kind of talked about this in the 737 Max and the idea of a digital thread

Speaker

where customers and society are presuming that the OEM will maintain responsibility much deeper into the life cycle.

Speaker

Yeah.

Speaker

Now in the case of apparel who cares, right? Once it's out the factory door, we don't even even the customer doesn't care about you%. not that concerned with the OEM maintaining my shirt, right? But in my aircraft carrier or my airplane or my car or more than likely when you start getting down to home appliances, yeah, the microwave I might just throw it away, but the washer and dryer I want it repaired, right? There's some there's so there's a spectrum here and there's something in the middle of that. But as we move toward this world and if you start looking at um circular economies, so even in apparel at that point with circular economy,

Speaker

we need the OEM needs to pay attention throughout the entirety of its life cycle all the way into disassembly and disposal.

Speaker

So at this point, we need just a we the World War II methodology where we really didn't care what happened to the airplane after it left the factory. that's no longer viable and we're going to need something new for this.

Speaker

I agree.

Speaker

And I'll move into this and say and and a big piece of that is the service bomb. There's a disposal bomb that we got disposal of something rather that we got to talk about, but a big piece of this

Speaker

is the service bomb.

Speaker

And we need to have a feedback loop from the service to the engineering. Right.

Speaker

Yeah. Right. But but that becomes so Pat I'm just going to say that that becomes the as maintained and one of the things that remember we talked about the aircraft I don't remember the exact name and the number how many people died but the fact is if the as maintained changes something in order for it to continue to work that should ripple back that should go back that should fly back to the engineering bomb to change every future and it should also tickle

Speaker

all the other serial numbered planes to say infield replacement. Bam, bam, bam, bam, bam, bam. Right. So, there are some things in the as maintained that should come back in because they just save people's lives, right?

Speaker

Yeah. And there are there are examples of that that and I use this one in my class. The TWWA800 um the fuel tank exploded 20 minutes out of um this is in 1990.

Speaker

Not a good thing,

Speaker

right? And [snorts] the they were able to to pull it out of the sea. And because they were able to pull it out of the sea at a great deal of expense and work and and some risk,

Speaker

they realized that this problem, I think it was the MD-80s, um they realized that this problem could exist in other aircraft. And they did at that point, the FAA did at that point go back and say, "You've got to fix all these wiring harnesses

Speaker

in these planes because of this problem that we had on the first one." And a little after that when I was working at Boeing, I learned that the FAA then began to require what was what we would now call a digital twin on

Speaker

on all aircraft manufacturers. So in the process of manufacturing, the example that was given to me is if a forklift runs into the aircraft while it's being assembled and you have to take a piece a skin off and put a new skin on, you've got to record that information. So

Speaker

yeah, that's that's not a planned event either.

Speaker

Yeah. Right. Exactly. Yeah. you got to cover all these immersion events. So, at any I'll kind of wrap up by saying I think we're into this. I think we're moving Well, let's see. First, there's a difference between durable and non-durable goods. So, apparel is a non-durable good. We probably don't care. The OEM doesn't care about

Speaker

unless you look at circular economy,

Speaker

but the circular economy does, right? Yeah. Exactly. Exactly. In particular, when you look at a fast fashion and that sort of stuff, right, you got to start thinking about the disposal phase, durable goods, you need to start thinking about the service phase. Um and the first step of the service phase is the manufacturing phase. Right? So,

Speaker

right.

Speaker

So, there's there's this continuity that needs to

Speaker

that's where that mbomb, let's call it an Mbomb, meaning what was done in manufacturing has to live on as a static state serialized

Speaker

and either I have a VIN on my car, right? vehicle identification number that's that says that my whatever the hell it is Toyota something um has to be maintained individual to any other similar car that's out there right and that's that durable good you're talking about so that's where the mbomb or the becomes the asered bomb and the longevity of all of these should be and I'll go back to Oleg system right it should be where it just tentacles out and that gets into the product memory. And that gets into what's been serviced in uh the world, product memory. If you apply AI to it, it goes, things are still going good. Things just, oh sorry about that. Oh crap, something happened. I need to do something, right? And the product memory is the saving grace of all of that because it looks at

Speaker

Go ahead.

Speaker

And silos exist historically. Think people think that silos exist because everybody's using a different system. But guess what? People are using a different system because organ organizational silos exist because different organizations have different needs and people like to gatekeep their information in these manufacturing companies. Not sure if you've noticed this,

Speaker

right? But what's going to happen or what's [snorts] happening with AI that I'm seeing is this orchestration layer that PTC and Seammens have both rolled out this year.

Speaker

Um, you know, AIS is doing it. AIS has has capabilities. So what AI is going to do is is it's going to chip away at these silos at a higher level and enable visibility into places that visibility's never been seen before. in really interesting ways.

Speaker

Well, that's actually that I did a presentation on that just like two months ago talking about PLM and MEES orchestration because like rarely the people in PLM get to go into the MEES like if you look at like really upstream engineering but there's valuable data there and and vice versa like people who you know their primary system of engagement is MEES they don't get to go upstream into like the design tools necessarily but they have something to learn from each other. Yes.

Speaker

And the data is is being built out. Additional information is being added along the way

Speaker

and and yes, visibility is great, but my definition of focus working in a startup manufacturing company was deciding what I don't care about.

Speaker

So, so that's the thing.

Speaker

Tell me what to make and I'll make it. Tell me what to buy and I'll buy it.

Speaker

Right. So, Christina, I just started a company, Vivid Nexus, right? Which means clarity in connection. If you look at vivid nexus to put together it um and that is totally focused on the drawing in to product memory from a wide range of silos because you to your point organizations use systems that complete their role and they don't really give a crap one way or another about how the data got in but it's going to be good for them. They're going to do what they got to do and then they're going to ship it off to wherever that next silo is. Right? And product memory has to be the orchestration as you said of all of these product memory has to be drawing in from all of these silos and normalizing that data so AI could look across all organizations. That's where the world's going to go. But we can't say that product memory is only for this silo

Speaker

and PTC came out with Jetream. Go ahead. Sorry. No, I was just going to say so I was going to jump off of what Christine was saying is that you know we looked at how do we do end toend supply chain from you know McDonald's in Australia that had the my Mac app and I could actually scan the QR code of my Big Mac and and it could tell me exactly where the bakery that made the bun the the farm that that produced the the beef for everything that was there. The same thing applies for even my service. And and I think when I was first introduced or brought into this call, it was always the challenge of going from Ebomb to Mbomb and now we want to add in this SBOM. And this is really where I start to talk about, well, there just needs to be a standard way to do that. And well, guess what? There is a standard that allows us to do it. We just always think of it as only purely manufacturing. But there's any maintenance operations.

Speaker

I'm sorry. First first things first, what what is your definition of S and Sbomb? So that's the service bond. That is that piece where I've now done some uh work on it uh on a product after the fact, but that needs to come back. So you know, do we all agree on this?

Speaker

Yeah.

Speaker

So wait uh I would say like that's an as maintained bomb, right?

Speaker

Like some people would call that as apologies. Yeah. It's

Speaker

I was going to say for something the service bomb is like oh this is the compilation of all the service kits and services and you know more like a a small cut of the bomb plus the IKEA Allen wrench is like on my sbomb.

Speaker

Okay. Oh perfect.

Speaker

Yeah. Thank thanks for that that clarification.

Speaker

Software bomb.

Speaker

Oh or simulation or Yeah,

Speaker

the bombware italiciz.

Speaker

Yeah. No, thanks for the clarification. So, for me, it's just really anything that happens. But, you know, regardless of whether it's the the the um the service bomb or here's your here's your spare parts material or here's the software you need to run it or you know, regardless, you know, it comes back to what Christine was getting at is we still see silos because not because software exists in silos, it's because companies exist in silos. We need a common way of exchanging that data. And and I think going back to the very first the premise of this is really hard and now we're trying to add more integrations. And I think we're at this point where we think AI is going to do all this magic stuff, but the real reality is is because we're call we I mean I just used the term sbomb and I used it differently and now all of a sudden we want to apply AI to something. It's we got to standardize on the data that's coming back. Go ahead, Brian.

Speaker

David, what what I'm saying is that normalization of all silos data has to preede the application of AI. So, let's say to your point, by the way, I was driving on the way in New York.

Speaker

I was driving on the throughway in New York. I stopped at a McDonald's

Speaker

and I had the best Big Mac I've ever had in my life. So, I went back to I did went back to the counter. I said, "Who made this Big Mac?" And the guy goes, "I did." I said, "You did the best." So, I relayed it to the manufacturer of the Big Mac.

Speaker

Unbelievable. Never had it like that. All the patties are usually screwed up and you got to reorganize. So you you just need to go where they make the patty sometime because that is the best Big Mac you'll ever have. Man, I love going to that place. Anyway, go on.

Speaker

Well, but the thing is you have to normalize all of the silo data. You have to if you don't normalize it and you know this vivid nexus now has a patent map, tag and transcribe because it has to map, tag as it goes into product memory and then transcribe as it comes back out. If you don't do that, nobody knows what the hell you're talking about and AI is useless, right? But to your point, every silo

Speaker

should inject its data and normalize it as it comes in. And if you apply AI to that, you've got product, you've got business, you've got organizational AI, and that's where you get value and gain, right?

Speaker

Going back to Yas's comment and today about Conway's law. So the the idea is that a product will follow the organizational structure, right? That the structure of the product matches the structure of the organization

Speaker

to what you're talking about with you know some some value in AI without first breaking down Conway's law.

Speaker

Are are you kind of saying like if I have a really flat organizational structure like I have one you know everyone operates in one group that my product structure is also going to be like very simplistic and it's like there's just one bomb. Whereas if I have many silos then I have many different records to represent that one product.

Speaker

Right? And and think of think of the words that we use to define a corporate. Think of the words we use to define a life cycle. Right? We have tiers, we have departments, we have divisions.

Speaker

All these words are divisiveness, right? We we encourage divisiveness in our product life cycle.

Speaker

Are you a matrixed organization or not? Like

Speaker

are you matrixed? you know is all of marketing in one group organizers.

Speaker

My point is the organization is not big enough

Speaker

but if you're thinking about the life cycle you can't limit your thinking to the OEM.

Speaker

You've got to think about everything from the supplier out to the user. So when we talked about the 737 Max there were failures at there didn't seem to be no there was one fail let's see there were failures at Boeing there were failures at one service supplier there was a failure at a second service supplier there was a failure in pilot training so to keep those planes flying you need a digital thread in my view across

Speaker

supply you know a thousand suppliers one OEM dozens of aircraft airlines thousands of pilots hundreds of service organizations.

Speaker

Yeah, that's all got to be connected.

Speaker

That's the instantiation of Conway's law.

Speaker

That all has to be connected.

Speaker

So, how I mean I my my point is I don't think a database I don't think there's any sort of database artificial intelligent or not that can overcome those dysfunctions.

Speaker

Well, Pat, I would say that if if you started out knowing the dimensionality as you just went through and my head was about to go poof, right? Because you got pilots, you got this hour, you got that guy's drunk, and you got all these things, right? That [laughter] that the operational stability of an airplane, right? Then you got all the humans that are on it or aren't on it because it just went into the sea, right? That whole thing to keep that digitally managed, it it ain't going to happen. The reason is there isn't a godlike organization that says never let go, right? Because everybody lets go. Okay, my job's done.

Speaker

So to keep it going, you need something above all of that in order to say, I the above thing have responsibility for all of that. And until you get that godlike figure, you're not going to get what in the case of airline use or even trains, you know, trains are going at 70 m an hour down a track with a sleeping conductor that's got, you know, he laid down on the uh what is that? When your foot falls off, it shuts off the engine.

Speaker

He just fell asleep on it and you're going. So, the thing is all these things don't have godlike uh representatives. they don't. And so we're always going to have times where there's a distance between what you should know and what's really going on and how it's going to affect everything. And if we try to plug it, um, it may be plugged for some, like a shirt, that was easy, but for an airplane, I'm letting go. I'm going back into the balcony where I feel safe.

Speaker

Let's let's bring this back to Ebon MBA. Are we are we aligning on the bomb which is closest to our own work and therefore are we aligning on the bomb which is in our own silo

Speaker

can break down silos. [clears throat]

Speaker

I I was going to I I was pondering this question uh yesterday getting ready to come on here kind of like the Ebomb versus Mbomb. Uh Olig's seen a funny picture I made that had Dr. Jorg and Yoss on it regarding Ebomb and Mbomb. Um it but prior prior to like all these different disciplines where you know we we didn't have electrical electronics and software and all these things. It was just like purely mechanical like you know [clears throat] did we make a bomb even that was an ebomb? Was it just an M bomb? Did we just make the bomb once and it was manufacturable and it had all that definition in it or did we still have

Speaker

sourced? Are we gonna make it? Are we gonna buy it?

Speaker

Where are we gonna get it? Look, even earlier though, we used to make, you know, some folks used to make everything in house. They still had to source the materials. That's right. Maybe they didn't have like as fine of a magnifying glass as to where they got it. They were just like, "Get some aluminum.

Speaker

Get get me a billet

Speaker

from somewhere." I I wrote a blog a little while that nobody cared about where I said that that's the supply chain is kind of like the story of the velvetine rabbit. The supply chain is where it becomes real until you have sourced it and bought it.

Speaker

True.

Speaker

It's imaginary.

Speaker

True.

Speaker

No, it's still puzzle pieces at that point. You've got to you've got to assemble the puzzle pieces together.

Speaker

It's not real until it leaves the factory.

Speaker

It It's real. Well, it becomes real.

Speaker

It can become real

Speaker

through through this because that's not [laughter] the organization going back to what you said. This is the point at which people spend money,

Speaker

right?

Speaker

You know, that's when they start money,

Speaker

but the customers don't spend money until after manufacturing.

Speaker

No, Pat, I would say I just saw my son posted something. You know, there's a Brian Carroll number two out there somewhere in the world.

Speaker

He just posted something where in the retail community, you can actually sell a digital garment to somebody that wants to put it on their avatar. So it never ever ever becomes real. Never. It's sold as a

Speaker

as a I want to wear this shirt. Boom. You got to buy it. That's freaky.

Speaker

Yes. I I I'll absolutely give you that. If you want a product want to move places though, you [laughter] need something physical.

Speaker

It is a product. It is a product.

Speaker

Oh, sure. It's It's software.

Speaker

It's a software product.

Speaker

It's a software product.

Speaker

But if if you want to eat food, if you want transportation, you need something physical. Yeah.

Speaker

When I go to ERP conferences and people look at me like, "Why are you here?" I tell people, "I deal with the making of the stuff."

Speaker

If it doesn't have to do with the making of the stuff, I don't deal with it.

Speaker

The making of the actual physical

Speaker

of the physical stuff.

Speaker

Yes. But there are there's a market now for non-physical assets

Speaker

that you have on the app store. Yeah.

Speaker

So Pat, I think you hit on something here earlier when your comment about do we just look at this thing because it's our lens or our view of it. If I'm in I'm in maintenance, I see things through the maintenance lens. And you're absolutely right. And I think this really comes down to the the breaking down of the silos is really a people problem. We have to have discip people discipline thought discipline action of we are now going to not just consider what's in my own little eyes in front of me. Yes, I deal with MEES, but if I don't know what's happening in PLM, there's no way I can ever translate what actually is going to happen. If I'm not talking to maintenance, there's no way that I can understand how we, you know, both how are we going to maintain this equipment because I, you know, if I'm a a manufacturing engineer and I'm going to make this just goofball process that nobody can understand or work with, that that's not very helpful. So, you know, it does start from the I have to think broader than just my own little view of the world. Yes, it does. That takes organizational discipline and that's that's hard.

Speaker

Well, there already are there already is individuals that should think above the silo level. That's a CIO, the VP of data governance. If you have those humans in your organization, they should be able or CRO, chief revenue officer, right? They should be able to go, everybody get together. I'm sick of this crap.

Speaker

I want you to talk and I want you there with I know you're

Speaker

right. Yeah,

Speaker

that's the way you got to do it. You can't just say I'm the CIO and I guess [clears throat] since nothing's broke, I'm okay floating out in the atmosphere.

Speaker

Still the the organization is not big enough.

Speaker

True. Because you got for your world, you've got all those independent OEM or the manufact

Speaker

the organization's not big enough. Do you mean like in compared to Boeing that can kind of run this like godlike system versus like the average manufacturer that's 200 people? Boeing Boeing was not big enough to control the 737 Max

Speaker

because it got separated out from the manufacturing and the actual

Speaker

because Boeing sells to airlines and then they assume airlines are going to do the service and they also assume that airlines are going to train their pilots properly.

Speaker

Exactly.

Speaker

Go ahead. You know,

Speaker

no, I was going to say I think there's a bit of background noise somewhere. Is that um I think that the there's a bunch of lines we're crossing. There's a a problem where we have I we talked about this last time like the engineers want to own their data and manufacture wants to own their data and the service guys and so there's an ownership problem because you know it's my ebomb and then I'm going to throw it over the fence and hopefully that someone catches it even though my PLM system which is owned by me the ebomb guy can do inbombs but screw that we don't you know the manufacturing guys don't trust it and which hits the second problem which is user experience and the pms are designed for engineers and they can't. It's unusable from anyone outside of engineering, right? MEES, you got your little worker screens. It's a little bit easier to understand. They're sitting on the thing next to you when you're working. That's easy. And then ERP, another catastrophe. If it's sorry, you work, but you know, they're not known for a good user experience. And then and then we go back to service and once again you've got maintain X or or service stuff like that where you've got a relatively easy user interface where I can put stuff in and yet these are four different systems that are completely dissociated from each other. I mean maybe Gus you're going to say oh we're going to fix all that with the new uh thing but uh we've been saying that for years that's what PTC said they were going to do and they bought service max and thing works and what did they do? They sold thing works. So then what do you do? There's no mees in the middle, right? Dot said we're going to solve it because we have a po and so we can do m and nobody uses it. It doesn't work. You know, you're still using Excel at the end of the day. So that's why David and I discussion like we're we're trying to take the approach of like having a data model underneath that just has like all these components. So it's like here's a product and then there's an Ebomb, an Mbomb, the CAD bomb, there's every single bomb that you can create permutations under, but it's just a data model. So whatever system of engagement you come into, whether that be the CMMS or the PLM or the MEES or the CAD interface, it all just pulls granular data from one data model. So that that's approach auditing and I I kind of like it.

Speaker

Isn't that what PTC announced last week with Orbit and Jetream though? PTC that is asset basically orbit was the asset life cycle manager which is supposed to be multi-discipline and then jetream was sort of the digital thread thing between them. They're all anna you know pre-announced coming later kind of thing but the talk from them and I'm I'm supposed to have an interview actually with uh Steve Dertine and and and the new head of product management about it uh is this sort of uh digital thread thing. So I don't know,

Speaker

you know, let me let me just point one thing out. When FlexPLM came out into the world, it was built on PDM link. So PDM link was the shared data model and you could jet off and do the fan above my head.

Speaker

At the same time, you have a different interface for merch or people that wanted to see it graphically, right? that both using the exact same bill of material because you could do consumer products and retail on the same system. Now, there was nothing that kept Service Max from going into that same world except they were already engaged in their own system. And so PTC bought them and they brought all their excuse me, their stuff with them. So it was segregated and separated. what it could have been just go into the same place and put service bomb within that just like Gus is saying

Speaker

you know you could have a unified data model and think of it as you know different UIs that service the you know unique needs of each one of these humans engineers manufacturers service you know

Speaker

and I would argue you come back to the problem that we're talking about each BEu having their budget for their system who the hell's going to pay for that engineering already spent their budget on PLM. So screw those manufacturing guys and

Speaker

unless you got to put a budget costing

Speaker

getting anybody to spend money on supply chain software is almost impossible.

Speaker

You seem to go to it and call it a security issue and then you'll get be budget for it. Well, maybe

Speaker

David

Speaker

May maybe maybe is it more uh when we do the transformation of having true data governance and having a data organization like a co is that where it's supposed to happen is that person's budget supposed to have hey I own the I product memory to take Oleg's term

Speaker

is that where it ends is that the problem is that the budget should be in that data silo go ahead

Speaker

right exactly

Speaker

organization needs an orchestration layer is Is that what you're saying?

Speaker

No. The life cycle does

Speaker

well organizational layer

Speaker

realize that AI is going to become a shared budget.

Speaker

AI will become a shared budget. A unique line item at the CXX level and everyone will be otherwise it's kind of useless will be a benefactor of its expense. That's what's going to happen. AI is going to become the blend.

Speaker

Benefactor or a victim? We'll [laughter] see. Depending on how you do it, you could be whoever's in charge of this needs to be compassionate to the needs of the organizational.

Speaker

You have to be compassionate

Speaker

and putting organizational change management into place.

Speaker

To make the people and the systems code,

Speaker

there's the people

Speaker

so Gus mentioned something pretty that I want to get back to. Apologies. I always end up coming in two three conversations after the fact. But it's around that data model and I'm a big believer in this master data model is a concept I promote of it's something that exists outside any product or system or solution or infrastructure that this is our data model and then those systems that want to you know whatever its functionality is my PLM my CMS my MEES the you know fill in all your TLAs there needs to be a common way that we expose that that information and there's a common way that we exchange that information so we're all looking at the same thing, but it doesn't become that model. You know what?

Speaker

David, that's where that's where the product memory comes in, right? Because vendors will never disappear. There will always be vendors.

Speaker

Vendors will go ahead. You're smiling over there. Like

Speaker

they'll reinforce why we have IFC for architecture. Like we have one common way of exchanging geometric data between all these proprietary solutions. when do we get that for a product instead of just for a ge geometric model

Speaker

but that that's the point each vendor is going to try to contain and own as much of the organization as they can it's really a vendor influence to or uh responsibility level vendors are going to be in CMM or SCM or MEES or you know whatever their threeletter acronym or four-letter acronym means product memory should must has to draw from each of those silos and normalize harmonize that data so AI can rest at top it. That's what has to happen because you're never going to get rid of the the little rabbit race of all of these vendors reinforcing organizational confinement.

Speaker

Sophina, that was question number one. I see five more questions [laughter] here.

Speaker

I What are you doing on time management, bro?

Speaker

I propose that we use the closing question. Everybody gets to sound off on it. The closing question we had was and I I think everybody will have something interesting to say which is and thank you Oleg by the way. It was Oleg that put together this uh what belief about in Mbomb or manufacturing data management does the industry that that's widely accepted today will be proven completely wrong within five years

Speaker

and Oleg you asked a question so you get to answer it first and then we can go around the horn. So what so what is that commonly accepted as gospel thing about the inbomb or manufacturing data that is definitely not going to have in five years is absolutely not the truth anymore go ahead

Speaker

five years holy jeez

Speaker

five years I know it's hard to even think 18 months at this point you wrote the question you got your you get the first response

Speaker

yes I I I will give a response and uh I I think I think what we're going to see is that uh that people will not disagree how to manage data in different departments and the mistakes that they will have as a result of the misalignment of data and this is happens all the time. So but people will not agree how to manage data because they have different departments and they have different opinion about how to do and this is we come to the second thing the people will never organizations will never agree and people will never agree but we need to put something for them to work and this is where a systems will come so and if SAP wins in one organization they can manage everything like Mr. Fischer said in some other organizations it will not happens. The biggest from our experience in open bond with customers the biggest mistake that we see is unit of measures. I mean a very stupid simple example someone is ordering different unit of measures

Speaker

somehat in in in many different like it's a simple and stupid mistakes who try to take pull your bomb put it in any uh language model and ask to analyze the unit of measure it will tell you it using different unit of measures in the same bomb from different metrics imperial whatsoever it's a horrible mistakes that are happening so again misalignment of data is the most visible and impactful mistake. You know, someone is ordering boxes and in fact uh someone planning for boxes and ordering pallets. Someone planning for each units and then ordering some boxes. I mean I have a real example of people that I cannot mention their names now that ordered pieces and get two pallets or something. Uh I think the best example is in um in uh um ah no I'm I lost uh in

Speaker

this is a sourcing problem by the way.

Speaker

Yes. [laughter] And this is

Speaker

spinal tap the the the the and this is the sourcing that that's why what I'm saying mistakes are coming from the place that people will not people will disagree and organizations will run multiple systems. This is goes to the go to your comment. You cannot put everything in the single system. You will end up with 3D experience. No one wants this for the moment. I think unless you buy SAP

Speaker

I mean unless you buy SAP. So again if you agree an organization on the single piece of software God bless you. I mean you can do it. This is fine. But the normal like in most of organization that I've seen eventually people come into different pieces of software. So it will be very interesting to see. It will be very interesting to see in Simmons and PTC now because I think they are following some some different strategies. But my point is and this is where I think Brian you you did a great job explaining product memory better than I did. But uh I mean you need to have something that connects between those disagreements

Speaker

in order to in order to reason and in order to make decisions. That's it. Thank you.

Speaker

Okay Gus, your turn. Okay. Uh is something accepted today? Uh it I I'll I'll take more of a stance uh related to a lot of the companies I work with where uh they do discrete manufacturing and a lot of the product definition starts with mechanical CAD like 90% of it comes from there. Um as far as like the the structure, you know, you got to throw in all the supply chain and sourcing and all that. Um and then we have to, you know, make it manufacturable. Um, and so, uh, something commonly accepted is there's only two ways this is going to go down. Either we're going to optimize the product for CAD design and updates, and then it's going to be really hard to add all of that definition to make, you know, an MBOM if we ever got to an agreeance on what the definition is so that we can get it into an ERP and someone's going to have to just eat that labor. The flip side is okay, we're going to make it really easy to get into the ERP and now we have to optimize our CAD for the manufacturable structure which is actually really hard to then update when I want to change one little part of that geometric definition and it just blows up my model. That's the acceptance today is that it's only one way or the other. I think in five years, you know, probably just like a year or 18 months, uh it is going to be let's all point to one data model. all point to one place where we can then have this kind of transformation layer so that I can get my mbomb out of this without having to force some sort of uh you know structure or way of working that isn't very good for the the folks designing it or the flip where I'm going to optimize for my upstream design and updating and then downstream they're just going to have to suffer with whatever updates and transformations but rather in the future it'll get really easy to do these transformation activities to be able to have that thread throughout the entire product and that bill of material definition there's actually glimpses of it today I see like in the last month I've seen four different AI coded applications to edit or create a bill of material you know it doesn't matter what kind of bill of material but they all do that they all add some sort of UX to be able to edit it or update it or view it but at the end of the day they're all pointing to a data model underneath no one cares about a data model They care about the context in which they interact with that bomb. And so I think that future state is they're all going to point to one place for that kind of system of record, the data model, but everyone can go and have a UX that works really well for them and then no one's having to just like eat all this work to be able to transform or shove it into a system, but rather hopefully things can gracefully flow from one to the next. To David's point, I really liked what he was saying. You have to agree on how you're transmitting that data, how you're going to structure it within your organization so that you can then pass it along from system to system or person to person.

Speaker

David, why don't you pick it up then because we're running out.

Speaker

Yeah. So, I actually have two Yeah, I have two answers to the question. One is right now the whole approach that everybody's taking is that we're going to use these abstracted models to exchange data between systems. And that's the conventional wisdom. But what I'm seeing the market do is is just the opposite of go back to the way we always did it. Instead of making these um abstracted connections, we're going to go right back to pointtooint because I've now seen so many projects of I'm just going to take some new piece of technology and then I'm going to build it in one big behemoth application. So I I think in terms of what's going to change is that we're just going to go right back to where we were. What I would like to see change is that we get away from creating these bespoke data models and these bespoke databases and knowledge graphs and start to create what I you know one comment or one concept that I was going to bring up earlier is this onlogical representation of my manufacturing process. Maybe we can let make that a little bit larger of now anytime I want to know anything about the data that's there whether it's my as design as built service anything that I now not only know where to go get that data in a common system I know how to interrogate it because I now have a common way it's you know what I talk about in a knowledge graph if I'm going to build out a um a a family tree you already understand the concept of cousin and and brother and sibling and etc. The same type of relationships need to exist within manufacturing data. So there there's my what I think's going to happen is is not the direction we think we're going and and what I'd like to have happen is let's really be deliberate about what we're doing in the future.

Speaker

Awesome. Brian quickly.

Speaker

Yeah. So I'll try to do it in less than eight minutes. though the mbomb today and what what really kind of screws up the answer no matter who gives it is that new technology doesn't mean it's adopted. So people will continue to use old systems because they either don't have the funding or don't think it's worth it or blah blah blah. So if you look at the future there will be and to David's point the ontology of all data for all systems and to Gus's point different UIs getting at the data based on the profile of role of the human. So future state is kind of like the jetream PTC or seammens whatever tool they have where it's a layer on top

Speaker

intelligence center.

Speaker

Yeah. And you go in, you say, "Hey, I'm this role." He goes, "Oh, here, Mr. Johnson, let me show you what you need to see." Which is totally different than Mr. Robinson, which is totally different than than Miss Long Street. I was going to do Longwell, but you've already used that, so I can't do it. So, coming into this shared ontology is the human with the role, and it validates who they are and changes what they see based on who they are. That's where in five years because five years I mean son of a

Speaker

long time

Speaker

son of a gun that's a long time in technology years right so who's on the front line is going to say screw all that crap all the data is here just shut up and log in thank you very much do your stuff we're taking care of all of this stuff and underneath it is running AI to say whoops we got to tell that person something different so AI is going to become much more mixed it's going to be shared ontology and it'll be variances of the view of how you see what you're going to do, but uh and you'll feel like you're doing it uniquely, but you're not. It's all going into the same data model.

Speaker

Patrick,

Speaker

you know, the five years thing um to um to Brian's point, so um [clears throat] technology moves fast, but adoption is glacial.

Speaker

Yeah. So I don't think anything is going to change until suddenly everything changes and I don't know what the trigger will be although it'll be it'll be something co or bigger. Um,

Speaker

so I know for you guys that are in Europe, it's we're 36 37 where I am am in in Detroit. It could be something like that. There'll be some sort of shift and I think where we're going is a digital thread which continues throughout the life cycle.

Speaker

And so the ebomb mbomb thing really does just become views into the into the digital thread.

Speaker

Awesome.

Speaker

And I'll stop with that. Oh. Oh. Uh, but I want to add one more thing. Oh, like I want to give a shout out to the post that you had today on uh Ebombs and Mbombs as kind of a leadin to this conversation and this is the highest praise I can give to anything. I just added you to my syllabus. So my students recovery industry bro

Speaker

I've been looking for I mean for a great conversation about Ebomb and Menbomb and [snorts] you really brought some good stuff in and the stuff that Yard Fisher brought in and then I have some stuff I haven't published but I will publish soon. So anyway, thank you very much for your your your pose today.

Speaker

Thank you.

Speaker

So bring us on Christine.

Speaker

I honestly I I think we're all saying the same things but we're using different words. As long as a bill of materials means a list of parts, which is a lot of the way that people look at it. A bill of materials is not a list of parts. Um, we need more it is a part of what it is is the product definition and people in different organizations have different needs for their view into product. So hopefully systems are going to um are going to see that. In terms of projections, I'm seeing consolidation between PLM and ERP. M

Speaker

I I am really seeing that that PLM is going to have to work with modern ERP systems because that's where sourcing and supply chain

Speaker

lives and that you can't we have cut them out of the conversation for far too long.

Speaker

Well, we'll see what disruptive uh companies come up between now and then because I'm not sure but we'll see what happens. It's going to be an interesting couple. Michael.

Speaker

Michael, do you think we actually came to some form of conclusion?

Speaker

No. [laughter]

Speaker

Here we come.

Speaker

Yeah, we might have to. Well, you know what? Honestly, I think we we need on here too to defend his point because uh he was in class. Maybe we can find a time or a day where he's on a class. That would be good. Um

Speaker

we have all people here and no ERP people.

Speaker

No, yes, we have David. We have David. That's right.

Speaker

Kind of ERP people will not trust him and

Speaker

unfortunately I speak PLM.

Speaker

Unfortunately, uh we didn't even get to David's uh the discussion he and I had online which is why can't PLM natively speak 95 so that that discussion becomes pretty much more smooth and less translation required kind of thing. But we'll get to that next time. So I guess perhaps we will have a a part three. You want to might want to answer that. Um

Speaker

I [laughter] got it. calling. [laughter]

Speaker

So, thanks everybody. Uh, thank you to the audience. Thanks to our sponsor Aerys for this podcast and we will be back um after the summer break uh with another one. I don't know if it'll be in Bomb 3 or we'll come up with something. Don't worry, it'll be something entertaining. It'll probably be some of the same uh usual suspects. It probably be other new usual suspects. So, we'll see. Um, thanks everybody. Cheers. All right. Thanks, Pino.