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?
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.
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.
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.
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.
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.