ARIS Method Manual

ARIS
METHOD MANUAL
VERSION 10.0 - SERVICE RELEASE 18

MAY 2022
This document applies to ARIS Version 10.0 and to all subsequent releases.
Specifications contained herein are subject to change and these changes will be reported in
subsequent release notes or new editions.
Copyright © 2010 - 2022 Software AG, Darmstadt, Germany and/or Software AG USA Inc.,
Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
The name Software AG and all Software AG product names are either trademarks or
registered trademarks of Software AG and/or Software AG USA Inc. and/or its subsidiaries
and/or its affiliates and/or their licensors. Other company and product names mentioned
herein may be trademarks of their respective owners.
Detailed information on trademarks and patents owned by Software AG and/or its
subsidiaries is located at https://softwareag.com/licenses.
Use of this software is subject to adherence to Software AG's licensing conditions and terms.
These terms are part of the product documentation, located at
https://softwareag.com/licenses and/or in the root installation directory of the licensed
product(s).
This software may include portions of third-party products. For third-party copyright notices,
license terms, additional rights or restrictions, please refer to "License Texts, Copyright
Notices and Disclaimers of Third Party Products". For certain specific third-party license
restrictions, please refer to section E of the Legal Notices available under "License Terms and
Conditions for Use of Software AG Products / Copyright and Trademark Notices of Software
AG Products". These documents are part of the product documentation, located at
https://softwareag.com/licenses and/or in the root installation directory of the licensed
product(s).
METHOD MANUAL
Contents
Contents ........................................................................................................................................................... I
1 Introduction ............................................................................................................................................. 1
2 Architecture of Integrated Information Systems (ARIS) .............................................................. 3

2.1 ARIS architecture concept ..................................................................................................... 3
2.2 Descriptive views ...................................................................................................................... 3
2.3 Descriptive levels ...................................................................................................................... 7
3 Modeling within the views and levels of the ARIS concept......................................................... 11

3.1 Function view ........................................................................................................................... 11
3.1.1 Requirements definition .............................................................................................. 11
3.1.1.1 Function tree .................................................................................................... 12
3.1.1.2 Objective diagram ............................................................................................. 17
3.1.2 Design specification - Application system type diagram.................................... 18
3.1.3 Implementation - Application system diagram ..................................................... 23
3.2 Data view .................................................................................................................................. 26
3.2.1 Requirements definition ............................................................................................. 26
3.2.1.1 The ERM base model ....................................................................................... 26
3.2.1.2 ERM - eERM extensions.................................................................................. 31
3.2.1.2.1 Design operators added ....................................................................... 31
3.2.1.2.2 Extension of cardinalities .................................................................... 36
3.2.1.2.3 Identification and existence dependency .......................................38
3.2.1.2.4 Modeling technical terms used in a company - Technical
terms model ............................................................................................ 39
3.2.1.2.5 eERM attribute allocation diagram .................................................... 41
3.2.1.2.6 IE data model .......................................................................................... 42
3.2.1.3 Summary of the main terms and forms of representation of the
eERM ................................................................................................................... 43
3.2.1.4 Modeling the Data Warehouse structure ....................................................44
3.2.1.5 Project management data - Information carrier diagram ...................... 45
3.2.2 Implementation - Table diagram ............................................................................... 46
3.2.3 Role assignment diagram (RAD) ............................................................................... 49
3.3 Organization view ................................................................................................................... 50
3.3.1.1 Organizational structure of companies ...................................................... 50
3.3.1.2 Organizational chart ........................................................................................ 53
3.3.2 Design specification - Network topology ................................................................ 58
3.3.3 Implementation ............................................................................................................. 60
3.3.3.1 Network diagram.............................................................................................. 60
3.3.3.2 Material flow modeling - Technical resources .......................................... 62
3.4 Process view ............................................................................................................................ 65
3.4.1.1 Linking functions with organization - EPC ................................................ 65
3.4.1.2 Linking functions with data ........................................................................... 67
I
METHOD MANUAL
3.4.1.2.1 Event control - Event-driven process chain (EPC)........................ 67

3.4.1.2.2 Function allocation diagram (I/O) ...................................................... 77
3.4.1.2.3 Event diagram ....................................................................................... 80
3.4.1.3 Functions - Organization - Data................................................................... 81
3.4.1.3.1 Value-added chain diagram ................................................................ 81
3.4.1.4 Object-oriented modeling.............................................................................. 81
3.4.1.5 Process variants .............................................................................................. 82
3.4.1.5.1 Process selection matrix ..................................................................... 82
3.4.1.6 Material flow modeling .................................................................................. 84
3.4.1.6.1 EPC (material flow)............................................................................... 84
3.4.1.6.2 EPC (column/row display) ...................................................................86
3.4.1.7 Other models ................................................................................................... 88
3.4.1.7.1 Business controls diagram ................................................................. 88
3.4.1.7.2 E-Business scenario diagram ............................................................. 89
3.4.1.7.3 Structuring model ................................................................................. 92
3.4.1.7.4 Role diagram ........................................................................................... 93
3.4.1.7.5 Quick model ............................................................................................ 95
3.4.1.7.6 Screen design......................................................................................... 96
3.4.1.7.7 Screen navigation ................................................................................. 98
3.4.1.7.8 Business segment matrix .................................................................... 99
3.4.2 Design specification ................................................................................................... 101
3.4.2.1 Access diagram ............................................................................................... 101
3.4.2.1.1 Linking functions with data ...............................................................101
3.4.2.1.2 Linking organization with function.................................................. 102
3.4.2.2 Program flow chart ....................................................................................... 103
3.4.2.3 Program flow chart (PF) ............................................................................... 104
3.4.2.4 Screen diagram .............................................................................................. 105
3.4.3 Implementation - Access diagram (physical) ...................................................... 107
3.4.3.1 Linking functions with data ......................................................................... 107
3.4.3.2 Linking organization with data ................................................................... 109
3.4.3.3 Linking organization with functions ...........................................................110
3.5 Product/Service modeling ................................................................................................... 113
3.5.1 Product/Service exchange diagram ....................................................................... 114
3.5.2 Product/Service tree .................................................................................................. 116
3.5.3 Product allocation diagram ....................................................................................... 117
3.5.4 Product tree .................................................................................................................. 119
3.5.5 Product selection matrix .......................................................................................... 120
4 Unified Modeling Language (UML) in ARIS .................................................................................... 121

4.1 Introduction ............................................................................................................................ 121
4.2 ARIS UML Designer - Supported UML standard.............................................................. 121
5 Methods for knowledge management .......................................................................................... 122

5.1 Introduction ........................................................................................................................... 122
5.2 Object types for modeling knowledge processing ........................................................ 123
5.2.1 Knowledge category .................................................................................................. 123
5.2.2 Documented knowledge ........................................................................................... 126
II
METHOD MANUAL
5.3 Model types for modeling knowledge processing ......................................................... 126

5.3.1 Knowledge structure diagram ................................................................................. 126
5.3.2 Knowledge map........................................................................................................... 127
5.3.3 Representation of knowledge processing in business processes .................. 129
6 Balanced Scorecard method ........................................................................................................... 130

6.1 Introduction ........................................................................................................................... 130
6.2 The Balanced Scorecard concept ..................................................................................... 130
6.2.1 Key elements of the BSC approach ........................................................................ 130
6.2.2 Strategic management process and Balanced Scorecard................................. 131
6.2.2.1 Formulation and realization of vision and strategy ............................... 133
6.2.2.1.1 Standard perspectives of a Balanced Scorecard ......................... 134
6.2.2.1.2 Cause-and-effect chain .................................................................... 135
6.2.2.1.3 Definition of leading and lagging indicators.................................. 135
6.2.2.2 Communication and derivation of further scorecards .......................... 136
6.2.2.3 Planning and targets..................................................................................... 136
6.2.2.4 Strategic learning and feedback ................................................................ 137
6.2.3 Advantages and benefits of the Balanced Scorecard ....................................... 138
6.3 Developing a Balanced Scorecard with ARIS BSC......................................................... 139
6.3.1 Terms and abbreviations .......................................................................................... 139
6.3.2 Creating Balanced Scorecards with ARIS BSC ..................................................... 141
6.3.2.1 Specification of perspectives ...................................................................... 141
6.3.2.2 Balanced Scorecard system structure specification .............................141
6.3.2.3 Cause-and-effect relationship specification .......................................... 142
6.3.2.4 Specification of initiatives and KPIs to monitor objectives .................. 145
6.3.2.5 Description of KPIs and their relationships.............................................. 148
6.3.3 Relationships to other models ................................................................................. 148
7 E-Business scenario diagram ......................................................................................................... 149

7.1 Introduction ........................................................................................................................... 149
7.2 E-Business scenario diagram method .............................................................................. 151
7.2.1 The idea ......................................................................................................................... 151
7.2.2 The model and its objects .......................................................................................... 151
7.2.3 'Transmission type' attribute group ....................................................................... 153
7.3 Evaluations using reports ................................................................................................... 153
7.3.1 Data security check ................................................................................................... 153
7.3.2 System support........................................................................................................... 153
7.3.3 Information flow ......................................................................................................... 154
7.3.4 Collaborative business maps ................................................................................... 154
III
METHOD MANUAL
7.4 Connection to other methods and components ........................................................... 154
8 IT City Planning .................................................................................................................................. 158

8.1 Enterprise Architecture and IT City Planning ................................................................. 158
8.2 Which companies may benefit from IT City Planning? ................................................. 158
8.3 IT City Planning with ARIS .................................................................................................. 159
8.4 Service view ............................................................................................................................ 161
8.5 Service types and their data .............................................................................................. 165
8.6 Detail description of service types ................................................................................... 166
8.7 Chronological-logical operational sequences of IS elements .................................... 167
8.8 IT view ..................................................................................................................................... 168
8.9 IT elements and their data .................................................................................................. 169
8.10 Detail description of IT elements ...................................................................................... 170
8.11 Organizational aspects ......................................................................................................... 171
8.12 Chronological-logical operational sequences of IT elements...................................... 171
8.13 Chronological-logical operational sequences within the architecture .................... 172
8.14 Possible evaluations............................................................................................................. 173
9 Business process modeling ............................................................................................................. 174

9.1 Process classes and the business process diagram .................................................... 174
9.2 Implementation of BPMN in ARIS ...................................................................................... 176
9.3 Elements of the business process diagram ..................................................................... 177
9.3.1 Pools and lanes ............................................................................................................ 177
9.3.2 Modeling guidelines for pools and lanes ............................................................... 178
9.3.3 Sequence flow............................................................................................................. 178
9.3.4 Modeling guidelines for sequence flow connections ......................................... 178
9.3.5 Message flow ............................................................................................................... 179
9.3.6 Modeling guidelines for message flow connections........................................... 180
9.3.7 Association................................................................................................................... 180
9.3.8 Events ............................................................................................................................181
9.3.9 Modeling guidelines for events ............................................................................... 182
9.3.10 Activities ....................................................................................................................... 184
9.3.11 Modeling guidelines for activities ........................................................................... 185
9.3.12 Gateway ........................................................................................................................ 186
9.3.13 Modeling guidelines for gateways .......................................................................... 187
9.3.14 Artifact .......................................................................................................................... 189
9.3.15 Sources of figures ....................................................................................................... 191
10 Modeling BPMN 2.0............................................................................................................................ 192

10.1 Introduction ........................................................................................................................... 192
10.1.1 Initial situation and objective................................................................................... 192
10.1.2 Purpose of this chapter ............................................................................................ 192
10.2 BPMN core elements and their implementation in ARIS .............................................. 193
10.2.1 Infrastructure .............................................................................................................. 193
10.2.2 Foundation ................................................................................................................... 194
IV
METHOD MANUAL
10.2.3 Common Elements ..................................................................................................... 196

10.2.3.1 Artifacts ........................................................................................................... 196
10.2.3.1.1 Association .......................................................................................... 200
10.2.3.1.2 Group ..................................................................................................... 200
10.2.3.1.3 Text annotation.................................................................................... 201
10.2.3.2 Callable Elements ......................................................................................... 202
10.2.3.3 Event ............................................................................................................... 202
10.2.3.4 Expression ...................................................................................................... 203
10.2.3.5 Flow Element ................................................................................................. 203
10.2.3.6 Flow Elements Container ............................................................................ 204
10.2.3.7 Gateways ........................................................................................................ 205
10.2.3.8 Message .......................................................................................................... 206
10.2.3.9 Message flow .................................................................................................. 207
10.2.3.10 Participant ...................................................................................................... 209
10.2.3.11 Resource .......................................................................................................... 213
10.2.3.12 Sequence flow ................................................................................................ 213
10.2.3.13 Elements not included in the current implementation ......................... 217
10.3 BPMN diagrams and ARIS model types: An overview ................................................... 218
10.4 Process.................................................................................................................................... 219
10.4.1 Activities ....................................................................................................................... 221
10.4.1.1 Resource assignment .................................................................................. 224
10.4.1.2 Performer ....................................................................................................... 224
10.4.1.3 Activity type: Task ........................................................................................ 225
10.4.1.4 Human interactions...................................................................................... 229
10.4.1.5 Activity type: Subprocess ........................................................................... 229
10.4.1.5.1 Subprocess type: Subprocess ......................................................... 230
10.4.1.5.2 Subprocess type: Event subprocess.............................................. 232
10.4.1.5.3 Subprocess type: Transaction ......................................................... 233
10.4.1.5.4 Subprocess type: Ad hoc subprocess ........................................... 234
10.4.1.6 Subprocess type: Call Activity ................................................................... 236
10.4.1.7 Global task ...................................................................................................... 238
10.4.1.8 Loop characteristics .................................................................................... 238
10.4.1.8.1 Loop characteristics representations............................................ 238
10.4.1.8.2 Standard and multi-instance loop characteristics and
complex behavior definition ............................................................ 240
10.4.2 Items and Data ........................................................................................................... 243
10.4.2.1 Data object ..................................................................................................... 243
10.4.2.2 Data store ....................................................................................................... 246
10.4.3 Events ........................................................................................................................... 247
10.4.3.1 Catch events and throw events ................................................................ 249
10.4.3.2 Start event ...................................................................................................... 251
10.4.3.3 Intermediate events ..................................................................................... 252
10.4.3.4 End event ....................................................................................................... 253
10.4.3.5 Event definitions ........................................................................................... 253
10.4.4 Gateways ...................................................................................................................... 261
V
METHOD MANUAL
10.4.5 Exclusive gateway ..................................................................................................... 262

10.4.5.1 Inclusive gateway ......................................................................................... 262
10.4.5.2 Parallel gateway ............................................................................................ 263
10.4.5.3 Complex gateway ......................................................................................... 263
10.4.5.4 Event-based gateways ............................................................................... 264
10.4.6 Lanes ............................................................................................................................ 265
10.5 Collaboration .......................................................................................................................... 267
10.5.1 Pool and participant .................................................................................................. 268
10.5.2 Object types and connection types reused from a process ............................ 269
10.5.3 Message flow ............................................................................................................... 270
10.6 Conversation .......................................................................................................................... 270
10.6.1 Conversation container............................................................................................. 271
10.6.2 Conversation nodes ................................................................................................... 272
10.6.3 Participant .................................................................................................................... 273
10.6.4 Artifacts ........................................................................................................................ 273
10.6.5 Conversation link ........................................................................................................ 273
10.6.6 Message flow in a conversation .............................................................................. 274
10.6.7 Model assignments .................................................................................................... 275
10.7 Enterprise BPMN collaboration diagram .......................................................................... 275
11 Customer Experience Management (CXM) .................................................................................. 276

11.1 Customer journey landscape ............................................................................................. 277
11.2 Customer journey map ........................................................................................................ 278
11.3 Customer touchpoint allocation diagram....................................................................... 280
11.4 Customer touchpoint map .................................................................................................. 281
11.5 Linking CXM and BPM ......................................................................................................... 282
11.5.1 Analysis capabilities .................................................................................................. 283
11.5.1.1 Report .............................................................................................................. 283
11.5.1.2 Queries ............................................................................................................ 284
11.5.1.2.1 Get full customer journey overview ............................................... 284
11.5.1.2.2 Find customer touchpoints clustered by associated risk ......... 286
11.5.1.2.3 Find customer touchpoints clustered by associated
ownership.............................................................................................. 287
11.5.1.2.4 Find customer touchpoints clustered by associated
channel ................................................................................................. 288
11.5.1.2.5 Find risks and initiatives for all customer touchpoints .............. 289
11.5.1.2.6 Find risks and initiatives for bad customer touchpoints only .. 290
11.5.1.2.7 Find all processes related to customer journeys ......................... 291
VI
METHOD MANUAL
12 Use cases............................................................................................................................................ 292

12.1 General company documentation.................................................................................... 295
12.2 Database management/Data warehousing................................................................... 296
12.3 PC hardware and network management ......................................................................... 297
12.4 Process cost management ................................................................................................ 298
12.5 Quality management ........................................................................................................... 299
12.6 Reorganization measures .................................................................................................. 300
12.7 SAP R/3 implementation..................................................................................................... 301
12.8 Software development and implementation ................................................................. 302
12.9 Knowledge management ................................................................................................... 303
12.10 Workflow management ....................................................................................................... 304
13 Bibliography ....................................................................................................................................... 305

13.1 General literature list........................................................................................................... 305
13.2 Topic-related bibliography ................................................................................................ 307
13.2.1 Unified Modeling Language in ARIS....................................................................... 307
13.2.1.1 UML specification ......................................................................................... 307
13.2.1.2 Using UML....................................................................................................... 307
13.2.1.3 UML and business process modeling ....................................................... 307
13.2.2 Methods for knowledge management .................................................................. 308
13.2.2.1 General knowledge management ............................................................. 308
13.2.2.2 Using ARIS for knowledge management ................................................. 308
13.2.3 Balanced Scorecard method................................................................................... 308
13.2.4 IT City Planning .......................................................................................................... 308
13.2.5 Business process modeling..................................................................................... 308
14 Legal information.............................................................................................................................. 309

14.1 Documentation scope......................................................................................................... 309
14.2 Support .................................................................................................................................. 309
15 Index ...........................................................................................................................................................i
VII
METHOD MANUAL
1 Introduction
In the past, system design and system integration had the greatest potential for optimization.
In recent years, however, the focus has shifted more and more towards creating solutions for
the special demands of individual sectors. The fact that decentralized information systems
became available and that it was possible to incorporate them into integrated information
system infrastructures created new cost saving potential regarding the organizational design
of companies.
Organizational structures were formerly broken down functionally and established centrally
because they were mostly based on centralized host environments with only limited
capabilities. As a consequence, companies suffered a loss of flexibility. In the beginning, few
people realized or paid attention to the new prospects resulting from the increase in
decentralization of computer services and parallel development of new information system
architecture concepts (for example, client/server, workflow management).
Today, steadily intensifying competition has turned this potential into the number one topic
for every single company. Flexible structures that persistently focus on internal business
processes are becoming the decisive competition factor for companies. However, only a
holistic view of all business processes enables a company to recognize, streamline, and
support interconnected processes through optimized information system infrastructures.
Compared with the management of centralized business environments, the management of
these new structures is significantly more complex. Facing this challenge requires
unequivocal assignment of responsibilities, maximum transparency of structures,
homogeneous communication throughout all company levels, and streamlined project
management based on defined business objectives.
Enterprise modeling methods assist business managers in accomplishing these complex
tasks. Enterprise models are a crucial prerequisite for analyzing business processes, bringing
projects in line with the overall business objectives, and using information system
infrastructures in the form of composite distributed and integrated systems to optimally
support these lean organizational structures.
Thus, modeling the company's actual situation - and, in doing so, examining holistic business
processes - is becoming more and more the focus of the discussion. The diversity and
increasing multitude of modeling methods used to result in complexity and confusion.
Consequently, efforts were made to define standardized framework concepts (architectures)
for development and modeling methods.
One of these architectures is the Architecture of Integrated Information Systems (ARIS©)
developed by Scheer (see Scheer, Architecture of Integrated Information Systems, 1992). This
architecture concept enables methods to be evaluated and organized by focusing on their
main points, and it serves as an orientation framework for complex development projects
1
METHOD MANUAL
because due to its structural elements, it contains an implicit procedure model for developing
integrated information systems.
An architecture of this kind naturally leads towards standardization in the use of methods.
Based on this architecture, existing and new modeling methods were combined to create a
holistic method for modeling business processes.
In addition, the ARIS architecture integrates products such as ARIS Architect within the
product range of Software AG. These products support consultants and companies in
creating, analyzing, and evaluating business processes in terms of business process
reengineering. Convenient recording and modeling of the relevant business processes in the
operating departments is enabled by ARIS Designer.
This manual gives a first introduction to the relevant modeling methods. In addition,
approaches and methods are presented that make use of the full range of ARIS products
including the system add-ons they offer. This manual also provides excellent support for
users who deal with modeling methods without the intention of considering questions or
problems regarding the use of tools.
2
METHOD MANUAL
2 Architecture of Integrated Information Systems (ARIS)
2.1 ARIS architecture concept

The ARchitecture of integrated Information Systems (ARIS) is based on an integration
concept derived from a holistic view of business processes. The first step in creating the
architecture is to develop a business process model containing all basic features for
describing business processes. The result is a highly complex model, which is broken down
into individual views so that its complexity is reduced. Due to this breakdown, it is possible to
describe the content of individual views by special methods suitable for a specific view
without having to pay attention to the numerous view interrelationships. The relationships
between the views are incorporated in a final step and combined to form an overall overview
of process chains without any redundancies.
A second approach that also reduces complexity is a differentiation via descriptions.
Following the lifecycle concept, the various description methods for information systems are
classified based on their proximity to information technology. This ensures a consistent
description, from business management problems through to technical implementation.
Thus, the ARIS concept is a framework for developing and optimizing integrated information
systems and for describing their implementation. As the emphasis lies on the technical
descriptive level, the ARIS concept serves as a model for creating, analyzing, and evaluating
business management process chains. Scheer describes the Architecture of integrated
Information Systems in more detail (see Scheer, Architecture of Integrated Information
Systems, 1992, and Scheer, ARIS - Business Process Frameworks, 1998).
2.2 Descriptive views

The focus of this approach is on a business process, like the one shown in the following
figure.
The process is triggered by the Customer order received event. In turn, this event activates
the Accept customer order function (procedure). For this procedure to be performed, the
current state of the relevant process environment must first be described. In particular, this
includes data relating to customers and items. The state of associated objects may change
during workflow processing, for example, when the items' inventory data is updated with the
new reservation data.
The procedures are performed by sales employees who can be assigned to departments.
Departments use specific information technology resources (personal computers, printers,
etc.) to perform their tasks.
3
METHOD MANUAL
Once the Accept customer order procedure is completed, the Order is confirmed event
occurs that in turn may trigger other procedures, such as Track order or Create production
plan. The Order object is now in a new state because the Order received object has become
an Order confirmed object. Carrying out the Accept customer order function has
generated a product/service that is used - in combination with human and technical
resources - as an input for processing subsequent procedures.
Figure 1: Business process model
The components required to provide a full description of a business process include

procedures, events, products/services (states), users, organizational units, and information
technology resources. Covering all effects on all elements of every procedure under
consideration would result in a rather complex model and lead to redundancies in the
description.
4
METHOD MANUAL
To reduce complexity, the general context is broken down into individual views (see the
following figure) that represent specific modeling and design aspects (see Scheer,
Architecture of Integrated Information Systems, 1992, p. 13 et sqq.). These can be processed
independently. The views are broken down in such a way that relationships between the
components are rather numerous within a single view, while there are only relatively few
relationships between the various views.
Figure 2: Process model views
Events, such as Customer order received or Invoice created, represent the fact that the
state of information objects (data) changes. Events are described in the data view of the ARIS
architecture.
The states that exist in the objects' environment, for example, within the scope of the
customer order, are represented by products/services. The term product/service refers to
the supply of either goods or services. Services that create and provide information are
information services. Products/Services also include the provision of financial resources.
Relationships between products/services are described in the ARIS architecture's
Product/Service view.
The functions to be carried out (procedures) and their interrelationships form a second view,
the Function view. It contains the description of the function, an enumeration of individual
subfunctions that are part of the overall context, and the relationships that exist between the
functions.
The Organization view subsumes users and organizational units, as well as their
relationships and structures.
5
METHOD MANUAL
Information technology resources constitute the fourth area of consideration, the so-called
Resource view. However, this view is significant for the technical consideration of business
processes only insofar as it provides general conditions for describing other components that
are more directly geared toward business management. For this reason, the components of
the other views (Data, Function, and Organization view) are described in terms of their
proximity to the information technology resources. Thus, resources are dealt with at the
design specification and implementation level of the other views (see chapter Descriptive
levels (page 7)). The lifecycle model that is defined as a result of the descriptive level
approach replaces the resource view as an independent object of consideration.
While breaking down the process into individual views reduces complexity, the process
component relationships across the views are lost. For this reason, the Control view is
provided as an additional view for describing the relationships between views. Combining
these relationships in a separate view allows for systematic and redundancy-free recording
of all relationships.
The control view is an essential component of ARIS. It is the fundamental feature that
distinguishes the ARIS concept from other architecture approaches (for comparison with
other architecture approaches see Scheer, Architecture of Integrated Information Systems,
p. 24 et sqq.).
Thus, there is a total of five ARIS views, which form the basis of the following method
descriptions.
Figure 3: Views of a process model
6
METHOD MANUAL
2.3 Descriptive levels

As mentioned earlier, the ARIS resource view is replaced by a lifecycle concept of an
information system's descriptions.
Lifecycle models in the form of level or phase concepts describe the lifecycle of information
systems. However, the ARIS lifecycle model is not to be understood as a procedure model for
developing an information system. It rather serves to define the various descriptions that
differ in their proximity to information technology.
ARIS uses the three-tier division shown in the following figure (see Scheer, Architecture of
Integrated Information Systems, 1992, p. 16 et sqq.).
The focus of this approach is on the business management problem. The description lists
rough facts that focus very closely on technical objectives and technical language. The
options that information technology provides for supporting business management
processes and decisions are also included. Therefore, only semi-formal description methods
are used for representation purposes. Because of their lack of detail and their highly technical
vocabulary, these description methods cannot serve as a starting point for a formalized
implementation.
Thus, a Requirements definition has a rather formalized description language to describe
the business management approach to be supported, so that it can be used as the basis for
consistent transformation into information technology. This procedure is also referred to as
(semantic) modeling. The requirements definition is closely associated with the business
management problem, as indicated by the width of the arrow in the following figure.
Applying the requirements definition's concept to the design of IT systems leads to the
Design specification level. Here, the modules or transactions that carry out technical
functions are defined, not the functions themselves. At this level, the requirements definition
is aligned with general concepts used in information technology. However, the requirements
definition and the design specification are only loosely coupled. This means that a design
specification can be changed without affecting the requirements definition. However, this
does not imply that requirement definitions and design specifications can be developed
separately from each other. In fact, once a requirements definition is complete, the business
management-related topics should be specified in such a way that purely IT-specific
considerations, such as the information system performance, do not have any impact on the
technical content.
At the Implementation level, the design specification is transformed into functional
hardware and software components. This establishes the link to information technology.
The descriptions have individual update cycles. The update frequency is lowest at the
requirements definition level and highest at the implementation level.
7
METHOD MANUAL
The implementation level is closely coupled with information technology development and is
subject to continuous change as a result of rapid innovation cycles in information technology.
The requirements definition level is of particular importance because it serves as a repository
for the long-term business management approach and, at the same time, is the starting point
for further steps towards technical implementation. Requirement definitions have the longest
lifecycle and – due to their close proximity to the business management problem – also
document the technical benefits of the information system. For this reason, the view that
deals with developing requirement definitions or semantic models is the one with the highest
priority. Semantic models build the bridge between users and the initial translation of their
business management problem into an IT-related language.
Figure 4: Descriptions of an information system
The combination of views, descriptions, and business management solutions forms the
essence of the ARIS concept. As shown in the following figure, each descriptive view is
8
METHOD MANUAL
broken down into the Requirements definition, Design specification and Implementation
level.
Figure 5: ARIS concept
The ARIS concept sums up the relevant objects or areas of consideration as defined by the
architecture's descriptive views and levels. Including the business management problem,
which is the focus of this approach, this gives rise to a total of thirteen components. In a next
step it is necessary to select and explain suitable description methods for each object or area
of consideration.
9
METHOD MANUAL
The criteria for selecting these methods (see Scheer, Business Process Engineering, 1994)
include:
 simplicity and understandability of the means of representation,
 suitability for the content to be expressed,
 ability to use consistent methods for all applications to be represented,
 existing or expected level of familiarity with the methods, and
 independence of the methods from technical developments in information technology.
Individual methods applied to the objects or areas of consideration are described in the
following chapters.
10
METHOD MANUAL
3 Modeling within the views and levels of the ARIS

concept
3.1 Function view
3.1.1 Requirements definition

Modeling methods often look at functions in the context of objects from other descriptive
views of ARIS. For example, the relationship between data and functions is displayed to
illustrate how the input/output data affect the process of transforming a function.
In contrast, the ARIS architecture strictly separates the various areas of consideration (see
Scheer, Architecture of Integrated Information Systems, 1992, p. 62). Consequently, the
function view covers only those means of representation that show the interconnections
between functions. Relationships between functions and data are displayed in the ARIS
process view.
A function is a technical task or activity performed for an object to support one or more
business objectives (see Scheer, Architecture of Integrated Information Systems, 1992, p. 63).
Functions are displayed as rectangles with rounded corners:
Figure 6: Representation of the 'Verify customer inquiry' function
Usually, the criterion for establishing such a function is an information object, such as a
customer inquiry or a production order. This should also be expressed in the function name.
This is shown in the above figure. Customer inquiry defines the object while Check indicates
the operation that is performed for this object. At a higher level, however, mostly a noun is
used as the function name (for example, Procurement logistics, Production, Sales).
11
METHOD MANUAL
3.1.1.1 Function tree

Functions can be described at different aggregation levels. Accumulations of functions in the
form of business processes or process chains form the top level of aggregation. An example
may be the processing of a customer order, from customer inquiry through to shipping. A
business process thus represents a complex function that can be broken down into
subfunctions to reduce its complexity. The term 'function' can be used at all hierarchy levels.
However, other terms, such as procedure, process, subfunction, or elementary function, are
also used to indicate the hierarchy level.
Breaking down functions can be done across multiple hierarchy levels. Elementary functions
represent the lowest level in semantic function trees.
Elementary functions are functions that, from the business management point of view,
cannot be broken down any further.
Hierarchical structures are best represented using function trees or hierarchy models.
Figure 7: Function tree (extract)
Grouping functions within a function tree can be performed according to different criteria
(see Brombacher/Bungert, 'Praxis der Unternehmensmodellierung' [Enterprise modeling
12
METHOD MANUAL
practise], 1992). Criteria frequently used for this purpose include: processing of the same
object (object-oriented), breakdown according to process affiliation (process-oriented), or
grouping of functions in charge of the same operations (execution-oriented).
The next figure shows an example of an object-oriented breakdown. The superior Process
production order function is subdivided into the functions Create production order,
Confirm production order, Update production order, Cancel production order, Release
production order and Monitor production order. These functions describe different
operations (create, update, cancel, etc.) that are performed for one and the same object,
which is Production order.
Figure 8: Object-oriented function tree
A process-oriented representation is recommended for function trees that represent the

results of business process modeling. The following figure shows an example of
process-oriented function breakdown.
13
METHOD MANUAL
The functions Accept customer order, Check customer order, Create customer data,
Check customer creditworthiness, Check product availability, and Confirm customer
order are part of the Process customer order business process. Unlike the object-oriented
breakdown, the operations here are performed for different objects (customer order, product
availability, etc.).
Figure 9: Process-oriented function tree
14
METHOD MANUAL
Execution-oriented grouping means that all functions performing the same operation (check,
create, delete) for different information objects are grouped together. An example of the
Change operation is shown in the following figure. The functions shown may occur in
different processes and are involved in processing different objects. However, the type of
operation they perform for the various objects is always the same.
Figure 10: Execution-oriented function tree
Representing functions in a function tree reduces complexity, but the representation is static.
Besides the static representation, the chronological sequence of functions may also be of
interest. Chronological-logical operational sequences are represented in so-called
event-driven process chains (EPCs). These contain not only functions, but also events linking
the functions. Events belong to the data view in ARIS. In line with the principle of separation
of views stipulated by ARIS (see chapter Requirements definition (page 11)), event-driven
process chains are described in the ARIS control view.
Describing functions from a requirements definition-related point of view involves not only
the principle of breaking down functions into subfunctions, but also other function properties,
especially those that can influence the design of business processes.
For example, it is recommended that functions always include information on whether or not
user intervention is required for carrying out the function. Functions of similar type that can
be carried out automatically may be bundled and processed in a batch run.
Information on the quantity structure of a function (for example, number of inquiries
processed in a day) and on the total amount of time it takes to carry out the function provide
15
METHOD MANUAL
further data that can serve as a basis for decision-making with regard to the redesign of
business processes. The total amount of time can be further divided into individual units of
time (orientation time, processing time, wait time). In ARIS, this information can be saved in
the attributes of the Function object type. A list of all attribute types that are available is
provided in the ARIS Method Reference manual (ARIS Method Reference.pdf) on your
installation media.
16
METHOD MANUAL
3.1.1.2 Objective diagram

Before a company starts modeling, analyzing, or optimizing business processes (Business
Process Reengineering), it should define the objectives it wants to achieve by modeling the
company's business processes.
In the objective diagram, companies can define their (business) objectives, arrange them in an
objective hierarchy, etc.
An objective defines future business objectives that are to be achieved by promoting success
factors and implementing new business processes.
Factors that may be critical for achieving objectives can be specified, arranged in a hierarchy,
and assigned to the goals they help accomplish.
Success factors specify the aspects that need to be considered in order to achieve a specific
business objective. They are assigned to business objectives in the objective diagram.
This model type is linked to other model types of the requirements definition via the Function
object type. The functions (business processes) contributing to the achievement of an
objective can be displayed for every single objective. When establishing the procedure model
in the business process modeling and optimizing phase, both the prioritization of objectives
as well as the assigned functions should be taken into account.
The following figure shows an example of an objective diagram.
Figure 11: Objective diagram
17
METHOD MANUAL
3.1.2 Design specification - Application system type diagram

The design specification of the function view contains the specification for the application
system and module types, as well as the modular structure of the application system type, an
outline of individual transaction steps, and the definition of input and output presentations in
the form of draft lists and screen designs.
Key questions to which the design specification of the function view provides answers are:
 How can application system types, module types, or IT functions support the functions
defined in the requirements definition?
 What is the modular structure of application system types or module types?
 Which lists and screens are required to carry out a function?
 Which lists can be created with an application system type or a module type, and which
screens do application system types and module types use?
 What technology (operating system, user interface, database management system) is an
application system type based on?
 Which business objectives are pursued when a specific application system type is used?
Thus, the Application system type is the key object type of the function view's design
specification.
Unlike concrete application systems that come into play only at the implementation level of
the function view and that represent specific, identifiable (for example, by a license number)
application systems within a company, application system types are generated as the result
of typifying all application systems that are based on precisely the same technology.
An application system type typifies individual application systems that are based on precisely
the same technology.
Example: ARIS Architect is an application system type. You can purchase several licenses for
this application system type and thus obtain various individual application systems.
Application system types are represented by the following graphic symbol:
Figure 12: Graphical representation of an application system type
18
METHOD MANUAL
Application system types are mostly modular in structure. The application system type
diagram is a means of representing this modular structure. Application system types are
broken down into module types. The following figure shows an example:
Figure 13: Modular structure of an application system type
In the above example, ARIS Architect consists of the module types Explorer, Model, Matrix
Editor, Administration, and Script Editor. As with application system types, module types
typify individual modules that are based on precisely the same technology. Module types are
components of application system types. They are capable of autonomous operation.
A module type is a component of an application system type, which is capable of autonomous
operation. Module types typify individual modules that are based on precisely the same
technology.
Application system types and module types can be arranged in any hierarchy. At the lowest
level, module types can be divided into IT function types.
An IT function type, in the sense of a transaction, is the smallest unit of a module type. IT
function types are realized as individual program modules and must always be carried out
completely to process an individual work step.
Figure 14: Graphical representation of an IT function type
19
METHOD MANUAL
The application system type diagram is also a means of defining the functions of the
requirements definition that are supported by the specified application system types and
module types. This assignment forms the link between the requirements definition and the
design specification of the function view. The following figure shows an example.
Figure 15: Allocation of functions to application system types
To obtain a more detailed specification of the technology that application system types and
module types are based on, it is possible to allocate to them the types of user interfaces,
database management systems, and operating systems under which they can run, as well as
the programming languages that are used to implement them. As this concerns types and not
concrete specimen, multiple relationships are possible. For example, an application system
type can be assigned the Windows 7 and Windows 8 user interface, which means that the
application system type can run under both user interfaces. A unique relationship is required
only when the graphical user interface is assigned to a concrete specimen (that is, a specific
application system) at the implementation level of the function view. This relationship
describes the exact configuration of the application system type license that the company
purchased.
20
METHOD MANUAL
An example of possible assignments in an application system type diagram is shown in the

following figure.
Figure 16: Application system type configuration
Processing a technical function with the support of an application system involves the use of
various screens and the creation or use of various lists provided by the corresponding
application system. For this purpose, the List and Screen objects are available and can be
assigned to either the technical function or the application system types and module types.
If, in a first step, general operational procedures are to be defined without reference to
specific application system types, the Draft list and Screen design objects can be used to
specify the required screens and lists. First, both object types specify in general which type of
list or screen is to be used (for example, Enter customer data), without establishing a
specific reference to application system type lists or screens. Subsequently, these draft lists
and screen designs can be assigned to specific lists and screens. Existing assignments
determine possible implementation scenarios. The following figure illustrates an example.
Figure 17: Screen and list assignments
21
METHOD MANUAL
A list of object types and relationships that are available in an application system type
diagram is provided in the ARIS Method Reference manual on your installation media.
22
METHOD MANUAL
3.1.3 Implementation - Application system diagram

In the application system type diagram, you can assign specific application systems and
modules to the application system types and module types described in the design
specification. Application systems are specimens of an application system type that exist in
the company and can be uniquely identified, for example, by the license numbers.
An application system (module) is an individual specimen of an application system type
(module type), which can be uniquely identified, for example, by the license number.
Application systems and modules are displayed graphically as follows.
Figure 18: Graphical representation of the application system and the module
As a company may have more than one license for an application system type (module type),
more than one application system (module) can be assigned to an application system type
(module type) in the application system diagram.
Figure 19: Assignment of application systems to their application system types
23
METHOD MANUAL
The application system diagram shows the actual modular structure of an application system.
While the design specification lists all modular components that an application system type
may have, here we are dealing with a single application system license so that the modular
components can be uniquely defined for each license. Therefore, a company may have
multiple application systems of the same application system type, but with completely
different modular structures.
Figure 20: Different modular structure of two application systems of the same type
The implementation level not only represents all existing application systems and modules,
but also enables the technical (physical) implementation of application systems to be defined
in the form of individual program files.
The application system type diagram illustrates which program module types are required to
implement an application system type or module type.
A program module is a program file on a storage medium obtained by purchasing a license (for
example, an EXE file or COM file). A program module type is created by typifying program
modules that are based on precisely the same technology.
24
METHOD MANUAL
The following figure illustrates the assignment of program module types to an application
system type and of individual program modules to program module types.
Figure 21: Assignment of application system types, program module types, and program modules
The ARIS Architect application system type consists of the arisarchitect.exe, dbbase.dll,
abaris.dll, and ATAexpl.dll program module types. Multiple specimens (program modules) of
each program module type may exist in the company if several licenses were purchased or if
backup copies were created.
Program module types and program modules can be arranged in any hierarchy. For a more
precise technological specification of the program it is possible to also represent the access
of program module types to program libraries in the application system type diagram.
A list of object types and relationships that are available in an application system type
diagram is provided in the ARIS Method Reference manual on your installation media.
25
METHOD MANUAL
3.2 Data view

The requirements definition of the data view includes a description of the semantic data
model of the area of consideration. In line with the breakdown approach stipulated by ARIS,
the description covers both the objects that specify the start and end events of a process
chain and the current state of the relevant process chain environment.
Unlike function modeling, data modeling is particularly demanding as far as the method is
concerned. In the function view, the only object examined is the function. Furthermore,
relationships between functions simply illustrate superordination or subordination.
Chen's Entity-Relationship Model (ERM) is the most widely used designing method for
semantic data models (see Chen, The Entity-Relationship Model, 1976). This modeling method
uses a variety of specialized terms, such as entity type, relationship type, attribute, etc. The
relationships that exist between these objects are numerous and - compared with function
modeling - significantly more difficult to classify.
The following pages introduce modeling with entity relationship models (ERM). First, the
objects and relationships of Chen's base model are explained. Then, another chapter
describes several rules that were added later to the base model.
3.2.1.1 The ERM base model

The base model distinguishes between entities, attributes, and relationships. Basically, a
distinction is made between type level and occurrence level.
Entities are real or abstract objects that are relevant for the business management tasks
being examined.
For example, a business process can be a considered object. According to the ARIS
breakdown model, the data objects of interest are objects of the environment and objects
specifying events. Examples of entities in the Customer order processing process are:
 Customer 1235,
 Item 471,
 Order 11.
Entities are described in more detail by specific attributes (properties). For example, a
customer can be specified more precisely by his name, first name, and address.
If similar entities are grouped into sets, these are referred to as entity types, the individual
occurrences of which are the entities.
26
METHOD MANUAL
Entities of a similar type can be described by the same attributes. For example, customer
Moore and customer Miller are grouped under the Customer entity type; item 4710 and item
4712 are grouped under the Item entity type. Entity types are displayed as rectangles in the
ERM (see the figure below). In the following, entity types are indicated by capitalized text.
Figure 22: Examples of entity types
Attributes are properties describing entity types.

Attribute occurrences are specific values of attributes of individual entities. For example,
customer 1235 can be described by attribute occurrences such as Miller, Peter, and Munich.
The relevant attributes are Name, First name, and City.
Attributes are usually represented by an oval or a circle. In the following, attributes are
represented by ovals. The following figure shows examples of attributes for the CUSTOMER
entity type.
Figure 23: Examples of attributes of the 'Customer' entity type
Entity types and attributes are often hard to distinguish and can sometimes only be
determined from the context of the modeling procedure. For example, a customer address
can be understood as an entity and not as an attribute of CUSTOMER. In this case, a separate
entity type ADDRESS would be modeled with a relationship to CUSTOMER. A helpful criterion
27
METHOD MANUAL
for specifying whether you are dealing with an entity type or an attribute is the fact that
entities have attributes, while attributes cannot have their own attributes. An attribute that is
created in an ERM and is to be described by further attributes later on thus becomes an entity
type. Whether or not an object will have relationships with other entity types is another
helpful question. If yes, the object under consideration is an entity type as well.
A relationship is a logical link between entities.
Therefore, the existence of relationships directly depends on the existence of entities.
If similar relationships are grouped into sets, these are referred to as relationship types.
For example, a possible relationship type between SUPPLIER and PART is SUPPLIES. In the
following text, relationship types are also indicated by capital letters. In an ERM, relationship
types are displayed as diamonds and are linked with entity types using connections (see the
following figure).
Figure 24: Example of a relationship type
Often, only one direction of reading relationship type names results in viable connections. The
example above illustrates the relationship Supplier supplies Part. In the opposite direction,
this would read Part supplies Supplier, which is not suitable. If you cannot determine the
particular read direction, carefully select superior terms.
Various kinds of relationship types can be distinguished. The distinguishing criteria are the
number of entity types linked by relationship types, and the complexity of a relationship.
Thus, unary, binary, or n-ary relationships may exist between entity types.
The complexity or cardinality indicates how many entities of one entity type may be
connected with an entity of another entity type.
The relationships to be distinguished are illustrated in the following figure (see Scheer,
Business Process Engineering, 1994, p. 34).
There are four different types of relationships (cardinalities):
 1:1 relationship,
 1:n relationship,
 n:1 relationship,
 n:m relationship.
In a 1:1 relationship, each entity of the first set is assigned to exactly one entity of the second
set.
In a 1:n relationship, each entity of the first set is assigned to exactly one entity of the second
set, but each entity of the second set may be connected with multiple entities of the first set.
28
METHOD MANUAL
An n:1 relationship means the same, but in reverse order.

In an n:m relationship, multiple entities of the second set are assigned to each entity of the
first set and vice versa.
Figure 25: Cardinalities of relationships between two entity types
The cardinalities of the relationship type (Complexity attribute type) are shown at the
connections of the entity relationship model.
Figure 26: Representation of cardinalities in the ERM
The cardinality on an entity specifies for the entity type in question the maximum number of
relationships of a specific relationship type it may have. In the n:1 relationship shown in the
above figure, this means that a company of the COMPANY entity type may have multiple
ASSIGNED relationships because a company consists of multiple plants, whereas a specific
29
METHOD MANUAL
plant may only have a maximum of one ASSIGNED relationship as it must be uniquely
assigned to a company.
Chen’s original work poses a different interpretation of cardinality. However, the notation
used in this manual allows for clearer specifications, particularly when illustrating
relationships between multiple entity types. In order to avoid confusion, Chen's original work
is not discussed in detail here.
Due to the fact that relationships between entities of one entity type are allowed, two parallel
connections may exist between an entity type and a relationship type. These connections can
be distinguished by assigning role names. The following figure illustrates recursive
relationships. A superior part consists of various subordinate parts. A subordinate part, in
turn, may also be used as a component in various superior parts.
Figure 27: ERM for a bill of materials
Both entity types and relationship types can be described by attributes (see the figure below).
The value ranges of attributes are called domains.
Assignments of domain elements to elements of entity or relationship types are also
relationships and can be represented by a connection named accordingly.
A 1:1 relationship must exist between an entity type and at least one domain. The values of
this domain uniquely identify individual entities. Therefore, they are called the key attributes
of the entity type.
In the example shown in the figure below (see Scheer, Business Process Engineering, 1994,
p. 33), the entities of CUSTOMER are uniquely identified by the Customer ID key attribute.
Relationships are identified by merging the key attributes of all linked entities. Thus, the key
attributes of the RESIDES AT relationship type are Customer ID and Address ID.
30
METHOD MANUAL
The descriptive attributes of the relevant data objects are defined by values derived from
domains having a 1:n relationship to entity types or relationship types.
Figure 28: Assignment of attributes in the ERM
3.2.1.2 ERM - eERM extensions

In the last few years, Chen's base model has been substantially extended. This manual will
discuss only those extensions that are significant for modeling the data view in the ARIS
concept.
3.2.1.2.1 Design operators added

Design operators provide formal support in creating a data model. Their use ensures
systematic creation of data structures and provides the person who looks at an existing data
structure with insights into the design process. Based on existing terms, new terms are
developed by using design operators. This process is an intellectual procedure running at the
level of business management knowledge. The examination of business management facts in
terms of data structures either entails that known structures are changed based on new
approaches, or that entirely new conclusions are drawn.
Of the numerous and various approaches for extending ERM modeling, four basic design
operators have become accepted (see Scheer, Business Process Engineering, 1994, p. 35 et
sqq.):
 Classification,
 Generalization,
 Aggregation, and
 Grouping.
31
METHOD MANUAL
CLASSIFICATION
Through classification, objects (entities) of the same type are identified and assigned to a
term (entity type). Two objects are identical if the same properties (attributes) are used to
describe them.
Classification thus results in the previously described identification of entity types.
Figure 29: Classification of customers
GENERALIZATION/SPECIALIZATION
Generalization means that similar object types are grouped under a superior object type.
As shown in the following figure, the Customer entity type and the Supplier entity type are
generalized to form the generic term Business associate. Properties (described by
attributes) that both source objects share are transferred to the generalized object type.
Thus, only those attributes in which the source object types differ are left to be described.
The formation of the new entity type Business associate is graphically represented by a
triangle, also called an 'is a' relationship.
Specialization is the breakdown of a generic term into subterms (Business associate is split
into Customer and Supplier).
Specialization is the reverse of generalization. The specialized objects inherit the properties of
the generalized object. Apart from these inherited attributes, the specialized object types
may have their own attributes. Graphically, specialization and generalization are represented
in the same way.
For this reason, the links in the illustration are not drawn as arrows indicating a direction.
Figure 30: Generalization/Specialization
While specialization primarily supports a top-down procedure when creating a data model,
generalization is used to support a bottom-up procedure.
32
METHOD MANUAL
Within the scope of specialization, the completeness and disjunction (alternative) of the
subsets formed can be specified as they are created.
Non-disjoint subsets are characterized by the fact that the occurrence of an object may exist
in one subset as well as in another. In the above example, a customer may also be a supplier.
If an occurrence can be allocated to precisely one subset only, these sets are disjoint.
Complete specialization describes the fact that all specialized object types that meet a
specific specialization criterion are listed for a generalized object type. For example, when
specializing the Human being entity type the Female and Male entity types can be listed.
Thus, specialization in terms of Gender is complete.
Figure 31: Complete specialization
Combining these criteria results in the following four occurrences used for specifying a
generalization/specialization in more detail:
 disjoint/complete,
 disjoint/incomplete,
 non-disjoint/complete,
 non-disjoint/incomplete.
AGGREGATION
Aggregation is the formation of new object types by combining existing object types. The new
object type can be carrier of new properties.
33
METHOD MANUAL
In the ERM, aggregation is expressed by the formation of relationship types (see the following
figure). Aggregating the Production order and Routing entity types forms the new object
Order routing.
Figure 32: Example of an aggregation
The aggregation operator can also be applied to relationships. An existing relationship type is
then treated as an entity type and can thus become the starting point for creating new
relationships. An example illustrating this is shown in the following figure.
In a first aggregation step, the Order routing relationship type is formed from the
Production order and Routing entity types. The production order number (PONO) and
routing number (RNO) key attributes form the complex key of the order routing. Now,
multiple operations can be assigned to the order routing. Therefore, the Order operation
relationship is formed between the Order routing relationship type and the Operation entity
type. As relationships can be created only between entity types, the original Order routing
relationship type must be reinterpreted. In the following figure, this is illustrated by a framed
diamond. This reinterpreted relationship type thus formed is treated as a 'normal' entity type.
To graphically illustrate the formation of the relationship type, the connections of the entity
types participating in that formation are drawn to the diamond. The outgoing connections of
the reinterpreted relationship type that form new relationships are drawn only to the edges of
the rectangle and do not touch the diamond inside the symbol.
Although, as a general rule, it is possible to replace the complex keys with simple keys,
maintaining complex keys is useful in terms of tracing the data model's creation.
Figure 33: Aggregation with reinterpreted relationship types
34
METHOD MANUAL
In an ERM, a complex structural context is split into a transparent structure. As the relation to
the overall structure might become obscured, complex objects in the form of Cluster/Data
models are introduced.
A Cluster/Data model is the logical view of multiple entity types and relationship types of a
data model that are required for describing a complex object.
Besides entity types and relationship types, Cluster/Data models themselves can be part of a
Cluster/Data model. Unlike entity and relationship types, Cluster/Data models can be
arranged in any hierarchy and thus mainly supports a top-down procedure in the process of
creating data models. However, forming Cluster/Data models may also be very helpful when
combining and consolidating submodels during a bottom-up approach.
The following figure graphically displays a Cluster/Data model.
Figure 34: Data cluster (graphic symbol)
Figure 35: Data cluster view of multiple objects
The Cluster/Data model represents a logical view of multiple entity types and relationship
types. The Customer, Time, Customer order header, Item, and Customer order item entity
types and relationship types are required to describe the complex Customer order object.
GROUPING
Grouping forms groups from the elements of an entity set.
For example, in the following figure, all Operating resources are combined into an Operating
resources group. The operating resources group is an independent object which can be
35
METHOD MANUAL
described more precisely by additional attributes (name of the operating resources group,
number of operating resources) not contained in the individual operating resources. Other
examples are the grouping of workstations into departments or the combination of order line
items into orders.
Figure 36: Grouping
3.2.1.2.2 Extension of cardinalities

When specifying cardinalities, so far only the upper limit for the admitted number of
relationship occurrences was indicated. For example, the cardinalities in the following figure
indicate that a project can be assigned a maximum number (m) of employees and one
employee can participate in a maximum number (n) of projects.
Figure 37: Upper/Lower limit (1)
Besides the upper limit, the lower limit specifying the minimum number of relationship
occurrences may also be of interest. For this purpose, the cardinalities can be expressed as a
letter pair (a,b), for example, (see Scheer, Business Process Engineering). The letter pair (a1,
b1) in the following figure indicates that every project can participate in at least a1 and at
most b1 relationship occurrences of the works in type, which means that every project can
be assigned at least a1 and at most b1 employees. The other letter pair (a2, b2) indicates that
one employee can participate in at least a2 and in at most b2 projects.
Thus, every relationship is defined by two degrees of complexity (minimum, maximum). The
lower limit often has the values 0 and 1, whereas the value range for the upper limit is defined
as 1 <= max <= * (where * is 'any number').
A lower limit of min = 0 means that an entity may participate in a relationship, but does not
necessarily have to. A lower limit of min = 1 indicates that an entity must participate in at least
one relationship.
36
METHOD MANUAL
In the following figure, the lower limits indicate that an employee may participate in a
relationship, but does not necessarily have to (min = 0), while a project has to participate in at
least one relationship (min = 1). What is expressed here is that there can be employees who
are not assigned to a project. In turn, however, every project must be assigned at least one
employee.
If minimum values are equal to 0 or 1 and maximum values are equal to 1 or *, the following
four cases of a (min,max) notation can be distinguished: (1,1), (1,m), (0,1), and (0,m).
Alternatively, the following abbreviated notation can be used (see Schlageter/Stucky,
Database systems, 1983, p. 51):
 1 (corresponds to (1,1))
 c (corresponds to (0,1)),
 m (corresponds to (1,m)),
 cm (corresponds to (0,m)).
The following figure shows the previous graphical example using the abbreviated notation.
37
METHOD MANUAL
3.2.1.2.3 Identification and existence dependency

The method of extending cardinalities via the specification of lower and upper limits as
discussed in chapter ERM - eERM extensions (page 31) enables certain dependencies
between data objects to be defined.
By definition, relationship types and reinterpreted relationship types do not exist
autonomously, but come into being due to the existence of the entity types they link. This
means that they depend on other entity types in terms of both identification and existence.
In addition, there are entity types that depend on the existence of other entities even though
they have their own key attribute. These dependencies may be the result of a grouping
operation, for example. Thus, in the example of the following figure, a department requires at
least one assigned workstation, while defining a workstation, in turn, implies that it be
assigned to a department. As shown in the following figure, these existence-related
dependencies are expressed by specifying the complexity. A (min, max) notation uses (1,1)
and (1,*). The definition of existence-related dependencies within the data model results in
conditions for the referential data integrity when implemented. In other words, complying
with these conditions ensures that the consistency of the database contents is preserved
even after certain transactions have been performed. In the example below, this means that a
department can be deleted only if all workstations assigned to this department are also
deleted.
Figure 41: Existence dependency
38
METHOD MANUAL
3.2.1.2.4 Modeling technical terms used in a company -

Technical terms model
In modeling, and especially in data modeling, a difficulty that frequently occurs is the variety
of terms used for information objects in large companies. For example, the purchasing
department's definition of the term order differs from the production department's definition
of the same term. However, acceptance of the information gathered can be substantially
increased by the use of consistent terminology throughout the company or the department.
For this reason, ARIS Method provides the so-called Technical terms model that may be used
for managing the various terms in the form of a synonym management for data objects, as
well as for specifying the relationships that exist between the objects of data models (entity
type, relationship type, ...) and the technical terms used within the company.
In order to represent these relationships, the 'Technical term' object type was introduced. You
can thus assign multiple technical terms to every information object of the data model. The
following figure illustrates an example.
Figure 42: Technical terms (1)
39
METHOD MANUAL
Technical terms can be interrelated and may be arranged in a hierarchy. The following figure
illustrates how connection types are used between technical terms.
Figure 43: Technical terms (2)
The technical terms defined in the technical terms model can also be used in other model
types that contain information objects, for example, in process chains for illustrating a
function's input/output data.
40
METHOD MANUAL
3.2.1.2.5 eERM attribute allocation diagram

Data models in the form of eERMs, even if they display entity types and relationship types
only, mostly have a rather complex structure. If ERM attributes were included in these models,
they would no longer be legible.
eERM attribute allocation diagrams enable you to assign ERM attribute allocations to every
entity type and relationship type in a separate model. The object type of the eERM (entity type
or relationship type) can be included in this model as an occurrence copy, and the
relationships to the ERM attributes can be modeled. It is possible to distinguish whether the
linked ERM attribute is a key attribute, a foreign key, or a descriptive attribute. The following
figure illustrates an example.
Figure 44: Allocation of ERM attributes to an entity type
This model type not only enables individual ERM attributes to be represented and allocated,
but also displays attribute type groups and their allocations.
An attribute type group represents a group of ERM attributes of an entity type that are closely
related semantically. For example, ERM attributes of an entity type that, in their entirety, form
a secondary key can be combined to form an attribute type group.
Attribute type groups are represented as follows:
Figure 45: Representation of an attribute type group
A list of relationships that are available in an ERM attribute allocation diagram is provided in
the ARIS Method Reference manual on your installation media.
41
METHOD MANUAL
3.2.1.2.6 IE data model

The IE data model complies with the data modeling notation of the Information Engineering
Facility (IEF) CASE tool by Texas Instruments Inc.
It does not provide proprietary object types for relationships between entity types.
The following figure illustrates an example of a data model in IE notation.
Figure 46: Data model in IE notation
42
METHOD MANUAL
3.2.1.3 Summary of the main terms and forms of

representation of the eERM
The terms and representation forms of structural elements and design operators featured by
the extended entity relationship model (eERM) are summarized in the following figure (see
Scheer, Business Process Engineering, 1994, p. 45).
Figure 47: eERM: Terms and forms of representation
43
METHOD MANUAL
3.2.1.4 Modeling the Data Warehouse structure

The Data Warehouse structure diagram describes the structure of a Data Warehouse.
Primarily, the diagram is a static description, that is, it illustrates the interrelation of data as
well as their locations. In the ARIS architecture this type of description is realized in the data
view. The focus lies on the interrelation and arrangement of information. The data dimensions
are described by the info cube. The interplay of the dimensions is represented by the star
schema (see the following figure). A dimension can serve as a key for connecting other
dimensions. The objects of individual dimensions can have specific values, which are
cataloged in fact tables and are exactly defined by KPIs. Dependencies are described in
dimension tables listing their key attributes and characteristics. The hierarchical interrelations
of the features are described by tree structures. Finally, dimensions can be allocated to
master data tables using the structure diagram.
Figure 48: Data Warehouse in the star schema
44
METHOD MANUAL
3.2.1.5 Project management data - Information carrier

diagram
The information carrier diagram is an optional component for project management with ARIS.
It belongs to the requirements definition of the data view and is used to record incoming and
outgoing data, such as documents, logs, or ARIS models.
The required documents (for example, word processing files) can be displayed explicitly and
accessed from within ARIS via the Link 1 to Link 4 attributes.
Figure 49: Information carrier diagram
45
METHOD MANUAL
3.2.2Implementation - Table diagram

The table diagram is used to describe the tables and fields of a database system. The
following figure shows a graphical representation of tables and fields.
Figure 50: Graphical representation of table and field
The individual fields assigned to this table can be shown for each table. For further
specification, a sorting index and the domain can be assigned to each field. The following
figure illustrates an example.
Figure 51: Field allocations
Multilateral relationships between tables and relations or entity types may occur. These
relationships can be illustrated in the table diagram by selecting the relevant connections.
Due to the fact that converting or documenting database tables and fields used in a company
does not necessarily require the definition of a relational schema, both the realization
relationships between relations (or attributes) and tables (or fields) and between entity types
(or ERM attributes) and tables (or fields) can be represented.
46
METHOD MANUAL
The representation may focus either on the relations and attributes realized by the tables and
fields, or - leaving out the relational definitions – on the entity types, relationship types, and
ERM attributes illustrated by the tables and fields. Both types of representation are illustrated
in the following figure.
Figure 52: Allocation of requirements definition and design specification objects
To be able to define the exact location of specific tables and fields in a company, it must be
possible to define every single specimen of a table. The same applies when the privileges for
accessing tables and fields are to be specified for organizational units. The Table object type
introduced earlier determines the logical structure of a physical table and its fields at the
Type level. However, multiple specimens of every table thus defined may exist on different
media or at different locations in a company. This fact can be represented using the Table
(specimen) and Field (specimen) object types.
47
METHOD MANUAL
With the help of these objects, the specimen count of a table or a field can be determined
exactly. The following figure shows this aspect.
Figure 53: Table specimens
A list of objects and relationships that are available in a table diagram is provided in the ARIS
Method Reference manual on your installation media.
48
METHOD MANUAL
3.2.3 Role assignment diagram (RAD)

The SAP® reference model is represented using EPCs. These EPCs illustrate the business
processes at different levels of detail. In the EPCs with the highest level of detail, which the
SAP® terminology refers to as processes, procedures of processing executables in the SAP®
system are modeled. These processes can be assigned both roles and executables.
In ARIS, this is done in the function allocation diagram where the EPC containing the modeled
process must be assigned to the corresponding function definition. Thus, the function
allocation diagram shows which roles are necessary to run the executables. However, since
there are no direct relationships between roles and executables, no decision can be made as
to which executable a role is responsible for if there are multiple roles. For this reason, the
assignment of roles to executables takes place in the role assignment diagram (RAD). One role
is displayed per column. Executables are placed in columns, which creates implicit
relationships.
The information can be used during R/3 implementation to create the necessary user profiles
and authorization concepts for operating the SAP® system.
Figure 54: Role assignment diagram (RAD)
49
METHOD MANUAL
3.3 Organization view
3.3.1.1 Organizational structure of companies

Companies are complex social structures that are divided into manageable units. To deal with
the given complexity, patterns are defined and rules established. The result of this process is
called organization. Until recently, the role of organizational considerations as an aspect of
developing information systems has rarely been the object of research. But newer business
concepts, such as Lean Production, Lean Management, or CIM are closely allied with the
organizational setup of the area of consideration. For this reason, the ARIS concept provides
an independent descriptive view on organization.
In a company's organizational design, a distinction can be made between the organizational
structure and the process organization.
The organizational structure encompasses the rules by which the company is statically
structured. The process organization contains the rules relating to the tasks to be performed
by the company. This task-related structure in the sense of distributing functions to task
performers is dealt with in the control view of the ARIS house. The organization view basically
looks at a company's organizational structure.
The design of an ideal company organization with the aim of reducing coordination efforts to
a minimum depends on the company's business environment and objectives. Therefore, it is
not possible to define universally valid ideal organizational structures that may serve as
reference structures.
The structure of organizational units depends on various criteria.
A very common criterion is the functional structure. One company function (procurement,
production, finance and accounting, sales) is given responsibility for all products and sectors.
The advantage of this approach lies in a high level of staff specialization, but it also entails a
multiplication of efforts concerning communication and coordination between the functional
areas.
Both the design and use of information systems had their focus on this functional breakdown
of companies for a long time. However, looking at integrated process chains in the sense of
cohesive processing of similar data objects makes it difficult to establish interrelationships
between individual functions for such a structural design.
For this reason, the discussion of integrated data processing resulted in the demand for a
consistent base of data aimed to support the various functions. However, the intended
integration of functions counteracts the desired effect of reducing complexity via the
functional structure.
50
METHOD MANUAL
Hence, when dealing with the aim of achieving functional integration, other criteria of
organizational breakdown are frequently applied.
For example, the breakdown may focus on criteria such as sectors or products. The following
figure shows a breakdown by product (see Scheer, Business Process Engineering, 1994, p. 26
et sqq.).
In a sector-based organizational structure the organizational units are specified in
accordance with the local distribution of the company or corporate division. This kind of
structure is particularly suitable for sales functions because regional factors such as varying
legislation can be dealt with more appropriately.
Figure 55: Organizational breakdown by product
A product-based organizational structure defines organizational units for products or product

groups. Within a product group, a maximum number of functions that are relevant for this
particular product group are integrated. The aim of this procedure is to reduce the
communication effort that functional structures entail. However, this results in the necessity
of information exchange between the product group-based subsystems.
To counteract these effects, hybrid organizational forms are often created. The following
figure illustrates this with an example of Purchasing (see Scheer, Business Process
Engineering, 1994, p. 26 et sqq.).
Figure 56: Hybrid organizational forms
Using a purely functional structure would imply that a central purchasing department was
responsible for all product groups. In this case, synergy effects between the product groups
may be exploited, but major coordination problems would arise from carrying out a
purchasing procedure across all subfunctions. When the purchasing functions are split up
51
METHOD MANUAL
according to the various product groups, individual purchasing departments must be

established for every product group to carry out all purchasing functions. When selecting
suppliers or negotiating framework contracts, for example, synergy effects may only be
obtained at the expense of high coordination efforts.
In the breakdown illustrated in the above figure, those purchasing functions for which high
synergy effects are expected are broken down functionally, that is, they are carried out by a
central purchasing department. Functions that must comply with specific requirements and
restrictions stipulated by individual product groups are divided by product group in an
object-oriented approach. These functions can thus be integrated in the process flow of the
individual product groups immediately. This means that the operational handling of processes
takes place in decentralized units, while the relationships among the decentralized units are
dealt with at the superior, central coordination level.
These flexible organizational forms are given special emphasis in the ARIS concept due to
their strongly process-oriented approach. The formation of organizational structures to which
various breakdown criteria are applied at the same time is a claim put forward especially by
accounting-based approaches, such as the profit center concept.
52
METHOD MANUAL
3.3.1.2 Organizational chart

A typical way of representing organizational structures is the organizational chart. In this
chart, organizational units (as task performers) and their interrelationships are represented
according to the structuring criteria selected.
Organizational units are the performers of the tasks that must be carried out in order to
achieve the business objectives.
Organizational units are linked via relationships. The following figure shows an example.
For a more precise specification of the hierarchical relationships, a distinction is made
between various connection types that may exist between organizational units. In this
context, a connection may have one of the following meanings:
 is technical superior to
 is disciplinary superior to
 is a component of
If functional responsibilities are recorded, the organizational chart illustrates the distribution
of the business tasks.
Figure 57: Organizational chart
The Position object type is provided to represent individual positions within the company, for
example, positions for which descriptions exist. This object type is illustrated in the following
figure. Multiple positions can be assigned to an organizational unit. The meaning of the
connections corresponds to the interaction between organizational units.
53
METHOD MANUAL
Individual persons in the company can be assigned to the positions and organizational units.
ARIS offers separate objects for persons, which is illustrated in the following figure. The
assignment of an individual person to an organizational unit shows that this person is
assigned as an employee to this organizational unit, whereas the assignment to an individual
position defines the current staffing in the company. An example is shown in the following
figure.
Figure 58: Organizational chart with position and person assignment
Organizational units and persons can be typified. For example, you can define for each
organizational unit whether it is a department, a main department, or a group. Persons can be
assigned to the Department head, Group leader, or Project manager roles, for example.
54
METHOD MANUAL
This typification is represented by the Organizational unit type and Role objects provided
for this purpose. An example of the typification of organizational units and persons is shown
in the following figure.
Figure 59: Person types
Using these object types enables you to depict general business rules derived from concrete
organizational units or employees. Thus, in process chains, it is possible to define that only
specific roles may carry out a function or have access to an information object.
55
METHOD MANUAL
The modeling of the organizational structure of the company is the starting point for the
network topologies to be defined at the design specification level, which are to support this
organizational structure as best as possible. Included in the definition of the network topology
are network connections and network nodes, which may be found at particular locations of
the company. The location of an organizational unit is therefore the most important link
between requirements definition and design specification of the organization view. Thus, the
location of every organizational unit is already defined in the requirements definition. An
example is shown in the following figure.
Figure 60: Location assignments
Locations may be arranged in any required hierarchy. A location can be an entire plant, a
building or, for a more detailed examination, an office through to an individual workstation in a
room. This makes it possible, in the design specification, to assign network nodes of a network
to individual workstations of the organizational unit. For example, the design specification
may stipulate that a total of 3 network nodes must be available in a particular office (room
202).
56
METHOD MANUAL
The following figure shows an example of a location hierarchy.
Figure 61: Location hierarchies
57
METHOD MANUAL
3.3.2 Design specification - Network topology

The company's organizational structure as represented in the organizational chart can now
be supported using communication and information system infrastructures. The structural
requirements for these information systems can generally be defined in the design
specification in the form of network topologies.
In a first step, various network types can be incorporated in a Network topology model.
A network type typifies individual network specimens that are based on precisely the same
technology.
The following figure shows an example of a network type:
Figure 62: Graphical representation of a network type
Network types can be interlinked and, since they are logical constructs, they can also be
arranged in a hierarchy.
Network node types and network connection types can be assigned to every network type.
Thus, technological restrictions resulting from the choice of one particular network type for a
company can be identified immediately. It is possible to show for every network connection
type which network node types it may end in.
When speaking of hardware component types, the term may refer to either network hardware
for implementing the defined network structures, or hardware component types that can be
connected to network node types.
As with application system or network types, hardware component types do not represent
individual specimens of hardware components that can be identified, for example, by
inventory numbers assigned by the company. Instead, they typify all hardware components
that are based on the same technology. Hardware component types may be arranged in any
required hierarchy.
A hardware component type typifies individual specimens of hardware components that are
based on precisely the same technology.
Together with network node and connection types, a kind of reference model of the network
topology can now be created. This model indicates which hardware component types can be
used for realizing specific network connection types or network node types. An example of a
connection type might be a particular type of transmission cable. Besides, it is possible to
show which hardware component type can be connected to which network node type.
58
METHOD MANUAL
Network node types may also have relationships to hardware component types that are used
to create node types. An example is shown in the following figure.
Figure 63: Network topology
The link between network topology and the objects of the requirements definition is
established via two approaches.
On the one hand, for every single hardware component type the organizational unit or
position responsible for it can be specified.
On the other hand, it is possible to define for each network type, network node type, network
connection type, and hardware component type at which location within the company they
may be found. Thus, the location is the central link between the requirements definition and
the design specification of the organization view.
A list of object and relationship types that are available in a network topology model is
provided in the ARIS Method Reference manual on your installation media.
59
METHOD MANUAL
3.3.3 Implementation
3.3.3.1 Network diagram

The network diagram illustrates the realization of the network topology defined in the design
specification.
The networks that exist in the company are recorded by means of the Network object. It is
possible to specify for each network the network nodes and network connections it consists
of.
The exact location of every network, network node, and network connection within the
company can be indicated. A location can be an entire plant, a specific building, a complex of
buildings, an office, or an individual workstation.
Figure 64: Network diagram with location assignment
60
METHOD MANUAL
The network diagram also records the hardware components used to realize each network
connection and network node. Besides, it is possible to illustrate the structure of every single
hardware component. On the one hand, hardware components are used to form network
connections and network nodes; on the other hand, they can be connected to network nodes.
This relationship can be represented in the network diagram, as well. For every object of the
specimen level, the relationship to the corresponding object of the design specification level
can be modeled. This way it is possible to express, for example, that the network in the Port
St. plant is of the FDDI ANSI X3.139 type.
Figure 65: Network diagram with hardware components and location assignment
Thus, the network diagram establishes the links to the design specification via type
allocations, as well as the links to the requirements definition via the allocation of network
components to specific locations.
A list of object and relationship types that are available in a network diagram is provided in the
ARIS Method Reference manual on your installation media.
61
METHOD MANUAL
3.3.3.2 Material flow modeling - Technical resources

To illustrate the material flow in process models (EPC (material flow), material types are
allocated to individual functions of the business process in the form of function input or
output. Similar to the allocation of information objects to functions (representation of
information transformation by functions), this allocation represents the transformation of
input material types to output material types. Additionally, the technical resources required
for transforming materials can be recorded in the process chains. In this context, a distinction
is made between operating resources, warehouse equipment, transport systems, and
technical operating supplies.
In the Technical resources model type you can arrange technical resources in a hierarchy,
assign a type to them, and classify them. The following object types are available for this
purpose:
OPERATING RESOURCE
Operating resources are specimens of various operating resource types that are available for
a company to perform its tasks. Operating resources are often identified by inventory
numbers (for example, number of a production plant).
OPERATING RESOURCE TYPE

An operating resource type typifies individual operating resources that are based on precisely
the same technology.
OPERATING RESOURCE CLASS

Similar operating resource types can be combined to form an operating resource class. The
similarity can be based on different classification criteria. Thus, an operating resource type
can be assigned to multiple operating resource classes.
WAREHOUSE EQUIPMENT
Warehouse equipment items are specimens of various warehouse equipment types that are
available for a company to perform its tasks. Warehouse equipment items are often identified
by inventory numbers.
WAREHOUSE EQUIPMENT TYPE

A warehouse equipment type typifies individual warehouse equipment items that are based
on precisely the same technology.
62
METHOD MANUAL
WAREHOUSE EQUIPMENT CLASS

Similar warehouse equipment types can be combined to form a warehouse equipment class.
The similarity can be based on different classification criteria. Thus, a warehouse equipment
type can be assigned to multiple warehouse equipment classes.
TECHNICAL OPERATING SUPPLY

A technical operating supply is an individual specimen of a technical operating supply type. In
general, it can be identified by means of an inventory number.
TECHNICAL OPERATING SUPPLY TYPE

A technical operating supply type typifies individual technical operating supply items that are
based on precisely the same technology.
TECHNICAL OPERATING SUPPLY CLASS

Similar technical operating supply types can be combined to form a technical operating
supply class. The similarity can be based on different classification criteria. Thus, a technical
operating supply type can be assigned to multiple technical operating supply classes.
TRANSPORT SYSTEM
A transport system is an individual specimen of a transport system type. In general, it can be
identified by means of an inventory number or a plant number.
TRANSPORT SYSTEM TYPE

A transport system type typifies individual transport systems that are based on precisely the
same technology.
TRANSPORT SYSTEM CLASS

Similar transport system types can be combined to form a transport system class. The
similarity can be based on different classification criteria. Thus, a transport system type can
be assigned to multiple transport system classes.
Due to the various possibilities of creating hierarchies in the Technical resources model type
it is possible to describe the structure of complex technical installations. For example, the
components of a complex production plant and their interrelationships can be illustrated this
way.
63
METHOD MANUAL
In addition to the modeling options mentioned above, there is also the possibility of defining
location allocations and organizational responsibilities for technical resources. To do this, the
Location, Organizational unit, Group, Position, and Person object types which you already
know from the Organizational chart model type are available. These object types can be
linked to the Operating resource, Warehouse equipment, Technical operating supply, and
Transport system object types.
An example of a Technical resources model type is shown in the following figure.
Figure 66: Example of a 'Technical resources' model
64
METHOD MANUAL
3.4 Process view

The relationships between the objects of the data, organization, and function views are
analyzed in the control/process view. The relationships to be analyzed result from the
connections between the views.
First, the relationships between two views are examined, then diagrams are introduced,
illustrating the relationships between all three views.
3.4.1.1 Linking functions with organization - EPC

Linking the function view with the organization view serves to allocate the functions defined
in the function tree to the task performers (organizational units) of the organizational chart.
This allocation defines an organizational unit's responsibility and decision-making power with
regard to its allocated functions. Looking at how these organizational allocations are realized
in a process chain (business processes) enables you to identify the degree of functional
integration, that is, the number of business process functions that are to be processed by an
organizational unit.
65
METHOD MANUAL
The following figure shows an example of the allocation of organizational units to functions.
In this figure, the function placed on the left is assigned the organizational unit responsible
for its execution. The functions' superior or subordinate positions in the hierarchy are
illustrated in the function view (function tree), and the relationships between the
organizational units are shown in the organization view (organizational chart). Therefore,
there is no need to define them at this point.
Figure 67: Allocation of organizational elements to functions
66
METHOD MANUAL
3.4.1.2 Linking functions with data
3.4.1.2.1 Event control - Event-driven process chain

(EPC)
The operational sequence of functions in the sense of business processes is represented in
process chains. The start and end events of every function can be specified. Not only do
events trigger functions, they also represent results of functions.
An event describes the fact that an information object has taken on a business
management-relevant state that controls or influences the progression of the business
process. Events trigger functions and are the results of functions. Unlike a function, which is
a time-consuming task, an event relates to one point in time.
The change in state of an information object may refer to the first occurrence of this
information object (for example, Customer order received), or to a change in state in the
sense of a change in status recorded in an attribute occurrence (for example, Offer is
refused). Since information objects and attributes are described in the ARIS data view, the
event-driven representation of process chains forms a link between the data view and the
function view and is thus attributed to the ARIS control view.
Events are graphically represented as hexagons. The name should not only contain the
information object itself (Order), but also its state change (received). The following figure
illustrates events.
Figure 68: Events (graphical representation)
Events trigger functions and are the results of functions. By arranging events and functions
in a sequence, so-called Event-driven process chains (EPCs) are created. An event-driven
process chain (EPC) shows the chronological-logical operational sequence of a business
process.
67
METHOD MANUAL
An example of an EPC is shown in the following figure. Since events determine which state or
condition will trigger a function and which state will define the end of a function, the start and
end nodes of such an EPC are always events. Multiple functions can originate from one event
simultaneously, and a function can have multiple events as its result. A rule that is
represented by a circle is used to illustrate branches and processing loops in an EPC.
However, these connections do not only serve as graphic operators, but define the logical
links between the objects they connect.
Figure 69: Example of an EPC
68
METHOD MANUAL
Figure 70: Examples of rules
In the first example of this figure the start events are connected via an AND rule. This means
that the Release operation procedure is started only if the routing and the required
resources are available. Therefore, both events must have occurred before the procedure can
begin. The second example shows an exclusive OR connection using an XOR rule. The Check
supplier offer function may result in either acceptance or rejection of the quote. Both
results, however, cannot occur at the same time. Besides these two cases and links of the
'inclusive OR' type, more complex relationships are possible.
Thus, two different types of operators exist:
1. event operators and
2. function operators.
69
METHOD MANUAL
An overview of all possible event and function operators is listed in the following figure (see
Hoffmann, Kirsch, Scheer, 'Modellierung mit Ereignisgesteuerten Prozessketten' [Modeling
with event-driven process chains], 1993, p. 13).
Figure 71: Logic operators (rules)
70
METHOD MANUAL
In this context, special attention must be paid to the restrictions which exist for function
operators. Due to the fact that events cannot make decisions (only functions can do this), a
triggering event must not be linked using an OR or XOR operator.
Below, possible operators are explained using examples.
LINKING TRIGGERING EVENTS
AND RULE
Figure 72: AND operator for triggering events
The function can be started only after all events have occurred.
OR RULE
Figure 73: OR operator for triggering events
The function is carried out after at least one of the events has occurred.
71
METHOD MANUAL
EXCLUSIVE OR RULE (XOR RULE)
Figure 74: XOR operator for triggering events
The function is started after no more than exactly one event has occurred.
LINKING CREATED EVENTS
AND RULE
Figure 75: AND operator for created events
All events will occur after function execution is complete.
72
METHOD MANUAL
OR RULE
Figure 76: OR operator for created events
At least one of the events will occur after function execution is complete.
Figure 77: XOR operator for created events
No more than one event will occur after function execution is complete.
LINKING FUNCTIONS WITH CREATED EVENTS
73
METHOD MANUAL
AND RULE
Figure 78: AND operator of functions with created events
The event occurs only after all functions have been carried out.
OR RULE
Figure 79: OR operator of functions with created events
The event occurs after at least one of the functions has been carried out.
74
METHOD MANUAL
Figure 80: XOR operator of functions with created events
The event occurs after no more than exactly one function has been carried out.
LINKING FUNCTIONS WITH TRIGGERING EVENTS
AND RULE
Figure 81: AND operator of functions with triggering events
The event triggers all functions.
OR RULE
Events have no decision-making power. This operator is invalid.
75
METHOD MANUAL

Events have no decision-making power. This operator is invalid.
Besides being illustrated in the form of event-driven process chains, these branches can also
be represented in table form in the event and function columns of a process chain diagram.
Since functions are sorted sequentially in a process chain diagram, branches and processing
loops can be represented only in a rather complex and thus confusing manner.
76
METHOD MANUAL
3.4.1.2.2 Function allocation diagram (I/O)

In addition to the event control representation explained in chapter Event-driven process
chain (EPC) (page 67), the transformation of input data into output data and the
representation of data flows between functions also form a link between the data view and
the function view in the ARIS concept. The transformation of input data into output data can
be illustrated in so-called Function allocation diagrams (I/O). The figure below illustrates an
example of a function allocation diagram (I/O). The input data of the Determine delivery
date function are Parts data, Inventory data, Bill of materials data, and Shipping data.
Inquiry data serves as both input data and output data. Thus, a function allocation diagram
(I/O) consists of functions of the function view and information objects of the data view. The
arrows determine whether an information object is used only as input data, output data, or as
input/output data. More detailed specifications are possible, indicating, for example, that the
function has created or deleted an information object. Depending on the degree of detail,
information objects can be Cluster/Data models, Entity types or Relationship types, or
attributes of the data view.
Figure 82: Example of a function allocation diagram (I/O)
The example shown above illustrates the actual aim of function allocation diagrams (I/O),
which is to represent a function's input/output data.
77
METHOD MANUAL
Besides a function's input/output data, events and all other objects that can be allocated to
the functions in an EPC are available. Thus, the user is able to restrict the modeling of process
chains in EPC diagrams to events and functions, and to assign each function a function
allocation diagram (I/O) containing all additional relationships the function has. This allows for
much clearer representations of business processes and also explains the use of a new name
for this model type. The figure below illustrates an example of this more detailed
representation in a function allocation diagram.
Figure 83: Detailed representation of the function allocation diagram
78
METHOD MANUAL
Besides this method of representing data transformation in the form of function allocation
diagrams (I/O), it is also possible to include this information in an EPC. The figure below
illustrates an example. In this case, the links between functions and information objects play
the same role as in function allocation diagrams (I/O). However, including them in a process
chain with numerous branches may result in a very complex representation.
Figure 84: EPC with input/output data
79
METHOD MANUAL
3.4.1.2.3 Event diagram

Events define the fact that the state of information objects has changed. Thus, every event
references particular information objects of the data model and defines the status of this
information object at a given point in time.
First of all, events are roughly specified in a top-down procedure (example: Order
processed). The next level of detail in process modeling involves the specification of detailed
events that, in certain combinations, cause the event to occur at the rough level. For example,
the occurrence of the events Feasibility checked, Order header registered, and Order
items registered can, in sum, define the Order processed status.
You can use the event diagram to display these event correlations at the rough and detail
modeling levels. For this purpose, an event at the rough level can be assigned an event
diagram displaying the events and the corresponding operators at the detail level (which
results in the formation of a hierarchy). Moreover, you can include information objects of the
data model in this model type and link them to the events. Thus you specify the event which
defines the state change of a given information object.
An example is shown in the following figure.
Figure 85: Example of an event diagram
80
METHOD MANUAL
3.4.1.3 Functions - Organization - Data
3.4.1.3.1 Value-added chain diagram

The value-added chain diagram is mainly used to identify the functions within a company that
are directly involved in the creation of a company's value-added. These functions can be
interlinked as a sequence of functions and thus form a value-added chain. The following
figure shows an example of a value-added chain diagram.
Figure 86: Value-added chain
In a value-added chain diagram, functions can be arranged in a hierarchy, similar to a function

tree. It always represents process-oriented superiority/subordination.
A value-added chain diagram not only enables you to express a superiority or subordination
of functions, it can also display the functions' links to organizational units and information
objects. When allocating organizational units to functions, as with process chains we
differentiate between a function's technical responsibility, its IT responsibility, and the actual
execution of a function.
A list of other relationships that are available in a value-added chain diagram is provided in
the ARIS Method Reference manual on your installation media.
3.4.1.4 Object-oriented modeling

For modeling in a UML environment, UML is available. All method-relevant information on UML
diagrams and UML elements is accessible directly via the ARIS UML Designer interface.
81
METHOD MANUAL
3.4.1.5 Process variants
3.4.1.5.1 Process selection matrix

The process selection matrix displays different process scenarios by assigning main
processes to individual scenarios.
The user can determine which functions of the scenario processes are to occur in the
company. For this purpose, all main functions (scenario functions) of an application system or
of an industry reference model need to be included as processes.
The following symbol types are available for modeling a process selection matrix:
 Scenario
 Process
 Main process
A scenario represents a scenario process in the selection matrix which arranges different
main processes in groups.
The process represents functions of the scenario process that are described in more detail in
the reference model by process models.
The main process represents the main functions in function trees to which the processes
(functions from the scenario processes) are assigned.
82
METHOD MANUAL
The following figure shows an example of a process selection matrix.
Figure 87: Process selection matrix (extract from the SAP AG R/3 reference model)
83
METHOD MANUAL
3.4.1.6 Material flow modeling

You can use EPCs to illustrate not only the information flow, but also the material
transformation. To represent a material flow within business processes, ARIS provides the
EPC (material flow) model type which is an extension of the EPC model type.
3.4.1.6.1 EPC (material flow)

In addition to the object types of an EPC, the following object types are available in the 'EPC
(material flow)':
 Material type
 Packaging material type
 Operating resource type
 Operating resource
 Technical operating supply type
 Technical operating supply
 Warehouse equipment type
 Warehouse equipment
 Transport system type
 Transport system
The Material type object type can be linked to the Function object type by means of an
incoming or outgoing connection. In the case of an incoming connection, the materials that a
function requires as input are defined. In this context, by selecting the corresponding
connection type, you can define whether the function uses none, part, or all of the material.
An outgoing connection specifies the material types created by the function.
Technical resources are required for material transformation. In process chains, you can also
link them to the Function object type. To specify alternative resources that may be available,
the requires alternatively connection type is provided in addition to the requires
connection type.
If materials are to be packaged during function execution, packaging material types are
needed. In order to specify the corresponding packaging material types, you can model a
relationship between the function and the required packaging material types.
84
METHOD MANUAL
The following figure shows an EPC (material flow) and the corresponding technical resource
types and packaging material types.
Figure 88: Extract from an EPC (material flow)
85
METHOD MANUAL
3.4.1.6.2 EPC (column/row display)

The following description also applies to the EPC (row display).
Most of the explanations on the EPC also apply to the EPC (column display) model type,
except that all symbols in this model are distributed over various columns. The advantage is
that this representation makes the EPC much easier to interpret. Organizational elements and
application systems are placed in the diagram header. All other symbols are placed in the
second row of each column.
A particular characteristic of all lane models (that is, models that are modeled in columns
and/or rows) is the automatic creation of invisible (implicit) relationships. For example, when
you model application systems and functions, the implicit relationship 'supports' is
automatically created in the default columns of the EPC (column display). Organizational
elements and functions are implicitly connected by a 'carries out' relationship. The user may
also add the following columns named after the implicit relationships:
 Contributes to
 Decides on
 Is IT responsible for
 Is technically responsible for
 Must be informed on cancellation
 Must inform about result of
 Must be informed about
 Accepts
 Has consulting role in
86
METHOD MANUAL
The following figure shows an example of an EPC (column display).
Figure 89: EPC (column display)
The difference between the EPC (column display) and the EPC (row display) lies in the
modeling direction. In the EPC (column display) modeling is performed from top to bottom, in
the EPC (row display) from left to right.
87
METHOD MANUAL
3.4.1.7 Other models
3.4.1.7.1 Business controls diagram

A business controls diagram displays potential risks for a process or function as well as risk
control methods.
A risk represents the possible danger of a defined process objective not being achieved.
Risk control is a general way of eliminating or minimizing risks.
Risk solution means implementing risk control for a risk.
The business controls diagram layout corresponds to a matrix or table. The abscissa shows
the potential process risks, and the ordinate shows the possible risk control methods. Risk
solutions are now inserted as operators between risk and risk control. Additionally,
organizational units (in the sense of user requirements) and documents, which also support
implementation of risk control for a risk, may be added to the model.
Figure 90: Example of a business controls diagram
This model type is generally used to describe SAP® standard processes. The model shows the
risks and risk control methods of an SAP® solution for the process being examined.
88
METHOD MANUAL
3.4.1.7.2 E-Business scenario diagram

The smooth execution of inter-company business processes is continuously gaining in
significance. Here, the focus of interest lies on the operational sequence of specific
procedures at the interfaces between companies on the one hand and at the interfaces
between companies and their customers on the other. The contacts need to take place in a
clear, quick, consistent, and direct manner.
Also, rapidly finding suitable business associates (from a corporate perspective) and providers
(from a consumer point of view) is becoming increasingly more important. Maximum
optimization of these processes results in a competitive advantage. The ideal platform for
supporting these bilateral relationships is the Internet. As the processes in the
above-mentioned environment are very complex, it is necessary to define the term
e-business.
E-business describes all computer-assisted processes involving two economic agents and
the attempt to gain added value by using new media.
Thus, e-business can mean simply acquiring an item using the Internet, or a highly complex
project involving two companies, or creating a Web site for a corporate presentation.
Relationships between companies are referred to as Business-to-Business (or B2B), while
relationships between companies and consumers are called Business-to-Consumer (or B2C).
The E-Business scenario diagram was developed to support e-business.
The ability to view a value-added chain in its entirety, that is, from the end user to each of the
companies involved in a procedure, provides a basis for developing optimization potential. The
objective is, for example, to improve the supply chain, to reduce procurement and
distribution costs, or to optimize the information system architecture. The contents
represented by the objectives can be modeled using this method.
The economic agents are arranged in the upper row of the diagram and referred to as
Business participants. The participating companies can be assigned using an organizational
chart. Here, interest centers on the individual processes that economic agents perform as
part of the overall process as well as the interfaces between these subprocesses. An
individual process is a business process that plays an important role in inter-company
cooperation and that can be assigned to the process model. The business process is
supported by application systems (business components), such as the R/3 system.
Even the roles of the employees involved in the process can be defined. These are referred to
in the model as Employee role.
The main feature of the interfaces is the transfer of process-specific information. The
information is gathered in business documents and can assume the form of an XML or HTML
document. The business document can also be assigned as a data model. As an alternative to
this object, the objects Money transaction (for representing a cash flow), Goods shipment
89
METHOD MANUAL
(for representing a flow of goods), as well as E-mail, Internet, Intranet, Extranet, and
Mobile phone (for specifying the technological aspects of the data transfer) can also be used.
All operational procedures relating to a company are modeled in the row below the business
participant, but in the same column.
Thus, column borders form abstract interfaces. These merit special attention, as they carry
the main potential for optimization, and it is therefore always beneficial to model them.
Explanation of terms: In the sample model below, OEM stands for Original Equipment
Manufacturer and MRP for Material Resource Planning Controller.
Figure 91: Example of an e-business scenario diagram for the motor industry
90
METHOD MANUAL
The sample model shows how a manufacturer, an importer, and a dealer cooperate. Each
party has its specific processes in the overall structure and uses business documents to
exchange information via the interfaces to processes of other business associates. The
persons involved in the business processes are also recorded and assigned with their roles.
91
METHOD MANUAL
3.4.1.7.3 Structuring model

The structuring model is generally used to express the hierarchy or systematization
(specialization or generalization) of facts.
A structural element represents a fact (in the direction of the intended systematization).
Models relating to the facts can be assigned to individual structural elements of the fact
hierarchy.
Structuring models are most frequently used in quality management, particularly for
certification purposes. There, the structuring model divides a norm into its individual
components, and models which help meet the quality criterion are assigned to individual
structural elements.
Figure 92: Example of a structuring model (extract from VDA 6.2 standard)
By means of a report, these facts can easily be evaluated or used for documentation
purposes.
92
METHOD MANUAL
3.4.1.7.4 Role diagram

In general, the role diagram is used to describe processes in more detail. The focus is put on
the organizational units participating in the processes as well as on their roles. Objects and
their relationships have the following properties:
A role participates in processes with due consideration of authorizations. The specification of
the authorization type in the process (a role is 'involved in the execution') is just as significant
as executability itself. During process execution with a specific authorization, the Role -
Participation - Process relationship chain (including both Participation - Authorization
condition and Participation - Authorization value) is established.
A role can be occupied by persons, positions, or information systems. The role forms the link
between the processes and the resources involved in them. It is defined by an aggregation of
expectations of the resources involved in the processes.
Executing a process requires skills that the participating role or the allocated resource must
have. To be able to define roles in a process-oriented manner, the processes must be
assessed and the process requirements of the persons/systems involved be specified. More
precisely, requirements of persons or systems constitute the knowledge and capabilities
(skills) these persons or systems have. The evaluation of a skill is standardized by an assigned
evaluation scale.
93
METHOD MANUAL
Therefore, in the role diagram it is possible to depict processes and specific elementary
processes, represent the resources involved, record their skills or required skills, and show
their authorizations.
Figure 93: Role diagram
The sample model displays the elementary process' requirements of the role (capabilities and
authorizations), as well as the elementary role's requirements of the resource with regard to
capabilities and authorizations.
The diagram is assigned to the relevant elementary process and elementary role. By assigning
the diagram to the elementary process, the requirements of the underlying process EPC
(corresponds to the process reference model) can be viewed. Assigning it to the elementary
role shows the elementary role's requirements of the resource with regard to its capabilities
and authorizations in the role structure diagram.
94
METHOD MANUAL
3.4.1.7.5 Quick model

The Quick model model type enables you to model without method restrictions. The Quick
model contains the Quick object object type with over 30 different symbols. Relationships of
the has relation with type can be created between quick objects. Multiple connections of
this type are allowed between two objects.
The corresponding default attributes can be specified for models, objects, and connections.
You can assign multiple quick models to all objects of any object type provided by ARIS
Method. In addition, you can assign any number of models provided by ARIS Method to a quick
object regardless of the model type.
You can transform Quick model model types and/or Quick object object types into
method-based models or objects using the Semantics Generator in ARIS.
95
METHOD MANUAL
3.4.1.7.6 Screen design

When designing software, you can use a 'Screen design' in ARIS to specify the technical
requirements of a dialog or Web form.
In the Layout column, you specify the structure of the dialog or Web form. The procedure for
designing a dialog, for example, is similar to working with a resource editor in a development
environment.
The graphic elements that can be placed in the Layout column include text boxes, spin
boxes, option buttons and check boxes, combo boxes, buttons, tree and list controls, as well
as bitmaps and static text. You can use the Tabindex attribute type to specify the order in
which the Tab key moves the cursor to the individual screen elements.
You can place various data elements and function objects in the Data and Functions
columns. Using a connection of the represents type, the objects can be associated with the
data elements and functions they are editing.
Each screen design can be assigned to the corresponding screen object that is used, for
example, in an EPC or a model of the Screen navigation type. In addition, a screen design
can also be assigned to the entity type, cluster, complex object type, class, or function/IT
function edited via the screen.
96
METHOD MANUAL
Figure 94: Example of a screen design for a registration dialog and implementation in C++
97
METHOD MANUAL
3.4.1.7.7 Screen navigation

In a model of the Screen navigation type, you can either specify the structure of a screen
that comprises multiple subscreens (for example, a Website with several form fields or
frames), or you can describe the transition between various screens. The transition between
the screens can be described in detail.
Example
You want to illustrate that a screen element has to be active before the next screen can be
accessed. Assign the triggering screen element (of the Screen design model) to the screen
using the contains connection. Then draw a connection of the calls type from the screen
element to the screen that follows.
It is also possible to show that navigation depends on events. When you exit a screen various
events can occur. For example, if a user has completed the registration page of an online
shop, the registration can either be completed successfully or it can fail. This will determine
whether the user moves to the contents page of the catalog or is returned to the registration
page.
Figure 95: Example of screen navigation with events
98
METHOD MANUAL
3.4.1.7.8 Business segment matrix

In the business segment matrix, the various markets in which a company is active are shown
in an overview and their significance for the success of the company is shown in visual terms.
Each market is described by
 the product or service offered and
 the customer group that the offer addresses.
Products and services (objects of the Product/Service type) are placed in the cells of the
first column of the business segment matrix. The target group (various organizational
elements) is placed in the cells of the first row. You define the market by placing a business
segment object in the cell where product row and target group column intersect. Implicit
relationships of the belongs to business segment type are established between the
product/service and the organizational element.
To emphasize the significance of a business segment, five different symbols are available
from almost unimportant to very important.
When modeling, you need to observe that each business segment can be placed within the
matrix only once.
For each business segment, you can indicate its importance in terms of the corporate
strategy. A strategy describes long-term procedures that the company employs to achieve its
objectives and to gain competitive edge.
The following figure shows a business segment matrix from the pharmaceutical field.
Figure 96: Example of a business segment matrix
Business segments can also be assigned an objective diagram. The objective diagram
contains the objectives set for the business segment as well as the processes and success
factors supporting the achievement of these objectives.
99
METHOD MANUAL
The success factors in the objective diagram can be the basis of success factor analysis if the
Success - Actual, Success - Target, and Success - Competitor attributes are specified in
the attribute type group of the same name. Success is evaluated by means of a five-step
scale from very low to very high.
Procedures
To perform a success factor analysis,
1. use the pop-up menu of the business segment to start ARIS report (Evaluate > Report),
2. and select the MSF_Analysis(Object).rso report script of the BPM group in the default
path of the Report Wizard.
The report is output in HTML format.
Figure 97: Report
Alternatively, you can start the success factor analysis via the pop-up menu of the objective
diagram. Select the MSF_Analysis(Model).rsm report script.
100
METHOD MANUAL
3.4.2 Design specification
3.4.2.1 Access diagram

The relationships illustrated below between the objects explained in the design specification
descriptions of the other views can be included in the access diagram of the control view. In
order to make the illustration clearer, the individual dual relationships are dealt with
separately.
3.4.2.1.1 Linking functions with data

First, you can define the information flows between application system types, module types,
or IT functions. For this purpose, an information flow object is created between the
corresponding application system types or module types. In order to specify the information
flow between system types in more detail, an eERM diagram or a table diagram is linked with
the information flow object. Thus, the information flow objects may be located either at the
requirements definition level, design specification level, or implementation level.
Figure 98: Information flow between application system types
Besides the information flows, input and output data of every application system type,
module type, and IT function type can be represented as data objects of the requirements
definition or design specification. The direction of the arrows indicates whether it is an
incoming (input) or outgoing (output) data flow.
Figure 99: I/O data at the design specification level
101
METHOD MANUAL
3.4.2.1.2 Linking organization with function

The fact that the organizational aspects are linked to the functional aspects defined at the
design specification level basically answers the following questions:
 Who (which organizational unit, position, person, etc.) is responsible for the application
system types and module types specified in the function view at the design specification
level, or who uses these systems?
 Which locations (organization view) within the company use which application system
types or module types?
 Which platforms available in the company (hardware component types (organization
view)) are suitable to run which application system types?
In order to answer the first question, connections can be drawn in the access diagram
between the organizational units of the organizational chart (organizational units, positions,
and persons) and the objects of the application system type diagram (application system
type, module type, IT function, etc.). While doing this, the significance of this relationship can
be specified more precisely. We distinguish the following:
 An organizational unit may be responsible for an application system type as far as the
technical aspects are concerned.
 An organizational unit may be responsible for the development of an application
system type.
 An organizational unit may be a user of an application system type.
The question of location may be solved by assigning locations from the organization view to
application system types, module types, and IT function types.
In the design specification we are not dealing with individual application systems in the sense
of individual licenses, but with application system types. Therefore, no actual locations of
application systems are defined by means of this relationship (this is realized at the
implementation level), but possible locations of a particular application system type are
pointed out.
The design specification of the organization view defines the hardware component types
available in a company. In the control view, the relationship between these hardware
component types and the application system types can be established. This is how the
hardware platforms for running certain application system types, module types, or IT function
types are determined. At this stage, the graphical user interface types, operating system
types, and DBMS types included in the function view can be assigned to the hardware
component types, as well.
A list of relationships that are available in an access diagram is provided in the ARIS Method
Reference manual on your installation media.
102
METHOD MANUAL
The following figure shows examples of relationships.
Figure 100: Access diagram (excerpt)
3.4.2.2 Program flow chart

In the access diagram, you can establish the relationships between the object types of the
organization view and data view and the application system types, module types, and IT
function types specified in the application system type diagram (see chapter Access
diagram (page 101)). In this model type, you cannot directly represent the allocation of
functions of the requirements definition. This allocation is realized in the application system
type diagram. Similarly, possible chronological-logical operational sequences of application
system types, module types, and IT function types cannot be illustrated directly. Strictly
following the ARIS architecture, you can trace these links only by navigating through a
number of model types.
However, in the system design environment, model types (for example, program flow charts
(PF) (page 104)) have been established that allow an integral view of all aspects of the system
design.
For this reason, ARIS provides the Program flow chart model type. It enables you to model
all relationships to application system types, module types, and IT function types available in
other ARIS model types, regardless of the ARIS breakdown into views. Moreover, you can
represent the chronological-logical operational sequence of the object types mentioned. For
this purpose, events are provided in this model type. Similar to arranging functions and
events in the EPC, you can define module sequences in the program flow chart. In this
context, the event is seen as a trigger that activates module types or application system
types. Branches can be represented by the rules known from the EPC. Unlike in an EPC, you
can also define operational sequences in the program flow chart without the use of events.
103
METHOD MANUAL
3.4.2.3 Program flow chart (PF)

The program flow chart (PF) is used to show processing sequences of a program. The
sequence of the processing steps is illustrated by the relationships between the objects. This
diagram does not represent any data.
The following figure shows a simplified example of the processing sequences of an automatic
teller machine. The illustration of the processing sequences reveals a strong focus on
implementation.
Figure 101: Example of a program flow chart (PF)
104
METHOD MANUAL
3.4.2.4 Screen diagram

A screen diagram describes screens used in software development. The aim is automatic
derivation of screens from the screen diagram.
Thus, screen diagrams display the structure and to a certain degree the functionality of
screens. From left to right and top to bottom, the screen diagram's structure corresponds to
the geometry of the interface described.
The central symbol is the 'screen', which corresponds to a window in Windows terminology.
This window can have multiple tabs (Page symbol). In general, the interface can be divided
into areas using a table format (Section symbol for a row, and Column symbol for a column).
The Section and Column symbols can be nested as required in order to form complex
interfaces. You can place tables (Screen table symbol), text entry boxes (COT attribute
symbol), graphics (Bitmap symbol), and text descriptions (Text symbol) on the interface.
Using the Layout symbol you can assign representation properties to the Screen, Page,
Section, Column, Screen table, COT attribute, and Text objects.
Additional symbols can be used to describe the screen interface.
105
METHOD MANUAL
The following figure shows an example of a screen diagram. The second figure illustrates the
screen derived from the diagram.
Figure 102: Example of a screen diagram
Figure 103: Screen derived from the screen diagram of the previous figure
106
METHOD MANUAL
3.4.3 Implementation - Access diagram (physical)

The questions considered in the design specification of the control view are also relevant for
the implementation level. However, in contrast to the design specification level, concrete
specimens of individual objects are examined, not object types. For example, the focus may
be on relationships between concrete application systems and organizational units, not on
relationships between application system types and organizational units.
The relationships illustrated in the following are modeled in the access diagram (physical).
3.4.3.1 Linking functions with data

To show which data is exchanged between application systems, information flow objects can
be created between application system objects of the function view. Unlike application
system objects at the design specification level, these application system objects are no
application system types, but concrete specimens (individual licenses). This means that
application systems, modules, and program module types can be interlinked by data flow
connections. If you defined at the design specification level that the Sales system SD
version 2.1 module type can exchange data with the Material management system MM
version 1.2 module type, the implementation level shows that the SD license no. 1234
module exchanges data with the MM license no. 2352 and MM license no. 34234 modules.
Both MM modules are of the Material management system MM version 1.2 module type.
This is illustrated in the following figure.
Figure 104: Data flow
To specify the data objects that are exchanged between systems in more detail,
corresponding model types of the data view are assigned to the information flow objects.
Apart from the data flows between application systems, input/output data can also be
specified for every application system. There are two reasons for the relationships to be
represented in an access diagram (physical). In the first case, the data objects are objects of
the table diagram (table, field, view (physical)) located in the data view of the implementation
level. These data objects can be linked to application system objects of the design
specification level or implementation level via input/output relationships. In the second case,
107
METHOD MANUAL
the application system objects are concrete application systems or modules of the
implementation level, which are linked to objects in the data view.
Therefore, the following general rule can be defined:

If one of the object types participating in an input/output relationship originates from the
implementation level of the relevant view, the relationships in the process view are
represented at the implementation level (access diagram (physical)), as well.
Figure 105: Input/Output relationships
108
METHOD MANUAL
3.4.3.2 Linking organization with data

The focus is on the same questions dealt with in the design specification:
 Which organizational units are responsible for data objects?
 Who has access to which data objects?
 Which data objects are stored on which hardware components?
Unlike the relationships in the design specification, the relationships established here form a
link to the data objects shown at the implementation level of the data view.
This means that the responsibility for data objects is defined for relations and attributes for
the physical structures, that is, tables, fields, and their specimens [table (specimen), field
(specimen)].
To represent these dependencies, connections are drawn in the access diagram (physical)
between the objects of the organization view (organizational unit, position, person, etc.) and
the table diagram's objects mentioned earlier (table, field, view (physical), etc.).
When a connection is drawn between organizational units and tables and fields, the meaning
of each relationship must be defined individually. For example, is responsible for means that
an organizational unit is responsible for the contents of the relevant table or field, while
accesses means that a position or person has access privileges for the data objects shown.
In addition to defining access privileges and responsibilities, you can use the hardware
component object (organization view/implementation) to define on which of the available
hardware components - which can be uniquely identified by the inventory number, for
instance - certain information objects of the company are located. For this purpose, the
Hardware component object may be linked to information objects of the implementation
level (tables, fields, etc.), the design specification level (relations, attributes), or the
requirements definition level (entity types, cluster/data models, etc.) in the access diagram
(physical).
The figure below illustrates an example.
Figure 106: Assignments to hardware component
109
METHOD MANUAL
3.4.3.3 Linking organization with functions

The relationships defined in the access diagram (physical) between objects of the
organization view and the function view answer the following questions:
WHICH APPLICATION SYSTEMS RUN ON WHICH HARDWARE COMPONENTS, AND

WHICH APPLICATION SYSTEM TYPES CAN RUN ON THEM?
In order to illustrate these dependencies, the is platform of and can be platform of
relationships can be modeled between the application system objects of the implementation
level (application system, module, program module, etc.) or the design specification level
(application system type, module type, etc.) and the Hardware component object type of the
organization view.
Figure 107: Hardware component as platform
110
METHOD MANUAL
WHICH ORGANIZATIONAL UNIT USES A SPECIFIC APPLICATION SYSTEM?

While the design specification level is the level for defining the users that access certain
application system types, the implementation level allows for defining this relationship for
specific application systems (individual licenses). For example, it is possible that in one
company multiple licenses of the ARIS Architect application system type are available with
different configurations. An access diagram (physical) can show which user is using which
license. For this purpose, the Organizational unit, Position, and Person object types may be
linked with the Application system and Module object types via the uses connection. The
following figure illustrates an example.
Figure 108: Users and application systems
WHICH COMPANY LOCATIONS HAVE APPLICATION SYSTEMS?

The design specification can use the Application system type - Location relationship to
define which application system types may be situated at specific locations in the company.
For the purpose of specifying exactly where in the company individual licenses assigned to an
application system type are used, the access diagram (physical) may serve to link locations
with the Application system, Module, and IT function object types.
111
METHOD MANUAL
Figure 109: Location assignments
The ARIS Method Reference manual on your installation media lists all relationships available
in the access diagram (phys.).
112
METHOD MANUAL
3.5 Product/Service modeling

ARIS provides various model types for describing a company's products and services.
Products or services are generated or provided in the course of a value creation process. They
are the result of a human act or a technical procedure. The term product/service refers to the
supply of either services or goods.
Goods can be consumable products, material types, operating resource types, technical
operating supply types, or packaging material types. The trigger for creating a product or
service is always the demand of an organizational unit or a customer. Goods are offered to the
customer in the form of tangible merchandise.
Services are intangible products standing out for the fact that they are simultaneously
produced and consumed.
For example, typical providers of pure services are banks, insurance companies, or public
authorities.
The stronger the customer orientation in the market segment of a product provider, the more
important it is for that provider to closely observe and improve the services in the product
environment.
Therefore, the various model types available in ARIS are designed for describing both
individual products or services and a combination of products and services.
You can use the following model types for product/service modeling:
 Product/Service exchange diagram
 Product/Service tree
 Product allocation diagram
 Product tree
 Product selection matrix
113
METHOD MANUAL
3.5.1 Product/Service exchange diagram

The product/service exchange diagram illustrates the creation of products/services and their
exchange within the company. The term product/service refers to the supply of either
services or products, each of which is represented by the corresponding symbol. Products
can be material types, operating resource types, technical operating supply types, and/or
packaging material types, all of which are familiar from the EPC (material flow), for example.
Products/Services that are the input for and/or output of functions can be connected with
the start and/or end events of these functions.
This product/service exchange between business management functions can be used to
advantage at an abstraction level that ranges between the value-added chain diagram and
the EPC. The product/service exchange relationships can be illustrated not only from a
functional viewpoint, but also from an organizational viewpoint. The product/service
exchange diagram provides various modeling options to serve this purpose.
114
METHOD MANUAL
The following figure illustrates an example of a product/service exchange diagram.
Figure 110: Example of product/service exchange in a software company
115
METHOD MANUAL
3.5.2Product/Service tree
Products or services can be looked at from different levels of abstraction. Therefore, it is
useful to store the relationships in a model showing which product or service components are
making up a complete product or service. This static aspect is represented in the
product/service tree. For example, a complex product often contains several modules, each
of which has various component parts. Each of these elements can be understood as a
product or service.
The has relation with connection, which is also permitted between products or services in
the product/service tree, can be used to describe other kinds of dependencies. These include
the relationship between a consumer credit and the checking account through which the
payments are effected.
Substitution relationships to other products or services such as (potential) replacement
products or services can also be represented.
This static model also represents the interrelationship between products or services and the
(business) objectives.
The following figure illustrates an example of a product/service tree.
Figure 111: Product/Service tree
116
METHOD MANUAL
3.5.3 Product allocation diagram

Besides the general product/service diagrams, which belong to the graphic models, product
models are recommended for realizing abstract representations. The product allocation
diagram is primarily used to analyze product creation in public administration. Like the
product/service exchange diagram, this model type can be used to show which
organizational units provide or use which products, and which functions are required for the
creation of the products, or for which functions the products provide an input. In addition, the
(legal) order basis of each product is shown here. The objectives to be achieved with the
various products can be represented as well.
The following figure shows part of a product allocation diagram for public authorities.
Figure 112: Example of a product allocation diagram
Finally, this model type can be used to describe aspects relating to product marketing.
In the following, a simplified example of banking products describes these aspects.
The growth of the Internet and the rising number of private Internet users over the past
decades has been accompanied by the spread of online banking. At the same time, the
financial power of adolescents has increased, making them more important as a target group.
As a result, the checking account service is now being offered in different forms:
For example, it can be offered as a 'senior citizen account', with the holder being supported by
the staff at a branch of the bank. This product is geared particularly to older customers who
are less familiar with the new technologies, attach importance to personal support and advice
from people they know, and whose mobility is restricted due to their age. The fees charged for
such an account may be above average.
Another variant of a checking account may be a low-fee online 'teenager account'. This
product is aimed at adolescents aged 12 to 20 who are familiar with Internet technology, but
have a lower budget. The fees should therefore be at the lower end of the range.
117
METHOD MANUAL
The following figures show product allocation diagrams for these two product variants:
Figure 113: Product allocation diagram - Checking account
Figure 114: Product allocation diagrams - Sales products
The Teenager account and Senior citizen account services have been created as object
variants of the checking account and are identified by the Sales product attribute. A sales
product is a product or service rendered by a company. It is offered under different names in
118
METHOD MANUAL
different market segments. Generally, different marketing instruments are used for different
sales products.
The ARIS variants component can be used to develop any number of sales products from a
given product.
3.5.4 Product tree

The purpose of the product tree is to analyze the composition of products in public
administration. This model essentially corresponds to the product/service tree, but does not
provide the option of modeling replacement products. The product tree is located at the
requirements definition level of the product/service view.
The following figure illustrates an example of a product tree.
Figure 115: Classification of the 'Resident and citizenship affairs' product group using a product tree
119
METHOD MANUAL
3.5.5Product selection matrix

In the product selection matrix, the focus is on an organizational unit and the products within
its responsibility. The functions required for the products' creation can be allocated to the
products. The model is suitable as a starting point enabling navigation to organizational
charts, product trees, and processes relevant to the creation of products. The following figure
shows an example of a product selection matrix.
Figure 116: Product selection matrix of the social welfare office
120
METHOD MANUAL
4 Unified Modeling Language (UML) in ARIS
4.1 Introduction
UML (Unified Modeling Language) is an object-oriented modeling language whose language
constructs are standardized by a working group of the OMG (Object Management Group). UML
is based on the object-oriented approaches of OMT, Booch, and OOSE.
4.2 ARIS UML Designer - Supported UML standard

ARIS UML Designer 9.x supports the entire UML standard 2.5.
The UML specification is available at http://www.omg.org/spec/UML/2.5/Beta2/PDF/.
121
METHOD MANUAL
5 Methods for knowledge management
5.1 Introduction
The purpose of knowledge management is the systematic control of knowledge, an
increasingly important company resource. It encompasses development, monitoring, support,
and improvement of strategies, processes, organizational structures, and technologies for
effective knowledge processing within a company. This includes all activities relating to
acquisition, preparation, transmission, and utilization of knowledge. These knowledge
management activities generally do not occur in isolation; they occur primarily in the
operational and scheduling business processes of the company. Hence, an integrated view of
business processes, knowledge processing, organizational structures, information systems,
etc. is needed.
Most of these aspects can be depicted using established ARIS methods (for example, EPCs,
organizational charts, function allocation diagrams, eERMs, etc.). However, accurate
representation, analysis, and improvement of knowledge processing requires additional
means of representation to identify and structure the content of relevant knowledge
categories, to describe the distribution of knowledge within an organization, and to model
knowledge creation and utilization in business processes.
For this reason, two new object types, Knowledge category and Documented knowledge,
and two new model types, Knowledge structure diagram and Knowledge map, have been
added. Furthermore, existing model types used for the representation of business processes
(EPC, etc.) were extended to include constructs for handling knowledge creation and
utilization. The new object and model types are methodically integrated into the main model
types of the requirements definition (for example, eERM, organizational chart, function tree),
thus ensuring an integrated perspective. For example, this would enable models from a
business process optimization project to be used for the purpose of analyzing and improving
knowledge processing.
The knowledge structure diagram is located in the data view of the requirements definition.
The knowledge map, like the extended model types for business process modeling, belongs to
the control view of the requirements definition.
122
METHOD MANUAL
5.2 Object types for modeling knowledge processing
5.2.1 Knowledge category

The Knowledge category object type, represented by an oval thought bubble (see figure
Knowledge structure diagram (page 126)), illustrates an object with content referring to
specific knowledge. Examples of knowledge categories include project management
knowledge, specific industry knowledge, specific technology knowledge, customer and
competitor knowledge, etc. These categories assist in classifying a company's existing or
required knowledge.
Knowledge assigned to a particular knowledge category can be either implicit knowledge, that
is, knowledge that cannot be fully documented as it is available in the form of employee or
group skills, or explicit knowledge that can be documented in the form of descriptions or
technical drawings. Knowledge categories often contain both. For example, project
management knowledge can include project managers' experiences on the one hand and
information provided in a project management manual on the other.
In addition to general attributes like Description, Remark, Source, etc., the following specific
attributes serve to describe knowledge categories in more detail:
Attribute name Value range Description/Example

Updating Enumeration The updating frequency describes how often the
frequency type: hourly, knowledge of the relevant category must be
daily, weekly, refreshed to be up-to-date. For example, basic
monthly, trigonometry knowledge needs to be updated rarely
annually, seldom, or, for practical purposes, never, whereas knowledge
never of certain stock prices must be updated daily or
even hourly.
Significance Percentage: The significance of the knowledge category for the

0..100 company can range from 0% (totally unimportant) to
100% (extremely important).
123
METHOD MANUAL
Attribute name Value range Description/Example

Degree of Percentage: The current degree of coverage for the relevant
coverage 0..100 knowledge in the company can range from 0% (not
covered at all) to 100% (maximum possible
coverage).
If the degree of coverage of a knowledge category is
to be represented by a particular organizational unit
or person, the corresponding attribute of the has at
disposal connection type can be used to specify
this in a knowledge map.
Knowlegde Percentage: The relative advantage of your company over the

advantage 0..100 competition in terms of knowledge can range from
0% (the competition has the greatest possible
advantage over your company) to 100% (your
company has the greatest possible advantage over
the competition).
Knowledge usage Percentage: The degree of utilization of a particular knowledge

0..100 category can range from 0% (relevant knowledge is
not utilized at all) to 100% (optimal utilization of
relevant knowledge).
Desired degree of Percentage: The desired degree of coverage for relevant

coverage 0..100 knowledge can range from 0% (not covered at all) to
100% (maximum possible degree of coverage).
Future significance Enumeration Future significance depicts the expected tendency

type: sharply of a knowledge category to change in significance
falling, falling, for the company.
stable, rising,
sharply rising
Structural Percentage: The structural change speed is a measure of how

change speed 0..100 fast the methods applied to acquire relevant
knowledge must change (0%: no change, 100%
maximum change speed).
These attributes are used to assess the significance of the relevant knowledge category for
the company. They can therefore serve as the basis for identifying important or urgent
measures aimed at improving the company's knowledge management. It is often helpful to
display such values graphically. Copying and pasting the values from the Attributes window
124
METHOD MANUAL
into a table calculation program that can create the desired models is a simple way to do so.
For example, it is possible to compare the current and desired degree of coverage in a bar
chart for the knowledge categories under consideration.
125
METHOD MANUAL
5.2.2Documented knowledge
Unlike the Knowledge category object type, which can include implicit and explicit
knowledge, the Documented knowledge object type relates exclusively to knowledge
categories that are explicitly documented, or are, in principle, capable of being documented.
An example of this type of knowledge is knowledge on using software that is documented in a
manual. When assigning knowledge to knowledge categories, differentiating between general
knowledge categories and documented knowledge helps to identify the possibilities and
limitations of information system support for knowledge processing, as only documented
knowledge can be electronically stored, transmitted, and processed.
The Documented knowledge object type is represented by a rectangular thought bubble. It
contains the same specific attribute types as the Knowledge category (page 123) object
type.
5.3 Model types for modeling knowledge processing
5.3.1 Knowledge structure diagram

Using a knowledge structure diagram, knowledge categories can be broken down based on
their content. An example of this is shown in the following figure. A knowledge category may
encompass other knowledge categories as well as documented knowledge. Documented
knowledge can also be divided into several documented knowledge subcategories. However,
it cannot encompass any general knowledge categories.
Figure 117: Knowledge structure diagram
For documented knowledge, a knowledge structure diagram can show which information
carrier stores the knowledge, or which information objects of a data model or which classes of
an object-oriented system are used for knowledge documentation purposes. Finally, the
126
METHOD MANUAL
types or classes of application systems that are used to manage the knowledge can also be
modeled.
5.3.2Knowledge map
A knowledge map depicts the organizational distribution of knowledge categories. Various
object types of the organization view (for example, Organizational unit, Position, Person,
Location, Group) can be connected to knowledge categories using has at disposal
connections. In addition to the fact that a particular person or organizational unit has
knowledge in a particular category, the degree of coverage can also be specified. The has at
disposal connection contains the Degree of coverage attribute, which can express the
degree of knowledge coverage in the selected category for the relevant organizational unit as
a percentage. A value of 100% stands for maximum coverage, while a value of 0% means that
absolutely no knowledge exists for the category. This is equivalent to the absence of the
above-mentioned connection. In addition to this quantitative assessment, a qualitative
assessment that can be made that can be displayed in the form of a graph. This is what the
Coverage quality connection attribute is for, which can have the values Low, Average, High,
and Maximum. This information can be visualized by graphic symbols at the connections as
shown in the following figure. There is no direct relation between the values of the Degree of
coverage and Coverage quality attributes. If both attributes are used, it is advisable that the
qualification Low be used for a degree of coverage of up to 25%, Average for 26-50%, High
for 51-75%, and Maximum for 76-100%.
Figure 118: Knowledge map - Relating to organizational units
The knowledge map shown in the following figure focuses on organizational units, that is, all
relevant knowledge categories are specified for each organizational unit. You can also start
127
METHOD MANUAL
with knowledge categories as central objects and add all relevant organizational units to
them. The navigation options in ARIS (Relationships tab in the Properties - Object dialog)
make it easy to find other existing relationships of an organizational unit or a knowledge
category in both cases. Knowledge maps are often represented in the form of a matrix. The
matrix representation can be achieved by arranging several occurrences of the same
knowledge category in column format as shown in the following figure. In this example, the
names are visible only for the knowledge categories displayed at the top, which look similar
to the header of a table. For the other occurrences, the names were removed using the
attribute placement function. This figure also shows an alternative visual representation
option for differing degrees of coverage: the knowledge categories are scaled in different
sizes.
Figure 119: Knowledge map - Matrix representation
128
METHOD MANUAL
5.3.3 Representation of knowledge processing in business

processes
The utilization and creation of knowledge in the company's business processes is modeled
using the model types available for representing business processes (EPC, EPC (material
flow)). The Knowledge category and Documented knowledge object types are now
available in these model types. It is possible to specify for a function which kind of knowledge
(general or documented) is required for its execution and which knowledge is created and/or
documented during its execution. This type of representation enables business processes to
be examined in terms of the knowledge processing involved. For example, gaps in required
knowledge can be revealed. Besides, the qualification profile needed to carry out a function
can be determined.
Figure 120: Knowledge processing in an EPC
129
METHOD MANUAL
6 Balanced Scorecard method
6.1 Introduction
If companies want to survive in the turbulent business environment and global competition of
today's markets, they need the best possible business processes. However, it is just as
important for them to be able to react to new developments in the business environment,
quickly and in line with the strategic business objectives. This requires efficient management
processes that enable consistent implementation of corporate strategies and achievement of
strategic objectives in day-to-day business by means of operational initiatives.
Many traditional management approaches do not establish the connection between the
formulation of corporate strategies and their implementation based on strategy-oriented
initiatives, or consistent control of the achievement of strategic objectives.
In addition, many companies are still run purely on the basis of financial KPIs which are of
limited use since they relate mainly to past performance and thus cannot provide much
information relevant to future management. Only by looking at the reasons for financial
success (customers, processes, innovation, etc.) it will be possible, at an early stage, to
identify factors that might prevent the achievement of strategic objectives.
The Balanced Scorecard approach offers a methodology with a structure that is easy to
understand and implement, and that helps to avoid weak points.
6.2 The Balanced Scorecard concept
6.2.1 Key elements of the BSC approach

The Balanced Scorecard approach is a strategic management system first proposed by
Robert Kaplan and David Norton in 1992 ('The Balanced Scorecard - Measures that drive
Performance', Harvard Business Review, January/February 1992). It was developed from the
results of research on the subject of Approaches to performance measurement. This
research found that performance measurement systems geared exclusively to financial KPIs
are likely to impede value-adding activities in many companies. Built on these findings, Kaplan
and Norton set out to collaborate with innovative businesses to create a system of KPIs that
would make it possible to optimally measure the realization of a company's visions and
strategies.
The Balanced Scorecard approach associates KPIs with various views of the company
(so-called perspectives). These include internal performance perspectives (for example,
learning and growth perspective, process perspective) and external performance
perspectives (for example, customer perspective, economic/financial perspective). Due to
130
METHOD MANUAL
this arrangement of KPIs, a certain balance between short-term and long-term goals,
financial and non-financial KPIs, leading and lagging indicators, and internal and external
views can be achieved. The integration of industry-specific KPIs adds a further benchmarking
component to the concept.
The pure performance measurement approach has evolved into a comprehensive
management system for goal-oriented corporate management, starting from corporate vision
and individual competitive strategies to the formulation and control of initiatives using
balanced KPIs. Therefore, the Balanced Scorecard approach is more than just a system of
performance measurement KPIs. It assists companies in communicating and implementing
their corporate strategy and supports the resulting strategic learning process (double-loop
learning).
6.2.2Strategic management process and Balanced Scorecard
Figure 121: BSC as a structure for strategic management
The strategic management process in the context of the Balanced Scorecard approach
comprises two phases:
1. In the first phase, the company's strategy must be established on the basis of strategic
analysis. Within the scope of this analysis, all data relating to competition are being
recorded. The aim of this analysis is to identify and assess trends, opportunities, and risks
pertaining to the development of the business environment, and to determine the
company's own core competencies. At the end of this phase, the company's individual
corporate strategy is defined.
131
METHOD MANUAL
2. The implementation of the corporate strategy takes place in the second phase. In this
phase, the BSC method can help. The corporate strategy may be refined with partial
strategies (for example, business segment-specific strategies). This leads to further
strategic objectives. These are concretized on the basis of targets for particular
measurement categories. An action program in the form of instructions on how to
proceed determines how these objectives are to be achieved. Within the scope of
business planning, this action program is broken down into various corporate divisions or
departments. Budgeting can be used to put actions into more concrete terms. With the
help of individual strategy-related scorecards, the achievement of objectives can be
measured by the KPIs generated. Based on the scorecards defined, a review process
takes place during which further initiatives are specified or the strategy is 'reworked' due
to possible deviations.
132
METHOD MANUAL
6.2.2.1 Formulation and realization of vision and strategy

The strategy of a company results from its vision.
The vision represents a superior mission statement for the company under consideration; as a
general, but striking statement it is vague, yet serves as the prime principle of action and as
such expresses a sort of short version of the company's philosophy.
Individual strategies are determined for different strategic business units. These strategies
must be geared to the performance goals of the company. Therefore, it is necessary that prior
to introducing a BSC, senior management holds a workshop to determine the vision and
resulting strategies for the strategic business units. In most cases, this involves setting a
financial target (financial perspective). The focus may vary: Possible objectives are particular
values for return on capital employed, ROI, shareholder value, sales revenue, or cash flow. The
financial objectives need to be realized through specific behavior on the relevant market
(customer perspective). Therefore, after defining the objectives, appropriate market and
customer segments are selected. This customer perspective also involves the definition of
strategic objectives and the identification of relevant KPIs. For example, they may relate to
market shares or growth rates in a given customer segment.
Appropriate company resources are required to implement specific market-oriented
strategies. When establishing a Balanced Scorecard, resources are divided into two categories
as follows:
1. Once the financial and customer objectives are defined, the main business processes
(process perspective) are looked at, objectives determined, and initiatives and KPIs
generated. The focus is usually on process times and costs.
2. As part of the so-called learning and growth perspective, strategic objectives for human
resources development, information technology, and innovation are derived from the
strategic objectives of the financial, customer, and process perspectives.
When setting up a Balanced Scorecard, all strategic objectives defined are mutually
interactive, which is known as the cause-and-effect chain.
For the first step to be effective it is important that a general consensus on the vision,
strategies, and resulting strategic objectives be reached at the management level.
133
METHOD MANUAL
6.2.2.1.1 Standard perspectives of a Balanced Scorecard

Kaplan and Norton propose four standard perspectives for the structure of a Balanced
Scorecard:
1. Financial perspective - Shareholder expectations: 'What effect on finances does the
strategy have?'
2. Customer perspective - Customer expectations: 'How do we position ourselves in the
target markets?'
3. Process perspective - Process requirements: 'Which processes are of strategic
importance?'
4. Learning perspective - Requirements of organizational learning and innovation: 'How can
we develop into a learning organization? How can we promote growth?'
Figure 122: Perspectives of BSC
The standard perspectives have an implicit logic that helps implement strategy and formulate
specific cause-and-effect relationships. However, in principle, it is also possible to define
other perspectives for a company (for example, environment perspective), which may be of
relevance to the corporate strategy, or whose objectives and KPIs have a direct relation to the
standard perspectives.
134
METHOD MANUAL
6.2.2.1.2 Cause-and-effect chain

The cause-and-effect chain defines the cause-and-effect relationships between individual
objectives of a strategy, that is, across the defined perspectives of the KPIs. In other words, it
describes how the objectives of the perspectives can be achieved. The perspectives
themselves form the general conditions for the cause-and-effect chain ('force field of the
company'). It can be assumed that improvements in the learning and growth perspective
environment have a direct and positive effect on the objectives and KPIs of the internal
process perspectives. Furthermore, developments in the process perspective also have a
positive impact on the objectives and KPIs of the customer perspective, which in turn leads to
an improvement in the financial objectives.
Within the scope of developing a Balanced Scorecard system that is to be valid throughout
the company, objectives and KPIs are defined for each strategy, and the relationships
between them are represented within and across the perspectives. Based on the objectives
and KPIs specified in the financial perspective, corresponding 'positive agents' (performance
drivers) are determined in the customer perspective. In a next step, these are broken down to
the learning and growth perspective via the internal process perspective. This procedure
allows strategies of a company or division to be split into subobjectives and KPIs, and
corresponding operational initiatives to be derived from them.
By establishing a cause-and-effect chain and defining the KPIs, a balance is implicitly created
between leading and lagging indicators.
6.2.2.1.3 Definition of leading and lagging indicators

The establishment of cause-and-effect chains also produces a temporal connection between
individual objectives and KPIs. Generally, performance drivers - so-called leading indicators -
are part of the learning and growth perspective and the process perspective and come
before the effects of the customer perspective and financial perspective. Most KPIs in the
customer and financial perspectives are result indicators that measure business success; as
so-called lagging indicators they focus on the past.
Both leading and lagging indicators should be defined in every Balanced Scorecard
perspective so that the interrelationships between initiatives and the achievement of
objectives can be represented. The leading indicators enable you to detect deviations from
given objectives at an early stage.
135
METHOD MANUAL
6.2.2.2 Communication and derivation of further

scorecards
The effectiveness of a corporate strategy and its realization using the Balanced Scorecard
concept depends on the corporate scorecard's recognition and acceptance throughout the
company. For this reason it is vital that corporate strategies and the corporate scorecard are
promoted at all hierarchy levels of the company through a comprehensive communication
campaign.
In a top-down approach, targets are derived from the superior corporate strategy (corporate
scorecard) for the subordinate hierarchy levels of the company, and superior strategic
objectives are adapted to match specific departmental goals. KPIs measuring the degree of
goal accomplishment are generated for these objectives, too. Various initiatives are required
in the different corporate divisions in order to achieve the objectives, and these initiatives are
recorded in the scorecards of the underlying hierarchy levels. All targets must be based on
long-term strategic considerations reaching beyond short-term results that may be
inconsistent with the overall strategy. An example of a short-term result is a reduction in
costs based on a short-term increase in the level of production.
6.2.2.3 Planning and targets

The BSC can be used to combine the process of strategy implementation at the various
corporate hierarchy levels with the budgeting process. The purpose of this combination is to
align all resources with the corporate strategy.
The BSC is integrated in four steps into the long-term strategic planning and budgeting
process.
1. Ambitious targets are set that are communicated to and accepted by the employees. The
relevant KPIs relating to the results in the client and financial perspectives are identified
by the cause-and-effect relationships between the KPIs.
2. Strategic initiatives must set out exactly at the KPIs with the greatest discrepancy
between current value and target value. In the long term, this procedure aligns capital
investments and action programs with strategically significant target values.
3. Critical, company-wide initiatives are identified to create synergies with the strategic
objectives.
4. Based on budgets of varying maturities (5, 3, and 1-year plan), KPI plan values are linked
to business planning.
136
METHOD MANUAL
6.2.2.4 Strategic learning and feedback

The Balanced Scorecard concept contributes to strategic learning in the company and offers
the possibility to give feedback on strategy realization.
Strategic learning is aimed at every single employee and at the entire company as a learning
organization. Employees should be acquainted with the strategy and align their actions with
it. During a defined feedback process, performance data is gathered to assess whether the
strategy has been realized. Assumptions are checked by verifying previously established
hypotheses on cause-and-effect relationships of strategic objectives.
This is how double-loop learning comes into being, where strategic targets are subjected to
critical review in a bottom-up process, after which new cause-and-effect relationships are
generated. These result in a more efficient pursuit of strategy due to a continuously growing
information base.
Feedback is therefore extremely important as it represents the counterprocess to breaking
down BSCs. Feedback comprises not only the reporting of KPIs in the form of plan progress
figures, but also suggestions for further initiatives and new interrelations. It reveals potential
inconsistencies in the pursuit of strategy.
137
METHOD MANUAL
6.2.3 Advantages and benefits of the Balanced Scorecard

The advantage of the Balanced Scorecard method lies in its consistent, strategy-oriented
corporate management, which includes the lowest levels of a company, where
strategy-based operational initiatives are derived. All resources and all employees of a
company are aligned with the corporate strategy. The strategy is consistently communicated
and monitored through Balanced Scorecards.
The Balanced Scorecard method overcomes the disadvantages of traditional KPI systems in
corporate management:
 No limitation to financial KPIs
 No pure focus on the past
 Qualitative data also considered
 Reduction of complexity, consensus building
 Strategic objectives as the starting point of the Balanced Scorecard approach
 Focus on management bottlenecks, not on existing data
 Acceleration of required changes
The Balanced Scorecard method is ideal for strategy-oriented corporate management as it
overcomes the following barriers:
 Concretization barrier: In traditional management approaches, vision and strategy are
theoretical formulations; the derivation of specific (operational) action plans is not
consistently pursued.
 Vision barrier: The strategy is often not understood by those employees who have to
implement it.
 Commitment barrier: Strategies are not associated with specific departmental or
individual objectives.
 Implementation barrier: Reporting is geared to operational-monetary objectives, rather
than strategic objectives.
 Operational barrier: The budgeting process is separated from the strategic planning
process.
138
METHOD MANUAL
6.3 Developing a Balanced Scorecard with ARIS BSC
6.3.1 Terms and abbreviations

Vision: A vision indicates the future strategic thrust and mission of a company and is realized
through various strategies.
Strategy: Strategies are developed based on the vision. Strategies can be split into specific
substrategies.
Strategic objective: Each strategy consists of a certain number of strategic objectives.
Generally, management determines strategic objectives in workshops. Objectives are
interconnected according to cause-and-effect relationships and chronology.
Success factor: A success factor influences the success of a company's business
operations. It may interact with other success factors and direct them towards a specific
behavior with a particular degree of effectiveness.
View/Perspective: A perspective puts a certain view of the company in more concrete
terms. In principle, the selection of perspectives should include the following views of a
company: human-oriented view, internal view, process-oriented view, and external view.
KPI: Each strategic objective or success factor is allocated KPIs to measure performance and
achievement of objectives.
Actual value: Current value of a KPI, strategic objective, or success factor. Based on the
actual value, the current degree of goal accomplishment can be derived by means of a
planned-actual comparison.
Plan value: Plan value of a KPI, strategic objective, or success factor set as the target for a
particular period. In the case of strategic objectives, this is usually a percentage derived from
the weighted achievement of objectives of individual KPIs. A plan value can be broken down
into individual periods and takes account of periodic fluctuations. Plan values represent a
degree of goal accomplishment of 100 %.
Target value: Value set as the target for a period in the future. Generally, this value becomes
the plan value once the target period is reached.
Minimum value: Smallest possible value that an objective, critical success factor, or KPI can
have. In ARIS, the minimum value is set to 0 by default. However, it can be modified.
Maximum value: Highest possible value (upper limit) a strategic objective, a success factor,
or a KPI can have. In ARIS, it is generally used to standardize the representation of multiple
KPIs so that they can be compared.
Warning limit: The warning limit corresponds to the plan value, that is, the plan value
corresponds to the limit at which the value of a KPI, strategic objective, or success factor falls
short of an expected target.
139
METHOD MANUAL
Tolerance range: The tolerance range is the negative deviation from the plan value for a
strategic objective, KPI, or success factor that can still be accepted.
Alarm limit: The alarm limit denotes the plan value minus the tolerance range. All values of a
strategic objective, KPI, or success factor that fall below the alarm limit are no longer
acceptable.
Initiative: An initiative influences a single objective or a number of strategic objectives.
Generally, initiatives are assigned a person responsible for them, and they have a starting
point, an end point, resources, etc.
Indicator type: A KPI can be of the Leading indicator or Lagging indicator type. A leading
indicator measures a performance driver and is an indicator pointing to the future. A lagging
indicator measures a result (result indicator) and is retrospective. Economic/Financial targets
are generally lagging indicators, while the targets of process, learning, and growth
perspectives are increasingly leading indicators. It is recommendable to include lagging
indicators in the perspectives in order to represent cause-and-effect relationships between
KPIs.
Data source: Each KPI has a data source from which it can be transferred to the Balanced
Scorecard system.
140
METHOD MANUAL
6.3.2 Creating Balanced Scorecards with ARIS BSC
6.3.2.1 Specification of perspectives

At the start of a Balanced Scorecard project, the perspectives should be specified within the
strategic plan. These perspectives are valid for all corporate scorecards.
The Perspective object type is available for this purpose. Perspectives can be modeled in the
BSC cause-and-effect diagram.
Perspectives are linked via the is influenced by connection. There is no need to define a
specific sequence. However, establishing a logical structure (with the individual perspectives
arranged in a sequence) considerably simplifies automatic generation of a model.
Furthermore, the logical structure of the cause-and-effect chain becomes more transparent.
6.3.2.2 Balanced Scorecard system structure

specification
The following models provide the framework for creating a Balanced Scorecard system:
 Organizational chart
A Balanced Scorecard system can be structured in line with the organizational structure
of a company. Any number of BSC cause-and-effect diagrams can be assigned to the
objects of the organizational chart (for example, for variant creation, history
management, etc.). This assignment establishes a connection between the objectives
required for strategy implementation and the corresponding organizational units. Based
on the organizational chart, the Balanced Scorecard system of a company can be broken
down from the highest corporate level to the level of individual departments or
employees.
 Structuring model
If a company prefers to create its Balanced Scorecard system based on strategic
business segments rather than the organizational chart, the structuring model is
available as a starting model for the balanced scorecard structure. In this case, any
number of BSC cause-and-effect diagrams can be assigned to a structuring object.
 Value-added chain diagram or function tree
As the Balanced Scorecard is meant to be an instrument for performance management
and performance measurement, the Balanced Scorecard system can be established in
ARIS with a view to value-added criteria. The value-added chain diagram or the function
tree can be used for this purpose.
141
METHOD MANUAL
6.3.2.3 Cause-and-effect relationship specification

The objects of the organizational chart and the functions or structural elements of the
structuring model, which determine the company-wide structure of the Balanced Scorecard,
are assigned BSC cause-and-effect diagrams.
In the BSC cause-and-effect diagrams, the strategic objectives and success factors required
for successful strategy implementation are defined, and their mutual influence is illustrated
by means of the various Balanced Scorecard perspectives. First, the individual perspectives
used in all cause-and-effect chains of the company are created as objects in ARIS.
The BSC cause-and-effect diagram is a lane model which allows the Perspective object
types to be stored in the Relevant perspectives column and the Strategy object types to be
stored in the Strategy row. The Objective, Success factor, and KPI object types can be
modeled in the cause-and-effect columns. The degree of effectiveness of the strategic
objectives and their success factors are described in the cause-and-effect column. The
greater the effectiveness, the thicker the arrow that represents it.
Furthermore, success factors for a Balanced Scorecard can be defined in the BSC
cause-and-effect diagram. By using the Success factors object type, you can include other
factors on which the company has no direct influence and their KPIs in the Balanced
Scorecard (for example, market growth).
142
METHOD MANUAL
The BSC cause-and-effect diagram can be found at the requirements definition level of the
control view.
Figure 123: BSC Cause-and-effect diagram
143
METHOD MANUAL
The Objective and Success factor object types in the modeling column of the BSC
cause-and-effect diagram can be assigned a BSC KPI allocation diagram only.
The following symbols are used in the BSC cause-and-effect diagram:
Symbol Object type

Perspective
Strategy
Objective
Success factor
KPI instance
144
METHOD MANUAL
6.3.2.4 Specification of initiatives and KPIs to monitor

objectives
After strategic objectives and success factors have been defined in the BSC
cause-and-effect diagram, a BSC KPI allocation diagram is assigned to each of the individual
objects. In the diagram, objectives and success factors are allocated KPIs to serve as a
benchmark for the relevant objective or success factor. These KPIs are subsequently
identified and channeled. If an object is allocated multiple KPIs, a connection of the is
measured by/measures type can be used to specify the weighting of any KPI. This indicates
how important the KPI is for the degree of goal accomplishment of the objective or success
factor. For the analysis script of ARIS BSC to run successfully, the Weighting attribute must
be specified for all connections of the is measured by/measures type.
Apart from KPIs, objectives and success factors in the BSC KPI allocation diagram may also be
allocated objects to define the data source (for example, entity type, file, document,
database, storage medium, etc.). This allocation establishes a link to the ARIS Data Warehouse
method. It allows an accurate definition of which data elements in the Data Warehouse
method each Balanced Scorecard KPI is connected with.
Since is possible to depict the interaction of KPIs using the influences/is influenced by
connection type, the effects that leading indicators have on lagging indicators can be
described in the BSC KPI allocation diagram. For this we recommend that an additional BSC
KPI allocation diagram be designed, which does not focus on the allocation of individual KPIs
to objectives or success factors, but on the consolidation and definition of KPIs used in other
BSC KPI allocation diagrams and on the description of their effects.
Figure 124: BSC KPI allocation diagram
The BSC KPI allocation diagram can be found at the requirements definition level of the
process view.
The following symbols are used in the BSC KPI allocation diagram:
145
METHOD MANUAL
Symbol Object type

Objective
Success factor
KPI instance
Task
Organizational unit
Organizational unit type
Position
Person
Role
Group
Application system type
Technical term
146
METHOD MANUAL
Symbol Object type

Entity type
Relationship type
ERM attribute
Cluster/Data model
Knowledge category
Documented knowledge
Class
Information carrier
147
METHOD MANUAL
6.3.2.5 Description of KPIs and their relationships

After KPIs for measuring strategic objectives and critical success factors have been selected,
these indicators and their relationships can be defined in more detail using the KPI tree
model type.
A KPI tree arranges various KPIs in a hierarchy by means of the influences connection type.
The Weighting attribute can be specified for these connections, thus enabling the calculation
of an overall KPI within a KPI tree with the help of weights. The KPI tree is assigned to the KPI
instance representing the overall KPI. This assignment is included in the Create BSC
management view and Perform BSC planned-actual comparison evaluations.
Figure 125: KPI tree
The KPI tree uses the KPI instance object type only.
The KPI tree can be found at the requirements definition level of the data view.
6.3.3 Relationships to other models

The objects of the Balanced Scorecard method can be associated with the following ARIS
models:
 EPC
 Objective diagram
 DW structure
148
METHOD MANUAL
7 E-Business scenario diagram
7.1 Introduction
The smooth execution of inter-company business processes is increasingly gaining in
significance. Here, the operational sequence of specific procedures at the interfaces between
companies on the one hand and at the interfaces between companies and their customers on
the other hand is in the center of interest. The contacts need to take place in a clear, quick,
consistent, and direct manner.
Rapidly finding suitable business associates (from a corporate perspective) and providers
(from a consumer point of view) is also of great relevance. Maximum optimization of these
processes results in a competitive advantage. The ideal platform for supporting these
multilateral relations is the Internet. As the processes in the above-mentioned environment
are very complex, it is necessary to define the term 'e-business'.
E-business is a generic term for the use of information and communication technologies in
support of a company's business activities. It includes the use of electronic media for the
purpose of supporting relationships and processes involving business associates, employees,
and customers (Herrmans, Sauter, 1999).
Thus, e-business can mean the creation of a Web site for a corporate presentation, the
acquisition of an item via Internet, a highly complex project shared by two companies, or
multilayered relationships between any number of business associates meeting in a
marketplace.
It can be subdivided into the following concepts:
B2B (BUSINESS TO BUSINESS)

Business to Business describes the transactions taking place between companies. For
example, this is enabled by linking the companies' supply chains.
B2C (BUSINESS TO CONSUMER)

Business to Consumer describes transactions taking place between companies and their
customers. For example, this includes purchases by customers in online shops.
149
METHOD MANUAL
B2A/C2A (BUSINESS/CONSUMER TO ADMINISTRATION)

Business/Consumer to Administration describes all transactions between companies or
individuals and public administration. Contacts between companies and administration are
considered to be an area with great cost-cutting potential.
Figure 126: Transaction options in e-business
In addition to differentiating between various partners, a distinction can also be made

regarding the scope of relationships between the partners: one to one, one to many, many to
many. Especially the marketplace scenario is of major significance.
MARKETPLACES
Electronic marketplaces are virtual places where any number of people buy and sell products
and services (openly) and exchange information.
To support these scenarios, the E-Business scenario diagram was developed. In conjunction
with other methods and various components supplied by ARIS, it enables optimal support of
the implementation of e-business projects. This chapter on e-business scenario diagrams
first describes the method with all objects and evaluation options and then goes on to discuss
interrelationships with other methods. At the end of the chapter, a use case demonstrates
the complex possibilities.
150
METHOD MANUAL
7.2 E-Business scenario diagram method
7.2.1 The idea

The possibility of viewing a value-added chain in its entirety, that is, from the end user to
each of the companies involved in a procedure, provides a basis for developing optimization
potential. The aim is, for example, the improvement of the supply chain, the reduction of
procurement and distribution costs, or the optimization of the information system
architecture. The e-business scenario diagram representation allows visualization of the
content that is to be examined to achieve the designated objectives. Due to the column
representation, the interfaces between very different process partners are depicted in an
abstracted form by the column borders. Various reports supplement the models and offer
important analysis capabilities.
7.2.2 The model and its objects

The economic agents considered in the model are placed in the header and identified as
business participants. They originate from the organization view and can be assigned
organizational charts that may serve to describe the company structure or the relationships
between the objects of the individual columns in more detail.
An economic agent's individual processes participating in the overall process and the
interfaces between them are the central and structurally relevant objects of the model. An
individual process is a business process that plays an important role in inter-company
cooperation. A more precise representation and analysis of such an individual process can be
obtained by assigning a process model. All processes running in a company are modeled in
the row below the business participant, but in the same column. Inter-company coordination
also requires precise analysis of application systems and hardware in use by the various
economic agents in support of their individual processes (for example, ERP systems). These
elements are represented by Business components. To coordinate the various components,
responsibilities for the systems must be specified exactly. For this purpose, Organizational
unit type objects are available. Even the roles of the employees involved in the process can
be defined. These are referred to in the model as Employee role. The integration of interfaces
is a particular requirement of e-business modeling. In this context the column borders are of
crucial importance since they symbolize the interfaces between the process participants.
They can be viewed from several perspectives.
One focus can be the transfer of process-specific information. That is the purpose of
Business documents, which can assume the form of XML or HTML documents. The business
document can be assigned a model of the data view, for example, a document type definition.
151
METHOD MANUAL
Alternatively, the flow of money or goods can be displayed using the Money transaction or
Goods shipment objects.
Another important aspect: data security must be ensured, especially the security of
electronic payments sent via Internet. Different encoding techniques can be used for this
purpose, for example, SET (Secure Electronic Transaction) or SSL (Secure Socket Layer). The
security aspect can be taken account of by using the Security protocol object. It is also
possible to define persons responsible for the security of transactions, which can be
represented by an Organizational unit type. Furthermore, the focus may be put on analyzing
a more technical aspect, namely the technical design of the data transfer at the interfaces.
For this purpose, the model uses various information carriers. Individual processes can be
linked via intranet, extranet, or Internet. Data transfer can take place by e-mail. The mobile
phone has also gained ground as a transmission medium.
Figure 127: Objects in the e-business scenario diagram
152
METHOD MANUAL
7.2.3 'Transmission type' attribute group

Modeled objects can be further specified by their attributes. The relevant attributes are
especially tailored to meet the e-business requirements.
Attention should be given to the Transmission type attribute group of the Business
document, Money transaction, and Goods shipment objects. Specifying transmission type
attributes not only identifies the transmission path, but also expresses the need for securing
the transaction. In the case of an online transmission, for example, it is important not to omit
the above-mentioned securing of confidential information and data.
7.3 Evaluations using reports

Various evaluation options provide support for modeling e-business scenarios. These
evaluations are performed in the form of reports. ARIS provides several predefined evaluation
reports, but the creation of user-defined ones is possible as well. The following reports for
e-business scenarios are provided.
7.3.1 Data security check

The security of data transferred online is one of the most important issues influencing
e-business acceptance. Protecting personal data or payments from access by unauthorized
persons is an issue that must be resolved in order to avoid loss of confidence of customers
and partners. A report allows all products/services exchanged (money transaction and goods
shipment) and all data (business documents) to be verified in this regard. The Transmission
type attribute group already mentioned is evaluated and, in the event that it is an online
transmission, checked to determine if data encoding takes place. Thus, potential security
gaps and obsolete encoding methods can be identified and eliminated.
7.3.2 System support

A second important aspect in e-business projects is the harmonization of application
systems. A company needs to consider many questions in this regard. Which processes must
be supported by which systems? Who will be responsible for operating which systems? Where
might training expenses be incurred? What adjustments of existing systems are necessary?
Here too, the answers can be found in a report. Individual processes are listed along with the
corresponding systems and the persons responsible for them.
153
METHOD MANUAL
7.3.3 Information flow

In contrast to other process models, e-business scenarios focus on transactions. Special
attention is given the data and products/services being exchanged. Therefore, evaluations
are provided to monitor data and service exchange. Important questions are: What data and
products/services are generated, where are they generated, and where are they used? The
required information may be obtained by running the report that outputs the modeled data
and products/services as well as the processes in which they are involved as input or output.
7.3.4Collaborative business maps

The collaborative business maps used by SAP constitute a special type of model. They
emphasize the view of various partners. There are two views that focus on different target
groups. The 'aggregated view' is designed for senior management and contains only business
participants and processes, while the 'detailed view' is designed for operating departments
and includes documents and roles of the process managers in charge. The reports enable a
transfer of the information shown in the e-business scenario diagram to both views at any
time.
7.4 Connection to other methods and components

Using the various modeling methods information can be viewed from different perspectives
and made available to various target groups with a special focus. The e-business scenario is
the starting point of these views. Details for specific target groups can be specified in its
objects. In this way, an e-business project can be represented in its entirety. In addition, the
various components of ARIS can be used to perform evaluations for the models created to
ensure optimal support of projects in the e-business environment.
EXAMPLE: CREATION OF AN ONLINE SHOP

The first step is defining the objectives that are to be achieved by the planned e-business
activities. This step can be performed with the help of the ARIS component Balanced
Scorecard (see the chapter Balanced Scorecard method (page 130)). This makes it possible
to identify the processes that have to be optimized to achieve the objectives. In our example,
the objective is identified as the development of a new distribution channel, namely the
Internet. In order to pursue this new path optimally, precise documentation and planning are
indispensable.
154
METHOD MANUAL
Not only must the process flow itself be taken into account, but also the organization of
responsibilities, interfaces between various systems, and data security.
Starting point is the e-business scenario diagram. The business participants in our example
are the company that implements the shop system and the customer who will use this offer.
The entire process from 'entering the shop' to 'leaving' is broken down into subprocesses. The
representation shows the view of the customer and that of the company. The e-business
scenario diagram serves as an entry point to the implementation project. The following figure
shows how the overall process is divided up.
Figure 128: Excerpt from the 'Online shop' e-business scenario
155
METHOD MANUAL
The various process steps can now be refined by EPCs: for example, they can be verified with
the Simulation component, displayed after optimization by means of pipeline diagrams, and
converted into a finished shop system through Intershop Enfinity to be further improved.
Figure 129: Excerpt from the pipeline diagram
156
METHOD MANUAL
If a shop is to be connected to an external ERP system (Enterprise Resource Planning

system), the data to be transferred needs to be in the correct format. For this purpose, there
are various ways of standardizing documents and data. One such standardization option is
offered by the use of Extensible Markup Language (XML). Since XML is a language that is
being developed along completely different paths, a uniform foundation is needed here.
Different organizations, consisting of companies and scientific institutions, are involved in
standardizing XML for various sectors.
The use of standardized XML documents facilitates the integration of ERP systems.
The problems arising from the need to harmonize various components have already been
mentioned. The application system type diagram can serve to visualize the systems and can
be assigned as a model to application systems or business components to explain the
systems' interrelationships in more detail.
The new e-business activities will also affect the organizational structure. It may be
necessary to define new responsibilities or make new allocations. The e-business scenario
diagram can describe roles and organizational units for individual process steps. What
position they take in the company's organization or in the process can be analyzed further by
means of organizational charts.
Implementation begins with the realization of modeled content. If the Intershop method is
used, the content modeled is converted into an operational system by means of Intershop
Enfinity.
157
METHOD MANUAL
8 IT City Planning
8.1 Enterprise Architecture and IT City Planning

IT City Planning is an architectural approach that was developed by the Frenchman Jacques
Sassoon in the 1980s. The aim of IT City Planning is to bring harmony to a heterogeneous
system landscape by thoroughly analyzing its interactions, that is, the exchange of
information among the applications in that system.
Based on the approach used in town planning, the procedure for drawing up an IT city plan is
driven by the idea of enabling long-term, strategic IT management that considers not only the
present but also aspects of the past (legacy systems) and those of the future.
However, there is no need to redesign the entire system. Instead, a project-by-project,
incremental approach is adopted.
As with Model Driven Architecture (MDA),which is supported by ARIS products, the subject of
IT City Planning can be approached through models that describe the information system
without reference to technology-related information. However, IT City Planning dispenses
with UML, which simplifies familiarization with the subject for those with a less technical
background, and increases its acceptance.
8.2 Which companies may benefit from IT City Planning?

IT City Planning addresses the following companies:
 Companies with a large portfolio of applications.
 Companies that have a long history of using information technologies.
 Companies for which information technology is of strategic importance.
 Companies that are involved in a merger.
Aims of IT City Planning:
 Reusing software resources to avoid the creation of further redundancies.
 Reducing maintenance costs by 'block-by-block' overhaul and by defining new software
resources that can replace existing resources and cover the various use cases.
 Consolidating information systems.
 Preparing the deployment of EAI software at a higher level.
Creating an IT city plan is the responsibility of the Integration Competence Center. The plan
itself must address both the design pattern and the information and technology architecture.
158
METHOD MANUAL
EAI = Enterprise Application Integration. Company-wide integration of applications. EAI

provides the e-business infrastructure. EAI software is the technical middleware required as a
prerequisite for implementing an e-business strategy.
8.3 IT City Planning with ARIS

ARIS provides the following views of an information system:
 Data view
 Function view
 Organization view
 Product/Service view
 Process view
Each of these views is subdivided into the Requirements definition, Design specification,
and Implementation descriptive levels. These are based on the lifecycle of an information
system and their proximity to information technology.
The design specification and implementation levels essentially describe the software system.
The concepts and terms of these levels are closely interrelated and their 'translation' is
unproblematic.
This is not the case with the transition between the requirements definition and the design
specification. When creating the design specification, the business management view must
be aligned with the standard software. This requires both business management expertise
and data processing knowledge (see Scheer, A.-W., ARIS - Business Process Frameworks,
1998, 3rd edition, p. 7).
The information system view (IS view) in IT City Planning can assist as a mediator between
levels. In ARIS, the object types of the IS view are located at a level between functions and
application systems, thus extending the function view in ARIS. Like functions, IS elements are
associated with the various constructs from the familiar views of the ARIS House. These
extensions mainly relate to process view and data view. In the following, the term IS view
refers to the model types from the function and process views of the ARIS House, which
describe relationships between IS elements or give a detailed description of IS elements seen
in the context of the other ARIS views.
159
METHOD MANUAL
Application system types, IT function types, and sockets are considered as elements of the IT
(information technology) view. In analogy to the IS view, the IT view includes all model types
in which relationships between application system types, IT function types, and the new
Socket object type are described, or which are used to describe one of these elements in
detail.
Figure 130: Process view, IS view, IT view
160
METHOD MANUAL
8.4 Service view

ARIS provides the following model types for describing the Service view:
 Service architecture diagram
 Service allocation diagram
 Service collaboration diagram
The two service architecture models arrange the structural elements of the information
system in a hierarchy.
An IS hierarchy can include the following levels:
 Zone
 District
 Building cluster
 Functional block
 Capability
 IS service
 Business service
Zone, District, Building cluster, Functional block, and Business service are Service type
object types. Service types are used to organize an information system in independent
units/blocks by function.
Each service type is characterized in that it is the 'owner' of the data it uses and of the
associated processing methods. Other service types can access these data and processing
methods only if they call a service of the 'owner service type'.
Within a service type, similar data is used and identical activities and business functions are
carried out.
At the top level, the information system is divided into zones. A zone can correspond to an
operational and development area, for example.
The following figure shows the zones into which a company's information system can be
typically broken down.
Figure 131: Zones of a company's information system
161
METHOD MANUAL
Each zone, in turn, can contain one or more districts.

Districts of a zone are characterized by a high degree of similarity in terms of processes and
temporal features (for example, similar lifecycles and information processing cycles). Districts
can be terms of payment or of price, human resources administration, travel guidelines etc.
The Resources zone may include the Human resources and Accounting districts:
Figure 132: Zone divided into districts
A district may contain one or more building clusters that serve a functional purpose, for
example, salary payments, invoicing, etc.
The Human resources district includes the Business unit administration, Recruiting, Human
resources development, and Human resources support building clusters.
Figure 133: District divided into building clusters
Each building cluster can encompass one or more functional blocks. Functional blocks are
characterized by substantial similarity regarding the business objects and events they
manage.
A functional block is an independent, reusable functional component. Capabilities and IS

services are combined to form a functional block according to the following rules:
 There is a close interrelationship between the objects they manage and the functions
they support.
 There is only minimal exchange with other functional blocks.
162
METHOD MANUAL
The building cluster Human resources support of the given example includes the Master
data maintenance, References, Controlling, and Salaries functional blocks.
Figure 134: 'Human resources support' building cluster divided into functional blocks
A capability is an elementary functionality within a system. It supports the realization of an

activity within a process.
An IS service is an interface of a service type or a capability. IS services allow other IS
elements controlled access to data and processing methods of the IS element that provides a
service.
These interfaces can be used to exchange messages with other elements of the IS view.
163
METHOD MANUAL
The following figure shows the capabilities and IS services of the Salaries functional block.
Figure 135: Capabilities and IS services of the 'Salaries' functional block
For describing the IS hierarchy it is not necessary to entirely model all levels described here.
The Capability and IS service IS elements are not regarded as elements of the city plan in IT
City Planning. The city planner's tasks end at the building block level. Capabilities and IS
services are the responsibility of the architect (see Longépé, Christoph: Le projet
d'urbanisation du système d'information, p. 18).
164
METHOD MANUAL
8.5 Service types and their data

The eERM is used to describe which data belong to a service type or capability. In the context
of the city planning approach, the eERM provides the IS view symbols. A connection of the is
owner of type can be used to link these objects with relationship and entity types.
Figure 136: 'is owner of' connection between symbols of the IS view and relationship and entity types
165
METHOD MANUAL
8.6 Detail description of service types

A detailed description of service types and capabilities of an information system can be given
in the service allocation diagram. This includes
 the interfaces of a block,
 the interactions between the blocks,
 the application systems supporting the block, and
 business management functions that are supported by the block.
Zones, districts, building clusters, functional blocks, and capabilities can be connected to an
IS service using the provides connection.
Input/Output connections can be drawn between IS elements and data elements to describe
the information flows between the service types.
The various application system and IT function type objects can be assigned to the objects of
the IT view via a connection of the supports type. If the city plan is interpreted as a
development plan of a city, this connection provides information about which information
system areas are 'populated' by which application systems. The supports connection is also
available for use between IS elements and the function.
Figure 137: 'supports' connection between IS elements and functions
166
METHOD MANUAL
8.7 Chronological-logical operational sequences of IS

elements
In the service allocation diagram, the relationships to the object types of the organization,
data, and process views can be created for the service types, capabilities, and IS services
specified in the service architecture diagram. Possible chronological-logical operational
sequences of IS elements cannot be represented.
In IT City Planning, the service collaboration diagram is used to illustrate chronological-logical
operational sequences of IS elements, that is, to describe the dynamic aspects within the
information system. As a model type it is equivalent to the program flow chart of the IT view
(see chapter Program flow chart (page 103)). It provides events for displaying operational
sequences. As with the allocation of IT elements and events in the program flow chart, events
in the service collaboration diagram can serve to define the sequence of functional modules.
In this context, the event is seen as a trigger that activates service types, capabilities, or IS
services. Branches can be represented using the rules known from the EPC or the program
flow chart. Operational sequences can also be defined without the use of events.
167
METHOD MANUAL
8.8 IT view
The IT view contains the following model types:
 Application system type diagram
 Access diagram
 Program flow chart
Application system hierarchy
In the context of city planning, the current application system hierarchy of a company is
depicted using the application system type diagram.
The following levels of an application system type hierarchy can be depicted:
 IT system
 Subsystem
 IT software
 IT block
 IT procedure
 Socket
IT system, Subsystem, IT software, and IT block are symbols of the Application system type
object type. The hierarchy is built using the encompasses relationship type.
IT systems are at the top level of the application system type hierarchy. An IT system is made
up of a structured quantity of IT elements, usually subsystems. Administration and operation
of an IT system are the task of a specified organizational unit.
A subsystem is a component of an IT system. The components of a subsystem are called IT
software.
IT software supports a homogeneous set of functions. It is user-oriented and supports one or
more business processes. IT blocks are components of IT software.
Generally, an IT block includes IT procedures that access the same data (databases, tables,
files, etc.).
IT procedures are objects of the IT function type type. Each IT procedure supports a specific
function.
A socket corresponds to the IS service, that is, it is an interface that an IT element provides
for other IT elements so that these can access the IT element's data and processing methods.
168
METHOD MANUAL
The following figure shows an example of the subsystem structure of the DATEV system:
Figure 138: Subsystem structure of the DATEV system
8.9 IT elements and their data

As with IS elements in the eERM, the is owner of connection is available, which can be drawn
from application system types, IT function types, or sockets to entity types or relationship
types to describe the data that belong to an IT element.
169
METHOD MANUAL
8.10 Detail description of IT elements

IT elements of the IT city plan are described in detail in the access diagram. It corresponds to
the service allocation diagram of the IS view.
The description may refer to:
 input and output relationships of the IT element in question
 supported business functions
 supported IS elements
 activation of other IT elements by the element under consideration
 platform on which the IT element runs
 users of the IT element
Figure 139: Detailed description of IT elements in the access diagram
170
METHOD MANUAL
8.11 Organizational aspects

The detail description of an IT element also incorporates information from the organization
view. This includes information about which organizational elements can be users of an IT
element, and more. A network diagram can be used to show the influences and effects of the
IT infrastructure.
Figure 140: Influences and effects of the technical infrastructure
8.12 Chronological-logical operational sequences of IT

elements
In analogy to the Service collaboration diagram, the Program flow chart (PF) is used to
describe the chronological-logical operational sequence of the Application system type, IT
function type, and Socket IT elements.
171
METHOD MANUAL
8.13 Chronological-logical operational sequences within

the architecture
Various process models (all variations of the EPC) and the program flow chart provide
appropriate objects for illustrating how IS elements and IT elements are integrated into a
chronological-logical operational sequence.
Figure 141: Integration of IS and IT elements into a chronological-logical operational sequence
172
METHOD MANUAL
8.14 Possible evaluations

Based on the modeling options described in the sections above, evaluations are available to
answer the following questions and help set up the information system:
 What data is managed by a given IS element?
 Which application systems support an IS element?
 Which functions are supported by a given IS element?
 What data is used by the IT elements of a given IS element?
 What data is generated by the IT elements of a given IS element?
 Which IS services are provided by an IS element and in which processes are they used?
 On which hardware components do application systems of a particular IS element run?
The following evaluations are provided for selected application system types, IT function
types, and sockets:
 Data used by an IT element
 IS elements supported by an IT element
 Functions supported by an IT element
 Data used by IS elements that are supported by an IT element
 Data created by IS elements that are supported by an IT element
 Hardware components on which an IT system is running
173
METHOD MANUAL
9 Business process modeling

The interactions and transactions between companies and their partners, suppliers, and
customers are becoming ever more complex, mostly due to new information and
communication technologies. It is becoming more and more evident that the further
development and performance of business processes depend on close cooperation between
the various business associates.
On the one hand, it is important for a company to be able to better understand its own actions
and those of its business associates; on the other hand, organizations should be given the
ability to adapt faster to internal and market-driven changes. A standardized process
modeling language can help companies to describe their internal and external business
processes clearly and flexibly. Companies must also be in a position to communicate the
modeled processes to their business associates appropriately, clearly, and comprehensibly.
All parties involved should speak the same 'process language'.
To reach these goals, the Business Process Management Initiative (BPMI.org) offers a
standardized modeling language: "Business Process Model and Notation (BPMN)". BPMN is a
graphical notation for describing business processes.
The notation is required to be easily understood by all users. This makes it suitable not only
for business process analysts and those who monitor and manage processes, but also for
developers who implement the process execution technologies.
Furthermore, it is important to ensure that XML-based languages can be visualized with this
notation for business process automation, for example, Business Process Execution
Language for Web Services (BPEL4WS).
9.1 Process classes and the business process diagram

Business Process Model and Notation (BPMN) uses the Business process diagram (BPD)
model type for describing processes. This model depicts three classes of business processes
and the relationships between them:
 Private business processes (internal business processes)
 Abstract business processes (public business processes)
 Collaboration processes (global business processes)
Private business processes are business processes that are performed exclusively within an
organization. They are generally known as workflow or BPM processes.
Various internal business processes are modeled as a sequence flow within individual pools
(see chapter Implementation of BPMN in ARIS (page 176)) whose interactions are represented
using message flows.
174
METHOD MANUAL
BPMN uses the terms Sequence flow and Message flow instead of Control flow because the
process is controlled not only by events, but also by the messages exchanged.
Abstract business processes describe interactions between private processes of different
pools, between objects of different pools, or combinations of both. Besides the sequence flow
within the private process, the message flow between the individual processes is particularly
important. Interactions are modeled using message flows.
Abstract business processes are integrated in individual pools and can be modeled separately
or as part of an entire BPMN diagram. If an abstract business process occurs in the same
model as a corresponding private business process, they can be associated with each other.
Collaboration processes describe only interactions between two or more business entities
(business associates). A sequence of activities is modeled to reflect the pattern of message
exchanges between the various business associates. The sequence flow has no part in this.
Relevant languages for collaborations include bXML BPSS, RosettaNet, or W3C Choreography
Working Group. The mapping specification is planned for later versions of the BPMN
specification.
Collaboration processes can be integrated in pools. Interactions of the partners involved are
described in individual lanes. This allows the processes to be modeled separately or as part of
a comprehensive BPMN diagram. If a collaboration occurs in the same diagram as one of its
internal processes, activities common in both can be associated with each other.
In turn, various types of business processes can be derived from the three process classes:
 Private business processes at a higher level
 Private business processes at a detail level (target or actual processes)
 Processes running between detail processes and external entities
 Processes running between detail processes
 Processes running between detail processes and abstract processes
 Processes running between detail processes and collaboration processes
 Processes running between abstract processes
 Processes running between abstract processes and collaborations
 Processes running between collaborations
 Processes running between multiple detail processes interacting through their abstract
processes
 Processes running between multiple detail processes interacting through a collaboration
 Processes running between multiple detail processes interacting through their abstract
processes and a collaboration
The following figure shows an example of a BPMN collaboration diagram with two business
associates to which a separate process has been assigned. Both detail processes comprise a
175
METHOD MANUAL
start event, activities, sequence flow connections, and an end event. Message flow
connections are modeled between the activities of the two detail processes.
Figure 142: Two pools with sequence and message flow
As processes of multiple business associates can be shown in one BPMN collaboration

diagram and each business associate has a different view of the same process, it is useful to
specify a 'point of view'. The BPMN does not dictate how the point of view is to be emphasized
in a BPMN collaboration diagram. The easiest way is to specify the names of the assigned
business entities (business associates) in the Description/Definition attribute (see the
figure).
9.2 Implementation of BPMN in ARIS

Although BPMN supplies only the Business process diagram (BPD) model type, two model
types can be used in ARIS: the EPC and the new Business process diagram (BPD) model
type. In this way, processes existing in ARIS can be reused as private processes. The EPC has
all the model attributes that are specified by BPMN for the business process diagram. By
using the Business process diagram (BPD) model type, you keep existing models of the EPC
type free of B2B-specific aspects. As a result, the complexity of EPC models does not rise due
to additional relationship types.
The new business process diagram in turn inherits all BPMN-relevant model attributes from
the EPC and all sequence flow-relevant objects, connections, and symbols. The new Business
process diagram (BPD) model type allows sequence flow-relevant EPC concepts to be reused.
It is also possible to depict pools, lanes, and message flows.
176
METHOD MANUAL
9.3 Elements of the business process diagram
9.3.1 Pools and lanes

Pools give business process diagrams a clear structure.
A pool is a graphical container in which a set of activities of a business entity are combined.
A business entity can be a function, an application system, an organizational element
(including Organizational unit, Organizational unit type, Group, Role, Position, Person,
Location, System organizational unit, and System organizational unit type), or a data
element (including Technical term, Cluster/Data model, Entity type, Relationship type, ERM
attribute, Business object, Complex object type, COT attribute, Class, and Information carrier).
In BPMN, two pools represent two different business entities. The technique of structuring a
model into pools is typically used in a B2B context.
A pool combines a process partner's various activities that are structured and organized using
lanes. In this way, a differentiation is made to the activities of other process partners (see the
previous figure Two pools with sequence and message flow (page 174)).
In a BPD, pools need not necessarily contain process elements. It is also possible to insert an
empty pool ('black box') into a model, for example, for the purpose of integrating the
interrelationships of a subprocess (for example, of a business associate) that is involved, but
whose details are unknown into an overall process. Avoiding overcomplexity may be a reason
for not modeling details of a subprocess (see the figure E-mail voting process (page 189)).
Pools include at least one lane. A lane can in turn contain additional lanes that are nested or
defined as a matrix. If a pool has only one lane, the pool and the lane will have the same name.
If a pool includes more than one lane, lane names and a special pool name must be specified.
Figure 143: Pool with two lanes according to BPMN
In ARIS, pools and lanes are individual object types that are initially placed in the model. Within
the pool, the process can be modeled in a way similar to an EPC. All functions, events, and
rules of the process are placed on the pool object. Use the belongs to connection to describe
the association of these objects with a pool. We recommend that you create it as an implicit
177
METHOD MANUAL
relationship. A connection of the depicts type links the pool object to an organizational
element, application system type object, data element, or function. It should be noted that
each pool may have only one connection of this type throughout the given database. These
relationships should also be implicit.
According to BPMN specifications, a pool does not need to be represented in the model by a
symbol. Furthermore, the borders of a single pool may be hidden, especially if the diagram
contains only one pool (see the figure E-mail voting process (page 189)). However, these
options are not recommended for models containing multiple pools because this would affect
the model's transparency.
9.3.2Modeling guidelines for pools and lanes

 Only one pool may exist with invisible borders in a diagram.
 If the Pool type attribute was set to Collaboration, no owner (Person responsible
attribute) should be specified.
 Each lane may have only one superior pool.
9.3.3 Sequence flow

A process in the form of a sequence flow describes the sequence in which activities of a
process are performed. The sequence flow combines the Event, Activity, and Gateway
object types. Sequence flows are permitted only within pools and may not cross their borders
(see the following figure).
The sequence flow is represented by a solid line with a black arrow head:
Figure 144: Sequence flow connection
Appropriate connection types, such as activates, is evaluated by, creates, links, or leads to are
specified depending on the connection's source and target object type.
9.3.4 Modeling guidelines for sequence flow connections

 For sequence flows that follow an XOR (data-based) gateway or an inclusive gateway, a
value must be set for the Condition attribute.
 If the value Expression is set in the Condition attribute, the diamond symbol is to be
placed at the beginning of the connection.
178
METHOD MANUAL
 If the Condition attribute is set to Default and the source object is a function, the \
(backslash) character is to be placed as a symbol at the beginning of the connection.
 The \ (backslash) symbol must not be placed if the source object is a gateway.
 No condition should be set if the source object is one of the following symbols:
 Event-based gateway
 Complex gateway
 Parallel gateway
 Start event
 Intermediate event
 If the Default value is enabled in the Condition attribute for a sequence flow connection,
no condition must be specified.
 The Condition attribute may be set to Default if the source object is a function or an XOR
(data-based) gateway.
 If the value Expression is set in the Condition attribute, the Expression attribute must
also be specified.
9.3.5Message flow
A message flow describes the exchange of information between two pools. The message flow
can be placed either directly between two pool objects, or between objects in the sequence
flow of the processes in the corresponding pool. Only message flows are allowed to cross pool
borders, and a message flow connection must not be placed between two objects of the same
pool (see the figure Two pools with sequence and message flow (page 174)).
The connection is represented by a dashed line. The beginning of the line is marked by a
circle, and the end is a white arrow head.
Figure 145: Message flow connection
Each message flow comprises a sender object, a connection of the sends type, a connection
of the is received by type, and the recipient. No message flow connections may begin at a
start event or intermediate event. However, an end event does not receive message flows,
but can be a sender itself. Lanes, gateways, data objects, and text annotations do not have
message flows.
179
METHOD MANUAL
9.3.6 Modeling guidelines for message flow connections

Source and target objects must belong to different pools.
9.3.7 Association
An association is used to provide the sequence or message flow components with
information. This information can be of a textual or graphical nature. If multiple processes are
part of the same diagram, their individual process elements can be associated with each
other via connections.
An association is represented by a dotted line, to which open arrow heads may be added, if
required. This applies in particular when assignments of artifacts of the Data object type are
involved.
Figure 146: Association connections
Appropriate connection types, such as has as output, is input for, provides input for, or
creates output to are specified depending on the connection's source and target object
type.
In BPMN, the assignment of artifacts of the 'Data object' type to activities is of particular
importance.
This assignment is directed and describes how information is used and changed within a
process. It is implemented in the BPD (BPMN) using the following relationships:
Function - creates output to - data elements (especially information carriers)
Data element (especially information carrier) - provides input for - function
180
METHOD MANUAL
9.3.8 Events
An event is a state that occurs in the course of the business process. Events influence the
process flow. Normally, they represent triggers or effects within the processes. Depending on
when an event occurs, it is either a start event, an intermediate event, or an end event. The
three event categories are represented by their own symbols in BPMN:
Figure 147: Event categories
These categories are broken down into specialized subcategories. Additional symbols are
added to the symbols of the three event categories when the Event type attribute is
specified, as shown in the following three examples:
Figure 148: Examples of event types
All attributes relevant for the Event object type are combined in the BPMN attribute type
group.
181
METHOD MANUAL
9.3.9Modeling guidelines for events

 For start events, the Event type attribute type may have only one of the following values:
Message, Timer, Rule, Link, or Multiple.
 For end events, the Event type attribute type may have only one of the following values:
Message, Exception, Cancel, Compensation, Rule, Link, Multiple, or Terminate.
 For intermediate events, the Event type attribute type may have only one of the
following values: Message, Timer, Exception, Cancel, Compensation, Rule, Link, and
Multiple.
 Depending on the event type set, additional information must be specified in appropriate
attributes.
 A start event may have multiple outgoing sequence flow connections. No value must be
set for the Condition attribute of these connections.
 Intermediate events that indicate an exception or a compensation should be placed at the

border of the function.
 If an intermediate event is placed at the border of a function, a value other than Link
must be specified.
 The Multiple, Rule, and Cancel values must not be set for intermediate events that are
located within a normal sequence flow of a process.
 The value Cancel must not be set if
 the intermediate event is placed at the border of a function and the Transaction
attribute of the function is not enabled, or
 the event is not part of a process that describes a transaction.
 If an intermediate event is placed at the border of a function, it must not be the target
object of a sequence flow connection.
 If an intermediate event is located within the normal sequence flow of a process (that is,
it is not placed at the border of a function), it may have exactly one incoming sequence
flow connection. For the Event type attribute of the event, it is possible to specify no
value or one of the following values: Message, Timer, Exception, Link, Compensation.
182
METHOD MANUAL
 The value Link may be set for intermediate events in a normal sequence flow only if the
source object is a gateway whose Gateway type attribute has the value XOR
(event-based).
 Each intermediate event must have exactly one outgoing sequence flow connection.
 An intermediate event whose Event type attribute has the value Message may have an
incoming message flow (incoming connection of the is received by type).
 An intermediate event must not have an outgoing message flow (outgoing connection of
the sends type).
183
METHOD MANUAL
9.3.10 Activities
An activity is performed as part of a process. It can be atomic or non-atomic (compound).
BPMN uses three categories of activities: Process, Subprocess, and Task.
BPMN provides the following symbols for activities:
Figure 149: Activities according to BPMN
In ARIS, activities are modeled as functions by default:
Figure 150: Assigned function as activity in ARIS
The function is provided with all attributes that BPMN defines for processes, subprocesses,
and tasks. As with events, the BPMN attribute type group is used, which contains additional
subgroups for the activity types.
In terms of BPMN, a process describes an activity that is performed within a company or
organization. A process is described by a graph with flow objects that represent a set of
different activities and control objects. Processes are hierarchically structured and can be
defined at all levels of detail. In contrast to a process, a business process in BPMN describes a
set of activities that are performed across corporate/organizational boundaries.
In terms of BPMN, a subprocess is a combined activity with a detailed description. A
subprocess occurs as an object within a process flow.
Usually, a subprocess is assigned a detailed process. Unlike in BPMN, ARIS does not identify
an assigned activity by a plus sign, but by an assignment icon.
Besides identifying an assigned function, BPMN also provides the ability to show the detail
process at the next higher process level. This is done by clicking the plus sign.
184
METHOD MANUAL
9.3.11 Modeling guidelines for activities
PROCESS
 If the Ad hoc attribute is = True, the Completion condition attribute must be specified.
 If an ad hoc process is refined, no sequence flows must be modeled within the assigned
model.
SUBPROCESS
 If the value Independent is set for the Subprocess type attribute, the Process
reference attribute must also be specified.
 If the Transaction attribute is enabled for a subprocess, the Transaction ID attribute
must also be available.
 If the Loop type attribute is specified, the Loop condition attribute is also required.
 If models are to be transferred to BPEL4WS, a check is recommended to determine
whether the Loop type attribute is set to Maximum for processes with the value
Standard.
 If the value Standard is specified for the Loop type attribute, the Test before attribute
is also required. The Test before attribute should be disabled by default.
 If the value Multi-instance is specified for the Loop type attribute, the Parallel instance
generation attribute is also required. The Parallel instance generation attribute should
be disabled by default.
 If the Loop type attribute of a subprocess has the value Multi-instance and, at the same
time, the Parallel instance generation attribute is enabled, the Loop flow condition
attribute must be specified as well.
 If the value Complex is set for the Loop flow condition attribute in a process, an
expression that determines when and how many process markers are passed on after the
subprocess is complete must be specified for the Complex attribute.
TASK
 If the value Receive is specified for the Task type attribute, the function should not have
any outgoing message flow connections.
 If the value Send is specified for the Task type attribute, the function should not have
any incoming message flow connections.
 If the Task type attribute is not specified or the values Script or Manual are set, the
function should not have any incoming or outgoing message flow connections.
185
METHOD MANUAL
 For functions whose Task type attribute is set to Abstract, the Abstract type attribute
must also be specified. In addition, these functions may be used only in pools of the
Abstract type or in Collaborations.
9.3.12 Gateway
Gateways describe how sequence flows split or join within a process. They determine the
behavior of incoming and outgoing connections. In ARIS they are represented as objects of
the Rule type.
Similar to events, various types of gateways can be specified. Depending on the type, further
symbols are shown in the center of the Gateway symbol.
A few differentiating gateway symbols:
Figure 151: Gateway types
The BPMN specification stipulates that a number of gates must be defined for each gateway.
In ARIS the number of gates is determined by the number of incoming and outgoing
connections. Therefore, gate-dependent attributes are specified for the incoming and
outgoing sequence flow connections of the rule.
A special case is the complex gateway for which the Incoming condition and Outgoing
condition attributes are defined. These attributes are required if there are multiple incoming
or outgoing sequence flow connections for a given gateway. The attribute content of the
incoming condition can contain sequence flow names and process properties (data). The
outgoing condition contains references to sequence flow IDs and process characteristics
(data).
186
METHOD MANUAL
9.3.13 Modeling guidelines for gateways

 Gateways of the XOR (data-based) type: For all outgoing connections of an XOR
(data-based) gateway, the value Expression must be set for the Condition attribute, and
a valid expression must be used for the Condition expression attribute.
Sequence flow, especially after gateways
 For every XOR gateway of the XOR (data-based) type, the Default gateway attribute
should be specified for exactly one outgoing sequence flow connection (activates
connection type). Under no circumstances must multiple outgoing connections be
marked with this attribute.
 For each XOR gateway of the XOR (event-based) type there must be at least two
outgoing sequence flow connections (activates or leads to type).
 For all outgoing connections of an event-based XOR gateway, no value must be specified
for the Condition attribute. The Condition expression attribute should not be specified.
 The following target objects are permitted for outgoing sequence flow connections of an
event-based XOR gateway:
 Functions for which the Receive task type was set.
 Intermediate events whose Event type attribute type has a value other than
Compensation or Multiple.
 If there is a function in the set of target objects, this set must not contain an event of the
Message type.
 If a gateway of the OR type has no or exactly one incoming sequence flow connection,
there must be at least two outgoing sequence flow connections.
 For all outgoing sequence flow connections of an OR gateway, the value Expression
must be set for the Condition attribute, and a valid expression must be used for the
Condition expression attribute. The expression must unambiguously relate to the
current gateway.
 If an OR gateway has exactly one outgoing sequence flow connection, no value must be
specified for the Condition attribute of this connection.
 If a gateway of the Complex type has no or exactly one incoming sequence flow
connection, there must be at least two outgoing sequence flow connections.
 For all outgoing connections of a complex gateway, the value None must be specified for
the Condition attribute, especially if there is only one outgoing connection.
187
METHOD MANUAL
 If a complex gateway has multiple incoming sequence flow connections, a condition that
references the sequence flow names and process properties (data) must be specified for
the Incoming condition attribute.
 If a complex gateway has multiple outgoing sequence flow connections, a condition that
references the sequence flow names and process properties (data) must be specified for
the Outgoing condition attribute.
 If an AND gateway has no or exactly one incoming sequence flow connection, there must
be at least two outgoing sequence flow connections.
 For all outgoing sequence flow connections of an AND gateway, no value must be
specified for the Condition attribute.
188
METHOD MANUAL
9.3.14 Artifact
Artifacts provide information about the process. This information does not belong to the
sequence flow or message flow. A total of three artifact types are differentiated: Data
objects, Groups, and Annotations (the type list can be extended as required).
Data objects are comparable to information carriers or data elements in ARIS. However, in
the broadest sense they could encompass all assignments. Data objects influence neither the
sequence flow nor the message flow, instead they supply information about what happens
during the process. They show how documents, data, and other objects change during the
process.
A Group is a graphical emphasis of associated process elements. In ARIS, graphic objects,
such as rectangles or polygons are useful for this.
Alternatively, groupings may also serve this purpose. However, this only makes sense if the
grouping includes a graphic.
Annotations correspond to remarks about objects or connections, as in the following
example Time out [1week]. In ARIS they are often realized with the help of the
Remark/Example attribute. It is important that this attribute be placed in the model, as
shown in the following example with Yes and No.
189
METHOD MANUAL
Figure 152: E-mail voting process
190
METHOD MANUAL
This figure shows an example of how a business collaboration diagram is implemented in ARIS
according to BPMN 2.0. The diagram contains two pools, with the boundaries of the upper
pool hidden. The individual elements of the lower pool are not shown.
9.3.15 Sources of figures

Figure Two pools with sequence and message flow (page 174):
Business Process Modeling Notation, Working Draft (1.0); BPMI.org; August 25, 2003; page 85.
Figure Pool with two lanes according to BPMN (page 177):
Figure Event categories (page 181) and figure Examples of event types (page 181):
Figure Activities according to BPMN (page 184):
Figure Gateway types (page 186):
191
METHOD MANUAL
10 Modeling BPMN 2.0
10.1 Introduction
10.1.1 Initial situation and objective

BPMN (Business Process Modeling and Notation) has emerged as a widely adopted standard
for process modeling. Its popularity is based on the fact that it is has been developed by the
Object Management Group (OMG), a consortium of organizations that also released other
important modeling standards like UML.
The primary goal of BPMN is to provide a notation that is understandable by all users:
business analysts designing and documenting business processes, developers implementing
these business processes, and business end users executing, managing and monitoring their
business processes. Now, the OMG released a new version of BPMN 2.0. This standard shall be
supported by ARIS. In a first step, the objective is to focus on process modeling conformance,
one of four conformance types defined by the OMG.
The four conformance types are described in detail in the BPMN specification: Business
Process Model and Notation (BPMN), version 2.0.
10.1.2 Purpose of this chapter

Unfortunately the BPMN specification has increased an order of magnitude in technical
complexity and fails to distinguish those elements needed for business process modeling
from those required for process execution.
The purpose of this chapter is to describe the ARIS implementation of the BPMN 2.0 elements
that are part of business process modeling documenting the process flow. Those parts that
are needed for executable design are ignored. The elements relevant for business process
modeling are essentially those displayed in a diagram.
The mapping described in the chapters of this document is based on the BPMN specification
Business Process Model and Notation (BPMN), version 2.0 (http://www.bpmn.org).
The attribute and model association tables are also taken from the BPMN 2.0 specification
and extended to describe the implementation in ARIS.
192
METHOD MANUAL
10.2 BPMN core elements and their implementation in ARIS

The BPMN core consists of four packages:
 Foundation
 Infrastructure
 Common Elements as well as
 Service
It provides the basis for modeling processes, collaborations, choreographies and
conversations. These packages are described in detail in chapter 8 of the BPMN specification.
In the following sections the core constructs and their attributes and associations are
mapped to ARIS constructs.
10.2.1 Infrastructure
The infrastructure package consists of two elements which are particularly relevant for
import and export. Thus, their attributes and model associations are not included in the
current version of the BPMN 2.0 implementation.
See: Business Process Model and Notation (BPMN), Version 2.0.
193
METHOD MANUAL
10.2.2 Foundation
The foundation package contains classes which are shared amongst other packages in the
BPMN core. The foundation package consists of eight classes: BaseElement, Documentation,
RootElement, Extension, Extension Definition, ExtensionAttributeDefinition,
ExtensionAttributeValue and Relationship. See: Business Process Model and Notation (BPMN),
version 2.0.
MAPPING THE ATTRIBUTES AND MODEL ASSOCIATIONS TO ARIS
Class BPMN attribute name Implementation in ARIS

BaseElement id: string The ARIS GUID of the corresponding
modeling construct represents the
BPMN ID.
For imported BPMN elements an
attribute type in the attribute type
group Attributes of external
systems will be used.
documentation: see below: Documentation

Documentation [0..*]
extensionDefinitions: ARIS Method can be enhanced, for

ExtensionDefinition [0..*] example, by user-defined attributes.
extensionValues: The ARIS Method can be enhanced,

ExtensionAttributeValue for example, by user-defined
[0..*] attributes.
Documentation inherits from BaseElement
text: string All ARIS attribute types assigned to

model types, object types, and
connection types can be used for
documentation purposes. The
attribute types
Description/Definition (AT_DEC) and
Remark/Example (AT_REM) should
be used to for general information.
Specific attribute types should be
used to store specific information.
194
METHOD MANUAL

Extension mustUnderstand: boolean Currently not implemented.
[0..1] = False
definition:
ExtensionDefinition
ExtensionDefinition name: string Currently not implemented.
extensionAttributeDefinition
s:
ExtensionAttributeDefinition
[0..*]
ExtensionAttribute name: string Currently not implemented.

Definition
type: string
isReference: boolean [0..1] =

False
ExtensionAttribute value: Element [0..1] Currently not implemented.

Value
valueRef: Element [0..1]
extensionAttributeDefinition:
ExtensionAttributeDefinition
Relationship inherits from BaseElement Currently not implemented.
type: string
direction:
RelationshipDirection {none |
forward | backward | both}
sources: Element [1..*]
targets: Element [1..*]
RootElement inherits from BaseElement RootElement is an abstract class, it

has no direct representation in ARIS.
For example, ARIS object types are
root elements, ARIS attribute types
are not.
195
METHOD MANUAL
10.2.3 Common Elements

Common Elements are basic elements that may be used in more than one type of diagram, for
example, Process, Collaboration, Conversation, and Choreography. The Common Elements are
categorized into seventeen different groups.
10.2.3.1 Artifacts
Artifacts are used to depict additional information in a BPMN process diagram (BPMN2.0) or
BPMN collaboration diagram (BPMN2.0) that is not directly related to the sequence flow or
message flow. BPMN 2.0 provides three standard artifacts:
 Associations,
 Groups, and
 Text annotations
Data objects are no longer artifacts, they are concepts of their own (see chapter Items and
Data (page 243)).
See: Business Process Model and Notation (BPMN), version 2.0.

Association inherits from BaseElement various connection types
associationDirection: This attribute is represented by the

AssociationDirection = None direction and the style of the corresponding
{None | One | Both} ARIS connection type.
sourceRef: BaseElement Corresponds to the source object type of

the connection type representing the
association.
targetRef: BaseElement Corresponds to the target object type of the

connection type representing the
association.
196
METHOD MANUAL

Group inherits from BaseElement Object type: Structural element
(OT_STRCT_ELMT)
Symbol: Structural element in model type
Structuring model (MT_STRCT_DGM)
Symbol: Group (ST_BPMN_GROUPING_1)
categoryValueRef: Attribute type Name (AT_NAME) of object

CategoryValue [0..1] type Structural element (OT_STRCT_ELMT)
Category inherits from BaseElement Object type Structural element

(OT_STRCT_ELMT) in model type
categoryValue: Connection type in model type Structuring

CategoryValue [0..*] model:
* Structural element (representing the
category) contains structural element
(representing the category value).
CategoryValue inherits from BaseElement Object type: Structural element

(OT_STRCT_ELMT)
Symbol: Structural element in model type
Symbol: Group (ST_BPMN_GROUPING_1) in
BPMN 2.0 diagrams
value: string Attribute type Name of object type

Structural element
category: Category [0..1] Connection type in model type Structuring

model:
* Structural element (representing the
category) contains structural element
(representing the category value).
197
METHOD MANUAL

categorizedFlowElements: Connection type belongs to
FlowElement [0..*] [CT_BELONGS_TO_1] in the BPMN process
diagram (BPMN 2.0) and BPMN collaboration
diagram (BPMN 2.0):
Target object type: Structural element
(OT_STRCT_ELMT;
ST_BPMN_GROUPING_1)
Source object types:
* Function (OT_FUNC) representing
activities
* Event (OT_EVT)
* Rule (OT_RULE) representing Gateways
* Cluster/data model (OT_CLST)
representing data objects
* Information carrier (OT_INFO_CARR)
representing data stores
Text annotation inherits from BaseElement
198
METHOD MANUAL

text: string For object types in the BPMN process
diagram (BPMN 2.0), BPMN collaboration
diagram (BPMN 2.0), and BPMN
conversation diagram (BPMN 2.0):
* Text annotation
(OT_BPMN_ANNOTATION) with symbol
Text annotation
(ST_BPMN_ANNOTATION_1) is associated
with <target object type>. Target object
types are all object types available in the
corresponding model type.
For connection types in the BPMN process
diagram (BPMN 2.0), BPMN collaboration
diagram (BPMN 2.0), and BPMN
conversation diagram (BPMN 2.0): three
attribute types in the attribute type group
BPMN 2.0 attributes/Text annotation
attributes:
* Text annotation 1
(AT_BPMN_TEXT_ANNOTATION_1)
* Text annotation 2
* Text annotation 3
199
METHOD MANUAL
10.2.3.1.1 Association
Associations are used to associate information and artifacts with other BPMN elements. Thus,
associations are (usually) represented by connection types in ARIS. The relevant connection
types are described in the context of the object types being associated.
10.2.3.1.2 Group
BPMN 2.0 uses three different classes to represent groupings, but there is only one symbol:
Group. Thus, a group is the graphical representation of a category value.
Categories and their category values are modeled in an auxiliary model of type Structuring
model.
Figure 153: Structuring model: Categories and their values
In ARIS the graphical element Group is an occurrence copy of a category value object and is
depicted by a special symbol in the BPMN 2.0 models. The symbol name is Group.
Figure 154: Group symbol
200
METHOD MANUAL
10.2.3.1.3 Text annotation

Text annotations are used to provide additional textual information for the reader of a BPMN
model. They can be associated with graphical elements in a model, ARIS objects and
connections.
Figure 155: Symbol representing text annotations
Text annotations are implemented in ARIS in 2 different ways:
TEXT ANNOTATIONS ASSOCIATED WITH ARIS OBJECTS

The object type Text annotation and the connection type is associated with is used to
annotate objects (occurrences) in a model.
TEXT ANNOTATIONS ASSOCIATED WITH ARIS CONNECTIONS

Objects (here: Text annotation) cannot be assigned to connections. Thus, the program
provides a new functionality: The modeler selects the text annotation symbol in the Symbols
bar, places it on/near by the connection he/she wants to annotate and enters the text. The
program draws a line looking like an association and stores the text in a Text annotation
attribute of the corresponding connection. In the first step three text annotation attributes
are provided in the attribute type group BPMN 2.0 attributes/BPMN text annotations:
Text annotation 1 (AT_BPMN_TEXT_ANNOTATION_1)
201
METHOD MANUAL
10.2.3.2 Callable Elements

Callable Element is an abstract class and has four specialized classes: Process, Global task,
Choreography, and Choreography task. Only processes and global tasks are relevant for
business process modeling compliance. They are represented by the object type Function.

Callable Element inherits from BaseElement Object type: Function (OT_FUNC)
Symbol: Call activity
(ST_BPMN_CALL_ACTIVITY)
name: string [0..1] Attribute type Name (AT_NAME)

of object type Function
(OT_FUNC)
supportedInterfacesRefs: Currently not implemented.

Interface [0..*]
ioSpecification: Currently not implemented.

InputOutputSpecification [0..1]
ioBinding: InputOutputBinding Currently not implemented.

[0..*]
InputOutputBinding inputData: DataInput Currently not implemented.
outputData: DataOutput Currently not implemented.
operationRef: Operation Currently not implemented.
10.2.3.3 Event
Events are described in detail in the context of the BPMN process diagram (see chapter
Events (page 247)).
202
METHOD MANUAL
10.2.3.4 Expression
FormalExpressions belong to the execution design level and are not included in the current
version of the BPMN 2.0 implementation.
However, natural-language expressions are used to allow the modeler to specify conditions.
They are described in the context of the corresponding BPMN elements (object types and
connection types).
10.2.3.5 Flow Element

Flow Elements are described in detail in the context of the BPMN process diagram (see
chapter Process (page 219)).

FlowElement inherits from BaseElement No direct representation in ARIS ->
abstract class
name: string [0..1] Attribute type Name (AT_NAME) of the

object types representing flow nodes.
auditing: Auditing [0..1] Currently not implemented.
monitoring: Monitoring [0..1] Currently not implemented.
203
METHOD MANUAL
10.2.3.6 Flow Elements Container

A FlowElementsContainer is an abstract super class for BPMN diagrams (or views). So,
Processes and Subprocesses as well as Choreographies and Choreography subprocess are
FlowElementsContainers.
The specific attributes and model associations of a process and subprocess are described in
detail in the context of the BPMN process diagram.

FlowElementsContainer inherits from Model type BPMN process diagram
BaseElement (BPMN 2.0)
(MT_BPMN_PROCESS_DIAGRAM)
flowElements: Occurrences of the object types and

FlowElement [0..*] connection types allowed in a BPMN
process diagram (BPMN 2.0).
artifacts: Artifact [0..*] Occurrences of the object types and

attribute types representing groups
and text annotations as well as their
connection types allowed in the
BPMN process diagram (BPMN 2.0).
204
METHOD MANUAL
10.2.3.7 Gateways
Gateways are described in detail in the context of the BPMN process diagram (see chapter
Gateways (page 261)).

Gateway inherits from FlowElement Object type: Rule (OT_RULE)
gatewayDirection: GatewayDirection = The number of incoming and

unspecified outgoing sequence flows depends
{ unspecified | converging | diverging | on the modeling context, that is, the
mixed } position of the gateway in the
process. Thus, there is no ARIS
attribute type representing the
gateway direction. Gateways whose
direction is unspecified or mixed
should be avoided.
205
METHOD MANUAL
10.2.3.8 Message
Messages normally represent information exchanged between two participants in a BPMN
collaboration diagram.
A message is represented by the symbol Message of the ARIS object type Message.
Figure 156: Message symbol
See: Business Process Modeling Notation (BPMN), version 2.0, page 93 and the following.

Message inherits from BaseElement Object type: Message (OT_MSG_FLW)
Symbol: Message (ST_BPMN_MESSAGE_2)
name: string Attribute type Name (AT_NAME) of object

type Message (OT_MSG_FLW)
structureRef : ItemDefinition Currently not implemented.

[0..1]
206
METHOD MANUAL
10.2.3.9 Message flow

The message exchange between participants is shown by a message flow that connects two
pools or the objects within the pools.
Figure 157: Message flow between participants/pools
A message flow is represented in ARIS by the connection type message flow. If the message
sent from one participant to another should be displayed in the diagram, the connection type
message flow is replaced by the object type Message (symbol Message) and two connection
types:
 <Source object type> sends message.
 Message is received from <target object type>.
More details can be found in chapter Message flow (page 270).
Message flow associations are used to map message flows modeled in two different
diagrams, for example, in a conversation and a collaboration diagram. These associations are
realized in ARIS by occurrence copies of the message flow connections.
Message flow is also described in the context of the BPMN collaboration diagram (chapter
Message flow (page 270)) and the BPMN conversation diagram (chapter Message flow in a
conversation (page 274)).
207
METHOD MANUAL

message inherits from BaseElement Connection type: message flow
flow (CT_BPMN_MESAGE_FLOW)
name: string Attribute type Connection role of

connection type message flow
(CT_BPMN_MESSAGE_FLOW)
sourceRef: Source object type of connection type

MessageFlowNode message flow (CT_BPMN_MESAGE_FLOW)
(Participant, Function, Event)
targetRef: Target object type of connection type

MessageFlowNode message flow (CT_BPMN_MESAGE_FLOW)
(Participant, Function, Event)
messageRef: Message [0..1] Object type: Message (OT_MSG_FLW)

Symbol: Message (ST_BPMN_MESSAGE_2)
Connection types in the BPMN collaboration
diagram (BPMN 2.0):
* Participant sends (CT_SENDS_2) message.
* Event sends (CT_SENDS_2) message.
* Function sends (CT_SENDS_2) message.
* Message is received from
(CT_IS_RECEIVED_FROM) participant.
(CT_IS_RECEIVED_FROM) function.
(CT_IS_RECEIVED_FROM) event.
Flow node Object types that can be the source or target

of message flow
(CT_BPMN_MESSAGE_FLOW) connection
type: Participant (OT_BPMN_POOL),
Function (OT_FUNC), Event (OT_EVT)
Message flow inherits from BaseElement This association is used to map message
association flows modeled in a collaboration and a
conversation diagram.
208
METHOD MANUAL

innerMessageFlowRef: Occurrence copy of a message flow
Message Flow connection in a BPMN collaboration diagram
and BPMN conversation diagram.
outerMessageFlowRef: Occurrence copy of a message flow

Message Flow connection in a BPMN collaboration diagram
and BPMN conversation diagram.
10.2.3.10 Participant
A participant represents a Partner entity and/or a Partner role that participates in a
collaboration. Participants may be modeled in a BPMN collaboration diagram or a BPMN
conversation diagram.
The assignment of a Partner entity and/or a Partner role to a participant is transferred to the
BPMN allocation diagram (BPMN 2.0) assigned to the participant.
Figure 158: BPMN allocation diagram (BPMN 2.0): Participant and partner entity/partner role
The usage of participants is described in the context of the BPMN collaboration diagram (see
chapter Pool and participant (page 268)) and the BPMN conversation diagram (see chapter
Participant (page 273)).
Participant, Partner entity and Partner role inherit from base element
209
METHOD MANUAL

Participant inherits from BaseElement Object type: Participant
(OT_BPMN_POOL)
Symbol: Pool (ST_BPMN_POOL_1)
name: string [0..1] Attribute type Name (AT_NAME) of

object type Participant
(OT_BPMN_POOL)
processRef: Process [0..1] BPMN process diagram (BPMN 2.0)

assigned to the participant
(OT_BPMN_POOL
Process displayed within in the pool
partnerRoleRef: PartnerRole Model type: BPMN allocation diagram

[0..1] (BPMN 2.0):
Object type: Role (OT_PERS_TYPE)
Symbol: Partner role
(ST_BPMN_PARTNER_ROLE)
Connection type: depicts
(CT_DEPICTS_1) Role
partnerEntityRef: Model type: BPMN allocation diagram

PartnerEntity [0..1] (BPMN 2.0):
Object type: Organizational unit
(OT_ORG_UNIT)
Symbol: Partner entity
(ST_BPMN_PARTNER_ENTITY)
Connection type: depicts
(CT_DEPICTS_1) organizational unit
interfaceRef: Interface [0..*] Currently not implemented.
210
METHOD MANUAL

participantMultiplicity: Attribute type in the attribute type
participantMultiplicity [0..1] group BPMN 2.0
attributes/Participant multiplicity
attributes of the object type
Participant (OT_BPMN_POOL):
* Multi-instance participant
(AT_BPMN_MI_PARTICIPANT)
The mini-symbol (three vertical lines) is
displayed by the program if the value of
the attribute type Multi-instance
participant is set to true.
endpointRefs: EndPoint [0..*] Currently not implemented.
Partner entity inherits from BaseElement Object type: Organizational unit

(OT_ORG_UNIT)
Symbol: Partner entity
(ST_BPMN_PARTNER_ENTITY)
name: string Attribute type Name (AT_NAME) of

object type Organizational unit
(OT_ORG_UNIT)
Partner role inherits from BaseElement Object type: Role (OT_PERS_TYPE)

Symbol: Partner role
(ST_BPMN_PARTNER_ROLE)
name: string Attribute type Name of object type Role

(OT_PERS_TYPE)
Participant minimum: integer [0..1] = 2 Attribute type in the attribute type

Multiplicity group BPMN 2.0
* Minimum participant multiplicity
(AT_BPMN_MINIMUM_MI_PARTICIPAN
T)
211
METHOD MANUAL

maximum: integer [0..1] = 2 Attribute type in the attribute type
group BPMN 2.0
* Maximum participant multiplicity
(AT_BPMN_MAXIMUM_MI_PARTICIPAN
T)
Participant inherits from BaseElement

Association
innerParticipantRef: Occurrence copy of the relevant

Participant participant.
outerParticipantRef: Occurrence copy of the relevant

Participant participant.
212
METHOD MANUAL
10.2.3.11 Resource
Resources can be human resources as well as any other resource assigned to activities during
process execution. A direct mapping of the BPMN resources to ARIS constructs is not possible
- due to the semantically different object types representing resources in ARIS. ARIS does not
only provide different object types, but also different connection types.
BPMN 2.0 only knows one object type called Resource. The BPMN ActivityResource and its
specialized sub-classes correspond to ARIS connection types in combination with object
types. Therefore, resources are not included in the current version of the BPMN 2.0
implementation.
10.2.3.12 Sequence flow

The BPMN Sequence flow is mapped to nine different ARIS connection types, which are used
to depict the control flow in traditional ARIS process models.
Source object type Connection type Target object type

Event occurs before Event
Event activates Function
Event is evaluated by Rule
Function creates Event
Function is predecessor of Function
Function leads to Rule
Rule leads to Event
Rule activates Function
Rule links Rule
213
METHOD MANUAL
BPMN distinguishes three types of sequence flow:

 Unconditional sequence flow
The unconditional sequence flow means the normal flow, no specific conditions apply. In
other words: its condition has always the value true. It is depicted by a solid line with a
solid arrowhead.
 Conditional sequence flow

The conditional sequence flow from an activity is drawn with a little diamond at the
beginning of the connector, signifying a data condition. A conditional sequence flow from
a gateway shares the same shape as a normal sequence flow.
Conditional sequence flow from an activity:
 Default sequence flow

The default sequence flow, denoted by a slash marker at the beginning of the connector
means otherwise, that is, it is enabled if no other sequence flow condition evaluates to
true.
All connection types used in BPMN diagrams must hold attributes for recording text
annotations (page 201). Connection types emerging from activities and gateways need
additional attributes for recording sequence flow conditions.
214
METHOD MANUAL

Sequence inherits from FlowElement The sequence flow is depicted by nine
flow different connection types in the model
types BPMN process diagram (BPMN 2.0)
(MT_BPMN_PROCESS_DIAGRAM) and BPMN
collaboration diagram (BPMN 2.0)
(MT_BPMN_COLLABORATION_DIAGRAM):
* event occurs before (CT_SUCCEED) event
* event activates (CT_ACTIV_1) function
* event is evaluated (CT_IS_EVAL_BY_1) by
rule
* function creates (CT_CRT_1) event
* function is predecessor of
(CT_IS_PREDEC_OF_1) function
* function leads (CT_LEADS_TO_1) to rule
* rule leads to (CT_LEADS_TO_2) event
* rule activates (CT_ACTIV_1) function
* rule links (CT_LNK_2) rule
name: string Attribute type Connection role of connection

type Message flow
(CT_BPMN_MESSAGE_FLOW)
sourceRef: FlowNode Source object of a sequence flow

connection. Object types are:
* Function
* Event
* Rule
targetRef: FlowNode Target object of a sequence flow connection.

Object types are:
* Function
* Event
* Rule
215
METHOD MANUAL

conditionExpression : Attribute type Condition expression
Expression [0..1] (AT_BPMN_CONDITION_EXPRESSION) in
attribute type group BPMN 2.0 attributes of
the following connection types:
* activates (CT_ACTIV_1)
* creates (CT_CRT_1)
* links (CT_LNK_2)
* leads to (CT_LEADS_TO_1)
* leads to (CT_LEADS_TO_2)
* is predecessor of (CT_IS_PREDEC_OF_1)
The value of the attribute type Sequence
flow condition in the attribute type group
BPMN 2.0 attributes must be set to
Conditional sequence flow.
isImmediate: boolean Currently not implemented.
Flow node incoming: Sequence Flow Incoming connections representing the

[0..*] sequence flow of the flow node object
(object types: function, event, rule)
outgoing: Sequence Flow Outgoing connections representing the

[0..*] sequence flow of the flow node object
(object types: function, event, rule)
216
METHOD MANUAL
10.2.3.13 Elements not included in the current

implementation
The following elements belong to the execution design level and are not included in the
current version of the BPMN 2.0 implementation.
 Correlations (See: Business Process Modeling Notation (BPMN), version 2.0, page 136 and
the following.)
 Conversation Associations (See: Business Process Modeling Notation (BPMN), version 2.0,
page 135 and the following.)
 Error (See: Business Process Modeling Notation (BPMN), version 2.0, page 81 and the
following.)
 Interaction node (See: Business Process Modeling Notation (BPMN), version 2.0, page
123.)
 Item definition (See: Business Process Modeling Notation (BPMN), version 2.0, page 91
and the following.)
 Services (See: Business Process Modeling Notation (BPMN), version 2.0, page 104 and the
following.)
217
METHOD MANUAL
10.3 BPMN diagrams and ARIS model types: An overview

According to the BPMN 2.0 specification three diagram types are required for process
modeling conformance: Process diagram, Collaboration diagram and Conversation diagram
(See: Business Process Modeling Notation (BPMN), version 2.0. Page 2).
A careful consideration of these BPMN diagrams shows that the modeling constructs of the
process diagram are a subset of the modeling constructs used in the collaboration diagram.
There are also overlapping constructs in the collaboration and conversation diagram.
The model types listed in the following table are available in ARIS.
The BPMN allocation diagram allows the mapping of BPMN attributes and associations to the
semantically richer ARIS Method where graphical elements are often used to represent BPMN
attributes and associations.
BPMN diagram ARIS model type

Process diagram BPMN process diagram (BPMN 2.0)
Process diagram Enterprise BPMN process diagram
Collaboration diagram BPMN collaboration diagram (BPMN 2.0)
Collaboration diagram Enterprise BPMN collaboration diagram
Conversation diagram BPMN conversation diagram (BPMN 2.0)
BPMN allocation diagram (BPMN 2.0)
In models of types Enterprise BPMN process diagram and Enterprise BPMN collaboration
diagram, the following object types of the ARIS Method are available as lane symbols in
addition to the BPMN 2.0 specification:
 Application system type
 Organizational unit
 Position
 Role
 Group
In models of type Enterprise BPMN process diagram and Enterprise BPMN collaboration
diagram, the following additional connections to task objects are available in addition to the
BPMN 2.0 specification:
 Application system type supports Task
 Organizational unit supports Task
218
METHOD MANUAL
 Position carries out Task

 Role carries out Task
 Group carries out Task
10.4 Process
The BPMN process diagram depicts a BPMN process. A process is a specialization of a
FlowElementsContainer. So, it contains the following elements:
 flow nodes (event, activity, and gateway)
 sequence flow
 artifacts (see chapter Artifacts (page 196))

Process inherits from CallableElement Model type: BPMN process diagram (BPMN
inherits from 2.0)
FlowElementsContainer
processType: ProcessType = Attribute type in the attribute type group BPMN

none 2.0 attributes of model type BPMN process
{ none | executable | diagram (BPMN 2.0):
non-executable | public } * Process type (AT_BPMN_PROCESS_TYPE)
Attribute values:
* Undefined (= none),
* Executable process
(AVT_BPMN_EXECUTABLE),
* Non-executable process
(AVT_BPMN_NON_EXECUTABLE)
* Public process (AVT_BPMN_PUBLIC)
auditing: Auditing [0..1] Currently not implemented.
monitoring: Monitoring [0..1] Currently not implemented.
laneSets: LaneSet [0..*] Object type Lane (OT_BPMN_LANE)

Symbol: Lane (ST_BPMN_LANE_1)
219
METHOD MANUAL

IsClosed: boolean = false Attribute type Is closed
(AT_BPMN_IS_CLOSED) in attribute type
group BPMN 2.0 attributes of the BPMN
process diagram
supports: Process [0..*] Currently not implemented.
properties: Property [0..*] Currently not implemented.
definitionalCollaborationRef: The BPMN collaboration diagram (BPMN 2.0)

Collaboration [0..1] that contains the process
A process is a particular construct: On the one hand it is a model. On the other hand a process
can be visualized within a pool in a collaboration. But a pool is not identical with a process,
and vice versa. A pool represents a participant in a collaboration (see chapter Collaboration
(page 267)). A pool may contain the process the participant uses in a specific collaboration.
The core elements for modeling a BPMN process are those constructs which can be
connected to each other by sequence flow. They are called flow nodes. The corresponding
ARIS object types and their symbols provided in the Symbols bar are listed in the table below.
BPMN ARIS object type ARIS symbol API name

element
Event Event (OT_EVT) Start event ST_BPMN_START_EVENT
Intermediate event ST_BPMN_INTERMEDIATE_EVEN
End event T
ST_BPMN_END_EVENT
Activity Function (OT_FUNC) Task ST_BPMN_TASK

Subprocess ST_BPMN_SUBPROCESS
Call activity ST_BPMN_CALL_ACTIVITY
Gateway Rule (OT_RULE) Gateway ST_BPMN_RULE_1
These constructs are described in detail in the separate chapters below.
220
METHOD MANUAL
10.4.1 Activities
The BPMN activity is represented by the ARIS object type Function.
BPMN 2.0 differentiates three basic types of activities: task (atomic activity), subprocess
(non-atomic activity) and call activity. The symbols depicting these activity types are
provided in the ARIS Symbols bar.
Figure 159: Symbols representing activities in the Symbols bar
When the modeler places an activity symbol, the software sets the corresponding value of the
ARIS attribute type Activity type (AT_BPMN_ACTIVITY_TYPE). This activity type controls
the correct behavior of the symbol. For example: A subprocess may have embedded flow
elements, a task must not; a call activity may reference another task or process, tasks and
subprocesses must not.
221
METHOD MANUAL

Activity inherits from FlowElement Object type: Function (OT_FUNC)
Attribute type Activity type
(AT_BPMN_ACTIVITY_TYPE) in the
attribute type group BPMN 2.0 attributes
of object type Function
Attribute values:
* Task (AVT_BPMN_TASK)
* Subprocess (AVT_BPMN_SUBPROCESS)
* Call activity
(AVT_BPMN_CALL_ACTIVITY)
Compensation activity:: boolean Attribute type Compensation activity:

= false (AT_BPMN_COMPENSATION_ACTIVITY.TR
M=Compensation activity) in the attribute
type group BPMN 2.0 attributes of object
type Function
loopCharacteristics: see below: Loop characteristics

LoopCharacteristics [0..1]
resources: ActivityResource Currently not implemented.

[0..*]
default: SequenceFlow [0..1] Attribute type Sequence flow condition

(AT_BPMN_SEQ_FLOW_CONDITION) in the
attribute type group BPMN 2.0 attributes
of the following conenction types:
* Activity creates ...,
* Activity is predecessor of ...,
* Activity leads to ...
The attribute value must be set to Default
sequence flow.
ioSpecification: Currently not implemented.

InputOutputSpecification [0..1]
properties: Property [0..*] Currently not implemented.
222
METHOD MANUAL

boundaryEventRefs: Connection type: Function can trigger event
BoundaryEvent [0..*] CT_BPMN_CAN_TRIGGER
dataInputAssociations: Currently not implemented.

DataInputAssociation [0..*]
dataOutputAssociations: Currently not implemented.

DataOutputAssociation [0..*]
startQuantity: integer = 1 Currently not implemented.
Class completionQuantity: integer = 1 Currently not implemented.
223
METHOD MANUAL
10.4.1.1 Resource assignment

Resource assignments are not included in the current version of the BPMN 2.0
implementation. They will be dealt with in detail when implementing the execution design
level in ARIS.
10.4.1.2 Performer
Resource assignments are not included in the current version of the BPMN 2.0
implementation. They will be dealt with in detail when implementing the execution design
level in ARIS.
224
METHOD MANUAL
10.4.1.3 Activity type: Task

See: Business Process Model and Notation (BPMN).
BPMN 2.0 distinguishes eight task types which are represented by different symbols (see ).
Only the Abstract task is available in the Symbols bar. The symbols of the remaining seven
special task types are not available in the Symbols bar, they are handled by the program.
Figure 160: Task symbols
When the modeler selects a specific task symbol the software sets the corresponding value of
the ARIS attribute type Task type. This attribute type is read-only. It provides the following
values: Abstract task, Business rule task, Manual task, Script task, Send task, Service task,
Receive task, and User task.

Task inherits from Activity The value of the attribute type Activity
type (AT_BPMN_ACTIVITY_TYPE) is set to
Task in the attribute type group BPMN 2.0
attributes of object type Function.
Object type: Function (OT_FUNC)
Symbol: Task (ST_BPMN_TASK) or a special
task symbol (see below)
225
METHOD MANUAL

Service inherits from Activity The value of the attribute type Task type
task (AT_BPMN_TASK_TYPE) is set to Service
task in the attribute type group BPMN 2.0
attributes/Task attributes of object type
Function
Symbol: Service task
(ST_BPMN_SERVICE_TASK)
implementation: Currently not implemented.

Implementation = Web Service
{Web Service | Other |
Unspecified}
operationRef: Operation [0..1] Currently not implemented.
Send task inherits from Activity The value of the attribute type Task type
(AT_BPMN_TASK_TYPE) is set to Send
Function.
Symbol: Send task (ST_SEND_TASK)
messageRef: Message [0..1] Connection type in the BPMN collaboration

diagram (BPMN 2.0)
* Function sends message.

{Web Service| Other |
Unspecified}
226
METHOD MANUAL

Receive inherits from Activity The value of the attribute type Task type
task (AT_BPMN_TASK_TYPE) is set to Receive
task in the attribute type group BPMN
2.0 attributes/Task attributes of object
type Function.
Symbol: Receive task (ST_RECEIVE_TASK)
messageRef: Message [0..1 Connection type in the BPMN collaboration

diagram (BPMN 2.0)
* Message is received from function
Instantiate: boolean = False Currently not implemented.

{Web Service | Other |
Unspecified}
User task inherits from Activity The value of the attribute type Task type
(AT_BPMN_TASK_TYPE) is set to User
Function.
Symbol: User task (ST_USER_TASK)
Implementation: Currently not implemented.

UserTaskImplementation =
Other
{HumanTaskWebService |
WebService | Other |
Unspecified}
renderings: Rendering [0..*] Currently not implemented.
227
METHOD MANUAL

Manual inherits from Activity The value of the attribute type Task type
task (AT_BPMN_TASK_TYPE) is set to Manual
Function.
Symbol: Manual task (ST_MANUAL_TASK)
Business inherits from Activity The value of the attribute type Task type
Rule Task (AT_BPMN_TASK_TYPE) is set to Business
rule task in the attribute type group BPMN
2.0 attributes/Task attributes of object
type Function.
Symbol: Business rule task
(ST_BUSINESS_RULE_TASK)
Implementation: Currently not implemented.

BusinesRuleTaskImplementatio
n = Other
{BusinessRuleWebService |
WebService | Other |
Unspecified}
Script task inherits from Activity The value of the attribute type Task type
(AT_BPMN_TASK_TYPE) is set to Script
Function.
Symbol: Script task (ST_SCRIPT_TASK)
scriptLanguage: string [0..1] Currently not implemented.
script: string [0..1] Currently not implemented.
228
METHOD MANUAL
10.4.1.4 Human interactions

User tasks and manual tasks are relevant for modeling human interactions. Their attributes
and model associations can also be found in chapter Activity type: Task (page 224). They will
be dealt with in detail when implementing the execution design level in ARIS.
10.4.1.5 Activity type: Subprocess

BPMN 2.0 knows four types of subprocesses:
 Subprocess (standard)
(A ([standard] subprocess corresponds to the embedded subprocess in BPMN 1.x.)
 Event subprocess
 Transaction, and
 Ad hoc subprocess
Each type of a subprocess can be displayed as
 Subprocess (collapsed) or
 Subprocess (expanded)
Collapsed subprocesses have a special marker displayed at the bottom of the corresponding
subprocess symbol:
229
METHOD MANUAL
10.4.1.5.1 Subprocess type: Subprocess

A standard subprocess shares the same shape as a task. In the collapsed form, the
subprocess object uses the +-marker to distinguish it from a task. Expanded subprocesses
have no marker, they reveal their embedded objects.
The symbol representing the expanded subprocess is available in the Symbols bar, the
symbol representing the collapsed subprocess is handled by the software.
Figure 161: Symbols of a standard subprocess
The attributes and model associations of a subprocess and their mapping to ARIS constructs
are listed in the table below.
230
METHOD MANUAL

Subprocess inherits from Activity The value of the attribute type Activity
inherits from type (AT_BPMN_ACTIVITY_TYPE) is set to
FlowElementsContainer Subprocess in the attribute type group
BPMN 2.0 attributes of object type
Function.
Symbols:
* Subprocess (ST_BPMN_SUB_PROCESS)
* Subprocess collapsed
(ST_BPMN_SUB_PROCESS_COLLAPSED)
* or a special subprocess symbol (see below)
triggeredByEvent: boolean = Attribute type Event subprocess

false (AT_BPMN_EVENT_SUB_PROCESS) in the
attribute type group BPMN 2.0
attributes/Subprocess attributes of
object type Function.
Symbols:
* Event subprocess
(ST_BPMN_EVENT_SUBPROCESS)
* Event subprocess (collapsed)
(ST_BPMN_EVENT_SUBPROCESS_COLLAP
SED)
The symbols are rendered by the program.
231
METHOD MANUAL
10.4.1.5.2 Subprocess type: Event subprocess

An event subprocess is a specialized subprocess that is used within a process or a
subprocess. Unlike a standard subprocess which uses the flow of its parent process as a
trigger, an event subprocess is not part of the normal flow of its parent process, there is no
incoming and outgoing sequence flow. An event subprocess has a start event with a trigger.
Each time the start event is triggered while the parent process is active, then the event
subprocess will start.
The symbols of an event subprocess are shown below. If the event subprocess is collapsed,
its start event is used as a marker in the upper left corner of the symbol. The software will
render this marker.
Figure 162: Symbols of an event subprocess
There is a Boolean ARIS attribute type Event subprocess representing the BPMN attribute
triggeredByEvent (see table under Subprocess type: Subprocess (page 230)). This attribute
type is read-only and used by the software.
232
METHOD MANUAL
10.4.1.5.3 Subprocess type: Transaction

A transaction subprocess, denoted with a double-lined boundary, is a specialized type of
subprocess. In a transaction subprocess all activities must either complete successfully or
the subprocess must be rolled back to its original consistent state. A transaction subprocess
has a special behavior: It is associated with a transaction protocol that has to verify that all
activities have been successfully completed. The symbols are not available in the Symbols
bar, they are handled by the software. The program also sets the value of the ARIS attribute
type Subprocess type to Transaction.
Figure 163: Symbol for a collapsed transaction
A transaction inherits from Activity. The attributes and model associations of a transaction
subprocess and their mapping to ARIS constructs are shown in the table below.

Transaction inherits from Activity The value of the attribute type Subprocess
type (AT_BPMN_SUBPROCESS_TYPE) is
set to Transaction in the attribute type
group BPMN 2.0 attributes/Subprocess
Symbols:
* Transaction (ST_BPMN_TRANSACTION)
* Transaction (collapsed)
(ST_BPMN_TRANSACTION_COLLAPSED_1)
The symbols are rendered by the software.
protocol: string [0..1] Currently not implemented.
method: TransactionMethod Currently not implemented.

= compensate
{ compensate | store | image }
233
METHOD MANUAL
10.4.1.5.4 Subprocess type: Ad hoc subprocess

A transaction subprocess, denoted with a double-lined boundary, is a specialized type of
subprocess. In a transaction subprocess all activities must either complete successfully or
the subprocess must An Ad hoc subprocess, denoted with a tilde marker, is a specialized type
of subprocess. It contains a set of activities that could be performed. Sequence flow between
activities is optional in an Ad hoc subprocess. What activities are performed as well as the
sequence and the number of performances is determined by the performers of the activities.
During execution of the (parent) process, any one or more of the activities may be active.
The ARIS Method provides the tilde marker as mini-symbol for the value Ad hoc subprocess
of the attribute Subprocess type. The program will render the symbols for the Ad hoc
subprocess.
Figure 164: Symbol for a collapsed and expanded Ad hoc subprocess
234
METHOD MANUAL

Ad hoc inherits from Activity The value of the attribute type Subprocess
subprocess type (AT_BPMN_SUB_PROCESS_TYPE) is
set to Ad hoc subprocess in the attribute
type group BPMN 2.0
attributes/Subprocess attributes of
object type Function.
Symbols: The mini-symbol tilde is rendered
by the program.
completionCondition: Attribute type Ad hoc completion

Expression condition
(AT_BPMN_COMPLETION_CONDI) in the
attributes/Subprocess attributes/Ad
hoc subprocess attributes of object type
Function.
ordering: AdHocOrdering = Currently not implemented.

parallel
{ parallel | sequential }
cancelRemainingInstances Currently not implemented.

: Boolean = True
235
METHOD MANUAL
10.4.1.6 Subprocess type: Call Activity

A call activity represents the invocation of either a reusable global task or a process. The call
activity represents the calling element, and the global task or process represents the called
element.
The symbol Call activity is available in the Symbols bar. If the modeler places this symbol,
the value of the attribute Activity type is set to Call activity and the software provides a
dialog where the modeler selects the task or the process being called. Depending on this
selection, the value of the attribute type Called element is set to Global task or Global
process. The program renders the symbol for the call activity. It corresponds to the symbol
for the called task or process, but it is drawn with a thick border.
If a task is selected the program automatically creates a connection (call activity invokes task)
on definition level. If a process is selected, the related process diagram is assigned to the call
activity.

CallActivity inherits from Activity The value of the attribute type Activity
type (AT_BPMN_ACTIVITY_TYPE) is set to
Call activity in the attribute type group
BPMN 2.0 attributes of object type
Function.
Symbol: The symbol depends on the activity
being called. The program will render the
symbol.
236
METHOD MANUAL

calledElement: For tasks:
CallableElement [0..1] The value of the attribute type Called
element (AT_BPMN_CALLED_ELEMENT) is
set to Global task.
The program creates the connection type
Function invokes [CT_INVOKES] function
on definition level.
For processes:
The value of the attribute type Called
element (AT_BPMN_CALLED_ELEMENT) is
set to Global process.
The BPMN process diagram of the called
process is assigned to the Call activity.
In both cases the software provides an
appropriate dialog.
237
METHOD MANUAL
10.4.1.7 Global task

The global task is described in chapter Callable Elements (page 202).
A global task has no specific attributes and model associations, it inherits from callable
elements.
10.4.1.8 Loop characteristics

BPMN 2.0 provides two alternatives to model repeating activities (both tasks and
subprocesses):
 Loop activity (= standard loop)
 Multi-instance activity
10.4.1.8.1 Loop characteristics representations

An activity can be specified to repeat based on a condition. That is called standard loop
activity in BPMN. A standard loop is equivalent to the do while and do until structure in
programming. The number of iterations is unknown.
A multi-instance activity is another type of repeating activity useful for performing actions on
a list of items. A multi-instance activity is equivalent with a for each structure in
programming. The number of iterations is known when the activity starts. It is the number of
items in the list. Iterations of a multi-instance activity can be performed concurrently or
sequentially.
The marker for a standard loop is a circular arrow at the bottom center of the activity symbol.
Figure 165: Symbols of Standard loop activities
The markers for multi-instance activities are three bars at the bottom center of the task or
subprocess symbol.
238
METHOD MANUAL
Vertical bars are used to represent concurrent/parallel performances:
Figure 166: Symbols of BPMN multi-instance (parallel) activities
Horizontal bars are used to represent sequential performances:
Figure 167: Symbols for activities of the BPMN multi-instance (parallel)
Loop characteristics has no specific attributes, it inherits the attributes and associations of
base element. The attribute type Loop type is used in ARIS to specify whether the loop is a
standard loop, a multi-instance parallel loop, or a multi-instance sequential loop. The attribute
values are visualized by mini-symbols.
239
METHOD MANUAL
10.4.1.8.2 Standard and multi-instance loop

characteristics and complex behavior definition
The attributes and model associations of standard activities, multi-instance loop activities,
and complex behavior definition are summarized in the table below.
Class BPMN attribute Implementation in ARIS

name
LoopCharacteristics inherits from Attribute type group Loop characteristics
BaseElement (AT_BPMN_LOOP_CHARACTERISTICS) in
object type Function (OT_FUNC).
StandardLoopCharac inherits from The value of the attribute type Loop type
teristics BaseElement (AT_BPMN_LOOP_TYPE_2) is set to
Standard loop
(AVT_BPMN_STANDARD_LOOP) in the
attributes/Loop characteristics of object
type Function.
testBefore: Attribute type Test before

boolean = False (AT_BPMN_LOOP_TEST_TIME) in the
attributes/Loop characteristics/Standard
loop attributes of object type Function.
loopMaximum: Attribute type Loop maximum

Expression [0..1] (AT_BPMN_MAX_LOOP) in the attribute type
group BPMN 2.0 attributes/Loop
characteristics/Standard loop attributes
of object type Function.
loopCondition: Attribute type Loop condition

Expression [0..1] (AT_BPMN_LOOP_CONDITION ) in the
attributes/Loop characteristics/Standard
loop attributes of object type Function.
240
METHOD MANUAL

name
MultiInstanceLoop inherits from The value of the attribute type Loop type
Characteristics BaseElement (AT_BPMN_LOOP_TYPE_2) is set to
Multi-instance sequential loop
(AVT_BPMN_MULTI_INSTANCE_SEQUENTIA
L_LOOP) or Multi-instance parallel loop
(AVT_BPMN_MULTI_INSTANCE_PARALLEL_
LOOP) in the attribute type group BPMN 2.0
attributes/Loop characteristics of object
type Function.
isSequential: isSequential = true corresponds to: Loop type

boolean = False = Multi-instance sequential loop
isSequential = false corresponds to: Loop type
= Multi-instance parallel loop
loopCardinality: Attribute type Loop cardinality

Expression [0..1] (AT_BPMN_LOOP_CARDINALITY) in the
attributes/Loop
characteristics/Multi-instance loop
loopDataInput: Currently not implemented.

DataInput [0..1]
loopDataOutput: Currently not implemented.

DataOutput [0..1]
inputDataItem: Currently not implemented.

Property [0..1]
outputDataItem: Currently not implemented.

Property [0..1]
completionCondi Currently not implemented.

tion: Expression
[0..1]
241
METHOD MANUAL

name
behavior: Currently not implemented.
MultiInstanceBeha
vior = all
{ none | one | all |
complex }
complexBehavior Currently not implemented.

Definition:
ComplexBehavior
Definition [0..*]
oneBehaviorEven Currently not implemented.

tRef:
EventDefinition
[0..1]
noneBehaviorEve Currently not implemented.

ntRef:
EventDefinition
[0..1]
ComplexBehaviorDefi inherits from Currently not implemented.

nition BaseElement
condition: Formal
Expression
event:
ImplicitThrowEven
t
242
METHOD MANUAL
10.4.2 Items and Data

As mentioned above, the current implementation of BPMN 2.0 in ARIS focuses on the
business process level. Therefore, only data objects and data stores are provided - as input or
output of activities. Detailed data modeling aspects (for example data structures, data states,
data associations) are omitted.
10.4.2.1 Data object

In BPMN 1.x data were considered as an artifact; in BPMN 2.0, data objects were upgraded to
objects in the BPMN semantic model.
On the business level, where the data structures and mappings are not included, data objects
are represented in ARIS by six symbols of the object type Cluster/Data model:
 Data object
 Data collection
 Data input
 Data input collection
 Data output
 Data output collection
When you place a Data object the object symbols Data object, Data input, and Data output
are provided. You can select the object symbols Data collection, Data input collection, and
Data output collection using the Object appearance page of the Object properties dialog.
Figure 168: Symbols of data objects
243
METHOD MANUAL
Only the Data object symbol is available in the Symbols bar.

Data objects can represent the input or output of activities by using the following connection
types:
 Cluster/Data model is input for function
 Function has as output Cluster/Data model
The data input symbols must not be the target of a has as output connection, and the data
output symbols must not be the source of an is input for connection. The software ensures
this.

ItemAware inherits from BaseElement
Element
itemSubjectRef: Currently not implemented.

ItemDefinition [0..1]
dataState: DataState [0..1] Currently not implemented.
244
METHOD MANUAL

Data object inherits from FlowElement & Object type: Cluster/Data model (OT_CLST)
ItemAwareElement
Six symbols:
* Data object (ST_BPMN_DATA_OBJECT)
* Data collection
(ST_BPMN_DATA_COLLECTION)
* Data input (ST_BPMN_DATA_INPUT)
* Data input collection

(ST_BPMN_DATA_INPUT_COLLECTION)
* Data output (ST_BPMN_DATA_OUTPUT)
* Data output collection

(ST_BPMN_DATA_OUTPUT_COLLECTION)
isCollection: Boolean = False Represented by special symbols of the

object type Cluster/Data model
(OT_CLST)
245
METHOD MANUAL
10.4.2.2 Data store

Unlike data objects, which live only as long as the process instance is running, a Data store
represents information that persists beyond the lifetime of a particular process. On the
business level, a Data store is represented by the symbol Data store of the ARIS object type
Information carrier. This symbol is available in the Symbols bar.
On the business level, where the data structures and mappings are not included, data objects
are represented in ARIS by six symbols of the object type Cluster/Data model:
 Information carrier provides input for function
 Function creates output to information carrier.
Figure 169: Symbol for a data store
A Data store inherits from FlowElement and ItemAwareElement.

DataStore inherits from FlowElement Object type: Information carrier
and ItemAwareElement (OT_INFO_CARR)
Symbol: Data store
(ST_BPMN_DATA_STORE)
name: string Attribute type Name (AT_NAME) of object

type Information carrier (OT_INFO_CARR)
capacity: Integer [0..1] Currently not implemented.
isUnlimited: Boolean = False Currently not implemented.
DataStoreR inherits from FlowElement

eference and ItemAwareElement
dataStoreRef: DataStore Occurrence copies of the (referenced) data

store.
246
METHOD MANUAL
10.4.3 Events
BPMN events are represented in ARIS by the object type Event. Altogether there are
sixty-three symbols available in BPMN 2.0. The main event types are:
 Start event
 Intermediate event
 End event
Only these three events are provided in the Symbols bar in ARIS (see type = None). The
remaining symbols are provided as symbols in the ARIS Method.
BPMN events: (See: Business Process Modeling Notation (BPMN), version 2.0, page 233 and
the following).
Types Start Intermediate End

Top Event Event Catchin Boundar Boundary Throwin
level Sub- Sub- g y Inter- Non-Inter- g
process process rupting rupting
Inter- Non-Inter-
rupting rupting
None
Message
Timer
Error
Escalation
Cancel
Compensation
Conditional
247
METHOD MANUAL
Types Start Intermediate End

Link
Signal
Terminate
Multiple
Parallel
multiple
248
METHOD MANUAL
10.4.3.1 Catch events and throw events

Events can be:
 catch events (all start and a number of intermediate events)
 throw events (all end events a number of intermediate)

Event Object type: Event (OT_EVT)
Symbols: sixty-three different symbols (see
below)
Catch Event inherits from Object type: Event (OT_EVT)

FlowElement Symbols: different start or intermediate event
symbols
eventDefinitionRefs: Occurrence copy of the corresponding throw

EventDefinition [0..*] event.
eventDefinitions: Attribute type Event definition

EventDefinition [0..*] (AT_BPMN_EVENT_DEFINITION) in the
object type Event (OT_EVT).
The values of this attribute type are: None,
Message, Timer, Error, Escalation, Cancel,
Compensation, Conditional, Link, Signal,
Multiple, Parallel multiple (as special case of
Multiple).
Each event definition has a specific marker
inside the event symbol.
dataOutputAssociation Currently not implemented.

s: DataOutputAssociation
[0..*]
dataOutput: dataOutput Connection type in the BPMN process

[0..*] diagram (BPMN 2.0) and the BPMN
collaboration diagram (BPMN 2.0):
Event (symbol: only catch events) has as
output Cluster/data model
249
METHOD MANUAL

outputSet: OutputSet Currently not implemented.
[0..1]
Throw event inherits from Object type: Event (OT_EVT)

FlowElement Symbols: different intermediate or end event
symbols
eventDefinitionRefs: Occurrence copy of the corresponding catch

EventDefinition [0..*] event.
eventDefinitions: Attribute type Event definition

EventDefinition [0..*] (AT_BPMN_EVENT_DEFINITION) in the
object type Event (OT_EVT).
The values of this attribute type are: None,
Message, Error, Escalation, Cancel,
Compensation, Link, Signal, Terminate,
Multiple.
Each event definition has a specific marker
inside the event symbol.
dataInputAssociations: Currently not implemented.

DataInputAssociation
[0..*]
dataInput: DataInput Connection type in the BPMN process

[0..*] diagram (BPMN 2.0) and the BPMN
Cluster/data model is input for event (symbol:
only throw events)
inputSet: InputSet [0..1] Currently not implemented.
Implicit Throw inherits from ThrowEvent Currently not implemented.

Event
250
METHOD MANUAL
10.4.3.2 Start event

The symbols of start events are depicted in chapter events (page 247). Only the start event
None is available in the Symbols bar. When placing this start event, the modeler is guided by
a special functionality of the program.

Start event inherits from CatchEvent Object type: Event (OT_EVT)
Symbol: Start event (ST_BPMN_START_EVENT)
isInterrupting: boolean Interrupting start events are represented by

specific event symbols.
251
METHOD MANUAL
10.4.3.3 Intermediate events

The symbols of intermediate events are depicted in chapter events (page 247). Only the
intermediate event None is available in the Symbols bar. When placing this start event, the
modeler is guided by a special functionality of the program. Intermediate events have no
specific attributes and associations.

name
IntermediateEvent Object type: Event (OT_EVT)
Symbol: Intermediate event
(ST_BPMN_INTERMEDIATE_EVENT)
Some types of intermediate events can be attached to the boundary of activities, they are
called boundary events (see column Boundary Interrupting and Boundary
Non-interrupting in chapter events (page 247).
Boundary events are always catch events. Their attributes and model associations are shown
in the table below.

name
Boundary events inherits from Boundary events are specific intermediate
CatchEvent events.
AttachedTo: Activity Connection type in the BPMN process

diagram (BPMN 2.0) and the BPMN
Function can trigger
(CT_BPMN_CAN_TRIGGER) event (symbol:
intermediate event)
CancelActivity: (Non-)Interrupting events are represented by

boolean specific event symbols.
252
METHOD MANUAL
10.4.3.4 End event

The symbols of end events are depicted in chapter events (page 247). Only the none end
event is available in the Symbols bar. When placing this start event, the modeler is guided by
a special functionality of the program.

EndEvent Object type: Event (OT_EVT)
Symbol: End event (ST_BPMN_END_EVENT)
10.4.3.5 Event definitions

BPMN 2.0 distinguishes the following event definitions: None, Message, Timer, error,
Escalation, Cancel, Compensation, Conditional, Link, Signal, Terminate and Multiple (Parallel
multiple is a special case Multiple). The different definitions are visualized by specific
markers placed within the None start, Intermediate and End event symbol.

EventDefinition inherits from BaseElement Attribute type Event definition
(AT_BPMN_EVENT_DEFINITION) in
the attribute type group BPMN 2.0
attributes of object type Event
(OT_EVT)
Attribute values: None, Message,
Timer, Error, Escalation, Cancel,
Compensation, Conditional, Link,
Signal, Terminate, Multiple.
This attribute is read-only and set
automatically by the software.
253
METHOD MANUAL

CancelEventDefinitio inherits from BaseElement Object type: Event (OT_EVT)
n Symbols:
* Cancel intermediate event
(ST_BPMN_CANCEL_INTERMEDIATE
_EVENT)
* Cancel end event
(ST_BPMN_CANCEL_END_EVENT)
CompensationEvent inherits from BaseElement Object type: Event (OT_EVT)

Definition Symbols:
* Compensation start event
(ST_BPMN_COMPENSATION_START
* Compensation intermediate event
(catch)(ST_BPMN_COMPENSATION_I
NTERMEDIATE_CATCH
* Compensation intermediate event
(throw)
(ST_BPMN_COMPENSATION_INTERM
EDIATE_THROW)
* Compensation end event
(ST_BPMN_COMPENSATION_END_E
VENT)
activityRef: Activity [0..1] Attribute type Wait for completion

(AT_BPMN_WAIT_FOR_COMPLETION
) in the attribute type group BPMN
2.0 attributes/Compensation
event attributes of object type
Event (OT_EVT).
254
METHOD MANUAL

ConditionalEvent inherits from BaseElement Object type: Event (OT_EVT)
Definition Symbols:
* Conditional start event
(ST_BPMN_RULE_START_EVENT)
* Conditional start event
(non-interrupting)
(ST_BPMN_CONDITIONAL_START_N
I)
* Conditional intermediate event
(ST_BPMN_RULE_INTERMEDIATE_E
VENT)
* Conditional intermediate event
(non-interrupting)
(ST_BPMN_CONDITIONAL_INTERME
DIATE_NI)
condition: Expression Attribute type Condition

(AT_BPMN_RULE_EXPRESSION) in
the attribute type group BPMN 2.0
attributes/Conditional event
attributes of object type Event
(OT_EVT).
ErrorEventDefinition inherits from BaseElement Object type: Event (OT_EVT)

Symbols:
* Error start event
(ST_BPMN_ERROR_START)
* Error intermediate event
(ST_BPMN_ERROR_INTERMEDIATE_
EVENT
* Error end event
(ST_BPMN_ERROR_END_EVENT)
errorCode: string Currently not implemented.
error: Error [0..1] Currently not implemented.
255
METHOD MANUAL

EscalationEvent inherits from BaseElement Object type: Event (OT_EVT)
Definition Symbols:
* Escalation start event
(ST_BPMN_ESCALATION_START)
* Escalation start event
(non-interrupting)
(ST_BPMN_ESCALATION_START_NI)
* Escalation intermediate event
(catch)
(ST_BPMN_ESCALATION_INTERMEDI
ATE_CATCH)
* Escalation intermediate event
(non-interrupting)
ATE_NI)
* Escalation intermediate
event_throw
ATE_THROW)
* Escalation end event
(ST_BPMN_ESCALATION_END)
escalationCode: string Currently not implemented.
escalationRef: Escalation Currently not implemented.

[0..1]
LinkEventDefinition inherits from BaseElement Object type: Event (OT_EVT)

Symbols:
* Link intermediate event (catch)
(ST_BPMN_LINK_INTERMEDIATE_CA
TCH)
* Link intermediate event (throw)
(ST_BPMN_LINK_INTERMEDIATE_TH
ROW)
Catch and throw link events are
referred to each other by occurrence
copies.
256
METHOD MANUAL

name: string Attribute type Name (AT_NAME) of
object type Event (OT_EVT)
MessageEvent inherits from BaseElement Object type: Event (OT_EVT)

Definition Symbols:
* Message start event
(ST_BPMN_MESSAGE_START_EVEN
T)
* Message start event
(non-interrupting)
(ST_BPMN_MESSAGE_START_NI)
* Message intermediate event (catch)
(ST_BPMN_MESSAGE_INTERMEDIAT
E_CATCH)
* Message intermediate event
(non-interrupting)
E_NI)
* Message intermediate event (throw)
E_THROW)
* Message end event
(ST_BPMN_MESSAGE_END_EVENT)
MessageRef: Message Currently not implemented.

[0..1]
operationRef: Operation Currently not implemented.

[0..1]
257
METHOD MANUAL

Multiple event Object type: Event (OT_EVT)
Symbols:
* Multiple start event
(ST_BPMN_MULTIPLE_START_EVEN
T)
* Multiple start event
(non-interrupting)
(ST_BPMN_MULTIPLE_START_NI)
* Multiple intermediate event (catch)
(ST_BPMN_MULTIPLE_INTERMEDIAT
E_CATCH)
* Multiple intermediate event
(non-interrupting)(ST_BPMN_MULTI
PLE_INTERMEDIATE_NI)
* Multiple intermediate event (throw)
(ST_BPMN_MULTIPLE_INTERMEDIAT
E_THROW)
* Multiple end event
(ST_BPMN_MULTIPLE_END_EVENT)
None event Object type: Event (OT_EVT)

Symbols:
* Start event (ST_BPMN_SE)
* Intermediate event (ST_BPMN_IE)
* End event (ST_BPMN_EE)
These symbols are available in the
Symbols bar.
258
METHOD MANUAL

Parallel multiple Object type: Event (OT_EVT)
event Symbols:
* Parallel multiple start event
(ST_BPMN_PARALLEL_MULTIPLE_S
TART)
* Parallel multiple start event
(non-interrupting)
(ST_BPMN_PARALLEL_MULTIPLE_S
TART_NI)
* Parallel multiple intermediate event
(ST_BPMN_PARALLEL_MULTIPLE_I
NTERMEDIATE)
* Parallel multiple intermediate event
(non-interrupting)
(ST_BPMN_PARALLEL_MULTIPLE_I
NTERMEDIATE_NI)
SignalEventDefinitio inherits from BaseElement Object type: Event (OT_EVT)

n Symbols:
* Signal start event
(ST_BPMN_SIGNAL_START_EVENT)
* Signal start event (non-interrupting)
(ST_BPMN_SIGNAL_START_NI)
* Signal intermediate event (catch)
(ST_BPMN_SIGNAL_INTERMEDIATE
_EVENT)
* Signal intermediate event
(non-interrupting)
_NI)
* Signal intermediate event (throw)
_THROW)
* Signal end event
(ST_BPMN_SIGNAL_END_EVENT)
signalRef: Signal Currently not implemented.
259
METHOD MANUAL

TerminateEvent inherits from BaseElement Object type: Event (OT_EVT)
Definition Symbol:
* Terminate end event
(ST_BPMN_TERMINATE_END_EVEN
T)
TimerEventDefini inherits from BaseElement Object type: Event (OT_EVT)

tion Symbols:
* Timer start event
(ST_BPMN_TIMER_START_EVENT)
* Timer start event (non-interrupting)
(ST_BPMN_TIMER_START_NI)
* Timer intermediate event
(ST_BPMN_TIMER_INTERMEDIATE_
EVENT)
* Timer intermediate event
(non-interrupting)
(ST_BPMN_TIMER_INTERMEDIATE_
NI)
timeDate: Expression Attribute type Time date

[0..1] (AT_BPMN_TIMEDATE) in the
attributes/Timer event attributes
of object type Event (OT_EVT).
timeCycle: Expression Attribute type Time cycle

[0..1] (AT_BPMN_TIMECYCLE) in the
attributes/Timer event attributes
of object type Event (OT_EVT)
260
METHOD MANUAL
10.4.4 Gateways
The ARIS object type Rule depicts BPMN gateways. Although BPMN 2.0 knows five different
gateway types, only one symbol is available in the Symbols bar:
The remaining gateway symbols are handled by the program. The following figure depicts all
(basic) gateway symbols.
Figure 170: BPMN gateway types
For event-based gateways there are two additional symbols which are used to start a
process:
All in all the ARIS Method will provide eight gateway symbols. Contrary to events, an ARIS
attribute recording the gateway type is not required. It is up to the modeler to ensure that
gateways are used in a semantically correct way. The modeler should not reuse gateways.
261
METHOD MANUAL
10.4.5 Exclusive gateway

name
Exclusive gateway inherits from Object type: Rule (OT_RULE)
Gateway Symbols:
* Gateway (ST_BPMN_RULE_1)
* Exclusive gateway
(ST_BPMN_RULE_XOR_3)
* Event-based gateway
default: Attribute type Sequence flow condition

SequenceFlow [0..1] (AT_BPMN_SEQ_FLOW_CONDITION) in the
the following connection types:
* Rule leads to (CT_LEADS_TO_2) event
* Rule activates (CT_ACTIV_1) function
* Rule links (CT_LNK_2) rule
The attribute value must be set to Default
sequence flow.
The symbol (slash) is automatically set by the
software.
10.4.5.1 Inclusive gateway

name
Inclusive gateway inherits from Object type: Rule (OT_RULE)
Gateway Symbol:
* Inclusive gateway (ST_BPMN_RULE_OR_1)
default: See: exclusive gateway

SequenceFlow [0..1]
262
METHOD MANUAL
10.4.5.2 Parallel gateway

Parallel gateways have no specific attributes.
Parallel gateway inherits from Gateway Object type: Rule (OT_RULE)

Symbol:
* Parallel gateway (ST_BPMN_RULE_AND_1)
10.4.5.3 Complex gateway

name
Complex gateway inherits from Object type: Rule (OT_RULE)
Gateway Symbol:
* Complex gateway
(ST_BPMN_RULE_COMPLEX_1)
activationConditio Attribute type Activation condition

n: Expression [0..1] (AT_ACTIVATION_CONDITION) in the
attributes/Complex gateway attributes of
object type Rule (OT_RULE)
263
METHOD MANUAL
10.4.5.4 Event-based gateways

All attributes are represented by specific gateway symbols.
Event-based inherits from Gateway Object type: Rule (OT_RULE)

gateway Symbols:
* Instantiating event-based gateway
(ST_BPMN_RULE_XOR_START)
* Instantiating parallel event-based gateway
(ST_BPMN_RULE_XOR_PARALLEL)
instantiate: boolean = Represented by symbols.

False True if:
False if:
eventGatewayType: Represented by symbols:

EventGatewayType = Exclusive if:
Exclusive * Event-based gateway
{ Exclusive | Parallel } (ST_BPMN_RULE_XOR_4)
Parallel if:
264
METHOD MANUAL
10.4.6 Lanes
A lane is a subdivision of a process or a pool. Lanes have no semantics in BPMN. BPMN 2.0
uses lanes as a way to categorizes Flow Elements. Most often lanes represent organizational
elements, but in principle any categorization may be used for lanes. Lanes may contain
nested sub-lanes. A lane set specifies the categorization represented by the lanes.
Like a pool a lane is drawn as a rectangular box, its label is not boxed off.
Figure 171: Nested Lanes
LaneSet inherits from Object type: Lane (OT_BPMN_LANE)

BaseElement Symbol: Lane (ST_BPMN_LANE_1)
process: Process The BPMN process model that contains the lane(s).
lanes: Lane [0..*] Object type: Lane (OT_BPMN_LANE)

Symbol: Lane (ST_BPMN_LANE_1)
The source objects in the connection type: Lane
belongs to (CT_BELONGS_TO_1) lane
parentLane: Lane [0..1] The target object in the connection type: Lane
belongs to (CT_BELONGS_TO_1) lane CT: Lane
belongs to lane
Lane inherits from Object type: Lane (OT_BPMN_LANE)

BaseElement Symbol: Lane (ST_BPMN_LANE_1)
265
METHOD MANUAL
name: string Attribute type Name (AT_NAME) of object type Lane

(OT_BPMN_LANE)
partitionElement: Currently not implemented.

BaseElement [0..1]
partitionElementRef: Currently not implemented.

BaseElement [0..1]
childLaneSet: LaneSet The source objects in the connection type: Lane

[0..1] belongs to (CT_BELONGS_TO_1) lane
flowElementRefs: The source objects in the following belongs to

FlowElement [0..*] (CT_BELONGS_TO_1) connection types:
* Function belongs to lane
* Event belongs to lane
* Rule belongs to lane
* Cluster/data model belongs to lane
* Information carrier belongs to lane
266
METHOD MANUAL
10.5 Collaboration
A collaboration shows message exchanges between participants. A collaboration contains at
least two pools representing the participants. A pool may include a process (white box) or
may be shown as a black box with all details hidden. The message exchanges between the
participants are represented by message flows that connect two pools (or the objects within
the pools). Only one pool may be represented without a boundary.
The model type BPMN collaboration diagram (BPMN 2.0) has been introduced to model
collaborations.

Collaboration inherits from Model type: BPMN collaboration diagram (BPMN
BaseElement and 2.0) (MT_BPMN_COLLABORATION_DIAGRAM)
InteractionSpecification
name: string Attribute type Name of the BPMN collaboration

diagram (BPMN 2.0)
choreographyRef: Currently not implemented.

Choreography [0..1]
conversationAssociatio The relationships to conversations are

ns: represented by occurrence copies of
ConversationAssociation participants (OT_BPMN_POOL;
[0..*] ST_BPMN_POOL_1), occurrence copies of
message flow connections and the assignment
of a BPMN collaboration model (BPMN 2.0) to
the object type Conversation
(OT_BPMN_CONVERSATION).
conversations: BPMN collaboration diagram (BPMN 2.0)

Conversation [0..*] assigned to the object type Conversation
(OT_BPMN_CONVERSATION)
artifacts: Artifact [0..*] Artifacts (page 196)
267
METHOD MANUAL

participantAssociations The relationships to participants are
: ParticipantAssociations represented by occurrence copies of
[0..*] participants (OT_BPMN_POOL;
ST_BPMN_POOL_1)
messageFlowAssociatio The relationships to message flows are

ns: Message flow represented by occurrence copies of message
association [0..*] flow connections (and the involved
participants).
IsClosed: boolean = false Attribute type Is closed in the attribute type

group BPMN 2.0 attributes of model type the
BPMN Collaboration diagram (BPMN 2.0).
The object types and connection types of the BPMN collaboration diagram are detailed in the
following chapters.
10.5.1 Pool and participant

Pools and participants play a central role in collaborations. They are described in detail in
chapter Participant (page 209).
268
METHOD MANUAL
10.5.2 Object types and connection types reused from a

process
As a pool may show a process (white box) all object types and connection types that are
allowed in the BPMN process diagram (BPMN 2.0) are also available in the BPMN collaboration
diagram (BPMN 2.0).
The object types and connection types taken over from the BPMN process diagram (BPMN
2.0) are described in detail in chapter Process (page 219).
The connection type belongs to is used to embed the object types of a visible process into a
pool.
Source object type Connection type Target object type
Event (OT_EVT) belongs to Participant

(CT_BELONGS_TO_1) (OT_BPMN_POOL)
Function (OT_FUNC) belongs to Participant

Rule (OT_RULE) belongs to Participant

Lane belongs to Participant

(OT_BPMN_LANE) (CT_BELONGS_TO_1) (OT_BPMN_POOL)
Cluster/data model belongs to Participant

(OT_CLST) (CT_BELONGS_TO_1) (OT_BPMN_POOL)
Information carrier belongs to Participant

(OT_INFO_CARR) (CT_BELONGS_TO_1) (OT_BPMN_POOL)
269
METHOD MANUAL
10.5.3 Message flow

The message flow between different participants is represented by an ARIS connection type
of the same name. It connects two pools or the objects within a pool. The attributes and
model associations of message flow are described in chapter Message flow (page 207).
To show the messages being exchanged in message flows the ARIS object type message
represented by a message symbol is used. The message flow connection type is replaced by
two connection types: sends and is received from. This work around is required due to the
fact that it is not possible in ARIS to assign object types to connection types.
The program will display the sends and is received from connection types like a normal
message flow.
10.6 Conversation
See: Business Process Modeling Notation (BPMN), version 2.0, page 124 and the following.
The BPMN conversation diagram has been introduced with BPMN 2.0 to provide a big picture
of the interactions (in terms of related message exchanges) between collaborating
participants.
The BPMN conversation diagram is similar to the BPMN collaboration diagram, but its pools
are not allowed to contain a process and a choreography is not allowed between the pools.
The BPMN conversation diagram differentiates three basic elements.

 Conversation nodes (Communication, Sub-conversation)
 Participants (Pools)
 Conversation links (message flow, participates in)
They are described in the next chapters.
270
METHOD MANUAL
10.6.1 Conversation container

The attributes and model associations of a conversation and conversation container are
summarized in the table below.

Conversation inherits from
CallableElement,
InteractionSpecification,
ConversationContainer
correlationKeys: Currently not implemented.

CorrelationKey [0..*]
messageFlowRefs: Occurrence copies of message flows (and the

MessageFlow [0..*] involved participants)
Conversation inherits from BaseElement Model type: BPMN conversation diagram (BPMN
container 2.0)
MT_BPMN_CONVERSATION_DIAGRAM
conversationNodes: see below

ConversationNode [0..*]
artifacts: Artifact [0..*] see chapter Artifacts (page 196)
271
METHOD MANUAL
10.6.2 Conversation nodes

BPMN 2.0 distinguishes three sub-types of conversation nodes.
 Communication
 Sub-conversation
 Call conversation
(The concept of call conversation is not clear, thus, Call conversations are ignored in the
current implementation of BPMN 2.0 in ARIS. However, in ARIS Call conversations can be
particularly distinguished. See description below.)
Conversation nodes are represented in ARIS by the object type Conversation.
A communication is an atomic conversation element in a BPMN conversation diagram, it
represents a set of message flow grouped together based on a single correlation key. A
communication will involve at least two participants.
The symbol for a communication is available in the Symbols bar of the BPMN conversation
diagram (BPMN 2.0).
Figure 172: Symbols of Conversation nodes
A Sub conversation is a conversation which consists of lower-level conversations which are

modeled in a separate BPMN conversation diagram assigned to the sub-conversation. A
sub-conversation shares the participants of its parent conversation.
The ARIS method provides a Sub conversation symbol, it also shown in the Symbols bar.
A Call conversation identifies a place in a conversation where a global conversation or a
global communication is used. A global communication is a reusable atomic communication
definition that can be called from within any conversation by a Call conversation.
The concepts of Call conversations and global communication are very vague. Thus, the ARIS
method does not provide specific symbols. But there is the Boolean ARIS attribute type Call
272
METHOD MANUAL
conversation which allows the modeler to flag Call conversations. If the value is true, the
Call conversation symbol is rendered by the software automatically.
10.6.3 Participant
Participants are represented by the ARIS object type Participant. The Pool symbol is
available in the Symbols bar. If the ARIS attribute type Multi-instance participant is set to
true the program will render the symbol: three vertical lines are displayed at the bottom of
the pool symbol.
Participants/pools are described in detail in chapter Participant (page 209).
10.6.4 Artifacts
According to the metamodel artifacts are allowed in a conversation diagram. However, the
relevance of groupings in a conversation diagram is not evident. For that reason only text
annotations are implemented in the current version of the BPMN conversation diagram.
The symbol Text annotation is available in the Symbols bar. Artifacts and their usage are
described in detail in chapter Artifacts (page 196).
10.6.5 Conversation link

A conversation link is used to link participants with conversation nodes. A conversation node
has at least two participants.
There is an inconsistency in the specification: Sometimes the name Communication links is
used, sometimes the name Conversation link.
N-ary (n > 2) conversations are allowed.
273
METHOD MANUAL
In ARIS the connection type participates in (Participant participates in Conversation) has

been introduced. The passive name of the connection type is has conversation link to
(Conversation has conversation link to Participant). Specific attributes are not required.
Figure 173: Conversation link with Participant multiplicity
The fork shown at the source of a conversation link must be manually set by the modeler
using the property dialog of the relevant connection type.
10.6.6 Message flow in a conversation

According to the specification, it is allowed in the BPMN conversation diagram to model
message exchanges between participants using message flows. (See: Business Process
Model and Notation (BPMN), version 2.0.)
Figure 174: Message flow between Participants in a BPMN conversation diagram (BPMN 2.0)
Thus, the ARIS connection type message flow (Participant message flow Participant) is
available in the BPMN conversation diagram (BPMN 2.0).
274
METHOD MANUAL
10.6.7 Model assignments

The object type Conversation has the following assignments:
 BPMN conversation diagram
 BPMN collaboration diagram.
Only one model of each type can be assigned to a conversation object.
10.7 Enterprise BPMN collaboration diagram

The model type Enterprise BPMN Collaboration Diagram is based on the BPMN
Collaboration Diagram (BPMN 2.0).
It extents the BPMN Collaboration Diagram (BPMN 2.0) model type by ARIS constructs that
are already available in the EPC, but that are out of scope in the BPMN specification. Thus, for
example, the following object types can be (re-)used as lanes:
 Application system type
 Role
 Organizational unit
 Position
 Group
The supports connection is used to nest tasks in a lane object of the object type
Applications system type. The carries out connection is used to nest tasks in the lane
objects of the Organizational object types.
For all other nestings known from the BPMN specification the belongs to connection is used.
Similar to the EPC, an assignment relationship of the connection type is process-oriented
superior is available between a function assigned to an Enterprise BPMN collaboration
diagram and the tasks occurring in the assigned model.
275
METHOD MANUAL
11 Customer Experience Management (CXM)

As a result of digitization, consumers are spending ever-increasing amounts of time online,
and customer processes are also increasingly incorporating digital interactions. Due to these
developments, Customer Experience Management (CXM) is developing into one of the most
important drivers of innovation and customer loyalty.
CXM has the objectives of positively influencing the consumer behavior of a company's
customers and of providing all customers with the information they need at any time using
the right channel.
ARIS enables the implementation of CXM projects using two different approaches. Firstly, a
CXM project can be implemented using the top-down approach, whereby the CXM project
starts with the definition of the customer journey landscape and the subsequent creation of
the customer journey maps. Secondly, internal processes can be enhanced with customer
touchpoints and these can then be specified in more detail in customer touchpoint allocation
diagrams in an alternative, bottom-up approach to CXM project implementation.
276
METHOD MANUAL
11.1 Customer journey landscape

The Customer journey landscape model enables the description of the customer lifecycle
including the individual customer lifecycle stages and customer journeys. The model can be
used either to model the customer lifecycle stages only and assign customer journeys to
these, or to depict both the customer lifecycle stages and the corresponding customer
journeys in one model.
Figure 175: Customer journey landscape
If using the top-down approach, you would start with the customer journey landscape, which
provides a clear overview of all customer lifecycle stages and their associated customer
journeys.
Furthermore, the Customer journey object type enables the customer journey owner, the
business driver and business driver impact on transformation, as well as the overall customer
experience to be represented using attributes.
If the corresponding CXM templates are activated, a traffic-light display can be used to
visualize the relevant initiatives depending on the attribute values defined, so that the person
in charge can immediately see which initiatives are required for which customer journeys.
277
METHOD MANUAL
11.2 Customer journey map

The Customer journey map model is a column diagram, which symbolizes one of the
customer journeys from the Customer journey landscape model. The customer journey map
provides the Customer journey step and Customer touchpoint objects to enable the
illustration of the "journey" that the customer takes with the organization and that
characterizes the customer's interactions with the company. The model can thus incorporate
a detailed description of customer touchpoints, including the relevant KPIs, organizational
responsibilities, initiatives, and risks.
Figure 176: Customer journey map
278
METHOD MANUAL
However, the main object in this model type is the Customer touchpoint, which can be
described using many different attributes, including:
 customer objectives
 customer expectations and
 customer feeling
It is also possible to specify whether the customer touchpoint is a moment of truth, a pain
point, or a best practice. Given that this information is very important, it is displayed in the
model using special symbols.
Figure 177: CXM symbols
Moment of truth (MoT) indicates that the touchpoint is a crucial and decisive touchpoint for
the company and the process. An MoT can dictate whether the relationship between the
customer and the company is either reinforced or broken. Identifying moments of truth
should therefore be assigned a high priority because such touchpoints have a direct effect on
business.
To make the modeling of the customer journey map as simple as possible, ARIS enables the
placing of objects using drag and drop. In addition, it is not necessary to draw connections
between objects because this model type automatically creates the required object
relationships, with the exception of objects of the Customer journey step type. All objects in
a column belong to the Customer touchpoint object, which, in turn, is related to the
Customer journey step object.
If a customer journey step has more than one customer touchpoint because there are
multiple channels, the individual touchpoints can be described in more detail by assigning a
customer touchpoint allocation diagram. If you do not assign an allocation diagram to a given
touchpoint, all objects below that customer touchpoint will be used for all touchpoints in the
relevant step. In this way, it is only a general touchpoint specification.
279
METHOD MANUAL
11.3 Customer touchpoint allocation diagram

The Customer touchpoint allocation diagram model type is used to describe a customer
touchpoint in more detail including the relevant KPIs, organizational units, initiatives, risks,
etc.
Figure 178: Customer touchpoint allocation diagram
Besides the option of assigning it to a customer touchpoint object in a customer journey map,
this model type is particularly useful if companies already use ARIS and want to map
customer touchpoints in their internal processes without mapping them additionally in
customer journey map models. This model type offers the same object types as the
Customer journey map model type for describing the customer touchpoint in more detail.
280
METHOD MANUAL
11.4 Customer touchpoint map

The Customer touchpoint map model lists all customer touchpoints and can be used, for
example, as the starting point in a customer experience project, in order to identify the
interaction points with the customer. The customer touchpoints are grouped on the basis of a
certain criterion that may be important for the analysis, for example, by organizational unit,
channel, or risk.
Figure 179: Customer touchpoint map
281
METHOD MANUAL
The customer touchpoint map can also be used to gain an overview of all touchpoints in an
existing customer experience project and to manage these. Thus, it is possible to identify, at a
glance, which customer touchpoint is a moment of truth, a pain point, and/or a best practice.
11.5 Linking CXM and BPM

ARIS enables the mapping of both the internal and external processes and perspectives and
the creation of links between these using the Customer touchpoint object. If, for example, a
company has defined a customer touchpoint in a customer journey map, the company can
then create an occurrence of the touchpoint in an internal process and reuse it, for example,
in an EPC that is important for the customer journey. With this option, the two models are
linked with each other and you can, for example, run an analysis to very quickly obtain an
overview of which internal processes are influenced by changes to the touchpoint.
Figure 180: Linking CXM and BPM
282
METHOD MANUAL
11.5.1 Analysis capabilities

Besides the option of visualizing CXM data in the corresponding model types, it is possible to
analyze these data in ARIS using reports or queries.
11.5.1.1 Report
The Analyze customer experience report uses an infographic to visualize how customers
experience their interaction with the company during a customer journey and is intended to
help identify customer satisfaction as well as customer issues.
The following information is evaluated and displayed:
 Customer journey steps with customer touchpoints
 Moment of truth and pain points with description
 Best practice
 Importance to customer & customer feeling (satisfaction)
 Percentage proportion of pain points in the customer journey map
 Number of internal processes impacted
 Percentage proportion of satisfied customers
Figure 181: CXM infographic
283
METHOD MANUAL
11.5.1.2 Queries
Queries enable you to visualize, with just a few clicks of your mouse, the complex
interrelationships within an ARIS database. The data and interrelationships are visualized
graphically, but a table format can be provided also.
11.5.1.2.1 Get full customer journey overview

The Get full customer journey overview query is started for objects of the Customer
journey object type.
The query collects all customer journey maps assigned to the selected customer journey
objects and returns all information available about the customer journey steps and the related
customer touchpoints. The information belonging to a customer touchpoint describes the
customer touchpoint in detail, for example, the risks associated with it.
Figure 182: Customer journey overview
284
METHOD MANUAL
In addition to the graphical display, this query also provides a table showing a complete
overview of the customer journey, which can be used, for example, for data management.
Figure 183: Full overview – Customer journey table
The table contains information about the individual customer journey steps, for example, the
overall customer experience, as well as all important details about the customer touchpoints
of the selected customer journey, for example, which touchpoints represent a pain point for
the customer and which do not.
In addition to providing an overview, this table also enables you to specify attributes.
285
METHOD MANUAL
11.5.1.2.2 Find customer touchpoints clustered by

associated risk
This query is started for objects of the Risk object type. It shows all customer touchpoints
belonging to a risk to provide you with a quick overview.
Figure 184: Customer touchpoints by risk (query)
286
METHOD MANUAL

associated ownership
This query is started for objects of the Organizational unit object type and shows all
customer touchpoints belonging to an area of responsibility in order to provide you with a
quick overview.
Figure 185: Risks and initiatives for all customer touchpoints (query)
287
METHOD MANUAL

associated channel
This query is started for objects of the Distribution channel object type and shows all
customer touchpoints belonging to a distribution channel in order to provide you with a quick
overview.
Figure 186: Find customer touchpoints clustered by associated channel (query)
288
METHOD MANUAL
11.5.1.2.5 Find risks and initiatives for all customer

touchpoints
The Find risks and initiatives for all customer touchpoints query is started for customer
journey objects. It collects all customer journey maps assigned to the selected customer
journey objects and retrieves the corresponding customer touchpoints, as well as the
associated risks and planned initiatives for these touchpoints.
Figure 187: Risks and initiatives for all customer touchpoints (query)
The information about the customer journey objects and the corresponding customer
touchpoints is shown in a table returned by this query. The values for the Pain point, Moment
of truth, and Best practice attributes are included as additional details on the touchpoints.
Furthermore, the table contains all risks associated with the individual touchpoints, as well as
the planned initiatives.
289
METHOD MANUAL
11.5.1.2.6 Find risks and initiatives for bad customer

touchpoints only
The Find risks and initiatives for bad customer touchpoints only query is started for
customer journey objects. It contains information similar to the information provided by the
Find risks and initiatives for all customer touchpoints query, except that not all customer
touchpoints are evaluated. Instead, it evaluates only those for which the Pain point attribute
is specified as applicable, making this touchpoint a negative one for the customer. This query
also focuses on the risks associated with the individual touchpoints, and therefore provides
information about these, for example, the probability of their occurrence.
Figure 188: Risks and initiatives for bad customer touchpoints (query)
290
METHOD MANUAL
11.5.1.2.7 Find all processes related to customer journeys

This query is started for functions of a value-added chain diagram (VACD).
You can use it to detect customer touchpoints in internal processes and, in this way,
determine which customer journey map is connected with which internal process.
The query firstly shows all EPCs that are assigned to the selected functions. Then it shows all
functions of the EPC that are related to customer touchpoints.
Figure 189: Find all processes related to customer journeys
Besides the graphical display of interrelationships, this query provides a table with the
following information:
 The relevant EPC
 The process that is related to a customer touchpoint
 The customer touchpoint
 The specification whether the customer touchpoint is a pain point or a moment of truth
 The name of the customer journey in which the customer touchpoint occurs
291
METHOD MANUAL
12 Use cases
The purpose of this chapter is to assist you in finding the right ARIS support for specific
business management problems. Therefore, the chapter is divided into use case scenarios
(subchapters).
For each use case scenario the meaning of each scenario and the activities that are normally
performed in the corresponding scenario are briefly described. Subsequently, typical tasks
occurring in the scenario are described. For each task it is shown how ARIS can be used to
perform the task.
The following table gives an overview of the use cases described along with the model types
used:
Scenario Scenario tasks Model types

General company Documentation of business Objective diagram
documentation (page objectives Value-added chain diagram
295) Documentation of company Organizational chart
value-added
Function tree
Documentation of
EPC
organizational structures
Documentation of company
functions
Process documentation
Process warehousing
Database Data structuring/Database ERM

management/Data design IEF data model
warehousing (page 296) Database Table diagram
management/Access
Class diagram
management
PC hardware and network Identification of IT Network topology

management (page 297) infrastructure requirements Network diagram
Documentation of IT
infrastructure
Access privileges
Process cost Description of process and EPC

management (page 298) organizational structures Organizational chart
292
METHOD MANUAL

Cost center analysis
Process calculation
Quality management Creation of QM documentation Product tree

(page 299) Certification procedures Product selection matrix
Certification documents EPC
Value-added chain diagram
Structuring model
Organizational chart
Reorganization measures Project documentation Value-added chain diagram

(page 300) Performing a EPC
reorganization Organizational chart
Product model
Product/Service model
Objective diagram
SAP R/3 implementation Analysis phase, specification EPC

(page 301) phase (project preparation) Organizational chart
Design phase (Business
Blueprint); 3 use cases
available
Software development Project documentation Value-added chain diagram

and implementation Specification of application Organizational chart
(page 302) systems and modules EPC
Description of IT processes Use case diagram
System interface development Application system type diagram
Program flow chart

Screen diagram
293
METHOD MANUAL

Knowledge management Knowledge map or yellow page Knowledge map
(page 303) Categorization of knowledge Knowledge structure diagram
Knowledge processing in EPC
business processes Function allocation diagram
Workflow management Process customizing of EPC

(page 304) workflow management Function allocation diagram
systems
Application system diagram
Application system type diagram
294
METHOD MANUAL
12.1 General company documentation

Company characteristics, such as processes, structures, and data can be documented in
suitable form for training, presentation, and evaluation purposes of any kind. The most
important tasks of company documentation are briefly described below.
TASK: DOCUMENTATION OF BUSINESS OBJECTIVES

ARIS support: Objective diagrams can be used for hierarchical alignment of business
objectives and the corresponding success factors.
TASK: DOCUMENTATION OF THE COMPANY VALUE ADDED

Identification of the functions involved in value-adding activities of a company is the basis for
many corporate decisions.
ARIS support: The company functions involved in the value added can be displayed using the
value-added chain diagram. This model illustrates both the sequence of consecutive
functions, and superior and subordinate functions.
TASK: DOCUMENTATION OF THE ORGANIZATIONAL STRUCTURE

ARIS support: The structure of a company can be documented in organizational charts
illustrating the hierarchy and relationships of organizational units.
TASK: DOCUMENTATION OF COMPANY FUNCTIONS

ARIS support: A function tree can display an overview of a company's individual functions.
The functions are divided into object-oriented, process-oriented, or execution-oriented
functions.
TASK: PROCESS DOCUMENTATION

ARIS support: If utilization of process models by SAP® applications, simulations, workflows,
etc. is required, we recommend EPCs for modeling purposes.
TASK: PROCESS WAREHOUSING

Process warehousing is the systematic recording, storage, and maintenance of business
process knowledge in a repository.
ARIS support: EPCs are useful for modeling process knowledge, supported by documents,
images, and videos, so that the models can be used for demanding evaluations, such as
simulation or process cost management.
295
METHOD MANUAL
12.2 Database management/Data warehousing

By storing company data in databases, redundant data storage is reduced and
program-independent access to data used across the company is enabled. Data warehousing
ensures quality, integrity, and consistency of the underlying data. The term 'Data Warehouse'
generally designates a database that is isolated from operational IT systems and serves as a
company-wide data basis for all forms of management support systems. It is characterized by
strict separation from operational and decision-supporting data and systems. The focus of
the Data Warehouse concept is on efficient provision and processing of large amounts of data
to perform evaluations and analyses in decision-relevant processes.
TASK: DATA STRUCTURING/DATABASE DESIGN

The structure of databases is determined by the underlying data models.
ARIS support: The most widely used method of data modeling is the entity relationship
model (ERM), which serves as the basis for the implementation of a relational database.
The tables and fields of a database system are described by the table diagram.
Object-oriented database systems can be designed using the Unified Modeling Language
(UML). In UML, the class diagram can be used to show the static data relationships.
TASK: DATABASE MANAGEMENT/ACCESS MANAGEMENT

Assignment of users and system administrators to database systems.
ARIS support: The access diagram can be used in conjunction with relations and system
components to determine the access privileges that organizational units, positions, and
persons have for the database system.
296
METHOD MANUAL
12.3 PC hardware and network management

Network management is the control, monitoring, and coordination of all (distributed)
resources (data networks, processors, data, and applications) that enable communication in a
computer network.
TASK: IDENTIFICATION OF IT INFRASTRUCTURE REQUIREMENTS

Based on an existing organizational structure, communication and information system
infrastructures suitable for supporting it efficiently are to be derived.
ARIS support: The requirements of the information systems' structure can be depicted using
the network topology model type. The representation of application systems, network types,
and hardware components does not show individual, identifiable specimens (for example, PC
with inventory number 3423), but typifications based on the same technology.
TASK: DOCUMENTATION OF IT INFRASTRUCTURE

The task is to depict an existing or planned installation of an IT infrastructure with specific
hardware components, networks, and application systems.
ARIS support: An IT infrastructure can be illustrated using a network diagram as a concrete
implementation of a network topology.
TASK: ACCESS PRIVILEGES

The task is to demonstrate which applications and users have access to which data and in
which way.
ARIS support: The access diagram can be used to describe which applications or application
modules are allowed what kind of access (write/read/change) to databases and information
carriers, and whether the data acts as input or output. Furthermore, it can depict which user
privileges and views specific users or user groups have for the applications or application
modules.
297
METHOD MANUAL
12.4 Process cost management

By recording and allocating the costs arising from the commercial provision of products and
services, cost accounting provides a scheduling basis and a control instrument. Due to
changes in the cost structures, in particular the increase in overhead costs, traditional cost
accounting methods are replaced by process cost management. Process cost management
determines the costs of processes across cost centers. Budgeting, cost transparency in the
indirect performance areas, pricing, and support in make-or-buy decisions are the main
advantages of process cost management.
Parts of the ARIS support described in the following can be provided with ARIS Optimizer only.
TASK: DESCRIPTION OF PROCESS AND ORGANIZATIONAL STRUCTURES

The task is to determine the processes to which process cost management applies and to
describe cost centers.
ARIS support: Processes are illustrated using standard model types (for example, EPC).
Specifying time attributes and assigning organizational units are important steps in process
cost management.
The company organization is described in an organizational chart, in which the organizational
units correspond to cost centers (with the Cost rate and Products/Services attributes).
TASK: PROCESS CALCULATION

ARIS support: As a prerequisite, a complete cost center analysis must have been performed,
including the determination of process cost rates. No additional models are required to
perform process calculation. The results are shown in a calculation table.
298
METHOD MANUAL
12.5 Quality management

The term 'Quality Management' (QM) applies to all activities that define a company's quality
policy, objectives, and responsibilities. The means for implementing these activities include
quality planning, quality control (process management), quality assurance, and quality
improvement (quality promotion).
TASK: CREATION OF QM DOCUMENTATION

To ensure the quality of products and processes within a company, adequate documentation
has to be produced that enables the company to evaluate, compare, and improve products
and processes.
ARIS support: Product trees can be used for product documentation as they allow for
efficient classification of products. This type of representation is increasingly used in the
service industry, particularly in public administration. Furthermore, the product selection
matrix enables a company to illustrate which of its functions are required for the creation of
which products, and which organizational units are responsible for production.
Another main objective of QM documentation is to document processes that can be recorded
by means of EPCs, be evaluated by reports, or refer to documents and applications within the
company.
TASK: CERTIFICATION PROCEDURES

Use of procedure models to support project management in the certification process
according to nationally and internationally recognized standards, such as ISO or VDA.
ARIS support: A procedure model describing certification (for example, the ARIS procedure
model) can be represented using a value-added chain diagram. Individual steps can be
described in more detail by assigning additional process models.
TASK: CERTIFICATION DOCUMENTS

Creation of quality documents required for certification.
ARIS support: The structuring model subdivides individual certification standards into their
components. Individual items of a structuring model can be assigned company models for
quality control. For example, these models can be process models in the form of EPCs,
organizational charts, or value-added chain diagrams.
Using ARIS Architect, reports can be generated that are approved as a QM manual for
certification purposes.
299
METHOD MANUAL
12.6 Reorganization measures

Reorganization measures aimed at reducing costs or time or at improving the quality of
results or work involve modification of business processes (process redesign) or their
complete redevelopment (process reengineering).
TASK: PROJECT DOCUMENTATION

Documentation of reorganization measure planning, implementation, and results.
ARIS support: The main project phases of the reorganization process can be described as a
procedure model by a value-added chain diagram.
Individual project activities of the reorganization project and their operational sequence can
be documented by means of EPCs.
The organizational assignment of people and units involved in the project can be represented
in organizational charts.
TASK: PERFORMING THE REORGANIZATION

A reorganization project involves project preparation and strategic planning, followed by an
analysis of the actual situation, development of the target concept, and finally
implementation of the solutions.
ARIS support: Product/Service models as well as objective diagrams serve to document
general strategic conditions, so that the company's main business segments can be recorded
along with their products, services, and customer groups, and the critical success factors and
the objective hierarchy of the company can be depicted.
During the analysis of the actual situation, a framework containing the main business
processes is developed using value-added chain diagrams. Based on employee interviews,
these business processes are recorded in detail in the form of an EPC.
Following a weak point analysis that takes into account throughput times, process costs,
organizational breaks, system and media breaks, data redundancies, etc., alternative target
processes are defined. As with actual data, these processes are modeled using EPCs.
Once the target concept is complete, the system, organizational, and data components are
described in more detail, which facilitates implementation. For example, the application
system construct Word processing can now be specified as Microsoft® Word.
Note: The weak point analysis phase can be supported by evaluations using Simulation and
ARIS Optimizer.
300
METHOD MANUAL
12.7 SAP R/3 implementation

The support capabilities of ARIS in the implementation of the R/3 standard software by SAP
AG focus on the lifecycle of the ASAP implementation approach. However, in addition to
ASAP, other approaches geared more towards business process optimization (in the broadest
sense) are supported, as well. Parts of the ARIS support described in the following can be
provided with Extension pack SAP® only.
TASK: ANALYSIS PHASE, SPECIFICATION (PROJECT PREPARATION)

The task is identifying the degree of coverage of the company-specific processes via the
SAP® system, as well as timely identification of possible weak points.
ARIS support: If the analysis is not performed directly by the SAP R/3 reference model, the
'optimum business processes' to be supported can be modeled in ARIS (see general company
documentation). By mapping the company model with the SAP R/3 reference model, an initial
estimate of the degree of coverage can be obtained through reports.
TASK: DESIGN PHASE (BUSINESS BLUEPRINT)

Process and/or function deficits were identified in the SAP R/3 reference model.
ARIS support: Based on existing R/3 reference model components, new process and
scenario variants can be developed in ARIS. Furthermore, new functions, events, and rules
can be added to process and scenario components (that is, through the development of new
SAP® ABAP functions, if required).

Design of interfaces between SAP® R/3 and non-SAP® applications.
ARIS support: The documentation of the attributes to be exchanged can be described in
detail in process models in the ARIS Repository by assigning data or objects to functions and
data models or object models. This information can also be output in the form of reports and
establishes the basis for the development of interfaces.

Development of the organizational design of business processes and the SAP® system.
ARIS support: The company's social structure and the SAP® organizational structure can be
described and juxtaposed using organizational charts.
301
METHOD MANUAL
12.8 Software development and implementation
TASK: PROJECT DOCUMENTATION

Documentation of the planning, process steps, and results of software development and
implementation.
ARIS support: The main project phases can be described as a procedure model by a
value-added chain diagram.
Individual project activities during development and implementation and their operational
sequence can be documented by means of EPCs.
The organizational assignment of people and units involved in the project can be represented
in organizational charts.
TASK: SPECIFICATION OF APPLICATION SYSTEMS AND MODULES

The task is to show the structure of an information system based on system requirements.
ARIS support: The use cases of the software system to be developed can be identified by
means of the use case diagram. Furthermore, the system users can be defined and then
assigned to individual use cases. Often, the use case diagram is the starting point for detailed
process modeling. Process models can be assigned to individual use cases.
The application system type diagram may serve to describe the hierarchical structure of
application systems at type level using module types and IT function types.
Concrete occurrences describing specific types in more detail can be represented in the
application system diagram.
TASK: DESCRIPTION OF IT PROCESSES

The task is to describe the chronological-logical operational sequence of processes within
and across modules.
ARIS support: IT processes can be modeled in program flow charts.
TASK: DEVELOPMENT OF THE SYSTEM INTERFACE

The task is to develop and document a user interface.
ARIS support: The structural and functional organization of a screen (window) can be
described with a screen diagram. The screen diagram is the basis for deriving the program
code.
302
METHOD MANUAL
12.9 Knowledge management

The starting point for designing comprehensive knowledge management is the assumption
that knowledge has become or is becoming the dominant production factor in companies.
This results in the need to understand knowledge as a controllable element, just like the
classic operational production factors.
Therefore, knowledge management focuses on acquisition, representation, and distribution of
knowledge. Knowledge management is the sum of all methods, measures, and systems used
by an organization to develop knowledge, render it transparent, and provide it regardless of
time, people, and location. The aim of knowledge management is to increase knowledge and
to apply existing knowledge in the company in an optimal way.
TASK: KNOWLEDGE MAP OR YELLOW PAGE

The objective is to show what knowledge is available in the company and where.
ARIS support: The Knowledge map model type can be used to display the organizational
distribution of different knowledge categories. It shows which organizational unit, position, or
employee has expertise in certain knowledge categories, and at what level of competence.
TASK: CATEGORIZATION OF KNOWLEDGE

The task is to analytically classify the intellectual capital of an organization, that is, to
describe the various types and groups of knowledge in order to design a knowledge storage
structure, for example.
ARIS support: The knowledge structure diagram can be used to show how the knowledge
base of an organization is divided into different knowledge categories and how these are
further broken down into knowledge categories and documented knowledge. For documented
knowledge, it is also possible to depict the information carriers storing the knowledge.
TASK: KNOWLEDGE PROCESSING IN BUSINESS PROCESSES

The task is to show where knowledge is generated, modified, and required in business
processes so that the most efficient use of the knowledge resource can be determined.
ARIS support: The EPC, Process chain diagram, and Function allocation diagram model
types provide the Knowledge category and Documented knowledge objects. The
knowledge structure and the organizational distribution of knowledge can be described
separately by means of the knowledge structure diagram and the knowledge map.
303
METHOD MANUAL
12.10 Workflow management

In the broadest sense, a workflow can be interpreted as a business process. The term
'workflow' describes processes that are based on the division of labor and initiated to carry
out business transactions. This can include both very simple business processes and
complex, cross-organizational processes. The focus of the analysis is on the dynamic process
flow from start to completion. Workflow management is the sum of methods, measures, and
systems used in order to develop, control, and optimize workflows.
A workflow management system is actively operating, flexibly designable software that works
according to an organizational framework of rules and controls a process spanning several
workstations and integrating existing basic technical components. Process control systems
can be used to support complex tasks involving a large number of employees and positions.
TASK: PROCESS CUSTOMIZING OF WORKFLOW MANAGEMENT SYSTEMS

A special focus of ARIS is to support the transfer of general business process models into
workflow models that can be used to configure various workflow management systems
(semi-)automatically.
ARIS support: As with process modeling, the activity flow is depicted in an EPC. Modeling has
to be done in strict adherence to the method! A function allocation diagram has to be created
for each function, where a user as well as input and output data are allocated to the function
- unless this has already been represented in the EPC.
In order for data-related applications to be launched automatically at runtime, files must be
assigned to applications in an application system diagram or an application system type
diagram.
304
METHOD MANUAL
13 Bibliography
13.1 General literature list

 Brombacher, R.; Bungert, W.: 'Praxis der Unternehmensmodellierung' [Enterprise modeling
practise], 1992.
Enterprise modeling practise, a seminar by IDS Prof. Scheer GmbH, Bad Soden/Taunus
(Germany), November 12-13, 1992.
 Chen, P. P.: Entity-Relationship Model, 1976
The entity-relationship model - toward a unified view of data, in: ACM Transactions on
Database Systems, Volume 1 (1976), Issue 1, pages 9 - 36.
 Hoffmann, W.; Kirsch, J.; Scheer, A.-W.: 'Modellierung mit Ereignisgesteuerten

Prozeßketten' [Modeling with event-driven process chains], 1993
Modeling with event-driven process chains (Methods Manual, as of December 1992), in:
Scheer, A.-W. (editor), Publication of the 'Institut für Wirtschaftsinformatik' [Institute for
Information Systems], paper 101, Saarbrücken, January 1993.
 Keller, G.; Hechler, H.-J.: 'Informationsmodell' [Information Model], 1991
'Konzeption eines integrierten Informationsmodells für die Kostenrechnung des

SAP®-Systems' [Design of an integrated information model for cost accounting in the
SAP® system], in: Scheer, A.-W. (editor): 'Rechnungswesen und EDV - 12. Saarbrücker
Arbeitstagung 1991. Kritische Erfolgsfaktoren im Rechnungswesen und Controlling' [12th
Saarbrücken conference for accounting and IT 1991. Critical success factors in
accounting and controlling], Heidelberg 1991, pages 67 - 106.
 Scheer, A.-W.: Architecture of Integrated Information Systems, 1992
Architecture of Integrated Information Systems - Foundations of Enterprise Modelling,

2nd edition, Berlin et al. 1992.
 Scheer, A.-W.: 'EDV-orientierte Betriebswirtschaftslehre' [EDP-oriented business

management], 1990
'EDV-orientierte Betriebswirtschaftslehre - Grundlagen für ein effizientes

Informationsmanagement' [EDP-oriented business management - Foundations of
efficient information management], 4th edition, Berlin et al. 1990.
 Scheer, A.-W.: Business Process Engineering, 1994
Business Process Engineering - Reference Models for Industrial Enterprises, 5th edition,
Berlin et al. 1994.
305
METHOD MANUAL
 Schlageter, G.; Stucky, W.: 'Datenbanksysteme' [Database systems], 1983
'Datenbanksysteme - Konzepte und Modelle' [Database systems: Concepts and models],

2nd edition, Stuttgart 1983.
 Seubert, M.: 'SAP®-Datenmodell' [SAP® data model], 1991
'Entwicklungsstand und Konzeption des SAP®-Datenmodells' [State of development and

design of the SAP® data model], in: Scheer, A.-W. (editor): 'Datenbanken 1991 - Praxis
relationaler Datenbanken: Vom Datenmodell zur Implementierung' [Databases 1991 -
Relational database practise: From data model to implementation (symposium
06/04-06/05 1991 in Saarbrücken/Germany)], Saarbrücken 1991, pages 87 - 109.
 Sinz, E. J.: 'Entity-Relationship-Modell' [Entity Relationship Model], 1990
'Das Entity-Relationship-Modell (ERM) und seine Erweiterungen' [The Entity Relationship

Model (ERM) and its extensions], in: 'HMD Theorie und Praxis der Wirtschaftsinformatik
(1990)' [HMD magazine on the theory and practice of business process engineering
(1990)], paper 152, pages 17 - 29.
 Scheer, A.-W.: ARIS - Business Process Frameworks. 3. edition Berlin et al. 1998.
 Scheer, A.-W.: ARIS - Business Process Modeling. 3. edition Berlin et al. 1998.
 Scheer, A.-W., Jost, W.: 'ARIS in der Praxis' [ARIS in Practice], 2002
'Gestaltung, Implementierung und Optimierung von Geschäftsprozessen' [Design,

Implementation and Optimization of Business Processes], Berlin, Heidelberg, New York
2002.
 Scheer, A.-W., Abolhassan, F., Jost, W., Kirschmer, M.: Business Process Excellence, 2002
ARIS in Practice , Berlin, Heidelberg, New York 2002.
306
METHOD MANUAL
13.2 Topic-related bibliography
13.2.1 Unified Modeling Language in ARIS
13.2.1.1 UML specification

UML specification: http://www.uml.org.
13.2.1.2 Using UML

 Burkhardt, R.: 'UML - Unified Modeling Language, Objektorientierte Modellierung für die
Praxis' [Object-Oriented Modeling in Practice], Bonn 1997.
 Fowler, M.; Scott, K.: UML Distilled - Applying the Standard Object Modeling Language,
Reading et al. 1997.
 Oesterreich, B.: Developing Software with UML: Object-oriented analysis and design in
practice, 3rd edition, Munich/Vienna 1997.
13.2.1.3 UML and business process modeling

 Ambler, S. W.: What's Missing from the UML? Techniques that can help model effective
business applications, Object Magazine 7(1997)8
 Loos, P.; Allweyer, Th.: Process Orientation and Object-Orientation - An Approach for
Integrating UML and Event-Driven Process Chains (EPC), Publication of the 'Institut für
Wirtschaftsinformatik' [Institute for Information Systems], Paper 144, Saarbrücken 1998.
307
METHOD MANUAL
13.2.2 Methods for knowledge management
13.2.2.1 General knowledge management

 Probst, G.; Raub, S.; Romhardt, K.: Managing Knowledge - Building Blocks for Success.
Frankfurt/Wiesbaden 1998.
 Bürgel, H. D. (editor): 'Wissensmanagement - Schritte zum intelligenten Unternehmen'
[Knowledge management - Steps towards an intelligent company]. Berlin et al. 1998.
13.2.2.2 Using ARIS for knowledge management

 Allweyer, Th.: 'Modellbasiertes Wissensmanagement' [Model-based knowledge
management]. In: IM Information Management & Consulting 13 (1998) 1, pp. 37-45.
 Allweyer, Th.: Using ARIS Models for Knowledge Management. In: Scheer, A.-W.: ARIS -
Business Process Frameworks. 3. edition Berlin et al. 1998, p. 162-168.
13.2.3 Balanced Scorecard method

Kaplan, Robert/Norton, David: The Balanced Scorecard - Measures that Drive Performance,
Harvard Business Review January/February 1992.
13.2.4 IT City Planning

 Schulman, Jeff: A New View of Architectures Needed for New Business Drivers, Gartner
Briefing Presentations.
 Longépé, Christoph: Le projet d'urbanisation du système d'information, Dunod, Paris,
2001
13.2.5 Business process modeling

Business Process Modeling Notation, Working Draft (1.0); BPMI.org; August 25, 2003.
308
METHOD MANUAL
14 Legal information
14.1 Documentation scope

The information provided describes the settings and features as they were at the time of
publishing. Since documentation and software are subject to different production cycles, the
description of settings and features may differ from actual settings and features. Information
about discrepancies is provided in the Release Notes that accompany the product. Please
read the Release Notes and take the information into account when installing, setting up, and
using the product.
If you want to install technical and/or business system functions without using the
consulting services provided by Software AG, you require extensive knowledge of the system
to be installed, its intended purpose, the target systems, and their various dependencies. Due
to the number of platforms and interdependent hardware and software configurations, we
can describe only specific installations. It is not possible to document all settings and
dependencies.
When you combine various technologies, please observe the manufacturers' instructions,
particularly announcements concerning releases on their Internet pages. We cannot
guarantee proper functioning and installation of approved third-party systems and do not
support them. Always follow the instructions provided in the installation manuals of the
relevant manufacturers. If you experience difficulties, please contact the relevant
manufacturer.
If you need help installing third-party systems, contact your local Software AG sales
organization. Please note that this type of manufacturer-specific or customer-specific
customization is not covered by the standard Software AG software maintenance agreement
and can be performed only on special request and agreement.
14.2 Support
If you have any questions on specific installations that you cannot perform yourself, contact
your local Software AG sales organization
(https://www.softwareag.com/corporate/company/global/offices/default.html). To get
detailed information and support, use our websites.
If you have a valid support contract, you can contact Global Support ARIS at: +800
ARISHELP. If this number is not supported by your telephone provider, please refer to our
Global Support Contact Directory.
309
METHOD MANUAL
ARIS COMMUNITY
Find information, expert articles, issue resolution, videos, and communication with other ARIS
users. If you do not yet have an account, register at ARIS Community.
PRODUCT DOCUMENTATION
You can find the product documentation on our documentation website.
In addition, you can also access the cloud product documentation. Navigate to the desired
product and then, depending on your solution, go to Developer Center, User Center or
Documentation.
PRODUCT TRAINING
You can find helpful product training material on our Learning Portal.
TECH COMMUNITY
You can collaborate with Software AG experts on our Tech Community website. From here
you can, for example:
 Browse through our vast knowledge base.
 Ask questions and find answers in our discussion forums.
 Get the latest Software AG news and announcements.
 Explore our communities.
 Go to our public GitHub and Docker repositories and discover additional Software AG
resources.
PRODUCT SUPPORT
Support for Software AG products is provided to licensed customers via our Empower Portal
(https://empower.softwareag.com/). Many services on this portal require that you have an
account. If you do not yet have one, you can request it. Once you have an account, you can,
for example:
 Download products, updates and fixes.
 Add product feature requests.
 Search the Knowledge Center for technical information and tips.
 Subscribe to early warnings and critical alerts.
 Open and update support incidents.
310
METHOD MANUAL
Design operators added • 31

15 Index
Distinction from entity type • 26
A Domain • 26
ERM base model • 26
A2A • 150 Occurrences • 26
A2B • 150 Passed on • 31
A2C • 150 Requirements definition • 26
Abstract business process • 175 Authorities • 53
Access diagram • 101 Authorization • 93
Access diagram (physical) • 108 Authorization concept • 49
Access privilege Authorization type • 93
Implementation - Table diagram • 46
PC hardware and network management • B
300
B2A • 150
Achievement of objectives • 137
B2B • 150
Action program • 137
Balanced Scorecard (BSC)
Activity • 185
Acceptance • 137
Actual value • 140
Advantages and benefits • 139
Aggregation operator • 31
Approach • 131
Analysis
B2C • 150
SAP R3 introduction • 304
Balanced Scorecard system structure
Strategy • 132 specification • 142
AND rule • 67 BSC KPI allocation diagram • 146
Annotation • 190 Cause-and-effect chain • 136
Application scenario • 295 Cause-and-effect relationship
Application system type specification • 143
Definition • 23 Concept • 131
Design specification - Application system Customer perspective • 135
type diagram • 18 E-business scenario • 155
Information flows between application Economic/Financial perspective • 131
system types • 101
External performance perspective • 131
Modular structure • 18
Financial perspective • 135
Specimens of an application system type
• 23 Function tree • 142
Application system type hierarchy • 169 Human-oriented perspective • 140
Applications • 300 Internal performance perspective • 131

Architecture of Integrated Information Learning and growth perspective • 131
Systems (ARIS) Method • 131
Company structure • 50 Object relation to ARIS models • 149
Concept • 3 Organizational chart • 142
Descriptive levels • 7 Performance management • 142
Introduction • 1 Performance measurement • 142
Organization view • 50 Process perspective • 135
Artifact • 190 Recognition • 137
Attribute Stages • 132
Coverage quality • 128 Standard perspective • 135
Degree of coverage • 128 Structuring model • 142
i
METHOD MANUAL
Value-added chain diagram • 142 Loop characteristics representations •

Bottom-up process • 138 239
BPMN Message flow • 208
Activities • 222 Message flow (connection type) • 272
Activity type - Subprocess • 230 Message flow (conversation) • 276
Activity type - Task • 225 Model assignments • 276
Artifacts • 197 Not considered elements • 218
Artifacts (conversation) • 275 Parallel gateway • 265
Association • 201 Participant • 210
Callable Elements • 203 Participant (conversation) • 274
Catch and throw events • 250 Performer • 225
Collaboration • 269 Pool and participant • 270
Common Elements • 197 Process • 220
Complex gateway • 187 Process classes/business process
diagram • 175
Conversation • 272
Purpose BPMN chapter • 193
Conversation container • 273
Resource • 214
Conversation link • 275
Resource assignment • 225
Conversation nodes • 273
Reused types • 271
Core elements • 194
Sequence flow • 214
Data object • 244
Standard and multi-instance loop
Data store • 247
characteristics • 241
Diagrams/model types overview • 219
Start event • 252
End event • 254
Subprocess type - Ad hoc subprocess •
Enterprise BPMN collaboration diagram • 235
277
Subprocess type - Call Activity • 237
Event • 203
Subprocess type - Event subprocess •
Event definitions • 255 233
Event-based gateways • 266 Subprocess type - Subprocess • 231
Events • 248 Subprocess type - Transaction • 234
Exclusive gateway • 264 Text annotation • 202
Expression • 204 Breakdown (organizational) • 50
Flow element • 204 Breaks • 303
Flow element container • 205 BSC Cause-and-effect diagram
Foundation • 195 Cause-and-effect relationship
Gateway • 206 specification • 143
Gateways • 263 Structure • 142
Global task • 239 Symbols • 143
Group • 201 BSC KPI allocation diagram
Human interactions • 230 BSC KPI allocation diagram • 146
Inclusive gateway • 264 Symbols • 146
Infrastructure • 194 Budget
Initial situation • 193 Budgeting process • 137
Intermediate events • 253 Targets • 137
Items and Data • 244
Lanes • 267
Loop characteristics • 239
ii
METHOD MANUAL
Budgeting • 301 Business to Business • 150

Budgeting process • 139 Business to Consumer • 150
Building cluster • 162 Business units • 133
Business blueprint • 304 Business/Consumer to Administration • 150
Business controls diagram • 88
C
Business documents • 152
Business objectives C++ development environment • 96
Balanced Scorecard • 131 C2A • 150
Hierarchical arrangement • 298 C2B • 150
Objective diagram • 17 Calculation table • 301
Organizational chart • 53 Capability • 162
Business participant Capital investment • 137
E-Business scenario diagram • 89 Cash flow • 133
E-Business scenario diagram and its Categorization of knowledge • 306
objects • 152 Cause-and-effect relationships
Business process Balanced Scorecard • 135
Branches and processing loops • 67 Cause-and-effect chain • 136
Design • 304 Certification
Event and function columns • 67 Documents • 302
Function tree • 12 Procedures • 302
Holistic view • 1 Structuring model • 92
Introduction • 150 CIM • 50
Knowledge • 298 Classification • 31
Logical-chronological procedure • 67 Cluster • 31
Modeling • 1 Collaboration processes • 175
Modeling objectives • 17 Collaborative business maps • 155
Optimization • 304 Commercial • 301
Business process automation • 175 Communication campaign • 137
Business process diagram Company
BPMN realization • 177 In databases • 299
Business process modeling • 175 Mission statement • 133
Process classes • 175 Performance goal • 133
Business process modeling Perspectives • 131
Communication technologies • 175 Philosophy • 133
Information technologies • 175 Strategy • 131, 133
Views • 131
Company analysis
Vision • 131
iii
METHOD MANUAL
Company documentation • 298 D

Company functions • 298
Data cluster • 31
Company model • 304
Data object • 190
Competitive strategy • 131
Data redundancies • 303
Complexity • 26
Data source
Complexity reduction • 139
Data source • 140, 146
Consensus building • 139
Data structure • 299
Control instrument • 301
Data structuring/Database design • 299
Control view
Data view
Access diagram • 101
Implementation • 46
ARIS • 67
Requirements definition • 26
ARIS House • 50
Data Warehouse method • 146
Descriptive views • 3
Data Warehouse structure diagram • 44
Requirements definition • 65
Database management system • 18
Core competence • 132
Database management system type • 18
Corporate decisions • 298
Database management/Access
Corporate management • 139
management • 299
Cost accounting • 301
Database system
Cost center analysis • 301
Implementation - Table diagram • 46
Cost reduction • 137
Object-oriented • 299
Costs
Decision-making power • 65
Reduction • 303
Definition • 62
Structures • 301
Degree of coverage
Transparency • 301
Knowledge category • 124
CRM system • 159
Knowledge map • 128
Customer Experience Management (CXM)
Degree of goal accomplishment • 140
Analysis capabilities • 285
Description of IT processes • 305
Customer journey landscape • 279
Descriptive ERM attribute • 41
Customer touchpoint allocation diagram
Descriptive level • 7
• 282
Customer touchpoint map • 283 Design
Business processes • 304
CXM • 278
Linking CXM and BPM • 284 Organizational design of business
processes • 304
Query – All processes related to
customer journeys • 294 Organizational design of the SAP System
• 304
Query – Customer touchpoints clustered
by associated channel • 291 PC hardware and network management •
300
by associated ownership • 290 Design operator
eERM • 43
by associated risk • 289 Types • 31
Query – Full overview • 287 Design operators
Query – Risks for all customer Design operators • 31
touchpoints • 292 Occurrence level • 26
Query – Risks for bad customer Type level • 26
touchpoints • 293
Report • 285
iv
METHOD MANUAL
Design phase (Business Blueprint) • 304 Economic agent • 89

Design process • 31 eERM
Design specification Design operators • 43
Control/Process view • 101 ERM attribute • 41
Descriptive levels • 7 ERM attribute allocations • 41
Descriptive views • 3 ERM base model • 26
Function view • 18 ERM relationship type • 41
Development of interfaces • 304 Structural elements • 43
Dimension table • 44 Terms and forms of representation • 43
Direction of effect • 140 Effectiveness • 140
District • 162 Elementary function • 12
Document Elementary process • 93
HTML • 89 Elementary role • 93
XML • 89 E-mail • 152
Documentation Enterprise BPMN collaboration diagram •
Business objectives • 298 277
Company functions • 298 Entity relationship model
Organizational structure • 298 Base model • 26
Documented knowledge • 123 ERM • 26
Domain Extensions • 31
ERM base model • 26 Modeling • 26
Implementation • 46 Entity set • 31
Double-loop learning • 131 Entity type
Key elements of the BSC approach • 131 Aggregation • 31
Strategic learning and feedback • 138 Distinction from attribute • 26
Draft list • 18 Examples • 26
DW structure Environment
Modeling • 44 Organizational structure • 50
Relationship to other models • 149 State description • 3
DW transformation • 149 EPC
Branches and processing loops • 67
E Column/Row display • 86
E-business Event control • 67
Definition • 150 Material flow • 83
Scenario diagram • 89 Process selection matrix • 82
E-business scenario Product/Service exchange modeling •
115
Balanced Scorecard • 155
Relationships to other models • 149
Diagram • 89
EPC (row display) • 86
Idea • 152
ERM base model
Introduction • 150
ERM base model • 26
Model and object • 152
Extension • 36
Protection • 154
Lower limit • 36
Report • 154
ERP system
Transaction protection • 154
Connection • 155
Transmission path • 154
IT City Planning • 159
v
METHOD MANUAL
XML • 155 Function allocation diagram • 77

Evaluation scale • 93 Function tree
Event Execution-oriented • 12
Function tree • 12 Model • 12
Graphical representation • 67 Object-oriented • 12
Operator • 67 Process-oriented • 12
Start and end events • 26 Semantic • 12
Event diagram • 80 Function view
Execution-oriented • 298 Descriptive views • 3
Existence dependency • 38 Linking organization with functions • 65
Extensible markup language (XML) • 155 Requirements definition • 11
Extranet • 152 Function/Organizational level diagram • 65
Functional block • 162
F
Future significance • 124
Fact hierarchy • 92
G
Fact table • 44
Feedback process • 138 Gateway
Field (specimen) • 46 Complex gateway • 187
Financial KPI • 131 Symbols • 187
Financial objective • 136 Types • 187
Focus on the past • 139 Generalization
Form field • 98 Generic term • 31
Frame • 98 Occurrences • 31
Function Structuring model • 92
Aggregation levels • 12 Subterm • 31
Assignment to data • 67 Goods shipment • 89
Automated • 12 Group • 190
Batch run • 12 Grouping • 31
Degree of integration • 65
H
Execution • 12
Execution-oriented grouping • 12 Hierarchical arrangement
Grouping criteria • 12 Hierarchy model • 12
Hierarchy levels • 12 Success factors • 17
Integration • 50 HTML document • 89
Operational sequence (EPC) • 67 Human resources development • 133
Operational sequence (Function tree) •
12 I
Orientation time • 12 Identification and existence dependency •
Procedure • 3 38
Processing time • 12 IE data model • 42
Process-oriented breakdown • 12 IE notation • 42
Quantity structure • 12 Implementation
Rule • 67 Data view • 46
Units of time • 12 Function view • 23
Wait time • 12 Implementation • 7
vi
METHOD MANUAL
Implicit relationship • 86 Simple • 31

Indicator Key attribute • 26
Lagging indicator • 136 Knowledge
Leading indicator • 136 Category • 124
Type • 140 Degree of coverage • 124
Individual process • 89 Documented • 123
Industry • 298 Knowledge map • 128
Influencing factor • 140 Knowledge structure diagram • 127
Information carrier diagram • 45 Knowledge usage • 124
Information flow diagram • 77 Processing in business processes • 306
Information system Term • 123
Lifecycle • 7 Usage • 306
Procedure model for development • 7 KPI system • 139
Support • 127
L
Information technology • 133
Initiative • 140 Lagging indicator • 136
Innovations • 133 Lane • 178
Input/Output diagram • 77 Leading indicator • 136
Integration concept • 3 Lean management • 50
Intellectual capital • 306 Lean production • 50
Interaction • 133, 140 Level or phase concept • 7
Interfaces Life cycle concept • 3
SAP R/3 and non-SAP applications • 304 Line position • 53
Interrelation • 138 List • 18
Interviews • 303
IS service • 162
M
IS view • 162 Make-or-buy decisions • 301
ISO • 302 Management bottleneck • 139
IT blocks • 169 Management information • 131
IT City Planning report Management process (strategy) • 132
Aim (detailed) • 159 Management support systems • 299
Aim (superior) • 159 Market growth • 143
Companies affected • 159 Material flow (EPC) • 83
Evaluation • 174 Maximum value • 140
IT City Planning • 159 Media breaks • 303
Views • 160 Message flow • 175
IT function • 18 Methods • 7
IT function type (definition) • 18 Minimum value • 140
IT procedures • 169 Mission statement • 133
IT processes • 305 Mobile phone • 89
IT software • 169 Model
IT view • 169 Access diagram • 101
Access diagram (physical) • 108
K
Application system type diagram • 18,
Key 23
Complex • 31 Business controls diagram • 88
vii
METHOD MANUAL
Collaborative business maps • 155 Semantic • 7

DW structure • 44 Module (definition) • 23
E-Business scenario diagram • 89, 150 Module type (definition) • 18
eERM • 31 Money transaction
eERM attribute allocation diagram • 41 E-Business scenario diagram • 89
EPC (column/row display) • 86 Object • 152
EPC (event-driven process chain) • 67
N
EPC (material flow) • 83
EPC (row display) • 86 Network • 60
ERM base model • 26 Network connection • 60
Function allocation diagram • 77 Network diagram • 60
Function tree • 12 Network management • 300
Function/Organizational level diagram • Network node • 60
65 Notation
IE data model • 42 Identification and existence dependency
Information carrier diagram • 45 • 38
Information flow diagram • 77
Input/Output diagram • 77
O
Knowledge map • 128 Object Management Group • 122
Knowledge structure diagram • 127 Object Modeling Technique • 299
Network diagram • 60 Objective
Objective diagram • 17 Definition • 17
Organizational chart • 53 Departmental goal • 139
Process selection matrix • 82 Economic/Financial • 140
Product allocation diagram • 118 Individual • 139
Product selection matrix • 121 Operational-monetary • 139
Product tree • 120 Strategic • 131, 139
Product/Service exchange diagram • 115 Objective diagram • 17
Product/Service tree • 117 Objective hierarchies • 17
Quick model • 94 Object-oriented database systems • 299
Role allocation diagram • 49 Online shop
Role diagram • 93 Example • 155
Screen design • 96 Model • 155
Screen diagram • 105 Operating resource
Screen navigation • 98 EPC (material flow) • 83
Semantic • 7 Technical resource • 62
Service allocation diagram • 167 Operating resource type • 83
Structuring model • 92 Operating system • 18
Swimlane • 1 Operating system type • 18
Table diagram • 46 Operator
Technical resources • 62 AND • 67
Technical terms model • 39 Complex relationships • 67
Modeling Event • 67
Actual business situation • 1 Function • 67
Material flow • 82 General rule • 67
Methods • 1 Logical AND operator • 67
viii
METHOD MANUAL
Logical OR operator • 67 Person responsible • 3

Logical XOR operator • 67 Person type • 53
OR • 67 Philosophy • 133
Rules • 67 Pipeline diagram • 155
XOR • 67 Plan progress figure • 138
OR operator • 67 Plan value • 140
OR rule • 67 Planned-Actual comparison • 140
Organization • 50 Planning (strategic) • 303
Organization view Planning process • 139
Descriptive views • 3 Pool • 178
Linking organization with functions • 65 Position • 53
Requirements definition • 50 Pricing • 301
Organizational • 50 Private business process • 175
Organizational Private process • 177
Breakdown • 50 Problem (business) • 295
Organizational units • 50 Procedure
Structuring • 50 Bottom-up • 31
Unit • 50 Descriptive views • 3
Organizational Function tree • 12
Element • 86 Top-down • 31
Organizational Procedure concept • 1
Breaks • 303 Process
Organizational chart • 53 Costs • 133
Organizational complexity management • Definition of process selection matrix •
50 82
Organizational form • 50 Descriptive views • 3
Organizational structure • 50 Feedback • 138
Area-based • 50 Function tree • 12
Balanced Scorecard systems • 142 Times • 133
General company documentation • 298 Process and organizational structures • 301
Organizational company structure • 50 Process and/or function deficits • 304
Product-related • 50 Process calculation • 301
Organizational unit Process cost rate • 301
Assignment to functions • 67 Process documentation • 298
Descriptive views • 3 Process knowledge • 298
Organizational chart • 53 Process management • 302
Organizational unit type • 152 Process organization • 50
Process reference model • 93
P
Process risks • 88
Packaging material type • 83 Process selection matrix • 82
Partial strategy • 132 Process type • 298
Performance driver • 136 Process variants • 304
Performance measurement Process view
Approach • 131 ARIS • 67
Balanced Scorecard system • 142 Requirements definition • 65
System • 131
ix
METHOD MANUAL
Process warehousing • 298 B2C • 89

Process-oriented • 298 Complexity • 26
Product • 114 Existence • 26
Product allocation diagram • 118 Implicit • 1, 86
Product selection matrix • 121 Relationship • 26
Product tree • 120 Types • 26
Product/Service • 114 Relationship type
Product/Service exchange diagram • 115 Formation • 31
Product/Service tree • 117 Identification and existence dependency
Production intensity • 137 • 38
Program code • 305 Requirements definition • 26
Program file • 23 Types • 26
Program module (definition) • 23 Reorganization
Program module type Execution • 303
Assignment to application system types Measures • 303
• 23 Report
Assignment to program modules • 23 E-business scenario • 154
Definition • 23 Reporting • 139
Programming language • 18 Requirements definition
Project documentation Data view • 26
Reorganization measures • 303 Descriptive levels • 7
Software development and Function view • 11
implementation • 305 Organization view • 50
Project preparation • 304 Resource
Information technology • 3
Q
Record • 133
QM documentation • 302 Resource view • 3
QM manual • 302 Result indicator • 137
Quality Result quality • 303
Assurance • 302 Return on capital employed • 133
Control • 302 Risk
Criterion • 92 Process risks • 88
Documents • 302 Risk • 88
Improvement • 302 Risk control • 88
Management • 302 Risk handling • 88
Planning • 302 Risk resolution • 88
Policy • 302
Promotion • 302
Quick model • 94
R
RAD • 49
Referential data integrity • 38
Reinterpreted relationship type • 31
Relationship
B2B • 89
x
METHOD MANUAL
ROI • 133 Specification • 304

Role • 49 Specification of application systems and
Role allocation diagram • 49 modules • 305
Role assignment diagram • 49 Staff position • 53
Role diagram • 93 Standard perspective • 135
Role name • 26 Star schema • 44
Rule • 67 Start and end events • 67
State • 3
S State change • 67
Sales revenue • 133 States (relevant process environment) • 3
SAP applications • 298 Strategic objective • 140
SAP system • 304 Strategy
Scenario Analysis • 132
Definition in the process selection matrix Business segment-specific • 132
• 82 Business units • 133
Variants • 304 Competition • 131
Scheduling basis • 301 Corporate strategy • 133
SCM solution • 159 Formulation of actions • 139
Screen design • 18, 96 Human resources development • 133
Screen diagram • 105 Implementation • 137
Screen navigation • 98 Inconsistency • 138
Security protocol • 152 Information technology • 133
Semantic • 26 Innovations • 133
Semantic Generator • 94 Learning • 138
Sequence flow • 175 Management process • 132
Service • 114 Market-oriented • 133
Service allocation diagram Objective • 140
Cluster • 167 Partial strategy • 132
IT elements • 171 Planning process • 139
Service type • 162 Pursuit • 138
Shareholder value • 133 Superior • 137
Similar entity • 26 Term • 140
Simulation • 298 Theoretical formulation • 139
Skill • 93 Structural change speed • 124
Sorting index • 46 Structural element • 92
Specialization Structural elements of the eERM • 43
Completeness • 31 Structuring model • 92
Disjunction • 31 Generalization • 92
Occurrences • 31 Specialization • 92
Subfunction • 12
Subobjective • 136
Substitution relationship • 117
Subsystem • 169
Success factor
Company documentation • 298
Definition • 17
xi
METHOD MANUAL
Factors influencing success • 140 Knowledge processing in business

Hierarchical arrangement • 17 processes • 306
Interaction • 140 Performing a reorganization • 303
Synergy effect • 137 Process calculation • 301
System Process documentation • 298
CRM • 159 Process warehousing • 298
ERP • 159 Reorganization measures • 303
Management support • 299 Software development and
implementation • 305
System interface • 305
Specification of application systems and
System interface development • 305
modules • 305
T System interface development • 305
Task performer
Table • 46
Linking functions with organization -
Table (specimen) • 46 EPC, Function/Organizational level
Table diagram • 46 diagram • 65
Tables and fields • 46 Organizational structure of companies •
Target • 137 50
Target time period • 140 Task performer
Target value • 137, 140 Organizational chart • 53
Task Techn. operating supply (definition) • 62
Access privileges • 300 Techn. operating supply class (definition) •
62
Analysis phase, specification phase
(project preparation) • 304 Technical operating supply type
Categorization of knowledge • 306 Definition • 62
Certification documents • 302 Technical operating supply type • 83
Certification procedures • 302 Technical resources • 62
Cost center analysis • 301 Technical terms model • 39
Creation of QM documentation • 302 Term
Data structuring/Database design • 299 Actual value • 140
Database management/Access Alarm limit • 140
management • 299 Data source • 140
Description of IT processes • 305 Indicator type • 140
Description of process and organizational Initiative • 140
structures • 301 KPI • 140
Design phase (Business Blueprint) • 304 Maximum value • 140
Documentation of business objectives • Minimum value • 140
298
Perspective • 140
Documentation of company functions •
Plan value • 140
298
Strategic objective • 140
Documentation of company value-added
• 298 Strategy • 140
Documentation of IT infrastructure • 300 Success factor • 140
Documentation of organizational Target value • 140
structures • 298 Tolerance range • 140
Identification of IT infrastructure Vision • 140
requirements • 300 Warning limit • 140
Knowledge map or yellow page • 306
xii
METHOD MANUAL
Time reduction • 303 Virtual place • 150

Tolerance range • 140 Vision • 140
Top management • 133
W
Top-down approach • 137
Transaction steps • 18 Warehouse equipment (definition) • 62
Transport system (definition) • 62 Warehouse equipment class (definition) •
Transport system class (definition) • 62 62
Type level • 26 Warning limit • 140
Weak point (SAP) • 304
U Weak point analysis • 298
Unified Modeling Language • 122 Web form • 96
Unit • 50 Web services • 175
Updating frequency • 124 Work quality • 303
User groups • 300 Workflow • 298
User interface • 18 Workshop • 140
User privileges • 300
X
User profile • 49
Users • 300 XML • 155
XML document • 89
V XOR rule • 67
Value-added • 298
Y
Value-added chain • 89
Variant • 118 Yellow page • 306
Process • 304
Z
Scenario • 304
VDA • 302 Zone • 162
View
Breakdown • 3
Formation • 7
Human-oriented • 140
Physical • 46
xiii

ARIS Method Manual

Uploaded by

Copyright:

Available Formats

ARIS Method Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ARIS Method Manual

Uploaded by

Copyright:

Available Formats

ARIS

VERSION 10.0 - SERVICE RELEASE 18

2 Architecture of Integrated Information Systems (ARIS) .............................................................. 3

3 Modeling within the views and levels of the ARIS concept......................................................... 11

3.4.1.2.1 Event control - Event-driven process chain (EPC)........................ 67

4 Unified Modeling Language (UML) in ARIS .................................................................................... 121

5 Methods for knowledge management .......................................................................................... 122

5.3 Model types for modeling knowledge processing ......................................................... 126

6 Balanced Scorecard method ........................................................................................................... 130

7 E-Business scenario diagram ......................................................................................................... 149

7.4 Connection to other methods and components ........................................................... 154

8 IT City Planning .................................................................................................................................. 158

9 Business process modeling ............................................................................................................. 174

10 Modeling BPMN 2.0............................................................................................................................ 192

10.2.3 Common Elements ..................................................................................................... 196

10.4.5 Exclusive gateway ..................................................................................................... 262

11 Customer Experience Management (CXM) .................................................................................. 276

12 Use cases............................................................................................................................................ 292

13 Bibliography ....................................................................................................................................... 305

14 Legal information.............................................................................................................................. 309

2 Architecture of Integrated Information Systems (ARIS)

2.1 ARIS architecture concept

2.2 Descriptive views

Figure 1: Business process model

The components required to provide a full description of a business process include

Figure 2: Process model views

Figure 3: Views of a process model

2.3 Descriptive levels

Figure 4: Descriptions of an information system

Figure 5: ARIS concept

3 Modeling within the views and levels of the ARIS

3.1 Function view

3.1.1 Requirements definition

Figure 6: Representation of the 'Verify customer inquiry' function

3.1.1.1 Function tree

Figure 7: Function tree (extract)

Figure 8: Object-oriented function tree

A process-oriented representation is recommended for function trees that represent the

Figure 9: Process-oriented function tree

Figure 10: Execution-oriented function tree

3.1.1.2 Objective diagram

Figure 11: Objective diagram

3.1.2 Design specification - Application system type diagram

Figure 12: Graphical representation of an application system type

Figure 13: Modular structure of an application system type

Figure 14: Graphical representation of an IT function type

Figure 15: Allocation of functions to application system types

An example of possible assignments in an application system type diagram is shown in the

Figure 16: Application system type configuration

Figure 17: Screen and list assignments

3.1.3 Implementation - Application system diagram

Figure 19: Assignment of application systems to their application system types

3.2 Data view

3.2.1 Requirements definition

3.2.1.1 The ERM base model

Figure 22: Examples of entity types

Attributes are properties describing entity types.

Figure 23: Examples of attributes of the 'Customer' entity type

Figure 24: Example of a relationship type

An n:1 relationship means the same, but in reverse order.