Journal of Engineering Design Vol. 18, No. 6, December 2007, 599–616
A design-oriented framework for modelling production management systems PH. G. MOSCOSO* IESE Business School, University of Navarra, Spain Design-oriented modelling frameworks are intended to support design practice, by helping designers to create models of specific design problems, within a class of design problems. This paper examines the development of a design-oriented framework for the design of production management systems (PMS). It is concluded that such a framework should encourage a holistic and integrated PMS design. A holistic design acknowledges that social and technical subsystems can achieve better management performance by collaborating with one another than one can individually. An integrated design does not artificially separate the PMS from the shop-floor it manages, but rather considers the two as intertwined and complementary parts of an organizational whole. This paper postulates four key axioms to be considered for achieving such a PMS design. A dual modelling framework is then presented that supports the envisioned PMS design approach, and that further allows the use of computer simulation. Its practical contribution is analysed in an industrial case study. Keywords: Modelling; System design; Information systems; Production management; Industrial case study; Computer simulation
1.
Introduction
The problem of modelling production systems has been central to information systems and operations management literature and practice. In both research areas there exists theoretical modelling literature focused on the analysis of planning models and solution techniques, and more empirical or case literature concerned primarily with implementation challenges. Much less research, however, has been undertaken on developing modelling frameworks for the design of production management systems (PMS). In the extant information systems literature, modelling the production or business process in general has been discussed very much in terms of information or user requirement determination (Brown and Ramesh 2002, Zoryk-Schalla et al. 2004). Such a requirement analysis typically occurs during the development of information systems and includes the use of design models. Wand and Weber (1993, 2002) discuss the importance modelling has in this context and review key open issues. Cognitive aspects of the requirement analysis are reviewed by
*Email:
[email protected]
Journal of Engineering Design ISSN 0954-4828 print/ISSN 1466-1837 online © 2007 Taylor & Francis http://www.tandf.co.uk/journals DOI: 10.1080/09544820601024313
600
Ph. G. Moscoso
Brown and Ramesh (2002). Within the information systems field, developing such models involves building a representation of selected aspects of a system in some domain. The models are used to represent both static and dynamic phenomena, and they have at least three purposes (Wand and Weber 2002): 1. Support communication between users, designers and developers. 2. Provide required input for the design process. 3. Document the original requirements for future reference (Kung and Solvberg 1986). According to Zorky-Schalla et al. (2004), in the extant operations management research, two types of modelling can be distinguished: (1) real-world observations are captured in simplified models that help researchers to distil the essence of the planning problem, and develop general insights; and (2) more axiomatic than empirical research focusing on approximate analysis and solution, resulting in models that are used extensively in software solutions. Typically, these are planning models built to elaborate a production plan over a specified time horizon that, while fulfilling certain constraints, satisfies the given demand and minimizes total cost. Furthermore, there exists a fair amount of empirical work on the implementation of PMS. Most of the work has focused either on the requirements and factors that are considered important for achieving a successful implementation, such as for example, the organizational structure, or has studied the implementation problem from a project management perspective (Hong and Kim 2002, Swan et al. 1999). However, much less research has been done on the modelling of the production management process itself; and, more specifically, on how to capture the management process for the PMS design. A good review is given by Zoryk-Schalla et al. (2004), where the authors specifically analyse the difficulties of capturing the production planning process in planning software. They develop an approach based on a normative method for hierarchical production planning. Yet the paper concludes that extensive support from highly trained modellers is necessary, as information technology tools may not be capable of assisting in properly building the production management model due to the complexity of the models in practice. To a significant extent, this complexity originates in the essential role humans still play in operating a PMS. Finally, in industrial practice, improving modelling of production would be very welcomed for activities such as process re-engineering or documentation of best practices, for example. Moreover, considering the significant amounts of money companies invest in the design and implementation of PMS, a better understanding of the success factors of developing the underlying (conceptual) management models for the PMS design is of great interest. In this paper, specifically, the modelling for such PMS design purposes is discussed. However, it is clearly recognized that other factors not studied further in this paper, such as, for example, management leadership or budget constraints, are also highly determinant for the PMS design. From here on, the paper is structured as follows. In section 2, which follows, some of the key PMS design challenges are reviewed. The purpose of this study and the intended contribution of the paper are explained. In section 3, the key axioms for the development of a design-oriented modelling framework are presented. In section 4, the resulting insights are considered for the development of a dual modelling framework for PMS design. The description of the framework focuses specially on the underlying ontological groundings (i.e. the modelling constructs). A simulation platform that provides operational support in using the framework is also presented. Section 5 instantiates the framework in an empirical case study of managing a semi-conductor assembly work-cell. Finally, section 6 offers some conclusions.
Modelling production management systems
601
2. The PMS design challenge and research contribution 2.1
Research perspective
Design research should begin with the definition of success criteria that state the aim of research or the problem that will be addressed (Smith and Clarkson 2005). This must be specific and clear enough to allow evaluation of research at its completion. The aim of the research reported here was to develop an understanding of PMS design challenges that would lead to the development of a modelling framework that supports the design process in industrial practice, and eventually improves quality of design output. The required understanding of PMS design problems was developed through interdisciplinary research projects together with industrial partners, as well as through study of relevant literature in this area. This understanding was summarized in four axioms taken into account when developing the envisioned modelling framework. The developed modelling framework was successfully tested in an industry case study.
2.2
Industrial practice perspective
Advances in the field of information technology have encouraged more and more companies to resort to technology to manage their production facilities (e.g. Enterprise Resource Planning (ERPs), Advance Planning System (APS), or other types of PMS). Modern information technology allows greater automation of production management. One of the newer approaches delivering interesting results in this field is multi-agent systems, where planning and scheduling problems are distributed to virtual agents (Wooldrige and Jennings 1995). Agents are software artefacts acting autonomously, without direct interference by the user, but subordinated to a control process. Many shop-floor managers, however, consider the results delivered by modern information technology far from optimal (Ulich 1994, Moscoso 2004). One key problem analysed in the literature is that technological solutions too often neglect the combined technical and social nature of shop-floors (Zuelch et al. 2004). The technologies implemented usually restrict drastically the autonomy of shop-floors, both in terms of decisions and execution; hence, they do not allow shop-floor personnel to contribute fully or to develop. The more dynamic and global the business environment becomes, the more acute these self-imposed limitations become in practice. As companies increasingly outsource part of their operations to third countries where labour costs are low, coordination becomes more challenging. Furthermore, as low costs are no longer sufficient for achieving sustainable competitiveness in the longer term, flexibility and speed of response become crucial for differentiation in the market. As a matter of fact, in many companies these environmental requirements and conditions have led to a deep change in how production planning and control is done, and in the way the nature of work within PMS is considered. Essentially, the vision of production managers is changing from a previously product/functional view focusing on certain states of production (e.g. utilization) to a more systemic view focusing on certain system capabilities (e.g. agility) (Lee 2004, Moscoso 1999). Consequently, new PMS design strategies and concepts are needed. Traditional deterministic views, where the uncertainties deriving from the complexity of production are considered a failure to be eliminated, are insufficient for coping with today’s production challenges. Instead, these uncertainties should be accepted as the norm, or even as a requirement for organizational learning and development (Espejo et al. 1996). This realization specifically calls for a move away from pure technocratic conceptions of PMS towards more holistic views, integrating human, technical and organizational aspects of production systems.
602
Ph. G. Moscoso
The main conclusion is that to remain competitive in today’s economic environment, PMS design must become a key objective for manufacturing companies. But the design must be based on a holistic and integrated understanding of both the production system and its management system (the PMS). 2.3 Research contribution The particular understanding of a given system, however, is ultimately determined by the model one has built of it (explicitly or implicitly). Therefore, in all the steps to be taken during PMS design, the models on which the design is based play a central role. The purpose of this article is to analyse the role of these models, and to provide some guidelines and tools that can instruct the required modelling for successful PMS design. This is the primary and more practical contribution the author would like to make. Secondly, the paper is intended to contribute to the envisioned research field through a more careful analysis of the requisites for the development of a holistic and integrated modelling framework for PMS design, as a review of extant research and industrial practice makes this look like something worth addressing.
3. 3.1
Key axioms for the design of PMS Modelling challenges and dilemmas
According to Hubka and Eder (1996), the task of designing consists of ‘the transformation of information from the condition of needs, demands, requirements and constraints into the description of a structure which is capable of fulfilling these demands’. PMS designers typically rely on their experience and rules of thumb to identify the effect of design parameters and control rules on management performance (Buzacott and Shantikumar 1993). In fact, designing involves forming mental representations in order to compare or recombine characteristics of design variants, introduce new characteristics, or reject others (Hacker 1997). In industrial practice, therefore, most decisions and actions during PMS design are based not on the actual production system, but on the designers’ mental images of it. The advantages and disadvantages of these mental models are well documented (for example, Senge 1994). For instance, they can take into account a wider range of information than just numerical data, and they can immediately be adapted to new situations and be modified as new information becomes available. However, they are not easily understood by others (i.e. interpretations of them differ), and they often are flawed, since leaps of abstraction may occur. The underlying assumptions are usually difficult to examine, so ambiguities and contradictions within them can stay undetected. Moreover, very often, mental models are tacit; that is, people are not even aware of their own mental models and the effects they have on their decisions. To overcome the limitations of mental models, formal modelling methodologies and frameworks have been introduced in many design fields. Very relevant frameworks in this direction were, for example, the ones developed within the general systems theory ideas of the 1950s by people such as Ashby and Bertalanffy. They provided very valuable system classification schemes. Along this line of work, a very comprehensive approach was developed within the systems engineering tradition by Hubka and Eder (1988). Their approach focused primarily on technical systems and considered a variety of possible bases for classification and modelling including function, type of operand, product use, production method or materials. For PMS design, process-oriented approaches have also gained significant interest, as firms face an increasingly more dynamic business environment. This, together with possibilities
Modelling production management systems
603
of modern information technology, has eventually led to the development of a wide variety of modelling concepts using simulation for the design of PMS (Davenport 1992, Moscoso 2004). Computer simulation is now widely accepted as an essential tool for both the design and the operational analysis of production systems. Traditionally, however, simulation has been viewed primarily as an analysis tool in which an abstract or conceptual model of the realworld system is obtained and then performance measures of the system are computed from the model. With the emergence of virtual production concepts, simulation has additionally become a synthesis or design tool, where a virtual prototype of the system is built and utilized during the entire design cycle. Nonetheless, important modelling drawbacks exist. First of all, both the modeller and the modelling technique precondition the set of variables to be represented in a model as well as their possible interactions. Obviously, when comparing different design solutions or scenarios (e.g. when using computer simulation), only the variables formally represented in the model are considered. Most simulation models focus primarily on technical aspects of manufacturing, representing only hard technical (i.e. quantifiable) variables as throughput time or capacity. Soft variables such as knowledge, skills or motivation, as well as the influences of a given organization, are not considered at all. For instance, the final model typically will neglect the fact that the organizational context affects the appropriateness of alternative PMS design options (Helander 1997, Moscoso et al. 1999); that is, the model will be the same for a plant in Asia as for one in Europe, regardless of their different social and organizational characteristics. One of two basic modelling options can be chosen, therefore. Either we formulate a numerically precise model that will certainly miss some essential aspects of production system behaviour, or we relinquish a certain kind of quantitative precision in order to include soft variables critical to system behaviour. Furthermore, two additional dimensions of this dilemma exist. First, if we want to share and review the model with other people, we have to maintain a balance between the complexity of the model needed for a proper understanding of the system under study, and the necessary simplicity for it to be shared by the various people involved in the design process. Second, the context of this modelling dilemma changes along the design process. In fact, providing modelling support for PMS design requires covering very different levels of mental abstraction along the different design process stages. In the first phases—that is, the identification and clarification of the design problem and the development of the conceptual frame for analysing different solutions—designers have to deal with high uncertainty with respect to the envisioned results. A design-oriented modelling framework should therefore enable early detection and correction of errors, as it is known that the cost of fixing errors grows exponentially as a function of elapsed time to discovery (Moody 1998). For the later phases of design—that is, the detail design of the chosen solution—a more concrete and specific model of the production system is required. In this later phase, detailed design decisions have to be taken (e.g. specification of maximum workstation capacity or layouts). Summing up, developing a design-oriented modelling framework should address two types of methodological issues: 1. Facilitate the designer’s tasks in procedural terms, taking into account the static and the dynamic complexity inherent in production management, as well as the different requirements along the design process. The first two axioms introduced next address these requirements. 2. Procedural support should ideally be complemented with content guidance for designers. That is, the design-oriented framework should provide guidance as to what elements and attributes should be modelled and how (descriptive), but without necessarily directly
604
Ph. G. Moscoso
imposing norms on the design effort (normative). The third and fourth axioms address this issue. 3.2
First axiom: distinguishing between regulatory and design models
Axiom: Models required for PMS design (i.e. design models) should be different from models required for the operational management of shop-floors (i.e. regulatory models).
A first answer to the question of the right modelling complexity is to distinguish between the models of production on which the PMS bases its operation (i.e. regulatory models) and the models on which the designers base their design activities (i.e. design models). This differentiation is based on two insights: in industrial practice it is very unlikely that the two will ever be identical, and the two model types serve fundamentally different purposes. The production model on which the PMS design is based will never be identical to the regulatory models coded in the brains of human operators because those regulatory models have been developed under particular influences of knowledge, experience and interaction (Grote et al. 2000). Even the models of different operators in a given plant are likely to be different, depending, for example, on their background or experience. Furthermore, the models will be very different from the ones coded in the plant’s ERP. While regulatory models are required for performing the production management tasks, design models should focus primarily on the interaction between the different regulatory models, both within the shop-floor and with the rest of the supply chain (Moscoso et al. 1999). A PMS design model must first define the particular action domains within the production management activities; that is, what each subsystem—individual, organizational unit, or technology—should do and how the different subsystems should communicate (Helander 1997). In fact, the quality of the PMS will depend on whether the design model used—and the semantics (terminology) on which this model was built—allow appropriate consideration of all relevant design variables (e.g. human operator’s motivation and knowledge) and representation of all the solution scenarios considered. The fundamental conclusion is that the primary purpose of a model for PMS design is to improve design, rather than any regulatory purpose. Finally, since the two models serve different purposes, based on these purposes one can decide what can and what cannot be left out. 3.3 Second axiom: providing a dual modelling framework Axiom: An integrated modelling support of the PMS design process should cover two basic design levels: an aggregated meta-level and a concrete object-level.
For initial design phases a more abstract system model will be most helpful, as it will make the desired functionality patterns of the design options more explicit, and consequently make the solution space more transparent. At this aggregated design level, the modelling of the fundamental relations among the shop-floor elements and between the shop-floor and its environment (e.g. supply chain), together with the reflection of design principles and criteria, are of primary interest. The purpose of a meta-model for this phase is to offer support for analysing innovative solutions while reviewing the risk of detrimental decisions and failures (Smith and Clarkson 2005). It should essentially provide a blueprint upon which to carry out the PMS design. A more concrete object-model should support the detailed PMS design (Schachinger and Johannesson 2000). For example, capacity profiles and scheduling procedures have to be
Modelling production management systems
605
tested. To describe the dynamic behaviour of a system, ideally it should be possible to easily extend the object-model to a simulation model. 3.4
Third axiom: complementing social and technical subsystems
Axiom: Social and technical subsystems can achieve higher production management performance through their interaction than each subsystem can individually; therefore, a complementary PMS design is most appropriate.
Although modern information technology allows more and more automation of production management, in today’s industrial practice guidance, support and control from human operators are typically still required to a significant extent (MacCarthy et al. 2001). Recognizing the importance of interaction between regulatory models means realizing that PMS design depends decisively on the interaction between the human operators and the technical subsystem; or more precisely, between their regulatory models. The degree of production management centralization and automation, and therefore the extent of the opportunities available to the human operators to participate in production management, must be adaptable to match the specific production context (e.g. qualification and motivation of the planners). The goal is to empower human contributions by designing job positions that allow operators to develop production management capabilities. This is a precondition for agile production management. PMS design must therefore take into account the fact that production management should not be dominated by technology. Ultimately, operators should learn to leverage themselves with the technologies in place, while at the same time countering the proven weaknesses of these technologies (Grote et al. 2000, Waefler 2002). 3.5
Fourth axiom: integrating PMS and the production system
Axiom: For PMS design one should not artificially separate the PMS from the shop-floor it manages.
The PMS and the shop-floor should be considered as two intertwined parts of an integrated organizational whole (e.g. a manufacturing shop-floor). In the socio-technical system notion, a shop-floor (design) model is proposed where manufacturing activities are the primary worksystem and the PMS Is the secondary system (Waefler 2002). Such a structure weakens the boundaries between the managing entity and the managed entity. It also allows balancing local autonomy and overall supply chain coordination, as the latter is only required to define the broader conditions for shop-floor operation (e.g. performance goals), without interfering in the details of shop-floor planning and control activities (Moscoso 1999). The goal is to establish an organizational structure where PMS and production systems are intertwined along both the technical and the social subsystems.
4. A dual modelling framework for PMS design 4.1 Providing a common terminology for PMS design The first step in developing the envisioned dual modelling framework is to specify the key elements of a holistic and integrated production management model that fulfils the four stated axioms. Semantics are therefore crucial to provide a precise terminology and mental conception for these elements. The difficulty of developing a terminologically precise production management modelling framework is that such management systems comprise a large number of very different and interrelated constituents. In addition, they may represent among themselves a variety of viewpoints of the managed system. Fortunately, significant work has been
606
Ph. G. Moscoso
done already in this direction. Several production system models have been developed and validated in practice. A detailed description of the different models studied, and the reasons for which concepts where chosen to be built on (in both the meta-model and object-model), can be found in Moscoso (2004). The core of the socio-technical system view of production management is the tasks to be performed. Functions are obtained by relating a task to a specific item to be transformed. On the next level, activities are generated by relating functions to the resources that allow transformation, and a management entity that manages the transformation. Finally, a process is made up of an ordered sequence of connected activities that determines a transformation (i.e. activities are elementary processes). A process consists of a source, a transformation and a sink, and takes place in an open, dynamic socio-technical system. Relations with the environment are modelled by the sources and sinks of the processes. Processes are only meaningful if they fulfil the tasks of the system; that is, the transformation between the source and the sink results in a value addition. Two types of tasks can be the foundation of a process: primary or secondary tasks. The primary task is given through the key purpose of the system and is the reason it was created. Secondary tasks are defined to preserve and control the system (Waefler 2002). Apart from production management, maintenance or calibration of the machines would be other secondary tasks. To exhaustively guide the PMS design, the concepts of purposes and goals are also crucial. The purpose refers to the ‘raison d’ˆetre’(e.g. manufacturing capacity) of the production system in relation to its environment and consequently results in the primary task. The goals (e.g. costs, time or quality) specify the intended characteristics and objectives of behaviour and are measured by a set of key performance indicators (KPIs) and with regard to targeted capabilities. To realize goals and purposes, a performance potential for the intended value addition is needed. This must be provided by the resources of the production system (e.g. the machines and the operators). The specific capabilities of a system are determined through its structure and processes. The structure of the production system is constituted by the amount, arrangement and types of its internal and external relationships (e.g. within the plant and between the plant and its environment). We need to distinguish between a static and a dynamic view of structure. The second is only given as processes take place. Together, both views show the order in time and space characterizing the system behaviour. Structure is in a complementary relation to process; that is, structures enable processes, but are also the result of processes. For example, a specific plant layout results in particular manufacturing processes. At the same time, those processes generate work-in-progress (WIP) that changes the plant’s capacity structure.
4.2 The meta-model for PMS design The meta-model is intended primarily as a design aid to guarantee a holistic and integrated perception of production systems in order to approach PMS design in the envisioned way. Based on the conception and terminology outlined above, a meta-model was defined (figure 1). It offers a design catalogue conceived as a set of key levers for tackling PMS design. The chosen set comprises seven highly interdependent dimensions, which are based on the system terminology of section 4.1: management, tasks, structures, processes, resources, KPIs and capabilities. The first five are independent variables of design; the last two are dependent variables. The framework for task specification is determined in the management dimension. Together with the tasks dimension, this establishes the base for the design of processes, structures and resources. The outlined meta-model is based on a recursive modelling concept, which
Modelling production management systems
607
Figure 1. The meta-model of the framework.
states that the same seven design dimensions must be considered on all modelling levels (e.g. for an entire plant, a section of it, or a men-machine system). The seven dimensions are essentially descriptive. They provide a reference framework for PMS design and are specified in more detail in table 1. However, an additional explanation is needed with respect to the management dimension. The inclusion of a normative level was considered necessary for the modelling, as a holistic design requires a corresponding design policy for technology usage. This policy should guarantee complementarities between social and technological subsystems. The criteria chosen are both descriptive and normative, concern all five system design variables in table 1, and are documented in detail in Grote et al. (2000) and Waefler (2002). The normative aspect provides designers with indications of how to meet psychologically founded demands for complementary system design. One key criteria, for example, is the objective of designing complete individual tasks; that is, tasks that include preparation, planning, execution, controlling and maintenance. Summing up, the meta-model is intended primarily as a design aid to guarantee a holistic and integrated perception of production systems in order to approach PMS design in the envisioned way. 4.3 The object-model for PMS design In a second step, to meet the purpose of also supporting more detailed design phases, the concept of the object-model was developed (see figure 2). It follows an object-oriented modelling approach, leveraging the close relationship between this approach and the general system theory. In addition, this modelling approach facilitates the use of object-oriented simulation
608
Ph. G. Moscoso Table 1.
Descriptive dimensions of the modelling framework (Moscoso et al. 1999).
The management dimension addresses the capability of a system to guarantee its long-term viability, and consists of three intertwined levels: • normative: description of principles and values as well as determination of goals and purposes of the system • strategic: description of the relations with the environment and the system’s development approaches • operative: description of value addition, coordination of subsystems and stabilization of variances The tasks dimension differentiates between two main task types: • the primary task is given through a determined purpose and is the reason that the system was created • the aim of secondary tasks is to preserve, plan and control the system Process description includes three main aspects: • sources describe the items to be transformed by the process and the relation with the previous processes • sinks describe the transformed items and the demand-patterns of the following processes • transformations describe the transformation of items from an initial state at time t to an end state at t + ∂ Structures describe the relations between the elements of the system. Two views must be distinguished: • the static view describes the hierarchical organization of the system and its subsystems • the dynamic view describes the procedural organization that is constituted during a process Resources describe elements of the system that can be allocated and contain information about their availability and their behaviour. There are five main aspects of resources to be considered: • functionality, flexibility, autonomy, degree of interdependence and degree of virtualization (i.e. independence of time and space) Capabilities describe the core capabilities of the system to reach determined goals and purposes as well as to survive in a given environment (c.f. management level). There are nine main capabilities to be considered: • competitive advantages, communication, structural and dynamic reaction (i.e. agility), synergism, realization, learning, efficiency and effectiveness KPIs describe quantifiable system characteristics. There are six main KPIs to be considered: • throughput, work-in-progress (WIP), utilization, lateness, throughput (lead) time and costs
platforms for PMS design. Simulation is probably the best methodological tool to gain insight into the dynamic complexity of production systems, and their advantages are well documented (Luethi et al. 1996). To ensure modelling coherence and consistency, the five design dimensions of the metamodel were transformed into the object-model. This was done by specifying four recursive modelling levels, derived from the system terminology of section 4.1.
Figure 2. The object-model of the framework.
Modelling production management systems
609
The starting point is the object-independent description of tasks. Functions are then described by relating a task to specific object-class items (to be processed), the instances of which have certain attributes that are transformed by the task. On the next level, activities are described by relating functions to the object-class resources, which make the transformation possible, and the object-class agents, the instances of which control the transformation. Using these object-classes, a specific activity (i.e. an elementary process) is described completely by some instances of these classes. The object-model concept describes a specific PMS by generating instances of the key object-classes, and specifying their behaviour and their relationships. To describe the dynamic behaviour of the system, such an object-model can easily be extended to a simulation model. Although object-oriented simulation approaches already have a long tradition in the production context, traditionally there seems to be a considerable gap between the modelling software offered by the simulation community and the modelling tools demanded by the designer community (Park et al. 1997). Most of all, the tools are not natural to designers, making it very difficult for them to learn and use them properly. For example, the concept of inheritance and encapsulation may be quite natural to object-oriented programmers, but less intuitive to an engineer designing PMS. Secondly, most of the available software is oriented toward the modelling of production systems and much less toward PMS design. Thus, embedding the modelling framework in a design-oriented simulation platform that supports designers in their model building for PMS design seems critical to make the framework relevant in industrial practice. This was one of the main reasons for further developing the simulation platform described below.
4.4
The simulation platform
The simulation platform—the Highly Interactive Discrete Event Simulator (HIDES) (cf. Luethi et al. 1996)—was originally developed as a general purpose simulation platform for the production and logistic context. It was designed for event-oriented simulation and was implemented in an object-oriented environment. It allows the user to build hierarchical models with different levels of abstraction, and it is based on a general reference model for logistic systems. When modelling in HIDES one can distinguish conceptually between a logical and a physical level, corresponding in reality to the separation of the physical system from its logistical control. The static structure of the system and the dynamic sequence of the physical events are represented on the physical level. The relationships are modelled as a directed graph with two types of nodes: stations and queues. Resources were introduced as abstract elements that can be allocated dynamically, containing information about their availability and their behaviour. The logical level comprises the control of the system, together with the information flow needed for that purpose. For designing PMS, the simulation platform was extended in two steps (Moscoso and Ulrich 1998). First, an additional third level was introduced in order to embed the agent class. This extended level forms the basis for developing the coordination process among the agents and is called the ‘management level’. It illustrates a management concept that formally regulates the competencies and responsibilities of the agents, and can therefore be considered an extension of the logical control level. For the specification of the object-class agents and its instances (e.g. an operator in a plant) for simulation, two issues had to be taken into account. From an external point of view, agents must be characterized by their purpose, their responsibilities, the services they perform, the information they require and maintain, and their external interactions. From an internal point
610
Ph. G. Moscoso
of view, one has to impose structures upon the informational and motivational states of the agents and control structures which determine their behaviour. As second step, the interaction of human resources with the management process, as it happens in reality, had to be enabled. For this purpose, a special type of agents providing the required interface functions was introduced. The multi-agent system therefore has two types of agents: control agents to execute the automated control tasks, and interface agents to establish the necessary interface for interaction with human designers and managers. The extension of the HIDES reference model to a multi-agent system is shown in figure 3. The control agents have to accomplish management tasks corresponding to those in a human environment. Therefore, problem-solving capabilities are required, which, in turn, include a certain degree of intelligence. These agents have general problem-solving procedures, called ‘engines’, which have to be specified individually for each application case. For the control agents, two levels of intelligence are available, corresponding to the different tasks to be accomplished: a reactive and a cognitive level. The reactive level is based on knowledge, which is represented in rules or decision trees. The solution process provides an adequate reaction to the actual situation and consists of a search procedure on the individual knowledge base. Reactive intelligence comprises all the well-known conventional automation, where an apparatus reacts to input signals according to well-defined rules. The possible outcome is selected among a number of predefined actions (e.g. finite state automata). The cognitive level includes reactive intelligence, but more sophisticated problem-solving procedures are also available. A base of methods offers a selection of methods ready for use. These methods can be applied in a problem-solving procedure where solutions are generated in view of explicit goals, valued according to relevant criteria, in order finally to choose the best one. The interface agents establish communication between the technical subsystem and the outside world. They are built up according to a general schema but have to be specified individually, like the control agents. They do not have any direct control duties (these functions are delegated to the control agents) and so lack any problem-solving capability. Their duty is to establish the necessary communication links and procure the required information about the actual state of the system. By means of these interface agents a human designer or manager is able to interact with the process, stop the simulation run, change instructions and then continue
Figure 3.
Structure of the simulation platform (Moscoso and Ulrich 1998).
Modelling production management systems
611
the run. This opens up a large field for interesting studies, particularly of the task distribution between technical and human subsystems in production management. A sort of interactive simulator is provided, where designers and managers can test and share their design options. 4.5
Performance evaluations during PMS design
Simulation in an experimental environment is one of the best ways of evaluating the quality of PMS design concepts (Park et al. 1997). As the object-model described earlier facilitates the use of simulation for PMS design, production operating curves were included in the modelling framework as a production management performance evaluation tool. Operating curves are an aggregated representation of a production system’s intrinsic operational behaviour and are described extensively in Wiendahl (1997). Developing the curves allows one to model the interrelationship between the KPIs introduced in the meta-model. On the one hand, designers can discuss what shape the production operating curve of the system under study should have (e.g. maximum capacity or ideal work load level). This shape will largely determine the behaviour of the production system. On the other hand, designers are able to predict the impact of changes in the production system (e.g. increased production speed) by simulating new, derived curve structures. The analysis of conflicting KPIs is highly relevant for PMS design, because PMS design practice deals with paradoxes all the time. Perceived contradictions are often the result of different meanings a design issue may have, depending on the viewpoint. For example, lowering the WIP level often brings to light problems such as unstable processes, unbalanced capacities, lack of flexibility or long reaction times (cf. capabilities). The different actors often consider these problems in isolation. To conclude, the dual modelling approach, through its meta-model, provides a general system model as a reference for PMS design. Selected design options can then be modelled in detail at the object-level and simulated with the HIDES platform.
5. A practical case study Many practical case studies in which the author has participated corroborate the importance of adequate modelling within the PMS design process. One of the studies was an interdisciplinary project together with work psychologists and operations research specialists, and this should be presented in more detail as it is very representative of the PMS design problems addressed in this paper. 5.1 The first-generation PMS The request from the industrial partner of this project was to analyse a new, highly automated work-cell for semi-conductor assembly. The work-cell is made up of several production facilities. Transport within the work-cell is performed by a fully automated robot (see figure 4). However, despite the high degree of automation, at least one operator is needed for each workcell to perform some manual tasks such as, for example, resetting and quality control. The greatest innovation of this work cell was a very sophisticated internal PMS based on intelligent agents. This PMS could be operated locally through a terminal. The introduction of the first generation of work-cells had revealed some problems, however. Clients of the company claimed that they were unable to achieve expected productivity improvements, and, in particular, that their operators had a hard time operating the new PMS.
612
Ph. G. Moscoso
Figure 4.
Structure of the work-cell.
The research team came to the conclusion that one key error in the design approach was to ignore the socio-technical nature of the work-cell. Moreover, the design approach followed did consider only technology as an enabler of dynamic production management. Such technocratic designs generally lead to highly intricate PMS that are not very agile. In industrial practice, this often reverts to an informal PMS, with foremen keeping their own additional databases in order to be able to keep due dates despite numerous changes (Wiendahl 1997). The second key error identified was to neglect the fact that the work-cell only supported a few manufacturing steps within the entire industrial semi-conductor back-end operation. Therefore, the preceding and the following process steps should have exerted a more explicit influence on the PMS design (Buzacott and Shantikumar 1992). It was decided that the internal PMS should be redesigned to overcome as many as possible of these deficiencies. 5.2 Redesigning the PMS As in their earliest attempts designers of the partner company did only rely on formal modelling tools for the technical specification of the work-cell, the partner company decided to test the dual modelling framework for a revision of the first-generation PMS, with on-site support from researchers. In a first step, a meta-model of the PMS was developed in group meetings. The start was the physical flow model of the work-cell management tasks, depicted in figure 5, and later detailed using basic process analysis tools.
Figure 5. Physical flow model of the work-cell.
Modelling production management systems Table 2.
613
Examples of key questions for the men–machine function allocation.
Question
Design aspects
How should the coupling between men and machine be designed? How transparent is the technical planning for human operators?
How flexible is the production management function allocation?
For the PMS design it is of interest, to what extend the human planners can choose the level of coupling in terms of time, location, methodology or cognition The central issue is to what extent human planners do understand the schedules proposed by the technical part of the PMS. Do they understand the constraints taken into account, and the logic underlying the computed solution? Here the design issue is to decide to what extend the degree of automation in production management can be changed depending on the particular production set-up
Then the key elements of the meta-model (e.g. tasks, structure, etc.) were discussed following a holistic and integrated work-cell view. As an example, table 2 presents three key questions regarding the men–machine function allocation in the PMS that had to be defined. Another example of the design issues in this preliminary phase would be the review of the KPIs. The company managers were surprised by the fact that the working meetings revealed different priorities among the different individuals participating as to the production goals to be achieved in terms of utilization, lead times or WIP. Next, an object-model was specified and codified into a HIDES simulation model. On this level, design discussion had to become much more detailed, as particular design options had to be reviewed. Ultimately, it was decided to build a software interface between the simulation platform and the real work-cell. As a result, the design team could test design options and specification in a ‘virtual cockpit’ (figure 6). Eventually, most of the first-generation design errors were solved in the next-generation work-cell PMS. Designers agreed that this process was very much facilitated by supporting PMS re-design with the design-oriented modelling framework presented here, together with the simulation platform. The key advantage was that the design models became more explicit and comprehensive, and so they could infallibly compute the logical consequences of the designer’s assumptions, and interrelate many more design factors simultaneously. Figure 7
Figure 6. The virtual cockpit for the work-cell PMS design and test (Luethi et al. 1996).
614
Ph. G. Moscoso
Figure 7.
Example of operating curves computed for the work-cell.
shows an example of computed operating curves for the work-cell, where the lead time, throughput and utilization are plotted for different work-cell work loads. As happens typically in industrial practice, the real operating state of the work-cell in the simulation presents a much higher work load level than the mathematically computed ideal state would suggest. Natural variability of order arrivals, for example, is a common cause for this, as it may generate queues even where average capacity would be sufficient a priori. Probably the most important lesson, however, as the designers acknowledged, was that by using the modelling framework it became clear to them that designing a PMS is not just a technology design, but a system design that requires a corresponding technology integration policy. In fact, as a result, the new-generation PMS was less automated than the previous one. It also took the situation of the previous and following process steps much better into account.Yet it is important to notice that the framework and simulation tools were not used as a substitute for the designers’ mental models, but as a complement; and that, probably independently of the utilization of the framework, this time designers could rely on their previous experience gained in the development of the first PMS generation.
6.
Conclusions
The aim of design-oriented frameworks is to improve designers’reasoning about different solutions to particular design problems. This paper presents such a framework for PMS design. The aim of the paper is to show that the framework is appropriate to support such design reasoning. The framework is intended for use in a specify-and-implement type of design practice; that is, where solutions are iteratively specified, improved and implemented, until a desired result is achieved.
Modelling production management systems
615
Specifically, in the PMS design context, both the literature review and the case study highlighted the need for holistic and integrated PMS design. The purpose of such a design is to complement the technical and social subsystems in the PMS (holistic) and at the same time consider the PMS as an integral part of the shop-floor it manages (integrated). Secondly, the analysis also showed the benefits of the dual modelling framework to instrumentally support such an integrated and holistic design. However, the modelling framework should not be understood as leading to a single straightforward design solution. It does not even provide detailed normative design guidance. Rather, the framework is intended to support analysis of the design space and reflection on design decisions, complementing the mental models of the designers. In order to make the modelling framework more user-friendly to practitioners, the aim of further research is to integrate it operationally in a design methodology (i.e. like a toolbox). To do that, further case studies will examine, among other things, the methodological principles to be made explicit in instructions for facilitating the use of the framework. These further practical validations should also help to identify opportunities for further improving the modelling framework. Acknowledgments The author thanks Toni Waefler from the University of Applied Sciences Northwestern Switzerland for his constructive ideas and helpful discussions throughout this research effort. References Brown, G.J. and Ramesh, V., Improving information requirements determination: a cognitive perspective. Inf. Manage., 2002, 39, 625–645. Buzacott, J. and Shantikumar, J., A general approach for coordinating production in multiple-cell manufacturing systems. Prod. Operat. Manag., 1992, 1(1), 34–52. Buzacott, J. and Shantikumar, J., Stochastic Models of Manufacturing Systems, 1993 (Prentice-Hall: Engelwood Cliffs, NJ). Davenport, T.H., Process Innovation: Reengineering Work through Information Technology, 1992 (Harvard Business School Press: Cambridge, MA). Espejo, R., Schuhmann, W., Schwaninger, M. and Billelo, U., Organizational Transformation and Learning, 1996 (Wiley: Chichester). Grote, G., Ryser, C., Waefler, T., Windischer, A. and Weik, S., KOMPASS: A method for complementary function allocation in automated work systems. Int. J. Human–Computer Studies, 2000, 52, 267–287. Hacker, W., Improving engineering design—contributions of cognitive ergonomics. Ergonomics, 1997, 40, 1088–1096. Helander, M.G., The evolution of ergonomics. Ergonomics, 1997, 40, 952–961. Hong, Y. and Kim, Y., The critical success factor of ERP implementation: an organizational fit perspective. Inf. Manage., 2002, 40, 25–40. Hubka, V. and Eder, W.E., Theory of Technical Systems: A Total Concept Theory for Engineering Design, 1988 (Springer: New York). Hubka, V. and Eder, W.E., Design Science: Introduction to the Needs, Scope and Organization of Engineering Design Knowledge, 1996 (Springer: London). Kung, C.H. and Solvberg A., Activity modeling and behaviour modeling. In Information System Design Methodologies: Improving the Practice, edited by T.W. Olle, H.G. Sol and A.A. Verrijn-Stuart, pp. 145–171, 1986 (North-Holland: Amsterdam). Lee, H.L., The tripple-A supply chain. Harvard Bus. Rev., 2004, 82(10), 102–112. Luethi, H.-J., Ulrich, H. and Dürig, W., Innovation by simulation using the example of an automated work-cell. Central Eur. J. Operat. Res. Econ., 1996, 2–3(4), 134–154. MacCarthy, B.L., Wilson, J.R. and Crawford, S., Human performance in industrial scheduling: a framework for understanding. Human Factors Ergonom. Manufact., 2001, 11(4), 299–320. Moody, D.L., Metrics for evaluating the quality of entity relationship models, in Proceedings of the 17th International Conference on Conceptual Modeling, Singapore, 1998. Moscoso, Ph. and Ulrich, H., A simulation-supported modeling approach for the design of production planning and control systems, in Proceedings of the First International Workshop on Intelligent Manufacturing Systems (IMS), Lausanne, 1998, pp. 51–64. Moscoso, Ph., Der Shop Floor: eine Herausforderung für das Logistikmanagement, PPS Manage., 1999, 4, 22–26.
616
Ph. G. Moscoso
Moscoso, Ph., Waefler, T. and Windischer, A., A modelling framework for complementary design of production planning and control systems. Ergonomics, 1999, 42(11), 1492–1506. Moscoso, Ph., Integrales Management der Produktion, 2004 (WVBerlin: Berlin). Park, T., Han, K. and Choi, B., An object-oriented modelling framework for automated manufacturing system. Int. J. Computer Integrat. Manufact., 1997, 10(5), 324–334. Schachinger, P. and Johannesson, H.L., Computer modelling of design specifications. J. Eng. Design, 2000, 11(4), 317–329. Senge, P., The Fifth Discipline, 1994 (Doubleday: New York). Smith, J. and Clarkson, P.J., Design concepts to improve reliability. J. Eng. Design, 2005, 16(5), 473–492. Swan, J., Newell, S. and Robertson, M., The illusion of ‘best practice’ in information systems for operations management. Eur. J. Inf. Syst., 1999, 8(4), 284–293. Ulich, E., Arbeitspsychologie, 3rd edition, 1994 (vdf: Zurich) Waefler, T., Verteilt koordinierte Autonomie und Kontrolle. Doctoral thesis, University of Zurich, 2002. Wand, Y. and Weber, R., On the ontological expressiveness of information systems analysis and design grammars. J. Inf. Syst., 1993, 3, 217–237. Wand, Y. and Weber, R., Research commentary: information systems and conceptual modeling—a research agenda. Inf. Syst. Res., 2002, 13(4), 363–376. Wiendahl, H.P., Fertigungsregelung, 1997 (Hanser Verlag: Munich). Wooldrige M. and Jennings, N.R., Agent theories, architectures, and languages: a survey. In Intelligent Agents, edited by M. Wooldrige and N.R. Jennings, pp. 1–22, 1995 (Springer, Berlin). Zoryk-Schalla, A., Fransoo, J.C. and de Kok, T.G., Modeling the planning process in advanced planning systems. Inf. Manage., 2004, 42, 75–82 Zuelch, G., Jagdev, H.S. and Stock, P., Integrating Human Aspects in Production Management, 2004 (Springer: Berlin).
