Is this a Change?

[PaulRKrueger]

I have just completed implementing Change Management in our small organization (17 IT staff). We have not yet implemented any of the other processes. As things ramp up, I have come across some questions I can't quite answer. I'm sure it's because we don't have Configuration, Incident, Problem, etc. up and running, but certainly I should be able to handle these:

1. We have a SPAM firewall that uses a Bayesian database to score email messages. We "train" this database by teaching it what is and isn't spam. This is a routine activity and we want to know when it takes place. The training is done in the background while the system is operational.

A change is a change in status of a CI, but my spam firewall isn't changing status. So do I have a change? If not, where would this record be kept? If we were to train it incorrectly (resulting in false-positives) we would have in increase in incidents related to the training that took place, but with a change record... you see where I'm going with this one.

2. We have a request to install an ActiveX control for Internet Explorer on one of our machines. Like the previous example, there is no change in status of a CI here, so is there not a change?

[jpgilles]

to determine whether it is a change or not, you may look at whether it is part of your cmdb or not.

You may want to consider that the "rules" for antispam make up a CI as such , therefore any modification to it is a change. However that does not mean you have to go and get cab's approval everytime: you may have the cab agree with this change to be done on a regular basis according to certain guidelines , rules of operations, procedures, (save the"table" first, being able to restore it, trace the change, ...) and have the authority to execute it delegated to an operationnal team.

whether to consider something as a CI or not , I would usually ask myself: in case of a disaster recovery plan , is this a piece I would want to be able to recover as it was before? If yes, that means It is part of the config I want to have in the cmdb, and I want the changes on it to be controlled through chabnge management.

hope it can help...

br
JP
_________________
JP Gilles

[UKVIKING]

In addition to jpgiles,

answer the following question ?

Do you keep track of the 'rules' that you have on the spam filter ?

Are you interested in what rules were added/deleted/modified on insert date or by whom ?

Is the 'rules' updated manually or automatically ?

Does someone double check the rules enabled and corrects them if they are overly sensitive ?

Change Management is control of what goes on...

As long as you have a written/enforced/well known process for dealing with the above to include an audit trail, then you have a change management process / control for the spam filter.

From my POV, if you have all that, then change management would consider your area... controlled (standard change rules)
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[dboylan]

And remember that a Change isn't just for a change in Status of a CI. It should also be invoked in a change in Attribute of the CI. If you are tracking what version of software patch the "rule" is contained within, then yes, you should be managing it with Change Management. If you aren't tracking the version, then no, you don't have to.

[Guerino1]

Hi Paul,

I think it's safe to say that it's far more important to track Changes than it is to run everything through your Change Management process.

Change Management, especially as identified by ITIL, is not necessarily the best answer to managing Changes to your environment. For example, there are many forms of change that can be automated and sanctioned to be applied to your environment that you shouldn't have to run through your CM process. ITIL will call this something like "pre-approved Changed", however the reality is that there is a huge ocean of these types of changes that, when implemented properly, will be far more effective than running everything through a single body like a CAB. My recommendation is that you use your CAB only for the most obvious and critical of changes, to maximize it's time and value. The alternative is to properly automate and document other forms of change, so that they become obvious, repeatable, high in quality, and low in risk.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL