Managing the Risks of Risk Management

Abstract

Enterprise Risk Management (ERM) is a field of enormous importance due to its economic repercussion. More and more companies are paying attention to it, given there is significant economic savings for attending to the various aspects of risk. At the same time, ERM has witnessed a shift in the way firms manage the many uncertainties that stand in the way of achieving their strategic, operational and financial objectives. Nevertheless, existing Risk Management Systems (RMIS) are neither powerful, nor flexible enough to model the complexity of the risk management process. In this paper we will examine these issues in greater detail, explaining the existing problem and proposing a software system that addresses them. We will also show the actual design and operation of ARMISTICE (Advanced Risk Management Information System: Tracking Insurances, Claims and Exposures), a successful RMIS case study.

Full text

This article was downloaded by: [University of Coruna], [Laura M. Castro]
On: 18 April 2012, At: 01:36
Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer
House, 37-41 Mortimer Street, London W1T 3JH, UK
Journal of Decision Systems
Publication details, including instructions for authors and subscription information:
http://www.tandfonline.com/loi/tjds20
Managing the Risks of Risk Management
Laura M. Castro a , Víctor M. Gulías a , Carlos Abalde a & J. Santiago Jorge a
a MADS Group – Department of Computer Science, University of A Coruña, Spain
Available online: 18 Apr 2012
To cite this article: Laura M. Castro, Víctor M. Gulías, Carlos Abalde & J. Santiago Jorge (2008): Managing the Risks of
Risk Management, Journal of Decision Systems, 17:4, 501-521
To link to this article: http://dx.doi.org/10.3166/jds.17.501-521
PLEASE SCROLL DOWN FOR ARTICLE
Full terms and conditions of use: http://www.tandfonline.com/page/terms-and-conditions
This article may be used for research, teaching, and private study purposes. Any substantial or systematic
reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any form to
anyone is expressly forbidden.
The publisher does not give any warranty express or implied or make any representation that the contents
will be complete or accurate or up to date. The accuracy of any instructions, formulae, and drug doses
should be independently verified with primary sources. The publisher shall not be liable for any loss, actions,
claims, proceedings, demand, or costs or damages whatsoever or howsoever caused arising directly or
indirectly in connection with or arising out of the use of this material.

Journal of Decision Systems. Volume 17 – No. 4/2008, pages 501 to 521
Managing the Risks of Risk Management
Laura M. Castro — Víctor M. Gulías — Carlos Abalde
J. Santiago Jorge
MADS Group – Department of Computer Science
University of A Coruña, Spain
{lcastro; gulias; cabalde; sjorge}@udc.es
ABSTRACT. Enterprise Risk Management (ERM) is a field of enormous importance due to its
economic repercussion. More and more companies are paying attention to it, given there is
significant economic savings for attending to the various aspects of risk. At the same time,
ERM has witnessed a shift in the way firms manage the many uncertainties that stand in the
way of achieving their strategic, operational and financial objectives. Nevertheless, existing
Risk Management Systems (RMIS) are neither powerful, nor flexible enough to model the
complexity of the risk management process. In this paper we will examine these issues in
greater detail, explaining the existing problem and proposing a software system that
addresses them. We will also show the actual design and operation of ARMISTICE (Advanced
Risk Management Information System: Tracking Insurances, Claims and Exposures), a
successful RMIS case study.
RÉSUMÉ. Le management du risque dans les entreprises est un domaine d’extrême importance
à cause de ses répercutions économiques. De plus en plus d’organisations s’y intéressent
dans le but d’obtenir des économies à long terme. Dans le même temps, un changement
notable s’est produit dans la façon dont les entreprises appréhendent les diverses sources
d’incertitudes qui font la différence entre atteindre et ne pas atteindre leurs objectifs
stratégiques, opérationnels et financiers. Pour autant, les systèmes de gestion du risque
disponibles actuellement ne sont ni assez puissants ni assez flexibles pour modéliser les
éléments de risques dans toute leur complexité. Cet article examine ces problèmes en détail,
ainsi que les systèmes disponibles pour les résoudre. Nous présentons aussi une étude de cas
du système ARMISTICE qui a été implanté avec succès.
KEYWORDS: Software Engineering, Risk Management, Risk Object, Hazard, Exposure,
Coverage.
MOTS-CLÉS : ingénierie des logiciels, management du risque, dangers, exposition aux risques,
couverture.
DOI:10.3166/JDS.17.501-521 © 2008 Lavoisier, Paris
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

