Page 25 -

1.3 Process Mining 7

The value of models is limited if too little attention is paid to the alignment of
model and reality. Process models become “paper tigers” when the people involved
cannot trust them. For example, it makes no sense to conduct simulation experi-
ments while using a model that assumes an idealized version of the real process.
It is likely that—based on such an idealized model—incorrect redesign decisions
are made. It is also precarious to start a new implementation project guided by
process models that hide reality. A system implemented on the basis of idealized
models is likely to be disruptive and unacceptable for end users. A nice illustra-
tion is the limited quality of most reference models. Reference models are used in
the context of large enterprise systems such as SAP [25] but also to document pro-
cesses for particular branches, cf. the NVVB (Nederlandse Vereniging Voor Burg-
erzaken) models describing the core processes in Dutch municipalities. The idea is
that “best practices” are shared among different organizations. Unfortunately, the
quality of such models leaves much to be desired. For example, the SAP reference
model has very little to do with the processes actually supported by SAP. In fact,
more than 20 percent of the SAP models contain serious flaws (deadlocks, live-
locks, etc.) [66]. Such models are not aligned with reality and, thus, have little value
for end users.
Given (a) the interest in process models, (b) the abundance of event data, and
(c) the limited quality of hand-made models, it seems worthwhile to relate event
data to process models. This way the actual processes can be discovered and exist-
ing process models can be evaluated and enhanced. This is precisely what process
mining aims to achieve.

1.3 Process Mining

To position process mining, we first describe the so-called BPM life-cycle using
Fig. 1.3. The life-cycle describes the different phases of managing a particular busi-
ness process. In the design phase, a process is designed. This model is transformed
into a running system in the configuration/implementation phase. If the model is
already in executable form and a WFM or BPM system is already running, this
phase may be very short. However, if the model is informal and needs to be hard-
coded in conventional software, this phase may take substantial time. After the sys-
tem supports the designed processes, the enactment/monitoring phase starts. In this
phase, the processes are running while being monitored by management to see if
any changes are needed. Some of these changes are handled in the adjustment phase
shown in Fig. 1.3. In this phase, the process is not redesigned and no new software
is created; only predefined controls are used to adapt or reconfigure the process. The
diagnosis/requirements phase evaluates the process and monitors emerging require-
ments due to changes in the environment of the process (e.g., changing policies,
laws, competition). Poor performance (e.g., inability to meet service levels) or new
demands imposed by the environment may trigger a new iteration of the BPM life-
cycle starting with the redesign phase.