METHODOLOGY AND RECOMMENDATIONS

FOR CRISIS PROCESSES

An Effective Way How to Manage Business Process Deployment

in the Crisis Management

Tomáš Ludík, Jaroslav Ráček and Lucie Pekárková

Faculty of Informatics, Masaryk University, Botanická 68a, Brno, Czech Republic

Keywords: Process management, Crisis management, Process oriented methodology, Recommendations, Case study,

Business process management suite.

Abstract: The paper focuses on identification and software support processes in the field of crisis management. The

paper aims to describe a process methodology for crisis management. The methodology consists of five

main phases, being Identifying, Modelling, Configuration, Execution/Monitoring and Optimization of

processes. Each phase is described in terms of individual activities, input and output artefacts, and user

roles. The next part of the paper recommends the use of particular technologies, tools and resources that

have been successfully proved in the analysis of crisis situations in the Czech Republic. Established process

methodology and practical recommendations create the foundation for the full methodology deployment in

practice. Throughout this paper the emphasis is on practical demonstration of results on a case study that

applies a process methodology and hereof related recommendations in the crisis situation.

1 INTRODUCTION

The crisis management requires considerable effort.

To manage crisis situations, it is necessary to spend

human resources and technical resources. It is useful

if there are available some best practices in solving

the crisis and also specified responsibilities for

particular activities. To capture such information it

is appropriate to use the process management, which

has been approved in the private and public sector

(Kubíček et al., 2010).

Identification and subsequent automation of the

process is a challenging issue. At present, there are

primarily two different approaches to the business

process deployment. One is based on the business

process life-cycle, the second one on the overall

architecture which supports the business process

deployment. It is convenient to integrate the

mentioned approaches to the process management

for effective process deployment and create an

unified view of the process deployment. Such a view

is defined by Process Framework for Crisis

Management (Ludík and Ráček, 2011).

The Process Framework for Crisis Management

provides a basic view of the process deployment

from the methodology and architecture point of

view. For this reason, this paper aims to describe the

process-oriented methodology, which is an essential

part of the framework. The paper also contains a

case study that illustrates the use of process-oriented

methodology in practise and its adequate support by

Business Process Management Suite.

There are many methodologies that lead the user

through the process deployment, e.g. Object Process

Methodology, Rational Unified Process or Business

Driven Development. The business process analysis

is the principle of these methodologies, but the

process automation does not follow the process

management ideology.

1.1 Object Process Methodology

Object Process Methodology (OPM) (Dori, 2000) is

an approach to design information system by

representing it by object models and process models.

OPM combines a minimal set of building blocks

with a dual graphic-textual representation in a single

diagram type.

The disadvantage is the non-standard diagram

notation, which has similar properties to the Data

333

Ludík T., Rá

cek J. and Pekárková L..

METHODOLOGY AND RECOMMENDATIONS FOR CRISIS PROCESSES - An Effective Way How to Manage Business Process Deployment in the

Crisis Management.

DOI: 10.5220/0003600803330338

In Proceedings of 1st International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2011), pages

333-338

ISBN: 978-989-8425-78-2

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

Flow Diagram. Another disadvantage is a low

correlation between modelled process diagrams and

their subsequent implementation.

1.2 Rational Unified Process

The Rational Unified Process (RUP) (Shuja and

Krebs, 2008) is an iterative software development

process framework created by IBM in 2003. RUP is

not a single concrete prescriptive process, but rather

an adaptable process framework, intended to be

tailored by the development organizations and

software project teams that will select the process

elements that are appropriate for their needs.

The disadvantage of RUP methodology is that

business process analysis is used only at the

beginning in order to create business requirements.

The final application reflects the business processes,

but there is not created a closer bond with them.

Therefore, even a small change of business process

leads to a fundamental change of the created

information system.

1.3 Business Driven Development

Services-Oriented Architecture (SOA) provides an

IT framework along with a set of principles and

guidelines to create IT solutions as a set of reusable,

and configurable services that are independent of

applications and runtime platforms. Transitioning an

enterprise to SOA requires a Business Driven

Development (BDD) approach that uses business

goals and requirements to drive downstream design,

development, and testing (Mitra, 2005).

It is the best of so far described methodologies

from the view of the close interdependence to

business processes. But there is missing the

application of a workflow reference model that

allows to deploy the modelled process instance

directly to the workflow engine.

2 PROCESS ORIENTED

METHODOLOGY

The created process-oriented methodology is based

on the above mentioned methodologies but also

eliminates their disadvantages. This innovative

methodology is described in terms of different

phases, from which it is composed, as well as in

terms of user roles and work products generated by

this methodology.

2.1 Phases

The first phase of the methodology is Identifying

(Figure 1). In this phase the strategic objectives of

the organization are defined. In accordance with

them there are also identified processes that bring

added value to the organization. These processes can

be divided into primary, support and management

processes (Fiala and Ministr, 2007). It is also

appropriate to assign responsibility for individual

processes and particular activities as well. It is

appropriate to use the Use Case Diagram to integrate

processes and user roles. The output of the phase is a

list of business requirements. It is convenient to

define the Glossary to better understand the area of

interest, which facilitates communication between

user roles. The last tasks of the phase are verification

and validation of business requirements.

In the Modelling phase, the business process is

modelled in detail and decomposed into several

levels, depending on its complexity (Weske, 2007).

During this phase the emphasis is on the correct data

flow in processes. Decision-making in processes is

solved by using business rules, which could be

changed during the process runtime. Designed

processes should be simulated in this phase.

Simulation can reveal bottlenecks in the process and

also visualize the process functions. The outcome of

this phase is the system requirements determination.

System requirements should be verified and

approved by the user-validation. Key outcome is the

appropriate automation level determination.

Figure 1: Identifying phase of Process Oriented Methodology.

SIMULTECH 2011 - 1st International Conference on Simulation and Modeling Methodologies, Technologies and

Applications

334

The Configuration phase deals with detailed set

up of business processes. Processes are transformed

into the configuration phase mostly in Business

Process Execution Language (BPEL). In this form

they are accompanied by the necessary functionality

build on service-oriented architecture. Processes

consist of already existing services or of the brand

new ones that need to be programmed. In this phase

are created the key performance indicators (KPI)

that are intended for the process performance control

during the runtime. In such way the comprehensive

application is built on business process. Its instances

can be deployed on the workflow engine. The

created system is set to the end customer. The

service and process testing, as well as system

validation, belong to the control mechanisms.

The Execution/Monitoring phase provides

primarily two activities. First it is an administration

of running process instances in the workflow engine,

which allows the end users to work with the

processes. Created applications can be set up and

configured during the runtime. Business rules enable

the configuration of the branching in processes,

which enables better response to possible changes in

a company. Setting of the user rights and roles is

another option. Roles and rights can be assigned or

removed for the current or new users, according to

their current responsibilities. This phase is also

responsible for process monitoring and for gathering

data about the process run. Based on this

information, it is possible to evaluate the process

progress and partly adapt the process on the flow.

Defined KPIs have a great impact. They enable

overall control of the process and therefore also a

rapid response to sudden changes.

The last phase is Optimization. This phase is

crucial for continuous process improvement. During

the monitoring phase the data about process

instances are collected, which may result in some

gaps in the modelled process. There are some

advanced techniques of mathematical statistics or

process mining available for the process instances

analysis. Based on the results it is possible to choose

two different approaches to process improvement. It

is a Business Process Reengineering (BPR) or a

Total Quality Management (TQM) (Řepa, 2007).

TQM is focused on the consequent improvement of

processes, BPR focuses on radical changes.

2.2 Roles

Stakeholder represents interest groups whose needs

must be satisfied by the project. It is a role that may

be played by anyone who is (or potentially will be)

materially affected by the project outcome.

Business analyst is a high-level role responsible

for the business analysis and BPM work activities.

The business analyst performs process modelling

and creates functional specifications for process.

Architect is a high-level role responsible for the

overall work effort of creating the architecture and

system design. More specialized roles, such as

enterprise architect, application architect, SOA

architect, and infrastructure architect, are actually

responsible for various architectural work efforts

that constitute the design phase of the project.

Developer is a high-level role responsible for the

implementation of the result (services).

Tester is a role responsible for performing

activities required to test the application before it is

deployed into a production environment.

Line Manager is a person who heads revenue

generating departments (manufacturing and selling)

and is responsible for achieving the organization's

main objectives by executing functions such as

policy making, target setting or decision making.

2.3 Work Products

This section describes the outputs generated by the

methodology. Thus outputs are quite a bit through

the methodology phases and therefore only main

outcomes of the various phases are described.

Business Requirements are based on customer's

wishes and their needs. They describe the principles

and functioning of a company as a whole, defining

its objectives (Shuja and Krebs, 2008). Identified

processes are part of these requirements.

System Requirements are the modelling phase

results. These are the requirements for creating an

information system built on business processes.

Detailed and hierarchically organized process

diagrams are part of this output. These requirements

also describe the level of process automation.

Information System is a result of the

configuration phase. Modelled processes are

configured and composed of individual services.

Thus created processes are deployed on a process

engine, which interprets them. The workflow engine

also allows interaction with users and external tools.

Monitoring data is an output of the monitoring

phase. It contains information about process

instances run, such as duration or cost of individual

processes. It also records the passing through the

business process, which can be useful in further

analysis.

Strategic plans are the optimization phase

outputs. The overall technology improvement

(TQM, BPR) and strategic plans for further business

process improvement are chosen in strategic plans.

METHODOLOGY AND RECOMMENDATIONS FOR CRISIS PROCESSES - An Effective Way How to Manage

Business Process Deployment in the Crisis Management

335

3 RECOMMENDATIONS FOR

CRISIS MANAGEMENT

In case the methodology is used in the field of crisis

management it is appropriate to consider certain

features that arise from this specific area. This

features are illustrated on crisis management in the

Czech Republic.

3.1 Organizational Structure

The Integrated Rescue System (IRS) is determined

for co-ordination of rescue and clean-up operations

in case, where a situation requires operation of

forces and means of several bodies, e.g. fire fighters,

police, medical rescue service and other bodies, or in

case, where the rescue and clean-up operation is

necessary to be co-ordinated from the Ministry of

Interior or by a leader of region’s level, or by

mayors of municipalities with extended

responsibilities (Rektořík, 2004). As the Integrated

Rescue System are therefore considered the co-

ordinated proceedings of its bodies during

preparations for crisis situations, and during rescue

and clean-up operations.

3.2 Legislation and Documentation

There are many laws dealing with crisis

management in the Czech Republic. Crisis

management elements are codified in the Law No.

240/2000 on crisis management and on modification

of certain codes (Crisis Code), in latter wording. The

other important Law is the Law No. 239/2000 on the

Integrated Rescue System and on amendment of

certain codes, in latter wording. It is the basic legal

frame describing situation around IRS.

Another feature of the crisis management is the

detailed documentation that defines how to proceed

in particular situations. The Contingency Plans

belong to the basic documents. They contain a set of

measures and procedures addressed to crisis

situations.

3.3 Different Types of Information

To successfully deal with critical situations, it is

inevitable to have all the necessary information at

disposal. It is often not trivial because the

information used in crisis management can have

three basic characteristics or dimensions: time, space

and aggregation. The time dimension of the data is

important in the crisis situation with dynamic

character. This information varies with time so it is a

relevant factor in dealing with the crisis situation.

Another important aspect of the information is that it

is bound to the intervention place. It is only the

limited area around the intervention place that is

important and it can be defined according to the

character of the crisis. The last dimension of the

information relevant to dealing with a crisis situation

is aggregation. The data is provided in aggregated

form, for example as specific maps or map layers.

However, they contain also specific data sets that

could be irrelevant to the character of a particular

intervention location or to the crisis itself. The way

to avoid unnecessary information is to use adaptive

mapping (Kubíček et al., 2010).

3.4 Psychological Aspects

There is a new belief that even despite the

devastating impact of disasters, substantial lack of

resources, and general chaos, there is still a

possibility of carrying out some actions that will

serve in maintaining at least the basic integrity of the

human society and its dignity. Psychological aspects

are usually very important for dealing with crises.

All activities of crisis management are performed

under substantial time and psychological pressure.

Intervention commanders work and make decisions

in fear of their possible failure. They often have

insufficient and inaccurate information. Other

problems arise from lack of necessary resources.

The basic requirements of life may sometimes be

