Hard systems Thinking

Hard systems Thinking

In the previous chapters we introduced what a system is, developed various concepts and definitions that underpin systems thinking, and introduced a number of complementary systems thinking models and frameworks, which provide different perspectives on systems.

In Chapter 2, when we introduced systems, we differentiated between hard and soft systems and suggested the following definitions:

Hard system: a system consisting of high-integrity parts that are connected through well-understood interaction patterns producing predictable behaviours.

Soft system: a system consisting of autonomous parts that are characterized by high variability and unpredictable behaviours and connected through a loosely defined dynamic web of relationships, power structures, shared interests and values.

In this chapter, we introduce hard systems thinking and several approaches for modelling hard systems. We will start by outlining the characteristics of hard systems and then take you through some of the commonly used hard systems modelling techniques. The penultimate section will outline the key limitations of hard systems modelling techniques and provide examples of how organizations can overcome these limitations in innovative ways. These examples will serve as a transition to the next chapter on modelling of soft systems.

LEARNING OUTCOMES

.Understand hard systems and hard systems thinking

.Become familiar with different approaches to hard systems modelling including

.flow charts and data flow diagrams

.structured systems analysis and design method (SSADM) and the integrated definition (IDEF) method

.process maps, including swim lane process maps

.value stream maps

.discrete event and agent-based simulation techniques

.Be able to use the hard systems modelling techniques to create models of simple systems

.Understand the limitations of hard systems modelling and hard systems thinking

.Develop strategies for overcoming these limitations

5.1 Characteristics of hard systems and hard systems thinking

Earlier we defined a system as consisting of different parts, which interact with each other, producing a certain kind of behaviour that could be more or less predictable. We also defined hard systems as consisting of high-integrity parts that are connected through well-understood interaction patterns producing predictable behaviours. From this definition, we can deduce that the key characteristics of hard systems are their predictable behaviours, caused by high-integrity parts that are connected through well-understood interactions.

In this context, high-integrity parts mean that each part operates within tight tolerances and the amount of variation in each part is understood and predictable. Typically, the performance of each part of a hard system would not be affected by different worldviews, mood swings, and other unpredictable behaviours associated with people and animals. Just think about why in show business they say never work with animals. In short, in hard systems there are no unpredictable variations in the behaviour of each part. We expect each part in a hard system to conform to a statistically and mathematically explainable, repeatable, and reliable behavioural pattern. In a similar vein, in hard systems, we also expect to see well-understood (i.e., statistically and mathematically explainable) repeatable and reliable interactions to take place between different parts of the system.

Over time each part in a system will suffer wear and tear, particularly if not maintained. Consequently, the variation in the behaviour of each part as well as the interconnections will change (i.e. entropy). However, in hard systems even the rate of deterioration is predictable and well understood, and in many cases it is mathematically and statistically explainable. This is how manufacturers can define the service life of a light bulb or the maintenance schedule of your car.

As an example, a car serviced by the manufacturer’s approved specialist service centre with trained technicians using approved replacement parts is less likely to suffer from breakdowns compared to the same car serviced by a generalist mechanic. The specialist will have information on how different parts behave over time, and what parts wear faster and need to be inspected, lubricated or changed before they fail. The generalist mechanic is unlikely to have the same level of knowledge and will most probably apply the same maintenance routine to all cars; thus the car is likely to break down more quickly.

In hard systems, feedback from the system can be used to compensate for deviation from the expected outcomes by adjusting technical control parameters. In some systems this adjustment can happen automatically in the system based on some predefined rules. In other systems the feedback may be used to send a signal (possibly an algedonic signal in the Viable Systems Model) to an external party for a corrective action to take place. We can best see this feedback and automatic/manual intervention in the human body, wherein the body, if healthy, automatically controls the amount of sugar in the blood. When a person has diabetes, there are external sensors available that can send the person a message when the blood sugar level raises and the person can then manually administer insulin. In both cases, we are dealing with a hard system inside the human body that is measurable and predictable, enabling feedback to be used to compensate for deviation.

At this point we can summarize the characteristics of hard systems as follows:

.predictable behaviours

.high-integrity parts

.high-integrity connections

