George Fratian

Planning Your SAP CRM Implementation

Bonn Boston

196.indb 3

7/1/08 3:38:46 PM

Contents at a Glance
1

Introduction .............................................................................

21

Project Initiation .....................................................................

35

Scoping for Success .................................................................

53

SAP CRM Project Team ...........................................................

67

Project Lifecycle ......................................................................

91

Architectural Design ............................................................... 119

Case Study: CRM Interaction Center WebClient .................... 149

Case Study: CRM Case Management . .................................... 165

Case Study: Sales Force Automation (SFA) .............................. 179

10 Integration with Other SAP and Non-SAP Systems ................ 205

11 Upgrade Considerations . ......................................................... 215
12

CRM Functionality and Implementation Guidelines .............. 225

13 Total Cost of Ownership and Future Projects . ....................... 255

A

Job Descriptions . ..................................................................... 265

References ................................................................................ 269

The Author ............................................................................... 271

196.indb 7

7/1/08 3:38:47 PM

Contents
Acknowledgment . ........................................................................................ 17
Foreword ...................................................................................................... 19

1 Introduction ................................................................................ 21
1.1
1.2
1.3
1.4
1.5
1.6

Other Reference Material ..............................................................

Why This Book? .............................................................................
Book Structure . .............................................................................
SAP CRM Customer Profile ............................................................
The SAP Ecosystem ........................................................................
Summary .......................................................................................

22
24
25
27
31
32

2 Project Initiation . ...................................................................... 35

2.1 Long-term Roadmap ......................................................................
2.2 The Importance of the Business Case and Return on
Investment (ROI) ...........................................................................
2.3 Start with a Pilot Project ................................................................
2.3.1 Design and Implement the Functionality .............................
2.3.2 Train the Pilot Users ............................................................
2.3.3 Incorporate the Feedback ....................................................
2.3.4 Revise the Roadmap and Next Steps . ..................................
2.4 Strategic vs. Tactical .......................................................................
2.5 End-user Adoption ........................................................................
2.6 The Impossible Trilogy ...................................................................
2.6.1 Scope ..................................................................................
2.6.2 Time . ..................................................................................
2.6.3 Money ................................................................................
2.6.4 The Impossible Part ..........................................................
2.7 A Word on Estimating Costs ..........................................................
2.8 Quality Counts . .............................................................................
2.9 Additional Research .......................................................................
2.10 Summary .......................................................................................

35
37
40
40
40
40
41
42
45
45
46
47
48
48
49
49
50
50

196.indb 9

7/1/08 3:38:47 PM

Contents

3 Scoping for Success .................................................................... 53

3.1
3.2
3.3
3.4
3.5
3.6
3.7

The Virtual Case File Story .............................................................

Funding vs. Scope . ........................................................................
What is the Scope? ........................................................................
Scope Documentation and Tracking ...............................................
Geography Implications .................................................................
Scope Management and Exception Handling .................................
Summary .......................................................................................

53
54
56
61
62
63
65

4 SAP CRM Project Team . ............................................................ 67

4.1

4.2
4.3

4.4

4.5
4.6
4.7
4.8

Project Team Roles ........................................................................

4.1.1 Project Manager ..................................................................
4.1.2 Project Management Office (PMO) ....................................
4.1.3 Steering Committee . ...........................................................
4.1.4 Functional Team ..................................................................
4.1.5 Technical Team ....................................................................
4.1.6 Basis and Security team .......................................................
4.1.7 Infrastructure Team .............................................................
4.1.8 Change Management Team .................................................
4.1.9 Other Teams . ......................................................................
SAP Ecosystem Considerations . .....................................................
Staffing Types ................................................................................
4.3.1 In-house Staffing .................................................................
4.3.2 Consultant-run Project ........................................................
4.3.3 Hybrid (In-house Plus Consultants) ......................................
4.3.4 Financial Partnerships ..........................................................
Outsourcing Considerations ...........................................................
4.4.1 India vs. the Rest of the World ............................................
4.4.2 Other Considerations ..........................................................
Hosting Considerations ..................................................................
Relationships and Chemistry ..........................................................
Other Types of IT Organizations ....................................................
Summary .......................................................................................

68
68
69
70
70
73
74
76
77
79
80
81
82
83
84
85
86
86
86
87
88
89
90

10

196.indb 10

7/1/08 3:38:47 PM

Contents

5 Project Lifecycle . ....................................................................... 91

