We’re data focused. It’s what we do better than almost all the other UKG consultants we’ve met.
But too often, it’s hard to get the right answer. No matter which API or reporting tool you choose. You need to perform the data double backflip with a twist. With your eyes closed.
Because the setup isn’t right.
Why?
Because like any large, complex system UKG Pro and UKG Pro WFM need to support three things:
Transactions, Analyses and Audits.
Transactions – You need to do something to keep the business running right now. In our case, that means recording time and paying employees. Any implementation that go lives will get this done or the business will close. If you can’t pay your people, they aren’t going to hang around.
Analyses – You need to understand what happened when you review your data a day, a week, a month, or a year later. Moreover, answering most questions shouldn’t need special knowledge of your rules. Here’s a good test. You hire a new report developer, whether as an employee or as a consultant. This person knows UKG People Anlaytics. How many times do you need to say, “sorry, I forgot to tell you.” Or “sorry, that only happened once. That we remember”.
Audit – Your data needs to be self-explanatory. No audit is fun. But convoluted explanations make audits worse.
Here’s a simple example. A certain client didn’t enter employee transfers in a timely fashion. (I’m sure this doesn’t happen at your organization. But pretend for the sake of the example).
The employee gets paid. But all the org level and/or job information isn’t right.
The correction shows up in weeks or months later. So, they make the appropriate change.
But they use the same earnings codes they use for a regular payroll. So, the numbers balance for the company. But departmental analysis shows some strange numbers. A department with $100K monthly budget shows a $250,000 month. Year to Date all is correct. But the month is crazy.
Of course, a little analysis means it’s not hard to figure out what happened. But separate adjustment earnings codes would make it obvious.
This is a simple example. Using different codes is even more useful when you want a different G/L treatment. Because it’s a pain to reconcile Payroll vs G/L when there are ALWAYS adjusting entries.
Why does this happen? Because too often the consultant or the team was under pressure. And they wanted to get the transaction done now.
But the right answer isn’t always the fastest answer.
Which is why we help folks adjust their setup so it’s easy to get the answers out of their systems.
Without doing a double reverse backflip with a twist.
If your data analysis is much harder than it needs to be, let’s talk.