Operational risk management with real-time

business intelligence

B Azvine, Z Cui, B Majeed and M Spott

Operational risk is a function of the complexity of the business and the environment that the business operates in. Such
complexities increase as the business or the environment become more dynamic, i.e. where change is a permanent feature and
a factor to build into the management of the business. The key question that arises is how do businesses respond to such
changes today and, if the nature of the business and the environment is becoming more and more dynamic, what actions can
businesses take to predict and prepare for change. Viewed in this manner, operational risk becomes very closely related to the
operational performance of the enterprise because it can be considered as dealing with changes that have a negative impact
on the operational objectives. It is vital for enterprises to understand in real time how they are performing, and where on the
spectrum of operational risk they are positioned. To accomplish this, it is essential to have a system for establishing the status
of a business at any moment in time in relation to its performance objectives. This is the role of real-time business intelligence
(RTBI), without which operational risk management could be out of date, or in some cases out of synchronisation with the
business cycle, with serious consequences. This paper discusses the cornerstones of RTBI and demonstrates how these are also
essential elements of an effective operational risk management framework.

1. Introduction and timely reporting of performance and expec-

Enterprise risk management can be considered as a number
of, possibly overlapping, components such as strategic,
operational, financial, technology-oriented, etc. The focus
of this paper is operational risk management (ORM) which is
defined by the Basel Committee on Banking Supervision as:
‘The risk of direct or indirect losses due to failures in systems,
processes and people, or from external factors’ [1]. Although
this definition originated in the banking environment, it has
been accepted as a generic definition by other enterprise
sectors. This definition, however, does not establish a link
between the performance of the enterprise and its ORM.
A more intuitive view of ORM, which establishes a clear
link with operational performance, is presented by the
enterprise risk management framework developed by The
Committee of Sponsoring Organisations of the Treadway
Commission (COSO) [2]. This framework has been
established as one of the most comprehensive roadmaps
that helps enterprises in building their ORM processes. This
framework states that:
‘Enterprise risk management over operations focuses
primarily on: developing consistency of objectives and
goals throughout the organisation; identifying key
success factors and risks; assessing the risks and
making informed responses; implementing appro-
priate risk responses; establishing needed controls;
tations. For these objectives, enterprise risk manage-
ment can provide reasonable assurance that
management and, in its oversight role, the board are
made aware, in a timely manner, of the extent to
which the entity is moving toward these objectives’
[3].
The above statement encapsulates the important
elements of ORM and the inter-relationship between these
elements, and also indicates that the starting point of ORM
should be the definition of performance objectives and the
ability to measure the success or failure in achieving these
objectives. This means that in order for ORM to be successful
and up to date with what is actually happening within the
enterprise, a framework for measuring the performance of
the enterprise must be available and must be capable of
tracking the performance objectives, whether at the
strategic level or at the business process level of the
organisation. Such performance tracking and management
capabilities have been provided by business intelligence (BI)
systems and more recently by the real-time business
intelligence (RTBI) framework developed by BT Research and
Venturing [4].
In order to clarify the role of BI and RTBI within ORM, we
dedicate the rest of this section to briefly discussing BI and
RTBI, highlighting the differences between them, and how

154 BT Technology Journal • Vol 25 No 1 • January 2007


the deficiencies of BI has led to the development of the RTBI
vision. This is then followed by an analysis of the relationship
between RTBI and ORM. The rest of the paper will be
dedicated to describing the components of RTBI, the
achievements and technical challenges of these
components, and how they fit within the overall ORM
capability.
1.1 The evolution of real-time business
intelligence
As with many generic concepts, BI is not a well-defined
term. Some consider BI as data reporting and visualisation,
while others include business performance management.
Database vendors highlight data extraction, transformation
and integration. Analysis tools vendors emphasise statistical
analysis and data mining. These different views make it very
clear that BI has many facets. To capture them, we globally
define BI as the framework for accessing, understanding,
and analysing one of the most valuable assets of an
enterprise — raw data — and turning it into actionable
information in order to improve business performance.
Current BI systems suffer from a number of obstacles
that prevent the realisation of their envisaged potential:
firstly, the transition from data into information is
hindered by the shortage of analysts and experts who
are required to configure and run analytical software,
the second issue is the bottle-neck in the transition
from information into action, which has traditionally
been of a manual nature because of the lack of
automatic links back into the business process layer that
facilitate rapid modification of process parameters to
improve performance,
SO
KPI
OPM
retail regional
Fig 1 Traditional BI implementation.
Operational risk management with real-time business intelligence
the third issue is related to the ability to fuse and relate
the huge amount of data from the different sources into
a timely and meaningful source of information,
including the ability to validate the data and deal with
quality issues.
The deficiencies of traditional BI mentioned above can
be addressed by providing capabilities for the seamless
transition from data into information into action, which we
refer to as RTBI [4]. This means that RTBI must provide the
same functionality as traditional business intelligence, but
operate on data that is extracted from operational data
sources with adequate speed, and provides a means to
propagate actions back into business processes in an
adequate time-frame. Specifically, RTBI should provide
three critical components:
real-time information delivery,
real-time business performance analysis,
real-time action on the business processes.
It must be emphasised here that the concept of real time
does not necessarily equate to zero latency in the operation
of these three components. The concept of real time
indicates the timeliness of the ‘information-decision-action’
cycle that is relevant to the specific business environment.
Figure 1 illustrates the situation of current BI systems.
The information flow between operational, tactical and
strategic layers is broken by manual intervention. The
challenge is to use intelligent technologies to model the
manual intervention present in current systems and
automate both the flow of information from operational to
SO strategic objective
KPI key performance indicator
OPM operational performance measure
strategic
tactical
product operational
BT Technology Journal • Vol 25 No 1 • January 2007 155
 Operational risk management with real-time business intelligence

tactical to strategic layer, representing data to the
information stage of RTBI, and the actions necessary to
translate strategic objectives back to operational drivers to
influence strategic decisions in real time, as shown in Fig 2.
1.2 The relationship between ORM and RTBI
A close comparison of available implementations of ORM,
particularly if carried out according to the COSO framework
highlighted in the previous section, with the vision and
developments of RTBI, unveils very strong links in terms of
requirements, goals and methodologies.
Firstly, in order to have any meaningful ORM process in
place, the enterprise has to have a clear and consistent set of
objectives, which according to the COSO framework [3] can
be categorised as:
strategic — these are the high-level objectives, aligned
with and supporting the entity’s mission/vision,
operations — these are the operational layer objectives,
which are related to effectiveness and efficiency of the
entity’s operations, including performance and
profitability goals,
reporting — these relate to the effectiveness of the
internal and external reporting processes, including
financial or non-financial information,
compliance — relating to the entity’s compliance with
applicable laws and regulations.
In a similar manner, RTBI is based on building a hierarchy
of enterprise performance measures starting from the top at
the strategic business objectives and linking these to finer
and lower-order key performance indicators and operational
measures that emanate from the business process layer, as
shown in Fig 2.
The second point of similarity between ORM and RTBI is
evident from looking at the role of key risk indicators (KRIs)
in ORM. A KRI is a metric representing one or more critical
success factors [5]. For example, the age of the IT systems or
the number of server failures per unit time, are KRIs to a
major system failure event. It is sometimes possible to
measure KRIs directly from available data. However this is
not always the case. Typically, risk is calculated by analysing
and modelling of relationships hidden in data. Such analysis
is often performed by experts off line, leading to significant
delays and high costs. One of the key features of RTBI is real-

vision SO strategic objective

fully joined-up automated BI KPI key performance indicator
strategic OPM operational performance measure
SO
tactical
operational

KPI ta
e

rg
c
an

et
rm

s
rfo
pe

OPM
OPM

common data model

human finance operations vertical SCM CRM

resources applications

on demand infrastructure: network, storage and processing

Fig 2 The vision of RTBI.

156 BT Technology Journal • Vol 25 No 1 • January 2007


time discovery of relationships between operation
performance measures, which can be also applied to the
discovery of key risk indicators. RTBI enables real-time
analysis of operational data through continuous and
automated/semi-automated learning resulting in models
that can be used for what-if analysis, target setting and
forecasting of future operational risks.
Another important issue is that in order for ORM to be
successful, it requires accurate and timely information about
the internal operations of the business and its external
environment. Without such information, the impact of risk
events cannot be accurately quantified, and risk mitigation
and control measures will not be able to respond adequately
to threats. With today’s technical advances in IT, and the
emergence of the highly dynamic service-oriented
architecture (SOA-)based enterprise models, the ORM
framework has to deal with huge amounts of data that
change rapidly and that vary in nature from quantitative to
qualitative, and from accurate to lacking in quality. The
answer to such a challenge is in adopting the RTBI data
fusion and modelling methodologies that establish an
information systems infrastructure capable of the timely
capture, aggregation and sourcing of the relevant data.
The link between the ORM framework and operational
process levels of the RTBI pyramid exhibits itself in two
aspects.
Risk mitigation
The first is related to risk mitigation. Once risk is
identified and its impact is quantified, then some action
should be taken to reduce or eliminate its impact. In a
process-based enterprise the majority of these actions
need to be taken at the process level either requiring
long-term changes or with immediate effect. To do this,
a comprehensive business process management (BPM)
framework is needed to model, simulate, and execute
business processes, and to monitor changes at the
process level. A robust and well-designed execution
environment provides for the necessary compliance
with regulatory requirements. This means that once risk
mitigation action is needed, it can be put into operation
with minimum delay at the business process level.
Risk analysis
The second dimension of the ORM/BPM relationship is
a result of the needs for ORM at the business process
level. In BPM, process designers and/or owners should
consider carefully the risk environment affecting the
performance of each individual process. This is done in
terms of analysing the effect of risk events on the
achievement of the process performance indicators and
on the compliance of the process actors and procedures
with the regulatory environment. Modelling and
simulation allows a process risk analysis to be carried
Operational risk management with real-time business intelligence
out at an early stage in order to plan suitable mitigating
actions.
The above discussion makes it clear that ORM is a natural
partner for RTBI. The following sections will go into the
details of this relationship, highlighting the components of
RTBI, current achievements, and focusing on the technical
challenges that should be addressed in order for this
partnership to achieve its goals. Section 2 describes the real-
time analytics and performance framework, and how it can
contribute to ORM. Section 3 discusses the challenges
associated with real-time data fusion and data quality
management and its impact on ORM. Section 4 focuses on
the business process management, its role within ORM and
how real-time technology could reduce change
implementation time and decrease operational risk.
2. RTBI analytics framework
The role of the analytics part within the overall RTBI/ORM
framework is concerned with building performance models
of the organisation, allowing evaluation of the performance
parameters, given external and internal risks. We will first
introduce the concept of performance modelling, and then
add threats and risks as a natural extension.
The main building blocks of a performance framework
are business entities (BEs), each of which represents exactly
one performance quantity of a part of the organisation.
Examples are strategic quantities such as customer
satisfaction or profit, and tactical or operational quantities
such as ‘average time to clear a fault’ or ‘number of
abandoned calls in call centre’. Furthermore, we distinguish
between:
internal performance quantities such as the ones just
mentioned,
business levers which can be changed in order to
improve the performance, e.g. the number of call
centre staff,
external influences stemming from the business
environment, i.e. anything related to customers,
competitors or other factors, e.g. weather, which
influence the business.
2.1 Defining performance frameworks
The first step of building a performance framework is to
identify relevant performance quantities. The approach is
very similar to the ideas formulated by Kaplan and Norton
[6] for balanced scorecards. The search for the right
quantities is usually driven by the strategy of the
organisation, since we are only interested in those quantities
that influence the performance at the strategic level.
Typically, answering questions like the following helps to
identify a set of relevant quantities.
BT Technology Journal • Vol 25 No 1 • January 2007 157
 Operational risk management with real-time business intelligence
