ITIL Practical Guide - Service Operation
•Download as PPT, PDF•
36 likes•16,482 views
To view this complimentary webcast in full, visit: http://forms.axiossystems.com/LP=251 This video provides a run through of the lifecycle stage, which manages the day-to-day operation of IT services for the identification and reporting of interruptions in the delivery of services and handling of service requests at agreed levels.
![V3 Service Operation : Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ITIL Practical Guide - Service Operation
Similar to ITIL Practical Guide - Service Operation (20)
More from Axios Systems
More from Axios Systems (20)
Recently uploaded
Recently uploaded (20)
ITIL Practical Guide - Service Operation
- 1. V3 Service Operation Finbarr Callan Lecturer, Best Practice
- 3. Service Lifecycle Components © Crown Copyright 2007. Reproduced with permission from OGC
- 13. Event Management
- 16. Events Event Management Information Warning Exception Responses Logged Auto Response Alert/ Intervention Incident Problem Change
- 17. Event Management
- 19. Incident Management “ An unplanned interruption to an IT service or actual or potential reduction in the quality of service”. (Includes any event which disrupts, or could disrupt, a service) To restore normal service operation as quickly as possible and minimize the adverse impact upon business operations, thus ensuring that the best possible levels of service quality and availability are maintained
- 20. Incident Management Process (1) © Crown Copyright 2007. Reproduced with permission from OGC
- 21. Incident Management Process (2) © Crown Copyright 2007. Reproduced with permission from OGC
- 34. Access Management : Concepts Access : the level and extent of a service’s functionality or data that a user is entitled to use Identity : the information about them that distinguishes them as an individual and verifies their status within the organization Rights (privileges) : settings whereby a user is provided access – read, write, execute, change, delete Service groups : aggregation of a set of users accessing a common set of services Directory services : a specific type of tool used to manage access and rights
- 38. Self-Help © Crown Copyright 2007. Reproduced with permission from OGC
- 39. Functions
- 40. Functions Logical functions to perform specific activities and processes – not necessarily mapping onto organizational structures or individuals © Crown Copyright 2007. Reproduced with permission from OGC
- 43. Service Desk : Local
- 44. Service Desk : Centralized
- 45. Service Desk : Virtual
- 46. Service Desk
- 56. Overlaps Technical Management and Operations Management Both play a role in management and maintenance of the IT infrastructure Technical Management and Application Management Both play a role in the design, testing and improvement of CIs that form part of IT services Application Management and Operations Management Both play in role in application support
- 57. Common Service Operations © Crown Copyright 2007. Reproduced with permission from OGC
- 59. Service Lifecycle Components © Crown Copyright 2007. Reproduced with permission from OGC
Editor's Notes
- The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO
- Intentionally blank page to be completed by Training Provider with additional information if desired
- To coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers To manage the technology that is used to deliver and support services To properly conduct, control and manage the day to day operations Using the well designed and implemented processes from Service Design and Service Transition! To monitor performance, assess metrics and gather data systematically to enable continual service improvement
- SO – para 2.4.3 – important! Service value is modelled in Service Strategy The cost of the service is designed, predicted and validated in Service Design and Service Transition Measures for optimization are identified in Continual Service Improvement But this is where any value is actually realised! Until a service is operational, there is no value being delivered.
- To effect the translation of service designs into the operational environment, while controlling the risks of failure and disruption.
- See para 6.7 SO book. Pp. 146+
- In addition to being responsible for the specific processes covered in this session, Service Operation is responsible for executing many processes that are owned and managed by other areas of Service Management. The slide shows the extent to which operations become involved.
- The external view of IT is the way in which services are experienced by users and customers. They do not always understand, nor care about, the details of what technology is used to deliver or manage the services. All they care about is the service meeting their requirements (utility and warranty). The internal view is of the way the IT components and systems are managed to deliver the services. Since IT systems are complex and diverse, this often means multiple teams managing their own aspects of the total solution. They will tend to focus on achieving good performance and availability of “their” systems. Both views are relevant and necessary, but an organisation that focuses on one extreme or the other will not achieve value. To far to the right and often promises are made that can’t be met; too far to the left and expensive services delivering little customer value result.
- SO book – P. 35+
- Monitoring all events that occur through the IT infrastructure
- Closure category User satisfaction survey Documentation Ongoing or recurring incident? Formal closure Re-opening rules A workaround is a way of reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record. Timescales must be agreed for all incident handling stages – based upon agreed response times and resolution targets documented in SLAs. These must be reflected as targets within OLAs and underpinning Contracts. All support groups must be aware of these timescales and tools may be used to automate escalation. Incident models. Many Incidents recur and standard responses can be formulated to deal with them. These predefined approaches are known as incident models. Each model defines the specific steps to be taken in each instance of this incident type. Tools can be used to manage the process and ensure that a consistent approach is always followed. Major incidents represent the highest Category of Impact for an Incident. A Major Incident results in significant disruption to the Business. Special procedures need to be followed to ensure that all resources are available to deal with the incident speedily. The organisation defines what constitutes a major incident.
- The first two are largely about educating the whole community appropriately to ensure they use all the systems, processes and tools efficiently and effectively. The remainder are largely to do with the sophistication and maturity of the ITSM solution.
- Concentrates on restoring the service as quickly as possible
- Header slide
- The term service request describes varying demands placed on IT by users. Many are actually small changes – low risk, frequently occurring, low cost, etc (e.g. password reset, s/w installation on a single PC) – or information requests. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. Predefined process-flow (model) Standard changes Roles
- Header slide
- A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation. It is important to understand the distinction between Incidents and Problems. In one sense, Incidents can be viewed as symptoms of something having gone wrong. But, just as with human ailments, the symptoms may have been caused by something that at first sight is unrelated. For example, a patient goes to the doctor complaining of back pain. The pain may be caused by an injury to the back, an inherited condition, poor posture, feet problem or even a disease. The doctor may treat the symptom initially, at the same time initiating a fuller diagnosis to identify the real underlying cause. It is important to understand that not all Incidents become Problems. Problem records may be generated as a result of analysis of Events or Incidents, from proactive trend analysis, or simply be reported from a variety of sources.
- Draw (simplified) PM process, p.60 – detect/log/cat./priority (note – severity has been re-introduced fm V1!)/Inv.& diagnose/ W-around/KE/KEDB/Change/Close/post-Problem Review…………….no more Problem/Error control Severity – 4.4.5.4, p.61. Note – para 4.4.5.7 – KE records created whenever! Once the underlying cause of a problem has been identified and a workaround or permanent resolution designed, a known error record is created and stored in the Known Error Db Most problems will be unique, but there may be some that are persistent due to a underlying fault that is too expensive to resolve fully. As well as creating a known error record, a standard response for dealing with such problems may be established = models.
- Root Cause Analysis
- P.68+/SO book
- Security and Availability define policies for who is allowed to access what under which conditions. Collectively they are defining the Confidentiality, Integrity and Availability requirements/constraints for the users, services and the data. Access management is the execution level of ensuring/enforcing those policies.
- SO – p.68+
- New User workflow, granting access to Sage application via an authorisation Stage/Task
- New User workflow, granting access to Sage application via an authorisation Stage/Task
- Menu driven shopping - the key image is that of a customer being able to pick and choose from a variety of services from a menu, and then placing them in a shopping cart for check-out. NB – Self-help applies to Event/Incident/RF and Access Mgmt
- Tutor – make sure you cover Ops Control/Facilities here – no detail later. See para 6.4.1, p.126 SO book.
- Providing a single consistent way to communicate with an Organisation or Business Unit. For example, a Single Point of Contact for an IT Service Provider is usually called a Service Desk.
- They are not mutually exclusive, as a large multinational enterprise may deploy a combination of them.
- They are not mutually exclusive, as a large multinational enterprise may deploy a combination of them.
- They are not mutually exclusive, as a large multinational enterprise may deploy a combination of them.
- They are not mutually exclusive, as a large multinational enterprise may deploy a combination of them.
- Initial Agent Login
- Header slide
- To help plan, implement and maintain a stable technical infrastructure to support the organisation’s business processes through: Well designed and highly resilient, cost-effective technical topology Use of adequate technical skills to maintain infrastructure in optimum condition Swift use of technical skills to diagnose and resolve any technical failures
- Providing the actual resources required to support the ongoing operation of the IT infrastructure. Resource Manager:-
- Header slide
- Managing applications through their lifecycle – ‘Server Upgrade’ Process
- Header slide
- Intentionally blank page to be completed by Training Provider with additional information if desired
- The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO