In this month’s Introduction, three hierarchies were introduced. We continue the series discussing the first of those: line management. The line management hierarchy is the most common of the approval hierarchies, the most frequently-used, the easiest to understand, the most highly sought-after, and possibly the hardest to develop because it encompasses everyone in the organization.
We’ll work through this hierarchy using the five steps outlined in the Approach to this month’s Introduction segment.
Step 1: Determine the needed granularity
Granularity speaks to ongoing management – the more layers of management that are collected, the more complex the setup will be in role manager, the more complex the workflows will be, and thus maintenance over time will be more involved.
It is extemely important to think carefully about granularity at the beginning. Think in terms of what needs to be done, not what can be done. Anything can be done, but is it worth it?
For example, many large companies have a team lead or supervisor type position. This is a good thing – it gives employees the ability to take on more lead/management roles in a relatively safe and protected way. But do these individuals need to be part of the reports-to hierarchy?
Maybe, maybe not.
If they ever approve anything (access, equipment, vacations, travel, training, etc.) or even write and deliver performance appraisals, then yes, they do need to be part of the hierarchy. If they only recommend approval or contribute to the performance appraisal but it’s a manager or higher that has ownership of these things, then the team lead/supervisor level is not needed as part of the reports-to hierarchy.
Selecting the right level of granularity up-front is essential – not trivial. The decisions should also not be made by the identity management team in a vacuum.
The identity management team has the opportunity here to really add value to the organization. I mentioned before that some HR systems only store management data at the director level and higher. That doesn’t mean that HR wouldn’t love to have management info at lower levels, but if their system doesn’t support it, it makes it much harder for them to acquire and maintain the data. The identity management enterprise can pick up where the HR system leaves off, providing much-needed information to the HR team, and building a lot of good will.
There may be other organizations that have a need for up-to-date reports-to information that should also be a part of this design process.
Step 2: Collect available data
Now for the reality check: ask HR for whatever reports-to data they may have, and get an understanding from them of the condition of the data. Is it kept meticulously current, or is it only as accurate as it was during the last salary increase cycle that happened nine months ago?
Step 3: Obtain missing data
Hopefully, HR keeps meticulous reports-to data and little if anything is missing. If that’s the case, buy the entire department flowers or take them to a nice dinner – they’ve just saved you a ton of work.
If that’s not the case, let the grunt-work begin.
There’s no easy way to obtain this information, which is why many large organizations covet the data yet can’t keep it current.
Certainly, getting the most current data should lie with HR, and they do have to get the information current (to a certain level, which might not be the desired level) at the next pay cycle. So worst case, wait it out. Theoretically, HR will be motivated to help with an off-cycle cleanup of management data in anticipation of getting help in maintaining the data going forward – help them envision a world when they never have to do a reports-to cleanup again – it’s a powerful motivator!
HR should take the lead on this – due in no small part to the fact that they have representatives in most or all locations who possibly know much of their employee population by name if not by sight. At a minimum, they should know all of the managers in their area, and can collect the names of individuals that report to each. In fact, you may find that some of the local HR reps keep this information for their own people, even if it doesn’t make it up to a more centralized location.
Administrative assistants might also be helpful in this arena – they too may collect and maintain some sort of organization chart for their department.
Of course, it’s not a good idea to just dump this activity on HR – the identity management team should do their best to be supportive, whether that means making some phone calls to collect names, or offering up the team’s script writer to help expedite the data collection process.
Step 4: Design the workflow
The line managerment workflow is the most straightforward of the workflows – basically, the request to fill a vacancy goes up to the next person in the hierarchy. If that person is also missing, it goes to the next person, and the next, until someone is found (or it reaches the CEO). The complexity is in connecting roles to people (e.g., Suzy Smith is the Manager of UNIX Engineering; John Doe is the Manager of UNIX Operations). There should also be a default set that until the vacancy is filled; for example, “any approvals that are needed get automatically routed to the next higher person in the hierarchy.â€
The only tricky part here is keeping up with the constant stream of reorganizations that seem to plague most companies. This can either be handled on an as-they-happen basis, or via a periodic verification process. For example, consider a quarterly or semi-annual workflow – which could also be run ad-hoc if needed – that sends each manager (manager in the generic sense meaning someone who manages people, not a specific level of the organization) a listing of their direct reports for review. As part of the workflow, the manager should be able to not only confirm if each individual still reports to them, but they can also select the name of a different manager for individuals who may have moved to another team.
The reports-to hierarchy and workflows should also apply to non-employees. As long as the non-employee’s manager is recorded at the time that they are first entered into the identity management system, they can be included in the periodic verification process, and they would be covered in the vacancy management process.
Step 5: Notification
At a minimum, the people that expressed an interest in the reports-to hierarchy (i.e., the people that participated in Step 1) should receive an email notification any time any changes occur. However, for something as fluid as reports-to hierarchies, sending emails is likely not sufficient because there’s no guarantee that the recipient receives or acts on the email.
A better solution is to create an additional step in the workflow, which is assigning a task to the right people to make the changes wherever they need to do that. The act of making the update is still a manual task that someone has to perform, but by requiring them to mark a task done on a system the task is more likely to actually get done – or if it doesn’t, it will be easy to see by the growing queue of incomplete tasks.
The best solution, of course, is system integration. This ensures that any needed updates are made automatically, without human intervention. The cost of building and maintaining such an integration may or may not be worth it – that’s up to the organization to decide, based on the value they place on having accurate and timely reports-to data. To some degree, though, automation should be fairly simple, if the system being updated is the HR system since the HR system will be integrated with identity management anyway.
In the next segment, we’ll develop the data/access ownership hierarchy and workflow.
0 comments