The first research session this afternoon was on BPM in practice, looking at what people are actually doing with BPM.
How Novices Model Business Processes
I missed the first paper in this section, but arrived just in time for the presentation from Queensland University of Technology on how people who have no prior knowledge of formal process modeling techniques actually create process models.
Conveniently, they had a well-controlled group of research subjects: new students in the process modeling course. They looked at the students’ prior experience in modeling methodology, knowledge of the business domain and drawing skills, with the goal to correlate that with the diagram classification (i.e., what type of diagram that they drew) and semantic correctness of diagrams. Their diagram classification ranged across five basic types of design from pure textual descriptions to purely graphical representation; most commonly used was a classical flowchart design (type 2), with boxes annotated with text, connected by arrows, but there were also hybrid designs that added graphics to standard flowcharts, as well as storyboard styles (type 4). In some cases, they overlaid additional information, such as a flowchart of activities with a timeline plotted beneath it.
They did find some prior knowledge factors that could predict the most likely design type used by an individual: low levels of object-oriented model knowledge predicted a preference for storyboard-style design, whereas high levels of previous domain knowledge was more likely to result in a flowchart-style design. Design quality, that is, semantic correctness of the model, was correlated with design type and previous domain knowledge. Personally, I’d like to see the correlation with the students’ Myers-Briggs scores.
Considering the debates going on now about the need for flowcharting, and by extension, BPMN and other modeling notations, I find it interesting that the most common design style that students use without any prior process modeling experience is the flowchart. However, they see a more graphical and free-form representation as possibly also adding value, considering that a rigid notation such as BPMN might restrict creativity in process modeling.
IT Requirements of BPM in Practice – An Empirical Study
The last paper in this section, from the University of Bern, looked at the link between low BPM maturity rates within organizations and the inability of currently BPM tools to meet the key requirements of those organizations.
They conducted a survey of 130 companies across various industry sectors within the Forbes Global 2000 list, asking questions about their business processes, the related applications used for managing processes, and the process scope and duration. They also asked how (e.g., text versus graphical modeling notation) and why (e.g., compliance) they documented their processes; interestingly, more than a third were documented as text, 20% as tables, and about 30% combined for all process-specific modeling languages.
The use of BPM tools is a prerequisite for reaching the highest level of BPM maturity, so the survey also contained questions on the importance of specific capabilities of a BPM tool; the most important factor was supporting (manual) task execution, with automation of tasks coming in at #4. Most companies are still using Visio and Word [and based on my experience, probably PowerPoint as well] to document their processes; the first BPM tool (ARIS) doesn’t appear until #4 on the list.
Relating this back to the BPMM maturity levels, process documentation is critical in moving from level 2 to level 3, with textual descriptions indicating a lower maturity level than graphical models; most of the companies surveyed are still at level 2, but are in a position to transition to level 3. Using some sort of BPM execution software – whether a dedicated BPM system, an ERP system or something else – is critical to reaching level 4.
Getting back to the capabilities of the BPM tools and how this impacts maturity levels, they found that both usability of the tools and software integration requirements were not satisfied by the current crop of BPM tools. At the point that this paper was written, the details of those unsatisfied requirements were not fully established; this can be expected in their future research.