Application Rationalisation Techniques

By Phil Hames

1. Overview

Application rationalisation is the radical reshuffling of an application portfolio as part of an application strategy, a plan that implements changes to applications to achieve a business outcome.

Many organisations try to achieve this by reducing the overall number of applications but many fail to deliver the expected benefits of reduced cost and increased efficiency. This article outlines the problems and how to overcome them with a logical and effective process.

2. Why bother with applications rationalisation?

Essentially if you don’t use any software applications then you do not need to have any IT infrastructure and associated costs. Therefore the logic would indicate that if you reduce the number of applications then you will also reduce your overall costs of IT. The relationship can be summarised by the “software iceberg” diagram as shown below. You see the visible costs of the software licenses and support but it is much harder to relate these back to all the supporting costs.

Over time there is a tendency for IT requirements to change, business processes are revised or eradicated and organisations change so that the supporting software applications become irrelevant or of less value to the organisation. In addition there is a tendency towards duplication of applications, for example one retail organisation admitted to having 12 different software applications for performing essentially the same task but their business units had each chosen different products from different suppliers.

As organisations move towards new platforms such as cloud there is a natural tendency to remove the complexity of application where similar or duplicate exist. If this isn’t done they will replace an old inefficient infrastructure with a new inefficient infrastructure. There are many examples of transitions which go ahead and transfer applications that are no longer used to the cloud.

3. What are the barriers?

Whenever you try to create order from chaos you will face barriers. There appears to be an inbuilt inertia and opposition to change. This is exactly so with application rationalisation. If you do not have a plan to anticipate and deal with these barrier,s then at best you will have only a partial success and waste your time and resources without delivering the benefits you are expecting.

In many cases users will not want to give up applications. Department heads and their workers will resist the changes because they are used to older applications and are comfortable with them. You may need to prove that people are not using applications even when they say they are. In other cases you may have to prove the applications can be replaced without reducing the workers effectiveness. An approach which relies heavily on questionnaires and feedback from users will never deliver full efficiency, you need concrete facts to base your rationalisation program on.

Getting factual evidence can be difficult. A recent conversation with a major organisation revealed they did not know how many PCs or servers they had, what operating systems were running on them, what applications they were running and who used them – the person in the conversation had the title of Chief Information Officer. Most organisations will have problems creating a full and accurate list of their applications, how many are installed, how many they are entitled to use and how many of the licensed copies are actually being used on a regular basis. Unless you can create an accurate view of this information then you don’t even know where you are starting from, never mind where you want to get to.

Another barrier to practical application rationalisation is the amount of high level strategy or “consultant speak” that surrounds the whole area. A search on the internet will reveal a number of strategy documents and articles that are excellent in explaining why you should rationalise and the theoretical benefits but there is relatively little substance in how you can do the practical implementation. What is really needed are guidance on the key steps to complete a rationalisation project.

The final aspect to consider is the amount of time and resources such a project will require. Do you have the skills never mind the time to do the work and more importantly where do you start and how can you prioritise the workload.

4. How can you implement application rationalisation?

When you start on application rationalisation bear in mind three key guidelines:

  • You are closing a gap or variance between where you are now and where you want to be. To do this you will need to know where you are now, where you want to get to and how you are going to get there.
  • There are facts and there are opinions. When it comes to making decisions an accurate measurement is worth a thousand opinions, so take into account what people tell you about application requirements, but validate this with factual data.
  • You need to prioritise to workload and separate software applications for rationalisation into the “vital few” and the “insignificant many”. To do this you will follow a logical process to come up with the list of prime applications for rationalisation. As with most projects of this type you will find that 80% of the savings will come from 20% of the applications. The following diagram shows a matrix of 4 different types of applications.

The applications that have low percentage usage levels of licenses and high costs are prime candidates for significant cost reduction, whereas those with low costs and low usage levels can be tolerated and allowed to continue as they do not drain many resources. The applications that have high percentage usage of licenses and a high cost per license are those that should be examined for replacement but often they will be maintained. Any application that has high percentage of usage of licenses and a low cost per license can be expanded without any concern.

To arrive at a matrix and rationalise the applications, you need a rational process to ensure you do not waste time on unnecessary tasks. To start you will need to find out your current state as follows:

  • What software have you deployed and to what devices? You need an accurate count and the locations of the installs for each software application along with version and supplier details. Even if you have a reasonable inventory of applications and their host devices it is worth running a check with a third party tool to establish the accuracy of your existing records. There are tools available for agentless scanning of your infrastructure, finding devices, what operating systems are being run and what software is installed on each device. This can be a quick task and without this inventory you will be unable to see who has what software for rationalisation.
  • How many licenses have you paid for or are paying for and at what costs? Many organisations do not have all their software contracts in one place, some may even be missing. You need to know the cost of your licenses, how many you have purchased, the ongoing support and maintenance charges plus any terms and conditions and especially the date when your next renewal is due. If you don’t have this then it is more often than not a manual task of finding the contracts, going through purchase records or even requesting copies from vendors. The later action sometimes can result in a vendor being alerted to you not having your records under control and they may even request a license assessment to check that you are compliant with the terms and license quantities in the agreement.
  • How many of the licenses are actually being used? You may have been deployed the same number of licenses as you purchased but are they actually used? In most organisations there will have been changes to staff, mergers and acquisitions, downsizing, or even “gold-disk” type deployments of software that most people do not use. In server applications there may be facilities or software that has not been used or discontinued but still annual updates and support payments are being made. Remember you want to pay for what you need in terms of active usage rather than what has historically been deployed.
  • Once you have these three sets of data, deployments, license entitlements and actual usage levels you can establish your key variances or opportunities for rationalisation. The following diagram shows why this is such an important stage.

