Standard Changes - How to submit

[dsemeniuk]

How do people log and submit Standard changes?

As in, we still want people to submit RFCs but they would classified as "Standard" and already have a status of approved.

We want to automate this process in our tool so that you can select the type of "Standard" change you are doing and fill out most of the known information for the requestor and just have them fill in the maybe the time they are doing it?

Anyone else take this approach or how do you handle submitting and tracking Standard changes?

[ARoll]

dsemeniuk,

I can let you know how we've done this with our toolset and i suppose there really won't be a right answer i could give that isn't dependent how you have that setup.

I may jump this around a bit but hopefully it will be followable. Our Change Owners(CO) go through the normal RFC process, and in our form we have a check box in which they can check if they believe the change should be considered for a standard change. This is a trigger for us when generating Cab agenda's to pull this in as a stndard change consideration. If at the cab we determine that yes this will be a standard change we do the following in our toolset. We create what's called, by our organization, a Standard Group Change. (In our toolset we cannot relate an RFC to an RFC so these group changes are how we relate an RFC, like a hierarchy). We have UI/Role rules setup that only members of change management can create this Standard group change. Once this is create the CO has the ability to make a copy of the original change, update necessary fields and select a pre-approved status. by UI rules we have in place it has to be related to this Standard Group Change. Then we review it post implementation to ensure that the approved standard was followed etc.

Hope this makes sense. Some other options that i have seen/heard of is having an web api into your tool set for these standard changes in which the CO basically fills in the blank. But again this tends to depend on your org/tool and how you implement standard changes.

[UKVIKING]

If you are talking about Standard (ITIL defined) chanegs, this is how we are going about

We define what the criteria are for each type

Emergency
Urgent
Normal
Standard

We define the Normal process as the primary process through a policy document

We have an shorter process which auto-dealing with certain aspects for Emergency, Urgent and Standard.

Each type of Standard changes need to be explicitly defined so that the definition is quite clear.

For example All the details risk impact, imp plan test plan, backout plan, are the same except for the specific work for the change
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[skeptic]

Dear me ARoll, seesm to me you are defeating the purpose of standard change, which is to get out of the way of the business and let things happen. Once a category of change has been judged to be sufficiently low risk to be Standard changes, people should be able to just request one and it happens.

having an approval or pre-review process adds bureacracy that is not in the spirit of a standard change. To be precise, having approval by the Change management process is not cool. other stakeholders may well want to review a standard change, for example if someone requests access to a new service then security and/or the service owner may want to approve that change first. but Change Management should butt out - that is the whole point of standard change.

For this to happen, you need a few things:
- standard changes must have templates that rigorously pre-define the implementation process, the test plan, the backout plan etc...
- there must be audits of standard change to ensure the mechanism is not being abused to smuggle through non-standard change, and there must be cruel and unusual punishment for those caught. Fire the first one, I say.
- have a report so you can track usage of standard changes
- some standard changes may trigger a PIR, especially if they are big. Remember standard changes don't have to be small, just low risk. The two do tend to correlate but not always.
_________________
The IT Skeptic
see you at itskeptic.org

[goitilcouk]

All,

for what its worth, here is my take on it (or certainly how we have approached standard changes....)

Our motive following a complete review of our change process was to get the average lead time for a change to 8 days. This allows the process to be followed to meet our senior manager objectives of showing an increase in core service uptime. One of the biggest issues we found that was driving outages was short lead time changes not being discussed and evaluated enought.

So to get the buy in, we allowed "pre approved" standard changes to have a 3 day lead time.

All standard changes are documented around the technical steps, impact, testing, backout etc but we noticed that most standard changes have a variable element (eg restores may have a file directory that changes each time, SAP transfers may have a variable account code etc). The variable aspect of the change is clearly defined in the RFC (ie an RFC is raised with an agreed set of fast track approvers, the standard change form is attached into the RFC and the only "type" information is the variable elements).

It seems to work and clearly demonstrates that ITIL is a framework that should not be taken as "the only way to do it" but offers guidance and best practice to mould to each individual organisations aims

Rob
_________________
Pondering the question:
Why dont small companies get it ??

[skeptic]

if a change has been classified as low risk (highly controlled, highly defined, well understood) and designated as "standard" as a result, why should it wait at all? Standard-change notification should be after the fact as a FYI for change and config managers and reporting.

that's the whole point of standard change, I think.
_________________
The IT Skeptic
see you at itskeptic.org

[goitilcouk]

[Ivy]

We too log and submit standard changes, although we call them MAC's (Move, Add, Change)
We define it to our users as a routine activity involving low risk and impact to production services and is performed on a recurring basis. To utilize the MAC, the process to perform the activity must be certified through the normal change process for a Major Change Order. Once certified, a MAC can be performed according the approved process and with the appropriate change record without additional approvals for the individual change orders.

The process flow we use is:
IT Member evaluates if the process routine, benign occurs on a regular basis.
If so, they submit a major change order to the CAB requesting certification.
The certification must include:
 Documented implementation procedures
 A verified test plan from past implementations
 A verified backout plan from past implementations
The CAB confirms risk, process, test plan, backout plan and frequency of occurrence.
The above step is a 1 time deal (unless the process changes... then it needs to be updated via the same process)

After the one time certification...

IT Member Enters a MAC change order.
IT Member Implements MAC change order.
IT Member Sets the change order status to “closed”.