Kronos WFC v6.1 introduced the concept of "Cascading Pay Codes." And actually the logic of cascading pay codes was introduced a few versions back as a part of the Leave module -- the idea had so many possibilities that Kronos incorporated it into the main module of WTK.
What is a cascading pay code?
It is a "dummy" pay code that can be put on a schedule or a timecard that does not make it to the totals. Instead, it will default in an assigned pay code that will drain an accrual balance (like vacation or PTO) before "cascading" to a different pay code to drain a different accrual balance.
Convoluted description, I know. What do you do with it? Well here are two neat ideas that I have talked about with fellow customers who are just starting to creative with them.
1. Use it to schedule PTO.OK, that may not sound like a very creative idea -- kind of what it was built for -- but let me tell you WHY it solves so many problems for you!
If you have earned/accrued time off based on hours worked, like so many healthcare systems do (think "PTO"), you have always struggled in the past on how to let employees schedule PTO out into the future when they haven't worked enough yet to build up their PTO balance. Of course you don't want their PTO balance to go negative, but you also don't want to keep them from scheduling next year's two week long Memorial Day vacation just because they only have 40 hours of PTO right now. So what to do?
In the past, you had two primary choices: Schedule a non-paying pay code that was not associated with their PTO balance as an indicator to your managers to put PTO on their timecard/schedule when the pay period with the vacation finally rolled around, assuming the employee had enough PTO. I like to call that method "double entry." Alternatively, you let them schedule PTO way out in the future, but had to turn off the system check that kept them going negative in their PTO bucket and hope your process checks & balances caught it before it got paid. The "hope & pray" method.
So now with a cascading pay code, you can schedule that cascading pay code out into the future and be confident that when the vacation week rolls around, the employee will either get PTO or not, whichever is appropriate, as the cascading pay code figures out which pay code to apply to the timecard.
2. Encourage exempt swiping policy.
Let's say that you, like many other Kronos customers, have a policy that requires your exempt employees to punch once a day to indicate that they worked that day. Odds are, you generate their daily pay with a shift guarantee or some other similar configuration. And, odds also are, your managers do lots of timecard edits to fix exempt timecards because your exempts don't always remember to punch.
So, one possible solution to encourage compliance is to use cascading pay codes. Here's how:
Create a new cascading pay code called "Exempt Hours" and put it on exempt employee's schedules with 8 hours a day, or whatever is appropriate for that employee. Configure the exempt pay rule such that it will pay from schedule and apply the pay code when the employee doesn't swipe. Configure the new cascading pay code to take hours out of the vacation/PTO bucket. Schedule the new cascading pay code for all exempts.
Now, if an exempt employee "forgets" to swipe, the Kronos system automatically assumes that it must be a vacation day and decrements the vacation balance appropriately. The employee still gets paid consistently (thus helping with DOL compliance for exempts) and they have a little extra motivation to remember to punch. Of course it can always be corrected and changed Regular time, but by defaulting the system to assume vacation, it helps make corrections truly be the exception!
So there are a couple of creative suggestions for using cascading pay codes. I'm sure there are more out there. Have a good one? Put in the comments below!
When you are building a schedule for an employee, it is often common that an employee will do multiple things during that period of time while they are working. For example (using hospital schedules), a nurse may spend the morning precepting another employee and the afternoon floating to another unit. Both of those are schedule transfers.
Or a nurse may work a 12-hour shift and then spend the next 12 hours on call. All of these are important to put on the schedule for coverage and tracking purposes.
But when you have a schedule-centric approach, where all the schedule data should also feed Timekeeper to drive payroll, you want to make sure those shifts and segments go in correctly to pay correctly as well as show coverage, etc. correctly.
Kronos Schedules module has shifts and shift segments (which are, intuitively, partial segments of a single shift). What's the best way to put in schedules? Always use separate shifts? Always use a single shift with multiple segments? A mix - and if so, how do you know which to use?
A good rule of thumb is to use a single shift with multiple shift segments when the employee could punch in once at the beginning of the shift and once out at the end.
Use a separate shift if there is some worked time that the employee does not record punches for.
So, in the examples above:
When an employee is precepting (i.e. work rule) for one period of time and then floating for the rest of the shift (i.e. job transfer), then PUT IT ALL IN A SINGLE SHIFT. Employee clocks in at the beginning of the day and out at the end of day and all the transfers are applied for both the schedule and the timecard.
When an employee is working a shift and then goes on call (which implies going home - not punched in), then PUT IT IN TWO SEPARATE SHIFTS. Employee clocks out and goes home and the schedule still shows coverage without trying to link the on call shift back to the first worked shift.
Of course you always want to test every scenario in your test environment to make sure it pays the way you expect, but thinking of it in terms of the simple rule of thumb will help your schedulers know when to use a single shift with multiple segments and when to use multiple shifts.
The introduction of schedules and the org map into Kronos Workforce Central Timekeeper provides an area of opportunity for your time transfers to be handle in a whole new way. (And you all read the previous blog entry on WHY you should do all transfers via the org map with schedules, especially in Kronos Healthcare, right?!)
But just because you want all transfers to happen in a certain way doesn't mean that they always turn out that way. In fact, when it comes to troubleshooting just exactly how employee XYZ ended up with 3.33 hours transferred into cost center 123 can be a challenge.
So here is a quick primer on WHICH TRANSFER WINS when you are looking at schedules and timecards. Let's start with some general guidelines:
- Data flows from the employee's default info to the schedules, to the timecard, and finally to totals.
- Labor Level transfers override Org Map transfers when made in the same location.
- The last transfer in is the one that applies to the totals.
- Percentage Allocation Rules override everything!
Simple enough, right?
Here's another way to look at it. If you have multiple entries below applying to an employee in a pay period, the LAST ONE ON THE LIST is the one that will be reflected in the totals:
- Employee default - Primary job
- Employee default - Home labor account
- Schedule transfer - Job (org map)
- Schedule transfer - Labor Level
- Timecard transfer - Job (org map)
- Timecard transfer - Labor Level
- Percentage Allocation Rule
So if you have your org map mapped to a particular labor level (like a cost center), your managers have multiple places that they can transfer the employee's time into that cost center to affect how those totals look. Troubleshooting that is YOUR PROBLEM, of course, but what YOU CAN DO is set a good process in place so every timecard you look at is not a mishmash of random transfers but one that falls into your standardized approach. Then when you do have to troubleshoot totals and figure out where that transfer came from, it is just an outlier and the exceptions are a little easier to get your hands around and find!
Everyone is familiar with labor levels in Kronos. You have up to seven that you can assign and use to make up your employee's "home labor account." The general practice is align your labor levels with your financial systems - GL and Payroll - so that your employee's time worked is charged appropriately. Of course no one has seven levels that they actually use for charging and transferring time, so the rest of the labor levels are used for reporting or some reason that no one remembers...! The only really important labor levels that get transferred around are Company/Facility, Cost Center/Department, Position, and sometimes a project code (although this one is mostly for reporting). Does this sound familiar?
A few years back, Kronos introduced the "Org Map," which has a lot of potential purposes. But we're talking about healthcare here, and for healthcare, there is no mystery to the purpose of the org map: It is for scheduling. Org locations and jobs are the heartbeat for staffing employees and a good org structure is critical for an effective scheduling implementation. Hopefully I'm not telling you anything new here!
But is that all the org map is good for? Driving your scheduling processes?
Absolutely NOT!
If you plan it right, your org map can be the key structure around which you interact with WFC, instead of labor levels. Yes, you read that right. "INSTEAD OF LABOR LEVELS." Should I say it again?
INSTEAD OF LABOR LEVELS!
You still need labor levels, of course. The org map does not REPLACE them. But it does eliminate the need for most-if-not-all of your labor level transfers. So think about all the things you hate about labor levels:
--How they are not
tied together (giving your managers the ability to accidentally transfer an employee's time into the "Labor & Delivery" cost center in your corporate office...).
--How they are awkward to pick and choose and search for the right ones when you are doing transfers.
--How your managers and employees are confused about the full labor account on reports and timecards because they only know what three of the entries mean.
And I'm sure you have others...
But then along comes the org map. It is structured like a tree, so leaves that are not appropriate for certain branches don't have to be attached. And users can browse to the location and job that they are looking for instead of doing multiple searches to find the right labor levels. And you are already using it for scheduling.
Here is the secret: You tie your org map to your labor levels for those levels that need transfers. Like the facility and the cost center. (But you don't tie it to the position.) So every time you do a schedule transfer to a new job in a different location, it automatically changes the labor levels too. Simple as that!
Of course there's a whole art form around how many levels deep to make your org structure and how to resolve positions and jobs and what to do with locations like "On Call," but that's a little more than the scope of this blog entry.
Suffice it to say, ORG MAPS CAN FREE YOU FROM LABOR LEVELS. And THAT is why the org map is beautiful thing.
As a review, let's briefly recall where our Quest has taken us so far. Remember that our Grail is WFM (workforce management) system harmony for healthcare organizations. We have dreamed what our system would like in a perfect world... and we know that it doesn't exist. But we also know that a Schedule-Centric approach to Kronos Workforce Central lets us start with staff schedules and utilize the features of the Schedule Planner to funnel data into a single point of entry.
Now, let's talk specific about what should go on into the Schedule Planner and what is still best kept elsewhere.
Things you should put on the schedule:
EVERYTHING YOU CAN!!
Not too much ambiguity here. You want the Schedule Planner to be the place where you spend most of your time, so you want to put in everything that the Genie will let you enter on it. That means transactions like:
- Scheduled shifts
- Pay code edits
- Work Rule transfers
- Job transfers
- Comments
Not only do you have the ability to put all of those data elements on the schedule directly, but you should design your processes to require entry there. There are downstream benefits that you want to realize from you implementation that are going to be a direct result of putting all the data in here first.
[SNEAK PEAK: If you are looking to see where "Labor Level transfers" are on the list, they're not there. Nor are they going to be on the list of items of to put elsewhere. Next week's blog entry is going to address Labor Levels and the Org Map. Prepare for controversy!]
So what goes elsewhere? The primary (and traditional) point of data entry left is the timecard. And by design in WFC, this is where punches end up and all punch-related data (like visual day divides and virtual punches) or data that is created as a result of punches (like exceptions and totals). So, with no other choice, the timecard is the place where you must manage employee punches (fixing missing punches, etc.) and resolving punch exceptions. You don't have a whole lot of choice here...
But that's okay because those are minor tasks compared to the amount of data that goes on the schedule. You will still spend most of your time on the schedule and just come on the timecard as needed or prompted by your exception Genies or your pay period signoff process.
The way WFC works and can be configured to take advantage of is that all the important data that you put on the schedule that affects totals-we're talking mostly transfers here-flow from the (1) schedule through the (2) timecard punches and end up the in the (3) totals. So by putting the work rules and job transfers on the schedule (and the pay codes too, for that matter), you are changing the location of your traditional timekeeper workload to the schedule. An effective design means you eliminate the duplicate data entry/tracking that often happens and you also eliminate inconsistencies between the schedules and the timecards (and totals).
And what about the Absence Management modules of Leave & Attendance? They still have their own screens built for you to interact with their core functionality, but designing the entire system to work together in harmony means that Leave & Attendance can be specifically built to support the schedule-centric approach. More on that later...
What is the most immediately noticeable feature of a harmonious implementation of Kronos WFC in healthcare?A single point of entry for employee transactional data.
In a perfect world, that single point of entry would have all the functionality of the entire WFC suite and all modules accessible at your fingertips, so you could see whatever you need to see and update whatever needs to be updated. Unfortunately, we don't live in a perfect world and Kronos does not have that cross-modular single point of entry developed (yet!).
Dreaming for a moment of a perfect world, wouldn't it be great if the system had a "screen" (or "view" or "grid" or "Genie" or whatever you want to call it) where you could put in all schedules and manage your staffing AND IN THE SAME PLACE put in all transfers and pay codes AND IN THE SAME PLACE manage punches and exceptions AND IN THE SAME PLACE see totals and accrual balances and attendance events and leave cases? That would be AWESOME!! But of course we all know that "screen" does not exist.
So, in lieu of perfection, we work with what we have. And what Kronos has that provides the most and best selection of functionality is the location schedules in the form of the Schedule Planner. This is the place that you should configure your system and design your business processes to perform most of your system interaction. (It's a "schedule-centric" configuration approach!) In the Schedule Planner, you can manage employee and location schedules, deal with staffing, put in all the transfers and pay codes, see some accruals, and even drive attendance events or see some of the output of the leave module. That's actually quite a bit of the "perfect world" we dreamed above - and probably a lot closer to perfect than you thought was possible.
Next week we are going to look at what you can and should put on the schedule specifically and what functions are best left elsewhere.