Original subtitles

Today, Business Intelligence is a recently well-understood term.

However, let's begin with the definition that's been sourced

from Gartner.

Now they define Business Intelligence as a broad category

of applications and technologies for gathering, storing,

analyzing, sharing, and providing access to data to help

enterprise users make better business decisions.

Now, I've worked in the industry for well over 15 years, and

I certainly wouldn't argue with that definition.

I may suggest that it could be put more simply,

and that is that it could be described as the application of

knowledge derived from analyzing the business' data

to effect a more positive outcome.

And arguably, this could be put more simply.

And so I'll land at this simple definition that is about

the transformation of your data assets into knowledge to support

the decisions that are being made by your business users.

Let's understand then how BI is used by the decision makers or

your users.

Typically like placing a finger on the pulse,

it's about understanding the health.

And when it comes to the health of a business,

you'll find that data is the blood of the business.

And therefore, we'll look to the data to help us understand

the whats and hows of what's going on.

What were the sales and how are they

in comparison to the goals and targets that we've set?

Next, the collaboration on a shared view of not just data but

also business logic.

And so I'll ask you to consider the scenario that you're in

a meeting with colleagues.

You are referring to last month's profitability and

you understand that you have different numbers.

And so you spend not so productive time in a meeting

determining who is correct and who is wrong.

Well, the reasons for this, and it's not so

uncommon today, is that the way that

the profit was being calculated was perhaps incorrect.

One was looking at a definition of gross profit, or

one was looking at the definition of net profit.

It could also be that the data sources, or

even the definition of time itself, was it a fiscal period,

was it a calendar period?

And so we often refer to the terminology or the objective

in business intelligence of a single version of the truth.

Now while I'll share with you that that's rather difficult

to achieve, we certainly strive towards.

In doing so, we eliminate or tempt to eliminate

the duplication of data and the duplication of business logic

and also the duplication of ethic.

Lastly, and increasingly important these days,

is the ability to reduce the time to decision.

Business users don't wanna learn today that

two weeks ago they were running low on an important ingredient

in the manufacturing process.

They need up-to-date data, even up to the second.

The goal then of business intelligence is often to

do things better.

And therefore, we should expect it to impact on the bottom line

by improving the way that we measure.

And it can also come down to enhancing competitive advantage.

Consider this, if your competitors are successfully

implementing business intelligence and

transforming their data into effective knowledge to support

good business decisions, then they indeed have a competitive

advantage over you if you're not achieving the same.

So I will stress, for some organizations today

they continue to consider that business intelligence is

an afterthought or a lower priority.

We would stress regardless of size of business, whether it's

small, medium or large, that business intelligence should be

considered an essential part of the IT portfolio.

Now as an experienced professional,

delivering business intelligence solutions,

I can attest to the fact that solutions encompass and require

an understanding to implement broad spectrums of technologies.

And in this training course,

we'll be exploring data warehousing and the ecosystem

that supports the delivery of the enterprise data warehouse.

Let's then consider the perspective from the business

users and the types of questions they ask and the challenges that

we may have in delivering responses to these questions.

The first is reasonably straight forward.

What sales have been made, and where?

With a sale system, we're likely able to group by,

filter summarized to answer this question.

When it comes to the second example here of

the salespeople's performance, it implies that there is some

target or goal to measure the salespeople activity against.

So there would be an expectation from my standing that

there would be planning systems with approved values

ensuring the ability to compare and

measure performance in future periods.

Next, which customers are likely to buy from us?

And so this isn't a query that you could easily write against

an operational system.

The customers that are likely to buy from us, it implies that

there are patterns and customers typically defined in terms of

their demographics like age, location, gender.

We would be able to detect patterns

if we could use technology to understand what has happened,

what have customers purchasing patterns been?

And therefore if these patterns can be revealed from data,

then it's likely that we could predict from those patterns,

with a reasonable degree of accuracy.

Which products do our customer buy together?

Here's another example that analyzing the relationships

between data, purchases, browsing.

And commonly used in online retail today that when I'm

browsing for a product, I like to see useful and

relevant suggestions to entice me to buy more.

What drives this?

Is it a simple query, or as is the case,

is a deeper process in place to deliver this question's answer?

Lastly, what is the customers sentiment of the new product?

So increasingly with social avenues,

people are liking things, people are commenting on things.

And now there's a need to aggregate data from a vast

variety and formats representing people's opinions and

thoughts and attitudes and somehow producing a response

that tells us what people feel about our new product.

Increasingly, as the questions become more complex,

it delivers more challenges for

us in delivering business intelligence.

So common challenges that we'll say up front,

typically, today involving volume, variety and velocity.

We have enormous systems collecting

enormous data at enormous rights.

And it's not all conveniently in relational stores that makes

my drive easier.

It could also be in file format.

It could also be in unstructured format.

It could also reside, not just conveniently on premises, but

it might also be in Cloud,

whether it's My Cloud Services or whether it's a software as

a service provider managing my data.

Now from a business user looking to answer questions

from the data, it may help be so straightforward, the volumes,

variety, and velocity aside.

How can this be easily queried?

If the data resides in a series of files,

