Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Evaluation vertical strategies in CRM using an object-oriented approach Parkinson, Pierre 2003

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

Item Metadata

Download

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

Full Text

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 USING AN OBJECT-ORIENTED 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 a n a d v a n c e d d e g r e e at the University of British C o l u m b i a , I a g r e e that the Library shall m a k e it freely available for reference a n d study. I further a g r e e that permission for extensive c o p y i n g of this thesis for scholarly p u r p o s e s m a y be granted by the h e a d of my department or by his or her representatives. It is understood that c o p y i n g or publication of this thesis for financial gain shall not be allowed without my written p e r m i s s i o n .  1?  E  N a m e of Author (please print)  Title of T h e s i s :  Degree:  of  SU€NCB  lS>AU£>eP-  T h e University of British C o l u m b i a Vancouver, B C  {/eiiutA-u ^raAr£tui£S  ti/^urtT,^/^  flftiKretZ  Department of  Date (dd/mm/yyyy)  Canada  S  Y  *  .  o  f  e  a  r  :  thi  ZQQH ^SS^BSS  c&w,  Abstract  Software v e n d o r s are required to constantly adjust their product strategies to maintain the c o m p e t i t i v e n e s s of their products a s they evolve through the product lifecycle. C u s t o m e r Relationship M a n a g e m e n t ( C R M ) software r e a c h e d , what m a n y c o n s i d e r e d , the mature stage of its lifecycle in the y e a r 2 0 0 0 . T o prevent s a l e s from stagnating in a maturing market, s o m e C R M v e n d o r s a d o p t e d a strategy of d e v e l o p i n g vertical C R M solutions to continue s a l e s growth by exploiting well-defined niche markets.  T o d e v e l o p a vertical C R M product it is n e c e s s a r y to create a single solution that c a n easily be c u s t o m i z e d to suit the n e e d s of a set of c o m p a n i e s in a defined industry. T h e objective of this paper is to investigate if a n object-oriented b u s i n e s s m o d e l i n g t e c h n i q u e is appropriate for defining vertical C R M solutions.  T o investigate the a p p r o p r i a t e n e s s of a n object-oriented b u s i n e s s m o d e l i n g technique, object-oriented b u s i n e s s m o d e l s w e r e c r e a t e d for two financial s e r v i c e s organizations a n d then c o m p a r e d to a n actual vertical C R M solution that w a s known to be s u c c e s s f u l .  T h e results of the a n a l y s i s demonstrate that object-oriented modeling t e c h n i q u e s c a n be u s e d s u c c e s s f u l l y to both define the requirements for vertical C R M solutions, a s well a s to test if a vertical C R M solution m e e t s those requirements.  T h e implication of this r e s e a r c h is that object-oriented b u s i n e s s a n a l y s i s s h o w s p r o m i s e in defining vertical C R M solutions a n d that this technique c o u l d be a d o p t e d by industry to a c c e l e r a t e the d e v e l o p m e n t c y c l e s of vertical C R M solutions.  ii  T a b l e of C o n t e n t s Abstract T a b l e of C o n t e n t s List of T a b l e s List of Figures Chapter I Introduction 1.1 Defining a C R M Solution 1.2 Solution Definition U s i n g D a t a M o d e l i n g 1.3 Solution Definition U s i n g P r o c e s s M o d e l i n g 1.4 Solution Definition U s i n g R o l e a n d interaction b a s e d modeling 1.5 Defining vertical C R M solutions C h a p t e r II  C h a p t e r III  S e l e c t i n g the Appropriate M o d e l i n g A p p r o a c h for Vertical C R M Solutions 2.1 R e q u i r e m e n t s of a vertical C R M m o d e l 2.2 D a t a Modeling 2.3 P r o c e s s Modeling 2.4 Role/interaction b a s e d m o d e l i n g 2.5 S e l e c t i n g the Most Appropriate M o d e l i n g A p p r o a c h 2.6 Related Work M o d e l i n g C R M R e q u i r e m e n t s for T w o Financial S e r v i c e s Organizations 3.1 Research Overview 3.2 M o d e l i n g the C R M R e q u i r e m e n t s of a Rural Bank 3.3 S t e p 1: Rural B a n k B u s i n e s s M o d e l Definition 3.4 S t e p 2 : Aggregating the R u r a l B a n k ' s S e r v i c e T y p e s 3.5 S t e p 3: Objectifying the Rural B a n k ' s S e r v i c e s 3.6 S t e p 4: A s s i g n m e n t of requests from the Rural B a n k ' s b u s i n e s s model to objects 3.7 S t e p 5: Identify Internal Object Interactions in the R u r a l Bank's Business Model 3.8 S t e p 6: Verify integrity of d a t a objects of the R u r a l B a n k ' s b u s i n e s s model 3.9 External R e q u e s t s of the Rural B a n k b u s i n e s s m o d e l 3.10 M o d e l i n g the C R M R e q u i r e m e n t s of a Private B a n k i n g Institution 3.11 External R e q u e s t s of the Private B a n k b u s i n e s s m o d e l 3.12 S u m m a r y of R e s e a r c h in C h a p t e r III  ii iii v vi 1 4 5 6 7 8  9 9 10 10 11 12 14  16 16 23 25 27 28 31 32 33 33 34 35 36  C h a p t e r IV System  Constructing D a t a a n d D y n a m i c Objects from a n Existing C R M 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9  37 T h e Vertical F i n a n c i a l S e r v i c e s T e m p l a t e 37 E R D for Financial S e r v i c e s C R M T e m p l a t e 39 S t e p 1 - Identification of all major or strong entities from the database 40 S t e p 2 - Determine if a child table is a c a n d i d a t e for a data object 40 S t e p 3 - A s s i g n m e n t of Relationship T a b l e s to D a t a Objects 41 S t e p 4: Constructing D y n a m i c Objects 43 D a t a a n d D y n a m i c Objects for the Financial S e r v i c e s Template 44 Relationships between Dynamic Objects and Application Objects 46 S u m m a r y of r e s e a r c h d e s c r i b e d in C h a p t e r IV 46  Chapter V  Linking the Ideal B u s i n e s s M o d e l s to the Existing C R M S y s t e m . . . 4 7 5.1 Identifying Static a n d Delegate Objects for the R u r a l Bank 47 5.2 Linking Static Objects from the Rural B a n k to the F i n a n c i a l Services C R M Template 48 5.3 Linking D y n a m i c Objects from the Private B a n k to the Financial S e r v i c e s C R M T e m p l a t e 49 5.4 Identifying Static a n d Delegate Objects for the Private Bank 49 5.5 Linking Static Objects from the Private B a n k to the F i n a n c i a l Services C R M Template 50 5.6 Linking D y n a m i c O b j e c t s f r o m the Private B a n k to the Financial S e r v i c e s C R M T e m p l a t e 51  C h a p t e r VI  Conclusion 6.1 Creating the Ideal B u s i n e s s M o d e l s 6.2 Constructing D a t a Objects from Existing IT 6.3 A r e a s for Future R e s e a r c h  53 53 54 55  S i x - S t e p O O B M P r o c e s s for Private B a n k Research Summary 1 Research Summary 2 Interviewing A n a l y s t s for O O B M R e s e a r c h Constructing D y n a m i c Objects  57 59 68 73 80 82  References Appendix A Appendix B Appendix C Appendix D Appendix E  iv  List of T a b l e s T a b l e 1.  External Object Definition for Rural B a n k C R M s y s t e m  26  T a b l e 2.  External requests to the Rural B a n k C R M S y s t e m  27  T a b l e 3.  Aggregation of s e r v i c e s for the Rural B a n k C R M S y s t e m  28  T a b l e 4.  Objects created to handle service types for the R u r a l B a n k C R M System  T a b l e 5.  A s s i g n i n g requests to Objects from the Rural B a n k C R M System  T a b l e 6.  29  31  Identifying internal interactions of the Rural B a n k C R M System  32  T a b l e 7.  C h i l d T a b l e Determination for Rural B a n k  40  T a b l e 8.  A s s i g n m e n t of Relationship T a b l e s to D a t a O b j e c t s  42  V  List of Figures Figure Figure Figure Figure Figure Figure Figure  1 2 3 4 5a 5b 6  Figure 7 Figure 8 Figure 9 Figure 10  Steps Followed in the Study 19 O O E M of the Rural Bank business model 33 O O E M of the Private Bank business model 35 E R D for Financial Services C R M Template 39 Data and Dynamic Objects for the Financial Services Template...44 Data and Dynamic Objects for the Financial Services Template...45 Relationships between Dynamic Objects and Application Objects 46 Linking Static Objects from the Rural Bank to the Financial Services C R M Template 48 Linking Dynamic Objects from the Private Bank to the Financial Services C R M Template 49 Linking Static Objects from the Private Bank to the Financial Services C R M Template 50 Linking Dynamic Objects from the Private Bank to the Financial Services C R M Template 51  vi  Chapter I - Introduction  " C R M is d e a d " T o m S i e b e l d e c l a r e d . T h e future of C R M , a c c o r d i n g to S i e b e l while s p e a k i n g at the a n n u a l C u s t o m e r Relationship M a n a g e m e n t C o n f e r e n c e held S e p t e m b e r 2 0 0 2 in N e w Y o r k , is going to be in vertical b u s i n e s s p r o c e s s e s a n d W e b s e r v i c e s . G i v e n that his multi-billion dollar c o m p a n y , S i e b e l S y s t e m s , w a s currently the leader in the enterprise C R M software market, these statements certainly raised e y e b r o w s . T o understand the context in which S i e b e l ' s statements w e r e m a d e it is n e c e s s a r y to take a look at why the C R M market e m e r g e d a n d how it e v o l v e d .  T h e story of C R M b e g i n s in the early 1 9 9 0 s w h e n the E R P market w a s still enjoying rapid growth. E R P h a d b e e n a r o u n d in o n e form or another for 3 0 y e a r s helping organizations w h o s e b u s i n e s s involved s o m e c o m p o n e n t of c o m p l e x manufacturing, to s q u e e z e out inefficiencies a n d i n c r e a s e collaboration in a r e a s s u c h a s materials requirements planning, finance, e n g i n e e r i n g , project m a n a g e m e n t a n d h u m a n r e s o u r c e s . (1) E R P products, d e s i g n e d to handle h u g e transaction v o l u m e s a n d critical b u s i n e s s p r o c e s s e s , h a d rigid architectures that w e r e coldly efficient for grinding a w a y the b a c k office p r o c e s s e s that m a d e m u c h of the product f o c u s e d , manufacturing b a s e d , e c o n o m y h u m .  A s the global e c o n o m y e v o l v e d in the 1 9 8 0 s , service b a s e d industries b e g a n to take o n a more important role a n d a new s c h o o l of thought g a i n e d m o m e n t u m placing the customer, rather than products a n d the supply c h a i n , at the center of b u s i n e s s strategies. (2) Back-office efficiencies w e r e v i e w e d a s a minimum requirement for doing b u s i n e s s but, market s h a r e , it w a s now believed, would be w o n a n d lost by f o c u s i n g on t e c h n i q u e s a n d strategies for automating a n d standardizing the internal p r o c e s s e s a s s o c i a t e d with capturing, servicing, a n d retaining c u s t o m e r s .  T h i s new b r e e d of "customer f o c u s e d " organization  required a new breed of enterprise software - C u s t o m e r Relationship M a n a g e m e n t ( C R M ) software w a s born.  1  Early entrants into the C R M market f o c u s e d on specific a r e a s of C R M to gain market s h a r e . S i e b e l s y s t e m s for instance f o c u s e d o n s a l e s force automation functionality w h i c h allows s a l e s p e o p l e to keep track of their c u s t o m e r s a n d Clarify f o c u s e d on call center functionality w h i c h allows large call centers to automate inbound a n d outbound calling p r o c e s s e s . T h e s e pioneers of the C R M industry w h o h a d early s u c c e s s , w e r e a l s o the first c o m p a n i e s to e x p a n d their product footprints to offer c u s t o m e r s a complete C R M suite that h a d functionality in the three key a r e a s of C R M : s a l e s , marketing a n d support.  T h e late 1 9 9 0 s s a w rapid s a l e s growth for C R M v e n d o r s a s c o m p a n i e s spent freely o n C R M initiatives. T h e C R M industry in turn, spent freely o n marketing m e s s a g e s to c o n v i n c e m o r e c o m p a n i e s that they n e e d e d to s p e n d a s i z a b l e portion of their IT budgets o n C R M or risk losing their c u s t o m e r s to c o m p a n i e s that did.  At the s a m e time a s the C R M hyperbole w a s r e a c h i n g a c r e s c e n d o ,  the hype a s s o c i a t e d with the Internet w a s a l s o rising.  Largely driven by investments in the t e l e c o m m u n i c a t i o n s sector, the Internet's infrastructure matured to a point w h e r e corporations b e g a n to rely on the low c o s t network for s e r v i c e s s u c h a s e-mail, a n d e x p e c t e d their C R M implementations to leverage it a s well. T h i s market d e m a n d for products that w e r e d e s i g n e d to u s e the Internet forced C R M v e n d o r s to invest R & D dollars into updating their software architectures from client server architectures, d e s i g n e d to leverage local a r e a networks, to "3 tier" architectures that u s e d Internet related t e c h n o l o g i e s a n d s t a n d a r d s s u c h a s X M L over H T T P a s their c o r e m e t h o d of inter-application communication.  A g a i n s t this b a c k d r o p of rapid adoption of C R M a n d f u n d a m e n t a l c h a n g e s in the architectures of C R M v e n d o r s , the s a l e s environment for C R M s u d d e n l y c h a n g e d in 2001 from rapid growth to retrenchment. C R M v e n d o r s started m i s s i n g s a l e s targets a n d the b u s i n e s s p r e s s s t o p p e d extolling the virtues of C R M a n d quickly  2  filled their p a g e s with stories of failed C R M implementations a n d dire w a r n i n g s that corporations now n e e d e d to carefully establish return o n investment metrics a n d clearly link how a n y p l a n n e d C R M implementations c o u l d pay for t h e m s e l v e s . (3)  N e w product a n d s a l e s strategies had to be i m p l e m e n t e d quickly if C R M v e n d o r s w e r e going to regain s o m e of the m o m e n t u m that they h a d s o quickly lost. (4) C o r p o r a t i o n s w e r e now m u c h more rigorous in the p u r c h a s i n g c y c l e a n d w e r e d e m a n d i n g more from C R M v e n d o r s to reduce their implementation risk.  One  strategy that h a s e m e r g e d a s holding great p r o m i s e to meet the c h a l l e n g e s of this n e w environment h a s b e e n to offer product features that are tailored for specific vertical market s e g m e n t s .  S i e b e l s y s t e m s , the a c k n o w l e d g e d C R M  market leader, c l a i m e d that in 2 0 0 2 , 8 0 % of their software l i c e n s e r e v e n u e w a s from s a l e s related to products serving specific vertical markets. (5)  G a r t n e r group h a s a l s o r e c o m m e n d e d that in order to c o m p e t e in a highly competitive C R M software market, v e n d o r s s h o u l d c o m p l i m e n t their existing product lines with vertical solutions that reduce the risk for buyers a s well a s r e d u c e the time required for implementation. (6) In effect, by offering a vertical solution, the C R M v e n d o r a s s u m e s a portion of the implementation risk by m a k i n g a n upfront investment in the features a n d p r o c e s s e s required for the given vertical industry. If the vertical solution r e s o n a t e s with the target industry, the C R M v e n d o r is r e w a r d e d with i n c r e a s e d market s h a r e in the identified vertical market.  T o provide insight to C R M v e n d o r s o n how to best define functionality required for a vertical solution, this p a p e r will explore three t e c h n i q u e s for m o d e l i n g a vertical b u s i n e s s solution: d a t a b a s e d modeling, p r o c e s s b a s e d modeling a n d role b a s e d m o d e l i n g . M o d e l i n g a p p r o a c h e s , if they c a n be u s e d s u c c e s s f u l l y , h a v e the potential to allow C R M v e n d o r s to d e v e l o p vertical solutions m o r e  3  accurately a n d quickly a s they create a representation of the organizational d o m a i n for w h i c h the information s y s t e m is d e v e l o p e d (17).  T h e d e c i s i o n m a k i n g p r o c e s s u s e d by a software v e n d o r that is pursuing vertical markets to determine w h i c h vertical market to target requires m a n y inputs. Factors c o m m o n l y c o n s i d e r e d w h e n selecting w h i c h vertical markets to c r e a t e solutions for include, the existing markets a n d c u s t o m e r s that the c o m p a n y s e r v e s , the nature of the software solution currently offered a n d the r e s o u r c e s available to d e v e l o p the solution.  R e g a r d l e s s of the method u s e d to d e t e r m i n e  w h i c h vertical s e g m e n t to target, o n c e identified, the task of defining the s p e c i f i c features a n d functions of the vertical solution b e g i n s .  1.1 Defining a C R M Solution  T h e definition of a vertical C R M solution s e r v e s two primary p u r p o s e s .  Firstly,  it s e r v e s a s a point of reference for the t e a m t a s k e d with d e v e l o p i n g the solution to e n s u r e the right solution is built. S e c o n d l y , it must allow d e c i s i o n m a k e r s at c o m p a n i e s that are c o n s i d e r i n g implementing the solution to understand the functionality a n d benefits of the solution a s well a s how the solution c o u l d fit into their existing IT framework.  It is of critical importance that the high-level vertical  solution definition is understandable by both the technical community a n d the b u s i n e s s c o m m u n i t y to e n s u r e that the correct s y s t e m is d e v e l o p e d to s o l v e the organization's b u s i n e s s pains.  T h e following section will review three c o m m o n modeling t e c h n i q u e s u s e d by b u s i n e s s a n a l y s t s for defining information s y s t e m s : •  d a t a modeling  •  p r o c e s s modeling  •  object modeling  4  T h e s e three m o d e l i n g t e c h n i q u e s w e r e s e l e c t e d a s they are c o m m o n l y taught in b u s i n e s s a n a l y s i s c o u r s e s (7) a n d are c o m m o n l y u s e d in industry a s tools to d e s i g n C R M s y s t e m s (8). A r e c o m m e n d a t i o n 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 D a t a m o d e l i n g is the p r o c e s s of defining all the entities a n d attributes that are required for a given information s y s t e m , a s well a s the relationships b e t w e e n t h o s e entities. A d a t a m o d e l acts a s the d a t a foundation over w h i c h information s y s t e m s c a n b e built.  A well thought out d a t a model allows powerful, flexible  a n d stable applications to be built. A poorly p l a n n e d data model results in a n application that m a y meet initial requirements, but over time a s feature a n d functional e n h a n c e m e n t s are a d d e d , will s e e m to always n e e d to be " s h o e h o r n e d " to offer the d e s i r e d functionality (9). D a t a modeling m e t h o d s c o m p r i s e of modeling t e c h n i q u e s a n d modeling p r o c e s s e s . T h e p r o c e s s is d e f i n e d in terms of guidelines a n d rules o n m a p p i n g k n o w l e d g e about the m o d e l e d d o m a i n into the constructs of the modeling technique (17).  T h e following e x a m p l e illustrates the types of d e c i s i o n s that are m a d e by a d a t a modeler.  If a d a t a m o d e l w e r e created for a financial application a n d the majority of products a n d s e r v i c e s offered in the s y s t e m could be offered to both individuals a n d to o r g a n i z a t i o n s , it would be tempting to create a single entity that c o n t a i n e d all the attributes required for both individuals a n d organizations a n d link all the products a n d s e r v i c e s that are offered by the financial institution to this o n e entity. A benefit of this a p p r o a c h w o u l d be that all relationships to both individuals a n d organizations would only n e e d to be created o n c e . A d r a w b a c k of this a p p r o a c h w o u l d be that certain s e a r c h e s would now take longer.  It is up  to the d a t a m o d e l e r to b a l a n c e the benefits v e r s u s the d r a w b a c k s . If the financial  5  institution that will be using this s y s t e m has e m p l o y e e s that only d e a l with individuals, a n d other e m p l o y e e s w h o only deal with organizations, than the time spent sorting through all organizations a n d individuals for e a c h s e a r c h may not be a c c e p t a b l e , however, if it is important to be able to view s e a r c h results in w h i c h individuals a n d organizations are interchangeable it m a y be worthwhile to create a single entity for both individuals a n d organizations.  T h i s s i m p l e e x a m p l e illustrates a d a t a modeler's potential impact o n a n e n d users experience.  D a t a modeling a l s o c a n have a large impact o n a s y s t e m ' s  maintainability, p e r f o r m a n c e a n d the e a s e with which it c a n be integrated to other systems.  1.3 Solution Definition Using Process Modeling In defining a C R M s y s t e m using a p r o c e s s modeling a p p r o a c h , the b u s i n e s s analyst d e s c r i b e s the s y s t e m a s a network of interacting p r o c e s s e s , or a s e q u e n c e of actions performed by the s y s t e m , with the aim of finding the set of p r o c e s s e s that c a n c o m p l e t e the t a s k s most efficiently. T h e definition of what is efficient will vary from s y s t e m to s y s t e m but will usually be m e a s u r e d by metrics s u c h a s how quickly the t a s k s c a n be c o m p l e t e d , how m a n y p e o p l e will be n e e d e d to c o m p l e t e the task, a n d finally, what r e s o u r c e s are required. Often p r o c e s s e s that have b e e n s h o w n to work in similar environments c a n be r e u s e d a n d are termed "Industry B e s t P r a c t i c e s " . T y p i c a l of c l a i m s surrounding C R M B e s t P r a c t i c e s is the following from the S i e b e l S y s t e m s W e b site:  http://www.siebel.com/bestpractices/fujitsu_siemens.shtm  With  Siebel Sales a n d Siebel Call Center, Fujitsu S i e m e n s C o m p u t e r s h a s : R e d u c e d overall order p r o c e s s i n g time by 65 percent  6  Increased lead c o n v e r s i o n rates by 4 5 percent R e d u c e d reseller order p r o c e s s i n g time from 2 d a y s to approximately 3 0 minutes T h i s promotional text a n n o u n c e s that by using the S i e b e l S a l e s product a n d the S i e b e l C a l l C e n t e r product Fujitsu h a s b e e n able to implement the best practices c o n t a i n e d in the order p r o c e s s , lead c o n v e r s i o n p r o c e s s a n d order p r o c e s s to p r o c e s s quicker, convert m o r e , a n d sell faster. W h e n defining the p r o c e s s e s required in a s y s t e m , the analyst populates a d a t a dictionary which contains a description of the d a t a required to perform the p r o c e s s . A s the set of p r o c e s s e s grows the d a t a dictionary a l s o grows until all the p r o c e s s e s h a v e b e e n defined a n d there is a c o m p l e t e listing of the d a t a that is required.  1.4 Solution Definition Using Role and interaction based modeling R o l e a n d interaction b a s e d m o d e l i n g doesn't f o c u s o n the underlying d a t a or p r o c e s s but rather g r o u p s functionality around objects that exist in the real world that c a n receive a n d a n s w e r m e s s a g e s . T h e complexity of the inner workings of the object remain hidden from a n analyst allowing t h e m to f o c u s more o n what a s y s t e m s h o u l d d o rather than h o w the s y s t e m s h o u l d d o it. If w e are to c o n s i d e r a simple banking s y s t e m defined using a role a n d interaction m o d e l , there might be three objects that represent the customer, the a c c o u n t m a n a g e m e n t s y s t e m , a n d the c u s t o m e r s e r v i c e function. T h e model c o u l d easily e x p r e s s that c u s t o m e r c a n write a c h e q u e , a c h e q u e c a n be d e p o s i t e d a n d a n a c c o u n t c a n a c c e p t a deposit a n d return a confirmation by creating a s i m p l e drawn representation of the three objects with lines b e t w e e n the objects to indicate the actions of writing a c h e q u e or m a k i n g a deposit. U s i n g this method the e s s e n c e of the roles involved a s well a s the interactions are captured without n e e d i n g to f o c u s on the underlying d a t a . A n analyst modeling s u c h a s y s t e m using a role a n d interaction modeling technique c a n model this s i m p l e banking s y s t e m without n e e d i n g to define the  7  details a s s o c i a t e d with the transaction s u c h a s what information is required o n the c h e q u e or what information is required to verify the m o n e y is d e p o s i t e d into the correct account. T h e s e details are vitally important to the correct functioning of the final s y s t e m , however, they d o not n e e d to be defined in this high level model.  1.5 Defining vertical C R M s o l u t i o n s A s has b e e n mentioned in m a n y popular p r e s s articles, C R M offers great return w h e n d o n e properly but o n the other h a n d , the implementation failure rate is very high (10).  W e b e l i e v e , b a s e d o n interviews with b u s i n e s s analysts w h o  implement C R M s y s t e m s , that the biggest r e a s o n that C R M implementations fail is that they are very c o m p l e x s y s t e m s that c a n c o m p r i s e of 10 or more s u b s y s t e m s s u c h a s a call-center, analytics, s e r v i c e a n d warranty, c o m p l e x configuration, w e b p e r s o n a l i z a t i o n , a n d s a l e s force automation a n d the current m e t h o d s u s e d to define the solutions are too f o c u s e d on how the s y s t e m s work a n d not f o c u s e d e n o u g h o n what the s y s t e m s c a n do.  T h e result of using definition a p p r o a c h e s f o c u s e d o n implementation is that b u s i n e s s p e o p l e a n d technologists are not able to s p e a k a c o m m o n l a n g u a g e to d e s c r i b e the target functionality a n d a s a result, in m a n y c a s e s , the w r o n g C R M s y s t e m s get built w h i c h fail to meet expectations.  O u r contention is that a  promising modeling m e t h o d for defining vertical C R M solutions is the role a n d interaction modeling a p p r o a c h d u e to its ability to "hide" complexity a n d f o c u s o n what a s y s t e m will d o rather than how it will d o it. T h e following c h a p t e r s will explore this hypothesis in more detail. B e l o w are the main topics c o v e r e d in e a c h chapter: C h a p t e r 2 - S e l e c t i n g the optimum method of modeling C R M applications C h a p t e r 3 - C r e a t i n g B u s i n e s s m o d e l s for two b a n k s C h a p t e r 4 - C r e a t i n g a n object perspective of a n existing IT s y s t e m C h a p t e r 5 - Linking the bank b u s i n e s s m o d e l s to a n existing IT s y s t e m Chapter 6 - Conclusions  8  Chapter II - Selecting the Appropriate Modeling Approach for Vertical CRM Solutions  Having e x p l o r e d the key i d e a s behind d a t a , p r o c e s s , a n d role/interaction b a s e d modeling t e c h n i q u e s , this chapter will explore w h y w e believe that role/interaction b a s e d modeling t e c h n i q u e s are the most appropriate for creating m o d e l s for vertical C R M solutions.  2.1 requirements of a vertical CRM model W h e n creating a m o d e l for a vertical C R M solution it is n e c e s s a r y to be a b l e to capture the e s s e n c e of what b u s i n e s s e s in the target industry do without getting distracted by the implementation details of how the b u s i n e s s e s d o it. W h a t b u s i n e s s e s d o is usually d e s c r i b e d in terms of the products or s e r v i c e s the b u s i n e s s offers a n d the c u s t o m e r s they s e r v e . H o w b u s i n e s s e s a c c o m p l i s h t h e s e functions, is usually d e s c r i b e d by s y s t e m s a n d p r o c e s s e s .  If there is not  e n o u g h c o m m o n functionality in what b u s i n e s s e s d o a c r o s s a vertical market then it is unlikely that the industry will be a g o o d candidate for a vertical C R M solution. It is, therefore, imperative to understand early o n in the a n a l y s i s p r o c e s s if e n o u g h c o m m o n b u s i n e s s functionality exists to warrant a n investment in a vertical solution.  T o discover what a b u s i n e s s d o e s , it is best to interview the b u s i n e s s p e o p l e within a n organization.  M e m b e r s of the s a l e s , marketing, product, a n d  administration departments have visibility a c r o s s different functions a n d a r e a b l e to articulate the key functions of a b u s i n e s s . T e c h n o l o g i s t s , on the other h a n d , s u c h a s m e m b e r s of the IT staff, are best suited for describing how the b u s i n e s s performs those functions, therefore, the key to being able to model C R M solutions is to u s e a modeling technique that c a n be understood by the b u s i n e s s community within a n organization.  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 highlevel 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. A s 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 m a y be applied to a n entity a n d the relationships b e t w e e n entities are hidden within the p r o c e s s e s making it difficult to understand the impact of the s y s t e m on specific entities a n d more importantly, to get a n overall understanding of the s y s t e m . F o r e x a m p l e , if w e w e r e defining the c u s t o m e r lifecycle p r o c e s s , different portions of the p r o c e s s w o u l d define how l e a d s are c a p t u r e d , how p r o s p e c t s are c r e a t e d , how a contract s h o u l d be c o m p l e t e d a n d finally h o w to c r e a t e a c u s t o m e r . O n c e a g a i n , similar to d a t a modeling, a p r o c e s s m o d e l is g o o d at defining features of a specific implementation but is too specific to be useful for defining a vertical C R M solution.  A l s o , p r o c e s s modeling is difficult to  m o d u l a r i s e d u e to the relationships b e t w e e n entities being hidden within the p r o c e s s e s making it difficult for the s a m e s y s t e m to be u s e d in two implementations w h e n only o n e a s p e c t of the implementation m a y be different. C o m b i n i n g p r o c e s s modeling with d a t a modeling would not yield the results n e e d e d for describing a g e n e r a l vertical C R M solution either, a s the d a t a m o d e l would b e tied to the implementation of a specific p r o c e s s . For e x a m p l e , in the c u s t o m e r lifecycle p r o c e s s d e s c r i b e d a b o v e any c h a n g e s in the p r o c e s s would result in c h a n g e s to the underlying d a t a m o d e l a s well s i n c e the p r o c e s s is not tied to real world entities it is difficult to create a g e n e r a l i s e d supporting d a t a m o d e l without g u i d a n c e of w h e r e the p r o c e s s m a y be e x t e n d e d .  G i v e n that the  prime g o a l of modeling a vertical C R M solution is to gain a n overall understanding of the p r o p o s e d s y s t e m , p r o c e s s modeling is not a n appropriate approach.  2.4 Role/interaction based modeling  T h e m a i n feature of object b a s e d modeling techniques that c a n potentially offer m a n y benefits for defining vertical C R M solutions is e n c a p s u l a t i o n . E n c a p s u l a t i o n is the ability to be able to s h o w the key features of a n entity without having to s h o w b a c k g r o u n d information or u n n e c e s s a r y detail. Object oriented a p p r o a c h e s a c h i e v e encapsulation by treating a n object a s a "black box" that c a n only be c o m m u n i c a t e d with by s e n d i n g it m e s s a g e s . B y defining the types of requests  11  a n object c a n a c c e p t a n d r e s p o n s e s that it c a n g e n e r a t e , it is p o s s i b l e to define what a n object d o e s without having to understand, h o w the object a c h i e v e s its functionality.  A n o t h e r benefit of e n c a p s u l a t i o n is that it m a k e s object oriented  m o d e l i n g techniques a useful tool for m a n a g i n g complexity. In C R M s y s t e m s that are routinely c o m p r i s e d of s e v e r a l interacting software s y s t e m s s u c h a s call centers, analytics p a c k a g e s a n d configuration tools, t e c h n i q u e s for m a n a g i n g complexity a n d maintaining a n overall view of s y s t e m functionality are n e c e s s a r y to e n s u r e that the s y s t e m is delivering v a l u e a n d meeting stated g o a l s .  E n c a p s u l a t i o n a l s o results in functionality being g r o u p e d a r o u n d real-world entities, which m a k e s the resulting m o d e l e a s i e r to understand for non-technical users. In C R M s y s t e m s for instance, typical objects that e m e r g e are the different types of individuals that will interact with a s y s t e m s u c h a s c u s t o m e r s , m a n a g e r s , or partners of a n organization. T h i s partitioning a n d grouping of functionality a r o u n d real world constructs reflects how m a n y organizations are a r r a n g e d with the marketing a n d s a l e s responsible for m a n y c u s t o m e r functions, a n d the partner organization responsible for partners.  2.5 Selecting the Most Appropriate Modeling Approach T h e object-oriented a p p r o a c h for m o d e l i n g vertical C R M solutions that will be u s e d in this r e s e a r c h p a p e r is the Object-Oriented B u s i n e s s M o d e l i n g ( O O B M ) a p p r o a c h p r o p o s e d in " D e v e l o p i n g B u s i n e s s M o d e l s to S u p p o r t Information S y s t e m Evolution" by Y a i r W a n d , C a r s o n W o o a n d S a m s o n H u i . T h e O O B M a p p r o a c h w a s s e l e c t e d b e c a u s e it is object-oriented, it h a s b e e n u s e d s u c c e s s f u l l y in the past (11), a n d it a i m s to d e s c r i b e a n organization by the products a n d s e r v i c e s that it delivers w h i c h is precisely the a p p r o a c h that is required to define vertical C R M solutions. For a s u m m a r y of this p a p e r s e e A p p e n d i x B.  12  The W W H 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.  A s 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).  A s 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 a p p r o p r i a t e n e s s of n e w software s y s t e m s being c o n s i d e r e d a s additions to existing IT infrastructure (16).  A l o n g with r e s e a r c h determining if  new software s y s t e m s deliver the required functionality, relevant r e s e a r c h h a s a l s o b e e n c o n d u c t e d in the a r e a of linking existing IT infrastructures to b u s i n e s s m o d e l s to establish a reference point that reflects the core b u s i n e s s b e h a v i o u r which is l e s s fluid than the actual IT implementations supporting the b u s i n e s s behaviour m a k i n g longer term IT planning p o s s i b l e (11).  R e s e a r c h in this p a p e r differs from previous r e s e a r c h in that the f o c u s of this p a p e r is from the perspective of the software v e n d o r rather than from the perspective of a n organization c o n s i d e r i n g a n e w software solution.  B y turning  the r e s e a r c h perspective to the software v e n d o r ' s perspective, the c h a l l e n g e s that are f a c e d are different from the c h a l l e n g e s a single c u s t o m e r w o u l d e x p e r i e n c e s i n c e a set of organizations n e e d to be c o n s i d e r e d before a n optimal solution c a n be defined rather than a unique implementation.  A n o t h e r significant  difference in the r e s e a r c h c o n d u c t e d in this p a p e r is that this p a p e r a i m s to bring the three a r e a s of relevant r e s e a r c h together w h e r e a s previous r e s e a r c h h a s h a d a more specific f o c u s o n e a c h given topic.  15  Chapter III - Modeling CRM Requirements for Two Financial Services Organizations 3.1 Research Overview  T h e g o a l of the thesis is to determine if it is p o s s i b l e a n d feasible to define the required functionality of a vertical C R M s y s t e m of a specific vertical industry s e g m e n t b a s e d o n the Object-Oriented B u s i n e s s M o d e l i n g ( O O B M ) a p p r o a c h p r o p o s e d in " D e v e l o p i n g B u s i n e s s M o d e l s to S u p p o r t Information S y s t e m Evolution" by Y a i r W a n d , C a r s o n W o o a n d S a m s o n Hui. T h e financial s e r v i c e s industry w a s s e l e c t e d a s the vertical industry s e g m e n t for the study d u e to: •  T h e industry h a s actual C R M s y s t e m s in operation a n d it a l s o provided a c c e s s to a known g o o d m o d e l .  •  Its market s i z e a n d potential s a l e s r e v e n u e h a v e attracted m a n y different C R M providers.  •  T h e organizations within the financial s e r v i c e s industry h a v e b e e n early a d o p t e r s of C R M s y s t e m s d u e to the a c k n o w l e d g e d importance of establishing personal relationships with their c u s t o m e r s .  •  C o n s o l i d a t i o n within the s e g m e n t h a s resulted in i n c r e a s e d c o m p e t i t i v e n e s s a m o n g the m e m b e r firms to offer m o r e individualized products a n d s e r v i c e s which h a s i n c r e a s e d d e m a n d for more sophisticated yet more m a n a g e a b l e C R M s y s t e m s .  •  T h e fact that m a n y early C R M s y s t e m s within the financial s e r v i c e s sector w e r e not entirely satisfactory indicating that a different a p p r o a c h to d e s i g n i n g C R M functionality a n d implementation, s u c h a s t h o s e offered by O O B M , is warranted.  Research Design Internal v s . 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  findings will apply to other settings a n d whether the findings will continue to apply o v e r time.  T h e study controls the threats to external validity by: •  T h e s a m p l e drawn from the population w a s s e l e c t e d to e n s u r e that the main types of financial institutions a n d C R M s y s t e m s w e r e r e p r e s e n t e d . That there w a s a n e s t a b l i s h e d history of C R M implementation a n d u s e , a n d that the individuals interviewed w e r e a c k n o w l e d g e d by p e e r s a s b e i n g familiar with the c h a l l e n g e s a s s o c i a t e d with C R M s y s t e m s a n d h a d a thorough understanding of their respective institutions n e e d s a n d u s e of C R M systems.  •  T h e applicability of t h e s e findings to other settings is validated by c o m p a r i n g the results to the known g o o d m o d e l of C R M that has b e e n a c c e p t e d by the industry. Rather than theorize about the functionality of a s u c c e s s f u l C R M s y s t e m , the C R M s y s t e m d e v e l o p e d is b e n c h m a r k e d against a n a c c e p t e d industry s t a n d a r d .  •  T h e applicability of t h e s e findings to apply o v e r time is p e r h a p s the w e a k e s t of the external validity i s s u e s . W h i l e the actual r e s e a r c h is b e i n g c o n d u c t e d at a time w h e n i s s u e s related to C R M s y s t e m s are the f o c u s of great efforts by both providers a n d c u s t o m e r s alike, the rapid technological c h a n g e s a n d competitive p r e s s u r e within the industry m a k e predictions for future implementations difficult. T h e study h a s attempted to control for this through the utilization of the most recent theoretical d e v e l o p m e n t s in object oriented that are able to capture the e s s e n c e of a C R M s y s t e m irrespective of the underlying t e c h n o l o g y a s well a s by c o m p a r i n g the theoretical model to a known g o o d C R M s y s t e m .  O v e r v i e w of Different P h a s e s of R e s e a r c h S t u d y  A s c h e m a t i c representation of the steps followed 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  T h e d a t a for this study w a s collected from interviews with b u s i n e s s a n a l y s t s w h o w e r e working o n actual C R M implementations in their respective institutions. T h e criteria for their selection included: •  Familiarization with their institution's organizational structure a n d C R M systems.  •  E m p l o y e d in the target institutions;  •  Interested in participating a n d available for interviews required in the study  Collecting information from C R M b u s i n e s s analysts p o s e d two primary c h a l l e n g e s . T h e first c h a l l e n g e is that b u s i n e s s a n a l y s t s working o n large projects are generally under intense time constraints, w h i c h m e a n s that the time available to a n interviewer is limited. S e c o n d l y they are very familiar with building C R M applications with current technologies, however, m a n y are not familiar with object oriented c o n c e p t s a n d ideas.  3. Pre-interview material distributed Prior to the interviews, a brief overview of the r e s e a r c h w a s sent to the interview subjects. T h e p u r p o s e of this material w a s to introduce the subjects to the type a n d nature of i s s u e s the study w a s interested in a d d r e s s i n g . T o p r e p a r e the subjects for the l a n g u a g e a n d nomenclature of the interview a n d to provide a template w h i c h w o u l d s e r v e to structure the initial s t a g e s of the interview a n d a checklist s o that pertinent i s s u e s w e r e not omitted. T h e main point to get a c r o s s in the pre-interview material w a s to c o n v e y that the study w a s mostly interested in the different t y p e s of u s e r s that interacted with the s y s t e m a n d what type of interactions they h a d with the s y s t e m .  4. P e r f o r m e d interviews T h e interviews w e r e performed over the p h o n e in 30-minute interview p e r i o d s . O n a v e r a g e e a c h analyst w a s interviewed three times. In all c a s e s the a n a l y s t s u s e d what they c a l l e d security groups a s the guide of the different t y p e s of u s e r s they h a d interacting with the s y s t e m . S i n c e security is a n important part of a n y  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 a n d r e s p o n s e s of the individual b u s i n e s s objects o n c e they u n d e r s t o o d the O O E M terminology in context of the b u s i n e s s p r o c e s s e s they w e r e familiar with.  5. A n a l y s i s of d a t a F r o m the d a t a collected in the interviews a list of external b u s i n e s s object c a n d i d a t e s w a s c r e a t e d , a n d the types of requests t h e s e external object c a n d i d a t e s m a d e into the s y s t e m w a s g e n e r a t e d .  T h e external object  c a n d i d a t e s w e r e then tested to s e e if they w e r e indeed external to the s y s t e m or not u s i n g O O E M theory.  6. G e n e r a l i z a t i o n s to target m o d e l s 1.  With the data, ideal b u s i n e s s m o d e l s were c r e a t e d using O O E M .  2.  T h e two b u s i n e s s m o d e l s w e r e c o m p a r e d a n d it w a s s h o w n that they w e r e very similar.  3.  T h e ideal b u s i n e s s m o d e l s w e r e then linked to the known g o o d s y s t e m using the linking technique.  7. C o n c l u s i o n s C o n c l u s i o n s w e r e then drawn b a s e d on how well the ideal b u s i n e s s m o d e l s c o u l d b e linked to the known g o o d C R M s y s t e m .  22  3.2 Modeling the C R M Requirements of a Rural B a n k  T h e rural bank w h o s e C R M n e e d s were m o d e l e d for this r e s e a r c h is a wholly o w n e d subsidiary of a larger b a n k that operates a u t o n o m o u s l y from the parent c o m p a n y . T h e rural b a n k is a full service financial institution that offers a c o m p l e t e range of products targeted at b u s i n e s s e s involved in all a s p e c t s of agriculture. T h e largest proportion of their c u s t o m e r s are farmers, however, they a l s o cater to b u s i n e s s e s that raise cattle a n d individuals w h o work for b u s i n e s s e s in the agriculture industry.  T h e range of products offered fall into three main c a t e g o r i e s , l o a n s , l e a s e s a n d i n s u r a n c e . If y o u n e e d to buy hail insurance, l e a s e farm equipment, or n e e d a loan to finance the p u r c h a s e of cattle, y o u could turn to this bank.  T h e rural bank d e c i d e d to invest in C R M to provide a unified interface by w h i c h a c c o u n t m a n a g e r s c o u l d c r e a t e a n d track opportunities a c r o s s the entire product line. At the time this r e s e a r c h w a s d o n e , in M a y a n d J u n e 2 0 0 2 the b a n k w a s using three s e p a r a t e interfaces to a c c e s s the s y s t e m s for l o a n s , l e a s e s , a n d i n s u r a n c e . T h e rural b a n k w a s a l s o looking for s e r v i c e functionality to be able to track a n d r e s p o n d to c o m p l a i n t s . Finally, the rural bank n e e d e d a tool that w o u l d allow them to create c u s t o m e r a n d organization profiles to allow better targeting of product offers.  T h e two b u s i n e s s a n a l y s t s , w h o w o r k e d with the rural b a n k to help define the C R M s y s t e m , a s well a s future u s e r s of the s y s t e m , w e r e interviewed to collect information for this r e s e a r c h paper. R e f e r to A p p e n d i x D for a n overview of the method u s e d to interview the b u s i n e s s analysts.  T h e six-step methodology, d e s c r i b e d on the following p a g e s , that w a s u s e d to d e v e l o p the b u s i n e s s m o d e l is the object-oriented b u s i n e s s modeling ( O O B M )  23  a p p r o a c h d e s c r i b e d by Y a i r W a n d , C a r s o n W o o a n d S a m s o n Hui in " D e v e l o p i n g B u s i n e s s M o d e l s to S u p p o r t Information S y s t e m Evolution".  T h e six-step O O B M p r o c e s s u s e d is a request driven a p p r o a c h that is b a s e d o n the requests that are m a d e from external objects into the s y s t e m in question a s well a s the requests that are m a d e within the s y s t e m a s a result of external requests.  S e r v i c e s to satisfy the requests are defined, g r o u p e d together a n d  then a s s i g n e d to objects.  O v e r l a p s are then eliminated a n d a final m o d e l is  p r e s e n t e d (16).  24  3.3 Step 1: Rural Bank B u s i n e s s 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.  Object  Doscription  Ruqurud  One of two is required  Behaves Independently  H.'JS a Direct Impact  Provides  on Model  Required Service not in Model  Customer  Controller  Company or  Customer is independent  individual  from system being  associated with  modeled as the CRM  the agriculture  system is designed to  business  serve them.  Customer initiated transactions are what the system is  No  designed to address.  Monitors system  Yes,  performance and  performance  provides feedback  Yes, controller is the  Yes, input from the  external entity that  controller determines  defines how the system  the prioritization of  should perform.  transactions.  monitoring is required to ensure that the system is achieving the goals defined for the system.  Dealer  Supplier  Provides another Dealers are independent Dealer initiated sales channel for from system being  transactions are what  certain products  modeled as the CRM  a portion of the  system has functionality  system is designed to  designed to serve them.  address.  Provides market Suppliers provide  Yes, Information  No  Yes, market  data for the  information that  system  generated independently is used in calculations by supplier is of the system.  provided by suppliers data provided by the system  required  26  Part C: Define the requests m a d e by the external objects into the R u r a l B a n k ' s C R M s y s t e m . This table lists all the external requests m a d e into the C R M s y s t e m a s defined by the b u s i n e s s analysts a n d users interviewed.  T a b l e 2 . External requests to the R u r a l B a n k C R M S y s t e m 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 A g g r e g a t i n g s e r v i c e s into s e r v i c e types. In step two the s e r v i c e s n e c e s s a r y to satisfy the external requests of the R u r a l B a n k ' s C R M S y s t e m a r e defined a n d a g g r e g a t e d . S e r v i c e s a r e a g g r e g a t e d together if they h a v e a similarity in state transformation, similarity in internal transformations, or a similarity in the r e s o u r c e s they u s e . In T a b l e 3 , the s e r v i c e s required to satisfy the requests listed in T a b l e 2 a r e listed.  A s c a n be s e e n in table 3 the only a g g r e g a t i o n of  s e r v i c e s is a c h i e v e d by the C u s t o m e r M a n a g e m e n t service that a g g r e g a t e s requests 2,4,5 a n d 8 from T a b l e 2 .  27  T a b l e 3. A g g r e g a t i o n of s e r v i c e s for the Rural B a n k C R M S y s t e m  One of threp is  Service Type Similarity in state trans- Similarity in formation  Similarity in  Requests # from  internal trans-  resources used for Table 2 that  formations  internal trans-  Require thp ''.crvicf  1  formations Execute  Performs actions on  Account  Account variables  1  Transactions Customer  Performs actions based  2, 4, 5, 8,  Management on the customer profile variables Activity  Creates, deletes,  Management  and assigns  6  activities. Product  Displays Product  Management  information  Service  Manages Service  Management  workflow  7  3  3.5 Step 3: Objectifying the Rural Bank's Services In this step, w e create objects that a r e responsible for delivering e a c h type of s e r v i c e . T h e s e objects d o not represent the s e r v i c e s t h e m s e l v e s , but rather represent a collection of s e r v i c e s that h a v e a similarity in the transformations they perform, a similarity in the entities o n which they perform transformations, or finally the r e s o u r c e s they require to perform their transformations.  28  T a b l e 4: Objects created to handle the s e r v i c e types for the Rural B a n k C R M system. Object  Service Type  Account  E x e c u t e L o a n , L e a s e , Insurance T r a n s a c t i o n s Return Status  C u s t o m e r Mgmt  Customer Analysis  Activity  Activity M a n a g e m e n t  Service  Service Management  Product  Product M a n a g e m e n t  Object Descriptions: Account: T h e account object h a n d l e s all requests that h a v e a n effect on a c c o u n t s . T h i s object is a l s o the object that would be part of the " b a c k - e n d " integration to the s y s t e m s of record within the financial institutions.  It b e c o m e s a n object d u e to  the entities, back e n d s y s t e m integration m o d u l e s , on w h i c h it performs transformations. C u s t o m e r Mgmt: T h i s object stores all the profile information about c u s t o m e r s , a n d is a n object b e c a u s e it collects all s e r v i c e s that a c c e s s the r e s o u r c e s a s s o c i a t e d with customers. Activity: T h e activity object h a n d l e s all the requests related to activity m a n a g e m e n t , s u c h a s creating meetings or recording call details. Activity b e c o m e s a n object b e c a u s e the transformations that the s e r v i c e s perform to s c h e d u l e all types of activities are similar in nature. Service: T h e service object h a n d l e s all post-sale requests from c u s t o m e r s , which are similar in the resources they require. Product:  29  T h e product object stores all product information a n d h a n d l e s any information update requests related to products. Product b e c o m e s a n object s i n c e all the s e r v i c e s that are related to product require a c c e s s to similar r e s o u r c e s .  3.6 Step 4: Assignment of requests from the Rural Bank's business model to objects In this step, requests are a s s i g n e d to objects b a s e d o n the state information they require or the state transformations the request c a u s e s . T a b l e 5: A s s i g n i n g requests to O b j e c t s from the Rural B a n k C R M S y s t e m Roquest Iypo  S.nto Infn  Resulting SUto Objuut Irom  Required  Transformation Table 4 Responsible tor Statu  Request  Information  # from  External  Table 2  Object  Delivery or Request  Customer Account Transaction  Transformation Account  Modifies  Related  Deposit  1  Accounts Customer Apply for loan pre-approval  Customer  Checks  Customer  Analysis  Customer  Mgmt  2  Profile Customer Complaint \  Service  Modifies  Feedback  Request Customer Best offer  Product  Returns  Related  Product  4  Product  Details Controller Performance  5  Reports  6 Dealer  Customer  Customer  Customer  Analysis  Profile  Mgmt  Activity  Modify  activities  Management  Activities  Product  Product  Returns  Information  Related  Product  Controller Assign  7  Activity Product  Details Dealer  Apply for loan  Customer  Customer  Customer  pre-approval  Analysis  Profile  Mgmt  Market Data  Return  Account  Supplier Market Feed  9  Service  Service  3  8  Account  Market Info  31  3.7 Step 5: Identify Internal Object Interactions in the Rural Bank's Business Model In this step interactions that result b e t w e e n objects a s a result of external requests a r e d o c u m e n t e d . T a b l e 6 s h o w s all external requests that precipitate a n internal request. T h e "Object R e s p o n s i b l e " c o l u m n s s h o w s the object that a c c e p t s the external request, a n d the c o l u m n titled " S e r v i c e H a n d l e d by Object" s h o w s the object that a l s o participates a s a result of a n internal request.  Internal  interactions w e r e identified by looking for objects that a c c e p t e d a n external request but w e r e not able to satisfy the initial request without the participation of another object.  T a b l e 6: Identifying internal interactions of the Rural B a n k C R M S y s t e m  Inter-  Object  action Request External  Responsible  Objoi.t  Request  Customer Account a  Account  Transaction  1  Customer Apply for loan Cust Mgmt b  c  2  3  Customer  Complaint \ Feedback Best offer  6  handled by  Interaction  object  Service  Customer  Customer  Customer  Data  Mgmt  Analysis  Product Info Product  activities  Product Detail  Modifies Service  Service  Service  Request Product  Customer  Customer  Customer  Data  Mgmt  Analysis  Activity  Modify  Activity  Management  Activities  4  Controller Assign e  Internal  pre-approval  Customer d  Service  32  3.8 Step 6: Verify integrity of data objects of the Rural Bank's business model In this section w e verify if n e w objects n e e d to b e c r e a t e d or if existing objects n e e d to b e r e m o v e d d e p e n d i n g if there is overlap b e t w e e n the s e r v i c e s offered by two objects or if a n e w object n e e d s to b e c r e a t e d to perform the service for both of t h e m . B y referring to T a b l e 5 w e s e e that there a r e no o v e r l a p s a n d , n o n e w objects a r e required to perform the s e r v i c e of two objects, therefore, n o c h a n g e s to the objects a r e required.  3.9 OOEM of the Rural Bank business model T h i s drawing s h o w s the interactions b e t w e e n the external objects of the Rural B a n k ' s b u s i n e s s m o d e l with the internal objects. R e f e r to T a b l e 5 for descriptions of e a c h of the requests that a r e identified by the n u m b e r that a p p e a r s c l o s e to the line linking the external object a n d internal object. T h i s m o d e l a l s o s h o w s the internal requests that o c c u r a s a result of a n external request. R e f e r to T a b l e 6 for descriptions of the internal requests.  1 Account Transactions  Account Account Requests [Transaction Info]  9 -Market Feed  Supplier  Account Transactions a. Customer Data 2 -Apply for Loan  Customer Mgmt Loan Requests [Customer Info]  8. Loan Pre-Approval b. Prod. Info.  Dealer  Customer Transactions  customer d.Cust. data 4, Product Search  Product Product Requests Product Trans actions  7. Product Search 5. Performance Reports  Activity e . Activity Info  Activity Requests  6. Create Activity  Activity Transactions c. Service Info\ 3. Register Complaint  Service •Service Requests  Controller  Service Transactions  Figure 2 - O O E M of the Rural Bank business model  33  3.10 Modeling the CRM Requirements of a Private Banking Institution  T h e s e c o n d C R M s y s t e m that w a s m o d e l e d for this r e s e a r c h d e s c r i b e s the n e e d s of a private b a n k i n g institution that caters to wealthy individuals w h o require sophisticated financial s e r v i c e s s u c h a s portfolio m a n a g e m e n t , financial planning, wealth m a n a g e m e n t a n d various i n s u r a n c e offerings.  A key a s p e c t of  s u c c e s s f u l private b a n k s is the ability of the p e r s o n a l b a n k e r s to provide a very high level of service for their clients making C R M t e c h n o l o g y very v a l u a b l e to them.  T h e main drivers for the private b a n k to adopt a C R M s y s t e m w e r e to provide a unified interface for p e r s o n a l b a n k e r s to a c c e s s information from disparate b a c k e n d s y s t e m s a s well a s activity m a n a g e m e n t capabilities to allow p e r s o n a l b a n k e r s to monitor a n d track all their activities with clients. Other features that the private b a n k w a s looking for w e r e opportunity tracking a n d c u s t o m e r rating b a s e d o n profiles.  T h e b u s i n e s s analyst w h o w a s working o n the d e s i g n for the private b a n k ' s C R M s y s t e m , a s well a s eventual users of the s y s t e m , w e r e interviewed to collect information for this r e s e a r c h p a p e r in M a y a n d J u n e of 2 0 0 2 .  T h e six-step methodology, d e s c r i b e d on the following p a g e s , that w a s u s e d to d e v e l o p the b u s i n e s s m o d e l is the W a n d , W o o , Hui enterprise object oriented modeling a p p r o a c h d e s c r i b e d in " D e v e l o p i n g B u s i n e s s M o d e l s to Support Information S y s t e m Evolution".  R e f e r to A p p e n d i x A for details of the six-step O O B M p r o c e s s for the Private Bank.  34  3.11 External Requests of the Private Bank business model T h i s drawing s h o w s the interactions b e t w e e n the external objects of the Private B a n k ' s b u s i n e s s m o d e l with the internal objects. R e f e r to T a b l e B in A p p e n d i x A for descriptions of e a c h of the requests that are identified by the n u m b e r that a p p e a r s c l o s e to the line linking the external object a n d internal object. T h i s m o d e l a l s o s h o w s the internal requests that o c c u r a s a result of a n external request. R e f e r to T a b l e F in A p p e n d i x A for descriptions of the internal requests.  Account 1 Jiccount Transactions  9 Market Feed  Supplier  Account Requests [Transaction Info] Account Transactions a. Customer Data  Customer Mgmt 2 J!pply for Loan  Loan Requests [Customer Info]  customer  b. Prod. Info.  Customer Transactions  Product d.Cust. data 4&7. Product Search  Product Requests Product Transactions 5. Performance Reports  Activity e. Activity Info  Activity Requests  6. Create Activity  Activity Transactions c. Service Info 3. Register Complaint  Service Service Requests  Controller  Service Transactions  Figure 3 - - O O E M of the Private Bank business model  35  3.12 Summary of Research in Chapter 3  In this chapter w e d e v e l o p e d b u s i n e s s m o d e l s for a rural bank a s well a s a private b a n k b a s e d o n the requests m a d e into the s y s t e m from external objects. V i e w i n g T a b l e s 7 a n d 8 for the rural b a n k a n d T a b l e s B a n d F from A p p e n d i x A for the private b a n k allows us to c o m p a r e the b u s i n e s s m o d e l s a n d r e c o g n i z e that the two m o d e l s a r e very similar.  T h e only real difference b e t w e e n the two  m o d e l s is that that the Rural B a n k h a s o n e extra external objects - the D e a l e r object. T h i s extra external object is able to leverage the s a m e objects a n d s e r v i c e s that a r e required for the private banking b u s i n e s s m o d e l , h o w e v e r , which reinforces the fact that these m o d e l s a r e very similar. T h e c o n c l u s i o n that c a n be d r a w n from this a n a l y s i s is that the two b a n k s have very similar requirements a n d that it is likely that a single vertical template c o u l d likely b e d e v e l o p e d that w o u l d b e useful to both institutions.  36  Chapter IV - Constructing Data and Dynamic Objects from an Existing CRM System  T h i s chapter will d e s c r i b e the p r o c e s s of constructing d a t a a n d d y n a m i c objects, a s defined by W a n d , W o o a n d Hui in "Linking Information S y s t e m s Architecture to the B u s i n e s s M o d e l " (11), from a n existing information s y s t e m . D a t a objects represent the d a t a in tables a s s o c i a t e d with major or strong entities.  Dynamic  objects represent the e n c a p s u l a t i o n of application objects a n d m o d u l e s that a c c e s s t h e s e d a t a tables directly. T h e existing information s y s t e m that will be u s e d is a C R M template that w a s d e s i g n e d by a C R M v e n d o r to a d d r e s s the n e e d s of C o m m e r c i a l L e n d e r s .  4.1 The Vertical Financial Services Template A t e a m of 8 p e o p l e including d e v e l o p e r s , b u s i n e s s analysts a n d industry experts d e v e l o p e d the vertical financial s e r v i c e s template that w a s u s e d in this study to explore the linkage a p p r o a c h p r e s e n t e d by W a n d , W o o a n d Hui in "Linking Information S y s t e m s Architecture to the B u s i n e s s M o d e l " (11).  T h e template  w a s d e s i g n e d to meet the n e e d s of c o m m e r c i a l lenders inside a full s e r v i c e bank.  T h e c h a l l e n g e s that the template w a s d e s i g n e d to a d d r e s s w e r e the following:  C o m m e r c i a l lenders have poor tools to support customer-centric s a l e s & s e r v i c e strategies. M u c h of the c o m m e r c i a l lending s a l e s f o r c e s d o not h a v e the integrated technology n e e d e d to support strategic selling activities. T h e r e are usually a variety of non-integrated s y s t e m s in p l a c e to m a n a g e c u s t o m e r c o n t a c t s , s a l e s reporting a n d c a m p a i g n e x e c u t i o n . T h i s collection of s y s t e m s provides a fragmented a p p r o a c h to c u s t o m e r interaction s i n c e they are generally c o m p r i s e d of linked s p r e a d s h e e t s or stand-alone applications a c c e s s i n g s t a n d a l o n e d a t a b a s e — o f t e n with duplicate data. Before C R M s y s t e m s are in p l a c e , for e x a m p l e , c o m m e r c i a l lenders are often having their assistants s c a n up to 8  37  different s y s t e m s that e a c h contain a s e p a r a t e p i e c e of important information required for a s a l e s call s u c h a s contact information, product p u r c h a s e history, a n d the b a l a n c e s of a c c o u n t s that are e a c h in their o w n s y s t e m .  A n inability to retain corporate m e m o r y . T h e corporate lending s i d e of m a n y b a n k s is the most profitable a n d highest dollar of a n y other divisions. S t r a n g e a s it m a y s e e m it is a l s o typically the least a u t o m a t e d . L e n d e r s in this a r e a are typically higher paid specially trained a n d e x p e r i e n c e d individuals. Without C R M automation w h e n a corporate lender left the b a n k to g o to a competitor s o went any corporate k n o w l e d g e of the A c c o u n t . S o m e t i m e s this included m a n y y e a r s of calling o n the a c c o u n t . A n e w lender w o u l d h a v e to start from s c r a t c h with no contacts a n d no k n o w l e d g e of the account.  T h e following p a g e s will d e s c r i b e the s t e p s taken a s d e s c r i b e d in "Linking Information S y s t e m s Architecture to the B u s i n e s s M o d e l " by W a n d , W o o a n d H u i , to construct data objects from a n existing IT s y s t e m .  38  4.2 E R D for Financial Services C R M Template T h e following E R D is t a k e n from the d a t a m o d e l of the financial s e r v i c e s C R M template. All c o n n e c t i o n s in the m o d e l are "one-to-many" with the e n d of the line with the s m a l l circle representing the "many" e n d of the c o n n e c t i o n .  Opportunity _ P r o d _F_D.es Opportunity Opportunity  Product  P r o d Fe_unes Id  Product  Product,  Opportunity ODDortunitv  Feature Feature Id  Product Id:  Product  Product  Product Id* H  <  Opportuniry_Jd  Product Id Opportunity  Product Id  Opporturiy Opportunity id Company_kJ Contact Id  1  Corrtact  Comp <y  Contact Id  C o m p a n y Id  -  A±vty  -CM Activity  ID  Contact ~ ~ Company Id  Connection Connection  -0*=l  Id*  Service_Request Service  Focal_Comparry_fcl Connected_Corrpaniy_ld Focal_Contact_ld Connected Contact Id:  Request Id  Contact ~ T " Company Id _  Account A c c o u n t Id Contact HET" Company Id Account  Work Work  Features:  A c c o u n t Features Id A^count Id  A;count_Ho_Tg  o4  A c c o u n t Holding Id  Service  Order Order ID Request ID  Account Id  Figure 4 - E R D for Financial Services C R M Template  39  4.3 Step 1 - Identification of all major or strong entities from the database. Strong entities are identified by referring to the d a t a m o d e l of the s y s t e m b e i n g modeled.  R e f e r to Figure 17, the E R D of the financial s e r v i c e s C R M template.  From  Figure 17 the following strong entities are identified: 1. C o n t a c t 2.  Company  3.  Product  4.  Account  5.  Opportunity  6.  Activity  7. S e r v i c e R e q u e s t  4.4 Step 2 - Determine if a child table is a candidate for a data object. In this step w e c h e c k to s e e if any child tables are c a n d i d a t e s for being d a t a objects if they are a c c e s s e d directly by other applications. C h i l d tables are tables that would be m e a n i n g l e s s without the table to w h i c h they are a s s o c i a t e d through a foreign key. F o r instance, if the a d d r e s s of a c u s t o m e r is stored in a s e p a r a t e table from the c u s t o m e r , the a d d r e s s table would be a child table of the c u s t o m e r table. T a b l e 7: Accessed Strong Entity  Child Tables  Directly?  Opportunity  Yes  Product  Yes  Connection  No  Account  Yes  Contact  40  Activity  Yes  Service_Request  Yes  Opportunity  Yes  Product  Yes  Connection  No  Account  Yes  Activity  Yes  Service_Request  Yes  Product Feature  No  Account Features  No  Account Holding  No  Opportunity_Product  No  Company  Product  Account  Opportunity  Opportunity_Product_features No Activity Service Request Work_Order  No  Product, Account, Opportunity, Activity and Service Request qualify as strong entities along with their child tables.  4.5 Step 3 - Assignment of 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.  41  Table 8: Strong Entity  Assigned Relationship Tables  Contact Contact Connection Company Company Connection Product Product Product Feature Account Account Account Features Account Holding Opportunity Opportunity Opportunity_Product Opportunity_Product_features Activity Activity Service Request Service Request Work_Order  4.6 Step 4: Constructing Dynamic Objects: R e f e r to the table in A p p e n d i x E for details o n how d y n a m i c objects are then c r e a t e d b a s e d o n the relationship tables a n d the application object m o d u l e s . F o r e a c h d y n a m i c object, the a s s i g n e d relationship tables are listed a l o n g with application objects a s s o c i a t e d with e a c h relationship table. T h e d y n a m i c object t h e n inherits all the functionality a s s o c i a t e d with all the application objects that fall under its a s s o c i a t e d relationship tables.  43  4.7 Data and Dynamic Objects for the Financial Services Template  els Company  els Contact  clsProduct X c l s P r n r f m 1. Fi ttturv  clsConnection  DynaContact . clsConlact .Add dsGoxiiaci .Modify clsContajct .Remove clsContact .Status clsConnection. Add ckConraction.Modify cbCorm«ction.R*mov« cbCotuMction Stttu*  Contact  Connection  DynaC omp any clsCojmpany.Add  cls<3ompany. Modify clsCompaMy.ftemov-e  clsCompwy Status cliCojtwection.Add cfeConnectkm Modify cl*Ce>*uw«t«tk>tt ,R®mov® cl».Coturutction.St*tvi5  c  Company  Connection  D.ynaProduct <rlsPjrod_Add : dsProd-Modify els Prod Re «TO ve C lsP«3dSt*tUS; . ;  :  cl*PJrod_Feat Add ci»ProdJF«*t .Modify •cl*P«od_F«a,t ,R«wvov«cbPxod_F«*t St*tu*  Product Product 'Feat  Figure 5a - Data and Dynamic Objects for the Financial Services Template Solid lines represent connections between classes, objects and tables, dashed lines represent tables that share data.  44  4 . 7 cont. Data and Dynamic Objects for the Financial Services Template continued:  c  CIJALLUUH:  clsOppoitunity  clsAcuvity  X  clsAccount Feature  els Opp ortumty_Pr o d  clsAc c ount _Ho Id in g  c!sOpp_Procl_Feat  els S ervic e_Requ est X clsWork Order  DynaOpportunity els Acc.Add clsAcc .Modify r clsAcc Remove elsAcc.Status: cl»Acc_Feat,Add cl* Acc_Feat ;Modiiy clsAcc_Fe*t .R*mov« cl»Acc_F«*t Statu* cUAcc_Holdms.Add cbAcc_Holding.Mod cl*Acc_Holdiitg. Rem clsAcc_Holding. Status  clsOpp.Add clsOpp Mod clsOpp Remove clsOpp;Stahi*: el*Opp_P»d;Add cl*Opp_P»d.Mod: cUOpp_P»d.R»m cbOppJPiod.Stat cbOpp _P»d_F*at .Add «J»Opp_P»d JFeat.Mod cbOpp_Piod_Fe4t Rem clsOpp_Prod_Feat .Stat  Account  Opportunity  clsActivrtyAdd elsActivT.ty;Modiiy els Activity.Remov« clsActivtfy.Stahw  ^ V ^ w r k _ P » i d 8 r Statu*  ;  Activity  QppJProd  Account Feat  cBSexviceJteqVA&& clsSejri_e_;Rfiq*;Mo djjfy cIsSeryrce^Re Remove  Serace_Request  Work Order  c:  AccHolding  OppProdFeat C  Figure 5b - Data and Dynamic Objects for the Financial Services Template Solid lines represent connections between classes, objects and tables.  45  4.8 Relationships between Dynamic Objects and Application Objects _A.p_»licixtioil O b j e c t s ; clsContact clsOoixixectioxx clsCoinpaiiy e l s <3_>p oi'txxixit y els Opp_JProcl cIsOpp  F iocl_F"efitxiie >  clsPioclxxct 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 clsAccoimt^_Holdiiigs els A c t i v i ty e l s Sex-vice_JR.e<_xiest clsWork  Order  I  Figure 6 - Relationships between Dynamic Objects and Application Objects T h i s figure w a s generated by listing all A p p l i c a t i o n Objects a n d c o n n e c t i n g t h e m to the D y n a m i c Object(s) with which it m a y interact.  4.9 Summary of research described in Chapter 4 In this chapter a n existing C R M s y s t e m w a s a n a l y z e d a n d D y n a m i c D a t a objects w e r e c r e a t e d a n d application functionality w a s a s s i g n e d to t h e s e d a t a objects. H a v i n g n o w c r e a t e d the b u s i n e s s m o d e l s for the Rural B a n k a n d the Private B a n k a n d having created D y n a m i c D a t a O b j e c t s for it is p o s s i b l e to link t h e m o d e l s for the R u r a l a n d Private b a n k s to the D y n a m i c D a t a O b j e c t s of the financial s e r v i c e s template this will b e d e s c r i b e d in C h a p t e r 5.  46  Chapter V - Linking the Ideal Business Models to the Existing CRM System In this section w e will verify if the ideal b u s i n e s s m o d e l s d e v e l o p e d for the Rural B a n k a n d the Private B a n k c a n be linked to the financial s e r v i c e s template.  In  effect w e are trying to s e e if the financial s e r v i c e s template would be a g o o d b a s e C R M s y s t e m for the rural a n d private b a n k s . T o test if the ideal b u s i n e s s m o d e l s c a n be linked to the financial s e r v i c e s template the c o n c e p t of static a n d delegate objects for the b u s i n e s s m o d e l s will be introduced. Static objects are objects w h o s e status w e n e e d to know, like a c u s t o m e r ' s for instance, but that have no responsibility in running the s y s t e m . D e l e g a t e objects, o n the other h a n d , are r e s p o n s i b l e for performing information p r o c e s s i n g activities s u c h a s the a c c o u n t object that records transactions. If the static a n d d e l e g a t e objects from the rural a n d private b a n k s match up with the d a t a a n d d y n a m i c objects of the financial s e r v i c e s template then w e c a n c o n c l u d e that the financial s e r v i c e s template would be a g o o d fit a s a C R M solution for the two b a n k s .  T o link a n actual implementation to a b u s i n e s s m o d e l it is n e c e s s a r y to be a b l e to identify in the b u s i n e s s m o d e l the activities that c a n be c o m p u t e r i s e d . W a n d , W o o a n d Hui p r o p o s e to d o this using the notion of delegate a n d static objects (13).  D e l e g a t e objects represent objects that are responsible for performing information p r o c e s s i n g activities, static objects, represent objects w h o s e state w e n e e d to know, but d o not h a v e any responsibilities related to running the s y s t e m being m o d e l e d .  5.1 Identifying Static and Delegate Objects for the Rural Bank Static O b j e c t s for the Rural B a n k : (Objects w h o s e state w e n e e d to know but do not have a n y responsibilities running the s y s t e m 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  F i g u r e 7 - L i n k i n g Static Objects f r o m the R u r a l B a n k to the F i n a n c i a l Services C R M Template  48  5 . 3 Linking Dynamic Objects from the Private Bank to the Financial Services CRM Template  Figure 9 s h o w s that the delegate objects from the Rural B a n k B u s i n e s s m o d e l c a n be linked in a logical m a n n e r to the d y n a m i c objects of the financial s e r v i c e s template a n d have similar service 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 Static Objects for the Rural B a n k :  Supplier, C u s t o m e r , P e r s o n a l B a n k e r , Supervisor,  D e l e g a t e Objects for the Rural B a n k : A c c o u n t , S e r v i c e , C u s t o m e r Mgmt, Activity, Product  49  5.5 Linking Static Objects from the Private Bank to the Financial Services CRM Template Figure 10 s h o w s that the d a t a objects from the financial s e r v i c e s template a r e able to a c c o m m o d a t e the static objects from the Private B a n k ' s b u s i n e s s m o d e l . Data Tables Static O b j e c t s  Data Objects  Company Connection Opportunity Opp_Prod O p p _ P i od_F e atuie Product Product  Account  Feature  Features  A c c o i m t H o l d i i igs Activity S e r v i c e R e q u e st Work  Order  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 s h o w s that the delegate objects from the Private B a n k ' s B u s i n e s s m o d e l c a n b e linked in a logical m a n n e r to the d y n a m i c objects of the financial s e r v i c e s 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 w e c o m p a r e figures 8 a n d 9 to figures 10 a n d 11 w e s e e that the linkage for the R u r a l B a n k a n d Private B a n k s are very similar.  T h e only significant difference  a p p e a r s in Figures 8 a n d 10 w h e r e the static objects a r e being linked to the d a t a tables of the financial s e r v i c e s C R M template.  H e r e w e notice that the d e s i g n of  the C R M template easily a c c o m m o d a t e s both b u s i n e s s m o d e l s by treating all of the static objects a s either C o n t a c t s or C o m p a n i e s . If the d e s i g n of the template did not have g e n e r a l i s e d objects that could handle a n y type of individual or  51  organization, the ideal b u s i n e s s m o d e l s from the rural a n d private b a n k s w o u l d not be s o e a s i l y linked. In fact if s p e c i a l i s e d objects were c r e a t e d for e a c h type of individual or organization, the financial s e r v i c e s template w o u l d n e e d to be modified substantially for e a c h implementation.  T h e linkage for the delegate objects of the rural a n d private b a n k s is identical a n d is well s u p p o r t e d by the D y n a m i c Objects of the F i n a n c i a l S e r v i c e s C R M template with o n e to o n e m a p p i n g s of all objects except for the c u s t o m e r m a n a g e m e n t D e l e g a t e Object which n e e d s to be a b l e to a c c e s s all the D e l e g a t e O b j e c t s to satisfy its reporting requests.  Finally, the c o m p l e t e d m o d e l s were p r e s e n t e d to the b u s i n e s s analysts w h o w e r e interviewed for this paper. Although s o m e of the details of the a p p r o a c h u s e d to d e v e l o p the m o d e l s w e r e not fully e x p l a i n e d to the analysts, the resulting m o d e l w a s quickly u n d e r s t o o d by the analysts a n d , the benefits of having s u c h a n object oriented m o d e l to guide C R M implementations in specific vertical industries w a s r e c o g n i z e d a s v a l u a b l e for d e c r e a s i n g implementation times o n future C R M implementations.  52  Chapter VI - Conclusion  A s software products travel through their product lifecycles software v e n d o r s must constantly adjust their strategies to k e e p in line with the current market climate. C R M software is entering a p h a s e in its lifecycle w h e r e market d e m a n d is driving C R M v e n d o r s to offer solutions that are more closely a l i g n e d with the specific n e e d s of organizations. Offering solutions that are tailored to s p e c i f i c market s e g m e n t s is o n e way of aligning software functionality m o r e c l o s e l y with the n e e d s of a n organization.  In this p a p e r w e h a v e demonstrated that using a role a n d interaction m o d e l i n g a p p r o a c h e s is a useful method of defining vertical C R M solutions. T h e O O B M t e c h n i q u e p r o p o s e d by W a n d , W o o a n d Hui (16) w a s u s e d to c r e a t e ideal b u s i n e s s m o d e l s for two b a n k s . T h e linkage m e t h o d p r o p o s e d by W a n d , W o o a n d Hui (11) w a s then u s e d to generate a n object b a s e d view of the capabilities of a n existing financial s e r v i c e s vertical C R M template.  The business models  w e r e then s u c c e s s f u l l y linked to the existing vertical financial s e r v i c e s C R M solution a n d verified by b u s i n e s s analysts w h o d e s i g n C R M s y s t e m s . T h i s d e m o n s t r a t e s that requirements from a target market c a n be gathered a n d tested against a c a n d i d a t e s y s t e m to verify if the c a n d i d a t e s y s t e m is a g o o d m a t c h for the functionality required.  6.1 Creating the Ideal Business Models T h e fact that the b u s i n e s s m o d e l s created for the rural bank a n d private b a n k w e r e very similar indicates that the financial s e r v i c e s industry is, from a technical standpoint at least, a g o o d candidate for a vertical solution. If the r e s e a r c h of the two financial institutions h a d resulted in greatly divergent b u s i n e s s m o d e l s then it is unlikely that a single vertical template c o u l d be d e v e l o p e d that w o u l d be a g o o d starting point for both organizations.  53  T h e other interesting a s p e c t that w a s learned from using the O O B M technique for creating a b u s i n e s s m o d e l is that collecting the d a t a required to form the b u s i n e s s m o d e l w a s not difficult. B u s i n e s s analysts a n d b u s i n e s s u s e r s c a n easily define the specific roles that will be interacting with the s y s t e m a s well a s the requests that they feel the different users a n d s y s t e m s will be m a k i n g of the p l a n n e d s y s t e m . In effect, by having them define the requests that the s y s t e m must support they are a b l e to clearly articulate their i d e a s of what the s y s t e m n e e d s to d o without being b u r d e n e d with technical details. T h i s is particularly v a l u a b l e b e c a u s e it e n s u r e s that the model that is c r e a t e d truly reflects the n e e d s of a n organization s i n c e it is the actual users of the s y s t e m that h a v e defined it.  6.2 C o n s t r u c t i n g Data Objects from Existing IT T h e a p p r o a c h d e s c r i b e d by W a n d , W o o a n d Hui to construct d a t a objects from existing IT resulted in d a t a objects that aligned well with the ideal b u s i n e s s m o d e l s that w e r e created for the rural bank a n d the private bank, indicating that the C R M template d e s i g n e d by the C R M v e n d o r is well suited for the task it w a s d e s i g n e d for.  O n e a r e a w h e r e the r e s e a r c h h a s s h o w n that the C R M template  might h a v e a w e a k n e s s , however, is in the a r e a of reporting.  O n e of the key benefits of a C R M s y s t e m is that d a t a from front office functions is c o l l e c t e d m a k i n g it p o s s i b l e to m e a s u r e a n d report o n t h e m . T h e current financial s e r v i c e s template requires the c u s t o m e r m a n a g e m e n t d e l e g a t e object to query e a c h d y n a m i c object of the financial s e r v i c e s template in order to satisfy the requests that it supports.  A better a p p r o a c h m a y be to h a v e the reporting  functionality required by the c u s t o m e r m a n a g e m e n t d e l e g a t e object a b s o r b e d into the d y n a m i c objects for the contact a n d c o m p a n y .  T h i s would a d d s o m e  complexity a n d d e p e n d e n c i e s within the financial s e r v i c e s C R M template; h o w e v e r , it would m a k e the outward interface more modular with fewer interdependencies.  54  6.3 A r e a s for Future R e s e a r c h T h e object-oriented a p p r o a c h of creating b u s i n e s s m o d e l s a s well a s the objectoriented a p p r o a c h to constructing d a t a objects from existing IT s y s t e m s is a n effective method of determining market requirements for a vertical C R M solution a s well a s evaluating if a C R M template is appropriate to meet those n e e d s for a s p e c i f i c industry.  T h i s p a p e r d e m o n s t r a t e s a p r o c e s s to operationalize the  linkage p r o c e s s p r o p o s e d by W a n d , W o o a n d Hui. Future r e s e a r c h a r e a s c o u l d f o c u s o n a d v a n c i n g the t e c h n o l o g y u s e d to support vertical C R M strategies.  C e r t a i n industries require specific functionality outside of the standard s a l e s , marketing a n d service functionality generally a s s o c i a t e d with C R M .  In the  i n s u r a n c e industry, for i n s t a n c e , there is a requirement to be a b l e to create q u o t e s for c u s t o m e r s b a s e d o n historical risk data. S u c h a n i n s u r a n c e quoting m o d u l e w o u l d n e e d to be a b l e to extract profile information from the c u s t o m e r to c r e a t e the quote a n d it m a y a l s o n e e d to interact with the product m o d u l e to m a k e a r e c o m m e n d a t i o n o n the best product for the given c i r c u m s t a n c e s . D e v e l o p i n g the quoting m o d u l e for a vertical C R M solution for financial s e r v i c e s w o u l d be fairly straightforward.  T h e complication a r i s e s , however, if it is  n e c e s s a r y to be able to u s e the s a m e quoting m o d u l e in another vertical solution s u c h a s a solution targeting p h a r m a c e u t i c a l c o m p a n i e s . W h a t is the best w a y to build the quoting module s o that p h a r m a c i s t s selling drugs c a n a l s o offer i n s u r a n c e quotes to c u s t o m e r s ?  T o a n s w e r this question will require a  thorough understanding of the all the objects that the quoting m o d u l e w o u l d interact with a n d being s u r e that the interfaces a c r o s s the vertical solutions are common.  A variation on the s a m e p r o b l e m a r e a that requires more investigation is determining the optimal w a y to d e s i g n vertical applications to allow objects within the template to be substituted b a s e d on the specific implementation. F o r i n s t a n c e if w e c o n s i d e r a template to be d e s i g n e d for the manufacturing industry for instance, the product object a n d the s a l e s object will require significantly  55  different functionality b a s e d on the product that is being s o l d . F o r instance, a c o m p a n y that sells electrical fixtures will n e e d a product object that c a n h a n d l e m a n y parts with few features. A c o m p a n y that s e l l s fire trucks on the other h a n d w o u l d n e e d a product object that could handle few products that have a h u g e n u m b e r of configuration options. W h e n w e look at the s a l e s object for t h e s e two c o m p a n i e s they w o u l d differ greatly a s well. T h e electrical fixtures c o m p a n y w o u l d n e e d cataloguing functionality in the quoting m o d u l e of the s a l e s object while the fire truck manufacturer would have to be a b l e to offer c o m p l e x product configuration functionality in their quotes.  56  References ;1) E R P History, T u n c a y K a r a c a , April 19, 2 0 0 2 http://www.saptech.8m.com/erp  history.htm  [2) G a r t n e r C u s t o m e r P r o c e s s R e e n g i n e e r i n g - talk to your c u s t o m e r s , E . T h o m p s o n 13, D e c e m b e r 2 0 0 2 . [3) Z D N E T : S i x m i s t a k e s that will sink your C R M , B y A d r i a n M e l l o , M a r c h 18, 2002 4 ) Gartner: S e g m e n t i n g C R M S e r v i c e s : W h a t Is Y o u r Target M a r k e t ? , B y D e b a s h i s h S i n h a , A u g u s t 7, 2 0 0 0 [5) Forrester: S i e b e l ' s Verticalization O v e r h a u l s C R M Market R u l e s , B o b C h a t h a m , Laurie M . Orlov, M a r c h 13, 2 0 0 2 . [6) Gartner: S e g m e n t i n g C R M S e r v i c e s : W h a t Is Y o u r Target M a r k e t ? , B y D e b a s h i s h S i n h a , A u g u s t 7, 2 0 0 0 7 ) " S y s t e m s A n a l y s i s a n d D e s i g n " , G a r y B. S h e l l y , T h o m a s J . C a s h m a n , Harry J . Rosenblatt, J a n u a r y 2 0 0 0 B) IDS S c h e e r A G , Enterprise S e r v i c e Integrators, http://www.idsscheer.com/sixcms/detail.php/2014 [9) " R a p i d Application Development", J a m e s Martin, M a c m i l l a n P u b l i s h i n g C o . , Inc, 1991 ;10)  " Z D N E T : S i x mistakes that will sink your C R M " , A d r i a n M e l l o ,  M a r c h 18, 2 0 0 2 11)  W o r k i n g p a p e r 9 9 - M I S - 0 0 5 , Faculty of C o m m e r c e a n d B u s i n e s s  Administration, University of British C o l u m b i a , 1999. 12)  Gartner: S e g m e n t i n g C R M S e r v i c e s : W h a t Is Y o u r Target M a r k e t ? ,  B y D e b a s h i s h S i n h a , A u g u s t 7, 2 0 0 0 13)  Gartner: C R M in B a n k s — F r o m S i l o s to a n Enterprise A p p r o a c h ,  by S . Landry, F e b r u a r y 2001 14)  G a r t n e r : C R M Applications - A n Architectural V i e w of K e y V e n d o r s ,  B y Jeff C o m p o r t , M a r c h 2 0 0 3 15)  Gartner: A Five Y e a r V i s i o n for C R M Architectures a n d  T e c h n o l o g i e s , B y Jeff C o m p o r t , M a r c h 2 0 0 3  57  (16)  Proceedings of the Ninth Workshop on Information  Technologies  and Systems ( W I T S ' 9 9 , D e c e m b e r 11-12, 1999, Charlotte, North C a r o l i n a ) , 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 B a n k S y s t e m Definition T h e s y s t e m definition defines the b o u n d a r i e s of the s y s t e m that will b e m o d e l e d .  T h e s y s t e m in question provides a m e a n s for the organization to track a n d m a n a g e s a l e s a n d support functions of the Private B a n k .  Part B: Definition of Objects External to the s y s t e m O b j e c t s external to the s y s t e m are the objects that m a k e requests into the s y s t e m being m o d e l e d .  O b j e c t s external to the s y s t e m must b e h a v e independently a n d either h a v e a direct impact o n the m o d e l , provide a s e r v i c e required by the m o d e l o r both.  59  Table A.  External O b j e c t Definition for Private B a n k C R M s y s t e m  T h i s table lists all the external objects that will m a k e r e q u e s t s into the rural b a n k ' s C R M s y s t e m , a n d verifies if they m e e t the criteria for a n external object.  Object  1  Required  O n e of two is required  Description  Behaves  H a s a Direct  Provides  Independently  Impact o n M o d e l  Required S e r v i c e not in M o d e l  Customer  Company or  Customer is independent  individual  from system being  associated with  modeled as the C R M  the private bank  system is designed to serve them.  Controller  Customer initiated transactions are what the system is  No  designed to address.  Monitors system  Yes,  performance and  performance  provides feedback  Y e s , controller is the  Y e s , input from the  external entity that  controller determines  defines how the system  the prioritization of  should perform.  transactions.  monitoring is required to ensure that the system is achieving the goals defined for the system.  Supplier  Provides market  Suppliers provide  Y e s , Information  data for the  information that  provided by suppliers data provided  system  generated independently is used in calculations by supplier is of the system.  by the system  Y e s , market  required  60  Part C: Define the requests m a d e by the external objects into the Private B a n k ' s C R M s y s t e m . T h i s table lists all the external requests m a d e into the C R M s y s t e m a s defined by the b u s i n e s s analysts a n d u s e r s interviewed.  T a b l e B. External requests to the Private B a n k C R M S y s t e m  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 Aggregating s e r v i c e s into s e r v i c e types. In step two the s e r v i c e s n e c e s s a r y to satisfy the external requests of the Private B a n k ' s C R M S y s t e m a r e defined a n d a g g r e g a t e d . S e r v i c e s a r e aggregated together if they h a v e a similarity in state transformation, similarity in internal transformations, or a similarity in the r e s o u r c e s they u s e . A s c a n be s e e n in table C the only aggregation of s e r v i c e s is a c h i e v e d by the C u s t o m e r M a n a g e m e n t s e r v i c e that a g g r e g a t e s r e q u e s t s 2,4,5 a n d 8 from T a b l e 2 .  T a b l e C . A g g r e g a t i o n of s e r v i c e s for the Private B a n k C R M S y s t e m  One of three is Required Service Type Similarity in state transformation  Similarity in  Similarity in  internal trans-  resources used from Table 2  formations  for internal  that Rcquir" tho  trans-  service  Requests #  formations Execute  Performs actions on Account  Account  variables  1  Transactions Customer  Performs actions based on the  2, 4, 5,  Management customer profile variables Activity  Creates, deletes,  Management  and assigns  6  activities. Product  Displays  Management  Product  7  information Service  Manages Service  Management  workflow  3  Step 3: Objectifying the Private Bank's Service 62  In this step, w e c r e a t e objects that are responsible for delivering e a c h type of service.  T a b l e D: O b j e c t s c r e a t e d to handle the s e r v i c e types for the Private B a n k C R M system.  Object  Service Typo  Account  E x e c u t e L o a n , L e a s e , Insurance T r a n s a c t i o n s R e t u r n S t a t u s  Customer Mgmt  Customer Analysis  Activity  Activity M a n a g e m e n t  Service  Service Management  Product  Product M a n a g e m e n t  Object Descriptions: Account: T h e a c c o u n t object h a n d l e s all requests that h a v e a n effect on a c c o u n t s . T h i s object is a l s o the object that would be part of the " b a c k - e n d " integration to the s y s t e m s of record within the financial institutions.  It b e c o m e s a n object d u e to  the entities, b a c k e n d s y s t e m integration m o d u l e s , on which it performs transformations. C u s t o m e r Mgmt: T h i s object stores all the profile information about c u s t o m e r s , a n d is a n object b e c a u s e it collects all s e r v i c e s that a c c e s s the r e s o u r c e s a s s o c i a t e d with customers. Activity: T h e activity object h a n d l e s all the requests related to activity m a n a g e m e n t , s u c h a s creating meetings or recording call details. Activity b e c o m e s a n object b e c a u s e the transformations that the s e r v i c e s perform to s c h e d u l e all types of activities are similar in nature. Service:  63  T h e s e r v i c e object h a n d l e s all post-sale requests from c u s t o m e r s , w h i c h are similar in the r e s o u r c e s they require. Product: T h e product object stores all product information a n d h a n d l e s a n y information update requests related to products. Product b e c o m e s a n object s i n c e all the s e r v i c e s that are related to product require a c c e s s to similar r e s o u r c e s .  Step 4: Assignment of requests from the Private Bank's business model to objects In this step, requests a r e a s s i g n e d to objects b a s e d o n the state information or state transformations the request c a u s e s .  T a b l e E : A s s i g n i n g requests to O b j e c t s from the Private B a n k C R M S y s t e m Request Type State Info Required  Resulting State Object from Transformation Tablu 4 Responsible for State  Request  Information  # from  External  Table 2  Object  Delivery or Request  Customer Account Transaction  Transformation Account  Modifies  Related  Deposit  1  Accounts Customer Apply for loan pre-approval  Customer  Checks  Customer  Analysis  Customer  Mgmt  2  Profile Customer Complaint \  Service  Modifies  Feedback  Request Customer Best offer  Product  Returns  Related  Product  4 Reports Controller Assign activities Customer Product Information  Customer  Customer  Customer  Analysis  Profile  Mgmt  Activity  Modify  Management  Activities  Product  Returns  Related  Product  7  Activity Product  Details Supplier Market Feed  8  Product  Details Controller Performance  6  Service  Service  3  5  Account  Market Data  Return  Account  Market Info  65  Step 5: Identify Internal Object Interactions in the Private Bank's Business Model In this step interactions that result b e t w e e n objects a s a result of external requests are d o c u m e n t e d . T a b l e 6 s h o w s all external requests that precipitate a n internal request. T h e "Object R e s p o n s i b l e " c o l u m n s s h o w s the object that a c c e p t s the external request, a n d the c o l u m n titled " S e r v i c e H a n d l e d by Object" s h o w s the object that a l s o participates a s a result of a n internal request.  Internal  interactions w e r e identified by looking for objects that a c c e p t e d a n external request but were not a b l e to satisfy the initial request without the participation of another object  66  T a b l e F: Identifying internal interactions of the Private B a n k C R M S y s t e m  Inter-  Objei t  action Request Fxlernal  Rosponsible  Bllllli a  Object  Request  Customer Account a  Account  Transaction  1  Customer Apply for loan Cust Mgmt b  c  Customer  Customer d  Complaint \ Feedback Best offer  handled by  Interaction  object  Service  Customer  Customer  Customer  Data  Mgmt  Analysis  Product Info Product  6  activities  Product Detail  Modifies Service  Service  Service  Request Product  Customer  Customer  Customer  Data  Mgmt  Analysis  Activity  Modify  Activity  Management  Activities  4  Controller Assign e  Internal  pre-approval  2  3  Service  Private Bank Business Model Definition Step 6: In this section w e verify if n e w objects n e e d to b e c r e a t e d or if existing objects n e e d to be r e m o v e d d e p e n d i n g if there is overlap b e t w e e n the s e r v i c e s offered by two objects or if a n e w object n e e d s to b e c r e a t e d to perform the s e r v i c e for both of t h e m .  B y referring to T a b l e 11 w e s e e that there a r e no o v e r l a p s , s o no c h a n g e s to the objects a r e required.  67  2. The Challenges of Developing a Business Model  T h e c h a l l e n g e s in developing a b u s i n e s s model include the inappropriateness of " r e v e r s e engineering" to determine the b u s i n e s s p r o c e s s e s governing the b u s i n e s s ; lack of clear guidelines in determining what is difference b e t w e e n the c o r e b u s i n e s s a n d b u s i n e s s implementation a n d finally, how to d e c o m p o s e the b u s i n e s s m o d e l into meaningful c o m p o n e n t s .  3. The Business Model T h e p r o p o s e d b u s i n e s s model is d e v e l o p e d using a n object-oriented a p p r o a c h b e c a u s e objects support a view of organizations in terms of interacting i n d e p e n d e n t a g e n t s a n d units. In s u c h a m o d e l , the objects are either a role of the b u s i n e s s units or external entities that interact with the b u s i n e s s . R e q u e s t s are defined a s the interactions b e t w e e n objects that c a n flow in either direction a n d p o s s e s s both state variables a n d s e r v i c e s responsibilities a n d capabilities. T h e objects are the roles played by a g e n t s both internally a n d externally.  A  given agent c a n play different roles a n d s e v e r a l a g e n t s c a n play the s a m e role. R o l e s are l e s s d e p e n d e n t o n organization structure a n d implementation of business processes.  4. A Methodology to Develop a Business Model  T h e p r o p o s e d methodology is request driven b a s e d on requests m a d e to the b u s i n e s s . T h i s a p p r o a c h - known a s e n c a p s u l a t i o n - m e a n s that b u s i n e s s implementation p r o c e s s e s are not important in defining the roles of IS c o m p o n e n t s with respect to the b u s i n e s s m o d e l . T h e methodology for d e v e l o p i n g a b u s i n e s s model is:  69  Step 1: Identify Objects and Requests External to an Organization and Assign Services to Requests. T h i s step defines the boundary a n d identifies the p u r p o s e of the b u s i n e s s m o d e l . External objects b e h a v e independently of the c o r e b u s i n e s s a n d either have a direct impact or provide s e r v i c e s n e e d e d in the core b u s i n e s s . T h e p u r p o s e of identifying external objects this w a y is to e n s u r e that they are not tied to b u s i n e s s implementation a n d that their interaction with the m o d e l is d e f i n e d . After the b o u n d a r y of the m o d e l e d s y s t e m is defined in terms of the external objects with w h i c h the s y s t e m interacts, then the requests sent or r e c e i v e d by the external objects c a n be identified.  Step 2: Aggregate Services. T h e objective of this step is to group similar responsibilities together b a s e d on identified requests. S e r v i c e s are a g g r e g a t e d o n the b a s i s of s e r v i c e type. T h e s e r v i c e types are similarity in internal transformations types (include similarity of state information), similarity in internal transformations a n d similarity in the r e s o u r c e s u s e d for internal transformations.  Step3:  Objectify each Service.  O n c e a g g r e g a t e d , e a c h s e r v i c e type is r e p l a c e d by a n object a n d n a m e d in a c c o r d a n c e with the role it plays. T h i s e n s u r e s e a c h object in the d e c o m p o s e d m o d e l h a s a c l e a r responsibility a n d c l e a r responsibility signifies e n c a p s u l a t i o n . E n c a p s u l a t i o n in the context of the b u s i n e s s m o d e l m e a n s that the b u s i n e s s s t a y s the s a m e , independent of how it is "implemented" (in terms of b u s i n e s s structure a n d p r o c e s s e s ) a n d thus r e s i s t a n c e to b u s i n e s s c h a n g e s . T h e result of S t e p 3 is a set of objects, e a c h handling o n e type of request using o n e s e r v i c e .  Step 4: Decompose Requests in the Previous Levels of Model. Utilizing the generated objects, this step d e c o m p o s e s the request of e a c h object e m p l o y i n g the criteria outlined in S t e p 2. (i.e., looking for similar state information or state transformation).  70  Step 5: Identify Interactions  among  Objects.  After identifying the d e c o m p o s e d objects with their c o r r e s p o n d i n g external e v e n t s a n d s e r v i c e s , if a n object n e e d s a service of another object in the c o u r s e of performing its o w n s e r v i c e , the former object must s e n d a request to the latter. T h i s results in a n e w s e r v i c e provided by the latter.  Step 6: Create/Remove  Objects  for Sharing  Services/State  Information.  If a s e r v i c e (or part of a service) of o n e object is similar to that of another object, then either a n existing object will perform the s e r v i c e or a n e w object to provide the s e r v i c e must be c r e a t e d . T h e s e r v i c e s provided by e a c h object must be clearly identified a n d d e s c r i b e d .  5. Conclusion, Experience of Using a Business Model, and Future Work T h e article d i s c u s s e s the n e e d for a b u s i n e s s m o d e l to support redesign a n d r e u s e of IS a n d outlines the c h a l l e n g e s in constructing s u c h a m o d e l . T h e resulting m o d e l u s e s external objects a n d their requests involving roles rather than a g e n t s . D e c o m p o s i n g t h e s e roles using aggregation of requests a n d s e r v i c e s - b a s e d in similarities in state information a n d state transformations ensures independence.  T h e major portion of the b u s i n e s s model w a s d e v e l o p e d for the c u s t o m e r s e r v i c e of a cellular p h o n e c o m p a n y a n d proved robust e n o u g h to accurately depict their c o r e b u s i n e s s p r o c e s s e s e v e n while undergoing rapid c h a n g e . It w a s a l s o found to be applicable to a landline p h o n e c o m p a n y a s well.  W h i l e e n c o u r a g e d by practical results, the n e e d for more empirical r e s e a r c h is clearly required. T h e authors believe that by linking the architecture of the IS to the b u s i n e s s m o d e l , they c a n attach to e a c h IS c o m p o n e n t to its b u s i n e s s m e a n i n g . T h e y are currently developing a methodology to derive "ideal" IS  71  architecture a n d explore w a y s to link IS c o m p o n e n t s a n d d a t a b a s e contents to the b u s i n e s s m o d e l . T h e resultant model c o u l d a l s o aid in identifying r e u s a b l e IS c o m p o n e n t s a n d a s s i s t with migrations to n e w platforms.  Relevance T h i s p a p e r is relevant to this research p a p e r a s it p r o p o s e s a method of distilling the true nature of a b u s i n e s s irrespective of the underlying IT infrastructure. W h e n creating a Vertical C R M solution the s a m e c h a l l e n g e is f a c e d . A s u c c e s s f u l Vertical C R M solution should be relevant to m a n y c o m p a n i e s in a specific vertical market irrespective of the technology that already exists within the organization  72  r e u s e d while restructuring or reengineering. A method for constructing a n organization's b u s i n e s s m o d e l - b a s e d o n a n Object-Oriented Enterprise M o d e l i n g ( O O E M ) - is p r e s e n t e d w h i c h e n a b l e s the d e v e l o p m e n t of a n "ideal" IS architecture and/or reverse e n g i n e e r existing IS architectures. T h e author's u s e a t e l e c o m m u n i c a t i o n s c o m p a n y to illustrate their methodology a n d d e s c r i b e h o w it c a n b e i m p l e m e n t e d .  2 A Representational Framework of an Organization  T h e authors present the representational framework of a n organization that is n e c e s s a r y for understanding the relationship of b u s i n e s s m o d e l a n d IS. T h e framework c o n s i s t s of four layers: b u s i n e s s m o d e l , b u s i n e s s architecture, IS architecture, a n d IS implementation. T h e first two layers f o c u s o n the b u s i n e s s d o m a i n of a n organization while the bottom two o n the IS d o m a i n .  2.1 Business Model  T h e b a s i s of a b u s i n e s s model is that the c o m p a n y exists to deliver products a n d s e r v i c e s to its c u s t o m e r s . It d o e s not s h o w h o w a n organization is structured or o p e r a t e s - the business architecture -to a c c o m p l i s h its goal of c u s t o m e r satisfaction. T h e s e p r o c e s s e s a r e c o n s i d e r e d a n implementation of the b u s i n e s s architecture.  T h e p r o p o s e d m o d e l utilizes a n object-oriented a p p r o a c h b e c a u s e objects d e s c r i b e a n organization in terms of interacting independent a g e n t s a n d units. T h e authors then outline a b u s i n e s s model consisting of a set of objects e a c h reflecting either a role of a b u s i n e s s unit (or agent) or a role of a n external entity that is interacting with the b u s i n e s s . Interactions a r e m o d e l e d in terms of requests sent b e t w e e n objects. A n object type h a s state variables reflecting its physical state a n d knowledge, a n d services representing its responsibilities a n d capabilities.  74  2.2 Business Architecture T h e b u s i n e s s architecture is a n implementation of the m o d e l a n d d e s c r i b e s the a c t u a l organizational units a n d their relationships. G i v e n the complexity of roles a n d responsibilities, the relationships between objects are m a n y - t o - m a n y .  2.3 IS Architecture T h e IS architecture s p e c i f i e s the logical composition of c o m p o n e n t s that support the b u s i n e s s model a n d d o e s not a d d r e s s the actual IS implementation.  2.4 IS Implementation T h i s layer is the actual implementation of the IS architecture including d a t a b a s e d e s i g n a n d implementation, p r o c e s s i n g c o m p o n e n t s (which m a y or m a y not u s e a n object architecture), a n d G U I d e s i g n a n d implementation.  3 The Challenges  A s d i s c u s s e d , in traditional b u s i n e s s m o d e l s the IS architecture is c o n s t r a i n e d by the b u s i n e s s architecture a n d more c o n c e r n e d with b u s i n e s s operations s u c h a s h o w the b u s i n e s s is i m p l e m e n t e d . T h e p r o c e s s of m a p p i n g the "ideal" IS architecture to the resultant m o d e l is imperfect d u e to: •  T h e m e a n i n g of objects is o b s c u r e d d u e to philosophical differences in the m e a n i n g of objects u s e d in a b u s i n e s s model a n d objects a s u s e d in a n implementation m o d e l ;  •  Existing IS architecture reflects how the b u s i n e s s is i m p l e m e n t e d rather than what the b u s i n e s s is. T h e result is conflicts b e t w e e n b u s i n e s s operations a n d the b u s i n e s s m o d e l in the roles a n d responsibilities of a given IS c o m p o n e n t ;  75  •  Often the IS architecture reflects a data-centric view andt not a n object v i e w a n d therefore d o e s not indicate the d y n a m i c s of the b u s i n e s s .  4 A Linkage Method  T h e author d e s c r i b e the d e v e l o p m e n t of the b u s i n e s s m o d e l ; derive a n "ideal: IS architecture; reverse translate existing d a t a tables a n d applications into a n object oriented d e s i g n ; a n d outline h o w to link the current IS architecture to the derived business model.  4.1 Developing a Business Model T h e authors d e s c r i b e the methodology a n d ideas for constructing a b u s i n e s s m o d e l . T h e methodology is request driven a n d u s e s roles b a s e d o n requests, which ensures encapsulation.  T h e b u s i n e s s model methodology is d e s c r i b e d in five s t e p s . T h e first step is to identify external objects that s e n d requests to the organization. External objects are t h o s e that interact with, but are independent of a n d play not roles in carrying out, the b u s i n e s s . F o r e a c h external request, a s e r v i c e in the organization is a s s i g n e d to p r o c e s s . In step 2, similar s e r v i c e s are a g g r e g a t e d together to eliminate duplication of responsibilities. In step 3, e a c h s e r v i c e is r e p l a c e d by a n object w h i c h represents a role in the organization. T o further d e c o m p o s e the object, the request d e c o m p o s e d in step 4. Next, in step 5, object interactions are identified. A n interaction o c c u r s w h e n a n object n e e d s a s e r v i c e of another object in the c o u r s e of performing its o w n service. In this c a s e , the former object must s e n d a request to the latter. Finally, in step 6, similar s e r v i c e s in different objects are resolved by eliminating duplication  4.2 Deriving an Ideal IS Architecture from the Business Model  76  T o differentiate b e t w e e n h u m a n a n d computing activities, delegate a n d static objects are e m p l o y e d . D e l e g a t e objects are responsible for performing information p r o c e s s i n g activities. G i v e n that a n object h a s state v a r i a b l e s , if they are structured e n o u g h to be c o m p u t e r i z e d , then they c a n be " d e l e g a t e d " to a n IS c o m p o n e n t . T h i s "delegation" provides a m e c h a n i s m for determining a u t o m a t e d IS c o m p o n e n t s a n d provides the linkage to technology.  T h e model u s e s static objects to represent things n e e d e d to be known but perform no s e r v i c e s in running the b u s i n e s s e s . Static objects d o not h a v e s e r v i c e s a n d their states are maintained by objects that h a v e s e r v i c e s . Differentiating b e t w e e n d e l e g a t e a n d static objects is difficult a n d the authors p r o p o s e a method of "objectifying" the c o m p a n y ' s IS relationship d a t a b a s e s to arrive at a n appropriate representation of the b u s i n e s s m o d e l .  4.3 C o n s t r u c t i n g Data Objects from Existing IS  E x a m i n i n g the d e s i g n of the d a t a b a s e s in the existing IS b e g i n s the construction of d a t a objects. T h e r e are three s t e p s involved in this p r o c e s s .  Step 1 - Identify all major/strong  entities from a  database  All strong entities b e c o m e the c a n d i d a t e s for d a t a objects.  Step 2 - Determine  if a child table can be a data object  C h i l d tables c a n be the attributes of data objects identified in step 1 or be d a t a objects t h e m s e l v e s . T h e consideration d e p e n d s on whether the tables a l o n e are a c c e s s e d by other c o m p u t e r applications without a c c e s s i n g their parent tables.  Step 3 - Assign  relationship  tables to data  objects  All attributes of a relationship table b e c o m e the attributes of the d a t a objects that represent the strong entities of the relationship.  77  4.4 Constructing Dynamic Objects D y n a m i c objects e n c a p s u l a t e all operations against e a c h d a t a object e n a b l i n g the authors to d e v e l o p their object-oriented view of IS architecture. T o construct a d y n a m i c object, e x a m i n e the application objects/modules that a c c e s s the tables a s s o c i a t e d with the d a t a object; determine the a c c e s s operations that are performed by t h e s e applications; a n d identify the programming objects a n d the d a t a tables to w h i c h they have a c c e s s . It is then p o s s i b l e to incorporate the operations of the application (object/module) against the d a t a objects into d y n a m i c objects.  4.5 Connecting IS implementation and the ideal IS architecture T h e next step in understanding how existing IS supports the b u s i n e s s m o d e l , the d a t a a n d d y n a m i c objects derived from existing IS implementation are m a p p e d into the "ideal" IS architecture derived from the m o d e l . O n c e c o m p l e t e d , the various c o m p o n e n t s are linked to a n "implementation independent" v i e w of the b u s i n e s s . S i n c e the n e w view of IS is a n object-oriented m o d e l , it allows e a s i e r reengineering or restructuring a n d adoption of n e w IS architecture  5 Related Work  T h e authors review the literature related to the u s e of objects in the attempting to capture information at the b u s i n e s s a n d IS architecture levels; facilitate c h a n g e ; a n d reverse e n g i n e e r existing s y s t e m s a s well a s using object-oriented a n a l y s i s m e t h o d s to m o d e l b u s i n e s s p r o c e s s e s .  6 Conclusions T h e authors p r o p o s e d a method for linking existing IS architecture to the b u s i n e s s m o d e l a n d d e s c r i b e d the methodology u s e d to d e v e l o p s u c h a m o d e l .  78  T h e y then illustrated a reverse translation of a specific application a n d provided a n e x a m p l e of s u c h a m a p p i n g b e t w e e n the applications a n d the b u s i n e s s m o d e l for a t e l e c o m m u n i c a t i o n s c o m p a n y . W h i l e they a c k n o w l e d g e that m o r e r e s e a r c h is required, they believe that they h a v e demonstrated the applicability of the method.  T h e authors believe that their modeling a p p r o a c h a n d linking m e t h o d o l o g y provides a w a y to evaluate a n IS in the context of b u s i n e s s n e e d s a n d p r o c e s s e s ; a m e a n s of identifying r e u s a b l e IS c o m p o n e n t s , a m e t h o d of "reverse e n g i n e e r i n g " the architecture of existing IS s y s t e m s ; facilitate migration to n e w platforms; support for the creation of a n object-oriented view of existing application a n d provide methods to aid in the development of "organizational memory".  Relevance  T h e linking r e s e a r c h is relevant to creating Vertical C R M solutions a s it offers a n a p p r o a c h to verify if a solution that h a s b e e n d e v e l o p e d actually m e e t s the true n e e d s that h a v e b e e n identified for the vertical market.  7 9  Appendix D - Interviewing Business Analysts for OOBM Research O n e key s o u r c e of d a t a for this p a p e r w a s collected from interviews with b u s i n e s s analysts w h o w e r e working o n actual C R M implementations. C o l l e c t i n g information from C R M b u s i n e s s analysts p o s e d two primary c h a l l e n g e s . T h e first c h a l l e n g e is that b u s i n e s s analysts working o n large projects are generally under intense time constraints, which m e a n s that the time available to a n interviewer is limited. S e c o n d l y they are very familiar with building C R M applications with current t e c h n o l o g i e s , however, m a n y are not familiar with object oriented c o n c e p t s a n d i d e a s .  Provide Reading in Advance T o o v e r c o m e the limited time available the b a s i c s of the object-oriented a p p r o a c h to b u s i n e s s modeling w a s s u m m a r i z e d a n d e-mailed to the analysts a w e e k before the interview w a s to take p l a c e .  T h i s a p p r o a c h proved useful in that it  provided a foundation, h o w e v e r s m a l l , o n w h i c h to b a s e the interview.  Understand Their Work Methodology B y far, the most important strategy that allowed g o o d information to be collected w a s s p e n d i n g time understanding the a p p r o a c h that the b u s i n e s s a n a l y s t s currently u s e d for defining a C R M solution. Understanding the p r o c e s s e s a n d s t e p s that the analysts u s e for the specific C R M p a c k a g e with w h i c h they are working with allows the a r e a s that are relevant to O O B M r e s e a r c h to b e identified and focused upon.  T h e p a c k a g e that w a s u s e d for the r e s e a r c h p r e s e n t e d in  this p a p e r h a d two primary p h a s e s of development. T h e first step entailed creating a d a t a m o d e l , a n d the s e c o n d step w a s to define b u s i n e s s p r o c e s s e s . O n c e t h e s e s t e p s w e r e c o m p l e t e d , a user interface w a s g e n e r a t e d to allow e n d u s e r s to interact with the s y s t e m .  With a n d understanding of how the b u s i n e s s analysts worked it greatly s p e e d e d up the interview p r o c e s s . It w a s d i s c o v e r e d , for instance, that w h e n the G U I w a s  80  g e n e r a t e d , the a n a l y s t s a l s o c r e a t e d a superset of c a n d i d a t e s for b u s i n e s s objects; therefore, the c o n v e r s a t i o n w a s able to quickly f o c u s on the list of b u s i n e s s objects that a p p e a r e d o n the planned G U I . H a v i n g identified the b u s i n e s s object c a n d i d a t e s it w a s then n e c e s s a r y to extract the list of requests for e a c h object.  Use Existing Project Documentation Extracting the requests w a s c h a l l e n g i n g at first s i n c e the b u s i n e s s analysts did not think in term of r e q u e s t s , but rather, in terms of b u s i n e s s p r o c e s s e s .  It w a s  n e c e s s a r y , therefore, to identify a n d step through the primary p r o c e s s e s of the s y s t e m a n d interpret the flow of the p r o c e s s in terms of object requests a n d r e s p o n s e s rather than individual p r o c e s s e s . T h e p r o c e s s e s w e r e generally well d o c u m e n t e d a n d the b u s i n e s s a n a l y s t s were able to be very helpful in identifying the requests a n d r e s p o n s e s of the individual b u s i n e s s objects o n c e they understood the O O B M terminology in context of the b u s i n e s s p r o c e s s e s they w e r e familiar with.  B y being very o r g a n i z e d , leveraging existing documentation for the C R M project, a n d breaking the interviews up into s e v e r a l short 3 0 min s e s s i o n s that suited the b u s i n e s s analysts s c h e d u l e it w a s p o s s i b l e to collect a large amount of d a t a in relatively little time.  81  A p p e n d i x E - C o n s t r u c t i n g Dynamic Objects  Assigned Dynamic  Relationship Application  Object  Tables  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 Modifies a Connection in the Connection  clsConnection.Modify table clsConnection.Remov Removes a Connection from the e  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 Removes a company from the company  cIsCompany.Remove table clsCompany.Status  Returns the status of the Company  Connection clsConnection cIsConnection.Add  Adds a Connection to the Connection table Modifies a Connection in the Connection  clsConnection.Modify table  82  cIsConnection.Remov Removes a Connection from the e  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 Adds a Product Feature to the dd  Product_Feature table  clsProduct_Feature.  Modifies a Product Feature in the  Modify  Product_Feature table  clsProduct_Feature.R Removes a Product Feature from the emove  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 Removes an Account from the Account  cIsAccount. Remove  table  cls.Status  Returns the status of the  Account Features clsAccount_Features clsAccount_Features. Adds an Account Feature to the Add  Account_Features table  clsAccount_Features. Modifies an Account Feature in the Modify  Account_Features table  83  clsAccount_Features. Removes an Account Feature from the Remove  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.  Modifies holdings in the Account_Holding  Modify  table  clsAccount_Hplding. Removes holdings from the Remove  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 Modifies an opportunity in the opportunity  cIsOpportunity.Modify table cIsOpportunity.Remo Removes an opportunity from the ve  opportunity table  clsOpportunity.Status Returns the status of the Opportunity Opportunity_ Product clsOpportunity_Produ ct clsOpportunity_Produ Adds a Product to the Opportunity_Product ct.Add  table  clsOpportunity_Produ Modifies a Product in the ct.Modify  Opportunity_Product table  clsOpportunity_Produ Removes a Product from the ct.Remove  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 Adds a Product Feature to the ct_Features.Add  Opportunity_Product_Features table  clsOpportunity_Produ Modifies a Product Feature in the ct_Features.Modify  Opportunity_Product_Features table  clsOpportunity_Produ Removes a Product Feature from the ct_Features.Remove Opportunity_Product_Features table clsOpportunity_Produ Returns the status of the Opportunity ct_Features.Status  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. Adds service requests to the Add  Service_Request table  clsService_Request. Modifies service requests in the Modify  Service_Request table  clsService_Request. Removes service requests from the Remove  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 Modifies work orders in the Work_Order y  table  clsWork_Order.Remo Removes work orders from the Work_Order ve  table  clsWork_Order.Statu s  Returns the status of the Work_Order  86  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

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

Comment

Related Items