For this episode of the “PLM Quick 30,” we speak with Heather Pomerene, Senior Principal Mechanical Engineer at Northrop Grumman, about all things options and variants, including:

  • Major hurdles to consider when thinking about pursuing options and variants
  • Why they’re a stepping stone down the path of digital transformation that gets you one step closer to a model-based enterprise
  • Essential to ensure that your options and variants way of working is not only successful when it’s first launched

Contact us if you’re ready to discuss a dynamic PLM strategy.

Transcript

The transcript is close to a literal transcript of the spoken word. Please excuse any grammatical errors, spelling errors or break in the flow. The podcast is a non-scripted conversation with natural flow aimed to deliver value.

Patrick Sullivan:

Hello everybody. This is Patrick Sullivan with Archer Grey’s PLM Quick 30. Thanks for spending some time with us to talk about all things PLM and today we have a return visitor, so we didn’t offend her at all. Heather Pomerene is back for the attack. Her title is Senior Principal Engineer at Northrop Grumman and if you haven’t listened to the previous episode, she tackled a tough topic, but very popular model-based design in this whole discussion of digital thread and digital transformation.

Many organizations dream of implementing model-based design and Heather is one of the few that has implemented it successfully so you will not want to miss a lot of the knowledge that she dropped in that last episode. So today she’s joining us to talk about options and variants, which I know is a very relevant topic for lots of organizations who are trying to implement efficiency in their design and engineering processes. So we’re excited to have you back Heather. Thanks for spending some time with us.

Heather Pomerene:

Thanks, Patrick. Appreciate it.

Patrick Sullivan:

Absolutely. I know some folks may not go back and listen to that model-based design if it’s not applicable for them. So would you mind taking a few moments here and introducing yourself, Heather, and giving everybody some background?

Heather Pomerene:

Sure. Like you said, my name’s Heather Pomerene. I am an engineer with Northrop Grumman. My background originally was in Space Systems with Northrop, just recently transferred out to the defense portion of the business. So been implementing a lot of what I’ve previously implemented in the last location, into the new location here. My background. I have a broad background in the model-based definition, like we’re going to talk about today, options and variants as it applies in Windchill and in Creo, just lots of that digital thread.

Patrick Sullivan:

Yeah. Awesome. Great. So thanks for that intro. So I’m curious, and I know we touched on the topic and I think I asked you the question of what digital transformation means to you, but I keep talking with individuals about digital thread. Okay. And since you brought it up first, I’m curious to know, when you say digital thread, can you give some context around that please?

Heather Pomerene:

Sure. So in my broad scheme of things, digital thread can be created for different entities and processes. It follows a product through the life cycle, design and inception through engineering, product life cycle management and manufacturing instructions, supply chain, service history and customer events. So, it really enables you to anticipate and effectively communicate up and downstream of where the product is in its life cycle. Really making sure that everybody utilizes that most current dataset and reaction time is on point.

Patrick Sullivan:

Yeah, that’s great. I loved that you mentioned that everybody’s able to access the most current dataset because that’s very relevant. In fact, at the PTC User Tech Committee meeting, we actually ended up giving a presentation on where is your digital thread broken? And so we kind of went through that, although we displayed it in a linear fashion like you just described from concept to design to manufacturing on down the line. We had specific examples branching down of artifacts along the way and how the information builds on each other and everybody’s interpretation of what may be a digital asset or a physical asset. And you know, the simple question of is a PDF digital? Which we had people wide survey, some people considered it digital and then others thought, “hey, is it dynamic?” And so the debate started from there.

Heather Pomerene:

That is a hot topic. But in my point of view, and obviously everyone has their own, entitled to their own opinion, from my point of view PDF is outdated the minute it’s created. So I prefer to not rely on PDFs if possible.

Patrick Sullivan:

You are going to get so many emails after that comment. Yeah, our conversation of trying to level-set it was, is the information something that you can consume and pass on in a digital fashion where people can leverage it in an efficient way. And you’re right, PDF as soon as you create it, it’s a dead artifact. It’s disconnected. All right, so I just jumped in there with you. So let’s bring this back a little bit to the topic of options and variants and for some folks who may be new to the topic, I think that’s probably a good place to start before we start kind of diving into it. So Heather, can you explain to everybody who’s listening what options and variants means and why we might be talking about it on this podcast?