How can we express our strategic goals in terms of
measurable quantities?
What are the influences of strategic quantities at
tactical levels, and which operational quantities
influence tactical ones?
What can we control in our business in order to
influence the performance?
What are the external influences we have to take into
account?
Once all the relevant quantities have been identified, the
following step consists of producing a framework that shows
how each quantity affects the rest. As the questions above
already suggest, we select quantities such that they
influence others in the performance hierarchy. Business
levers and external influences are at the bottom of the
hierarchy, linking into operational quantities above them.
These in turn are linked to tactical ones and finally into
strategic quantities at the topmost level. Figure 3 shows an
example framework describing a call centre scenario.
At this point of defining the performance framework,
everything has been done at the qualitative level. We have
defined what quantities we want to measure but not how.
Therefore, the third step is about defining measures for the
quantities. For the quantity customer satisfaction, for
example, we could compute the relative number of very
happy customers according to surveys. An alternative could
be to measure the average happiness of customers. The
decision depends on which definition of measure is more
relevant for the strategy. In the case of the first one, we
Fig 3
158 BT Technology Journal • Vol 25 No 1 • January 2007
completely ignore the distribution of customers who are not
very happy, i.e. we do not measure if most of them are still
quite happy, or if they are utterly unhappy. The second one
takes this into account, but still does not tell us anything
about the variation of happiness among customers.
All measures are based on data, e.g. we require survey
data to measure customer satisfaction. Therefore, for each
performance measure a data source needs to be specified. In
that context, the role of the data fusion layer described in
section 3 is of great importance since the required data is
typically distributed between a number of data sources that
can be easily described as ‘disjoint and heterogeneous’. This
is particularly the case in large organisations. In order to
obtain the correct measurement of a performance quantity,
it is possible that a combination of data sources need to be
accessed in order to assemble the required value. The
capabilities of the data fusion layer in terms of
understanding the data model and relating the contents of
different sources, in addition to the management of data
quality, are crucial for ensuring the validity of the collected
measurements within the performance framework.
Finally, the relationships between the connected
quantities need to be quantified. If the relationship is
known, an equation expressing the relationship can be
defined. Many relationships, however, are unknown in
advance or are of a dynamic nature, i.e. changing over time
as the business environment changes. An example of this is
the relationship between operational quantities and
customer satisfaction. Such relationships can be learnt from
historic data as described in section 2.3.
Call centre performance framework.
 Operational risk management with real-time business intelligence

