Let's start with conceptual model. We're going to use words to describe our problem. You will quickly see that our description here is more precise and more comprehensive than the description we had in the first section. But is not going to play with the details of mathematics, it will be at a higher level that accurately describe the problem, but just in words. What is the decision we want to make for each given location? We want to determine whether there should be a facility. Currently we have 12, maybe tomorrow we want to evaluate one out of 15 or 20 facility locations. But anyway, for each location, we want to determine whether there should be a facility. Plus, for that particular case study, we actually may determine the scale level. We may determine to build a large facility or a small facility in some sense, two floors, five floors, that has some correspondence with scale. We may determine the scale level if we want to build one. Then we need to allocate engineers to build facilities. If you have a facility that has been built, you may send engineers there. Then finally for each customer, you need to assign a customer to one facility that has been built. In this particular case, we are doing four kinds of decisions, or you may say our decisions are four dimensional. We need to decide whether to build a facility, it's scale, we need to allocate engineers, and we need to assign customers. Here when we say customers, we are actually talking about customer sites. For example, if you are talking about 7-Eleven, there may be a 7-Eleven store at Taipei, another 7-Eleven store at [inaudible]. You don't need to assign them to one single facility, you may assign them to multiple facilities. But here when we are talking about concepts, we may call each customer store as a customer. When you do that, you need to somehow considering capacity. You cannot just assign all the customers to the Taipei facility because there are no enough engineers to serve everybody. That's one thing. Our objective for the decision is to do cost minimization. For cost there are three components, we need to take care of office rents. If you want to have a facility here, you need to pay the rent, and you need to play those traveling cost so that you may subsidize engineers to move from facilities to customer size, move there, go back. In our problem, the subsidy actually means you need to pay the oils, so pay the fuel, pay the gasoline for your company cars. In some other problems, you may let engineers drive their own cars, and you subsidize them. But in an abstract way, we call them subsidies. Those are the traveling costs that you need to worry about. Then finally, there are some utility costs, you need to pay for hosting engineers in facilities. Because once you put one person in your facility, the engineer need to eat, need to drink, need to use electricity. That per engineer cost may be different from Taipei to [inaudible]. That's also some costs that are relevant to your decisions because you need to allocate engineers. Wherever you are trying to describe your objective terms, don't forget to link everybody. The cost terms must be relevant to part of your decisions. For all those things that are relevant enough, you need to include all of them in your problem description. Finally, we must have some constraints, otherwise, we will do our decisions in any way. What are the constraints? There can be at most one facility at any candidate location. That's obvious, you cannot get two facilities in one location. If you build a facility, then you may choose exactly one scale level, you cannot choose two, you cannot choose nothing. Once you have a facility, then that facility can serve a customer, and get engineers allocated only if it is built. In your model, you are not allowed to have one customer be served by an empty facility. You cannot have a customer be served by an unbuilt facility, also that's a constraint. Also, if you have facilities, for each facility, the number of allocated engineers should be large enough so that they have the energy, they have the capability to serve all those assigned customers. You cannot assign 10,000 customers to one store where you only have one or two engineers in that particular facility. The number of engineers allocated and the number of customers assigned must somehow be reasonable. Then finally, for each facility, the number of engineers that may be hosted is limited according to the scale level, you cannot just build a very small facility, but you'll want to put 100 engineers there, that's impossible. You may see that all these descriptions are somehow translating a real problem to a mathematical model. You may see that we are intentionally doing that. There are all real concerns, these are all real concerns. When we write down one-by-one, it would not be so hard to generate a mathematical model from these descriptions. But all these descriptions are conceptual, you don't need any mathematical terms to describe them and you are always allowed to do that. There must be a way for you to describe your problem, describe the objective function, describe the constraints, describe the decisions, without using any notation. You need to be able to do that so that a business person understand what you are talking about, so that the business person may agree with your model, and accept the suggested solutions. That's why a conceptual model is useful. Always, when you have a problem to be solved before you build a mathematical model, write down your conceptual model. In some sense that's similar to what? To writing a computer program. Before you're ready to write down a computer program, we always ask you to do what? To write down pseudo codes. If you are able to do that, then that would be some design before you really concretely write down codes. That's almost always the case for any fields. Before you build a concrete thing, first build a conceptual thing. In OR before we build a mathematical model, we first build conceptual models to help us do the preparation, and it will help us do the communication between business persons.
