Building RACI for Organizational Processes in V4

[jangm]

We used to build process classification and RACI for Org processes without drawing process diagrams. From fat client in V3 it could be done like this:

Then in the properties of a process we could define RACI roles:

I want to do the same in V4 from web client, but can't, because in Characteristics section I can't connect Org units. How to do that without having to draw diagrams and assign roles from Participant objects?

Thanks,

jang

[OLeGuellec]

Hi,

A quick update regarding this. There are actually two topics :

1) RACI

We got additional feedbacks about the missing capability to complement the RACI as defined based on participant assignation

-> as a short term solution (in next CPs), we decided to reopen the manual edition of the operation / org-unit link

As noted above, this is not ideal however, and has a potential cost in terms of diagram / model consistency.

2) Processes deployment

Instead of using the RACI to define deployment, the other available options to define the process deployment should be considered :

- using the org-process / org-unit direct link (in available in characteristics>properties)

- using the org-process / site direct link (e.g. for country specific processes)

This is highly dependent on how organization & processes are described (e.g. level of "genericity" in the description) there is not a "one size fits all" answer for this.

[hsoegaard]

Hi,

The issue is, that we are missing a good concept for describing deployment of processes. This is espcially valid for organizations that are global or with several business units. This is the reason we have used this resposibility field. And it is only on a certain level in the process architecture that we describe this deployment. For the rest we rely on the assignment via Participants.

[OLeGuellec]

Hi,

Indeed it is easy to change this setup, as it is only a button setting in the properties (RACI sub section in the operations properties page)

  SubList = Item(~ZqUisAB5iaD1[Org-Unit]),Contains(Subs),In(SubGroup),Control(ListView),Title(No),Param(NoDefaultColumn,ToolBar[-C,-L,-D,-U]),ExcludedOn(IsRaciManagedInBPMN)

But the real question is what would be expected by the end users, especially when carrying out updates on the model (e.g. reassigning an operation to a new participant, removing the link to an org-unit, deleting participants, etc.) ?

What happened here is that we had cases since there were inconsistencies in org-unit / operation / participant triangle synchronization when carrying out updates to the model (e.g. old links were kept and not reset when reassigning an operation to another participants), so we did the fixes and also chose to restrict the edition options since they were allowing for more inconsistencies (see below)

The retained logic is that org-units where assigned through participants, and specific RACI settings set from the operation perspective. This works all the time, but indeed is less powerful (we neglected the case when we want to edit the RACI without doing a diagram so without having participants to assign org-units from).

We could loosen the possibilities here and allow the operation / org-unit edition again, but it comes with a price in terms of consequences when maintaining the model :

- assigning an org unit to the operation is displayed in the participant and this could be mis read ? ; we could emphasize it is a different link (e.g. display in italic) or remove this display by default ?

- reassigning the operation to another participants wipes the specific operation / org unit links (e.g. consulted / informed additional information) ; this is normal but if this is done by mistake the information is lost from the user perspective (except in history log of course, but this is advanced usage already)

- /!\ it would be possible to remove org-unit assigned to the participant from an operation (and assign another one), which makes the drawing inconsistent with the underlying data, since participant assignation shows something else ; this is less normal because this allows creating inconsistencies (which would then require ex post consistency checks)

I am unsure  how these could be intuitive for the end user ... but minus the bugs it was already the case in previous versions, so may be this is an acceptable option ?

[hsoegaard]

Hi,

We have actually kept the old behavior for one of our clients, since they are using the Responsibility section in a slightly different way.

They use it to show in which business units of their organization the process is valid for. So they manually add the business unit (org-unit) when they deploy the processes.

It does require a small customization of the property page in order to get the Connect button back again.

[jangm]

I also want to add that diagrams are visualization of data, objects and relations and should not be the sole means to manage that data and relations. Now one useful way of defining organization's responsibilities is gone.

[jangm]

Thanks for explanation.

Pity, because it was useful in analysis stage where we could define process responsibilities without going into process details. Not all consulting work requires strict rules, sometimes tools as HOPEX are just aids for helping achieve other objectives or are used more freely. When we get responsibilities, then we can go into process details with required stakeholders.

[OLeGuellec]

hi

we did several fixes / evolution on the RACI feature over the latest releases / CPs

- first the feature is now deactivated by default (not everybody uses this)

- then, it appeared the former behavior was too permissive and was leading to issues, so we restricted what was possible in the UI

-> in particular the case you mention (adding org-units on org processes / operations outside of participant) is indeed no longer possible

[jangm]

Hm, no ideas? I have to find a solution for our client, otherwise I will have to do more manual work. I don't want to include Informed and Consulted in Participant object, because it's not directly important for workflow.