USING OOEM TO ANALYZE INTER-ORGANIZATION PROCESS ZHENGBIN SHUAI. M.Eng., Beijing University of Aeronautics and Astronautics, 1988

Transcription

1 USING OOEM TO ANALYZE INTER-ORGANIZATION PROCESS by ZHENGBIN SHUAI M.Eng., Beijing University of Aeronautics and Astronautics, 1988 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREEE OF MASTER OF SCIENCE in THE FACULTY OF GRADUATE STUDIES (Faculty of Commerce and Business Administration) We accept this thesis as confirming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA February , Zhengbin Shuai

2 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of ^ M ^ y sznjfecfz''*>t>&fy*""' 6 * The University of British Columbia Vancouver, Canada DE-6 (2/88)

3 Abstract Inter-organization (IO) process streamlining and integration are becoming more and more important in business operations, especially in B2B and supply chain management. Not only will analyzing and modeling IO processes help people on both the business side and the technology side clearly understand the related issues, but it will also allow information system design and implementation to meet business requirements. Compared with the modeling of intra-organization process, modeling IO process necessitates dealing with some special issues such as the interface difference and the rule difference of different organizations. This thesis aims to test the applicability of the object-oriented enterprise model (OOEM), an ontologically based enterprise analysis method, and the OOEM workflow model (OOWM) to a multi-organizational system to help analyze IO processes and stress the related issues. Rules and procedures for the formation of MO-OOEM, an OOEM and OOWM specialization that is used to support cross organization process analysis, are proposed. We use the MO-OOEM object model to describe the structure of the multi-organization system, and the MO-OOEM workflow model to model the inter-organization processes. Sample cases are presented in the thesis to show the details of our method. ii

4 Table of Contents ABSTRACT TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES ii iii v vii 1. INTRODUCTION Motivation Thesis Objectives Thesis Outline 2 2. IO PROCESS ISSUES IO Process IO Process in Supply Chain Information Systems and IO Process IO Process Related Issues Criteria for IO Process Analysis Methods Proposed Method OOEM METHOD Theoretical Foundations OOEM Constructs OOEM Rules OOWM 23

5 4. THE USE OF OOEM TO SUPPORT IO PROCESS ANALYSIS MO-OOEM: An Overview MO-OOEM Object Model for IO Process The MO-OOEM Workflow Model THE WORKFLOW LOGIC OF MO-OOEM What's New in IO Processes Controllers Requests Control Logic CASE ANALYSIS AND EVALUATION TKCase Creating the MO-OOEM Object Model MO-OOEM Workflow Model Model with System Controller Li & Fung Case Evaluation THESIS SUMMARY AND FUTURE RESEARCH Thesis Summary Contributions Limitations and Future Research 80 BIBLIOGRAPHY 82 iv

6 List of Figures Figure 2-1 A SCM Model 5 Figure 3-1 OOEM Graph 18 Figure 3-2 OOEM Workflow Model 24 Figure 3-3 Service vs. Activities 26 Figure 3-4 The Implementation Model of OOWMS 28 Figure 4-1 MO-OOEM Structure 31 Figure 4-2 Meta Model of MO-OOEM 32 Figure 4-3 MO-OOEM Graphic Model 33 Figure 4-4 Sub-processes 37 Figure 4-5 The Default Maximum Scope 38 Figure 4-6 Target vs. Actual Scope 39 Figure 4-7 OOEM Workflow Graphic Model 46 Figure 5-1 Controller Architecture 52 Figure 5-2 The Workflow Implementation Model of MO-OOEM ' Figure 5-3 The Request Handling Structure 57 Figure 6-1 MO-OOEM Object Model of TK Case 63 Figure 6-2 Ordering Process in OOWM 65 Figure 6-3 Activity Diagram of Ordering Process 68 Figure 6-4 TK Ordering Process with Controllers 69 Figure 6-5 Li & Fung's Value Added Chain 71 Figure 6-6 Li & Fung in the Chain 71 V

7 Figure 6-7 Li & Fung Case MO-OOEM Object Model Figure 6-8 Ordering Process of Li & Fung Figure 6-9 System Controller in Li & Fung Case

8 List of Tables Table 3-1 OOEM Constructs 17 Table 3-2 OOEM Object Template 19 Table 3-3 Object Activity Template 25 Table 4-1 Steps and Rules 45 Table 6-1 Attributes and Requests 61 Table 6-2 Order Management Department Object Activity Template 66 vii

