Has anyone standardised changes within IT?

[seanban]

Hi,
I'm rather new to this world of Change and amazed of the absence of standardized changes within IT. I'm not talking of the Standard/Normal/Emergency worflows - this is s well defined. No. I'm more talking of how we:

- list the types of repeatable changes we do such as Install Server, Install DB Servers/App Servers/Firewalls ....
- decompose each change into logical builing blocks/tasks and order them?

I know that this is linked to how each IT department is organised and the technology used. Nevertheless I fail to understand that a blueprint for this "change architecture" is not already done and available in the public domain?

Anyone know otherwise?

Thanks - Sean

[laurieballard]

We use Request Fullfillments for standard changes

[UKVIKING]

seanban

As each company defines standard changes - even the set of activities of 'install new laptop or desktop' - differently, there really is no official IT list of standard changes.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Al_Rel-EZ_Al]

Hey Seanban,

I know what you mean about the 'absence of standardized changes', but as UKViking mentioned, many organisations have their own customized way of handling various changes.

I agree with you that there are MANY processes out there that has been so often done and dusted, that you'd think people would publish some kind of methodology or even some kind of standard so Change Managers/Operators like yourself would not have to re-invent the wheel.

I believe the world of ITIL is huge and complex, and there are certainly many pieces left for you to piece together.

Incidentally, my area of focus is Database and Software Deployment Change Management...
I have seen many clients of mine merely re-creating the wheel and finding no resources to maintain, nor standards to adhere to. So the system/workflow ends up being very clunky and a real band-aid job as long as they somehow manage to get through BAU. Which is why I am trying to create a new standard and a new tool to hopefully cover majority of use cases.

Perhaps you might want to define a standard somewhere or contribute to putting together a standard for specific repeatable changes you have spoken about somewhere and we could comment and help refine?
_________________
Al_RelEZ_Al

[Diarmid]

I missed this thread . I suppose because I was still away when it started.

Anyway, the mechanics of methodically building a server, for example, are not the core concern of Change Management and if you can document them in a sufficiently detailed and easy to use manner to form an industry blueprint, then that is good, but it will not give you a viable "standard change" blueprint.

Change Management is concerned with impact and risk above all else and a blueprint for any particular "standard change" would have to be extremely general and cover many topics, not relevant to all organizations.

A "standard change" procedure has to address scheduling of actions and resources, authority (both in IT Services and in the customer environment), approval, co-ordination between and among service units and user units, contingency arrangements, prioritizing..., in short it has to cover everything that the CAB would have concerned itself with, were it not approved as a "standard change".

It takes but a moment's thought to realize that the above paragraph is about as far as the blueprint could go, because of the vast diversity of organization and business circumstances.

The true criteria for establishing a "standard change" are repeatability and controllability, and the second of these is sine qua non. If it cannot be controlled without the intervention of the CAB then it is not a candidate for becoming a "standard change", however repeatable and simple the technical processes are.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718