The bottom line
SAP ByDesign's built-in reporting hits a ceiling fast - the fix isn't replacing your ERP, it's extracting data into a proper analytics layer built for cross-function, multi-entity questions your ERP was never designed to answer.
In This Article
Where SAP ByDesign Sits in the Market
SAP ByDesign occupies a specific and well-earned niche: mid-market companies with 50 to 500 employees that need genuine ERP functionality - procurement, manufacturing, financials, project management - without the cost and complexity of SAP S/4HANA. In the GCC, it is the ERP of choice for a large proportion of manufacturing subsidiaries, joint ventures, and export-oriented businesses. In India, it is common among companies with GCC operations that needed a cloud ERP they could deploy across both geographies.
The decision to go with ByDesign is typically sound. The implementation delivers what it promises: a structured, auditable, multi-currency ERP that handles the core transactional workflows competently. Finance, procurement, and production orders work. The integrated reporting layer - a combination of embedded reports, Crystal Reports, and pre-built analytical views - works well enough for the first two or three years of operation.
The problem arrives when the business grows. When reporting demands expand from basic operational reports to multi-entity consolidated views, custom KPI calculations, or trend analysis across four years of data, the ByDesign analytics layer runs into its design constraints. It was built to support a specific set of standard reports for a mid-market company. It was not built for the cross-functional, multi-source, real-time reporting demands of a business that has outgrown its initial profile.
ByDesign's embedded analytics are designed for operational reporting, not analytical depth. That boundary is invisible on day one and unavoidable by year three.
The Reporting Ceiling Every ByD Customer Hits
The ceiling manifests in four specific ways. First, cross-system analytics. ByDesign handles its own transactional data well, but the moment you need to join ByD production data with warehouse management data from a separate WMS, or combine ByD financials with sales data from a CRM, the embedded reports cannot do it. Every cross-system question becomes a manual export-and-reconcile exercise in Excel.
Second, custom KPI calculations. The pre-built ByD reports use SAP's own metric definitions, which do not always align with how a specific business calculates its operational KPIs. Gross margin by product line calculated the way the finance director wants it - not the way SAP defines it - requires either a customised Crystal Report (expensive, brittle) or an external analytics layer.
Third, historical trend analysis. ByDesign's embedded reporting is designed for current-state operational views. Running a meaningful trend analysis across 36 months of production, inventory, and cost data requires query patterns that the ByD reporting layer was not designed to handle at speed. Reports that should return in seconds can take minutes - or time out entirely on large datasets. Fourth, real-time dashboards. ByDesign refreshes its reporting views on a scheduled basis. For operations teams that need live production visibility, the refresh cycle is too slow.
Why Direct Power BI on ByD OData Breaks Down
The first instinct most ByDesign customers have when they hit the reporting ceiling is to connect Power BI directly to ByDesign via its OData feeds. SAP exposes a range of OData endpoints from ByDesign, and Power BI can connect to OData sources natively. For simple, single-entity reports - a list of open purchase orders, a sales order summary - this works adequately.
The breakdown happens at scale and at complexity. OData queries on ByDesign are row-limited and performance-constrained. A Power BI report pulling 200,000 rows of historical inventory transactions via OData will either time out, return a truncated result, or run so slowly that users abandon it. The ByDesign OData layer was designed for transactional data access, not for bulk analytical extraction.
The second failure mode is multi-source joins. Power BI can connect to multiple OData sources and attempt to join them, but the joins happen in Power BI's in-memory engine rather than at the database level. For large datasets, this is slow and memory-intensive. For complex joins across five or six ByD entities plus external data, it becomes unmanageable. Directquery mode on OData is even more constrained - every visual interaction triggers a new OData query against ByDesign, which degrades both the report and the ERP's transactional performance.
Power BI on ByD OData is a viable approach for simple reports with limited row counts. For analytical depth, historical trends, or multi-source joins, it is the wrong architecture.
The Architecture That Actually Works
The right architecture treats ByDesign as what it is: an excellent transaction processing system. It extracts data from ByD into a dedicated analytical layer - a lakehouse or data warehouse - where the data can be modelled, joined with other sources, and queried at speed without touching the ERP. Power BI then connects to the analytical layer, not directly to ByDesign.
The extraction mechanism depends on volume and latency requirements. For most ByD customers, a scheduled OData extraction into Azure Data Factory or Fabric Data Factory - pulling incremental data every 1–4 hours - provides sufficient freshness for operational reporting without the instability of direct OData queries from Power BI. For customers who need near-real-time data, ByDesign's data replication service can push data to an external target, though this requires additional configuration.
Once the data lands in the analytical layer - typically a Delta Lake lakehouse on Microsoft Fabric or Azure Data Lake Gen2 - it is transformed into a governed semantic model. This is where cross-system joins happen: ByD production data joined with WMS inventory data, ByD financials joined with CRM pipeline data. Power BI connects to this semantic layer via Direct Lake (on Fabric) or DirectQuery (on Synapse), delivering sub-second query performance on datasets that would time out on OData.
How to Migrate Without Disrupting the ERP
The migration approach is non-disruptive by design. ByDesign continues to run unchanged - all transactional processing, all user workflows, all existing ERP reports remain intact. The analytical layer is additive: it reads from ByDesign but does not write back, and it does not require any changes to the ByD configuration or data model.
Phase one is extraction and storage: configure the OData or data replication feeds to push ByD data into the analytical layer on a scheduled basis. For most customers, four entities cover 80% of reporting use cases: sales orders, production orders, inventory movements, and financial postings. Start with those. Add entities as specific reporting requirements surface.
Phase two is semantic modelling: build the dimensional model on top of the raw extracted data. This is where the finance director's KPI definitions get encoded into the model - margin calculations, cost allocations, production efficiency metrics - rather than being recalculated in every Power BI report. Phase three is Power BI migration: rebuild the most-used Power BI reports to point at the semantic layer rather than the OData feeds. Users see faster reports with more data. The ERP is untouched.
SAP ByDesign will serve you well for years - if you stop asking it to do something it was never designed to do. Extract the data properly, build the analytics layer above it, and the ERP investment you've already made starts compounding. Most ByD implementations I've seen underperform not because the ERP is wrong, but because nobody built what belongs above it.