# Modelling Framework to Support Decision-Making in Manufacturing Enterprises

Authors: Tariq Masood; Richard H. Weston
Journal: Advances in Decision Sciences
 (2013)

---

## Abstract

Systematic model-driven decision-making is crucial to design, engineer, and transform manufacturing enterprises (MEs). Choosing and applying the best philosophies and techniques is challenging as most MEs deploy complex and unique configurations of process-resource systems and seek economies of scope and scale in respect of changing and distinctive product flows. This paper presents a novel systematicenhanced integrated modelling framework to facilitate transformation of MEs, which is centred on CIMOSA. Application of the new framework in an automotive industrial case study is also presented. The following new contributions to knowledge are made: (1) an innovative structured framework that can support various decisions in design, optimisation, and control to reconfigure MEs; (2) an enriched and generic process modelling approach with capability to represent both static and dynamic aspects of MEs; and (3) an automotive industrial case application showing benefits in terms of reduced lead time and cost with improved responsiveness of process-resource system with a special focus on PPC. It is anticipated that the new framework is not limited to only automotive industry but has a wider scope of application. Therefore, it would be interesting to extend its testing with different configurations and decision-making levels.


---

## Body

## 1. Need for Responsive Manufacturing Enterprises

Making well-informed decisions that lead to timely responses to change is vital to the long-term existence of many MEs [1–3]. Present day MEs cannot sustain if they concentrate only on their current set of products and services and on their current operational procedures, processes, and systems. Over shortening life spans of products the profits that can be gained from fixed production systems will vary significantly over time. Hence the long-term success of a company lies not only in the capabilities and attractiveness of its products but also in the product realising systems it uses to make products and in the processes it uses to engineer change to its product realising systems [4]. According to a survey of manufacturers [5], it is evident that many companies need to continue to transform their systems (see Figure 1). For instance, in 2006, 57% of manufacturers thought that new product development was a key priority in their business. This kind of enterprise transformation will often lead to needed changes in production lines, raw materials, and/or supply chains, and this was reported to be another strategic area of importance for 58% of manufacturers in 2006. There are many other challenges to present day MEs like continuing to succeed despite growing business competition, finding better ways of coping with increased complexity of products and processes, and an increasing need to make rapid responses to changing requirements of customers. Although MEs are typically supported by a variety of suitably engineered human and machine resources, information systems and organisation structures, nonresponsiveness may mean an end to any given business. The next generation of manufacturing systems therefore, need to be suitably reconfigured on an ongoing basis by effective processes of change engineering, which generally will require complex processes involving many types of decision-making [1–3].Figure 1
Key priorities in business strategy [5].The present day customer typically imposes significant problems to and constraints on MEs. For example, they may request change in product qualities, quantities, cost, delivery, and service performance. Implications of a customer focus are time to market is shortening, products need to be tailored to meet a breadth of customer needs, and demand is variable [6–8]. However, normally MEs cannot simply respond by rapidly deploying new processes and resources. Generally they need to redeploy (i.e., reconfigure and reintegrate) their existing processes and resources such that they can respond competitively on an ongoing basis.The manufacturing world is continually changing. It is moving focus from economy of scale to an economy of scope and is becoming a global economy for mass customisation [9]. For many companies around the world, staying in business means to meet customer requirements and be innovative, reduce the time-to-market of products, and manufacture quality products at competitive cost. In the wake of this rapidly changing business environment, new generations of reconfigurable manufacturing systems have emerged and new ME organising structural patterns and systems are being deployed. To complement these advances, however, also needed is better enabled ME decision-making; both with respect to supporting individual decision-making roles and with respect to realising better integrated decision-making. Industrially advanced countries have initiated research and development programs, namely, Manufacturing-2020 (UK), Next Generation Manufacturing (National Science Foundation, USA), and Intelligent Manufacturing Systems (Industry led R&D initiative from EU countries, Japan, Korea, Switzerland, and USA).


## 2. Model-Driven ME Design

In general, current approaches to ME design do not enable processes, and their under pinning resource systems and support services, to be readily implemented and transformed [10]. Therefore, achieving effective levels of agility, flexibility, postponement, systems and departmental integration, and globalisation have posed real challenges for present day MEs. Hence commonly organisations face the challenge of transforming their operations to match dynamic not static business environments [11]. Significant transformation is ongoing in environments in which modern MEs must operate competitively. Pontrandolfo and Okogbaa [12] presented a review of global manufacturing and identified two problem levels: (1) a configuration level related to strategic decision-making and (2) a coordination level related to operational issues [12]. Quick and timely responses of various production system types are vital for MEs to remain competitive [1–3]. One key common response is for MEs to have a broadened product portfolio. But to compete on such a basis they must deploy an effective and change-capable set of human and technical resource systems. Also because of falling product lifetimes and growing customisation requirements, the deployment of these resource systems will increasingly need to give rise to economies of scope and mass customisation [9]. For many companies around the world, staying in business necessitates (1) meeting specific customer requirements innovatively and effectively, (2) reducing the time-to-market of products, and (3) manufacturing quality products at competitive cost.Enterprise modelling and integration (EMI) techniques have been developed based on decomposition and configuration concepts, with modelling methods provided to analyse and engineer business processes (BPs). The application of these techniques has potential to reduce risks arising from uncertainty; thereby increasing chances of realising successful BP operation and interoperation. These innovations also have potential to enable organisations to capitalise knowledge and react to change effectively and efficiently. Systematic decomposition and analysis of complex systems is possible with the aid of supporting EMI architectures, approaches, and tools. However, realising the potential of EMI technologies gives rise to far from trivial problems. The skill with which EMI technologies are used in conjunction with other modelling technologies, such as simulation modelling (SM) and information technology (IT) systems engineering technologies, will determine the extent to which benefits of improved ME systems design and interoperation can in practice be realised. For example, the models developed using these various technologies need themselves to be reconfigurable and interoperable to synchronise their development and deployment of specific and targeted change-capable environments [13–15].There is a wide scope of adopting modelling methods to enhance reconfigurability during the design and redesign phases of manufacturing processes/systems. The models for such systems also need to be reconfigurable and interoperable in order to synchronise with the change-capable environments. There have been recent advancements to extend the coverage of public domain open systems architectures and to bridge the gap between enterprise and simulation modelling. Some important developments include a component-based approach for the design and construction of change-capable manufacturing cell control [16–18] and its applications in the automotive industry [19] and electronics SMEs [20]; a multiprocess modelling (MPM) approach [10]; the enriched MPM approach [21]; and an enhanced use of enterprise and simulation modelling techniques to support factory changeability [22]. It is noted that use of the Computer-Integrated Manufacturing Open Systems Architecture (CIMOSA) has been central to these developments. Current approaches to modelling complex MEs adopt the use of multiperspective views of present day problems. However, there is a need for integration of different manufacturing system modelling views and technologies in order to make the models and hence manufacturing systems reconfigurable and responsive to upcoming change [1–3, 15, 23–25].


## 3. Need to Improve the Design and Engineering of Future MEs

The identification of methods by which manufacturing improvements can be achieved is ongoing and has led to a range of approaches in recent years including lean, agile, changeable and reconfigurable manufacturing [2, 26–30]. Progressive improvements in information system capabilities continues to offer support for improved decision-making [31, 32]. It also follows that ME personnel must have (individual and collective) in-depth understandings about specific processes and resource systems and that these processes must be flexible enough to change whenever the need arises. The complexity of manufacturing systems is reaching that of many natural (e.g., economic and political) systems, thus ongoing redesign and reengineering of future responsive and reconfigurable MEs (RMEs) requires the use of systematic approaches, which deploy various types of system models to understand current and possible future behaviours and to inform systems engineering decision-making [25].Technological innovation has induced very significant change in industry during recent times. This has impacted significantly on the way MEs operate and compete with each other. But in general MEs are complex entities: designed, managed, and changed by people and the supporting systems that people design; to realise customer and stakeholder (people) requirements; by deploying operational (technological and people) resources in innovative, systematic, and timely ways that generate competitive behaviours. Because typically MEs have multipurposes and stakeholders, it is difficult to decide how best (and therefore near optimal) to design, select, and develop the technological systems (such as ERP and CAD/CAM systems) they deploy. Also for many reasons it is difficult to change them rapidly and in ways that enhance competitive ME behaviours. Whereas comparatively it will likely be simpler, easier, and faster to design and realise change to systems with a single well-defined purpose and small set of stakeholders. Evidently, therefore, there arises a need to seek to deploy decomposition principles aimed at breaking down complex systems into readily understood, and reusable human and technical building blocks, which can be used as interoperating “components” (or modules) of wider scope and complex MEs that can be reconfigured as requirements change [25, 33]. Globalisation is one outcome from technological innovation within MEs, but this raises further complication and a need to deploy decomposition principles. With sufficient resources, many entrepreneurs can now physically or virtually relocate themselves and their products (knowledge, experience, ideas and artefacts) to various locations around the globe. This has enabled knowledge sharing on a worldwide basis and technical systems globalisation.The combination of global competition and customer-oriented manufacture implies that modern manufacturing systems must be flexible, agile, reactive, integrated, and cost efficient [6]. It follows that designing or redesigning future RME requires the adoption of systematic approaches provided that ME must have in-depth understanding of its processes and that these processes must be reconfigurable enough to transform whenever the need arises.


