Planning Your SAP CRM Implementation · George Fratian Planning Your SAP® CRM Implementation Bonn...

George Fratian

Planning Your SAP® CRM Implementation

Bonn � Boston

196.indb 3 7/1/08 3:38:46 PM

http://www.sap-press.com

7

Contents at a Glance

1 Introduction ............................................................................ 21

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

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

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

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

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

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

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

9 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

B References ............................................................................... 269

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

196.indb 7 7/1/08 3:38:47 PM

www.sappressbooks.com

9

Contents

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

1 Introduction ............................................................................... 21

1.1 Other Reference Material .............................................................. 221.2 Why This Book? ............................................................................ 241.3 Book Structure .............................................................................. 251.4 SAP CRM Customer Profile ........................................................... 271.5 The SAP Ecosystem ....................................................................... 311.6 Summary ...................................................................................... 32

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

2.1 Long-term Roadmap ..................................................................... 352.2 The Importance of the Business Case and Return on

Investment (ROI) .......................................................................... 372.3 Start with a Pilot Project ............................................................... 40

2.3.1 Design and Implement the Functionality ............................ 402.3.2 Train the Pilot Users ........................................................... 402.3.3 Incorporate the Feedback ................................................... 402.3.4 Revise the Roadmap and Next Steps ................................... 41

2.4 Strategic vs. Tactical ...................................................................... 422.5 End-user Adoption ....................................................................... 452.6 The Impossible Trilogy .................................................................. 45

2.6.1 Scope ................................................................................. 462.6.2 Time ................................................................................... 472.6.3 Money ............................................................................... 482.6.4 The “Impossible” Part ......................................................... 48

2.7 A Word on Estimating Costs ......................................................... 492.8 Quality Counts .............................................................................. 492.9 Additional Research ...................................................................... 502.10 Summary ...................................................................................... 50

196.indb 9 7/1/08 3:38:47 PM


10

Contents

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

3.1 The Virtual Case File Story ............................................................ 533.2 Funding vs. Scope ......................................................................... 543.3 What is the Scope? ....................................................................... 563.4 Scope Documentation and Tracking .............................................. 613.5 Geography Implications ................................................................ 623.6 Scope Management and Exception Handling ................................ 633.7 Summary ...................................................................................... 65

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

4.1 Project Team Roles ........................................................................ 684.1.1 Project Manager ................................................................. 684.1.2 Project Management Office (PMO) .................................... 694.1.3 Steering Committee ............................................................ 704.1.4 Functional Team ................................................................. 704.1.5 Technical Team ................................................................... 734.1.6 Basis and Security team ...................................................... 744.1.7 Infrastructure Team ............................................................. 764.1.8 Change Management Team ................................................ 774.1.9 Other Teams ....................................................................... 79

4.2 SAP Ecosystem Considerations ...................................................... 804.3 Staffing Types ................................................................................ 81

4.3.1 In-house Staffing ................................................................ 824.3.2 Consultant-run Project ........................................................ 834.3.3 Hybrid (In-house Plus Consultants) ..................................... 844.3.4 Financial Partnerships ......................................................... 85

4.4 Outsourcing Considerations .......................................................... 864.4.1 India vs. the Rest of the World ........................................... 864.4.2 Other Considerations .......................................................... 86

4.5 Hosting Considerations ................................................................. 874.6 Relationships and Chemistry ......................................................... 884.7 Other Types of IT Organizations ................................................... 894.8 Summary ...................................................................................... 90

196.indb 10 7/1/08 3:38:47 PM


11

Contents

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

5.1 The ASAP Methodology ................................................................ 925.2 ASAP Toolset ................................................................................ 935.3 ASAP Roadmap Phases ................................................................. 97

5.3.1 Project Preparation ............................................................. 975.3.2 Business Blueprint .............................................................. 985.3.3 Realization ......................................................................... 1005.3.4 Final Preparation ................................................................ 1015.3.5 Go-live and Support .......................................................... 103

5.4 International Rollout Considerations ............................................. 1045.5 Following a Release Schedule ....................................................... 1065.6 Upgrade Considerations ................................................................ 1065.7 Mergers and Acquisitions Considerations ...................................... 1075.8 Additional Implementation Content .............................................. 1085.9 Overlaying the SDLC Over ASAP ................................................... 1085.10 SAP Best Practices for CRM ........................................................... 1115.11 CRM Business Packages ................................................................ 1135.12 The Adoption Curve ...................................................................... 1155.13 Additional Considerations ............................................................. 1165.14 Summary ...................................................................................... 117

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

6.1 The SAP Ecosystem ....................................................................... 1196.1.1 SAP Solutions ..................................................................... 1196.1.2 SAP Services ....................................................................... 1206.1.3 SAP Ecosystem/Partners ..................................................... 120

6.2 Technical Landscape .................................................................... 1236.3 Technical Landscape Revised — Again? ......................................... 1286.4 User Interface Options .................................................................. 129

6.4.1 SAP GUI ............................................................................. 1296.4.2 Web-based UIs ................................................................... 1326.4.3 Other UI Options ............................................................... 134

6.5 Internally vs. Externally Focused Portal .......................................... 1366.6 CRM Online vs. ERP Functionality ................................................. 137

6.6.1 Order Management Options ............................................... 1386.6.2 Customer Master ............................................................... 1416.6.3 Other Master Data ............................................................. 141

196.indb 11 7/1/08 3:38:47 PM


12

Contents

6.6.4 Variant Pricing and Configuration ....................................... 1426.7 CRM Online vs. CRM Mobile ........................................................ 1436.8 CRM On-Demand ......................................................................... 1436.9 Hybrid Architecture ...................................................................... 144

6.9.1 SAP + Non-SAP ................................................................. 1456.10 Other Considerations .................................................................... 145

6.10.1 BI Refresh ........................................................................... 1456.10.2 Backups .............................................................................. 1466.10.3 System Copies .................................................................... 146

6.11 Summary ...................................................................................... 147

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

7.1 A Summary of the New ICWC Functionality in CRM 2007 ............ 1497.2 ICWC — a Pilot Project ................................................................. 150

7.2.1 Initial Scope ...................................................................... 1517.2.2 Implementation Aspects ..................................................... 1527.2.3 Issues and Troubleshooting ................................................. 158

7.3 ICWC — the Next Steps ................................................................ 1597.3.1 Order Integration ............................................................... 1597.3.2 CTI Integration ................................................................... 1617.3.3 Third-party Web Services Integration .................................. 162

7.4 Lessons Learned ............................................................................ 1637.5 Summary ...................................................................................... 163

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

8.1 A Summary of the New Case Management Functionality in CRM 2007 .................................................................................... 165

8.2 High-level Scope for Case Management ........................................ 1678.3 Scope in Detail ............................................................................. 168

8.3.1 Case Classification .............................................................. 1688.3.2 Automatic Routing ............................................................. 1698.3.3 Case Notifications/Alerts .................................................... 1718.3.4 Automatic Case Creation .................................................... 1728.3.5 Automatic Escalation .......................................................... 173

8.4 One Type of Case Management and Two Access Methods ............. 1768.5 Lessons Learned ............................................................................ 177

196.indb 12 7/1/08 3:38:47 PM


13

Contents

8.6 Other Considerations .................................................................... 1778.7 Summary ...................................................................................... 178

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

9.1 A Summary of the New SFA Functionality in CRM 2007 ................ 1799.2 High-level Scope of the SFA Implementation ................................ 180

9.2.1 Business Processes First ...................................................... 1819.2.2 Tailor the Technical Solution to Real Business Needs ........... 1839.2.3 User Interface — Revisited ................................................. 185

9.3 Scope in Detail ............................................................................ 1869.3.1 Account Management ........................................................ 1869.3.2 Opportunity Management .................................................. 1899.3.3 Contact Management ......................................................... 1919.3.4 Reporting ........................................................................... 192

9.4 The Importance of Clean Master Data ........................................... 1929.4.1 External Data Sources Might Be an Option ......................... 1939.4.2 Territory Management Considerations ................................ 1959.4.3 Legacy Data Sources and Quality Control ............................ 196

9.5 Non-standard Functionality .......................................................... 1979.6 Speeding Up the Access — a Citrix Mini-Case Study ..................... 1999.7 Change Management and the WIIFM Concept ............................. 2019.8 System Ownership ........................................................................ 2039.9 Other Considerations .................................................................... 2049.10 Summary ...................................................................................... 204

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

10.1 Native Integration in an SAP Environment .................................... 20510.1.1 SAP Middleware ................................................................. 20510.1.2 Running Parallel ERP and CRM Projects .............................. 20810.1.3 CRM and ERP — Always a 1:1 Relationship? ....................... 20910.1.4 Other Out-of-the-box Integration Technologies .................. 210

10.2 Integration vs. Interfacing Considerations ..................................... 21110.3 Summary ...................................................................................... 213

196.indb 13 7/1/08 3:38:47 PM


14

Contents

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

11.1 Functional Upgrades ..................................................................... 21511.2 Technical Upgrades ....................................................................... 21611.3 Functional Reimplementations ...................................................... 217

11.3.1 Determining the Optimal Upgrade Type ............................. 21711.3.2 Business and IT Impact on the Upgrade .............................. 218

11.4 Minor vs. Major Upgrades ............................................................ 21911.4.1 Minor Upgrades ................................................................. 21911.4.2 Major Upgrades .................................................................. 22011.4.3 A Note on Upgrades from Gartner ...................................... 221

11.5 Upgrade Considerations for Your Entire SAP Landscape ................. 22211.6 Summary ...................................................................................... 222

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

12.1 Before We Start ............................................................................ 22512.2 Sales ............................................................................................. 227

12.2.1 Sales Introduction .............................................................. 22712.2.2 Sales Implementation Suggestions ..................................... 231

12.3 Service .......................................................................................... 23612.3.1 Service Introduction .......................................................... 23612.3.2 Service Implementation Suggestions ................................. 236

12.4 Marketing ..................................................................................... 23912.4.1 Marketing Implementation Suggestions ............................. 24012.4.2 Web Channel .................................................................... 24312.4.3 Web Channel Implementation Suggestions ........................ 24512.4.4 Partner Channel Management ........................................... 24712.4.5 Partner Channel Management Implementation

Suggestions ...................................................................... 24812.4.6 Field Applications ............................................................. 24912.4.7 Field Applications Implementation Suggestions ................. 25012.4.8 Industry Solutions ............................................................. 252

12.5 Summary ...................................................................................... 253

196.indb 14 7/1/08 3:38:47 PM


15

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 ........................................................................ 25713.3 Summary ...................................................................................... 261

Appendices ........................................................................................ 263

A Job Descriptions ..................................................................................... 265A.1 CRM Sales Functional Consultant .................................................. 265A.2 CRM Technical Consultant ............................................................ 266A.3 BASIS Consultant .......................................................................... 267A.4 CRM Field Apps Functional Sales Consultant ................................ 268

B References ............................................................................................. 269C The Author ............................................................................................. 271

Index ............................................................................................................. 273

196.indb 15 7/1/08 3:38:47 PM


53

Scoping for Success3

Why is controlling the scope such an important task for any project?

To answer this question, it’s useful to state that at some level everyone under-stands 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 doesn’t matter if these additions and changes are value added or not. What matters is the project started with a set of business require-ments that were significantly changed during the course of the project. The key word here is “significantly,” because there’s almost no Information Technology (IT) project that will not suffer some minor changes while in development. The level of changes is what’s important here!

The Virtual Case File3.1 Story

Because we all like to learn from history lessons, we’ll discuss the FBI’s Virtual Case File project — a software project disaster. While this project isn’t 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 big-gest 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

196.indb 53 7/1/08 3:38:53 PM


54

ScopingforSuccess3

estimated. SAIC and the FBI chose to develop a custom system that would fulfill all of the FBI’s business requirements.

The requirements grew significantly over the course of the project to over 800 pages. The FBI’s IT management changed several times during the next three years and SAIC’s 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 after-thought, 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 system’s 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 FBI’s VCF project, please refer to the excellent article, “Who Killed the Virtual Case File?” by Harry Goldstein.4

Funding3.2 vs. Scope

Before we discuss scope in detail, we should discuss the balancing act the manage-ment 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.

It’s important (but not critical at this stage) to drill down to a very granular level of detail in the project plan. It’s 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

196.indb 54 7/1/08 3:38:53 PM


55

Fundingvs.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 deter-mine the other. The duration of the project depends on how many activities can realistically be run in parallel.

The project’s 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 it’s not an elegant one.

The biggest costs associated with any CRM project

SAP CRM software (usually included in the SAP license; also covers the ERP, Portal, EE

BI, etc.)

Annual software maintenance fee (typically around 18% — but depends on your par-EE

ticular contract); the first year is waived

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)EE

196.indb 55 7/1/08 3:38:53 PM


56

ScopingforSuccess3

Testing (some companies have a dedicated independent QA team, while others may EE

do the testing with the IT and/or the business‘ resources — not recommended)

Cost of decommisioning the legacy systems (and/or maintaining them in parallel for EE

historical reasons)

Depending on your circumstances, the weight of the preceding cost categories might be in a different order.

It’s everyone’s 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.

What is the Scope?3.3

The scope associated with a project is the sum of the business requirements gath-ered 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 they’re 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:

196.indb 56 7/1/08 3:38:54 PM


57

WhatistheScope? 3.3

Correct Business Requirements Incorrect Business Requirements

1. Be able to capture the contact’s details (first name, last name, address, telephone number, mobile number, email address)

1. Capture the contact’s 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 order-ing website

Examples of Correct and Incorrect Business RequirementsTable 3.1

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 don’t 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.

Let’s discuss the three requirements listed in Table 3.1 in a bit more detail.

Requirement 1EE When we are talking about a contact‘s details, we are always thinking about the name, address, and so on. It’s 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!

Requirement 2EE 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

196.indb 57 7/1/08 3:38:54 PM


58

ScopingforSuccess3

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

A Possible Implementation for the Customer Feedback RequirementFigure 3.1

As you can see from Figure 3.1, this solution is technically feasible, but quite inelegant. Let’s 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

Customer Feedback Requirement as Standard Functionality within Case ManagementFigure 3.2

196.indb 58 7/1/08 3:38:56 PM


59

WhatistheScope? 3.3

It’s 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 refi ned 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 insuffi cient. If that’s the case with the particular business requirement at hand, feel free to develop whatever feature is important for the end users.

Requirement 3EE 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 child’s 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 per-formed 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 — defi nitely 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 requirement’s technical implementation is never a good idea.

Let’s see one example of such a business requirement: the account managementfunctionality in CRM provides very good access to the account data, as depicted in Figure 3.3.

Basic Account Management functionalityFigure 3.3

196.indb 59 7/1/08 3:38:57 PM


60

ScopingforSuccess3

However, some SAP customers have a business requirement to present the various relationships between their own customers in a hierarchical fashion. Let’s 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.

Enhanced Account Management FunctionalityFigure 3.4

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 defi nition 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 defi ned the scope as the sum of the business requirements, plus any additional tasks that have to be performed in order to sup-port 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 functional-ity, the project management activities, etc. As you can see, there’s a lot you’ll have to consider when you look at the project scope from a holistic point of view.

196.indb 60 7/1/08 3:38:57 PM


61

ScopeDocumentationandTracking 3.4

Scope Documentation and Tracking3.4

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

Sample Template for Gathering Business RequirementsFigure 3.5

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 refi ned into the requirements documents for your project (fi nalized during the blueprint phase).

At this stage it’s impossible not to mix apples and oranges — so when running those workshops it’s important to understand the software capabilities, so you can guide your Business partners on the embedded Best Business practices in SAP CRM. It’s also important to see if there is any business reengineering opportuni-ties – if you identify a bloated, ineffi cient business process, there’s no better time to reengineer it than now, before you start implementing the CRM software.

196.indb 61 7/1/08 3:38:58 PM


62

ScopingforSuccess3

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 avail-able 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 project’s 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 what’s being delivered.

Tip

The best method to ensure what’s delivered is indeed what was initially requested, is to employ a traceability matrix that relates the functionality being delivered against the original requirements.

Geography3.5 Implications

Up to this point, we haven’t 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. Let‘s 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 proj-ect, 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 you’ll 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.

196.indb 62 7/1/08 3:38:58 PM


63

ScopeManagementandExceptionHandling 3.6

While scope control is a very important area, there will always be justifiable addi-tional 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.

Scope Management and Exception Handling3.6

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.

It’s human nature to be imperfect (that‘s 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 it’s very hard to negotiate with them if that’s the stage-setting message. But at the end of the day, you’ll have to deliver your CRM project on time, and on budget.

Because we now know the scope drives the budget, and by extension, your time-line, it’s 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 can‘t 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 require-ments can be dropped out of scope. As long as you are still going to maneuver inside your margin you’ll be fine. And while it’s very important to control the scope during the project, not too many people will worry about the scope at the end of the project.

196.indb 63 7/1/08 3:38:58 PM


64

ScopingforSuccess3

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 proj-ect is apparently non-negotiable from the business’s perspective. If you aren’t 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 dura-tion. 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). There’s 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, there’s 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 don’t 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 origi-nal scope, but you’ll be safer if you strive for the lower end of that interval.

196.indb 64 7/1/08 3:38:58 PM


65

Summary 3.7

Summary3.7

Scope control is paramount!EE

Budget = function (scope); time depends on how many activities can be realisti-EE

cally run in parallel.

Understand your total cost structure.EE

Understand how to phrase a good business requirement; explain to your busi-EE

ness clients the way to properly state the requirement.

Nonstandard functionality is appealing, but it’s also expensive and problematic EE

to upgrade.

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

Use the escalation process to control the scope creep.EE

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

196.indb 65 7/1/08 3:38:58 PM


273

A

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

B

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

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

C

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

Index

196.indb 273 7/1/08 3:40:10 PM


274

Index

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

D

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

E

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

F

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

G

Gartner, 221Geography, 62

Global template, 95Go-live and support, 103

H

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

I

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

K

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

L

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

196.indb 274 7/1/08 3:40:10 PM


275

Index

M

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

N

Native integration, 205Nonstandard Functionality, 60, 197

O

Opportunity Management, 41, 71, 180, 189Optimal upgrade type, 217Order entry, 139Order integration, 159Order to Cash (OTC), 70, 231Organization structure, 174Outsourcing, 86

P

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

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

R

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

S

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

196.indb 275 7/1/08 3:40:10 PM


276

Index

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

T

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

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

U

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

V

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

W

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

Srini Katta

Discover SAP CRM

In today’s competitive market environment,

companies who lose sight of their customer’s

needs, lose those customers, and to be

successful in retaining and satisfying customers,

companies need to understand CRM, which is

where Discover SAP CRM comes in. This book

helps companies learn how to use SAP CRM

effectively to ensure that customers are heard

and that their needs are met.

.

406 pp., 2008, 39,95 Euro / US$ 39.95ISBN 978-1-59229-173-1

Discover SAP CRMwww.sap-press.com

Provides managers andconsultants with a complete guide

to what SAP CRM is

Teaches about the benefits of using CRMto build profitable customer relationships

Includes practical insights fromcustomers using SAP CRM successfully

196.indb 276 7/1/08 3:40:11 PM


Planning Your SAP CRM Implementation · George Fratian Planning Your SAP® CRM Implementation Bonn...

Documents

Transcript of Planning Your SAP CRM Implementation · George Fratian Planning Your SAP® CRM Implementation Bonn...