Commentary on “A 10,000-foot View of the Business Process Space”: Guest PostMy December 8 blog post about classifying business process approaches generated an avalanche of responses. See the 2×2 matrix itself (from John Mansfield of Fidelity Investments) and the stream of Comments about it on http://www.brsolutions.com/2014/12/08/a-10000-foot-view-of-the-business-process-space-is-it-correct-is-it-complete/. In the guest post below, Brett Champlin shares his evaluation of the matrix. ~~~~~~~~~~ There are many things wrong with the matrix.
- Lean and Six Sigma are both process improvement methodologies and are frequently combined as Lean Six Sigma. So they can all be subsumed into a category of process improvement methods.
- The matrix leaves out classic process redesign methods which are very commonly used. These methods go beyond improvement methods to respond to things like automation, new products, M&A, etc. where the basic process is modified or extended to accommodate some new situation.
- Process improvement and redesign methods along with reegineering (aka process transformation and/or innovation and/or reinvention) are all process change methods. Change management should certainly accompany them all.
- The matrix also leaves out Business Process Management as an all-encompassing discipline that deals with all types of process change as well as strategy, monitoring and measurement, and process portfolio management.
- It also leaves out Customer Experience Design, which over the last several years has been incorporated into many BPM toolkits as a precursor to any process change effort.
Tags: BPM, Brett Champlin, business process management, business process re-engineering, continuous improvement, Lean, process redesign, Six Sigma
Ronald G. Ross
Brett, You make some excellent points that bring the perspective and potential flaws of the original matrix into focus. (Thx!)
Where we part ways is seeing BPM as an all-encompassing discipline. In effect, I see you simply adding a progression of techniques on top of one each other:
1. Industrial-style process improvement.
2. Process redesign to address things like automation, new products, M&A, etc.
3. Change management.
4. Strategy, and monitoring and measurement.
5. Process portfolio management (which is really about governance).
6. Customer experience design.
Too big. Too unwieldy. Too weak at the base. That’s what a call a Big-P approach … all things stuffed into the process bag. I’m on the record against that mindset:
Instead, as those posts suggest, I believe in a more balanced approach to business architecture whose primary objective is ‘business configuration agility’.
I’ve resisted commenting on the 2×2 matrix – I thought it was a bit simplistic to put the whole “business process” space into a 2×2 matrix, and knew I’d end up writing 1500 words on why I didn’t like it. Of course, as a long-time consultant, I love 2×2 matrices, still finding the original “Boston Matrix” useful for making points about product management, but this one didn’t work for me.
To be fair, we don’t know the context in which John from Fidelity was using the diagram. If the intent was to compare and contrast Lean (waste) and Six Sigma (a defect-oriented view of quality) then it’s just fine. We’re all piling on and observing it doesn’t really represent the BPM (a label I hate) space when that was probably not the original purpose. While I’m at it, let’s also acknowledge that Lean and Six Sigma are, like all labels, ultimately useless because the discipline under the label continually evolves and incorporates ideas from other disciplines. What people claim as being standard Lean or Six Sig in 2014 is far removed from what would be claimed as standard 5 or 10 or 15 years ago. I see I’m about to leap into a 1500 word “No Labels!” diatribe, so I’ll pull back and get to my comment on Brett’s post…
Brett, as usual, has succinctly put all the important points into an admirably brief post, complete with some excellent charts. If I use them, I’ll give full attribution to Brett. 🙂 And I might well use them… I found recently that one of my clients (CIO at a major east coast public research university) carries around a couple of laminated PPT slides of my two key frameworks. The only other laminated slide he carries around is from Brett, who has a knack for summarising key points.
I also really like Ron’s response about the problem of lumping everything into a “Big-P” approach. I couldn’t agree more! Ron’s comments tie into my aversion to labels. Whether the label is “business process management,” or “data,” or “Agile,” or “business rules,” or “enterprise architecture,” or “customer experience design,” or whatever, the result is that people put themselves into boxes, or silos. Ron sees a holistic approach that helps to achieve “business configuration agility” which sounds pretty good to me. Often, though, the point isn’t to be more agile but to be less boneheaded. I’ve realised in recent years my clients hire me not because of expertise with process or data or applications or whatever, but because I help them see how they actually operate and what the issue really is, and then help them figure out a reasonable way forward. With no labels.
Thanks Brett and Ron!
Richard Bach sums it up in Jonathan Livingston Seagull
“A name is a label, and as soon as there is a label, the ideas disappear and out comes label-worship and label bashing, and instead of living by a theme of ideas, people begin dying for labels…”
I see that we are obviously not talking apples and apples here based on your equating my diagrams to what you call the big-P approach… which I am not entirely clear on even after reading your posts on the subject… but I can tell that it isn’t what I am describing here. I also have a big-P concept but it is quite different. To me, BPM isn’t the technology or the “business architecture” (whatever that is), it is a management discipline, i.e., a framework that presents a perspective on managing (forecasting,. planning, organizing, directing, coordinating and controlling work and resources) a business operation based on recognizing the organization as a system of processes – what we do and how we do it. Business/Process Managers have to be able to assess the need to allocate resources and attention to a constant need to change the operations of an organization – improve, retire, fix, add, etc. To do it well requires some approach and Process Management is one approach that has evolved to attempt to overcome most of the more serious problems with other management approaches. My version of big-P is recognizing end-to-end processes and their inter-dependencies in a consistent way and to align change efforts to strategic goals rather than the squeaky wheel approach… rather than a PROJECT portfolio prioritized on localized financial justifications, a PROCESS portfolio prioritized by strategic positioning… I could go on and on, but I am not trying to promote BPM as any kind of IT architecture and none of this implies embedding rules in code which seems to be your main objection to your idea of big-P … this isn’t meant to apply to IT backend processing or data architecture or repositories or SOA or anything of that nature. It is a mindset, if you will, to enable better decision making about managing change in organizations. I would sure like to understand what you think is a more balanced approach to managing ‘business configuration agility’… which is a phrase I doubt I would hear any business manager use in daily conversation. If we are talking about the ability to adapt your business model and align the parts of the business, then I haven’t seen anything better than BPM (as a management discipline).
Alex, thank you for the kind words. You may not like to use labels, but then how can you discuss anything if you don’t try to agree on some common language to reference your idea? It seems to me that all useful disciplines depend on the community of practitioners agreeing on common language and labels in order to make any progress and build upon each others idea. It certainly is the case in discussions of BPM that one of the most vexing problems is trying to find commonly agreed upon labels and definitions of the basic terminology – which as you correctly point out, by necessity changes over time. Part of the problem is not everyone takes the time to make sure that they are using the same words in the same ways… less boneheaded indeed!
Ronald G. Ross
Re Configuration Agility: See http://www.brsolutions.com/2012/06/13/the-procedural-paradigm-won%e2%80%99t-scale-we-need-configuration-agility/
Re Vocabulary: Establishing a common concept system (business vocabulary) is THE problem for any discipline that wants to move beyond sales and politics. (In both, labels are used intentionally as placeholders for listeners to assign their own meanings.) In other words, any time you want to engineer results requiring real communication.