Heather Pomerene:

I would say in kind of general terms with options and variants, you’re going to be able to manage lots of different configurations under one base model, or what we call the overloaded BOM, or overloaded model with predefined requirements. So within the context of that model, we’ll define all the parameters, all of the constraints for every different option possible. It’s also going to allow for more robust and efficient design and collaboration and to quickly output variant deliverables. Kind of on demand as a customer needs one. So you don’t have to actually go in and save a copy anymore, make your updates, you can do it within the context of Windchill and configure the WTpart to the spec that you need to create.

Patrick Sullivan:

So can you give, if you step back, and think about the product in and of itself and help some folks visualize what options or variants would be in terms of a product. Is that question clear by the way?

Heather Pomerene:

Like different colors or different…

Patrick Sullivan:

Yeah, like for instance, we were working with a client that was in the automotive industry and they were interested in pursuing options and variants related to creating greater efficiencies of how they could turn around estimates to clients from their sales team to their engineers. But the sales team couldn’t provide estimates without collaborating with the engineers. And so what used to take three or four weeks to turn an estimate around was shortened down into, we went through different phases of it, but it was ultimately shortened to days versus three or four weeks because of options and variants. So for instance, what kind of chassis, there’s only a few options and variants that can exist for that specific model like you had earlier. And so seats, color associated to it. So that would be an example, at least from my perspective that I would kind of explain, and that’s through the eyes of automotive, but you’re in aerospace and defense. So I’d be interested to hear an example, you know from your perspective.

Heather Pomerene:

For example, we deal with different heights of things, so we might have different station heights for the same component. So it’s the same component just assembled at a different height offset from a generic plane. So various things like that that depending on what it is that we’re building, we may scale it, but it’s going to be pretty much the same deliverable aside from maybe a couple of items that then need to stretch with that change.

Patrick Sullivan:

Got it. Okay, perfect. Thank you. So now that we’ve got kind of a basis understanding to work from here, thinking about a company that may be thinking about implementing options and variants functionality, what are some compelling pain points where the business, well I guess that the business could use in justifying the investment of implementing options and variants functionality?

Heather Pomerene:

Say really at like the lowest level. If you find yourself recreating the same thing over and over again, just with slightly different variations, this is definitely a do-able process for you. It doesn’t even need to be a full product. You can start with, we know that 75% of our product has 10% variability. Okay. So then that 75% is now built into an options and variants style output. And then on top of that is where you build the rest of your product. So it doesn’t need to be a full end-product, so to say, you can definitely break it down into, into smaller subsets.

Patrick Sullivan:

So when you’re talking about, excuse me, when you’re talking about the potential of investing in, in implementing options and variants, you’re suggesting that it could be broken into even product by product?

Heather Pomerene:

Oh, absolutely. Yep. Even subsystem by subsystem. However you break down your product. I would say there’s a use case for a lot of the industry there.

Patrick Sullivan:

So I mean, I know that you’ve implemented this in your past and so one… I guess what were some of the key factors to help ensure that you were set up to be successful when you implemented it?

Heather Pomerene:

I would say the number one factor to ensuring a success is skeleton usage. 100%. So the way that I went about it, I built up an overloaded BOM in Creo first. So I had all of my options built up into the physical model and basically everything that I put into that model hung off of a skeleton.

So you really have to understand dependencies and things like that where you really want to make sure that it’s all driven from that central skeleton, so that nothing, when it goes to configure, nothing’s going to hiccup. Nothing’s going to fail, because you’ve now, component B that you assembled to component A now can’t exist anywhere because component A is not part of that configuration. So now component B fails and you fail that configuration. So definitely skeleton usage. And I would say if you’re doing full PLM in Windchill, the other major hurdle or issue that I wish I had known about when I had done it was making sure that all of the change notices and things like that were executed properly for everything below what I was configuring, which took a lot of time to fix because that was not a known factor at the time.

Patrick Sullivan:

All right. So I’m going to rewind a little bit just in case, I’m assuming that the engineers that are listening know what you’re talking about. So for the benefit of the non-engineering folks, can you define skeleton usage a little bit?

Heather Pomerene:

It’s kind of like an anchor for your models. It’s a central point from which we hang datums and defining features off of. So within the context of an assembly, I’ll have a skeleton, I’ll have all of my coordinate systems in that skeleton, to which I will assemble the rest of my sub-components and all of that. The parametric ability is all contained within the skeleton. So, depending on how I want components to move with relation to each other, I’ll build that into the skeleton to the coordinate systems, for example. So that’s kind of in a nutshell, I guess, my main usage of skeletons. Obviously there’s motion skeletons and space claims and things like that. But in this context that is to which I am referring.

Patrick Sullivan:

Okay. So when you have your overloaded BOM first, which are we equating an overloaded BOM? So how would you phrase it to say overloaded BOM and skeleton usage together? Because, you had started saying the first thing without a doubt is skeleton usage. And then you started by, and then you went into your next point of saying that the first thing that you did was built and overloaded BOM. So kind of pull those two together. They’re not synonymous, right?

Heather Pomerene:

No, but the skeleton goes into the overloaded BOM. So it’s basically one end product model within Creo, an assembly that has a skeleton basically at every configurable module level. So there’s configurable products at the top level and then modules, and modules can go into products and products cannot go into modules. So all of my products would have skeletons within the context of an assembly. I would put in every possible option, assembly or part-wise, configuration-wise within that top assembly, with all constraints for every part or sub-assembly hanging off of the configurable product skeleton.

Patrick Sullivan:

And so when you said on your second pain point regarding making sure that the CNs (change notices), right…

Heather Pomerene:

Yeah.

Patrick Sullivan:

…were executed below. Are you referring to the sub-components that are hanging off of the skeleton?

Heather Pomerene:

Yep. Every single, and I mean every single component within the context of your overloaded BOM, regardless of whether it’s a tiny little screw or a much larger sub-assembly, all of those change notices need to be executed properly. Because if you, for example, if you have it in your business rules to not have or to make sure that you’re WTpart revision matches your CAD revision and those are disconnected because the change notice was implemented incorrectly via a revise function, or someone went into the change notice later and added another… Let’s say someone went in, started a change notice and only revised CAD without revising WTpart. So now that new revision of CAD is linked to the old revision of the WTpart. So then they go in and add the WTpart to the change notice, revise that, but now the two new revisions are not linked together. So that in and of itself causes problems with configuring in Windchill.

Patrick Sullivan:

Yeah, that doesn’t sound good.

Heather Pomerene:

Yeah. I know. So every single issue like that when it comes time to configure will rear its ugly head. So if you pay attention to those kinds of things before it becomes a problem, making sure that the philosophy of why people need to revise and execute their change notices properly upfront, it saves you time in the long run when it comes time to do options and variants. Because then you don’t need to do product structure compare, build functions or anything like that.

Patrick Sullivan:

That sounds like one of the big lessons learned. I mean you said it up front around CNs, but I’m sure you probably have a big playbook that you would apply moving forward. It sounds like a lot of trial and error that you had to go through to learn that lesson.

Heather Pomerene:

Yep.

Patrick Sullivan:

No, that’s awesome. Thank you for sharing that. So, all right. So we talked a bit about what do you need to be ready to implement options and variants successfully and you don’t have to eat the whole elephant at one time, you can take a more methodical approach right, of approaching one product at a time. And, and thinking about some of these major aspects that can save you time in the long run, paying attention to how you treat change notices upfront so it’s not as painful on the backside. Did you have any other big lessons learned or major hurdles that you need to consider when you’re thinking about pursuing options and variants?

Heather Pomerene:

It really was just the skeletons and the revisions. So making sure the revisions between the CAD and the WTparts matched up. But therein lies… What I’ve been advocating for awhile is philosophy of product structure where if we can kind of focus in on that to begin with and we build up a strong product structure, your model integrity is on point all through change management, then it all becomes a moot point in the end. So it really does come down to those two things in my opinion.

Patrick Sullivan:

Yeah, that’s great. Okay. So if those are the major blocks to pay attention to it, then let me kind of tie in this idea of transforming an organization, because options and variants is definitely a different way of approaching your product design. Right? And so oftentimes when executives decide to fund something, they fund it with the mindset of there’s a start and an end. Is there one for options and variants?

Heather Pomerene:

No. I mean there’s obviously a start because you need to draw that line in the sand. But there really is no end unless you say there’s an end of life here and that we’re not going to be producing any more products up to this point. Literally. But as far as it goes, I would say it’s definitely like a stepping stone down the path of digital transformation, to be poetic. It is a piece of that digital thread that gets you one step closer to a model-based enterprise in the end. It doesn’t need to be part of your enterprise view, but it definitely does aid in the long run. Especially if you have a lot of re-use in your industry.

Patrick Sullivan:

So thinking about that idea that there is no, and related to it… I feel like a lot of organizations underestimate the amount of effort that an investment needs to keep it alive. That’s why I say beginning and end. Everybody goes back to their normal day of work, but it’s a new way of working that requires love, care, feeding. Right?

Heather Pomerene:

Yes. It’s like a house plant.

Patrick Sullivan:

It’s like a what?

Heather Pomerene:

It’s like a house plant.

Patrick Sullivan:

Exactly. I mean, what would you say are some of those essentials when you’re thinking about that this is a journey, what are some of those essential things to ensure that your options and variants way of working is not only successful when it’s first launched, but more importantly, sustained.

Heather Pomerene:

Definitely you want to make sure that the… I mean there is going to be a lot of time spent upfront in this setup, that’s a given. There’s a lot of time spent there, majority of the time. But as far as sustainment goes, you want to make sure that as you’re making these changes or you’re applying change notices to your overloaded BOM, that they’re done methodically.

Because there’s a lot more contained within the BOM and within that model than normal, that becomes a task in and of itself, just ensuring that everything is captured that needs to be captured whenever you’re going to be rolling a revision or something like that, or applying the change, if you need to add a part or make a new configuration, that every aspect is addressed before that’s rolled out or before it’s reconfigured. Knowing where the change needs to be applied. Is it a global change that you just apply to the top level and it doesn’t need to be as part of a choice or something like that when it comes time to configure in Windchill, or does it only need to be applied to certain variants? That kind of methodical work needs to take place down the line. So the users need to have a broader scope of understanding of the whole product, not just of one variant. So that’s really important.

Patrick Sullivan:

Are there products that aren’t appropriate for options and variants that even though it could benefit from an efficiency standpoint, to your point about users need to have a broader understanding of the overall product to understand the ins and outs of options and variants, are there some products that you could see that although it would be beneficial, just aren’t conceivably…it just can’t be done, to your point about the broader scope and the impact associated to the overall model.

Heather Pomerene:

Yeah, I mean, I can’t think of obviously anything specific off the top of my head. I definitely think maybe just if it’s a super small product that you’re trying to configure, weigh the time to value. That’s really, I would say, the biggest hurdle for that. I can’t think of a specific product.

Patrick Sullivan:

That’s okay. It came to mind as you were starting to think about it, and I thought, Oh wow. You know, when you, when you start to think about some of these larger products that are very complex, and also the larger the product, oftentimes the more variants that you could have.

Heather Pomerene:

Oh absolutely.

Patrick Sullivan:

Unless it’s engineered to order it then maybe options and variants may not be applicable.

Heather Pomerene:

Right. Therein lies the balance, because depending if you go the overloaded BOM route, having to maintain, if have a very large model, having to maintain that in CAD can get very cumbersome. So that balance needs to be there as well. There comes a point where, well now we’ve built entirely too much variability into it, that there isn’t any benefit long run, so you need to weigh how much variability you want to build into it and kind of stick with it. And it needs to become its own standalone model at that point.

Patrick Sullivan:

How do you ensure that all the rules that were established up front, I mean, with regards to, making sure that the skeleton and revisions match, how do you ensure that all rules are being followed? When you’re setting this up is a large portion of it automated or people need to understand the cause and effect of how the initial configuration was originally set up and the intent related to it.

Heather Pomerene:

