Data and information, are both separate things. Unfortunately many people have trouble distinguishing them and this is where you have wasted time, frustration and the occasional email war.
I'm sure we've all had the situation where we've asked for a clear set of information or asked a specific question, only to be sent a 120 row "data dump" with the answer allegedly lurking somewhere inside.
Data is raw, unrefined information devoid of context and conveys little if any story to the interpreter. Information sits at the opposite end of the spectrum and allows the business to make informed choices.
With any simple datasheet most people automatically convert the data to information on the fly, seeing patterns and extracting answers. Once you start moving to the realm of HR analytics, cross referencing data silos and hundreds of rows spanning dozens of columns your ability to do this 'casually' becomes severely limited.
One of the lessons i'll remember from one of my previous managers is that she would always ensure a question stayed front of mind when I produced reports or graphs - "what story is this telling?". It's important because not only does it provide purpose and direction, but it also keeps the audience front of mind.
To tell a story you need defined roles, clear actors who know what they're doing, and a plot that is internally consistent. Where am I going with this? it's a metaphor for how you can set up your data in your HRIS or Payroll system to help avoid unnecessary complexities down the line.
1. Each field in your database should only hold one type of information. This ensures your dataset is pure and provides confidence in your findings:
One of the most common mistakes i've seen. For instance a salary pay class field which people try to use as a differentiator of your industrial instrument or a location field which tries to denote cost center. If a field is telling you more information than its purpose then it should be coincidental (and this will frequently occour sporadically as an emergent property of the data). However by relying on a field to tell you more than one thing you'll soon end up in a situation of trying to line up 2 pieces of string that are different lengths.
You might get 80%, even 95% of the way but in doing so you will always leave yourself a manual checking process at the end by definition. This is where errors occur and time is lost.
If a field of data tells you something more, that's a nice bonus but don't build reporting structures that depend on it.
How do you fix it?
Split those fields up! If you want to report on salary class and industrial instrument then enter them separately to begin with. This will make your pivot tables 10x easier.
2. Remember databases often work in silos, with various clusters of data attached to specific key entities in the system.
A common example here is the split between employee and positions. Biographical data, work pattern, probity information - this will be typically attached to an individual. On the other hand Position title, reporting line and business unit will typically be attached to a position.
Now comes the interesting piece - where do you want to put everything else? Will your cost centres be attached to the individual or the position? What about location of work? How will these two silos interact?
What are some examples?
For instance, by having hours worked per week attached to an individual and FTE capacity attached to a position you can suddenly start to see your vacancy rate or;
By having remuneration bands attached to a position you can report on how individual salaries compare against theoretical market bands and structure in remuneration growth capacity.
3. Don't be afraid to roll your sleeve's up and do some old fashioned adventuring!
I'm always surprised by the number of people that suddenly stop when they don't know how to do something in a database, excel or word and just put their hand up for some "expert" to come in and fix it for them.
These programs are incredibly advanced in 2017 and if there's something you'd like the system to do, chances are it probably can but you just have to do a little bit of self learning to find out.
Keep the 70/20/10 rule in mind. 70% of learning comes from actually doing, 20% is mentoring and 10% is structured learning.
I can definitely put my hand on heart and say I never truly understood v-lookups or index-match functions until I just dived into some data sheets and ran the formulas directly.
A recent example I've had is actually looking into FTE functionality in CHRIS21. I was having a hard time finding a way to easily add up the individual hours people were working within a single position, after going for a 'digital wander' I discovered the PEM (staff in position) screen which automatically pulls individual, current and historically attached to a single position code.
So how can you kick things off?
Start clicking on buttons to see what they do, hover over icons for the help tip, enter a quick question on Google. Most of what I know has been self taught and has come from literally tinkering with these programs to find unique ways to get data out of them.
