1. The document discusses integrated process modeling using various modeling methods in ARIS including event-driven process chains (EPCs), value chain diagrams, organizational frameworks, and function trees. 2. It provides an overview of modeling conventions for different views including organizational, data, functional, and process views as well as different levels including requirements definition, design specification, and implementation. 3. Examples are given of how to model an order acceptance process using an enhanced EPC diagram combining different views and modeling notations such as organizational devices, functions, events, and data objects.

1. Integrated ProcessModelling

2. GoalsComplexityof Information Systems EngineeringViews of Information Systems EngineeringLevels of Information Systems EngineeringSCHEER‘S ARIS Model

3. ExampleforcomplexityAn Information System supportingthe order acceptanceofyourbusinessshallbeintroduced.Describethe relevant issuesconcerningtherealizationof a systemwithaccordingrepresentationfunctions.

4. Need for an architecture- as an orientationalandstructuralframework- as a process model- for a unifieddeploymentofmethodsProblem ofcomplexityCorporate environment constitutes need for a flexible and transparent corporate structureThere is a problem of complexity due tothe size of the (corporate) reality partitionthe multiplicity of elements to be considered(data, functions, resources, ...)the multiplicity of available modelling methods

5. ViewsOrganizationalviewWhattypesoforganizationaldevicesexist? (e. g. purchase, distribution, accountancy)Data viewWhattypesofinformationare relevant? (e. g. customers, suppliers, article, listofmaterials)FunctionalviewWhattypesoffunctionsaretobeexecuted? (e. g. createenquiries, verifyaccounts)ControlviewCoherencyofdata, functionsandorganizationaldevices

6. Waterfall Model of Software Engineering

7. Operational realityprofessional languagesemi-formal descriptionmethods

8. Assignment to concrete IT componentsImplementationconceptDescription levelsRequirements Definition-1- organizationalview(“whodoeswhat in which order”) -2- detaileddescriptionoftasksModel-like mapping of the operational reality in consideration of a formalized description method

9. Inclusion of IT specificsDesign specificationInformationtechnology

10. Description levelsA requirements definition is necessaryto document experiencesbecause business knowledge changes slowlyto „sort“ new requirements correctlybecause otherwise problems will be solved in an unstructured way, and insular solutions are developedto keep the focus

11. Description levelsA design specification is necessarybecause models cannot be transscripted directly into program codeto undertake refinementsbecause the requirements definition cannot cover everythingto assure that changes of technology respectively implementation cannot affect the requirements definition directlythe design specification works as an intermediary between the other levelsDescription levelImplementation is necessarybecause otherwise no software could be generated

12. CombinationofviewsandlevelsThe engineering of complex systems is divided in separate divisionsOn the one hand: views(data, functions, processes and organization)On the other hand: levels(requirements definition, design specification, implementation)

13. House of ARISSCHEER‘S House of ARIS

14. ARISWhat is ARIS ?ARIS= Architecture of integrated Information SystemsA method-oriented architectureA program to support the modelling processdifferentiation:House of ARIS (the “idea“)ARIS Toolset (the “program“)

15. ResultsComplexityof Information Systems Engineering (unstructuredproceedingendangersthelongtermsuccess)Views of Information Systems Engineering (organization, data, functions, processes) Levels of Information Systems Engineering (requirementsdefinition, design specification, implementation)SCHEER‘S ARIS Model (House of ARIS)

16. Information Systems Engineering Methods

17. organigramOrganizationnetworktopologynetworkdiagramfunctiontreeeERMInformation flowdiagramY-diagrameERM-attribute-valuechaindiagramgoaldiagramassignmentdiagrameEPC, ACDrelationdiagramapplicationsystemaccessdiagramattributeassignmenttype diagramdiagramapplicationsystemtablediagramaccessdiagram (phys.)diagramControlFunctionsDataOverviewofmethods

18. Containment of model typesorganizationalviewOrganigram

19. enhancedevent-drivenprocesschain (eEPK)

20. technicalterm model

21. Entity-Relationship model(ERM)

22. functiontreedataviewprocessviewfunctionview

23. Functiontreestock masterdatacarestockrearrangementandrebookingstock-taking stockstocktakingStock-takingagencyctockcontrol

24. accountancyexternalaccountancyImpersonalaccountaccountantpersonalaccountantOrganigramOrganizationaldevice:taskbearerfor a certaintaskclassjob:smallestorganizationaldevice (competencyarea)joballocationpersonMr. MillerMs. Scott[Becker/Schütte (1996)]

25. Technical term modelThe technical term model is a structured description of the “technical reality“ of the observed areaserves for term harmonizationsupports process modelling by clearly defining and structuring the input and output objectsstarting basis of data modelling based on technical definitions of data objects and data groups

26. Technical termFBTechnical term modelobjects:A technicaltermrepresents Input and Output objects,dataobjects, documents etc. withintheobservedarearelations:Bymodellingrelationsbetweentechnicalterms, semanticrelationsaremapped“relatesto”

27. “is synonym of

28. “is a copyof”

29. “classifies”

30. “is a characteristicof”

31. “comprises”millFBmillerFBwatermillFBspicemillFBpeppermillFBTechnical term modelrelatestois a copyofmillattherustlingbrookFBmill type,energyorientedclassifiesFBis ais ais a

32. EntityRelationship Model (ERM)sourceofsupplyarticlesupplierANR,ANRnameLNRnamepriceLNRentitytypekeyattributerelationship typeattribute

33. orderacceptedverifyorderorder isverifieddisposeorderEvent-drivenProcess Chainorderacceptance

34. customercontactadmittedcustomerFBcustomeradresssearchcustomerFBlistofiustomersisshownCall-Centerxorcustomernotexistentcustomeridentifiedenhanced Event-drivenProcess Chain (eEPC)Maps the coherencies that have been lost due to the creation of views in an appropriate diagram without redundanciesThe coactions of the deceased components is depicted by process modellingSAP SPIdentifycustomerfromlist

35. applicationsystemtypeTechnical termFBTechnical termFBfunctionTechnical termFBTechnical termFBenhanced Event-drivenProcess Chain (eEPC)ConventionsforthealignmentofsymbolsInput objectsorganizationaldevicejobpersonext.Output objects

36. CustomerFBsearchcustomerxorenhanced Event-drivenProcess Chain (eEPC)customercontactadmittedfunctionsdata Customer AddressSAP SPFBresourceslistofcustomersisshownorganizationidentifycustomerfromlistCallCentercustomernotexistentcustomeridentified

37. Resultsrelevance of methods (in this case: level of requirements definition)methods of the functional view (function tree)methods of the organizational view (organigram)methods of the data view (technical term model, Entity Relationship Model (ERM))methods of the process view (Event-driven Process Chain (EPC), eEPC, combination of views)

38. Process Modeling withEvent-Driven Process Chains (EPC)

39. Event-DrivenProcess Chain (EPC)NameOriginally introduced as EPC(principally only functions and events)By degrees enrichment with symbols and semanticsDe facto: concept “EPC“ synonym to “eEPC“ContentDepiction of process structure of companies as a sequence of functions and eventsDepiction of connections between objects of data, functional and organizational viewStarting and ending events can be denounced for every functionEvents are triggers and results of functions

40. FunctionTime-consumptive elementActive component with “decision-making authority “Symbol:name: „active denotation“examplesacquire bill of deliveryexecute loading of THM....Function

41. EventIncidence of a state of the information system that determines the further procedure - point of time-related issuePassive componentWithout “decision-making authority“Symbol: Differentiation between allocation and releasing eventEvent

42. startingeventexecutexyzSimplestrule-conforming EPC:endingeventAssignmentFunction-Eventaxiomatic: strongly alternating procedure of functions and eventsevery EPC starts with an event.every EPC ends with an event

43. orderisacceptedverifyorderorderisverifieddisposeorderEvent-DrivenProcess Chain (EPC) – Exampleorderacceptance...

44. EPC – ConventionsfortheAssignmentFunctions-EventsAn event-drivenprocesschainalwaysstartswith a startingeventandalwaysendswith an endingevent.optional: trivial in-betweeneventswithinthe EPC maybeleft outEvents triggerfunctionsStartingeventStartingeventfunctionfunctionTrivial in-betweeneventsmaybeleft outeventfunctionfunctionCompletedfunctionscreateeventsEndingeventEndingevent

