Every business can be improved and efficiency increased. One method to identify ways to make your business more efficient is to evaluate the “process flow” you use to produce your business “output,” whether your output is a product or a service. There are several components to this analysis and I will walk you through a fairly straightforward method to identify bottlenecks and increase capacity in your own processes.

As an example of this process, let’s consider the example of a pizza shop. A pizza shop sells its delicious, hot, and cheesy products to customers using the resources they have assembled to do so. In this case, those resources include the workers, the raw supplies, and the equipment necessary to produce that yummy thing. The question is how to go about looking for inefficiencies in the process which, when corrected, can allow a higher rate of production while utilizing fewer resources?

The answer? Capacity analysis. This problem-solving approach has several components which should be considered when examining a process:

1. Throughput, or the average flow rate of a process (i.e. how many pizzas can be produced in one hour),
2. Resource pools, or the interchangeable resource units that can perform an identical set of activities,
3. Unit load, as measured in time per flow unit (for example, how many minutes it takes to prepare the dough for the pizza),
4. Load batching, or the ability for one resource to process several flow units simultaneously,
5. Scheduled availability, or the total hours that a resource is available for use (e.g. a pizza chef works an 8 hour shift, five days per week), and finally
6. Theoretical capacity, or the maximum potential flow rate of a process based on the above combination of factors.

First thing to consider is “Flow rate measurement.” which can be expressed in the number of flow units per unit of time. For instance, how many pizzas does one shop produce in an hour? The average current flow rate can be determined by observing a process over a period of time and measuring the number of units that ass through the process. Computing the average number of flow units per unit of time is a simple step. For instance, if our pizza shop produced and sold 600 pizzas over 8 days, and each day consisted of 10 business hours, we can easily determine the flow rate to be 564/(8*10), or 7.5 pizzas per hour.

The maximum flow rate would be the number of “potential” pizzas which the shop could produce if it were using its resources in the most efficient manner. This number will of course be limited by the resources involved (i.e. how many cooks work a given shift, how many ovens are utilized, and how many customers can be served in a given 10-hour day).

The most important step is to determine the theoretical capacity of our pizza shop, and, in turn, identify the current “bottleneck” in the process. We can do this by analyzing all of the available resource pools (pizza chef, oven, order-taker/cashier, etc) to determine the theoretical capacity of each. This analysis will allow us to identify the bottleneck, or the slowest of the resource pools. Remember that the total theoretical capacity of our pizza shop is the maximum flow rate if all of the resources were being fully utilized. Therefore, capacity will be defined by (and limited to) the throughput of the slowest resource pool in the process.

Let’s start with one resource pool (the oven) and a simple computation which we can use to determine the Unit load for this resource pool. The oven is large enough to cook 5 pizzas simultaneously, therefore the “batch” size is equal to 5. Let’s say that it takes 15 minutes to bake a pizza, therefore the capacity of the oven will be:

If we do the same for our other resource pools, we can easily identify the slowest of these and, bingo! Our bottleneck is magically revealed! Let’s take a look at the other major resource pools, starting with the pizza chef. The chef has a number of activities which take up his time: preparing the sauce, spinning the dough, assembling the pie,  and loading it in the oven. Let’s assume that sauce preparation for a batch of five pizzas equals 4 minutes, that prepping the dough for those same 5 pizzas equals 10 minutes, that assembly takes another 5 minutes, and that loading takes 1 minute more. The total for the chef to produce one batch of 5 pizzas adds up to 20 minutes. The pizza chef unit load calculation would look like this:

The final resource pool is the order taker/cashier. Let’s assume that this worker is also responsible for removing the pizza from the oven, boxing it up, ringing the order and taking payment. Here’s how it breaks down: Unloading/boxing takes 1 minute per batch of 5, and payment takes 3 minutes per order. The cashier’s process takes a total of 4 minutes, and the unit load calculation would be:

The culprit here? The pizza chef, who is clearly the bottleneck and his productivity limits the total theoretical capacity of the shop to 150 pizzas per day. If we could improve the throughput time for the tasks performed by this resource, or reassign the tasks so that they are shared among the other resources, we could increase the theoretical capacity of the entire operation. Next week we will discuss some ways in which we might tackle that problem. Until then? Ooops. Sorry, gotta run. The doorbell just rang and my pizza is here!

(You can read part 2 of this post by clicking here)