Is change management so difficult to implement?

When it organizations strive to improve efficiency and effectiveness, they must reduce unplanned feedback while improving the quality of commercial IT services. The pressure from management is so great that it predecessors are helpless in the face of this situation. There are countless la s about management, which sounds good, but the investment income has not improved. Change management is a key IT service management (ITSM) process that can really work.

It is clear that change management is not a magic medicine that can solve all problems. However, it can greatly reduce unplanned work while improving availability, security and flexibility, so that more employees can engage in planned projects. There is reliable evidence that this is by no means a cliché that sounds good and cannot be implemented.

· Human Error Spreading in design, coding and operations. Any changes to the system may cause a certain degree of risk and lead to a negative result.

· According to the latest research of IDC, nearly 80% of network availability accidents come from human error. Some organizations even exceed this number. In any case, when an incident occurs, the project is put on hold and resources are exchanged until the crisis is mitigated. This will cause project backlog and management failure.

· All things are the same. A system accident may be due to a change. Yes, environmental problems and hardware faults may be one reason, but their probability is lower. People often spend 80% of their repair time trying to find out what has actually changed. If you can solve the problem as soon as possible, your data center will become more available, and IT staff will have more time to focus on planning.

· Although the evidence shows that change management and standardized processes are effective, there is a common "Cowboy" mentality in the IT industry, that is, employees do not like to be told that they must follow a process. To implement change management, or any process about it, you must consciously change this culture.

Considerations for implementing change management

Here I will not repeat the change management content mentioned in ITIL service transformation. I would like to review some of the problems we have encountered, and explain the problems that often occur during the design and implementation of change operations.

· Promote cultural changes. The demand for cultural changes has not received much attention. In fact, a positive attitude often leads to failure. During the design and execution of a process, you should find the right candidates. They are trained to provide communication and early warning mechanisms. The work description and Compensation Plan should be updated in a timely manner to make them suitable for the entire process. Last but not least, users and managers must work hard to learn about IT management, ITSM management, and change management, so as to continuously enhance the demand for change management.

· Why is there a change manager? One person must be responsible for balancing risks or avoiding risks. This person must have a general picture to ensure that the change may not be executed at the local level but at the higher level. For example, a network manager may think that upgrading a vswitch is a low risk because he does not realize that the change occurred during the weekend's account statistics, which hides a risk.

· Focus on it! It is best to design a process and execute it at a specific IT level, at which both the business and IT departments are willing to prototype the process and debug it. In a small scope, a change process is easier and less politically risky than pursuing an all-in-one or all-in-one method.

· Start from scratch. As complexity increases, the difficulty of cultural transformation and the risk of long-term continuous change management also increases. At this point, we need to plan the continuous process improvement and develop a development blueprint to determine that the process will evolve with the new version. However, we must make sure that the improvements are gradually made from the beginning. Sometimes the beginning of change management may be the most difficult.

· Multi-mode. ITIL change management processes can identify the use of multiple modes: Standard, urgent, secondary, formal, and primary. These are only workflow processes that properly balance risks, costs, and time. In fact, an organization can have multiple models, as long as they have practical meanings and know when to follow them. Organizations implementing change management should adapt to their various models so as to have appropriate flexibility and risk management capabilities.

· The standard change model is crucial. Speaking of models, the standard model enables the recording and implementation of low-risk and predictable changes. These changes do not need to be submitted to the Change Advisory Board (CAB), so that the IT department has higher flexibility. They still need to be executed only in the authorization change window, and must be recorded so that people can easily answer this question "Is there any change ?" Over time, changes that meet the required standards should be formally reviewed and follow this model. Most changes in the Organization should follow this pattern. Note: If a change has obvious problems for any reason, there must be a way to formally revoke the standard level of the change.

· Pay attention to urgent changes. For the Organization, emergency changes bear the greatest risk. Pay special attention not to let it personnel think that urgent changes are a good way to promote changes in production in order to make up for the lack of planning. An emergency change should be an emergency, which will then be detected and investigated by cab, the relevant Vice-Chairman or CIO to determine why the enterprise is in danger.

· Criteria for determining failed changes. Many people often argue about what causes a failed change. They often associate individual and team behavior goals with compensation. If an accidental event or change cannot be completed as planned, a change shall be deemed as a failure. Note these two factors-if an IT service has a negative impact, such changes fail. When a change occurs but cannot be executed as planned strictly, it is marked as a failed change and the opposite plan is executed. Failure must not be wrapped in sugar clothing. The capability of changes must be improved over time. If the change result is unpredictable, it indicates that some things are common errors and must be corrected immediately.

· Change detection. Automated tools can help detect and communicate with a configuration change approved in a configuration. With these tools, a group can literally ensure that the system is not modified in any way and the change management process is being tracked. This is very important because business operations and information security need to know in a timely manner whether a change has occurred.

· Responsibility. IT personnel must follow the change management process. If they do not, there must be clear solutions. Quality Expert W. Edwards Deming says that you can only do two things in one process-either follow it or formally change it-there are no other options. In addition, people cannot deviate from the process spontaneously. It is necessary to confirm the process in management, which can reduce risks.

Change management is a key control process for the IT industry. It is by no means a process that satisfies the bureaucratic control of regulators. It has proved to be beneficial to all organizations, including improving availability, reducing costs, obeying management, and reducing security vulnerabilities. (Post)