Labor Entry Time Tracking Quantity Only

So we are in the middle of a transition on one production area. We are moving toward tracking our labor with the intention of comparing estimated against actual labor hours. Up until this very moment, we have always setup our operations as Quantity Only method. During my testing, I was able to tell that I could still log hours against an operation and track my actual hours even though we still only accounted for the cost using the quantity only method. This week, we started having the team clock in to each job and then clock out when complete or at the end of the day. We’re getting the data into Epicor now. This is good!

However, now I’m getting asked about how to deduct break and lunch times from those times. Additionally, it’s common for some folks to be logged into multiple jobs at the same time (thus splitting their time evenly between all the jobs). Is there a table I should be looking at other than LaborDtl to get my times for reporting purpose? Is there a good way to discern when to split the times amongst multiple jobs? I have a feeling I’m not getting the full data capture experience because we are not capturing labor using Time and Quantity. Are there pitfalls or other considerations I should know about before changing these operations to be T&Q?

I’d just say don’t underestimate the maintenance burden of clocking in and out of operations. People will consistently miss punches and someone will have to deal with overseeing and cleaning the data if it’s going to be useful. And as you said, how do you deal with lunch breaks and split time? (I know manufacturing consultants can give you good answers for that but it’s still going to increase the complexity of your system)

But it really depends on your company. Some will adapt with ease and some will struggle so badly that the data they capture is useless.

1 Like

I think lunches are automatically deducted if they are set up properly in the shift that they clock into.

As far as breaks, most of the time, I think that is still considered paid time, and as such is just included in what they are clocked into. Will it skew some of the results for actuals vs. estimates? Yeah, but you still had to pay the employee right? So in that sense it should be included. You’ll find that single sample sizes aren’t good anyways and trends need to be averaged out over more that a single occurrence, so break time should be included. It should also be included in the estimate. So if you do a time study and get 3:30 per unit per operation, you can’t expect someone to consistently hit that anyways. Generally industry standard is to add 10-20% to time study times to account for breaks and interruptions. Otherwise you’ll find you will just always fall behind and never be able to catch back up. A human being can’t run at 100% capacity constantly, so they shouldn’t be judged that way.

My 2 cents.

2 Likes

@TomAlexander and @Banderson - thank you both for your thoughtful input. I was looking for where the lunch was managed - I saw that it was there in Time and Expense but wasn’t sure where it was coming from. Now I know. At the same Shift maintenance you can also add breaks. I know that it may be advised against, but I wanted to put it out here if someone else stumbles across this. I am worried about the burden of maintaining the entries also. I guess we will have to see how bad it gets.

That’s interesting, I didn’t realize that was in there! Good to know if i ever do need it.

Another thing that has come up this afternoon that I didn’t realize was going to be an issue… but when they go to log in, they have to enter their Shift the very first time. I had originally thought they could leave themselves “clocked in” indefinitely and freely able to log in and out of new job/operations each new day. However, I’m seeing in Time and Expense how all the detail records are children of the head record from the first day they were clocked in. Do you know of any smarter way to manage this? I’m not opposed to having them clock in each morning and enter their shift and then clock out at the end of the day… but I want to make sure there isn’t an easier way. Like you were saying there is a burden to maintain things this way.

I don’t know of a better way, but I am much more of a technical person than a manufacturing/functionality expert… I just know that I’ve seen a ton of development requests over the years in this area and the common theme is “please add code to make this whole thing easier for us”. So some updatable dashboards here and there, some BPMs, customizations, etc. It often leaves me thinking “this is a mess, why are they even bothering?”.

I hope I am not scaring you away or sounding alarmist though, plenty of companies manage okay, I guess I’m just trying to say it’s not for everyone. It would be a mess at my current company for example. We are mostly Quantity reporting only, but are starting to shift to time reporting in some areas. This is just a user reporting time for the final op though, not clocking in and out. We see this as a middle ground to experiment with before potentially considering clock in clock out in the distant future…

1 Like

Yeah I appreciate the feedback either way. I have also seen a lot of those types of requests and wondered… why is it so hard to just have the people clock out at the end of the day? Haha now I get it.

If you aren’t using those times for payroll, you have a little more flexibility so you can do auto clock outs and if it’s not right, it’s just a data issue and not a paycheck issue. So you can build something to click everyone out at the end of their shift and then you wouldn’t have to worry about them forgetting. (A function on a schedule here would work great.)

But yes, keeping the child records until a single header for weeks in end causes LOTS of issues, and won’t work.