45. Event-DrivenProcess Chain (EPC) – Basic Elements

46. Event-DrivenProcess Chain (EPC) – Additional Elements

47. Event-DrivenProcess Chain (EPC)Modelling ConventionsLinkage of several functions and eventsProblem: If several fuctions and events have to be connected, the path that is executed within the process is not visible anymoreSolution:Relief is prduced by connection rules that are represented by the already shown connectors.

48. xorEvent-DrivenProcess Chain (EPC)Modelling ConventionsConnection of several occuring events:FFFE 2E 1E 3E 2E 1E 3E 2E 1E 3After executionofthefunction ...After execution of the function ...After execution of the function ...... eacheventoccurs.... at least oneeventoccurs.... exactlyoneeventoccurs.

49. xorEvent-DrivenProcess Chain (EPC) Modelling ConventionsConnection of several triggering events:E 2E 1E 3E 2E 1E 3E 2E 1E 3FFFThe functionisexecutedif ...The functionisexecutedif ...The functionisexecutedif ...... eacheventhasoccured.... at least oneeventhasoccured.... exactlyoneeventhasoccured

50. xorEvent-DrivenProcess Chain (EPC) Modelling ConventionsConnection of several executed functions:F 2F 1F 3F 2F 1F 3F 2F 1F 3EEEThe eventoccursif ...The eventoccursif ...The eventoccursif ...... eachfunctionhasbeenexecuted.... at least onefunctionhasbeenexecuted.... exactlyonefunctionhasbeenexecuted.

51. xorEvent-DrivenProcess Chain (EPC)Modelling ConventionsConnection of several functions to be executed:EEEF 2F 1F 3F 2F 1F 3F 2F 1F 3Not allowed !!!Not allowed !!!After occurrenceoftheevent…Events are passiveelementsandare notabletodecide.Events are passiveelementsandare notabletodecide.... eachfunctionistriggered.

52. E 2E 1E 3F 2F 1F 3Event-DrivenProcess Chain (EPC)Modelling ConventionsExample for combined connection rules:Ifat least oneeventhasoccurred, ...... eachfunctionisexecuted

53. Order hasbeenreceivedCheckorderOrder hasbeenreceivedOrderischeckedProcessorderEvent-DrivenProcess Chain (EPC) Modelling ConventionsHorizontal segmentation of EPC:Process modelorder processingOrder receiptProcess modelorder receiptOrderhasarrivedReceiveorderProcessinterfaceOrderprocessingHint: The firstandsecond model arelocated on the same detailinglevel

54. Order hasbeenreceivedCheckorderProcess orderOrder hasbeencheckedDisposeorderOrder isprocessedOrder isprocessedEvent-DrivenProcess Chain (EPC) Modelling ConventionsHieraching / Refinement of EPC:Order hasbeenreceivedHint: The second model islocated on a higherlevelofdetailingthanthefirstone

55. eEPCOrganigramERMFunctionTreeEPC

56. ApplicationSystemTechnical TermFBTechnical TermFBFunctionJobTechnical TermFBTechnical TermFBeEPC – Modelling ConventionsConventionsforthealignmentofsymbols:Input objectsOrganizationalDevicePersonext.Output objects

57. Swim-Lane Notation ofthe EPCMotivationDemand of practionersClear consideration ofOrganizational devicesApplication systemsDesire of process shortenigDirect connection of functionsEPC not longer compulsorily drawn as bipartite graphLoss of methodical funding

58. Swim-Lane Notation ofthe EPC - Modelling ConventionsDevelopment ofnewmodellingrules:0. Onlyoneorganizationaldevice / applicationsystem per lane1. Processeshavetostartand end withevents2. After OR or XOR eventshavetofollow3. Processinterfacesatthe end of a processhavetobeprecededbyevents4. Events shouldbelocatedbeforeand after refinedfunctionsDrawing arrowsWithin an org. device: bottomto topAccross org. devicesa) sidetosideb) bottomtosidec) bottomto topOmissions:Trivial eventsEvents thatfollow AND-connectors

59. Org. device AOrg. device Bwithin an org. device:„bottom“ „to top“Accross org. devices:„side“ „toside“Drawing Arrows in EPC(Swim-Lane Notation)