At What Point are Cycle Times Determined?

[Neil V.]

I've been asked to address a few recurring issues here at work. Please bear in mind this question relates to a 'family' of parts only - short run, job shop type parts. We run two systems, one for those requiring TS or ISO9001 and another for the short run/spot buy stuff.

Main Internal Management complaints are 1) that engineering misses the mark on our cycle time estimations and that 2) engineering provides manufacturing incomplete/inaccurate information (including aspects related to the mfg print and/or the traveler or router).

The feeling I and others have is that we are too lax during APQP. Reality is that for this short-run job shop type work APQP is pretty non-existent.

Having said that, I see the APQP manual mentions in Appendix A, A3, line 12, ensuring we have capacity to handle forecasted production volumes. Surely capacity is related to the part cycle time, which we make educated guesses at during quoting. However, we don't get the chance to do prototype or pilot runs and thus don't get the chance to actually see how long it takes to run so there is the risk of shipping late.

My questions then, in a round about way:

Do you consider cycle times a direct output of APQP? If so, at what point in the APQP process are they usually identified?

Or perhaps APQP is concerned only with capacity, and cycle times should be treated only as an input into scheduling....

Any suggestions on how we could address the issue of improperly identifying cycle times for parts yet to be run?

Any thoughts or advice will be greatly appreciated as I try to come up with an improvement plan! Thanks!

 

[Stijloor]

<snip>My questions then, in a round about way:

Do you consider cycle times a direct output of APQP? If so, at what point in the APQP process are they usually identified?

Cycle times should be calculated and available as early in the (APQP) process as possible because they are needed to assess feasibility. You can not commit to a Customer order if you can not predict the requested delivery times. A serious issue in automotive land...

If you Google "cycle time calculation", there are quite e few of calculators you can download. I have not tried them, so user beware. "Lean" obviously, is also very concerned about cycle times. Historical information can also be used to make fairly decent cycle time estimations.

Or perhaps APQP is concerned only with capacity, and cycle times should be treated only as an input into scheduling....

APQP is concerned with all planning steps; from the initial contact with the Customer, all the way to delivery and obtaining Customer feedback.

Any suggestions on how we could address the issue of improperly identifying cycle times for parts yet to be run?

First of all, get these folks on board soon, because any effort without their input/involvement is doomed to fail.

Any thoughts or advice will be greatly appreciated as I try to come up with an improvement plan! Thanks!

I tried.

I hope others will chime in.

Stijloor.

 

[reynald]

Any thoughts or advice will be greatly appreciated as I try to come up with an improvement plan! Thanks!

Well here is a thought...

Have all the historical processes broken down to as much details as possible (load, walk, unload, wait, machine, etc..) and then measure the time it take to complete each step. Then if you will have a new process this too can be broken down into considerable detailed steps. You can then estimate the time it would take to perform each step by comparing it to the details of the past processes. Now to predict the cycle time, add up all the times for each step of the historical process. The method is described in details in this book by Niebel, browse at chapter 13 (Predetermined Time Systems).

Regards,
Reynald

 

[trainerbob]

I had a situation that was quite similar to yours. I inherited part of an organization that did small runs of unique parts. Production was not meeting the estimates that all bids were based on. For reasons that are too long to go into I found that the estimator had bad information and poor training.

I resolved the issue by getting a person from the production floor to collaborate with the estimator in doing the bids. This combined experience gave us realistic estimates that production was able to meet and therefore do a better job of satisfying our customers.

Our estimator improved, our efficiency improved, and our customer satisfaction improved.

This may not be possible in all situations, but it worked very well for us.
It may be something you can consider for your organization.

 

[Stijloor]

I had a situation that was quite similar to yours. I inherited part of an organization that did small runs of unique parts. Production was not meeting the estimates that all bids were based on. For reasons that are too long to go into I found that the estimator had bad information and poor training.

I resolved the issue by getting a person from the production floor to collaborate with the estimator in doing the bids. This combined experience gave us realistic estimates that production was able to meet and therefore do a better job of satisfying our customers.

Our estimator improved, our efficiency improved, and our customer satisfaction improved.

This may not be possible in all situations, but it worked very well for us.
It may be something you can consider for your organization.

Excellent suggestion!

Talking with people who do the real work. In addition, historical process information is not collected, analyzed, and used to its fullest potential. Another underutilized resource.

Stijloor.