The presentation focussed on the content of the ARIS Toolset with emphasis on the ARIS way of representing enterprise models. Starting from the ARIS House the different model views (Data, Function, Organisation, Control (Process) and Product/Service) are presented and the related modelling language is explained and demonstrated.

The language consists of Events that trigger Functions, Data are processed by Functions, Employees are responsible for Functions and representing a Position in Organisational Units, Functions create or process Product/Service.

ARIS defines a Business Process Architecture that provides several modelling levels (Overview Model, Rough Models, Detailed Models of various levels). Levels are derived from each other by decomposing high level functions and providing additional details. Process dynamics are modelled by link operators (AND, OR, XOR).

ARIS models are used for business process analysis and optimisation. A number of methods are available like ARIS activity based costing, ARIS simulation for process analysis, process communication and access to documents via ARIS web publisher.
 
 

Enterprises today face dramatic changes: Internationalisation of market and competition relations, increasing complexity of products and services, shorter life cycles and individualisation of market and client requirements, dynamic changes and innovations of processes and organisational structures etc. These changes require that in the future more business partners must contribute to the value chain. New forms of collaboration over enterprise boundaries have to be developed and set up. By leaving enterprise boundaries risk sharing, reduction of complexity and bundling of task-specific competencies can be used in a wider range. Two common organisational forms developed in the last years: the virtual corporation and the extended enterprise.

Both organisational forms have in common that they imply crossing-boundary business activities. They are the basis for an optimal configuration of business processes and they present the chance to optimise the value-chain across company boundaries. Optimisation across corporation boundaries requires an extended view on business processes: Business processes in virtual companies or extended enterprises can influence the work of several companies. But these distributed business processes can nowadays only be modelled in an insufficient way. Traditionally business process modelling focused on business processes and organisational structures within an isolated company. Collaboration with other companies was merely described as information and material flow from and to other companies.

The current status quo of business process analysis and modelling does not fulfil the requirements of nowadays-organisational forms as described above. Several aspects of business process analysis and modelling must be extended to support the concepts of virtual companies and extended enterprises:

• Modelling tools: Tools must support concurrent modelling.
• Analysis methodology: Methodologies must be extended to integrate all companies participating in a virtual corporation or an extended enterprise.
• Modelling language: Modelling languages must semantically und syntactically support the modelling of distributed business processes.

Early ICEIMTs struggled with finding the best balance of what needs in the enterprise could be supported by enterprise-wide information infrastructure. Ten years ago, many users were content with any solution that allowed reasonable interoperability and data sharing. The system-wide capabilities gleaned were rudimentary and practically limited to scheduling and resource optimisation. Solutions presumed that the product was well understood, the resource pool known and unevolving, and that all information resources in the value chain were re-engineerable to a significant extent.

This new enterprise integration agenda seems to mandate two key architectural principles: federation and agent systems.

The notion of federation was identified as desirable in the first ICEIMT process as a complement to centralized or master models. A key notion of federation is that everyone is free to use the tools that they feel are best for their job; there is no artificial pressure to compromise for integration's sake. One pool of information and models is maintained, and this is done at the finest level of decentralization, as close to the process as possible. However, the amount of information, its integrity, formality and timeliness may be more robust than locally warranted. Federation preserves legacy systems, which is a benefit; but the more important advantages are allowing innovation in the domain and tapping the source as close as possible to actual information used to do work.

Technical difficulties do exist. The general approach for all such tasks is to create an "interlingua" and a formal definition, an "ontology" of the world in which it exists. Fortunately, this is a well-studied problem. Formal methods had been developed for defining such ontologies, and significant effort has gone into understanding practical process ontologies that deal with vexing problems of state. The requirement for a federation ontology is much greater, or seemingly so. Representing processes actively is simply a matter of expanding the ambition of what one wants process models to do. In this vision, processes and process aggregations will (as one service) be "turned loose" within conditions constrained by enterprise goals to seek optimum solutions. For example, a specific product design would be set, some key partners and processes established, some constraints on processes set (for instance quality auditability) and the agent system set to produce a range of business and process combinations and their various costs and risks. The costs be determined by actual "virtual manufacturing;" the risks determined by many iterations (including similar cases).

The second of our three major problems concerns a key feature of the federation suggested by prior workshops: the notion of persistent indices. Most enterprise-wide, system analyses potentially require nearly all information in the enterprise, but practically need only a small portion of that information. Federation should provide some sort of index that characterizes elements of each process to indicate which ones should be "fetched" for each analyses or simulation.

