top of page
Image by Jonathan Velasquez

Guest Podcast

Engineering Change Control Best Practices | Microsoft Dynamics 365

What comes to mind when you think of engineering change control?

Well, if you are a small shop with a few changes per month (or relatively straightforward products), then you might not see as many change orders.

See Below for the full transcription of this episode!

Sam Gupta  (00:24):
Hello everyone. Welcome to today's show. And if you're joining for the first time, this is part of our digital transformation series for which we meet every Thursday at 5:30 PM Eastern. We pick one topic related to digital transformation, and we always have an expert panel here. Uh, for today, we are going to be discussing, um, a very, very, very deep topic. It's called engineering change control. It could get really complex, somebody wants to mute, I guess. Uh, it could get really complex overall with respect to the requirements, uh, how the data is going to flow from engineering to your E R P. And if you don't have your engineering data in control, obviously you are going to see a lot of downstream issues. On that note, we are going to start with everybody's intros first, and then we, and then we are gonna do the deep dive into the topic. Um, so I'll start with my intro. If you don't know me, Sam Gupta, principal at Elevate iq. Elevate IQ is the independent E r P and digital transformation consulting firm. On that note, I am going to move to Chuck for his intro.

Chuck Coxhead (01:32):
Hey, hey, my name's Chuck Coxhead. I started my career running an engineering design department many years ago and have grown from there. I love this topic. 35 year manufacturing professional. Look forward to it.

Sam Gupta  (01:43):
Awesome. Thank you so much for being here, Chuck. Uh, Netra, can I ask you to introduce yourself next?

Nriav Shah (01:49):
Yeah, absolutely. Nasha. I'm CEO E O of Adera, C r p. We're a premier Acumatica partner. Um, like Chuck in my career, I've dealt a lot in the manufacturing sector, implemented e r P software, and there is a time where I was selling, uh, engineering change management solutions out there for e r P solutions. So have a lot of stories, have a lot of good insight to share, ultimately, right. Manufacturing, just more than putting things together is the ability to go ahead and see the principles, create something outta nothing, right, and be having a perfect product out the door.

Sam Gupta  (02:18):
Awesome. Thank you so much for being here. Now, uh, Paul, can I ask you to introduce yourself next?

Paul Vragel (02:23):
Sure. Quickly, we're, uh, process and operations consultants. Uh, our focus is to help manufacturers take the business from there to there in that much time. Doesn't come, come across visual anyway, process and execution, operating and technology implementation, uh, for manufacturers.

Sam Gupta  (02:43):
Awesome. Thank you so much for being here, Paul. Um, so if you're in the audience and joining for the first time, make sure you guys post your questions and comments. We typically try to cover them during the show. Uh, if we run out of time, we'll make sure that you guys are going to receive your answers. On that note, I am going to start with the first question with, um, Chuck and Chuck. This is going to be the overarching view of what is engineering change control. Uh, if you could walk us through the process. Okay. How the process starts from the beginning, how that flows through the E R P and what are different terms. And I know we were talking about different ECS in the pre-show, so if you could touch on those and then we'll probably, uh, you know, ask other people, uh, to touch on those as well. So just provide the context overall in terms of the engineering change control process.

Chuck Coxhead (03:38):
Absolutely. So, you know, anybody that thinks that their designs are not going to change, um, they're silly. The engineering, uh, change control process is very simple. It's really important to understand that when a design changes, in theory, it's as if it's a different skew. The comparison for engineering design is form fit and function. Okay? Yeah. Even if there is a design control and you just change a revision, but the form fit and function do not change. It needs consideration. It needs evaluation as whether or not that is a unique pro uh, product that is suitable to carry forth into your manufacturing process or all the way to your customer. The change control process is an orderly process where someone identifies a need for a change, makes a formal request, it's reviewed. Okay? That way we may understand that all of the different business processes are covered, okay? And then once we do that, we can go forward with executing the design change documents and then carry that forward into, for instance, manufacturing because it can carry all the way through to the final product and to the customer and even sales documentation. So it's a very orderly process of discovery, identification of issues, execution and notification and follow through.

Sam Gupta  (04:56):
Okay. Very interesting insights there. And I especially like your bit about form fit and, uh, function. And you also mentioned that you know what, the change is always going to be their respect of the product or the customer or the industry that you might be working with. So you need to probably appreciate that change mm-hmm. <affirmative>. But, you know, when I think of the form fit and function, it could mean a lot of different things. I don't think most people really understand. Uh, you know, how to sort of distinguish between your, if you think about matrix inventory in your apparel industry, okay? Mm-hmm. <affirmative>, it could be very different here. When you look at the form quite and function, and I'm pretty sure this is probably coming from very deep engineering organizations and in that probably they might use the term form fit and function. So if you were to sort of paint the colors around that, you know, how to sort of distinguish routine and how to go for different skews when you are thinking about form fit and function provides a more commonly data.

Chuck Coxhead (05:58):
Absolutely. So yes, it does come from an understanding and it, and it, it arises from a mechanical design, electrical design, um, you know, form is the product form physically changes. Yep. I can illustrate through exaggeration. Okay. I can put, you know, a third ear cup on my headphones that would change the form. Okay. The fit is that I could make them much smaller and they wouldn't fit on this big bald head. Okay. And the function is that they might send the sound outward instead of inward toward my ears. Yeah. Okay. Form fit and function. And so, you know, all these things clearly affect whether you know, all, all, you know, the size. Okay. It'll affect piece parts that go into that. Okay. So you have a supply chain concern fit, okay? That can clearly, you know, go into, does does the part feed a ma another higher level assembly and manufacturing also, does it function the same or fit the same from the customer's perspective? Okay. So, and that really does go beyond mechanical design. It does go beyond electrical design. It even can't go all the way to architecture design. You could extend those same concepts.

Sam Gupta  (07:08):
Okay. Love your insights. Thank you so much Chuck for that. And, uh, before I move to nara, Chris, do you wanna introduce yourself? Um, I know we missed that. Sure.

Chris Gheradini (07:16):
Chris Gar, owner and c e o of turnkey technologies. We're a to 28 year Microsoft partner, so I, I do a lot of manufacturing deal with a lot of aerospace defense. So it's a fun topic and sorry I dropped the internet there for a bit, but thanks. Send I'm back.

Sam Gupta  (07:28):
No problem. Thank you so much for being here, Chuck. So Netra, uh, you know, uh, we are going to be building over what Chuck just mentioned in defining the form fit and function. So let's say if you were to translate this insight more in terms of the E R P, how different skews are going to be for different form function, how you are going to be structuring the skews in different industries. Maybe if you can provide some sort of examples from different industries of how to think about designing these queues, designing the revisions, uh, about form print and function. That'll be super.

Nriav Shah (08:03):
Yeah, yeah, absolutely. Right? And, and I don't think that's, uh, you know, per se a decision, maybe even what a E R P user would say, right? That has to go as a change request potentially. Yeah. So it goes, there's a notification from the E R P, right? Depending on where the request is coming from. Could be not, not only, not only only manufacturing, you're talking about someone doing physical inventory, you're talking about someone receiving in purchase orders, you're talking about someone that receives in, you know, even a, uh, return order essentially, right? That comes in. There should be a way to initiate a request for engineering change from all these different document types, right? That request should go through an approval process. You don't wanna inundate your engineering team, the application engineers to all day long. Just go ahead and start, uh, you know, changing all these designs when they haven't gone through a formal review process.
Yeah, we, we wanna take the request cuz the people closest to the floor have a good understanding of how the product is being built, right? What, what limitations does it co is, uh, maybe machine have, you can't get to a specific angle. What limitation does, you know, something have where that's not really relayed back up there to the engineering team, right? So you could take that understanding how to take the lower level request through an engineering department, right? A request gets approved and then that gets sent with the formal request number back to as an XML back to their CAT system, right? The cat system takes it. Now that goes into a queue to get handed off to a proper application engineer. They make the proper changes. Right? Now you're talking about the engineering change order. The change order goes into that application engineer's hand, they make the, they make the adjustments that need to make, they make the revisions, build material adjustments.
They send that back as an engineering change notice, right? That notice now has to be propagated through the system. So that goes into a staging system and possibly one more even set of approval to make sure, because you wanted maybe use up some old components, uh, because a bomb has changed, okay? Or you wanna obsolete a component, but you know that you already have production orders on the floor. You can't make a media changes, right? To an open production order out there. You don't wanna do that, right? Uh, do a pull cuz that's gonna mess up capacity, that's gonna mess up, you know, all the other reports out there. Um, how you're planning the, the material orders. So you wanna carefully introduce that item maybe as a new revision right on top of the item that's being about manufactured. So it's a new bill of material potentially for the same amount that's being, being, uh, uh, manufactured now.
And the, and the top level item has a new revision number revision A, revision B, revision C, right? So now you have a formal process that you are allowing anybody in the organization, obviously with some permissions to create a request cuz they see a concern, you wanna take their ideas, right? You see a concern. Now let ha let's, let's have a conversation around, uh, which ideas do we wanna move forward with, right? Prioritize that, send the high priority ones to application engineers to work on via xml, right? You don't wanna be handling paper, right? You wanna try to move this stuff back and forth as quickly as you can be between multiple systems. Now you bring that back as an engineering change order because now you're ready to commit. Either there's new items to being generated because this engineering change order or there's changes to the bill of material, there's inventory considerations, and then you gotta commit those changes, right? So you make sure that you are staying ahead of the times taking those requests on hand and making those changes on the manufacturing floor. It's a full process, but there's a lot of communication here if executed properly, right through the e r p system planned out properly, right? It could be a valuable tool that could save you money at the end of the day and minimize your scrap.

Sam Gupta  (11:34):
Okay? Very interesting. And, and you have some very, very, very interesting layers there and I wanna make sure that listeners are able to follow along. So you mentioned a couple of terms, okay? And I don't know how many people are really going to be clear about these terms, you know, what is going to be a context and when to use what sometimes, you know, they are probably gonna be all over the place in terms of these terms. So you mentioned the e c, the change order, that is the first one. And then you have the revision, and then you have the engineering change notice. So maybe provide some more colors and maybe provide the examples of each of those, you know, who is going to be the audience, what is going to be decomposition when you are looking at, let's say engineer change order, who initiates it? Uh, so provide some more commentary

Nriav Shah (12:17):
There. AB absolutely. And, and all those terms go down to essentially looking at the process and the traceability, right? The audit trail of this engineering change order. So now we're talking about people, right? We're talking about the personas that are using these different type of engineering change, um, uh, processes out there. So you got the engineering change request. It could be the foreman out there on the manufacturing floor, right? It could be the receiving clerk, it could be the shipping clerk, it could be somebody that has the authority to say, Hey, there is a defect in this product and we've noticed it and we see it. I need to put a request in. So our engineering team, our team that's responsible to, you know, doing the product designs in the system right? Gets notice of this particular issue. So that's a request that comes in.
The request could be very loose in terms of associating a picture, you know, putting some comments on angles and dimensions on what needs to be updated and changed. Um, that request goes into a queue. Now you have a manager, right? And your engineering department that interfaces maybe with, with the CAD system and the e r P system. But within the E R P system, they're looking at all these requests coming in and they're prioritizing it, right? Going through an approval process, essentially, which ones do we want to execute this week, next week, next month? Which ones do we don't wanna do all together, but we wanna archive it, right? Because you wanna create that traceability essentially. Now you have that request, you have that manager going through the process, sending it to the, to the, to the, to the CAD system. The CAD system user.
Now you have a strict maybe engineering, right? Um, application engineer that's getting this, queuing all this up. They're not in the E R P, right? All they're charged to do is look at the requests that are coming in, make the proper changes. Now, engineering has it own workflow when it, when you talk about SolidWorks, right? We're not getting into that right now, but talk about SolidWorks and how, how that keyhole works and how that approval process works. Now, let's assume now, now that that particular drawing is now ready to be released back into the E R P, right now, that becomes back into the R rp, but it becomes a change notice that's linked back to the change request. So you have that auditability, you have that traceability of, you know, how it originated, who worked on it, when did it come back in? And ultimately what records were updated in the system, which items were impacted, right?
When was the new revision created? What, what production orders did this impact? What purchase orders did the new items impact, right? Do we have to go back and tell vendors, uh, of a new revision for our product, maybe send a new drawing to the vendor, potentially, right? So those are all the different stages and or kind of Norman cultures or, you know, kind of additional vocabulary, the engineering change process that will help, you know, get the proper people in place to audit and also create that traceability to, uh, provide the checks and balances that the engineering team, the application I got pulling their hair out with all 50 different requests because one person's, you know, told 'em 50 different things to do and one day, but it's kind of going through a formal process that's being checked off and only the right, right? Uh, changes are being instituted because they impact customer orders. Maybe they impact, you know, um, purchase orders, um, high dollar amount, right? Uh, it impacts a specific, uh, project that's being, you know, um, you know, kind of taken off the ground. So those are all the different type type of scenarios you wanna take into consideration.

Sam Gupta  (15:29):
Okay. Amazing insights there. Thank you so much Nara for that. So Paul, I am coming to you and, um, you know, either you wanna touch, uh, on any of the comments that have been offered so far, but I don't want to overwhelm you with my questions. You have, uh, a story that you wanted to share as well as the ideas of why, why don't you go ahead and share that story?

Paul Vragel (15:48):
So it's, it, it, it touches on all of the things that have been said, but really starts. So the, the case that, uh, that I wanna talk about here is, is actually a really complex aero aerospace defense product that has electronics and, and, uh, mechanical hydraulics software. Uh, it's basically a camera that you've reconnaissance camera you bolt onto, onto an F 16 go flying around. And that raised a whole set of issues that you need to think about in terms of what is it that you actually need to control. So, uh, the's talked, I mean, very well about the mechanics of how that control is going to get executed. Uh, the, the expansion I'd like to make is you have to think about first, especially in these really complex environments, what is it that you need to change? And how do you manage through changes that are occurring?
Not in one function, but multiple functions. It's not just a change on a part, it's multiple areas where interrelated changes. And one of the things, so in this particular instance, uh, we started with that firm with a, uh, uh, a, an engineering project management system, uh, that required if you wanted to see what was happening, you had to know who worked on that project, what computer they used, and make sure that still had the right hard drive in it. So <laugh>, Chuck, you're laughing cuz you've been there <laugh>, now we've all been there. So, uh, uh, so we first had to rethink what is the process here? And then in those complicated situations, uh, you, you're, you have, uh, RFPs and design proposal acceptance and, and you go all the way through stages. And, uh, one of the important concepts as part of that is baselines at various points, what's, what's the baseline for the rf, for the, uh, R F P, how did we match the requirements in the R F P to what we plan to do there?
And what does that baseline look like? And then there's negotiation back and forth with the customer. And you, you, you're creating a succession of baselines that actually goes all the way out into, since this is, this is equipment that's out on the, uh, out in, uh, out in service. Uh, and, and they had in fact a unique issue that their equipment will go out and it'll be out there for 40 years. So you really need to think through what your long-term data and retention strategy is and how you're gonna manage that through all of these changes which are occurring in the field. And, and now with additive, by the way, additive manufacturing, uh, you don't have the control of, we had the part and we shipped it to them. They can make whatever part they want. Adds another dimension to, uh, engineering changes the provision of parts and the, and the related, uh, the ready related controls that you need to be able to know, uh, what, what is the product? What did, how is it designed? How is, what was the production, what was the as built configuration? What's the as serviced configuration in life? And then think through that and how all of those various parties are going to play together, if you will, in and, and I will say obviously in a, in some software, because if you try to do this manually, you're <laugh> Houston, we got a problem, <laugh>.
So it is, it is. And, and, and having said that, that's, there's a very complex system. And I would say the, the important part of that is really think through what you need. What do you really, what do you really need in your business to, to establish the right level of controls, whether that be design, product, service, um, and then, then look at how you can effectively automate and, uh, integrate all those pieces.

Sam Gupta  (21:05):
Yeah, so some very interesting insights there, by the way. Yeah, Houston is not the only one that is gonna have a problem. I think we are gonna have problems everywhere if they are not using the system. So good. Um, <laugh> insight there, uh, I can touch on so many different things in your insight to be on it, but I would like to go back to your story and if you could touch a little bit more on, um, the traceability aspects of which computers were used is what you said, and then you had to maintain, uh, the, the hard drive usage as well. So how did you sort of ensure that compliance and was this part of your, um, e c N process to be able to do that? And I don't know how you did it. Do you wanna touch some more, maybe provide the industry and the product insights as well?

Paul Vragel (21:51):
Yeah, so the, so the first step was, was to, uh, completely revamp their, uh, engineering project management system, okay.
So that we, we essentially created instead of documents everywhere and go and go and search for every product, we essentially created a front end, uh, let's okay the a document. But that was the front end to the project that led you to all of the different pieces that were part of that project. So it was kind of an, it sat up here and pointed you to all of the places that, uh, you wanted to look at. And what we also did is, uh, in 30 days, we moved 35,000 documents into a document repository with structured, uh, with, with a structured, uh, directories for projects so that you, you no longer had to know all of those pieces. Now we had all of that in a document repository and, and now you could know, okay, this is, this is where everything is, and now you have a basis to take that next technology step to, uh, automate some of the, the, uh, back and forth. And in fact, the, the repository provided a lot of those capabilities, approval paths and, and uh, and things like that. So that's how we got from chaos to a manageable system that, uh, that that worked worked for them.

