Game of Throne Book 7

IT Basics for Supply Networks/3
Dr. Withalm 25-Jan-18 IT Basics for Supply Networks

Lectures at the University of Bratislava/Autumn 2014
30.09.2014 Lecture 1 Introduction in CNO’s & Basics of Supply Networks
07.10.2014 Lecture 2 Kanban & Essential Supply Chain Processes
21.10.2014 Lecture 3 Business Processes & Semantic Web
11.11.2014 Lecture 4 SOA and SOA basing on J2EE
18.11.2014 Lecture 5 B2B & Cloud Computing including SaaS
2 25.01.2018 Dr.Withalm IT Basics for Supply Networks

Today’s Agenda
 Brief introduction of ARIS

 Connection SOA with ARIS
 Event Control – Event Driven Process Chain (EPC)
 Function Allocation Diagram
 Information Flow Diagram
 Event Diagram
 Function Organization Data
 EPC/PCD
 Semantic WEB
 Example
 Ontology
 Connection to WS

ARIS(ARchitecture of integrated Information
Systems)/1
 Main focus is modeling of business processes and their

implementation on information systems
 This architecture concept enables methods to be evaluated and
organized
 By concentrating on their focal points
 And it also serves as an orientation Framework for complex
development projects
 Because in its structuring elements
 It contains an implicit procedural model
 For the development of integrated information systems

Systems)/2
 An architecure of this kind naturally leads toward standardization in

the use of methods
 As a result existing and new modeling methods were merged
 To create a holistic method for modeling business processes
 On the basis of this architecture
 This ARIS architecture was then used as the basis for the
development of the
 ARIS toolset – a family of tools developed by IDS Scheer
 i.e. ARIS Simulation, ARIS Web Publisher, ARIS Lotus Notes
Connectivity
 ARIS toolset supports consultants and companies in
 Creating, analyzing, and evaluating company processes
 For purposes of Business Process Reengineering

Systems)/3
 Following issues are tackled (more than 2000 pages!!):

 Structure and structuring elements
 Allocation of the individual modeling methods to the
the structuring elements of the ARIS architecture.
 Implementation of UML in ARIS
 Implementation of OMT in ARIS
 Knowledge Management methods
 ARIS solutions for specific business management
problems
 ARIS BSC (Balanced Score Card) method
 eBusiness Scenario Diagram and CBusinessMaps

Systems)/4

Systems)/5

ARIS Analytical Views of the Process Model

Process Model Views

Example of a Process Chain Diagram

Descriptive Levels of an Information System

ARIS Concept

Example of a Process Chain Diagram

Representation of a Function
 A function is a technical task or activity performed on an object in

support of one or more company objectives
 Elementary functions are functions which cannot be reduced
any further for the purpose of business process analysis.
 Example:

Function Tree (Extract)

Object –oriented Function Tree

Process – oriented Function Tree

Execution - Oriented Function Tree

Mapping of an ARIS function onto a SOA service/1
(Architecture of Integrated Information systems)

Mapping of an ARIS function onto a SOA service/2
 The ARIS function which denotes a business service

 Is directly mapped onto a SOA service
 I/O data are mapped to the respective I/O data of the
service
 The operating entity is the SOA service provider
 Activating and resulting events are elements of the
service of the service consumer
 In which the service is employed

Event Control-Event-Driven Process Chain (EPC) /1
 Events such as Customer order received or Invoice produced

define the point
 at which a change in the state of information objects (data)
occurs.
 They are described in the data view of the ARIS architecture.
 The procedural sequence of functions in the sense of business
processes
 is represented in process chains.
 This means that the start and end events can be specified for each
function.
 Events are not only trigger functions, but they are results of
functions.

 By an event we understand the fact
 that an information object (data) has taken on a

business-relevant state
 which is controlling or influencing the further

procedure of the business process.
 Unlike a function, which is a time-consuming occurrence,
 an event is related to one point in time.

 The change in state of an information object
 may refer to the first occurrence of this information

object
 e.g., Customer order received
 or to a change in state in the sense of a change in

status
 that is recorded in an attribute occurrence
 e.g., Offer is refused.

 Since information objects and attributes are described in

the ARIS data view,
 the event-driven representation of process chains is a

link
 between the data view and the function view.
 Hence it is assigned to the ARIS control view.
 Events are graphically represented as hexagons.
 The description should not only contain the information

