This is a statement I frequently relay on my calls, and oftentimes I can feel the lingering distrust and skepticism. The statement is often discarded, and sometimes the tone even shifts as if to implicitly say, “you’re not the first sales guy we’ve ever met”. Sometimes the response isn’t implicit at all…
And I get it – it’s a bold claim.
This article is my best attempt to prove that our claim is not only possible, but probable.
In the realm of Automation, no scenario is off limits. That being said if this article was lacking specifics, I’d really be missing the mark.
Today’s chosen scenario is both accessible, and universal: Accounts Payable (AP). We’ve all got bills to pay, am I right?
In our current state process, the vendors send their invoices to a group inbox. This group inbox is monitored by a team of AP Clerks who then enter it into the system. Once entered, an Accounts Payable Manager must review the invoice against the Purchase Order (if one exists). Once the invoice is approved, the Accounting team then releases the funds to the vendor.
Anyone familiar with AP can probably identify several problems, or at least improvement areas, in this diagram. The biggest problem with … problems… is that it take time to resolve.
This process seems simple enough but, as is usually the case with business processes, the devil is in the details. Here is an abbreviated list of problems with our current state model:
Since all the AP clerks are working out of one group inbox, they are frequently stepping on each other’s toes, or worse – missing invoices completely.
The human condition prevents AP clerks from entering the invoices perfectly every time. This degrades the data quality and can have more profound impacts on the process (especially in situations where amounts are entered incorrectly).
The managers are not able to review the invoices in a timely manner. Keep in mind that one’s involvement in a process is only a subset of their overall job description.
There are some higher-level problems as well. For instance, if our payments are not made on time, we may incur late fees. And if this keeps happening we may gain a reputation for not paying on time, resulting in vendors not wanting to work with us.
Let’s also consider what this process (problems and all) costs us to run.
Our current state has seven steps, but only five that are performed by us. Since the “Send Invoice” and “Provide More Info” steps are both performed externally by the vendor (i.e. not us), we can exclude them from consideration. No need to worry about things we cannot change.
For the sake of calculations, let’s give each of the remaining steps an average work time. To be fair, most of the activities happen fairly quickly, with the exception of “Dispute Invoice” – which can take clerks hours to resolve (finding the right vendor contact, playing lengthy games of phone tag, putting people on hold to check on things, being put on hold while people check on things, etc…)
Work Time (in minutes)
|Match Invoice to Purchase Order||10|
In order to provide numbers that are as authentic as possible, I’ve taken the average salaries for AP Clerks, AP Managers and Accounting Clerks from Glassdoor in order to calculate what each instance of this process is costing us:
|Activity||Work Time (in minutes)||Participant||Cost (per instance)|
|Enter Invoice||10||AP Clerk||$3.46|
|Match Invoice to Purchase Order||10||AP Clerk||$3.46|
|Review Invoice||10||AP Manager||$5.71|
|Dispute Invoice||60||AP Clerk||$20.75|
Since the process has two outcomes – the payment being released, or the invoice being disputed – we can comfortably say that the process costs us somewhere between $17.29 and $33.37 for every single invoice.
Now let’s assume that we have 1,000 incoming invoices per month – 70% are paid out and the remaining 30% are disputed. That means the process is costing us $265,363.75 per year.
It is also costing our workers a lot of headaches. After all, data entry is not exactly soul-enriching work… nor is being put on hold.
So how does Automation provide relief, not only for our workers, but for our bottom line? How can we solve these problems while also lowering our operational costs?
First, we can use a workflow application to systematically pull the emails out of the inbox and put them into the formal constructs of a process flow. This will eliminate the issue of clerks not knowing which invoices have been transferred and which have not. It will also give us insight into where each invoice is in the process at any particular moment.
Second, we can use our capture solution to extract the data from the attached images. In addition to eliminating the “swivel chair activity, this will also increase our data integrity issue as systems are much less likely to type something incorrectly than their error-prone human counterparts.
Third, we can lean on a rules engine to auto-approve invoices in certain circumstances. We may still need AP Managers to review invoices sometimes, but the rules engine can be the first line of defense – reducing the noise for management, and in many cases bypassing the step that was previously a bottleneck.
Since “Dispute Invoice” is such a costly activity, perhaps we can even handle it with an automated email to the vendor letting them know the invoice was rejected. Something like this:
The attached invoice ####### was rejected for x reason. If you believe you are receiving this in error, please reach out to us at ###-###-####. Until then, we’ll keep our money. Thanks.
Albeit a little “on the nose”, an automated email might prove sufficient in some instances (more than expected, perhaps). In other instances, the “Dispute Invoice” activity might still need to be performed. Worst case, it will spare your worker’s ears a little elevator music.
Factoring in these changes results in a future state process which looks like this:
We’ll make two final assumptions that (1) the “Auto-Approve Invoice” works 50% of the time and (2) the “Send Rejection Email” works 40% of the time.
This future state process, with IBM Automation, now costs us $103,311.19 per year to operate. Compared to the $265,363.75 in the current state, these are big savings. Less than half the cost.
This was a pretty straightforward application of our technology (i.e. not a “stretch”), and we were able to see a 61% reduction in the operating costs associated with this process – from $265K to $103K annually.
We didn’t even talk about other value-adds that are equally compelling, but less quantifiable:
We also didn’t consider indirect costs:
Lastly, this is only a single process. Our tools are meant to handle processes of all shapes and sizes, in harmony. So, while we were able to save $162K here, we may be able to automate another process down the road and realize another $100-200K in annual savings, and so on, and so on… without incurring any additional software costs.
Speaking of software costs –
While there are too many factors to provide an earnest figure, I can say with confidence that, given today’s scenario, a positive return on investment in year one is possible – taking both software and services into account.
IBM Automation pays for itself. A claim that is not only highly possible, but highly probable.