## 4. Business Environment and Specific Need for a New Modelling Framework

Key research challenges identified in the literature review included the following:(1) how to cope with customer-related uncertainties and complexities in a manufacturing business; and (2) lack of structured, explicit, and quantitative modelling methods to design and develop planning and control systems that can address research challenge 1 for different types of manufacturing systems [2, 9, 10, 25, 34]. To address these research challenges, an innovative integrated modelling framework (IMF) for designing and engineering responsive and reconfigurable MEs is proposed and presented in this paper. In a typical business environment, customers request a manufacturer to produce a given quantity of a product (or products) in an agreed or required time frame. Often products requested by different customers vary from one another, and this variance forms a source of complexity with which the production system must deal, commonly where customer orders are placed. The variance can also transform over time, for example, when new or customised products come on stream. Another dimension of complexity is volume or quantity in which a product is required to be made. As the number of orders and/or numbers in each order increases it becomes more difficult for a production system to cope with the demand. Therefore, the product dynamics (PD) includes product variance (delta P), volume variance (delta V), and hence customer order (CO) variance (delta CO), which is composite of delta P and delta V. It follows that to cope with customer-related transformation in any business environment; any production planning and control (PPC) system is required to play an important role to attenuate unwanted dynamic impacts on available but limited production resources. The PPC system can be viewed as generating a work dynamic (WD), which is an attenuated form of PD and is used as input to processes (Pr) and resources (Re). The PPC system can use various control algorithms to seek to optimally deploy Pr and Re elements so that product outputs can be achieved, responsively. Figure 2 shows typical customer-related impacts in a conceptualised combined business, engineering and manufacturing environment.Figure 2
A typical business environment.The design of a production system is typically greatly influenced by the nature of the product and work dynamics as shown in Figure2. Therefore, the PPC system aims to reduce impacts on production systems of the rate of change in product design and demand. The PPC system may be seen as a place where impacts arising from the rate of change in COs, product types, and design are relatively fast (i.e., has a significant dynamic). Most likely in comparison Re goes through medium changes while the Pr goes through slow changes. Hence ideally, where possible there is a need to decouple Pr-Re couples from PPC system, so that it becomes possible to optimise workloads by flexibly distributing them. The need also arises to understand the dynamic impacts of changes in customer requirements, such as on (a) the design of production system decisions and (b) production engineering decision-making related to process plans, production schedules, and the sequencing and control of work. Ideally any future approach needs to consider such dynamics and their interrelationship. This mainly concerns understanding, representing, computer executing and virtually experimenting the relations between the WD, Pr, and Re while also considering the impacts of WD on Pr and Re [35]. The changes in WD come from the way in which the PPCS attenuates the PD. While the ability of any production system to cope with a generated WD will depend on characteristics of its Pr and Re subsystems and how these are configured and programmed into a production system.Modelling approaches have a potentially significant role to play in enabling decision-making and in supporting systems composition. This can include PPC strategy selection to facilitate responsive manufacturing. BP analysis aided by EMI can reduce risks and improve the chances of implementing successful BPs. It also enables organisations to capitalise knowledge so that they can react by changing operations in an effective, efficient, and responsive manner. Systematic decomposition and analysis of complex systems is possible with the aid of supporting architectures and by using complementary modelling techniques, which can include EM, CLM, SM, and Work Flow Modelling (WfM) [13]. The models of ME processes, resource systems, and workflows so created need themselves to be reconfigurable and interoperable in order to synchronise between virtual and real elements of processes and systems that need to interoperate within dynamic (often uncertain) environments [14]. In principle, by achieving integration of different modelling approaches, new opportunities will arise to make the models live and responsive to upcoming but “yet to be determined” rapid changes [14].


## 5. The Proposed Integrated Modelling Framework (IMF)

In this section it is explained how PPC problems arising in the context described in the foregoing section can be systematically addressed via the use of a stepwise IMF. The IMF is new process-based, modular approach, which is proposed with a view to support explicit definition or conceptual design and virtual testing of alternative ME system compositions composed of reusable systems modules. The proposal is founded on the use of ME design and change principles that include the following: (a) the modules can be flexibly (re)configured or (re)composed into higher-level systems of modules or systems; (b) the modules are themselves flexible configurations of human and technical (machine + IT) resources that possess abilities to realise assigned processing activities which lead to defined goals; (c) the modules can be (re)programmable resources, that is, possess changeability enabling them to reach various states constrained within their design envelope; (d) needed product realising processes can be explicitly decomposed into feasible roles that modules (of people and technical resources) can realise; and (e) modules can be attributed to one or many roles, therefore their actual assignments to roles need to be scheduled and controlled in order to achieve the desired types and scenarios of responsiveness.The primary modelling steps that constitute the IMF, and were defined to support integrated decision-making about various aspects of ME systems, are illustrated by Figure3.Figure 3
The IMF for RME (a simplified version).Step 1.
Use of a proven Enterprise Modelling (EM) methodology and framework to create and validate visual process maps that explicitly describe a “big picture” of the reality in the subject organisation and its operating domains.Step 2.
Use of EM concepts and tables to populate process maps with “resource” and “work” data. This data can be flexibly attributed to process elements forming the EM so current and possible future ME system configurations can be explicitly described in terms of coupled process, resource, and work types and work flow elements [34].Step 3.
Development of multilevel of abstraction “fit for purpose” Simulation Models (SMs) that are designed to model the behaviours of selected segments of ME systems. Here reuse is made of structural relationships connecting process, resource, and work flow elements of ME systems previously defined at various abstraction levels during modelling Steps1 and 2. By so doing the modeller can explicitly decompose the big picture of the ME into one or more specific segments of ME systems, which need to be recoded using an appropriate choice of simulation technology to provide “fit for purpose” support of particular needs of targeted ME decision-makers, whilst ensuring that the integrity of the structural design of the specific ME segments modelled via SMs is maintained and conforms to the wider organisational context defined by the EM of the subject ME. Any given engineering project, focussed on realising a change to an ME, will involve a distinctive set of decision-making roles, hence the steps of the IMF are geared towards explicitly understanding decision-making needs with respect to the scope and focus of ME systems of concern to each decision-maker. Consequently, appropriately configured and focussed system segments can be computer executed using proven simulation tools to help decision-makers better understand behavioural constraints placed on the responsiveness of existing ME system configurations, by replicating known behaviours of the ME and by predicting potential future behaviours arising from feasible changes made to the configuration of ME systems. Here it is important to consider that it can take long time to build and maintain simulation models, and reduced lead-time is critical in decision-making. Simulation modelling can also prove costly in terms of time and money.Step 4.
Use of the coherent set of “fit for purpose” SMs to predict potential future behaviours arising from decision-making.The proposed elements and elemental relationships of the IMF for designing future RME are explicitly documented in this section by using modelling notations of the well-established Integration Definition for Function Modelling (IDEF0) standard [36]. The IDEF0 method is adopted here because (1) it can usefully model the design steps involved in the IMF for future RME and (2) it is a well-established function modelling standard issued by National Institute of Standards and Technology (NIST), USA. In this standard method, a square box is used to denote manufacturing functions along with arrows to show inputs (arrows from left), controls (arrows from top), and mechanisms (arrows from bottom) and outputs (arrows stemming outwards right). An overview of the IDEF0 method is shown in Figure 4.Figure 4
The IDEF0 Method.Changes in customer orders, products, and work-related dynamics impact upon the need to redesign a responsive manufacturing system. The proposed purpose for the IMF for future RME is to systemise and facilitate the (re)design process by making use of the modelling concepts and to integrate explicit descriptions of Pr-Re (Process-Resource) couples at needed levels of abstraction and thereby to visualise and document the way work types and flows related to these Pr-Re couples, which can be viewed as being modular building blocks of models of ME systems at a higher level of abstraction. This is intended to result in identified systematic ways of improving the responsiveness of a subject ME and its constituent business, engineering, and manufacturing systems. Figure 5 shows the main IDEF0 diagram for the proposed IMF.Figure 5
The IMF for RME: (Re)Design of a responsive manufacturing enterprise (Main).The following design steps are proposed to conform to the IMF: (a) create enterprise models and (b) create simulation models. While creating enterprise and simulation models, a specific modelling formalism is followed, keeping in mind overall objectives of any given ME engineering project. Different modelling blocks and identifiers are used to uniquely represent models in terms of CIMOSA (and non-CIMOSA) domains, activities, events, information, physical and human resources, flow of processes, resources or materials, alternative flows, and finances. Key Performance Indicators (KPIs) are used to benchmark designed manufacturing performance with reference to overall objectives. Figure6 shows the design steps undertaken for the IMF.Figure 6
Design steps for the IMF (A0).


### 5.1. Design Steps for Creating Enterprise Models (A1)

The following steps are undertaken while creating enterprise models:(1) create context diagram(s); (2) create structure diagram(s); (3) create interaction diagram(s); and (4) create activity diagram(s). While creating enterprise models, related EM formalisms are followed while keeping in mind overall objectives of the exercise and CIMOSA and non-CIMOSA domains. Different modelling blocks and identifiers are used to uniquely document enterprise models. Figure 7 shows the modelling sequence followed while creating enterprise models.Figure 7
Design steps for creating enterprise models (A1).


#### 5.1.1. Design Steps for Creating Context Diagram (A11)

The overall objective of creating a context diagram is to determine the scope of involvement from a process-oriented point of view. It is written in the manner “verb + noun,” meaning like “something is being done, or going to be done.” It represents a process as a central concern not a function. Things involved in realising this objective are domains associated with that objective. CIMOSA domains are represented using oval-shaped modelling blocks, and non-CIMOSA domains with crossed-out oval shaped modelling blocks. Domains are named as “nouns.” Identifiers are assigned to domains as (DM + unique number). Figure8 shows the steps undertaken for creating context diagram(s) as follows: (1) identify and document related CIMOSA DP(s); (2) identify and document non-CIMOSA DP(s); and (3) identify and assign identifiers to DP(s).Figure 8
Design steps for creating context diagram(s) (A11).


#### 5.1.2. Design Steps for Creating Structure Diagrams (A12)

Generally, one top level structure diagram may be developed for each domain under consideration. The DP is represented in the centre of the diagram while developing the structure diagram. The BPs involved in a DP are identified and associated with the DP. Identifiers are given to BPs as (BP + domain identifier + unique BP number). Sub-BPs and EAs are identified for each BP. The EAs are represented under each BP. Identifiers are given to sub-BP as (BP + BP number + “-” + sub-BP number). Identifiers are given to EAs as (EA + BP or sub-BP or DP number + unique EA number). Figure9 shows the steps normally undertaken for creating structure diagram(s) as follows: (1) specify and document structure diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-BP(s); and (4) identify and assign identifiers to EAs.Figure 9
Procedural steps for creating structure diagram(s) (A12).


#### 5.1.3. Design Steps for Creating Interaction Diagrams (A13)

One top level interaction diagram can be created for each objective under consideration. The top level interaction diagram is created by considering interactions between domains involved in the context diagram(s). Those interactions are considered to occur between DP(s) owned by the interacting domains. Identifiers are assigned to DP(s) as (DP + domain number). Between any two DPs, only information, human resource(s), physical resource(s), event(s), and finance are represented in interaction diagram(s). One interaction diagram is created for each domain under study. In subsequent interaction diagrams, DPs are decomposed and represented as sub-DPs or BPs. A DP not under consideration is represented as an external link. While creating subinteraction diagrams, domains under consideration are represented in terms of either their sub-DPs or BPs. Decisions are taken on the basis of ease in the modelling effort, understanding to be developed and subsequent need for development of structure diagrams. Identifiers are assigned to sub-DPs as (DP + parent DP number + unique number of this sub-DP), and to BPs as (BP + parent DP number + unique number of this BP). Figure10 shows steps undertaken for creating interaction diagram(s) as follows: (1) specify and document interaction diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-DP(s); and (4) identify and assign identifiers to BP(s).Figure 10
Design steps for creating interaction diagram(s) (A13).


#### 5.1.4. Design Steps for Creating Activity Diagrams (A14)

The activity diagrams are normally developed from structure diagrams, so that their development remains positioned in the context of their parent enterprise. The EAs, BPs, and sub-BPs, as identified in structure diagram, are sequenced together using the notations developed for activity diagrams. A complete end-to-end process is represented using activity diagram formalisms with dependencies among EAs/BPs. The flow of process, control, and resources is represented in activity diagrams. If an end-to-end process cannot be accommodated using one template, then further templates may be added with dependencies shown between any two templates. It is important to place EAs/BPs on activity diagrams with respect to a time line at the bottom of the activity diagram. Figure11 shows steps undertaken for creating activity diagram(s) as follows: (1) specify and document activity diagram(s); (2) represent complete end-to-end process with dependencies among EAs/BPs; (3) represent the flow of process, control and resources; and (4) carefully check that the EAs/BPs are appropriately placed with respect to the time line.Figure 11
Design steps for creating activity diagram(s) (A14).


#### 5.1.5. Analysis of EM Tool Set

The EM templates facilitate the process of IMF application in an enterprise. These EM templates basically provide a base for EM, following which fit for purpose SMs can be conceptually designed and implemented and simulation experiments can be conducted based upon the reuse of knowledge and data previously coded using enterprise models. The EM templates make use of the following formalisms:(i)
general blocks—which includes CIMOSA domain & non-CIMOSA domain activity, external link, and event modelling constructs;(ii)
resources—which include information (resource), HR (human resources), physical (resources), and finance (related resources);(iii)
flow control logic—which includes conditional (logic), OR (logic), AND (logic), sub-process, chained process, and delay;(iv)
flow types—which includes flow of resource, flow of process, and alternative flow;(v)
operation types—which includes direct generation, direct supportive, and indirect supportive (operation types).Figures12, 13, 14, and 15 show example use of context diagrams, interaction diagrams, structure diagrams, and activity diagrams, respectively.Figure 12
Example use of EM template for “context diagram.”Figure 13
Example use of EM template for “interaction diagram.”Figure 14
Example use of EM template for “structure diagram.”Figure 15
Example use of EM template for “activity diagram.”


### 5.2. Design Steps for Creating Simulation Models (A2-1 and A2-2)

The design steps for creating simulation models are listed in the following:(1) gather simulation requirements; (2) select SM tool; (3) create AS-IS simulation model(s); (4) verify and validate the AS-IS simulation model; (5) create TO-BE simulation models; (6) verify and validate the TO-BE simulation models; (7) analyse results; and (8) implement TO-BE simulation models (where applicable). Figures 16 and 17 show steps undertaken for creating simulation models (A2-1 and A2-2).Figure 16
Design steps for creating simulation models (A2-1).Figure 17
Design steps for creating simulation models—continued (A2-2).


### 5.3. Analysis and Selection of SM Tool Set

It is assumed that a set of computer and manual technologies and systems will be used to understand the problem scenarios, execute the IMF, and provide suitable interfaces to users and modellers for decision-making. During this research, MS Visio was used to create static enterprise and causal loop models. Proprietary software packages were used to create simulation models, namely, Simul8, Plant Simulation, Arena, and iThink. The selection of these specific software tool set was based upon(1) model requirements; (2) model KPIs; (3) modeller’s capability to successfully model the required configurations; (4) acceptance of results by the peers; and (5) availability. Table 1 shows authors’ capability set for the selected simulation tools. Furthermore, other modelling methods and case studies by the authors and their research colleagues have successfully utilised these software tool sets. Such interfaces enabled the authors to (1) capture requirements data; (2) input data into models; (3) reconfigure a simulation model to meet various specified needs; (4) conduct various experiments based upon different configurations; (5) collect results; and (6) conduct analysis of results.Table 1
Authors’ capability set for selected simulation software tools.
Simulation software tool set
iThink
Simul8
Plant simulation
Arena
Matlab/simulink
Petrinets
Selection parameters
(1) Model requirements
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
(2) Model KPIs
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
(3) Modeller's capability
Good
Good
Good
Good
Good
Good
(4) Peer acceptance
Good
Good
Good
Good
Average
Good
(5) Availability
Good
Good
Good
Good
Good
GoodThere has been a weak impact of enterprise architecture research in industry and insufficient maturity of standards on enterprise architectures including CIMOSA and GERAM in the past two decades [37]. Hence it is important to know how to apply the IMF in general. Even though significant work has been done on enterprise application integration during past two decades, there are still several issues that have not been addressed and they need to be studied further. Predicting the evolution of a particular piece of modelling software is one of such issues [38]. This issue is crucial to achieving a near optimal trade-off for a particular enterprise between short-term gain and long-term suitability. A company could invest in an enterprise application software system today in order to obtain better support to its existing business functions, but that software may become obsolete in say 2-3 years. Any new software choice may bring some constraints on introducing other new software systems due to their inability to communicate with previously existing software. This issue could also be viewed in another way, namely, how could one make decisions under uncertain situations (including uncertainty in the evolution of any selected software tool)? The proposed IMF intends to be generic in a sense that it could (re)use existing organisational resource systems (hardware, software, human) and organisational structure in order to achieve the benefits of “openness,” “standardised view,” “low-cost of change,” and “easier adaptation by the organisation and its stake holders,” to name a few.


### 5.4. Discussion

