HR cloud implementations move fast. One moment you’re having fun with your team during a design workshop, discussing new ways of working and potential options of using a new system, the next moment you’re lying awake at night because the configuration team has started demanding answers to decisions that you may not have made!
For every business process that you are implementing, there are a number of key requirements that need to have been defined before you start your project. Because these are the same for all cloud HR software, you do not need to have chosen which software before engaging your stakeholders in critical decision-making before your design phase.
For some processes there may, however, be quite detailed decision-making and content-building necessary at an early stage, especially when those processes are new, transformational, or critical to your industry sector or business. Here are some classic examples of each.
Example 1: Manager Role & Responsibilities
Imagine you’ve just begun a design workshop on Core HR–transactional processes, such as starters, movers, and leavers. With the Employee Self-Service (ESS) and Manager Self-Service (MSS) functionality available in cloud HR solutions, many businesses are seizing the opportunity to re-visit the way that people transactions are delivered, and looking at opportunities to move more away from HR & central functions and towards managers.
But the spectrum of what managers can do is wide. On one end, your managers could be able to view details of their team, receive requests for leave, and approve those. On the other end, your managers could be driving a highly proactive performance process, feeding into a global talent assessment process, and doing online bonus and merit reviews.
If you go into a workshop on talent management, without having agreed with your business stakeholders what the role of a line manager will be in these processes, the project will be put on hold whilst you figure out what you want. These decisions take time to agree upon and should be made before the vendors walk through your door on the first day. It’s essential to know what you’ll be working towards.
Example 2: HR and Payroll
This one usually rears its head in some shape or form during the design phase. It is common to see an HR project which does not have payroll in scope–I am not sure there is such a thing. In most cases where HR and payroll are not integrated, HR feeds payroll, and if it doesn’t today, it will in the future. Payroll usually makes everyone nervous–and for good reason! We all live in dread of a new HR system being turned on and payroll not working perfectly.
As you go through your first design workshop, Core HR, you will inevitably land on the compensation screens. This is the point where you need to be clear about how compensation data will be processed, and, specifically, what the boundary is between what happens in HR (system of record) and what happens in Payroll. It sounds simple, but experience says this decision always brings about more debate than anticipated, especially when you are operating internationally across several countries and / or have multiple payrolls.
Making changes to the operating model between HR and Payroll impacts not only the design of the HR system, but also interface requirements and, more often than not, the payroll system. Getting this agreed and signed off by all stakeholders prior to the first design workshop will reduce the risk of delays, which cost time, money, and credibility.
Example 3: Performance Management
This is a hot topic as many organisations assess the value of traditional methods, yet sometimes unknowingly walk into a contract with a software vendor that could tie them to a very structured and traditional process.
Most cloud HR systems are designed to deliver a process that support traditional start-of-year, mid-year, and end-of-year procedures. However, if your business is looking for a more dynamic and fluid performance management process, that is something that needs to decided beforehand, for that functionality is fundamentally different from standard configuration. Ideally, this requirement would be defined before you sign a contract with the software vendor, as it involves commercial negotiation and impacts design decisions.
Organisations are getting better at moulding their performance processes to the relevant groups of employees, looking to ensure maximum engagement and drive better outcomes by NOT having one standard process for all. Performance Management is the area where companies often bend their entrepreneurial spirit to accommodate the standard processes delivered within the cloud HR system – this could and should be avoided if you want to maximise the investment your company is making in HR technology.
These three examples are just a few of many high level functional requirements that you need to address either before you contract with a software vendor or before you start your design phase. The good thing is that you know the modules that you are looking to deploy and the outcomes your business is expecting. So the questions can be predicted and the answers prepared… preferably long before you start that first design workshop!
By Helen Thiel. For more information about reporting, insight, or implementing Cloud HR technology, please get touch.
留言