object itself (Order),
 but also its status change (received).

Events (Graphical Representation):

 Events trigger functions and are the results of functions.
 By arranging this event-to-function change in a sequence,
 so-called event-driven process chains (EPCs) are

created.
 An event-driven process chain (EPC) shows
 The chronological-logical procedure of a business

process.

Example of EPC:

 An example of an EPC is shown in above figure.
 Since events determine which state or condition will

trigger a function
 and which state will define the end of a function,
 the starting and end nodes of such an EPC are always

events.
 Several functions can originate simultaneously from one

event and conversely
 a function can have several events as its result.

 A link in the form of a circle is used to represent
 branches and processing loops in an EPC.
 These connections, however, not only serve as graphic

operators,
 but define the logical links
 between the objects they connect.


 In the first example of above Figure
 the starting events are linked by an AND operator.
 This means that the procedure Release operation
 is only started if a routing is available
 and the necessary resources have been verified.
 Therefore, both events must have occurred before the

procedure can begin.

 The second example shows an exclusive OR operator
 The Check supplier offer function may either result
 in acceptance or rejection of the quote.
 Both results, however, cannot occur at the same time.

 Besides these two cases and the "Inclusive OR" operator,
 more complex relationships are conceivable.
 In this case, a general rule can be represented in an EPC
 which will be described later in more detail in the form
of a rule diagram.

 Therefore, we can distinguish between two different types

of operators:
 Event operators
 Function operators

overview of all possible event operators:

overview of all possible function operators:

 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.

Operator for Triggering Events /1
AND Operator
The function can be started only after all events have occurred.

OR Operator
 The function will be carried out
 after at least one of the events has occurred.

XOR operator
 The function is started after exactly one and only one

event has occurred.

Operator for Created Events /1
AND Operator
 The function results in all events occurring.

OR Operator
 Executing the function results in at least one of the

events occurring.

XOR Operator
 Executing the function results in one event at the

most occurring.

Linking of functions with created events /1
AND Operator of Functions with Created Events
 The event occurs only after all functions have been

carried out.
OR Operator of Functions with Created Events
 The event occurs after at least one of the functions

has been carried out.
XOR Operator of Functions with Created Events
 The event occurs when exactly one of the functions

 has been carried out.
Linking of functions with triggering events /1
AND Operator of Functions with Triggering Events
 The event triggers all functions.

OR Operator of Functions with Triggering Events
 Events have no decision-making power!
 This operator is not possible!

XOR Operator of Functions with Triggering Events
 Events have no decision-making power!
 This operator is not possible!

Function Allocation Diagram /1
 As well as the representation of event control explained in previous

Chapter,
 the transformation of input data to output data
 and the representation of the data flows between functions
 represent 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
function allocation diagrams (I/O)
 which essentially correspond to pure input/output diagrams used in
other methods.

An example of a function allocation diagram (I/O):

 An example of a function allocation diagram (I/O) is

shown in above Figure.
 The input data of the Determine delivery date function

are
 Bill of materials data

 Parts data,
 Inventory data,
 and Shipping data.
 Inquiry data serve as input data as well as output data.

 Function allocation diagrams (I/O) thus contain functions

of the function view
 And information objects of the data view.
 The arrows determine whether an information object is

only used as
 input data
 output data
 or as input/output data.

 More detailed specifications are also possible,
 indicating for example that the function has created or deleted an

information object.
 Depending on the degree of detail,
 the information objects can either be data clusters (see above

Figure) entity or relationship types
 or even attributes of the data view.

 The example shown above clarifies the actual objective of

function allocation diagrams (I/O)
 which is to represent a function's input/output data.
 Besides including a function's input/output data and events,
 all other objects which can be allocated to individual

functions in an eEPC (Functions with Organization ) are
available.

 The user is thus able to restrict the modeling of process

chains in eEPC diagrams
 to events and functions, and to assign each function a
function allocation diagram (I/O)
 with all additional relationships for the function.
 This enables business processes to be illustrated much
more clearly
 and also explains the use of a new name for this model
type.


 An example of this more detailed representation in a function

allocation diagram (I/O) is shown in above Figure.
 In addition to the separate representation of data transformation

as function allocation diagrams (I/O),
 this information can also be included in an EPC.

EPC with Input/Output Data/1

EPC with Input/Output Data/2
 Here, the significance of the operators between functions

