CRM Software Implementation

5 Phase Implementation Process Overview

Phase II: CRM Software Design and Conference Room Pilot

A Conference Room Pilot (CRP) is a systemic approach to prototype the proposed operation of an information system, to learn how it works or should work, and to decide how to best manage the business with it – prior to the go-live conversion.

CRP's usually begin with an introductory CRM software training course. In general terms, the CRP is used to test and validate the company's business model with the new business software system. The CRP results indicate confirmation or illustrate gaps and areas requiring a more detailed design effort prior to full implementation. Several CRP objectives are illustrated below.

• To explore policy and procedure alternatives and evaluate improvements
• To train project team members in the new CRM system, including configuration options, setup parameters, procedures, internal controls, modification capabilities and reports
• To gain a more practical understanding of the strengths and weaknesses of the software application
• To evaluate the software for fit and optimize the system where possible
• To test and confirm design alternatives for appropriateness and impact
• To help develop and confirm the plan for live data setup, conversion and implementation

A number of key decisions must be made when implementing CRM software modules. For each software application, there should be a designated subject matter expert (SME) or Sponsor who will assume responsibility for the configured application. Typically, the software vendor or third party consultant will provide implementation consulting to assist the project team in making these important decisions while setting up the CRP environment. The CRP configuration will force a balance between the operational desires of the company and the software's capabilities. Additional activities included in the CRP are highlighted below:

• Confirm end to end business process transaction flows
• Adopt new procedures and TFR’s (transaction flow reviews); this activity is often facilitated with the CRM software's automated work-flow design tool
• Explore and confirm the design of primary CRM keys (such as Customer ID, Customer Name, Territory, Lead Source, etc.)
  • Consider building intelligence into the keys where it makes sense - you may want to segment keys or force certain characters to represent types of values
  • Recognize the permanence of most primary keys - they are not easily changed as history must also be updated for analysis and comparative reporting
• Map out the data conversion process. Sample and verify the cleanliness of the historical data; scrub data as necessary, then perform another sample conversion and reconcile; Don't convert dirty data with the intention of cleaning it up after it is in the new system
• Explore the configuration setup and file maintenance software parameters; they generally can be manipulated to offer significant work-around opportunities
• Document user and system security profiles; confirm integration and back door security tests
• Review, develop and tailor (transaction entry) forms; if you modify forms do it by user role or class and not by individual users; test and verify efficiency with actual users performing actual tasks
• Catalogue your reporting requirements (report format, content, production frequency, distribution, etc.)
• Develop integration points and data transfer design documents early; plan for thorough system integration testing
• Evaluate and develop system enhancements or productivity aides which will promote user adoption
• Perform frequent system and user testing; first by project team members and then by random actual users

Business Process Alignment
CRM software implementations offer an ideal time to revamp and reengineer business processes. While business process improvement (BPI) exercises do impose additional change (which therefore requires additional change management), they also offer increased efficiency in conjunction with the new software for a more powerful result. The diagram below shows a common approach to business process alignment.

 

As-Is Process Review: In this step the existing business processes are analyzed with the objective of identifying process activities, workflow patterns, decision points and end results. The current (‘As-Is’) processes provide a base line so that the future (“To-Be”) processes can be developed and measured.

 

Develop To-Be Processes: In this stage, the proposed business processes are defined. In addition to the AS-IS analysis, the key inputs to this step are recognized best practices and the functionality of the CRM software product being implemented. These three inputs provide the basis for creating the “To-Be” business process. These processes are usually documented in the form of visual diagrams called process maps.

 

Identify Software Gaps: Many functional gaps between the To-Be process and the CRM software product may be identified in the prior step.  During this step, the To-Be processes are compared directly against the CRM software functionality.

 

Categorize Gaps: In this step each gap is prioritized into a schema such as Required By Regulation, Required By Organisation, Required By Line of Business, Desirable and Non-Essential. Based on the priority of the void, alternative methods to meet the process requirement are evaluated. The options for consideration normally include the following:

• Software configuration. This option indicates that the functional gap can be remedied by making a change to the CRM software configuration or setup parameters. This is sometimes accomplished through the vendor’s modification toolkit and does not require the product to incur source code modification.
• Process workaround. It's often viable that an acceptable work-around can be identified in order to meet the process requirement. This often entails a minimal change to a business process work flow.
• Software customization. Software customization is typically the most expensive and high risk alternative to meet process requirements. It is important to recognize that customization is a recurring expense as it must then be upgraded with each new software version release.

The CRP analysis phase will complete an initial review of existing business processes, map upgraded processes, possibly incorporate best practices within the context of the application software, describe new functionality and ultimately determine the method in which the CRM system will be deployed to meet identified objectives.

 

While new application software brings exciting and rewarding changes to the company, it doesn't remedy all of the company's challenges. In many implementations, managing change of both business processes and information systems can be one of the greatest challenges. The proposed implementation approach should consider and plan for change obstacles and incorporate a formal change management mitigation strategy.

 

CRPs and prototyping are proven to work. Modeling the business software system through a series of prototypes or pilots that, through each iteration, more closely model the business requirements and stakeholder vision, increases the likelihood that business objectives will be realized. Further, by seeking the input and feedback of the user communities during each phase, the proposed system will both adapt to user requirements and steadily earn the buy-in of the user communities.

 

Good CRPs also accelerate project team learning, identify issues and opportunities early in the engagement life cycle, set realistic expectations for project team and incur far less risk than a live pilot or big bang implementation.