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.
I see your point about the flexibility of BPMN as limiting, and also the temptation to go the flowchart way for inexperienced “modelers”. My question is that while i understand that larger companies use BPM software to model their processes and automate it therein, i mean the ability to execute process from the model using the execution engine. What is the place of process modelling during business analysis, say for a software project? If i use a software like BizAgi (open source and excellent at drawing) to model the processes of a client with a view to understanding the process, see areas for improvement or even process that might be eradicated, all in attempt to gather “better” business requirement for a software project, will that be considered reasonable without any execution engine, ERP etc?
Modeling processes are a valid part of process understanding, documentation and improvement, even if the processes are not going to be automated. These models can, as well, become part of the requirements given for a software project, without the modeling tools itself having any process execution capabilities.
What is essential is that the modeling tool and the execution tool either share a common model, or have very tight integration so that the model can be automatically translated between the two environments. Process models change constantly, especially during the first weeks and months of implementation, so the ability to change the model on either side and have it synchronized is essential if you are not sharing a common model between the two.
Sandy, if you had any further pointers to the source material, or the researchers, from the University of Bern I would be (a) fascinated and (b) very grateful.
PS I hope London treated you well, maybe come see us next visit 🙂 Keep tweeting
Matthew, sorry for the delay responding. The authors of the papers are Susanne Patig, Vanessa Casanova-Brito, and Barbara Vögeli at University of Bern, Institute of Business Information Systems. Their email addresses as listed on the paper are {Susanne.Patig,Vanessa.Casanova-Brito, Barbara.Voegeli} @iwi.unibe.ch if you want to contact them directly.