DC
I'm following the standard practices of modelling Risks and Controls in FADs and BCDs and generating a Risk and Controls Matrix or RACM, for the Business to review and sign off. Our Risks and Controls are modelled at one level – Level 4. We use Org Charts for Teams, True Roles (Maintainer, Verifier, Approver) and reference Control Owners in Org Charts and BCDs. From our Risk and Controls work to date we would appear to have two types of Risks & Controls.
1. Specific to the activity undertaken at a Process Step and the responsibility of the Process Operator, e.g. the process step Create Report will have a Risk that the data is wrong, and there is a subsequent step to Verify Report with a Control Check Report Accuracy. Undertaken by the Maintainer and Verifier respectively.
2. Overarching or generic to Teams and apply to more than one Process Step where the responsibility lies with a Process Manager or Leader, e.g. Key Man Dependency, whereby key Process Steps should have more than one individual suitably capable of undertaking the process activity. This Control isn't the responsibility of the Operator but lies with the Manager/Leader and will feature many times across a Team’s Processes. Other examples are Segregation of Duties, Processes and Procedures, Service Level Agreements.
To date, we have shoe horned the Overarching Risks and Controls into “best fit” Process Steps, but this approach isn’t delivering the quality of data we now want, meaning we have to amend the ARIS driven RACM as it doesnt reflect the truth as we see similar Controls featuring many times and associated with the wrong Role (Operator not Manager).
My question is, how to practically model these overarching Risks and Controls so
a) They feature once on my RACM, and
b) They have the correct relationship with the Process Manager/Leader.
Some pragmatic, practical and non-theoretical responses would be much appreciated!
Thank you
How about separating the different types of controls in different groups and using access rights to take only those controls in the generation that are needed? Alternatively you could also use an attribute to mark the different kind of controls and use this to select the fright ones?How about separating the different types of controls in different groups and using access rights to take only those controls in the generation that are needed? Alternatively you could also use an attribute to mark the different kind of controls and use this to select the fright ones?
Thanks for the reply Georg,
One of the solutions I have been toying with is to create a "stub" model of just an Event-Function-Event and title the Model "Administer Operation Capability" and the Function "Deliver Operational Capability Leadership". Other stub models would be Change Management and IT Delivery Support, for instance.
Within the FAD of the Function I can then place the relevant overarching Risks and Controls and create a relationship with the Role "XYZ Team Leader".
When the Risks and Controls are included in the scope of the RACM run they will then populate the excel RACM report. My only concern is that it doesn't feel "right" to have stub models substituting for what are managerial processes that should probably happen on a frequent basis! But to start modeling these as well does feel like overkill?
Welcome any other alternatives or suggestions! Thanks, Darren
Overarching Risks and Controls - maybe they shouldn't be in the EPCs/FADs. Try using the KPI Allocation Diagram to model Objectives - Risks and then model the BCD for that risk with controls. So such overarching Controls can be linked to Process Objectives, instead of the operational process. Another approach is to put the Risk in a VACD (so higher level of the process), and then drill down to BCDs. So the Risk and Control is not a process step, but at the high level process itself.
