Part 2: Lifecycle experiences
The lifecycle of an employee provides us with many opportunities to collect diversity data. The HR processes themselves are generating data on an employee so why not collect a little more........ right? Well, not always.
The perceived value that diversity data can bring can blind us to the realities of governance. Leaving organisations exposed to the risk of a misuse of data, or a breach, albeit internal.
Sourcing diverse talent
Recruitment is increasingly becoming the preferred process for collecting diversity data. The values of this are appealing:
The default process for collecting applicant diversity application is within the application itself. There's probably a purpose statement along the lines of "commitment to equality" and a belief that the system storage of data in the process will inform all other downstream processes. But the data itself is tainted.... here's why:
My biggest observation here is in the process design and system capability for collecting the data, clouded a perception of value. When a person clicks on an advert, they are requested to either log into and existing profile or create a new one from scratch before progressing with the application. Recruitment systems generally manage two broad processes. The first being the creation of a candidate profile (which stores as a data table) the second managing the application (which stores as another data table).
One candidate can have multiple applications and more often than not diversity is asked within the application, rather than as part of the candidate profile. This creates duplicate rows and removes a single source of truth.
My next observation is the purpose of collection and blurring of diversity "profile" and inclusive adjustments required for an application. Most application forms that are requesting D&I data do so with a statement that refers to the application and doesn't go as broad as to state the data is intended for uses in downstream processes. Unless carefully stated, any diversity data collected for the purpose of an application fulfills its purpose once the application has closed. The data should be destroyed or inaccessible for other use.
As attractive as it is to collect diversity data through recruitment, if it's not done right, it can't be used.
Onboarding successful candidates
Onboarding is the process of converting a candidate into an employee and getting them set up for payroll. It is arguably the most crucial point of data collection. HR systems are improving in their functionality of connecting recruitment to payroll but even with interfaced systems there are requirements for data collection......so why not collect a little more...... right?
My observation here is the expectation that people will provide the information purely because it's part of the onboarding process. The issue with this is that diversity information is not a requirement for onboarding. Yes, there are mandatory data elements that have a clear purpose of creating an employee payroll record. But this is not the same purpose as collecting diversity data for analysis, or monitoring equality in processes.
Diversity completion percentages when the data is collected at onboarding is low. I don't claim to know the reason for this, but I suspect individuals are a little fatigued with the amount of data they need to provide for onboarding, and deep down they know diversity information isn't required, so don't feel compelled to provide it. They're even less likely to provide it if they already did during the application process.
Managing and farewelling diverse talent
By this stage there really should be no further need for the collection of diversity data. But as we've discovered response rates to diversity surveys are so low, organisations are faced with the constant challenge of maintaining diversity data and encouraging those who have not yet provided to do so - but to do so only once for all systems!
Systems are improving, more and more organisations are moving away from the "best of breed" platforms that are specific to one process, to the "end-to-end" platforms with data flowing from module to module. My historical observations here have been in organisations that haven't had integrated or interfaced systems and have therefore requested employees to complete yet another diversity profile for another process and another system. This once again creates multiple records for an employee, and we lose the source of truth.
More recently I have observed organisations opting not to have diversity as part of a secondary system profile because it has been collected at core. Instead, they rely on analyst to be able to join data from multiple systems to provide insights. Or those with more advanced interfaces between systems migrate the data from one platform to another.
The issue here comes back to purpose. An employee may be willing to provide diversity data at onboarding or updating a profile after a campaign. But they might not be aware that reporting analyst has access to their data or that it is indeed moving from one system to another, nor are they aware of how long the data will be held and used for analytics after they leave.
Without consent, this is a misuse of data.
To sum up:
In part 3 I will draw on these lifecycle experiences and provide some recommendations as to how I think it can be done right....... more to come!
Leave a Reply.
WHAT I DO
WHAT I'VE DONE
WHAT I TALK ABOUT
Owner: Richard McMorn
Entity Type: Sole Trader
ABN: 28 825 984 791