Error Stack Handling

This is bound to be a debatable item for any BI solution on the owner of the error stack in BAU mode whether Support or Business users. Before the developer switch the error handling mode in DTP, please consider the fact of 'real' records that supposed to fall in error stack and those supposedly be filtered out before transformation level. Support also has the tendency to switch on the error stack in cases where a lot of data that were supposed to be filtered out causes process chain to fail.

'Real' records that suppose to be monitored in error stack are:

• data related to mapping logic
• data dependent of master data attribute to derive

The above points to the fact that the error stack management should fall into the master data,business user or SME as to correct those records, business logic is mandatory.

Unnecessary data which supposed to be filtered out (usually in start routine) are normally data that is not used from that module. Example records from certain sales organization are not needed to be reported can be filtered out before it went into the transformation level.

0FI_GL_6 and when 0FI_GL_4

0FI_GL_4 Extractor works in different way . Init and delta is based on system date .So only one delta is possible in each day . This is applicable for older SAP PI release until 2004.1 and there is a OSS note to enable minute base delta. Please refer to OSS note 991429.

You can obtain detail information of 0FI_GL_4 extractor here.

In BI we extract 2 types of General Ledger information

• Opening Balances (once a year, starts only on 1.1.2011) Take from 0FI_GL_4.
• Line items postings (daily) Take from 0FI_GL_6.

If you have ECC version 5 above, you can opt to use 0FI_GL_10 for transaction figures (balance carry forward) and 0FI_GL_14 for line items. If you have EhP3 upgrade on your ECC, there is a new option to use 0FI_GL_20 for transaction figures and 0FI_GL_40 for line item. The downside for 0FI_GL_20 is this data source has after image delta and therefore a DSO is required to enable delta. For  0FI_GL_40, it is by default not delta enabled  because ist specifically created for the Remote Cube.

§

Outsourcing, BAU and CAB

In most big organization,resources are often categorized as 'Value Add' and 'Commodities'. 'Commodities' groups are often outsourced and this include developers and supports. 'Value Add' groups are BAU organization and often comprises of management and gatekeeper who contribute to impact analysis and decision making on certain action or escalation point when issue or change arise. They tend to form a lean organization structure who participate in advisory,coordination and management workforce. In order to have a standard agreeable escalation point either to project as enhancement or support as bug/break fixes, the Value Add group's decisions need to be governed by a set of rules call 'CAB exemption list'.

As the structure and solutions in an organization are different, the way this exemption list evolves is different. But the baseline of arriving at a standard agreeable ownership of issues and clear defined process has to be based on the content of the list. This list is an ongoing efforts to put down the ownership of issues based on the objects together with different type of scenarios that could possibly trigger the change of the object. Eg. In cases like a DTP,missing DTP is categorize as CAB1 as this impact the daily process chain while new DTP filtering rule are CAB2 as it may be an enhancement to cater for any new business rules. Any new scenarios need to be discussed in the CAB meeting to agree on which category it falls into, either CAB1 or CAB2. In a nutshell, CAB1 is a list of responsibilities held for bug and break fixes. CAB2 is a list of objects that involves enhancement to existing design. Small/easy enhancements such as adding values to the condition of filtering can be addressed by Support team wherelse multiple enhancements or big enhancement can be grouped into a mini project that falls into project.

It is still a debatable subject on whether SME falls under 'Commodities' or 'Value Add' group. This question back on the reliability to outsource entire development work to vendors with only indirect participation of BAU during build review session. SME of BI solutions requires a thorough understanding of technical and functional requirement for a particular solution and they are the best people to perform any impact analysis to the proposed solution. Most of the BI impact assessment are technical as they are the receiver system of the business change in the feed system of R/3,external system or APO.As such it is possible that the technical impact assessment can be done via the help of BI meta-repository and a where-used lookup. There are other exceptional cases in which changes in R/3 or feed system has to be impact analyze at BI level due to the nature of datasource or content being 'modified' at source system level (Please refer to my other post on this). This is because the projects are often the expert of the solutions because they design the solution and the gatekeeper will not have the necessary detailed insight of the design and build unless it's from blueprint and walk through sessions. The gatekeeper may not be involved in Support issues as well unless the support team is not performing according to their job scope.Support on the other hand is the group who understand the in and out of the flaws of the design as they are the front liner for any issues logged by business users.

It is also a common overlook of role feasibility when a BAU organization which aims to be a lean organization in IT services starts to streamline all 'subjects' (especially in BI where it consist of a range of different solutions for different reporting purposes) into one single SME role and further extend the role to a 'Value Add' gatekeeper role who held responsible for any changes that land into the system.

On top of all that, the next successful outsource strategy will evolve around the concept of 'long term partnership' and not base on mere vendor-client relationship as it takes a close knitted working relationship to form a successful IT organization in a corporate company.

The thing about APO-BI Integration

The major issues with the data reconciliation between APO and BI is:
1) In APO, the planning does not use source system but in BI, the materials are compounded to source system based on the nature of multiple R/3 regional boxes feeding data to one regional SAP BI instance which in turn consolidate with other regional BI instance to consolidate data at Global BI instance. There are incidents where same SKU may exist in 2 regional R/3 source but refer to different material.
2) In APO, the planning does not plan by base UOM or ISO UOM, it always plan in PUM. Hence when data is send to BI, the conversion factor must include converting base on PUM to the base UOM and then to the ISO UOM or CORE UOM.

Common Bugs, Breaks and Enhancements

Whether it's in the phase of project transitioning into BAU or already in BAU mode, there are common major bugs,breaks and enhancements in SAP BI that are needed along with the standardization of master data (that runs in parallel with ERP convergence) . It is always a long back and forth discussion on who is the responsible party to be responsible for those changes and on which category the desire fix falls into whether it's a project defects(bugs), breaks (resulted from changes of other things) or an enhancement. This is important as it lead to the party who will fund the fix.

Here is a list of common bugs, breaks and enhancements in a highly integrated SAP BI platform:
Bugs

• Web template functionality
• Inconsistent coding logic applies in routines with the same business rules
  

Breaks

• Changes in shared user exit
• Changes in the shared infoobjects

Enhancement

• Adding navigational attribute
• New flow/enhanced datasource to pick new fields
  

Integrated system and impacts

BI in a change management environment has its challenges in terms of dependency to other source system such as ERP and APO. Generally changes in ERP and APO or any feed system has impact to BI as BI depend on the source system for data. The changes in feed system can be driven by new business requirement(functional) or technical. Example of these are:

New CO-PA analysis object
This impact CO-PA extraction as the generic extractor for CO-PA cost based is value field specific thus any new one will require a new datasource to be generated and new initialization.

Realignment of CO-PA
CO-PA realignment is done in ERP side when there is a need to move SD related data in CO-PA from profit center A to profit center B. Any configuration that is done at operating concern level and create additional entries in table CE4XXXX will require reinitialization of COPA datasource at BI side. The date of reinit has to get business user's approval as when the new change in r/3 has to be reflected in BI.

Any ERP realignment from Project or enhancement CR or any activity on transaction KEND in Production system via firefighter ID will impact the COPA delta extraction in BI.

Scenario:
Finance
1) COPA datasource is used in F17 reports for data above gross margin and sales volume.
2) Realignment occured twice in Production server region A on 05.01.2011 and 09.12.11 to move SD related data in COPA from BAHEXP to MEBIXP profit center and ZAFIXP to BSAIXP profit center.
3) This resulted in the delta extraction from COPA datasource (1_CO_PA500AM01_1) in S+ to fail on 06.01.2011 and 24.12.2010 because the delta updates is no longer possible due to the data is inconsistent between the OLTP and BI. This is a known SAP scenario as stated in OSS Note 400576.
4) Realignment in ERP will require reinitialization and reload of BI COPA datasource. The date of reinitialization is also dependent on whether the changes done also affect the historical data.

* Please refer to attachment for evidence of delta update in BI fail due to realignment
Note 400576
KEB2 printscreen

Marketing
1) Marketing extracts billing data from  ERP system region A on a daily basis and there is no data retrieved for end-market specific business rules since beginning of November 2010.
2) The interim solution from BI is to ask the end markets to enter the data via manual entry until the sales volume flow is switched to COPA from SD Billing.

COPA additional value field
Example would be VAT is calculated in COPA report in ERP system region A but not in BI report.To get the VAT amount, it needs to be captured separately into another value field for VAT.

Hence a new extractor for that particular controlling area need to be generated to capture the two new VAT value fields :-
VVU88 VAT on Bulk Discount
VVK89 VAT Amount

Material Classification characteristics
The attribute of material classification such as length and unit of measure has to be consistent across the r/3 instances so that the structure generated in development can be used in test,regression and production when it got imported to the other landscape during cutover. If not, the extraction from those material classification will fail.Eg: Material A UOM  maintained in Regression server as GM but nothing in Development box.

APO datasources
APO datasources such as MALO and MALORE which had been modified at APO end needs to be replicated to BI and coordinated within Business Release calendar so that it won't impact the daily data load.

Market migration
Market migration to other regional ERP box has impact to the data BI is extracting as new business rules has to be defined in BI to pull data for the migrated markets from the other system.

Changes or standardization of master data
Decommission of any material characteristic or its value which is used in BI has impact to the master data in BI. Depending on the type of attribute it was modeled in the cube , either navigational or display, the effort can involve the reload of data and missing historical value.

Logical system name conversion
Changes to logical system name has to be straightly coordinated with the dependent system such as BI and EBI APO so that the datasource will point to the correct logical system and has the correct technical name. This is very important to be reflected in the rsyslogmap as well so that the mapping of logical system is done correctly for the DTP and DTP in the process chain when transports are imported over to Test, Regression and Production system.

Master data
Example is changes of area and zone for a business unit. This is triggered from the business and channeled to the MDM team. There is a need to bridge the MDM to BI Support as a downstream impact on the master data change will require alignment in the hierarchy and infoprovider master data.

