Checklist Service Design Package SDP: Difference between revisions

From IT Process Wiki
No edit summary
No edit summary
Line 7: Line 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="SDP ITIL">Overview</span> ==


'''ITIL Process''': [[ITIL V3 Service Design|ITIL 2011 Service Design]] - [[ITIL Design Coordination|Design Coordination]]
'''ITIL Process''': [[ITIL V3 Service Design|ITIL 2011 Service Design]] - [[ITIL Design Coordination|Design Coordination]]
Line 23: Line 25:


'''The Service Design Package contains the following information (the actual level of detail will vary, depending on the type of service):'''
'''The Service Design Package contains the following information (the actual level of detail will vary, depending on the type of service):'''
<p>&nbsp;</p>
__TOC__


<p>&nbsp;</p>
<p>&nbsp;</p>


==== Service Design Package - Part 1: Header ====
== Part I: Header ==


# Name of the service  
This part describes the header data contained in a Service Design Package.
# Service Owner responsible for delivering the service
 
# Clearance information (with location and date)  
==== Name of the service ====
## Clearance of the [[Roles within ITIL V3#Service Design Manager|Service Design Manager]]
 
## Clearance of the Service Design Package by Service Management (confirmation that the requirements as laid out in this document are able to be fulfilled and where necessary, specification of any preconditions which must be fulfilled before the service can go operational)  
==== Service Owner responsible for delivering the service ====
### [[Roles within ITIL V3#Capacity Manager|Capacity Manager]]
 
### [[Roles within ITIL V3#Availability Manager|Availability Manager ]]
==== Clearance information ====
### [[Roles within ITIL V3#IT Service Continuity Manager|IT Service Continuity Manager]]
(with location and date)  
### [[Roles within ITIL V3#Information Security Manager|Information Security Manager]]  
# Clearance of the [[Roles within ITIL V3#Service Design Manager|Service Design Manager]]
### [[Roles within ITIL V3#Compliance Manager|Compliance Manager]]
# Clearance of the Service Design Package by Service Management (confirmation that the requirements as laid out in this document are able to be fulfilled and where necessary, specification of any preconditions which must be fulfilled before the service can go operational)  
### [[Roles within ITIL V3#Financial Manager|Financial Manager]]
## [[Roles within ITIL V3#Capacity Manager|Capacity Manager]]
## [[Roles within ITIL V3#Availability Manager|Availability Manager ]]
## [[Roles within ITIL V3#IT Service Continuity Manager|IT Service Continuity Manager]]
## [[Roles within ITIL V3#Information Security Manager|Information Security Manager]]  
## [[Roles within ITIL V3#Compliance Manager|Compliance Manager]]
## [[Roles within ITIL V3#Financial Manager|Financial Manager]]


<p>&nbsp;</p>
<p>&nbsp;</p>


==== Service Design Package - Part 2: Detailed Requirements Specification as a Basis for Service Transition ====
== Part II: Detailed Requirements Specification as a Basis for Service Transition ==


