In previous posts, I have talked about the notion that some of the IT portfolio provides services that are common to any organization, regardless of its nature, and that some of the portfolio provides services that are part of what makes this organization unique.
But how do you know what is a true differentiation, and what is merely historical (“the way we have always done things”)?
Ideally, when a common service is clouded by historical differences, we’d like to change the way the enterprise works so that it could use the common approach. That would allow us to use packaged software, or software-as-a-service, without modifications, thus removing the cost to apply those changes and allowing us to benefit from changes introduced by the supplier of the service. (This is otherwise known as “getting value from your maintenance fees”.)
Real market differentiation — unique products or services supported by technology that allow for high market share or superior prices (because of the value to the customer involved) — are an obvious differentiation to support in the IT portfolio. These are worth the cost of code, its maintenance and support.
Real mission differentiation falls into the same camp. Military and intelligence applications are but two examples of situations where the value isn’t monetary, but nonetheless there (in this case, the less known by the outside world about how you do things, the better). (Many other functions may make this claim: the burden of proof should be on them that the secrecy has a true payback.)
Then there’s the middle ground, which is occupied by products that used to be unique (but have now been copied by competitors), or work practices that used to be required but which time has passed by (such as code to handle rounding up and down to avoid handling coins in an era when pay was in cash, in envelopes), or the attempt to retain old forms and procedures from, say, the paper-based era into an all-on-screen age.
There are several tests that can be used to ferret these out.
One is an experiment that requires nothing more or less than a meeting room. The assumption to be discussed is that “you can’t have this anymore”. Come up with all the risks to the enterprise of having to change the way you do things to the way a common service works. Assess those risks: if there are too many conditionals (“under this rare circumstance if we don’t have this field this could happen”), or too many “just in case” responses, you’ve probably located something where changing the work is the right answer.
Another is to build some financial models where the cost to own and operate the customized solution is compared to the cost to own and operate a common service. Good Chief Financial Officers and Controllers will start pressing for the lower of these two. (Don’t forget to build regular version upgrade cycles, with all the retrofitting, into the models: you’d be getting them with the common service — especially if software-as-a-service is chosen — and so need them in both cases.)
A third is to work with a software-as-a-service vendor to establish a testbed, and let the affected areas actually experience the change.
Every enterprise needs to optimize its IT spend: resources should be minimized where the value to the enterprise that the work generates is low, or where the work is routine, so that they’re available to create value elsewhere. Cleaning up unneeded differentiations so as to have more of the ones that do make a difference is a good starting point.