CRM systems have become the norm for many companies, but the process of making changes or customizations can throw...
companies for a loop.
As developers make changes to the system to enable processes, customization or automation, it can cause unintended consequences for the existing CRM configurations in place. Particularly for companies that have already customized the system more extensively, the release management process can create a domino effect of change, which is disruptive, and invites errors and problems.
Cloud-based CRM providers, such as Salesforce, for example, make updates to the customer relationship management platform three times a year. Reading the release documentation can help, but the goal is to ensure that all CRM admins, developers and users are up to date and functioning properly post-release. To ensure a successful CRM release management process, consider your change management processes and tools for automating a CRM deployment.
Best practices and tools for a problem-free release management process
Every CRM platform should have a release management schedule and process in place for deploying changes and enhancements to the system, no matter the complexity of the change. This ensures that unforeseen issues can be addressed well before users are affected. Still, it can be tedious and time-consuming for admins, especially if you deploy weekly or biweekly.
Successful release management hinges on proper user acceptance testing (UAT) to ensure that the changes are beneficial -- and have no unintended consequences. And then, regression testing must be conducted to ensure other features were unaffected by the change. Depending on the complexity of a company's CRM system,configuration can take days and multiple people to complete regularly. This can create a process that involves finding every piece that has been added or changed, and adding it to the set.
For larger organizations, UAT testers and project managers have been designated for release management tasks, given the speed-to- market requirements that often accompany CRM changes. This further increases the cost of such a system and gives many organizations a headache over the resources needed to run a CRM without incident. But you can reduce these issues by setting up a proper sandbox structure.
, consider your current process and where improvements could be made. Creating a sound sandbox structure and test scripts are necessary to take advantage of a change management tool.
A sandbox should never be used to develop anything; it is merely a testing sandbox for and enhanced features. You may have one or multiple sandboxes, but one should be dedicated to release management testing, and nothing should be pushed to production before tests in this sandbox pass. Underneath this sandbox, also establish sandboxes for developers and admins -- perhaps a few for large projects that require their own system for development -- and then a hierarchy of sandboxes to combine projects and test before UAT. UAT may act like this for smaller organizations, because they do not have very many sandboxes to utilize or large projects to manage.
With a sandbox structure in place, create a list of all the key areas of the CRM platform that should never "break," because they are too integral to users' daily tasks. This can be as broad or as limited as you want, but anything that is critical to the business should be included, and test scripts should be made to test each function before each deployment. For those who do not already have such a list in place, you can develop it simply -- even in an Excel spreadsheet, with a step-by-step process on how to test the feature, and those can do the testing.
Finally, the team should evaluate the true business need for deployments. Can changes be deployed monthly, or do they need to be biweekly, weekly or even daily? Given the amount of testing, can the team possibly meet these needs with a manual process, or should a system be put in place that can automate some of these steps?
Buying change management tools for release management
There are also change management tools to help track and audit your CRM changes, such as continuous integration (CI) applications AutoRABIT or Dreamfactory's SnapShot, which aim to simplify integration of CRM and development.
Today, the change management software field is broad, and each application has different features, so evaluation of your current process and what is important for you is key to making the right decision. AutoRABIT, for instance, is a continuous integration application that works with your subscriptions to GitHub and Selenium to create a data backup that can be searched, filtered, tested and pushed automatically into test or production environments. They use your test scripts to create an automated version that can be run prior to each deployment, which saves many man-hours. You can schedule deployments for every night or month, depending on need, and tell the system to stop deployment if any tests fail.
With Dreamfactory's SnapShot, profile updates are aggregated all on one page; users can perform enhanced search through metadata; and an audit report can be created with a click of a button. While test scripts are not included, the ability to pick and choose what profiles should get access to a feature is great for a company that has many profiles. And the auditing feature is perfect for industries such as healthcare and financial services, which need to prove security of content within a CRM system. Flosum and Copado are also continuous integration tools for deployment management within Salesforce. Jenkins or the xRM CI Framework are good options for Microsoft Dynamics.
For companies that make substantial changes regularly in their CRM systems, it is worth investing in a program that can back up, test and deploy features seamlessly without manual touch. The ultimate goal should be development that can be pushed between UAT and production environments automatically, without a manual schedule. Users are unaffected by the changes, but are nonetheless getting the newest and best version of the CRM.
A release manager talks about software rollouts
Managing change in release management
Why release change management is more complex