Upgrading complicated software, such as Kronos and PeopleSoft can be a challenge at best. Typically, this process takes up to six months with many hours of testing, design and development. There are several key elements that every organization needs in order to effectively maintain change control: standardization of customizations, updated documention, standardized testing requirements. Maintaining these requirements helps improve the quality of an upgrade and improved SOX and SAS-70 requirements.
The primary issue with change control is keeping track of customizations vs. delivered code. It is not uncommon for clients of large scale ERP solutions to make changes or customizations to support the uniqueness of their organizations. 
There are several approaches to keep track of the customization without the use of speciaized software. The first approach is to develop a unique naming standard for custom vs. delivered code, for example, prefixing a unique client identifier with the name of the delivered program. One example is the delivered program PROG01, customized to C_PROG01. The benefit to this approach is during the upgrade process, the program is easily identified as a delivered program that was customized. Custom programs, written from scratch to support a client need would have a unique identifier associated with them, such as PAYPROG01 - a totally custom payroll program. Online objects would have similar constraints associated with them. For example, field names such as C_FIELD_NAME would be identified as a totally custom data object, easily identifiable as a custom object. Records, pages, components and other objects would use the same approach to maintain their integrity.
Once the custom changes are created it becomes imperative to store them separate from non-customized objects. Creating custom object libraries is important to totally keep client written objects separate. This will facilitate the complex upgrade process by total segregation of source, easily identifying the modules that need changed and allowing developers to focus on business critical needs. Customizations can be easily tracked and modified and enhanced where needed. Delivered code is protected during the development process.
The final benefit of using this approach is to focus on a key component of an upgrade - testing. The overall of mantra of an upgrade is to have minimal impact to the end-user, except where new software needs dictate. 
Therefore, by segregating source code from delivered to custom allows the testing team to focus on business critical objectives. Custom objects can be easily isolated for a test plan and regression and impact testing can be much more streamlined with objects separated. The overall mantra should be test, test and retest. With the overall impact to focus on testing, a much better product will be realized.
Finally, IT governance has been a challenge in the development arena. Sign-offs, proof of testing and proof of user acceptance are critical for auditors. By effectively controlling the customizations through simple naming standards, it becomes easier for auditors to verify what changes need to be reviewed for Sarbanes-Oxley and SAS-70 requirements. Segregating the objects allows the audit team to identify customizations, verify the test plan and focus on implementing the processes more effectively.
In conclusion, change control is a concept that needs to be practiced to support any upgrade process. With the complicated number of objects typically associated with large scale ERP solutions, by using an effective naming standard, the testing and development effort can be reduced to business critical processes.
------------------------------------
Jeff Hill PMP, CPP is our newest guest blogger. He's a Senior Consultant for a large PeopleSoft consulting firm responsible for project management and functional implementation of large-scale HRMS & Payroll solutions. He has spent 20 years working with both ERP and MRP solutions for manufacturing, retail and defense industries. IOW, he's a serious PeopleSoft, Payroll, HR guy about whom you can find more on his LinkedIn profile.
We believe...
-
In serious team engagement, throughout the project
- In applying the CANI theory of continuous
improvement to our Best Practices
- In preparing the organization for the CHANGE that is to come
-
In doing
the right thing, every time
So many consulting vendors say "we have a
methodology", "we do this all the time", "we'll hit the ground running", "it's eeeeeeeasy", "We'll
throw a lot of fantastic, experienced people at it and MAKE it happen for you.
Trust me."
Customers deserve a more thoughtful approach
If we could always use Kronos or always use Stromberg, or always use
Workforce AND always pick the right path without fully understanding our goals,
risks and opportunities...
If we could always simply ‘implement' the software without realizing
its role in the achievement of the objective...
But it doesn't work that way does it? The approach we
suggest... One we're working hard at continuously improving... One we're working to
document on this web site...is our client engagement philosophy.
We Listen, We Engage, We Do What We Say
This is a continuation of the Improvizations vision (earlier
blog link). There will be a series of blog articles and updates to the site
over the next few months that explain the thought behind this phrase. Everything
starts and stops with the management of CHANGE. It's the make or break, not
tool, but attitude/approach to a project.
--We LISTEN to everyone
and ask a lot of questions. Add this data to what we already know and we
quickly create a high level outline of what you might call a
"Roadmap" for the project. Some people call this Discovery. It's much
more than that. We kick off the project with the through-line items that are often
simply a project task to check off; Change
Management, Strategic Project Alignment, Training Zen, Risk Avoidance and
Mitigation planning. All start in the beginning and never are put to the
side. Think of a big block map of the country you grew up in. You could use it to get from here to there,
but it might take a while and you'd likely make many expensive mistakes along
the way.
--We ENGAGE not just the
small team who've been working on the project since it was just a thought, but
a wide variety of employees, consultants and vendors. We like BIG TEAMS. We expand
the requirements detail, capture problems and solutions from the field, work
with Vendors and specialty consultants to build a serious roadmap with budgets
and ROI, detailed Change Management and Risk Mitigation Plans, and flesh out
the overall project Plan. To continue the Roadmap analogy, this is that AAA "Triptik"
with some major construction highlighted to avoid and suggested paths to the destination.
With this level of detail we can add in the creation of fit/gaps, vendor
selection, training requirements and more. And depending on the expected timeline,
even create interim solutions.
"And this is where most people stop the process and begin the implementation..."
We disagree with that approach.
--How (what) do we DELIVER?
A unique task we perform is "Strategic Reconciliation"... looking at
all the related opportunities for integration and the creation of other
projects, necessary projects! OR perhaps the termination of some we find that
are now unnecessary. What's so great about this? It's knowledge of the
landscape, the traffic so to speak, and shows the best way to get from HERE to
THERE. Consider this the Web 2.0 version of the Google Maps on your personal
Garmin with options showing the fastest and/or best way to your destination with traffic
and weather avoidance showing up in real time. It of course also shows what
sights to see near the path. Consider these unforeseen opportunities. This plan
will re-route you the best way from wherever you end up for whatever reason.
We welcome you to the Improvizations way. Enjoy the trip.
Jeff Millard has written an introductory white paper on
this subject. Watch this blog over the next few weeks for more.
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!
Welcome Stromberg Time and Attendance users to the Kronos Workforce Central world. It's great to see a new group come to play in our sandbox! Don't worry, we don't bite. As a matter of fact, we have pretty much fun, and I think so will you. As you learn to navigate our little workforce management world, feel free to ask questions, enjoy our support group at Yahoo, learn about some of the cool things you'll be able to accomplish when you end up with Workforce Central.
- Better labor tracking (7 labor levels instead of only 3)
- More configuration options such as pretty darn good handling of shift differentials
- A serious scheduling tool
- ... we'll talk about more later
Are you going to Kronosworks? Join in on the "Pick Our Brains" contest to find out more about what change you are about to enjoy. Check out some of the good stuff Improvizations has to offer too, like the Upgrade Studio. We're going to make it easy for you to switch to Kronos Timekeeper. Not implemented yet? We can help you navigate the challenges that are a software implementation with the best practice Upgrade Studio processes.
There has been a lot of chatter this year about so called 'Best Practices.' I must admit that I've been part of this; trying to advocate proven practices 
rather than the typical complex ones floating around IT. We suggest best practices for Kronos Upgrades, Training, Change Management, Module Config and almost everything else. However, one must not blindly follow any of them! Keep this in mind:
- They are important, but not the final word.
- They are guidelines that change over time.
- They should be proven, to your organization, as successful, not simply written up by someone who you think probably 'knows.'
- They should NOT be followed. Yikes, management doesn't want to hear that. But I mean it. They MUST not be followed. They are meant to be integrated with the knowledge of the PEOPLE in the organization who know how the applied practices will affect the project and the organization. Each working group has their own view, culture and needs that differentiate them from the ‘best practice' currently out there. Apply, don't copy blindly.
Sometimes Best Practices excuse management and the AC's and TC's of really understanding 
what needs to be done. "But I did what I was told! It's the vendors fault!"
If we just implement the "best practice," we'll perceived as doing the right thing. However, My experience is that you have to create and manage your own proven processes for the work at hand. This doesn't mean we should ignore them though! They are guidelines which feed and nurture the process which are not simply to be checked off.
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.