Service Management Processes Introduction. The service management system is a system, comprised of...
-
Upload
jordan-hill -
Category
Documents
-
view
219 -
download
1
Transcript of Service Management Processes Introduction. The service management system is a system, comprised of...
Service Management Processes
Introduction
Introduction
The service management system is a system, comprised of processes, tools, and technologies working together to fulfill the goals and objectives of the service management plan and meet the demands of the customer.
The foundation of operating a service management system effectively is the measuring, control, and management of service management processes as defined by the ISO/IEC 20000 standard.
ISO/IEC 20000 Processes
Service Owner vs. Process Owner
A service owner is accountable for the delivery of a specific IT service and is responsible for continual improvement and management of change affecting services under their care.
A process owner is responsible for ensuring that the process is fit for the desired purpose and is accountable for the outputs of that process.
Service Delivery Processes
Service Level Management Service Reporting Capacity Management Service Continuity and Availability
Management Information Security Management Budgeting and Accounting of Service
6
6.1 Service Level Management
Objective:
To define, agree, record, and manage levels of service
Service Catalog
A catalog of services for each customer, showing dependencies between services and service components.
Agreements – SLAs, OLAs, UCs
Several agreements exist in a service environment:
– Service Level Agreement – an agreement between customer and service provider
– Operational Level Agreement – an agreement between one group of the service provider and another group of the service provider
– Underpinning Contracts – an agreement between the service provider and a supplier
Content of SLAs
Service Level Agreements should contain the following information, at minimum:
9
• Service description
• Service hours
• Communication: reports, schedule and frequency
• Guidelines for determining impact and priority
• Service targets
• Interruptions to services (agreed and scheduled)
• Escalation and notification process(es)
• Complaints procedure
• Workload limits (upper and lower)
• Actions or processes taken for unplanned service interruptions
• Service period (dates agreement is valid or can be changed)
• Responsibilities of customer
• Liabilities and obligations of service provider
• Financial information (i.e. charge codes)
• Change approvals
• Glossary of terms
• Related services
• Service exceptions
Service Reviews
Service and Service Level Agreements are reviewed with customer at planned intervals
Service Targets and Monitoring
Monitoring for trends and performance Identifying causes of nonconformities Identifying opportunities for improvement
Services From Other Parties
The service level management process is responsible for:
– Making agreements with customers and internal groups
– Monitoring performance against agreed service targets
– Identifying the causes of nonconformities and opportunities for improvement
13
6.2 Service Reporting
Objective: To produce agreed, timely, reliable, accurate reports for informed decision making and effective communication
14
Service reports shall be produced using information from service delivery, service management system activities, and service management processes.
Management decisions and corrective actions shall take into consideration the findings in the service reports and shall be communicated to relevant parties.
The success of the Service Management processes are dependent on the use of the information provided in service reports.
Service Reporting
15
6.3 Service Continuity and Availability Management
Objective:
To ensure that agreed service continuity and availability
commitments to customers can be met in all circumstances
Continuity and Availability Requirements
Service Continuity and Availability requirements must include (at minimum):
– Access rights to services– Service response times– End-to-end availability of services
Service Continuity Plan(s)
Service provider shall create, implement, and maintain a service continuity plan(s), which includes:
– Procedures to implement in event of major loss of service
– Availability targets– Recovery requirements– Approach for returning to normal working
conditions
Availability Plan(s)
Availability Plans must include:Availability requirementsAvailability targets
Monitoring and Testing
Service provider must ensure:– Service availability is monitored– Unplanned service outages are investigated– Plans are tested, and retested after major
changes– Test results are recorded and reviewed
20
6.4 Budgeting and Accounting
Objective: To budget and account for the cost of service provision
Budgeting and Accounting
All accounting practices used should be aligned to the wider accountancy practices of the whole of the service provider’s organization.
Policy– What objectives need to be met? What cost types? How to
apportion overheads? What rules are there to handle variances?
Budgeting– Consider seasonal factors, planned changes, variances
Accounting– Track costs to an agreed level of detail– Decisions based on cost effectiveness comparisons– Show the cost of service provision– Accounts should demonstrate over and under-spending
22
6.5 Capacity Management
Objective:To ensure that the service provider has, at all times,
sufficient capacity to meet the current and future agreed demands of the customer’s business needs
23
Capacity management shall produce, implement and maintain a capacity plan.
Capacity Management Plan
24
6.6 Information Security Management
Objective: To manage information security effectively within all service activities
25
• Create Security Policies with management approval and communicate to all relevant parties.
• Implement the controls (and document them).
• Assess impact on security controls BEFORE changes are implemented.
• Access rights (particularly for external parties).
• Investigate security incidents.
• Actions for improvement of this process
Information Security Management
Evaluating Impact on Security
Operational activities related to changes and incidents can have an unintentional impact on information security.
Information security should be a key evaluation point for assessing the appropriateness of any request for change, workaround, or resolution.
All requests for changes must be assessed to identify the risks, or changes to risks, to information security and impact on security policies and controls
The types, volumes, and impact of security incidents should be analyzed regularly to determine any opportunities for improvement.
Relationship Processes
Supplier
ServiceProvider
(The IT Organization going for ISO/IEC 20000 certification)
Business
SupplierManagement
Business RelationshipManagement
7.2 Business Relationship Management
Objective:To establish and maintain a good relationship between the
service provider and the customer based on understanding the customer and their business drivers
There shall be a
complaints process.
Business Relationship Management
29
There shall be a communication mechanism.
7.3 Supplier Management
Objective:To manage suppliers to ensure the provision of seamless, quality services
30
ISO/IEC 20000 does NOT include procurement of suppliers
Supplier Relationship Management
Part 1:There shall be a named contract manager responsible for each supplier.All service and communication processes shall be documented.All interfaces between processes shall be documented and agreed.
32
Supplier Relationship
Service Provider
)
Business
Service Provider going for ISO/IEC 20000 audit can be internal or external
SUBCONTRACTED SUPPLIER 4
LEAD SUPPLIER 1
LEAD SUPPLIER 2
LEAD SUPPLIER 3
Does the Lead supplier provider have processes to meet contractual requirements?
Does the service provider have full management control over all Service Management processes?
Resolution Processes
Incident and Service Request Management Problem Management
34
Background
Reminder:Priority is based on URGENCY and IMPACT.
Workarounds:Problem Management should develop workarounds. Incident Management should use workarounds.This data is stored in a knowledge database.
Incident Management and Problem Management are 2 SEPARATE processes!
8.1 Incident and Service Request Management
Objective: To restore agreed service to the business as soon as possible, or to respond to service requests
Incident and Service Request Management
Part 1:
• Procedures to manage ALL incidents and service requests shall be written and adopted.
• IMPACT and URGENCY shall be used to determine priority.
• Customer shall be kept informed.• All staff shall have access to relevant information,
including CMDB, known errors, problem resolutions, etc.• Progress shall be communicated to customers.• There shall be a separate process for major incidents.
Major and Security Incidents
Major and Security Incidents will often have a higher impact to the organization and required greater attention than provided by the normal procedure for incident management.
ISO/IEC 20000 requires a separate procedure for handling major incidents. The standard incident management procedure is used for security incidents but requires a priority appropriate to the risk involved.
What defines a major incident must be agreed between customer and service provider and documented. Based on the risk involved, security incidents could fall into the definition of a major incident.
Escalation
Escalation of incidents and service requests can take the form of:Functional escalationHierarchical escalation
Functional escalation is performed by the Service Desk or second-level support as part of the procedure for handling the incident or service request.
Hierarchical escalation is performed when the procedure for handling the incident or service request breaks down and requires the attention of management.
Major incidents will generally require both functional and hierarchical escalation because of the nature of the incident.
8.3 Problem Management
Objective:To minimize disruption to the business by proactive identification and analysis of the cause of incidents and by managing problems to closure.
Main focus of Part 1: Documented procedures for managing problems must
be established. Have procedures to identify, minimize, or avoid the
impact of incidents and problems Problem Management shall have a preventative
component. When changes are required pass on to Change
Management. Monitor, review, and report Problem Resolution. Keep up-to-date information on known errors available to
incident management.
Problem Management
Proactive Problem Management
Proactive Problem Management involve activities designed to seek out and resolve potential problems within the service management system and the delivered services.
The activities include analyzing data and trends on incidents and problems to identify root causes and apply preventive measures to the environment.
Trend analysis is a practice of identifying patterns within existing information which may be used to predict future behavior.
Problem Reviews
Problems reviews enable:– Improvements to problem management process,
SMS, services or other service management processes
– Prevention of a particular problem – Awareness and training related to human errors – Identifying responsible parties
Major problem reviews are performed for problems which are unresolved, unusual, or can have a significant impact to the SMS or services.
Known Errors
Known errors can come from a variety of sources, including:
– Error messages in commercial applications and systems
– Errors identified during development and testing and allowed into the production environment
– Investigations of incidents and problems
Known errors must be documented and made available to persons involved in incident management. Every known error must have a workaround or resolution associated with it.
Control Processes
Configuration Management Change Management Release and Deployment Management
9.1 Configuration Management
Objective:To define and control the components of the service andInfrastructure, and maintain accurate configuration information
Configuration Management
Part 1:• Definitions for each type of configuration item shall be
established along with appropriate procedures.• Configuration items shall be uniquely identified in
CMDB.• CMDB shall be audited at planned intervals.• CI information available to change management • Changes to CIs traceable in CMDB
Part 1 (cont’d.)• Configuration control shall ensure integrity of services
and service components.• A baseline of the appropriate configuration items
shall be taken before a release into the live environment.
• Master copies of digital configuration items shall be controlled in secure physical or electronic libraries and referenced to the configuration records, e.g. software, testing products, support documents.
• Define the interface to financial asset accounting.
Configuration Management – Shall
9.2 Change Management
Objective:To ensure all changes are assessed, approved, implemented, and reviewed in a controlled manner
Change Management Policy
The Change Management Policy defines:What configuration items are controlled by the change management processThe criteria for determining major impact of changes to services or the customer
Requests for Change
Part 1 of standard requires:– A documented procedure for recording,
classifying, assessing, and approving requests for change
– Requests for change must be raised for all changes to a service or service component
– Requests for change must have a defined scope
Change Management – Review
Has the planning been met? Has the impact been correctly estimated? Has the usage of resources been correctly estimated? Has the right effect of the change been reached? Are the users satisfied with the result? Number of incidents on the change Were/are there unexpected side effects? Have detected anomalies been communicated to the
CAB for future changes?
Change Schedule
A change schedule:– Contains details of approved changes and their
deployment dates– Used to communicate changes to interested
parties– Used in planning deployment of changes and
releases
9.3 Release Management
Objective:To deliver, distribute, and track one or more changes in a release into the live environment
Release Management
Part 1:
• Policy shall state the frequency and type.• Deployment of new or changed services and service
components shall be planned, including reversals and remedies due to failure.
• Emergency release shall be defined.• Releases shall be tested before deployment.• Acceptance criteria is established.• The process shall include reversal and remedies.• Integrity of hardware and software is maintained.• Measure success and failure.
The Toolkit
The Toolkit is designed to be holistic and comprehensive to ISO/IEC 20000. The parts of the standard provide guidance on what to implement, not how to implement the standard: where the standard lacks in this area, the toolkit will attempt to complete.
The goal of the ISO/IEC 20000 Toolkit is to define the contributing factors, major components, and their relationships as defined by the ISO/IEC 20000 , while providing the basic tools to take action based on the organization’s needs.
Moving Forward
The presentations found within the Toolkit provide education about the different facets of ISO/IEC 20000: they can be used for self-edification or as the foundation for presenting a case to different levels of the organization.
The process document, Developing Service Management Processes, is intended to be a step by step guide in developing the processes required in your organization based on the ISO/IEC 20000 standard. Multiple templates have been created to support the process and aid organizations in their efforts to improve their capabilities.