I’m working on redesigning our financial reporting dashboard in S/4HANA 1909 using Fiori KPI tiles. Our finance team needs quick visibility into key metrics like cash position, AR aging, AP overdue, and budget variance across company codes and profit centers.
The challenge is balancing information density with performance and usability. Some team members want drill-down capabilities from tiles, others want real-time updates, and everyone has different preferences for data granularity. We’re also struggling with defining KPIs clearly - what exactly should “cash position” show? Current bank balance? Liquidity forecast? Available credit lines?
I’ve looked at SAP’s standard KPI tiles, but they seem too generic for our needs. We’re considering building custom tiles using CDS views, but I’m concerned about performance impact if we have 20-30 tiles loading on the launchpad. What are the best practices for KPI definition clarity, optimizing underlying CDS views, and properly using Fiori KPI Workspace for configuration?
KPI tile performance degradation with 20-30 concurrent tiles on launch is a well-documented pattern tied to unoptimized CDS view execution and excessive OData calls on launchpad load.
Diagnostic Steps
Run /IWFND/TRACES and ST05 simultaneously during launchpad load to capture OData service calls and underlying SQL execution per tile. Identify which tiles exceed 500ms response threshold.
Check RSRT for each CDS-backed query — execute with Debug/Log mode to expose missing indexes, missing aggregations, and full table scans on ACDOCA or FAGLFLEXA.
Use transaction SE11 to verify that CDS views backing financial KPIs have @Analytics.dataCategory: #CUBE or #FACT annotations correctly set — missing annotations force runtime to skip pre-aggregation.
In SICF, confirm that the SAP_BASIS_SRV_OVP and UI2 services are active; missing services cause tiles to fire redundant fallback requests.
Review NW Gateway server logs via /IWFND/ERROR_LOG for throttled or queued tile requests during peak load.
Tuning Parameters & Design Controls
Lazy loading: In KPI Workspace (/UI2/FLP config), enable lazyLoading: true for tile groups outside the initial viewport — verify path in your version under Fiori Launchpad Designer → Site Settings.
CDS view buffering: Apply @VDM.viewType: #CONSUMPTION and add @ObjectModel.usageType.dataClass: #MIXED with @Semantics.amount annotations to prevent repeated currency conversion at runtime.
Aggregation push-down: Define calculation views or CDS aggregation views with GROUP BY pushed to HANA rather than application server. Use @Aggregation.default: #SUM on measure fields.
Refresh interval: Set tile refresh to ≥300 seconds for non-critical KPIs (budget variance, AP overdue aging). Reserve sub-60s refresh only for cash position if genuinely required. Configure via Smart Business KPI configuration app.
Tile count ceiling: Stay under 15 tiles per launchpad group loading on initial render. Use sections/pages to segment AR, AP, and liquidity into separate groups with on-demand load.
KPI Definition Clarity
For cash position specifically: define scope explicitly in the KPI header — current bank balance (HKB accounts from FF7A/FLQC10) vs. liquidity forecast (integrates FI-LC planning data). These are distinct data sources with different latency profiles. Document the definition in the tile subtitle field to prevent finance team misinterpretation.
Monitoring / Verification
After tuning, baseline launchpad load time using Chrome DevTools Network waterfall filtered to /sap/opu/odata/ calls. Target: all tile data requests complete within 3 seconds of initial render. Re-run RSRT on modified CDS views and confirm HANA execution plan shows Column Store access, not Row Store fallback.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
From a UX perspective, less is more with KPI tiles. I recommend limiting launchpad to 8-12 critical KPIs maximum. More than that overwhelms users and impacts performance. Use role-based launchpad configurations so different user groups see relevant KPIs - AP clerks don’t need the same view as CFO. For drill-downs, consider linking tiles to full Fiori analytical apps rather than trying to pack too much into the tile itself.
Performance-wise, each KPI tile makes an OData call when the launchpad loads. With 20-30 tiles, you’re looking at significant load time unless you optimize. Key techniques: 1) Use CDS views with proper indexing and aggregation, 2) Implement tile caching with reasonable expiration (5-10 minutes for financial data), 3) Use lazy loading so tiles only fetch data when visible, 4) Consider batch requests to combine multiple OData calls. Also, test with realistic data volumes - a KPI that performs well with test data might timeout with production volumes.
For KPI definition, we spent weeks in workshops defining exactly what each metric means. “Cash position” is meaningless without context - we ended up creating three separate KPIs: 1) Available cash (bank balances minus committed payments), 2) 30-day liquidity forecast, 3) Credit facility utilization. Each has clear calculation logic documented. Document your KPI definitions in a financial metrics catalog - include calculation formula, data sources, refresh frequency, and business owner. This prevents confusion and ensures consistent interpretation across the organization.
CDS view optimization for KPI tiles is critical. Use @Analytics.query: true on consumption views and ensure your view stack is shallow - ideally 2-3 layers max. For financial KPIs pulling from BSEG/BKPF, always filter on company code and fiscal year as early as possible in the view hierarchy. Use @ObjectModel.usageType.serviceQuality: #D for KPIs that can tolerate slightly stale data - this enables better caching. And test your CDS views directly in RSRT or with /IWFND/GW_CLIENT before building Fiori tiles around them.
Fiori KPI Workspace is your friend here. Instead of hard-coding KPI definitions in ABAP or JavaScript, use the workspace to configure KPIs declaratively. You can define calculations, thresholds, and visualizations without coding. It also supports evaluation scenarios where the same underlying data can be sliced different ways (by company code, profit center, etc.) without creating separate CDS views for each. The workspace integrates with KPI tiles automatically.
Thresholds and Alerts: Define what constitutes red/yellow/green
AR Aging > 90 days > 15% of total = Red
Cash position < 5 days operating expenses = Yellow
Drill-Down Path: Specify what users see when clicking the tile
Cash Position → Bank Account Details app → Individual transactions
Data Quality Dependencies: Note any data prerequisites
Budget variance requires current budget version loaded
Liquidity forecast requires payment terms maintained on vendors
Create a KPI catalog document with these details for each metric. Store it in a shared location and reference it in tile descriptions.
CDS View Optimization for Financial KPIs:
Financial data in S/4HANA (especially BSEG/ACDOCA) can have millions of records. Optimization is critical:
View Architecture:
Layer 1 (Interface): I_JournalEntry, I_OperationalAcctgDocItem (use SAP standard)
Layer 2 (Composite): Z_CashPositionBase
- Join bank accounts (GLT0/SKA1) with open items (BSID/BSIK)
- Filter: BUKRS, GJAHR, Account Type = 'Bank'
- Early aggregation by company code and account
Layer 3 (Consumption): Z_CashPositionKPI
- @Analytics.query: true
- @OData.publish: true (or service definition in newer approach)
- Final calculations, currency conversion
- @UI annotations for tile visualization
Performance Patterns:
Selective Filtering: Always filter on indexed fields early
BUKRS (company code) - typically first filter
GJAHR (fiscal year) - limit to current + prior year
BLART (document type) if relevant
Aggregation Strategy: Pre-aggregate where possible
Instead of counting individual line items, aggregate at document header level
Use SUM/COUNT in CDS view rather than in OData query
Association vs. Join: Use associations for optional data
Join for required data (company code to company code text)
Association for optional enrichment (cost center details)
Currency Handling: Use built-in CDS currency conversion
The key is treating KPI design as a product development effort, not just a technical implementation. Involve users throughout, iterate based on feedback, and continuously optimize based on usage patterns.