This part builds upon the [[Service Level Management#SLR|Service Level Requirements]] and specifies in more detail what conditions the new service and its underlying applications and infrastructure must fulfill, providing all information which is needed for building the new service.
This part builds upon the [[Service Level Management#SLR|Service Level Requirements]] and specifies in more detail what conditions the new service and its underlying applications and infrastructure must fulfill, providing all information which is needed for building the new service.


# Service level requirements (reference to the [[Service Level Management#SLR|SLR]] document, where service level requirements are defined)
==== Service level requirements ====
# Functional requirements (the SLR document contains a summary description of the desired customer outcome; however, functional requirements may need to be specified in greater detail, especially if new applications/ systems are to be developed)  
''(reference to the [[Service Level Management#SLR|SLR]] document, where service level requirements are defined)''
# Information security requirements which are relevant for the service
 
# Compliance requirements which are relevant for the service
==== Functional requirements ====
# Architectural constraints (e.g. specific technology or vendors)
(the SLR document contains a summary description of the desired customer outcome; however, functional requirements may need to be specified in greater detail, especially if new applications/ systems are to be developed)  
# Interface requirements (e.g. if a new system needs to communicate with other systems)
 
# Migration requirements (e.g. if data are to be migrated from an existing to a new application)
==== Information security requirements ====
# Operational requirements (e.g. requirements for backup and restore mechanisms, compatibility with existing system monitoring tools)
(Information security requirements which are relevant for the service)
# Required access rights (which users or user groups will require access to the service, and what levels of access must be provided)
 
==== Compliance requirements ====
(Compliance requirements which are relevant for the service)
 
==== Architectural constraints ====
(e.g. specific technology or vendors)
 
==== Interface requirements ====
(e.g. if a new system needs to communicate with other systems)
 
==== Migration requirements ====
(e.g. if data are to be migrated from an existing to a new application)
 
==== Operational requirements ====
(e.g. requirements for backup and restore mechanisms, compatibility with existing system monitoring tools)
 
==== Required access rights ====
(which users or user groups will require access to the service, and what levels of access must be provided)


<p>&nbsp;</p>
<p>&nbsp;</p>


==== Service Design Package - Part 3: Technical and Organizational Implementation Blueprint ====
== Part III: Service Operation and Improvement Concepts ==
 
This part details how the service will be operated and continually improved, including the associated responsibilities, and what is required to do so.
 
==== Service Operation ====
# Approach to managing risks and issues
# Required monitoring, measuring and reporting
# Requirements with regards to operational functions, e.g. procedures and activities required on operational level to operate the service
# Required operational and end-user documentation
# Human resources as well as skills required to operate the service
 
==== Continual Service Improvement ====
# Approach and mechanisms to continually improve the service
# Human resources as well as skills required to improve the service
 
<p>&nbsp;</p>
 
== Part IV: Technical and Organizational Implementation Blueprint ==


This part details what must be done during [[ITIL V3 Service Transition|Service Transition]] to meet the specified requirements.
This part details what must be done during [[ITIL V3 Service Transition|Service Transition]] to meet the specified requirements.


# Transition strategy (a brief outline of the selected approach to implementing the new service)
==== Decomposition of the Business Service into Infrastructure Services ====
## Testing strategy
# Internal Infrastructure Services on which this service is based   
## Deployment strategy
## Names of the infrastructure services  
## Migration concept
## Service providers (responsible Service Owners)
## Back-out strategy in the case of a failed deployment
## References to Operational Level Agreements (OLAs)  
# Decomposition of the Business Service into Infrastructure Services
## Required changes to OLAs, if existing OLAs are not sufficient for the service to be established
## Internal Infrastructure Services on which this service is based   
# Externally supplied Supporting Services on which this service is based
### Names of the infrastructure services  
## Names of the external services  
### Service providers (responsible [[Roles within ITIL V3#Service Owner|Service Owners]])
## Name of the supplier
### References to [[Checklist SLA OLA|Operational Level Agreements (OLAs)]]
## Responsible Supplier Manager
### Required changes to OLAs, if existing OLAs are not sufficient for the service to be established
## References to Underpinning Contracts (UCs)  
## Externally supplied Supporting Services on which this service is based
## Required changes to UCs, if existing UCs do not support the introduction of the new service
### Names of the external services  
 
### Name of the supplier
==== Transition strategy ====
### Responsible Supplier Manager
(a brief outline of the selected approach to implementing the new service)
### References to [[Checklist Underpinning Contract (UC)|Underpinning Contracts (UCs)]]
# Testing strategy
### Required changes to UCs, if existing UCs do not support the introduction of the new service
# Deployment strategy
# Details on technical changes required to build, test, deploy and operate the service
# Migration concept
## Development/ customization of base applications for the service (e.g. if the service to be introduced is based on the SAP system or a custom application)
# Back-out strategy in the case of a failed deployment
## Supporting tools
# Integration with other service transition projects
### Development/ customization of migration tools
 
### Development/ customization of testing tools
==== Details on technical changes ====
### Development/ customization of deployment tools
 
### Development/ customization of back-out tools in the case of a failed release deployment
Details on technical changes required to build, test, deploy and operate the service.
## Infrastructure modifications required to build, test, deploy and operate the service
 
### Infrastructure components to be purchased and installed
# Development/ customization of base applications for the service (e.g. if the service to be introduced is based on the SAP system or a custom application)
### Infrastructure components to be (re-)configured
# Supporting tools
## Required changes to facilities
## Development/ customization of migration tools
# Organizational changes required to implement and operate the service
## Development/ customization of testing tools
## Personnel resources to be added
## Development/ customization of deployment tools
### Specification of required resources
## Development/ customization of back-out tools in the case of a failed release deployment
### Strategy for acquiring the resources
# Infrastructure modifications required to build, test, deploy and operate the service
## Skills to be developed
## Infrastructure components to be purchased and installed
### Specification of the required skills
## Infrastructure components to be (re-)configured
### Strategy for acquiring the skills
# Required changes to facilities
## Changes to processes
 
### List of IT processes which must be changed or created, including process owners
==== Organizational changes ====
### Detailed specification of required changes to IT processes, e.g. in the form of process designs
# Operational concept, e.g.
Organizational changes required to implement and operate the service.
## Routine administrative tasks to be carried out
 
## Rules for archiving and backup
# Personnel resources to be added
# Required financial resources
## Specification of required resources
## Financial resources required to build the service (itemized)
## Strategy for acquiring the resources
## Financial resources required to operate the service (itemized)
# Skills to be developed
## Specification of the required skills
## Strategy for acquiring the skills
# Changes to processes
## List of IT processes which must be changed or created, including process owners
## Detailed specification of required changes to IT processes, e.g. in the form of process designs
 
==== Required financial resources ====
# Financial resources required to build the service (itemized)
# Financial resources required to operate the service (itemized)


<p>&nbsp;</p>
<p>&nbsp;</p>


==== Service Design Package - Part 4: Transition Planning Information ====
== Part V: Transition Planning Information ==


This part sets an intended time frame for the service implementation and estimates the required resources; this information may be updated later by [[Change Management|Change]], [[Release and Deployment Management|Release]] or [[Project Management - Transition Planning and Support|Project Management]].
This part sets an intended time frame for the service implementation and estimates the required resources; this information may be updated later by [[Change Management|Change]], [[Release and Deployment Management|Release]] or [[Project Management - Transition Planning and Support|Project Management]].


# Preliminary [[Project Management - Transition Planning and Support#Service Transition Plan|Service Transition Plan]]
==== Preliminary [[Project Management - Transition Planning and Support#Service Transition Plan|Service Transition Plan]] ====
## Major project phases and milestones
# Major project phases and milestones
## Intended time schedule
# Intended time schedule
## Required staff resources
# Required staff resources


<p>&nbsp;</p>
<p>&nbsp;</p>

Revision as of 17:58, 18 March 2012

<seo metakeywords="service design package, itil service design package, service design package template, itil sdp" metadescription="The Service Design Package (SDP) builds upon the Service Level Requirements. It further specifies the requirements from the viewpoint of the ..." />

DE - ES - Checklist Service Design Package SDP - Template Service Design Package SDPdiese Seite auf Deutschesta página en español
DE - ES - Checklist Service Design Package SDP - Template Service Design Package SDP


Overview

ITIL Process: ITIL 2011 Service Design - Design Coordination

Checklist Category: Checklists ITIL Service Design

Source: Checklist "Service Design Package - SDP" from the ITIL Process Map

 

The Service Design Package (SDP) builds upon the Service Level Requirements. It further specifies the requirements from the viewpoint of the client and defines how these are actually fulfilled from a technical and organizational point of view. It is assumed that a bundle of Supporting Services is combined in order to deliver a Business Service for the client. In this context, the IT organization may opt to supply the Supporting Service with its own resources, or to use an external service supplier.

The Service Design Package is passed from Service Design to the Service Transition process and details all information required in order to develop the service solution, including a preliminary (intended) time-schedule for the Service Transition phase.

 

The Service Design Package contains the following information (the actual level of detail will vary, depending on the type of service):

 

 

Part I: Header

This part describes the header data contained in a Service Design Package.

Name of the service

Service Owner responsible for delivering the service

Clearance information

(with location and date)

  1. Clearance of the Service Design Manager
  2. Clearance of the Service Design Package by Service Management (confirmation that the requirements as laid out in this document are able to be fulfilled and where necessary, specification of any preconditions which must be fulfilled before the service can go operational)
    1. Capacity Manager
    2. Availability Manager
    3. IT Service Continuity Manager
    4. Information Security Manager
    5. Compliance Manager
    6. Financial Manager

 

Part II: Detailed Requirements Specification as a Basis for Service Transition

This part builds upon the Service Level Requirements and specifies in more detail what conditions the new service and its underlying applications and infrastructure must fulfill, providing all information which is needed for building the new service.

Service level requirements

(reference to the SLR document, where service level requirements are defined)

Functional requirements

(the SLR document contains a summary description of the desired customer outcome; however, functional requirements may need to be specified in greater detail, especially if new applications/ systems are to be developed)

Information security requirements

(Information security requirements which are relevant for the service)

Compliance requirements

(Compliance requirements which are relevant for the service)

Architectural constraints

(e.g. specific technology or vendors)

Interface requirements

(e.g. if a new system needs to communicate with other systems)

Migration requirements

(e.g. if data are to be migrated from an existing to a new application)

Operational requirements

(e.g. requirements for backup and restore mechanisms, compatibility with existing system monitoring tools)

Required access rights

(which users or user groups will require access to the service, and what levels of access must be provided)

 

Part III: Service Operation and Improvement Concepts

This part details how the service will be operated and continually improved, including the associated responsibilities, and what is required to do so.

Service Operation

  1. Approach to managing risks and issues
  2. Required monitoring, measuring and reporting
  3. Requirements with regards to operational functions, e.g. procedures and activities required on operational level to operate the service
  4. Required operational and end-user documentation
  5. Human resources as well as skills required to operate the service

Continual Service Improvement

  1. Approach and mechanisms to continually improve the service
  2. Human resources as well as skills required to improve the service

 

Part IV: Technical and Organizational Implementation Blueprint

This part details what must be done during Service Transition to meet the specified requirements.

Decomposition of the Business Service into Infrastructure Services

  1. Internal Infrastructure Services on which this service is based
    1. Names of the infrastructure services
    2. Service providers (responsible Service Owners)
    3. References to Operational Level Agreements (OLAs)
    4. Required changes to OLAs, if existing OLAs are not sufficient for the service to be established
  2. Externally supplied Supporting Services on which this service is based
    1. Names of the external services
    2. Name of the supplier
    3. Responsible Supplier Manager
    4. References to Underpinning Contracts (UCs)
    5. Required changes to UCs, if existing UCs do not support the introduction of the new service

Transition strategy

(a brief outline of the selected approach to implementing the new service)

  1. Testing strategy
  2. Deployment strategy
  3. Migration concept
  4. Back-out strategy in the case of a failed deployment
  5. Integration with other service transition projects

Details on technical changes

Details on technical changes required to build, test, deploy and operate the service.

  1. Development/ customization of base applications for the service (e.g. if the service to be introduced is based on the SAP system or a custom application)
  2. Supporting tools
    1. Development/ customization of migration tools
    2. Development/ customization of testing tools
    3. Development/ customization of deployment tools
    4. Development/ customization of back-out tools in the case of a failed release deployment
  3. Infrastructure modifications required to build, test, deploy and operate the service
    1. Infrastructure components to be purchased and installed
    2. Infrastructure components to be (re-)configured
  4. Required changes to facilities

Organizational changes

Organizational changes required to implement and operate the service.

  1. Personnel resources to be added
    1. Specification of required resources
    2. Strategy for acquiring the resources
  2. Skills to be developed
    1. Specification of the required skills
    2. Strategy for acquiring the skills
  3. Changes to processes
    1. List of IT processes which must be changed or created, including process owners
    2. Detailed specification of required changes to IT processes, e.g. in the form of process designs

Required financial resources

  1. Financial resources required to build the service (itemized)
  2. Financial resources required to operate the service (itemized)

 

Part V: Transition Planning Information

This part sets an intended time frame for the service implementation and estimates the required resources; this information may be updated later by Change, Release or Project Management.

Preliminary Service Transition Plan

  1. Major project phases and milestones
  2. Intended time schedule
  3. Required staff resources