CRM Implementations and Upgrades

© 2008 BearingPoint, Inc. All rights reserved.
SAP® CRM
Implementations and
Upgrades: A Step-by-
Step Guide
Peter Ware
BearingPoint

2
What We’ll Cover …
• Introduction
• Project initiation
• Project planning
• SAP solution manager and services
• Functional execution
• Technical execution
• Change management
• Training
• Wrap-up

3
Main Focus of This Session
• Project management techniques, tools and lessons-
learned from SAP CRM Projects
• All topics that are an essential part of CRM projects
 Cover what works and what doesn’t work
• Applies to IT and project managers and team members
with an imminent SAP CRM implementation
• Intended to inform, offer guidance, and help you
negotiate the learning curve a little less painfully

Before We Start — Anatomy of a CRM Project
• Based on a recently completed SAP CRM 5.0 Global
Service Management implementation project for a high-
tech manufacturer
 Addressed Service Order Management, Contact Center,
Technical Support, Project Cases, Scheduled Maintenance,
Product Service Letters, Scheduling and Dispatch,
Confirmations, Contracts Management, Billing and Service
Finance, Business Intelligence and Field Service Mobility via
Blackberry devices
 Implemented in US, EU and Asia,14 countries, 2,200 users, in
15 months
• Also other valid lessons learned from 30 years project
management experience
 History tends to repeat itself

5
• Introduction
• Training
• Wrap-up

Project Initiation
• Defining the problem to be solved
• The importance of involving stakeholders early
• Defining the business requirements
• Determining the Return on Investment (ROI)

Defining the Problem to Be Solved
• Strategic considerations
 Ideally a project should evolve from strategic considerations
 The corporation creates a vision for the future with goals for
the next 5-10 years
 The division determines how it will support, and what it
should do to realize the vision and goals
 This then would include some form of business
transformation with objectives defined to realize the goals
• Tactical considerations
 A business transformation will compete for investment in
the corporation
 If it is not a foundation of the overall strategic plan it may be
at risk downstream from competition for funding
 A solid ROI and payback to justify the investment is necessary

Stakeholder Management
• Stakeholders set the vision, direction, and requirements
for the project
• Get stakeholder influence inputs early in the life-cycle —
later in the project cycle is more costly to change
• Stakeholders: executives, management, users, internal
and external customers

Building Blocks to the New Business Model

Defining the Business Requirements
• When the need for the project is identified, start defining
the requirements and process for the new
business model
• Options
1. Define the current and future states of the business model
2. Minimize the current model and focus on the future
state model
3. Don’t do either; use the SAP standard processes and
capabilities as the guideline for the future state model of
the business

Option 1: Documenting the Current State
• Pros
 Identifies business as usual that must be supported in addition
to the new changes that must occur
 A framework to analyze current state process issues and
translate them into the potential ROI
 Defining today’s requirements eases the leap to tomorrow
• Cons
 An investment that is often judged as not required
 Adds time and cost to the project timeline

Option 2: Documenting the Future State
• Pros
 Essential to define the requirements to support the new
business model — new strategic capabilities
 Confirms ROI by identifying processes that capture benefit
 Identifies business areas that require more definition
 Participation provides the leverage for adoption (ownership)
• Cons
 The future state can develop beyond the basic requirements to
satisfying wish lists or non-essential (to the business
case) functionality
 Could define a model that is outside standard SAP functionality
(e.g., has a high enhancement component, thus increasing risk
and cost)

Option 3: Using SAP Standard Processes As the Future
State Model
• Pros
 Out-of-the box capability, as is, the software would require no
enhancements
 Definitely the least cost and time to implement
• Cons
 May offer significant change from existing processes, making it
a hard change to adopt
 May not deliver the process improvements you are looking for
in the benefits case
 The missing business as usual requirements are detected and
require definition in design, causing delay
 The devil is always in the details; discovery sometimes hurts

Criteria for Requirements Definition
• Involve and or represent all stakeholders in the process
• Give each requirement a unique tracking number
• Sections
 Function and sub-function: A statement summarizing the
specific requirement
 Description: A more detailed explanation of the requirement
 Importance: A rating of assessed need, expressed as
1=Business mandatory, 2=Highly desirable, 3=Nice to have,
4=Not required
 Vendor rating: A rating or an assessment of requirements
“fit,” expressed as S=Standard functionality, P=Partial
functionality, A=Add-on (third-party), C=Custom functionality,
O=Other
 Comments: A free-form multi-purpose field, may be used to
further qualify or define requirement

Later Purposes for the Requirements Listings
• Provide traceability to the SAP functions
 Tie the requirements to the SAP functions in the modules
satisfying the requirement
 Planning: Identifies standard functions versus gaps
 Feedback to stakeholders: “We listened”
 Design: Provides specific information on functionality
• Indicate which requirements or SAP functions are tied to
planned ROI and benefits
• Repository for requirements and functionality for future
releases — never can do everything at once

Relationship of Requirements and Process

Determine the ROI
• Interview the leadership on their view of opportunity
• Piggy-back off the definition of current state process
• Conduct a workshop with a cross-section of
the organization
 Middle managers, supervisors, workers and finance
• Supply a pre-prepared hit list of typical issues
• Ask the question “What problems exist today across the
organization?”
• Identify every match, calculate an order of
magnitude estimate
• Rank the top 20 based on results

Determine the ROI (cont.)
• Involve finance in the process (validated numbers)
• For each item, conduct a detailed costing using defect
pricing techniques
 Estimated expense, time, frequency
• Also document the measures of the item
• Select the top 10 opportunities based on the savings
realized if the problem is addressed
• Calculate the return over five years
• Estimate the proposed project costs and prepare an ROI
• Go get funding

19
• Introduction
• Training
• Wrap-up

20
Project Planning
• High-level project life-cycle
• The planning process
• Setting the scope
• Technical requirements
• Project organization and staffing
• Project roadmap
• Budgeting

High-Level Project Life-Cycle — Planning
• Planning and strategy
 Project planning and kick-off
 Vision and principles
 Process scenario definition
• Business process workshops
 Business process validation
 Requirements validation
• Solution analysis
 Assess requirements against
SAP CRM
 Conduct solution analysis
 Identify SAP functions to support
business scenarios and functions

Scope  Design
• Scope definition
 Develop work packages
 Design documents
 Key design decision analysis
 Development specs
 Configuration templates
• Solution design
 Develop design documents
 Development specifications
 Configuration specifications
 Functional specifications

Build  Deploy
• System build
 Develop configuration
 Develop configuration
documentation
 RICEF development
• Business Process Procedures
(BPPs)
 Develop BPPs
• Testing
 Integration testing
 User acceptance testing
• Roll-out
 System cutover
 Go-live and support

Setting Scope
• Total scope is a function of the overall business
transformation being affected
• The bigger it is, the larger the risk and change
components — all the more difficult to manage
• Enterprise can absorb only a finite amount of change at
one time
 There is a business to run and the resources are always shared
• Preferred choice should always be a series of smaller
releases or successes
 However, it is constrained by a number of factors

Setting Scope (cont.)
• Infrastructure
 A global implementation converting a number of standalone
systems to a single system allows the luxury of bringing up a
region at a time — much reduced risk
• If the system being replaced or upgraded is already
global, big-bang is the only way — potentially high risk
• The larger the business transformation (e.g., operations,
sales and marketing, and customer services) the more
difficult it is to control the integration management of
systems and processes across the enterprise
• Business dependencies create added risk

Setting Scope (cont.)
• Amount of custom work beyond standard functionality
(Reports, Interfaces, Conversions, Enhancements and
Forms (RICEF)), the higher the risk
• Technical requirements figure into scope
 Bleeding edge is high risk
 Un-proven software releases or latest technology are risky
 Technical skills are scarcer on the latest release
• Cost is directly related to the work and ultimately
affected by the impact of risk
• Always consider risk when setting scope

Technical Requirements
• Scope drives technical architecture, sizing, software,
and hardware requirements
• Within the scope, the business processes (e.g., types of
transactions, volumes, and end users) are used in the
sizing process
• The end result is the software combination required to
support the solution set
• Hardware requirements in terms of CPU and memory are
also derived from sizing

Project Organization
Program Management Office
Steering CommitteeAdvisory Committee
Organizational
Change
Management
Workforce
Transition
Field Exec/
Comms
Business
Intelligence
KPI /
Metrics
SAP Business
Warehouse
Reporting /
Analytics
TracksKeyActivities
Business
Transformation
BPP
Process &
Procedures
CRP3 / CRP4
/ IT / UAT
Contact
Center
Service
Delivery
SAP
Functional
Design &
Configuration
CRP3 / CR4
/ IT / UAT
Configurations
Executive Sponsor
Technical
Infrastructure
Development
Portal
Basis
Middleware
Training
Commercial
Master Data
Customer
Readiness
SAP Solution
Architect
Business
Architect
Performance Test
Lead & Team
Testing Lead
& Team
Data Migration
Lead & Team
Program Management Office
Steering CommitteeAdvisory Committee
Organizational
Change
Management
Workforce
Transition
Field Exec/
Comms
Business
Intelligence
KPI /
Metrics
SAP Business
Warehouse
Reporting /
Analytics
TracksKeyActivities
Business
Transformation
BPP
Process &
Procedures
CRP3 / CRP4
/ IT / UAT
Contact
Center
Service
Delivery
SAP
Functional
Design &
Configuration
CRP3 / CR4
/ IT / UAT
Configurations
Executive Sponsor
Technical
Infrastructure
Development
Portal
Basis
Middleware
Training
Commercial
Master Data
Customer
Readiness
SAP Solution
Architect
Business
Architect
Performance Test
Lead & Team
Testing Lead
& Team
Data Migration
Lead & Team

Staffing the Project
• Project staffing is in generic teams or tracks
 Project Management Office, Business, Change Management,
Functional, Technical and optionally Business Warehouse
• There are also cross-track shared resources in purpose-
driven teams
 Performance Test, Data Migration and Cutover and Testing
• There may be special resources (e.g., SAP or
business architects)
• Types of resources are based on the skills required
• Timing is based on the project plan
• Cost is based on activity time derived in the plan
through the life-cycle phases

CRM Project Roadmap
• A roadmap is a means of delivering a methodology to
the individuals who might benefit from using it
• The project roadmap is the framework that ties the
proposed timeline to the methodology and includes:
 Deliverables and ownership
 Stakeholder participation
 Milestones and phase reviews
• Used to:
 Manage the project
 Explain project status
 Set expectations on what the next steps are to stakeholders and
the delivery team

Project Roadmap — Timeline
• Timeline
• Dates
• Major milestones
• Phase exits

Project Roadmap — Tracks and Activity by Phase
Tracks / Teams
Each activity is timed
and has a % planned
completion to guide
resource planning

CRP3 is:
• A validation of the configured
solution at 80% complete, using end-
to-end business scenarios
• Some breaks in the system process
will occur
• Some RICEF components will be
shown as a part of the solution
• Core Team demonstration mode
• Viewed by Change Agent Team
Put It All Together — With a Little Explanation

Each Phase Follows the Roadmap
CRP4 is:
• A validation of the final configured
solution using end-to-end
business scenarios
• Less breaks in the system process
• More RICEF components will be
shown as part of the solution
• Core Team hands-on
• Viewed by Change Agent Team

Budgeting
• Resource: employee or contractor
• Hourly rate
• Plan and actual hours
• Plan and actual cost
• Plan and actual expenses
• Summarize by department
• Accumulate long-term assignment cost
• Convert plan to actual each period

37
• Introduction
• Training
• Wrap-up

The Role of SAP Solution Manager
• SAP Business Suite implementation and upgrades
 Accelerates implementation by providing content
 Speeds up blueprint, configuration, and final
preparation phases
 Supports centralized control of cross-component
implementations
• Change control management
 Controls all software and configuration changes with approvals
 Ensures traceability of all changes
• Testing
 Single point of access to the complete system landscape
 Centralized storage of testing material and test results to
support integration tests

The Role of SAP Solution Manager (cont.)
• IT and application support
 Helps manage incidents — centralized handling of
support messages
• Root cause analysis
 Diagnostics functions allow identification, analysis, and
resolution of problems, even in heterogeneous environments
 Can isolate performance bottlenecks, incidents, and changes
• Solution monitoring
 Real-time monitoring of systems, business processes,
and interfaces
 Automatic notifications

The Role of SAP Solution Manager (cont.)
• Service-level management and reporting
 Automated reporting
• Service processing
 Makes appropriate service recommendations
 Includes SAP Safeguarding, SAP Solution Management
Optimization, and SAP Empowering
• Administration
 Tasks are executed locally but can be accessed and triggered
from a central administration console
 Unified access to all SAP technology

Linkage from Business to Transaction
Business
Scenario
Business
Process
Process
Step
A business scenario is a set of
processes that define a business
task in a comprehensive and self-
contained manner on a macro level
A business process is a set of
logically related activities performed
to achieve a defined business
outcome (cf. Davenport & Short, 1990)
A process step is an elementary
activity performed to accomplish a
process
Contact to Log
Contact – Interaction Center
Identify Account
Transaction(s) CRM_IC WebIC

SAP Technical Feasibility Check
• First step in managing technical risks for your SAP
solution, in the framework of a SAP MaxAttention™ or
SAP Safeguarding engagement
• Follows the risk management process of identifying,
quantifying, assigning, mitigating, and then
monitoring risks
• Delivered by an on-site team with remote access to
additional SAP consultants
• Overall process is driven by your SAP Solution Manager

SAP Technical Feasibility Check (cont.)
• It takes time to bring the SAP team up to speed, focus on
management time versus delivery time
• Our client signed up for it, it was a little difficult at first,
but the SAP folks really dug in and validated
the approach
• We received a completely clean sheet
• The validation is absolutely worth it and recommended,
regardless of who the primary Systems Integrator (SI) is

SAP GoingLive Onsite Service
• Mitigate potential risks of critical go-lives
• React quickly to issues, due to fast access to SAP in-
depth knowledge
• Increase technical stability, performance, throughput,
and maintainability of to-be solution
• Increase the competence of your support organization
through knowledge transfer from the SAP consultants
who are onsite, as well as, fast access to
SAP knowledge
• Support the first run of critical processes at, and after,
go-live, such as a period-end closing

SAP GoingLive Onsite Service (cont.)
• Document core business processes of the to-be solution
• Set up key monitoring functions of the SAP
Solution Manager
 For example: There was a problem with a J2EE engine,
continually running garbage collection. As a result RPA
scheduling notifications were not reaching the intended
recipients and messages were queuing up within CRM. At the
time there were approx 63,000 entries in the MapBox queue and
slow performance for IPC (seven days since go-live)
 This is a key service process (dispatch notification)

46
• Introduction
• Training
• Wrap-up

Functional Execution
• Deliverables
• Planning and delivering configuration
• User acceptance testing (UAT)
• UAT measures

Functional Deliverables
• Define SAP implementation strategy
• Define technical architecture and standards for
the project
• Develop business process scope document
• Conduct business design workshops
• Design system solution
• Identify and define development requirements (RICEF)
• Define user roles and authorization requirements
• Establish development environment

Functional Deliverables (cont.)
• Prepare and conduct conference room pilot (CRP)
reviews CRP1, CRP2, CRP3, CRP4
• Build the SAP pilot release
• Gather detailed business rules and business values
specifics for configuration
• Conduct baseline configuration, testing and shadowing
with client Business Process Analysts (BPAs)
• Design rework as necessary to accommodate issue
resolution and process exceptions
• Complete final configuration, testing and shadowing
with client BPAs
• Author detailed functional specifications

• Author detailed configuration documents
• Resolve issues related to design and propose solutions
• Integration testing — preparation, execution, and
issue resolution
• Support business team in the creation of business
process procedures (BPPs)
• Application role and user authorization definitions
• User acceptance testing — preparation, execution, and
issue resolution
• Trial and final cutovers — preparation, execution, and
issue resolution

• Go-live — readiness review
• Go-live — preparation and execution
• Post go-live — support and issue resolution
• Support SAP BW functional team in activities related to
design of InfoProviders and reports

Planning and Delivering Configuration
• “You know when you are done when you finish”
• Viewed as an art vs. a science
 It can’t be planned … not!
 However, it is a struggle to plan for a number of reasons
• SAP CRM is tightly integrated
 A configuration change that satisfies one situation can
completely break an already tested and agreed upon step
• The design has to be implemented and validated in a
number of cycles, each one progressively adding
functionality
• Most times you don’t know what can be done or what
will be a gap until you explore the capabilities of
the system

Planning and Delivering Configuration (cont.)
• Avoid the tendency to go straight to defining a gap if the
solution is not immediately obvious
• Configuration is implemented in a series of steps that
culminate in a conference room pilot
• The solution, at it’s stage of development, is reviewed in
the conference room pilot (CRP1 – 4)
• The users validate the solution and provide feedback
and new requirements
• The later in the cycle the requirements are received, the
more painful it is to include them without a
schedule impact

User Acceptance Testing
• Conducted in 2x2 week workshop sessions, US and Asia
• About 40 people in each
• Representatives from every region/business group with
a target of two attendees per role
• Prepared test scenarios made up of combined smaller
test scripts around core business processes
• Added variations on a theme for exceptions
• Tracked test performance in pass/fail mode using HP
Test Director
• Re-tested all failed scenarios and scripts following
the workshops

UAT Measures
• Scenarios complete
• Scripts executed
• Scripts passed
Executed scripts
0%
20%
40%
60%
80%
100%
120%
11/13/200711/14/200711/15/200711/16/200711/17/200711/18/200711/19/200711/20/2007
China
Taiw an
Singapore
Japan
Korea
US
Goal
Passed Scipts
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
11/13/2007
11/14/2007
11/15/2007
11/16/2007
11/17/2007
11/18/2007
11/19/2007
11/20/2007
China
Taiwan
Singapore
Japan
Korea
US
Goal
Scenarios complete
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
11/13/2007
11/14/2007
11/15/2007
11/16/2007
11/17/2007
11/18/2007
11/19/2007
11/20/2007
China
Taiwan
Singapore
Japan
Korea
US UAT
Goal

56
• Introduction
• Training
• Wrap-up

Technical Execution
• Deliverables
• RICEF
• Rework
• CRM middleware
• Data migration and cutover
• Importing and migrating custom code
• Performance testing
• IT department touch-points

Technical Deliverables
• Environment setup — QA, PERF, PROD
• Environment setup support to client for training
• CRP 3 — support preparation and execution
• Author detailed technical specifications
• CRP 4 — support preparation and execution
• Resolve issues related to system setup and environment
• RICEF — development and unit testing
• Author technical documentation for RICEF items
• Manage RICEF workload distribution between client,
vendor, and third-party
• Track RICEF allocation and delivery status in
shared system

Technical Deliverables (cont.)
• Update the program plan with RICEF status
• Integration testing — support preparation, execution,
and issue resolution
• Application role and user authorization —
implementation of roles
• User acceptance testing — support preparation,
execution and issue resolution
• Cutovers
 Trial — in CRP 1 – 3
 Final — support of preparation, execution and issue resolution
• Go-live — readiness review
• Go-live — preparation and execution
• Post go-live — support and issue resolution

RICEF
• Always a critical and difficult area to manage
• Clear definition of scope is required up front, followed by
formal change management to avoid scope creep
• Delivery is typically a mix of onshore and offshore
• The combination of managing onshore and offshore
delivery is complex and potentially problematic
• Fortunately there are mitigation steps that can be taken

RICEF — Reports
• Historical, operational performance
 Export data to SAP BW daily
 Requires development of data extractors
 Requires development of data cubes
 Specialized design area
 Expensive resource, not too many around in CRM
• Real-time, tactical, operational performance
 Address through online reporting
 Keep it simple and avoid giving them ability to bring the system
to its knees

RICEF — Interfaces and CRM Middleware
• Most companies grow a heterogeneous environment that
evolves over time
 Then along comes SAP to offer a standard platform
• Middleware provides standard integration between back-
office and front-office SAP systems
• Very few CRM implementations are standard
• The gaps are usually picked up by modifications to the
standard middleware and custom interfaces
• A typical service SAP CRM project has many more
interfaces in addition to the middleware supplied

