次の方法で共有

The Value of Change Management, MOF Style

  • [アーティクル]

In a strong article by George Spafford on Datamation, entitled "The True Value of Change Management", many good thoughts around change mgmt are listed. 

 

Some of the points mentioned are:

  • Change is always constant, be prepared to deal with it
  • Change mgmt should have various processes to deal with different types of change
  • Emergency changes should also follow a change process
  • Change Advisory Boards (CABs) should have the right personnel

 

When looking at the change mgmt process specific to your organization, it is true that you have to define a process that takes into account various categories of changes.  This classification should be based on priority and impact to the organization.  The following can help guide the decision for the proper change category:

 

  • The affect on service availability
  • The risk exposure incurred by implementing (or not implementing) the change
  • The number of services affected by the change
  • The number of personnel or support teams required to implement
  • The criticality of the service that would be impacted by the change

 

There are many other factors that can be considered, of course, and ideally these should be placed in a matrix based on each category to help quickly determine what category an RFC (request for change) should be classified with.

 

Once the RFC is classified, it should flow through various levels of authorization, testing, release readiness review, implementation, and post implementation review.  I made the following graphic in an attempt to explain the nature of this process.

 

Change Process

 

The idea behind this graphic is that once the change is categorized in the classification phase, it flows down the appropriate column for a major, significant, minor, or standard change. 

 

As you can see, standard changes flow through the process very quickly to production with minimal "pieces of the pie" required for a post implementation review.  They do not require any authorization or release readiness.  These are changes that are very low impact, often repeatable, and usually pre-approved.  However, they still need to be tracked as a "change" to a particular item in your environment. 

 

As you move to the left into the minor, significant, and major changes, more "pieces of the pie" are needed in order to authorize the RFC, give the GO / NO GO decision for release readiness, and review in the change in the post implementation review.  These "pie pieces" would be made up of various levels of IT Executive Committee, CAB members, Change Managers, Change Owners, etc.  More pieces are needed as the change category rises in impact.

 

In building your change process this way, it is flexible to account for various impact levels for changes, yet still follows a consistent pattern and approach.  Importantly, this same approach can be made for emergency changes.  You could take this same process flow and reduce the amount of personnel involved at each stage.  The CAB/EC (CAB Emergency Committee) would replace the CAB in most cases.  The Change Manager could have a greater authority to put changes through the system.  However, regardless of whether the change is emergency in nature or not, the same level of post implementation review should be made, as at that point, the emergency should be over.