One of the topics that has been an on-going discussion all the way during my 25 years with NAV has been how to deal with different report requirements. Like any other maturing industry, there are different fractions of believers when it comes to best practices around Reporting, Performance Management and Business Intelligence.
Microsoft has been investing quite a bit in new Business Intelligence features, new ways to intuitively search for data in a dialogue string way like “What was the Revenue in January 2014 in Germany” where the key words detected are “Revenue”, “January 2014”, “Germany”. Based on this, the system is able to find the information for you.
Historically the report designer inside NAV has been commonly used to create reports. However, it has also always been tricky to make reports where there is a need for joining data from many tables unless you are very familiar with the report designer. One of the biggest challenges making reports from ERP systems is to figure out where to find the right data and which tables to combine to provide the required data. An ERP system can have thousands of tables in a relational database, and it is just not easy to navigate within unless you are a real reporting specialist. As an example, a typical NAV 2009 database has just around 1,000 tables. A traditional user will get lost in complexity. That is one reason why reporting from a relational database is not optimal.
Another element in reporting is to work with calculated measures consistently between users and reports. If the measurement has to be made in the report there is the risk that different reports are using different filters or users are calculating the measurements based on different methodologies causing inconsistent reports and reporting. Have you ever sat in a meeting trying to figure out what the right number is, because two participants came with different versions of the truth?
When I discuss Business Intelligence with a company, it often starts by the company asking about front-end tools. There is a lot of confusion about what front-end tools can do and if it runs directly on the NAV database, in a data warehouse and if there is a need for cubes or not. There are also good and relevant questions about what data can do and if a tool with an “in-memory” database is a better option?
However, the underlying success to improved reporting is not a question of front-end tool selection because this comes much later. To establish a successful reporting platform you need to understand the company’s conceptual business data-model and you need to understand the user roles.
If you have reports that join tables or merge multiple data sources, then you will typically benefit from having a data warehouse – or just call it a reporting database. A reporting database is structured for fast reporting that match the business logic and only contains the tables required for the reporting. The logic built for reporting is a lot easier to navigate in for the user. There are a lot of intelligence and consistency built into the system, which are enabling users to create better reports faster. If you also add a cube, you can make consistent measurements and faster reports.
When I meet new companies wanting to implement Microsoft Dynamics NAV, internationally improved reporting is often one of the key drivers. In addition, a consistent NAV implementation can provide efficient consolidation data out of the box, but if you also want to introduce performance management to your organization make sure to think about how you want information out of you improved systems.
Make sure to make an informed decision about your reporting strategy and do yourself the favor to start on neutral ground before jumping into a specific front-end tool. It will save you lots of money to select your reporting structure before selecting your front-end tool. It does not take more than a day or two to get a good overview of the possibilities and to create the direction for your next big achievement; Improved business insight.
If you have already a clear view on what you want and your real requirement is a front-end selection, then there is a good scorecard process available for that. The information about the different front-end tools like Qlikview, Tableau, BI4Dynamics, Cognos, Jet Reports etc. is already consolidated we only need to add what is most important for you in order to make the match in the scorecard.
If you want to know more on how to get on the path for improved business insight, let me know and I will be happy to help.
Latest posts by Henning (Posts)
- Why you could fail at implementing ERP in your subsidiaries - July 11, 2014
- 4 steps to start bridging business and IT - June 20, 2014
- 10 tips for ERP across borders - June 3, 2014