# Estimating the Cost Savings of an Application Integration

I was educated as a physicist, so not surprisingly, I’m a numbers guy. Recently I’ve been thinking about the cost savings of doing application integrations, and in particular, how to come up with a decent way to estimate these cost savings in order to justify doing an integration project. In this article, I’ll take you through a thought process that you can follow to arrive at a reasonable estimate.

The first thing to think about are the task(s) being replaced by the integration. Generally there’s a good reason already in the mind of a business stakeholder for starting an integration project, and usually it has to do with eliminating time-consuming data entry processes, or replacing an old, inaccurate existing integration.

For the purpose of this article, have a manual task in your mind; for example, a person copying invoices from an operational tracking system to an accounting system. I’m going to outline the factors involved in creating the cost estimation and then finish up with the “stand back, I’m going to do math” part. The overall goal is to come up with an annual estimated savings of doing an integration vs. continuing with the existing process.

## Annual Salary

A task like copying an invoice between systems manually may be done by a business owner (if it’s a small business), an accountant, or clerical staff. So the first thing to acknowledge is that not everyone’s time is worth exactly the same amount to the business, and is dependent on how much that person is compensated. The salary of the person doing the task will be represented by variable, $A$ in our estimation process.

## Fraction of Time Savings

The fraction (or percentage, if you like) of time saved $f_t$ is another key variable in estimating the cost savings. Generally business stakeholders have a pretty good sense of the time that doing a single task takes. Therefore, estimating this fraction may be more easily computed by multiplying the hours per task, $T_h$, by the number of times the task was performed in a week, $n_w$ to get the total number of hours per week $T_w$.

$T_w = T_h * n_w$

I’m assuming a 40 hour work week but that may vary based on the person performing the task. With my 40 hour work week assumption, the fraction of time saved by replacing the task is simply divided by 40 hours per week.

$f_t=\frac{T_w}{40}$

## First Approximation

Back in my science days, a formula that was “pretty good” but perhaps didn’t take into account all variables and situations is called a “first approximation”. Remember, we’re estimating here, not calculating rocket launch trajectories - so, this is a good time to try out a first-approximation estimate. Here’s the formula, and it’s simple. Annual savings is equal to annual salary multiplied by the fractional time on task.

$S=A&space;*&space;f_t$

Now let’s try it out. Suppose an employee making $35,000/year is copying 15 invoices a week over manually. Suppose, for each invoice copied, it takes about 5 minutes to read the invoice details out of one system, log in to the other system, and manually enter invoice in the other system. Start by calculating hours per week spent on the task: $T_w&space;=&space;T_h&space;*&space;n_w$ $T_w&space;=&space;\frac{5\;minutes}{60\;minutes/hour}&space;*&space;15\;times/week$ $T_w&space;=&space;1.25\;hours/week$ Now calculate the fraction of a regular work week this takes up. $f_t=\frac{T_w}{40}$ $f_t=\frac{1.25}{40}$ $f_t=0.03125$ Finally, compute the annual savings. $S=A&space;*&space;f_t$ $S=\35000&space;*&space;0.03125$ $S=\1093.75$ So the first approximation estimate is an annual savings of almost$1100 for this scenario, assuming the task time can be eliminated.

Here is an itDuzzit widget that calculates the cost savings using the above approach.

For an better estimate, there are some other factors you may wish to consider, summarized as follows:

### Efficiency Savings

This another time-based savings that can be calculated in the same manner as S, associated with clerical errors, typos, or time spent troubleshooting the existing process. The number of occurrences of this troubleshooting may not be constant (i.e. not weekly, so it might be hard to come up with a weekly estimate.  Try a monthly or annual estimate instead.  You should also take into account that the person doing the troubleshooting may NOT be the same person doing the original task. In fact, it might involve more than ONE person.  This term can also be used to capture implicit costs from task-switching or “context-switching”.  An increasing body of evidence suggests that having employees jump between multiple tasks harms productivity, and there are significant time costs associated with this.

### Saved Opportunity Cost

Go back to economics class for this one.  If the person performing the task can move to a differnt task that results in one or more additional sales for the company, for example - you could allocate that amount here. Surprisingly, this can be the entire justification for doing an application integration. For example, if you need an integration to do something vital to the business, the opportunity cost of NOT doing that can be large.

### Ongoing Integration Cost

Supporting an integration is not free. First, there are the direct costs with keeping the integration running. If you are using an application integration platform like itDuzzit, these costs can be quite low - typically less than \$1000 /year.  If, however, you hire your own development staff, the ongoing integration costs might be very high. Hiring a developer and keeping that developer on staff is a six-figure prospect these days. Hopefully you are only using a fraction of that person’s time to support the integration!

## Second Approximation

So, in view of these additional variables, I have now have a second-approximation:

$S&space;=&space;A*f_t&space;+&space;S_e&space;+&space;S_o&space;-&space;C_i$

where...

$Efficiency\;Savings&space;=&space;S_e$
$Saved\;Opportunity\;Cost&space;=&space;S_o$
$Ongoing\;Integration\;Cost&space;=&space;C_i$

Use  these additional terms as they apply. Remember the idea of this exercise is to build business justification for doing an integration. There are other ways to come up with estimates, of course. If you’re nervous about guessing wrong, I like to remind people about a technique called a Fermi estimate.  This technique uses an approach like the above, but assumes that someone who is reasonably familiar with a complex system (such as a business) can actually  make fairly accurate estimates, even about complex problems, because the number of “high guesses” tends to balance the number of “low guesses”.

The important thing is to follow a thought process that makes you to think about the ways an integration will affect your business so you can make a solid and confident decision.