« Concealed Weapon | Main | Drain The Moat »

Revolutionary CRM Thinking

What happens when the central IT function chooses a standard CRM software platform required for all to utilize, but built for another business unit that does not adequately match your needs? Many times the results mirror what we have all been watching on the evening news over the last few months. When a government is consistently unable to deliver on the needs of its citizens, those people eventually take to the streets. This began in Tunisia and has spread across Northern Africa and into the Gulf States. I have client organizations that have either recently struggled through the same process or are in the midst of it currently, with less violence, but no less drama.

It starts with a smaller division or business unit. They have a slightly different business model than what appears as the company norm. The central CRM platform chosen by IT to serve the enterprise does not fit. Literally it was built for a different part of the organization. The smaller division makes attempts to make their case for something else, but they are a minority and are told to comply. So they take matters into their own hands. With the backing of a senior executive they perform corporate rebellion and don’t adopt the standard CRM platform but secure their own, which fits their needs and can be managed within their own means.

Meanwhile, a second division, a bit bigger, but with a very different commercial market is also struggling with the functionality of the centralized CRM. It has different sales stages than theirs and includes product and process references that are literally meaningless to them. The word gets out that a small business unit just jumped ship and went with a different CRM package. A few meetings happen and a business case is built, and then presented up the chain of command for approval.

Then a cascade of defection occurs. The following fiscal year IT must renegotiate their contract with the CRM vendor. The number of projected users has been cut by 55% and plans for expansion have been halted. A few of the rebellious divisions have collaborated and worked out a cross-division contract on their own with the competing platform vendor. Their cost per user is nearly 30% lower.

Have you witnessed this first hand? It is common and growing. I raise the example above as an opportunity from which others might learn. Let’s look at what leads up to a situation like this.

When I have had the ability to perform some investigation into the histories of this kind technical revolt I have found that it starts with the software selection process. IT conducts an evaluation of different packages, but one or two things get in the way of it going down a successful path. First, it is not uncommon that the selection committee is made up entirely of IT team members. The business is not involved or has only a token presence. Second, the objectives for the selection fit financial and technical objectives: economy of scale, ease of support, robust software programming capability. Business objectives are often in conflict: flexibility to match divergent needs, ease of use, administrator-level change control. I even have two recent clients where the selection team, which did include business representatives, chose a package using a rational evaluation process, but a different vendor was eventually selected because it was deemed the better technical solution. When the software is chosen to primarily satisfy IT, the stage is set for a business coup.

Old Kicks on 66

A variation on the business involvement problem is selecting the software that fits the largest, loudest or closest business user. The software platform might have been a good fit for most groups, but it was built for one and then exported to others as if an afterthought. More groups might have been happy with the original package, but it was so heavily customized to fit someone else that it really can’t be used without pain.

So, the result is that a portion of the business takes matters into its own hands. The most common form of this is the mushrooming nature of micro-IT, the resource work-around. Business units can’t get what they need from the technology IT has given to them, so they hire their own technical resources to compensate. The sales stages in the CRM system don't fit so they build their own pipeline management tool. The central reporting uses the wrong data model so they build their own data base. The examples are virtually endless.

These rogue IT resources represent the symptom of the problem – the business cannot get what it needs from the software so it finds a way to get needs met on its own. This wastes resources and sub-optimizes the objectives for justifying a central CRM platform. Customer data is spread haphazardly all over the place, support is uncoordinated, and the corporation spends too much time and money on sub- par performance. And, this does not even raise the strained reputation that IT suffers in the eyes of the business as a result.

Ultimately, the question is about the balance between software standardization benefits versus higher flexibility and business needs satisfaction. Behind each end point on this continuum are two philosophies with deep entrenchment within each camp. Some of you out there are thinking about all the reasons why software standardization is so critical and some of you are thinking why standardization fails the business (and I’ll acknowledge there are some fence-sitters likely as well). Yes, standardization has many elements of logic to its case. But when the standard approach impedes the business to perform customer-facing tasks and achieve targeted outcomes, the logic fails.

I think it is time to challenge the infallible nature of the standard, single platform position. It may serve the financial and technical interests at headquarters but has a growing track record of not serving the interests of the business in a multiple business unit enterprise.

I have two recommendations – one for IT and one for the business stakeholders.

IT needs to explore and understand why it is not meeting the needs of its customers and embrace a more customer-centric approach to service delivery. IT exists to serve the technology needs of the business, not develop and control software with the least per capita cost. The IT function must still serve in a leadership capacity to guide the use of technology correctly, but it must satisfy needs in a way that supports the realization of business outcomes as its prime objective.

In parallel, the business needs to fully articulate its requirements, both current and future state, and provide clear examples of where technology and support are leaving gaps in the fulfillment of requirements. It is impossible for IT to be successful in satisfying needs when they have to guess at the requirements. These requirements must also include service level agreements that are defined clearly. Expectations have to be clear.

A final consideration: many large organizations are attempting to accomplish a one-size-fits all approach with a single, global on-premise software platform. This is rapidly becoming an outdated approach and we need to change the paradigm. We can attempt to satisfy multi-group needs by building local instances with customized functionality, but that drives software proliferation in the same capacity as using different packages. Data is hard to share or integration is required. Or, multiple groups live within a single, heavily customized instance that has liabilities for managing enhancements and upgrades. Releases take considerable time due to regression testing and business need satisfaction is delayed.

These multi-group situations are increasingly going to be satisfied best with the introduction of SaaS applications that enable the flexibility of business-unit level tailoring while collectively benefiting from both the infrastructure and data residing together in the cloud. But the paradigm change goes further than the consideration of hybrid software platforms. We also have to redistribute IT to work within the business and for the business. By distributing both the right technology and the right technical skills across the business units IT will have the maximum power to truly satisfy business outcomes. It may appear to some like letting go of the control.

Well, I guess it is letting go of the control.


I don't think the problem stops with selection. In implementation, IT rarely asks the important question "does this need to fit your exact requirements, or will you adjust your business process so that the system can remain flexible?" And in the rare instances that IT asks that question, business is rarely able to accept anything less than exactly what they ask for. The result is that as business changes, the tool has become too narrow to easily change with them.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)