Palisade Knowledge Base

HomeTechniques and Tips@RISK DistributionsEvent or Operational Risks

3.13. Event or Operational Risks

Applies to:
@RISK 5.x–7.x

A risk has a certain chance of occurring, let's say 40%. If it does occur, there's a probability distribution for its severity; let's say a Triang. I've been multiplying RiskBinomial(1, 0.4) by my RiskTriang. Should I do anything in my risk register beyond just multiplying?

Caution: The technique in this article will is intended only for "light-switch" risks that either happen once or don't happen. For risks that could happen multiple times in one iteration, please see Combining Frequency and Severity and use RiskCompound.

Probably you should. You probably want to wrap the multiplication inside a RiskMakeInput function. If probability is in cell C11 and impact in C12, your function for actual impact in any given iteration would look like this:

=RiskMakeInput(C11*C12)

If you wish, you can give it a name:

=RiskMakeInput(C11*C12, RiskName("my name for this risk") )

Why introduce an extra distribution instead of just multiplying? Don't they get the same answers?

Nearly the same, though not identical. Here's why. Suppose your simulation has 10,000 iterations, and your risk has a 40% probability of occurring. There are 10,000 values of your RiskTriang for the 10,000 iterations. Only 4,000 of them (40% of the 10,000) get used. but statistics and graphs will all report based on all 10,000 values. RiskMakeInput treats the product as a distribution, so that now you have 6,000 zero values and 4,000 non-zero values, and the statistics reflect that.

But using RiskMakeInput can make the greatest improvement in your tornado graphs. Without RiskMakeInput, you might get a bar in your tornado for the RiskBinomial, or for the RiskTriang, or both, or neither. With RiskMakeInput, if the risk is significant you get one bar in the tornado, and if the risk isn't significant there's no bar for it.

The attached example shows a risk register, both with plain multiplication and with improvement by way of RiskMakeInput. Run a simulation. Though the two output graphs don't look very different, the two tornado graphs show very different sets of bars. (In this particular example, most of the tornado bars in Method A come from the RiskBinomial functions, which probably isn't helpful.) Also, with plain multiplication in method A, there's no way to get an accurate graph of the impacts in all 10,000 iterations; with RiskMakeInput, just click on one and click Browse Results.

Can I correlate RiskMakeInput?

Unfortunately, no. This is a limitation of RiskMakeInput, and of the plain multiplication method also. There is a workaround in Correlating RiskMakeInput or RiskCompound, Approximately.

See also: All Articles about RiskMakeInput

Additional keywords: Event risk, operational risk, Risk register

Last edited: 2018-10-24

Downloads

This page was: Helpful | Not Helpful