Introduction to ITSM and ITIL

Introduction to ITSM and ITIL
January 2012 Introducing: IT Service Management and ITIL Welcome! We’re here for an important purpose, so please refrain from cell phone and laptop use during this session. Session is scheduled for 90 hours, but shouldn’t take that long, so we’re not going to plan any official breaks. Introductions ITIL® is a Registered Trade Mark of the Cabinet Office in the United Kingdom. The trade mark symbol should be inferred wherever the term “ITIL” appears in these materials. Harvard University IT

January 2012 Agenda Why are we here? IT Service Management Concepts IT Service Management Benefits The ITIL Framework Key ITSM Processes for HUIT Process Unification and Roadmap Initial question: How many attendees have previously attended ITIL training? These are the main points we will cover today. Might be a review for some, might be new for others. This session is just an introduction, the first step in the process. Goal is to hit the high points, create some common ground and language , and let people know what’s coming next. This not a new thing, we are already utilizing many of these concepts throughout the organization. Agenda Harvard University IT

January 2012 Why are we here? Why are we here? Because HUIT management recognizes the value of IT Service Management as a framework for delivering our services. This video is a message from Anne and other HUIT leaders about the importance of IT Service Management and this training program. So we are here today to talk about IT Service Management or ITSM. Follow-up with brainstorm activity 3-5 minutes what are our current pain points? Relate subject matter throughout presentation back to these pain points Why are we here? Harvard University IT

January 2012 IT Service Management IT Service Management (ITSM) is a process-based approach to aligning IT services with the needs of the university. Industry-developed and accepted best practice Focused on delivering services effectively and efficiently Well-established in Higher Education The red exclamation mark is used to identify key terms and concepts throughout the presentation. ITSM is an approach that leverages industry-developed and accepted best practices to deliver IT services effectively and efficiently It is now well-established in higher education. Other schools are doing IT service management, including: Yale, Brown, Cornell, BU, BC, Duke, and Notre Dame The national Higher Education ITSM special interest group includes 900+ members. HUIT management sees the value in ITSM, and is making a significant investment in it . Why are we here? Harvard University IT

HUIT’s mission Mission
January 2012 HUIT’s mission Mission To assure Harvard’s leadership in IT, we strive to: Make it easier for faculty, students, and staff to teach, research, learn, and work through the effective use of information technology. Why is HUIT here? Our is mission is to make it easier for faculty, students, and staff to teach, research, learn, and work through the effective use of information technology. Harvard’s Goals or the ‘business’ of Harvard is: Teaching Learning Research How do we enable teaching, learning and research? Why are we here? 5

How do we enable Harvard’s business goals?
Introduction to ITSM and ITIL January 2012 How do we enable Harvard’s business goals? Every one of us plays an important role in facilitating outcomes that support Harvard’s goals. For example a faculty member teaches a student in another country, a student registers for a course, scientist uses microscopic imagery, YOU get paid. These are all outcomes that support Harvard’s goals of teaching, learning, and researching. What are some examples of outcomes that we are facilitating? What Harvard goals (teaching, learning, research) do these outcomes support? <Solicit examples from attendees.> HUIT achieves these outcomes by providing services. IT Service Management concepts Harvard University IT

ITIL® Version 3 Awareness - Walgreens
August 2009 What are services? Services are a means of delivering value to customers by facilitating outcomes customers want to achieve without taking on the ownership of specific costs and risks. ‘People do not want quarter-inch drills. They want quarter-inch holes.’ Professor Emeritus Theodore Levitt, Harvard Business School Services are a means of delivering value to customers by facilitating outcomes customers want to achieve without taking on the ownership of specific costs and risks. How many people want to run their own, wells or power plants? Satellite TV system? No one does. They want flushing toilets or a warm bath or a warm lit house. They want the OUTCOME but they don’t want to worry about everything require to make the outcome happen. That is why they purchase Services. <Solicit examples><Focus on the outcomes not the means><small group table discussions> Payroll Examples Examples HUIT provides service to facilitate outcomes. Online course video is a service we provide that enables a faculty member to teach across borders independent of time. So what do you need to provide a service? You need people, partners, products and process. IT Service Management concepts Third Sky, Inc. Proprietary & Confidential 7

What goes into providing a service?
Introduction to ITSM and ITIL January 2012 What goes into providing a service? + = People & Partners Products (Technology) What do we mean by “People, Partners, Products, and Process”? Consider an orchestra people and partners are represented by the musicians The products are the instruments Without any process, you get this: <play audio clip of warm up> Process is the score that transforms a cacophony into a symphony <play other audio clip> Beautiful music is the outcome. Without PROCESS, we will be less successful at producing the outcomes that our customers want. So what is process? IT Service Management concepts Harvard University IT

What goes into providing a service?
Introduction to ITSM and ITIL January 2012 What goes into providing a service? + = People & Partners Products (Technology) + = What do we mean by “People, Partners, Products, and Process”? Consider an orchestra people and partners are represented by the musicians The products are the instruments Without any process, you get this: <play audio clip of warm up> Process is the score that transforms a cacophony into a symphony <play other audio clip> Beautiful music is the outcome. Without PROCESS, we will be less successful at producing the outcomes that our customers want. So what is process? Process IT Service Management concepts Harvard University IT

January 2012 What is process? A Process is a structured set of activities designed to accomplish specific objectives Takes one or more inputs and turns them into outputs Includes roles, tools, and management controls Governance, Controls & Feedback Capabilities Resources Activities Inputs Outputs Key term A Process is a structured set of activities designed to accomplish specific objectives. Processes are standardized, consistent and repeatable. A process has one or more inputs, conducts certain activities to the input and has one or more outputs. For example: An Input = Customer calls the Service Desk with an issue Activities = logging, prioritization, diagnosis, troubleshooting. Outputs = a resolved customer issue, OR an escalated ticket, OR a change request. Other examples? The process is standardized, so the customer experience is consistent regardless of who they are or who they talk to at the Service Desk. IT Service Management concepts Harvard University IT

