Best Practice Recommendation for RACI

Hi Julie,

did you search for RACI related articles already?

Cheers

Rune

Hi Rune,

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. 

Julie

Hi Julie,

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.

Florian

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?

Much appreciated,

Julie

Julie,

Please find an illustration of what I mean. Also as connector objects are not linked to the rest of the model, this will not affect Simulation.

I hope it helps.

https://lh4.googleusercontent.com/_QRexhZEMO-0/TdDfX-4Us6I/AAAAAAAABus/pzSDzip5Bv4/s800/Org%20Xor%20e.g..jpg

Florian.

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.)

... And then the best is to have both ;)

showing it graphically and in the text.

"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.

Hi Julie,

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 :-) )

Hope that helps,

Michael

Hi there,

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!