Keywords

1 Introduction

The Business Process Management is according to [1] considered as a new way of managing organization and it is based on the principles managing the organization when the processes have the key role. According to [2] it is the managerial discipline that uses the technologies for the process oriented management. Generally, it is said that Business Process Management is a complex of methods, tools and technologies used for design, approval, analyses and company process management. Thanks to that, it is possible to set customer needs as primary ones, achieving success by what stated in [1].

The Business Process Management brings the change of the view from production oriented (a large number of products at a low price with a goal to meet the needs of the market for the price of surplus products – see consumer industry also so called industry 3.0) to the production targeted at the customer needs fully utilizing opportunities of the organizations. This production, characterized by the product (or service) is not only a tangible object produced according to the defined technological processes. The product is supplemented by a digital dispatch. The digital dispatch carries the identifying target customer, his specific needs (for example color of the product is not determined by heuristic estimate of the future demand of the market – black cars 20%, white 18% and red ones 5%) and also technology procedure needed for the realization of the final product. These are the thoughts of the industry 4.0. These are based on the mechanism of the “Cyber-physical system” [3].

This mode procedure of the management brings synergy effect in terms of customer satisfaction to achieve maximum possible efficiency of the organization (the minimum production to warehouse, accurate production planning etc.). To get the real meaning, it is necessary to bridge a lot of real problems. Among these errors there are ambiguous designation of:

  • scope (where direct the process),

  • metrics (how to fulfil the individual’s goals),

  • owner of the process (who is responsible of the business process),

  • inputs (what really joins the process),

  • outputs (what really stands out of the process),

  • limitations (connected to the process).

These questions come out from the Capability Maturity Model [4], that defines following levels of maturity of the project:

  1. 1.

    level - there is no process management. The processes and their management within the organization is chaotic and undefined.

  2. 2.

    level - initial management of the processes. The processes are realized ad-hoc. The organization’s success is based on the individual performance.

  3. 3.

    level - repeated project management. The basic processes of the company are identified and their execution complies with the certain discipline.

  4. 4.

    level - defining the process management. The basic processes are described, standardized, documented and integrated within all of the organization. The compliance of these processes in the organization is enshrined as a duty.

  5. 5.

    level - driven process execution. The processes have defined appropriate indicators, regularly reviewed. Thanks to that it is possible to realize minor changes of the software without measurable loss.

  6. 6.

    level - optimized process control. Processes are continuously improved. defining an innovation cycle.

To allow the target improving the level of maturity of processes, the organization should be implemented with the life cycle of the Business Process Management (see Fig. 1).

Fig. 1.
figure 1

Business Process Management life cycle.

Full size image

Thanks to the BPM, life cycle can increase organizational effectiveness, minimize the cost and eliminate increasing the cost and their overwork [1]. Just the first step of the BPM life cycle is a model and designing that it brings following advantages [5, 6] and this is turn brings following advantages:

  • visibility of processes – anyone can see the process, measure and simulate different parts of the process, detect the errors in the design,

  • transparency of the process – all participants can see the whole of the process and not only a part defined for them.

None of the modelling languages or tool alone are enough to create concise, clear, precise and graphic quality process models. It is necessary to deal with the possible ways of interfering the quality of the process models. Affecting the quality of the process models is possible in several ways. Either during the modelling or retrospectively or after the modelling of the process models. Affecting the quality during the modelling helps methodologies and recommendations how to design the processes. These methodologies include:

  • SEQUAL Framework [7, 8].

  • The Guidelines of Modelling (GoM).

  • Quality Framework for conceptual modelling (ISO 9126 standard for software quality).

  • Seven Process Modelling Guidelines (7PMG) [9].

  • Process models quality metrics [5].

Disadvantage of using the first four methodologies can be that except some experiences with modelling of the business processes; it can be difficult for the non experienced designer to apply the recommendations in the model because he may misunderstand or apply them wrongly.

Numerous modelling languages exist for the creating of the process models during the model and design phase.

For example:

  • Unified Modeling Language (UML) [10].

  • Business Process Model & Notation (BPMN) [11, 26].

  • Event-driven Process Chain (EPC) [12].

  • Petri Nets [13].

  • Finite State Machine (FSM) [14].

  • Subject Oriented Business Process Management (S-BPM) [15].

  • Yet Another Workflow Language (YAWL) [16].

  • Business Object Relation Modeling (BORM) [17].

Outputs of the modelling languages is possible generally understanding it as a graphs. Sometimes the process is possible to write down in structured form. We are able to work with the graph using familiar mathematical procedures. Most of the applied metrics for quality measurement is based on the graph analysis. The most widely used measures are:

  • The number of elements.

  • The complexity of the flow control.

  • The immersion of the depth decision.

  • The degree of clarity.

  • The complexity of interconnections.

Each of the measures focus on one area of the process model and ignores other areas. The measure can mark the model as a correct modelled one according to one specific area. The model can be incomprehensible for the reader of the model. According to [6] “It does not exist one general measure that can affect the process model from all the areas and determine if it is clear and “understable”” (Fig. 2).

Fig. 2.
figure 2

Business Process Models common notations

Full size image

Here we define the factors that influence “usability” of the process model. These are:

  1. 1.

    Graph elements (symbols for the nodes and arches, limitation of the logic blocks of the process, option and view of the nesting node).

  2. 2.

    Possibility due to the notation of the graph to affect modelled reality. If we try to generalize the process steps, we will lose part of the modelled reality. Or if we choose the approach similar to BORM (i.e. we are trying to write down the streams and we are creating the model with a lot of the elements).

  3. 3.

    The ability of the process designer to convey the reality.

  4. 4.

    The ability of the reader to understand the process reality.

We are calling these attributes 4F4U BPM … which stands for Four factors For Usability BPM.

2 Research Questions

The research team focused just on factors 4F4U BPM and provided following research questions:

  • Have the size and model structure influence to the intelligibility of the process model?

  • From what number of elements does it make sense starting the process model hierarchically divided?

The team decided for these questions to process the feasibility study in the Collaborative Usability Lab in the context of 4F4U. The modelled language for the process models design was chosen from the BPMN [11, 18] and Camunda Modeler tool was chosen for the modelling.

The right environment for the 4F4U is Usability Lab. According to [19] “Usability Lab Allows to effectively track user interaction with the computer.” It consists in observation of the user activity by recording desktop, recording responses on the subject and call record “Thinking aloud”. By J. Pavlicek and R. Bock [25]: The designed Collaborative Usability Lab complements interaction to interaction of the tested persons (Participants) between them. It is possible to monitor and effectively measure the defined factors in the lab. This measurement is called Usability testing of the process models (Therefore in the context of 4F4U).

3 Materials and Methods

Based on the [5, 6, 20] the research team defined the three testing research methods:

  • Classic testing using UI Study according to [19].

  • Collaborative testing using the lab HUBRU [25].

  • Collaborative pair testing J. Pavlicek and R. Bock [25] using HUBRU lab.

All the methods used as default approach traditional Usability study [19]:

  • definition of the users (Personifications),

  • qualitative test,

  • test scenarios (cognitive or heuristic),

  • screen records,

  • Think aloud record,

  • Moderator leading,

  • Post interview.

Furthermore, it was completed by new approaches J. Pavlicek and R. Bock [25]:

  • monitoring by the eye camera,

  • collaborative testing (by the collaborative studies),

  • pair testing (by the pair studies).

3.1 Classic Testing

Classical usability test approach

During this test the participant tries to achieve everything from defined goals Fig. 3. During his/her work the usability researcher records his/her behaviour by the behaviour camcorder and records the computer desktop. The participant has to think aloud. It means, he/she has to comment his/her activity. His/her ideas are recorded too. Finally, (after the test is finished) the researcher makes the final interview. This interview can expose gaps at the GUI design. These gaps can be (not matter of course) recorded by researched during the study. The researcher tries to recapitulate them. Thanks to this approach the researcher can finally define all usability issues. According to the Jacob Nielsen [19] 8 participants are enough to expose 90 percent of Usability bugs. It means, we should test minimally 8 participants, but for example twice more (16 participants) is ineffective yet. It consumes more resources (time, money) and the results are not significantly different.

Fig. 3.
figure 3

Usability study approach

Full size image

We call this approach l “classical” of “common” according to the J. Pavlicek and R. Bock [25].

Advantages

The main advantage for the classical usability study (Fig. 3) is the deeply known methodology, how to lead it, how to gain data from it. The Jacob Nielsen team [19] developed huge amount of technics and UI Lab used for this purposes (Fig. 4). In the world there are teams that perform these studies and get business result from them.

Fig. 4.
figure 4

Classical usability lab

Full size image

Disadvantages

The classical approach for the usability testing is “de facto” etalon till now and it’s very hard to classify disadvantages. We didn’t gain some publications, talking about classical usability testing disadvantages. But we can do that. We could be – maybe – the first. The main problem is the price. Each Usability study is very expensive, because each participant “occupies” the whole lab. Because the pure time (pure time without researches introduction, coffee break etc.) for common Usability test consumes between 30–60 min (plus time for data collection by researcher, time for the usability scenario explaining etc.), the time for each participant is multiplied by the amount of these minutes. According to the Jacob Nielsen [19] research, we need approx. 8 participants to find the main usability bugs. That means two working days for Usability study.

But another problem is the participant isolation. No paper talks about that, but the problem really exists. By the term isolation we understand: the participant works over the psychical pressure. He/she is recorded by camcorders, eye tracking system, his/her ideas are recorded by “think aloud” mechanism. The participant might spend more time of investigation of some problem, than in the real live. This behaviour really exists and we recorded that during the collaborative usability study. We will be talking about this in this paper.

3.2 Collaborative Testing

The term Collaborative testing approach was defined by J. Pavlicek and R. Bock [25] for the collaborative usability lab (Fig. 5) developed at the CULS Prague as a part of HUBRU lab [25]. This approach follows the authors’ experiences gained during their work on the usability labs constructions at the California, Menlo Park USA and the CTU UI lab construction. The Jacob Nielsen usability studies tests only one person/participant during the one session. In some cases, this kind of usability test allows to test two participants. Some specific type is “baby lab”. In this case we are testing GUI used for babies. So babies are performing the test at the group. But this study focuses on children’s interaction. Pavlicek and Bock defined new lab architecture for the observing room. While the classical usability study tests only one participant, our approach can tests 10 participants together (according to Nielsen 8 is enough for classical study). It’s possible thanks to different Usability Lab architectures. In epitome we designed two crescents desks with 5 PC. The whole of the room is controlled by 4 environmental camcorders. Each PC desktop can be recorded and the middle PC’s are equipped by Eyes tracking system. So we can record the participant eyes activity during the test. The final interview can be performed at the Usability room or in the meeting room (outside the lab).

Fig. 5.
figure 5

Collaborative usability lab [25]

Full size image

Advantages

Main advantage is the price for the study. As the Usability study can be done in one lab with 10 participants simultaneously (Fig. 5), the study time is rapidly decreasing. During this kind of study, we can very quickly expose the design bugs at the GUI. Thanks to the UI Lab architecture, it’s possible to test process steps as for example:

  • call center,

  • service department,

  • customer (who needs help).

and we are able to test all mandatory business process steps in real time. This mechanism brings new horizons for GUI testing. Now it’s possible to test not only GUI, but the business steps too. Each business process, each kind of business process needs specific GUI expression. And we are able to test all possibilities in real time.

Disadvantages

We have to state [25], we don’t expose some fundamental problems during the Usability studies. The collaborative UI Study opponents discussed about the missing “Think aloud” technic. During this study type it is really problematic to be loud because it’s disturbing to the others participants. Another criticism is that during the UI study, participants can copy from the others. And another idea is, that during collaborative usability study is not possible to expose all bugs (in comparison with classical) because the UI researcher doesn’t have time to do it (because he/she has to control even 10 participants). But nothing about this was detected during our studies.

3.3 Pair Testing

Pair testing was proposed by J. Pavlicek for the K. Jelinkova [6] diploma thesis CTU FIT Prague. It is “de facto” special type of collaborative Usability study. The “Pair testing principle” follows the pair code review ideas. The code review is used for the software code quality compliance. The pair “junior - senior” or “senior – senior” check their code mutually. J. Pavlicek [25] suggested to use similar principle for the business process model quality checking. This principle is very close to reality. The process model is almost every time evaluated by more users. The situation, where the user is alone, in the stressful situation (similarly like at the classical usability study in the lab) is very improbable. The important tasks needing high level concentration on the process model, are almost exclusively the team oriented ones. During the pair testing one participant reads the process model and the test scenario, second participant finishes demanded tasks. Their consensus is thus the answer on the demanded task.

3.4 Participants Hiring

Participants were hired from students of Informatics science or engineers - software developers from business area. The age interval was from 22–38 years old. In the participants group we did not hire experienced BPM designers. The highest participant’s level of business modelling was intermediate. This condition was very important. We need to gain answers from the humans, who are close to the process modelling area, but who are not natively doing it. Laymen’s are not able to understand the problem context, experienced designers have influent the mental model and their answers are out or reality (respective out of “standard” process model users).

The time for the Usability study was not directly set. But we noticed: If the model consumes more than 10 min, the participant started to be stressed. This stress brakes the main idea of Usability which we intuitively call: “Do not make me feel dumb”. It the participant starts to feel dumb, he/she loses enthusiasms to continue the test. In this case we have to expose what happened:

  • the Usability of model is bad (it should be improved = Usability bug).

  • the test scenario is wrong (the usability researcher prepared wrong test).

  • the participant skills are not suitable to finish the task (it means, he/she is wrongly hired and it’s generally usability researcher bud – if the participant didn’t lie during the hiring questionnaire – unfortunately, sometimes it happens.).

According to these findings we can deduce quality or less quality of designed model.

3.5 Post Review

After the Usability test it is necessary to make participant’s final review. This review exposes:

  • Likes – what was great (during usability test performation).

  • Dislikes – what was wrong.

  • Recommendation – that’s very often deeply described, what should be better in the design (that is not so sharp Like or Dislike).

4 Results

4.1 The Size and the Structure Affect the Clarity of the Model

The test was conducted on the selected processes of the university study department and selected logical games. These processes are relatively simple and understandable. These processes are easy imaginable for the students (the students formed the main testing group) [6, 21, 22]. The final verification was divided into three groups:

  • cognitive Usability testing of the flat process,

  • cognitive Usability testing with the hierarchical process with nesting,

  • verification participants gained knowledge and gaining feedback.

The test was conducted in 3 groups for 7 participants.

The tested models were in paper form (with possibility also to view it electronically). The study was conducted in collaborative environment. However, there was no collaboration.

The size of the model is very important. It is an expected result. The participants worked the best with the plain model. All the information was readable from one model. The model was worse readable due to its size. It was not clear which process was the main one in the hierarchical model.

The process has the purpose to nest only in the case of the high number of the elements. The result is 4F4U:

  1. 1.

    the used elements are understandable,

  2. 2.

    the BMPN notation enables capture the modelled process with the sufficient fidelity,

  3. 3.

    the designer did not design the model precisely enough,

  4. 4.

    understanding of the model decreases with the number of the nesting and with the model size.

4.2 From What Number of Elements, Does It Make Sense to Start the Process Model Hierarchically Divided

The research team work to answer this question for a long time [5, 6, 20,21,22,23,24]. As it is stated in [6] for the testing in the second phase it was chosen 5 processes from the FEL CVUT portal. The 3 processes were prepared according to the own experience and with the supervisor consultations. She modelled 6 processes for the testing of the number of elements measure and for the depth of the process 2 processes. The methods 7PMG [9] recommends to divide the process into hierarchical with over the 50 elements. The goal was to prove or disprove this claim.

The processes for the measure of number of the elements:

  • the tax form (the process contains 27 elements),

  • the study termination due to transfer to another faculty (31 elements),

  • the study interruption (35 elements),

  • the self-employed registration form (40 elements),

  • inclusion to the specialization (university) (48 elements),

  • Erasmus study (61 elements).

The processes and the set of the questions were presented to the participants. The participants should evaluate the process after the completion of the issues. They were to evaluate, on the scale from 1 to 3, how the process was intelligible, how they could orient in the process, how difficult for them was it to understand the process and how well-arranged was the process.

The values were set as follows:

  • intelligibility: 1 (intelligible) - 2 (less intelligible) - 3 (non intelligible),

  • process understanding: 1 (easy) - 2 (slightly difficult) - 3 (difficult),

  • clarity: 1 (well-arranged) - 2 - (less well-arranged) - 3 (confused).

After every evaluation the participants could stop the study. It was very important to obtain the feedback of the participants (Table 1).

Table 1. Number of elements measure in classical test
Full size table

The table shows, that the number of the participants filling the questionnaire decreases with the higher number of the process elements. It is due to difficulty to understand the process model. The process is more complicated and less well- arranged with the higher number of elements. It is very difficult to search in the large processes. The number of errors decreases with the higher number of elements. It is given due to the fact that with the higher number of the elements decreases the number of the participants that evaluated the process. It was given due to the fact that the complex models were able to read only the experienced participants (seniors). This process is unreadable for the beginners.

That is why we introduce the collaborative test in which all the participants could advise each other and they worked still in pairs (Pair Usability test).

The table shows the significant decrease of the orientation evaluation, clarity and intelligibility. The participants could explain each other different parts of the model. They easily understood the process then.

Notice

We have to expose, that the results contain methodological error. From mathematical point of view, it is not possible to make averages from ordinal values. We should present histograms, mode or median. But none of these discussed show the model dependency strongest quality attributes, like average. And we are sure, if we used one from discussed, the result will be similar (sure - not the same) but the results will be hardly readable. Finally, we decided to make this error and we take example from Function point analysis [27] or Use Case point’s analysis [28] (which solves the same problem – averages from the ordinal values. Authors know about this methodological error, but will work with that, because there is not an easier way, nevertheless notice that).

The findings from the results we try to interpret according to [6]:

  • The process is more complicated and less well- arranged with the higher number of elements.

  • The user has the problem with the orientation in the large process.

  • Zooming into the detail the user does not have the view about the whole of the process.

  • Optimal number of elements, in which is needed to divide the process into hierarchical, is 35.

  • Maximal number of elements, in which is needed to dive the process into hierarchical, is 40.

The collaborative test showed the new result (which should be studied in the future). Time for the finishing of the usability task is limited. Especially for the Business process model probably exists (we should study it in the future) something as maximal time spend for the model comprehension. And this time probably short correlates with the process complexity. As we can read from Table 2, the big size processes are not finished in the Collaborative approach with the Pavlicek’s [25] Usability pair testing method. During the post review we gained the participants don’t want to perform so big process models.

Table 2. Number of elements measure in collaborative test with the pair testing
Full size table

5 Discussion

It is evident, that the size of the process model (number of its elements) affect the itself readability. Of course, the generalization of this problem must be placed into the context. The different evaluation will be by the experienced process model designers, and different for common user (like we described at the Participants hiring chapter). All process models are prepared by our team, and follow these ideas: the model has to be readable by common user, the model must contain the “common” symbols only, the model must follow the BPMN rules, the model must describe common process (as it is for example the course final exam enrolment). The models were focusing for common users as the students, parking system users, some internet shop users … etc. – briefly normal users who have elementary computer skills. In this context the tests were prepared and in this context it should be interpreted.

The usability pair test showed, the participants don’t want to “waste” time to read (and understand) such a big process model. This finding is very important. It says (as we discussed in the chapter “Results”) that the process model size has to be in 30–40 intervals. But it shows that the process model reader enthusiasm disappears, if the process model is so complex. This phenomenon is underlined, if work with the process more users and if they can collaborate (as is usual). In this case – could happened, the readers make deal – the process is incomprehensible. And they lose the enthusiasm to try to understand that. This is a big difference between classical usability approach, where the participant tries to finish the task (because he/she feels to be monitored and important to achieve the goal), although he/she stopped it in the real life. The collaborative usability pair test exposes this gap very early. If the process is “incomprehensible”, the participants gain the same feeling and stopped the test immediately (one human is alone – he/she can make mistake, but if two have the same opinion? It’s probably true).

The problem of elements number at the process model is not the new finding. According to 7PMG [9] is needed with the 50 elements reduce the process by nesting. This statement we propose to state. Already with the number of 30 elements the process began to be complicated for the beginner reader (non experienced). The intermediate reader (designer) begins to have the problems with more of the 40 elements. The problematic of the process nesting is one of the other dimension of the complexity. It is clear that the complex processes should be divided into subprocesses. Our research proves that the process nesting has purpose in the moment when the number of the elements is between 30–40. When the designer decides to nest the process with the less number of the elements, he unnecessarily complicates the readability and usability.

6 Conclusion

The business process model usability is possible to measure and directly influent by the suitable metrics, at the context of our 4F4U factors. The first measure, which describes the model complexity, is the number of used elements in the model. Second measure is the nesting number. Third measure is the process average nesting number. Unfortunately, we cannot define that the process is less usable if the number of nesting is 2 in comparison with number of nesting 1. It’s evident that thanks to the digital technology, the problem with number of nesting partially drops out. Especially in the comparison with the printed (hard copy) version. From this point of view, we have to keep in mind, who is the final process consumer. The context is significant here. The student visiting the university web page by the HTTP browser has with the number of nesting smaller usability issues, than the parking guidelines consumer in front of the printed version in the department store garages.