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.