Music and BPM

Scott Francis
Next Post
Previous Post
Update: In the interest of clarity I’ve updated the second-to-last paragraph of this post. Anyone following the #BPM hashtag on twitter has probably been amused at times because we also get a fair number of posts about BPM the XM/Sirius station as well. But in this case, Emily Burns of Pega has decided music offers a metaphor for BPM vs. Case Management:
Recently I was describing to someone the difference between BPM and Case Management, and found that music lends itself very nicely as a metaphor—specifically, the contrast between solo and ensemble works and the contrast between Classical and jazz.
I couldn’t disagree more.  Any use of an analogy like this, especially when it is loaded to make one party sound better than the other, is easy to pick apart.  In particular she states that “the closest musical metaphor to traditional BPM is the performance of a solo piece; a piece of music written to be performed by an individual person.”  I’m not sure what kind of BPM Emily Burns has been familiar with, but I have yet to see a BPM project for one person.  or built around one process-actor (or even multiple process actors all playing out the same role in the process).  BPM projects are cross-functional and typically cross-departmental. The core of her argument is on more common footing with the idea that case management accommodates improvisation whereas BPM does not.  But I’d hardly equate case management with a jazz ensemble.  Nor BPM with classical music.  Music is art.  Office work may not be routine, but it isn’t typically what I’d call art. Comparisons and analogies around Case Management and BPM always trip up if one is willing to dig into specifics.  Often, the people making the comparisons do so with an implicit (unstated) assumption that all the interactions between process participants has to be modeled in a tool to be effective (or coordinated in a tool at runtime to be effective).  This just isn’t the case – normal human interaction takes place outside of tooling – whether you are a BPM advocate or a Case Management advocate.  There’s no need to model the conversation in the hall, the conversation over the cube wall, the agreements made between coworkers over lunch. What it boils down to is simple – most case management approaches really focus on improving the outcome of a single case, largely ignoring the consequences at volume.  Case Management approaches seem more appropriate to work “processes” (cases) that can not be well-designed a priori.  BPM approaches, on the other hand, tend to focus on optimizing aggregate outcomes rather than a single outcome.  BPM approaches seem more appropriate to work “processes” (cases) that can be largely designed in advance (a priori). The analogies may be comforting, they may help explain an opinion or a point of view, but let’s not mistake them for proof. (Or in particular, proof that one approach is better than the other)
  • While I usually agree with you Scott – this time I think you are blowing smoke. Smoke that reflects your own preoccupation with one approach over another – you miss the point in Emily’s post. 

    I certainly see the analogy (which I think I first used in 2007) to show how BPM is a little like a string orchestra, where as Case Mgt allowed/enabled/supported variations on a theme. The theme is like the structure of the case, the variations being where people exercise their judgement on how the work should be handled (usually within the limits established by the structure). 

    She makes some extremely valid points about the cost and brittleness of a priori mapping a complex process using more traditional BPM approaches. 

    Look forward to a paper I have in editing on the difference between the two streams (actually two ends of the same spectrum we call process). I’ll send you a pre-edit copy to chew on. Maybe we’ll get to discuss it over a bevvy (if you happen to be attending the Forrester BPM Forum in Boston on Sept 22-23).  

    • Derek – in my defense, I wasn’t trying to argue her main point, just taking issue with her method of making it. As you say, the music analogy is a little tired (4+ years of that analogy is enough).  Plus I think you’re analogy, being at a bit higher level, works better.  I don’t really need to talk my own book on this – the market is voting with dollars and euros. 

      Analogies are a great way to explain something early in someone’s understanding precisely because they oversimplify and relate to something more people can relate to.  Not a good way to make an argument, however (because someone can always twist the analogy around).  So I think it is fine for someone to say Case Management is like xyz because of a, b, c reasons.  Gives me an understanding of their thought process. But when someone is doing compare-contrast, using analogies… there are lots of holes.

      I could take lots of issues with the music analogies. For example, how does one scale the jazz ensemble across the # of people that are involved in an orchestra? Why is Emily focused only on one performance? Why not the whole business of delivering that music – from ticket purchasing to collection to manning the gates to ushering to practicing to giving that stellar performance 100 times a year? And coordinating with all the other musical performances that might be at the same venue?

      I’ve played in a band (but please don’t ask me to play anything these days), and my sister is a very good piano player.  I live in Austin, TX, “Live Music Capital of the World” so they say.  Maybe the problem is that I understand a bit too much about how these musical operations work to feel comfortable with the simplistic analogies.

      The brittleness that some experience with BPM is a result of trying to prescribe that which should not or cannot be prescribed in advance.  If you are modeling “every note” you’re doing it wrong.  Maybe this is a consequence of Pega’s rules background/history, that they think that is what BPM looks like?

      “She makes some extremely valid points about the cost and brittleness of a
      priori mapping a complex process using more traditional BPM
      approaches. ” – traditional to whom? Pega?

    • BTW reading your paper now… I’ll let you know what I think :) I’m not currently scheduled for the Forrester BPM Forum (hm… must not be on the right mailing list – hadn’t hit my radar)…

    • Derek – I read it. This paper is guaranteed to be good for business for Forrester and in defining a market that will require a nice competition for the quadrants.  But it doesn’t make DCM a good product category.  At a technical level, I think you’d be surprised how well (some) BPM products address these use cases.  In fact, you can build a pretty interesting ACM/DCM system inside a good BPMS even if the BPMS isn’t explicitly trying to support DCM.  Hm. Maybe I should take a weekend or two to build that just as a proof point ;)

      Now, case management and bpm aren’t just about the technical. But I mention the technical issue simply because it means that DCM products may have a hard time differentiating.  I think the ECM vendors are smart to latch onto BPM and try to be uniquely good at solving these types of business process problems – but the fact is, if BPM wasn’t the heart of the strategy they wouldn’t be buying the BPM projects and kicking off interesting opensource projects. 

      Finally, there’s just the “how do you approach managing work” perspective. And there are interesting differences in approaching with a case management or BPM bias.  But there’s no reason you can’t do both, as has been discussed on this blog ad nauseum!

      But, I’ll also say this:  if you have a chart where BPM occupies the lower left corner, and then you have several points of different kinds of CM categories and are claiming these are all outside of BPM… you’ve lost me.  It doesn’t reflect the reality of what’s going on in the field at all.  You do put the word “Traditional” in front of it – so I suppose I could exclude what we do as not being “traditional” – but I don’t think that’s your intent :)

      (incidentally, one vendor i used to work for used to eat the ECM/DCM vendors for lunch in head-to-heads.  turns out the bpm vendor solved the case management scenarios better than the alleged case management vendors… and some of them tried desperately to become BPM vendors… only to be bought again by another ECM or BPM rollup ;)

  • Emily Burns

    Hi, Scott,
     
    Well, I’ll have to defend myself and my analogy here (more my analogy). I think the area of confusion, lies here:

    “the closest musical metaphor to traditional BPM is the performance of a solo piece; a piece of music written to be performed by an individual person. Just as a piece of sheet music contains the instructions for how to perform that piece, a process model contain the instructions for how to execute a process”

    The one-to-one comparison I am making here is actually to the piece of sheet music, to an individual process map—not the number of performers or actors (to use BPM parlance). The performer is more analogous to the process engine—one process engine executing one of many processes in its “repertoire” (process repository in BPM parlance), compared to one performer executing one of the pieces in his or her repertoire. In both cases, the model is driving how it is executed, but it is just one model that is not interacting with other models. And hence the execution is simpler. That doesn’t mean the piece/process is simpler, and doesn’t have many “voices” or actors. I am a classically trained pianist, having majored in piano performance, and I can tell you, there’s nothing simple about a Bach fugue, or a Chopin ballade. (For my credibility’s sake, I’ll add that my other major was biochemistry and molecular biology, and while I find plenty of metaphors there, too, people tend to find them more difficult to digest).

    That said, executing an individual model, whether a process model or a piece of music written for one person, is easier than executing a work (say a case, or orchestral work) that has multiple different models being executed simultaneously.   

    I think actually where our real disconnect is that for me, case ≠ process. From your comments in the last paragraph of your post

    “Case Management approaches seem more appropriate to “processes” (cases) that can not be well-designed a priori.”

     I assume that for you, case = process and the question as to whether or not it is labeled a “case” or a “process” is purely semantic, dictated by the type of work it is, i.e. more or less structured. As I said, the way I look at it, case and process are not the same, in fact, they are two distinct things. The way I look at it, the case:process relationship is not a 1:1 relationship, but rather, case:process is a 1:many relationship. Each case has a process that governs its overall handling, even if that process is very simple (read “yet-to-be-defined”), but that case may also have other processes executed against it. This is why I stated in my blog that a piece of ensemble music is like case mgmt, because the case is the overall piece, and the “processes” are the multiple pieces of music being played in parallel by the different players. It is not about the number of people involved, it is about the number of models/processes being asked to be performed in parallel. I’ve elaborated on this in detail in this blog post of mine. http://www.pega.com/community/pega-blog/the-distinction-between-case-and-process

    Where the jazz part of the analogy comes in is that in the real world of work, there are often ad hoc elements (sometimes cases, sometimes processes) that must be added to the case and which need to be responded to by the other models, and the different actors executing those models, whether they be people or systems.

    I have a feeling we’re not going to see eye-to-eye on this, because to my mind “case” is not just another word for “process,” and certainly not just another word for “messy, un-defined process.” I think my analogy holds up better than you’re giving it credit for. More to the point though, I think that case management is MORE than BPM, I think that case management can take process management to a new level of utility, by providing a platform for broader consumption of an organization’s business processes, more on that here: http://www.pega.com/community/pega-blog/case-management-your-built-in-bpm-center-of-excellence. Further, I think this platform provides a mechanism for standardizing work done in cases that have only nascent processes and best practices, and that that is part of the great value, moving work progressively from one end of the spectrum to the other. More on that, here: http://www.pega.com/community/pega-blog/ad-hocky-and-the-jabberwocky

    • Emily, welcome :)

      You make a fair point on the solo performance. Thanks for the clarification, although… “In both cases, the model is driving how it is executed, but it is just one model that is not interacting with other models.” Actually, models do interact with other models and/or processes/events via the events and data they interact with (to name just a couple ways that they interact).

      “That said, executing an individual model, whether a process model or a
      piece of music written for one person, is easier than executing a work
      (say a case, or orchestral work) that has multiple different models
      being executed simultaneously. ” This is the heart of it. One person again.  One performance.  And the judgmental notion of “easier” tells me a lot about how you’re thinking about BPM vs. Case Management – because you mean it as a pejorative.  Easier as in “less skilled” or “less interesting”. 

      I think Derek would have argued that an orchestra off of sheet music is more like BPM than a case (see his comment).  Sure they’re playing different pieces but it is all predefined, a priori.  I just think the analogy is messy – and you and Derek have demonstrated that nicely :)  The different pieces of work in the orchestra are like different subprocesses – all part of the master model.  They’re not really different models…

      In BPM many players are operating to different schedules in parallel, on different processes or subprocesses that tie together.  It *sounds* like your orchestra example.  So either the analogy is flawed, or the understanding of BPM is flawed. 

      The argument you’re making is that Case is more than BPM.  I don’t make that argument.  I think they’re just different, and case management seems to be more focused on optimizing the outcome of a single case (or each case individually)- trusting that the cumulative effect is positive. Whereas BPM approaches are more focused on the aggregate outcome (good outcomes in general or on average).  I’ve written to that effect before, as have others in the ACM community.

      I used, deliberately “cases” and “processes” interchangeably – ie, there’s work to get done, and I wanted to discuss the how that work (on a process or a case) gets done and managed using the different approaches.  I could have instead said “work” – apologies for the confusion. 

      (Regarding the 1:many relationship… If you believe case and process are separate, how can you not see that case:process is many-to-many?  A process may touch many cases, and vice versa.  Like many in the case management community, you’re trying to give one primacy over the other, but it is like a russian doll of abstraction – if you go up a level or down a level the perspective changes. It doesn’t matter who is on top, it just matters what is appropriate given your level of abstraction. 

      “More to the point though, I think that case management is MORE than BPM…” I think it is both more and less.  And BPM is both more and less than case management.