Business Information Systems II

What challenges do companies face today?

- Market transparency, increased competition, shorter product lifecycles
- Growing requirements on time, quality, costs and flexibility
- Increasing effectiveness (are we doing the right things) and efficiency (are we doing
the things right) is necessary
- Processes which are not fully controlled jeopardize effectiveness and efficiency

What is a model?
= a simplified, goal-oriented reproduction/illustration of a real world object created with a
modelling language → There is no such thing as “universal model”!

What is modelling?
- Activities, that transfer a system into a model → system = Something that includes a lot
of elements, e.g. Information Systems where a lot of elements interrelate with one
another
- “Artificial language” with well-defined syntax and semantics
- Problem independent
- Understandable for people from different departments
- Syntax = form and characters of a language without considering the notion →
aim: reduce explanation efforts
- Semantic = agrees on common meaning for symbols and expressions
- Aim of modelling: simplification, documentation of systems → visual representation helps
in easier understanding
- Reduce complexity
- Reduce space for interpretation
- Reduce misunderstandings
- General understanding of the system

How to model?
1. System boundaries (mini world): What will be described?; Clearly defined; Part of the
real world
2. Select essential elements: Meaningful elements; Take interactions into account!
3. Label elements: Conventions; Consistent naming
Basics of proper modelling
Correctness •Syntax rules Clarity •Group of processes
•Semantic correctness •Visualization
•Terminology •Labelling

Relevance •Process structures Comparability •Syntax-semantic relation

•Organization & information systems conventions
•Process instances •Naming conventions

Economic •Process model details Systematic design •View integration

efficiency •Building blocks •Level integration
•Time and resource restrictions •Clear relation
Modelling Principles
1. Abstraction: different degrees of detail
- Generalization → Opposite would be concretization
- Restriction on essential system components
2. Partitioning: divide into smaller subsystems
- Decomposition
- Split an entire system into meaningful and manageable subsystems (recursive)
3. Projection: different views
- Consideration of different perspectives
- Views of models from different points of view
- Check whether abstraction and partition were conducted consistently
- Documentation of different information

Business Processes in the focus of modelling

What is a business process?

= a collection of inter-related events, activities and decision points that involve a number of
actors and objects, and that collectively lead to an outcome that is of value to at least one
customer.
- Functions (or activities) of a business process:
- Have a temporal logical connection,
- Are performed by various actors,
- Help to achieve goals, and
- Use information and data sources
- To create a product or service
SUMMARY
Modelling produces a realistic presentation of the real world.
Modelling language defines syntax and semantics.
Generally accepted modelling principles have to be used.
ARIS - HOUSE OF BUSINESS ENGINEERING
- Uses different modeling languages, e.g.
- Organization chart - eEPC (extended event-driven process chains
- eERM (extended Entity-Relationship Model), Technical Term Model
 - Function tree - Product tree
- The ‘concept’ and the ‘software’ can be used independently of each other!
- The ARIS concept describes a complete enterprise or parts of it
- using several graphical models,
- inspecting business processes (core processes and support processes).
- Projections = in ARIS known as Views
- Complexity reduction by using different Layers
- Requirements definition
- Design specifications
- Implementation

ARIS views:
- Each process (process or control view) → How is it done?
- is performed by an actor (organizational view), → Who does it?
- requires or generates data (data view), → Which information is needed?
- is composed by several actions (function view) and → What is done?
- has some kind of output (product/service view). → Why is it done?
ARIS layers
- Requirement definition: structured representation of a process by means of
conceptual descriptive models (e.g. ERP, EPC, organizational chart, function
tree) → Systematic description and documentation of a problem
- Design specification: Implementation of the concept in IT-related descriptive
models (relational databases, structure charts, UML language, …)
- Implementation: The design specification is transferred to concrete hardware
and software components, where the link
to IT is established (program code,
database systems, protocols).

Organizational view
- Provides an overview of organizational structure of
company (Organizational unit, position, person,
 location) → Describes structure and process of a company
- The structure is part of the “Structural Organization”
- Organizations are complex entities → Split into manageable units
- Determine who is responsible for a certain task → Organizational chart
- The structural organization is associated with the organizational view
- Structuring dependent on current objectives & general regulations (frame
conditions)
- Functional classification
- Advantage: high degree of specialization
- Disadvantage: a lot of effort for communication and coordination

- Divisional classification
- structured according to regions / areas / products / customers etc.
- Processes are part of the “Operational Organization”
- Determine how a certain task should be performed → EPC
- The operational organization is associated with the control view
- Organizational chart
- Diagram used for illustrating the organizational structure
- It contains the following symbols: Organizational unit, Position, Person, Location
Function view
- Provides overview of the activities of a company
- Functions can be assigned to an organizational unit
- Functions are decomposed into hierarchical structure (“trees”)
- A better understanding is created through partitioning functions in sub-functions
- Function = a task that must be carried out to support one or more company objectives
- Subfunctions
- Derived from complex functions,
- Can be part of several hierarchical levels
- Often, terms such as “Procedure”, “Process”, “Sub-function” or “Elementary
function” are used to clarify the different decomposed levels
- Elementary function
- Are functions that cannot be further decomposed
- In complete function trees, the elementary functions are represented in the
lowest level
- For representing decomposition of functions, ARIS offers the diagram type „Function
tree“.
- Limited to a static, functional view.
- Symbol (Object types):
→ The diagram type Function tree uses only the one symbol (object type) „Function“.
- Different criteria for decomposing functions:
- Decomposition based on process membership (process-oriented)
- Processing of the same object (object-oriented)
 - Process aggregation based on the same tasks/services (task-oriented)

- Particularly important function characteristics/attributes for business processes are:

- processing type (manually vs. IT-supported)
- quantity structure (how often per unit of time)
- average duration
- average training period
- average processing time
- average waiting time
- Goal diagram
- At the beginning of each modelling, analysis or optimization task, the following
facts should be clarified:
- What does the company aim for? → contributes to a better
understanding and avoids confusion
- What are the objectives of the modelling analysis or optimization?
- has significant impact on clarifying the expectations of the client
for the other party
- identifies conflicts about content and scope already at the
beginning, hence, can prevent them from happening
- Characteristic of a goal include
- a content description
- a measurand / parameter (an object being measured)
- a value for the measurand (an indica
- A goal should be Specific, Measurable, Accepted, Realistic, Timely
- Finance, Customer, Potential & Process goals
- Symbols: Goal, Function, Success factor
- Possible relationships:
- A goal belongs to a another goal.
- The goal achievement is supported by carrying out one or more functions.
- The goal achievement is supported by success factors.
- The goal achievement is supported by performing one or more services.

Data view
- In business processes, we access data, and we produce data. Data requirements are
modelled in the data view → ERM - Entity Relationship Model
- Key Elements in the data view: Entity types, Relationship types, Attribute types
- Sources for data analysis: Forms, surveys, documents, records of data
- Database systems
- Enable large IT applications
- Support the operational organization and management
- Are key technologies for efficient and complex information systems
- Are prerequisites for multimedia online content management
- have become an integral part of daily work and life
- Operational purpose of creating database systems:
- Supporting a high number of users
- Covering complex operational processes
- Managing large volumes of data
- Attention: Often related to high investment and operating costs!
- Role of data modelling: Planning of database systems and reduction of costs!
- Consist of
- one or more databases (DBs),
- one data dictionary (DD)
- and one database management system (DBMS)‫‏‬

- ANSI-SPARC 3-tier architecture

…is a framework that covers planning, creation, and operation of database systems and
the associated applications.
- External tier (ex.: forms, mask, layout, lists, interfaces)
- Conceptual tier (data modelling takes place): comprehensive and
redundancy-free modelling of the entire relevant information objects and their
relationships.
- Internal tier: physical view of the database in the computer → How and where is
the data saved?
- Entity relationship Model (ER model)
- Used to design the conceptual tier → a conceptual, technical neutral data model
- is the most used data model
- Simple graphical notation → easy to follow
- A relational database schema and/or a class diagram can be derived from the ER
model by widely automated rules → relational resolution
- Basis for most commercial applications
- Object-oriented software development represents the state-of-the-art technology
- Type = Instances with the same characteristics
- Entities
- The world to be modelled consists of clearly definable and identifiable
instances of things
 - Entity type
- Generalized description of entities with the same attributes e.g.
lecturer, employer, article, etc.
- Most often formulated as singular nouns
- Sub and super types … enable the subdivision of entity types in
subtypes → Entity type employee (super type) can be divided into
salesman, technician, manager, programmer (sub types)
- Inheritance of super type to sub types
- All sub types inherit the attributes of the super type.
- Entities of the sub type take part in all relation types
of the super type.
- Criteria for modelling the sub / super type hierarchies
- Entities of the sub types can have additional
attributes compared to the super type.
- Entities of the sub types, regardless of the super
types, can take part in additional relationships.
- Relationships
- Entities are related to each other/ there is an association (or relationship)
between two or more entities
- Relationship type
- Generalized description of connection between one or more
entities, e.g. employee works in a company
- Most often formulated as verbs
- connects entity types and can be described in the following way:
- Level: determine the number of entity types, which are
related through relationship types with each other
- Cardinality: determine the number of entity instances from
an entity type, which are connected through relationship
types with entity instances from another entity type
- 1:1 cardinality → 1 student receives 1 discount
- 1:n cardinality → 1 coach trains n players
- N:m cardinality → n doctors treat m patients
- Notation
- Participation condition (Chen notation) is
represented by double connection line between
entity type and relationship type: Every employee
has to be associated via the relationship “works in”
to a department of the company
- (min, max) notation
- Type vs instances
- Relationship type: car driver owns motor vehicle
 - Relationship instances: Paul Gruber owns a VW-Passat with
registration certificate W123456 AB
- Degree of relationship types
- Binary relationship type (degree 2)
- Ternary relationship type (degree 3)
- Polyvalent relationship types (degree > 2) are in practice of less
importance and will normally be replaced by additional entity types
and/or relationship types:
- Attribute
- describes the characteristic of an entity or a relationship e.g. eye colour,
matriculation number, address
- Attribute type:
- Generalized description of characteristics of interest, specifies the
data type of the attribute e.g. birthday defined as valid calendar
data (30.02 doesn’t exist)
- Most often formulated as singular nouns
- Type vs instances:
- Attribute type: determines the “type” and “range” e.g. text,
number, date
- Attribute value: actual value e.g. max, 386, 15th Feb 2017
- Symbols:
- Key attribute (or “identifying attribute”)
- are attributes or combination of attributes to clearly
identify entities.
- Primary key
- The main task of a key attribute is to clearly
define instances.
- The attribute value has to be unique for all
instances of an entity type.
- In most cases artificial value (surrogate)
- e.g. social security number, matriculation
number, receipt number
- Secondary key → all other keys
- Foreign key attribute (are not used in ERM)
- are attributes or combination of attributes to create
relations between content related entities.
- A foreign key
- serves to implement an illustrated ER
relationship in a relational model
- contains the characteristic(s) of a primary
key from a reference entity type
 - is rarely given credits in ER models
because the necessary columns are
generated automatically from the
relationship types
- is not used in ERM models !!!
- Descriptive attribute type
- are not further dividable and serve to describe the
characteristics of entities and relations.
- Are not primary keys → cannot uniquely identify
entities or relations
- Are not foreign keys → can not establish relations
between entities
- Composed attribute type (attribute type group)
- are composed of more attributes and serve to
describe the characteristics of entities and
relations.
- Are not primary keys
- Are not foreign keys
- Multivalent attributes
- are further dividable or composed, and possess
more than one characteristic for one entity or
relation.
- Multivalent attributes are illustrated by an entity
type, which is existentially independent of the
original entity type.
- Chen notation weaknesses
- Relationship type possesses only one formulation → creates quality
assurance problems
- Display attributes leads to complex diagrams in complex systems
- ERM - Relation schema
- Mapping/transition from an ER model to a table/relations
- There is one method for the mapping
- Step by step instructions
- Important: A correct relational database mapping demands the correct
modelling of the system as an ERM (Entity Relationship Model)!
- For each Entity type
- an (entity) table is defined
- Elements of the table are (n-) tuples
- The table receives all attributes of the entity types
- Primary key in the table
- corresponds to the key attribute of the entity type
- Each Relationship
 - can basically be resolved with an explicit “relationship table”
- However, it is recommended to use a different method depending on the
cardinality type
- 1:1
- 1:n
- n:m
- Explicit „relationship types into relation schema“ is necessary in
- binary m:n - relationships
- and in higher degree relationships
- Attributes of the relationship become attributes in the relation schema.
- The primary key of the resulting relationship consists of the key attributes
of all members of the relationship
- Binary 1:n relationships
- By using appropriate foreign keys an explicit relation schema is not
necessary.
- Foreign keys:
- point to the primary key of the related other relation.
- The foreign key is inserted into the n-side of the relationship.
- The foreign key corresponds to the key attribute of the other entity.
- Binary 1:1 relationships
- Same procedure as in the 1:n case
- With the exception that
- The foreign key can be inserted in both sides of the relation.
- i.e. in 1:1 relationships the side can be freely chosen.

- Technical term model

- Technical terms describe examined information objects in a company → can be
set up in a hierarchical relationship.
- Technical term model enables
- administration of different technical terms in terms of handling synonyms
- simple documentation of relationship
- linking technical terms with structured objects in data models (entity types
and relation types).
 - Symbols of technical term model: technical term → can be used in any diagram
(where information objects are illustrated)
Control/Process view
- Serves as a link to all other views
- Modelling of the dynamic behaviour of the business process (EPC - Event Driven
Process Chain, Value-added chain diagram)
- Modelling the relationship between the views
- Functions and organization
- Functions and data
- Data and organization
- Value-added chain diagram
- The value chain specifies the value-added functions that are directly involved in
adding value to the company.
- These functions are linked to each other in a sequence, thus they form a value
chain
- The value-added chain diagram throws light on :
- The sequence of constructive functions
- The higher and lower level functions
- Symbols:
- Value-added chains (functions)
- Goal
- Organizational unit
- Process Landscape
- Abstract overview of all processes in an organization
- Can be used to structure the process portfolio of a company
- Categorization

Management Determine how company is run, e.g. the periodic process to assess the
processes strength of

Core processes Cover the essential value creation of a company, that is the production of
(primary BP) goods and services for which customers pay,
Have a direct impact on customers.
Differentiation from competitors, Unique selling proposition.

Support Enable the execution of core processes.

processes Indirectly impact customers.

- Creating a process landscape

- Select “Value-added chain diagram”
- Division of processes in swim lanes for different process types
- It can be very abstract, not too many details
 - No chronological sequence
- Event-driven process chain

Process Function

consists of a set of interrelated activities Represents one activity in a process that cannot be
(functions) that are carried out in a specific order further decomposed,
in order to achieve a given (specific) target. represents one logical step within one process.
The activities can be started and performed It can further contain one process (the concept of
sequentially and/or in parallel. abstraction).

- Elements of EPC:
- Events
- Trigger functions
- Are the results of functions
- Always represent an instant in time (time-dependent state)
- Describe fulfilled conditions of information objects (process maps)
- Control or influence the flow of business processes
- Are pre- and post-conditions of functions
- Indicate what ‘follows’ if taken into account when making decisions
- Could be results from functions
- Examples: “Order accepted” “Registration confirmed”
- Functions
- Activities take place in functions
- Functions expire (have a certain period)
- Functions trigger events after they are finished
- Are operational tasks or activities on an (information) object that
support one or more company objectives
- Are carriers of ‘time’ and ‘costs’
- Are triggered by events
- Result in events
- Examples: “Edit order” “Open door”
- Logical operators:
- Logical relationship between functions and events
- One event can trigger (activate) several functions or
- One or several functions must occur in order for an event to be
activated
- Operator chains are possible.
- Split operators
- have one incoming and several outgoing control flow
edges
- transmit active process maps to subsequent control flow
objects, as follows:
 - Join operators
- have several incoming and one outgoing control flow edge
- transmit active process maps to subsequent control flow
objects if there are no further incoming process maps and
the following conditions are met:

Semantic Split Join

Are describing a point where paths are To every Received from

AND beings branched parallel. All the paths subsequent every directly
are parallel performed. The AND control flow preceded control
operator merger is synchronizing the object flow objects one
paths and transfers the completed process map
paths to the control

are describing a decision point. The to one received from one

XOR conditions are specified by the subsequent directly preceded
subsequent events. These conditions control flow control flow object
should be mutually exclusive so that object one process
only one alternative will be followed.
Finally the XOR operator merge
merges the branch.

are describing a decision point where to a chosen received from a

OR one or more alternatives can be subsequent subset of control
chosen. The OR operator merge control flow flow objects one
synchronizes the selected paths and objects process map
switches over automatically.
- Control flows
- are directional and provide the sequence
- illustrate the functional and chronological
- dependencies of functions
- Process interfaces (object type function)
- Are describing links to sub processes
- eEPCs are supplemented with
- Organizational units
- Used data, generated data
- Executive, support systems
- By necessity also other object types from the ARIS modelling pool
- Rules:
- EPC always starts with an event and an EPC always ends with an event
(or multiple events).
- Functions and Events are not allowed to have more than one incoming
and outgoing edge.
 - Events and functions are alternating. - Multiple functions can follow each
event or multiple events can follow each function, BUT there must be
rules between them.
- Before XOR- and OR-operators there should always be a function, which
triggers events. The other operators can be randomly included between
events and functions.
- A branch from a certain type should
always be again put together with
the matching operator type.
- Permitted connector combinations
- Possible Sequence:
- One function - several events
- one function
- One event - several functions - one event

- If the operator is positioned after an event and leads to two functions then
ONLY the AND-operator is allowed

Product/Service view
- Provides an overview of the entire product/service portfolio (Material outputs,
Nonmaterial or intangible outputs, Cash flows)