Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.013 Identify risks to business effectiveness (business loss-risk mapping)

SM-2749 - Populate Confluence page for activity definition: ARCH.013 Identify risks to business effectiveness (feared event-undesired state mapping) Finished

GoalProvide a consistent starting point for business risk analysis
Requirements met by this process step

RiL 0120 series (DB quality management system)

Inputs

Selected parts of the RiL 0120 series relevant to this activity

AMOD-106 Enterprise goals including measures of effectiveness

OutputsAMOD-130 Business loss and risk state model
Methodology

This process step consist in preparing the risk model basis which will be enriched iteratively with steps ARCH.020 Identify & classify operational deviationsARCH.014 Evaluate risks to business effectiveness and ARCH.028 Define operational safety measures

The main intended pattern of the state model is the representation of a <non business risk state> that makes transition to a <business risk state> which can then lead to an <business loss state>. as shown by the upper part of the below diagram

Complementary patterns of the model (shown above) are:

  • <business loss state> persists in <business loss state> (it is considered once the business loss state is reached, that it cannot be left thus this transition exists only for calculation reason: probability = 1)
  • <business risk state> recovers to <non business risk state> (for situations where there is a successful safety reaction, or the hazard clears up by itself)
  • <non business risk state> persists in <non business risk state> (a transition that allows the modelling of the probability of successful mitigations - and hence completes the state diagram as a hidden Markov model where the sum of all outgoing transitions from a state has probability 1)
  • <business risk state> persists in <business risk state> (where the business risk state is still active but an accident has not occurred). Since it is considered that business risk state cannot be kept thus this transition exists only for calculation reason (probability = 0)

The viewpoint definition for AMOD-130 indicates the detail of how this is captured in the analysis model.

A set of buissness risks assigned to the respective business loss which are identified using the relevant source material and regulations (with reference to existing material in the DB quality management system), define a standard set of business losses are used for defining the business loss states and related business risk state(s) in the model as starting point. 

This initial set wil be consolidated and potentially updated/supplemented when carrying out the operational deviation analysis of ARCH.020

A Risk Model is to be created for each business risk state identified in relation to an business loss state.

Different risk models may be needed for one business risk state if for the same business risk state, there exist:

  • Different business loss states with different severities;
  • Different conditions (including different involved functions) for state transitions or same conditions with drastically different probabilities;

Remarks: 

  • When several succesive business loss are related to a business risk, only the business loss occuring first is considered, if the subsequent business loss is of importance, this shall be adressed in a separate risk model.
  • Before starting creating a new risk model, the coverage and the existence of potential variant models shall be investigated. By variant models the difference in terms of conditions/events involved to lead to the accident or related probability (not the severity extent) is meant.
    As far as possible only one risk model per hazard shall be defined, if the conditions cannot be combined together or the probability cannot be covered by a worst case assumption then a variant risk model is needed. In this case the different variant and the respective severity when different can be reflected on each model in instantiating the business loss description.

The set of the risk state models defined as starting basis will be then completed by potentially additional business risk states or new conditions for transitions between states found out after performing the 1st part of ARCH.020.

The worst case consequence of a particular business loss related to a business risk in question is considered in the given severity level.

When creating a risk model, the following steps have to be carried out:

  • Define the business loss state;
  • Assess the severity of loss
  • Define a set of business risk states;
  • Define the non business risk state (which is the exact opposite of the business risk state);
  • For each created state: Select predefined risk state type property - business loss state, business risk state or non business risk state.
  • Derive, from the severity of a loss, the maximum tolerable occurrence rate of a not-allowed state

The business risk state must be expressed in terms of physical conditions that could lead to an accident, excluding any notion of a system or safety function failure. They can include reference to abstract concepts that are not safety-related, for example an operational plan.

Then the following is to be done just formally without any content consideration

  • For each business loss state, define one decision nodes (pseudo states) to represent the "business loss state entry gate"
  • For each business risk state, define one decision nodes (pseudo states) to represent the "business risk state entry gate"
  • For each non business risk state, define two decision nodes (pseudo states):
    1. One to represent the "business risk state recovery gate"
    2. One to represent the "non business risk state persistence gate"
  • Define the following unnamed transitions:
    1. From business risk state to business risk state (reflexive, probability set to 0, see reason above)
    2. From "business risk state entry gate" state to business risk state
    3. From "business risk state recovery gate" to non business risk state
    4. From "non business risk state persistence gate" to non business risk state
    5. From "business loss state entry gate" to business loss state
    6. From business loss state to business loss state (reflexive, probability set to 1, see reason above)

Note: the intention here is not to create a working state model of the entire business, rather to reduce down to an abstract set the critical business losses and the mechanisms by which they happen, so that sufficient mitigations can be built into the operational concept. The focus is on creating a good experience for our customers by avoiding delays, making the railway user-friendly, and anticipating deviations that we can mitigate to maintain service quality.

Tools and non-human resourcesTeam for Capella
CardinalityOne-off with possibility of revisions
Completion criteria

The output view is complete i.e. sufficient losses and not-allowed states have been covered

The output view includes elements that are required by DB regulations, where applicable

The output view conforms to its modelling rules

Design reviewARCH.R.2 Operational review - consolidated
Step done by (Responsible)RAMS architect
Provides input to/assists (Contributes)RAMS engineer
Uses outputs (Informed)None directly