The proposed IMF for future RME is illustrated and documented through IDEF0 diagrams in this paper and is composed of an integrated use of EM and SM, which is described in this paper in detail. The development of the IMF also led onto the development of a Manufacturing system integration UNified Environment (MUNE). In a number of industry-based case studies (e.g., in automotive, bearing manufacturing, furniture manufacturing), such an environment has since played a pivotal role that enables responsiveness and reconfigurability in future RME [34, 39–41]. The MUNE proposed in this study has three primary dimensions along which complex system decompositions can be instrumented via suitable software system choice(s). These dimensions correspond to (1) modelling levels, (2) modelling views, and (3) production management levels. The modelling views consist of the following: (a) product dynamics (PD), (b) customer order decoupling point (CODP), (c) work dynamics (WD), (d) performance metrics (PM), (e) EM, and (f) SM. The modelling views include generic, partial, and particular views that are similar to previously proposed CIMOSA modelling views. The MUNE is presented conceptually in Figure 18.Figure 18
MSI UNified Environment (MUNE).In theory, the IMF offers the following solutions to ME engineering research challenges (as identified in Section4).(1)
It provides a decomposition of the complexity typical within MEs: in terms of delta orders, delta volume required, delta product variance, and so forth. Hence it promises to provide a way to cope with customer-related uncertainties and complexities and to match ME system configurations and their behaviours to long- and short-term responsiveness needs.(2)
It provides a structured modelling framework and as shown in the research thesis of the first author [34], it provides a structured, explicit, and quantitative modelling approach that has been used to facilitate the design and development of production planning and control systems.Table2 shows weaknesses of formal methods found in specific literature review and how these are addressed in the IMF.Table 2
Weaknesses of formal methods in the literature and how these are addressed in IMF.
Weaknesses of formal methods in the literature
How weaknesses are addressed in IMF
Lack of structured ways of explicitly defining the relatively enduring structures of business, engineering, and production systems used by a given specific manufacturing enterprise.
EM:(i) This stage provides a structured base to understand the business in context by usefully modelling the enterprise. (ii) It provides a way of systematic reuse of enterprise model fragments in the form of modelling diagram templates. (iii) The context, structure, interaction, and activity diagrams help in producing and reconfiguring enterprise models in a rapid and effective way.
Lack of structured ways of creating “fit for purpose” simulation models that can support decision making about ME systems and how changes in the ME system design can result in needed reachable enterprise behaviours.
SM:(i) This stage provides benefits in terms of a structured dynamic analysis tool for decision making in terms of achieving reconfigurability and responsiveness. (ii) It provides a basis for a structured decision making for TO-BE models by creating reconfigured simulation models and making comparisons with As-Is or other TO-BE models. (iii) It provides a way to analyse and predict about alternative TO-BE options available to the ME.


## 5.1. Design Steps for Creating Enterprise Models (A1)

The following steps are undertaken while creating enterprise models:(1) create context diagram(s); (2) create structure diagram(s); (3) create interaction diagram(s); and (4) create activity diagram(s). While creating enterprise models, related EM formalisms are followed while keeping in mind overall objectives of the exercise and CIMOSA and non-CIMOSA domains. Different modelling blocks and identifiers are used to uniquely document enterprise models. Figure 7 shows the modelling sequence followed while creating enterprise models.Figure 7
Design steps for creating enterprise models (A1).


### 5.1.1. Design Steps for Creating Context Diagram (A11)

The overall objective of creating a context diagram is to determine the scope of involvement from a process-oriented point of view. It is written in the manner “verb + noun,” meaning like “something is being done, or going to be done.” It represents a process as a central concern not a function. Things involved in realising this objective are domains associated with that objective. CIMOSA domains are represented using oval-shaped modelling blocks, and non-CIMOSA domains with crossed-out oval shaped modelling blocks. Domains are named as “nouns.” Identifiers are assigned to domains as (DM + unique number). Figure8 shows the steps undertaken for creating context diagram(s) as follows: (1) identify and document related CIMOSA DP(s); (2) identify and document non-CIMOSA DP(s); and (3) identify and assign identifiers to DP(s).Figure 8
Design steps for creating context diagram(s) (A11).


### 5.1.2. Design Steps for Creating Structure Diagrams (A12)

Generally, one top level structure diagram may be developed for each domain under consideration. The DP is represented in the centre of the diagram while developing the structure diagram. The BPs involved in a DP are identified and associated with the DP. Identifiers are given to BPs as (BP + domain identifier + unique BP number). Sub-BPs and EAs are identified for each BP. The EAs are represented under each BP. Identifiers are given to sub-BP as (BP + BP number + “-” + sub-BP number). Identifiers are given to EAs as (EA + BP or sub-BP or DP number + unique EA number). Figure9 shows the steps normally undertaken for creating structure diagram(s) as follows: (1) specify and document structure diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-BP(s); and (4) identify and assign identifiers to EAs.Figure 9
Procedural steps for creating structure diagram(s) (A12).


### 5.1.3. Design Steps for Creating Interaction Diagrams (A13)

One top level interaction diagram can be created for each objective under consideration. The top level interaction diagram is created by considering interactions between domains involved in the context diagram(s). Those interactions are considered to occur between DP(s) owned by the interacting domains. Identifiers are assigned to DP(s) as (DP + domain number). Between any two DPs, only information, human resource(s), physical resource(s), event(s), and finance are represented in interaction diagram(s). One interaction diagram is created for each domain under study. In subsequent interaction diagrams, DPs are decomposed and represented as sub-DPs or BPs. A DP not under consideration is represented as an external link. While creating subinteraction diagrams, domains under consideration are represented in terms of either their sub-DPs or BPs. Decisions are taken on the basis of ease in the modelling effort, understanding to be developed and subsequent need for development of structure diagrams. Identifiers are assigned to sub-DPs as (DP + parent DP number + unique number of this sub-DP), and to BPs as (BP + parent DP number + unique number of this BP). Figure10 shows steps undertaken for creating interaction diagram(s) as follows: (1) specify and document interaction diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-DP(s); and (4) identify and assign identifiers to BP(s).Figure 10
Design steps for creating interaction diagram(s) (A13).


### 5.1.4. Design Steps for Creating Activity Diagrams (A14)

The activity diagrams are normally developed from structure diagrams, so that their development remains positioned in the context of their parent enterprise. The EAs, BPs, and sub-BPs, as identified in structure diagram, are sequenced together using the notations developed for activity diagrams. A complete end-to-end process is represented using activity diagram formalisms with dependencies among EAs/BPs. The flow of process, control, and resources is represented in activity diagrams. If an end-to-end process cannot be accommodated using one template, then further templates may be added with dependencies shown between any two templates. It is important to place EAs/BPs on activity diagrams with respect to a time line at the bottom of the activity diagram. Figure11 shows steps undertaken for creating activity diagram(s) as follows: (1) specify and document activity diagram(s); (2) represent complete end-to-end process with dependencies among EAs/BPs; (3) represent the flow of process, control and resources; and (4) carefully check that the EAs/BPs are appropriately placed with respect to the time line.Figure 11
Design steps for creating activity diagram(s) (A14).


### 5.1.5. Analysis of EM Tool Set

The EM templates facilitate the process of IMF application in an enterprise. These EM templates basically provide a base for EM, following which fit for purpose SMs can be conceptually designed and implemented and simulation experiments can be conducted based upon the reuse of knowledge and data previously coded using enterprise models. The EM templates make use of the following formalisms:(i)
general blocks—which includes CIMOSA domain & non-CIMOSA domain activity, external link, and event modelling constructs;(ii)
resources—which include information (resource), HR (human resources), physical (resources), and finance (related resources);(iii)
flow control logic—which includes conditional (logic), OR (logic), AND (logic), sub-process, chained process, and delay;(iv)
flow types—which includes flow of resource, flow of process, and alternative flow;(v)
operation types—which includes direct generation, direct supportive, and indirect supportive (operation types).Figures12, 13, 14, and 15 show example use of context diagrams, interaction diagrams, structure diagrams, and activity diagrams, respectively.Figure 12
Example use of EM template for “context diagram.”Figure 13
Example use of EM template for “interaction diagram.”Figure 14
Example use of EM template for “structure diagram.”Figure 15
Example use of EM template for “activity diagram.”


## 5.1.1. Design Steps for Creating Context Diagram (A11)

The overall objective of creating a context diagram is to determine the scope of involvement from a process-oriented point of view. It is written in the manner “verb + noun,” meaning like “something is being done, or going to be done.” It represents a process as a central concern not a function. Things involved in realising this objective are domains associated with that objective. CIMOSA domains are represented using oval-shaped modelling blocks, and non-CIMOSA domains with crossed-out oval shaped modelling blocks. Domains are named as “nouns.” Identifiers are assigned to domains as (DM + unique number). Figure8 shows the steps undertaken for creating context diagram(s) as follows: (1) identify and document related CIMOSA DP(s); (2) identify and document non-CIMOSA DP(s); and (3) identify and assign identifiers to DP(s).Figure 8
Design steps for creating context diagram(s) (A11).


## 5.1.2. Design Steps for Creating Structure Diagrams (A12)

Generally, one top level structure diagram may be developed for each domain under consideration. The DP is represented in the centre of the diagram while developing the structure diagram. The BPs involved in a DP are identified and associated with the DP. Identifiers are given to BPs as (BP + domain identifier + unique BP number). Sub-BPs and EAs are identified for each BP. The EAs are represented under each BP. Identifiers are given to sub-BP as (BP + BP number + “-” + sub-BP number). Identifiers are given to EAs as (EA + BP or sub-BP or DP number + unique EA number). Figure9 shows the steps normally undertaken for creating structure diagram(s) as follows: (1) specify and document structure diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-BP(s); and (4) identify and assign identifiers to EAs.Figure 9
Procedural steps for creating structure diagram(s) (A12).


## 5.1.3. Design Steps for Creating Interaction Diagrams (A13)

One top level interaction diagram can be created for each objective under consideration. The top level interaction diagram is created by considering interactions between domains involved in the context diagram(s). Those interactions are considered to occur between DP(s) owned by the interacting domains. Identifiers are assigned to DP(s) as (DP + domain number). Between any two DPs, only information, human resource(s), physical resource(s), event(s), and finance are represented in interaction diagram(s). One interaction diagram is created for each domain under study. In subsequent interaction diagrams, DPs are decomposed and represented as sub-DPs or BPs. A DP not under consideration is represented as an external link. While creating subinteraction diagrams, domains under consideration are represented in terms of either their sub-DPs or BPs. Decisions are taken on the basis of ease in the modelling effort, understanding to be developed and subsequent need for development of structure diagrams. Identifiers are assigned to sub-DPs as (DP + parent DP number + unique number of this sub-DP), and to BPs as (BP + parent DP number + unique number of this BP). Figure10 shows steps undertaken for creating interaction diagram(s) as follows: (1) specify and document interaction diagram(s); (2) identify BP(s) involved in this DP and assign identifiers; (3) identify and assign identifiers to sub-DP(s); and (4) identify and assign identifiers to BP(s).Figure 10
Design steps for creating interaction diagram(s) (A13).


## 5.1.4. Design Steps for Creating Activity Diagrams (A14)

The activity diagrams are normally developed from structure diagrams, so that their development remains positioned in the context of their parent enterprise. The EAs, BPs, and sub-BPs, as identified in structure diagram, are sequenced together using the notations developed for activity diagrams. A complete end-to-end process is represented using activity diagram formalisms with dependencies among EAs/BPs. The flow of process, control, and resources is represented in activity diagrams. If an end-to-end process cannot be accommodated using one template, then further templates may be added with dependencies shown between any two templates. It is important to place EAs/BPs on activity diagrams with respect to a time line at the bottom of the activity diagram. Figure11 shows steps undertaken for creating activity diagram(s) as follows: (1) specify and document activity diagram(s); (2) represent complete end-to-end process with dependencies among EAs/BPs; (3) represent the flow of process, control and resources; and (4) carefully check that the EAs/BPs are appropriately placed with respect to the time line.Figure 11
Design steps for creating activity diagram(s) (A14).


## 5.1.5. Analysis of EM Tool Set

The EM templates facilitate the process of IMF application in an enterprise. These EM templates basically provide a base for EM, following which fit for purpose SMs can be conceptually designed and implemented and simulation experiments can be conducted based upon the reuse of knowledge and data previously coded using enterprise models. The EM templates make use of the following formalisms:(i)
general blocks—which includes CIMOSA domain & non-CIMOSA domain activity, external link, and event modelling constructs;(ii)
resources—which include information (resource), HR (human resources), physical (resources), and finance (related resources);(iii)
flow control logic—which includes conditional (logic), OR (logic), AND (logic), sub-process, chained process, and delay;(iv)
flow types—which includes flow of resource, flow of process, and alternative flow;(v)
operation types—which includes direct generation, direct supportive, and indirect supportive (operation types).Figures12, 13, 14, and 15 show example use of context diagrams, interaction diagrams, structure diagrams, and activity diagrams, respectively.Figure 12
Example use of EM template for “context diagram.”Figure 13
Example use of EM template for “interaction diagram.”Figure 14
Example use of EM template for “structure diagram.”Figure 15
Example use of EM template for “activity diagram.”


## 5.2. Design Steps for Creating Simulation Models (A2-1 and A2-2)

The design steps for creating simulation models are listed in the following:(1) gather simulation requirements; (2) select SM tool; (3) create AS-IS simulation model(s); (4) verify and validate the AS-IS simulation model; (5) create TO-BE simulation models; (6) verify and validate the TO-BE simulation models; (7) analyse results; and (8) implement TO-BE simulation models (where applicable). Figures 16 and 17 show steps undertaken for creating simulation models (A2-1 and A2-2).Figure 16
Design steps for creating simulation models (A2-1).Figure 17
Design steps for creating simulation models—continued (A2-2).


## 5.3. Analysis and Selection of SM Tool Set

It is assumed that a set of computer and manual technologies and systems will be used to understand the problem scenarios, execute the IMF, and provide suitable interfaces to users and modellers for decision-making. During this research, MS Visio was used to create static enterprise and causal loop models. Proprietary software packages were used to create simulation models, namely, Simul8, Plant Simulation, Arena, and iThink. The selection of these specific software tool set was based upon(1) model requirements; (2) model KPIs; (3) modeller’s capability to successfully model the required configurations; (4) acceptance of results by the peers; and (5) availability. Table 1 shows authors’ capability set for the selected simulation tools. Furthermore, other modelling methods and case studies by the authors and their research colleagues have successfully utilised these software tool sets. Such interfaces enabled the authors to (1) capture requirements data; (2) input data into models; (3) reconfigure a simulation model to meet various specified needs; (4) conduct various experiments based upon different configurations; (5) collect results; and (6) conduct analysis of results.Table 1
Authors’ capability set for selected simulation software tools.
Simulation software tool set
iThink
Simul8
Plant simulation
Arena
Matlab/simulink
Petrinets
Selection parameters
(1) Model requirements
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
(2) Model KPIs
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
Context dependant
(3) Modeller's capability
Good
Good
Good
Good
Good
Good
(4) Peer acceptance
Good
Good
Good
Good
Average
Good
(5) Availability
Good
Good
Good
Good
Good
GoodThere has been a weak impact of enterprise architecture research in industry and insufficient maturity of standards on enterprise architectures including CIMOSA and GERAM in the past two decades [37]. Hence it is important to know how to apply the IMF in general. Even though significant work has been done on enterprise application integration during past two decades, there are still several issues that have not been addressed and they need to be studied further. Predicting the evolution of a particular piece of modelling software is one of such issues [38]. This issue is crucial to achieving a near optimal trade-off for a particular enterprise between short-term gain and long-term suitability. A company could invest in an enterprise application software system today in order to obtain better support to its existing business functions, but that software may become obsolete in say 2-3 years. Any new software choice may bring some constraints on introducing other new software systems due to their inability to communicate with previously existing software. This issue could also be viewed in another way, namely, how could one make decisions under uncertain situations (including uncertainty in the evolution of any selected software tool)? The proposed IMF intends to be generic in a sense that it could (re)use existing organisational resource systems (hardware, software, human) and organisational structure in order to achieve the benefits of “openness,” “standardised view,” “low-cost of change,” and “easier adaptation by the organisation and its stake holders,” to name a few.


## 5.4. Discussion

