After spending time with a few old friends at the Avidxchange User Conference this week, I learned two things. I frist learned that you are never too far along in your automation walk to improve. Whatever processes you have in place and whatever steps you have taken to get rid of manual effort, there are always an areas that has been neglected or left for later. I wrote in The 8 Pitfalls of Accounts Payable Automation that automation is not an event but a process. This notion was reinforced in a big way when I met with people who I have been working with for as much as eight years and they are still changing and updating. If people approach automation as a “project” or an event, they will underestimate the amount of time and effort it will take to do automation correctly. Don’t get me wrong, for the last few weeks I have been writing about automation being only as good as the time and effort that it frees up, but there is still an amount of time that is needed to administer the software and process.
Here is a section from The Argument to Automate about system administration:
Sometimes overlooked but never underappreciated is the work that needs to be done when a new piece of software is introduced. The new piece of software I am referring to is the software that will drive your automation project. This section takes a person whose time is freed up by automation and gives him/her a new duty of being the system administrator for the new automation software. This is such a prevalent use of new time that I have thought about adding it as a fact in the new time calculation. For example, if your organization is able to free up 12,000 hours annually, 10,500 are transferable hours to new tasks or opportunities and 1,500 will need to be used to administer the new automation system. This is one of those points where my bias is going to start to show. When selecting a service provider, besides selecting one that has a very powerful hard cost impact, I firmly believe that you should select a service provider whose software is un-IT. Yes, here I go again with making up works. Un-IT means that you do not need programming or development skills to administer the software. If the software is user-friendly enough and configurable, which means a person is able to use the software through a user interface and pointing and clicking, the person who administers the software will need to be someone who has intimate knowledge of the process, not hardware or software skills. After all, the software’s intent is to improve the process, not require you to have someone on the accounting staff that knows SQL or Java.
Oh… the second thing I learned at the AvidXchange User Conference was some people are too old to stay out late and drink 😉
Buy the book – The Argument to Automate – How Innovation Can INSPIRE Not Fire – click here to buy
(Also) To get your copy of The 8 Pitfalls of Accounts Payable Automation – click here to buy