To get the most out of your mySAP CRM data warehouse, understand how to use the Analysis Process Designer (APD) and data mining capabilities in your SAP BW system.
Key Concept
Starting with BW Release 3.5, Analysis Process Designer (APD) includes embedded data mining functionality. The option of using APD in conjunction with data mining adds to the CRM analytics and reporting arsenal. This combined toolset — and the business content delivered as part of both BW and CRM for using it — opens new windows into your data and information.
Analysis Process Designer (APD) is a specialized workbench that empowers its users to identify and create new relationships among existing data — to gain new insights into that data that they might otherwise miss. APD is more than an object-oriented drag-and-drop design area. It is also the key component joined with the SAP data mining functionality that is growing more powerful with each release. APD also allows users to proactively identify potential targets for marketing campaigns, sales promotions, and more.
APD is considered a model or methodology for knowledge discovery in databases (KDD). KDD (also referred to as data mining) is a process-based approach to the search for potentially high-quality knowledge in databases. You can summarize nearly all of the many KDD models and methodologies in five phases: task analysis, preprocessing, data mining, post-processing, and deployment (Figure 1).
Figure 1
Five phases of KDD models and methodologies click here to view a larger version of this image
SAP APD complies with this KDD philosophy and methodology, giving you the ability to analyze and process your data in new ways (Figure 2).
Figure 2
BW 3.5 APD delivers all five phases and toolsets of KDD to its users click here to view a larger version of this image
The “new” APD provides an environment in which you can explore relationships between your data that are hidden or too complex to uncover through pure observation or traditional OLAP analysis. With it, you can read data from different sources (via the standard BW interfaces and extraction, transformation, and loading [ETL] options) and apply unique transformation logic (versus your OLAP update logic). You then can work with the results of your analysis immediately, save it in your data warehouse for future use, or deploy it to CRM for action (Figure 3). See the sidebar, “How to Extract Data from mySAP CRM into BW,” for the unique relationship and processes associated with moving CRM data into BW.
Figure 3
Analyze or deploy your APD results click here to view a larger version of this image
While the core APD functionality existed in previous versions of SAP BW (Figure 4), the tools for re-designing and mining the data were separate. Additionally, far less business content was available.
Figure 4
BW 3.0B APD and data mining processes and transactions
With BW 3.5, APD has come into its own and brings value to the CRM community with its immediate integration and ability to write APD results back into CRM as events. With that said, however, this is not a toolset that should be made available to the general masses, but rather only to those select few super users who have the need, skills, training, and authorization to work with this ad hoc capability. For those who are empowered with APD and its associated tools, the possibilities are endless for the types of information that they are able to derive.
APD Technique
So, how does this work? The APD modeling technique allows you — on the fly — to create new relationships between existing data within BW, bringing together, for example, a couple of elements from InfoCube A with components from master data B and the results of query C. You can import the results of a query into your modeling. You then create the transformations and relationships that you desire. You can either immediately work with the results in queries or load those results into another InfoProvider to work with at a future time (Figures 5 and 6).
Figure 5
Overall flow of information for the APD process click here to view a larger version of this image
Figure 6
The APD workbench is part of the Administration Workbench and thus requires additional authorizations click here to view a larger version of this image
This adds to your ad hoc analytic capabilities by allowing you to create relationships after the data has already been loaded into the system. You thereby reduce your dependency on getting the data models right when they are first designed and configured in the system. (See the October 2005 CRM Expert article “5 Tips to Improve Your mySAP CRM Reports and Analytics.”)
You can immediately work with the data in either the standard-delivered queries (Figure 7) or create your own queries with the results of your design by loading them into either an ODS or master data object, or you can transfer them into an OLTP system — specifically CRM — to work within forms (like targeted marketing campaigns, for example).
Figure 7
Example of standard statistical reporting available with APD click here to view a larger version of this image
Let’s look at the processes of working with APD in more detail. The first step in working with APD is determining what data you need to bring into your analysis. Based on the task or problem at hand, data must be statistically and semantically relevant. APD provides a mechanism for delivering this data in an easy-to-use, graphical environment. Subsequent steps can then be assured of a firm basis for continued analysis. Data can be “read” or gathered from the following sources:
 |
Characteristic: Read data from an InfoObject master data |
 |
InfoProvider: Use an InfoCube, ODS object, or MultiProvider as the source |
 |
Query: Read data from a query |
 |
Flat file: Read data from a flat file |
 |
