I’ve been meaning to write this post for ages, but a combination of life in general and more exciting things to do keep getting in the way. What’s finally nudged me in to it is working with a customer this week who were already using Talent before sa.global got involved. They had a number of requirements that would have been met out of the box by enabling personnel actions, and yet the partner they’d previously been working with hadn’t switched it on.
First things first then.
What is it?
Personnel actions is a feature which is enabled in the personnel management workspace under human resources shared parameters. It’s a global feature, meaning you only need to enable it once for the entire environment. It will impact all users and all legal entities once switched on.
There are two flavours of personnel actions that you can enable – worker actions, and position actions. Once enabled, you can also select whether users should be able to delete completed actions. For reasons that I hope will shortly become obvious, you want to leave this set to ‘No’.
With personnel actions switched on, significant changes to workers (like hiring, transfers, and terminations) or positions (creating or editing) are done through a new form – the ‘worker/position action’ form. This form captures some additional details relating to the reason for the change, as well as the detail of the change itself. For example – you can capture the name of the person requesting the change, and a date stamped comment relating to the change. You’re also offered a reason code field (filtered according to context, which was my suggestion – #proudface).
Most importantly, you’re asked to select a personnel action type. Personnel action types can (optionally) be linked to workflows, meaning – for example – that new vacant positions can be pushed to a resourcing team for approval before they actually get created. Which user roles have access to different personnel actions is configurable, so you can bypass workflow for all HR users, or just some of them, depending on how you’ve got your security roles set up.
Enabling personnel actions has another dimension too – it throws some extra buttons into the manager’s ‘my team’ tab in employee self service.
Users with the manager role assigned can now submit change requests (in the categories shown) to HR. And because of that neat feature where you can select which users see which action types, you can make sure that all changes submitted by managers get routed to HR for a bit of a sense check before they get committed to the database.
So why would I want this?
Well you wouldn’t necessarily. I certainly don’t enable them by default when setting up a customer’s environment. Doing so adds some additional clicks each time I make a change which, depending on the company I’m deploying with, wouldn’t necessarily add any value. It also adds a little bit of potential confusion. The worker/position action form has a save button on it – which saves the action. It doesn’t commit the change to the database. To do that you have to hit ‘complete’. This can cause problems – users think they’ve made the change, but actually they haven’t hit complete and the action is still at draft state. That’s easily checked by looking at the actions list though (Personnel Management > Links > Worker actions > All worker actions OR Personnel Management > Links > Position actions > All position actions).
But throughout the course of deployment workshops, if we start talking about change tracking, audit trails, managers initiating changes in the system or getting a clear overview of the way your organisation is changing and why, I introduce the feature and discuss the pros and cons. We probably end up enabling the feature in 70% of cases. With a few small changes, this would become a ‘must have’ feature.
Why isn’t it a no brainer?
- If you work in a low governance environment and you just want Talent to hold a list of your workers, then the setup needed and the ongoing additional clicks probably aren’t worth it.
- Sometimes it feels a little bit unfinished. Like a great idea that didn’t quite get followed through all the way. For example – I’ve enabled personnel actions, and I can’t just hit the edit button on the position form without going into the action form and capturing the justification for the change, Great stuff. But I can still go into manage changes and directly edit records without routing through workflow. We have ways of making that better, as a partner who know how to use security config, but it really should be part of the standard feature.
- The action grid views I mentioned above need personalising to be truly useful. The columns shown don’t always seem to be completely logical (why wouldn’t you have reason code in there as standard?) and I’m still waiting on a release that will make me properly trust personalisation.
- Data. Data, data, data. There really needs to be a data entity available so I can get at this change data via BYODB. Must get round to submitting an Idea for that one ASAP.
So that’s it – handy little feature if you want to be able to track changes, have managers submit change requests in ESS, or route internal changes through workflow. Enjoy!
The post Personnel actions – what and why appeared first on Tom's Talent Blog.
]]>