The third problem is perhaps the most challenging. We propose a solution that leverages the notion of emergence. It does not address all concerns of strategic planners, but it does address some rather high value problems. The notion is simple: to recognize that essentially all the components of strategic management are artefacts of imperfect tools in the infrastructure (and the accident of the conflation of the management of production with the management of capital). A truly frictionless infrastructure would integrate business processes as an intrinsic layer over operational processes. Abstractions from one to the other would define both some behaviour of the layer and elements within the layer.

We believe that the foundation for all such infrastructures should begin with the core value-producing processes, those covered by PSL (Process Specification Language).
 
 

Global Enterprises have to face new ways of distributed work. Within this huge field, MISSION focuses on the Manufacturing Engineering process and, furthermore, on simulation. The global approach is enhanced by the integration of three regions from Japan, Europe and USA. The E.U. and U.S. partners have defined a common architecture, called the MISSION General Architecture. The European demonstrator architecture is one instance of the MISSION general architecture.

The project MISSION develops an environment for integrated applications of simulation and non-simulation tools from different vendors. Three years ago the High Level Architecture (HLA) was selected as the base for the MISSION architecture. The HLA satisfied many requirements for distributed simulations. Within military applications of the HLA, for each new model a new simulator will be programmed, typically. Therefore, a flexible interface for simulation models is not required for military applications. This is completely different within civil domains, where the total effort spent to one simulation study is extremely low, compared to defence applications. The dependency of the interface description to the HLA-RTI from the specific simulation model is a critical disadvantage for regular civil applications of HLA.

Within MISSION an approach has been established that allows flexible configuration of interfaces of tools within a simulation scenario. This approach is based on a template library approach and the generation of a federate configuration file for each simulation interface as well as the generation of the federation execution file for the HLA-RTI in parallel. The major advantage of this approach is that changing simulation models or adding completely new ones requires only changes of the configuration, but no re-programming. Of course, those interfaces need to be related to a specific application field then, which is manufacturing systems (including virtual enterprises and logistics) within the MISSION project.

The design and implementation of a MISSION prototype to demonstrate the usage of the MISSION platform for modelling and simulation of global distributed enterprises was one task within the European MISSION project. The demonstrator shows the connection between different simulation models as well as between software tools providing information for the simulation process. The software components can be executed on different computers at different locations.

The demonstrator shows how the MMP can be used to bridge the gap between different simulation model islands. In addition, the bridge between the simulation and the necessary information available within different software tools is shown. The demonstrator is mainly based on existing tools and methodologies. The MS-RTI and the MSE integration infrastructure are anchors for the different components of the MMP.
 
 

Most major Enterprise Modelling and Integration projects (e.g. ESPRIT/CIMOSA, ICAM/IDEF, IPK/IEM, ESPRIT/CCE-CNMA, LUT/CIM-BIOSYS, PERA, GRAI/GIM, GERAM) have demonstrated the necessity of developing enterprise models to support analysis, design and management of the business processes that are executed in companies. These processes must be modelled from different points of view and at different levels for the purpose of building more integrated systems (stand-alone companies or networked enterprises). These ideas have even contributed to standardisation and unification efforts to harmonise concepts and terminology (CEN ENV 40 003 and its reworked version, CEN ENV 12 204 and its reworked version, ISO CD 15 704, ISO IEC ODP, GERAM, EDOC, BPML).

Several commercial tools for enterprise engineering as well as process management are also being proposed based on these concepts (e.g. ARIS ToolSet, FirstSTEP, PrimeObjects, Bonapart, MOOGO, etc.). However, business users still face a variety of difficulties in their day-to-day work. Therefore, it becomes a necessity to define a unified language for universal use by business users as well as within the enterprise modelling community and which would address these problems. We therefore propose the development of such a language, called Unified Enterprise Modelling Language (UEML), by analogy with UML devoted to conceptual systems modelling.

Objectives:

The objective of UEML is to provide the Enterprise Modelling/Engineering community with a standard, general-purpose descriptive language to satisfy its needs. UEML will be based on international standards (CEN ENV 12 204 and ISO / IEC ODP) as well as from constructs of major commercial tools available.

Relevance and Benefits:

