To print this page properly - use Print icon located on the page.
Please note that JavaScript has to be enabled.

SAP BW/BI Blog

<< first  < prev   1   2   3   next >  last >> 
  • 14-Dec-07 15:06 | Sergei Peleshuk (administrator)

    What is the difference between ODS and DSO?

    In BI 7.0 ODS (Operational Data Store) object has been renamed to DSO (Data store Objects). There are three types of this new object:

    • Standard: similar to the old ODS, has three tables for activation queue, table for active data and change log table
    • Write optimized: has only active data table (with delta capture capability) 
    • Direct update: consists of active data table only.
      SIDs are not generated for write optimized and direct update DSOs.

     

    What is the use of DTP in BI 7.0?

    Prior to BI 7.0, infopackages were used to transfer data from source systems all the way up to data targets and datamarts. In BI 7.0 infopackages are used to load data only to PSA. Data transfer process (DTP) is used for loading data from PSA to data targets.

     

    What is the use of End Routines in DTPs?

    An end routine is a routine with a table in the target structure format as input and output parameters. You can use an end routine to postprocess data after transformation on a package-by-package basis.

    Application: you can delete records that are not to be updated, or perform data checks based on the fields of the target structure format. This provides new capabilities and eliminates the need for enhancing source objects (extractors/DSOs) or introducing new data layers.


    Class Data declarations

    In the ABAP routines between *$*$ begin of global ... and *$*$ end of global ...  you can define the global data declarations 'CLASS DATA'. These are available in all routines. Data declarations with ‘DATA’ on the contrary can only be accessed in the current package. This means that you can use intermediate results in other routines, for example, or reuse results when you call a routine again at a later time.

    Application: During data processing we can pre-calculate certain results and store them in the internal tables declared within 'Class Data'. This gives a tremendous benefit when processing huge volumes of data where lookup tables have to be reused in multiple data packages.


    New infoset capabilities in BI 7.0

    In SAP NetWeaver BI 7.0 infosets can combine InfoCubes, DataStore objects, infoobjects. This creates a new range of reporting capabilities by joining data, for example, from existing DataStore objects and InfoCubes in a single query.

    Application: We can provide new reporting capabilities by using a join link. For example, link together supplier-vendor mapping DSO with a Vendor reporting infocube. Whenever vendor gets mapped to a new supplier and this detail is refreshed in the DSO all queries based on the infoset will display new vendor-supplier mapping.


    Control Objects in new BEx Analyzer

    BEx Analyzer in SAP NetWeaver BI 7.0 allows users to insert control objects, such as check boxes, buttons, and drop-down menus, with simple drag-and-drop functionality. This new functionality creates a range of new analysis capabilities, adding value to interactive end-user analysis, especially for ad-hoc querying.

     

    Authorizations and security migration issues

    As SAP no longer supports the 3.x method of authorizations it is recommended to migrate the authorization security to the BI 7.0 right after the upgrade. This can involve a rather large effort depending on the complexity of the 3.x security model. The security migration tool provided by SAP converts only about 80% of security. Therefore some of the migration needs to happen manually. All security requires a regression testing to ensure the migration was successful. This is a rather labor-intensive process involving creation of many user IDs and manual testing to verify that the authorizations are set up correctly.

     

     

  • 27-Sep-07 13:25 | Sergei Peleshuk (administrator)
    Brand Contribution dashboards provided in this article may be used as an example of key performance indicators in the fast moving consumer goods industry. The solution described in the “Brand Contribution Reporting Or How to Implement Marketing Dashboards" serves as a backend platform for implementing them. These dashboards may be used in business planning as well as regular operational decisions. They need to be customized in order to address particular business logic and performance indicator requirements.  

     

     

    1.    Annual Marketing Spend

    Purpose: Provide business planning capability and visual presentation of marketing spend and sales revenue.

    Decisions: Allocate marketing budget by period. Based on a full year sales plan propose total marketing spend for the year. Plan yearly marketing campaigns and see their impact on the bottom line by period.

    image002.jpg

     

    2.    Brand Contribution Plan

    Purpose: Provide business planning capability for brand contribution and marketing campaigns by period and brand.

    Decisions: Analyze how planned sales volume and revenue compares to marketing spend by brand. Plan marketing budget and yearly marketing activities, see their impact on brand contribution by period.

    image004.jpg 

     

    3.    Revenue & Expense Trend: Plan vs. Actual

    Purpose: Provide means of control over revenue generated by brand vs plan, as well as planned marketing expense vs. actual.

    Decisions: Analyze how planned sales revenue compares to actuals, and review correlations of pressurized marketing spend (planned vs. ordered). Based on actual results and ordered campaigns make decisions on adjusting marketing budget by brand for the rest of the year.

    image006.jpg 

     

    4.    Brand Contribution: Plan vs. Actual vs. Ordered

    Purpose: Provide means for analysis of brand contribution performance during the year. As soon as actual and ordered numbers are available see impact of brand contribution on the bottom line.

    Decisions: Analyze how brand contribution is performing during the year. See how the actual brand contribution together with the marketing activities that have been ordered may impact the bottom line. Make decisions whether marketing budget needs to be adjusted for the brand.  

    image008.jpg 

     

    5.    Brand Contribution vs. plan: brand A and B

    Purpose: Provide capability of comparing multiple brand contribution trends vs. planned figures.

    Decisions: Analyze how brand contribution is performing for multiple brands. See how actual sales and marketing expense impact brand contribution. Compare brand contribution for each brand with what was planned. Based on forecasted sales and ordered marketing services adjust marketing spend, do budget shifts, introduce/modify marketing activities.

    image010.jpg

     

    6.    Brand Contribution Full year trend

    Purpose: Provide capability of monitoring full year brand contribution based on actual sales, spend and ordered marketing services.

    Decisions: Analyze how full year brand contribution is changing over time. See how each brand is contributing to the full year bottom line, make decisions on budget shifts. Analyze how brand contribution is performing vs. forecasted revenue for each brand, produce more accurate forecast for full year income statement.

    image012.jpg

     

    7.    Brand Contribution by trade channel

    Purpose: Provide means of following brand contribution trend by trade channel.

    Decisions: Analyze brand contribution in each trade channel based on sales volume and channel specific campaigns. See how campaigns impact bottom line by brand. Make decisions on running channel specific campaigns and/or budget shifts.

    image014.jpg

  • 21-Aug-07 13:39 | Sergei Peleshuk (administrator)
    This article discusses BI approach and provides guidelines on implementing brand and product contribution reporting functionality. It shows why brand contribution is important in evaluating marketing investments, business planning and forecasting in the FMCG industry. The author reviews points important to BI design and concept definition, when consolidating financial, project, and sales data. Technical details are reviewed on implementing financial data split functionality and addressing related performance issues. Concepts of "marketing view" and "market pressure points" are introduced in relation to management and marketing reports.

     

     

    1. Preword

    Once upon a time there was Kingdom X. It was spending zillions of dollars on promoting its products. Although Kingdom’s image was relatively good and the products were quite popular, it was facing a sever pressure from its neighbors (competition). When a new king (CEO) came to power he announced he wants to have a tighter control over Kingdom’s marketing spend.

    As marketing budget was the biggest expense and as it was closely linked with new product launches, having a sharper view on it as well as providing better business planning capabilities was essential. This is where Business Intelligence technologies were considered by royal advisors. Specifically, brand contribution forward looking statements, when implemented, were supposed to help the king making better decisions and stay ahead of competition.

    2.    Marketeers need brand contribution reports

    Kingdom X was a marketing empire spending over 30% of its revenue on marketing and advertising. Marketing job is to maximize the impact of this spend. The idea is not just to maximize sales volume, but to optimize it, in other words, make growth more profitable.

    For growing sales volume in fast moving consumer goods industry it is important to understand growth drivers, analyze marketplace variables, explain impact of seasonality and market condition changes. A big role here can be played by ad-hoc revenue and expense reporting tools that are updated with quality information on a regular basis. This would allow producing a brand/product contribution view.

    Brand Contribution is revenue generated by the brand less direct costs associated with it. Direct costs may include manufacturing, sales and marketing costs.

    Proper brand contribution reporting besides actual numbers should contain planning data. Ad-hoc tools presenting actual and forecasted numbers for sales, revenue and profitability by product can be used as a starting point in producing forward looking statements.

    Depending on incoming data granularity and business needs our brand contribution reporting can be done by trade channel and/or customer. This opens new capabilities to brand managers in making timely adjustments to marketing investments based on changing business results and market conditions.

     

    3.    Concept and assumptions

    It is common in today’s corporate world to have multiple platforms and data sources supporting similar business functions. Budgeting and planning may be performed in one environment, transactional data may be handled using one or several ERP applications, and management reporting can be done using a separate set of tools.

    To make things simple let us imagine in Kingdom X all transactional data is handled in SAP R/3 or Netweaver. We have all major modules implemented across all geographical regions and we can access the following data sources:

    ·         Financial (FIGL) data – direct costs and overheads

    ·         Campaign (PS, MM) data – budgeted and ordered costs for each marketing campaign by brand and period

    ·         Sales (SD, BPS) data – budgeted and actual sales figures

     

    3.1    Related Data flows

    Here are examples of relevant data flows on the transactional side representing three major business processes:

    3.1.1    Business Planning

    Every year marketing associates set up a plan for sales volume and marketing spend during business planning process.

    image001.jpg

    Technically, they have to enter marketing project structures (campaigns) in the PS module.

    image002.jpg

    3.1.2    Regular updates

    During the year marketing associates make adjustments to sales volume plans.

    image003.jpg

    Previously planned marketing activities are adjusted; budgets are shifted between brands, customers and campaigns.

    image004.jpg

    Finance associates perform regular data entries of actuals on Purchase Orders, Accounts Payable, goods receipt.

    image005.jpg

     

    3.1.3    Period Closing

    Period closing procedures are performed by accounting/finance associates at the end of each month. Special entries are done in SAP PA, PS and BPS related to costing, accruals, budget copy and adjustments to forecasts.

    image006.jpg

     

    3.2    Know Your Audience when designing BI models

    In many cases we face situations when certain reporting functionality is relevant for one business function within an organization and makes absolutely no sense for another one. If we produce a brand split expense report for marketing purposes it definitely cannot be used in financial reporting or statutory accounting.

    This is due to the fact that historical data cannot be changed according to GAAP rules, while for marketing purposes we may want to have multiple views on what has happened in the past.

    3.2.1    Restatements example

    The following chart illustrates how marketing project updates (restatements) impact historical brand split. Each time we allocate costs to a certain project they have to be split according to project structure. When budgets are adjusted brand split allocation changes. While restated view on costs is essential for brand contribution reporting it does not make sense for statutory accounting:

     image007.jpg

    Note: In the scenario proposed in this article restatements are addressed when loading data from the 1st to the 2nd level (see 4.3).

     

    4.    Collect and consolidate data based on common rules

    The goal of BI tools is collecting multiple data sources together and presenting information in such a way so that it becomes easy to make tangible business decisions. When we integrate financial, campaigns and sales data we have to come up with a list of common analysis codes (dimensions) that would allow us analyzing consolidated information.

    In the case of brand contribution reporting it is recommended to use the following dimensions in the multiprovider:

    image008.jpg

    We can be sure that Time, Geography and to some extent Product breakdown is common for all three data sources (financial, campaigns and sales). According to GAAP rules product or band split for overhead expenses is usually available in PA module as soon as product costing and period closing procedures are executed. However, for marketing reporting GAAP accounting does not always apply.

    As for the other dimensions in the multiprovider source data will give us the following level of detail:

    • Account Category: available for Financial (FIGL) data
    • Project: available for Campaign (PS, MM) + Financial (FIGL) data
    • Customer: available for Sales (SD, BPS) data
    • Trade Channel: available for Sales (SD, BPS) data

    Depending on source data granularity different views on income statements can be produced. Usually we do not get FIGL or PO data broken down by customer or trade channel. Therefore if we do not implement additional transformations we cannot produce a brand contribution view by customer or channel.

     

    4.1    Add sales analytics to marketing expenses

    In SAP BI it is possible to increase granularity of source data by using a multi layer BI setup. In case brand contribution planning is done by trade channel and/or customer we may want to implement trade channel and/or customer group split for FIGL data. In the multi layer BW architecture we process data using several steps (layers). The following approach can be used in this case:

    image009.jpg

    When moving data from DSO1 to DSO2 implement logic that would split each financial record into several based on certain business requirements, such as sales split for the same day. The idea is that we know sales by product, trade channel and customer group from our SD source. So when processing FIGL data we want to use sales data as a lookup for distributing finance results (costs) over sales analytics (trade channel and customer group) in proportion to products sold during the day.

    Similar approach can be implemented when splitting marketing related purchase orders over customers, trade channels or profit centers.

     

    4.2    Marketing view and Market pressure points

    In order to produce a marketing view for financial reports we want to apply market pressure points to direct costs. Market pressure points define how marketing budget for each campaign is spread over brands, periods, etc. The point is that invoices posted in a certain fiscal period may not have impact on the market during that period. However, marketing associates want to see when expenses impact the market and which brands they are related to. Therefore, in order to produce a “marketing view” every invoice or purchase order related to the project has to be “pressurized” according to market pressure points.

    An example is advertising air time. If we pay an advertising bill in January, but the ad is going to be aired during the whole year, we want to spread the cost of the campaign over the year according to market pressure points specified in the marketing project (PS). Technically we need to split each record of relevant invoice/order into multiple records, depending on how many pressure points we get from the corresponding project (WBS code). Every generated record is assigned to a proper fiscal period and brand.

    As mentioned earlier, “marketing view” is not going to match financial reports and cannot be used for GAAP reporting. It is used purely by marketing associates, helping them to manage marketing investments and campaigns.

     

    4.3    BI dataflow and implementation tips

    Brand contribution reporting functionality can be delivered with the following data flows:

    image010.jpg

    Here are a few points to keep in mind when implementing such scenario:

    • 2nd level objects should contain only project relevant details needed at the time these objects are used. For instance, FIGL DataStore object should contain only those expenses that are relevant for brand contribution reporting.
    • When applying project structure and sales split in the update rules of FIGL_02 DataStore objects take into account that addressing performance is critical. Heavy lookups may kill the whole concept. Performance issues have to be addressed in the data warehouse design from the very beginning.
    • If we have to implement two splits (market pressure points and customer split) make sure you split data in the right sequence. Market pressure points define brand and time for each FIGL record, which are needed for sales data lookup. Therefore, the sequence should be: apply market pressure points first, and then perform customer split.
    • Multiprovider has to link details from each infocube at the lowest possible level of detail. For instance, if we deliver customer split with FI data we should link customer code from Actuals infocube with customer code from Sales, etc.

     

    4.4    Performance issues

    In the described scenario we are facing performance issues when processing millions of FIGL or MM transaction lines over millions of SD or PS lines. In the case of history loads these numbers could be billions.

    How do we make sure the split and lookup logic is going to work? Addressing performance in the backend data processing is extremely important! Here are a few tips on how you may want to address performance issues when implementing heavy lookups:

    • Make sure you process only relevant records (FIGL or MM): filter out all items that are not in the project scope. Keep only direct expenses that you want to be used in brand contribution reports.
    • Set up proper indexes in the DataStore objects that are used as lookups.
    • Make sure internal tables filled from lookup DataStore objects contain only relevant records and are properly indexed.
    • In case DataStore object indexes do not help improving performance or when indexes are not allowed due to various reasons we may want to implement “intelligent lookup tables” approach. (For more details see: Optimize FIGL Processing with Intelligent Lookup Tables and Pseudo Delta Loads)

     

  • 25-Jun-07 18:20 | Sergei Peleshuk (administrator)
    This is the first time I faced a BI implementation project that required an automated hierarchy generation. Usually hierarchies are loaded from a source system, either R/3, flat files, or another data source. But in this project the hierarchy was not available in the source; we were only getting business rules on how to generate hierarchies. And the generation itself had to be performed using an application, for example, SAP BI.

    The approach described here was tested in an actual BI implementation, but it involves direct update of SAP hierarchy tables. Should you have any problem with this approach please do not blame the author ;)

    Note:

    The business requirement described in this article uses a time independent hierarchy. All examples and charts do not imply time dependency. However, similar approach can be used in the case of time dependent hierarchies: Valid From and Valid To date fields in the respective nodes have to be updated in order to enable time dependent functionality.

    Read Full article (authorization required) 

     

  • 01-May-07 14:58 | Sergei Peleshuk (administrator)
    BW 3.x does not allow you to run two delta loads back to back. Learn a workaround involving DataStore objects and a pseudo delta load that allows you to do this. You can use this functionality to improve system performance in processing high data volumes when implementing complex business logic.

    Download Full Article here...

  • 15-Dec-06 15:30 | Sergei Peleshuk (administrator)

    Collection of introduction slides to BI 7 (BI in NW2004s) that may be used for initial assessment and training. Includes overview of new release's Features, Benefits, and Upgrade Issues. 

    Download Slides here...  
  • 01-Mar-06 14:48 | Sergei Peleshuk (administrator)
    Learn about the advantages of and tips for using Business Objects on top of SAP BW. Specifically, learn what issues developers should be aware of when building structures in Business Objects.

    Download Full Article here...

     

  • 25-Aug-04 14:45 | Sergei Peleshuk (administrator)

    Business Intelligence tools are implemented by corporations to benefit from the investments made during decades into IT infrastructure and transactional systems. However, not all implementations get a proper return on investment.

    Major corporations nowadays spend a big chunk of their IT budgets on implementing business intelligence solutions. Corporate management wants to benefit from the investments made during decades into IT infrastructure and transactional systems. According to META Group, 59% of corporations running SAP have SAP BW module installed, a business intelligence tool provided by SAP.

    BI tools allow business management to view product sales by day or week, compare them with budget, analyze product costs or brand contribution, do forecasting. In other words, the tools provide means of improving business planning processes as well as making better and faster management decisions.

    At the same time companies are facing numerous implementation issues and have to constantly review their BI strategy. One of the reasons for that is constantly changing business environment and reporting requirements. If your project takes more than two years to implement it is hard to make sure that by the end of the project your business objectives will be addressed within the same solution or technology.

    Another issue is related to existing data flows and internal procedures that have to be adjusted to accommodate data consolidation from multiple sources. A company may face a problem in identifying the “source of truth”. For example, you may currently keep track of your materials (stock items) in separate systems or database instances, linked to strategic business units. When you implement a BI system an issue comes up on how to consolidate material codes into a single database in such a way that there would be a possibility to analyze product sales across business units and at the same time transactional data would be linked to the right products from the source system.

    BI Project Phases

    A lot of potential design and data issues can be addressed in the analysis and the blueprint phases. At this stage the technology is selected and the system architecture is defined. In a typical project the development begins as soon as project planning is done, the resources are committed and software licenses are acquired.

    In many cases blueprint and development is performed by completely different teams, and sometimes even by different vendors. Although procedures and methodologies may allow knowledge transfer, it is very likely that design details may not be properly interpreted or understood by developers.

    The development phase in BI projects is followed by series of tests, user acceptance, go live, and data validation. On many projects programming flaws and procedural issues are discovered only at the data validation phase, when business analysts start using reports on a daily basis.

    Importance of Testing
    In order to minimize a number of errors discovered at the very last moment it is important to perform thorough testing throughout the project. There are typical series of tests, with some variations, depending on methodologies used in each particular implementation:

    • ü Unit testing: Performed when your developers are testing every module and program unit, that has been developed, for example, data load from one table (ODS object) to another.

    • ü Integration testing: You define a number of business scenarios and check if the data is loaded properly from source to target. For instance, you check a number of invoices in the source and check if they have been transferred properly to the target. This step is usually performed together with power users.

     

    • ü User acceptance testing: You involve end users in the overall application testing. They have to run reports and check if the numbers make sense from the business point of view. This is normally done in the test/user acceptance environment, after which the system goes live into production.

     

    • ü Data validation/monitoring: This ongoing procedure is performed in the production environment after each load. A lot of data validation can be automated with source/target comparative reporting performed on a regular basis. Human involvement is important at this stage due to complex business logic and the fact that multiple parties are involved in managing source data and processes. Data flow issues, discovered at this stage result in the requests for enhancements, submitted to new releases.


    Managing user expectations
    It is extremely important for overall project success to properly manage end user expectations. Make sure users do not immediately expect 100% accuracy and completeness from the BI application when you go live. In complex environments reports may look incomplete: some legal entities are missing or budget data is not loaded; reports may be invalid due to various reasons: master data not properly maintained, invalid product codes are entered in the source system, errors occurred during transaction loads, etc.

    In order to gain end user credibility it is advised to start with functional areas that are valid and complete. This may be just a few business units (geographical areas) that have been thoroughly tested. Even if not all measures (key figures) are loaded and tested, make sure your users know which ones have been tested, which ones are in the process, so that there is no general frustration with the system if Version 2 budget for a certain product is incorrect, for example.

    Data Quality
    The complexity of data validation procedures depends on system architecture and on how many different environments or platforms are consolidated together. For instance, if master data is loaded from a single source, validation procedures will be relatively simple. However, this is not the case in the actual business environment.

    If you are consolidating multiple AS/400 applications, SAP R/3 and PC application data into a single datawarehouse you may expect various types of data processing issues. This may relate to internal company procedures on how master data was handled prior to datawarehouse implementation. If a sales clerk, for instance, enters a new product in R/3 with a product code that does not match AS/400 product table, you would have to require your business analyst to spend some time to investigate where the problem comes from.

    More severe validation issues are related to the absence of the “source of truth”. If you want to display “net sales” in your BI reports you have to have valid source system reports, where you can check your net sales. In the case when you allow your customers, for example, to have cash discounts based on when they pay their bills, it is not always easy to determine in the source system how the cash discounts are allocated to multiple invoices and, therefore, what is the “net sale” amount per invoice line item.

    Some companies introduce corporate standards for accepted data quality. If data accuracy in the end user reports is within 2% difference with the source, for example, the reports are considered to be valid and released to the users.

    Summary

    To maximize the return on investment in BI projects one should not only choose proper technology and system architecture, it is also a matter of team experience with similar projects in the right functional area. If your database architect is experienced with sales data flows and knows how data is processed in transactional systems, he will be better equipped for defining sales datawarehouse architecture rather than the person without such experience.

    If you have project team members at your disposal that can point out where potential data validation issues may arise, you will be able to address these issues earlier. And of course, knowledge of business processes together with industry experience is important. The success in Business Intelligence projects depends on whether your project team has the right balance of technical skills together with experience in relevant business processes and functional areas.

<< first  < prev   1   2   3   next >  last >> 
 

Powered by Wild Apricot                                                                                                                                                       Copyright BI Portal.ORG