Consider the fundamentals of the data model of SAP BusinessObjects Risk Management 3.0. A risk is always defined in the context of an organizational entity (Figure 1). In addition, you can optionally link a risk to one of the strategic objectives or activities tied to that entity. You can define types of activities via IMG menu path GRC Risk Management > Master Data Setup > Maintain Activity Types. Common activity types include business processes, projects, products, or other planning objects you’d like to include in your risk management. Activities are always defined in the context of a specific organizational entity, whereas you can assign the same strategic objective to multiple organizations. However, the use of activities and strategic objectives in SAP BusinessObjects Risk Management 3.0 is optional and depends on the requirements and maturity of your enterprise regarding risk management.

Figure 1

The core of the data model from a risk-centric perspective

One example could be the risk of being non-FDA compliant in one of your manufacturing units (e.g., organization) in the production process of a new product (i.e., activity), which also threatens your strategic objective to introduce new products. This setup allows for risk monitoring by organizations, by processes (or other activities), and by objectives.

Risks, organizations, objectives, and activities are organized in hierarchies (Figure 2). The following hierarchies are created during the risk planning phase:

• Objective hierarchy: Consists of only two levels — strategies on the top level and objectives on the second level
• Organization structure: Multiple levels of organizational entities
• Hierarchy of activity categories: For each activity type (e.g., business process or project), you can create a multi-level hierarchy of activity categories. When creating a new activity at a later stage, you have to assign it to an activity category.
• Risk classification: Create a multi-level hierarchy of risk categories according to your risk taxonomy. When creating a new risk, you have to assign it to a risk category.

Figure 2

Master data hierarchies defining the risk context

Log on to SAP BusinessObjects Risk Management 3.0 via the SAP NetWeaver Portal and go to GRC Risk Management > Risk Structure to execute all risk planning-related activities (Figure 3). 

Figure 3

Master data setup during risk planning is executed in the Risk Structure portal page

Objectives Hierarchy

Creating the two-level objectives hierarchy in the system is straightforward. Navigate to GRC Risk Management > Risk Structure > Objectives Hierarchy and start with your strategies on the top level. Continue creating the relevant objectives for each strategy on the second level (Figure 4). You can assign a validity period to both strategies and objectives. You need to assign an objective category to each objective. Follow IMG menu path GRC Risk Management > Master Data Setup > Maintain Objective Categories. In addition, you can add attachments and links to your objectives. However, you can only view organizational entities tied to a given objective, and you can only assign them during the maintenance of organizational entities.

Figure 4

Create an objective below the strategy Improve Sustainability

Organization Structure

You can create organizational entities by following menu path GRC Risk Management > Risk Structure > Organizations (Figure 5). Before you start to create organizations in the application, you need to create a root organizational hierarchy by following menu path GRC Risk Management > Master Data Setup > Maintain Root Organizational Hierarchy. Each organizational entity comes with the following tabs for the holders of the risk manager or organization owner roles to maintain:

• General
• Objective
• Unit of Measure
• Risk Appetite
• Risk Thresholds
• Assignments
• Roles
• Attachments & Links

Figure 5

Creating a new organizational entity includes a number of tabs to maintain

Let’s have a closer look into each of these tabs. The General tab contains header data such as the name, description, currency, and validity dates of the organizational entity. In the Objective tab, you select the strategic objectives from the objective hierarchy that are relevant for the given entity so you can later relate risks to them.

In the Unit of Measure tab, select a unit of measure from a predefined list for each impact category that is relevant and not measured in the selected currency. The list is maintained in the IMG customizing by following menu path GRC Risk Management > Master Data Setup > Maintain Units of Measure. In addition, you assign a conversion factor to convert the selected unit of measure into a value in the chosen currency, a description, and a validity period (Figure 6). For example, if you want to measure the impact category Reputation in hours and set a conversion factor of 125 EUR, then a risk event having a 1,000-hour impact in reputation would be converted into a potential loss of 1000 x 125 EUR = 125.000 EUR.

Figure 6

Defining units of measure for impact categories and conversion factors

