Common Configurations to Increase Costing Efficiency in aPriori

How to Boost Your Manufacturing Cost Efficiency With aPriori

Matt Roy: Hello, and welcome to the presentation today. What we’re going to be covering today are common configurations to increase cost efficiency for an end user in aPriori. Now, before we get started, I want to give folks here a brief introduction about myself. So my name is Matt Roy. I manage the North American Expert Services team here at aPriori. I’ve been with aPriori now for about four and a half years. Three and a half of those I’ve spent directly working on the expert services team. I’ve held a variety of different roles in the team between when I started and today, being an individual contributor all the way up to now managing the team. Now, that said, throughout my tenure, I’ve worked with a number of different customers in varying different industries, from aerospace to automotive to consumer durables. And on a personal note, my interests include sports, so specifically football, and basketball. Really, I like to play as much golf as I can when the weather is nice. And then cooking for both family and friends and then just hanging out and spending time with family and friends. So before we get into the meat of the presentation, I want to pose a question to the group.

What do we suppose that this 5% that I’m showing on the screen is representative of? Now, obviously, this is a rhetorical question, but this 5% represents the average annual savings our customers see compared to the spend that they put through aPriori. So let’s go through a little bit of an example here just so that we can illustrate what this actually means. So 5% doesn’t seem like a lot. Well, what if we said that our annual spend was $100 million? $100 million worth of annual spend, what’s 5% of $100 million? That works out to be $5 million. Now, that $5 million is what we would expect to see if you put $100 million of annual spend through aPriori. That’s the figure that we’ve come up with based on what we’ve seen in our client base that suggests what’s achievable. So this is really what we’re driving today’s presentation around, how do we increase the spend we can get through aPriori so that we can maximize the amount of low-cost savings opportunities that we have available to us with that spend? I think it makes a little bit of sense to talk here about how we support these savings initiatives.

aPriori’s Real-Time Manufacturing Insights Support Cost-Saving Initiatives

We have over 25 different process groups in aPriori to work with sheet metal, stock machining, and plastic injection molding, just to name a few. We have over 300 discrete processes within aPriori that we can use to help us analyze component costs. We have over 70 different costing regions. We can understand geographically how much a part should cost be at the United States, China, the United Kingdom, or anywhere else in the world. And we have three bona fide use cases. We have the sourcing use case, the design use case, and the quoting use case. All of this is to say that aPriori is a very robust tool that offers an end user with quite a lot of flexibility on assumptions to drive relevant results and improve profit margins. Flexibility is great, but in my opinion, can sometimes be a double-edged sword. So an end user might be faced with a project or costing event that requires a decent time investment. Let’s say up to 30 minutes per costing scenario. That’s a lot of time on the part of the end user to be dedicated to a single cost-efficiency analysis. So the question then becomes, well, how do we speed that up? So it really brings us then to our main agenda for what I want to cover today in this session.

Again, aPriori is a flexible solution, and this presents us with an amazing opportunity to work with our customers to not only respect the assumptions needed for the costs coming out of aPriori to be relevant but also to reduce the time required to receive that high-fidelity total cost result. aPriori does not need to be an intense application to use. Instead, we can introduce, relatively speaking, low-lift efforts to enable enhanced efficiency for a user. So throughout this presentation, think about your deployment; think about where your end users might spend quite a lot of time interacting directly with aPriori. Take note of this, take this back to your account team, work with your customer success manager, work with the expert services consultant, and review these situations and opportunities in which we can improve the user experience. In making an end user more efficient, we enable the ability to cost more parts, thus increasing the value aPriori can generate. Remember, just a couple minutes ago, we talked on average, 5% of total spend costed through aPriori can be converted to hard dollars saved and improved bottom lines.

Throughout this presentation, we’re going to be talking about automated process inclusion, tolerances to drive critical assumptions, and, finally, virtual welding. Now, before we get into those nuanced topics, I do want to take a second here and just touch on what we have available in the current product today. All of what we’re going to touch on today are something of customization configurations that we can put in place, but I think it’s worth noting what we already have. And that falls into bulk costing, BOM loading, and matrix costing. Bulk costing, if you’re familiar, you can take a large swath of parts, assign some inputs in a spreadsheet, and kick off a costing event without having to open up each individual part in aPriori and cost it. You can do that tabularly and hands-off. You set it up, click it, let it run, and come back when it’s complete. BOM loading allows us to get purchased components, hardware, or off-the-shelf parts into aPriori and assigned with their known cost. BOM loading also provides us the opportunity to push UDA inputs to scenarios en masse. If there are certain values we need to assign to a part that’s contained within a UDA or user-defined attribute, we can create spreadsheets and use our BOM loading capability to get that information onto those scenarios in aPriori.

