A few years back I was doing an invoicing automation for a client. They wanted their customers to automatically get emailed a computer generated invoice when the customer placed an order on their website. This client did a lot of drop shipping.
Judy, a member of the client's staff, was telling me what information needed to be included in the generated invoices. She explained that for drop shipped orders, the invoice needed to include a four digit code that corresponded to the product vendor or vendors. For the invoices that they had been manually creating, if a customer ordered 6 products that were dropped shipped from different vendors, the invoice would have a string of 24 numbers (4 digits X 6 vendors) in the comment section indicating which vendors were associated with that order.
Knowing a little bit about the client's business operations, it struck me as odd that these codes had to be on the invoice, which was basically a customer-facing document. When I asked Judy about it she replied "I don't know what we use them for, the person that trained me just said we needed them on the invoice." This revelation led to several more questions.
"If she needed to know the vendors for a particular order, did she pull up the invoice to get that information?" Judy said no. She would pull up the order information in their Point-Of-Sale (POS) software to get that. Judy explained that once an invoice is sent to a customer she really never looks at it again except to acknowledge if it has been paid or not.
I inquired around around the office to figure out if any other system they use required these vendor codes to be on the customer invoice.
It turned out that they stopped needing these codes about 4 years ago, but the staff was faithfully and robotically reproducing them on every invoice anyway. Apparently back in the day their POS software could not realistically handle products that were drop shipped, and this vendor code on the invoices was (at the time) a workaround.
The problem with workarounds is that after a while they can become routine habits.
This is of course a trivial example. Who cares whether or not there are some extra numbers on the bottom of an invoice? The numbers on the invoice may be trivial, but the larger issue is very important.
A process such as creating a customer invoice can be seen as a series of steps taken. Had I not intervened with some basic examination and evaluation, the client would have spent time and money to automate a step in the invoicing process that simply did not need to exist.
Having steps that aren't necessary is bad enough. Now imagine a step that actually adds to the overall inefficiency or workload. An example would be a step that generates paperwork for an employee to review or process. It is possible that there is a better way to handle this paperwork or that review the paperwork is only of marginal value. But by automating the steps before you have evaluated them in the context of the overall process, you have now automated and scaled that inefficiency -- you now reliably and consistently have more paperwork for your staff to review.
Another example of a step that could create inefficiencies is one that handles data in a manner that is confusing or unreliable. Lets say that every once in a while your system screws up and transposes the customers mailing and shipping addresses. Your staff spends a few hours each week on finding and fixing these messed up orders. In that case you should fix the bug in your order system before you automate invoice creation. Otherwise any efficiency gained by automation will be cancelled out by the increased labor spent fixing your incorrect orders. What used to be an occasional hiccup has now been baked into the system. Once you add in the expense of your software developer, you are actually losing money on your investment in automation now.
All of which brings me to the first rule of automation.
We will walk through these concepts using the earlier example of generating a customer invoice.
Discover:
Write down, in detail, each and every step you take to create a customer invoice manually. You get bonus points if you also write down how long each step takes, on average, to perform.
Evaluate:
Look at each of the steps identified in the discovery phase and ask the following:
Be sure to also consider the overall process. Sometimes by making a few minor changes to your process (by switching to a different software product for example) you might be able to eliminate or improve several steps at once.
Automate:
Now after having done the discovery and evaluation phases you can finally begin working on creating the automation.
It can be useful to have a tech savy business consultant to help guide the discovery and evaluation phases of this journey. But it should be noted that nothing in the discovery or evaluation phases requires knowing how to write code. Often by this point you may have found several ways to optimize your processes without ever having spent a dime on hiring a developer.
After having already optimized what you can yourself, spending money on custom coded software solutions is now more likely to be a worthwhile endeavour.
The sad truth is that a great many developers would be happy to take your money and automate whatever you ask them to and they won't spend any brain cells wondering if it makes sense to automate that particular process a certain way or if their code will actually improve your business or not. If you end up with a developer like that then the time you spend on discovery and evaluation will be time well spent. The information gleamed from the discovery and evaluation phases will be like a roadmap for both you and your developer, helping to guide you on your automation journey.