Specification and Design of A CRM System For Smes: Inderjit Singh MSC Information Systems 2002-2003

MSc Project 2003 - Specification and Design of a CRM system
Specification and Design of a

CRM system for SMEs
Inderjit Singh
MSc Information Systems
2002-2003
The candidate confirms that the work submitted is their own and the appropriate credit has been
given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
(Signature of student) _______________________________

Summary
Customer Relationship Management (CRM) is aimed at maximising the profitability of customers
through the customer relationship. The focus on the project was the specification and design of a
CRM system for small and medium enterprises (SMEs). This initially involved understanding the
importance of CRM and its applicability to SMEs. In addition, the current CRM market offerings
were investigated to understand their underlying data models.
The project was carried out in conjunction with Leeds University Business School (LUBS), and the
SME requirements were based upon a single service-based SME – Harland, Turnball and Roberts.
The project initially involved explaining the applicability of CRM to the SME and then aiding the
SME in identifying the relevant CRM requirements that could then be taken to their software
vendors to provide an integrated approach.
Through the project, the business benefits of CRM were identified and the functional and data
requirements developed in a scenario-based approach. These were implemented using a JSP-
MySQL open-source architecture.
The evaluation indicated that the project clearly defined relevant requirements and functionality,
and that the implementation demonstrated how the benefits of CRM could be achieved. The
applicability of the functional and data requirements to other product-based and service-based
SMEs was also evaluated. It was found that the functional requirements were largely applicable
across both contexts but there were differences in the implementation against these requirements.
Also, the underlying data models were too different to be combined into a single language-neutral
CRM data model to support all SMEs.
i
Inderjit Singh
Acknowledgment
I would especially like to thank my project supervisor, Dr. Stuart Roberts whose patience, support
and guidance throughout the project were invaluable. It was a pleasure working with him.
I would also like to thank Wayne Robinson and Tim Duckett of LUBS for their input during the
project.
Finally and importantly, my family and friends who were there for me throughout the project. A
special acknowledgment goes to Tejan Balakrishnan, Dima Al Damen and Rahul Ahuja whose
friendship and guidance spurred me on.
I dedicate this project to my parents, my brother and sister-in-law whose love I cherish and whose
unconditional backing is my pillar of strength.
ii
Inderjit Singh
Table of Contents
Summary .............................................................................................................................................. i
Acknowledgment................................................................................................................................. ii
Table of Contents ............................................................................................................................... iii
1 Introduction ..................................................................................................................................1
1.1 Project Aims, Objectives and Requirements........................................................................1
1.1.1 Project Objectives.........................................................................................................1
1.1.2 Minimum Requirements...............................................................................................1
1.2 Key Challenges.....................................................................................................................1
1.3 Structure of the Report .........................................................................................................2
1.3.1 Background Review (chapter 2)...................................................................................2
1.3.2 Project Management and Methodology (chapter 3) .....................................................2
1.3.3 Understanding the Problem (chapter 4)........................................................................2
1.3.4 Producing a Solution (chapter 5,6,7)............................................................................2
1.3.5 Evaluation of the Solution (chapter 8) .........................................................................2
1.3.6 Conclusion and Future Work (chapter 9) .....................................................................2
1.4 Project Solutions for the specific SME ................................................................................2
1.5 Project Solutions for SMEs ..................................................................................................3
2 Background Review .....................................................................................................................4
2.1 What is CRM and why is it important?................................................................................4
2.2 What are the main CRM vendor offerings? .........................................................................6
2.3 What are the SME trends for CRM? ....................................................................................7
2.4 Data Requirements for SME CRM offering.........................................................................8
3 Project Management and Methodology .....................................................................................11
3.1 Project Methodology ..........................................................................................................11
3.2 Project Plan.........................................................................................................................12
4 Defining the Business Problem ..................................................................................................13
4.1 Understanding the Business and the Business Context......................................................13
4.1.1 Defining the ‘Product’ Offered ..................................................................................14
4.2 Different Approach for Service-Based CRM.....................................................................14
4.2.1 Relationship Marketing ..............................................................................................14
4.2.2 Service Quality...........................................................................................................15
4.3 Understanding of the Requirements ...................................................................................16
4.4 Define the Project Problem ................................................................................................18
4.5 Identifying the Business Benefits.......................................................................................19
4.6 Business Modelling ............................................................................................................20
4.7 Validation of the Project Problem ......................................................................................20
4.8 Impact on Project Management..........................................................................................21
5 Approach in Producing a Solution .............................................................................................23
5.1 Requirements Workflow ....................................................................................................23
5.2 Analysis and Design Workflows........................................................................................23
5.3 Implementation and Test Workflows .................................................................................23
6 Producing a Solution – Tactical .................................................................................................24
6.1 Scenario 1 – Integrate New Customer Case Creation ........................................................25
6.1.1 Requirements..............................................................................................................25
6.1.2 Analysis and Design...................................................................................................26
6.1.3 Architecture Definition...............................................................................................26
6.1.4 Implementation...........................................................................................................27
6.1.5 Testing ........................................................................................................................27
6.2 Scenario 2 – Provide Service Cycle ...................................................................................28
6.2.1 Requirements..............................................................................................................28
iii
Inderjit Singh

6.2.3 Implementation and Testing.......................................................................................29
6.3 Scenario 3 - Reduce Search Time ......................................................................................29
6.3.1 Requirements..............................................................................................................30
7 Producing a Solution – Strategic ................................................................................................32
7.1 Scenario 4 – Capture Inbound Referral Information..........................................................32
7.1.1 Requirements..............................................................................................................33
7.2 Scenario 5 – Provide Targeted Marketing..........................................................................34
7.2.1 Requirements..............................................................................................................35
8 Evaluation...................................................................................................................................38
8.1 Evaluation against Project Objectives................................................................................38
8.2 Evaluation of Background Literature .................................................................................39
8.3 Evaluation of the Project Outcomes by the specific SME (HTR)......................................39
8.4 Evaluation of Project Outcomes by LUBS.........................................................................39
8.5 Evaluation of the functional and data requirements for the SME market as a whole ........40
8.5.1 Scenarios ....................................................................................................................40
8.5.2 Functional Requirements............................................................................................41
8.5.3 Data Requirements .....................................................................................................41
8.6 Evaluation of the system with regards to ISO9126............................................................41
8.6.1 Functionality...............................................................................................................41
8.6.2 Reliability ...................................................................................................................41
8.6.3 Usability .....................................................................................................................42
8.6.4 Efficiency ...................................................................................................................42
8.6.5 Maintainability ...........................................................................................................42
8.6.6 Portability ...................................................................................................................42
8.7 Evaluation of the Architecture ...........................................................................................42
8.8 Evaluation of Project Management ....................................................................................42
8.9 Evaluation of the Evaluation ..............................................................................................43
9 Conclusion and Future Work .....................................................................................................44
9.1 Next Steps for the Business................................................................................................44
9.2 Next Steps of the System In Relating to the Business .......................................................44
9.3 Next Steps in the Addition of Functionality to the System................................................45
10 References ..............................................................................................................................46
11 Appendix A - Personal Reflection.........................................................................................49
12 Appendix B - Objectives and Deliverables ............................................................................51
13 Appendix C - Marking Scheme and Feedback.......................................................................53
14 Appendix D ............................................................................................................................55
14.1 Use-Case Realisations of the Scenarios .............................................................................56
14.2 Applicability of functional and data requirements to product and service-based SMEs ...65
14.2.1 Functional Requirements............................................................................................65
14.2.2 Data Requirements .....................................................................................................67
14.3 Project Questionnaires........................................................................................................69
14.3.1 Evaluation of Background Literature by LUBS.........................................................69
14.3.2 Evaluation of Project by Harland, Turball and Roberts .............................................70
14.3.3 Evaluation of the Project by LUBS............................................................................74
15 Appendix E - Partner Presentations........................................................................................80
iv
Inderjit Singh
15.1 Partner Presentation 25th June 2003 ...................................................................................80

15.2 Final Partner Presentation 1st August 2003 ........................................................................84
16 Appendix F - Screenshots......................................................................................................92
16.1 Scenario 1 ...........................................................................................................................92
16.2 Scenario 2 ...........................................................................................................................95
16.3 Scenario 3 ...........................................................................................................................99
16.4 Scenario 4 .........................................................................................................................102
16.5 Scenario 5 .........................................................................................................................108
v
Inderjit Singh
1 Introduction
This report describes the project undertaken in conjunction with the Leeds University Business
School (LUBS) with regards to the specification and design of an open-source customer
relationship management system (CRM) [1].
1.1 Project Aims, Objectives and Requirements

The initial project specification by LUBS suggested the implementation of a CRM system to be
used as a live system by small and medium enterprises (SMEs). The aim was to provide an open-
source solution that would result in minimal costs to the SMEs. In addition, the product was to be
browser-based and database-centric. However, it was noted to LUBS that without a clear
understanding of SME requirements at the start of the project and the lack of assurance of adequate
SME resources to the project, that the aim should be to provide a proof-of-concept system that
could then be made operational.
1.1.1 Project Objectives

After discussion with both the project supervisor and LUBS, the following objectives of the project
were stated.
1. To gain an understanding of the importance of CRM and its relevance to SMEs
2. To investigate the current CRM market offerings e.g. Siebel, Peoplesoft, SAP and
SalesLogix and their underlying data models
3. To define the requirements of the SMEs and perform the analysis and design of the CRM
system
4. To develop a proof of concept CRM system
1.1.2 Minimum Requirements

The minimum requirements represented the way of achieving these objectives.
• A report outlining the importance of CRM, its relevance to SMEs and current CRM market
offerings
• Use of a methodology to define requirements of the SMEs and perform the analysis and
design of the CRM system
• Identification of the functionality of the system to support the SME requirements
• Production of a data model to support the CRM system
• Implementation of one or more components of functionality
1.2 Key Challenges

For the project to succeed, both business and technical issues had to be overcome. From a business
perspective, this included learning about the SMEs and their market and also establishing
relationships with key personnel to elicit requirements. Also, the expectations of the SMEs and of
LUBS had to be carefully managed and the focus maintained on delivering the requirements and
objectives of this project and not simply producing their preferred deliverables. At the same time, it
was important to continually demonstrate the ‘value’ that the project was providing to both LUBS
and the SMEs to keep them committed.
From a technical perspective, the project required both application and database development and
since the project was to be open-source this would require gaining skills in open-source database
management systems (DBMS) as well as browser-based technologies.
1
Inderjit Singh
1.3 Structure of the Report

1.3.1 Background Review (chapter 2)
The chapter provides a review that established the business case for CRM and the relevance of
CRM to SMEs through SME market analysis. A review of the main CRM vendors was then
undertaken and a set of core CRM components established. The data requirements were then
produced that supported CRM components provided by SME product-based vendors.
1.3.2 Project Management and Methodology (chapter 3)

Due to the project involving two external clients that were LUBS and the specific business, there
was an increased emphasis on project management to demonstrate value and ensure commitment
but also to maintain the focus on this project and its deliverables. The chapter describes the
methodology chosen that complemented the focus on management of risk as well as iteration in
development.
1.3.3 Understanding the Problem (chapter 4)

The chapter summarises the understanding of the context of the business and its current business
processes and use of IT. This led to the definition of the project problem that required the
establishment of ‘why’ CRM was important as well as ‘how’ the benefits could be realised. This
also required the incorporation of a benefits-focused approach.
1.3.4 Producing a Solution (chapter 5,6,7)

The chapter summarises the agreed approach for producing the solution that was a scenario-based
approach as this would minimise risk by establishing the proof-of-architecture early on in the
project and allow the focus on one scenario at a time. An approach is outlined in terms of the
different artefacts of the core workflows that would ensure consistency from requirements through
analysis and design and into implementation.
1.3.5 Evaluation of the Solution (chapter 8)

The chapter summaries the evaluation of the project against the objectives incorporating the
feedback gained both from LUBS and the specific business. Also, an attempt was made to evaluate
the applicability of the functional and data requirements to product-based and service-based SMEs
as a whole.
1.3.6 Conclusion and Future Work (chapter 9)

The chapter concludes the report and what it has achieved. Future work is also described including
the next steps for the business and the additional functionality that could be added to the system.
1.4 Project Solutions for the specific SME

The project focused upon CRM for SMEs, however, within the project, only one specific SME was
dealt with - Harland Turnball and Roberts (HTR). As a result, project solutions were delivered that
were specific to the business and there was a need to generalise the requirements for SMEs from
this one example. The specific business was provided with
• An indication of the CRM service quality gaps existing in the business
• A list of business benefits that would be gained if the quality gaps were addressed
• A list of functional requirements needed to address the quality gaps
• A list of data requirements needed to support the functionality
• Implementations of business processes that represented the functionality
2
Inderjit Singh
Overall, the business agreed with the service quality gaps and business benefits identified. They
also thought that the functional and data requirements defined were both relevant and required by
the business. Also, they agreed that the implementation clearly demonstrated the functionality and
that the implementation of the functionality showed how the business benefits could be achieved.
Their overall opinion of the project was ‘extremely beneficial’ and ‘enjoyable and useful’ as
provided in their evaluation. This is included in Appendix D.
1.5 Project Solutions for SMEs

As only one SME was dealt with within the project that was a service-based firm in the legal sector,
generalisation was required in terms of the functional and data requirements for the SME market as
a whole. Within the evaluation of the functional and data requirements produced, a comparison was
made of their applicability to service-based as well as product-based SMEs. It was found that the
functional requirements were largely applicable across both contexts but there were differences in
the implementation against these requirements. Also, the underlying data models were too different
to be combined into a single language-neutral CRM data model to support all SMEs.
3
Inderjit Singh
2 Background Review
The review was used to define and establish the business case for CRM, its applicability to SMEs
and the data requirements of product-based CRM vendor offerings.
2.1 What is CRM and why is it important?

Interactions between a business and its customers occur throughout the ‘customer life cycle.’ [6]
This is composed of three basic stages as quoted from [6]:
1) Sales – ‘all activities from identifying and targeting potential customers, to first contact, to a
commitment to buy, and finally to contractual closure.’
2) Delivery – ‘installation/implementation of the particular product or service.’
3) After-Sales – ‘covers those activities concerned with the ongoing relationship, like customer
service and general enquiries.’
There are a number of processes, both internal and external that underpin each of these stages as
shown in figure 1 from [6].
Figure 1. The customer life cycle processes
The approach taken to maximising the profitability of a customer relationship is referred to as

Customer Relationship Management (CRM) and it should support the processes within the different
stages of the customer lifecycle. CRM is defined as ‘a management approach that enables
organisations to identify, attract and increase retention of profitable customers by managing
relationships with them.’ [2]
It involves
1) ‘identifying, satisfying, retaining and maximising the value of a company’s best
customers.’[3]
2) ‘a sales and service business strategy so that whenever there is an interaction, the message
exchanged is appropriate for that customer.’ [4]
3) ‘an effort to create the whole picture of a given customer, bringing together consistent,
comprehensive and credible information on all aspects of the existing relationship.’ [5]
Consequently, CRM is not simply a technical solution but rather a business strategy that is enabled
through the use of IS/IT.
4
Inderjit Singh
The growth of CRM is due to the development of relationship marketing and a focus on customer
retention. Studies have shown that ‘a 5% increase in customer retention results in an increase in
average lifetime value of between 35% and 95%.’ [7] In addition, loyal customers are more
profitable to a company for the following reasons as quoted from [7]:
1) ‘Customer acquisition costs may be high, so customers may not become profitable unless
they are retained for one or more years.’
2) ‘There will be a stream of profits from the loyal customer in each year after acquisition costs
are covered.’
3) ‘Loyal customers buy more over time, so revenues go up.’
4) ‘Companies become more efficient as serving loyal customers, so costs go down.’
5) ‘The relationship is of value to the customer too, and so retained customers tend to become
less price-sensitive. Brand loyalty also reduces price sensitivity.’
However, customer loyalty is decreasing and customer churn is becoming an issue. For example, in
the mobile telephone sector, churn has reached 25% p.a. in the UK and 30% p.a. in the US [8]. As a
result, there is a requirement for businesses to move from a product-focus to a customer-focus [9].
A CRM approach will enable such a transition to increase customer loyalty. Additional benefits
include ‘faster response to customer inquiries, increased marketing and selling opportunities and
identification of the most profitable customers.’ [10]
The first step in a CRM approach is to develop models as to how the business should manage the
different customer relationships. They are founded on four tenants described in [11].
1) ‘Customers should be managed as important assets.’
2) ‘Customer profitability varies – not all customers are equally desirable.’
3) ‘Customers vary in their needs, preferences, buying behaviour and price sensitivity.’
4) ‘By understanding customer drivers and customer profitability, companies can tailor their
offerings to maximise the overall value of their customer portfolio.’
These models will cover the main CRM functions of sales, marketing, service and knowledge
management [11]. Factors such as customer behaviour, customer motivation, cost of the customer
and customer involvement will determine the nature of the models [3]. The next step is to turn these
models into reality using CRM system applications as shown in figure 2 from [11].
5
Inderjit Singh
Figure 2. The CRM applications used to support the primary CRM functions
Benefits of CRM systems include a consolidated view of the customer through the use of a
centralised database. This also decreases inaccuracies and inconsistencies in data capture. In
addition, information loss due to staff turnover can be minimised by capturing the knowledge
associated with the customer within a system as opposed to with a particular sales representative.
The definition of a ‘sales cycle’ will also ensure that potential leads are not lost, as lost leads = lost
sales, and a ‘service cycle’ will ensure that the customer enquiries follow a defined process to
ensure efficient resolution and closure.
An IDC study revealed in [11] that CRM projects yield an immediate increase of 8% in revenues
and target growth of 16% in 2 years. In addition, the Insight Technology Group investigated those
CRM projects that had ‘met all expectations,’ and they achieved ‘revenue increases of up to 42%,
sales costs decreases of up to 35%, sell cycle length reduction of 25%, margin improvements of 2%
and customer satisfaction rating increases as much as 20%.’ [11]
It has been shown that CRM is not simply the latest management buzzword; there is a business
requirement for CRM with specified benefits both to the customer and the business with a tangible
impact on the bottom-line. CRM is seen as a strategic investment with advances in technology
providing further CRM capabilities. The next section will describe the main vendor offerings.
2.2 What are the main CRM vendor offerings?

The evolution of CRM systems came from two directions. Firstly, CRM was seen as a ‘natural and
predictable extension to the evolution of marketing and sales so the primitive Sales Force
Automation (SFA) systems grew to include contact management.’ [10] Examples include Siebel
and Vantive. At the same time, the major Enterprise Resource Planning (ERP) vendors who had
traditionally focused on the back-office moved into the CRM market leveraging their integration
capability. Examples include SAP and Oracle. Furthermore, the recent acquisition of Vantive by
Peoplesoft confirmed the move of ERP vendors into new markets [11].
6
Inderjit Singh
A detailed description of the offerings from Oracle, SAP, Siebel and Peoplesoft with a subsequent
comparison was provided in [12].
Through the vendor comparison, the common core functional capabilities areas were identified [12],
as summarised in Table 1. However, these are the capabilities of large-scale vendors and so need to
be tailored to the specific requirements of the SME sector. The next section will review the CRM
trends in SMEs to identify the applicability of these CRM capabilities to SMEs.
Capability Area Core Capability

Customer Data Acquisition Capture Customer Product Preferences
Selling and Sales Administration Quote Generation
Selling and Sales Administration Lead Management
Selling and Sales Administration Scripting
Customer Service Customer Contact History
Customer Service Order Status
Customer Insight Offer Packaging
Campaign Management Planning of Campaigns
Reporting Ad Hoc Querying
Customer Sales Opportunity Management
Table 1: Outline of the core capabilities within each area of CRM
2.3 What are the SME trends for CRM?

The SME Trends for CRM have been taken from [14]. Small businesses (between 50-100
employees) have been slow to move into the CRM space. CRM applications purchased have been
operationally focused and mainly for only sales and customer service capabilities. There is an
estimate of only 2-3% market penetration of CRM systems in North American small businesses.
This is due to the lack of awareness of CRM as a business strategy and the perception that CRM is
for larger businesses and is only confined to large-scale expensive implementations. Many
businesses have customer databases and simple ways of tracking interactions, and assume that this
is sufficient. In addition, the smaller customer base can provide a more intimate interaction with
customers and so the need for systems may not seem appropriate.
Of the three primary CRM functions of sales, marketing and customer service; it is sales that has the
highest demand. 40-45% of businesses rated sales as the highest priority with 30-35% of businesses
rating customer service as the highest priority.
Two types of CRM systems have emerged for small businesses. SalesLogix Quickstart [17]
represents those CRM systems that are deployed in the business in a guaranteed implementation
period e.g. 30 days. The costs of software, support, training, implementation and warranty are all
bundled in a fixed price. Alternatively, Salesforce.com [16] provide online CRM applications that
are provided to the business at a monthly cost e.g. $65/month. No software is bought or maintained
by the client and only an Internet browser is required.
For Midsize businesses (between 100-1000 employees) there is only an estimated 20% market
penetration of CRM systems for North American businesses and this penetration is industry-
focused with the concentration being in financial services, manufacturing and communications.
Midsize businesses that are purchasing CRM solutions are mainly buying sales with customer
service or marketing solutions but rarely the full CRM suite. As the midsize business sector is not
7
Inderjit Singh
homogenous, there are a variety of vendor offerings including Onyx and Pivotal that provide the
full CRM suite.
According to a report by Jupiter Research in [15], ‘Midsize companies are showing strong demand
for enterprise software, the bulk of the dollars to drive the market to the next level will come from
midsize businesses, which are more likely to invest in CRM and other enterprise-grade software.’
And Jupiter estimates the SME market for CRM to grow to about $3.4 billion by 2006.
The review of the SME trends has demonstrated that the primary focus remains on sales with
customer service capabilities, and marketing as the lowest priority. However, the prioritisation of
functions refers mainly to product-based businesses rather than service-based businesses. The next
section will provide generic data requirements to support these primary functions.
2.4 Data Requirements for SME CRM offering

The review of the main vendor offerings provided an overview of the CRM capability areas and the
functionality provided in each of these areas. The analysis of the SME market then provided an
indication as to which capability areas were relevant. Generic data requirements from a product-
based perspective will now be defined that can be used as a reference point in the requirements
analysis of the specific SMEs related to this project. However, as the main vendors are focused
upon large-scale implementations, their data requirements may be overly complex for the SME
market and as a result, those of SME CRM vendors will be used.
The user interfaces from Salesforce.com [15] and from SalesLogix [16] were reviewed for the core
capability areas of sales, service and marketing and the data required to support these user interfaces
was noted. For example, the Customer Opportunity entity and its attributes were derived from the
Opportunity Management screen in [16].
The entities noted from the user interface reviews included:

- Campaign, Customer, Customer Lead, Customer Opportunity, Customer Account, Customer
Product, Customer Contact and Customer Case and Product Ticket.
These entities support both sales and service cycle capabilities
Product Return and Defect entities were then also added to provide additional customer service
capabilities. All entities were normalised to Third Normal Form [49] and weak entities were added
to resolve many-to-many relationships. The derived data model with attributes and relations is
shown within figure 4.
8
Inderjit Singh
Figure 4. The derived data model after review of SalesLogix and Salesforce.com user interfaces for sales, service and marketing capability areas
9
Inderjit Singh
This data model identifies the main entities required within a product-based CRM system and how
these are related. An overview of the CRM functionality based on this data model is described
below.
A Campaign will result in the generation of Customer Leads. These Customer Leads can then be
followed up to generate Customer Opportunities. These concern the selling of products to the
customer. Consequently, Customer Products are associated with Customer Opportunities. Each of
the Opportunities may require several activities and the conversion of an opportunity into a sale will
require several stages. This will follow the defined sales cycle and is captured in the Opportunity
Status entity. Customer Opportunities will be related to a particular Customer Account. Information
regarding the customer is held in the Customer entity that is also related to the Customer Account
entity. Any Customer Contacts with that customer are captured in the Customer Contact entity.
Customer Cases which are customer service enquiries regarding a product, are related to the
Customer Account and each of the cases will either be opened/closed. Issues with a product are
managed by the Product Ticket entity through the service cycle and may require the return of a
product that will be captured in the Product Return entity. Additionally, a defect may be noted with
a product by the business and this will be captured in the Product Defect entity.
10
Inderjit Singh
3 P ro je c t Ma n a g e m e n t a n d Me th o d o lo g y
This section outlines the various tools and techniques used to effectively manage the project. This
includes the identification of the appropriate methodology to be used as well as the derivation of a
project plan and the creation of a project log. This log is available at
http://csiis.leeds.ac.uk/scs2is/ProjectLog.htm
3.1 P ro je c t Me th o d o lo g y
Due to the project involving both LUBS and an external business, there was an added emphasis on
managing the project to deliver value to both parties and to minimise risk. The software
development methodology used would have to complement the management of the project in this
way. The information systems development life cycle [33] was not appropriate, as it does not
actively address risk within the project and risk increases as the project continues [26].
Boehm’s spiral model [32] as shown in figure 5 provides a risk-management evolutionary approach
to software development.
Figure 5. Boehm’s Spiral Model of evolutionary development
The risks of the project are addressed, however, the iterative review of the previous stages may lead
to inefficiencies in time within the development process and so it did not seem appropriate within
the timescales of this project.
The Rational Unified Process [31] as shown in figure 6, however, defines a set of core workflows
that can be performed in parallel as well as iterated as a set through different phases of the project.
The early inception and elaboration phases of the process focus upon the business modelling and
requirements capture and manage risk through the establishment of a proof-of-architecture while the
latter phases of construction and transition focus more upon the implementation and testing.
11
Inderjit Singh
It was chosen for this project due to the consistency provided by the artefacts within each workflow
and its emphasis on establishing the proof-of-architecture early on. In addition, it provides
flexibility for iteration between workflows. In this way, following RUP provides a use-case driven,
architecture-centric, iterative and incremental approach [34].
Figure 6. The Rational Unified Process defining the core workflows and the development phases.
3.2 P ro je c t P la n
Within the project, the initial assumption was that the business would provide requirements that
would be discussed and confirmed to then lead onto subsequent development. The initial project
plan reflected a sequential development plan through each workflow with the completion of a
workflow as a milestone that the business would then validate. The initial project plan to develop
the CRM system is shown in Table 2. The final week was left as contingency.
Stage W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13

Reqs
Analysis
Design
Build Holiday
Test
Write-
Up
Table 2. The Initial Project Plan based upon sequential development
12
Inderjit Singh
4 De fin in g th e Bu s in e s s P ro b le m
To determine the nature of the development in the project, the specific problem to be tackled within
the project had to be defined. This relied upon first defining the problem for the business by
investigating the business itself and then understanding their requirements.
4.1 Un d e rs ta n d in g th e Bu s in e s s a n d the Bu s in e s s Co n te xt
The specific SME that formed the basis of the project was Harland, Turball and Roberts (HTR) who
are a small-to-medium sized law firm. They have 5 offices located within East Yorkshire that
mainly focus upon providing conveyancing services, although probate, will and personal injury
services are provided on an ad-hoc basis. They employ about 20 staff and have approximately £1
million turnover pa.
Strategic analysis had been conducted by LUBS upon the legal SME market as shown in Table 3
[19] using Porter 5 Forces model [18].
Bar r ier To Entr y Rating Rationale
o Economies of scale LOW o No national chain
o Product differentiation o No brand or recognised Quality mark
o Access to distribution channels o Potentially sharing the same customer base
o Government policy o De-regulation plans
o Competitor reaction o Fragmented industry
Bar gaining Power of HIGH Rationale
Supplier s o Only 3 suppliers
o E-conveyancing information
search
Bar gaining Power of Buyer s HIGH Rationale
o Ability to play competitors off o Fragmented industry with lots of choice
o Undifferentiated o Standardised products & services
products/services o On commodity products and services
o Price not quality decisions o Where errors in judgement can be costly
o Quality oriented o Low mobility barriers
o Switching costs
Thr eat of Substitute Pr oducts HIGH Rationale
or Ser vices
o Products o (Low) standardised/undifferentiated
o Services products
o Bundled offerings from new entrants
o New delivery mediums
o Multi-channel access
o Branded, trustworthy & credible
o Internet expands the market size
Rivalr y Amongst Existing HIGH Rationale
Competitor s
o Numerous competitors o Over 10,000 firms in the UK
o Service lacks differentiation o Offering is difficult to keep proprietary
o Service has low switching costs o Difficult to protect raids on customer base
o Rivals are diverse in strategies o Due to a focused approach to offering
selected legal services
Table 3. Summary of the Industry Forces within the Legal Services Market
This gave an indication of the competitive forces faced by the business. The legal SME market is
shown as highly competitive, containing many businesses with undifferentiated service offering and
13
Inderjit Singh
price. This demonstrates the potential benefit that could be gained by embracing CRM to provide a
differentiation in service and hence competitive advantage.
4.1.1 Defining the ‘Product’ Offered

The focus of the main CRM vendors and that of the background review was upon product-based
business where the core offering is goods. However, the SME chosen for the project provides
services as it core offering i.e. ‘conveyancing’ that is a standardised process across all legal firms.
4.2 Diffe re n t Ap p ro a c h fo r S e rvic e -Ba s e d CRM

It has been stated that the SME is service and not product-based. ‘There is a general agreement that
inherent differences between goods and services exist’ [20]. The differences have been summarised
in [20]
• Intangibility – services are performances/actions rather than objects and cannot be
seen/touched/tasted in the same way as with tangible products.
• Heterogeneity – services are performances that are usually produced by humans, so the
services produced are not exactly alike while there is a focus on the homogeneity of
products to provide a consistent offering.
• Simultaneous Production and Consumption - services are provided and consumed at the
same time while products are produced and then only consumed at a later stage. The
customer may actively take part in the delivery and consumption of the service and affect
their own experience.
• Perishability – services cannot be stored, saved or resold unlike products that can have
inventory and be resold if the product was initially incorrect. Once a bad service is
provided, it cannot be returned or resold like that of a product.
This has implications for the manner of handling the customer interactions through CRM and has
led to an expanded marketing mix for service-based businesses that includes people, physical
evidence and process in addition to the traditional product-based marketing mix of product, place,
promotion and price. [20]. Consequently, it is suggested that product-based businesses are more
suited to a transaction-type strategy while service-based businesses would be better off pursuing a
relationship-type strategy [21].
This focus on personal relationships and the fact that the process of delivering the service is
intrinsic to the service itself lead to the foundation of the two main concepts within service-based
CRM. These are Relationship Marketing and Service Quality.
4.2.1 Relationship Marketing

Emphasis is required upon the establishment of relationships both with the customer and with other
parties that impact the overall satisfaction of the customer. As the interaction of customer, employee
and other parties is intrinsic to the service delivered and therefore the customer satisfaction with the
service, relationship marketing highlights the need for ‘building relationships with customers rather
than creating exchange processes.’ [22]
In addition, it demonstrates the greater importance of referral markets to service-based CRM than
product-based ‘where word-of-mouth recommendation can be the key factor in the consumer
decision process.’ [22] Additional emphasis is also required on dealing with existing customers as
they can be the best source of referrals, so it must be ensured that they have high customer
satisfaction.
14
Inderjit Singh
4.2.2 S e rvic e Qu a lity

Quality is defined as ‘zero-defects – doing it right the first time.’ [23] However, knowledge of
‘goods-quality’ is not sufficient to understand ‘service-quality’ as it does not take account of
intangibility, heterogeneity and inseparability. Service Quality is defined as a ‘measure of how well
the service-level delivered matches customer expectations.’ [23]
Developing and delivering service quality is paramount for a service-based business as defined in
[22].
• Organisations with a reputation for consistently high quality can sustain an enviable
competitive advantage in the service marketplace
• Quality is ‘free’ – getting it right first time costs far less than providing remedies when
services fail to meet customer expectations
• Better quality services can attract premium prices
Consequently, service quality has a direct impact upon the profitability of service-based businesses.
The gaps model of service quality as shown in figure 7 describes the concept of service quality and
the factors that affect it that have found to be consistent across various service-based business
categories. [23]
Figure 7. The Service Quality Gap Model
Within the model, 5 gaps are identified involving the consumer and the marketer (the business).
[23]
1. Consumer expectation-management perception gap – the gap between what the customer
expects and what management think the customer expects
2. Management perception-service quality specification gap – the gap between what
management thinks the customer expects and the quality of the service specified
3. Service quality specifications-service delivery gap – the gap between the service quality
specified and the service actually delivered
4. Service delivery-external communications gap – the gap between the service actually
delivered and that suggested in the media
15
Inderjit Singh
5. Expected service-perceived service gap – the gap between the service expected by the
customer and that perception of the service delivered to the customer
The service quality as perceived by a consumer is gap 5 and this is a function of the other 4 gaps.
[23]
Perceived Service Quality = Gap 5 = f{GAP1, GAP2, GAP3, GAP4}
The provision of this service quality by a business relies on identifying gaps in both the internal
service quality and the service delivery quality. [22] Therefore, the examination of HTR regarding
their service quality must focus on both these areas and identify if the defined gaps are relevant to
the legal sector.
4.3 Un d e rs ta n d in g o f th e Re q u ire m e n ts
An understanding of the current CRM capability of the business was required to begin to
understand the relevant CRM requirements. Stakeholders were identified at the different offices and
several interviews were conducted regarding the current business processes, use of IT and potential
improvements. In addition, sample documents used were obtained as well as observation of current
working practises. This followed the SQIRO (Sample Document, Questionnaires, Interviews,
Reading and Observation) techniques for investigating requirements [26].
The firm had recently installed a case-management system- DPS [27] within the main office at Hull.
The system was expected to support the employees in managing customer cases and automatically
generating required legal forms and letters. However, it was only used to generate legal forms and
managing of the case still relied on the hard-copy case file as well as the knowledge of the specific
legal employee. In addition, the system was only installed at the main office so case management at
all the other offices required manual legal form generation which provided additional process
inefficiencies in addition to the reliance on the hard-copy case file.
An econveyancing system had also been installed within the Beverly office for serving Halifax
Estate Agent customers referred to HTR. The ‘Total-Absolute’ system enabled econveyancing
customers to view the status of their cases online at any time. However, as these cases were not
entered onto the DPS system, no DPS functionality could be used so legal forms and letters had to
be manually created. In addition, once cases were closed on Total-Absolute, the customer
information was lost so no historical information could be maintained. Conversely, conveyancing
customers whose cases were not captured on the Total-Absolute system could not view the status of
their cases online and relied on telephone interaction.
In conclusion, the current use of IT demonstrated that customers were receiving a different level of
service depending upon the office that their case was held at and/or if they were an econveyancing
customer. This has a damaging impact upon the perceived service quality due to the difference
between service-quality specified that was homogenous for all customers, and the actual service-
delivery that was not. This relates to Gap 3. [23] In addition, due to no historical econveyancing
information being captured, there was no potential for establishing strategic benefits through long-
term relationships with these customers even though ‘the longer established the relationship, the
more clients view the benefit of the relationship to them in terms of confidence.’ [25]
A Business Activity Model was then created of the current conveyancing process as shown in figure
8.
16
Inderjit Singh
Figure 8. Business Activity model for the conveyancing process
The swimlane activity diagram highlights the system swimlane that demonstrates the number of
activities performed by the system in the process. The process is complicated and so the purpose of
the diagram was not to highlight each of the activities but to demonstrate that few activities are
done by the system, as the system was not currently used to drive the process.
17
Inderjit Singh
The extent of the service quality gaps identified and the lack of a system-driven process were
discussed with LUBS. [28] It was highlighted by LUBS that both the quality gaps and this lack of
system-focus was due to the business having little understanding of CRM, its benefits and how
technology can support CRM. Demonstration of the inadequacies in the current use of IT with
suggested improvements would have to be shown in conjunction with the establishment what CRM
is, its relevance to the firm and of the advantages of CRM.
4.4 De fin e th e P roje c t P ro b le m