Sam Gupta  (23:54):
Okay, amazing insight there. Thank you so much Paul for that. So Chris, uh, you know, um, even if you are going last, I think you are gonna show us today, you know how to steal the show, right? Uh, <laugh>, but then <laugh>, it's alright. But then, you know, you are also going to be talking about different, uh, systems and the integration. And the reason why I am really interested in that is because when we we're discussing this in the pre-show, we're discussing a lot of different ecs and what those ECS are going to be. They are going to be part of your workflow, they are going to have a lot of different statuses. And when you are gonna have multiple systems in your architecture, good luck with that when you are gonna have that complex workflow. So maybe talk about, you know, the challenges that you're gonna get from different system perspective and the whole, um, you know, change control process.

Chris Gheradini (24:42):
Absolutely. And I mean, just from a g overall, you hear all the buzzwords. E ecm, E C, C, E, C R E, cn, E C O E C V E, ccp, E C I, yeah, there's a lot of 'em. Where are all those ecs? Everything's engineering change. But if you think about the first one, engineering, change management. And if you think about the governance, overarching the process, okay, processes, you know, how, how, what is engineering, change management, em, body, it's a lot in there. The first thing I'll say is, is not all systems have an EC m an engineering change management component, and not all systems have it to the degree that's needed to minimize manual work. So one of the things is we, as we discussed this, which you'll find, and in the less capable systems, there's a lot of manual process. And depending on your industry and your level of complexity in your manufacturing, that can, that can define the difference between profitability and competitive advantage, quite, quite frankly.
So as you think about, you know, business process, and I think Nirav had a great point, is, hey, how do we, how do we create an e ecm? How do we get a or an ecr an engineering change request, right? How does this thing start? Starts with a request. Hey, we need to make a change. And I think as you look at sophistication of systems, and I have, I have one group that does tons of field service and they're a manufacturer. And what needs to happen is field service where they're doing repairs and they're doing remediation, they say, Hey, we need to get that to engineering. So they fix this problem, so we're not fixing it every time. So they're treating the symptoms not the, cause. There's a perfect example of having a, a service or organization's out there repairing equipment to be able to surface, you know, in their tracking what was the initial diagnosis, what was the final diagnosis, what's the defect?
Defect? And to surface service data, and again, to feed it back into engineering, change management is form of a change request. And hopefully it gets through the process where there's a change proposal, what do we, how do we do this change? And then there's a, you know, then it goes through work phone, it's approved, and once it's a proposal and it's accepted, it's gonna move into a change order where now it's gonna be enacted, right? It's impacting a lot of different things. But so there's one example of how does a complex service system for field service on equipment feed an engineering change request? What else? Quality. Internally, we're doing manufacturing, doing quality. Hey guys, we're failing. We're failing, we're failing whoop feedback loop. And if you didn't know, every engineering engineer has a big block inputs outputs, and there's a loop that goes back and it's feedback.
And so we optimize that stream. So again, as you go through the process, and you know, and, and I deal with a, a lot of aerospace defense contractors and back to complexity, again, if you're simple, maybe fully automated, it doesn't kill you. But if you're aerospace in your complexity, and we're running big solid works and we're running big e r p, and if we don't have the correct level of integration, we have a lot of manual process. And again, where does the, where does the request originate? Let's, let's not worry about it. Maybe it's something, this part, the vendor said, Hey, guess what? New part, a part change is an engineering change. Okay? A new part, a revision on a part from a vendor is a change. And so again, as you incorporate that into the system, request the proposal impact engineering change impact, wow, what's the impact of this?
Wow. How many bill of materials consume this component, right? The impact may be broad. And then, you know, even, even impact. What do we have on order? What do we have in production? What are the states of all that? And if you think about manual process to analyze and aggregate and really come up with an answer or what's the impact? The engineering change impact could be dramatic. Um, and I think as you go back to the systems and the capabilities, we don't create new bombs. We create bomb revisions. Absolutely. We have revisions, revision 1, 2, 3, again, components and components out. And, and again, I think that integration comment that is in the aerospace, I've got a great partner that really built a, a SolidWorks CAD integration specifically for Dynamics 365 F and O, which means it's so invasive. But to that point, whether I change on the, in, on the CAT side or I change on the E R P side, we're not replicating work.
We're moving documents at the speed of light. The documents are always the latest revision no matter where I'm doing my work. But moreover, that propagation identification of open pos that I can go in and update and I can make those changes there. Tracking the pos that are too late production orders, I can impact production orders. It's too late where, hey, you know, what, are they out the door? Are they finished? Is there a point to bring them back, recycle 'em and update them? Versus tracking customers that have rev one? And you know what? We need to get them rev two, it's almost like a vehicle. And you get a recall. That's exactly engineering. Change management is an example in your vehicle, in a recall. It's a process. It goes through all that. And now all of a sudden they're dealing with impact. So again, this this integration capability and you know, I heard an XML file, well, that's not the degree of integration.
Sure, it'll create the bomb and a new bomb. But again, in the more complex worlds, you can't afford to, uh, to not have full automation because, you know, I've, I've walked in where people have, they've got a cat. Oh, we're not gonna integrate 'em, we're not going gonna use a different tool, but the manual overhead, and they don't measure the cost of that. And again, if you're a competitive organization, you really need to rationalize the impact of interchange management manual processes on your organization, because the speed of doing business, right? Time is of the essence. When you, when you guys identify a problem and you're like, okay, how do we track it? But again, process, we gotta run through the process. Engineering approvals, workflow proposals, okay, now we're impacting and enacting the change. There's an EC V that's variance, right? Hey, we thought it would be this.
Wow, that change takes a lot more. So now we're even, does the proposal match? So even variance, what's the impact of this change? So again, a lot surrounding ECM processes, and again, not all systems have it. And to your point, Sam, if I'm using an external system for engineering change management, hmm, we're manually, and again, to build integrations from an engineering change management to talk to your cad, talk to your e r p, talk to your bombs open pos open production orders, you, you get a feel for the complexity. It really does challenge an organization. I think that, you know, documentation, you know, how do we really get a clear view of impact? That's difficult unless you're really, really integrated. So again, by industry, I think you're gonna pick different systems. You're looking for an engineering change management module. Is there quality in there? Is there a service in there where you can get feeders from those on? How do I continue to improve my manufacturing and do less service? I don't wanna be fixing stuff, right? And that's what this is all about, is, uh, so anyway, those are just some general comments, but hopefully that, uh, gets you thinking. And

