Understand the businessbefore designing the data.

GreenBox is a fictional sustainable packaging manufacturer and distributor operating across Australia, New Zealand, and Singapore. Its business spans sales, procurement, inventory, fulfilment, finance, marketing, and customer service, supported by a mix of operational and analytical systems.

The central challenge identified in this simulated discovery is that teams cannot always rely on the same interpretation of enterprise performance. Revenue and margin definitions can differ, operational processes are measured in silos, and ownership of key business metrics is not consistently formalised.

Discovery conclusion: This is a business definition, process integration, and governance challenge as well as a technical data-platform challenge. More dashboards alone will not resolve it.

The objective is to understand business needs before committing to physical data models or implementation patterns.

1. Understand executive priorities and the decisions that require better information.
2. Capture departmental processes, KPIs, pain points, and data dependencies.
3. Identify cross-functional processes and the events connecting them.
4. Propose KPI ownership and record definitions that require business approval.
5. Translate findings into integration, modelling, governance, and semantic-layer requirements.
6. Record assumptions, open questions, and next-phase activities.

Guiding principle: capabilities → processes → events → KPIs and requirements → data models → platform implementation → semantic metrics → consumption.

Executive findings

Establish a common understanding of enterprise performance

Leadership needs approved definitions for enterprise KPIs, including calculation rules, business scope, and accountable owners.

Connect departmental reporting to end-to-end processes

A sales order may progress through allocation, picking, shipment, delivery, invoicing, and payment. Reporting should preserve those separate stages while enabling lifecycle analysis.

Improve confidence in financial and operational information

Users need to understand why figures differ, which definition is appropriate for a particular decision, and who owns the underlying rule.

Prepare for future analytical use cases

The platform should preserve appropriate detail and expose reusable, governed metrics for BI and future AI consumption.

Executive design principles

• One governed definition for each approved enterprise KPI, with explicitly named variants where needed.
• Business owners approve business meaning; technical teams implement and document the approved rules.
• Model business processes and their relationships, not just source-system tables.
• Preserve atomic detail and use appropriate aggregates and semantic design for performance.
• Maintain traceability, data quality, access controls, and change governance.

Stakeholders: Michael Lee (Finance Manager), Jessica Brown (Financial Controller). Executive sponsor: Sarah Williams, CFO.

Priorities

Revenue recognition, financial reporting, budgeting and forecasting, profitability reporting, and reconciliation of financial results with commercial and operational information.

Findings

• Revenue is not one interchangeable measure. Finance Revenue and Sales Revenue may represent different business questions, recognition rules, periods, or transaction populations.
• Gross Margin needs Finance approval. Its formula and cost inclusions have not been established in discovery.
• KPI ownership needs formalisation. The business requires a glossary with owners, definitions, calculation rules, and approved use.
• Similar labels can hide different meanings. Gross Revenue, Returned Revenue, and Net Revenue should be distinguished explicitly.

Requirements and architecture implications

• Document financial metric purpose, scope, dates, and calculation rules.
• Investigate relationships among sales order lines, invoice lines, credit notes, returns, and accounting entries.
• Preserve transaction-level traceability and required reconciliation points.
• Publish approved definitions through a governed semantic layer rather than redefining them in individual reports.

Open decisions

Finance must approve treatment of returns, credits, discounts, adjustments, reporting dates, Gross Margin cost components, and authoritative reconciliation sources.

Stakeholders: Emma Brooks (National Sales Manager), Daniel Chen (Key Account Manager). Executive sponsor: James Carter, CSO.

Priorities

Sales performance, quote-to-fulfilment visibility, commercial profitability, customer-account performance, and future customer retention analysis.

Findings

• Sales performance extends beyond order creation into fulfilment, delivery, invoicing, returns, and financial outcomes.
• Sales and Finance need related but distinct measures; common labels do not imply identical definitions.
• Customer retention is a future priority, but its definition, measurement period, eligible population, and accountable owner remain open.

Requirements and architecture implications

• Track opportunity and quote through order and downstream fulfilment.
• Use conformed Customer and Product dimensions and retain relationships to downstream transactions.
• Keep opportunity, order, fulfilment, shipment, invoice, and return grains distinct.
• Agree how cancellations, partial fulfilment, and returns affect commercial analysis.

Open decisions

Define commercial sales measures, customer hierarchy, treatment of exceptions, retention methodology, and which measures should reconcile to Finance versus answer a distinct commercial question.

Stakeholders: Lisa Morgan (Supply Chain Director), Ben Harris (Warehouse Operations Manager), Sophie White (Procurement Manager). Executive sponsor: David Cooper, COO.

Priorities

Inventory visibility, fulfilment reliability, supplier performance, warehouse operations, OTIF, and identifying operational delays.

Findings

• Operational milestones span systems and teams: allocation, picking, packing, shipment, and delivery.
• Inventory quantities need context by product, location, status, and snapshot time; on-hand stock is not automatically available stock.
• Supplier delays can affect inventory availability and downstream customer commitments.
• OTIF is an enterprise outcome, but its definition depends on agreed commitment, timing, completeness, and evaluation grain.

Requirements and architecture implications

• Distinguish ordered, allocated, picked, shipped, and delivered quantities.
• Use inventory movement and inventory snapshot models for their different analytical purposes.
• Model purchase orders and supplier deliveries, and retain product and location context.
• Capture timestamps and statuses needed to evaluate approved delivery commitments.
• Do not assume one order corresponds to one shipment or delivery.

Open decisions

Agree promised-date rules, OTIF grain, partial-delivery treatment, stock statuses, supplier-performance rules, and authoritative operational systems.

Stakeholders: Ryan Scott (Marketing Manager), Emily Davis (CRM & Campaign Specialist). Executive sponsor: Olivia Taylor, CMO.

Priorities

Lead generation, campaign effectiveness, customer engagement, contribution to revenue, and future retention analysis.

Findings

• Campaign-attributed revenue depends on attribution windows, qualifying interactions, identity matching, and conversion rules.
• Marketing needs to measure contribution to commercial outcomes but does not own the enterprise definition of Revenue.
• Leads, contacts, customer accounts, opportunities, and orders need explicit relationships and identity rules.

Requirements and architecture implications

• Model leads, opportunities, campaigns, and sales transactions as distinct entities or processes.
• Document attribution methodology and its limitations.
• Prevent multiple campaign interactions from accidentally multiplying attributed revenue.
• Publish campaign-attributed metrics with clear names and approved logic.

Open decisions

Define qualified leads, conversion, attribution model and window, handling of multiple interactions, and identity resolution rules.

Stakeholders: Tom Wilson (Customer Support Manager), Anna Lewis (Customer Experience Manager). Cross-functional partners include Sales, Supply Chain, and Finance.

Priorities

Case volume, complaint management, resolution time, first-contact resolution, customer satisfaction, and recurring customer issues.

Findings

• Cases can arise from late delivery, incorrect products, incorrect invoices, missing orders, damage, or pricing discrepancies.
• The team handling a case is not necessarily the owner of the upstream cause.
• Case volume and resolution time are useful, but understanding recurring problems requires links to orders, shipments, invoices, products, or returns where possible.

Requirements and architecture implications

• Model customer cases separately from orders, shipments, and returns.
• Capture case category, status, creation and resolution milestones, and root-cause classification.
• Define how reopened cases and multiple cases for one order are counted.
• Separate case-management performance from upstream operational performance.

Open decisions

Agree definitions for cases, complaints, reopened cases, business-hours resolution time, first-contact resolution, root-cause taxonomy, and links to source transactions.

Enterprise governance requirement

Every important KPI needs a clear business owner, approved definition, calculation rule, lineage, and change process. Business disagreements should be resolved through governance, not silently decided in transformation code.

These are proposed requirements derived from the fictional discovery scenario. They are not yet formally approved acceptance criteria.

Ownership is a proposal until formally approved. Formula details are intentionally left open where discovery did not establish a business-approved rule.

Business architecture before physical modelling

Use the sequence capabilities → processes → events → KPIs and requirements → data models → implementation → semantic metrics → consumption. This ties structures to business outcomes instead of simply copying source schemas.

Fact grain must be explicit

Sales order lines, shipment lines, inventory movements, inventory snapshots, invoice lines, and customer cases have different grains. They should not be merged just because they are related. A single order line can be fulfilled by multiple shipments, and naive joins can multiply measures.

Conformed dimensions support shared analysis

Customer, Product, and Location are initial candidates for conformed dimensions. The design must distinguish source-system IDs, enterprise business IDs, and warehouse surrogate keys, especially across legacy systems and acquired businesses.

Separate atomic facts from governed metrics

Preserve the appropriate transaction detail. Use a semantic layer for approved reusable definitions, and use aggregates or performance design where required without unnecessarily discarding atomic data.

Governance is part of the architecture

Business definitions, ownership, lineage, source-to-target mappings, quality checks, reconciliation, access controls, and change processes should be designed into the solution from the beginning.

Discovery outputs

Key risks and assumptions

• Centralising data will not resolve conflicting definitions unless business rules are agreed.
• Incorrect fact relationships can inflate measures if grain is not respected.
• Technical teams should not make unapproved business decisions in code.
• Source identifiers, timestamps, and statuses may be incomplete or inconsistent.
• Manufacturing, risk, compliance, and regional requirements need further discovery.
• Illustrative systems include NetSuite, legacy SAP, Shopify, HubSpot, Manhattan WMS, 3PL systems, Snowflake, and Power BI; these are assumptions for the fictional scenario.

Step 1 exit criteria

• Executive priorities documented.
• Finance, Sales, Supply Chain, Marketing, and Customer Service findings captured.
• Cross-functional issues and initial requirements recorded.
• Initial KPI ownership directions proposed.
• Open questions and assumptions documented.
• Formal KPI approval, full capability validation, and acceptance criteria remain outstanding.

Transition to Step 2 — Business Requirements & Scope

The next phase prioritises requirements, defines in-scope and out-of-scope areas, identifies the first release, sets acceptance criteria, and confirms source-system and data-domain boundaries.

Proposed initial focus: Sales, Fulfilment, Inventory, and Finance, because these domains connect revenue and profitability questions with inventory availability, delivery performance, and downstream financial outcomes. The first release should be confirmed against business value, source availability, and implementation effort.

Final takeaway: The architecture should preserve the meaning of business transactions, connect the processes that create outcomes, establish approved reusable definitions, and make information trustworthy and understandable. That is the business foundation for the data model and platform design.