GDP Framework¶

By: Anant Kulkarni

Introduction¶

The Gold Data Points (GDP) Framework is a structured approach for transforming raw enterprise data into business-ready insights for C-suite decision-making.
It defines the layers, canonical models, and governance principles that allow data to move from ERP/CRM/HRMS systems into trusted financial, sales, and operational metrics.

Why GDP? Raw data is noisy, siloed, and system-specific. GDP abstracts this into a small, finite set of enterprise metrics — the “gold” numbers that leaders actually use.
Target Users: CFOs, Sales Heads, COOs (domain-wise packs).
Design Philosophy: Keep raw data intact (bronze), reduce and align into GDP (silver → gold), and expose only the important facts that drive enterprise intelligence.

Layered Architecture¶

Core Systems (ERP / CRM / HRMS / Mfg)  
        │  
        ▼  
Bronze Layer → Raw Data (immutable, CDC, no joins)  
        │  
        ▼  
Silver Layer → Standardized / GDP Tables (typed, deduped, aligned to canonical keys)  
        │  
        ▼  
Gold Layer → GDP → KPI Tables (enterprise-ready metrics, anomaly checks, contracts)  
        │  
        ▼  
Executive Packs → CFO, CGO, COO Dashboards & Reports

Bronze (Raw)¶

Immutable copies of source tables.
Schema as-is (system-specific).
Used for traceability, never directly queried by business.

Silver (Standardized / GDP Base)¶

Transformations applied: deduplication, typing, harmonization.
Canonical dimensions introduced: Customer, Product, Calendar, Org, Plant/Project.
Still near-source shape but readable.

Gold (GDP → KPI)¶

Gold Data Points are business-critical facts abstracted from GDP tables.
Examples: Revenue, AR Aging, Liquidity Ratios, Headcount, OEE, Pipeline Velocity.
Governed semantic layer ensures consistent definitions across domains.

GDP Table Families¶

GDP Table Type	Description	Example Tables
Universal	Cross-enterprise canonical tables	Date/Fiscal Calendar, Organization, Customer Master
Finance	Core financial abstractions	Invoices, Payments Received, Credit/Debit Notes, AR, AP
Sales	Commercial and pipeline views	Orders, Pipeline Stages, Conversion Ratios
Operations	Production and supply chain	Plant Output, OEE, On-Time Delivery
People	Workforce abstractions	Headcount, Attrition, Cost per Employee

Canonical Dimensions¶

GDP uses canonical building blocks that remain consistent across industries:

Date / Fiscal Calendar – standardizes holidays, fiscal years, org-level and unit-level calendars.
Organization – companies, plants, projects, stores (depending on industry).
Customer – harmonized view across CRM, ERP, and finance.
Product / Service – common catalog for revenue and cost analysis.
People – employees, contractors, units for HR/finance ratios.

Gold Data Points (Examples)¶

Finance (CFO Pack)¶

Revenue (Net, Gross)
Accounts Receivable Aging
Liquidity Ratios
EBITA / Margin %
Compliance readiness metrics

Sales (CGO Pack)¶

Pipeline Coverage Ratio
Lead → Opportunity → Win Conversion
Revenue Acceleration Index
Customer Profitability

Operations (COO Pack)¶

OEE (Overall Equipment Effectiveness)
Cost of Quality
Throughput
On-Time Delivery %

Design Principles¶

Keep it Simple: GDPs are finite and human-readable, not system-dump replicas.
Separation of Concerns: Raw → GDP → KPI ensures clarity and auditability.
ERP-Agnostic: GDP abstracts away vendor complexity (SAP, Oracle, SFDC).
Reusable: Same GDP layer can serve multiple functional packs.
Enterprise Data Contract: GDP definitions act as contracts between IT and Business.

Known Risks / Mitigations¶

Risk	Impact	Mitigation
Over-generalization (too SAP-like)	Complexity, slow adoption	Keep base GDP simple, domain packs on top
Tagging overhead	Heavy setup cost	One-time heavy lifting, reusable thereafter
“Gold Data” confusion (GDP vs GDP in economics)	Miscommunication	Always expand as “Gold Data Points” in docs
Lack of UI connect	Business disconnect	Subsection on UI implications (filters, drill-downs, semantic layer)

Takeaways¶

Declare holidays, fiscal years at both org and unit level.
Use Universal Date Table as a foundation.
GDP tables should be auditable back to a raw source.
Do not attempt to expose all operational details — abstract only important information.
Always document freshness, anomaly checks, and validation.