From Data to Decisions

BUS220 - Business Intelligence and Analytics | Week 1

Oleh Omelchenko

2026-03-11

Welcome to BUS220

Business Intelligence and Analytics

Kyiv School of Economics | Spring 2026

Oleh Omelchenko

o_omelchenko@kse.org.ua

Welcome everyone. I’m Oleh Omelchenko, Senior Product Analyst at MacPaw, 8 years in data analytics for web and mobile products.

This course is about turning your data skills into something businesses actually use. Most of you have taken data visualization and data manipulation courses. Here, we connect those skills to real business problems.

Let’s start with a question.

Before we start

A few questions for the room:

• What data courses have you taken so far?
• Have you worked with data outside of coursework?
• What do you expect to get from this course?

This is a quick pulse check — 3-4 minutes, not a full round.

Ask for a show of hands: “Who’s taken STAT163 (data manipulation)? STAT230 (data viz)? Both?” This tells you how much prerequisite knowledge to assume during the lecture.

Then open it up: “Has anyone worked with data in an internship or a personal project? What tools did you use?” You’ll likely hear Python, Excel, maybe Tableau. Acknowledge whatever comes up.

Finally: “What are you hoping to learn here? What would make this course worth your time?” Listen for themes — job skills, Tableau, dashboards, analytics. You’ll circle back to these expectations when you present the course structure.

Don’t spend more than 3-4 minutes here. The goal is to make students feel heard and to calibrate your delivery for the rest of the lecture.

What is a “dashboard”?

You see this word everywhere — Tableau, Google Analytics, job postings.

What is it, actually?

Not what tools you use to build one — what is it?

I want you to think about this for a moment. What is a dashboard? Not “a thing you build in Tableau” — what does the word actually mean?

[Take 2-3 answers. Students will likely say “a page with charts,” “a visual summary,” “an interactive report.” Don’t correct anyone — just collect the answers on the board or remember them. You’ll come back to these at the end.]

Good. Let’s hold onto those answers. I want to tell you where this word comes from.

The original dashboard

The answer starts about 150 years ago, before cars existed.

A board that catches the dash

A physical board at the front of a horse-drawn carriage.

Its job: protect the driver from mud kicked up by the horses.

“Dash” meant splash or spray. The dashboard caught it.

The original dashboard was a physical board at the front of a horse-drawn carriage. It had one job: protect the driver from mud and debris kicked up by the horses’ hooves. That’s it — a barrier, no information display at all. The word literally meant “a board that catches the dash,” where “dash” meant splash or spray.

So how did we get from a mud guard to Google Analytics?

From mud guard to instrument panel

When cars replaced horses, the board stayed — but the horses were gone.

The board was useless as a barrier. But it was right there in front of the driver.

So engineers started mounting instruments on it: speedometer, fuel gauge, temperature, oil pressure.

What matters is why those instruments ended up there. Nobody sat down and designed a “driver information system.” There was a flat surface in the driver’s line of sight, so engineers used it. Form followed proximity, not theory.

But over a century of iteration, car dashboards became very effective information displays. And the principles that emerged from that process are the same ones that make data dashboards work — or fail.

Let me show you what I mean.

What car dashboards teach us

Six design principles that transfer directly to data dashboards.

Each of these comes from how car dashboards work. And each one maps to a principle of good data dashboard design.

1. Glanceable, not studyable

A speedometer gives you the answer in under a second.

You don’t pull over to analyze your speed — you glance.

If you have to think about it, it’s a report, not a dashboard.

A speedometer gives you the answer in under a second. You don’t pull over to study your speed — you glance. A good data dashboard works the same way: the key numbers are immediately visible, not buried in a table you need to scroll through.

This word “glanceable” — I want you to remember it. We’ll come back to it when we start building dashboards in Week 4. It’s the single fastest test of whether a dashboard is well designed.

2. Context through reference marks

A fuel gauge doesn’t just show a number.

It shows a range from E to F, with color zones.

You know instantly whether the value is good or bad — without remembering what “37 liters” means for your tank.

Dashboards need the same: targets, benchmarks, color coding that tells you “normal” vs “needs attention.”

A fuel gauge is a brilliant piece of design. It doesn’t show you “37.2 liters” — it shows you a position on a scale with zones. You know instantly whether you need to stop for fuel.

Data dashboards need the same thing. A number like “$5.2M revenue” means nothing without context. Is that good? Bad? Compared to what? Reference lines, targets, year-over-year comparisons — these are the fuel gauge zones of a data dashboard.

3. Only the metrics that matter for driving

A car dashboard doesn’t show you engine compression ratios or transmission fluid viscosity.

While driving, you need speed, fuel, temperature, and maybe RPM. Everything else is noise.

The hard part of dashboard design isn’t adding information — it’s deciding what to leave out.

Engine compression ratios exist. They matter for maintenance. But while you’re driving, they’re irrelevant. You need speed, fuel, temperature, and maybe RPM. Everything else is noise.

This is the hardest lesson in dashboard design. Everyone wants to add “just one more metric.” But every metric you add competes for attention with everything else on the screen. The best dashboards are the ones where someone had the discipline to say “no, we don’t need that here.”

4. Consistent position, always available

Your speedometer is always in the same place. You don’t search for it.

A quick glance left: speed. A quick glance right: fuel. Muscle memory.

Users shouldn’t have to hunt for the number they check every morning.

You build muscle memory with a car dashboard. You don’t think about where to look — you just look. Dashboard layout should work the same way. If someone checks their sales numbers every morning, that number should always be in the same spot, in the same format.

Rearranging a dashboard is like moving the speedometer to the back seat. Even if you had a good reason, the driver will hate you for it.

5. Warnings interrupt, status stays quiet

The check engine light is invisible until something goes wrong.

The speedometer is always visible.

These are two different jobs:

• Ambient — always there, quietly (speedometer)
• Interruptive — hidden until it demands attention (warning light)

These are two different jobs. Some information should be ambient — always there, quietly. Some should be interruptive — hidden until it demands attention.

Mixing these up breaks the dashboard. If everything blinks orange, nothing stands out. If critical alerts are hidden in a tab the user never clicks, they don’t see the problem until it’s too late.

6. The driver is not the mechanic

The car dashboard is designed for the driver, not the engineer who built the engine.

A racing car’s dashboard looks nothing like a family sedan’s.

Different audiences need different dashboards — the analyst who builds it is not the manager who uses it.

The car dashboard hides the complexity. It doesn’t show you how the engine works — it shows you what you need to know to drive.

Business dashboards fail when they’re designed for the analyst who built them rather than the manager who needs to make a decision. Your Tableau workbook might have 47 calculated fields under the hood, but the person looking at the dashboard should see five numbers and know what to do.

Different audiences need different dashboards — just like a racing car’s dashboard looks nothing like a family sedan’s.

Dashboard or not?

Now that we have a definition — let’s test it.

We said dashboards are glanceable, contextual, selective, consistent, and audience-specific. Let’s look at things that people call “dashboards” but aren’t. Each of these is a legitimate format — the point isn’t that they’re worse, it’s that they’re different.

Infographic

Static, designed, tells one story. You read it once. A dashboard you check every morning.

An infographic is a designed, static visual that tells one story about a dataset. Often beautiful, often shared on social media. But it’s not interactive, it’s not updated, and it’s not meant for repeated use. You read it once and move on. A dashboard you check every morning — that’s a different relationship with the data.

Data story / scrollytelling

The author controls the sequence. A dashboard lets the user control the exploration.

A data story — like a New York Times interactive piece — walks the reader through a sequence of findings. It has a narrative arc. A dashboard doesn’t have a narrative arc. It answers whatever question the user brings to it right now.

The author of a data story controls the sequence. The user of a dashboard controls the exploration. Both are valid — but they’re different things.

Data art

Aesthetics and emotional response as the goal, not decisions.

Wind maps, Dear Data postcards, Spotify Wrapped — data as medium, not as decision tool.

Data art uses data as a medium. Dear Data postcards, wind maps, Spotify Wrapped — they’re beautiful, they create emotional responses, but nobody makes a business decision from them.

Nothing wrong with data art. It’s just a different thing from a dashboard. The problem is when the word “dashboard” gets applied to all of these, and nobody knows what anyone means anymore.

From dashboards to BI

