Enterprise Application Value

This is a continuation of the last post, The Goal of IT where I tried to separate out how IT as a business function contributes to the goal of a company. Most of my experience is in Enterprise IT – that is IT is a function of a larger business enterprise, not specifically creating IT products or services for sale.

Enterprise IT is typically regarded as a cost center, not a revenue center. We are a support service to the larger business model, not dissimilar to facilities, legal, or human resources.

In the last post, I claim that IT exists to support the goals of the larger business enterprise, which are ultimately, to make money. The way IT accomplishes this is by delivering application capabilities, period. Working application capabilities that are used by business people, to increase their throughput, reduce their operating expense.

The business gets value from application capabilities in the same way a manufacturing plant gets value from machine tools, it uses them to increase the throughput of the manufacturing process. If a machine is not used, it does not increase throughput. The same is true for software – if it is not used, it cannot add value.

The same is true if the business has people with excess capacity. If your staff have excess capacity, then application capabilities that increase their capacity does not increase throughput. However, if your business growth is constrained by human capacity, then application capabilities can enable business growth. Likewise, if business growth is constrained by customer satisfaction and application capabilities can enable increased customer satisfaction then application capabilities can enable business growth.

So that is all well and good, but what if business growth is constrained by profitability? What if you need to lower operating costs so that you can lower prices or fees without lowering your net profit margin in order to grow? If I already have excess capacity, does investing in new application capabilities that increase capacity (lower direct labor input per service or product) help me lower operating expense? Only if I go down head count. In fact, if I already have excess capacity, I could drop head count but if employee engagement drops, or if customer satisfaction drops, I have a different constraint on business growth.

Its not enough for application capabilities to contribute to the bottom line, they must be proven to contribute to the net bottom line.

The cost of the application must be overcome with the net bottom line contribution, that is over the life of the application, the cost of capital investment – depreciation, plus the cost of maintenance and operation (including infrastructure) should be less than the net bottom line contribution, otherwise IT is just a welfare program for the technically inclined.

How hard is it to prove this net bottom line contribution? In my experience it is damnably hard – and most organizations that do not sell software or sell application development services, do not expend the energy to account for IT in this way.

Organizations may allocate IT expenses back to departments that use applications based on real expenses – and they may accept capital contribution from departments for new application capabilities. They may require departments to propose ROI on capital contribution, and they may even require chopping heads if that is the payback on ROI. Most IT organizations centralize and consolidate as much infrastructure as possible, and they may try even to consolidate applications across user departments or major business functions to reduce the overall operating expense within IT. But this consolidation actually makes it harder to measure benefit of individual capabilities or even to review your entire portfolio of capabilities to see which ones are being consumed (used).

Most larger IT organizations create a project management office to supervise the expenditure of capital, actively managing a portfolio of projects, but many do not actively manage their portfolio of software assets with the same rigor. Active portfolio management would require some means of articulating the current business value as well as the total cost of ownership (TCO) of each software capability. I think that most organizations would struggle to find an objective way to value software assets, or to express in purely financial terms the contribution to the net bottom line of any software capability. In fact, many organizations struggle to paint a compelling picture of Total Cost of Ownership for software capabilities in a way that would allow them to passively manage the portfolio, according to an upward cost trend assuming a flat value trend.

If I used these metrics as the basis for making IT decisions, it would lead me to question the following assumptions if they existed in my IT organization:

1) It is always beneficial to consolidate capabilities into a single application platform.
2) It is always beneficial to consolidate application capabilities onto share infrastructure platforms.
3) It is always beneficial to reduce infrastructure platform diversity (to have a smaller number of different OS’s, DBMS’s, App Servers, Language standards).
4) It is always beneficial to follow our current technology expertise (to implement platform that our current staff understands deeply).
5) It is always beneficial to optimize capital application delivery projects against cost and schedule constraints.
6) It is important whether we use capital or operating expense to pay for new application capabilities.

What other organizational assumptions and biases might we throw out, if I started valuing software assets and capturing an accurate picture of total cost of ownership? How would that change the way we deliver and manage IT?

No Comments

Leave a Reply