Production Lead Time using Routings
The production lead time if you are using routings in Microsoft Dynamics NAV is the sum of the lead times for the operations that each can have 5 different time components; queue time, setup time, run time, wait time and move time.
In addition to the production lead time is the safety lead time defined on the item or stockkeeping unit card of the product being produced; this adds a slack time between the scheduled ending time for the last operation and the due date of the production order.
The below illustrates the different times and how they together makes up the total lead time on a production order in Dynamics NAV.
The setup time and run time makes up the execution time of a production order and is the time that could affect the cost of the production. The queue time, wait time and move time is sometimes referred to as the interoperation time of an operation and those do not add any costs to the production, they are purely for scheduling purpose.
Below is a description of each of the times and some notes worth knowing. I am using a production order routing for 10 units and changing the different times to see the effect on the operations (I think this is the best way to simulate how the different times affects the routing). The same fields are obviously on the routing attached to the item as well and this is typically where you set things up (instead of modifying times on individual production orders).
The queue time is defined on the work center card in Dynamics NAV and is entered in the unit of measure you specify in the queue time unit of measure code. It represents an expected time that the product wait at a work center before the setup of the operation can start. A queue in a work center is typically used to neutralizing delays in previous operations.
The queue time has no impact on the load of a work center but moves the starting time of the operation forward and therefor creates a gap between the end time and start time of two operations. In our example we have a queue time of 120 minutes on work center 200 which has the effect of moving the starting time to be 120 minutes after the ending time of the previous operation. Having a queue time on the work center for the first operation does not really affect anything since the start time of the first operation is when you start the production order.
Note that the queue time is inside the calendar of the work center.
The setup time for the operation should reflect the time it takes to prepare and setup a job (prior to the process or machine is running). The setup time is per production order and concurrent capacity. Example; if the work center represent employees assembling items and you want two employees to assemble items, then you will have the concurrent capacity set to 2 and the allocated time (expected capacity need) will be twice the setup time since two employees needs to be setup, but it is independent of the lot size (e.g. the quantity on a production order does not affect the setup time needed).
The setup time is defined in the unit of measure entered in the setup time unit of measure field in the routing.
The setup time could be included in the cost calculation if the cost incl. setup is activated in the manufacturing setup table. It is most common to have the setup time included in the cost; at least that is my experience.
The run time should reflect the time it takes to produce a certain quantity specified in the lot size field (also see previous post Production Lot Sizes), it is entered in the unit of measure specified in the routing. The run time is multiplied with the quantity of the production order, if for example the production orders is for 10 units and the run time is 10 minutes per 2 units then the allocated time (expected capacity need) on the work center is 50 minutes (10 / 2 * 10).
If the concurrent capacity is set to something else than 1 (representing multiple machines or employees doing the same work concurrently as described earlier), then the start and end time is adjusted accordingly. Concurrently capacity of 2 will finish the operation in half the time, but with the same amount of allocated time.
If an operation starts before the previous operation has ended then the send-ahead quantity can be used to define that. For example; a send-ahead quantity of 5 means that the next operation will start when 5 units are completed. In the below example 5 units are completed after half the operation (and plus the 120 min queue time on work center 200).
The run time typically affects the costs of the product, which is achieved by specifying costs on the work center card (or alternative on the routing if different cost depending on the routing should be applied).
The wait time is used to specify if the parts needs to wait before continuing to the next operation, something like paint that needs to dry could be a candidate for defining as a wait time. Another use of the wait time is for specifying the lead time for a subcontracting operation (I will probably do a future post about subcontracting operations). The wait time is specified in the wait time unit of measure on the routing.
The wait time does not allocate any time on the work center (it does not affect the expected capacity nor the cost of production). It is also outside the calendar of the work center, even if the work center calendar is setup to work 7 am to 4 pm, an operation with a wait time can finish 8 pm. This is the main difference between the wait time and move time.
The move time is the time it takes to move the material to the next operation; it is specified in the move time unit of measure on the routing. The move time sits between the two operations and is assigned to the preceding operation.
Like the wait time, the move time does not allocate any time on the work center. But it is inside the calendar of a work center (the product will not move itself during the night 🙂 ).
Safety Lead Time
The safety lead time can be defined on the item card or stockkeeping unit card of the product being produced. It moves the production order ending date to an earlier date and is used to create some slack time between the orders (sometimes also referred to as float). If an item or a stockkeeping unit does not have a safety leady time, then Dynamics NAV uses the default safety lead time specified in the manufacturing setup table.
Below is a summary of what functionality in the routing that corresponds to the different times in Dynamics NAV.
Most of the times it is quite straight forward to define the times on the routings when implementing Dynamics NAV, but from time to time it can be tricky to get the system to behave as required. I always simulate the times together with the customers with a sample set of items before applying a setup on a larger set of items (or start migrating routings from an old system).
It’s recommended to choose between hours, minutes and days and keep it consistent. Dynamics NAV allows you to mix the way you want, but there is a risk of making things more confusing/complicated than needed when mixing the capacity unit of measures for different times/routings.
If you select to use days as a unit of measure, then remember that 1 day = 24 hours, and not 8 (working hours).
The above describe a serial operatons where the product travels the same path throughout the routing, Dynamics NAV also supports parallel operations which in my mind is not very common. My plan is to do a future post about parallel operations.
Only setup and run times are reported back to Dynamics NAV when posting the production. My experience is that most companies estimates their times and then uses the estimated times for posting the production (instead of asking their employees/operators to keep track of the time spent). The exception to this is when an add-on for registering starts and stops is used, then you obviously want to capture actual times.