Blog Archive

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.

An example:

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.

Make a comment

GRC Certification - is it worth the paper its written on?

Monday, 16 July 2012

Posted by Simon Persin

The SAP GRC Access Controls certification (C_GRCAC_10) was released early in 2012. In this blog, we’ll look at the quality of the certifications and its relevance and usefulness for both clients and consultants.

SAP has a difficult job in setting content for the training courses and indeed the examinations. The most common complaint is that the content is generic and very theoretical. The exercises can often feel worthwhile given the classroom conditions but not particularly relevant for real world examples or use cases. Every customer uses SAP applications in their own particular way and therefore, it is impossible to provide specific examples to cater for each and every scenario.

GRC is no different in that regard especially when you consider the possibilies available for a workflow based user provisioning process. So how can you set an examination based upon all of the particular requirements of each and every different SAP customer?

How much is certifiable?

To my mind, the only way that SAP can really do this is to focus on the technology; how to use and configure it. Whilst we all know that technology is only a small part of the wider GRC projects, it is the only area of the project which can be adequately assessed.

Actually defining the business use cases and process designs cannot be simply taught or certified through traditional multiple choice exam questions as there is never a single correct answer. It is the experience of having worked in and around the technology for a number of projects which differentiates the quality of individual consultants, consultancies and ultimately the success of the customer project. SAP has recognised the limitation in their current certification tracks and has worked to fill that by providing the Professional and Master qualification levels. Rather than certifying these through traditional examinations, these are based more on implementation experiences based focussing on applied knowledge rather than retained technical information.

Does the Exam test the knowledge?

Given that the SAP GRC Access Controls associate certification has to be technology focussed how well does it test this area? Having implemented the technology numerous times and taught the pre-requisite course (GRC300), my belief is that the examination does provide a stern test to all delegates.

The questions really get into details and are worded in such a way that you do need to have an understanding of the actual technology and SAP terminology rather than simply the themes involved. That is not to say that there aren’t a few “freebies” thrown in there to cover the more straight-forward application areas and the wider areas of business integration.

Exam Technique

There are also elements where exam techniques can help. Understanding the way that SAP approach a subject rather than the way in which you might tackle it in a specific project is paramount to lead you to the correct answer. With multiple choice exams, there will always be the possibility to be able to work towards the correct answer by a process of applying logic, common-sense or a process of elimination and that will still work in some cases. However, I do believe that SAP has improved the quality of the examinations to accurately test against the technology.

Many of my colleagues and contacts have taken the certification and many of them have returned similar thoughts on the content; it is a tricky exam where you need to be on top of the theory and the details of the system configuration to be able to navigate it successfully. It is easy to get confused by the wording of the questions and therefore, it does seem to achieve the objectives of testing the SAP technology underpinning the GRC Systems.

The worth to consultants and customers

There is often a debate in the market as to whether customers really appreciate and respect the certification. Many great application consultants have never taken the SAP endorsed application certification and similarly many consultants who have that cetification really do not have much more to offer a customer other than that. So is it simply a rubber stamp or can it be trusted?

From a consultancy perspective, it is a fairly clear cut decision. Certification is an important differentiator, demonstrating a baseline level of technical competence and is a good way to provide that assurance that all of the consultants offered into client work have met the minimum standards set bySAP.

Individual consultants may also wish to take the certification exam for their own personal development or to be able to market themselves more clearly to clients. In this way, it is a good way for their parent organisation to demonstrate support for their development by supporting their desire to undertake this. Certainly, with this certification, the successful consultant should take some pride from passing the exam as it is certainly not a given that passing is guaranteed.

Customers do seem to like the tangible endorsement afforded by SAP certification. It can play a part in the decision process when selecting a supplier or indeed a contractor. I’m not convinced that it should play a major role and care should be taken to ensure that appropriate attention is placed upon delivery experience and references. However, it is still a very quick and easy comparison to make.


It is easy to become cynical about the SAP certification process, especially once you have attained the qualification but it does seem to be viewed positively within the market. My view is definitely that it is a useful qualification but it should not be relied upon in isolation to guarantee that the holder is right for all GRC projects. As mentioned earlier in this blog, its scope is limited to the “easy” bits of a GRC project and does not test the real agility of the consultant in implementing the customer solution. However, it still presented me with a sufficient challenge that I am proud to call myself a SAP Certified GRC Consultant and to congratulate my peers once they pass the exam.

Make a comment

Evolving challenges require evolving skills

Thursday, 12 July 2012

Posted by Alex Ayers

One of our clients recently remarked that our team offer something that their other partners in the security & GRC space don't - We keep them integrated with other relevant projects in their organisation and they are confident that they get the benefit of our experiences from other engagements and clients.

That is great to hear and reinforces my view that we take KT seriously but also got me thinking about how, like projects often are, security knowledge for SAP is still kept in silos.

SAP and the security ecosystem have done great work in getting the message out that as the technology platform improves integration and collaboration, there is the need for strong controls over the technology that supports this. Those controls are not the domain of just one team but from a security perspective we need to understand how they fit together to provide a secure environment.

There have been discussions on some of the SAP forums recently debating the role of the SAP security analyst (and the relevance of certification based on that role).

There are two prevalent views:

  1. Those who say that they retain a business focus and therefore roles are their domain and that's where they are staying. If SoD and SA checks are OK then things are secure (which will be the topic of another blog soon).
  2. Those who are developing their skills to meet the challenges of evolving technology and business practices. They view security holistically and while not necessarily being expert in comms, OS, DB, network security etc, they have an understanding of the integration points and dependencies between the components.

The business & technical components of security are not mutually exclusive and it is one of the things that makes this field such an interesting area to work. I do, however, believe that a credible security practitioner must be aiming to wear both hats if they want to be, and stay, effective.

Make a comment
Visit Turnkey Insights