View
221
Download
0
Category
Tags:
Preview:
DESCRIPTION
In today’s world, people expect the same level of ease when engaging IT systems in their working lives as they have in their private lives where they are accustomed to intuitive apps on mobile devices and tablets.
Citation preview
Operational Business Analytics
Whitepaper20-08-2013
The gap in the IT landscape which holds the key to making self-service BI work
Colophon
Every Angle Software Solutions
Kampenringweg 45C
2803 PE Gouda
The Netherlands
www.everyangle.com
Authors: Fred Hermans, Hans Veltman, Jacques Adriaansen
Published: August 2013
© Every Angle Solutions, Gouda, The Netherlands
No part of this publication may be reproduced in any form
without permission in writing from Every Angle Software
Solutions
Contents
1
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
3.1
3.2
3.3
3.3.1
3.3.2
4
4.1
4.2
4.2.1
4.2.2
5
Overview
Different Processes, Different Requirements
Introduction: Business Processes and Requirements for IT-systems
Historical Background
Executive Focus and Execution Focus
The Executive Angle
The Execution Angle
Summary: Executive and Execution
The Everyday Practice
Different Reporting and Analytical Systems
Introduction: Business Processes, BI and Operational Business Analytics
BI Systems
OBA Systems
Why is it so difficult to realize OBA within ERP?
Why is it so difficult to realize OBA with traditional BI?
How does a Solution Architecture with ERP, BI and OBA look like?
The proposed solution architecture
Functionality OBA
Business User Self Service Tool
Feeder to BI-systems / dashboards
Conclusion - What Business Value does OBA bring?
4
5
5
5
6
7
7
9
9
11
11
11
11
12
12
13
13
14
14
15
16
4
1. Overview
In today’s world, people expect the
same level of ease when engaging IT
systems in their working lives as they
have in their private lives where they
are accustomed to intuitive apps on
mobile devices and tablets.
The trend, called consumerization, com-
bined with the maturing of IT systems,
result in business users becoming ever
more demanding for information that
helps them improve their business pro-
cesses and bottom line performance. In
this evolving IT landscape, Operational
Reporting and Business Analytics are
too often treated as a kind of neglected
child in the IT architecture. As a result,
business users fill in this gap themselves,
using spreadsheets and a variety of local
databases. Without question, this is an
undesired and costly situation, both from
the IT and business perspectives.
By looking back in time, the evolution
of this situation can be explained. When
transaction systems like ERP entered
companies back in the 90’s, everybody
thought these systems would solve all in-
formational needs. It slowly became clear
that these “Systems of Record” were not
able to do that and Business Intelligence
(BI) systems arrived as the suggest-
ed solution. BI systems are dedicated
reporting systems which extract and
transform data from multiple systems
and provide publishing tools for analysis
and reporting. Although these systems
are very powerful, companies now realize
that BI cannot solve all the information
needs across all departments at all
organizational levels. There is a gap. A
new type of technology is required which
provides the most granular level of detail
possible and gives the user speed and
flexibility. Such a technology, engineered
to deliver reporting and analytics on an
operational level, is the next step in this
evolution over the years to come. In this
paper, it is referred to as an “Operational
Business Analytics” (OBA) system.
At present, however, many companies
are forced to deal with a gap in the IT
landscape at the business user level
since they do not have an OBA system in
place. In order for users to solve complex
business questions which often arise on
an ad-hoc basis, they utilize locally creat-
ed solutions and spreadsheets. Classical
BI systems and ERP systems simply do
not fulfill the granularity and flexibility re-
quirements necessary for business users
to define and answer their own analytical
queries without the support from IT pro-
fessionals. When the attempt is made to
use them for this functionality, the result
is a high level of IT projects failing to
meet expectations.
OBA systems that are well implemented
and utilized are the missing link in the IT
architecture. They empower business us-
ers and enlighten IT professionals. They
are also an important piece in the reali-
zation of a “closed loop system” enabling
the operations management to translate
the executive strategy into action on the
work floor. Next to that, OBA systems are
a powerful tool to improve data reliability
and assist in meeting internal and exter-
nal compliance requirements.
“Companies now realize .
that BI cannot solve .
all the information .
needs across all .
departments at all .
organizational levels.” .
Five Characteristics of an Effective
OBA System
1 Lowest level of transactional detail is
accessible
2 Smooth and automatic refreshment
of data from the originating transac-
tion processing systems
3 Expose the data to the end-users
in ‘’business language’’ and add
‘’pre-calculated fields’’ to make ana-
lytics easy
4 A user interface that invites and
enables business users to create
and update their own reports, ag-
gregations and root-cause analytics
(Self-Service)
5 Operates extremely fast, even when
dealing with millions of records
5
“Companies now realize .
that BI cannot solve .
all the information .
needs across all .
departments at all .
organizational levels.” .
2. Different Processes, Different Requirements
2.1 Introduction: Business Pro-cesses and Requirements for IT-systems
Since the introduction of the com-
puter for business support, much has
changed technology-wise, but orga-
nizationally the challenge remains
the same. “Business users” impose
requirements that IT must fulfill and
IT delivers functionality to meet these
requirements. Simplified and for the
purpose of this paper, it is depicted as
follows:
Three process types can be distin-
guished, on the business side:
• executive and higher management
processes: these processes define the
external strategy of an organization,
define the (operational) processes and
organizational structure, and are con-
cerned with the overall performance
and risk
• operational management processes:
plan and control the operations
• operational (execution) processes: this
is where the actual work is done. An
operational process can be physical in
nature (receiving goods and storing in
warehouse, manufacturing, packaging
and distribution) or can be adminis-
trative in nature (invoice processing,
insurance policy processing, financial
reporting, etc.).
On the IT side, different types of IT sys-
tems exist:
• business Intelligence systems (“report-
ing systems”): this is a container term
that refers to the IT-systems where the
functionality is provided for planning,
analysis, reporting and control. In other
words, these are systems to acquire
insight for decision making and support
focused actions
• transaction processing systems
(“systems of record”): these are the
IT-systems where the (master- and
transaction) data are stored, required to
execute or resulting from the execution
of operational processes.
2.2 Historical Background
In the last decades of the 20th centu-
ry, the marriage between systems for
financial administration and logistic
systems like MRP I (Material Require-
ment Planning) evolved to the genesis
of standard ERP (Enterprise Resource
Planning) packages. ERP systems
deliver functionality to support many
Corporate Business
Intelligence
TransactionProcessingSystems
IT Systems
Analysis, Reporting & Control
Master Data & Transactions
Data
Information
Functionality
Requirements
Execution
Operational management
Business
Executive andHigher Management
Evaluate the Past Focus Actions
Act
6
business processes from purchasing to
sales and from financials to production
planning.
This was quite a spectacular evolution,
since ERP systems replaced many de-
partmental IT systems silos. Nowadays it
can be difficult to imagine, but in the 70’s
and 80’s, most companies used separate
systems for each business function. The
financial department, the sales depart-
ment, purchasing, warehousing and
production planning each had their own
local system. Generally these systems
were not interconnected. At the best
they were loosely connected, involving
employees copying data from one system
to another with tapes or floppy disks.
Replacing all these local systems with
one big ERP system was an important
and sometimes a dangerous step to take
for a company. Not only were individual
processes automated, but processes
became connected, or as it was called
“integrated”.
Take, for example, the following scenario.
As soon as the receipt of goods from
a supplier would be posted in an ERP
system, the stock quantities would be
automatically updated, as well as the sta-
tus of the purchase order, the financial
value of the stocks, the work list of the
quality department and maybe even the
list of transfer orders for the warehouse
manager. The projected expectations for
improved efficiency were huge, once the
people had become accustomed to the
system.
ERP systems were sometimes regarded
as the solution for all information re-
quirements. Since all data was stored in
one system, it seemed only logical that
this system could easily use this data to
provide valuable information to all users.
This expectation, however, did not be-
come reality. Many companies suffered
quite a disappointment after an ERP
implementation when they discovered
that the system could not fulfill their
reporting needs. There were too many
performance constraints in the hardware,
and the complexity of the information
structure led to high costs as well as
long lead-times when developing reports.
Sometimes, the ERP systems did not cov-
er all data that was needed, or data from
multiple ERP systems was required.
As a result, new systems for BI (Business
Intelligence) were introduced. A dedicat-
ed DW-system (Data Warehouse) that
stored all relevant data from multiple
sources formed the basis for these new
systems and took the load off the ERP
system. The BI systems appeared to suc-
cessfully cover the information needs of
higher management, however, they did
not prove beneficial for operational man-
agement and overall operations.
2.3 Excutive Focus and Execu-tion Focus
Operational processes as well as the
management of day-to-day processes
(“Execution Focus”) differ in nature
from executive/higher management
processes (“Executive focus”).
This is in the picture on the right.
“Not only were .
individual processes .
automated, .
but processes became .
connected, or as it was .
called ‘integrated’.” .
7
“Not only were .
individual processes .
automated, .
but processes became .
connected, or as it was .
called ‘integrated’.” .
2.4 The Executive Angle
The executive management function
involves the higher managerial layers
in organizations. It deals with the
functions: plan, execute and control.
Its focus is on overall business per-
formance, governance and risk man-
agement.. Typically, the accountability
structure (hierarchical/departmental)
of an organization is followed, indicat-
ed by the vertical arrow.
The information needed to inform top
management is often highly formalized
and can be realized with standardized
reporting. The information requirements
must be well defined and stable, leaving
no freedom for interpretation or confu-
sion. The definition process of this control
information can be lengthy and involve
discussion. However, once defined, the
specifications are translated into software
solutions and “set in stone”, and this solu-
tion will be in use for as long as the funda-
mental strategy remains in place...
2.5 The Execution Angle
Operational execution and operations
management, corresponding to the
right side of the diagram above, is
about achieving process performance.
The core questions are “how can the
product flow be optimized, and to what
extent are we delivering the goods/
services compared to the customers’
expectations, within the given limita-
tions of cost and capacity?”
There are multiple differences within the
execution area which have important
impact on the information needs. First of
all, this a larger number of people in this
area and they have more diverse roles.
All these people have varying needs for
information and they tend to change their
requirements rapidly over time. Also, the
time horizon is much shorter than in the
executive area, and the dynamics are
• What is the actual performance last month
and how does it compare to the budget?
(Sales, costs, production, etc.)
• What was the customer service level of
last month and how does it compare to the
target?
• How much product did we ship in tons/
hectoliters last month compared to plan?
• What are our year-to-date sales and how
do they compare to the same period last
year?
Some typical examples of executive
reporting (BI)
Executive/Higher Management processes have an Executive focus
Operational (Management) processes have an Executive focus
• focus on budget performance• LT Planning leads to hierachical budgets
Execution generates financial postings• top-down/bottom-up
Focused on Spending vers us Budget
• focus on Process performance• procurement to Pay, Make to Deliver, Order to Cash,
S& OP, End-to-End SC• End-to-End detailed process analytics
Focused on process goal fulfillment
Plan and Execute Observe and Respond
8
higher. In some functions, exceptional
situations arise daily that require special
procedures and unique information.
Many questions in the execution area
have an “ad hoc” character. When an op-
erational problem arises, the root cause
analyses as well as specific answers
are needed quickly. When that prob-
lem is solved, those specific questions
may never be needed again. This area
requires a lot of so-called “nitty-gritty”
detailed information, because within the
processes themselves, the devil is often
in the details. The operational level does
not just call for standard reports built on
a limited number of standard questions
that can properly be specified, thor-
oughly checked and run periodically for
several years. In operations, the need is
for a vast amount of reports that change
rapidly and, in addition, a continuous flow
of ad-hoc reports.
To make matters more challenging, the
operational level often requires highly
complex reports, involving flow-oriented
analytics which often run across multiple
departmental steps the workflow. Once
again, the word “integration” pops up.
What is the impact of a problem in one
step of a process on the next step? What
caused a bottleneck in a certain process
step? Purchasing processes can have a
direct impact on production processes,
which can have a direct impact on stor-
age levels which can have a direct impact
on customer delivery. Analytics that can
detect root-causes rapidly become much
more complex than those of traditional
performance statistics over historic time
frames.
• Which customer orders will not be deliv-
ered on time next week, what is the reason
and what can we do about it?
• Which purchase order lines are late and
which of them will cause a customer de-
livery problem for us? How much (%) of
the order lines do we need immediately in
order to control the damage?
• Which local small suppliers will be over-
loaded in the near future as a result of our
actual production plan? How can we off-
load these suppliers in time and capacity in
order to stabilize their delivery reliability?
Some typical examples of the ques-
tions answered via execution report-
ing (OBA):
Business intelligence (BI) systems: sys-
tems that transform data into meaningful
and useful information for business pur-
poses.
Traditional BI systems: BI systems provid-
ing cube-based, aggregated and mostly
historical information to the users. It offers
slice-and dice functionality over a limited
number of dimensions and values, and is
restricted by the design and technical lim-
itations of the system.
Operational BA systems: Systems offering
a maximum level of granularity, flexibility
and variety to business users. They are
enriched with business flow-oriented infor-
mation and predictive analytics, in a way
that enables business users to define their
own analytical reports without the support
from IT professionals.
“Within the
processes themselves
the devil is often
in the details.”.
9
2.6 Summary: Executive and Execution
The difference in focus implies that
Operational (Management) Processes
have completely different requirements
for “reporting’’ than Executive/higher
management processes, as the table
on below summarizes.
The table illustrates that, given the dy-
namics, variety and deep complexity of
chain-analytics, it is much more difficult
and costly to fulfill the information need
on the operational level than on the exec-
utive level.
Characteristic of the requirementsExecutive and Higher Management
processes
Operational Processes and Operational Man-
agement
Goal Accountability & Control Process optimization
General nature Condensed information related to time
buckets in the past
Detailed information about current and near future
Orientation • Vertical (top-down)
• Holistic and complete
• Horizontal (process)
• Exception-based (root-cause)
Dominant how-to Compare actual to budget Integrate data from multiple process steps
Level of Detail Low High
Number of users Low High
Need for ad-hoc Low High
Time orientation Past, long horizon Current and future, short horizon
Need for flexibility Low High
Expected changes in information need Low High
Performance indicators Orientation Process Performance Indicators
Available time and budget (IT) High Low (but.. hidden cost)
2.7 The Everyday Practice
Examining the architecture of IT sys-
tems, it is common to see ERP and oth-
er transaction systems covering each
of the needed transactional areas. It is
also common to find a data warehouse
(DW) as the aggregation layer for data
of all types.
This paper defines the important solu-
tion gap that exists between transac-
tion processing systems and business
intelligence. It is precisely the area that
Operational Reporting and Business Ana-
lytics supports and we call this layer Op-
erational Business Analytics (OBA). Most
corporate IT landscapes neglect this area
as shown in the diagram on the right.
It is often assumed that operational
information requirements are properly
covered by either transaction process-
ing systems or by their BI-systems; an
10
assumption heavily underestimating the
day-to-day needs of operations oriented
business users.
This difference in requirements is often
not understood or not recognized. IT pro-
fessionals sometimes attempt to solve
this problem with ‘’One BI’’, under the
argumentation: “once we have stored all
data in one big central database, we can
always answer the question from the end
users”.
Unfortunately, this is not the case, be-
cause the level of detail and the broad-
ness of the data required by people in
operational processes cannot be matched
with the requirements of BI. The complex-
ity is too high, the system performance
suffers and, at best, only one of the user
groups is properly serviced, usually upper
management.
Hence, business users on the operational
level, fill this gap by using spreadsheets,
local databases or any other form of “lo-
cally self-made business analytics.” That
is, of course, not the preferred situation
from the IT perspective in terms of se-
curity, stability, standardization, quality,
validity and scalability.
Once the data is stored in a spreadsheet,
it is difficult to maintain the security stan-
dards. Multiple departments will define
their own standards, each having their
own “version of the truth”. Since most of
these local solutions are not set up pro-
fessionally, maintainability is low, leading
to additional costs and risk. Besides that,
companies can become very dependent
on a few people who understand the
structure and use of these local systems.
It is evident that the mere existence of
these “spreadsheet forests” is proof that
there is a gap in the IT landscape that IT
department does not control. Filling this
gap with a professionally managed sys-
tem, that can sufficiently fulfill the users’
needs, will lead to better business perfor-
mance against lower cost.
SolutionGap
Business Intelligence
TransactionProcessingSystems
IT Systems
Analysis, Reporting & Control
Master Data & Transactions
Data
Information
Functionality
Requirements
Operational Proceses
Operational management
Business
Executive andHigher Management
Extract Transform
& Load
Business Intelligence (KPIs)
Business user self-service BI
• BW/ Business Objects• Quickview• Tableau
• reliability and security• maintainability? Availability?• single source of truth?• scalability? Hidden Cost?
Corporate Management (KPIs)
Operational Management (PPI)
• vertical, Control oriented• financial, strategic• stable KPIs – Dashboards• “cube-based”
• horizontal, process oriented• high detail and diversity• multi-dimensional• high change level
11
3. Different Reporting and Analytical Systems
3.1 Introduction: Business Processes, BI and Operational Business Analytics
In this section the concepts of the
“BI-system” (BI) and “Operational
Business Analytics system” (OBA) are
explained in more detail.
Both BI and OBA have to convert raw
data into information that answers ques-
tions from users. The characteristics of
BI differ a quite a bit from the character-
istics of OBA as a result of the difference
in requirements.
3.2 BI Systems
Over the past decade, a significant
amount of time and money has been
spent to build and maintain BI sys-
tems. In most cases, BI supports high-
er and executive management with
business planning and performance
measurement reports, with or without
dashboards. The characteristics of
these BI-systems are:
1. Limited number of dimensions and
values
The number of dimensions (product,
region, customer, and vendor) and val-
ues (revenue, gross margin, and cost)
means a maximum of a few dozen,
usually less
2. Primarily focused on historic figures,
preferably compared with budget
3. Limited level of end-user flexibility
The end user can choose from a cer-
tain set of reports, each of which has
a limited number of dimensions and
values. While a user can freely report
over these existing dimensions, he is
limited to them: if a dimension was
not defined in the report, it cannot be
added by the user.
Since these BI-systems are often used
for “accountability’’ as well as ‘’external
reporting’’ purposes, the definitions must
be formalized, solidly understood and the
systems must be robust and reliably built.
3.3 OBA Systems
Given the nature of OBA, the challenge
is to fulfill a large number of highly
complex, analytical report requests
while utilizing limited resources in
time and money. There are a variety of
users from different departments who
each have diverse needs. Users need
drill-down detail into multiple business
areas and push for it quickly. Often,
they change their mind in a few weeks,
requesting modifications to the report
or something completely new. On top
of that, there will probably be a lot of
ad-hoc questions or answers that busi-
ness users need urgently and might
never ask again.
Operational Business Analytics
(OBA)
CorporateBusiness
Intelligence
TransactionProcessingSystems
IT Systems
Analysis, Reporting & Control
Master Data & Transactions
Data
Information
Functionality
Requirements
Business
Executive andHigher Management
Execution
Operational management
Evaluate the Past Focus Actions
Act
Extract Transform
& Load
12
In such a dynamic environment, it is im-
possible to follow the steps necessary to
have an IT professional create the report.
There is limited time and budget and the
classic way of submitting an IT report
request and responding to it is no longer
effective. A faster and more flexible way
of working is needed, an environment is
needed that empowers end users with
self-service capability.
The requirements for an OBA system are:
1. High level of granular transparency (all
details are available for the end user)
2. Automatic and regular synchronization
with transaction systems
3. Expose the ‘’data’’ to users in ‘’busi-
ness language’’ to support business
user self-service
4. High level of flexibility for user to
change and create new analytics, as
well as variety of available reports
themselves, quickly and easily without
incurring high costs
5. Process flow-oriented information is
available for end-users and can be de-
rived rapidly.
Because of all this, it is impossible to
expect an IT department to design all the
necessary reports on request. The only
solution is to bring smart, specialized, fast
and flexible systems to business users that
enable these key users to create the nec-
essary reports themselves. Therefore, busi-
ness-user self-service becomes the fifth
most important characteristic of an OBA
system. Any organization needs BI as well
as OBA systems. All successful companies
have to organize their IT in such a way that
both the BI and the OBA-requirements are
fulfilled.The question now is: how to realize
an OBA-system? In the transaction pro-
cessing systems? As part of BI?
3.3.1 Why is it so difficult to realize
OBA within ERP?
It is clear that the data required for an
Operational BA-system often resides in
the ERP environment. However, ERP sys-
tems were never designed for reporting.
They were designed to cater for register-
ing business transactions in all kind of
different business events and scenarios.
This has led to a “data-structure’’ that
is capable of handling many business
scenarios, but is not understandable for
business users.
When flow-oriented information covering
multiple process steps (order, produc-
tion, stock management, delivery, in-
voicing, complaint management and pay-
ment) is involved, reporting and analytics
become especially complex. The ERP
system was simply not designed for this.
In addition, standard ERP-systems have a
lot of customizing parameters to ensure
that one standard software can be used
by many different companies without
changing the code. Some examples of
these parameters include fields in a data-
base which are sometimes a concatena-
tion of different fields and illogical for the
user. Relations between tables are some-
times in the application logic or found via
complicated “in-between-tables’’ some-
where in the design of sub-modules,
sometimes purely as a result of different
development teams that have worked on
the software. All of this leads to complex-
ity. There is complexity of the data-struc-
ture, complexity of the process logic and,
on top of that, complexity of the soft-
ware-technology itself. As a result, end
users are not capable of finding their way
through this complex data-structure. One
of the core-characteristics of an OBA
system is that it is dynamic, meaning that
requirements often change.
Constantly changing requirements are a
headache for an IT department and the
only good way to handle this is to provide
the business end-user with the tools for
ad-hoc reporting, which is the core of
business user self-service. Ad hoc re-
porting is a mismatch with the nature of
transaction processing systems.
3.3.2 Why is it so difficult to realize
OBA with traditional BI?
Modern BI-solutions offer great possibili-
ties to represent, slice, dice, and browse
through structured business information.
Data warehouses provide safe storage,
properly derived information and autho-
rized viewing of data in an aggregated
form (for example in the form of cubes).
As soon as the data is stored in aggre-
gated form, it is no longer suitable for
OBA. It will not meet the requirements
for granulation, variety, flow-orientation
and flexibility. Left alone the lack of func-
tionality to offer business users to create
their own reports and use advanced ana-
lytics over multiple business processes.
During the panel session vendors were
asked to estimate the failure rate of analytic
projects. They generally agreed that more
than 70% failed to meet expectations – but
since most organizations don’t put in place
explicit success criteria, it is hard to assess
what this means. In addition, failure rates
probably vary between different levels of
maturity – with simple descriptive analytics
being relatively successful.
Are Your Analytics Projects Failing?
13
4. How does a Solution Architecture with ERP, BI and OBA look?
4.1 The proposed solution architecture
In view of the different characteristics
of the three types of IT systems, the
following architecture could address
the business requirements in an opti-
mal way.
With the above architecture, both busi-
ness and IT benefit. IT departments keep
in control of their IT-landscape and lower
cost, by providing a manageable OBA
system. Operational business users ben-
efit because they have a system that not
only enables them to address the (chang-
ing) needs, it also provides them with the
day-to-day information to make better
decisions and improve performance.
A well implemented and well utilized
OBA system is the missing link in the IT
architecture. It is an important piece in
the realization of a “closed loop system”,
represented by the arrow circle in the
above figure. In a closed loop environ-
ment there is a direct link between the
KPI information on operational manage-
ment level and the information that is
used by (or presented to) the co-workers
at execution level. This direct link is man-
datory to turn strategy into action. The
actions at the execution level change the
current situation. This situation (the past)
is then analyzed and evaluated at opera-
(ERP-)
Transaction Pro-
cessing systems
Operational
Business Analytics
systems
Business Intelligence
systems
User Interaction Predefined trans-
action
Business User Self
Service with tools to
analyze follow-up ques-
tions viewing only
Dashboards with slice and
dice capability viewing
only
Level of detail All details and all
functionality
All details, but reduced
complexity and opti-
mized for Analytics
Aggregated in accordance
with predefined KPI,
dimensions and measure-
ments
Data store Persistent, create
and view
Not persistent, rebuild
on basis of ERP-data
Persistent
Extract Transform
& Load
Operational Business Analytics
(OBA)
CorporateBusiness
Intelligence
TransactionProcessingSystems
IT Systems
Master Data & Transactions
Information
Business
Executive andHigher Management
Execution
Operational managementEvaluate the Past Focus Actions
Act
Analysis, Reporting & Control
Data
Information
Information
14
tional management level, and predictive
analytic information is used to focus
the next actions to be carried out by the
execution level. This Act-Evaluate-Focus
cycle is carried out frequently to attain
the operational goals set by the higher
management levels.
4.2 Functionality OBA
4.2.1 A Business User Self Service Tool
The OBA system allows business end
users to analyze the current situation
and to create, publish and (regularly)
execute their own reports, which is true
self-service. They do not have to await
the outcome of an often lengthy software
development cycle and, as a result, have
the possibility to cope with the dynamics
and uncertainty of everyday life.
On reporting level, Transaction Process-
ing systems can give users hindsight, by
showing the results of what went wrong.
An OBA system however has to provide
insight, to give the people in daily oper-
ations the tools to improve their daily
performance. Insight comes from a com-
bination of diagnostic analytics (figuring
out why things happened) and predictive
analytics (figuring out what is going to
happen if no action is taken). Diagnostic
analytics, for example, can detect bottle-
necks and calculate payment reliabilities.
Predictive analytics can calculate items
such as excess stocks and expected
delivery reliability. Both these categories
are smart analytics to optimize the pro-
cesses for which they were designed.
Two examples of areas in which OBA
is very powerful are data reliability and
GRC (Governance Risk and Compliance).
These complex areas require a high level
of granular transparency of the data and
a professional way to manage a very high
number of changing “checks” that the
users want to perform on the data.
“A well implemented .
and well utilized .
OBA system .
is the missing link .
in the IT architecture.” .
Operational Business Analytics
(OBA)
TransactionProcessingSystems
Master Data & Transactions
Information
Business
Execution
Operational managementEvaluate the Past Focus Actions
ActData
Information
IT Systems
15
“A well implemented .
and well utilized .
OBA system .
is the missing link .
in the IT architecture.” .
4.2.2 A Feeder to BI-systems / dash-
boards
In order to make the OBA system suit-
able for business user self-service, the
data must be prepared and presented in
“business language” with as many pre-
defined calculations as possible. Exam-
ples of pre-defined calculations would be
service-level, Otif, stock valuation, order
status, etc.
To accomplish this, the OBA system must
have the built-in intelligence to trans-
form fields in the transactional database
in meaningfull business information by
executing complex calculations. Once
this is done, the OBA system has solved
an important problem that all BI systems
face: accessing fields from databases
and transforming them into information
which is useful for end users.
Therefore, the OBA system can be a
content provider or “data feeder” to BI
system which can store the data in a
time-series format and can compare
actuals with targets. As an example, the
OBA system can perform a daily calcula-
tion that transforms stock/cash balanc-
es into euro amounts and then posts to a
BI-system that keeps track of the trend.
With an OBA system, it is possible to
have a BI/Dashboard environment that
truly supports “rapid prototyping”. Ef-
fective rapid prototyping of dashboards
allows a power user, who does not need
to be an IT expert, deliver the answers
to business questions in seconds. This
power user, in an ideal setting, can sit
with a business expert, enter whatever
question they may have question in min-
utes and system will derive the answer in
seconds. This allows a business expert to
immediately verify that the question was
formulated correctly. If not, the power
user can filter out the unneeded data and
revise the question on the spot, showing
the results of the new out output again
for further refining.
As an additional benefit, the OBA-system
is also an excellent feeder of historical
usage data and inventory data which is
often needed for sales and Operations
planning software.
Operational Business Analytics (OBA)
CorporateBusiness
Intelligence
TransactionProcessingSystems
IT Systems
Master Data & Transactions
Information
Business
Executive andHigher Management
Execution
Operational managementEvaluate the Past Focus Actions
Act
Analysis, Reporting & Control
Data
Information
Information
BI Rapid Prototyping Lane
Ensures higher management oriented slicing and dicing within constraints of ‘Cube’
Provides‘out-of-the-box’ ERP system content for BI applications
16
5. Conclusion - What Business Value does OBA bring?
An OBA system is a software system,
which on its own, seldom improves
business value. Yet software systems
can indeed produce transparency and
insights that people need to take the
appropriate actions and these actions
generate business value.
In order to explain what the business
value of an OBA system can be, we make
a distinction between its direct value
and its derived value. The direct value
(or benefit) is the “improved operational
information’’ which people can use to do
their job better. The derived value is the
result of better actions/controls/deci-
sions that are based on the OBA insights,
materializing in improved business per-
formance.
As explained in the previous paragraph
OBA has to answer questions from many
different users, working in different de-
partments, asking questions for which
one has to combine information from
multiple business areas. This all takes
place in an environment requiring quick
answers to questions. Some examples of
“OBA questions” touching various busi-
ness areas at the same time:
Purchase to Pay:
In purchase and production it is very
useful to know, for example, which miss-
ing parts may jeopardize the production
progress, so that the issue can be solved
before it has a negative impact on pro-
duction.
To answer this question one has to:
a. analyze the master data of the pur-
chased item (e.g. standard lead time)
b. perform a thorough multi-level bill of
material analysis and
c. connect the purchase order to the pro-
duction orders.
The “direct value” is the list of missing
parts that may jeopardize the production
progress.
The “derived value” is the fact that the
production process isn’t jeopardized
when the focused appropriate actions
are taken.
Supply Chain Management:
In an ERP system, open sales orders
(sales orders still to be delivered) will
“claim stock” in the warehouse. The
amount of stock needed for the delivery
of the sales order is administratively
“set aside” to ensure the delivery. ERP
systems also tend to have a lot of old
open sales orders (for example sales or-
ders with an order due date that is more
than three months in the past). Partial
deliveries are one of the reasons to get
this. The customer orders 100 pieces,
the company delivers 98 pieces and the
remaining 2 pieces stay open for eternity.
That doesn’t seem to be too much of a
problem, but the ERP material require-
ment planning (MRP) algorithm shows
something different.
It will recognize this partly open sales
order as “still to be delivered” and re-
serves stock to deliver it, actually issu-
ing purchase or production orders for
new sales orders for the same material.
Thus, to reduce working capital in supply
chain management it is thus very useful
to know how much money is tied up in
“claimed stock”.
To answer this question one has to:
a. analyze the open sales orders to iden-
tify “polluted orders” (too old open
sales orders);
b. analyze the stock batches;
c. figure out the financial value of the
claimed stock.
The “direct value” is the list of old open
sales orders;
The “derived value” is the reduction of
stock when the reservation of stock is
lifted by cleaning up (closing) the pollut-
ed sales orders.
Expand these examples to all the opera-
tional issues that exist across the organi-
zation and there are thousands of possi-
ble use cases in which the use of an OBA
system can directly translate into finding
money hidden inside the ERP system.
17
Direct value Derived value
Operational Business Analytics direct value for Execution
Operational Business Analytics direct value for Operations Management
Direct Value and Derived Value of Operational Business Analytics
Support day-to-day Operational execution
Bottleneck detection & prioritization, detailed (ad-hoc) information
Support SAP ERP data Quality
Quality of Master data Quality of Transaction data
Support Operational Management & Control
Measure PPIs such as Service level, process accuracy, excess stocks, dead
stock reduction, output, data accuracy, etc.
Improved BusinessPerformance
Higher service level against lower cost, improved working
capital, improved cash flow, etc.
Every Angle Deutschland GmbH
Siemensstraße 31
47533 Kleve, Germany
Tel: +49 700 EVERYANGLE
r.pistorius@everyangle.com
www.everyangle.com
Every Angle USA
1727-8A Sardis Road
Suite 251
Charlotte NC 28270, USA
Tel: +1 704 905-0536
scottclifton@everyangleus.com
www.everyangle.com
www.everyangle.com
Every Angle The Netherlands (HQ)
Kampenringweg 45C
2803 PE Gouda, The Netherlands
Tel: +31 182 577 744
Fax: +31 182 577 740
info@everyangle.com
www.everyangle.com
Every Angle office at
SAP Netherlands
Partnerpoort 26
Amerikastraat 10
5232 BE s-Hertogenbosch
The Netherlands
Recommended