Unlocking information in BW
Sunday, 22 July 2012
Posted by Tom Venables
BW systems present some very specific challenges when authorising access to data, so for this series I want to talk about some of the key points of control to consider.
The first of these, as you will see, is about ensuring your reporting users understand the system and its uses:
BW is not your operational database!
While this may seem an obvious statement to make, it is important at all stages of designing your reporting solution to consider the purpose of the BW reports, it is very easy to lose focus on the purpose of a data warehousing and reporting system.
Many organisations have implemented SAP BW to provide reporting capabilities, but have fallen into the all-too-easy trap of using BW to provide data which is already accessible in the source system. Operational reporting such as this does not take advantage of the data warehousing capabilities of the tool while presenting unnecessary challenges to the authorisation design:
e.g. The need to secure fields within BW requires activation of multiple characteristics to attempt to replicate the authorisations in the source system, while this level of protection may not be essential to deliver the management information required and, due to the “all or nothing” rule in BW, can impact the delivery of other reports.
If you have identified that there are large volumes of ad-hoc reporting taking place from the BW system, take the time to understand the requirements of the highest volume users and explore options for providing similar reporting capabilities from source ERP systems. Solutions such as ad-hoc query or tailored reports from tables in the ERP can provide much more effective solutions for these users and ensure you can focus on delivering the strategic and tactical reporting for which you have invested in BW.
Why is this important?
Without a clear understanding of the data consumers, it is extremely difficult to design all components in a way which will support not only the reports themselves, but the authorisation for the data contained in those reports. It is common for operational reports to act simply as a “data-dump” tool for business users to see all detailed data pertaining to a specific operational requirement, be it tracing all information about an account, or seeing all data relating to employees. Management information often does not require this level of detail and inclusion of these details in reports presents the first point of challenge in designing authorisations – the need to secure details is often greater than that to secure aggregate data within the BW system.
Management teams would like to track bonus payments per team, but do not require the details of the payments to individuals to meet these KPI requirements. Knowing how a team is performing against a metric will tell management what they need to know, dealing with an individual case within that team takes us to a level of detail which is more appropriately handled at the detailed information level which is already available for individuals within the source system (with appropriate authorisations in place)
In this example, it is possible for the data warehousing architects to ensure that only the high-level or summary level information is presented in the reports to managers, to provide a view which will show how each organisation, branch and /or team is performing against the metrics defined. Because we do not need to display specific details of individual records, the need to secure the data within the report is lessened, which allows us to keep the authorisation concept simple. This drives cost savings in terms of support and greater transparency in the event of an audit, helping to demonstrate control across your SAP landscape.
By adhering to the first principle: Ensuring data is appropriate for the needs of the report, your authorisation specialists will be able to focus on areas where there is greater need to provide technical solutions and let the processes and understanding of BW take the lead in these high-level reports.
As we continue this series, we will look into other fundamental principles in achieving a secure and compliant BW landscape which will complement your wider SAP architecture. If you have any comments or questions, please feel free to use the comment submission below.
- July 2015 (1)
- May 2015 (1)
- January 2015 (2)
- December 2014 (1)
- September 2014 (1)
- August 2014 (2)
- April 2014 (1)
- February 2014 (1)
- December 2013 (1)
- October 2013 (1)
- June 2013 (1)
- May 2013 (1)
- March 2013 (1)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (3)
- October 2012 (2)
- August 2012 (2)
- July 2012 (3)