The proposed IMF for future RME is illustrated and documented through IDEF0 diagrams in this paper and is composed of an integrated use of EM and SM, which is described in this paper in detail. The development of the IMF also led onto the development of a Manufacturing system integration UNified Environment (MUNE). In a number of industry-based case studies (e.g., in automotive, bearing manufacturing, furniture manufacturing), such an environment has since played a pivotal role that enables responsiveness and reconfigurability in future RME [34, 39–41]. The MUNE proposed in this study has three primary dimensions along which complex system decompositions can be instrumented via suitable software system choice(s). These dimensions correspond to (1) modelling levels, (2) modelling views, and (3) production management levels. The modelling views consist of the following: (a) product dynamics (PD), (b) customer order decoupling point (CODP), (c) work dynamics (WD), (d) performance metrics (PM), (e) EM, and (f) SM. The modelling views include generic, partial, and particular views that are similar to previously proposed CIMOSA modelling views. The MUNE is presented conceptually in Figure 18.Figure 18
MSI UNified Environment (MUNE).In theory, the IMF offers the following solutions to ME engineering research challenges (as identified in Section4).(1)
It provides a decomposition of the complexity typical within MEs: in terms of delta orders, delta volume required, delta product variance, and so forth. Hence it promises to provide a way to cope with customer-related uncertainties and complexities and to match ME system configurations and their behaviours to long- and short-term responsiveness needs.(2)
It provides a structured modelling framework and as shown in the research thesis of the first author [34], it provides a structured, explicit, and quantitative modelling approach that has been used to facilitate the design and development of production planning and control systems.Table2 shows weaknesses of formal methods found in specific literature review and how these are addressed in the IMF.Table 2
Weaknesses of formal methods in the literature and how these are addressed in IMF.
Weaknesses of formal methods in the literature
How weaknesses are addressed in IMF
Lack of structured ways of explicitly defining the relatively enduring structures of business, engineering, and production systems used by a given specific manufacturing enterprise.
EM:(i) This stage provides a structured base to understand the business in context by usefully modelling the enterprise. (ii) It provides a way of systematic reuse of enterprise model fragments in the form of modelling diagram templates. (iii) The context, structure, interaction, and activity diagrams help in producing and reconfiguring enterprise models in a rapid and effective way.
Lack of structured ways of creating “fit for purpose” simulation models that can support decision making about ME systems and how changes in the ME system design can result in needed reachable enterprise behaviours.
SM:(i) This stage provides benefits in terms of a structured dynamic analysis tool for decision making in terms of achieving reconfigurability and responsiveness. (ii) It provides a basis for a structured decision making for TO-BE models by creating reconfigured simulation models and making comparisons with As-Is or other TO-BE models. (iii) It provides a way to analyse and predict about alternative TO-BE options available to the ME.


## 6. Effectiveness of Applying the IMF in an Automotive Industry Case

The IMF was applied in an automotive industrial case study (where the ME concerned will be referred to as FPD in the following). Reduction in lead time, cost, and work load on a preproduction management team were key issues for the management of the FPD. While applying the IMF in this case study, comparisons of AS-IS and future (TO-BE) situations of pre-production control were presented. Based upon observations made during this case study, the IMF proved to be useful but some limitations were also identified [34]. Such limitations demanded for an enhancement of the IMF. The original IMF was based upon previously discussed general literature review, detailed literature review, and early exploratory modelling and results. Lack of adequate structured data capturing methods and gaps in information and data when transforming between EMs and SMs were among some limitations of the IMF. Hence a need was raised to enhance the IMF in order to improve its application and achieve better results. This paper will present an enhanced integrated modelling framework (EIMF) after taking into consideration lessons learnt during the FPD case study.During the FPD case the authors made the following observations. CIMOSA provides a coherent set of modelling constructs to explicitly represent processes, resource systems, information flows, and organisational structures of MEs. Along the “derivation” dimension, it provides multiperspective modelling constructs that enable decomposition of the enterprise so as to handle high levels of complexity such that understandings gained about process segments can be understood in detail within the organisational context specified by the parent enterprise model. In this way understandings about relatively enduring structural aspects of processes can be gained at various levels of abstraction. Thereby both “big picture understandings” can be developed that cross organisational boundaries and in depth process analysis can be enabled by “drilling into” the model at needed levels of modelling abstraction. The “generation” dimension is concerned with the life cycle of the ME and its processes, resources, information flows, and its organisational structures. Here definitive separation is made between “models of requirements” (generally expressed as process models that can be treated as a backbone model and attributed with other modelled entities) and “models of conceptual solutions,” “detailed models of specific solutions,” and “implementation descriptions” used to document implemented systems capable of meeting defined requirements. In general such solutions will be configurations of active resource components (including people, automated machines, and IT systems). The third CIMOSA cube dimension “instantiation” is concerned with the extent to which “models” and “implemented solutions” are general or specific and is of prime concern later in this research. The basic idea is that enterprise models may describe MEs or parts of them from a structural point of view, equally they may describe some industry sector or common structural aspects of many MEs, or may simply describe one particular ME, or even just one particular part of one particular ME. Here in principle enterprise modellers and other enterprise engineers and decision-makers can particularise a generic model through a partially generic modelling stage to an ME specific one. Alternatively generalisation of specific or semigeneric models can lead to models and solutions that can be generally applied. In this scheme of things therefore an ERP package is a semigeneric solution technology, which can be made specific by inputting specific product, and so forth, data related to a specific ME.However, in general enterprise modelling (including CIMOSA) is designed to represent and communicate primarily structural (i.e., relatively enduring) aspects of any ME. CIMOSA modelling constructs are not designed to be computer executed to simulate ME state change; if they were then EMs used to model a complex ME, they would themselves become too complex to deploy for all possible enterprise engineering decision-making purposes. Hence where simulation experiments are needed to predict future behaviours of ME processes configured in different ways, and when using alternative resource systems, it is necessary to complement the use of EM with SM technologies; as SM technologies are designed to model and predict changes in system behaviours. This section reviews the basis of the IMF’s systematic approach to creating coherent sets of integrated (EM and SM) models that can interoperate to replicate and predict changing organisational behaviours and to place the generated behaviours within the specific case organisational context of a parent ME as modelled by a parent EM.As described earlier at a generic level, the IMF provides a framework that encompasses the following main modelling stages.Stage 1.
Development of enterprise models, to represent the organising structure of a specific ME and its product realising processes.Stage 2.
Development of multiple simulation models of relevant process segments where, with reference to needs of particular enterprise engineering decision-makers, it is necessary to consider and encode: (a) the nature of the work that flows through production systems, where these systems comprise both “process elements” and “resource system elements” and (b) best ways of configuring the production system elements, such that required “values” can be added to those work flows. Simulation models are run using alternative responsiveness strategies by inputting data into AS-IS and possible TO-BE configurations of production systems (for various organisational departments). Before (or during) running the simulations, certain KPIs are chosen to enable comparison and choice to be made between different combinations of responsiveness strategy and production systems configuration (composition). As soon as a near optimal solution (and therefore a suitable configuration of ME systems) is defined, the modelling and decision-making process is stopped; otherwise it is carried on to find additional combinations of future responsiveness strategies and production system configurations (compositions). The KPIs used for this specific case study included lead time, cost, and resource load. Table3 shows results of AS-IS and selected TO-BE model configurations considered during experimentation. It shows a significant reduction in lead time of TO-BE model configuration of FPD, that is, from 66 days to 56 days.Table 3
AS-IS and TO-BE model configurations.
Model configurations
Strategy
Time(days)
Resource load(engineers)
Cost of engineers($)
AS-IS
Random assignment of work with dedicated resource groups
66
16.75(Total: 33.04)
58960(Total: 118094)
TO-BE
First come first serve with introduction of three flexible resource sets
56
13.30(Total: 27.61)
53201(Total: 111781)
Difference
10
3.45 (Total: 5.43)
5759 (Total: 6313)
Percent improvement (%)
15.15%
20.60%
9.77% (Total: 5.35%)While reviewing the IMF with respect to its use in the FPD case certain limitations were identified, as presented in the following section.


### 6.1. Limitations of the IMF and Need for Enhancement

The application of the IMF in the FPD case proved useful in visualising alternative pre-production control management methods. But during the application process, limitations of the IMF were also identified, namely,(i)
lack of adequate structured data collection for enterprise models,(ii)
lack of linking EMs with SMs effectively,(iii)
lack of verification, validations, and accreditation of developed models,(iv)
lack of structured output of the modelling exercises.The authors, therefore, found that it was necessary:(1) to define and deploy structured data collection methods during EM stages; (2) to deploy “systems thinking” (via causal loop modelling) to help better understand impacts of parameter change and causality amongst parameters in complex manufacturing systems and thereby to design better SMs and SM experiments; (3) to exercise verification, validation, and accreditation of enterprise and simulation models after all modelling stages; and (4) to tailor the generic IMF towards PPC policy selection. It is important to explore how to address key aspects of these identified IMF limitations. The following section will discuss the way in which the authors adopted systems thinking as an integral part of an enhanced form of the IMF.


### 6.2. Systems Thinking via Causal Loop Modelling

Causal loop models can visually represent causal effects between activities [43, 44]. This type of modelling helps identify aspects of complex system dynamics. When used as a standalone technique, however, Causal Loop Modelling (CLM) is limited in support of complex manufacturing systems design [45]. When applied on its own, CLM may prove useful for strategic decision-making but generally it does not adequately encode complex systems except at a high level of abstraction. However, when combined with suitable process modelling technique(s) focussed on structural design, it may prove useful for complex systems design, due to its ability to capture the causality of dynamics and provide a basis for qualitative analysis of businesses. Causal loop models by themselves cannot readily be quantitively modelled but they can be transformed into equivalent iThink models for simulation purposes. Previous to work of the authors and their colleagues, the literature had not shown that causal loop models being used in support of CIM implementation [45]. Masood [34, 46], Rashid et al. [47] and Agyapong-Kodua et al. [45] have further detailed and applied CLMs. The following will discuss model verification, validation, and accreditation.


### 6.3. Verification, Validation, and Accreditation of Models