BI Reality

The reality is :
1) Adoption level and usage of the reports drive the BI business and needs of services from vendor and shared service
2) Business pays for the enhancements and new reports
3) Data accuracy is most important (follow by the availability of reports) and often a lot of build defects or missing/incorrect business rules are realized at later stage. In a multiple SAP R/3 environments, data accuracy and feasibility to consolidate data from multiple systems relies on the data standards and business rules. The data standards is usually adopted in the source system and extracted to BI but in some cases, there will be a requirement to standardized the master data in the BI layer due to the complexity of getting it done in R/3. Eg. to measure the consolidated sales of the same product which is name differently in different systems.

Global and Regional Authorization Concept

Concept:
- Global AA role (A)
- Global role (B)
- Global composite role (A+B+E)

- Regional AA role (C)
- Regional role (D)
- Regional composite role (C+D)(E)

Authorization can be inserted into roles that are used to determine what type of content is available to specific user groups.

Authorization Objects
Authorization objects enable you to define complex authorizations by grouping up to 10 authorization fields in an AND relationship to check whether a user is allowed to perform certain action. To pass an authorization test for an object, the user must satisfy the authorization check for each field in the object.

SU21 to maintain the authorization objects. Major one starts with RS.

Analysis Authorization (AA)
AA define semantic data slices a user is allowed to see in reporting, eg all data belonging to company code variable xxx that goes through user exit during query runtime. Infoobjects has to be defined as authorization relevant.

AA (Authorization Analysis)

Demand IT in BI

Ensures the reports are utilized
Bridge between end users and BAU organization to obtain the fund for valid/required change
especially in master data changes and standardization
Ensures business users availability of UAT

Business Release in BI

Changes to be promoted in Production system for all the IT system in a big organization that include several regional instances has to adhere to the business release time line.

This is to ensure the impacts are accessed and minimal risk is introduced to the production environment. There is also a need to cross check the dependent changes that ensures the correct sequence of importing the changes in all different systems are followed.

This is very important as:

• Prevent newest changes to be overwritten by old transport(emphasize in orphan transport and transport not in build list)
• Datasource not imported first or replicated after . Eg shared datasources like 2LIS_02_SCL (Purchase Order History) which is shared between SRM and BI (Procurement solution).
• Data loading and transport sequence (top down dependency and cross solution dependency)
• Inactive objects discovered later and development system is opened for new changes, thus re-transport is impossible
• Shared datasource and dataflow are not impacted.eg OTIF(sales forecast) and COPA(sales volume)
• The conversion of logical system name is done in parallel (done in the same BR) for all the 'target' system like BI and APO that feeds on the same ERP system when the feed system change its logical system name.

Change Management in BI

The key success for a Global platform is to have strong governance. In order to produce strong governance in a big organization, a robust and effective process has to be in place. This include the deep understanding of a changes in business and technical that impact BI. One of the rule of thumb of change management in BI is changes in the target system won't impact the feed system but changes in the source system might impact the target system. For example: COPA realignment is done inR/3 which changes the historical master data but BI must reinitialize the delta. New characteristics are created under a new class for new/existing material group. In order to report on the new attributes , BI needs to regenerate its material classification datasource in R/3. A criteria needed to ensure successful change management is the ability to understand the root cause of the issues technically and functionally and address its risk and effort level accurately. Knowing how to identify and fill the gaps between in-source responsibility with outsource capability is equivalently important to drive an efficient BAU process and avoid redundant processes to take place.

The objective of a change process is to ensure there is a standard and control for changes that lands into the system in order to mitigate risk of defects and impacts. But the control must be flexible enough to hold different type of scenarios that range from project mode, project into bau transitioning mode, shadow support mode,post go live, warranty fix mode,technical go live, business go live and etc. Eg. during warranty period or post go live mode, it is impossible to demand for a CR for each fixes as it is not uncommon at all to spot handful of bugs and breaks in those period. At some cases, when project and demand IT team are not in agreement of the project release timeline, there will be a release for technical go live and only when there adoption of the BI reports by business users, the project is moved to the business release go live stage. Such scenario is very complex to handle in bau management and project resource management, especially the technical warranty period is lapsed but more issues were encountered during business go live. At such, the process of change management should be flexible enough to apply different level of control at different stage.

BI Readiness in the Global Arena

• Adoption level of the regional business users to utilize the BI reports as a reliable source to make decisions
• A BI roadmap that ensures strategical implementation, maintainability and governance that adhere to a tactical operational model
• Standard business rules that might impact the data mapping and conversion factor that needs to be in agreement by all regional stakeholders
• Readiness of standard master data
• Establishment of inter dependency between BI and ERP/APO/source system
• Existence of Demand IT and body to govern the functional changes
• Existence of Information Office to bridge the business users , the Demand IT, the Solution
• Delivery and the Solution Center
• Solid process and efficient of business release management process
• Strong governance and efficient change management process
• Good partnership of BAU organization with project and support team