Abraham Maslow’s ‘law of instrument’ says “If the only tool you have is a hammer; you tend to see every problem as a nail”. You may have heard some version of this law. We all tend to have a familiar or favourite tool that we are very eager to use whenever there is a slight opportunity. Let us rephrase Maslow's law: “If you know Systems Engineering, you tend to use it on all problems you encounter”. Maslow’s law does not say that a hammer should never be used if what you need to drive in is not a nail. It only alerts you to look for a more appropriate tool if the problem is not a nail. But once you determine that your problem is a nail, then a hammer is probably the best tool one can use! Similarly, once it is determined that the solution to a problem is a ‘system’, then we must use Systems Engineering (SE).
SE Toolkit
Before we proceed, it is critical that we clarify something here. By using Maslow’s quote, we may have equated SE to a hammer, but it was done only to bring out the importance of choosing the right tool to solve a problem. However, it must be understood that SE is not a single tool like a hammer, but rather an approach with a toolkit – a collection of various methods, processes, and techniques, including acts of thinking and communication, along with an assortment of related tools. Collectively, it is an approach that you would use when you have a system to be engineered. Some of the items in the SE toolkit are useful in other contexts such as product design, solving open problems and even in solving simple day-to-day problems in personal lives. They may go by slightly different names, but they are essentially the same. Sometimes, this becomes a challenge for the discipline of SE – people who have familiarity with a subset of SE tools may dismiss SE as nothing new.
What's the Problem?
After a satisfying career at IIT-Bombay, KS (one of the co-authors of this article/blog), is spending his retired (yet professionally active) life in a coffee estate in Wayanad, Kerala. Something that he enjoys doing these days is teaching Maths to local school children. All of us have studied Maths while at school. Whether it was a painful or a pleasurable experience is a different matter that will vary from person to person.
Initially, we would have solved straightforward problems such as ‘what is 15x3’, ‘solve for x’, ‘what is the mean, median, and mode of this set of numbers’, and so on. Just reading the problem will immediately tell us how to solve it. And as long as one does not make silly errors, we would get the answer right. Then, we would encounter ‘word problems’ , where a couple of sentences would describe some situation with numbers embedded within. Here, we had to take an additional step of understanding the problem and re-writing it in some standard mathematical format before proceeding to solve it using a familiar technique that was earlier taught in the classroom. KS finds that students who are good at multiplication and division, struggle to translate a ‘word problem’ into correct arithmetic. If a problem is stated as “If you wish to distribute 2 toffees each to all 26 students in a classroom, how many toffees will you need?”, some students translate this as “the number of toffees needed is 26/2”, and calculate the answer to be 13. You may be good at arithmetic, but if you do not fully understand the ‘word problem’ and convert it into the correct ‘equivalent problem’, your answers will be correct for the ‘incorrect equivalent problem’, but incorrect for the original ‘word problem’. (This is what Verification and Validation are all about, but we will explore this in a future article). Understanding the problem is a critical step. Real-life problems we encounter either at home or at work, are no different. They first need to be understood thoroughly, before proceeding to solve them.
At school, a Math question paper will not include science questions, and the method to solving any problem in the Math question paper would have definitely been taught in the classroom - otherwise, it would be ‘out-of-syllabus’. But there is nothing ‘out-of-syllabus’ in real-life problems if you choose to solve one. How does one ‘understand’ a problem? Where do you start? That’s where Systems Thinking (ST) makes its grand entry.
We will elaborate on ST in a separate article. Here, we will just say that one would use ST to understand the larger context within which the problem exists, and visualize the larger environment with which the potential solution would interact. By ‘solution’, we do not mean a detailed description that can immediately be realized (or built), but rather only a high-level concept to begin with. As the problem solver alternates between understanding the problem and visualising the solution, both the problem and the solution gradually gain clarity. Somewhere along the process, the problem solver shall recognise the complexity of the problem context and the complexity of the solution environment, and then recognise that the solution itself is going to be complex. Slowly, the visualisation leads to the solution becoming a system. For example, solution options to help commuters cross a water body could start with options such as row-boat or pedestrian rope-bridge, and then move on to options such as motor-boat, ferry, motorable bridge, or helicopter.
Does the Solution need SE?
At the end of the ST exercise, one may identify a set of high-level concepts that could be potential solutions for the problem at hand. This is the time to decide if SE is an essential tool to develop the solution! For SE to be employed, the solution must be a ‘system’. To determine if it is indeed a system or not, the four checks that we had proposed in an earlier article, will help (Read our previous articles: “What is NOT a System” and “CHECK: ‘System’ or ‘NOT a System’?”). To recap, the potential solution must pass these checks to be considered a system:
Check-1: The solution must be intentionally made by humans. If the solution already exists, then this check fails.
Check-2: The solution must serve a stated purpose. As long as the problem at hand has been explicitly stated by someone (individual or organization), this check is passed.
Check-3: The solution must be decomposable. It cannot be a monolith.
Check-4: There must be a purpose for decomposing the solution. The solution must be decomposed in order to manage its engineering (including designing and developing), for purposes of complexity, schedule, resources, or any such factor.
Once it is clear that the solution is going to be a ‘system’, then one must use SE. This will greatly increase the chances of developing an effective solution in an efficient manner, and getting it right the very first time!
In some cases though, it would be clear right at the beginning that the solution is going to be a system. For example, an automobile company developing a new electric car need not start by looking at all possible options for mobility between two points, but rather start by exploring various concepts of electric cars.
We began this article with Maslow’s law about a hammer and nail, and used it to elaborate on the importance of first determining if you really need to use SE before actually beginning to use it. We also clarified that while a hammer is a single tool, SE is an approach with a toolkit replete with a variety of tools, including a universal tool - Systems Thinking. Now, we wish to conclude this article by presenting two laws that summarize our message here (and we are calling them “SE360 Laws”, named after our blog):
SE360-Law#1: "If the solution to a problem is going to be an engineered system, you shall use Systems Engineering".
SE360-Law#2: "If you know Systems Engineering, you could use some of it on any problem you may encounter - just do not claim that you are using Systems Engineering”.
- KS & DH
To know more about us, read our blog launch article
コメント