We've written a few articles over the past year about Change Management and Kronos Workforce Record Manager. I've just posted a white paper and accomanying Slideshare presentation about things to think about during setup and how to troubleshoot issues that commonly arise. I hope this helps some of you out there who are pulling your hair out!
If you choose to wait a year or so before starting to use Workforce Record Manager, 
there
will be a significant backlog of data that has not been copied to the
archive database. To attack this backlog, it is recommended that you
first understand how much data you have over various time periods. A
good approximation of this can be obtained by going to your database's
query tool and running some date relative queries of a key table, the
TIMESHEETITEM table. For example, a query like:
select count(*) from TIMESHEETITEM where EVENTDTM between '1/1/2009' and '1/31/2009'
This
query identifies the number of rows in the table for the month of
January 2009. Run comparable queries over different date ranges and you
will have a reasonable approximation of the density of data over
different time periods.
After you run a copy or two and have
actual processing times, you will be in a position to extrapolate the
performance of subsequent copies and choose date ranges appropriate to
your needs. When you run your first copy, plan on starting small, for
example, copy the data for a single pay period, before trying to copy
larger amounts of data.
Note: You will need
to populate the copy start date value on the Copy Screen for the
initial copy in the same manner as previously described when using
Workforce Record Manager right away.
After copying the
initial pay period, you can experiment with larger date ranges based on
the performance of the initial copy and the TIMESHEETITEM table row
counts you have collected.
Purges should be run in a manner
similar to copies to remove any data for which access is unlikely to be
required. Remember, if you have waited only about a year before
starting to use Workforce Record Manager, there may not be any
significant backlog of data to be purged. After you have dealt with the
backlog of data that has not been copied or purged, you can proceed
with a regular schedule of copies and purges that meets your needs, for
example, doing a copy and purge each pay period. Some other
considerations to keep in mind:
- Data within the copy/purge
time frames must be payroll locked before it can be acted upon by
Workforce Record Manager. It is best to payroll lock data every time
payroll is issued.
- In addition to the routine periodic backups
done of the production database, make sure to backup the archive
database. It is best to do this shortly after data has been copied to
the archive database.
Best Practice Alert: Run Kronos Workforce Record Manager (WRM) on its own application server, not on the production application server. This minimizes the impact WRM has on the performance of the production system. It also allows maintenance of the archive database to be performed outside of the Kronos production system's tight maintenance window.
Keep in mind that after years of data have been archived, the archive database will contain much more data than is stored within the production database, therefore, database maintenance activities on the archive database will take longer than such activities on the production database. Run Workforce Record Manager in your system's maintenance window or, if the maintenance window is too small, during off-peak hours.
Note: Kronos Workforce Record Manager allows pauses and resumes to be scheduled so you can limit its activities to a prescribed timeframe. Pauses and resumes are not instantaneous, so you should allow a window of several minutes (10-15 minutes is a good rule of thumb) to allow in-process work units to complete.
If you choose to start using WRM right away:
- After each pay period, payroll lock the pay period and use the WRM copy option to copy the pay period's data from the production database to the archive database. Note: You will need to populate the copy start date value on the Copy Screen for the initial copy. To ensure all ancillary data gets copied, first go to the Archive Screen or the Purge Screen to see the prepopulated start date value. This value is determined by Workforce Record Manager by examining the dates of key records (usually accrual transactions) within your Kronos Workforce Central database. Populate the copy start date value with this same value.
- At the end of a year (or whatever timeframe your company chooses to keep within the production database), use Workforce Record Manager to purge the data from the oldest pay period within the production database.
Under the best scenario, you might start using Workforce Record Manager (WRM) right away to copy locked payroll data to the archive database. And each time payroll is processed another pay period would be copied to the archive. No data is removed from the production database until much later on. The goal is to keep Kronos Workforce Central product data your users are likely to need to access within the production database. User access to the archive database should be limited and infrequent.
Some people
call this a
"Best Practice"
The key users of Kronos Workforce Central products are managers and the timeframe of data they need to access typically goes back a year. Of course, you might have different requirements at your company. So as a general rule, you can probably wait about a year before starting to purge data from the production database using Record Manager. But what if your workload prevents you from starting to use WRM right away? How long can you afford to wait?
One approach is to wait until the amount of time it takes to do database maintenance exceeds the database maintenance time window. Keep in mind, customers typically rollout Kronos Workforce Central products incrementally. That is, they start with a few sites and eventually rollout everything to the entire enterprise. As such, there is far less data initially so database maintenance is probably not that time consuming. The amount of time it takes to do the maintenance often becomes a concern when Workforce Central products get used by most or the entire enterprise. And then, the use of Workforce Record Manager is seen itself as a database maintenance activity which imposes further pressure on the database maintenance time window.
Unfortunately, some customers, particularly those with small database maintenance windows, have waited years before archiving data and have found that WRM has to run around the clock for months at a time to copy data from the production to the archive database and then purge the copied data from the production database. In particular, when you start to find key database tables, for example, the PUNCHEVENT, TIMESHEETITEM, and WFCTOTAL tables, having tens of millions of rows, it is definitely time to start using Workforce Record Manager.
Nonetheless, it is recommended that you do not wait that long. If you cannot start using Kronos Workforce Record Manager right away, it is recommended that you do start when you have reached the point where your production database contains all the Workforce Central data your managers are likely to need to access, typically about a year of data.
So you have bought a license for the Workforce Record Manager software. You know Kronos Record Manager will archive the data created when using the various Workforce Central products, for example, Workforce Timekeeper and Workforce Scheduler, but why, when, and how should it be used? This will be the topic of several blog entries over the next week or so.
First, the WHY of Record Manager
Often Kronos customers believe that copying data from their production database to an archive database and purging the copied data from their production 
database using Workforce Record Manager will result in better performance of the Workforce Central products they use frequently in the production system. In reality, the use of Workforce Record Manager does not improve the performance of these Kronos products. Instead it reduces the amount of time it takes to maintain the Workforce Central production database. So, it will take less time to perform such database maintenance activities as backups, rebuilding of table indexes, and the updating of table statistics on the production database.This is good stuff and needed by many organizations.
So with those best practice concepts under our belt, let's get into the details of our 5 step process.
Step 1 - Use PRAC to figure out your configuration changes
- Update your PRAC environment with a current copy of PROD, so you know your manipulating the right configuration.
- Create and update all the elements you need to get a successful test within PRAC for your desired configuration change or new configuration.
- Once you have it working, go through and identify every configuration change you made that was critical to the final result.
Ignore all of your other practicing!
Step 2 - Put all of your final configuration changes in the DEV
- Keep careful track of every element that you create, rename or update in your spreadsheet, database or SharePoint. Do not create unnecessary elements.
- Perform a simple test in DEV to confirm that what you have created works as you expected.
- Update any other configuration items that you intend to move with SDM (like data access profiles).
- Make note of any configuration items that you changed which SDM cannot move (like global hyperfinds).
Step 3 - Copy those changes to your TEST
- First rename every element in TEST that you renamed in DEV.
- If necessary, delete any elements in TEST that you deleted in DEV.
- Use SDM to select and copy the individual configuration items from DEV into TEST. First the pay configuration items, and then anything else. It is best to copy just one grouping at a time.
- Make any needed manual updates from your list from step 2.4.
Everything you do here should be carefully documented. Use screen shots. This process needs to be repeatable in PROD later.
Step 4 - Perform your formal testing in TEST
Testing is out of the scope of this series but at a minimum, you must confirm every item that was changed in Step 3.
Step 5 - Copy your changes from DEV to PROD (This should be exactly what you did in Step 3.)
- First rename every element in PROD that you renamed in DEV.
- If necessary, delete any elements in PROD that you deleted in DEV.
- Use SDM to select and copy the individual configuration items from DEV into PROD. First the pay configuration items, and then anything else. It is best to copy just one grouping at a time.
- Make any manual updates that you needed to make from your list from step 2.4.
And you're done! Now PROD has exactly the same configuration that DEV has and it is exactly the same configuration that you tested in TEST and all of your practice work and mistakes are safely isolated in PRAC. Risk has been minimized and you have documentation of what you changed and when it was changed!
Hopefully you'll find a process similar to this that works to improve the limited, native change control abilities in WFC. Let's face it. All we can do is wrap good processes around it.
-------------------------------
As we close out this series I want to again thank all the folk I've spoken with and who've written articles and bits to make this so successful. Change Management has been so popular that next week Jeff Hill and I will start a discussion on ensuring accurate standards are kept in CM. If there is something else you'd like discussed in this blog feel free to comment here or email me directly. Thanks!
Over the last few months we've spent a lot of blog time talking about the how, why and what to move configuration data from one environment to another in Kronos WFC. There needs to be more conversation about the WHEN to do it.
I had a meet
ing last week about Change Control for Kronos. They have a large number of configuration and other changes that are ready to be promoted to Prod sometime soon. One of the tough parts of the promotion decision is when to move the data. It's obvious there needs to be a maintenance window, but what if the changes won't propogate in that time. We might need to stage the updates.
Sometimes changes can be moved any time. Other changes need to be promoted together and some are dependent on other changes being there ahead of them. Some changes can take days to promote and others minutes. In the Change Promotion document you built in Excel (ok), Google Docs or DabbleDB (better) or Sharepoint, there should be a column for dependencies and one for when in the process it needs to be moved. And perhaps one showing when it CAN be moved.
Scheduling some changes weeks before a major migration or update can be a real help, saving downtime and simplifying the overall effort; but one must be certain that those changes don't affect anything else. I always suggest that this Promotion document be tested in the move from DEV to TEST and then to QA if you have it. That way any kinks in your expectations of the affect the change will have can be verified.
How do you manage the WHEN of Change?
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
So what does SDM do? What doesn't it do? I think it's important to understand this at a high level before we build our best practice for the Kronos WFC Change Control processes.
What SDM Does:
- Copies all elements related to pay configuration, accrual configuration, and access profiles, as well as other configuration elements.
- Copies a new individual element from a source environment to a target environment.
- Updates an existing individual element from a source environment to a target environment, overwriting the target environment's element, using the element name from the source environment to identify the target element in the target environment.
- Copies or updates multiple elements in order by the lowest common denominator elements first. In other words, if you have a new pay code and a new combined pay code for SDM to copy to a new environment, it will automatically copy the pay code first, just in case the combined pay code needs that pay code to exist. In other words, SDM knows the prerequisite order of the WFC configurations.
What SDM Does NOT Do:
- Delete any elements. If you have deleted an element out of your development environment, SDM does give you a way to delete the same element in a target environment.
- Rename elements. If you rename an element in your development environment and use SDM to copy it to a target environment, SDM will see that element as a new element that did not exist and copy it over accordingly. You still have the old element existing in your target environment because SDM doesn't handle renaming. THIS IS REALLY IMPORTANT as it's something that's done all the time and NOT TRACKED.
- Copy elements that you did not select, even if they are prerequisites for what you did select to copy. For example, if you created a new work rule that uses a new pay code distribution, but you only select the work rule to copy, it will fail because it will not find the pay code distribution it needed in the target environment - you have to specifically tell SDM to copy both the work rule and the PCD.
- Copy employee data. This is a tool for configuration elements ONLY.
- Copy labor level elements or org map elements (as of v6.1).
- Copy labor level sets or org sets (as of v6.1).
- Copy anything related to Process Manager or hyperfinds or reports. See your version's Record Manager User Guide for a listing of what specific elements that you think may be configuration that SDM does or does not support.
The most important thing to understand about what SDM does is that it copies new elements or updates existing elements only -- it does not ever delete anything. And it works off of the element name to determine if the target environment has the item already (and just needs to be updated) or if it is a new item.
As you can see, it is still very important for the developer to record change manually thoughout the process. You cannot trust any tool to do it for you. The benefit of SDM is still great as you can use it as a tool to help migrate part of the development though the environments.
Next article we'll start to describe the Best Practices we can implement for Change Management with Kronos WFC products.
---------------
Thanks again to Chris Flanders and others for contributing to this series