3 Generic Concepts

ITIL Version 3 Foundation Certificate EX0-101: Generic Concepts

You can print this text-only version of this course for future reference. If you wish to use the accessible version of our courses, which includes questions in text-only format, click Text Only on the log on page, and then enter your user ID and password from the Accessibility Log On page.

Lesson 1. Course Introduction

Hi! My name is Rusty Reese and I'll be your instructor for Generic Concepts. This course is one of a series of lectures on ITIL Version 3 Foundation Certificate EX0-101. In this lecture, I'll discuss the generic concepts you need to know to understand the information technology infrastructure library. Remember to use the Course Tools tab if you want to:

� View or print a complete transcript of my lecture � Download the PowerPoint presentation I use in this lecture � View or print takeaways and reference materials from this lecture � View flashcards or play a match game to check your understanding of this lecture

When you exit this course, be sure to view my other lectures in ITIL Version 3 Foundation Certificate EX0-101.

Lesson 2. Generic Concepts

After completing this lesson, you should be able to:

� Explain the generic concepts and terminology of ITIL

Topic 2.1 Instruction Presentation

Slide 1 ITIL classifies services as assets which are of value to the organization, customers, or business partners. Two of the most important assets are Service Utility and Service Warranty. Service Utility and Service Warranty are reliant on each other to deliver the service to the customer creating its value to the IT organization and customer. If assets are not available to the IT organization it could have a direct impact on the IT organization's revenue, margins, and/or customer confidence and satisfaction. Service Utility Is classified as an asset and is the actual service itself within the IT organization and provided to the customer or business partner through the combination of people, processes, and technology. Utility service is really what the customer gets.

Page 1 of 23ITIL Version 3 Foundation Certificate EX0-101: Generic Concepts

06.05.2010http://central.mindleaders.com/dpec/courses/l_3i03/l_3i03ac.htm?access=1&printversi...

Slide 2 Service Warranty Is classified as an asset and is closely monitored and tracked by the customer and/or business partner. Warranty is how the service is delivered to the customer and in what state. The customer wants assurance from the IT organization that the warranty of the deliverable is what they perceived the output is and what is documented in the Service Level Agreement. The customer wants the IT organization to show them that the warranty of the service produced has ensured the availability of their resources to produce a valued service, have the right capabilities available to produce a valued service, taken into account the capacity load of the resources, and that necessary steps have been made for the continuity of the service and all necessary security controls have been implemented safeguarding the service. Slide 3 An IT organization provides services to a customer through a Service Level Agreement using service capabilities and resources to deliver what is agreed upon in the Service Level Agreement. Capabilities consist of the knowledge that senior leadership brings to the organization, the processes such as Capacity Management and Release Management that is developed, and the knowledge of the staff and all the expertise they have from individual training, on the job training and prior work experience. Since capabilities are based on what knowledge people bring to developing the service it is safe to say that capabilities mature over a long time. Slide 4 Resources are easily obtainable for an organization if the budget allows tools to be purchased to integrate with the capabilities to produce a service for the customer or business partner. Resources are the data information that resides in the databases or mainframe computers, software applications, network infrastructure, and the finances available for purchasing. An IT organization needs to ensure that they are monitoring their capabilities and resources and provide continuous service improvement to stay ahead or competitive with their competitors. Through proper quality assurance checks and balances this can be achieved within the organization. The customer is going to look at the service provided and measure its output and determine if it is satisfactory or not. A customer has choices of many organizations to get a service from but an IT organization may not always have the choice to pick customers. Many organizations have similar products with other companies they are providing a customer. This allows the customer to pick who has the best processes and who can deliver value propositions within their budget constraints. Slide 5 A Service Catalog provides a listing, with associated detail, of services currently offered by an IT organization to current or prospective customers. The utility of a Service Catalog will vary somewhat with the stage of maturity the organization is experiencing. In general, the Service Catalog serves several main purposes for an Information Technology organization: It provides clients with a listing of available Information Technology services, with detailed information about items such as cost and currently agreed-to service levels. Customers (usually with IT partnership) can tailor and combine the individual services listed in the catalog to configure suitable solutions. Since the Service Catalog contains references to both cost and service level agreements, it functions as the baseline for strategic IT planning, governance and performance management. In addition, the ITIL Service Desk is organized around the service catalog and serves as a single point of entry for



routing and tracking the service demand and service support through the Information Technology organization. That is, it fills a service pipeline management requirement inherent in IT governance. Because it functions as an Information Technology acquisition portal for customers, it also makes the provider's operational capability transparent to the customer. Slide 6 In its initial iterations, the Service Catalog serves as a ready reference for internal IT business units to promote communication and collaboration. That is, it serves the function of informing everyone within IT "who does what." As organizations develop and mature, they generally acquire or develop more sophisticated knowledge management and collaboration capabilities, thereby lessening the need for the Service Catalog to deliver this functionality. The Service Catalog provides the baseline repository for metrics, key performance indicators (KPI) and for the remainder of the organization's ITIL implementation. Most organizations undertaking a move toward ITIL also must deal with immature or inconsistent governance and quality management functions. The fact that the Service Catalog highlights service levels, KPIs, and metrics means that creating it provides the organization a "quick hit" toward both quality and governance. Slide 7 Service Catalog Composition The Service Catalog is composed of two types of services: business and technical. Business services — often termed "customer-facing" — are the usable services that an IT organization provides either to department partners or to constituents on behalf of a business partner. An example of a business service an IT organization provides to business partners is email and collaboration. A service provided to constituents by the IT organization's business partners is online renewals and real-time traffic status. An example of a service provided to both business partners and constituents is authentication. Technical services — often termed "resource-facing" — are services the IT organization uses in delivery of business services. These would be services that the IT organization's business users and constituents would not necessarily know or care about, but are vital to the IT organization's ability to deliver business services. Analysis and design, database backups, and server monitoring are examples of technical services. Slide 8 The Service Catalog details services organized into five distinct categories, one business and four technical. These five are: Business Application Services. These services provide the principal customer-facing services for those clients (business units and constituents) external to the IT organization. Professional Support Services. These are services associated with governance, due diligence, fiduciary responsibility, and non-security oversight. They also include all services that are provided to the customer via outsourcing. Hosting and Network Support Services. These provide support to both external and internal customers for the named support service. Collaboration and Communication Services. These are services specifically designed to enable and foster productivity for all users. Security Services. These provide the services to ensure appropriate physical, virtual, and data security as well as general security oversight. Slide 9 Application Portfolio Management (APM) is a practice that has emerged in mid to large size Information Technology (IT) organizations since the mid 1990s. Application Portfolio Management



