Well, it should actually. But perhaps not just because of RPA only.
What we lack (big time IMO) is overview (and insight) of process knowledge with all that other related stuff. Something I would define as: knowing WHAT it is you try to achieve, WHEN you want to achieve it and, guess what, WHY you want to achieve it.
The WHY (are you spending time, money, your life on this activity) is the (only) justification of the WHAT. Then add the WHO (is responsible, accountable, consulted, informed etc). Now... if you have all that, you can think about the HOW. And really important: In the right context that is.
This being said... and in order to be able to reengineer, you do need to start with full E2E process knowledge. Otherwise you're walking in the dark. As we have so incredibly complex situations nowadays, tools such as process mining can be of great help here. But it starts with ownership and the above mandatory insight.
Yes, as re-shoring takes place, manufacturing plants will install new infrastructure, dig out their old processes, and possibly want to update these for the new infrastructure.
If things have changed too much, they will invent new processes to go with the new infrastructure.
One word of caution . . . I often find clients trying to find industry "templates" - usually it's more troublesome to adapt someone else's best practices to yours than to simply bring a few stakeholders in a room and map out a process.
We try to get clients to give us images of all of the forms they were using/have been using - this allows us to inventory these at a drawing canvas and do drag and drop as we build a workflow. Much better to have them see their forms posting along workflows than placeholder fake forms.
The key to efficiency when posting form images on forms to include a memo field so that when you roll out a workflow for piano-playing, stakeholders can type in comments,
Very easy from there to take note of bad logic, bad forms, make changes and roll out an update of a process.
+1 on Emiel's comment. I've always thought BPR was "Can we do it better than the way it's being done now and, if so, how and why?" In that context I think it's never gone away. Maybe just renewed instance in something that's been there all along, but now some technology(ies) presents more opportunity for doing it better?
Just my tuppence.
I was at the PEX Financial Services event this week. Many of the attendees were executives / business analysts focused on operational excellence. They are LSS, master black belt professionals learning and sharing best practices for transforming operations and the customer experience. What I see happening more and more is the unification of Lean and BPM. More and more OpEx / Lean professionals are discovering BPM as the platform to extend SIPOCs and Charters into real solutions.
While there I also heard about Robotics. I don't know that it means. I find it confusing. In manufacting real robots do work to accelerate processing and packaging. What do robots do to automate purchasing, AP, on-boarding, claims, referrals, and customer service? If robots are the equivalent of software functionalty based on rules, forms, and web services, then I get it. But let's use the word software or business rules or integrations to explain what we're doing to automate process.
Dr. Davenport's article (originally from WSJ, July 2015) is fascinating because he reports on the colliding worlds of:
Note that RPA is receiving a huge amount of attention in the BPO ("business process outsouring") world, not surprisingly given the nature of a lot of BPO work.
Interestingly, BPM either as acronym or phrase is not included in this particular item by Dr. Davenport.
Conclusion? With a little imagination, Dr. Davenport's insights can be interpreted as supporting a growing BPM opportunity, because . . .
1. ENVIRONMENT ... outside the world of BPM practise and technology, there are business changes (in economics, business organization, management practices) which add up to demand for more process automation and
2. TECHNOLOGY ... inside the world of BPM itself, we see continually improved BPM software technology, and ancillary technologies such as business rules, which make satisfying that demand easier with process-specific solutions.
I saw a marketing piece from a competitor the other day touting “business process automation”. No mention whatsoever of BPM. I guess what's old is new again.
It is interesting that "business process reingineering" means "automation" to BPM vendors. It used to mean consulting / thinking / redesigning / simpliying... and then possibly automation.
Maybe what SHOULD make a comeback is the realization that
"The only place automation comes before simplication is in the dictionary"
Right, BPR is not BPM and the intent of BPR is not always automation. What I find frustrating is when BPR/BPI activities result in a great opportunity for BPM but falls flat becuase lack of committment, vision, or turnover. I feel if BPR professionals better understood/embraced BPM they could leverage BPM suites early in the process innovation exercies to captures to-be workflows with all associated rules and data models to fluidly move into development of solutions for automation.
Thanks for letting me know that Robotics is essentially screenscraping. Fancy word. Confuses the marketplace.
From the comments in this thread, it seems to me that people are missing the "obliterate" part of the original re-engineering manifesto. Don't even think of automation, since that would allow for incremental change to an existing process, that may allow for an adapting to change. What happened to dynamic or adaptive processes? True, if manufacturing returns to the old country, we do have a chance to rethink the processes, but why re-engineer, we might as well engineer the correct processes ground-up. I agree with Garth in that any BPR exercise should lead to a consideration of BPM.
To chime in to Emiel's and Patrick's comments above:
I believe BPR is still here, it's just at a smaller level of granularity (let's just not call it continuous improvement), similar to what happened to re-factoring in software development. You don't re-factor large projects anymore from Fortran to C++ to Java to RoR, you just deploy, tweak, test, redeploy smaller multi-language increments in an agile format.
Of course, the effect of reengineering is much higher than continual improvement – this is why transformations and innvivations are in the high demand right now.
The principles of BPR were very good and they are still valid:
And BPR tools were OK for that time:
But the potentials of BPR were hampered by the IT capabilities of that time (primarily the low speed of evolution). For example, I saw a fully reengineered organisation which used the old ERP system. Fortunately, BPM is more powerful than BPR (see ref1 for comparison of various process-based methodologies).
I believe that combining
will allow realising the full potentials of the BPR – quick re-engineering business processes – thus enables transformations and innovations at various scales & scopes including business models.
Such a combination will be a huge step toward software-defined enterprises.