it basics for supply networks it basics for supply networks/3 dr. withalm 17-aug-15

IT Basics for Supply NetworksIT Basics for Supply Networks

IT Basics for Supply Networks/3IT Basics for Supply Networks/3

Dr. Withalm Apr 19, 2023

IT Basics for Supply Networks19.04.23 Dr.Withalm2

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


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



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



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


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


Event Control-Event-Driven Process Chain (EPC) /5 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.


Event Control-Event-Driven Process Chain (EPC) /7 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


Event Control-Event-Driven Process Chain (EPC) /15 overview of all possible event operators:


Event Control-Event-Driven Process Chain (EPC) /16 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.


Event Control-Event-Driven Process Chain (EPC) /18 Operator for Triggering Events /1AND Operator

The function can be started only after all events have occurred.


Event Control-Event-Driven Process Chain (EPC) /19 Operator for Triggering Events /2OR Operator


Event Control-Event-Driven Process Chain (EPC) /20 Operator for Triggering Events /3XOR operator

The function is started after exactly one and only one event has occurred.


Event Control-Event-Driven Process Chain (EPC) /21 Operator for Created Events /1AND Operator

The function results in all events occurring.


Event Control-Event-Driven Process Chain (EPC) /22 Operator for Created Events /2OR Operator

Executing the function results in at least one of the events occurring.


Event Control-Event-Driven Process Chain (EPC) /23 Operator for Created Events /3XOR Operator

Executing the function results in one event at the most occurring.


Event Control-Event-Driven Process Chain (EPC) /24Linking of functions with created events /1 AND Operator of Functions with Created Events

The event occurs only after all functions have been carried out.


Event Control-Event-Driven Process Chain (EPC) /25Linking of functions with created events /2 OR Operator of Functions with Created Events

The event occurs after at least one of the functions has been carried out.


Event Control-Event-Driven Process Chain (EPC) /26Linking of functions with created events /3 XOR Operator of Functions with Created Events


Event Control-Event-Driven Process Chain (EPC) /27Linking of functions with triggering events /1 AND Operator of Functions with Triggering Events

The event triggers all functions.


Event Control-Event-Driven Process Chain (EPC) /28Linking of functions with triggering events /2 OR Operator of Functions with Triggering Events

Events have no decision-making power!

This operator is not possible!


Event Control-Event-Driven Process Chain (EPC) /29Linking of functions with triggering events /3XOR 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.


Function Allocation Diagram /2 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.


Function Allocation Diagram /10 EPC with Input/Output Data/1


Function Allocation Diagram /11 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.


Function Allocation Diagram /13 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.


Functions - Organization - Data /2eEPC/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



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.



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.



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.



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



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.


Functions - Organization - Data /9 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/2Top 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.

IT Basics for Supply NetworksIT Basics for Supply Networks

Thank youfor your attention!


Farbpalette mit Farbcodes

Primäre Flächenfarbe:

R 215G 225B 225

R 130G 160B 165

R 170G 190B 195

R 220G 225B 230

R 145G 155B 165

R 185G 195B 205

R 255G 210B 078

R 229G 025B 055

R 245G 128B 039

R 000G 133B 062

R 000G 000B 000

R 000G 084B 159

R 255G 255B 255

Sekundäre Flächenfarben:

Akzentfarben:

R 255G 221B 122

R 236G 083B 105

R 248G 160B 093

R 064G 164B 110

R 064G 064B 064

R 064G 127B 183

R 255G 232B 166

R 242G 140B 155

R 250G 191B 147

R 127G 194B 158

R 127G 127B 127

R 127G 169B 207

R 255G 244B 211

R 248G 197B 205

R 252G 223B 201

R 191G 224B 207

R 191G 191B 191

R 191G 212B 231

R 255G 250B 237

R 252G 232B 235

R 254G 242B 233

R 229G 243B 235

R 229G 229B 229

R 229G 238B 245

it basics for supply networks it basics for supply networks/3 dr. withalm 17-aug-15

Documents

cnos basics of supply

aris architecture

supply networks3

information system slide

aris simulation

process model slide

cbusinessmaps slide

saas slide