Planning your SAP CRM implementation

 George Fratian Planning Your SAP CRM Implementation ® Bonn � Boston 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 7 Contents Acknowledgment ......................................................................................... Foreword ..................................................................................................... 1 Introduction ............................................................................... 21 1.1 1.2 1.3 1.4 1.5 1.6 2 17 19 Other Reference Material .............................................................. Why This Book? ............................................................................ Book Structure .............................................................................. SAP CRM Customer Proile ........................................................... The SAP Ecosystem ....................................................................... Summary ...................................................................................... 22 24 25 27 31 32 Project Initiation ....................................................................... 35 2.1 2.2 Long-term Roadmap ..................................................................... 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 9 Contents 3 Scoping for Success ................................................................... 53 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 53 54 56 61 62 63 65 SAP CRM Project Team ............................................................. 67 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 10 The Virtual Case File Story ............................................................ Funding vs. Scope ......................................................................... What is the Scope? ....................................................................... Scope Documentation and Tracking .............................................. Geography Implications ................................................................ Scope Management and Exception Handling ................................ Summary ...................................................................................... Project Team Roles ........................................................................ 4.1.1 Project Manager ................................................................. 4.1.2 Project Management Ofice (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 ...................................................... Stafing Types ................................................................................ 4.3.1 In-house Stafing ................................................................ 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 Contents 5 Project Lifecycle ........................................................................ 91 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 6 The ASAP Methodology ................................................................ ASAP Toolset ................................................................................ ASAP Roadmap Phases ................................................................. 5.3.1 Project Preparation ............................................................. 5.3.2 Business Blueprint .............................................................. 5.3.3 Realization ......................................................................... 5.3.4 Final Preparation ................................................................ 5.3.5 Go-live and Support .......................................................... International Rollout Considerations ............................................. Following a Release Schedule ....................................................... Upgrade Considerations ................................................................ Mergers and Acquisitions Considerations ...................................... Additional Implementation Content .............................................. Overlaying the SDLC Over ASAP ................................................... SAP Best Practices for CRM ........................................................... CRM Business Packages ................................................................ The Adoption Curve ...................................................................... Additional Considerations ............................................................. Summary ...................................................................................... 92 93 97 97 98 100 101 103 104 106 106 107 108 108 111 113 115 116 117 Architectural Design ................................................................. 119 6.1 6.2 6.3 6.4 6.5 6.6 The SAP Ecosystem ....................................................................... 6.1.1 SAP Solutions ..................................................................... 6.1.2 SAP Services ....................................................................... 6.1.3 SAP Ecosystem/Partners ..................................................... Technical Landscape .................................................................... Technical Landscape Revised — Again? ......................................... User Interface Options .................................................................. 6.4.1 SAP GUI ............................................................................. 6.4.2 Web-based UIs ................................................................... 6.4.3 Other UI Options ............................................................... Internally vs. Externally Focused Portal .......................................... CRM Online vs. ERP Functionality ................................................. 6.6.1 Order Management Options ............................................... 6.6.2 Customer Master ............................................................... 6.6.3 Other Master Data ............................................................. 119 119 120 120 123 128 129 129 132 134 136 137 138 141 141 11 Contents 6.6.4 Variant Pricing and Coniguration ....................................... CRM Online vs. CRM Mobile ........................................................ CRM On-Demand ......................................................................... Hybrid Architecture ...................................................................... 6.9.1 SAP + Non-SAP ................................................................. 6.10 Other Considerations .................................................................... 6.10.1 BI Refresh ........................................................................... 6.10.2 Backups .............................................................................. 6.10.3 System Copies .................................................................... 6.11 Summary ...................................................................................... 6.7 6.8 6.9 7 Case Study: CRM Interaction Center WebClient 7.1 7.2 7.3 7.4 7.5 8 ..................... 149 A Summary of the New ICWC Functionality in CRM 2007 ............ ICWC — a Pilot Project ................................................................. 7.2.1 Initial Scope ...................................................................... 7.2.2 Implementation Aspects ..................................................... 7.2.3 Issues and Troubleshooting ................................................. ICWC — the Next Steps ................................................................ 7.3.1 Order Integration ............................................................... 7.3.2 CTI Integration ................................................................... 7.3.3 Third-party Web Services Integration .................................. Lessons Learned ............................................................................ Summary ...................................................................................... 149 150 151 152 158 159 159 161 162 163 163 Case Study: CRM Case Management ....................................... 165 8.1 8.2 8.3 8.4 8.5 12 142 143 143 144 145 145 145 146 146 147 A Summary of the New Case Management Functionality in CRM 2007 .................................................................................... High-level Scope for Case Management ........................................ Scope in Detail ............................................................................. 8.3.1 Case Classiication .............................................................. 8.3.2 Automatic Routing ............................................................. 8.3.3 Case Notiications/Alerts .................................................... 8.3.4 Automatic Case Creation .................................................... 8.3.5 Automatic Escalation .......................................................... One Type of Case Management and Two Access Methods ............. Lessons Learned ............................................................................ 165 167 168 168 169 171 172 173 176 177 Contents 8.6 8.7 9 Other Considerations .................................................................... 177 Summary ...................................................................................... 178 Case Study: Sales Force Automation (SFA) ............................... 179 9.1 9.2 A Summary of the New SFA Functionality in CRM 2007 ................ High-level Scope of the SFA Implementation ................................ 9.2.1 Business Processes First ...................................................... 9.2.2 Tailor the Technical Solution to Real Business Needs ........... 9.2.3 User Interface — Revisited ................................................. 9.3 Scope in Detail ............................................................................ 9.3.1 Account Management ........................................................ 9.3.2 Opportunity Management .................................................. 9.3.3 Contact Management ......................................................... 9.3.4 Reporting ........................................................................... 9.4 The Importance of Clean Master Data ........................................... 9.4.1 External Data Sources Might Be an Option ......................... 9.4.2 Territory Management Considerations ................................ 9.4.3 Legacy Data Sources and Quality Control ............................ 9.5 Non-standard Functionality .......................................................... 9.6 Speeding Up the Access — a Citrix Mini-Case Study ..................... 9.7 Change Management and the WIIFM Concept ............................. 9.8 System Ownership ........................................................................ 9.9 Other Considerations .................................................................... 9.10 Summary ...................................................................................... 179 180 181 183 185 186 186 189 191 192 192 193 195 196 197 199 201 203 204 204 10 Integration with Other SAP and Non-SAP Systems ................. 205 10.1 Native Integration in an SAP Environment .................................... 10.1.1 SAP Middleware ................................................................. 10.1.2 Running Parallel ERP and CRM Projects .............................. 10.1.3 CRM and ERP — Always a 1:1 Relationship? ....................... 10.1.4 Other Out-of-the-box Integration Technologies .................. 10.2 Integration vs. Interfacing Considerations ..................................... 10.3 Summary ...................................................................................... 205 205 208 209 210 211 213 13 Contents 11 Upgrade Considerations ............................................................ 215 11.1 Functional Upgrades ..................................................................... 11.2 Technical Upgrades ....................................................................... 11.3 Functional Reimplementations ...................................................... 11.3.1 Determining the Optimal Upgrade Type ............................. 11.3.2 Business and IT Impact on the Upgrade .............................. 11.4 Minor vs. Major Upgrades ............................................................ 11.4.1 Minor Upgrades ................................................................. 11.4.2 Major Upgrades .................................................................. 11.4.3 A Note on Upgrades from Gartner ...................................... 11.5 Upgrade Considerations for Your Entire SAP Landscape ................. 11.6 Summary ...................................................................................... 215 216 217 217 218 219 219 220 221 222 222 12 CRM Functionality and Implementation Guidelines ................ 225 12.1 Before We Start ............................................................................ 12.2 Sales ............................................................................................. 12.2.1 Sales Introduction .............................................................. 12.2.2 Sales Implementation Suggestions ..................................... 12.3 Service .......................................................................................... 12.3.1 Service Introduction .......................................................... 12.3.2 Service Implementation Suggestions ................................. 12.4 Marketing ..................................................................................... 12.4.1 Marketing Implementation Suggestions ............................. 12.4.2 Web Channel .................................................................... 12.4.3 Web Channel Implementation Suggestions ........................ 12.4.4 Partner Channel Management ........................................... 12.4.5 Partner Channel Management Implementation Suggestions ...................................................................... 12.4.6 Field Applications ............................................................. 12.4.7 Field Applications Implementation Suggestions ................. 12.4.8 Industry Solutions ............................................................. 12.5 Summary ...................................................................................... 14 225 227 227 231 236 236 236 239 240 243 245 247 248 249 250 252 253 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 ..................................................................................... A.1 CRM Sales Functional Consultant .................................................. A.2 CRM Technical Consultant ............................................................ A.3 BASIS Consultant .......................................................................... A.4 CRM Field Apps Functional Sales Consultant ................................ B References ............................................................................................. C The Author ............................................................................................. 265 265 266 267 268 269 271 Index ............................................................................................................. 273 15 3 Scoping for Success 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 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 signiicantly changed due to additions and modiications. 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 requirements that were signiicantly changed during the course of the project. The key word here is “signiicantly,” 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! 3.1 The Virtual Case File 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 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 eficient manner, so the FBI had identiied 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 3 ScopingforSuccess estimated. SAIC and the FBI chose to develop a custom system that would fulill all of the FBI’s business requirements. The requirements grew signiicantly 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 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 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 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. 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 reine 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 Fundingvs.Scope 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 conigured 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 irst 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 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 speciic 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 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 irst 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 3.2 3 ScopingforSuccess 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. 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. 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 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: 56 WhatistheScope? Correct Business Requirements Incorrect Business Requirements 1. Be able to capture the contact’s details (irst 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 ordering website 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 deining business requirements without implying a technical solution is a de facto best business practice, you also have a more selish 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. EE Requirement 1 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 speciied 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 beneit. This makes no sense! EE Requirement 2 The feedback received from a customer can be classiied in various categories: suggestions, complaints, documentation requests, etc. While a supericial look documenting and classifying the feedback received from the customer in a text 57 3.3 3 ScopingforSuccess 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). 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. 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 Figure 3.2 58 Customer Feedback Requirement as Standard Functionality within Case Management WhatistheScope? 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 reined 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 insuficient. If that’s 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 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 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 — deinitely 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 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 3.3 3 ScopingforSuccess 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. 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 deinition 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 deined 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, there’s a lot you’ll have to consider when you look at the project scope from a holistic point of view. 60 ScopeDocumentationandTracking 3.4 Scope Documentation and Tracking Later in the book we’ll discuss the lifecycle of an SAP project, but one of the irst things that you have to do after deciding on a project is to determine the exact scope (even if it‘s your irst 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). 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 reined into the requirements documents for your project (inalized 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 opportunities – if you identify a bloated, ineficient business process, there’s no better time to reengineer it than now, before you start implementing the CRM software. 61 3.4 3 ScopingforSuccess 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 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. 3.5 Geography 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 conigured 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 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 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. 62 ScopeManagementandExceptionHandling While scope control is a very important area, there will always be justiiable 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. 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 timeline, 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 requirements can be dropped out of scope. As long as you are still going to maneuver inside your margin you’ll be ine. 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. 63 3.6 3 ScopingforSuccess Tip Please make sure that you have a well-deined 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 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 conlict. 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 modiied 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 justiied. 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 deinitive 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 original scope, but you’ll be safer if you strive for the lower end of that interval. 64 Summary 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 it’s 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 we’ll discuss the project team structure, with examples from a medium-size CRM project. 65 3.7 Index A Account identiication, 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 classiication, 168 Case management, 151, 165 Case Management, 43, 58 Case notiications, 171 CDMA, 184 Change management, 70, 77 Change Management , 201 Chemistry, 88 Citrix, 185, 199 Coniguration, 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 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 coniguration, 100 Final preparation, 101 Formal signoff, 63 Functional reimplementations, 217 Functional team, 70 Functional upgrades, 215 Funding, 54 Future projects, 255 G Gartner, 221 Geography, 62 274 Global template, 95 Go-live and support, 103 H high-speed Internet , 200 Hosting, 87 Hybrid architecture, 144 Hybrid stafing, 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 “What’s 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 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 Modiication, 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 Ofice (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 R 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 O S 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 N P Partner product range, 29 Party web services integration, 162 PCUI, 106 Phased approach, 42 Pilot project, 40, 51, 150 Pilot scope, 42 275 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 Stafing 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 coniguration, 231 Variant pricing, 142 Verispan SMG, 193 Virtual case ile, 53 W T Tactical project, 42 TCO (Total Cost of Ownership), 213, 255 Team selling, 77, 182 Technical landscape, 76, 123, 128 276 Warranty period, 104 Web Channel, 243 WebClient UI, 106, 132 Wireless card, 200 Workshops, 41