attempts to use the lessons of financial portfolio management to justify and measure the financial benefits of each application in comparison to the costs of the application's maintenance and operations. Because IT organizations expend so much of their human and capital resources maintaining a growing inventory of applications and supporting infrastructure, effectively managing those applications should be a high priority of IT organization senior leadership. Yet industry research indicates that it is not uncommon for organizations to have multiple systems and applications that perform the same (or strikingly similar) function. There's no single reason for such duplication. Often it's the result of internal competition, conflicting viewpoints, independent decisions, or diverging opinions about the "right" new tools for a particular purpose. Regardless of the degree of duplication, separate applications are separately maintained (usually by separate organizational elements) and require resource expenditure to periodically upgrade. Slide 10 Since such a significant portion of expenses flows to managing the existing IT applications, Application Portfolio Management attempts to control these costs by identifying duplication and redundancy and by enabling proactive control and integration. Some organizations have claimed upward of a 33% reduction[1] in application maintenance costs as a result of using Application Portfolio Management tools and techniques. The business benefit would come, according to the proponents of Application Portfolio Management, by removing duplication and redundancy by retiring systems that proved unnecessary. [1] This figure was cited as an "approximate gain" by Gregor Bailar, CIO of Capital One, in the June 2004 Richmond PMI/Portfolio Management Symposium. Slide 11 Aside from the potential to eliminate duplication the specific benefits Application Portfolio Management can deliver to an IT organization are listed below: Visibility. Application Portfolio Management enables the organization to inventory and then actively manage applications across the organization. Without Application Portfolio Management, the number and variety of applications can expand in an uncontrolled fashion. Architecture. Architectural plans or efforts must include consideration of applications as a major component of that architecture. Understanding and actively managing the Application Portfolio is a critical first step in developing the organization's architecture. Governance. An essential ingredient of any governance effort is the requirement to monitor, measure, and manage all four IT resource types: People, Information, Infrastructure, and Applications. The Application Portfolio, if managed properly, provides both a facilitating and a controlling impact on the organization, thereby significantly contributing to governance efforts. Slide 12 Service Catalog Crosswalk. Once a listing of applications is available, the next step is to map those applications to all the services the organization offers via the Service Catalog. In that manner, the organization can know exactly which application supports which service and will be able to anticipate impacts from application changes. Database Crosswalk. The natural extension of the application portfolio is mapping each application to the data interdependencies. The organization can know exactly which application interacts with which database and will be able to anticipate impacts to databases from application changes or impacts to applications from database changes. Slide 13



Communication and Collaboration. Managing via an application portfolio has the significant benefit of enabling a greater level of interaction. By making the dependencies of groups and functions more visible, they can more easily effect the collaboration that is the mark of acceptance of best-practice level organizations. Facilitates Service Level Agreement (SLA) Discussions. One of the most common elements of the SLAs an IT organization will create with their customers will be the level of application support (primarily availability). Understanding the interdependencies among applications, databases, and services, as well as the costs of applications will enable more informed negotiation of Service Level Agreements. Slide 14 The Application Portfolio is normally a distinct service within the IT Service Catalog. Since the principal benefit from the Application Portfolio goes to the Information Technology organization, the Application Portfolio is generally categorized as a technical (resource-facing) service, but it is equally acceptable to categorize it as a business (customer-facing) service. The Application Portfolio has great potential to be a valuable asset to IT organization leadership. It will assist in governance as well as architectural efforts, integrate with the Service Catalog and other ITIL efforts, and will provide a tangible way to measure and track application costs and performance. The Application Portfolio is foundational in an IT organization effort to measure and demonstrate its value to the customers. Slide 15 Information Technology Governance known as enterprise governance is a subset of corporate governance focusing on IT systems and performance. IT Governance is designed to deliver the best quality services and products that will enable the business to meet its goals, while employing IT resources to satisfy customer and business partner needs. Slide 16 Because governance is often misunderstood, especially in organizations where it is just emerging, it is critical to acknowledge at least one common misperception. That common misconception is that Governance is just regulating the flow of work into the pipeline, that Governance is equivalent to simply prioritizing the projects or work that come into the organization. That prioritization is certainly a key component of governance. However, one very important point is that the domain of IT Governance extends well beyond the project portfolio. Governance is not a single facet of Information Technology Management such as project prioritization nor is it simply control of services under an ITIL framework. Instead, it is much more encompassing, dealing with every facet of Information Technology, with concentration on management of the four commonly accepted types of IT resources. Those four types of resources are: Applications Infrastructure Information People Slide 17 When one views Governance in terms of the four resource types, it immediately becomes apparent that IT Governance is about the entire domain of IT, not just projects. Stated alternately, when IT Governance is defined as judicious stewardship of all resources, and when it is clear that projects consume only a small percentage of the total resource pie, then IT Governance is obviously much more than just project-related oversight.



