A Few Technical Notes on the Implementation

Let's now consider two technical issues that have implications in business decisions starting early in the project: the issue of the development environment versus the production environment, and the issue of migrating data from existing tools to the new tool. Both should be addressed and a strategy developed in the kickoff workshop.

Development/Test/Production Environments

It's good practice to maintain three distinct hardware and software environments for CRM systems (or any other systems for that matter): one for development, where any coding and changes are performed, one for testing, where development changes are checked before impacting any real work, and one for production, where the users do their work. The advantage of maintaining three different systems is that it's possible to experiment safely without impacting the production environment. At the start of the CRM project you only need the development environment, of course. If you are using an integrator, it's likely that the development system will reside there, which allows the programmers to be more productive and which typically requires little setup work. At some point down the line you will need to create a development environment at your site so you can handle further development past the rollout date, if nothing else. Development environments are very small versions of the real thing and therefore easier to set up and much less expensive. Nevertheless, make sure that the setup of the development environment is planned and scheduled appropriately, down to who will be responsible for purchasing, installing, and configuring each piece. The testing environment is required from the first series of tests, as we will see below, and even earlier if the development environment is set up at the integrator's site so you cannot use it to do demos or other work at your site. The testing environment should resemble the production environment as much as possible if you want to run realistic tests, although it's usually on a smaller scale. Here again, determine who will purchase, install, and configure the test systems. One major concern about maintaining the development, testing, and production environments is devising a robust system for migrating code and data from one to the other. It's best to have an automated system to do that to avoid human errors. Sadly, many CRM tools are very weak in that area. Follow the suggestions of the integrators for how best to handle the migration to minimize effort and mishaps. Many smaller companies cannot afford to maintain three different environments, and indeed some companies work with only one. It's clearly dangerous to make unproven changes right in the production environment, so try to maintain at least two environments, so you can develop and test on one without impacting production.

Data Migration

If you are moving from an existing system to a new system, you will have to face the issue of migrating existing data to the new system. Existing data usually requires some amount of coaxing to match the new data structure, and sometimes quite a lot. Therefore, before you undertake what can be a very large effort indeed, you should think long and hard about whether the old data is worth transferring, and how you can make sure that the data you want to transfer is as "clean" as can be. For instance, if the old system contains your customer database, you probably will want to move it to the new system. But is the data in the database correct? For instance, if you have scads of dormant customers, you probably don't need to bother transferring them. If you have duplicates, or other bad quality information, you should put in place a data-cleansing program rather than moving junk over. After you spend time and effort cleaning up the data for the migration, you'll want to keep it clean, so define an ongoing process for checking and cleansing data. This is not a part of the CRM project per se and may not have much impact for months, but it's one of those additional touches that make the difference between so-so and great CRM implementations. As you analyze data to be migrated you may find that some is not worth moving at all. A common example is old knowledge base documents. In a fast-paced world, documents over a year old, or documents that are waiting for review are probably of little use and should simply be left behind. Make a backup if that makes you feel better, although I bet you will never use it. The same is true with old service calls or old sales records. Don't expand effort migrating data that will not be used.