Why CRM Implementation Needs Training Wheels, Not Racing Gear
If it's true that the best CRM systems are built, not bought, then which features should you be building? And how should you build them? As with riding a bike, implementing a CRM system gets much harder once you take off the training wheels--or, in this case, the out-of-the-box features.
Tue, August 13, 2013
CIO — The most basic CRM implementations can be done as a "simple" package deployment, with no custom code and a couple of simple plug-ins to a standalone system. But that's just the basic ones.
More ambitious CRM implementations require more ambitious customization and extension. It doesn't take long before you have to think seriously about the development strategy you use. Making the wrong choice has serious consequences in costs, data quality and user satisfaction.
The specifics of this topic vary significantly for each CRM vendor. To keep this article short, I've focused on Salesforce.com, as covering all major vendors would require way too many pages. But the general principles explained here apply to all vendors.
Take Off Training Wheels At Your Own Risk
Salesforce provides a wide array of features that are essentially "training wheels" for early, quick deployments. The features are easy to understand, require zero coding and are (more or less) user friendly. For a CRM implementation with only a couple use cases, these features may be all you ever need.
Unfortunately, these training wheels are dead wrong for anything sophisticated. An easy example is using multiple lookup fields on the same object. One example is having fields for Board Member, Attorney, and Auditor on an account, all pointing to contacts. It's easier to understand and report on than using a junction object such as "influencers," which allows for an arbitrary number of people (of any job title) to be added to an account. Other common examples are using lead sources versus campaigns, or sending lots of emails from workflows. These are bad ideas all the way around.
The most critical items for review are validation rules, workflows and flows that users may have set up. These bits of automation will seriously conflict with custom coding. The two big areas of conflict with these technologies are the inability to fully control sequencing (leading to race conditions) and erroneous or misleading error messages (leading to chasing-your-tail scenarios). I won't go into the specifics; just know that when you bump into these issues during debugging, you'll start swearing.
The solution: As soon as you start doing any juicy Apex and VisualForce code for an object, replace all the workflows and validation rules for that object with Apex classes. This, along with all the test code you'll have to write, can be a major undertaking. But it's in your future if you do serious development.
You can take it one step further, too. Salesforce's best practices guidance states that there should only be one trigger per object. All the work of the many triggers you may have written gets moved into supporting classes, and all the test code for these classes accordingly gets moved into its own special test classes. This leads to a major code refactoring exercise, though Eclipse can help (somewhat). As you curse the hours you'll spend, just know that this is a "pay me now or pay me later" situation.