07 integrated process modelling

1,579 views
1,460 views

Published on

07 integrated process modelling

  1. 1. Integrated Process<br />Modelling<br />
  2. 2. Goals<br />Complexityof Information Systems Engineering<br />Views of Information Systems Engineering<br />Levels of Information Systems Engineering<br />SCHEER‘S ARIS Model<br />
  3. 3. Exampleforcomplexity<br />An Information System supportingthe order acceptanceofyourbusinessshallbeintroduced.<br />Describethe relevant issuesconcerningtherealizationof a systemwithaccordingrepresentationfunctions.<br />
  4. 4. Need for an architecture<br />- as an orientationalandstructuralframework<br />- as a process model<br />- for a unifieddeploymentofmethods<br />Problem ofcomplexity<br />Corporate environment constitutes need for a flexible and transparent corporate structure<br />There is a problem of complexity due to<br />the size of the (corporate) reality partition<br />the multiplicity of elements to be considered(data, functions, resources, ...)<br />the multiplicity of available modelling methods<br />
  5. 5. Views<br />OrganizationalviewWhattypesoforganizationaldevicesexist? (e. g. purchase, distribution, accountancy)<br />Data viewWhattypesofinformationare relevant? (e. g. customers, suppliers, article, listofmaterials)<br />FunctionalviewWhattypesoffunctionsaretobeexecuted? (e. g. createenquiries, verifyaccounts)<br />ControlviewCoherencyofdata, functionsandorganizationaldevices<br />
  6. 6. Waterfall Model of Software Engineering<br />
  7. 7. Operational reality<br /><ul><li>professional languagesemi-formal descriptionmethods
  8. 8. Assignment to concrete IT components</li></ul>Implementationconcept<br />Description levels<br />Requirements Definition<br />-1- organizationalview<br />(“whodoeswhat in which order”)<br /> -2- detaileddescriptionoftasks<br /><ul><li>Model-like mapping of the operational reality in consideration of a formalized description method
  9. 9. Inclusion of IT specifics</li></ul>Design specification<br />Information<br />technology<br />
  10. 10. Description levels<br />A requirements definition is necessary<br />to document experiences<br />because business knowledge changes slowly<br />to „sort“ new requirements correctly<br />because otherwise problems will be solved in an unstructured way, and insular solutions are developed<br />to keep the focus<br />
  11. 11. Description levels<br />A design specification is necessary<br />because models cannot be transscripted directly into program code<br />to undertake refinements<br />because the requirements definition cannot cover everything<br />to assure that changes of technology respectively implementation cannot affect the requirements definition directly<br /><ul><li>the design specification works as an intermediary between the other levels</li></li></ul><li>Description level<br />Implementation is necessary<br />because otherwise no software could be generated<br />
  12. 12. Combinationofviewsandlevels<br />The engineering of complex systems is divided in separate divisions<br />On the one hand: views(data, functions, processes and organization)<br />On the other hand: levels(requirements definition, design specification,<br /> implementation)<br />
  13. 13. House of ARIS<br />SCHEER‘S House of ARIS<br />
  14. 14. ARIS<br />What is ARIS ?<br />ARIS= Architecture of integrated Information Systems<br />A method-oriented architecture<br />A program to support the modelling process<br />differentiation:<br />House of ARIS (the “idea“)<br />ARIS Toolset (the “program“)<br />
  15. 15. Results<br />Complexityof Information Systems Engineering (unstructuredproceedingendangersthelongtermsuccess)<br />Views of Information Systems Engineering (organization, data, functions, processes) <br />Levels of Information Systems Engineering (requirementsdefinition, design specification, implementation)<br />SCHEER‘S ARIS Model (House of ARIS)<br />
  16. 16. Information Systems Engineering Methods<br />
  17. 17. organigram<br />Organization<br />networktopology<br />networkdiagram<br />functiontree<br />eERM<br />Information flowdiagram<br />Y-<br />diagram<br />eERM-attribute-<br />valuechaindiagram<br />goaldiagram<br />assignmentdiagram<br />eEPC, ACD<br />relationdiagram<br />applicationsystem<br />accessdiagram<br />attributeassignment<br />type diagram<br />diagram<br />applicationsystem<br />tablediagram<br />accessdiagram (phys.)<br />diagram<br />Control<br />Functions<br />Data<br />Overviewofmethods<br />
  18. 18. Containment of model types<br />organizationalview<br /><ul><li>Organigram
  19. 19. enhancedevent-drivenprocesschain (eEPK)
  20. 20. technicalterm model
  21. 21. Entity-Relationship model(ERM)
  22. 22. functiontree</li></ul>dataview<br />processview<br />functionview<br />
  23. 23. Functiontree<br />stock masterdatacare<br />stock<br />rearrangement<br />and<br />rebooking<br />stock-taking stock<br />stocktaking<br />Stock-takingagency<br />ctock<br />control<br />
  24. 24. accountancy<br />external<br />accountancy<br />Impersonal<br />account<br />accountant<br />personal<br />accountant<br />Organigram<br />Organizationaldevice:taskbearerfor a certaintaskclass<br />job:smallestorganizationaldevice (competencyarea)<br />job<br />allocation<br />person<br />Mr. Miller<br />Ms. Scott<br />[Becker/Schütte (1996)]<br />
  25. 25. Technical term model<br />The technical term model is a structured description of the “technical reality“ of the observed area<br />serves for term harmonization<br />supports process modelling by clearly defining and structuring the input and output objects<br />starting basis of data modelling based on technical definitions of data objects and data groups<br />
  26. 26. Technical term<br />FB<br />Technical term model<br />objects:<br />A technicaltermrepresents Input and Output objects,dataobjects, documents etc. withintheobservedarea<br />relations:<br />Bymodellingrelationsbetweentechnicalterms, semanticrelationsaremapped<br /><ul><li>“relatesto”
  27. 27. “is synonym of
  28. 28. “is a copyof”
  29. 29. “classifies”
  30. 30. “is a characteristicof”
  31. 31. “comprises”</li></li></ul><li>mill<br />FB<br />miller<br />FB<br />watermill<br />FB<br />spicemill<br />FB<br />peppermill<br />FB<br />Technical term model<br />relatesto<br />is a copyof<br />millattherustlingbrook<br />FB<br />mill type,<br />energyoriented<br />classifies<br />FB<br />is a<br />is a<br />is a<br />
  32. 32. EntityRelationship Model (ERM)<br />sourceofsupply<br />article<br />supplier<br />ANR,<br />ANR<br />name<br />LNR<br />name<br />price<br />LNR<br />entity<br />type<br />key<br />attribute<br />relationship type<br />attribute<br />
  33. 33. orderaccepted<br />verify<br />order<br />order is<br />verified<br />dispose<br />order<br />Event-drivenProcess Chain<br />orderacceptance<br />
  34. 34. customer<br />contact<br />admitted<br />customer<br />FB<br />customeradress<br />searchcustomer<br />FB<br />listof<br />iustomers<br />isshown<br />Call-Center<br />xor<br />customer<br />not<br />existent<br />customer<br />identified<br />enhanced Event-drivenProcess Chain (eEPC)<br />Maps the coherencies that have been lost due to the creation of views in an appropriate diagram without redundancies<br />The coactions of the deceased components is depicted by process modelling<br />SAP SP<br />Identify<br />customerfromlist<br />
  35. 35. application<br />system<br />type<br />Technical term<br />FB<br />Technical term<br />FB<br />function<br />Technical term<br />FB<br />Technical term<br />FB<br />enhanced Event-drivenProcess Chain (eEPC)<br />Conventionsforthealignmentofsymbols<br />Input objects<br />organizational<br />device<br />job<br />person<br />ext.<br />Output objects<br />
  36. 36. Customer<br />FB<br />searchcustomer<br />xor<br />enhanced Event-drivenProcess Chain (eEPC)<br />customercontactadmitted<br />functions<br />data<br /> Customer Address<br />SAP SP<br />FB<br />resources<br />listofcustomers<br />isshown<br />organization<br />identifycustomerfromlist<br />Call<br />Center<br />customernotexistent<br />customeridentified<br />
  37. 37. Results<br />relevance of methods (in this case: level of requirements definition)<br />methods of the functional view (function tree)<br />methods of the organizational view (organigram)<br />methods of the data view (technical term model, Entity Relationship Model (ERM))<br />methods of the process view (Event-driven Process Chain (EPC), eEPC, combination of views)<br />
  38. 38. Process Modeling withEvent-Driven Process Chains (EPC)<br />
  39. 39. Event-DrivenProcess Chain (EPC)<br />Name<br />Originally introduced as EPC(principally only functions and events)<br />By degrees enrichment with symbols and semantics<br />De facto: concept “EPC“ synonym to “eEPC“<br />Content<br />Depiction of process structure of companies as a sequence of functions and events<br />Depiction of connections between objects of data, functional and organizational view<br />Starting and ending events can be denounced for every function<br />Events are triggers and results of functions<br />
  40. 40. Function<br />Time-consumptive element<br />Active component with “decision-making authority “<br />Symbol:<br />name: „active denotation“<br />examples<br />acquire bill of delivery<br />execute loading of THM<br />....<br />Function<br />
  41. 41. Event<br />Incidence of a state of the information system that determines the further procedure<br /> - point of time-related issue<br />Passive component<br />Without “decision-making authority“<br />Symbol: <br />Differentiation between allocation and releasing event<br />Event<br />
  42. 42. starting<br />event<br />execute<br />xyz<br />Simplestrule-<br />conforming EPC:<br />ending<br />event<br />AssignmentFunction-Event<br />axiomatic: strongly alternating procedure of functions and events<br />every EPC starts with an event.<br />every EPC ends with an event<br />
  43. 43. orderisaccepted<br />verify<br />order<br />order<br />isverified<br />dispose<br />order<br />Event-DrivenProcess Chain (EPC) – Example<br />orderacceptance<br />...<br />
  44. 44. EPC – ConventionsfortheAssignmentFunctions-Events<br />An event-drivenprocesschainalwaysstartswith a startingeventandalwaysendswith an endingevent.<br />optional: trivial in-betweeneventswithinthe EPC maybeleft out<br />Events trigger<br />functions<br />Starting<br />event<br />Starting<br />event<br />function<br />function<br />Trivial in-betweeneventsmaybeleft out<br />event<br />function<br />function<br />Completedfunctions<br />createevents<br />Ending<br />event<br />Ending<br />event<br />
  45. 45. Event-DrivenProcess Chain (EPC) – Basic Elements<br />
  46. 46. Event-DrivenProcess Chain (EPC) – Additional Elements<br />
  47. 47. Event-DrivenProcess Chain (EPC)Modelling Conventions<br />Linkage of several functions and events<br />Problem: <br />If several fuctions and events have to be connected, the path that is executed within the process is not visible anymore<br />Solution:<br />Relief is prduced by connection rules that are represented by the already shown connectors.<br />
  48. 48. xor<br />Event-DrivenProcess Chain (EPC)Modelling Conventions<br />Connection of several occuring events:<br />F<br />F<br />F<br />E 2<br />E 1<br />E 3<br />E 2<br />E 1<br />E 3<br />E 2<br />E 1<br />E 3<br />After executionofthefunction ...<br />After execution of the function ...<br />After execution of the function ...<br />... eacheventoccurs.<br />... at least oneeventoccurs.<br />... exactlyoneeventoccurs.<br />
  49. 49. xor<br />Event-DrivenProcess Chain (EPC) Modelling Conventions<br />Connection of several triggering events:<br />E 2<br />E 1<br />E 3<br />E 2<br />E 1<br />E 3<br />E 2<br />E 1<br />E 3<br />F<br />F<br />F<br />The functionisexecutedif ...<br />The functionisexecutedif ...<br />The functionisexecutedif ...<br />... eacheventhasoccured.<br />... at least oneeventhasoccured.<br />... exactlyoneeventhasoccured<br />
  50. 50. xor<br />Event-DrivenProcess Chain (EPC) Modelling Conventions<br />Connection of several executed functions:<br />F 2<br />F 1<br />F 3<br />F 2<br />F 1<br />F 3<br />F 2<br />F 1<br />F 3<br />E<br />E<br />E<br />The eventoccursif ...<br />The eventoccursif ...<br />The eventoccursif ...<br />... eachfunctionhasbeenexecuted.<br />... at least onefunctionhasbeenexecuted.<br />... exactlyonefunctionhasbeenexecuted.<br />
  51. 51. xor<br />Event-DrivenProcess Chain (EPC)Modelling Conventions<br />Connection of several functions to be executed:<br />E<br />E<br />E<br />F 2<br />F 1<br />F 3<br />F 2<br />F 1<br />F 3<br />F 2<br />F 1<br />F 3<br />Not allowed !!!<br />Not allowed !!!<br />After occurrenceoftheevent…<br />Events are passiveelementsandare notabletodecide.<br />Events are passiveelementsandare notabletodecide.<br />... eachfunctionistriggered.<br />
  52. 52. E 2<br />E 1<br />E 3<br />F 2<br />F 1<br />F 3<br />Event-DrivenProcess Chain (EPC)Modelling Conventions<br />Example for combined connection rules:<br />Ifat least oneeventhas<br />occurred, ...<br />... eachfunctionisexecuted<br />
  53. 53. Order has<br />been<br />received<br />Check<br />order<br />Order has<br />been<br />received<br />Order<br />ischecked<br />Process<br />order<br />Event-DrivenProcess Chain (EPC) Modelling Conventions<br />Horizontal segmentation of EPC:<br />Process model<br />order processing<br />Order receipt<br />Process model<br />order receipt<br />Orderhasarrived<br />Receive<br />order<br />Processinterface<br />Order<br />processing<br />Hint: The firstandsecond model arelocated on the same detailinglevel<br />
  54. 54. Order has<br />been<br />received<br />Check<br />order<br />Process order<br />Order has<br />been<br />checked<br />Dispose<br />order<br />Order is<br />processed<br />Order is<br />processed<br />Event-DrivenProcess Chain (EPC) Modelling Conventions<br />Hieraching / Refinement of EPC:<br />Order has<br />been<br />received<br />Hint: The second model islocated on a higherlevelofdetailingthanthefirstone<br />
  55. 55. eEPC<br />Organigram<br />ERM<br />FunctionTree<br />EPC<br />
  56. 56. Application<br />System<br />Technical Term<br />FB<br />Technical Term<br />FB<br />Function<br />Job<br />Technical Term<br />FB<br />Technical Term<br />FB<br />eEPC – Modelling Conventions<br />Conventionsforthealignmentofsymbols:<br />Input objects<br />Organizational<br />Device<br />Person<br />ext.<br />Output objects<br />
  57. 57. Swim-Lane Notation ofthe EPCMotivation<br />Demand of practioners<br />Clear consideration of<br />Organizational devices<br />Application systems<br />Desire of process shortenig<br />Direct connection of functions<br />EPC not longer compulsorily drawn as bipartite graph<br />Loss of methodical funding<br />
  58. 58. Swim-Lane Notation ofthe EPC - Modelling Conventions<br />Development ofnewmodellingrules:<br />0. Onlyoneorganizationaldevice / applicationsystem per lane<br />1. Processeshavetostartand end withevents<br />2. After OR or XOR eventshavetofollow<br />3. Processinterfacesatthe end of a processhavetobeprecededbyevents<br />4. Events shouldbelocatedbeforeand after refinedfunctions<br />Drawing arrows<br />Within an org. device: bottomto top<br />Accross org. devicesa) sidetosideb) bottomtosidec) bottomto top<br />Omissions:<br />Trivial events<br />Events thatfollow AND-connectors<br />
  59. 59. Org. device A<br />Org. device B<br />within an org. device:<br />„bottom“ <br />„to top“<br />Accross org. devices:„side“ <br />„toside“<br />Drawing Arrows in EPC(Swim-Lane Notation)<br />
  60. 60. Org. device A<br />Org. device B<br />Org. device C<br />Drawing Arrows in EPC(Swim-Lane Notation)<br />Accross org. devices:„bottom“<br />„toside“<br />
  61. 61. Examplefor an EPC in Swim-Lane Notation<br />.<br />
  62. 62. More Model Types<br />Hierarching EPCs („bottom-up“): Value Chains Diagrams<br />…<br />
  63. 63. Value Chain Diagram (VCD)<br />Classic Value Chain<br />Depictionofthesequenceoffunctionsthatcontributetothevaluecreationof a product (Idea „Value Cain“ by M. E. Porter: Competitive Advantage, 1985)<br />Functionsarearranged in a processorientedway<br />VCD in ARIS<br />Methodicalextensionofthe classic valuechain<br />Provides an abstractdepictionofhighlyaggregatedprocesses / functions<br />Not suitabletodisplaydetailedorcomplexprocesslogics due tomissingcontrolconnectors<br />
  64. 64. Value Chain Diagram (VCD)Modelling Conventions<br />VCD element<br />“ispredecessorof”<br />Startfunktion<br />Folgefunktion<br />Implicitlogical<br />“AND”<br />“isprocess-orientedsuperior”<br />Refinedby a<br />detailed model<br />Sequential<br />processes<br />Parallel<br />processes<br />
  65. 65. Interrelation VCD - EPC<br />Layer 1: Value Chain Diagrams (VCD)<br />Function A<br />Function B<br />Function C<br />Function 1<br />Function 2<br />Function 3<br />Refinementof a VCD<br />Functionbyanother<br />VCD<br />Function 1<br />Function 2<br />Function 3<br />Refinementof a VCD<br />functionby an EPC<br />Layer 2: Event-DrivenProcess Chains (EPC)<br />Process A<br />Process B<br />Event 1<br />Predecessor /<br />Successor<br />process<br />Function 10<br />Event 4<br />Event 5<br />Function 12<br />Function 13<br />Event2<br />Event 3<br />Event 3<br />Event 5<br />Event 6<br />Function 11<br />Function 11a<br />Process C<br />Event 4<br />Event 4<br />Refinementof an EPC<br />functionby an EPC<br />Process B<br />
  66. 66. Alternatives of VCDOrganizational Frameworks andFunctionTrees<br />
  67. 67. Alternatives of VCDOrganizational Frameworks andFunctionTrees<br />
  68. 68. Alternatives of VCDOrganizational Frameworks andFunctionTrees<br />
  69. 69. Integrated Process<br />Modelling<br />

×