Nowadays business process modeling is an integral part of many organizations to document and redesign complex organizational processes. One of the most promising tendency in application development today is business process design based software development. Software development methodologies have traditionally been driven by programming and not organizational concepts, leading to a semantic gap between the software system and its operational environment. Business process modeling aligns the business goals and incentives with the IT software design process.
As a forerunner of BPM, in the early 1990s, the idea of Business Process Reengineering (BPR) brought business processes to the center of interest and lifted the subject of design from the supporting IT systems to business processes, to the perspective of business experts. The term is originated from Hammer&Champy’s BPR paradigm (Hammer & Champy, What is reengineering?, 1992), (Hammer &
Champy, Reengineering the Corporation: A Manifesto fo Business Revolution, 1993).
It has been common sense to first determine business requirements and then to derive IT implementations, to develop software according to ideal processes as determined by business logic. Business processes have to perform well within ever-changing organizational environments. It can be expected that Business Process Management will only come closer to its promises if it allows for a better automation of the two-way translation between the business level and the software systems.
19
2.1.1 Process lifecycle
In order to obtain a full view of the capabilities of BPM, we have to start out from the overview of the BPM lifecycle. Among the vast number of BPM lifecycle models available (Jeston & Nelis, 2008), we chose to build upon the most concise and probably one of the most popular model of van der Aalst.
According to the proposed basic model, the four elements of the BPM Lifecycle are the following:
Process Design: The organizational processes concerning the subject are identified, top level visualization of the processes are laid down. Several modeling standards and tools are aiding this phase, as we will have a deeper look among them in the following sections.
System Configuration: This phase provides a more thorough overview of the processes, ideally taking into consideration all possible aspects required for the implementation of the underlying IT infrastructure. One very important dimension of the configuration is business-IT alignment, and also the synchronization of roles and responsibilities of the organizational structure concerning the processes. This stage has many obstacles in real-life implementations due to the inhomogeneous nature of the IT and organizational architectures of different enterprises.
Process Enactment: Processes are inaugurated in real life circumstances, and form the IT point of view being deployed into Business Process Management Systems/Suites (BPMS), workflow engines or other software instances. Recently, in a state-of-the-art organization, this deployment holds some extent of automation. The current focus of BPM theory is concerned with raising this level of automation in turning electronically modeled processes into effective IT supporting infrastructure.
Diagnosis: In an ever-changing business environment it is inevitable to have appropriate feedback on the operational environment of the processes. Diagnosis activities range from monitoring, analysis of the effectiveness – or other KPIs – of enacted processes, and also after identifying and analyzing possible failures and bottlenecks, the revision of the process design, making BPM a continuous, cyclic function of the organization. This phase has a wide body of literature within the BPM
20 community, it is supported by many diagnostic standards, but it falls out of the scope of our interest.
2.1.2 Granularity of process models
The term granularity originates from the Latin word granus and refers to the property of being granular and consisting of smaller grains or particles. Zadeh defines this concept as construction, interpretation, and representation of granules, i.e., a clump of objects drawn together by indistinguishably, similarity, proximity, or functionality (Zadeh, 1997). Granularity in process modeling is used to characterize the scale or level of detail in a modeling process. The greater the granularity, the deeper the level of detail. The provided recommendations on process model granularity are not very specific and do not support process modelers in deciding on the appropriate level of detail. As there is currently no sufficiently effective possibility of measuring the granularity of a process model, the decision about the appropriate level of detail is purely based on the subjective assessment of the modelers.(Leopold, Pittke, &
Mendling, 2013)
Setting this appropriate level can be thought of as an optimization problem in itself. If a process model is too superficial, it will not contain enough information to draw conclusions, conduct redesign or utilize it in any other ways. A modeling architecture with unnecessarily frittered details or a model with inhomogeneous granularity results confusing process architecture, and consumes unnecessary resources to create, maintain and manage. Throughout my work, the level of granularity in modeling a process is set to grant the ability to attach corresponding concepts like roles or information objects to the model.
2.1.3 Static-dynamic process representation
In the modeling practiced we often refer to these models as “static” models. The term suggests that these submodels remain unchanged during the modeling period, which is far from being realistic, especially since the BPR approach aims to redesign change the internal environment of the organizations, but since every modeling concept
21 captures only a reduced set of the reality, this is something I have to accept as a compromise and also as a limitation for the applicability of my work..