Data Mining · Business Analysis Notes

What it is#

The BABOK Guide uses “data mining” as an umbrella for three kinds of analysis:

Descriptive — grouping data, for example by clustering, to see similarities and differences: what patterns are there?
Diagnostic — techniques such as decision trees or segmentation that show why a pattern exists.
Predictive — techniques such as regression or neural networks that estimate how likely something is to be true in the future.

The BABOK Guide frames the work as a sequence: elicit the requirements for the analysis, prepare the data (an analytical data set), analyze it, apply modeling techniques, and deploy the results.

You do not need to be a data scientist to use this technique. Your job as a business analyst is usually to frame the question, find and assess the data, work with specialists on the analysis, interpret the results with stakeholders, and make sure the findings are built into a process or decision.

The BABOK Guide lists it in Prepare for Elicitation, Conduct Elicitation, Analyze Current State and all five Solution Evaluation tasks, from Measure Solution Performance to Recommend Actions to Increase Solution Value.

When to use it#

Use data mining when:

you have a large volume of reasonably reliable historical data;
a decision repeats often enough that better predictions pay off;
simple reports and metrics have stopped answering the question;
you want facts to challenge assumptions or reduce bias in a discussion.

Do not use it when a query or a report would answer the question, when the data is thin or of poor quality, or when there is no clear decision that will use the result. The BABOK Guide also warns that results are hard to deploy if the target solution is unclear, that many techniques need specialist skills, and that stakeholders may resist results they see as opaque or mathematically obscure.

How to do it#

Start from the decision. Write down which decision the analysis will inform and what you would do differently depending on the answer.
Define success. Agree how accurate a result must be to be useful, and how you will measure business impact afterwards.
Find and assess the data. List sources, time period, coverage and known quality issues. Check privacy and legal constraints before you copy anything.
Prepare the analytical data set. Usually one row per case (a booking, a customer, a part), with cleaned fields and derived features. Set aside part of the data for testing.
Explore descriptively. Look at distributions and groupings with stakeholders before building any model.
Model. Apply diagnostic or predictive techniques. Always compare against a simple baseline, such as “assume next month equals last month”.
Validate. Test on the data you set aside. Ask domain experts whether the patterns make sense, and look for correlations that have no plausible cause.
Deploy. Turn the result into something people or systems use: a decision rule, a score in a screen, a revised process.
Monitor. Track whether the model still performs and whether the business outcome improved; retrain or retire it when it drifts.

Example#

The Workshop, a fictional chain of bike-repair workshops, loses mechanic time to customers who book and do not show up. The owner asks whether online booking will make this worse.

Question and decision: “Which bookings are likely to be no-shows, so front-desk staff can send an extra reminder or ask for a deposit?”
Data: two years of bookings from the current spreadsheet: lead time, day of week, bike type, channel, whether a reminder was sent, and outcome.
Descriptive: the team groups bookings by lead time and channel to see where no-shows concentrate.
Diagnostic: a decision tree is built to show which combinations of factors separate shows from no-shows. Suppose it points to long lead times without a reminder; the team checks this with workshop managers before believing it.
Predictive: a simple model scores each new booking’s no-show risk.
Deployment: high-risk bookings trigger a second reminder; the deposit rule is captured in a decision table so it can be reviewed and changed.
Monitoring: the no-show rate per workshop becomes a KPI reviewed monthly.

All of this is illustrative; the point is the chain from question to decision to measurement.

Common mistakes#

Starting with the data instead of a question → agree the decision first; otherwise you will find patterns nobody can use.
Treating correlation as cause → ask for a plausible mechanism and test it before acting.
Using information not available at decision time (for example, a “cancelled by phone” flag when predicting no-shows at booking) → build features only from data known when the decision is made.
Testing on the same data used to build the model → keep a separate test set.
Ignoring data quality → profile the data first; see data quality dimensions.
Handing over a black box → explain the model in business terms; unexplained results get ignored.
No deployment or monitoring plan → decide upfront where results will live and who watches them.

Checklist#

The business question and the decision it informs are written down.
Success criteria and a baseline are agreed.
Data sources, period and quality issues are documented.
Privacy and legal constraints are checked.
Results are validated on held-back data and by domain experts.
There is a deployment plan: a rule, process or system change.
Someone owns monitoring after go-live.

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.14 “Data Mining”.
Watermark Learning. BABOK v3 Study Tables. 2016 (study aid for the BABOK Guide), technique 10.14.