502 Journal of Decision Systems. Volume 17 – No. 4/2008
1. Introduction
Enterprise Risk Management (ERM) is a field of enormous importance due to its
increasing complexity and obvious economic value. More and more companies are
paying attention to it, given there is not only a significant economic reward for
attending to the various aspects of risk (Kauf, 1978), but that what constitutes
Enterprise Risk Management has itself undergone significant change. ERM has
witnessed a shift in the way firms manage the many uncertainties that stand in the
way of achieving their strategic, operational and financial objectives. “Band-aid”
approaches to risk management – with each risk considered in isolation and only
when it occurs – have been replaced with more holistic methods, looking at risks as
they are integrated and interrelated across the entire organisation and managing risk
response strategies well before they are necessary (Nordblad, 1982). Many
organisations have begun to recognise the both value in and the need to change to
this more complex model and approach. Nevertheless, there are few tools available
in the market capable of actually supporting the complex decision process involved.
Every enterprise is unique: their business models differ, the types of products
and services life-cycles are context driven, organisational charts are diverse, their
motivation for overall business style are not the same. However, most of them have
as their bottom line, the same pursuit for economic success, so their objects of
interest may not be the same, but their ultimate aims are. Given that ERM now
recognises that there is greater variety and increasing number and interaction of risks
facing organisations (Coopers and Lybrand, 1997), it is surprising that the few
software applications which claim to help to manage the risks are not designed to
cope with these enormous differences, even though their commonalities are the
really important point here.
Hence, there is a need for a new sort of Risk Management Information System
(RMIS) to fill this void. What is needed is a system designed with one important
thought in mind: to be powerful enough to model all the complexity and diversity of
the risk management process, but also flexible enough to be adapted to any company
and therefore any type of risk, not just the familiar ones, regardless of their
particular business domain.
This innovative RMIS needs be designed to be a tool for the expert user who will
use it to spell out the company’s specific risk situations and their relevant and
complex properties from an expert point of view. It should also be important to be
able to define the insurance policies contracted to protect those resources from the
consequences of potentially harmful events, whichever these might be, for each
particular case. But it would be a tool for the non-expert user as well, the kind of
user who has to deal with accident reports and tracking for example, having little or
no expert knowledge regarding coverage and warranties. To ease this daily job
profile, the system should be able to provide support in the decision-making process,
retrieving and isolating only the most relevant information in each case, according to
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 503
the contextual data provided, and thus, providing extremely valuable support for
final decisions.
In this paper we will examine these issues related to a RMIS in greater detail,
explaining the existing problem and proposing the design of a software system that
addresses them. We start by describing some background ideas and general
concepts. Then we will move on to the key problem and our proposal, explaining the
design and operation of ARMISTICE (Advanced Risk Management Information
System: Tracking Insurances, Claims and Exposures), a successful RMIS case study
based on this design. Its relevance and further possibilities will then be discussed
followed by some brief conclusions and our proposals for future work.
2. Background
Risk Management has become a matter of such importance for the enterprise
today, that it has not only become an aspect of decision making for every CEO but
has moved up through the ranks of middle management and above. This is a direct
consequence of the new business concept it brings with: economic prosperity is not
just about making money, it is also about avoiding losing money. And this means,
most of all, the intimate overseeing of all of a company’s resources (whether they be
human, material, or ideological) monitoring all of its activities, but also from a
preventive point of view. In the business world, the main objective has been always
maximising the enterprise objective through successful planned strategies of action.
With Risk Management now on stage, this performance must take into account that
it is equally important to ensure we protect business activities from failure due to
external or indirect causes that may go unnoticed, at least to the non-expert eye. The
incorporation of risk management then, enhances the overall economic objective by
expressing risk not just as a threat, but also as an opportunity for economic profit
(Nordblad, 1982).
Risk management theories and procedures are formulated and re-formulated
every day, presented and discussed in major conferences and meetings (RMC, 2007;
RIS, 2007; ERM, 2007; IIR, 2007) at an international level. Risk management
associations and organisations (RMA, 2007; IRM, 2007; RIM, 2007) willing to
exchange ideas and experiences draw membership in the thousands.
But even though we now concede Risk Management the economic importance it
deserves, and despite all efforts that are being made to face its implied and obscured
potential threats, it is obvious that we have not employed all our potentially useful
tools against it. In a society where information technologies are more and more
present in the daily life of business and economy, Risk Management seems to be one
of those fields where computer engineering, unfortunately, has not made its impact.
Of course, personal computers are already part of the daily routine of risk
management departments everywhere, but user-level usage of computing is as far as
it gets. This prevents our benefiting, not only from applying automation and
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

