change authorisation Change Request Authorisation

[Everton1878]

Hi, can anyone assist us with Change Management and the authorisation of the changes?

There are a number of managers who we would like to approve a change before it can continue - In this case 3 managers should approve the change before it is ‘approved’, and so the 3 managers each have a weighting of 35%.

Our problem then arises if one of these managers is off, we’d like for them to have a delegate who can sign for them. But if we then add the delegates in (with 35% weighting again), we are then left in a situation whereby 3 of the ‘delegates’ could sign off the change without a manager at all or more than one person from the same team 

An issue with that would be that all the 6 users in this case would be receiving change request emails, when actually 3 of the users only need to be aware if there respective manager is off.

We've looked at possibly creating a change management group, but this would have the same issue I think?

There doesn't seem to be an obvious way to choose who needs to sign off the change when logging the change request as there was in SupportWorks

 

Another way to do it might be to have 4 managers each with a weighting of at least 30% and then their nominated deputies with a weighting of on 20% ish, where multiple managers are off we would need more people with the 20% weighting to approve it to get above the 100%

 

Is it possible to have the groups listed in the authorisation section with percentages assigned to each group and then anyone in those groups could approve the change in a combination with people from the other groups?

 

We might want to have different numbers of managers to approve a change depending on the type of change or the perceived risk of the change

We don't want too many people getting emails about approval as they may get ignored but at the same time we want it to be flexible enough so that it still works when the main IT managers are off for whatever reason

[Steven Boardman]

Hi @Everton1878

Just to come back on a few of the questions in the post.

1. We don't currently have the concept of delegates for approvers i'm afraid.

2. Authorisers need to be either a named individual / or a variable but groups are not supported. 

3. You can use the Get Request Information (Request Details / Questions) node ahead of a branch node, to evaluate say the Priority, custom questions etc to then branch to different nodes which contain different sets of approvers based on it being (High, Medium, Low etc). 

Considerations. 

1. As shown in your screenshot, we have recently introduced the option of an Owner for authorisations, this provides a little flexibility.

* The Owner can complete authorisations which are assigned to other users

* The Owner can reassign the authorisation to another user (when it has been spawned by the business process) 

* The Owner could be set as a variable (owner for tasks) to allow the owner of the request to alter the approvers if needed once set

2. As with any other sort of task, you can set Expiry as a valid outcome for the authorisation, so if the original approvers do not make there decision within say 24 hours (because they are away) then the authorisation task could follow an Expiry branch and this could lead to a second authorisation node which has a different set of approvers - This does not address knowing who is away but it may be something to explore

3. We have a change in our to do list which will allow the required  approvers to be manually populated from the request before getting to the approval node, this has not been started just yet but it is scoped and i can update here once this is in motion.

I know the above may not provide an immediate solution to your challenge, but i wanted to provide some information on the current capabilities, some options to consider and what we also have planned

Steve

[Everton1878]

Thanks as always @Steven Boardman, that will give us some things to think about

No. 3 would be great, we'll watch out for that

[Guest]

Hi @Everton1878,

Based on the chat we had earlier on this afternoon, I had a think about the scenario you explained further to me regards to the Change Authorisations. Some of the considerations included:

• Ensuring that different areas each have a say in the approval of tasks i.e. 1 person from IT, 1 manager etc
• The number of approvers (in terms of the above areas) depending on the impact/urgency of the Change
• The difficulties there are in accounting for potential absence by including multiple people in a single approval node - because in theory uses could "cheat the system" where a number of approvers from a single area could tally their percentages up to 100%. 

 

The idea I had (which Steve also alluded too in point 2 above) was to have an approval node per area - i.e. all of your IT approvers in one node, all of your Managers in another. This way you could ensure that every area gets a say in the approval as they all need to be involved, but you can manage this a little more granular e.g. perhaps give all of your managers 100% weighting and only one of them needs to approve, but IT staff all have 50% so two of them need to approve.

I initially suggested this could be done with parallel processing, but as you rightly pointed out, this doesn't really work if someone rejects a change as the other groups will still have theirs outstanding. So I would suggest a consecutive approach - which actually could work quite well as you could use this to ensure that the most important people see the request first and either rule it out or approve it to move it onward to the next approval area. 

I've created an example of this in the screenshot below - if you follow this through, you'll also see I have used an initial decision looking at the Change Priority to make a decision about how many areas of approval are needed - so a High priority Change needs all 3 (IT, Infrastructure, Management) whereas a Low priority only needs the IT approval. If its rejected at ANY stage it will mark the rejected checkpoint and skip to the final stage instead of moving to the implementation stage (as an example). 

 

This could be a viable alternative to consider whilst we don't currently have the "Ad Hoc Approver" style functionality?

Let me know if you have any further questions around this, I hope it helps!

Kind Regards

Bob

[Steven Boardman]

@Everton1878 

just an update to this post. 

We are introducing the options to allow approvers by both Role and Group.

We are adding two new business process options: Hornbill Collaboration > Application > Utility > Get Authorisers By Role / Get Authorisers By Group

From here you will have the option to then choose an Assignment Role or Group 

• This will include all Active users with that role or in that group as an approver (will receive an approval task), Active being non archived or suspended user accounts. 
• You can set authorisation type as follows:
  • Unanimous - Needs approval by all users
  • Majority - Needs approval by the majority of the users (i.e 4 out of 7)
  • Individual - Needs approval only by one of the users  

The New node needs to be followed by the existing Auto Assign Authorisation node in order to actually load and create the approval tasks.

This approach will mean you can manage your users in the groups and roles and not need to remember to edit individual business processes should a user leave / join etc. 

This new option will be available in a admin console update shortly so watch out for the release notes 

Steve