modeling e-government business processes: new approaches to transparent and efficient performance

8/17/2019 Modeling e-government business processes: New approaches to transparent and efficient performance

1/20

Information Polity 14 (2009) 91–109 91DOI 10.3233/IP-2009-0168IOS Press

Modeling e-government business processes:New approaches to transparent and efficient

performance

Hafedh Chourabi, Sehl Mellouli and Faouzi Bouslama∗

Management Information Systems Department, Faculty of Business Administration, Universit́ e Laval,

Pavillon Palasis-Prince, 2325, rue de la Terrasse, local 2507, Qu ´ ebec (Qu´ ebec) , Canada G1V 0A6

Abstract. Many governments worldwide are restructuring their business practices to improve their performances. To helpdescribe and understand the process of restructuring, modeling techniques are used at different levels of modeling abstraction.This paper presents a new approach to the modeling of e-government business processes. It is based on two existing modelingtechniques: Business Process Mapping (BPMapping) and UN/CEFACT Modeling Methodology (UMM). The BPMappingtechnique provides an overall graphical representation of an organization depicting all different types of business processes,their inputs, outputs, and the environment in which the organization operates. The UMM methodology with its different businessviews gives details on collaborations and interactions of business processes. Combining BPMapping with UMM leads to a veryexpressive modeling approach which can provide artifact details at the higher levels of modeling abstraction and which alsoshows deployment strategies of the business processes. To illustrate the effectiveness of the proposed approach, it is applied tothe modeling of the Record Integrated Management business process at Quebec Government.

Keywords: BPMapping, UMM, Business process modeling, e-Government, Record Integrated Management, Business domainview, Business requirements view, Business transaction view

1. Introduction

In recent years, government organizations in many countries are witnessing major transformationswhere business practices are restructured and business processes are re-engineered to achieve moretransparency and to improve performances. Governments are transforming themselvesto become a single

entity qualified as an enterprise that will offer a single entry point to all citizens. This transformationis done at two levels [15]: the front office transformation to achieve a single multi-channel entry pointsuch as a Portal, and a back-office transformation where all business processes are integrated to achievethe pooling, sharing, and reusing of information and common components.

To achieve the back-office transformation, governments need to have a global vision that can be

documented and described through a Government Enterprise Architecture (GEA) [1,2] and its architectureframework [9,24,32]. This global vision offers to governments a common framework of reference to all

Ministries and Agencies (M-A) [7]. The framework allows any M-A not only to position its projects withrespect to other projects, but also to anticipate the opportunities of pooling, sharing and re-utilization [21]

∗Corresponding author: Pavillon Palasis-Prince, 2325, rue de la Terrasse, local 2507, Université Laval, Québec (Québec),Canada G1V 0A6, Tel.: +1 418 266 5872; Fax: +1 418 656 2624; E-mail: [email protected].

1570-1255/09/$17.00 © 2009 – IOS Press and the authors. All rights reserved


2/20

92 H. Chourabi et al. / Modeling e-government business processes

Fig. 1. The four main levels of modeling abstraction.

by developing interoperable and inter-connected systems, and by the reusing of informational entities andcommon components securely and in accordance with international norms and standards. The use of theframework contributes to the transparency and efficiency of the back-office processes [14]. Moreover,governments adopting an architecture framework are able to close the gap between their current/futurestrategy and the ability of their supporting information technology (IT) while improving the effectiveness

of their performances and business processes.The performance of government organizations can be improved through restructuring and management

of the business processes in governments’ M-As. This restructuring act implies a business process re-engineering (BPR) and management [30] while focusing on three main concepts of pooling, sharing, andreuse of the common components. Prior to re-engineering of government business processes, there is aneed to model the business processes in order to provide an abstract representation [16,18,26,31] whichshould facilitate the analysis and the design of solutions that can improve the execution of the businessprocess.

There are several techniques andmethodologiesto model business processes: BPMN [8], Petri Nets [3],

UN/CEFACT Modeling Methodology (UMM) [28], Business Process Mapping (BPMapping) [4,20], andUML 2.0 Activity Diagrams [25]. The modeling process usually runs through three main levels of ab-

straction, a conceptual, a logical and a physical level, respectively [27,29] to organize any architecturalartifacts. However, the modeling process must also take into consideration the reality of the businessdomain [31] necessitating adding another level of modeling abstraction. This business context andrequirements dimension is expected to help modelers achieve more comprehensive and realistic mod-els [29]. Figure 1 depicts the different levels of modeling abstraction. At each level, the modelingprocess generates artifacts that describe to varying degrees of details how business processes operate and

collaborate in any legal framework and constraints, how these processes are supported by informationand technology, who the artifact targets and which particular issue is addressed.

Though each of the above mentioned modeling techniques and methodologies generates artifacts intheir most appropriate level of abstraction, there is no single approach that describes how to generate

all business re-engineering modeling artifacts through all the levels of abstraction. Moreover, models

created by techniques such as BPMN, Petri Nets and UML 2.0 Activity Diagrams may not fully reflectthe reality on the ground due to sometimes a lack of supporting procedures and guidelines on how totransfer the business domain expert knowledge to the business process modeler. In fact, presently there

is a big challenge on how to reduce the mismatch in understanding between these two parties.The UMM on the other hand is a top-down methodology that provides a well-defined set of procedures

for interaction between the business domain expert and the process modeler leading to models closerto reality. With its Business Domain View (BDV), Business Requirements View (BRV), and Business

Transaction View (BTV), UMM leads to the creation of the needed artifact details. Moreover, it


3/20

H. Chourabi et al. / Modeling e-government business processes 93

contributes to the understanding of the whole business collaboration at different levels. However, thismethodology has one shortcoming where it is difficult to properly classify the business processes intheir respective logical grouping of business areas. Moreover, UMM does not provide details of the

collaboration such as the inputs, outputs and inter-relationships between the business processes.To address the UMM shortcomings and provide a complete global picture, it was necessary to use atechnique such as BPMapping. In fact, with BPMapping it is possible to show a lot of details includingthe operational business processes, the business processes for management and support, the interrelationbetween the business processes, the mission, the legal framework and constraints of the organization, aswell as the business partners. Therefore, the use of both modeling techniques leads to the generation of all needed business modeling artifacts at all the levels of abstraction.

Based on a combination of BPMapping and UMM, this paper introduces a new methodology formodeling business processes in government applications. The BPMapping is used at the businesscontext-level to provide a global and a high-level of abstraction model showing the government businessprocesses and their interdependencies, and the environment in which these processes interact. Thismodel helps identify all the inputs, outputs and the stakeholders of the business processes. Moreover, it

depicts the interrelation of the business processes from a necessity logic perspective [20]. The detaileddescription of these processes is achieved through the use of the top-down UMM methodology. UMMhelps view the business collaborations, the business interactions and the flow of information exchangedbetween all business partners. The combination of BPMapping and UMM provides an efficient toolthat is able to model the many complexities of government business processes at different levels of abstraction. To illustrate the effectiveness of the modeling methodology, it is implemented to modelthe Record Integrated Management (RIM) business process used by the government of Quebec. TheRIM is a highly complex process that spans many M-As and which includes many sub-processes thatare interrelated, dependent on each other and which involves many business partners. The proposedmethodology helps in the understanding of this business process by showing its details at various levelsof modeling abstractions.

The rest of the paper is organized as follows. Section 2 gives an overview of the BPMapping modelingtechnique and the UMM methodology. Section 3 presents the details of the combined approach and thesteps of modeling business processes. Section 4 introduces the RIM project at the Quebec governmentused as a motivating example. Finally, Section 5 is the conclusion and a summary of future work.

2. Overview of business process mapping and UMM

There are quite a few modeling techniques and methodologies used to model, describe and documentbusiness processes in organizations. Among these techniques, the Business Process Mapping techniqueor BPMapping and the UMM methodology are two modeling approaches that are increasingly adoptedby modelers to provide all the needed artifact details of any business process at various levels of modelingabstraction.

2.1. The BPMapping modeling technique

BPMapping provides a global overview of the business processes of an organization from a contextualperspective. It leads to simple graphical global models that encompass the functional complexities of anorganization as in the case of governments. In BPMapping, there are three types of business processes:

– the operational processes,


4/20


Fig. 2. The interaction between the different process types [4].

– the support processes, and– the monitoring processes.

The operational processes are the activities that transform inputs into outputs in the form of products

or services. They refer to any routine activities performed by the various business functions in the

organization including sales and marketing, manufacturing and production, and finance and account-

ing [4]. The support processes on the other hand provide the necessary support for the achievement of the

operational processes. They supply the required resources which can be in the form of material, human

resources or financial support. As for the monitoring processes, they provide the rules to which the

operational processes must conform for proper execution. These rules can be in the form of development

of strategies, and planning and/or budgeting specifications. Figure 2 depicts these process types and their

relationships to one another.

In order to build a business process mapping, there are four steps to follow [4,20]. The first stepidentifies the operational processes since they represent the business core of the organization as stated in

its mission. Here, the inputs and the outputs of these processes are determined. The inputs can be either

any physical elements or information provided from within or outside the organization. Inputs from the

environment are provided by suppliers and customers. In addition, the map identifies the business process

partners including customers, suppliers and any stakeholder. The second step involves the identification

of the required resources, and the rules and guidelines to which each operational process must conform

to. The third step identifies the support and the monitoring processes. Finally, the fourth step produces

the map that shows all the interactions that may occur between all the business processes. Figure 3

depicts the results of this business process mapping.

2.2. UN/CEFACT modeling methodology – UMM

UMM is a methodology developed by the United Nations Center for Trade Facilitation and Electronic

Business (UN/CEFACT) to model collaborative business processes performed between different business

partners [28]. It allows modeling inter-organizational business processes [33] by developing their global

choreography [10]. It depicts the collaboration that can take place between different partners involved

in a business process. This methodology provides guidelines to analyze and model business processes

for orchestrating services [22]. It proposes diagrams based on the Unified Modeling Language (UML)


5/20


Fig. 3. The BPMapping formalism.

formalism to describe the business collaboration at different levels of abstraction; from the conceptual

to the physical level [12].

UMM offers three views of a business process:

– the Business Domain View (BDV),

– the Business Requirements View (BRV), and

– the Business Transaction View (BTV).

The BDV is used to gather existing knowledge from stakeholders and business domain experts. It

identifies the business processes, provides a description of theses processes, classifies them, and finally

identifies the business partners and the stakeholders involved in these processes [17]. The identification

of the business processes is achieved through interviews with the domain expert. Once identified, these

processes are described by pre-defined forms that must be fulfilled by the designer. Then, the business

processes are classified into categories of process areas which themselves are classified into categories

of business areas [29].

UMM proposes eight categories of business areas and five categories of process areas [29]. The eight

categories of business areas are: procurement/sales, design, manufacture, logistics, recruitment/training,

financial services, regulation, and health care. The five categories of process areas are: planning,

identification, negotiation, actualization and post-actualization [29]. In the BDV, a business process


6/20


Fig. 4. The BDV conceptual overview [28].

may involve either a business partner or a stakeholder. A partner participates in the achievement of theprocess. A stakeholder does not take part in the process but has an interest or a stake in the achievementof the process. Figure 4 represents the BDV conceptual overview.

The BRV captures the requirements of each business partner or stakeholder involved in a businessprocess. These requirements are gathered within three sub-views of the BRV. Each view representsan artifact that helps to capture the requirements of the business collaboration. The first sub-view isthe business process view that is represented by an activity diagram. This activity diagram shows the

activities of the processes, their states such as when they begin, when they end, their breakpoints, etc.,and the different partners of these processes and the moment at which these partners start to participate.The second sub-view is the business entity view that shows, by using a state diagram, the lifecycleof the entities manipulated when performing the collaborative business process. The third sub-view isthe business partnership view that describes, in the form use cases, the requirements of an identifiedcollaboration between business partners. Figure 5 represents the conceptual view of the BRV.

Finally, the BTV describes the business information exchange protocol expressed as a data model thatformally represents the information exchanged between business partners of the business processes [13].The BTV is made of three sub-views that are used to describe the overall choreography of informationexchanges between processes. The first sub-view is the business choreography view that illustrates thecollaboration protocol by representing the different existing business transactions between partners. Thesecond sub-view is the business interaction view that defines the interactions between business partners

in detail. The third sub-view is the business information view that explains the information exchangedin the business interactions. Figure 6 represents the conceptual view of the BTV.

3. The BPMapping-UMM combined approach

Combining BPMapping modeling technique with UMM methodology leads to the generation of anefficient modeling tool to capture and describe the many complexities of business processes at different


7/20


Fig. 5. The BRV conceptual overview [28].

levels of abstraction. This combination provides a single framework for modeling business processesfrom the business-contextual to the physical level, respectively.

BPMapping provides the global view at the business-contextual level whereas UMM describes and

documents the details of the collaboration and interaction of the business processes at the conceptual,logical, and physical levels, respectively. The combined approach starts by developing the businessprocess map and then continues with the development of the different UMM models. Although in both

of BPMapping and UMM modelers have enough guidance and information on how to create the globalbusinessmodel and the various UMM artifacts, it is not clear how to transit with models from BPMappingto UMM.

In fact, the major challenge in the proposed combined approach resides with the definition of amechanism that allows the transition from the business map to UMM models. The challenge is due

to the fact that both modeling techniques of BPMapping and UMM do not use the same formalismsand concepts. Consequently, this combined approach includes a mapping phase between BPMappingconcepts and formalisms to UMM concepts and formalisms to guarantee an overall coherence between

the different models so that a modeler and therefore a designer can go from one model to another withoutany ambiguity.

3.1. Steps of the combined approach

The combined approach has three main ensembles or grouping of steps. The first ensemble includesthe four steps of the BPMapping approach. It serves as a foundation to develop the UMM artifacts. In

this ensemble, the first step identifies the operational processes and their inputs and outputs, the second


8/20


Fig. 6. The BTV conceptual overview [28].

step involves the identification of the required resources and the rules to which each operational process

must conform to, the third step determines the support and the monitoring processes, and finally the

fourth produces the overall map. In this first group of modeling steps, the modeler focuses only on theconcepts and formalisms of BPMapping.

The second ensemble involves the transition steps from BPMapping to UMM. However, when per-

forming the transition only the concepts and formalisms between those of BPMapping and BDV of

UMM are taken into consideration. In fact, the BDV is the first step in the UMM top-down approach.

Then, other models corresponding to UMM BRV and UMM BTV are generated. Therefore, this second

ensemble includes two steps. The first step is the mapping of the core concepts of BPMapping which

are the operational processes, the monitoring processes, and the support processes into UMM BDV

formalism. The second step is the mapping of the representation of a business process with BPMapping

into its representation with UMM.

The final ensemble of steps relates to the developmentof the different UMM diagrams. These modeling

activities involve the development in three steps of the BDV, the BRV and the BTV.The details of all of these phases of modeling of the combined approach are listed hereafter:

Ensemble 1: BPMapping development

– Step 1 (BPMapping): Identifies the operational processes, their inputs, and their outputs.

– Step 2 (BPMapping): For each operational process, the resources it requires, the guidelines and

rules to which it must conform to are determined.


9/20


Fig. 7. Mapping of the Monitoring process of BPMapping to Planning and Identification.

Fig. 8. Mapping of the Operational process of BPMapping to Actualization and Post-Actualization of UMM.

– Step 3 (BPMapping): From these resources, rules and guidelines, support processes and monitoringprocesses are respectively identified.

– Step 4 (BPMapping): Identifies the interactions that may occur between all the business processes.

Ensemble 2: Mapping BPMapping to UMM

– Step 5: The BPMapping identifies business processes and groups them into either monitoring pro-

cesses, operational processes or support processes. In the BDV, UMM classifies business processesinto categories of process areas. The mapping of the types of processes of BPMapping to UMM

process areas categories is operated as follows. The monitoring processesin BPMapping are mappedto the categories “planning” and “identification”. In fact, the Planning processes identify the future

strategies that monitor and manage the execution of business processes. The Identification processes

identify the ways to implement the planned strategies. Figure 7 shows the mapping of the monitoringprocesses of BPMapping to both Planning and Identification process categories.

The operational processes are mapped to the process categories “Actualization” and “Post-actualization” where the actualization phase performs the agreed upon exchange values, and the post-actualization phase executes the possible complaints. These two categories achieve the global objectivesof the organization. Figure 8 shows the mapping of the operational processes of BPMapping to both

process categories of Actualization and Post-Actualization of UMM.


10/20


Fig. 9. Mapping of the Support process of BPMapping to process areas of Negotiation of UMM.

Fig. 10. Mapping a business process in BPMapping to an UMM use case diagram.

The support processes in BPMapping are mapped to the negotiation process category. In fact, the

negotiation process identifies the human, financial, material and technology support, respectively thatallow business processes to achieve the overall objective of the organization. Figure 9 shows the mappingof the support processes of BPMapping to the negotiation process category of UMM.

– Step 6: Any business process identified in the BPMapping is represented by a use case diagram inthe BDV. Figure 10 shows how a business process in BPMapping is mapped to an UMM use casediagram.

Ensemble 3: UMM diagrams

– Step 7: A business domain view is decomposed into business areas, process areas and businessprocesses. These elements represent the artifacts of the BDV. Each artifact is described by a form.Moreover, the business areas and the process areas are represented by package diagrams, and the

business processes are represented by a use case diagram. At this stage, all the diagrams aregenerated by mapping the BPMapping concepts into UMM artifacts as shown in Ensemble 2.– Step 8: This step identifies and describes the business collaborations where the details of each one

are provided by a form. Each business process that has been identified in the BDV is decomposedinto activities which are represented by an activity diagram. Then, the business collaboration isidentified and described by use case diagrams. Then, the business transactions are identified.

– Step 9: This step identifies the business collaboration protocol that takes place between businessprocesses. It describes the choreography of the business transactions that were identified in the


11/20


business collaboration. The business collaboration is detailed by a specific form and represented byan activity diagram. Then, each business transaction is described by a use case diagram in which abusiness transaction is an exchange of business information. Finally, a class diagram that represents

the final business information model is developed.Based on the UMM diagrams, a BPEL code can be generated in order to deploy processes as web

services [11]. In fact, a business process defines how to coordinate the interactions with a businesspartner. In a Web Service environment, this translates to a BPEL process definition that coordinatesactivities representing the execution of Web Service.

To emphasize the usefulness of combined approach, it has been implemented in the modeling of acomplex government business process at the Quebec government. This business process is called theRecord Integrated Management (RIM). The following section presents the modeling artifacts for theRIM at all levels of abstraction.

4. Case study: The record integrated management project at the quebec government

The Government of Quebec has initiated a new project for the management of documents in theirdifferent formats (paper, digital, CD, etc.). The project is dubbed the CRGGID (in French: Cadre deRéf ́erence Gouvernemental en Gestion Intégrée des Documents) for Government Reference Framework in Integrated Management of Documents. The CRGGID which is developed under the ISO 15489international standard on Records Management provides generic models aimed at the following aspectsof the records’ management:

– the Recording Act,– the Metadata Profiles, and– the Classification Schemes.

The objective of the CRGGID is to fulfill the business requirements of record management including

the legal proof, the tracking records, the personnel protection and confidential information, and theintegration management of both digital and paper documents.

The CRGGID is based on a government business process called the Records Integrated Management(RIM). This process is designed to provide service to all government businesses and programs. RIM is acomplex process which includes many sub-processes that are interrelated and dependent on each other.It involves inter as well as intra M-A business partners where the Archives of Quebec plays a majorrole as an external business partner. In fact, the Archives of Quebec sets the rules and regulations thatgovern the process of recording documents and each M-A is expected to apply these guidelines in itsRIM process.

The RIM process follows a specific execution cycle. It starts with the “Records Retention ScheduleDevelopment” phase within a particular M-A. The records retention schedule includes a recording plan

and a set of rules and regulations of the Archives of Quebec. The records retention schedule is thensubmitted for internal approval by the M-A. This is the “Records Retention Schedule Approval” phase.Once the schedule is approved by an M-A, it is then submitted to the Archives of Quebec for anotherapproval. If a records retention schedule has been approved by the Archives of Quebec, the M-A thenprepares the application of the RIM that consists of functional interfaces for document management. Atthis stage, the process is operational which means that users can perform the actions of “registering”,“updating”, and “consulting” documents. Once a document is registered, it can be updated, consulted,archivedor deleted after a certain number of years have elapsed as stated in the records retention schedule.


12/20


The complexity of the RIM process is due to the fact that it involves a large number of users withinthe government sector including individuals and M-A. Throughout the lifecycle of a document, thereare specific users of the RIM who can be both suppliers and customers. A document can be saved by a

person but it affects everyone including the Archives Quebec, the M-As, citizens (individuals or groupssuch as local firms). The objective of RIM project is to ensure better management of information.The modeling of the RIM process initiated as a pilot project to test and validate the introduction of

UMM at the Quebec government. This project followed the UMM modeling steps as stated in themethodology where the business process modeler and the domain expert meet together for interview inorder to fulfill the UMM stereotypes forms. Despite the fact that UMM proposes these forms to avoidproblems of misunderstanding between the two parties due to communication problems, the challengeresides with the issue related on how to classify processes in their respective process and business areas.The complexity of the RIM process made it difficult for the business process modeler and the domainexpert to classify the business processes in their respective process areas.

There were some major challenges with the RIM project which required more attention from themodeling team. Some of these challenges were related to the methodology itself and some were related

to the software packages that have to support UMM. A lot of efforts have been spent on introducingUMM to novice users in the modeling team and a consensus had to be reached on adopting it as themodeling technique for the project. The Enterprise Architect software package was the only availabletool that supports UMM models and artifacts. Here also a lot of training was required to acquire skills.Along with these challenges, there was the major challenge related to the understanding of the RIM itself and its business requirements. Indeed, the RIM is a complex business process that consists of severalbusiness processes that are related and interdependent.

Due to the complexity of the RIM business process, its modeling can be very challenging. However,by following the guidelines of the proposed BPMapping-UMM modeling approach, the complexitiespresent in the many interrelationships of the business processes can be described and documented. Infact, the model of the RIM can be developed by applying the nine design steps of Section 3.1 as follows:

Ensemble 1:

– RIM Step 1: The operational processes are the processes that add a value to inputs to productoutputs. The operational processes identified in the complex process RIM are: register, update,management of conserved asset and consult.

– RIM Step 2: The rules of the operational processes are the record retention schedule. The resourcesrequired in the RIM are in the form of software packages to support the operational processes.

– RIM Step 3: From the rules and resources identified in step 2, the following monitoring processesand support processes are identified:

∗ The monitoring processes are “records retention schedule development” and “records retentionschedule approval” processes. In fact, their output is the records retention schedule which states

the rules and the guidelines to be followed by the other processes.∗ The support processes are only one processes the “management of rules and application” process.

The output of this process is an application used to achieve the operational processes.