Measurement is a key component of management, and therefore Governance. Most organizations develop and use forms of measurement, commonly called metrics. In general, unless something is measured, there is no way to know with certainty if it is getting better or worse. An IT organization can't manage for improvement without a baseline. Slide 18 IT Governance touches every aspect of the ITIL lifecycle. Continual Service Improvement is constantly being done and managed by IT Governance in an organization. Enterprise Governance takes a holistic to ensure the strategic strategy is aligned and good leadership is achieved. Enterprise Governance touches Corporate Governance which fairness across the organization and accountability of all resources to include staff and assets. Through Enterprise, Corporate, and Business Governance accountability, value creation, and resource utilization can be optimized across the organization. Slide 19 A business case begins in the Initiation phase of the project lifecycle. A business case should answer the following questions: What is the business problem to be solved? What is the value of solving the problem? What is the cost of not solving the problem? What is the proposed solution? What are the major deliverables? What is the estimated cost? What is the estimated duration? Who is the customer implementing the solution? What are the customer's responsibilities? Who is providing funding for the solution development (sponsor)? What are the sponsor's responsibilities? Slide 20 Management should determine if the business case justifies the project scope (by considering issues such as tangible and intangible benefits, estimated costs, projected return-on-investment, etc.) and decide if the project is feasible. If management approves a request, the scope documentation serves as the basis for developing the project plan. A business case should, at a minimum, describe a proposal's purpose, identify expected benefits, and explain how the proposed system supports one of the organization's business strategies. The business case should also identify alternative solutions and detail as many informational, functional, and network requirements as possible. Slide 21 When developing a business case with an external customer or business partner an IT organization needs to work closely with the customer or business partner to define the purpose of the interconnection, determine how it will support their mission requirements, and identify potential costs and risks. Defining the business case will establish the basis of the interconnection and facilitate the planning process. Factors that should be considered are estimated costs (i.e., staffing, equipment, facilities), expected benefits i.e., improved efficiency), and potential risks (i.e., technical, legal, and financial). The development of software "from scratch" for a new service or enhance a current service should only be considered if warranted by a strong Business Case and supported both by management and adequate resources over the projected life time of the resultant project. Slide 22 Statements of business requirements for new systems, or enhancements to existing systems should



specify the requirements for controls. Such specifications should consider the automated controls to be incorporated in the system, and the need for supporting manual controls. Similar considerations should be applied when evaluating software packages for business applications supporting services. If considered appropriate, management may wish to make use of independently evaluated and certified products. Slide 23 Risk Management – Is the process of assessing risk, taking steps to reduce risk to an acceptable level, and maintaining that level of risk. (Risk Assessment, System Documented, Business Impact Analysis) Risk - The net negative impact of the exercise of a internal or external vulnerability, considering both the probability and the impact of occurrence to a system. Threat Source - Intent and methods targeted at the intentional exploitation of a vulnerability or a situation and method that may accidentally trigger a vulnerability in a system. Slide 24 Vulnerability - A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and results in a security breach or a violation of the system's security policy. Likelihood - The potential of a threat being exploited. Impact - The positive or negative measurable influence on the system from either an implemented security measure (positive impact) or the effectiveness of an adverse event (negative impact) on the system which rates the Severity of the event. Slide 25 Risk Mitigation is a systematic methodology used to reduce mission risk by creating a Risk Mitigation Strategy that fits an IT organization's needs, uses "best of breeds," and is cost-effective. The four basic Risk Mitigation options include: Risk Assumption Risk Avoidance Risk Limitation Risk Transference Slide 26 Risk Assumption –To accept the potential risk and continue operations, or implement controls to lower the risk to an acceptable level. Risk Avoidance – To avoid the risk by eliminating the risk cause and/or consequence or changing how a system is used. This option includes Research and Acknowledgment which includes researching controls to correct the vulnerability and subsequent Risk Planning which establishes a plan to mitigate the risks. Risk Limitation – To limit the risk by implementing controls that minimize the adverse impact of a threat's exercising a vulnerability. Risk Transference – To transfer the risk by using other options to compensate for the loss, such as purchasing insurance. Slide 27 Customer needs a system and defines the purpose and scope with all the following activates listed in



the picture as input Risk Management Process - Identified risks are used to develop the system requirements including security controls System is designed, purchased, constructed by the IT organization Risk Management Process - Identified risks are used to make design tradeoffs during system development System features configured, enabled, tested within the IT organization Risk Management Process – Security controls are assessed against requirements with risks prior to deployment System in production with enhancements and maintenance a routine function Risk Management Process - Identified risks from periodic assessments are addressed and mitigated System is discontinued, Hardware/Software disposal and data is archived Risk Management Process – Disposal or migration of system is handled in a secure and systematic process Slide 28 A Risk Strategy needs to be documented so that the organization can have detailed risk procedures developed to provide Continuous Service Improvement throughout the ITIL Lifecycle for internal improvement leading to external improvement of customer services. Slide 29 Before services are moved into the Service Operation production environment they are go through the ITL lifecycle stages of Service Strategy, Service Design, and Service Transition. In the Service Strategy stage service models are depicted through process maps, workflow diagrams, queuing models, and activity patterns are organized and structured through the market space. The strategy documents how the functions and processes communicate and collaborate to ensure that the best possible value is presented to the customer. The Service Level Agreement is the binding agreement between the IT organization and the customer. The Service Level Agreement documents how the IT organization resources and assets interact with the customer's resources and assets to meet the objectives outlined in the agreement. The IT organization is considered the service provider if it offers any type of service to a external customer or if it offers services internally to another business unit within the organization. Slide 30 In the Service Design stage a holistic view is taken to ensure that all the requirements have been taken into consideration in designing a new application or modifying an existing application. During this stage all the relationships and dependencies are documented and communicated to personnel for clear understanding on how they interact with throughout the service lifecycle. The Service Design passes a service package to the Service Transition stage which contains one or several Service Level Packages which contain the utilities (services) and warranties (assurance) that are delivered to the correct IT business unit to use in testing and designing. The requirements of the service model are identified in the Service Design Package providing the way the service will be structured and delivered to Service Operation. Slide 31 For example, a customer reaches an agreement with an organization to rent rack space in their data center for storage of the applications for business continuity. The customer and organization (Service Provider) sign a Service Level Agreement (SLA) documenting the cost and services to be provided and how their resources will communicate and integrate with each other. In the Service Strategy and Service Design stages the Service Provider will need to know what assets the customer has and the applications in question they are to service and protect. This will include the capacity requirements and types of applications and software for designing the space, hardware, and software requirements in the data center. This information allows the Service Provider to perform precise strategy planning



and develop the models identifying the risks which is importance to service testing. The Service Transition stage will review the detailed models the Service Provider developed to ensure that they can meet the required service capacity the customer needs and be able to support the customer in business continuity. Slide 32 Contracts with third-party vendors who supply services to support the IT organization should be handled through Supplier Management. Detailed policies, procedures and business continuity recovery procedures should be documented and enforced when dealing with suppliers. Suppliers may play a vital role in supporting the organization. This role may be of a major contributor or a minor contributor. A major contributor would be a supplier that provides backup storage capabilities such as SUNGARD and a minor contributor may be Office Deport who delivers paper and officer supplies. Both companies play a vital role to support the services that IT is providing to customers and business partners. It is important that contracts are managed properly for continued service and business recovery if needed. Managing the contracts should follow a process that includes: Developing a supplier policy and implementing it throughout the organization to include communication, training, and enforcement of the policy Review of the contract for amendments, termination or renewal Storage of all contracts in a centralized database Categorization of supplier services Risk assessment impact of supplier services Supplier performance of services Supplier management of services Continual Service Improvement of supplier services General maintenance of supplier contracts to include terms, conditions and cost Slide 33 Service Level Management is the process that manages Service Level Agreements and Operational Level Agreements. A Service Level Agreement is developed with an external customer who has contracted with the IT organization for delivery of services. A Service Level Agreement outlines the expected services and responses to issues in great detail. A Service Level Agreement can also be developed for a contract with an external business partner as well. An example of this would be the IT organization providing information on personnel to a customer so that the customer can issue a photo ID card to an individual. The IT organization should ensure that the Service Level Agreement includes requirements for regular monitoring, review, and auditing of the service levels and security requirements as well as incident response and reporting requirements. Slide 34 The IT organization should follow best practices in enforcing compliance with the SLA and be proactive with customers to mitigate risk to a reasonable level in delivery of services. Changes to the SLA and services provided should be controlled through the organization's change management process. An Operational Level Agreement is a contract that is developed internally for services of support to the IT organization to help them provide the necessary resources or activities to meet customer delivery and expectations outlined in the Service Level Agreement. An example of this would be legal aide from the legal department, security protection after hours, mailroom delivery and facility maintenance Slide 35



An IT organization must have a binding contract with an external customer or business partner who supplies services to the organization in support of their ongoing operational deliveries to internal or external customers. There must be a formal process for establishing new contracts, modifying existing contracts, terminating contracts, and renewing contracts. Contracts come in different varieties to the organization. They have a single contract or a contract with multiple suppliers. An IT organization may have a partnership to have services delivered to them. No matter what all contracts should be governed by policy and procedures and should include standard best practice and ITIL verbiage to protect the organization. The following are best practices and ITIL criteria when selecting a new supplier: The track record of the supplier The capability to provide the service References of the supplier Credit rating of the supplier Size of the Supplier How many years in operation Reputation Business Continuity Security breaches Experience and expertise of staff Slide 36 Changes to the provision of supplier services provided to IT organization in support of its business operations should be managed by the appropriate IT organization department. Review of changes to services provided to IT organization by supplier providers should take into account: Updating existing IT organization policies and procedures, as necessary Re-assessment of business criticality and associated risks to IT organization as a result of service changes Updating IT organization process maps and other process documentation, as necessary Slide 37 Reviews, evaluations and audits of changes to supplier services should take into account changes to the supplier organization itself, including: Enhancements to current services offered Development of new applications / systems Changes to the organization's operating procedures Changes to the organization's policies and/or procedures Reviews, evaluations and audits of changes to supplier services should take into account changes to the individual services offered by the supplier, including: Changes or enhancements to networks, systems or applications Use of new technologies to deliver services to IT organization Changes to development tools, services or environments Changes to physical locations of service facilities Change to a different service provider/vendor for services Slide 38 Prior to sending exchanging information and services to customers, not only must the intended recipient be authorized to receive such information or service, but also the procedures and Information Security measures adopted by the supplier must be demonstrated,. assure the confidentiality and integrity of the deliverable and electronic communications between them. Service level management concepts should be applied to all deliveries of services from a supplier provider. This should require suppliers to meet all security and service controls, service definitions and agreed service levels; as described in the associated Service Level Agreement or Contract for