2.2 Monitoring performance target optimisation (optimise business levers and

An important function of the RTBI system is to monitor the targets for BEs given strategic targets).
performance of an organisation in real time. Data is collected
from operational systems or other internal or external data What-if analysis answers the question of how business
sources via the data fusion engine, and fed into the analytics levers and the business environment influence operational,
module. Whenever new data arrives, the performance tactical and, finally, the strategic performance. We could, for
measures are evaluated. The RTBI platform provides instance, determine how customer satisfaction would
configurable dashboards to display the resulting change if we were to increase the number of call centre staff
performance figures (and optionally a relevant historical and if the number of incoming calls were to change.
view) of each of the quantities within the framework. This
approach is considerably different from common reporting Another type of analysis is the scenario in which a
where performance is only published on a regular basis, e.g. higher-level target value is set (typically by managers), and
monthly, weekly or daily. The dashboards can also be set to the requirement is to determine how this translates into
provide alarms or traffic light type monitors such that lower-level targets. Following the example in Fig 3, targets
warnings can be issued in case of a quantity deviating from for customer satisfaction and costs have to be translated into
its required region of normality. targets for response time, transfer time, server time outs,
etc. This target translation is not trivial since the relations
between the business entities we established can generally
2.3 Learning relationships
not be inverted. The problem of finding targets therefore
As was mentioned previously, not all relationships between
turns into an optimisation problem. For instance, we might
entities are known in advance, and in most cases only
look for targets for all measures such that we achieve a
qualitative knowledge is available about the nature of the
target for customer satisfaction at minimal cost.
relationship. On the other hand, each performance quantity
is measured regularly and the values are collected over time.
In order to be proactive, managers have to predict future
In particular, we can assume that the system collects data of
developments to make the right decisions at the right time.
related entities. Therefore, we can employ intelligent data
This can be achieved by predicting the development of
analysis (IDA) and data mining techniques to learn the
external influences and propagating predictions through the
relationships from data. But learning on its own is not
performance framework similar to what-if analysis. In that
enough for RTBI because of what we mentioned earlier
way, the future performance of the business can be
regarding the changeable nature of some (if not most) of the
predicted given the chosen settings of the business levers.
relationships typically found in the business environment.
The learning and data analysis must be carried out
automatically and repeatedly in a timely manner in order for
2.5 Threats and risks — extending the
the results to be relevant to the situation developing at the performance platform
current time. The performance framework described above measures how
well the organisation is meeting its objectives at various
levels. It also provides capabilities for analysing what is
Learning relationships from data is not trivial, since it
going on in the business using what-if analysis and
consists of a number of steps, each of which requires expert
prediction, as well as for planning and control using target
data analysis knowledge. For each relationship, an
optimisation. ORM, as explained in section 1, is also
appropriate data mining technique has to be chosen and
concerned with the business objectives of the organisation
configured, and the data has to be pre-processed
in that it considers the effects of threats. Threats are
accordingly among other things. Realistically, an expert
situations or entities (e.g. operational conditions,
would set all these steps up based on an initial analysis.
organisations, persons) that might inflict harm on the
Relationships can then be re-learned or adapted at any time
organisation. Thereby we assume that a threat might cause
using the given set up. In the future, tools like SPIDA [7]
an event which influences the organisation. For instance, a
could be plugged into the RTBI system which would
group of hackers (the threat) might attack the network of an
automate a great deal of the set-up procedure. Business
organisation (the event). As a final result, a high level
users could then trigger the learning capabilities of the RTBI
performance measure such as customer satisfaction might
platform without the need to understand the learning
drop considerably, because customers might not be able to
techniques behind it.
access their services any more.

2.4 What-if scenarios, target optimisation and It follows naturally from the above discussion that the
prediction performance platform can be considered as an ORM
Apart from monitoring, two main functions of the RTBI environment through which one can carry out what-if
system are: analysis to predict the effect of risk events, generated by the
threats, on the different performance measures modelled in
running what-if scenarios, the performance hierarchy provided a link/relationship can

BT Technology Journal • Vol 25 No 1 • January 2007 159

 Operational risk management with real-time business intelligence
be established between the risk event and one of the
performance quantities in the graph. It is important to note
here that this differs from the traditional way of carrying out
operational risk analysis, where the temptation is to link the
influence of the risk event directly to the higher level
objectives, which is mainly done by ORM consultants who
use their expertise in quantifying such relationships. In our
opinion such an approach is not suitable for today’s rapidly
changing and service-oriented business environment
because it requires a constant modification of the functions
describing the links between the risks and the objectives,
and requires the expensive services of ORM consultants each
time a new threat is discovered that requires evaluation.
A much better approach is to link the events to the
performance quantities they immediately influence — this
can be done easily by the business expert and does not need
an ORM expert — and propagate the effects up the
performance hierarchy using the capabilities of the frame-
work to evaluate the effect on high-level measures.
However, up to this point, all the framework
relationships are expressed by quantitative functions that
assume a deterministic world. In risk analysis, probability
distributions are attached to risk events to reflect the fact
that these events are uncertain, and their impact on the
performance is similarly uncertain. In other words, rather
than a single performance value, the result of what-if
analysis would be a probability distribution on performance
values. The business user can then derive the most likely
outcomes, but can also investigate other ones which might
be less likely but still possible. Uncertainty in the
relationships between the framework entities must also be
considered and included in the framework, although this is a
more difficult issue and needs further evaluation.
Risk countermeasures can also be incorporated in the
framework by inserting their influence on the relationships
between the risk event and its entry point to the framework,
or in some cases in the relationship between two framework
entities. To find the best set of counter measures, what-if
analysis or optimisation can be used.
3. Real-time data support for ORM
The quality of ORM depends on its data. Good data often
leads to visionary and profitable decision making. Poor data
quality is often the cause of bad strategic decisions and
inaccurate financial and management reporting. Because of
this, most current BI and ORM systems draw data only from a
fixed number of data sources, and it is very difficult and
costly to use data from any new data sources after the
systems have been built. In the following sections, we
present a system being developed within the BT Research
and Venturing programme, which meets the ORM data
management requirements.
160 BT Technology Journal • Vol 25 No 1 • January 2007
3.1 Key ORM data requirements
As discussed in the earlier sections, KRIs are developed by
analysing the business requirements according to data
available from underlying business processes. In the age of
the Internet, the problem is not lack of data, but rather in
identifying good data. Since the data required by ORM is
produced by many operational applications and is stored in a
number of data repositories, careful analysis must be carried
out to determine its suitability. The implicit context and
semantics of data must be made explicit to ORM designers,
as well as to business users, to avoid data misuse.
There are many existing tools for handling so called dirty
data. These tools can adequately tackle syntactical errors of
data, missing data and incorrect data such as non-telephone
numbers for telephone number columns, and non-
numerical data for numerical columns. However, these tools
are often unable to handle semantic issues associated with
data. This is a serious shortcoming. As mentioned above,
data is produced with implicit semantics in specific contexts.
For example, the percentage of the churn of broadband
customers cannot be generalised to the percentage of the
churn of all the company’s customers. Data has to be taken
in the right context so that all users would have the same
interpretation (i.e. semantics) of a set of data no matter
where and how it is used.
Although data management communities have talked
about the importance of data semantics for a long time,
current vendor solutions have not made data semantics
explicitly available to end users. For example, data
warehouse solutions focus on target schema definitions and
ETL (extract, transform and load). There is hardly any formal
documentation, i.e. documentation that could be processed
by machines. Even if some informal documentation exists of
target schemas and transformation specifications, it is rarely
available to the end user, because much of the semantics is
still hidden in transformation codes. As these are not made
explicit, KRIs are often defined by dedicated teams who
understand the business and the data. The high cost
associated with this means only a few KRIs could be defined.
However, there are many occasions that KRIs should be
defined dynamically by end users who may not know the
implicit semantics. This means that data semantics as well as
contexts have to be available to these users. A true ORM
needs to have the capabilities for business users to choose
data and data context to compose or define new KRIs, and
to get unified data support from any available data sources.
The key requirement to support business users in
defining KRIs and KPIs on-the-fly is to relieve them from
knowing the details of low-level data integration. Data
should be presented to the measure builders in terms they
understand. This would address the usual gap between IT
departments and users and business users, who often blame
each other for project failure. IT personnel are often unable
to understand business requirements, while business users
 Operational risk management with real-time business intelligence

are unable to articulate their requirements exactly. Thus
there is a need to supply the data in context for business
users to define new measures, i.e. KRIs or KPIs, which in turn
would lead to the broad adoption of ORM and BI.
The widespread use of ORM or BI requires a data layer
that allows dynamic integration of new data sources,
because enterprises cannot afford to build data warehouses
for every BI application. Thus the technologies must be
developed to provide the following:
automated data mismatch reconciliation — this is a way
of combining data while removing any mismatches
between the different data sets.
This type of data layers empowers business users to
select data sources suitable for their applications from a pool
of silo data sources without the risk of misusing them. They
can safely and dynamically define any KRIs based on the
latest data including data from external data sources. As the
data layer provides a unified view of selected data sources, it
shortens application developments.

unified data layer — a common metadata structure
unifies data access by creating a virtual warehouse view
of enterprise data so that all users, regardless of their
departments or analytical prowess, have access to the
same values, field names and sources,
streamlined development cycle — this is a step-by-
step guide to creating machine processable metadata
repositories and a mapping between metadata and
concept-based data access,
3.2 Real-time data fusion and data quality
platform
This section overviews the real-time data fusion and data
quality platform in the light of ORM requirements. The
system was originally developed to support real-time
business intelligence [4, 8, 9].
System architecture
Figure 4 shows the overall architecture of the system. The
semantic data repository includes metadata of all available

business software/
users applications

C Thing
C Customer

business C BroadbandCustomer data

vocabulary address quality

customerName
productName

automatic
fusion

semantic
repository

Fig 4 RTBI data fusion and data quality system.

BT Technology Journal • Vol 25 No 1 • January 2007 161

 Operational risk management with real-time business intelligence
data sources. These metadata take the form of a centralised
ontology which forms the business vocabulary. Currently the
system supports both relational and XML data sources. For
other data sources, adapters are needed.
When a data source is plugged into the semantic
repository, IT users use a GUI mapping editor, as shown in
Fig 5, to publish its metadata in terms of concepts defined in
the centralised ontology.
This is different from data warehouse building in that ETL
needs to resolve heterogeneities of data sources, while our
system only requires descriptions of metadata of the data
source one at a time. It does not require IT users to resolve
any mismatches with other data sources. The mismatches
between data sources are resolved by the system at run time
by analysing the published metadata, removing the need for
the repeated ETL processes required by the data warehouse
approach. Moreover, the mappings could be done in a
distributed fashion. In addition, they can be changed or
updated easily as they are in declarative form and do not
involve other data sources. One caveat of this is that the
changes made will affect all applications. This could be a
good feature or a bad one depending on the applications.
For each data source, the semantic repository includes a
semantic description of its contents, and a profile of its data
quality, i.e. how good its data is according to certain
measures. The profiling is done through business rules. We
have used machine learning techniques to try to learn these
rules from training data. The system can also use third party
data quality software through APIs.
Fig 5 Mapping editor for publishing data source metadata using ontology.
162 BT Technology Journal • Vol 25 No 1 • January 2007
The fusion engine provides the unified view of all
selected data sources. Through this view, users can compose
their queries. Upon receiving these queries, the fusion
engine decomposes them through the ontology and
available mappings into sub-queries, which could be
processed by each data source. Using each data source
description, it computes a query graph using any possible
semantic-based joints. This means they are derived through
ontology definitions and mappings. Each sub-query is then
sent to the data source to retrieve partial results. Once all
sub-queries are computed, the fusion takes place using the
semantic joint graph. Finally the fused results are provided
to the end users or end applications through Web Services.
The user can select any data sources from the semantic
repository through GUI interfaces. There are two kinds of
information available to assist end users — a semantic view
of the data for each data source, and a data quality profile.
After viewing these details, users click to select or deselect
data sources, and save the selection. Then a unified view of
selected data is computed and presented to them for
querying.
Data adapters are software wrappers, which provide
translation between ontology queries and native data source
queries. The pre-built adapters are available for relational
databases and XML data sources. For other data sources,
adapters have to be built. This includes retrieving data
source metadata, and mapping ontology queries to native
data source queries.
The mapping editor provides a set of standard transform-
ation tools. Currently these include pass-through trans-

