Defining a reporting strategy

Organizations rely on reporting and business intelligence to make informed decisions. In some scenarios, government and industry standards drive the need for reporting. For example: 

• Executive management requires dashboard reports and key performance indicators (KPIs) to make strategic decisions for the business, monitor the organization's performance, and take action based on that data. 
• Line-level managers need reports to ensure their teams meet business Service-Level Agreements (SLAs). 

When defining a reporting strategy, it is important to inventory the reports that the business uses to make key decisions, which can help determine the overall reporting strategy.

After you inventory these reports, create a matrix that categorizes the user roles and the reports each role uses to make business decisions. For example, you may create throughput reports for various users. 

• Line managers use the reports to show the throughput of team members.
• Managers use reports to optimize the routing of assignments.
• Executives may want to see a summary of throughput over specific periods. The reports enable the executives to drill down into the results of individual departments and plan staffing requirements for these departments in the coming months.
• Individual team members can see their own throughput metrics to gauge how close they are to meeting their own goals and to work toward their incentives.

Identify how often the data needs to be delivered. This information affects configuration decisions such as report scheduling settings, agent schedules, and refresh strategies on Data Pages. Other factors, such as currency requirements, might also play a role in your strategy. For example, you might have a Data Page that contains exchange rates, and this data requires hourly updates. In this example, the report that sources the Data Page requires a refresh strategy. 

Data storage and availability are also important considerations related to frequency. The answer to these questions influences how you architect a data-archiving or table-partitioning approach. Implementing a data-archiving strategy and partitioning tables can help improve the long-term performance of your reports.

This question is related to who needs the data and what the purpose of the report is. Existing reporting requirements influence what data the report must contain. When you research the need for each report, you might find that some of the report data is unnecessary. For example: 

• You might discover that no one in the organization reads the report or uses the report as the basis for any decisions.

On the other hand, you might find opportunities to provide new reports. For example:

• A department cannot create a necessary report because the current business process management system cannot extract the data.

Pega Platform offers several options for gathering report data within the application. The strategy that you recommend depends on the reporting that you are doing.

• If the organization requires heavy trending reporting and business intelligence (BI) reporting, a data warehouse might be a better fit.
• If you want to display the status of work Assignments on a dashboard in the application, report definitions with charting are appropriate.

When you access data for reports, you need to know which table has the data and how the system maps it. You want to join multiple tables to access the data in some situations. Pega Platform provides different options for the data, such as join, association, declare index, and subreport options. As a Lead System Architect (LSA), you must decide which joining mechanism performs better to extract the required information. For example, use:

• Case and Subcase relationships to show Subcase data along with the parent Case data.
  • List the purchase orders in a purchase request. You match the Case identifier in the parent purchase order class to the Case identifier in the child purchase request class.
• Case and Assignment relationships to show how the system processes Assignments for a specific Case or a Subcase.
  • Show the operators working on specific Case. You match the operator identifier in the database table of the Case with the operator ID column in the Assignment table.
• Case and history relationships to monitor performance.
  • Show the total amount of time required to resolve specific Cases. You match the Case identifier in the data table of the Case with the Case identifier in the history table.
• Subreports
  • Subreports can use class definitions that are different from definitions of the main report.
  • Subreports can help to filter results. This approach allows you to include or exclude data.
  • Subreports can help to display aggregate calculations on specific rows in a list report.

While Pega Platform offers robust reporting capabilities, it is important to consider alternative approaches to traditional reporting and data warehousing. These approaches may be the best way to meet your reporting requirements. For example, you can use robotic automation to gather data from external desktop applications. If you use data for analytics, consider using adaptive and predictive Decision features. If you need dynamic queries, you can also use freeform searching on text, such as Elasticsearch, instead of constructing a report definition to gather the data. With the increasing popularity of big data and NoSQL databases, freeform search is becoming more common. 

Check your knowledge with the following interaction: