The question is how should RACI be documented in ARIS EPC models? I'm looking for a best practice from ARIS users out there. Here are three alternatives my team has proposed. Would appreciate insights/feedback/best approach.
RACI is represented only for the Responsible role. Enter this role in a Process Role object and display in the EPC. Other RACI roles would be buried in the Description but no others would display in the EPC. This implies a procedure step for the actual consultation or communication. Print out would include only the Responsible role.
Full RACI is presented in the EPC using connector properties to tie the Process Role object to the Process. RACI methods require one Accountable and one or more Responsible role for each process. Consulted and Informed RACI roles would be documented when applicable in a Process Role object with the associated connector property. This implies a procedure step for the actual consultation or communication. Print out would either include all the assigned RACI roles or none of them. A separate RACI table could be generated by the tool.
Similar to #1 above with the addition of adding other RACI roles when applicable and necessary for clarity in a Process Role object. Otherwise, bury other RACI roles in the Description. This implies a procedure step for the actual consultation or communication. Print out would include all of the RACI roles shown as selected by the Process Modeling team to display.
Yes, I did search for related articles but what I'm after is really a recommendation on whether RACI should be used or not. Currently, our filter only allows for one connection "carries out" which is equivalent to "R". The dilemma we're facing is, with the full RACI option we tend to do more "RACI modeling" rather than process modeling. In other words, processes are embedded into a RACI role instead of being reflected in the process model iteself. We are trying to come to a consensus on RACI approach and have proposed the 3 options above in my first thread. Basically, it boils down to whether we should keep our current filter which only has one relationship connection type (R) or allow for the rest (A, C, I). Hope I'm making some sense.
From my experience of using the RACI in Aris, it is clearly putting more controls on the execution of your processes. It helps you clarify the responsabilities and using it in Aris can generate a clear role definition for the organization.
I believe it is always risky to only put the information in the description because people might not read the entire text or might misundertand it. What you are representing on a model is supposed to be the most important and the most relevant for the people who execute them, so even if this is not the meaning you want to put in it, text always comes in second.
Now it also depends on what objective you are attempting to reach and what are the processes concerned, in other words your strategy. You might want to consider adding RACI on processes you want to have most control on.
If I understand well your other concern, is that instead of focusing on the process descriptions, using the RACI you tend to change the process design only because of the RACI. I understand this is painfull, and it can make the process more complex in the end, but also it helps asking the right questions for you organization.
One of the pain points I have encountered using the RACI with customers, is for multiple Responsible actors on a process or a step. Once you have several actors responsible for a task, it is confusing for process executors. The only way I found to manage this is to use fake connectors XOR between actors with the "Responsible" connection and explain the different cases in the description of the task saying who should realize it in which situation. The other way, which is a bit frustrating, is to create a seperate process to describe this case with exactly the same action but different actors.
In the end your three solutions are valid, though I would suggest to update your filter to use the RACI connections between tasks and roles, and then manage the information details depending on the criticity of you process.
I hope this will help you to make the right decision.
Thank you for your response and recommendation Florian! The other question I have is: will there be any issues running the simulation when using full RACI or the fake XOR connectors?
Would it also be possible for you to attach a sample process diagram to this post?
It is not a good idea to add a semantically relevant object in a graphical way, i.e. without properly connecting it with other objects. I've already seen cases where this led to confusion because an evaluation of the model (e.g. with a report) did not deliver the results one would have expected from just looking at the model.
Describing the behavior with a free-form text would be less misleading. (In case you need the information in the diagram in addition to the description in an attribute.)
"The only way I found to manage this is to use fake connectors XOR between actors with the "Responsible" connection and explain the different cases in the description of the task saying who should realize it in which situation."
With "free-form text" I mean the text boxes you can insert by clicking on the "Insert free-form text" button in the toolbar. And that would be the thing I'd use as the hint in the diagram. Not an XOR rule which is just placed on top of connections and can therefore give rise to misinterpretation.
I'm trying to understand why you need RACI. I do not mean that RACI is not useful but I found quite odd that you wonder whether or not to use RACI. The business needs should drive any filter extension and presenting them could help us recommands a particular way of describing them. I would say that extending the filter capability should always be argumented by specific business needs.
With that being said, I don't found right to have several Responsible role on a particular activity (in that case who is actually doing the job ?) and by default I would also use the standard modeling capability with the right connections.
Finally, adding so much roles can really make the process look complex. The alternative would be to keep the Responsible role on the model and describe other roles on a matrix.
(I agree with Ralf, please do not create bogus models :-) )
I've read with interest the above comments, and it seems that creating a responsibility matrix is not native to Aris, or have I misunderstood? In other words, one needs to use some sort of a workaround. Correct?
You see, we need to be able to associate either RACI or RASCI responsibility-matrix notation to each task of the processes that are being mapped for a global reorganisation/implementation. The results will feed into a number of key activities, the principal of which are:
- organisational design
- headcount/effort definition
- competency/skills matrix
- impact assessment
- authorisation profiles
ie. our processes won't be signed-off until it is clear people can use them.
Has a means been defined to easily apply a complete responsibility-matrix to aris express and/or full-aris? For this to work, it would be necessary to export the results into Access, Excell or - at worst - csv, for analysis.
Any help meeting this challenge would be appreciated. Thanks!
