Defining a reporting strategy

Organizations rely on reporting and business intelligence to drive decisions in the organization. Sometimes, government and industry standards drive reporting needs. For example,

• Executive management requires dashboard reports and key performance indicators (KPIs) to drive strategic decisions for the business, oversee how the organization is performing, 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, inventory the reports that the business uses to make key decisions to help determine the overall reporting strategy.

Once you have an inventory of these reports, create a matrix categorizing the user roles and 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 frequently the data needs to be delivered. Your research outcome affects configuration decisions such as report scheduling settings, agent schedules, and refresh strategies on data pages. Other factors, such as currency requirements, may play a role in your strategy. For example, you may have a data page that contains exchange rates. This data needs to be current on an hourly basis. Also, the report that sources the data page must have a refresh strategy.

Related to frequency is the question of data storage and availability. The answer influences how you architect a data-archiving or table-partitioning approach. Implementing a data-archiving strategy and partitioning tables can help with the long-term performance of your reports.

This question is related to who needs the data and what is the purpose of the report. Existing reporting requirements influence what data the report must contain. As you research the need for each report, you may find the report data is not needed at all. For example:

• You may 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 may 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 may 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 accessing data for reports, you need to know which table has the data and how it is mapped. In some situations, you want to join multiple tables to access the data. Pega provides different options such as join, association, declare index, and subreport options for the data. As a lead system architect, LSA, you need to decide which joining mechanism will perform 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 cases. You match the operator identifier in the case database table 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 case data table with the case identifier in the history table.
• Subreports
  • Subreports can be defined in classes different from the main report.
  • Subreports can be used to filter results. This approach allows you to include or exclude data.
  • Subreports can be used to display aggregate calculations on specific rows in a list report.

Although Pega offers powerful reporting capabilities, also consider alternatives to traditional reporting and data warehousing approaches. 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. Or, if you are using data for analytics, consider using adaptive and predictive decisioning 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 growth in popularity of big data and NoSQL databases, a freeform search is becoming more common.