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 P A R T I A L F U L F I L L M E N T OF T H E REQUIREMENTS FOR THE D E G R E E OF M A S T E R OF SCIENCE IN BUSINESS A D M I N I S T R A T I O N in THE F A C U L T Y OF C O M M E R C E A N D BUSINESS A D M I N I S T R A T I O N (Management Information Systems Program)  We accept this thesis as conforming to the required standard  T H E UNIVERSITY OF BRITISH C O L U M B I A January 1996 © S o o n AunYeap, 1996  In  presenting this  degree at the  thesis  in  University of  partial  fulfilment  of  of  department  this or  thesis for by  his  her  representatives.  for  an advanced  Library shall make  it  agree that permission for extensive  scholarly purposes may be  or  requirements  British Columbia, I agree that the  freely available for reference and study. I further copying  the  It  is  granted  by the  understood  that  head of copying  my 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  DE-6 (2/88)  P  W  .  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 compare the OOEM models against two other modeling techniques: the Integrated Definition (IDEFO) technique and Jacobson's object-oriented 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.  T A B L E OF CONTENTS  LIST OF T A B L E S vii  LIST OF FIGURES ix  CHAPTER 1  1  INTRODUCTION 1.1 MOTIVATION  1  1.2 BACKGROUND  3  1.3 RESEARCH QUESTIONS 5 1.4 ORGANIZATION CHAPTER 2  FOUNDATION  6  7  2.1 ENTERPRISE MODELING  7  2.2 PROCESS MODELING TECHNIQUE 2.2.1  Introduction  8  8  Application of O O E M : A n Industrial C a s e Study  Contents  2.3  2.2.2  Conceptual Framework  2.2.3  IDEFO: A n Example of P M T  3.1  3.2  3.3  Background 12  2.2.3.2  Objectives & Applicability 13  2.2.3.3  Model Concepts 15  OBJECT-ORIENTED ENTERPRISE M O D E L I N G 2.3.1  Introduction  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  INTRODUCTION  16  16  27  27  3.1.1  The Company  3.1.2  Business Environment  3.1.3  T h e Business  3.1.4  IS Infrastructure  28 32  34 37  3.1.4.1  Hardware 37  3.1.4.2  Systems 39  BUSINESS PROCESSES  41  3.2.1  B R A N C H ORGANIZATION & OPERATION  3.2.2  T H E S E R V I C E REPAIR P R O C E S S 3.2.2.1  A n Overview 44  3.2.2.2  Tracking WIP 47  42  44  K E Y ISSUES 5 0 3.3.1  3.3.2  3.4  12  2.2.3.1  A N INDUSTRIAL C A S E  CHAPTER 3  9  IS Infrastructure  50  3.3.1.1  Hardware 50  3.3.1.2  Systems 51  T h e Service Repair Model  CASE ANALYSIS  51  52  Application of OOEM: An Industrial Case Study  iv  Contents  3.4.1  C H A P T E R 4  Process Analysis  52  O O E M & IDEFO M O D E L I N G  56  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 ( E O T ) 62  4.1.2  O O E M Model of D D A B C  64  4.1.3  O O E M Model of the Service Repair Process  67  4 . 2 IDEFO MODELING 7 3  CHAPTER 5  4.2.1  IDEFO Model Building  73  4.2.2  High-Level Reference Description  4.2.3  Context Descriptions  4.2.4  IDEFO Model of the Service Repair P r o c e s s  74  76  C O M P A R A T I V E A N A L Y S I S OF O O E M  78  84  5.1 COMPARISON OF OOEM WITH IDEFO 8 5 5.1.1  Separability of Process & Functional Information  5.1.2  Request Semantics  5.1.3  S c o p e of Model  5.1.4  Model Efficiency  5.1.5  Level of Information Representation  5.1.6  Other Observations  5.1.7  Summary of Comparison With IDEFO  85  87  91 92 93  94 98  5.2 A N OBJECT-ORIENTED COMPARISON 1 0 1 5.2.1  Overview of Jacobson's Object-Oriented Approach  5.2.2  Comparative Analysis with Jacobson's Approach 5.2.2.1  101 104  Model Constructs 104  5.3 S U M M A R Y 1 1 0  Application of OOEM: An Industrial Case Study  v  Contents  CHAPTER 6  112  CONCLUSION 6.1 CONTRIBUTION  116  6.2 LIMITATIONS A N D FUTURE RESEARCH BIBLIOGRAPHY  APPENDIX A  116  118  O O E M M O D E L OF S E R V I C E R E P A I R ACCOUNTING 121 A.1 OBJECT COMMUNICATION D I A G R A M A.2 INTERNAL OBJECT TEMPLATES  123  A.3 E X T E R N A L OBJECT TEMPLATES  124  Application of OOEM: An Industrial Case Study  122  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 Template (EOT) 60  TABLE 4  Internal Object Template (IOT) o f D D A B C Object  TABLE 5  External Object Template (EOT) of Customer Object 66  TABLE 6  External Object Template (EOT) of Supplier Object  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  65  66  70  T A B L E 10 Internal Object Template (IOT) of Inventory Control Object 71 T A B L E 11 Internal Object Template (IOT) of Service Floor Object 71 T A B L E 12 Internal Object Template (IOT) of Accounts Receivable Object 71  Application of OOEM: An Industrial Case Study  vii  Contents  T A B L E 13 Internal Object Template (IOT) of Remanufacturing Object 72 T A B L E 14 External Object Template (EOT) of Customer Object 72 T A B L E 15 External Object Template (EOT) of Supplier Object  72  T A B L E 16 Comparative Characteristics of OOEM and IDEFO 9 9 T A B L E 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 FIGURE 9 An OOEM Object Communication Diagram  54  59  FIGURE 10 OOEM Object Communication Diagram: Request Propagation Analysis o f ' D D A B C ' 64 FIGURE 11 OOEM Object Communication Diagram: Request Propagation Analysis of 'Service Repair Process' 69 FIGURE 12 Node Index for Service Repair FIGURE 13 Node Tree for Service Repair FIGURE 14 Syntax of a Function  75 76  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 FIGURE 21 Inventory Control and Its Associated Requests  Application of OOEM: An Industrial Case Study  95 96  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 Carson 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 DieselAllison 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-oriented method within an industrial setting, and in the process, to assess the usefulness of the object-oriented method in modeling an organization. The object-oriented method discussed in this thesis is the ObjectOriented 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. However, OOEM is unique in its rule-driven methodology to modeling. As such, this thesis seeks to examine the value of this departure in methodology 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 processes 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 technology (IT) that could be deployed to give DDA BC a sustainable competitive 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 recognizes 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 solutions, 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 business 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 industrial setting. In addition to the case-based approach to evaluating OOEM, a highlevel comparative analysis against the Integrated Definition (IDEFO) standard is undertaken to gain a better perspective of OOEM as a process 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 methodologies. Foremost is the traditional approach by way of data modeling 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 process 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 traditional structured analysis techniques, distinguishes itself from the datacentric 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-oriented 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 processes generally rather than business processes specifically. PMT includes petri-net, system dynamics, and the IDEFO modeling techApplication 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 techniques as an process modeling methodology? These questions are posed in an attempt to ascertain the appropriateness and value of using OOEM as a modeling methodology both at the organizational level, i.e., enterprise modeling, and at the systems planning 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 understanding 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 following order: literature survey, case presentation, description of models, analysis, conclusion, bibliography, and appendices. Chapter 2 presents a survey of the literature on enterprise modeling, process modeling 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 discusses the issues in using OOEM as an enterprise modeling methodology 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 organization's structure, needs, and future direction. In other words, the organization 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 perspective of a system. Organizational modeling has been linked in some  Application of OOEM: An Industrial Case Study  7  P R O C E S S 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 processes. Enterprise modeling can thus be viewed as the high-level modeling of business processes, i.e., modeling at the enterprise level. However, enterprise modeling in the IS literature tends to allude modeling activities to IS process modeling [5], and in instances when references 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  2.2.1  PROCESS MODELING TECHNIQUE  Introduction  Process modeling distinguishes itself from other IS modeling techniques such as structured analysis and entity-relationship diagramming. 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  P R O C E S S 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, coordination technology, and process-driven software development. Literature 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 substructure." Whether an element's structure must be further broken down to  Application of OOEM: An Industrial Case Study  9  P R O C E S S MODELING TECHNIQUE  support the process model objectives determines whether a process element 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 process 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 process 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 criteria. 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 relationship 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 perspectives 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 perspectives outlined above.  Application of OOEM: An Industrial Case Study  11  P R O C E S S 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, equipment, 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 P M T  2.2.3.1 B a c k g r o u n d  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 I C A M 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  P R O C E S S 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 represents the time-varying behavioral characteristics of the modeled subject area or system. IDEF1 was further enhanced in 1983 through the U.S. Air Force Integrated 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 Information Processing Standards (FIPS) publications for modeling techniques based on the IDEFO [27] and IDEF1X [19][29] techniques. The standards were published at the end of 1993 and were designated as follows: 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 (information or objects) that support the integration of those functions. 2. To provide a modeling technique which is independent of Computer-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 characteristics: •  Generic — for the analysis of systems of various purposes, scopes, and complexity.  • Rigorous and precise — for producing correct and usable models without imposing constraints on the analyst. •  Concise — to facilitate understanding, communication, consensus, and validation (through model documentation).  •  Conceptual — to represent functional requirements rather than physical or organizational implementations. The IDEFO technique 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 publication also identified the following enterprise and application development projects that could benefit from the IDEFO technique: 1. Those that require a modeling technique for the analysis, development, reengineering, integration, or acquisition of information systems. 2. Those that involve the incorporation of a system or enterprise modeling technique into a business process analysis or software engineering 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 participants. More importantly, perhaps, is that the IDEFO technique also provides the framework to manage large and complex projects through qualitative measures of progress, and a reference architecture for enterprise 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 applying 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 judgement 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 independent 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 boundary of the domain being modeled. The following details the six fundamental OOEM modeling principles as formulated by Wand and Woo: Principle 1 The regular activities of an organization include the information processing activities.  The implication of Principle 1 is that activities relating to the generation of services and activities related to information processing as well as the actual processing of commodities should be included in an enterprise model. In contrast, structured analysis focuses only on information 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-centric 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 communication 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 system.  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 possesses 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 modeling 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 formulating 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 properties 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. All 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 functions 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 combinations do not necessarily represent valid states of things. Having described the characteristics of things and properties, the following paragraphs describe the dynamics of things based on ontological 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 modeled 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 transformation 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 Properties of Object  The four characteristics of the model object are encapsulation, composition, 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 purpose 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 consists of information about the state of another object. In essence, an object model comprised of the objects and their dynamics 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 cannot be aware of services and state transitions that affect non-interface attributes. This is the notion of encapsulation when applied to modeling.  Application of OOEM: An Industrial Case Study  24  OBJECT-ORIENTED ENTERPRISE MODELING  In the process of modeling a component of an organization, the modeler 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 internal or external to the system being modeled.  2.3.2.5 R u l e - B a s e d Model Building  The following rules were developed by Wand and Woo [31] as guidelines 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 guidelines for identifying and defining an enterprise model of an organization. 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  INTRODUCTION  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 redesigned, 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 operations 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 processes 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. D D A BC distributes and services engines manufactured by Detroit Diesel, Volvo, and Mercedes, and transmissions manufactured by Allison. DDA BC's annual sales revenue 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 D D A B C ' s Branches in British Columbia  SURREY Service Branch  KAMLOOPS Service Branch  Tumbler Ridge Service Branch  Elkfo Service B ranch  CRANBROOK Service Branch SURREY Detroit Diesel-Allison BC Head Office NANAIMO Service Branch  CAMPBELL RIVER Service Branch  PENTICTON Service Branch  3 I  Greenhills Service Branch  1 ] 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 province 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.  FIGURE  2  High-Level Organizational Chart Board of Directors  Allan Cullen President  Financial Manager  Computing  Accounting  Vice President  Branch Manager  Vice President  Branch Operations  Surrey  Sales  Parts  Parts & Service  Administration  Sales  Service & Warranty  Parts Department  Payroll &  Inventory Control  Accounts Payable  & Traffic  Accounts  Branch Manager  Field / Diesel  Receivable  Cranbrook  Service Shop  Dealer Development & Training Coordinator  S60 (Kamploops & Northern BC)  Service Manager  Kohler Generator Sets  Branch Manager  Truck  Indirect Sales  Kamploops  Service Shop  Alison/S60/S50  Branch Manager Campbell River  Allison Service  Branch Manager  Injector  Nanaimo  Department  Industrial Detroit & Perkins  Marine "Small" Detroit, Perkins, Volvo  Branch Manager  Marine "Large"  Penticlon  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, journeymen, 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  B u s i n e s s 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 entities or resources. Examples in the case of DDA BC include suppliers and utility companies. The following paragraphs summarize the key players and the conditions 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 servicing 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 transmissions. 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 stable market; its products are also well established. Any existing competitive 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, transmissions, 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 Corporation, 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)  SERVICE  PARTS  PRODUCT  SUB-TOTAL  TOTAL  MINING  Coal  90000  4500  150  13650  Copper  1500  1500  0  3000  Other  100  50  0  150  Equipment  1500  1000  1000  3500  Off-Highway Truck  2000  1000  300  3300  Highway Truck  1000  500  0  1500  Towing  400  200  100  700  Ship Handling  100  100  200  400  Fishing  50  50  300  400  Pleasure  10  10  1800  1820  3320  1800  1000  300  3100  3100  Standby  10  80  1600  1690  Marine  5  10  250  265  4000  16800  FORESTRY  8300  MARINE  TRUCKS (not incl. forestry)  Highway GENERATOR SETS  1955  INDUSTRIAL EQUIPMENT  Miscellaneous TOTAL  1500  1500  1000  18975  11500  7000  Application of OOEM: An Industrial Case Study  4000 37475  35  INTRODUCTION  Each of D D A B C ' s six branches maintains its own inventory warehouse. 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 warehouse. Approximately 17,000 unique parts are maintained in the inventory 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 transfers 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 Section 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 communication 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 administration. A description of the hardware distribution topology is illustrated in Figure 4.  Application of OOEM: An Industrial Case Study  37  INTRODUCTION  FIGURE  4  Hardware Topology Kamloops  1 r  To flower/vet at DDC  r-a  -a —a -a H3  Campbell River  t 56 kb satellite link through EDS'NETl  Surrey Head Office (Wang VS10000)  cn  CH  Ethernet-Based Local Area Networks  Cranbrook  cn  Cable  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 information 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 ). The ROSS package 2  consists of the following three main functional components: 1. Shop Floor Management, 2. Customer Management, and 3. Financial Management, while the M C system provides the following three key functions: 2  1. Material Control (inventory management), 2. Customer Control, and 3. Vendor Control. These packages were fully implemented in 1982 and have undergone substantial enhancements. All of the application packages were developed in-house and DDA BC has complete ownership of all the source codes to the application packages. Furthermore, the application packages 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  Workflow Linkages Among Application Packages  FIGURE 5  Inventory Management  Order Entry  Job Pricing / Costing  Job History  Invoicing  WIP Tracking  J  Customer History  SERVICE Focus Forecasting  MANAGEMENT MATERIAL MANAGEMENT  Receiving  j J  >  A  Expediting  Purchase Ordering  j J  j —.  Accounts Receivable  FINANCIAL MANAGEMENT  1  General Ledger  Payroll  Accounts Payable  J  J  A high-level description of the package workflow between ROSS and M C is described in Figure 5. Figure 5 also presents another perspec2  tive of the application packages, where the application packages' modules 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 P R O C E S S E S  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  BUSINESS PROCESSES  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 P R O C E S S E S  business processes is focused on branch operations. Moreover, the redesign of service branch processes is expected to generate a significant improvement in operating revenue and expenses. Among the six service branches, the Surrey branch generates the highest 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. Section 3.2.1 and Section 3.2.2 present detailed surveys of the Surrey service branch and its service process respectively.  3.2.1 BRANCH ORGANIZATION & OPERATION A service branch is typically organized along the following four functional areas: 1. Job Control 2. Material Control 3. Sales 4. Administration The job control function refers to the servicing, repairing, and overhauling of engines and transmissions, while the material control function 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 opportunities in the market and in the OTC parts sales. The administration Application of OOEM: An Industrial Case Study  42  BUSINESS P R O C E S S E S  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  Branch Manager Receptionist / Clerk  Parts Foreman  Partsmen  Warehousemen  Parts Sales  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 P R O C E S S E S  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 generators. • 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 activityworkflow diagram.  Application of OOEM: An Industrial Case Study  44  BUSINESS PROCESSES  Activity-Workflow Description of the Service Repair Process  FIGURE 7  CUSTOMER  CLERK  CHARGEHAND  MECHANICS  PARTS MEN  ACCOUNTS  OEM  PAYABLE  service requests & quotes | diagnosis  confirm servicing  enter data / create WO  receive confirmation  process WO I  service/  service:report parts;request  repair  process parts request  parts request  labour/parts charges  ship verify report receive job story  activity  job story writeup  post labour charges  O  alternative activity  info, flow (normal)  confirm job story  story  1  1  consolidate job story  jobstory.  verify job  verify job confirmation / correction  story (exception)  split job story warranty claim data entry  completed job story  invoice / request for payment invoicing  forward charges invoice / request for payment  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 P R O C E S S E S  includes the problem description by the customer, the serial number of the engine (or transmission or parts), warranty information, the classification 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 chargehand who then verifies that the job story is: Application of OOEM: An Industrial Case Study  46  BUSINESS P R O C E S S E S  1. Fair and accurate, i.e., that the pertinent parts and labour information 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 customer 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 possession 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 payment. If the job type is W, i.e., the engine is under warranty, a different procedure 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 process. In the course of a service repair job, the costs of labour and parts  Application of OOEM: An Industrial Case Study  47  BUSINESS P R O C E S S E S  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 operation 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 : A n Industrial C a s e Study  48  BUSINESS P R O C E S S E S  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 productivity, 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 transferring 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  KEY ISSUES  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 concern: 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 industry. 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 S y s t e m s  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 company's ability to adapt quickly to changes in the business environment. In essence, the development of business practices has become a bottom-up approach rather than the optimal top-down.  3.3.2  T h e 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 bottleneck that constricts the flow of cash.  Application of OOEM: An Industrial Case Study  51  C A S E 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 redesign. 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 determine 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  C A S E 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 process that is driven by rules that pose obstacles rather than facilitate efficient 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  C A S E ANALYSIS  A Redesigned View of the Service Repair Process  FIGURE 8  CUSTOMER  CHARGEHAND  CLERK  PARTSMEN  MECHANICS  service ; report  service requests  ACCOUNTS  OEM  PAYABLE parts! service repair  & quotes:  job story. process parts request  notification of job completion  verify job story  process job story  invoice / request for payment  -warranty claim -  invoicing invoice / request; for payment;  process invoice  activity  o  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  C A S E 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 circumvent 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  OOEM & IDEFO MODELING  CHAPTER 4  4.1  OOEM MODELING  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 contribute to further development of the OOEM methodology. Together with the concepts and principles of OOEM modeling surveyed 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 semantics used in representing OOEM models is pertinent. Although references are drawn heavily from this work, the notations are not necessarily adequate and are modified in the course of the case analysis. 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 notational 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-sufficient 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 C o m m u n i c a t i o n 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 elements 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 generated by each of the services. The semantics of these elements were detailed in Chapter 2. These elements together form the basic components of an object communication diagram. Figure 9 illustrates and explains the composition of an example 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 client 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  A n O O E M Object Communication Diagram  FIGURE 9  Legend External Object  External Object  (  )  Internal Object  - •  Request • System Scope  Request External Object  Internal Object) Request  External Request Internal Object  J^External Request  •{  Internal Object  V-Request  Request  External Request  I  I  External Object  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  Objects  Interface  Internal  Generated  Receiving  Attributes  Attributes  Requests  Objects Object 3  Incoming  Internal  Access  Request  interface  attributes  Mode  generated  -  attributes  to support  from Service 1  -  Returning  Service 1  Request  Object n  interface  Object 1  Service 1  Object 2  generated from Serv ice 1  attributes Incoming  Internal  Access  Request  -  interface  attributes  Mode  generated  Object n  attributes  to support  Object 1  Service 2  Object 4  Object 5  from Serv ice 2  Serv ice 2  TABLE 3  External Object Representation: External Object Template (EOT) Object  Name  Requests  Receiving  to  Object  System  I n te r n a I 0 b je c 11 I n t e r n a l 0 b je ct 2  R e q u e st 1 R e q u e st 2 Requesting  Interface  S e rv ic o s  to  Attributes  0 b je c ts  I n t e r n a l 0 b je ct 3  S e rv ice 1  Internal0bject4  S e r v ice 2  In te rfa ce a ttrib u te s o f S e rv ice 1 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 characteristics 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 information 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 represent 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 system, i.e., the external object is a client, or provide services to the system, 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 system, • 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 requesting internal objects in order to service the requests. Information regarding internal attributes of external objects is not captured 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 representation of an OOEM model of an organization. This is especially useful in large organizations where complex details can be encapsulated and systematically represented. Furthermore, subsequent levels of detail can be represented and described as sub-models. This multi-layered 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 models do not include any information, objects, or services that do not contribute 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 business of the company. The analysis and discussion are based on the progressive application of OOEM  in modeling D D A BC as an  organization and as a service process.  Application of OOEM: An Industrial Case Study  63  OOEM MODELING  O O E M Object Communication Diagram: Request Propagation Analysis of 'DDA BC  FIGURE 10  Legend External Object  (  )  Internal Object  - •  Request j System Scope  Financial Institutions  Financial / Banking Services  4  DD-ABC  -Order Product -  Payment  Info. Quote Product Service Customers  4.1.2  )-^-  -Invoice-  Suppliers  O O E M Model of D D A B C  A "high-level" perspective of DDA BC as an enterprise from its clients' 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 levels in the latter part of this chapter.  TABLE  4  Internal Object Template (IOT) of DDA BC Object DDA BC  Requesting  Services  Objects  Customer  Interface  Internal  Attributes  Attributes  Generated  Receiving  Requests  Objects  U/M  Order product  Suppliers  (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  - Warranty info  U  Order product  Suppliers  - Product info  U  Payment  Customer  - Account info  M  Financial/Banking  Financial  Services  Institutions  Service  - Serv ice request  product  - Serv ice history  - Work description - Billing info Customer  Purchase  - Product info  product - Billing info Customer  Prov ide  - Quote request  - Product info  U  - Info request  - Product info  U  price quote Customer  Prov ide product info  Complementing the OCD in Figure 10 is a set of object templates comprised 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 Customer R e q u e s t s to  Receiving  System  Object  - Product info  DDA BC  - Quote - Order product - Serv ice Requesting  Services  Interface to  Objects DDA BC  TABLE 6  Attributes Pay ment  Billing info  External Object Template (EOT) of Supplier Object Supplier R e q u e s t s to  Receiving  System  Object  Invoice Requesting  DDA BC Services  Interface to  Objects DDA BC  TABLE 7  Attributes Order product  Product info  External Object Template (EOT) of Financial Institution Object F i n a n c i a l Institution  Requesting  Services  Objects DDA BC  Requests to  Receiving  System  Object Interface to Attributes  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 concept of encapsulation. The immediate implication is that all the information 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 P r o c e s s  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 perspective of the company's customers, such as those who request services (sales and repair, for example). At this level, none of the more detailed components (e.g., internal objects) of the DDA BC organization 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 external to the system.  Application of OOEM: An Industrial Case Study  68  OOEM MODELING  O O E M Object Communication Diagram: Request Propagation Analysis of 'Service Repair Process'  FIGURE 11  Legend  Customer  Service Quote  Service Payment Accounts Receivable  Close service ,  I Update Charges  A c c o u n  I  -Payment  Service Chargehand  Close WO Open WO — -Service WO -  I  Service Admin.  T  Allocate  Update  Parts  Charges Verify Job Story  Service Floor  Reman ufactu ring ^ )  Remanufacture -  I  I Allocate  LA  Inventory Control  Parts  Oroer Product  Suppliers  Application of OOEM: An Industrial Case Study  69  OOEM MODELING  TABLE  8  Internal Object Template (IOT) of Service  Chargehand  Object  Service Chargehand Requesting Objects Customer  Services  Internal  Interface  Attributes  Service  Attributes - Product info  Quote  (engine serial #, model/year)  - Warranty info  Generated  Receiving  Requests  Objects  U  - Problem description (symptoms, location) - 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  Payment  Customer  - Work description - Billing info  TABLE  9  Requesting Objects Service  Internal Object Template (IOT) of Service  Services  Interface  Open WO  Attributes - Product info  Service Admin Internal Attributes - WO info  Admin  Object  Generated  Receiving  Requests  Objects  Update charges  AIR  Close service  A/R  M  (customer info, product (engine serial #, model/year)  Chargehand  - Problem description  info, problem description)  (symptoms, location) - Estimated work description (repair type, parts needed, labour hours) Remanu-  Update  - Account info  - Work info  facturing  charges  (account #)  (rebuilding work done,  - WO info  parts used, labour  M  committed) (job story, parts allocated, labour hours) Service Chargehand  Close WO  - WO info  - Work info  M  (yob story, parts allocated, (repair done, parts used, labour hours)  labour committed)  account  Application of OOEM: An Industrial Case Study  70  OOEM MODELING  T A B L E 10  Internal Object Template (IOT)  of Inventory Control Object  Inventory Control Requesting  Services  Objects - Service  Internal  Interface  Allocate  Chargehand Parts - Serv ice Floor  T A B L E 11  Generated  Attributes - Stock info  Attributes - Product info  M  (serial #, model/year,  (quantity on hand, transit,  quantity)  backordered, dirty, clean,  - Confirm allocation  to be remanufactured)  Internal Object Template (IOT)  Receiving  Requests  Objects  Order product  Suppliers  of Service Floor Object  Service Floor Requesting  Services  Objects Service  Interface  Internal  Attributes  Attributes  Service WO - WO info  Generated M  - Actual repair info  (repair type, duration, (problem description, prelim,  Chargehand  Receiving  Requests  Objects  Allocate parts  Inventory Control  Remanufacture  Reman. Dept  parts used) diagnosis, repair needed) - Job story - Labour hours  T A B L E 12  Internal Object Template (IOT)  of Accounts Receivable Object  Accounts Receivable (AIR) Requesting  Services  Objects  Interface  Internal  Generated  Receiving  Attributes  Attributes  Requests  Objects  Payment  Customer  Service  Update  - Account #  - Customer accounts  U  Admin  charges  - Charge info  - Account credit/debit info  M  Service  Close  - Account #  (parts info, costing info) Admin  Service  -Amount Payable  M  - Credit limit  M  Account  Application of OOEM: An Industrial Case Study  71  OOEM MODELING  T A B L E 13  Internal Object Template (IOT) of Remanufacturing Object Rem an u fact u ring  Requesting Objects Service  Interface  Internal  Generated  Attributes  Attributes  Requests  Objects  Update charges  Service Admin  Services Rebuild  Floor  - Part info  - Labour hours committed  M  - WO info  - Parts used  M  T A B L E 14  Receiving  External Object Template (EOT) of Customer Object Customer Requests to  Receiving  System  Object  - Service quote  Service Chargehand  -Service Requesting  Services  Interface to Attributes  Objects Service Chargehand  Payment  Billing info  Accounts Receivable  Payment  Billing info  T A B L E 15  >  External Object Template (EOT) of Supplier Object Supplier  Requesting  Services  Receiving  System  Object  Interface to Attributes  Objects Inventory Control  Requests to  - 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 primarily 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 models 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 Description  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, however, 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 T r e e for Service Repair  QA11  Determine Requirements  Parts  4.2.3 C o n t e x t D e s c r i p t i o n s  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  Call Mechanism  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 interfaces 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 consumed or transformed by the function to produce outputs, Outputs are in turn represented by arrows leaving the function 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 function.  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 supported. 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. Likewise, 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 M o d e l of the S e r v i c e Repair P r o c e s s  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 earlier. 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 Supply Parts  LL  Repaired Product  Repair Product  j£ Mechanics  A3  "I  Job Story Completed Close Work Order 4  "f Chargehand  Warranty Credits  Invoice Repair  Control  i Input  Billing Info  Clerk  Output  Function Name #  >j  Call  Mechanism  Account Info Make Accounting Entries  Receipt 6  Ir Accounting Dept  SERVICE  PRODUCT  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  Discounts, Landed Costs,  Pricing Info  4 Tax Requirements  Parts Dept -•j  Determine D educations  Clerk Negotiate Servicing Details 4  Modified Price  Input  Finalized Price Quote Work & Product Info  ^  Chargehand  Output  Function Name #  •  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 Costs of Allocated Parts  Repaired Product Job Story  Mechanics  Parts Request  Control  1  Input  Function Name  Output •  REPAIR PRODUCT  Application of OOEM: An Industrial Case Study  82  IDEFO MODELING  IDEFO Context Diagram for A32: Pick Inventory  FIGURE 18  Inventory Stock  ••j  Check Stock  Partsmen  Specification  1  —M  Order Parts  Costing Info —M  Assign Parts ->. A33  Partsmen  Control  1  Input  w  Function Name  T  Output •  Call  T i Mechanism  Y  PICK INVENTORY  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, provide 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 recognized 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 will 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.  5.1.1  1  Separability of P r o c e s s & 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 O C D s and the IDEFO Context Diagrams described in Chapter 4.  For instance, the service repair process represented by the O C D in Figure 11 is described by a set of objects and their requests irrespective of how the functions are defined within the existing business environment. 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 o f activities that are performed.  This IDEFO approach to modeling processes may be beneficial for certain 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  OOEM  method of modeling interactive agents allows the separability of "functional" 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 intuitive process-oriented perspective through a model as opposed to the IDEFO function-oriented approach.  5.1.2  Request S e m a n t i c s  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 contrast, in IDEFO, arrows could represent one of the following four constructs: input, output, control, and mechanics. Input and output could be in the form of physical objects such as raw material and work-inprocess or a piece o f paper travelling through different departments o f 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 semantics 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 generally 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 example. A portion of the Service Repair Process is extracted and reproduced 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  OpenWDacseWO-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 "verify 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 o f 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, the semantics o f the arrows dictate that until the appro1  priate service is initiated and completed by the service chargehand object, the service floor object will 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 o f 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 servicefloorobject.  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 Inventory 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 Efficiency 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 "hidden". 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 important distinction here is that redundant information may be represented in an IDEFO model. A n example is the "Determine Deductions" function in Figure 16. From an O O E M perspective, this function is unnecessary 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 methodology 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 o f detail will be very meaningful. Additionally, such detail could obscure useful information. Examples of such detail are explicitly demonstrated in Figure 17 and Figure 18.  In summary, the IDEFO technique serves as a comprehensive documenting methodology which does not seem to take into consideration how the information is to be used. Although the IDEFO technique provides a proven framework for IS analysis, the extension into the process 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 precedence of functions. The order o f 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 propagation 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 internal object receives more than one request and each of the requests in turn generates multiple services and requests. Although the precondition for spawning a request may be inferred from the OTs through the services generated, unless these services are listed in a preordered 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 originate 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 E O T , 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  Service Quote Service  t  Close WO  Payment  Service Chargehand Allocate  -Open WO  Service WO  Parts  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 formalizing the presentation of the sequence of services and generated requests in the IOTs and the sequence of requests to system and services 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 completed from the perspective of the client. Such a perspective-oriented approach lacks the semantics to convey the necessary conditional information.  FIGURE 21  Inventory Control and Its Associated Requests  Availability of Parts  Q uote  Inventory Control  Allocate Parts  Order Product Product Info  A n 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 processes 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 O C D s and the OTs could potentially 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 numbering 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  S u m m a r y of C o m p a r i s o n With IDEFO  Table 16 summarizes and discusses the general findings of the comparison 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  T A B L E 16  Comparative Characteristics of O O E M and IDEFO OOEM  IDEFO  Process-Orientation  Functional-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.  Individual functions describe the sequence of events or work-flow of a process. This concept of process does not include information on the active agents within the organizational context. Rather, the focus is on systems analysis and design type of information, i.e., data-centric information.  Through the objects and object templates, the abstracted process can be viewed as a world of interacting agents.  Process-based information is not explicitly abstracted.  No function-based information is shown.  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 unidirectional or bidirectional, depending on the need to return request-specific information.  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 relevant details.  Economizes  on the Level of Details  OOEM models are governed by the aggregation and decomposition rule that dictates the precise level of detail that should be modeled.  Confusing Arrow  Semantics  The arrows used in context diagrams can be one of four abstractions: input, output, control, 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 cannot be identified with a particular input.  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 relevance and application of results. For a complex system, the IDEFO model can be very large and incorporate unnecessary information.  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 C a s e Study  99  COMPARISON OF OOEM WITH IDEFO  TABLE  16  Comparative Characteristics of O O E M and IDEFO OOEM  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 services. The level of exposition of details is contingent upon the level of information deemed necessary for a model to be complete. The scope of the subsequent levels remains bound by the OOEM rules.  IDEFO  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  Sequencing of Events  The order in which objects receive requests or service requests is not explicitly described in either the OCDs or the OTs.  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 loopback is allowed to show repetition of events.  However, it should be relatively easy to formalize the semantics of presenting the services and requests in the intended order.  No Conditional Information  No Conditional Information  The semantic for conditional control is not defined in both the Communication Diagrams and the OTs. It is not possible to abstract and communicate if-then-else type of branching of service requests.  The semantics of arrows in Context Diagrams do not provide for conditional control of if-then-else type of condition checking.  It may be possible to integrate a conditional control scheme in the object templates.  Guesses have to be made as to the conditional controls on the Context Diagrams since IDEFO does not provide for complementary means, e.g., templates, of describing functions.  Poor Process-Object Referencing  Node Referencing Scheme  The referencing of objects and processes is through the assignment of unique names that does not indicate the relationship between processes and objects.  Different levels of process and functions are systematically referenced through a numbering scheme as well as through the use of a node index and a node tree.  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.  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 evaluating O O E M as an object-oriented process modeling technique. 2. Jacobson's approach has also been applied to the domain of enterprise 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 J a c o b s o n ' s Object-Oriented A p p r o a c h  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 Jacobson's approach to modeling is the notion o f 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 perceived by the users of the process, and is defined by Jacobson [15] as 1  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. A s 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 similar 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 supplier 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 o f 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 machinery as well. 3. Interface Object — This refers to objects whose tasks are to communicate 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 will 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 subsystem 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 Jacobson's object-oriented approach. It is only intended to provide a background for the ensuing discussion. A comprehensive description of Jacobson's approach can be found in [15].  5.2.2  Comparative A n a l y s i s with J a c o b s o n ' s A p p r o a c h  The above descriptions of Jacobson's object-oriented approach to modeling business processes provide a basis against which the modeling constructs of the O O E M may be evaluated. In performing the comparison and the following analysis, attempts are made to address certain aspects of the O O E M method.  5.2.2.1 Model C o n s t r u c t s  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 example demonstrates that Jacobson's approach does not provide an unambiguous 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 organizational entity that belongs to part o f 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 will 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 w i 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, w i 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 Jacobson'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 perceived 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 methodology. Under this rule, the need to maintain such a distinction as proposed 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 distinction 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-oriented 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 propagation 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 analogous 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 Jacobson's object-oriented approach. While Jacobson distinguishes among three classes of objects, he stops short o f 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.  A n example from the case study can be drawn from the service repair process. B y Jacobson's definition, the remanufacturing object in Figure 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]' A t 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] From these two definitions, it is difficult to draw such 2  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 information 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  SUMMARY  In effect, an O O E M model conveys a clearly defined scope of a problem 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 information 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 comparison 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 o f 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). A s 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 opportunity 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 communicate 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 methodology 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 identification of objects, the appropriate inclusion of services and attributes, the ownership of these attributes, and the appropriate inclusion of composites 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 analysis , 1  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 delineate 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 O C D ' s and O T ' s , is able to sufficiently abstract and communicate information about processes 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 essential 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 O O 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 improvements to the O O E M methodology. Three issues outlined in this thesis refer to the inadequacy of semantics in representing and communicating 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 modeling 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 evaluation of the O O E M methodology, the evaluation process is a preliminary 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 will 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 Strategies, 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 Automated Support in Business Process Re-Engineering," Journal of Management Information Systems, 10(3), Winter 1993-94, 117-138.  [9]  Gartner Group, "Client/Server Computing in the 1990s," Information Technology Management 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 Comprehensive Methodology," Information Systems Management, Summer 1993, 13-22.  [11]  Hammer M . , and Champy J., Reengineering the Corporation: A Manifesto for Business Revolution, HarperCollins Publishers, N Y , 1993.  [12]  Henderson-Sellers B., and Edwards J.M., "The Object-Oriented Systems Life Cycle," Communications 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 Reengineering 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 Process 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 Systems 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 Architectures: A n 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, 223239.  [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 Processing 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., " A n 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), 186195.  [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 (  / Inventory \ Control  Internal ) Object  - •  Request : System ;  Scope  Customer  Update Charges Payment -Update Charges -  bte)«Accounts Receivable  Close Service Account Service Admin.  Debit Warranty Credit  Supplier Payment  Accounts Payable  1  Update Labour Hours Cut Cheques Payroll  Application of OOEM: An Industrial Case Study  122  INTERNAL OBJECT TEMPLATES  A.2  INTERNAL OBJECT TEMPLATES  1. Internal Object Template (IOT)  Requesting  Services  Objects  Interface  of Accounts Receivable Object  Accounts Receivable Internal Attributes  Attributes  Serv ice  U pdate  - Account #  - Customer account #  U  Adm in  charges  - C h a r g e info  - A c c o u n t credit/debit info  M  Generated  Receiving  Requests  Objects  Payment  Customer  (parts info, costing info) Remanu-  Update  - Account #  - Customer account #  U  facturing  charges  - C h a r g e info  - A c c o u n t credit/debit info  M  (work done info, parts info, costing info) Serv ice  Close  Adm in  serv ice  - Account #  - Amountpayable  M  - Credit limit  M  account  2. Internal Object Template (IOT)  of Accounts Payable Object  Accounts Payable Requesting  Services  Objects  Payroll  Interface  Internal  Generated  Receiving  Attributes  Attributes  Requests  Objects  Cut  - Employee ID  - Employee pay info  cheques  - Pay info  (total pay: year-to-date,  U/M  (hours worked, pay type, current period, deductSupplier  overtime time info)  ions, benefits)  Debit  - Distributor account info  - Receivable info  warranty  (to-date credit/debit balances, (customer account #,  credit  credit limit)  M  G/L account)  • Warranty credit info (application #, credit awarded/ rejected)  Application of OOEM: An Industrial Case Study  123  EXTERNAL OBJECT TEMPLATES  3. Internal Object Template (IOT) oi Payroll Object Payroll Requesting  Services  Internal  Interface  Objects  Attributes  Attributes  Service  Update  - Employee ID  Admin  labour  - Hours committed  Generated  - Total hours worked  M  Receiving  Requests  Objects  Cut cheques  Accounts Payable  hours  A.3 EXTERNAL OBJECT TEMPLATES  1. External Object Template (EOT) of Customer Object Custom er  Requesting Objects Accounts Receivable  Requests to  Receiving  System  Object  Services  Interface to Attributes  Pay ment  Billing info  2. External Object Template (EOT) oi Supplier Object Supplier Requests to  Receiving  System  Object  - Debit warranty credit  Accounts Receivable  - Payment Requesting Objects  Services  Accounts Payable Interface to Attributes  Application of OOEM: A n Industrial Case Study  124  EXTERNAL OBJECT TEMPLATES  3. External Object Template ( E O T ) of Inventory Control Object Inventory C o n t r o l Requests to  Receiving  System  Object  - Update charges Requesting  Accounts Receivable  Services  Interface to  Objects  Attributes  4.  External Object Template ( E O T ) of Service Admin Object Service A d m i n Requests to  Receiving  System  Object  - Update charges  Accounts  - Close service account  Receivable  - Update labour hours Requesting Objects  Services  Pay roll Interface to Attributes  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