Overview

This will be a 4 part series to guide you through identifying and analyzing your business processes today and the way to implement a strategic solution which will set you up for future growth.

Objectives

1. Identify the Business Units and Users of your CRM 
   • Who uses the application and why do they use it?
   • What data is being used?
2. Bridging the gaps between Current State and Future State 
   • What are some of the current system limitations and workarounds that have been created to circumvent functionality limitations? 
   • Why are certain features of the software not in use today? Would using the functionality create issues for other Users?
   • What functionality can make your current processes more efficient and how do you position yourselves for future growth? 
   • How easy would be it be to scale solutions back if the Business were to take a different direction? 
3. Introducing the new software to your teams and providing training 
4. On-going support
   • Stay as up to date as possible with versions

Let’s Get Started …

While implementing a CRM, or another software program, this is the time to enhance and expand upon your current system capabilities, cleanse your records and to consider methods in which processes have failed in the past or should have performed better. CRM software provides a 360-view of your client, their current interests and potential growth. Ensuring that these records are accurate on Day 1 and maintained in a well timed fashion is vital. We’re going to walk through a few steps that can be taken throughout the planning and requirement phase to mitigate mistakes early on.

Where does the application sit and who are the Users?

Discovering what areas within your organization are reliant on the application and who the Users are is the first step in determining useability. In the case of a CRM, many times, the Sales and Marketing teams are a great starting point. Operations and Accounting can have permissions to read only data and/or export functionality so it’s vital to find out:

1. Who is using the application?
2. What data is being used? 
   • Why is it being used? 
   • When is it being used?
   • Is it being sent elsewhere?

This discovery process impacts not only who uses the application, what Users have access to and how current data is received but also the length of time the data may need to be retained. 

What data is used and where does it come from? 

Once the Users of the application and data has been identified, it’s important to understand what data is required and what data is optional or nice to have. Creating a data dictionary that consists of all data fields required, optional or recommended as well as the status of each data element can help determine the prioritization of how you’ll approach your implementation. For example, the Name Field is a required field and has an Active use status with a current last update date; however physical Business Address may be an optional field and only in use for a handful of  clients. The Business Address field can have a status of Inactive or the last update date could be years prior to now. 

All data should probably be retained or archived for at least a year but based on the nature and characteristics of the data, it may need to be stored for 7 years or more, depending upon regulatory requirements. Understanding what internal and external audit requirements are is also imperative to a successful implementation. 

Also, data can be received from internal and/or external applications by receiving a feed or call/answer feature that populates the data fields and makes it available to Users. In addition, once data is received sometimes Users have the capability to manually override the data field. Rule validations and error checks may also be in place to help protect the integrity of the data. Understanding how data is being received, where it’s coming from and whether it is editable will be impactful to the success of the migration. 

Lastly, data can be “real time” or “live” or can be received via batch so understanding the timing of the data is crucial.

How is your data protected and is there a Disaster Recovery plan/process?

Data Integrity is a key component of  your organization’s bottom line but so is data retention and disaster recovery. There are four phases of disaster recovery: 

1. Mitigation
2. Preparedness
3. Response
4. Recovery

Work with your technology counterparts and service providers to ensure your SLA’s for recovery time are clearly defined. Put policies and procedures in place to protect your organization against potential failures (internally and externally).

What are the system limitations? What workarounds (manual processes/processes that sit outside of the system) are in place?

When you identify a “Day in the Life” for your Users, try to determine whether the processes are optimal and provide the most efficient use of resources and time. There are many modules within a CRM that can be used to create better communication both internally and externally, such as task tracking and follow up. Sometimes, when a new application is implemented, not all of the functionality is put to use. It’s important to understand what’s not being used due to system limitations and define those system limitations as well as manual processes that are in their place. Oftentimes, functionality isn’t used because it entails a change to the workflows. 

Bridging the Gap – Current State vs. Future State

Once most of the items mentioned above have been flushed out, a clearer picture of your current state should be evident. You’ll understand what data is in use today, how it’s maintained and protected. Next, the workflows and processes need to be clearly defined in both the Business and Technology pieces. 

Think about the manual processes in place today and whether they can be automated with existing functionality or that will be available in the most recent version of the software. 

Create data workflow mappings between what is currently done and then do the same for the future state. Imagine optimizing a solution that not only fits your world today but in the next five years. Visualize how your organization can grow or possibly move in another direction where you’d still be able to leverage the build out. Also, solutions should be clearly identified and designed to prepare not only for future growth but also scale back, if necessary. 

Educating Users and Provide Training

Users should be exposed to the new software sooner rather than later. Engaging Users early on provides not only time for adjustment but also provides an opportunity for Users to become active in the project and buy-in. Engaging Users and training them should run parallel with implementing and rolling out new software and this can be done in a few different ways. 

After gathering current state requirements, provide a demo of the new software. Walk through it’s core functionality as well as some of its features and provide some of their “Day in the Life” activities as examples throughout the demo. This allows them to not only learn about the new software but creates relatability into their activities and how they’ll be impacted. This also helps facilitate new ideas and thinking into how their worlds can change for better or worse. 

Training can be done in a combination of ways – visual, auditory and tactile or hands on. After providing a demo of the new software and its features, Users can then be given credentials to log into a training environment to familiarize themselves and/or walk through functionality test scripts. Group training sessions can also be held where each user will use the system and walk through scenarios with the trainer. This is an effective process at not only bringing teams up to speed but also flushing out issues and/or defects which mitigates risk down the line.

Ongoing Support 

Having the most recent version of the software not only allows your systems to perform better and be more secure but you’ll also receive resolution patches for defects. Your organization can determine to opt in and install the patch or opt out. Implementing a patch though takes analysis and planning and it’s quite similar to a full blown software implementation. In addition to testing the patches “corrected functionality”, all existing functionality needs to be regression tested to ensure nothing broke or acts differently. Stay abreast of versioning, its new functionality, defect remediation and make informed decisions as to whether it makes sense implementing patches or waiting for the next full version of the software. Just don’t get too far behind on versions as it could add to the project timeline when you do decide to upgrade.