Int. J. Organisational Design and Engineering, Vol. 2, No. 1, 2012 61

Copyright © 2012 Inderscience Enterprises Ltd.

Collaborative maintenance of business process models

Nuno Castela* Center for Organizational Design and Engineering, INESC INOVAÇÃO, Rua Alves Redol, n°9, 1000-029 Lisbon, Portugal and Polytechnic Institute of Castelo Branco, Av. Empresário, 6000-767 Castelo Branco, Portugal E-mail: ncastela@ipcb.pt *Corresponding author

Paulo Dias Polytechnic Institute of Castelo Branco, Av. Empresário, 6000-767 Castelo Branco, Portugal E-mail: paulo.dias@ipcb.pt

Marielba Zacarias Center for Organizational Design and Engineering, INESC INOVAÇÃO, Rua Alves Redol, n°9, 1000-029 Lisbon, Portugal and Research Center for Spatial and Organizational Dynamics, University of Algarve, Campus de Gambelas, 8005-139 Faro, Portugal E-mail: mzacaria@ualg.pt

José M. Tribolet Center for Organizational Design and Engineering, INESC INOVAÇÃO, Rua Alves Redol, n°9, 1000-029 Lisbon, Portugal and Department of Information Systems and Computer Science, Instituto Superior Técnico, Technical University of Lisbon, Campus Alameda, Av. Rovisco Pais, 1, 1049-001 Lisbon, Portugal E-mail: jose.tribolet@inesc.pt

Abstract: Enterprise modelling helps improving individual and organisational self-awareness by allowing sharing knowledge about the organisation among its human actors through graphical representations. In order to achieve this goal, enterprise models must not only offer a trustworthy and reliable

62 N. Castela et al.

representation of different enterprise concerns, but such representation must be up-to-date. The work presented in this paper defines a collaborative ‘as-is’ business process model updating process that uses the annotation mechanism to create interaction contexts and enable business actors to communicate their knowledge about organisational processes turning it explicit and to discuss existing process representations in order to update them. The proposed approach allows actors to act as active updaters and modellers of the as-is business process model by comparing modelled with actually executed activities. The benefits of this approach have been gathered through several case studies in real organisational environment where a collaborative enterprise modelling tool was deployed to support the defined process.

Keywords: business process modelling; as-is business process model; model updating; collaborative business process modelling tool; business process maintenance.

Reference to this paper should be made as follows: Castela, N., Dias, P., Zacarias, M. and Tribolet, J.M. (2012) ‘Collaborative maintenance of business process models’, Int. J. Organisational Design and Engineering, Vol. 2, No. 1, pp.61–84.

Biographical notes: Nuno Castela is an Assistant Professor at Polytechnic Institute of Castelo Branco and an Invited Researcher at the Center for Organizational Design and Engineering (CODE/INESC-INOVAÇÃO). His areas of interest in research are enterprise engineering, enterprise architecture, business process modelling, collaborative modelling and business process updating processes and tools. Currently, he teaches system analysis, databases and information systems architecture courses. He received his PhD in Information Systems and Computer Engineering (2011) from the Instituto Superior Técnico, Technical University of Lisbon.

Paulo Dias is an Invited Teaching Assistant at Polytechnic Institute of Castelo Branco. He holds an Information Technology Engineer and a Information Systems and Technology MSc, from the University of Beira Interior, Covilhã, Portugal.

Marielba Zacarias is a Computer Engineer (1982) with an MSc in Systems Engineering (1996) and a PhD in Informatics and Computers Engineering (2008). She has a professional experience of over 25 year in the information systems field. She is an Assistant Professor of Electronics and Informatics Engineering Department and a member of Research Center for Spatial and Organizational Dynamics (CIEO), at the Algarve University. After her PhD, she has worked mainly in organisational modelling and ontologies, focusing particularly in modelling organisational contexts, and has published 28 refereed scientific papers in those areas.

José M. Tribolet is a Full Professor of Information Systems and holds a joint appointment as a Full Professor at the Engineering and Management Department of the Instituto Superior Técnico, the Engineering School of Lisbon’s Technical University. He is the Executive Director of POSI-E3. He received his PhD in Electrical Engineering and Computer Science from MIT (1977). He was a member of the research staff of Bell Laboratories, from 1977 through 1979. He spent a full sabbatical year (1997–1998) at MIT’s Sloan School of Management. He founded and is the President of INESC – Institute for Systems and Computer Engineering.

Collaborative maintenance of business process models 63

1 Introduction

Enterprise engineering brings together concepts, methods and technologies which allows to understand, model, develop and analyse all the changing business aspects through the focus on the relationships and dependencies among strategy, processes and the supporting information systems (Tribolet, 2005). Enterprise architectures are enterprise engineering frameworks that allow representing organisations from different perspectives where the most commonly used include strategy, process, application and technology perspectives (Schekkerman, 2006). The process perspective describes business processes and is used to communicate, document and understand activity in organisations (Caetano et al., 2004).

The ‘as-is’ business process model represents current organisational processes, in contrast with the ‘to-be’ model, which reflects future changes to processes resulting from business process oriented management practices such as BPR, TQM and BPM. The general goals of as-is business process models construction are: redesigning or improve the organisation (Davenport, 1993; Hammer and Champy, 1993), improve enterprise integration (Goul and Corral, 2007), act as a starting point to information systems architecture (Sousa et al., 2005) and to requirements gathering in information systems development (Loucopoulos and Kavakli, 1995), control running processes (Bernus, 2003; Vinturella, 2005) and act as knowledge repository of organisations.

Enterprise models, with the contribution of individual knowledge of all who work in organisations, can help to gather and make organisational knowledge explicit, transforming organisations in learning organisations (Boudreau and Robey, 1996; Magalhães, 2005).

Enterprise models have to accommodate different points of view; individual, group and organisational, but at the same time the consistency of the whole model has to be guaranteed, allowing representing organisational self-awareness (Magalhães et al., 2008). To achieve this it is necessary to understand the interaction dynamics among organisational actors and the roles they play in such interactions. One important aspect in understanding actor interactions is the notion of context. This concept is an essential means to filter relevant information and appropriate behaviour for business actors in specific situations. The acknowledgment of specific rules governing interaction contexts plays a key role in managing actor interactions (Zacarias et al., 2004).

Nonetheless, it is acknowledged that in current enterprise modelling practice, companies are creating business process models to use in specific projects occurring at a given time and that the maintenance of those models is a difficult task.

These facts have hindered enterprise modelling to become a solid foundation in supporting daily activities by acting as an organisational knowledge repository. As-is enterprise model, despite being recognised as one important organisational asset, is not continuously updated, because maintaining this representation is not a trivial question (Castela and Tribolet, 2004).

The work presented in this paper aims to establish a process to automate and streamline the management and updating of business process model in order to align it with reality, using a collaborative process. To achieve this, some research goals were defined:

64 N. Castela et al.

• Definition of an as-is enterprise model updating process and a supporting collaborative tool to align the model with the operational reality. This process recognises organisational actors as key agents to reduce the gap between organisation and its representation, through misalignment detection.

• Definition of a misalignment detection mechanism – the annotation, supporting the actor interactions required to keep business process models up-to-date and aligned with their actual execution. The annotation mechanism should be also the key in establishing and keeping open conversation channels between actors (the parts) and organisation (the whole) in order to facilitate discussions and negotiations between all stakeholders involved in the updating context.

Section 2 summarises related work. In Section 3, the as-is enterprise model dynamic updating process (PROASIS) is presented. Section 4 describes the collaborative supporting tool (named MAPA) developed. Section 5 presents the conclusions and future work.

2 Related work

Organisations are complex adaptive systems created and maintained through the interactions of its organisational actors (Mitleton-Kelly, 2003) and as such, obeys to principles such as connectivity, inter-dependence, self-organisation, emergence and co-evolution. Organisational actors are the individuals, which can form groups of individuals, working in organisations, which in turn are also complex and adaptive entities with capacities to act, monitor, analyse, learn and change (themselves and the organisation).

Thanks to its learning nature, the organisation and its actors are in constant change (Magalhães and Tribolet, 2007; Nonaka and Takeuchi, 1995). There are several disciplines that address planned organisational change, like business process management (van der Aalst et al., 2003; Ko, 2009), total quality management (Robertson et al., 1995), change management (Zayas-Castro et al., 2002), to name a few. However, due to their complexity, organisations are subject to emerging and therefore not planned changes (Heylighen, 1989; Mitleton-Kelly, 2003).

The implementation of activities is constrained by human-social factors such as needs and motivations of the actors involved, the tools as mediators between the actors involved, and shared socio-cultural rules (Constantine, 2006). In addition, activities are subject to constant change. The social nature of activity implies that is performed in a collective manner at group level. Activities consist of actions taken by individuals involved in them.

Operations in organisations are described in terms of processes and activities where the processes are composed of activities flows. Activities are an abstraction of what the organisation does. The definition of activities in these areas involves shared understandings about their objectives, resources consumed and produced, roles and procedures involved. A single organisational actor may have several behaviours. Due to their multi-tasking nature, each actor can have multiple personal contexts and participate in various group or inter-personal contexts. Their behaviour is determined by the role played under certain context (Zacarias et al., 2010).

Collaborative maintenance of business process models 65

Enterprise architecture has several perspectives (strategic, organisational processes, information, application, technology) (Schekkerman, 2006; Lankhorst, 2005). The process perspective describes processes at several organisational levels (operational, management, knowledge) (Laudon and Laudon, 2004). The as-is business process model represents the operational level of the organisations at current time. The creation and maintenance of operational processes models involve communication and negotiation processes between the actors involved (Habermas, 1984; Rittgen, 2007).

2.1 Organisational self awareness

Tribolet (2005) defines organisation as the result of actions executed by human and non-human actors arranged in socio-technical systems that self-realise themselves through actions and interactions of its components. In this definition, the concept of organisational self awareness appears naturally as the result of the complex intersection of various consciences – individual, group, functional and procedural – that guide the current action in organisations, depending on the contexts invoked. Zacarias et al. (2008) specifies this notion indicating that the organisational self awareness is the capacity that organisations have to respond to questions at any specific time about their activities, resources and actors.

Business process models have a key role in representing knowledge and organisational self awareness and in the possibility of serving as a subject of conversation to incorporate more knowledge in an iterative and incremental way. This role is due mainly to the intrinsic characteristics for the dynamic representation of organisational actions and interactions focused on process implementation as sequences of orchestrated activities. The processes and activities are the elements that contain all the information about how, when and who does the work flow (Magalhães and Tribolet, 2007).

The concept of organisational self awareness is the result of a process that involves, firstly, the efforts of each individual member of an organisation to know its surroundings using their senses and their ‘sense-making’ (Weick, 1995). This personal ability to learn and understand the environment is influenced by many factors, some related to the psychological profile of each individual, others related to the individual work environment.

2.2 Business process modelling

A model is an abstract representation of reality. A business model is “a symbolic representation of the company and the things that it is dealing with” (Whitman et al., 2001).

A business processes model (one of the views of the enterprise model) can be defined as “a computational representation of the structure, activities, processes, information, resources, people, behaviour and restrictions of a business, governmental entity or other organization. The business process model allows the designing, analysing and operation of companies” (Fox and Gruninger, 1998).

One of the most common activities for the modeller is the documentation of existing business processes in organisations (Bhaskar et al., 1994). The stage prior to the modelling process deals with the collection of information that will constitute the

66 N. Castela et al.

information and work flows. In this stage, empirical studies related to interview techniques and analysis of available documentation can be used (Weske et al., 1999).

Business process models should be able to provide several pieces of information to its users. These elements include, for example, which activities compose the business process, who performs these activities, how and why are implemented, and what informational elements manipulate. Any modelling technique should be able to represent one or more of the following modelling perspectives: functional, behavioural, organisational and informational (Giaglis et al., 1999).

Business process models offer an effective mechanism to clarify, communicate and distribute the knowledge about the operation of the company. Therefore, they can be a valuable repository and be used in managing that organisational knowledge (Magalhães and Tribolet, 2007).

2.3 CSCW and collaborative modelling

According to Borghoff and Schlichter (2000), the widespread use of personal computers and associated networks meant that these resources began to be used to work collaboratively, so the designations computer supported cooperative work (CSCW) and groupware were introduced. The CSCW designation refers to the creation of a research field, and groupware refers to the solutions and tools designed to support collaborative work in practice.

The role of individual members of groups is an important aspect in the development of CSCW tools, because the roles help to structure the interactions between team members and to define the functionalities and access rights of the group. The roles define the social function of individuals in relation to group process, to group organisation and relatively to other group members. The roles define rights and obligations in relation to group process.

Groupware systems send notifications when something changes. This feature eases the self-awareness of the individual and the group itself and, moreover, the actions that occur in competition. The notifications inform all users involved in a group of changes made to a shared environment.

Ellis et al. (1991) define groupware as “computer-based systems that assist groups of people who share a common task (or common purpose), which provide an interface to a shared environment”. The goal of groupware is to support communication, collaboration and coordination of group activities.

Rittgen (2007) suggests that while the modelling literature is abundant, the majority describes the use of notation in a descriptive way, instead of a prescriptive way, because the most common problems that people experience during the modelling process are not issued. Of the descriptive approaches, only a few are dealing with collaborative modelling based on groupware systems. All the others assume the scenario where only one modelling expert creates a formal model.

However the following issues should be taken into account:

• the development of a model is rarely done by just one modeller, but by a team

• the problem domain of business modelling is unstructured and formal languages have a limited use

Collaborative maintenance of business process models 67

• the objective of providing a tool for collaborative modeling requires the identification of detailed stages involved.

To Rittgen (2007), modelling is a kind of conversational negotiation. The conclusions drawn from the social and pragmatic levels of the organisational semiotics ladder, through the observation of individuals involved in the business modelling process over three years, were the following:

• at the social level, it was found that social norms among the modelling team are mainly made of rules to determine whether a proposal is accepted or rejected

• at the pragmatic level, two types of behaviour were discovered, and each one can be classified into two subcategories: understanding, which is concerned with the text of the description of the case or with the modelling language and organisation of the modelling process, which involves negotiation.

Most activities at pragmatic level are associated with a negotiation process that follows a certain pattern (Figure 1).

Figure 1 Negotiation pattern

Source: Rittgen (2007)

According to Rittgen (2007), groupware systems for collective sense-making address an important issue in collaborative modelling and can be used as the core of a support modelling system, so there is a need to implement a component of negotiation that facilitates the structuring of arguments and decisions regarding modelling choices.

2.4 Collaborative enterprise modelling tools

A business processes modelling tool is an automated system that provides capabilities to build business process models (Gonzalez and Framinan, 2010).

68 N. Castela et al.

Gonzalez and Framinan (2010) identifies a set of features necessary to collaborative tools for modelling business processes and analyses a set of commercial tools to check whether these features identified are implemented. In general most of the tools analysed provide collaborative features, but many of the features are not present unless, in some cases, all modules have to be purchased, or in other cases, some modules have to be purchased from other vendors. The collaborative features considered most important include: web publishing or exporting to HTML, model viewer, information reports, version control allowing the comparison of different versions of the same model, user profiles, comments and notes adding (this feature is particularly important when several participants working in the same model at different times, asynchronously), ability to disaggregate/aggregate (allowing the dividing of the model into parts, so that participants only work on their part accordingly) and other collaborative features not included in the analysis: notification to alert the participants that changes were made to the model during the asynchronous work and chat for discussion among participants.

2.5 Software engineering processes updating and annotations

The area of processes and models maintenance is transverse to the knowledge areas where models are used to represent the reality related with productive processes. Some perspectives, like the evolution of processes and models in software engineering, brought some contributions to this work.

Software processes models support the performance of procedures by establishing a common understanding and terminology. Most software development organisations use process models created by process engineers. In practice these models are often outdated, since the software processes evolve over time (Becker-Kornstaedt and Reinert, 2002).

Software processes are complex entities that last long periods of time and run through the interaction of humans and computer-based tools. These processes require development in order to be adapted both to organisational changes or technological changes that occur over time. The production of high quality software has become very complex and difficult to manage, mainly due to (Conradi et al., 1993): evolving technologies and working methodologies; the variability and unpredictability of the human processes; and because the life cycle of processes is too long.

The use of the annotation concept in the course of this work is based on the vision of Becker-Kornstaedt and Reinert (2002) who applied this mechanism to capture the reasons for the changes that are normally made in software projects, caused by the implicit knowledge of development teams. Annotations should capture the activities, resources and context involved. The continuous improvement of processes requires that the experience is captured to be continuously incorporated into business processes and continually portrayed in as-is model. The systematic capture and storage in the context where the experience was captured has three major benefits (Becker-Kornstaedt and Reinert, 2002): it can become explicit; it may be incorporated in the description of processes; and can be reused in other processes for process improving.

3 Defining the process for updating the business process model

PROASIS is a collaborative process that is supported by organisational actors who participate in the running processes of organisations. These actors should dynamically

Collaborative maintenance of business process models 69

compare the represented processes with the processes where they participate, detecting the misalignments between them. This misalignment analysis uses the annotations as a mechanism to gather the updates proposed by organisational agents.

PROASIS is executed by organisational actors performing the activities that compose the business processes and share a common representation of business processes. Annotations allow actors to make proposals for correcting the model (corrective maintenance), capture changes in action or interaction contexts (adaptive maintenance), make free comments that could anticipate problems (preventive maintenance) and promote process continuous improvement (perfective maintenance).After making an annotation on a modelling element (which depends on the level of granularity), may exist negotiation with the actors who eventually share the same context of action. This negotiation/discussion involves all stakeholders of the annotated element in order to clarify the original purpose of the annotation. All actors involved in this review should declare the agreement or disagreement with the annotation made to the model element.

Figure 2 Negotiation pattern and steps of PROASIS cycle (see online version for colours)

Annotation

ReviewEva

luation

Update

70 N. Castela et al.

After the review of the annotation, the annotation should be evaluated by the actors enabled to do so, having some degree of responsibility on the executed activities or on the organisational actors involved. If the evaluation of the annotation (and any reviews made to it) results in an approval, the changes requested in the annotation could be incorporated in the new version of the process model by the modeller. Figure 2 shows the structure that identifies the generic activities in PROASIS (annotation, review, evaluation and update) and shows the negotiation pattern involved in review and evaluation steps, based in the negotiation pattern of Rittgen (2007) (Figure 1).

3.1 PROASIS application scenario example

In the scenario used to illustrate the operation of PROASIS, an organisation having two organisational units (department 1 and department 2) is considered (Figure 3). The department 1 has a responsible (R1) and three executors (A1, A2 and A4). In turn, the department 2 has a responsible (R2), and the actor A3 performs his work there.

At activity level of detail it is necessary to know who executes each activity and who owns the process (Figure 4).

Considering the scenario described, if an annotation is made at the activity level of detail, by actor A1 to activity X1 (Figure 5) belonging to his context of action in the operational model, the actor A1 who has an operational model role as executor starts playing the role of annotator in PROASIS.

In the case described in this scenario, the A4 is an actor who also executes the same activity as A1, which now has attached the annotation made by the actor A1 (see Figure 4). The actor A4, who plays the role of executor in the operational model, becomes a reviewer in PROASIS, so he can review the annotation made by the actor A1, initiating a period of conversation/negotiation on the proposed update/amendment expressed in the initial annotation done about the activity X1 (annotated model element).

Figure 3 Organisational chart

Collaborative maintenance of business process models 71

Figure 4 Processes (see online version for colours)

Figure 5 Annotation of an activity (see online version for colours)

72 N. Castela et al.

When an actor makes an annotation, if there are more actors executing the annotated activity, they will be invited, trough a notification, to review the annotation (this information is part of the operational model, because the reviewers are all executors of the annotated activity). Then, the responsible of the organisational unit to which actors belongs, and the owner of the business process to which the annotated activity enter into a negotiation stage as evaluators to approve or not approve the annotation. If the annotation is approved the necessary changes will be made to the model by the modeller.

Another example that can be considered is when an annotation is made to a modelling element that exists in an interaction context between actors in the operational model. Here the role of the actor is the same as in the case of an individual annotation, because the annotator actor does not need to know whether the annotation involves more actors. That will depend on the context of modelling element that is annotated.

For example (Figure 6), if an actor makes an annotation to the workflow that goes from activity X1 to activity X2 (and this annotation can be a corrective annotation of type: should not go for X2 but for X25), and as the activity X2 is not executed by the same actor, but by actor A2, he is involved in the review of the annotation made by A1, which actor A2, the actor A4 (which executes X1) and even the actor A1 (the annotator) can review.

Figure 6 Annotation of a workflow (see online version for colours)

Figure 7 Annotation of an informational entity (see online version for colours)

Collaborative maintenance of business process models 73

Another similar case occurs when an actor makes an annotation to an informational entity consumed or produced by the activity that he executes (Figure 7). In this scenario, if the actor A1 makes an annotation to the informational entity IE1 that is produced by X1 and consumed by X3, which in turn is executed by actor A3, this annotation has to be reviewed by the actors A1, A3 and A4.

When an actor makes an annotation to a modelling element shared by other actors, they all become reviewers. Then the responsible of the organisational units where they work and the owners of the process to which the annotated activity belongs enter into a negotiation stage (as evaluators in PROASIS) to approve or disapprove the annotation made. Note that in this case it is possible that we are dealing with an annotation between the activities of two distinct processes, which are executed by actors who belong to different departments. If the annotation is approved, the necessary changes will be made to the model by the modeller.

A process annotation, made by the process owner acting as annotator in PROASIS, can be done spontaneously or after the analysis of the annotations made by the executers of the activities that comprise the process that he owns. In the scenario considered, if process X is annotated, the heads of department 1 and 2 (as well as the annotator) will be responsible for reviewing the annotation because this process is composed by activities that ‘cross’ department 1 and 2 (see Figure 4).

If the model is constructed only up to the process level of detail, only the processes owners, the organisational units responsible and the set of executers are known. It can be assumed, optionally, that either the process owner or the executors of the activities that comprise the process can make annotations. The set of executers, the process owner and in addition, the organisational units responsible can participate in the reviewing of annotations. Consequently, the evaluation is made by the owner of process and/or the organisational units responsible involved. If the original annotation is adopted this could lead to a new version of the as-is model. In the case of an annotation made by an organisational unit responsible to an organisational unit as a modelling element, it will be reviewed by the owners of processes which have activities that are executed by actors working for the organisational unit annotated.

The actor roles in PROASIS depend on the modelling element that is annotated, relating the actor roles in the operational model with the actor roles in PROASIS. If the annotated element is an activity, flow, informational entity or information system, the annotation and subsequent revisions are made by the executors and the evaluation is made by the process owners and the organisational units responsible. If the annotated element is the business process, the annotation is made by the process owner and the review and evaluation are made by the organisational units responsible and the process owners. If the annotated element is the organisational unit, the annotation is made by the organisational unit responsible and reviews and evaluation are made by the process owners and the organisational units responsible.

4 MAPA: PROASIS supporting tool

The PROASIS supporting prototype tool, named monitoring and annotation of processes and activities (MAPA), was developed in the present work scope, inheriting the assumptions and concepts outlined in Section 3 of this document.

74 N. Castela et al.

MAPA was defined and developed as a groupware tool that allows dynamic update of the business process models in a collaborative way, with the following general requirements, based on the necessities identified to support PROASIS in real organisational environment:

• Annotation editing functions: actors need support to make immediate annotations in context where the experience occurs. Therefore, an annotation creation, modification and deleting system must be created to be used by organisational users.

• Different levels of granularity: it should be possible to annotate any object (process, activity, role, resource, relation) in the process model as well as any attribute of each object.

• Selective distribution of diagrams and modelling elements: users only access information that concerns them, depending on the role played (executor, process owner and organisational unit responsible).

• Access rights: different levels of access rights should be addressed to protect the authors of the annotations. Only the author of an annotation must be able to delete or modify it.

• Ability to save and browse the entire history of models and their annotations, and the corresponding reviews and evaluations.

• Mapping annotations to entities: it is essential to know to what object each annotation corresponds to.

• Notification mechanisms: to warn organisational actors about the need to participate in the reviewing and/or evaluation of annotation made and to warn about changes made to the diagrams due to the approved annotations.

• Diagram drawing capabilities: to allow annotator actors to make graphical annotations with proposed changes to models or to allow modeller actors to directly change the diagrams if the proposals for changing the model was approved.

In order to verify if these functionalities already exist in some tool in the market, four commercial tools were examined in the scope of the present work. Two of them were also studied by Gonzalez and Framinan (2010): system architect and ARIS, and the other two were not: enterprise architect and ADONIS. For each of the tools reviewed, the intention was to study the existence of mechanisms for business process model sharing and dissemination by organisational actors, promoting discussion and collaboration to update them. These tools have characteristics of models distribution through the diagrams publication in standard formats trough web portals. Regarding the model updating, system architect, enterprise architect and ARIS have centralised repositories where models are stored with versioning mechanisms allowing, to each version of the diagrams, to keep information about the date, modeller and reasons for creating new version. ADONIS has a workflow release feature allowing the proposed diagrams to be published only after approval. Any of these tools, which support the BPM and software development processes, is suited to support business processes design and development performed by expert modellers. The common organisational actor can only use these tools to consult the business processes modelled.

Collaborative maintenance of business process models 75

The MAPA tool saves the as-is business processes model (organisation, processes, activities, informational entities, flows, information systems) in a relational database system guaranteeing the integrity of the as-is business process model and the corresponding annotations, reviews and evaluations.

The interaction with several end users of all case studies implemented provided information to refine the initial requirements of the tool, which lead to the incorporation of new features in MAPA v2:

• incorporation of BPMN specific elements (event types, activity types, etc.)

• improved diagram visualisation in order to allow the comparison of the update proposal diagram (graphic annotation) with the current diagram

• improvement of notifications sent by e-mail, indicating the actor who did the action, the annotated process, the annotation/revision/evaluation type and a direct link to the tool (website)

• introduction and improvement of administration functionalities (creation of processes, users, user groups, roles, etc.)

• introduction of options that enhance the interaction, such as the ability to record a diagram without sending a notification and without generation of history, which allows the incremental recording of diagrams, only sending notification when the diagram is complete.

In the version of MAPA used in the case study described in the following section, the interaction allows direct diagram handling, so it also presents a palette of BPMN modelling artefacts. The interaction at this level can be carried out either by annotators who propose changes to the diagrams, or by the modellers who change the diagrams, updating them. Figure 8 shows the screenshot of the MAPA tool.

Figure 8 MAPA tool (see online version for colours)

76 N. Castela et al.

