Not long ago I had a discussion with a company where, I were proudly informed, they were able to expand their portfolio of applications far beyond their peers. They were eating into the backlog at last.
I were surprised, however, to find out that the way they had done this was simply to extend the depreciation on each and every piece of technology — equipment and software packages alike — to reduce the costs they were carrying. That created the financial room to do more.
Does this sound odd? It shouldn’t — it’s been a common practice for several years now.
One of the reasons we were having the discussion was that now they felt trapped.
Much of the operating budget was tied up in years of outstanding depreciation still to be worked off.
Meanwhile the collection of applications — which included much duplicate function and many bridges, both automated and manual — had become an operating cost burden in its own right, as packages slipped far beyond their “best before” date (and maintenance was withdrawn), and the cost of keeping things running continued to mount.
Unlike traditional infrastructure, from buildings to factory equipment, information technology has a far shorter life-span.
This is not always obvious, as software doesn’t appear to wear out, and equipment can often be extended through prudent management of software change.
In other words, what this company was doing would have looked perfectly reasonable to anyone with an asset management background in physical plant, fleets, or in finance, which we can sum up with the cliché “if it ain’t broke, don’t fix it”.
Still and all, things were wearing out, if you connected the dots.
Things were breaking in many different ways, but not in ways that show up on outage reports.
Remember: software once implemented models the work requirements of the time of implementation. If these change, the software and the work grow apart.
Nearly 100 clerks were handling data transformation by extracting data from one package into Excel spreadsheets, doing one operation on it, and reloading the data into another package for continued processing. Needs had changed but the systems weren’t keeping up.
Another small army of clerks was trying to reconcile differences in the general ledger arising from corrections being posted in the source application, and only summary data being kept in the target.
Managers in the business couldn’t easily see simple things (e.g. “how much are we spending on office supplies”) due to procurement being handled in multiple applications and a project-based accounting layout was integral to one system rather than either activity-based costing (a second system) or an organizational budget centre approach (the final ledgers).
A great deal of the duplicate function existed as one group or another’s work changed, and a new package implemented to fit the change would be used — but only for that group.
The infrastructure itself was a mass of small purchases from different suppliers, thanks to a procurement policy of “only buy by RFP, and only buy the lowest viable bid”, so that consolidation never really got started.
Instead, the whole mess was outsourced, thus locking in the disarray.
When you shift to a managed portfolio approach, it’s necessary to understand that there are two key dates to keep in mind.
One is the “best before” date: this is the point in time by which all depreciation — including depreciation associated with subsequent changes — must be cleared off the books.
That has nothing to do with when the depreciation according to the tax code or your own internal standards says the cycle has ended. It has to do with the deviation between work and implementation.
Certainly, you can make changes. But these too must be depreciated.
At some point, the whole system will need replacement. This, in practical terms, implies a “freezing” of changes that attract depreciation ahead of the “best before” date, if only because the remaining period is too short to write the change down.
Then there is the “removal” date, which falls after the “best before” date.
The goal is that, under normal circumstances, replacements occur around the “best before” date, not, as often happens, after the “removal” date.
This date has been chosen to minimize deviations in the way work is done and the implementation that exists, and gives an opportunity to “catch up” to incremental change (as well as reconsider choices, deal with the fallout from vendor mergers, etc.).
The “removal” date is the absolutely last day this technology can remain installed (so that, even under abnormally difficult circumstances, regeneration of this part of the portfolio is a top priority item, displacing other projects, once the “last date to start work” to meet the removal date has arrived.
Without these disciplines, you may have portfolio inventories, and analysis of the implications buried in that inventory, but you don’t have portfolio management.
Keeping things running smoothly and efficiently involves a steady change-over of assets.
For most organizations, this will mean their portfolio will need to shrink, for shorter replacement cycles than you are currently following mean almost all of the portfolio is being depreciated concurrently, or operating budgets will need to rise to create more “depreciation room”.
This, in turn, is one good reason to look at Software-as-a-Service or selective outsourcing as an interim step to rebuild your portfolio on a new financial footing — not one that is entered into for “savings”, but one which allows the portfolio to be refreshed and the replacement cycles initiated by organizations with greater buying power.
Being “hunkered down” and waiting out difficult years by stretching an already-stretched portfolio further are tactics which will cripple the enterprise and become a “value drain” in the business.
Meanwhile, the cycle time for IT solutions continues to tighten, as cloud deployments and “-as-a-service” offerings continue to improve.
It would be prudent — even in times of turbulence for the business — to straighten this out.
Manoeuvring room will be vital to deal with vendor change and business change in the years ahead.