So when you said “a page with charts” — you weren’t wrong about what most dashboards are.

But a dashboard that works requires work that happens long before you open Tableau:

• Choosing what to measure
• Cleaning the data
• Understanding the audience

That’s what this course covers — the full pipeline from data to decision.

So when you said “a page with charts” — you described what most dashboards look like. But a dashboard that actually works requires work that happens long before you open Tableau: choosing what to measure, cleaning the data, understanding who’s going to use it.

The dashboard is just where the audience sees the result. This course covers everything underneath. Let me show you the full picture.

Where this course fits

You’ve already taken courses on data manipulation and data visualization. Where does business intelligence fit in relation to those?

The data analysis pipeline

Seven stages from raw data to a decision:

#	Stage	Guiding question
1	Data acquisition & storage	Where does the data come from?
2	Data cleaning & transformation	Is the data correct and structured?
3	Exploratory analysis	What patterns exist?
4	Metric design & calculation	What should we measure and why?
5	Visualization	How do we show it effectively?
6	Dashboard assembly	How do we make it interactive?
7	Communication & decision support	What does this mean for the audience?

This is the full pipeline from raw data to a decision. Each stage has a guiding question. Notice that it starts with data — not with a chart, not with Tableau — and it ends with communication, not with a dashboard. The dashboard is stage 6. Stage 7 is making sure someone actually understands and acts on it.

Your prerequisite courses covered parts of this pipeline. Let me show you which parts.

Three courses, three focal points

	Data Manipulation (STAT163)	Data Visualization (STAT230)	Business Intelligence (BUS220 — this course)
Acquisition
Cleaning
Exploratory
Metric design
Visualization
Dashboards
Communication

“Can I get the data
into shape?”

“Can I show this
clearly?”

“Can someone make
a decision from this?”

Data Manipulation focused on stages 1 through 3 — getting data into shape. DataFrames, dtypes, merging, reshaping, handling missing values. Visualization showed up as a way to check your work, not as the end product.

Data Visualization focused on stage 5 — choosing the right chart, encoding data visually, perception principles. The data was usually pre-cleaned for you.

This course focuses on stages 4, 6, and 7 — the parts your other courses touched lightly. Choosing the right metrics, assembling multiple views into one interactive tool, making it actionable for a specific audience. We still clean data — you always do — but the main focus is metric design, dashboard assembly, and communication.

The question that defines this course

Data manipulation: “Can I get the data into shape?”

Data visualization: “Can I show this clearly?”

Business intelligence:

“Can someone make a decision from this?”

This is the question I want you to carry through the entire course. Every assignment, every practice session, every group project — ask yourself: can someone make a decision from this?

That question is harder than it sounds. It forces you to think about the audience, the business context, which metrics actually matter, and whether a non-technical person can explore the data without breaking it.

What we won’t cover

• Building data pipelines or ETL code — that’s data engineering
• Machine learning or predictive modeling — that’s data science
• Deep statistical inference — that’s statistics
• Production software — that’s software engineering

We sit in the space between “the data is ready” and “the decision is made.”

I want to be honest about the boundaries of this course. We’re not going to make you data engineers, ML specialists, or statisticians. Those are different jobs with different skill sets.

We sit in the space between “the data is ready” and “the decision is made.” That space is where most business analysts and BI professionals spend their time.

Course mechanics

Let me walk through the practical details. I’ll keep this concise — the full syllabus is on Moodle.

The 8-week arc

Weeks	Focus	Pipeline stage
1–2	Spreadsheet fundamentals and advanced features	Data prep & exploratory analysis
3	Data cleaning with Syto, Tableau connections	Data prep → Visualization
4–5	Metrics, KPIs, calculated fields, LOD expressions	Metric design
6–7	Interactivity, parameters, design polish	Dashboard assembly
8	Group project presentations	Communication

The course follows the pipeline roughly in order. Weeks 1-2 are spreadsheets — and before you think that’s too basic, I’ll explain why in a moment. Week 3 is the bridge: we clean data with Syto and connect it to Tableau. Weeks 4-5 are the analytical core — metrics, KPIs, and the calculations that power them. Weeks 6-7 are about craft — making dashboards interactive, polished, and “glanceable.” Week 8 is group project presentations.