5.1 The ASAP Methodology . ............................................................... 92
5.2 ASAP Toolset ................................................................................. 93
5.3 ASAP Roadmap Phases .................................................................. 97
5.3.1 Project Preparation . ............................................................ 97
5.3.2 Business Blueprint ............................................................... 98
5.3.3 Realization .......................................................................... 100
5.3.4 Final Preparation ................................................................. 101
5.3.5 Go-live and Support ........................................................... 103
5.4 International Rollout Considerations .............................................. 104
5.5 Following a Release Schedule ........................................................ 106
5.6 Upgrade Considerations ................................................................. 106
5.7 Mergers and Acquisitions Considerations ....................................... 107
5.8 Additional Implementation Content .............................................. 108
5.9 Overlaying the SDLC Over ASAP .................................................... 108
5.10 SAP Best Practices for CRM ........................................................... 111
5.11 CRM Business Packages ................................................................. 113
5.12 The Adoption Curve ...................................................................... 115
5.13 Additional Considerations . ............................................................ 116
5.14 Summary ....................................................................................... 117

6 Architectural Design .................................................................. 119

6.1

6.2
6.3
6.4

6.5
6.6

The SAP Ecosystem ........................................................................ 119

6.1.1 SAP Solutions ...................................................................... 119
6.1.2 SAP Services ........................................................................ 120
6.1.3 SAP Ecosystem/Partners ...................................................... 120
Technical Landscape ..................................................................... 123
Technical Landscape Revised Again? .......................................... 128
User Interface Options ................................................................... 129
6.4.1 SAP GUI .............................................................................. 129
6.4.2 Web-based UIs . .................................................................. 132
6.4.3 Other UI Options ................................................................ 134
Internally vs. Externally Focused Portal .......................................... 136
CRM Online vs. ERP Functionality ................................................. 137
6.6.1 Order Management Options ............................................... 138
6.6.2 Customer Master . .............................................................. 141
6.6.3 Other Master Data .............................................................. 141
11

196.indb 11

7/1/08 3:38:47 PM

Contents

6.6.4 Variant Pricing and Configuration ........................................ 142

6.7 CRM Online vs. CRM Mobile ......................................................... 143
6.8 CRM On-Demand . ........................................................................ 143
6.9 Hybrid Architecture ....................................................................... 144
6.9.1 SAP + Non-SAP .................................................................. 145
6.10 Other Considerations ..................................................................... 145
6.10.1 BI Refresh . .......................................................................... 145
6.10.2 Backups . ............................................................................. 146
6.10.3 System Copies ..................................................................... 146
6.11 Summary ....................................................................................... 147

7 Case Study: CRM Interaction Center WebClient ...................... 149

7.1
7.2

7.3

7.4
7.5

A Summary of the New ICWC Functionality in CRM 2007 ............. 149

ICWC a Pilot Project . ................................................................ 150
7.2.1 Initial Scope ....................................................................... 151
7.2.2 Implementation Aspects . .................................................... 152
7.2.3 Issues and Troubleshooting . ................................................ 158
ICWC the Next Steps . ............................................................... 159
7.3.1 Order Integration ................................................................ 159
7.3.2 CTI Integration .................................................................... 161
7.3.3 Third-party Web Services Integration . ................................. 162
Lessons Learned ............................................................................ 163
Summary ....................................................................................... 163

8 Case Study: CRM Case Management ........................................ 165

8.1
8.2
8.3

8.4
8.5

A Summary of the New Case Management Functionality in

CRM 2007 ..................................................................................... 165
High-level Scope for Case Management ......................................... 167
Scope in Detail .............................................................................. 168
8.3.1 Case Classification ............................................................... 168
8.3.2 Automatic Routing .............................................................. 169
8.3.3 Case Notifications/Alerts ..................................................... 171
8.3.4 Automatic Case Creation ..................................................... 172
8.3.5 Automatic Escalation ........................................................... 173
One Type of Case Management and Two Access Methods ............. 176
Lessons Learned ............................................................................ 177

12

196.indb 12

7/1/08 3:38:47 PM

Contents

8.6 Other Considerations ..................................................................... 177

8.7 Summary ....................................................................................... 178

9 Case Study: Sales Force Automation (SFA) ................................ 179

9.1 A Summary of the New SFA Functionality in CRM 2007 ................ 179
9.2 High-level Scope of the SFA Implementation ................................. 180
9.2.1 Business Processes First ....................................................... 181
9.2.2 Tailor the Technical Solution to Real Business Needs ........... 183
9.2.3 User Interface Revisited .................................................. 185
9.3 Scope in Detail ............................................................................. 186
9.3.1 Account Management ......................................................... 186
9.3.2 Opportunity Management ................................................... 189
9.3.3 Contact Management .......................................................... 191
9.3.4 Reporting ............................................................................ 192
9.4 The Importance of Clean Master Data . .......................................... 192
9.4.1 External Data Sources Might Be an Option .......................... 193
9.4.2 Territory Management Considerations ................................. 195
9.4.3 Legacy Data Sources and Quality Control ............................ 196
9.5 Non-standard Functionality ........................................................... 197
9.6 Speeding Up the Access a Citrix Mini-Case Study ...................... 199
9.7 Change Management and the WIIFM Concept .............................. 201
9.8 System Ownership ......................................................................... 203
9.9 Other Considerations ..................................................................... 204
9.10 Summary ....................................................................................... 204

10 Integration with Other SAP and Non-SAP Systems .................. 205

10.1 Native Integration in an SAP Environment ..................................... 205
10.1.1 SAP Middleware . ................................................................ 205
10.1.2 Running Parallel ERP and CRM Projects . ............................. 208
10.1.3 CRM and ERP Always a 1:1 Relationship? ....................... 209
10.1.4 Other Out-of-the-box Integration Technologies ................... 210
10.2 Integration vs. Interfacing Considerations ...................................... 211
10.3 Summary ....................................................................................... 213

13

196.indb 13

7/1/08 3:38:47 PM

Contents

11 Upgrade Considerations ............................................................. 215

11.1 Functional Upgrades ...................................................................... 215
11.2 Technical Upgrades ........................................................................ 216
11.3 Functional Reimplementations . ..................................................... 217
11.3.1 Determining the Optimal Upgrade Type .............................. 217
11.3.2 Business and IT Impact on the Upgrade ............................... 218
11.4 Minor vs. Major Upgrades ............................................................. 219
11.4.1 Minor Upgrades .................................................................. 219
11.4.2 Major Upgrades .................................................................. 220
11.4.3 A Note on Upgrades from Gartner ....................................... 221
11.5 Upgrade Considerations for Your Entire SAP Landscape ................. 222
11.6 Summary ....................................................................................... 222

12 CRM Functionality and Implementation Guidelines . ............... 225

12.1 Before We Start ............................................................................. 225
12.2 Sales .............................................................................................. 227
12.2.1 Sales Introduction .............................................................. 227
12.2.2 Sales Implementation Suggestions . .................................... 231
12.3 Service . ......................................................................................... 236
12.3.1 Service Introduction ........................................................... 236
12.3.2 Service Implementation Suggestions .................................. 236
12.4 Marketing . .................................................................................... 239
12.4.1 Marketing Implementation Suggestions . ............................ 240
12.4.2 Web Channel ..................................................................... 243
12.4.3 Web Channel Implementation Suggestions ........................ 245
12.4.4 Partner Channel Management ............................................ 247
12.4.5 Partner Channel Management Implementation
Suggestions ....................................................................... 248
12.4.6 Field Applications .............................................................. 249
12.4.7 Field Applications Implementation Suggestions . ................ 250
12.4.8 Industry Solutions .............................................................. 252
12.5 Summary ....................................................................................... 253

14

196.indb 14

7/1/08 3:38:47 PM

Contents

13 Total Cost of Ownership and Future Projects ........................... 255

13.1 A Word on Total Cost of Ownership (TCO) and the
Controlled Growth of Your Environment ........................................ 255
13.2 The Future is Now ......................................................................... 257
13.3 Summary ....................................................................................... 261

Appendices......................................................................................... 263
A Job Descriptions . .................................................................................... 265
A.1 CRM Sales Functional Consultant . ................................................. 265
A.2 CRM Technical Consultant ............................................................. 266
A.3 BASIS Consultant ........................................................................... 267
A.4 CRM Field Apps Functional Sales Consultant ................................. 268
B References .............................................................................................. 269
C The Author ............................................................................................. 271
Index.............................................................................................................. 273

15

196.indb 15

7/1/08 3:38:47 PM

Scoping for Success

Why is controlling the scope such an important task for any project?
To answer this question, its useful to state that at some level everyone understands the importance of keeping the scope under control. The term scope creep
means the initially agreed-upon scope for a project has actually been significantly
changed due to additions and modifications. Please note that from a pure scope
control perspective, it doesnt matter if these additions and changes are value
added or not. What matters is the project started with a set of business requirements that were significantly changed during the course of the project. The key
word here is significantly, because theres almost no Information Technology (IT)
project that will not suffer some minor changes while in development. The level
of changes is whats important here!

3.1

The Virtual Case File Story

Because we all like to learn from history lessons, well discuss the FBIs Virtual
Case File project a software project disaster. While this project isnt necessarily
a typical Customer Relationship Management (CRM) one, it will probably drive
the point home much better than any other lesser known story.
In the early 2000s, the FBI had started a project that later become one of the biggest software disasters in history. The FBI had an antiquated case system, based on
an archaic combination of old software and paper-based information. This system
did not help the organization in dealing with new terrorism threats in an efficient
manner, so the FBI had identified a clear need for a new system. In September
2000, the Congress approved $380 million over a three-year period for a project
initially called the FBI Information Technology Upgrade Project.
The most ambitious part of this program was the Virtual Case Filesystem (VCF),
and that portion of the contract was awarded to SAIC of San Diego. Interestingly
enough, the contract was of the cost plus variety, which allowed the contractor
(SAIC) to bill for the actual work, even if the work will take longer than initially

53

196.indb 53

7/1/08 3:38:53 PM

Scoping for Success

estimated. SAIC and the FBI chose to develop a custom system that would fulfill
all of the FBIs business requirements.
The requirements grew significantly over the course of the project to over 800
pages. The FBIs IT management changed several times during the next three
years and SAICs programmers had to allow constant requirement changes that
impacted the code already developed. During 2003 alone, there were more than
400 changes allowed! This approach, where scope control was almost an afterthought, brought a clear analogy between the VCF project and the Babel tower
it became impossible for anyone to guarantee compatibility between the various
software components and releases.
To make a long story short, in April 2005, the FBI killed the VCF project, at a total
cost of over $170 million.
The VCF systems story makes for a fascinating read, sometimes even surreal, and
if this had happened in a private company instead of a government agency, this
disaster would likely have led to bankruptcy for that organization. Fortunately (in
a manner of speaking), the government cannot go bankrupt.
Note
If you are interested in more details about the FBIs VCF project, please refer to the
excellent article, Who Killed the Virtual Case File? by Harry Goldstein.4

3.2

Funding vs. Scope

Before we discuss scope in detail, we should discuss the balancing act the management of the project has to perform from the very beginning. At the onset of the
project, the project manager puts together a project plan that consists of the major
tasks to accomplish in order to deliver the project. The major milestones should
be incorporated in the project plan as well.
Its important (but not critical at this stage) to drill down to a very granular level
of detail in the project plan. Its probably a safer approach to start with a higher
level project plan and refine it continuously as long as there is enough detail
to make the entire planning exercise worthwhile. The project plan will give the
manager the fundamental tool to estimate the cost associated with the project, and
the duration. The project plan can also present an accurate picture of the resources
needed, and their loading. Going back to our scope topic the project plan has

54

196.indb 54

7/1/08 3:38:53 PM

Funding vs. Scope

3.2

to present the scope in such a fashion that it will make it easily traceable against
the list of requirements. At the end of the project you should be able to track the
developed or configured functionality back to the original requirements (plus any
changes allowed and documented during the project).
Budget = function (scope)

What we mean by this equation is that your scope will drive the budget allocated
to your project. Ideally, you will agree first on the high- and medium-level scope,
and then start estimating the budget. However, there are instances when you are
given the budget, and you have to determine the scope. It does not really matter
which is the constraint as long as you have one of the factors, you can determine the other. The duration of the project depends on how many activities can
realistically be run in parallel.
The projects budget will have to represent an accurate depiction of all of the costs
associated with the project at least from an IT perspective (many CRM projects
do not quantify the cost associated with the business work, which understates the
total cost, and makes for a better looking Return on Investment (ROI) number).
This does not mean that work is negligible, or less important, but it means the
cost associated with the business analysts and the business participation is borne
by the respective departments.
The total cost of your project might understate the real cost for the company from
anywhere between 10% and 20%, depending on your specific circumstances. As
long as this cost understatement is understood by everyone, this is considered an
accepted business practice even if its not an elegant one.
The biggest costs associated with any CRM project
EE

SAP CRM software (usually included in the SAP license; also covers the ERP, Portal,
BI, etc.)

EE

Annual software maintenance fee (typically around 18% but depends on your particular contract); the first year is waived

EE

Internal IT costs (systems analysts, project managers, team leaders, etc.)

EE

External IT costs (consultants)

EE

Business resources costs (business analysts, process owners, etc.)

EE

End-user training (trainers and development of the training material)

EE

Project team training (SAP classes for the team; include the travel costs)

55

196.indb 55

7/1/08 3:38:53 PM

Scoping for Success

EE

Testing (some companies have a dedicated independent QA team, while others may
do the testing with the IT and/or the business resources not recommended)

EE

Cost of decommisioning the legacy systems (and/or maintaining them in parallel for
historical reasons)

Depending on your circumstances, the weight of the preceding cost categories

might be in a different order.
Its everyones responsibility to adhere to the initially approved scope, but the
project manager has the unenviable task of managing the scope creep. In order to
be successful in this task, the project manager needs the full support of the project
sponsor and the Steering Committee. The escalation path has to be very clear and
the escalation process has to allow for quick resolutions.

3.3

What is the Scope?

The scope associated with a project is the sum of the business requirements gathered during the course of the Blueprint exercise (more on this later), plus any
additional tasks that have to be performed in order to support the delivery of said
business requirements.
The business requirements describe the features and functions required to execute
certain business processes. A good business requirement will not prescribe how
that feature or function is implemented.
Note
There are numerous templates that help in capturing the business requirements, but
theyre all basically the same. As long as you concentrate on the quality of the gathered
requirements, the template used to document those requirements matters less. The
ASAP methodology and toolset that SAP software uses has a template than can be used
successfully.

