Resolved
4 votes

As we haven't discussed BPMN in awhile on the forum, how important do you think it is to know BPMN to fully understand BPM?

Tuesday, November 24 2015, 09:50 AM
Share this post:
Responses (19)
  • Accepted Answer

    Tuesday, November 24 2015, 09:55 AM - #Permalink
    Resolved
    5 votes

    Not important at all, I know people that understand BPM very well but don't know BPMN. I know people that know BPMN but don't understand BPM.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 09:59 AM - #Permalink
    Resolved
    4 votes

    - 67% important.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 10:01 AM - #Permalink
    Resolved
    4 votes

    Not important. However... It is of course great that there is are some standards (for silicon based lifeforms as BPMN sits in that techie corner) but modelling (in order to ... ) is just a part of process based management. I do strongly believe however in a very simple 3 layer (or so max) representation of your business processes, from a value chain type of level 0 to a bit more detail. As this can act as a fundament for anything else (e.g., attaching models for the sake of automation for example, but also other artefacts). This is missing most of the times: In other words, context is missing...

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 10:12 AM - #Permalink
    Resolved
    4 votes

    Not at all. If it were then no-one would have fully understood BPM before BPMN was invented, and that lacks a certain ring of truth.

    This is part of the reason why you could say that Effektif’s kind of ‘simplified workflow’ automation uses as little BPMN as possible, instead of as much as possible (i.e. all of it).

    Of course, the only thing worse than BPMN is all of the alternatives :)

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 10:22 AM - #Permalink
    Resolved
    5 votes

    BPMN matters for the same reason that standards always matter: it provides a common language for describing problems and solutions. And helps to mitigate the extra-ordinary ability of carbon-based lifeforms for miscommunication.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 10:22 AM - #Permalink
    Resolved
    5 votes

    BPMN is for n00bs. When I talk to CxO's, I always use Petri nets (and C-nets for the slightly more advanced).

    Joke aside, BPMN is just a modelling language - I think it can give you a formal framework to better understand BPM, but it's not that important.

    • Patrick Lujan
      more than a month ago
      Ah, I love it when you talk dirty.
    • Emiel Kelly
      more than a month ago
      Still love petri-nets too, because they show 'the dynamics of execution' a little better than flat bpmn
    • John Morris
      more than a month ago
      The animated process histories which are available in several process mining products are based on mined Petri nets generated from logs -- and the results are marvellous for managers wanting to understand bottlenecks etc.
    • Emiel Kelly
      more than a month ago
      With mining you can see bottlenecks, that's not the same as understanding them. Mining is indeed more dynamic, but only shows the symptoms of process performance
    The reply is currently minimized Show
  • Accepted Answer

    Geoff Hook
    Geoff Hook
    Offline
    Tuesday, November 24 2015, 10:28 AM - #Permalink
    Resolved
    3 votes

    BPMN is not important at all in respect to understanding BPM, BPM is an approach to managing the organisation and its customers/suppliers. BPMN can have a role in succesfully implementing a BPM strategy, as others have said you need a common language that can accurately and unambiguously be used to define and communicate your process plans, this is where BPMN has a part to play.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 10:53 AM - #Permalink
    Resolved
    3 votes

    In accordance of the 1st law of BPM (see ref1), at present there is no way to "fully understanding BPM". In this situation, knowledge of BPMN is useful if

    1) there is a clear explanation that (as Walter said) no context thus no guarantee that BPMN will automagically solve all your BPM problems

    2) it is overcomplicated

    3) you will need to make your own subset optimised for your current needs.

    Thanks,

    AS

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 11:51 AM - #Permalink
    Resolved
    5 votes

    There's a sales angle to the question of the importance of BPMN to understanding BPM.

    Without BPMN (or other process language) selling a business process project has a high likelyhood of being perceived as just selling "a talk shop".

    And talk shops cannnot be sold.

    Let's explore this.

    As multiple people have said in different ways "a process language is important in order to support human discourse around business process". (OK, not quite as formally . . . )

    We could leave this discussion at this point. But I have a problem.

    And that is the gap between the "conceptual talk shops" and "in-production software". The gap in time, misunderstandings, escalating costs and project failure between business need and production software is scandalously wide. I believe that just saying "BPMN is too technical for business people" is too easy -- even if the statement is true on the face of it.

    Process automation is about building software artefacts that help humans do more work with less effort.

    Unless one has executable software as a project objective in the near future, why bother with the project in the first place? And executable software probably means BPMN (or equivalent) is involved somehow. BPMN models are not so hard to understand and can be used effectively with hands-on business execs.

    BPMN provides the discipline of an concrete, business-useful end-point for any process programme where the mantra is "make a positive impact fast".

    Don't hide your light. Embrace the technology. Sell the heck out of it. Help your customers make a difference.

    Like
    1
    • Patrick Lujan
      more than a month ago
      "And that is the gap between the "conceptual talk shops" and "in-production software". The gap in time, misunderstandings, escalating costs and project failure between business need and production software is scandalously wide."
    • E Scott Menter
      more than a month ago
      "BPMN provides the discipline of an concrete, business-useful end-point for any process programme". Sure. But so would any cleverly designed model. Let's not confine ourselves within the limitations of BPMN just because that's what happens to be best known at this moment.

      As an aside: your experience is different than mine, because I've found that BPMN models are indeed hard to understand unless you've spent considerable time working with them, and that business managers do not relate to them well at all. I may be working with a less enlightened crowd. :)
    • Patrick Lujan
      more than a month ago
      1) You're working with a less enlightened crowd ;), 2) don't forget "we execute what we model." If I do a good process model in BPMN and slurp it straight into the process designer of my process engine I'm good to go, 3) a LOT of the big boys want to see, use BPMN. If they didn't, Bruce Silver wouldn't have been teaching the class, and teaching it well, all this time.

      Don't forget the sales angle.
    • E Scott Menter
      more than a month ago
      Ha! If there's one thing I try hard never to forget, it's the sales angle. I have two kids in college. :)

      There are two issues here. One is the idea of modeling in one place and doing "process design" in another. That's an unnecessary extra step... but out of scope for this discussion, I think.

      Also, I've noticed that project managers, for example, who might well be expected to use something not unlike BPMN for their work, do not. They use MS Project, or spreadsheets, or whatever. That's not because they're not bright enough to use a flowchart; rather, it's because the flowchart is simply too complex and inflexible for what they're trying to accomplish. And, heck, anybody can look at an MS Project diagram and see what's happening.

      I can share that as a CIO, if I was discussing process with a line of business manager, the only time flowcharts would make an appearance was when that manager was paying a process analyst to create and interpret them.
    • John Morris
      more than a month ago
      Nice comments -- and LOL "sales angle" and "executable" . . . and I agree that BPMN is only one of multiple possible process modeling options supporting business dialogue.

      Lurking in the background here is a question of "what do we model". A lot of the complexity (i.e. "unreadability" for business or anyone) of process models are the SOA-related deployment artefacts. This is the issue addressed by Volker Stiehl in his book "Process-Driven Applications with BPMN", which has been referenced here in previous discussions. A BPM project will look different if it is only about business workflow and logic. And then one can likely answer the current question differently.
    • Patrick Lujan
      more than a month ago
      BPM and SOA go together very well. Your process patterns change though dependent upon how you want your interaction to work. Some people want everything to go through the ESB or MQ. That's do'able, but it's very complex, hard, takes time and money both. Further, shouldn't always be done that way. I'm thinking Fowler's enterprise integration patterns here, but it should, does work differently based upon whether your exchanging info via the transport or operating within the stack and, more importantly, when you should do it one way versus the other.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, November 24 2015, 11:58 AM - #Permalink
    Resolved
    3 votes

    Not important at all. I use other techniques which, I believe, produces superior results. Does this make me wrong if I do not conform to someone else's rules?

    References:

    1. http://timbryce.com/
    • E Scott Menter
      more than a month ago
      It could. But in this case, probably not.
    • Patrick Lujan
      more than a month ago
      It depends. For technical people new to BPM it is a good way to start looking at, thinking about processes through a certain lens.

      It - BPMN - is another tool in the toolbox.
    • E Scott Menter
      more than a month ago
      Ah, Patrick, I understand that view from where you are, on the implementation end of the stick. But those of us on the vendor side have, I think, a responsibility to look hard at making your experience as an implementer easier and more likely to be successful. Put another way, BPMN is a tool, but it's our job to create better tools.
    • Patrick Lujan
      more than a month ago
      My stick is the full monty, cradle to grave, inception to implementation. I like the process discovery, workshops, "understanding the problem" stuff up front. I like the use cases and BPMN in the middle. I like the 'taking a good process design, effecting and implementing a solid process definition' on the BPMS.

      I'm on the solution's side.
    • E Scott Menter
      more than a month ago
      Right, apologies, didn't mean to suggest you weren't doing all those things. It's just that from this angle we casually refer to that whole thing as "implementation". :) But of course you're correct.
    • Tim Bryce
      more than a month ago
      Question: What if the standard is wrong and we have taught it to impressionable youth. How do we debrief them?
    • Patrick Lujan
      more than a month ago
      @Tim, we got to said, same "impressionable youth" and ask "How'd that work for you?" If anything approaching "not so much," then we elaborate and say "Let's take a look at that, shall we?" Modeling notations, methodologies, SDLC, technology mean bupkus if we don't properly frame the business problem and execute on that.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 12:52 PM - #Permalink
    Resolved
    3 votes

    Wow, I have to admit, I expected to show up and have to defend my long-held position that BPMN is non-essential, not only for the "understanding" of BPM, but for its implementation as well. So, as that position doesn't seem to be controversial enough to bother with, I'll take this one: flowchart-style diagrams in general are a relic. They're too hard to change, and too hard to understand. They provide virtually no information related to efficiency. They require the builder to make complex and explicit decisions about execution (and, specifically, parallel execution) that are better left to the computer. Critical path identification in a flowchart is tricky at best.

    Time to leave flowcharts behind. I'd tell you what to use instead, but then this would be a commercial rather than a polemic.

    On another note: I am thankful for many things in my life, among them the opportunity I have on a daily basis to talk about big ideas with people smarter than I. This forum is a part of that, so thank you BPM.com and Peter for providing it, and to all of you for the conversations. Have a great Thanksgiving.

    • Tim Bryce
      more than a month ago
      I have been using flowcharts using ANSII symbols for years. It works and can be easily modified (at least in my world), but mine shows both process and data flow, not just one or the other.
    • E Scott Menter
      more than a month ago
      Right. My argument isn't that they're never useful for anything, but rather that they don't make a useful executable model (relying as well on my other proposition, that an executable model is the only one that makes sense when you're talking about BPM). A simple flowchart can be useful as a high-level communication device, but when you really start to dive into the details ("order business cards but not before the employee has been assigned a phone, office, and email address"), it won't keep up.
    • Emiel Kelly
      more than a month ago
      "an executable model is the only one that makes sense when you're talking about BPM"

      Not that models make sense there, but there is still a large amount of processes that are not executed with software. And that's also BPM to me.
    • Tim Bryce
      more than a month ago
      Emiel - You are absolutely correct. We've had business processes well before the advent of the computer.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 01:37 PM - #Permalink
    Resolved
    3 votes

    I came down reading, and as Scott said, was expecting to defend my position that BPMN is really useful, but not mandatory. But it’s done. So I will only tell you guys my vision from Latin America: we have several high-growth years, so we became very pragmatic. BPMN has been established as a de-facto standard? Ok, let’s use it. Tomorrow it changes to WhateverML, right, we'll use.

    I think organizations evolved from “use only standards” to “use what make me sense”. Now, what make us sense for modeling is BPMN. So, it is important? Well, it is not mandatory, but as an easy standard, it is a good fast-pass for people to get into the BPM world.

    I agree with Peter Hilton, innovative BPMS (Flokzu is another example), are “cutting” BPMN, keeping just the really useful and needed artifacts. In this other example (including a short video), a complete process is built in just minutes, using just a few BPMN artifacts. Probably it could be done by someone who's not a BPM expert.

    I sum, I break a lance for BPM: if it is simplified enough, it would tend bridges for the Small and Medium Businesses to massively adopt BPM.

    • Bogdan Nafornita
      more than a month ago
      I almost agreed with you, Juan, until that last paragraph.

      yes, a simplified enough BPMN will make more people "get it".

      Adopting it though into their business practices means moving to implementation and execution and, if I know anything about SMB's, it's that their proceses are more about exceptions than about rules. And that brings back complexity into the executable BPMN bit.

      Again, and this is a recurring theme - in my part of the world. And probably in other emerging markets too.

      I'd be interested if you relate to that kind of perspective, Juan.
    • John Morris
      more than a month ago
      Bogdan your comment perfectly captures the nexus of business culture and technology for BPM.

      If BPM and enabling BPMS products are to break out of a big organization, first-world "ghetto", if I may be permitted to use the term, then the issues you have raised (several times) regarding business needs in such demanding conditions will have to be addressed.

      So, does the inherent complexity of business life mean that BPM is doomed in emerging markets?

      I believe the answer is "no", if a BPMS can support fast model-driven build/execute cycles.

      Such a solution means "no round-tripping issues". And "what-you-see-is-what-you-execute". Then adding exceptions and richness to your processes can be justified. Incrementally. Every day.

      Hey, if this can be done in emerging markets, the most challenging laboratories for software, BPM technology adoption will be enhanced everywhere. (And OK, and not to harp, but I think the Stiehl approach is relevant here.)
    • Bogdan Nafornita
      more than a month ago
      Jonh, I do believe BPM has a bright future in emerging markets (otherwise I wouldn't do and enjoy what I currently do - which is the Stiehl approach here, in a country at the edge of EU). However I believe that an overly simplified approach does not bring enough value to make it compelling for SMB's.

      There's only so many Pinterests and Ubers and 1-minute pizza delivery start-ups this world needs.

      I am constantly reminded of that anecdote with a senior Googler explaining to an Indian the great Google Now feature of remembering where you parked your car so you can easily find your way back in a crowded parking lot. To which the Indian replied: "I jump off a train every day to get to work".

      I have many more from my personal experience - in a meeting in Bucharest, a shocked senior row of Western P&G'ers digging into the low diaper shipment numbers, discovered that mothers in emerging markets do recycle the single-use diapers by washing and drying them, thus reducing dramatically the cost per use.

      And I absolutely agree that an environment such as an emerging market is the ideal software laboratory: qualified and still relatively cheap workforce and ever shifting business and regulatory conditions. That's why I insisted in front of my partners to keep the business in this location and in a bootrstrap model: if we can succeed here, chances that we fail elsewhere are slim.
    • John Morris
      more than a month ago
      Bogdan: Love the P&G story!!

      And now we have a new version of the old maxim:

      "If you can make it in Romania, you can make it everywhere!!"

      Bravo!
    • Bogdan Nafornita
      more than a month ago
      it's not as dramatic and Romania might not be the absolute lowest business standard ever - for sure it's fun, but it's harmonized to EU principles in a lot of areas.

      :-)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 24 2015, 01:45 PM - #Permalink
    Resolved
    3 votes

    Conclusion: BPMN is not important for BPM. And even that on a forum where most think BPM is some kind of software ;-)

    Like
    1
    • Patrick Lujan
      more than a month ago
      I think that BPM *is* a discipline and a practice both. I also think that more often than not it is effected on a BPMS, operational aspects included. :D
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, November 24 2015, 01:47 PM - #Permalink
    Resolved
    3 votes

    Ouch... Who is going to tell Mr Silver?

    • Patrick Lujan
      more than a month ago
      He knows. It's a niche and he occupies that niche very comfortably, very profitably.
    • Emiel Kelly
      more than a month ago
      Oh, be aware there are still loads of organizations who like to model (in bpmn) their processes.

      Just to...mmm...just to.. Yes, just to model their processes.
    • John Morris
      more than a month ago
      BTW, Bruce Silver wrote the forward to Volker Stiehl's book (see my comment above on topic).
    • Patrick Lujan
      more than a month ago
      @Emiel, well I do like to model in BPMN but first with an agreed-upon, prescribed (not mandated), discrete set of patterns. Why? Again, it gets the delivery team to look at thing(s) in a different manner, context than they have previously and, once in that mode, we get the opportunity for re-usability.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 25 2015, 12:38 AM - #Permalink
    Resolved
    3 votes

    Bpmn is not a tool, a sales technique, or a religion. Its just a process language that many people and tools understand and use. Probably more than use your undoubtedly superior alternatives. If that has no value to you, you are free to ignore it.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 25 2015, 03:27 AM - #Permalink
    Resolved
    3 votes
    Wow, Peter, you definitely triggered something here, LOL.
     

    There is no issue with BPMN. There is an issue with using the proper stuff in the proper context. And BPMN (but also EPC say) is actually often used in the wrong context.

    For example: Using BPMN (or EPC) for communicating to a wider audience, is IMO pretty useless. Roger Tregaer wrote a nice blog a year ago covering the context of this area. The paragraph that caught my direct attention was:

    "Every organization should have an Enterprise Process Architecture (EPA), a hierarchical model of the first three levels of its business processes. Individuals processes in the EPA, and there may be hundreds of them, need only be identified as a single object (a box of some form depending on the graphic notation being used). The EPA model is about identifying relationships between processes, rather than the details of individual processes. Modeling the process detail is then undertaken on demand; it’s done to address a particular problem or opportunity. Therefore, detailed process modeling should be done as part of a process improvement project that has a very clear organizational performance goal."

     
     

    And I think that pretty much nails it. BPMN / EPC models should sit in the context of this EPA. But cannot or should never be used to visualize the EPA at the highest levels.

     
    @Peter: Next questions on using Swimlanes please? :-)

     

    The reply is currently minimized Show
  • Accepted Answer

    Maria Paz
    Maria Paz
    Offline
    Wednesday, November 25 2015, 08:24 AM - #Permalink
    Resolved
    2 votes

    BPMN is a useful standard, but it is notindispensable.

    It's useful to apply it because most people who use BPM know BPMN, so it's sometimes easier to follow the majority.

    When simplified, BPMN becomes more accessible but it's still quite complex. That's because processes ARE complex and BPMS that simplify too much cannot deliver the required functionalities. For example, Gateways are complex, but they're needed in most processes!

    Even though modeling is essential and it's the most visible part of a process, there are other fundamental parts, and as important (or more) than modeling: a good process engine that is scalable, safe, etc.; Business Intelligence that lets us improve the business, goodBAM (Business Activity Monitoring) that sends alerts when there are delays, smart Document Management, and so much more...

    References:

    1. http://www.flokzu.com
    • John Morris
      more than a month ago
      Good highlight on BAM, which is more important than people usually realize - and it's not just "fancy BI" either. As for making a BPMN-based process model as accessible and as simple as possible, being able to pull out business rules (e.g. via DMN) is probably one of the most important things to do.
    • Emiel Kelly
      more than a month ago
      I don't agree that modelling is essential, but BAM is. Knowing what's going on with all the cases that are currently in your process. That's what I would call essential for proper, what I'd like to call, case management.

      So BAM, that's waht I call Insight in a process. Really something more valuable than 'Insight by mapping'.

      But be aware; a speedometer is useless without a throttle or a brake, so by preference, only BAMify process indicators on which you really have influence and are able to act upon.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 25 2015, 10:42 AM - #Permalink
    Resolved
    2 votes

    Not important at all. However what is important before you begin the BPM journey is that users understand just how is the real world of work going to supported by the software. Build direct from their ideas in their language easy to change and UIs that deliver ease of use. All something old IT has failed to deliver over past decades so there are challenges to educate all involved.

    As for BPMN this will slide into history just as BPEL has. New approaches will disrupt the such existing complex and expensive tools to deliver on next generation requirements driven by BPM principles.

    The reply is currently minimized Show
  • Accepted Answer

    Sunday, December 13 2015, 02:23 PM - #Permalink
    Resolved
    1 votes
    Unimportant to understand any part of BPM, other than its history
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
26/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
221 Replies
26/09/2016
Bogdan Nafornita
209 Replies
26/09/2016
E Scott Menter
182 Replies
26/09/2016