Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

http://gbvazque.wordpress.com/2013/02/22/sap-hana-analytics-foundation-use-case-to-understand/

HANA Analytic Foundation.

For those clients that run their businesses using SAP Business Suites systems, and also run non SAP transactional and non SAP analytical systems, and at the same time, they  would like to have an alternative in the use of BW modeling or  in addition to current ABAP reporting, the HANA Analytics Foundations represents  a very good  option.

HANA Analytics Foundation (HAF),  provide a very extensive reporting capabilities across all business suites applications by pre-built SAP Data models.

HAF provides hundreds of HANA Data models based on the SAP standard business scenarios in which your systems runs.

These data models are the foundation for a major and scalable HANA data models and applications, that can be expanded  with structured data from your SAP systems, or non sap systems, and also unstructured data from non SAP Systems.

Your starting point to start building you analytical foundation is far from starting from scratch, as it happened at HANA beginnings.

Your data warehouse in HANA can be completed, in less time, by the savings in time and efforts of using very complex and strong pre-built and certified SAP  HANA Data Models.

The data sourced from SAP business suite systems, like SAP ECC, CRM, SCM, GTS, to SAP HANA, uses the SAP Landscape Transformation System (SLT), and data from non sap systems could be sourced into HANA using SAP Data Services.

In the Figure (1) Below a complex architecture is represented with a single SAP Business Suite System (SAP ECC), and many other non-sap systems, bring content into SAP HANA.

The Virtual Data models, are use as a foundation of more complex ad hoc  HANA data models.  Please note that SAP HAF, only support built Calculation views.

Figure (1)

Capture

Please note that the SAP  HAF provide virtual data models not only for SAP ECC, but also for SAP CRM, SCM, GTS and SAP is expanding these capabilities.

The  SAP HAF consists of the following elements ,  virtual Data Models,  and on top analytical applications with rich clients and user interfaces.

You as a customer can build new query view layers  in top of the prebuilt customer virtual data models, expanding the basic models provided by SAP.

This extensible model, allows you and your company to expand in an easy way your analytical capabilities, extracting, and using views, that are based on standard SAP business processes.

You will not need to rethink how to build this views, that most likely will be standard across Industries and sectors, releasing your organization talent, to focused in actual business analytics needs, and expanding operational possibilities in the design of mobile applications.

The most important features of SAP HANA  can be exploded using the SAP HAF,  uniformity, speed and scalability.

If you are familiar with SAP Business Scenarios, Process, steps, and transactions, you know the complexities of configuration complexities and dependencies in the ECC, CRM and other SAP suite systems , well, SAP HAF make them available, and your teams, will not need to have deep understanding of SAP models.

Lets follow an implementation example, so you can understand the benefits and use of the SAP HAF.

HAF Use Case  SAP Sales and Distribution.

For this example, lets define Corporation XYZ, a very successful Candy producer that runs their SAP ECC systems using the Consumer Products Industry Solution.

Their main distribution channel primarily is composed, by young entrepreneurs that run all their operations using complex E-commerce applications, after meeting with the Sales Vice-president of Corporation XYZ, they are demanding  a tool that can help them predict what their main distributors will order, and must importantly what is the main order composition. In top of they expressed serious concerns on regards, competitors penetrating their markets, and they would like to detect in advance which of their clients are not supplying in normal rates.

The Sales Vice-president in a normal display of sympathy offer to them a solution that will be implemented before 45 days, that is the pick season of the national candy sales, and also, in order to keep them happy, he offered that this reporting, should be made available for Mobile Devices.

The Sales Vice-President finishes his meeting, and call his CIO with the request.

In this new business environment, this request should not be a surprise for efficient IT areas, and implementation cycles should be kept in weeks, to make the business agile and efficient..

The implementation team runs their operations in a similar architecture as the one described in Figure 1.

