1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, April 11 2017, 09:55 AM
  4.  Subscribe via email
With all the buzz about business process reengineering, would you say BPR is one of the keys to business transformation today?
Not any more than it always has been in BPM
It should be a balance, as usual. Unfortunately, BPR was actively ignoring the technological side of changes (I remember that a completed BPRed organization used all the same IT applications as before being BPRed). Right now, I can see an opposite extreme - changes become technology-only.

What can be a name for BPR+BT?

A version for BPR+BT -- Digital Execution of Business and Transformation (DEBT)
  1. Dr Alexander Samarin
  2. 2 weeks ago
People *and* technology?! Whaaa? #TouchNose
  1. Patrick Lujan
  2. 2 weeks ago
David Chassels Accepted Answer
So we now come full circle to the base message from Hammer and Champy in the early 90s as the digital focus now recognises that business is driven by people and their processes which constantly change. The reason those early BPR efforts failed was the failure of the software to support either how people needed support or the ability to easily change. This was recognised in the birth of BPM from those forward thinkers in "IT" but sadly the supporting software just failed to make that step towards putting business in control of their processes. However this at last now changing as evidenced by the forward thinkers in this forum.

The need for a paradigm shift in delivery of next generation software which creates adaptive digital solutions is long overdue. Build must be quick simple transparent and in hands of business with IT in support for delivery, security and of course using legacy as required by users needs. Real time feed back of process knowledge to allow and encourage empowerment of users to promote efficiency and accountability without tiers of "management"....and there in may be the real challenge for the required transformation. Remember real transformation starts with transformation of management...!

Frankly most top business management have lost faith and trust in how software has created a very costly inflexible mess of now legacy systems. They will need to be persuaded that this next generation software is going to deliver. Once they understand how such software Platforms actually work then a new journey will begin....as ever just a question of when and likely quite soon and BPR can become a reality.
+1 . . . "business is driven by people and their processes which constantly change" . . . insofar as this is true, the centrality and importance of the "roundtrip problem" is highlighted. There are few problems in BPM, technical or human or sales or adoption, that are not traceable to the roundtrip problem in some way or another.
  1. John Morris
  2. 2 weeks ago
Hi John. I am intrigued what is in business language " the round trip problem"?
  1. David Chassels
  2. 2 weeks ago
Hi David, good question.
So, in answer, here's an excerpt from an upcoming item in the current "BPM As Revolutionary Enabler" series on BPM.com, exploring the roundtrip problem from a business perspective (Paper III, Part 4):
--------- EXCERPT FROM UPCOMING ARTICLE --------------------
You wouldn’t be surprised if after deploying a new business process, that the very next day, you and your team learn something new about your business process. And want to change the process!
This is why you bought or deployed with BPM software in the first place, to be able to build and evolve your business processes faster. But you find that changing your in-place process isn’t quite as easy as you’d hoped!
The so-called “process modeling roundtrip problem” was, and often still is, a challenge.
Typically an executable process artefact needs to have all sorts of additional “techy” improvements added to the artefact to make it usable in a corporate environment. IT staff might even add new process steps that the business people didn’t think of!
And so very quickly the two process models, the original process model and the deployed process model, are now out of sync. This is the “roundtrip problem”: synchronizing changes made in either business model or execution model, back and forth between the two models.
For technical reasons, pushing changes back and forth between these two pieces of software might not be easy – and even when it can be done, limitations on modeling freedom are sometimes added part of the synchronization.
The result of the roundtrip problem has all too often been that the full management-friendly business process model (that shows up in nice sales demos) is no longer usable, and that the only people who can now change a deployed model are IT people. This is very disappointing of course to the business team who imagined being able to evolve business processes quickly, without always need IT help.
Fortunately, with new BPM software products and more research into the computer science of BPM software the round tripping issue is slowly diminishing in importance. Especially important is the rise of executable BPMN; with executable BPMN there are no longer two process languages and/or two process data stores to synchronize.
(The reason that the round trip problem is diminishing is in part because of improving technology, but also because of the innovation discussed in the next section on “segregation patterns”.)
Even though the roundtrip issue is based on very technical issues, the impact on BPM technology adoption has been, your author believes, much more substantial than is generally acknowledged.
Maximum benefit from a BPM programme is achieved when managers "think" and "build" new business processes. The hidden roundtrip issue requires planning to minimize any negative impact on the core BPM value proposition.
BONUS: There's also another section in the article on Volker Stiehl's "Business Logic Segregation Pattern", which in itself is very relevant to the issue of roundtripping.
Expected publication sometime in May 2017
  1. John Morris
  2. 1 week ago
Thanks the future should eliminate these issues. First the model be comes the deployed application at a click of button..no code generation compiling. In build change is very easy just change the model with user feed back...almost inevitable when users realise their views can be readily implemented. When change after deployment take the old model change and then with version control i.e. where when you want to implement the new again at a click. This will enhance the BPM value and truly put business in charge and responsible for operational business processes.
  1. David Chassels
  2. 1 week ago
