Production Job Repairs

Hi,

There are a number of posts about how Epicor handles subassemblies that fail testing and need to sent for repair before being reintroduced to the job.

Whilst the DMR process is quite cumbersome, I think it is workable for small volumes, so I’m happy to go with this as a means of recording fails and reintroducing repaired subassemblies back to the job.

The one thing the DMR process doesn’t do is capture the repair labor against the job.

Does anyone see any potential issues in getting the person carrying out the repair to log onto the main operation to select ‘Repair’ as the resource and instead of taking the default resource on the ‘Start Activity’ screen (e.g. soldering). Thus I can capture any repair labor separate from normal production labor against the relevant operation.

From a costing perspective all the labor is captured.

Thanks,

Andrew.

For us this was far too cumbersome, not least folks having to find job numbers/route cards for parts sent back from other processes meant it would never happen and often the operator is doing the rework without a DMR/quality involvement in real time - "that paint needs touched up, I’ll do it now. "

We just created three rework jobs for the ops where we have rework - the three are simple rework (10 minutes), medium rework (30 minutes) and complex rework (60 minutes) - jobs are due in 2199 and have 100,000 parts on the job. Jobs are quantity only and employees just report the quantity - if they want to report 20 minutes they just book a quantity of two to the simple rework job and 20 minutes labour is recorded against it. Job numbers for rework are printed and stuck on data entry station. Employee is required to enter something in the notes for traceability

Good thing with this is that it can be done if parent job is closed and also retrospectively. Just tailor any rework reports to look at these jobs and you can get your high level rework cost for an operation for a day, month year etc.

What you are suggesting will work and will give granular traceability but I was wondering why you don’t just use the start rework activity option on the MES - route card/transactional indiscipline were barriers for us - as it reports the labour as type rework?

Thanks James.

I’m at the stage of considering all options, so your suggestions are appreciated and I will certainly present it as an option.

Rework is a good option, but I think I’m going to have to add another level of fault reporting on the end activity screen for reporting purposes.

Thanks again,

Andrew.

I’ve seen a couple different things work.

  1. There is a rework reason code that you can set the GL controls on.
  2. You can also add resource groups specifically for the rework that get the costs to the proper department and can omit burden if desired.

Doing generic rework jobs doesn’t always flow the costs the way you want (e.g. how much does it really cost to make this part, including rework). With high DMR occurrence on a part, setup a job with that part # and disposition DMR parts to the job as they come up. That way you can rework several on the same job with only 1 clock in. With lower occurrences, you can add a rework operation to the job. You could either set fixed time if you don’t know how long rework takes, or setup quantity only with an estimate just to get closer on costs.
Jenn

We added a custom field to the end production screen pointing at the labor notes on the operation - as it is a generic rework job there is typically no notes for the transaction - folks capture the part number and detail of the fault/action taken.

Jenn you are right Epicor is highly granular for rework reporting but I think it depends on how robust data collection processes and disciplines are and also how granular the level of reporting.

For us a high level of detail was never going to work primarily as we just needed a cost and given transactional discipline is very poor and a few folks have a shaky grasp of English, giving folks too many decisions to make mean they were never going to do it. We came up with something simple that can be done well after the fact - quality team can do the transactions retrospectively.

I have been through the options with the super user and we have decided to trial the DMR process. The basis for this decision is that there are not that many repairs and the labor cost is not really that relevant. The key thing is to be able to tack repairs and enter reasons against the cause and corrective actions.

It’s only a trial at the moment - so as the saying goes - time will tell.