For those who miss posts on this blog: for certain reasons now I publish more at bpmntraining.ru.
For the convinience of my English-speaking readers I’ll translate the most popular posts here, like this one.
For those who miss posts on this blog: for certain reasons now I publish more at bpmntraining.ru.
For the convinience of my English-speaking readers I’ll translate the most popular posts here, like this one.
This post was originally published at bpmntraining.ru.
Typical BPMN use cases are:
Let’s define the analogue/digital divide first and then proceed to use case #3.
Bruce Silver shared his thoughts about the conditional event in the recent post.
For those not deeply immersed into BPMN 2.0, the conditional event pauses a process until specified logical expression becomes true (changes its value from false to true, to be precise). I’m writing this post in October, so the good conditional start example would be:
Fig. 1. Conditional start event example.
Here the process starts when the logical expression becomes true, i.e. when winter comes. (BTW, this is the real rule in effect here in Moscow.)
The typical conditional intermediate example:
Fig. 2. Conditional intermediate event example.
Here the process waits until the invoice record stored in some unspecified system would be marked as paid. (This is overly simplistic version - please be patient, the more robust will follow.)
Bruce says that he prefers not to use conditional events and excluded it from the “Method and Style” - the collection of best practices he created, supports and promotes by his famous book (the best BPMN guide in my opinion).
With all respect to Bruce as my BPMN teacher, I have a different opinion on the matter: I believe that conditional event is the best solution for certain quite common process collaboration scenarios. (To be more specific, it’s the conditional intermediate event; the conditional start event doesn’t have much value so it won’t be discussed here.) » read the rest
The BPMN 2.0.2 specification is ambiguous regarding the subject.
Please compare:
1) Table 10.89 at p. 250 says:
The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event. It is used for modeling methodologies that use Events to indicate some change of state in the Process.
2) Table 10.93 at p. 259 also clearly shows that None intermediate is a Throw event.
3) However the text at p. 271 says the opposite:
There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and an End Event
Here is what other authoritative sources say -
4) Bruce Silver, “BPMN Method & Style”:
Omission of eventDefinition signifies a throwing None event, which is allowed; it can be used in the diagram to indicate a particular state of the instance.
5) Tibco:
Intermediate None event indicates an unspecified change in the process.
6) Camunda:
Intermediate none events (throwing) can be used to indicate some state achieved in the process.
Looks like the text at p.271 should be corrected to -
There are three (3) variations of None Events: a Start Event, a throw Intermediate Event, and an End Event
PS. Thanks to my colleague Julia Wagner for pointing to this issue.
UPDATE: Bruce Silver’s comment -
Anatoly, Yes I agree with your post - (3) is incorrect, along with 400 other errors reported since 2009.
Sorry, this entry is only available in Русский.
I wrote here already that it’s common for what business considers a business process to become several process pools in BPMN - look at process patterns “internal order” or “incoming processor”. In both examples the “client” process posts a task into DB and process to wait message from the “server” process that the task is completed.
The diagrams are valid but here is the caveat: server should know the client internals - namely the event on the client side. It’s ok if the server deals with a single client but what if not?
This is yet another attempt to answer the damned question about BPM: why, albeit being successful in so many projects, it never matched the analysts’ growth predictions and still haven’t become mainstream?
There must be something wrong deep in the core. It can’t be just prospects’ ignorance, non-perfect software products or greedy consultants. Nobody would say that BPM methodology is inadequate or unusable (well, except ACM proponents but their voices aren’t loud nowadays).
I blogged on the matter already… well, it was 8 years away: 10 Reasons Why BPM Market Doesn’t Meet The Expectations. It wasn’t a final explanation obviously - 10 answers means one doesn’t have the killing answer.
What turned me back to the matter is a thought that I’ve read recently. It was about the real value delivered by a good business consultant. It’s not a specific business receipt or advice; ultimately, it’s about making complex business issues simple.
Now what do we BPM professionals offer in this respect, do we simplify business issues? I’m afraid not.
BPM software isn’t an issue here (IT people love complex toys) but we proudly bring a full-blown discipline, we suggest extensive training programs and introduce new roles to the organization. We create process diagrams. They turned out to be rather complex but we rightfully assure that they are as complex as business is - no more, no less.
This is all true, but… does it make a customer happy? Well, it does - those who are paranoid to do more with less, be more efficient today than yesterday etc. Are they majority of business leaders? I don’t know the big picture but for the selection that I observe the answer is negative.
And what is decision maker’s best alternative? Sweeping garbage under the carpet: keep it as-is, more or less. Imitate a BPM initative by purchasing BPMS software is OK but pulling out business processes from employee’s brains and making them explicit is way too hard, creates too much tension on the way and too much complexity at the end.
Indeed, implicit processes have numerous hidden weak points and hence are less effective, less efficient and way less agile… but who cares, as soon as the majority of organizations around operate this way. See no evil, hear no evil. Not that efficient but simple and manageable from C-level perspective.
Current Digital Transformation trend should break this modus operandi because digital business models implies digital business processes. So hiding processes complexity by delegating them to performers shouldn’t be an option any more.
Last time we found out that only two of five BPMN gateways are absolutely necessary: XOR and AND.
Now let’s consider events. BPMN events are categorized by type (13 variants) and position (8 variants). Let’s consider event types:
1. None
It’s a paradox but the term “process” remains the most ambiguous in BPMN, as the recent discussion on the BPM.com forum has shown.
Thus, if we look at the process hierarchy through the prism of BPMN, we’d find several levels of process groups at the top, several levels of subprocesses at the bottom and a thin layer of what BPMN calls a process in the middle:
See also:
Complete BPMN palette includes hundreds of elements if all allowed combinations are counted. Seasoned professional should know the semantics and usage rules of any but at the same time shouldn’t seek to use them all.
Firstly, exotic elements would make the diagram less comprehensible for business users, leading to refusal in some cases. Probably the biggest BPMN advantage is that it’s both intuitive and strict enough, allowing business users, analysts and IT developers to be on the same page. But this is going to happen only if a good style and healthy minimalism are followed.
Secondly, if BPMS powered processes are considered, no engine implements BPMN completely and strictly. Hence the popular questions: how critical is a given BPMN element being not supported? Is there a workaround?
In this article we’ll investigate BPMN gateways - which ones are must-have and how others can be workarounded. The other BPMN elements will follow.