In the subject of information systems modelling languages have proven to be an effective mean to design business processes of enterprises and their information systems as well. These modelling languages are specified by metamodels. The choice of elements that are specified by the meta-model, which hence are part of the modelling language, is driven by the modelling languages' field of application. Areas of special interest for process modelling are inter-organisational collaboration scenarios. In this field, new requirements for business process models arise with the need to visualize new aspects of business processes. The review of existing modelling concepts is necessary to achieve an effective and efficient inter-organisational business process management. This paper motivates new requirements for collaborative business process models and presents a metamodel based extension Event-driven Process Chain (EPC), which can be considered as standard language for Business Process Management.
During the last decades, a wide set of different information systems modelling languages has been applied for the design of enterprise processes and their supporting information systems. Modelling languages as, for instance the Petri-Net [Gr01], the Business Process Modeling Notation (BPMN) [Wh04], the Event-driven Process Chain (EPC) [KNS92], or language sets as the Unified Modeling Language (UML) [Oe03] ease the mapping of complex enterprise structures (data, processes, products and services, etc.) and behaviours (e.g. process flows, process costs) to a model-based image of the concerned reality. These modelling languages are usually specified by meta-models, e.g. the UML 2.0 is specified by use of the MOF [OMG05].
Due to changing fields of application a need for modelling language adjustment may arise because of an either less generic orientation or a too specific bias. Collaborative Business (C-Business) [SGZ03] [RS01] as a research field with the investigation of the emerging enterprise integration paradigm in collaboration scenarios has such influences on existing modelling languages and techniques: With a growing number of collaborations and the combination of core competencies for a collaborative service or good production enterprises have to react concerning their design of enterprise business processes and their computer-assisted support on an inter-organisational level. The kind of and the quality of Business Process Management (BPM) activities, are depending on the modelling languages, techniques and tools which are applied to create an effective and efficient way to conduct C-Business. Hence, the influences of C-Business concerning the inter-organisational Business Process Management have to be analysed, which leads to the definition of requirements for the underlying methods and tools. Thus, a state-of-the art reflection of process characteristics is provided in section 2. These characteristics have to be considered in modelling concepts and tools. For this purpose, we first evaluate the expressiveness of the Event-driven Process Chain (EPC) in collaborative scenarios, as one representative state-of-the art modelling language. To fill the gap between actual modelling concepts and to-be state we derive design recommendations for inter-organisational process modelling languages and apply them to the EPC. Therefore in section 4 a meta-model based extension of the EPC is presented.
As the most characterising part of C-Business, the processes among two or more enterprise departments, branches, but also business partners are integrated [Sc01a]. However, only sub-processes have been supported by BPM in the past. The single subprocesses of the collaborating enterprises must be integrated on different layers. The special process characteristics – the difference between usual, intra- and the new interorganisational business processes – are mainly based on two pillars or field of interests as it is described in the following: first “cross-organisational business process flow” as a well-tangible, abstract object that describes static and dynamic process elements and characteristics and second “security and trust” as a fuzzy necessity for C-Business design, implementation and controlling.
Both classes of characteristics – coexisting interdependently and complementarily – are explained in the following. The subsequent derivation of requirements towards process modelling is described in section 2.2.
A business process includes different flows as a continuous, directed flow of data or information, goods and services or currency between process objects as well as the determination of the underlying processing logic. These flows remain inside an enterprise, e.g. as a data flow between departments (e.g. internal transfer of bills). However, they also cross enterprise borders and address external stakeholders as, for instance, it is with material goods- or immaterial service-flow (e.g. transport of goods from a supplier via forwarding agent up to the manufacturer of the final product) [Hi98], [Th01], [Le03a]. A complex mesh of connections among the flows of individual, distributed process steps characterises those inter-organisational flows. From the view of one enterprise, internal process steps are initiated with well defined interfaces by external process events. Hence, we will have a closer look at these process interfaces implying flowing objects between different sending and receiving process participants. This decentralisation leads to high coordination efforts of cross-enterprise business processes. The circumstance results in an increasing number of organisational and ITrelated (process) interfaces [Sc01a]. Interfaces interlink activity-executing process objects such as application systems or databases, but also employees via data exchange as an information or control flow. Such interfaces may be identified both internally (intra-organisationally), within enterprises (e.g. between departments, branches, internal systems), and externally (inter-organisationally), between one enterprise and its business partners, customers, suppliers etc. [Sc03]. Such process interfaces cause friction losses. They result from, for example, long wait times caused by redundant work, high coordination efforts and competence splits [Th01]. In the following, we focus on external interfaces. They are divided into two main interface classes: process interfaces on a human layer and on a technical, machine-oriented layer.
Considering human beings as those actors who execute entrepreneurial activities manually we chose the term “organizational interface” for enterprise-spanning business processes that are characterised by interfaces concerning the organisational units involved in the process execution [Hi98]. The existence of organisational interfaces has numerous impacts on the way of process execution and on the involved organisational control instances. From an organisational point of view, explicit responsibilities concerning “power structures” and explicit “control instances” have to be defined in enterprise-spanning business processes. They ensure a smooth process flow even across the borders of a single enterprise [Sc02a]. However, this turns out to be particularly complicated in cross-enterprise processes as these responsibilities are mostly nonexistent or even unintentional due to the kind of cooperation. A lack of organisational regulations leads to increasing coordination efforts concerning the execution of a process [Hi98].
Regarding mechanical actors information technology (IT) interfaces are identified. Cross-enterprise integration and optimisation of business processes mostly aims at a minimisation of interruptions in process flows caused by information and communication technology [Wö03]. In a cooperation scenario, the compatibility of application or information systems is required for a smooth cross-enterprise data and information exchange [Hi98]. The benefits concerning an increase in efficiency and effectiveness is only achieved with a vast implementation of processes over different application systems [Wö03]. Thus, the technical layer of process execution considering IT interfaces as relevant process interfaces are described in the following more detailed. Heterogeneous IT landscapes may be identified as one central problem area causing ineffective and inefficient process hurdles. Predefined standards concerning existing IT interfaces have to ensure that IT systems used in the respective enterprises can be integrated [Sc02a]. As various application systems of different manufacturers are mostly used in the different enterprises for heterogeneous purposes, the complexity of the process integration increases as a result of the heterogeneity of the IT landscapes. However, to reach business objectives, systems have to be interlinked through suitable mechanisms. Integration of heterogeneous application systems is mainly addressed within the field of Enterprise Application Integration (EAI) [Li00], however on a rather technical layer.
The number of existing format mismatches, which describes the frequency of changed communication media for the transmission of relevant information, may be seen as one resulting problem of IT heterogeneity. The manual transfer of information contained from a fax document (an order for instance) to an online form of an ERP system may serve as an example. In the context of inter-organisational business process controlling, the number of format mismatches can be used as a value for the analysis of the whole process [Bu03a].
The use of different standards may be identified as another relevant technical aspect within inter-organisational business processes. The integration of IT systems requires standardised methods for the connection of different communication end points and IT interfaces respectively. With heterogeneity of interfaces the integration effort increases [Wö03]. Inefficiencies concerning the electronic exchange of data and information can be eliminated by the definition of central semantic and syntactic standards for exchange objects (for example business documents) as well as transfer methods (transmission medium, exchange protocols etc.) [Mü03]. The complexity of a holistic process integration, caused by the multiplicity of potential business partners and IT systems to be integrated, is intensified by the existence of numerous, specific and partly very differently, sophisticated standardization approaches [Wö03]. This has a negative impact on the effort for process integration requiring adequate complexity reducing measures. Moreover, the automation of process steps is also addressed with the help of IT as a primary objective in a cross-enterprise context. Here, a reduction of format mismatches is intended. With regard to process efficiency and effectiveness, improvements concerning process performance can be realized by the removal of manual process executions [Sc02a]. Furthermore, by defining automation as a value characteristic with Key-Performance-Indicators [SJ02], inter-organisational processes can be analysed in a measurable way [Bu03a].
As a core part of business processes the exchange of information between employees is often problematic. Employees receive information willingly but they only reveal certain data under special circumstances [Wö03]. This aspect is even worse at the level of collaboration and inter-organisational business processes. The exchange of information is much more complicated due to cultural and mental aspects. Collaborations are characterized by insecurities during many phases of the collaboration life-cycle [We01]. With the use of the internet as the central medium for information exchange and transfer, the network economy turns out to be more impersonal and insecure in practice. The electronic exchange of information is a weak point for every attack due to the described character of the medium internet. A disturbance of inter-organisational partner relationships may result. Thus, security and trust can be regarded as particularly critical for the inter-organisational process integration. Trust has to be regarded as an essential basis for an effective and efficient information exchange. It enables the communication between business partners. The described aspects have to be regarded as key success factors for the realisation of collaborative scenarios [Ra03].
Concerning the design of cross-enterprise processes, enterprises rely on negotiations for the coordination and the discussion or avoidance of potential partner conflicts. As the communication among the partners plays a major role in this context, cultural and social discrepancies have to be taken into account as well [Hi98]. Thereby, organisations are characterized considerably by cultural imprints because of organisational behaviour patterns and values [Sc97]. Within international cooperations, the problem to find common agreements due to cultural (e.g. language, terminology and understanding barriers, mental imprinting, legal distinctions) and temporal barriers (transcend time zones) by cooperating with acceptable coordination efforts is even aggravated [Wö03].
Based upon the characteristics of section 2.1, requirements towards the modelling of business processes are defined in the following section to derive the language extensions presented in section 3 and 4.
From the main characteristic “process interface” which can be seen as a substitute for the necessity of process coordination the need for an explicit and purpose-driven description is derived. From a conceptual point of view, an adequate graphical visualisation is required. Furthermore, inter-organisational flows between human and mechanical process actors ought to be differentiated according to the kind of flow (see previous section). For a complete, cross-enterprise coordination additional information in the form of attributes may be necessary in a model as, e.g. pre- and post-conditions which limit the scope of interactions between the enterprise borders. Such attributes provide an execution-driven view on the necessary data for cross-enterprise business processes on a conceptual and even technical layer. Business processes may be coordinated with the aid of documentation models, but IT as for instance workflow engines or Enterprise Resource Planning (ERP) Systems might be also customized reverting to business process model information.
Moreover, the underlying interaction points with multiple end points [Bu03b] have to be specified by addressing the human layer with collaborating employees and departments on the one hand and the technical layer with IT on the other hand: x
Considering organisational units the area of authority has to be communicated to collaboration partners in order to ease the coordination of business processes. Without explicit responsibilities, business process objectives may be neglected, business process owners ought to be defined [Fr01] not only for small sub-processes but also on a cross-enterprise level. Detailed contact data ease the process execution through the minimisation of coordination efforts. Transparency towards organisational structures with authority and communication relationships ought to be created.
To derive appropriate and relevant information for the design of integrated but heterogeneous IT landscapes business process models have to be extended considering IT-related data. The crucial information which system covers which part of a sub-process has to be specified explicitly similarly to the description of organisational responsibilities. Moreover, interfaces ought to be described more in detail with special attributes marking heterogeneous systems (for instance syntactical description of exchange formats as e.g. individual XML structures, supported standards etc.) [Le03b] or necessary associations to related detail descriptions as sequence specification with UML sequence diagrams [Je04].
The modelling and the exchange of inter-organisational process model aiming at partner coordination have to be applied with reasonable efforts. Existing knowledge which is cast in models should be reused in order to save former investments [VZS05] of, e.g. Business Process Reengineering (BPR) - or Software Engineering (SE)-tasks. [Va05] Furthermore, a global sharing of information in the form of process models requires model integration and security mechanisms. Any flexible exchange of process data with heterogeneous description formats needs support in C-Business. Process data have to be secured and mechanism to hide critical information in models towards business partners need to be developed. [VZS05] Finally adaptation mechanisms for the translation of process models between different languages should be provided helping to overcome language-driven hurdles.
Summarizing, every possible weak point which may derange inter-organisational business process flows ought to be analysed in the design phase of the process, monitored during its implementation and controlled during the execution of enterprisespanning business processes.
After this rather general requirements definition, precise description mechanisms are developed in the following sections considering the EPC as state-of-the art modelling language for BPM. In order to fulfil the requirements the extension of EPC becomes necessary. In the following chapter we hence introduce the EPC accomplishing the development of extensions due to the requirements as a practical example for the extension of modelling languages for inter-organisational process modelling. As languages are defined by their meta-models an extension of the EPC meta-model becomes necessary in order to allow the adequate representation of the interorganisational process by the use of EPCs. Thus, beside the introduction towards EPC modelling the authors’ definition of meta-modelling and then the meta-model of EPC is presented.
The Event-driven Process Chain (EPC) was developed in 1992 at the Institute for Information Systems in Saarbruecken in cooperation with SAP AG [KNS92]. EPCmodels are central elements of BPM last but not least because of its use in the SAP R/3 reference model of SAP AG and the ARIS Toolset of IDS Scheer AG [Sc02b]. Enterprises model their process data as EPC-models in order to plan, design, simulate and control private enterprise processes. The EPC is a core part of the ARIS-framework and combines the different views towards the description of enterprises and information systems in the control view on the conceptual level. Few examples of EPC fragments, introducing the graphical EPC-visualisation, are given in section 4. The model elements of the EPC are introduced by the EPC’s meta-model, which is presented in the following paragraph.
The term meta-model has its origin in the language levels of constructivism. This theory divides languages into languages on object-level and on meta-level [LS75]. The object language is the language, which is used to describe the objects of discourse. The meta language is the language, which describes the discourse itself. Transferred to modelling languages (cf. figure 1) a language oriented meta-model is model M2 which describes a language S1 that is used to create a model M1 of an object [Ho01]. STRAHINGER [St96] and HOLTEN [Ho00] divide a language into an ortho-language and a notation. The ortholanguage describes all elements of modelling language unambiguous and without circles. The notation defines a graphical representation for each model element. One language can have multiple notations. Due to this definition the meta-model of a language and the notation has to be extended in order to create any adjustment.
Level 1 Language-orientierted
Meta-model of Level 0
Level -1
M2
Model of M1 represented in language
Model of Object represented by model M1
L1 Fig. 1: Language-oriented Meta-Model [Ho01] The EPC describes processes by the use of alternating functions and events as timereferring state changes Events und functions are linked by the control flow as directional edges [Ke00]. Functions describe activities and events passive states. Concerning the control flow functions and events can only be connected to each other. To split and join the control flow operator with the occurrences OR, XOR, and AND can be used after functions and events, except the OR- and XOR-Operators must not be used after events. The last remaining element, that could be connected via the control flow are process interfaces, which can be applied at the end and the beginning of an EPC to connect two EPCs from different models.
In the EPC meta-model (cf. fig. 2), which is constructed as an Entity-RelationshipModel (ERM) [Ch76], these four model elements are generalised as “process element”. The connection between these four model elements are represented by the “PredecessorSuccessor-Relationship”. A problem of the generalisation to the “process element” and its recursive relationship are multiplicities of this relationship which should define which connections of these model elements are permitted. This problem can be solved by determining the multiplicities for each combination of predecessor and successor, e.g. if a function is followed by an event the multiplicities of the predecessor are (0,1) and the multiplicities of the successor are (0,1), too. The multiplicities of all possible cases are shown in Table 1.
Relation Type
(0,1) Ressource structure The next important meta-model element is the „process“. Every process element is part of exactly one process and each process consists of one or more process elements. The construct “process” can be used to create hierarchies of process models. Therefore a function is detailed by a sub-process. This refining of functions with sub-processes can be done over an unlimited number of levels. This issue is represented in the meta-model by the relation “process affiliation” between a function and a process, which allows, that one process can refine no or many functions. A function can either be not refined or be refined by exactly one process, because if a function was refined by more than one process the execution of the function would be ambiguous. The unlimited hierarchy levels of function affiliations are possible, because of the generalisation of the function to process element which is part of a process. So every sub-process consists of process elements, which could be function, that are refined by another sub process. The last important characteristic of the modelling language EPC are resources, which can be annotated to functions. A resource1 like, e.g. organisational units, applications systems or documents has its resource specific type relation to a function. For instance, an organisational unit can have the type of relation “is responsible for”, which is not allowed for a document. So the meta-model contains a relationship between the type of relation and the resource, which determines which type of relation to a function is possible for what resource. As one resource can have more than one type of relation and one type of relation can be suitable for more than one resource, the relationship between a resource and a function is specified by a combination of the resource and its type of relation. Therefore, in the ER-Meta-Model the relationship “ToR-Ressource-Rel.” is redefined to an entity type and creates a triple relationship with the entity type “function” and the entity type “resource”. So the exact type of the relation for each connection of a resource to a function is specified. Additional resources can be related to each other, e.g. one organizational unit can have the relationship of the type “reports to” to another organisational unit. This is taken into account by the relationship “Resource Structure”, which also includes the “type of relation”.
To derive the need for the development of extensions, the modelling language is analysed due to the requirements defined in previous sections.
The level of complexity escalates when trying to couple processes with each another in the development of a collaborative process model, as each network participant has their own “private” set of established methods (e.g. EPC, Petri-Net, UML Activity Diagram, BPMN) and tools (e.g. ARIS Toolset, VISIO, Rational Rose, eMagim, Metis) in use. Due to a lack of common interfaces and mapping-methods, neither can the tools interact with each other nor can the methods be transformed into one another.
The introduced EPC enables process modelling considering all relevant aspects for the description of business processes within the enterprise borders. Due to its connection to the ARIS framework, especially the ARIS House by SCHEER [Sc02c], an EPC model integrates the different views or perspectives on entrepreneurial entities. It builds up the dynamic connection with entity-relationships in the so called ‘control view’. With the eEPC further elements such as process participants or data and information systems have been introduced. However, a clear focus on inter-organisational aspects does not yet exist.
Hence, we compare the capabilities of EPC modelling with the requirements described in section 2.2. This will be based upon the characteristics of processes in section 2.1. The eEPC, which was introduced above by its meta-model, enables holistic modelling of business processes considering control flows, organisational aspects, data entities as well 1 There is no common understanding, which resources can be annotated to function in the EPC. An impression of the variety of resources gives the ARIS-Toolset of the IDS Scheer AG, which provides in its current release (6.2.3) 115 resource occurrences. Therefore, not all resources are regarded in detail in this paper. as services and goods with every possible relationship in between. However, the eEPC does not differentiate the various kinds of process flows as connections between collaborating enterprises in a cross-organisational business process. An explicit visualisation of enterprise-spanning message triggers as it is introduced in the Business Process Modelling Notation (BPMN) with the so-called “Message Flow” is not envisaged. With this lack of information, EPC models loose expressiveness in the case of coordination. The explicit design or marking of the – for the execution of crossorganisational process responsible – process actors (human vs. machine) is not part of the eEPC. Enterprise-spanning interaction points are only included implicitly. Moreover, information which may become important for the coordination of process actors, are not part of the EPC modelling. Concerning human actors as the organisational units of an enterprise-network process-owners with their responsibilities are not explicit part of EPC processes. The scope of responsibilities is not shown in an EPC and may only be derived from the information which units act at a certain function. Coordination over the borders of an enterprise may become difficult because of such missing information in the business process models. Finally, even trivial attributes as contact data might be missing. This information is not required by the modelling language by default but might be implemented as a kind of model attribute in modelling tools. Aside from the human execution of process parts the technical dimensions should be specified in order to enable recognition of e.g. compatibility problems due to the need for heterogeneous application integration already at an early conceptual description level. Hence, the different kind of application systems must be visualized in an EPC with the crucial information of cross-organisational communication dependencies. While application systems themselves are already part of eEPCs, interaction points with a detailed description of data formats and flow descriptions (messages) are not contained. Hence, this should be introduced with, possibly, providing detailed data exchange information in an additional model as, e.g. UML sequence diagrams.
The mentioned requirements should be fulfilled by the modelling language itself in order to enable the application of the language in a special application domain. The simple addition of e.g. attributes depending on the use of a modelling tool complicates the modelling and integration of cross-organisational business process (parts) as few characteristics in modelling may differ due to the heterogeneity of tools.
In the following section, extensions for the inter-organisational modelling of business processes are introduced. The propositions are based upon the requirements of section 2. They demonstrate a possible occurrence of the extensions considering the EPC. Starting with the need for process interface visualisation we first want to create the ability to enable an identification of cross-enterprise process actors. Ordinary EPC models do not differentiate organisational units due to their affiliation to collaborating enterprises. Thereby, semantic faults as they might be caused through the use of homonyms and synonyms [RZ96], have to be avoided. Otherwise, misunderstandings as depict in Fig. 3 are possible. Affiliation should be described clearly expressing which enterprise and which organisational unit or application system resp. process actor belongs together in an inter-organisational business process. As shown in Fig. 4 organisational groups depicting parts of a cross-organisational business process with the same affiliation are introduced. These groups might be completed with additional information due to the special modelling objective as, e.g. coordination of human process actors. In this case, adding contact partners as process owners to the organisational groups ease process coordination through the transparency of execution responsibilities.
In order to introduce the concepts of organisational groups to the EPC, a new model element “organisational group” has been added to the meta-model. As organisational groups consist of at least one process element, a relationship between the new metamodel element “organisational group” and the process element becomes necessary. The multiplicities of this relationship are (0,n) for the process element, because it must not belong to an organisational group, and (1,n) for the organizational group. To accommodate the idea that there is one contact person for each organisational group, from the meta-model element “organisational group” a relationship to the meta-model element “organisation unit”, which is a specialisation of the resource, is added. The grouping-approach aiming for an increase in transparency has already been introduced in former times with the column-concept of process chain diagrams [Sc94], or the pool and lane approach of, e.g. UML Activity Diagrams [Oe03] or the Business Process Modeling Notation [OR04], [Wh04]. Organisational interfaces are identified easier. As a graphical occurrence small boxes enclosing relevant process parts might be the suitable notation for organisational groups. Similar to the grouping of organisational entities, interacting information systems could be marked within so called “application integration points”. Such interaction groups visualize process actors from a rather technical point of view. In an EPC, the group may be illustrated with a rectangle including all necessary interaction entities (application systems, interacting process steps, data exchange).
This interaction between process actors is realised via resources that are exchanged, e.g. documents or data objects. To introduce a model element in the EPC as described above in the meta-model, the relationship, which connects resources to functions, is redefined to an entity type and a recursive relationship with this redefined entity type is added. So it is possible in an EPC-model to create a new arch from one function of the first interacting process to the resource, that is used to interact, and from this resource to a function of the second interacting process, which directly indicates which functions interacts by the exchange of which resource. send invoice application
A invoice Aside from the rather less specified characterisation of application integration points, the exact description of system interfaces should be inserted to the EPC model due to the requirement of heterogeneous application integration coordination. Thus, detailed parameters as the syntax and semantic of EPC data clusters or conditions towards the execution of cross-organisational application interaction points (e.g. timer conditions, rules/constraints) might be shown in a detailed subgroup “interface description” of the interaction groups (cf. Fig. 6). The interface between two processes is an interface between two functions, because resources, like application systems or documents that link processes to each other can only be added to functions. So the interaction of processes is always realised by an interaction of functions. Therefore, the concept of “interface description” is integrated in the EPC as a recursive relationship of the meta-model element “function” with itself. But this relationship would only allow expressing that two functions are interacting, but not how they are interacting. So the relationship “interface description” is redefined to an entity type, which has two relationships. The first relationship is connected to the new model element “sequence diagram”, which is a link to another model. The second relationship consists of the “interface description” and the “description object”. The description object is only a model element on meta-model level and not supposed to be used in an EPC-Model, it is just a generalization for such model elements as “Timer”, “rule/constraint” and “document/message”. These three model elements represent the concept which has been described before.
Finally, security questions has been mentioned as an important issue restricting the scope of the modelling task and its result as a process model. To enable an exchange of process data using EPCs, information might be hidden as so called “process modules” [Ho05] [KKS04], which hide critical private process data. Only the information is shown in a process model which does not lead to economic disadvantages for single enterprises throughout the exchange of business process models. The rest is hidden behind substitute objects using abstraction mechanisms and reduction or extension. The kind of knowledge could be classified as private, public partner and global partner information. [VZS05], [Fr04]. The information towards view differentiation in EPC modelling has already been discussed in [LGB05], [Ad04].
Private enterprise A hidden process enterprise A
billing department Visibility: • - private • + partner • # global process module In order to introduce this visibility approach to the EPC the grouping of model elements becomes necessary. Particularly as one process element could belong to more than one group, the new model element “process module” is added to the meta-model. It has a relationship “belongs to” with the meta-model element “process element”. Additionally, the “process element” has got a relationship to the meta-model element “visibility”, which has the occurrences “private”, “partner” and “global” according to the introduced differentiation. However, to specify the visibility for each “process module” is not enough, because if e.g. a private process module is visible depends on a particular perspective. So, for its owner a model element could be visible but for external partners, e.g., it wouldn’t. For this reason an attribute owner is added to the “process element”, which indicates the perspective towards visibility definition. (0,n) sucessing (1,1)
Process module affiliation
(1,n) (1,1) Is visible in
(0,n)
Visibility outgoing (0,n) (0,n) receiving
Process
link ... (0,1)
Link to
D,T Process interface
Process module Process affiliation (0,n) Fig. 8: Extended Meta-Model of the eEPC
Information system
Organizational (0,n) unit
To be contacted Organizational group (1,n) (1,1)
Owner
predecessing Belongs to (0,n) Process element
In the paper, we gave an overview of challenges for the modelling of business processes as a core part of Business Process Management. From the influences of a new application domain we derived requirements towards the scope of modelling and the modelling task itself. Moreover, a possible approach to fill the gap between as-is and tobe modelling with established modelling languages considering inter-organisational business processes has been presented. To demonstrate the requirements and their fulfilment an occurrence of the extensions for inter-organisational process modelling was derived for Event-driven Process Chains as a state-of-the art business process modelling language. Thereby, we identified problems in the cross-organisational EPC application and we proposed extensions for the EPC modelling.
The extensions for the language have been developed by the use of meta-models. Considering the method of meta-modelling to extend existing modelling languages, the presented meta-models have shown that ERM can appropriately be used to create metamodels and to extend languages. However, the expressiveness of an ERM is limited, concerning multiplicities in complex relationships. So in the field of meta-modelling, the development of a more expressive meta-modelling language is one of the future tasks. However, few aspects considering inter-organisational modelling have not been solved: Social and cultural discrepancies as e.g. language barriers have to be addressed by flanking methods. Moreover, security- and trust-establishing actions need additional attention, so tool-based methods to hide process knowledge in defined collaboration scenarios according to an existing degree of partner confidence are a core part of future research. Finally, the presented extensions are going to be evaluated striving for a continuous improvement and a tool-based support.
The approaches – presented in the paper – have been developed at the Institute for Information Systems (IWi) at the German Research Center for Artificial Intelligence. The need for an appropriate inter-organisational business process modelling support is being addressed within the research project “ArKoS – Architecture for Collaborative Scenarios”2. Meta-modelling as a method to develop and to extent modelling languages is discussed within the research project “RefMod06 – Reference Modelling of conceptual Software Models for SMSE”3. Both projects are funded by the German Federal Ministry of Education and Research (BMBF). 2 Further project information is available at http://www.arkos.info. 3 Further project information is available at http://www.refmod06.de XML4BPM 2005, Proceedings of the 2nd GI Workshop XML4BPM -- XML for Business Process Management at 11th Conference Business, Technologie, and Web (BTW 2005) in Karlsruhe (Germany), 01 March 2005. Karlsruhe, 2005, pp. 7-21. [Li00] Linthicum, D. S.: Enterprise application integration. 3. eds. Addison-Wesley, Boston et al, 2000. [LS75] Lorenzen, P.; Schwemmer, O.: Konstruktive Logik, Ethik und
Wissenschaftstheorie. 2. eds. Mannheim, 1975. [Mü03] Müller-Lankenau, C.: Interessengemeinschaft Datenverbund für die Haustechnik IGH. In: Schubert, P.; Wölfle, R.; Dettling, W. (Eds.): E-Business Integration : Fallstudien zur Optimierung elektronischer Geschäftsprozesse. Hanser, München et al., 2003, pp. 123-136, p. 128. [Oe03] Oestereich, B. et al.: Objektorientierte Geschäftsprozessmodellierung mit der UML.
dpunkt, Heidelberg, 2003, pp.175-178. [OMG05]Object Management Group: Meta-Object Facility, Version 1.4. URL http://www.omg.org/cgi-bin/apps/doc?formal/02-04-03.pdf [29.11.2005]. [OR04] Owen, M.; Raj, J.: BPMN and Business Process Management : Introduction to the New Business Process Modeling Standard. URL http://www.bpmi.org/bpmilibrary/6AD5D16960.BPMN_and_BPM.pdf. [Ra03] Ratnasingam, P.: Inter-Organizational Trust for Business-to-Business E-commerce.
IBM Press, Hershey et al., 2003, pp. 2-4, p. 3. [RS01] Röhricht, J.; Schlögel, C.: cBusiness : Erfolgreiche Internetstrategien durch collaborative business am Beispiel mySAP.com. Addison-Wesley, München et al., 2001, p.19. [RZ96] Rosemann, M.; zur Mühlen, M.: Der Lösungsbeitrag von Metamodellen beim Vergleich von Workflowmanagementsystemen. In: Becker, J. et al. (Eds.): Arbeitsberichte des Instituts für Wirtschaftsinformatik, No. 48, Universität Münster, Münster, 1996, p. 10. [Sc01a] Schmitt, R.: Unternehmensübergreifender Engineering Workflow : Verteilte Produktentwicklung auf der Grundlage eines parameterbasierten Daten- und Prozeßmanagements. Papierflieger, Clausthal-Zellerfeld, 2001, p. 37. [Sc02a] Scheer, A.-W. et al.: Geschäftsprozessmanagement - The 2nd wave. In: IM Information Management & Consulting 17 (2002), Sonderausgabe, pp. 9-15, p. 11, p. 12. [Sc02b] Scheer, A.-W.: ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung.
In: Scheer, A.-W.; Jost, W. (Eds.): ARIS in der Praxis : Gestaltung, Implementierung und Optimierung von Geschäftsprozessen. Springer, Berlin et al., 2002. [Sc02c] Scheer, A.-W.: ARIS - vom Geschäftsprozeß zum Anwendungssystem. 4. Eds.,
Springer, Berlin et al., 2002. [Sc03] Schubert, P.: E-Business Integration. In: Schubert, P.; Wölfle, R.; Dettling, W. (Eds.): E-Business Integration : Fallstudien zur Optimierung elektronischer Geschäftsprozesse.
Hanser, München et al., 2003, pp. 1-22, p. 5, p. 7. [Sc94] Scheer, A.-W.: Business Process Engineering : Reference Models for Industrial
Enterprises. 2. Eds. Springer, Berlin et al., 1994, p. 17. [Sc97] Scholz, C.: Strategische Organisation : Prinzipien zur Vitalisierung und
Virtualisierung. Moderne Industrie , Landsberg/Lech, 1997, pp. 225-229. [SGZ03] Scheer, A.-W.; Grieble, O.; Zang, S.: Collaborative Business Management. In: Kersten, W. (Ed.): E-Collaboration : Prozessoptimierung in der Wertschöpfungskette. Dt. Univ.-Verl., Wiesbaden, 2003, pp. 29-57, p. 42; [SJ02] Scheer, A.-W.; Jost, W.: Geschäftsprozessmanagement : Kernaufgabe einer jeden Unternehmensorganisation. In: Scheer, A.-W.; Jost, W. (Eds.): ARIS in der Praxis : Gestaltung, Implementierung und Optimierung von Geschäftsprozessen. Springer, Berlin et al., 2002, pp. 33-44, p 43. [St96] Strahinger, S.: Metamodellierung als Instrument des Methodenvergleichs : Eine
Evaluierung am Beispiel objetktorientierter Analysemethoden. Shaker, Aachen, 1996. [Th01] Thaler, K.: Supply Chain Management : Prozessoptimierung in der logistischen
Kette. 3. eds. Fortis Verlag, Köln et al., 2001, pp. 43-44, p. 46, p. 49, p.76, p. 95, p. 117. [Va05] Vanderhaeghen, D. et al.: XML-based Transformation of Business Process Models Enabler for Collaborative Business Process Management. In: Nüttgens, M.; Mendling, J. (Eds.): XML4BPM 2005, Proceedings of the 2nd GI Workshop XML4BPM -- XML for Business Process Management at 11th Conference Business, Technologie, and Web (BTW 2005) in Karlsruhe (Germany), 01 March 2005. Karlsruhe, 2005, pp. 81-94. [VZS05] Vanderhaeghen, D.; Zang, S.; Scheer, A.-W.: Interorganisationales Geschäftsprozessmanagement durch Modelltransformation. In: Scheer, A.-W. (Eds.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, No. 182, Universität des Saarlandes, Saarbrücken, 2005, pp. 6-7. [We01] Wehner, J.: Projektnetzwerke - Neue Unternehmensstrukturen und neue Qualifizierungen. In: Rohde, M.; Rittenbruch, W.; Wulf, V. (Eds.): Auf dem Weg zur virtuellen Organisation : Fallstudien, Problembeschreibungen, Lösungskonzepte.
Physica-Verlag, Heidelberg, 2001, pp. 33-54, p. 41. [Wh04] White, S. A.: Business Process Modeling Notation (BPMN). URL http://www.bpmi.org/bpmi-downloads/BPMN-V1.0.pdf. [Wö03] Wölfle, R.: Stellenwert von E-Business-Integrationsprojekten in Unternehmen. In: Schubert, P.; Wölfle, R.; Dettling, W. (Eds.): E-Business Integration : Fallstudien zur Optimierung elektronischer Geschäftsprozesse. Hanser, München et al., 2003, pp. 23-38, p. 29, p. 27, p. 34, p. 37.