Early positioning of organizational change management during your implementation process

In reality, supporting a BI solutions in BAU mode can be challenging not only because there are no documentation or insufficient knowledge transition but there are many important points that were only known by the project consultants which  were not possible to be knowledge transferred or documented fully at the end of the project milestone.A lot of times, the issue is only discovered when the report is showing inaccurate data or process chain fails. This can happen if a working solution is not robust enough to handle different type of future changes and scenarios.Hence it is important for a professional project consultant to document and highlights areas of common maintenance required, known bugs and customized/hardcoded method applied during the implementation process. To ensure the smoothness of handover, this has to be reviewed and updated periodically during the implementation phase and not only at the stage of near completion as what most of the project practices. This is to ensure a complete understanding of the solution and a proactive working partnership between the project and the clients/support. Some of the crucial points that can be covered in this area:

• customized abap program to lookup mapping values or selection of period filtering
• deletion selection in the process chain
• process chain failure root cause
• possible enhancement area in the transformation logic (any hardcoded values that can changed or added in future)
• impact of changing a web template or query objects to the other items in same template
• shared datasources and infoobjects and the dependency 
• any customized objects sits on erp/feed system 
• which master data attributes required to be maintained when new assignment is added
• roles and authorization matrix (usually liase with S&A and Portal team)

Bye to CO-PA BW backend and welcome CO-PA HANA?

Read the full article here.

Production Support Project TCODE

The consultant is required to have access to the following transactions in R3 :

1. ST22 
2. SM37 
3. SM58 
4. SM51 
5. RSA7 
6. RSA3
7. RSA6
8. SM13
9. SE16
10. RSO2

Depending on needs:

1. SP01
2. DB02
3. SM14
4. SUIM
5. SM01

Authorizations for the following transactions are required in BW:

1. 1. RSA1 
2. 2. SM37 
3. 3. ST22 
4. 4. ST04 
5. 5. SE38 
6. 6. SE37 
7. 7. SM12 
8. 8. RSKC 
9. 9. SM51 
10. 10. RSRV 
11. 11. RSMO

Query Design Tips for Performance

• Use filters - use as many as possible to reduce amount of data need to read from source
• Use the 0infoprov in query restriction if data model is designed in a multiprovider that contain data segregated by same definition for each Infocube
• Avoid using condition and exception
• Use free characteristics - use as few as possible
• Use restricted key figure with care - generate more complex sql
• Use more than one structure with care
• Characteristics/Navigational attribute are more efficient than hierarchies
• Avoid complex queries - consider RRI to offer analysis path rather than define queries showing everything in the infoprovider
• Check the Use Selection of Structure Elements option

*While filters are evaluated by the database, conditions and exceptions are usually 
evaluated by the application server resulting in a much larger volume of data being transferred between both servers.

Some throw in for BI Whitepaper titles

1) IT Globalization impacts to BI and ERP
2) ERP convergence impacts to existing BI landscapes
3) Global template architecture and its feasibility in long run and local change management
4) The handshake relationship between BI and its feed partners - APO, SRM,CRM, ERP
5) Master Data Management gearing up towards ERP convergence
6) Reaping benefits from Consolidated Financial Reporting
7) How BI plays its role in bridging the gap between a fragmented business entities and Global Enterprise Model

Dimension attribute, navigational attribute or display attribute?

When modeling the infocube, the decision to include the infoobject in the dimension object itself or either as a navigational or display attribute is influenced by
1) slowly changing dimension/historical data view
2) cleanliness of the master data

Display attributes values are stored in the dimension table itself and it has its advantage such as data will reflect data from the historical-truth perspective.The disadvantage is the data in the infocube has to be reloaded if there is unclean or changed of master data assignment to the value of the infoobject which happen quite frequently in a global alignment environment. If the impact of truncating the infocube and reload is too high, a new infoobject that refers to the same business object may be introduce to replace the one with unclean master data. The later one may be labelled as 'no longer in use'.

Navigational attribute values are not stored in the dimension table but in the attribute table of the characteristic used in the infocube. Any changes to the attribute value assignment of the infoobject does not require the realignment of infocube. It may however require realignment of the aggregate containing the navigational attribute. If the infoobject and its attribute values are used in hierarchy , the hierarchy may required to be drop before the attribute value can be changed.

If the value is stored as a display attribute, any changes on the value of the attribute of the infoobject won't impact the data in the infocube as the display attribute is not stored as SID in the dimension table.Display attribute does not support drill down reporting and it can only be displayed in the report.

Either it's navigational or display attribute, the report will always refer to the current value in the master data and modelling the infocube with this approach does not support historical-truth.

Common questions posted during handover

