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 - Real world collaboration

user-pic
Vote 0 Votes

In the last entry to this blog, I challenged readers to depict a very simple process in BPMN - development of a branding package (colours, fonts, logo, artwork, etc), in which:

  1. The account manager, designer and artist throw ideas back and forward for review and debate (concepts, images, documents, etc), usually but not always by email;
  2. The same person acts as designer and artist at the start, but has the option of handing over the artwork creation to others if their workload becomes too heavy;
  3. It is possible to add more artists as needed during the life of the process, all of whom participate in the same communications.

So far no-one has responded to the challenge. This is not surprising, since it is not possible to show any of this in BPMN.

With regard to "throwing ideas back and forward", message flow in BPMN is limited to a single, one-way send from one pool to another. The send can be repeated if the appropriate looping constructs are used, but it is very hard to depict message flow between more than 2 parties, and any attempt to reproduce the flexible manner in which people exchange messages is doomed to failure. Mainstream BPMS software currently deals with this limitation by claiming that message exchange between colleagues is not really part of a work process - rather, they claim, it is an ad-hoc activity on which no structure can (or needs to) be placed. In other words, what is perhaps the most fundamental tool of knowledge work is relegated to floating around under the organizational radar, in an unmanageable backwater.

With regard to "handing over work", BPMN has no concept of who does the work. It simply shows what needs to be done, by someone or something. Hence it is impossible to include in a process diagram any indication of the people, or sorts of people, involved. Again, fundamental aspects of knowledge work (acceptance and delegation of responsibility, capabilities, personal characteristics, and so on) are quite literally out of the picture.

Finally, with regard to "adding more" of a certain role, there is no means to achieve this in a BPMN process. It is hard even to imagine how the notation could be extended to support the notion, since the flowchart principles on which BPMN are based do not support such a concept. Yet human resource planning is fundamental to process management, as it is to all management. How is process software supposed to support human resource planning using a notation in which it is not possible to depict, let alone adjust, the resource levels assigned to a work package?

By contrast, here is a simple diagram using Human Interaction Management (HIM) notation that shows all the above constraints:

The horizontal, dashed lines are Interactions - they show message exchange between the 3 parties to the process. Messages can flow in any direction, repeatedly as necessary.

The yellow rectangles are Roles in the process, and the ovals at the top are Users of those Roles. At the start, Dee Zeiner is playing both the Designer and the Artist Roles. However, the diagram includes an extra User, Richard Tist, to whom the Artist Role can be reassigned during the process if Dee takes on other work and has to delegate.

Finally, should it become necessary to add another Artist as extra resource, this can be done in a Human Interaction Management System (HIMS) simply by right-clicking on the Artist Role and asking for another one. The HIMS will prompt for the details of the person to be assigned the work and then duplicate the Role, automatically assigning the new Role to the new person and including the new Role in the same Interactions as the current Role.

TAKE AWAY

There are many other aspects of HIM notation that make it more suitable for collaborative, adaptive human work than BPMN. I will discuss these aspects in future posts in this series. While waiting for the next post in this series, you might like to consider the following puzzle.

The Artist in the process above must create a draft set of colours before starting to create fonts. However, once they have created a draft set of colours, [the semantics of a HIM diagram mean that] they can repeat and interleave the colour and font creation activities as they wish. Similarly, they must create a draft set of fonts before starting to create a logo. However, once they have created a draft set of fonts they can repeat and interleave the colour, font and logo creation activities as they wish. Simple common sense! Yet can you depict this incredibly simple and commonplace pattern of work in BPMN?

You will find that it is necessary to jump through some very artificial hoops in order to draw such a pattern in BPMN - just try to show how the Artist can go directly from colour creation to logo creation only once they have created fonts. Unlike people, a flowchart has no memory. A HIMS does, however. If you are interested to try out the next generation of workplace software, the free HumanEdj (via which the above diagram was generated) is available online for download.

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

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT