Data is now central to almost every BA engagement — yet most BA training treats it as someone else’s problem. You do not need to become a data scientist. You do need to read a dashboard critically, brief a data team effectively, challenge data quality before it becomes a project risk, and interpret AI outputs for business stakeholders. These skills distinguish you in any ANZ organisation.
BI Dashboard Critique
Data Team Briefs
Data Quality 6 Dimensions
Data Governance
AI/ML Outputs & Explainability
What decision does this enable?
Every dashboard should support a specific decision. If you cannot name it, the dashboard is reporting activity rather than enabling action.
What is missing?
Dashboards show what builders chose to show. A sales dashboard showing revenue without returns tells an incomplete story.
What is the data freshness?
When was this data last updated? “Current” stock levels that refresh daily are not current in any operational sense.
Who is the audience?
An operations manager’s dashboard ≠ a CEO’s dashboard. Audience determines appropriate granularity and required context.
What assumptions are baked in?
Every visualisation embeds assumptions: baseline time period, segment definitions, what constitutes a conversion or failure.
⚠ Cherry-picked metrics
Only KPIs that look good
⚠ Misleading axes
Y-axis not starting at zero
⚠ No baseline comparison
“Sales are up” — compared to what?
⚠ Vanity metrics
High volume numbers disconnected from outcomes
4 Questions to Answer Before Going to the Data Team
What decision are we making?
“We are deciding whether to expand the Wellington service to Christchurch in Q3.”
What grain of data do we need?
One row per customer? Per transaction? Per day per product? Wrong grain = wrong analysis.
What time period?
“Recent data” is not a specification. Name start and end dates, rolling vs fixed snapshot.
What format is the output?
CSV? Dashboard? API? This drives infrastructure and delivery effort.
▶ Scope Creep
“While you’re at it…” needs the same 4-question treatment. No exceptions.
▶ Undefined Business Terms
“Active customer” means different things to marketing, finance, and operations. Define before you request.
▶ Urgency Without Priority
When everything is urgent, nothing is. Establish clear priority ranking with the data team.
▶ Assuming Data Exists
Always confirm data availability before committing to a data-dependent requirement.
Completeness
Are all required fields populated?
Accuracy
Does the data reflect the real-world entity it represents?
Consistency
Same entity represented the same way across different systems?
Timeliness
Available when the business process needs it?
Validity
Conforms to defined formats, ranges, and business rules?
Uniqueness
Each entity represented once and only once?
BA accountability: More projects fail because of poor data quality than because of poor requirements — yet data quality rarely appears on risk registers until something has already gone wrong. If data quality is not specified as a requirement, it will not be built, tested, or measured. That absence is a BA failure, not a technical one.
Data governance governs what you can do with data in your projects, who has authority to make data-related decisions, and what the consequences are when you get it wrong. For ANZ BAs in financial services, health, or government — this is a live constraint on every requirement you write.
Data Owner
Business executive accountable for quality, access, and appropriate use of a data set
Data Steward
Operational practitioner responsible for day-to-day data quality and definitions
Data Dictionary
Formal catalogue of data elements: names, definitions, formats, allowable values
Master Data
Core reference data defining the entities the organisation does business with
Data Lineage
Documented history of where data comes from, how it was transformed, where it goes
Who is the data owner for each data set this project will access or modify?
Is there a data dictionary for the relevant data entities?
What are the data retention and purge rules?
Are there privacy or security classifications restricting access?
Does this project involve personal information under the Privacy Act 2020 (NZ) or Australian Privacy Act 1988?
Are there cross-border data transfer implications?
AI and ML are embedded in the systems ANZ organisations build every day — credit scoring, fraud detection, document classification, demand forecasting, churn prediction. You do not need to understand the mathematics. You need to understand enough to ask the right questions and write useful requirements.
The single most important thing for a BA to internalise: AI outputs are not answers. They are predictions with a probability attached. A machine learning system learns patterns from historical data and uses them to make predictions about new data — it does not know with certainty.
Confidence Scores
“78% likelihood of churning.” Your requirements must specify what the business does at different thresholds: automated action vs human review.
False Positives
Model predicts event that doesn’t occur. In fraud: legitimate transaction flagged. Business cost: customer friction, manual review, reputational damage.
False Negatives
Model fails to predict event that does occur. In fraud: fraudulent transaction let through. Often a more severe business cost. The acceptable trade-off is a business decision, not a technical one.
Explainability Requirement — ANZ Regulatory Context
The FMA (NZ) and ASIC (AU) require organisations to explain AI-driven decisions affecting consumers — credit decisions, insurance pricing, benefits assessments. As a BA on any AI system that influences decisions about individuals, you must include an explainability requirement:
✎ Practice: AI Acceptance Criteria — NZ Loan Scoring System
Thresholds for auto-approve, auto-decline, and human review (e.g. score ≥ 750 = auto-approve; 500–749 = human review; < 500 = auto-decline)
Acceptable false positive rate: auto-declined applications where the customer would have repaid
Acceptable false negative rate: auto-approved applications that default within 12 months
Explainability requirement: for all declined applicants, the system must generate a plain-language explanation of the top 3 contributing factors
Ongoing model performance monitoring: accuracy and demographic parity reviewed monthly by the data science team
Data literacy is now a core BA competency — not an optional technical add-on. If you don’t challenge data quality, no-one else will.
Every dashboard request should begin with: What decision does this enable? Missing that question is the most common cause of unused analytics investment.
Brief the data team with the 4-question framework: decision, grain, time period, output format. Vague requests produce delayed, wrong results.
Data quality has 6 measurable dimensions (completeness, accuracy, consistency, timeliness, validity, uniqueness) — specify them in your acceptance criteria, not after UAT.
AI outputs are probabilistic, not deterministic. False positive and false negative rates are business requirements, not technical configuration — a BA must elicit and document them.
FMA (NZ) and ASIC (AU) require explainability for AI-driven consumer decisions. If your system influences a decision about an individual, you need an explainability requirement.
Ready to go further?
Go from foundational knowledge to a globally-recognised BA certification. 6 weeks, 100% online, built around a real-world case study — not just theory.
One-time payment. Instant access. 14-day money-back guarantee.
Ready for the full qualification? CBBA Certification — $349 NZD · 6 weeks · 30-day money-back
Enrol in CBBA →