formation, filter transformation, expression transformation,
concatenation and joint transformation. Other transform-
ations are still in development.
Ontology as data models
The system uses ontology as data models. Actually there are
several different ontologies. Figure 6 shows the relationships
between them.
A shared ontology is a common, agreed vocabulary [10]
of both domain users and developers. We treat this ontology
as a superset of vocabulary, which is rich enough to describe
any enterprise data sources. Tools have been developed to
update this shared vocabulary.
Source ontologies define the data semantics of their
associated data sources. The terms in source ontologies are
often taken from a shared ontology, but their definitions
could be further constrained. For example, certain attributes
may be sub-typed or have fixed values. New terms may be
defined, over and above those in the shared ontology.
Shared, source, user and application ontologies are the
critical components for the RTBI data layer to perform
context-based mismatch reconciliation at run time. As an
example, products could be priced in different currencies.
The system could automatically convert all product prices
into pounds sterling for UK users, and US dollars for US
users. Of course, the user could force the system not to
resolve any mismatch, if they prefer.
applications
user application
ontology ontology
shared
ontology
source source source
ontology ontology ontology
database Web
files
Fig 6 Ontology models for the RTBI data fusion and data quality
system.
Operational risk management with real-time business intelligence
Implementation
The data layer has been implemented using J2EE/Java, and
deployed on a BEA Weblogic server. All the tools are
available through the Web so that end users do not need to
install any software. The system is currently being trialled by
BT Openreach, using several BT data sources.
4. Business process management
A key feature of the RTBI framework is that once targets
have been set for operational parameters (as a result of
target optimisation to achieve a strategic objectives), the
operational layer is modified accordingly in order to achieve
the targets. This is done either by changing the parameters
of the business processes, or by modifying the process and
deploying the new version in the operational environment.
This means that there is continuous feedback between the
performance framework (section 2) and the business process
management environment, in which information and
decisions are fed back and forth in a timely manner. The
following sections will discuss our BPM environment and
how it supports RTBI, then take a look at how BPM is related
to ORM.
4.1 The BPM environment within RTBI
The business process management environment is based on
the open source JBPM [11] as the core workflow system
where the processes are executed and/or simulated. JBPM
defines processes through JPDL, a workflow language that
allows parallel execution, selective branching and process
composition. We have extended the JBPM system to store
the audit data trail in a database in a structured way so that it
can be used in posterior analysis. A process task is defined as
a black box, whose function is performed by an actor
(human or system) and whose results are expressed in terms
of output attributes. These attributes represent any
important information about the tasks such as timing, cost,
or any other attributes that can contribute directly or
indirectly to the performance analysis and measurement of
the process. Processes are defined with input and output
attributes, making it easy to use process composition. Task
output attributes can be mapped into process output
attributes, connecting the low level implementation of the
process with the external high level view.
The BPM environment is composed of the following
elements:
process designer — a visual application used to create
the process model, based on JBPM’s process designer,
execution server — a server where the real process can
be executed according to the model,
process simulator — an environment that simulates the
process execution using the model created by the
designer, and the knowledge extracted from the trail of
the execution server,
BT Technology Journal • Vol 25 No 1 • January 2007 163
 Operational risk management with real-time business intelligence

KPI tool — a tool that is used to define metrics for the
process and to calculate them against the execution or
simulation data — these metrics link the business
process executions with the high-level goals of the
company,
business rules — this engine allows the definition of
business rules and manages the triggering of the
actions associated with them during the execution (real
or simulated) of the process — these rules represent the
business constraints set to complement the process
model created by the designer.
As shown in Fig 7, the process simulator and the
execution server constitute the two parallel pillars of the
BPM system. They are fed with the processes created with
the process designer and connected to the business goals
and constraints through the KPIs and business rules
respectively.
The process simulator follows an event-based
architecture integrated into the workflow system with the
following main components:
resource management system — used to assign tasks to
actors in the system.
All the process-generated data is captured and stored in
the database whether in real execution or in simulation. In
addition, real-time execution data is available through event
listener interfaces that allow integration into an enterprise
data bus for transporting to other systems or for data
transformation using the data fusion layer. This allows the
monitoring of the process simulation/execution in order to
evaluate any change to the process, be it through a re-
engineering effort (e.g. a new resource assignment policy)
or through an unforeseen problem (e.g. failure of suppliers
to deliver on time).
In order to carry out local process performance analysis,
two tools are provided which allow monitoring of process
performance. The first is a KPI tool, which consists of a visual
editor for KPI definition in terms of task and process
attributes, and an engine that evaluates the current and
historic value of a KPI and displays the result as customised
charts as shown in Fig 8, where the queue time is monitored
as part of a client order process.

event scheduler — used to order and fire the events
within the simulation time-scale,
workflow system — ensures that the simulation is
executed as prescribed by the process model,
process sources — generate new process instances that
constitute the start point of the workflow executions,
The second performance analysis tool is the business
rules engine. These rules can be defined and checked against
the process instances to find exceptional situations in
process behaviour.
Three different scopes have been defined according to
which the rules can be checked:

task execution estimators — responsible for estimating node — the rule is checked when leaving a certain
the task output attributes and duration, node,

resource
policy process
execution
history
server
process database
execution action
handlers

