![10 | P a g e
Entity Store
The Entity Store, which is named “AxDW” within D365, serves Embedded PowerBI/Analytical Workspaces.
The Entity Store is a Clustered Column Store Database, separate from the OLTP, and as such, data is “near”
real-time. At this writing, the Entity Store is only available to be refreshed as a full load. Incremental
refresh is in an early Microsoft preview program. It is anticipated that once the incremental load is
available, the Entity Store can be updated as “Low Priority” to refresh every 15 minutes, or “High Priority”
to set up every 1-5 minutes5
.
In order to populate the Entity Store, “Aggregate Measures” must first be configured with the D365
application. Conceptually, this is similar to building OLAP cubes, but less complex when using the D365
Aggregate Measure options. If more complex features are required, such as building out complex
calculations, MDX language (calculations and scripts) may also be used to augment out-of-the-box
features of building Aggregate Measures. Aggregate Measures provide the definition, or data model, for
the Entity Store. The creation of Aggregate Measures requires knowledge in data modeling design, X++,
MDX and native D365 application configurations.
At this writing, there are 52 out-of-box Aggregate Measures within Dynamics 365 F&O that are used to
publish data to the Entity Store.
Aggregate Measures are different from Aggregate [Data] Entities.
What is the difference between an “Aggregate Measure” and “Aggregate Entity”?
In addition to providing definition for the Entity Store, Aggregate Measures also provide the definition for
the Aggregate [Data] Entities. We must first define and create an Aggregate Measure before we can
5
We recommend setting the Entity Store update on Low Priority – as every 15 minutes should meet most reporting needs.
Setting this at a High Priority may create excess batch processes to keep the Entity Store updated and could possibly delay other
operational batch processes. Microsoft states that in case of very high system utilization (ex. due to extreme refresh schedules),
the Microsoft operations teams will advise the customer on managing load.](https://image.slidesharecdn.com/whitepaper-dataandanalyticsford36509162018-180916173519/85/D365-Finance-Operations-Data-Analytics-see-newer-release-of-this-document-10-320.jpg)
D365 Finance & Operations - Data & Analytics (see newer release of this document)
- 1. 1 | P a g e What you need to know about Reporting & Analytics Dynamics 365 Finance & Operations Written By: Gina Pabalan Managing Director, Business Intelligence Edgewater Fullscope https://www.linkedin.com/in/ginapabalan
- 2. 2 | P a g e Table of Contents A. OVERVIEW 3 B. DEFINING THE BASICS 3 C. MICROSOFT’S APPROACH FOR REPORTING AND ANALYTICS WITH D365 F&O 5 EMBEDDED OPERATIONAL WORKSPACES 5 EMBEDDED ANALYTICAL WORKSPACES 6 EMBEDDED POWERBI.COM DASHBOARDS 6 OTHER REPORT AUTHORING TOOLS 8 CURATING DATA 8 SUMMARY OF OPTIONS 9 ENTITY STORE 10 WHAT IS THE DIFFERENCE BETWEEN AN “AGGREGATE MEASURE” AND “AGGREGATE ENTITY”? 10 ODATA CONNECTIONS 11 BRING YOUR OWN DATABASE (“BYOD”) 11 ENTERPRISE DATA WAREHOUSE (“EDW”) 12 D. IN CONTEXT OF YOUR D365 F&O IMPLEMENTATION 13 ASSESSING THE LANDSCAPE AND SETTING EXPECTATIONS 14 BUILDING REPORTING & ANALYTICS REQUIREMENTS WITHIN YOUR D365 F&O PHASE I IMPLEMENTATION 16 FULLSCOPE’S BI ACCELERATOR 16 E. UPDATES AND FEEDBACK 17
- 3. 3 | P a g e A. Overview There are many advantages and exciting promises of cloud-based computing, along with new challenges that we will face along the way. In regards to Microsoft Dynamics 365 Finance & Operations (“D365 F&O”) reporting and analytics, the same holds true. In this white paper, we will describe Microsoft’s out-of-box tools for reporting and analytics, define the various customer requirements and how these are met within the D365 F&O framework, address the specific skills required to deliver on each, and best approaches to serving complex data & analytical requirements. B. Defining the Basics Before we get started, it’s important to define the different terms used to discuss this hot topic: 1. Report Form – A business form such as an Invoice or Bill of Lading. Forms are developed using SSRS. 2. D365 Grid – This is a predefined “grid” of information displayed within the D365 application. A grid of information may be easily sorted and filtered. You may also export a grid data into Excel via OData protocol (note: size limitations apply, see section on OData). Grids are developed using X++.1 3. Paginated Report – This is typically a printed report with columns and lines of transactional data, possibly with totals and subtotals. Paginated reports are typically developed using SSRS. 4. Excel Export (“Export to Excel”) – this is when transactional data is exported into Excel for the purpose of serving a more exploratory business reporting requirement. In this case, Excel is both storing the data as well as authoring the report (note: size limitations and data security are key considerations). 5. Excel-based Report (“Open in Excel”) – This implies that Excel is connected to the D365 data set and being used merely as the reporting authoring tool. 6. Embedded Workspaces – these are dashboards viewed within D365. They can be either Analytical Workspaces or Operational Workspaces. (more on this later) 7. Analytics - Related to interacting with and visualizing data, leveraging aggregated or summarized data sets with the ability to slice and dice, and interactively drill into lists and individual transactions in a more ad hoc exploratory fashion. Analytics implies the use of dashboards and the ability to set up KPIs and metrics to visually understand where the organization is trending, and also to potentially use more advanced predictive BI capabilities to better understand the key performance drivers of the business and predict where it is heading. 8. Augmented Analytics – Related to leveraging Machine Learning (“ML”) and Artificial Intelligence (“AI”) used for the analysis of current and historical data to generate actionable predictions of future events. Augmented Analytics can also be used to automatically perform tasks that normally require human intelligence, such as speech recognition, decision-making, and translation between languages. Once the business’s reporting and analytics requirements are understood, there are two key considerations to determine in the design: Curating Data (how and where will the data be curated) Authoring Reports (what is the best tool to write the report) 1 In release 8.1, not yet available at this writing, users are expected to be able to expand, collapse (group by), see subtotals by group, and see totals in filtered or non-filtered views in form grids. The Excel style filtering in the grid by top row will return.
- 4. 4 | P a g e Although most people are very excited to see the output of business intelligence (the “authoring report” part), it is important to note that one does not exist without the other. Curating data correctly is critical to a successful reporting and analytics program. If we don’t get the data part right, there are consequences, like reports that take too long to run, system performance issues (impacting other parts of the system), inability to get at the required information, getting inaccurate information, displaying wrong level of granularity, inability to harmonize data with other sources, latency between a business need and the availability of a solution, etc. Understanding where to source and curate data, how to structure the data, what tools and skills are required to do this work are questions that should be considered, along with the proper report authoring tool, when embarking on a reporting and analytics initiative.
- 5. 5 | P a g e C. Microsoft’s approach for reporting and analytics with D365 F&O Microsoft understands that although most people interact with business applications daily, fewer than 22% of employees have access to analytical insights. Further, Microsoft intends to make PowerBI the new “Excel” for business users to federate analytics across the organization. With Microsoft Dynamics 365 Finance & Operations (“D365 F&O”) delivery of cloud-based ERP, the promise of delivering analytics to the masses has become a reality. And here in lies the opportunity. What is new in Microsoft Dynamics 365 Finance & Operations (“D365 F&O”) are Embedded Analytics. Embedded analytics empower and enrich the user experience. Within D365 Embedded Analytics, we are able to deliver an enriched user experience to all D365 users. There are three types of Embedded Analytics: Operational Workspaces, Analytical Workspaces (also referred to as “embedded PBi”), and Embedded PowerBI.com2 . Embedded Operational Workspaces Operational Workspaces help D365 F&O users manage and prioritize daily tasks and track items that require attention. Operational workspaces provide big picture statistics with drill through capability to the detailed transactions. An example is perhaps a tile that lists the number of unapplied customer payments, with a drill through to the associated detailed payments, so the associate can easily navigate to the list of payments requiring settlement. These workspaces directly access the D365 transactional data (also referred to as “D365 OLTP”, or “AxDB”) real time and are relatively easy to personalize. Microsoft delivers over 50 pre-configured Operational workspaces within D365 F&O that can be enhanced to meet specific business requirements. The underlying technology for these workspaces is native X++ programming language and embedded chart controls. It should be noted that users can create their own workspaces and enrich them with lists and tiles – even with the drill though capability. However, KPIs and charts require the D365 developer to create these visuals. 2 Embedded PowerBI and Embedded PowerBI.com are two different capabilities and are also implemented completely differently.
- 6. 6 | P a g e Embedded Analytical Workspaces Analytical Workspaces, also referred to as “embedded PowerBI,” deliver insights into the business, leveraging data summarized in charts, KPIs and beautiful PowerBI (PBI) visuals. These workspaces are intended to help users identify trends, relationships and anomalies expressed through data visualizations. Analytical workspaces leverage aggregated data sourced within the D365 Entity Store (also referred to as “AxDW”), and are designed to quickly analyze large volumes of data at once. The aggregated data in the Entity Store is updated from the D365 OLTP near real time. Microsoft delivers over 18 pre-configured Analytical workspaces within D365 F&O that can be enhanced to meet specific business requirements. These workspaces, developed using Embedded PowerBI, require data preparation, which is accomplished through the development of Aggregate Measures (which are then used to push data to the Entity Store). The creation of Aggregate Measures requires knowledge in proper data modeling design, X++, MDX3 and native D365 application configurations. Embedded PowerBI should not be confused with Embedded PowerBI.com Dashboards, which are explained below. Embedded PowerBI.com Dashboards In addition to the above two types of embedded workspaces, PowerBI.com dashboards can also be embedded into the D365 F&O form. This requires each report viewer to have a PowerBI Pro license (or Premium) in addition to their D365 F&O license, and is configured by the user, as opposed to an enterprise configuration. Any user who has both a D354 F&O license and a PowerBI Pro license can select the “Get Started” option (shown above in the Operational Workspace illustration), to quickly embed a PowerBI.com dashboard that they have access to. The data and dashboard are completely separate from the underlying D365 data, unless of course the D365 data has been first curated and surfaced through PowerBI.com. In this scenario, the D365 form is merely being used as a display for the PowerBI.com 3 The MultiDimensional eXpressions (MDX) language provides a specialized syntax for querying and manipulating the multidimensional data stored in OLAP cubes. MDX has become the standard for OLAP systems.
- 7. 7 | P a g e dashboard. There is no drill through into the D365 forms in this case. The data source for the PowerBI.com dashboard is not limited to D365 data, and can include data from any source that has been curated and surfaced through PowerBI.com. For example, the PowerBI.com dashboard shown below has been created using a separate PBI.com model file. In fact, the data contained in this particular dashboard is completely unrelated to the D365 data. With the Embedded PowerBI.com feature within D365, a user can quickly embed this Dashboard wherever the option for PowerBI is made available. PowerBI.com Dashboard Embedded in the Credit and Collections Operational Workspace (the same) PowerBI.com Dashboard Embedded in the Budget Planning Operational Workspace
- 8. 8 | P a g e It should be noted that this feature is not available to be made at the corporate level and is handled as a personalization by individual users. Other Report Authoring Tools Customers have more options for addressing operational and analytical reporting needs within D365 F&O. Again, one must consider both the reporting tool, as well as the data source, when developing a holistic approach for reporting. There are seven (7) standard report authoring tools within D365 F&O, and six (6) areas in which to source data. In addition to the two different flavors of Embedded Workspaces, the other five Report Authoring tools standard to D365 F&O are: 1. Management Reporter (“MR”) is the report authoring tool Business Users use to develop and generate financial reports. MR is included in D365 F&O licensing. MR leverages its own “data mart” which prepares the underlying OLTP data for consumption. This “data mart” is a black box, in that external data cannot be brought in, nor can it be modified in any way. In fact, most customers are not even aware that it’s there. Microsoft delivers the MR data mart to specifically serve the needs of reporting in Management Reporter. No other report authoring tools may access the MR data mart. 2. SQL Server Reporting Services (“SSRS”) is the tool IT resources use to generate pixel perfect paginated reports, with structured headers and footers that include columns and rows of transactional data, with subtotals and totals. SSRS is included within D365 F&O application. Microsoft delivers approximately 1,200 SSRS reports available with out-of-box D365 F&O. Customers are also able to write custom SSRS reports from within the D365 F&O application, connected directly to the OLTP data. Of course, an externally deployed version of SSRS can also be used to author reports, but it would be subject to the same constraints as other external report authoring tools mentioned in this white paper. 3. D365 Grid is a D365 form that has predefined “grid” of information displayed within the D365 F&O application. Once the grid is defined and developed by IT development resources, business users are able to easily sort and filter the live D365 data and even export it to Excel, with an OData connection. D365 grids also allow for some limited personalization by users to add or hide data fields. 4. Excel is considered an analytical tool used by Business Users that allow for tabular reporting and data exploration. 5. PowerBI.com is considered an “analytical” tool used by IT and business users that allow for data exploration and visualization. Generally, PowerBI.com is used over an aggregated, or summarized, data set. The degree of aggregation is dictated by how the underlying data has been modeled. Data may be ingested into PowerBI.com directly, or a “Direct Query” method against an external data source may be used. Any PowerBI.com dashboard can be displayed within D365 forms, as discussed above. Curating Data The curation of data is a key inflection point in determining your overall reporting and analytical strategy. There are six (6) different places in which to source data when authoring a report or visualization. Not all report authoring tools may connect with all data sources!
- 9. 9 | P a g e The six potential Data Sources are: 1. D365 Transactional OLTP Database, “AxDB” (not available to external report authoring tools)4 2. D365 Data Entities within AxDB (available to external report authoring tools via an OData connection). There are two types: a. Aggregate Data Entities, or simply “Aggregate Entities” – for aggregated data b. Standard Data Entities, or simply “Standard Entities” – for transaction level data 3. Management Reporter Data Mart (only serves Management Reporter for report authoring) 4. Entity Store, “AxDW” (only serves Embedded PowerBI for report authoring) 5. BYOD (Bring Your Own Database) – secure Azure SQL database with no access restrictions 6. Enterprise Data Warehouse (“EDW”) – secure Azure or On-Prem Data Warehouse with no access restrictions Summary of Options The following is a table and illustration of options for Data sourcing and report authoring for D365 F&O: 4 Sometimes confusingly, access to the D365 OLTP database is available in some NON Production D365 F&O environments. This should be considered in the design and implementation of reporting. 1 2 3 4 5 6 Report Authoring Tool Authoring Technology D365Transactional OLTP("AxDB") D365DataEntities (Standard& Aggregated) Management ReporterDataMart EntityStore ("AxDW") BYOD EnterpriseData Warehouse Embedded Workspace - Operational View X++, Chart Controls l l Embedded Workspace - Analytical View Embedded PBi l Management Reporter MR l SSRS SSRS l l l l D365 Grid X++ l l Excel Excel l l l PowerBI.com PBi l l l l through Odata Connection only Data Source
- 10. 10 | P a g e Entity Store The Entity Store, which is named “AxDW” within D365, serves Embedded PowerBI/Analytical Workspaces. The Entity Store is a Clustered Column Store Database, separate from the OLTP, and as such, data is “near” real-time. At this writing, the Entity Store is only available to be refreshed as a full load. Incremental refresh is in an early Microsoft preview program. It is anticipated that once the incremental load is available, the Entity Store can be updated as “Low Priority” to refresh every 15 minutes, or “High Priority” to set up every 1-5 minutes5 . In order to populate the Entity Store, “Aggregate Measures” must first be configured with the D365 application. Conceptually, this is similar to building OLAP cubes, but less complex when using the D365 Aggregate Measure options. If more complex features are required, such as building out complex calculations, MDX language (calculations and scripts) may also be used to augment out-of-the-box features of building Aggregate Measures. Aggregate Measures provide the definition, or data model, for the Entity Store. The creation of Aggregate Measures requires knowledge in data modeling design, X++, MDX and native D365 application configurations. At this writing, there are 52 out-of-box Aggregate Measures within Dynamics 365 F&O that are used to publish data to the Entity Store. Aggregate Measures are different from Aggregate [Data] Entities. What is the difference between an “Aggregate Measure” and “Aggregate Entity”? In addition to providing definition for the Entity Store, Aggregate Measures also provide the definition for the Aggregate [Data] Entities. We must first define and create an Aggregate Measure before we can 5 We recommend setting the Entity Store update on Low Priority – as every 15 minutes should meet most reporting needs. Setting this at a High Priority may create excess batch processes to keep the Entity Store updated and could possibly delay other operational batch processes. Microsoft states that in case of very high system utilization (ex. due to extreme refresh schedules), the Microsoft operations teams will advise the customer on managing load.
- 11. 11 | P a g e create an Aggregate Entity. The Aggregate Entities reside within the OLTP (AxDB), so access to the data is in real time and since it may access transactional level data, non-clustered column store indexing is used to return data more quickly when a query is executed. Aggregate Entities can be useful for “Pie Charts” and other visuals when working with Embedded Operational Workspaces. Aggregate Entities can also be accessed via OData from PowerBI.com, or even Excel. At the current writing, there are 11 Aggregate Entities delivered out-of-the-box with D365 F&O, 5 are finance-specific and 6 support the Retail module: BudgetActivityEntity BudgetAmoutnbyPeriodAggregateDataEntity BudgetPlanActivityEntity LedgerActivityEntity LedgerAmountsByPeriodAggregateEntity RetailTransDetailsADE RetailTransDetailsNoItemIdADE RetailTransDiscountedADE RetailTransInvoicedADE RetailTransPriceOverridesADE RetailTransVoidedADE Embedded PowerBI (aka, Embedded Analytical Workspaces) uses Aggregate Measures, NOT Aggregate Entities! OData Connections Open Data Protocol (OData) is an open integration protocol developed by Microsoft and recognized as a global standard, for querying and updating data and is built on standardized technologies such as HTTP, Atom/XML, and JSON. Unless the BYOD is leveraged, OData is the only way to connect with D365 data from external report authoring tools. Further, access to D365 F&O data via the OData protocol is only available through the Data Entities (either Standard Entity or Aggregate Entity). Access to the underlying transactional D365 tables is not available from external report authoring tools, including PowerBI.com. The OData protocol limits transfer to 10,000 records at a time6 . If using an external report authoring tool (Excel or PowerBI.com, connecting directly to the Data Entities), and running reports with data volumes exceeding 10,000 records, the report will not be performant. Bring your own Database (“BYOD”) BYOD is an Azure SQL database that is used as a data store for transactional level D365 F&O data. D365 F&O customers are licensed for BYOD, however an additional Azure subscription will be required. The BYOD has no Microsoft driven limitations in terms of data access, and is available for all external report authoring tools, including PowerBI.com, Excel or SSRS (external). BYOD is built leveraging the Data Management Framework and supports large batch D365 F&O data exports. To set up the BYOD, D365 F&O Standard Data Entities must be configured to incrementally export the D365 F&O transactional data (AxDB) into the customer’s own Azure SQL data store (BYOD). It is recommended that customer’s create custom Standard Data Entities as opposed to the out-of-box Standard Data Entities that are delivered with D365 to create the BYOD. The out-of-box Standard Entities were developed with data import in mind, not data export and reporting. For example, the out-of-box Standard Entities include ALL the underlying attributes within a table. In a reporting scenario, one would not need all the fields within all the required tables. Further, the out-of-box Standard Entities are not set 6 Release 8.1 which is not yet available, is expected to address this limitation. This white paper will be updated when this is available and verified.
- 12. 12 | P a g e up for incremental load. In a real world scenario, we will want the BYOD to load incrementally, especially as the underlying transactional dataset grows. Further, the out-of-box Standard Entities have been de- normalized, which will create data redundancies within the BYOD and cause other issues as addressed below. Either way, the creation of custom Standard Entities is quite simple (as compared to creating aggregate entities), however it does require an X++ developer, SDLC (Software Development Life Cycle) and deployment like any other D365 modification. The Standard Entity should be architected to meet the specific needs of the customer. And it is recommended to design for the future (and often unknown) reporting and analytics needs of the business, vs taking a one-off kind of approach. A more normalized data set within BYOD supports future scalability, flexibility, and a reduction of data and query redundancies, and results in more efficient data storage, reduced cost and reduced risk. Aligning the Standard Entities to the underlying OLTP tables promotes flexibility and data transformation transparency if the BYOD is to be used as a data source to support a more structured data modeling effort – such as, but not limited to, a data warehouse scenario. This approach makes it much easier for IT staff to build SQL based reports for other needs outside of the “current” report requirement, and reduces the risk of “entity proliferation.” If a transformed, de-normalized data set is used to push data to the BYOD, the data transformation is “veiled” in the underlying code within D365, plus it results in data redundancy within the BYOD - which could become a limitation over time. In addition, certain system fields such as RECID, etc. would not be exposed, limiting the tables which can be joined to the de-normalized entity. We also want to reduce the risk of the proliferation of data entities. For example, a customized entity could be created for the specific report requirement, providing all the fields and logic necessary within that one entity. That would not only result in data redundancy, but could lead to the proliferation of single purpose entities, and wouldn’t give the customer the ability to easily write their own reports or queries for other purposes. This is a significant risk in how customers may choose to meet specific reporting requirements during the throes of a D365 F&O implementation. If the customer requires an Enterprise Data Warehouse (“EDW”), BYOD will be used to facilitate the transfer of information. BYOD does not connect via OData, which would be quite limiting with the larger data requirements required to support transactional level table updates and data warehouse integration. Enterprise Data Warehouse (“EDW”) Organizations that have a high level of data diversity, such as multiple line of business systems, additional ERP applications, additional applications interfaced with D365 F&O, or that have complex data and analytical requirements, an Enterprise Data Warehouse may be part of the overall reporting and analytics strategy. The EDW may be platformed in Azure SQL, Azure Data Warehouse, SQL Server or a variety of other potential platforms. The EDW becomes an IT-controlled and managed, governed corporate data set that serves the broader reporting and analytical needs of the organization. The EDW will store transactional level details, and become the one source of the truth for building semantic models or serving structured, simplified and harmonized data to tools like PowerBI, Excel or even SSRS. The EDW data architecture is designed to optimize reporting (i.e. read operations), not transaction processing (i.e., write operations), which is a completely different framework for storing data. The benefits of the EDW are:
- 13. 13 | P a g e If multiple source systems are in play that require data harmonization for the purpose of reporting, transforming this data through more standard Microsoft ETL capabilities will result in less risk, less cost and a higher degree of adaptability (required for BI). Creating reports and analytics sourced from a structured, simplified and harmonized data set will allow more mainstream users to explore the data and build data literacy, allowing more individuals in the organization to obtain business value from it. The result is that reports are simpler to build, empowering the average user to dig into the data, build their own reports, analyze new information, and make discoveries not thought of previously. Generating reports and analytics sourced from a structured, simplified and harmonized data set will allow reports to run more quickly and efficiently. Common data transformations such as standard costing, currency conversions, unit of measure conversions, and other business approved and validated calculations are all built into the EDW, ensuring that reports are truly displaying the expected results, versus having multiple reports implement the various conversions and calculations in differing ways. This ensures data quality and consistency throughout. The Dimensional Model design of the EDW allows for the implementation of slowly changing dimensions, displaying the state of the various transactions and attributes exactly as they were at that point in time. Allows for better snap shot capabilities, such as inventory snapshots, account payable aging snapshots, sales pipeline snapshots, etc. Decoupling the data management platform that serves reporting & analytics from the transactional system that serves day-to-day transaction processing allows the BI journey to evolve in a more agile manner. As data literacy grows, key models evolve and requirements are better defined. Implementing select corporate BI data models within the D365 platform will be easier, resulting in less rework, cost and risk. Lastly, the EDW does not replace the operational reporting and embedded analytics within D365 F&O. It augments it, and in some cases, will enhance it. D. In Context of Your D365 F&O Implementation Now that we have most of the technical considerations explained, let’s consider all this in terms of your D365 F&O ERP implementation. The primary goal of your D365 F&O implementation may be to implement a flexible, cloud-based enterprise business application that enables the organization to adapt to changing business needs, fuel innovation and take advantage of technical advancements. Part of this may even be to improve data literacy throughout your organization or to even establish a foundation for a future analytics program. Implementing a new ERP system consumes significant resources: time, money and overall energy of the business. During the implementation project, your team and the overall business will be very focused on the basic blocking and tackling of business process transformation and marching towards a “go-live” date. After all, when the new system in turned on, you will need to be ready to take customer orders, ship products and invoice your customers. But we also know there will be baseline reporting capabilities required to be in place from Day One.
- 14. 14 | P a g e Foundational decisions should be made at this stage and since there are different ways to achieve the same result, one might want to consider the bigger picture verses making reporting decisions one report requirement at a time (such as “which reporting tool?” and “where is the data sourced?”). We want to avoid making short term decisions at the expense of serving long term goals. Further, BI fuels much excitement with your business leaders, and it may be easy to get side tracked with “BI” requests. It will be important to keep your eye on the ball implementing a new transaction processing system, manage expectations and cost, and avoid future surprises. Assessing the Landscape and Setting Expectations When D365 F&O is put into production, the business will not want to step back from where they are at today with reporting and analytics. So, it is important to understand the organization’s current level of BI Maturity, Application Landscape, as well as the Organizational Alignment that serve the business’ reporting & analytics needs. And then consider these in terms of D365 go-live goals and future end-state goals. For each question below, consider these in terms of current state, at D365 F&O go-live, and aspired end state: BI Maturity 1. What is scale of your analytical capability? Individual (s) Departmental Enterprise 2. What is the use of data in the organization (all may apply)? Corporate Reporting Ad-Hoc/ Exploratory Dashboards & Visualizations Advanced Analytics (predictive, AI) 3. What is your Data Infrastructure? Reporting from transactional systems only Spreadsheets Independent Data Marts Enterprise Data Warehouse Big Data Eco System 4. How does your organization think about data (“Data Culture”) Tactical Mission Critical Strategic Application Landscape How many source systems or other data sources are required? Is there a need to merge, or harmonize data from multiple source systems? To what extent will you need to harmonize historical transactional data with D365 data? Are applications running on-premise, in the cloud or both? What Report authoring tools are/will be used?
- 15. 15 | P a g e Organizational Alignment 1. What is the business geography? Single location Multi location – US Multi location – North America Multi location - Global 2. Who is the Business Executive champion for delivering analytics within the organization? CEO CFO VP – Business Unit CIO 3. Is there a Data & Analytics team (BI Competency Center)? 4. Who manages and controls Master Data, does this occur in a systematic way, or ad hoc? 5. What is the break out of mainstream users (expecting IT to author reports) vs the Business Analysts & Super Users (desiring a more ad hoc approach for reporting)? And is there a goal to trend towards the latter? 6. What is the overall level of data literacy within the organization?
- 16. 16 | P a g e Building Reporting & Analytics Requirements within your D365 F&O Phase I Implementation The business users require information to execute their jobs, to make decisions, to report to governmental agencies, etc. Sometimes this information is critical to day-to-day operations of the business, regardless of the ERP system used or where that information comes from. The next step then is to inventory the current reporting & analytical needs of the business. The goal here is to not reproduce every report that exists in the legacy ERP environment. The goal is to understand at a high level, the holistic informational requirements of the business, especially but not exclusively as it relates to the Phase I D365 go-live. At this point, we are not considering the optimization of enterprise analytics, we are looking to meet the critical and must-have requirements for the Phase I implementation. The following is a list of important attributes to understand about each informational requirement. Once the inventory is built and these attributes known, a recommendation can be made as to where the data is sourced (curated) and what report authoring tools are best. For each reporting or informational requirement, identify: 1. Usage – Individual, Departmental, Business Unit, Enterprise 2. Output Type – Document, Paginated Report, Excel, No Print/Screen (i.e., PowerBI, D365 Grid) 3. Info Type – Statutory, Operational, Analytic, Exploratory 4. Data set size – Data sets over 10,000 records should be noted 5. Level of Complexity – Joining data from multiple areas within D365 or multiple systems or complex calculations? 6. Single source D365 or multi-source data? 7. If Multi-source, name Sources. 8. Priority – critical for Phase I go-live, must-have, or nice-to-have? 9. Frequency – how often is the report run? Multiple times a day? Once a day? Once a month? 10. Data Refresh (Currency) – up to the minute, 15 minutes, 4 hours or EoD (end of day) If taken as a whole, we can minimize ambiguity and put a winning strategy in place that will meet expectations and maximize time and investment returns, while building a solid foundation for a future, more comprehensive analytics program. Fullscope’s BI Accelerator Fullscope is committed to delivering on the promise of embedded analytics within D365 F&O. We also recognize that some clients will have a high level of data diversity and/or more complex data requirements. Fullscope’s BI Accelerator is a data management solution that helps D365 F&O clients curate D365 F&O data, as well as harmonize it with other sources in preparation for reporting and analytics. 1. 100% Microsoft Stack 2. Azure or On-Premise 3. Baseline BYOD (including Standard Entities) for supporting an Enterprise Data Warehouse architecture 4. ETL Automation for agile delivery of your BI solution, and a short learning curve to promote self- sufficiency 5. Baseline D365 Enterprise Data Warehouse to jump start your project 6. Supports ALL report authoring tools that can consume SQL, SSAS OLAP or SSAS Tabular data 7. Affordable with a high ROI
- 17. 17 | P a g e E. Updates and Feedback This white paper has been written based on currently available capabilities of Microsoft Dynamics 365 Finance & Operations. Product updates and enhancements are consistently being pushed out to the market. Therefore, look for regular updates to this document. Feedback may be sent directly to gina.pabalan@fullscope.com, or find me on LinkedIn.