This screen shows in the left, the process navigation area. In the upper central area is the toolbar (which varies depending on the user’s role) and in the centre is the drawing area (where the diagrams are presented, and can be changed using the palette of the BPMN modelling artefacts presented in the left of the drawing area).

The following section describes a case study, in which PROASIS and MAPA tool have been used.

5 Case study

The purpose of the case study presented was the application of PROASIS and MAPA for updating the activities and business processes at Social Security District Centre of Castelo Branco (CDSSCB).

5.1 Background

The Social Security District Centre of Castelo Branco (CDSSCB) is part of the Social Security Institute. The district centres are the organisational and administrative basis of Portuguese Social Security System, responsible for implementing the necessary steps for the development, implementation and management of benefits under the Social Security System. The organisational goals are: timely payment of benefits, struggle against social exclusion and fraud and support workers, families, children, elderly and companies.

In this scope, MAPA was used to update 19 business processes business processes modelled from scratch using mainly a bottom-up approach, starting from gathering the actions executed by each organisational actor. Then, an abstraction of actions to define activities was made involving the organisational actors. Finally, the defined activities were embedded in their processes, which were gathered from the organisational units responsible. At the end of this modelling phase, 2 processes from District Interlocutors Team, 12 processes from Financial Management Team and 5 processes from Administration and Assets Team, were modelled.

5.2 Using PROASIS and MAPA

A sequence of annotation, reviews, evaluation and updating of the business process ‘handling complaints’ (‘Tratamento de Reclamações’, in Portuguese) is showed in the next figures. The original version published in MAPA tool that actors who belong to the Financial Management Team had access is shown in Figure 9.

In this context, a graphical annotation (Figure 10) with an alternative proposal to this process was made (Figure 11). The organisational actor who made the annotation of the type correction said “from the activity response to the request for additional data given by the beneficiary does not go to activity response to the complaint request, but for the previous activity: analysis of current account of the beneficiary”.

Collaborative maintenance of business process models 77

A draft diagram proposal was attached to this annotation showed in Figure 11. Figure 12 describes the review and evaluation made to the annotation described in

Figures 10 and 11.

Figure 9 First version of the business process ‘handling claims’ (see online version for colours)

Figure 10 Annotation (see online version for colours)

78 N. Castela et al.

Figure 11 Alternative model proposed within the graphic annotation (see online version for colours)

Figure 12 Reviews and evaluation of the graphical annotation made (see online version for colours)

Collaborative maintenance of business process models 79

In Figure 12 we can see that the annotation was reviewed by three organisational actors, which agreed with the annotation. We can also see the result of the evaluation made by the organisational unit responsible, which approved the annotation.

Figure 13 Second version of the business process ‘handling claims’ (see online version for colours)

The approval of the annotation, together with the approvals of other annotations made to the first version of the diagram (Figure 10), resulted in a new version of business process diagram, which is shown in Figure 13. Note that the full history of the previous versions is saved and can be accessed by selecting it on the process navigator in the left side of the screen.

5.3 Results

Table 1 summarises the global results obtained in this case study in the first PROASIS cycle. These quantitative results derived from a series of parameters that were measured through the analysis of MAPA data in order to characterise the use of the tool. These parameters include the number of annotated processes, the number of annotations made to the processes (text and graphics), number of reviews (agreements/disagreements), number of evaluations (approvals/rejections) and the number of new versions of processes produced. The number of annotations in each category was also accounted.

80 N. Castela et al.

Table 1 Summary of results of the case study

PROASIS cycle Summary of results (CDSSCB – Phase 2)

Modelling Modelled processes 19 Annotation Annotated processes 14

Number of annotations made to the processes 29 Percentage of processes annotated 73.7%

Textual annotations 16 Percentage of textual annotations made 55.2%

Graphical annotations 13 Percentage of graphical annotations 44.8%

Review Number of reviews made 41 Percentage of annotations reviewed 75.9%

Reviews of type ‘I agree’ 40 Reviews of type ‘I do not agree’ 1

Evaluation Evaluations made 26 Percentage of evaluated annotations 89.7% Evaluations of the type ‘approval’ 26

Modelling New versions of processes modelled 14 Percentage of updated processes 73.7%

Thirteen organisational actors were involved in this case. In the District Interlocutors Team, 4 organisational actors played the roles of annotator and reviewer and 1 played the roles of evaluator and modeller; in the Financial Management Team 5 organisational actors played the roles of annotator and reviewer and one actor played the roles of evaluator and modeller; In the Administration and Assets Team, 3 actors played the roles of annotator and reviewer and 1 actor played the role of evaluator and modeller.

In this case study, 29 annotations were made to the 19 modelled processes. 75.9% of the annotations made were reviewed. With a total number of 41 reviews made, only one review was made to declare non-agreement with the annotation, the remaining 40 reviews were made to declare agreement with the correspondent annotation. 89.7% of annotations were evaluated, all of the evaluations made (26) result in approvals of the corresponding annotations. These approvals have resulted in the creation of 14 new versions of the business processes distributed with MAPA v2. Another result from this case study is the following: 41.4% of the annotations made were of category ‘correction’, 27.6% were of category ‘adaptation’ and 31.0% were of category ‘detail’.

Some qualitative results were also obtained through interviews conducted with the organisational actors involved in the case studies.

From a total of 16 responses to the interviews, and relatively to PROASIS, the results indicate that 88% of the organisational actors made annotations to the models and reviews to the annotations, and 19% made evaluations and created new versions of the diagrams distributed with the MAPA tool. All actors considered important to discuss the process updating and the widespread deployment of MAPA tool to all processes of the organisation where they work. 93% of organisational actors have made textual annotations and 40% used graphical annotations. 94% of organisational actors considered

