Running and Creating Reports

In SAP Fieldglass, users can execute various reports to monitor metrics related to their external workforce program, such as the number of open positions, headcount, or the status of services projects, just to name a few. Standard reports are the go-to for users who want to see more commonly requested data sets quickly, like a headcount report or an overview of their project spend to date. Custom reports can be built in order to tailor data analysis to specific and detailed needs to provide granular and personalized insights. Whatever the method, running and executing a report can help provide helpful data needed for informed, data-driven decision-making.

In SAP Fieldglass, reports are typically created for a variety of audiences at different levels, including executives, Human Resource employees, the Program Office, Hiring Managers, and even Suppliers. Generally, executives will want to see the "big picture" value of a Program, while the Program Office will want to ensure high productivity and low cost. Hiring Managers are often looking for detailed information on their own workers, and suppliers want the relevant information to make sure they are performing well in providing hiring managers with quality external workers and services projects.

So when you embark on creating or running reports, it’s important to consider that different audiences have different needs. Thus, before a report is provided, it’s important to consider the goal of the report: What is the reason for this report? What business decisions will be made, or what questions are to be answered from the data?

Of course, these questions are linked to the audience for the report, but nonetheless, as Brian is asking these questions, he should continuously narrow the scope of the report to produce only the output necessary to achieve the desired goal.

If, for example, he needs to provide a report on the breakdown of worker status by site, he might consider creating separate reports for contingent workers and SOW workers, or decide to make separate reports for each site, as opposed to a comprehensive report of 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 someone’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 to Users to run as-needed?

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 reports 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’d select Work Order as the base module. Of course, his first inclination may be to use Worker as the Base Module since it’s 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.

Considering the procurement workflow, Brian will want to choose the module that’s furthest along in the process to get the most relevant and accurate data.