RICEF — Conversions
• Required to transfer the data from the legacy or source
systems to the new SAP CRM system
 For an upgrade it is SAP to SAP
 SAP R/3 to SAP CRM  middleware
 SAP CRM  SAP CRM  middleware
 Standalone CRM or linked to SAP R/3
 Legacy to SAP CRM  combo of middleware and custom
 Key service requirement is to build the Ibase
 As-built Equipment has configurable components
 Component-level data comes from Manufacturing or build
systems outside service
 Multi-step process: extract, clean up, build, load
 Middleware is useful but rarely supplies all the answers

RICEF — Enhancements
• Always try to configure to meet the requirements
 If you can’t, it is a gap that is plugged by an enhancement
• Enhancements are always a potential risk area due to
complexity
• Complexity ranges from:
 Simple: Adding and maintaining a data element on Web IC
 Complex: Writing a module to manage entitlement under
varying conditions in the Contracts module
• Functional specifications
 Written by functional team and distributed to technical team
who produce technical specifications, develop, and test
• Risk occurs in interaction between offshore and onshore
resources in the development and acceptance
testing process

RICEF — Forms
• Typically easy and saved until the end
 Usually a conversion of one type of form to a CRM form
 Layout, etc., is know
• Forms require special attention
 In one SAP R/3 implementation, it was assumed that the new
CRM forms would be a copy of the old
 However, users were not using the SAP R/3 forms
 They were using creative ways to extract and modify
invoices, quotes, credit and debit memos
• Forms deserve their own CRP and UAT sessions

RICEF — Work Distribution
• High-level decision criteria
 Cost
 Available resources
 Skills
 Complexity
 Criticality
 Physical location
 Knowledge

RICEF — Work Assignment Factors
• Reports
 Driven by the BI business with the business
 Much trial and error interaction
 BI focus  onshore design  onshore or offshore build
• Interfaces
 Key knowledge: Legacy and SAP CRM  onshore design 
offshore build
• Conversions
 Key knowledge: Legacy and SAP CRM  onshore design 
offshore build
 Complexity very high  onshore build

RICEF — Work Assignment Factors (cont.)
• Enhancements
 Complexity very high  onshore design  onshore build
 Complexity medium  onshore design  offshore build
 Complexity low  onshore design  offshore build
 Offshore locations may have skills differences. This must weigh
in where there are multiple choices
 CRM knowledge
• Forms
 Seldom complex, always the last items to be fixed
 Onshore design  offshore build  testing requires data
generated by end to end process execution

Offshore Challenges
• Very attractive based on cost — an essential part of
delivery now
• RICEF involves knowledge transfer from business to
functional to technical resources across continents
• Communication must be clear and frequent, distance
adds language and time delays to the mix
• Track progress through a shared Web-based tool —
workflow pushes the deliverable to the next person
• To meet technical requirements without error depends
on more than the developer understanding of the code,
understanding the impact of changes is important
• Rework is a fact of life and a killer of schedule

Rework Is a Certainty — Minimize It!
• Offshore rework cycle
 Offshore sends to onshore
 Four hours onshore response — busy
 Two hours test time
 16 hours time difference
 One hour communication
 Four hours offshore — busy
 Two hours rework
 Offshore sends to onshore
 Total cycle time 29+ hours
• Complex developments
 Take up to 30 cycles
• How do you minimize it?

Minimizing Rework
• Visit vendor’s off-shore facilities
 Assess: skills, availability, references, management, quality and
infrastructure
• Bring sufficient key technical people onshore
during design
 Ground them in the design docs — team lead levels
• Start technical specifications onshore and
monitor quality
• Have the key technical people return offshore and recruit
the team

Minimizing Rework (cont.)
• Review the resumes and experience
• Send low, medium, and some high complexity offshore
as appropriate based on capability
• Retain very high complexity for onshore
• Bring the key technical resources onshore towards the
end of Realization phase for acceptance testing and the
inevitable rework

CRM Middleware Capabilities
Products SAP R/3 
SAP CRM
Replicate materials from SAP R/3 to SAP CRM
SAP R/3 is the system of record for configured
products
Installed Base SAP
R/3 SAP CRM
Equipment record created in SAP R/3 needs to
trigger the creation of installed base
individual object in SAP CRM
Business Partners
SAP R/3  SAP
CRM
Download of customers in SAP R/3 to SAP
CRM as organizations
Org Structure SAP
R/3  SAP CRM
Download of organizational structure
Sales Order
Replication SAP R/3
 SAP CRM
Standard sales order replication

CRM Middleware Capabilities (cont.)
Employees SAP R/3
 SAP CRM
Standard employee replication
Groupware Integration to Microsoft Outlook and IBM
Lotus Notes
VC SPA R/3 SAP
CRM
Variant configuration
Pricing Config SAP
R/3SAP CRM
Pricing rules

Data Migration and Cutover
• Involves preparing and sequentially building the data
that is required for the new system
• When the plan has been put together, we recommend at
least three trial cutovers are planned
 Test execution and develop the required level of detail and
quality assurance
• The longest most difficult part of the data migration for
service is always the building the Ibase
• Data migration requires resources from the business
who know the data — they usually have other jobs to do
• This is a critical activity and always a potential risk area

Sample Scope of Data Objects for Cutover
Data Object
Current
Source
System
Target
System
Migration Method
Sale Organization Structure R/3 CRM
Initial download via middleware. Manually
change the description of the sale org.
Customer R/3 CRM
Initial download via Middleware. Any additional
information in Clarify will need to be evaluated
and populated in the CRM customer master.
Contacts Legacy CRM Initial download via developed interface.
Employee Legacy CRM
Initial download via developed
Interface.
Employee (Field Engineers,
Sales Partners)
R/3 CRM
Initial download via enhanced
Middleware interface.
Business Partner
Relationships
R/3, Legacy CRM
Business Partner relationships will
need to be created in CRM based on
information in R/3 and legacy HR.
Products (Materials) R/3 CRM Initial download via middleware.
Products (Configurable
Service Offerings)
R/3 CRM Initial download via middleware.
Products (Non-configurable
Service Offerings)
R/3 CRM
Manual data entry in CRM as Service
Products.

Sample Scope of Data Objects for Cutover (cont.)
Data Object
Current Source
System
Target System Migration Method
Spare Parts R/3 CRM Initial download via middleware.
Tooling R/3 CRM Initial download via middleware.
Resource Skills Training System CRM
Manual data entry until developed interface is
available in subsequent release.
Resource Calendar N/A CRM Manual data entry.
Pricing R/3 CRM Initial download to via middleware.
Installed Base –
Top Level Tool
R/3 CRM Initial download via middleware.
Installed Base (As-Built) Manufacturing CRM
One time download and ongoing download via
custom developed interface.
Installed Base Legacy CRM
One time extraction and load clean data via
custom program.
Service Contracts R/3 CRM Automated initial download via custom program.

Sample Scope of Data Objects for Cutover (cont.)
Data Object
Current
Source
System
Target System Migration Method
Warranties R/3 CRM
Automated initial download via custom program.
(Middleware should be the basis for the
interface.)
Open Cases (incl. FSRs) Legacy CRM Automated initial download via custom program.
Closed Cases with DMRs Legacy CRM Manual data entry.
Historical Cases Legacy N/A No data migration required.
Open Quotations R/3 CRM
Manual data entry of open quotations into CRM
service quotations.
Open Parts Orders R/3 CRM
Automated initial download and conversion via
custom program of open parts order into CRM
service orders.
Open Debit Memo
Requests
R/3 CRM
Manual data entry and conversion may be
required due to changes in service product
offerings and invoicing process.

Cutover Approach
• First pass: Frames the skeleton plan that is inserted in
the project plan with dependencies
• Each cutover has objectives that put flesh on the
skeleton based on progressive elaboration
• Trial cutovers progressively explore and discover the
endpoint requirements for final cutover
• It is a case of “You don’t know what you don’t know
when you start”
 For example: Number of plan line items grew from 80  250 for
final cutover as understanding grew

Trial Cutover Sequence — Planned
Aug Sept Oct Nov Dec Jan
Test Conversion Programs – ~75% success
rate, small samples of data

~95% success rate -Training Sys
– Master Data - conversion only –
Ran middleware downloads
~99% success rate = Final
Cutover – Timings –
Performance Testing

Trial Cutover 1
(Q/A)
Trial Cutover 2
Trial Cutover 3
Final Cutover
8/20 9/6
9/17 10/19
10/22 11/16
11/19 1/6

Trial Cutover Sequence — Reality
• The planned sequences elongated due to issues,
eventually running three in parallel
• This stretched resources to the utmost
• Ultimately all parts of the cutover were tested multiple
times until the piece parts executed without defects
• Ibase conversion was complicated by the introduction of
a new universal serial number
• Contracts conversion ran very slowly due to variant
configuration copied from SAP R/3 and > 30 lines in
the contract
• Added multiple parallel sessions to enhance
performance

Importing Custom Code
• Package solution  Project environment
• Identify re-usable source code
• Create transport requests in source system
• Import requests into target system
• Limitation — versions have to be compatible
 If versions are not compatible, still use as reference
• Benefit is speed, saves time
• Perform functional test

Migrating Custom Code
• In an upgrade situation, development team
must supervise
• Analyze
 What is obsolete? What is re-usable?
• Make a copy of the system
• Apply the new version
• Remove the obsolete code
• Work over the re-usable code
• Regression test

Performance Testing
• Objective
 To prove that the designed CRM hardware, software,
middleware, network, SAP R/3 and Portal solution will provide
acceptable performance to support the business and be
scalable for predicted growth
• Approach
 Develop test transaction sets based on “A day in the life”
around standard business processes
 Assume 80% of the work is based on 20% of the
business processes
 Determine volumes and create “virtual users” on the load
testing software application to simulate multiple users per
test PC

Performance Testing (cont.)
• Tools
 HP Load Runner
 IBM® Rational® Performance Testing solutions, Rational
Performance Tester Extension for SAP Solutions
 “Load-Injector” servers connected to the WAN in the remote
geographical regions containing virtual users and
execution scripts
 1 Gig RAM, P4, Intel Core Dual Processors
 1 Virtual User is equal to approx. 10 normal users
 Windows NT boxes loaded with ADoW in remote geographical
regions communicating to a centrally located box, monitoring
and reducing “trips” between boxes

Performance Testing (cont.)
• ADoW
 GUI doesn’t usually have a response time problem
 Portal usually does have a response time problem
 SAP Application Delivery over the WAN Software
 Dramatically improves portal performance over the WAN
 Calculate a four to six times improvement with ADoW
 Six seconds with ADoW would be 24 to 36 seconds without
 Our portal applications response time was 4.1 seconds or less
in Asia from the US
 ADoW provides an 8:1 reduction in traffic over the WAN

Performance Testing the CRM Solution
• End-to-end tests of all the parts connected by
middleware
 SAP R/3 CPU scalability: Max utilization >60% @ 300% load
 SAP CRM CPU scalability: Show excess utilization capacity
 SAP R/3 Main Memory scalability: Support 200% load
 SAP CRM Memory scalability: 20%of memory paged
out @ 200%
 Workload sharing across servers: Show equal distribution
 End-user response time: Target < 6 seconds
• Considerations
 Must have the core transactions and middleware working
 Can make exceptions for low volume transactions or processes
 Concentrate on 80/20 rule and execute all processes in parallel

Sample Plan vs. Tested Results
• “Big Bang” test from six regions: 200% of planned load
 US, Singapore, Taiwan, Japan, China, Korea
 Injected load from same regions over the WAN
Big Bang test,
achieved load
2008 estimated
transaction load

IT Department Touch-Points
• BASIS
 Systems and middleware
 System performance
• Security
 Access and authorizations
• Systems and version management
 SAP R/3
 SAP CRM
 Portal
 Backup and recovery
• Transport management
 Approvals
 Sarbanes-Oxley (SOX)
• Desk-top services

90
• Introduction
• Training
• Wrap-up

Change Management
• Significance
• Deliverables
• Managing stakeholder buy-in
• Readiness assessment
• Communications

Significance of Change Management
• A CRM system implementation is seldom, if ever, a pure
technology swap (i.e., legacy out, SAP CRM in)
• The capabilities rarely stand still and are usually the
drivers for the implementation
• New capability gives rise to policy, process, procedural,
job content and required behavioral change for
the stakeholders
• The capture of benefits associated with a CRM
implementation relies on adoption of the required
behavioral changes
• Change management is an essential CRM critical
success factor, and yet it is often marginalized
or ignored

The Mission
• A CRM Implementation is always undertaken to achieve
an ROI
• ROI is gained by real people adopting the new system
and processes and using it as intended
• Training is not enough in itself
• Changing behavior is critical to achieving ROI
• The focus of change management is changing behavior

Change Management Deliverables
• Organizational risk and readiness assessment
• Change strategy
• Stakeholder analysis
• Leadership action plan
• Global communications strategy and plan
• Mobilize and alignment plan
• Job impact assessment
• Work force transition plan
• Customer impact assessment
• Communications materials
• Organizational impact assessment

Change Management Methodology
Mobilize &
Align
Leaders
Design Change
Strategy
Support
Workforce
Align
Organization
Engage &
Communicate with
Stakeholders
Articulate A
Business Case
& Vision for
Change
Assess
Organizational
Risk &
Readiness
BearingPoint’s Change
Management Approach
Focuses on User
Adoption and
Sustainable Change
Mobilize &
Align
Leaders
Design Change
Strategy
Support
Workforce
Align
Organization
Engage &
Communicate with
Stakeholders
Articulate A
Business Case
& Vision for
Change
Assess
Organizational
Risk &
Readiness
BearingPoint’s Change
Management Approach
Focuses on User
Adoption and
Sustainable Change
• Assess organizational risk and readiness
• Articulate vision for change
• Design change strategy
• Mobilize and align leaders
• Align organization
• Support the workforce
• Engage and communicate
with stakeholders

Managing Stakeholder Buy-In
• You saw earlier the importance of the Stakeholder
• Stakeholders come in all shapes and sizes: executives,
management, users, internal and external customers
• They all share a common trait expressed as “WIIFM”
 What is in it for me?
• Find the magic formula and they will buy-in

Managing Stakeholder Buy-In (cont.)
• Executives and management
 $$$$$, corporate goals, personal goals
• End users
 Job satisfaction — Will it make my job easier? Why am I doing
this? Are you nuts?
• Internal and external customers
 Customer Satisfaction — How will my life improve because of
what you are doing?
• You have to be able to satisfactorily answer the
questions, and provide constant communications and
feedback reinforcing the message

The Role of Change Agents
• Someone who affects the acceptance of change brought
about by the new system and process in a positive or
negative way
• Identify and create change agents, persons of influence
who will help implement the new system
• Try to get the “water-cooler influencers” on your side,
especially if they have a reputation of resistance
to change
 Converts are worth their weight in gold
• The very same change agents can be Subject Matter
Experts (SMEs) who will also double as trainers in a
Train-the- Trainer strategy

Organizational Risk and Readiness Assessment
• How ready is the organization to receive the proposed
systems and operational solution?
• Are they aware of the impact on their jobs?
• Are they aware of the changes in policy, process,
and procedure?
• Do they understand what is being done?
• What are their reactions to the changes?

Job Impact Analysis
• Analysis documenting the changes in affected roles and
responsibilities.
• The existing job specification is the start-point.
• What job specification?
• Don’t forget policy, process and procedure in addition to
system related actions.
• There may potential OSHA requirements.

Customer Impact Analysis
• Determine the impacts to the customer at the
touch-points.
 Is the delivery process changing? What are the required
different behaviors?
 For example: You now must use a unique serial number to
open a case.
• Tell them what you are doing and what might happen so
they are not blind-sided, keep the complaints down.
• What reactions will you get from customer, and your
people will have to explain?
 “So now you have this new system your costs will go down,
how about my contract price being reduced?”

102
• Introduction
• Training
• Wrap-up

Training
• Planning considerations
• Challenges
• Instructor-led training
• Web-based training
• Curriculum development options

Planning Considerations
• Who needs to be trained?
 What are the job roles that are affected?
• What needs to be trained?
 What are the program’s learning objectives?
 What processes need to be trained by job role?
 What are the user interfaces involved?
 How will you measure based on learning objectives?
 How will you report progress?
 How will you identify learning gaps?
 How will you close the gaps? Refresher training?

Planning Considerations — Where, When?
• Where are they located?
 Are they remote?
 Can they get to a central location?
• When do we need to do it?
 How long will it take to train based on the delivery method?
 When will the system be ready for screen prints, etc.?

Choice of User Interface
• There are a variety of technology-based solutions
available to support a business process in SAP
• The decision regarding the best fit is not always about
functionality; the end user has to be trained
• To present a number of user interfaces would be
confusing and also greatly increase the training
workload at all levels
• The choice of user interfaces was the subject of a
business decisions document
 Recommendation shown on the next slide

Selection of User Interfaces
SL. No Role / Functions Proposed SAP User Interface
1. Back Office Functions
• Installed Base Management
• Service Quotations
• Service Contracts Management
Primary interface is SAP GUI.
Secondary interface can be Enterprise Portals
using CRM Business Packages
2. Billing & Invoicing Primary interface is SAP GUI.
Secondary interface can be Enterprise Portals
using CRM Business Packages
3. Field Resources Field Service Rep Portal (custom on Enterprise
Portal)
4. Field Resources – Mobile Blackberry – Antenna Solution
5. Interaction Center Interaction Center – WebClient within Enterprise
Portal. This will be transparent to user since it
will reside in the Enterprise Portal.
6. Service Resource Planners Resource Planning Application within Enterprise
Portal. This will be transparent to the Resource
Planner since it will reside in the Enterprise
Portal.
7. Service Managers Enterprise Portals using CRM Business Packages
8. BW Reporting & Analytics Web Reporting

Challenges Faced in Training Development
• The schedule stays the same and system delivery is late,
which pushes training development
• Enhancements are often late, screen prints are always
last minute updates
• Knowledge transfer
 What the system does and why, has to go from the SME, to the
training curriculum developer
• Where they are different, the learning curve can be very
painful and demands significant time of business people

Instructor-Led Training
Pros
• Interactive, allows questions
• More satisfying for the student
• Allows trainer to monitor better
• Allows customization
• Is more effective than WBT
• Allows change aspects beyond
the materials to be discussed
• In the language of the trainee
Cons
• Must have trainers trained
• Preparation time is the same
for every trainer
• Takes three sessions to get
familiar and comfortable with
the material
• Logistically, magnitudes
greater to implement than WBT
• Balance lecture, demo, and
hands-on
• No more than 15 – 20 minutes
of lecture or lose the audience

Web-Based Training
Pros
• No train-the-trainer required
• Reaches a wider, dispersed
audience
• Doesn’t require group
scheduling unless via a WebEx
• Allows the student to train in
off-peak times, reduces conflict
with the ongoing job
Cons
• Can only sustain interest in 30
minute bites
• Usually in English with local
sub-titles
• More expensive to prepare than
trainer slide materials

Curriculum Development Options
Onshore Development
• Cost
 Higher initial, saves in rework
• Ease
 Facilitated knowledge transfer
 Fewer communication problems
 Option to have the business
people develop the curriculum
with expert guidance
 Less rework
• Production
 Do it offshore
Offshore Development
• Cost
 Lower
 More rework/cycles
• Ease
 Travel required for knowledge
transfer
 More communication problems
 Rework and cycles higher
• Production
 Lowest cost
 Easy to manage

112
• Introduction
• Training
• Wrap-up

113
Resources
• Project Management Institute
 www.PMI.org
• SAP Safeguarding — Reduce implementation or upgrade
risk and cost and ensure proper performance
 www.service.sap.com/safeguarding
• SAP MaxAttention — comprehensive support
 www.service.sap.com/MaxAttention
• SAP Solution Manager
 www.sap.com/services/newsevents/press.epx?pressid=6549
 www.sap.com/platform/netweaver/components/solutionmanage
r/index.epx

114
7 Key Points to Take Home
• Don’t forget that today’s business has to be supported
tomorrow — define ahead of need
• Conduct solution reviews earlier than you are told
you can
• If you are going to incur a delay, take it when you first
detect it, waiting doesn’t lessen it, it creates more work
• Rework will kill your schedule, use the mitigation
• Plan for the multi-tasking and definition that users have
to do, it can delay your project
• Cutover always takes much longer than you think
• Work smarter not harder

115
Your Turn!
How to contact me: Peter Ware
peter.ware@servicewarellc.com

CRM Implementations and Upgrades

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to CRM Implementations and Upgrades (20)

Recently uploaded (20)

CRM Implementations and Upgrades