Juan J Moreno Accepted Answer
I'd ask the reverse question: Is possible a real digital transformation without a business process re engineering?
Well, maybe in some particular cases, but in the majority, I think they would walk hand in hand.

Most of cases facing a digital transformation, need to re think how they do each activity that sustain the business, and how this activity could be improved via digitization (if this is possible). This naturally implies that the activity will be changed in a way that is not just replacing tools (example: not justa replace paper with tablets). It implies changing the way this activity is done, if it is needed to be done, if it has to be done by the same people/rol. And this is re engineering this activity and in the big scope, re engineering your business.

So, in sum: Yes, I think BPR is key in DT initiatives and they have to walk hand in hand.

Best regards !
CEO at Flokzu Cloud BPM Suite
Sure, "Where should we start using 3-D printing?" is an example.
  1. Karl Walter Keirstead
  2. 2 weeks ago
E Scott Menter Accepted Answer
Blog Writer
I'm skeptical that we ought to apply any of the process improvement models of the past: Six Sigma, OpEx, BPRE, Kaizen, TQM... all the way back to Taylor.

New tools, new methods. And, frankly, new goals: efficiency and reduced headcount were the KPIs of the past. New business models, new markets, and rapid adaptability to market changes are what it's about today. And besides: the efficiency gains accruing from simply substituting BPM-driven development for traditional coding is going to dwarf any improvements arising from small changes in process execution.
http://www.bplogix.com/images/icon-x-medium.png Scott
RE "New tools, new methods. And, frankly, new goals" I think to have new architecture is very important in this situation.
  1. Dr Alexander Samarin
  2. 2 weeks ago
True enough (the enormous impact of substituting BPM over code-based automation artefact construction). But then BPR ensures that the faster we go, we are going in the right direction.
  1. John Morris
  2. 2 weeks ago
Kay Winkler Accepted Answer
We have seen both. Scenarios were the BPM implementation was mainly focused on gaining insight, process control and compliance as well as cases were BPM was primarily focused on optimizing before “automating” the process. Latter scenario, I would lump into the BPR category. Of course, subtle process enhancements won’t necessarily fit a true reengineering criterion.
Depending on the BPM maturity curve, there are likely to be more BPR occurrences for BPM starters than there are for veterans. In our experience that holds true to the point on which a company faces the need of reinventing itself.
So, both, gradual changes as well BPR have their rightful places in BPM. Whether BPR is a key ingredient to business transformation or not, I think, is a matter of velocity. In that sense, slow, progressive process enhancements will as surely lead to business transformations (compared to the momentum 0) in the long term as BPR will do in the short term, under the umbrella of BPM.
Maybe of interest: I published a couple of KPI measurements in the book referenced below, iBPMS: Digital Edition, that clearly would pertain to the realm of BPR (1st time BPM implementations with huge impacts as compared to the marginal gains, achieved through later improvements).
  1. https://bpm-books.com/collections/bpm-and-workflow/products/ibpms-digital-edition
NSI Soluciones - ABPMP PTY
Bogdan Nafornita Accepted Answer
I agree with E Scott Menter, old methodologies are kind of stuck a bit in the waterfall-ish, monolitic-ish, big bang-ish past.

While BPR still happens, the key difference is in the size of the "re-engineering" efforts - much, much smaller, so delivery is faster, more accurate, less risky and far more frequent - kind of like a purposeful process improvement towards a coherent digitization strategy (no, PI wasn't that purposeful before, it was mostly filling chairs in the BPM CoE :-) ).

A key enabler of the new small-sized BPR is a digital architecture.
Managing Founder, profluo.com
John Morris Accepted Answer
History! Which according to Henry Ford "is bunk". Until it catches up to you.

So today's BPM.com topic is a terrific discussion concerning business transformation (#BizTrans) and business process re-engineering (#BPR) and what can be learned about BPR today and historically.

We could say that today's mania for business transformation, especially via "adaptive" and "agile" business models, is a reworking of old themes, old wine in new bottles perhaps. Not a bad thing at all. But this time around we have more science to help us, especially around "architecture" and "better BPM process engines".

All the BPR activities of analysis, planning and implementation for business transformation (especially concerning iterative business analysis and business modeling) can now be conducted much more successfully:

1. Today BPR is better understood (better understanding of enterprise architecture, better understanding of business models)
2. Today there are now actual tools for making BPR dreams real (better BPM software technology).
Glad to hear that architecture is associated with science!
  1. Dr Alexander Samarin
  2. 2 weeks ago
At least one can defend the proposition that architecture is going in the direction of science, notwithstanding that architecture includes "art" of course. But as a science, one is justified in the claim especially insofar as "ontology" and "systems theory" (including information theory and cybernetics) are both sciences and together they comprise a lot of what is architecture. (Other developing sciences could be added, including micro-economics, behavioural economics and organizational behaviour.) Enterprise architecture on its own is still a very difficult sell I think, better to slip it in as part of a practical BPR programme.
  1. John Morris
  2. 2 weeks ago
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.