Hard systems thinking is a way of thinking about systems whereby the analyst/thinker is assuming that systems behave as hard systems, i.e. they are predictable. In hard systems thinking it is assumed that the analyst can understand the system’s current (or as-is) behaviour by modelling each part and the interactions between these parts. They can then go on and change parts and/or interactions of the system to define a new system with improved behaviour (make it more efficient or more effective, eliminate or reduce a problem, exploit an opportunity, etc.). The behaviour of this new (or to-be) system will be as intended, i.e. predictable.

In the following sections we will outline various techniques for modelling hard systems, or modelling systems from a hard systems perspective. This is not intended to be an exhaustive list of systems modelling techniques and indeed there are many commercial tools available that use these techniques, or variations of them, to help model hard systems. All of these techniques can be used to model the current (as-is) system as well as the desired new (to-be) systems.

5.2 Flowcharts

Flowcharts are one of the simplest systems modelling tools. A flowchart is a diagram that uses standard symbols to illustrate various activities of a process in sequential order. They are typically used to describe process flows in different processes including manufacturing, service, administrative and software. Although its main purpose is to model flows of activity within a process, it can be adapted for a variety of purposes, including modelling the flows within a system.

Figure 5.1 illustrates the most commonly used flowchart symbols together with an example of how these symbols are used to construct a flowchart that connects various activities (parts) of a customer order planning system. Essentially it describes the flow of work through the system by connecting various parts of the system in a logical sequence.

Figure 5.1 describes a simple customer order planning system which starts with the receipt of the customer order electronically as an entry into a database. It is then entered into the sales order processing system (SOPS). In the next stage, the customer’s credit status is checked automatically using a predefined criterion. If the credit status is passed, i.e. the customer’s credit status is within defined limits, then the order is planned into the production schedule and the output from the system is the production schedule in the form of a document. If the customer fails to pass the credit check, then they are contacted and the order is put on hold until the credit status is cleared.

Naturally, we can expand this flowchart to develop further detail around this simple system by flowcharting how the credit is checked, how the customer is contacted, etc. However, it might be more practical to describe these subsystems on different flowcharts to avoid overcomplicating the flowchart.

5.3 Data-flow diagrams

Data-flow diagrams (DFDs) are a form of flowchart that provide the means of representing flow of data through a system. Although DFDs use only four symbols to enable modelling of data flows through the system, the nature of the symbols can change depending on the notation used:

Entity, which is the process, function or subsystem that transforms inputs to outputs. Depending on the notation, the symbol used can be a circle, an oval, a rectangle or a rectangle with rounded corners.

Flow, shown in the form of an arrow, connects entities to one another. The arrow shows the direction of the data flow between the entities. Although originally conceived to illustrate data or information flows, it is now often used to also show other flows, such as materials, people, customers and decisions. Although we could argue that a decision is simply an information flow as illustrated in Figure 5.2. In some cases the flows can be bidirectional to illustrate that the entities are logically interdependent.

Store (warehouse, database or file) is used to illustrate storage of whatever is flowing between entities, represented by two horizontal lines. The store does not have to be a warehouse, database or a file – it can also be a filing cabinet where documents are stored or even a hotel or a hospital where people are staying.

External entity, sometimes referred to as terminal, stands outside the boundaries of the system but interacts with the system. It can be a computer system, an organization, a person, groups of people and so on. The key criterion here is that the entity sits outside the boundaries of the system and interacts with the system through flows.

Figure 5.2 illustrates the symbols used in two common notations. Here you will notice that the symbols for entity and external entity are the same. However, usually the analyst would use symbols with different shapes to differentiate between internal and external entities.

Figure 5.3 illustrates the use of the DFDs to model the customer order planning system we described in the previous section. Here the customer and the production department are external entities shown as rectangles. The entities within the system are shown using oval symbols. The customer order is received from the customer and is stored in the sales orders database. The process outlined in Figure 5.3 is as follows:

1.The customer order is received from the customer and is stored in the sales orders database.

2.The process sales order function takes the customer’s order from the sales database, processes it and passes it on to the check credit function for checking the customer’s credit status against the customer accounts file.

3.If the order value exceeds the customer’s credit limit the credit check fails, and this information is passed to the contact customer function (a decision flow); the function contacts the customer and a two-way dialogue takes place, illustrated by the bidirectional arrow.

