Whitepaper Operational Business Analytics

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


IT Systems



Data

Information

Functionality

Requirements

Operational Proceses


Business


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.


(OBA)

CorporateBusiness

Intelligence


IT Systems



Data

Information

Functionality

Requirements

Business


Execution


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


(OBA)

CorporateBusiness

Intelligence


IT Systems


Information

Business


Execution

Operational managementEvaluate the Past Focus Actions

Act


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.” .


(OBA)



Information

Business

Execution


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


IT Systems


Information

Business


Execution


Act


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

[email protected]

www.everyangle.com

Every Angle USA

1727-8A Sardis Road

Suite 251

Charlotte NC 28270, USA

Tel: +1 704 905-0536

[email protected]

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

[email protected]

www.everyangle.com

Every Angle office at

SAP Netherlands

Partnerpoort 26

Amerikastraat 10

5232 BE s-Hertogenbosch

The Netherlands

Documents

Whitepaper Operational Business Analytics