I want the Service Catelogue details as to the service being provided to the users

Data like

Who the users are for the service provided
what are the expectations in the SLA about maintenance windows, changes etc

I want the entire SLA so when I have to deal with the service associated with the SLA, I know some of the risks/impacts of changes on that services_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

>what are the expectations in the SLA about maintenance windows,
>changes etc

This a a little vague. There should not be expectations in an SLA, there should be hard data. e.g. the maintenance window is 0000 - 0200 on the 1st Sunday of the month etc. In fact the SLA and SLD (Service Level Description) should be dictating all of the major influences in the change process for that service. By that I mean the cost, the time taken to perform a change, the affected systems, windows in which the change may be performed etc.

>I want the entire SLA so when I have to deal with the service
>associated with the SLA, I know some of the risks/impacts of
>changes on that services

I agree you'd want the entire SLA, (and the SLD as well). But again this is a little vague. You *must* have the SLA/SLD so that you know *all* of the potential risks and impacts on the existing service.

How can the CAB authorise a change if it does not know the cost, impact, lead times, risk, change window etc. for that service? In other words all of the information the CAB needs to process a change request should exist in the SLA/SLD. This is also how the CAB knows whether a request is urgent or not.

The change management process is reasonably easy to define in terms of the processes, roles and responsibilities. However, the data captured, timings, and decision making factors are all dependent on the specific service, and hence on the SLA/SLD.

The SLA/SLD should be driving the change management process to a much greater degree than the general impression I get from reading this forum suggests.

If there is a service being provided using IT equipment, there needs to be within the SLA or contract that the department supporting that kit can conduct periodic maintainence (monthly) on the kit and consider the time outside of SLA Operating Hours

In addition. the IT Operations group needs also to have the ability to do emergency S/W and H/W patching in regards to security or vulnerability concerns

Some SLAs are written very broadly, poorly or not at all when it comes to needed downtime, service hours etc.

The Change Mgmt process while it does need to identify the risks and impacts of a change, the members of teh CAB should come from the service provider and the service consumer - even it is all one company

As to costing etc, that is usually handled with a company through cross charging or budget codes of the staff's hours.

I dont think a change request should be held up because of penny pinching.

It usually costs the company more later_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

John,
this seems to have become a longer post than I expected; apologies to those who like short answers:-)

I totally agree with what you say, but I'm not sure how that is incompatible with my post. Any halfway competent ICT provider will ensure they have provision for emergency maintenance at any time - however this should not be an excuse to subvert the change procedure.

On the other hand the change procedure must allow for emergencies, which is what ITIL does with 'Urgent Changes'. How that happens depends on the environment and the service involved: it might allow for the ICT provider to go ahead and make the change, and inform the customer retrospectively, or it might still require approval from the CAB irrespective of the threat to the service.

I totally agree that most SLA/SLDs are poorly written, but that does not change their importance to the change process. Not only should they set parameters for changes to be processed, they also should define the benchmarks by which the performance of the service and service provider are measured. Otherwise how do you know you are getting what you pay for?

I know many organisations, espcially those that provide their ICT solutions in-house, do not bother with internal SLAs to their own customers (i.e. the business) but this is poor practice. Worse, it normally ends up slowing down the change process as the CAB must do a lot of extra work determining information such as cost, impact etc. Information that should be in the SLA/SLD.

Indeed there is a strong argument for the CAB having a predefined set of criteria that a service must meet before it is accepted as a service. This should include SLA/SLDs with a minimum set of required parameters such as cost, lead time, maintenance windows etc.

Of course this does not always work in some situations, but the CAB can always impose SLA values on 'services' that do not have them. It is then up to the service provider to agree these, or provide their own values.

The usual argument against this is that the organisation wants to be 'lean, mean, flexible and responsive'. But what that often means is that the organisation operates in perpetual crisis mode, and is particularly vulnerable to key staff leaving or being absent for whatever reason.

>As to costing etc, that is usually handled with a company through
>cross charging or budget codes of the staff's hours.

That is very dependant on the environment. I work mainly with large corporates where many services are outsourced, and generally have known prices. Internal cross charging is frequent of course, but particlarly when the company is a multi-national, it is not always possible, or even legal. Cross-charging can become cross-subsidation which goes against competition laws in many countries.

It still think it is better to create SLAs and fix costs as far as possible.

I agree it is not always possible to have a known cost for a service, particularly when it involves development. But this is why (IMO) it is usually better to separate service development from routine change management - but that also of course is dependant on the type of change, and the environment.

I do feel this is one of the areas where ITIL can be confusing - in many organisations changes due to service development and routine changes to existing services (moves/adds/deletes) are handled differently, which I personally think this is correct.

>I dont think a change request should be held up because of
>penny pinching.

I'm not sure what you mean about holding up a change request due to penny pinching. A change request follows a set process where the costs are evaluated as part of that process, and cost is then a factor in whether the change is authorised or not. The only way cost should hold up the process is when it is not known - and having well defined SLAs will help prevent that situation.

Hmm, another hour of theoretically productive work gone;-) Still, it is great to have this forum and I wish there had been something similiar around years ago!