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?
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...
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 :)
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.
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.
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.
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.
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?
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.
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.
Conclusion: BPMN is not important for BPM. And even that on a forum where most think BPM is some kind of software ;-)
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.
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...
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.