restricted under the influence of all these factors.

3.5 Using of Standards

Unified Modelling Language (UML) is a

standardized modelling language used in the field of

software engineering. Two diagrams are especially

suitable for process modelling: Use Case Diagram

and Activity Diagram.

Business Process Modelling Notation (BPMN)

(Silver, 2009) provides a notation that is readily

understandable by all business users. This way,

BPMN creates a standardized bridge over the gap

between the business process design and process

implementation.

Web Services Business Process Execution

Language (WS-BPEL) defines a model and a

grammar for describing the behaviour of a business

process based on interactions between the process

and its partners (Jordan and Evdemon, 2007). WS-

BPEL introduces a mechanism to define how

individual or composite activities within a unit of

work are to be compensated in cases where

exceptions occur or a partner requests reversal.

SIMULTECH 2011 - 1st International Conference on Simulation and Modeling Methodologies, Technologies and

Applications

336

4 CASE STUDY

To demonstrate the practical use of the process-

oriented methodology in crisis management a typical

activity STC - 05/IZS called “Finding an object that

is suspicious to contain B-agents and toxins” is

chosen. Typical activities describe cooperation of

the Integrated Rescue System (IRS) components for

joint intervention (Kubíček et al., 2010). This group

of documents is released by the Directorate of Fire

Brigade of the Czech Republic.

4.1 Application of Methodology

At Identifying phase it is important to understand the

research problems and identify the individual

processes. The main output is a good theoretical

preparation for the next phase of the methodology.

Intervention from the perspective of the Intervention

commander begins when the commander arrives into

the site of finding a subject that is suspicious of the

presence of B-agents or toxins. The Intervention

commander immediately conducts an evaluation of

the situation. In case of a threat the intervention

commander decides about organization of the

intervention and future joint actions. Coordination

with emergency medical service (EMS) provides

medical assistance to affected civilians and rescue

teams. In parallel with this activity intervention units

carry out in the affected area disinfection and

medical examination of people and decontamination

of the area, especially suspicious object and location

findings. When all of these activities are finished,

the intervention commander ends the intervention.

At the moment ends a common intervention of IRS

components.

Consecutively, there is the Modelling phase.

Based on the previous proposal the process model is

created (Figure 2). The diagram shows the order in

which activities are behind, what data streams flow

between them and what the outcomes of the process

are. The process is modelled in BPMN notation.

This phase also includes a simulation and process

optimization possibility. Simulation can show the

bottlenecks as well as lead the user through the

individual process steps to check whether the

process is modelled in accordance with the user’s

wishes. This phase results in verified, validated and

simulated processes (Mak et al., 1999).

To Configuration the process model means that

processes first need to be supplemented by specific

data types, especially in the simplified form. These

forms wander through processes and every activity

adds new information to them. This phase of the

process-oriented methodology also involves making

key performance indicators and the monitoring

model, which will monitor and evaluate the

deployed process. In order to implement instances of

automated processes, it is necessary to convert the

processes into a format that is computing

processable. For this purpose Business Process

Executive Language (BPEL) is used. The created

process is then deployed into a process server.

The Execution/Monitoring phase is essential to

execute and monitor processes and to visualize

conditions of the process instances. The monitoring

process is an important mechanism to provide

accurate and timely information on conditions of

process instances. Important modules are primarily

Sequence diagram of human work, Detailed activity

description and Key performance indicators.

The last phase is the Optimization. The basics for

this phase are data from processes monitoring that

are used to evaluate and optimize business process

models and their implementations. Execution logs

are evaluated by using business activity monitoring

and process mining techniques. These techniques

aim to identify the quality of business process

models and adequacy of the execution environment.

For instance, business activity monitoring might

reveal that a certain activity takes too long due to

shortage of resources required to conduct it.

Figure 2: Process model of typical activity STČ – 05/IZS.

METHODOLOGY AND RECOMMENDATIONS FOR CRISIS PROCESSES - An Effective Way How to Manage

Business Process Deployment in the Crisis Management

337

4.2 Business Process Management Suite

The overall architecture is often composed of a set

of tools covering everything necessary to deploy

complex processes in the organization. Such a

software package is called Business Process

Management Suite (BPMS). Unlike the first

generation instrument, which was conceived as a

compilation of several separate programs, by far did

not cover the requirements of the complex

architecture necessary for the deployment of

processes. Current systems already offer

comprehensive and holistic options tools with an

intuitive user interface, which covers complex

architecture requirements.

For this case study IBM WebSphere software

was used. The software includes programs that cover

the elements of architecture describing the process

framework for crisis management (Ludík and Ráček,

2011). There are many other solutions, of course.

5 CONCLUSIONS

The primary contribution of this paper is the

innovative, process-oriented methodology. The

methodology is described in terms of phases, user

roles and work products. The paper also describes

set of recommendations, which should be applied

when methodology is used on crisis management

processes. These are based on practical experiences

when solving the research plan called Dynamic

Geovisualisation in Crises Management (Kubíček et

al., 2010; Ludík and Ráček, 2011). The paper also

illustrates the practical use of the methodology in

real situation called “Finding an object that is

suspicious to contain B-agents and toxins”.

It is appropriate to emphasis on adequate

software support during the use of methodology.

This support is provided by Business Process

Management Suite (BPMS), where different tools

support different methodology phases. In case of a

comprehensive crisis management system it is

necessary to take the close interoperability to GIS or

other systems used by the IRS into account.

Therefore it is recommended to add the global

architecture which will illustrate the overall

deployment of the system based on processes.

The subsequent objective of this research is to

define in detail the methodology phases in terms of

individual tasks and their links to each other. This is

related to the assignment of responsibilities for these

tasks. Similarly, detailed description of the role

associated with implementing the methodology in

terms of ICT and crisis management is needed. The

final aim is to describe the task inputs and outputs in

detail in terms of work products and determine

whether all information is available at the right time.

ACKNOWLEDGEMENTS

The contribution is a part of the research plan no.

MSM0021622418 and the research project no.

FRVS/1035/2011, both supported by the Czech

Ministry of Education, Youth and Sports.

REFERENCES

Dori, D., 2000. Object-Process Methodology - A Holistic

Systems Paradigm. Springer-Verlag. Heidelberg, New

York.

Fiala, J., Ministr, J., 2007. The Model of Process

Framework in Czech Public Government. In

Proceedings of the 26th International Conference on

Organizational Science Development – Creative

Organization. University of Maribor. Portorož.

Jordan, D., Evdemon, J., 2007. Web Services Business

Process Execution Language Version 2.0. OASIS

Standard. 2007. Available at http://docs.oasis-

open.org/ wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf, 20.3.2011

Kubíček, P., Ludík, T., Muličková, E., et al., 2010.

Process Support and Adaptive Geovisualisation in

Emergency Management. In Geographic Information

and Cartography for Risk and Crisis Management -

Towards Better Solutions. Springer-Verlag. Berlin

Heidelberg. ISBN 9783642034411.

Ludík, T., Ráček, J., 2011. Process Support for

Emergency Management. ECON - Journal of

Economics, Management and Business, VŠB-TU

Ostrava, 19/2011, 1, Ostrava.

Mak, H., Mallard, A., Bui, T., et al., 1999. Building online

crisis management support using workflow systems. In

Decision Support Systems 25. Elsevier.

Mitra, T., 2005. Business-driven development. IBM.

Available at URL: http://www.ibm.com/developer

works/webservices/library/ws-bdd/, 20.3.2011.

Rektořík, J., 2004. Crisis management in public sectors.

Ekopress. Praha. ISBN 8086119831. (in Czech)

Řepa, V., 2007. Business Processes, Process Management

and Modelling. Grada. Praha. ISBN 9788024722528.

(in Czech)

Shuja, A., Krebs, J., 2008. IBM Rational Unified Process

Reference and Certification Guide: Solution Designer.

IBM Press. ISBN 9780131562929.

Silver, B., 2009. BPMN method and style. Cody-Cassidy

Press. Aptos. ISBN 9780982368107.

Weske, M., 2007. Business Process Management,

Concepts, Languages, Architectures. Springer-Verlag.

Berlin Heidelberg. ISBN 9783540735212.

SIMULTECH 2011 - 1st International Conference on Simulation and Modeling Methodologies, Technologies and

Applications

338