You run a business office in a large enterprise, and you have finally had it up to here with paper forms, fillable PDFs, emailed spreadsheets, and scanned attachments sludging across your desk and through your inbox, haphazardly collecting signatures, before being painstakingly pecked a key at a time into your business system. You’re done with two-week lag times to get something in the system, done with “do you have my form yet?” voicemails, done with re-keying data, done with bulging filing cabinets.
It’s time to finally automate your business processes! Time for workflow, time for eForms, time for electronic signatures, time for scripts that do all the data entry! It’s finally time… to fail!
Now, automating your high-volume business processes is definitely a good idea. Computers have been doing repetitive tasks faster than humans for a long time now, and your humans have more meaningful things they could be doing. Automation is undeniably the right thing to do, but there are so many wrong ways to do it! Let’s explore four ways to blow your business process automation project.
#1 – Be Ambitious
You’ve finally got funding, available business and IT resources, and a lull in the upgrade calendar. You have eleven high-volume paper processes, and their transaction loads ride your poor staff like a sumo wrestler rides a goat. This is your moment – automate them all in one fell project!
That should read, “one fail project.” Who is going to be providing the subject-matter expertise to the automation project? Your staff. Who is going to review and sign off on the design, perform system tests, and train users on the new system? Your staff. And who is still trying to hold up under the paper avalanche of your legacy processes while the automation project cranks along interminably? Still the same staff.
Certainly you want to automate all eleven processes, just not all at once. Get a few processes done and in production fast, and free up some staff time so the next project phase doesn’t take as much overtime.
The biggest cost of an automation project is not having it live yet. If automating the first three processes is going to save you $60,000 per month, every month you delay going live with them while you work on the others costs you $60,000. Additional go-lives do add project cost, but that cost can be more than offset by the benefit of being live sooner.
#2 – Automate Every Transaction
Now you’ve nimbly dodged the first pothole by only selecting three of your eleven processes for the first project phase. You’re excited to free your staff from the toil of manually handling all those transactions, especially the thorny occasional exceptions your people really hate because they take five times longer to handle than the rest. Pothole number two, dead ahead.
I’ve seen an automation project double in length, just trying to automate the last 5% of the transaction load. Once you get past the bulk of the transactions that are all pretty straightforward and start trying to automate exceptions that only happen periodically, as shown in the illustration, the complexity of the solution starts to increase exponentially.
Not only can the project go long trying to automate complex exceptions, you can end up complicating the simple transactions and adding more long-term maintenance overhead.
Do the easier stuff, and go live with it. The exceptions can either wait for another project phase, or they may just be the stuff best suited for humans to handle.
#3 – Do it Right the First Time
Now that the stars have finally aligned and you are doing your automation project, you don’t want to do it half-baked, do you? You may never get the chance again to add the extra features, the clever edits, the gravy integrations, the superfluous notifications, the gold-plated cupholder. Go big or go home, right?
As a business process automation consultancy, we have worked with several clients who have insisted we build complex edits, checks, and features to handle every exigency. Our team has reviewed some of these systems in production use and found that as much as half of the code we wrote is never fired. The business user community migrated quickly toward what worked best and fastest and ended up never needing the nanny edits and shiny toys that cost so much project time and dollars.
In most cases, even a simple automated process will be much more effective than the manual process it replaces. One client sponsor, toward the end of a project much prolonged by demands for a few more features before go-live, said, “We’re replacing a piece of paper. How many features does it take to beat a piece of paper?” Yet their organization kept using that piece of paper months longer, trying to agree on a few more bells and whistles for the automated process.
Build a simple process that is better than the one you’re replacing, and go live with it. Plan an immediate post-go-live analysis of how the system is used, followed by a scheduled update phase to implement the lessons learned. You won’t know for sure what edits and features are really needed until you see how the simple system gets used in real life. And as discussed in #1 above, the sooner your project goes live, the sooner it starts paying for itself.
#4 – Insist on 100% Stakeholder Buy-In
You’ve been fielding complaints for years from the various stakeholder roles and divisions you service about these clunky business processes. Every division and interest group in the enterprise forever wants you to cater to its specific procedures and eccentricities. This is your chance to finally make everyone happy! And by everyone, of course, I mean no one.
I’ve seen a six-month project stretch to two years, trying to get all six semi-autonomous divisions to agree on functionality and go live together. Each division knew the expectation was for a unified process, and that essentially gave each division power to hold the project hostage – every pet feature request became a “showstopper” they couldn’t go live without. The result was a system so complex that no one liked it – and ironically, it still isn’t used by all divisions.
By contrast, another organization had a business office that objected to the automation project and didn’t want to be included. Rather than make concessions to bring them on board, the project sponsors proceeded without them. When the solution went live, the process became many times easier across the enterprise – except for the population served by the holdout business office. Intense pressure landed on the holdout office, and within months of the initial go-live, they came to the sponsors asking to be included.
To avoid a hostage situation:
- Strike a balance between rigid standardization and profligate customization. Giving stakeholders some common-sense concessions for unique needs can help get the project done faster, as long as the goal to get live soon and simple isn’t ceded.
- Run a nimble, focused automation project that avoids the other pitfalls, and work first with stakeholders that share that vision as a ‘pilot production’ group. Other stakeholders who want good outcomes but fear failure will be assured by the initial success and join later.
In Conclusion
The best way to fail with business process automation is not to do it. The benefits of an elegant, workflow-enabled electronic form solution can be stunning: drastic reductions in turnaround time, error rates, and overall human effort; payoffs in customer service, better security, reduced liability, and freed-up resources who can focus on more productive work. Now that you know what not to do, it would be a shame not to try!
Written by Paul Taylor, Founder
Copyright (c) 2016 Gideon Taylor Consulting, All Rights Reserved.
