Search
Close this search box.

IT-Business Value chains revisited

IT Business value chain

IT-Business Value Chain

Have you ever felt frustrated that business people donโ€™t understand the value of your work in IT? I certainly have and this was the reason why I spent some time thinking about how to translate the value of IT services to a business context. I wrote a blog on the topic in 2016 and have now come up with another way of expressing the โ€˜ IT-business value chain โ€™.

The figure below says it all, but need a voiceover.

Value chains revisited v02

The value flows from left to right, from IT to the business. As a side note, โ€œthe businessโ€ is becoming a strange notion now that IT is often such an integral part of doing business, whether itโ€™s used as a production resource or as part of the enterpriseโ€™s products and services that influence the customersโ€™ experience.

Bottom line

Starting on the right-hand side, enterprises can be private or public organizations, but for this value chain Iโ€™ve chosen a profit-oriented private organization, with the following generic bottom-line concerns:

  • Valuation of the enterprise, dependent on material assets and immaterial assets (such as image and reputation)
  • Revenue, dependent on price and volume of sales
  • Cost, determined by operational expenditure (OPEX) and capital expenditure (CAPEX)
  • Risk profile โ€“ the probability that the enterpriseโ€™s valuation, revenue or cost will be adversely affected

This is of course pretty basic stuff, but using these fundamental terms keeps it simple.

Public organizations have differing concerns of a more societal nature. For instance, an organization in the justice sector would be concerned with the citizensโ€™ perception of safety and appropriate treatment of perpetrators and victims of crime. This is the equivalent of โ€˜revenueโ€™ for a private organization.

Fast IT

Now moving to IT on the left-hand side and starting the flow of value, we start with the assumption that IT should be good and cheap, and delivered quickly. Again, basic terminology.

Iโ€™ve put โ€˜fastโ€™ in a slightly different dimension, โ€˜servingโ€™ good and cheap. Itโ€™s the speed with which good and cheap IT solutions are delivered. Fast in itself is meaningless.

Fast IT is not only about delivering functionality quickly (throughput), but also about prioritizing the various work items in a way that delivers the functionality with the most value first. Don Reinertsen refers to this as the cost of delay, and itโ€™s a really important notion to understand. If youโ€™ve got several work items to be executed, which sequence of execution will generate the most value? Calculating the cost of delay helps you take the right decisions and Reinertsen provides you with the mental tools to do this. But even if you donโ€™t calculate it in detail, just thinking about it will be better than capacity-based prioritization.

Cheap IT

When we talk about costs, particularly with managers, itโ€™s good to make the distinction between the money that you spend on stuff (assets), and the money spent on using the assets (operations). Assets represent capital expenditure (CAPEX), and operations is operational expenditure (OPEX). Having fewer or cheaper assets reduces CAPEX, and running them more efficiently reduces OPEX.

Itโ€™s good to realize how significant IT costs are as a proportion of total enterprise costs. This varies enormously from enterprise to enterprise, depending mostly on the sector. I consulted a professor in information economics to get reliable figures. His research indicates that enterprises in the Fintech sector could spend around 30% of their total costs on IT. In an enterprise like Shell, however, that owns non-IT assets such as oil rigs and tankers, IT is insignificant as a percentage, being just a couple of percent at most. From a cost perspective, itโ€™s not going to be the boardโ€™s highest priority. But the discussion is shifting from cost to value, as weโ€™ll see in the next section.

Good IT

Good IT has two dimensions: utility and warranty. These are familiar concepts for people who have taken more than a cursory look at ITILยฎ.

Utility is the functionality that IT provides to meet a particular need (fit for purpose). Utility can be expressed in how IT contributes to the enterpriseโ€™s valuation, revenue, cost and risk. In the past, IT was mainly used as a way of reducing costs by automating work and reducing labour costs but increasingly, IT is being used to increase revenue and the valuation of the enterprise, for instance by creating an attractive digital experience for the user, resulting in a positive image. Because IT has a direct effect on the customer, it is an instrument for competitive advantage. And the quicker an enterprise can get these benefits, the better. Which is why I spent some time talking about the value of fast throughput of functionality with the highest utility.

Warranty is the promise or guarantee that the utility (functionality) will actually be available (fit for use). Warranty is usually expressed in terms of non-functional requirements such as availability, performance and security. Warranty is mainly about reducing the risk that valuation, revenue and cost will be adversely affected; utility can also contribute to reducing risk, for instance by reducing human error (and hopefully not introducing algorithmic error). Just as with โ€˜fastโ€™, Iโ€™ve put warranty in another dimension, โ€˜subservientโ€™ to utility. Thereโ€™s no warranty without utility to warrant.

Strategic IT matters

Some final thoughts on value. As I mentioned previously, the discussion about IT is moving from cost to value. Sometimes even valuable enough to be taken seriously at board level. This is not a flippant comment. We in IT have often been dismissive of executive managersโ€™ reluctance to get involved in things IT. But there was method in their apparent madness. They simply had more important things to do. They are not stupid โ€“ if IT was really important, they would have spent more time on it. They would have invested time in understanding IT. The only thing that you needed to know about IT was that being involved in IT was not exactly something that was likely to benefit a C-level career. It was an acceptable trade-off to leave it to the CIO, with the not inconsiderable corporate political benefit that they could blame the CIO when it went wrong.

But if IT can not only break but make an enterprise, then the boardroom tables will turn. In Nicholas Carrโ€™s 2003 article IT Doesnโ€™t Matter, he made the point that โ€œwhen a resource becomes essential to competition but inconsequential to strategy, the risks it creates become more important than the advantages it providesโ€. Letโ€™s do some reverse engineering. Think about IT in your enterprise. Does IT (have the potential to) drive the enterpriseโ€™s strategy, to change its business model? If IT is on your boardโ€™s agenda, then IT is probably strategic.

SHARE :
Saas Customer Success
application migration
data science certification

Explore our topics