Paul Vragel (30:56):
Just, just to amplify that a little bit, the, uh, the, the, the cost of not doing that is, is, is enormous. We, we took almost 2 million out of the cost in that, uh, that, that case that I'm, that I mentioned before, documented real live costs that went away and we reduced the engineering. I mean, lack of engineering change process generates engineering change. <laugh>, that's,

Chris Gheradini (31:32):
And these are indirect expenses and a lot of organizations do a terrible job of managing indirect expense. Uh, the guys are already on the payroll. I don't know how much his time is spent fixing stuff, cleaning up stuff, updating stuff. But think about the capacity that you really wish you had because you had a more efficient process to drive growth of the business versus throwing labor at it. People throw labor at it all the time. And you're right, Paul, $2 million, again, if you're a, if you're a hundred million company change is gonna be there. And in the, in the high complex manufacturing space, change is gonna be there. Whether it's form fit, oh, it itchy, let's get the itchy out, right? That's a whole different process, but you can spend a lot of money dealing with that. So, great comment.

Sam Gupta  (32:10):
Okay. Awesome insights, guys. Uh, so Chuck, I'm actually coming back to you. Uh, and um, the things that we wanna discuss is going to be, there are two layers that everybody sort of spoke, and that is gonna be product and service. So I think service, uh, a lot of people touch that, you know what, if service is sort of driving the change request, then we are gonna get that change request, uh, in our system. So that's number one, right? And then everybody's sort of talking about product management, but a lot of organizations, when you think about them, they don't necessarily have a product, okay? And I don't know if there is a fine line between when you are going to formalize your product structure. I know a lot of companies, for example, let's say if you go to any of the sign manufacturing, print manufacturing, they don't even understand what a product is, to be honest, for them, it is going to be in order. And they are sort of trying to start the process. We have had a lot of conversations with them. They're like, okay, you are showing me e r p, you are talking about all this product. What the hell is product? We don't understand that. Okay, <laugh>, so when do you sort of formalize the process of pro uh, you know, product management, because you are engineering, change control process is going to be driven by that. If you don't even have a product, then how are you going to have your control process? So check over to you.

Chuck Coxhead (33:27):
Well, interestingly enough, I mean the, the sign manufacturing that you brought up, there is an opportunity for engineering change control. Yeah. It's, it's not a bill of material in a sense, right? It, it's not a drawing in a sense. But depending on the printing process that they use, they may be using a print plate, okay? And if there's a change to the customer requirement, they might need to change that print plate. Yep. And so an engineering change control process for the print plate is warranted. The print plate is equivalent to a tool. Okay? But I, I love that. Talk about, you know, we don't have the, the product management process. We don't have a product. The, the, the interesting bit to me is that when these, especially smaller, less mature organizations get started, they don't begin with the end in mind. I, all I need to do is build something.
All I need is something once, let me get something out the door and everything will be fine. Okay? And that just assumes that everything's gonna be rosy and is never gonna ever be an issue. When you get to the, you know, if it's something that's serviceable, you know, that was mentioned here, it's like, you know, you feed the, Chris said you feed that back to engineering for design changes, okay? But as Paul mentioned, sometimes you have to do a, an asbill, right? You're, you're documenting something out there that's specific to a customer, okay? That doesn't necessarily come back to the design. These things happen. So the product management process has to happen at the beginning of your design, uh, uh, your design focus. It's, it's like so many things. It's begin with the end in mind. And it doesn't necessarily mean that, you know, everything is a product in a sense, right?
So we're not talking about a lot of engineering change for services. Okay? So everything else, you have a product or you have a service, it could be a house or it could be a widget. Um, so that has to begin from inception. You going back to the, to the SolidWorks and the design, those systems are amazing. They're meant to save a tremendous amount of time, but in a simple implementation, they're designed to, they can really just screw everything up. You change a model, you change a solid model once it flows to all the other documentation, if nobody else knows that that got changed, boom, all of a sudden it doesn't fit anymore. Okay? Or it's purple instead of red. And that's just a big problem. So that kind of control, again, you, you need to begin with the end in mind. Um, how are we gonna, how are we gonna do that? And that is product management and, and engineering control change is just a subset of that. You know, it's, it, it starts with, you know, what is the vision from the customer or the, you know, or what's saleable in a market or serviceable in a market, okay? And works all the way backwards. But if we don't start product data management from day one, we're in trouble. Man.

Paul Vragel (36:15):
There's, there's also a cultural issue there. Uh, I think every, everybody on on the call knows about the, the, the guys who manufacture, who, who do their work off the drawing that they have stapled on the back of their, uh, cork board. And, uh, you can, you can do all the engineering change management you want, but in the end, they're gonna make it according to that drawing they have stapled on the cork board. So there's, there is a cultural issue that needs to be addressed as well, uh, in, in making sure that this, this idea that we we're, we have a controlled system and we need to build according to what we have designed and, and developed, uh, that, that just needs to be part of the culture of the organization as well.