Table 3.1 has a few examples of business requirements mixed together with their
possible solutions:

56

196.indb 56

7/1/08 3:38:54 PM

What is the Scope?

Correct Business Requirements

Incorrect Business Requirements

1. Be able to capture the contacts details

(first name, last name, address, telephone
number, mobile number, email address)

1. Capture the contacts details in a matrix

format

2. Be able to document and classify the

feedback received from the customer

2. Document and classify the feedback

received from the customer in a text box,
with sections for each type of feedback

3. Be able to raise an online order and

instantly provide the product availability
information

3. Raise an online order and instantly provide

product availability information based on
stock availability maintained in the ordering website

3.3

Table 3.1 Examples of Correct and Incorrect Business Requirements

Note
The requirements listed in Table 3.1 are just examples. The requirements in your real-life
project will not be as cut and dry as these.

While defining business requirements without implying a technical solution is a

de facto best business practice, you also have a more selfish reason to insist on this
principle. If you dont insist on it, your implementation of the SAP CRM package
will be harder, because the requirement already prescribes how that feature or
function actually works.
Lets discuss the three requirements listed in Table 3.1 in a bit more detail.
EE

Requirement 1 
When we are talking about a contacts details, we are always thinking about
the name, address, and so on. Its counterproductive to specify how one would
capture the format of this information as the newly specified format may run
against the design principles already embedded in that particular software. If
you refer to the Contact Management functionality discussed in Chapter 2 (see
Figure 2.2), how would you implement this contact functionality in a matrix
format? You will have to heavily modify the SAP screen for an illusory benefit.
This makes no sense!

EE

Requirement 2 
The feedback received from a customer can be classified in various categories:
suggestions, complaints, documentation requests, etc. While a superficial look
documenting and classifying the feedback received from the customer in a text

57

196.indb 57

7/1/08 3:38:54 PM

ScopingforSuccess

box, with sections for each type of feedback, may make sense, lets think about
how this requirement may look in practice (Figure 3.1).

Figure 3.1 A Possible Implementation for the Customer Feedback Requirement

As you can see from Figure 3.1, this solution is technically feasible, but quite
inelegant. Lets look at how SAP CRM will handle the same business requirement
within Case Management (Figure 3.2).

Create three new text types:

Suggestion
Complaint
Documentation Request

Figure 3.2

Customer Feedback Requirement as Standard Functionality within Case Management

58

196.indb 58

7/1/08 3:38:56 PM

WhatistheScope?

3.3

Its clear the option depicted in Figure 3.2 is a lot more elegant than the previous
one. This is due to the fact that SAP software already refined this functionality over
the last few releases of CRM, and it already incorporates a lot of feedback from
numerous customers. What works for thousands of SAP customers, is probably
going to work for you as well.
This is not to say that you will not encounter instances where the basic functionality
is going to be insufficient. If thats the case with the particular business requirement
at hand, feel free to develop whatever feature is important for the end users.
EE

Requirement 3
When ordering online, the stock availability is one of the most important features
for an online store. How frustrating would it be to place an order for a childs
birthday, just to receive an email a few days later that the item was out of stock?

That being said, a requirement that prescribes how the availability check is performed is inferior to a requirement that plainly states how an availability check
should be performed. In the case of the bad requirement, that availability check
must be based on data that someone needs to maintain at the website level
definitely something that will create issues down the road. In SAP CRM you
can rely on a real-time availability check performed against either the ERP or
the SCM (APO) systems (if so desired). Prescribing the requirements technical
implementation is never a good idea.
Lets see one example of such a business requirement: the account management
functionality in CRM provides very good access to the account data, as depicted
in Figure 3.3.

Figure 3.3

Basic Account Management functionality

59

196.indb 59

7/1/08 3:38:57 PM

ScopingforSuccess

However, some SAP customers have a business requirement to present the various
relationships between their own customers in a hierarchical fashion. Lets think
about a company that sells products to the healthcare industry. They may sell their
wares to the hospital chain headquarters (Integrated Delivery Network or IDN),
but they also want to see the independent hospitals that are part of this structure.
This is how this business requirement was implemented for one SAP customer (see
Figure 3.4) more about this topic in Chapter 9.

Figure 3.4

Enhanced Account Management Functionality

Note
Please treat the nonstandard functionality as a last-resort option. Not only is changing
the SAP functionality expensive and problematic to upgrade, but it can also play an
undesired role in your scope creep battle (it is very hard to limit the development for a
non-SAP standard functionality because the end users will always want to tweak it).

