The Kronos & PeopleSoft & every other software Change Control Guide

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. 

Kronos Training Zen - The beginning

Developing an effective training strategy is an important part of your Kronos Timekeeper (or any products) implementation/upgrade. While good training has a hand in its success, poorly planned and executed training can lead to dissatisfied employees and a loss of productivity. Training can be a significant investment of both time and money, so it is important get the most bang for your buck. Here are questions to ponder when developing a training strategy.

• How can you ensure employees are learning what is being presented?
• What tools can be provided during and after training to ensure success away from the classroom?
• Is the information being retained?
• What training deliverable will be the best fit for our employees?
• How can we convey the importance of this implementation/upgrade and the affect it will have on employees?

There are issues that arise in this quick list of questions and obviously it is important to get this right.

Customized training should be an integral part of a training strategy. One should strive for quality customized training which considers all facets of the organization, incorporates them into the training strategy, and therefore your training. By doing this, one can deliver an efficient, effective training program that empowers employees to move forward with the new application confidently.

In the next few articles we'll consider the three main benefits here, efficiency, effectiveness and empowerment.

---------------------------

We're introducing Dwain Lambrigger in this series, the Purveyor of Training Zen for Improvizations Kronos practice.

WHEN can that Kronos config change be moved?

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 meeting 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?

Kronos WFC Enviroment Management Tools Part 2 OR "Just what does SDM do anyway?"

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

Kronos WFC Environment Management Tools Part I

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

Understanding Kronos Environments

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.

What is Change Management - Part Deux

For this series we're using the ambiguous term Change Management (CM) as a hybrid of all three descriptors mentioned last article. It's a way to manage change in an organization related to Kronos Workforce Central software development, configuration and upgrades. For our purposes this includes both the cultural/functional (actually CM) and technical changes (actually CC) the improvements will bring.

Are the users going to know how to use the new stuff? How about changing and improving processes and procedures because of the change? These types of issues are often ignored, especially at the Kronos Service Pack level changes. So many new features are not even looked at. Many fixes that could dramatically change and improve the processes & procedures currently used by the organization aren't implemented. And don't forget the workarounds! The technical side is easier (yea right/no really!) and is going to come in more detail later in the series.

CM should be a strong, as automated as possible, well documented and understood approval process for moving though environments. There should be an integrated tool for administration and handling of change request and change documents. This is something that Improvizations is working hard on the R&D right now for the Kronos Upgrade Studio.

So, to begin the high level part of the discussion... The difficulties and dangers are real...without good Change Management practices:

• Connections between business issues we are trying to solve or improve and their associated technical changes are easily lost.
• System problems always come at the worst time and are an ever-present risk.
• Stuff that worked in Development doesn't work in Test or worse, Production
• "Communication problems" are often blamed for mistakes and system instability. 
• Budgets are often (usually) overrun.

Some sources of Change are:

Technical

1. Configuration
2. Enhancements
3. Bug fixes
4. Service Packs
5. Version Upgrades
6. Development Projects

Functional

1. Senior Management
2. Operations Management
3. Project Managers and Team leaders
4. Functional Experts
5. Configurers
6. Developers
7. Quality Assurance
8. Training
9. Help Desk

There are ways to handle the technical issues with a reasonable effort and the use of Record Manager and Setup Data Manager. We still need a procedure around the process.

• Changes are grouped according to projects, areas of use and common technical objects involvement, so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
• Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
• Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. Entries into the Change Control documentation are made automatically and users of dependant objects for a change are being alerted.
• Change processes are strictly followed.
• All changes are executed in a secure way; rollback functions can be made available and changes run repeatedly.
• There is a complete audit trail for all changes.

The functional part is all manual unless you can tie into one of those big expensive SAP systems or plan to get involved with the Upgrade Studio! The technical part is handled well enough by the tools mentioned above, Record Manager and Setup Data Manager. The next part will discuss the Environment Management setup one should have and we'll then follow with details on the How to Manage them.
-----------------

Again... Thanks to Chris Flanders and many others for contributing to this and other articles in the series.

What is Change Management for Kronos?

Change is constant. Right, we all know that. So what's the big deal? Firstly let's get some definitions down for this series as these topics cross one another all over the place.

Change Management (CM) is the process of developing a planned approach to change in an organization. It's somewhat of a holistic approach in that CM looks at everything. Cultural, financial, and technical affects of change; not just for the project but how it fits into the organization. Typically the objective is to maximize the collective benefits for all people involved in the change and minimize the risk of failure of implementing the change. In many circles the term change management deals primarily with the human aspect of change, and is therefore related to pure and industrial psychology in those cases. This is a BIG deal, and in our opinion is usually ignored, or sometimes worse OVER DONE and not really done at all.

Change Control (CC) is the phrase typically used in IT to manage technical changes developed and installed into the applications. It includes tracking Requests for Change and the implementation of those requests safely and efficiently from Development to Production.

Environments & Instances. To create the structure in which one can implement a good Change Control process one creates multiple WFC "environments". An "environment" is defined as, at a minimum, a database, application server instance, and a BGP. There can be more to an environment -- a DCM, multiple application servers, load balancers, etc. This is different that a WFC "instance". One can create multiple application server instances on a single Windows server and these instances can point to either the same database or different databases. The primary difference between an environment and an instance is that while an instance must share a physical server with other instances, an environment can be on a separate physical server. This may seem like splitting hairs, but it will be important to understand later as each environment need is explained.

Besides your Production environment, the best practice structure for Change Control means having other non-Production environments. These environments can be referred to as Sandbox environment(s) (SAND), a Development environment (DEV), and a Testing environment (TEST). What you label each of these environments is really inconsequential, but we will use these terms prupose, and why each of them has a critical role in the Change Control function later. Please note that we're using these three as examples. Depending on your organization, Change Control processes and complexity you might have two or ten instances.

Coming soon! A blog entry or two detailing best practices for managing Kronos WFC environments.

Change Matters

Welcome to the second in the series of the Kronos WFC Upgrade Studio Change Management Toolkit. Remember, no psycho-babble. No discussion of checkpoints, Change Control Review Boards or big flowcharts. We're going to focus on the stuff that matters.

So let's cut to the chase. How does an implementation team decide just how much Change Management (next blog I'll clearly define my use of the terms) is required for the organization? One has to carefully analyze both the functional and technical impact of the changes that will be promoted into Production.

The Technical concerns are usually just "Make sure the change does what it appears it's supposed to do. Don't let it break Production."

The Functional concerns are simply, well, often ignored except for development requested by a particular person/dept/location. The scary part here is that it's the functional areas for which ALL this is done? Why do anything if it doesn't improve Operations, ROI, User Experience, etc.

With this in mind one should ask serious questions about the way we manage change.

• Do you care about the cultural change that's coming? We should consider this every bit as important as not breaking something! 
• Do you understand the ‘WHY' of the change and what it might impact? 
• The change will likely need training. Who needs it, exactly what and why? What will change in their work? How can we leverage the good stuff to come (consider the potential widespread impact)?
• How large is our organization and what are our internal requirements for managing change? Do we have strong automated and/or well documented and understood approval processes for moving through environments (DEV-PROD)? Why not?
• How much development is going on? Coming? And will there be multiple teams who interact, or don't? (We'll chat about Environments and Sandboxes later)
• How are we going to manage the changes as they move through the environments?
• How often are we going to handle patches and upgrades?
• How do we handle issues that arise while migrating change through the environments? 

Those are just a few thoughts to get one started. More to come tomorrow right here in this space!

Kronos WFC Change Management - A Start

Welcome to the first in a series of blog entries about Change Management, Change Control, and Environment Management with content and brainstorming provided by a many including some regular guest bloggers such as Chris Flanders and David Goldhirsch. This is all still in the brainstorming stage so excuse the mess! Please comment, call, email, whatever. We want your input. Thanks to all for your generous help and support to Kronosblog.

The not so clearly defined terms Change Control / Change Management and Environment / Instance Management come up more and more these days as the WFC product line becomes larger and more complex itself. However, unlike from the big guys at SAP or Oracle there is little documentation and tools available at a reasonable cost for Kronos products. Given this is an important part of our new initiative "The Upgrade Studio" I’m starting this discussion and research of best practices to improve what we all can manage for a reasonable effort (always leading to serious cost savings!)

Managing and controlling change; customization, configuration changes and upgrades to Kronos Timekeeper and associated Workforce Central products can be a truly daunting task, with more than its fair share of perils and dramas. What we’re going to present in this series is a simple combination of all those terms and call it the Kronos WFC Upgrade Studio Change Management Toolkit. I'm not going to go into the gritty details of these topics as there are numerous good places to study the science and psycho-babble online like:

Change Management 101: A Primer

Change management - Wikipedia - check out the early links to Change Control and Configuration Management too.

The Information Technology Infrastructure Library (ITIL) is a set of concepts and policies for managing information technology (IT) infrastructure, development and operations. 6.1.4 - 6.1.6 applies to what we're talking about here.

Why Change Management?

Numerous changes initiated by support, project teams or by Kronos are moved into the system landscapes and semi-automatically or more often manually transported to Production servers. Because of the typically elaborate, complex implementations of large customers, the risk that something goes wrong is high and complex; expensive manual interventions are often required to get changes applied without impacting the running systems and operations.

Goal 1: The most important reason to implement Change Management processes is to reduce the risk of your production system. There are three primary risk factors we meet. They are: (1) crashing the system, (2) slowing down the system, and (3) causing inaccurate results in the system. There are other benefits to Change Management as well, like having documentation of change and coordinating communications, but reducing the risk to your production system, by significantly reducing the probability that problems will occur when change is introduced, is the primary goal.

Goal 2: The most important reason to implement Change Management processes is to increase the ROI of the system. Yep. Just as important as not breaking it IMO. I believe in not only avoiding risk (see Goal 1) but in growth from change. Every change to the system should improve the organization in some way. Even fixes to existing problems can do this if approached correctly. Over the years you’ve probably engaged workarounds to various problems. If you don’t address the cultural change of the fix the workarounds will continue to be used, hampering productivity. Prof Frances Frei makes the analogy that "workarounds" are just adding water to cover rocks. The Change Management process NEEDS to uncover the rocks and find the best path to improvements in the organization; changing processes, procedures, training, documentation, etc.

Agree/Disagree? Please comment and look for much more to come soon here at the Kronos Guy Blog.