- Email: [email protected]
Process modelling in small–medium enterprise networks
Computers in Industry 38 Ž1999. 149–158
Process modelling in small–medium enterprise networks K. Mallidi b
a,)
, A.T. Paraskevopoulos a , P. Paganelli
b,1
a ITCC, Sapfous 143, 176 75 Kallithea, Athens, Greece Gruppo Formula, Via Matteotti 5 40055 VillanoÕa di Castenaso, Bologna, Italy
Abstract Virtualrextended enterprise concepts have gained considerable relevance in the last years, giving rise to several interesting studies and industrial applications. While significant effort has been spent to demonstrate the benefits of the new production paradigm on large companies, small-medium enterprises ŽSMEs. are still missing a proper approach to co-operative manufacturing. The ESPRIT 4 project 20723 PLENT Ž PLanning small-medium Enterprise NeT works. intends to fill this gap, focusing on virtual enterprise networks formed by aggregation of independent SMEs, rather than by decomposition of a single, large firm. The project started on January 1996 for duration of 30 months, involving 12 independent partners, including several users, in three EU countries ŽItaly, Spain and Greece. and one Eastern Europe country ŽHungary. w1x. The PLENT objective is developing a set of innovative software tools to support coordinated production planning and control in a distributed organisation formed by autonomous manufacturing SMEs. In this paper we introduce the process modelling approach adopted in PLENT, along with the prototype software developed for validation on the target SME networks. We introduce a detailed representation of the network process in terms of modelling primitives and data items required for the basic NOS Žnetwork operational schema. instantiation. We also describe the prototype software implementation with the IPSYS ToolBuilder meta-CASE tool. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Process modelling; Virtual enterprise networks; Meta-CASE; Production planning
1. Introduction The main benefits for SMEs in joining manufacturing networks are: Ži. access to new markets, by realising products that are out of reach for the single SME; Žii. increased productivity, by cumulating and optimising the nodes productive capacity; Žiii. improved reactiveness, through joint response to perturbations that would be unbearable for the single node;
)
Corresponding author. Tel.: q30-1-9514653; fax: q30-19591908; e-mail: [email protected], [email protected] 1 Tel.: q39-51-6002111; fax: q39-51-6002222, e-mail: [email protected]
Živ. improved resources utilisation, by avoiding duplication of functions across the network. Network creation is favoured by the SMEs lean and flexible structure and, for most of them, by a natural disposition toward cooperation, gained through stable subcontracting and partnership links. The main obstacles to network creation are the individualistic and independent nature of SME management, the lack of contractual frameworks for these new forms of cooperation and, on the information systems side, the lack of suitable methods and tools for distributed production management. The PLENT project addresses the production management requirements of SME networks, proposing an organisation model where: Ži. the nodes are
0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 Ž 9 8 . 0 0 1 1 5 - 8
150
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
autonomous firms spontaneously co-operating to pursue a common objective, i.e., producing and selling together a certain product; Žii. each node has basically equal rights on the manufacturing tasks originated by orders for the network final product; Žiii. a neutral coordination unit is established to plan and oversee the tasks execution, ensuring proper synchronisation and reactiveness; Živ. the coordination unit decisions are driven by transparent criteria, constantly updated to reflect the nodes current status and past performance. The network operation is supported by global planning and performance evaluation software at the coordination unit, and by local planning software at each node, to evaluate and confirm network planning decisions. The different decision-making environments are integrated on a distributed basis by means of a standard workflow. The most critical decision-support functionalities are required for coordination unit planning, including: Ži. order configuration and splitting into macrophases at the node level; Žii. tasks assignment based on multiple workload distribution criteria; Žiii. finite capacity planning based on the nodes declared capacity for each phase; Živ. partial re-planning of ongoing orders in response to node delay or other changes. Timeliness and reliability of planning decisions are
essential for acceptance of the coordination unit role by the individual nodes. For this, a key pre-condition is to have available a consistent and updated representation of the network distributed manufacturing process as shown in Fig. 1. To this purpose, a set of modelling primitives has been identified in the first part of the PLENT project, allowing a detailed representation of the network process. The resulting Network Operational Schema ŽNOS. consists of a product-oriented process representation given at the network level, i.e., where only macro-phases at each node and the transportations between nodes are visible. The NOS is a family-based reconfigurable structure, allowing representation of alternative product features and manufacturing paths, and it is completed by information on node capacities, manufacturing and transportation times. The above information produces the network flow graph ŽNFG. which identifies all the possible routes for delivering a product to a customer. NOS definition is a fundamental step in the creation of a PLENT network, as the NOS constitutes the basic structure for network coordination and planning. To this purpose, the co-ordination unit will be provided with powerful software tools for NOS creation, editing and analysis. To allow validation of
Fig. 1. The Plent model.
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
the modelling approach, such a tool has been implemented using the meta-CASE technology, allowing fast prototyping and testing of the NOS management functionalities. PLENT users in different countries are currently testing the prototype on the NOS data provided. It is the aim of this paper to introduce the process modelling approach adopted in PLENT, along with the prototype software developed for validation on the target SME networks. Section 2 introduces the basic NOS definition, in terms of modelling primitives and data items required for NOS instantiation. Section 3 describes the prototype implementation in the IPSYS ToolBuilder meta-CASE tool. 2. The network process model 2.1. Process modelling requirements The PLENT planning and management functions refer to an updated representation of the network, maintained at the co-ordination unit to capture relevant knowledge elements about the nodes and their joint behaviour. Primary among these elements is the description of the network distributed process, in terms of activities carried out by the different nodes to reach a common goal. This description is needed to specify the nodes capacity and responsibilities, to define the network planning policy, and to qualify the network offer with respect to external customers. More precisely, the following requirements are to be met. Ž1. Product-orientation. PLENT supports daily production management in enterprise networks where a cooperative manufacturing process is triggered by each customer order. Hence the process representation must be related to the final result, i.e., the ordered product which the different nodes concur to realise. Furthermore, only activities in the order supply chain are of interest, among all those performed by the network nodes. Ž2. Node-leÕel granularity. The network process representation must include all phases performed by the nodes to obtain a product. This does not require that every production and assembly operation is modelled. Rather, every macro-phase is identified that represents all activities carried out by a node to transform the inputŽs. received from the supplier
151
nodes into the outputŽs. transferred to the customer nodes. Ž3. Transfer phases. To obtain the final product, each phase output must be transferred to the subsequent phaseŽs. in the network process. This usually corresponds to a physical transportation of materials between the involved nodes, but it may also represent an exchange of information or a simple precedence. Due to the complexity of transports and communications in a distributed environment, transfer phases are a critical aspect to be considered for planning. Ž4. Family-based modelling. The PLENT network is a persistent and re-configurable structure, where each node is capable of offering a wide range of products. In general, a network offers different versions of the final product, that is, a family of products. For network coordination purposes, and to avoid redundancies, a unique, generalised process representation should be given for each family. In response to an individual customer order, the family process representation will be configured to obtain the required product version. Ž5. Scenario-independence. The network process representation must support different decision-making activities, such as planning, simulation and performance evaluation, carried out cyclically in varying network conditions and operating scenarios. This calls for a process representation which is as much as possible independent of contingent aspects, such as external demand, nodes status or calendar. 2.2. The network operational schema In consideration of the above requirements, the network operational schema ŽNOS. is defined as the sequence of all manufacturing and transfer phases required to obtain a given product, where: Ža. each manufacturing phase represents an atomic step in the distributed production process, in the sense defined by the above requirement Žii.; and Žb. each transfer phase represents the delivery of the preceding phase output to the next manufacturing phase. The NOS can be conveniently represented as an oriented graph, where nodes represent manufacturing and transfer phases, and arcs represent precedence links between subsequent phases. The NOS graph has the following properties.
152
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
Ž1. It is connected, in that all phases are linked into a unique structure, representing the distributed manufacturing process for the product family the NOS refers to. Ž2. It is acyclical, in that no phase can directly or indirectly receive input from itself. We assume that each phase introduces a component in the resulting product structure, and no product can be part of itself. Ž3. It has a single root node, i.e., a node with no outgoing arcs. The root node is assumed to be always a transfer phase, representing the finished product delivery to a customer outside the network. Ž4. It has a number of leaf nodes, i.e., nodes with no entering arcs. The leaf nodes are assumed to be always manufacturing phases, representing the first operations in the network distributed process. Ž5. It presents alternated manufacturing and transfer phases, since: Ž5a. A manufacturing phase must always be followed by a transfer phase. Any two subsequent manufacturing phases represent process steps that can be performed at different nodes, and thus a transfer is required between them. Otherwise, the two steps should be aggregated into a single phase. Ž5b. A transfer phase must always be preceded by a manufacturing phase. The only components of interest for network co-ordination are those produced inside the network; thus, a transfer can only be applied to a manufacturing phase output. All other materials consumed during phase execution, including those feeding the leaf phases, come from outside the network: ensuring their timely availability is up to local planning at the single node. 2.3. Manufacturing phases A manufacturing phase represents a portion of the production process covered by a single node. The phase represents all the activities performed at the node, from input acquisition to output delivery to the subsequent nodes, abstracting from the details of node resources operation. This does not mean that each manufacturing phase is performed exclusively by a certain node. In general, being the NOS scenario-independent, different nodes may declare themselves available to perform the same phase. These capacity declarations are taken into account by the coordination unit to assign phases to the avail-
able nodes, depending on the circumstances and the applied workload distribution criteria. Formally, said m i 4is1 . . . m and t j 4js1 . . . n the sets of manufacturing and transfer phases constituting the NOS graph, the ith manufacturing phase is represented by a triplet of the form: ²ID, Output, Input:i where: l ID is the phase name. The name is mandatory for each manufacturing phase and is univocal in the NOS graph. l Output is the indication of the phase output, represented by an arc Ž i, h. starting from m i and directed to a transfer phase t h . The output link is mandatory for each manufacturing phase, and the arc bears the indication of the corresponding output product p h , representing the phase final outcome. l Input is the list of input components consumed by phase m i . Multiple input is required to represent the different components required from other network nodes in order to perform the phase m i . Ø Each item in the list is represented by an arc Ž k, i . entering m i and starting from a transfer phase t k . This indicates that a quantity of the transferred component is consumed by phase m i . Ø For each arc, the consumed quantity qk is specified in proper units, to indicate the amount of kth input component required for a unitary amount of m i output. Ø According to the NOS graph definition, each leaf phase has an empty input list. For all other phases the list contains at least one element. The above definition leads to the general graphical representation for manufacturing phases, shown in Fig. 2. 2.4. Phase functional parameters According to the above requirement Živ. the NOS is defined as a generalised structure, representing all
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
153
The different product configurations resulting from phase m i correspond to legal combinations of the functional parameters values, where a configuration is legal if it matches the conditions in C. An in-deep discussion of product families is given in Ref. w2x, along with the methods for checking and comparing product configurations. 2.5. Transfer phases Fig. 2. Manufacturing phase.
the different versions in a family of products. Correspondingly, a phase output represents a family of components, each included into a different final product version. Given an order from the customer, the coordination unit must configure the NOS to obtain the corresponding distribution of orders for the individual nodes. Each order will indicate the required component version, selected among those associated to the required phase in the generalised NOS. These orders shall be managed by the node local planning transparently, i.e., using the same procedures and tools as for other orders coming from outside the network. This requires a product classification mechanism which is sufficiently general to be shared by all the nodes. A general model for products classification is that studied in Esprit Project 8224, RUMS. Referring to the RUMS product model w3x, a phase output can be in general represented as a family of products, sharing some basic features and functionalities. More precisely, being m i the ith manufacturing phase, the output product corresponding to the arc Ž i, h. is described by a triplet of the form:
A transfer phase represents the connection between two subsequent manufacturing phases. Formally, said m i 4is1 . . . m and t j 4js1 . . . n the sets of manufacturing and transfer phases constituting the NOS graph, the jth transfer phase is represented by a triplet of the form: ²ID, Source, Destination:j defined as follows. Ža. ID is the phase name. The name is not mandatory, being each manufacturing phase univocally identified by the couple ²Source, Destination:j . The name can be useful to characterise a complex transport, whereas a simple precedence may not need to be explicitly indicated. Žb. Source is the indication of the manufacturing phaseŽs. whose output is being transferred. Two cases are given: Ži. Source is represented by a single arc Ž i, j . starting from the ith manufacturing phase m i to indicate that the transferred product pj is produced by m i ŽFig. 3.. Žii. Source is represented by a set of entering arcs sh , j4hs1 . . . p , each starting from a manufacturing phase in the set m sh4hs1 . . . p of those producing the transferred product pj . Consequently, all the source arcs represent the same
ph s ² f , F , C :h where: f is the name of a family of products, univocally defined at the network level; F is a set of functional parameters representing the external features and functionalities shared by all products in the family; each parameter is defined on a finite domain of values; and C is a set of functional conditions, representing dependence and exclusion constraints on the functional parameter values.
Fig. 3. Transfer phase.
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
154
product, which is the one transferred by phase t j ŽFig. 4.. In such circumstances a manufacturing alternative is given, in that each entering arc represents a different process path to obtain the same product. Žc. Destination is a set of outgoing arcs j, d k 4ks1 . . . q , where each arc is directed to a manufacturing phase in the set m d k 4ks1 . . . q of those consuming the transferred product pj ŽFigs. 3 and 4.. As explained above, a consumed quantity is specified for each such arc. While the generic transfer phase t j must always have at least one Source arc, the Destination list can be empty in case the t j represents the transfer to the final customer.
Conversely, the alternative between producing and sub-contracting a component is perceived at the network level: the former phase represents the manufacturing of a component by a network node, while the latter represents acquisition of the same component from a sub-contractor outside the network. The alternative has to be considered by the coordination unit for workload assignment, since the two phases can be performed in different ways by two disjointed subset of nodes.
2.7. Composition alternatiÕes
2.6. Manufacturing alternatiÕes According to the previous definition for transfer phases, a manufacturing alternative is given when a transfer phase has two or more entering arcs ŽFig. 4.. These represent the same output product, which can be obtained from each of the corresponding manufacturing phases. It has to be observed that when the choice between alternative processes is resolved by the individual node, it must not be represented at the network level. For example, a complex manufacturing phase may be exploded at the node level into a process including alternative sequences of operations Že.g., FMS or traditional machining.. In such cases, the node local planning is offered a range of possibilities on how to obtain the same final result. These possibilities cannot be considered at the network level, since this would require a description of manufacturing resources and activities inside each node. For this reason, a single phase is used to represent the whole process, including all the possible alternatives.
Fig. 4. Transfer phase with manufacturing alternative.
Another kind of alternative is given when, depending on the chosen components, different versions of the final product are obtained. In general, different product versions are characterised by different composition structures, with a shared basic structure and a number of alternative components. Local alternatives affect the composition structure of a phase output product but are visible only to the node performing that phase. Since the NOS detail level does not extend to components managed locally by a node, these alternatives are not given an explicit representation in the NOS graph. Instead, the different versions of a phase output product are represented as configurations of the above defined phase functional parameters, which are mapped onto local alternatives by the node performing the phase. Network composition alternatives are given when the alternative components are visible at the NOS level, as output products of phases performed by network nodes. For example, the customer may be offered product versions deriving from two alternative components, each resulting from a different phase performed by a different node. This kind of alternative affects the coordination unit decisions on workload distribution and must be represented properly in the NOS, thus adding a further level of generalisation. Formally, said Ž k, i . the k th arc entering the production phase m i , a composition alternative is given when the arc joins two or more input links from different transfer phases, rather than from a single phase as in the original definition. Said t r l 4ls1 . . . n k the set of transfer phases connected to
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
m i through the kth arc ŽFig. 5., we assume the following: Ø Each phase t r l transfers a different product pr l . Ø All the different product types transferred by phases joining at the kth arc represent alternative options for the input component represented by that arc. Each of those types can be used for that component, in the indicated quantity qk . Ø Each such alternative has associated a network functional parameter f k with as many values as the alternative options. Formally, the parameter is defined as follows, where Õr l represents the value corresponding to the pr l product: f k : Ž Õr1 , Õr 2 , . . . , Õr n k . By choosing one of these values a different version of the final product is obtained, which presents the corresponding component as input for the phase mi. 2.8. NOS configuration and instantiation From the above analysis, three important observations can be derived about the NOS graph semantics. Ži. The NOS is a generalised structure, that needs to be configured against each single customer order, to obtain the specific process structure for the ordered product. Žii. The NOS graph is a representation of the distributed manufacturing process in abstract terms,
155
describing ‘how’ the final product is realised without saying ‘when’ and ‘where’ Ži.e., by which particular node. each different phase is to be executed. To this purpose, nodes capacity declarations have been introduced to complete the manufacturing phases representation. Given a phase in the NOS, all the nodes declaring capacity for it are potentially enabled to perform it. Žiii. The transfer nodes represent logical precedence relationships between manufacturing phases, indicating which phases consume a given phase output, without giving any indication of the physical path followed by components in the actual PLENT network. To this purpose, PLENT also includes a representation of the network topology, describing physical links between the nodes and how transport phases are performed across these links. Points Žii. and Žiii. are not covered in the present paper. To chose among the candidate nodes for phase assignment, and consequently to determine ‘when’ each phase is performed are the primary objectives of coordination unit planning. To this purpose a workload distribution mechanism has been defined in Ref. w2x, which is able to generate an instantiated version of the NOS on the basis of capacity declarations and links between the nodes. For what attains point Ži., a NOS configuration mechanism is required, to be applied on the generalised NOS before planning. The resulting configured NOS will be the basis for assigning manufacturing tasks to the network nodes. Configuration is a partially automated process, performed on the set of functional parameters and conditions associated to the NOS manufacturing phases and composition alternatives.
3. The prototype developed with meta-CASE tools 3.1. Description of the tool
Fig. 5. Composition alternative.
The environment of the prototype NOS management system, give us the ability to navigate between a text frame and a diagram frame for input, update or deleting the macro-phases that construct the NOS. Opening a new database we can define in the text frame an infinite number of products Žfamily of products., by giving a name and additional informa-
156
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
tion about the family, for example description. With the creation of a family of products automatically a NOS diagram is generated in the diagrammatic frame on the screen. The automatically created NOS contains a root-phase on the top of the frame. After that the user can enter with the help of a mouse one by one all the macro-phases. The input of the macro-phases in a NOS diagram can be accomplished following the next steps: Ži. by selecting from the menu the type of the phase e.g. manufacturing phase, transfer phase, leaf phase, etc. The type of the phase is selected the diagrammatic representation of the phase is automatically added in the diagrammatic frame e.g. a rectangular for a manufacturing phase; and Žii. by giving a name. Then the phase is added in the repository of the database. When the macro-phases are defined, the user has the ability to link the phases according with the predefined rules of the PLENT model, e.g., to link a manufacturing phase with a transfer phase and to define the name of the link, or to link a transfer phase with a composition alternative, and so on. But the user is forbidden to complete an action that is against the rules for example to link a transfer phase with another transfer phase. The NOS or a part of it is constructed, the user can navigate in the text frame by selecting a NOS entity Ža link or a phase. to view or add details that concern the selected entity. For instance, to add a description for a manufacturing phase or to define a set of functional parameters and functional conditions. The generic NOS is complete for a family of products, the user can define an infinite number of versions of output product for each family and for each version of product to generate a configured NOS from the generic one. To configure a NOS we must select a set of composition alternatives andror a set of phase functional parameters and conditions. Concerning the nodes that compose the PLENT network can be defined in Node Catalogue text frame. To add a node in the network, the node name is defined in Node Catalogue Frame and additional information are defined in Node Details Frame. Since a node has been added in the network, it can declare capacities for a number of macro-phases. Capacity declarations can be independent of the out-
put product version or parameterised if a set of functional parameters has been defined for the phase. To sum up, the prototype developed by ITCC supports the following: Ø Coordination Unit o Define product families. o Define versions of output products for each product family. Ø NOS o Define the sequence of all manufacturing and transfer phases required to obtain a given family of products. ŽManufacturing Phases, Transfer Phases and links between the phases have a graphical representation in a NOS graph.. o Define Functional Parameters and Functional Conditions for each manufacturing phase. o Define Composition Alternatives. o Generate a configured NOS from a generic NOS, a set of composition alternatives and a set of phase functional parameters and conditions. Ø Capacity Declarations o Each node can declare capacity for a number of phases. o Define Transportation Time to the destination node. 3.2. Implementation of the tool The prototype was implemented using the IPSYS ToolBuilder environment. ToolBuilder provides a meta-CASE tool ŽMETHS. which allows the developer to construct a data model for the method to be supported, including relationships between elements of the model. The data model is used to generate a CASE database for the tool as shown in Fig. 6. The
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
157
Fig. 6. Enacting Plent’s NOS specifications with Meta-CASE technology.
information held within the database may have a number of concrete representations, diagrammatic or textual. Changing an element of one representation updates the database and thereby any other concrete representation. This makes ToolBuilder particularly suitable not only for capturing methods but also for prototyping configuration management tools, process modelling management systems, developing reverse engineering and transformation tools, where the structured diagrams and mathematical text are alternative views of the same system. The formal notation is integrated into the objectoriented analysis data model by adding entities and attributes to model syntactic structures. Consistency and completeness checks can be specified and carried out automatically. Navigation between elements of models and between models can easily be specified and generated. These are needed to provide structuring mechanisms for specifications, and traceability both across the models and through time. ToolBuilder provides a standard user interface based on the use of diagram and structured text frames, control panels and context sensitive menus. Any graphical or textual component of a frame may have an attached menu of operations. Such operations may facilitate the production of other components, crosschecking or navigation between components. ToolBuilder also provides a Publisher tool which is used to specify the structure and format of reports to be produced by generated tool; a document con-
figuration specifies what information is to be included in the document and how it is to be laid out and presented. The Publisher allowed us to generate reports in the format required for processing by the co-ordination unit. The ToolBuilder technology is described in details in Refs. w4,5x. 3.3. Future work In the work reported in this paper we have achieved the implementation of a useful software prototype. The next step will be the implementation of a new extended version of the PLENT prototype to support the global planning and performance evaluation software at the co-ordination unit, and the local planning software at each node. The intention is to use the meta-CASE environment as the basis for much of this future activity.
References w1x Esprit Project 20723 - PLENT, Deliverable D01, Requirements Specification and Analysis, PLENT Consortium, 1996. w2x Esprit Project 20723—PLENT, Deliverable D02, Planning Small-medium Enterprise Networks, PLENT Consortium, 1996. w3x EP 8224—RUMS, Deliverable D01, Product and Process Modelling, RUMS Consortium, 1994. w4x Albert Alderson, meta-CASE Technology, Lincoln Software, 1996. w5x IPSYS ToolBuilder Product Summary, IPSYS Software, 1995.
158
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158 Kalliopi Mallidi is a software engineer in the IPSYS Software group at ITCC. She received her diploma from the Information Technology Department of Athens Technological Institute ŽTEI of Athens. in 1995.
Aggelos Paraskevopoulos is a chief researcher in the information systems group at ITCC and a PhD candidate student at the Panteion University of Athens. His research interests include process-centered engineering environments, meta-CASE technologies, process modelling, parallel processing algorithms and achitecture and Very Large Data Bases. Paraskevopoulos received a diploma in Electrical and Computer Engineering from the National Technical University of Athens ŽNTUA. in 1994. He is an affiliate member of the IEEE Computer Society and a member of ACM.
Paolo Paganelli is a principal engineer at Gruppo Formula where he is responsible for ERPrMRP software systems and his managing several European and national R&D projects involving modern manufacturing and organisational paradigms. Paganelli received a diploma in engineering in the Faculty of Engineering at the University of Bologna.
Process modelling in small–medium enterprise networks K. Mallidi b
a,)
, A.T. Paraskevopoulos a , P. Paganelli
b,1
a ITCC, Sapfous 143, 176 75 Kallithea, Athens, Greece Gruppo Formula, Via Matteotti 5 40055 VillanoÕa di Castenaso, Bologna, Italy
Abstract Virtualrextended enterprise concepts have gained considerable relevance in the last years, giving rise to several interesting studies and industrial applications. While significant effort has been spent to demonstrate the benefits of the new production paradigm on large companies, small-medium enterprises ŽSMEs. are still missing a proper approach to co-operative manufacturing. The ESPRIT 4 project 20723 PLENT Ž PLanning small-medium Enterprise NeT works. intends to fill this gap, focusing on virtual enterprise networks formed by aggregation of independent SMEs, rather than by decomposition of a single, large firm. The project started on January 1996 for duration of 30 months, involving 12 independent partners, including several users, in three EU countries ŽItaly, Spain and Greece. and one Eastern Europe country ŽHungary. w1x. The PLENT objective is developing a set of innovative software tools to support coordinated production planning and control in a distributed organisation formed by autonomous manufacturing SMEs. In this paper we introduce the process modelling approach adopted in PLENT, along with the prototype software developed for validation on the target SME networks. We introduce a detailed representation of the network process in terms of modelling primitives and data items required for the basic NOS Žnetwork operational schema. instantiation. We also describe the prototype software implementation with the IPSYS ToolBuilder meta-CASE tool. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Process modelling; Virtual enterprise networks; Meta-CASE; Production planning
1. Introduction The main benefits for SMEs in joining manufacturing networks are: Ži. access to new markets, by realising products that are out of reach for the single SME; Žii. increased productivity, by cumulating and optimising the nodes productive capacity; Žiii. improved reactiveness, through joint response to perturbations that would be unbearable for the single node;
)
Corresponding author. Tel.: q30-1-9514653; fax: q30-19591908; e-mail: [email protected], [email protected] 1 Tel.: q39-51-6002111; fax: q39-51-6002222, e-mail: [email protected]
Živ. improved resources utilisation, by avoiding duplication of functions across the network. Network creation is favoured by the SMEs lean and flexible structure and, for most of them, by a natural disposition toward cooperation, gained through stable subcontracting and partnership links. The main obstacles to network creation are the individualistic and independent nature of SME management, the lack of contractual frameworks for these new forms of cooperation and, on the information systems side, the lack of suitable methods and tools for distributed production management. The PLENT project addresses the production management requirements of SME networks, proposing an organisation model where: Ži. the nodes are
0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 Ž 9 8 . 0 0 1 1 5 - 8
150
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
autonomous firms spontaneously co-operating to pursue a common objective, i.e., producing and selling together a certain product; Žii. each node has basically equal rights on the manufacturing tasks originated by orders for the network final product; Žiii. a neutral coordination unit is established to plan and oversee the tasks execution, ensuring proper synchronisation and reactiveness; Živ. the coordination unit decisions are driven by transparent criteria, constantly updated to reflect the nodes current status and past performance. The network operation is supported by global planning and performance evaluation software at the coordination unit, and by local planning software at each node, to evaluate and confirm network planning decisions. The different decision-making environments are integrated on a distributed basis by means of a standard workflow. The most critical decision-support functionalities are required for coordination unit planning, including: Ži. order configuration and splitting into macrophases at the node level; Žii. tasks assignment based on multiple workload distribution criteria; Žiii. finite capacity planning based on the nodes declared capacity for each phase; Živ. partial re-planning of ongoing orders in response to node delay or other changes. Timeliness and reliability of planning decisions are
essential for acceptance of the coordination unit role by the individual nodes. For this, a key pre-condition is to have available a consistent and updated representation of the network distributed manufacturing process as shown in Fig. 1. To this purpose, a set of modelling primitives has been identified in the first part of the PLENT project, allowing a detailed representation of the network process. The resulting Network Operational Schema ŽNOS. consists of a product-oriented process representation given at the network level, i.e., where only macro-phases at each node and the transportations between nodes are visible. The NOS is a family-based reconfigurable structure, allowing representation of alternative product features and manufacturing paths, and it is completed by information on node capacities, manufacturing and transportation times. The above information produces the network flow graph ŽNFG. which identifies all the possible routes for delivering a product to a customer. NOS definition is a fundamental step in the creation of a PLENT network, as the NOS constitutes the basic structure for network coordination and planning. To this purpose, the co-ordination unit will be provided with powerful software tools for NOS creation, editing and analysis. To allow validation of
Fig. 1. The Plent model.
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
the modelling approach, such a tool has been implemented using the meta-CASE technology, allowing fast prototyping and testing of the NOS management functionalities. PLENT users in different countries are currently testing the prototype on the NOS data provided. It is the aim of this paper to introduce the process modelling approach adopted in PLENT, along with the prototype software developed for validation on the target SME networks. Section 2 introduces the basic NOS definition, in terms of modelling primitives and data items required for NOS instantiation. Section 3 describes the prototype implementation in the IPSYS ToolBuilder meta-CASE tool. 2. The network process model 2.1. Process modelling requirements The PLENT planning and management functions refer to an updated representation of the network, maintained at the co-ordination unit to capture relevant knowledge elements about the nodes and their joint behaviour. Primary among these elements is the description of the network distributed process, in terms of activities carried out by the different nodes to reach a common goal. This description is needed to specify the nodes capacity and responsibilities, to define the network planning policy, and to qualify the network offer with respect to external customers. More precisely, the following requirements are to be met. Ž1. Product-orientation. PLENT supports daily production management in enterprise networks where a cooperative manufacturing process is triggered by each customer order. Hence the process representation must be related to the final result, i.e., the ordered product which the different nodes concur to realise. Furthermore, only activities in the order supply chain are of interest, among all those performed by the network nodes. Ž2. Node-leÕel granularity. The network process representation must include all phases performed by the nodes to obtain a product. This does not require that every production and assembly operation is modelled. Rather, every macro-phase is identified that represents all activities carried out by a node to transform the inputŽs. received from the supplier
151
nodes into the outputŽs. transferred to the customer nodes. Ž3. Transfer phases. To obtain the final product, each phase output must be transferred to the subsequent phaseŽs. in the network process. This usually corresponds to a physical transportation of materials between the involved nodes, but it may also represent an exchange of information or a simple precedence. Due to the complexity of transports and communications in a distributed environment, transfer phases are a critical aspect to be considered for planning. Ž4. Family-based modelling. The PLENT network is a persistent and re-configurable structure, where each node is capable of offering a wide range of products. In general, a network offers different versions of the final product, that is, a family of products. For network coordination purposes, and to avoid redundancies, a unique, generalised process representation should be given for each family. In response to an individual customer order, the family process representation will be configured to obtain the required product version. Ž5. Scenario-independence. The network process representation must support different decision-making activities, such as planning, simulation and performance evaluation, carried out cyclically in varying network conditions and operating scenarios. This calls for a process representation which is as much as possible independent of contingent aspects, such as external demand, nodes status or calendar. 2.2. The network operational schema In consideration of the above requirements, the network operational schema ŽNOS. is defined as the sequence of all manufacturing and transfer phases required to obtain a given product, where: Ža. each manufacturing phase represents an atomic step in the distributed production process, in the sense defined by the above requirement Žii.; and Žb. each transfer phase represents the delivery of the preceding phase output to the next manufacturing phase. The NOS can be conveniently represented as an oriented graph, where nodes represent manufacturing and transfer phases, and arcs represent precedence links between subsequent phases. The NOS graph has the following properties.
152
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
Ž1. It is connected, in that all phases are linked into a unique structure, representing the distributed manufacturing process for the product family the NOS refers to. Ž2. It is acyclical, in that no phase can directly or indirectly receive input from itself. We assume that each phase introduces a component in the resulting product structure, and no product can be part of itself. Ž3. It has a single root node, i.e., a node with no outgoing arcs. The root node is assumed to be always a transfer phase, representing the finished product delivery to a customer outside the network. Ž4. It has a number of leaf nodes, i.e., nodes with no entering arcs. The leaf nodes are assumed to be always manufacturing phases, representing the first operations in the network distributed process. Ž5. It presents alternated manufacturing and transfer phases, since: Ž5a. A manufacturing phase must always be followed by a transfer phase. Any two subsequent manufacturing phases represent process steps that can be performed at different nodes, and thus a transfer is required between them. Otherwise, the two steps should be aggregated into a single phase. Ž5b. A transfer phase must always be preceded by a manufacturing phase. The only components of interest for network co-ordination are those produced inside the network; thus, a transfer can only be applied to a manufacturing phase output. All other materials consumed during phase execution, including those feeding the leaf phases, come from outside the network: ensuring their timely availability is up to local planning at the single node. 2.3. Manufacturing phases A manufacturing phase represents a portion of the production process covered by a single node. The phase represents all the activities performed at the node, from input acquisition to output delivery to the subsequent nodes, abstracting from the details of node resources operation. This does not mean that each manufacturing phase is performed exclusively by a certain node. In general, being the NOS scenario-independent, different nodes may declare themselves available to perform the same phase. These capacity declarations are taken into account by the coordination unit to assign phases to the avail-
able nodes, depending on the circumstances and the applied workload distribution criteria. Formally, said m i 4is1 . . . m and t j 4js1 . . . n the sets of manufacturing and transfer phases constituting the NOS graph, the ith manufacturing phase is represented by a triplet of the form: ²ID, Output, Input:i where: l ID is the phase name. The name is mandatory for each manufacturing phase and is univocal in the NOS graph. l Output is the indication of the phase output, represented by an arc Ž i, h. starting from m i and directed to a transfer phase t h . The output link is mandatory for each manufacturing phase, and the arc bears the indication of the corresponding output product p h , representing the phase final outcome. l Input is the list of input components consumed by phase m i . Multiple input is required to represent the different components required from other network nodes in order to perform the phase m i . Ø Each item in the list is represented by an arc Ž k, i . entering m i and starting from a transfer phase t k . This indicates that a quantity of the transferred component is consumed by phase m i . Ø For each arc, the consumed quantity qk is specified in proper units, to indicate the amount of kth input component required for a unitary amount of m i output. Ø According to the NOS graph definition, each leaf phase has an empty input list. For all other phases the list contains at least one element. The above definition leads to the general graphical representation for manufacturing phases, shown in Fig. 2. 2.4. Phase functional parameters According to the above requirement Živ. the NOS is defined as a generalised structure, representing all
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
153
The different product configurations resulting from phase m i correspond to legal combinations of the functional parameters values, where a configuration is legal if it matches the conditions in C. An in-deep discussion of product families is given in Ref. w2x, along with the methods for checking and comparing product configurations. 2.5. Transfer phases Fig. 2. Manufacturing phase.
the different versions in a family of products. Correspondingly, a phase output represents a family of components, each included into a different final product version. Given an order from the customer, the coordination unit must configure the NOS to obtain the corresponding distribution of orders for the individual nodes. Each order will indicate the required component version, selected among those associated to the required phase in the generalised NOS. These orders shall be managed by the node local planning transparently, i.e., using the same procedures and tools as for other orders coming from outside the network. This requires a product classification mechanism which is sufficiently general to be shared by all the nodes. A general model for products classification is that studied in Esprit Project 8224, RUMS. Referring to the RUMS product model w3x, a phase output can be in general represented as a family of products, sharing some basic features and functionalities. More precisely, being m i the ith manufacturing phase, the output product corresponding to the arc Ž i, h. is described by a triplet of the form:
A transfer phase represents the connection between two subsequent manufacturing phases. Formally, said m i 4is1 . . . m and t j 4js1 . . . n the sets of manufacturing and transfer phases constituting the NOS graph, the jth transfer phase is represented by a triplet of the form: ²ID, Source, Destination:j defined as follows. Ža. ID is the phase name. The name is not mandatory, being each manufacturing phase univocally identified by the couple ²Source, Destination:j . The name can be useful to characterise a complex transport, whereas a simple precedence may not need to be explicitly indicated. Žb. Source is the indication of the manufacturing phaseŽs. whose output is being transferred. Two cases are given: Ži. Source is represented by a single arc Ž i, j . starting from the ith manufacturing phase m i to indicate that the transferred product pj is produced by m i ŽFig. 3.. Žii. Source is represented by a set of entering arcs sh , j4hs1 . . . p , each starting from a manufacturing phase in the set m sh4hs1 . . . p of those producing the transferred product pj . Consequently, all the source arcs represent the same
ph s ² f , F , C :h where: f is the name of a family of products, univocally defined at the network level; F is a set of functional parameters representing the external features and functionalities shared by all products in the family; each parameter is defined on a finite domain of values; and C is a set of functional conditions, representing dependence and exclusion constraints on the functional parameter values.
Fig. 3. Transfer phase.
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
154
product, which is the one transferred by phase t j ŽFig. 4.. In such circumstances a manufacturing alternative is given, in that each entering arc represents a different process path to obtain the same product. Žc. Destination is a set of outgoing arcs j, d k 4ks1 . . . q , where each arc is directed to a manufacturing phase in the set m d k 4ks1 . . . q of those consuming the transferred product pj ŽFigs. 3 and 4.. As explained above, a consumed quantity is specified for each such arc. While the generic transfer phase t j must always have at least one Source arc, the Destination list can be empty in case the t j represents the transfer to the final customer.
Conversely, the alternative between producing and sub-contracting a component is perceived at the network level: the former phase represents the manufacturing of a component by a network node, while the latter represents acquisition of the same component from a sub-contractor outside the network. The alternative has to be considered by the coordination unit for workload assignment, since the two phases can be performed in different ways by two disjointed subset of nodes.
2.7. Composition alternatiÕes
2.6. Manufacturing alternatiÕes According to the previous definition for transfer phases, a manufacturing alternative is given when a transfer phase has two or more entering arcs ŽFig. 4.. These represent the same output product, which can be obtained from each of the corresponding manufacturing phases. It has to be observed that when the choice between alternative processes is resolved by the individual node, it must not be represented at the network level. For example, a complex manufacturing phase may be exploded at the node level into a process including alternative sequences of operations Že.g., FMS or traditional machining.. In such cases, the node local planning is offered a range of possibilities on how to obtain the same final result. These possibilities cannot be considered at the network level, since this would require a description of manufacturing resources and activities inside each node. For this reason, a single phase is used to represent the whole process, including all the possible alternatives.
Fig. 4. Transfer phase with manufacturing alternative.
Another kind of alternative is given when, depending on the chosen components, different versions of the final product are obtained. In general, different product versions are characterised by different composition structures, with a shared basic structure and a number of alternative components. Local alternatives affect the composition structure of a phase output product but are visible only to the node performing that phase. Since the NOS detail level does not extend to components managed locally by a node, these alternatives are not given an explicit representation in the NOS graph. Instead, the different versions of a phase output product are represented as configurations of the above defined phase functional parameters, which are mapped onto local alternatives by the node performing the phase. Network composition alternatives are given when the alternative components are visible at the NOS level, as output products of phases performed by network nodes. For example, the customer may be offered product versions deriving from two alternative components, each resulting from a different phase performed by a different node. This kind of alternative affects the coordination unit decisions on workload distribution and must be represented properly in the NOS, thus adding a further level of generalisation. Formally, said Ž k, i . the k th arc entering the production phase m i , a composition alternative is given when the arc joins two or more input links from different transfer phases, rather than from a single phase as in the original definition. Said t r l 4ls1 . . . n k the set of transfer phases connected to
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
m i through the kth arc ŽFig. 5., we assume the following: Ø Each phase t r l transfers a different product pr l . Ø All the different product types transferred by phases joining at the kth arc represent alternative options for the input component represented by that arc. Each of those types can be used for that component, in the indicated quantity qk . Ø Each such alternative has associated a network functional parameter f k with as many values as the alternative options. Formally, the parameter is defined as follows, where Õr l represents the value corresponding to the pr l product: f k : Ž Õr1 , Õr 2 , . . . , Õr n k . By choosing one of these values a different version of the final product is obtained, which presents the corresponding component as input for the phase mi. 2.8. NOS configuration and instantiation From the above analysis, three important observations can be derived about the NOS graph semantics. Ži. The NOS is a generalised structure, that needs to be configured against each single customer order, to obtain the specific process structure for the ordered product. Žii. The NOS graph is a representation of the distributed manufacturing process in abstract terms,
155
describing ‘how’ the final product is realised without saying ‘when’ and ‘where’ Ži.e., by which particular node. each different phase is to be executed. To this purpose, nodes capacity declarations have been introduced to complete the manufacturing phases representation. Given a phase in the NOS, all the nodes declaring capacity for it are potentially enabled to perform it. Žiii. The transfer nodes represent logical precedence relationships between manufacturing phases, indicating which phases consume a given phase output, without giving any indication of the physical path followed by components in the actual PLENT network. To this purpose, PLENT also includes a representation of the network topology, describing physical links between the nodes and how transport phases are performed across these links. Points Žii. and Žiii. are not covered in the present paper. To chose among the candidate nodes for phase assignment, and consequently to determine ‘when’ each phase is performed are the primary objectives of coordination unit planning. To this purpose a workload distribution mechanism has been defined in Ref. w2x, which is able to generate an instantiated version of the NOS on the basis of capacity declarations and links between the nodes. For what attains point Ži., a NOS configuration mechanism is required, to be applied on the generalised NOS before planning. The resulting configured NOS will be the basis for assigning manufacturing tasks to the network nodes. Configuration is a partially automated process, performed on the set of functional parameters and conditions associated to the NOS manufacturing phases and composition alternatives.
3. The prototype developed with meta-CASE tools 3.1. Description of the tool
Fig. 5. Composition alternative.
The environment of the prototype NOS management system, give us the ability to navigate between a text frame and a diagram frame for input, update or deleting the macro-phases that construct the NOS. Opening a new database we can define in the text frame an infinite number of products Žfamily of products., by giving a name and additional informa-
156
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
tion about the family, for example description. With the creation of a family of products automatically a NOS diagram is generated in the diagrammatic frame on the screen. The automatically created NOS contains a root-phase on the top of the frame. After that the user can enter with the help of a mouse one by one all the macro-phases. The input of the macro-phases in a NOS diagram can be accomplished following the next steps: Ži. by selecting from the menu the type of the phase e.g. manufacturing phase, transfer phase, leaf phase, etc. The type of the phase is selected the diagrammatic representation of the phase is automatically added in the diagrammatic frame e.g. a rectangular for a manufacturing phase; and Žii. by giving a name. Then the phase is added in the repository of the database. When the macro-phases are defined, the user has the ability to link the phases according with the predefined rules of the PLENT model, e.g., to link a manufacturing phase with a transfer phase and to define the name of the link, or to link a transfer phase with a composition alternative, and so on. But the user is forbidden to complete an action that is against the rules for example to link a transfer phase with another transfer phase. The NOS or a part of it is constructed, the user can navigate in the text frame by selecting a NOS entity Ža link or a phase. to view or add details that concern the selected entity. For instance, to add a description for a manufacturing phase or to define a set of functional parameters and functional conditions. The generic NOS is complete for a family of products, the user can define an infinite number of versions of output product for each family and for each version of product to generate a configured NOS from the generic one. To configure a NOS we must select a set of composition alternatives andror a set of phase functional parameters and conditions. Concerning the nodes that compose the PLENT network can be defined in Node Catalogue text frame. To add a node in the network, the node name is defined in Node Catalogue Frame and additional information are defined in Node Details Frame. Since a node has been added in the network, it can declare capacities for a number of macro-phases. Capacity declarations can be independent of the out-
put product version or parameterised if a set of functional parameters has been defined for the phase. To sum up, the prototype developed by ITCC supports the following: Ø Coordination Unit o Define product families. o Define versions of output products for each product family. Ø NOS o Define the sequence of all manufacturing and transfer phases required to obtain a given family of products. ŽManufacturing Phases, Transfer Phases and links between the phases have a graphical representation in a NOS graph.. o Define Functional Parameters and Functional Conditions for each manufacturing phase. o Define Composition Alternatives. o Generate a configured NOS from a generic NOS, a set of composition alternatives and a set of phase functional parameters and conditions. Ø Capacity Declarations o Each node can declare capacity for a number of phases. o Define Transportation Time to the destination node. 3.2. Implementation of the tool The prototype was implemented using the IPSYS ToolBuilder environment. ToolBuilder provides a meta-CASE tool ŽMETHS. which allows the developer to construct a data model for the method to be supported, including relationships between elements of the model. The data model is used to generate a CASE database for the tool as shown in Fig. 6. The
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158
157
Fig. 6. Enacting Plent’s NOS specifications with Meta-CASE technology.
information held within the database may have a number of concrete representations, diagrammatic or textual. Changing an element of one representation updates the database and thereby any other concrete representation. This makes ToolBuilder particularly suitable not only for capturing methods but also for prototyping configuration management tools, process modelling management systems, developing reverse engineering and transformation tools, where the structured diagrams and mathematical text are alternative views of the same system. The formal notation is integrated into the objectoriented analysis data model by adding entities and attributes to model syntactic structures. Consistency and completeness checks can be specified and carried out automatically. Navigation between elements of models and between models can easily be specified and generated. These are needed to provide structuring mechanisms for specifications, and traceability both across the models and through time. ToolBuilder provides a standard user interface based on the use of diagram and structured text frames, control panels and context sensitive menus. Any graphical or textual component of a frame may have an attached menu of operations. Such operations may facilitate the production of other components, crosschecking or navigation between components. ToolBuilder also provides a Publisher tool which is used to specify the structure and format of reports to be produced by generated tool; a document con-
figuration specifies what information is to be included in the document and how it is to be laid out and presented. The Publisher allowed us to generate reports in the format required for processing by the co-ordination unit. The ToolBuilder technology is described in details in Refs. w4,5x. 3.3. Future work In the work reported in this paper we have achieved the implementation of a useful software prototype. The next step will be the implementation of a new extended version of the PLENT prototype to support the global planning and performance evaluation software at the co-ordination unit, and the local planning software at each node. The intention is to use the meta-CASE environment as the basis for much of this future activity.
References w1x Esprit Project 20723 - PLENT, Deliverable D01, Requirements Specification and Analysis, PLENT Consortium, 1996. w2x Esprit Project 20723—PLENT, Deliverable D02, Planning Small-medium Enterprise Networks, PLENT Consortium, 1996. w3x EP 8224—RUMS, Deliverable D01, Product and Process Modelling, RUMS Consortium, 1994. w4x Albert Alderson, meta-CASE Technology, Lincoln Software, 1996. w5x IPSYS ToolBuilder Product Summary, IPSYS Software, 1995.
158
K. Mallidi et al.r Computers in Industry 38 (1999) 149–158 Kalliopi Mallidi is a software engineer in the IPSYS Software group at ITCC. She received her diploma from the Information Technology Department of Athens Technological Institute ŽTEI of Athens. in 1995.
Aggelos Paraskevopoulos is a chief researcher in the information systems group at ITCC and a PhD candidate student at the Panteion University of Athens. His research interests include process-centered engineering environments, meta-CASE technologies, process modelling, parallel processing algorithms and achitecture and Very Large Data Bases. Paraskevopoulos received a diploma in Electrical and Computer Engineering from the National Technical University of Athens ŽNTUA. in 1994. He is an affiliate member of the IEEE Computer Society and a member of ACM.
Paolo Paganelli is a principal engineer at Gruppo Formula where he is responsible for ERPrMRP software systems and his managing several European and national R&D projects involving modern manufacturing and organisational paradigms. Paganelli received a diploma in engineering in the Faculty of Engineering at the University of Bologna.