BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, November 24 2015, 09:50 AM
  4.  Subscribe via email

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?
Craig Willis Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer

- 67% important.
Common Sensei at Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Walter Bril Accepted Answer

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
[i]modelling (in order to ... ) is just a part of process based management[/i]
. 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...
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Peter Hilton Accepted Answer

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 [url="http://www.effektif.com"]Effektif[/url]’s kind of ‘simplified workflow’ automation uses
[i]as little BPMN as possible,[/i]
instead of as much as possible (i.e. all of it).


Of course, the only thing worse than BPMN is all of the alternatives :)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Tim Stephenson Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Bogdan Nafornita Accepted Answer

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.
Managing Founder, profluo.com
Comment
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
  1. Emiel Kelly
  2. 1 year 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.
  1. John Morris
  2. 1 year ago
Still love petri-nets too, because they show 'the dynamics of execution' a little better than flat bpmn
  1. Emiel Kelly
  2. 1 year ago
Ah, I love it when you talk dirty.
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Geoff Hook Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7

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



References
  1. http://improving-bpm-systems.blogspot.ch/2015/07/laws-of-bpm-business-process-management.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
John Morris Accepted Answer

There's a
[u]sales angle [/u]
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
[u]being perceived as just selling "a talk shop"[/u]
.


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.
[u]I believe that just saying "BPMN is too technical for business people" is too easy[/u]
-- 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.


[u]Unless one has executable software as a project objective in the near future, why bother with the project in the first place?[/u]
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.
Comment
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.
  1. Patrick Lujan
  2. 1 year 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.
  1. John Morris
  2. 1 year 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.
  1. E Scott Menter
  2. 1 year 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.
  1. Patrick Lujan
  2. 1 year 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. :)
  1. E Scott Menter
  2. 1 year 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."
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Tim Bryce Accepted Answer

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/
Comment
@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.
  1. Patrick Lujan
  2. 1 year ago
Question: What if the standard is wrong and we have taught it to impressionable youth. How do we debrief them?
  1. Tim Bryce
  2. 1 year 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.
  1. E Scott Menter
  2. 1 year 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.
  1. Patrick Lujan
  2. 1 year 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.
  1. E Scott Menter
  2. 1 year 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.
  1. Patrick Lujan
  2. 1 year ago
It could. But in this case, probably not.
  1. E Scott Menter
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
E Scott Menter Accepted Answer
Blog Writer

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.



http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
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.
  1. E Scott Menter
  2. 1 year 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.
  1. Tim Bryce
  2. 1 year ago
Emiel - You are absolutely correct. We've had business processes well before the advent of the computer.
  1. Tim Bryce
  2. 1 year 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.
  1. Emiel Kelly
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Juan J Moreno Accepted Answer

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
[i]Whatever[/i]
ML, right, we'll use.


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


I agree with Peter Hilton, innovative BPMS ([url="http://www.flokzu.com/"]Flokzu[/url] is another example), are “cutting” BPMN, keeping just the really useful and needed artifacts. In this [url="http://www.flokzu.com/blog/en/documents-and-processes/creating-first-process/"]other example[/url] (including a short video), a
[b]complete[/b]
process is built in
[b]just minutes[/b]
, using
[b]just a few[/b]
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.
Comment
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.

:-)
  1. Bogdan Nafornita
  2. 1 year 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!
  1. John Morris
  2. 1 year 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.
  1. Bogdan Nafornita
  2. 1 year 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.)
  1. John Morris
  2. 1 year 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.
  1. Bogdan Nafornita
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Emiel Kelly Accepted Answer

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



Common Sensei at Procesje.nl
Comment
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
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Ian Gotts Accepted Answer

Ouch... Who is going to tell Mr Silver?
Comment
@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.
  1. Patrick Lujan
  2. 1 year ago
BTW, Bruce Silver wrote the forward to Volker Stiehl's book (see my comment above on topic).
  1. John Morris
  2. 1 year 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.
  1. Emiel Kelly
  2. 1 year ago
He knows. It's a niche and he occupies that niche very comfortably, very profitably.
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Bruce Silver Accepted Answer
Blog Writer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Walter Bril Accepted Answer

Wow, Peter, you definitely triggered something here, LOL.

 

There is no issue with BPMN.
[b] There is an issue with using the proper stuff in the proper context.[/b]
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:


[i]"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."[/i]



 

([url="http://blog.leonardo.com.au/are-you-modeling-too-many-processes?utm_campaign=Blog&utm_content=23124804&utm_medium=social&utm_source=twitter"]See also here[/url])

 

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


 

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

 
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Maria Paz Accepted Answer

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
Comment
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.
  1. John Morris
  2. 1 year 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.
  1. Emiel Kelly
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 17
David Chassels Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 18
Unimportant to understand any part of BPM, other than its history
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 19
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.