Why Reporting in Dynamics AX2012 is Difficult and what you can do about it

Transcription

1 Why Reporting in Dynamics AX2012 is Difficult and what you can do about it Written By: Gina Pabalan Director, Data & Analytics

2 Reporting in the Context of an ERP Project Implementing a new ERP system consumes significant resources: time, money, and overall energy of the business. Many times the legacy ERP system, which has evolved over the years, is meeting the business s basic day-to-day operational needs, including its reporting and general data needs. Nevertheless, companies sometimes decide to replace legacy ERP systems with a more modern, flexible ERP system in order to adapt to changing business needs, take advantage of technical advancements, and help drive the organization to the next level and in some cases to replace those old green screens, sometimes the kiss of death when trying to recruit new talent! What companies sometimes overlook is that the basic blocking and tackling of implementing a new ERP system is all-consuming, and even though there will be many wins for the organization, there will also initially be a few losses including in the area of reporting. So now that you are live on Dynamics AX2012, you may be wondering about the best strategy for developing all those operational and analytical reports not included as part of your ERP implementation. You may have found that your business is not getting everything it anticipated when it comes to reporting. In this white paper, we will explore this challenge in terms of your Microsoft Dynamics AX2012 [AX2012] implementation. Reporting vs Analytics It s important to distinguish the meaning of reporting and analytics. These terms are often improperly used interchangeably. Both terms relate to how the business is leveraging enterprise business data, including the data that is created from each and every transaction within AX2012. Let s clarify Reporting by defining what we mean by a report. In AX2012, a report can mean: 1. A business form, like an Invoice or Bill of Lading 2. A grid of information being displayed within the AX2012 application/screen 3. A report with columns and lines of transactional data, with groupings and subtotals typically something that is to be printed with page numbers. For this white paper, when we refer to a report, we will specifically be referring to #3. It is important to note that the tool Microsoft uses for AX2012 reporting is SSRS, or SQL Server Reporting Services. The standard out-of-the-box AX2012 operational reports are SSRS reports. SSRS is an IT tool and requires a technical resource to create the report. Standard AX2012 SSRS reports directly access the AX2012 transactional data as the data source. Analytics, especially business-oriented exploratory analytics, means interacting with and visualizing data, often leveraging aggregated, or summarized, data sets. The ability to slice and dice, and interactively drill into lists and individual transactions in a more ad hoc exploratory fashion, can lead to new business insights. Analytics can also imply the use of dashboards that display KPIs and metrics. More advanced predictive analytics techniques can provide better understanding of the influence key performance drivers have on future results. For analytics in AX2012, Microsoft delivers 20 out-of-the-box SSAS OLAP cubes [SQL Server Analysis Services; Online Analytical Processing]. These cubes are multidimensional, aggregated data sets intended to provide a foundation for customers using Microsoft s analytical technologies. Optimally, both Reporting and Analytics tap into a shared governed data set as a framework for establishing a single source of truth. For AX2012, that shared governed data set is the AX2012 transactional database. This has been problematic for many customers, because of the complexity in the underlying AX2012 data, the difficulty in harmonizing additional data sources, and the proprietary way the out-of-the-box SSAS OLAP cubes function. Let s further understand the out-of-the-box features in AX2012.

3 Standard Microsoft Dynamics AX2012 Reporting & Analytics Capabilities There are four key reporting tools for Microsoft AX2012 customers to consider when building out a standard Microsoft stack: SQL Server Reporting Services [SSRS], Management Reporter [MR], Excel, and Power BI as illustrated below: 1. SQL Server Reporting Services [SSRS] is a reporting tool IT resources would use to generate pixel perfect paginated reports, with structured headers and footers that include columns and rows of transactional data, many times with subtotals and totals. SSRS is included in SQL Server licensing, as well as in the SQL Server runtime license that is delivered with AX2012. Standard operational reports delivered in AX2012 are written in SSRS, and many customers use SSRS to generate custom reports. The source data for using SSRS is generally the AX2012 transactional database, unless the implementation includes a data warehouse (more on this later). SSRS reports typically provide operational information. 2. Management Reporter [MR] is a reporting tool for business users who generate financial reports. MR is included in the AX2012 licensing. With AX2012, the MR Data Mart is a mandatory part of the set up. In earlier versions of Dynamics AX, MR connected directly to the AX transactional database, but with AX2012 s increased complexity, Microsoft determined that the Data Mart was necessary. The MR Data Mart is a black box, in that external data cannot be brought in, nor can the Data Mart be modified. As an example, new fields cannot be added to the MR Data Mart, even if these fields are driven from the AX2012 database. Microsoft delivers the MR Data Mart to specifically serve the needs of reporting in MR. No other reporting tools may access the MR Data Mart. 3. Power BI and Excel are analytical tools used by business users that allow for data exploration and visualization. Generally, these tools get data from aggregated, or summarized data sets, in this case the SSAS OLAP cubes. Microsoft delivers 20 standard OLAP cubes. You would not want to connect PowerBI or in many cases Excel directly to the AX2012 transactional database. Connecting to the transactional database is not performant. For this reason the OLAP cubes are the preferred data source for AX2012 analytics 1, providing aggregated, or summarized data. It should be noted that the 20 standard OLAP cubes were developed as a generic solution, and seldom work well out-of-the-box in real-world scenarios. Each customer has unique needs, so the cubes require work before they are truly usable. Extending and managing the cubes is tedious, labor intensive, and not business-oriented. The task requires advanced MDX programming skills, combined with a firm understanding of the AX2012 database, which is a difficult skill combination to procure. Further, these OLAP cubes are sourced directly from the AX2012 transactional database: one must go back to the highly complex AX2012 environment to serve more granular reporting needs. Therefore, less than 10% of all AX2012 users are using the standard out-of-the-box SSAS OLAP cubes to serve their analytics needs. 1 In D365FO, the next version of AX2012, Microsoft created the Entity Store, functionally similar to the OLAP cubes in AX2012, but intended for Power BI and better adapted to an SSAS Tabular model. Microsoft backported the Entities to AX2012; however at the time of writing, the AX2012 Entities are known to be problematic.

4 So why is reporting so difficult in AX2012? The AX2012 database was designed for transactional efficiency and scalability. That is, the AX2012 database is highly normalized and complex after all, it is an ERP system. The more normalized and complex the database, the less useful it becomes for writing reports. As a point of reference, the previous release of AX (AX2009) contained 1,800 tables. In AX2012, the tables have exploded to over 6,400. The standard SSRS reports delivered out-of-the-box are very basic reports and not overly complex. However, most customers will need custom reports that require complex queries with multi-table joins against the production AX2012 transactional data. Transactional ERP databases grow over time, with some tables reaching in the millions of transactions. Custom SSRS reports become more problematic when running complex reports over a complex database with large data sets. The result can be significant ERP system performance degradation. Since these reports are running against your production ERP system, the potential to slow down order entry and shipping processes is high. Further, if data important for reporting is not captured within your Dynamics AX system, you may be tempted to customize AX2012 in order to store the data just for reporting purposes. This should be avoided, as any customization to AX will increase your total cost of ownership [TCO]. For example, think about the additional cost to upgrade when customizations and custom data are in play. And for what? So you can write a report from the AX transactional database, which is not structured for reporting in the first place? Customizing AX may be the right answer, but in most cases, it is not. Finally, any reporting tool, whether it be Power BI, Excel, SSRS or other, will not perform well if connected directly to the transactional AX2012 database. This is why Microsoft requires the Data Mart for Management Reporter, and it is why Microsoft delivered the OLAP cubes for Power BI. Microsoft prepares its data before putting a reporting tool over it, and so should you. Ad hoc reporting against the AX2012 database should be highly limited. Like all general best practice rules, this one must sometimes be overridden, but organizations must carefully consider the long term impact and have another option for the majority of its operational reporting and analytics needs. Best Practices for delivering Reporting & Analytics for AX2012 To achieve best practice reporting and analytics in AX2012, you must PREPARE YOUR DATA! With a governed and simplified data set for your operational AX2012 transactional data, SSRS reports will be easier to create (requiring a less skilled IT resource), and reporting will become more accessible to the business without constant assistance from the IT staff. IT becomes the curator and purveyor of the data, and the business is enabled to drive its own reporting in a self-serve environment. Preparing your data implies separating your reporting data from your ERP data, and structuring it in a way that makes sense for your business. The time-tested approach is creation of a Data Warehouse. Benefits include: 1. Employees with no AX2012 license will still have access to critical enterprise data. 2. Sourcing complex reports off a prepared data set will allow reports to run more efficiently (quicker), as well as have zero ERP production system impact. 3. Developing reports from the prepared data set requires a less skilled worker (IT or Business) 4. Democratizing your data is best practice and is essential for achieving a data-driven organization. 5. Microsoft does it, and so should you.

5 How Did Fullscope solve these challenges? Fullscope s Customer Support & Optimization Services ( CSO ) team manages close to 100 AX2012 customers and experienced first-hand how the new and complex AX2012 data schema created challenges for operational reporting and analytics. We needed to identify the right solution for our customers to meet their BI needs. Our guiding principles were: 1. Leverage as much of the Microsoft stack as possible. Our customers have invested in Microsoft and it is important that they maximize the return on that investment. 2. Avoid proprietary components that require customers to be married to an ISV (Independent Software Vendor) longer than they choose to be. 3. Deliver baseline capability that is not over-engineered, something the customer can leverage and easily modify and extend to make their own. Out-of-the-box analytics solutions are conceptually appealing, but in reality, one size never fits all. 4. Enable the customer to be self-sufficient and not highly dependent on consultants for the solution s long term care and feeding. The customer s reporting and analytics solution will evolve over time, and they need to be able to drive that independently. 5. Plan and build for business user adoption. The right front end reporting tool is one a specific user will use. Whether that turns out to be Power BI, Excel, or something else the right BI solution must meet the needs and enhance the performance of everyone in the organization. 6. Make the solution affordable. Most AX2012 customers are mid-market manufacturing organizations and do not have the budget for massive BI investments. At Fullscope, our customers leverage our highly affordable Reporting & BI Accelerator, which aligns with all six principles above. The solution includes a baseline Enterprise SQL Data Warehouse that takes the 6,400 AX2012 tables and flattens them to 65 tables for easier access to your enterprise information, coupled with a drag and drop tool to easily and efficiently adapt, extend and enhance the back end data that drives analytics. The result is a simplified and governed data set of your AX2012 transactional data that accelerates your ability to deliver vital information to your business. To learn more, contact gina.pabalan@fullscope.com.