Grading

Component	Points	Details
Lecture quizzes	12	6 quizzes × 2 pts (Weeks 2–7)
Practice submissions	14	7 weeks × 2 pts, completion-based
Individual assignments	50	5 × 10 pts (8 technical + 2 documentation)
Group project	35	Dashboard + documentation + presentation
Total	111	Capped at 100

Late policy: 1–7 days = 50% credit, >7 days = not accepted.

The total is 111 points, capped at 100. That gives you a buffer — you don’t need to ace everything.

Notice that assignments have a documentation component worth 2 points each. You’re expected to explain your analytical choices, not just produce charts. This mirrors real analyst work where you need to justify your approach.

Practice submissions are completion-based — 2 points for satisfactory work. You have 3 days after the practice session to submit.

Quizzes start in Week 2 and cover the previous week’s material. The quiz in Week 2 covers what we learn this week and the readings you were assigned.

Why these tools?

Weeks	Tool	Why
1–2	Google Sheets	Most-used analyst tool, teaches patterns that transfer everywhere
3+	Syto	Visual, step-by-step data cleaning in the browser — no install needed
3+	Tableau Public	Industry standard for BI visualization, free, builds on STAT230

Three tools, all free.

Why spreadsheets first? Because they’re the tool you’ll use most often in your first analyst job. Not Python, not Tableau — spreadsheets. Quick ad-hoc questions, data validation before loading into a pipeline, sharing a calculation with a non-technical colleague. We’re not going to cover “how to use Excel.” We’ll focus on analytical patterns: pivot tables, lookup functions, conditional formatting, structured reports. If spreadsheets feel too basic for you, focus on the analytical reports part — structuring a spreadsheet so someone else can read and trust it. That’s harder than it sounds.

Why Syto instead of Python/pandas? You already know pandas. But in BI work, data cleaning often needs to be transparent to people who don’t read code. Syto is a browser-based wrangling tool where you build cleaning pipelines step by step — filter, rename, derive columns, join — and each step is visible and inspectable. Think of it as a lightweight Power Query that runs in your browser.

Why Tableau? Industry standard, shows up in more job postings than any other BI tool, and the concepts transfer. Once you understand calculated fields, LOD expressions, and dashboard actions in Tableau, picking up Power BI or Looker Studio takes days, not weeks.

AI tools policy

Encouraged:

• Using AI to learn concepts and debug formulas
• Generating example code snippets
• Clarifying complex topics

Required: Document all AI usage in assignments

Not accepted: Submitting AI-generated work as your own understanding

I may ask you to explain any part of your submission.

AI tools are encouraged for learning. Ask them to explain concepts, help you debug, generate examples. But you must document any AI usage in your assignments, and you need to understand what you submit. I may ask you to explain any part of your work — if you can’t, that’s an academic integrity issue.

Data quality

We said this course focuses on stages 4 through 7 — metric design through communication. But there’s a stage you can never skip, no matter which course you’re in: cleaning. Let me show you why.

What dirty data costs

A dataset has duplicate entries for 8% of customer orders.

Your revenue dashboard shows $5.4M instead of the actual $5.0M.

The marketing team allocates budget based on your numbers.

The dashboard was well designed, the charts were clear, the filters worked — and the decision was still wrong.

This is a realistic scenario. Duplicate records are one of the most common data quality issues, and they directly inflate aggregated metrics. If someone makes a budget decision based on inflated revenue, that’s a real business cost.

The problem wasn’t the visualization. It was the data underneath. This is why we spend Weeks 1 and 2 on spreadsheet fundamentals including cleaning, and why Week 3 introduces Syto for more structured data wrangling.

The cleaning workflow

Inspect — look at the structure, types, and shape of your data

Identify — find missing values, duplicates, inconsistencies, outliers

Fix — standardize formats, remove duplicates, handle missing data

Validate — check that your fixes didn’t introduce new problems

Same four steps whether you’re in a spreadsheet, Syto, or Tableau’s data source pane.

This four-step workflow applies regardless of the tool. Whether you’re in Google Sheets, Syto, or Tableau’s data preparation layer, the process is the same: look at the data, find the problems, fix them, and verify your fixes.

You’ll use this pattern in every week of the course. Data cleaning isn’t a one-time step — you’ll often discover new issues as you build your analysis.

Tidy data: one rule

Tidy (good)

Date	Product	Revenue
Jan	A	100
Jan	B	200
Feb	A	150
Feb	B	180

Messy (common)

Product	Jan	Feb
A	100	150
B	200	180

Each variable is a column, each observation is a row, each cell holds one value.

The tidy data principle: each variable gets its own column, each observation gets its own row, each cell holds exactly one value.

The messy version on the right looks cleaner to a human eye — and for a quick report, it might be fine. But try to filter by month, or add March data, or connect it to Tableau — and you’ll have problems. Tidy data is machine-friendly, which means it works with every tool we’ll use in this course.

You’ve reshaped data from wide to long format before in your data manipulation course — same concept, different tool.

Spot the problems

Student Name	Course	Grade	Date
Ivanova, Maria	BUS220	92	2025-09-15
ivanova maria	bus220	A	15/09/2025
Petrov, Oleksandr	BUS220	85	2025-09-15
Petrov, Oleksandr	BUS220	85	2025-09-15
	BUS310	78	Sept 15
Koval, Daryna	BUS220	ninety	2025-09-15

How many issues can you find? Take 30 seconds.

Take 30 seconds — how many data quality issues can you spot? Talk to your neighbor if you’d like.

[Wait 30 seconds, then collect answers]

Here’s what I see: inconsistent name formatting (comma-separated vs space, different capitalization), mixed grade types (numeric vs letter vs text), inconsistent date formats across rows, a duplicate row for Petrov, a missing name in row 5, and “ninety” written as text instead of a number. That’s at least six issues in six rows.

This is a small example, but imagine this at scale — 100,000 rows with similar problems. That’s what real data looks like, and that’s why data cleaning takes most of an analyst’s time.

What’s ahead

Let me preview what’s coming this week and next.

This week’s practice sessions

Practice 1 — Spreadsheet formulas

• Cell references (absolute vs relative)
• Basic functions: SUM, AVERAGE, IF, COUNTIF

Practice 2 — Data cleaning in spreadsheets

• Sorting, filtering, removing duplicates
• Text functions for standardization
• Data validation rules

Submission due within 3 days of the practice session.

Practice 1 covers the formula fundamentals — if you’re comfortable with spreadsheets, this will be a refresher that lets you help classmates. Practice 2 gets into cleaning techniques, which is where the real analytical work begins.

Submit your work within 3 days of the session. It’s graded on satisfactory completion — I’m not looking for perfection, I’m looking for evidence that you engaged with the material.

Next week

Advanced Spreadsheets — pivot tables, VLOOKUP, INDEX/MATCH, conditional formatting, analytical reports.

Required reading before next lecture:

• SWD Ch1 — The Importance of Context (audience, the Big Idea)
• SWD Ch2 — Choosing an Effective Visual (tables, graphs, what to avoid)

Week 2 starts with Quiz 1 covering this week’s material and readings.

Next week we move from data fundamentals to analytical reporting. Pivot tables are one of the most powerful features in spreadsheets — they let you summarize and cross-tabulate data without writing code.

The Storytelling with Data readings are about thinking before building. Before you create a chart or a report, ask: who is my audience? What do they need to know? What action should they take?

The quiz in Week 2 will cover today’s content and the CwD chapters you read for this week. It’s short.

Summary

We started with a question: what is a dashboard?

A dashboard is just the surface — the last step.

This course covers everything underneath:

cleaning data, choosing metrics, designing for a specific audience.

By Week 8, you’ll present a dashboard that someone could actually use to make a decision.

Office hours: Wednesday 16:00–18:00 | Slack

We started today with a question about dashboards, and you said [reference student answers]. A dashboard is just the surface — the last step. Over the next 8 weeks we’ll work through everything underneath: cleaning data, choosing metrics, designing for a specific audience.

By Week 8, you’ll present a dashboard that someone could actually use to make a decision. That’s the test for this whole course: can someone make a decision from this?

My office hours are Wednesdays 4 to 6 PM, and I’m on Slack during business hours. See you in practice!