Verification, validation, and accreditation (VVA) of models is very important in establishing confidence and trust in a model and its results. VVA terms are defined as follows. Verification is the process of determining that a model implementation accurately represents the developer’s conceptual description and specifications that the model was designed for [42]. Validation is the process of determining the manner and degree to which a model is an accurate representation of the real world from the perspective of the intended uses of the model and of establishing the level of confidence that should be placed on this assessment [42]. Validation is the process of establishing confidence in the usefulness of a model [48]. Being “valid” means “well suited to a purpose and soundly constructed” but does not imply that a model somehow becomes absolutely correct and true [49]. It is important to validate the static models up to an acceptable level of accuracy. The performance of the model needs to be compared with the operation of the real system to build confidence in the results. It is important to note that the model may only be “valid for the purpose.” In reality, however, it may not be possible to validate fully a model of a real system [20, 50–52]. Accreditation is the formal certification that a model or simulation is acceptable for use for a specific purpose. The validation method adopted here generally follows the method suggested by Robinson [50] (i.e., validation of static model, data, codes, and black box approaches). Accreditation is conferred by the ME best positioned to make the judgement that the model or simulation in question is acceptable [42]. In MEs there may be many types of potential operational user, programme manager users, and contractor users, depending upon the purposes intended. Figure 19 illustrates the basic differences between the VVA terms. Having explored the systems thinking and model verification, validation, and accreditation, the next section will propose the EIMF.Figure 19
Verification, validation, and accreditation [42].


## 6.1. Limitations of the IMF and Need for Enhancement

The application of the IMF in the FPD case proved useful in visualising alternative pre-production control management methods. But during the application process, limitations of the IMF were also identified, namely,(i)
lack of adequate structured data collection for enterprise models,(ii)
lack of linking EMs with SMs effectively,(iii)
lack of verification, validations, and accreditation of developed models,(iv)
lack of structured output of the modelling exercises.The authors, therefore, found that it was necessary:(1) to define and deploy structured data collection methods during EM stages; (2) to deploy “systems thinking” (via causal loop modelling) to help better understand impacts of parameter change and causality amongst parameters in complex manufacturing systems and thereby to design better SMs and SM experiments; (3) to exercise verification, validation, and accreditation of enterprise and simulation models after all modelling stages; and (4) to tailor the generic IMF towards PPC policy selection. It is important to explore how to address key aspects of these identified IMF limitations. The following section will discuss the way in which the authors adopted systems thinking as an integral part of an enhanced form of the IMF.


## 6.2. Systems Thinking via Causal Loop Modelling

Causal loop models can visually represent causal effects between activities [43, 44]. This type of modelling helps identify aspects of complex system dynamics. When used as a standalone technique, however, Causal Loop Modelling (CLM) is limited in support of complex manufacturing systems design [45]. When applied on its own, CLM may prove useful for strategic decision-making but generally it does not adequately encode complex systems except at a high level of abstraction. However, when combined with suitable process modelling technique(s) focussed on structural design, it may prove useful for complex systems design, due to its ability to capture the causality of dynamics and provide a basis for qualitative analysis of businesses. Causal loop models by themselves cannot readily be quantitively modelled but they can be transformed into equivalent iThink models for simulation purposes. Previous to work of the authors and their colleagues, the literature had not shown that causal loop models being used in support of CIM implementation [45]. Masood [34, 46], Rashid et al. [47] and Agyapong-Kodua et al. [45] have further detailed and applied CLMs. The following will discuss model verification, validation, and accreditation.


## 6.3. Verification, Validation, and Accreditation of Models

Verification, validation, and accreditation (VVA) of models is very important in establishing confidence and trust in a model and its results. VVA terms are defined as follows. Verification is the process of determining that a model implementation accurately represents the developer’s conceptual description and specifications that the model was designed for [42]. Validation is the process of determining the manner and degree to which a model is an accurate representation of the real world from the perspective of the intended uses of the model and of establishing the level of confidence that should be placed on this assessment [42]. Validation is the process of establishing confidence in the usefulness of a model [48]. Being “valid” means “well suited to a purpose and soundly constructed” but does not imply that a model somehow becomes absolutely correct and true [49]. It is important to validate the static models up to an acceptable level of accuracy. The performance of the model needs to be compared with the operation of the real system to build confidence in the results. It is important to note that the model may only be “valid for the purpose.” In reality, however, it may not be possible to validate fully a model of a real system [20, 50–52]. Accreditation is the formal certification that a model or simulation is acceptable for use for a specific purpose. The validation method adopted here generally follows the method suggested by Robinson [50] (i.e., validation of static model, data, codes, and black box approaches). Accreditation is conferred by the ME best positioned to make the judgement that the model or simulation in question is acceptable [42]. In MEs there may be many types of potential operational user, programme manager users, and contractor users, depending upon the purposes intended. Figure 19 illustrates the basic differences between the VVA terms. Having explored the systems thinking and model verification, validation, and accreditation, the next section will propose the EIMF.Figure 19
Verification, validation, and accreditation [42].


## 7. The Enhanced Integrated Modelling Framework (EIMF)

In this section an enhanced form of the IMF is proposed, which is based on observations made during the FPD case study. The EIMF is designed to engineer change/reconfiguration within MEs, and relative to the IMF it includes additional steps of(1) using structured data capturing methods during modelling Stage 1, (2) creating causal loop models if and where necessary, (3) using structured modelling analysis based upon results of alternative configurations (e.g., production policy matrix within the IMF stages), (4) VVA of models after modelling stages, and (5) model implementation, which aims to enhance the framework resulting in more logical models of any complex system under study. The stepwise EIMF modelling approach is shown conceptually in Figure 20, while its relationship with respect to the IMF can be expressed as follows:
(1)EIMF=IMF+Stagesof(CLM+ModellingAnalysis+VVA+Implementation).Figure 20
The simplified version of EIMF.The additional steps included in the EIMF are discussed in the following.


### 7.1. Stage 2: CLM

Following EM but before moving to SM it was decided that CLM could usefully enhance the IMF resulting in(1) improved system decomposition; (2) designing a set of experiments to deploy the simulation model to address issues of concern to the organisation being studied; and (3) identification and improved design of coherent set of computer executable simulation experiments. The CLM stage is shown in Figures 21 and 22. The CLM stage consists of the following procedural steps (see Figure 22):(i)
A21: Identify and document main issues involved,(ii)
A22: Identify and document main causes,(iii)
A23: Identify and document main effects,(iv)
A24: Create causal loop model.Figure 21
Design steps of EIMF to reconfiguring MEs.Figure 22
Procedural steps of CLM (A2).


### 7.2. Step 4: Modelling Analysis

The modelling analysis stage enables the system designer to use simulation models (supported as required by CLM) in a structured way to replicate existing behaviours and to predict, analyse, and explain potential future behaviours arising from decision-making. The selection of KPIs is a challenging task in today’s dynamic environment and should show causal relationship [53]. Analysis of results are based on ME deployment of current (AS-IS) and possible future (TO-BE) responsiveness strategies, where KPIs are used to predict and compare production system behaviours under alternative strategies. The decision-makers might be considering KPIs, for example, time (reduced lead time or ramp up time), cost (reduced production cost or life cycle cost), and so forth, but not limited to these only.


### 7.3. Step 5: Modelling VVA and Implementation

The AS-IS enterprise and simulation models generally need VVA before embarking on TO-BE model generation and testing. Also, upon reaching a near optimal model reconfiguration solution, the results require VVA. In effect, this process is carried out at all stages and formally acknowledged before implementation. Hence before final selection of strategy and production system configurations presentations are made to relevant funders and managers. Upon successful VVA, the ME management may approve the finalised TO-BE reconfiguration solution to be implemented within the ME. Table4 presents an overview of the methods and tools to be used in EIMF. It is anticipated that the EIMF will be tested in more complex situations by going into further depth of ME production control.Table 4
Overview of the EIMF—the methods and tools to be used.
EIMF stages
Details/steps
Reference architectures, methods, or concepts (to be) used
Tools or templates (to be) used to apply EIMF
Stage 1:EM
Capture industrial data and create big picture
CIMOSA
Structured data capturing templates; MS Excel
Create detailed enterprise models using process maps, resource, and work data
CIMOSA
EM templates (i.e., context diagram, interaction diagram, structure diagram, and activity diagram) and MS Visio
Stage 2:CLM
Develop causal loop models (if and where required)
Systems thinking, CLM formalisms
CLM formalisms, MS Visio
Stage 3:SM
Develop AS-IS simulation models for candidate strategies
CIMOSA (generic level).For example, PPC methods (partial level). For example, push, pull, Kanban, ConWIP (specific level)
Plant simulation, Simul8, Arena, iThink/Stella, MS Excel
Develop TO-BE simulation models for candidate strategies
CIMOSA (generic level).For example, PPC methods (partial level). For example, push, pull, Kanban, ConWIP (specific level)
Plant simulation, Simul8, Arena, iThink/Stella, MS Excel
Stage 4:Modelling analysis
Analysis of AS-IS and TO-BE model configuration results based upon KPIs
Specific analysing methods
Structured ways.Enterprise models. Causal loop models. Simulation models.
Stage 5:Modelling VVA and implementation
VVA of enterprise models and As-Is simulation models
Specific VVA methods
Verification: By modeller Validation: By industrial partner Accreditation: By industrial partner
Implementation of enterprise and simulation models
Specific implementation methods
Host ME tools (either owned or third party)


