:






Table E.6 Office environments



Access All offices should have the appropriate secure access depending on the business, the information and the equipment contained within them
Lighting, temperature, humidity and air quality A normal clean, comfortable and tidy office environment, conforming to the organizations health, safety and environmental requirements
Power Clean power supply for all computer equipment, with UPS facilities if appropriate
False floors Preferred if possible, but all cables should be contained within appropriate trunking
Fire detection/prevention and extinguishers Normal office smoke/fire detection systems and intruder alerting systems, unless there are major concentrations of equipment. Sufficient fire extinguishers of the appropriate type, with adequate signage and procedures
Network connections The office space should preferably be flood-wired with adequate capacity for reasonable growth. All cables should be positioned and secured to appropriate cable trays. All network equipment should be secured in secure cupboards or cabinets
Disaster recovery Fully tested recovery plans should be developed where appropriate

 


Appendix F: Sample SLA and OLA

This appendix contains examples of SLAs and OLAs and their contents. It is not recommended that every SLA or OLA should necessarily contain all of the sections listed within the following sample documents. It is suggested that these areas are considered when preparing document templates, but that they are only incorporated into the actual documents themselves where they are appropriate and relevant. So the following outlines should only be considered as guidelines or checklists.

SERVICE LEVEL AGREEMENT (SLA Sample)

This agreement is made between.................................................................and

..........................................................................

The agreement covers the provision and support of the ABC services which..... (brief service description).

This agreement remains valid for 12 months from the (date) until (date). The agreement will be reviewed annually. Minor changes may be recorded on the form at the end of the agreement, providing they are mutually endorsed by the two parties and managed through the Change Management process.

Signatories:

Name....................................................Position........................................Date...............

Name....................................................Position........................................Date...............



Service description:

The ABC Service consists of.... (a fuller description to include key business functions, deliverables and all relevant information to describe the service and its scale, impact and priority for the business).

Scope of the agreement:

What is covered within the agreement and what is excluded?

Service hours:

A description of the hours that the customers can expect the service to be available (e.g. 7 24 365, 08:00 to 18:00 Monday to Friday).

Special conditions for exceptions (e.g. weekends, public holidays) and procedures for requesting service extensions (who to contact normally the Service Desk and what notice periods are required).

This could include a service calendar or reference to a service calendar.

Details of any pre-agreed maintenance or housekeeping slots, if these impact on service hours, together with details of how any other potential outages must be negotiated and agreed by whom and notice periods etc.

Procedures for requesting permanent changes to service hours.

Service availability:

The target availability levels that the IT service provider will seek to deliver within the agreed service hours. Availability targets within agreed service hours, normally expressed as percentages (e.g. 99.5%), measurement periods, method and calculations must be stipulated. This figure may be expressed for the overall service, underpinning services and critical components or all three. However, it is difficult to relate such simplistic percentage availability figures to service quality, or to customer business activities. It is therefore often better to try to measure service unavailability in terms of the customers inability to conduct its business activities. For example, sales are immediately affected by a failure of IT to provide an adequate POS support service. This strong link between the IT service and the customers business processes is a sign of maturity in both the SLM and the Availability Management processes.

Agreed details of how and at what point this will be measured and reported, and over what agreed period should also be documented.

Reliability:

The maximum number of service breaks that can be tolerated within an agreed period (may be defined either as number of breaks e.g. four per annum, or as a Mean Time Between Failures (MTBF) or Mean Time Between Systems Incidents (MTBSI)).

Definition of what constitutes a break and how these will be monitored and recorded.

Customer support:

Details of how to contact the Service Desk, the hours it will be available, the hours support is available and what to do outside these hours to obtain assistance (e.g. on-call support, third-party assistance etc.) must be documented. The SLA may also include reference to internet/Intranet Self Help and/or Incident logging. Metrics and measurements should be included such as telephone call answer targets (number of rings, missed calls etc.)

Targets for Incident response times (how long will it be before someone starts to assist the customer may include travelling time etc.)

