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 barriers, 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.

(Continue)

Request the full white paper at here.