Collaborative maintenance of business process models 81

important the discussion possibility that the reviews allow. The organisational actors also expressed their opinion about the benefits that regular use of the MAPA tool could bring to organisations, proposed changes or improvements that should be used to refine the MAPA tool, opined about the possibility of creating new versions of the diagrams directly the tool and suggested improvements to this functionality.

When asked about the advantages that the regular use of the MAPA tool could bring to the organisation where they work, some of the most relevant answers of organisational actors were: ‘The collaborators can propose improvements and optimise their activities’; ‘MAPA facilitates the participation of employees in modelling and analysis of processes and allows the registration of employees multiple opinions’; ‘MAPA improve knowledge about the functioning of services by all employees’; ‘Gives opportunity to discovery possible constraints in the processes’; ‘New users can be aware of the process, improving learning about context and implementation of activities’; ‘Turn visible what each one does in the organisation’; ‘It allows discussing how to execute the business activities’.

An important conclusion that can be drawn from this case study is related to the familiarity that organisational actors demonstrated regarding the business process models presented. It was found that the organisational actors recognised themselves in the diagrams and began making annotations on the same day that the MAPA tool was released. This acceptance must be related to the bottom-up methodology used to build the business process model, directly involving the executers through the gathering of actions, from which the activities were abstracted.

6 Conclusions and future work

The tool to support the business process model updating process is currently being used at two public organisations (Social Security District Centre of Castelo Branco and Technology Superior School of Castelo Branco) and at a private organisation, a multinational automotive parts factory (Huf Portuguesa). PROASIS and MAPA tool are also being autonomously used in other organisations (University of Algarve and Viriato Theatre Company).

Available results in all the case studies developed showed that initially the actors mostly made annotations as corrections to the distributed model, allowing however the involvement of all actors connected directly (executers) or indirectly (process owners and organisational units responsible) in validating (and thus updating) the business process model, aligning it with the reality in an collaborative and interactive. So, annotations and their extensions fit the requirement of being a suited mechanism to make actors talk about their activities and thus proposing changes to the enterprise model, involving negotiation.

The introduction of MAPA in a real organisations revealed that it could have an important role not only in gathering the information needed to update the model (beyond the initial important role in the validation of the initially constructed model), but also because it allowed the opening of a communication channel, for gathering and sharing knowledge about the activities of the organisation.

PROASIS is important in the growth of self-awareness because it provides explicit representations to the organisational actors that are left with a better sense of what they do and the surrounding context. It was also important in increasing self-awareness of

82 N. Castela et al.

groups around processes and activities. The organisational self-awareness gained from the contribution and explanation of group and individual knowledge through the creation of the historical evolution of the business processes (versions of the process diagrams), which contains all the history of annotations (and its negotiation/discussion) that culminated, at certain moments in time, with the proper evolution of the modelled processes, aligning them with their implementation in practice.

The future work, in operational terms, will focus on the improvement of the MAPA tool in order to accommodate new requirements gathered in the course of the case studies. In theoretical terms, it will focus on exploring the negotiation patterns in the scope of PROASIS and in the defining annotations categories in the context of business process models.

References Becker-Kornstaedt, U. and Reinert, R. (2002) ‘A concept to support process model maintenance

through systematic experience capture’, SEKE ‘02, 15–19 July, Ischia, Italy. Bernus, P. (2003) ‘Enterprise models for enterprise architecture and ISO9000:2000’, Annual

Reviews in Control, Elsevier, Vol. 27, pp211–220. Bhaskar, R., Lee, H.S., Levas, A., Pétrakian, R., Tsai, F. and Tulskie, B. (1994) ‘Analyzing and

re-engineering business process using simulation’, Proceedings of the ACM’s 1994 Winter Simulation Conference.

Borghoff, U. and Schlichter, J. (2000) Computer-Supported Cooperative Work: Introduction to Distributed Applications, Springer, Germany.

Boudreau, M-C. and Robey, D. (1996) Coping with Contradictions in Business Process Re-engineering, Information Technology & People, Vol. 9 No. 4, pp.40–57.

Caetano, A., Silva, A. and Tribolet, J. (2004) ‘Object-oriented business process modelling with roles’, 7th ISIM, Czech Republic.

Castela, N. and Tribolet, J. (2004) ‘Representação As-Is em Engenharia Organizacional’, 5ª CAPSI, Lisboa, Portugal, 3–5 Novembro 2004, ISBN: 972-99387-1-7.

Conradi, R., Fernström, C. and Fuggetta, A. (1993) ‘A conceptual framework for evolving software processes’, ACM SIGSOFT Software Engineering Notes, Vol. 18, No. 4, pp.26–35.

Constantine, L.L. (2006) ‘Activity modelling: toward a pragmatic integration of activity theory with usage-centered design’, Technical paper, Laboratory for Usage-Centered Software Engineering, Department of Mathematics and Engineering, University of Madeira, Funchal, Portugal.

Davenport, T.H. (1993) Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press.

Ellis, C.A., Gibbs, S.J. and Rein, G.L. (1991) ‘Groupware: some issues and experiences’, Communications of the ACM, January, Vol. 34, No. 1.

Fox, M.S. and Gruninger, M. (1998) ‘Enterprise modelling’, AI Magazine, AAAI Press, Fall, pp.109–121.

