Timekeeping is not all that sexy a subject, and within timekeeping, the subject of interfaces does not give anyone an adrenaline rush. So bear with me as I give a few salient thoughts which will benefit anyone who is considering the purchase of a timekeeping system, or has just recently purchased one, or who has one and realizes that data flow between systems is either nonexistent or clunky. Come to think of it, that should cover just about everyone. So please read on.
Data Flow 101 – System of Record
When designing interfaces, it’s all about the system of record. Data should be entered once and only once, into its system of record. Take for example, employee name. The system of record for a name is the HR system. It should be entered there and it should flow automatically to ALL other systems that need it. JobCode? Salary? Those also go into the HR system. Work schedule? That probably belongs in timekeeping. Why does HR care if a person is moving their start and end times back one hour? Specific hours worked on a day? Definitely timekeeping. Accrual balance? Depends on where it’s computed. Wherever it’s computed, that’s the system of record, and the balance should flow to other systems as needed to keep it as current as possible. You get the picture – it’s all about system of record. Don’t you dare ever ask anyone to enter information into a system that is not the system of record for that information. If ANY double data entry is occurring, you have messed up.
Be Smart – Infer what you can
Your HR system already contains all of the information that is needed to create basic Kronos data. Use it. Take, for example, the Timekeeper payrule. Exempt people are, well, exempt, and your HR knows that. You probably have a payrule called Exempt. Don’t even think about asking your user to tell you that the exempt employee has an exempt payrule. You can figure that out yourself. And if an exempt employee in Nevada has a different holiday schedule (therefore a different payrule) than an exempt employee in California, then look at the employee’s state, and if it’s Nevada, assign the Exempt Nevada payrule. The same principle applies to all other data. You know who is a manager – if someone reports to you, you’re a manager, so you need a manager license. Don’t make your users tell you that the manager is a manager. Figure it out yourself using data in the HR system. I have written several Kronos inbound demographic interfaces, and I’ve never had to ask the HR people to tell me a person’s payrule... or their licenses, or any profile, for that matter. It can always be inferred from HR data.
Bring it ALL
Don’t try to be clever and do a changes-only demographic interface. Why would you? Just pass it all, every time. It’s much simpler that way. You paid a ton of money for Kronos Workforce Central, and a ton of money for Oracle or SQL Server, and a ton of money for your servers. Use them! Let them do the work, not your programmers. Who cares if worker type has changed since the last time you transmitted? Just pass it – and absorb the additional 3 milliseconds that it takes for the system to overwrite data with the same data, at 3:00AM when your interface probably runs. Processors are fast, and so are databases. Use them. And if you add a new data element, just add it – you don’t have to worry about adding it to a shadow table, then adding logic to see if it has changed or not since you last ran.
Final Thoughts
Be amazing. Amaze your users with how clever your interface is. Surprise them, in a pleasant way, when correct data just somehow gets to Kronos. Keep it simple, bring in everything every time, infer what you can, clearly identify the system of record for your information, and you will have an elegant and efficient interface environment that makes you look smart…because you are. Do you keep it simple?
Free Whitepaper: How should one design and build Kronos Interfaces?
Need to know when to use Connect and when to use SQL? Download this free white paper to learn best practices.
Comments