and information objects
 is the same as for those within the function allocation

diagrams (I/O).
 If they are included in a process chain
 with numerous branches, however, a rather confusing

representation may result.

 In the PCD (Process Chain Diagram) objects have to be arranged
 according to the column description.
 The EPC representation permits a free arrangement of objects.
 However, adding input/output data may result in confusing models.
 Therefore we recommend a PCD representation


 especially for business processes
 executed in sequence.

PCD with Input/Output Data

 The above figure shows the EPC with input/output data of

the previous Figure
 as a PCD (Process Chain Diagram)

Information Flow Diagrams /1
 Information flow diagrams are suitable for illustrating
 the flow of data between functions as mentioned

earlier.
 For this purpose two functions can be interlinked
 By a data flow object in an information flow diagram.
 This object expresses that there is a data flow
 from the source function to the target function.

 In order to specify the data objects more precisely
 flowing between the displayed functions
 can be set in a hierarchy
 which, in turn, allows assigning a data model to
that object.


 This data model represents the information objects
 which are exchanged between the functions.
 Depending on the degree of detail of the examined functions,
 the information objects can be data clusters, entity types or

ERM (Entity-Relationship Model) attributes.
 An example of this type of representation is shown in above Figure

Event Diagram /1
 Events define the fact that the status of information
objects has changed.
 Thus, every event is a reference to particular information
objects of the data model
 and defines the status of this information object
 at a given point in time.

Event Diagram /2
 First of all, events are roughly specified in a top-down

procedure
 example: Customer order has been processed.
 The next level of the process modeling level involves
 specification of the events in more detail.
 If they are combined in a certain way,
 the events occur on the roughly defined level.

Event Diagram /3
 For example, the total of the following events that have

occurred:
 Feasibility checked
 Order header registered
 Order line items registered
 and Feasibility checked
 could define the Customer order status.

Event Diagram /4
 You can display these event correlations on the rough and

detailed modeling levels
 using the event diagram.
 For this purpose, you can assign an event diagram to an
event
 on the rough level (hierarchy!),
 which would, in turn, display the events and the
operators between them on the detailed level
 by means of rule operators as well.

Event Diagram /5
 Moreover, you can even 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 status change of a given information

object.

Example of an Objective Diagram:

Functions - Organization - Data /1
eEPC/PCD/1
 The same facts are represented in eEPCs and in PCDs
 Up to this point we have been dealing with just two views;
 now a third view is introduced.
 This means that the process chain's partial views are

again combined
 to form an overall view and that the interactions of all

components of the ARIS architecture can be
examined.

eEPC/PCD/2
 The process chain we originally started out with is again

shown in detail.
 However, this examination does not focus on the details
 extracted in the individual views for the objects

examined,
 but on the operators between these objects

eEPC/PCD/3

eEPC/PCD/4
 Above Figure shows a process chain with all views of a

process chain.
 Events representing data view objects have been placed

in the first column.
 The arrows lead to the process column
 where the process chain's functions are listed.

eEPC/PCD/5
 Thus, the first and second columns define the event

control.
 The data objects are located in the third column
 where their relations to the individual functions are

displayed.

eEPC/PCD/6
 The view of the second and third column of the PCD
 thus defines the data flow of the process chain.
 Unlike the PCD
 the process chain diagram of the requirements

definition has no columns for the definition of the
processing type and the IT system.

eEPC/PCD/7
 The requirements definition therefore

has to describe the business application
 which is to be supported in a formalized
description language so that it can be
used
 as the starting point for a coherent
translation into information technology.
 This process is also referred to as
(semantic) modeling.
 The requirements definition is very
closely associated with the operational
business problem, as is indicated by the
width of the arrow in figure

eEPC/PCD/8
 These facts are needed to capture the actual situation in a

company,
 but nevertheless they are not part of the subject-

related description of a business process.
 The organizational units of the organization view
 which are responsible for executing the individual

functions of the process chain
 are defined in the fourth column.

eEPC with Functions, Data, Organizational Units and Events:
 The process chain

illustrated in previous
Figure
 can also be expressed
as an EPC
 see following
Figure.

Semantic Web
 Semantics: Meaning of a word, a sentence or a text

 The existing web consists of data,
 which is readable for machines
 which should – in the future – be made understandable and
interpretable for machines

Motivation for Semantic WEB/1
 Task: Find and buy specific audio CD on the web

 At present:
 "clicking" from one web-shop to the next
 performing the same search on each site
 comparing the prices
 A SW-agent is currently unable to find CD-retailers on the web
 If it has a list of retailers, there is another problem:
 How shall it search the site for relevant offers?

 Problems of the search request:

 Over HTTP and URL, but how exactly?
 Is there a search-function implemented in the site?
 If yes, with which URI should the request be placed?
 What are the parameter names?
 HTTP-transmission over GET- or POST-method?

 Problems with the received answer:

 Humans see the web-page as more or less beautifully designed
 It contains the price of the CD, but where?
 The SW-agent is unable to find it out
 If it would be programmed to find it in line 3, column 5?
 What happens if the layout is changed?

Solutions/1
 Parts of the HTML-code could be made interpretable for the agent with
the help of XML
 If tags like <price> ... </price> were added to the HTML elements, the
agent could recognize the requested data
 W3C recommends the XML-schemata for establishing the required
vocabulary

Solutions/2
 Another problem arises if the simple example is translated into

another language, resulting in tags like <preis>....</preis> (German)
or <prix>....</prix> (French)
 in this case, another element-type name is used to express the
same term

Solutions/3
 But do they really have the same meaning?

 Do <price>20</price> and <preis>20</preis> have exactly the
same significance?
 Obviously the currency is not defined!
 Does the price include taxes? (USA!)
 Fluctuations of exchange rates:
 Are 20 US$ at the time when the product is ordered the same
as when the invoice is issued?

Solutions/4
 price and preis are closely related

 In the W3C scenario, the nature of this relationship is explained by:
 RDF (Resource Description Framework) is the basis for expressing
information about all things that can be addressed by a URI Basis
 OWL (Ontology Web Language) provides a notation for ontology
 An ontology is the description of terms and their interrelations
within a domain (a context-sensitive vocabulary)

Semantic Web Example/1
Listing 1: Wine Ontolgy
<owl: Class rdf: ID=“Wine”/>

<owl: Class rdf: ID=“RedWine”>
<rdf:subClassOf rdf:resource=“#Wine”/>
</owl>
<owl: Class rdf: ID=“Chianti”>
<rdf:subClassOf rdf:resource=“#RedWine”/>
</owl>

 This is a section of an ontology that classifies wines

 If it is predefined, the SW-agent’s job becomes easier...
 ...e.g. if it is given the task of finding offers from wine
merchants for:
 red wine
 vintage 1995

Listing 2: Merchant Data

<Wine Merchant>
<Merchant>
<Phone href=“tel:+49401234”>040 / 1234</Phone>
<Office Hours>Mo – Fr 10am -4pm/Office Hours>
</Merchant>
<Store>
<Italy>
<Chianti>
<Wine Growing Estate>......< Wine Growing Estate />
<Year>2007</Year>
<Price per Bottle>20< Price per Bottle/>
<Availability> 25 Boxes <Availability/>
<Chianti/>
<Italy/>
<France>
...................
<France/>
...................
<Store/>
<Wine Merchant/>

 This document contains neither the term "red wine" or "vintage"

 but with its ontology knowledge, the agent conceives that Chianti is a
red wine
 if the ontology defines that in the wine-domain "year" and "vintage"
have the same meaning, the problem is solved
 Furthermore, the data type is defined:
 Type integer according to the XML-scheme

Listing 3: Same Meaning
<owl:DatatypeProperty rdf:ID=“Vintage”>
<owl:equivalentProperty rdf:resource=“#Year”/>
<rdf:domain rdf:resource=“#Wine”/>
<rdf:range rdf:resource=&xsd,#integer”/>
</owl:DatatypeProperty>

Semantic WEB
 The Semantic Web is a vision for the future of the Web

 in which information is given explicit meaning
 making it easier for machines to automatically process and integrate
information available on the Web.
 The Semantic Web will build on XML's ability
 to define customised tagging schemes
 and RDF's flexible approach to representing data.
 The next element required for the Semantic Web is a web ontology language
 which can formally describe the semantics of classes and properties used in
web documents.
 In order to machines perform useful reasoning tasks on these documents
 the language must go beyond the basic semantics of RDF Schema.
 OWL has been designed to meet this need for a Web Ontology Language.

