This is the third article in this series to have an effective HR Strategy while on the transformation journey. You can find links for the rest of the blogs at the bottom of this one.
Today, we are going to uncover good practices and approaches around enabling COEs and HR Services.
COE taxonomy and management
HRSD case management comprises dedicated tables to record based on different functions and disciplines within the HR department which are known as HR COEs e.g., Talent management, Rewards, Workforce Administration, etc. All these COE tables are extended from the parent HR case table. This allows great flexibility in terms of data management, security, and autonomy for each HR function.
Here is a simplified view of how COE taxonomy works.
Beyond COEs, there are additional levels of categorization existing in the form of topic category, topic detail to which an HR service is mapped at the most bottom step of the entire hierarchy.
- Most of the customer coming from legacy HRMS needs to have this clear picture as the previous hierarchy existed in the form of category, subcategory, and sometimes subcategory level 2.
- Assessment and category mapping exercises need to be done to ensure that the category is tagged at the right location i.e., dental benefits should be sitting at the HR Topic detail level and not a Topic category.
- Consideration should be given to standardization and not location-based unique categories.
- HR Services should be unique enough in terms of audience, accessibility (from portal vs. Agents), or workflow process associated with it.
HR service activities
For all we know that Service catalog can be associated with a flow or a workflow to build the process after a service request is submitted. You could always do the same with HR services however there is an underutilized feature called HR service activities which allows you to empower your business administrators to configure an HR process efficiently.
HR Service Activities has capabilities to invoke different HR TASKs, approvals, or another HR service as part of its workflow with any given order with its simplest means of configurations. Since a lot of us have ITSM in the backyard knowledge center, we tend to spin up workflows wherein an HR service activity is an easier option to configure, maintain, and scale the HRSD.
Most standard HR processes can be fulfilled via basic HR Tasks or approvals while some may still require additional business logic or integrations. So, when designing an HR service, we should start with HR services activities as a standard approach and then move up the ladder with flows/workflow in complex HR services.
COE Security Policies
ACLs have been there as the core foundation of security on the platform since the beginning. However, it's vital to understand the ACL rule execution and its whole anatomy to not break the security around a table.
HRSD offers a better way to manage security around COE-specific tables via COE security policies. These policies have a way of providing read/write access to an HR Fulfiller group. Beyond that, it also can be applied at the HR service level for a COE which makes it a powerful choice for managing COE security.
This way, you can not only manage access for different groups for different COEs but also take it forward to VIP cases, special locations, and sensitive cases. In a nutshell, COE security policies cover
- COE
- HR Service
- Any Case level field e.g., Priority, location, department
So, it's always advisable to leverage COE security policies instead of ACLs for HR service delivery.
Manage Request Views
In my opinion, this is one of the most underutilized features of HR service configuration. When you configure an HR service, you can control the fields visible to an end user based on their persona e.g., subject person, opened for, assignee, manager, etc. This configuration is stored in the sn_hr_core_config_case table and referred to within an HR service.
Not only that, but you could also take it further to other fields and plan to bring them to my request page on the employee center with a basic configuration. Moreover, these views can be specific to an HR service level.
Without this feature, the developer would end up cloning the OOTB widget and creating their custom version of it thus introducing technical debt to the platform. Thus, plan to look at default views and amend them based on HR services without introducing a single line of code.
In the below example, I have added a location field for a specific HR service.
You can see that the location field has appeared on my request detail page.
That’s all for today. Happy Learning !!!
1 Comment