4.As a result of this dialogue, if the customer’s credit issue is resolved, for example by increasing the customer’s credit limit or the customer making a payment, then the customer credit status is updated.

5.As a result, the order passes the credit check and the order details are communicated to the plan production function which plans production and issues the production schedule to the production department.

The key differences between flowcharts and DFDs are that:

.DFDs use fewer symbols

.The flows between entities are annotated to describe the nature of the flows

.There is no time element represented, rather the sequence of activities is determined by the flow

5.4 Structured systems analysis and design method and integrated definition

The structured systems analysis and design method (SSADM) is a further development from DFDs. It was initially developed to deal with analysis and design of complex computer systems for the UK Government’s Central Computer and Telecommunications Agency in the early 1980s. SSADM has evolved over the years and in 2000 it was repackaged as the business system development method. In summary, SSADM comprises three modelling techniques:

.Data modelling details the data requirements of a system. The data model contains entities about which business needs to record information, attributes that represent the facts about these entities, and relationships between these entities.

.Data flow modelling details how data moves through the system. Similar to DFDs, this technique details activities that transform data from one form to another, data stores where data is stored, external entities that send or receive data from a system, and data flows.

.Entity event modelling details the events and their sequence that impact on an entity and consequently affect the behaviour of the system over time.

Integrated Definition (IDEF) is a set of modelling techniques that built upon SSADM and emerged from the field of systems and software engineering. These modelling approaches were developed for the United States Air Force.

and other public agencies to enable modelling complex information and engineering systems. The set of modelling techniques, identified as IDEF14, covers a wide range of purposes including functional modelling, data modelling, simulation, object-oriented modelling, knowledge modelling, constraint modelling, organization modelling and network modelling.

In relation to systems thinking and modelling of hard systems, the most widely used technique is the IDEF0 functional modelling technique, which is similar to SSADM’s functional modelling. In the following paragraphs we further explain the IDEF0 technique; however, we will refrain from going into additional detail on other SSADM or IDEF approaches as they are infrequently used in systems thinking and are more useful when analysing, modelling and designing complex software or engineering systems.

The IDEF0 or SSADM functional modelling approach uses the inputs, controls, outputs and mechanisms (ICOM) to model the relationship between entities, similar to our earlier conceptualization of a system in Chapter 3. In this context, the entity (system, subsystem or activity) transforms inputs to outputs under the rules, policies and/or constraints imposed by the controls and using the mechanisms (means or resources) available. These entities are linked together through these ICOMs, where an output from an entity can be an input, control (e.g. a policy decision) or even a mechanism (e.g. a tool) for another entity. A key feature of this approach is that the details of each entity can be modelled in greater detail in the next levels of analysis as illustrated in Figure 5.4, which is consistent with the recursive nature of systems discussed in the previous chapter.

In Figure 5.5 we have illustrated modelling of the customer order planning system using the IDEF0/SSADM approach through this simplified and rather abstract example. Here we can see the same customer order planning system described with additional details. At Level 0 we only see the process as a whole with the key input (Customer Order) and the output (Production Schedule), as well as controls and mechanisms summarized as Various Controls and Various Mechanisms.

At level 1 we see the next level of detail. The customer order is entered into the sales database (not shown) by the sales agent using the sales order processing system by the sales agent. We can also observe that this activity takes place during working hours (9 am–5 pm) five days per week due to the working hours policy of the company, indicating a potential constraint. Once the processed order is received by the financial controller (a mechanism), the check credit activity commences. Finance system (another mechanism) enables this activity and is controlled or constrained by the information.

"available from the external credit rating agency. If the credit check fails, the customer services department (mechanism) is contacted, and then in turn contacts the customer. As an outcome of this dialogue, if the credit issue is resolved (e.g. customer makes a payment) then the order is forwarded to the plan updated. If the credit check is passed, then the order is forwarded to the production planner (mechanism) uses the production activity, where the production planner (another mechanism) to produce the production schedule. Here the control suggests that the production schedule is issued once a week on a Thursday, which may be another constraint.

At level 2, we see another level of detail that models the check credit activity. Here the credit controller (mechanism) compares the customer’s credit balance to their credit limit. If the credit balance is within the limit the order is passed; if it exceeds the limit the credit check fails and the order is put on hold. If the credit check is failed then the first step is for the credit controller (mechanism) to contact the sales representative who is dealing with this customer to ascertain further information, as a result of which the credit issue may be resolved and the order passed. If the credit issue is not resolved, then the credit controller (mechanism) contacts the finance director together with information on the customer’s credit rating from an external credit rating agency (control). The outcome of this can be that the customer’s credit limit is extended and the credit is passed."

The IDEF0/SSADM technique comes with rigorous guidelines to help users to consistently apply and develop functional models of the systems. Although the rules and guidelines for constructing such models are outside the scope of this book, we will give some examples. One of the rules of this approach is that any system should have no less than two and no more than seven sub-systems. Whilst the bottom limit of two is obvious, the top limit of seven is based on the psychology literature that states that any system with more than seven parts would be too complicated to comprehend. Another guideline is the numbering convention that should be used when creating these models so that it would be easy to relate various models to one another.

IDEF0/SSADM when used with rigour can help to uncover a lot of detail within a system. The only issue is that even with just two levels of analysis, as illustrated in our example, a lot of detailed documentation is produced representing a lot of person-hours of work. During the 1990s it was widely used to model the business processes of organizations before making investments into computer systems such as enterprise resource planning systems. In our experience, these resulted in models running into hundreds of pages of diagrams and associated narratives, which requires more time and effort to maintain and update as systems change.

5.5 Process mapping or business process modelling

Process mapping or business process modelling is widely used in business process management and systems engineering. It focuses on illustrating the processes, sub-processes and activities of an organization with a purpose to understand, analyse, improve and automate these processes. In fact, the techniques discussed thus far have all been used in one way or another to model business processes. However, some users have developed methods with fewer formalities and some of these approaches have been converted into software-based tools to help users model business processes. One of the simplest approaches for modelling business processes is the use of sticky notes on a wall or a similar surface, where the entire business process is modelled end-to-end on a single wall. Although this approach is less formal and less rigorous than DFDs or IDEF0/SSADM for modelling the system, it can generate results a lot more quickly whilst enabling the users to be creative with their modelling approach, capturing key details that may be missed through more formalized approaches. An example of such a process map is illustrated in Figure 5.6.

5.6 Swim lane process maps and flowcharts

This is a development of the simple process maps or flowcharts covered earlier in this section. It simply organizes the symbols into relevant lanes to show additional information on who or which function is responsible for the part of the process. An example of a swim lane flowchart for the customer order planning systems is provided in Figure 5.7.

5.7 Value stream mapping

Value stream mapping (VSM) is a technique that emerged from the lean thinking or lean management movement (Womack and Jones, 2003), which in turn is a development of lean manufacturing principles (Womack et al., 1990). Lean management is a methodology that focuses on minimizing waste within organizations while simultaneously maximizing quality, productivity, and customer service performance. It is a customer-focused approach where waste is defined as anything that customers do not believe adds value and are not willing to pay for.

Value-stream mapping was developed specifically to address the needs of lean management by focusing on identifying waste in the system. This is achieved by focusing on activities that add value and eliminating, or minimizing, activities that do not add value. VSM visually analyses the series of events that take a product or service from the beginning (e.g., receiving raw materials) until it reaches the customer. As in previous approaches, it focuses on the flow of information, materials and/or people at each stage of the process, quantifies the time taken at each stage, and classifies this time as either value-adding time or non-value-adding time. The final output from the analysis is an in-depth understanding of waste across the system, which enables quantification of the value-added time as a ratio (value add ratio) and percentage of the overall time consumed across the system. An example of value stream mapping is illustrated in Figure 5.8.

The value stream map starts with the customer at the top-right-hand corner. We can observe that the customer issues a long-term forecast against which they place weekly orders and they call off these weekly orders on a daily basis with variable quantities. Moving left, we can also observe that at any time the customer has about two days of stock available. The manufacturing company uses this information to produce and agree upon a customer delivery schedule, which takes around 20 hours per month to complete. This delivery schedule is used to develop a production plan (taking three hours per week) and a materials plan (taking 24 hours per week). The production plan is used for management of daily production priorities by the manufacturing supervisors. The materials plans are used to provide the suppliers with a long-term forecast, weekly demand schedule, and daily expedites. The supplier delivers materials to the production site twice weekly and the time taken for these deliveries is unknown.