Semantic WEB: Summary/2
 A further step is to:

 develop useful tools such as the wine agent
 so that content providers will provide the required meta-data
as a supplement to HTML

Semantic Web Layers
[Tim Berners-Lee]

Ontology/1
 hierarchical structure of terms

 which are brought into relationship through pre-defined
associations
 the definition of sub-classes is the most common way of
establishing a hierarchy
 specialisation of the terms
 every term can be structured further by attributes

Ontology/2
 ontology focus on connecting terms in order to allow statements

 for example:
 the residential address of Person Smith is identical with the working
address of person Smith
 the household at the residential address consists of only one
address
 therefore we conclude that Person Smith runs a small company

Ontology/3
 further partial ontology can be derived:

 residential address is a sub-class of address
 working address is a sub-class of address
 household is the entirety of persons with identical residential
address
 small company is a sub-class of company

Ontology/4
 Ontology is the attempt to formulate an exhaustive and rigorous

conceptual schema
 within a given domain, typically a hierarchical data structure
 containing all the relevant entities and their relationships and
rules (theorems, regulations) within that domain.
 For example: in the automotive industry Bill of Material
 To be useful, ontology must be expressed in a concrete notation.
 An ontology language is a formal language by which an ontology is
built.
 There have been a number of data languages for ontology
 both proprietary and standards-based:
 CycL (ontology language based on first-order logic)
 KIF (syntax for first order logic)
 OWL, a language compatible with the architecture of the World
Wide Web in general, and the Semantic Web in particular.
Ontology Interoperability
 Ontology, as the means for conceptualising and structuring domain

knowledge
 has become the backbone to enable the fulfilment of the
Semantic Web vision.
 It aims to make data more sharable.
 However, ontology themselves can be heterogeneous.
 Mapping between different ontology thus becomes essential to
ontology interoperability.
 Ontology mapping is the task of finding semantic relationships
between entities of two ontology.
 i.e. concept, attribute, and relation.

Heterogeneity of Ontology/1
 In order to reach interoperability over heterogeneous ontology,

two problems must be dealt with,
 i.e.: metadata heterogeneity and instance heterogeneity .
 Metadata heterogeneity concerns the intended meaning of
described information. There are two kinds of conflicts in
metadata heterogeneity:
 structure conflict, which means that ontology for same domain
knowledge may have different semantic structures; and
 name conflict, which means that the same concept may use
different names or different concepts may use the same
name.

Heterogeneity of Ontology/2
 Instance heterogeneity concerns the different representations of

instances.
 Information described by the same ontology can be represented
in different ways, also called representation conflict.
 For example,
 date can be represented as “2004/2/27” or “Feb, 27,
2004”;
 person name can be represented as “Jackson Michael”
and “Michael, Jackson”, etc.
 Representation conflict requires normalisation before ontology
interoperation.

Different solutions for Ontology Interoperability/4
 Following a summary of the main approaches to ontology

Interoperability
 Ontology mapping/matching.
 Ontology alignment.
 Ontology translation.
 Ontology transformation.
 Ontology merging/integrating.
 Ontology checking.
 Ontology evolution/ versioning.

WS Language Descriptions/1
 The Semantic Web should enable greater access not only

to content but also to services on the Web.
 Users and software agents should be able
 to discover, invoke, compose, and monitor Web
resources
 offering particular services and having particular
properties,
 and should be able to do so with a high degree of
automation when desired.
 To make use of a Web service,
 a software agent needs a computer-interpretable
description of the service
 and the means by which it is accessed.

WS Language Descriptions/2
 An important goal for Semantic Web markup languages

 is to establish a framework within which these descriptions are
made and shared.
 Web sites should be able to employ a standard ontology
 consisting of a set of basic classes and properties
 for declaring and describing services
 and the ontology structuring mechanisms of OWL
 provide an appropriate and Web-compatible
representation language framework within which to do
this.

OWL-S/2
Top Level of the Service Ontology

OWL-S/3
 OWL-S has three main parts:

 What does the service provide for prospective clients?
The answer to this question is given in the “profile”
(ServiceProfile class), which is used to advertise the
service.
 How is it used? The answer to this question is given in
the “process model”. This perspective is captured by
the ServiceModel class.
 How does one interact with it? The answer to this
question is given in the “grounding”. A grounding
(ServiceGrounding class) provides the needed details
about transport protocols.

