Max J Pucher on "The Knowledge Between Your Ears" and Some Thoughts about BPM

Scott Francis
Next Post
Previous Post
Max often writes provocatively, and this one is no exception. I think if one reads his work and takes the big ideas without getting hung up on a few of the specifics that might cause debate, there’s a lot to take away and internalize. As an aside, I find it interesting how often BPM is characterized as being a rigid Tayloristic approach to business – but this is never how we approached BPM at BP3, so I have a hard time relating to this point of view – it sort of assumes that we can’t learn from Taylor and Drucker (and others) at the same time, and benefit from more than one process improvement theology. If I can sum up the criticisms (not from Max’s post, I’m borrowing from many discussions on blogs):
  1. BPM is rigid, like a Taylor management-by-science-gone-bad approach.
  2. BPM can’t be about managing to objectives, like Drucker would suggest
  3. Knowledge workers can’t be managed by a process, or by BPM
  4. Creative processes can’t be managed by a process, or by BPM
Of course, those of us who do BPM “right” look at it a bit differently:
  1. BPM is about adapting to the change that is happening in and around your business.  It is scientific in that it puts value on real data, but it does not believe in replacing human judgment and decision making and subjective valuations. It is not about automating people out of the process – it is about putting the right information in front of them at the right time so that they can do their job more effectively, and make good decisions.
  2. BPM can be about whatever you decide to focus on – managing to objectives or managing a prescribed process – much depends upon the kind of work you’re tackling.  Clearly, handling financial transactions there really shouldn’t be a lot of variance in executing account transfers. But deciding how to handle a customer complaint may leave a lot of room for judgment.  And deciding what the objectives are for a line of business is a process that has much wider latitude.
  3. Knowledge workers interact with processes all the time.  If the process is to support knowledge work, it has to be quite different from one that is quite constrained and repetitive – but that isn’t the same thing as saying it can’t be done.  ACM proponents prefer to talk about this as a separate discipline than BPM – which may leverage the same software tools.  That’s fine – but the point is, there are software tools that market themselves as BPMS packages that *do* support knowledge work, and there are BPM professionals (like BP3) who build and support knowledge worker processes day-in and day-out.
  4. Creative efforts can absolutely be managed by process.  If anyone thinks Einstein and Edison didn’t have a process to guide their efforts, they haven’t studied these two.  Genentech and Apple both have repeatable processes to guide their innovation and creative efforts.  Do they use a BPMS? Likely not, but I don’t despair about that because the penetration of BPMS packages into the market is still small relative to the potential market size, and just because someone doesn’t use a tool doesn’t mean it can’t be useful to that purpose.
Lest it look like I am writing the above as a disagreement with Max, I don’t believe that’s the case – I just want to set the background for some of the general points made against BPM, and my feelings about those points.  Here are some great points from Max that I think a lot of people could learn from:
There are BPM proponents who say that using structured process should be seen as applying experience. I disagree, because a rigid procedure that may have worked in the past is not goal oriented. Experience is something one gains as a person and is not something one can copy. Applying experience happens by people at each singular activity towards the goal. Experience won’t get encoded into process flowcharts during analysis.
Very true.  BPM proponents *should* be applying experience to their work, but that does not mean that a well-built structured process replaces experience.  Max’s points illustrate why it is so important to have experience in general, and specifically with BPM deployments, in order to understand these finer points.
The higher you go in the management hierarchy, the less predefined processes you will find, need and be able to work with. Otherwise, why would one need management and executives? That’s why I am opposed to best practices that are no more than an average of past approaches now being applied to a specific situation without being sure of its applicability.
Again, great points.  Part of the reason processes higher in the organization don’t get defined as well as because there isn’t economy of scale at that level.  But at organizations like GE, they have very evolved processes around developing their executive management team and the bench for each role.  So processes that *do* have scale continue to get process attention. And yet, the decisions made about each of these individuals involve subjective as well as objective data.
The complexity of current information technology leads consultants and analysts to propose that IT has to be rigidly managed as a business resource only and is ideally outsourced or ‘cloudsourced’. This approach certainly kills inhouse innovation.
This reminds me of how some organizations react to complexity by enforcing rigid gateways between project approval, requirements, design, development, testing, and user acceptance… Instead of adopting an agile development approach.
I propose that if executives chose to manage by orthodox (BPM) process management, they chose to ignore the knowledge between the ears of the people that count — their employees and customers!
Executives and management at all levels have to value the knowledge and experience of the people in their businesses – and use software to help them, rather than hinder them.  Thanks to Max for another really interesting read in the BPM/ACM/Adaptive Process discussion.

Tags:

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Max J Pucher on “The Knowledge Between Your Ears” and Some Thoughts about BPM -- Topsy.com()

  • Scott,

    I have found in past that your thoughts and mine match, and this one confirms it again… I had similar thoughts when I read post from Max…. I couldn't have put those better, excellent!

    Having said that I actually found Max's post very intriguing and I have a lot of takeaways from that as well. So in all, great conversations to have!

  • I found his post intriguing as well. He has a different way of formulating his explanations that I find pretty useful. Still, makes me want to try to synthesize “out loud” in the blog :)

  • Scott, thanks for the comments and the positive reaction. A little provocation goes a long way towards being heard over the noise … ;-)

    I do hear what you are saying and some tell me that BPM can be done right. I am not doubting it. I do talk about 'orthodox BPM' often, to make sure it does not get confused with more recent arrivals such as Social-BPM. I just don't see the 'right BPM' happening and most certainly not with the BPM products out there. Paper-and-file BPM could handle it but is no longer competitive. BPM is used to ascertain reliability (seen as a quality) and lower cost and that's how it is being justified. I don't see marketing that says: get your BPM system here that enables your people to do what they think is right. I don't see BPM being marketed as NOT requiring substantial analysis, modeling and monitoring. I don't see the BPM marketing that says that only 20% of processes are predictable. Quite the opposite.

    One could certainly make a milestone process only to ascertain certain steps to be taken, and leave the rest to the actors, but how would they add new actors, new tasks, new content, add goals, rules and event handlers, and change the process as needed on the fly and feed that back to the flowchart. If you do all of that all the time then yes, I wonder why I don't see it. I also propose that this is not the accepted view of BPM, otherwise why would we have a discussion as to if and how BPM is changing.

    BTW: I am an expert on Einstein, if you allow me to say so and the last thing Einstein had was a process. All he had was perseverance and stamina and faith that nature can be grasped by mental modeling alone. Einstein died quite disappointed that the GUT – Grand Unified Theory eluded his most certainly great mind. He had a quite hard time to accept the uncertainty, unpredictability, and probability aspects of quantum theory. Predictability is after all a human illusion.

    He said: 'God does not play dice.' Well, it seems that's all he does.

  • to quote your response: “I don't see marketing that says: get your BPM system here that enables your people to do what they think is right. I don't see BPM being marketed as NOT requiring substantial analysis, modeling and monitoring. I don't see the BPM marketing that says that only 20% of processes are predictable. Quite the opposite. ”

    I don't either, but I'm not in marketing for a BPM vendor :)

    Every creative person I've ever known has had a process. Though, virtually all of them do not perceive it as such, and would never describe it as such. And yet, it is obvious to the outside observer. I'll not pick an argument w/ you over Einstein in particular but I believe Edison said that inventing was 99% perspiration and 1% inspiration. What was that perspiration? (answer: process, iterated many times, to find a commercializable solution)

    you also state:
    “One could certainly make a milestone process only to ascertain certain steps to be taken, and leave the rest to the actors, but how would they add new actors, new tasks, new content, add goals, rules and event handlers, and change the process as needed on the fly and feed that back to the flowchart.”

    Well, now you're constraining things to a specific set of variances, rather than opening up to a wide spectrum of required variance. A process can very well assist knowledge workers without requiring them to add goals and event handlers and actors to the process. Many processes are only partly unpredictable, not wholly unpredictable, and so they do not require inventing the process on the fly for each instance – but they do require human judgment and action in each instance.

    I'll give an example. Invoice reconciliation is not something that can be fully automated – it requires human judgment to decide what to do with it when it doesn't match up. That doesn't mean that the human in the process has to design new process on the fly. That's maybe a trivial example, but we could go on and on with similar examples. They can be outlined but require real people to drive them. I'm just finishing a customer service process now that puts more tools at the fingertips of the CSR. The CSR has a highly subjective creative task they have to complete (finding acceptable substitute product inventory for a customer), but there is still a process for initiating and completing the process, and the ramifications of that process on other business entities.

    “I also propose that this is not the accepted view of BPM, otherwise why would we have a discussion as to if and how BPM is changing. ” Actually, I think the discussion has come up because people are now trying to narrow the definition of BPM to create more space for something called ACM :) if BPM includes any unpredictability at all, that shrinks the space for something called ACM. So, I see an effort to put BPM into a tight, small box. But, I'm willing to concede your point that there are a lot of people who think BPM is all about automating. I think those people are wrong, or at least only addressing part of the problem.

    I've said before, I'll say it again – from what you say about your product it sounds interesting, and I'll have to make time to learn more. But even a product without your product's features can be used to support knowledge work rather than defeat it. (and yes, i could get into esoterics but I can build processes that allow for new actors to be added, and events, and so forth – though the implementation would be quite different than your product, no doubt. But I assure you, the software is quite Turing Complete :)

    As to the last:
    “He said: 'God does not play dice.' Well, it seems that's all he does.”

    Key word: seems. We are like the blind men feeling the elephant. We can see so few of the variables in the universe, and so little of its light and information. Even if there was no randomness at all, we couldn't help but experience something that feels like luck or randomness because we can't see observe the cause and effect. And maybe it is dice rolling (are dice random?) :) but I won't presume to bet one way or the other!

    • Scott, as I am writing a new paper and book I went back to some of our exchanges and realize that I haven’t responded on your comment. Let me just say this: You say that BPMS and BPM practitioners do support knowledge workers and knowledge processes all the time. I simply disagree and I would really be thankful about a few real world samples so I can understand why we do.

      In terms of creative processes: Yes, some ‘creations’ require a process, (i.e. record a song, but not the writing of it) but it is a grave error to believe that Einstein followed some process to discover relativity. I at least fail to see any process in my creative efforts and sometimes I wish there would be to make them more predictable! The creative crowd I know really shies away from predictability.

      Finally, when I quoted: ‘God does not play dice’ I refered to EInstein’s refusal to accept quantum mechanics. As you most probably know he eventually had to and therefore ‘God does play dice.’ The discoveries searched for by the Large Hadron Collider in Geneva are all based on Monte Carlo walks and probability calculations. Nothing predictabel at all .. we are not even sure if what we measure is really there.

      And here come the BPM gurus who think they have it all under control. Excuse me, but I find that hilarious …

      Thanks for the great discussion and exchange. Max

      • Even those who write have a process. The processes are certainly lighter touch than processes that can be automated. Applying process to creative efforts that don’t have scale may not make that obvious. But consider organizations that are both creative and do it at scale- ad firms, Apple, Pixar, web design, frog design (product design firm), etc. I think these organizations would be offended at the idea that what they do isn’t creative. But it still has process. The process provides a framework – not the creativity. And it doesn’t replace human judgment (is this character deep enough? does this animation FEEL right?) But of course the trick is not so much process that it stifles the very creativity it seeks to organize.

        Having done some work at a linear accelerator (at Stanford), I’m familiar with the issues of finding small particles – you simply can’t know their position and momentum precisely. But business processes are hardly particle physics – in some ways they’re less predictable, and in some ways more :)

        As for BPMS practitioners- perhaps I shouldn’t speak for all of them. But I certainly can speak for our own work at bp3. We’ve worked on processes that enabled Product Managers to define product without worrying that all the appropriate people were notified of changes to parts and builds and specifications – and that appropriate approvals were triggered. Not only are those notifications and approvals triggered automatically, the processes to manage those are managed by a set of processes we contributed to. Yet all of the participants in the process are knowledge workers. We just took some of the rote work out of their to-do list and left them with the stuff that is actually hard! (but, with more time in the day to address it).

        There are many examples like this.

      • And I should have mentioned, I’m looking forward to hearing about the new book –

  • Scott, good post.

    I think it would really help me, and maybe some others if you could list 5 or 6 things that are NOT BPM. It seems to me, and I don't know if I am misunderstanding, but it seems that you are saying that everything can be handled by BPM.

    To the extent that a term means “everything” its usefulness as a term approaches zero. I don't really think that you think BPM means everything, but it would help if you could list some patterns of work that are NOT BPM.

  • I'll work on a post to explain my thinking better.
    But to your question: are you asking for examples of things should not be managed processes, or are you asking for examples of things that I would not apply a BPMS to provide a solution?

  • The essence of the definition of BPM: the “Management of Business Processes”.

  • I'd start with this thought:
    If its a business, and its a process, and it is worth something to you, then you should manage it.

    I'd set aside “one-off” processes like continental and united merging – if you haven't anticipated it, and you believe it to be a one-off, then BPM may not make sense.

    But processes with volume and frequency (and therefore, significant $ value) can and should be managed. Whether you call them cases or processes, they have inputs, outputs, actors and outcomes that affect your business that you can manage, understand, and improve. This doesn't mean that every minutiae of the process comes under scrutiny – picking the right abstractions is part of the secret sauce.

    There are certainly areas that are not businesses where a BPM approach makes sense (research administration in a university), but there are also areas that are businesses that I think you can take BPM too far. While many operations in a hospital would benefit from BPM (and I've implemented quite a few), I would not presume to implement medical diagnosis and treatment of an individual patient with BPM. In a larger health system though, I would absolutely apply methods (value stream analysis, lean, six sigma) to understand outcomes and throughput and bottlenecks and quality of care – and to use this feedback to change how we operate the system for the better. Note, we'd probably not only optimize for $ in such a situation, but for patient outcomes.

    The doctor may have a case – and some of those cases may set off processes (like, getting reimbursed by insurance). Take a step back now. Handling the totality of the cases is itself a process (or set of processes) to which BPM can be applied.

    In a complex organization, as you look at the business in different levels or layers, some parts will look structured, and some parts unstructured. And as you dial out the lens, some of those structured parts will be encapsulated by unstructured layers, and vice versa… and dial out again, and it repeats. Perspective makes a difference.

  • Good post, Scott!

    Big part of criticisms towards BPM that I hear comes from people that don't know how to / didn't have a chance to see an example of “BPM done right”.

    OK, one may question why it's such a rare beast. Maybe BPM is too complicated and ACM will solve the same tasks more easily? I seriously doubt this is the case.

    The major source of complexity are enterprise processes (core, end-to-end, cross-functional – whatever you call them) per se, not BPM. And the control system (the process management system) can't be simpler than the system being controlled (the enterprise), it's an axiom. Hence the complexity of BPM.

    ACM offers some fresh ideas indeed. I'd love if it finally established a good links from BPM to social things and to project management. But it's an addition or extension to BPM, not a replacement. One can't go ACM without learing BPM lessons.

  • Anatoly, I once again find it hard to disagree with you :)

  • I completely agree that scope effects this. It will be normal to have an ACM approach (you call this unstructured) which has some steps which are themselves implemented with a BPM approach (you call this structured) and that may in turn have steps which are implemented with an ACM approach.

    Things you listed which are not handled well by BPM:

    1) continental and united merging
    2) medical diagnosis and treatment of an individual patient

    Did I get that right? Do you agree that these are easy to handle with a “case management” approach? If so, there we have it: ACM can't be a subset of BPM, if it handles things that are not well handled with BPM.

    You seem to group everything into BPM: value chains, lean, six-sigma, and anything with volume and frequency. If you believe that BPM is any sort of automation or support of people in the office, then of course everything falls under BPM.

    I have provided a definition of BPM, and you will find it at:

    http://kswenson.wordpress.com/glossary/

    My argument and claims are related to this definition of BPM. You may not agree with this definition. If that is the case, can I impose on you to provide your definition in a similar fashion? Jacob mentioned this many times: it is pointless to argue whether ACM and BPM are different when you have not nailed down the definition of BPM.

    I can not claim that my definition of BPM is universal, though I tried very hard to make it representative of the majority of uses.

    I can assure you, however, that my position of BPM and ACM as different is NOT simply glamor-eyed infatuation of my new pet theory. Instead, a careful rigorous assessment of what BPM is according to the value it provides, and what ACM is, and its value. However, there is no universal meaning of BPM…..

  • Keith, likewise, I assure you that I am not simply close-minded as you implied in the other post: “There is a certain blindness that we are afflicted with once we adopt a mindset for viewing the world.” So, neither of us accepts the notion that we are blinded :) Let's move on then.

    You asked me to identify things that might not be a good fit for BPM – that isn't the same thing as saying they're easy with ACM. They're not easy, period.

    Also, if ACM addresses a single instance well – let's just take that as a given for a moment. BPM addresses *aggregate* outcomes well – let's take that as a given for a moment as well. It no longer matters what “contains” what in this context. But if I run a bpm project, it might make a lot of sense to run an ACM playbook for parts of the business. If I'm running an ACM project, it might make sense to run a BPM playbook for parts of the business (for example, rolling up the outcomes to look for correlations as we get volume).

    And yes, I group all of those things into BPM. So does OMG by the way – check out the http://www.omg.org/oceb section for what is covered under the BPM examinations for certification. Not that you can't do a six sigma project without doing BPM, but if you do BPM, you can certainly include six sigma techniques to support your project (and in many cases, you should).

    That's why I think ACM is “part of BPM” – when I'm doing a project, I'd apply case management techniques (as you've described them) to things that aren't “structured” to overuse that term.

    Regarding definitions, I'm not going to put one out there and be accused of further fragmenting the BPM definitions and get called on your BPM definitions page ;) But I think this page summarizes BPM nicely:

    http://www.omg.org/oceb/defbusinessprocess.htm

    I don't find the definition on your glossary page objectionable either. I just draw different conclusions than you do about what the words in your definitions mean.