Change and Configuration Management

[query]

Hi Guys

Is this a good break down of the two ITIL models? Anything more to add?

Configuration Management: (Subject to Change Management update)

- Hardware Configuration Records (E.g. Routers, Firewalls, Server Hardware etc.)
- Software Configuration Records (E.g. OS Configuration, Critical Bussiness Software Configuration etc.)
- Network / VPN / VOIP Configuration Records (Network Diagrams and Charts etc.)
- Instruction Records (E.g. Mission Critical Tasks instructions)
- Procedure Records (E.g. IT procedures and policies impacting any IT systems)

Change Management (Subject to live updates)

- Changes to System or other Hardware Records
- Changes to System or other Software Records
- Changes to Network / VPN / VOIP Records
- Changes to instruction Records
- Changes to Procedure Records

[query]

Are there no takers for this one or noone really knows?

[itilimp]

Not sure about everyone else, but in my case I'm not too clear as to what you are actually after. When you ask for a breakdown of change and config do you mean the differences in the deliverables, the definitions, the scope, etc.?
If so the answer is readily available in the blue service support book, and if you just want the nuts and bolts of it a nice summary is in the pocket guide.

[query]

[rjp]

I'm not sure what you are seeking either? When you say 'models' it would help us to respond if you indicated what exactly is being modeled - the ifnrastructure, processes, inforamtion records on the infrastructure (CIs), etc? A breif description of what you are trying to do, or why is also always helpful.

But perhaps the following will help.

Change management is not concerned with the kind of list you included under it. It is concerned with the kinds of 'changes'. Whether a change is planned or unplanned, whether it is a standard pre-approved change or whether it requires approval, whether it is a like-for-ike replacement, an upgrade, a decomissioning, etc. Wether it will change the features of a service (a very important question)!! Whether or not the change is part of a managed release or not. And so on....

What type of thing is undergoing change is a question for the change implementers and configuration management. Change management does not carry out changes - it simply controls and manages them.

Configuration management is concerned with everything in the infrastructure including the items on your list. But bear in mind that it is not primarily concerned with cataloging the 'types' of things. It's two critical concerns are:

1) Being able to check records on the infrastructure with its actual state (status auditing)

2) Being able to show the dependencies between individual components and colection of components. (Ideally to the extent that you can see how they contribute to the production of your services.)

You will need to catalogue them - because, obviously hardware gets managed slightly differently to documentation. But that is only to simplify the administrative overheads. There are no direct process returns from classifying CIs (as components), it's just necessary housekeeping.

[query]

Thanks rjp

Just to clarify a little. By models I mean Change and Configuration management as models part of ITIL. What I am seeking is classification in order to begin implementation of both. Classifications can be broad, but are required in order for the implementation to begin. If no classifications are made then data collected will be disorganized and completely open to change implementer's interepretation, which is something we would like to avoid.

I understand ofcourse that every classification group will have differing internal components such as hardware records structure will differ from software records structure, but all of these branches will also be defined further down the road. The main intention at the moment is to grab the core components, which MUST be included under both configuration and change management records.

I understand change management is not primarily concerned with a list of things, but the change itself. What I would like to record is changes of what? Because if it is not defined then Change manegement would have to be records of every single change no matter how insignificant that change might be (For example changing a viewing setting of my notepad - notepad being a Microsoft application). I agree with all of the internal proccesses you have listed for Change Management, I think they are all a requirement, but the internal proccesses part is something that is being defined on parallel to record management.

I compeletely agree with you on Configuration Management. Is there anything additional that should be noted?

[rjp]

OK - don't stress overly on your component classifications. Whatever you put in pace in the first stage should be clear and simple - and definitely restricted to config management (more on that below).

Software / Hardware / Document and some sub types will get you rolling.

Why? Becasue what I didn't mention is that configuration management, where it is used for status auditing, is also more concerned with instances than classes. It is more important that you identify that a particular component (asset no. xxxx) is being changed than whether you can fully identify its type from its records.

Ensuring that you know specific CI xxx has changed is configuration management. Documenting the technical requirements for changes to System RAM on boards of type xxx is Infrastructure Management - neither change or config management.

Back to Change, and to re-iterate my previous post: If you are classifying components in configuration management you do not need to classify them in change management. Once you liink an RFC to the target components that information will be available to change management via the CI records. Stick to classifying the types of change.

If you are trying to do this because you are thinking about writing work-guidelines for changing certain 'types' of components - my advice is don't. (Welll don't as part of change or config management) That is out of scope for change management, and is back in the realm of technical suppoort specialists (Infrastructure Management).

Change Management is simply that - management - it is a process for reviewing, approving, scheduling (not technical planning), quality control, posit implementation reviews, sign-off and record keeping.

Change building - which would be concerned with 'what type' of thing is being changed is assigned to technical specialists - and they should already know what they are dealing with. That's operational. The change management process are further up the management pyramid - at the tactical level.

So don't overload your process with unecessary or redundant information. Especially in the early stages.

On the other hand let's consider one possibility - you needs are actually operational. That is, what you are really tasked with doing is developing operational guidelines or protocols for technology owners building changes to the infrastructure. In that case I recommend you obtain a copy of the ITIL Infrastructure Management book, and perhaps the Application Management book as well. ITIL is more than Service Support and Service Delivery.