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.

The cultural change is really important.

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 dependent 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.