If, after your decision to start a CRM implementation project, you determine that you have insufficient resources to execute the project on your own, you may elect to supplement your staff with a few independent consultants or select a systems integration partner to help design and implement the solution. Regardless of the type of project (new implementation, upgrade, or global roll-out), the key to getting the most out of your CRM consultants and to spending your consulting dollars effectively is accurately matching the consultant’s skill set with the appropriate role on the project team.

Selecting the appropriate project team is critical to the effective use of your consulting dollars. Focusing on the costs without identifying the skill sets and experience associated with those costs can often lead to unexpected weaknesses in your team. This does not mean that you should reject “stretch assignments,” but that you should be aware that it is a stretch assignment and have a process to quickly rectify role mismatches.

If you align skill sets with the appropriate roles, as the time commitments for roles decrease, the presence of the consultant filling that role can also decrease. If it is in the best interests of the project to retain the consultant’s services, consider shifting non-dependent project tasks (such as knowledge transfer) earlier rather than filling a role for which the consultant is overqualified.

When selecting (or approving) consulting team members, consider the following areas during your evaluation:

• Do the consultants approach the solution design in business terms?
  
  
• What is the extent of their CRM knowledge?
  
  
• What role will they play on this project?

The first two questions help to assess the skill set (experience and knowledge base) of the consultant. The last question helps to determine whether that skill set has a place on the project team. Let’s look at each of these areas in detail and see why they are important to your project’s success.

Solution Design Approach

A primary reason for selecting mySAP CRM is for its close integration with other SAP components. The close coupling of mySAP CRM with the back-end R/3 ERP system requires that the CRM solution design consider associated business processes while focusing on the processes of the current project. An expensive approach to satisfying this requirement is to blueprint the entire end-to-end business process and then implement only that portion of the process germane to the specific project. Conceptually, the approach aims to produce a design that is consistent across the business enterprise. An implicit assumption in this approach, however, is that your business will not change during the lifetime of either the current project or subsequent projects covered by the same blueprint design.

A better approach is to focus on the business drivers that prompted the need for a new system and rely on the flexibility of SAP to be able to expand upon the initial solution as your business evolves. This approach requires that the consultant understand the business implications of a design decision and the constraints that a decision may impose on future functionality.

For example, consider the decision to designate customer numbers (numbers in the 40 million range are sold-to’s and those in the 50 million range are indirects). In R/3, customers are normally not entered into the system until there is a sales relationship established. In mySAP CRM, however, you enter a business partner in the system as a prospect long before an actual purchase order is received. At the time of the initial interaction, the final business relationship has not been established, making the designation of a customer number difficult.

If you decide to enter prospects in mySAP CRM only and then create a different customer number once the order is received, then all of the sales activity prior to getting the order is not connected to the order itself. It does not mean that you cannot deliver the same analytics with “significant” customer numbers, but the effort will probably take longer and have a higher cost of ownership over time.

During the blueprint phase, if the consultant considers the types of analytics that will be desired in the future as well as the types of relationships that may arise between the buyer and seller, then the design recommendation would be to use non-significant numbering.

Extent of CRM Knowledge

mySAP CRM is a rapidly evolving application environment compared to its beginnings some six years ago. Consultants tend to reside in a single application niche: E-commerce, sales, service, marketing, and analytics, with specialists within each niche. A CRM sales consultant may have interaction center experience or field sales experience but seldom both. Because the technical tools are different than in R/3 (Java, XML, Object ABAP, Visual Basic), it is less likely that an application consultant can implement customer-specific requirements without additional resources.

Many of the early mySAP CRM projects were pilots, proof-of-concept type projects servicing a relatively small user base. In this environment, how many projects and the specific functionality implemented are more important than how long someone has been working in CRM. Smaller projects also tend to require people to work outside of their comfort zone, increasing the breadth of the product knowledge.

To ascertain the depth of mySAP CRM product knowledge, consider the following subjects. See the summary of these issues in Table 1.

• Describe the project scope, team size, and the roles of the individual team members. The smaller the team relative to the project scope, the more each team member has to accomplish. From a product learning perspective, smaller projects tend to result in greater learning. The drawback to smaller projects is that they tend to avoid addressing significant gaps.
  
  
• Describe any user exits that were implemented for the project and your role in developing that user exit. Although it is possible to implement a mySAP CRM project without activating any user exits, the lack of enhancements also points to a few complex process issues. A consultant with little or no involvement in user-exit development may be unable to assist in trouble-shooting the inevitable problems that arise on any SAP project. This increases the likelihood that you must pay for idle time while someone else figures out the problem.
  
  
• How did the functionality implemented interact with the R/3 back end? Many consultants whose background is non-SAP CRM have acquired knowledge of the mySAP CRM product but have minimal knowledge of R/3. Unless the project is implementing a stand-alone CRM system (unconnected to an R/3 system back end), inadequate knowledge of the sending system can lead to unexpected consequences. 
  
  
• What sort of enhancements to R/3 create the greatest issues to your project? The data models for customers, products, and pricing are different in mySAP CRM compared to R/3. Pricing user exits and creative use of existing data fields are the two areas that may generate the most work on the project. I sometimes think that the longer someone has been an R/3 customer, the more difficult the mySAP CRM implementation. This is because earlier SAP releases had less delivered functionality requiring the greater use of user exits.

The information gathered with these questions can help decide whether the consultant’s skill set is appropriate for the project in question. It is also vital to determine what the consultant will be doing on the project.

What Role Will the Consultant Play?

The skill set and experience level needed from consultants is directly associated with the role that they will fill on the project team. The complexity of the project, the fit of the project to the software, and the willingness of the company to adjust business practices to system functionality also influence the experience level needed.

Often, system integrators staff a project with one experienced and several junior team members to effectively address project complexity while keeping costs in line with the customer’s expectations. In these circumstances, it is even more important to identify the roles the team members will fill because of the impact those resources have on producing a realistic implementation plan.

When a project implementation plan is first established, the detailed tasks are entered with an estimated effort and task dependencies are established. The specific resources are then placed into the plan to show that it will be within budget and the expected timeline. It is important to confirm that the people assigned to the tasks have the experience and skills consistent with the tasks to be performed. A mismatch in this area may not reveal itself during the actual project implementation, but the impact of that mismatch will be felt during subsequent phases and normal maintenance support.

A couple of examples illustrate this point. One of the key roles that a consultant plays on a project is that of the mentor performing knowledge transfer. The goal is to establish self-sufficiency within the organization and reduce the dependency on consultants because of product knowledge gaps. Effective knowledge transfer requires time and a mentor with teaching skills and sufficient experience to not only know what was configured but why it was configured in that manner.

Successful mentoring requires a more senior individual, but is often assigned to more junior project members. It also requires receptive trainees. Too often, knowledge transfer is relegated to the final go-live phase or post go-live support. When this happens, the trainees generally feel they are inadequately prepared to assume responsibility for ongoing application support.

A smooth go-live requires adequate testing. The development of the testing scenarios requires an understanding of the solution and a passion for detail that ensures that all of the possible business cases are identified. Inadequate testing often occurs because insufficient negative test cases were identified and not because the team was missing some of the positive test cases. In other words, it is essential to make sure the system does not do what it should not do as well as to make sure that it performs in the desired manner.

The testing process contains the following tasks: development of test cases, execution of test cases (both individual tasks and business scenarios), and analysis and correction of test errors. The execution of test cases does not require highly skilled individuals and should be staffed accordingly.

As long as one or two people have solid knowledge of the application (the employees that will be super users or support analysts after go- live), the individual testers can either be actual future users or temporary employees with data entry computer skills. Building a complete test scenario not only improves the quality of your go-live but also gives you the base for regression testing that will speed future upgrades and additional project phases.

Michael Debevec

Michael Debevec is president of Debevec Consulting, Inc., and is a senior consultant with more than 14 years of experience with SAP. He has worked with SAP CRM for the past nine years and assisted in implementations in the high tech, consumer products, and pharmaceuticals industries. Prior to working in SAP, Michael was an IS manager in charge of logistics systems.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.