In the Risk Appetite tab, document a qualitative and, if desired, a quantitative risk appetite for the selected organization (Figure 7). Select the Qualitative Appetite from the predefined drop-down list (e.g., High, Medium, and Low). (You can maintain these values by following the IMG menu path GRC Risk Management > Master Data Setup > Maintain Risk Appetite.) Select the quantitative amount of the risk appetite based on the maximum monetary value for a potential total loss in the chosen currency. The risk appetite defines whether a given organization is risk-taking or risk-averse. It marks the balance between risk and reward and helps you understand the relative significance of the risks faced by the organization and prioritize risk monitoring and risk response planning. For example, finance departments are risk averse whereas business units in emerging markets may be willing to accept more risk as there might be a lot to win in turn.

Figure 7

Documenting the risk appetite of an organization

In the Risk Thresholds tab, define a range of total losses in the chosen currency for each impact level: Insignificant, Minor, Moderate, Major, and Catastrophic (Figure 8). This defines, for instance, whether a total loss of 1,000,000 Euros is considered a moderate, major, or catastrophic impact for the given organization. You define impact levels via IMG menu path GRC Risk Management > Master Data Setup > Maintain Impact Levels.

Figure 8

Define the risk thresholds for the selected organization

In the Assignments tab, you can assign organizations to organizational views. This is useful if you are using SAP BusinessObjects Process Control 3.0 in the same system client and share the same organizational repository across both applications. You can define an organizational view for SAP BusinessObjects Risk Management 3.0 and build a different organizational hierarchy, reusing organizational entities defined in the shared repository.

In the Roles tab, assign users to the following pre-delivered application roles:

• CEO/CFO
• Organization owner
• Internal auditor
• Unit risk manager
• System administrator

These application roles are pre-delivered as part of the SAP BusinessObjects Risk Management 3.0 security concept, which I’ll explain in more detail later.  

In the Attachments & Links tab, you can attach documents and links to provide additional documentation. You can search this documentation if you have implemented the document search functionality requiring SAP NetWeaver TREX.

Risk Classification and Central Risk Templates  

A risk classification schema consists of a multi-level hierarchy of risk categories matching the risk taxonomy you have defined for your enterprise (Figure 2). It facilitates data aggregation and reporting across entire risk categories. You can create risk categories in GRC Risk Management > Risk Structure > Risk Classification (Figure 9). Click the Create button and select Risk Category (Figure 10).

Figure 9

Multi-level hierarchy of risk categories

Figure 10

Create a new risk category

A risk category comes with three tabs: General, KRI Template, and Attachments & Links (Figure 10). In the General tab, enter a name, description, and validity period for the new risk category. The Allow Assignment option determines whether you can later create central risk templates under this category or only create risk categories or subcategories.

In the KRI Template tab, you can assign one or multiple KRI templates to the risk category. You create KRI templates via IMG menu path GRC Risk Management > Risk Monitoring > Key Risk Indicators > Key Risk Indicator Template (Figure 11). They represent a business definition of a KRI without technical details such as system, query, or Web service. In later stages of the implementation of your risk monitoring concept, you technically implement KRIs in a multi-level approach consisting of KRI implementations, KRI instances, and KRI localizations, and create business rules based on KRI information to raise alerts or trigger risk assessments.

Figure 11

KRI template

Apart from a free text description and a value type, which can be Number, Currency, or Quantity, KRI templates are described by the attributes System, Business Process, and Component. These are set up in the IMG customizing under GRC Risk Management > Key Risk Indicators.

Central risk templates act as templates to standardize risk data and streamline risk documentation. You create them within risk categories by setting the Allow Assignment option to Yes. These are later referred to when you create risks for different areas of the organization. The templates include the description of the risk event, comments, and validity dates, as well as drivers and impacts (Figure 12). You need to assign drivers and impacts to the driver and impact categories, respectively, which are defined in the IMG customizing as mentioned earlier.

Figure 12

Create a central risk template

Hierarchy of Activity Categories