After using requirements investigation techniques and discussing the business’s current
understanding of CRM with LUBS, the problem that the project was to address was defined in two
stages. This initial stage would confirm that the business understood ‘why’ CRM was important and
how it related to the business. This would include
• Explaining what CRM is
• Explaining the advantages of CRM to the business
• Defining how CRM applies to the conveyancing process
Validation by the business would ensure their commitment to the second stage of the problem in
determining ‘how’ these advantages could be realised through business benefits. This would
include
• Defining the Service Quality Gaps
• Defining the Business Benefits
• Providing the Functional and Data Requirements to realise the benefits
The background literature review in chapter 2 indicated that competitive advantage can be gained
through CRM, and in this sense, it is a strategic information system. [30] However, strategic
systems rely upon the information captured from tactical and/or operational systems as defined by
Anthony’s Hierarchy of Applications [18] and shown in figure 9.
Figure 9. Anthony’s Hierarchy of Applications
The investigation of the current business processes and use of IT showed a lack of adequately
meeting user demands due to process inefficiency demonstrated by the manual creation of legal
forms, and process ineffectiveness demonstrated by the lack of conveyancing status information.
Consequently, the service quality gaps in tactical processes that are ‘based upon user demands’ [30]
must be addressed first. This will then allow the development of strategic processes ‘providing
competitive advantage.’ [30] These together would result in the overall CRM benefits to the
business.
18
Inderjit Singh
4.5 Id e n tifyin g th e Bus in e s s Be n e fits

Throughout the project, maintaining the value of the project to the business was paramount. The
traditional focus of software engineering only regards the identification of requirements and the
extent that the requirements are met and does not relate them to business benefits. Consequently, a
Benefits Management approach was adopted as an extension to the RUP as shown in figure 10 as
the ‘existing RUP is light on benefits identification and on benefits realisation.’ [26].
Figure 10. Adoption of a Benefits Management Approach as an extension of the RUP

The approach involves identification of the high-level investment objectives and the business
benefits. Both the business and enabling changes required to achieve the business benefits are then
identified. Consequently, the IS/IT requirements can be derived to support the business and
enabling changes. This was represented within a Benefits Dependency Network [30] as shown in
figure 11 that was validated by LUBS in [28]. The benefits and changes specified were based on the
background research conducted in chapter 2.
Figure 11. Benefits Dependency Network of CRM for HTR

19
Inderjit Singh
The overall objectives included support more profitable customers and expand the client base. By
identifying the profitability of client and increasing the levels of customer service, this would
achieve the first objective. By improving the response rate from marketing campaigns and
increasing the rate of conversion, this would achieve the second objective.
4.6 Bu s in e s s Mo d e llin g
Once the business benefits were identified, the artefacts of the Business Modelling workflow [31]
were used to represent the value propositions to the business in terms of Business Use Cases as
shown in figure 12. CRM would allow the business to understand the customer better. It would also
improve the customer service provided to the customer. These in combination would then allow the
business to service a better quality customer.
Figure 12. Business Use Cases demonstrating value to the business of CRM
4.7 Va lid a tio n o f th e P ro je c t P ro b le m

A consistent issue throughout the project was the lack of exposure to the main stakeholders i.e. the
business partners. As a result, the primary meeting with the partners served as confirmation of the
current business situation and problems to be addressed in the project as opposed to elicitation of
the business situation and derivation of the project problem. A presentation that is included in
Appendix E was delivered.
The presentation covered
• A definition of CRM [2]
• The benefits of CRM in the legal industry
• The strategic (competitive advantage) and tactical (process efficiency and effectiveness)
advantages of CRM to the business
• The value propositions of CRM shown in the Business Use Case diagram (figure 12)
• The business and IT changes required to realise the benefits shown in the Benefits
Dependency Network (figure 11)
The current lack of integrated business processes and use of IT was also highlighted to the business.
The partners agreed with the contents of the presentation and there was an appreciation that both
tactical and strategic requirements needed to be addressed, although the focus would be on
supporting more profitable customers and not expanding the client base due to the constraints in the
size of the business. It was also noted that it would not be a simple process of implementing the
requirements into the current systems, as both systems were vendor systems. As such, it was agreed
that the project would elicit the relevant and required functional requirements that could then be
20
Inderjit Singh
taken to the vendors to implement. [28] In addition, due to lack of access to the data models of the
vendor systems, the focus changed from producing a data model to support all aspects of the
conveyancing process to those specifically related to CRM. Consequently, the objectives of the
project as defined in section 1.1.1 were still applicable but the focus was to derive the CRM
requirements of the business as opposed to implementing a proof-of-concept system that would
become operational.
This phase of the project established the business case of CRM for HTR through the use of the
business and requirements workflows of RUP and the addition of the Benefits Management
approach. As such, establishment of the business case and feasibility of the project represents the
completion of the inception phase of RUP [34] where the focus is mainly upon the business and
requirements workflows as shown in figure 13.
Figure 13. Focus of the Inception Phase of Business Modelling and Requirements
4.8 Im p a c t o n P roje c t Ma n a g e m e n t
Due to the new focus of attempting to elicit and validate the relevant requirements, it was agreed
with the business that the optimum way to derive the functional and data requirements would be
through scenario-based demonstrations. These would show how the functionality would be used to
support a particular process. The use of scenarios is an established method as ‘scenarios have been
widely used and documented in object-oriented design and user interface design as a technique to
elicit and validate requirements.’[46]
This would allow the focus of the business and LUBS to be on one scenario at a time to ensure that
the value and relevance was established. Also it would minimise risk in development by
implementing distinct functionality for each scenario. In addition, not all requirements would have
to be defined at the beginning which would allow strategic scenarios to be defined that evolved
from the tactical ones. Consequently, the project schedule was changed from week 3 onwards as
shown in Table 4 to reflect iterations through the workflows of the elaboration phase for each
scenario. It also allowed working on parallel workflows of different scenarios. At the end of the
elaboration phase, this would ensure a stable proof-of-architecture prototype and enable the
business to begin the construction phase of RUP. [34]
21
Inderjit Singh
Stage W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13

Project
Reqs
Sc1
Reqs
Sc2
Reqs
Sc3
Reqs
Sc1
Analysis
+Design
Sc2
Analysis
+Design
Sc3
Analysis
+Design
Sc1
Build
Sc2
Build
Sc3
Build
Sc1
Test Holiday
Sc2
Test
Sc3
Test
Sc4
Reqs
Sc5
Reqs
Sc4
Analysis
+Design
Sc5
Analysis
+Design
Sc4
Build
Sc5
Build
Sc4
Test
Sc5
Test
Write-
Up
Table 4. Revised Project Plan that follows iterations through the workflows for each
scenario and working on parallel workflows for different scenarios.
22
Inderjit Singh
5 Ap p ro a c h in P ro d u c in g a S o lu tio n
For each scenario developed, this would constitute an iteration through the core workflows in the
elaboration phase of RUP. This section will summarise the artefacts used to ensure consistency
within the development process.
5.1 Re q u ire m e n ts Wo rkflo w

Through the inception phase the Business Use Cases had been derived. However, due to the lack of
insight into the business, a Business Object Model could not be created that could be ‘used to define
the business use cases from an internal’s worker’s viewpoint.’ [26] The Business Object Model
allows the analyst to derive the system use cases (functionality of value) required to support the
roles of the business workers. In this project, due to the absence of this model, system use cases
were derived from the overall functionality needed to support the tactical and strategic advantages
that had been presented to the business.
Use cases and the system architecture to support the use cases are related as ‘every product has both
form and function.’ [34] Consequently, development of use cases and the architecture must occur in
parallel. To this extent, the completion of the first scenario established the architecture and hence
mitigated the main risk to the project. Additional artefacts such as User-Interface Storyboards [31]
that showed the screen flow were also used to define the process followed in the scenario. However,
Use Case Description Forms that describe the different paths in a use case were not created as only
the basic flow of a use case was demonstrated and not the exception or alternative paths. This basic
flow was provided by the use case storyboards.
5.2 An a lys is a n d De s ig n Wo rkflo ws

From the System Use Cases, Use Case Realisations artefacts were derived that ‘describe how a
specific use case is realized and performed in terms of analysis classes and their interacting analysis
objects.’ [34] Also, during the design of the first scenario, an architecture was selected not only to
support the object-oriented analysis but one that also met the initial project requirements of being
open-source.
The entity classes derived within the use case realisation that were persistent data entities were
represented in the data model, the control classes represented the functionality in the application
layer and the boundary classes represented the presentation layer. As each subsequent realisation
was created, the relevant classes were identified to construct a conceptual-level class diagram
artefact. However no interfaces classes were defined, as the development was not intended for a
proof-of-concept system implementation that would become operational. In addition, data entities
were added to the data model using entity-relationship modelling with weak entities added if
required.
5.3 Im p le m e n ta tio n a n d Te s t Wo rkflo ws

The creation of the 3-tier architecture facilitated implementation as the boundary classes
represented the browser-based front-end and the entity classes the underlying data model. The
control classes were implemented in an object-oriented language in the application layer to provide
consistency between the analysis, design and implementation.
Each object created was unit tested as part of the implementation workflow activities [31]. Also, a
test use case artefact was created that represented the flow of events of the scenario to test that the
functionality of the each of the scenarios produced was correct [26].
23
Inderjit Singh
6 P ro d u c in g a S o lu tio n – Tactical
The current conveyancing process is both inefficient due to manual creation of legal forms for
econveyancing cases, and ineffective due to a lack of system provided case status. Consequently,
there are quality gaps at a tactical level by not being able to meet user demands. Changes required
to address the quality gaps in order to achieve the tactical business benefits were specified in the
Benefits Dependency Network (figure 14). The required changes included improve business process
efficiency and provide customer history and up-to-date customer information. These would provide
the benefits of improving customer retention and increased levels of customer service.
Consequently, the focus of the scenarios was upon identification of the service quality gaps that
once mitigated would deliver these benefits and the functionality specified would support the
changes to address these gaps.
Figure 14. Benefits Dependency Network highlighting the Tactical Benefits and Required Changes
To further enable the identification of service quality gaps within the business, 10 service quality
determinants have been defined that apply regardless of the type of service. [23] These include
1. Reliability 6. Communication
2. Responsiveness 7. Credibility
3. Competence 8. Security
4. Access 9. Understanding/Knowing the Customer
5. Courtesy 10. Tangibles (physical evidence)
Each of the scenarios will be discussed as an iteration through the core workflows of RUP. Each
scenario will demonstrate functionality of the system and as such will be represented by a system
use case as shown in figure 15.
24
Inderjit Singh
Figure 15. CRM System Use Cases
6.1 S c e n a rio 1 – Integrate New Customer Case Creation

The investigation from the inception phase of the project highlighted the different service provided
in the creation and maintenance of conveyancing and econveyancing cases. The focus of this
scenario is upon integration of these processes as well as the definition of the underlying
architecture to support this functionality.
6.1.1 Re q u ire m e n ts
The following service-quality gaps were identified relating to the current business processes and use
of IT regarding new customer cases.
• The econveyancing process requires manual creation of legal forms while these are system-
created for conveyancing cases. This is an example of the service quality specifications-
service delivery gap (Gap3) as the service quality specified is the same for both cases but
due to the current use of IT, the service delivery is not the same.
• No historical data is captured regarding econveyancing cases as when closed, all customer
and case information is lost.
• There is no system recognition if the customer is a new/existing customer. Again, the
reliance is upon a manual process or employee knowledge.
Both of the latter points are examples of the consumer expectation-management perception
gap (Gap1) due to expectation by existing customers of recognition as part of relationship
marketing and of the Understanding/Knowing the customer service quality dimension that
includes the requirement of ‘recognising the regular customer.’ [23]
The requirements relate to how the service-gaps can be mitigated. These include
• Capturing of econveyancing cases and cases on the case management system allowing
o econveyancing historical data to be captured
o econveyancing cases being able to automatically generate legal forms
This would ensure the same level of service delivery, as all cases would be created on the
same system.
• Recognition of new/existing customers and providing of a quick customer summary
This would satisfy the expectation of existing customers to be recognised.
25
Inderjit Singh
The changes will result in improved business process efficiency and the integration of conveyancing
and econveyancing cases into a homogeneous process by storing information electronically. These
are changes specified in the Business Dependency Network to achieve the business benefits (figure
14).
6.1.2 An a lys is a n d De s ig n
The functionality to support these requirements included:
• Checking if there was an existing customer record in the database
• Capturing product type information i.e. conveyancing/econveyancing cases
• Creating and maintaining new conveyancing and econveyancing cases
• Querying the database to provide a customer summary
The use case realisation of this scenario is shown in figure 16 in Appendix D that displays the
boundary, control and entity classes required to provide this functionality. It also defines the process
flow for the implementation of the scenario.
The functionality initially checks if the customer is a new/existing customer. The product type
information is then captured depending upon the type of customer case. Further information
regarding property and estate agent information provided by the user is also captured and added to
the customer case information. At the end of the process, a customer summary is provided based
upon the information inputted by the user. An explanation of the functionality in terms of the
classes created is provided in the subsequent paragraph.
The CaptureClientDetails control class initially checks if the customer is an existing or new
customer and creates a new customer case and adds the CustomerID to this case. The
AddProductType control class determines whether the case is a conveyancing or econveyancing
case and updates the coveyancing_customercase entity class with the ProductTypeID. The
subsequent control classes gather data entered by the user regarding the case and update the relevant
entity classes including the property and estateagent classes as well as updating the
conveyancing_customercase entity class with the relevant record IDs. The
ProvideCustomerSummary control class then retrieves the relevant case information entered which
is displayed by the CustomerSummary boundary class.
6.1.3 Arc h ite c tu re De fin itio n

Part of the development of the first scenario was the establishment of the proof-of-architecture. The
project specification stated an open-source browser-based database-centric system. [1] The
possibilities included MySQL or PostgreSQL as the open-source DBMS and PHP or Java Server
Pages (JSP) as the open-source scripting language. The use of either PHP or JSP would allow
consistency to be ensured between analysis, design and implementation as RUP provides object-
oriented analysis and design but it does also have the potential for forward-engineering into Java
code [31]. In addition, in relation to project management, if implementation of a scenario could not
be completed, the analysis and design artefacts created would mean that the effort in future
implementation into JSP would not be great as for PHP. These factors in combination with the
previous experience in Java meant that JSP was chosen.
MySQL was selected due to its popularity of uptake and potentially extensive support network in
addition to the ability of running the database in a production Windows environment. [35] It does
not support transaction control as in PostgreSQL but for this project concurrent transactions were
not necessary. In addition, the lack of referential integrity was not seen as an issue as access to the
26
Inderjit Singh
database occurred through only one interface and the integrity could then be ensured through this
interface. The architecture is shown in figure 17.
Presentation Layer (HTML)
JSP
Application Layer (Java Beans)
JBDC
Database Layer (MySQL)
Figure 17. Three-tier architecture supporting the CRM functionality
6.1.4 Im p le m e n ta tio n
The implementation of the functionality specified within the use-case realisations also incorporated
designs from the use case storyboard artefacts as well as following usability heuristics including
consistency, readability and efficiency. [36] A screenshot from the scenario displaying the customer
summary is shown in figure 18. All screenshots produced throughout all the scenarios are included
in Appendix F.
Figure 18. The Case Summary screen
6.1.5 Te s tin g
Testing of the implementation occurred in two stages. Firstly as each JSP and the Java Beans it
called were constructed, each was unit tested to ensure that the input and output were correct. In
addition, as the use case realisation defined the basic flow of events, it was used as the test use case
to test the set of JSPs and Java classes created. This ensured that the functionality specified in the
design was actually implemented. This same method of testing was applied to all scenarios. By
successfully implementing the first scenario, this had also confirmed the open-source proof-of-
architecture and so mitigated one of the main project risks.
27
Inderjit Singh
6.2 S c e n a rio 2 – Provide Service Cycle