### 7.4. Significance of the EIMF

The EIMF is an enhanced version of the IMF and significance of its use is presented in the following (and is in addition to the aforementioned significance of the IMF):(i)
structured data capturing during EM stage;(ii)
introduction of CLM stage enable formal definition of objectives, broader situational analysis, a more focussed way of looking into global objectives while considering side effects;(iii)
improved system decomposition;(iv)
designing a set of experiments to deploy the simulation model to address issues of concern to the organisation being studied;(v)
identification and improved design of coherent sets of computer executable simulation experiments;(vi)
structured way of modelling analysis based upon AS-IS and TO-BE model reconfiguration KPI results;(vii)
structured use of VVA stages enhancing credibility of models and hence their results;(viii)
providing structured modelling outputs via additional optional stages to the initial IMF that will facilitate a set of production policy mix for better decision-making.Initially the IMF was proposed in this paper based upon general and specific literature analysis. Having applied the IMF in a Pre-Production Management System used in the automotive industry, it was enhanced to form the EIMF.


## 7.1. Stage 2: CLM

Following EM but before moving to SM it was decided that CLM could usefully enhance the IMF resulting in(1) improved system decomposition; (2) designing a set of experiments to deploy the simulation model to address issues of concern to the organisation being studied; and (3) identification and improved design of coherent set of computer executable simulation experiments. The CLM stage is shown in Figures 21 and 22. The CLM stage consists of the following procedural steps (see Figure 22):(i)
A21: Identify and document main issues involved,(ii)
A22: Identify and document main causes,(iii)
A23: Identify and document main effects,(iv)
A24: Create causal loop model.Figure 21
Design steps of EIMF to reconfiguring MEs.Figure 22
Procedural steps of CLM (A2).


## 7.2. Step 4: Modelling Analysis

The modelling analysis stage enables the system designer to use simulation models (supported as required by CLM) in a structured way to replicate existing behaviours and to predict, analyse, and explain potential future behaviours arising from decision-making. The selection of KPIs is a challenging task in today’s dynamic environment and should show causal relationship [53]. Analysis of results are based on ME deployment of current (AS-IS) and possible future (TO-BE) responsiveness strategies, where KPIs are used to predict and compare production system behaviours under alternative strategies. The decision-makers might be considering KPIs, for example, time (reduced lead time or ramp up time), cost (reduced production cost or life cycle cost), and so forth, but not limited to these only.


## 7.3. Step 5: Modelling VVA and Implementation

The AS-IS enterprise and simulation models generally need VVA before embarking on TO-BE model generation and testing. Also, upon reaching a near optimal model reconfiguration solution, the results require VVA. In effect, this process is carried out at all stages and formally acknowledged before implementation. Hence before final selection of strategy and production system configurations presentations are made to relevant funders and managers. Upon successful VVA, the ME management may approve the finalised TO-BE reconfiguration solution to be implemented within the ME. Table4 presents an overview of the methods and tools to be used in EIMF. It is anticipated that the EIMF will be tested in more complex situations by going into further depth of ME production control.Table 4
Overview of the EIMF—the methods and tools to be used.
EIMF stages
Details/steps
Reference architectures, methods, or concepts (to be) used
Tools or templates (to be) used to apply EIMF
Stage 1:EM
Capture industrial data and create big picture
CIMOSA
Structured data capturing templates; MS Excel
Create detailed enterprise models using process maps, resource, and work data
CIMOSA
EM templates (i.e., context diagram, interaction diagram, structure diagram, and activity diagram) and MS Visio
Stage 2:CLM
Develop causal loop models (if and where required)
Systems thinking, CLM formalisms
CLM formalisms, MS Visio
Stage 3:SM
Develop AS-IS simulation models for candidate strategies
CIMOSA (generic level).For example, PPC methods (partial level). For example, push, pull, Kanban, ConWIP (specific level)
Plant simulation, Simul8, Arena, iThink/Stella, MS Excel
Develop TO-BE simulation models for candidate strategies
CIMOSA (generic level).For example, PPC methods (partial level). For example, push, pull, Kanban, ConWIP (specific level)
Plant simulation, Simul8, Arena, iThink/Stella, MS Excel
Stage 4:Modelling analysis
Analysis of AS-IS and TO-BE model configuration results based upon KPIs
Specific analysing methods
Structured ways.Enterprise models. Causal loop models. Simulation models.
Stage 5:Modelling VVA and implementation
VVA of enterprise models and As-Is simulation models
Specific VVA methods
Verification: By modeller Validation: By industrial partner Accreditation: By industrial partner
Implementation of enterprise and simulation models
Specific implementation methods
Host ME tools (either owned or third party)


## 7.4. Significance of the EIMF

The EIMF is an enhanced version of the IMF and significance of its use is presented in the following (and is in addition to the aforementioned significance of the IMF):(i)
structured data capturing during EM stage;(ii)
introduction of CLM stage enable formal definition of objectives, broader situational analysis, a more focussed way of looking into global objectives while considering side effects;(iii)
improved system decomposition;(iv)
designing a set of experiments to deploy the simulation model to address issues of concern to the organisation being studied;(v)
identification and improved design of coherent sets of computer executable simulation experiments;(vi)
structured way of modelling analysis based upon AS-IS and TO-BE model reconfiguration KPI results;(vii)
structured use of VVA stages enhancing credibility of models and hence their results;(viii)
providing structured modelling outputs via additional optional stages to the initial IMF that will facilitate a set of production policy mix for better decision-making.Initially the IMF was proposed in this paper based upon general and specific literature analysis. Having applied the IMF in a Pre-Production Management System used in the automotive industry, it was enhanced to form the EIMF.


## 8. Reflections and Conclusions

This paper reports on a model-driven decision-making framework in support of ME transformation. The EIMF can support the coherent (“in context”) and systematic design of many types of (“fit for purpose”) discrete event and continuous SMs that (I) individually facilitate strategic, tactical, and operational decision-making roles required in MEs and (II) collectively facilitate joined-up/collective decision-making processes required to support the engineering of large- and small-scale ME change projects. Table5 shows weaknesses of IMF and how these are addressed in the EIMF.Table 5
Weaknesses of IMF and how these are addressed in EIMF.
Weaknesses of IMF
How these are addressed in EIMF
Lack of structured data capture for EM stage.
EM:Data capturing during EM stage in a structured way using templates enhances the framework.
There was a lack of linking EMs with SMs effectively with following identified weaknesses:(i) Chances of incorrect definition of objectives; (ii) Too much concentration on local objectives ignoring the global objectives; (iii) Limited situational analysis; (iv) Ignoring side effects
CLM:(i) It provides rightful definition of objectives; (ii) It provides broader situational analysis;  (iii) It provides more focussed way of looking into global objectives; (iv) It also considers side effects.
There was a need to enhance modelling analysis stage to predict in more quantitative terms.
Modelling Analysis:It provides a more structured way of modelling analysis based upon comparisons of AS-IS and TO-BE model reconfiguration results which are based upon focussed KPIs chosen for specific cases.
There was a lack of VVA of developed models.
VVA:It incorporates VVA of models enhancing their credibility and hence results.
Lack of structured output of the modelling exercises (e.g., difficulties in production policy decision making).
It provides a structured modelling output by providing additional stages to the initial IMF, which facilitates a set of production policy mix for better decision making.Having formed the EIMF, it was required to be applied and tested in industrial settings. It was, therefore, important to see what types of industrial application would be suitable for the purpose. The IMF was applied in a Make to Stock case of “preproduction management” in the FPD automotive industrial case [34]. The EIMF was applied in respect of both Make to Order (furniture manufacturing) and Engineer to Order (bearing manufacturing) system configurations, and it was seen how alternative designed production control configurations enable responsive business behaviours [34].The research has resulted in new contribution to knowledge in terms of new understanding on modelling complex systems of systems and has identified concepts and methods that collectively facilitate:(1) a structured model-driven integrated approach to the design, optimization, and control of reconfigurable MEs; (2) an enriched modelling concept framework to capture requirements of static and dynamic aspects of MEs, where the conceptual framework has the capability to be extended and modified; (3) an enriched and generic process modelling framework with capability to represent both static and dynamic aspects of an organisation; and (4) example application cases showing benefits in terms of lead time and cost reductions and in terms of improved responsiveness of processes and resource systems with a special focus on alternative forms of PPC.



---

*Source: 234939-2013-03-11.xml*