In GRC Risk Management > Risk Structure > Activity Hierarchy, create a multi-level hierarchy of activity categories for each activity type previously defined in the IMG customizing (Figure 13). If you run SAP BusinessObjects Process Control 3.0 in the same system client, you can reuse the central process hierarchy defined in there as an activity hierarchy for activity type business processes in SAP BusinessObjects Risk Management 3.0.

Figure 13

Activity hierarchies

An activity category contains the tabs General, Risk Classification, Opportunity Classification, and Attachment and Links (Figure 14). I’ll focus on the Risk Classification tab only because opportunity management isn’t covered in this article and all other tabs work the same way as the tabs in risk classification. The Risk Classification tab allows you to restrict risk categories from the activity category. This is necessary because certain risk categories (e.g., operational risks) should not be permitted under certain categories (e.g., a financial activity category). By default, all risk categories are available and you must choose which ones to exclude.

Figure 14

Create a new activity category

Overview of the Security Concept

As ERM is a collaborative process, it is crucial to identify all relevant stakeholders and implement their responsibilities using the security concept of the application. The security concept is flexible and comes with a certain level of complexity that can’t be covered here in depth. On a high level, it distinguishes three different types of roles:

• Portal roles
• ABAP authorization roles
• Application roles

As all business users access the application through SAP NetWeaver Portal 7.01, they need a user setup that has the GRC Risk Management role assigned. This portal role is included in the portal content package, which has to be deployed on SAP NetWeaver Portal during the installation of the software components.

The software is shipped with a number of ABAP authorization roles. Of these, you need to copy the two roles SAP_GRC_FN_BASE and SAP_GRC_FN_BUSINESS_USER and assign the copied roles to all your business users. They contain authorizations required by every user working with the application.

Application roles represent a new concept in SAP BusinessObjects Risk Management 3.0 and are also shipped with the software. Application roles are maintained with the standard profile generator transaction, but are only assigned within the application and not with the standard user maintenance transaction SU01. A role assignment establishes a triangular relation between a role, a user, and an entity, such as an organization, activity, risk, opportunity, or the corporate level for global roles (Table 1). It ensures that a user can execute certain functions only for the selected entities for which he or she is responsible.  

Table 1

Pre-delivered application roles and their entity levels

For example, follow IMG menu path GRC Risk Management > User Access > Mass Role Assignments for Risks, Opportunities and Activities and set appropriate filters to select a risk to which you want to assign the application role Risk Owner. In the next screen of the guided procedure, assign users to the Risk Owner application role for the selected risks (Figure 15). Unless you activate the option Second-Level Authorizations in IMG customizing in GRC Risk Management > General Settings > Maintain Authorization Customizing, you can select any user holding the ABAP authorization role SAP_GRC_FN_BUSINESS_USER. The selected user inherits the authorizations associated with the corresponding application role Risk Owner, as configured in transaction PFCG. If you activate second-level authorizations, you can only assign users who have previously been assigned to the application role Risk Owner in the user maintenance transaction SU01 on the Basis level. This makes them eligible as the holder of the application role Risk Owner, but as long as no entity is assigned, no access is granted within the application. This applies accordingly to all other application roles listed in Table 1.

Figure 15

Assign the Risk Owner application role for a specific risk

SAP BusinessObjects Risk Management 3.0 includes a number of workflow-based collaboration scenarios triggered in the planner tool accessible at GRC Risk Management > Risk Monitoring and identified by business events. The available business events are listed in Table 2 and trigger workflow tasks such as answering a survey, performing a risk assessment, or validation. The receivers of these workflow tasks are the holders of application roles for the entities selected in the planner tool. Follow IMG menu path GRC Process Control > Authorizations > Maintain Roles to Receive Workflow Tasks to relate business events to application roles. These define, for example, if the workflow tasks to conduct a risk assessment for all risks documented for Organization A are sent to the holder of the application role Unit Risk Manager for Organization A, or to the holders of the application role Risk Owner for all risks documented for Organization A. If you don’t relate business events to application roles in the IMG customizing, the default behavior described in SAP Note 1362997 is followed by the application.

Table 2

Business events triggering workflows

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

You may contact the author at frank.rambo@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.