services. Slide 39 Supplier service providers should be required to demonstrate sufficient service capability together with workable plans designed to ensure continuity of agreed upon service levels to the IT organization (i.e.,. Disaster Recovery Plan, Business Continuity Plan, etc Only authorized persons should order services on behalf of IT organization. These services should be ordered in strict accordance with the organization's purchasing policy. Only properly authorized IT organization personnel may sign for work or services delivered by third parties. Supplier services should be regularly monitored by authorized IT organization personnel, including review of records, reports and evaluation of services provided by the supplier. Slide 40 The Service Design Package is produced along with a service solution in the Service Design stage. The input into the service solution and the Service Design Package comes from the Service Strategy stage in the form of a Service Level Package which is developed based on the business needs and requirements of the organization. Slide 41 The Service Design Package is developed in alignment with the organization's service strategy and policies regarding service delivery and contains at a minimum the following criteria: Utilities identifying the services to be delivered to the customer Warranties identifying what state the services should be delivered in Availability of the service to the customer Business functionality of the service Business continuity recovery process identifying steps for continual service to the customer Security protecting the integrity of the service Usability of the service by the customer Regression testing of the service Once the Service Design Package (SDP) passes testing as a valid service solution meeting business requirements it is passed to the Service Transition stage which is the next stage in the lifecycle for evaluation, testing, and validation. Slide 42 Availability Management's purpose is to ensure that services being offered by the IT organization currently meet its business strategy objectives and also the future business strategy objectives within the budget outlined for Service Operation. An IT organization can accomplish this by implementing an Availability Management Information System to capture and maintain all of the measurements and information to be analyzed and generate reports to management on the service levels. The IT organization can use the information in the system to document a Availability plan identifying Vital Business functions and how the service and component levels will be maintained and serviced to include their availability and reliability. Slide 43 Reactive and proactive are two key activities of Availability Management conducted primarily in the Service Operation Stage. Reactive activities involve service unavailability for the IT organization to meet customer service delivery availability targets. To ensure that availability target dates are met the IT organization will incorporate monitoring controls, metrics, event management notification and analysis, incident response and problem resolution into the Service Design of an solution before it is moved into the



production environment. Proactive activities involve strategic planning up front and the documentation on design guidelines for new services or services identified to be changed through the Change Management process. Proactive activities reduce risk ensuring the availability for the IT organization to meet current and future business objectives. Slide 44 To measure the availability of a Service or component's ability to perform as agreed upon when it is required to do so is measured and reported as a percentage. If an IT organization was running a service for a customer on a 24 x 7 basis that included one of its resources to crunch numbers for six months totaling 7,200 hours in a database with only three stops of 25 hours, 45 hours and 30 hours downtime for maintenance we would be able to perform the following calculations: Availability = (7,200 – (25+45+30)) / 7,200 X 100 = 98.6% Slide 45 To measure the reliability of a Service or component's ability to perform without interruption as agreed is measured and reported in hours. This will allow for the service reliability of a component to be improved. If an IT organization was running a service for a customer on a 24 x 7 basis that included one of its resources to crunch numbers for six months totaling 7,200 hours in a database with only three stops of 25 hours, 45 hours and 30 hours downtime for maintenance we would be able to perform the following calculations: Reliability (MTBSI) = 7,200 / 2 = 3,600 hours Slide 46 Effective Service Management is having the necessary resources available in making the best decision possible to deliver and support services being provided to customers and business partners. One of the most valuable resources available to a user is the Service Knowledge Management System (SKMS) which contains valuable information regarding: Assets Configuration Items Staff experience and skill-sets Vendor information Partner information Known errors Problem resolutions Having the Service Knowledge Management System readily available enables a user to query the database and make a decision quicker based on the results retrieved. The Service Knowledge Management System is held in the Configuration Management System and Configuration Management Database repository. Slide 47 Configuration management exists because changes to an IT organization's existing information system are inevitable. The purpose of configuration management is to ensure that these changes take place in an identifiable and controlled environment and that they do not adversely affect any properties of the system, or in the case of services, do not adversely affect service output to customers or business partners.



Configuration management provides assurance that additions, deletions, or changes made to the system do not compromise the trust of the originally evaluated system to deliver services internally or externally to the customer as outlined in a Service Level Agreement. It accomplishes this by providing procedures to ensure that the system and all documentation are updated accordingly. Slide 48 The basic function of configuration identification is to identify the components of the design and implementation of a system. When it concerns Configuration Items, this specifically means the design and implementation of the Configuration Items. By establishing configuration items and baselines, the configuration of the system can be accurately identified throughout the system life-cycle. Configuration control involves the systematic evaluation, coordination, approval, or disapproval of proposed changes to the design and construction of a configuration item whose configuration has been formally approved. Configuration control should begin in the earliest stages of the design and development of the system and extend over the full life of the configuration items included in the design and development stages. Early initiation of configuration control procedures provides increased accountability for the system by making its development more traceable. The traceability function of configuration control serves a dual purpose. It makes it possible to evaluate the impact of a change to the system and controls the change as it is being made. With configuration control in place, there is less chance of making undesirable changes to a system that may later adversely affect the security of the system. Configuration control provides assurance that each change is complete and acceptable. The control exercised is in process quality assurance check. Slide 49 An organization should develop a Configuration Management plan that specifies procedures to ensure that all documentation is updated properly and presents an accurate description of the system and its configuration. Often a change to one area of a system may necessitate a change to another area. The failure of the system to deliver required capabilities puts staff, resources and services at risk. The large number of workarounds, the system hang-ups, inadequate or insufficient training add to the already arduous workday of internal staff. The operation of systems that do not perform as designed cause a general lack of confidence and trust by users, customers and business partners. This lack of confidence/trust further exacerbates the day-to-day operations and adds to operator stress. Operating in a high stress environment with systems that do not perform contributes in driving valuable customers from the organization's services. Slide 50 Configuration Item and Hardware and Software Configuration Configuration Items are considered an asset and reside in the Configuration Management Database and managed by the Configuration Manager. The configuration Manager will identify the way are selected using the best possible solution that fits the need of the organization. The Configuration Items may be grouped, classified, identified and selected in any capacity as long as the Configuration Manager can establish audit controls that make a Configuration Item traceable throughout the lifecycle.



Slide 51 Configuration Items may fall into one the following categories: Service Lifecycle Configuration Item – Services available Service Configuration Items – Service Capability and Resource assets Organization Configuration Items – Characteristics Internal Organization Configuration Items – Tangible and Intangible assets External Configuration Items – Customer requirements Interface Configuration Items – end-to-end service across the organization Hardware Configuration - Include for each system component, the manufacturer, model number, nomenclature, and the quantity of each equipment item and whether the equipment is owned or leased. Include a physical layout of the system. Specify whether the system uses hard disk or removable disk storage media. Software Configuration - Specify the operating system (include version and release), applications software and any special add-on security packages used by this facility and describe the functions of each. Refer to system documentation/specifications for specific security features provided by the operating system. Slide 52 The Service Asset and Configuration Management (SACM) process manages the Definitive Media Library which is a secured area within the production environment that contains all reviewed and authorized software. Configuration Items are what actually is checked into and stored in the Definitive Media Library relating to its category, vendor, license key, IT owner, date entered, approved usage, software, release packages, patches, system images, physical location, naming conventions, environment supported, security controls, capacity planning and audit procedures. An organization needs to ensure that they develop a Definitive Spare which contains spare components maintained as an exact replica of the master Definitive Media Library. A Configuration Baseline should be configured to allow for a fail-over back to the original state if needed. The baseline supports audit compliance by establishing a benchmark to work from up to the state if the existing system and all new Configuration Items. A snapshot of the current state should be archived in the Configuration Management System for historical purposes. Slide 53 The Service Portfolio is the key to Service change and starts in Service Strategy documenting strategic changes that need to be implemented and passes along these changes to Service Design for Continual Service improvement or new design and is passed to Service Operation for implementation or outsourced to a third-party. The Service Portfolio contains the information on the current services, services that are going to be retired and new services that are planned. If a change is outside the scope of Change Management within an IT organization the organization may need to outsource and issue a Request for Change to have a third-party come into the organization and make the change. For example, moving the Data Center racks and servers over to a new Data Center within the same facility may be a change that a third-party may need to perform. Slide 54 Change Management is the practice of ensuring all changes to the applications, including software, hardware, and configuration items, are carried out in a planned and authorized manner. This includes ensuring that there is management approval for changes being made to the production environments.



This process also ensures that thorough documentation is provided so that all involved parties have a shared knowledge of the ticket and change. Change Management is a component of the Information Technology Infrastructure Library (ITIL) and functions interdependently with the Demand Management, Solution Development, and Release Management components. Changes can be a result of problems, issues, or requests. Changes come to the Help Desk team by way of tickets that have been assigned through the Change Management process. Change Management documents, migrates, and escalates the tickets related to any of the applications that are included in the scope of the Change Control Board. This includes problems, changes, and cases. Slide 55 The objectives of normal and standard Change Management include: Resolve tickets in a timely manner Take responsibility for facilitating the resolution of specific help tickets Monitor progress/status of outstanding help tickets Accurately and thoroughly document each phase of the Solution Development Process, including Requirements, Design, and Test Accurately and thoroughly document the resolution in the ticket Understand the appropriate escalation procedures Understand the migration approval process and role of the Change Advisory Board team Understand the migration approval process and role of the Change Advisory Board Slide 56 An emergency will be defined as anything that must be changed or fixed immediately because it affects production systems and impacts users. Should a change be prioritized as an emergency, Emergency Change procedures should be followed to expedite the overall process. This includes contacting the Emergency Change Advisory Board members either by conducting an emergency meeting, email notification, or phone contact. If an emergency ticket is approved by the Emergency Change Advisory Board members, then work can immediately begin and the application development process will be expedited. Additionally, Impact Requirements and Resource Requirements should be estimated at this point. An emergency exists only if a sudden, unexpected occurrence takes place which causes a disruption in service to the users and customers, and which requires an immediate change to correct or resolve. All emergency changes should be submitted on a Change Notification Form. Slide 57 Changes to a system, service asset, or component are scheduled through the Release Management process. The IT organization needs to determine during this process what type of Release Unit will be scheduled. The IT organization determines if the changes in the release are for one service asset, several assets, or for all applications. If a Microsoft Service Pack is being performed on VISTA the IT organization would schedule a Full release of all application components operating Vista to be updated. If a problem occurs with Vista's capability to access a legacy software application in the production environment a Delta release containing only the Configuration Items that have been altered or are new since the last full or package release may be scheduled in a release unit. Slide 58 A Package release may be scheduled as a release unit if an IT organization was moving from a Windows XP image on all their platforms to Vista. To change the entire image on the workstations, laptops and any application interfaces would require a Package release which contains all the previous Delta and Full releases. Package releases are generally implemented less frequently than Delta of Full releases because an IT organization does not switch images of their software on a



regular basis. It is important for an organization to identify what type of release is going to be scheduled in the Release Unit. This will enable the organization to determine: What impact the release will have Resources needed for the release Testing of the release Training if required Identify and documents all interfaces of the release Capacity requirements pertaining to storage How the release will be tested in the test environment How the release will be implemented in the production environment Slide 59 The 7 R's according to ITIL Service Transition are: Raised Reason Return Risk Resources Responsible Relationship When documenting a change the following questions should be answered and documented on a Change Control Form: Who initiated or RAISED the change? What is the REASON for the change? What is the expected RETURN or result of the change? What RISK may occur based on a risk assessment of the change? What RESOIURCES are needed to design and implement the change? Who is RESPONSIBLE to build, test, and implement the change? Does the change impact any other changes that are going to be implemented or does the change need to coincide or have a RELATIONSHIP by interfacing with another change? Slide 60 Every change request submitted to the Change Advisory Board should have documentation of the risk assessment performed or an initial Impact Analysis of the change, to include at a minimum: Baseline affected Configuration items affected Impact on cost Impact on schedule Impact on resources Risk associated with implementing change Risk associated with not implementing change Slide 61 Each Change should include contingencies to abort or revoke the change, returning the system to pre-change condition, in the event of unsuccessful implementation of the change or unforeseen events interfering with the change implementation. The Fallback Procedures should include, at a minimum: Responsibilities for implementing fallback Procedures for revoking the change implementation Procedures for restoring the system to pre-change condition



Slide 62 An organization's resources must be protected against events that may jeopardize services by contaminating, damaging, or destroying service resources. Whether suspected or proven, deliberate or inadvertent, events threaten the integrity, availability, or confidentiality of service resources to include information resources. Monitoring is used to provide Continual Service Improvement for service resources, to ensure appropriate use of those resources, and to protect service resources from attack. Using monitoring tools will enable an organization to receive notifications via a management console, email, or pager. Active monitoring looks at Configuration Items and monitors them constantly (real-time) reporting on the status and availability. If the state of the Configuration Item changes an alert is sent via a management console, email, or pager for immediate attention. Passive monitoring (after-the-fact) receives operational alerts and alerts correlated to Configuration Items and than responds to the event. Slide 63 An alert provides an advanced notification to appropriate personnel in an IT organization via a event management tool that an emergency or disaster situation may occur to one of the services being monitored. When alerts are received, the appropriate person identified in the organization is usually immediately notified via pager and email automatically from the event management tool. The first line of the defense in an organization is usually the Help Desk. The Help Desk usually will be notified first of an incident and works with the Computer Security Incident Response Team (CSIRT) to determine the need for escalation or forensics and course of action. The reporting of incidents via the event management tool on service resources enables the IT organization to review the security controls and procedures; establish additional, appropriate corrective measures, if required; and reduces the likelihood of recurrence to any service. Slide 64 ITIL uses Incident, Problem and Change management processes to describe the lifecycle of errors through to permanent resolution. An incident is any event which is not part of the standard operation of a service in the organization and that causes, or may cause, an interruption to, or a reduction in, the quality of that service to internal and external customers. Incident Management's focus is on return to normal service levels as soon as possible with the smallest possible impact on the business activity and user. Sources of Incidents include any error or potential error in the IT infrastructure as reported by an end user, IT staff, or Event Management System. The IT organization has the responsibility for: Restoring Service/Resolving the Incident May or may not produce a Workaround or alternative Opening Problem records in accordance with guidelines provided Accurate and timely documentation The IT organization does not have responsibility for: Root Cause Identification or permanent resolution of the Error causing the Incident. This falls under Problem Management. Slide 65 ITIL guides an organization on "what to do" for Incident Management but does not tell the organization "how to" implement and how to measure impact, urgency, or prioritize an incident or



event. Organizations use best practices and what is a best fit for their organization when implementing an Incident Management process. A computer security incident can take on different priorities depending on the impact, scope and criticality to the organization's computing environment as well as the potential for public or regulatory disclosure of the incident. During the triage phase, the Computer Security Incident Response Team (CSIRT) lead should set the initial priority of the incident, and this priority may change during the incident based on new information uncovered or the success of initial containment or eradication procedures. Slide 66 Priority 1 incidents are described from both a business impact to services and public awareness level. From a business standpoint, enterprise business service interruptions, actual network intrusions, actual denial of service attacks, and enterprise wide virus infestations or worm outbreaks are considered the greatest impact. Additional risk to the IT organization can occur when the incident becomes known to the organization's internal customers or may become known to external customers, or if incident involved unauthorized disclosure of privacy regulation protected customer data. In this context, customers can be synonymous with the public. Priority 2 incidents are also described from both a business impact and public awareness level. From a business standpoint, e-mail abuse issues; insider threats to the organization; hardware theft; significant degradation or outage of regional office or data center network or system performance due to a regional or single business unit worm outbreak or virus infestation, or the piracy of the organization's software, impact the business at a lesser extent than priority 1 incidents. Generally speaking, the pubic is not aware of these types of incidents, and there has been no unauthorized disclosure of privacy protected customer data, thus these are generally considered less risk to the organization. A priority 2 incident can increase in risk however if the incident becomes known to the organization's internal customers or may become known to external customers. Slide 67 Priority 3 is a potential incident that is in the form of a security alert, or impact to a single non-critical system or component with limited impact in scope. These include investigations into the conduct of a single employee, and other types of employee misconduct investigations. Priority three may also include the residual cleanup of worms, viruses or patching on the last 5% of network systems. Incidents are prioritized according to a predefined threshold like above and at times may be given the wrong priority initially because of someone over riding the priority due to position, their interpretation of the priority code, urgency of the service or the severity of the incident due to time constraints. This does happen at the Help Desk level when assigning priorities to incidents but it is rectified by the Computer Security Incident Response Team and the priority may be changed and if changed it is documented in the Incident Log for accountability. Slide 68 A Service Request is a predefined planned event enabling an IT organization to carry out a request at a certain time so that it does not impact operations. A Service Request is different from a incident because a Service Request is planned ahead of time and an incident is real-time and may come suddenly or released slowly throughout time. A Service Request may be determined at the Help Desk level so that a determination can be made to handle the request at the Service Level stage or escalate it up to the Incident Management or Change Management processes. A Service Level Request could be as follows: Network maintenance outage Relocation of CPU's due to office change Backup Storage



Batch processing Facilities maintenance repair Schedule virus scanning The Service Request process is documented and defined in procedures for the entire organization. The Help Desk may have more detailed procedures on what constitutes a Service Request and have the procedures readily available to assist any personnel in filling them out. The Help Desk may be considered an information resource for users or customers to call and ask general questions regarding services or procedures to obtain them so they can submit a Service Request. Slide 69 Problem Management's focus is on identifying the unknown or underlying causes (Root Cause) of Incidents. A workaround or alternative will be provided to Service Desk, if feasible, while the Problem Investigation and Diagnosis takes place. Problem Management's is characterized by an unknown underlying cause of an Incident. Sources of potential Problems may be as follows: Multiple Incidents with common symptoms Major Incident Recurring Incidents Project Activities Declared by Management Non-matches to Problem Records Slide 70 Problem Management has responsibility for: Providing Workarounds or alternatives in the event the error occurs again Reviewing Workarounds or alternatives produced in Manage Incident for validity and soundness in the event the error recurs or is ongoing Opening Known Error Records on identification of Root Cause and a Workaround Problem Management does not have responsibility for Resolving Incidents. Problem Management works closely with Incident Management and Change Management for resolution or a possible temporary workaround. A temporary workaround may be needed for such reasons as it is a holiday weekend and the Change Control Board will not meet for another week and the severity or impact of the change or incident is minimum to the organization. If a workaround is used the ticket should remain open until a full resolution has been implemented. Slide 71 What is the difference between an Incident, a Problem and a Known Error? The difference is in their focus and timeline: Incident Controls aims to restore service as quickly and efficiently as possible and is not concerned with discovering the Root Cause. Problem Control seeks to identify the Root Cause of an Error to provide a Workaround or alternative. While Manage Problem provides Workarounds where possible, it does not have responsibility for restoring service and recovery activities. Error Control seeks to permanently resolve errors from the IT Infrastructure once Root Cause and a Workaround have been identified.



Slide 72 Known Error's focus is on permanently resolving the Root Cause via Request for Change (RFC). Known Error is characterized by a problem for which a Root Cause and Workaround have been identified and a permanent resolution is being sought. Sources of Known Errors are as follows: A problem with Root Cause and a Workaround identified Project Activities Vendor/Industry information where Root Cause and a Workaround or alternative have been identified Known Error has responsibility for permanently resolving errors in the IT infrastructure. Known Error does not have responsibility for resolving Incidents or providing Workarounds or alternatives. The Known Error database keeps an account of all previously reported incidents and problems in detailed format providing descriptions of the fault, symptoms, impact, resolutions, metrics, and workaround so that the Help Desk may be able provide a quicker diagnosis and response to a resolution. Slide 73 Communication is instrumental throughout the entire ITIL lifecycle and is considered a valued commodity to an organization and the customers and business partners they have Service Level Agreements with. Communications and Systems security management is fundamental to the protection of the confidentiality, integrity, availability, authenticity, and non-repudiation characteristics of information and assets of an organization. How an organization handles communication should documented in a Communication Policy. The policy should describe all the different types of communication and how communication will be governed across the organization internally for Service Operation and externally with customers, business partners, and the media. Slide 74 Communication should have a sender and a receiver and a purpose for the communication resulting in action. Communication takes place in many forums through service delivery such as: Routine Operational Shift communication Performance Reporting Project Management Change Management Emergencies Exceptions Users and Customers An IT organization needs to ensure that routine operational communication is effective throughout the organization in communicating: Operational logs on shift changes Incident management reports regarding notification through resolution Problem management analysis regarding root cause and resolution Scheduled network infrastructure maintenance Change management schedule regarding when changes will be implemented into production Slide 75 Shift communications are very important to ensure that operations continue to run effectively on a 24



hour basis. Shift communications usually take place in a shift or section log which all incidents, problems, known errors, system changes, staff accountability, exceptions, alerts, services started, completed, and outstanding, and any communications from management regarding policy, procedures, staff, or operations. Performance reporting is done ad hoc in an IT organization and not necessary reported on a weekly, daily, or monthly schedule. Each IT organization will define what best fits their organization. Performance reporting is important for IT staff working on delivering customer services. Performance reporting informs staff on how they are meeting the services their organization agreed to in the Service Level Agreement. Performance reporting enables IT management to make continual service improvements to enhance services to the customer and communications with staff resulting in quality service. Slide 76 Project communications is performed through status reports and team meetings. Status reports and meetings enable the project manager to provide project status to stakeholders. Meetings enable the project manager to identify strengths and weaknesses in the project, assign work breakdown, and ensure project meets project objectives outlined in the project charter. In order to ensure that communication among key players is effective in a project, the project team should develop a formal Communication Plan. This document: Identifies key project stakeholders Lists what types of information are of most value to our stakeholders Identify optimum means of communication and format Establish the purpose, timing, location and attendees for regular meetings State which communication vehicles will be used and whether any steps are required to put them in place Includes specific steps that the project team and stakeholders can take to keep everyone who will be impacted by the project well informed Slide 77 Communications of System Changes are made through a change management plan which requires the development of a communication plan to effectively communicate the change throughout the organization. Customer notification should be completed for each scheduled or unscheduled change following the steps contained in a Change Management Plan and Communications Plan. A fallback procedure needs to be communicated effectively so staff knows the contingency to abort or revoke the change, returning the system to pre-change condition, in the event of unsuccessful implementation of the change or unforeseen events interfering with the change implementation. Communication regarding change is through the following: Change Management Policy Change Management Procedures Request for Change Staff meetings Change Advisory Board Release plans Scheduled maintenance reports Change Reviews Monitoring Activity logs Slide 78 Communication through exception reporting is usually performed in Incident Management when an incident is outside the normal or expected performance of the system or processes being performed to service a customer. Exception reporting may result from context sources such as: Process reviews



Change reviews Service Level reviews, trend analysis of processes, devices, team performance Incident, Problem and Change records Customer satisfaction surveys Slide 79 Communication resulting from emergencies is very valuable to an IT organization. Emergency communication is not in relation to ITIL business continuity but deals with Incident and Problem management. This type of communication only occurs when an incident happens. The incident has to be determined immediately if it falls under the criteria to activate the business continuity or disaster recovery plan, is a problem, or an incident resulting activation of the Computer Security Incident Response Team. Determination may be made through the following context or sources: Computer Security Incident Response Team meetings Incident record for major incidents Events Emergency change order meetings Slide 80 Communication with Users and Customers is very important for continual service Improvement. The IT organization needs to communicate frequently with customers to ensure that they are meeting the service expectations that are documented in the Service Level Agreement. This will enable the IT organization to improve their services and provide better quality to the customer. The IT organization communicates with the customer on a number of other things during normal operations and obligated services documented in the Service Level Agreement such as: Notification of breaches within the organization that may impact the customer Notification of business continuity and disaster recovery development, maintenance upkeep, testing and training Service Request scheduling Incident Management notification and resolution impacting the customer services Change Management solutions impacting the customer services Security Issues impacting the customer services as well as internal services and resources Customer satisfaction surveys Continuity of Operations and Disaster Recovery Planning Customer requirement changes impacting services being delivered

Topic 2.2 Exercises

Exercise 1 Use what you've learned about ITIL to complete the lists described below.

Step Action

1 List some of the Utilities and Warranties provided by your organization to internal customers (other business units) and externally to customers or business partners.

2 List some of the Capabilities and Resources provided by your organization to customers or business partners.

3 List some of the Business Services and Technical Services provided by your organization to customers or business partners.



© 2008 MindLeaders, Inc. All Rights Reserved.

4 List some of the risks to your organization that would require your organization to perform risk mitigation.

5 List some of the internal and external suppliers that supply services to your IT organization.

6 List some of the internal Operational Level Agreements and external Service Level Agreements of your IT organization.

7 List some of the internal Configuration Items used by your IT organization.

8 List some of the changes you know that have been made in your organization.

9 List the 7 R's of Change Management.

10 List the first step you are to perform in your organization when you encounter an incident.

11 List some of the different types of incidents that have happened in the past or that are recurring in your organization.

12 List the communications types you have seen in your organization.



Documents

3 Generic Concepts