What is Change Management for Kronos?
Sep 06, 2013
Your web browser is out of date. Update your browser for more security, speed, and the best experience on this site.
You may also visit the site on your mobile device.
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.