process process event analysis

business
optimisation KPI tool
designer definition rules listeners
components

action
handlers

simulation
system simulation
resource history
policy database

task process
estimator source

Fig 7 The BPM environment.

164 BT Technology Journal • Vol 25 No 1 • January 2007


Fig 8 Process KPI monitoring.
process — when the process instance has finished, the
rule is checked,
global — rule checking is carried out periodically.
In this case, the rule can check constrains relevant to the
group of processes finished in that period, rather than just
one single instance. The consequence of the rule is defined
as an interface. The system provides the user with some
basic implementations (e.g. stop the process, send an e-
mail), any other action can be carried out by implementing a
new class (written in Java) that extends that interface.
4.2 BPM for ORM
The role of BPM in an ORM implementation was mentioned
in section 1, where two aspects were identified. The first
aspect is the local ORM within an individual process
(process-oriented ORM), the responsibility of which falls on
the process owner. The process owner is accountable not
only for the performance of the process (i.e. meeting the
KPIs), but also for making sure that potential threats to the
process performance and their related risk events and
situations are identified, analysed and measures are put in
place to mitigate their effects. It is important that the local
risk analysis is done in terms of the operational objectives of
the process in order to focus the effort of risk analysis on the
most relevant issues. In a similar manner to the risk analysis
within the performance framework, discussed in section 2,
threats should be classified as internal or external, and their
relevant KRIs identified and measured.
Another important issue in process-oriented ORM is
compliance with both legal requirements and with local
Operational risk management with real-time business intelligence
regulations for carrying out process tasks, especially in
processes which involve considerable human interaction.
Legal requirements are continuously increasing, leaving
companies facing huge financial penalties as a result of
infringement. On the other hand, people taking short cuts
and working ‘around the process’ in carrying out their tasks
is one of the major reasons for process failure leading to
missed targets and increased customer dissatisfaction.
The second aspect of the BPM/ORM connection is that
mitigation of operational risks identified within the overall
performance framework (section 2) usually requires actions
to be taken on the process level. Examples of such actions
are complete process re-design, monitoring of process
execution in terms of performance and ensuring process
actors comply with regulations.
The requirements of these two aspects are quite
interrelated and can be serviced with a similar set of tools to
provide the required functionality. The BPM environment,
discussed in section 4.1 above, provides many of the
functions needed to carry out the local process risk analysis
and the risk mitigation requests filtering down from the
performance framework. As an important first tool, the
process simulator allows process owners to evaluate what-if
scenarios in the execution of the process, changing process
parameters and including risk events. For example, call
centre process owners can evaluate the risk of losing a
percentage of the staff, e.g. as a result of illness or strike
action, by simulating different scenarios for resources and
incoming calls, thus enabling them to plan the necessary
actions in case such a risk should materialise. Another
BT Technology Journal • Vol 25 No 1 • January 2007 165
 Operational risk management with real-time business intelligence
