It's time to define 'BPM' for a new era, just forget about the name for now

“A rose by any other name” they say. Seems the first thing people want to jump on is to hang their hat on creating a new acronym for what BPM is trying to evolve into. And I say trying because there’s a massive amount of legacy to bin in order to move at least one step. Business Process Management was forged roughly 20 years ago now out of the fires of BPR but I’ll be frank and say that as a discipline it’s hardly broken out of the process reengineering mould has it ?

In a recent flurry of tweets between Connie Moore, Scott Francis, Ashish Bhagwat and myself, Connie said that “the problem with #bpm is that process is too constraining. BPM is spilling over the boundaries of process”, I agreed stating that BPM needs to shed it’s skin, it’s changing into something far bigger and more flexible. The perennial favourite of naming the newborn came up in question and Scott made a couple of interesting comments about the term BPM itself (I agree with him though that we should focus on what the ‘stuff’ in the middle is before we worry about the name): “how much more generic can name get than BPM ?

Therein lies the issue. When the term was coined it was too generic, too vague and not a million miles away from BPR, so we’ve had confusion and misinterpretation for two decades now which has allowed multiple strands of what BPM should have been to exist, petty in-fighting, vendor hype and plenty of “certified” courses to choose from (certifiable more like if you took one but that’s a personal opinion).

So back to the point, it’s time to redefine BPM for this new era. But perhaps redefining is still too weak an option to take, what we need to do is examine what is happening in the industry and treat this as a completely new concept from scratch, start with the blank sheet and forget the legacy. So let’s try and consider some of the points that have shaped the last 12 months and brought about such a desire to break out of the process cage.

  • No matter how you define it; phenomenon, discipline or technology, ‘Social’ is changing how we think about traditional BPM not only from a technical standpoint but also an organisational point of view. It’s clear from discussions that Social is also affecting other industries too, most notably CRM. But it’s the way it’s exposing how little difference there really is between sectors which have been kept at arms length before is astonishing. Like I blogged before, Salesforce may have understood process better than we have by doing everything backwards, coming from CRM and not BPM. Pega’s acquisition of Chordiant is another clear indication of the blurring of lines between strategies. Social is nothing new, people like Sandy Kemsley have been talking about it for a few years but it’s only really now that it’s getting the attention it deserves. But please think beyond the technology ! Social is not exclusive to just one industry or aspect of it, it can really change the fabric of the enterprise but little focus is made in this area.
  • Gartner talks of ad-hoc and unstructured processes, Forrester speaks about Dynamic Case Management. Depending on who you talk to in these areas surveys suggest there is between 60-80% of an enterprise built on these seemingly unmanageable and unstructured processes, meaning there’s 20-40% that can be mapped. Speaking to the traditional BPA vendor market the numbers are similar to manual vs. automated processes so who is right, and more importantly has anyone qualified them both together (so have we been mapping for the sake of it and capturing exceptions left, right and centre when the process was too chaotic in the first place ?) Andrew Smith made a really good case (no pun intended) for managing without maps altogether in this blog this week about Adaptive BPM (again though I have to question why we need to think about the ‘BPM’ element if it’s something evolutionary, or even revolutionary)
  • There have been blurred lines between BPM, ECM, MDM and other areas coming to the fore in recent times so there appears to be a push in consolidating all these terms and finding commonality between them all, and given the buzz every time people mention this there must be scope to. Ashish blogged about convergence in the industry and it’s very true.
  • PaaS, SaaS, Cloud, Mobile, Business Process Applications, Open Source, they’ve all changed the platform and if you’re not there in some shape or form then you’re lagging behind a little.
  • The term BPM itself means many things to many people. Business – Process – Management. Like I said, it was too vague to begin with. Connie may have struck on something when she said that process has become too constraining as a term or concept. I’d argue that all three elements have been outgrown by where we are today.

So, as practitioners, vendors and analysts don’t we have a duty to sit down as a collective and start scribbling on that blank sheet of paper ? If ‘Social’ can break down so many barriers and faux-silos then it also can bring parties to the table for a common cause.

“Your father called the future ‘the undiscovered country’….people can be very frightened of change…”
The ramifications are huge, whole product strategies and ways we apply change and think of process are at stake but it’s just as bad to resist just because “we’ve always done it that way”.

I said in a previous blog that CRM and BPM were destined to get married. I was wrong. It’s not a marriage we want, it’s a rebirth. Or perhaps a brand new birth itself. Like a hybrid or Chimera, take the best DNA from each industry, shake up the test tube and watch the results unfold.

