ASAP Methodology

ASAP stands for Accelerated SAP methodology which is used to implement and deliver the project efficiently.

The five stages of ASAP methodologies are-

Project plan, Business Blue print, Realization, Final preparation & Go-Live - support.

1. Project Preparation: In this phase the system landscape will be set up.

2. Business Blueprint: It is a detailed documentation of your company's requirements. (I.e. what are the objects we need to develop are modified depending on the client's requirements).

3. Realization: In this only, the implementation of the project takes place (development of objects etc)

And we are involved in the project from here only.

4. Final Preparation: Final preparation before going live i.e. testing, conducting pre-go-live, end user training etc.

End user training is given that is in the client site you train them how to work with the new environment, as they are new to the technology.

5. Go-Live & support: The project has gone live and it is into production. The Project team will be supporting the end users.

The BW ASAP Methodology Implementation Project phases:

1.Project Preparation / Requirement Gathering

2 Business Blueprint

3 Realization

4 Final Preparation

5 GO Live & Support

1. Project Preparation / Requirement Gathering:

Collect requirement thru interviews with Business teams /Core users / Information Leaders.

Study& analyze KPI’s (key figures) of Business process.

Identify the measurement criteria's (Characteristics).

Understand the Drill down requirements if any.

Understand the Business process data flow if any.

Identify the needs for data staging layers in BW – (i.e need for ODS if any)

Understand the system landscape.

Prepare Final Requirements Documents in the form of Functional Specifications containing:

Report Owners,

Data flow,

KPI’s,

Measurement criteria’s,

Report format along with drilldown requirements.

2. Business Blueprint:

Check Business content against the requirements

Check for appropriate

Info Objects - Key figures & Characters

Check for Info cubes / ODS

Check for data sources & identify fields in source system

Identify Master data

Document all the information in a file – follow standard templates

Prepare final solution

Identify differences (Gaps) between Business Content & Functional

Specification, Propose new solutions/Developments & changes if required at different levels such as Info Objects, Info cube, Data source etc. Document the gaps& respective solutions proposed– follow standard templates

Design& Documentation

Design the ERD & MDM diagrams for each cube & related objects

Design the primary keys/data fields for intermediate Storage in ODS

Design the Data flow charts right from data source up to Cube .

Consider the performance parameters while designing data models

Prepare High level / Low level design documents for each data model. --- follow standard templates

Identify the Roles & Authorizations required and Document it – follow standard templates

Final review of design with core BW users.

Sign off the BBP documents

In this phase you create a blueprint using the Question & Answer database (Q&Adb), which documents your enterprise’s requirements and establishes how your business processes and organizational structure are to be represented in the SAP System. You also refine the original project goals and objectives and revise the overall project schedule in this phase.

Functional requirements should cover minimum of the below check list

Business Objectives and Benefits

Business Scope and Events

Business Process Scope

Future state process improvements

Business KPI s

Reporting Requirements

System/Client Strategy Interface Requirements

Source System Mapping

Field availability (Master data + Transaction data)

Transformation details

Data availability frequency

Data availability type

System availability and Outage window

Data load dependencies

History Data Load availability

Data Volume

Data Reconciliation

Data retention

Contingency Planning

Authorizations

Transport Strategy

Capacity /Resource Planning

Gap Analysis

Integration and Policy/SOX consideration

Support– Service Level support /Production support

Change Management

Technical requirements - Take a BI report ,translate functional requirements in to technical design.

Map KF, Characteristics, Free Char, RKF,CKF

3. Realization

Check& Apply Latest Patches/Packages ...in BW & R/3 systems.

Activate/Build& enhance the cubes/ODS as per data model designs...maintain the version documents.

Identify& activate Info objects / Master data info sources / attributes ,prepare update rules

Assign data sources .prepare transfer rules , prepare multi providers . prepare Info packages .

Perform the unit testing for data loads….both for master data & transaction data .

develop& test the end user queries .

Design the process chains ,schedule & test

create authorizations / Roles …assign to users ..and test

Apply necessary patches & Notes if any .

freeze& release the final objects to quality systems