1) How do we manage the number of records in error stacks?
2) Identify owner of mapping and filter tables
3) Test on unit and currency conversion done?
4) Data release mechanism tested?
5) Yearly process chain or mechanism (such as balance brought forward) tested?
6) Any master data issue and escalation process?
7) Cleaning up of obsolete objects?

Intercompany Elimination - how BI helps to reduce manual workload

When preparing or combining consolidated balance sheet,routine manual finance task is required to deduct the intercompany items between a parent and its subsidiary. This can be done either through manual adjustment (by manual entries) or through dummy account posting.

However, there is a feature in BI that allows this deduction to be done automatically. It uses the elimination feature in the key figure infoobject (SAP reference). The elimination is by each characteristic pairs or done via start routine in the transformation for a more complex approach such as elimination at parent-child level (Intercompany elimination). The elimination figures is calculated in a separate flow and consolidated in the financial multiprovider for reporting.In a global environment, the different regions must have the standard and consistent master data that is referred to during the elimination such product (SKU) , selling business unit and buying business unit.

The business rules behind intercompany elimination:
1) IC sales -done as soon as data available in BI(dynamic) for the following account:

• Internal Net Turnover
• Bought in Goods
• Primary Supply Chain Cost

2) IC margin -done monthly
3) Profit in stock (involve IC margin and sales volume) - done monthly.Eg:

• 6 month rolling IC margin in June will be based on Jan-June IC Margin / Jan-June IC Sales volume
• 6 month rolling IC margin in July will be based on Feb-July IC Margin / Feb-July IC Sales volume

4) There are 2 types of elimination:

• Intracompany Elimination

BI will eliminate when the BU/Entity has an identical corresponding Partner BU/ Partner Entity

• Intercompany Elimination

BI will eliminate when the BU/Entity and the corresponding Partner BU/ Partner Entity
belong to the same level of the market hierarchy (eg. same End Market, Cluster, Zone, Area or Region)

The Framework of a BI BAU Organization

Change Management Framework - To be able to access the BI related changes and impacts from current development and changes in feed system, identify escalation party
Business Release Framework - To ensure the changes land successfully in the BR timeline, ensure the readiness of infrastructure and no impacts resulted from the transports
Quality Assurance Framework - To ensure no or minimal risks or defects landing into the system

Future of SAP BI?

Ok, we all know BO is gonna replace SAP BEx (not in near future) but HANA to wipe off the datawarehouse? This is like hardware evolution vs the datawarehousing technology. HANA 1.0 is more like the BWA but going forward, SAP's roadmap was to replace BW database with HANA, main memory cache is used to store data copy of database. But the BI application server is still to be used on top of HANA in addition to separate application server for ECC.

In-memory is going further to eliminate the need for a separate OLTP system . BI analytical capabilities are directly incorporated into the ECC system and allow all analytics to be run on operational data (ECC data). But hey, it's still a long way to go.

The BI Delivery E2E Bird Eye View

A successful BI delivery in any organization is actually an end to end process which involves a lot of parties and bridging of gaps between them. A common overlook in most organization is the lack of involvement of business (yellow box) and the bridge between the different parties (red arrow) that result in a long term lose of credibility from users and this leads to the failure of BI delivery.

Without the business involvement from early start coupled with the straight timeline of delivery, the project is eventually pushed to deliver a solution base on technical go live as there is a problem securing the business user's involvement at the last milestone of the project. A BI solution that is delivered into BAU without business go live is at high risk of capturing the bugs and issues later on when business starts to be engaged and they reveal tons of issues from the solution. This eventually leads to a lost of credibility on the BAU organization when it fails to deliver a lot of major fixes required by business due to the fact that those fixes are not ready to be taken on by Support team and the project team had left when the project was declared technical live. In situation like this, is it politically correct to say the BAU organization is subjected as the 'victim' of the whole process?Which party is going to fund the cost if the project team is required to stay back to fix the issues? That is the reason a solution that is fit to land into BAU mode has to be both technically and business live. The BAU organization has the authority to raise a red flag to prevent a solution to land into BAU state without proper sign off from both technical and business.

The other common overlook is the knowledge transfer and skills capability from Project to Support team to maintain the solution (blue arrow). Often if this is two different teams or companies,there will be a gap of knowledge transfer for Support team to take on any major bug fixes or enhancements, thus leading to a high turnover time that at the end resulted in business losing confidence of the BAU organization to ensure 'business run as usual'.

Transport Watchout!

During the imports of a BI transports, the following should be look out:
1) Double check if Function Group or Shared User Exit are intentionally needed to be transported
2) Old transport overwrite new ones (esp in a multiple solution development environment)
3) Orphan transport left in non production system