What constitutes a "change" vs. a sys admin task?

[fwells2005]

We are having a debate about how to define a "change" vs. a sys admin task. Some are obvious like applying a patch to a server OS that will require a reboot - change, or a sys admin adding a user to an application environment via a standard admin interface and with assigned authority - admin task. The grey areas are situations like:

1. Installing a new test server into a production network

2. Database configuration changes

3. Creating and running SQL code that manipulates data

Does anyone have ideas or documentation about how to define a change?

Thanks!

[UKVIKING]

all three constitute a change in my world

1 - you are adding (change) to the production network
2 - you are configuring (chaneg) the db
3 - back end data manipulation -
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[jmichaels]

Here are a few other examples we're having some debate over, I'd love to have some input from folks who've been through these discussions and have decided one way or another, with the rationale applied:

1- Application/Service startup-script change
2- System/Server startup-script change
3- Data replication software configuration change
4- Data replication software data-set change (add/remove)
5- Failed RAID5 hard disk replacement
6- Disk controller cache-battery replacement

Personally, I think all these have slam-dunk answers, but you know how it is....

Also, if there's a section in the ITIL manuals or some other well-established guidance that clearly speaks to (how to answer) these questions, I'd appreciate if someone could direct me to it.

[Diarmid]

I think you will find that many people would consider all these to be changes and I would be among them.

It's a bit like a change is a change is a change. Anything you do to your configuration is done in order to have an impact on service (perhaps preventing a future failure, or making an improvement, or adjusting to changed circumstances) f it will not have an impact, then why do it? If it is intended to have an impact then you must ensure that the impact it has is the desired or accepted impact and no other and for this you use Change Management.

One supposes that, behind the question is a concern of over-managing "simple" activities. The answer to this is not to deny that things are changes and therefore have risks and costs attached, but to consider defining specific procedures to manage specific types of change in the most efficacious manner. Some people (and ITIL) want to classify such things as "standard changes".
_________________
"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

[Bluesman]

Sysadmins *generally* know their stuff. So..in order not to complicate/delay things and drive them (and the CM process) crazy, put server patches and other well defined & justified smaller changes into a "pre-approved change" category. Ask for written procedure on each PAC, and demand post-implementation documentation. "Who did what, when, why, to what system and according to what (approved) routine" could be your baseline for documentation.

No best practice (and approved) routine=NO CHANGE ALLOWED. No post-documentation = sysadmin takes the heat.

my 0,02 /Richard
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr