Naturally, if you're in the market for a reasonably large system, you have a great many ways that you can customize the system for your organization's particular needs. But even if you're small you have some choices to make, and possibly a little customization to do.
But options and customization means decisions and decisions inevitably mean you probably can't have the system do everything that everyone in the company would like it to do. So, where do you put the emphasis? What department gets what they want, and which departments have to give something up? Or does everyone share the suffering and everyone gives something up?
The natural tendency is to try to get the system to do everything everyone wants and when it is obvious that it can't, to have everyone give a little, meaning on one really gets what they want, but everyone gets a little something.
That design by committee tendency results in failed installations. The system never lives up to expectations because it never really had a chance to impact any department in a meaningful way. When everyone gets a little but on one gets it all, everyone ends up frustrated, with the company being the biggest loser.
The natural first question is why is the system being implemented? What is the primary purpose for the system? Is it to exchange information between sales and customer service? Is it to manage compensation? Is it to track the activities and behaviors of individual salespeople in order to improve sales efficiency? Is it to coordinate the activities of and exchange information between sales and marketing?
That natural first question however should be secondary to the question of who will be primarily responsible for imputing the information. Is it marketing? Is it sales? Is it payroll or shipping?
If the primary user sees little or no return on their time investment, the installation will fail. If sales is responsible for the bulk of the data entry and the individual sales team members are the ones doing the data entry, they must see tangible benefits to themselves or they simply won't give the system adequate attention; likewise if the primary user is customer service, marketing, or any other department.
Certainly, senior management can dictate compliance. But demand compliance seldom works well. Bribery can be used, but that tends to wear off after awhile, meaning the bribes have to get bigger to maintain compliance.
Rather than trying to force a system that offers little benefit for those who are primarily responsible for its maintenance, why not recognize human nature for what it is and design the system from the beginning to cater to the natural tendency of employees to use those things that help them and avoid those things that don't?
Rather than creating a system that encourages resistance, why not opt for a system that encourages cooperation? If customer service is the primary user, institute a system that will bring real benefit to customer service reps. If it is sales that does the heavy lifting, design a system that gives salespeople real information that will improve their ability and skills to sell.
Does that mean your system might not do all they you want? Yes. Does it mean that some departments will be disappointed? Yes. Does it mean that eventually you'll need a system primarily for those other departments? Yes.
But talk to one of the companies that has thrown millions upon millions at systems that do a little for everyone and not much of anything for anyone and you'll probably be happy to invest a fraction of the dollars for a system that really does do something of value.
Fortunately, technology is evolving and may someday be able to be all things to all departments-as some developers currently claim their systems to be. Until that day comes when the wish is a reality, it is best to remember that human nature isn't evolving quickly enough to expect your employees to act outside of what's beneficial to them.
The Management Curve is a blog dedicated to discussion and debate about the impact sales metrics programs such as CRM, Sales Performance Management and Sales Force Automation Programs are having and will have on how the sales function is managed. Hosted by Paul McCord, the blog also features articles and commentary by other sales trainers, consultants, product developers, and the sales managers and salespeople who actually use the products.