There will be occasions where the data you receive in your regular monthly Finance pack is incorrect. It could be something like some Profit Centre information is missing, or a range of revenue or expenditure is missing. The natural reaction is generally to assume that there is an error with the report, which then leads to a ticket being raised for your internal SAP support team to review it. In most cases this is batted across to the SAP BI team to look into, identify and see if they can fix the problem. From experience, a change would be made in SAP BI to change some of the data mapping, or write a business rule to re-engineer the data so it is in the correct format.
The question I have regarding this process is around the approach being taken. Would it be better to review the source data to understand why the data has changed? Has someone opened or closed a new GL account or Profit Centre? Is the cause of the issue the new GL account's settings which don't have the correct, tax, currency or field status settings? If we could get the data flowing correctly from the source system (SAP ECC) then the level of re-work, mapping and bespoke coding in BI would be reduced?
I was recently talking with a client to see how we could automate their consolidation process. They had the best part of 50 manual tasks that they wanted to automate through an SAP consolidation product. To produce an estimate for automating the manual tasks we asked for some detail around the steps that they performed each month. Rather than go through all 50, we picked a sample of tasks to enable us to produce a more accurate estimate. The first example was pretty simple. They needed to convert certain balance sheet entries to the group currency. When quizzed over this, the SAP BI team said they only extracted the local currency data, and then performed a manual task to convert the local balances into the group currency. We then reviewed the source data (SAP ECC) and found that the group balances were available, and the need for the manual tasks was not required, so the need for automation (extra build) was removed. The fix was performed by aligning the SAP ECC data that was being extracted so the correct data could be used within SAP BI without any manual effort to reformat the report.
So what is the best approach?
Every problem and issue with an SAP BI report will be different. Data could be missing, not up to date, have incorrect mapping and so on. However the approach to dealing with issues should be common. The best place to start is to look at what the issue actually is and define the cause. Missing data and old data could be fixed by making a change in the SAP ERP system - or creating bespoke tables in the SAP BI landscape to overcome the issue. Firstly it is important to look at all of the options that are available. Neglecting to look in both systems will invariably lead to a restricted decision being made. In some cases you may be lucky and make the right change, however you are limiting yourself.
Having consultants that are familiar with both systems would be ideal. If the SAP BI consultants understand the source system and data, they will be in a better position to make a more informed decision. Where the SAP BI team do not have the correct knowledge of the source system and data, they need to ensure they involve the necessary resource from the source system to ensure the correct decision is made.
What will be the outcome?
It is very simple for an IS division to state that as an objective they want to avoid bespoking the solution. Cross-system governance is required to ensure that whilst one system stays standard, it should not lead to another becoming further bespoked. Projects and support activities can be done in isolation - so an SAP BI report query would be passed to the SAP BI team to resolve. Any proposed fixes and changes to the core system design should be passed to a cross-system governance team that can provide guidance to ensure that the system where the proposed change is to be made is the correct one.
Cross-system governance or business owners who are system agnostic, seems like sensible approaches to this issue. Complex landscapes where data consolidation covers many systems can be simplified by using common processes and talking in a common language. Having the correct level of governance and guidance should enable a client to make changes in the correct system and let the data flow freely through the landscape. Accurate reporting is based on accurate data and common definitions of the data. The key message is simple before you make a change to an SAP BW report check to see if the source system has the data in it.