I have a very contrarian view to the mainstream one when it comes to the “academic” debate about Robotic Process Automation vs. Business Process Re-engineering.
When RPA is associated with Goldratt’s Theory of Constraints approach, BPR only comes second in terms of benefits, as it wisely should also in the timeline of any company.
Being heavily involved in the RPA industry (that’s also my disclaimer for what comes next), I can churn out all the possible obstacles to a sound and reliable RPA implementation.
Let me name you those three I think are the most important:
1. The Mythical Beast. A “standard process” is a mythical beast very rarely seen in the real world. Reality shows that processes have many variations, especially when executed by humans…, thus programming RPA bots to cover all of them can be very daunting and complicated;
2. Forsaken Robots. Much less than humans, but RPA bots need care and attention too. In other words, robots must be monitored for performances, cybersecurity, and “environment” modifications, and must be maintained and upgraded as any other software product. Too often we meet RPA robots that companies can’t tell what they are doing, and this is scary…;
3. Governance, what else? Implementing a relevant number of RPA bots (in our experience a dozen is that number…) introduces the need to define bespoke governance by the IT organization over RPA, and this can be complicated by the fact that, usually, the IT organization is not the one that brought about RPA in a company.
These obstacles are dangerous, but they can be overcome by proper planning, strong knowledge, and experience on RPA.
What is very paralyzing, in my view, and in some cases almost impossible to overcome, is the “academical” debate among top managers about if they must go through a ‘systemic’ BPR project before implementing any RPA robot.
In my view, this is a futile and somehow cloying debate, where company politics and fights for power can also play a significant role. Indeed, a losing approach when compared to what RPA can do, especially when RPA is combined with the Theory of Constraints recommendations, for a simple set of reasons:
1. If a BPR project hasn’t been initiated before, I question how long and how much debate it will take yet for the same company to start this BPR project and how long it will last, while immediate improvement opportunities are kept on hold, as well as company bottlenecks, waiting for top management to decide on BPR…
2. RPA, when properly implemented, can bring productivity and data quality improvements so rapidly and cost-effectively that investment pay-backs can be achieved before any BPR would eventually review, change, or even dismiss RPA implementations;
3. Plus, after any RPA implementation, other company bottlenecks appear immediately. They can be solved using the Theory of Constraints approach, which is much more effective than any BPR project because TOC focuses on addressing what is exactly bounding the performance and outcomes of a company in that right moment. Solved the first bottleneck, a company can focus on and remove the next one, possibly using RPA again.
Briefly, my point is that RPA and TOC must be used jointly and immediately to bring rapid wins to a company, nevertheless using a broader scope and long-term approach to adopt RPA wherever a meaningful business case sustains the investments and, again, with unified governance.
Business Process Re-engineering and RPA/TOC can then meet down the road, but after many performance improvements have been gained and bottlenecks removed thanks to the powerful combination of RPA and TOC.
Commenti recenti