Giaglis, G., Paul, R. and Serrano, A. (1999) ‘Reconciliation of business and systems modelling via discrete event simulation’, Proceedings of the ACM’s 1999 Winter Simulation Conferences.

Gonzalez, P.P. and Framinan, J.M. (2010) Tools For Collaborative Business Process Modelling, Business Information Systems: Concepts, Methodologies, Tools and Applications, Vol. 4, pp.636-648, Information Resources Management Association, USA.

Goul, M. and Corral, K. (2007) ‘Enterprise model management and next generation decision support’, Decision Support Systems, Elsevier, Vol. 43, pp915–932.

Collaborative maintenance of business process models 83

Habermas, J. (1984) The Theory of Communicative Action: Reason and the Rationalization of Society, Beacon Press.

Hammer, M. and Champy, J. (1993) Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business.

Heylighen, F. (1989) ‘Self-organization, emergence and the architecture of complexity’, in Proceedings of the 1st European Conference on System Science, AFCET, Paris, pp.23–32.

Ko, R. (2009) A Computer Scientist’s Introductory Guide to BPM, ACM Crossroads, Summer, Vol. 15, No. 4.

Lankhorst, M. (2005) Enterprise Architecture at Work: Modelling, Communication and Analysis, Spinger, Germany.

Laudon, K. and Laudon, J. (2004) Management Information Systems, Prentice Hall. Loucopoulos, P. and Kavakli, E. (1995) ‘Enterprise modelling and the teleological approach to

requirements engineering’, International Journal of Intelligent and Cooperative Information Systems.

Magalhães, R. (2005) Fundamentos da Gestão do Conhecimento Organizacional, Sílabo. Magalhães, R. and Tribolet, J. (2007) ‘Engenharia Organizacional: das partes ao todo e do todo às

partes na dialéctica entre pessoas e sistemas’, Cap. do livro ‘Ventos de Mudança’, Editora Fundo de Cultura, Brasil.

Magalhães, R., Sousa, P. and Tribolet, J. (2008) ‘The role of business processes and enterprise architectures in the development of organizational self-awareness’, Polytechnical Studies Review 2008, Vol. VI, No. 9, ISSN: 1645-9911.

Mitleton-Kelly, E. (2003) ‘Ten principles of complexity & enabling infrastructures’, in Complex Systems & Evolutionary Perspectives of Organisations, Elsevier, ISBN 0- 08-043957-8.

Nonaka, I. and Takeuchi, H. (1995) The Knowledge-Creating Company, Oxford University Press. Rittgen, P. (2007) ‘Negotiation models, advanced information systems engineering’, 19th

International Conference, CAiSE 2007, Trondheim, Norway. Robertson, J.L, Subrahmanian, E., Thomas, M.E. and Westerberg, A.W. (1995) ‘Management of

the design process: the impact of information modelling’, Fourth International Conf. on Foundations of Computer Aided Process Design Conference, AIChE Symp. Series No. 304.

Schekkerman, J. (2006) How to Survive in the Jungle of Enterprise Architectures Frameworks, 3nd ed., Trafford Publishing, Canada.

Sousa, P., Caetano, A., Vasconcelos, A., Pereira, A.and Tribolet, J. (2005) Entreprise Architecture Modelling with Unified Modelling Language, IRM Press.

Tribolet, J. (2005) ‘Sistemas de Informação Organizacionais’, Chapter ‘Organizações, Pessoas, Processos e Conhecimento: Da Reificação do Ser Humano como Componente do Conhecimento à ‘Consciência de Si’ Organizacional’, November, Edições Sílabo – Ed. L. Amaral.

van der Aalst, W., ter Hostfede, A. and Weske, M. (2003) ‘Business process management: a survey’, in Proceedings of the Business Process Management International Conference.

Vinturella, J. (2005) Management Briefing Business Process Management (BPM): Must Have?, available at http://management-briefings.jbv.com, (accessed on 30 April 2005).

Weick, K.E. (1995) Sensemaking in Organizations, Sage Publications, Thousand Oaks. Weske, M., Goesmann, T., Holten, R. and Striemer, R. (1999) ‘A reference model for workflow

application development processes’, Proceedings of the International Joint Conference on Work Activities Coordination and Collaboration, pp.1–10.

Whitman, L. and Ramachandran. K. and Ketkar, V. (2001) ‘A taxonomy of a living model of the enterprise’, Proceedings of the 2001 Winter Simulation Conference.

Zacarias, M., Magalhães, R., Caetano, A., Pinto, H.S. and Tribolet, J. (2008) ‘Towards organizational self-awareness: an initial architecture and ontology’, in P. Rittgen (Ed.): Ontologies for Business Interactions, pp.101–121, IDEA Group.

84 N. Castela et al.

Zacarias, M., Pinto, H.S., Magalhães, R. and Tribolet, J. (2010) ‘A ‘context-aware’ and agent-centric perspective for the alignment between individuals and organizations’, Information Systems, Vol. 35, No. 3, pp.271–374, in press.

Zacarias, M., Pinto, S. and Tribolet, J. (2004) ‘Redes de conhecimento em engenharia organizacional: o imperativo dos contextos de acção’, Cadernos BAD, No. 1, pp.6–23.

Zayas-Castro, J.L., Crowe, T.J. and Alvarez, H.R. (2002) ‘Organizational change: a case for more systematic and dynamic modeling’, Industrial and Manufacturing IERC 2002 Conference Proceedings, Orlando, 19–21 May.