Thank you
for your attention!
IT Basics for Supply Networks

Farbpalette mit Farbcodes
Primäre Flächenfarbe: Akzentfarben:

R 255 R 255 R 245 R 229 R 000 R 000 R 000
G 255 G 210 G 128 G 025 G 133 G 084 G 000
B 255 B 078 B 039 B 055 B 062 B 159 B 000
R 255 R 248 R 236 R 064 R 064 R 064

G 221 G 160 G 083 G 164 G 127 G 064
Sekundäre Flächenfarben: B 122 B 093 B 105 B 110 B 183 B 064
R 215 R 170 R 130 R 255 R 250 R 242 R 127 R 127 R 127

G 225 G 190 G 160 G 232 G 191 G 140 G 194 G 169 G 127
B 225 B 195 B 165 B 166 B 147 B 155 B 158 B 207 B 127
R 220 R 185 R 145 R 255 R 252 R 248 R 191 R 191 R 191

G 225 G 195 G 155 G 244 G 223 G 197 G 224 G 212 G 191
B 230 B 205 B 165 B 211 B 201 B 205 B 207 B 231 B 191
R 255 R 254 R 252 R 229 R 229 R 229

G 250 G 242 G 232 G 243 G 238 G 229
B 237 B 233 B 235 B 235 B 245 B 229

Game of Throne Book 7

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Game of Throne Book 7

Enviado por

Direitos autorais:

Formatos disponíveis

IT Basics for Supply Networks/3

Dr. Withalm 25-Jan-18 IT Basics for Supply Networks

30.09.2014 Lecture 1 Introduction in CNO’s & Basics of Supply Networks

07.10.2014 Lecture 2 Kanban & Essential Supply Chain Processes

21.10.2014 Lecture 3 Business Processes & Semantic Web

11.11.2014 Lecture 4 SOA and SOA basing on J2EE

18.11.2014 Lecture 5 B2B & Cloud Computing including SaaS

2 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Brief introduction of ARIS

3 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Main focus is modeling of business processes and their

4 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 An architecure of this kind naturally leads toward standardization in

5 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Following issues are tackled (more than 2000 pages!!):

6 25.01.2018 Dr.Withalm IT Basics for Supply Networks

7 25.01.2018 Dr.Withalm IT Basics for Supply Networks

8 25.01.2018 Dr.Withalm IT Basics for Supply Networks

9 25.01.2018 Dr.Withalm IT Basics for Supply Networks

10 25.01.2018 Dr.Withalm IT Basics for Supply Networks

11 25.01.2018 Dr.Withalm IT Basics for Supply Networks

12 25.01.2018 Dr.Withalm IT Basics for Supply Networks

13 25.01.2018 Dr.Withalm IT Basics for Supply Networks

14 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 A function is a technical task or activity performed on an object in

15 25.01.2018 Dr.Withalm IT Basics for Supply Networks

16 25.01.2018 Dr.Withalm IT Basics for Supply Networks

17 25.01.2018 Dr.Withalm IT Basics for Supply Networks

18 25.01.2018 Dr.Withalm IT Basics for Supply Networks

19 25.01.2018 Dr.Withalm IT Basics for Supply Networks

20 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 The ARIS function which denotes a business service

21 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Events such as Customer order received or Invoice produced

22 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 By an event we understand the fact

 that an information object (data) has taken on a

 which is controlling or influencing the further

 Unlike a function, which is a time-consuming occurrence,

 an event is related to one point in time.

23 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 The change in state of an information object

 may refer to the first occurrence of this information

 e.g., Customer order received

 or to a change in state in the sense of a change in

 that is recorded in an attribute occurrence

 e.g., Offer is refused.

24 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Since information objects and attributes are described in

 the event-driven representation of process chains is a

 between the data view and the function view.

 Hence it is assigned to the ARIS control view.

 Events are graphically represented as hexagons.

 The description should not only contain the information

 but also its status change (received).

26 25.01.2018 Dr.Withalm IT Basics for Supply Networks

 Events trigger functions and are the results of functions.

 By arranging this event-to-function change in a sequence,

 so-called event-driven process chains (EPCs) are

 An event-driven process chain (EPC) shows

 The chronological-logical procedure of a business

27 25.01.2018 Dr.Withalm IT Basics for Supply Networks

28 25.01.2018 Dr.Withalm IT Basics for Supply Networks