Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Why CRM implementation needs training wheels, not racing gear

David Taber | Aug. 14, 2013
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.

Now for the coup de grace. Remember the old days of error logs that were actually useful in debugging production problems that happen in the middle of the night? Those logs are just a fond memory unless you build code to capture error conditions and generate them yourself.

Salesforce, like nearly all cloud-based applications, has training-wheel logging. For performance and storage reasons, the logs are recorded only when explicitly requested-and they stop after a few transactions. Since error conditions are the most important log events, the logs should be stored outside the system, pushed out by some nice Web service classes. I've been looking for a Salesforce add-on for this, but I've yet to find a good one. This is an area where system integrators have to develop their own toolkits.

Get back to agile-first principles
In IT, coding is second nature. Salesforce is a well-thought-out platform for building business apps. So knock yourself out for features that are absolutely required.

Reread the word absolutely in that sentence, because you'll be tempted to add some features that really aren't critical. In the land of Salesforce, features aren't as important as data quality. Features aren't as important as flexibility. Features-unless explicitly requested by a lot of users-get in the way.

How? Ongoing flexibility is a critical success factor in CRM systems. This lets them accommodate the inevitable changes in requirements over years. Every feature you code in Salesforce will reduce the system's flexibility in the objects you touch and, perhaps, in related objects. Too much code means the users can't even add pick-list values without a complete coding, testing and deployment cycle. If you don't build your code in some really clever ways-using lots of introspection and dynamic techniques, for example-the tiniest changes made by users can have big consequences.

Even if you're coding in the best possible way, the code from third-party products may not play nice. Every time they upgrade, and every time you make a change, there may be hundreds of test failures and new anomalies to troubleshoot.

You really have to apply the fundamentals of value engineering and agile. Keep the training wheels on as long as you possibly can-and when it's time to get serious, create just the essential features with the best coding practices you can. Then you can add the Shimano and Campagnolo racing gear.

 

Previous Page  1  2 

Sign up for CIO Asia eNewsletters.