The relevance of the proposal is clear because of its relevance to industrial companies as well as to consultants and software developers. It supports the development of exploitable models in an appropriate framework at different management levels of the company and at different levels of details (function, information, organisation, resource) would be welcome by the business user community and allows to move models from one tool to another more easily, and therefore be able to share or exchange models with his business partners.

Furthermore, this common format and way of expressing enterprise models should make it easier to develop so-called reference models, i.e. partial, reusable models, which could be shared and commonly developed within a company or within a community of business partners.
 
 

The mismatch between syntax and semantics of languages for Enterprise Modelling has been identified as a serious shortcoming in the course of Enterprise Integration by the ICEIMT’97. This is the fundamental reason why models, even syntactically compatible ones, can neither be exchanged between tools, nor can they be federated and The ICEIMT’97 identified the need for both a Unified Enterprise Modelling Language (UEML) and precise semantics for its constructs. To achieve the latter, the need for a single definition of the constructs in terms of a common underlying domain theory has been identified already 5 years ago. We argue the case that category theory morphisms of object interactions is a strong candidate for an underlying domain theory within which:

• all generic enterprise modelling concepts and constructs can potentially be mapped so as to provide definition, unification and resolution mechanisms for semantics of modelling languages,
• fundamental properties such as genericity of modelling, architecture completeness and model correctness can be addressed using the objects of the theory.

Objects

We introduce objects themselves as categorical morphisms called "Observed Processes" and we extend this characterisation to interactions among them. As mentioned before, the generality of category theory can ensure that neither "useful real objects" nor "useful interactions" can be excluded from such a formalism.

We also define special cases of object morphisms such as the "partial observation morphism", responsible for abstractions from reality. In this way, we can give substance to the relationship of the "real world", i.e. physical objects, to models. We consider a (finite) set of primitive objects, which correspond to all the functions of the physical objects of the enterprise. To those we apply partial observation morphisms, in order to construct a new set of processable objects, which we term the enterprise objects. Interaction between them is represented as another set of object morphisms. The two sets together, enterprise objects and enterprise morphisms are what constitute the formal enterprise. To avoid notational excess we do not rename and continue with the use of the single term "enterprise".

Environments

Objects are usually seen as operating within a larger set or a larger object, frequently called an "environment". Here we also define a similar concept adapted to the requirements of modelling architectures, which is amenable to hierarchical control structures similar to the organisation structures of an enterprise (Business Process models).

The encoding morphism "translates" the commands of the environment into commands the process part of the object "understands", while the decoding one does the reverse. Should there be other behaviour morphisms with corresponding domains and encoding and decoding morphisms, a common environment for all of them can be set by suitably enlarging the original.

The idea of an environment depicts a selected subsets of behaviour, without reference to the internal workings of the embedded objects or morphisms (events and/or observations), a notion close to the common concept of a physical environment. Based on this, one can populate the modelling constructs by further decomposing Business Processes into Enterprise Activities and/or generalising those into the Business or the Activity Environment. Furthermore, object morphisms such as Enterprise Activities can be decomposed into simpler morphisms. This is the path followed by CIMOSA with the definition of the Functional Operation construct, or, for us, an elementary morphism.
 
 

General requirements for models and modelling languages and discrete production processes on the representation of objects, functions, processes and time are presented that could be used as guidelines for quality modelling. The following list represents the requirements for models and modelling languages:

An important aspect of introducing enterprise engineering technology is the clear definition of its goal and objectives. Only if the people in the enterprise understand and assosiate themselves with these goals and objectives will the implementation of new technologies bear the expected fruits. A very important aspect is the technology naming. The name has to carry the goals and objectives of the technology in a very explicit way. As an example enterprise modelling does not convey the information of its capabilities - the creation of an enterprise blueprint, but rather creates the impression of an artifical and abstract representation of the enterprise. May Enterprise Architecture be a more convincing name?

The paper is concerned with user involvement in company activities and the needs for sufficient training and clear presentation of company goals and objectives as they relate to the work of the new employee. Especially the introduction of new technology requires a detailed planning of the implementation process. Again the understanding of the overall goals and of the particular benefits for the people themselves has to be achieved. Graphical representation of thecontent of the new technology will be a powerfull tool to gain acceptance of the new technology. Also involving the technology provider will be helpful for increasing the understanding and acceptance.
 
 

Angel Ortiz Bas, M. Hawa, F.C. Lario, Universidad Politecnica de Valencia, Spain, aortiz@upvnet.upv.es