The lower part of the value stream map illustrates each stage of the production process starting from materials receipt through to packing and dispatch of the finished product to the customer. For each manufacturing stage, the minimum and maximum time taken to complete each stage for a typical batch has been recorded along with other pertinent information relevant to each stage of the manufacturing process. This information includes the status between each stage of the manufacturing process, depicted by the angle and the inventory level below the triangle, as well as the quality in the action policies used at each stage of the manufacturing process.

At the bottom of the figure, we can see that the total production lead time varies between 26 and 110 hours, whereas the value-added time at each stage is much smaller, totalling 9.5 hours across the entire production process. This makes the value-added ratio of 36 per cent at best and 8.6 per cent at worst. In this case, the value-added time at each stage of the production process is computed based on the fastest time it takes to complete each stage for a typical batch with no interruptions, breakdowns, and so on. We can also observe that stages such as materials receipt, materials inspection, final inspection and testing, and packing and dispatch, although they may be necessary, are not counted as value-adding activities.

VSM helps us to understand the waste within the system, as defined in lean management, thus helping us to optimize the system design to minimize waste. In this respect, different stakeholders may interpret the definition of waste differently. In the example about whilst packaging was considered a waste, in other instances it may be considered a value-adding aspect of the product, particularly if it makes the product more attractive and motivates the customer to choose your product over a competitor's product.

VSM helps us to understand the waste within the system, as defined in lean management, thus helping us to optimize the system design to minimize waste. In this respect, different stakeholders may interpret the definition of waste differently. In the example about whilst packaging was considered a waste, in other instances it may be considered a value-adding aspect of the product, particularly if it makes the product more attractive and motivates the customer to choose your product over a competitor’s product.

In this section we will refrain from providing further details on the construction of value stream maps and their variations. There are comprehensive guidance resources available online. We have also found Rother and Shook’s (1999) book titled Learning to See: Value-stream mapping to create value and eliminate muda a valuable reference (muda meaning waste in Japanese).

Over the years we have also come across innovative ways of creating visual value stream maps. This has been achieved by using videos or still photos of each stage of the process and organizing them in such a way that they tell a story of what is value-adding and what is not value-adding in the entire system. The video (see video link 5.1 in the online resources on the Koganpage.com product page) produced by Mercury Marine, although 13 years old, is a good example of applying this technique. These innovative approaches help us to more effectively tell a story about the system and its behaviour.

5.8 Discrete Event Simulation

Discrete Event Simulation (DES) is a simulation-based approach used for modeling systems (Allen, 2011). It models the flow of work through the system as a discrete set of events over time. Each event occurs either at a specific instant in time (e.g., 10:05 am every day) or following completion of a specific event (e.g., when the order entry event is complete, the credit control event will commence) and marks a change in the overall state of the system. DES assumes that the state of the system does not change between events; therefore, the simulation time can fast-forward directly to the next event. DES is commonly used to model business and manufacturing processes. The customer order planning system we have used as an example throughout the system can easily be modeled using the DES approach.

As DES is a time-based simulation, in addition to having the sequence of events, i.e., activities, we would also need to have variables such as processing times (e.g., the time it takes the sales department to enter the order into the system), queue time (e.g., the length of time the order has to wait in the sales department’s inbox before they get around to processing the order), various statistical and computational algorithms such as probability distributions, and confidence intervals. The Monte Carlo method as well as random number generators used to model variations in order/materials arrival rates and patterns, capacities, queue times and processing times of various events.

Although it is possible to develop DES models of very simple systems using spreadsheet software, due to the complexity of the systems and the volume of variables and associated algorithms and data involved, it is more likely that DES models are built using proprietary or open-source DES software tools. Today, DES is commonly used to model in a variety of contexts. Some examples include:

.Understanding bottlenecks in a complex manufacturing or traffic flow system. By accurately simulating the system, it is possible to gain a detailed understanding of the conditions (such as specific combinations of variations at different events and times) that could create bottlenecks at critical resources.

.Optimizing queuing systems at road junctions, hospitals, call centers, and other such systems by better understanding the interplay between various factors and variations.

.Testing the potential impact of potential interventions to improve system performance, including stress testing solutions to see whether a particular set of conditions would cause the system to fail.

