Joined: Aug 11, 2006 Posts: 1 Location: Milwaukee, WI
Posted: Fri Nov 03, 2006 4:24 am Post subject: Tracking Routine Maintenance changes
In our organization, we have four change types Planned, Unplanned, For-the-Record, and Routine Maintenance (RM). ServiceCenter is used to process (repository of docs, approvals, etc.) the first three types but RM changes are not. A listing of each workgroup's RM changes is maintained for audit purposes.
Now we are being asked to be provided counts on the total number of changes. Our clients wouldn't appreciate having to complete a RFC for a RM change. Even if we stripped out virtually every 'control' in ServiceCenter app, the RFC process would still take longer than performing the actual change.
Joined: Sep 16, 2006 Posts: 3536 Location: London, UK
Posted: Fri Nov 03, 2006 4:57 am Post subject:
What do you mean 'Routine Maintenance'
If there is no changes in the configuration of the IT devices but merely the culling of the log files etc, then it is not really a change but merely operational service work.
The only real reason to put the work in Change Management is to track the scheduling so that any 'real' chaneg work does not conflict with the Routine maintanence
The examples given are not changes but operational work (service requests), so in my humble (not) opinion a RFC is not needed merely a Service Request and tasking for the implementating group _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Fri Apr 27, 2007 7:20 pm Post subject:
For most enterprises, what you describe as Routine Maintenance is really no more than a "Task". As John mentioned, if you're not changing a configuration, it's really not a change.
Whoa, stop, hang on...
Now I know I'm a bit late to this discussion, but let's not be too hasty to dismiss stuff as mere 'tasks' or 'routine'. It depends on the environment, and for example in the Defence environment resetting a password or clearing logs is not routine, and an audit trail is definitely required.
Take the following scenario - user calls service desk to change password and the password is reset. Later another user calls the service desk to say he is blocked out. Panic ensues as it turns out the service desk has been finessed into giving access to someone who should not have access.
Now of course the service desk should have processes to prevent such an occurance, but that's not the point.
The point is that what constitutes routine maintenance for one environment does not for another. So think hard about what constitutes a change and what is routine.
Let's also try to define what routine maintenance is. If these are daily, weekly, monthly tasks that are necessary for the service to continue functioning, but do not affect the service availability, e.g. log archival, testing during the service maintenance window, etc. then you do not need a change request.
Any other task that might affect service availability according to the SLA are not routine and definitely require an RFC, irrespective of whether a configuration item is changed or not.
So the first simple test to determine if a task requires an RFC is: will it affect service availability as defined in the SLA?
Another easy way to distinguish between routine maintenance or RFC is to ask yourself if the task in question will go via the service desk?
1) an SMTP server has its logs routinely archived. This will be part of the task list of the technicians maintaining the server, no-one will call the service desk and request that the logs are cleared.
2) A user forgets his password and cannot log in. This is effectively an incident as the user cannot use the service, therefore he/she will call the service desk and request a reset. The service desk may have delegated authority to change the password, and does so immediately as allowed by the workflow. However they should still open and close the incident.
Now in say a tin box manufacturing company this may be a routine occurance, and the incident record could be considered a sufficient record, whereas other organisations may need a retrospective RFC to be required.
In a top secret death beam research lab you would probably not want the service desk to make such a change, but to raise an urgent change request which might be authorised by head of the SS (security services).
What constitues a change should be described in the Service Description, and have service parameters defined in the SLA. This should be your first stop, unless of course you are writing the SLA;-)
I think what's important is that you want to track the work. Can you get ServiceCenter to simply log each task it performs, in such a way that you can farm its logs for counts?
Agreed. And you can use incident or change records to do this. After all this is information that is required by capacity management, problem management and financial management.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum