Standard Change Process

[dsemeniuk]

Right now, our thinking is that Standard changes still require an RFC to be filled out for tracking purposes, but obviously pre-approved, we just want to know what people are doing and when but not slow down their job.

We have purchased a tool and want to have list of Standard Changes listed so the user can select the change they are doing and the RFC will be automatically pre-populated with most of the information, the requestor would have to complete some CI information as to where and when the change is happening.

Does this seem like the right track?

[nailerpa]

We are currently using a Change Management form via a database in Lotus Notes. It's very primitive and there is nothing automated about the change process. We've recently purchased Service Desk Express (from the makers of Remedy) and will be purchasing the Change Management module that integrates with that. I'm hoping that that process is much more automated.

[guerino1]

Hello dsemeniuk,

It appears that you're using the term "standard change" in place of a "pre-approved change". Some common terminology that many enterprises use, that might also help you out is as follows:

• Pre-Approved Changes can be executed by authorized stakeholders following authorized instruction, without going through the CM process. (An RFC should still be captured.)
• Standard Changes go through a standard release cycle/window.
• Expedited Changes are usually unplanned changes that must be approved to make it into the next release cycle/window.
• Emergency Changes are unplanned changes that usually require approval for emergency release, outside of a scheduled change cycle/release.

But to get back to your original point, yes, all RFCs should be tracked in some way, shape, or form. However, this doesn't mean that they must be tracked through an RFC form. For example, if you have a traditional Service Catalog in your enterprise, that allows for someone to look up a Service and generate a Service Request, the Service Request, itself, may be adequate to capture the change request information. For example, The Service may be that Service Group A adds a new user to an existing system's database. This may be pre-approved work. When someone makes the request, you have details of who's requesting the work, in the Service Request. Once the work is completed, Service Group A (specifically the member of the group that was accountable for the work) updates the Service Request ticket with relevant information, as they do work, and then closes the Service Request ticket, when the work is complete. You now also have record of who did the work, when it was done, etc.

Do not get caught up in the idea that everything must fit into ITIL. ITIL only covers a very small portion of IT and you must keep in mind that there is a bigger picture to worry about. Think like a CIO, not like an ITIL master, and you'll have a better understanding of what really needs to be done.

I hope this helps.

My Best,

Frank Guerino
CEO & Founder
TraverseIT