BPM Managers and Visualisations

Have just read the latest BPMTrends newsletter: "What Do Business Process Managers Manage?"

What is interesting is the derivation of Process Sponsor and Operational Manager roles within an organisation. In particular, the article shows some derivations of finer grained tasks that are performed by such people. Most Visualisation approaches for BPM are restricted to just roles, which is fine. However, I argue that a visualisation is meant for a task, because it is about providing information for decision making. Since a process manager or sponsor has many tasks to perform, each visualisation, I argue, needs to be tuned to help them make decisions for that task.

Treinish published an interesting paper on this issue a while back, but the truth still holds. As we often produce differing text for differing tasks, so too we should modify visualisations to fit a task, not just a role in an organisation. Case in (simple) point; if I was a modeller talking to another modeller, then I would use a BPMN diagram, due to the compact, iconic representation being easy for experts to use. However, if I was a modeller explaining a process system to a naive viewer, I would not use BPMN, I would probably use a full 3D simulation to get my point across. In fact, the later is often done regarding community consultation in Urban Planning applications, CAD drawings just don't cut it when talking to investors and residents about how a site is to be redeveloped.

I believe this holds across the board, for executable and non-executable modelling systems.

Ross

BPMN Animated

As mentioned in my previous post, I have been following a discussion on the uptake of BPMN functionality. Basically, the debate revolves around the actual number of BPMN components being used, and the lack of uptake on many of the components devised by the OMG. This is an exceedingly complex issue, that I cannot fully comment on due to my nascent knowledge of BPM, having defected so to speak from the gaming community.

However, I can't help but wonder if the issue here is to do with the visual nature of the diagrams, and their interaction capabilities. Most software I know of that uses this standard presents the diagrams in an inanimate, low-level interactive manner. While this works well for certain stakeholders in a process modelling scenario, it does not bode well for those that think in a different manner, especially if they are new to the field. For instance, you model the business, and then show the user the model and expect them to understand easily. I think a static diagram does not work here for people who are not BPMN experts.

Would more components be used if it was clearer what these icons meant, and what they model? Most of the time we avoid software functionality as it is too hard to find out its usage. And no, RTFM just doesn't cut it as a methodology, because we usually learn by doing, and the doing requires tools that clearly show their functionality.

I think a lot of pedagogical theory could be applied here to look at how animation could be used to show the functionality of the diagram. Not in a simulation manner, but simply in a base functionality level. The user could use a tool to brush over the diagram to generate animations that indicate node or group levels of functionality.

For instance, as an icon is inserted into a diagram (xor-split say), it could animate itself judiciously to indicate that one or the other choice in the branch is made, and not both.

This technique has been applied in other visualisation fields, and I think it could work here.

Ross