Modelling notations as BPMN imply a dominant perspective in the detriment of others, thus motivating the need of di erent stakeholders to look for di erent models of the same process. However, in BPMN, once modelled, the process de nition becomes xed into a dominant perspective, making them harder to use by the other stakeholders. In fact, it is common to see di erent models of the same processes in di erent units of an organisation (such as quality, audit, risk or human resources), each focusing speci c aspects. In this paper we present an overview of our method to consolidate di erent perspectives of the same business process into a consolidated model and than to generate on-they di erent BPMN views according to speci c stakeholders perspectives. The implementation work is ongoing but the core of the view generation method is already available.
Business Process models are fundamental to document, analyse and sustain
organisational change, as documented by multiple works related to business process
management [
Process blueprints are developed according to speci c goals as well as to the modeller's perspective. This means con icting speci cations may exist for the same process. However, and despite a number of notations and techniques assisting the modelling task, there is no agreement on the modelling criteria that can be used by di erent stakeholders. Organisations are then faced with disparate blueprints for the same process and no formal procedures to sort out their relevance. In fact, these models are probably accurate while representing the actual organisation but from the modeller's view of that particular process. Given that business processes often cross multiple organisational units, they are often shared among di erent stakeholders and represented from multiple perspectives, such as quality, auditing, information technology and security. As a result, process blueprints must be able to address the di erent stakeholders perspectives and interests and their management and sharing may be simpli ed if they are handled by a process repository.
The problem of multiple process views starts with the de nition of an
Activity. Activities comprise a number of atomic tasks, and it is up to the modeller to
decide how to aggregate them into activities. This means di erent modellers can
compose tasks into activities di erently, leading to di erent representations of
the same process. The work presented here is not new. The basic general ideas
were presented in [
Our approach allows consistent modelling of business processes and e ciently supports di erent business process views by: { Consistently integrating views from di erent stakeholders into a common and consolidated process model. This is sustained on a exible notion of activity, specifying the properties of an activity that enables further aggregation and/or disaggregation according to the desired level of detail. { Consistently generating views from a common and consolidated business process model according to the stakeholders requirements, that trigger activities aggregation or disaggregation.
In gure 1 we present the three elements of our approach. On the left the Process View Integration method, the Repository in the middle and the Process View generation on the right.
views of a business process into a single, consolidated business process model [
The Repository The repository holds: { The organisational taxonomy; { The consolidated BPMN process model; { The mapping between the activities of the consolidated process model and the leaf nodes of the taxonomy trees.
The meta-model of the repository is presented in gure 2, using an UML class diagram. A Process is composed of Flow Elements. A Flow Element can be an Activity, Gateway or Event and is connected to other Flow Elements by sequence ows (represented by the Flow Element class self-association). A Process also aggregates, for each dimension applied in the generation of views of that process, the root of the dimensions taxonomy tree, which is a Taxonomy Node. Taxonomy Nodes in turn aggregate other Taxonomy Nodes and the leafs of the taxonomy trees classify each Activity of the Process (represented by the association between the Taxonomy Node and the Activity classes).
In the current state of a airs, we only support swimlanes and the BPMN
elements presented in the gure 2. Since the BPMN standard allows a wide
scope for the swimlane elements (i.e. pools and lanes) [
a business process from a consolidated business process model [
One needs to aggregate the activities in the consolidated model according to a simple rule. The basic rules for aggregating and/or disaggregating activities are listed below.
{ Two activities and can be aggregated into an activity if and only if for every dimension one of the following two conditions applies: the taxonomy concepts mapped to and are the same; the taxonomy concepts mapped to and are di erent but their ancestor at the chosen level of detail is the same. { Likewise, an activity can be disaggregated into two consecutive activities and if and only if for any dimension the following condition applies: there exists more than one taxonomy concept mapped to at the chosen level of detail.
To better illustrate the problem and our solution, we present a scenario in section 1.1 and afterwards we present the overall solution. 1.1
This section describes the research problem by presenting the illustrative example of an automobile repair company, with the intention of promoting the readers understanding of the problem. This scenario will be used throughout the paper: "The ACME automobile repair company specialises in bodywork repairs. When a damaged car arrives to the ACME's garage, its service manager assesses the vehicle damage. Based on the service manager's analysis, a panel beater planes the damaged parts or goes to the company's warehouse to pick up replacement parts or both. After the body work repair, a painter prepares the car for spraying. The spraying is done on the company's painting greenhouse, where the service manager also inspects the quality of the nished job. If he/she believes the quality is low, the painter resprays the vehicle and it is inspected again. Otherwise, the car is ready to be delivered. This process is monitored by two departments: the Human Resources (HR) department and the Facilities Department. To perform this monitoring, each department models their own view of the process focused in the resources that each has to manage: actors for the rst and premises for the second department."
The process is performed by three actors, in three distinct locations and has six activities. Figure 3 shows the business process views designed by the HR and Facilities department. On the one hand, the HR department grouped the "Replace parts" and "Planish parts" activities because they are both performed by the panel beater. On the other hand, the facilities department grouped the "Spray car" and "Inspect painting quality" activities since they are performed in the same location (greenhouse). We refer to the former as the Who dimension and the latter as the Where dimension.
In the scope of our problem, the question that now arises is: "How do we model additional views of the process or update any of the existing views while maintaining consistency across all views?". In this very simple scenario, a process change would be easy to keep up with. However, in more complex processes (with more decision gateways, exception ows, etc.) it would take a lot of e ort to keep consistency across views. To our knowledge, there are no mechanisms to simplify the work of keeping consistency across views nor to assist the creation of new views, thus making these tasks costly and ine cient.
The method for view integration is presented in detail in [
The proposed view integration method is represented in gure 4, where the Stakeholder A and Stakeholder B lanes can represent any stakeholder willing to integrate its speci c process view. The lane Repository represents the business process repository supporting our method. The view integration process starts with the identi cation of a modelling need, followed by the activity of modelling a view of a given process. The respective view is then uploaded into the repository. At this point, the classi cation of the view elements is performed by the stakeholder, by giving the information about the desired taxonomy. These activities are repeated in the context of another view of the same process, highlighting the incremental aspect of the proposed method. In this case, we assume there are only two views to be integrated, but there could be more. The process ends with the generation of the consolidated model in the repository, based on the information introduced as input by the stakeholders.
We now present the case for the two process views shown in Figure 3. Integrating the Facilities View For this example of view integration, consider the following : { The Who and Where dimensions will be used as the taxonomy to classify the process activities; { The gateway elements will not be considered for classi cation, therefore they are connected automatically to the previous and the following elements in the consolidated business process model.
The repository is initially empty. The steps for classifying the elements of the "Facilities view" are the following: { Pool: ACME. One asks the question "From the following list, how do you classify this pool?", and the logic answer is "Organisation" and a new taxonomy node is created in both dimensions Who and Where. { Lanes: "Warehouse", "Garage" & "Greenhouse". The same question is now answered regarding the process lanes. The answer is the same for all the lanes, however, there are two valid answers: "Location" and "Organisational Unit". We consider "Location" as the answer, resulting in the assignment of all the lanes to the Where dimension. As a result, three child nodes having the "ACME" as a parent are created in the Where taxonomy tree. { Events: "Damaged car arrives" and "Car ready to be delivered". In this case, the events are automatically assigned as nodes of the When taxonomy tree root. { Activities: In this step it is asked to the stakeholder to classify each activity considering the Who and Where dimensions, with the resulting classi cation: Assess car damage - Who: Service Manager; Where: Garage; Planish parts - Who: Panel Beater; Where: Garage; Replace parts - Who: Panel Beater; Where: Warehouse;
Prepare car for spraying - Who: Painter; Where: Garage; Regarding the "Spray and inspect painting" activity, the classi cation is the following: the Where dimension has the value "Greenhouse" and the Who dimension is composed of two actors "Painter" and "Service Manager". When the latter case occurs, the activity must be drilled down so the resulting classi cation of the tasks only has one value for each dimension. Therefore, using the modeller tool, the stakeholder replaces the "Spray and inspect painting" activity with two distinct tasks, connected in this order: "Spray car" and "Inspect painting quality". These tasks must then be classi ed as follows:
Integrating the Human Resources View At this point, the repository already has information regarding the "Facilities view". We will now describe the classi cation of the elements belonging to the "HR view". The steps for classifying these elements in the taxonomy are the following: { Pool: "ACME". Now that the repository is not empty, based on the name of the element, it is suggested to the stakeholder that the lane "ACME" already exists. Since the stakeholder agrees with the classi cation of this lane as "Organisation", he selects the already existing nodes for this lane in the Who and Where dimensions. { Lanes: "Service Manager", "Panel Beater" & "Painter". This step is analogous to the one described for the classi cation of the "Facilities view". The di erence lies in the classi cation given to the lanes, which in this case is "Actor". The result of this step is adding the three lanes as child nodes of the "ACME" in the Who taxonomy tree. { Events: "Damaged car arrives" and "Car ready to be delivered". Now that the same events are already present in the repository taxonomy, the stakeholder selects them and the taxonomy remains unchanged. { Activities: In this step it is asked to the stakeholder to classify each activity considering the Who and Where dimensions, with the resulting classi cation:
Regarding the "Fix parts" activity, the classi cation is the following: the the Who dimension has the value "Panel Beater" and the Where dimension is composed of two locations "Warehouse" and "Garage". When the latter case occurs, the activity must be drilled down so the resulting classi cation of the tasks only has one value for each dimension. Therefore, using the modeller tool, the stakeholder replaces the "Fix parts" activity with two distinct tasks, connected directly or indirectly using inclusive gateways (the way of connecting these two tasks is not relevant for the activity classi cation in the taxonomy): "Planish parts" and "Replace parts". These tasks must then be classi ed as follows: { Planish parts - Who: Panel Beater; Where: Garage; { Replace parts - Who: Panel Beater; Where: Warehouse;
After uploading and classifying the elements of the "HR view", we reach the nal state of the repository that contains the necessary information for the generation of the views presented in the next section. We state so because all the elements present in both views are classi ed in the taxonomy and the relationships between the elements are su cient to produce a consolidated model and organisational taxonomy. 2.2
The generation algorithm iterates the consolidated process model to identify
patterns to which it applies the activity aggregation rule. All the activities contained
in a piece of process ow that matches a pattern are then evaluated against the
aggregation rule. If the rule can be applied, the matched process ow is grouped
into a single activity. It can take several iterations to generate the nal view
because new patterns may be generated in each iteration. The algorithm stops
when one can no longer apply any aggregation rule during an entire iteration.
Figure 5 shows the three patterns considered. These patterns are composed of
some of the patterns identi ed in [
Pattern A is the simplest. Any two sequential activities that respect the aggregation rule can be grouped into a single activity. If any, the intermediate events between the activities are also aggregated into the resulting activity.
Pattern B refers to the splitting of the process ow into an unspeci ed number of branches which must all join at the same gateway. The gateway type is not relevant. The branches must only contain at most one activity and any number of events. If the activities of all branches respect the aggregation rule, then both gateways and the branches can be grouped into a single activity.
Pattern C depicts the classic rework pattern. Both the main branch and rework branch must contain at most one activity and any number of events. If both activities respect the aggregation rule, then both branches and gateways can be grouped into a single activity,
It is expected that not all process ows respect these patterns. When that happens, it is up to the modeller to group the process elements of the generated view as they see t.
In a nal phase, the algorithm assigns a name to each generated activity, which is simply the aggregation of the names of the activities that originated it. Then, it looks for a matching stakeholder de ned name and uses it instead, whenever one is found. This mapping between generated names and stakeholder given names is updated whenever the stakeholder changes and uploads a generated view and cleared whenever at least one of the corresponding activities are removed or changed from the process repository.
In what concerns the activities positioning, a similar approach is taken. In the nal layout, a stakeholder de ned position is searched for each generated activity, and used whenever a position is found. The position information of generated views is cleared whenever one of the corresponding activities in the process model are changed or removed.
Using the car repairing process as an example, if one chooses the Where dimension at level of detail 2 and the Who dimension at level of detail 1, two given activities can only be aggregated if they are both performed in the same location (garage, warehouse or greenhouse). In this section, we provide a glimpse of the tool developed to support the generation of process views. Moreover, we also show some examples of generated views of the car repairing process that we believe will further help the readers understanding of our solution.
The tool was developed extending the Atlas [
The construction of the consolidate model, as well as future changes, is done through the process modeller. Thus, the modeller has three distinct functions: { Creation of new consolidated models (see gure 6); { Edition of existing models; { Generation of views from the existing consolidated process models.
Regarding the generation of views, we show some examples of views in gure 7 that are generated from the repository content created after using the view integration method with the views depicted in gure 3. Only two dimensions are present: the Who and Where dimensions, each with a two-level taxonomy tree, representing process actors and locations, respectively. 3 http://www.linkconsulting.com/atlas 4 https://bpmn.io
View c) clearly focuses on the Who dimension as this dimension is represented with the highest level of detail (level 2), whereas the Where dimension was set to the lowest level of detail (level 1). Furthermore, lanes were used to represent the Who dimension. In turn, view b) was generated from the exact opposite input: the Where at the maximum level of detail; the Who at the lowest level of detail; and the lanes were chosen to represent the Where dimension.
Whereas in the previously described views the focus was on one dimension, in views a) and d) both dimensions were set to the lowest level of detail and to the highest and lanes represent the Where and the Who dimension, respectively. As expected, the higher the level of detail of the dimensions, the more the process activities are decomposed; if the lowest level of detail is chosen for all dimensions, there is no activity decomposition at all.
The name of a generated activity is simply the aggregation of the names of the activities that originated it. Nonetheless, as previously mentioned, the stakeholder may choose to edit the naming and positioning of the activities. These changes are kept in the repository and used in future generation requests. 4
To demonstrate and test the applicability and usefulness of our research work, we will apply the view generation approach in real-life cases study performed within real organisations, starting from a company in the automotive retail industry.
In this proof-of-concept, the rst step is to select one business process involving several stakeholders and gather information about the chosen process from the various stakeholders, each stating its view. We follow the view integration method to merge the di erent process views from the di erent stakeholders and populate the Atlas process repository. In this process, the dimensions that better address the stakeholder's concerns will become explicit and de ned, as well as the taxonomy tree for each dimension.
Afterwards, the participants will be asked to state their concerns and to generate views that better suits such concerns, and comment on the usefulness of the generated views, thus ful lling the requirement of evaluation of our work. 5
This work served the purpose of exposing the di culties of having consistent process views, with each conveying the concerns of di erent stakeholders. Our contribution to this problem is grounded on applying a rule for business process activities aggregation and matching of work ow patterns with the ultimate goal of creating di erent process views based on existing consolidated models and organisational taxonomies.
Apart from the research work in progress, as future work we intend to
eliminate some of the limitations imposed on the consolidated business process model.
We are assuming various simpli cations on the consolidated models, although
they are still compliant with the BPMN 2.0 standard [
Moreover, the consolidated models must comply with some modelling constraints: they shall have only one start event; activities and events have exactly one outgoing and one incoming arc (except for the start and end event which do not have, respectively, any incoming and outgoing arc); split gateways have only one incoming arc and arbitrary outgoing arcs while join gateways are the opposite. Despite these limitations, this work already provides a rst glance on the generation of stakeholder-speci c business process models in BPMN 2.0.
Finally, we also aim to improve the view generation algorithm by identifying further patterns and enhance the generation of the aggregated activities' names. Besides that, we aim to generate views in notations other than BPMN.
This research was supported by the Link Consultings project IT-Atlas n 11419, under the IAPMEI 2020 PO CI Operational Program.