I have a challenge involving the recording of job related setup activity as trackable ‘entities’ distinct from the jobs they support.
we run several jobs per day on one of our machines. There are setup activities that occur between those jobs requiring engineers and other setup personnel. our operations mgmt wants to be able to analyze these in the same way she would analyze the jobs themselves.
We know that we can specify these in the form of operations within the jobs, but we really want them to be separate for the purpose of analysis.
Current thinking is to create dummy parts that hold the operations required for these activities and put up jobs for the setup in between the ‘real’ jobs. we may try this approach to see if it yields the granular perspectives on our setup activities.
However, since e10help exists, i immediately thought i might get some feedback from others that may be analyzing production work at this level.
What metrics are you really working to achieve? Is it multiple people? Is it multiple details of an operation to setup? Just trying to get a little more detail of the output you are really working to get. Do you need the cost of setup included in the pricing of the part production? Just curious here to think about it further.
Thanks Josh. And, thanks to your post, I realize mine had very little useful information for anyone to provide a thoughtful response.
So, as the IT guy, I’ll articulate my understanding of the need, as relayed to me by Ops mgmt, thusly…
Our changeovers involve many of the same tasks performed by the same team - sometime more people, sometimes less, sometimes longer, sometimes shorter – and is part type/category specific, as you might guess. Part type A requires a 2 hour setup, while Part type B may require 4.
There are times when significant issues occur during changeovers (component failure, etc.)
Occasionally, mistakes are made, and every facet of our changeover has costs associated with it.
At present, we simply use an overhead factor in our job setups to accommodate the setup costs - based on annual reviews to determine the appropriate factors. So that’s the scenario and we will continue to use this method to capture our setup costs in the production of parts.
I think whats still a little unclear (because it doesn’t exist) is what a screen would look like if the Ops mgr could snap her fingers and make it appear. Examples I was provided include KPIs like…
How often did my 2 hour setup actually take 3.
Across all machines on the production floor, how many ‘longer’ changeovers per day have I been performing.(understanding that I’m paying production personnel to stand around while changeovers occur).
Increased visibility into the changeover process (separate from the jobs they support) might allow mgmt to make better scheduling decisions, and, as with all efforts, hopefully reduce costs.
We have always posted setup costs as indirect, like you, our setup costs are covered by overhead costs. I originally set up user defined fields to record the job, assembly and operation. Data entry clerks posted any setup entries on our time slips as indirect and entered job info into the user defined fields. (Yes, we enter time slips manually.) This worked to collect setup hours on a job, with no cost. I imagine a BPM could be set up to also collect labor costs, we weren’t concerned with it. We recently started posted setup as Epicor intended using the setup labor type. We didn’t want setup costs to go to the job/part. I wrote BPMs to move the labor rate to a user defined field before zeroing out the labor rate. I added a dashboard that calculates setup labor costs using the user defined field with a report exported to Excel, which is then paste inserted into journal entries capturing the setup labor costs for GL purposes. Jobs allows entry of estimated setup time and setup crew size. All information needed for reporting on setup efficiency and/or setup costs would be available. Maybe a version of one of our solutions will work for you.
@snielsen28 That is very interesting… We also use paper to track setup activity. While all job-related activities are tightly bound to Epicor, There’s absolutely no interaction between the folks performing setup work and Epicor. I think I’m only fully realizing this as I type this response!
So, if I’m reading your response correctly, you’re using indirect labor to accommodate setup times and personnel and using UD fields (on the Job records) to store the information you want to track.
You’re using BPMs to prevent the labor costs from impacting the job cost (and ultimately the cost of the manufactured part) and, then finally, you’re capturing this data via query/dashboard and updating the GL via journal entries.
This is interesting indeed, Sue. Thank you. I’ll run this by Ops Mgmt to see what they think. I like it! Thank you for responding
Addendum: This answers my original post in that it provides for the capture of the data I said I wanted to track. It hadn’t dawned on me that the linkage between the setup folks and Epicor was missing. I have to get data into the system - I’ll certainly be able to track it once that’s done.
That’s one reason I LOVE this group! I don’t know how many times topics on the forum resulted in a “Gee, I never thought about that! That gives me an idea…”.
Andrew,
One additional note for you. @snielsen28 actually provided two solutions in the post. One is the indirect time which will be a record in the LaborDtl table with custom fields to record the JobNum, Assembly, Operation if needed, but definitely the JobNum.
The other solution provided is the one you described, but the UD fields will still be on the LaborDtl table I believe. The fields are different in that they will have labor rate information as the custom fields because Epicor will record the time as Setup and include the Job details in the record automatically.
Finally, your addendum is what I was curious about in my original post. As you said you have to collect the data to report the data, and if you use the second option with the BPM you will have all of the ability to compare efficiencies and other details if it is planned for 2 and takes 3, etc.
