Can buying software save money?

Last updated on February 25th 2011 by Simon Barnes

I’m not sure if it is the recession or just a coincidence but over the last year I’ve been asked a number of times to help write Return on Investment (ROI) Studies or Business Cases to try and justify software purchases.  It seems that in the current economic climate a software purchase of any size must save money before the purchase is agreed.

Can buying software really save money? Well of course a lot of software is bought just because it is desirable. For instance I recently paid for an application to display Orb Data’s Message Broker magazine purely because of its aesthetic value and I’m sure nobody has to write an ROI study for a Computer game. However where software is bought on the premise to save money (as a lot of Enterprise Systems Management software is) it is not unreasonable to write a ROI document or a business case to justify the purchase and with a little bit of thought it is not as difficult as you probably think.

So let’s start with a few general questions that you will need to answer when you start looking for economic value when purchasing software:

  • What is the impact on revenue of the software purchase or implementation, if any?
  • What is the impact on costs?
  • If efficiency is a factor, will the headcount actually be reduced?
  • Are there any one-time savings of cash or reductions in capital needs?
  • Is the benefit realised one time or on a recurring basis?

Sometimes these questions can be easier to answer than in other cases. For example IBM’s recent purchase of the BigFix patch management solution (now renamed Tivoli Endpoint Manager) offers a fantastic Return on Investment. In this case the cost variations in a patch solution are caused by the amount of automation that can be achieved.  For example a typical patch management process would look something like this:

  1.  Monitor and research software vendor patch sources
  2.  Package Patches
  3. Test the packages
  4. Analyse Environment for Missing or Compatible Patches
  5. Deploy the Patch
  6. Confirm Success or Failure
  7. Report    

With the BigFix solution over 75% of this process is automated leaving the customer to simply deploy the packages (step 5). In the business case for this solution the current time spent on steps 1,2,3,4,6  and 7 would need to be quantified and a value associated with each stage. To do this you will need to identify the fully burdened cost of a Full Time Employee (FTE) for each type of affected member of staff. This figure is likely to be higher than you expect as things like office space, employer tax, pension payments etc all need to be taken into account to get the true cost. For example the current range of values for companies we have analysed are between £320 to £450 per day. You will also need to know how many hours a day an employee at your company is expected to work – if it is 7 then divide this by 7 to get the hourly cost per employee. Once you have this value the number of hours spent performing this task can be multiplied by the hourly charge and a yearly saving calculated. As difficult as it may be you will also need to accept that these sort of savings means that headcount can be reduced and this should be documented as part of the Business case (and carried out when the product is bought and deployed).

If you are a Tivoli Configuration Manager (TCM) customer the savings can be even bigger. Not only does BigFix automate the packaging and analysis of patches but due to its lightweight relay architecture the existing TCM gateways (used to fan out a deployment) can be removed and existing distributed systems used in their place.  If you take a customer that has a 100 gateway environment, even by conservative estimates (using a maintenance/power charge for a system of about £3000) this saving is over £300,000 a year. Customers should also remember that if they are a current TCM user you have a right to use the BigFix patching software without any further payment.

Another common scenario recently has been customers looking to upgrade from TEC to OMNIbus. Essentially the issue is that a customer who uses TEC will find it difficult to justify both the software and implementation costs of moving to a product that offers very similar functionality.   I have been asked this question so many times that I added an hour specifically on writing the business case for this migration into our workshop “TEC to OMNIbus: Why Upgrade?”. In it I not only discuss the reasons why OMNIbus is better than other products but more importantly how money can be saved concentrating on these 4 main aspects:

  1. Reduce Capital Expenditure – Reduce Hardware costs, simplify the architecture and alleviate future TEC hardware purchases and storm failures
  2. Improve Operational Expenditure – Utilise normalisation, de-duplication, aggregation, correlation capabilities, as well as time, device, and service based event reductions.
  3. Maximise Service Availability – Leverage hundreds of out-of-the-box integrations, with included domain intelligent event reduction rules, to monitor end-to-end infrastructure status and health.
  4. Resiliency and Maintenance – Leverage proven availability and reliability, with trusted system redundancy, failover and security.

Something I suggest in the workshop is to use examples of where it has been done before and how it was achieved. Depositing a business case on an already sceptical CFO’s desk and asking for money based on wildly optimistic values is more likely to be rejected if no proof is offered. In this course I used the following key points from a real customer example:

  • ·         Increased level of automation  – 60% time saved due to increased number of events managed by Tivoli Netcool via automatic check with external data-sources
  • ·         Increased throughput of monitoring process – Time to Acknowledge alarms has been reduced due to the re-use of resources previously used for managing “simple” alarms
  • ·         Reduced time to dispatch Trouble Tickets  – Time to open tickets has been reduced due to availability of additional information (inventory and field work force) on alarms
  • ·         Centralises / Consolidated monitoring process  – Single operations console (instead of 8): optimisation and consolidation of existing monitoring processes

And all this resulted in a 34% time saving in the Alarm Monitoring process reducing the FTE need in central NOC.

Lastly something I am working on at the moment is Orb Data’s Managed Service and Remote Support offering ( For both of these I have been writing Return On Investment Calculators . Of the 2 tasks the Remote Support component is far easier to quantify than the Managed Service. This is because the Remote Support option is based on a Template we have designed to run a textbook Tivoli Monitoring solution. In this scenario I know how long a task will take and how many people it takes to run a certain size environment. We also take into account that a company will have to train at least 2 people to fully cover the support they will need to run a service and these employees will generally have second or third roles. We can reduce these costs by using economies of scale and by deploying staff who are experts and only concentrate on Tivoli software.

The second part is of this is the ROI for the actual monitoring software. This is by far the most difficult task; not because the software offers no value but because each customer will have different criteria. For example a Web retailer will have a monetary value for a minute (or even a second) of downtime and another financial value for transaction slowdown. For example tests at Amazon revealed every 100 ms increase in load time of decreased sales by 1%. But how do these values relate to a transport or construction company? The value of IT to these companies is every bit as important as it is to the Web retailer but the criteria are different and this is what makes writing a generic business very difficult. However I think there are some generic questions you can ask though:

  1. What are your key services?
  2. What are the key components of those services?
  3. What happens if each or any of those components fail?
  4. Who is affected when each component fails? Customers, external users, internal users, support staff?
  5. What is the impact for each of the affected group of people and what cost is associated with the failure or slowdown?
  1. And finally if you already use a product (whether in house written, freeware, or even somebody performing manual checking) then what is the cost of maintaining and performing this service?

With these questions answered you should be able to start calculating the economic value you can get from buying a Cloud service like or buying a product and installing it yourself.

Views: 18