Over the last 18 months I’ve canvassed a lot of clients who were beginning to work with RPA and initiating pilot projects or evaluations. I was initially surprised to hear a client tell me that before they automated their processes with RPA, they needed to first document their processes.
You can imagine me being surprised. After all, documenting processes isn’t something new. iGrafx has been offering great software for documenting processes for a few decades. Discovering processes is a discipline that goes back at least as far as the 1990’s and Business Process Re-engineering.
But, I shouldn’t have been surprised. And after hearing this a dozen times, I wasn’t surprised anymore. I shouldn’t have been surprised because business changes and evolves, and it really doesn’t wait for process documentation to be updated. In fact, executives often fail to fund efforts to define and document core processes – because they don’t attach a hard ROI to those efforts.
So, I asked these clients and prospective clients why they were investigating RPA if they felt they still had core process definition and documentation to do – and the answer was that the documentation effort was going to get funded by an RPA project. That’s the secret sauce. To do RPA correctly, we need to discover not just the details of an automation, but the business process in which it participates. But RPA is the juice to the ROI equation that makes the documentation effort feel worthwhile.
This arrangement also signals two more things:
To the first, you need an accurate representation of what’s happening now in your business. By definition your documentation is out of date. Moreover, as you make changes to your process with automation driven by RPA, process mining can give you the insights to see if you’re yielding the benefits you anticipated – and if not, why not.
To the second point, you need your delivery team involved in discovery because the boundary conditions of RPA tooling are not widely known. They’re not as common and settled as spreadsheets for business technology. And your delivery team can advise you as to which automations RPA is well-suited to drive, and which details are best suited for other approaches in addition to RPA. Of course, you need a delivery team with expertise in the relevant areas: process mining, RPA, process, decisioning, AI/ML, to start. It’s a long list but not an unreasonable one to ask of your delivery team.
Of course, delivery teams know how important it is to work with their business teams during discovery – and during delivery. They’ve usually seen the failure modes that occur from isolating discovery from delivery. The biggest insights come from multi-disciplinary and inter-disciplinary innovation. Give these teams a chance to collaborate and creatively solve problems for your business- and give them the tools to get it done!