@prefix vivo: . @prefix edm: . @prefix ns0: . @prefix dcterms: . @prefix dc: . @prefix skos: . vivo:departmentOrSchool "Business, Sauder School of"@en, "Management Information Systems, Division of"@en ; edm:dataProvider "DSpace"@en ; ns0:degreeCampus "UBCV"@en ; dcterms:creator "Parkinson, Pierre"@en ; dcterms:issued "2009-11-17T00:00:00"@en, "2003"@en ; vivo:relatedDegree "Master of Science in Business - MScB"@en ; ns0:degreeGrantor "University of British Columbia"@en ; dcterms:description """Software vendors are required to constantly adjust their product strategies to maintain the competitiveness of their products as they evolve through the product lifecycle. Customer Relationship Management (CRM) software reached, what many considered, the mature stage of its lifecycle in the year 2000. To prevent sales from stagnating in a maturing market, some CRM vendors adopted a strategy of developing vertical CRM solutions to continue sales growth by exploiting well-defined niche markets. To develop a vertical CRM product it is necessary to create a single solution that can easily be customized to suit the needs of a set of companies in a defined industry. The objective of this paper is to investigate if an object-oriented business modeling technique is appropriate for defining vertical CRM solutions. To investigate the appropriateness of an object-oriented business modeling technique, object-oriented business models were created for two financial services organizations and then compared to an actual vertical CRM solution that was known to be successful. The results of the analysis demonstrate that object-oriented modeling techniques can be used successfully to both define the requirements for vertical CRM solutions, as well as to test if a vertical CRM solution meets those requirements. The implication of this research is that object-oriented business analysis shows promise in defining vertical CRM solutions and that this technique could be adopted by industry to accelerate the development cycles of vertical CRM solutions."""@en ; edm:aggregatedCHO "https://circle.library.ubc.ca/rest/handle/2429/15081?expand=metadata"@en ; dcterms:extent "4949663 bytes"@en ; dc:format "application/pdf"@en ; skos:note "E V A L U A T I N G V E R T I C A L S T R A T E G I E S IN C R M U S I N G A N O B J E C T - O R I E N T E D A P P R O A C H by PIERRE PARKINSON B.Comm. McGill University, 1993 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE in the j The Faculty of Graduate Studies! Sauder School of Business (Division of Management Information Systems) We accept this thesis as conforming to the required/standard THE UNIVERSITY OF BRITISH COLUMBIA December 2003 © Pierre Parkinson, 2003 Library Authorization In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Co lumb ia , I agree that the Library shal l make it freely avai lable for reference and study. I further agree that permission for extensive copying of this thesis for scholar ly purposes may be granted by the head of my department or by his or her representat ives. It is understood that copying or publication of this thesis for f inancial gain shal l not be al lowed without my written permiss ion. 1?E N a m e of Author (please print) Date (dd/mm/yyyy) Title of Thes is : t i / ^ u r t T , ^ / ^ {/eiiutA-u ^raAr£tui£S thi c&w, Degree: flftiKretZ of SU€NCB Y e a r : ZQQH Department of lS>AU£>eP- S * . o f ^SS^BSS T h e University of Brit ish C o l u m b i a Vancouver , B C C a n a d a Abstract Software vendors are required to constantly adjust their product strategies to maintain the compet i t iveness of their products as they evolve through the product l i fecycle. Cus tomer Relat ionship Management ( C R M ) software reached, what many cons idered, the mature stage of its l i fecycle in the year 2000. To prevent sa les from stagnating in a maturing market, s o m e C R M vendors adopted a strategy of developing vertical C R M solut ions to continue sa les growth by exploiting wel l-def ined niche markets. To develop a vertical C R M product it is necessary to create a single solut ion that can easi ly be cus tomized to suit the needs of a set of compan ies in a def ined industry. The objective of this paper is to investigate if an object-oriented bus iness model ing technique is appropriate for defining vertical C R M solut ions. To investigate the appropr iateness of an object-oriented bus iness model ing technique, object-oriented bus iness models were created for two f inancial serv ices organizat ions and then compared to an actual vertical C R M solution that was known to be success fu l . The results of the analys is demonstrate that object-oriented model ing techniques can be used successfu l ly to both define the requirements for vertical C R M solutions, as well as to test if a vertical C R M solut ion meets those requirements. The implication of this research is that object-oriented bus iness analys is shows promise in defining vertical C R M solutions and that this technique could be adopted by industry to accelerate the development cyc les of vertical C R M solutions. ii Tab le of Contents Abstract ii Tab le of Contents iii List of Tab les v List of Figures vi Chapter I Introduction 1 1.1 Defining a C R M Solut ion 4 1.2 Solut ion Definition Us ing Data Model ing 5 1.3 Solut ion Definition Us ing P r o c e s s Model ing 6 1.4 Solut ion Definition Us ing Ro le and interaction based model ing 7 1.5 Defining vertical C R M solut ions 8 Chapter II Se lect ing the Appropriate Model ing Approach for Vert ical C R M Solut ions 9 2.1 Requirements of a vertical C R M model 9 2.2 Data Model ing 10 2.3 P rocess Model ing 10 2.4 Role/ interaction based model ing 11 2.5 Select ing the Most Appropr iate Model ing Approach 12 2.6 Rela ted Work 14 Chapter III Model ing C R M Requirements for T w o Financial Se rv i ces Organizat ions 16 3.1 Resea rch Overv iew 16 3.2 Model ing the C R M Requi rements of a Rural Bank 23 3.3 Step 1: Rural Bank Bus iness Mode l Definition 25 3.4 S tep 2 : Aggregat ing the Rura l Bank ' s Serv ice T y p e s 2 7 3.5 Step 3: Objectifying the Rural Bank 's Serv ices 28 3.6 S tep 4: Ass ignment of requests from the Rural Bank ' s bus iness model to objects 31 3.7 Step 5: Identify Internal Object Interactions in the Rural Bank 's Bus iness Model 32 3.8 Step 6: Verify integrity of data objects of the Rural Bank ' s bus iness model 33 3.9 External Requests of the Rural Bank bus iness model 33 3.10 Model ing the C R M Requi rements of a Private Bank ing Institution 34 3.11 External Requests of the Private Bank bus iness model 35 3.12 Summary of Research in Chapter III 36 Chapte r IV Construct ing Data and Dynamic Objects from an Exist ing C R M S y s t e m 37 4.1 The Vert ical F inancia l Serv ices Templa te 37 4.2 E R D for Financia l Serv ices C R M Template 39 4.3 Step 1 - Identification of all major or strong entities from the database 40 4.4 Step 2 - Determine if a child table is a candidate for a data object 40 4.5 Step 3 - Ass ignment of Relat ionship Tab les to Data Objects 41 4.6 Step 4: Construct ing Dynamic Objects 43 4.7 Data and Dynamic Objects for the Financia l Se rv i ces Template 44 4.8 Relat ionships between Dynamic Objects and Appl icat ion Objects 46 4.9 Summary of research descr ibed in Chapter IV 46 Chapte r V Linking the Ideal Bus iness Mode ls to the Exist ing C R M Sys tem. . . 47 5.1 Identifying Stat ic and Delegate Objects for the Rural Bank 47 5.2 Linking Stat ic Objects from the Rural Bank to the Financia l Serv ices C R M Template 48 5.3 Linking Dynamic Objects from the Private Bank to the Financia l Serv ices C R M Template 49 5.4 Identifying Stat ic and Delegate Objects for the Private Bank 49 5.5 Linking Stat ic Objects from the Private Bank to the Financia l Serv ices C R M Template 50 5.6 Linking Dynamic Objects f rom the Private Bank to the Financial Serv ices C R M Template 51 Chapte r VI Conc lus ion 53 6.1 Creat ing the Ideal Bus iness Mode ls 53 6.2 Construct ing Data Objects from Exist ing IT 54 6.3 A reas for Future Resea rch 55 Re fe rences 57 Append ix A S ix -Step O O B M Process for Private Bank 59 Append ix B Resea rch Summary 1 68 Append ix C R e s e a r c h Summary 2 73 Append ix D Interviewing Analys ts for O O B M Resea rch 80 Append ix E Construct ing Dynamic Objects 82 iv List of Tab les Tab le 1. External Object Definition for Rural Bank C R M sys tem 26 Tab le 2. External requests to the Rural Bank C R M Sys tem 27 Tab le 3. Aggregat ion of serv ices for the Rural Bank C R M Sys tem 28 Tab le 4. Objects created to handle service types for the Rural Bank C R M Sys tem 29 Tab le 5. Ass ign ing requests to Objects from the Rural Bank C R M Sys tem 31 Tab le 6. Identifying internal interactions of the Rural Bank C R M Sys tem 32 Tab le 7. Chi ld Tab le Determination for Rural Bank 40 Tab le 8. Ass ignment of Relat ionship Tab les to Data Objects 42 V List of Figures Figure 1 Steps Followed in the Study 19 Figure 2 O O E M of the Rural Bank business model 33 Figure 3 O O E M of the Private Bank business model 35 Figure 4 ERD for Financial Services C R M Template 39 Figure 5a Data and Dynamic Objects for the Financial Services Template...44 Figure 5b Data and Dynamic Objects for the Financial Services Template...45 Figure 6 Relationships between Dynamic Objects and Application Objects 46 Figure 7 Linking Static Objects from the Rural Bank to the Financial Services C R M Template 48 Figure 8 Linking Dynamic Objects from the Private Bank to the Financial Services C R M Template 49 Figure 9 Linking Static Objects from the Private Bank to the Financial Services C R M Template 50 Figure 10 Linking Dynamic Objects from the Private Bank to the Financial Services C R M Template 51 vi Chapter I - Introduction \" C R M is dead\" T o m S iebe l dec lared. The future of C R M , according to S iebe l while speak ing at the annual Cus tomer Relat ionship Management Confe rence held September 2002 in New York, is going to be in vertical bus iness p rocesses and W e b serv ices. G iven that his multi-billion dollar company, S iebe l Sys tems , was currently the leader in the enterprise C R M software market, these statements certainly raised eyebrows. To understand the context in which S iebe l ' s statements were made it is necessary to take a look at why the C R M market emerged and how it evo lved. The story of C R M begins in the early 1990s when the E R P market was still enjoying rapid growth. E R P had been around in one form or another for 30 years helping organizat ions whose bus iness involved s o m e component of complex manufacturing, to squeeze out inefficiencies and increase col laboration in a reas such as materials requirements planning, f inance, engineer ing, project management and human resources. (1) E R P products, des igned to handle huge transact ion vo lumes and critical bus iness p rocesses , had rigid architectures that were coldly efficient for grinding away the back office p rocesses that made much of the product focused, manufactur ing based , economy hum. A s the global economy evolved in the 1980s, service based industries began to take on a more important role and a new schoo l of thought ga ined momentum placing the customer, rather than products and the supply cha in , at the center of bus iness strategies. (2) Back-of f ice eff iciencies were v iewed as a minimum requirement for doing bus iness but, market share, it was now bel ieved, would be won and lost by focusing on techniques and strategies for automating and standardiz ing the internal p rocesses assoc ia ted with captur ing, servic ing, and retaining customers. Th is new breed of \"customer focused\" organizat ion required a new breed of enterprise software - Cus tomer Relat ionship Management (CRM) software was born. 1 Early entrants into the C R M market focused on speci f ic a reas of C R M to gain market share. S iebe l sys tems for instance focused on sa les force automation functionality which al lows sa les people to keep track of their customers and Clarify focused on call center functionality which al lows large call centers to automate inbound and outbound call ing p rocesses . T h e s e pioneers of the C R M industry who had early s u c c e s s , were a lso the first compan ies to expand their product footprints to offer customers a complete C R M suite that had functionality in the three key a reas of C R M : sa les , marketing and support. The late 1990s saw rapid sa les growth for C R M vendors as compan ies spent freely on C R M initiatives. The C R M industry in turn, spent freely on marketing m e s s a g e s to conv ince more compan ies that they needed to spend a s izab le portion of their IT budgets on C R M or risk losing their customers to compan ies that did. At the s a m e time as the C R M hyperbole was reaching a c rescendo , the hype assoc ia ted with the Internet was also rising. Largely driven by investments in the te lecommunicat ions sector, the Internet's infrastructure matured to a point where corporat ions began to rely on the low cost network for serv ices such as e-mai l , and expected their C R M implementat ions to leverage it as wel l . Th is market demand for products that were des igned to use the Internet forced C R M vendors to invest R & D dol lars into updating their software architectures from client server architectures, des igned to leverage local a rea networks, to \"3 tier\" architectures that used Internet related technologies and standards such as X M L over H T T P as their core method of inter-application communicat ion. Against this backdrop of rapid adoption of C R M and fundamental changes in the architectures of C R M vendors, the sa les environment for C R M suddenly changed in 2001 from rapid growth to retrenchment. C R M vendors started missing sa les targets and the bus iness press stopped extolling the virtues of C R M and quickly 2 filled their pages with stories of failed C R M implementat ions and dire warnings that corporat ions now needed to carefully establ ish return on investment metrics and clearly link how any p lanned C R M implementat ions could pay for themselves. (3) New product and sa les strategies had to be implemented quickly if C R M vendors were going to regain s o m e of the momentum that they had so quickly lost. (4) Corporat ions were now much more rigorous in the purchasing cycle and were demanding more from C R M vendors to reduce their implementation risk. O n e strategy that has emerged as holding great promise to meet the cha l lenges of this new environment has been to offer product features that are tailored for speci f ic vertical market segments . S iebe l sys tems, the acknowledged C R M market leader, c la imed that in 2002, 8 0 % of their software l icense revenue w a s from sa les related to products serving specif ic vertical markets. (5) Gartner group has a lso recommended that in order to compete in a highly competit ive C R M software market, vendors should compl iment their existing product l ines with vertical solut ions that reduce the risk for buyers as well as reduce the time required for implementation. (6) In effect, by offering a vertical solut ion, the C R M vendor a s s u m e s a portion of the implementation risk by making an upfront investment in the features and p rocesses required for the given vertical industry. If the vertical solution resonates with the target industry, the C R M vendor is rewarded with increased market share in the identified vertical market. T o provide insight to C R M vendors on how to best define functionality required for a vertical solut ion, this paper will explore three techniques for model ing a vertical bus iness solut ion: data based model ing, p rocess based model ing and role based model ing. Model ing approaches, if they can be used successfu l ly , have the potential to allow C R M vendors to develop vertical solut ions more 3 accurately and quickly as they create a representation of the organizat ional domain for which the information sys tem is developed (17). The decis ion making process used by a software vendor that is pursuing vertical markets to determine which vertical market to target requires many inputs. Factors commonly cons idered when select ing which vertical markets to create solut ions for include, the existing markets and customers that the company serves, the nature of the software solution currently offered and the resources avai lable to develop the solution. Regard less of the method used to determine which vertical segment to target, once identified, the task of defining the speci f ic features and functions of the vertical solution begins. 1.1 Defining a C R M Solut ion The definition of a vertical C R M solution serves two primary purposes. Firstly, it serves a s a point of reference for the team tasked with developing the solut ion to ensure the right solution is built. Second ly , it must allow decis ion makers at compan ies that are consider ing implementing the solution to understand the functionality and benefits of the solution as well as how the solution could fit into their existing IT framework. It is of critical importance that the high-level vert ical solution definition is understandable by both the technical community and the bus iness communi ty to ensure that the correct sys tem is deve loped to so lve the organizat ion's bus iness pains. The following sect ion will review three common model ing techniques used by bus iness analysts for defining information sys tems: • data model ing • p rocess model ing • object model ing 4 T h e s e three model ing techniques were selected as they are commonly taught in bus iness analys is courses (7) and are commonly used in industry as tools to des ign C R M sys tems (8). A recommendat ion on which method s e e m s most appropriate for defining vertical C R M solution definitions will then be forwarded. 1.2 Solution Definition Using Data Modeling Data model ing is the process of defining all the entities and attributes that are required for a given information sys tem, as well as the relat ionships between those entit ies. A data model acts as the data foundation over which information sys tems can be built. A well thought out data model al lows powerful, f lexible and stable appl icat ions to be built. A poorly p lanned data model results in an appl icat ion that may meet initial requirements, but over time as feature and functional enhancements are added, will s e e m to always need to be \"shoe-horned\" to offer the desired functionality (9). Data model ing methods compr ise of model ing techniques and model ing p rocesses . The process is def ined in terms of guidel ines and rules on mapping knowledge about the modeled domain into the constructs of the model ing technique (17). The fol lowing example illustrates the types of dec is ions that are made by a data modeler. If a data model were created for a f inancial application and the majority of products and serv ices offered in the sys tem could be offered to both individuals and to organizat ions, it would be tempting to create a single entity that conta ined all the attributes required for both individuals and organizat ions and link all the products and serv ices that are offered by the f inancial institution to this one entity. A benefit of this approach would be that all relationships to both individuals and organizat ions would only need to be created once . A drawback of this approach would be that certain sea rches would now take longer. It is up to the data modeler to ba lance the benefits versus the drawbacks. If the f inancial 5 institution that will be using this sys tem has employees that only deal with individuals, and other employees who only deal with organizat ions, than the time spent sorting through all organizat ions and individuals for e a c h search may not be acceptable, however, if it is important to be able to view search results in which individuals and organizat ions are interchangeable it may be worthwhile to create a single entity for both individuals and organizat ions. Th is s imple example illustrates a data modeler 's potential impact on an end -users exper ience. Data model ing a lso can have a large impact on a sys tem's maintainability, per formance and the e a s e with which it can be integrated to other sys tems. 1.3 Solution Definition Using Process Modeling In defining a C R M system using a process model ing approach, the bus iness analyst descr ibes the sys tem as a network of interacting p rocesses , or a sequence of act ions performed by the sys tem, with the aim of f inding the set of p rocesses that can complete the tasks most efficiently. The definition of what is efficient will vary from sys tem to sys tem but will usually be measured by metrics such as how quickly the tasks can be completed, how many people will be needed to complete the task, and finally, what resources are required. Often p rocesses that have been shown to work in similar environments can be reused and are termed \"Industry Best Pract ices\" . Typical of c la ims surrounding C R M Best Pract ices is the following from the S iebe l Sys tems W e b site: http:/ /www.siebel.com/bestpract ices/fuj i tsu_siemens.shtm With Siebel Sales and Siebel Call Center, Fujitsu S iemens Compute rs has: R e d u c e d overall order process ing time by 65 percent 6 Increased lead convers ion rates by 45 percent Reduced reseller order process ing time from 2 days to approximately 30 minutes This promotional text announces that by using the S iebe l S a l e s product and the S iebe l Ca l l Center product Fujitsu has been able to implement the best pract ices conta ined in the order p rocess , lead convers ion process and order p rocess to process quicker, convert more, and sel l faster. W h e n defining the p rocesses required in a sys tem, the analyst populates a data dictionary which contains a descript ion of the data required to perform the process . A s the set of p rocesses grows the data dictionary a lso grows until all the p rocesses have been def ined and there is a complete listing of the data that is required. 1.4 Solution Definition Using Role and interaction based modeling Role and interaction based model ing doesn' t focus on the underlying data or process but rather groups functionality around objects that exist in the real world that can receive and answer m e s s a g e s . The complexity of the inner workings of the object remain hidden from an analyst allowing them to focus more on what a sys tem should do rather than how the system should do it. If we are to cons ider a s imple banking sys tem def ined using a role and interaction model , there might be three objects that represent the customer, the account management sys tem, and the customer serv ice function. The model could easi ly express that customer can write a cheque, a cheque can be deposi ted and an account can accept a deposit and return a confirmation by creating a s imple drawn representation of the three objects with lines between the objects to indicate the act ions of writing a cheque or making a deposit. Us ing this method the e s s e n c e of the roles involved as well as the interactions are captured without needing to focus on the underlying data. A n analyst model ing such a sys tem using a role and interaction model ing technique can model this s imple banking system without needing to define the 7 details assoc ia ted with the transaction such as what information is required on the cheque or what information is required to verify the money is deposi ted into the correct account. T h e s e details are vitally important to the correct functioning of the final sys tem, however, they do not need to be defined in this high level model . 1.5 Defining vertical C R M solut ions A s has been ment ioned in many popular press art icles, C R M offers great return when done properly but on the other hand, the implementation failure rate is very high (10). W e bel ieve, based on interviews with bus iness analysts who implement C R M sys tems, that the biggest reason that C R M implementat ions fail is that they are very complex sys tems that can compr ise of 10 or more sub-sys tems such as a cal l-center, analyt ics, serv ice and warranty, complex configuration, web personal izat ion, and sa les force automation and the current methods used to define the solut ions are too focused on how the sys tems work and not focused enough on what the sys tems can do. The result of using definition approaches focused on implementation is that bus iness people and technologists are not able to speak a common language to descr ibe the target functionality and as a result, in many c a s e s , the wrong C R M systems get built which fail to meet expectat ions. Our contention is that a promising model ing method for defining vertical C R M solutions is the role and interaction model ing approach due to its ability to \"hide\" complexity and focus on what a system will do rather than how it will do it. The following chapters will explore this hypothesis in more detail. Be low are the main topics covered in each chapter: Chapter 2 - Se lect ing the opt imum method of model ing C R M appl icat ions Chapter 3 - Creat ing Bus iness models for two banks Chapter 4 - Creat ing an object perspect ive of an existing IT system Chapter 5 - Linking the bank bus iness models to an existing IT system Chapter 6 - Conc lus ions 8 Chapter II - Selecting the Appropriate Modeling Approach for Vertical CRM Solutions Having explored the key ideas behind data, p rocess , and role/interaction based model ing techniques, this chapter will explore why we bel ieve that role/interaction based model ing techniques are the most appropriate for creating models for vertical C R M solut ions. 2.1 requirements of a vertical CRM model W h e n creating a model for a vertical C R M solut ion it is necessary to be able to capture the e s s e n c e of what bus inesses in the target industry do without getting distracted by the implementation details of how the bus inesses do it. Wha t bus inesses do is usual ly descr ibed in terms of the products or serv ices the bus iness offers and the customers they serve. How bus inesses accompl ish these functions, is usual ly descr ibed by sys tems and processes . If there is not enough common functionality in what bus inesses do across a vertical market then it is unlikely that the industry will be a good candidate for a vertical C R M solution. It is, therefore, imperative to understand early on in the analys is process if enough c o m m o n bus iness functionality exists to warrant an investment in a vertical solut ion. To discover what a bus iness does, it is best to interview the bus iness people within an organizat ion. Members of the sa les , marketing, product, and administration departments have visibility ac ross different functions and are able to articulate the key functions of a bus iness. Technologis ts , on the other hand, such as members of the IT staff, are best suited for descr ibing how the bus iness performs those functions, therefore, the key to being able to model C R M solutions is to use a model ing technique that can be understood by the bus iness community within an organizat ion. 9 2.2 Data Modeling Although absolutely necessary when designing the actual implementation of a C R M system, data modeling techniques are not suitable for defining a vertical C R M definition since they do not have the descriptive power to capture the high-level concepts and ideas that describe the essence of what a business does. Data Modeling is useful for defining the optimal database structure for a specific implementation but not for generalised model required for a vertical C R M solution. For instance, when considering the products that are sold by a bank, at one bank it may be possible to capture all the information regarding a product by having a main product table with a product feature child table. Using a data modeling approach would result in a product table and product feature child table being designed into the system. This may suit a particular implementation of a financial C R M system, but it would imply that all products that the bank sold could only be defined if they had a set of basic characteristics and then a set of specific features. The reality is that financial products are much more complex than this but the technology does not yet exist to economically capture all the rules and constraints that actually get applied by bank personnel before a product is sold. Combining process modeling with data modeling would not overcome these drawbacks as the processes would be tied to the data model which itself is too specific too be a useful model. As a result, in the example given above, if a configuration tool were introduced into the product model, the processes required to select a product would need to change as well as the data model. Data modeling by its very nature results in implementation specific models that due to their inherent specificity lack the flexibility to be useful as vertical C R M solution templates. 2.3 Process modeling The major drawback of process modeling for defining vertical C R M solutions is that it is difficult to map the resulting system back to the real world, which in turn makes it difficult to define the scope of processes. Also, the set of state changes 10 that may be appl ied to an entity and the relationships between entities are hidden within the p rocesses making it difficult to understand the impact of the sys tem on speci f ic entities and more importantly, to get an overall understanding of the sys tem. For example, if we were defining the customer l i fecycle p rocess , different portions of the p rocess would define how leads are captured, how prospects are created, how a contract should be completed and finally how to create a customer. O n c e again, similar to data model ing, a p rocess model is good at defining features of a speci f ic implementation but is too speci f ic to be useful for defining a vertical C R M solut ion. A lso , p rocess model ing is difficult to modular ise due to the relationships between entities being hidden within the p rocesses making it difficult for the s a m e system to be used in two implementat ions when only one aspect of the implementation may be different. Combin ing process model ing with data model ing would not yield the results needed for describing a general vertical C R M solution either, as the data model would be tied to the implementation of a specif ic process. For example , in the customer l ifecycle process descr ibed above any changes in the p rocess would result in changes to the underlying data model as well s ince the p rocess is not tied to real world entities it is difficult to create a general ised support ing data model without guidance of where the p rocess may be extended. G iven that the prime goal of model ing a vertical C R M solution is to gain an overal l understanding of the proposed sys tem, process model ing is not an appropriate approach . 2.4 Role/interaction based modeling The main feature of object based model ing techniques that can potentially offer many benefits for defining vertical C R M solut ions is encapsulat ion. Encapsula t ion is the ability to be able to show the key features of an entity without having to show background information or unnecessary detail. Object oriented approaches ach ieve encapsulat ion by treating an object as a \"black box\" that can only be communica ted with by sending it m e s s a g e s . By defining the types of requests 11 an object can accept and responses that it can generate, it is possib le to define what an object does without having to understand, how the object ach ieves its functionality. Another benefit of encapsulat ion is that it makes object oriented model ing techniques a useful tool for managing complexity. In C R M systems that are routinely compr ised of several interacting software sys tems such as call centers, analyt ics packages and configuration tools, techniques for managing complexity and maintaining an overall v iew of sys tem functionality are necessary to ensure that the sys tem is delivering value and meeting stated goals. Encapsulat ion a lso results in functionality being grouped around real-world entities, which makes the resulting model eas ier to understand for non-technical users. In C R M sys tems for instance, typical objects that emerge are the different types of individuals that will interact with a sys tem such as customers, managers , or partners of an organizat ion. Th is partitioning and grouping of functionality around real world constructs reflects how many organizat ions are arranged with the marketing and sa les responsible for many customer functions, and the partner organizat ion responsible for partners. 2.5 Selecting the Most Appropriate Modeling Approach The object-oriented approach for model ing vertical C R M solut ions that will be used in this research paper is the Object-Oriented Bus iness Model ing ( O O B M ) approach proposed in \"Developing Bus iness Mode ls to Support Information Sys tem Evolut ion\" by Yai r W a n d , C a r s o n W o o and S a m s o n Hui . The O O B M approach was selected because it is object-oriented, it has been used successfu l ly in the past (11), and it a ims to descr ibe an organizat ion by the products and serv ices that it del ivers which is precisely the approach that is required to define vertical C R M solut ions. For a summary of this paper see Append ix B. 12 The WWH O O B M approach, offers flexibility in the definition of the problem space since the system that is being modeled can be an entire organization or a subset of the organization. This is suitable for the task of defining vertical C R M solutions, which are generally focused on the activities, and interactions that are performed by customer and partner facing units of an organization and may have very little interaction with other corporate systems such as inventory control or finance. The O O B M approach defines objects in the system by roles not by specific processes or agents. This allows the resulting model to be more easily generalised into a vertical C R M solution and less specifically to the organizations that have been modeled. By defining the customer as a role and not as an agent, for example, it is possible to model the customer role without needing to define the specific interaction methods used by the customer. This is very useful in maintaining a high level perspective and not diving into implementation details since one organization may deal with customers directly over the phone, however another organization may offer the same functionality via web services. The O O B M proposes a six-step method for developing a business model that results in the definition of the unique roles with specific responsibilities within an organization and a mapping of their interactions with the organization and its environment. Wand, Woo and Hui also propose a method of linking the business model to an actual IT implementation of the modeled system thereby allowing a mapping to occur between the \"ideal\" modeled system and the actual software implementation designed to support the model(11). For a summary of the Wand, Woo and Hui method of linking an actual IT implementation to a business model see Appendix C. 13 2.6 Related Work There are three areas of research that are related to the research of this paper. This first area of related research is focused on product life cycles and the analysis of C R M sales strategies in the market place. Industry analysts such as the Gartner Group conduct much of the research in this area. As early as August 2000, Gartner was declaring with 0.8 probability that C R M vendors that did not differentiate themselves by developing solutions around industry segments or business issues would be unable to maintain market leadership status(12). More specific research looking at C R M in banks reveals that a trend is emerging in the purchasing patterns in banks that is placing on emphasis on enterprise wide C R M strategies that require a deep understanding of the entire business unit that will be served by the solution rather than focusing on narrow C R M initiatives focused on specific business lines or customer segments (13). The fact that this paper is investigating how to approach creating vertical C R M solutions is because product life cycle research indicates that vertical solutions are important to retain market share in the present state of the C R M market. The second area of research related to the research of this paper has to do with examining the optimal technical architectures that should be adopted for delivering C R M solutions. A growing body of research is recognizing that software vendors can no longer afford to view their technical architectures in isolation but must understand how their solutions can best be integrated into the larger enterprise wide IT strategy (14). As well, the increasing complexity of considering software solutions in a broader context requires business-modeling approaches that allow alternative business solutions to be considered without the costs associated with testing methods that require near full implementation of the target system (15). The final area of research relevant to this paper is research that has been done on specific approaches for creating business models that can be used to 14 evaluate the appropr iateness of new software sys tems being cons idered as addit ions to exist ing IT infrastructure (16). A long with research determining if new software sys tems deliver the required functionality, relevant research has a lso been conducted in the area of linking existing IT infrastructures to bus iness models to establ ish a reference point that reflects the core bus iness behaviour which is less fluid than the actual IT implementat ions supporting the bus iness behaviour making longer term IT planning possib le (11). R e s e a r c h in this paper differs from previous research in that the focus of this paper is from the perspect ive of the software vendor rather than from the perspect ive of an organization consider ing a new software solut ion. By turning the research perspect ive to the software vendor 's perspect ive, the cha l lenges that are faced are different from the cha l lenges a single customer would exper ience s ince a set of organizat ions need to be cons idered before an optimal solution can be def ined rather than a unique implementat ion. Another significant difference in the research conducted in this paper is that this paper a ims to bring the three a reas of relevant research together whereas previous research has had a more speci f ic focus on each given topic. 15 Chapter III - Modeling CRM Requirements for Two Financial Services Organizations 3.1 Research Overview The goal of the thesis is to determine if it is possib le and feasible to def ine the required functionality of a vertical C R M sys tem of a specif ic vertical industry segment based on the Object-Oriented Bus iness Model ing ( O O B M ) approach proposed in \"Developing Bus iness Mode ls to Support Information Sys tem Evolut ion\" by Yai r W a n d , C a r s o n W o o and S a m s o n Hui. The f inancial serv ices industry was se lected as the vertical industry segment for the study due to: • The industry has actual C R M sys tems in operation and it a lso provided a c c e s s to a known good model . • Its market s ize and potential sa les revenue have attracted many different C R M providers. • The organizat ions within the f inancial serv ices industry have been early adopters of C R M sys tems due to the acknowledged importance of establ ishing personal relationships with their customers. • Consol idat ion within the segment has resulted in increased compet i t iveness among the member firms to offer more individual ized products and serv ices which has increased demand for more sophist icated yet more manageab le C R M sys tems. • The fact that many early C R M sys tems within the f inancial serv ices sector were not entirely satisfactory indicating that a different approach to designing C R M functionality and implementation, such as those offered by O O B M , is warranted. Resea rch Des ign Internal vs . External Validity 16 For an experiment to be internally valid it should show a cause and effect relationship between the independent variables and the dependent variables. To ensure that this experiment was internally valid, a single person collected all the data using a consistent methodology and, following the O O B M of Wand, Woo and Hui developed both ideal business models. These steps ensured that the business models that were developed would be consistent and comparable. Internal validity, while important, is not the prime consideration in the research design of this study. Being more concerned with the external validity, or with whom and under what circumstances these results can be generalized, more attention was focused on ensuring the external validity of this study. Therefore the research design is focused on descriptive variables rather than observing the effects of independent and dependent variables in an experimental situation. This is in contrast to studies where internal validity is more important because the study is more concerned with whether the experimental treatment is responsible for any observed changes and seeks to make inferences about cause-effect or causal relationships. The ability to generalize the findings of this study to a \"known good\" vertical solution for the financial services industry is one of the primary considerations of this research project. The design of the experiment is to first determine what functionality exists in two existing C R M systems that are being used in two separate financial services institutions. Secondly, to an \"ideal business model\" to describe the functionality in the two institutions studied using the modeling technique called O O E M (Object Oriented Enterprise Modeling). The final step of the research is to compare the \"ideal business model\" to a known good C R M system. Threats to External Validity The major threats to the external validity of this study can be found in issues related to the population that is being generalized to, specifically, whether the 17 f indings will apply to other settings and whether the f indings will cont inue to apply over time. The study controls the threats to external validity by: • The sample drawn from the population was se lected to ensure that the main types of f inancial institutions and C R M sys tems were represented. That there was an establ ished history of C R M implementation and use, and that the individuals interviewed were acknowledged by peers as being familiar with the chal lenges assoc ia ted with C R M sys tems and had a thorough understanding of their respective institutions needs and use of C R M sys tems. • The applicability of these findings to other settings is val idated by compar ing the results to the known good model of C R M that has been accepted by the industry. Rather than theorize about the functionality of a success fu l C R M sys tem, the C R M sys tem deve loped is benchmarked against an accepted industry standard. • The applicability of these findings to apply over time is perhaps the weakest of the external validity issues. Whi le the actual research is being conducted at a time when issues related to C R M sys tems are the focus of great efforts by both providers and customers al ike, the rapid technological changes and competit ive pressure within the industry make predictions for future implementations difficult. The study has attempted to control for this through the utilization of the most recent theoretical developments in object oriented that are able to capture the e s s e n c e of a C R M system irrespective of the underlying technology as well as by compar ing the theoretical model to a known good C R M sys tem. Overv iew of Different P h a s e s of Research Study A schemat ic representation of the steps fol lowed in the study is found in F i g u r e l . 18 Identification of Population Criteria for selection developed: - Potential pool of interview targets identified - Conversant with overall business processes - Familiar with modeling techniques - Familiar with CRM systems - Interested in participating study Included by meeting criteria for selection I ~ Excluded due to not meeting criteria - Pre-interview material distributed. - Provided sample questions to interview Subjects. I - Performed interviews - Data collected - Follow-up interviews - Analysis of data - Data from analysts - Brainstorming with other industry experts and IT professionals I Generalizations to target models Conclusions Figure 1. Steps Followed In the Study Steps Followed in The Research Study 1. Identification of Population The financial services industry was selected due to factors identified earlier. The fact that it is an industry with actual C R M systems deployed and available for study was an important determinant in selection. In addition access to a known good business model for the industry was also crucial. Other industries could have worked as well but for factors outlined, the financial services industry was selected. 2. Criteria for selection 19 The data for this study was col lected from interviews with bus iness analysts who were working on actual C R M implementat ions in their respective institutions. The criteria for their select ion included: • Famil iar izat ion with their institution's organizat ional structure and C R M sys tems. • Emp loyed in the target institutions; • Interested in participating and avai lable for interviews required in the study Col lect ing information from C R M bus iness analysts posed two primary chal lenges. The first chal lenge is that bus iness analysts working on large projects are general ly under intense time constraints, which means that the t ime avai lable to an interviewer is limited. Second ly they are very familiar with building C R M appl icat ions with current technologies, however, many are not famil iar with object oriented concepts and ideas. 3. Pre-interview material distributed Prior to the interviews, a brief overview of the research was sent to the interview subjects. T h e purpose of this material was to introduce the subjects to the type and nature of i ssues the study was interested in address ing. To prepare the subjects for the language and nomenclature of the interview and to provide a template which would serve to structure the initial s tages of the interview and a checkl ist s o that pertinent issues were not omitted. The main point to get ac ross in the pre-interview material was to convey that the study was mostly interested in the different types of users that interacted with the sys tem and what type of interactions they had with the sys tem. 4. Per formed interviews The interviews were performed over the phone in 30-minute interview per iods. O n average each analyst was interviewed three t imes. In all c a s e s the analysts used what they ca l led security groups as the guide of the different types of users they had interacting with the sys tem. S ince security is an important part of any 20 CRM system each user class had specific requirements rights which made it quite easy to identify what groups were candidates for being external objects. For each security group, a list of the types of interactions they had with system was generated. These interactions became the requests. Understand The Analysts Work Methodology By far, the most important strategy that allowed good information to be collected was spending time understanding the approach that the business analysts currently used for defining a CRM solution. Understanding the processes and steps that the analysts used for the specific CRM package with which they were working with allowed the areas that were relevant to OOBM research to be identified and focused upon. The package that was used for the research presented in this paper had two primary phases of development. The first step entailed creating a data model, and the second step was to define business processes. Once these steps were completed, a user interface was generated to allow end users to interact with the system. With an understanding of how the business analysts worked it greatly speeded up the interview process. It was discovered, for instance, that when the GUI was generated, the analysts also created a list of menu items that listed all the different user groups which were candidates for business objects; therefore, the conversation was able to quickly focus on the list of business objects that appeared on the planned GUI. Use of Existing Project Documentation Extracting the requests was challenging at first since the business analysts did not think in term of requests, but rather, in terms of business processes. It was necessary, therefore, to identify and step through the primary processes of the system and interpret the flow of the process in terms of object requests and responses rather than individual processes. The processes were generally well documented and the business analysts were able to be very helpful in identifying 21 the requests and responses of the individual bus iness objects once they understood the O O E M terminology in context of the bus iness p rocesses they were famil iar with. 5. Ana lys is of data From the data col lected in the interviews a list of external bus iness object cand idates was created, and the types of requests these external object cand idates made into the sys tem was generated. The external object cand idates were then tested to s e e if they were indeed external to the sys tem or not using O O E M theory. 6. Genera l izat ions to target models 1. With the data, ideal bus iness models were created using O O E M . 2. The two bus iness models were compared and it was shown that they were very similar. 3. The ideal bus iness models were then linked to the known good system using the linking technique. 7. Conc lus ions Conc lus ions were then drawn based on how well the ideal bus iness models could be linked to the known good C R M sys tem. 22 3.2 Model ing the C R M Requirements of a Rural Bank The rural bank whose C R M needs were modeled for this research is a wholly owned subsidiary of a larger bank that operates autonomously from the parent company. The rural bank is a full service f inancial institution that offers a complete range of products targeted at bus inesses involved in all aspects of agriculture. The largest proportion of their customers are farmers, however, they a lso cater to bus inesses that raise cattle and individuals who work for bus inesses in the agriculture industry. The range of products offered fall into three main categor ies, loans, leases and insurance. If you need to buy hail insurance, lease farm equipment, or need a loan to f inance the purchase of cattle, you could turn to this bank. The rural bank dec ided to invest in C R M to provide a unified interface by which account managers could create and track opportunities ac ross the entire product line. At the time this research was done, in May and J u n e 2002 the bank was using three separate interfaces to a c c e s s the sys tems for loans, leases , and insurance. The rural bank w a s a lso looking for serv ice functionality to be able to track and respond to complaints. Finally, the rural bank needed a tool that would al low them to create customer and organizat ion profiles to al low better targeting of product offers. The two bus iness analysts, who worked with the rural bank to help define the C R M sys tem, as well as future users of the sys tem, were interviewed to collect information for this research paper. Refer to Append ix D for an overview of the method used to interview the bus iness analysts. The six-step methodology, descr ibed on the following pages , that was used to develop the bus iness model is the object-oriented bus iness model ing ( O O B M ) 23 approach descr ibed by Ya i r W a n d , C a r s o n W o o and S a m s o n Hui in \"Develop ing Bus iness Mode ls to Support Information Sys tem Evolut ion\". The six-step O O B M process used is a request driven approach that is based on the requests that are made from external objects into the sys tem in quest ion as well as the requests that are made within the sys tem as a result of external requests. Serv ices to satisfy the requests are def ined, grouped together and then ass igned to objects. Over laps are then el iminated and a final model is presented (16). 24 3.3 Step 1: Rural Bank Business Model Definition Part A: Rural Bank System Definition The system definition defines the boundaries of the system that will be modeled. The system in question provides a means for the organization to track and manage sales and support functions of the Rural Bank. Part B: Definition of Objects External to the system Objects external to the system are the objects that make requests into the system being modeled. Objects external to the system must behave independently and either have a direct impact on the model, provide a service required by the model or both. 25 Table 1. External Object Definition for Rural Bank CRM system This table lists all the external objects that will make requests into the rural bank's CRM system, and verifies if they meet the criteria for an external object. To qualify as an external object an object must behave independently of the system being modeled and have a direct impact and or provide a required service for the model. Ruqurud One of two is required Object Doscription Behaves Independently H.'JS a Direct Impact on Model Provides Required Service not in Model Customer Company or individual associated with the agriculture business Customer is independent from system being modeled as the CRM system is designed to serve them. Customer initiated transactions are what the system is designed to address. No Controller Monitors system performance and provides feedback Yes, controller is the external entity that defines how the system should perform. Yes, input from the controller determines the prioritization of transactions. Yes, performance monitoring is required to ensure that the system is achieving the goals defined for the system. Dealer Provides another sales channel for certain products Dealers are independent from system being modeled as the CRM system has functionality designed to serve them. Dealer initiated transactions are what a portion of the system is designed to address. No Supplier Provides market data for the system Suppliers provide information that generated independently of the system. Yes, Information provided by suppliers is used in calculations by the system Yes, market data provided by supplier is required 26 Part C: Define the requests made by the external objects into the Rural Bank 's C R M sys tem. This table lists all the external requests made into the C R M sys tem as defined by the bus iness analysts and users interviewed. Tab le 2. External requests to the Rural Bank C R M Sys tem Request # Exlurnal Object Request 1 Customer Account Transaction 2 Customer Apply for loan pre-approval 3 Customer Complaint \\ Feedback 4 Customer Best offer 5 Controller Performance Reports 6 Controller Create, delete, assign activities 7 Dealer Product Information 8 Dealer Apply for loan pre-approval 9 Supplier Market Feed 3.4 Step 2: Aggregating the Rural Bank's Service Types Aggregat ing serv ices into serv ice types. In step two the serv ices necessary to satisfy the external requests of the Rural Bank 's C R M Sys tem are def ined and aggregated. Serv ices are aggregated together if they have a similarity in state transformation, similarity in internal transformations, or a similarity in the resources they use. In Tab le 3, the serv ices required to satisfy the requests listed in Tab le 2 are listed. A s can be seen in table 3 the only aggregat ion of serv ices is ach ieved by the Cus tomer Management service that aggregates requests 2,4,5 and 8 from Tab le 2. 27 Table 3. Aggregat ion of serv ices for the Rural Bank C R M Sys tem One of threp is Service Type Similarity in state trans-formation Similarity in internal trans-formations Similarity in resources used for internal trans-formations Requests # from Table 2 that Require thp ''.crvicf1 Execute Account Transactions Performs actions on Account variables 1 Customer Management Performs actions based on the customer profile variables 2, 4, 5, 8, Activity Management Creates, deletes, and assigns activities. 6 Product Management Displays Product information 7 Service Management Manages Service workflow 3 3.5 Step 3: Objectifying the Rural Bank's Services In this step, we create objects that are responsible for delivering each type of serv ice. T h e s e objects do not represent the serv ices themselves, but rather represent a collection of serv ices that have a similarity in the transformations they perform, a similarity in the entities on which they perform transformations, or finally the resources they require to perform their transformations. 28 Table 4: Objects created to handle the serv ice types for the Rural Bank C R M sys tem. Object Serv ice Type Account Execute Loan, Lease , Insurance Transact ions Return Status Cus tomer Mgmt Cus tomer Ana lys is Activity Activity Management Serv ice Serv ice Management Product Product Management Object Descript ions: Account : The account object handles all requests that have an effect on accounts. This object is a lso the object that would be part of the \"back-end\" integration to the sys tems of record within the f inancial institutions. It becomes an object due to the entities, back end system integration modules, on which it performs transformations. Cus tomer Mgmt: Th is object stores all the profile information about customers, and is an object because it col lects all serv ices that a c c e s s the resources assoc ia ted with customers. Activity: The activity object handles all the requests related to activity management , such as creating meetings or recording call details. Activity becomes an object because the transformations that the serv ices perform to schedu le all types of activities are similar in nature. Serv ice : The service object handles all post-sale requests from customers, which are similar in the resources they require. Product: 29 The product object stores all product information and handles any information update requests related to products. Product b e c o m e s an object s ince all the serv ices that are related to product require a c c e s s to similar resources. 3.6 Step 4: Assignment of requests from the Rural Bank's business model to objects In this step, requests are ass igned to objects based on the state information they require or the state transformations the request c a u s e s . Tab le 5: Ass ign ing requests to Objects from the Rural Bank C R M Sys tem Request # from Table 2 External Object Request Roquest Iypo S.nto Infn Required Resulting SUto Transformation Objuut Irom Table 4 Responsible tor Statu Information Delivery or Transformation 1 Customer Account Transaction Account Related Modifies Deposit Accounts Account 2 Customer Apply for loan pre-approval Customer Analysis Checks Customer Profile Customer Mgmt 3 Customer Complaint \\ Feedback Service Modifies Service Request Service 4 Customer Best offer Product Related Returns Product Details Product 5 Controller Performance Reports Customer Analysis Customer Profile Customer Mgmt 6 Controller Assign activities Activity Management Modify Activities Activity 7 Dealer Product Information Product Related Returns Product Details Product 8 Dealer Apply for loan pre-approval Customer Analysis Customer Profile Customer Mgmt 9 Supplier Market Feed Market Data Return Market Info Account 31 3.7 Step 5: Identify Internal Object Interactions in the Rural Bank's Business Model In this step interactions that result between objects as a result of external requests are documented. Tab le 6 shows all external requests that precipitate an internal request. The \"Object Respons ib le \" co lumns shows the object that accepts the external request, and the co lumn titled \"Serv ice Hand led by Object\" shows the object that a lso participates as a result of an internal request. Internal interactions were identified by looking for objects that accepted an external request but were not able to satisfy the initial request without the participation of another object. Tab le 6: Identifying internal interactions of the Rural Bank C R M Sys tem Inter-action Request External Objoi.t Request Object Responsible Internal Interaction Service handled by object Service a 1 Customer Account Transaction Account Customer Data Customer Mgmt Customer Analysis b 2 Customer Apply for loan pre-approval Cust Mgmt Product Info Product Product Detail c 3 Customer Complaint \\ Feedback Service Modifies Service Request Service d 4 Customer Best offer Product Customer Data Customer Mgmt Customer Analysis e 6 Controller Assign activities Activity Management Modify Activities Activity 32 3.8 Step 6: Verify integrity of data objects of the Rural Bank's business model In this sect ion we verify if new objects need to be created or if existing objects need to be removed depending if there is overlap between the serv ices offered by two objects or if a new object needs to be created to perform the service for both of them. By referring to Tab le 5 we s e e that there are no over laps and , no new objects are required to perform the serv ice of two objects, therefore, no changes to the objects are required. 3.9 OOEM of the Rural Bank business model This drawing shows the interactions between the external objects of the Rural Bank 's bus iness model with the internal objects. Refer to Tab le 5 for descr ipt ions of each of the requests that are identified by the number that appears c lose to the line linking the external object and internal object. Th is model a lso shows the internal requests that occur as a result of an external request. Refer to Tab le 6 for descr ipt ions of the internal requests. 1 Account Transactions 2 -Apply for Loan customer d.Cust. data 4, Product Search e . Activity Info c. Service Info\\ 3. Register Complaint Account Account Requests [Transaction Info] Account Transactions Customer Mgmt Loan Requests [Customer Info] Customer Transactions Product Product Requests Product Trans actions Activity Activity Requests Activity Transactions 9 -Market Feed Supplier a. Customer Data 8. Loan Pre-Approval b. Prod. Info. Dealer 7. Product Search 5. Performance Reports 6. Create Activity Service •Service Requests Service Transactions Controller Figure 2 - O O E M of the Rural Bank business model 33 3.10 Modeling the CRM Requirements of a Private Banking Institution The second C R M sys tem that was modeled for this research descr ibes the needs of a private banking institution that caters to wealthy individuals who require sophist icated f inancial serv ices such as portfolio management , f inancial p lanning, wealth management and various insurance offerings. A key aspect of success fu l private banks is the ability of the personal bankers to provide a very high level of service for their cl ients making C R M technology very valuable to them. The main drivers for the private bank to adopt a C R M sys tem were to provide a unified interface for personal bankers to a c c e s s information from disparate back-end sys tems as well as activity management capabi l i t ies to al low personal bankers to monitor and track all their activities with cl ients. Other features that the private bank was looking for were opportunity tracking and customer rating based on profiles. The bus iness analyst who was working on the des ign for the private bank's C R M sys tem, as well as eventual users of the sys tem, were interviewed to col lect information for this research paper in May and J u n e of 2002. The six-step methodology, descr ibed on the following pages , that was used to deve lop the bus iness model is the W a n d , W o o , Hui enterprise object oriented model ing approach descr ibed in \"Developing Bus iness Mode ls to Support Information Sys tem Evolut ion\". Refer to Appendix A for details of the six-step O O B M process for the Private Bank. 34 3.11 External Requests of the Private Bank business model This drawing shows the interactions between the external objects of the Private Bank 's bus iness model with the internal objects. Refer to Tab le B in Append ix A for descr ipt ions of each of the requests that are identified by the number that appears c lose to the line linking the external object and internal object. Th is model a lso shows the internal requests that occur as a result of an external request. Refer to Tab le F in Appendix A for descript ions of the internal requests. 1 Jiccount Transactions 2 J!pply for Loan customer d.Cust. data 4&7. Product Search e. Activity Info c. Service Info 3. Register Complaint Account Account Requests [Transaction Info] Account Transactions Customer Mgmt Loan Requests [Customer Info] Customer Transactions Product Product Requests Product Transactions Activity Activity Requests Activity Transactions Service 9 Market Feed Supplier a. Customer Data b. Prod. Info. 5. Performance Reports 6. Create Activity Service Requests Service Transactions Controller Figure 3 - - OOEM of the Private Bank business model 35 3.12 Summary of Research in Chapter 3 In this chapter we deve loped bus iness models for a rural bank as well as a private bank based on the requests made into the system from external objects. V iewing Tab les 7 and 8 for the rural bank and Tab les B and F from Append ix A for the private bank al lows us to compare the bus iness models and recognize that the two mode ls are very similar. The only real difference between the two models is that that the Rural Bank has one extra external objects - the Dealer object. Th is extra external object is able to leverage the s a m e objects and serv ices that are required for the private banking bus iness model , however, which reinforces the fact that these models are very similar. The conc lus ion that can be drawn from this analys is is that the two banks have very simi lar requirements and that it is likely that a single vertical template could likely be deve loped that would be useful to both institutions. 36 Chapter IV - Constructing Data and Dynamic Objects from an Existing CRM System This chapter will descr ibe the p rocess of constructing data and dynamic objects, as def ined by W a n d , W o o and Hui in \"Linking Information S y s t e m s Architecture to the Bus iness Mode l \" (11), from an existing information sys tem. Data objects represent the data in tables assoc ia ted with major or strong entities. Dynamic objects represent the encapsulat ion of application objects and modules that a c c e s s these data tables directly. The existing information sys tem that will be used is a C R M template that was des igned by a C R M vendor to address the needs of Commerc ia l Lenders . 4.1 The Vertical Financial Services Template A team of 8 people including developers, bus iness analysts and industry experts deve loped the vertical f inancial serv ices template that was used in this study to explore the l inkage approach presented by W a n d , W o o and Hui in \"Linking Information Sys tems Architecture to the Bus iness Mode l \" (11). The template was des igned to meet the needs of commerc ia l lenders inside a full serv ice bank. The cha l lenges that the template was des igned to address were the fol lowing: Commerc ia l lenders have poor tools to support customer-centr ic sa les & serv ice strategies. Much of the commerc ia l lending sa les forces do not have the integrated technology needed to support strategic sel l ing activities. There are usual ly a variety of non-integrated sys tems in p lace to manage customer contacts, sa les reporting and campaign execut ion. This col lect ion of sys tems provides a fragmented approach to customer interaction s ince they are general ly compr ised of l inked spreadsheets or stand-alone appl icat ions access ing s tand-alone database—often with duplicate data. Before C R M sys tems are in p lace, for example , commerc ia l lenders are often having their assistants s c a n up to 8 37 different sys tems that each contain a separate piece of important information required for a sa les call such as contact information, product purchase history, and the ba lances of accounts that are each in their own sys tem. A n inability to retain corporate memory. T h e corporate lending s ide of many banks is the most profitable and highest dollar of any other divisions. Strange as it may s e e m it is a lso typically the least automated. Lenders in this a rea are typically higher paid special ly trained and exper ienced individuals. Without C R M automation when a corporate lender left the bank to go to a competitor so went any corporate knowledge of the Account . Somet imes this included many years of call ing on the account. A new lender would have to start from scratch with no contacts and no knowledge of the account . T h e following pages will descr ibe the steps taken as descr ibed in \"Linking Information Sys tems Architecture to the Bus iness Mode l \" by W a n d , W o o and Hui , to construct data objects from an existing IT sys tem. 38 4.2 ERD for Financial Services CRM Template The following E R D is taken from the data model of the f inancial serv ices C R M template. Al l connect ions in the model are \"one-to-many\" with the end of the line with the smal l circle representing the \"many\" end of the connect ion. Opportunity _ P r o d _F_D.es Opportuni ty Prod Fe_unes Id Opportunity Product, Product Feature Product Feature Id Product Id: Opportunity Product H < ODDortunitv Product Id* Opportuniry_Jd Product Product Id Opportunity Product Id Opporturiy Opportunity id Company_kJ Contact Id Corrtact Contact Id Comp -*uw«t«tk>tt ,R®mov® cl».Coturutction.St*tvi5 D.ynaProduct p oi'txxixit y e l s O p p _ J P r o c l c I s O p p F > ioc l_F\"ef i tx i i e c l s P i o c l x x c t c l s P x o d x i c t _ F e Eitxii-e e l s A c c oxxixt e l s A c c oxxixt F e: 11 i l l e s c l s A c c o i m t ^ _ H o l d i i i g s e l s A c t i v i t y e l s Sex-vice_JR.e<_xiest c l s W o r k O r d e r I Figure 6 - Relationships between Dynamic Objects and Application Objects This figure was generated by listing all Appl icat ion Objects and connect ing them to the Dynamic Object(s) with which it may interact. 4.9 Summary of research described in Chapter 4 In this chapter an existing C R M sys tem was ana lyzed and Dynamic Da ta objects were created and application functionality was ass igned to these data objects. Having now created the business models for the Rural Bank and the Private Bank and having created Dynamic Data Objects for it is possib le to link the models for the Rural and Private banks to the Dynamic Data Objects of the financial serv ices template this will be descr ibed in Chapter 5. 46 Chapter V - Linking the Ideal Business Models to the Existing CRM System In this sect ion we will verify if the ideal bus iness models deve loped for the Rural Bank and the Private Bank can be linked to the f inancial serv ices template. In effect we are trying to s e e if the f inancial serv ices template would be a good base C R M sys tem for the rural and private banks. To test if the ideal bus iness models can be linked to the f inancial serv ices template the concept of static and delegate objects for the bus iness models will be introduced. Stat ic objects are objects whose status we need to know, like a customer 's for instance, but that have no responsibil i ty in running the sys tem. Delegate objects, on the other hand, are responsib le for performing information processing activities such as the account object that records transact ions. If the static and delegate objects from the rural and private banks match up with the data and dynamic objects of the f inancial serv ices template then we can conc lude that the f inancial serv ices template would be a good fit as a C R M solution for the two banks. T o link an actual implementation to a bus iness model it is necessary to be able to identify in the bus iness model the activities that can be computer ised. W a n d , W o o and Hui propose to do this using the notion of delegate and static objects (13). Delegate objects represent objects that are responsible for performing information process ing activities, static objects, represent objects whose state we need to know, but do not have any responsibi l i t ies related to running the sys tem being mode led . 5.1 Identifying Static and Delegate Objects for the Rural Bank Stat ic Objects for the Rural Bank: (Objects whose state we need to know but do not have any responsibi l i t ies running the sys tem being modeled) 47 Supplier, Customer, Account Manager, Supervisor, HR Managers, Dealer. These six objects do not have any responsibilities running the CRM, system, however, their profile information must be stored to determine how they should be treated by the system. For the Rural Bank, the static objects Account Manager, Supervisor and HR Managers are part of the Controller external object. Delegate Objects for the Rural Bank: (Objects that are responsible for performing information processing activities) Account, Service, Customer Mgmt, Activity, Product These five objects contain information processing activities relevant to their area of responsibility. 5.2 Linking Static Objects from the Rural Bank to the Financial Services CRM Template Figure 8 shows that the data objects from the financial services template are able to accommodate the static objects from the Rural Bank business model. Data Tables Static Objects Figure 7 - L i n k i n g Static Objects f r om the R u r a l Bank to the F inanc ia l Services C R M Template 48 5 . 3 Linking Dynamic Objects from the Private Bank to the Financial Services CRM Template Figure 9 shows that the delegate objects from the Rural Bank Bus iness model can be linked in a logical manner to the dynamic objects of the f inancial serv ices template and have similar serv ice profiles. Application Objects Figure 8 - Linking Dynamic Objects from the Private Bank to the Financial Services CRM Template 5 . 4 Identifying Static and Delegate Objects for the Private Bank Stat ic Objects for the Rural Bank: Suppl ier , Customer , Persona l Banker , Supervisor, Delegate Objects for the Rural Bank: Account , Serv ice , Cus tomer Mgmt, Activity, Product 49 5.5 Linking Static Objects from the Private Bank to the Financial Services CRM Template Figure 10 shows that the data objects from the f inancial serv ices template are able to accommoda te the static objects from the Private Bank 's bus iness model . S t a t i c O b j e c t s D a t a O b j e c t s D a t a T a b l e s C o m p a n y C o n n e c t i o n Opportunity O p p _ P r o d O p p _ P i o d _ F e atuie Product Product Feature A c c o u n t Features A c c o i m t H o l d i i igs A c t i v i t y Servic e R e q u e st W o r k O r d e r Figure 9 - Linking Static Objects from the Private Bank to the Financial Services CRM Template 50 5.6 Linking Dynamic Objects from the Private Bank to the Financial Services CRM Template Figure 11 shows that the delegate objects from the Private Bank 's Bus iness model can be linked in a logical manner to the dynamic objects of the f inancial serv ices template. A p p l i c a t i o n Objects : ''X)elesiate.:Objects. Figure 10 - Linking Dynamic Objects from the Private Bank to the Financial Services CRM Template If we compare f igures 8 and 9 to figures 10 and 11 we s e e that the l inkage for the Rural Bank and Private Banks are very similar. The only significant difference appears in Figures 8 and 10 where the static objects are being linked to the data tables of the financial serv ices C R M template. Here we notice that the des ign of the C R M template easi ly accommodates both bus iness models by treating all of the static objects as either Contacts or Compan ies . If the design of the template did not have general ised objects that could handle any type of individual or 51 organizat ion, the ideal bus iness models from the rural and private banks would not be so easi ly l inked. In fact if spec ia l ised objects were created for e a c h type of individual or organizat ion, the f inancial serv ices template would need to be modif ied substantial ly for each implementation. The l inkage for the delegate objects of the rural and private banks is identical and is well suppor ted by the Dynamic Objects of the Financia l Serv ices C R M template with one to one mappings of all objects except for the customer management Delegate Object which needs to be able to a c c e s s all the Delegate Objects to satisfy its reporting requests. Finally, the completed models were presented to the bus iness analysts who were interviewed for this paper. Al though s o m e of the details of the approach used to develop the models were not fully expla ined to the analysts, the resulting model was quickly understood by the analysts and , the benefits of having such an object oriented model to guide C R M implementat ions in speci f ic vertical industries was recognized as valuable for decreas ing implementation t imes on future C R M implementat ions. 52 Chapter VI - Conclusion A s software products travel through their product l i fecycles software vendors must constantly adjust their strategies to keep in line with the current market cl imate. C R M software is entering a phase in its l ifecycle where market demand is driving C R M vendors to offer solut ions that are more closely a l igned with the speci f ic needs of organizat ions. Offering solut ions that are tailored to speci f ic market segments is one way of al igning software functionality more c losely with the needs of an organizat ion. In this paper we have demonstrated that using a role and interaction model ing approaches is a useful method of defining vertical C R M solut ions. T h e O O B M technique proposed by W a n d , W o o and Hui (16) was used to create ideal bus iness mode ls for two banks. The l inkage method proposed by W a n d , W o o and Hui (11) was then used to generate an object based view of the capabi l i t ies of an exist ing f inancial serv ices vertical C R M template. The bus iness models were then successfu l ly l inked to the existing vertical f inancial serv ices C R M solution and verif ied by bus iness analysts who design C R M sys tems. Th is demonstrates that requirements from a target market can be gathered and tested against a candidate system to verify if the candidate system is a good match for the functionality required. 6.1 Creating the Ideal Business Models The fact that the bus iness models created for the rural bank and private bank were very similar indicates that the f inancial serv ices industry is, from a technical standpoint at least, a good candidate for a vertical solution. If the research of the two f inancial institutions had resulted in greatly divergent bus iness mode ls then it is unlikely that a single vertical template could be developed that would be a good starting point for both organizat ions. 53 T h e other interesting aspect that was learned from using the O O B M technique for creat ing a bus iness model is that collecting the data required to form the bus iness model was not difficult. Bus iness analysts and bus iness users can easi ly def ine the specif ic roles that will be interacting with the sys tem as well as the requests that they feel the different users and sys tems will be making of the p lanned sys tem. In effect, by having them define the requests that the sys tem must support they are able to clearly articulate their ideas of what the sys tem needs to do without being burdened with technical details. Th is is particularly va luable because it ensures that the model that is created truly reflects the needs of an organizat ion s ince it is the actual users of the sys tem that have def ined it. 6.2 Construct ing Data Objects from Exist ing IT The approach descr ibed by W a n d , W o o and Hui to construct data objects from existing IT resulted in data objects that al igned well with the ideal bus iness models that were created for the rural bank and the private bank, indicating that the C R M template des igned by the C R M vendor is well sui ted for the task it was des igned for. O n e a rea where the research has shown that the C R M template might have a weakness , however, is in the a rea of reporting. O n e of the key benefits of a C R M sys tem is that data from front office functions is col lected making it possib le to measure and report on them. The current f inancial serv ices template requires the customer management delegate object to query each dynamic object of the f inancial serv ices template in order to satisfy the requests that it supports. A better approach may be to have the reporting functionality required by the customer management delegate object absorbed into the dynamic objects for the contact and company. Th is would add some complexi ty and dependenc ies within the f inancial serv ices C R M template; however, it would make the outward interface more modular with fewer in terdependencies. 54 6.3 Areas for Future Research The object-oriented approach of creating bus iness models as well as the object-oriented approach to construct ing data objects from exist ing IT sys tems is an effective method of determining market requirements for a vertical C R M solution as well as evaluating if a C R M template is appropriate to meet those needs for a speci f ic industry. Th is paper demonstrates a p rocess to operat ional ize the l inkage process proposed by W a n d , W o o and Hui. Future research areas could focus on advancing the technology used to support vertical C R M strategies. Cer ta in industries require speci f ic functionality outside of the standard sa les , market ing and service functionality general ly assoc ia ted with C R M . In the insurance industry, for instance, there is a requirement to be able to create quotes for customers based on historical risk data. S u c h an insurance quoting module would need to be able to extract profile information from the customer to create the quote and it may a lso need to interact with the product module to make a recommendat ion on the best product for the given c i rcumstances. Develop ing the quoting module for a vertical C R M solution for f inancial serv ices would be fairly straightforward. The complicat ion ar ises, however, if it is necessary to be able to use the s a m e quoting module in another vertical solution such as a solution targeting pharmaceut ical compan ies . Wha t is the best way to build the quoting module s o that pharmacists sel l ing drugs can a lso offer insurance quotes to cus tomers? To answer this quest ion will require a thorough understanding of the all the objects that the quoting module would interact with and being sure that the interfaces ac ross the vertical solut ions are c o m m o n . A variation on the s a m e problem area that requires more investigation is determining the optimal way to design vertical appl icat ions to al low objects within the template to be substituted based on the specif ic implementat ion. For instance if we consider a template to be des igned for the manufacturing industry for instance, the product object and the sa les object will require significantly 55 different functionality based on the product that is being so ld . For instance, a company that sel ls electrical fixtures will need a product object that can handle many parts with few features. A company that sel ls fire trucks on the other hand would need a product object that could handle few products that have a huge number of configuration options. W h e n we look at the sa les object for these two compan ies they would differ greatly as well. The electrical fixtures company would need cataloguing functionality in the quoting module of the sa les object while the fire truck manufacturer would have to be able to offer complex product configuration functionality in their quotes. 5 6 References ;1) E R P History, Tuncay Ka raca , Apri l 19, 2002 http:/ /www.saptech.8m.com/erp history.htm [2) Gartner Cus tomer P rocess Reengineer ing - talk to your customers, E. Thompson 13, December 2002. [3) Z D N E T : S ix mistakes that will sink your C R M , By Adr ian Mel lo, March 18, 2002 4 ) Gartner: Segment ing C R M Serv ices : Wha t Is Your Target Market? , By Debash ish S i n h a , August 7, 2000 [5) Forrester: S iebe l ' s Vert ical ization Overhau ls C R M Market Ru les , B o b Cha tham, Laur ie M. Orlov, March 13, 2002. [6) Gartner: Segment ing C R M Serv ices : Wha t Is Your Target Market? , By Debash ish S i n h a , August 7, 2000 7 ) \"Sys tems Ana lys is and Design\" , Gary B. Shel ly , T h o m a s J . C a s h m a n , Harry J . Rosenblat t , January 2000 B) IDS S c h e e r A G , Enterprise Serv ice Integrators, http://www.ids-scheer .com/s ixcms/deta i l .php/2014 [9) \"Rap id Appl icat ion Development\", J a m e s Martin, Macmi l lan Publ ish ing C o . , Inc, 1991 ;10) \" Z D N E T : S ix mistakes that will sink your C R M \" , Adr ian Mel lo , March 18, 2002 11) Work ing paper 99-MIS-005, Faculty of C o m m e r c e and Bus iness Administrat ion, University of British Co lumb ia , 1999. 12) Gartner: Segment ing C R M Serv ices : What Is Your Target Marke t? , By Debash ish S inha , August 7, 2000 13) Gartner: C R M in Banks — From S i los to an Enterprise App roach , by S . Landry, February 2001 14) Gartner: C R M Appl icat ions - A n Architectural V iew of Key Vendors , By Jeff Compor t , March 2003 15) Gartner: A Five Yea r Vis ion for C R M Architectures and Techno log ies , By Jeff Comport , March 2003 57 (16) Proceedings of the Ninth Workshop on Information Technologies and Systems (WITS'99, December 11-12, 1999, Charlotte, North Carol ina) , pp. 137-142. (17) \"Ontology-Based Rules for Object-Oriented Enterprise Modeling\", Yair Wand, Carson Woo, June 1999 58 Appendix A - Six-Step OOBM Process for Private Bank Step 1: Private Bank Business Model Definition Part A: Private Bank Sys tem Definition The sys tem definition def ines the boundar ies of the system that will be modeled. The sys tem in quest ion provides a means for the organizat ion to track and manage sa les and support functions of the Private Bank. Part B: Definition of Objects External to the system Objects external to the sys tem are the objects that make requests into the sys tem being modeled. Objects external to the system must behave independently and either have a direct impact on the model , provide a serv ice required by the model or both. 59 Tab le A . External Object Definition for Private Bank C R M sys tem Th is table lists all the external objects that will make requests into the rural bank 's C R M sys tem, and verif ies if they meet the criteria for an external object. 1 Requi red O n e of two is required Object Descript ion B e h a v e s Independently Has a Direct Impact on Mode l Prov ides Requi red Serv ice not in Mode l Customer Company or individual associated with the private bank Customer is independent from system being modeled as the C R M system is designed to serve them. Customer initiated transactions are what the system is designed to address. No Controller Monitors system performance and provides feedback Yes , controller is the external entity that defines how the system should perform. Yes, input from the controller determines the prioritization of transactions. Yes , performance monitoring is required to ensure that the system is achieving the goals defined for the system. Supplier Provides market data for the system Suppliers provide information that generated independently of the system. Yes, Information provided by suppliers is used in calculations by the system Yes , market data provided by supplier is required 6 0 Part C: Define the requests made by the external objects into the Private Bank ' s C R M system. This table lists all the external requests made into the C R M sys tem as defined by the bus iness analysts and users interviewed. Tab le B. External requests to the Private Bank C R M Sys tem Request # External Object Request 1 Customer Account Transaction 2 Customer Apply for loan pre-approval 3 Customer Complaint \\ Feedback 4 Customer Best offer 5 Controller Performance Reports 6 Controller Create, delete, assign activities 7 Customer Product Information 8 Supplier Market Feed 61 Step 2 : Aggregating the Private Bank's Service Types Aggregat ing serv ices into serv ice types. In step two the serv ices necessary to satisfy the external requests of the Private Bank 's C R M Sys tem are def ined and aggregated. Serv ices are aggregated together if they have a similarity in state transformation, similarity in internal transformations, or a similarity in the resources they use. A s can be seen in table C the only aggregation of serv ices is ach ieved by the Cus tomer Management serv ice that aggregates requests 2,4,5 and 8 from Table 2. Tab le C . Aggregat ion of serv ices for the Private Bank C R M Sys tem One of three is Required Service Type Similarity in state trans-formation Similarity in internal trans-formations Similarity in resources used for internal trans-formations Requests # from Table 2 that Rcquir\" tho service Execute Account Transactions Performs actions on Account variables 1 Customer Management Performs actions based on the customer profile variables 2, 4, 5, Activity Management Creates, deletes, and assigns activities. 6 Product Management Displays Product information 7 Service Management Manages Service workflow 3 Step 3: Objectifying the Private Bank's Service 62 In this step, we create objects that are responsible for delivering e a c h type of serv ice. Tab le D: Objects created to handle the serv ice types for the Private Bank C R M sys tem. Object Serv ice Typo Account Execute Loan , L e a s e , Insurance Transact ions Return Status Cus tomer Mgmt Cus tomer Ana lys is Activity Activity Management Serv ice Serv ice Management Product Product Management Object Descr ipt ions: Account : The account object handles all requests that have an effect on accounts . Th is object is a lso the object that would be part of the \"back-end\" integration to the sys tems of record within the f inancial institutions. It becomes an object due to the entities, back end system integration modules, on which it performs transformations. Cus tomer Mgmt: This object stores all the profile information about customers, and is an object because it col lects all serv ices that a c c e s s the resources assoc ia ted with customers. Activity: The activity object handles all the requests related to activity management , such as creating meet ings or recording call detai ls. Activity becomes an object because the transformations that the serv ices perform to schedule all types of activities are similar in nature. Serv ice : 63 The serv ice object handles all post-sale requests from customers, which are similar in the resources they require. Product: The product object stores all product information and handles any information update requests related to products. Product becomes an object s ince all the serv ices that are related to product require a c c e s s to similar resources. Step 4: Assignment of requests from the Private Bank's business model to objects In this step, requests are ass igned to objects based on the state information or state transformations the request c a u s e s . Tab le E: Ass ign ing requests to Objects from the Private Bank C R M Sys tem Request # from Table 2 External Object Request Request Type State Info Required Resulting State Transformation Object from Tablu 4 Responsible for State Information Delivery or Transformation 1 Customer Account Transaction Account Related Modifies Deposit Accounts Account 2 Customer Apply for loan pre-approval Customer Analysis Checks Customer Profile Customer Mgmt 3 Customer Complaint \\ Feedback Service Modifies Service Request Service 4 Customer Best offer Product Related Returns Product Details Product 5 Controller Performance Reports Customer Analysis Customer Profile Customer Mgmt 6 Controller Assign activities Activity Management Modify Activities Activity 7 Customer Product Information Product Related Returns Product Details Product 8 Supplier Market Feed Market Data Return Market Info Account 65 Step 5: Identify Internal Object Interactions in the Private Bank's Business Model In this step interactions that result between objects as a result of external requests are documented. Tab le 6 shows all external requests that precipitate an internal request. The \"Object Respons ib le\" co lumns shows the object that accepts the external request, and the column titled \"Serv ice Handled by Object\" shows the object that a lso participates as a result of an internal request. Internal interactions were identified by looking for objects that accepted an external request but were not able to satisfy the initial request without the participation of another object 66 Tab le F: Identifying internal interactions of the Private Bank C R M Sys tem Inter-action Bllllli Request Fxlernal a Object Request Objei t Rosponsible Internal Interaction Service handled by object Service a 1 Customer Account Transaction Account Customer Data Customer Mgmt Customer Analysis b 2 Customer Apply for loan pre-approval Cust Mgmt Product Info Product Product Detail c 3 Customer Complaint \\ Feedback Service Modifies Service Request Service d 4 Customer Best offer Product Customer Data Customer Mgmt Customer Analysis e 6 Controller Assign activities Activity Management Modify Activities Activity Private Bank Business Model Definition Step 6: In this sect ion we verify if new objects need to be created or if existing objects need to be removed depending if there is over lap between the serv ices offered by two objects or if a new object needs to be created to perform the serv ice for both of them. By referring to Tab le 11 we s e e that there are no over laps, so no changes to the objects are required. 67 2. The Challenges of Developing a Business Model The cha l lenges in developing a bus iness model include the inappropr iateness of \" reverse engineer ing\" to determine the bus iness p rocesses governing the bus iness ; lack of c lear guidel ines in determining what is difference between the core bus iness and bus iness implementat ion and finally, how to d e c o m p o s e the bus iness model into meaningful components . 3. The Business Model The proposed bus iness model is deve loped using an object-oriented approach because objects support a view of organizat ions in terms of interacting independent agents and units. In such a model , the objects are either a role of the bus iness units or external entities that interact with the bus iness . Reques ts are def ined as the interactions between objects that can flow in either direction and p o s s e s s both state var iables and serv ices responsibil i t ies and capabi l i t ies. The objects are the roles played by agents both internally and externally. A given agent can play different roles and severa l agents can play the s a m e role. Ro les are less dependent on organizat ion structure and implementat ion of bus iness p rocesses . 4. A Methodology to Develop a Business Model The proposed methodology is request driven based on requests made to the bus iness . Th is approach - known as encapsulat ion - means that bus iness implementat ion p rocesses are not important in defining the roles of IS components with respect to the bus iness model . The methodology for developing a bus iness model is: 69 Step 1: Identify Objects and Requests External to an Organization and Assign Services to Requests. This step def ines the boundary and identifies the purpose of the bus iness model . External objects behave independently of the core bus iness and either have a direct impact or provide serv ices needed in the core bus iness . The purpose of identifying external objects this way is to ensure that they are not tied to bus iness implementat ion and that their interaction with the model is def ined. After the boundary of the modeled system is def ined in terms of the external objects with which the sys tem interacts, then the requests sent or received by the external objects can be identified. Step 2: Aggregate Services. The objective of this step is to group similar responsibi l i t ies together based on identified requests. Serv ices are aggregated on the bas is of serv ice type. The serv ice types are similarity in internal transformations types (include similarity of state information), similarity in internal transformations and similarity in the resources used for internal transformations. Step3: Objectify each Service. O n c e aggregated, each serv ice type is replaced by an object and named in acco rdance with the role it plays. Th is ensures each object in the decomposed model has a c lear responsibil ity and c lear responsibil i ty signif ies encapsulat ion. Encapsulat ion in the context of the bus iness model means that the bus iness s tays the same , independent of how it is \" implemented\" (in terms of bus iness structure and processes) and thus resistance to bus iness changes . The result of S tep 3 is a set of objects, each handling one type of request using one service. Step 4: Decompose Requests in the Previous Levels of Model. Utilizing the generated objects, this step decomposes the request of each object employing the criteria outlined in S tep 2. (i.e., looking for similar state information or state transformation). 70 Step 5: Identify Interactions among Objects. After identifying the decomposed objects with their corresponding external events and serv ices, if an object needs a service of another object in the course of performing its own serv ice, the former object must send a request to the latter. Th is results in a new serv ice provided by the latter. Step 6: Create/Remove Objects for Sharing Services/State Information. If a serv ice (or part of a service) of one object is similar to that of another object, then either an existing object will perform the serv ice or a new object to provide the serv ice must be created. The serv ices provided by e a c h object must be clearly identified and descr ibed. 5. Conclusion, Experience of Using a Business Model, and Future Work The article d i scusses the need for a bus iness model to support redesign and reuse of IS and outl ines the chal lenges in constructing such a model . The resulting model uses external objects and their requests involving roles rather than agents. Decompos ing these roles using aggregat ion of requests and serv ices - based in similarit ies in state information and state transformations -ensures independence. T h e major portion of the bus iness model was deve loped for the customer serv ice of a cellular phone company and proved robust enough to accurately depict their core bus iness p rocesses even while undergoing rapid change. It was a lso found to be appl icable to a landline phone company as wel l . Whi le encouraged by practical results, the need for more empir ical research is clearly required. The authors bel ieve that by linking the architecture of the IS to the bus iness model , they can attach to each IS component to its bus iness mean ing. They are currently developing a methodology to derive \" ideal\" IS 71 architecture and explore ways to link IS components and database contents to the bus iness model . The resultant model could a lso aid in identifying reusable IS components and assist with migrations to new platforms. Relevance This paper is relevant to this research paper as it p roposes a method of distill ing the true nature of a bus iness irrespective of the underlying IT infrastructure. W h e n creating a Vert ical C R M solution the s a m e chal lenge is faced. A success fu l Vert ical C R M solution should be relevant to many compan ies in a speci f ic vertical market irrespective of the technology that already exists within the organizat ion 72 reused while restructuring or reengineering. A method for construct ing an organizat ion's bus iness model - based on an Object-Oriented Enterpr ise Model ing ( O O E M ) - is presented which enab les the development of an \" ideal\" IS architecture and/or reverse engineer existing IS architectures. The author's use a te lecommunicat ions company to illustrate their methodology and descr ibe how it can be implemented. 2 A Representational Framework of an Organization The authors present the representational framework of an organizat ion that is necessary for understanding the relationship of bus iness model and IS. The framework cons is ts of four layers: bus iness model , bus iness architecture, IS architecture, and IS implementation. The first two layers focus on the bus iness domain of an organizat ion while the bottom two on the IS domain . 2.1 Business Model The bas is of a bus iness model is that the company exists to deliver products and serv ices to its customers. It does not show how an organizat ion is structured or operates - the business architecture -to accompl ish its goal of customer sat isfact ion. T h e s e processes are cons idered an implementation of the bus iness architecture. The proposed model utilizes an object-oriented approach because objects descr ibe an organizat ion in terms of interacting independent agents and units. The authors then outline a bus iness model consist ing of a set of objects each reflecting either a role of a bus iness unit (or agent) or a role of an external entity that is interacting with the bus iness. Interactions are modeled in terms of requests sent between objects. A n object type has state variables reflecting its physical state and knowledge, and services representing its responsibi l i t ies and capabi l i t ies. 74 2.2 Business Architecture T h e bus iness architecture is an implementation of the model and descr ibes the actual organizat ional units and their relationships. G i ven the complexi ty of roles and responsibi l i t ies, the relat ionships between objects are many-to-many. 2.3 IS Architecture T h e IS architecture speci f ies the logical composit ion of components that support the bus iness model and does not address the actual IS implementat ion. 2.4 IS Implementation This layer is the actual implementation of the IS architecture including da tabase des ign and implementation, process ing components (which may or may not use an object architecture), and GUI design and implementat ion. 3 The Challenges A s d i scussed , in traditional bus iness models the IS architecture is constra ined by the bus iness architecture and more concerned with bus iness operat ions such as how the bus iness is implemented. T h e process of mapping the \" ideal\" IS architecture to the resultant model is imperfect due to: • The meaning of objects is obscured due to phi losophical di f ferences in the meaning of objects used in a bus iness model and objects as used in an implementation model ; • Exist ing IS architecture reflects how the bus iness is implemented rather than what the bus iness is. The result is conflicts between bus iness operat ions and the bus iness model in the roles and responsibi l i t ies of a given IS component ; 75 • Often the IS architecture reflects a data-centric v iew andt not an object v iew and therefore does not indicate the dynamics of the bus iness. 4 A Linkage Method The author descr ibe the development of the bus iness model ; derive an \" ideal: IS architecture; reverse translate existing data tables and appl icat ions into an object oriented des ign; and outline how to link the current IS architecture to the derived bus iness model . 4.1 Developing a Business Model The authors descr ibe the methodology and ideas for construct ing a bus iness model . The methodology is request driven and uses roles based on requests, which ensures encapsulat ion. The bus iness model methodology is descr ibed in five s teps. The first step is to identify external objects that send requests to the organizat ion. External objects are those that interact with, but are independent of and play not roles in carrying out, the bus iness. For each external request, a serv ice in the organizat ion is ass igned to process. In step 2, similar serv ices are aggregated together to el iminate duplication of responsibi l i t ies. In step 3, each serv ice is replaced by an object which represents a role in the organizat ion. To further decompose the object, the request decomposed in step 4. Next, in step 5, object interactions are identified. A n interaction occurs when an object needs a serv ice of another object in the course of performing its own service. In this c a s e , the former object must send a request to the latter. Finally, in step 6, similar serv ices in different objects are resolved by eliminating duplication 4.2 Deriving an Ideal IS Architecture from the Business Model 76 T o differentiate between human and computing activit ies, delegate and static objects are employed. Delegate objects are responsible for performing information process ing activities. G iven that an object has state var iables, if they are structured enough to be computer ized, then they can be \"delegated\" to an IS component . Th is \"delegat ion\" provides a mechan ism for determining automated IS components and provides the l inkage to technology. The model uses static objects to represent things needed to be known but perform no serv ices in running the bus inesses . Stat ic objects do not have serv ices and their states are maintained by objects that have serv ices. Differentiating between delegate and static objects is difficult and the authors propose a method of \"objectifying\" the company 's IS relationship da tabases to arrive at an appropriate representation of the bus iness model . 4.3 Construct ing Data Objects from Exist ing IS Examin ing the des ign of the da tabases in the existing IS begins the construct ion of data objects. There are three steps involved in this p rocess . Step 1 - Identify all major/strong entities from a database All strong entities become the candidates for data objects. Step 2 - Determine if a child table can be a data object Chi ld tables can be the attributes of data objects identified in step 1 or be data objects themselves. The considerat ion depends on whether the tables a lone are a c c e s s e d by other computer appl icat ions without access ing their parent tables. Step 3 - Assign relationship tables to data objects All attributes of a relationship table become the attributes of the data objects that represent the strong entities of the relationship. 77 4.4 Constructing Dynamic Objects Dynamic objects encapsulate all operat ions against each data object enabl ing the authors to develop their object-oriented view of IS architecture. T o construct a dynamic object, examine the application objects/modules that a c c e s s the tables assoc ia ted with the data object; determine the a c c e s s operat ions that are performed by these appl icat ions; and identify the programming objects and the data tables to which they have a c c e s s . It is then possib le to incorporate the operat ions of the appl icat ion (object/module) against the data objects into dynamic objects. 4.5 Connecting IS implementation and the ideal IS architecture The next step in understanding how existing IS supports the bus iness mode l , the data and dynamic objects derived from existing IS implementation are mapped into the \" ideal\" IS architecture derived from the model . O n c e completed, the var ious components are l inked to an \"implementation independent\" v iew of the bus iness. S ince the new view of IS is an object-oriented model , it a l lows eas ie r reengineering or restructuring and adoption of new IS architecture 5 Related Work The authors review the literature related to the use of objects in the attempting to capture information at the bus iness and IS architecture levels; facilitate change ; and reverse engineer existing sys tems as well as using object-oriented ana lys is methods to model bus iness p rocesses . 6 Conclusions The authors proposed a method for linking existing IS architecture to the bus iness model and descr ibed the methodology used to develop such a model . 78 They then illustrated a reverse translation of a specif ic appl icat ion and provided an example of such a mapping between the applications and the bus iness model for a te lecommunicat ions company. Whi le they acknowledge that more research is required, they bel ieve that they have demonstrated the applicabil i ty of the method. The authors bel ieve that their model ing approach and linking methodology provides a way to evaluate an IS in the context of bus iness needs and p rocesses ; a means of identifying reusable IS components, a method of \"reverse engineer ing\" the architecture of existing IS sys tems; facilitate migration to new platforms; support for the creation of an object-oriented view of exist ing appl icat ion and provide methods to aid in the development of \"organizat ional memory\". Relevance The linking research is relevant to creating Vert ical C R M solut ions a s it offers an approach to verify if a solution that has been developed actually meets the true needs that have been identified for the vertical market. 7 9 Appendix D - Interviewing Business Analysts for OOBM Research O n e key source of data for this paper was col lected from interviews with bus iness analysts who were working on actual C R M implementat ions. Col lect ing information from C R M bus iness analysts posed two primary cha l lenges. The first chal lenge is that bus iness analysts working on large projects are general ly under intense time constraints, which means that the time avai lable to an interviewer is l imited. Second ly they are very familiar with building C R M appl icat ions with current technologies, however, many are not famil iar with object oriented concepts and ideas. Provide Reading in Advance T o overcome the limited time avai lable the bas ics of the object-oriented approach to bus iness model ing was summar ized and e-mai led to the analysts a week before the interview was to take p lace. This approach proved useful in that it provided a foundation, however smal l , on which to base the interview. Understand Their Work Methodology By far, the most important strategy that al lowed good information to be col lected was spend ing time understanding the approach that the bus iness analysts currently used for defining a C R M solut ion. Understanding the p rocesses and steps that the analysts use for the speci f ic C R M package with which they are working with al lows the areas that are relevant to O O B M research to be identified and focused upon. The package that was used for the research presented in this paper had two primary phases of development. The first step entai led creating a data model , and the second step was to define bus iness p rocesses . O n c e these steps were completed, a user interface was generated to al low end users to interact with the sys tem. With and understanding of how the bus iness analysts worked it greatly s p e e d e d up the interview process . It was d iscovered, for instance, that when the GUI was 80 generated, the analysts a lso created a superset of candidates for bus iness objects; therefore, the conversat ion was able to quickly focus on the list of bus iness objects that appeared on the planned GUI . Having identified the bus iness object candidates it was then necessary to extract the list of requests for each object. Use Existing Project Documentation Extracting the requests was chal lenging at first s ince the bus iness analysts did not think in term of requests, but rather, in terms of bus iness p rocesses . It was necessary , therefore, to identify and step through the primary p rocesses of the sys tem and interpret the flow of the process in terms of object requests and responses rather than individual p rocesses . The p rocesses were general ly well documented and the bus iness analysts were able to be very helpful in identifying the requests and responses of the individual bus iness objects once they understood the O O B M terminology in context of the bus iness p rocesses they were familiar with. By being very organized, leveraging existing documentat ion for the C R M project, and breaking the interviews up into severa l short 30 min sess ions that suited the bus iness analysts schedu le it was possib le to col lect a large amount of data in relatively little time. 81 Appendix E - Construct ing Dynamic Objects Dynamic Object Assigned Relationship Tables Application Objects/Modules Description DynaContact Contact clsContact cIsContact.Add Adds a contact to the contact table clsContact. Modify Modifies a contact in the contact table dsContact.Remove Removes a contact from the contact table clsContact. Status Returns the status of the Contact Connection clsConnection cIsConnection.Add Adds a Connection to the Connection table clsConnection.Modify Modifies a Connection in the Connection table clsConnection.Remov e Removes a Connection from the Connection table clsConnection.Status Returns the status of the Connection DynaCompany Company clsCompany cIsCompany.Add Adds a company to the company table cIsCompany.Modify Modifies a company in the company table cIsCompany.Remove Removes a company from the company table clsCompany.Status Returns the status of the Company Connection clsConnection cIsConnection.Add Adds a Connection to the Connection table clsConnection.Modify Modifies a Connection in the Connection table 82 cIsConnection.Remov e Removes a Connection from the Connection table els.Connection.Status Returns the status of the Connection DynaProduct Product clsProduct cIsProduct.Add Adds a Product to the Product table clsProduct. Modify Modifies a Product in the Product table clsProduct. Remove Removes a Product from the Product table clsProduct.Status Returns the status of the Product Product_Feat ure clsProduct_Feature clsProduct_Feature.A dd Adds a Product Feature to the Product_Feature table clsProduct_Feature. Modify Modifies a Product Feature in the Product_Feature table clsProduct_Feature.R emove Removes a Product Feature from the Product_Feature table clsProduct_Feature.S tatus Returns the status of the Product Feature DynaAccount Account clsAccount_Features dsAccount.Add Adds an Account to the Account table cIsAccount.Modify Modifies an Account in the Account table cIsAccount. Remove Removes an Account from the Account table cls.Status Returns the status of the Account Features clsAccount_Features clsAccount_Features. Add Adds an Account Feature to the Account_Features table clsAccount_Features. Modify Modifies an Account Feature in the Account_Features table 83 clsAccount_Features. Remove Removes an Account Feature from the Account_Features table clsAccount_Features. Status Returns the status of the Account Features Account Holding clsAccount_Holding clsAccount_Holding.A dd Adds holdings to the Account_Holding table clsAccount_Holding. Modify Modifies holdings in the Account_Holding table clsAccount_Hplding. Remove Removes holdings from the AccountJHolding table clsAccount_Holding.S tatus Returns the status of the Account Holding DynaOpportunit y Opportunity clsOpportunity dsOpportunity.Add Adds an opportunity to the opportunity table cIsOpportunity.Modify Modifies an opportunity in the opportunity table cIsOpportunity.Remo ve Removes an opportunity from the opportunity table clsOpportunity.Status Returns the status of the Opportunity Opportunity_ Product clsOpportunity_Produ ct clsOpportunity_Produ ct.Add Adds a Product to the Opportunity_Product table clsOpportunity_Produ ct.Modify Modifies a Product in the Opportunity_Product table clsOpportunity_Produ ct.Remove Removes a Product from the Opportunity_Product table clsOpportunity_Produ Returns the status of the Opportunity 84 ct.Status Product Opportunity_ Product_Feat ures clsOpportunity_Produ ct_Features clsOpportunity_Produ ct_Features.Add Adds a Product Feature to the Opportunity_Product_Features table clsOpportunity_Produ ct_Features.Modify Modifies a Product Feature in the Opportunity_Product_Features table clsOpportunity_Produ ct_Features.Remove Removes a Product Feature from the Opportunity_Product_Features table clsOpportunity_Produ ct_Features.Status Returns the status of the Opportunity Product Features DynaActivity Activity cIsActivity cIsActivity.Add Adds activities to the Activity table cisActivity.Modify Modifies activities in the Activity table cIsActivity. Remove Removes activities from the Activity table cisActivity.Status Returns the status of the Activity DynaService Service_Req uest clsService_Request clsService_Request. Add Adds service requests to the Service_Request table clsService_Request. Modify Modifies service requests in the Service_Request table clsService_Request. Remove Removes service requests from the Service_Request table clsService_Request. Status Returns the status of the Service Request Work_Order clsWork_Order clsWork_Order.Add Adds work orders to the Work_Order table 85 clsWork_Order.Modif y Modifies work orders in the Work_Order table clsWork_Order.Remo ve Removes work orders from the Work_Order table clsWork_Order.Statu s Returns the status of the Work_Order 8 6 "@en ; edm:hasType "Thesis/Dissertation"@en ; vivo:dateIssued "2004-05"@en ; edm:isShownAt "10.14288/1.0099753"@en ; dcterms:language "eng"@en ; ns0:degreeDiscipline "Business Administration - Management Information Systems"@en ; edm:provider "Vancouver : University of British Columbia Library"@en ; dcterms:publisher "University of British Columbia"@en ; dcterms:rights "For non-commercial purposes only, such as research, private study and education. Additional conditions apply, see Terms of Use https://open.library.ubc.ca/terms_of_use."@en ; ns0:scholarLevel "Graduate"@en ; dcterms:title "Evaluation vertical strategies in CRM using an object-oriented approach"@en ; dcterms:type "Text"@en ; ns0:identifierURI "http://hdl.handle.net/2429/15081"@en .