Generally speaking, the more general the business requirement definition is, the
easier it will be to implement. You will map each requirement with the available
functionality in the CRM system, and then plan on how to address any eventual
remaining gaps.
At the beginning of this section, we defined the scope as the sum of the business
requirements, plus any additional tasks that have to be performed in order to support the delivery of said business requirements. These tasks range from the initial
software installation and testing, the procurement of the hardware required for
your CRM system (and other SAP systems), the testing of the developed functionality, the project management activities, etc. As you can see, theres a lot youll have
to consider when you look at the project scope from a holistic point of view.
60

196.indb 60

7/1/08 3:38:57 PM

ScopeDocumentationandTracking

3.4

3.4

Scope Documentation and Tracking

Later in the book well discuss the lifecycle of an SAP project, but one of the first
things that you have to do after deciding on a project is to determine the exact
scope (even if its your first pilot project). The best way to start the requirements
gathering process is to go through a series of workshops with the business. As
well see in more detail in Chapter 5, SAP software provides a lot of templates that
you can use at your leisure and heres an example of a template for gathering
the business requirements for a webshop (see Figure 3.5).

Figure 3.5

Sample Template for Gathering Business Requirements

A typical workshop will take between two and four hours for a given business
process (longer for more complex business processes). During the workshop, the
business will describe the inner workings of the business process. Eventually, the
content of the workshop will be refined into the requirements documents for your
project (finalized during the blueprint phase).
At this stage its impossible not to mix apples and oranges so when running
those workshops its important to understand the software capabilities, so you
can guide your Business partners on the embedded Best Business practices in SAP
CRM. Its also important to see if there is any business reengineering opportunities if you identify a bloated, inefficient business process, theres no better time
to reengineer it than now, before you start implementing the CRM software.

61

196.indb 61

7/1/08 3:38:58 PM

Scoping for Success

So, as long as you strike a good balance between these centrifugal tendencies (basic
business requirements, software capabilities, and reengineering opportunities), the
mix obtained at the end of the workshop series should work quite well.
When everything is said and done, your scope will be well documented and available for everyone. As always with documentation, you may want to store it in a
change-controlled environment (very important for Food and Drug Administration
(FDA) controlled companies). The scope documents will also be used for testing.
Your projects test scripts will have to refer back to the scope items this is how
you can ensure that what was initially agreed upon, functionality-wise, is whats
being delivered.
Tip
The best method to ensure whats delivered is indeed what was initially requested, is
to employ a traceability matrix that relates the functionality being delivered against the
original requirements.

3.5

Geography Implications

Up to this point, we havent considered any geographical implications for your

CRM project. From a geography standpoint, there is good news and bad news. The
good news is that all SAP systems, CRM included, are natively multi-language and
multicurrency capable. The bad news is that all SAP systems, CRM included, have
to be configured to support multiple languages and currencies. Lets say your U.S.
company has a Canadian division. In order to do business in both the U.S. and
Canada, you have to be able to provide various legal documents in both English
and French (documents localized for each country). While this requirement may
not seem to be something that you have to worry too much about in a CRM project, there are instances when different languages and currencies are still important.
For example, if you have an online store, your product descriptions will have to
be available in both English and French, while the prices will have to be available
in U.S. and Canadian dollars.
The point is that youll have to consider the geographical implications of your
project. If you deliver functionality across multiple countries and languages, think
about the impact on your scope.

62

196.indb 62

7/1/08 3:38:58 PM

Scope Management and Exception Handling

3.6

While scope control is a very important area, there will always be justifiable additional business requirements that will have to be implemented in the middle of
a project. This is where scope control will play a huge role, and as such, help the
project team to distinguish between the so-called scope creep and the important
business requirements that you cannot shy away from implementing.

3.6

Scope Management and Exception Handling

After the Blueprint phase of your CRM project is completed, you should have a
very good project plan, know how long it will take you to deliver the agreed upon
scope, and know how many resources you will need.
You may also want to have a formal signoff for your scope document. While this
approach is not necessarily the most palatable one, it will help enforce the scope
control activities.
Its human nature to be imperfect (thats the reason we invented computers!).
People will forget to mention some requirements that are perhaps obvious from
their point of view, or they will think about various bells and whistles (disguised
as new requirements), so keeping a close tab on your scope is paramount. Your
message to the business has to be very clear: any additional piece of scope has a
price tag associated with it (the same goes for changing the agreed-upon scope).
Keep in mind that oftentimes the business is stuck in an everything we want to
add is critical for the success of the project mode, and its very hard to negotiate
with them if thats the stage-setting message. But at the end of the day, youll have
to deliver your CRM project on time, and on budget.
Because we now know the scope drives the budget, and by extension, your timeline, its obvious why you need to be a scope hawk. A good project manager will
embed some maneuvering margin in his project plan (anywhere between 10%
and 25%). Because you cant always say no to your business partners, so use that
margin judiciously. You can, however, always negotiate with your business clients
on what additional scope can be realistically added, versus what existing requirements can be dropped out of scope. As long as you are still going to maneuver
inside your margin youll be fine. And while its very important to control the scope
during the project, not too many people will worry about the scope at the end of
the project.

