When it comes to defining a Change Control process one needs a way to get updated or added configuration into the production environment. So let's start by creating a process flow. Using SDM as our primary tool we’ll define the process using three non-production environments--Practice, Development, and Test.
Step 1 - Use the Practice environment (PRAC) to figure out your configuration changes.
Step 2 – Key the final configuration changes into the Development environment (DEV) and validate the interaction with other changes in the works.
Step 3 - Copy those changes to your Testing environment (TEST).
Step 4 - Perform your formal testing in TEST.
Step 5 - Copy your changes from DEV to your production environment (PROD).
Seems simple enough, right? Well, as the saying goes, "the devil is in the details." We suggest using Excel, Access, Sharepoint or an online tool such as DabbleDB to track what and how changes are going to be migrated. This document should include things like the item name, persons responsible (requestor and developer), where it needs to go, how it needs to be moved (SDM often but not always), when it can be moved and anything else appropriate.
Let's talk about some best practice concepts to follow and then flesh out these steps a little more. Of course there are exceptions to every rule, but these guidelines are going to be applicable most, if not all, of the time.
Best Practice #1 - SDM should only be used to copy from DEV to a target environment. There's really no point in copying data from somewhere else. Because in our scenario, DEV contains the master configuration and you don't want to copy something INTO DEV and potentially compromise your configuration. And, since DEV does have the master configuration, you are always going to want it to be the source of what gets distributed out. That way there's no confusion. Let me expand on this.
If we use SDM to copy pieces out of PRAC into DEV, you run a high risk of moving stuff over that didn’t need to be there. Plus the payroll manager may have lost track of all the tweaks that were done to prove out the pay practice during development.
Instead, by requiring the rekeying into DEV, you create a process where only the exact changes/additions that are needed for the pay practice are put into DEV and you’ve left all the unnecessary pieces of practicing where they don’t hurt anything, in PRAC. You also end up with an exact list of things that were touched in DEV that you can move over into TEST for testing and eventually into PROD.
Best Practice #2 - Don't delete configuration elements from DEV. This is a good rule just in general for Kronos configurations. Just because you no longer use a work rule doesn't mean it is a good idea to remove it from your configuration. And actually, you'll have a hard time accomplishing that because Kronos doesn't want to let you remove it if it has ever been used, to protect your historical integrity. Instead, just rename it with some indicator that lets you know the element is no longer in use. Something that starts with "zzz" is convenient, because that ensures the Kronos screens that sort alphabetically will always have those elements at the bottom and out of the way. The exception here is if you have elements that you created but never used.
Best Practice #3 - Be very careful about changing how existing elements work. This is a good idea just in general with the WFC system. The reason is that if you update that combined pay code or break rule, it will interfere with your historical integrity. You could attempt to audit employee data from the previous year and not be able to prove why totals were calculated the way they were, since those same punches calculate different totals today with today's rules. The best solution then becomes to rename the element and create a new element with the same name as the original one so that you keep the old one for the historical integrity. But this becomes especially tricky to handle with SDM. Which leads us to the new Best Practice....
Best Practice #4 - If you ever rename an element in DEV, you must rename that element in your target environment manually before doing any SDM copy. The reason is this: When you rename an element manually in WFC, it updates all of the pay configuration elements that reference that element because it uses the element's internal ID number as the key. But when you copy via SDM, it only copies using the element name as the key. So if you have a pay code named "Evening Differential" and this pay code is referenced in a combined pay code you use for reporting, when you rename the pay code to be "zzz-Evening Differential retired on Jan 1 2009", you would see this new name in the combined pay code as well. But, if you didn't do that and you just renamed the pay code and then created a new one with the same name and copied both of them over to your target environment with SDM, both pay codes would be there. Your target's combined pay code would only reference the new pay code and lose all association with the old pay code. When you consider that this also happens to your pay code distributions and your data access profiles, it can begin to get messy very quickly.
Best Practice #5 - Only implement a strict process for configuration elements that can increase the risk to your production environment. There is such a thing as too much change control! Some of the setup elements that SDM lets you move are really low risk elements as updates to them don't cause employees to be retotalized nor do they affect the integrity of the data or the pay configuration Examples of this are comments and scheduling shift templates. There are other elements that might be important, depending on how they are used or treated. Examples of elements in this category are FAPs and Genie-related configuration elements. For these elements, it can sometimes be more efficient to not subject them to a strict Change Control process. You need to determine what are the risk items that you are most concerned about causing risk to your production environment. A good rule of thumb is: If a element causes an employee to be retotalized (all accruals and pay policy elements), then it should be included. Otherwise, it is up for discussion.
Next we'll expand on the five step process to managing change in Kronos Workforce Central using SDM.
--------------------------------
Thanks again to Chris Flanders and others for contributing to this series
Comments