I got a new project to improve how we handle tooling. In the past, these were added to the inventory and issued/returned from jobs as needed. The tooling is also serialized so I know what jobs it’s been used on. Overall, the system works well enough for finding out where something is at any given time and covering our traceability requirements. Except now we’re looking at preventative maintenance via the Maintenance module. So now I have a conundrum:
Inventory items can be tracked location-wise, but it doesn’t talk to maintenance.
I can set these up as resources, which would solve the maintenance aspect, but the tooling is part-specific. We’re talking thousands of items, and that’s in addition to whatever I have to build in Equipment Entry. And then I lose location visibility because neither resources nor equipment talks to the inventory system. Equipment has a “location”, but it’s not very fleshed out and my users are unfamiliar with it.
Right now I’m leaning towards sticking with the inventory route, and maybe adding a few custom fields to the Equipment table and using that to key BPM calls to Meter Reading to update usage for preventative scheduling. But before I go off building that, I wanted to see how other people handled this kind of thing.
In my opinion, tooling should never be inventoried.
If you create all of the tooling as resources, then you can use scheduling with them. Instead of putting them in the BOM, you add them as a resource on an operation. This setup does give you the location because you will see that the tooling is currently logged into on machine x. If the resource is not currently active and not back in the tooling area, then you can find the last time it was used, who used it, and go ask them. This setup also gives you the ability to track time or hits against the tooling. The other thing this does is allows you to schedule around the usage of them. A job needs this tool on Tuesday? Can’t be done because that tooling is already scheduled on a different job all day Tuesday. I need this tool next week? Can’t because the tool is being sent to a third party to be calibrated. You get the best of every world if it is set up this way.
Thanks for the feedback. I get what you’re saying and I’m usually the first person to try suggest doing things by the book. My struggle is this is all part-specific stuff, it would never be unavailable for a job because we only run 1 job per part at a time, and there’s a fair bit of time between runs of the same part. Scheduling isn’t an issue. Proactively doing maintenance, and then logging it, during the “downtime” is the issue.
Honestly (and without getting into specifics) a lot of the things you want to lean on are areas where my users have struggled to maintain correctly in the system. This isn’t really a system issue. Frankly, even going this far is going to be a culture shock. Hence my instinct to build a shiv to bridge the gap between the current process and where I need to go.
Still, my other instinct is to do it by the book. Perhaps my time is better spent trying to streamline the resource side rather than avoid it? I’m just not sure how I’d even start with that. Thank you, again.
@jtownsend We do it similar, but even looser that you. We have a Tool revision that caries what tools could be needed for a job and they vary by job size, some are hand tools for small quantities and some are applicators for automation. We use normal inventory transfer to transfer the serial number to the floor bin which is the same as the resource group, so we know sort of where it is.
We looked at the Maintenance Module, but are currently using GageTrak for calibrations.
Another issue that’s come up while researching the whole “tooling as resources” is that the ResourceID is limited to only 12 characters. Our existing tooling ID’s exceed that limit and that’s without reserving characters to identify specific tools since we might have more than one of each to allow parallel runs. So going that route will require a discussion about renaming these things, which is always fun, especially when the existing ID is literally etched into the tool.
Oddly, EquipmentID allows for 20 characters.
I still don’t have a decision on which route I’m going to take. I might just pitch both approaches and see what the SME’s think of the tradeoffs. On the plus side, I built out a few BPM’s which automate a fair amount of the resource entry process, which will be helpful regardless of how this pans out.
Just curious which way your team decided. We recently purchased the maintenance module and are planning for using for both gages and equipment and are talking through some of the same concerns/issues you mentioned.
Honestly, there hasn’t been much of an update. Tooling is in inventory and on BOM. That has satisfied the primary goal here, which was traceability. We know which piece of tooling was used on the job (based on issue/return). We also know when it hits the service dept (when its transferred into their “in” bin), when it’s done (moved to primary storage bin).
That particular business unit did not elect to move forward (yet) with automating maintenance. Again, these items are largely part-specific tooling and get a servicing (e.g. (dis)assembly and cleaning) after each run. Over the longer term, these things are subject to repair/replacement cycles, but they’re not frequent enough to really justify that project.
Resources are instead being spent getting tribal knowledge and old paperwork into the system where it is rev controlled and easily retrieved. Not exciting, and not really needing my involvement, but a big benefit for productivity and consistency.
If/when we get to revisiting preventative maintenance, I’ve already got the tool# and serial in the system. Should be a pretty simple copy (via DMT or function/BPM) to the equipment table. At that point, it’s just a matter of defining a template maintenance plan and applying it across the board. Adjust as needed from there.
Whether or not we keep the tools in inventory vs moving to resources is an open question and I’m not particularly inclined to either side. As I said before, Resource is not a great fit for these tools. They’re not constrained and we already know when they’re needed based on the Job schedule.