SAP HAF, will provide to the implementation team with the following prebuilt SAP SD based HANA DATA Models, so the team consults can search in the  http:// help.sap.com  site, and find that the following HANA Data Models are available. Please note that team already has the SAP HAF virtual models installed, and their main analysis will be in finding out, how to produce additional DATA models to be able to predict order, quantities, and current clients purchasing trends.

Please review the content of the SAP ECC Sales and Distribution Virtual models available.

1.2.1           Sales   **

The following reuse views are included in this virtual data model:

  • Reuse view for sales document headers (SalesDocumentHeader)
  • Reuse view for sales quotation headers (SalesQuotationHeader)
  • Reuse view for sales order headers (SalesOrderHeader)
  • Reuse view for sales contract headers (SalesContractHeader)
  • Reuse view for headers of credit memo requests (CreditMemoRequestHeader)
  • Reuse view for headers of debit memo requests (DebitMemoRequestHeader)
  • Reuse view for customer return headers (CustomerReturnHeader)
  • Reuse view for business partners for SD document headers (SDDocHeaderBusinessPartner)
  • Reuse view for sales document items (SalesDocumentItem)
  • Reuse view for sales quotation items (SalesQuotationItem)
  • Reuse view for sales order items (SalesOrderItem)
  • Reuse view for sales contract items (SalesContractItem)
  • Reuse view for items of credit memo requests (CreditMemoRequestItem)
  • Reuse view for items of debit memo requests (DebitMemoRequestItem)
  • Reuse view for customer return items (CustomerReturnItem)
  • Reuse view for business partners for SD document items (SDDocItemBusinessPartner)
  • Reuse view for schedule lines of sales documents (SalesDocumentScheduleLine)
  • Reuse view for schedule lines of sales orders (SalesOrderScheduleLine)
  • Reuse view for schedule lines of customer returns (CustomerReturnScheduleLine)
  • Reuse view for sales document conditions (SalesDocumentCondition)
  • Reuse view for sales quotation conditions (SalesQuotationCondition)
  • Reuse view for sales order conditions (SalesOrderCondition)
  • Reuse view for sales contract conditions (SalesContractCondition)
Measures and Attributes

Some important measures and attributes are the following:

  • Reuse view for sales document headers (SalesDocumentHeader)
    • The view provides general data such as SD document category, sales organization, distribution channel, organization division, sold-to party, purchase order by customer and overall SD process status.
    • The view provides information about values such as total net amount and header counter.
  • Reuse view for sales quotation headers (SalesQuotationHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, purchase order by customer, sales quotation validity start date and sales quotation validity end date.
    • The view provides information about values such as total net amount.
  • Reuse view for sales order headers (SalesOrderHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, purchase order by customer, requested delivery date, overall SD process status and user ID of creator.
    • The view provides information about values such as total net amount.
  • Reuse view for sales contract headers (SalesContractHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, sales contract validity start date, sales contract validity end date, sales contract signed date and sales contract cancellation reason.
    • The view provides information about values such as total net amount.
  • Reuse view for headers of credit memo requests (CreditMemoRequestHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, purchase order by customer, overall SD process status, user ID of creator and creation time.
    • The view provides information about values such as total net amount.
  • Reuse view for headers of debit memo requests (DebitMemoRequestHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, purchase order by customer, overall SD process status, user ID of creator and creation time.
    • The view provides information about values such as total net amount.
  • Reuse view for customer return headers (CustomerReturnHeader)
    • The view provides general data such as sales organization, distribution channel, organization division, sold-to party, purchase order by customer, overall SD process status, user ID of creator and creation time.
    • The view provides information about values such as total net amount.
  • Reuse view for business partners for SD document headers (SDDocHeaderBusinessPartner)
    • The view provides general data such as sold-to party, ship-to party, bill-to party, payer party, sales employee and responsible employee.
Used Tables and Views

The views mainly select data from the following tables, for example:

  • VBAK (sales document header)
  • VBAP (sales document item)
  • KONV (conditions)
  • LIKP (delivery document header)
  • VBUK (delivery document header status)
  • LIPS (delivery document item)
  • VBUP (delivery document item status)
  • VBUV (incompletion log)
  • VBRK (billing document header)
  • VBRP (billing document item)
  • KONV (conditions)

** source from www.help.sap.com

SAP HAF provides equivalent virtual views for SAP SD Delivery processes, and SAP SD Billing processes, as you can notice the IT group of Corporation XYZ, have available all the key components of an End to End Sales Process.

From the Sales Order, Delivery and Billing processes, the SAP HAF Virtual models,  available covers the end to end implementation requirements to operate the virtual models, so after implementation the IT  group of Corporation XYZ, will have available :

SAP SLT Data Schemas built for the SAP ECC Tables mentioned above.

SAP HANA Data models with the required Calculation views, Attribute Vies and Analytical views already operational.

Basic content to be available using HTML5 basic presentation views.

So an implementation that by itself could took several weeks, to bring standard SAP ECC content into HANA, is completed, tested and operational in days.

So the Corporation XYZ IT group will focus only in the analysis and build of Virtual Client XYZ views, in top, of the existing SAP HAF views.

Corporation XYZ, hires his favorite QUAN from a prestigious University in Pennsylvania and discuss the urgent requirement.

The Statistician concludes the following based on the Business requirements, and the available data in the SAP HAF Sales and Distribution Models. He only took five business days to complete the research due to the efficiency in documentation available of SAP HAF.

The Statistical Model for Corporation XYZ.

A basic logistics regression model which predicts the probability that a sales order will be placed by a customer, and a Linear regression model to be used in the forecasting of number of items per product will constitute the foundation of the required Data model to be build in SAP HANA.

The Functional teams at Corporation XYZ, analyzed the statistical model and concluded that this new Data model is classified as medium complex, and that it will take, 3 weeks to fully implement, due to the fact that no new data will be required to be replicated in SLT, and also to the fact that the required algorithms can be creates using the SAP HANA available Statistical Language “R”.

The Model to predict the probability that a Sales order be placed,  the Reorder Model, will required the following data elements, or in more formal terms, the Reorder Model metadata requirements are:

1) Forecasted Customer new order Date

  1. Calculate the average numbers of days between past orders.

i.      Algorithm to calculate the difference between the Sales Order Date of  Sales Order 1, and the Sales Order Date of Sales Order 2…. Sales Order date of Sales Order n, for orders placed in the last 180 days.

2) Forecasted Customer Reorder quantity

a)   Calculate the average consumption rates between past orders.

i.      Algorithm to calculate the difference between the Sales Order quantities of   Client Product A for Sales Order 1, and the Sales Order quantities of Product A of Sales Order 2…. Sales Order quantity of Product A of Sales Order n, for orders placed in the last 180 days.

** Please note that HANA will provide coverage for the million of records that Company XYZ will need to process to estimate the Forecaster Customer Reorder Quantity.

3)  Estimated Product Mode

  1. Calculate how many times Product A, Product B , Product  n.. has been ordered.
  2. Take the natural Logarithm for each Estimated Product mode for each product.

Company XYZ,  uses with this variables calculated the predictive algorithms required,  and estimation order volume level algorithms using  the advantages of the statistical Language “R”.

Once that the models are operating, Company XYZ define and implement the required BOBJ 4.0 Explorer views, that can be displayed in Mobile devices, the level of effort to complete this implementation,  is not complex, as the teams are using standard BOBJ available functionality.

Company XYZ, was able to implement this complex statistical model, in the timeframe define by their business requirements, due to the fact that :

* SAP HOF Virtual models provide all required content to be able to map an end to end sales process from Sales to Billing at the Header and Items levels.

  • Teams were able to use more time, to create their own virtual models to solve a complex business problem.
  • Teams also used available BOBJ 4.0 reporting capabilities to fulfill business requirements.
2 Comments
Labels in this area