Soutenance mémoire
BPM at multiple levels of abstraction (MLA)
BUILDING THE BPM+ APPROACH
The BPM+ a priori version
As described in the Introduction chapter of this thesis, one key factor for a successful BPM project is the active participation of all the stakeholders and sharing a common vision of business processes. This translates into modeling business processes that can be successfully shared among all the involved stakeholders. To achieve this, a typical BPM project will have to deal with different perspectives of the same business process (refer to section 1.4). These perspectives cannot be exclusive: they must complement each other, and all of them together should contain most of the valuable elements and information from the business process. If only a technical point of view is considered when modeling the business processes then it is likely that not all the stakeholders will find valuable the resulting business process models (Smith and Fingar, 2007; Van Nuffel and De Backer, 2012). Each of the perspectives should be seen as a layer of the same business process. In this way, each stakeholder can find helpful to use one or more of these perspectives at a given moment in time (refer to Figure 1.6).
From the literature we learned that the various groups of stakeholders might have conflicting requirements from a business process model, and that it is not possible to represent all the BPM perspectives into one single model (refer to section 1.4). For instance, if a business process model is going to be used as a source of information for developing software then it needs formality (Becker, Rosemann and von Uthmann, 2000). The SWEBOK (Abran et al., 2004, p. 2.3) mentions that “software requirements should be stated as clearly and as unambiguously as possible”. However, there might be an evident conflict here, because the more formal the BPM notation is, the more difficult to understand it likely is, especially by non-IT stakeholders. To address these problems, many authors have argued that BPM at multiple levels of abstraction (MLA) helps to represent the appropriate information to be provided to various types of stakeholders (refer to section 1.5).
aims at providing the means for a consistent and structured way of modeling various business process perspectives. There are many modeling notations that have been proposed and used for modeling business processes (refer to subsection 1.3.2); therefore, the rationale behind the design of BPM+ is not to design yet another BPM notation, but to develop a BPM approach that incorporates MLA, and that selects an appropriate set of BPM constructs for each of its levels of abstraction. The solution proposed by BPM+ needs to be simple and should not significantly increase the complexity of the BPM notations selected, thereby allowing business process models to be easily understood by different stakeholders. BPM+ levels of abstraction cannot be designed and studied separately: they must be designed and studied concurrently, considering the needs and constraints of: each actor (i.e. individual), each unit or department (i.e. team or group), and the organization. The result of using BPM+
within an organization should be a set of models that allows the understanding and the coordination of the activities performed by the various stakeholders of the organization (refer to subsection 1.5.1). Traditionally BPM has been mainly focused around the behavioral aspects of a business process (refer to Table 1.3). By designing the MLA structure concurrently, BPM+ adds other complementary aspects to the traditional BPM. For instance, a business process element represented at a high-level model should be able to be traced to an element represented at a lower-level model; and a low-level representation should be able to be traced back to a highlevel representation. This traceability capability of BPM+ helps to improve the “scope management” and the “change impact analysis” of its MLA approach (IIBA, 2009, p. 130). That is, it should be possible in BPM+ to trace to a lower-level activity or dependency the impact caused by a change in a high-level business process representation. As a consequence of the afore-discussed considerations, the design of BPM+ is based on a focused ontological analysis (refer to section 2.3) complemented by the use of MLA in BPM (refer to section 1.5). It is argued here that following this design approach: 101
BPM+
is not a solution that is only based on the “practical wisdom” of the authors “rather than on a scientific theory” (Recker et al., 2007). 2. The BPM constructs proposed by BPM+ : a) are systematically identified based on an ontological analysis; and b) are necessary to represent the concepts from the real world that have been found to be relevant to be modeled (refer to section 2.3).
BPM+
provides information and formality at the appropriate level of abstraction according to what is required by the different types of stakeholders. We have already reviewed (refer to subsection 1.5.2) several approaches to incorporate a MLA structure in BPM. Anthony’s model (refer to subsection 1.5.1) has been chosen as the basis of BPM+ MLA structure because: 1. Anthony’s model has influenced: the design of commercial BPM notations such as Qualigram (Berger and Guillard, 2000), and recent BPM research (Bhat and Deshmukh, 2005; Haque, Pawar and Barson, 2003). 2. The recommendations of the ISO for documenting business processes (ISO, 2010) reflect
the three levels of activities found in organizations as described by Anthony’s model. 3. Anthony’s model has been used in the literature as a basis for the classification of the added value of IT investment in the organization (Shang and Seddon, 2002).
In addition, we observe that all BPM research proposals reviewed in subsection 1.5.2.3 recommend the use of three levels of abstraction, even though, depending on the author, the content of each level of abstraction varies from one proposal to another. Therefore, BPM+ is developed based on an abstraction hierarchy (see Figure 3.1) that includes three levels of abstraction: strategic, tactical, and operational. The design of each of these three levels of abstraction is inspired from Anthony’s model (Anthony, 1965; Gorry and Morton, 1989), the ISO recommendations for documenting business processes (ISO, 2010), and Qualigram’s pyramid (refer to Figure 1.3). Each abstraction level represents a particular detail of information such as: 102 • The strategic level describes the core processes, goals and policies of the organization, aiming at representing “why” the organization needs to perform the business process modeled. • The tactical level deals with the attainment and efficient use of the resources of the organization: it describes the procedures, aiming at representing “what” activities are done in the organization as part of a business process and “who” in the organization is responsible for each of the activities. • The operational level procures the efficient and effective execution of atomic tasks: it describes specific activities of the organization, aiming at representing “how” to perform each activity.
|
Table des matières
INTRODUCTION
CHAPTER 1 LITERATURE REVIEW
1.1 What is a business process?
1.2.1 What is business process management?
1.2.2 Business process management support systems
1.3 Business process model and modeling
1.3.1 What is a business process model?
1.3.2 Popular BPM notations
1.3.2.1 Business Process Model and Notation (BPMN)
1.3.2.2 Event-driven process chains (EPC)
1.3.2.3 Petri Nets
1.3.2.4 Unified Modeling Language (UML)
1.3.3 Qualigram notation
1.4 What elements of a business process to represent?
1.4.1 The need of BPM perspectives in a BPM project
1.4.2 Business process perspectives presented in the literature
1.5 BPM at multiple levels of abstraction (MLA)
1.5.1 Theoretical foundations
1.5.2 MLA and its use in business process-oriented approaches
1.5.2.1 MLA in management-oriented approaches
1.5.2.2 MLA in BPM notations and methods
1.5.2.3 MLA in BPM research proposals
1.6 BPM and software requirements elicitation
1.6.1 The references for requirements elicitation
1.6.2 Proposed approaches to BPM for software requirements elicitation
1.6.2.1 i* based approaches
1.6.2.2 UML based approaches
1.6.2.3 BPMN based approaches
1.6.2.4 Approaches based on other BPM notations
1.6.2.5 Methodological approaches
1.7 An ontology based theory of representation
1.8 BPM and functional size measurement
1.8.1 The COSMIC FSM method
1.8.2 Functional size measurement from business process models using COSMIC
1.9 Summary
CHAPTER 2 RESEARCH METHODOLOGY, ACTIVITIES AND EXPECTED
RESULTS
2.1 Research methodology and expected results
2.1.1 Definition phase
2.1.2 Planning phase
2.1.3 Operation phase
2.1.4 Interpretation phase
2.2 Design of the case studies
2.3 Research methodology for the representational analyses
2.4 Research design of the survey
2.5 Methodology for developing the FSM from BPM procedure
2.5.1 Business application software domain
2.5.2 Real-time software domain
2.6 Summary of the research methodology
CHAPTER 3 BUILDING THE BPM+
APPROACH
3.1 The BPM+ a priori version
strategic level of abstraction
3.1.2 The BPM+
tactical level of abstraction
3.1.3 The BPM+
operational level of abstraction
3.2 The pilot case study
3.2.1 Details of the research design
3.2.2 Results
3.2.2.1 Results related to Qualigram notation
3.2.2.2 Results related to BPMN
3.2.3 Comparison of the BPM notations
3.2.4 Interpretation and summary of the results
3.3 Refining the set of BPM+
modeling concepts
3.3.1 Mapping results and analysis
3.3.1.1 A SWEBOK insight into the BWW representation model
3.3.1.2 A BABOK insight into the BWW representation model
3.3.1.3 A BWW representation model subset for SRE
3.3.1.4 Qualigram and BPMN mappings
3.3.2 Discussion of the results
3.4 A survey of practitioners with experience
3.4.1 The research propositions
3.4.2 Data analysis
3.4.3 Conclusion
3.5 The BPM+
reviewed version
3.5.1 The BPM+
strategic level of abstraction
3.5.2 The BPM+
tactical level of abstraction
3.5.3 The BPM+
operational level of abstraction
3.6 Case study with a Canadian forensic engineering company
3.6.1 Details of the research design
3.6.2 Results
3.6.2.1 Results related to the number and scope of the levels of abstraction
3.6.2.2 Results related to the modeling requirements for each level of abstraction
3.6.2.3 Results related to the BPM notations
3.6.3 Interpretation and summary of the results
CHAPTER 4 MEASURING FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS WITH COSMIC FSM METHOD
4.1 Introduction
4.2 The business application software domain
4.2.1 Results obtained with Qualigram notation
4.2.1.1 Modeling guidelines for Qualigram
4.2.1.2 Mapping and measuring based on Qualigram
4.2.2 Results obtained with BPMN notation
4.2.2.1 Modeling guidelines for BPMN
4.2.2.2 Mapping and measuring based on BPMN
4.2.3 Deriving notation-independent BPM guidelines and mapping rules
4.3 The real-time software domain
4.3.1 Modeling guidelines for the real-time software domain
4.3.2 Mapping and measuring
4.4 Discussion of results
4.4.1 Business application software domain
4.4.2 Real-time software domain
4.5 Summary
ANNEX I LIST OF APPENDICES ON CD-ROM
LIST OF BIBLIOGRAPHICAL REFERENCES
Télécharger le rapport complet