The establishment of a service cycle is central to providing any level of customer service by being
able to track the stage that the customer has reached within the cycle and to capture any issues
raised to ensure that they are addressed [47]. The scenario focuses on the lack of a defined service
cycle in the business.
The following service quality gaps were identified in relation to providing a service
• Customer cases were only handled by the case owner and knowledge was not available
regarding the progression of the case
• Limited case status information was held electronically. Customer interactions could be
captured but these were not related to any specific stage.
• No capture of issues relating a case and when/how the issue was resolved.
This lack of service quality impacts the consumer expectation-management perception gap (Gap1)
in the difference between the customer expectation of the promptness and accuracy in retrieval of
case information and lack of understanding by management of this expectation. Also, the
management perception-service quality specification gap (Gap2) exists due to the lack of specifying
how event and task information that is available on DPS should be captured.
The requirements relate to how the service-gaps can be mitigated. These include:
• Providing customer history and up-to-to-date customer information
Identifying this requirement ensures management has understanding of the customer
expectation.
• Enabling authorised employees to provide case status to the customer
• Capturing of issue and issue management of the resolution of issues
All the requirements ensure that the service quality specified meets the newly understood
management expectations.
This will increase levels of customer service through process effectiveness. Again, the requirements
listed are consistent with those changes specified in the Benefits Dependency Network (figure 14).
• Retrieval of customer case information from the database
• Capturing and updating case stage information
• Capturing and updating case issue information
• Capturing Branch and Solicitor information (As relationship marketing is more important in
service-based CRM, it is important that the specific employee is noted as opposed to
capturing the customer contacts as in a product-based CRM.) [22]
boundary, control and entity classes required to provide this functionality. It also defines the process
flow for the implementation of the scenario.
The functionality initially retrieves a case summary based upon customer forename and surname
information entered into the search. The case status information is then retrieved including the
completed stages, the uncompleted stages that have associated issues and the uncompleted stages
with no associated issue. The set of process stages retrieved will depend upon the type of customer
case e.g. purchase or sale. An issue can be added to each stage that can be viewed and updated at a
later stage. As this is system-driven, any authorised user can provide this status to the customer
28
Inderjit Singh
without requiring prior knowledge of the case and can add/update case issues. Again, the scenario
demonstrates the need to remove case-specific information held by the individual and capture this
information into a system. An explanation of the functionality in terms of the classes created is
provided in the subsequent paragraph.
The ProvideCustomerSummary control class retrieves the relevant information to provide the
customer summary. To view the case status, the StatusInfo control class retrieves those stages of the
relevant sales/purchase process that have been completed, those that have not yet been completed
but have an associated issue and those that have not yet been completed and do not have an
associated issue. Issues can be added through the IssueAdd control class and can be updated through
the IssueUpdate control class. They are retrieved in the IssueInfo control class to be displayed by
the DisplayIssue boundary class. The status of the process stages can be updated through the
StageUpdate control class.
6.2.3 Im p le m e n ta tio n a n d Te s tin g

The implementation of the functionality followed the specification within the use-case realisations.
A screenshot from the implementation of the scenario displaying the status screen for the sales
process is shown in figure 20. All screenshots produced throughout all the scenarios are included in
Appendix F. Unit tests were executed on each JSP and the Java Beans it called. In addition, as the
use case realisation defined the basic flow of events, it was used as the test use case to test the set of
JSPs and Java classes created.
Figure 20. The Status and Issues screen providing a system-driven Service Cycle
6.3 S c e n a rio 3 - Re d u c e S e a rc h Tim e

An important part of the conveyancing process is the searches undertaken regarding the property.
Currently, the forms are created on the case management system and then sent to the third parties.
However, the process of receiving the searches can take days or weeks and involves significant
resources in chasing up the search process. The focus on the scenario was upon demonstrating how
process efficiency can be gained through online searching.
29
Inderjit Singh
The current search process is not only labour intensive and so requires significant resources, but the
reliance on an inefficient process creates a gap between management’s view of the customer
expectation of an efficient service and the actual service specified i.e. the management perception-
service quality specification gap (Gap2).
As part providing additional value to the business, a 3rd party vendor - NLIS Searchflow [37] was
found that could provide online searching functionality and that had already been integrated with
the core DPS case management product.
The requirements of the scenario were then related to how the service-gap could be mitigated using
NLIS Searchflow. These included features of the software to provide online searching:
• Submitting and tracking searches online
• Establishing integration between DPS and NLIS Searchflow
• Identifying the relevant searches for the specific customer property
This would ensure that the service quality specified matches management’s view of the customer
expectation. It will improve business process efficiency and so improve customer service while
reducing the resources required. This is a change specified in the Benefits Dependency Network to
achieve the business benefits (figure 14).
The functional requirements specified within the scenario reflected the functionality of NLIS
Searchflow in order to demonstrate to the business how online searching would work.
They included
• Creating a customer search instruction
• Validating the customer address
• Allowing the user to define the property boundaries using maps
• Selecting the searches relevant to the property
• Being able to review the search instruction
boundary, control and entity classes and their responsibilities required to provide this functionality.
It also defines the process flow for the implementation of the scenario.
The functionality initially retrieves a case summary based upon customer forename and surname
information entered into the search. The specific property information relating to the customer case
is then retrieved and confirmed by the user. Through the confirmation, a search instruction for that
property is created and a map of the property is then retrieved. The user then outlines the property
boundary in order to define the searches appropriate to that property. The searches are then
retrieved and the user selects the relevant searches and the complete information regarding those
selected searches is then displayed. An explanation of the functionality in terms of the classes
created is provided in the subsequent paragraph.
The ProvideCustomerSummary control class retrieves the relevant information to provide the
customer summary. The details of the property are then retrieved from the property entity class by
the ConfirmSearchDetails control class and the user confirms that these are the correct property
details. A search instruction is then created by the CreateInstruction control class and is added to
the searchinstruction entity class. The ordnance map associated with that property is then retrieved
by the RetrieveMapInfo control class and is displayed by the PropertyMap boundary class. The user
then selects the relevant property boundary and this is captured within the
30
Inderjit Singh
CaptureOutlinedMapArea control class. The different search types relating to the property are then
retrieved by the DisplaySearches control class from the onlinesearchtype entity class and displayed
by the SearchTypes boundary class. The user then selects the required search types that are captured
in the SelectedSearches control class that then updates the searchinstruction entity class with those
search types. The full information regarding the selected search types is then displayed by the
FullSearchTypeInfo boundary class.

However, ordnance map retrieval could not be implemented, as this functionality is part of a vendor
package, so instead a demonstration of how the functionality would work was provided to show the
business how process efficiency could be achieved. A screenshot from the implementation of the
scenario displaying selection of the property boundary is shown in figure 22. All screenshots
produced throughout all the scenarios are included in Appendix F. Unit tests were executed on each
JSP and the Java Beans it called. In addition, as the use case realisation defined the basic flow of
events, it was used as the test use case to test the set of JSPs and Java classes created.
Figure 22. The Selection of Property Boundaries screen
Through the development of the three tactical scenarios, functional requirements have been derived
to support the enabling and business changes in the Benefits Dependency Network (figure 14) that
will allow the business to realise the business benefits. The emphasis on system-driven processes
will provide reliability, responsiveness and assurance that are deemed the most important
dimensions of overall service quality [39].
31
Inderjit Singh
7 P ro d u c in g a S o lu tio n – Strategic
The strategic advantages highlighted to the business related to establishing competitive advantage.
The inception phase demonstrated the inadequacy of the tactical situation of the business that had
led to the business consequently having no current strategic capability. It was shown through
Anthony’s Hierarchy of Applications (figure 9) that the strategic advantages could only be realised
once the tactical functional requirements had been derived. These functional requirements were
ascertained through the tactical scenarios described in the previous chapter.
As there were no current strategic capabilities, the service quality gap model could not be used to
assess the current situation. Instead, capabilities were gleaned from the literature that could provide
the strategic business benefit of identify profitability of clients as specified in the Benefits
Dependency Network. These included capture of inbound referrals [24] and of customer
segmentation to identify profitable customers [38]. A meeting was set up with the business partners
that confirmed the relevance of these strategic capabilities to the business and how they would aid
the business in realising the business benefits of CRM [28]. These capabilities supported strategic
changes such as analyse customer transaction information and better understand customer
requirements highlighted in the Benefit Dependency Network shown in figure 23.
Figure 23. Benefits Dependency Network demonstrating the business and enabling changes
required to realise the strategic business benefits
7.1 S c e n a rio 4 – Capture Inbound Referral Information

The business confirmed that the majority of new clients come through referrals and that the main
referrer types are financial advisors, estate agents or existing customers. However, there was
currently no information captured about who had referred a customer and so no insight at a strategic
level to define the most profitable referrer types or referrers.
The importance of establishing relationships with referrers is demonstrated in the literature. In

addition to the customer, ‘the aim of relationship marketing is to build relationships with all the
32
Inderjit Singh
organisation’s publics.’[22] This includes both relationships with channel members but also the
referral markets. [22] ‘Word-of-mouth is seen as part of the marketing communications mix….and
studies in professional services have indicated that it can have a more influential impact than the
usual promotional mix.’ [24] Customers rely on secondary clues in selecting a service including
‘reliance on referrals from another professional and dependence on trusted personal sources.’ [24]
The focus on the scenario was upon the establishment of an inbound referral network to begin to
allow relationships to be formed with the most profitable referrers/referrer types.
There was a requirement to capture inbound referral information and also a requirement of
capturing of the transaction value as currently all customers were charged the same amount
irrespective of the time and cost to the business in dealing with the case.
The identification of the most profitable referrer/referral types for different customer segments
would ultimately allow the business to support more profitable customers as defined in the Business
Dependency Network (figure 23).
Part of a project undertaken by LUBS involved the definition of customer segments appropriate to
the business [40] and it was this set of segments that was used for the scenario. In addition, the
conveyancing instruction types were specified by LUBS.
• Capturing the transaction value of the customer
• Capturing the referral type and referrer of the customer (including existing customers)
• Capturing the customer segment
• Capturing the conveyancing instruction information
• Creating referral reports by segment, instruction or referral type
boundary, control and entity classes and their responsibilities required to provide this functionality.
It also defines the process flow for the implementation of the scenario.
information is then captured depending upon the type of customer case. Conveyancing instruction
information is then displayed relating to the different types of instruction e.g. first-time buyer, sale
or purchase. The user then selects the relevant instruction. The instruction information selected is
added to the customer case and the different customer segments are then displayed. The user selects
the relevant segment of the customer and this information is added to the customer information. The
different referral types are then displayed e.g. financial advisor, estate agent etc. and the user selects
the relevant referrer type and enters the name of the referrer. This referral information is then
captured and this is added to the customer information. Referral reports can then be viewed by
segment, instruction or referral type. The chosen report is displayed and can be ordered by referral
name or referral type. An explanation of the functionality in terms of the classes created is provided
in the subsequent paragraph.
The customer case is created as stated in the tactical scenario1 (section 6.1). The conveyancing
instruction information is then retrieved by the ConvInstructions control class and is displayed by
the InstructionTypes boundary class. The user selects the relevant instruction type that is captured
by the DisplaySegments control class which then updates the conveyancing_customercase entity
33
Inderjit Singh
class. The class then retrieves the customer segments from the customersegment entity class that are
displayed by the SegmentType boundary class. The selected segment is captured in the ReferralType
control class that then updates the customer entity class with this segment information. The control
class then retrieves the different referral types from the inboundreferral entity class that are
displayed by the DisplayReferralType boundary class.
The selected referral type is captured in the ConfirmReferral control class and this updates the
customer entity class with the referral type. It then retrieves the different referral report types that
are displayed by the DisplayReportTypeOptions boundary class. The user then selects the report
type that is captured by the RetrieveReportType control class that then retrieves the relevant report
information. The report is displayed by the DisplayReportInfo boundary class that allows the user to
order the report by referral name or referral type.

A screenshot from the implementation of the scenario displaying the referral report is shown in
figure 25. All screenshots produced throughout all the scenarios are included in Appendix F. Unit
tests were executed on each JSP and the Java Beans it called. In addition, as the use case realisation
defined the basic flow of events, it was used as the test use case to test the set of JSPs and Java
classes created.
Figure 25. The Referral Report screen
7.2 S c e n a rio 5 – Provide Targeted Marketing

There was recognition by the business that currently all customers were treated the same as no
information was captured regarding their profitability. However, ‘different profitability segments
are likely to be sensitive to different service emphases and are likely to deserve different levels of
service.’ [38] It has also been shown that the profitability impact of improving service quality varies
greatly across customer tiers i.e. compared to the Lowest 20% ‘the Top 20% appeared to be almost
10 times as responsive to changes in service quality’ [38]. The difference in quality of service based
upon the customer segment also includes the provision of different services to the segments through
targeted cross-selling. The business currently offers additional legal services such as wills and
probate and 3rd-party services such as referral to independent financial advisors but these are not
34
Inderjit Singh
targeted offerings and only provided on an ad-hoc basis with no cross-selling information captured
in a system - all knowledge is held with the individuals.
Targeted marketing would rely on the requirement to capture customer segmentation information
that would enable the creation of a customer profile. This will provide a better understanding of the
customer requirements as specified in the Benefits Dependency Network (figure 22) and allow
targeted cross-selling based upon the responses to targeted questioning.
As the business had not yet specified the factors relevant to creating a customer profile, it was also
agreed with LUBS that the customer profile should be a combination of the conveyancing
instruction type, the property type and the segment [28]. LUBS also specified the different property
types.
• Capturing customer instruction, property type and segment information
• Formulating a customer profile
• Providing targeted questioning based upon the customer profile
• Providing targeted actions based upon the responses to the questions
The use case realisation of this scenario is shown in figure 26 that displays the boundary, control
and entity classes and their responsibilities required to provide this functionality. It also defines the
process flow for the implementation of the scenario.
information is then captured depending upon the type of customer case. Conveyancing instruction
information is then displayed relating to the different types of instruction e.g. first-time buyer, sale
or purchase. The user then selects the relevant instruction. The instruction information selected is
added to the customer case and the different customer property types are then displayed. These
include flat, detached, maisonette etc. The user selects the relevant property type for the case and
this information is added to the customer information. The different customer segments are then
displayed and the user selects the relevant segment of the customer and this information is added to
the customer information. Based upon the response to the instruction type, property type and
segment, a profile is created and this is matched with a set of segmentation questions. The relevant
questions are then returned. Based upon the responses to the questions, a set of actions is then
displayed. An explanation of the functionality in terms of the classes created is provided in the
subsequent paragraph
The customer case is created as stated in the tactical scenario1 (section 6.1). The conveyancing
instruction information is then retrieved by the ConvInstructions control class and is displayed by
the InstructionTypes boundary class. The user selects the relevant instruction type that is captured
by the SelectPropertyType control class which then updates the conveyancing_customercase entity
class. The control class will retrieve the different property type information dependant upon the
instruction type selected. The PropertyType boundary class displays the property types. The
selected property type is captured by the DisplaySegments control class that updates the
conveyancing_customercase entity class with this property type information. The control class then
retrieves the customer segments from the customersegment entity class that are displayed by the
SegmentType boundary class. The segment selected is then captured by the SegmentQuestions
control class that updates the customer entity class with the segment information. The class then
forms a customer profile based upon instruction type, property type and segment and retrieves the
35
Inderjit Singh
segment questions that match this profile from the segmentquestions entity class. The
DisplayMatchingQuestions boundary class displays these questions. The responses to the questions
are captured in the SegmentActions control class that retrieves the appropriate actions that are
displayed by the DisplayActions boundary class.

A screenshot from the implementation of the scenario displaying the targeted questions is shown in
figure 27. All screenshots produced throughout all the scenarios are included in Appendix F. Unit
tests were executed on each JSP and the Java Beans it called. In addition, as the use case realisation
defined the basic flow of events, it was used as the test use case to test the set of JSPs and Java
classes created.
Figure 27. Screen displaying targeted questions based upon specific customer profile
The completion of development of all the scenarios allowed the construction of the conceptual level
class diagram that specifies all the entity classes and their associations as shown in figure 28 in
Appendix D. A data model was also constructed as shown in figure 29. Entities added to the data
model were normalised to Third Normal Form and additional weak entities such as
‘requiredonlinesearches’ and ‘conveyancingprocessstatus’ were added to resolve many-to-many
relationships.
The completion of development also signified the completion of the iterations through the
elaboration phase of RUP as it captured most of the requirements, established an architectural
baseline and provided an execution of the implementation [34]. The business is now in a position to
begin the construction phase of RUP that focuses on the build of the system to provide operational
capability. This will involve prioritising the requirements and providing them to the vendors to be
incorporated into the existing vendor systems.
36
Inderjit Singh
Figure 29. Data Model supporting CRM data requirements for service-based SME
37
Inderjit Singh
8 Eva lu a tio n
The aim of the chapter is for evaluating the project as a whole and to determine if the project was
deemed a success. The criteria included:
• Evaluation against the project objectives (section 1.1.1).

• Evaluation by LUBS over the background literature review
• Evaluation by the business (HTR) on the business benefits, functional and data requirements
• Evaluation by LUBS over the extent that the project had reached it aims both regarding the
specific business but also the SME market as a whole
• Evaluation of the functional and data requirements produced for the specific business and
their applicability to product-based and service-based SMEs
• Evaluation of the system with regards to the ISO9126 software evaluation standard
• Evaluation of the Architecture
• Evaluation of Project Management
8.1 Eva lu a tio n a g a in s t P ro je c t Ob je c tive s

