The other day I was in a meeting with the usual suspects from HR, Finance, Manufacturing & IT. We were discussing going to a new Payroll vendor (and thus their embedded timekeeping system) from the existing in-house system and payroll company. Our prime reason for meeting was discussing the critical interface to cost accounting. It was right after I finished my second doughnut that I reached my limit.
Not of doughnuts (like there’s a limit?!?) but on how many times the vendor rep over used the term ‘Payroll’s Data’ to describe what we were capturing in the timekeeping system. Granted she was from the payroll company, so that is generally her purview, but this casting of diverse information with a single purpose is a common problem in many companies we go into.
If the only purpose for keeping track of time (yes this is a Kronos blog, but this other stuff matters too!) were to pay people we would still be calling it ‘The Payroll System’. And, in most companies, it would still be 1890 and we would also be anxiously awaiting the stagecoach with the strong box of cash so we could collect our pay, ride into town and have our fill at Maginty’s Saloon & Doughnut Emporium. I'm guessing Kronos Timekeeper wasn't available back then?
As I’m sure you are all well aware, ‘TimeCards’ and ‘TimeKeeping Systems’ are used to collect information for a diverse set of needs in companies. To meet these needs, we slice and dice and collate time worked and time off and either put them into virtual buckets directly—as on a timecard: 14 hours worked on April 1st on the Boston Cream line, or via rules and pay codes: 12 hours of regular time plus 2 hours of overtime worked April 1st on the Boston Cream line. Generally speaking, the granularity of information needed to put the right amount of money in the employee’s pocket each pay period is less than the more intricate ‘siloing’ that happens in a very granular project and/or cost accounting structure fed by the same timekeeping system. Obviously it would be silly to have a different time collection system for each of the different purposes of Pay, Labor and Costing but sometimes we effectively do this by not crawling out of our silos often or soon enough.
“It is company data” I said to the Payroll vendor rep after I had wiped the powdered sugar from my tie.
“Of course it is your company’s data, I meant the data used to do your company’s payroll” the rep said.
“And costing”, I said.
“Costing?” she said
“Yep… we need to feed the cost accounting system from this data as well’, I said. The cost manager just nodded as his mouth was full of an Apple Fritter (highest density pastry per cost unit by the way)
“ How are we going to do that?” the rep asked.
“That’s what we are all here to find out” I said. “So you see why I don’t want to cast anything too strongly for any single purpose until we make sure all the consumers of this data are fed.”
“Ok” she said as she grabbed the last ‘old fashioned’.
Figures. I thought to myself.
I’ve found when putting in a new major component in the HR/PR/WFM world it is best to get everyone out of their respective Payroll, Labor, Project, Costing, etc silos to revisit who needs what information, when, and how. You would assume the liveliest discussions come about because of the impending changes to the system—people making sure they keep their silo properly filled with the data they need. Much more exciting, however, are the discussions initiated to figure out what data they are actually using now.
This happens all the time when an interface needs to be re-written. For example, when we go to one of the consumers of the existing feeds they might indicate they need extended dollars coming in. The next question is, of course, “based on what?”
“Well… Hours x Rate” I suppose.
“Straight time, overtime, Pay Rate, Burden Rate, Bill Rate?” and “Where do we get the rate and who maintains them?”
“Those are all fantastic questions” most people will say. “Let us get back to you on that”.
Which, of course, leaves me time for one more doughnut.
Comments