With SAP Net Weaver, you can:
•Make one portal that gives each user exactly what he needs from all your applications.
•Provide a unified view of information form every part of your company and deliver it to employees just when and how they need it.
•Knot together into one streamlined interface processes that are distributed in bits across many applications.
•SAP Business Intelligence is providing tools for information integration, so what a companies Sales employees see about a customer matches exactly what an employee in Customer Services sees. Or that Production offers enough capacities to produce those additional volumes of a specific product that is marketed in your summer promotion campaign.
•SAP BI is tightly integrated with SAP EP.
•SAP BI can generate various types of queries and reports and save them directly as iViews, which can be included in the portal.
•The results of SAP BI Web applications can be stored in the content management repository.
•SAP BI offers plan data entry and reporting on one database.
•Provide a unified view of information form every part of your company and deliver it to employees just when and how they need it.
•Knot together into one streamlined interface processes that are distributed in bits across many applications.
•SAP Business Intelligence is providing tools for information integration, so what a companies Sales employees see about a customer matches exactly what an employee in Customer Services sees. Or that Production offers enough capacities to produce those additional volumes of a specific product that is marketed in your summer promotion campaign.
•SAP BI is tightly integrated with SAP EP.
•SAP BI can generate various types of queries and reports and save them directly as iViews, which can be included in the portal.
•The results of SAP BI Web applications can be stored in the content management repository.
•SAP BI offers plan data entry and reporting on one database.
The open integration and application platform for TCO reduction
Integrate people, information and processes…
- … in 1 hub …
- … across technologies and organizations.
- Enterprise-scale Java and ABAP application platform
- .NET and WebSphere interoperability and extensibility
- Pre-configured with business content
- Adapters to non-SAP
SAP BW Architecture
The role that SAP BI plays in SAP Net Weaver is that of a central, integrated repository for information from distributed and heterogeneous sources. The parts described below are used for moving data from the source systems that contain it to the SAP BI data warehouse, and then organizing it, passing it out to others who need parts of it, and preparing it for analysis.
• Data Warehousing in SAP BW represents the integration, transformation, consolidation, cleanup, and storage of data. It also incorporates the extraction of data for analysis and interpretation.
• Administrator Workbench: The data warehousing process includes data modeling, data extraction, and administration of the data warehouse management processes. The central tool for data warehousing tasks in SAP BW is the Administrator Workbench.
• BI Platform: The business intelligence platform serves as the technological infrastructure and offers various analytical technologies and functions. These include the OLAP processor, the Metadata Repository, Business Planning and Simulation, special analysis processes such as Data Mining, and the Reporting Agent.
• Business Explorer Suite: The SAP BW Business Intelligence Suite, the Business Explorer, provides flexible reporting and analysis tools for strategic analyses, operational reporting, and decision-making support within a business. These tools include query, reporting, and analysis functions. Past or current data can be evaluated on various levels of detail, and from different perspectives, not only on the Web but also in MS Excel.
• Administrator Workbench: The data warehousing process includes data modeling, data extraction, and administration of the data warehouse management processes. The central tool for data warehousing tasks in SAP BW is the Administrator Workbench.
• BI Platform: The business intelligence platform serves as the technological infrastructure and offers various analytical technologies and functions. These include the OLAP processor, the Metadata Repository, Business Planning and Simulation, special analysis processes such as Data Mining, and the Reporting Agent.
• Business Explorer Suite: The SAP BW Business Intelligence Suite, the Business Explorer, provides flexible reporting and analysis tools for strategic analyses, operational reporting, and decision-making support within a business. These tools include query, reporting, and analysis functions. Past or current data can be evaluated on various levels of detail, and from different perspectives, not only on the Web but also in MS Excel.
Info Cubes and Planning Areas
Operational Data Store or Info Sources.
•BW-BPS Master data and transactional data is stored in Basic Info Cubes
•There are two types of Basic Info Cubes: Basic non-transactional Info Cubes (NT) and Basic transactional Info Cubes (T)
•Basic non-transactional Info Cubes are used for actual data, whereas Basic transactional Info Cubes are intended to be used for plan data. The main difference is that non-transactional Info Cubes are optimized for read-access while transactional Info Cubes are optimized for write-access.
•Planning can only be carried out on Basic transactional Info Cubes.
•In order to use transactional Info Cubes for planning, a Planning Area must be set up in BW-BPS.
•Basic non-transactional Info Cubes may be used in Planning Areas as well – e.g. as a source for reference data or for plan-actual comparison.
•Both types of Basic Info Cubes may be used for data analysis in the BEx Analyzer.
•The main difference between the different types of Basic Info Cubes is organizational – Basic non transactional Info Cubes may be loaded in a batch procedure while Basic transactional Info Cubes are
usually filled either manually or by planning functions.
•It is also possible to use transactional Info Cubes both for loading of actuals via extraction and for planning. To achieve this a switch needs to be set on the Info Cube to allow either "Load" or "Plan" at the given time.
usually filled either manually or by planning functions.
•It is also possible to use transactional Info Cubes both for loading of actuals via extraction and for planning. To achieve this a switch needs to be set on the Info Cube to allow either "Load" or "Plan" at the given time.
BW-BPS Architecture Overview
Business Planning with BW-BPS allows to create strategic and operational business plans in a multidimensional way.
• BW is the database for all master and transactional data. Plan data can immediately be analyzed within SAP BW upon saving.
• BW-BPS provides user interfaces based on Excel, ABAP List Viewer (ALV) and Web.
• Planning functions allow to automatically alter and create data sets. Event-based execution of planning functions allows to automate parts of the planning process.
• BW is the database for all master and transactional data. Plan data can immediately be analyzed within SAP BW upon saving.
• BW-BPS provides user interfaces based on Excel, ABAP List Viewer (ALV) and Web.
• Planning functions allow to automatically alter and create data sets. Event-based execution of planning functions allows to automate parts of the planning process.
• Planning processes may be automated and monitored using a comfortable, easy to configure workflow tool – the Status and Tracking System.
• Data modeling, user interfaces and planning methods are designed very flexible. BW-BPS may be used for the design of any type of planning application.
• Planning in BW-BPS can be easily combined with planning in R/3.
• Data modeling, user interfaces and planning methods are designed very flexible. BW-BPS may be used for the design of any type of planning application.
• Planning in BW-BPS can be easily combined with planning in R/3.
Request ID-Handling in Transactional Info Cubes
• Data requests in transactional cubes stay open until the number of records in the data request exceeds 50,000.
• When an application is writing data into the request, so that the limit of 50,000 records is exceeded, the data is stored and the request is closed. (Thus a request can actually contain more than 50,000 records. Example: If a request already contains 49,900 records, and someone is using a BPS layout to store 500 records at once, then all the records are into the same request of this Info Cube, so that the request contains 50,400 records)
• As soon as the number of records in this data request exceeds 50,000, this request is closed and the request can be rolled up in defined aggregates if any exist (in asynchronous mode).
• Physically, the design of these Info Cubes possibly differs with respect to indexing and partitioning (depending on database). For an Oracle DBMS this for example means: no bitmap indexes on the F fact table and no partitioning of the F fact table by packet dimension (initiated by the BW).
• Roll up and definition of aggregates, compressing and so on is still possible.
• When an application is writing data into the request, so that the limit of 50,000 records is exceeded, the data is stored and the request is closed. (Thus a request can actually contain more than 50,000 records. Example: If a request already contains 49,900 records, and someone is using a BPS layout to store 500 records at once, then all the records are into the same request of this Info Cube, so that the request contains 50,400 records)
• As soon as the number of records in this data request exceeds 50,000, this request is closed and the request can be rolled up in defined aggregates if any exist (in asynchronous mode).
• Physically, the design of these Info Cubes possibly differs with respect to indexing and partitioning (depending on database). For an Oracle DBMS this for example means: no bitmap indexes on the F fact table and no partitioning of the F fact table by packet dimension (initiated by the BW).
• Roll up and definition of aggregates, compressing and so on is still possible.
Impact of Planning on Data Volume
Data volume increases in planning due to:
•additional transactional cubes,
•additional records (delta records) and
•additional detail level (e.g. version handling)
But:
•planning is usually done on a more aggregated level than actual reporting (A ship builder may plan by single customer, whereas a telecommunications company may plan by customer group only)
•plan data is archived more often
•plan data is archived more often
Overview of BW-BPS
Planning in BW-BPS comprises four major areas:
In Modeling the data model of a planning process is defined. That includes to determine how the planning process will be set up in regards to business structure (slice and dice) and planning strategy (e.g. bottom-up, top-down, counter-current). Planning functions are operations that support the automatic processing of plan data (e.g. copying, forecasting, ...) in a stimulative fashion or embedded in batch processing.
Planning layouts in manual planning allow to set up the context of entering plan data for different users. Planning interfaces consist of one or many planning layouts together with planning functions to support the planner with the planning task.In order to coordinate the sequence of the planning process a planning tasks may be assigned to the planners and the status of the planning accomplishments can be tracked over the cycle of a planning session.
Planning with SAP R/3 and SAP BW
What are the differences between planning in SAP BW-BPS and SAP R/3?
• For customers who do not use R/3, BW-BPS offers a generic modeling tool that is ideally suited to flexible planning.
• R/3 is used for planning across the whole range of applications, from Cost Center Accounting, and Profitability Analysis to Human Resources. This planning is relatively static, this means it tends to follow the same path. So a cost center always plans its costs, activities, activity input and statistical key figures within the controlling area by cost center. Group wide, cross-controlling area planning is not possible in R/3. The planning functions, which are not covered in R/3 are generally covered either by Excel or other systems. Here the top-down, bottom-up planning integration is missing, which is supported by BW-BPS.
• Using the flexible structure of BW, you can for example create a new material as a characteristic, without having the maintain material masters, or simply change organizational structures, which you can then plan in BW-BPS.Consequently, the whole enterprise structure can become the object of planning. This is not possible in R/3.
• In contrast to R/3, which has separate, specific Customizing for every application, BW-BPS has a unified framework, which is not dependent on what the customer wants to plan.
• Whilst in the R/3 applications, the interfaces are all constructed differently, in BW-BPS the data is integrated according to the same procedure regardless of the planning application.
• You can integrate your planning by splitting the tasks between R/3 and BW-BPS. In areas where a company requires a high level of detail it is better to continue to plan with R/3. In other planning areas where the goal is the most flexible simulation of structure changes and their effects, you can use SEM-BPS to model and analyze the changes. This releases you from the relatively static conditions applying to organizational structures and Customizing.
• The CFO does not usually plan the quantity of sales, but uses aggregate planning at controlling area and company code level, which can be designated as characteristics. For example, he plans the key figure 'sales' for the following year,which increases 10% in comparison to the previous year.
• The sales manager, who is responsible for the sales organization, already plans in more detail, for example quantities
and costs as well as the average price for the product group. This already indicates a refining of the characteristics and
key figures.
• The key account manager plans at the most detailed level with regard to characteristics and key figures. He plans sales
quantities, which are to be valuated using a material cost estimate and SD conditions.
• When modeling the planning process, you have to consider at which level of detail you want to work with BW-BPS or R/3. You should always plan where the data can be most effectively accessed. The key account manager is more likely to plan in R/3, as it is possible to access the material cost estimate and sales conditions, and there is no need to model these detailed planning values first in BW-BPS.
and costs as well as the average price for the product group. This already indicates a refining of the characteristics and
key figures.
• The key account manager plans at the most detailed level with regard to characteristics and key figures. He plans sales
quantities, which are to be valuated using a material cost estimate and SD conditions.
• When modeling the planning process, you have to consider at which level of detail you want to work with BW-BPS or R/3. You should always plan where the data can be most effectively accessed. The key account manager is more likely to plan in R/3, as it is possible to access the material cost estimate and sales conditions, and there is no need to model these detailed planning values first in BW-BPS.
Planning with SAP R/3 and SAP BW – Feature comparison
Profitability Planning:
If valuation with negotiated prices and calculated standard costs is a must, CO-PA must be a part of profitability planning. If sales prices / product costs come from other systems or are entered manually or calculated as averages from actual data, BPS gives much more freedom and enhanced functionality.
Cost Center Planning
Plan price iteration is not available in BPS. However, BPS gives much more flexibility in modeling your plans according to your business needs and provides enhanced functionality. Whenever the output of cost center planning in BPS has to be transferred back to R/3 the necessary retractors are available.
Investment Planning
R/3 IM should be used for local investment planning (incl. Workflow for approval) and realization as these planning objects lead to actual data in the exact same structure. Values that are marked as „strategic“, can be extracted to BPS, changed and retracted to R/3.
Profit Center Planning
It is recommended to do profit center planning in BPS due to higher flexibility and strong integration to other plans. Interaction with R/3 is ensured via Extractor and – in future – retractor Planned depreciation If plan depreciation is needed on a detailed level (e.g. capitalized fixed assets) the FI-AA functionality should be used. The results may be downloaded from R/3 and uploaded into BPS via CSV / Excel. For integrated scenarios (e.g. with investment planning) the formula function in BPS is recommended as it allows you to plan on a less complex level.
Headcount Planning
Planning close to the structures of actual data should be done in R/3, aggregated plans in BPS Planning in CRM Uses BPS technically for Sales Planning, Key Account Planning, Marketing Planning, Campaign Planning.Therefore Positioning against each other is not required.
Related Posts
No comments :
Post a Comment