Don't Treat IT Assets Like Junk Food

Ann All
Slide Show

Why Enteprise App Portfolios Get Bloated

Check out new research from HP and Forrester.

A few months back I likened the way many companies use their IT assets to folks shoving potato chips into their faces. They ingest them without much thought as to which ones are really necessary, at some point realizing they are no longer lean or healthy. Just as being less agile makes it tougher for folks to perform on the tennis or basketball court, reduced business agility makes it tougher to introduce new products and services or otherwise maintain a competitive edge.

 

This happens with software applications, which I addressed in that post, noting that companies running unneeded, outdated or duplicative apps also tend to have more technical platforms, more data models, more fixes and upgrades, greater fragmentation of expertise and more duplication of work-all of which slow project completion and increase IT costs. A whopping 80 percent of IT decision-makers surveyed by HP and Forrester Research said obsolete and overly complex technology platforms had significant or critical impact on application development productivity.

 

It also happens with hardware, as seen by a City of Los Angeles audit of three government agencies in which the agencies couldn't locate nearly a quarter of the assets on a list of randomly selected items, including such pricey items as a $60,000 video recorder.

 


Just as with consumption of junk food, companies tend to think their own IT asset-management practices are much more virtuous than they really are.

 

When I interviewed Honorio Padron, the Hackett Group's Global IT Advisory Practice leader, he told me companies need to take a more holistic view of their IT assets. When introducing a new asset, be sure to consider retiring any existing ones it might replace and create a plan for doing so. Perform regular inventories of assets, which will not only help target ones that can be eliminated, but may yield other savings opportunities such as reducing the number of software licenses.

 

Sure, these suggestions sound like common sense. But it's not always easy to retire assets. Reluctant business users sometimes resist. As Padron told me:

It's like a restaurant that adds a new menu item. When it goes to drop an item to make room for the new one, somebody probably says, "You can't get rid of that. Three customers in the world still eat it."

In the Forrester/HP survey, 44 percent of respondents cited business users' over-attachment to applications as the biggest hurdle to retiring applications, followed by busy IT departments (43 percent), inadequate budgeting for data migration and storage costs (40 percent) and leaving apps in inquiry mode for data access and/or compliance reasons (40 percent).

 

So, what's the answer? In some cases, I wrote several weeks ago, it might make sense for companies to get help from a consultant, service provider or other outsider. Some messages, especially ones we don't like, carry more weight when they come from an outside authority. In many organizations, managers find it easier to dispense-and more importantly follow-recommendations when they come from a consultant. Hopefully consultants can also help establish an asset rationalization process that will mean their help is less necessary in the future.

 

I also like a suggestion Steve O'Donnell makes on The Hot Aisle blog. He says all IT systems should have two owners, one from business and one from IT. (I'd add this list, just like asset inventories, must be kept current. It should reflect any changes in business roles. If folks leave, are promoted or otherwise switch jobs, new owners must be appointed.) As he writes:

The business owner needs to be willing to pay the running costs and the technology owner has to have the responsibility of delivering the service. Just by cataloguing your IT systems and switching off those that don't have owners (of either type) you will reduce costs and improve reliability.

Peter Kretzman, author of the smart CTO/CIO Perspectives blog, chimes in with an insightful comment. Decommissioning assets is a core (albeit unheralded) function of mature, robust IT organizations. As he points out:

A great deal of IT in general consists of laboriously, tediously dotting the i's and crossing the t's. When you have a situation where "perhaps the decommissioning phase got missed" (and we've all seen them), it's characteristic of an organization that isn't dotting and crossing a whole lot of anything.

In line with other experts I mentioned in my posts, Kretzman says all proposals for new systems must spell out which assets will be replaced, depreciated or turned down, with associated costs (and cost recovery) outlined. He also notes it's the CIO's job to make sure decommissioning of assets isn't glossed over. Writes Kretzman:

The CIO/CTO can't be so concerned with strategy and innovation that he/she ignores the operational thorniness associated with implementing that strategy. As the cliche goes, the devil is in those details, grinning and making mischief.


Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.