7. Classification Business Process Modelling and Workflow Management Business value Lecture 4 (Terminology cntd.) Ekkart Kindler kindler@upb.de Structuring (repetition) Automation UPB SS 2006 L04 2 Classification (after Leymann/Roller) Automation no: The business process is not supported by an information system. Documents are created changed and routed by hand. Semiautomatic: partial support by an information system. Fully automatic: The execution of the business process is fully controlled by an information system. Many activities are automated. UPB SS 2006 L04 3 UPB SS 2006 L04 4 8. Architecture and interfaces of a WFMS Workflow Engine Organisation Information Integration Control Execution of workflows (enactment) keeping track of current activities assignment of activities to agents (work items work lists) providing and maintaining the associated documents resp. data UPB SS 2006 L04 5 UPB SS 2006 L04 6 1
Developer's view Agent's view Organisation Information Integration Control workflow modelling analysis validation and verification of a workflow (resp. of some aspects) simulation of workflows Maintain and display executable activities (work list) Allow the agent to chose an activity (work item) start of associated applications Start of new (instances of) workflows UPB SS 2006 L04 7 UPB SS 2006 L04 8 Administrator's and manager's view Neighbour system's view! Interoperation with other workflow engine start of workflows on other engines access state of workflows on other engines... UPB SS 2006 L04 9 UPB SS 2006 L04 10 II. Business Process Modelling BPM & WfM Organisation Information aspect Information Integration Control II. Business Process Modelling Control aspect Organisational aspect UPB SS 2006 L04 12 2
1. Information Aspect 1.1 Motivation and Terminology Data: Information documents and their representation "# $ " UPB SS 2006 L04 13 UPB SS 2006 L04 14 Business data In conventional business information technology business data are maintained in a (relational) data base. Studies show that most information in an enterprise exists in form of documents; only a small amount of information is represented in relational form! Reasons %&' &' Users (agents) don't think in data records (tuples of a RDBMS). Users think in documents. The relation between the data in the data base and a business process is not represented in the database schema. Users are not willing (and should not be forced to) get the related data from a data base. UPB SS 2006 L04 15 UPB SS 2006 L04 16 Disclaimer Data Modelling (Information modelling) Database and transaction theory are one of the foundations of business information technology. A database forms the centre part of a WFMS. But: Most of it belongs to the technical aspects of workflows. Data modelling is part of business process modelling (information aspect). But a data model is not enough for modelling the information aspect of a business process. $( UPB SS 2006 L04 17 UPB SS 2006 L04 18 3
What is missing? Remarks A document is a collection of related data (information) necessary for processing specific activity or business process. A business process can be considered as a goal oriented structuring mechanism for all activities of an enterprise which defines the relation among activities. Likewise documents can be considered as a (nonorthogonal) structuring mechanism for all business data. UPB SS 2006 L04 19 UPB SS 2006 L04 20 1.2. Data Modelling Example: Course Administration Entity Relationship Diagrams (ER) Extended ERDiagrams (EER) (Simplified) class diagrams "$ )&*' )+ * * * * * * / ( * *. UPB SS 2006 L04 21 UPB SS 2006 L04 22 EER Diagrams: Summary Warning: Cardinalities 0 1 *. There are two different versions of representing the cardinalities of a relation! We use the crosswise notation in analogy to UML s cardinalities of associations ARIS uses the noncrosswise notation. * UPB SS 2006 L04 23 UPB SS 2006 L04 24 4
Example in UML Documents Extended ER diagrams (after Scheer) allow us to indicate related information: roughly Documents 23 23 23 23 23 /3. 23 2/ / ( /3 UPB SS 2006 L04 25 UPB SS 2006 L04 26 Re: Document Defining Documents A document is a collection of related (business) data necessary for processing a specific activity or business process. Identifying related information is only the first step towards defining the involved documents. The document structure is still missing (the order and the hierarchical relation between data). The structure document structure can be defined in a document definition/description language: ODA SGML XML. UPB SS 2006 L04 27 UPB SS 2006 L04 28 Remark 1. 4 XML The description of documents with conventional document description languages to some extent deals with technical aspects of a business process (encoding etc.). Nevertheless we will briefly discuss document definition languages here. XML should serve as an example of a document description language. XML is a cutdown version of SGML for defining the logical structure of documents. 456*. UPB SS 2006 L04 29 UPB SS 2006 L04 30 5
XML (extensible Markup Language) Counter example: Objective: Documents should be understood by a computer (program)! Textual representation of an address: Kuno von der Heide Hinter dem Teich 25 47110 Dorf UPB SS 2006 L04 31 UPB SS 2006 L04 32 Example in XML: XML: The Concept <person> <name> <forename>kuno</forename> <titel>von der</titel> <surname>heide</surname> </name> <addresse> <street>hinter dem Teich</street> <no>25</no> <zipcode>47110</zipcode> <city>dorf</city> </addresse> </person> Separation of Syntax Semantics and Presentation Ontologies semantic web 4 7 4 74 8 UPB SS 2006 L04 33 UPB SS 2006 L04 34 Example Presentation XML vs. HTML! " 8(9: ;<//21 XML and HTML seem to be similar! What is the difference? HTML provides no semantical information HTML provides structural and presentation information only <em>kuno von der Heide</em> 0 = UPB SS 2006 L04 35 UPB SS 2006 L04 36 6
XML vs. HTML Document and Document Type The legal syntax of HTML documents is fixed; it cannot be adapted to our specific needs. XML allows us to define the structure of documents (and to name the elements according to their meaning). The structure of an XML document is defined by an XML Document Type Definition (DTD) # $%&' = UPB SS 2006 L04 37 Ontologies semantic web techniques define the sematics UPB SS 2006 L04 38 Information Aspect II. Business Process Modelling Up to now we only modelled data and documents! We did not model how data or documents are propagated among tasks resp. activities! We will deal with this later Integration of aspects MQ Series (in the context of the behaviour aspect) Information aspect Control aspect Organisational aspect UPB SS 2006 L04 39 UPB SS 2006 L04 40 2. Control Aspect 2.1 Routing Constructs Routing constructs Modelling with Petri nets EPCs (Event driven Process Chains) MQ Series Process Model The Workflow Management Coalition (WfMC) identifies for routing constructs for the definition of the behaviour of a business process (workflow): sequential conditional parallel iterative UPB SS 2006 L04 41 UPB SS 2006 L04 42 7
Sequential Routing Conditional Routing Two activities are processed one after the other (sequentially): Two activities are processed alternatively: (' (' UPB SS 2006 L04 43 UPB SS 2006 L04 44 Parallel Routing Iterative Routing Two activities are processed concurrently to each other (in parallel): One activity is (sequentially) processed one or more times: )' )' UPB SS 2006 L04 45 UPB SS 2006 L04 46 Iterative Routing (other version) Routing Constructs (Summary) One activity is processed zero or more times: The four routing constructs of the WfMC can be easily mapped to Petri nets. Workflows constructed from the four routing constructs only can be translated to most workflow definition languages. Workflows built from the four constructs are always sound ( workflow analysis) But: Workflow languages with these four routing constructs are quite limited > UPB SS 2006 L04 47 UPB SS 2006 L04 48 8
Re: Business Trip Routing Constructs Summary Many notations for business processes provide more freedom: Advantages: Simpler models More intuitive models > Disadvantages: Many different notations (minor variations / major conceptual differences) Different notations cannot be mapped to each other UPB SS 2006 L04 49 UPB SS 2006 L04 50 9