The gap between what you need and what you are paying for is your enemy. Your main task is to prioritise these variances and eradicate them. It does not matter if you have deployed the same number of licenses as you have purchased, if you are continuing to pay for them but not using them, then they represent a cost saving. The larger the potential cost saving the more effort you should use to eradicate the variance for that application. To gather usage information you will need to run some form of usage metering. This can vary from a simple interrogation of the last used dates to a more automated and in depth usage metering tool which gives you length of times that users access an application and compares these usage levels to the licensed quantities.

5. Prioritising Applications for Rationalisation

In principle this stage is easy because you need to rank the applications according to the size of the benefit you can realise from their rationalisation. However this may be a manual process and can take some time to achieve.

At this stage of the process for each software application, you will need to multiply the cost per license (or ongoing cost) by the unused variance as described above, e.g. 1,000 unused licenses at £1 each give a costed variance of £1,000 whereas 100 unused licenses at £100 gives a costed variance of £100,000. Clearly the 100 unused expensive licenses are more interesting than the cheaper 1,000 licenses.

When you have created costed variances for your applications you will end up with a graph similar to the one below

It is obvious from this graph which applications will deliver the best cost saving opportunities. These are the ones with the tall blue cost columns and are your “vital few”. You also have a number of red negative columns which show you do not have enough licenses for what you are using, these are also important because you do not want to be non-compliant with your supplier agreements. The applications in the middle with little opportunity for cost saving can be left for a while as these are part of your “insignificant many”.

6. Validation of the Vital View and the need for Qualitative research

By now you have your list of vital few applications for rationalisation however you cannot just start eradicating applications without doing research into user requirements and other key factors.

With reference to your vital few list ask the users about their usage of these applications, key information to find out:

  • Are the software products really being used? If not you can get rid of them. In some cases the users will claim to use them intensively but you already have the quantitive data to show users the real situation.
  • What is the business impact of getting rid of these applications? If they are not essentials then again you can replace or eradicate them.
  • If they are essential are the users prepared to use an alternative that can be sourced at a lower cost? If so replace the application.
  • If the application cannot be replaced what better deal is available from the software publisher? You have already seen you have excess licenses so you need to seek more cost efficient alternative options from the software supplier.

User input is key for effective application rationalisation. You do not want to adversely affect business process productivity by preventing people from doing their daily work. However you have ranked the vital few applications and you have validated the user requirements so you can start on managing the rationalisation.

There is another key factor in prioritising which applications you will rationalise. This is when the supplier contracts are due for renewal. If you have just sign an agreement for another three years there is not much point in spending much time on this, however the agreement that is due to be renewed in six month time is a prime candidate for rationalisation.

7. Tracking your success with R.O.I.

The process of application rationalisation is only worthwhile doing if you produce a return on investment. Validating your ROI is important to prove your success, but it does have a number of problems.

Most SAM practitioners will point out the difficulties of measuring SAM ROI because effective SAM delivers efficiency benefits in some ways that are not easy to quantify. However, it is possible to implement ROI measure if you have this as a key deliverable to assess your SAM program.

The primary cost efficiencies can be split into the following three groups:

  • Reducing IT costs. Examples of these savings can be the reduction of the number of licenses paid for in a contract renewal or “re-harvesting” of unused licenses and reallocating them to users who need them, thereby avoiding the need to purchase additional licenses. These types of savings can be measured and quantified but may take a considerable amount of manual tracking.
  • Cost efficiencies from improved services. An example of this can be improved service from a helpdesk because they have better information about the assets used by users. Another case could be the identification and retraining of users who have a new system to work with, but they have had difficulties coming to terms with it. In these cases it is harder to make an assessment of the value that a SAM program delivers in accurate financial numbers.
  • Risk reduction. There are risks if IT assets are unknown. These can be penalties for being outside of license agreements or even security breaches where IT assets and software access fall into the wrong hands. Risk assessments should be part of any SAM project but it would not be appropriate to count these as savings unless a specific cost saving can be identified and quantified.

In addition to the cost benefits you will also need to identify the investment costs. These are much easier to calculate than the cost savings. Key components are:

  • Staff costs. These include staff direct working on the project with all the additional costs and benefits such as pensions, tax, sick days and admin costs. Also you will need to add in a proportion of the cost for other workers who contribute towards the project.
  • Cost of outside services, outsourcing and contract staff.
  • SAM tools or other technology used to make assessments required by the SAM project.
8. Summary

Application rationalisation is not a revolution it is evolution. It won’t be an overnight task but instead one that become a process of continuous improvement. You start by knowing where you are now, identify your vital few opportunities and then validate them to create your action plan for the priority of rationalisation. Key things to remember are:

  • Make sure you have accurate data for deployments, license entitlements and most importantly what you actually need based on real usage.
  • Prioritise your applications with costed variances which show the value of your unused applications.
  • Validate with users the impact of eliminating or replacing the applications.
  • Measure your success and track ROI to show the value that you are delivering back to your organisation.
  • Start now, don’t put this task off as you are wasting money every day.

About the Author

Phil Hames is the Director of The Business Software Centre Limited.