If you have been selling enterprise software in the last five years, you have undoubtedly gone thru the following scenario multiple times. You did everything that you know you should do – you have put in a perfect value proposition, your software scored most points in a bake off with other competitors – you even got a off the record assurance from the business users that yours is the software they will recommend. And yet you lose the deal – sometimes to the ERP vendor and increasingly to a decision to make a home grown solution.

Whatever happened? After interacting with scores of CIOs in some of the largest companies in the world, this is what I have distilled in my mind…

The shift of power to the CIO

Ever since the internet bubble burst, as organizations have realized that they went overboard in buying packaged applications (most of which could not be implemented due to want of implementation funds and time), there is a subtle shift in power that has happened in this buying process. And that is the emergence of the CIO as the more powerful decision maker. It used to be the business side of the house. But that underwent a change.

Don’t be fooled into thinking that business value of a solution lost its utility. It absolutely remains a driver. Contrary to popular belief, CIOs are totally aligned with the business folks in extracting business value from their investments. However, a second driver has emerged as a decisive factor in many of these decisions – and that is the Total Cost of Ownership (TCO).

TCO includes not just the license cost of buying the application but also the cost of implementing it, integrating it, writing code to extract data and massage them and then more importantly, maintaining all this over the years.

And here is where the whole charm of best-of-breed application vendors starts falling down. While a lot of software has been written in the last 15 years solving some business problem very elegantly, very little has been done, in what I have seen, to solve the CIO’s problem. A typical supply chain product implementation across the industry as an example usually had the following breakup – for every $ that you spend on license software, you will spend anywhere from 30 to 50 cents on hardware and other middleware, anywhere between $4 to $10 on professional services (to configure, implement, integrate etc), and another 1 $ over the next 5 year or so for annual maintenance.

Add to that the cost of upgrading the software (application vendors will invariably ask you to upgrade once every 3-4 years and these are not simple technical upgrades of putting the CD in and pressing some buttons here and there) and the cost of the internal people or external contractors who are involved in the long term maintenance of the implementation code written. Now you get an idea what makes the CIO cringe even though you are asking for just a $ of product to be bought.

This is where broad providers like ERP vendors win. They may not have the best and most elegant solution – but their “good enough” solutions are very attractive since that avoids a lot of the integration and data manipulating costs (the story at least from the ERP vendors is that the new modules work perfectly on top of the old data models). Maintenance is far less of a cost and there is one less vendor/provider to deal with for the CIO. If you read a previous blog I had written about mergers, you will realize that it is the same driver – focus on total cost of ownership – that made the winning mergers rewrite the acquired software all over again with their existing architectures and data models.

The re-emergence of home-grown software

The swing towards the home-grown software is occurring ever since three things have come together. First, as I explained, the cost of making a best of breed solution sit on a pre-existing IT environment is high. But the fun starts after you have decided to spend that money. No pre-packaged software ever solves all the business needs and requirements that you have. (That is the nature of the business – it is not necessarily the fault of the application vendor). However, for you to get those features built in, you are asked to stand in a queue of other customers and follow the product release deadlines that the vendor has.

While vendors are absolutely eager to help you and see how to expedite things, there is no guarantee that your feature will be put in. The vendor is in the business of making standard products and will always prioritize “commonly asked for” features higher than the rest. (Don’t forget the sales and competitive pressures R&D organizations go thru also – their internal sales/executives saying “have to have this feature else we will lose the deal”!!). From the CIO’s point of view, he can’t care less about all the plethora of features that he never uses. He just wants his stuff – his way and that’s all he is asking for.

Second, as the budget of the CIO kept getting squeezed over the last five years, the ratio of money spent on “new projects” has been going down. A CIO divides his/her budget roughly into two parts – the ongoing maintenance of existing systems and then “new” projects. Pre-2000, the new projects could command as high as 25 to 30% of the total budget. Over time, that has been squeezed down to sometimes as low as single digit of percentage. Think of ongoing maintenance cost as almost fixed cost. And as budgets got squeezed beyond those levels, the CIOs started adopting the India model whole scale since that brought down their maintenance side of the budget by about 30% on an average.

However, the business demands did not sit tight just because budgets were being cut down. If anything the landscape became even more competitive and customers were less tolerant of service levels being missed. In this world, the CIOs started looking into the possibility of harvesting their existing investments. Technologies like web services have made it much easier to leave the existing code as is and put wrappers around and use these existing functionalities in workflows that you can build outside these code bases. These are usually called composite apps. The theory is – as I said above – you put in wrappers over your legacy code to expose the functionality as web services. And you can write composite apps that use these web services and any new ones that you write to solve a business problem. You leverage the existing data models as well as functionality.

Finally, the emergence of quality labor at a fraction of a price from the India vendors has made it much easier for the CIOs to attempt to build these solutions themselves. And some of the CIOs have gone to the extent of opening up their operations in India themselves (almost without exception, given the market of India, these companies have some sales presence and a legal vehicle already existing in India). Opening up your operations gets you further cost advantage (almost 1:4) but on the other hand you take on some of the management problems on yourself.

In any case, hope this helps you understand what goes thru a CIO’s mind. Hope this will help you in steering your company strategy on how to build solutions. In the least, you will know how to give a good sense of where your products are on the TCO front to the CIO.

Rajib