504 Journal of Decision Systems. Volume 17 – No. 4/2008
computing power to repeatable processes, but from using software engineering
techniques to create new software tools to solve problems on the whole that are not
being adequately addressed by existing systems. Instead of using computers just as
an auxiliary tool, the key is to use computers and computing power to take over as
much of the risk management tasks and processes as possible.
Software Engineering is a computer engineering discipline devoted to the
systematic and disciplined analysis, design, development, operation and
maintenance of software (Sommerville, 2005; Pressman, 2005). It involves
knowledge about methods and tools for defining software systems requirements, and
also knowledge about tools and methods for designing software that fulfils those
identified requirements, for building such a software system, for testing it, and for
maintaining it. The theoretical principles that allow a group of software engineers to
analyse a field like Risk Management and design a valid solution for its needs, are
those from software analysis and design (Rumbaugh, 1991; Braude, 2001; Larman,
1998; Gamma et al., 1996). Software Engineering uses abstraction to gather the
essence of a problem, leaving all specific constrained details behind and reaching
the main properties of a generic scenario. Once the software engineer has moved
from the concrete needs to the main requirements formal definition, identifying the
core parts of the software solution in the process, it is time to refine each
component’s task and goal on the system to be built. Keeping each of those parts
both as a working element on its own and as an essential piece of the software gear
(modularity), the future system architecture can be outlined. The use of software
design patterns (Booch et al., 1998; Erikson, 2001) is the more convenient way to
carry out this task, ensuring the result to be efficient, robust and flexible.
3. Taking Risk Management one step forward
So we have highlighted that Risk Management is an extremely important
activity, and a key aspect not only for insurance companies, which deal directly with
risk as their most important business element, but also for any type of business
activity, since we can take as a given that risk as an inherent property or
consequence of human activities among other things. In addition, we explained how
and why applying Software Engineering techniques to analyse processes, to model
them, and then to design and create a software system to manage them is the best
way to ensure good results when introducing information technologies into new
fields.
So, given our intention to take Risk Management one step forward, we propose
the application of Software Engineering to the very own concept of risk itself. This
is no longer about designing tools to control existing business processes. Rather, it is
about building a software system that will allow us to control the risks affecting
those business processes, to manage those risks, and to treat them in an appropriate
and timely manner.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 505
In order to achieve this, the same methodologies we use when developing any
software system can be applied here: requirements elicitation, problem abstraction,
and usage of software patterns to obtain a design of the functional architecture of
our target software system. And this is precisely what we have done in our case
study ARMISTICE (ARM, 2007).
ARMISTICE (Gulías et al., 2006; 2005; Cabrero et al., 2003) is an efficient and
robust risk management system (RMIS), developed using software engineering
techniques and methodologies, which permits an unusual and powerful flexibility.
This makes it possible for ARMISTICE to be applied to diverse business fields,
regardless of their nature. The design aspect responsible for this versatility is the
abstraction level reached at the definition of the system, which is that of meta-
information. When talking about meta-information, we mean that we deal with
information about information, that is, we design a system not only able to manage
some specific concepts, tied to more or less specific cases and specific business
scenarios, but with the ability to specify the very nature of those concepts, cases and
scenarios in the first place.
The methodology we followed in the development of the ARMISTICE project
varied from the first stages, when the stress was put on frequent meetings with the
domain experts, to the final stages, when few meetings were necessary and the need
was for user testing of the application. The initial appointments included long
discussion sessions about both what the user demanded and what we, as technology
experts, thought possible to achieve. Risk Management is not a well-known domain
amongst computer scientists, so many explanations, instructions and clarifications
were demanded during the first months. Once the essence of the domain and its
main concepts were clear to us, the system modelling process started. For that
matter, we found UML (Booch et al., 1998) a very useful tool to communicate with
the domain experts. As we formalised the system analysis and design in the shape of
UML diagrams (mainly structure diagrams, but also behaviour and interaction
diagrams), the same diagrams were showed and explained to the experts in the field,
that after a few notions on this standard modelling language were quite easily able to
understand them and even, soon enough, make corrections and put their fingers on
errors and mistakes. As part of our personal experience, we must remark that this
also helped them to feel involved and as part of the development process instead of
just mere clients or spectators, which definitely lead to a greather level of
communication and better results. In addition, the prototyping development cycle
(Pressman, 2005) that was adopted, also allowed the user to, relatively soon, see
their demands on the screen, correct domain missinterpretations, overspecifications,
etc.
Risk management field and needs analysis sheds light on the fact that
irregardless of the specific type of risk to face, the resources or processes exposed to
that specific risk, the shape the threat might take, the different consequences it might
have: the approach in dealing with risks, in general, is common in all possible
scenarios. This generalisation is the key concept behind ARMISTICE.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

506 Journal of Decision Systems. Volume 17 – No. 4/2008
We have gone one step further, defining meta-information instead of just pure
and domain-specific information, so that the ARMISTICE user could be the one to
establish which are the objects of interest, i.e. risk situations, and also the hazards
threatening those risk situations that we are interested in. The way this is achieved is
not only by introducing information about those risk situations, but by previously
introducing the related meta-information, i.e., the information about which type of
risk situations will be in the system. For example, a user interested in the risks
affecting employees would be able to input the specific information about all
personnel. But prior to doing this the meta-information about those risk situations
(employees) needs to be created, that is, ARMISTICE allows one to specify that the
type of object of interest is a person, whose important properties are, for instance:
name, age, gender, qualification, job, salary, etc. This first abstraction is called risk
group.
In Figure 1 we have formalised these concepts into a brief UML diagram, where
each concept/business object is represented by a square box, and relationships
between concepts/business objects by links between them. Directed links show
visibility properties, and multiplicity in properties are also displayed on the diagram
(default is one, * meaning many).
Figure 1. UML model of risk groups and risk situations
So, the diagram shows, every specific object of interest (i.e. every person in the
staff) will be an instance of a risk group, which specifies the relevant properties of a
set of risk situations of the same type. After introducing this meta-information (see
Figure 2), the user can proceed and input the necessary specific data about the
employees (Figure 3).
A similar process involves hazards threatening the risk situations: if the objects
of interest are people, the main hazards may be long-lasting illnesses or strikes; if
the objects of interest are warehouses or offices, the relevant hazards to be taken into
account by the system may be arson, flooding or theft. Again, is the ARMISTICE
domain expert who will first decide what the meaningful risks to the business area
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 507
are, and then introduce them into the system, classifying them (if applicable) under
the appropriate categories.
Figure 2. Creation of a risk situation
Figure 3. Creation of a risk group
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

508 Journal of Decision Systems. Volume 17 – No. 4/2008
Once risks situations and hazards have been created in the system, exposures are
set to match pairs of risk situations and hazards potentially affecting them (see 4(a)).
Many different types of objects of interest can be registered in the system, as well as
many different hazards. However, not all hazards threaten the same kind of risk
situations. A person is probably not vulnerable to theft (unless he/she performs an
important “intellectual” role and competitors may be interested in headhunting or
recruiting valuable employees), but the contents of a warehouse are. Thus, exposures
represent the kind of information that will tell the system which hazards we want to
bear in mind when referring to certain risk situations. When a exposure link is
established between a hazard and a risk situation, some interesting values are
assigned: probable maximum loss (PML), estimated maximum loss (EML), normal
loss expectancy (NLE), intensity or frequency (Figure 4b).
Figure 4a. Risk situation exposures UML model
Figure 4b. Exposures management
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 509
This additional information (PML, EML, NLE, intensity and frequency of an
exposure) will be very valuable an useful for the analysis of the risk management
measures and their effectiveness (see subsection 4.2).
These are the first system configuration steps ARMISTICE needs, so it will
contain the necessary business data to work with. But ARMISTICE is much more
than just a risk situations or hazards database, it is a tool to assist in the
implementation of a company’s overall risk management policy.
Attitude is the basis
Regardless the use of this kind (or any other kind) of tools to assist a risk
manager on his/her task, any company interested in dealing with risk needs to define
a set of considerations, of guidelines and intentions that will comprise the
company’s policy on Risk Management. To face a hazard threat, there are different
risk management strategies that can be applied, different philosophies to follow,
different attitudes to adopt (Navas et al., 1986). They can be classified as follows:
– Avoiding. The first strategy that can be considered when we realise that some
activity involves some risk is just to avoid that activity. Of course, this is hardly ever
possible for all risky activities because, as we said, risk is something that has
become inherent to almost any human activity and certainly to any business
opportunity.
– Minimising/Prevention. Another possible attitude is to attack the very causes of
the risks threatening the risk situations. This implies a hard task of studying the
cause-effect relationship between possible causes of risks and the risks themselves,
which is never easy. After that, it requires investments devoted to introduce
measures to prevent those causes from materialising and to minimise or limit their
consequences (risks and their effects, i.e. potential losses).
– Hold/Assumption. The lack of any risk management policy, intended or not, is
usually called risk assumption. Basically, we do nothing to avoid or prevent either
risks, or their causes. When they eventually do emerge, money is allocated to the
problem to recover from potential losses. The only difference between a deliberate
risk assumption and an unconscious risk assumption is a separate part of the budget
that, in the first case, is allocated in advance, foreseeing what may eventually occur.
– Transference. Last but not least, transferring a risk is most of the times a good
compromise solution. When a risk is transferred, a company, instead of putting aside
part of its funds, hires someone else to be responsible for restoring the losses after a
hazard materialises and affects some of the threatened objects of interest. The
responsibility is normally handed over to another company, generally a specialised
one, such as an insurance company. Risk transference to the insurance company can
be either total or partial. When the transference is total, the insurance company will
take care of any loss caused by the considered risks according to the agreed upon
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

510 Journal of Decision Systems. Volume 17 – No. 4/2008
terms. When the transference is partial, the insurance holder restricts its
responsibility by means of franchises, limits, etc.
Of course, the best risk management policy always depends on the company, its
business area, its particular situation on the market, lifetime, size, etc. Nevertheless,
it is often a wise choice not to apply only one of the previous strategies, but to build
a customised risk management policy choosing for each risk the best attitude in each
specific case.
Even though ARMISTICE will mainly help a risk manager to have first-hand
control and closely monitor a risk transference scenario, and does not directly
manage avoiding, prevention or assumption, we will see, later on, how in fact it can
help to decide if the current policy is good enough or not. This means, for example,
if some risks are being successfully prevented or not (they are causing expensive
losses anyhow), if those assumed ones are dangerously diminishing the company’s
stocks, if those losses caused by transferred risks are really worth the amount of
money that is being paid out to the insurance company, etc.
Figure 5. Insurance policy overview
To enable all these activities, ARMISTICE supports the introduction of the
insurance policies into the system, detailed to the level of the warranties which
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 511
specify the terms of the contracted coverage for the risk situations when some
specific conditions become present. Furthermore, at the warranty level, it deals with
the formulae which calculate franchises and limits when the transference is not total
(Figures 5 and 6).
Figure 6. Insurance policy details overview
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

512 Journal of Decision Systems. Volume 17 – No. 4/2008
Insurance policies are the most complex element in Risk Management, and
consequently in our system. These formal documents, pages and pages long, detail
all the norms, rules and regulations previously agreed upon by all parties: not only
which specific objects are being considered or which particular hazards are being
taken into consideration, but also relevant dates (when the agreement validity
commences and when it expires) and of course all sorts of applicability conditions
and constraints they decide upon. Once an insurance policy term comes to an end,
the agreement can be renewed as is, or it can be modified to include subtle
variations, or it might be renegotiated from scratch. Of course, changes can also be
made by mutual consent even during policy validity period, meaning an amending
document or new enclosure will be written down, where the new terms and
conditions will be put on record and be in vigour at that very moment. Depending on
the business area, theses kind of modifications may even be foreseeable, so that the
new terms applicable, if they finally appear, can be stated and agreed upon in
advance.
To fulfil this real-life behaviour of a policy life-cycle, ARMISTICE has been
designed to allow modelling of insurance policies as a set of renewals (see 7). A
renewal represents a new policy created to provide coverage to a set of risk
situations over a certain time interval. At the same time, a renewal can be broken
down into one or more supplements (endorsements). A supplement represents a
revision of the policy, made to change its coverage, its contractual clauses, etc.
Thus, a supplement represents the minimal element that can be used to give
coverage to a claim. Apart from some indispensable information such as the set of
covered risk situations, the relevant dates and other attributes (such as different sorts
of limits and franchises), the essential core element of a supplement (see 6) is the
conditional. What is more, the conditional is also the key object as far as the
ARMISTICE decision support engine is concerned. Conditionals model the
constraints under which an insurance policy provides coverage for a claim. In other
words, the supplement conditional is a model of the contractual clauses of a specific
policy, the model of the policy coverage, that is to say, the model of the policy
warranties.
The way contractual clauses or policy warranties are specified in the system is
very descriptive. As descriptions of conditions or constraints, these elements must
allow the inclusion of references to actual risks, properties of the risks situations that
are being covered, as well as other policy-related data and calculations (limits,
franchises, etc.). Last but not least, a model of policy coverage can also include short
descriptions (nuances) in natural language. As we will see in the next section, the
possibility of including this human-language explanations as part of the description
of a supplement clause and the ability to deal with them as part of it, allows
ARMISTICE to very faithfully represent reality, and makes it possible for its
decision system to assist the user to obtain extremely accurate results when selecting
the appropriate policy to charge with the expenses of an accident.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 513
Figure 7. UML policy model
Once all this information concerning insurance policies is also in the system,
ARMISTICE is ready to assist risk managers. First, to manage accidents as soon as
they occur, to decide which of the contracted applicable policies is the most suitable
or desirable to apply in each case, and then to be aware of the life of the claim,
tracking the accident from the start point until the file is closed. Second, to analyse
all data and make decisions about the suitability of the current risk management
policy that is being put into practise, as previously mentioned.
4. Improvement of the risk management decision process
The improvement of the risk management decision process that we discuss here
takes place in two different moments and in two different aspects: as a powerful
working tool for the non-expert user, and as an advanced analysis tool for the expert
user.
4.1. Vitalising the daily routine
Thanks to the detailed design, which paid a lot of attention to all domain
properties and characteristics, we find in ARMISTICE a very useful tool for the
daily control and management of a claim. This management process involves, not
only becoming aware of those risk situations that were affected by a particular
hazard, but also estimating losses and repairs costs, tracking all related activities
until the file is finally closed.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

514 Journal of Decision Systems. Volume 17 – No. 4/2008
Having all the information about the contracted policies, ARMISTICE is able to
act as a decision support system, discarding all the irrelevant policies (those with
non-applicable warranty clauses, covering different risk situations, different hazards,
or different time periods) for a given accident. It does so by automatically checking
all policy data (specifically, each supplement/conditional data) against the known
accident details the user inputs. By analysing policy warranties contents and
contrasting them with accident dates, objects of interest involved, materialised risks,
etc., all non-applicable warranty clauses (and thus, all non-applicable supplements,
then policies) can be discarded, leaving for the user to select from only a few
choices, corresponding to those constraints which applicability lays on the human-
language nuances they contain, thus only decidable by a human being. The way this
process is performed consists in pruning branches off the logical tree policy clauses
are organised into. Prunable constraints will be those that can be evaluated and so
designated as true or false by the system.
Let us picture, for instance, an applicability precondition of a hypothetical
contractual clause that would provide coverage against fire (but only if it is not an
arson), flood, and earthquake (but only if a tremor’s Richter magnitude is greater
than 4.0, and whenever total number of employees in the set of affected risk
situations – i.e. company’s offices – is greater than five). Besides, let us say that
coverage would also only be supplied if the government does not provide financial
support to alleviate the accident. These restrictions can be logically organised as
shown in Figure 8a.
Now, if an earthquake strikes the region and there are more than five employees
working in the affected facilities, the system can automatically simplify the
expression to Figure 8b. The user that inputs the original information about the
earthquake and its effects into the system, should now just answer whether there will
be government response to the catastrophe or the tremor had a relevant magnitude
for the clause to be applicable (i.e. true).
Figure 8a. Policy clause representation (logical tree)
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 515
Figure 8b. Simplified logical tree
So the output of the decision support module is, in the end, the list of policies
with non-automatically evaluable constraints/clauses, a much more smaller set than
the original one, of course. These few possibilities can then be explored by the non-
expert user, to decide if the nuances they depend on are important or not, concerning
the specific accident that he/she is dealing with at the moment.
Figure 9. Input of new accident data and assisted policy selection
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

516 Journal of Decision Systems. Volume 17 – No. 4/2008
Figure 9 an example of this process is displayed. As shown, general information
concerning the accident details is required before the actual assisted decision process
can be fired. After at least the time, the affected risk situation, and the source risk for
the accident are determined, the user can ask ARMISTICE for help deciding the
most suitable coverage. The system will discard all non-relevant policies, and report
back just those either already applicable, or else, which require the user to make a
decision on about their suitability because they include human-language nuances
(thus are only human-decidable) present in the warranty clauses text. This turns the
decision making process into something much easier, even for the non-expert user,
since the quantity of information to be taken into account has been substantially
reduced.
Once these initial steps in the accident registration into the system have been
performed, the rest of the file life will consist on dealing with the normal flow of
activities involved in these procedures: determination of the tasks to be carried out
to repair the damages, sending and reception of evidence documentation and various
paperwork, payments issuing and processing, indemnities claiming and recovery,
etc. As a management application, ARMISTICE provides a very complete user
interface to do so, as in Figure 10.
Figure 10. Accident management and tracking
4.2. Efficiently assisting the experts
As repairs are being performed, receipts are coming in, and insurer
compensations are being recovered, corresponding data helps the system to keep the
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 517
claim status up-to-date, right through and up to the final stage when everything is
solved and the file is permanently closed. Even then, ARMISTICE’s usefulness is
not finished. Apart from these everyday kind of operations, there is potential for
analysis that can be performed on the basis of all the daily information gathered.
This is the second risk management working area that ARMISTICE greatly
improves upon.
Figure 11. ARMISTICE reports tool
The head of the risk management department will have the actual data his/her
company is producing added to his/her regular statistical resources, reports and
studies, right away. At any time, he/she can query the system and obtain different
flavours of reports that will show if the risk management policy is doing its job, if
the losses are being recovered as desired, if any of the contracted policies are
redundant or superfluous, if there is any hazard causing uncovered accidents because
it was missed or underestimated at insurance negotiation time. This second task is
even more critical than the first, because it can help to detect deviations on the risk
management policy at relatively early stages and, hence, to correct them.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

518 Journal of Decision Systems. Volume 17 – No. 4/2008
Such in-depth analysis is only possible thanks to the application managing all
relevant information, from risk situations and hazards to policies and accidents.
Then, a report generation tool is provided (see 11) for the expert user to select, first
the kind of information he/she is interested in at one point: exploring the catalogue
of business objects (risk situations, risk groups, hazards, policies), checking the
status of risk situations (coverage) or policies (expiration), or having a thorough
look at the losses (which policies are they mostly charged to, which situations they
usually affect to, which hazards are they more often due to, etc.). Once the type of
report is selected, the user can obtain all the information or refine the query to tune it
to suit a specific need or interest. This is done by giving values to the report-specific
filtering fields. For example, 12 shows how the expert will fill-in the gaps to obtain
a report that shows information about all the accidents that had happened to risk
situations classified as warehouses, claimed during August 2007, and of certain size
or located in certain city.
Figure 12. Details of report-customising form
There is no doubt, and it is fairly well understandable, that this analysis tool is a
very powerful resource for those responsible to have the overall risk management
policy of a company under much higher control.
5. Conclusions and further research
Risk Management is one of the current trends when talking about ways of
improving business performance in any marketplace. Risk is an unavoidable part of
human activities, but different approaches can be used to both confront it and to
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 519
minimise its negative consequences. These approaches include several degrees of
commitment with the risk management philosophy: from having little or none at all
(risk assumption) to a “paranoid” attitude (risk avoidance), and including an optimal
balance between transference and prevention.
As much progress as we are making in introducing new technologies in almost
every aspect of our lives and jobs, Risk Management is surprisingly lagging well
behind in this endeavour. Apart from text processors, spreadsheets, and a few ad-
hoc specific non-reusable solutions, there seems to be a disconcerting lack of
generic, flexible, powerful tools in this field. This is clearly not due to an absence of
need for them, to be sure. The task of a risk manager is so complex that benefiting
from a really comprehensible analysis tool can only improve his/her function,
enormously increasing his/her level of knowledge, and thus, the control and
management experience and overall results. And we must not forget either, the daily
routines of accident management and tracking, which does not need the whole
picture, but has to deal with deciding the most suitable treatment for each incident.
Here we have presented our own case study, ARMISTICE, as a very convenient
risk management process support tool, with decision making assistance abilities, not
bounded to a specific business area thanks to its abstraction capabilities, and meta-
information definition and use. Actually, a token of its success is proven by the fact
that ARMISTICE has been in successful production inside an international
corporation for more than two years now. User evaluation of their experience
reveals that almost all but the essential paperwork has been replaced by the use of
ARMISTICE, and while the number of new risk situations has kept an increasing
rate, the number of contracted policies is stable, reflecting that a better
understanding of the exposures and improved overall risk management has been
achieved.
Furthermore, ARMISTICE is also a successful study case that proves that,
irregardless of the complexity of a given domain, engineering techniques,
methodologies and procedures are powerful enough to overcome initial concerns.
The key step in the way to applying new technologies in such scenarios is
knowledge elicitation from the experts. Here we have shown how the available
standard notational solutions and well-known development life cycles perfectly
apply and favour good results.
And even though we strongly feel that those responsible for risk management
can benefit from using a tool like ARMISTICE as it stands, there is still further work
to be done. A few ideas on this include additional customisable reports, for example,
perhaps in the same way the system already deals with risk situations and hazards
definition (through the use of meta-information). Another very interesting line of
inquiry would be that of architectural and functional pattern detection for these sort
of highly critical applications. The effort carried out to meticulously analyse the
domain and extract the relevant information that was then written down as a model
design, lead to the gathering of the kind of expert knowledge that would be needed
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

