BRASSING OUT - Kronos Data Mining

Underground mines are required to have a TAG IN/OUT board that miners use to indicate when they go underground and when they leave the mine. Go into the mine, put your tag on the IN side, leave the mine and put your tag on the OUT side. This is known as “BRASSING IN” or “BRASSING OUT” since many mines continue to use brass tags with the miner's name stamped on it. The obvious purpose is to quickly and easily tell who is underground if there is a problem or at the end of the day. (If you think missing your carpool ride home is bad just imagine missing the last elevator out of the mine with no one checking for stragglers)

Most boards, like the one above, go one step further and even let you drill down and see what level of the mine each miner is working on. Don’t laugh—this level of ‘data mining’ (pun fully intended) is often more than many companies take advantage of even with their high-tech Kronos clocks and gate security systems. This renders the attendance-wary in many organizations blind to another kind of ‘brassing out’; managers adjusting time-clock punches for chronically late employees. Similar to the “buddy punch”, which is only about 1 day younger than time-clocks themselves, having the “Brass” (i.e. your manager) adjust time-clock entries is more common yet more difficult to track than you might imagine.

Kronos time-clocks and Timekeeper provide a good view of when someone actually punched in, what adjustments were made to the timecard and who, when and why they were done. The “why” is often left to a comment field and its validity rests basically in the trust you have in the manager.  “Long line at time-clock or Employee arrived and started work before punching in” sound reasonable on the face of it. Moreover, unless you actually go looking for these and counting them over time you won’t be able to spot trends easily nor would you have any other information to corroborate or dispute what is in Timekeeper. But what about the security/gate access system?

Although an entirely separate system from the time-clock/keeper system, an organization’s door access data can provide highly relevant commentary when pressed up against Kronos Punch and Adjustment data. Consider one of the reasons mentioned above for adjusting a subordinate’s timecard. Let’s say the employee punched in at 5:28am when they were supposed to be at work at 5am. The rounding rules move the entry to 5:30 but the supervisor moves it back to 5am and indicates that the employee had actually been at work on time.

Now go get the gate entry data for that employee and see that she actually swiped in at the main entrance at 5:15am and her work building at 5:20am. Now the Kronos punch seems a bit more truthful and the supervisor suspect. Total up the difference of all the suspect adjustments and you now have a quantitative amount you have been paying for someone not working—not to mention a clear employee problem with clear evidence to proceed with disciplinary action.

With a little thought and by considering the gate/timeclock layout and data available in your environment it is rather straightforward to create an exception based reporting system with some drill-down capability to support further investigative efforts. For example, if the reason for the rollback adjustment was the ever popular ‘long line at the timeclock’ justification code one could quickly pull up the volume of activity on that clock in the preceding 30 minutes to see if, in fact, it indicated a queue of people.

Several of our clients have asked us for such reporting capability.  While our people are quite adept at pulling the useful data out of the Kronos database we often need to work with someone from the security side to understand and access the gate data it a way that can be correlated. This obviously starts with time synchronization between the two systems but can also involve allowing for variations in campus geography, shift times (eg: crossing days), and what is considered ‘normal’ versus ‘suspect’ conditions.      

Once the criteria and data required is determined, those feeds (and only those feeds) from the security system are extracted for use by our developer. This was accomplished at our last client in one group meeting with the key departments weighing in and a few follow up calls to resolve the technical details. A week later the HR department had the much needed information to pursue their ongoing investigation in the form of a Crystal report that could be exported to Excel. It’s not that this is particularly difficult but, as most of our customers have shared, it takes significant knowledge of the Kronos data side whereas the security system side is relatively simple. With that in mind it is often faster and cheaper for one of our Kronos Reporting people to do the majority of the work rather than their in-house IT developers.     

That’s my blog for the day… time to brass out for lunch! (I will be back at exactly 1pm… really…you can ask my manager ;-P)