 Okay good morning everyone. I see there are a lot less people than last time which is kind of understandable. Welcome to the second lecture on system dynamics and complexity. Before we start I want to clear some administrative issues which were bothering me quite a lot in the last two weeks. So first of all I'm not a professor and you please don't call me professor. It kind of makes me feel uncomfortable and I'm also tempted not to correct you which is not nice. So don't call me professor. Now seriously there are still people without groups and it's not really such a big problem as you might think. So if you're not assigned the group I will do this. This is the easiest thing to do and you will present. You will have your chance to present. I'm just waiting to see who decides to stay with the course and who decides to drop it and as you know there are like I think two weeks after the semester starts. So there is a huge flux of people. It's difficult. It's somehow difficult to assign groups because people drop out and stuff like that. But hopefully most of you have groups. Who doesn't have a group assigned? Oh wonderful. Alright. Any questions about administration? There was one post on the forum and apparently I did not make it clear how these handouts are going to be distributed. I think there is something in the first lecture about it. You will get it the night before 6, 7 p.m. And the reason is not that we want you to have no time to read them and prepare in some way. The reason is that basically I'm still working on these handouts. It's not that you know there's this cupboard where we take all the slides year after year. They change constantly and there's no other way to post them earlier. If there are no more questions I'll go on with the lecture. Today's lecture is in my opinion very intuitive. It's about the problem solving cycle, how we identify problems, how we solve problems. It's more of a non-mathematical approach as opposed to what you may think this course is about. But this is mostly kind of a management perspective. And I think it would be easy for everybody. There are trivial things and I hope to kind of convey the message that even in trivial things sometimes we can fall into certain traps. So without further ado let's start. Again I would like to repeat what this course is about because in my opinion if you know if you can tell what course you're taking in five sentences, if you tell the purpose of the course then you've really understood and you can do well on the exam. So the course is really about three things. Finding solutions, implementing solutions and controlling these solutions. That's all. Finding solutions is topic of systems engineering, how to define your system, how to define your situation. Implementing solutions is topic of project management. This is coming in the next lectures and as I mentioned these two parts would take about a third of the course. The last one is about controlling solutions understanding how the system works and why it doesn't and so on. And this is where systems dynamics and non-linear dynamics, chaos, unpredictability, things like this come into play. Last lecture we dealt extensively with the topic why problems are not simple. And hopefully now you know why problems are not simple. They have ill-defined problem space, no known algorithm to solve them, multiple conflicting objectives, contradicting both correlated demands. And we will be interested in exactly those problems, not in the trivial well-defined problems. And hopefully I gave you a flavor of what we're going to mean by complexity. Complexity is not going to be something that you can simplify or can abstract away, reason away, negotiate away or stuff like that. Complexity is going to be system property. So we're dealing with systems and with problems which exhibit complexity. And with complexity come the notions of unpredictability and chaos. But this is the last part. I gave you a flavor of the problem solving cycle or one way to solve a problem which was this iterative procedure. If you remember the traveling salesman problem. We also incorporated the notion from evolution where we have random mutations and recombinations. And finally we ended with kind of the message that in most real-life situations all these kind of are hard to apply because we need human problem solvers. Which means no defined endpoint. We don't know when to stop this refinement and this constant negotiations and discussions and things like this. And the problem solving cycle will hopefully give you kind of a framework to make this human problem solving easier. Okay. So before that we talked a lot about how problems have multiple solutions. This kind of multiple criteria optimization. And we don't know the best solution and we're not even sure it exists. If it exists we're not even sure if we can find it. The point I want to make is that this is not something bad in real life that we try to deal with by discourse or by thinking about it. We're not trying to address something bad in life. That's the point. Because imagine what will happen if problems were not that complicated and complex in real life. If they had one best solution everybody knew this best solution and there was no need even to think about it. So if you imagine this then probably you can expand this list. But this is just an example of what may happen. So everybody would like to move in into the best apartment to marry the same woman or man or somewhere in between. I don't know. They would want to make. Well, I don't know. I mean I've seen things. All political parties. No offense. All political parties would like to make the same argument. We would know what the best political system is. We would have the same products and things like this. So you can expand this list by yourself. If there are no multiple solutions available this is what's going to happen. And in essence complexity, this kind of undefinedness of the solution space, complexity leads to diversity. Diversity in products, diversity in political strategies, diversity in people's opinions. And ultimately I think diversity leads to progress. Because without diversity, without this kind of multiple products for example, you wouldn't be able to have a market where people compete. So invisible hand wouldn't work. And we wouldn't be able to be creative. So this is not something that we'd like to think as a bad thing, which we're addressing with this problem solving cycle and this kind of stuff. It's something that is good and will embrace this notion. So let's start with the problem solving cycle. What is a problem solving cycle? In fact, if you go to Wikipedia and you Google, well, Wikipedia problem solving, problem solving turns out to be the most complex intellectual function that beings are able to do. So it seems like problem solving, although most of us don't really realize it, is the highest cognitive function in a way. So it's something really, really good if I think about it. The problem solving cycle will give you a general approach or framework how to solve a problem. First, how to define a problem, how to generate solutions, how to implement these solutions and then how to control these solutions. It's so general that almost every industry or management discipline has it in one way or another. We'll look at this notion, abbreviation similar, you'll see what it means. It's just the problem solving cycle from a systems engineering perspective, the organization of systems engineers. It's on the next slide I'll show you. It's just a different name for the same thing. The idea of iterations, you start and you define your problem, you come up with proposals, you evaluate these proposals, maybe you go back in the beginning when new information becomes available. This idea comes from the Asian Greeks with the so-called Mayutics. Do you know what it means? This philosophical notion? Exactly. It's exactly what you said. The idea is that every human somehow knows the truth in some kind of innate reason. Somehow you know what the best thing to do is. You just need to be directed in finding it. How you know it, the philosophy doesn't say, but if you're asked the right questions by an experienced psychologist, then you will realize whether you're thinking is wrong. When you realize this, you will be able to find the true answer. The idea that you somehow know this truth is basically Mayutics. What you need to do is just to start iterating, asking the right questions, coming up with answers, evaluating these answers, and then asking the right questions again. This kind of cycle is basically what the problem solving is about. Midwifery, midwives, they help women give birth and the idea of Mayutics is that you help people give birth to the truth, because somehow it's already inside of them, you just help them to find it. The reason why Midwifery is mentioned is that the words in Greek, Mayutics and Midwifery is somehow similar. Probably one derived from another. As I mentioned, it gives you a framework, how to solve a problem, so you can think of it as steps that you need to do. Counterintuitively, though, there is still room for creativity, and we'll see this. You may think that the rigid procedure you should think in this way would limit your creativity, but in fact, this is not the case. Not usually, but always, unless the problem is very simple. Always, it's iterative in nature. So quick words about this similar thing. It's state the problem, investigate the term, dismantle the system, and so on. This is the definition of the problem-solving cycle from Incose, the International Council on Systems Engineering. They have a lot of information on their website, but essentially, this is what they think the problem-solving cycle should be. It's just one particular interpretation of a more general framework. State the problem, which means accumulate all inputs from all stakeholders, understand how different people see the problem, and then finally come up with a problem statement that more or less captures what everybody thinks. Investigate alternatives, alternative solutions. Modeling is very important here. Here's where modeling comes into play. We need to represent this real-life problem. You'll see a nice real-life example later on, but we need to represent it in some kind of an abstraction to be able to deal with it. We talked about this in the last lecture, and there would be formal lectures on modeling to come up. And then so on. Launch the system, assess performance. So this is just one implementation. But in the most general way to look into it is these three parts. The problem-solving cycle is really these three parts. So in a sense, the whole lecture could be just this light. It's setting the objective, meaning what is it that you want to do? Search for possible solutions, generate solutions, evaluate solutions, and finally select the right solution. And each of these steps could be further broken down into sub-steps. For example, we'll look into these in details, but for example, before you set the objective, so what do you want to do? First, you need to understand what is your current situation. It's a no-brainer. And then only can you formulate the objective. For example, imagine your boss comes into the office and says, we have a problem. The problem is that the profits are going down. What do we have to do? So can you really set an objective based on this definition of a problem? Not really. So first, you need to analyze why the profits are going down, situation analysis, and only then can you formulate objectives. All right. So just a flavor of the self-study. The self-study is about the problem-solving cycle. It's split in two parts. The first two steps of the problem-solving cycle, namely situation analysis and generation of solutions, would be this week or next week. And then next next week would be the actual selection of solution. And in fact, with the self-study, you would really get the chance to practice this problem-solving cycle. It's a very nice case-like structure. It's actually a realistic case. It's not a made-up thing. You would play different roles, and it's going to be very interesting. Imagine we have an airport. In this case, let's imagine it's a 2D airport. In fact, it was the Munich airport, but let's now imagine it's a 2D airport. And you want to expand the capacity of this airport. So you have multiple ways to do this. You can either build new runways or you can extend existing runways. And each of these decisions would affect basically everyone, the environment, the stakeholders, the common public in different ways. You will generate different levels of noise, different levels of pollution, and you need to take care of all these interests at the same time. This is the self-study, what it's all about. And to show you that this is actually a real case that people were trying to solve, this is a picture taken from the Tagessan Tiger. It's five years ago, I think, or four years ago, yeah, 2007. And you see, this is what they presented. It's exactly the same issue. We have the current situation. This is a runway. And you need to expand the capacity. So you can either extend these red things, extend the existing runways, or you can build new ones. It's actually a combination of building a new one and extending the current ones. And then here, what they've done, they've evaluated. So this is, let's say, a number of landings per year, I think. Yes. And this is the noise that they calculated each solution will have. So you see, if we extend, if we build new runways, we would be able to have more planes landing at larger noise levels, which is not good. So this going to the right is good for the policymakers. They would get more planes. But at the same time, going up is bad for the public living nearby. So this kind of balancing act you have to do in the self-study. And I even believe that you can also find the results of all these discussions online, because I'm not sure if the discussions are over yet. It was four years ago. So I haven't checked. Maybe they've come up to a conclusion. So it would be interesting to compare what you come up with, with what they came up with. Yes. So this is the self-study. You need to apply the problem solving cycle to these airports. As I mentioned, this week, or technically next week, we'll deal with setting the objective. So it's the other way around. This week, it's only going to be setting the objective, and then the second part is searching for a solution and selecting a solution. And this, I find this self-study more or less one of the best in the whole course, because it's very realistic. When we get to the modeling, you need to be able to appreciate why we model things, to appreciate the self-studies themselves. But if you don't, you can still enjoy this one, because it's very realistic. All right. So let's dig deeper into each step of the problem-solving cycle. The first one was setting the objective. And setting the objective could be split in two parts. First, as I mentioned, we need to analyze the exact problem that we're trying to solve. I mean, it's a no-brainer, but take this example with your boss walking in. You need to be composed and to actually not panic and start understanding what your boss is really telling you, what the problem is really about. So scrutinize the problem, understand why the profits are going down. Of course, be aware of constraints. You need to be aware of how your actions may be limited, because this would influence your creativity in the solution phase. So it's good to know it in advance. And then we move on to analysis of the current situation. So it's this typical idea, we analyze where we are now and where do we want to get in, whatever time frame, and then how to get there. And this contains four parts. We need to define, this is where the system thinking comes into play. First, we need to define our system. What are we going to be concerned with? For example, if your problem is in the supply chain, for instance, you're not concerned with marketing or human resources, or you are concerned with finance in one way or another, but not with marketing and human resources. So your system, in a way, your scope of interest will not include these things. So you need to define what is your scope of interest. You need to define what is outside of your scope of interest, environment in other words. Analyze the system and relevant parts of the environment is the next step. So once you've defined your scope and the environment, you start analyzing mostly things within your scope, but also how they feed back with your environment. We'll see an example. You do the normal strength weaknesses analysis, and important. The last part, probably, is there a computer scientist here? You are a computer scientist. So you probably know about this. How you should always consider, even at the design phase, you should always consider what may change, what is likely to change in the future, because this would, in a way, direct how you solve the problem. So no magic numbers and things like this. All right. All right. So before we move with defining system, environment, borders, first we need to take care of or think about what exactly is our scope of interest or our system. And in the more generic way, so first of all, what is a system? The most general basic definition that you can come up with after all that we've seen so far. What is a system? It's something that I think is good to know for this course. Anyone? Interrelationship. So the system is just the interrelationship between the parts. Are the individuals part of the system or just their interrelationships? Yes. So basically a system could be seen as simply a collection of interacting elements in the simplest way. And I can give you a hint that something like this would probably come up on the exam. Basic things like what is a system? Or what is modeling? And you don't need to write paragraphs and paragraphs of explanations. One sentence, which just makes sense with your own words, is more than enough. All right. So a system is simply a collection of interacting elements. And you're free to model everything within this system. You're free to model your elements. You're free to model their interaction. You're free to model, well, that's pretty much all. But think about, for example, your supply chain problem. You want to solve some bottleneck. The elements in this system would be something like plants or machines or workforce. The interactions may be how, let's say, how many machines one plant has and things like this. So this is more of an operational perspective. You define your system based on how it's structured. But for example, if your problem is make my company more adaptable or make it less inert, then your elements would not be plants and machines. Your elements may be decision processes or process flows. So this kind of more abstract things. So as you can see, I mean, your elements and your system may be completely abstract entities. It doesn't prevent you from solving a problem. Furthermore, this is not a flat picture. Element, element, element, they interact. We have a system on a flat surface. What we actually have is a hierarchy. So you can have systems within systems, within systems, within systems. Basically, this is the picture. So depending on which level you zoom into, you may consider something to be an element on one level and then to be a whole system on another level. And in your notes, you have the most common example with the human. How the human can be considered a system, collection of cells, but also an element in an economic system, for example. And this is, in fact, I would say we start with microeconomics here and we slowly go to the macroeconomics. This is how you can think about the link between micro and macroeconomics. Okay. So we've defined our system, our scope of interest. We've defined the most important elements, whatever that is. Humans, machines, abstract notions, God, I don't know. And then we're ready to move to defining what the borders of the systems are, of the system are and what the environment is. And there are basically two approaches that you can use. You can use the so-called, or I call it the first one, within the system perspective, which means that you're inside the system and you define where does the system end and where my environment starts. There is an illustration on the next slide that I'll illustrate this. So you're within the system and you simply limit, let's say, your scope. I mean, your scope will be limited by your cognitive abilities or by your time constraints. So what can you actually influence? And then everything else is environment. We saw more kind of a physicist perspective on system environment, delineation, which were open, closed system and isolated systems. So these are definitions from physics that are kind of, it takes certain amount of imagination to apply them to real life, open system, exchange, matter, energy and information, closed system for our purposes. So in the physics sense, they only exchange information. But the point is that in a closed system, you cannot have movements of the elements in or out. So if you consider the economy as a closed system and if you consider that the economy consists of people, a closed view on economy would mean that no people can come out or in from the economy. Information can flow, but not matter, not the elements themselves. And isolated systems, which almost don't exist in the real world, unless you consider the universe to be a system, do not exchange anything. So this is just kind of a more abstract definition of system and environment. So this is open, closed, isolated. All right. Now more about delineation between environment and system. This is an illustration of, in a sense, I wouldn't say the whole problem solving cycle, just the first two parts. But it means the following. As I told you, first we define the system and then normally what happens, the problem that you're trying to solve is a subset of your system. And I'll give you an example. Imagine that this is the economic system, the green thing. Yes, the green thing is an economic system. And your problem that you're trying to solve is high oil prices, for instance. I mean, hopefully one person can solve this. But let's imagine that this is the problem and obviously this solving, dealing with high oil prices, is just part of the economic system. The economic system has many more problems than high oil prices. All right. So this is your problem. In addition, the amount of impact that you may have, depending on who you are, of course, but the amount of impact that you can have is even less than the problem size. So for example, if you're just one individual, your ability to influence this problem is probably very limited. Or in the so-called intervention zone, which parts of the problem you can actually enhance is very limited. If you're Saudi Arabia, for example, probably this intervention zone would be much bigger. It would probably encompass the whole problem. If you're, yeah, I mean, any other country would probably be less than Saudi Arabia. Okay. And then in most cases, again, unless you're Saudi Arabia, but in most cases the actual solution that you can come up with would be even less or even smaller than the intervention zone. Because just think about it, you may be able to do a lot of things in theory. So your intervention zone may be kind of white. But the actual things that you can do in practice would normally be less than that. You may be not able to just stop producing oil or increase production of oil to decrease prices due to political reasons or trade agreements and whatnot. So normally this is what's going to happen. Your solution, your actual, this is your actual impact. Think of it as this. Solution zone is your actual impact. Intervention zone is your potential impact. And this is the problem, this is the system. And now a funny thing happens. You've defined all these things. You implement your solution. And then what you see is that your solution creates new problems. So before this was your problem. And now your problem is this. So you've created a new problem, which I think most of you would agree with. Often we think we've solved something, we solve it, and we create something new. Or we don't solve it and we still create something new. I don't want to give examples because it's recorded, but I have nice political examples, so we can talk about this later. I would have liked to give them, but I'm not sure how people would react. I mean, just, for example, think that... Well, no. Okay, let's move on. No, it's nice to try to think in real life terms about all these things. So how trivial it may seem. We have a problem, we have solutions. In fact, it happens every day, and it's not as trivial as you may think. Okay. In more details, or this is the second part of the task analysis, we need to analyze the system and the relevant, only the relevant parts of the environment. This is... Here we have more or less aggregated idea of what is... No, these are just like particular actions that you can take. Come again? Either that or you may think it like this. This is an action I need to do, and then after I do this I need to do this one, and then this one, and then things like this. So it's any notion of action that you can come up with. So this was more or less an aggregated perspective. We have a system, we have a problem zone, we have possible intervention zone, but in fact when you analyze the environment, for example, you need to analyze the influence of the environment on your system. You don't really analyze the whole environment. Somehow you need to model the environment as well. Environment is too abstract to be useful. So this is... So first of all, I apologize. This is reversed. So the... What is this called? Orange needs to be actually investigation, intervention area. Investigation, intervention is the same, and the yellow one should be the system. So correct that. This is taken from a paper written by a student where he analyzed... I think it was an electronic healthcare system. The point of what exactly he did is irrelevant. What is important is the following. So for him, let's start in a different way. Imagine, let's say me and you, we have the same goal. We both want to improve the patient's quality of life. This is our goal. And we both can think about it and come up with a solution how to do it. And let's imagine this is me and this is you. So we have the same... Let's call this the universe. The collection of everything that exists within the system and outside the system is our universe, in a sense. So, for example, you can have what influences our healthcare system. Well, of course, legal conditions. Of course, funding. So legal conditions influence the funding. Funding, of course, influences the type of treatment that you will get or you will not get. Well, what else? For example, the complaints by patients or by doctors influence the data that you record and so on and so forth. This is not so important. We have, this is our universe, okay? And I define my system. So the thing that is within my scope of interest is the yellow one. So I care only about consulting. I care about consulting, providing advice to doctors. Maybe I'm a medical consultant, so I provide advice to doctors. I provide advice to hospitals on best management practices, things like this. Consulting, support and provisions, and I care about the social environment, whatever that means. So this is the system for me or my scope of interest. What I can actually influence within that scope of interest may be even more limited, as you saw. I may only be able to influence consulting and support. And then the solution that I will come up with to improve patients' quality of life may have to do with improving management practices in hospitals, for example, by educating managers and doctors or proposing some kind of, it's very popular, this kind of private-public cooperation where hospitals are managed by professional managers, not by doctors, things like this. You on the other hand may be, I mean you, maybe let's say an IT firm, IT SAP for example. And then your scope of interest will be, for example, data acquisition. How you store the data from complaints or whatever data in the patients' records, so on and so forth. Where you store it, how you acquire it. Again, consulting and usability and so on. And your scope of, let's say, ability to change something may only have to do with the IT part of it. The final usability of whatever and then data acquisition and so on. And then the solution that you may come up with will probably have to do with building better infrastructure, digital infrastructure for exchanging medical records and storing patients' medical history and so on and so forth. So you see, depending on how, first of all, on who we are, what we can do, what our interests are, we come up with completely different solutions to the same problem. And both of them are good. Both of them, in a sense, deserve to be implemented. So, yeah, that's it. The next part of the task analysis is, so after we've defined our system, we've defined our environment, we've defined what exactly we can do, what we can do, we move to defining the so-called strength and weaknesses, so you have to understand where you are and what you need to change, what you don't need to change. It's the typical, the most popular SWOT analysis, PEST analysis, portfolio analysis, things that you will do at length in other courses. You will also have to do them in the fourth self-study just to give you a little flavor of these things. And I remember when I was doing this MS degree, it's not as trivial as it may sound. This is my point. You may be tired of hearing this strength, weaknesses. It's so easy. But in fact, there was a consultant invited for one of the courses. I think it was strategic management. And then I asked him, well, how often is this SWOT analysis used in practice? And he said, well, not very often. I said, why? And then he told me, the thing is that if you ask different people within a company to do a SWOT analysis, it's very simple. Strength, weaknesses, opportunities, threats. What is a strength for one person may be a weakness for another one. So you would get a completely conflicting situation analysis. It's part of situation analysis. So you would get completely conflicting things. And then this would obviously create problems with defining your actual problem. So it's just something to keep in mind. Don't underestimate how easy this is to do, but also don't overestimate its potential impact because it's in practice, yeah, it's limited. All right. And finally, as I mentioned, future development. So you need to... This is still part of situation analysis, by the way. The first part of the problem-solving cycle. It's very important to do it now because when you identify things that may eventually change in the future, you will come up with different solutions eventually. You will come up with solutions which are adaptable, which are not rigid. And it's very important as any computer scientist will tell you, for example. All right. And yes, forecasting systems dynamics is basically this. You try to predict in an intuitive way how your system would behave, how your environment would behave, and how the feedback between them would behave. You can do SWOT analysis for evaluating solutions, that's true. And this would also be part of the problem-solving cycle when we get to evaluating solutions. But before you can actually come up with solutions, you need to answer the questions, solutions to what. And this question is what motivates doing SWOT at this point of time. So for example, if you have a very large market share, this is your situation. You have a very, very large market share. And you may think this is a strength, in which case we don't have a problem and we don't need a solution. But one, your boss, for example, or your colleague, may think that this is a weakness because this is, in fact, let's say, a saturated market without future. In which case we have a problem and we need to do something. So it's worth doing the SWOT on your situation, which motivates your problem and eventually your solutions. Did I hear a bell? Was there a bell? There's one minute or... one minute. Okay, so let's stop here for a break because this starts, actually, the second part of the problem-solving cycle. So I don't want to stop this progression. Oh, okay, well. Let's continue. A few words. Administrative again. I was reminded of something. We're going to have online tests, three online tests, after the fourth, the eighth, and before the exam. So three online tests you only need to pass two. And as I mentioned, in the beginning there would be a lot of time and open book, everything would be open. You just need internet access. All right. I need to turn this on. So now we've finished with analyzing the situation. This was part of... This was part of the first sub-point. Let's see, this one. So we finished with... So the first point, the first part of the problem-solving cycle is situation analysis in the most general sense. The first sub-part was task analysis. So identifying what your system is, what your problem is. The second part is, now that we know exactly where we are, what can we influence, what can we not influence, what our constraints are, what can we define our objectives? What do we want to do? And this is the step 1.2. So the second sub-part of the first part of the problem-solving cycle is setting the objective. And this... I got a question in the break about when do we exactly start implementing the solution and we hand something to the customer. And we know this is the most possible solution given all our constraints and this is what we give to the customer. And this has a lot to do with this part, with setting the objectives. Because the objectives would be the basis on which you evaluate your solution. And this sounds trivial at first glance. Of course, we need to have an objective in order to evaluate solutions. But objectives and goals are vague, not defined explicitly. A PhD is a perfect example of this. I can attest. And eventually you end up with a bad solution. So the objectives in most cases although the word means objective, that is invariant to different interpretations they are defined in a very subjective way. Because everybody has different interests, everybody has different ideas and consequently everybody has different goals, different objectives. We need to be able, we need to know this in order to balance things out. Again, you can think about many different examples of what an objective could be. These three classes of objectives are more or less the more common. Procedural objectives which regard the process workflow so how do we want to implement our process or let's say a production line, manufacturing line. There are also objectives regarding the end product of your system, a product of something that you produce or how this thing should look like. And again, there are mandatory objectives that you need to do and nice to have or desired objectives. In the most simple way you can define objectives in the following algorithm if you'd like. The system has to have certain properties within these specifications in the given time frame. For example, the instance here is I'm a runner I want to be fast, meaning I want to run 100 meters less than 9.78 seconds and I want to accomplish this to be able to do this in one year. But of course you can come up with more realistic examples. I want to have a product which is cheap, whatever price in two years for instance. So this is kind of a generic way to formulate objectives. It works in a lot of cases where normally you wouldn't think it works and in the self-study if you try to use this things would be somehow a lot easier. At least they were for me when I was doing it. So what should an objective look like exactly? A very important thing an objective should not mention anything about the solution anything. You shouldn't think about whether this is possible well, you should think about whether this is possible or not but you shouldn't think about how to do it. For example with the airport with the airport case a bad objective would be something like we can only build a new runway and there's no other way to expand the capacity so let's figure out how to do it exactly. This is an objective which already hints into the solution. It's a very bad thing so never do it. The objectives importantly should be measurable or quantifiable you should be able to measure something with real numbers what you can't measure you can't control. I think this was the same thing. The objective should be measurable running fast is not measurable or high quality product is not measurable. Defects per million is measurable though. The objective should be complete and balanced what does that mean? Complete meaning all the stakeholders involved should have given their goals should have given their opinions and you should have collected all the objectives from the different sites that come into the problem. Balanced means that you shouldn't have very important objectives and very insignificant or trivial objectives in the same kind of catalog of objectives so you shouldn't have an objective like we want one DPM for our product and an objective which is the internal code name of our product should be I don't know chair, something like this so they should be balanced contradiction free is obvious no contradicting objectives because this eventually locks you into not being able to solve anything no repeating objectives obviously and an important thing also prioritization often it happens that individual objectives are at odds with the system's objectives with the overall welfare of the system probably you can think of a lot of examples economic examples are the most common ones tragedy of the commons if you've heard of this prototypical example of the conflict between individual and system-wide objectives you need to prioritize redundancy free means you shouldn't have repeating objectives which are more or less the same just reformulated differently for example a high quality product is not a good objective but that's basically what it means giving priorities is also very important because later on if your solution is targeted towards one of these priorities and somebody comes to blame you this was a bad solution this was a bad thing you can justify your solution by referring to your priorities and blaming you on your priorities is in general more difficult to do than blaming you on the results of your solution alright there are different techniques of formulating objectives we look into I think three one is the so called objectives catalog so this is a very simple idea often you would end up with so many objectives or goals think of objectives as goals or desires from so many different people I mean the MAS students would probably immediately recall an example that it may be difficult to simply process all this information so it's useful to split all these objectives into different classes of objective and the example here is with a car I want to produce a car and the car should have a high quality so that's a bad objective right there high quality should have whatever amount of air bags I don't know what consumption purchase price brand color and we can create the following objective classes for each of these objectives safety cost prestige and then we assign priorities to the objective classes and then we deal with objective classes later on this is one technique for formulating objectives another one so another one evaluates the objective relationship matrix evaluates the contradicting aspect what I mentioned so it evaluates whether you have contradicting objectives or not because sometimes it's not trivial to identify them at first glance so this is in German unfortunately but the point is the following on both on both sides you have the same objectives and you put a zero if if the two objectives so that one and that one do not influence each other no sorry you put a zero if there is a conflict between these two objectives you put a one if the two objectives do not influence each other at all so you can do them at the same time some problem and you put a two if the two objectives enhance each other so by doing one you would also contribute to accomplishing the second one and I'll just give you an example the first row here is yeah it's in German but it actually means reducing the acquisition costs for instance and if you take number two here so this was reducing acquisition costs and this is improving product availability what is that let's take let's take this one because it's in English after sales service so reducing acquisition costs and after sales service are obviously not related you can do them both at the same time it's not a problem however if you take yes the third one this is reducing storage costs and let's take one zero for example this one so we go to this row and we take that zero and this thing is so increasing the availability of spare parts now if you think more about this you would see that they conflict each other storage costs probably means that you store less you have less inventory you pay less which automatically means that the amount of spare parts that you may have available would decrease so you cannot actually increase the availability of spare parts and the same thing for this zero that zero which is improvement of product availability so if you have less storage costs meaning probably you store less your inventory is less product availability may be negatively impacted at times of high demand so things like this you identify the contradicting aspect of your objectives polarity profiles you would probably see this a lot and you've probably seen this a lot you put all your objectives into kind of a n-dimensional space and each arrow here corresponds to an objective and then you evaluate the importance of each objective and with this you can analyze your current situation and where you want to be so if you imagine that the solid line is your current situation the solid line is where you want to be you immediately see basically how to focus your efforts and an example actually again I think it comes from the Tiger Sun Tiger actually I don't know where it comes from but it comes from a newspaper about politicians so pardon they ask these politicians I think this was long time ago six years ago you've heard of these politicians I don't know but this was actually in a newspaper where they asked each politician to evaluate the importance of these following objectives and I was just looking at this yesterday and I thought okay well actually let's pay attention to it and read it so what was quite amazing to me is that if you look here this one this guy Matthias Feller and this says law and order law and order and it doesn't seem to be important to this guy at all compared to these guys so that that was really interesting thing and I didn't have time to actually google this guy and why wouldn't you care about law and order I don't know so yeah these are polarity profiles it gives you a nice very intuitive nice illustration of where you are where you want to be so this was formulation of objectives what kind of objectives you should define and how to define them let's see what we've done so far we've analyzed the situation meaning we've defined our system we've defined our environment we've defined how both interact what part of the system we can influence how our solution may or how our actions may affect our environment we've considered hopefully how all these things may change in the future and we formulated our objectives based on this task analysis the next part is search for solutions and selection of solutions so search of solutions basically means as many solutions as possible this is the solution synthesis so you synthesize as many solutions as possible you generate a lot of diversity and then you narrow down everything to one or two solution candidates and then you make a selection in the third part so let's ok and then here going back to this example with your boss coming and telling you that the profits are low and you should do something after you've done this hopefully you know for example that the profits are low because customers are not satisfied and then you know that your objective is to let's say increase customer retention for instance and this is a solid yes this is yes you can basically do this this is part of quantifying the objectives so when you have to quantify law and order it's basically you who come up with the numbers and that's the beauty of it because it depends on humans so there's no clear cut way to do it there's no clear cut polarity profiles it all depends on human problem solvers so yes if you end up with a huge range of say for example this objective is on the Likert scale 1 to 6 another one is I don't know 10 to 20 of course you normalize these are kind of technicalities but the numbers you come up with them so yeah that's a good point normally how it works is if people the chance to come up with their own quantification so you don't go to these three different people and tell them can you kind of come up with the number by yourself how important this is for you you give them a scale and I think this this is one so this represents okay we also have inner circles so I don't know the scale but yes make sure that everybody has the same scale if you end up with some marketing research from different companies where they use different scales then you need to normalize but then again the question is I don't think normalization is subjective it simply means that you shift everything to the same mean and that's it it's quite quantifiable okay now we move to okay to search for solutions second part so so far we didn't mention anything about solutions and we shouldn't think about solutions we should only think about the what and not about the how but now we need to search for solutions what kind of solutions are there we distinguish between the following two types the first type is first order solution this is a solution which exists within your system boundaries so in other words in more trivial terms it means do more of the same for instance the other heating problem if you're cold in your room doing more of the same or a first order solution would be to turn up the heating if you're still cold you do more of the same turning up and do this more and more until you either cannot turn the heating anymore in which case you certainly have still a problem or you're satisfied so this is the first order solution turning up the heating on fourth well I mean often it happens that first order solution simply exacerbate the problem second order solution would entail changing the system itself or in other words thinking outside of the box and all these kind of popular sayings which means you change the system boundaries and an example with again with the heating problem maybe instead of increasing your heating more and more you simply build better isolation for instance this would be a second order solution to the problem the examples here the Gordon Knott where Alexander the Great instead of untying a knot he just cut it with his sword still did the job Awaking from a nightmare instead of dealing with your feelings you just wake up and it's clear and a big mistake is that people sometimes try to change the order of this employ first order solutions where second order solutions are needed and when I was reading these slides a couple of days ago I immediately thought about so that's another political reference but it won't be ironic about the current way the EU is dealing with the problem with Greece with this extra debt of countries what they do they just do let's bail out more and bail out more and bail out more and now they're even bailing out the whole EU so it's doing more of the same doing more of the same and I don't know if that's the best idea I don't know so this is an example probably some of you are aware of those of you who are aware of don't say anything it's an example of connecting these dots in four straight lines can somebody do it? so this is basically the second order solution can you do it in three lines all the dots connect so in four lines how can I show you yeah four straight lines so it basically goes something like I hope you can follow you go something like this and then you go like this what is it two and then what is it three and four I think that was the right thing but can you do it in three lines so this is a second order solution obviously you break the system boundary nobody told you that you can't go out of the out of the margin but you did so it's breaking the system boundary can you do it in three lines which I would call is a third order solution okay I mean I googled this and it didn't come up with it so I'm not trying to impress anyone yeah straight lines okay that's such nth order solution that yeah you can do it no but something funny is that if you imagine the line not going straight like this through the dots but the line going a little bit tilted so still falling within the dots right so it comes through here middle of this dot and then the bottom of this dot so a line going like that slightly tilted so it's like one it comes to here then you do the same here two and then three right so you're using basically the size of the dots you don't have what infinitely small well you don't you don't really need a hypothesis because the definition of a problem is generally enough for you not to so if you had some kind of restriction then you have to do kind of a hypothesis well let's assume that the dots are not infinitely small if I gave you just point particles then you make this assumption because obviously you have a restriction you don't see big dots but here you see big dots so ok my bad so I'll correct it it should be dots but I think this was the best solution with folding the paper it's nice topological thing ok now this is where the creative part of the problem solving cycle comes as you just saw and for this part there are least the fewest amount of procedures that are imposed by the whole framework second order solution so it really ups to you it really is up to you so the only thing that can be said in this part is kind of a general advices of how to be creative for example one general advice is do not just listen to customers suggestions have you heard of this management professor Clayton Christensen not yet but he will be mentioned in the management courses so he wrote a very nice book which exactly addressed this point it's called the innovators dilemma which talks about the dilemma between being a good company having good relationships with your customers listening to your customers needs and complaints trying to satisfy them at all times and the notion that sometimes customers don't know what they want sometimes you need to do something that your customers may not like in the beginning but eventually would appreciate there are lots of industries that went completely extinct due to not due to disregarding this advice typewriter's industry is a prototypical example so don't always listen to your customers another thing again it's a repetition but there is not the best solution there are multitudes of possible solutions which are equally good depending on the perspective this may sound trivial but in fact I'm still amazed how quickly people jump into judging a given let's say performance of a government for instance so they quickly jump into saying this was a bad policy and the good policy is this, this is the good policy but there is no such thing as this is the good and this is the bad, they're equally good and you need to evaluate them in the right context given evaluating the right assumptions that were made and priorities, we talked about priorities it's in general it's much harder to blame somebody on choosing the priorities that they chose but it's much easier to blame them on the exposed result okay so this is one thing yes, how to search another advice be open minded okay I just have to tell you this example so yesterday I was it yesterday? yes it was yesterday I attended have you heard of Richard Feynman this physicist also but he's one of the most famous physicists of the 20th century and there was a presentation in the Irhel campus about his life and a distinguishing characteristic of this guy was his open mindedness and even kind of aversion to system boundaries I think most of the creations and progress in life has happened because of this trying to break the system boundaries so open mindedness always be open minded, it's not very easy to do this imagine if you have a brainstorming session and you have 5 people brainstorming on a topic, everybody comes with different proposals you think this is a good thing but in fact what happens is and there has been research on this that you are influenced by all these proposals and your own creativity and open mindedness is limited so a much better approach would be to have the people separated come up with their own ideas then they meet and exchange ideas then they're separated again, think more and meet again than having them in the same room the whole time so this is just an example how you don't even realize when your open mindedness is limited and the important part in this step of the problem solving cycle the second part the concept of the solution synthesis is you don't come up with a solution, you come up with solution variance with many different solutions there is no rule of thumb how many it's up to you it's again human problem solving okay this is a wait a second, I think I skipped a slide yes, I skipped this slide again I said synthesis means generating more and more solutions or variety of solutions the analysis part of the second step is to evaluate these solutions the solution is based on the objectives so you need to have your objectives quantified before you can actually start evaluating solutions so in this part concept synthesis it's important to create a variety of solutions you need to have diverse solutions and this goes back to the example with the brainstorming if you have people brainstorming in the same room you may not create the necessary diversity of solutions because open mind this is limited in the next step which is the analysis your goal here is to limit this plethora of solutions to limit it so you evaluate solutions based on your objectives you discard some solutions this does not accomplish the objective and then you limit kind of a funnel approach to reduce the variety here but you don't select anything not yet you simply remove the most obvious things that wouldn't work and this is a schematic representation of basically previous two slides we've done already our situation analysis we've defined our system we've defined the current situation we've defined our objectives and now we start creating solutions we create a solution we evaluate it we either modify it or we reject it and we do this and so on and so forth we end up finally with variety of solutions and then in the last phase we reduce this variety of solutions to just a few kind of solution candidates this is the example with the traveling salesman problem in the first lecture the course-grained approach we start with a random graph and we start mutating and removing links and we're kind of going to a more fine grained let's say we go to a more optimal or shortest path because the random graph is most likely way too far from being optimal we start to evaluate so in other words this means don't start to optimize every little detail and making it perfect just start from a big picture and have something that makes sense and then start to dig deeper and deeper and optimize things this is what essentially means and then the evaluation is the third phase of the problem solving cycle the second phase simply generates the end product of the second phase a generation of solution candidates and then the evaluation is the last phase this is another schematic about the whole process again it's a bit more difficult to understand so let me try to explain it the empty circles are possible solutions the circles with a letter with a letter inside selected solutions so not just C but also A and B would be selected solutions and this dot is unusable solution so what it means essentially is the following you start here this is your starting position you generate a lot of solution candidates so this one is a possible solution this one turns out not to be possible and then you select your solution candidates they have to make a choice this looks to be the best one this is the first solution idea you come to the realization that to implement it you need to do all these things so this is the idea to implement it you may need to do all these things see this is the concretization part so when you come to implementation you realize well none of these things are actually viable so what you do you go back to the beginning and you go into a different dimension you go into a different solution space somehow and then these are different solutions you select that one this is the idea you evaluate how easy it is to implement and how viable it is you find out that this action here is a good one it will actually implement it and you do it and it's over so it's a very abstract kind of a figure but the point here is the cycle this is the important point you have a solution candidate you see that it's not implementable you go back to the beginning and you start cycling through all solution candidates like this okay how from traps can we fall into when we create solution candidates I would like to repeat this point the avoiding of putting a solution hint into your objectives or into your design so this is a very sometimes natural thing that happens at the airport we have only we can only extend or we can only build a new runway and that's the only thing we can do let's see how to do it most efficiently this should be avoided because it directs you it directs you into a solution space that may end up completely completely unviable and you would never be aware of this solution space which may be extending maybe building a new runway alright again important thing quantifiable objectives yes don't fall in love with your solution I think we've all experienced this psychological effect that you tend to like your own proposal you automatically tend to disregard other proposals I myself have done this mistake quite often even though you don't realize it the best thing to do is simply ask somebody you trust don't fall in love with your solution ok now we have we have done our concept synthesis which is generating a lot of solution but this phase here the analysis we've narrowed down the possible solutions it's time it's time to assess them and basically the solution candidates that you have you don't simply assess them you don't simply disregard suboptimal ones but you rank them you create a ranking which is the best one second best, third best and so on because this thing is still open to discussion later on exactly this is very important the ranking is conditional on your objectives ok so it's important I mean the procedure of having your objectives having your solution candidates and evaluating them based on your objectives still needs to be defined and this slide basically defines this you need to evaluate your procedure sorry you need to define your procedure with evaluation for example we for instance we take these objectives and we apply them in that order to the solutions so if the solution so yeah if the solution doesn't satisfy the fifth objective it's not as bad if the solution doesn't satisfy for example the first objective and this slide would make it actually a lot easier to understand let's assume you have ok one thing I wanted to mention actually here is again even in selecting your solutions keep in mind future developments this has a lot to do with let's say if you're a company you want to purchase an information system solution from SAP for instance don't just think about the cost of the purchase but think about the total cost of ownership how much it would cost you throughout the whole life cycle of the product ok and this is an example we have here life cycle cost and here we have whatever you think effectiveness can be measured with for instance I don't know if you have an instance no there's no example but some quantifiable unit of effectiveness defects per million for instance is one and then for each so here we have right and so this is the dotted line is the so called objective function which is which is the cost which is the cost effectiveness function which basically takes your two dimensions life cycle cost and efficiency a single number which is which somehow weights these two criteria right this is one criteria this is another criteria and you need to give some weight to them for example if this is not important to you at all the objective function would simply disregard it and then you would only have high values here and low values here so this is the function basically which weights your criteria this are contour lines meaning the objective function has the same value so a solution here would have the same value to you as a solution here but it would have different performance in terms of these two in terms of these two objectives and we have three solutions A, B and C the solution A has uncertainty I think this is the last slide so yeah it's the last slide let me just finish it the solution A has certain uncertainty solution C as well solution B is actually quite quite certain and you see that the solution B has very low effectiveness but also very low life cycle cost your objective function as a consequence would be lower solution A has very high uncertainty so you may end up actually here and solution C may end up here so in total I think if you run a contour line here solution C may become better than solution A so this is a way a visual way to select your solution and these are the questions after the lecture and I'll see you next Tuesday thank you