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.

IT Directions

Keith Harrison-Broninski

Keith's adventures in BPMN - Respond to RFP

Vote 0 Votes

As a first step towards exploring the depiction of human-driven processes in BPMN, I have chosen a very common process - responding to a Request for Proposal (RFP). Here is my attempt to show a simplified version of this work in BPMN:

From a manager's perspective, the questions underneath the image are important. The process as it stands could be carried out exactly as shown, but completely fail to deliver what the business needs. Whatever your organization's "process maturity level", and however sophisticated your BPM software, implementation of the process without answering these questions is more likely to harm the business than to improve it.

The underlying problem is that the diagram itself offers no hooks on which to hang the answers. Let's take them in turn.

What are the goals and responsibilities of each player?
A BPMN lane or pool is simply a grouping of activities - it is not an organizational role, with associated goals and responsibilities

How can the Salesperson know what the others are looking for?
Starting from a diagram such as this, the proposal author is effectively working blind - they have no idea on what basis their work will be reviewed, or even who by

To what policies and regulations must the players adhere?
The diagram shows no indication of organizational context - to what conditions the proposal must conform

What skills, experience and personality type should each player possess?
Encoding processes in standard format can be dangerous - without providing any information about the players, it gives the false impression that the work is somehow independent of the people carrying out the activities

What if the Salesperson needs help from another Salesperson to write the proposal?
If the proposal turns out to be too much work for one person in the time available, they may need to share it with someone else - but the diagram offers no means to achieve this

What if the Salesperson needs to discuss matters with the others?
The most efficient way to prepare a document draft is to allow communication with reviewers prior to submission - but BPMN does not allow the depiction of interactive, multi-party communication channels, only one-off messages sent from 1 pool to another as part of a workflow

What if other work apart from document writing is necessary to prepare the proposal?
Writing the proposal document is actually the tip of the iceberg compared to the research, evaluation and analysis that underpins the document - such activities tend to be hard to predict in advance, yet BPMN makes no allowance for on-the-fly adjustment to the process

What supporting information is needed?
It is critical to supply each player with the reference material they need - yet BPMN allows artefacts to be associated with a process only as activity inputs/outputs

How is material containing that supporting information made available to the participants?
It is not enough just to show reference material - the players need to know what form it is in, where to find it, and how to access these locations (account details for a technical journal subscription, for example)

Anyone who has ever prepared a proposal in response to an RFP will see immediately that this diagram is totally unrealistic - the real world is neither so simple nor so rigid as the workflow depicted


BPMN is a fine process notation - when used for its natural purpose, which is to capture routine work in which the only human activities are data entry and low-level decision making. Work suited to depiction using BPMN is either automated, semi-automated, or so repetitive that one day it will be automated. Effectively, BPMN is a high-level software design notation.

When it comes to human knowledge work, a BPMN diagram simply does not contain the right information. Even if business people can be persuaded to try and understand a notation stuffed full of engineering symbols, a software design notation is the wrong tool to capture collaborative, adaptive, innovative human activity.

In the next postings to this blog, I will continue to explore the application of BPMN to knowledge work, and look at an alternative - the simple notation of Human Interaction Management, which is designed both to capture human work and to support it with software (a Human Interaction Management System).


Pretty rough to bag BPMN by using it incorrectly and to describe a business process which has not been fully explored. More at http://davethinkingaloud.blogspot.com/2008/09/adventures-in-bpmn.html
However, great to get the discussions out there.

Thanks for this comment, David. Your criticisms are not correct, though.

To be sure, I just checked against the BPMN specification, and my diagram is entirely valid. There are examples in there of all the constructs used except for message flow from a gateway, but it says (p.123) "A modeler can connect either type of Flow in any direction at any place in the Diagram" which legitimizes this usage.

You refer in your own blog post to "the semantics of BPMN", but the BPMN specification has no semantics! This vagueness about meaning is deliberate, since BPMN attempts to represent everything and anything (though I am challenging this ability in my blog series). However, it is a weakness of the notation - witness this discussion. Were the notation more formal, it would have not been needed.

I suspect that the lack of semantics in BPMN is also what is holding up the definition of BPDM - and may eventually derail it. We shall see ...

All the best

Clearly we do not have the same view of the BPMN spec. I do not agree with your use of LANES or message flows. The section (10.1) that you quote as legitimizing the use of a gateway as source for a message is discussing the direction of flows only (perhaps not the most precise piece of English). However, Para 10.1.3 Message Flow states quite unambiguously ...
A Message Flow is used to show the flow of messages between two entities that are prepared to send and receive them.
In BPMN, two separate Pools in the Diagram will represent the two entities. Thus,
° Message Flow MUST connect two Pools, either to the Pools themselves or to Flow Objects within the Pools. They cannot connect two objects within the same Pool.

By definition the Lanes of your diagram are in the same default Pool.

And para Message Flow Connections
This section applies to all Gateways. See Section 8.4.2, “Message Flow Rules,? on page 31 for the entire set of objects and how they may be source or targets of Message Flow.
° A Gateway MUST NOT be a target for Message Flow.
° A Gateway MUST NOT be a source for Message Flow.

Both of your gateways are shown as source for message flows.

Hi David

Re message flow between gateways, the spec is ambiguous. I took the statement I mentioned in my previous comment to allow it, whereas this one on p.31 (which I think is the statement you refer to in support of your view) disallows it:

"Only those objects that can have incoming and/or outgoing Message Flow are shown in the table. Thus, Lane, Gateway, Data Object, and Text Annotation are not listed in the table."

Re lanes, the diagram on p.14, "Example of a Collaboration Business Process", shows message flow used in the same way that I have - between lanes. Or are they pools? The usage is unclear, just as it is in my diagram.

In both cases, we have come back round to the point I made in my previous comment. BPMN has no semantics - i.e., whatever you mean by what you draw, the beholder must make their own interpretation. So it doesn't really matter how you choose to read the rather ambiguous specification document. I think you are right about my message flows from gateways - I'll change them to sequence flows, thanks - but apart from that my diagram is legit. However, ultimately it makes little difference, since a BPMN diagram has no formal meaning.

If you use a BPMS, the developers who designed it will have made decisions on your behalf about how the shapes are to be used - and what those decisions actually were may be deeply hidden from sight. If you don't use a BPMS, and draw BPMN diagrams using something like Visio, then the readers of those diagrams must all interpret your work in their own way - they have no other option.

This could be taken as a criticism of BPMN, but it is not the criticism I am making in my blog series. In fact, I am not criticizing BPMN at all! Rather, I am making a quite different point, namely that the range of purposes for which BPMN is suited is limited to routine processes, what some people call "production processes" - those that execute many times in the same way, and in which the only human involvement is to enter data and make low-level decisions at key points.

There is another kind of process, that is responsible for somewhere between 40% and 85% of the work in an organization (take your pick of the statistics, which on this subject are many and varied). This second kind of process is what I call "human-driven", in which humans do "knowledge work" - they collaborate to innovate solutions, adapting their behaviour to unfolding circumstances along the way.

The assertion of this blog series is that BPMN is deeply unsuited to such processes. Debates over how the spec authors meant message flow to be used are irrelevant to this, since they clearly did not intend it to be used in any way that could truly support collaborative human processes.

All the best

I agree that BPMN is not targeted to the behaviour of people to people and people to system interaction. Using it for such a purpose is akin to using a chisel to open a paint tin.
However, you are still misusing and misunderstanding BPMN in your examples and ignoring the meaning that is defined in the notation specification.
in BPMN1.1 spec Figure 7.3 - Example of a Collaboration Business Process shows the correct use of messages between pools not lanes. Pools and lanes are not interchangeable. We can be sure that it is between Pools because the spec limits message flows to communication between pools. Because your example is clearly of a single organisational unit, your use of Lanes to subdivide the organisational roles is correct and therefore the use of messages to communicate between the activities in different lanes is incorrect. There should be no messages only sequence flow in your diagram.

Thank you again for this response, David. It is good to read your agreement with the issue I am raising in my blog series, and your other comments are very helpful in bringing out a further deep issue with BPMN.

You write "your example is clearly of a single organisational unit". Why? There is nothing to suggest this in the diagram - you are making your own personal interpretation.

This is exactly the point I have been trying to make in our discussion, i.e., a BPMN diagram has no definitive meaning. For instance, there is no way to tell whether I have drawn pools or lanes - all 3 players could very well belong to either the same or to different organizational units.

This is dangerous whether or not you use a BPMS. Whether or not your diagram is being interpreted by readers, or by the designers of your BPMS, you have no way of knowing whether it will be used as you intended. To my mind, this makes the notation something of a business risk.

All the best



I think the problem is that "your" diagram isn't fit for the purpose you describe.

You talk about the "hooks" not being there, but that's based entirely on what you choose to model.

If your goal was to describe the who, how, why etc. your tasks should be higher level. You would likely have milestones and move the mundane details into the supporting text.

How about a diagram with tasks more like

- Plan Response
- Draft Response
- Review Response
- Release Response

Basically, your tasks need to be more suited to your goal.

Remember, the ultimate goal of a BPMN diagram is to make things clearer, if you don't find it valuable, it's unlikely anyone else will.



How is moving "mundane" details into supporting text making things clearer? Especially when they are not "mundane" at all.

With your approach, one might as well abandon diagramming altogether and go back to writing procedure documents!

All the best

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives