Although data seems to be on everyone’s minds these days, it wasn’t always like that. In fact, when we consider the old days of implementing HR technology, we remember a long, 9-12 month design phase in which the system was built, and then, at the 11th hour before go-live, someone would shout “give us the data!” followed by us all scurrying around, trying to get it into the new system as quickly as possible.
Thank goodness it doesn’t work like that anymore! Today, we address the situation of data much earlier on in the project.
Preparing your data at the start: real vs. dummy data
A couple weeks after you begin your HR cloud implementation, you’ll start your design workshops and agree how you want to use the system. Then, 6 weeks later, you’ll be asked for all the data that’s required for the types of processes you’ve specified–for example, if you do 5 business processes in week 2, by week 8 you will need to provide all the data for those 5 processes. That can be a lot of data!
Gathering this data is essential because when you get your first prototype back of what your new system will look like (for user testing and whatnot), you’ll want to have real, relevant data in there so users can get an accurate feel for the system. Why?
When people test a system with their own data, they test it well. When people test a system with dummy data that doesn’t look anything like their own data, they won’t go through it as meticulously because that dummy data doesn’t mean anything to them, and those individuals can’t see what it really means.
This is why it’s important to talk about and start collecting that data up front, especially as it will be required within about two months of project start.
What data are we talking about?
The data that you need ultimately depends on the core processes you’ve decided on during your design workshops, and will eventually be delivering. Therefore, just as you’ve looked at the key decisions for each business process, the same thing will be done with data. Start by looking at the key data fields you need to enable your processes.
For example, if you are implementing core HR and nothing else, then you know that you’re going to need a very small set of data around people, their personal information, and their role within the company. (At the bare minimum, every HR system in the universe will require you to enter someone’s department and their role.)
However, if you think about a more complex business process such as workforce planning, you’ll need your core data and then additional data around skills. This is where it pays to think ahead and know exactly what data you need, not simply collecting and cleansing data for the sake of it.
We once completed workforce planning for an organisation, where we looked at what skills the staff had and where they were deployed. Initially, we went into that project thinking that we needed to look at every single, individual skill, but after doing some research and having exploratory conversations, we realised that what mattered to the company was only 5 skills.
Had we neglected to do that research and understand what specific data we needed for that process, it would have taken us infinitely longer, and we would have ended up with data we didn’t need. IN the end, we went out and asked people whether or not they had any of those five skills we previously identified, without doing end-to-end skill catalogues.
If you’re planning on implementing full-blown talent management, however, that will take much longer as each person, their role, individual skill, and individual skill level (agreed upon with line manager) will need to be catalogued, and you’ll ultimately end up with a complete current skill profile. That entire process is a huge undertaking, but necessary in the end.
So again, don’t set out to collect data and clean data for the sake of it, understand what business processes you’re trying to deliver and what the core data structures are, to determine the key data you need to be able to enable that business process, and set about that early.
A little extra advice…
The power of a good tool
When you’re talking about people-focussed technology, the goal is to make it so good that people will naturally want to use it. This follows the assumption that if you give people a good tool, they will not only use it, but use it well.
You may be sceptical, but we’ve seen it happen. Here’s an example.
Let’s say your HR function has an objective to spend less on head hunters and reduce indirect recruitment to 10%. The skills required for that include getting better at social media like LinkedIn, and you could see that by doing that, you would impact your team’s ability to recruit less people from agencies and more people directly from LinkedIn, and ultimately reach that goal.
So as an employee, you set your objectives and you can see (because all the corporate function objectives have already been entered into the system before you started) how your seemingly small contribution added to the big picture of the company. In the past, when you’d simply write your objectives down on a piece of paper, it was less meaningful because they were solely about you, not how you were adding to the bigger pot.
This is really powerful. It makes staff want to go in, use the tool, and do the activities that would be part of the process of achieving success. Having a people-focussed tool can drive engagement in processes that traditionally many people haven’t been engaged with, especially by giving people content that makes the business process more real.
We recently implemented a performance management system for one of our clients and set it up so that when you went in as an employee and set your objectives, you were able to see exactly how those objectives were going to support your manager’s objectives for the team, and how your manager’s objectives were supporting the departmental or functional objectives. This was a huge success with the organisation and bolstered engagement.
Good luck with your implementation!
For more information about data for preparing for HR cloud, please get touch.
Comentários