Share: |


In my last post, I talked about the need for our customers to develop a “Center of Excellence”. There are two good reasons to do this:

 

  • Develop standards that assist in enabling the broader organization, and
  • Identify value-add projects with solid ROI that can be measured & marketed to those who cut the checks

 

 

 

You really can’t be successful with any implementation unless you do both…But if I had to choose, I’d go with ROI measurement over standards. It’s simple really – if I’m cutting the checks and I can’t see what I’m getting, I’m inevitably going to ask to see that value - or cut the program all together. Better to be prepared up-front so you never have to get into that situation.

 

 

 

If you’ve avoided the first pitfall and you’ve invested in ROI measurement from the outset, do yourself a huge favor: don’t over-engineer it. There can be a thousand different ways to measure ROI, but in reality your management only needs you to be directionally accurate, likely within +/- 10%. Presented below are some key dos and don’ts for the most common ROI measurements of any automation system – labor cost & time reduction

Blogging_for_Dummies.jpg

 

 

 

 

DODO NOT
  • Survey those living the day-to-day job to get a solid understanding of the time involved to execute a given use case.
  • Include aspects of the end to end process where automation will have no bearing. For example, in a provisioning process, there is a large chunk of time spent in procurement. It is likely that your procurement process is not the first thing you are going to automate with your automation tools, so it doesn’t make sense to include it in the measurement.
  • Use the POC process and early tests to determine what the average savings (in minutes or hours) will be each time the use case is run. Convert that savings to $$$’s by looking at fully-loaded costs of your administrators.
  • Attempt to dissect actual job run times or workflow start/end times to determine savings. The reality is that the time it takes for automation routines to run has little bearing on the actual savings. If you’re using automation, you’re likely off doing other things while the job is running – or better yet, you’ve got it scheduled.
  • Identify the key marker for when a given use case has been run. This could be a workflow that executes, a job that is run in the system, an email that the automation system sends – really anything that tells you that the use case was run and is completed. It’s pretty simple to get an operational report that will tell you how many times something was run. From there it’s simple math:

 

 

 

# Use Cases Executed * Average Savings = $$$ & Time Saved

  • Roll-up your ROI metrics by use case and in terms that your management understands. Those terms are:
    • $$$ Saved
    • Headcount Reduced
    • Reduction in Time to Market
    • Velocity/Efficiency Increased
  • Attempt to showcase raw automation data as a substitute for ROI. Data points such as “# of Successful Job Runs”, “% Compliant”, and “Average Run Time” are important metrics for the operators of the system, but don’t tell the check-writers a single thing about the value of the solution they purchased.

 

 

 

 

In general, automation solutions are great tools for the day-to-day operators, but they have a long way to go to spit out the kinds of ROI measurements and management reports discussed above. Until that time comes – and it is most definitely coming – use these tips to simplify the way you look at ROI and report up to your management. It will save you time and put your project in the good graces of those cutting the checks – and that’s exactly where you want to be!