As mentioned in the previous post in this series, a current state architecture model can be useful for communities other than just the originally conceived users – after all, a model is aimed at gaining insight into some complex activity. So it's natural that any group that might want to gain a better understanding of the subject matter of a model, could find that model useful for their own purposes. In previous posts I've talked about some interesting cases that I've seen where models have indeed been useful for other groups within the organization.
However, in one case I've seen, this concept has managed to go even further in leveraging the value of models. Specifically, one organization that I worked with has invested in developing process models, and has been able to make use of them in detailing their expectation of how to work with other organizations.
The key aspect here is the use of pools in BPMN to show message exchanges. For the purpose of establishing a baseline, I’ll engage in a little bit of revision of the structure of a BPMN diagram, borrowing a couple of diagrams from the Object Management Group’s document “BPMN 2.0 by example”.
BPMN includes swimlanes to show roles, but these swimlanes are also grouped into pools, with a pool representing separate organizational entities. The diagram below shows a single process that involves three pools. The key point is that interactions between the pools are shown by the dashed lines, which represent message flow – as opposed to handover of responsibility that is shown by the solid lines (sequence flow).
So a strength of a BPMN diagram for the purposes discussed here is that it can show touchpoints to external organizations, meaning that an appropriately constructed BPMN diagram can show the external touchpoints for a given interaction.
As with other posts in this series, there are a few considerations that we need to keep in mind. First of all, the risk in publishing your processes in this way is that you could reveal confidential information about the internal operations of your organization – obviously, this is something that we would want to avoid. For this reason the internal process of the organization should be shown as a closed pool only.
There is a second consideration in using process maps in this way – which is one of buy-in. This model works well in a specific case – where the outsider organization has no choice but to align itself with the organization’s processes. If there’s scope for negotiation, with a different process being agreed for each bilateral agreement, formally documenting the process can easily impose more costs than benefits. So it’s a better model for engaging with multiple smaller partners as opposed to a small number of larger organizations.
Exposing your organization’s processes outside the ‘beehive’ seems counterintuitive – and for good reason. But in cases where a large organization is engaging with a relatively large number of smaller organizations, publishing a restricted view of some of the organization’s processes externally can be a very valuable activity.