Use of APD(Analysis Process and Designer)

Everyone who worked with BI 7.0 knows that Analysis Process Designer (APD) is a workbench for creating, executing, and monitoring analysis processes. The analysis process is primarily based on data that was consolidated in the Data Warehouse and that exists in InfoProviders. One of the applications of APDs from a technical point of view would be feeding query results into a DataStore object or an attribute of a characteristic. In this post I review a few examples on how consultants may use APDs for addressing particular analysis tasks.



Analysis Process Designer allows you to set up a model where you move data from source to target and do some transformations on the way. As a source we can use any InfoProvider in the data model. The following types of data target are available in the Analysis Process Designer:

● Attributes of a characteristic

● DataStore objects

● Files

● CRM attributes

● Target groups for SAP CRM

● Data mining models:

○ Training the decision tree

○ Training the clustering model

○ Training the scoring model (regression)

○ Training data mining models from third parties

○ Creating association analysis models


1. Examples of business applications
1.1. ABC classification for customers

In ABC classification we assign customers to certain categories based on business rules. For example, you can classify your customers into three classes A, B and C according to the sales revenue or profit they generate. When you choose ABC classification in APD you have to specify the characteristic for which the classification is to be performed, its attribute, key figure, appropriate query, and threshold values for the individual ABC classes.
1.2. Scoring (traffic light) model

In a number of BI scenarios we may have a requirement for generating scoring or traffic light indicators for a certain set of KPIs. We may want to know, for example, how close the actual value is to the budgeted one. A range of traffic lights (red/yellow/green) needs to be displayed by geography, product group, profit center, etc.



Traffic light indicators need to be assigned to each report line based on a complex logic. For example, if one or two countries in the region are underperforming, region’s indicator is set to yellow. If more then two countries are underperforming region’s indicator for the analyzed period should be set to red.



As values for traffic light indicators are not cumulative they have to be calculated separately for each level of granularity. Knowing indicators at the lowest level of granularity does not help much in deriving them for upper levels, as there is a business rule defined for each level separately. Therefore, we have to build a set of queries for each level of data model where traffic light indicators need to be displayed. APD would help us feeding query results into the cube reporting on scoring results.


2. Example of data flow for scoring model

The following data flow model can be used for calculating scoring results. The infocube contains measures (KPIs) used for scoring, such as sales volume and sales budget. It also has a set of traffic light KPIs that need to be populated with indicators for each granularity level.


3. Why using APD in the scoring model

It is important to note that in the scoring model instead of APD/Query approach one can use a transformation (formerly known as an update rule) connecting cube to itself. In the start/end routine we can build business logic required for scoring results calculations:

image011.jpg

However, this approach requires complex development in ABAP. Specific scoring requirements have to be documented by a business user in advance, which usually makes development cycle longer. Any adjustments to the scoring logic require ABAP code modifications.



Alternatively, when we use Query/APD approach, analysts are able to define scoring requirements in the queries, test and modify them whenever it is needed. They can also run queries and check preliminary results. Needless to say, it is usually easier to modify and test queries rather than transformations with ABAP code.