63

196.indb 63

7/1/08 3:38:58 PM

Scoping for Success

Tip
Please make sure that you have a well-defined scope change process, so everyone,
including the business, will understand from the get-go the importance of gathering
complete and accurate requirements.

There will be cases when the additional scope requested in the middle of the project is apparently non-negotiable from the businesss perspective. If you arent
comfortable with changing the scope so late in the game, you can always escalate
the issue. Your Steering Committee and your project sponsor are the ones called
into action in order to solve this conflict. If they will uphold the initial scope,
the business will have to live with that decision. On the contrary, if they will
allow these business requirements to be added to the scope, then you will have
a freehand to re-determine one or more of the following: the budget or the duration. Just make sure the impact associated with the scope change is understood
by everyone!
Note
There are instances when the scope has to be modified in a substantial fashion the
typical example is an acquisition. If, for example, your company is acquiring another
company, and you want to allow the additional users gained through that acquisition
into your CRM system, they may have additional business requirements that were not
considered previously. Some of those new requirements will always be justified. Please
remember to communicate the impact on the project (budget or time wise). Theres no
such thing as over communication.

So, what are the lessons that we need to extract from this entire chapter? First and
foremost, having a very strict scope control in place is mandatory for a successful
CRM project. By itself, the scope control will not guarantee success, but its absence
will almost undoubtedly guarantee failure. You may ask so where should we
draw the line? Unfortunately, theres no definitive answer to this question. Each
project will have to draw a line in the sand on what changes are acceptable and
what changes are not acceptable. Generally speaking, you dont want to have a
high percentage of changes, as they relate to the original scope. Various sources
quote an acceptable level of change as anywhere between 5% and 15% of the original scope, but youll be safer if you strive for the lower end of that interval.

64

196.indb 64

7/1/08 3:38:58 PM

Summary

3.7

3.7

Summary

EE

Scope control is paramount!

EE

Budget = function (scope); time depends on how many activities can be realistically run in parallel.

EE

Understand your total cost structure.

EE

Understand how to phrase a good business requirement; explain to your business clients the way to properly state the requirement.

EE

Nonstandard functionality is appealing, but its also expensive and problematic

to upgrade.

EE

Document, track the implementation, and measure the delivery of your scope.

EE

Use the escalation process to control the scope creep.

In the next chapter well discuss the project team structure, with examples from a
medium-size CRM project.

65

196.indb 65

7/1/08 3:38:58 PM

Index
A
Account identification, 153
Account management, 59
Account Management, 186
Account Management , 180
Adobe forms, 135
Adoption, 45
Adoption curve, 115
Advanced Planner and Optimizer (APO), 31
Alerts, 171
Application Service Provider (ASP), 78
Architectural design, 119
ASAP methodology, 91, 105
ASAP roadmap for upgrades, 221
ASAP toolset, 93
ASUG, 258
ATP, 231
Automatic case creation, 172
Automatic escalation, 173
Automatic routing, 169
Available-to-Promise (ATP), 32

B
BAPI, 210
Baseline, 100
Basis, 93
Basis team, 40, 74
Best business practices, 100
Best practices, 111
Big bang, 42
BI (Business Intelligence), 75
BI refresh, 145
Blueprint, 63
BPR (Business Process Reengineering), 99
Business analysts, 48, 99
Business Analysts (BA), 72
Business blueprint, 98
Business Intelligence (BI), 31
Business objects, 32

Business reengineering, 61
business requirement, 40
Business requirement, 46
Business requirements, 53, 56, 99
Business Server Pages (BSP), 132

C
Cable, 200
Case classification, 168
Case management, 151, 165
Case Management, 43, 58
Case notifications, 171
CDMA, 184
Change management, 70, 77
Change Management , 201
Chemistry, 88
Citrix, 185, 199
Configuration, 124, 142
Consulting partner, 83, 92
Contact Management, 40, 46, 191
Contact Management, 180
CRM 200x conferences, 258
CRM billing, 238
CRM conference, 258
CRM heavy, 231
CRM light, 233
CRM mobile, 249
CRM Mobile, 143
CRM (Customer Relationship Management),
75
CRM On-demand, 143
CRM online, 249
CRM Online, 137, 143
CRM Online , 183
CRM_UI_FRAME, 225
C-suite, 182
CTI, 256
CTI integration, 161
Custom code, 73
Customer master, 141

273

196.indb 273

7/1/08 3:40:10 PM

Index

Customer satisfaction, 44
Customer Service agents (CSR), 43
Cutover plan, 104

D
Data Base Administration (DBA), 76
Database administrator, 76
detached scenario, 183
download speeds , 185
DSL, 200
Duet, 135
Dun and Bradstreet , 193

E
EDGE, 184
EDI, 231
Enhancements, 100
ERP (Enterprise Resource Planning), 32, 75
E-selling, 139
EVDO, 200
Evolution-Data Optimized (EVDO), 184
Externally focused Portal, 136

F
Failure rate, 35
Field applications, 249
Final configuration, 100
Final preparation, 101
Formal signoff, 63
Functional reimplementations, 217
Functional team, 70
Functional upgrades, 215
Funding, 54
Future projects, 255

Global template, 95
Go-live and support, 103

H
high-speed Internet , 200
Hosting, 87
Hybrid architecture, 144
Hybrid staffing, 85

I
ICWC framework, 151
IDES, 117
IDoc, 210
Implementation, 95
Implementation Guide (IMG), 124
Implementation methodology, 91
Impossible trilogy, 45
Industry solutions, 252
Infrastructure, 76
Integration, 211
Integration technologies, 210
Interaction Center WebClient (ICWC), 41, 149
Interfacing, 211
Internally focused portal, 136
International rollout, 104
Whats In It For Me (WIIFM), 192

K
Knowledge database, 156
Knowledge Management (KM), 32
Knowledge transfer, 100

L
Landscape, 122
Logical landscape, 123
Long-term trade planning process, 239

Gartner, 221
Geography, 62

274

196.indb 274

7/1/08 3:40:10 PM

Index

M
Major upgrades, 220
Marketing, 239
Marketingpro role, 239
Master Data, 37, 141, 192
Master Data Czar , 194
Master Data Management (MDM), 74
Matrix environment, 89
MCRM scenario, 209
Meta Group report, 35
Middleware, 205
MII, 193
Minor upgrades, 219
Mobile Sales, 183
Modification, 219
Money, 45, 48
Multicurrency, 62
Multilanguage, 62

Pilot users, 40
portal, 122
Pricing routines, 139
Project delivery, 69
Project lifecycle, 91
Project Management Institute (PMI), 68
Project Management Office (PMO), 69
Project manager (PM), 56, 68, 88, 97
Project organization chart, 67
Project plan, 54, 69
Project preparation, 97
Project sponsor, 44, 64, 70, 88, 97
Project status report, 258
Project team roles, 68

Native integration, 205

Nonstandard Functionality, 60, 197

Ramp-up, 117
Realization, 100
Release schedule, 106
Remote access, 122
Reporting , 180, 192
Roadmap, 35, 50, 91, 94, 221
Rollout, 41

Opportunity Management, 41, 71, 180, 189

Optimal upgrade type, 217
Order entry, 139
Order integration, 159
Order to Cash (OTC), 70, 231
Organization structure, 174
Outsourcing, 86

Sales, 227
Sales Force deployment, 180
Sales forecast, 181
SALESPRO role, 227
SAP BI (Business Intelligence), 120
SAP CRM (Customer Relationship
Management), 21, 120
SAP Ecosystem, 31, 80, 119
SAP EP, 120
SAP ERP, 120
SAP GUI, 106, 129
SAP GUI for HTML, 129
SAP GUI for Java, 129
SAP GUI session, 225
SAP MDM , 194
SAP Middleware, 205
SAPPHIRE, 258

P
Partner product range, 29
Party web services integration, 162
PCUI, 106
Phased approach, 42
Pilot project, 40, 51, 150
Pilot scope, 42

275

196.indb 275

7/1/08 3:40:10 PM

Index

SAP SCM, 120

SCM (Supply Chain Management), 75
Scope, 45, 54, 62, 63
Scope creep, 53, 101
Scratch pad, 156
Screen layout, 188
SDLC, 108
Service, 236
Service pack, 219
Servicepro role, 236
SFA, 256
SFA , 179
Sign-off, 104
Single Sign On (SSO), 32, 189
Solution Database, 151, 156, 256
Solution Manager, 75, 93, 206
SRM (Supplier Relationship Management), 75
Staffing types, 81
Stakeholders, 40
Standard functionality, 100
Steering Committee, 64, 70, 88
Strategic project, 42
Success rate, 35
Supplier Relationship Management (SRM), 31

Technical team, 73
Technical upgrades, 215
Territory management , 194
Time, 45, 47
Trade Promotion Management (TPM), 241
TREX, 156

U
Upgrade, 96, 106, 215
Upgrade paths, 216
Upload bandwidth, 185
User interface (UI), 129, 185

V
Variant configuration, 231
Variant pricing, 142
Verispan SMG, 193
Virtual case file, 53

W
T
Tactical project, 42
TCO (Total Cost of Ownership), 213, 255
Team selling, 77, 182
Technical landscape, 76, 123, 128

Warranty period, 104

Web Channel, 243
WebClient UI, 106, 132
Wireless card, 200
Workshops, 41

276

196.indb 276

7/1/08 3:40:11 PM