The project objectives remained the same throughout the project. However, through understanding
the problem (section 4), the focus of the project shifted from producing a solution that would be
implemented as a proof-of-concept to become operational, to producing a solution that would elicit
the functional and data requirements that could then be taken to the current system vendors. An
initial evaluation of the project was conducted to ensure that each of the project objectives had been
addressed.
1 .To gain an understanding of the importance of CRM and its relevance to SMEs
A report outlining the importance of CRM and its relevance to SMEs was produced as a minimum
requirement. This was evaluated by LUBS as described in section 8.2.
2 .To investigate the current CRM market offerings e.g. Siebel, Peoplesoft, SAP and SalesLogix and
their underlying data models
The report also contained a review of the current CRM market offerings with a summary of the core
capabilities offered. The data requirements relating to a CRM offering were derived through
analysis of current SME CRM vendors and a data model was produced, although it was noted that
the analysis had been undertaken on product-based CRM vendors. This formed part of the
evaluation by LUBS as described in section 8.2.
3. To define the requirements of the SMEs and perform analysis and design of the CRM system
The use of a methodology to define requirements and perform analysis and design was a minimum
requirement. A methodology (RUP) was selected that allowed consistency between requirements
capture and subsequent analysis and design through the use of artefacts. Artefacts from each
workflow would derive artefacts in subsequent workflows e.g. use cases derive use case
realisations.
The service quality gap model [23] was used to identify quality gaps within the current business
processes and use of IT. Through the analysis and design workflow, the functional and data
requirements were specified that were needed to mitigate these gaps to then realise the business
benefits. Additional functionality related to providing a strategic competitive advantage was gained
from further literature reviews. The business benefits, functional and data requirements produced
were evaluated both by HTR in section 8.3 and LUBS in section 8.4.
4. To develop a proof-of-concept CRM system

38
Inderjit Singh
The implementation of one or more components of functionality was a minimum requirement. The
implementation was scenario-based as it focused on the demonstration of functionality that would
elicit and validate the requirements. Not only one but five such components of functionality were
implemented. The implementations were also evaluated by HTR in section 8.3 and LUBS in section
8.4. Additional value was provided within the implementation by identifying vendors that could
provide some of the required functionality and that could be integrated with the current systems e.g.
NLIS-Searchflow.
8.2 Eva lu a tio n o f Ba c kg ro u n d Lite ra ture

The background literature review was evaluated by LUBS in relation to the project using a
questionnaire designed with open and closed questions [48]. This would establish how well project
objectives 1 and 2 were met. The evaluation questionnaire is included in Appendix D. LUBS agreed
that the report outlined the importance of CRM and the relevance of CRM to the SME market. It
also identified the core components and clearly identified the data requirements. However, it was
noted that the data requirements were based on sales-centric product-based solutions and it was
suggested that comparison should also involve package solutions such as Goldmine [41] that
provide solutions for service-based businesses. Also, a comparison between product-based and
service-based requirements was suggested. As a result, a review of the Goldmine vendor offering
was undertaken, and this was included in the subsequent evaluation of the applicability of the
identified functional and data requirements to the SME market as a whole (section 8.5).
8.3 Eva lu a tio n o f th e P ro je c t Ou tc o m e s b y th e s p e c ific S ME (HTR)

The initial partner presentation as described in section 4.7 defined the project problem in terms of
‘why’ CRM was important and ‘how’ CRM advantages could be realised. It then established the
‘why’ element. A subsequent partner presentation was delivered at the end of the project to
demonstrate the ‘how’ element of the project which was the functional and data requirements that
were produced and the implementations. The presentation is included in Appendix E.
Partner evaluation was then gathered using a questionnaire designed with open and closed questions
[48]. The evaluation is included in Appendix D. This evaluated the business benefits outlined, and
the functional and data requirements that had been elicited through the various scenarios and the
overall management of the project. This would establish how well project objectives 3 and 4 were
met from the business’s perspective. Both partners agreed with all business benefits and they
considered all the functional requirements stated as both relevant and required by the business. For
all scenarios, they agreed that the implementation clearly demonstrated the functionality and that
the implementation of the functionality showed how the business benefits could be achieved. The
overall opinion of the project was ‘extremely beneficial’ and ‘enjoyable and useful’ and both agreed
that the project was handled in a professional manner and that they were far more confident in
discussing their CRM requirements with their software vendors. They would have liked to seen the
next steps in implementation, however, it was explained that this would involve discussions with
the vendors themselves as well as the development of a strategic plan, both of which were not in the
scope or the timescale of this project. Also, both of these would have required a substantial amount
of time with the business, and it was this time that had been lacking throughout the project.
8.4 Eva lu a tio n o f P ro je c t Ou tc o m e s b y LUBS

LUBS evaluation was also gathered using a questionnaire designed with open and closed questions
[48]. This evaluation is also included in Appendix D. This would establish how well project
objectives 3 and 4 were met from LUBS’s perspective. They felt that due to the project, the
business had a much better understanding of CRM and its applicability. They also agreed with the
business benefits stated and they considered the functional requirements as ‘vital’ in all scenarios
apart from scenario3 where they were still seen as important. In all cases, they agreed that the
39
Inderjit Singh
implementation clearly demonstrated the functionality and that the implementation of the
functionality showed how the business benefits could be achieved. They stated that the ‘benefits
outlined the main aspects of crm’ and that no additional business benefits needed to be included. In
general, there was agreement that the functional requirements were applicable to other service-
based SMEs apart from scenario3 that was particular to the legal sector. It was also felt that the
requirements relating to the strategic scenarios were relevant to product-based SMEs. The overall
opinion of the project was that ‘it homed in on the priorities and more importantly demonstrated the
benefits that could be gained.’
8.5 Eva lu a tio n o f th e fu n c tio n a l a n d d a ta re q u ire m e n ts for th e S ME

m a rke t a s a wh o le
The functional and data requirements elicited through the project were based upon a single SME
and as the project is related to SMEs, some attempt must be made to evaluate these requirements in
terms of service-based and product-based businesses as a whole. Additional investigation took place
into the Goldmine [41] offering to service-based business as suggested as feedback in section 8.2
that provided an understanding of requirements for the service-based sector. With regards to the
product-based sector, comparison was based upon the vendor offerings of Salesforce.com [16] and
Saleslogix [17]
The applicability is described in terms of the scenarios chosen in Table 5, the functional
requirements of these scenarios in Table 6 and a comparison between the data model derived for the
SME (figure 29) and the data model based upon CRM product-based vendors (figure 5) in Table 7.
The comparisons regarding the functional and data requirements are included in Appendix D.
Key
1 - completely applicable
generic – applicable at a generic level
(1) – applicable functionality but not used in the same way
2 - not applicable
8.5.1 S c e n a rio s
Requir ement Pr oduct Ser vice Comment

Integrate New generic generic Applicable to both in that a consistent new case creation process is
Case Creation required over the range of products/services offered.
Service Cycle 1 1 A service cycle is required for both, however, a service cycle in
product-based context refers to customer service cycle ‘that is the
service provided in support of a company’s core products’ [20].
While, a service cycle in the service-based context refers to the
process of completion of the service offered to the customer.
Online generic generic Online conveyancing searches are only specific to the legal context,
Searching and therefore not applicable for product/service based SMEs.
However, generic use of an online capability to improve process
efficiency is applicable to both.
Inbound 1 1 Inbound Referrals ‘are especially important in services marketing’
Referrals [22]. However, this is applicable to Lead Management [16] in a
product-based context in that knowledge is captured over the source
of potential customers and where the best leads come from i.e.
profitability of marketing campaigns and channels of interaction.
Targeted 1 1 Segmentation is not only applicable but important in any CRM
Cross-Selling strategy for both product-based and service-based SMEs [38]. The
creation of a customer-profile can also facilitate tailored scripting in
both contexts.
Table 5.Applicability of SME Scenarios for service and product-based contexts

40
Inderjit Singh
8.5.2 Fu n c tio n a l Re q u ire m e n ts
The comparison of functionality as included in Appendix D, showed that the functional

requirements were largely applicable across both contexts but there were differences in the specific
implementation against these requirements in a product-based context e.g. the focus on the product
and not the customer case. However, the comparison was made from the applicability of the
specific SME service-based requirements to a product-based context and did not include a
comparison of product-based requirements to a service-based context. Product-based requirements
also include the management of a sales-cycle through Opportunity Management [17] and the
execution of campaigns to generate customer leads through Campaign Management and Lead
Management [16]. However, these were not relevant to the specific SME as there was no reliance
on attracting customers as customers contact the business for the service.
The underlying data models were then compared to determine if one language-neutral data model
could be created that was applicable for both product-based and service-based contexts. This
comparison involved the data model derived for the SME (figure 29) and the data model based upon
CRM product-based vendors (figure 5).
8.5.3 Da ta Re q u ire m e n ts
The data requirements comparison was undertaken between those requirements for the specific
service-based SME and generic product-based requirements. This is included in Appendix D. As
such, additional service-based requirements were gathered from a service-based vendor review [41],
however, the differences between the service and product-based data models in terms of focal
entities and contact information were great enough that they could not be combined into a single
language-neutral CRM data model to support all SMEs.
8.6 Eva lu a tio n o f th e s ys te m with re g a rd s to IS O9126

The ISO9126 standard [43] provides a set of characteristics for evaluating software produced. These
include:
• Functionality – does the functionality satisfy the needs?
• Reliability – does the software maintain its level of performance under stated conditions?
• Usability – how easy is the system to use?
• Efficiency – how well does the system perform in relation to the resources used?
• Maintainability – how much effort is needed to make changes?
• Portability – how easy can the software be transferred from one environment to another?
This would provide a useful evaluation for a fully implemented solution, however, here it is not
appropriate to require full compliance as the system was produced for demonstration purposes, but
the various categories were nevertheless applied in order to ensure that there were no fundamental
flaws.
8.6.1 Fu n c tio n a lity

The functionality of the system was derived following the RUP from the business benefits. It was
evaluated by both the business and LUBS as stated in section 8.3 and 8.4, who both confirmed that
it satisfied their needs. The evaluations are included in Appendix D.
8.6.2 Re lia b ility

Execution of the system based on the JSP-MySQL architecture provided the same level of
performance on different occasions. To this extent, the system satisfied the criteria.
41
Inderjit Singh
8.6.3 Us a b ility
The system was based on use-case storyboards and followed usability heuristics [36]. The usability
was evaluated as part of the evaluation of the implementation by both the business and LUBS who
both confirmed its adequacy. The evaluations are included in Appendix D.
8.6.4 Effic ie n c y
The evaluation of the usability of the system by LUBS also incorporated the efficiency of the
functionality in performing the scenarios. The feedback confirmed that the system also satisfied the
criteria.
8.6.5 Ma in ta in a b ility
The functionality of the system was encapsulated within the Java Beans that were called by the Java
Server Pages. The development of the system was based upon object-oriented concepts of
encapsulation and modularity [44] that meant that changes required would only impact the relevant
objects so the system has high maintainability.
8.6.6 P o rta b ility

The development of an open-source system based on the JSP-MySQL architecture means that the
system is fully portable to all environments and so the system has high portability. The architecture
requirements include SDK 1.4, Tomcat web server and the MySQL database server.
8.7 Eva lu a tio n o f th e Arc h ite c ture

The specification of an open-source system led to the selection of the JSP-MySQL architecture
(section 6.1.3). However, there were implications in development due to the constraints of the
DBMS used i.e. MySQL v3.23. These included the lack of stored procedures and triggers, the lack
of embedded select queries and the date format specified as ‘yyyy-mm-dd’. This required the
creation of more complex select queries using temporary tables to define set difference and the use
of the StringTokenizer class to separate the date elements to allow the display in a ‘dd-mm-yyyy’
format to the user.
8.8 Eva lu a tio n o f P ro je c t Ma n a g e m e n t

Project Management was particularly important to this project due to there being two external
clients that were LUBS and the specific business. As the project commenced, it became evident that
the project did not just involve the specification and design based upon a set of defined
requirements but that significant additional effort was required in initially establishing the business
case of CRM to the SME and that the emphasis was upon myself to provide the requirements to the
business for them to then validate. This required management of scope that changed the emphasis of
the project and resulted in the deliverables being focused on eliciting and confirming the
requirements and not upon the implementation of a proof-of-concept that would become
operational. In addition, the commitment of project time by the business was restricted even though
the value of the project became evident to them. The evaluation by LUBS included in Appendix D,
stated that the project was ‘extremely well managed, good communication throughout, and
excellent presentation,’ and in relation to the lack of project time with the business ‘within the time
constraints a significant amount of work was conducted in an environment that was ill disciplined
and unstructured.’ The change to a scenario-based approach was also shown to be successful as it
reduced risk in development but was also evaluated as demonstrating the relevant functionality by
both LUBS and the business.
42
Inderjit Singh
8.9 Eva lu a tio n o f th e Eva lu a tio n

The comparison of functional and data requirements compared a specific service-based case study
with product-based vendor offerings. A more applicable comparison would have involved a
product-based case study with the service-based case study as well as a separate product and service
vendor comparison.
This chapter has demonstrated that each of the project objectives was met and the evaluation by
LUBS and the business indicated that the project clearly defined relevant requirements and
functionality and that the implementation demonstrated how the benefits of CRM could be
achieved. Furthermore, the evaluation of the requirements against SMEs as a whole showed that the
requirements were largely applicable to service and product-based SMEs.
43
Inderjit Singh
9 Co n c lu s io n a n d Fu tu re Wo rk
The project overcame the key challenges (section 1.2) regarding both business-related challenges of
managing a project with two external clients (LUBS and HTR) and demonstrating value as well as
the technical–related challenges of gaining application and database development skills to produce
an open-source implementation. The use of the RUP methodology that incorporated Benefits
Management also ensured consistency in the development process from benefits to requirements
through analysis and design and into implementation.
The evaluation demonstrated that the project objectives were all met and additional insight was
provided to the business by highlighting potential vendors that could provide some of the required
functionality. Both the business and LUBS agreed with the business benefits that the project had
identified and clearly stated that the functional and data requirements identified to support them
were both required and relevant to the business. Also the implementations clearly demonstrated
how the functionality would enable the business benefits to be achieved. In addition, the project
generalised the findings to determine the applicability of the requirements to the SME market as a
whole. While the functional requirements were mainly applicable to both product and service-based
contexts, the underlying data models were different enough to conclude that there is no one
language-neutral data model that can serve the SME market as a whole.
However, the emphasis of the project was upon establishing the requirements and functionality to
support CRM. Consequently, there was little mention of the potential negative impact on a business
such as a decrease in morale due to the potential de-skilling of workers as processes become
system-driven. Also, the specific business rules associated with the functionality were not specified
as the project created functionality for demonstration and not operational purposes.
The future work associated with the project includes both the next step in the project for the
business and also the future work associated with the functionality of the system both in relation to
the business and in increasing the functionality.
9.1 Ne xt S te p s fo r th e Bu s in e s s
The final partner presentation delivered not only provided a summary of the findings of the project
but also the next steps for the business. This included
• Maximisation of the use of the functionality in the current systems

• The prioritisation of the functional and data requirements elicited
• Discussion of these requirements with the vendors
• Re-definition and alignment of the business process with this functionality
• Development of an IS strategy and plan
It was made clear that an IS strategy was required to ensure that there was a consistent view of how
IS/IT would support as well as drive the business and that the prioritisation of the required
functionality should be explicitly noted within an IS plan.
9.2 Ne xt S te p s o f th e S ys te m In Re la tin g to th e Bu s in e s s
The analysis and design only concentrated on the functionality required to meet the business
benefits but not on how this functionality would be incorporated into the current business processes.
This was partly due to the lack of project time dedicated by the business. Additional stakeholder
workshops [26] could be held with key employees to define how the functionality could be
incorporated into the current processes. The important stakeholder groups could be identified within
a Stakeholder Analysis [30] that is used in conjunction with the Benefits Dependency Network.
44
Inderjit Singh
This would identify the ‘commitment mapping’ required of the different groups to ensure that the
organisational changes in the businesses occur to realise the benefits. This would also highlight any
perceived resistance in relation to the downside of implementing CRM such as de-skilling.
Based upon the output of the workshops, Business Activity diagrams of the proposed business
processes could be created. The proposed Business Object Model that defines the roles and
responsibilities of the internal workers could also be created that would show how the system
functionality would be used and by whom.
9.3 Ne xt S te p s in th e Ad d itio n o f Fu n c tio n a lity to th e S ys te m
Additional functionality could also be incorporated into the system as specified in the Table 8.
Functionality Descr iption

