Step back and think: How would you answer the question, “What does your IT group deliver to your business?” Your answer will indicate how you think about the relationship between business and technology, and, in turn, it will affect your business agility and your business-IT alignment.
If you answer anything close to “IT delivers and integrates solutions to meet business requirements,” your mental model boils down to thinking that your solutions support the business: Business is one thing; solutions are a separate thing. If the business has a problem, let it come ask IT for some application to address the problem — maybe IT will even help the business figure out what it needs. Each application supports (typically overlapping) parts of the business, and IT performs whatever behind-the-scenes integration is necessary to gain some degree of coherency across the whole. The result is the sort of siloed spaghetti application mess that most organizations are dealing with — even if SOA and BPM and the rest make it easier to deal with.
One of the most common questions I get is: How to we assure (or, improve) the adoption of a CRM solution in our organization?
In the past, the clumsy user interfaces (UI) of CRM solutions have turned off users, causing them to reject the solutions offered by their IT departments. In response to these complaints, the leading CRM solution providers, such as Oracle Siebel CRM and SAP CRM, have invested heavily to improve the UIs in their most recent releases. The same is true for midmarket solutions like the Sage family of CRM products, CDC’s Pivotal, and Sugar CRM. salesforce.com has achieved great success with its pioneering UI that incorporates the ease-of-use characteristics of consumer-oriented solutions that employees are used to working with in their private lives. And Microsoft Dynamics CRM applies the vendor’s knowledge of the use patterns of desktop applications, and incorporates the familiar Outlook UI paradigm, with a focus on improving user productivity.
In addition to choosing a CRM solution with a modern user-friendly UI, what can you do to improve adoption? Here are eight tips that I picked up working with the CRM leader at major bank:
Define your business processes before selecting technology. "One key to success was that we defined a standardized sales process before we purchased the technology to enable it. We had a team of users study our sales processes and define better ways of working for the future.”
MyCustomer.com recently asked me what my thoughts were about CRM: Why initial CRM projects failed, what has now changed to make deployments successful, and what the future holds for CRM. Here is the first part of my point of view, as well as a link to a series of three published articles from MyCustomer.com.
Question: Nearly a decade ago, estimates suggested that a very large proportion of CRM projects were failing. What were the main problems undermining CRM projects in those days?
Answer: The main problems undermining CRM projects a decade ago were mismatched expectations with reality in three categories: technology, process and people.
The first CRM systems were not fully baked and had large feature holes that were not always communicated to the purchaser. The technology was not intuitive or easy to use. It was hard to implement with long time-to-value and hard to become proficient in its use. It was even harder to change the business processes that had been implemented — changes that were necessary to stay in line with evolving business needs.
CRM systems were also difficult to integrate with a company’s IT ecosystem, which meant that many actions needed to be repeated in multiple systems. (For example, consider a CRM system that was not integrated into a company’s email system. This means that a sales person would have to cut and paste a customer communication from their email correspondence into the CRM system, which was labor intensive and often not done. )
Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.
Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.
Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.
Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.
Similar to the past few years at this time of year, we are in the process of preparing a global banking platform deals report for 2010. As we have done since 2005 to help application delivery teams make informed decisions, we will analyze deals’ structure, determine countable new named deals, and look at extended business as well as key functional areas and hosted deals — all to identify the level of global and regional success as well as functional hot spots for a large number of banking platform vendors.
In the past, some vendors told us that they are not particularly fond of us counting new named deals while only mentioning extended business, renewed licenses, and the like. Why do we do this, and what is the background for this approach? First, extended business as often represents good existing relationships between vendors and banks as it represents product capabilities themselves. Second, we have asked for average deals sizes and license fees for years, but only a minority of vendors typically discloses this information. Thus, we do not have a broad basis for dollar or euro market shares — and I personally shy away from playing the banking platform revenue estimates game.
An Alternative Counting Model Could Be Implemented Easily . . .
Consequently, available data makes counting new named deals the only feasible way to represent an extending or shrinking footprint in the off-the-shelf banking platform market — and thus to also represent customer decisions in favor of one banking platform or the other. Some vendors suggested introducing weights for the size of the bank and the relevance of the seven world regions (for example, North America and Asia Pacific). We could easily do so, but there are problems with this approach: