There's been a lot of talk about implementing CRM in nine days and 90 days. What is missing from the 90-day im
CRM in 90 days is typically an out-of-the-box, take-what-you-get approach. What's missing is any reflection of what the business problem is that you're trying to solve. Most CRM is designed to drive increased sales, to increase market share. It's a top-line focused initiative. In order to leverage top line initiatives, you need to get people to buy from you as opposed to buying from your competitors. You have to leverage what makes you unique. If you implement an out-of-the-box relationship management system, what you're doing is taking the unique dimensions of your business and relegating that to the business processes and overall structure of the imposed system. That's why most people do so much customization.
How much customization is needed for a CRM package to do what a company expects?
Usually, there's substantial customization to render any real value. ... For example, if I'm a company and need to map a selling process...if I have to make structural modifications to get there, a lot of times it's going to take months. We've all heard stories of the 18-, 24-, 30-month implementations. There's a reason why people spend that kind of time and that kind of money, but the problem is, by the time you make those modifications, generally the business has changed.
A component assembly approach... leverages the existing environment to a much higher extent.
What can companies expect when they choose a rapid implementation?
Probably a disaster. It depends on who's providing the rapid implementation. More often that not, (rapid implementation) infers that you're going to take what you get. You'll use an imposed data model with no changes. You may get rapid implementation, but you're going to have to modify your company's own process to match what the system itself dictates.
What are the problems with that?
There are three specific problems with that. Problem number one is that the approach of the system may not match how you do business. For instance, the sales cycle steps may be different. Second is the information needed by the system usually will reside in one or more other systems in a different manner. This approach causes you to either recreate that information entirely, or use pieces of that information out of context in ways that it wasn't originally intended to be used, or forced into a model that's onerous. You either have to change it, and you're no longer looking at a rapid implementation, or you have to use it in a less valuable way, which is compromising the overall value of the system. And third, ...assuming you can change the process to match the imposed system...that assumes that all the people who are users of the system can and will change the way they behave and operate. That's really unrealistic. In fact, a lot of times when you look at a rapid implementation where you impose business processes to fit a new system, you're basically telling people they need to change the way they work to fit the new system. ...You end up with an adoption rate that is minimal, and the information that goes into the system becomes useless because unless you have complete adoption and a buy-in of using the system, the information in the system itself becomes invalid.
FOR MORE INFORMATION: Best Web Links on Implementing CRM