Methodologies are a main element to develop Enterprise Integration (EI) Projects. Although a lot of different methodologies exist in EI, some aspects are common of most of them, in this article we have identified it, but at the same time some additional characteristics has been added. Finally, an analysis of how current EI Methodologies (CIMOSA, PERA, GRAI-GIM, IE-GIP, GERAM) are supporting methodological aspects has been made. The article objective is to guide future research in this area to provide appropriate methodologies.
 
 

Enterprise modelling contributes to understand enterprise structure by providing an explicit description of enterprise processes. Among many key issues in an engineering project, formalisation appears to be a suitable technique to check the global consistency between all the various specifications a system is intended to cover. This paper deals with the use of UML semantics representation by means of stereotypes and OCL invariant formalisation to cope with a global consistency of the UEML definition.

UML provides extensibility mechanisms able to formalise enterprise modelling constructs. Constraints are also expressed and could be used, by engineering tools, to aid the modeller in ensuring the global consistency of its model. These rules are expressed in the generic view of the model. It exists tools that can interpret these rules using class instances values for particular models. In order to be able to verify them in partial model (for domain-based models), works are currently done to translate them into the B language, which allows properties proofs, based on non-refutable mathematical theories.
 
 

Abstract: This paper presents a report on work in progress of a Synthesis of (selected) State of the Art Enterprise Ontologies (SSAEO) – which aims to produce a Base Enterprise Ontology to be used as the foundation for the construction of an ‘industrial strength’ Core Enterprise Ontology (CEO). The synthesis is intended to harvest the insights from the selected ontologies, building upon their strengths and eliminating – as far as possible – their weaknesses. One of the main achievements of this work is the development of the notion of a person (entities that can acquire rights and obligations) enabling the integration of a number of lower level concepts. In addition, we have already been able to identify some of the common ‘mistakes’ in current enterprise ontologies – and propose solutions.

Even at this early stage our work has revealed the need for a substantial improvement in enterprise ontologies to bring them up to ‘industrial strength’. Hopefully, our work will go some way towards realising this.
 
 

The current situation in enterprise modelling is characterised by a large number of enterprise modelling languages and tools leading to heterogeneous and unintegrated models of the enterprise and by absence of communication among tools. This situation reveals the need for a UEML (Unified Enterprise Modelling Language) as a means to mediate between different Enterprise Modelling (EM) tools and models. The definition of a UEML should help, amongst other things, to obtain more expressive, more precise, more natural and more understandable integrated enterprise models and allow the reuse of existing EM tools and models.

In the paper, we investigate the relations between the UEML definition problem and data base integration problems. In some respects, the definition of a UEML can be considered as a database schema integration problem in which (i) the schemas to be integrated are the meta-models of the languages whose constructs are candidate to be included in UEML and (ii) the data are the models defined in these languages.

The paper reuses a general methodology for database integration (DBI) and shows its implications for defining a UEML. The DBI methodology consists in three major steps: preparation for integration (translating and reorganizing schemas to facilitate further steps), establishing and investigating correspondences (among schema elements and data) and defining the integrated schema (solving conflicts where necessary).

For each of these three steps, a parallel is made with the UEML definition problem. Lessons learned and practical solutions from the area of DBI are outlined. In particular, we stress (1) the importance of the correspondences at the data level (between examples of models) to infer correspondences at the schema level (between languages constructs) and (2) the importance of tracing the correpondences between the integrated schema and the original schemas (between the existing languages and a UEML). Where apporpriate, some elements of our research work on a multi-formalism approach for manufacturing systems modelling are presented. Additional methodological hints are given for the definition of a UEML.
 
 

PSA Peugeot Citroën is a French carmaker selling 3 billions of vehicle in the world, 2^nd in Europe and 6^th around worldwide. PSA can be considered as a real extended enterprise having many points of activity dispatched: head office, every selling and repairing points for Peugeot and Citroen, a dozen of automotive plants, and several thousands of suppliers all over the world. At time, we will just focus on the industrial part. It means that we will just take into account interactions between an automotive plant and its suppliers.

Few values are necessary to understand the dimension of our problem. One car needs approximately 1500 different components, selected among 4000 references. Around 350 suppliers are required to assume this task just for one kind of vehicle.

Nowadays we need a global vision of this logistic. And to obtain it, we have to model all the flows between the automotive plant and its suppliers.