.Evaluating investment decisions and potential alternatives by simulating their implications under different conditions.

In short, unlike other hard systems modeling approaches discussed earlier in this chapter, DES provides an opportunity for observing a system under dynamic conditions, i.e., a working model of the system, rather than the static models offered by other approaches. This allows management to understand the interaction between performance drivers and performance outcomes in a dynamic context. Although most DES software tools provide visualization of the system, such as various entities (customers, information, materials, people) flowing through the system, the real value from DES and other simulation models is the statistics, such as the arrival rates, resource utilization, queue times, etc., over time, which enables us to understand how different variables in the system interact to define the system’s behavior.

5.9 Agent-based modelling and simulation

Agent-based modelling (ABM) is also a simulation modelling method (Macy and North, 2009), but is different from DES as it focuses on modeling and simulating autonomous parts, i.e., agents, as well as their individual behaviors and interactions. In contrast, DES does not lend itself to the modeling of systems where each part of the system is an autonomous agent.

In ABM, different agents exhibit behaviors which can be described by a set of relatively simple rules. An agent interacts with other agents and their environment, which may influence their behavior and, in turn, they may influence the behavior of other agents. The modeling is constructed from the bottom up, describing each agent and the rules governing their behavior and interactions from which a large-scale self-organizing system may emerge. This emergence of self-organization is the first of the two important features of this method. Each agent pursues its own interest in the system, and as the simulation progresses, the agents can have the ability to adapt to the changing environment.

environment. Diversity of agents is the second of the two important features of this method.

As a result, ABM allows us to construct the complex interrelationships of decisions of interacting agents while providing an environment for exploring the collective behaviour of agents. In other words, higher-level system properties that were not explicitly programmed in the system emerge from the lower-level subsystems. Hence ABM allows us to build and test models depicting particular behaviours that can then inform decisions about how to change the system. This approach allows us to simulate a complex system that is impossible to do using deterministic methods. The ability to incorporate the adaptability of the behaviour of the agents enables modelling of complex adaptive systems.

An agent-based model typically has the following three components:

1.Agents with their properties/attributes and behaviours.

2.Relationships or interactions between the agents (how each agent interacts and with whom) that create an underlying topology of interconnectedness.

3.Interactions of the agents with the surrounding environment.

The agents in the model have distinctive attributes that make them recognizable by other agents. They are autonomous and can execute their specific functions at least for a limited period of time. However, they also have dynamic interactions with other agents that might influence their behaviour over time. Agents also have access to only local information from other agents, which is defined either by close proximity to them or from the local environment, or by their own network. Both are defined and controlled by the modeler. This makes ABM ideal for modelling decentralized systems with no central entity distributing information to agents or exercising control over the agents. However, this method can also be used to model systems with centralized control, with a main agent that can exercise some control. Information that agents obtain from the local environment can either be specific to their environment, such as their locations, behaviours, or certain attributes, or relating to objects within their environment, thus enabling an agent’s actions. For instance, in a transportation model, the available infrastructure and its capacity may provide information about the agent to perform certain actions to make use of this infrastructure. If you would like to learn this method in more detail, the Examples of using ABM include:

.Understanding water consumption behavior of residents in response to different policies and demand management strategies. ABM allows us to examine water conservation tendencies among different groups of users, each with their unique attributes, such as income level and access to information, and explore different scenarios determined by the application of different strategies.

.Analyzing transport-sharing schemes (such as car- or bike-sharing schemes) and different incentives that might alter user behavior. ABM allows us to test the effectiveness of different incentives aimed at encouraging users to choose alternative stations preferred by the system as their pick-up or drop-off points.

.Improving efficiency of logistics operations in retail by involving customers in making deliveries (customer crowd-shipping). ABM allows us to model the delivery of customer orders by a dedicated fleet (not autonomous agents) and customers as autonomous delivery agents making decisions about a delivery in response to different incentives.

In short, ABM allows us to observe the behavior of a system under dynamic conditions and explore emergent behaviors under different scenarios. What makes it a distinctive approach is the focus on capturing the behavior of autonomous agents and allowing for modeling adaptive behavior in response to the behavior of other agents. This makes it possible to model complex and adaptive system behaviors with emergent properties that are not programmed in advance but are rather revealed over time during the simulation.