Process Maturity Optimized Quantitative Standardized Prescribed Ad hoc
4/13/2017 Process Maturity Ad hoc Prescribed Standardized Quantitative Optimized Process is not a “Set it and forget it”-type tool. Process evolves and matures over time. One of the tenets of ITSM is that it’s a journey, not a destination. At the bottom of the process maturity scale – called initial, chaotic, unstructured – are the IT organizations characterized by heroes, silos and small boxes. Their heroes spend 95% of their effort fighting fires. In the middle of the maturity scale, IT is a service provider to the business. They provide services that the business wants and needs – they are “aligned” with the business. IT deliver services effectively At the top end of the maturity scale – IT is in the service business, the high-tech products business. IT is a strategic part of the business of the enterprise. In the (few!) organizations that have very high levels of maturity around their major ITSM processes, IT people only spend 5% of their time dealing with unplanned work. <Stress Continuous improvement> Two notes on CMMI Maturity model takes time Moving up the scale represents cost – so we need to optimize/right-size Proposed near-term (depending on the TIPA: Incident & Change at 2, with longer term target of 3 Others at 2 – service catalog & problem, potentially release and others.

As processes mature, IT is transformed
Introduction to ITSM and ITIL January 2012 As processes mature, IT is transformed From: Reactive System oriented Organizational silos Disparate approach Best efforts Ad hoc improvement To: Proactive Service oriented Accountability across teams Consistent approach Predictable quality Metrics-based continuous improvement As processes mature, our IT organization improves. HUIT shifts from a fire fighting mode to a fire prevention mode Our efforts are spent being proactive We focus on services that achieve the right business outcomes Accountability for those services becomes clear Delivery of those services becomes consistent Service quality improves and is predictable Opportunities for improvement are more easily identified through measuring and reporting IT Service Management concepts Harvard University IT

HUIT ITSM Awareness August 2009 IT Service Management IT Service Management (ITSM) is a process-based approach to aligning IT services with the needs of the university ITSM involves a paradigm shift: From managing IT as stacks of individual components, groups and technologies To focusing on the delivery of end-to-end services So as a reminder, IT Service Management is focused on using and maturing processes to allow us to effectively deliver services that are aligned with Harvard’s goals Review slide concepts to this point, Goals  Services  People, Process, Technology  Process  Process Maturity  ITSM IT Service Management concepts Third Sky, Inc. Proprietary & Confidential

ITSM processes span all IT service areas
Academic Technology Administrative Technology Infrastructure IT Security Support Services Providing quality end-to-end services is something that involves all service areas within HUIT. <click> Just as Project management, Risk Management, Development Lifecycles, Security Policies and Quality Assurance practices, apply to all service areas so does IT Service Management bridge across technology and organizational silos to effect a repeatable, predictable, end-to-end delivery of quality services. So, that is an overview of WHAT IT Service Management is. Now let’s talk about some of the benefits of using IT Service Management. Project Management Risk Management Development Lifecycles IT Service Management IT Service Management concepts 14

ITSM provides Operational benefits
Introduction to ITSM and ITIL January 2012 ITSM provides Operational benefits Dimension Median Reduction Overall IT support costs 16% Failed changes 15% Recurring incidents 7% User downtime 10% Incident resolution time 28% Recovery time after disaster 40% A 2008 study of 55 companies and government organizations found measureable operational improvements after implementation of ITSM Costs were reduced, there were fewer failed changes, incidents were resolved faster. These are tangible benefits that improve the customer experience. 2008 Research Study Conducted by Glomark-Governan IT Service Management benefits Harvard University IT

ITSM provides Individual benefits
Introduction to ITSM and ITIL January 2012 ITSM provides Individual benefits Clearer responsibilities and expectations More targeted training More productivity and satisfaction Improved reputation and visibility of IT staff Professional development A well-designed and documented process makes it easier for all participants to know and understand expectations Clear definition and designation of roles and responsibilities allows for targeted training Individual success leads to organizational success, which facilitates more opportunities for individual success. It’s a cycle. ITSM is not going away. As of 2010, 50% of organizations polled by Gartner have implemented ITSM, up from 25% in Expertise and experience lead to more opportunities for growth. <solicit other examples of individual benefits> IT Service Management benefits Harvard University IT

The core principles of ITSM align with HUIT’s values
Introduction to ITSM and ITIL January 2012 The core principles of ITSM align with HUIT’s values HUIT Value User-focused Collaborative Innovative Open IT Service Management facilitates alignment with our HUIT values: By aligning our services and outcomes with the goals of the business, we are user-focused. By developing a common language and common tracking systems we promote collaboration. By committing to continuous improvement and service strategy, we encourage innovation By proactively communicating with our customers and users we are open IT Service Management benefits Harvard University IT

So how are we going to “do” ITSM?
Introduction to ITSM and ITIL January 2012 So how are we going to “do” ITSM? ITSM Frameworks There are many industry accepted ITSM frameworks. HUIT will be developing ITSM process using the most widely implemented and comprehensive framework: ITIL – or IT Infrastructure Library. Aberdeen Group 2008 The ITIL framework Harvard University IT

January 2012 What is ITIL? Information Technology Infrastructure Library (ITIL) is a best-practice framework for IT Service Management Globally recognized Evolving and flexible ITIL provides guidance on delivering the right end-to-end services efficiently and effectively using well-defined and repeatable processes ITIL is one framework or set of practices in ITSM, and it’s the ITSM framework that is the most widely used. It was developed by the UK Government in the 1980s to control escalating costs in civil service IT. Globally recognized: Over 80 percent of industry implementations of IT Service Management make use of the ITIL framework It’s evolving: ITIL is now on update version 3. As ITSM best practices are identified, ITIL is updated to include them. Flexible: It is a FRAMEWORK, not a METHODOLOGY. There is no one-size-fits-all blueprint. The goal is to “Adapt and adopt”. ITIL provides guidance for managing services throughout their entire lifecycle, from conception to retirement. ITIL organizes service management processes into life-cycle stages. The ITIL framework Harvard University IT

The ITIL service lifecycle
Introduction to ITSM and ITIL January 2012 The ITIL service lifecycle The ITIL Service Lifecycle is a five-stage holistic view of the interconnected processes that make up service management Continual Service Improvement Service Transition Service Transition Service Validation & Testing Release & Deployment Management Svc Asset & Config Management Change Management Change Evaluation Transition Planning & Support Knowledge Management Service Design Supplier Management Service Continuity Management Service Catalog Management Information Security Management Availability Management Capacity Management Service Level Management Design Coordination Continual Service Improvement 7-Step Improvement Process Service Strategy Strategy Mgt. for IT Services Financial Management Demand Management Service Portfolio Management Business Relationship Management Service Operation Problem Management Operational Activities of other lifecycle phase processes Event Management Incident Management Access Management Request Fulfillment Service Operation Service Strategy Fundamental ITIL concept! <click> Service Strategy: These are the processes that help us determine WHAT services we should we offer based on business priorities and customer needs. They also help us ensure that we are prepared to handle the costs and risks associated with the services. <click> Service Design: These processes identify HOW the services will be provided. The Design stage ensures that the services meet the specific business, capacity, and technical needs of the business. <click> Service Transition: We use these processes to put new services or service updates into production. Service Transition ensures that risks to the existing environment are minimized, and that testing, training, documentation, and support needs are met. <click> Service Operation: These processes help us deliver ongoing, stable services as expected, required, and promised to the customers. Service Operation includes both service delivery and service restoration. <click> Continual Service Improvement: Throughout the lifecycle, we are always looking for opportunities to improve both our services and our processes Service Design The ITIL framework © Crown copyright 2007 Reproduced under license from OGC Harvard University IT

Initial HUIT process focus
Introduction to ITSM and ITIL January 2012 Initial HUIT process focus Service Strategy Service Design Continual Service Improvement Strategy Mgt. for IT Services Financial Management Supplier Management Service Continuity Management Information Security Management Demand Management Service Catalog Management Availability Management Capacity Management Service Portfolio Management Business Relationship Management Design Coordination Service Level Management Service Portfolio / Catalog Configuration Management System (CMS) Event Management Incident Management Request Fulfillment Config Management Change Management Transition Planning & Support This is the complete chart of all the ITIL version 3 processes. Taken as a whole, it can be overwhelming, but remember that a philosophy of ITIL is “ADAPT and ADOPT”. We’re not going to try boiling the ocean. We can start with a scope that makes sense within the HUIT organization. Those of you that are going on to ITIL foundations training will learn about all of these processes in more detail. For today’s session, we are just going to go over the five highlighted processes, which will be HUIT’s initial focus: Service Catalog Request Incident Change Problem Mgmt will focus on after Incident management Access Management Problem Management Operational Activities of other lifecycle phase processes Change Evaluation Service Validation & Testing Release & Deployment Management Knowledge Management 7-Step Improvement Process Service Operation Service Transition The ITIL framework Harvard University IT

Service Catalog Management
Service Design Stage ITIL® Foundation Course Service Catalog Management The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services (and those being prepared to be run operationally), and to ensure that it is widely available to those who are authorized to access it. Definition: Service Catalog The service catalog is a database or structured document with information about all live IT services, including those available for deployment. A Service Catalog is a detailed account of all the services IT provides to its customers. In many ways a service catalog is very similar to a menu in a restaurant or shopping for a cell phone online; you have to pick your contract, data plan, phone and accessories to request your wireless service . Customers can pick and choose what IT Services they need and request them. IT can also package certain services together to make multiple requests easier, such as onboarding a new employee. HUIT has their first version of a service catalog available at as an example. Having a service catalog provides value to our customers by ensuring a common understanding of what IT services are available to them and using the service catalog as a marketing and communication tool. It also improves knowledge, alignment and focus on each service that IT provides. HUIT is striving to improve our service catalog on the HUIT website over the coming year. Key ITSM processes for HUIT SD 4.2 SD 4.2.1 SD 4.2.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 22

Service Operation Stage
ITIL® Foundation Course Request Fulfillment Request Fulfillment is the ITIL process responsible for managing the lifecycle of all service requests from the users. The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT Department by the users. A Service Request may be a request from a User for: Information, advice or training a application feature or enhancement access to an IT Service Examples: Reset a password Onboard a new user into the IT service environment & Calendar provisioning, New Computer, Phone, PIN, FAS || UIS systems accounts A service request is the generic description we use to describe the many demands for services we receive from our customers. A service request can be anything from a request for information or training, to provisioning a new server or network .A service request can be initiated from the service catalog or other web-based application ,a call to the service desk or from our partners. They can come from anywhere. The role of Request Fulfillment is to manage the lifecycle of service requests. It is responsible for managing all the processes and procedures the it takes to fulfill a request. Ideally , because every service we offer should have a finite amount of ways that a user can request access to, information about or changes to that service, each service request would have a standardized and repeatable procedure to fulfill it. Some of these procedures could be completely automated, some might require budgetary or access approval. We will talk about incidents in the next slide, but we should take care not to confuse service requests as low priority incidents. Service requests should have defined procedures to fulfill them that are triggered by the request, where as incident do not .Service Requests can have there own priorities separate from incidents, we CAN have a high priority service request, for example an emergency mass message or Drew Faust requests an iPad. What are some other examples of service requests? <solicit examples form the audience> Key ITSM processes for HUIT SO 4.3 SO 4.3.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 23

ITIL® Foundation Course Incident Management An Incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service The purpose of incident management is to restore normal service operation as quickly as possible Incident Management is not too concerned with finding the root cause of an incident (see Problem Management) Increase visibility and communication of incidents to business and IT support staff Enhance business perception of IT through use of a professional approach in quickly resolving and communicating incidents when they occur Align incident management activities and priorities with those of the business Maintain user satisfaction with the quality of IT services. Incident Management is the process for dealing with all incidents. An incident is anything that was working and is not anymore or not working as it should anymore. This differs from a service request which a customer is requesting something new or access to an IT Service. Can anybody give me an example of an Incident versus a Service Request? <Solicit examples from class> The purpose of incident management is to restore service to normal, or as expected, as quickly as possible. While we are restoring service it is imperative we keep our customers updated to the status of their incidents, maintain transparency and visibility to the process and prioritize incidents to the needs of the business. Incident management is not required to discover the underlying or root cause of an incident. That is the role of Problem Management, which be covered later in this presentation. Key ITSM processes for HUIT SO 4.2 SO 4.2.1 SO 4.2.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 24

January 2012 Major Incidents Some incidents will affect one or more services in a way that has major impact for the business. ITIL classifies these as Major Incidents. A separate procedure, with shorter timescales and greater urgency, and communication plans must be used for ‘major’ incidents. "Houston, we have a Major Incident” When a service critical to a Harvard business processes is interrupted, many people need to know about it: Business process owners (Customers) whose work the service supports IT Service owners who provide the service to the business The Service Desk and distributed support people close to the users The Incident Manager coordinates the Major Incident Process A major incident is the same as a regular incident but has significant impact to the business. Major incident has greater urgency and a reduced timeline in which it needs to be resolved. A separate incident process is used while working towards the resolution of a major incident coordinated by an Incident Manager. A separate major incident team maybe called upon to focus solely on the resolution of a major incident. We effectively communicate the nature of the interruption and who is impacted: Phone, , Web Postings, In Person, Harvard Alert Systems. We communicate to the impacted users to be courteous, proactive, set expectations and get feedback. A Major Incident is not the same as a problem. People sometimes use loose terminology and/or confuse a major incident with a problem. In reality, an incident remains an incident forever – it may grow in impact or priority to become a major incident, but an incident never ‘becomes’ a problem. A problem is the underlying cause of one or more incidents and remains a separate entity. (Actually what Apollo 13 had was an incident – a major incident, but not a problem) Key ITSM processes for HUIT Harvard University IT

ITIL® Foundation Course Problem Management A problem as the underlying cause of one or more incidents. The purpose of problem management is to manage the lifecycle of all problems from first identification through further investigation, documentation and eventual removal. Minimize the adverse impact of problems to the business Proactively prevent recurrence of incidents related to problems Investigate root cause and document known errors, and workarounds Communicate known errors and workarounds to support staff to resolve incidents faster Correction of problems often involve a request for change to the service requested Problems are the root cause of one or more incidents. Problem Management manages the identification, investigation, documentation, and removal of problems. Some examples of incidents and problems might be: A firewall has failed several times (incidents), resetting the FW restores service quickly, but after further troubleshooting a bug in the OS has been discovered (the problem), this is documented as a known error with the workaround being to reset the FW. When the bug is corrected by the vendor, applying that patch requires a request for change the removes the problem and the known error. Can you think of other incident/problem examples? <solicit examples from the audience> It is important to communicate with support staff during problem management, the can link additional incidents during the investigation phase, and resolve incidents faster if known errors and workarounds are communicated to them. Key ITSM processes for HUIT SO 4.4 SO 4.4.1 SO 4.4.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 26

Service Transition Stage
ITIL® Foundation Course Change Management The purpose of the change management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. A Change is defined as the addition, modification, or removal of anything that could have an effect on IT Services Changes are made for a variety of reasons and in different ways – for example: Proactively, e.g. when organizations are seeking business benefits such as reduction in costs, improved services or increased ease and effectiveness of support Reactively as a means of resolving errors and adapting to changing circumstances. Changes should be managed in order to: Optimize risk exposure (supporting the risk profile required by the business) Minimize the severity of any impact and disruption Achieve success at the first attempt Ensure that all stakeholders receive appropriate and timely communication about the change so that they are aware and ready to adopt and support the change. Such an approach will improve the bottom line for the business by delivering early realization of benefits (or removal of risk) while saving money and time. That ends our overview of the ITIL processes that will be part of HUIT’s initial focus. Are there questions before we move on to Next Steps? Key ITSM processes for HUIT ST 4.2 ST 4.2.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 27

The ITSM Unification Project Has Begun
Introduction to ITSM and ITIL January 2012 The ITSM Unification Project Has Begun The ITSM Unification project will find ways to make our existing processes and new processes work together to achieve our common goals. Deliverables will include: Request Management Incident Management Problem Management Change Management Enterprise Tool Selection HUIT website & Service Catalog It’s important to be clear that the ITSM Unification project is not intended to be the only way that HUIT implements and improves process. One of the primary goals of this Awareness training is to get people thinking about and identifying opportunities for collaboration and improvement. For example Service Catalog improvement will be happening as part of the website improvement project. Process unification and roadmap Harvard University IT

ITSM Unification Roadmap

January 2012 Training schedule HUIT ITSM Awareness (1 ½ hours) Tue. May 22 at 1:00 Tue. May 22 at 3:00 Thu. Jun. 21 at 9:00 Thu. Jun. 21 at 2:30 ITIL® 2011 Foundations (3-day, exam on 4th day) May 14 – 16 May 29 – June 1 June 11 – 13 June 25 – 28 July 9 – 12 Oct 1 – 3 (tentative) Nov 12 – 14 (tentative) Dec 3 – 5 (tentative) ITIL Intermediate (subsidized by HUIT) Release, Control & Validation (TBD) Operational Support & Analysis (TBD) ½ Day ITSM Overview (TBD) HUIT Awareness classes are intended for everyone in HUIT and is Mandatory ITIL Foundations is a 3-day course intended to teach the basics of the entire ITIL framework. There is an optional certification exam at the end of the session. This class is intended for service owners, process owners and managers, managers and directors but anyone is welcome. Please coordinate with your group and your manager, before registering for a course. Process unification and roadmap Harvard University IT

January 2012 We need your help! Additional ITSM training ITIL Foundations Advanced ITIL Certifications ITSM Unification Project participation Service Catalog refinement Input to ITSM and project teams Core teams and subteams ITSM contact information: HUIT Intranet ( As Anne mentioned during the video at the beginning of this session, it is important that people get involved in our ITSM efforts. We encourage interested staff to attend further training and contact the ITSM team if you’d like to become more involved or if you are aware of opportunities for improvement or collaboration. Process unification and roadmap Harvard University IT

January 2012 Q & A Harvard University IT

Thank you for attending!

January 2012 Appendix Harvard University IT

Purpose and objectives
Introduction to ITSM and ITIL January 2012 Purpose and objectives ITIL usually defines a Purpose and some Objectives for each process The Purpose of a process is the overall reason for carrying out the activities defined in each process. It defines the business-focused outcome obtained by following the process. It answers the question “Why do we have this process?” The Objectives of a process define, at a high level, the activities and targets that the process involves. They answer the question “What do we do in this process?” 35 Harvard University IT

Service Design Stage ITIL® Foundation Course Service Catalog Management The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services (and those being prepared to be run operationally), and to ensure that it is widely available to those who are authorized to access it. The objectives of Service Catalog Management are: To manage the information contained within the Service Catalog To ensure that the service catalog is accurate and reflects the current details, status, interfaces and dependencies of all services that are being run, or being prepared to run, in the live environment, according to the defined policies Ensure that the service catalog is made available to those approved to access it in a manner that supports their effective and efficient use of service catalog information Ensure that the service catalog supports the evolving needs of all other service management processes for service catalog information, including all interface and dependency information. Process Scope The scope of the service catalog management process is to provide and maintain accurate information on all services that are being transitioned or have been transitioned to the live environment. The services presented in the service catalog may be listed individually or, more typically, some or all of the services may be presented in the form of service packages (see ITIL Service Strategy for information about service packages). 36 SD 4.2 SD 4.2.1 SD 4.2.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 36

The service catalog management process covers: Contribution to the definition of services and service packages Development and maintenance of service and service package descriptions appropriate for the service catalog Production and maintenance of an accurate service catalog Interfaces, dependencies and consistency between the service catalog and the overall service portfolio Interfaces and dependencies between all services and supporting services within the service catalog and the CMS Interfaces and dependencies between all services, and supporting components and configuration items (CIs) within the service catalog and the CMS. The service catalog management process does not include: Detailed attention to the capturing, maintenance and use of service asset and configuration data as performed through the service asset and configuration management process (see ITIL Service Transition) Detailed attention to the capturing, maintenance and fulfillment of service requests as performed through request fulfillment (see ITIL Service Operation). 37

ITIL® Foundation Course Request Fulfillment Request Fulfillment is the ITIL process responsible for managing the lifecycle of all service requests from the users. The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT Department by the users. A Service Request may be a request from a User for: information or advice, a Standard Change access to an IT Service. Examples: reset a password (where not self service) Onboard a new user into the IT service environment /calendar provisioning Computer Phone PIN FAS || UIS systems Accounts An examples Reset password (IDM) Server Provisioning, On boarding a new users (accounts, computer, access, etc.) Visuals Request Fulfillment Process ITIL V3 Book says: “ The term ‘service request’ is used as a generic description for many different types of demands that are placed upon the IT organization by the users. Many of these are typically requests for small changes that are low risk, frequently performed, low cost etc. (e.g. a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment) or may be just a request for information. Their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal incident and change management processes. “ Effective request fulfilment has a very important role in maintaining end user satisfaction with the services they are receiving and can directly impact how well IT is perceived throughout the business. Talking points: A request is different from an Incident. In an incident, something the user had or used is no longer doing what was intended. In a request, the user is asking for something new to them – a service, an asset, some information. Don’t think of requests as being a low-priority incidents. They are different things and have different actions taken to resolve them. - Some requests can be pretty high priority! What would be an example? Suggestion: getting Drew Faust a new iPad! Come back to this example when discussing Service Level Management – why is she high priority? Role based service levels and escalations. - Some requests are actually small Changes. There is overlap between Change Management and Request Fulfillment. - A Service Desk is empowered to fulfill a set of approved requests without involving their management or the Change Management process. 38 SO 4.3 SO 4.3.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 38

Request Fulfillment Objectives
Service Operation Stage ITIL® Foundation Course Request Fulfillment Objectives The objectives of request fulfillment are: Maintain user and customer satisfaction through efficient and professional handling of all service requests Provide a channel for users to request and receive standard services for which a predefined authorization and qualification process exists Provide information to users and customers about the availability of services and the procedure for obtaining them Source and deliver the components of requested standard services (e.g. licenses and software media) Assist with general information, complaints or comments. “Provide information…” overlaps with Service Catalog Process Scope From the ITIL v3 book: The process needed to fulfill a request will vary depending upon exactly what is being requested, but can usually be broken down into a set of activities that have to be performed. For each request, these activities should be documented into a request model and stored in the SKMS. Some organizations will be comfortable letting the service requests be handled through their incident management process (and tools) – with service requests being handled as a particular type of ‘incident’ (using a high-level categorization system to identify those ‘incidents’ that are in fact service requests). Note, however, that there is a significant difference here – an incident is usually an unplanned event, whereas a service request is usually something that can and should be planned! Therefore, in an organization where large numbers of service requests have to be handled, and where the actions to be taken to fulfill those requests are very varied or specialized, it may be appropriate to handle service requests as a completely separate work stream – and to record and manage them as a separate record type. This is essential if reporting is desired that more accurately separates incidents from requests. This may be particularly appropriate if the organization has chosen to widen the scope of the service desk to expand upon just IT-related issues and use the desk as a focal point for other types of service request– for example, a request to service a photocopier or even going so far as to include, for example, building management issues, such as a need to replace a light fitting or repair a leak in the plumbing. Note that ultimately it will be up to each organization to decide and document which service requests it will handle through the request fulfillment process and which will have to go through other processes such as business relationship management for dealing with requests for new or changed services (see ITIL Service Strategy). There will always be grey areas which prevent generic guidance from being usefully prescribed. 39 SO 4.3.1 SO 4.3.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 39

ITIL® Foundation Course Request - Key Concepts Request Model – ITIL–speak for a templated approach to processing requests There is overlap with Service Catalog Management Users should be able to initiate requests for service after learning about it from the public version of the Service Catalog (to come!) Financial approval may be required in order to fulfill a request. Not just for charge-back environments. Non-standard software and hardware might need to be approved in advance. When designing the Request Fulfillment process it is advised to: Create predefined process flows and Request Models Create a standard procedure for handling specific requests Gain approval from Change Management in advance to handle “standard changes” as requests Request Models Some Service Requests will occur frequently and will require handling in a consistent manner in order to meet agreed service levels. To assist this, many organizations will wish to create pre-defined Request Models (which typically include some form of pre-approval by Change Management). This is similar in concept to the idea of Incident Models already described in the previous section, but applied to Service Requests. Menu Selection Request Fulfillment offers great opportunities for self-help practices where users can generate a Service Request using technology that links into Service Management tools. Ideally, users should be offered a ‘menu’-type selection via a web interface, so that they can select and input details of Service Requests from a pre-defined list –where appropriate expectations can be set by giving target delivery and/or implementation targets/dates (in line with SLA targets). Where organizations are offering a self-help IT support capability to the users, it would make sense to combine this with a Request Fulfillment system as described. Specialist web tools to offer this type of ‘shopping basket’ experience can be used together with interfaces directly to the back-end integrated ITSM tools, or other more general business process automation or Enterprise Resource Planning (ERP) tools that may be used for management of the Request Fulfillment activities. Financial approval One important extra step that is likely to be needed when dealing with a service request is that of financial approval. Most requests will have some form of financial implications, regardless of the type of commercial arrangements in place. The cost of fulfilling the request must first be established. It may be possible to agree fixed prices for ‘standard’ requests – and prior approval for such requests may be given as part of the organization’s overall annual financial management. In all other cases, an estimate of the cost must be produced and submitted to the user for financial approval (the user may need to seek approval up their management/financial chain). If approval is given, in addition to fulfilling the request, the process must also include charging for the work done–if charging is in place. 40 SO Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 40

ITIL® Foundation Course Incident Management An Incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service, Incident Management is the process for dealing with all incidents The purpose of incident management is to restore normal service operation as quickly as possible Incident Management is not too concerned with finding the root cause of an incident. That is the purpose of Problem Management (coming up!) Incident Management Objectives The objectives of Incident Management are to: Ensure that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, on-going management and reporting of incidents Increase visibility and communication of incidents to business and IT support staff Enhance business perception of IT through use of a professional approach in quickly resolving and communicating incidents when they occur Align incident management activities and priorities with those of the business Maintain user satisfaction with the quality of IT services. 41 SO 4.2 SO 4.2.1 SO 4.2.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 41

Incident Management cont.
Process Scope Incident management includes any event which disrupts, or which could disrupt, a service. This includes events which are communicated directly by users, either through the service desk or through an interface from event management to incident management tools. Incidents can also be reported and/or logged by technical staff (if, for example, they notice something untoward with a hardware or network component they may report or log an incident and refer it to the service desk). This does not mean, however, that all events are incidents. Many classes of events are not related to disruptions at all, but are indicators of normal operation or are simply informational. An Incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service, or a failure of a configuration item that has not yet impacted an IT service. For example one disk in a RAID array. It doesn’t cause an interruption but will affect performance, and if left unhandled, will eventually lead to an interruption when another disk in the array fails. Incident Management is the process for dealing with all incidents 42

Incident Management cont.
The purpose of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that agreed levels of service quality are maintained. ‘Normal service operation’ is defined as an operational state where services and CIs are performing within their agreed service and operational levels. Example: field technicians are basically in the business of Incident Management. Their job is to restore normal service operation – which may involve some troubleshooting. However the overriding imperative is to restore service. Recently a batch of Dell desktops started blue screening. Details were not known but it started after a Windows Update, and evidence pointed to the graphics card drivers. One tech was assisting a VIP who was having this problem. Running out of time and unable to correct the problem in software, he swapped the graphics card for an older one, installed its driver and returned the machine to its user. He succeeded in restoring the normal service. Doing detailed troubleshooting can come later when the user is back up and running. ‘Normal service operation’ is defined as an operational state where services and CIs are performing within their agreed service and operational levels. 43

Major Incident Process
Introduction to ITSM and ITIL January 2012 Major Incident Process Coordinating response to a MI is the job of the Incident Manager Same basics as any incident: Identification, Logging, Categorization, Prioritization, Diagnosis, Incident Escalation (Functional and Hierarchic), Investigation and Diagnosis, Resolution and Recovery, Incident Closure We communicate to the impacted customers or users and responsible Service Owners and their management at more stages. FAS has a defined procedure for which services are handled by the MI process Other services have defined notification and escalation procedures. The Incident Manager is the role responsible for coordinating the Major Incident response 44 Harvard University IT

Incident Management Activities
Service Operation Stage ITIL® Foundation Course Incident Management Activities Incident Identification Detection from users and event monitoring tools; Early detection is key! Incident Logging Log 100% of Incidents Incident Categorization Example: Hardware->Server->Memory board->Card failure Incident Prioritization Relative Importance to the business Initial Diagnosis Discovery of the full symptoms of the incident Incident Identification Work cannot begin on dealing with an incident until it is known that an incident has occurred. As far as possible, all key components should be monitored so that failures or potential failures are detected early so that the incident management process can be started quickly. Ideally, incidents should be resolved before they have an impact on users! Incident Logging All incidents must be fully logged and date/time stamped, regardless of their origin. All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained – and so that if the incident has to be referred to other support group(s), they will have all relevant information to hand to assist them. Incident Categorization Part of the initial logging must be to allocate suitable incident categorization coding so that the exact type of the call is recorded. Multi-level categorization is available in most tools – usually to three or four levels of granularity. All organizations are unique and it is therefore difficult to give generic guidance on the categories an organization should use, particularly at the lower levels. Incident Prioritization Another important aspect of logging every incident is to agree and allocate an appropriate prioritization code – as this will determine how the incident is handled both by support tools and support staff. Prioritization can normally be determined by taking into account both the urgency of the incident (how quickly the business needs a resolution) and the level of impact it is causing. Initial Diagnosis If the incident has been routed via the Service Desk, the Service Desk Analyst must carry out initial diagnosis, typically while the user is still on the telephone – if the call is raised in this way. If possible, the Service Desk Analyst will resolve the incident while the user is still on the telephone – and close the incident if the resolution is successful. © Crown copyright 2011 Reproduced under license from the Cabinet Office 45 SO 4.2.5 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 45

Incident Management Activities - Continued
Service Operation Stage ITIL® Foundation Course Incident Management Activities - Continued Incident Escalation Functional and Hierarchic Investigation and Diagnosis Troubleshooting steps to determine what has gone wrong, including searching knowledge databases (Problems, Known Errors, etc.) Resolution and Recovery Application and testing of potential resolutions Incident Closure Incident resolved to user satisfaction Leverage self-help technologies that link into Service Management tools Make the procedures for issuing a request clear and simple for users to follow Incident escalation Functional escalation. As soon as it becomes clear that the Service Desk is unable to resolve the incident itself (or when target times for first-point resolution have been exceeded – whichever comes first!) the incident must be immediately escalated for further support. The rules for escalation and handling of incidents must be agreed in OLAs and UCs with internal and external support groups respectively. Hierarchic escalation. If incidents are of a serious nature the appropriate IT managers must be notified, for informational purposes at least. Hierarchic escalation is also used if the ‘Investigation and Diagnosis’ and ‘Resolution and Recovery’ steps are taking too long or proving too difficult. Investigation and Diagnosis Each of the support groups involved with the incident handling will investigate and diagnose what has gone wrong – and all such activities) should be fully documented. This investigation is likely to include such actions as: Establishing exactly what has gone wrong or being sought by the user Understanding the chronological order of events Confirming the full impact of the incident, including the number and range of users affected Identifying any events that could have triggered the incident Knowledge searches looking for previous occurrences by searching previous records. Resolution and Recovery When a potential resolution has been identified, this should be applied and tested. The resolving group should pass the incident back to the Service Desk for closure action. Incident Closure The Service Desk should check that the incident is fully resolved and that the users are satisfied and willing to agree the incident can be closed. © Crown copyright 2011 Reproduced under license from the Cabinet Office 46 SO 4.2.5 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 46

ITIL® Foundation Course Problem Management A problem is 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. The purpose of problem management is to manage the lifecycle of all problems from first identification through further investigation, documentation and eventual removal. Problem management seeks to: minimize the adverse impact of incidents and problems on the business that are caused by underlying errors within the IT Infrastructure, and to proactively prevent recurrence of incidents related to these errors. In order to achieve this, problem management seeks to get to the root cause of incidents, document and communicate known errors and initiate actions to improve or correct the situation. The correction may involve a Request For Change to the service affected 47 SO 4.4 SO 4.4.1 SO 4.4.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 47

Problem Management Cont.
Process Scope Problem management includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially change management and release and deployment management. Problem management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. In this respect, problem management has a strong interface with knowledge management, and tools such as the KEDB will be used for both. 48

Service Transition Stage
ITIL® Foundation Course Change Management The purpose of the change management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. Changes are made for a variety of reasons and in different ways – for example: Proactively, e.g. when organizations are seeking business benefits such as reduction in costs, improved services or increased ease and effectiveness of support Reactively as a means of resolving errors and adapting to changing circumstances. Change Management Objectives The objectives of change management include: Respond to the business and IT requests for change that will align the services with the business needs. Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. Optimize overall business risk. Changes should be managed in order to: Optimize risk exposure (supporting the risk profile required by the business) Minimize the severity of any impact and disruption Achieve success at the first attempt Ensure that all stakeholders receive appropriate and timely communication about the change so that they are aware and ready to adopt and support the change. Such an approach will improve the bottom line for the business by delivering early realization of benefits (or removal of risk) while saving money and time. 49 ST 4.2 ST 4.2.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 49

Change Management The service portfolio provides a clear definition of all current, planned and retired services. Understanding the service portfolio helps all parties involved in the service transition to understand the potential impact of the new or changed service on current services and other new or changed services. Strategic changes are brought in via service strategy and the service portfolio management process in the form of change proposals. Changes to a service will be brought in via service design, continual service improvement, service level management and service catalog management. Corrective change, resolving errors detected in services, will be initiated from service operation and may route via support or external suppliers into a formal RFC. Exclusion Change management is not responsible for coordinating all of the service management processes to ensure the smooth implementation of projects. This activity is carried out by transition planning and support. The objectives of change management include: Respond to the business and IT requests for change that will align the services with the business needs. Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. Optimize overall business risk. 50

Change Management Scope
Service Transition Stage ITIL® Foundation Course Change Management Scope The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items. Each organization should define the changes that lie outside the scope of their service change process. Typically these might include: Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes Changes at an operational level such as repair to printers or other routine service components. The diagram above shows a typical scope for the service Change Management process an IT organization and how it interfaces with the business and suppliers at strategic, tactical and operational levels. It covers interfaces to internal and external service providers where there are shared assets and configuration items that need to be under change management. Change management must interface with business change management and with the supplier’s change management. This may be an external supplier within a formal change management system, or the project change mechanisms within an internal development project. 51 ST 4.2.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 51

Key Concepts Service Change
Service Transition Stage ITIL® Foundation Course Key Concepts Service Change The addition, modification or removal of anything that could have an effect on IT services. There are three different types of service change: Standard change: A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. Emergency change: A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. Normal change: Any service change that is not a standard change or an emergency change. Changes are often categorized as major, significant and minor, depending on the level of cost and risk involved, and on the scope and relationship to other changes. This categorization may be used to identify an appropriate change authority. As much use as possible should be made of devolved authorization, both through the standard change procedure and through the authorization of minor changes by change management staff. During the planning of different types of change requests, each must be defined with a unique naming convention. Standard Change: patching servers on a monthly cycle – in our case we mitigate the risk of a rogue patch by patching development servers before production servers 52 ST Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 52

Key Concepts – Change Types
Service Transition Stage ITIL® Foundation Course Key Concepts – Change Types Normal A change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process. In this process RFCs are recorded, assessed and then approved or disapproved by a Change Authority – usually a Change Advisory Board or CAB. Typical activities in managing individual changes are: Create and record the RFC Review the RFC Filter changes (e.g. incomplete or wrongly routed changes) Assess and evaluate the change Establish the appropriate level of change authority Establish relevant areas of interest (i.e. who should be involved in the CAB) Evaluate the business justification, impact, cost, benefits, risks and predicted performance of the change Submit a request for evaluation to initiate activity from the change evaluation process Authorize the change Obtain authorization/rejection Communicate the decision with all stakeholders, in particular the initiator of the request for change Plan updates Coordinate change implementation Review and close change Collate the change documentation, e.g. baselines and evaluation reports Review the change(s) and change documentation Ensure that details of lessons learned have been entered into the service knowledge management system Close the change document when all actions are completed. Throughout all the process activities listed above and described within this section, information is gathered, stored in the SKMS, recorded in the CMS and reported. © Crown copyright 2011 Reproduced under license from the Cabinet Office 53 ST 4.2.5 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 53

Normal Change Activities
Service Transition Stage ITIL® Foundation Course Normal Change Activities The figure above shows an example of a change to the service provider’s services, applications or infrastructure. Examples of the status of the change are shown in italics. Change and configuration information is updated all the way through the activities. This example shows authorization for change build and test and for change deployment. In practice there may be additional authorization steps, for example to authorize change design or change development. Further information about the need for multiple evaluation and authorization steps can be found in section of the ITIL Service Transition publication. Process flows for standard changes will be discussed next. After a change has been built and tested, and the deployment procedure has been used successfully one or more times, then it may be appropriate to use a ‘standard deployment request’ change model for future deployments of the same change. This is much simpler than the full change management process flow. © Crown copyright 2011 Reproduced under license from the Cabinet Office 54 ST Fig. 4.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 54

Secondary HUIT processes
Introduction to ITSM and ITIL January 2012 Secondary HUIT processes Service Strategy Service Design Continual Service Improvement Strategy Mgt. for IT Services Financial Management Supplier Management Service Continuity Management Information Security Management Demand Management Service Catalog Management Availability Management Capacity Management Service Portfolio Management Business Relationship Management Design Coordination Service Level Management Service Portfolio / Catalog Configuration Management System (CMS) Event Management Incident Management Request Fulfillment Config Management Change Management Transition Planning & Support The Secondary processes we will focus on are: Service Continuity Management Service Level Management Service Asset & Configuration Management Release & Deployment Management Knowledge Management Continual Service Improvement The Secondary HUIT Processes are no less important than the Primary processes, however HUIT has made a strategic decisions that this processes would not be part of the ITSM Unification project. That being said over the course of the next year or two we will always be looking at opportunities to improve and combine these processes in HUIT. Access Management Problem Management Operational Activities of other lifecycle phase processes Change Evaluation Service Validation & Testing Release & Deployment Management Knowledge Management 7-Step Improvement Process Service Operation Service Transition 55 Harvard University IT

Release and Deployment Management
Service Transition Stage ITIL® Foundation Course Release and Deployment Management The purpose of the release and deployment management process is to plan, schedule and control the build, test and deployment of releases, and to deliver new functionality required by the business while protecting the integrity of existing services. Release and Deployment Management aims to build, test and deliver the capability to provide the services specified by Service Design and that will accomplish the stakeholders’ requirements and deliver the intended objectives. Release and Deployment Management Deliver new functionality and services that the business requires Ensure the integrity of the release through the development and testing phases Ensure appropriate knowledge is logged Ensure service catalogue and Configuration management is updated Process Scope The scope of release and deployment management includes the processes, systems and functions to package, build, test and deploy a release into live use, establish the service specified in the service design package, and formally hand the service over to the service operation functions. The scope includes all configuration items required to implement a release, for example: Physical assets such as a server or network Virtual assets such as a virtual server or virtual storage Applications and software Training for users and IT staff Services, including all related contracts and agreements. Exclusions Although release and deployment management is responsible for ensuring that appropriate testing takes place, the actual testing is carried out as part of the service validation and testing process. Release and deployment management is not responsible for authoring changes, and requires authorization from change management at various stages in the lifecycle of a release. 56 ST 4.4 ST 4.4.1 ST 4.4.2 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 56

Service Level Management
Service Design Stage ITIL® Foundation Course Service Level Management The purpose of the SLM process is to ensure that all current and planned IT services are delivered to agreed achievable targets. This is accomplished through a constant cycle of negotiating, agreeing, monitoring, reporting on and reviewing IT service targets and achievements, and through instigation of actions to correct or improve the level of service delivered. SLM is a vital process for every IT service provider organization in that it is responsible for agreeing and documenting service level targets and responsibilities within SLAs and service level requirements (SLRs) for every service and related activity within IT. If these targets are appropriate and accurately reflect the requirements of the business, then the service delivered by the service providers will align with business requirements and meet the expectations of the customers and users in terms of service quality. If the targets are not aligned with business needs, then service provider activities and service levels will not be aligned with business expectations and problems will develop. The SLA is effectively a level of assurance or warranty with regard to the level of service quality delivered by the service provider for each of the services delivered to the business. The success of SLM is very dependent on the quality of the service portfolio and the service catalog and their contents because they provide the necessary information on the services to be managed within the SLM process. 57 SD 4.3 SD 4.3.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 57

Service Asset & Configuration Management
Service Transition Stage ITIL® Foundation Course Service Asset & Configuration Management The purpose of the service asset and configuration management (SACM) process is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets. No organization can be fully efficient or effective unless it manages its assets well, particularly those assets that are vital to the running of the customer’s or organization’s business. 58 ST 4.3 ST 4.3.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 58

IT Service Continuity Management
Service Design Stage ITIL® Foundation Course IT Service Continuity Management The purpose of the IT service continuity management process is to support the overall business continuity management (BCM) process by ensuring that, by managing the risks that could seriously affect IT services, the IT service provider can always provide minimum agreed business continuity-related service levels. As technology is a core component of most business processes, continued or high availability of IT is critical to the survival of the business as a whole. This is achieved by introducing risk reduction measures and recovery options. Like all elements of ITSM, successful implementation of ITSCM can only be achieved with senior management commitment and the support of all members of the organization. Ongoing maintenance of the recovery capability is essential if it is to remain effective. The purpose of ITSCM is to maintain the necessary ongoing recovery capability within the IT services and their supporting components. Business Continuity Management (BCM) This is the Business Process responsible for managing risks that could seriously impact the Business. BCM safeguards the interests of key stakeholders, reputation, brand and value creating activities. The BCM Process involves reducing Risks to an acceptable level and planning for the recovery of Business Processes should a disruption to the Business occur. BCM sets the Objectives, Scope and Requirements for IT Service Continuity Management. Unfortunately, in many organizations BCM is absent or has very little focus, and often ITSCM is required to fulfill many of the requirements and activities of BCM. Much of the guidance in the Service Design publication’s section on ITSCM assumes that ITSCM has had to perform many of the activities required by BCM. Where a BCM process is established with Business Continuity Strategies and Plans in place, these documents should provide the focus and drive for establishing ITSCM. ITSCM Techniques In support of and alignment with the BCM process, ITSCM uses formal risk assessment and management techniques to: Reduce risks to IT services to agreed acceptable levels Plan and prepare for the recovery of IT services. 59 SD 4.6 SD 4.6.1 Third Sky, Inc. - Proprietary & Confidential Master Ver.-4.0 59

Continual Service Improvement
Introduction to ITSM and ITIL January 2012 Continual Service Improvement The purpose of the CSI stage of the lifecycle is to align IT services with changing business needs by identifying and implementing improvements to IT services that support business processes. Purpose and objectives of CSI The purpose of the CSI stage of the lifecycle is to align IT services with changing business needs by identifying and implementing improvements to IT services that support business processes. These improvement activities support the lifecycle approach through service strategy, service design, service transition and service operation. CSI is always seeking ways to improve service effectiveness, process effectiveness and Cost effectiveness. In order to identify improvement opportunities, the measurement of current performance is an important factor. Consider the following sayings about measurements and management: You cannot manage what you cannot control. You cannot control what you cannot measure. You cannot measure what you cannot define. If services and processes are not implemented, managed and supported using dearly defined goals, objectives and relevant measurements that lead to actionable improvements, the business will suffer. Depending upon the criticality of a specific IT service to the business, the organization could lose productive hours, experience higher costs, suffer loss of reputation or, perhaps, even risk business failure. Ultimately it could also lead to loss of customer business. That is why it is critically important to understand what to measure, why it is being measured and what the successful outcome should be. The objectives of CSI are to: Review, analyze, prioritize and make recommendations on improvement opportunities in each lifecycle stage: service strategy, service design, service transition, service operation and C51 itself Review and analyze service level achievement Identify and implement specific activities to improve IT service quality and improve the efficiency and effectiveness of the enabling processes Improve cost effectiveness of delivering IT services without sacrificing customer satisfaction Ensure applicable quality management methods are used to support continual improvement activities Ensure that processes have dearly defined objectives and measurements that lead to actionable improvements Understand what to measure, why it is being measured and what the successful outcome should be. Scope ITIL Continual Service Improvement provides guidance in four main areas: The overall health of ITSM as a discipline The continual alignment of the service portfolio with the current and future business needs The maturity and capability of the organization, management, processes and people utilized by the services Continual improvement of all aspects of the IT service and the service assets that support them. To implement CSI successfully it is important to understand the different activities that need to be applied. The following activities support CSI: Reviewing management information and trends to ensure that services are meeting agreed service levels Reviewing management information and trends to ensure that the output of the enabling processes are achieving the desired results Periodically conducting maturity assessments against the process activities and associated roles to demonstrate areas of improvement or, conversely, areas of concern Periodically conducting internal audits verifying employee and process compliance Reviewing existing deliverables for appropriateness Periodically proposing recommendations for improvement opportunities Periodically conducting customer satisfaction surveys Reviewing business trends and changed priorities, and keeping abreast of business projections Conducting external and internal service reviews to identify CSI opportunities These improvement activities support the lifecycle approach through service strategy, service design. service transition and service operation. CSI is always seeking ways to improve service effectiveness. process effectiveness and cost effectiveness. 60 Harvard University IT

HUIT exists to provide services
ITIL® Version 3 Awareness - Walgreens August 2009 HUIT exists to provide services HUIT is an essential part of the larger institution, and exists to provide a variety of services that support the institution’s goals. Harvard Goals Business Outcomes IT Services IT Providers Fundamental concept: IT exists to provide services IT provides services that result in outcomes that create value to support Harvard’s Goals IT does not exist to provide technology for technology’s sake. IT has to be aligned with the goals of the organization We need to understand the organizations goals, then have an understanding of the business processes that are in place to support those goals. IT then needs to work closely with the business to determine the IT services that are needed to support the core business processes. IT Service Management exists to help IT provide the right services The Service that IT provides 61 Third Sky, Inc. Proprietary & Confidential

Introduction to ITSM and ITIL

Similar presentations

Presentation on theme: "Introduction to ITSM and ITIL"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to ITSM and ITIL

Similar presentations

Presentation on theme: "Introduction to ITSM and ITIL"— Presentation transcript:

Similar presentations

About project

Feedback