perform quality tests .

Re design if required . (document changes, maintain versions)

4. Final Preparations:

Prepare the final check list of objects to be released .identify the dependencies & sequence of release

Perform Go Live checks as recommended by SAP in production system

Keep up to date Patch Levels in Production system

Test for production scenarios in a pre-production system which is a replica of production system.

Do not encourage the changes at this stage.

Freeze the objects.

5. GO Live & Support:

Keep up to date Patch Levels

Release the objects to production system

Run the set ups in R/3 source system & Initialize Loads in BW

Schedule Batch jobs in R/3 system (Delta loads)

Schedule the process chains in BW.

Performance tuning – on going activity

Enhancements- if any

0Record Mode

0recordmode is a field which is added in the DSO level. It helps in fetching the after & before images of data.

First: the 0recrodmode controls how data is posted into cubes or ODS (DSO) Objects.

N for new records
B for Pre Images
' ' for after images
R for Reverse Images
X for Storno
D for Deletion of a Key (only in ODS possible)
Y-Update image

You would see the significance of the 0RECORDMODE if you look at the change log table of the ODS. When the data is loaded for the first time the 0RECORDMODE would get assigned a value "N". Now if you reload the data after sometime and lets say 1 of the records were modified then there will be 2 additional records in the change log table with 0RECORDMODE "X" and "" where X corresponds to Before image and "" corresponds to After image.

So when you do a delta from the ODS the system automatically picks up the changed records from the ODS (using the change log table) based on the 0RECORDMODE value.

Multi providers

Multi providers (just a structure, not a physical data store object like cube or ODS) is the union of infoproviders namely Infocubes, ODS , master data tables.

This is just a union of more than one infoproviders, for example if you have a requirement that you need to compare plan data vs actual data OR last year data vs current year ...or similar scenarios. Then it may be easy hassle to create different cube and create a multiprovider then design your report out of multiprovider. Just keep in mind that you need to have at least one similar char in all the infoproviders which includes in your multiprovider.
You can create multprovider of any of the following:

1. Infocube
2. ODS
3. InfoObject
4. Infosets.

Identification Tab:

Identification tab is for system to identify which char. in multiprovider maps to which characteristic in the specific base providers.

The same characteristic may be present in more than one of the base InfoProviders of the multiprovider.

Also one characteristic in the multiprovider can be matched to another characteristic in one of the base providers which is of similar data type and length.

E.g. you could match 0CUSTOMER and 0SOLD_TO (because 0SOLD_TO has reference characteristic 0CUSTOMER), but it is not possible to match e.g. 0MATERIAL and 0MAT_SALES (because 0MAT_SALES is compounded to 0SALESORG etc.).

Eg: If you have 0VENDOR in ODS1 and ZVENDOR in ODS2 and you want to assign them to the same Multiprovider characteristic 0VENDOR, you need to have ZVENDOR created with reference to 0VENDOR.
If the ODSs are productive I'd suggest creating an ODS3 that is filled out of ODS2 but with 0VENDOR instead of ZVENDOR.

Variables

Variables are parameters of a query that you defined in the Query Designer and that are filled with values when you execute the query or Web application. They serve as a store for characteristic values, hierarchies, hierarchy nodes, texts and formula elements, and can be processed in different ways.

Variable Type /Processing Type	User Entry / Default Value	Replacement path	Customer Exit	SAP Exit	Authorization
Characteristic	ß	ß	ß		ß
Text	ß	ß	ß
Hierarchy	ß		ß
Hierarchy node	ß		ß		ß
Formula	ß	ß	ß

1.     Characteristic value variables represent characteristic values and can be used wherever characteristic values are used.

2.     Text variables represent a text and can be used in descriptions of queries, calculated key figures and structural components.

3.     Formula variables represent numerical values. You can use formula variables in formulas. Numerical values are also used for calculating exceptions and conditions.

4.     Hierarchy variables represent hierarchies and can be used wherever hierarchies can be selected.

5.     Hierarchy node variables represent a node in a hierarchy and can be used wherever hierarchy nodes are used.

1.      If you choose User Entry/Default Value as the processing type for a variable, you can enter the required value for the variable manually in a dialog box when you execute the query. You enter a default value when you create the variable. This default value is then displayed for input-enabled variables in the input field of the variable screen. For fields that are not input-enabled, the default value is used as the variable value.

2.      The processing type Replacement Path enables you to specify the value that automatically replaces the variable when the query or Web application is executed. i.e., Characteristic value variables with the processing type Replacement Path are replaced by the results of a query.

3.      The Customer Exit processing type for variables enables you to determine values for variables by means of a function module exit. The function module used is EXIT_SAPLRRS0_001. (You create a project in transaction CMOD by selecting the SAP enhancement RSR00001 and assigning this to the enhancement project. Activate the project.)

4.      The SAP exit processing type is contained in variables that are delivered with SAP BW Business Content.

5.      If you choose Process with Authorization, the variable is automatically filled with the values of the user's authorization. When the user opens a query, the data is selected automatically according to his or her authorizations.

Variable offsets

To analyze key figures that have a fixed time-relationship to one another, you can use the variable offset. For example, you want to compare the sales volume from the current time period with that of the same time period in the previous year. In your report definition, you can use the same variable several times to restrict the key figures and determine a difference from the input value.

You can also use the variable offset to select an interval as a restriction with upper and lower limits that refer to the same variable.

1.      To do this, in the upper-left selection field, choose Value Range and between as the operator.

2.      On the Variables tab page, select the required variable and move this using Drag & Drop (or using the arrow key pointing to the right) into the right selection window.

3.      Now specify variable offsets for the upper and lower limits

Replacement Path

Replacement path processing type is used in a variable when you wish to get a value from attributes of another character or from a query.

Example:- if you wish to display the age of a customer in your report which will not be in the cube. I mean Age is attribute of customer and not part of the cube. But each transaction record in the cube is assigned with a customer field. So if we want to get this value into our report .. we create a variable on customer with replacement path and use its attribute AGE . So when you use this variable in your query for any thing you get the age of the customer associated with that transaction data.

One use of the Replacement path variable is as highlighted by Riccardo (formula variable).

Other than that Replacement path variables of type Characteristic variable replace the results of a query in the variable ad are used in Result Set scenario queries. So if you have such a variable on material, Query1 will supply a list of Materials to Query2.

Replacement path variables are also used to enhance the column headings as Text variables. Eg, A text variable created that will put the text for each month on the column heading.
Characteristic Variable with Replacement Path on Query
While working for TOP-N Vendor Report I encountered the need of Replacement with Query
We already have Report to Calculate TOP-5 Vendors of the Year, and recently I got new requirement to update this report for analyzing the TOP-5 Vendors of the year over all the months of the given year. I tried simple approach by creating multiple selections for all the months individually in Columns, and created condition of TOP-5 for all the months. But it didn’t work in the way I was expecting. It included TOP-5 Vendors of each month individually, which added some new vendors to analyze in my report. Then I tried the same solution with the Replacement Path on TOP-5 Vendor Query (which I was already having in my system), and finally it worked fine for me.
Below is the detailed explanation of the scenario that I discussed and the problem I faced with the alternative approach, and how it solved with the approach of Replacement Path on Query:

Advantages Of Bw Reporting Over R3 Reporting

1. Moves the workload off the R3 system. Most sites are trying to run is little reporting off of R3 to maintain server performance for the OLTP users. R3 is not optimized for reporting - it's a highly normalized DB design.

2. BW - better query performance. It's been optimized for that, the DB design, features like OLAP and web caching, reporting agent, aggregates, etc...

3. Many more formatting and distribution options - Excel, Web. Reports can be scheduled to run off hours and cached for very quick access during business hours or e-mailed to users.

4. Reports (queries) can be easily setup for variables to parameterize the report and users can save their different selection options as variants.

5. User can modify the report with drill downs, drill across, sorting, modifying selection criteria, change display of key, key and text, or just text.

6. Quicker changes to the queries, addition of fields in BW environment, don't need ABAP developer.