Say we have an operation that takes 18 minutes to run 1-20 parts, (that is for any qty from 1 to 20 takes 18 minutes to run). For every interval of up to 20 parts we need to add an additional cycle. A cycle must complete and cannot stop part way (If a cycle is required, it will take 18 minutes). That would mean there are 3.333 cycles per hours and 20 pcs per cycle.
So say we have a job for 19 parts, that would require 1 cycle so 18 minutes, so I would expect an estimated production time of .3 hours (18/60 =.3), What Kinetic appears to calculate is .29 (19 / 20 * 18 / 60 = .285 —> Rounded up to .29)
Now say we have a job for 21 parts, that would require 2 cycles of 18 minutes (36 mins total), so I would expect an estimated production time of .6 hours (36/60 = .6). What Kinetic appears to calculate is .32 (21 / 20 * 18 / 60 = .315 —> Rounded up to .32). This results in an estimate thats almost half the time actually needed.
Is there any way to get Kinetic to report an entire cycles worth of time here?
There are two Standard Format options that aren’t described in the Help but exist in the dropdown… Cycles/Minute and Cycles/Hour. If you select either of those options, a field opens up on the right of the window for Pieces per Cycle.
Yep, Cycle/Hour is the thing I’m talking about that does the calculation “incorrectly”. It’s not giving times that are intervals of the cycle time, it’s just doing the calculation per the qty. Per KB0118564:
Cycles/Hour = (RunQty / ProdStandard / QtyPerCycle)
How I would expect this to calculate:
Cycles/Hour = (Ceiling(RunQty/QtyPerCycle)/ProdStandard)
I’ve made a BPM that makes this adjustment on the Job side, but because the data in quotes is calculated on the fly, I’m struggling to find a way to fix this for quotes.
Maybe it’s just our industry, but several of us here have thought about it and are struggling to find an application where you would want to have partial cycles like how this behaves. As it stands, Cycles/Hour is basically Pieces/Hour as they both calculate out the same.
I was told:
“The calculations and resulting values are as expected given the base functionality of the application. The calculation for the estimated hours are always based on the run quantity for the operation.”
