BUS606: Operations and Supply Chain Management

Perhaps the most commonly used analytical modelling approaches in practice are those that represent processes as flowchart diagrams. Such approaches can be especially helpful for understanding, communicating, and reengineering processes. For instance, the event-driven process chain (EPC) notation maps a process in terms of activities, events, and logic gates. An application to product development is reported by Kreimeyer and Lindemann. Other similar notations include the business process modelling notation (BPMN), and the IDEF3 process description capture method. These modelling approaches may be viewed as interchangeable in many circumstances. Although the graphical notations may differ, the basic principles and focus on providing a visual notation for developing process maps are very similar. Typically, such notations provide an array of elements and graphical symbols allowing a modeller to represent additional contextual information. Some software tools provide features to support the construction of large models, for instance creating variants of a process, specifying rules to validate process models, and splitting process models across multiple diagrams.

The modelling approaches discussed above are generic and can be applied in many contexts. Focusing specifically on engineering design, Park and Cutkosky develop the design roadmap (DR) approach for modelling mature engineering design processes comprising many tasks with interactions that can be represented at multiple hierarchical levels. DR defines tasks in terms of explicit input and output information, because in comparison to representing this implicitly using arrows between tasks, "the description is more complete, the boundaries between tasks are defined, and a basis for developing interfaces between tasks is established". A noteworthy feature of DR is that it distinguishes between various types of relationships between tasks. First, strong precedence relationships strictly constrain the sequence of tasks. Second, weak precedence relationships indicate flows that may or may not occur, e.g., relating to iteration. Third, side-effect relationships indicate where a task is not necessary to produce information, but may impact it when executed. Finally, constraint relationships indicate interactions between the information produced by tasks.

A limitation of the above methods is that they provide essentially static pictures, while processes typically involve "complex interactions that can only be understood by unfolding behaviour through time". Researchers have accordingly developed computable models to study these issues using task precedence networks. The early work focused on application of program evaluation and review technique (PERT) to lay out the plan of work for development projects and then to focus management attention on the critical path. A related approach called critical chain/buffer management (CC/BM) is concerned with analysing a PERT-type network to identify buffers that protect the critical path and are used up as delays accumulate, so that those buffers can be actively managed. PERT and CC/BM are based on acyclic precedence networks and do not explicitly account for iteration, which is one of the key characteristics of the DDP. Researchers considering this limitation applied later developments of PERT, namely graphical evaluation and review technique (GERT) and its variant Q-GERT to analyse DDPs under the assumption that some tasks in the network may trigger iteration probabilistically.

Other DDP modelling approaches explicitly represent dynamic flows of information in a process using variants of the Petri net. This is a formal approach which, in its simplest form, represents a process in terms of a network of places and transitions. A transition is triggered when tokens accumulate in its input places, whereupon those tokens are absorbed and reappear in the transition's output places, potentially triggering other transitions in turn. Appropriately constructed Petri nets allow the dynamic behaviours of serial, parallel, and iterative task patterns to be modelled. For instance, McMahon and Xianyi use a Petri net-based process model as the basis of an automatic controller which directs computer processes to design a crankshaft. A shortcoming of the Petri net is that logical problems such as deadlocks can appear if the net is not appropriately structured, which becomes more difficult to achieve as the complexity of information flows and the number of possible routes increases. Considering these problems, Ha and Suh develop a set of Petri net templates that each represent a certain pattern of DDP task interactions. Larger models can then be assembled from these templates. Another issue is that, in the DDP context, it is common that changes in the planned process are required during its execution. This is also difficult to handle using Petri nets. Karniel and Reich address this issue with an approach to automatically generate or update a Petri net from a Task DSM (discussed in Sect. 4.2.2) in a way that ensures its logical correctness, thereby allowing simulation of a dynamic process involving complex information flows.

A more descriptively elaborate but less formal computable model based on a graphical precedence approach is the applied signposting model (ASM) developed by Wynn et al.. The ASM is based on a hierarchical flowchart representation intended to be scaleable and familiar to practitioners. Similar to DR, tasks are specified in terms of input and output information, different dependency types can be represented, and an abstraction hierarchy of tasks and design parameters is provided with tool support to automatically generate simplified views. The ASM simulation algorithm was developed to handle processes having multiple intertwined iteration loops, which are difficult to configure in many other approaches. It also allows flexible specification of individual tasks' behaviours. In contrast to notations such as EPC and BPMN, flow logic such as AND/OR/XOR gates is not represented graphically, because this was found to require large and complex diagrams even for relatively simple processes. Instead, such logic is embedded in the tasks' configurations. The ASM was developed and applied through industry collaborations in the aerospace sector. For example, Kerley et al. describe how the approach was applied to model and simulate jet engine conceptual design in Rolls-Royce to support integration of improved lifecycle engineering tools into the process. Hisarciklilar et al. and Zhang et al. apply the approach to determine how to reduce process span time at Bombardier Aerospace. The ASM also laid groundwork for approaches to predict change propagation in a design process, to analyse changes to the process itself, and to optimise resource allocation.

A strength of graphical task precedence approaches is their intuitive flowchart-style notation which can be easily understood by most people. Another is the flexibility; a model may be constructed at different levels of rigour and formality according to the modeller's needs and preference. However, such models also have limitations. As is apparent in the example of Fig. 8, although it is possible to model quite complex processes, graphical network models do become unwieldy as a model's structure becomes more complex and incorporates more concurrent tasks, because it becomes difficult to visually arrange and make sense of the many information flows required. Flows that connect across a long distance of the model are especially difficult to read and manipulate. The effort to make changes to a graphical model tends to increase substantially with the model's scale and density, due to the need to manually reorganise the layout and rewire the connections. Some of these difficulties may be partially addressed by organising a model hierarchically into subprocesses, but this can introduce further challenges in managing and visualising connections that cross levels and can also cause problems if the hierarchy later needs to be repartitioned. Another consideration is that if a model is used for simulation, some schemes require careful configuration and painstaking verification to ensure it operates as intended in all scenarios, especially if it incorporates a dense structure of dependencies with concurrent flows and intertwined iteration loops.

ProModeller is a task precedence approach which is not based on node-arrow diagramming and thus avoids some of these issues. This system allows modellers to represent a process by hierarchically combining process elements drawn from a standard library comprising around 50 objects, each representing either a type of task or a structural element. Tasks can be configured when instantiated into a model. Structural elements are essentially hierarchical containers that specify the procedure for attempting the objects nested within: sequentially; in a cycle of iterative refinement; concurrently; or by selecting one from a set of alternatives. The reflection of process behaviour in structure ensures that models constructed using this approach are logically correct. In consequence, it is not necessary to validate a model's structure prior to analysis. This may facilitate the distribution of modelling effort among many process participants. On the other hand, in comparison to graphical network approaches, tree-structured approaches like ProModeller provide less flexibility for modelling complex information flows and arguably a less visually intuitive representation.

The task precedence models discussed in this subsection may be especially useful where design processes are relatively routine, while also involving enough complexity that stakeholders may not fully understand them prior to modelling. These situations do often occur in practice - for instance in the evolutionary development of large-scale designs. The situated and responsive aspects of designing may be embedded in the possibility of some tasks triggering iteration, or may occur within individual tasks and thus be below the level of resolution of a model. They may also render a model inaccurate if they lead to changes in the tasks that are needed or in the way information flows between them.