important tool is the business rule engine that allows flexible
configuration of compliance rules and monitoring of any
infringement of these rules in real time, enabling the process
owner to take immediate action to rectify the situation and
to prevent the results of the infringement from propagating
further and causing serious damage. Another capability that
facilitates the deployment of mitigating actions is the
flexibility of process design and rapid deployment of a new
version of the process in the operational environment in
order to minimise the damaging effects of a developing risk
situation. Finally, the KPI editing and monitoring tools can
also be used for building and monitoring process KRIs in a
systematic way so that process managers can easily and
quickly mange performance and risk in an integrated manner.
5. Conclusions
This paper has discussed the different components of RTBI
and how these can work towards achieving a successful
implementation of ORM that is based on a continuum of
objectives setting, monitoring and optimisation. We have
followed broadly the COSO framework for enterprise risk
management, which has established itself as the de facto
standard for ORM implementation.
The business performance framework is the first
component within RTBI, and is responsible for building
performance models of the organisation, allowing the
evaluation of the performance parameters of the business,
as well as providing the ability to carry out what-if analysis
and target optimisation. These facilities allow business
managers to have real-time visibility of the status of their
targets, and to assess the effects of any actions they want to
take on performance. The same tools can be used to assess
performance given external and internal risks, thus
providing an integrated view of performance and risk.
RTBI and ORM cannot succeed without the availability of
information which is clean, timely and relevant. Without it,
operational risk management could be out of date or in
some cases out of synchronisation with the business cycle,
with serious consequences. However, the diversity and
typical ad hoc implementation of data sources within large
enterprises makes the task of making the data available very
difficult. This is where the second component of RTBI comes
into play — the data fusion layer. Based on a common data
model, this layer empowers business users with the ability to
integrate data using any available data sources based on
conceptual views of the underlying data sources. This is
achieved through metadata, abstraction and separation of
low level data from their semantics. Thus IT users can focus
on publishing their data through ontologies, i.e. conceptual
views. As the system retrieves data from the data source
directly, this guarantees the freshness of the data.
This was followed by discussion of how the third
component, BPM, fits into the scheme of RTBI and ORM. We
166 BT Technology Journal • Vol 25 No 1 • January 2007
presented the tools that assist process owners in carrying out
process-oriented ORM, and discussed the role of BPM in risk
mitigation.
Despite the development of advanced statistical
techniques for ORM, it is currently the view of some experts
that, for a large business, the most meaningful analysis must
be qualitative in nature because of the difficulty in
establishing the accurate quantitative relationships between
risk events and strategic business goals. Although we
acknowledge the fact that qualitative analysis has an
important role to play, we are of the view that the source of
the problem is that quantitative risk analysis is not carried
out with the help of a complete performance framework
such as RTBI. RTBI allows detailed modelling of the business,
based on solid information provision and a two-way link to
the business process layer. Saying that, some of the
relationships within the framework can be qualitative and
best described by qualitative modelling methods such as
those provided by the field of soft computing.
References
1 ‘International Convergence of Capital Measurement and Capital
Standards: A Revised Framework’, Basel Committee on Banking
Supervision (June 2003) — www.bis.org/publ/bcbs107.pdf
2 The Committee of Sponsoring Organisations of the Treadway
Commission (COSO) — www.coso.org/
3 ‘Enterprise Risk Management — Integrated Framework’, published by
the COSO organisation (2004).
4 Azvine B, Cui Z, Nauck D and Majeed B: ‘Real Time Business Intelligence
for the Adaptive Enterprise’, in Proceedings of the IEEE Joint
Conference on E-Commerce Technology (CEC'06) and Enterprise
Computing, E-Commerce and E-Services (EEE'06), San Francisco, pp
222—229 (June 2006).
5 Vinella P and Jin J: ‘A Foundation for KPI and KRI’, in Davis E (Ed):
‘Operational Risk — Practical Approaches to Implementation’, Risk
Books (2005).
6 Kaplan R S and Norton D P: ‘Balanced Scorecard: Translating Strategy
into Action’, Harvard Business School Press (1996).
7 Nauck D , Spott M and Azvine B: ‘SPIDA — a novel data analysis tool’,
BT Technol J, 21, No 4, pp 104—112 (October 2003).
8 Cui Z, Jones D and O’Brien P: ‘Semantic B2B Integration: Issues in
Ontology based Approaches’, ACM Sigmod Record Special Issue on
‘Data Management Issues in E-commerce’ (March 2002).
9 Cui Z, Tamma V and Bellifemine F: ‘Ontology management in
enterprises’, BT Technol J, 17, No 4, pp 98—107 (October 1999).
10 Cui Z, Shepherdson J W and Li Y: ‘An ontology-based approach to
eCatalogue management’ BT Technol J, 21, No 4, pp 76—83 (October
2003).
11 Open source JBPM — www.jboss.com/products/jbpm/

Ben Azvine holds a BSc in mechanical
engineeering, an MSc in control engineering,
a PhD in intelligent control systems from
Manchester University and an MBA from
Imperial College, London. Having held research
fellowship and lectureship posts in several
universities, he joined BT to set up a research
programme to develop and exploit soft
computing and computational intelligence
techniques within BT. Since then he has held
senior, principal and chief research scientist
posts at Adastral Park where he currently
leads the business intelligence research
programme. He is the author of two books,
has published more than 100 scientific papers and is an inventor on more
than 20 patents. He has won four British Computer Society gold medals for IT
innovation and more than ten BT innovation awards, holds visiting professor-
ships at Bristol and Bournemouth Universities, and a visiting fellowship at
Cranfield University. His current research interests include real-time business
intelligence, predictive CRM and next generation smart services.
Zhan Cui received a BSc (1981) and an MSc
(1985) in Computer Science from Jilin
University of China, and a PhD in Artificial
Intelligence from Academia Sinica in 1988.
Between 1989 and 1996, he worked as a
research fellow in the areas of artificial
intelligence and databases not only for the
Universities of Edinburgh and Leeds, but also
for the Imperial Cancer Research Fund (now
Cancer Research UK), and as a lecturer for the
Universities of Swansea and Liverpool. He
joined BT in October 1996. Since then he has
been working on R&D projects in software
agents ontology, knowledge management
and the Semantic Web. He is a recognised expert in ontology-based
approaches to semantic integration of disparate information sources. He has
authored more than 50 technical papers and is an inventor on more than 12
patents. He is currently working on automatic taxonomy generation from
text, text categorisation and fusing data from unstructured data sources
such as Web pages and documents.
Operational risk management with real-time business intelligence
Dr Basim Majeed is a Principal Research
Professional at the Intelligent Systems
Research Centre within BT Research and
Venturing at Adastral Park.
He holds a Masters degree (1987) and a PhD
degree (1992) in Intelligent Control Systems
from the University of Manchester.
He is part of a team working in the area of
real-time business intelligence and business
process management. He is a Member of the
IET and IEEE, and a Chartered Engineer.
Martin Spott received a Diploma (MSc) in
Mathematics in 1995 from the University of
Karlsruhe, Germany.
He continued working in Karlsruhe until 2000
as a research assistant in the Innovative
Computing Group of Prof G Goos. He
completed his PhD in Computer Science in
November 2000 with a dissertation on
‘Reasoning with Fuzzy Terms’ and joined BT in
January 2001 where he works as a Principal
Researcher in the computational intelligence
research group.
He has published numerous papers in his research area, and is also a regular
member of programme committees for related conferences and a reviewer
for scientific journals. His current research interests include soft computing,
machine learning and data mining.
Since joining BT, he has worked on several intelligent data analysis projects
like travel time prediction, real time business intelligence tools and a
platform for automating data analysis, for which he received a BCS medal in
the category ‘IT Developer of the Year — Infrastructure’ in 2005.
BT Technology Journal • Vol 25 No 1 • January 2007 167