So far in this module, we have assumed that every customer that comes through our process would be willing to wait, and would be able to wait until it is their turn. That means as a consequence of that, we assume that every unit of demand that came to us was served eventually, maybe not as quickly as in the analysis would've suggested but everyone that came in the process would be leaving the process as a served customer. In this session, we consider what happens if customers are unwilling or unable to wait. In that case, customers will leave the process before we've actually served them. In other words, our outflow, our completed flow rate, will differ from the inflow, from the demand rate. We'll introduce a simple mathematical tool that helps us predict what fraction of the demand we will be able to serve in this case. Once again, we will focus on process flow diagrams that are very simple and just include one resource, potentially though with multiple servers. Now, on the very left of this slide, we see the situation that we've analyzed so far in this module. We have a resource and we have a waiting line. Now let's move from this very left to the right. You can imagine that customers are impatient. After a while, they're tired of waiting and they abandon the waiting line. Examples of this would be an emergency room, for patients after a couple of hours waiting, might just quit or a call center where customers hang up if you have had them wait too long. Further on the right, we can imagine that some customers might not even enter the system when the line is very busy. Think about a drive-through restaurant. Imagine you are pulling in at a McDonald's where there are three parking lots at a busy road. If all these three parking lots are full, pulling in will not work, you have to keep on driving on. So the customer gets lost from the perspective of the server if there's not enough space to store them here in inventory. In the very extreme case, waiting time is just not an option. If you cannot serve the customer immediately, the customer will be lost. Notice how these cases are related as we move from, for example, the very left to the right here. We're just adding some impatience of the customer. As we move from here to here, we're basically just set the sizes of the inventory equals to zero. We have focused the previous session on this very left case, we will focus this session on the right case. Now there are mathematical models that also analyze the cases in between but they are a little bit more tedious than what I would like to do in this first course on operations management. Consider yet another healthcare example. We previously talked about emergency rooms, big inventories in front of a resource. Next, consider the case of trauma care. Patients that have to be moved to trauma care, they are so acutely sick that waiting is not an option. What happens if all the trauma bays and all the trauma capacity in a hospital is busy? The hospital goes on what is called diversion. It tells the regional fire and rescue to stop sending ambulances and helicopters. Simply put, the demand rate is shut down but let's analyze the situation. As before, we have a random demand process. Say for sake of argument, a patient comes in every three hours. We will impose in this session here, that the CVA is equals to 1 and that we're dealing with exponential interarrival times. On the service process, we find that in this trauma center, patients stay on average in the trauma bay for two hours. This is nothing else but our good old friend the processing time. Again, it is naive to believe that, Toyota-like, the patients would stay exactly two hours in the hospital but P can have any distribution. So it turns out that the standard deviation of this distribution would not matter for our analysis. The magic number that we want to compute is the probability with which an incoming customer will not be served. This is an important number. Once I know this probability, I can multiply this with the demand rate. I can compute the number of customers that get lost, as well as the number of customers that get served. How do we find that probability? It turns out that there is a big mathematical formula that computes the probability as a function of the number of service, the processing time, and the interarrival time. I will show you that formula, just in a moment, but you will thank me one day that you will not have to use it. Here is how I want you to find out the probability. The first thing I want you to do is compute the ratio between the processing time and the interarrival time. I would prefer that you don't try to interpret that number, just call it r for ratio. Next, you look at how many resources do you have, or how many services do you have in that resource and in this case, we have three trauma bays, m equals 3. The last thing that you need to do, is you need to go into a big table that I will provide you, and in this table, you are going to go into row r and you're going to go into column m. Where row and column meet, you will have the diversion probability. In this case, 2.55%. Again, once you have this number, you are in good shape. If you want to figure out what percentage of the time and the date the hospital is on diversion, just multiply 24 hours is 2.55%. If you want to figure out how many patients that you're going to lose because of diversion, remember that we have a patient arriving every a units of time, which is one every three hours. So eight patients per day, and if you multiply this with 2.55%, you'll figure out how many patients we lose. Similarly, if you want to take one minus a probability, you can figure out how many patients that we have served. Again, figuring out this probability is at the heart dealing with these types of loss problems. In this graph, I show the relationship between the implied utilization and the probability that all servers are utilized. Let me emphasize why I plot the implied utilization here compared to the utilization, which is what we drew in the graph where we looked at how TQ was increasing with utilization. Remember that in the TQ model, the assumption was that u was less than 100%. For an implied utilization over 100%, if I have the situation where demand exceeds capacity, the line here would just go through the roof. This is not a matter of variability, this is a matter of insufficient capacity. Things are different in this type of model we're discussing right now. Here, if I have demand exceeding capacity, the system simply clears up itself. It just drops customers from the system, these customers get lost. Even in a situation where I have 50% more demand than I have capacity, I actually will observe an occasional idle time at the resource. This is why I plot here the relationship between the implied utilization and the probability that all servers are busy. In order that for a 50% utilization, I have about a 30% probability that all servers are busy. If you think about the fire truck, for example, and assuming that you really don't want to have a long waiting line of calls asking for 911 support, waiting for the fire truck, you notice that at 50% utilization of the fire truck, 30% of the calls would actually get a problem. The other thing that you see in this graph is the power of pooling. At an m=1, one individual fire truck at 50% utilization, my service is going to be a disaster. If, however I'm able to pool demand and I'm moving up from m=1 to let's say m=20, I cannot afford to run a much higher level of utilization and provide still decent responsiveness. This is very similar to the example we had in the case of pooling in the TQ formula. Let's look at a specific example. I mentioned earlier on, the trauma center where I have three trauma bays, and a customer coming in every three hours, processing time was two hours. Let's ask ourself what would happen if I would pool two such systems. If I would pool this hospital with another hospital that also has an a=3, p=2, and m=3. Let's figure this out. Once I have pooled the two hospitals, I have an m=6. My processing time would not be affected by the pooling and stays at two hours. However, now I have more demand. I have had a customer coming every three hours in one hospital. I have a customer coming every three hours at the other hospital, so I have a new interarrival time of 1.5. To see this, just go to the timeline. If you have one customer every three hours from the one system, one customer every three hours on the other system, and you know that the pooled amount has a shorter interarrival time? Now, how do I take m=6, p=2, and a=1.5 and figure out the probability of waiting? I promised you, at some point, I would show you the formula, so here it is. This is a model known as the Erlang Loss Formula. Mr. Erlang was an engineer working for the Danish telecom company some 100 years ago. His job was to figure out what likelihood of the telephone lines would be busy. He came up with lots of cool math, including the one that we're discussing right here. So you notice that the table I gave you earlier on was a little on the small side. As we are now looking at an m=6 and an r equals to p over a, equals to 2 divided by 1.5. I will need this bigger table. Let's take a look at an M=6 and in 1.33, I'm looking at a 0.2% probability of diversion. Notice again, this is the power of pooling. I've not added any capacity, I've just pooled the system, I've pooled the demand, I've pooled the capacity, and I'm dramatically improving the level of service. Buffer or suffer, that's what we said when we first encountered variability in our process analysis module a long time ago. Buffer or suffer. If we cannot buffer our customers because they are either not willing or able to wait, we will have to suffer a loss of through put. Buffer or suffer. In this session, we introduce the Erlang Loss Formula as a way of predicting how bad that suffering of flow rate really will be. We computed what percentage of demand would be unserved, if the occupancy or the utilization of the resource is high. We noticed that, once again, the variability was the root cause of all the problems.