9 1. Introduction 1.1 Motivation While some companies are still trying to integrate their business processes across different functional departments within the scope of their company, others are integrating the processes across company boundaries to further increase efficiency and competition advantages. Software vendors (e.g. IBM, Microsoft, BEA, etc.) have developed different products to support the integration. Many vendors claim that their products can support the integration of inter-organization business processes seamlessly. However, those products are developed mainly based on the specification, perspective or intuition of vendors. To date, there has been no well developed methodology for analyzing of IO process integration. Surprisingly little literature discusses how to analyze or model IO processes. Considering the complexity of IO process analysis, a methodological approach is needed. As Klein [1994] states, "an intuitive approach tells people where to go, whereas, the methodological approach tells people what to do to get there." A modeling and analysis method which can support IO processes is the central part of the methodology. In this thesis, we suggest to use object-oriented enterprise model (OOEM) proposed by Zhao [1995] and OOEM workflow model (OOWM) proposed by Hui [1997], which provide methods to analyze and model business process in an organization. Compared with many other modeling methods and tools, OOEM has a good theoretical foundation 1

10 and well defined constructs. The OOEM method can not only be used in the high level business analysis, but also be transferred to a system design model [Jung, Wand and Woo, 1997]. However, like most of the other analysis or modeling methods, OOEM is normally used for analyzing processes or systems within a single organization. 1.2 Thesis Objectives The objective of this thesis is to apply OOEM and OOWM to inter-organization process analysis. Considering the special issues in the modeling of IO processes and multi-organization systems, and also considering the single-organizational characteristics of currently used methods, we need to make modifications to OOEM and OOWM so as to support IO process or IO system analysis. We aim to achieve the following objectives in this thesis: Identify the issues in modeling IO process Test the applicability of OOEM and OOWM in supporting IO process analysis and dealing with the identified issues 4* Set modeling rules or modify the current OOEM rules for modeling IO process -sv Provide algorithms for modeling IO process using OOEM and OOWM Evaluate the results of using OOEM and OOWM to analyze inter-organizational processes. 1.3 Thesis Outline Chapter 2 outlines the IO process, IO process related information systems, and issues in 2

11 10 process modeling. Chapter 3 reviews the background of OOEM, including the OOEM workflow model. Chapter 4 introduces the methods which will be used in 10 process analysis. This chapter also presents and discusses related rules, tools and algorithms. Chapter 5 provides the workflow logic of the proposed model. Chapter 6 presents sample cases to illustrate the use of the method, followed by evaluations of the method. Chapter 7 summarizes the thesis and outlines future research. 3

12 2. IO Process Issues This chapter provides the background information about IO process, IO process in supply chain management, and IO process analysis. We also introduce the types of inter-organization information systems which support IO process. The aim of the chapter is to identify the issues related to IO process. 2.1 IO Process IO process is the process which crosses the boundaries between different organizations. In order to cut waste and improve efficiency, many organizations have thoroughly studied intra-organization processes and have successfully streamlined such processes. In comparison to intra-organization process analysis, IO process analysis is relatively new. As Hammer [2001] mentions, "While it's true that companies have done a great job streamlining their internal processes, it's equally true that their shared processes- those that involve interactions with other companies-are largely a mess". However, because of its great potential to improve the efficiency and productivity of the organizations involved, IO process study and streamlining are attracting more and more attention [Lindert & Deiters, 1999]. "Streamlining cross-company processes is the next great frontier for reducing costs, enhancing quality, and speeding operations."[hammer, 2001] 2.2 IO Process in Supply Chain The supply chain (SC) includes all activities related to the flow and transformation of raw materials, through to the end user, and the associated information flows. When these 4

13 activities are connected, IO processes normally result. Supply chain management (SCM) is the integration of the activities in a supply chain and is achieved by improving supply chain relationships, to achieve a sustainable competitive advantage. The graph on figure 2-1 shows an integrated supply chain model proposed by Hanfield & Nichols [1999]. ^Customers \7 Product & material flov Retailers Inform ation & financial flow Distribution Centre \7 Dark background indicates relationship management Assembly/ Manf. \7 W 1st Tier Suppliers K W 1 st Tier Suppliers A 2nd Tier Suppliers r* W2nd Tier Suppliers (2nd Tier Suppliers Figure 2-1 A SCM Model Adapted from [Hanfield & Nichols, 1999]. In a supply chain, most of the key processes, whether upstream (buy-side) or downstream

14 (sell-side), are 10 processes. When these 10 processes are cut into segments and performed separately, we see many problems, such as the inconsistency of data, duplication of activities, uncertain inventory, etc. [Hammer, 2001]. Therefore, like those in other fields, companies in supply chain "are starting to see business process - and manage them - as they truly are: chains of activities that are performed by different organizations."[hammer, 2001] On the buy-side, companies are trying to streamline the IO process by sharing information in real time, avoiding the reentry of the same data across border, and relocating work to obtain higher efficiency. On the sell-side, by better managing the IO process, companies can make demand planning or forecasting more accurate. Even collaborative product development becomes possible when organizational walls are torn down. 2.3 Information Systems and IO Process Information technology is an important technology which supports business operations. Business processes across organizations can also be supported by information systems which cross different organizations Inter-organizational Systems When information systems are applied to support multi-organizational applications, they are normally inter-organizational systems. The inter-organizational system (IOS) is the 6

15 application system that links various organizations using a public or private telecommunications infrastructure. [Premkumar, 2000]. Based on the level of sophistication of an IOS, Premkumar [2000] divides the IOS into three levels: communication, coordination, and cooperation. The communication level, which is the simplest level, is used to exchange electronic messages between partners. The initial stage of EDI falls into this category. The second level is the coordination level. At this level, computer-to-computer communication is integrated with the internal information systems of the participating organizations. On the third level, business partners share common goals and use similar performance measures to evaluate the performance of their IO activities. Hong [2001] classifies the IOS into four types by their role linkage and the system support level. The four types of IOS are resource pooling, complementary cooperation, operational cooperation and operational coordination. The resource pooling IOS links participants who are performing common value activities. For example, Garden.com's internet-based IOS interconnects many flower suppliers to deliver flowers to customers in different regions. A complementary cooperation IOS represents a form of cooperation among firms in an industry value chain. An example of complementary cooperation IOS is UAL and SAS's attempt to offer an integrated travel service that combines the airline, car-rental, and hotel in one system. The operational cooperation IOS brings together firms in a common value chain to improve the quality of customer service or to share 7

16 information of common interest (e.g. Canadian Airlines united with other international airlines in certain services). The role of an operational coordination IOS is to interconnect different roles played by firms to increase operational efficiency. For example, Nike Inc. outsources production to contractors and coordinates/controls it through an IOS. Hong [2001] also states that IOS can link firms either horizontally (e.g. connected for cooperation between competitors) or vertically (e.g. interconnected with buyers, sellers). In the above categories, the resource pooling and operational cooperation IOSs are linking horizontal firms while the complementary cooperation and operational coordination IOSs link firms vertically. Hong [2001] suggests that the B2B intermediary which can link firms both vertically and horizontally is a new form of IOS. Those different classifications of IOSs help us understand that IOSs can support IO processes in different ways and at quite different levels Streamlining and Integration of Business Process There are several closely related terms regarding the streamlining and integration of business processes on an information system basis, such as business process integration (BPI), enterprise application integration (EAI) and inter-enterprise integration (IEI). Business process integration (BPI) is the term used to describe the integration of business processes among previously segregated business units. BPI can also cover the integration 8

17 of processes across organizations. By consolidating redundant processes across functional areas, BPI can result in a more efficient organization with lower costs [Ulrich, 2002]. Enterprise application integration (EAI) is normally related to the integration of information systems within an organization. EAI also covers inter-organization integration [Roch, 2002]. Inter-enterprise integration (IEI), on the other hand, mainly focuses on issues of integration across enterprises [Meta Group, 2002]. While streamlining processes within their boundaries, companies recognize the importance of breaking down the functional boundary between departments or business units. As a result, efficiency is improved and companies gain a competitive advantage. Since processes are not always confined to within an organization's border, especially in B2B and supply chain areas where the core processes (e.g. purchasing) normally cross at least two organizations, inter-organization integration is becoming more and more important [Hammer, 2001]. According to research conducted by META Group Inc., "by 2004, a business operations integration paradigm driven by web services-based business process objects maintained within secure repositories will include B2B as enterprises participate cooperatively in cross-industry, multiparty transactions. By 2006, co-combined business operations will emerge as the predominant model among value chain partners, setting the stage for 9

18 enterprise-to-enterprise integration by 2007". [Friedman, 2001] In terms of advantages provided by IEI, Barnes [2001] claims that IEI will: Enable B2B or supply chain partners to cost-effectively extend supply/service chains to partners, suppliers, customers and marketplaces; *Y- Provide mechanisms necessary to exchange and rationalize the flow of data, processes, and information; \V Help organizations provide value-added services, e.g. more accurate delivery dates; \V Help improve operational efficiency and increase incomes by enabling organizations to reduce costs within the supply chain, improve cash flow, and eliminate manual touch points; "v* Reduce the order-to-ship gap, enable predicable delivery forecast, which is crucial for improving customer satisfaction and retention, and eventually reduce outstanding accounts receivable. It is believed that "cost-effectively implementing, managing, and maintaining application integration solutions and technology (both within and across organizations involved in B2B initiatives) will remain a key success factor for Global 2000 organizations during the next three to five years."[barnes, 2001] 2.4 IO Process Related Issues In contrast to intra-organization process, inter-organization process has two special 10

19 issues: (1) Different interfaces - Since an intra-organization process is within a single organizational system, the involved objects share certain attributes and interface. Therefore, they know how to communicate with each other. On the other hand, the participating objects of an inter-organization process may not know how to communicate with the objects in other organizations because objects from different organizations may have no knowledge of each other. For example, if we try to model the communication between two objects from different organizations and the two objects have different ways of communication (e.g. the format of message), and may not have knowledge of these different ways, the communication will be hard to establish and model. (2) Rule difference - Objects in a single organization share common organizational rules; however, the participating objects from different organizations in an inter-organization process have different organizational rules. Objects in different organizations may act differently regarding the same event, because they are following their own organizational rules. When modeling an IO process, for example, it will be difficult to model the actions an object may take if we do not know which rule it will follow. In addition to the above two special issues, there are some generic issues related to IO process. Some of them are as follows: No clear boundary - An IO process may span many organizations and normally it is 11

20 difficult to find the process's starting and ending point, "v" Complexity - Once a process crosses the organization border; and continues, it becomes a chain. A good example is the process in supply chain, because it " becomes sufficiently complex beyond two levels" and "the complexity stems from the fact that it is not simple linear chain [but] a complex web of chains". [Premkumar, 2000] Difficult to coordinate - With many owners, each performing a segment of the IO process based upon their own motivations, the management and coordination will be difficult. Compatibility - Different organizations may have different approaches and technologies for the same IO process. Compatibility might be a problem at both higher and lower levels. Boundary issues - Since the IO process will cross organizational boundaries, issues related to boundaries might occur [Premkumar, 2000]. Distributed locations of partners [Basu and Kumar, 2002] - The IO process is normally conducted by partners in different locations, which means a failure in communication might cause the failure of the process. Although some of these issues apply to both intra-organization and inter-organization operations, they will be much more challenging in inter-organization operations due to the problem of different interfaces and rules. For example, with different interfaces and rules for participating objects, coordination will be much more difficult in an IO operation than 12

21 it is in an intra-organization one. Similarly, the two special issues of the IO process will add much complexity to IO operations and make the compatibility issue even more challenging. 2.5 Criteria for IO Process Analysis Methods Although there are many challenges, IO process analysis is very important for BPI, IEI, B2B and supply chain management, since it provides the basis and starting point for the streamlining and integration of the process. It is hard for an IO process to be improved or streamlined without a thorough study and analysis of the process. We need to find a way to analyze the IO process. We believe that the ideal method must emphasize the issues of IO process, i.e. the problem of dealing with the different interfaces and different rules. The method should also "v* be easily understood by different stakeholders; have a good business view; -v* have clear modeling procedure and rules; sv facilitate business process streamlining; sv convey information about interaction and steps; -s> be transferable into IS model as needed. 2.6 Proposed Method Considering the issues (i.e. the different interfaces and rules) mentioned in 2.4, we believe that existing process modeling methods are not able to handle the above mentioned 13

22 challenges well. For example, using existing methods, it is quite difficult to model the different interfaces of different organizations because existing methods mainly focus on the steps of operations in a process. Normally they either do not model the interactions among participating units or assume the participating units have the same interface (as is the case in an intra-organization process) to communicate. Therefore, the different interfaces of participating units from different organizations in an 10 process will be difficult to model. Similarly, the existing process modeling methods normally assume the same organizational rule will be followed throughout like in a single organizational process. However, when a process crosses several organizations, the different rules will make the process modeling difficult. For example, it will be difficult to determine which rules will be used in the process segments which cross different organizations and therefore do not belong to any organization. We propose to combine the object-oriented enterprise model (OOEM) and OOEM workflow model (00WM) to analyze the 10 process. As an object-oriented method, OOEM can handle the interactions between participating objects and deal with the different interface issue. Considering the fact that OOEM itself cannot handle the rules, we use OOWM, which can handle business rules, to deal with the issue of different rules. Therefore, we believe that the analysis of special 10 process issues might be facilitated by combining OOEM and OOWM. 14

23 3. OOEM Method The object-oriented enterprise model (OOEM) based on the modeling rules ofwand and Woo [Wand & Woo, 1993] is described by Zhao [1995]. With an ontological foundation on Mario Bunge's ontology [Bunge, 1977, 1979], OOEM has a modeling method, a request propagation algorithm, and a systematic way for finding objects and creating an enterprise model [Zhao, 1995]. 3.1 Theoretical foundations The OOEM is based on ontological principles from Mario Bunge's ontology [Bunge 1977, 1979]. A brief summary of the main concepts as categorized by Wand and Woo [1999] is given below. Things and properties o o The world is made of things that possess properties. The properties of a thing are related and constrained by laws that are themselves properties, o o Things can associate to form composite things, An emergent property is the property of a composite thing which is not possessed by any of its components, "v" Model of things - functional schema o o A thing possesses properties whether humans are aware of them or not. Every property can be modeled as an attribute, but not every property will be described in terms of attributes and not every attribute will represent a 15

24 property. o An attribute can be represented as a function where the arguments are things and an "observation point" (in a particular time) where the output is a value. o A functional schema is a set of attribute functions defined over a certain domain. o The state of a thing comprises the values of functions in the functional schema at a given point in a certain domain M (especially in time). Dynamics o o Everything changes and every change is a change of things, An event is a change in the state of a thing Systems o A system is a composite thing where for every bi-partition of the composition, interactions exist between things in the two subsets. 3.2 OOEM Constructs The basic constructs in OOEM are object, service, attribute and request. Table 3-1 is a summary of these constructs described by Hui [Hui, 1997] 16

25 Constructs Object Meaning A model of a substantial thing in the problem domain that interacts with other objects. An object can be a client or an internal object. A client object is not considered a part of the system directly under study whereas an internal object is an object within the system. An object can represent organizational unit, a division, a department or a role. Interface Attribute A mutual property of things. It serves as a mechanism by which objects communicate with each other. Internal Attribute An intrinsic property of a thing. It can represent knowledge internal to an object and inaccessible to other objects Service A well-defined series of actions which satisfy a request. A service may access or modify the objects. Request A representation of an interaction between objects. It changes the interaction between objects. It changes the interface attributes of a recipient object, and it may trigger a service. Table 3-1 OOEM Constructs 17

26 Figure 3-1 shows the graphic OOEM model. In the model, the dashed oval represents the system to be analyzed. Object 1 is the external object of the system which has two internal objects: Object 2 and Object 3. The arrow on the graph shows the request and response of one object to another. The request is at the start of the arrow while the response for the request is shown at the end of the arrow. -^JbjectY Request i Respons^ ^ Object2 Attribute ^ Request f Object3 ^' Attribute Service 1 V / Response ^ Service j, Figure 3-1 OOEM Graph In many cases, we are interested in more detailed information than that which could be shown on this graph. In order to provide a powerful modeling tool and an easily readable graph to effectively manage the complexity, OOEM provides a separate object template to show detailed information about an object. Table 3-2 shows a sample object template. 18

27 Object Name Services Interface Internal Request generated Attributes Attributes Service 1 Incoming Internal Access Request to object A interface attributes to Mode generated from service 1 attributes support Returning Service 1 Request to object B interface generated from service 1 attributes Service 2 Incoming Internal Access Request to object C interface attributes to Mode generated from service 2 attributes support Service 2 Table 3-2 OOEM Object Template (Adapted from Zhao [1995]) 3.3 OOEM Rules The OOEM modeling rules proposed by Wand and Woo [1993] are the essential parts of OOEM. These rules provide guidelines for how to apply the model to analyze a case. Rule #1 Scope rule The aspects of the system to be modeled are all and only those needed to represent the effects of relevant external events. The scope rule is aimed at defining the boundary of the targeted system. The external events are external stimuli that the system has to respond to and the set of relevant stimuli can be determined by the modeler. With this rule, an analyst can differentiate the target system from the environment. The objects outside the scope are clients or external objects 19

28 of the system, while the objects inside the system are internal objects. For example, when a customer places an order using the system of a company, all the participants and actions directly or indirectly reacting to the customer's request are in the scope of the system. Thus the customer is a client of the system. If there are several external events, the modeler can follow the same procedure for each one, and the final scope will be the union of all the results. Rule #2 Object inclusion rule The model will contain all and only objects involved with generating requests for the system or responding directly or indirectly to the relevant external events. This rule reflects the idea of request propagation in OOEM. With this rule, the analyst can determine whether or not an object should be included in the model. Using the example of a customer placing an order, if the objects in sales, marketing, accounting and shipping are involved in the customer order process, we will include all these objects in the final model. On the other hand, an object, which does not participate in any such process triggered by an external event will not be included in the model. Rule #3 Service inclusion rule A service will be included in an object if and only if it is invoked by at least one request generated directly or indirectly by a client. Each service must use and change at least one attribute. 20

29 This rule defines which services of an object should be included in the object only those used by the object to process a request in the domain. In the aforementioned example, a request from a client may trigger an object in the sales department to take action to accept the customer order. In that case, the "accept order" service of the object should be included. Rule #4 Attribute inclusion rule Every attribute in the model must be (1) used or affected by at least one service of the object and (2) either an interface attribute 'known' to at least one other object, which then must be included, or an internal attribute, which is not necessarily included. This rule states that only an attribute known by at least one other object and used by at least one service of the object itself can be included in the object. In example of a customer placing an order, if another object of the sales department is requested to update the order information after an order is accepted, the "order information" attribute should be included in this object. Rule #5 Attribute ownership rule For every attribute in the model, there is exactly one object that can modify it. For an internal attribute, the object is the only one that can access the value of the attribute. 21

30 This rule is related to the encapsulation of object. Based on this rule, no attribute can be shared by two or more objects and only the owner of the attribute can modify it. If an object wants to change the attributes of other objects, it can only send requests to the attributes' owners. Rule #6 Composite object rule (1) A composite object should be included in the model only if it provides services that are not provided by any of its components. (2) Only properties that are not properties of components should be included in the composite. This rule determines when a composite object can be included with its component object in the same model. For example, if the sales department does not provide any new services other than those provided by the objects of the department, the sales department should not be included it the model. Rule #7 Sub-classification rule (1) A sub-class should be formed only if it includes new properties with respect to its super-class. Only properties that are not of super-classes should be include in the sub-class. (2) A super-class will be formed from two or more classes only if they have some common properties. 22

31 This rule determines when a sub-class or super-class can be used in the model. For example, if there is an employee class, we may form a part-time employee class as a sub-class, because the part-time employee class includes new properties (e.g. hours worked) not otherwise included in the employee class. On the other hand, the reason we have the employee super-class is that both part-time employee and full-time employee have common properties (e.g. employee number, name, date of birth etc.). 3.4 OOWM OOEM workflow model (OOWM) is an extension of OOEM made by Hui [1997]. Since some new constructs such as activity and business rules are introduced in the workflow constructs, the extension makes the OOEM support for workflow analysis better. Hui believes that every service of an object consists of an ordered set of activities which are governed by business rules defined by an organization, and each activity ends or begins when a request or a response is received. With the concepts of activity and business rules, OOWM is able to show the ordering of activities and the conditions for starting or terminating the activities. Unlike traditional workflow models, the OOWM reflects the object-oriented view of the organizational process OOWM Meta-Model Since OOWM is an extension of OOEM, the basic constructs of OOWM, such as object, attribute, request and service are the same as those of OOEM. After adding the concepts 23

32 of activity and business rule to the OOEM constructs, the meta-model of the OOEM workflow model (in entity relationship diagram) extended by Hui [1997] is shown in figure 3-2. In the OOEM workflow model, it is the activity, instead of a service as in the original OOEM model, accessing at least one attribute and spawning any number of requests. The figure also shows that a service in the OOWM comprises at least one activity and an activity is governed by the business rule. Figure 3-2 OOEM Workflow Model [Hui, 1997] OOWM Constructs OOWM constructs are based on OOEM constructs and workflow concepts. The following table (3-3) shows an object activity template (OAT) in OOWM. OAT provides detailed information about the object, such as the attributes of the object, the services of 24

33 the object, activities the object performs for a service and under what condition the activity will be performed or terminated. If a request is generated when an object is performing an activity, the OAT of the object will show the request with its receiver identified. Object Name Interface Attributes Internal Service Attributes Service 1 Incoming Internal Access Pre Activity Termination Request Receiver interface attributes Mode conditions condition Generated attributes to support Service 1 Pre Termination Request Object condition 1 condition 1 generated receiving from a request Returning Activity activity 1 generated interface 1 from attributes activity 1 Pre Termination Request Object condition 2 condition 2 generated receiving from a request Returning activity 2 generated interface Activity from attributes 2 activity 2 Incoming Internal Access Service 2 interface attribute Mode Pre Activity Termination Request Receiver attributes to support conditions conditions generated service 2 Termination Request Object Pre condition 1 generated receiving condition! from a request Returning activity 1 generated interface Activity 1 from attributes activity 1 Table 3-3 Object Activity Template (adapted from [Hui, 1997]) 25

34 3.4.3 Service vs. Activities A process is composed of activities performed by different objects. When activities of the same object are arranged in a set order, they represent the services provided by that object. In other words, the service of an object is composed of sequential activities that are performed by the object based on certain rules. Therefore, the activities performed by an object can be derived from the OOEM when services are decomposed into activities. When a service begins, the first activity starts and the activity ends when a request is sent out. At that point, another activity may begin as part of a service of another object. The service of the first object (unless finished) resumes when a response to the first request comes. This will start the second activity of the first object, but not the second activity in the process. By following the procedure, we can derive a process model from the OOWM. [I Request! Object B Requests Request3 Response2 r \ Object C Attributel Attribute2 Kgervict?: Figure 3-3 Service vs. Activities 26

35 The relationship between OOWM and the decomposition of service is show in figure 3-3. As shown in the figure, when object B receives request 1 from object A, B performs activity A-bl which ends when request 2 is sent. Request 2 starts activity A-cl of object C and A-cl ends when C sends response 2 to B. After receiving response 2 from object C, object B starts activity A-b2 which ends when request 3 is sent. Similarly, request 3 starts activity A-c2 of object C and A-c2 ends when C sends response 3 to B. Then, after B receives response 3 from C, B performs activity A-b3 which ends when response 1 is sent to object A. By performing A-bl, A-b2 and A-b3, object B provides its service and the three activities (i.e. A-bl, A-b2 and A-b3 in their order) comprise the service provided by object B. In a similar way, object Cs service is decomposed into activities A-cl and A-c Steps in Creating an OOWM The process of creating an OOWM is divided into two steps, "v- The first step is to create an OOEM model based on the rules of OOEM. -v* The second step is to create OAT for an internal object. In this step, we need to: "Y* Obtain organization policies about how a certain process should be carried out; s> Identify services; Break down services into activities with pre-condition and termination condition based on the request/response that is received/sent; -v- Identify the requests generated in each activity and the receiver of the request.

36 3.4.5 Implementation Model of OOWM System The implementation model of the object-oriented workflow management system (OOWMS) enacts the OOWM. As mentioned by Hui [1997], the model identifies the important components of OOWMS architecture and specifies the general functions of the components, given that "the objective of OOWMS is to automate interactions among objects in accordance with workflow business rules". Figure 3-4 depicts the implementation model of OOWMS in an entity relationship model created by Hui [1997]. Figure 3-4 The Implementation Model of OOWMS [Hui, 1997] In the implementation model, a controller is introduced to monitor all controlled requests on the basis of business logic and the state of requests to ensure that the interactions among objects satisfy organizational process. Based on Hui [1997], we summarize the specifications and functionalities of the controller object as follows. A controller object 28

37 will: be used to ensure the business rules are followed in an automated workflow environment; be able to issue requests to other objects to obtain additional information for evaluating business rules; perform actions specified by the business rules after evaluating the rules; -v* take all external requests and process the responses to external requests; -v* not monitor interactions between internal objects. A controller's behavior is defined in the control schema that determines which requests are managed by the controller object. The control schema also tells the controller which workflow business rules are applied to the requests and what actions should be taken by the controller object if the rules are evaluated to be true. The control schema is derived from the policies of the organization 29

38 4. The Use of OOEM to Support IO Process Analysis We propose to use a method called Multi-Organization OOEM (MO-OOEM) to analyze IO processes. MO-OOEM is composed of an object model which is based on the OOEM enterprise model and a workflow model which is based on the OOEM workflow model. Before outlining the details of MO-OOEM, we will first present an overview of MO-OOEM. 4.1 MO-OOEM: An Overview Model Basis MO-OOEM is the method we propose which may be used to analyze the processes which cross multi-organizations. Figure 4-1 shows the building blocks of MO-OOEM and the structure of this method. As shown in the figure, the MO-OOEM is composed of an MO-OOEM object model and an MO-OOEM workflow model. The MO-OOEM object model is based on the OOEM object model [Zhao, 1995] with modifications (e.g. model scope, organization representation etc.) to support multi-organizational modeling, while the MO-OOEM workflow model is based on the OOWM [Hui, 1997] with modifications to support multi-organizational process modeling. 30

39 MO-OOEM MO-OOEM Object Model Specialized OOEM Object Model MO-OOEM Workflow Model Specialized OOWM Supporting IO Process Supporting IO Process OOEM + Supporting IO Features OOWM + Supporting IO Features for Workflow for Object Model Model Supporting IO OOEM Concepts of Supporting IO Features for O-O Ontological Workflow Features for Object Model Constructs Constructs for IS Management Workflow Model Bunge's Ontology Figure 4-1 MO-OOEM Structure Meta Model We extend the meta model as shown in figure 4-2, based on the meta model presented by Tan [1997] and Hui [1997]. In order to model the IO process, we add inter-organization process into our MO-OOEM model and show organizations as composite objects. The organization may be modeled as a decomposed organization with composing objects or as organization object, depending on whether the organization is our focus in the model. In MO-OOEM, we will focus on the IO process instead of the intra-organizational process of a specific organization. 31

40 Figure 4-2 Meta Model of MO-OOEM 4.2 MO-OOEM Object Model for IO Process Although OOEM is a well-defined modeling method for business analysis, we need to set some rules or to modify the original rules of OOEM so that the IO process can be modeled. We first show the graphic representation of MO-OOEM object model and then present some rules for using OOEM to model multi-organization system. Finally, we introduce the steps used to apply the rules to create the MO-OOEM object model Graphic Representation of the MO-OOEM Object Model When modeling a multi-organization system, it is important to provide information about which organization each object belongs to. This is normally not a problem in the internal 32

41 system of an organization, because the whole system belongs to a single organization and any external objects interacting with the system will be called external objects or clients. However, if the system crosses several organizations, there is no default ownership for every object. Therefore, we need to find ways to specify organizational identity. We choose to show organizational identity in the graphic model by using the dashed line oval to represent an organization, with all the objects belong to the organization drawn inside the dashed line oval. Obviously, an organization which is not decomposed does not need a dashed line oval. All other basic graphic representations are the same as those used by Zhao [1995] in the original OOEM. A graphic MO-OOEM model with the dashed line oval representing the organizational identity is shown in figure 4-3. Figure 4-3 MO-OOEM Graphic Model Definitions Before the modeling rules are presented, we define the following terms, which will be 33

42 used subsequently. Y* Target organizations: These are the organizations the modeler will focus on in the model. The target organizations can normally be determined or defined by the application domain. For example, if the purpose of a model is to analyze ABC company's procurement process, ABC company will quite likely be one of our target organizations. Across target organization interaction: This refers to the interaction among target organizations or the interaction between the target organization and other organizations, direct or indirect. Y* IO process: IO process is a process with components or steps performed by objects from at least two organizations. The event which triggers a process is not considered a component of the process. The reason we do not include the event step as part of the process is that every external event is generated by an organization other than the one reacting to the event. If we include it as a component of the process, every external event will trigger an IO process because the process will have components in at least two organizations, i.e. the triggering one and the reacting one. This is not always what we want to analyze. For example, when a customer requests certain information from a company, the company processes the request internally and answers it. This process is not an IO process, because we do not consider the request performed by (an object of) another organization (i.e. customer) a component of the process. Y- Sub-process: This is the process that is enacted or called from another (initiating) 34

43 process (or sub-process), and which forms part of the overall process. Across target organization IO process: The across target organization IO process is the process which has acrossed target organization interactions. In other words, an across target IO process is a process which either crosses at least two target organizations or crosses at least one target organization and at least one non-target organization Rules for MO-OOEM Object Model Rule #1 Target organization rule A model includes the target organizations which are the focus parts of a cross organization model. According to this rule, there must be some target organizations in every MO-OOEM model. We will only pay attention to those processes which have at least one step related to any of the target organizations. Other processes which may cross different organizations but are not related to target organizations will not be considered. The reason for including target organizations is to limit the scope and complexity of the final model. Since every organization may have its own partnership or network, if we do not restrict the target, the model will end up with a map without boundaries. Rule #2 Sub-process rule If a sub-process is outside the target organization, only certain sub-processes triggered (or 35

44 called) by the across target organization process will be traced in the model. If the sub-process is within the target organizations, the sub-process will always be traced. The purpose of this rule is to avoid including infinite lop of process and unnecessary sub-processes into the model. Which sub-processes (outside the target organization) are to be traced will be determined by the application domain. For example, as shown in figure 4-4, an IO process goes through companies A, B, C and D. At B, sub-process Ll-1 is triggered, and Ll-1 has another sub-process, L2-1. Similarly, at C, two sub-processes (LI-2 and L2-2) are triggered. We cannot trace all the sub-processes in our model, as we must focus on the target and avoid making our model too complicated. If we determine to trace the sub-process LI-2 but not L2-2, then, according to this rule, we will trace Ll-1, L2-1 and LI-2, but not L

45 A I 10 Pre cess (TargetJ lqf& &-^> C I 10Process Legend Main Process Sub-process Organization Figure 4-4 Sub-processes Rule #3 Scope rule The scope of the system should cover all and only those aspects needed to represent the effects of the relevant external events which trigger direct or indirect across target organization 10 processes. If there are sub-processes in the initial 10 process, the sub-process rule will apply. This rule is an extension of the original OOEM scope rule. When applying the original rule, we can determine whether a relevant event is "external" before the scope of system is defined because there is a default maximum boundary of the system to be modeled (as shown in figure 4-5). This default maximum scope is normally the organization's boundary, but if we want to analyze an 10 process, we cannot assume our maximum scope 37

46 is the boundary of the organization. It will be difficult for us to know the scope of our model before we actually analyze the IO processes. It is for this reason in original OOEM, that we start from the default maximum boundary of the system and end up with a sub-set of the (organizational) maximum scope. In contrast, when using OOEM to model IO process, we start from the event which triggers the across target organizations IO processes and follow those processes to get a final scope which might be larger than the target organizations (as shown in figure 4-6). Furthermore, according to this rule, if there are sub-processes in the initial IO process, only the initial IO process and certain sub-process will be considered. Finally, this rule fans out the internal processes of an organization so that the analyst can focus on the IO processes. These two restrictions of the rule are also aimed at preventing the scope from becoming unnecessarily large.. * Default Maximum Scope Figure 4-5 The Default Maximum Scope 38

47 Figure 4-6 Target vs. Actual Scope For example, a customer's request to buy products from a retailer may trigger the ordering process from the retailer to the distribution center, from the distribution center to the manufacturer, and further from the manufacturer to the supplier etc. If the manufacturer and the supplier are our target organizations, the final scope may cover the manufacturer, the distribution center, and the supplier etc. However, if our target organizations are the manufacturer and the supplier, when an event triggers a process between the retailer and the bank, we would not include this part in our system because this IO process does not cross any target organization. Rule #4 Integrity rule (1) Every IO request should be traced back to an external triggering event (request). (2) Every internal request in a decomposed organization should be traced back to an IO 39