520 Journal of Decision Systems. Volume 17 – No. 4/2008
for such a task. Locating behaviour or structural similarities between these kinds of
knowledge-intensive software systems could be really interesting and open a whole
bunch of research possibilities.
Last but not least, in business areas as decisive as this of Risk Management, new
technologies are desired for inclusion as part of the every-day work but in the most
reliable way. So applying software formal verification strategies and tools, to ensure
the validity and persistence of the properties and behaviours of the applications is
also a very important topic to look into.
Acknowledgements
We would like to thank Javier Losada for providing valuable expertise and
advise about risk management domain. This work was partly supported by Spanish
MEC TIN2005-08986 and Xunta de Galicia PGIDIT06PXIC105164PN.
6. References
ARM, “ARMISTICE Project”, http://www.madsgroup.org/armistice, 2007.
Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language, Addison Wesley,
1998.
Braude E., Software Engineering. An Object-Oriented Perspective, John Wiley and Sons,
2001.
Cabrero D., Abalde C., Varela C., Castro L., “ARMISTICE: An Experience Developing
Management Software with Erlang”, Proceedings of Principles, Logics and
Implementations of High-Level Programming Languages (PLI’03), ACM SIGPLAN
Erlang Workshop, 2003.
Coopers & Lybrand, Los nuevos conceptos del Control Interno, Díaz de Santos, 1997.
Erikson E.H., Business Modeling with UML (Business patterns at work), John Wiley and
Sons, 2001.
ERM, “The Enterprise Risk Management Annual Conference”, http://www.conference-
board.org/erm.htm, 2007.
Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns: Elements of Reusable Object-
Oriented Software, Addison Wesley, 1996.
Gulías V., Abalde C., Castro L., Varela C., “A New Risk Management Approach Deployed
over a Client/Server Distributed Functional Architecture”, Proceedings of 18th
International Conference on Systems Engineering (ICSEn’05), IEEE Computer Society,
2005, p. 370-375.
Gulías V., Abalde C., Castro L., Varela C., “Formalisation of a Functional Risk Management
System”, Proceedings of 8th International Conference on Enterprise Information Systems
(ICEIS’06), INSTICC Press, 2006, p. 516-519.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012

Risk Management 521
IIR, “Middle East Risk Management Annual Congress”, http://www.iirme.com/risk, 2007.
IRI, “IRIS integrated risk management”, http://www.irisunified.com, 2007.
IRM, “The Institute of Risk Management”, http://www.theirm.org, 2007.
Kauf E., La Maîtrise des Risques, Securitas, 1978.
Larman C., Applying UML and Patterns, Prentice Hall, 1998.
Navas Oloriz F.J., Fernández Isla G., « Programa de Gerencia de Riesgos en la Empresa »,
Gerencia de Riesgos, 1986.
Nordblad U., “Risk Management”, Risk Management Conference (ICEA), 1982.
Pressman R.S., Software Engineering: A Practitioner’s Approach, 6 edn, McGraw-Hill, 2005.
RIM, “Risk and Insurance Management Society, Inc.”, http://www.rims.org, 2007.
RIS, “Risk Minds Annual Conference”, http://www.icbi-uk.com/riskminds, 2007.
RMA, “The Risk Management Association”, http://www.rmahq.org/RMA, 2007.
RMC, “Risk Management Annual Conference”, http://www.cboe.com/rmc, 2007.
Rumbaugh J., Object-Oriented Modeling and Design, Prentice Hall, 1991.
Sommerville I., Software Engineering, 7 ed., Addison-Wesley, 2005.
Downloaded by [University of Coruna], [Laura M. Castro] at 01:36 18 April 2012