Reservations
Note that RAMs are intended to be a responsibility modelling mechanism and are not provided with support for automated analysis that could help to use them together with business processes during process execution. Their expressive power is high in terms of the number of responsibilities that can be assigned but low regarding the number of workflow resource patterns supported, as constraints like sod and bod cannot be defined.
The default support for responsibility management in current process modelling notations is limited. BPMN 2.0 (OMG 2011 ), the de-facto standard for process modelling, provides a mechanism to assign responsibilities to an activity. However, the only responsibility type that is defined by default is Responsible (so-called Potential Owner in BPMN). Other types of responsibilities can be added by extending the BPMN metamodel. In addition, nothing is said about the implications of adding new responsibilities during process execution.
The EPC notation (Dumas, van der Aalst, and ter Hofstede 2005 ) is more expressive than BPMN for resource modelling in the sense that it provides a specific representation of organisational units and allows defining organisational relations. However, to the best of our knowledge there is no support for responsibilities other than the resource in charge of executing the activity.
The so-called activity partitions of Unified Modeling Language (UML) Activity Diagrams (Russell et al. 2006 ) are classifiers similar to the BPMN swimlanes, although enriched with dimensions for hierarchical modelling. Therefore, they allow grouping process activities according to any criterion, which includes organisational information. Besides that, this modelling approach is very little expressive in terms of the support provided for the creation patterns (Russell et al. 2005 ). There is no notion of responsibility modelling either.
Finally, BPEL4People (OASIS 2009 ) is an extension of the BPEL notation (OASIS 2007 ) based on the WS-HumanTask specification (OASIS 2010 ), which enables the integration of human beings in service-oriented applications. It provides support for the execution of business processes with three types of responsibilities, namely: Responsible, Accountable and Informed. However, although it provides a rather flexible mechanism for defining the notifications that the people with responsibility Informed receive, the participation of people with responsibility Accountable is limited to intervening when a deadline is missed. Other forms of interaction, such as checking that an activity was correctly performed, are not allowed.
Modelling software tools, such as Visual Paradigm, 6 facilitate the automatic generation of a RACI matrix from a resource-aware BPMN model. Specifically, the responsibility type Responsible can be automatically extracted and the RACI matrix can then be manually filled out to include information about the other types of responsibilities. However, the output is just used for documentation purposes, since BPMN does not support the definition of responsibilities Accountable, Consulted and Informed.
Signavio Process Editor 7 also allows for defining RACI responsibilities in process models by making use of BPMN elements. While those models can be used for generating reports subsequently, process engines will not take into account the responsibilities Accountable, Consulted and Informed for automatic process execution.
The support for responsibility management is a novel functionality in BPMSs . Bizagi 8 and ARIS (Scheer 2000 ) allow for the definition of RASCI responsibilities in BPMN models by making use of extended attributes in process activities. Nevertheless, similar to the tools focused on modelling, only the responsibility Responsible is considered for execution and the rest are used for process documentation and reporting. RACI matrices can be defined in the Red Hat JBoss BPM Suite 9 aside of a process model for broader documentation of the responsibilities involved in the process (Cumberlidge 2007 ). To the best of our knowledge, only (YAWL) (Adams 2016 ) slightly supports responsibility-aware process execution by means of the concept of secondary resources (human and non-human), which may assist in the completion of the work (hence providing support). Any kind of support for responsibility modelling and execution other than Responsible is still missing, however, in other BPMSs, such as Camunda 10 and Bonita BPM. 11
Due to the limitations of the process modelling notations and systems for responsibility management a few research proposals have been developed to support the assignment of different responsibilities to process activities and the automation of such responsibility-aware process models. In particular, Grosskopf ( 2007 ) extended BPMN 1.0 to support accountability.
Resource Assignment Language (RAL) (Cabanillas et al. 2015b ; Cabanillas, Resinas, and Ruiz-Cortés 2011a ) is an expressive language for defining resource assignments that supports all the creation patterns (Russell et al. 2005 ). RAL is independent of the process modelling notation. Therefore, it can be decoupled from the process model or it can be integrated in it, as shown in Cabanillas, Resinas, and Ruiz-Cortés ( 2011 ) with BPMN. Furthermore, RAL is suited to be used for modelling any kind of responsibility as long as that is supported by the process modelling notation with which it is used.
A graphical notation with a similar expressive power than RAL (RALph) was designed to allow for graphically defining resource assignments in process models (Cabanillas et al. 2015a ). Similarly to the case of RAL, RALph is not actually equipped with support for modelling specific responsibilities. Therefore, that support depends on the process modelling notation with which RALph is used. Otherwise, the notation should be extended.
To a greater or lesser extent, these proposals only address responsibility modelling and they do not provide details about the implications on the execution of the responsibility-aware process models generated.
Since process execution is also a concern and the different responsibilities modelled with a process should also be considered at run time, the approach described in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ) presented a pattern-based mechanism for including specific activities in a BPMN model that represent accountability, support, consultancy and notification functions. The result is thus a responsibility-aware executable process model that can be automated by BPMN process engines. However, due to the extra elements added in order to include RASCI responsibilities, the model is likely to become unreadable and deviate from the original one, hence turning out to be less eligible for other purposes, such as documentation, due to the large amount of implementation details. As an illustrative example, applying this technique to the scenario described in Section 2 , the number of process activities would increase from 5 to 15. Moreover, the RASCI patterns defined are fixed and hence, there is no flexibility for adapting the joint use of the responsibilities to the organisational needs. Our preliminary work in this area (Cabanillas, Resinas, and Ruiz-Cortés 2012 ) also generated executable process models provided with RASCI information avoiding the aforementioned readability problem. However, flexibility remained an issue, as the way of including responsibilities in the process model was fixed.
Process templates have been defined with different notations and used for different purposes and in different domains. For instance, BPMN templates were defined for generating so-called business process studios by means of model transformations (Mos and Cortés-Cornax 2016 ). Configurable processes rely on process fragments or templates for adapting an abstract process to a specific context. They have been used, e.g., for addressing the problem of variability in service implementation, a.k.a. service differentiation, with BPEL (Tao and Yang 2007 ) as well as the problem of reference model implementation with Configurable epc (C-EPC) (Recker et al. 2005 ). In addition, configurable processes have been applied in industry to solve real problems, as described in Gottschalk, van der Aalst, and Jansen-Vullers ( 2007 ) for SAP processes.
Most of these approaches, however, focus on control-flow aspects of business process and disregard other perspectives. Nevertheless, notations like the one presented in La Rosa et al. ( 2011 ) allow for defining configurable process models considering control flow, data and resources. These three perspectives are also supported by a template-based approach for modelling process performance indicators (del-Río-Ortega et al. 2016 ).
Support for responsibility management in business processes. √ indicates that the feature is supported, ≈ indicates that the feature is partly supported, − indicates that the feature is not supported, and n/a indicates that the evaluation criterion is not applicable.
Group | Approach | Responsibilities | Modelling | Execution | Flexibility |
---|---|---|---|---|---|
Generic | RAM (Website ) | Any | out | – | n/a |
BP modelling notations | BPMN 2.0 (OMG ) | Any | in | – | n/a |
BPMN 2.0 (OMG ) BPEL4People (OASIS )/WSHumanTask (OASIS ) | RAI | in | ✓ | ≈ | |
Modelling tools and BPMSs | Visual Paradigm | RACI | out | – | n/a |
Signavio | RACI | in | – | n/a | |
Bizagi | Any | in | – | n/a | |
ARIS (Scheer ) | RASCI | in | – | n/a | |
JBoss BPM Suite (Cumberlidge ) YAWL (Adams ) | RACI | out | – | n/a | |
YAWL adams_yawl_2016 | RS | in | ✓ | – | |
Research proposals | BPMN 1.0 Ext. by Grosskopf ( ) | RA | in | – | n/a |
RAL (Cabanillas et al. ) | Any | in/out | – | n/a | |
RALph (Cabanillas et al. ) | Any | in | – | n/a | |
RASCI patterns (Cabanillas, Resinas, and Ruiz-Cortés ) | RASCI | in | ✓ | – | |
RACI2BPMN (Cabanillas, Resinas, and Ruiz-Cortés ) | RASCI | out | ✓ | – | |
Any | out | ✓ | ✓ |
All the previous approaches have shown benefits for the purpose they were conceived. However, none of them has taken into consideration activity responsibilities since they did not specifically focus on the organisational perspective of business processes.
To conduct this research we have followed design science principles as suggested by Hevner et al. ( 2004 ) and, in particular, we have applied the design science research methodology (DSRM) (Peffers et al. 2007 ) as follows:
Several conclusions can be drawn from this analysis. First, many proposals from industry (notations, modelling tools and BPMS) recognise the importance of modelling different types of responsibilities for each activity and provide some kind of support for them, although this support is limited to modelling and documentation purposes, i.e., business-oriented process models.
Second, the RASCI concepts seem to be the most extended mechanism to model responsibility management in business processes. Indeed, many software modelling tools and BPMS use them and automatically generate RAMs to model or document responsibilities. The biggest limitation of this way of proceeding is that the expressiveness of RAMs for resource assignment in business processes is restricted to three creation patterns, namely, Direct-based Distribution, Role-based Distribution and Organisational Distribution . Patterns like SoD or BoD are not supported by default by RAMs . This is not a significant problem if RAMs are used solely for documentation purposes because they can be accompanied with a description of these concerns in natural language. However, it is an important limitation if RAMs were used as the model to guide the automated execution of a process in a BPMS.
Finally, the support for automating the resulting responsibility-aware process models is limited. When existing, it either does not cover all the RASCI responsibilities or is not flexible enough to accommodate different interaction patterns between the people that collaborate in an activity with different responsibilities.
The result is that there is a gap between the responsibility types that are modelled in business-oriented process models such as the one described in the running example ( Section 2 ) or the use case ( Section 7.3 ) and the ability of BPMSs to automate their execution. Consequently, to enforce their correct execution, it is necessary to implement them by manually adding activities for them in the executable process model. This is not desirable, especially when the process model has many activities (it is not uncommon to find process models with more than 15 activities (Mendling, Reijers, and van der Aalst 2010 )) and there are several responsibilities for each activity (which is not uncommon either, e.g., in best practice frameworks). For instance, in our running example, despite its small size, at least 8 activities have to be added manually to model all responsibilities, one for each responsibility type assigned to an activity. The problem gets even worse when either the process or the responsibility assignment changes, because the modified process has to be changed by hand again. This involves first checking what has changed, then understanding the impact of this change in the modified process model and finally, changing the modified process model appropriately. This time-consuming and error-prone task is the problem we are facing in this research.
These phases were developed by means of several iterative cycles. In an initial cycle, we partially defined the problem, reviewed existing research literature and current solutions from industry, and developed an initial solution that included a first version of the RAM BI metamodel and a predefined interaction for RASCI responsibilities (Cabanillas, Resinas, and Ruiz-Cortés 2011b ). Then, subsequent cycles were necessary to refine the RAM BI metamodel, to make the approach independent of RASCI responsibilities and to give flexibility to the approach by means of the template-based technique.
A typical RAM enables an assignment of resources based on the organisational entities placed at the columns of the matrix, which usually are organisational roles. This limits the expressiveness of the resource assignments in two directions. On the one hand, it is not possible to set additional constraints related to the person assigned to the activity, such as requiring specific capabilities or excluding performers of previous activities to enforce an SOD . For instance, in the example of Section 2 the PhD student that is responsible for the activity Send Authorisation is not any PhD student but the one that prepared the authorisation form. On the other hand, it limits the ability to put additional constraints on the organisational entities used as columns. For instance, in the same example, the role project coordinator should not refer to any project coordinator, but the coordinator of the project to which the authorisation that is being requested belongs.
In the remainder of this section, we first introduce the RAM BI metamodel, then we present its semantics and at last, we provide details of a specific instantiation of the metamodel with a specific resource assignment language.
RAM BI matrices (i.e., RAMs with binding information) is the extension we propose to overcome these limitations of the expressiveness of RAMs. It complements a RAMs with binding information that provides the specific conditions that the individuals have to fulfil in order to participate with a specific type of responsibility in an activity.
These conditions are expressed using a resource assignment language. From an abstract perspective, a resource assignment language ℒ is composed of a set of expressions that use the different entities that are part of an organisational metamodel, such as people, roles or positions, for selecting elements of an organisational model defined according to the organisational metamodel. In other words, it can be seen as a query language for the organisational model. Accordingly, the semantics of a resource assignment language ℒ can be defined by a function m a p ℒ that maps each expression in ℒ to a set of elements of the organisational model that is being queried.
For instance, a resource assignment language ℒ that queries an organisational model defined according to the organisational metamodel depicted in Figure 2 could have expressions that select people that play a certain role (e.g., selecting all people that have the role researcher ) or that have performed a previous activity in the process (e.g., selecting all people that have performed activity Prepare authorisation in the current instance), amongst others. Furthermore, a resource assignment language also can have expressions to select not only people but other elements of an organisationl model such as organisational units or roles. For instance, we can query the model to obtain all positions that belong to an organisational unit.
Excerpt of the organisational model described by Russell et al. ( 2004 ).
Using a resource assignment language, a RAM BI model can be formalised as follows.
Let 𝒯𝒟 be the responsibility types that can be used in a RAMs, and let ℒ be a resource assignment language where κ and χ are the set of expressions to select organisational entities and people, respectively. A RAM BI is a tuple M = (𝒜, 𝒪ℛ, ℬℛ, o c , a r ) , where:
In this definition, the binding information is provided by functions o c and a r , namely: (i) o c indicates additional restrictions that apply to the organisational entity used as column, such as the organisational unit to which the role must belong for a specific BoundRole ; and (ii) a r is used to specify restrictions on the people that can have a certain responsibility in an activity, e.g., to have knowledge on a specific subject or to have performed a previous activity in the process.
Table 4 defines a set of auxiliary functions that are used in the following sections to manipulate the RAM BI matrix M .
Auxiliary functions for the RAM BI metamodel.
Function | Definition |
---|---|
:ℬℛ → 𝒪ℛ | It obtains the organisational role used in a . Formally: Let = ( , , ) ∈ ℬℛ be a in , ( ) = . |
:𝒜 → 𝒫(𝒯𝒟) | It obtains the responsibility types used in any bound role of the given activity according to . Formally: ( ) = { |∃ ∈ 𝒪ℛ(( , , ) ∈ ℬℛ)}. |
:𝒜 × 𝒯𝒟 → 𝒫(ℬℛ) | It obtains the bound roles that refer to the given activity and responsibility type according to . Formally: ( , ) = {( , , ) ∈ ℬℛ| = ∧ = }. |
:𝒜 × 𝒯𝒟 → { , } | It evaluates to true if and only if the given activity has at least one organisational role that has the given responsibility type assigned in . Formally: ( , ) ⇔ ∈ ( ). |
:𝒜 × 𝒯𝒟 → { , } | It evaluates to true if and only if the given responsibility type is the only responsibility type defined for the given activity according to . Formally: ( , ) ⇔ { } = ( ). |
:𝒜 → { , } | It evaluates to true if and only if the given activity has at least one organisational role that has one responsibility type assigned in . Formally: ( ) ⇔ ( ) ≠ ∅. |
Giving semantics to a RAM BI means to determine which are the people that can have a certain type of responsibility in a given activity according to the information included in a RAM BI model. To do so, we rely on a function m a p ℬℛ that determines the people that fulfill the conditions of a BoundedRole . Intuitively, this function can be defined as follows:
This can be formalised as follows.
Let O be an organisational model with P people. Let ℒ be a resource expression language that can query model O whose semantics is defined by function m a p ℒ . Let O C be the set of all possible organisational contexts for a role o r ∈ 𝒪ℛ in model O , and let p ( o r , o c ) ⊆ P be the set of people that have role o r in context o c according to O . The semantics of each BoundRole of a RAM BI M = (𝒜, 𝒪ℛ, ℬℛ, o c , a r ) is defined by function m a p ℬℛ :ℬℛ → 𝒫( P ) as follows:
This function gives semantics to the resource assignment specified in each BoundRole (i.e., in each cell of the RAM BI ). However, this does not specify the semantics when there are several BoundRoles with the same responsibility for the same activity (i.e., the same responsibility appears in more than one cell in the same row), which is common for responsibilities like Consulted, Support or Informed. Since no formal semantics for RAMs have been defined, several different interpretations can be done in different contexts:
These interpretations can be formalised as follows.
Let M = (𝒜, 𝒪ℛ, ℬℛ, o c , a r ) be a RAM BI model, and let 𝒯𝒟 be the type of responsibilities that can be used in M :
The additional constraints included by binding information may cause undesirable side effects if there is no person in the organisational model that meets all the constraints. This could happen, for instance, if we set as additional constraint for the clerk that is responsible for activity Prepare authorisation in the running example that she has the capability of speaking English and it turns out that there is no clerk with such a capability in the project. The identification of these situations is called consistency checking and it has been studied in detail in the literature (Cabanillas et al. 2015b ). Specifically, a resource assignment, such as the one specified by a RAM BI model, is consistent if it is always possible to find a potential participant for an activity during any execution of the process for any responsibility type that appears in the resource assignment.
Since inconsistencies are caused by the constraints included by binding information specified in a resource assignment language, the ability to check the consistency of a RAM BI model is directly related to the ability to check the consistency of the resource assignment language used in its binding information. This is possible with some resource assignment languages such as RAL (Cabanillas et al. 2015b ). In the next section we introduce RAL and detail how consistency checking can be implemented with it.
As discussed in the previous sections, a RAM BI model relies on an external resource assignment language to define its binding information. Next, we illustrate how RAM BI can be used with RAL (Cabanillas et al. 2015b ). We have chosen RAL because of its high expressive power, capable of supporting all the creation patterns (Cabanillas, Resinas, and Ruiz-Cortés 2011 ) and because it has a well-defined semantics that enable the implementation of analysis operations such as consistency checking. However, other resource assignment languages could also be used.
RAL is a modular (DSL) that specifies a set of expressions and constraints to define resource assignment conditions independently of any specific process modelling notation. It is composed of five modules:
The use of a specific resource assignment language in a RAM BI model has an impact concerning the type of binding information that can be used in it. Specifically, for RAL it involves the following aspects:
Figure 3 illustrates in a simplified way the use of the RAM BI metamodel with RAL using as example activity Register at Conference of the scenario described in Section 2 and Table 2 . As depicted in Figure 3(a ), the person with responsibility type Responsible is the researcher who prepared the authorisation request. Hence, there is a bod access-control constraint defined with RAL AC. As for responsibility type Consulted, it is assigned to the coordinator of the project that funds the trip to the conference, indicated in the data object Authorisation form . Therefore, the organisational context is defined with aRAL DataOrg expression.
RAM-BI models and RAL expressions for activity Prepare Authorisation.
Finally, the well-defined semantics of RAL enables the implementation of several analysis operations such as consistency checking (Cabanillas et al. 2015b ). Therefore, to check the consistency of a RAM BI model that uses RAL as its language for binding information, we just need to translate a RAM BI model into a RAL expressions and then leverage the consistency checking operation that has been implemented for RAL . This translation can be easily done using RAL expressions HAS ROLE or for the case when o c ( b ) and a r ( b ) are undefined, HAS ROLE or IN UNIT u for the case when o c ( b ) is defined and the operator AND to compose expressions for the case when a r ( b ) is defined. The result is function m a p B R R A L : B R → R A L E x p r that can be defined as follows:
Finally, o r M a p M R A L and a n d M a p M R A L , both can be straightforwardly defined by joining the RAL expressions obtained by m a p B R R A L for each bound role defined for the same task duty and the same activity with OR and AND, respectively.
RAM2BPMN is our approach to enable current BPMS to execute BPMN processes in which people with different responsibilities collaborate to complete process activities. An overview of RAM2BPMN is depicted in Figure 4 . The core idea is to take a BPMN model without resource-related information and a RAM BI model as inputs and to automatically generate a new BPMN model in which the only responsibility defined for each activity is Responsible, but which includes new activities to model the semantics conveyed by the other responsibilities included in the RAM BI model. More specifically, RAM2BPMN turns every activity for which some type of responsibility different than Responsible is defined into a subprocess. We refer to the subprocesses created during the transformation as RAM subprocesses . A RAMs subprocess is a regular BPMN subprocess that includes the specific tasks for all the responsibilities that people may have during the execution of the activity of the original process. RAMs subprocesses are created from collaboration templates . A collaboration template specifies how people with different responsibilities interact with each other to carry out an activity of a process. The collaboration template used is chosen at design-time amongst a library of templates depending on the specific requirements of the activity.
Overview of RAM2BPMN.
We have opted for this approach for several reasons. First, because it ensures that RAM2BPMN can generate models for any BPMS because the generated model only relies on defining the resource responsible for each activity, which is the only responsibility supported in BPMN by default. Second, because the additional complexity that results from including the information about different responsibilities is found only inside the RAMs subprocesses and hence, it does not affect the overall understandability of the initial process. Furthermore, the only difference between the resulting model and the initial one from the visualisation standpoint is that tasks are transformed into collapsed subprocesses.
Figure 5 depicts an example of template 13 that models the interaction of the RASCI responsibilities as it was introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ). This interaction establishes that the approval action (Accountable) takes place after the completion of the work developed for the activity (Responsible), and only then the notification action (Informed) can be performed. There is also a loop to redo the work in case it does not get the approval by the resource with the responsibility Accountable. Actions of responsibility Consulted and responsibility Support are considered to take place in parallel with the task performed by the resource with responsibility Responsible. Finally, the template includes two decision activities performed by the resource with responsibility Responsible to decide whether support or consultation are required. The template also has some placeholders that have to be filled with information that comes from the RAM BI model and the definition of the activity in the BPMN model.
Example of a template that models the interaction of RASCI responsibilities as it was introduced in in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ).
Another relevant aspect is that not all possible RAM BI models can be used with the template depicted in Figure 5 . In particular, it requires that there is exactly one bound role for responsibility responsible and at most one bound role for responsibility accountable for each activity, whereas there can be any number of bound roles for the other responsibilities. In general, each template may require a specific cardinality for the responsibilities of a RAM BI model.
The procedure that creates a RAM subprocess from a template for a specific activity of the process is the instantiation of a template . This procedure uses the information of the RAM BI and the BPMN models to fill the placeholders of the template with activity-specific information and to compose the RAMs subprocess, when necessary. For instance, Figure 6 depicts the result of the instantiation of the template in Figure 5 .
Example of the instantiation of static template in Figure 5 for activity Register at Conference of the process defined in Figure 1 .
The advantage of using templates is that each organisation may define their own library of templates to specify how people involved in an activity of a process with different responsibilities interact with each other, thus providing flexibility on the way these interactions are carried out. Furthermore, although one template is usually used for all activities of a process or even several processes, it may be the case that for a specific activity (or process) one might be interested in using a different template. For instance, for a time-sensitive activity, one might be interested in a template in which the person accountable for the activity does not only supervise the outcome of the activity but also the completion time. This can be done, e.g., by designing a template in which the task performed by the person responsible for the activity has a timer that triggers a supervision task performed by the person accountable for the activity when a predefined time has passed. Section 7.2 discusses some examples of different templates that can be used with RASCI responsibilities.
The support for different templates for each activity in the process is modelled by means of function t e m p l that links each activity to the template that must be used:
(Assignment of templates to activities) Let A be the set of activities of a process and 𝒯 be the set of all possible templates, function t e m p l : A → 𝒯 specifies which template is used for each activity of the process.
RAM2BPMN: Including resource assignment information from RAM BI into a BPMN model
1: IN : BPMN; M = ( 𝒜; 𝒪 R ; ℬ R ; o c ; a r ); templ
2: Pre : 𝒜 ⊆ activities of process BPMN
3: Pre : The resource assignment of M is consistent with BPMN
4: Pre : compatible(M; templ)
5: OUT : BPMN’ model with resource information
6: BPMN ’ ← BPMN
7: for all activity a in the business process BPMN do
8: if anyTD(a) then
9: T ← templ(a)
10: subprocess a ← instantiation of template T using BPMN and M
11: replace in BPMN’ activity a by subprocess a
12: end if
13: end fo r
14: return BPMN’
Based on the concept of template and its instantiation, the RAM2BPMN algorithm can be formalised as detailed in Algorithm 6. The input is a resource-unaware BPMN model, i.e., a model without resource assignments, ( b p m n ); a RAM BI model ( M ), and a t e m p l function.
The algorithm has three preconditions, namely: the activities of the RAM BI model must be a subset of the activities in the BPMN model (specifically, those that cannot be automated); the resource assignment of M must be consistent with bpmn (cf. Section 5.2 ), and the templates chosen by the t e m p l function must be compatible with the RAM BI model in terms of cardinality (cf. Section 6.1 ).
The algorithm can be outlined as follows. First, the b p m n model is cloned into b p m n ′ (line 6). Then, the following three steps are executed for each activity of the process (line 6) that has a resource assignment in the RAM BI model ( a n y T D ( a ) ) (line 6). First, the template associated to the activity is selected (line 6). Second, the template is instantiated using the resource assignment information provided by the RAM BI model (line 6). Finally, the activity of b p m n ′ is replaced by a subprocess created using the template instantiated in the previous step (line 6). The last step of the algorithm is to return the new b p m n ′ in which activities have been replaced by RAMs subprocesses (line 6.
Next, we delve into the two parts of the algorithm that require more details, namely: the concept of compatibility between RAM BI model and template (line 6), and the definition and instantiation of templates (line 6). The consistency checking has already been discussed in Section 5.2 .
As discussed before, not all RAM BI models can be used with a specific template because templates may require a specific cardinality for the responsibilities of the RAM BI model (e.g., they may limit the number of people with responsibility Responsible to exactly one). The cardinality of a template is defined with the template together with the specification of the interaction it models, such as the one in Figure 5 , and can be formalised as follows.
(Cardinality of a template) Let T be a template and let 𝒯𝒟 be the set of responsibilities supported by T . The cardinality of each responsibility is defined by means of function c a r d T :𝒯𝒟 → IN 0 × (IN 0 ∪ { n } ) such that c a r d T ( t d ) = ( x , y ) means that the template requires at least x bound roles and at most y bound roles for a responsibility t ∈ 𝒯𝒟 , such that x ≤ y . If y = n , then any number of bound roles greater than or equal to x is allowed.
For convenience, for each c a r d T ( t d ) = ( x , y ) we define functions m i n T ( t d ) = x and m a x T ( t d ) = y to represent the minimum and maximum number of bound roles for a responsibility t ∈ 𝒯𝒟 .
Based on the cardinality of a template, the compatibility of a template and a RAM BI model for an activity can be defined. Intuitively, a template is compatible with a RAM BI model for an activity A if all responsibilities specified in the RAM BI model for A fulfil the cardinality restrictions specified in the template. This can be formalised as follows:
(Compatibility of a template) Let M = (𝒜, 𝒪ℛ, ℬℛ, o c , a r ) be a RAM BI model , 𝒯𝒟 M be the set of responsibilities used in M , c a r d be the cardinality function of a template T , and 𝒯𝒟 T be the set of responsibilities used in T . The template T is compatible with the RAM BI model M for an activity a ∈ 𝒜 iff the number of bound roles specified in M related to activity a for each responsibility is within the constraints specified by the cardinality function c a r d :
Finally, equipped with this definition, it is easy to define the compatibility of an assignment of templates to activities ( t e m p l ) with a RAM BI model as follows.
(Compatibility of an assignment of templates) Let M = (𝒜, 𝒪ℛ, ℬℛ, o c , a r ) be a RAM BI model and t e m p l an assignment of templates to activities. The assignment of templates to activities t e m p l is compatible with M if and only if it assigns a template that is compatible with M for each activity in 𝒜 :
Figure 5 depicts an example of template for RASCI responsibilities. However, this shows just one possible way in which a template can be defined and instantiated. As a matter of fact, the only requirement imposed by the RAM2BPMN algorithm is that the result of the instantiation should be a subprocess configured using information from the BPMN and the RAM BI models. This means that different approaches can be used to define templates and their choice depends on the characteristics of the template that is being modelled as discussed in Section 6.2.3 .
In the remainder of this section, we detail two different approaches for the definition of collaboration templates and discuss their advantages and drawbacks, although other approaches could also be designed. To illustrate them, we use the aforementioned interaction of RASCI responsibilities introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ).
A static template is a process model defined in BPMN (cf. Figure 5 ) that details the interaction between people with different responsibilities within an activity with just two peculiarities:
The instantiation mechanism of these static templates just involves the replacement of all the placeholders that appear in the template. This is done by iterating over all these placeholders and replacing their value by one obtained from the RAM BI or the BPMN model. Table 5 depicts a list of the placeholders that can be used in the static template and their replacement.
Frequent placeholders and their replacement.
Placeholder name | Replacement of the placeholder |
---|---|
<activityName< | Name of the activity obtained from the BPMN model |
<responsibleBoD> | RAL expression , where is the activity for which the RAMs subprocess is created. |
<f> | Where is , or . It represents the value of the function according to the RAM model for the activity for which the RAMs subprocess is created. |
<f(TD)> | Where is , , , , , or . It represents the value of the function according to the RAM model. |
<f(BR)> | Where is , or . It represents the value of the function according to the RAM model. |
Figure 5 depicts an example of a static template and Figure 6 depicts its instantiation. The template models the interaction of RASCI responsibilities introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ) and includes gateways to bypass parts of the process in case the responsibility is not assigned for the activity. The template also has placeholders for the name of the activities so that they include the name of the activity for which the RAM subprocess is created, and the resource assignments (expressed using BPMN annotations in the diagram). In particular, activities Provide support, Provide information and Approve activity are assigned to the responsibilities Support, Consulted and Accountable, respectively. The other activities, which include the two decision and the two assessment activities, are performed by the responsibility Responsible. In the latter case, the RAL expression
is used. This allows every element within the subprocess to make reference to the performer of the activity (i.e., the new subprocess), since according to BPMN (OMG 2011 ) the allocation related to a subprocess is made before starting the activities that compose it. Note also that the responsibility Informed is different from the others because it refers to the target of the notification action (i.e., the people that are informed), not to the holder of the responsibility like in the rest of cases. Furthermore, given the definition of the responsibility Informed (cf. Section 3.1.1 ), it is reasonable to consider it an external participant of the process because, independently of her responsibilities with respect to other process activities, for the activity in question she is a target and not an executor. For this reason, the activities that correspond to the responsibility Informed are modelled as send tasks (OMG 2011 ).
Static templates provide a simple yet useful mechanism to define templates. However, more complex mechanisms can be devised. One source of inspiration for these mechanisms are configurable business processes (La Rosa et al. 2011 ). A configurable process model captures a family of related process models in a single artifact. Such models are intended to be configured to fit the requirements of specific organisations or projects, leading to individualised process models (van der Aalst et al. 2010 ). Therefore, templates can be seen as a type of configurable business processes and their instantiation can be seen as a configuration of them (Kumar and Yao 2012 ). Consequently, most approaches for defining and setting up configurable business processes can be adapted for defining collaboration templates.
In particular, fragment-based templates are based on the approach proposed in Kumar and Yao ( 2012 ) for designing flexible process variants using templates and rules. The templates are made up of two different elements that can change from template to template, namely: a set of process fragments, at least one for each responsibility; and a composition algorithm that is used for putting together all those fragments and for enabling or disabling the tasks specific to a responsibility.
Fragments must be subprocess graphs with single entry and single exit nodes (also denoted as hammocks in graph literature (Weber, Reichert, and Rinderle-Ma 2008 )) that represent the tasks that are necessary to carry out a given responsibility. Not only the same placeholders as with static templates but also ad-hoc placeholders can be used in the fragments. The value for these placeholders must be provided by the composition algorithm. Figure 7 depicts an example of fragments that belong to a fragment-based template (more examples can be found in Section 7.2 ). Specifically, five process fragments named R-fragment, A-fragment, S-fragment, C-fragment, and I-fragment are defined, one for each RASCI responsibility. Each of them have their corresponding placeholders in the names of the activities and the resource assignments.
Example of the fragments defined for each of the RASCI responsibilities in a fragment-based template.
Concerning the composition algorithm, the idea is to combine the accompanying process fragments in a meaningful way based on the information provided by the RAM BI model and the BPMN model. To describe how the process fragments are composed together, we suggest the use of change patterns (Weber, Reichert, and Rinderle-Ma 2008 ). Change patterns and in particular, a type of them called adaptation patterns, allow users to structurally modify a process model using change operations defined in terms of the process model (e.g., adding an activity in parallel to another one) instead of change primitives defined in terms of the underlying graph (e.g., adding a single node, two control flow edges, and the connectors between them) (Weber, Reichert, and Rinderle-Ma 2008 ). A consequence of this is that change operations provide a compact way of defining changes on a process because each change operation involves one or more change primitives (e.g., adding an activity in parallel involves up to seven change primitives). Furthermore, these changes tend to be easier to understand because they are defined in a higher-level way. All these reasons make change operations a suitable language to define these compositions. Table 6 shows a summary of the most frequent change operations.
Frequent change operations for the implementation of fragment-based templates.
Change operations | Meaning |
---|---|
Inserts the fragment right after | |
Inserts the fragment in parallel with the fragment | |
Embeds the fragment in a loop. and are the loop condition and the exit condition, respectively |
Together with change operations, placeholders defined in Table 5 can also be used as variables and functions in the composition algorithm. The placeholders of the process fragments are replaced during the execution of the composition algorithm. This is done by means of function replace , which receives the fragment with placeholders and returns the same fragment with all placeholders replaced with their corresponding value. The values for ad-hoc placeholders must be provided as parameters of function replace .
Algorithm 2 shows an example of composition algorithm of a fragment-based template that composes the fragments defined in Figure 7 . This algorithm is executed as part of the instantiation of the fragment-based template it belongs to, which means that it would be invoked within line 10 of Algorithm 1. The algorithm starts by replacing the placeholders in the fragment for the responsibility Responsible (line 8). Then, if responsibility types support or consulted have been defined in the RAM BI model (lines 5 and 8) it inserts in parallel fragments for the responsibilities Support and Consulted (lines 6 and 9, respectively). Next, if responsibility type accountable has been defined in the RAM BI model (line 11), it inserts sequentially the fragment for the responsibility Accountable (line 12) and embeds the whole process in a loop based on the decision made by the person accountable for the activity, i.e., whether the work is approved or not (line 13). Finally, if responsibility type informed has been defined in the RAM BI model (line 15) it inserts a fragment for the responsibility Informed for each organisational role that must be informed. This is done in several steps. It iterates over all organisational roles with responsibility Informed defined in the RAM BI model for the given activity (line 17). For each of them, it obtains its resource assignment and name (lines 18 and 19) and it inserts in parallel fragments for each of them in a temporal variable i n f o r m F r a g m e n t (lines 20–23). Finally, it inserts sequentially all these parallel fragments contained in i n f o r m F r a g m e n t (line 26). Figure 8 depicts the instantiation obtained after executing the composition algorithm for activity Register at conference according to the RAM BI model depicted in Table 2 .
Example of the composition algorithm of a fragment-based template that support RASCI responsibilities
1: IN : 𝒯𝒟 = { R ; A ; S ; C ; I } are the RASCI responsibilities supported by this template.
2: IN : R – fragment; S – fragment;C – fragment;A – fragment; I – fragment are the fragments defined in Figure 7 .
3: OUT : composed fragment
4: base ← replace(R-fragment)
5: if hasTD(S) then
6: base ← insertParallel(base, replace(S-fragment))
8: if hasTD(C) then
9: base ← insertParallel(base, replace(C-fragment))
11: if hasTD(A) then
12: base ← insertSequential(base, replace(A-fragment))
13: base ← embedInLoop(base, not approved, approved)
15: if hasTD(I) then
16: informFragment ← empty fragment
17: for all br ∈ filter(I) do
18: ra ← map M (br)
19: name ← orM(br)
20: if informFragment = empty fragment then
21: informFragment ← replace(I-fragment, ra, name)
22: else
23: informFragment ← insertParallel(informFragment, replace(I-fragment, ra, name))
24: end if
25: end for
26: base ← insertSequential(base, informFragment)
28: return base
Instantiation of the template depicted in Figure 2 for activity Register at Conference.
The decision on which template mechanism to use depends on the requirements of the specific scenario in which they are being applied. Fragment-based templates enable reusing fragments in different templates. So, one can have a repository of different fragments for the same responsibility and combine them in different ways with different composition algorithms. In addition, fragment-based templates allow a more flexible definition since the composition algorithm provides a more fine-grained control of the results of the instantiation. For instance, in Figure 8 several inform fragments were added, one for each organisational role with the responsibility Informed in the RAM BI model, which is something that cannot be easily done with static templates. Finally, the subprocess obtained from fragment-based templates tends to be easier to understand since it only includes the responsibilities that have been assigned to the activity.
However, static templates are easier to build since they do not need a composition algorithm and hence, it is not necessary to deal with its implementation. Moreover, in fragment-based templates, it is harder to detect deadlocks or livelocks introduced during the instantiation because the composition algorithm may change the control flow depending on which responsibilities are enabled for the activity at hand. This does not happen in static templates, in which the control flow is the same all the time.
Therefore, the conclusion is that fragment-based templates should be used in cases in which we are interested in building templates that have many commonalities or in cases in which we require a more fine-grained control of the instantiation. Otherwise, static templates are more appealing since that approach avoids the complexity of developing the composition algorithm.
We have validated the feasibility of the approach with a reference implementation, its flexibility with a repository of templates for responsibility modelling on the basis of the RASCI responsibilities, and its applicability by using the approach with a real scenarion from the railway automation domain.
We have developed a reference implementation of the RAM2BPMN algorithm as well as an editor for RAM BI models and a repository of templates. Furthermore, we have also implemented templates according to the modelling alternatives for the RASCI responsibilities described in Section 7.2 . An overview of the architecture designed to support the RAM2BPMN procedure is depicted in Figure 9 . A use case for the whole architecture is described as follows:
Overview of the architecture implement to support the RAM2BPMN procedure.
The templates used by the architecture can be either static templates or fragment-based templates. Furthermore, the architecture has been designed so that new types of templates could be easily added to the system.
All of the components that make up this architecture have been integrated into Collection of Resource-centrIc Supporting Tools And Languages (CRISTAL) (Cabanillas et al. 2012 ), a tool suite that provides support for the specification and automated analysis of the business process resource perspective. Information about the system can be found at
In our current implementation, there is no dedicated template editor. Instead, a BPMN model editor is used to model the static templates or the process fragments for the fragment-based templates and then, they are manually stored in the templates repository.
The templates repository is a Java library that stores the templates that have been designed for the organisation. Each template is composed of a template description file, which details the name of the template and its cardinality (cf. Section 6 ), and a set of companion files that are specific of each type of template. For instance, in a static template there is only one companion file, which is the BPMN model of the template; and in a fragment-based template there is one companion file for each process fragment and another one for describing the composition algorithm. The current implementation of the templates repository relies on a file-based storage for both template descriptions and companion files.
It is a Web application developed in Java that allows the user to define the resource information associated with the activities of a BPMN model by filling in a RASCI matrix (Website 2014 ) and optionally adding binding information with RAL (Cabanillas et al. 2015b ), as shown in Figure 10 . This editor also allows the user to specify the template that should be used for each activity in the process, i.e., function t e m p l . Both the RAM BI model and the function t e m p l are serialised into the JSON file format.
Screenshot of the RAM BI Model Editor.
The RAM2BPMN Engine implements the RAM2BPMN algorithm (cf. Algorithm 1). Specifically, it receives an XML file with the representation of a (resource-unaware) BPMN model, a JSON file with the RAM BI model and the function t e m p l , as well as a templates repository; and it returns the XML representation of the BPMN model with the RASCI information embedded in it. This functionality can be invoked from the user interface of the RAM BI Editor (cf. Figure 10 ) or from the command line.
The RAM2BPMN Engine supports the two types of templates described in Section 6 . Furthermore, the engine has been designed to allow new types of templates provided that the corresponding instantiation mechanism is integrated into the engine.
The resulting BPMN model generated is standard BPMN . Therefore, it can be manipulated in any process modelling tool and executed in a BPMN -compliant BPMS that has the required support for the resource assignment language used in the RAM BI model .
One of the main advantages of our approach is that it does not enforce any specific behaviour for the people with different responsibilities that work together on an activity, but it allows the organisation to model the interaction that best suits its requirements. Furthermore, a library of templates can be created by the organisation so that they can be reused in different processes.
In the following we validate this flexibility by modelling alternatives that can be considered for RASCI responsibilities. We focus on RASCI responsibilities because they are a well-known responsibility set used in many different domains. The modelling alternatives are obtained from our experience in different projects in which RASCI responsibilities have been modelled as well as from patterns identified in both the industry (Effektif 2016 ; OASIS 2010 ) and the related research literature (Brambilla, Fraternali, and Vaca 2011 ; Barchetti et al. 2012 ). Because the requirements of each organisation may lead to different alternatives, this is by no means a complete catalogue, but rather an illustration of the wide variety of possibilities that our approach enables.
To avoid confusion, in this section we use activity to refer to the activity of the original business process for which a RAMs subprocess shall be created and we use task to refer to each of the activities that are part of the RAMs subprocess. The modelling alternatives are introduced using BPMN 2.0 modelling concepts (OMG 2011 ).
This responsibility represents the execution of the activity itself and the coordination of other responsibilities involved in the execution of the activity such as Support, Consult or Informed. Therefore, the modelling alternatives for this responsibility come from the role it plays in the interaction with the other ones. Since these alternatives are also related to the other responsibilities, they are described in the section that discusses the respective modelling alternatives.
The modelling alternatives of this responsibility are based on whether the accountability refers to the quality of the work performed or it also refers to the fact that the work is finished in a timely manner. The former is the typical interpretation of accountability whereas the latter is useful for time-sensitive activities.
If accountability refers to the quality of the work performed, it usually involves an explicit approval of the work previously performed by the person responsible for the activity. This implies adding a task for that purpose in the template. If the work is not approved, then a loop is in place so that the person responsible for the activity has to do it again. An example of this can be found in the task Approve Activity < activityName > of the template of Figure 5 . This behaviour has been identified as the Document Approval pattern in Effektif ( 2016 )
If accountability refers to making sure the work is finished in time, it involves the inclusion of a trigger in the process that notifies the person accountable for the activity that it has not been completed in a predefined amount of time. From a modelling perspective, this involves adding a time-based non-interrupting boundary event to the task performed by the person responsible for the activity such that if a certain time has passed and the task has not been completed, the person allocated to the responsibility Accountable is notified. This behaviour has been identified as the Timed Escalation pattern in Effektif ( 2016 ) and it is also the way accountability is dealt used in OASIS ( 2010 ).
Both alternatives are not exclusive and can be used together in the same template.
The responsibilities Support and Consulted share some modelling alternatives because they have a very similar nature. Both of them involve a person to collaborate with the person responsible for the activity in its execution, being their degree of involvement in it the only difference between them. There is a wide variety of modelling alternatives for these two responsibilities based on several characteristics of the interaction, namely:
Template fragment that shows a modelling example for consult responsibility modelled as mandatory, done after some work, batches, group-based, system decided and not assessed.
Template fragment that shows a modelling example for support responsibility modelled as optional, done in parallel, anytime, group-based, responsible decided and assessed.
In addition to the aforementioned characteristics, it is also possible to model the support tasks in a more structured manner. For instance, one may create a template in which the support follows a divide-and-conquer approach. In this case, the person responsible for the activity may decompose the work to be done in small work items and assign each of them to people that provide support to the activity. After all the contributions have finished, the person responsible for the activity can merge all the work items into a final result. This pattern is typically used in crowdsourcing scenarios (Kittur et al. 2011 ).
This responsibility is modelled as a task that notifies the people that have to be informed about the state of the activity. Its modelling alternatives are based on the following characteristics of the interaction and a version of them are also present in the support WS-HumanTask (OASIS 2010 ) provides to responsibility informed:
We have applied our approch to a real scenario from industry in the railway automation domain, specifically to the process for releasing a new engineering system for a railway customer. The BPMN model of the process is depicted in Figure 13 .
An engineering process in the railway domain.
The process starts when a new agreement with a client has been signed by the project management team. A new repository is then created for the customer data by a technician and, at the same time, possible additional data are requested from the client by the engineer project manager. The next step is the actual engineering of the system, a subprocess in which the new system is built. It thus involves a large variety of resources and data coming from different data sources. The engineering project manager orchestrates and monitors the engineering tasks. Once the system is built, it must be tested before it is released for its use. That procedure takes place in a laboratory and comprises two steps: the test setup and the test execution. Prior to that, the testing project manager has to check whether the lab spaces needed must be set up for the test. Specific information about the lab settings and the system developed might be required in order to make such a decision. The employees of the organisation involved in the test setup and run steps are specialised in the execution of specific testing phases for specific types of systems, i.e., there may be an engineer who can perform the setup for a system S 1 and the test execution for a system S 2 , another engineer who cannot be involved in the testing of system S 1 but can perform both activities for the system S 2 , and so on. The setup tasks usually require one lab assistant working on one unit for a specific type of hardware in the laboratory; and the run activity usually requires several employees for its execution, in particular, one engineer who is responsible for conducting the tests and one lab assistant who provides support. When the testing of the system is finished, the testing project manager is notified, as they account for this activity. They then check the results of the test. If the results are not satisfactory, the system must be re-engineered. Otherwise, the testing project manager writes a final report that is archived together with the information generated containing the description of the test cases, test data, test results, and the outline of the findings. Information from the engineers involved in the building of the system may be necessary for writing such a report. Once ready, the engineer project manager is informed and proceeds to deploy an already complete and tested version of the engineering system, most likely helped by an engineer. The system integration team will later undertake the installation of the product, which constitutes a different process.
Table 7 shows the RASCI matrix of the process excluding the two subprocesses and Figure 14 illustrates a template that models the interaction of RASCI responsibilities for activity Run test . The template is done by composing template fragments for the responsibilities involved. Note that the alternatives described in Section 7.2 must be considered for this purpose. In particular, regarding support, it is optional for the activity and, in case it is required, it can be requested at any time and will be carried out in parallel with the rest of the execution performed by the person responsible for the activity, i.e., the engineer in charge. Only one lab assistant supports the engineer in running the test. Assessment by the engineer is not necessary as the work will later be checked for approval. In order for that to happen, the testing project manager is informed about the completion of the work and proceeds to check the outcome, hence following the Document Approval pattern.
RASCI matrix for the engineering system release process.
Engineer | Testing | Lab | Lab | |||
---|---|---|---|---|---|---|
Engineer | Manager | Manager | Manager | Assistant | Technician | |
Setup project | A | R | ||||
repository | ||||||
Request | R | |||||
customer data | ||||||
Check need | C | R | C | |||
for lab setup | ||||||
Run | R | A, I | S | |||
test | ||||||
Check | R | I | ||||
test results | ||||||
Report | C | I | R | |||
test results | ||||||
Create release | S | R | ||||
for integration |
Composition of template fragments for activity Run Test.
From the analysis of the research literature and the current approach followed in industry to responsibility management in business processes, it becomes apparent that there is an increasing demand and support for modelling activities that involve several people with different responsibilities. However, as far as process automation is concerned, the only responsibility that is managed during process execution in most proposals is the one related to carrying out the work required for the completion of the activity. Moreover, in the few cases that they support other types of responsibilities, this support is very limited in terms of generalisability and flexibility as discussed in Section 4 . This is a problem because the other responsibilities have to be implemented by manually adding activities for them in the executable process model, which is a time-consuming and error-prone task, specially for processes with a large number of activities or frequent changes in the resource assignment.
This paper introduces two novel artefacts, namely the RAM BI metamodel and the RAM2BPMN algorithm that contribute to improve the existing support for responsibility management in executable business processes in order to alleviate the aforementioned problem. Specifically, these two artefacts together enable the execution, in current BPMN engines, of business processes in which several people participate in the same activity with different responsibilities. This is done thanks to RAM2BPMN that automatically extends business process models to include in them the information about the people with different responsibilities that are specified in a RAM BI model. This extension is done leveraging templates that can be defined by the user and specify how the interaction between the people with different responsibilities must be carried out. Although the use of templates to transform BPMN models has been done elsewhere, this approach is the first time in which templates have been used to deal with the organisational perspective of business processes. Specifically, by using them, our approach fulfils the two goals defined in Section 4 , which are not supported by any of the proposals analysed in Section 3 , namely:
Furthermore, the way RAM2BPMN is designed provides the following additional advantages:
It is also remarkable that although we use BPMN as the process modelling language, the same ideas can be applied to other process modelling languages by adapting the details of the approaches described in this paper to their features. Similarly, where we use RAL one could use another language for defining resource assignments. In this case, the overall expressiveness would be that of the resource assignment language used.
However, our proposal has two main limitations. First, in the current approach, the template has to deal with the errors that occur during the process, e.g. a person that should be informed is not informed because the email server does not work. Although this is enough for most cases, it limits the ability to reuse error recovery strategies in different templates. One possible solution could be to extend RAM2BPMN so that the designer can specify which recovery strategy must be use in each activity independently of the template chosen. Second, since we are using RAL to define the resource assignments, mechanisms to process RAL expressions are necessary in order to be able to automatically calculate the potential holders of the responsibilities at run time; however, this support can be easily integrated into BPMS, as described in Cabanillas et al. ( 2015b ).
In this paper we have presented an approach to extend the existing support for responsibility management in business processes. This approach is based on a metamodel and a technique to enable the execution, in current BPMN engines, of business processes in which several people participate in the same activity with different responsibilities. A prototype of the approach has been implemented, and it has been evaluated by modelling existing interaction patterns between people that collaborate in an activity with different responsibilities and by applying it to two real scenarios.
From this work we conclude that the existing support for responsibility management can be improved in several directions. On the one hand, our proposal of RAM BI models shows how modelling responsibility assignments can be decoupled from process models unlike what is usually done in languages such as BPMN that put together the information concerning control flow and human resources. This enables a separation of concerns between process behaviour and resource assignment, which provides a better visualisation of the information concerning resource assignment. This is especially useful when modelling complex processes or when the designs of the control flow and the resource assignments are done by different persons.
On the other hand, this work shows that it is possible to create a library templates that model different interactions patterns between people that participate in the same activity with different responsibilities. What is interesting is that these templates are reused across different activities and even different processes. This encourages a new research line focused on identifying these interaction patterns and determining in which situation they are useful. Some preliminary work already exists coming from industry (Effektif 2016 ) and academy (Brambilla, Fraternali, and Vaca 2011 ; Barchetti et al. 2012 ).
As next steps, we plan to explore additional use cases together with industry. In particular, we are interested in coming up with a set of interaction patterns that can be found in different cases and to define them using a similar approach to the design patterns in software engineering (Gamma et al. 1993 ). In addition, we also plan to extend our prototype implementation to integrate it into an open source BPMS such as Camunda. 14 Specifically the idea is to integrate the implementation as a plugin so that a model is transformed right after being deployed in the BPMS in a way that is transparent to the user. We think that this would contribute to the dissemination of the tool and its integration by startups or third party companies.
This work was supported by the Austrian Science Fund [V 569-N31]; Austrian Research Promotion Agency (FFG) [845638]; European Union’s H2020 Programme [645751]; Spanish R&D&I Programme [TIN2015–70560]; Andalusian R&D&I Programme [P12–TIC-1867].
1. Please notice that the values for roles and persons are fictitious.
2. In BPMN a process takes place within a single pool. Diagrams with two or more pools, in which messages between the pools are exchanged, are called collaborations.
3. http://www.sixsigmaonline.org/six-sigma-training-certification-information/articles/the-efficient-use-of-a-six-sigma-raci-matrix.html .
4. http://en.it-processmaps.com/products/itil-raci-matrix.html .
5. For the sake of simplicity, the organisational roles that are not involved have been omitted.
6. http://www.visual-paradigm.com/tutorials/racichart.jsp .
7. http://academic.signavio.com/help/en/responsibility_assignment_acco.htm .
8. http://www.bizagi.com/ .
9. http://www.jboss.org/products/bpmsuite/overview/ .
10. https://camunda.com/ .
11. http://www.bonitasoft.com/ .
12. A Business Process can have a set of Data Objects , which can contain one or more Data Fields , whose value may change throughout process execution.
13. From now on, when we use the term template , we refer to collaboration templates .
14. http://camunda.org .
No potential conflict of interest was reported by the authors.
The time management matrix, also known as the Eisenhower matrix , is a productivity tool designed to help individuals categorize and prioritize their tasks based on urgency and importance. Renowned for its simplicity and effectiveness, this matrix enables users to identify the tasks they should focus on first, ensuring critical activities are not neglected.
The primary purpose of the time management matrix is to enhance productivity by systematically categorizing tasks. It aims to reduce stress, improve efficiency, and facilitate better decision-making when managing multiple responsibilities. By using the matrix, individuals can visually map out their tasks, ensuring that essential activities are given the attention they require, while less critical ones are managed appropriately.
The time management matrix divides tasks into four distinct quadrants:
Quadrant I: Urgent and Important - Tasks that require immediate attention, such as crises or pressing deadlines.
Quadrant II: Not Urgent but Important - Activities focused on long-term goals, planning, and personal growth.
Quadrant III: Urgent but Not Important - Distractions and interruptions that need to be minimized, like unnecessary meetings.
Quadrant IV: Not Urgent and Not Important - Time-wasting activities that should be minimized or eliminated, such as excessive social media use.
By categorizing tasks into these quadrants, users can effectively prioritize their workload, focusing on tasks that contribute meaningfully to their goals and minimizing distractions. In conjunction with modern tools like Creately, which supports visual project management and task tracking, implementing time management becomes even more efficient. For further reading, check out our article on the Eisenhower matrix .
The time management matrix stems from a long history of prioritization strategies developed to boost productivity. Its foundation lies in the Eisenhower Matrix, conceptualized by President Dwight D. Eisenhower. This method was designed to aid in managing tasks more effectively by categorizing them based on urgency and importance.
Stephen Covey brought widespread attention to the time management matrix through his best-selling book, The 7 Habits of Highly Effective People . Covey adapted Eisenhower’s original idea into a more comprehensive framework. His version further emphasizes long-term goal-oriented activities in Quadrant II, recognizing the importance of proactive planning and improvement. This distinction helps individuals dedicate sufficient time to not just urgent tasks, but crucial ones that foster growth and success over time.
The time management matrix categorizes tasks into four distinct quadrants based on their urgency and importance. This framework helps individuals and teams prioritize their tasks effectively, fostering increased productivity and reduced stress. Here’s a breakdown of the four quadrants:
Quadrant I | Urgent and Important | Crises, deadlines, unforeseen emergencies |
Quadrant II | Not Urgent but Important | Long-term planning, relationship building, personal development |
Quadrant III | Urgent but Not Important | Interruptions, non-essential meetings, emails |
Quadrant IV | Not Urgent and Not Important | Time-wasting activities, excessive TV or social media |
This quadrant focuses on tasks that require immediate attention and have significant consequences if not completed. These tasks include crises, impending deadlines, and emergencies. Managing Quadrant I effectively ensures critical issues are addressed promptly, preventing escalation into more significant problems.
Quadrant II emphasizes tasks that are vital for long-term success but do not require immediate action. Activities such as strategic planning, personal growth, and relationship maintenance fall into this category. Spending more time in Quadrant II can lead to proactive management, reducing the occurrences of crises.
Tasks in this quadrant demand immediate attention but are not crucial to achieving major objectives. These activities, often distractions, include non-essential emails, phone calls, and meetings. To maintain productivity, it’s essential to delegate or limit time spent on Quadrant III tasks. Utilizing distraction blockers can play a pivotal role here.
Quadrant IV is reserved for tasks that neither contribute to your goals nor require immediate action. These tasks are generally time-wasters, such as excessive use of social media or binge-watching TV shows. Minimizing or eliminating these activities can vastly improve productivity and focus.
By mastering the use of the four quadrants, you can better prioritize your tasks, ensuring that your time is spent on activities that matter most.
The short answer is, anyone. If you want to figure out how to allocate your time effectively to complete your daily tasks, you can use a time management matrix. Anyone who has to juggle mutliple tasks while working on different projects can benefit largely from a time management matrix, as it helps you to organize tasks according to priority and help you deliver on time.
The modern workplace has a lot of distractions. A study conducted in the UK revealed that an average employee is only productive for 2 hours and 53 minutes out of the working day. In this context, time management is more important because it helps employees to focus on what needs to be done in an effective manner.
By strategically allocating time to critical tasks, professionals can enhance productivity, reduce stress, and achieve their goals more efficiently. Mastering time management allows for better focus, improved decision-making, and increased job satisfaction. Ultimately, it empowers individuals to take control of their workload, leading to a more balanced and fulfilling career.
Increase in productivity.
The time management matrix significantly boosts productivity by highlighting tasks that truly matter. By focusing resources on Quadrants I and II—urgent and important, and important but not urgent, respectively—professionals can tackle critical tasks promptly and proactively plan for long-term goals without the distraction of less important activities. This method ensures that energies are directed where they will have the most impact.
Effective prioritization is a core advantage of using the time management matrix. It enables users to categorize their tasks intuitively, easily separating essential activities from those that can be delegated or postponed. This clarity fosters better decision-making, ensuring that the most vital tasks are attended to first, which can be particularly beneficial for product managers like Riley overseeing complex projects.
By methodically addressing critical tasks in Quads I and II, the time management matrix reduces the occurrence of last-minute emergencies and distractions. This systematic approach can lead to a substantial decrease in stress levels, as users are not constantly firefighting or feeling overwhelmed by unmanageable to-do lists.
The matrix also enhances the tracking and visualization of progress, a feature that is amplified with visual workspaces like Creately. With its collaborative planning and real-time execution capabilities, Creately allows teams to see exactly where they stand on various projects. Tools like project visualization and task management can ensure that everyone is on the same page, further bolstering productivity and ensuring timely completions.
Implementing the time management matrix can streamline your workflow and enhance productivity. Here’s a step-by-step guide to help you start using this powerful tool effectively.
Begin by listing all tasks and responsibilities you need to manage. Use a comprehensive approach to ensure you don’t overlook any critical activities.
Once you have identified all tasks, classify them into the four quadrants of the matrix:
Quadrant I: Urgent and Important - Tasks that need immediate attention, such as crises or pressing deadlines.
Quadrant II: Not Urgent but Important - Long-term planning, relationship building, and personal growth activities.
Quadrant III: Urgent but Not Important - Interruptions, meetings, and tasks that can be delegated.
Quadrant IV: Not Urgent and Not Important - Time-wasting activities like excessive social media use.
After categorizing, prioritize tasks within each quadrant. Focus on completing Quadrant I tasks first to avoid negative consequences. Aim to spend more time in Quadrant II for strategic planning and growth.
Develop a schedule to manage your tasks efficiently. Allocate specific time blocks for Quadrant II activities to ensure you stay proactive and prevent crises from arising. Platforms like Creately offer real-time task tracking to help visualize workflows and maintain a balanced schedule.
While having a schedule is crucial, flexibility is equally important. Stay adaptable to accommodate unexpected tasks or changes. Reviewing your schedule regularly helps in making necessary adjustments.
Minimize time spent on tasks in Quadrant III and IV by using distraction blockers. Tools integrated into platforms like Creately can help eliminate non-essential interruptions, keeping you focused on more important tasks.
Mastering the time management matrix can revolutionize your productivity and task prioritization. Here are some invaluable tips:
Your first step is to determine what tasks align most closely with your goals. Ask yourself which tasks hold significant consequences if left unattended. This practice will help you continually focus on your most critical work.
Speed is essential. Develop the habit of instant classification by questioning the urgency and importance of each task. Using the matrix regularly will sharpen this skill, enabling quicker decision-making.
Allocate dedicated blocks of time for Quadrant II activities—important but not urgent tasks. This can help you reduce future crises and emergencies.
Consider tools and strategies to automate, delegate, or outsource Quadrant III and IV tasks. This can free up precious time for more critical activities.
Implementing distraction blockers can significantly enhance focus. Use software to block non-productive websites and apps during work hours.
Deploying these tips effectively can make the time management matrix an indispensable part of your productivity arsenal, boosting your ability to manage tasks efficiently across different projects.
Overloading quadrants: It’s easy to pile too many tasks into the urgent and important quadrant. Regularly reassess and redistribute tasks to prevent burnout.
Neglecting quadrant 2: This quadrant often holds long-term planning and improvement activities. Ensure you dedicate sufficient time to it for sustainable productivity.
Inaccurate task categorization: Misplacing tasks in the wrong quadrant can lead to inefficient time allocation. Regularly review and adjust as needed.
Failing to adapt: The matrix is a tool, not a rigid structure. Be flexible and modify it to fit your changing priorities and workload.
Ignoring time estimates: Underestimating task duration can lead to schedule overloads. Accurately estimate time requirements to maintain control.
Professional use case examples.
Consider a product manager, Riley, who oversees the development and launch of new products. Using the time management matrix, Riley can categorize her tasks effectively:
By allocating tasks to these quadrants, Riley ensures that urgent and important tasks receive the highest priority, while simultaneously making time for long-term planning and minimizing distractions.
On a personal level, let’s take the example of a student using the time management matrix to handle academic and extracurricular responsibilities:
By using the time management matrix, the student can focus more on important tasks and less on time-wasting activities, leading to better academic performance and personal growth.
The time management matrix is an effective tool to prioritize what is important and enhance productivity. By categorizing tasks into four distinct quadrants based on urgency and importance, users can focus on what truly matters, plan proactively, and minimize distractions. Implementing this matrix involves steps such as identifying all tasks, categorizing them, setting priorities, creating flexible schedules, and using distraction blockers.
Using the time management matrix can transform how you handle your daily tasks, allowing for better organization, clearer goal-setting, and more efficient use of your time. Tools like Creately’s visual workspace not only support the matrix by enabling collaborative planning and execution but also offer features like task management and real-time tracking, making it easier to stay on top of your priorities. Don’t let stress and disorganization hold you back. Embrace the time management matrix to streamline your work processes and improve your overall productivity and well-being.
Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.
Who popularized the time management matrix, how are tasks categorized in the time management matrix, what are some practical tips for implementing the time management matrix, why should i use the time management matrix, how does a tool like creately fit into using the time management matrix, more related articles.
Hansani has a background in journalism and marketing communications. She loves reading and writing about tech innovations. She enjoys writing poetry, travelling and photography.
IMAGES
COMMENTS
Getty. The responsibility assignment matrix (RAM) is a form of project management that encourages everyone to understand every step of the project. Looking at the chart involves all parties and ...
RACI is a project management acronym for the different responsibility types within a project: Responsible, Accountable, Consulted, and Informed. The RACI matrix clarifies the roles named individuals or groups will play in the successful delivery of the project. Accurate RACI matrices can help ensure a project's success before it even begins.
Draft the responsibility assignment matrix using a table with the project tasks listed on the left-hand column. Across the top add the name of everyone in the project. Where the tasks meet the project team member, assign whether they're responsible, accountable, consulted or informed. When completed, share the responsibility assignment matrix ...
Assigning RACI roles and responsibilities to TeamGantt tasks. Open your project, and toggle to the RACI tab. This will display all your project tasks in a list format (rows). On the right side of the matrix, you'll see a column for each person currently invited to the project with cells for each task in the project.
A RACI chart—also known as a responsibility assignment matrix—is a diagram used in project management to define team roles across 4 categories: Responsible, Accountable, Consulted, and Informed. It helps clarify who does the work, who calls the shots, whose opinion matters, and who needs to stay in the loop for each task, milestone, or ...
Key Takeaway: A Responsibility Assignment Matrix (RAM) is a useful tool for project managers to assign tasks and responsibilities to team members. It can help improve communication, increase accountability, track progress more accurately and reduce risk. There are two main types of RAMs: Functional (F-RAM) and Projectized (P-RAM), each with ...
In business and project management, a responsibility assignment matrix [1] (RAM), also known as RACI matrix [2] (/ ˈ r eɪ s i /) or linear responsibility chart [3] (LRC), is a model that describes the participation by various roles in completing tasks or deliverables [4] for a project or business process.RACI is an acronym derived from the four key responsibilities most typically used ...
Master the responsibility assignment matrix today! ... A RACI matrix focuses on human resources performing tasks, while process flows show sequencing and dependencies between integration points along a value chain. Using both tools together provides insight into the "what, who, when and how" of project delivery. ...
This matrix clearly identifies which role each team member has agreed to take on for each of the project's main deliverables. With these assignments, you can eliminate miscommunication about who's doing what - and you can help to ensure that your project is successful. You've accessed 1 of your 2 free resources.
Responsibility Assignment Matrix (RAM): this article explains the Responsibility Assignment Matrix or RAM for short in a practical way. Next to what it is (including an in-depth explanation video), this article also highlights an example, inlcuiding the steps to conduct, to use it during a complex project and downloadable and editable Responsibility Assignment Matrix template to get started.
Introduction to Responsibility Assignment Matrix (RAM) Project management is a complex process that involves multiple stakeholders, tasks, and resources. To ensure the success of a project, it is crucial to assign clear roles and responsibilities to team members and accurately define their tasks. One tool that can help project managers achieve ...
A resource assignment matrix or a RAM you might see it referred to on the PMP exam, shows the project resources assigned to each work package. Each thing that we're working on and who is working on it. It is used to illustrate the connections between work packages or activities and the project team members. An example of a resource assignment ...
This video describes the Resource Assignment Matrix, from the Project Management Body of Knowledge. The most common RAM is a RACI - who is Responsible, Acco...
This comprehensive blog aims to provide you with a complete overview of the Responsibility Assignment Matrix and its pivotal role in Project Management. 01344203999 - Available 24/7. Courses ... Optimal Resource Allocation: Project managers can optimise resource allocation by understanding task ownership and workload distribution as described ...
RACI matrix is a simple approach to defining project roles and responsibilities that help produce desired outcomes. This term is an acronym that stands for Responsible, Accountable, Consulted, and Informed. RACI essentially describes the different roles assigned to team members involved in the project and details who does what.
Credit: track5/Getty Images. A Responsibility Assignment Matrix (RAM), sometimes known as a RACI chart, is a tool used in project management to keep track of all responsibilities assigned to cross-functional teams on a specific task or assignment. It's known as a RACI chart because its acronym names the four key roles displayed in the matrix:
Below is a list of the 6 (six) most common steps in developing a Responsibility Assignment Matrix (RAM). Step 1: List all project tasks and deliverables. Step 2: Identify all project stakeholders. Step 3: Determine the responsibility and accountability level for each task and deliverable. Step 4: Assign stakeholders to each task.
Implementing a Responsibility Assignment Matrix (RAM) in your project management process provides several key benefits: Clarity in Roles and Responsibilities: By defining who is responsible, accountable, consulted, and informed, a RAM eliminates confusion and prevents task overlap. Everyone is fully aware of the expectations placed on them.
The RACI Matrix, also called a Responsibility Assignment Matrix, visually represents the roles and responsibilities of stakeholders involved in a project. Using a RACI matrix template, project managers can easily assign tasks and clarify each individual or group's role in the project. The RACI Matrix definition is Responsible, Accountable ...
The goal of the Responsibility Assignment Matrix (RAM) is to clearly define roles and responsibilities of everyone on a project team. This ensures that everyone understands their role and how it fits into the bigger picture. RAM also allows for quick identification of whom to contact when an issue arises.
Here are some steps to follow: Identify the resources required for each project or task. Develop a resource allocation matrix that assigns resources based on priority and criticality. Monitor resource utilization and adjust allocation as needed. Integrate the RAM with project management tools and processes.
A resource matrix, also known as a staffing matrix or resource allocation chart, is a visual representation that maps project tasks or activities against the resources required to complete them. It provides an overview of the project's resource needs and helps in identifying potential bottlenecks or imbalances in resource allocation.
The responsibility assignment matrix can receive information from: Scope baseline; Requirements documentation; Stakeholder register; It is a data representation tool that provides information to the resource management plan in process. Plan Resource Management in the PMBOK® Guide - Sixth Edition. It is progressively elaborated as more ...
A Responsibility Assignment Matrix (RAM) provides a way to plan, ... This enables a separation of concerns between process behaviour and resource assignment, which provides a better visualisation of the information concerning resource assignment. This is especially useful when modelling complex processes or when the designs of the control flow ...
Implementing this matrix involves steps such as identifying all tasks, categorizing them, setting priorities, creating flexible schedules, and using distraction blockers. Using the time management matrix can transform how you handle your daily tasks, allowing for better organization, clearer goal-setting, and more efficient use of your time.