A definition is needed of response Is it a telephone call back to the customer or a site visit? as appropriate.

Arrangements for requesting support extensions, including required notice periods (e.g. request must be made to the Service Desk by 12 noon for an evening extension, by 12 noon on Thursday for a week-end extension)

Note. Both Incident response and resolution times will be based on whatever incident impact/priority codes are used details of the classification of Incidents should also be included here.

Note. In some cases, it may be appropriate to reference out to third-party contacts and contracts and OLAs but not as a way of diverting responsibility.

Contact points and escalation:

Details of the contacts within each of the parties involved in the agreement and the escalation processes and contact points. This should also include the definition of a complaint and procedure for managing complaints.

Service performance:

Details of the expected responsiveness of the IT service (e.g. target workstation response times for average, or maximum workstation response times, sometimes expressed as a percentile e.g. 95% within two seconds), details of expected service throughput on which targets are based, and any thresholds that would invalidate the targets).

This should include indication of likely traffic volumes, throughput activity, constraints and dependencies (e.g. the number of transactions to be processed, number of concurrent users, and amount of data to be transmitted over the network). This is important so that performance issues that have been caused by excessive throughput outside the terms of the agreement may be identified.

Batch turnaround times:

If appropriate, details of any batch turnaround times, completion times and key deliverables, including times for delivery of input and the time and place for delivery of output where appropriate.

Functionality (if appropriate):

Details of the minimal functionality to be provided and the number of errors of particular types that can be tolerated before the SLA is breached. Should include severity levels and the reporting period.

Change Management:

Brief mention of and/or reference out to the organizations Change Management procedures that must be followed just to reinforce compliance. Also targets for approving, handling and implementing RFCs, usually based on the category or urgency/priority of the change, should also be included and details of any known changes that will impact on the agreement, if any.

Service Continuity:

Brief mention of and/or reference out to the organizations Service Continuity Plans, together with details of how the SLA might be affected or reference to a separate Continuity SLA, containing details of any diminished or amended service targets should a disaster situation occur. Details of any specific responsibilities on both sides (e.g. data backup, off-site storage). Also details of the invocation of plans and coverage of any security issues, particularly any customer responsibilities (e.g. coordination of business activities, business documentation, backup of freestanding PCs, password changes).

Security:

Brief mention of and/or reference out to the organizations Security Policy (covering issues such as password controls, security violations, unauthorized software, viruses etc.). Details of any specific responsibilities on both sides (e.g. Virus Protection, Firewalls).

Printing:

Details of any special conditions relating to printing or printers (e.g. print distribution details, notification of large centralized print runs, or handling of any special high-value stationery).

Responsibilities:

Details of the responsibilities of the various parties involved within the service and their agreed responsibilities, including the service provider, the customer and the users.

Charging (if applicable):

Details of any charging formulas used, charging periods, or reference out to charging policy documents, together with invoicing procedures and payment conditions etc. must be included. This should also include details of any financial penalties or bonuses that will be paid if service targets do not meet expectations. What will the penalties/bonuses be and how will they be calculated, agreed and collected/paid (more appropriate for third-party situations). If the SLA covers an outsourcing relationship, charges should be detailed in an Appendix as they are often covered by commercial in-confidence provisions.

It should be noted that penalty clauses can create their own difficulties. They can prove a barrier to partnerships if unfairly invoked on a technicality and can also make service provider staff unwilling to admit to mistakes for fear of penalties being imposed. This can, unless used properly, be a barrier to developing effective relationships and problem solving.

Service reporting and reviewing:

The content, frequency, content, timing and distribution of service reports, and the frequency of associated service review meetings. Also details of how and when SLAs and the associated service targets will be reviewed and possibly revised, including who will be involved and in what capacity.

Glossary:

Explanation of any unavoidable abbreviations or terminology used, to assist customer understanding.

Amendment sheet:

To include a record of any agreed amendments, with details of amendments, dates and signatories. It should also contain details of a complete change history of the document and its revisions.

It should be noted that the SLA contents given above are examples only. They should not be regarded as exhaustive or mandatory, but they provide a good starting point.

OPERATIONAL LEVEL AGREEMENT (OLA Sample)

This agreement is made between.................................................................and

.........................................................................

The agreement covers the provision of the support service providing..... (brief service description).

This agreement remains valid for 12 months from the (date) until (date).

The agreement will be reviewed annually. Minor changes may be recorded on the form at the end of the agreement, providing they are mutually endorsed by the two parties and managed through the Change Management process.

Signatories:

Name....................................................Position........................................Date...............

Name....................................................Position........................................Date...............

Details of previous amendments:

Support service description:

Comprehensive explanation and details of the support service being provided.

Scope of the agreement:

What is covered within the agreement and what is excluded?

Service hours:

A description of the hours for which the support service is provided.

Service targets:

The targets for the provision of the support service and the reporting and reviewing processes and frequency.

Contact points and escalation:

Details of the contacts within each of the parties involved within the agreement and the escalation processes and contact points.

Service Desk and incident response times and responsibilities:

The responsibilities and targets agreed for the progress and resolution of Incidents and support of the Service Desk.

Problem response times and responsibilities:

The responsibilities and targets agreed for the progress and resolution of Problems.

Change Management:

The responsibilities and targets agreed for the progress and implementation of changes.

Release Management:

The responsibilities and targets agreed for the progress and implementation of releases.

Configuration Management:

The responsibilities for the ownership, provision and maintenance of accurate Configuration Management information.

Information Security Management:

The responsibilities and targets agreed for the support of the Security Policy(s) and the Information Security Management process.

Availability Management:

Responsibility for ensuring that all components within their support domain are managed and supported to meet and continue to meet all of the service and component availability targets.

Service Continuity Management:

Responsibility for ensuring that all components within their support domain have up-to-date and tested recovery plans that support agreed and documented business requirements. This should include assistance with the technical assessment of risk and its subsequent management and mitigation.

Capacity Management:

Responsibility for supporting the needs of the Capacity Management process within the agreed scope of their technical domain.

Service Level Management:

Assistance with the definition and agreement of appropriate targets within SLAs, SLRs and OLAs, concerning components within the scope of their technical domain.

Supplier Management:

Assistance with the management of contracts and suppliers, again principally within the scope of their technical domain.

Provisionof information:

The provision and maintenance of accurate information, including financial data for all components within the agreed scope of their technical domain.

Glossary:

Explanation of any unavoidable abbreviations or terminology used, to assist understanding of terms contained within the agreement.

Amendment sheet:

To include a record of any agreed amendments, with details of amendments, dates and signatories. It should also contain details of a complete change history of the document and its revisions.


Appendix G: Example Service Catalogue

The Service Catalogue is key document containing valuable information on the complete set of services offered. It should preferably be stored as a set of service CIs within a CMS, maintained under Change Management. As it is such a valuable set of information it should be available to anyone within the organization. Every new service should immediately be entered into the Service Catalogue once its initial definition of requirements has been documented and agreed. So as well as the information below, the Service Catalogue should record the status of every service, through the stages of its defined lifecycle.

 
Service Name Service Description Service type Supporting services Business Owner(s) Business Unit(s) Service Manager (s) Business Impact Business Priority SLA Service hours Business Contacts Escalation Contacts Service Reports Service Reviews Security Rating
Service 1                              
Service 2                              
Service 3                              
Service 4                              
 

Table G.1 Example Service Catalogue


Appendix H: The Service Management process maturity framework

The process maturity framework (PMF) can be used either as a framework to assess the maturity of each of the Service Management processes individually, or to measure the maturity of the Service Management process as a whole. This is an approach that has been widely used in the IT industry for a number of years, with many proprietary models being used by a number of organizations. This particular PMF has been developed to bring a common, best practice approach to the review and assessment of Service Management process maturity. This framework, which is shown in Figure H.1, can be used by organizations to internally review their own Service Management processes as well as third-party organizations brought in as external reviewers, assessors or auditors.





sdamzavas.net - 2019 . ! , ...