Table 1 shows the results of applying the first three design steps of the combined approach.

– RIM Step 4: This step summarizes, in a graphical map, the modeling results of the previous threedesign steps. Figure 11 depicts all the identified business processes of the RIM and their respectiveinputs and outputs.


13/20


Table 1Modeling results of the first three design steps of the RIM

Type of processes Business processes Inputs Outputs

Monitoring process Records retention schedule

development

Laws, guides, compendium Records retention schedule

Records retention scheduleapproval

Records retention schedule Approved records retentionschedule

Operational process Register − Files/documents− Rules and guidelines of the

records retention schedule

RecordsLegal proof

Update Records RecordsConsult Records Legal proof Management of records Records Ordered records

Statistical and textual analysisSecure and reliable information

Support process Rules and applicationsmanagement

SoftwareGeneric componentsRules and guidelines of therecords retention schedule

IFGD

Fig. 11. Business process map of the RIM.

Ensemble 2:

– RIM Step5: In the case of RIM, the “planning” process area includes the “records retention scheduledevelopment” business process and the “identification” process category includes the “recordsretention schedule approval” business process. In the case of the process area “Negotiation”, the


14/20


Fig. 12. Package diagram of the RIM process areas.

business collaboration partners negotiate all the actions that should be taken to facilitate the businesscollaboration. The output of these processes will support the realization of the business collaborationbetween the business partners. Therefore, the support processes of the BPMapping are mapped intothe process category “negotiation”. In the case of RIM, the “negotiation” process category includesthe “rules and applications management” business process.Finally, in the case of the process areas “actualization” and “post-actualization”, the business col-laboration is performed between the business partners according to rules and guidelines provided bythe monitoring processes of the two process areas “Planning” and “Identification” and based on theoutput of the support processes of the “Negotiation” process area. The operational processes providethe outputs needed by the clients. They are the core of the business collaboration. The “actual-

ization” and “post-actualization” process areas also represent the core of the business collaborationbetween partners. Consequently, the operational processes of the BPMapping are mapped into the“actualization” and “post-actualization” process areas. The “actualization” process area of the RIMincludes the “register”, “update” and “consult” business processes, whereas the “post-actualization”process area includes the “records management” business process.

– RIM Step 6: This step maps the business processes of the RIM identified in the BPMapping to theartifacts of business process of UMM. Each business process is represented by a use case diagram.The use case diagram shows the business partners of the business process and the nature of theirrelations. The business processes are regrouped in the same use case diagram according to theirprocess areas.

Ensemble 3:

– RIM Step 7: Here the BDV work procedure is defined. Figure 12 represents the package diagram of the decomposition of the RIM into the five process categories: planning, identification, negotiation,actualization and post-actualization. Figure 13 shows the use case diagram of the business processesof the actualization process category.

– RIM Step 8: This step defines the BRV work procedure. Each business process identified in theBDV is described in more details through an activity diagram. This diagram helps the identificationof the business collaboration. Each business collaboration is defined by a use case diagram. Figure 14shows the activity diagram of the “register document” business process.


15/20


Fig. 13. Use case diagram of the processes “Register”, “Update” and “Consult” of “actualization”.

– RIM Step 9: This step defines the BTV work procedure. It provides three diagrams: An activitydiagram to describe the business collaboration protocol, a use case diagram to identify each businesstransaction, and a class diagram to describe the information model of the RIM. The Fig. 15 depictsthe business collaboration protocol diagram.

By applying the BPMapping-UMM approach to the modeling of the RIM business process, it ispossible not only to view all the elements that make this complex business process but also to gain ununderstanding of how this process work. Elements such as inputs, outputs, added values of the processes,and the processes interdependencies can be illustrated. The transition from the model’s high level of abstraction to its low level is guaranteed by the combined approach.

5. Conclusions and future work

This paper presented a methodology for modeling complex business processes such as those encoun-tered in government organizations. Two business process modeling techniques, the BPMapping and

UMM, were combined to generate guidelines of how to model complexities in business processes atdifferent levels of details and abstraction. The BPMapping technique was used to create an overallgraphical representation of the business process in its environment, legal framework and constraints.It provided not only details of the business domain, but it also should help business domain expertscapture the justification and environment in which these business processes are used without having touse the technical language of systems analysts and application developers. The details of the processesat lower levels of abstraction were modeled using the UMM methodology which provided an effectivetool to model the business process collaboration between the different partners in an organization. The


16/20


act RegisterDocument

Responsible Document Management (M-O)Authenticate user

«BusinessProcessActi...

Request document metadata

form

InitialState

«SharedBusinessEntit...

:Metadata form

[requested]

«BusinessProcessActivity»

Provide metadata form


:Metadata form

[provided]

«BusinessProcessActivity»

PrepareRegistration

«InternalBus...

:Registration

[prepared]

«BusinessProcessA...SubmitRegitration


:Registration

[submitted]

«BusinessProcessA...CheckRegistration

«InternalBus...

:Registration

[notApproved]

«InternalBus...

:Registration

[approved]

«BusinessProcessActiv...

RefuseRegistration


AcceptRegistration

«SharedBusi...

:Registration

[refused]

«SharedBusi...

:Registration

[confirmed]

«BusinessPro...

ReviseRegistration


Recieve Confirmation

Success

Failure

«InternalBus...

:Registration

[rejected]

«InternalBus...

:Registration

[revised]

«BusinessProcessA...

AbandonRegistration


Register Metadata in

the register


Classify document in

the repository


ConfirmRegistration

Fig. 14. Activity diagram of the business process “register document”.

combination of the two modeling techniques resulted in a methodology that shows how to generatemodeling artifacts at varying levels of details and in different levels of abstraction, and how to move

from one level to the other.To demonstrate the usefulness of the methodology, it was applied to the modeling of the RIM process

at the Quebec Government. The results showed that the RIM business process can be well modeled and

documented by a set of appropriate artifacts showing the overall business view as well as the detailed


17/20


Fig. 15. Business collaboration protocol of the business process “register document”.

operational views of the process. The artifacts for this complex business process can be used to provide

a common communication background between all of the business process’ stakeholders including the

business managers, the information systems analysts as well as the applications’ developers. This should

help reduce any ambiguity in the re-engineering process and will contribute to the enhancement of work

and productivity.

Though this modeling approach focused on the first three levels of modeling abstractions reflectingthe business process re-engineering in its analysis and design, the approach can be extended to include

details of business processes at the implementation level. In this case, a modeling technique such as

BPMN can be used. However, in large-scale organizations the number of business processes that need

to be modeled is extremely large. Before attempting to create a comprehensive model, there is a need to

identify data that interconnect the business processes. Without this identification, the interconnection of

the business processes can be very challenging. The business processes integration approach can follow

the methodology of Information System Urbanization [5,6,19]. Therefore, the proposed methodology

can be further enhanced by putting more focus on the reality on the ground and by therefore preceding it

with a data-driven information architecture [23]. These ideas are presently investigated by the authors.

Acknowledgments

This work has been financially supported by the Government of Quebec, Canada. The authors would

like to thank the Government of Quebec and all the government employees who have been involved in

this project. The authors would also like to thank Prof. Daniel Pascot, Director of the Management

Information Systems Department at Université Laval, for his valuable comments.


18/20


References

[1] AGA, Australian Government Architecture Reference Models, 2008. http://www.finance.gov.au/publications/australian-

government-architecture-reference-models/index.html.[2] B. Bellman and F. Rausch, Enterprise Architecture for e-Government, Lecture Notes in Computer Science 3183 (2004),

48–56.[3] J. Billington, S. Christensen, H. Van Hee, E. Kindler, O. Kummer, L. Petrucci, R. Post, C. Stehno and M. Weber, The Petri

Net Markup Language: Concepts, Technology, and Tools, Lecture Notes in Computer Science 2679 (2004), 483–505.

[4] H. Brandenburg and J.P. Wojtyna, L’approche processus: mode d’emploi, in: Éditions d’Organisation, 2003.

[5] Y. Caseau, Urbanisation et BPM, in: Édition Dunod, 2005.[6] H. Chelli, Urbaniser l’entreprise et son système d’information, in: Guide des entreprises agiles, in: Édition Vuibert,

2003.[7] J. Gotze and P.E. Christiansen, Trends in governmental enterprise architecture: Reviewing national EA programs-Part I,

Journal of Enterprise Architecture 3(1) (February 2007), 8–18.[8] G. Decker and F. Puhlmann, Extending BPMN for Modeling Complex Choreographies, Lecture Notes in Computer

Science 4803 (2004), 24–40.[9] D.A. Dryer, T. Bock, M. Broschi and T.D. Beach, DoDAF limitations and enhancements for the Capability Test

Methodology, Proceeding of Spring Simulation Multi-Conference SpringSim 3 (2007), 170–176.

[10] B. Hofreiter and C. Huemer, From a UMM business process model to a business environment specific ebxml process, Journal of Electronic Commerce Research 7(3) (2006), 138–153.

[11] B. Hofreiter and C. Huemer, Transforming UMM Business Collaboration Models to BPEL, in Workshop on ModelingInter-Organizational Systems (MIOS), Lecture Notes in Computer Science 3292 (2004), 507–519.

[12] B. Hofreiter, C. Huemer, P. Liegl, R. Schuster and M. Zapletal, UMM Add-In: A UML Extension for UN/CEFACT’sModeling Methodology, Lecture Notes in Computer Science 4749 (2008), 618–619.

[13] C. Huemer and M. Zapletal, A State Machine executing UMM Business Transactions, in: Reports of the Insti-tute of Software Technology and Interactive Systems, Wien University of Technologies, 2008. http://www.ec.tuwien.ac.at/˜marco/pub/UMMBusinessTransactionsStateMachines.pdf.

[14] P. Kimberley, E-Governance in tradefacilitation: transparency and ICT as prerequisites for freeand fair trade, proceedingsof the 1st International Conference on Theory and Practice of Electronic Governments, ACM International ConferenceProceeding Series 232 (2007), 283–290.

[15] A. Koumpis, M. Chatzidimitriou, A. Vontas and V. Peristeras, The 100 Euro e-Gov Portal, proceedings of the 1st International Conference on Theory and Practice of Electronic Governments, ACM International Conference ProceedingSeries 232 (2007), 81–84.

[16] J.L. Lemoigne, La modélisation des systèmes complexes, in: Édition Dunod, 1990.[17] P. Liegl, S. Schuster, M. Zapletal, C. Huemer, B. Hofreiter and R. Mosser, Modeling e-Government processes with UMM,

Informatica: an International Journal of Computing and Informatics 31(4) (2007), 407–417.[18] B. List and B. Korherr, An evaluation of conceptual business process modeling languages , Proceedings of the ACM

Symposium on Applied Computing, 2006, pp. 1532–1539.

[19] C. Longépé, Le Projet d’Urbanisation du S.I., 2e Édition, in: Édition Dunod, 2004.

[20] Y. Mougin, La cartographie des processus: Mâıtriser les interfaces, 2e Édition, in: Éditions d’Organisations, 2004.

[21] MSG,Ministère des Services Gouvernementaux, Cadre de réf ́erence, Report, AEG-Étude cadre de réf ́erence v20- versionFinale, 2007.

[22] P. Offermann, C. Schröpfer and M. Ahrens, Extending the UN/CEFACT Modeling Methodology and Core Componentsfor Intra-organizational Service Orchestration, Lecture Notes in Computer Science 4652 (2007), 154–165.

[23] D. Pascot, La méthode Datarun, Management Information Systems Department, Faculty of Business Adminis-tration, Laval University, Quebec, Canada. URL: http://loli.fsa.ulaval.ca/fileadmin/Methodes/Analyse/pdf-datarun/ DATARUN.pdf.

[24] C. Perks and T. Beveridge, TOGAF and the Architectural Development Method , in: Guide to Enterprise IT Architecture,Springer New York, 2004, pp. 76–94.[25] A. Rodŕıguez, E. Fernández-Medina and M. Piattini, Towards a UML 2.0 Extension for the Modeling of Security

Requirements in Business Processes, Lecture Notes in Computer Science 4083 (2006), 51–61.[26] G.A.Sundström, Business process modeling and process management: concepts and examples, International Conference

on Computational Cybernetics and Simulation 1(12–15) (1997), 227–231.[27] H. Tardieu, A. Rochfeld, R. Colletti, G. Panet and G. Vahée, La méthode Merise – Tome 2 Démarches et pratiques, in

Editions d’Organisation, 1985.[28] UN/CEFACT Modeling Methodology (UMM): Meta Model – Foundation Module, Version 1.0 Technical specification,

UN/CEFACT, October 2006, URL: http://unece.org/cefact/umm/UMM Foundation Module.pdf.


19/20


[29] UN/CEFACT Modeling Methodology (UMM) User guide CEFACT/TMG/N093, Version N20030922, UN/CEFACT,September 2003. URL: http://www.unece.org/cefact/umm/UMM userguide 220606.pdf.

[30] W.M.P. Van der Aalst, A.H.M. Ter Hofstede and M. Weske, Business process management: a survey, Lecture Notes inComputer Science 2678 (2003), 1–12.

[31] W. Wang, H. Ding, J. Dong and C. Ren, A Comparison of Business Process Modeling Methods, Proceedings of the IEEEInternational Conference on Service Operations and Logistics, and Informatics, SOLI 2006, pp. 1136–1141.[32] J.A. Zachman, A Framework for Information Systems Architecture, in IBM Publication, System Journal 26(3) (1987),

276–292.[33] M. Zapletal, A holistic Methodology for model-driven B2B Integration: From Business Values over Business Collab-

orations to Deployment Artifacts, in: Reports of the Institute of Software Technology and Interactive Systems, WienUniversity of Technologies. URL: http://publik.tuwien.ac.at/files/PubDat 166304.pdf.


20/20