Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

STD Time Accuracy vs. Precision 1

Status
Not open for further replies.

TonyE

Industrial
Feb 24, 1999
4
US
Given a variety of products that are similar in their routing, but may have slight differences, what 'precision' is required for each product in the group of items for their run-time? Obviously, the group of products, if given ONE standard time for the group, will lose visibility to cost differences. However, if each product within the group is given a unique time to show the real difference in run-time, it becomes difficult to manage. Can someone give some advice as to logic that can be applied?
 
Replies continue below

Recommended for you

Can you break up the routing so that you keep a core one for all the similar operations, and make smaller, modualr routings for the different ops? That way you only have to add onto your core routing if needed, instead of creating a new one for each different product. For example, product XYZ has two routings: op 10 (core)+ op 20(modular add-on.)
 
Actually, my question isn't relative to the routing structure, yet the STD time associated with the operation itself. Perhaps my question wasn't worded very well. If we had 20 products that were similar in nature, but varied in operation time from 4 hours to 5 hours, would putting a SINGLE standard 'weighted' by volume for ALL 20 products be better than 20 different standards that only vary 5-10 mins or so each. The issue here, is to how many products should I apply a SINGLE standard time while sacrificing the precision of the standard?
 
Would it be possible to assume linearity among your products? If product know A has 1 feature and takes 1 minute, while product Z has 26 features and takes 26 minutes, can you say with "reasonable" accuracy that product J will take 10 minutes? This way you would not have to spend an enormous amount of effort in time studies. In addition, it would not mask problems or create them where they don't exist. You could have a much better basis for improvements in labor, machine hours, and setup time.
 
I have had a similar problem to this. The answer depends upon a few things. First of all, three reason for have a "STD" time are to measure performance, schedule, and to estimate cost. Depending upon the degree of "control" needed, will determine what level of accuracy will be required. For example, if scheduling is based upon a volumetric basis and not an hour basis, then detailed accuracy is not needed. If employee measurement are based upon total performance and not individual part performance, then detailed accuracy is not required. If the "run time" cost are a relative small amount in regards to the total, then detailed accuracy is not required. If further evidence is required, try to "quantify" the accuracy level required. One method is to estimate the cost that would be incurred for setting the detailed standard versus the expected change in unit cost. If the benefit is low, then it is not worth to do (Amortizing it over the production volume may be tricky)<br>
I hope this helps you.
 
I may have followed the thread wrongly,&nbsp;&nbsp;but maybe the solution may not be to either measure the standard time or the volume, but to compare the production rate with a standard proven rate....<br>you may find then that the products that look very similar when based on time standards suddenly become completely different when based on rate, 1 min lost on one product may cost differently to another.<br>Also this means that if you are manufacturing 'any batch size' rather than standard sizes every time, your standards will still be relevant and won't have to be recalculated everytime you change the batch size.<br>Does this help?
 
Thanks, Gary!!!!!&nbsp;&nbsp;That helps...&nbsp;&nbsp;Sorry it took so long to reply, but been soooo busy!&nbsp;&nbsp;Thanks, everyone!!
 
Status
Not open for further replies.
Back
Top