Automation-Driven Mechanical Operation Inclusion for Cost-Effective Parts

And then lastly, matrix costing. Matrix costing, if you’re not familiar with it, is an inherent functionality that allows us to create a number of different scenarios that are reflective of varying geographical areas of the world that the part’s being manufactured in, along with different volumes and batch sizes. Not listed on here, but just a quick mention, we do have the opportunity to take advantage of the command line in Windows, and this is on-prem only. We can execute bulk costing and BOM loading through the command line. We can also run reports through the command line, among some other actions, so we can script that and make things a bit more efficient. But starting off with our main topic here, I want to start to discuss what automated process inclusion looks like. What you’re seeing on your screen right now is a very simple assembly. And what we’re going to walk through in these next few slides is a typical workflow to add mechanical assembly operations to subcomponents. Now, when I was going through this workflow and creating this presentation, I did a little bit of reflection and deliberate analysis of how I would go about this.

And what I found was that for each subcomponent we need to add mechanical assembly operations to, there’s a minimum of five clicks to include a single mechanical assembly operation. And subsequent to that, another two for each operation were added thereafter. And this needs to be done for every subcomponent for our assembly costing results to be as accurate as possible. So to step through this process, you would right-click on the subcomponent in the UI and select the edit operation drop-down in that menu. From there, you would select the operations that are of interest to you in the routing dialogue screen presented. You’d right-click and click include. And then, from there, you would adjust any PSOs or any other settings that you’d want. You’d have to, again, do this for every single mechanical assembly operation on a particular subcomponent. And then once you do that, you get a cycle time, as denoted here, for about 17 and a half seconds. Right? Pretty straightforward, pretty easy, and not a big deal, but let’s just assume that we have an assembly with over a hundred subcomponents.

What I just showed you is going to take a lot of time. Even if we assume 30 seconds per part, that’s still a good bit of time. So what can we do about this? There’s two options here for potential solutions or two flavors maybe is a better way to characterize it. Number one is leveraging UDAs or user-defined attributes. So what you can see on the screen here is a drop-down menu for UDAs that reflect a certain mechanical assembly operation type. We can create these UDAs, then have the end user go in when they’re costing the hardware components, in this case, or the subcomponents, whichever they may be. They may be both. We assign the UDAs that are applicable to the operations that we need present on these subcomponents. We can then go into the background of the tool into the cost model logic and write rules on these operations themselves to include if the UDA selections match. So when somebody was to go back to the assembly and recast it, those mechanical assembly operations will automatically be added to these subcomponents where appropriate. The second flavor of this is leveraging the part’s name or number. Oftentimes what I’ve seen in the past is that folks will name their hardware bits explicitly, post, screw, nut, whatever it may be.

We can use those part names or part numbers to create a table of known mechanical assembly operations. And we can use that cross reference and look up to tell aPriori which mechanical assembly operations need to be applicable to a certain subcomponent of an assembly. Now, we also have a third option, if you will, the best of both worlds option. We can combine the functionality of those two things that I’ve just mentioned, UDAs and the parts name or number, to create a solution that allows you to apply mechanical assembly ops for costed subcomponents. So actually manufactured or fabricated subcomponents that are part of the assembly that are not standard via the UDA. And then, we can use the second part of the solution about leveraging the parts name or number for hardware, if applicable. So for the vast majority of parts, which is the hardware, no worries, the end user doesn’t have to do anything. And for the smaller percentage of parts that are actual manufactured subcomponents, we can use the UDA route to get those mechanical assembly operations on those particular parts.

Now, this can be leveraged with bulk costing, this can be leveraged with BOM loading, bulk costing. Since it’s driven by UDAs, that’s an input that we can specify in a bulk cost input sheet and then BOM loading, of course. Like I mentioned, we can use that to get these UDA values on the scenarios if they are already present within the aPriori database. And so if we go back to the assembly and look, well, lo and behold, these mechanical assembly operations are automatically included without us having to do anything at all. That’s assemblies. Now taking this a step further, a different idea or flavor of this same solution can be applied to automatic secondary process inclusion. Almost every single part that is manufactured, I say almost, is going to have some sort of surface treatment, heat treatment, inspection, test, or whatever it might be associated with that part. To get it to a point where it’s ready to be assembled or used in its intended use case. So we can apply a similar solution here and create a UDA that houses specs. I’ve seen customers do this in the past where they have a certain alphanumeric spec that then translates to a single or series of surface treatments, heat treatments, inspection tests, et cetera, that need to be included on the part. What we can do there is take the UDA option that is of interest.

And now, if we look here, what happens is anodizing has automatically been included because we’ve applied that spec. These are arbitrary, but the idea is that this spec would then translate to aPriori, suggesting I need to automatically include this particular operation or process. Again, since this is UDA driven, it can be done via bulk costing or BOM loading. Now, one other slight riff on this solution here is that we don’t need to necessarily use UDAs to drive secondary process inclusion. We can also use the material. So, for example, perhaps the supplier and the requirements of your design in part suggests that any part made of aluminum 7075 needs to be anodized. That’s an easy rule that we can write in the cost model logic so that it takes some of the burden off the end user of assigning these cost incurring secondary processes. And then, of course, we can obviously take advantage of this in cost insight reporting. That, I think, is good to put out there as well. Moving on to our next topic. Tolerance is driving critical assumptions in manufacturing. We’re going to go through an example here to give an illustration of what this actually means.

We’ll take this part that you see on the screen, a very simple flat plate machine part. We’re going to cost in the United States, and we’re going to assume a material of aluminum 6061. When we cost the part without any tolerances applied, we have a time of about 287 seconds of cycle time for machining. Now, when it comes to machining, for those who are familiar with the commodity type, tolerances can drive quite a variety of behavior. Now, by default, in aPriori, when an applied tolerance cannot be met with traditional machining, milling, turning, whatever it might be. A specialized finishing operation like grinding for surfaces or reaming for holes is automatically invoked. However, what I’ve seen in practice is that, typically, the case is not that a feature would be ground or reamed. But perhaps additional finishing passes on that surface will be assumed to meet that tolerance instead of invoking a completely different process altogether. With that said, we can write very, very simple logic so that instead of automatically defaulting to secondary and specialized machining to accommodate a tolerance based on a tolerance band or threshold, we can automatically apply additional finished passes to certain features.

Now, the reason why it’s included here in this presentation for efficiency is because number of finished passes is something that aPriori always assumes to be one and needs to be overridden feature by feature. So if we were to then go ahead and assume that we want to put a profile of surface tolerance of five-thousandths of an inch on either large face on this part, not only do we have to set that tolerance, but then we have to go into the routing dialogue to then select the number of finishing passes. If we haven’t set up this automation of tolerancing driving the amendment of a number finishing passes assumed. So you can see here what we’re doing is setting the tolerance on those two features. We’re then right-clicking on the feature and going into its process setup options to take a look at the finished passes. And you can see here highlighted in this red box number of finished passes. I’ve already made the change here to assume and trigger an additional finishing pass for a tolerance that meets the criteria. However, you get the idea that there is at least one, two, or three clicks involved in order to set a finished pass change on a feature, and that needs to be done feature by feature.

So if we were to do this and then revisit what that costing is and what the change then results in assuming additional finished passes, we recast the part, and we see now that we have a cycle time of 320 seconds. If we take a step back and review what that looks like for no-toleranced versus toleranced, the no-tolerance part was coming in at 287 seconds. Tolerances on two of the larger surfaces that require additional finished passes. Now our cycle time jumped up to 320 seconds. Not too much, only about 33 seconds of time. But that’s an 11 percent increase scenario to scenario. And where this becomes important is that if you had a part that was a couple hours, a 10 percent increase on a couple-hour part is somewhat significant. And for us to make sure that we’re aligning those assumptions correctly, an end user would have to set the number of finishing passes feature by feature. With a small, minor, very, very low-effort configuration, we can automate that behavior and take it out of the hands of the end user. And so if the appropriate tolerance has been applied, then we’re good to go.

Now taking this one step further in terms of efficiency gains and working with tolerances, aPriori offers a feature that enables the extraction of semantic PMI data and metrics from the model. So what does this mean? This means that an end user would not need to specify tolerances as they’d already been set on the model and therefore imported via the geometry extraction process that aPriori engages in when we’re doing a costing event. So this creates a major boost in cost efficiency because now we don’t have to assign tolerances on each feature based on the print. aPriori is going to import that for ourselves. And then on top of that, if we put in place the configuration to change the assumption of finish passes driven by tolerancing, well, that puts us in a great spot as an end user to just cost the part tolerances pull in and the correct number of finishing passes are being assumed, therefore giving us confidence in the time of the resulting costing event, as well as creating a much more streamlined process for that costing with tolerances being considered. Now, the last topic that I want to go through here is virtual welding. For those people familiar with welding in aPriori, it can be, at times, somewhat tedious.

Using aPriori to Improve the Cost Efficiency of Welding Methodologies

So before we talk about improving the efficiency of applying and assuming the cost for welding, it makes sense to first understand why applying welds can take so long in the first place for those who might be unaware. In order to apply welds, you need to use the weld tool. You can find that at the top of the rendered model with the paintbrush or pen icon. Each weld needs to be added and configured properly with the necessary edges selected, which can be tedious if you have a lot of welds in a large assembly. So a couple of things to take into consideration here. You need to determine the weld type. You need to determine whether or not it’s being laid down manually or it’s being laid down by our robot. What the size of the weld is, and if there’s an intermittent pattern. I mentioned you need to select edges. So you have to select the edges where a continuous bead will be laid, and then that total weld length will be automatically aggregated. And you need to do this for each weld. And so after you’ve done that, a weld GCD has been created at the bottom of the screen. And again, your user would need to do that for every single weld on an assembly. I made that look a lot easier, and it is. And on this part, it is quite easy.

Let’s take, for example, you had a very large assembly, over 100 subcomponents, and there was components within that assembly that are obscuring certain edges that you might need to weld. Well, you’re going to have to do a lot of manipulation of the model itself in order to find those particular contact regions that you then assign a weld to. So if you have a lot of welds in a part, doing it manually by hand can take a lot of time. It’s going to give you a pretty accurate result, of course because you are using the geometry to drive the inclusion of these welds in the assessment of them, but you’re doing it by hand. So how can we make this process a bit more streamlined? So let’s take the following set of parameters as an example for this virtual welding. We have three different welds, two fillet welds, one bevel groove. The two fillet welds have different dimensions on them, and there’s different counts, and they all have a different, or rather not different, but disparate total weld length potentially. So why don’t we review how virtual welding will work? The end user would group the same welds together into line items like I have here on my screen, and add their total weld lengths together.

Then once that information is understood and tabulated, you can begin to create virtual welding instances and assign the appropriate input to each instance invokes. What you do on the screen here, you’d right-click and go to the routing selection dialog window. You then pull up the routing dialog window. From there, you would go ahead and review and identify which and how many instances you need. So, in this case, we have three discrete types of welds that have a different set of parameters. So we need to create three occurrences of that. Once we do that, you can then see that we have three instances of virtual welding created. On each one, we then need to go into the process setup options to identify those parameters. And so what this does is this enables us to add 18 welds in far, far fewer picks and clicks, with much less margin for improper assignment. And that includes wrong edges selected, too many edges considered part of a weld, and inappropriate size considerations that the traditional weld tool might use. You might lose a bit in terms of fidelity of results, but you more than make up for that in throughput.

Now, for those that use Creo, aPriori also has the ability to import pro welds onto the model so that it eliminates any user intervention altogether, similar to the tolerance import. And so what you can see here now on my screen that I’m highlighting is that we’ve gone ahead and now included cost for three discrete weld types. We’ve dramatically improved our efficiency here, and this is a really good opportunity for bulk costing as well. Bulk costing is something that we like to think does provide us efficiency, but in terms of welding, you can’t use the weld tool in bulk costing, of course, but with this solution, you can. And so, again, that further underscores the potential efficiency gains that something like this minor configuration can really help drive for our end users. So wrapping things up. So why do we consider or care about increasing cost efficiency in the user experience? Really what it boils down to is higher throughput of analysis of spend, more efficient users likely to embrace adoption, and fewer expert users required.

Adopt aPriori to Bring Cost Efficiency and Better Decision-Making to the Supply Chain

So what does this do for us? It really gives us that idea that we’re increasing our savings because we’re enabling ourselves to put more spend in aPriori and really drive value. So, in summary, reach out to your account teams about this. If you found anything in this presentation compelling to you that would fit your use case or your situation, talk with your CSM, talk with your expert services consultant. They’ll help understand your particular situation and advise you with a plan to move forward to help you get to that point of increased cost efficiency. So with that said, I want to say thank you for listening to the presentation.