We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

What percentage of process definitions does BPMN cover and how do you define the rest?

Vote 0 Votes
A question suggested by Max Pucher as a follow up to this question, What percentage of process definitions does BPMN cover and how do you define the rest?

9 Replies

| Add a Reply
  • If you want to only count processes that will make sense to business users in BPMN...a small part. BPMN is great for defining technical process concepts and terrible as a tool for communicating with process stakeholders (hint: everyone is a stakeholder of business processes). BPMN is a great way to keep end user expertise out of process capture and improvement. Great BPMN involves everyone and complexity works against involving everyone. BPMN has its purpose, but not for the majority of processes.

  • What percentage does it currently cover, what percentage could it possibly cover, or what percentage should it cover? :)

    Variations on this question really change the nature of the discussion. Current coverage is very small, relatively speaking. Possible coverage is very large (most things that can be programmed can be represented in BPMN diagrams, if you include implementation details that most BPMN software packages would supply - ie, not a modeling only solution like Visio).

    As to what percentage it should cover... it doesn't matter really. As a business, I only care that I apply it to the right processes, I don't necessarily care about the overall percentage/penetration into my business. I might start to care at the point where BPMN is being inefficiently applied to processes that don't provide enough return on investment. (Presuming that I am able to start with high value processes first).

    Also, what percentage *should* be covered also depends on what other tools your organization has at its disposal. Someone who owns Max's software might come to a different answer than someone who owns Christopher Taylor's, vs. someone who owns IBM BPM, etc. (Not to mention tools that are potentially completely outside of BPMN, like an ERP system or a CRM system).

    2 cents...

  • From my experience BPMN covers most workflow concepts. Where it falls short is in the area of dynamic activities.

  • Despite all the criticism around BPMN it actually or somehow become a modeling standard meaning that this is the language companies use to communicate. When a company adopt wide open a standard and stick to it people figure it out out to work around deficiencies.
    I have experience modeling processes on EPC or with IDEF in the begging of the 90's and companies still use it, despite not be prepared with the evolution of process mapping.
    The major problem with BPMN is the never delivered interoperability (that's one of the main reasons BPMN was created) and translation into BPEL in order to automate processes on the fly.
    Try to draw a model on a so called compliant tool and import it to other standard compliant tool. You will not get the same model and information is lost.

  • Thanks for picking up the question. The way it has been phrased it could be misunderstood and I think that at least Scott Francis interpreted it that way. I was not asking what percentage of a companies processes could be described by using BPMN, but how much of an ready-to-execute process could be done in the BPMN notation.

    For example, if you spend 2 days drawing a process in BPMN, how many more days with other tools do you need to actually have a process that is executable by users. With that I mean all other definitions such as rules, data definitions, forms definitions, content definitions, any kind of scripts or code that put data into documents and also back-end data interfaces, while those will in most cases be reusable.

    I am trying to discuss that if anyone tries to claim that BPMN allows non-technical people in business to define processes then these would have to be usable AS-IS without further technical work. Additionally it would mean that those same business people could modify the process themselves at RUN-TIME using BPMN. And yes, cited as the all-in-one standard it should allow to take a complete process definition from one product to another and it would have to be executable with no further work.

    BPMN fails in all these areas. There is little benefit in JUST drawing a process flow. One has to define all the other elements that go with it and make the process actually what it is. BPMN is thus in most cases one part of the input to a process programmer. In the best cases the BPMS executes the BPMN model and offers all the other functionality without coding, but still way to complex for a non-technical analyst and certainly for a performer.

    One of the ways to allow business people to utilize BPMN themselves is to provide as many reusable process resources in libraries. Users can select data elements and drop them into forms and content to be executed in certain tasks. Defining task dependencies is a lot more logical than drawing BPMN flowcharts. Assigning tasks to events on the fly is easy as long as one doesn't have to fit it into a rigid flowchart.

    BPMN (or any other flowchart notation) can be a practical part of a complete process definition and covers around 20% of all the definitions that make a process executable. Given the right user interface that can include adaptive processes, where business users actually make changes to the process themselves. BPMN becomes one of the views of the process definition and one can link all other definitions into it as well with a few enhancements or add-ons to the BPMN notation. None of these are portable and as Alberto points out that makes the notion of a standard little compelling. For adaptive processes BPMN is just used as documentation how the process was actually defined on the fly by business people without even looking at a flowchart.

    It is amazing that there are all these wonderful claims about BPMN and there is little talk about how this actually pans out in the real world.

    • Max, which tool was it that doesn't use BPMN but still provides this business-user flexibility AND interoperability with other tools at execution level detail?

      "I am trying to discuss that if anyone tries to claim that BPMN allows non-technical people in business to define processes then these would have to be usable AS-IS without further technical work. Additionally it would mean that those same business people could modify the process themselves at RUN-TIME using BPMN. And yes, cited as the all-in-one standard it should allow to take a complete process definition from one product to another and it would have to be executable with no further work. "

      I'm sorry, was someone making these claims? is there a reference we can point to, to understand who is taking up the side of the straw man you presented? I mean, it is an impassioned argument... but against whom?

  • As always (on this topic, anyway), I'm with Max.

    In our experience, flowchart-style process definitions in general (including, but not limited to, BPMN) have value, but primarily in specific use cases. Generally speaking, we find flowchart-based models useful for short process segments that include looping, such as tight approval cycles.

    Anything more involved or complex begs for another model altogether. We use a time-driven model, not unlike what you might be used to already if you tend to describe your processes using Excel or MS Project.

    Every standard comes with baggage. Why live with that baggage when your standard addresses such a small subset of the overall problem it's intended to solve?

    Worse yet, as Christopher suggests so eloquently above, BPMN may actually be making the problem worse by "keep[ing] end user expertise out of process capture and improvement." I wish I'd said that!

    Ultimately, the value of a standard can be measured in the demand it generates. Nobody is going to buy a vacuum cleaner with a 12-pronged power cable: it does them no good. In my experience, the demand for BPMN compliance in the marketplace is only slightly higher than that.

  • I also agree with Max in one respect -- that business users should be presented with "process resources in libraries". When these are used, they shouldn't require any significant technical details to be specified before they work. Where I differ is where these would be used. I think that the "flowchart style" of BPMN can be used with such pre-configured libraries of activities. I recently gave a talk that describes how our Automation For Analysts tool uses this approach in order to provide a tool that is truly usable by Analysts and yet still results in executable processes.

  • Depending on the interpretation of the question:
    - BPM coverage by BPMN: I don't have precise stats on this, but my general opinion is that models (any kind and for every purpose) should be self-contained, complete and consistent. This doesn't mean A SINGLE MODEL (and modeling language) should cover all aspects, but a bunch of them should cover all the perspectives. For instance, sticking to the business specs level, sometimes is useful to complement BPMN with BMM (Business Motivation Model) for high level reuirements. It's intuitive and close to the business way of thinking. Do you use it? It's a standard, but I think it's quite neglected.

    - In terms of accessibility of BPMN to business users: this is actually hard, and as I always claim I trust much more a prototype-based discussion that a diagram-based one, when trying to validate a process with the business stakeholders.
    That's why we promote quick prototyping and complete executability within our tool WebRatio (we have stats showing the different levels of understanding of diagrams and apps).
    Executability (or merely implementability in some cases) is another property I think it's crucial for models.
    That's why I think some of the BPMN 2.0 notations (choreography, orchestration) will never get to wide adoption.
    To this regard, I think instead BPMN may need additional integration based on other modeling languages for describing the concrete part of the executability of tasks. In our case, we integrate with the WebML notation (under standardization within OMG in these months, with the name of IFML), which lets software analysts specify the details of the user interaction in the applications, enabling implementation down to the deployed app.
    Again, showing "a running app is worth a thousand diagrams"!

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT