In the module of customer choice, and product variety, we already introduced one tool that helps us tame the evil forces of variability. We introduced the concept of pooling. The purpose of this session is to help you think about pooling benefits in the context of waiting time problems. We will use our waiting time formula to estimate savings in terms of waiting times that you can achieve by introducing pooling to your service. We talk about some practical examples and explore the main benefits and costs that are associated with pooling and waiting time problems. Consider the following two process layout. In the first example, option number one, I have two waiting lines for two doctors or for two servers. People that come to this server have to be served by this server and people who come to the other server have to be served by the other server. Contrast this with the example of a pooled service. In the pooled service, no matter from where you come in, you're going to get served by whoever is available next. Which one will have the shorter waiting times? Most of us I think have an intuition that this process here will have a better waiting time. I would argue the intuition behind it goes something like follows. In the example up here, you might end up in a situation where we have a lot of people waiting in the upper case and you have a doctor idle here in the lower case. As a result of that, that cannot be efficient and that's what this pooling addresses in this system down here. Now, let's understand how this relates to our waiting time formula. First and foremost, let's see how it influences utilization. Recall that utilization is P divided by eight times M. In our example here we have, again, customers come in every four minutes, and the inter-arrival time is five minutes. With M equals 1, we simply get 4 divided by 5 equals to 80%. Now how does it look down here? If I pool two such systems, I have no impact on the processing time, however, I have now a shorter inter-arrival time. I here had 12 customers arrive per hour. If I pool, I have to have 24 customers per hour showing up. So pooling at least two similar systems, I move from 12 to 24 customers per hour, meaning an inter-arrival time from five minutes to 2.5. And notice oftentimes students get confused on this point. A shorter inter-arrival time means more demand. Finally I have an M=2, M =2, P= 4, A = 2.5. If I plot this into the formula, P divided by A times M, I'm going to get a utilization of 4 divided by 2 times 2.5. And voila, it's the same 80% as I had before. So pooling in and by itself actually does not change the utilization, but it will impact the waiting time. Let's try this out in our Excel spreadsheet. I'm using the same Excel spreadsheet that I used in the last session. We have P the processing time, inter-arrival time, number of servers, CVA, CVP, the utilization is defined by P divided by A times M, and finally the actual waiting time. All right, now let's take a look. Processing time stays unchanged. Inter-arrival times, if I basically pool two similar servers with the same demand rate together, I've cut the inter-arrival time in half, however the server capacity doubles because I'm moving from m=1 to m=2, and everything else is a matter of calculation. Notice as we saw on my calculations on the previous slides, the utilization does not change, yet the time in the queue does. The average time in the queue goes down from 16 minutes to 7.2 minutes. This is the power of pooling applied and queuing. Let me point out though that when you pool you don't necessarily have to assume that the inter-arrival times are going to be exactly identical and so that the new inter-arrival times are simply cut in half. More generally, the way that you're going to figure out the new inter-arrival times is by just adding up the demand rates and then dividing 60 minutes by the new demand rate in customers per hour, and that gives you the new inter-arrival time. Earlier in this session I discussed how the utilization drives up the waiting time. We noticed that as the utilization approaches 100%, the waiting time really goes through the roof. I've taken the waiting time formula, and I've plugged it in Excel, and then I've entered various levels of utilization, so this is the more exact graph that I should have showed you earlier on the previous slide. Now what you notice here is that as you're increasing the utilization, indeed the waiting time goes up very steeply. However you notice that while for an M=1, already an 80% utilization is quite a steep increase for every additional unit of utilization added. At an m=10, you can safely keep on adding additional units of utilization. So this is really the effect of pooling at work. Pooled systems are much more able to be loaded to very high volume without really experiencing the steep increase in the waiting time. One nice way of illustrating this is thinking about the trade-off here when designing the service. We have to balance the forces of responsiveness and efficiency. Now responsiveness means the service is responsive, and the time in the queue is short. High time in the queue, we would say the service is not responsive. Efficiency we can proxy by utilization. High utilization is typically a more efficient process than a low utilization. As we have seen previously, by changing the staffing plan, by adding more workers, I can move from the lower right to the upper left. So a change in staffing extra "M" number of workers will increase the responsiveness but it comes at the expense of the efficiency. Now, notice that when we pool the system however, we keep the utilization constant, and we're moving to a new frontier. Now oftentimes I get asked what is a good utilization to have for a service. The usual academic answer is, well, it depends. If you run a fire truck, I'm not sure that you're comfortable running it at a 50% utilization. The response time is simply too long given the urgency of a fire. On the other hand, if you're running the local cable company, and you're the only game in town, well, you can afford to run a 99% utilization if customers wait for 3 months for their cable TV but there's really no threat of substitution. So you notice again where you position yourself on this line, there's no right or wrong. That is a choice of strategy. Choose between being the fire truck that is up here or the local cable company that is down here. Clever system design, however, shifts the frontier and benefits you either way. If pooling is really that great, why don't we pool everything? Consider a company that is operating call centers in Germany, France, and Spain. How about pooling? Well the problem is that the Spanish customer service representatives might have a hard time dealing with these German customers, so in other words pooling really assumes a form of flexibility, that every resource is able to serve every customer. That is a very strong assumption. Second, pooling also complicates the work flow. The most prominent applications of pooling have been with help desks in call centers. Here we're dealing with digital work flows. Since transportation is cheap in the digital world, pooling around the globe is very simple. However, you obviously do not want to pool the primary care capacity of a health care operation that has facilities in Philadelphia and Pittsburgh. It's a little too far to drive five hours to see your primary care physician. This gets to another disadvantage of pooling. Pooling really interrupts the continuity of interaction between the flow unit, the customer, and the resource. Do you really want to be seen by a different doctor every time or talk to a different agent in your bank every time that you come? Pooling assumes that you're going to see whoever is available next, not whoever you're used to serving. This can hurt the customer experience, but it can also lead to additional set up times because the person who was serving you and who has never served you in the past might just not be as sufficient as your usual provider. Classic examples of pooling have been in the area of health care where we have seen a strong trend towards group practices and larger healthcare systems instead of the solo doctor offices that we saw 50 or 100 years ago. One of the hottest areas of work right now is in the energy field. The problem of pooling is that the supply and demand of energy varies widely across the country. So if we're able to pool, through a smart grid, our electricity, we're going to be able to get much higher utilization levels and still provide the same quality of service. Notice the idea of partial pooling that we talked about in the context of flexibility and production plants. We talked about how in the automotive industry, some companies including Nissan have been able to really, instead of having every plant be able to produce every vehicle, be able to have every vehicle be produced in two plants so then we can get almost all the benefits of pooling without paying all the costs. When I introduced a concept of pooling in the last module, I mentioned that pooling is probably one of the greatest insights from the field of operations management. The reason for that is pooling helps us shift the frontier of the process. When we dealt with waiting time problems through adjustments in the staffing plan, that was good, but it was simply walking up and down the efficient frontier. We increased utilization, to gain efficiency, but we decreased responsiveness, and vice versa. Pooling, in contrast, lets us shift the frontier. Pooling, however, is not without cost. We have to make investments or sacrifices to have this increased flexibility in the process.