5.10 Hard systems modelling: limitations and innovations

In this chapter so far we have covered a number of different approaches that we can use for modelling hard systems. There are no strict formalities with these approaches unless one wants to or there are contractual obligations for using a formal methodology such as SSADM or IDEF. In many cases the A system analyst will use one or a combination of these approaches to model the system to suit the needs of their project. In practice, we see many innovations around these approaches as exemplified by the use of still images and videos to bring the system to life as shown by the Mercury Marine example above. It is, however, important to emphasize that when we are modelling systems, the simpler it is and the more visual it is the more people will understand it and engage with it.

The key limitation of hard systems modelling techniques is that in business and management we tend to work with human-centred systems that have both technical/hard and social/soft dimensions. So, whilst using hard systems approaches helps to rigorously capture the procedural and tangible aspects of the system, it is likely that we will not be able to capture the softer social aspects (in memos and emails, behind closed office doors, informal conversations in corridors, around water coolers or coffee machines) that are most likely to shape the behaviour of the system. Recognition of these limitations has led some analysts to adopt further innovations as illustrated in the following case study.

CASE STUDY: A systems thinking case study

Figure 5.9 shows a model of the end-to-end process for a large engineering manufacturing company, from receiving an enquiry, through proposal preparation, proposal issue, winning the order, and so on, to delivering the order to the customer, gaining customer satisfaction, getting paid and closing the contract. In the photograph, you can see some of the stages of the process identified by the labels hanging on the ceiling. On the floor, you can see an SSADM approach to model the process in some detail. The company has chosen to use paper-based maps because having all these process maps on the computer or in folders was not user-friendly and very few people other than the analysts (i.e., the team who compiled them) understood what they really meant. So, making the model visual and enabling people to walk through the system was the first development.

When the team started to walk people through the process, they discovered that those participating started sharing stories about what was really happening behind this process. It became apparent that the process maps, while describing the procedural and tangible aspects of the process, also helped to surface the social interactions that shaped the behavior of the system. After walking many people through the process and listening to their stories, they developed a range of stories and roleplayed these stories along the process to raise awareness of both functional and dysfunctional aspects of the system.

The following dialogue is a short extract from one of these roleplays where an order fulfilment process is being enacted. All the engineering and manufacturing has been done, the product is at the final testing stage and the customer is about to fly in to witness the final acceptance test...

Mark (production manager): Hi Jim (sales engineer), I just heard that we have problems with the final testing. We are trying to sort it out but we need more time. Any chance you can delay the customer a little bit?

Jim: Oh darn, how long do you need?

Mark: I need at least six hours, but to be on the safe side a day would be much better. Can you delay him until tomorrow afternoon?

Jim: He is flying in later this morning, I’ll see what I can do—I think he likes playing golf!

Later at the airport Jimmy is meeting the customer’s engineer (Tom)...

Jim: Welcome to the UK Tom. I thought that since this is your first visit to this part of the world, I have taken the liberty of booking us into the Golden Eagle hotel. I believe you play golf, so I am planning to take you out for a round of golf this afternoon. We’ll stay at the hotel tonight and head down to the plant in the morning. Your test is scheduled for tomorrow afternoon, and we can still have you on the first flight the next morning.

Tom: I thought the test was scheduled for this afternoon.

Jim: To be honest, I thought so too. I am not entirely sure what happened, but it was the planning department who changed the schedule. I do not think it affects our schedule; I hope you are OK with all this.

As can be observed through this interaction, there is a hidden, arguably dysfunctional, dynamic within the system which was not captured by the SSADM-based hard systems thinking. In this example, the management team made the process visual by laying it out on the floor as a process map and then brought the real issues to the surface by storytelling and roleplaying along the process.

As we have demonstrated in this chapter, hard systems approaches can be used very effectively to capture the procedural and tangible aspect of a system, which is all that is needed for a computer program or an engineering system. However, in business and management where we have to deal with organizations, the key limitation of the hard systems approach is that it is...

largely impossible to capture the hidden social system using hard system techniques alone.

5.11 Summary

In this chapter our objective was to introduce you to hard systems thinking and help you to better understand the characteristics of hard systems. In doing this we also introduced you to commonly used hard systems modelling techniques. The techniques we selected to include in this chapter, whilst not being exhaustive, were intended to provide different perspectives and levels of sophistication to the modelling of hard systems.

