thing that struck me in these surveys that I read was that one of the business reasons for perceived failure was lack of user adoption and not lack of functionality.
So worded that way it sounds like common sense. But in reality a lot of people when they’re looking at a problem that they want to solve with technology, the first thing they look for is functionality. Hey, we need a CRM to improve our sales force’s efficiencies, so which of these products gives me the most bells and whistles? They start out with this IT-focused objective, looking at applications relative to which provide the most functionality. They prioritize user adoption and user ability too far down on the ladder when that is the key to success. That is it, man. It doesn’t matter how expensive, how profitable, how functional your IT solution is, if your users don’t use it, it’s failed – whether they’re internal users or consumers.
So usability is the number one metric for success and keep in mind that most of the IT solutions that we all use every day, we use only a fraction of the functionality. Look at how much we use of Word and Excel and Outlook. If you guys have seen some of the extensive feature that have been out of the box, available to us from day one, and yet we use the same features every day. You know, as a user we’re not that sophisticated when it comes to production. So, keep that in mind.
Another interesting thing, if you really haven’t dipped your toe into the technology waters for the last five or six or seven or ten years, our industry has changed tremendously. It’s normal for industries to advance. You know, home building techniques get better, houses get stronger, they get cheaper, so IT has experienced that same evolution. But I think it’s been on hyper speed since the dot-com era and it’s a very unique occurrence in our lifetime. I think it has catapulted IT much more so than the average growth that an industry would have seen.
In other words, back in ’99 or 2000 during the dot com era, literally billions of dollars were pumped into our sector. Whether it was a good decision or not that’s irrelevant, it was pumped in and what that did was create a ton of IP. A ton of sophisticated applications and hardware and data centers – huge data centers with all kinds of redundancy and power backup and all kinds of people. The flood of people into our space that were trained and became highly skilled was unlike any other period.
So then in the meltdown of 2001, those things did not evaporate, they didn’t disappear. People got different jobs, the IP was sold for pennies on the dollar, the data centers. And probably around 2005/2006 you really saw the results of that investment come out in new products and new offerings and it really catapulted the options available to a business looking to automate. I tell you if you’re looking to provide a portal for your company to collaborate internally or you want to put in a CRM solution for your sales force, or you want to add e-commerce to your customer facing Web property, the options that you have today are ridiculous compared to what was available 5, 10 years ago, both in functionality, cost and ease of implementation. So, again, if you haven’t looked, you’re going to be surprised at the options from hosted solutions that are hosted out on the cloud, require no installation, or on-premise installations. Or open source solutions that are free but tested. They run the gamut, so it’s pretty exciting.
The next bullet – avoid IT for IT’s sake. John hit this as well. You know, I think this sounds obvious here but it’s typically done backwards in my experience. Your business decisions should drive your IT decisions and not the other way around. In other words, you don’t want to go and look for a CRM solution because it’s all the rage and everyone has one.
The process that I recommend for a typical business to go through and you can decide how deeply you go into this process, is start with a requirements analysis. Get your business folks around and discuss the problem you’re trying to fix from a business perspective. In fact, I encourage that you assume that anything is possible from a technology perspective. Assume technology can do anything and there’s no budget constraints. The point is don’t apply a technology filter to that thought process. Discuss the problem from a business perspective. What the solution looks like, what the users need to see. What are the usability issues? What are the integration issues with other platforms? What are the preferences relative to products? Is it Microsoft or Unix? Get those issues down either in a formal requirements definition document or an informal back of the napkin, but have that process first before you start thinking about technology.
Once you have that, you kind of know what your solution is going to look like, you need to do a build versus buy. It simply means are you going to build a custom solution or are you going to buy an off-the-shelf solution or typically, these days, it’s some hybrid in the middle. That’s an important process. We have frequently used RFIs in that process – requests for information. It’s really just an informal RFP, but it allows you to get data from vendors – both custom development vendors and off-the-shelf vendors to see what your options are. Then when you’ve made your choice, you go find your solution. You build it or you get a vendor in, put out some RFPs. Then they match up the technology options against the business needs that you’ve already defined in your requirements document.
The next option, John mentioned as well, follow your customers, don’t lead them. Sounds a little harsh, but what I mean by that is – it’s tough to be a market maker. It’s tough and expensive. It’s tough to get consumers to do something that they have proven they don’t want to do. I would argue some have done it. Maybe Esurance has done it in getting more consumers to transact online than others. The Geicos and the
| Page 2
| Page 3
| Page 4
| Page 5
| Page 6
| Page 7
| Page 8
| Page 9
| Page 10
| Page 11
| Page 12