UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Application of OOEM : an industrial case study Yeap, Soon Aun 1996

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1996-0113.pdf [ 4.54MB ]
Metadata
JSON: 831-1.0087062.json
JSON-LD: 831-1.0087062-ld.json
RDF/XML (Pretty): 831-1.0087062-rdf.xml
RDF/JSON: 831-1.0087062-rdf.json
Turtle: 831-1.0087062-turtle.txt
N-Triples: 831-1.0087062-rdf-ntriples.txt
Original Record: 831-1.0087062-source.json
Full Text
831-1.0087062-fulltext.txt
Citation
831-1.0087062.ris

Full Text

A P P L I C A T I O N OF O O E M : A N I N D U S T R I A L C A S E S T U D Y by SOON A U N Y E A P B.Sc. (Honours), Trent University, 1993 A THESIS SUBMITTED IN PARTIAL F U L F I L L M E N T OF THE REQUIREMENTS FOR THE DEGREE OF M A S T E R OF SCIENCE IN BUSINESS ADMINISTRATION in THE F A C U L T Y OF C O M M E R C E A N D BUSINESS ADMINISTRATION (Management Information Systems Program) We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH C O L U M B I A January 1996 ©Soon AunYeap, 1996 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. ©epaffimea&sL The University of British Columbia Vancouver, Canada Date P W . DE-6 (2/88) ABSTRACT This thesis takes an industrial-based case and uses several modeling methods to model the organization and its business processes. The objective of this thesis is to apply the rule-based Object-Oriented Enterprise Modeling (OOEM) methodology developed by Wand and Woo as an enterprise and process modeling methodology, and to com-pare the OOEM models against two other modeling techniques: the Integrated Definition (IDEFO) technique and Jacobson's object-ori-ented approach to business modeling. The case analysis reveals that the OOEM method has advantages in modeling an enterprise and in communicating information about business processes. TABLE OF CONTENTS LIST OF TABLES vii LIST OF FIGURES ix CHAPTER 1 INTRODUCTION 1 1.1 MOTIVATION 1 1.2 BACKGROUND 3 1.3 RESEARCH QUESTIONS 5 1.4 ORGANIZATION 6 CHAPTER 2 FOUNDATION 7 2.1 ENTERPRISE MODELING 7 2.2 PROCESS MODELING TECHNIQUE 8 2.2.1 Introduction 8 Application of O O E M : An Industrial Case Study Contents 2.2.2 Conceptual Framework 9 2.2.3 IDEFO: An Example of PMT 12 2.2.3.1 Background 12 2.2.3.2 Objectives & Applicability 13 2.2.3.3 Model Concepts 15 2 . 3 O B J E C T - O R I E N T E D ENTERPRISE M O D E L I N G 1 6 2.3.1 Introduction 16 2.3.2 Theory 17 2.3.2.1 Modeling Principles 18 2.3.2.2 Ontological Concepts 20 2.3.2.3 Properties of Object 23 2.3.2.4 Implications 24 2.3.2.5 Rule-Based Model Building 25 C H A P T E R 3 A N INDUSTRIAL CASE 2 7 3.1 I N T R O D U C T I O N 2 7 3.1.1 The Company 28 3.1.2 Business Environment 32 3.1.3 The Business 34 3.1.4 IS Infrastructure 37 3.1.4.1 Hardware 37 3.1.4.2 Systems 39 3 .2 BUSINESS PROCESSES 4 1 3.2.1 B R A N C H ORGANIZATION & O P E R A T I O N 42 3.2.2 T H E S E R V I C E REPAIR P R O C E S S 44 3.2.2.1 An Overview 44 3.2.2.2 Tracking WIP 47 3 .3 K E Y ISSUES 5 0 3.3.1 IS Infrastructure 50 3.3.1.1 Hardware 50 3.3.1.2 Systems 51 3.3.2 The Service Repair Model 51 3 .4 C A S E A N A L Y S I S 5 2 Application of OOEM: An Industrial Case Study iv Contents 3.4.1 Process Analysis 52 C H A P T E R 4 O O E M & IDEFO MODELING 5 6 4.1 OOEM MODELING 5 6 4.1.1 Notational Representation 57 4.1.1.1 Object Communication Diagram 58 4.1.1.2 Object Templates 59 4.1.1.3 Internal Object Template (IOT) 61 4.1.1.4 External Object Template (EOT) 62 4.1.2 O O E M Model of DDA B C 64 4.1.3 O O E M Model of the Service Repair Process 67 4 . 2 IDEFO MODELING 7 3 4.2.1 IDEFO Model Building 73 4.2.2 High-Level Reference Description 74 4.2.3 Context Descriptions 76 4.2.4 IDEFO Model of the Service Repair Process 78 C H A P T E R 5 COMPARATIVE ANALYSIS OF O O E M 8 4 5.1 COMPARISON OF OOEM WITH IDEFO 8 5 5.1.1 Separability of Process & Functional Information 85 5.1.2 Request Semantics 87 5.1.3 Scope of Model 91 5.1.4 Model Efficiency 92 5.1.5 Level of Information Representation 93 5.1.6 Other Observations 94 5.1.7 Summary of Comparison With IDEFO 98 5.2 A N OBJECT-ORIENTED COMPARISON 1 0 1 5.2.1 Overview of Jacobson's Object-Oriented Approach 101 5.2.2 Comparative Analysis with Jacobson's Approach 104 5.2.2.1 Model Constructs 104 5 .3 SUMMARY 1 1 0 Application of OOEM: An Industrial Case Study v Contents CHAPTER 6 C O N C L U S I O N 112 6.1 CONTRIBUTION 116 6.2 LIMITATIONS AND FUTURE RESEARCH 116 B I B L I O G R A P H Y 118 APPENDIX A O O E M M O D E L OF S E R V I C E R E P A I R A C C O U N T I N G 121 A.1 OBJECT COMMUNICATION DIAGRAM 122 A.2 INTERNAL OBJECT TEMPLATES 123 A.3 EXTERNAL OBJECT TEMPLATES 124 Application of OOEM: An Industrial Case Study VI LIST OF TABLES TABLE 1 Estimated Revenue by Industry & Services for 1994 35 TABLE 2 Internal Object Representation: Internal Object Template (IOT) 60 TABLE 3 External Object Representation: External Object Tem-plate (EOT) 60 TABLE 4 Internal Object Template (IOT) o f D D A B C Object 65 TABLE 5 External Object Template (EOT) of Customer Object 66 TABLE 6 External Object Template (EOT) of Supplier Object 66 TABLE 7 External Object Template (EOT) of Financial Institution Object 66 TABLE 8 Internal Object Template (IOT) of Service Chargehand Object 70 TABLE 9 Internal Object Template (IOT) of Service Admin Object 70 TABLE 10 Internal Object Template (IOT) of Inventory Control Object 71 TABLE 11 Internal Object Template (IOT) of Service Floor Object 71 TABLE 12 Internal Object Template (IOT) of Accounts Receivable Object 71 Application of OOEM: An Industrial Case Study vii Contents TABLE 13 Internal Object Template (IOT) of Remanufacturing Object 72 TABLE 14 External Object Template (EOT) of Customer Object 72 TABLE 15 External Object Template (EOT) of Supplier Object 72 TABLE 16 Comparative Characteristics of OOEM and IDEFO 9 9 TABLE 17 Construct Mappings Between OOEM and Jacobson 108 Application of OOEM: An Industrial Case Study viii LIST OF FIGURES FIGURE 1 Location o f D D A B C ' s Branches in British Columbia 29 FIGURE 2 High-Level Organizational Chart 30 FIGURE 3 Revenue Composition by (a) Service Type, (b) Industry Base 35 FIGURE 4 Hardware Topology 38 FIGURE 5 Workflow Linkages Among Application Packages 40 FIGURE 6 Organizational Structure of a Service Repair Branch 43 FIGURE 7 Activity-Workflow Description of the Service Repair Process 45 FIGURE 8 A Redesigned View of the Service Repair Process 54 FIGURE 9 An OOEM Object Communication Diagram 59 FIGURE 10 OOEM Object Communication Diagram: Request Propa-gation Analysis o f 'DDA B C ' 64 FIGURE 11 OOEM Object Communication Diagram: Request Propa-gation Analysis of 'Service Repair Process' 69 FIGURE 12 Node Index for Service Repair 75 FIGURE 13 Node Tree for Service Repair 76 FIGURE 14 Syntax of a Function 77 FIGURE 15 Top-Level IDEFO Context Diagram for AO: Service Application of OOEM: An Industrial Case Study ix Contents Repair 80 FIGURE 16 IDEFO Context Diagram for A l : Provide Pricing Information 81 FIGURE 17 IDEFO Context Diagram for A3: Repair Product 82 FIGURE 18 IDEFO Context Diagram for A32: Pick Inventory 83 FIGURE 19 Analysis of Request Semantics 89 FIGURE 20 Service Chargehand and Its Associated Requests 95 FIGURE 21 Inventory Control and Its Associated Requests 96 Application of OOEM: An Industrial Case Study x DEDICATION I would like to take this opportunity to thank first of all, my thesis supervisor, Professor Yair Wand, for his persistence and his patience in seeing me through this journey, but most of all, for his ever insightful feedback whenever I thought I have reached the end of a dead tunnel. The same gratitude goes out to my committee member, Professor Car-son Woo, for extricating me from my confusion and for helping me to see the light at the end of the same tunnel. No less is my gratitude for Professor Dean Uyeno for his help. I am also indebted to Mr. Allan Cullen, president of Detroit Diesel-Allison BC, for the opportunity to work with him, his management team and his staff. Last but not least, I dedicate this thesis to my wife for putting up with my incessant (and no doubt annoying) grumblings, for her love, and for just being there for me. INTRODUCTION 1.1 MOTIVATION This thesis is motivated primarily by the desire to apply an object-ori-ented method within an industrial setting, and in the process, to assess the usefulness of the object-oriented method in modeling an organiza-tion. The object-oriented method discussed in this thesis is the Object-Oriented Enterprise Modeling (OOEM) method proposed by Wand and Woo [31]. As with many object-oriented methods, OOEM is broadly based on the Object-Oriented Analysis (OOA) approach. How-ever, OOEM is unique in its rule-driven methodology to modeling. As such, this thesis seeks to examine the value of this departure in method-ology in modeling an organization. The opportunity to apply and assess OOEM was offered by the project carried out at Detroit Diesel-Allison B.C. (DDA BC). The objective of this project was twofold: Application of OOEM: An Industrial Case Study 1 MOTIVATION 1. To perform a high-level review of DDA BC's existing business pro-cesses and to identify potential areas for improvement, and 2. To review the existing information systems (IS) infrastructure and to identify and evaluate potential IS solutions that can be adopted. These objectives are formulated in consultation with the president of DDA BC and take advantage of recent advances in information tech-nology (IT) that could be deployed to give DDA BC a sustainable com-petitive advantage. At the same time, this project gives DDA BC the opportunity to retire its existing decade-old IS infrastructure. This review is also an opportunity to evaluate the current business practices and operating activities. Furthermore, DDA BC's management views this review as an opportunity to put the company through the ISO 9001 certification process. Although the existing operating procedures and IS infrastructure are perceived by DDA BC's management to be fairly adequate, it also rec-ognizes that significant improvements and savings can be effected through business process reengineering (BPR) with the deployment of IT as a facilitator. In order to assess DDA BC's needs and to propose alternative solu-tions, one must have a broad understanding of DDA BC's business and operating environments. The process of modeling the company to gain this understanding requires a method that is adequately comprehensive in producing concise and unambiguous documentation about the busi-ness processes. The evaluation and application of one such method Application of OOEM: An Industrial Case Study 2 BACKGROUND offers the opportunity to apply OOEM, for the first time, in an indus-trial setting. In addition to the case-based approach to evaluating OOEM, a high-level comparative analysis against the Integrated Definition (IDEFO) standard is undertaken to gain a better perspective of OOEM as a pro-cess modeling methodology. A comparison of OOEM is also made against Jacobson's [15] object-oriented approach to business modeling. 1.2 BACKGROUND A survey of the current IS research and professional literature reveals various methodologies that are relevant as enterprise modeling meth-odologies. Foremost is the traditional approach by way of data model-ing techniques and structured analysis attributed to Yourdon [33]. While structured analysis has been useful in planning and documenting an organization's management of information, it is effective only when applied in conjunction with more traditional data-centric concepts and with hierarchically structured organizations. These techniques hold the view that data modeling is analogous to modeling an organization since an information system is supposedly a representative abstraction of an organization. This thesis takes the view that the traditional data-centric modeling approach to enterprise and process modeling is inappropriate given the structural transformation that organizations have been undergoing in Application of OOEM: An Industrial Case Study 3 BACKGROUND the name of quality improvement programs (such as BPR). Structural transformation can be supported by recent advances in IT. Common instances of technological influence include client/server, relational and distributed data base architectures. This observation is borne out in the course of the project with DDA BC. More importantly, Coad and Yourdon [4] have pointed out the inadequacy of structural analysis as an organization modeling method. The need to model an organization effectively and efficiently for pro-cess and IS planning and for defining user and systems requirements, therefore, requires new modeling methodologies that depart from the data-centric view of structural analysis. One such candidate is the OOEM modeling method developed by Wand and Woo [31]. This methodology, while not as mature as tradi-tional structured analysis techniques, distinguishes itself from the data-centric paradigm, and more importantly, from other OOA methods through its rule-based approach. Wand and Woo assert that the OOEM method can provide a better defined approach to building an object-ori-ented model of an organization than other OOA methods discussed in the literature. Another type of method that is discussed in this thesis is known by the generic name process modeling technique (PMT). PMT refers to a group of modeling methods applied to the modeling of a system of pro-cesses generally rather than business processes specifically. PMT includes petri-net, system dynamics, and the IDEFO modeling tech-Application of OOEM: An Industrial Case Study 4 RESEARCH QUESTIONS niques. It is against the IDEFO, Jacobson's object-oriented approach and the OOEM methods that the case analysis will be focused on. 1.3 RESEARCH QUESTIONS The DDA BC project raises several fundamental questions regarding object-oriented modeling, but specifically, about OOEM in relation to organizational process modeling in light of BPR and IS planning. The issues are summed up by the following questions: 1. Can OOEM be applied as an process modeling methodology? 2. Must OOEM be applied concurrently with other modeling tech-niques as an process modeling methodology? These questions are posed in an attempt to ascertain the appropriate-ness and value of using OOEM as a modeling methodology both at the organizational level, i.e., enterprise modeling, and at the systems plan-ning ievel, i.e., process modeling. The experience gained from the DDA BC project offers some qualitative insights into these questions in an industrial setting. Such insights may contribute to a better under-standing of OOEM as a modeling methodology and to its potential application in other industries and organizational settings. Application of OOEM: An Industrial Case Study 5 ORGANIZATION 1.4 ORGANIZATION The remainder of this thesis is organized into five chapters in the fol-lowing order: literature survey, case presentation, description of mod-els, analysis, conclusion, bibliography, and appendices. Chapter 2 presents a survey of the literature on enterprise modeling, process mod-eling techniques, and OOEM. Chapter 3 presents the facts and analyses of the case study carried out at DDA BC. Chapter 4 delves into the modeling of DDA BC using OOEM and IDEFO, while Chapter 5 dis-cusses the issues in using OOEM as an enterprise modeling methodol-ogy within the context of the industrial case. Conclusion is followed by a bibliography of the surveyed literature and one appendix chapter detailing supporting information for the thesis and information gleaned from the case study is included thereafter. Application of OOEM: An Industrial Case Study 6 FOUNDATION 2.1 ENTERPRISE MODELING Prior to the development of an IS plan, or in the course of a BPR endeavour, information about the organization must be collected and systematically documented to present a coherent picture of the organi-zation's structure, needs, and future direction. In other words, the orga-nization must be modeled. This process of documenting an organization has been accorded numerous names, including: structured analysis [33], systems analysis [20][27], organizational modeling [10], and enterprise modeling [16][22]. Structured analysis is commonly identified with conceptual modeling and information modeling, such as data flow and data relationships, while systems analysis takes its roots from the engineering discipline, focusing instead on the process per-spective of a system. Organizational modeling has been linked in some Application of OOEM: An Industrial Case Study 7 PROCESS MODELING TECHNIQUE respects to both structured and systems analysis as well as decision modeling [13]. Enterprise modeling is generally recognized as being analogous to business modeling [5][8][16][32], that is, the modeling of business pro-cesses. Enterprise modeling can thus be viewed as the high-level mod-eling of business processes, i.e., modeling at the enterprise level. However, enterprise modeling in the IS literature tends to allude mod-eling activities to IS process modeling [5], and in instances when refer-ences are made to business process modeling, it is both at the high and low levels of an organization [8][16]. It is this latter perspective of enterprise modeling through the various levels of an organizational hierarchy that is adopted for the purpose of this thesis. 2.2 P R O C E S S M O D E L I N G T E C H N I Q U E 2.2.1 Introduction Process modeling distinguishes itself from other IS modeling tech-niques such as structured analysis and entity-relationship diagram-ming. Instead of focusing merely on the flow and transformation of data, or the users' behaviour at the interface, process modeling seeks also to model the "interacting behaviours among agents" [5] in a domain. This perspective recognizes that the effective deployment and usage of IS are increasingly less dependent on the data-centric model of organizational modeling. Instead, information not traditionally iden-Application of OOEM: An Industrial Case Study 8 PROCESS MODELING TECHNIQUE tified as systems-related, such as process input and output, is taking on new roles. This shift in thinking about IS parallels an organizational paradigm shift [9][11][19][28]. Curtis, Kellner, and Over's [5] paper on process modeling provides a survey on process modeling [2][18][21]. The methodology of process modeling is presented in the context of software process modeling that has been extended into other disciplines. Although this extension can be attributed to an expanding deployment of IT, the phenomenon can also easily be reasoned as the need to model a more diversified domain. Curtis et al. [5] point to three such domains of application: BPR, coor-dination technology, and process-driven software development. Litera-ture references to the process modeling paradigm for discussion purposes will only be focused on BPR-related issues. The next two subsections describe the conceptual framework of process modeling and the IDEFO method as an example of a process modeling technique. 2.2.2 Conceptual Framework The basis for the process modeling conceptual framework draws heavily on the conceptual framework for software process modeling and its definition [5]. Under this framework, a process is defined as "a set of partially ordered steps intended to reach a goal," while a process element refers to a component of a process and a process step refers to "an atomic action of a process that has no externally visible substruc-ture." Whether an element's structure must be further broken down to Application of OOEM: An Industrial Case Study 9 PROCESS MODELING TECHNIQUE support the process model objectives determines whether a process ele-ment is a process step. Although Curtis et al. [5] noted that the constructs of a process model are clearly defined in the literature, they identified some of the most frequently referenced ones as follows: Agent — refers to an actor, who is either a machine or a human, that performs a process element. Role — refers to a coherent set of process elements that is to be assigned as a functional unit of responsibility to an agent. Artifact — refers to the creation or modification of a product as a result of the enactment of a process element. Note that a single agent is capable of performing multiple roles and that a single role may be performed by multiple agents. Thus, a process can be further elaborated as "one or more agents acting in defined roles to enact the process steps that collectively accomplish the goals for which the process was designed." [5] That is, a process model is a descriptive abstraction of an actual or proposed process representing certain pro-cess elements considered to be important to the model's purpose. Such a model must also be enactable by a machine or human. A key notion in process modeling is the concept of perspective. The emphasis placed on the constructs of a process model determines how the basic questions are to be answered by a process model. That is, the Application of OOEM: An Industrial Case Study 10 PROCESS MODELING TECHNIQUE various levels of emphasis placed on different constructs defines the perspective of a process model. Curtis et al. [5] and Wang [32] describe four of the most commonly represented perspectives in the literature as follows: 1. The functional perspective represents the flow of informational entities that are relevant to the process elements as well as the pro-cess elements that are being performed. 2. The behavioural perspective models information regarding the "when" and "how" process elements are performed. Examples of methods could be feedback loops, iteration, and entry and exit crite-ria. 3. The organizational perspective models information about "where" and "by whom" tasks are performed, i.e., which agents and process elements are performed in an organization. 4. The informational perspective represents the informational entities that are produced and manipulated by a process. Entities may include artifacts, data, intermediate and end products as well as objects. This perspective models both the structure of and the rela-tionship among informational entities. These perspectives are distinct yet are interrelated representations for the purpose of presenting and analyzing process information. This notion of perspective is similar to that of an observable process being viewed from different vantage points. Taken together, the different per-spectives should form a complete, integrated, and consistent model of the process being analyzed. Hence, an enterprise or business process modeling method (or tool) must be capable of describing the four per-spectives outlined above. Application of OOEM: An Industrial Case Study 11 PROCESS MODELING TECHNIQUE Davenport [6][7] defines a similar view, albeit a more "applied" and narrower one, of business processes based on the above concepts as follows: ... a set of logically related tasks performed to achieve a defined business outcome and: The logical organization of people, materials, energy, equip-ment, and procedures into work activities designed to produced a specified end result (work product). Section 2.2.3 below presents a high-level description of one process modeling technique, IDEF. 2.2.3 IDEFO: A n Example of PMT 2.2.3.1 Background Work on the IDEF standards began in the 1970s in the U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM) to develop better analysis and communication techniques that would improve manufacturing productivity. The ICAM program spawned a series of process modeling techniques known as IDEF, three of which are listed as follows [19][29]: 1. IDEFO — a technique used to produce a function model. That is, a structured representation of the activities, functions, or processes within a modeled subject area or system. Application of OOEM: An Industrial Case Study 12 PROCESS MODELING TECHNIQUE 2. IDEF1 — a technique used to produce an information model. That is, a representation of the structure and semantics of information within the modeled subject area or system. 3. IDEF2 — a technique used to produce a dynamic model which rep-resents the time-varying behavioral characteristics of the modeled subject area or system. IDEF1 was further enhanced in 1983 through the U.S. Air Force Inte-grated Information Support System program to form the IDEF1 Extended (IDEF1X) standard, a technique that supports semantic data modeling. In 1992, The National Institute of Standards (NIST), at the behest of the Department of Defence, reviewed and issued two Federal Informa-tion Processing Standards (FIPS) publications for modeling techniques based on the IDEFO [27] and IDEF1X [19][29] techniques. The stan-dards were published at the end of 1993 and were designated as fol-lows: IDEFO was assigned as FIPS Publication 183 and IDEF1X was assigned as FIPS Publication 184. Since the IDEFO technique is more relevant to this thesis, further discussion of the IDEF standards will focus solely on the former technique. 2.2.3.2 Objectives & Applicability The publication of the IDEFO standard was guided by the following primary objectives as stated in FIPS Publication 183 [27]: 1. To provide a means for consistently and completely modeling the functions (activities, actions, processes, operations) required by a Application of OOEM: An Industrial Case Study 13 PROCESS MODELING TECHNIQUE system or enterprise and the functional relationships and data (infor-mation or objects) that support the integration of those functions. 2. To provide a modeling technique which is independent of Com-puter-Aided Software Engineering (CASE) methods or tools, but which can be used in conjunction with those methods or tools. 3. To provide a modeling technique that possesses the following char-acteristics: • Generic — for the analysis of systems of various purposes, scopes, and complexity. • Rigorous and precise — for producing correct and usable mod-els without imposing constraints on the analyst. • Concise — to facilitate understanding, communication, consen-sus, and validation (through model documentation). • Conceptual — to represent functional requirements rather than physical or organizational implementations. The IDEFO tech-nique provides for the separation of organization from function, ensuring the avoidance of organizational viewpoints during model development. • Flexible — to support the various phases of the life cycle of a project. The IDEFO technique has been widely applied in diverse modeling efforts in the government, industrial and commercial sectors. The pub-lication also identified the following enterprise and application devel-opment projects that could benefit from the IDEFO technique: 1. Those that require a modeling technique for the analysis, develop-ment, reengineering, integration, or acquisition of information sys-tems. 2. Those that involve the incorporation of a system or enterprise mod-eling technique into a business process analysis or software engi-neering methodology. Application of OOEM: An Industrial Case Study 14 PROCESS MODELING TECHNIQUE The latter recommendation points to the relevancy of IDEFO as an enterprise modeling technique, and hence, encourages a comparative analysis of IDEFO with other enterprise modeling methods. 2.2.3.3 Model Concepts IDEFO as a modeling technique is defined in FIPS Publication 183 [27] as follows: IDEFO is a modeling technique based on combined graphics and text that are presented in an organized and systematic way to gain understanding, support analysis, provide logic for potential changes, specify requirements, or support systems level design and integration activities. An IDEFO model is made up of a series of diagrams that display increasing levels of detail which describe functions and their interfaces in the context of a system. There are three types of diagrams: graphic, text, and glossary. Functions and functional relationships are defined through the use of box and arrow syntax and semantics. Additional information supporting graphic diagrams takes the form of text and glossary. IDEFO is "an engineering technique for performing and managing needs analysis, benefits analysis, requirements definition, functional analysis, systems design, maintenance, and baselines for continuous improvement." [27] When applied in a systematic fashion, the IDEFO technique provides the framework of a systems engineering approach to performing systems analysis and design. In other words, IDEFO can Application of OOEM: An Industrial Case Study 15 OBJECT-ORIENTED ENTERPRISE MODELING be used for systems with people, machines, materials, computers, and all sorts of information, i.e., for the entire enterprise, system, or subject domain. The documentation generated from the IDEFO techniques serves as a reference point for communication among project partici-pants. More importantly, perhaps, is that the IDEFO technique also pro-vides the framework to manage large and complex projects through qualitative measures of progress, and a reference architecture for enter-prise analysis, information engineering, and resource management [19][27]. 2.3 OBJECT-ORIENTED ENTERPRISE MODELING 2.3.1 Introduction In the object-oriented school of thought, OOA has evolved and has been vigorously touted as the answer to many IS ills and, increasingly, to business problems as well. In spite of this trend, the application of OOA has caused much agony to its proponents and practitioners due to its ambiguity. Specifically, there is no standard methodology for apply-ing object-oriented concepts to model building in the literature. The absence of a standard is especially noteworthy given the increasing adaptation of the object-oriented paradigm to process modeling [5][14][18][32] and IS analysis [9][12][31]. After all, both essentially entail the building of enterprise or conceptual models [31] of the domain in question. It is the modeling activity in the absence of distinct Application of OOEM: An Industrial Case Study 16 OBJECT-ORIENTED ENTERPRISE MODELING rules on the identification and application of objects in constructing models that OOEM seeks to address. The absence of a common underlying paradigm is exemplified by Coad and Yourdon's [4] instruction on identifying objects: To find potential Class-&-Objects, look for: structure, other systems, devices, things or events remembered, roles played, operational procedures, sites, and organizational units and by the definition offered by Rumbaugh et al. [26]: ... define an object as a concept, abstraction, or thing with crisp boundaries and meaningful for the problem at hand. Decomposition of a problem into objects depends on judge-ment and the nature of the problem. There is no one correct representation. In view of such subjectiveness and ambiguity in identifying an object, and within the confines of a domain that should be modeled, Wand and Woo [31] proposed a set of modeling rules derived from ontological principles. The following subsection presents a survey of the concepts and framework behind the OOEM methodology formulated by Wand . and Woo. 2.3.2 Theory The OOEM methodology developed by Wand and Woo [31] is based on an ontological approach, i.e., the rules governing the methodology "are based on assumptions regarding the nature of the modelled Application of OOEM: An Industrial Case Study 17 OBJECT-ORIENTED ENTERPRISE MODELING domains." As well, the rules are also dependent on a well-defined model of object, a model that is characterized by its independence from implementation and from specific systems analysis methodologies. The following two subsections describe the modeling principles and the constructs of an OOEM model respectively. 2.3.2.1 Modeling Principles The OOEM methodology developed by Wand and Woo [31] is based upon six fundamental assumptions, the first four of which are indepen-dent of any modeling constructs. The concept of object is integrated in the fifth principle through an object-oriented modeling assumption, while the sixth establishes the principle in defining the practical bound-ary of the domain being modeled. The following details the six funda-mental OOEM modeling principles as formulated by Wand and Woo: Principle 1 The regular activities of an organization include the informa-tion processing activities. The implication of Principle 1 is that activities relating to the genera-tion of services and activities related to information processing as well as the actual processing of commodities should be included in an enter-prise model. In contrast, structured analysis focuses only on informa-tion processing activities [31]. Application of OOEM: An Industrial Case Study 18 OBJECT-ORIENTED ENTERPRISE MODELING Principle 2 An information system is a representation of another system. This assumption establishes information processing not in terms of technical references to data and its processing as a modeling guideline, but in terms of meanings. An example is the shift in focus away from the data processing of inventory to that of the state of the inventory and the accompanying events that affect its state. A contrast is the data-cen-tric paradigm of data flow where instances of data stores and flows may not have direct mappings onto the domain being modeled. Principle 3 The components of a modeled system are clearly defined. This principle ensures that entities, processes, activities, and actors [31] within a model are clearly distinguished. As well, any communi-cation or interaction between independent components is manifested through the exchange of stimuli [31]. Principle 4 It is the external stimuli that an organization system responds to that define its purpose. This implies that external stimuli are the cause of all actions in a sys-tem. Application of OOEM: An Industrial Case Study 19 OBJECT-ORIENTED ENTERPRISE MODELING Principle 5 Every thing and every organizational component that interacts with a system can be modeled as an object. Furthermore, a common extension of this concept is that an object pos-sesses a state, and that this state may be modified through its own actions taken in response to requests from other objects, i.e., external stimuli. Principle 6 The modeling of a system should include those aspects of the domain which are directly relevant to the purpose of the mod-eling endeavour. The notion of purpose is manifested through the external stimuli referred to in Principle 4. The bounds of a model can also be viewed as including only those components that either request or respond to requests of things in the modeled domain. 2.3.2.2 Ontological Concepts The six fundamental modeling principles are accompanied by a set of ontological concepts and assumptions adapted for IS analysis [30]. Together, they provide the framework under which the rules governing OOEM methodology is defined. The following paragraphs describe the key concepts of 1) the ontological model that are necessary in formu-lating object characteristics, and 2) the OOEM rules. Application of OOEM: An Industrial Case Study 20 OBJECT-ORIENTED ENTERPRISE MODELING 1. Things and Properties • The world consists of things that possess properties. These prop-erties are either intrinsic or mutual to several things. Things can be simple or associated together to form composite things. A property that is possessed by a composite thing and at least one of its components, i.e., simple things, is known as an inherited property. • Attributes of things are assigned by humans, but a thing may possess properties of which humans are unaware. Al l properties can be modeled as attributes but not every attribute describes a property. • A function can be used to describe an attribute through a set of values derived from a set of things and from a set of observations at specific points in time. • Laws are properties in themselves, and they constrain and relate to the properties of things. Laws can also be expressed as func-tions similar to any property. • Such a functional representation of attributes forms the basis for defining a model of a thing as a functional schema. A functional schema describes a set of attribute functions in a particular domain, M, which is usually time, and one functional schema can model similar things. A functional schema represents and describes a view of a set of similar things. This is the case because only those properties that an observer is interested in for a specific purpose are defined through the attribute functions in the schema. • At a given point M, the values of the functions in the functional schema is the state of a thing. The possible combinations of state function values is constrained by laws, i.e., all the possible com-binations do not necessarily represent valid states of things. Having described the characteristics of things and properties, the fol-lowing paragraphs describe the dynamics of things based on ontologi-cal principles. Application of OOEM: An Industrial Case Study 21 OBJECT-ORIENTED ENTERPRISE MODELING 2. Dynamics • Every thing changes, and every change is a change of things. The implication then becomes: every change is associated with a change in the properties of thing(s). Changes can also be mod-eled as state transitions, which are formalized as events. Events themselves can be described as a triplet, that is: <sl, s2, g>, where si and s2 are respectively states prior to and following a transition, and g describes the transformation in changing the state from si to s2. The laws governing a thing is described through the transformation, g. • The states that a thing traverses can be affected by another thing. Interaction occurs if and only if one thing acts on another, and ontology dictates that "action at a distance" is not possible. That is, the state of a thing can be influenced by another thing only if a mutual property exists between them. Given that properties are modeled by state variables, it would mean that mutual properties, and hence, interactions, can likewise be modeled through joint state variables. • The change in the state of a thing can be the result of the trans-formation from within the thing or from other things. The former is known as an internal event, while the latter is termed an external event. The premise is that the existence of an internal event is an indication that transition will transpire, and the existence of such a transition is called an unstable state. The absence of an internal transition is a stable state, i.e., only an external event can cause a thing to change its state from a stable state. • The evolution of the state of a thing is its behavior. • Stability is a characteristic of things that reach a stable state after an external event. A sub-class of such things are well-behaved things, i.e., things which, for every unstable state as a consequence of one external event, result in exactly one stable state. Application of OOEM: An Industrial Case Study 22 OBJECT-ORIENTED ENTERPRISE MODELING Based on the above ontological principles and modeling concepts, the four main characteristics of the OOEM object model are described below. 2.3.2.3 Propert ies of Object The four characteristics of the model object are encapsulation, compo-sition, classification, and communication/interaction. The notions behind these object characteristics are described in greater detail in the following paragraphs. Encapsulation An object possesses a state and has the ability to undergo state changes or transitions. Attributes are state variables and actions, or services, are possible state transitions. The attributes and actions together constitute the properties of objects. The interface of an object is the state variable which other objects are able to modify. Besides the interface, attributes can be modified only by those actions belonging to the object itself. Objects that possess only interface attributes are static objects. Composition Composite objects can be formed from the combination of two or more objects. Composite objects possess emergent properties which can be attributes or actions. Such emergent properties are not exhibited by the component objects. Classification A class is a group of objects that possesses the same set of properties, or more formally, things modeled through similar func-Application of OOEM: An Industrial Case Study 23 OBJECT-ORIENTED ENTERPRISE MODELING tional schema. The chosen set of properties is dependent on the pur-pose of a particular model. Communication/Interaction Communication between objects is effected through the modification of interface attributes via requests. An action at the receiver may or may not result from a request. The action of a receiving object may result in a state change of the sender. Only the state of a requesting object is changed when the request con-sists of information about the state of another object. In essence, an object model comprised of the objects and their dynam-ics can be described by the following three properties: 1. States —; described through attributes, 2. State Changes — described by possible actions and services, and 3. Object Interaction — described through external events and requests for services. 2.3.2.4 Implications Given that an object's interface attributes are the only attributes that other objects are aware of, only those changes of state arising from changes to interface attributes (and hence, the services responsible for the changes) can be known to other objects. That is, other objects can-not be aware of services and state transitions that affect non-interface attributes. This is the notion of encapsulation when applied to model-ing. Application of OOEM: An Industrial Case Study 24 OBJECT-ORIENTED ENTERPRISE MODELING In the process of modeling a component of an organization, the mod-eler may have knowledge of an object that is otherwise not known to the world. Hence, the internal view refers to information that is public to other objects, i.e., interface attributes, as well as those information, i.e., state variables, that are not part of the interface but do participate in the actions of the object. The external view, in contrast, refers only to those attributes that are recognizable by other objects, be they inter-nal or external to the system being modeled. 2.3.2.5 Rule-Based Model Building The following rules were developed by Wand and Woo [31] as guide-lines for building OOEM models based on the ontological principles and modeling concepts described in the previous subsections: Rule 1: The Scope Identification Rule — refers to the question of which aspect of the domain should be modeled. Rule 2: The Object Identification Rule — refers to the question of which things should be modeled. Rule 3: The Service Inclusion Rule — refers to the question of which object dynamics should be included. Rule 4: The Attribute Inclusion Rule — refers to the question of which object attributes should be included. Application of OOEM: An Industrial Case Study 25 OBJECT-ORIENTED ENTERPRISE MODELING Rule 5: The Attribute Ownership Rule — refers to the question of which object is responsible for an attribute value. Rule 6: The Composite Object Rule — refers to the question of when composites should be included. These rules together provide the OOEM method with a set of guide-lines for identifying and defining an enterprise model of an organiza-tion. The next chapter presents a case study of an organization upon which the OOEM method are applied and analyzed. Application of OOEM: An Industrial Case Study 26 A N INDUSTRIAL CASE 3.1 I N T R O D U C T I O N This case is the result of a project commissioned by Mr. Allan Cullen, president of DDA BC. The objective of this study is twofold: • To identify and study areas of business operations that can be rede-signed, and • To identify systems solutions with the aim of replacing the existing system. This study is intended to furnish the management of DDA BC with a high-level survey of the current practices of DDA BC's business oper-ations and of the IT that DDA BC could deploy. The information and proposals arising from this study are preliminary in nature and are intended only as a guide for future planning. They are not intended to serve as implementation plans. A confounding factor Application of OOEM: An Industrial Case Study 27 INTRODUCTION from the outset of this case study is that the parent company, Detroit Diesel Corporation (DDC), has yet to establish a clear agenda for its distributors' IS plan. The IS direction taken by DDC's distributors remains very much at the individual distributor's discretion. To meet the case study objectives, the company and its business pro-cesses must be understood. Specifically, one must be cognizant of the operating activities of DDA BC before a proposal for redesign is offered. This chapter serves not only to describe the organization and its activities, but also to present a detailed survey of one of the key business processes, the job control process, also known as the service repair process. 3.1.1 The Company DDA BC, an authorized distributor and service agent of diesel engines and transmissions, is jointly owned by Mr. Allan Cullen and Mr. Roger Penske of DDC. Presiding over the executive is a Board of Directors who counsels the management. DDA BC distributes and services engines manufactured by Detroit Diesel, Volvo, and Mercedes, and transmissions manufactured by Allison. DDA BC's annual sales reve-nue is in the region of $40 million. The market segment that DDA BC competes in is the high-end, large diesel engines that are used by the mining, forestry, marine, trucking, and industrial industry. Application of OOEM: An Industrial Case Study 28 INTRODUCTION FIGURE 1 Location of DDA BC's Branches in British Columbia SURREY Detroit Diesel-Allison BC Head Office S U R R E Y Service Branch KAMLOOPS Service Branch Tumbler Ridge Service Branch 3 C R A N B R O O K Service Branch Elkfo Service B ranch I Greenhills Service Branch NANAIMO Service Branch 1 C A M P B E L L RIVER Service Branch ] PENTICTON Service Branch 1 DDA BC's head office as well as a service repair "garage" are located in Surrey. DDA BC operates five other service branches in the prov-ince of British Columbia at Kam loops, Cranbrook, Nanaimo, Campbell River, and Penticton. As well, Cranbrook (at Greenhills and Elkford) and Kamloops (at Tumbler Ridge) each has one-man operated Application of OOEM: An Industrial Case Study 29 INTRODUCTION branches (see Figure 1). Altogether, 170 employees are on DDA BC's payroll. F I G U R E 2 High-Level Organizational Chart Board of Directors Allan Cullen President Financial Manager Computing Accounting Payroll & Accounts Payable Accounts Receivable Vice President Branch Operations Parts Administration Service & Warranty Inventory Control & Traffic Branch Manager Cranbrook Branch Manager Kamploops Branch Manager Campbell River Branch Manager Nanaimo Branch Manager Penticlon Branch Manager Surrey Parts & Service Sales Parts Department Service Manager Field / Diesel Service Shop Truck Service Shop Allison Service Injector Department Vice President Sales Dealer Development & Training Coordinator S60 (Kamploops & Northern BC) Kohler Generator Sets Indirect Sales Alison/S60/S50 Industrial Detroit & Perkins Marine "Small" Detroit, Perkins, Volvo Marine "Large" Detroit Engines Application of OOEM: An Industrial Case Study 30 INTRODUCTION Figure 2 describes DDA BC's organizational structure. There are three distinct layers: 1. Executive Management — Comprised of the president, two vice presidents, the Surrey branch manager, and the financial manager. 2. Middle Management — Comprised of parts, service and sales administrators, and the branch managers. 3. Operational Level — Comprised of the employees who participate in the day-to-day operating activities, e.g., the chargehand, journey-men, partsmen, mechanics, and clerks. Although the organization is generally perceived as hierarchical, it more closely resembles a matrix organization. This departure from the traditional hierarchy of management stems from the downsizing and reorganization which the company undertook several years ago. At the branch level, the managers are autonomous in their daily operating activities, which includes inventory management. A job description does not preclude an employee from other job functions. In fact, a very high percentage of employees are cross-functional in their capabilities. As such, each branch or department is a cost and profit center with the respective manager or department head responsible for revenue and expenses. In addition, they are also responsible for budgeting expenses and forecasting profits for each fiscal year. The managers ultimately are responsible for creating and meeting monthly revenue projections. These forecasts form the core of DDA BC's business plan. In essence, upper management views itself as a troubleshooter to facilitate the smooth operation of business. Application of OOEM: An Industrial Case Study 31 INTRODUCTION 3.1.2 Business Environment This subsection presents a description of the environment in which DDA BC operates. A distinction of such an environment can generally be made as follows: • The internal environment refers to the operating conditions that can be found within the company. Conditions which are not internal to the company but which can still be controlled or influenced by the company's policies are considered internal. • The external environment refers to those factors which are beyond the control of a company. Generally, these would be external enti-ties or resources. Examples in the case of DDA BC include suppli-ers and utility companies. The following paragraphs summarize the key players and the condi-tions of DDA BC's current business environment. 1. Stakeholders The stakeholders with vested interests in DDA BC are: • The Board of Directors • The Cullen family • DDC • The employees of DDA BC • The suppliers • The dealer network • The clients Application of OOEM: An Industrial Case Study 32 INTRODUCTION 2. Core Competencies The company is a mature competitor in the distribution and servic-ing of diesel engines and transmissions markets. Hence, DDA BC's core competencies are: • The sale and distribution of diesel engines and transmissions, and • The servicing, repairing, and overhauling of engines and trans-missions. This is evidenced by the revenue base generated from DDA BC's core businesses. 3. Competition DDA BC's main competitors are: • Caterpillar • Finning • Cummins 4. Competitive Advantage The market that DDA BC competes in is a relatively mature and sta-ble market; its products are also well established. Any existing com-petitive advantage is a direct manifestation of this stability. This stability is characterized by the following: • A vast base of clientele in North America, especially in highway trucking through the Detroit Diesel distributors network. • An established exchange (recycling) program for engines, trans-missions, and components for rebuilding as cores. Application of OOEM: An Industrial Case Study 33 INTRODUCTION • An established reputation and experience in the industry. • A sophisticated and established inventory management practice. • Effective human resource utilization — DDA BC has undergone several dramatic downsizing endeavours that reduced labour requirements by 60%. Middle management and administrative staff are operating at an average level of 40% below the previous staffing level. 3.1.3 The Business DDA BC's core business is the service repair and sales of diesel engines, transmissions, and parts. The primary client base, broken down according to industry in decreasing order of revenue, is mining, forestry, industrial, marine, and trucking. Figure 3 and Table 1 present an approximate breakdown of DDA BC's revenue according to type of services and according to the industry base. Major clients of DDA BC's business include Fording Coal Limited, Qeintette Operating Cor-poration, BC Transit, and Elkview Coal Corporation. DDA BC serves approximately 3,000 active clients, but lists a total of 10,000. Application of OOEM: An Industrial Case Study 34 INTRODUCTION TABLE 1 Estimated Revenue by Industry & Services for 1994 ($,000s) PARTS SERVICE PRODUCT SUB-TOTAL TOTAL MINING Coal 90000 4500 150 13650 Copper 1500 1500 0 3000 Other 100 50 0 150 16800 FORESTRY Equipment 1500 1000 1000 3500 Off-Highway Truck 2000 1000 300 3300 Highway Truck 1000 500 0 1500 8300 MARINE Towing 400 200 100 700 Ship Handling 100 100 200 400 Fishing 50 50 300 400 Pleasure 10 10 1800 1820 3320 TRUCKS (not incl. forestry) Highway 1800 1000 300 3100 3100 GENERATOR SETS Standby 10 80 1600 1690 Marine 5 10 250 265 1955 INDUSTRIAL EQUIPMENT Miscellaneous 1500 1500 1000 4000 4000 TOTAL 18975 11500 7000 37475 Application of OOEM: An Industrial Case Study 35 INTRODUCTION Each of D D A B C ' s six branches maintains its own inventory ware-house. The size of the warehouse and the type of parts in stock are dependent on the needs of the clients served by the individual branch. For example, approximately half of the servicing business handled by the Surrey branch is derived from the highway trucking industry, while Cranbrook caters mainly to the mining industry and Nanaimo handles mostly marine engines. Surrey maintains the largest inventory ware-house. Approximately 17,000 unique parts are maintained in the inven-tory and distributed among the 6 branches. Most of the inventory is supplied by 15 vendors, with intra-branch transfers within D D A B C constituting the largest transaction in terms of value. Intrabranch trans-fers helps to improve inventory turnover while lowering the costs of freight and import taxation. The latter is especially true in the purchase of new engines since they are imported from the United States, Great Britain, and Germany. A significant proportion of engine, transmission, and parts sales is derived from rebuilt engines, transmissions, and parts, respectively. This recycling program, whereby clients exchange their used parts (also known as cores) for rebuilt ones for a nominal price and a deposit, saves clients from having to purchase new components, which are significantly more costly. This program has helped to retain the customer base. Application of OOEM: An Industrial Case Study 36 INTRODUCTION 3.1.4 IS Infrastructure The existing IS infrastructure has been in operation for the last 13 years. The application packages were designed in-house and developed over a period of time with programmers from Sulcs P M & Associates, a Vancouver-based software development house. The application packages are written in VS COBOL, a variant of ANSI COBOL, and data is managed through a flat fde scheme. The hardware and software architectures are described in more detail in Section 3.1.4.1 and Sec-tion 3.1.4.2. 3.1.4.1 Hardware The main server, based in the Surrey head office, is a Wang mini VS 10000 with 4.5 gigabyte (GB) of secondary storage. Each of the other five branches is served by a smaller Wang mini, the VS5000, as a terminal server. The branches have dial-in capability to the Surrey office over 2400 baud lines leased from Insinc, a second-tier communi-cation service provider. The annual cost of leasing these low-speed lines is approximately $74,000. The main server at the Surrey site is connected via a 9.6 kilobyte (kb) satellite electronic data interchange (EDI) link to DDC's PowerNet, an on-line query service of engine, parts, and warranty information. A maximum of six concurrent users are able to access PowerNet. In addition, two small local area networks (LAN) are used at the Surrey site in accounting and in parts administra-tion. A description of the hardware distribution topology is illustrated in Figure 4. Application of OOEM: An Industrial Case Study 37 INTRODUCTION F I G U R E 4 Hardware Topology Kamloops To flower/vet r at DDC t 56 kb satellite link through EDS'NETl Surrey Head Office (Wang VS10000) Ethernet-Based Local Area Networks 1 r-a -a —a -a H3 Campbell River cn Cable CH Cranbrook cn = rfl -fl -fl -fl Lfl rfl -fl — f l -fl L-fl DDA BC is also currently in the process of installing CD-ROM servers at the Surrey service branch. This is a test phase to permit personnel in service repair, parts, and over-the-counter (OTC) sales to access infor-mation on engines and parts through multimedia CD-ROM licensed from the original equipment manufacturers (OEMs), primarily from DDC. This pilot project is part of DDC's Power Service Systems pro-Application of OOEM: An Industrial Case Study 38 INTRODUCTION gram designed for DDC's distributors. As part of the Power Service Systems program, DDC is also upgrading the PowerNet's satellite link to the EDS*NET link from 9.6 kb to 56 kb. 3.1.4.2 Systems Two software application packages are currently used at DDA BC: the Repair and Overhaul Shop Service Management System (ROSS) and the Material and Customer Control System (MC 2). The ROSS package consists of the following three main functional components: 1. Shop Floor Management, 2. Customer Management, and 3. Financial Management, while the M C 2 system provides the following three key functions: 1. Material Control (inventory management), 2. Customer Control, and 3. Vendor Control. These packages were fully implemented in 1982 and have undergone substantial enhancements. Al l of the application packages were devel-oped in-house and DDA BC has complete ownership of all the source codes to the application packages. Furthermore, the application pack-ages are licensed to six other Detroit Diesel distributors, with ongoing telephone support provided to Singapore, Toronto, and Winnipeg through a programmer at the Surrey head office. Application of OOEM: An Industrial Case Study 39 INTRODUCTION FIGURE 5 Workflow Linkages Among Application Packages Job Pricing / Costing WIP Tracking SERVICE MANAGEMENT Order Entry Invoicing MATERIAL MANAGEMENT J Inventory Management Job History Customer History Focus Forecasting j J > Receiving A j Expediting Purchase Ordering J j Accounts Receivable 1 General Ledger FINANCIAL MANAGEMENT Payroll J Accounts Payable —. J A high-level description of the package workflow between ROSS and M C 2 is described in Figure 5. Figure 5 also presents another perspec-tive of the application packages, where the application packages' mod-ules are differentiated into the following three functional components: 1. Financial Management — Consisting of Accounts Payable, Accounts Receivable, General Ledger, Payroll, and Fixed Assets. Application of OOEM: An Industrial Case Study 40 BUSINESS PROCESSES 2. Material Management — Consisting of Inventory Management, Order Entry, Invoicing, Focus Forecasting, Purchase Ordering, Expediting, and Receiving. 3. Service Management — Consisting primarily of Work-In-Process and Job Costing. 3.2 B U S I N E S S P R O C E S S E S DDA BC's business operations can be identified along the following traditional functional lines: 1. Sales 2. Accounting • Accounts Receivable • Accounts Payable • Payroll 3. Service Repair / Job Control 4. Material Control 5. Warranty Claim These functional areas can be realigned as business processes for the purpose of this case analysis. For example, the service repair process should include warranty claim, material control, accounts receivable, and payroll. Since service repair is one of DDA BC's core businesses, and since it has been identified as an area that was under-emphasized during the development of the current system, the case analysis of DDA BC's Application of OOEM: An Industrial Case Study 41 BUSINESS PROCESSES business processes is focused on branch operations. Moreover, the redesign of service branch processes is expected to generate a signifi-cant improvement in operating revenue and expenses. Among the six service branches, the Surrey branch generates the high-est revenue from both service repair and sales. Furthermore, the Surrey branch offers the most comprehensive repair services, and therefore, is the most complete DDA BC branch operating environment to model. As such, the case analysis is focused on the Surrey service branch. Sec-tion 3.2.1 and Section 3.2.2 present detailed surveys of the Surrey ser-vice branch and its service process respectively. 3.2.1 BRANCH ORGANIZATION & OPERATION A service branch is typically organized along the following four func-tional areas: 1. Job Control 2. Material Control 3. Sales 4. Administration The job control function refers to the servicing, repairing, and over-hauling of engines and transmissions, while the material control func-tion involves the management of inventory. For example, inventory management would include work functions such as receiving, picking, and shipping. The sales function is involved in identifying sales oppor-tunities in the market and in the OTC parts sales. The administration Application of OOEM: An Industrial Case Study 42 BUSINESS PROCESSES function includes both management and clerical functions. Figure 6 provides a description of the above-mentioned organizational and work functions. FIGURE 6 Organizational Structure of a Service Repair Branch Parts Foreman Partsmen Warehousemen Parts Sales Branch Manager Receptionist / Clerk Service Manager Truck Shop Field Service / Diesel Shop Allison Transmisson Service Shop Injector Department The Surrey service branch has two managers, a branch manager and a service manager, while other branches employ only one. The Surrey branch is unique because of its high volume of service repairs and parts Application of OOEM: An Industrial Case Study 43 BUSINESS PROCESSES sales. The service repair arm of the Surrey branch is further divided along the following service lines: • Truck servicing — The service repair of highway truck diesel engines. • Diesel servicing — The service repair of all other diesel engines, such as marine, mining, off-highway trucks, and industrial genera-tors. • Field (dispatch) servicing ^ - The service repair of engines in the field as opposed to depot servicing. • Transmission servicing — The service repair and rebuilding of transmission and related components. • Injector servicing — The service repair of fuel injectors. 3.2.2 T H E SERVICE REPAIR P R O C E S S The service repair process begins when a client enters the service office and requests a preliminary diagnosis over the counter. The process ends with the payment of the invoice, either by the client, through a warranty credit, or a combination of both. 3.2.2.1 A n Overview The service repair process is described in Figure 7 through an activity-workflow diagram. Application of OOEM: An Industrial Case Study 44 BUSINESS PROCESSES FIGURE 7 Activity-Workflow Description of the Service Repair Process CUSTOMER service requests & quotes | diagnosis confirm servicing CHARGEHAND receive confirmation process WO I service: report parts; receive job story confirm job story verify job story 1 1 consolidate job story split job story completed job story invoice / request for payment CLERK enter data / create WO request post labour charges data entry forward invoicing charges PARTS MEN process parts request ship verify MECHANICS service/ repair parts request report labour/parts charges job story. confirmation / correction warranty claim job story writeup verify job story invoice / request for payment ACCOUNTS PAYABLE OEM O a c t i v i t y a l t e r n a t i v e a c t i v i t y i n f o , f l o w ( n o r m a l ) ( e x c e p t i o n ) The process follows four key steps called the 4 Cs: the Complaint, the Condition, the Cause, and the Correction. The service process begins with the collection of information (the complaint) by the chargehand from the customer over the service counter. Key information collected Application of OOEM: An Industrial Case Study 45 BUSINESS PROCESSES includes the problem description by the customer, the serial number of the engine (or transmission or parts), warranty information, the classifi-cation of job type, and the method of payment. This information is recorded in the service report in triplicate by the chargehand prior to data entry into the work order system by a clerk. The entry of this information creates a work order in the system and a unique work order number is assigned to the repair job. Before any work can commence, i.e., the charging of labour hours and parts, a work order number must be assigned to each repair job. The first copy of the service report is filed in the service office by the chargehand while the second copy is attached to the work order printed from the system. The key information on the work order includes the work order number, the service history (if any) of the particular engine, and the customer's account number. The last copy of the service report is handed to the first mechanic assigned to the service repair job. The third copy of the service report is maintained by all the mechanics who work on the service repair job. While the job is in progress, the job story (the correction) is entered into the repair order. The job story entries describe the work that is performed. Parts and labour hours accumulated on the job are also recorded. Each mechanic devotes approximately one-half hour per day to completing the service repair job stories. Upon.completion of a job, the service report is returned to the charge-hand who then verifies that the job story is: Application of OOEM: An Industrial Case Study 46 BUSINESS PROCESSES 1. Fair and accurate, i.e., that the pertinent parts and labour informa-tion have been recorded by the mechanics, 2. Categorized and split into the relevant sub-jobs (if applicable), and 3. Translated and rewritten in the proper terms and format for the cus-tomer on the invoice, and for warranty claim (if applicable). The job story is then submitted to the clerks for entry in the invoicing and warranty claim modules of the system. If the method of payment is cash on delivery (COD), i.e., the job type is C, an invoice is issued to the customer and the payment is collected before the client takes pos-session of the engine. COD includes payments by cash, credit card, and cheque. However, if the charges are invoiced through a company account, accounts receivable (A/R) is credited upon collection of pay-ment. If the job type is W, i.e., the engine is under warranty, a different proce-dure is followed. A warranty claim number is assigned to the job and a warranty claim is printed. This warranty claim must be verified and authorized (signed) by the Service and Warranty administrator before an electronic copy of the warranty claim is transmitted to DDC. The paper-based copy of the warranty is then couriered the next business day. When DDC approves the warranty claim, a credit note is applied against DDA BC's accounts payable (A/P) to DDC. 3.2.2.2 Tracking WIP Section 3.2.2.1 presents a description of the generic service repair pro-cess. In the course of a service repair job, the costs of labour and parts Application of OOEM: An Industrial Case Study 47 BUSINESS PROCESSES have to be tracked and charged to the job. A detailed description of these two sub-processes, otherwise known as work in process (WIP), is described in this section. A service repair job is usually made up of numerous sub-jobs called operations. These operations form a job story. Each operation is recorded as a line item on the job story and is considered a discrete job process. For example, a "repair" job to overhaul an engine may entail the following initial three operations: 1. Evaluation of the engine, 2. Tearing down of the engine, and 3. Cleaning of the disassembled parts. Each of these three operations is recorded as a line item on the service report by the mechanic assigned to this particular job. The accompanying labour cost component is recorded on a time card, with each specific operation having a pre-assigned operation code. This system of operation code assignment to labour hours and hence, cost, is necessary to maintain a consistent operation name and rate for each specific operation. However, operation codes differ depending on the job type. For example, if a service job is a warranty job, the opera-tion code differs from that of a cash job. This distinction is necessary due to the flat rate that can be claimed for expenses incurred on an engine that is still covered under warranty. This process of applying the pre-defined rates against each operation is known as flat rating. Since there are several hundred operation codes, the mechanics must consult Application of O O E M : An Industrial Case Study 48 BUSINESS PROCESSES authorized operation code lists when completing their time cards. DDA BC estimates that each mechanic spends approximately one-half hour per day completing his time card. Since time cards are reviewed by the chargehands to ensure that clients are neither undercharged nor charged more than the original job quote and that the mechanics are maintaining an acceptable level of floor pro-ductivity, operation codes must again be cross-referenced against the operation code lists. Verified time cards are then routed to the service clerk for data entry into the ROSS. A conservative estimate of the average man-hours per day spent in recording, verifying, and entering data onto the time card and transfer-ring it into the system is approximately 40 hours. This figure assumes that there is a total of 80 mechanics, each submitting one time card per day, and that each time card requires 30 minutes distributed among the mechanic, the chargehand, and the clerk. At 40 hours per day, and at an average wage rate of $20 per hour, a conservative calculation of total wages and revenues foregone by either the mechanics or DDA BC is $800 per day (assuming that DDA BC's net profit margin is also $20 for each hour of labour charged to a job). The time required for the time cards to be routed from the mechanic to the chargehand and to the clerk also means that A/R is unnecessarily held up. This lag has inadvertently caused serious cash flow problems at month end. Application of OOEM: An Industrial Case Study 49 KEY ISSUES 3.3 K E Y I S S U E S The management of DDA BC believes that the current business model is outmoded and current advances in IT can be employed to enhance the business operations. Under existing practices, two key areas of con-cern: the infrastructure of IS, and the service repair process, have been identified and are discussed in the following two sub-sections. 3.3.1 IS Infrastructure 3.3.1.1 Hardware The Wang minis (VS10000 and VS5000s) incur overhead expenses through a maintenance contract with Wang Canada. Expenses include costs of regular maintenance, servicing, and replacement of parts due to attrition. This overhead has reached the threshold where it is no longer economical to maintain the hardware. The costs associated with the purchase of the hardware have been depreciated. Wang technology has also not kept pace with innovations in the indus-try. As a result, compatibility issues have increasingly become a central consideration in the upgrading of the hardware architecture to meet enterprise IS requirements. Application of OOEM: An Industrial Case Study 50 KEY ISSUES 3.3.1.2 Systems Substantial effort was expanded in the development of the systems inventory management modules when the application packages were developed. Although the inventory management modules still serve the users' requirements, the service management aspect of the system is deficient in many areas and must be improved. In short, the structure of the overall system is constraining the ability of the company to evolve in its business practices. Since the system has undergone over a decade of modifications and enhancements, the evolution of business practices has revolved around the constraints of the system. Over time, such practices have become inefficient, or even arcane, and are essentially restricting the com-pany's ability to adapt quickly to changes in the business environment. In essence, the development of business practices has become a bot-tom-up approach rather than the optimal top-down. 3.3.2 The Service Repair Model A fundamental issue regarding the service repair process relates to the lack of control of the operating activities. The duplication involved in the entry of data and the tracking of WIP means that WIP is not moving as fast as it potentially can. Resources that are tied up in WIP incur unwarranted overhead and expenses. More importantly, it is also a bot-tleneck that constricts the flow of cash. Application of OOEM: An Industrial Case Study 51 CASE ANALYSIS 3.4 CASE ANALYSIS The analysis can be divided into the following four main phases: 1. Study and document the existing business environment, processes, and operating activities. 2. Study the existing IS infrastructure and the functions that it serves. 3. Identify business processes that are potential candidates for rede-sign. 4. Identify, evaluate, and recommend the potential IS solutions that can be deployed in conjunction with the restructuring. The results from phases 1 and 2 have already been presented in Section 3.1.3 and Section 3.1.4, respectively, while the initial outcome of the analysis from phase 3 has been identified in Section 3.2.2. This section presents a summarized description of the analyses from phase 3 of the project. 3.4.1 Process Analysis The description of the service repair process in Section 3.2.2 identifies several key issues that are addressed here. This analysis is intentionally undertaken independent of technological facilitation. The purpose here is not to determine how technology can be deployed to achieve cost savings (although this is the ultimate objective), but rather, to deter-mine how the service repair process can be optimally improved. By establishing the "optimal" state of the service repair process indepen-Application of OOEM: An Industrial Case Study 52 CASE ANALYSIS dent of technology, the redesigned process will not be constrained by. technological considerations. The service repair process described in Section 3.2.2 and illustrated as an activity-workflow diagram in Figure 7 depicts a service repair pro-cess that is driven by rules that pose obstacles rather than facilitate effi-cient operations. Many information flow and activities can be eliminated while still maintaining coherence within the service repair process. Such a redesigned process is illustrated in Figure 8. Application of OOEM: An Industrial Case Study 53 CASE ANALYSIS FIGURE 8 A Redesigned View of the Service Repair Process CUSTOMER service requests & quotes: CHARGEHAND CLERK PARTSMEN MECHANICS service ; report ACCOUNTS PAYABLE OEM parts! service repair process parts request job story. verify job story notification of job completion process job story -warranty claim -invoice / request for payment invoicing invoice / request; for payment; process invoice o activity activity info, flow (normal) info, flow (exception) I Figure 8 describes a streamlined view of the service repair process, without the "redundant" steps. This perspective presents a "collapsed" view of the service repair process with a reduced number of activities. The processing of a work order in this case involves the collection and Application of OOEM: An Industrial Case Study 54 CASE ANALYSIS recording of pertinent information only once. Job story information is also recorded at only one point during the actual service repair by the mechanics prior to verification by the chargehand and the invoicing process. Although this redesigned process seems to lack checks and controls, many of the activities in the existing service repair process are redundant. These steps were manifested mainly by the need to circum-vent the limitations of the current system's capabilities, or because checks and balances in the business operation have become outdated. The service repair process is modeled using the OOEM methodology. Results and discussion are presented in Chapter 4 and Chapter 5, respectively. Application of OOEM: An Industrial Case Study 55 C H A P T E R 4 OOEM & IDEFO MODELING 4.1 O O E M M O D E L I N G The case description presented in Chapter 3 provides the framework within which the OOEM methodology is applied, for the first time, in an industrial setting. This case provides an opportunity to test the OOEM method in an actual "test-bed" environment, one that offers more variability and complexity than a textbook-based case. It is an environment that stimulates more questions which, hopefully, will con-tribute to further development of the OOEM methodology. Together with the concepts and principles of OOEM modeling sur-veyed in Chapter 2, the next section completes the OOEM approach by discussing the concepts and method of representing OOEM models. Application of OOEM: An Industrial Case Study 56 OOEM MODELING 4.1.1 Notational Representation Many of the notations used in this thesis are drawn from the recent work done by Zhao [34]. As such, a clear understanding of the seman-tics used in representing OOEM models is pertinent. Although refer-ences are drawn heavily from this work, the notations are not necessarily adequate and are modified in the course of the case analy-sis. The objective of OOEM is to provide a systematic way of identifying objects, their services, attributes, and the interactions that transpire between objects. As such, it is necessary to have an unambiguous set of notations to represent OOEM models. According to Zhao [34], there are two complementary sets of nota-tional representations: object communication diagrams (OCD) and object templates (OT). The OCD and OT of a system and its objects should communicate to a reader all the necessary information for a complete and accurate structural reconstruction of an organization. The term "complete" is used in reference only to the relevant information and does not necessarily apply to the complete system being modeled. Furthermore, these two forms of representation should be self-suffi-cient in communicating the nuances of processes explicit in the OOEM models. Application of OOEM: An Industrial Case Study 57 OOEM MODELING 4.1.1.1 Object Communication Diagram An OCD is intended to capture and communicate, firstly, the scope of a system that is being modeled. This includes the following sets of ele-ments as listed by Zhao [34]: • the set of external objects, • the set of internal objects, • the set of internal attributes of each object, • the set of services of each object, • the set of interface attributes of each service, and • the set of requests and their corresponding respondents that are gen-erated by each of the services. The semantics of these elements were detailed in Chapter 2. These ele-ments together form the basic components of an object communication diagram. Figure 9 illustrates and explains the composition of an exam-ple OCD. The OCD identifies the scope of a system (or organization) that is being modeled. The boundary of dashed lines delineates between objects that are internal and external to the system. The solid arrows represent the flow of requests for services from one object to another. An object that requests a service from another object is the cli-ent while the object that is providing the service is a server; an object can exist as both a client and a server simultaneously. Application of OOEM: An Industrial Case Study 58 OOEM MODELING FIGURE 9 An O O E M Object Communication Diagram External Object External Object External Request Request •{ Internal Object V-Request Request Legend External Object Internal ( ) Object Request Internal Object) Internal Object J^-- • Request • System Scope External Request I External Object External Request I External Object A more detailed exposition of the OCD is found in Zhao [34]. 4.1.1.2 Object Templates OTs are tables of information about objects. Since both internal and external objects can exist in a system, OTs are likewise distinguished into internal object templates (IOT) and external object templates (EOT), respectively. Table 2 and Table 3 describe an IOT and an EOT, respectively. Application of OOEM: An Industrial Case Study 59 OOEM MODELING TABLE 2 Internal Object Representation: Internal Object Template (IOT) Object Name Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Object 1 Service 1 Incoming Internal Access Request Object 3 Object 2 interface attributes Mode generated - attributes to support from Service 1 - Returning Service 1 Request Object 4 Object n interface generated attributes from Serv ice 1 Object 1 Service 2 Incoming Internal Access Request Object 5 - interface attributes Mode generated Object n attributes to support from Serv ice 2 Serv ice 2 TABLE 3 External Object Representation: External Object Template (EOT) O b j e c t N a m e R e q u e s t s to S y s t e m R e c e i v i n g O b j e c t R e q u e st 1 I n te r n a I 0 b je c 11 R e q u e st 2 Internal 0 b je ct 2 R e q u e s t i n g 0 b je c ts S e rv ic o s I n t e r f a c e to A t t r i b u t e s Internal 0 b je ct 3 S e rv ice 1 In te rfa ce a ttrib u te s o f S e rv ice 1 I n t e r n a l 0 b j e c t 4 S e r v ice 2 Interface attributes o f S e rv ice 2 Each object from the OCD can and should be represented by either an IOT or EOT, depending upon the relationship of an object relative to the defined system. Application of OOEM: An Industrial Case Study 60 OOEM MODELING 4.1.1.3 Internal Object Template (IOT) An object is firstly defined by the object name in the header of an IOT. The subsequent template header identifies several columns of key char-acteristics for an IOT. A requesting object identifies the names of other objects that request services from the said object, while services denote the services that are initiated as a result of the requests. The interface attributes refer to either: 1) the information that is required as part of providing a service in the course of servicing a request, or 2) the infor-mation that is returned upon conclusion of a service to the requesting object of the service. The former is referred to as incoming interface attributes while the latter is the returning interface attributes. The internal attributes column refers to the attributes owned by the object providing the services. These attributes are necessary for the completion of a service and may be referenced in either of two modes. That is, in the use mode and/or in the modify mode. The former is rep-resent by "U" and the latter as " M " in the access mode column. An object may have to request services from other objects in order to complete the original service request. Such requests are identified in the generated requests column. The objects servicing these generated requests are in turn listed in the last column of an IOT, the receiving objects column. Application Of OOEM: An Industrial Case Study 61 OOEM MODELING 4.1.1.4 External Object Template (EOT) External objects are objects that are outside the system but interact with the system proper. As such, only relevant information about external objects are modeled. External objects can submit requests to the sys-tem, i.e., the external object is a client, or provide services to the sys-tem, i.e., the external object is a server. These two roles are not mutually exclusive, as is the case with internal objects. However, an important distinction of an external object is that it is the beginning of a request propagation process. As can be seen from Table 3, the information encapsulated in the EOT includes the following: 1. Requesting object role-specific attributes: • the (external) requests that the external object submits to the sys-tem, • the attributes that interface with the services being requested, and • the objects within the system, i.e., the internal objects, that receive and service the requests. 2. Role-specific attributes of object providing service: • the internal objects that request services from the external object, • the services that are provided by the external object to the requesting internal objects, and • the (interface) attributes that are communicated from the request-ing internal objects in order to service the requests. Information regarding internal attributes of external objects is not cap-tured and represented since this information is irrelevant to the model. Application of OOEM: An Industrial Case Study 62 OOEM MODELING Taken together, the OCD and the OT provide a comprehensive repre-sentation of an OOEM model of an organization. This is especially useful in large organizations where complex details can be encapsu-lated and systematically represented. Furthermore, subsequent levels of detail can be represented and described as sub-models. This multi-lay-ered scheme of information structuring is especially useful when the system being modeled is large and complex with information that can be represented at different levels. This gradual exposition of details serves to reduce the possibility of information overload. OOEM mod-els do not include any information, objects, or services that do not con-tribute to the description of a system. This gradual exposition of details also serves as an essential control against excessive growth of the OOEM model. The following section takes the enterprise modeling process through a hierarchical view of the organization. That is, the company is modeled from a top-down approach, with successive decomposition into more detailed representations. The analysis focuses on the organization as a whole and on the service process in particular, since it is the core busi-ness of the company. The analysis and discussion are based on the pro-gressive application of OOEM in modeling DDA BC as an organization and as a service process. Application of OOEM: An Industrial Case Study 63 OOEM MODELING FIGURE 10 O O E M Object Communication Diagram: Request Propagation Analysis of 'DDA BC Financial Institutions Info. Quote Product Service Customers )-^-Legend ( ) External Object Internal Object Financial / Banking Services 4 DD-ABC -Order Product -Payment -Invoice-- • Request j System Scope Suppliers 4.1.2 O O E M Model of DDA B C A "high-level" perspective of DDA BC as an enterprise from its cli-ents' point of view is presented in Figure 10. This diagram illustrates several key aspects of the system that are being modeled. Objects that are explicitly represented are either service providers or service requestors. However, not every service provider or requestor is in the model. An object and its services are included in the model if and only if they are required to complete the request propagation process. Application of OOEM: An Industrial Case Study 64 OOEM MODELING The external object, Customers, defines the starting point of the request propagation process of this system. Consequently, other requests that are modeled in this system are generated as a result of one or more of the four requests that are submitted to the DDA BC object. This will become even more evident as the organization is modeled at lower lev-els in the latter part of this chapter. T A B L E 4 Internal Object Template (IOT) of DDA BC Object DDA BC Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Customer Service - Serv ice request - Serv ice history U/M Order product Suppliers product (product info, problem - Detailed product info U Payment Customer description, payment info) - Warranty info U Financial/Banking Financial - Serv ice confirmation - Account info M Services Institutions - Work description - Billing info Customer Purchase - Product info - Warranty info U Order product Suppliers product - Product info U Payment Customer - Billing info - Account info M Financial/Banking Services Financial Institutions Customer Prov ide price quote - Quote request - Product info U Customer Prov ide product info - Info request - Product info U Complementing the OCD in Figure 10 is a set of object templates com-prised of one internal and three external object templates. Each of these templates corresponds to the respective objects that are modeled in the communication diagram. Table 4 describes the IOT for the customer object, while the subsequent three tables describe each of the objects that is external to the system. Application of OOEM: An Industrial Case Study 65 OOEM MODELING TABLE 5 External Object Template (EOT) of Customer Object Cus tomer Requests to System Rece iv ing Object - Product info - Quote - Order product - Serv ice DDA BC Request ing Objects Services Interface to Attr ibutes DDA BC Pay ment Billing info TABLE 6 External Object Template (EOT) of Supplier Object Supp l ie r Requests to System Rece iv ing Object Invoice DDA BC Request ing Objects Services Interface to Attr ibutes DDA BC Order product Product info TABLE 7 External Object Template (EOT) of Financial Institution Object Financia l Institution Requests to System Receiv ing Object Request ing Objects Services Interface to Attr ibutes DDA BC Financial & Banking - Account info - Financial info Application of OOEM: An Industrial Case Study 66 OOEM MODELING The OTs provide additional information that is encapsulated within the objects themselves, including information that is: 1. communicated in the course of requesting for services, and 2. accessed and, perhaps, modified in the course of providing services. This information is not reflected in the OCD to minimize the amount of information that has to be assimilated at this level. More importantly, this representation of OCD in conjunction with OTs embraces the con-cept of encapsulation. The immediate implication is that all the infor-mation sets and attributes have clearly defined owners, where "owners" refer to the objects themselves. The next section presents a more focused and in-depth view of an OOEM model based on the service repair process at DDA BC. Although an in-depth level of detail could be provided for the whole organization, only the OOEM model of the service repair process is presented as it is the focus of this thesis. 4.1.3 O O E M Model of the Service Repair Process The OOEM model of DDA BC described in Section 4.1.2 illustrates a high-level view of an OOEM model of an organization from the per-spective of the company's customers, such as those who request ser-vices (sales and repair, for example). At this level, none of the more detailed components (e.g., internal objects) of the DDA BC organiza-tion is expressed in the OCD. This OOEM model has shown that the OOEM method is adequate as a high-level modeling method in this Application of OOEM: An Industrial Case Study 67 OOEM MODELING particular instance. The service repair OOEM model presented in this section offers a detailed view of the service repair process to further evaluate the applicability of the OOEM method. Figure 11 presents the OCD for a request propagation analysis of the service repair process. Again, the scope and level of detail included are dictated by the need to represent only those objects and information that must necessarily be present in order for the service request to be successfully propagated and acted upon. Table 8 through Table 15 describe the IOTs and EOTs that correspond to the objects in Figure 11. An obvious request that is omitted from this OCD is the request to the payroll department (object) to update the labour hours and accrued credit. These objects have been omitted since, from the customer's point of view, the service process concludes regardless of whether DDA BC's employees have been paid for the work performed. The completion of the service process, from the modeling point of view, occurs when a customer has responded to a payment request. As well, a noteworthy observation is that the suppliers object is considered exter-nal to the system. Application of OOEM: An Industrial Case Study 68 OOEM MODELING FIGURE 11 O O E M Object Communication Diagram: Request Propagation Analysis of 'Service Repair Process' Legend Customer Service Quote Service -Payment Payment Accounts Receivable Service Chargehand Allocate Parts Close WO Open WO — -Service WO -I Close Update service Charges A c c o u n , I I Service Admin. T Verify Job Story Update Charges Reman ufactu ring ^ ) Inventory Control LA Service Floor I Allocate Parts Remanufacture - I Oroer Product Suppliers Application of OOEM: An Industrial Case Study 69 OOEM MODELING T A B L E 8 Internal Object Template (IOT) of Service Chargehand Object Service Chargehand Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Customer Service Quote - Product info (engine serial #, model/year) - Problem description (symptoms, location) - Warranty info U - Estimated work description (repair type, parts needed, labour hours) Customer Service - Product info - Service history U7M Open WO Service Admin product - Problem description - Detailed product info U Service WO Service Floor - Payment info - Warranty info U Parts Inventory Control - Service confirmation - Account info M Close WO Serv ice Admin - Work description Payment Customer - Billing info T A B L E 9 Internal Object Template (IOT) of Service Admin Object Service Admin Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Service Open WO - Product info - WO info M Chargehand (engine serial #, model/year) - Problem description (symptoms, location) - Estimated work description (repair type, parts needed, labour hours) (customer info, product info, problem description) Remanu- Update - Account info - Work info M facturing charges (account #) - WO info (job story, parts allocated, labour hours) (rebuilding work done, parts used, labour committed) Service Close WO - WO info - Work info M Update charges AIR Chargehand (yob story, parts allocated, labour hours) (repair done, parts used, labour committed) Close service account A/R Application of OOEM: An Industrial Case Study 70 OOEM MODELING TABLE 10 Internal Object Template (IOT) of Inventory Control Object Inventory Control Requesting Objects Services Interface Attributes Internal Attributes Generated Requests Receiving Objects - Service Chargehand - Serv ice Floor Allocate Parts - Product info (serial #, model/year, quantity) - Confirm allocation - Stock info (quantity on hand, transit, backordered, dirty, clean, to be remanufactured) M Order product Suppliers TABLE 11 Internal Object Template (IOT) of Service Floor Object Service Floor Requesting Objects Services Interface Attributes Internal Attributes Generated Requests Receiving Objects Service Chargehand Service WO - WO info (problem description, prelim, diagnosis, repair needed) - Job story - Labour hours - Actual repair info (repair type, duration, parts used) M Allocate parts Inventory Control Remanufacture Reman. Dept TABLE 12 Internal Object Template (IOT) of Accounts Receivable Object Accounts Receivable (AIR) Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Service Update - Account # - Customer accounts U Admin charges - Charge info (parts info, costing info) - Account credit/debit info M Service Close - Account # -Amount Payable M Payment Customer Admin Service Account - Credit limit M Application of OOEM: An Industrial Case Study 71 OOEM MODELING TABLE 13 Internal Object Template (IOT) of Remanufacturing Object Rem an u fact u ring Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Service Rebuild - Part info - Labour hours committed M Update charges Service Admin Floor - WO info - Parts used M TABLE 14 External Object Template (EOT) of Customer Object Customer Requests to System Receiv ing Object - Service quote -Serv ice Service Chargehand Request ing Objects Services Interface to Attr ibutes Service Chargehand Payment Billing info Accounts Receivable Payment Billing info TABLE 15 > External Object Template (EOT) of Supplier Object Supplier Requests to System Receiving Object Requesting Objects Services Interface to Attributes Inventory Control - Order product Product info Application of OOEM: An Industrial Case Study 72 IDEFO MODELING In addition to the above models describing DDA BC and its service repair process, OCD templates describing the accounting process from the viewpoint of the service repair process are presented in Appendix A. 4.2 IDEFO MODELING The use of the IDEFO methodology in duplicating the models described in Section 4.1 is intended to provide a basis of comparison with the OOEM model. The IDEFO methodology is deemed appropriate prima-rily because it is a mature approach that is well tested and accepted as the standard methodology for describing systems of processes [19] [27]. While it is not the intention here to perform an extensive comparative evaluation between OOEM and IDEFO, the IDEFO mod-els are expected to provide a baseline against which the OOEM approach can be qualitatively assessed for its comprehensiveness in modeling an organization. 4.2.1 IDEFO Model Building The IDEFO technique specified in the FIPS Publication 183 [27] is very detailed in terms of its constructs and provisions for the collection of data to build an IDEFO model. The authoring phase entails six steps summarized as follows: 1. Selection of a context, viewpoint, and purpose 2. Creation of the context diagram Application of OOEM: An Industrial Case Study 73 IDEFO MODELING 3. Creation of the top-most level diagram 4. Creation of the child diagrams 5. Creation of the supporting material 6. Selection of boxes for detailing The authoring phase itself can be divided into the following four phases: 1. Data Gathering Phase 2. Structuring Phase 3. Presentation Phase 4. Interaction Phase The complete procedure for constructing and authoring an IDEFO model is highly detailed, and a comprehensive presentation of the method will not be elaborated upon here. For further details, see FIPS Publication 183 [27]. 4.2.2 High-Level Reference Descr ipt ion Details of the IDEFO model on the service repair process are described in two different ways, with both representations conveying the same set of information. Figure 12 contains the node index-based description of the service repair process while Figure 13 is a node tree. Application pf OOEM: An Industrial Case Study 74 IDEFO MODELING FIGURE 12 Node Index for Service Repair AO Service Product A1 Provide Pricing Information A11 Determine Requirements A12 Obtain Pricing Info A13 Determine Deductions A14 Negotiate Servicing Details A2 Open Work Order A3 Repair Product A31 Plan Repair A32 Pick Inventory A321 Check Stock A322 Order Parts A323 Assign Parts A33 Repair Product A4 Close Work Order A5 Invoice Service Repair A6 Make Accounting Entries for Work Order Both the node index and the node tree provide a hierarchical view of the functional components of the system being modeled. Whereas the node index provides a pseudocode-like algorithmic description, the node tree gives a structural view of a system. Both approaches, how-ever, serve to provide a complete set of information of the individual functional components within the system being modeled. Application of OOEM: An Industrial Case Study 75 IDEFO MODELING FIGURE 13 N o d e Tree for Service Repair Q A 1 1 Determine Require-ments Parts 4.2.3 Context Descr ipt ions The main form of documenting and describing IDEFO models is through the use of context diagrams. A context diagram for a given level of representation contains information on each of the functions that is present at that level. Each of the functions is represented by a rectangular box with connecting arrows as illustrated in Figure 14. Application of OOEM: An Industrial Case Study 76 IDEFO MODELING FIGURE 14 Syntax of a Function Control Input Function Name Output Mechanism Call Each side of the function box carries predefined meaning in terms of the box-arrow relationship, i.e., the side of the box that an arrow inter-faces with reflects the role of that arrow. As such, a function box with its interface arrows can be read as follows: Arrows which enter through the left side of a function box are inputs into the function. These inputs are either con-sumed or transformed by the function to produce outputs, Outputs are in turn represented by arrows leaving the func-tion box through the right side. Outputs may be data or objects produced by the function, and can be fed into another function as inputs. Arrows that interface through the top of a function box are termed controls, and they define the conditions which are necessary for the production of correct outputs by the func-tion. Application of OOEM: An Industrial Case Study 77 IDEFO MODELING Arrows that interface through the bottom of a function box are called mechanisms. Those which enter the function box denote the means by which execution of the function is sup-ported. Those that leave the function box are known as call arrows and they enable the sharing of details between two models, or between functions within the same model. A series of function boxes linked together form what is called a context diagram. Within a context diagram, each of the function boxes can be further decomposed into its major sub-functions, where each of the sub-functions is essentially a child of the original function box, i.e., the parent. The sub-functions, or children, together form a child context diagram. Each child diagram can contain in turn its own child boxes and arrows that provide additional detail about the parent box. Like-wise, a sub-function can be similarly decomposed to another level of children functions. This method of decomposition between parent and child can be performed progressively until the desired level of model details is documented. This decomposition scheme also means that a child function can simultaneously be a parent function. 4.2.4 IDEFO Model of the Serv ice Repair P rocess The IDEFO model developed consists of the first level parent objects denoted as A l to A6 in Figure 12 and Figure 13. Beyond this level, only selective parent-child objects are described in greater detail. These parent-child objects are A l , A3, and A32. This does not imply that the other objects, e.g., A2, A4, A5 and A6, lack lower-level child Application of OOEM: An Industrial Case Study 78 IDEFO MODELING objects. Rather, this exclusion allows a more concentrated focus on the analysis in Chapter 5. Figure 15 through Figure 18 describe the service repair function and selected sub-functions that parallel the OOEM models described ear-lier. Since these models have already been described in the case study, as well as by the OOEM models, the IDEFO models presented are not further elaborated. Application of OOEM: An Industrial Case Study 79 IDEFO MODELING FIGURE 15 Top-Level IDEFO Context Diagram for AO: Service Repair Provide Pricing ^ | Information T Chargehand WoikS Produi ;t Info J Open Work Order 2 Requirements C o n t r o l i Input Function Name # Output Call Mechanism Ir Supply Parts LL Repair Product j£ A3 Mechanics "I Job Story Close Work Order 4 "f Chargehand Billing Info Warranty Credits Invoice Repair Clerk Account Info Repaired Product Completed Make >j Accounting Entries 6 Receipt Accounting Dept S E R V I C E P R O D U C T Application of OOEM: An Industrial Case Study 80 IDEFO MODELING FIGURE 16 IDEFO Context Diagram for A1: Provide Pricing Information Determine Requirements nfo Obtain Pricing Info Parts Dept Pricing Info Discounts, Landed Costs, 4 Tax Requirements -•j Determine D educations Clerk Modified Price Chargehand Input Function Name # Output • Negotiate Servicing Details Finalized Price Quote Work & Product Info ^ 4 PROVIDE PRICING INFORMATION Application of OOEM: An Industrial Case Study 81 IDEFO MODELING FIGURE 17 IDEFO Context Diagram for A3: Repair Product Plan Repair Request Mechanics Control 1 Input Function Name Output • Parts Request Costs of Allocated Parts Repaired Product Job Story REPAIR PRODUCT Application of OOEM: An Industrial Case Study 82 IDEFO MODELING FIGURE 18 IDEFO Context Diagram for A32: Pick Inventory Inventory Stock ••j Check Stock Partsmen Specification 1 — M Order Parts —M Assign Parts Partsmen Control 1 Input Function Name Output w • T Call T i Mechanism Y PICK INVENTORY Costing Info ->. A33 Application of OOEM: An Industrial Case Study 83 COMPARATIVE ANALYSIS OF OOEM The models developed and presented in the previous chapter use both the OOEM methodology and the IDEFO technique, and together, pro-vide an opportunity to evaluate the OOEM method from a practical viewpoint. The IDEFO technique is specifically oriented to process modeling since it offers a well-established approach and is widely rec-ognized as the de facto standard. However, IDEFO in itself is not able to provide a complete basis of comparison against the OOEM method since IDEFO does not embody the object-oriented concept of modeling. Nevertheless, the IDEFO technique does provide a representation of process models that allows us to assess the OOEM models described in the earlier chapter. It allows us to determine whether OOEM can model processes and to compare the features of OOEM against that of IDEFO. Application of OOEM: An Industrial Case Study 84 COMPARISON OF OOEM WITH IDEFO 5.1 COMPARISON OF OOEM WITH IDEFO The analysis in this section focuses more on the aspects of O O E M and IDEFO as process modeling techniques. The observations noted and discussed here wil l be based on the O O E M and IDEFO models described in Chapter 4. While the comparison of the O O E M method is strictly confined to aspects of the IDEFO technique, it must be noted that the IDEFO technique is commonly used in conjunction with the IDEF1 and the IDEF I X techniques.1 5.1.1 Separability of Process & Functional Information In building the models, the foremost observation of the O O E M and the IDEFO approaches is that the O O E M method seems to lend itself to a process modeling approach while IDEFO can be more accurately described as a functional approach, or rather, a work-flow approach to modeling. This is evident from the definition of the methods and the models of the same system as created using the O O E M OCDs and the IDEFO Context Diagrams described in Chapter 4. For instance, the service repair process represented by the O C D in Fig-ure 11 is described by a set of objects and their requests irrespective of how the functions are defined within the existing business environ-ment. A reader is therefore able to identify the objects and requests that are propagated in order to fulfill the activities in question. That a result-1. IDEF1 is an information modeling technique, while IDEF1X is an extension of IDEF1 and is a semantic data modeling technique [19]. Application of OOEM: An Industrial Case Study 85 COMPARISON OF OOEM WITH IDEFO ing O O E M model departs from functional activities and centers around events aggregated as a process suggests that the O O E M method does lend itself well to the modeling of processes. In IDEFO, work functions are explicitly modeled according to the guidelines of FIPS Publication 183 [27]. The IDEFO technique does not necessarily distinguish between work functions that are essential in describing a process versus those required to completely describe the whole system. Hence, an IDEFO model faithfully describes all the details of a system without attempting to present a particular view, i.e., one which may be more useful to the task that called for the model in the first place. A n IDEFO Context Diagram captures and communicates a somewhat different set of information when compared to O O E M models. The IDEFO Context Diagrams presented as Figure 15 through Figure 18 do not trace the requests that are propagated through the processes and do not communicate information in terms of the interactive active "agents" in an organization. Rather, an IDEFO Context Diagram traces the sequence of activities that are performed. This IDEFO approach to modeling processes may be beneficial for cer-tain activities, but as is noted in FIPS Publication 183 [27] \ the use of the IDEFO standard "is strongly recommended for projects that require a modeling technique for the analysis, development, re-engineering, 1. [27], p. ii. Application of OOEM: An Industrial Case Study 86 COMPARISON OF OOEM WITH IDEFO integration, or acquisition of information systems." The O O E M method of modeling interactive agents allows the separability of "func-tional" versus "process" based information in a system, whereas in the case of IDEFO models, there is only a clear separation of functions. Even though the O O E M method is not intended as a process modeling technique, the interacting agents in an O O E M model aggregate to form a process-oriented model. In such a model, the functional lines are no longer distinct. In this respect, the O O E M method offers a more intui-tive process-oriented perspective through a model as opposed to the IDEFO function-oriented approach. 5.1.2 Request Semantics In O O E M , a process is described through the propagation of requests in the model. A request in O O E M is represented by an arrow. In con-trast, in IDEFO, arrows could represent one of the following four con-structs: input, output, control, and mechanics. Input and output could be in the form of physical objects such as raw material and work-in-process or a piece of paper travelling through different departments of an organization. Control could also refer to a physical constraint or informational constraint imposed on a function, while mechanism refers to a resource that is needed to perform the function, e.g., an employee or a piece of machinery. It would thus seem that the seman-tics of the arrow constructs in the IDEFO Context Diagrams are not clearly defined and their interpretation requires additional information on the form of the constructs depending on how they are connected to Application of OOEM: An Industrial Case Study 87 COMPARISON OF OOEM WITH IDEFO an activity. More importantly, arrows in IDEFO models represent gen-erally the flows from one function to another. In O O E M , arrows refer to requests for services only and its physical form is ignored. For example, it is immaterial whether the request is propagated on a piece of paper or as a data stream between computers. The main notion of request propagation is that a service is required from another object and that this service is invoked when the request is received. Hence, O O E M provides well-defined semantics of requests in the form of a logical abstraction. Furthermore, arrows in O O E M Communication Diagrams possess a richer set of semantics than those in IDEFO Context Diagrams. The service WO and verify job story requests in Figure 11 provide an exam-ple. A portion of the Service Repair Process is extracted and repro-duced in Figure 19 with an additional service request (dotted line) included for the present discussion. Application of OOEM: An Industrial Case Study 88 COMPARISON OF OOEM WITH IDEFO FIGURE 19 Analysis of Request Semantics c Service Cragehand OpenWD-acseWO--ServiceWO Service Adrrin. verify Job Stay Verify Job Stay 0 Service Flax The service chargehand sends a "service W O " request to the service floor where the repair work is carried out. Upon completion of repair, the service floor sends a "verify job story" request back to the service chargehand. The second request is returned through the same arrow as the incoming "service W O " request represented by the solid-line arrow, i.e., information related to the request is transmitted in both directions on the same arrow. A second alternative to describe the "ver-ify job story" request could be through a different arrow as illustrated by the dotted-line arrow in Figure 19. These two schemes of describing the "verify job story" request convey very different meanings. The first, as depicted in Figure 11, implies that the request to verify a job story is contingent upon the state of the service that is invoked by the request to service the work order. That is, Application of OOEM: An Industrial Case Study 89 COMPARISON OF OOEM WITH IDEFO the "verify job story" request is clearly issued as a consequence of the "service W O " request and is considered a returning request. The semantic of the arrow here also clearly indicates that the "service W O " request concludes when the "verify job story" request is returned. In this instance, the arrow is clearly bi-directional. Under the second scheme, the request to "verify job story" is returned by a separate arrow described using the dotted-line arrow in Figure 19. This request could be contingent upon the state of the service invoked by the request to service a work order, but it does not have to be, i.e., it could be generated as a consequence of another service that is provided by the service floor object. Furthermore, i f the "verify job story" request is generated as a result of the service initiated from the "service W O " request,1 the semantics of the arrows dictate that until the appro-priate service is initiated and completed by the service chargehand object, the service floor object wi l l not be able to conclude its service to the "service W O " request. That is, the service provided in response to the "service W O " request cannot proceed pending verification of the job story. In contrast, the arrows used in IDEFO Context Diagrams do not include the semantics of arrows found in O O E M models. In fact, the arrows in IDEFO clearly describe only flows and not calls for actions (services). 1. Whether the "verify job story" request is generated as a result of the "service WO" request can be found in the appropriate OT, and in this case, in the IOT of the service floor object. Application of OOEM: An Industrial Case Study 90 COMPARISON OF OOEM WITH IDEFO As well, arrows in IDEFO do not originate on a service, nor are they generated from the provision of services. Moreover, the flow of arrows is strictly unidirectional in IDEFO. 5.1.3 Scope of Model The descriptions given by the activity-workflow diagrams in Chapter 3 and by the IDEFO context diagrams do not provide a clear indication of the system boundary. Consider examples from the payroll and suppli-ers: 1. The function of the payroll is considered integral to the service repair process from the functional point of view. This is illustrated in Figure 7. 2. "Supplier" as an entity is not distinguished as being internal or external to the system in the context diagram for A32: Pick Inven-tory in Figure 18. These examples illustrate the potential for a model to grow unwieldy in size and contain unnecessary information. In contrast, the O O E M method with its scope identification rule offers a systematic approach to clearly define the scope of a system to be modeled. Therefore, the O O E M approach is likely to be more efficient in communicating the essential information of a system which is being modeled. The above comparison leads to an additional observation that can be inferred regarding the two methods. The O O E M model presents only the information that is necessary to complete a process that is started by Application of OOEM: An Industrial Case Study 91 COMPARISON OF OOEM WITH IDEFO an external request. On the other hand, the IDEFO model includes information which would otherwise be deemed irrelevant in an O O E M model simply because the IDEFO technique does not rely on the notion of requests arid is not governed by a set of well-defined rules regarding the scope of the system that should be modeled. 5.1.4 Model Eff ic iency The same argument can be made for O O E M models except that these models are more effective ("compact") in conveying information because a high level of information is "hidden" due to encapsulation. As a result, only that information which is needed at any given time can be extracted; at other times, this information would remain "hid-den". This is true to a certain extent but any information considered necessary to an O O E M model according to the O O E M rules is still captured and described as attributes in the IOTs and EOTs. The impor-tant distinction here is that redundant information may be represented in an IDEFO model. A n example is the "Determine Deductions" func-tion in Figure 16. From an O O E M perspective, this function is unnec-essary since the service quote request (see Figure 11) can be completed regardless of whether the appropriate deductions are determined and applied. However, it is included in the IDEFO model in order to ensure completeness. Application of OOEM: An Industrial Case Study 92 COMPARISON OF OOEM WITH IDEFO 5.1.5 Level of Information Representation Another aspect of information adequacy can be determined through the respective objectives of the modeling techniques. In this thesis, the objective is to determine the potential of the O O E M rule-based meth-odology as an enterprise modeling technique. From this viewpoint, the merit of including minute details as those described in IDEFO models is questionable. After all, i f the objective of a modeling exercise is to facilitate process redesign, it is highly unlikely that data-level types of detail wi l l be very meaningful. Additionally, such detail could obscure useful information. Examples of such detail are explicitly demon-strated in Figure 17 and Figure 18. In summary, the IDEFO technique serves as a comprehensive docu-menting methodology which does not seem to take into consideration how the information is to be used. Although the IDEFO technique pro-vides a proven framework for IS analysis, the extension into the pro-cess modeling domain seems to have been an afterthought. In contrast, the O O E M approach is more focused on a process-oriented perspective through the abstractions of interacting agents and request propagation. Furthermore, O O E M models better organize of information for the purpose of modeling organizational processes. Application of OOEM: An Industrial Case Study 93 COMPARISON OF OOEM WITH IDEFO 5.1.6 Other Observations Other issues that were noted in the course of developing the models using both the O O E M and the IDEFO techniques include the following observations: 1. Event Sequence The O O E M technique does not explicitly model the sequence of events, or requests, in a process. This is unlike the IDEFO models which explicitly use a numbering convention to denote the prece-dence of functions. The order of requests is not clear from the semantics of the O O E M O C D in circumstances when there is more than one request being received and/or generated. This ambiguity does not pose a problem when it is possible to trace request propa-gation from the very first requesting object (usually an external object who is a customer of the process). However, ambiguity does arise when this tracing is not possible, for example, when an inter-nal object receives more than one request and each of the requests in turn generates multiple services and requests. Although the precon-dition for spawning a request may be inferred from the OTs through the services generated, unless these services are listed in a pre-ordered sequence, it is not possible to determine the exact sequence of the propagation of requests. A n example of such an ambiguity is illustrated in Figure 11 on page 69. The internal object "service chargehand" in this case receives two requests and generates five requests and the semantics do not indicate the order of requests (see also Figure 20). Although it is still possible to resolve the order of requests when they origi-nate from, or are sent to, the same object via the OTs, i.e., the IOT Application of OOEM: An Industrial Case Study 94 COMPARISON OF OOEM WITH IDEFO and EOT, the same cannot be said when there are multiple objects generating or receiving requests from a single object (the service chargehand in this case). FIGURE 20 Service Chargehand and Its Associated Requests Payment Service Quote Service Service Chargehand Allocate Parts t Close WO -Open WO Service WO The information on sequence of events/requests is important enough to be reflected in a model and the O O E M models should integrate this set of information. This can be achieved easily by for-malizing the presentation of the sequence of services and generated requests in the IOTs and the sequence of requests to system and ser-vices in the EOTs. Application of OOEM: An Industrial Case Study 95 COMPARISON OF OOEM WITH IDEFO 2. Conditional Control Another modeling aspect that is not addressed by O O E M is the issue of conditional control, that is, when an "if-then-else" type of decision has to be made in order to generate and propagate the appropriate requests. Namely, to determine which requests must be generated as part of a service. Presently, the rules and semantics of the O O E M methodology call for the representation of those objects and requests which are necessary in order for a process to be com-pleted from the perspective of the client. Such a perspective-ori-ented approach lacks the semantics to convey the necessary conditional information. FIGURE 21 Inventory Control and Its Associated Requests Q uote Availability of Parts Inventory Control Order Product Product Info Allocate Parts An example can be drawn from Figure 11 on page 69 where the request "order product" generated by the internal object "inventory Application of OOEM: An Industrial Case Study 96 COMPARISON OF OOEM WITH IDEFO control" is conditional upon the availability of parts to be allocated (see Figure 21). The conditional information here is not evident anywhere on the constructs and the semantics of the O C D and the OTs. It would seem that the "order product" request is generated as a result of the "allocate parts" request regardless of any constraints that may or may not be imposed on "inventory control" servicing the "allocate parts" request. This assumption apparently does not support the actual view of reality. Although IDEFO models do describe branching information as they occur, there is also no provision for the inclusion of conditional information. Hence, the IDEFO technique is as inadequate in this respect as O O E M . 3. Referencing The IDEF node index and node tree describing the order of IDEFO diagrams is analogous to a high-level pseudocode that describes a program's structure. The node index and node tree describe the structural relationships of the IDEFO Context Diagrams relative to one another. This high-level view of a system being modeled can be especially useful when modeling complex systems. For the O O E M method, a similar scheme for referencing the pro-cesses and sub-processes can be useful as well. However, the O O E M method does not currently provide for such representation. Similarly, a quicker, and perhaps a more direct notation-based Application of OOEM: An Industrial Case Study 97 COMPARISON OF OOEM WITH IDEFO approach for referencing between OCDs and the OTs could poten-tially alleviate the need for multiple cross-referencing. It is worth noting that a formal referencing scheme can be integrated without violating the existing O O E M rules. It may be worthwhile to consider the referencing method of the IDEFO technique in number-ing objects through a node index or a node tree. The O O E M method of process modeling can benefit from a high-level linkage view of the structural relationship among different levels of processes and objects. 5.1.7 Summary of Comparison With IDEFO Table 16 summarizes and discusses the general findings of the compar-ison between O O E M and IDEFO. The comparison between these two methods allows the following results to be inferred: 1. features of O O E M that are not found in IDEFO, 2. features of IDEFO that are not found in O O E M , 3. features which are common to both O O E M and IDEFO. Application of OOEM: An Industrial Case Study 98 COMPARISON OF OOEM WITH IDEFO TABLE 16 Comparative Characteristics of O O E M and IDEFO OOEM IDEFO Process-Orientation Object-orientation where object information is based on active and interacting agents in an organization. Interaction is through the propagation of requests for services, where the tracing of request propagation describes essentially the process itself. Through the objects and object templates, the abstracted process can be viewed as a world of interacting agents. No function-based information is shown. Functional-Orientation Individual functions describe the sequence of events or work-flow of a process. This concept of process does not include infor-mation on the active agents within the orga-nizational context. Rather, the focus is on systems analysis and design type of infor-mation, i.e., data-centric information. Process-based information is not explicitly abstracted. Clear and Rich Request Semantics The semantics of arrows representing the propagation of service requests are well defined. Arrows abstract requests without regard to the media upon which they are propagated and are treated simply as a flow of information (about the service request). Information flows on requests can be unidi-rectional or bidirectional, depending on the need to return request-specific information. Confusing Arrow Semantics The arrows used in context diagrams can be one of four abstractions: input, output, con-trol, or mechanism. Some of the arrows (input, output, control) identify whether the flow refers to that of a physical object or of information. Other arrows (mechanisms) refer only to physical flows. Arrows are unidirectional and an output can-not be identified with a particular input. Clear System Scope The scope of a system to be modeled and the ensuing boundary of a process is clearly defined through the identification of internal and external objects based on the OOEM object inclusion rule. The inclusion of selective information results in models that communicate only the rele-vant details. Absence of Boundary The definition of the scope of a system is not governed by any rule. The actual system is completely modeled regardless of rele-vance and application of results. For a complex system, the IDEFO model can be very large and incorporate unneces-sary information. Economizes on the Level of Details OOEM models are governed by the aggre-gation and decomposition rule that dictates the precise level of detail that should be modeled. Full Exposition of All Levels There is no rule governing the extent of detail that should be modeled. The objective is to model everything there is to be abstracted from a system. Application of O O E M : An Industrial Case Study 99 COMPARISON OF OOEM WITH IDEFO T A B L E 16 Comparative Characteristics of O O E M and IDEFO OOEM IDEFO Decomposability of Services A process described through an OCD can be hierarchically decomposed to reveal additional details of generated requests and the appropriate objects providing the ser-vices. The level of exposition of details is contingent upon the level of information deemed necessary for a model to be com-plete. The scope of the subsequent levels remains bound by the OOEM rules. Decomposability of Functions Functions are successively decomposed hierarchically until a system has been fully modeled. There is no constraint imposed on the scope and depth of a model except that the model must faithfully abstract all the information of a system. No Sequencing of Events The order in which objects receive requests or service requests is not explicitly described in either the OCDs or the OTs. However, it should be relatively easy to for-malize the semantics of presenting the ser-vices and requests in the intended order. Sequencing of Events The ordering of functions as they appear in the context diagrams describes the sequence of events as they unfold. The basic flow of events is linear although loop-back is allowed to show repetition of events. No Conditional Information The semantic for conditional control is not defined in both the Communication Dia-grams and the OTs. It is not possible to abstract and communicate if-then-else type of branching of service requests. It may be possible to integrate a conditional control scheme in the object templates. No Conditional Information The semantics of arrows in Context Dia-grams do not provide for conditional control of if-then-else type of condition checking. Guesses have to be made as to the condi-tional controls on the Context Diagrams since IDEFO does not provide for comple-mentary means, e.g., templates, of describ-ing functions. Poor Process-Object Referencing The referencing of objects and processes is through the assignment of unique names that does not indicate the relationship between processes and objects. It is expected that a referencing scheme similar to that of IDEFO can be integrated without violating the existing rules and semantics of the OOEM method. Node Referencing Scheme Different levels of process and functions are systematically referenced through a num-bering scheme as well as through the use of a node index and a node tree. Application of OOEM: An Industrial Case Study 100 AN OBJECT-ORIENTED COMPARISON 5.2 AN OBJECT-ORIENTED COMPARISON Since IDEFO is not object-oriented, the need for a "complementary" object-oriented approach to process modeling for the purpose of our evaluation is clear. This deficiency is addressed by drawing upon Jacobson's [15] object-oriented approach to business modeling. The choice of Jacobson's object-oriented view was mainly motivated by the following: 1. Jacobson's approach is centered on the concept of object-oriented analysis and design, and as such, offers a common basis for evaluat-ing O O E M as an object-oriented process modeling technique. 2. Jacobson's approach has also been applied to the domain of enter-prise modeling and is thus an excellent framework for comparative evaluation of O O E M as an enterprise modeling technique. Also, Jacobson discusses B P R and his approach should then presumably be positioned as a process modeling approach. A n overview of Jacobson's approach to process modeling is provided below. 5.2.1 Overview of Jacobson 's Object-Oriented Approach Jacobson's object-oriented modeling approach can be described as a modeling language which facilitates the descriptions of activities and processes found in businesses and of how services and products are delivered through the interaction of the processes [15]. The construct for modeling internal processes is the object. Fundamental to Jacob-son's approach to modeling is the notion of use case. A use case is Application of OOEM: An Industrial Case Study 101 AN OBJECT-ORIENTED COMPARISON described by a set of objects communicating with one another. The use case model is essentially an external view of a business process as per-ceived by the users of the process, and is defined by Jacobson [15]1 as a "sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the business system." More importantly, this externally driven view as defined by Jacobson is from the perspectives of the end-users of an IS. As is discussed later, this perpective biases Jacobson's object-oriented approach away from being a systems independent method. Jacobson's object-oriented approach includes modeling constructs sim-ilar to O O E M such as object classes, attributes, messages, and services, which are explained in Chapter 2. A different construct included in Jacobson's modeling language is that of an actor. A n actor refers to the notion of an agent as defined by a set of roles that it can play within a business system. For example, an agent could refer to the object sup-plier in Figure 11 where its set of roles is to respond to requests for price quotes, product information, and for the product itself. Jacobson draws a finer distinction in the types of objects that can exist in his object-oriented models as compared to the O O E M model. The following is a description of object types as defined by Jacobson [15]: 1. p. 103. Application of OOEM: An Industrial Case Study 102 AN OBJECT-ORIENTED COMPARISON 1. Entity Object — This refers to objects which represent "occurrences such as products, deliverables, documents, and other things that are handled in the business" [15] 1. 2. Control Object — This refers to objects which represent a set of tasks in the business environment. Typically, a control object does not interact directly with the customer and is usually performed by a resource that is specially trained or designed to perform the task. A resource need not be restricted to a human, but can include machin-ery as well. 3. Interface Object — This refers to objects whose tasks are to com-municate with the business environment. In addition, Jacobson lays out the steps towards building a model of a business system. The method is by no means formalized, but rather, is intended only as a guide for a system modeler. The steps described by Jacobson are listed in sequence as follows: 1. Build a use case model. • Identify actors, i.e., business partners, suppliers, customers, branches of the company. • Identify and define use cases through an actor and identify the whole course of events that wi l l impart to the actor a measurable value. • Sort use cases according to priority. • Formulate use cases descriptions. • Identify and choose metrics for measuring parameters and review use cases. 1. p. 340. Application of OOEM: An Industrial Case Study 103 AN OBJECT-ORIENTED COMPARISON 2. Build an object model. • Identify subsystems. • Formulate use cases descriptions in lieu of relationships to sub-system by identifying the actors, their attributes and any controls or restrictions that should be imposed. • Identify objects. The above summary is not intended to be a detailed survey of Jacob-son's object-oriented approach. It is only intended to provide a back-ground for the ensuing discussion. A comprehensive description of Jacobson's approach can be found in [15]. 5.2.2 Comparative Analysis with Jacobson 's Approach The above descriptions of Jacobson's object-oriented approach to mod-eling business processes provide a basis against which the modeling constructs of the O O E M may be evaluated. In performing the compari-son and the following analysis, attempts are made to address certain aspects of the O O E M method. 5.2.2.1 Model Constructs 1. The Actor Construct Actors, as defined by Jacobson, refer mostly to external objects in the O O E M models. One exception in the case presented here is in the O C D of the 'Service Repair Process' in Figure 11 on page 69. The internal object remanufacturing in this instance would be considered an actor Application of OOEM: An Industrial Case Study 104 AN OBJECT-ORIENTED COMPARISON according to Jacobson's approach. Although it may be argued that the classification of remanufacturing can be attributed to a modeler's adoption of a certain viewpoint while constructing a model, this exam-ple demonstrates that Jacobson's approach does not provide an unam-biguous definition of the actor construct. In fact, this ambiguity can be traced to Jacobson's approach being based on the perspective of systems analysis and development. From an IS point of view, the remanufacturing object would be treated as a user of an information system and would not be perceived as an organi-zational entity that belongs to part of a request propagation process (as is the case with O O E M ) . 2. The Use Case Construct The equivalent of the use case construct in the O O E M model is the external request construct. The best case mapping between O O E M and Jacobson's approach from a modeler's perspective can be described as follows: the modeler wi l l need to identify the clients (actors), i.e., the requesting objects, and the corresponding requests that these clients submit to the system. In essence, Jacobson's definition of the use case construct is very similar to the external request construct of the O O E M method. However, a contradiction wi l l arise when an internal object is modeled as an actor in Jacobson's model as noted in the first point. Under this scenario, an actor cannot possibly initiate an external request since it is internal to the system and, hence, wi l l only be able to Application of OOEM: An Industrial Case Study 105 AN OBJECT-ORIENTED COMPARISON initiate an internal request. In this instance, the use case construct fails due to the definition (or lack) of the actor construct. 3. The Interface & Control Object Constructs Generally, both the interface object and the control object from Jacob-son's approach map onto the internal object of the OOEM method. The distinction that Jacobson is able to draw between these two types of objects can be traced to the definition of a system's boundary as per-ceived by a modeler. Essentially, the distinction between interface and control objects can be resolved and collapsed into internal objects by the application of the scope identification rule from the OOEM meth-odology. Under this rule, the need to maintain such a distinction as pro-posed by Jacobson becomes redundant and can in fact result in ambiguity. In OOEM, the internal object construct corresponds to both interface and control object constructs of Jacobson's approach. This has the advantage of a richer semantic, yet general, representation. However, this generalization is accompanied by a loss of a certain degree of information through the aggregation of information. The dis-tinction maintained by Jacobson's approach allows a finer granularity in separating information and thus, the object constructs should reflect a finer level of detail. The issue that needs to be resolved here is the level of detail at which the abstracted information is just adequate in communicating the intended model. Application of OOEM: An Industrial Case Study 106 AN OBJECT-ORIENTED COMPARISON 4. The Entity Object Construct When compared against the OOEM approach, an equivalent construct for the entity object construct of Jacobson's model does not exist. In fact, the notion of entity object espoused by Jacobson refers to the internal attributes of OOEM objects, and in doing so, Jacobson violates the encapsulation principle of object-orientation. Furthermore, the very fact that Jacobson likened entity objects to data stores violates OOEM's attribute ownership rule that guarantees encapsulation. Again, the analogy of data stores on entity objects can be attributed to Jacobson's information system design orientation for his object-ori-ented approach. Since the OOEM method is conceived as independent of any systems design method, it does not suffer from inconsistencies with object-oriented principles. A summary of the above analysis is tabulated in Table 17. Application of OOEM: An Industrial Case Study 107 AN OBJECT-ORIENTED COMPARISON TABLE 17 Construct Mappings Between O O E M and Jacobson Jacobson's Modeling Constructs Equivalent OOEM Modeling Constructs Actor Generally external object constructs, although exception exists. Use Case External request and request propa-gation constructs. The external request construct is contingent upon the actor construct not being violated. Interface & Control Object Internal object constructs. Entity Object No precise equivalent, although anal-ogous to the information about objects and their attributes. A widely recognized problem of object-oriented methods pertains to the definition and identification of objects and, ultimately, the scope of an object-oriented model. This problem is also clearly present in Jacob-son's object-oriented approach. While Jacobson distinguishes among three classes of objects, he stops short of offering a fundamental basis for drawing the distinction. Services are provided by both interface and control objects (as is the case with O O E M ' s internal objects) and the type of objects may change contingent upon the scope of a system as defined by a modeler. For example, in changing the scope of analysis, Application of OOEM: An Industrial Case Study 108 AN OBJECT-ORIENTED COMPARISON an interface object may become a control object. Such inconsistency and ambiguity is not found in O O E M models. An example from the case study can be drawn from the service repair process. By Jacobson's definition, the remanufacturing object in Fig-ure 11 is a control object when it is viewed as representing a set of (remanufacturing) tasks that is "performed by one resource instance which typically is a specialist or a routine worker, not dealing directly with the customer." [15]' At the same time, the remanufacturing object is also an interface object that represents "a set of operations in the business each of which is ... performed by one and the same resource" and whose "tasks involve communicating with the environment of the business." [15] 2 From these two definitions, it is difficult to draw such a distinction when defining an object. In contrast, it is obvious that all the internal objects in Figure 11 can be unambiguously defined as such when using the O O E M method. The above analysis illustrates that the O O E M method provides a more consistent approach to building an object-oriented model. Since the O O E M methodology includes well-defined rules to object-oriented modeling, it is more consistent and less arbitrary in identifying and defining the respective constructs of the model. The direct benefit is an object-oriented model that captures and communicates only the infor-mation which is relevant to the objective of the modeling task at hand. 1. p. 340. 2. p. 340. Application of OOEM: An Industrial Case Study 109 S U M M A R Y In effect, an O O E M model conveys a clearly defined scope of a prob-lem and its relevant information. This in itself is an improvement over Jacobson's object-oriented approach, which does not provide modeling rules. Furthermore, Jacobson's approach does not clearly distinguish between the two levels of information: the organizational and the infor-mation system. This results in confusion over what information of a process should, or should not, be included in an object-oriented model. 5.3 SUMMARY The analyses presented in this chapter focus on two aspects of O O E M . The first concentrates on O O E M as process modeling technique while the second looks at O O E M as an object-oriented approach in compari-son with Jacobson's object-oriented approach. The main observations drawn from the comparisons are as follows: 1. The O O E M rule-based methodology provides a more systematic approach to process modeling than either the IDEFO technique or Jacobson's approach. The rules provide a clear definition of an object and this enables the unambiguous identification of objects within a model. This also leads to an object-oriented model whose boundary is more precise and whose use of the request construct is well defined and richer in its semantics. 2. The O O E M modeling concepts are based on ontology and is not "burdened" by the objective of IS development (as is the case with the IDEFO technique and Jacobson's approach). As such, O O E M provides a better approach to enterprise and process modeling through the deliberate exclusion of lower level details that would otherwise hamper the understanding of business models. Application of OOEM: An Industrial Case Study 110 SUMMARY 3. Although it is established that O O E M offers a more systematic approach to process modeling, there remain semantic issues of event sequencing, conditional controls, and referencing which could be integrated into the O O E M method to improve it. Application of OOEM: An Industrial Case Study 111 CONCLUSION Object-oriented technology is being applied in many areas, not least of which is the domain of systems analysis. Hence it is a natural extension for object-orientation to also be used to facilitate process modeling and, in a broader context, enterprise modeling as well. It is this aspect which is the focus of this thesis. The O O E M methodology proposed by Wand and Woo and the oppor-tunity for an industrial case study provided the motivation to assess O O E M as an enterprise modeling method. The primary focus is in the application of the rule-based approach of O O E M to model and commu-nicate both the structural relationship and the dynamic character of the operating environment of a business. In doing so, O O E M models could be evaluated as an object-oriented approach to process modeling as well as a process modeling technique. Application of OOEM: An Industrial Case Study 112 This thesis presented the concepts of process modeling techniques in general and selected the Integrated Definition technique, IDEFO, as a representative framework for evaluating O O E M models in the domain of process modeling. The concepts and principles of the O O E M meth-odology were described and modeling constructs and semantics explained. The set of rules developed by Wand and Woo according to ontological principles served to define the scope of a model, the identi-fication of objects, the appropriate inclusion of services and attributes, the ownership of these attributes, and the appropriate inclusion of com-posites in an O O E M model. The information gathered from the case project with D D A B C was applied to developing enterprise models and process models using four approaches: 1. Activity Work-Flow analysis1, 2. OOEM analysis, 3. IDEFO analysis, and 4. Jacobson's object-oriented business modeling approach. The Activity Work-Flow analysis provided an independent method of modeling the required information. The IDEFO technique provided a functional approach to viewing the same information while Jacobson's 1. Unpublished method developed by Peng Tu as part of a course project under the supervision of Dr. Yair Wand at the University of British Columbia, Faculty of Commerce and Business Administration. Application of OOEM: An Industrial Case Study 113 model provided the basis for evaluating O O E M as an object-oriented method. Observations from the various models and modeling methods indicate that the O O E M method does provide a more systematic approach to defining objects and to building object-oriented enterprise models. These O O E M models also exhibit crisp boundaries that clearly delin-eate objects which are internal and external to a system, and identify the objects which are necessary and relevant to the situation being modeled. In other words, the O O E M models developed for the case project tended to communicate only essential information. In order to address one of the research questions posed in Chapter 1 as to whether O O E M can be used as a process modeling methodology, we have to examine whether O O E M , through the use of OCD' s and OT's, is able to sufficiently abstract and communicate information about pro-cesses at least as well as the IDEFO technique. The view of processes is perhaps best defined by Davenport's definition of business processes [6] [7] "as a set of logically related tasks performed to achieve a defined business outcome," where a set of processes forms a business system. As noted in Chapter 2, it is this "narrow" view of processes that is adopted in the evaluation of the O O E M method. The comparison made between the IDEFO technique and the O O E M method shows that the O O E M models are able to capture all the essen-tial information required to build a process model. If the O O E M method is modified to include sequencing information, the information Application of OOEM: An Industrial Case Study 114 from the O O E M models can be used by a modeler to reconstruct the equivalent models using the IDEFO technique. However, the converse is not always true. Information needed to identify requests and request propagation cannot be always be inferred from the arrow semantics of the IDEFO models. This conclusion alone shows that the O O E M method, as a process modeling approach, to be at least as "complete" as the IDEFO technique. Another conclusion that can be drawn from the analysis is that the O O E M method embodies an integrated-domain orientation towards modeling. That is, information about state, dynamics, interactions and structure are communicated by the O O E M models. This is in contrast to both the IDEFO and Jacobson's OO techniques where only state and structural information are conveyed. The integrated-domain orientation is also supported by Davenport and Short's view of business processes as a collection of interacting business units [7] which undergoes state changes. The comparison with IDEFO also revealed several possible improve-ments to the O O E M methodology. Three issues outlined in this thesis refer to the inadequacy of semantics in representing and communicat-ing the sequencing of events/requests, the conditional control of request generation, and the absence of a referencing scheme among process, sub-processes, and OTs. The application of the O O E M method to the modeling of business activity at D D A B C illustrated that O O E M models are better able to Application of OOEM: An Industrial Case Study 115 CONTRIBUTION present a process-oriented view even though the O O E M method is not perceived as a process modeling approach. The high-level view offers an enterprise view of an organization while the lower-level models present business activities distinguished as processes. 6.1 CONTRIBUTION The application of the O O E M methodology to an industrial case offered the opportunity to assess the correctness and completeness of the methodology in a real-world setting. This process affords the opportunity to improve not just the method itself, but the semantics used to represent and describe O O E M models. In doing so, this thesis contributed to the development of the O O E M methodology. Analyses based on an industrial case also provided insights into the application of O O E M analysis as a viable approach to enterprise and process mod-eling outside of academia. In addition, the comparison of O O E M against the "mature" IDEFO standard provides additional perspective to the existing literature on process modeling. 6.2 LIMITATIONS AND FUTURE RESEARCH In spite of the opportunity to apply an industrial case study to the eval-uation of the O O E M methodology, the evaluation process is a prelimi-nary effort and is by no means intended to be an all-encompassing study. This case study is the first practical application of the O O E M method. Therefore, future applications and evaluations in a corporate Application of OOEM: An Industrial Case Study 116 LIMITATIONS AND FUTURE RESEARCH setting wil l have to be undertaken to further test and improve the method. A more formal and rigorous empirical approach to evaluating the O O E M method would also contribute significantly to further improving the modeling paradigm. A further extension of the O O E M modeling rules and constructs could be the adaptation of O O E M as an IS analysis, design, and development methodology. Application of OOEM: An Industrial Case Study 117 BIBLIOGRAPHY [1] Acly E., "Application Development and Reengineering," IDC/Technology Investment Strat-egies, January 24, 1994, 1-42. [2] A T & T Quality Steering Committee, Describing Information Processes: The FIP Technique, A T & T Bell Laboratories, 1992. [3] A T & T Quality Steering Committee, Reengineering Handbook, A T & T Bell Laboratories, 1991. [4] Coad Y . , and Yourdon E., Object-Oriented Analysis, Second Edition, Prentice-Hall (Yourdon Press), Englewood Cliffs, NJ , 1991. [5] Curtis B., Kellner M . , and Over J., "Process Modeling," Communications of the ACM, 35(9), September 1992, 75-90. [6] Davenport T.H., Process Innovation, Harvard Business School Press, Boston, Massachusetts, 1993. [7] Davenport T.H., and Short J.E., "The New Industrial Engineering: Information Technology and Business Process Redesign," Sloan Management Review, Summer 1990, 11-27. [8] Dennis A.R., Daniels R .M. , Hayes G., and Nunamaker J.F., "Methodology-Driven Use of Auto-mated Support in Business Process Re-Engineering," Journal of Management Information Sys-tems, 10(3), Winter 1993-94, 117-138. [9] Gartner Group, "Client/Server Computing in the 1990s," Information Technology Manage-ment Academic Program, R-001-102, January 6, 1994. Application of OOEM: An Industrial Case Study 118 [10] Guha S., Kettinger W.J., Teng J.T.C., "Business Process Reengineering: Building a Comprehen-sive Methodology," Information Systems Management, Summer 1993, 13-22. [11] Hammer M . , and Champy J., Reengineering the Corporation: A Manifesto for Business Revolu-tion, HarperCollins Publishers, N Y , 1993. [12] Henderson-Sellers B. , and Edwards J.M., "The Object-Oriented Systems Life Cycle," Communi-cations of the ACM, 33(9), September 1990, 142-159. [13] Herbst H. , Knolmayer G., Myrach T., and Schlesinger M . , "The Specification of Business Rules: A Comparison of Selected Methodologies," Methods and Associate Tools for the Information Systems Life Cycle (A-55), A . A . Verrijn-Stuart and T.W. Olle (eds.), 1994, 29-46. [14] Iivari J., "Object-Oriented Information Systems Analysis: A Comparison of Six Object-Oriented Analysis Methods," Methods and Associate Tools for the Information Systems Life Cycle (A-55), A . A . Verrijn-Stuart and T.W. Olle (eds.), 1994, 85-110. [15] Jacobson I., Ericsson M . , and Jacobson A. , "The Object Advantage: Business Process Reengi-neering with Object Technology," A C M Press, N Y , 1994. [16] Katz R.L. , "Business/Enterprise Modeling," IBM Systems Journal, 29(4), 1990, 509-525. [17] Klein M . M . , "Reengineering Methodologies and Tools: A Prescription of Enhancing Success," Information Systems Management, Spring 1994, 30-35. [18] Krasner H. , Terrel J., Linehan A. , Arnold P., and Etc W., "Lessons Learned from a Software Pro-cess Modeling System," Communications of the ACM, 35(9), Spetember 1992, 91-100. [19] Laamanen M.T., "The IDEF Standards," Methods and Associated Tools for the Information Sys-tems Life Cycle (A-55), A . A . Verrijn-Stuart and T.W. Olle (eds.), 1994, 121-130. [20] Lundeberg M . , Handling Change Process: A Systems Approach, Studentlitteratur, Sweden, 1993. [21] Minkowitz C , "Formal Process Modelling," Information & Software Technology, 35(11/12), November/December 1993, 659-667. [22] Ngwenyama O.K., and Grant D.A., "Enterprise Modeling for C I M Information Systems Archi-tectures: An Object-Oriented Approach," Computers & Industrial Engineering, 26(2), 1994, 279-293. [23] Orr K. , Gane C , Yourdon E., Chen P.P., and Constantine L . L . , "Methodology: The Experts Speak," Byte, April 1989, 221-233. [24] Parsons J., and Wand Y . , "Object-Oriented Systems Analysis: A Representation View," Working Paper 93-MIS-001, Faculty of Commerce and Business Administration, University of British Columbia, January 1993. Application of OOEM: An Industrial Case Study" 119 [25] Ramackers G.J., "Model Integration and Model Execution," Information Systems Life Cycle (A-55), Verrijn-Stuart, and Olle T.W. (eds), Elsevier Science, North-Holland, 1994, 223-239. [26] Rumbaugh J., Blaha M . , Premerlani W., Eddy F., and Lorensen W., Object-Oriented Modeling and Design, Prentice Gall, Englewood Cliffs, NJ, 1991. [27] Standard for Integration Definition for Function Modeling (IDEFO), Federal Information Pro-cessing Standards Publication 183, December 21, 1993. [28] Tapscott D., and Caston A. , Paradigm Shift, McGraw-Hill, N Y , 1993. [29] "The Role of IT in Business Reengineering," I/S Analyzer, 31(8), August 1993, 1-16. [30] Wand Y . , and Weber R., "An Ontological Model of An Information System," IEEE Transactions on Software Engineering, 16( 11), November 1990, 1282-1292. [31] Wand Y . , and Woo C C , "Object-Oriented Analysis - Is It Really that Simple?" Proceedings of the 3rd Workshop on Information Technology & Systems (Orlando, Florida, Dec. 1993), 186-195. [32] Wang S., "OO Modeling of Business Processes," Information Systems Management, Spring 1994,36-43. [33] Yourdon E., Modern Structured Analysis, Prentice Hall, N Y , 1989. [34] Zhao, H . Object-Oriented Enterprise Modeling, unpublished Masters' thesis, Management of Information Systems Division, Faculty of Commerce and Business Administration, University of British Columbia, July 1995. Application of OOEM: An Industrial Case Study 120 OOEM MODEL OF SERVICE REPAIR ACCOUNTING Application of OOEM: An Industrial Case Study 121 OBJECT COMMUNICATION DIAGRAM A.1 OBJECT COMMUNICATION DIAGRAM Legend ( ) External Object Internal Object - • Request : System ; Scope / Inventory \ Control Update Charges -Update Charges -Close Service Account Service Admin. 1 Update Labour Hours Customer Payment Accounts Receivable te)«-Accounts Payable Cut Cheques Payroll Debit Warranty Credit Supplier Payment Application of OOEM: An Industrial Case Study 122 INTERNAL OBJECT TEMPLATES A.2 I N T E R N A L O B J E C T T E M P L A T E S 1. Internal Object Template (IOT) of Accounts Receivable Object Accounts Receivable Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Serv ice U pdate - Account # - Cus tomer account # U Adm in charges - Charge info (parts info, costing info) - Accoun t credit/debit info M R e m a n u - Update - Account # - Cus tomer account # U facturing charges - Charge info (work done info, parts info, costing info) - Accoun t credit/debit info M Serv ice C lose - Account # - A m o u n t p a y a b l e M P a y m e n t Cus tomer Adm in serv ice account - Credit limit M 2. Internal Object Template (IOT) of Accounts Payable Object Accounts Payable Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Payroll Cut cheques - Employee ID - Pay info (hours worked, pay type, overtime time info) - Employee pay info (total pay: year-to-date, current period, deduct-ions, benefits) U/M Supplier Debit warranty credit - Distributor account info (to-date credit/debit balances, credit limit) • Warranty credit info (application #, credit awarded/ rejected) - Receivable info (customer account #, G/L account) M Application of OOEM: An Industrial Case Study 123 EXTERNAL OBJECT TEMPLATES 3. Internal Object Template (IOT) oi Payroll Object Payroll Requesting Services Interface Internal Generated Receiving Objects Attributes Attributes Requests Objects Service Update - Employee ID - Total hours worked M Cut cheques Accounts Payable Admin labour hours - Hours committed A.3 EXTERNAL OBJECT TEMPLATES 1. External Object Template (EOT) of Customer Object Custom er Requests to System Receiving Object Request ing Objects Services Interface to Attributes Accounts Receivable Pay ment Billing info 2. External Object Template (EOT) oi Supplier Object Suppl ier Requests to System Receiv ing Object - Debit warranty credit Accounts Receivable - Payment Accounts Payable Request ing Objects Services Interface to Attr ibutes Application of OOEM: An Industrial Case Study 124 EXTERNAL OBJECT TEMPLATES 3. External Object Template (EOT) of Inventory Control Object Inventory Cont ro l Requests to System Receiv ing Object - Update charges Accounts Receivable Request ing Objects Services Interface to Attr ibutes 4. External Object Template (EOT) of Service Admin Object Service A d m i n Requests to System Receiv ing Object - Update charges - Close service account Accounts Receivable - Update labour hours Pay roll Request ing Objects Services Interface to Attr ibutes Application of OOEM: An Industrial Case Study 125 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0087062/manifest

Comment

Related Items