HR Vision Podcast #21 – A practical view on HR Data ft. Dan Reader

Ivo:
Hey everyone, and welcome to the HR Vision podcast. I'm your host, Ivo, and every week I'm going to have a conversation that matters about HR.

This week I have with me again: Daniel Reader. What's up Dan? How are you?

Dan:
Hey Ivo, I'm good, glad to be back.

Ivo:
Yes, you're back indeed. If you don't follow the podcast that often, Dan is here with us for the second time. We liked him so much the first time around. That's why he's here again. That's basically what it is. No, not really!

The first time he was here was to discuss his experience as an HR tech consultant. But today we will discuss data. Not in a very technical way, but more the high level importance of data in HR. And Dan was kind enough to say yes to the challenge.

So Dan, you ready?

Dan:
Yeah, am I, just to check, the first two-time podcast guest?

Ivo:
No, you are the third second-time podcaster. So you're in the top three, on the podium at least! OK, yeah, sorry for that man. I should should have checked this with you first.

Dan:
I'll come back the first time and then I'll break the record!

Ivo:
Yeah, alright! OK, so let's just dive right into it. Why are we doing this? About data. Big part of implementing a new HR system has a lot to do with data. Setting up, integration, data checks and all that jazz, right?

So let's start with the basics. In your experience, with what is in an HR database, and what is the benefit of centralizing that data?

Dan:
Your HR databas is, even if you don't understand techie IT speak, the chances are you've been using an HR database for a long time. HR is a very data centric department. It's effectively just a repository for the information that you store employees. The term centralization and centralizing been thrown around a lot in the last few years.

Effectively Microsoft has got the Dataverse now, formerly known as CDS, which is a way of centralizing information. And what that basically is in a nutshell, is using one data source for all your information, regardless of what operating system you're using, whether it's HR data or Finance data or procurement data or building and legislation data. It all goes into the same pot, so you can have one data set that you can report on. And you can extract data from.

Benefits wise, you've got the main one, centralization being your improved data integrity. As I mentioned, then it's sort of a 'single source of truth'. You don't really have to worry about pulling bits of data from random databases around the system. Correlating it using all sorts of weird and wonderful Excel formulas and then passing that around the business. You've got one source of information that you can report from. It minimizes all huge data duplications as well, and if the business has the confidence that the information is being stored in a single location, it doesn't need to be duplicated and then put anywhere else, so it reduces a lot of the potential risks involved with data inconsistencies due to personal errors.

Big one, even though it's quite a big expense initially, and there is a massive reducing cost in the long term through using things like the Dataverse. Centralizing your data does allow you to have one single database. So you can cut down a lot of third party applications if you need to do. You can also cut down on storing information in external places or external systems if they're not required anymore.

I think personally, the big one for the Dataverse is that you've got centralized reporting. So you've got one report until across the entire organization. So you don't have one person in the organization that knows how to extract reports on the payroll software, and another person that knows how to extract reports on HR software. Everybody can use Power BI. Everybody can use the standard set of tools. Obviously with security involved to hide information that you shouldn't have access to, but it's one way of teaching everybody how to extract data and it really makes everybody's life a lot easier for supporting that as well.

So those are really the big four benefits as far as I'm concerned. If you want to think about centralizing your data.

Ivo:
OK, that's interesting. Is there a benefit also, like the the quick access that that data has compared to when it's stored locally? There's a big difference with Dataverse? Because yeah, from what I understand everything is in the same place and everything is easily accessible, but that's quick too?

Dan:
Oh yeah. So using things like OData, or sort of bringing your database exports, the data that you're accessing is up-to-date information. And it can be pulled out immediately.

Ivo:
OK, that's cool. I have kind of a simple question, but what is the difference between general HR data and HR Analytics data? My assumption is that, of course I'm not from HR so Full disclosure, but from my understanding HR data is related to all the data that you have from your employees in your organization. Analytics is what you do with that data after treating that data. So you get analysis and reports regarding the data relating to, I don't know. Performance management, those kind of things. Am I correct in this assumption?

Dan:
Yeah, I think that in its most basic sense, I'd separated into the following, really like it. HR data is exactly what it says on the tin. It's just data. It's information that's collected and you can use that to answer a question. So it sort of provides a singular purpos,e so you can use that data to ask the database a question and say "How many employees do I have?" or "How many employees live in Manchester?". And it will give you that answer.

Analytics to me allows you to delve into the data and look at things like patterns and correlations and that sort of thing. So you can use the data and in an analytical sense to look at, for example you might want to delve into the reason codes when people hand their notice in based on location. And then you can find a pattern of "OK, people within our Paris branch are leaving due to salary being too low.". And then you can start looking at what lifting your salary in that particular location. Or looking at competitor wages and working on that, so it reveals a pattern in the information, something that you really only get when you're thinking about it analytically. Yeah, but I keep asking the same questions time after time, or asking its singular questions. You're really not getting the benefit of the dataverse. OK, so think about the possibilities rather than what you currently report on. That's the main win.

Ivo:
OK, alright, I think you already gave the answer of my follow-up question which is: What is the importance of data in an HR system? And I think a lot of that is like you can take a lot of decisions just looking and analyzing through that data. So for you, are there any other important factors for data in HR systems.

Dan:
As I said, I think one of the things I talked about last time as well, was sort of the history of HR, and it is, as I said just before, a really data heavy department. Because that's what it's historically. It is literally just storing employee information, in a very much like a cost-center scenario. You're literally taking information that the employees give you, you're storing it in a database, and you are reporting on that information.

If you're reporting on that data, you are pulling out how many employees you got, how many employees by cost center. Good data in your system; cleansed data when you go live, when we do the data migration, if you put the effort in at that starting point, you can look into having really brilliant data, where you can look geographically your data. You can look at patterns in the information on employee metrics, how long people are staying with the business, what age range you've got. Really weird things like 'How many employees can speak French and know how to fix a car?'.

Good data goes a long way. I think one example I always got given years ago was: There's a supermarket chain in the UK called Tesco. And using that sort of like 'club card' information. When you scan your card. They can predict when a couple are gonna get divorced six months before they get divorced.

Ivo:
Like they're gonna have babies or something?

Dan:
Yeah. Based on buying patterns and that's the kind of dataset. If you really want to think about what is and isn't good data: that's good data. Because you cannot get more accurate. Because it is literally just like you're taking it from transactions and you're looking at the analytics and the patterns in the information and the buying.

So yeah. Going back to HR. Data is at the core of it. I think when you're looking at moving from a cost center to a profit center. So when you're looking outwards to the business and what benefits HR can give the business, your data is really the core of that, because that's the main tool HR have. That's really it. If you can get the information off your employees. If you've got employees that are willing to give you the skill information and competency information and address information. That can be used to build up all sorts of benefits to the business, even outside of HR. You know?

Ivo:
Yeah, and support business decisions, right? You have more data to support like 'We should hire more of this or more of that because we are lacking the skills.' And only the data, and a good data can can can give you that right?

Dan:
Yeah, really like that's exactly it. If you don't know how many employees you've got that know Power BI, or that know how to fix a car. If you need that information, you haven't got it, or if you've got a platform where people can import that data themselves and it's easily reportable. I.e. all dropdown fields and it's information that you can easily sort news. The sky is the limit really.

Ivo:
Yeah. You said before that this data is all stored, specially with Microsoft Dynamics, is all stored in the in the Dataverse, is easily accessible. It can create reports and all that. The system integrates that data and manages this in a way that it's quick and accessible to you, to create all kinds of reports that you want to, right? Now my question is, from the side of the employee, for the employee experience. How can good day to improve the working experience? Because we're talking like on a business level, but for the day-to-day user of the of the platform, the employees, the HR professionals, how can good day to improve their working experience.

Dan:
From a HR point of view, I think one of the the the big wins that centralized new data, or something like the Dataverse does, is that it creates a better environment for doing things yourself. So historically, back in the days of SQL reporting, organisations were pretty limited to their reporting capabilities by the reporting team. I'm sure anybody listening that's dealt with the reporting team knows that they're all really, really busy people, and there's normally a really long waiting list to get that data prepared and built and scheduled. Whereas if you're centralizing, you can use things like Power BI, so you've got a single tool that you can train out to everyone in your department, and after a little bit of training, people can run their own reports. So if you need to prepare some information for the finance department or for the Board of Directors on whatever it may be. Benefits, employee retention information. It's easy to access and you can access absolutely up-to-date information.

So yeah, that's probably the biggest win. It really empowers HR department. It allows you to report on more than one aspect of your data. You can incorporate different bits of information from different systems as well, just using the integration that's built-in standard with the D365 platform.

From an employee point of view. I guess another thing is that you've got a lot more visibility of your information. That's more important than ever in this day and age, so using things like the employee self service, you can add in reporting widgets in there that will show people things like their total rewards statement. All information that's being stored on them by the company, any detailed benefit, Payroll, HR, finance information. Even things like vehicle leasing information if that's stored.