Whilst most of the techniques used for modelling hard systems had their origins in the information systems field (such as flowcharts, DFDs and SSADM/IDEF), other approaches such as process mapping, swim lane process modelling and value stream mapping are innovations that emerged from business process management, quality management and lean management disciplines.

 In the penultimate section we outlined the key limitations of hard systems modelling techniques with some examples of how organizations overcame these limitations in innovative ways. From these discussions it is clear that whilst being effective when dealing with engineered systems, from a business and management perspective, hard systems thinking and associated modelling approaches by themselves are not entirely sufficient to provide a complete understanding of a complex human activity system.

In the next chapter, introducing soft systems thinking, we will further reinforce the differences between hard and soft systems approaches by focusing on the characteristics of soft systems. We will also introduce techniques for modelling soft systems.

REFLECTIVE EXERCISE

Think about a small system you know fairly well. This could be a small part of the organization you work or study in. It could be a system related to a sports or arts club, your family or friends, or even a system you use regularly (e.g., a bicycle). Try to use three different techniques to model the system, like:

1 Flowcharts

2 Data Flow Diagrams

3 SSADM

4 Value Stream Mapping

Reflect on what you found easy while doing it. Then reflect on the aspects you found difficult. Was the problem in the modeling technique, i.e., it did not allow you to model what you wanted to explain? Or was it in your knowledge of the system? If it was the latter, a key function of any modeling technique is to make the analyst think about what they know and don't know about the system so that they know what questions they need to ask to develop a complete view. If it was the former, perhaps the technique is not suitable for the system you were trying to model, or you were trying to model some of the softer aspects of the system for which hard systems modeling techniques are not well suited.

TEAM EXERCISE

The objective of the exercise is to experience hard systems thinking and learn about relative merits and limitations of different hard systems modeling techniques.

Provide the participants with a bicycle or a detailed picture of a bicycle. Ask them to use SSADM in a rudimentary form to model how a bicycle works. The first thing they need to identify is all the subsystems of a bicycle. At this stage do not worry about the SSADM rule of a maximum seven subsystems. In general, the following are the subsystems of the bike:

.Frame, including the seat post where the rider sits.

.Drive system, including the pedals, sprockets, gears, rear wheel and tyre.

.Steering system, including the handlebar, front forks, front wheel and tyre.

.Braking system, including brake levers, brake calipers and brake pads.

.The rider, including arms, legs, torso and head. We need the rider included in this system as the bicycle will not work without the rider.

Then ask the participants to try to model how a bicycle works using the relationship between the parts. For example, the rider sits on the seat post, which is part of the frame, and holds the handlebars and places their feet on the pedals. The rider exerts force in a circular motion on the pedals, which transmit this force through the chain and sprockets to the rear wheel, providing forward motion... and so on.

With the above objective in mind, it is worth doing this exercise with groups of two or three participants and then comparing what each group has done and sharing what aspects of the exercise they found easy and what they found difficult.

References

Allen, TT (2011) Introduction to Discrete Event Simulation and Agent-based Modeling: Voting systems, health care, military, and manufacturing, Springer Science & Business Media

Macal, CM and North, MJ (2009) Agent-based modeling and simulation. In Proceedings of the 2009 Winter Simulation Conference (WSC) (pp. 86–98), IEEE

Rother, M and Shook, J (1999) Learning to See: Value-stream mapping to create value and eliminate muda, Brookline, Massachusetts: Lean Enterprise Institute

Taylor, S (Ed) (2014) Agent-based Modeling and Simulation, Springer

Womack, JP and Jones, DT (2003) Lean Thinking: Banish waste and create wealth in your corporation, Simon and Schuster, p 10

Womack, JP, Jones, DT and Roos, D (1990) The Machine that Changed the World, Rawson Associates, New York

Further Reading

.Downs, E., Clare, P., and Coe, I. (1992) Structured Systems Analysis and Design Method Application and Context, Prentice-Hall, Inc.

.Goodland, M. and Slater, C. (1995) SSADM A Practical Approach (version 4), McGraw-Hill, Berkshire.

.Hanrahan, R. P. (1995) The IDEF Process Modelling Methodology, Software Technology Support Center, pp. 1–8.