Just don’t quote me entries from the A-Z of Modern Baby Names please…..


12 responses to “It's time to define 'BPM' for a new era, just forget about the name for now

  1. To me, the word "process" isn’t narrow, its wide as the ocean – but sometimes people interpret BPM to mean only the confines of the diagram itself, and not the "living entity" that is what the participants in the process experience. And in that sense, Connie’s comment about process being confining is right – but I challenge the notion that a "process" has to be rigid and absent human judgment, and absent adaptation to the facts – and to the extent that we’ve let software vendors push this point of view is embarrassing to me – shame on us! The interesting thing about these products focused at more "adaptive" approaches is the extent to which they make this EASIER, not the extent to which they make it POSSIBLE (and there’s a big difference between the two – one is just an evolutionary incremental improvement, the other is a revolutionary improvement that might warrant new three letter acronyms 😉 I don’t think we need another three letter acronym. And I think when people tag "BPM" on the back end of other terms, that is actually clarifying and appropriate in some respects- they’re trying to define a subset of business process or business process management that they are targeting. But, the criticism I do have is that on the whole, too many of these terms are targeted at IT, rather than business ("Adaptive BPM" ? "Dynamic BPM"? At least most businesses know what case management is). We should instead be trying to figure out terms that will help business executives understand what the software will do for them. In that sense, maybe we should relabel BPM to ROI 😉 (just kidding!)you said: "The term BPM itself means many things to many people. Business – Process – Management. Like I said, it was too vague to begin with. Connie may have struck on something when she said that process has become too constraining as a term or concept. I’d argue that all three elements have been outgrown by where we are today." I think that’s a fair criticism of what the software labeled BPM did for businesses – too vague to begin with – but it speaks to the aspirations of the people involved in BPM in the early days – for businesses to actually manage mission-critical processes using this software. The terms may be "too vague" – but I don’t see the argument for how we’ve outgrown them – I think we still haven’t lived up to them.

  2. The problem might be that BPM the discipline has been conflated with BPMN the technology.It wasn’t an accident, BPM was co-opted by the BPMN vendors who promoted BPMN as the heir of both BPM and proprietary vendor workflow tools. The promise sounded good – ‘enable the drawing and we’ll have one common language for describing and executing process’. Nirvana, right. Close, but no cigar. As BPMN attempts to expand its markets, the flowcharts and the semantics are also growing, but at the cost of visual comprehension – flowcharts simply don’t scale with complexity. In addition, BPMN is about as dynamic as a train on tracks, you can gussy it up and improve the food, but off roading will always be out of the question.BPMN vendors are trying to course correct (i.e. multi-view, ad hoc sub-processes, etc.), but elevating a flowchart as the primary artifact of a visual programming language was simply a mistake. BPMN both enables processes and constrains them. The current schisms (dynamic bpm, adaptive case management, ad hoc task groupware, etc) are a result of this contradiction. The bottom line is we need better frameworks for managing the component-based distributed and interactive future.So now is the perfect time for BPM the craft to regain its technology independence. Organizations need help illuminating and optimizing processes now more than ever. In particular, they need qualified guidance on navigating the maze of technology options to ensure they get the right tools for the job.BPM can endure, but only if it separates from the technology de jour.

  3. In some sense, the current misunderstanding of BPM is a “victim” of English language – "business process management" is not about managing of business processes, but it is about managing of an enterprise by business processes. The latter has a completely different scope which is “bigger” than process and much “bigger” of any technology (ERP, MDM, CRM, PaaS, etc.).At present, we have the vendor-centric BPM market which we want to turn into a customer-centric BPM market (where the business will be the main customer). How? I think, by architecting BPM. In other words, we need a commonly-agreed BPM reference model and some BPM reference architectures. (This is a way by which W3C manage the evolution of HTML.)Thanks,AS

  4. You make some great points as ever. Naming things, or trying to describe something in a short sentance often causes problems. Why? It shouldnt, but it doesn because no sooner do you make a good description of something, then someone will say "hey, but its more than that, you need to add in x y and z". This is because vendors and marketing people want to sell everything they can about their product. However, by doing this, it just makes things too complex or simply overwhelming to people outside of the sector….Lets keep things simple!BPM for sure (from the vendors point of view at least) needs to take a few steps backwards before it can move forwards. Too much has been made of the designer and the BA role, so much so that BPM is becoming too restrictive. (Lean is another example of BPM restrictions) For me, this is vendor centric BPM and not customer centric BPM. Often businesses will buy into BPM only to be dissapointed becuase the platform doesnt deliver what it said on the tin, and thats usually because of restrictions placed by the designer, and the way we work with a particular BPM tool…A further problem that BPM needs to step back from, is marketing as a complete enterprise wide solution. I know this is true, but as soon as these words are mentioned, business decision makers start looking at their budget, worrying about cost, defining so many processes, getting other departments involved, other geographical locations, implementation timescales, maintenance, training etc. etc. This would turn off even the bravest of decision makers….BPM needs to connect with business at a departmental level to be understood….I have read a lot about standards for architecting BPM. I dont agree with this at all. I know standards work well(ish) with HTML but these are completely different areas. HTML relies on other companies products to be displayed and executed, I dont foresee a BPM vendor that says "yeap, use our platform and have your process delivered and executed by a third party provider"…The reason being is that, like with HTML, your BPM solution becomes dependent on its success via something you potentially have no control over. Lets look at HTML, it renders differently in browsers, so much so that web developers spend an age fiddling and testing style sheets ensuring their website displays the same in all browsers. We also see that such standards stiffle innovation, hence we have Silverlight and Flash for delivering RIAs, not HTML….This would be the same for BPM if standards were brought in, however, far worse, as BPM will be far more challenging than simply rendering display content to a screen. This kind of move is the bloating of BPM. BPM doesnt need standards in this way, BPM platforms and vendors need to ensure integration, integration integration. If your BPM platform isnt flexible enough for you to integrate with other LOB applications, data centres or BPM platforms, then I suggest you have chosen a poor vendor, do not blame BPM or lack of standards for this….The quest for the "designer" is the downfall of many BPM implementations, becuase it limits the potential that BPM can bring. Lets empower developers again so they can implement intelligent processes based on the BA, and then lets take this further and empower users of the system to define the process. BPM needs to be more flexible and adaptive, and the only way this will happen, is by stepping backwards, ditching the traditional designer and then moving forward…

  5. @Dave – your history is a bit off – there were no "BPMN vendors" at first – BPM software vendors adopted BPMN as a way to better describe the processes they were building. I was at Lombardi when the decision to adopt BPMN diagrams for processes was made. BPMN was adopted by vendors because it helped address an IT-business understanding gap. BPMN isn’t just trumped up workflow, but I can understand how it might appear to be that. I mean, I can see how someone would say the same thing about UML, but that wouldn’t be a fair characterization either. I do agree however, that BPM is separate from the "technology du jour" – it needs to take advantage of the mix of tools and methods that seem most appropriate at the time and situation one finds oneself. I found @Andrew’s comments to be particularly interesting (e.g. stepping back from enterprise wide positioning, and integration)

  6. Theo, I think the most important concept in all of this is that whether anyone wants it or not, there is a "blurring of the lines" between a number of different software segments. I’m specifically referring to the division of the market by technology, not by the problems companies are trying to solve. There is a substantial amount of overlap between CRM, ECM, BPM, ACM, KM, and a variety of other technologies, so it’s only natural that we start to see this collision and convergence. I for one am very excited by the prospect as I think the potential energy of these combined solutions is far greater than any one. Check out my blog post on this topic here.I especially like the characterization of this new world as a Chimera. Great way of looking at it, although most images I’ve seen of chimera’s have been pretty scary. :-)@Andrew, I’m in agreement with you on the quest for the designer, but only to a point. What I think we need to do is stop focusing exclusively on one or the other and find a balance. There are things that business analysts and perhaps more importantly business owners and users need to be able to do with any solution. Prioritization of work, adjustment of goals, personalization of their workspace are just a few, and all need to be able to be done without intervention from IT. But we can’t ignore that we’re talking about complex systems and that there needs to be significant tools for IT to deal with the complexities of the systems, for example deep integration that a business user often can’t or shouldn’t understand.Back to the core concept though, I’d love to see more cross-segment analysis of business problems. What does CRM bring to the table versus BPM? When do you need a full-blown ECM system versus a basic content system? And when we look at specific business problems, e.g. . life insurance underwriting, what technology components are best suited to solving the problem (considering that underwriting has content, process, rules, cases, etc.)?Great start to the discussion!

  7. Seems to me that there is an appetite to do something about it, it’s how we move forward as a group of people, agnostic of who we ‘serve’ (vendor, practitioner, analyst)Roundtable anyone ?

  8. Theo,good thought provoking post.One of the big problems I have with all of this is so many people wanting to name this ‘new’ beast. Part of the problem we have with ECM, BPM, CRM, KM, MDM et al is that the names are too restrictive and there’s a degree of overlap between all of them.As @andrew says, integration needs to be the key to how this adaptive/dynamic/unstructured (delete the ones that don’t apply) case management is going to evolve. I see this new animal as being about delivering a set of services – services around data and information, services around process, services around the user experience, services around the customer/citizen experience and so on. I’d like us to concentrate on how we make sure the integration between these services is effective.I agree with @Tom about the analysis of the business problem. In my service based model that allows us to decide the level and complexity of the services required e.g. around unstructured data.The other key point in all of this made by several posters is that we need to keep this simple and use business language to describe it. Some of the other TLAs have made themselves too complicated for our customers to understand.Really keen on your idea of some kind of a round table and happy to contribute from am SI perspective.

  9. The "next BPM" is not likely to be called BPM, because that term is already out in the field. In your blog post you mentioned "Adaptive BPM" and I think the trend is definitely for "Adaptive Something", but use of the BPM term will cloud the issue.BPM, as it exists, will continue to be useful for what it works for: routine work which can be predicted in a Taylorist / Scientific Management way. The real gains for the new era is going to be support of knowledge work, which can not be reduced to predetermined pathways, but will ALWAYS be something that human intelligence can have an edge on. Because of this, I think the new ‘BPM’ is going to be Adaptive Case Management".

  10. Hi Theo -Great post. We – Forrester – completely agree. Connie and I have been talking about this for a bit now and concluded that it’s not the name that we need to focus on, but the business case and business drivers that should illuminate the future path and direction for BPM.I’ve been pretty heads down over the past few months with our upcoming BPM Wave – evaluating the Top 12 BPM suite vendors and I’m definitely seeing significant change. But most of the changes are driven by what I see as the “BT shift” (i.e., more emphasis on shifting power and ownership for technology innovation to the business) and the need to manage business much more dynamically. This is really why customers are demanding next generation CRM (and next-generation packaged apps), not to mention the whole host of other dynamic and social capabilities for BPM.Ultimately, BPM will morph into something akin to “dynamic business management” – a discipline and methodology that allows companies to respond more rapidly to changing marking conditions.

  11. The problem with being late in commenting is that I may end up repeating most of what others said. Or I could fake not having read any of previous comments :)Good thing is there’s no one arguing against the fact that we’re indeed in for a change. So, here’s my vote too, in favor!!!What I found interesting is that all of us, while agreeing to avoid jargonism (the premise of Theo’s post), end up throwing some names in. There just doesn’t seem to be an easy way to convey what we mean without using a jargon that comes with a definition. It’s much easier to append Dynamic, Adaptive, Social, Clouded, etc to the terms BPM or Case Management or Biz Management to convey our PoV. So there goes the cycle…, but that’s inevitable in my opinion.@Tom ended his comment – "a good start to the discussion". So, let’s make something out of this, can we?When I posted on my blog about Convergence ( ), "BPM" ended up in brackets in my reference to the ecosystem. What I wanted to convey was a plain fact that all those technologies and domain principles / disciplines are means to get the businesses what they want – and a better synergy is expected among them all. It’s not important what we end up calling these complimentary combinations.Businesses want to get more Agile, more responsive, more efficient, more customer-oriented, and eventually want to earn more with better profitability while keeping the customers happy. They expect their departments, systems, functions to be more synergetic, and that’s where technology should help. BPM came in with that promise and I don’t see *that* changing. With collaboration tools, social networks, cloud etc, more technologies have become available and what’s important is that when faced with a problem, our customers are able to use these technologies with lesser constraints and more synergy. That’s what we should focus on and that’s what I emphasized in my post as well. Synergy!

  12. CRM, BPM and ECM should be a single silo. The problem with the generic term for BPM is that it covers so many different ways of implementing systems that essentially manage processes. For example a structured BPM map based system (take the old PC workflow, or eProcess from FileNET) deals with Business Process Management, but yet so does standard Case Management tools. They just deal with processes in a different way, and yet both get lumped together as BPM and yet both are very very different. This is fine for us in the industry who knows the technicalities of all of this, but from a business point of view, its confusing and very easy to see how solutions are missold or businesses simply choose to ignore “BPM”.

    I personally am all for ditching the silos, having a single platform that delivers CRM, BPM and ECM capabilities in a highly adaptive fashion, but after 20+ years I find myself describing such as solution as “it’s CRM, BPM and ECM all in one platform”…See my point? At workFile we termed the platform as @WE (Adaptive Working Enviornment) simply to try and get away from the whole silo mindset, and to add a bit of distnace between what we are trying to do compared with the typical implementations out there (which focus more on silos)…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s