You Can’t Run IT Like A Business (except Maybe You Can …)

An overused phrase, and one that I am not a fan of.

Let’s run IT like a business …

It’s a valid sentiment, to be sure. Many people realize that IT (along with other internal support functions like HR, Finance, and Legal) should correctly focus on Customer Service, with a consistent focus on priorities and alignment (“the Mission”). A well-run business does not sit back in the data center watching the servers – we want to focus on the value that we are creating with our systems and services.

Unfortunately, like most abstractions, the comparison only goes so far. Yes, it is important to treat our partners in the business with respect, and work with them on projects and processes that will drive the business forward. But the “run IT like a business” analogy is problematic for a very simple reason.

IT does not generate revenue

We do not charge our peer organizations for the services we provide. We do not invoice them every time we go that extra mile. This is truly a partnership – we make sure our goals are aligned and we are focused on the same objectives. We all have our roles to play – and we will deliver on those expectations in the most effective way possible.

The Analogy has Limits

Well-intentioned IT leaders, and their functional peers, want to apply running-a-business concepts like customer satisfaction and value creation to the operations of IT (and other support functions).

This is how I can demonstrate that I “get it” …
This is how I can become a “value creator” …

The problem, however, is easy to see. The work done by IT is not denoted in the same “currency” – the same type of value. Businesses define objectives, results, and daily impact in revenue and earnings. These transactional measures are tied to everything, from productivity and utilization all the way up to Total Shareholder Return. For a functional area that has no revenue, this means that any best practices, comparisons, and lessons learned only work at the highest levels of abstraction.

Take the idea of 8020 – the established practice of focusing on the 20% of products (for example) that generate 80% of the revenue. The methodology is powerful – if you eliminate the long tail of marginally profitable products, and cut the costs required to support them, you will see massive change in the profitability profile of your company.

What a great idea – lets apply it to IT systems! We will inventory all of the systems, reports, integrations, etc. that we support, and identify the 20% of systems that generate 80% of the …

Hmmm …

The analogy falls down when you realize that IT does not operate to generate a profit. Ok, so how am I going to identify the 20% of systems that generate 80% of [something good] when there is no measurable profit in the world of internal IT?

Change the Language to Shape the Analogy

Analogies are abstractions, patterns we apply to similar situations so we can adapt clever tactics to new domains. Simply put – if we can describe things with the same words, we can apply the same fixes. But “same” is a powerful concept here – it sets a problematic hurdle because we are comparing apples to oranges. So let us use the word similar, and see what happens.

The formula behind profitability is the basis of the Income Statement – something that we are all familiar with.

Revenue minus Cost = Earnings

Upon this rock I will build my wonderful 8020 analyses, and drive meaningful value for the company.

But as I have pointed out, we cannot use the same formula in the world of IT. Okay – let’s use our imagination. Suppose we change the formula like this …

Impact minus Effort = Results

Now this is something we can apply to the world of IT. Effort is straightforward – especially when the team is grousing about the extra effort required to support these low-value systems.

Impact could mean any number of things – the amount of support a system gives to core processes like Make-To-Ship, Record-To-Report, and Hire-To-Retire.

Results? Well, that is just funny math to express the dilutive effect that required Effort has on an Impact-ful system.

With this analogy, we can start talking about IT like a business – but a slightly different kind of business. When you abstract any business optimization methods (like 8020 ) using a different expression of the basic formula (Impact minus Effort = Results), you have a pretty powerful way to understand where your internal systems are creating or destroying value.

ERP – core to the operation of the company – typically a huge Impact, with many users every day, whose jobs depend on entering accurate transactions. Compare this to the one-off custom report – used by one or two people, for an hour or two “once per month” – important to those folks, but tiny in comparison. Next, consider the Effort required to support such systems – backup, availability, training, access. Yes, it takes more than a few people to support the ERP, but the Impact is huge. Meanwhile, all those one-off reports that have built up in the report library over the years must be managed; will IT have to back up, restore, and validate all of it every time we do a version upgrade? So much cognitive attention consumed, for such a small return.

The Long Tail of Impact

Given the conceptual idea of Impact minus Effort = Results, it is easier to imagine doing an 8020 analysis, identifying the long tail of non-value-adding systems, reports, processes, and other technical artifacts that are taking up your teams’ time and attention. A tremendous target list for a complexity reduction exercise – freeing up your time to pivot towards real innovation that can drive your company forward.

This is what the exec team and the Board of Directors has been asking for – how can we grow through innovation? This is what your team has been asking for – how can I get hands-on experience with the new technology? You can answer both of these questions by going through an 8020 exercise to understand where is this best place to focus your time.

How many other metrics and methods are in use across your business? And how might you adapt them, really get into the spirit of the metric, and adapt to comparable metrics that let you apply the same breakthrough thinking?