Alternate and exception Only the basic flow of events was defined for each use case to
paths of use cases demonstrate the basis functionality. Use Case Descriptions
Forms should be created for each use case that also defines both
the alternative and exception paths. This can then be used to
drive the implementation of these additional paths through the
system e.g. selection of different types of reports as an
alternative path.
OLAP and Data Mining OLAP techniques could be implemented to provide the business
partners with additional insight into the data captured through
slicing and dicing of the data model e.g. number of customer
cases created per month for each branch. Also, Data Mining
techniques could be implemented for exploratory investigation
that would allow clustering of the customers to re-define the
customer segments [45].
Partial Matching Partial matching functionality would provide greater recall in
information retrieval and enhance the usability of the system
e.g. a user can enter the initial of the first name of a customer as
opposed to entering the first name accurately. The addition of
indexing and inverted files would also enhance the efficiency in
the retrieval [45].
Campaign Management Campaign Management functionality was not deemed relevant
by the business but is relevant to service-based businesses as
specified in the Goldmine vendor offering [41]. Additional
scenarios could be designed and implemented to incorporate
this.
Lead and Opportunity Lead and Opportunity Management functionality was not
Management deemed relevant by the business but is relevant to service-based
businesses as specified in the Goldmine vendor offering [41].
Additional scenarios could be designed and implemented to
incorporate this.
Table 8. Additional functionality that could be added to the system as future work
Also, non-functional requirements such as security should be further investigated. For example,
scenario 2–Provide Service Cycle, allows users to view and update the case status of customers and
add and update issues. However, a security policy for this functionality is required to ensure that
authentication and authorisation of the employees who can use this functionality is established and
maintained, as the customer information in the legal context is particularly sensitive.
45
Inderjit Singh
10 Re fe re n c e s
[1] Msc Project Specification, (2003) in local.msc.projects
[2] Hobby, J. (1999) ‘Looking after the one who matters’, Accountancy Age, 28 October, 28-30
[3] Ryals, L., Knox, S., Maklan, S. (2000), ‘Customer relationship management (CRM);
building the business case.’ Prentice Hall
[4] Curley, B. (1999) ‘Profiting from the relationship,’ Insurance and Technology, 24(3), 34-8
[5] Papows, J.P. (1999) ‘The payoff from knowledge management,’ US Banker, 109 (9), 80
[6] Gentle, M. (2002) ‘The CRM project management handbook: building realistic
expectations and managing risk.’ Kogan Page
[7] Reichland, F.F. (1996) ‘The Loyalty Effect,’ Boston: Harvard Business School Press.
[8] Reeves, B. (1998) ‘Make new friends but keep the gold…,’ Wireless Review, 15 (8), 28-32
[9] Peppars, D. and Rogers, M. (1995) ‘A new marketing paradigm,’ Planning Review, 23, (2), 14-
18
[10] Mills, J. (2001) ‘CRM Overview,’ CRM.ITtoolbox.com

http://www.crmassist.com/browse.asp?c=CRMPeerPublishing&r=http%3A%2F%2Fwww%2Eittoo
lbox%2Ecom%2Fhelp%2Fcrmoverview%2Easp [3rd April 2003]
[11] Anderson, R. and Stang, D. (2000) ‘Customer Relationship Management (CRM): Perspective.’
Gartner Research
[12] Gottlieb, D. (2001) ‘Product Overview of CRM systems,’ CRM Global Service Line Market
Intelligence, 1-41
[13] Siebel Systems (2003)

www.siebel.com [10th April, 2003]
[14] Outlaw, J. (2002) ‘CRM Trends for Small and Medium Size Businesses in North America.’
Gartner. Inc
http://crmguru.custhelp.com/cgi-
bin/crmguru.cfg/php/enduser/fattach_get.php?p_sid=Y2R6tNGg&p_tbl=9&p_id=827&p_created=1
0376595551[23rd April, 2003]
[15] Curry, J. ‘CRM for SME: What’s Going to Happen In The Next 1000 Days?’ CRMguru.com
http://crmguru.custhelp.com/cgi-
bin/crmguru.cfg/php/enduser/std_adp.php?p_sid=NJm31rHg&p_lva=&p_faqid=218&p_created=10
14800613&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTM2JnBfc2VhcmNoX3Rl
eHQ9U01FJnBfcGFnZT0x&p_li21[17th April, 2003]
1
[16] Salesforce.com (2003) Product Overview

www.salesforce.com1[26th Aug, 2003]
46
Inderjit Singh
[17] Saleslogix.com (2003) Product Overview

www.saleslogix.com [27th Aug, 2003]
1
[18]1Robson, W. (1997) ‘Strategic Management and Information Systems.’ (2nd Ed). Pitman
[19] Robinson, W (2003) Porter’s 5 Forces Analysis of the Legal Sector, LUBS
[20] Ziethaml, V. and Bitner, M. (2003) ‘Services Marketing – Integrating Customer Focus
Across The Firm.’ McGraw-Hill
[21] Gronroos, C (1994) ‘From marketing mix to relationship marketing: Towards a paradigm shift
in marketing.’ Management Decision, MCB University Press
1
[22] Woodruffe, H (1985) ‘Services Marketing.’ Pearson Professional Limited
[23] Parasuraman, A., Ziethaml, V. and Berry, L. (1985) ‘A Conceptual Model of Service Quality
and Its Implications for Future Research.’ Journal of Marketing, 49 (Fall 1985), 41-50
[24] Stewart, H., Hope, C. and Muhlemann, A. (2000) ‘ Service quality in the legal profession: a
review.’ International Journal of Management Reviews, 2, Issue 3, 261-275
[25] Yorke, D. (1990) ‘Developing an interactive approach to the marketing of professional

services.’ In Ford, D. (ed), Understanding Business Markets Interaction Relationship
Networks. London: Harcourt Brace
[26] Johnson, O. (2003) Information Systems Engineering Lecture Notes
[27] DPS Solutions (2003) Product Overview

http://www.dpssoftware.co.uk/home.asp [30th July, 2003]
[28] MSc Project Log (2003)
[29] The Hildebrant Institute (2002) ‘Relationship Intelligence in a Competitive Market.’

http://www.interfacesoftware.com/pdf/wp_ri_hildebrandt.pdf [23rd April, 2003]
[30] Ward, J. and Peppard, J. (2002) ‘Strategic Planning for Information Systems.’ (3rd Ed)
Wiley
[31] Online Rational Unified Process (2002)
[32] Avison, D. and Fitzgerald, G. (2003) ‘Information Systems Development- Methodologies,

Techniques and Tools.’ 3rd edition, McGraw-Hill
[33] Avgerou, C and Cornford, T. (1998) ‘Developing Information System – Concepts, Issues
and Practice.’ 2nd Edition, MacMillan Press Ltd
[34] Booch, G., Jacobson, I and Rumbaugh, J. (1999) ‘The Unified Software Development
Process.’ Addison Wesley Longman Inc.
[35] Zymaris, C. (2003) ‘MySQL or PostgreSQL?’ ZDNET Australia

47
Inderjit Singh
http://www.zdnet.com.au/builder/architect/database/story/0,2000034918,20273361,00.htm [26th
Aug. 2003]
[36] Tognazzini, B (2003) ‘First Principles.’ Neilson-Nor man Gr oup

http://www.asktog.com/basics/firstPrinciples.html [22nd Aug. 2003]
[37] Practical Solutions (2002) ‘DPS Software joins forces with NLIS Searchflow.’
th
122345566678399
26 7
75698295693 59 1
6
6793 [18 July 2003]
[38] Zeithaml, V., Rust, R. and Lemon, R. (2001) ‘The Customer Pyramid: Creating and Serving
Profitable Customers.’ Califor nia Management Review, 43, 4, 118-142.
[39] Parasuraman, A and Zeithaml, V. (1988) ‘SERVQUAL: A Multiple-Item Scale for Measuring
Consumer Perceptions of Service Quality.’ J our nal of Retailing, 64 (Spring 1988), 1, 12-40
[40] Robinson, W. (2003) Client Segmentation Questionnaire, LUBS
[41] FrontRange Solutions Inc. (2003) Product Overview

www.goldmine.com [28th Aug. 2003]
[42] Kennedy, D. (1999) Contact Management Software Puts a Networking ‘Goldmine’ at Your
Fingertips.’ Law Pr actise Management, March 1999
[43] Information Systems Audit and Control Association

http://www.isaca.org.za/Iso9126.htm [26th Aug. 2003]
[44] FactGuru Object-Oriented Software Engineering

http://www.site.uottawa.ca:4321/oose/index.html#maintainability [28th Aug. 2003]
[45] Roberts, S (2003) Knowledge Management Lecture Notes
[46] Kazman (1999) ‘Scenario-Based Analysis of Software Architecture.’ Car negie-Mellon

Softwar e Engineer ing Institute
http://www.sei.cmu.edu/architecture/scenario_paper/ [27th Aug 2003]
[47] Gerson, R. (2003) ‘CRM Explained.’ STAT

http://sitetipsandtricks.com/art/a041001b.html [27th Aug 2003]
[48] William, F. (2001) ‘Constructing Questions for Interviews and Questionnaires.’

Cambridge University Press
[49] Information Modelling Module Lecture Notes, 2003
[50] Howard and Sheth, (1969) in Brassington & Pettitt, Principles of Marketing, 2000
48
Inderjit Singh
11 Ap p e n d ix A - P e rs o n a l Re fle c tio n
The reflection on the project includes both what I have learnt through the project but also what I
would do differently if I faced the same project again. Overall the project gave me exposure to the
entire development process from using IS strategy techniques such as Benefits Management to
define business benefits right through to the implementation of Java Server Pages within an open-
source architecture. While this breadth was challenging to handle, I was fortunate to have such an
opportunity to take responsibility for the entire business and technical approach and so this is an
opportunity that I am glad to add to my experiences.
Consequently, what I have learnt relates both to business and technical aspects.
Pr oject Management
Within this project, the stakeholders were identified as the business partners. However, due to the
lack of project commitment, instead of aiding the project in eliciting the requirements, I had to use
their role to validate what I had produced. Consequently, for future projects dealing with an external
client, it is imperative to identify the key stakeholder from the business and to agree a minimum
level of project time commitment before the project commences.
Also, be prepared to have to adjust the development plan to suit the nature of the project. Initially,
the project plan reflected a sequential development plan based upon the assumption that the
business would validate the milestone produced at each stage. However, as it became clear that the
system to be produced was to elicit and validate requirements, the appropriate development method
i.e. scenario-based development was used and this was then reflected in the revised project plan.
Requir ements Analysis

The initial review of the current processes and IT allowed me to convince the business and LUBS to
redefine the focus of the project due to the existence of established vendor systems supporting
processes that were not integrated. For all future projects with external clients, an initial project
evaluation of the current position should be undertaken to ensure that the project has the correct
focus at its inception.
Use of Methodology
While I was taught about the Rational Unified Process and Benefits Management within modules,
this was the first-time that I had used them within a real-world context. It provided me with a great
insight into how the different phases of the methodology could be used to address different aspects
of the problem and also how the specific artefacts in each workflow could be used together. Also,
the use of Benefits Management to complement RUP allowed a benefits-approach to be taken that
was particularly important in establishing the value to the external client.
For future projects, choose a methodology that complements the focus of the project and the
deliverables of the project. For this project, the use of RUP complemented the scenario-based
approach by allowing iterations through the elaboration phase for each scenario. Also, it is
suggested that an approach that is appropriate for the external client is chosen. The addition of
Benefits Management was vital to this project as it ensured client commitment to the project, as the
value to be gained was made explicit.
Web-based Development
The project also allowed me to develop my application programming skills and database skills. My
previous experience was limited and so this exposure has helped me to develop my programming
skills and understanding of some of the issues involved with web-based application development.
The requirement of implementation within the project also enhanced my analysis skills and I could
49
Inderjit Singh
clearly see how analysis and design decisions affected the implementation. The use of a
methodology that provided consistency also aided the development.
For future implementation projects, it is important to establish the proof-of-architecture early on.
This was achieved in this project through the implementation of the first scenario using the JSP-
MySQL architecture that established the JDBC connectivity. This minimises project risk associated
with implementation.
Evaluation Cr iter ia
The project also allowed me to focus upon the evaluation of the solution produced. In my previous
experience, a development project was completed once the solution had been delivered. This project
required me to think about the criteria to evaluate a solution in an objective manner. This was
achieved through questionnaires delivered to both external clients (LUBS and HTR).
For future projects, it is important to define the evaluation criteria early on, as the criteria will
provide project structure to the student so that the solution that is created can be adequately
evaluated by the criteria.
50
Inderjit Singh
12 Ap p e n d ix B - Ob je c tive s a n d De live ra b le s
This appendix contains the project objectives, minimum requirements and deliverables.
51
Inderjit Singh
52
Inderjit Singh
13 Ap p e n d ix C - Ma rkin g S c h e m e a n d Fe e d b a c k
This appendix specifies the marking scheme of the project and also includes the feedback provided
to the interim report.
53
Inderjit Singh
54
Inderjit Singh
14 Ap p e n d ix D
In the first section of the appendix, the use case realisations created during the analysis and design
of each scenario are included. In addition, the conceptual-level class diagram that specifies all the
entity classes and their associations is also provided. The second section of the appendix includes
the detailed evaluation of the applicability of the identified functional and data requirements to
service and product-based SMEs. The third section of the appendix includes the evaluation
questionnaires provided both to LUBS and the business. Evaluation was undertaken on the
background review and on the project overall. The final section of this appendix includes the slides
from the two partner presentations delivered.
55
Inderjit Singh
14.1 Us e -Ca s e Re a lis a tio n s o f th e S c e n a rio s

This section includes the use-case diagrams that support each of the scenarios. Each diagram highlights the boundary, control and entity classes required as well
as the responsibilities of each of the classes.
: solicitor : propert y : estate agent

: branch : product type
5: getSolicitorInfo
6: getBranchInfo 12: setPropertyInfo 16: setEstateAgentInfo
8: getProductType
1: submit client details 2: capture client details 10: gatherPropert yDat a 11: addPropertyData 14: gatherEstateAgentData 15: addEstateAgentData
7: specify product type

: employee : New Client Screen : Capture Client Details : AddP roduc tType : PropertyDetails : AddPropertyData : EstateAgentDetails : AddEstateAgentData
9: updatecaserecord
13: updatecaserecord
3: insert customer record

4: insert case record 17: updatecaserecord
: customer
: conveyancing_customercase
18: provideCustomerSummary
19: displayCaseSummary
: AddEstateAgentData : Provide Customer

Summary
: Case Summary
Figure 16. Use Case Realisation for the New Customer Case Integration Scenario
56
Inderjit Singh
The stage info will be

retrieved for either a
purchase or a sale 15: updateIssueInfo
: purchase process
stages
5: getProcessSt ageInfo 7: getProcessIssueInfo : process issues : IssueUpdate

10: insertIssueRecord
14: getIssueInfo
9: adddIssue
: IssueAdd
1: enterCust omerDetail s 2: getCust omerDetails 3: displayCaseSummary 4: getStageStatusInfo 8: displayCustomerStatus
12: viewIssueInfo
13: displayIssueInfo
: user : Search Client Screen : Provide Customer : Case Summary : GetStageInfo : Customer Status
Summary
: Iss ueinfo : DisplayIssue

6: getProcess St ageInfo
11: updateStageCompletion
: sales process stages
: StageUpdate
Figure 19. Use Case Realisation for the Provide Service Cycle Scenario
57
Inderjit Singh
The customer must confirm

property details for the
instruction to be generated
: property
5: get property info
1: enter customer details 2: get case information 3: display case summary 4: get Property Info 6: display property info
7: create instructi on
: em ployee : Search Client Screen : Provide Customer : Case Summary : ConfirmSearchDet ails : Property Info : Create Instruction
Summary
8: insert new record
: search instruction
Figure 21A. The Use Case Realisation of the Reduce Search Time Scenario
58
Inderjit Singh
: onlinesearchtype
13: get Search Type
10: display map area 11: select map area 12: retrieve search type info 14: display search types 15: retrieve selected searches 17: display full info of selected searches
: Retrieve Map Info : Property Map : Capture Outlined M ap : DisplaySearches : Search Types : Selected Searches : Full Search Type Info
Area
9: retrieve map info
16: updat e search ty pe info
: search instruction
Figure 21B. The Use Case Realisation of the Reduce Search Time Scenario (cont.)
59
Inderjit Singh
:
4: c reat e cu stomer case conveyancing_custo...
7: update case record
1: submit client details 2: capture client de tai ls 6: get product type
5: speci fy product t ype
: user : New Client Screen : Capture Client Details : AddP roductType : pro duct type
8: retrieve instruction type info
: ConvInst ructions
3: inse rt cust om er record
: customer
Figure 24A. Use Case Realisation to support the Capture Inbound Referral Information Scenario
60
Inderjit Singh
:
conveyancing_custo...
7: update case record : customer segment

12: update case record : inbound referral
6: get product type

17: get ReferralType
13: get SegmentType
: AddProductType : product type

10: display instruction types 11: retrieve selected instruction 15: ret ri eve selected segment 18: display referral ty pe 19: retrieve selected referral info
14: display segments
9: get instruction
: ConvInstructions : Ins truction Types : DisplaySegments : Segment Type : Referral Ty pe : Display Referral Type : ConfirmReferral
: conveyancing
instruction
16: update customer record
: customer
21: display report types

22: retrieve s elec ted rep ort type 23: display report type opt io ns 24: retrieve report type option 25: display report info
: ConfirmReferral : Display Report Types : Refe rralRepo rt : Display Report Type Options : Retrieve Rep ort Typ e : Display Report Info
Option
Figure 24B. Use Case Realisation to support the Capture Inbound Referral Information Scenario (cont.)
61
Inderjit Singh
:
4: create customer case conveyancing_custo...
1: s ubmit cl ient detail s 2: capture client details 5: add product type 6: get product type
: employee : New Client Screen : Capt ure Cli ent Det ail s : AddProductType : product type
: ConvInst ruc ti ons
3: insert customer record
8: get instruction
: conveyancing
instruction
: customer
Figure 26A. Use Case Realisation to support the Provide Targeted Marketing Scenario
62
Inderjit Singh
:
conveyancing_custo...
16: updat e case record
: customer segment
: segment questions
6: get product type Ei ther a purchase or sale
property type wi ll be retrieved 17: get Segment Type
11: update case record
bas ed upon the instruction
t ype
: AddProductType : product type 21: get matching questions and actions
: purchase property
12: get property type t ype
7: ret ri eve instruct ion ty pe i nfo
9: display instruct ion ty pes

10: retrieve property type 14: display property type 15: retrieve selected property type 18: display segment ty pe 19: retrieve selected segment
: ConvInst ructions : Instruction Types : Select Property Type : Property Type : DisplaySegments : Segment Type : Segm entQuesti ons
8: get instruction
13: get property type

