Internal project — code and data are private. Only design documentation and architecture are shared.
Zero-to-One design of a procurement analytics platform built on SAP BW/SAC, covering performance analysis, inventory monitoring, and KPI management across a global procurement organization. Used by ~100 people including executives and leadership for data-driven decision making.
| Phase | Scope |
|---|---|
| Phase 1 | BU1 — 7 global sites + Korea |
| Phase 2 | BU2 — 13 manufacturing plants |
| Phase 3 | BU3 — 10+ additional global sites |
| Expansion | Inventory analysis module added |
Total users: ~100 across HQ procurement org, including executives and leadership
A set of structural issues had built up from managing performance data in manual Excel files.
Data reliability Each site calculated the same metric using different logic. Numbers varied depending on who pulled them and how — performance management was running on data nobody fully trusted.
No version control, no history When standards changed, past data wasn't retroactively updated. No audit trail meant it was nearly impossible to explain why this month's number differed from last month's.
High cost of any change One number changing meant manually updating every connected file. Errors were inevitable, and tracking them down was even harder.
Procurement performance analysis
- Flexible views by receipt basis, production basis, and other criteria
- Free currency conversion (local currency / USD / KRW, etc.)
- Plan version comparisons (annual plan / revised plan / latest forecast, etc.)
- Price variance, volume variance, spend analysis
Inventory analysis (expansion)
- Days of inventory calculated against revenue
- In-transit inventory monitoring
- Inventory status by site and category
Usability
- Executive summary view vs. operational detail view
- Ad-hoc filtering for on-demand analysis by any combination of criteria
Step 1 — Stakeholder interviews Mapped what each team needed, how they calculated it, and where the data came from. Confirmed that the same metric was being calculated with different logic across sites.
Step 2 — Metric definition doc
| Metric | Formula | Source | Cadence | Owner |
|---|---|---|---|---|
| Price variance | (actual unit price - baseline) × volume | SAP ERP | Monthly | Procurement |
| Spend actuals | Cumulative confirmed PO amount | SAP ERP | Weekly | Strategy |
| Days of inventory | Inventory value / (revenue / days) | SAP ERP | Monthly | Inventory |
Unified calculation logic and established a change history process.
Step 3 — Data model design
SAP ERP (source)
↓
BW (extract + transform + load / site-specific logic standardized)
↓
SAC (visualization + dashboard)
↓
Executive summary view / operational detail view
Step 4 — Operational governance → Assigned data owners per org unit → Bi-weekly data verification meetings
Standardizing site-level logic Tax rules, FX timing, and PO confirmation criteria all differed by country. Applied site-specific conversion logic at the BW layer.
Dynamic currency conversion As more global sites were added, more currencies came in. Defined clear FX application rules and built dynamic conversion into SAC.
Plan version management Multiple plan versions (annual / revised / latest forecast) all live simultaneously and keep updating. Added a version dimension to the data model to enable side-by-side comparisons.
Expanding without restructuring Phase 1 structure held through BU2, BU3, and the inventory module expansion — because extensibility was built in from the start.
Getting teams to actually enter data Assigned ownership and bi-weekly review cadence instead of pressuring teams. Operational design problem, not a technical one.
SAP ERP SAP BW SAP SAC Python SQL
- Replaced manual reporting with auto-updated numbers from source data
- Standardized calculation logic across all sites → established data trust
- Built change history tracking → past data now comparable
- Executives and leadership directly querying procurement and inventory analytics
- ~100 HQ procurement staff operating from a single source of truth