Database tables: Read data from a database table |
The second and third steps of the process involve preparing and transforming the data into the necessary views and forms for this analysis. Preparing the data involves everything from data quality and completeness to filtering the specific values that you want to work with. The data completeness requirements for APD are no different than for other types of BW analytics — you can’t report on a field that isn’t there. Therefore, you need to perform reviews of your data to ensure that all relevant fields are populated — or that you are willing to work without those missing fields. Then, you can use these transformation tools to create the relationships and definitions that are applicable to this analysis:
This is where the modeling aspect comes into play. As noted earlier, these capabilities allow you to bring in data from (nearly) anywhere within your BW system and create new models and relationships. Knowing and understanding how the data is modeled in BW is a key skill set in working with APD. You need to understand where the data is now and how it is structured so that you can identify the places that you want APD to bridge. You need to understand the impacts of joining an InfoCube with a query result set, for example.
You also need to understand that the modeling requirements for data mining (where you can’t predefine the relationships and output) vary from traditional OLAP data modeling. To help jumpstart this process SAP has delivered the following business content for data mining:
Data mining has long been a goal for many BW users — the ability to use the system to drive out information beyond a standard report or query. This is even truer for CRM analysts who want the ability to work with data to drive out information to which they can respond proactively.
Data mining is a different, but critically important, type of reporting and analytics. Data mining doesn’t fit into the standard set of reporting, nor does it fit into what would traditionally be called ad hoc reporting. You are not necessarily looking to see what has already happened, but rather to turn historical results into proactive information.
Having done the modeling and transformations, you are able to immediately work with the results of your efforts. You have options to deliver the results via display data tools — which bring you back a simple list-based view of your results — or elementary statistics tools — which includes basic views for such common requests as correlations and standard deviations.
Additionally, you can process your results and write them back to data targets for full analytic capabilities. You can post the results back into transactional ODSs (from which you can then update to reportable BW objects), master data tables, or even into a transaction system like CRM. Once you have moved the data into either BW objects or the CRM system, you are free to work with it as you would any other information. Both BW and CRM deliver data mining capabilities to work with this data to perform new levels of analysis (such as clustering, decision tree, and regression). For examples, see Figures 8 and 9.
Figure 8
Example of data mining opportunities and the results you can generate click here to view a larger version of this image
Figure 9
APD and data mining can extend your BW solution beyond OLAP capabilities to help you identify trends and be proactive in your planning click here to view a larger version of this image
Ultimately, data mining capabilities allow you to see the forest through all the trees of data in your system. This is the end goal for many analysts — particularly those working with CRM — who need to create functional information out of the mountains of data that their systems generate. APD offers you that capability of bringing together data in entirely new ways, digging through the data to find information, and allowing you to bring that information back into CRM for action (Figure 10).
Figure 10
APD and data mining can extend your BW solution beyond OLAP capabilities to help you identify trends and be proactive in your planning click here to view a larger version of this image
ETL or APD?
With this new toolset in hand, and the ability to transform your data into new relationships and store the results for future querying, a significant question arises. Should you use the ETL process to load the data into your BW systems, or use the APD toolset to derive the data and then work with the “new” results?
While APD does deliver powerful design (even modeling) capabilities to trained users, remember that the APD and ETL processes, while similar, are different processes with different goals (Figure 11).
Figure 11
ETL process vs. APD process
The ETL process captures data out of its associated sources systems, supplying the system with the core information with which you work and enabling delta processing. Data is transformed in permanent ways during the transfer and update processes and is physically stored in the system. Data is modeled into predefined (indexed) relationships that allows users to quickly query the data.
APD allows you to create new information out of existing data with completely new relationships. You can save the data if you want. If you immediately work with the results, your querying capabilities are considerable, but your responses will likely be slower than for traditional queries as there has been no performance optimization for processes such as indexing and partitioning. Additionally, you can send the data back (in its transformed state) to CRM.
As you can see, while the question is valid, you have to look at the use of your data to determine which is the “correct” approach. In the vast majority of instances you will want to ETL your data into pre-defined BW models because this is likely where 90 percent or more of users and activities use the data. For those very special — and very well-trained — users who have the need to do the more dynamic modeling and work with data mining, APD is a good option to use in conjunction with your predefined models.
The tools and techniques I’ve described will continue to expand and mature in future releases of both the SAP BW and mySAP CRM products. New features on the immediate horizon include process chain integration, writing into flat files and InfoCubes, write-backs to SAP operational systems, variables, enhanced transformation with a formula library, and prognosis capabilities.
|
Moving data from mySAP CRM into BW is not that different than moving any other type of data into BW — with the noted difference of the real-time integration, of course. The key is the BW adapter that extracts CRM data into BW (Figure 1).
 Figure 1 Flow of data between CRM and BW
It is called up as part of the flows for the following business document types (BDoc types):
- sBDoc types of synchronizing the consolidated database (CDB) and the mobile clients
- mBDoc types of the message flow within the CRM server
By selecting the appropriate BDoc type, the BW adapter extracts the following objects into BW:
- CRM business transactions (mBDoc)
- Documents for CRM billing (mBDoc)
- Objects relevant to mobile clients such as chemical market potentials (sBDoc)
The BW adapter translates the BDoc into the extract structure of DataSources. You also need BW adapter metadata to give the technical structures, definitions, and data mapping that BW requires. To work with these you need to either create the DataSources with which to extract objects from an sBDoc or enhance the delivered DataSources.
You can enhance them via the CRM menu path Integration with Other mySAP Components>Data Transfer into SAP Business Warehouse>Settings for Application-Specific DataSources (CRM)>Settings for BW Adapter>Maintain DataSource and Enhance BW Adapter MetaData.
The first time you use a DataSource to transfer data into BW from mySAP CRM, you have to execute the initialization of the delta process, as you do with any delta-enabled DataSource. The initialization of the delta process occurs without integration to CRM Middleware. Only the delta is transferred to BW with subsequent extractions. This delta is determined using CRM Middleware, and in the case of a delta upload, is transferred to BW using the Service API, the standard interface in BW for source systems. This process will be familiar to those who have worked with BW and data extraction previously. Therefore, you will want to closely involve your BW team in this design and development process for the preparation of data movements out of mySAP CRM.
Reminder: The data is only loaded as far as an ODS in real time. It does not move directly up into your InfoCubes automatically — you must create that movement so that any reports or queries from that InfoCube reflect the new data.
|
Penny Silvia
Penny Silvia is managing director, SAP Analytics, for Deloitte Consulting. She is part of the cross-sector executive leadership team for the SAP service line at Deloitte Consulting, responsible for developing service offerings and go-to-market strategies for SAP Analytics and SAP HANA-based solutions including SAP S/4HANA and SAP BW/4HANA. This includes both internally and externally focused activities, sales enablement, solution development, client strategies, and thought leadership.
You may contact the author at psilvia@deloitte.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
