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

How big of a role does BPMN play in today's projects?

Vote 0 Votes
A question suggested by Chris Geier, How big of a role does BPMN play in today's projects?

18 Replies

| Add a Reply
  • Depends where you're starting from and what the goal of the project is really. BPMN can be used to enforce some rigor and discipline in your process modelling but if you're not looking to execute or do anything clever other than basic mapping then it's an overhead.

    Pragmatism wins when using BPMN, and the maturity of the organisation on it's approach to process.

  • I estimate 50% of the time I see it as mostly irrelevant or too detailed.

    Like Theo said, if you need to really capture the full logic to do execution, that's a different story. Depends on the participants and the purpose of the models.

    This reminds me of discussions years ago on the role of UML in software development. (And still somewhat today.) If you wanted the detail of UML as part of your requirements or specifications, or you were going to translate UML into code, then UML mattered. If you were just trying to communicate requirements and specifications and designs in general, it remained irrelevant for a lot of environments.

  • I feel that BPMN has become more of a non-factor. There are those out there that have learned it and find it very useful for how they do process. However with the proliferation of many other diagraming and modeling tools it has become less of a factor. I personally prefer a mixture of regular old Visio combined with a good process narrative. I wonder what is more conducive to sharing between IT and different levels of the busines, since that is going to be a real difference maker.

  • I think BPMN is critical when you want your model to capture the process in detail, leaving nothing to hand-waving vaguaries. Naturally this is needed when the process is going to have to execute, since computers aren't all that great at deciphering hand waving. But, in reality, people aren't as good at deciphering hand waving as they think they are. The problem is the classic one of false agreement. Without a precise process definition, the writer of the process and the reader of the process can think they agree, when they are actually envisioning very different things.

  • @Michael, even with the rigor of BPMN I've seen many cases of false agreement. Normally due to the fact that the business person doesn't have the same level of understanding of the BPMN palette as the analyst and is left to the vagaries of the analysts explanation.

    People will often agree with something they don't quite understand for fear of 'looking stupid'. I also wonder sometimes if the analysts have misunderstood the intention of some of the symbols available.

  • We use BPMN all the time in our projects, but we do a lot of process implementation projects, and it is a good fit for the tooling we use. Craig makes a good point about someone not understanding BPMN precisely - but at least BPMN has a precise definition - unlike the usual whiteboard drawings.

    I like to get on the whiteboard and build out the diagram and explain and talk as we do it. By seeing and hearing the build-out, there's much less chance of confusion about the interpretation. And when you're done, the diagram is actually accurate for someone who reads it "after-the-fact" if they know BPMN.

    Having said all that, BPMN is a means to an end. It isn't the goal, it is a tool. There are other tools and in the right time-place each one is useful.

    Whenever there is a standard there's inevitably a bit of back-lash against the standard from experts - almost as if it is a badge of honor to buck the industry standard. I say this knowing full well that I've done it before myself! But with experience comes a little wisdom and perspective and I don't hand out badges of honor for either obeying doctrine or bucking it. The badges of honor come for delivering great results.

  • The counterquetion would be: 'A role for whom?'

    And: 'Does it matter to anyone of it is BPMN or not?'

    We use a subset of BPMN and expanded it for resources, rules and data, only to find that it is virtually impossible to translate any of that to XPDL in a reusable manner.

    So it always plays a role but NO ONE asks if what we do is BPMN because no one sees it, and if they don't care what it is called.

    Is there a benefit that we use BPMN? NO.

    Is it a decising factor when we get chosen as a vendor? NO.

    Can business people work with it? NO.

    Do they want to? NO.

    Industry standards are for those who either lack better ideas or who want to say that those 'innovative types' are dangerous. Which they are but not for the customer.

    I would like to know what the promise of BPMN is, because it certainly isn't reusability.

    • Max, business people can work with BPMN.

      There are simple symbols that business people are used to working with, analogous to flow charting symbols that are more than 50 years old. Perhaps the problem is that one has to find and install a BPMN stencil to use it in Visio, and the shapes aren't included by default in MS Office's shape libraries.I agree that the value proposition for a business person to switch symbology or the sake of a standard is nebulous, but there's supposed to be more to BPMN than just high-level symbols. I don't know much more about the detailed symbols other than they exist, but I see generally where it's going.

      Your argument about "industry standards" is shortsighted and narrow. This country is built on industry standards. A great example: if railroads were subject to the whims of their owners, or bridges had non-standard heights, could you imagine the additional costs of moving tangible goods around the world? Why shouldn't we standardize on a modeling notation, whatever it may be, so that we can move concepts and ideas around as easily?

      Perhaps the scope of BPMN is too broad, but you can't objectively argue that coming up with a commonly used set of modeling symbols is not wanted, unusable by business people, or for people who "lack better ideas".

      • John, the reality is that business people do not use BPMN nor do they want to. It is an illusion. What would be the benefit? What the define is not executable or usable! the BPMN flowchart is just at best 20% of all the information needed to actually execute the process and therefore quite useless.

        I always hear the same things about standards ... it is good ... look at our railroads. Business processes are not about connecting America's East and West but about connecting people and when they do they do not want to be restricted and only follow the railroad line.

        People use communication and therefore business processes are not manufacturing or building railroads. They are about perceptions and innovation and thus things that can't be standardized.

        All in all we need to give people the ability to define those processes as they work (DESIGN BY DOING) and not have to go through the immense effort of flowcharting and then ENCODE the other 80% to make the process usable.

  • Great points by Craig, completely agree. To be effective all parties involved need to understand BPMN, and it has a learning curve. The more clear the diagrams and documentation the better.

    This is exactly why the BPM tool should separate concerns of designs from details of implementation. So all parties don't need to have the same level of understanding. For example, a business analyst may not know or want to know which url of the datastore she is using to retrieve information.

    The implementers want to know this url and all other parameters of the datastore. Or you might need several datastore for several kinds of information.

  • BPMN describes only the activity flow logic, nothing else. It does not presume that modeling other aspects of the process is unimportant, but just outside the scope of the standard. Most BPMN tools model things outside of BPMN as well, but to say that this is a deficiency in the standard is incorrect (and when tool vendors say it, it is just cynical disinformation). Second, BPMN is not just for execution. The Descriptive and Analytic process modeling conformance subclasses of BPMN 2.0 include NO execution-related details whatsoever.
    The value of BPMN is it is a tool-independent language for describing the activity flow logic in a diagram. Yes you can do the same thing using a tool-proprietary notation, supplemented by a couple hundred pages of supporting documentation. If you are a BPM vendor or consultant that depends on tool lock-in, lots of billable hours, etc., BPMN maybe seems like something to attack. On the other hand, if you want a greater portion of the info from those SME interviews to be captured in a diagram, and the meaning of that diagram to be precise and tool-independent, you might want to consider BPMN. Yes BPMN requires a couple days of training to use it properly. A Visio sketch plus 10,000 words of text documentation can capture the same information with less training, that's true. That's always an option.

    • Bruce, thanks for conforming that one needs a PROJECT TO IMPLEMENT what has been defined in the BPMN diagramm. BUT because the diagramm does not contain information about the other 80% of detail that is needed to make the process usable BPMN is really not much of a huge benefit.

      The future is that business people actually define the process as they DO IT. As they use it practically it gets refined (adapted) over time, but can still be changed at any point in time as needed by the business user without every looking at a diagram, BPMN or not. It might be helpful as a perspective, but that is all.

      Apart from the fact that BPMN leaves 80% of process detail out, flowcharting human service processes dramatically reduces service variety and therefore drives up cost by causing FAILURE demand (John Seddon). So the whole effort of creating flowcharts is ill-conceived from the outset. Thus BPMN is utterly irrelevant in improving business processes!

  • I haven't met Max, but darned if I don't think we'd get along great. "The whole effort of creating flowcharts is ill-conceived from the outset." Wish I'd said that!

    BPMN is simply not a factor in the automate-measure-improve cycle of business process management. Customers don't ask for it (at least, mine never do), and don't understand it.

    Among its other flaws, BPMN doesn't account for time, arguably one of the most important factors driving process improvement in the first place. It doesn't make processes easier to understand for the business; indeed, in my CIO days, if I asked the business to describe their process, I'd be a lot more likely to get a list of activities ala Excel or MS Project than a flowchart of any kind.

    We tolerate the limitations imposed by standards because they offer something in return. I can plug my electric shaver into any outlet in the US and reasonably expect it not to burst into flames—now that is a valuable standard. BPMN offers nothing like that sort of useful upside as compensation for the restrictions it places on the creativity, flexibility, and agility of the business.

  • At the risk of disagreeing with some, BPMN is a useful notation for IT and perhaps knowledge workers (if it is limited to a subset of its capabilities). BPMN is NOT a language to be consumed by business process end users. Look no further than the tool UPS talked about in the APQC Frameworks study to see that simple notation wins the hearts and minds, not complex notation.

    Especially as we continue along in the internet age, 'Dead Easy' is the mantra of what wins peoples hearts, minds, and eyes. The things we capture, store and communicate need to be geared for the audience, not the expert.

    I write about this here: http://bpmforreal.com/2011/11/16/seven-deadly-sins-of-bpm-6-making-it-hard-to-understand/

    Another great piece on making it easy by a guest blogger: http://bpmforreal.com/2011/06/21/business-process-and-behavioral-economics-bpm-behavioraleconomics/

  • Christopher, it is understandable that you flog your own version of flowcharts as an alternative to BPMN, it is just not very convincing.

    As Scott points out: 'What is it that business people ask for?' It is not an APQC framework. Simple notation only wins with someone who hasn't seen anything else or thinks that flowcharts of some kind are a must. UPS leaves even more process relevant information out than BPMN and it couldn't be used to actually execute some form of process ... oh, yes ... UPS isn't executed, it is just documentation.

    Business people want as much autonomy as possible, guidance where appropriate and verification where a must! No kind of flowcharts provides that and at the same time ensures top-down and bottom-up transparency for real-world, as-is executed processes.

  • It was rightfully pointed out above that BPMN is the best option if one needs to describe a process very precisely yet there are alternatives when it's not the case.

    But we never really know how a project would develop - shall we stay at descriptive or semi-formal level or go further. From this point of view, BPMN has unique advantage: one may use a small subset to create very intuitive yet not too strict diagrams or go right to the end and depict an executable process diagram.

    With any other option one would sit on two chairs. Two sets of competencies to gain is lesser inconvinience; two sources of process truth is more dangerous.

    Another common complain is the complexity of BPMN. But the source of complexity is business. BPMN is complex indeed but it has just right amount of complexity that matches the complexity of the business.

    Getting back to the orignal topic of BPMN role in today's projects, it's a function of particular vendor's or provider's offering. The services that our company provides and tools that we use depend on BPMN heavily hence the role of BPMN in our projects is high.

    We don't get involved into a project before until a prospect has passed the formal three-days BPMN training. We came to this approach by trials and errors and it works pretty good for both parties. Not only we are on the same page - after passing the BPMN training the customer gains a lot of trust to our capabilites which speeds up a project dramatically.

Add a Reply

Recently Commented On

Monthly Archives