The implementation teamwork of Microsoft Dynamics 365 for Finance and Operations should challenge the management's reporting needs in the analysis phase of implementation, with a particular focus on exploring the data required to build reports. These data requirements should then be cross-checked with the real data entry activities that end users will execute to ensure that business users will get vital information from the reports.
On several projects, there are no well-defined reports except the financial reports (trial balance, income statement, and balance sheet) that are in place during analysis. Later, for live operations on such projects, the implementation team determines the need for more data and starts chasing the required information inside the application by completing the missing information fields, and/or redesigning the data entry process. This may lead to an increase in the data entry time due to additional steps for data validation and the surprise discovery that there are not enough end user resources to execute the updated requirements. Hence, there should be a balance between the sum of required data entry values that directly affect the reporting quality, and the total number of end user resources that perform the data entry process.
Another word of caution is that during the operation, the solution architect may recognize that some transactions are performed by one end user, but, typically, these transactions are performed by two or three end users to attain the segregation of duties and control. For example, in the procurement cycle, there is one user who creates the inventory item, purchase order, and reception, but these transactions are normally performed by three different users. In this kind of resource-constrained situation, the segregation of duties and control concepts are breached, and the ERP solution is negatively impacted for the end users and key users. In these situations, the root cause of the concern is not the functionalities of ERP, but the lack of allocated resources.
The two other important models of reporting are as follows:
- Pulling reports: The pulling of reports refers to the active requesting of reports by operational managers for the lowest transactional level, such as purchasing, warehousing, sales, marketing, and financial entries. The middle management layer will pull reports to serve procurement, commercial/sales, and controllership.
- Pushing reports: The pushing of reports refers to the business intelligence (BI) capabilities that serve the top management, such as offering KPIs, balance score cards, and analytics/comparison views.
The various reporting levels of Microsoft Dynamics 365 for Finance and Operations are shown in the following diagram:
Microsoft Dynamics 365 for Finance and Operations and the supporting Microsoft technology stack offer a diversity of reporting capabilities, including ad hoc reports for the transactional level, developed by Microsoft Excel 2013, Excel Services, and Microsoft SQL Server Analysis Services (SSAS). Microsoft Dynamics financial reporting (also known as management reporter) offers the controllership in the middle management the ability to create and run financial reports. For the BI solutions built for Microsoft Dynamics 365 for Finance and Operations, customers should begin with Excel Power View, SSAS, and Power BI tools. The different levels of management are as follows:
- Operational management: The operational managers are involved in monitoring the performance of each business unit and managing employees
- Middle management: The middle managers are focused on the internal firm's performance, including revenues and costing management, resource allocation, and the development of short-term plans
- Top management: The top managers are focused on strategic business decisions that affect long-term plans, future performance, and the firm's overall objectives