To analyze the model, select the Production System Analysis button. When the calculation is complete, a new window will appear with the results page of the analysis.
Any warnings with data entry will be listed in the Notifications pane that will appear at the bottom of the UI. Warnings will also appear at the top of the results page. Another indication of errors in data entry is a results page that has charts missing and/or skewed to the right. If this happens, review and correct the list of notifications. Note that some notifications are to inform or warn the modeler and are not a sign of an error in data entry that needs to be corrected.
If all data was entered correctly, the results page should resemble the following. At the top of the results page, the system will provide a list of warnings indicating that one or more resources has a capacity utilization greater than 100%. This is to be expected, given the inputs to the model that have been provided. This condition will be used for model interpretation.
By default, the results will open to a summary page where the analysis of all product flows are displayed. At the top of the page, there is a drop-down selection where the user can select to view the results of individual product flows. Each product flow defined in the model will appear in this list.
Capacity Utilization
The first visual illustrated in the results page is Capacity Utilization. Capacity utilization is the proportion of time that a process center in a production system is not idle. Utilization is calculating by dividing the amount of time a process center spends working in a period (e.g. day, week, month) by the time the process center has available to work during the same period.
Consider a process center that is actively working for a total of 6 hours in each 8-hour day. Utilization would then be calculated as 6 hours divided by 8 hours or 75%. Utilization can also be calculated by dividing the rate of arrivals to a process center by the effective rate of the process center.
Average Capacity Utilization is an indicator of a production system’s ability to produce to a given demand. When average capacity utilization exceeds 100%, the rate of demand is greater than the system’s bottleneck can operate. Thus, an increase in capacity is needed. “Average” indicates that over time, utilization of a process center will sometimes be higher and sometimes lower. As Average Capacity Utilization approaches 100%, therefore, the chance that a delay, breakdown, or other unexpected variation in the process will result in a Utilization of over 100%. Because of this, it is advised to bring Average Capacity Utilization below 100%. How far below depends on the risk a company is willing to take on as well as the amount of expected variation in the system.
In the Airplane Assembly model just built, workstation 4 has a capacity utilization of 119.05%. This indicates that no matter what else happens, the target demand will never be fulfilled because the system lacks the capacity to do so. A minimum of 19.05% increase in capacity would be required at workstation 4 in order to meet the target demand of 10 airplanes per week.
When average capacity utilization reaches and exceeds 100%, queue time goes to infinity. Therefore, capacity utilization at the WS-4 bottleneck must be reduced below 100%. This will be done by increasing the rate at the Install Engines process step from 0.05 to 0.0625. Later, the various means to increase capacity will be discussed. Change the process rate of this process step and then press the Production System Analysis button. The new utilization plot is shown below.
Flow Performance Plot
The purpose of the Flow Performance plot is to illustrate how a production system performs with varying levels of WIP and enable an organization to set policy decisions that deliver maximum throughput with minimum cycle time.
The plot has 3 axes, Throughput and Cycle Time and WIP. The minimum and maximum bounds of each axis can be adjusted by using the slider bars below the table and by adjusting the “Plotting Parameters” values located within each Product Flow table in the modeling user interface. Flow performance plots do not always generate nicely with the default values for Plotting Parameters, so the modeler will need to adjust them from time to time. As a rule of thumb, set the plotting parameters for WIP and cycle time to be 3 times that of Push WIP and Push cycle time in order to generate a nice-looking plot.
The flow performance plot is interpreted as follows. First, for any number of WIP the plot shows the best possible throughput and cycle time that the production system being modeled can achieve. Best case throughput increases in a linear fashion until a certain level of WIP is in the system, then the throughput flattens out. This point is called Critical WIP. The same behavior is evident for best-case cycle time: cycle time is flat until Critical WIP, then increases linearly with increasing WIP. Both of these lines indicate system performance that improves with increasing WIP until a specific point. From there, system performance gets worse by adding more WIP into the system.
Furthermore, best-case throughput and cycle time only exist in a system with zero variability. Eliminating variability altogether is impossible, so the true performance of the system will be bounded by Predicted Throughput and Predicted Cycle Time. The more variability in the system, the further the predicted throughput and cycle time will be from the best-case curves (i.e. predicted throughput moves down and to the right and predicted cycle time moves up and to the left).
Each system has a demand that must be met in order to satisfy its customers. Daily demand, taken from the item table(s), is shown as a dark green horizontal whose value is read from the Throughput axis. In order for a system to meet its demand, the capacity must be equal to or greater than demand. This means, the capacity of the bottleneck (the bottleneck rate) must be greater than the demand rate.
The point at which demand and predicted throughput intersect is marked by a vertical line called the Minimum WIP (Min WIP). Min WIP represents the minimum level of WIP needed in the production system in order to meet demand. Any less throughput and production will fall behind. Any more, and cycle times for each part will increase and production delays may follow.
Push WIP represents the average amount of WIP that the system will experience over the long term when releasing work into the system at the rate of demand. Depending on the system characteristics, the Push WIP line and the Min WIP line can be on top of each other or be spaced apart. Large batches, rework, and defects all increase variability and result in moving average WIP (Push WIP) farther away from Min WIP.
We know from Operations Science, that WIP drives cycle time. WIP also has an impact on how much throughput a system will get. Therefore, controlling WIP at an optimal level is critical for ensuring a production system produces optimal results.
A common misconception is that Min WIP = Optimal WIP. Setting a policy to control WIP at the Min WIP level is risky. If the system experiences variability (which all do) and WIP falls below the Min WIP level, the system will experience a loss in thoughput and the organization falls behind. However setting a policy too far to the right of Min WIP can increase cycle times too much resulting in slower response times and potential production delays. Setting the WIP level has tradeoffs and must be decided considering how buffering with WIP affects the organization’s objectives.
Once a desire WIP level has been chosen, it can be controlled through various protocols. The most robust of which is called CONWIP, which stands for Constant Work in Process. A constant level of WIP level is maintained by starting new work only once the level of WIP across the routing/product flow falls below the target level. In this situation, average WIP the system will experience over the long term is at the CONWIP level, not Push WIP like mentioned above. The key difference is that with CONWIP, work is released into the system based on the WIP policy, whereas with Push, work is released into the system based on a schedule (i.e. demand).
Flow Performance Table
The Performance table organizes all the important information in the flow performance plots into tabular format. Each row in this table represents the results for a single product flow. As more product flows are added, more rows appear here. Following are descriptions of each of the elements in the table.
| Data Element | Source | Description |
|---|---|---|
| Throughput | Input by User | Daily demand of each product flow |
| Average Batch Cycle Time | Computed | The average time in days for one batch to transverse the system. |
| Bottleneck Rate | Computed | The maximum capacity of the production system being modeled. This is the rate of the bottleneck resource with 100% capacity utilization. Current demand shows the pull on the system as defined by the bottleneck. |
| Raw Process Time | Computed | The average time in days for one item to transverse the system. |
| Min WIP | Computed | The minimum level of WIP needed in the production system in order to meet demand. |
| Min Cycle Time | Computed | The cycle time for one batch with WIP in the system equal to Min WIP. |
| Push WIP | Computed | Push WIP represents the average level of WIP that the system will naturally gravitate towards over the long term if no WIP policies are set in place. |
| Push Cycle Time | Computed | The cycle time for one batch with WIP in the system equal to Push WIP. |
| CONWIP | Input by user | Value set in each product flow menu. Used to test the impact of an individual CONWIP level on Throughput, Cycle Time and Bottleneck Utilization |
| CONWIP Throughput | Computed | Throughput of the system with a CONWIP policy equal to the quantity set in the product flow menu. |
| CONWIP Cycle Time | Computed | Cycle Time of the system with a CONWIP policy equal to the quantity set in the product flow menu. |
| CONWIP Bottleneck Utilization | Computed | Utilization of the bottleneck with a CONWIP policy equal to the quantity set in the product flow menu. |
Cycle Time Analysis
The first part of cycle time analysis is organized by Product Flow. Notice how a CONWIP level of 20 is less than the Push WIP of 88.27. Using the Flow Analysis curves, observe how less WIP provides the system with lower cycle times but also lower throughput. With a CONWIP of 20, the system will fall behind production needs by 0.33 planes each day. If CONWIP is to be implemented, it will be wise to increase from 20 to something greater than the Min WIP.
Important Note: if there are multiple items in a product flow, the values for average throughput, WIP and cycle times are weighted by the demand of each item.
Cycle Time By Product Flow
| Data Element | Source | Description |
|---|---|---|
| CONWIP | Input | Value set in each product flow menu. Used to test the impact of a specific CONWIP level. |
| CONWIP Throughput | Computed | Throughput of the system with a CONWIP policy equal to the quantity set in the product flow menu. |
| CONWIP Cycle Time | Computed | Cycle Time of the system with a CONWIP policy equal to the quantity set in the product flow menu. |
| PUSH WIP | Computed | The expected average WIP in the product flow |
| PUSH Throughput | Computed | The expected average throughput of the product flow. This is also equal to the demand rate if capacity utilization of the bottleneck is not > 100%. |
| PUSH Cycle Time (Days) | Computed | The expected average time from when a transfer batch is released into a product flow to when it exits |
| PUSH Cycle Time (Hours) | Computed | Same as above but translated from days to hours |
| PUSH Raw Process Time | Computed | The sum of average time required to process a single transfer batch including all detractors such as downtime and setup time |
| PUSH Queue Time | Computed | The average length of time an item is waiting for capacity |
| PUSH Batch Time | Computed | The time items spend waiting due to batching and is composed of Wait-to-Batch Time and Wait-in-Batch Time. Wait-to-Batch Time is the time jobs spend waiting to form a batch for either (simultaneous) processing or moving. Wait-in-Batch Time is the average time a part spends in a (process) batch waiting its turn on a machine. |
| PUSH Move Time | Computed | Time that a transfer batch of an item spends moving from one station to the next, including the time spent waiting to move |
| PUSH Shift Differential Time | Computed | The time that parts or tasks spend waiting for processing or to be moved due to different resources working on different schedules. |
Cycle Time by Item
The second Cycle Time Analysis depicts cycle times of each item, rather than the times aggregated across product flows. This table also indicates the proportion of each cycle time element in overall item cycle time. This can be used as a quick way to identify items experiencing large queue or batch times.
| Data Element | Source | Description |
|---|---|---|
| CONWIP Cycle Time (Hours) | Computed | Same as above but now calculated by item |
| CONWIP Cycle Time SD (Hours) | Computed | Standard deviation of the CONWIP cycle time of the item |
| PUSH Cycle Time (Days) | Computed | Same as above but now calculated by item |
| PUSH Cycle Time SD (Hours) | Computed | Standard deviation of the PUSH cycle time of the item |
| On Time Delivery (%) | Computed | The percentage of deliveries of complete products which are predicted to occur within the deadline under the PUSH methodology. |
| Planned Lead Time (Days) | Input | The time planned between a new order for a part and the furnishing of that part. |
| Replenishment Time (Days) | Computed | The time between an item’s selling and its replacement in stock, under Push methodology. |
| Cycle Time Components (Hours) | Computed | Same as above but now calculated by item |
| Cycle Time Components (%) | Computed | Proportion of each cycle time component in overall cycle time |
Capacity Analysis
This table analyzes the capacity of each process center and its impact on variability, queue time, and WIP. Process centers with high capacity utilization will have larger queue times and greater amounts of WIP. Process centers allocated to process steps with high SCV for process and setup times will have larger SCVe which will contribute to larger queue times and WIP. Process centers used in routings with large batch sizes will have larger values of SCVa and SCVe and will have larger queue time and WIP.
| Data Element | Source | Description |
|---|---|---|
| Process Center | Input | Process centers defined in the model |
| Number of Machines | Input | |
| PC Util (%) | Computed | Process Center Capacity Utilization. This represents the proportion of time the resource is not idle. |
| SCVa Batches | Computed | Squared Coefficient Variation for arrivals to the system, or the variability in the rate of arrivals |
| SCVe Batches | Computed | Squared Coefficient Variation effective, or the variability for process times |
| Mean Time 1 Batch (Hours) | Computed | Average cycle time for a single batch of WIP seen at each process center |
| Queue Time (Hours) | Computed | The amount of time a single batch spends waiting for a resource |
| Queue Time Std Dev (Hours) | Computed | Standard deviation of queue time |
| WIP | Computed | The average amount of WIP that will be built up in front of each process center |