: conveyancing : sale property type
instruction
: customer
22: disp lay m atching quest ion s 23: retrieve responses 24: display act ions
: SegmentQuestions : Display Matching Questions : Retrieve Actions : Display A ctions
Figure 26B. Use Case Realisation to support the Provide Targeted Marketing Scenario (cont.)
63
Inderjit Singh
online search type
1..* inbound referral

process issues
forms a conceptual collection of 1
Product t ype is 0..* as a
product type may have no 0..* composed of
1..*
ass ocia ted cases
search instruction
product type has

1.. *
1 c ompo sed o f
has customer segment
1 customer
composed of 1
composed of 0..*
composed of 0..* 1..*

estate agent 1 1..* composed of 1 conveyancing instruction provides for
0 .. *
conveyancing_customercase
composed of 1..* 0 .. * provide s for

1..* 0 ..* 1..*
0..* 1..*
1..* composed of
property 0..*
1 {OR} segment questions
1..*
composed of provides for
0..1
dri ves 1..*
purchase property type
composed of
{OR} provides for
drives
1 composed of
branch
0..1
1
sale property type
solicitor 0..*
sales process stages
0..*
purchase process stages
Figure 28. Conceptual-level class diagram represented the entity classes derived through the use-case realisations
64
Inderjit Singh
14.2 Ap p lic a b ility o f fun c tio n a l a n d d a ta re q u ire m e n ts to pro d u c t a n d

s e rvic e -b a s e d S MEs
Key
1 - completely applicable
generic – applicable at a generic level
(1) – applicable functionality but not used in the same way
2 - not applicable
14.2.1 Fu n c tio n a l Re q u ire m e n ts
Requir ement Pr oduct Ser vice Comment

Scenario 1
Check if existing 1 1 The recognition of a new or existing customer is
customer in database applicable in both contexts. Partial matching
functionality will be required to support this.
Capture product type (1) 1 Product type in a service-based sense refers to the
information different service offerings e.g. conveyancing,
wills, probate. Capture of product-type will be
applicable for all service-based SMEs in all
markets. Product type in a product-based context
is applicable to the extent that the customer is
interested in certain types of products e.g.
electrical goods but not for the actual capture of
the specific products required by the customer e.g.
Toshiba 5 DISC SD-K615 DVD player.
Create and maintain (1) 1 Creation of maintenance of customer cases is
(conveyancing and central to service-based businesses as the customer
case represents the service provided. However, for
econveyancing) cases product-based businesses, the customer case only
represents that an interaction is/has taken place. It
is the products that are linked to the customer case
that are important.
Query database to 1 1 Use of a database that provides retrieval of
provide customer customer information is central to any CRM
system whether is it product or service-based.
summary
Retrieve customer 2 1 The customer case is central to service-based
case information from CRM and the service cycle will be related to the
case. However, it is the product that is central to
database product-based CRM and the customer-service
cycle will relate to the product. Hence the product
not the customer case needs to be retrieved from
the database.
Scenario 2
Capture and update 1 1 Capturing and updating of the service cycle is
case stage information applicable to service-based CRM and for
customer-service cycle with regards to product
CRM [20].
Capture and update 1 1 Capturing and updating issues in the service cycle
case issue information is applicable to service-based CRM and in the
customer-service cycle for product-based CRM
[20].
Capture Branch and (1) 1 There is greater reliance on the employee-
(Solicitor) employee customer relationship for professional services
[24] so ‘Credibility’ - a service quality dimension
information [23] is more important for service than product-
based businesses. In a product-based context, the
65
Inderjit Singh
customer interactions are likely to not be with the

same employee and are less reliant on professional
expert knowledge e.g. in call centres where the
emphasis is upon removing the focus away from
employee specific relationships and upon
maintaining the different contacts with a customer.
Scenario 3
Creation of customer generic generic Creation of search instructions to support online
search instruction searching as part of process efficiency is
applicable to both product and service-based
CRM.
Address validation generic generic Address validation is basic functionality that is
applicable to both in that the customer address
needs to be validated both for the provision of
services and the delivery of products.
Allow the user to 2 2 Specific to legal sector and not applicable to non-
define property legal SMEs
boundaries
Select relevant 2 2 Specific to legal sector and not applicable to non-
searches legal SMEs
Review of instruction 2 2 Specific to legal sector and not applicable to non-
legal SMEs
Scenario 4
Identify profitability 1 1 Capture of referral information is of paramount
of referral types and importance to service-based businesses [22] and
the profitability of customer referred will be linked
of specific referrers to their referrers. Information relating to the
source of the lead is also captured in product-
based business that aids marketers in identifying
profitable channels and campaigns e.g. Lead
Analysis tools [16].
Establish an inbound (1) 1 A referral network is important in service-based
referral network CRM to understand where the majority of
customers are coming from [43] and to form
relationships with those referrers. In a product-
based context the referral network is related to the
incoming channels of interaction and appropriate
intermediaries for targeted marketing campaigns
[16].
Capture transaction 2 1 Capturing transaction value will facilitate
value of customer segmentation of customers based upon potential
profitability for service-based businesses.
However, for product-based businesses the
transaction value will be the same for the same
product for all customers.
Capture profitability 1 1 This provides an indication of the referrers/referrer
of referral types that best serve different segments. This is
important to service-based businesses where
types/referrers across ‘recommendation can be a key factor in the
different customer consumer decision process’ [22]. A service-based
segments company can then focus on forming relationships
with those referrers that provide customers of the
relevant segments [42]. Equally for product-based
businesses, understanding which campaigns and
channels are most profitable for different target
customer groups is important [17].
66
Inderjit Singh
Scenario 5
Capture customer generic generic Capturing of instruction, property type and
instruction, property segment information is specific to the legal
market. However, capture of the information to
type and segment create the profile is applicable in both product and
information service-based contexts [38].
Formulate customer 1 1 Formulation of a customer profile is necessary to
profile facilitate targeted cross-selling [38].
Provide targeted 1 1 Use of scripting is already established within
questioning based product-based CRM vendors to provide targeted
questioning (Table 1). This is applicable only for
upon customer profile high-involvement products [50] where the
customer may require interactions with other
information sources to complete the purchase [20].
This is in contrast to simple mass produced
products where the decision to purchase will be
made by the customer alone. Targeted questioning
is also applicable for service-based CRM [41].
Provide targeted 1 1 Use of scripting is already established within
actions based upon product-based CRM vendors to provide targeted
questioning (Table 1). This is applicable only for
the responses to the high-involvement products [50] where the
questions customer may require interactions with other
information sources to complete the purchase [20].
This is in contrast to simple mass produced
products where the decision to purchase will be
made by the customer alone. Targeting
questioning is also applicable for service-based
CRM [41].
Table 6. Applicability of SME functional requirements for service and product-based contexts
14.2.2 Da ta Re q u ire m e n ts
Ar ea Pr oduct Ser vice Comment

Focal Entity Product Entity Customer Case Within a product-based context, the
Entity customer case entity only serves to
represent an interaction with a customer
and is not the focal entity. It is the
product entity that is the focal entity and
is it this entity that is managed through
the customer service cycle and related
to product ticket tracking and product
defects [17]. In a service-based context,
it is the customer case that is the focal
entity and it is this entity that is
managed through the service cycle.
Employee Customer Solicitor/ In a service-based context, the
Relationship Contact Professional establishment of a relationship with the
professional(s) providing the service is
paramount shown by the additional
‘people’ element in the services
marketing mix [20]. In a product-based
context, the interaction will be with
different employees as the emphasis is
on capturing of the customer contact
information with less emphasis on the
establishment of specific relationships.
67
Inderjit Singh
Sales Cycle Opportunity n/a For the specific service-based SME,

Management there was no defined sales cycle as
customers contact the business requiring
the service. However, in the product-
based context, a sales cycle is required
to get agreement from the customer
over purchasing product(s) [16]. It
should be noted that service-based CRM
vendors such as Goldmine [41] do also
provide Opportunity Management
capabilities.
Campaign Campaign n/a For the specific service-based SME,
Management Management, there is no defined campaign
management as customers contact the
Lead business requiring the service.
Management However, in the product-based context,
campaign management with subsequent
lead management is required to target
the relevant customers and convert these
leads into opportunities [16]. It should
be noted that service-based CRM
vendors such as Goldmine [41] do also
provide Campaign Management and
Lead Management capabilities.
Referrals Customer Lead Inbound The referral information captured within
Referral a service-based context will enable the
establishment of a referral network.
However, in a product-based context, it
is through the lead management that
information is captured about the source
of the lead in terms of the marketing
campaign and channel of interaction.
Account Customer n/a For the specific service-based SME,
Account there was no requirement for the CRM
system to capture customer account
information as this was captured upon a
separate accounting system. However,
customer account information is data
captured by the product-based CRM
vendors [17] and well as service-based
CRM vendors such as Goldmine.
Table 7. Applicability of SME data requirements for service and product-based contexts
68
Inderjit Singh
14.3 P ro je c t Qu e s tio n n a ire s

Evaluation questionnaires were designed as part of the project evaluation. Questionnaires were
provided to LUBS to elicit feedback regarding the background literature review as well as feedback
on the project overall. A questionnaire was also provided to the business to elicit their feedback on
the project overall. These questionnaires are included in the subsequent sections.
14.3.1 Eva lu a tio n o f Ba c kg ro u n d Lite ra tu re b y LUBS
Evaluation of Backgr ound Liter atur e – Tim Duckett, LUBS
Objective: - A report outlining the importance of CRM, its relevance to SMEs and current CRM
market offerings
1) In your opinion, how well does the report outline the importance of CRM?
• A clear explanation of the benefits

• Good use of examples to support arguments – e.g. mobile churn
• The customer lifecycle diagram is clear, but less relevant to service operations – is there
a more generic model that could be used?
2) In your opinion, how well does the report demonstrate the relevance of CRM to the SME
market?
• Explains the benefits well, but presentation could be a bit clearer – the first section uses
bullet points to present the benefits, but the SME section is textual.
• Minor concern about the sources cited – as industry sources, are they independent, or do
they have a vested interest in promoting CRM?
3) How well does the report cover the current market offerings?
• Excellent outline of capabilities of major vendors

• There are no details on relative costs of each – as cost is a major barrier to SME
implementation of CRM, is it possible to give indicative costs for major systems?
• Implementation is major area of potential difficulties, so good that this is explicitly
mentioned.
4) Does the report identify the core CRM components required for SMEs? Do you agree with
these components?
• Elements are identified, but buried within the text – could they be emphasised? Tabular
presentation?
• This reader was slightly confused between core components and data requirements – no
disagreement with components/data requirements listed however.
5) Does the report identify the primary data requirements for CRM for SMEs? (product-based)
• A good identification, but the presentation is a little complex – OK for a specialist

audience, but may need a simplified presentation if a non-specialist audience is intended.
• Are salesforce.com and Saleslogix too sales-centric to be a fair representation of small-
scale CRM solutions? Would package solutions such as Goldmine be better
representative of full lifecycle CRM systems?
69
Inderjit Singh
Evaluation of Backgr ound Liter atur e – Wayne Robinson, LUBS
Objective: - A report outlining the importance of CRM, its relevance to SMEs and current CRM
market offerings
1) In your opinion, how well does the report outline the importance of CRM?
The report captures the important elements of crm and why businesses need to embrace the
approach. Whilst the elements were broken down into sales, marketing and customer
service, it would have been beneficial to have identified what quantifiable business benefits
each element would bring about, plus a combination of one or more.
2) In your opinion, how well does the report demonstrate the relevance of CRM to the SME
market?
The report captures all the relevant aspects comprehensively.
3) How well does the report cover the current market offerings?
The report focuses on the major players at the top end of the market. A summary table
would have been useful to see at a glance the specifications and strengths and weaknesses of
each. This section of the report would have been enhanced had it also covered a summary of
other applications and In particular highlighted the sme specific offerings.
4) Does the report identify the core CRM components required for SMEs? Do you agree with
these components?
Yes the report covers the core requirements. It would have been useful to compare in a table
the core components that a large crm user would require versus that of a sme.
5) Does the report identify the primary data requirements for CRM for SMEs? (product-based)
The report covers very comprehensively the data requirements. It would have been
interesting to compare and contrast the data requirements for product versus service based
sme’s.
14.3.2 Eva lu a tio n o f P ro je c t b y Ha rla n d , Tu rb a ll a n d Ro b e rts
Each of the partners of the business completed an evaluation questionnaire after the final project
presentation, one of which has been included in this appendix.
70
Inderjit Singh
71
Inderjit Singh
72
Inderjit Singh
73
Inderjit Singh
14.3.3 Eva lu a tio n o f th e P ro je c t b y LUBS
P ro je c t Eva lu a tio n Qu e s tio n n a ire (LUBS )

The project has involved the specification and design of a CRM system for the SME market. It
focused upon a single SME to identity the relevant business benefits, the functional requirements
needed to achieve these benefits and demonstrations of the functionality. Consequently, part of the
evaluation will assess the extent that the project has achieved it aims for the specific business but in
addition the applicability of its findings to other service-based SMEs but also product-based SMEs.
The questionnaire enclosed has been prepared in order to ascertain this feedback. If you could
please spend some time completing the questions and providing whatever feedback you deem
appropriate.
CRM
1) The project provided the business (HTR) with a better understanding of what CRM is
Strongly Agree – Agree – Disagree – Strongly Disagree
2) Do you think that through the project, the business now has a better understanding of how
and why CRM is applicable to the business?
Absolutely
Business Benefits (Benefits Dependency Networ k)

3) The overall business benefits of CRM were clearly stated to the business
4) Do you agree with the business benefits stated?
Yes
5) Are there any additional business benefits you would have included?
No as the benefits outlined the main aspects of crm and the central issues which HT&R face.
6) To what extent are these business benefits applicable to other service-based SMEs e.g.
financial services and why?
Certain aspects will be such as segmentation, referrals , cross-selling
7) To what extent are these business benefits applicable to product-based SMEs e.g.
manufacturers, and why?
As above. Referrals and segmentation are becoming increasingly important as smaller and
smaller markets emerge
Scenar io 1 – New Case Integration of Processes

8) To what degree do you consider the functional requirements stated as both relevant and
required by the business?
74
Inderjit Singh
Vital because they are operating blind, however, not sure as to the wider applicability to all
law firms/service operations – are they all laggards
9) The implementation clearly demonstrates the functionality
10) Does the implementation of the functionality show how the business benefits can be
achieved? Please explain your answer.
Yes
11) To what extent are these functional requirements applicable to other service-based SMEs,
and why?
Difficult to say, in some cases where multi-sites are involved and IT has little influence in
the business, then highly likely
12) To what extent are these functional requirements applicable to product-based SMEs, and
why?
Unlikely as this function is more skewed to law firms
Scenar io 2 – Service Cycle

Vital as there is too much information in people’s heads rather than the system
achieved? Please explain your answer
Yes a status is clearly visible
and why?
Impossible to say without a more detailed understanding of the other service operations
business processes. In principle for a service sme that delivers a service offering over a
protracted period time, then there could be some application
why?
It wont be as they do not have a service cycle

75
Inderjit Singh
Scenar io 3 Online Sear ches

Important in saving time and duplication of effort
Yes through an integrated approach rather than the traditional paper based system
and why?
Only relevant to law firms
why?
Not relevant at all
Scenar io 4 – Inbound Referral Information

Absolutely vital as it starts to broach the sensitive topic of profit and through the
identification of where this profit comes from, it should start to focus on how best to service
the profit stream rather than providing a homogenous service
Formalises the data, formalises the relationships and identifies costs & benefits
and why?
Very relevant as all service based businesses rely on a network of relationships
why?
76
Inderjit Singh
Could be relevant depends on the type of ‘product’ – toothpaste no, mobile phone yes.
Would expect that fashion focused products would be relevant for this approach or high
value items
Scenar io 5 – Targeted Marketing

Vital in order to maximise their own revenue streams but also to start to force the process
internally
Through prompted questions based on a set response assists the solicitor in identifying
opportunities. The automated process forces the questions to be asked
and why?
Where a service sme has numerous offerings and /or a customer base that offers potential to
a 3rd party then yes it is applicable
why?
Depends on the nature of the product, some products have a natural cross-selling capability
e.g. walkmans with tapes, batteries etc.
General
33) In your opinion, which of the five scenarios were most and least important to the business?
Please rank from 1-5 (‘1’ being most important). Each scenario must have a different
rank
Scenario Name RANK
Scenario1 – New Case Integration 1-2-3-4-5

Scenario2 – Service Cycle 1-2-3-4-5
Scenario3 – Online Searching 1-2-3-4-5
Scenario4 – Inbound Referrals 1-2-3-4-5
Scenario5 – Targeted Cross-Selling 1-2-3-4-5
34) Please explain your ranking
Reflects the firms priorities and realism on implementation
77
Inderjit Singh
35) In your opinion, which of the five scenarios are most and least important to service-based
SMEs? Please rank from 1-5 (‘1’ being most important). Each scenario must have a
different rank
Scenar io Name RANK

36) Please explain your ranking
Impossible to generalise scenario 4 & 5 offer the widest application
37) In your opinion, which of the five scenarios are most and least important to product-based
SMEs? Please rank from 1-5 (‘1’ being most important). Each scenario must have a
different rank
Scenar io Name RANK

