Current State Analysis for Analytics
Key Takeaways
- Current-state analysis (CBDA 1.1.3) documents how the organization works today: environment, processes, decisions, and data already available—not a premature deep dive into raw tables.
- Analyze people, process, technology, and data as four linked dimensions so gaps in skills, workflow, systems, and information quality surface together.
- Baseline metrics and decision pain points explain why the situation hurts now and give a measured starting line for future-state success criteria.
- Current-state findings feed research questions by revealing what is unknown, contested, or unmeasured in today's decision process.
- Major trap: analyzing data before understanding how decisions are made today—beautiful charts that no decision maker uses.
Current State Analysis for Analytics
Quick Answer: After framing the business situation, analyze the current state: how decisions are made today, which processes and people are involved, what technology supports them, and what data already exists. Document baseline metrics and decision pain points so research questions target real uncertainty—not abstract data exploration.
Competency 1.1.3 expects CBDA practitioners to analyze the current state to understand the existing environment. In business data analytics, "current state" is broader than a system inventory. It is a structured view of how value is created (or lost) today and how information supports—or fails to support—decisions related to the framed situation.
Why Current State Comes Before Heavy Analysis
Teams often open SQL workbenches the day a project is approved. That habit creates three predictable failures:
- Orphan insights — findings that never map to a decision owner or process step.
- Wrong grain or wrong population — metrics that look precise but do not match how the business actually manages performance.
- Duplicated work — reinventing reports or models that already exist in a corner of the organization.
Current-state analysis prevents those failures by answering: Who decides what today, with which information, under which constraints, and with what pain? Only then do you know which data to source and which questions matter.
The Four Dimensions: People, Process, Technology, Data
Use all four dimensions on every analytics initiative. Gaps often hide at the intersections (for example, good data exists but the process never uses it).
| Dimension | What to examine | Example questions |
|---|---|---|
| People | Roles, skills, incentives, decision rights, culture toward data | Who approves price changes? Do managers trust the weekly forecast? Are analysts embedded or centralized? |
| Process | End-to-end workflow, handoffs, SLAs, exception paths | When is the forecast locked? What happens when a claim is disputed? Where do delays accumulate? |
| Technology | Systems of record, integration points, BI tools, automation | Which CRM is authoritative for customer status? Are warehouse and e-commerce stock figures reconciled? |
| Data | Sources, definitions, quality, latency, access, lineage | What is "active customer"? How fresh is inventory? Who can access PHI or payment data? |
People
Map decision rights (RACI-style is fine) for the situation you framed. Note skill gaps: a retail chain may have excellent transactional data but no one trained to interpret propensity scores. Capture cultural signals—leaders who only trust gut feel, or teams punished for bad news—because they shape whether analytics results will be used later (Domain 5).
Process
Document the decision cycle: trigger → information gathered → criteria used → decision → action → feedback. If there is no feedback loop (outcomes never measured), that is a current-state finding that will influence KPIs and research design. Process maps for analytics projects should highlight where judgment currently replaces evidence.
Technology
List systems that create, store, or present data relevant to the situation. Focus on authoritative sources and known breakage (nightly batch failures, dual CRM instances, spreadsheet shadow IT). Technology current state is not a full enterprise architecture review; it is enough architecture to know what is feasible for this initiative.
Data
Describe what is already collected, at what grain and latency, with what known quality issues. Include definitions and metric ownership. You are not yet cleaning data or sampling for models (those are Domain 2 skills); you are establishing the information landscape that will later support research questions.
Documenting Baseline Metrics and Decision Pain Points
Baseline metrics
A baseline is the measured starting performance for outcomes and process indicators tied to the framed situation. Baselines enable honest future-state targets and prevent "success theater."
Good baseline practice:
- Use definitions stakeholders already manage to, then note inconsistencies.
- Capture time window, population, and source (e.g., "Q1–Q2 online orders, excluding wholesale, from order management system").
- Prefer a short set of decision-relevant metrics over a kitchen-sink dashboard dump.
- Record confidence in each baseline (audited metric vs. one analyst's spreadsheet).
| Baseline element | Weak example | Strong example |
|---|---|---|
| Metric | "Sales are down" | "Online conversion rate for mobile new customers: 1.8% in last 12 weeks (web analytics + order system join)" |
| Population | "All customers" | "US retail loyalty members with ≥1 purchase in 24 months" |
| Process metric | "Ops is slow" | "Median claim cycle time 14.2 days; 90th percentile 31 days" |
| Decision metric | "Forecast feels wrong" | "MAPE of 4-week demand forecast = 28% at SKU-store grain" |
Decision pain points
Pain points describe friction in how decisions are made, not only bad outcome numbers. Common analytics-relevant pain points include:
- Latency — the answer arrives after the decision window closes.
- Inconsistency — two teams report different "truths" for the same KPI.
- Opacity — leaders cannot explain drivers of a change.
- Manual burden — high-effort assembly crowds out analysis.
- Actionability — reports show what happened but not who should do what.
- Trust gaps — decision makers ignore official numbers and use private spreadsheets.
Document pain points with evidence (interview quotes, sample conflicting reports, time-motion on report assembly). On the exam, the better answer often addresses a decision process pain, not only a data quality defect.
How Current-State Findings Feed Research Questions
Current-state analysis produces candidates for research questions, not the final wording (that is refined in later Domain 1 sections). Translate findings like this:
| Current-state finding | Research-question seed |
|---|---|
| Two definitions of "churn" used by finance and product | Which churn definition best predicts 90-day revenue loss for intervention design? |
| Managers override the forecast every week without logging reasons | What patterns distinguish overrides that improve accuracy from those that worsen it? |
| Readmission outreach capacity covers only 15% of discharged patients | Which patient attributes most strongly associate with preventable 30-day readmission among patients eligible for outreach? |
| Campaign ROI reports exclude returns and cannibalization | What is the incremental net revenue of campaign X after returns and category cannibalization? |
| Inventory system and e-commerce site disagree 8% of the time on availability | Where do availability mismatches concentrate, and what is the conversion impact? |
Notice the pattern: current-state friction + decision owner + measurable uncertainty. That triad keeps Domain 1 work connected to business value.
Scenario: Claims Operations Current State
Framed situation: A property insurer's claim cycle times are lengthening; customer NPS for claims is falling; leadership wants "better analytics."
People: Adjusters, specialty reviewers, and a small actuarial analytics group. Front-line supervisors decide staffing daily; a claims VP decides process policy quarterly. Adjusters are measured on closure volume, which can conflict with quality.
Process: FNOL → assignment → investigation → estimate → settlement. Exceptions (fraud review, total loss, litigation) exit the main path. There is no standard post-settlement review of estimate accuracy by vendor.
Technology: Legacy claims system is system of record; a separate imaging system holds documents; a BI tool shows lagging cycle-time dashboards refreshed nightly. No shared workspace for adjuster notes analytics.
Data: Structured claim fields are fairly complete; unstructured notes are rich but unused; vendor estimate quality scores exist but are not joined to cycle-time reporting. "Cycle time" is defined three ways across teams.
Baselines: Median cycle time 14.2 days; fraud-referral rate 4.1%; reopen rate 6.8%.
Pain points: Nightly dashboards arrive too late for daily staffing; leadership arguments waste time on metric definitions; high performers' practices are not captured.
Research-question seeds: Which claim attributes at FNOL best predict cycle time >21 days? Does vendor estimate error associate with reopens? Which process steps contribute most variance by claim type?
This current state makes clear that jumping into note NLP or building another dashboard would miss definitional and decision-timing issues.
Trap: Analyzing Data Before Understanding Decisions
Trap: A team pulls two years of transactions, runs clustering, and presents "interesting segments" before mapping who decides offers, budgets, or service treatments.
Why it fails: Segments without decision rights become posters, not policy. CBDA scenarios often reward the candidate who first maps the decision process and information used today, then determines what analysis would change a decision.
Counter-practice:
- Observe or interview a real decision cycle (weekly demand meeting, credit committee, bed huddle).
- Collect the actual artifacts used (spreadsheets, emails, tribal rules).
- Baseline the outcome and process metrics those people already debate.
- Only then design data pulls that answer their open questions.
Lightweight Current-State Deliverable
For most initiatives, a short current-state pack is enough:
- Situation restatement (from framing).
- Decision map (who/when/criteria).
- PPTD summary (people, process, technology, data) with risks.
- Baseline metric table with definitions and sources.
- Pain-point list ranked by decision impact.
- Research-question candidates for stakeholder validation.
You do not need a 100-page as-is architecture document. You need enough shared understanding that future-state design, gap analysis, and success metrics (next section) are grounded in reality.
Current-state analysis is the bridge between a framed business situation and testable research questions. Master the four dimensions, lock baselines, surface decision pain, and resist the urge to "just look at the data" until you know how decisions are made today.
A team begins profiling every table in the enterprise warehouse on day one of a margin-improvement project. Stakeholders have not yet mapped who sets prices or how weekly margin reviews work. What current-state principle is MOST violated?
Which item BEST belongs in a current-state baseline for a hospital readmission analytics initiative?
During current-state interviews, two departments publish different monthly "active customer" counts, and regional managers delay promotions until they reconcile the numbers. How should this finding primarily feed Domain 1 work?