Technical Blog Post
Abstract
BiLog: The Best...V7 Best Practices Data Analysis Options
Body
Have you ever been the best? The best runner in a race, the best student in your class, or the best Scrabble player? While I’ve never had the chance to stand on that best podium, I’ve come pretty close with a second place showing in a local Apple Pie Baking Contest!
At work, we often talk of best practices - excellent processes or functionality used by a variety of individuals and businesses. During IBM’s Pulse 2012 conference, in addition to highlighting two of the popular report features in Version 7.5, which were QBR Edit and and Email URL, we also talked extensively about reporting best practices.
The three best reporting practices highlighted were:
(1) Evaluate All Data Analysis Options
(2) Invest in Report Object Structures
(3) Engage in On Line Resources
The three best reporting practices highlighted were:
(1) Evaluate All Data Analysis Options
(2) Invest in Report Object Structures
(3) Engage in On Line Resources
Today, I want to highlight the first best practice of evaluating all data analysis options in more detail. The initial Bilog entry written a year ago, detailed the various ways you can analyze data within the Version 7 portfolio. Each of these unique features from data download to result sets, application exporting, KPIs and Ad Hoc reporting - can enable your users to quickly analyze data thru export to other tools, visually or thru immediate display of data.
In contrast, the process to create a custom report can be time consuming and resource intensive. To highlight this, the example of a user requesting an Overdue Work Order custom report was used at Pulse. To create this report, the user and the designer must first sketch out a report, and agree on its content. This information is written down in a report specification, which is then turned over to a report developer. The developer interprets the specification, develops the report, and then turns it back to the designer. The designer may require changes to the report, or change its design after viewing its output. Once the report is agreed upon, it is turned over to the tester, who may find issues, send it back to the developer, whew!, and then back to the tester. And finally, the report is imported, granted security access, and maintained by the administrator.
This iterative process of creating a custom report involves a significant investment in time and resources. Before you invest in custom reports, the best practice would be to first evaluate each of the other data analysis options to see if they can meet the user’s needs. Using our example, you can quickly create an application query for Overdue work orders, and use the data download to immediately export the results to Microsoft Excel. Or take that same query, and export additional fields thru Application Exporting or Ad Hoc reporting. Or you could quickly create visual indicators of the data thru KPIs or Result Sets.
You can learn more about the data Analysis best practice by reviewing the video recording of the Maximo Version 7 Reporting - Features and Best Practices You Tube Video located here
You can also find more details of the V7 Data analysis options available on this wiki page, or from the Report Upgrade Planning guides, which give additional screenshots, details and examples. The guide for Version 7.1x can be accessed here and the Version 7.5x can be accessed here
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
UID
ibm11134189