If you centralize it in the Dataverse, you can report it because you've got that primary key of the employee ID. That's the first thing that you get when you join the company. Before you do anything you get given a person number. So that ID number could be carried to every single system and it can all be reported on the Dataverse. So you've got an easy way of showing a complete audit trail of everything you need.

The other big thing, but a more process related benefit. You can use the information that's within your HR database. For example, you want your positional hierarchy information. You can pass that through to all the departments and it can be used for things like approval limits on purchase orders and sales orders. You can utilize the data that's within HR. Actually take the positional hierarchy and use that as a workflow. Hierarchy in other systems. So you don't need to create individual sort of workflow and hierarchies within all the systems, because you can just use the data that you've already got.

If HR knows that employee reports to line manager A. Why should it not be passed through to all the other systems as well? Because you only update it in one place. Then if something changes and line manager A leads the business and line manager B comes in. That change can be integrated to all your other systems so you don't have to make 10 changes. That's the importance of good data. You're not duplicating the information either.

Ivo:
That's absolutely important indeed. And I was thinking about things like simple things like leave and absence, time registration that it's in a click of a button that you can access all the information about your own personal profile. What you've been doing with the company, your latest performance management reports, those kind of things. They can all be integrated with the with the system. And the data is there to show at the click of a button, right?

Dan:
Yeah, it's all in the box, so yeah, you've got everything in one place. You can even link in external features through things like power apps or external links to different websites. The data is all on surface level for the employees.

Ivo:
OK, alright! Let's try to give people listening... How do you go about when you start a project? How do you handle data integrations in HR systems? I know, sometimes this can be depending on the company and the complexity of legal entities and how many cost centers you have and everything. It can be very complex and and it can be time-consuming as well. But overall, let's give a picture of how do we handle data integrations within an HR system.

Dan:
In its simplest form, I think the first thing we always need to ascertain is what sort of integration is within their design. Is it going to be something that's a one way street, so we're going to send the information from the HR database to another platform. So for example, if obviously we're talking before the merge next year, but as it stands now, if you've got a D365 HR and you've got Finance & Operations. You really want to set up an integration between the two. So normally we need to ascertain whether that's going to be a two way stream. Is there any requirement for information to come back from Finance and Operations? Or are we just sending information straight through FnO as and when it happens.

The next step that we need to have a think about would be, whether or not it's going to be trigger based or interval based. So for the trigger based integrations: it's when something happens. So when a certain fields updated on a record that triggers the integration. Which can be a little bit more complicated to make than an interval based integration, which will happen at set intervals. Whether that's one today or twice a day, or every hour depends on the requirements from the client. Normally it's an overnight routine that will take everything in a specific database and extract it.

Now depending on... I don't really want to get into the technical side too much, but really at that point it's a decision as to whether we use the standard integration technology that's available in powerapps. So for things like D365HR to Finance and Ops, we could use the standard integration technology that's there. If we're integrating to a third party app, we'd have to look at doing a database export to a custom built integration platform. But we'd have to do that based on requirements and what field that need to be pulled out.

But we can use the information in the dataverse to automatically push that data through, if it's required.

Ivo:
OK, just a curious question. What is the simplest version? When a customer doesn't have any system, only uses Excel files so you take those Excel files, just upload it into the platform. What is the easiest? Or when they have other system? Actually that custom integration is so easy to use for example. I don't know, that's why I'm asking.

Dan:
Oh, so if you're gonna go if you're talking from day one, how we add the data; actually building the the HR database. It depends. I think there's no right or wrong answer with that one. It really depends on how long the how well the data has been maintained throughout its lifespan.

You can get instances where people have been using Excel for the entirety of their tenure as a HR professional, at a business. And they've been maintained in the data really, really well. You also get people that have been maintaining the Excel data really badly. And you can get the same with larger systems as well.

Some of the common issues that we've had over the years are: I think the most common one that is difficult, is actually extracting the data from existing platforms. Normally the easiest thing to do if you're gonna export your data and if we're doing a project with you, we'll speak to your existing partner and we'll look at getting that data extracted into a certain Excel format, and then we can import it into the system. So rather than integrating it automatically, we'll go through cleansing the data, because nine out of 10 times the data just needs to be checked. Spending a little bit of time looking through your data and looking through some possible improvements to the data can make your life a lot easier down the road.

Ivo:
OK, yeah that would be my follow-up question to that, which is: In a lot of projects customers come in without really a clear understanding that you need to do some kind of work with the data that you have before you upload it into the system, right? So my question is, how can customers optimize their data and... something like a suggestion like don't wait until the last moment to put your data in order before you start adopting a new system. So my question is: How do you take on data preparation? Glancing during implementations for customers?

Dan:
The $1,000,000 question... I don't think there's an easy way to do it. In an ideal world everybody would have a month of the year where they just spend the time cleansing their data and keeping things up-to-date. Unfortunately life always gets in the way with these kinds of things.

I think a lot of times you don't realize there's a problem with your data. Until you try and put it into another system, you might not realize that there's anything wrong with your data. And I think that's the common misconception that we have when we start projects that people will come into a project thinking 'our data is fine'. There's no problem with our data. And then it is sort of put on the backburner.

Ivo:
Can you give a small example of that? What what can it be like a problem with the data that people don't usually see?

Dan:
It's normally formatting issues or duplicates in certain things like employee numbers or naming issues. Things that you do not think you have a problem with. And depending on how your system operates, or it could be the way that your employees are linked with positions. Might not line up correctly with what we need. These are all things that you'll get problems with when we try and test the migration of the data.

So these kinds of things will normally get put into the background because there's normally more important things to be thinking about as far as end users are concerned, which is "Can this new system hold all our information? Can I do my job in this system?".

And I get this. There's a lot to think about when you're actually starting a project like this, and that's why we have project managers and consultants and stuff like that. We're there to help guide you through the journey. It's always something that we spend a lot of time with. Really reading the riot act to clients really, just kind of stressing that your data needs to get sorted. Now I know it's really boring, but like it needs doing.

I think there's a lot of wins to be made in your data as well. Because if you're taking really dirty, badly managed data, we can probably put it into D365 without any issues, but it doesn't necessarily mean we should. So you really understand you only get one chance to kind of make a good first impression in the system. But like, putting in your personell data is the first thing you do. And everything gets built off the back of that, so your employees get put in, the start dates get put in, who they report to. And on the back of all of that, we can do you leave and absence. Your benefits compensation, all that uses your employee start date.

So things like your employee start dates aren't correct, or you seniority dates, or anything like that. It's gonna knock everything out.

Ivo:
Yeah, because there's dependencies in there.

Dan:
Yeah, there's a lot of dependencies. Your data is the foundation and a lot of the functionality feeds from that foundation. So bad data sort of creates bad processes to account for the bad data and then that can lead to like complex developments. And obviously there's a cost involved in all of that and it does cause a loss to system integrity as well. You shouldn't be making processes to account for bad data. That's the main thing to take away from this. And it's something we've seen hundreds of times. Not necessarily with our clients, but when you come in a client's been using a legacy system, it's normally something bespoke that's been built for them. These things normally have certain quirks and random bits of data that are being stored for some reason, and it's not a bad thing to ask the question why you store that information. If it is something relevant to the organization, do you need to store it? So if you're storing something absurd like hair color for example?

It's just weird and wonderful things like that they may have had a field for. Do we need to bring that through to the new system? Is it still required? I've never encountered anywhere that stores hair color. Can't report on how many ginger people work for you or anything weird like that. But yeah, I think a good example is like a certain data types. So if you've got fields for sort of geographical information is always a good one. So for example, you might see Manchester as a location. I'm also biased 'cause that's where I'm from. Manchester on one person to record and another person's record, the location will be MCR, which is an abbreviation. And then you might see MANC which is a different abbreviation.

So all of those. You're losing a load of reporting information right off the bat because you immediately have to then do the aftermath work of cleaning this data up after the fact. If you clean it up before it goes in, you never have to think about it again. And if you speak to a reporting analyst within HR, I can guarantee you they'll normally say reporting ZZ, the two hours I spend after I created the report. Running all sorts of Excel addons and formulas to try and tidy up the data is the bit that I hate. If you can sort that out in one fell swoop. You're fine.

Following go live, for new data that's put into the system, we can account for all that we can build processes. We can put things in the system where people have to specify the information. We can create dropdown lists instead of text-based fields. So we can make sure your data integrity is a big thing. Post go-live, pre go-live cleansing your data. That's the trick really.

Ivo:
Yeah, I think what you said there before about foundation is indeed the best analogy that you can have. It's like building a house. It takes a lot of time. The foundation is the part that takes a lot of time, because it needs to be right. So the house then can be built on it. People need to understand that data is very important. You better do it first time, right, because then you will have a way better usage of the system. Everything will work perfectly and I've seen a lot of what you said in like email lists or stuff like that. Like leads on CRM and stuff, because indeed. The example you said is super useful like the city that you described as MAN or Manchester or those kind of things are so common mistakes. Even if sometimes you don't refer to them as mistakes because you don't really see it at the time. But when you have a system that is depending on that data to work properly, you need to fix it from the start.

