ITIL Practical Guide - Service Operation

11,950 views
11,576 views

Published on

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.

Published in: Business, Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,950
On SlideShare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
1,385
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide
  • 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
  • ITIL Practical Guide - Service Operation

    1. 1. V3 Service Operation Finbarr Callan Lecturer, Best Practice
    2. 2. V3 Service Operation : Agenda <ul><li>Key Principles of Operation </li></ul><ul><li>Operational Activities </li></ul><ul><li>Processes </li></ul><ul><ul><li>Event Management </li></ul></ul><ul><ul><li>Incident Management </li></ul></ul><ul><ul><li>Request Fulfilment </li></ul></ul><ul><ul><li>Problem Management </li></ul></ul><ul><ul><li>Access Management </li></ul></ul><ul><ul><li>Functions </li></ul></ul><ul><ul><ul><li>Service Desk </li></ul></ul></ul><ul><ul><ul><li>Technical Management </li></ul></ul></ul><ul><ul><ul><li>Application Management </li></ul></ul></ul><ul><ul><ul><li>Operations Management </li></ul></ul></ul><ul><li>Questions </li></ul>
    3. 3. Service Lifecycle Components © Crown Copyright 2007. Reproduced with permission from OGC
    4. 4. <ul><ul><li>Managing day-to-day activities and technology </li></ul></ul><ul><ul><li>Executing processes to optimize cost and quality </li></ul></ul><ul><ul><li>Enabling the business to meet its objectives </li></ul></ul><ul><ul><li>Effective functioning of components </li></ul></ul>Service Operation : Principles
    5. 5. <ul><ul><li>T o coordinate and carry out the activities and processes required to deliver and manage services at agreed levels </li></ul></ul><ul><ul><li>Also responsible for ongoing management of the technology </li></ul></ul>Service Operation : Purpose Scope <ul><li>Services </li></ul><ul><li>Service Management Processes </li></ul><ul><li>Technology </li></ul><ul><li>People </li></ul>
    6. 6. <ul><ul><ul><li>Services run within budget and ROI targets </li></ul></ul></ul><ul><ul><ul><li>Design flaws fixed and unforeseen requirements satisfied </li></ul></ul></ul><ul><ul><ul><li>Efficiency gains achieved </li></ul></ul></ul><ul><ul><ul><li>Services optimized </li></ul></ul></ul>Value to the Business Service Operation is where the value is seen
    7. 7. Organization <ul><li>Function : a logical concept referring to the people and automated measures that execute a defined process, activity or combination </li></ul><ul><li>Group : a number of people who perform similar activities </li></ul><ul><li>Team: a more formal group </li></ul><ul><li>Department: formal organizational structure </li></ul><ul><li>Division: group of departments </li></ul><ul><li>Role: set of connected behaviours or actions performed by a person, group or team in a specific context </li></ul>
    8. 8. <ul><ul><li>Technical specialization </li></ul></ul><ul><ul><li>Activity </li></ul></ul><ul><ul><li>Process </li></ul></ul><ul><ul><li>Geography </li></ul></ul><ul><ul><li>Hybrid </li></ul></ul><ul><ul><li>Combined functions </li></ul></ul>Organizing for Service Operation
    9. 9. Operational Activities <ul><ul><li>Change Management </li></ul></ul><ul><ul><li>Configuration Management </li></ul></ul><ul><ul><li>Release and Deployment Management </li></ul></ul><ul><ul><li>Availability Management </li></ul></ul><ul><ul><li>Knowledge Management </li></ul></ul><ul><ul><li>Financial Management </li></ul></ul><ul><ul><li>IT Service Continuity Management </li></ul></ul><ul><ul><li>Capacity Management - Capacity and performance monitoring - Capacity and performance trends - Storage of capacity management data - Demand management - Workload management - Modelling and applications sizing - Capacity planning </li></ul></ul>
    10. 10. It’s all about Balance <ul><li>Focus – internal versus external </li></ul><ul><li>Focus – stability versus responsiveness </li></ul><ul><li>Focus – cost versus quality </li></ul><ul><li>Focus – reactive versus proactive </li></ul>
    11. 11. Out of Balance? <ul><li>Extreme Focus on: </li></ul><ul><li>Internal </li></ul><ul><li>Stability </li></ul><ul><li>Cost </li></ul><ul><li>Reactive </li></ul><ul><li>Extreme Focus on: </li></ul><ul><li>External </li></ul><ul><li>Responsiveness </li></ul><ul><li>Quality </li></ul><ul><li>Proactive </li></ul>
    12. 12. <ul><ul><li>Routine operational communication </li></ul></ul><ul><ul><li>Communication between shifts </li></ul></ul><ul><ul><li>Performance reporting </li></ul></ul><ul><ul><li>Communication in projects </li></ul></ul><ul><ul><li>Communications related to changes </li></ul></ul><ul><ul><li>Communications related to exceptions or to emergencies </li></ul></ul><ul><ul><li>Training for new or customized processes and service designs </li></ul></ul><ul><ul><li>Communication of strategy and design to Service </li></ul></ul><ul><ul><li>Operation teams </li></ul></ul>Service Operation : Communication
    13. 13. Event Management
    14. 14. Event Management <ul><ul><li>Scope </li></ul></ul><ul><ul><li>Value to the business </li></ul></ul><ul><ul><li>Basic concepts </li></ul></ul><ul><ul><li>Activities/techniques </li></ul></ul><ul><ul><li>Challenges </li></ul></ul>Any detectable or discernable occurrence that has significance for the management of the IT infrastructure or the delivery of IT service and Evaluation of the impact a deviation might cause to the services
    15. 15. Event Management : Objectives <ul><ul><li>To detect events, make sense of them, and determine appropriate control action </li></ul></ul><ul><ul><li>To act as a basis for automating routine Operations Management activities </li></ul></ul>The difference between the types isn’t fixed. They rely on send / receipt of a message, active versus passive monitoring. Concepts <ul><li>Informational </li></ul><ul><li>Warning </li></ul><ul><li>Exception </li></ul>
    16. 16. Events Event Management Information Warning Exception Responses Logged Auto Response Alert/ Intervention Incident Problem Change
    17. 17. Event Management
    18. 18. Incident Management
    19. 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. 20. Incident Management Process (1) © Crown Copyright 2007. Reproduced with permission from OGC
    21. 21. Incident Management Process (2) © Crown Copyright 2007. Reproduced with permission from OGC
    22. 22. Incident Management : Challenges <ul><li>Early detection ability </li></ul><ul><li>Need for logging and use of self-help </li></ul><ul><li>Availability of Problem and Known Error information </li></ul><ul><li>Integration into CMS </li></ul><ul><li>Integration into SLM process </li></ul>
    23. 23. Incident Management
    24. 24. Request Fulfilment
    25. 25. Request Fulfilment A request from a User for information, advice , or for a Standard Change or for Access to an IT Service, e.g. to reset a password or to provide standard IT Services for a new User <ul><li>Provide a regular channel for users to request and receive standard services </li></ul><ul><li>Provide information to users about service availability and access </li></ul><ul><li>Source and deliver components of standard services </li></ul><ul><li>Assist with general information, complaints or comments </li></ul>
    26. 26. Request Fulfilment
    27. 27. Problem Management
    28. 28. Problem Management <ul><li>Objectives </li></ul><ul><li>To prevent problems and resulting incidents from happening </li></ul><ul><li>Eliminate recurring incidents </li></ul><ul><li>To minimize the impact of incidents that cannot be prevented </li></ul>Problem Definition: The unknown cause of one or more incidents.
    29. 29. Problem Management Problem Manager Problem Solving Groups Concepts <ul><li>Known Errors </li></ul><ul><li>Known Error Database </li></ul><ul><li>Workaround </li></ul><ul><li>Resolution </li></ul><ul><li>Problem Models </li></ul>Process Activities <ul><li>Detection </li></ul><ul><li>Logging </li></ul><ul><li>Categorization </li></ul><ul><li>Prioritization </li></ul><ul><li>Diagnosis </li></ul><ul><li>KE Record </li></ul><ul><li>Resolution </li></ul>
    30. 30. Problem Management
    31. 31. Access Management
    32. 32. Access Management : Objectives <ul><li>Execute the policies and actions defined in Security and Availability Management </li></ul><ul><li>Provide the right for users to be able to use a service or group of services </li></ul>
    33. 33. Access Management <ul><li>Rights Management/ Identity Management </li></ul><ul><li>Grant rights to use services to authorized users </li></ul><ul><li>Prevent access to unauthorized individuals </li></ul><ul><li>Access/identity/rights </li></ul><ul><li>Request/Verify/Provide rights/Monitor status/Tracking access /Removal </li></ul>
    34. 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
    35. 35. <ul><li>Requesting access </li></ul><ul><li>Verification </li></ul><ul><li>Providing rights </li></ul><ul><li>Monitoring identity status </li></ul><ul><li>Logging and tracking access </li></ul><ul><li>Removing or restricting rights </li></ul>Access Management : Process Activities
    36. 36. Access Management
    37. 37. Access Management
    38. 38. Self-Help © Crown Copyright 2007. Reproduced with permission from OGC
    39. 39. Functions
    40. 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
    41. 41. Service Desk <ul><li>Logging all incidents/service requests, allocating categorization and prioritization codes </li></ul><ul><li>First line investigation and diagnosis </li></ul><ul><li>Resolving incidents/service requests </li></ul><ul><li>Escalation as necessary </li></ul><ul><li>Closing all resolved incidents and requests </li></ul><ul><li>Conducting customer satisfaction surveys </li></ul><ul><li>Communication with users - progress, information </li></ul><ul><li>Updating CMS as agreed and authorized </li></ul>Primary aim is to restore normal service – in the widest sense – as quickly as possible
    42. 42. Service Desk : Types <ul><li>Local </li></ul><ul><li>Centralized </li></ul><ul><li>Virtual </li></ul><ul><li>Follow-the-sun </li></ul><ul><li>Specialized </li></ul>
    43. 43. Service Desk : Local
    44. 44. Service Desk : Centralized
    45. 45. Service Desk : Virtual
    46. 46. Service Desk
    47. 47. Technical Management
    48. 48. Technical Management To help plan, implement and maintain a stable technical infrastructure to support the organization’s business processes Objective <ul><li>Custodian of technical knowledge and expertise related to managing the IT infrastructure </li></ul><ul><li>Provides the resources to support the IT management lifecycle </li></ul>Technical Management Role
    49. 49. Technical Management
    50. 50. Application Management
    51. 51. Application Management : Objectives <ul><li>To support the organization’s business processes by helping to identify functional and manageability requirements for application software </li></ul><ul><li>To assist in the design and deployment of applications </li></ul><ul><li>To assist in the ongoing support and improvement of applications </li></ul>
    52. 52. <ul><li>Contributes to the decision on whether to buy an application or build it </li></ul><ul><li>Is the custodian of technical knowledge and expertise relating to the management of applications </li></ul><ul><li>Provides resources to support the Service Management Lifecycle </li></ul>The Application Management Function:
    53. 53. Application Management
    54. 54. Operations Management
    55. 55. The IT Operations Function: <ul><li>Executes the ongoing activities and procedures required to manage and maintain the IT infrastructure so as to deliver and support IT services at the agreed service levels </li></ul><ul><li>Continually adapts to business requirements and demand </li></ul><ul><li>To maintain the ‘status quo’ to achieve stability of the organization’s day-to-day processes and activities </li></ul><ul><li>Regularly scrutinize and improve service at reduced cost, while maintaining stability </li></ul><ul><li>Swiftly applying operational skills to diagnose and resolve any IT operations failures that occur </li></ul>
    56. 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. 57. Common Service Operations © Crown Copyright 2007. Reproduced with permission from OGC
    58. 58. Operations Management
    59. 59. Service Lifecycle Components © Crown Copyright 2007. Reproduced with permission from OGC
    60. 60. Any Questions? <ul><li>V3 Service Strategy, Service Design & Service Transition Webinars – now available onDemand. </li></ul><ul><li>V2 versus V3 White Paper and Webinar - on Axios website. </li></ul><ul><li>ITIL V3 Quick Reference Guide – pocket guide & poster </li></ul><ul><li>ITSM: IT Transforms Itself into a Service . Aberdeen Group Research. Available to download, along with a complementary onDemand Webinar on the Axios website. </li></ul><ul><li>ITIL V3: The Future is Here White Paper, authored by Sharon Taylor, Chief Architect of ITIL V3. A Webinar by Sharon Taylor is also available onDemand. Both are available for download from the Axios website. </li></ul>[email_address] www.axiossystems.com Further Resources

    ×