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
Over the past couple of months we've been discussing Change Management and Kronos Workforce Central Environments. We don't really have good tools for Change Management for these projects, but when it comes to managing Environments, we're better off. We're going to cover these tools now so that you can effectively manage those environments and be confident that your (manual) Change Control processes protect your system from mitigatable risk. Here we will describe, with practical insights, the functionality of the Setup Data Manager tool (which is a part ofWFC's Record Manager) and how to create Change Control process that allow you take advantage of the features of SDM while minimizing the pitfalls.
Setup Data Manager (SDM) is that it is a tool which allows you select an individual configuration element (e.g. a pay code) and copy that element over to a different environment. It does this by submitting an XML transaction to the application server, exactly the same as if you were to log into your target system and key the element in from scratch. This functionality is completely different than Record Manager's Bulk Copy function which one can utilize for archiving dataand moving "rules" from one environment to another. Those Bulk Copy functions perform their tasks at a database level and take an "all ornothing" approach to moving stuff around. SDM lets you be more specific in what you move and simulates what would happen if you were to have done it manually in the application. This is an important distinction to understand.
Because SDM allows you to pick and choose individual configuration elements, it is an excellent tool for enabling individual configuration change controls. When you have a development environment with yourmaster configuration in it, you can pick and choose pieces of that master configuration to move other environments for testing or for promotion into production. SDM takes out the uncertainty that results when you have to rekey your configuration into your production environment after testing, eliminating any inadvertent manual mistakes that you could make while rekeying.
Next article we'll look at more detail about what SDM does.
---------------
Thanks again to Chris Flanders and others for contributing to this series
This is a follow-up on the 6/2 article "Understanding Kronos Environments."
There are different strategies to creating and maintaining the environments we've been discussing (SAND, DEV, TEST, PROD) and in determining just how many there should be. Most companies have constraints in budget and resources and the strategy that is best for you is going to be a function of those constraints. I beleive that the concepts for these environments still apply, no matter what your strategy is and what constraints you work around. For now I'll leave it to you to determine just how many. Let's look at some other environments that can be very useful.
How about a TRAINing environment?
How about a MODELing environment? This is a copy of PROD with all signoffs removed for a period. One ‘models’ change pay configuration elements such as rounding. This allows one to see what employee time records would have looked like had you had a different pay policy in place. As you might imagine it can be very useful for HR to determine if a change like switching from rounding to minute-to-minute pay will result in cost savings or additional costs.
What about QA? I've seen setups where there are multiple QA environments to segregate the work that valuable department performs.
I'd love to hear about your experiences and other enviroment ideas. Please comment.
Change IS inevitable! So let’s be prepared.
Environment Management reflects the Change Management doctrine and the implementation of it typically looks something like this picture. Of course smaller companies might just have TEST and PROD, but that’s a minimum.
Everyone experiences the need for change in their Production system. Whether that change is tweaking pay rule configuration or adding pay codes or even implementing service packs, if you have a WFC system, there will be a need for change on a periodic basis. Because of those change requirements, there are things you can do and a structure you can create to give yourself confidence that the changes will not cause bad things to happen in to your production systems. Kronos provides Record Manager and the tool Setup Data Manager (SDM) to help you administer your environments, but to make the best use of those tools, you must have the right environments in place.
In order to provide a decent explanation here, we will follow a process through each of the environments described above to see what their role is and why it is critical. In a later article we might present an alternative setup just for fun.
Let's start with a common scenario: The HR department has just dreamed up a new pay practice and they want you to implement it in your Production Kronos environment.
SANDBOX Environment(s)
A common best practice on agile teams is to ensure that developers have their own "sandboxes" to work in. A sandbox is basically a technical environment whose scope is well defined and respected. The primary advantage of sandboxes is that they help to reduce the risk of technical errors adversely affecting a larger group of people than is absolutely necessary at the time.
So, the purpose of the Sandbox is to provide a Kronos playground to "practice" configuration and development. The Sandbox database is a copy of Production and often times it’s stripped of sensitive data. There isn’t a need for tight controls around what is being created or changed in this environment -- that is not the purpose. Use it to figure out what needs to be done at the individual or small team level. Some companies employ multiple Sandboxes for different teams and those get merged into DEV for integration testing.
For our scenario, when HR communicates that they want a new pay practice implemented, the developer would work here to figure how to configure everything that it will take to implement the new policy. And since it is just a playground, you can try different things, different approaches to make it work, until you are satisfied that you know exactly how you want to go about implementing the new pay practice. If you break it and can’t fix it, just refresh the database.
DEVELOPMENT Environment
Sometimes called ‘Project Integration’, the purpose of the Development environment is different depending on if you have Sandboxes. Without them, all development is done there and promoted to TEST for all testing and training. If you have a Sandbox, DEV is primarily used to integrate development from the other sources and make sure those changes don’t affect other parts of the system. Some might perform all simple changes directly to DEV and create Sandboxes for bigger or more intrusive projects.
Doing the integration testing here is great. We can’t really trust the sandbox to reflect the Production system after all those kids have messed up the Sandbox. So refresh DEV and promote your finished changes from the Sandbox to validate your work.
TEST Environment
This final non Production environment is where one performs formal testing and it’s often controlled by a separate TEST/QA group. I’ve seen this one called Pre-PROD, TEST and STAGE. Its purpose is to provide an environment that simulates PROD as closely as possible.
Understanding how it fits in with the other environments is what’s important here. In SAND, you have played with the configuration until you got it working the way you wanted. Then, you put that configuration in DEV and confirmed that it works the way you expected. TEST is used for two primary purposes. Testing that you can successfully migrate the changes, run though the full test scenarios required by your Change Control Process, and if these are the only environments you have it’ll be used for QA & UAT.
The final scenario step, of course, is to use SDM and move your configuration from DEV or TEST depending on your Change Control process, into PROD. Since you are just moving the configuration and not recreating it, you can control the timing of the move such that it has the least amount of impact on PROD and its users.
So could you have gotten your new pay practice into Production without each of these environments? Of course you could have. But not without more risk
-----------------
Thanks to Chris Flanders and many others for contributing to this and other articles in the series.