I was curious how other organizations are handling work instructions that should be followed during assembly or when making unique piece parts. Our production staff have put together various reference documents with photos and instructions that shop floor staff can print out. These are simply stored in a common location on our local network, but we’d like to centralize this and make it much easier for team members to access them.
During our initial MES demo, it was stated that many customers simply utilized attached documents on the part or job (DocStar, Sharepoint, etc) and then shop floor staff can pull it up. This makes sense, but I am concerned amount the long term maintenance of this. We have some general instructions sets that cover multiple versions of a similar BOM, but then very specific instructions. I see things getting very messy as parts are revved.
Are there any other interesting solutions specifically geared towards this problem that could integrate with Epicor? I’m picturing the ability to maintain specific steps in a “Process Set” that can be associated with certain media, like photos, videos, drawings, etc. Potentially, these hypothetical solutions could also assist with the versioning and updating process when a process needs to change for a new part revision.
Right now we dump a lot of stuff into the op comments, as well as the op text that’s attached to the op master file. We’ve got drawings, but those are handled by a separate engineering PDM package that’s been running for years. The stuff contained in Epicor works well enough.
We’re beginning to roll out DocStar, and that should let as attach documents to the various objects in a hierarchy and flow it down as needed. So if something is rev-specific, it’s attached to the rev. If it covers every part shipped to a customer, you can attach it to the customer. Then it’s just a matter of using either BPM’s or Breaking and Routing to pull the required items for the given transaction. This is powerful stuff and should drive some big time savings for us.
The PDM software is still the home to drawings and other rev controlled engineering items. The current plan is to keep that there and not migrate it. However, the PDM has an API that I’m hoping to leverage to streamline things. Epicor’s Breaking and Routing module (which we already use for other items) will hopefully make that easier.
Yeah, attaching documents directly to parts/revs would work, I was just concerned about the maintainability of it.
We are also using DocStar and the Breaking/Routing features. We use it as part of our job release process to print the corresponding drawing on the back of our condensed travelers. The downside of breaking/routing is the inability to pull in additional documents that aren’t in DocStar. For instance, Epicor Functions can’t be called directly, or even documents from other locations like SharePoint.
You could part # your work instructions. Call it out in the Method, and then when the Employee needs to reference the document they can go into part tracker and grab the attached work instruction.
To me the ideal solution is integrating a PLM/DMS that houses all of your drawings, machine programs, support document, etc, and integrating it with Epicor. I’d be interested to see if anyone does this.
I do not understand the “maintainability” argument you’re making. You’re already maintaining reference material. The only difference is that linking documents to E10 objects via metadata means it’s a lot harder to pull the wrong document at production time. You can also run queries to find which parts/revs are lacking required documentation. These kinds of things are all much easier when everything is bound together.
Are there options that are even more tightly coupled? Potentially (I’ve already stated I’m personally looking at bridging E10 and PDM), but I’m not aware of any non-custom integrations. If you’ve got the resources to jump to that level, go for it. Otherwise, improvement is improvement.
We don’t do it in Epicor; we use Tulip. Wasn’t my idea, but I do like it. The Mfg Engineers here do up the instructions and then I help them integrate to Epicor. Tulip does a REST call to the Epicor job to grab a portion of the BOM (our jobs have hundreds of ops and thousands of material lines each).
Lately I made an Epicor Function for Tulip to send info to Epicor - specifically to mark an operation as complete.
Point is, Tulip is now the front-end for the assembly line. They have Epicor out there, but they don’t have any need for it now.
@Maggie Right, the office uses Epicor as normal; just the plant uses Tulip.
I think it is pricey. It’s something like $95 per terminal per month. MES, for example, is a tenth of that. But Tulip is much more intuitive and visual - it’s whatever you need it to be.
This was something they wanted regardless, and then “Hey Jason, we need this to work with Epicor.”
I don’t know what the alternatives would cost, or why they chose Tulip here.
I’m mainly referring to the relationships between work instructions and parts. We have broad categories of parts that are similar enough that the same work instructions would be associated with all of them. In the document attachment scenario, you would need to attach the same instructions hundreds or thousands of times to different parts. At the same time, we have specific parts that are a one-to-one with instructions.
I envision some kind of classifier that links a part to its work instructions, so it’s easy to update a bunch of parts at the same time.
@JasonMcD Tulip looks very cool, but is likely overkill for our use case (at this time). Most of our products are large multi-component “lines” custom built to a customer’s spec. We still rely heavily on individual operator/assembler expertise. These documents are intended to be used as reference materials, not step-by-step instructions.
Forrest, at my previous employer we used Epicor 9. We would give the work instructs document numbers and revisions in Epicor. Each revision would then have the document attached to the revision not the part. We never moved the revision, if it was obsolete we would watermark it as such.
In Epicor I would set the part to Non-stock and Phantom and on the BOM where used as pull as assembly. What would then happen is the job would pull in the attachment and it would be available on MES documents. Nothing special.
Set up a Product Line, Part Class, Analysis Code, Material Analysis, Reference Category, a UD field or all of the above to categorize these product families and attach the documents to the respective objects.
If you’re not organizing your parts into the categories you actually use in real life, you’re gonna have problems regardless of your solution.
@Maggie I think in this case, that might actually make the most sense. As long as we still have paper travelers floating around, we could also use APR to pull the instructions into the print automatically. Engineering could simply add the appropriate work instructions part number to the bill.