New video form BMCdocs’ boys. They are increasing the length of the videos, a thing that I really appreciate.
In this post I will link this video, and transcript the process description part (it’s quicker to read than to listen). Italic parts are my comments.
The Service Management Process Model
The Service Management Process Model, or SMPM, turns the theory and guidelines of the IT infrastructure Library (ITIL) into concrete processes than an IT organization can implement. The BMC Remedy Service Management applications automate these processes, and link directly to SMPM so that you can see the process that applies to the part of the application in which you’re currently working. In fact, the SMPM is a generic implementation of the ITIL processes, that you can adapt to your organization. At some points, SMPM vaguely detailed under my point of view, and at some points it provides an excess of detail that surely won’t adapt to the most organizations.
The Change Management Process
The Change Management Process contains two distinct work flows. One is used for emergency changes, which are changes made according to your organization’s emergency change policy. Emergency Changes are in fact one of the most important parts to focus when defining your procedures. What will be considered an emergency change?. Also, not shown on the video, there is a need for an Emergency CAB, to provide approval for this change.
Evaluating the RFC
The other is used for implementing planned changes, which is what this video describes. The planned change process starts when the change coordinator reviews the details of a new change request to see if it qualifies for the Change Management Process. If it does, the coordinator routes it through either the standard change or the non-standard change process, according to the organization’s policies. If it is a standard change, the coordinator uses a template to complete the request, and the change planning process can begin. One of the main advantages of using Remedy, is that you are able to speed up the execution of your processes. You need a coordinator, but I think that requiring him to review all RFCs is not the best solution. Specially when the change is an standard change. My advise is to teach your staff to know when it is an standard change, and only use the coordinator for non-standard situations. Think on this case: “A mouse replacement”, Does this change need the change coordinator to act? Definitively not. Of course the coordinator must overview the process. Also, for an standard change a RFC is not needed. A service request or an incident can result in an standard change. To force your users to register the change at the change management application has two counter effects. First, it is a waste of time clicking and filling text on the application with a very little value. Second, Change licenses are expensive, and you can reduce it’s cost by non using this application for standard changes. You can use work orders or Help Desk tickets to do this job. The Change application features won’t help in an standard change (like approval, time scheduling, etc.)
Before proceeding with nonstandard changes, the coordinator first checks to see if the change request conflicts with any company standards or policies. The coordinator then ask several questions about the request such as: will it adversely affect a service during service hours? If the answer to all of the questions is “no”, the change management process is not needed, and the request is rejected. Most nonstandard changes are now passed to the Release Management process, unless they meet certain other criteria, for example if they prevent or fix a problem, the coordinator keeps them within the change management process. I will be sincere to you. I don’t understand this paragraph. As I understood, if a change doesn’t adversely affect any service, the RFC is rejected. This is non-sense. Because a lot of reasons. First, at most cases the change coordinator is not able to declare if it impacts the service or not. That’s the work of the CAB. So, if the coordinator sees no problem with the change, then he must pass the decision to the CAB. There is only one exception to this: standard changes. But we are talking about non-standard changes. Also, you may want to track all changes to your CI’s. For standard chances, you can identify a incident or request category. But for non-standard changes?. Also, if when you reject a RFC, you deny it. So it can be confusing the situation of a little difference between denying a change and executing it outside the change management process. The next sentence, about deriving changes to the release management process, assumes a software change. Well, I would rewrite the sentence on the opposite, like, “The change coordinator will review if the RFC meets the criteria to be passed to the Release Management Process”. That is, most of the changes won’t be transferred to the release management process.
Planning
The Change Planning process starts with a risk and impact analysis, in which the change coordinator consults with specialists to gather information to create a change implementation plan. If corporate policy requires approvals, the change approval process comes next. Otherwise, the coordinator moves directly to the implementation process. I agree with the need to check the risk and impact with specialists. But I think that there is missing an important point: the service level management. Risk and Impact, along with urgency, must be evaluated without forgetting the related SLAs. How do you measure the risk? In affected users? In the number of compromised services? Or in the number possible broken SLAs? Finally, about the sentence “If corporate policy requires approvals…”, ITIL recommends to always define a CAB. As I stated before, there is only one exception: the standard change. The entity with the true decision power is the CAB associated with the CI.
Approval
If the approval process is needed, it starts with the change manager reviewing the request for conflicts with any internal standards or policies. Next, the manager reviews the plans to ensure they are complete and they don’t conflict with other changes or events. When the manager is satisfied with the plans, they collect the necessary approvals and then assign the change to a specialist for implementation. I think that it is a bad idea to first plan and then approve. I think that a two-stages approval is better suited. First approve the change itself. For instance, a problem determines a low free storage space for an email server. An RFC is created to add a new disc drive to the server. But maybe the CAB rejects this solution and promotes another RFC, that is a reduction in the email account space per user, because it is currently over the SLA. There is no need to spend time on planning.
Implementation
How the specialist implements the change depends on whether it affects infrastructure elements or an application. If the change is related to infrastructure elements, the specialist must ensure operational readiness. This can include such activities as ensuring the required hardware is ordered and so on. When the specialist is ready, they receive and complete the implementation tasks. If the change request is related to an application, the specialist begins by developing the changes. The application is then tested to ensure the change requirements are met. After the specialist confirms they are met, the release coordinator transfer the application to a test environment, where customer representatives perform acceptance testing. After the application is accepted, the specialist ensures operational readiness. This can include, for example: training users. When the application is ready, the release coordinator transfer it into production.
Closure
The final process, Closure, starts when the specialist performs production testing to verify the change requirements are met. After the specialist confirms this, they ipdate the CMDB and any other related systems to reflect the changes. When the coordinator closes the change request, they inform the stakeholders that the change was made. At this point I disagree. I think that changes must be reflected on the database as soon as they are realized, not as closure. For instance, a change execution can take weeks to complete. In this case as soon as a new server is placed into production, as a part of a quick win strategy within the change, this must be reflected on the CMDB. What I recommend is a verification of the CMDB at closure to ensure that the changes to the CMDB have been done.
