service level framework
DESCRIPTION
Service Level Framework. Hendershott Consulting Inc web Presence: www.hci-itil.com Email: [email protected]. Service Design / SLA Architecture. Services. - PowerPoint PPT PresentationTRANSCRIPT
HCI-ITIL Video
Service Level Framework
Hendershott Consulting Inc
web Presence: www.hci-itil.comEmail: [email protected] Design / SLA Architecture
Service Design / SLA ArchitectureServices
Services are a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.ITIL Service Design Section 2.2.1
Service Design / SLA ArchitectureService Portfolio Management
A Service Portfolio describes services in terms of business value. ITIL Service Strategy Section 5.3Service Portfolio Management is the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities and has an explicitly directive, strategic goal in determining what to continue investing in versus what to divest from.WikipediaAt its most mature, IT Portfolio Management is accomplished through the creation of two generic requirement sources:Application Portfolio - focuses on comparing spending on established systems based upon their relative value to the organization.Project Portfolio - addresses the issues with spending on the development of innovative capabilities in terms of potential ROI and reducing investment overlaps in situations where reorganization or acquisition occurs.
The Service Portfolio represents the commitments and investments made by a service provider across all customers and market spaces. It represents present contractual commitments, new service development, and ongoing service improvement plans initiated by Continual Service Improvement. The portfolio also includes third-party services, which are an integral part of service offerings to customers. Some third-party services are visible to the customers while others are not.
At its most mature, IT Portfolio management is accomplished through the creation of two portfolios:Application Portfolio - Management of this portfolio focuses on comparing spending on established systems based upon their relative value to the organization. The comparison can be based upon the level of contribution in terms of IT investments profitability. Additionally, this comparison can also be based upon the non-tangible factors such as organizations level of experience with a certain technology, users familiarity with the applications and infrastructure, and external forces such as emergence of new technologies and obsolesce of old ones.Project Portfolio - This type of portfolio management specially address the issues with spending on the development of innovative capabilities in terms of potential ROI and reducing investment overlaps in situations where reorganization or acquisition occurs. The management issues with the second type of portfolio management can be judged in terms of data cleanliness, maintenance savings, suitability of resulting solution and the relative value of new investments to replace these projects.
3
BIAServiceValuation
Demand
Service Design / SLA ArchitectureService Lifecycle
ApplicationPortfolio
ProjectPortfolio
Service Portfolio
BIAServiceValuation
Demand
Service Design / SLA ArchitectureService Lifecycle
ApplicationPortfolio
ProjectPortfolio
Service PortfolioNewChangeNewNewNewChange
BIAServiceValuation
Demand
Service Design / SLA ArchitectureService Lifecycle
ApplicationPortfolio
ProjectPortfolio
Service PortfolioNewChangeNewNewNewChangeService RequirementsService Design / SLA ArchitectureService Requirements
Information TechnologyService ManagementBusinessProcess321BusinessProcess654BusinessProcess987Business Unit ABusiness Unit BBusiness Unit CThe BusinessEnterpriseService CBASLAsEnvironmentDataApplicationsSystemS/WDBMSSystemH/WNetworksInfrastructureUCsSupportingServiceCBAOLAs
Teams
Suppliers
No service can be designed, transitioned and operated in isolation. The relationship of each service to its supporting components and services must be clearly understood and recognized.ITIL Service Design Section 3.3The scalability of the service to meet future requirements, in support of the long-term business objectivesThe business processes and business units supported by the serviceThe IT service and the agreed business functionality and requirementsThe service itself and its Service Level Requirement (SLR) or Service Level Agreement (SLA)The technology components used to deploy and deliver the service, including the infrastructure, the environment, the data and the applicationsThe internally supported services and components and their associated Operational Level Agreements (OLAs)The externally supported services and components and their associated underpinning contracts, which will often have their own related agreements and/or schedulesThe performance measurements and metrics requiredThe legislated or required security levels.Service Design / Figure 3.7 The Service Portfolio & its ContentsRequirements: a set of outline requirements have been received from the business or IT for a new or changed service Defined: the set of requirements for the new service are being assessed, defined and documented and the SLR is being produced Analyzed: the set of requirements for the new service are being analyzed and prioritized Approved: the set of requirements for the new service have been finalized and authorized Chartered: the new service requirements are being communicated and resources and budgets allocated Designed: the new service and its constituent components are being designed and procured, if required Developed: the service and its constituent components are being developed or harvested, if applicable Built: the service and its constituent components are being built Tested: the service and its constituent components are being tested Released: the service and its constituent components are being released Operational: the service and its constituent components are operational within the live environment Retired: the service and its constituent components have been retired..SKMSService PortfolioService LifecycleService PipelineService CatalogueRetired ServiceService DesignService Design / Figure 3.7 The Service Portfolio & its ContentsRequirements: a set of outline requirements have been received from the business or IT for a new or changed service Defined: the set of requirements for the new service are being assessed, defined and documented and the SLR is being produced Analyzed: the set of requirements for the new service are being analyzed and prioritized Approved: the set of requirements for the new service have been finalized and authorized Chartered: the new service requirements are being communicated and resources and budgets allocated Designed: the new service and its constituent components are being designed and procured, if required Developed: the service and its constituent components are being developed or harvested, if applicable Built: the service and its constituent components are being built Tested: the service and its constituent components are being tested Released: the service and its constituent components are being released Operational: the service and its constituent components are operational within the live environment Retired: the service and its constituent components have been retired..SKMSService PortfolioService LifecycleService PipelineService CatalogueRetired ServiceArchitecting the ServiceService Design / Figure 3.7 The Service Portfolio & its ContentsSKMSService PortfolioService LifecycleService PipelineService CatalogueRetired ServiceService Catalogue
Source of consistent information on all of the agreed servicesBusiness Service Catalogue details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalogue.Technical Service Catalogue details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and Cls necessary to support the provision of the service to the business.
Service Design / Figure 3.7 The Service Portfolio & its ContentsService Level ManagementNegotiates, agrees and documents appropriate IT service targets with representatives of the business, and then monitors and produces reports on the service provider's ability to deliver the agreed level of service.
Service Design / Figure 3.7 The Service Portfolio & its ContentsService Level AgreementNegotiates, agrees and documents appropriate IT service targets with representatives of the business, and then monitors and produces reports on the service provider's ability to deliver the agreed level of service.
Service Design / Figure 3.7 The Service Portfolio & its ContentsService Level Agreement
Service Design / Figure 3.7 The Service Portfolio & its ContentsService Level Agreement
A written agreement between an IT service provider and the IT customer(s), defining the key service targets and responsibilities of both parties.
The emphasis must be on agreement, and SLAs should not be used as a way of holding one side or the other to ransom. A true partnership should be developed between the IT service provider and the customer, so that a mutually beneficial agreement is reached - otherwise the SLA could quickly fall into disrepute and a 'blame culture' could develop that would prevent any true service quality improvements from taking place.
14Service Design / SLA ArchitectureSLA FrameworksService-Based SLAsSLA covers one service,
BU ABU B
BU C
BU D
The Business Enterprisefor all the customers of that service
Service AFor example, an SLA may be established for an organization's e-mail service - covering all the customers of that service. This may appear fairly straightforward. However, difficulties may arise if the specific requirements of different customers vary for the same service, or if characteristics of the infrastructure mean that different service levels are inevitable (e.g. head office staff may be connected via a high-speed LAN, while local offices may have to use a lower-speed WAN line). In such cases, separate targets may be needed within the one agreement. Difficulties may also arise in determining who should be the signatories to such an agreement. However, where common levels of service are provided across all areas of the business, e.g. e-mail or telephony, the service-based SLA can be an efficient approach to use. Multiple classes of service, e.g. gold, silver and bronze, can also be used to increase the effectiveness of service-based SLAs.15Service Design / SLA ArchitectureSLA FrameworksCustomer-Based SLAsCovers an individual customer group,
BU AThe Business Enterprisefor all the services they use
Service A
Service C
Service D
Service F
Service E
Service B
For example, agreements may be reached with an organization's finance department covering, say, the finance system, the accounting system, the payroll system, the billing system, the procurement system, and any other IT systems that they use. Customers often prefer such an agreement, as all of their requirements are covered in a single document. Only one signatory is normally required, which simplifies this issue.16Service Design / SLA ArchitectureSLA FrameworksMulti-Level SLAsCombinations of the above frameworks, to avoid duplication and complexity.
Service A
Service C
Service D
Service F
Service E
Service B
BU ABU B
BU C
BU D
The Business EnterpriseCorporate-Wide: covering all the generic SLM issues appropriate to every customer throughout the organization.
Issues with regard to enterprise service offerings are likely to be less volatile, so updates will not be required as frequently as more tailored offerings.
17Service Design / SLA ArchitectureSLA FrameworksMulti-Level SLAsCombinations of the above frameworks, to avoid duplication and complexity.
Service A
Service C
Service D
Service F
Service E
Service B
BU ABU B
BU C
BU D
The Business EnterpriseCustomer Specific: covering all SLM issues relevant to the particular customer group or business unit, regardless of the service referenced.
Not every Business Unit will have the same mix or, for that matter, service levels, of services
18Service Design / SLA ArchitectureSLA FrameworksMulti-Level SLAsCombinations of the above frameworks, to avoid duplication and complexity.
Service A
Service C
Service D
Service F
Service E
Service B
BU ABU B
BU C
BU D
The Business EnterpriseTailored: covering all SLM issues relevant to the specific service, in relation to a specific customer group (one for each service covered by the SLA).
These can be considered exceptions, often applications entirely within the domain of a specific Business Unit.19Service Design / SLA ArchitectureSLA FrameworksMulti-Level SLAsCombinations of the above frameworks, to avoid duplication and complexity.
Service A
Service C
Service D
Service F
Service E
Service B
BU ABU B
BU C
BU D
The Business EnterpriseThe Service Level Framework20Hendershott Consulting Inc
Email: [email protected] process site: hci-itil.com