Oh yeah. 100% the latter. I’m a firm believer in making sure that people understand why they need to do things a certain way. There might be six and one half dozen ways to get from A to B, but they all have background consequences that they don’t know about. But there is one way to get from A to B that yields the best result and they need to know why they need to go that way. So it really boils down to transparency into the users so they know why they need to do it a certain way and explain that to them upfront. Because if you just say, “you need to do it this way” without any explanation, they’re not really going to listen. They’re going to go off and find a better way to do it that might be faster. That they might like better. But in the end it causes more problems and they don’t know that. So…

Patrick Sullivan:

How how do you help avoid those scenarios? I mean you had mentioned education up front as to the why and I don’t know if consequences is… but the trade offs if they detour.

Heather Pomerene:

I actually got to the point where I would actually record myself on the computer showing the repercussions of what happens, and then I would push that out and say, “this small mistake that took you five seconds, took me 10 minutes to fix and this is what this is what goes into that.” So at that point, it really kind of sunk in when they could actually see the work that goes into fixing some of these mistakes and, “oh, maybe I will pay a little bit more attention to what I’m doing next time.”

Patrick Sullivan:

Does it ever trickle down to production?

Heather Pomerene:

No. It hasn’t gotten that bad. But, you know…

Patrick Sullivan:

I mean, could it conceivably? Not to say specifically with you, but if people don’t have tighter controls and they’re not following the governance that was originally put forth, even though they may have been educated, and to your earlier point, it’s just faster, they can push it through, they may get approvals but it could have huge consequences.

Heather Pomerene:

Then yes because, like I said earlier, if you are fully PLMin and you are releasing your data in Windchill, the shop floor might be looking at one version of CAD as a deliverable, something their MBD and Creo view. Then they go and they look at the related objects. They pull up an older version of a WTpart unbeknownst to them because that was how that change notice was implemented, obviously incorrectly. It takes them to an older revision, an older product structure is associated to that. There might be some older documentation that’s associated to it. So yes, I can see where that would cause problems down the line. Those kinds of things though we did catch ahead of time. So luckily it really never became an issue.

Patrick Sullivan:

Yeah, that’s great. Well we covered a lot of topics and I want to thank you again for jumping on the call. I’m curious, is there anything that we didn’t cover that you feel is important to at least mention on this topic of options and variants?

Heather Pomerene:

I would say, I guess two other things. So obviously building your configurable model, you’re overloaded BOM model, outside of the context of your production model. You don’t want to be building up your overloaded BOM in the context of your upper level assembly, which just causes issues across the board.

So therein lies where you can apply it in smaller chunks if you want to. So you can take out a subsection, build up your overloaded BOM, configure it, and then swap out the new variants in your upper level assembly once that’s made. So that makes life a lot easier because you’re making this overloaded BOM outside of anything that’s being reported to it. So that was pretty important. And then also just something simple like building your own table view within the context of Windchill, like when you’re trying to assign your choices. I found that super helpful. So I did… I put all the columns for “expressions” and then I would have a column for “built from CAD” and then the “version.” The “built from CAD” column option was really helpful when it came time because if I saw something that was not built from CAD as I was going through, I knew that that was a part that needed to be addressed that might’ve had its change notice improperly implemented. Just little triggers like that really help with that data management.

Patrick Sullivan:

I mean it’s those small things that ended up that ended up making a huge difference.

Heather Pomerene:

Oh 100%.

Patrick Sullivan:

Oh my gosh. Thanks for sharing those. I’m glad I asked that question. I appreciate that.

Heather Pomerene:

No problem.

Patrick Sullivan:

Definitely for the folks that are tasked with helping implement or structure the implementation plan around options and variants, they’re going to get huge value out of this topic. I’m glad that you were able to set aside some time to spend with us, so thanks again Heather. Really appreciate the time and all of your expertise on this topic.

Heather Pomerene:

Thank you, Patrick.

Patrick Sullivan:

Any other items you want to address before we part ways?

Heather Pomerene:

I think that’s it.

Patrick Sullivan:

All right. Awesome. Well, thanks again Heather, and we will look forward to collaborating more in the future.

Heather Pomerene:

Thanks for having me. I appreciate it.

 

Join our email list to receive updates