Tag: BPM2009

For the second half of the morning, I elected to attend a tutorial on a human view of process model comprehension by Jan Mendling of Humboldt-Universität zu Berlin and Hajo Reijers of Eindhoven University of Technology. Obviously a lot of other people are interested too, since we had to move to a much larger room before beginning.

This started with a definition of process model quality based on the SeQual Framework: syntactic, semantic, pragmatic and other measures of quality. Then, some basics on how human memory works:

• External stimuli pass through immediate sensory memory to short-term working memory to long-term memory that represents the knowledge that we maintain.
• Dual coding theory states that we process visual information differently depending on whether it is textual or graphical: with text, we tend to hear the words in our head and process them through auditory channels rather than visual channels.
• Cognitive load theory states that we can only hold a maximum of seven things in working memory at one time.
• Cognitive fit theory, which looks at how different types of stakeholders interact with the same information differently.

Having covered some of the theory around how we process information, we looked at some of the practical examples of how novices and experts view process models; in this case, “expert” may refer to either a subject matter expert or a process modeling expert. The selection of the visual representation – the “language” – does not have much of a difference on comprehension, assuming that all of these languages are flow-oriented, such as EPC, Petri Nets or BPMN. There are, however, a number of factors that do impact comprehension:

• Model complexity (this seems a pretty obvious conclusion to me, but I guess it needed to be proven 🙂 ), including complex operators and some clever but obscure model optimization.
• Layout/topology and coloring; these are considered secondary notation characteristics in that they don’t change the model, just its visual appearance.
• Text labels, that is, the understandability of text labels within process step.
• Purpose, that is, whether the process model is for execution, training or to meet specific certification requirements.

There are different methods of measuring process model comprehension while viewing a model: how accurately can people respond to questions about the model; how long does it take them to answer those questions; how much mental effort is expended to reach those answers, which is done by asking the subjects how hard it was for them. There are also different measures of how well that process model is remembered when it is removed from the subject: recall of process characteristics such as how many start events exist in the model; retention of the business meaning of tasks in the model; transfer of the entire model, measured by questions such as how the model could be simplified.

There are several implications of this process model comprehension research:

• Modeling tools should enforce structured models, analyze correctness (which is well understood in the research community and available in open source tools, but poorly represented in commercial products), and provide different views on the model for different stakeholders.
• With respect to training, abstract modeling knowledge is useful, but familiarity with a specific technique/language is less important
• Adopt 7PMG modeling guidelines: use as few elements as possible in the model, minimize the routing paths for each element (which can be counter to the first recommendation, since it may result in a complex gateway being split into two simpler gateways), use one start and one end event, keep the model as structured as possible, avoid OR routing elements in favor of AND and XOR elements, use verb-object text labeling style, and decompose a model with more than 50 elements to subprocesses (my sense, as well as Reijers’, is that this should be a lower number, such as 20-30, although their research shows a definite advantage at 50).

The relative importance of these factors are unknown, and further research is required to determine where to best invest time and money, e.g., is it better to invest in training or model decomposition? It should be possible for modeling tools to suggest some of the 7MPG guidelines (or similar guidelines for model improvement) when a model violates the rules, although none of them do; commercial products focus on optimizing the model from a business process standpoint, not model comprehension.

There are a number of reference papers supporting their research; I found this to be a fascinating tutorial with a great deal of practical applicability. I would highly recommend that anyone doing process modeling (and maybe some of the modeling vendors) should review the 7PMG paper, which I link to above, since it contains a lot of great ideas for creating better process models.

Update: I have a new link to the 7PMG paper from the authors which is a pre-print version with guidance on prioritizing the guidelines. It’s in place, above.

Yesterday was a great day of workshops here at BPM2009 in Ulm, Germany, and today is the start of the conference proper. After some introduction, we heard from Dr. August-Wilhelm Scheer of IDS Scheer (recently acquired by Software AG); I’ve heard Dr. Scheer speak at ARIS ProcessWorld in 2007 and 2008, and I was curious to see how his presentation to an academic audience would differ from the more commercial/enterprise audience of the user conferences. First big difference: no saxophone. 🙁

His topic was “BPM 3.0”, that is, a look at the future of BPM. He started with a historical view: how BPM has evolved over the past 25 years, and how the organizational scope of BPM has expanded from project-based implementations to blanketing the enterprise. BPM today has enormous strategic importance: you can’t do any sort of complex risk analysis without considering processes, and governance is based in a large part on appropriate process management.

Looking forward, we need to consider empowering the user by, for example, giving them ways to mash up their own view of processes by combining multiple data sources into a dashboard that is specific to their needs, or customizing how they search for information within processes. We also need to leverage the power of the community: he used the examples of IDS Scheer’s social media, including their community site and YouTube channel, although there are obviously more direct social applications within process design and execution.

There was a bit too much emphasis on the ARIS products: he illustrated each point with ARIS, which is fair, but went into a great deal of detail about how it works and the customers using it, which felt like a bit of a sales pitch.

Ben Jennings of University College London had the last presentation slot of the day, wherein he classified a duck using both hierarchical classification and protoype theory. He was successful using both methods, although identified the inherent flaws in hierarchical classification.

The point, however, is about the nature of classification systems: hierarchical classification systems can lead to issues due to errors when creating the taxonomy, whereas prototype methods have more dynamic boundaries.

His research is around gestural analysis of micro workflows: essentially a sort of process discovery, wherein the actions of people in unstructured expertise-driven processes (that is, processes that involve domain experts) are analyzed within a social context in order to establish a reputational representation of the agents that can be used to find the best person to assign to a task. In other words, rather than having a process designer manually pre-determine who does which task, knowledge about the task and the people who might best perform that task can be determined as required based on the human social behavior around past process instances.

Gestural analysis in this context considers both active gestures – such as the explicit creation of content – and passive gestures – such as who a person emails in order to help solve a problem, or blog commenting behavior. It considers both the things that people create, and the people who create them.

This has the greatest value in tasks that have high complexity and high uncertainty, wherein an adhocracy tends to apply, although these tasks may be embedded within a more traditional structured process.

Michael Prilla of Ruhr University of Bochum presented his research on integrating process models into knowledge management system content, using social tagging as a semantic layer for heterogeneous content, with the goal to disseminate process models to foster feedback from users that results in process improvement. Typically within an organization, process models are used by a small group, and there is fairly low acceptance of these models amongst the process participants.

Allowing for social tagging of process models allows users to easily provide feedback in a relatively unstructured fashion. I found his characterization of the groups involved to be interesting: “core users”, “extended core” and “periphery”; more like “inner sanctum”, “enforcers” and “clueless”. The periphery, although containing most of the process participants, is fairly unaware of process modeling and the explicit process models that guide their own work. Giving everyone access to an easy-to-use process modeler does not, by any stretch of the imagination, mean that more than a tiny fraction of those people are going to use that tool; more likely, they have a binder of paper documents with something approximating their processes.

If process models are not maintained in a repository of some sort, process designers search around on shared network drives to find them by name: no different from how they find any other document. It’s not surprising that if an organization doesn’t have any well-organized content management, they’re going to have the same problem with process models, which could be seen as just a specialized type of document. By putting process models into a knowledge management system (which you could consider a content management system to be) and tagging them with keywords that are relevant to the process participants, it makes it at least feasible that the periphery will locate and use these models rather than the outdated binders at their desks. The advantage of using social tagging is that the process designer doesn’t have to do this: tags can come from any of the different types of participants, and are not part of the process model itself.

At a high level, this isn’t fundamentally different from what you would experience with any type of document sharing in a content management system: you would see the same benefits from social tagging of any artifacts that may be of value to a wide audience. They have done some development of an interface for browsing the model repository based on the tags with some specific functionality for process models such as tagging at an intra-process level, but you would expect to see similar results from other types of artifacts/documents from social tagging. In fact, the challenges around social tagging are really the same for any type of content: appropriate tags, and sufficient levels of participation.

The impacts are to increase access to process models, and provide mechanisms for feedback on the process models from the participants, with an eventual goal to have process models be everyday work artifacts rather than some exotic diagram that is only within the domain of the inner sanctum.

Giorgio Bruno of Politecnico di Torino presented a paper on requirements elicitation as a social process. First, he covered the distinction between business processes – an emphasis on control flow, with the process distributing work to the participants – and social processes – where participants perform actions in a shared space, and including the participants, their actions and the artifacts produced.

He introduced a proof of concept textual language used to formally describe social processes, SPL. As he walked through it, it wasn’t clear to me the advantages of this over a graphical language for describing processes such as BPMN, although it is more descriptive around social actions such as adding participants to the process team. However, when he moved past the initial actions of electing a team/board member to details of writing requirements, the language expanded significantly to allow direct representation of documents and their components within a wiki, and member voting on the content created.

Next in their research is bridging the gap between business processes and social processes, with two possible directions:

• Introduce control flow features to SPL for better support of direct, predefined interaction between participants.
• Move cooperative features into business processes, for example, directly supporting wiki collaboration as part of a structured process.

As he pointed out at the end, BPMN and BPEL are not well-suited to social processes, and SPL is not well-suited to business processes; the hot topic is about which notation to use for these integrated processes, and the extensions required to any of the existing notations in order to support both types.

Next up was a presentation by Marcello Sarini, a computer scientist from the psychology department of University of Milano-Bicocca, discussing the socio-psychological perspective on process management. Processes that involve human tasks inherently are about interactions between people, which falls under the area of social psychology and the resulting theories of human social behavior.

They performed a case study examining the patterns of behavior in Wikipedia Italy, based on interviews with 28 participants ranging from contributors to administrators and higher-level mediators. What they found is that status (role within Wikipedia) affected perceptions; and that although the administrators considered Wikipedia to be self-organized, contributors and users view it as hierarchically pre-organized. This is interesting when looking at how social relations work in social software, and how this can be applied to human-centric BPM in both the process modeling and execution stages. In reality, organizations are not flat, and most collaboration occurs between peers (or near-peers); it can be difficult to motivate people to participate in social enterprise software if they feel that their management may be looking at it, although there is some research being performed to see if blind suggestions have a different impact that those that are attributed to individuals.

Prescriptive BPM, where a small group of people (usually management) determine the process designs that are executed by many other people, can lead to intergroup conflict: the participants disagree with the process designs, and a “us and them” mindset is reinforced. Easing this conflict can be done in a variety of ways, primarily through effective channels for user feedback. Aligning personal goals with organizational goals can also reduce barriers, which can be facilitated by the use of wikis to share information.

Descriptive BPM, where processes are seen as knowledge maps rather than a rigid set of steps to follow. The risks in this case are lack of standardization and reduced accountability, although most people will conform to norms due to social influence.

The goal of this research is to use social psychology to help design a new generation of human-centric BPM, as well as develop new social visualization techniques.