Every so often, one should tackle a Big Question.
While the first (2006) edition of my book featured an IT value chain, I realized that I needed to think more deeply about IT value in the second edition. One new set of influences was Lean thinking applied to IT management. I'd read The Goal, other Goldratt books, and much Lean material. In particular, I was thinking about the following classic passage from The Goal, in which the protagonist (Alex Rogo) is asked:
...tell me, what is the goal of your manufacturing organization?" he [Jonah] asks.
"The goal is to produce products as efficiently as we can," I tell him.
"Wrong," says Jonah. "That's not it. What is the real goal?"
But I needed more. I translated the conversation to an IT context and thought about it. What was the goal, the purpose, the value of IT?
Of course, there is no question that (in a for-profit organization) the purpose of the IT organization is also to make money. (If you're in a nonprofit, substitute "execute" or "provide services" as you see fit.) However, that was too simple. One could say it of any constituent function within the business. What does IT do, specifically, to help a business make money?
After all, the Law department helps the firm navigate often-treacherous legal waters. Human Resources assists in the hiring and management of people. Sales finds and nourishes the all important customer relationship. And so on.
I could have said "IT runs computers" but since computers are themselves IT, this became perilously close to a tautology. And it leaves unanswered the all important question of context. Why - and when - are computers important? How exactly does IT contribute to the bottom line?
Some insight came via reading Adventures of an IT Leader, by Richard Nolan. In that book, the protagonists observe:
you can usefully distinguish, not just in IT but in other areas too, between investments that are merely "Qualifiers" and investments that help you "Compete." ... A Qualifier investment keeps you in business. You have to qualify to run in the race, but Qualifiers only buy you a place at the starting line. A Compete investment gives you a potential edge over other companies in your industry...
But this wasn't quite enough either. As they note, the idea of qualifying versus competing might apply to any part of the business, any kind of investment.
The final piece came from my ongoing interest in the history of computing, and ultimately deconstructing the term "Information Technology" into the historical roots of each word.
Technology is means to an end, and seems to be a somewhat subjective term. Information, on the other hand, is a rich concept. Claude Shannon gave it a rigorous mathematical definition. Even when less formally defined, it still has to my mind more specific connotations than "technology." Context-specific, actionable data is a very common definition.
So, taking these three inputs, I have been developing the following definition of IT value:
IT Value is found in qualifying the organization to participate in information-rich, transactional environments, and -- to the extent that performance depends on excellence in managing information -- in elevating this performance above peers.
I've been working with this definition for about a year now and I believe it holds water. It's at least an hypothesis. It clarifies IT value in a manner that is falsifiable, since information can be quantified. If you can show me a relatively information-rich competitive situation that does NOT need IT services, that would falsify the definition.
I've considered changing "information-rich" to "information-constrained." This is not to say that the flow of information is constrained. Rather, it is to say that the organization could become constrained by a lack of ability to deal with the richness of information in its environment.
The purpose of all this is to enable better understanding of Lean IT, including the application of tools from systems theory. If we understand what the goal of IT is, we can understand where it falls short in supporting the value expected of it.
PS. That 2006 value chain, essentially a Plan/Build/Run construct, I am increasingly abandoning in favor of a Demand/Supply/Execute framework.