how can a business user query that?

That's challenging even for me as an IT professional.

If it is conveniently in a relational store, which often

our operational data is, is it optimized for analytic queries?

And in this training course we will be talking about

optimization.

And it's important to understand that BI drives a different

workload against relational systems.

The workload typically works like this, that when I look at

a report that shows me products down the rows and the 12 months

of the year, and I see the sales that each product by month.

What isn't so easily understandable is it that there

could be billions of detail rows that were required to aggregated

to produce that simple matrix.

What that requires then is analytic queries that can filter

group by an aggregate.

Now while relational systems can do this,

the systems we employ to manage our sales,

so these operational systems, they're not optimized.

They're right intensive systems and yet this query

would best be delivered through a read intensive system.

While we can, it has negative impacts on performance for

both the requesting user.

But perhaps also for the operations of those inserting

orders into the system.

Next, we would consider do these systems contain the data we need

by design?

If someone comes to me looking for

a report that correlates temperature to sales,

that's a great question, and it's a valid question.

But if we don't collect data around temperature then we're

not in a position to answer that question.

The other consideration is history.

Operational systems for

their own optimization reasons like to archive regularly.

The smaller the sets of the data,

the more efficient they can do their job.

However, business intelligence loves history.

We love to see trends across time.

So, do these systems contain adequate volumes of data?

Next we can consider historical context and I love to use

the example of Jenny Jones, an employee at my company.

And Jenny, well she gets married and

she chooses to change her last name.

So, an update in the HR system overwrites her last name from

Jones to Smith and then I run historical reports to look

at her sales activities of last year.

Perhaps this isn't a problem when we see that Jenny Smith,

with the new name had sales activities last year because we

all know Jenny.

But let me provide you a twist that Jenny Smith relocates

between sales territories from Australia to New Zealand.

And by updating a simple flag against the employee, we have

shifted all of the historical sales to a new sales region.

And clearly this is an undesirable from a reporting and

analytics perspective.

Operational systems rarely give consideration to the historical

context of data.

Lastly, are these systems available or accessible?

So, numerous challenges.

And then to move on from data challenges to human challenges,

our business users ordinarily do not come from an IT department.

So they typically don't have sufficient skills, tools,

or even the permissions to access these systems.

Self-service business intelligence will be

a topic that comes up time to time.

And we will address that some users are empowered to produce

their own solutions, but others are reliant upon pre-delivered

reports or exploration experiences through data models.

Lastly and in reference to my example of the profitability and

the conflicts we had in a meeting,

systems may not have consistent definitions.

So quering across systems provides ambiguities and

inaccuracies.

Now, our decision makers then, have common requirements.

They need to be able to discover and find data.

It needs to reliable and secure.

They need flexibility.

And the way I like to describe this is that in organisations

today, it's typically a pyramid.

You can consider at the very apex you have your executives in

C level.

Now commonly, these individuals are driven by dashboards.

They wanna see numbers, colors, arrows,

trends, and where things are off track,

they would like to drill in and understand chords.

Now when we think of the same organization chart,

those at the lower levels typically process workers.

These also are people that have business requirements to

ask questions and use data to deliver their answers.

But what you'll find is that process workers typically have

repetitive and recurring questions and

as such fixed reports work very well for them.

Now what interests me is the level in between,

which are more like your analysts and power users, and

these people often work on ad hoc custom requirements.

And they might work with tools like Excel and

produce rather complex solutions.

And so what I'm demonstrating here is that different users all

having valid questions driven by data have the need for

flexibility in the way they access or

even create their own solutions.

Low latency has already been brought up.

Increasingly we want real time data and certainly decision

makers and business users need tools and training.

Where I'd like to finish up in this topic, then,

are to consider delivery scenarios.

Let's begin then with Operational Reporting.

I've already mentioned this,

that typically operational systems will have a library

of reports that drive the day-to-day operations.

For example,

in a sale system, we're likely to have an invoice report.

This is not such a bad thing, however, if these reports

become more complex or more demanding of resources.

For example, the need to aggregate billions of rows of

data to produce that simple metrics of products and

their sales across months.

Then these will impact negatively on the performance of

everybody's experience.

So we might consider moving up a notch and producing

a business intelligence delivery scenario around a particular

business process, maybe the budgeting process in finance.

Let's produce experiences,

reports and analytic solutions to drive that business process.

Moving up another notch, we have the Data Mart.

And by definition, this is the integration of potential

multiple stores to provide a subject specific area for

the support of analysis and reporting.

It could integrate, for example, a finance and GL in planning

system and, therefore, with an integrated set of data and

single version of the truth business logic.

The finance people have a place to go

to answer their questions from the data mart.

Now we arrive then, at the enterprise data warehouse,

which in fact is the focus of this training course and more

specifically, the implementation of relational data warehousing.

If you can imagine the overtime,

the accumulation of these data marks,

these subjects specific stores around HR, sales, finance.

And designed in such a way that they're integrated, and

they're conformed to work with consistent definitions like

time, product, employee.

What you're building then is the enterprise data warehouse to

support the integration and

access of critical information systems by business users.

And that very much sets the focus of this course, and

concludes this topic.