38) Please explain your ranking.
39) Is there any additional functionality you would have liked to see, if so what and why?
No as these options matched the requirements of HT&R and their specific need
40) What is your opinion about the look and feel of the system?
Simplistic - which would make it easy to use and avoids duplication of input
41) What is your opinion about the look and feel of the system in terms of
a. consistency of user interface design
clear and functional
b. efficiency of the implemented processes that are required for the user to complete the
tasks
was efficient
c. learnability of the system functionality
use of system functionality was easy to learn
78
Inderjit Singh
d. readability of the user interfaces
fine, clear and simple
42) What is your overall opinion about the project and its outcomes?
The project covered many areas in great detail. It homed in on the priorities and more
importantly demonstrated the benefits that could be gained. It demonstrated how existing
data could be utilised and more importantly how additional customer data could give a
more strategic perspective to the firm.
Pr oject Management
43) Was the project handled in a professional manner?
Extremely well managed, good communication throughout and excellent presentation. The
end presentation really turned around a very sceptical partner who at the beginning was
interested in only in the bottom line….
44) How could the project have been improved?
With more time it would have been beneficial to compare against another live service sme
and product based sme. Within the time constraints a significant amount of work was
conducted in an environment that was ill-disciplined and unstructured – it was amazing that
a POC was delivered at all given the hurdles that had to be overcome
45) Any other comments?
Now onto a product sme please…….
79
Inderjit Singh
15 Ap p e n d ix E - P a rtn e r P re s e n ta tio n s
Two partner presentations were delivered during the project. An initial presentation was delivered to establish what CRM was and why it was
applicable to the business. The feedback provided by the business validated the direction of the project. A final presentation was then delivered at the
end of the project to summarise the business benefits, and functional and data requirements that had been developed during the project. In addition,
demonstrations of each of the scenarios were provided.
15.1 P a rtn e r P re s e n ta tio n 25 th J u n e 2003
Contents of Presentation
• What is CRM?
CRM Project for Harland, • What are the benefits of CRM in the legal
industry?
Turnball and Roberts • What are the strategic and tactical advantages?
• What are the value propositions of CRM?
Inderjit Singh
• What business and IT changes are required to
realise the benefits?
• How can we go about realising an integrated view
of CRM?
80
Inderjit Singh
What are the benefits of CRM in

What is CRM?
the legal industry?
• ‘A management approach that enables Incr ease competitiveness of the fir m
organisations to identify, attract and • Focus on lawyers providing better legal services
increase retention of profitable customers • Providing more responsive client service
by managing relationships with them’ • Ensure every interaction is perceived as an
informed and valued interaction by the customer
• Focusing marketing efforts at the right
clients/prospects
How does CRM apply to the

conveyancing process? Strategic Advantages of CRM
• Conveyancing issues are raised that are only • Identify profitability of customers
related to that transaction
• Segment different types of customer e.g.
– ‘Tactical’ CRM provides efficiency and
effectiveness regarding that one transaction first-time buyers, empty nesters
• Information can be captured regarding the • Capture referral information of new
customer as well as over several customers
transactions • Understand preferred manner of interaction
– ‘Strategic’ CRM provides competitive of a customer
advantage in the customer offering
81
Inderjit Singh
Strategic Advantages of CRM Tactical Advantages of CRM

(cont.)
• Capture and understand lifestage and lifestyle • Improve efficiency in retrieval and updating of
information of customers search information regarding a customer
transaction e.g. property and title deeds issues
• Identify cross-selling opportunities for products
within the firm and for 3rd party products • Ability to provide quicker local council searches
• Highlights disparities between information
• Hold retention information by region/by provided by owner and understanding of the
segment/by branch solicitor
• Identify employee capability in relation to • Hold information regarding mortgage lender lead
providing valued customer service time for the provision of documentation
Tactical Advantages of CRM What are the value propositions

(cont.) of CRM for you?
• Provision of status information of the
conveyancing process
Understand Custom er Bett er
• Identify activities completed within a stage and the
remaining activities
• Highlight issues regarding the customer related to Partner
this specific transaction e.g. lack of sufficient Service Better Quality Customer
funds, bankruptcy search results Existing

Customer
• Ensures process completion e.g. fees paid for

different stakeholders Improve Customer Service
82
Inderjit Singh
Benefits Dependency Network

IS/IT Enabling Business Business Investment
Hierarchy of Applications
enablers Changes Changes Benefits Objectives
Capture transaction
value of each customer Analyse customer Identify profitability
information transaction information of clients
Capture and analyse Better understand

information about Improve customer
customer requirements retention
CRM system built customer Support more
on top of profitable
automated Store information Improve business customers
business processes electronically Process efficiency Increased levels of
customer service
Capture information Provide customer

about each customer history and up-to-date
interaction customer information
Define
Use coherent customer segments Improved response
Coherent database to improve rate from marketing
database and targeting segmentation campaigns
Define marketing Expand
queries
processes based on Client
Re-align sales activity segmentation Base
Reduced cost of
with new segments contacting irrelevant
customers
Track customer
sales cycle stages
Require Integrated Tactical and Strategic CRM view
Identify issues
Increased rate of
at each stage and define
follow-up of leads
processes to mitigate
Current View of CRM Focus of the Project

• Case Management System
– Could provide some tactical CRM by capturing
customer interactions (effectiveness)
• Already started…
– but currently only used to generate forms to support the • Develop proof-of-concepts demonstrating
manual conveyancing process integrated tactical CRM capabilities
• E-Conveyancing • Develop proof-of-concepts demonstrating
– Could provide some tactical CRM by quicker searches integrated strategic CRM capabilities
(efficiency) • Determination of required and applicable CRM
• But capabilities
– technologies are not integrated into the conveyancing • Initial exposure to the required integrated CRM
process roadmap
– case management and e-conveyancing systems are not
themselves integrated
– there is no strategic capability
83
Inderjit Singh
15.2 Fin a l P a rtn e r P re s e n ta tio n 1 s t Au g u s t 2003
Contents
• Review of Introductory Presentation
Final CRM Project Presentation • Project Aims & Value Propositions
for Harland Turnball & Roberts • Service-based CRM and its concepts
• Each Scenario
– Quality-gaps and Business Benefits
Inderjit Singh
– Functional and Data requirements
1/8/03 – Proof of concept implementation of business process
• Next Steps
• Evaluation
84
Inderjit Singh
Introductory Presentation Project Aims

• What is CRM? • To outline the business benefits of CRM
• What are the benefits of CRM in the legal specific to HTR
industry?
• What are the strategic and tactical advantages? • The functional and data requirements
• What are the value propositions of CRM? needed to achieve these benefits
• What business and IT changes are required to • Demonstrations of the functionality
realise the benefits?
• How can we go about realising an integrated view
of CRM?
Nature of Service-focused CRM

Partner Comments
for the legal market
• Consolidate the existing client base • Relationship Marketing
– ‘zero defections not zero defects’
• Cross-play of information and services across the
– Building relationships with customers
different offices within the same practise – Analysing Referral Markets
• Need to look for opportunities for the client • Service Quality
• Referrals both inbound and outbound as currently – Appreciate different quality reqs for different customer
informal and intangible types - ‘perceived service quality’
– Understand quality requirements
• Internal service quality
• Service delivery quality
– Identify Quality Gaps
85
Inderjit Singh
Scenario 1 – New Case

IS/IT
enablers
Enabling
Changes
Capture transaction
Business
Changes
Business
Benefits
Investment
Objectives integration of processes
information
Capture and analyse

transaction information
Better understand
of clients
• Quality Gaps
Improve customer
– eConveyancing process requires manual

information about customer requirements
CRM system built customer retention Support more
creation of forms e.g. 94A, LLC1

automated Store information Improve business customers
customer service
Capture information
about each customer
interaction
Provide customer
history and up-to-date
customer information
– No historical data captured when
Define
eConvenyancing case closed
– No system determination if customer is a
Coherent database to improve rate from marketing
database and targeting segmentation campaigns
new/existing customer (reliant on employee

Define marketing Expand
queries
knowledge)
Reduced cost of
customers
Track customer
sales cycle stages
Identify issues
Increased rate of
follow-up of leads
86
Inderjit Singh
Scenario 1 – New Case Scenario 1 – New Case

integration of processes integration of processes
• Business Benefits • Functional requirements
– eConveyancing case can be captured on DPS – Check if existing customer record in database
system – Capture product type information
• eConveyancing historical data can be captured – Create and maintain new econveyancing and
• eConveyancing cases automatically generate forms conveyancing cases
– Quick Customer Summary – Query database to provide customer summary
• Impr oved business pr ocess efficiency • Data requirements
• Integr ation of Conveyancing and – Customer, ProductType, Property, Estate Agent,
Customer Case tables
eConveyancing - homogenous pr ocesses
Scenario 2 – Service Cycle Scenario 2 – Service Cycle

• Quality Gaps • Business Benefits
– Cases only handled by case owner (knowledge – Provide customer history and up-to-date
in head) customer information
– Allow any employee to provide status to
– Limited case status functionality available for
customer
conveyancing cases (mainly manual)
– Capture of issue and management of the
– No capture of issues or issue resolution resolution of issues
• No Defined Ser vice Cycle • Incr eased levels of customer ser vice
– Pr ocess effectiveness
87
Inderjit Singh
Scenario 3 – Online Searches

Scenario 2 – Service Cycle
NLIS Searchflow
• Functional requirements • Quality Gaps
– Retrieve customer case information from database
– Laborious search process
– Capture and update case stage information
• Labour intensive
– Capture and update case issue information
• Business Process Inefficiency impacts customer
– Capture Branch and Solicitor information perceived service quality
• Data requirements
– Customer Process Status, Process Issues, Sale Process
Stages, Purchase Process Stages, Branch, Solicitor
tables
Scenario 3 – Online Searches Scenario 3 – Online Searches

NLIS Searchflow NLIS Searchflow
• Business Benefits • Functional Requirements
– Searches submitted and tracked online – Creation of a customer search instruction
– Established integration between DPS and NLIS – Address validation
Searchflow – Allow the user to define the property boundaries using
maps
– Identifies relevant searches for the specific customer
property – Select relevant searches
– Review of instruction
• Impr oved Business Pr ocess Efficiency
• Data Requirements
– Impr oved customer ser vice
– Instruction, SearchType, RequiredSearches, Required
– Reduced r esour ces r equir ed HMSearches tables
88
Inderjit Singh
Scenario 4 – Inbound Referral

IS/IT
enablers
Enabling
Changes
Business
Changes
Business
Benefits
Investment
Objectives
Information
Capture transaction
• Quality Gaps
information transaction information of clients
Capture and analyse Better understand
– No inbound referral information captured

information about Improve customer
customer requirements retention
CRM system built customer Support more
automated Improve business customers
– No indication of profitability of referral types
Store information
customer service
Capture information
about each customer
Provide customer
history and up-to-date or of specific referrers
interaction customer information
Define
– No data regarding customer transaction value
Coherent
database and
database to improve
targeting segmentation
rate from marketing
campaigns
Expand
– No formalised understanding of referral
network
queries Define marketing
Reduced cost of
customers
Track customer
sales cycle stages
Identify issues
Increased rate of
follow-up of leads
Scenario 4 – Inbound Referral Scenario 4 – Inbound Referral

Information Information
• Business Benefits • Functional requirements
– Capture customer segment information
– Identify profitability of referral types and of
– Capture referrer information (including existing
specific referrers customers)
– Establish an inbound referral network – Capture conveyancing instruction information
– Capture transaction value of customer – Create Referral Report by segment, instruction or
referral type
– Capture profitability of referral types/referrers – Capture Fee Price information
across different customer segments • Data requirements
– ConveyancingInstruction, Segment, ReferralType
tables
89
Inderjit Singh
Scenario 5 – Targeted Cross- Scenario 5 – Targeted Cross-

Selling Selling
• Quality Gaps • Business benefits
– No information held about customer segment – Creation of customer profile
requirements – Targeted questioning based upon customer profile
– Provision of scripting to provide relevant actions
– No targeted interaction based upon customer
– Cross-selling of own/3rd party products based upon the
profile
specific customer needs
– No cross-selling of own products/3rd party – Eventually lead to improved response rate from
products based on captured customer marketing campaigns due to improved understanding of
information customer segments
Scenario 5 – Targeted Cross-

Results
Selling
• Demonstrated the functional and data
• Functional requirements
requirements to achieve the HTR business benefits
– Capture customer instruction, property type and
segment information
of CRM – both tactical and strategic
– Formulate customer profile • Provided a proof-of-concept demonstration of the
– Provide targeted questioning based upon customer business processes showing how these
profile requirements can be realised
– Provide targeted actions based upon the responses to • Created online system that would provide cross-
the questions play of information and services across the
• Data requirements different offices within the same practise
– Segment, Instruction, PropertyType, SegmentQuestions • Demonstrate how a system could be used to drive
tables an integrated CRM process
90
Inderjit Singh
Additional Insights Next Steps

• Use of Events Diary and Task Diary functionality
• Confirm what functionality is required and why
within DPS can be used to support scenario2
– Events and tasks can be associated with each stage • Prioritise functional requirements
– The different types of customer interactions can be • Discuss requirements with vendors and how they
captured can be implemented
• Cost information can provide indication of • Re-define and align business processes with this
profitability and aid segmentation functionality
• DPS provides functionality to support capture of • Adjust the mindset of HTR to become
disbursements and create completion statements customer -focused (now!)
• DPS provide a ‘Cashier’ product that provide an • Develop an IS str ategy and plan
accounting package that is integrated to the case
management tool
91
Inderjit Singh
16 Ap p e n d ix F - S c re e n s h o ts
This appendix includes a screenshot for all of the user interfaces produced through the five
scenarios.
16.1 S c e n a rio 1
92
Inderjit Singh
93
Inderjit Singh
94
Inderjit Singh
95
Inderjit Singh
96
Inderjit Singh
97
Inderjit Singh
98
Inderjit Singh
99
Inderjit Singh
100
Inderjit Singh
101
Inderjit Singh
102
Inderjit Singh
103
Inderjit Singh
104
Inderjit Singh
105
Inderjit Singh
106
Inderjit Singh
107
Inderjit Singh
108
Inderjit Singh
109
Inderjit Singh
110
Inderjit Singh
111
Inderjit Singh

Specification and Design of A CRM System For Smes: Inderjit Singh MSC Information Systems 2002-2003

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Specification and Design of A CRM System For Smes: Inderjit Singh MSC Information Systems 2002-2003

Загружено:

Авторское право:

Доступные форматы

MSc Project 2003 - Specification and Design of a CRM system

Specification and Design of a

(Signature of student) _______________________________

6.2.2 Analysis and Design...................................................................................................28

15.1 Partner Presentation 25th June 2003 ...................................................................................80

1.1 Project Aims, Objectives and Requirements

1.1.1 Project Objectives

1.1.2 Minimum Requirements

1.2 Key Challenges

1.3 Structure of the Report

1.3.2 Project Management and Methodology (chapter 3)

1.3.3 Understanding the Problem (chapter 4)

1.3.4 Producing a Solution (chapter 5,6,7)

1.3.5 Evaluation of the Solution (chapter 8)

1.3.6 Conclusion and Future Work (chapter 9)

1.4 Project Solutions for the specific SME

1.5 Project Solutions for SMEs

2.1 What is CRM and why is it important?

Figure 1. The customer life cycle processes

The approach taken to maximising the profitability of a customer relationship is referred to as

2.2 What are the main CRM vendor offerings?

Capability Area Core Capability

Table 1: Outline of the core capabilities within each area of CRM

2.3 What are the SME trends for CRM?

2.4 Data Requirements for SME CRM offering

The entities noted from the user interface reviews included:

Figure 5. Boehm’s Spiral Model of evolutionary development

Stage W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13

Table 2. The Initial Project Plan based upon sequential development

4.1.1 Defining the ‘Product’ Offered

4.2 Diffe re n t Ap p ro a c h fo r S e rvic e -Ba s e d CRM

4.2.1 Relationship Marketing

4.2.2 S e rvic e Qu a lity

Figure 7. The Service Quality Gap Model

Figure 8. Business Activity model for the conveyancing process

4.4 De fin e th e P roje c t P ro b le m

Figure 9. Anthony’s Hierarchy of Applications

4.5 Id e n tifyin g th e Bus in e s s Be n e fits

Figure 10. Adoption of a Benefits Management Approach as an extension of the RUP

Figure 11. Benefits Dependency Network of CRM for HTR

4.7 Va lid a tio n o f th e P ro je c t P ro b le m

Stage W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13

5.1 Re q u ire m e n ts Wo rkflo w

5.2 An a lys is a n d De s ig n Wo rkflo ws

5.3 Im p le m e n ta tio n a n d Te s t Wo rkflo ws

Figure 15. CRM System Use Cases

6.1 S c e n a rio 1 – Integrate New Customer Case Creation

6.1.3 Arc h ite c tu re De fin itio n

Presentation Layer (HTML)

Application Layer (Java Beans)

Database Layer (MySQL)

Figure 17. Three-tier architecture supporting the CRM functionality

Figure 18. The Case Summary screen

6.2 S c e n a rio 2 – Provide Service Cycle

6.2.3 Im p le m e n ta tio n a n d Te s tin g

6.3 S c e n a rio 3 - Re d u c e S e a rc h Tim e

6.3.3 Im p le m e n ta tio n a n d Te s tin g

Figure 22. The Selection of Property Boundaries screen

7.1 S c e n a rio 4 – Capture Inbound Referral Information

The importance of establishing relationships with referrers is demonstrated in the literature. In

7.1.3 Im p le m e n ta tio n a n d Te s tin g

Figure 25. The Referral Report screen