Downloaded 263 times
Uploaded byRasha Ragab
ITIL service design
The document outlines the ITIL V3 Service Design framework, emphasizing the alignment of IT services with business needs through processes such as service catalogue management, service level management, and capacity management. It details the objectives and responsibilities within these processes, including defining service targets, managing service availability, and ensuring supplier contracts meet business requirements. Additionally, it discusses the importance of monitoring, measuring, and continuous improvement in service delivery to enhance customer satisfaction and maintain operational efficiency.
ITIL service design
- 1. ITIL V3 ServiceDesign Eng. Rasha Ragab IT Asst. Business partner – Project manager Eng. Rasha Ragab Ahmed PMP – ITIL Service Design certified http://eg.linkedin.com/pub/rasha-ragab/18/8a6/839/ Eng.RashaRagab21@gmail.com – Rasha.Ragab@unilever.com 8th march 2014
- 2. ITIL and goodpractice in Service Management ITIL Framework is a source of good practice in Service Management. The primary objective of Service Management is to ensure that the IT services are aligned to the business needs and actively support them.
- 3.
- 4. Processes in ServiceDesign 1. Service Catalogue Management 2. Service Level Management 3. Capacity Management 4. Information Security Management 5. Availability Management 6. ITSCM (disaster recovery) 7. Supplier Management
- 5. Service Level Management •Service Level Management is responsible for defining the service targets that are used to measure value. • The Service Level Management process purpose is to make sure that all current and planned services are delivered to agreed, achievable targets. • To do this, Service Level Management will negotiate, agree, monitor, report and review IT service targets and achievements. They will also take corrective action when targets are not achieved, and initiate improvements to services.
- 6. Exercise Service Level Managementneeds to develop templates for SLAs. Draw up your own template. What needs to be included in the document? For example, you’ll need a service description. Try and think of at least 10 things that need to be included.
- 7. Things you mightfind in an SLA Service Description Hours of operation Incident Response times Resolution times Availability & Continuity targets Customer Responsibilities Critical operational periods Change Response Times
- 8. Process Purpose andObjectives • Make sure all IT services have targets in place • Monitoring and trying to improve customer satisfaction • Making sure IT and the customer have a clear and unambiguous understanding of the level of service to be delivered
- 9. In case ofnew services: • For new services, Service Level Management will produce a set of agreed Service Level Requirements. • These document what the customer wants, and are signed off so that everyone understands what has been agreed.
- 10. • Service LevelAgreement (SLA) – Operational Level Agreements • Internal – Underpinning Contracts (“SLAs are for service management, contract is for the court ...”) • External Organisation • Supplier Management – Should be clear and fair and written in easy-to- understand, unambiguous language • Success of SLM: Key Performance Indicators (KPIs) – How many services have SLAs? – How does the number of breaches of SLA change over time (we hope it reduces!)?
- 11. The Service Catalogueis the part of the Service Portfolio which provides a view of live services. The catalogue is the part of the portfolio that is visible to customers. Service Catalogue Management
- 12. Service Catalogue Management Objectives: Thegoal of the Service Catalogue Management process is to ensure that a Service Catalogue is produced and maintained, containing accurate information on all operational services and those being prepared to be run operationally.
- 13. Service Catalogue Management ActivitiesInclude: •Definition of the service •Production and maintenance of an accurate Service Catalogue •Interfaces, dependencies and consistency between the Service Catalogue and Service Portfolio •Interfaces and dependencies between all services and supporting services within the Service Catalogue and the CMS •Interfaces and dependencies between all services, and supporting components and Configuration Items (CIs) within the Service Catalogue and the CMS. What is a service?
- 14. Availability Management The goalof the Availability Management process is to ensure that the level of service availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner. Availability management defines, analyses, plans, measures and improves all aspects of the availability of IT services
- 15. •Service availability isat the core of customer satisfaction and business success: poor service performance is defined as being unavailable. •Recognizing that when services fail, it is still possible to achieve business, customer and user satisfaction and recognition •Service availability is only as good as the weakest link on the chain: it can be greatly increased by the elimination of Single Points of Failure (SPoFs) •It is cheaper to design the right level of service availability into a service from the start rather than try and ‘bolt it on’ subsequently. Don’t forget
- 16. Availability: the abilityof a service, component or CI to perform its agreed function when required. It is often measured and reported as a percentage: (Agreed Service Time (AST) – downtime) Availability (%) = ------------------------------------------------------- X 100 % Agreed Service Time (AST) Reliability: a measure of how long a service, component or CI can perform its agreed function without interruption. It is often measured and reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between Failures (MTBF): Available time in hours Reliability (MTBSI in hours) = ------------------------------------------ Number of breaks Available time in hours – Total downtime in hours Reliability (MTBF in hours) = ---------------------------------------------------------------------- Number of breaks How to measure it ?
- 17. situation where a24 x 7 service has been running for a period of 5,020 hours with only two breaks, one of six hours and one of 14 hours, would give the following figures: Availability = (5,020–(6+14)) / 5,020 x 100 = 99.60% Reliability (MTBSI) = 5,020 / 2 = 2,510 hours Reliability (MTBF) = 5,020–(6+14) / 2 = 2,500 hours The Availability Management process depends heavily on the measurement of service and component achievements with regard to availability.
- 18. Availability Management challenges the mainchallenge is to actually meet the expectations of the customers, the business and senior management. These expectations are that services will always be available not just during their agreed service hours, but that all services will be available on a 24-hour, 365-day basis. Yet another challenge facing Availability Management is convincing the business and senior management of the investment needed in proactive availability measures. Investment is always recognized once failures have occurred, but by then it is really too late.
- 19. Capacity Management ‘The goalof the Capacity Management process is to ensure that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner’. The purpose of Capacity Management is to provide a point of focus and management for all capacity- and performance- related issues, relating to both services and resources.
- 20. •Monitoring patterns ofbusiness activity and service-level plans. •Undertaking tuning activities to make the most efficient use of existing IT resources •Understanding the agreed current and future demands being made by the customer for IT resources. •producing forecasts for future requirements •Producing a Capacity Plan that enables the service provider to continue to provide services of the quality defined in SLAs. •Assistance with the identification and resolution of any incidents and problems associated with service or component performance The Capacity Management process should include:
- 21. Business Capacity Management Thissub-process translates business needs and plans into requirements for service and IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned and implemented in a timely fashion. Service Capacity Management The focus of this sub-process is the management, control and prediction of the end- to-end performance and capacity of the live, operational IT services usage and workloads. Component Capacity Management The focus in this sub-process is the management, control and prediction of the performance, utilization and capacity of individual IT technology components. Capacity Management sub – processes:
- 22. Monitoring The monitors shouldbe specific to particular operating systems, hardware configurations, applications, etc. It is important that the monitors can collect all the data required by the Capacity Management process, for a specific component or service. Typical monitored data includes: •Processor utilization •Memory utilization •Per cent processor per transaction type •IO rates (physical and buffer) and device utilization •Queue lengths •Disk utilization •Transaction rates •Response times •Batch duration •Database usage •Concurrent user numbers •Network traffic rates.
- 23. Information Security Management •Confidentiality – Making sure only those authorised can see data • Integrity – Making sure the data is accurate and not corrupted • Availability – Making sure data is supplied when it is requested
- 24. Supplier Management • Toensure that all contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments: – Providing the Supplier Management Framework – Evaluation of New Suppliers and Contracts – Establishing New Suppliers and Contracts – Processing of Standard Orders – Supplier and Contract Review – Contract Renewal or Termination
- 25. Continual service improvementin service design
Editor's Notes
- #3 If IT processes and IT services are implemented, managed and supported in the appropriate way, the business will be more successful, suffer less disruption and loss of productive hours, reduce costs, increase revenue, improve public relations and achieve its business objectives.
- #4 The Four P’s is a model, not a process. So it would not be accurate to describe the four P’s as a “four step process” – instead, it should be seen as four areas that need to be considered as a model for the effective design of service management. People People considerations are vital for all ITIL initiatives, projects and enhancements. Education and awareness, communication, and expectation setting are all part of the people considerations. Think about what would happen if you didn’t tell anyone what you were trying to do – with a new service for example. You would experience resentment and resistance from your Stakeholders. This is why education, awareness, communication and expectation setting are so important. Process Processes need to be defined and documented. If processes are not documented, inconsistencies will develop over time as people adapt it. It’s hard to track a process effectively it isn’t not documented. Partners Very few organizations work in isolation. They use third parties who supply goods and services from consultants and contractors through to software and tooling suppliers. Products Products are any of the tools or products that we use to help us provide, manage and measure our services.
- #10 Every IT service should have targets documented as part of their Service Design. Service Level Management has a major role to play during Service Design when targets are agreed.
- #13 The purpose of Service Catalogue Management is to provide a single source of consistent information on all of the agreed services, and ensure that it is widely available to those who are approved to access it. The goal of the Service Catalogue Management process is to ensure that a Service Catalogue is produced and maintained, containing accurate information on all operational services and those being prepared to be run operationally.
- #14 What is a service? This question is not as easy to answer as it may first appear, and many organizations have failed to come up with a clear definition in an IT context. IT staff often confuse a ‘service’ as perceived by the customer with an IT system. In many cases one ‘service’ can be made up of other ‘services’ (and so on), which are themselves made up of one or more IT systems within an overall infrastructure including hardware, software, networks, together with environments, data and applications. A good starting point is often to ask customers which IT services they use and how those services map onto and support their business processes. Customers often have a greater clarity of what they believe a service to be. Each organization needs to develop a policy of what is a service and how it is defined and agreed within their own organization. To avoid confusion, it may be a good idea to define a hierarchy of services within the Service Catalogue, by qualifying exactly what type of service is recorded, e.g. business service (that which is seen by the customer). Alternatively, supporting services, such as infrastructure services, network services, application services (all invisible to the customer, but essential to the delivery of IT services) will also need to be recorded. This often gives rise to a hierarchy of services incorporating customer services and other related services, including supporting services, shared services and commodity services, each with defined and agreed service levels. Each organization should develop and maintain a policy with regard to both the Portfolio and the Catalogue, relating to the services recorded within them, what details are recorded and what statuses are recorded for each of the services. The policy should also contain details of responsibilities for each section of the overall Service Portfolio and the scope of each of the constituent sections.
- #15 The goal of the Availability Management process is to ensure that the level of service availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner. Availability management defines, analyses, plans, measures and improves all aspects of the availability of IT services, ensuring that all IT infrastructure, processes, tools, roles,.. The objectives of Availability Management are to: Produce and maintain an appropriate and up-to-date Availability Plan that reflects the current and future needs of the business Provide advice and guidance to all other areas of the business and IT on all availability-related issues Ensure that service availability achievements meet or exceed all their agreed targets, by managing services and resources-related availability performance Assist with the diagnosis and resolution of availability-related incidents and problems Assess the impact of all changes on the Availability Plan and the performance and capacity of all services and resources Ensure that proactive measures to improve the availability of services are implemented wherever it is cost-justifiable to do so.
- #17 effective Availability Management process, consisting of both the reactive and proactive activities, can ‘make a big difference’ and will be recognized as such by the business Service availability is at the core of customer satisfaction and business success: there is a direct correlation in most organizations between the service availability and customer and user satisfaction, where poor service performance is defined as being unavailable. Recognizing that when services fail, it is still possible to achieve business, customer and user satisfaction and recognition: the way a service provider reacts in a failure situation has a major influence on customer and user perception and expectation. Improving availability can only begin after understanding how the IT services support the operation of the business. Service availability is only as good as the weakest link on the chain: it can be greatly increased by the elimination of Single Points of Failure (SPoFs) or an unreliable or weak component. Availability is not just a reactive process. The more proactive the process, the better service availability will be. Availability should not purely react to service and component failure. The more events and failures are predicted, pre-empted and prevented, the higher the level of service availability. It is cheaper to design the right level of service availability into a service from the start rather than try and ‘bolt it on’ subsequently. Adding resilience into a service or component is invariably more expensive than designing it in from the start. Also, once a service gets a bad name for unreliability, it becomes very difficult to change the image. Resilience is also a key consideration of ITSCM, and this should be considered at the same time.
- #18 Note: Downtime should only be included in the above calculation when it occurs within the Agreed Service Time (AST). However, total downtime should also be recorded and reported. Maintainability: a measure of how quickly and effectively a service, component or CI can be restored to normal working after a failure. It is measured and reported as Mean Time to Restore Service (MTRS) and should be calculated using the following formula: Total downtime in hours
- #20 Availability Management faces many challenges, but probably the main challenge is to actually meet the expectations of the customers, the business and senior management. These expectations are that services will always be available not just during their agreed service hours, but that all services will be available on a 24-hour, 365-day basis. When they aren’t, it is assumed that they will be recovered within minutes. This is only the case when the appropriate level of investment and design has been applied to the service, and this should only be made where the business impact justifies that level of investment. However, the message needs to be publicized to all customers and areas of the business, so that when services do fail they have the right level of expectation on their recovery. It also means that Availability Management must have access to the right level of quality information on the current business need for IT services and its plans for the future. This is another challenge faced by many Availability Management processes. Yet another challenge facing Availability Management is convincing the business and senior management of the investment needed in proactive availability measures. Investment is always recognized once failures have occurred, but by then it is really too late. Persuading businesses and customers to invest in resilience to avoid the possibility of failures that may happen is a difficult challenge. Availability Management should work closely with Service Continuity Management, Security Management and Capacity Management in producing the justifications necessary to secure the appropriate investment.
- #23 Monitoring patterns of business activity and service-level plans through performance, utilization and throughput of IT services and the supporting infrastructure, environmental, data and applications components and the production of regular and ad hoc reports on service and component capacity and performance Undertaking tuning activities to make the most efficient use of existing IT resources Understanding the agreed current and future demands being made by the customer for IT resources, and producing forecasts for future requirements Producing a Capacity Plan that enables the service provider to continue to provide services of the quality defined in SLAs and that covers a sufficient planning timeframe to meet future service levels required as defined in the Service Portfolio and SLRs Assistance with the identification and resolution of any incidents and problems associated with service or component performance
- #25 The monitors should be specific to particular operating systems, hardware configurations, applications, etc. It is important that the monitors can collect all the data required by the Capacity Management process, for a specific component or service. Typical monitored data includes: Processor utilization Memory utilization Per cent processor per transaction type IO rates (physical and buffer) and device utilization Queue lengths Disk utilization Transaction rates Response times Batch duration Database usage Index usage Hit rates Concurrent user numbers Network traffic rates. In considering the data that needs to be included, a distinction needs to be drawn between the data collected to monitor capacity (e.g. throughput) and the data to monitor performance (e.g. response times). Data of both types is required by the Service and Component Capacity Management sub-processes.