Each relation between an automotive plant and a supplier is quite simple and well known. However, there are two different flows blended: data flow and component flow. These flows are linked by both supplier and plant processes. Moreover, we can either identify two different kinds of exchange: orders based on production consumption (Kanban), and orders based on production forecast.

So two difficulties arose:

• Our main difficulty is to deal with the numerous quantities of flows. Indeed, current modelling and simulation tools are not efficient enough to analyse such a big quantity of data.
• Another important difficulty comes from the fact that all flows are linked together by the car production. Indeed, each vehicle needs specific components to be built.

• Adjust flows with a global view, in order to reduce inventories.
• Understand how flows are linked.
• Anticipate impacts of a flow trouble, on the other ones.

The paper describes the methodology of enterprise modelling following the ISO/EN 19439 (GERAM) modelling framework but extends the upper two levels (Identification and Concepts) by two additionals levels (Define Process and Masters Plan). The methodology distinguishes macro level modelling (Identification of the business entity to Master Plan for going from AS-IS to TO-Be) and detail level (Requirements to Disposal).

The building blocks involved in the modelling process correspond to those defined in ENV 12204. Graphical symbols have been defined to represent those symbols including those for the control flow to the business user.

The paper concludes with a summary of the experince gained in industrial applications:

• Need for sufficient user training
• Definition of business processes has to be iterative in a top-down and bottom-up mode
• Graphical representation is required for both understanding the AS-IS model and to design the TO-BE model
• Need for a master plan for the development of the TO-BE model

Abstract: ENV 12204, Constructs for Modelling, contains specifications for abstractions to be used in computer-based modelling. It is now being reworked as a joint EN/IS by CEN TC310 WG1, with additional inputs from interested ISO TC184 SC5 WG1 experts. This revision will reflect practical experience in the use of ENV 12204, increase its rigour, (specifically in increased alignment and accuracy of the textual and more formal 'template' specifications), and extend and reinterpret constructs to include aspects of decision-making. UML has been applied in this process to generate a single consistent model, based on several inputs from CEN TC310 WG1 experts.

Selective presentations of this model can be generated semi-automatically to focus on say functional or organisational aspects, or to show all the relationships between a constructs and all those constructs, which are related to it. Future work - to be based on WG1 discussions - will include documenting construct attributes within the model and XML representation. The UML modelling exercise has greatly increased the consistency and coherence of the constructs, demonstrated the benefits of being able to generate multiple views on one underlying model, and shown the crucial importance of having computer support for the UNML modelling.
 
 

Enterprise architectures are needed to make the structure and the behaviour of the enterprise explicit and to identify stakeholder needs and expectations. On the other hand systems engineering provides the techniques to create well engineered enterprise architectures and uses modelling for analysis, improvements and validation of proposed solutions as well as facilitating integration of interfacing enterprise systems.

An enterprise architecture/system engineering /EA/SE framework is introduced that adresses abstraction (like GERA and Zachman) through a set of supporting layers and interrogatives (like Zachman) as behaviour, structure and motivation or purpose. Relations between the framework and enterprise modelling are identified.
 
 

Enterprise modelling provides the means to structure and decompose the enterprise system into less complex parts and to describe functionality and behaviour of the operation or any part thereof. Process models support various requirements of enterprise inter- and intra-organizational engineering and integration.

Representing the reality of a virtual enterprise through the construction of an enterprise process model can be a very complex task. It requires to capture all the needed and produced information, many classes of objects with even many more interactions among them with the ultimate goal of providing an efficient operation support . To create an environment of the operations in e-business to business and virtual enterprises very many entities in various states need to be considered..

A methodical approach has to be followed to enable users to employ modelling constructs relevant for the representation of their business. Constructs that provide means for easy information capturing through simply designed templates and presented with easy to understand graphical symbols or icons. Both, common modelling construct and their representation by icons will make the modelling process more effective and efficient and also improve the human understanding as well as the overall use of enterprise models leading to a wider application of operational decision support.

The paper proposes and discusses generic types and type hierarchies for user oriented enterprise modelling constructs and its benefits. Further, an illustrative example of applying construct types with the modelling tool FirstSTEP Designer and an overview of construct icons for graphical representation used in different modelling tools is presented. Reference to standardisation in ISO 15704 and ENV 12204 and to the CIMOSA Architecture is made.
 

Return to Workshop Overview