In SAP Fieldglass, reports are typically created for various audiences at different levels, including executives, Human Resource employees, the Program Office, Hiring Managers, and even Suppliers. Before running a report, those audiences, their needs, and the data they require must be determined.
There are basically two considerations you must make before entering SAP Fieldglass to run a report:
- The goal of the report and,
- The module that is being reported on.
The Goal of the Report
When you create and run reports, it is important to consider the goal: What is the reason for this report? What business decisions will be made, or what questions are to be answered from the data?
If, for example, Brian, who manages the worker procurement program for WorkingNet Networking Inc., a manufacturer of data networking equipment, needs a report of all active workers by site, he could run separate reports for contingent workers and SOW workers, or he may decide to make separate reports for each site, as opposed to a comprehensive report comprising all workers at all sites.
Brian should also determine how the recipient will receive the report before getting started.
- Should the data be readily available on a user’s homepage?
- Should it be scheduled to deliver via email on a recurring basis?
- Should it be sent to a server over SFTP?
- Should it be available for Users to run as-needed?
The Base Module
Once Brian has a solid understanding of the report design and data needs, he will then need to determine the Base Module, which is the first item that must be selected when creating a report. The base module determines where the report’s data will come from, and what data elements are available to include.
In SAP Fieldglass, data flows downstream. When selecting the base module for a new report, you must think about the chronological order of the workflow. For example, if Brian wanted to create a report to track the number of new hires that failed onboarding by each supplier, he would select Work Order as the base module. His first inclination may be to use Worker as the Base Module since it is a report on new hires, but in a transactional workflow the worker comes after the work order, meaning not all work orders turn into workers. Choosing Worker as the base module in this case could mean that the report output would not include new hires that failed onboarding and never registered as a worker in the application.
Considering the procurement workflow, Brian will want to choose the module that is furthest along in the process to get the most relevant and accurate data.