Dan:
Definitely. Like we said, it's not something that is necessarily a problem and it's not something you'll see as a problem going in. But until you extract everything information in the system and everything is laid bare to see by everyone. That's when it becomes a problem and it's like you say with CRM; lead information in CRM is just ridiculous because sales guys will only put an abbreviation of the customer name and when it gets through to the creation of an account... You've won this business from someone and then the first thing you're doing is contacting them asking for the correct address information. It already sets you up on a bad foot with your client because you had bad data in the first place. But stuff like thatis really important in a relationship as well.

Ivo:
And then when you build a campaign and you need to create a report and then you need to source all these types of different data and figure out and then cleansing again. "Oh my god, we have so many different guys from Manchester with different abbreviations." or whatever. And it's yeah it's a mess. It becomes a mess.

Dan:
It's something people dread doing as well. They'll avoid doing certain things. Because they know it's going to be a lot of hassle. They'll avoid reporting on certain things, they'll avoid putting certain financial dimensions on people because they've never cleanse the financial dimensions and sorted them. So we've seen places in the past where they don't have correct financial dimensions on anything, even outside the HR data, because you're not; because it's too much of a job when you go live, but then before you know it, you're three years in and it becomes an impossibility to sort it out.

It's something that requires a lot of care and attention off the bat and it will save you all wallets and sanity. Along the road.

Ivo:
Like a lot of things in life, it's not fun to do, but you have to do it. I guess that's the point. Look, that's about all the questions I have for you. I just wanna have as usual or less to kind of a challenge. If you want to give an advice for people listening regarding data in HR, what would you say?

Dan:
I don't know. I'm not gonna say "don't do drugs" again like last time. I feel like you were setting me up for that there.

Ivo:
No I think it went well! I think people appreciated the the suggestion.

Dan:
I think that our reputation in the Dynamics community dropped because of that.

Ivo:
Of course, because of the podcast. Yes.

Dan:
Yeah, I don't know really. I think it's very, very difficult to kind of give people advice on their data, because as I said, it's such a big job for people and I think all time you don't realize there's a problem until you get to do a project or like some way you're implementing 365. That's the point when you get your data out. I guess my only advice for it will be: Trust the consultants on it, really. Because we'll always say the first thing will always start saying when we start project is talking about data and again just work with consultants on it.

There's a lot to be gained from getting the data right at square one. There's a lot to be gained from cleansing as much as you can and really think about: Do you need it? Because there's nothing wrong with asking the question of "Do you need to take these days are over?" Because you'll still have your legacy database that could still be imported into. The date of birth. You can still report on that legacy information. It won't be lost, but is all that information on employee records still valid to the organization? In 2021 do we still need to be reporting on employee hair color? No. So there's no point creating a field for it. There's no point in filtering it.

Think about what's actually important to the running of the organization and what's actually important to HR being a profit center rather than a cost center. So when you look at the information, is there a benefit to the employees and the business of also storing this information reported on it.

Ivo:
Yes, I think it's important. Also what you said regarding when you go through some through a moving to another tool to another HR system, you will have consultants that will help you guide through the process. So you're not alone in this, despite sometimes the task might be a bit daunting. But the consultants are there also to to support you, to guide you through to understand what is important to ask you that question "Are these fields useful? Should should we just keep it on the legacy but not in the new system and those kind of things?"

But, from my side, if I may. I think what you said throughout the whole the whole episode today is just: Take take some time to look at your data, frequently if you can. Cleansing is very important and think of it despite being yeah, time time consuming task is important too. It's important to have it right because it is the foundation of your HR home.

Dan:
Yeah, it really is. As you said, it is a daunting task and it can feel like that the start of a project. You're just given an obscene amount of data templates with examples on. It is very, very daunting, but it's as you said, it's what we're here for. And the benefits of that that little bit of extra work that start the project. And just questioning why the business does certain things, you know? Now saying assistant to hold data that's of no benefit to anyone. It doesn't benefit anyone.

Ivo:
There you go. Thank you Dan. Once again, this was great. I hope you enjoyed it.

Dan:
I did. I think if I come back again will have to talk about something different though.

Ivo:
Yeah? OK!

Dan:
Like a film review next time.

Ivo:
A film review? Yeah why not? Maybe some something related to HR. What do you think?

Dan:
We'll find something!

Ivo:
OK, let's do that. Alright then. Thank you so much for taking the time.

We really appreciate everyone out there listening. Take care and we'll see you next time.

Dan:
Bye guys.