Chuck Coxhead (37:11):
Well, with everything change is easy. If we don't have employees or customers, it's a breeze.

Paul Vragel (37:15):

Sam Gupta  (37:17):
Yep. So very interesting inside sales guys, thank you so much, uh, sun, I'm actually coming to you. And, um, there are some very interesting layers overall in, um, this discussion, especially when Chuck is talking about, uh, you know, disconnecting from your engineering process. I think Paul, uh, just on, on that as well. So if you are not going to have that control, meaning, uh, for example, uh, one of the things that a lot of e r p systems don't have is going to be tracking of the revision number at the product level. So you are going to have the revision number at the bomb level, but if you don't have that, then you are probably gonna have a little problem there. And today, I was discussing with one guy that, you know what they want those revision numbers at the bill level as well, so that you have the complete traceability, but not a lot of e p systems can support that. And then you have the disconnect between your physical and digital process as Paul was, uh, trying to mention. So, you know, they need to be aligned as well. So, uh, Nira over to you. Do you have any thoughts about this one? Yeah,

Nriav Shah (38:19):
Yeah, I mean that's a, that's a scary situation. Um, cuz the component lines could have unique different revision levels, right? Um, the bill of material could have unique revision itself and the item needs to have a different revision. It all has to stay connected. Interconnected. You can't have an item just be a generic item, but now a sudden the bomb keeps changing, right? And they, and, and like, like Chuck going back to Chuck's point form function fit, if it is different, it's really not the same item, it's a different item. You don't want someone picking the different item when they're shipping, right? You don't want someone picking the wrong item when they're gonna go ahead and, and issuing that particular item to the floor, right? To, to work in process. So yeah, I would, I would say, yeah, I think in that type of system, I think run as far as you can the other way, right?
If engineering's important, which, you know, Chuck hit the nail around the head, right? You should keep the end in mind, right? How are you gonna keep your data organized? The last thing you wanna do is confuse the engineers on what type of item they're actually working on, right? Going back to request. If you don't know the, the true revision that item is on what type of request, how is the engineer supposed to know what, what revision to pick up and, and and redo or modify, right? Um, essentially it all comes down to traceability. And what I really like about a formal engineering request process, and I've implemented it so many times over the years, is the ability to see how efficient your engineering team is and how efficient, you know, the products are that you're making on the manufacturing floor. Cuz if you have good reporting, you could have really nice dashboards created, uh, that show you, well we had, you know, 50 high priority engineering change requests that came in.
We had 25 medium priority and we had 10 low priority, right? And then connect that to how many got processed, right? At the end of the day, now you have some real nice analytics or now you can measure how efficient your engineering department is or how efficient your products are and how many requests you're getting essentially on a weekly, on a monthly, on a yearly basis. And how, what type of items are coming through here consistently all the time, right? Is it a is there a vendor that's, that's causing this issue all the time, right? That's not really not listening to you guys. Or is it, is it maybe a specific work center on a floor that's causing this issue, right? Or is it something you put something on a truck and then next thing you know, it's your truck and the way it's packaged in the truck, it just moves around so much, it's just denting the item all over the place.
So you have to keep going back doing engineering change request, right? So having this data all together on a formalized process, right? Sometimes in the e r P system, it's not there out of the box, right? Um, but you wanna be able to think of the end in mind, right? How are we gonna save is engineering is is a huge component of your, of your, uh, process, right? You need to have a clear, uh, and uh, clear responsible kind of, um, process that everyone knows what their, what their responsibilities are to keep costs down, to be effective and, um, you know, ultimately deliver good product to customers.

Sam Gupta  (41:07):
Okay? Yeah. So very interesting points there, and I completely agree with you that you need to keep the end in mind. I, I guess that's what Chuck has been, uh, preaching as well. Uh, now let's go a little specific in terms of, um, you know, the overall correlation between the revision number that we have at the bomb level. And then, you know, some LP systems are gonna support the revision number at the item level as well. What is the correlation between these two? The revision number that we have at the bomb level and the revision number that we have at the item level, the overarching picture, you are trying to find out, okay, which item is where, and that's why you have the revision number at the, the item level. But then, you know, in production, whatever is going to be at the bomb level is probably going to be used. So number one question, why do we have at two places, okay? If you really need at the item level, and if we need at two places, what is the correlation between these two over here? Yeah,

Nriav Shah (42:06):
Yeah, because the bomb could change, right? The, the, the ultimately the form function fit could be exactly the same, but the bill of materials is different. There's something changing in bill of materials. There's no change in form function fit, the item is exactly the same, right? Maybe they're using a new resin, uh, when they're injection molding something, right? Uh, now you have a new bomb number, you don't want them to use the old resin essentially, but it's the same item number. So a revision number on the item doesn't change, right? What may change ultimately is a cost between the item, right? With the new revision, right? Because a resident on the new item is gonna be a little, little more expensive possibly than the resident on the old item. Cost is gonna be different. Now if you're storing this item in two, you know, in two different revisions, you wanna have that visibility, well this item is stored at x cost, this other item with another revision, same item with another revision stored at this, this cost.
So that is really the true kind of what I would say factor around having different bomb numbers, right? With the same maybe item revision essentially, right? Or having different item numbers. Um, and, and, and not having a bomb, right? Not not having a revision. Now here's another, another thought I just, oh, some companies, depending on how many people they have, right? They might just say, we're gonna change always the top level revision, but we're gonna overwrite the default revision all the time on the BA bill of material. So our bill of material is always gonna have the latest and greatest drawing, but our item number that we're producing will have a new revision each time, right? That comes down to maintenance at the end of the day, right? How many people do you have managing the process? What is the value that you're adding into your process, right?
There's a cost benefit. Does the benefit outweigh the cost to maintain those different components at the specific engineering, uh, revision level? Or is there not a lot of value? Cuz you know, you're talking about maybe pennies, dimes, or, you know, maybe dollars, essentially not, not too expensive. So you just wanna go ahead and maintain it at the item level. So it's just not a, a black and white answer here, but whether you go one direction or not, I think you need a part. You need, you need like someone that's experts in E R P to go ahead and give you that analysis, right? To help you understand, you know, what way you wanna ma maintain, manage and set your system up to have the greatest engineering success ultimately, right? Because engineers, a lot of engineers I've, I've, I've, I've dealt with their pure engineers, they don't wanna be in new e p system, they wanna just keep doing engineering. Uh, right now you have to find that fine line, right? Where is this benefit here for them to also manage some of this e R P data?

