Looking Behind The Curtain

Scott Francis
Next Post
Previous Post
Neil Ward-Dutton has a great post about BPM vendor results that moves into a discussion of process improvement approaches:
The distinction between “old school” and “new wave” process improvement approaches (I’ve called these “high church” and “low church” before) is just continuing to get stronger. 10 years ago, the vast bulk of process improvement activity used to be driven by the “high church” crowd: lots of ceremony, burning of incense, and so on. Scientific improvement efforts driven by highly-qualified specialists are essential in situations where there’s a lot at stake (for example when you’re reengineering an auto manufacturing line: get it wrong and it’s going to cost you a lot to put it right). And don’t get me wrong: there’s definitely a place for this.
This description and the ensuing thoughts reminded me of our early experiences with BPM at Lombardi.  Lance and I (and others at Lombardi) were often running into process improvement experts with a grounding in Six Sigma or Lean (or less often, IDS Scheer, or Enterprise Architecture modeling).  We were sometimes supported by these folks, and sometimes they resisted our approach (and “BPM” in general).  On the whole, there was a lot of resistance, as our approach to process improvement was somewhat heretical. So Lance (now CEO of BP3), embarked on a journey to get behind the curtain, to understand the vestments of the Six Sigma and process improvement community so that we could better work with these folks.  After going through the first rounds of training at the Green Belt level, he started to get others of us to go through the training as well.  And what we found was that you didn’t have to adopt the religion of Six Sigma to get the value.  The statistical tools are just that :  great tools you can use.  The “high church” trappings are wholly unnecessary but they do create an aura of authority for those who exercise them.  Lance went on to become a certified Master Black Belt, but we continued to apply what we learned from Six Sigma in an eminently practical way.  The point isn’t to be “pure” – the point is to get to value faster.  If statistics can do that for your business, then you use them.  In our mind, if a BPMS can do that for your business, then you use it.  Make the best of the tools at your disposal to get the maximum benefit. Still, there are those whose self-interest is aligned with keeping the “high church” ceremonies and orthodoxy firmly in place.  The challenge is to keep it in perspective – scientific approaches can inform the “new wave” way of thinking without slowing things down. One of the ironies now is that some of the newer entrants to the Business Process space now see BPM as the high church (old school) and their own approach as the new wave.
  • sfrancis

    Also, a good post from Anatoly Belychook, who tries to draw a demarcation between EA tools and BPMN tools. I believe most of the EA tools would fall into Neil's description of “high church” :)

    http://mainthing.ru/item/285

  • Scott

    Actually I wrote a series of posts on the matter recently.

    Look, BPM is in turn a “high church” for ERP people; ERP is a “high church” for DBAs; DBMS is an over-complicated middleware for unix sysadmins etc. There is a stack of management disciplines and a stack of information technologies.

    Is Neil's “high church” of Six Sigma/Lean or other process improvement methodologies a necessary part of this stack? I believe yes: some management concept must be installed as part of organization's culture. It may be not pure Six Sigma or Lean but rather a fancy mix of these and other ideas taken from TQM and/or ToC which are most suitable for this particular organization but there must be something. BTW, we developed a “business methodology lite” and offer it to those who doesn't have anything as a starting point.

    But it isn't part of our BPM offering. This a problem of some newcomers – they consider business methodology as part of BPM and position themselves as a new wave of business gurus. From my observations, this isn't accepted by customers, this is wrong from methodology standpoint and this is unpractical for BPM providers business perspectives. Embedding management methodology into BPM is like embedding BPMS and process management skills into ERP – it's no good.

    BPM is a combination of tools and skills that can be used to implement process aspect of *any* management methodology. It's more powerfull when it's universal.

    A goal for any project or initiative should not be searched within it's scope – it should be established from broader perspective. Business concept or management methodology is such perspective for a BPM initiative. Lean and Six Sigma says “what to do” and BPM says “how”.

    One may say that it's all pure speculations but there are practical issues. How do we choose a particular business process for our BPM efforts? Picking the right goal is deadly important for the overall success of BPM but it can only be done within the broader scope. At the “high church” if you wish.

    Kind regards
    Anatoly

  • Anatoly – I see your points, but I think there's one bit of misunderstanding – I think when Neil refers to “high church” and “low church” this is a statement of the amount of formalism and structure and rules to follow to get process improvement done. Low church would involve fewer formalities, less structure. So BPM relative to six sigma would look like “low church” because it isn't as formalized… similarly, I would argue BPM looks less formal than many DBMS projects :) – so it isn't where you sit in the application stack, its how bound you are by ceremony, doctrine, and formality.

    Ok, setting aside this high/low church stuff, I think you make some excellent points regarding separating bpm from methodology. We often say that we use “methods” rather than “methodology” because methodology (to us) sounds too rigid and un-accepting of different ideas and approaches that are practically useful.

  • OK, thanks for clarification. It sounds similar to agile vs. traditional waterfall to me. I vote for the former, no doubt.