Sam Gupta  (44:26):
Okay? Thank you so much Nara for those insights. So Paul, uh, you know, I'm coming to you and I'm going to take this discussion one layer deeper, okay? And this is going to be, uh, so far we have discussed the revision number at the item level. We have discussed the revision number at the bomb level as well. And sometimes there could be a confusion, uh, and you know, because of the, the limitations in the e p systems, because they might not support the revision as the production order level. So there are three layers actually, okay. In a lot of different e r P systems, especially if you look at the larger one. So you are gonna have revision number at the item level. You are going to have revision number at the bomb level, and bomb is going to be your recipe, recipe that you are using each time when you are releasing a production order. But there could be changes on the production order itself, that is the change in your job order that could have another revision, okay. That, uh, the e r p systems might have. So now, you know, if you were to talk about the correlation between these three and you know, in which instances which one you are gonna use, and if the er p system does not support the revisions for the production order, how are you going to mitigate that situation? Follow over to you.

Paul Vragel (45:40):
Yeah, <laugh>. So we're, we're taking firearms out of the picture here, right? I, i, again, you need, you need to think about what you actually need. What is the degree of change in your organization, in your products? And if, if you have a high degree of change, you need to design that system specifically with that in mind. So you may have different controls at different levels and all of those have to work to get the right product. Outdoor, uh, again, it comes back to what do you, what do you really need? Think first, what do you really need in your business with the level of change and the velocity and scope of those changes? What makes, what makes the most sense? Some organizations end up with a, they end up with a, a, uh, a design bill of materials and a production bill, bill of materials. Yep. And, and, uh, have controls in place to sort out, sort that out so that the engineering group knows what they're doing. The, the production group knows what they're doing. Not, not a simple one size fits all answer.

Sam Gupta  (47:10):
Okay. Very interesting. And Paul, uh, you know, when we were doing this thing in the pre-show and you had a couple of compliance, uh, things that you wanted to discuss and that you had mentioned in your, in your email as well, do you wanna bring those up? You know, and how they affect the engineering change control? I think that was related to defense and aerospace industry, if I recall correctly, right?

Paul Vragel (47:29):
So one of the things that, uh, in, in this aerospace company, so they, they needed to be, uh, this, this was an 80 year old company, heavily siloed and they needed to get to today, right? And, and today is a particular, uh, there, there are particular department of defense standards for configuration management systems. And we had to def had to look at those systems. We ended up with a six or seven page itemized list of the things that we needed to have, uh, again, in this complex environment, uh, in order to get to those configuration compliant configuration management in that kind of business as well is, uh, <laugh> the level of change that, uh, defense organizations go through is really high customer changes requirements on a regular basis. And then all of those have to flow down to suppliers. If, I mean, if that's, if that's part of the, uh, the change there. So, uh, puts, puts a heavy burden again, on think through first, what do we need in our environment and how can we make sure we're compliant with whatever our internal requirement is and whatever our customer requirement is.

Sam Gupta  (49:21):
Okay. Amazing. Inside there, Paul. And I don't know if you're still talking, I think there's a little delay, uh, in the video as well as audio. So Chris, I am coming over to you and, uh, you know, one of the things I don't think we have touched is going to be a reference designator, and I don't know if that is gonna be part of the control process. Uh, so do you wanna provide a little commentary there overall with respect to that and how that fits in the control process?

Chris Gheradini (49:44):
Yeah, I'm not an expert on that, but reference to designators and electronics manufacturing. So yeah, I've, I've been through there and it, it gets really interesting as you look at the minutiae in the bill of material and some of these little bitty attributes that you need at the component level. And I think one thing I would clarify, even in terms of change, it doesn't have to be a, a component, it could be a process change. So a so an engineering change management could be the way that you actually manufacture or imagine you're finishing apart, you know, the finish isn't good enough, we have to change the way we finish that, or we need a different type of powder code or heat treat or something like that. So it could be a process change as well. But as you get into reference designators, I've most often seen those in the circuits, electronics manufacturing.
But as you look at just the complexities of that, it's a lot to manage. And, and again, you go back to revisions again, where's revision detail kept? And I know you were saying, well, why do I need it at the item lever if I got it at the BA level? Well, you know, there's, there's gotta be some continuity up and, and in a lot of systems, the primitive ones is how do they handle revisions? If it doesn't support it, what would they do? Can I rename an item and then copy it back into the same item number? Okay, well there's the new one and they start archiving Yep. Through a copy process that's primitive. But in the end, if I'm selling these parts out, I gotta know what revision went out with the finished good. And I think that's one of the premises is if I'm managing recalls or I'm managing updates and service to customers, it's imperative that I know what version do they have in the field.
It can't be buried down in the bill of materials. So I think there's some context at the, at the finished good level in terms of what is the version that went out the door and it's, it's probably not part of the sku. Some people do that. Oh, they keep making new items. Well, that's a problem. If you have e-com sites and you're trying to integrate, you don't want that skew to change. So that revision attribute has to be sub, but at the same time, in the bill of material, that revision attribute is part of the key so that I can have multiple instances of the bomb and I can go look at the prior version. The prior version, the prior version. Not all systems do that. A lot of 'em, you archive them, you can only have one archive. So at most you can keep one of the prior revisions.
So again, differentiation between capability. Paul raises a great point. What do you need? You know, what's your industry require, you know? And then we go back to if you're in a controlled industry, what do you need contractually to get ISO to be able to win a contract? Because a lot of times the, the, the requirements to win a contract is you've gotta support the detailed revision history such that, hey, we had a problem, we need to find everything that has this revision, every customer, every place, every place it was consumed. And that's a, that's a big data exercise if you think about that level of complexity. But yeah, I wish I can't talk more on reference designator. Sorry, it was a

Sam Gupta  (52:11):
No, that's actually awesome. I think that's sufficient detail that probably people, uh, need to know. But I'm, I'm going to have just one clarifying question for you. Sure. Uh, you know, overall in terms of layering in some more details there, and that's going to be, let's say if you are working on any sort of lot or serial controlled items and in defense aerospace, you are gonna have that. So number one question is, okay, at what point of time you are going to be assigning which revision number got transferred to your item? Because at the item level, let's say if you're keeping it at the attribute level, then you need to transfer. So does it get assigned when you are gonna be received the inventory? And then finally, okay, uh, you are assigning two things revision as well as a serial number. So is there gonna be any sort of correlation between those two? Chris, any commentary there? Yeah.

Chris Gheradini (52:55):
Yeah, yeah. And, and, and the revision, you know, if I execute a production order with a bill of material that's got revision 13, and again, where does that finish good get consumed that, that attribute is gonna be sub in the detail behind that production order that does get consumed to the item. And at the point where that item comes off the production line, we're attaching a serial number. So again, if I pulled up that serial number and Dred in, I'm gonna get to the item, I'm gonna get to the revision that's attached to that particular serial number and eventually goes out the door on the sales order. So, so we're gonna have continuity. It, it may not be a serial number. Oh, the revision's way up high. It's not gonna be, you see a sku. Oh, there's the serial for that sku. Oh, there's the revision and there's a lot more detail below that as you drill through your e r p system to take a look at, well, what particular component, because we may have a revision at the bomb, we may have a revision down at a component level.
So in the complex engineering diagrams, everything's, oh, I got one revision number. No, no, no, no, no, no. Bomb sub-assembly components. Yeah. When did that component get changed? What was the revision on that component? So in the reference that down at the component level as well. So again, you're not gonna see all this at the top, but at the same time, the continuities there in the, in the, in the well constructed D R P systems, well, again, is that serial number is attached. Yeah. It is all gonna be part of that data set that's attached with it

Paul Vragel (54:09):
Is what looks, let, let me add another, another variation. Indu, industry variation. If you look at medical industry, when they're looking at a product, and, and I had this with a client, you need to have a, the knowledge for every single product, everything that was in place at the point that that was, that's right. Shipped everything. Test procedures, uh, finishes, materials

Chris Gheradini (54:46):
Up You, Paul, we've got guys doing medical devices that are making spinal cord replacement parts. The other group we have, they bring bodies in the back door, so they're dealing with human tissue. Wow. You think about the traceability around tissue and you're thinking about the, the minuscule attributes and donor details. So you're, you're right on there is just a plethora of data that lives behind the scenes and in the medical space, whether they're hard devices or they're tissue and dna, N based stuff, you're correct. That opens up a whole new to complexity. And I think aerospace, defense, medical, they certainly have the biggest requirements. Electronics Sure they do. But, um, yeah, great comment, Paul.

Sam Gupta  (55:21):
Right. Awesome guys. So the only thing we can take right now is great video closing advice. So, Chuck, brief closing advice, please. We have two minutes. Four people.

Chuck Coxhead (55:28):
Yeah. This your engineering design and, and, and documentation. All the revisions and all the different things can very quickly get out of control. You have to beat the drum on the KISS principle. Keep it simple. Stupid. You, you, you. If, if it means changing bombs to agree with the document revision in order to keep it simple and that works for you, do it. Always chase the KISS principle.

Sam Gupta  (55:55):
Love it. Thank you so much, Chuck. Uh, Nira closing advice, please.

Nriav Shah (55:59):
Yeah, I'm gonna say, you know, we're humans, right? We learn from our mistakes. That's no different than an e R P system. There's no different than right. Engineering people, right? So it's continuous monitoring is making sure we understand where the mistakes are happening. Let's, let's get into a situation where there's feedback back to our application engineers. Just develop better products out the door, get better margins, get better, happier customers.

Sam Gupta  (56:20):
Love it. Thank you so much, Nira Paul, closing advice, please

Paul Vragel (56:24):
Think first <laugh>, what do you really need? What is what, what are the things that will make a difference for your business in terms of prevention of issues and giving you, uh, windows to opportunity in getting, getting your product out the door? Uh, what, what kind of automation would really, would really help you? Uh, don't layer on, let's say just any automation. Think, what's the process? What do we need? That's a place to place to start and continue.

Sam Gupta  (57:08):
Awesome. Thank you so much, Paul, for that. Chris, closing advice please.

Chris Gheradini (57:10):
So as you look at your business process requirements that engineering, change management, that's it. Envision them, anticipate the level of complexity in your business in future state and current state. And then try to anticipate and rationalize the amount of manual work it would take to propagate a change through your system and then multiply it and help you rationalize an r o i to put the right tool in place to manage the business.

Sam Gupta  (57:31):
Awesome guys. That's it for today. If you joined for the first time, this was part of our digital transformation series for which we meet every Thursday at 5:30 PM Eastern some week. So you guys are gonna be here next week. We are gonna come back with another topic on that note. Thanks everyone for tuning in tonight.

Chris Gheradini (57:46):
Thank you all. See you again. You good

Paul Vragel (57:48):
Night. Thank you. Have a great evening.

bottom of page