ITIL Process Assessment - Service Design (XLS)

ITIL Service Design Assessment
Service Design group provides guidance for the design and development
of services and service management practices. It covers design
principles and methods for translating strategic objectives into portfolios
of services and service assets.
Processes included in this assessment are:
1 Design Coordination
2 Service Catalogue Management
3 Service Level Management
4 Supplier Management
5 Availability Management
6 Capacity Management
7 IT Service Continuity Management
8 Information Security Management

Introduction
PMF Model
Figure 1: PMF – Maturity levels:
Table 1: PMF – Maturity levels description
Level Level – General description
Level 1: Initial
The process has been recognized but there is little or no process management activity and it is
allocated no importance, resources or focus within the organization. This level can also be
described as ‘ad hoc’ or occasionally even ‘chaotic’.
Level 2: Repeatable
The process has been recognized and is allocated little importance, resource or focus within the
operation. Generally activities related to the process are uncoordinated, irregular, without
direction and are directed towards process effectiveness.
Level 3: Defined
The process has been recognized and is documented but there is no formal agreement,
acceptance or recognition of its role within the IT operation as a whole. However, the process
has a process owner, formal objectives and targets with allocated resources, and is focused on
the efficiency as well as the effectiveness of the process. Reports and results are stored for
future reference.
(Level 3 +: Deployed ) (This extra level was introduced to emphasize actual deployment of the process as defined.)
Assessment methodology
This spreadsheet system allows you to conduct a Assessment of ITIL v3 processes.
Assessment highlights areas that require particular attention and gives you idea on process maturity. It can also be used as a
benchmarking mechanism and a boost in creating continual improvement culture for your ITSM / ITIL processes.
(Even if you want to employ external Service Management consultants to do an assessment, you can present the findings of
this spreadsheet to help them rapidly understand some of your current issues. This in itself is a time saving (and therefore)
cost saving exercise.)
The assessment is based on Process maturity framework (PMF), (as recommended in ITIL Service Design book). PMF shown
in Figure 1: PMF – Maturity levels, and described in Table 1: PMF – Maturity levels description brings a common, best-practice
approach to the review and assessment of service management process maturity.
PMF Model – Maturity level description
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/itil-process-assessment--service-design-xls-3668

Level 4: Managed
The process has been fully recognized and accepted throughout IT. It is service-focused and has
objectives and targets that are based on business objectives and goals. The process is fully
defined, managed and has become proactive, with documented, established interfaces and
dependencies with other IT process.
Level 5: Optimizing
The process has been fully recognized and has strategic objectives and goals aligned with
overall strategic business and IT goals. These have now become ‘institutionalized’ as part of the
everyday activity for everyone involved with the process. A self-contained continual process of
improvement is established as part of the process, which is now developing a pre-emptive
capability.
Figure 2: PMF – Process maturity (inputs, outputs, activities, measuring, optimisation)
1. Process performance (outcomes achieved)
2. Performance Management ( activities performed)
3. Work product management ( inputs/outputs)
4. Process Definition ( roles documentation)
5. Process deployment( accepted, performed)
6. Process Measurement
7. Process control
8. Process innovation
9. Process optimisation
Figure 3: Mapping: PMF- Assessment Question Areas:
Further, Figure 2: PMF – Process maturity (inputs, outputs, activities, measuring, optimisation) gives further graphical
representation of the PMF model as described above:
The use of the PMF in the assessment of service management processes relies on an appreciation of the IT organization
growth model. At the process level, assessment covered following groups of questions regarding process attributes to establish
process maturity:
Assessment questions map to PMF maturity levels as shown in Figure 3: Mapping: PMF- Assessment Question Areas;
7. Process control
8. Process innovation
9. Continuous optimization

Each process assessment sheet begins with a summary of industry best practice that has been used as a basis for the
assessment.
1. Process Performance ( outcomes achieved)
2. Performance Management ( activities performed)
3. Work Product Management ( inputs/outputs)
4. Process definition ( roles, documentation,...)
5. Process deployment ( accepted, performed)
6. Process measurement

1
2
3
Note 1:
Note 2:
Scoring Question counter
Yes 1 Yes 1
No 0 No 1
Partially 0.5 Partially 1
N.A. 0 N.A. 0
Scoring table & Question counter
Instructons for use
In each Process sheet, auditor should fill in only yellow cells ( Column C
"Answers"). All other values are calculated automatically.
Each Assessment question can be answered by: Yes, No, Partially, N.A. (Not
applicable). Possible answers come as drop-down menu in each cell.
After answer is given, score in respective column D cell is automatically populated with
calculated score (Yes=1, No=0, Partially=0.5 and N.A. is excluded from scoring).
XLS calculations of percentage scores are only guidelines and not final
scores. Final Maturity Levels in the Assessment should be determined by
the auditor based on given answers following the described PMF model.
If a process has very low maturity in certain area, auditor may opt to ask
open questions about what does organisation have/use rather than
asking explicitly assessment questions.

Level 1: Initial
Level 2: Repeatable
1. Process Performance:
Process outcomes are realized i.e. Process purpose is achieved.
Answer Score Comment
Design of services, service management information systems,
architectures, technology, processes and metrics is consistent.
#N/A
Design activities are scheduled and coordinated across projects, changes,
suppliers and support teams.
#N/A
Resources and capabilities required to design new or changed services
are planned and coordinated.
#N/A
Quality criteria, requirements, risks, and issues are controlled. #N/A
Service models and service solution designs conform to strategic,
architectural, governance and other corporate requirements.
#N/A
Service solution designs produced based on service charters and change
requests are handed over to Service Transition as agreed.
#N/A
#N/A
Level 3: Defined
2. Performance Management:
Process performance is managed
Design coordination policies and methods are defined and
maintained - Set of architectural documents and principles for the design
of service solutions and the production of Service Design Packages
(SDPs) is defined and maintained. Quality criteria, requirements,
interfaces and handovers between the Service Design stage and other
stages, particularly Service Strategy and Service Transition are agreed,
used and managed.
This includes the definition of the level of design coordination needed for
different types of projects and changes.
#N/A
Individual designs are planned and monitored - For each individual
project or change, design activities are planned (focusing on ensuring that
the resulting design can support the required business outcomes). Also,
each on-going design effort is monitored to ensure that there is adherence
to agreed methods and that design milestones are being met.
#N/A
Individual designs are coordinated - both service provider and
customer resources are coordinated to ensure involvement of the right
people at the right time to create an accurate and complete SDP.
Design activities must consider service functionality (utility), service
warranty, requirements to establish the service in effective use in the
organization, and, requirement to operate, maintain, and support the
service on an on-going basis (in other words, the full SDP).
#N/A
Design resources and capabilities across projects and changes are
planned - all service design resources and capabilities are planned,
prioritized and scheduled to ensure that competing demands from projects
and changes can be managed at the same time.
Service Design Coordination needs to be well informed regarding activities
in the service portfolio (particularly the service pipeline) as well as in the
Change Management process (by maintaining regular communication with
business relationship managers and service owners).
#N/A
All design activities across projects and changes are coordinated -
All design activities are coordinated and resource conflicts (if any) are
managed across projects, changes, supplier and support teams so that all
designs are moving forward in the most effective and efficient manner.
Coordination of all design activities across projects and changes should
ensure:
- good communication between the various design activities and all
concerned parties,
- availability of the latest versions of all appropriate business and IT plans
and strategies (to all designers),
- conformance of all architectural documents, service models, service
solution designs and SDPs to strategic, architectural, governance, and
other corporate documents, as well as IT policies and plans,
- good communication and coordination with Service Transition processes
(to ensure proper handover of this stage).
#N/A
Identify, manage and report design risks - Risk assessment and
management techniques are used to identify and manage risks associated
with design activities and so reduce the number of issues that can
subsequently lead to poor designs. Service design issues, risks and
deviations are reported to the appropriate stakeholders and decision
makers.
#N/A
Design Coordination purpose: to ensure the goals and objectives of the service design stage are
met by providing and maintaining a single point of coordination and control for all activities and
processes within Service Design stage of the service lifecycle.
NOTE: The triggers for the Design Coordination process are changes in the business requirement and
services, and therefore the main triggers are change proposals and the creation of new programs and
projects. Another major trigger for the review of design coordination activities would be the revision of the
overall IT strategy.

Designs are reviewed and verified - final review of the designs for
compliance with standards and conventions is performed to ensure that all
agreed requirements for the SDP have been completed correctly. Issues
are documented and it is determined whether they require revising any
part of the service design, or whether they can be addressed as part of the
plan for service transition. It is verified that the development of a
comprehensive design that will support the achievement of the required
business outcomes is taking place.
#N/A
Handover of Service Design Package is ensured - Once all required
criteria have been met, status of the service in the service portfolio is
changed so that the SDP can be officially handed over to Service
Transition (via the Transition Planning and Support process).
#N/A
#N/A
3. Work Product Management:
Work Products (Process Inputs and Outputs) are managed
Service Design policies and procedures are defined and maintained.
Service Design policies and procedures - A set of architectural
documents and principles for the design of service solutions and the
production of SDPs.
The design coordination policies should include:
- adherence to corporate standards and conventions
- explicit attention to governance and regulatory compliance in all design
activities
- standards for elements of a comprehensive design for new or changed
services such as: - document templates - documentation plans - training,
communication and marketing plans - measurement and metrics plans -
testing plans - deployment plans - criteria for resolving conflicting
demands for service design resources - standard cost models.
Service Design policies and procedures
#N/A
Service Design Package (SDP) is defined and produced for every
service design.
Service Design Package (SDP) - Documentation defining all aspects of
an IT service and its requirements through each stage of its lifecycle. A
service design package is produced for each new IT service, major
change, or IT service retirement.
Includes the service model and the Service Acceptance Criteria (SAC)
#N/A
Business impact analysis (BIA) report is produced for every service
design.
Business impact analysis report - Result of the activity that identifies Vital
Business Functions and their dependencies. BIA defines the recovery
requirements for IT services.
The dependencies may include suppliers, people, other business
processes, IT services, etc. The requirements include Recovery Time
Objectives (RTO), recovery point objectives and minimum service level
targets for each IT service
#N/A
Risk Assessment report is produced for every service design.
Risk assessment report - Risk is defined as the likelihood that a disaster
or other serious service disruption will actually occur. This report includes
the results of the risk assessment.
#N/A
Change request, Change proposal or Service Charter are defined
triggers/inputs for the process.
#N/A
Customer business plan is available as input. #N/A
IT Strategic information ( e.g. IT service strategy plan, Service Portfolio,
Budget for IT Services) are available as input.
#N/A
Change Schedule (CS) is available as input.
Change Schedule (CS) - Contains details of all the changes authorized for
implementation and their proposed implementation dates, as well as the
estimated dates of longer-term changes. A change schedule is sometimes
called a forward schedule of change, even though it also contains
information about changes that have already been implemented.
#N/A
Configuration Management System (CMS) is available as input.
Configuration Management System (CMS) - The CMS holds all the
information for CIs within the designated scope. It maintains the
relationships between all service components and any related incidents,
problems, known errors, change and release documentation and may also
contain corporate data about employees, suppliers, locations and
business units, customers and users.
#N/A
#N/A
4. Process definition:
Standard process is defined ( process guide, roles, interactions, resources,
capabilities, monitoring, reporting...) and maintained
Process owner is identified. #N/A
Standard process Purpose, Goals, Objectives, Scope, Triggers, Inputs,
Outputs are defined and documented.
#N/A
Standard process sequence of activities is defined and documented. #N/A
Standard process interaction with other processes is determined. #N/A
Standard Process roles and responsibilities are identified. #N/A
Competencies required for performing the process are identified.
#N/A

Infrastructure and work environment required for performing the process is
identified..
#N/A
Methods to monitor effectiveness and suitability of standard process are
determinend ( methods, data, CSFs, KPIs, need to audit and review the
process)
#N/A
Content of Service Management reporting is agreed with stakeholders (
layout, contents, frequency).
#N/A
#N/A
Level 3+: Defined & Deployed
5. Process deployment:
Process is effectively deployed in the organisation
Process owner accepts and performs his role. #N/A
Standard process is deployed and approved Process models are taylored
out of it for the context specific requirements.
#N/A
Process is performed as specified in Standard Process definition or
Process model and there is a clear criteria for choosing the respective
model.
#N/A
Process interactions with other processes are active. #N/A
Process roles and responsibilities are assigned and communicated. #N/A
Competencies required for performing the process are adequate or there
is a suitable training available/planned.
#N/A
Required Human resources to perform the process are available, allocated
and used.
#N/A
Required Information to perform the process is available, allocated and
used.
#N/A
Required Infrastructure to support the process is available, used and
maintained.
#N/A
Data required to understand behavior, effectiveness and suitability of
standard process is collected, analyzed and used to identify process
improvements
#N/A
Service Management reports are produced and published as agreed with
stakeholders.
#N/A
#N/A
4. Managed:
Process is measured and operates within defined limits and achieves
expected results.
6. Process measurement:
Measurement results are used to insure that process performance
supports achievement of process objectives in support of defined
business goals.
Process information needs are identified in relation to business goals. #N/A
Process measurement objectives are derived from Process information
needs.
#N/A
Quanititative Process performance objectives are established to explicitely
reflect business goals.
#N/A
Process performance objectives are verified with relevant management
and process owners to be realistic and useful.
#N/A
Detailed measurements, data collection methods, algorithms and methods
to create derived measurement results are defined.
#N/A
There is a verification mechanism for the defined measures.
#N/A
Service and process measurement results are collected and processed.
#N/A
Results of the measurement and monitoring are used to monitor and verify
the achievement of the process performance objectives.
#N/A
#N/A
7. Process control:
Process is quantitatively managed, stable, capable and predictable within
defined limits.
Suitable analysis and control techniques to control the process
performance are determined.
#N/A
Control limits of variation for normal process performance are established.
#N/A
Measurement data are analyzed for special causes and variation. #N/A
Corrective actions are taken to address special causes and variation. #N/A
Control limits are re-established ( as necessary) following corrective
action.
#N/A
#N/A
5. Optimizing:
Process is continuously improved to meet current and projected business
goals.
8. Process innovation:
Process changes are identified based on analysis and investigation of
innovative approaches
Process improvement objectives are defined that support relevant
business goals ( direction for improvement is set, business vision and
goals are analysed and cascaded to process, quantitative and qualitative
process improvements are defined).
#N/A
Measurement data is analysed to identify real and potential variations in
the process performance.
#N/A

Improvement opportunities of the process are derived based on innovation
and industry best practices.
#N/A
Improvement opportunities are derived from new technologies and
process concepts.
#N/A
Improvement strategy is defined based on a long-term improvement
vision and objectives ( management and process owners are commited to
improvement; proposed changes are evaluated, piloted, classified and
prioritized; approved changes are planned; after implementation there is
evaluation of change effects...)
#N/A
#N/A
9. Process optimization:
Process is continously improved ( changes are assessed & analysed for
impact, implementation of changes is controlled, effectivenes of changes
is evaluated)
Impact of each process change is assessed against the objectives defined
in standard process.
#N/A
Implementation of all agreed changes is managed to ensure that any
disruption to the process performance is understood and acted upon.
#N/A
Effectiveness of a process change is evaluated on the basis of process
performance, general process capability and business goals. #N/A

Level 1: Initial
Level 2: Repeatable
Service catalogue exists and accurately reflects the current details, status,
interfaces and dependencies of all services that are being run, or being
prepared to run, in the live environment.
Service provider should manage two views of its service catalogue: a
customer-facing services view (the business service catalogue), and a
supporting services view (the technical service catalogue).
#N/A
Description of customer-facing services that contribute to business
outcomes is shared with customers.
#N/A
Common understanding on how the IT services (both customer facing and
supporting services) contribute to business outcomes is fostered amongst
all service provider staff.
#N/A
Service catalogue supports the evolving needs for information of all
service management processes, including all interfaces and dependency
information.
#N/A
Service catalogue is made available to those approved to access it in a
manner that supports their effective (and efficient) use of service
catalogue information.
#N/A
#N/A
Level 3: Defined
Definition and a description for each service is documented and
agreed on - definition of each service is documented and agreed with all
relevant parties to ensure a common understanding of that service within
the service provider organization including how that service maps onto
and support the business. Details of each IT service are recorded in the
service catalogue and the valid statuses of a service are defined.
#N/A
It is identified which business units and processes use which
customer-facing services - For each service contained in the customer-
facing services view of the service catalogue, the business units and their
business processes that use that service are identified.
This activity should be done in conjunction with the business and the IT
Service Continuity Management process.
#N/A
Interfaces and dependencies between customer-facing services and
supporting services are identified - Interfaces and dependencies
between the customer-facing services and the supporting services,
components and CIs contained within the service catalogue are identified
together with the support teams, suppliers, and Service Asset and
Configuration Management.
#N/A
All services are described and recorded in the service catalogue -
Descriptions of services being run or being prepared to run in the live
environment, with their service levels and all their interfaces and
dependencies, are recorded in the service catalogue.
The collected information used to fill the service catalogue should come
from Business Relationship Management, Service Portfolio Management,
Service Level Management and the business.
#N/A
Customer-facing services part of the service catalogue is maintained -
customer-facing services part of the service catalogue (i.e. the business
service catalogue) is regularly maintained in conjunction with Service
Level Management and Business Relationship Management to ensure
alignment of its information with business and the business processes.
#N/A
Supporting services are maintained as a part of the service
catalogue - part of the service catalogue with supporting services (i.e.
the technical service catalogue) is regularly maintained in conjunction
with Change Management and Service Asset and Configuration
Management to ensure that the information it contains is aligned to the
supporting services, technical components and CIs.
#N/A
Service catalogue is made available - Service catalogue is made
available to those approved to access it.
#N/A
#N/A
Service Catalogue Management purpose: To
• provide and maintain a single source of consistent information on all agreed services ( e.g.
operational services and those being prepared to be run operationally)
• ensure that Service Catalogue (SC) is widely available to those who are authorized to access it.
The service catalogue (SC) provides a central source of information on the IT services delivered to
the business by the service provider organization, ensuring that business areas can view an
accurate, consistent picture of the IT services available, their details and status.
NOTE: Agreed services means operational services and those being prepared to be operational.

Service Cataloge is defined, maintained and aligned with Service
portfolio.
Service catalogue - It is a key document or database containing valuable
information on the complete set of services offered. It contains the details
and the current status of every live service provided by the service
provider or service being transitioned into the live environment, together
with the interfaces and dependencies. The service catalogue includes
information about deliverables, prices, contact points, ordering and
request process.
The service catalogue is the only part of the service portfolio published to
customers and is used to support the sale and delivery of IT services.
#N/A
Information about service changes are available as input. #N/A
Service oriented financial information is available as input. #N/A
Supplier and Contract information is available as input. #N/A
Business Impact Analysis (BIA) report is available as input.
requirements for IT services
#N/A
Configuration Management System (CMS) is available as input.
#N/A
#N/A
#N/A
#N/A
identified..
#N/A
process)
#N/A
#N/A
#N/A
#N/A
model.
#N/A
#N/A
and used.
#N/A
used.
#N/A
maintained.
#N/A
improvements
#N/A
stakeholders.
#N/A
#N/A
4. Managed:
expected results.
business goals.

needs.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
7. Process control:
defined limits.
#N/A
#N/A
Measurement data are analyzed for special causes and variation.
#N/A
action. #N/A
#N/A
5. Optimizing:
goals.
#N/A
#N/A
#N/A
process concepts.
#N/A
#N/A
#N/A
is evaluated)
#N/A
#N/A
performance, general process capability and business goals.
#N/A

Level 1: Initial
Level 2: Repeatable
IT and the customers have a common, clear and unambiguous
understanding of the levels of service to be delivered.
#N/A
IT services are delivered at levels agreed with the customers. #N/A
Close relationship with business and customers is maintained (in
conjunction with Business Relationship Management).
#N/A
Specific and measurable targets are developed for all IT services. #N/A
Customer satisfaction regarding service levels is monitored and improved. #N/A
Levels of service delivered are subject to cost-effective continual
improvement.
#N/A
#N/A
Level 3: Defined
Service Level Requirements (SLRs) are determined, documented and
agreed - service level requirements for services being developed,
changed or procured are determined, documented and agreed on . The
SLRs should be an integral part of the overall service design criteria which
also include the functional or “utility” specifications.
Representatives of other processes need to be consulted to determine
which targets can be realistically achieved.
#N/A
Service Level Agreements (SLAs) for operational services are
negotiated, documented and agreed upon – SLAs are drafted,
negotiated and agreed on, detailing the service level targets to be
achieved and specifying the responsibilities of both the IT service provider
and the customer.
#N/A
Service performance is monitored against SLAs - Service performance
achievements of all operational services are monitored and measured
against SLA targets.
Monitoring capabilities are established, reviewed and upgraded to assist
with the service performance measurement.
#N/A
Occurrence and impact of SLA breaches is minimized – It is ensured
that corrective actions are taken to prevent SLA breaches and minimize
their impact on the business operations.
#N/A
Customer is provided with regular service reports - Service reports
are produced and communicated to customer, based on agreed
mechanisms, report format, and intervals (service achievement report,
operational reports, and where possible, exception reports should be
produced whenever an SLA has been broken).
Service reports should be reviewed with the customer on a regular basis.
#N/A
Service reviews are conducted and improvements are discussed -
Review meetings with customer are held on a regular basis to review the
service achievement in the past period, to anticipate any issues for the
coming period and to identify potential improvements.
#N/A
SLAs, OLAs, and UCs are reviewed - SLAs and service scope are
reviewed periodically (at least annually), to ensure alignement to business
needs and strategy. It is ensured that service levels defined in Operational
Level Agreements (OLAs) and Underpinning Contracts (UCs) are kept
aligned.
SLM should assist Supplier Management with the review of all supplier
agreements and UCs to ensure that targets are aligned with SLA targets.
#N/A
Service level complaints, comments and compliments are managed -
Service level complaints originating from users and customers are logged
and managed, from the time they are made to the time they have been
dealt with. Also, comments and compliments are logged and
communicated to the relevant parties.
This work represents a significant contribution to the overall customer
satisfaction.
#N/A
Customer satisfaction is monitored and taken into account -
Customer perception of service levels provided is monitored and taken
into account in the SLA, OLA, and UC reviews and the Service
Improvement Plan (SIP).
#N/A
Service level improvements are instigated - Results of service and
SLA reviews, complaints, compliments and customer perception on
service levels are used to instigate service improvements
#N/A
#N/A
Service Level Management purpose: to ensure that all current and planned IT services are delivered
to agreed achievable targets.
NOTE: This is accomplished through a constant cycle of negotiating, agreeing, monitoring, reporting on and
reviewing IT service targets and achievements, and through instigation of actions to correct or improve the
level of service delivered.

Service Level Agreement (SLA) is defined and maintained for every
customer-facing services.
Service Level Agreement (SLA) - An agreement between an IT service
provider and a customer. The SLA describes the IT service, documents
service level targets, and specifies the responsibilities of the IT service
provider and the customer. A SLA may cover multiple IT services or
multiple customers.
Each SLA includes: - service description - scope of the agreement -
service hours - service availability - reliability - customer support - contact
points and escalation - batch turnaround times - change management -
service continuity - security - responsibilities - charging (if applicable) -
service reporting and reviewing - glossary - amendment
#N/A
Operational Level Agreement (OLA) is defined and maintained for every
internal supporting service.
Operational Level Agreement (OLA) - An agreement between an IT
service provider and another part of the same organization. An OLA
supports the IT service provider's delivery of IT services to customers. The
OLA defines the goods or services to be provided, and the targets and
responsibilities that are required to meet agreed service level targets in an
SLA.
Each OLA includes: - support service description - scope of the agreement
- service hours - service targets - contact points and escalation - service
desk, incident and problem response times and responsibilities - change,
release and configuration management interface and responsibilities -
information security responsibilities - availability, continuity and capacity
interface and responsibilities - service level management responsibilities -
supplier management responsibilities - glossary - amendment
#N/A
Underpinning Contract (UC) are defined and maintained.
Underpinning Contract (UC) - A contract (agreement) between an IT
service provider and a third party. The third party provides goods or
services that support delivery of an IT service to a customer. The
Underpinning Contract (agreement) defines targets and responsibilities
that are required to meet agreed service levels targets in an SLA.
#N/A
Service Reports are defined and produced.
Service report - It provides details of the service levels achieved in relation
to the targets contained within SLAs.
It includes: - details of all aspects of the service and its delivery - current
and historical performance - breaches - weaknesses - major events -
changes panned - current and predicted workloads - customer feedback -
improvement plan and activities
#N/A
Service review meeting minutes are defined and produced.
Service review meeting minutes - They are produced to record the
minutes and actions of all service review.
These minutes include: - meeting agenda - brief of discussions - new
actions - previous actions progress - schedule of next meetings
#N/A
Customer complaints, comments and compliments are recorded. #N/A
Customer satisfaction survey is conducted regularly. #N/A
Service Improvement Plan (SIP) is defined and maintained.
Service Improvement Plan (SIP) - An overall program or plan of prioritized
improvement actions, encompassing all services and all processes,
together with associated impacts and risks. It should be used to manage
the progress of agreed improvement actions. The target of a SIP could be
the service provider’s activities or those performed by one of its suppliers.
#N/A
Service quality plan is defined and maintained.
Service quality plan - A document containing all management information
on the measurement of service quality (upon the basis of Performance
Indicators) and the contribution by internal and external suppliers for the
provision of these services.
For each service: - agreed service levels - performance indicators -
measurement procedures - relationships to other SLAs - required internal
services - required externally procured services
#N/A
Service Level Requirements (SLRs) are defined and maintained.
Service Level Requirement (SLR) - A SLR is a customer requirement for
an aspect of an IT service. SLRs are based on business objectives and
are used to negotiate agreed service level targets.
#N/A
#N/A
#N/A
#N/A
identified..
#N/A

process)
#N/A
#N/A
#N/A
#N/A
model.
#N/A
#N/A
and used.
#N/A
used.
#N/A
maintained.
#N/A
improvements
#N/A
stakeholders.
#N/A
#N/A
4. Managed:
expected results.
business goals.
needs.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
7. Process control:
defined limits.
#N/A
#N/A
action. #N/A
#N/A
5. Optimizing:
goals.
#N/A
#N/A
#N/A

process concepts.
#N/A
#N/A
#N/A
is evaluated)
#N/A
#N/A

Level 1: Initial
Level 2: Repeatable
Relationships and communication with suppliers are managed. #N/A
Contracts and agreements with suppliers are aligned with business needs
by supporting the targets agreed in SLAs.
This should be done in conjunction with Service Level Management.
#N/A
Contribution of suppliers to the business value creation is determined. #N/A
Suppliers achieve the performance targets defined in their contracts and
agreements.
#N/A
#N/A
Level 3: Defined
New supplier and contract requirements are defined - detailed
requirements for new suppliers or new contracts with existing suppliers are
defined based on a business case, including costs, timescales, targets,
benefits and risk assessment.
Determining strategyically to what extent the contribution of suppliers would bring
value to all or part of the new or changed service and the decision to outsource
should be done beforehand.
#N/A
Suppliers are evaluated and best suitable is selected - Supplier
proposals are evaluated based on objective evaluation criteria in order to
finally select the best suitable suppliers for the business needs.
Supplier-related risks should be part of selection criteria.
#N/A
Contracts with new supplier are estabished - Contracts and
agreements with each new supplier are defined, negotiated and agreed ,
including the description of service(s) provided, the related targets, the
terms and conditions, and the documented responsibilities.
In case of underpinning contracts, the agreed targets have to be determined so
that the service provider is able to achieve the existing ( and planned) SLA
targets.
#N/A
Suppliers are categorized - Existing suppliers are categorized based on
objective criteria such as: the risks and impact associated with using the
supplier, and the value and importance of the supplier to the business.
The amount of time and effort spent managing the supplier and the relationship
should be appropriate to its categorization (e.g. strategic, tactical, operational, and
commodity).
#N/A
Interfaces with suppliers are defined and agreed - Interfaces with
suppliers are defined and agreed to establish functional boundaries
between the service provider, their suppliers and the suppliers’ sub-
contractors. This includes escalation paths in case issues are raised.
The definition of interfaces enables a global view on the supply chain and control
that the overall business service levels are achieved.
#N/A
Suppliers’ performance is monitored and reviewed - Suppliers’
performance is monitored, regularly reported to defined stakeholders, and
formal performance review meetings (at a detailed operational level) are
held on a regular basis.
The level of detail and the frequency of the performance reviews should depend
on the category of the supplier.
#N/A
Supplier contracts are reviewed, renewed or terminated - Supplier
contracts and agreements (at a strategic level) are reviewed and agreed
on a regular basis to ensure that contracts remain aligned to business
needs. When appropriate, renewal or termination of supplier contracts and
agreements is prepared.
The renewal and termination terms should be considered (in conjunction with
procurement and legal department) at the time the original contract is established.
#N/A
Contractual disputes are managed (if needed) - In case of contractual
disputes with a supplier, actions are taken to make sure that there is no or
limited impact on the service and/or the business.
#N/A
#N/A
Supplier and Contract Management Information System (SCMIS) exists
and is maintained.
Supplier and Contract Management Information System (SCMIS) - A set
of tools, data and information that is used to support supplier
management. The SCMIS contains details of the organization’s suppliers,
together with details of the products and services that they provide to the
business, together with details of the contracts. Ideally the SCMIS should
be contained within the overall CMS.
The SCMIS contains supplier details, a summary of each product/service,
information on the ordering process and, where applicable, contract
details.
#N/A
Supplier Management purpose: to ensure that all contracts and agreements with suppliers
efficiently support the needs of the business, and that all suppliers meet their contractual
commitments.

Underpinning Contract (UC) are defined and maintained.
Underpinning Contract (UC) - A contract (agreement) between an IT
service provider and a third party. The third party provides goods or
services that support delivery of an IT service to a customer. The
Underpinning Contract (agreement) defines targets and responsibilities
that are required to meet agreed service levels targets in an SLA.
#N/A
Service/Supplier performance reports are defined and produced.
Service/Supplier performance reports - A report on the performance of a
service or of a supplier. They are produced on a regular basis, based on
the category of supplier, and should form the basis of service review
meetings. The more important the supplier, the more frequent and
extensive the reports and reviews should be.
#N/A
Performance and contract review meeting minutes are produced.
Performance and contract review meeting minutes - They are produced to
record the minutes and actions of all review meetings with supplier (i.e.
supplier performance review and contract review).
#N/A
Contractual dispute records are maintained.
Contractual dispute record - A record containing the information about a
contractual dispute with an external supplier and all actions taken to
resolve it.
#N/A
Supplier and contracts policy is defined and available as input.
Supplier and contracts policy - It covers the sourcing policy of the service
provider and the types of suppliers and contracts used. It is produced by
the service strategy processes.
#N/A
Statement of Requirements (SOR) is defined for every purchase.
Statement of Requirements (SOR) - A document containing all
requirements for a product purchase or a new or changed IT service.
It includes: - description of the services, products or components required -
all relevant technical specifications, details and requirements - an SLR
where applicable - availability, reliability, maintainability and serviceability
requirements - details of performance criteria to be met by the equipment
and the supplier - details of all standard to be complied with (internal,
external, national, international) - legal and regulatory requirements -
details of quality criteria - contractual timescales, details and
requirements, terms and conditions - all commercial considerations: cost,
charges, bonus and penalty payments and schedules - interfaces and
contacts required - reporting, monitoring and reviewing procedures and
criteria to be used during and after the implementation - supplier
requirements and conditions - sub-contractor requirements - details of
planned and possible growth - procedures for handling changes - supplier
response requirements
#N/A
Supplier evaluation criteria are defined.
Supplier evaluation criteria - Criteria used to evaluate the suppliers.
Criteria for evaluating and selecting suppliers are usually based on: -
importance and impact - risk - costs
#N/A
#N/A
#N/A
Standard process sequence of activities is defined and documented.
#N/A
#N/A
identified..
#N/A
process)
#N/A
#N/A
#N/A
#N/A
model.
#N/A
#N/A

and used.
#N/A
used.
#N/A
maintained.
#N/A
improvements
#N/A
stakeholders.
#N/A
#N/A
4. Managed:
expected results.
business goals.
needs.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
7. Process control:
defined limits.
#N/A
#N/A
action.
#N/A
#N/A
5. Optimizing:
goals.
#N/A
#N/A
#N/A
process concepts.
#N/A
#N/A
#N/A
is evaluated)
#N/A
#N/A
performance, general process capability and business goals.
#N/A

Level 1: Initial
Level 2: Repeatable
Availability plan is produced and maintained to reflect the current and
future needs of the business.
#N/A
Availability of both services and resources enables to meet all the
availability targets agreed in SLAs and to meet future availability needs.
#N/A
Impact of all changes on the availability plan and the availability of all
services and resources is assessed and addressed.
#N/A
Advice and guidance on all availability-related issues are provided to all
other areas of the business and IT.
#N/A
Cost-justifiable measures to improve the availability of services are
implemented.
#N/A
#N/A
Level 3: Defined
Current and future availability requirements are determined - Vital
Business Functions (VBFs), business plans, SLAs, SLRs and trends on
service and component availability are analysed to determine the current
and future availability requirements.
The identification of the VBFs should be done in conjunction with the
business and the ITSCM process.
#N/A
Availability measurement mechanisms as well as service and
resource availability targets are defined - Availability measurement
mechanisms for all services and critical components as well as related
availability targets are defined.
The availability measures should be incorporated into SLAs, OLAs and
underpinning contracts.
#N/A
Service components availability is monitored and any service or
component unavailability is identified and resolved - All aspects of
availability, reliability and maintainability of resources and IT services
components are monitored, with appropriate events, alarms, and
escalations. It is assisted with the identification and resolution of any
exception event, incident and problem associated with service or
component unavailability.
#N/A
Impact of service changes on required availability is estimated -
Proposed changes to IT services (including service retirements) are
modeled and trended to understand the impact on availability and ensure
that appropriate available is maintained.
#N/A
Availability plan is produced and used - Availability plan that reflects
all trends, predicted changes, future requirements and plans (e.g. from
service portfolio and SLRs) is produced, maintained and used in order to
enable the service provider to deliver services in line with availability
targets defined in SLAs with a reasonable anticipation on future
expectations.
#N/A
Advice and guidance on availability issues is provided - Advice and
guidance is provided to all other areas of the business and IT on all
availability related issues.
In particular, Availability Management should be involved in defining SLRs
and SLAs, designing new or changed service (availability and recovery
design criteria), and analyzing change impact.
#N/A
Service availability is measured from the business and user
perspective - Availability of IT services that reflects the experience of the
business and users is measured based on the measured availability of
service components.
The user and business views of availability are influenced by: frequency
of downtime, duration of downtime, business impacts...
#N/A
Risk assessment and management activities are performed - risks
are identified and quantified, impact arising from IT service and
component failure is determined and, where appropriate, countermeasures
are implemented to ensure the prevention and/or recovery from service
and component unavailability.
Risk assessment and management activities should be conducted in
conjunction with the IT Service Continuity Management and the
Information Security Management processes.
#N/A
All resilience and fail-over components and mechanisms are tested -
Tests for all resilience and fail-over components and mechanisms are
scheduled and performed to ensure their effectiveness.
#N/A
Cost-justifiable improvements of service availability are identified
and instigated - Improvements of service or component availability are
activelly searched for and implemented wherever it is cost- justifiable and
meets the needs of the business.
#N/A
#N/A
Availability Management purpose: to ensure that the level of availability delivered in all IT services
meets the agreed availability needs and/or service level targets in a cost-effective and timely
manner.
NOTE 1: Availability Management is concerned with meeting both the current and future availability needs
of the business.
NOTE 2: IT Service Continuity Management (ITSCM) and Availability Management have a close

Availability Management Information System (AMIS) is defined and
maintained.
Availability Management Information System (AMIS) - A virtual repository
of all availability management data, usually stored in multiple physical
locations.
It includes the following information: - IT availability metrics -
measurements - targets and documents - including the availability plan -
availability measurements - achievement sports - service Failure Analysis
(SFA)
#N/A
Availability measures, targets and levels are defined and measured.
Availability measures, targets and levels - The availability measurement
mechanisms for all services and critical components, and their related
availability targets.
The availability measures should be incorporated into SLAs, OLAs and
#N/A
Availability plan is defined and maintained.
Availability plan - A plan to ensure that existing and future availability
requirements for IT Services can be provided cost effectively.
It should have aims, objectives and deliverables and should consider the
wider issues of people, processes, tools and techniques as well as having
a technology focus. It should cover a period of one to two years, with a
more detailed view and information for the first six months.
#N/A
Availability exception report is defined and produced.
Availability exception report - A document containing details of one or
more availability-related KPIs or other availability targets that have
exceeded defined thresholds.
#N/A
Ad hoc availability and performance reports are produced.
Ad hoc availability and performance report - It is used by all areas of
Availability Management, IT and business to analyze and resolve service
unavailability.
#N/A
Forecast and predictive report are defined and produced.
Forecast and predictive report - It is used by all areas to analyze, predict
and forecast particular business and IT scenarios and their potential
solutions.
#N/A
Risk assessment report is produced.
#N/A
Availability test schedule is defined and maintained.
Availability test schedule - Schedule for testing all availability and
resilience mechanisms. The test schedule should also document the
number of testers available for testing.
#N/A
Availability test report is defined and produced.
Availability test report - A report on the tests done for all resilience and fail-
over components and mechanisms.
#N/A
Cofiguration Management System (CMS) is available as input.
#N/A
#N/A
#N/A
#N/A
#N/A
identified..
#N/A
process)
#N/A
#N/A
#N/A

#N/A
model.
#N/A
#N/A
and used.
#N/A
used.
#N/A
maintained.
#N/A
improvements
#N/A
stakeholders.
#N/A
#N/A
4. Managed:
expected results.
6.. Process measurement:
business goals.
needs.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
7. Process control:
defined limits.
#N/A
#N/A
Measurement data are analyzed for special causes and variation.
#N/A
action. #N/A
#N/A
5. Optimizing:
goals.
#N/A
#N/A
#N/A
process concepts.
#N/A
#N/A
#N/A

is evaluated)
#N/A
#N/A

Level 1: Initial
Level 2: Repeatable
Capacity plan is produced and maintained to reflect the current and future
needs of the business.
#N/A
Capacity and performance of both services and resources enable to
provide services as agreed in SLAs and to meet future needs.
#N/A
Impact of all changes on the capacity plans and on the performance and
capacity of all services and resources is assessed and addressed.
#N/A
Advice and guidance on all capacity- and performance-related issues are
provided to all other areas of the business and IT.
#N/A
Cost-justifiable measures to improve the capacity and performance of
services are implemented.
#N/A
#N/A
Level 3: Defined
Current and future needs for resources and IT services are
determined - Patterns of Business Activity (PBAs), patterns of demand,
SLAs and trends on current resource utilization are analysed to determine
the current and future short-, medium- and long-term needs for resources
and IT services.
#N/A
Service and resource capacity measures and related thresholds are
defined - capacity measures for all services and critical resources are
documented and agreed , and thresholds beyond which actions should be
taken are defined, based on the technical limits and constraints of the
individual services and components and on the analysis of recorded data.
The biggest challenge facing Capacity Management is to translate the
business requirements and workload in terms of the impact on the IT
service and infrastructure workloads and resource utilization, so that
appropriate thresholds can be set.
The thresholds should be set below the level at which the component or
service is over-utilized or below the targets in the SLAs.
#N/A
Service components capacity is monitored and any capacity-related
event is identified and treated - Information on current utilization of
resources and service workload (e.g. response time) is collected,
compared against the capacity thresholds, and all capacity-related events
are responded to by instigating corrective actions.
The identification of capacity-related events should be under the
responsibility of the Event Management process (if it exists).
#N/A
Impact of service changes on required capacity is estimated -
proposed changes to IT services (including service retirements) are
modeled and trended to understand the impact and ensure that
appropriate capacity is available.
#N/A
Capacity plan is produced and used - Capacity plan that reflects current
demand, trends, predicted changes, future requirements and plans (e.g.
from service portfolio and SLRs) is produced, maintained and used in
order to enable the service provider to deliver services of the quality
defined in SLAs with a reasonable anticipation on future expectations.
#N/A
Advice and guidance on capacity and performance issues is
provided - Advice and guidance is provided to all other areas of the
business and IT on all capacity and performance related issues.
In particular, ....
... Capacity Management should be involved in defining SLRs and SLAs,
designing new or changed service, analyzing change impact and
application sizing.
... Capacity Management should assist with the identification and
resolution of any incidents and problems associated with the capacity or
performance of a service or component.
#N/A
Capacity and performance of existing services and resources is
optimized - Where possible and justified, parts of the configuration that
can be optimized are identified, and cost- justifiable tuning activities to
better utilize the service, system and component resources or to improve
the capacity and the performance of the services are undertaken.
#N/A
Cost-justifiable improvements of service capacity and performance
are identified and instigated - improvements in service or component
capacity and performance are activelly searched for and implemented
wherever it is cost-justifiable and meets the needs of the business
The identification of improvement opportunities should be based on the
analysis of new techniques, new technologies, and the relationship
between business capacity, service capacity and component capacity
(amongst others elements).
#N/A
#N/A
Capacity Management purpose: to ensure that the capacity of IT services and the IT infrastructure
meet the agreed current and future capacity-and-performance-related requirements in a cost-
effective and timely manner.

Capacity Management Information System (CMIS) is defined and
maintained.
Capacity Management Information System (CMIS) - It holds the
information needed by all sub- processes within Capacity Management.
For example, the data monitored and collected on components and
services utilization is used to determine what infrastructure components or
upgrades to components are needed and when.
#N/A
Capacity measures and thresholds are defined, measured and maintained.
Capacity measures and thresholds - The capacity measurement
mechanisms for all services and critical components, and their related
capacity targets.
The capacity measures should be incorporated into SLAs, OLAs and
#N/A
Capacity plan is produced and maintained.
Capacity plan It is acted on by the IT service provider and senior
management of the organization to plan the capacity of the IT
infrastructure. It provides planning input to many other areas of IT and
business. It contains information on the current usage of service and
components, and plans for the development of IT capacity to meet the
needs in the growth of both existing service and any agreed new services.
The Capacity plan should be actively used as a basis for decision-making.
It includes: - management summary - business scenarios - scope and
terms of reference - methods used - assumptions made - service
summary - resource summary - options for service improvement - cost
forecast - recommendations
#N/A
Forecast and predictive report are produced.
Forecast and predictive report - It is used by all areas to analyze, predict
and forecast particular business and IT scenarios and their potential
solutions.
#N/A
Workload analysis report is produced.
Workload analysis report - It used by IT operations to assess and
implement changes in conjunction with capacity Management to schedule
or reschedule when services or workloads are run, to ensure that the most
effective and efficient use is made of the available resources.
#N/A
Ad hoc capacity and performance report is produced as necessary.
Ad hoc capacity and performance report - It is used by all areas of
Capacity Management, IT and business to analyze and resolve service
and performance issues.
#N/A
Exception reports are produced.
Exception report - A document containing details of one or more KPIs or
other important targets that have exceeded defined thresholds. For
example, SLA targets are being missed or a performance metric indicating
a potential capacity problem.
#N/A
Relevant Customer information is available as input ( e.g. Customer
business plans, Business Impact Analysis (BIA),...).
#N/A
IT Service strategic plan and IT Service tactical plans are available as
input.
#N/A
Relevant information about Services is available as input ( e.g. Service
Portfolio, Service Level Agreements (SLAs), Operational Level
Agreements (OLAs), Underpinning contracts (UCs))
#N/A
Cofiguration Management System (CMS) is available as input.
#N/A
#N/A
#N/A
#N/A
#N/A
identified..
#N/A
process)
#N/A
#N/A
#N/A

#N/A
model.
#N/A
#N/A
and used.
#N/A
used.
#N/A
maintained.
#N/A
improvements
#N/A
stakeholders.
#N/A
#N/A
4. Managed:
expected results.
business goals.
needs.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
7. Process control:
defined limits.
#N/A
#N/A
action.
#N/A
#N/A
5. Optimizing:
goals.
#N/A
#N/A
#N/A
process concepts.
#N/A

#N/A
#N/A
is evaluated)
#N/A
#N/A

Level 1: Initial
Level 2: Repeatable
Set of IT service continuity plans that support the overall business
continuity plans of the organization is produced and maintained in line with
changing business context.
#N/A
Agreed IT service continuity-related service levels are constantly met or
can rapidly be restored in case of significant event or disaster.
#N/A
IT service-related risks are managed according to agreed levels of
business risk.
Risk Management activities are performed in conjunction with the
business, as well as with the Availability Management, and the Information
Security Management processes.
#N/A
Impact of all changes on the IT service continuity plans and supporting
methods and procedures is assessed and addressed.
#N/A
Advice and guidance on all IT service continuity-related issues are
provided to all other areas of the business and IT.
#N/A
IT service continuity plans are tested and exercised to ensure their
adequacy to respond to the agreed business continuity expectations.
#N/A
Cost-justifiable measures to ensure the continuity of IT services are
implemented.
#N/A
#N/A
Level 3: Defined
Scope of IT Service Continuity Management is defined - scope of IT
Service Continuity Management is determined and agreed with the
customers through the identification of critical business processes and the
analysis and coordination of the required technology and supporting IT
services.
When to invoke the IT service continuity plan and which business activities
should be safeguarded have to be agreed with the customers.
#N/A
Business Impact Analysis (BIA) is performed - Business Impact
Analysis is performed to quantify which impact that loss of IT service
would have on the business and prioritize IT service recovery accordingly.
BIA exercises are regularly performed to ensure that all continuity plans
are maintained in line with changing business impact and requirements.
#N/A
Risk assessment is performed - risk assessment is performed to
determine the level of threat and the extent to which an organization is
vulnerable to that threat.
Risk assessment exercises are regularly performed to ensure that all
continuity plans are maintained in line with changing business impact and
requirements.
#N/A
Risk reduction measures and recovery options are defined - cost-
justifiable risk reduction measures and recovery options are defined
resulting from risk assessment and BIA .
Preventive measures need to be adopted with regard to those processes
and services with earlier and higher impacts, whereas greater emphasis
should be placed on continuity and recovery measures for those where
the impact is lower and takes longer to develop. A balanced approach of
both measures should be adopted to those in between.
This activity consists in defining and reviewing the IT Service Continuity
strategy.
#N/A
IT service continuity plans are produced and used - IT service
continuity plans and procedures, supporting the business continuity plans,
are produced, maintained and used (e.g. in case of significant event or
service disruption) in order to ensure that the required IT services,
facilities and resources are kept available and usable at an acceptable
level, and are ‘fit for purpose’ as agreed by the business. Impact of all
changes on the IT service continuity plans is accessed, and it is ensured
that all authorized changes are reflected in these plans. Whole IT service
continuity plans are reviewed regularly to ensure that they remain current
and effective.
#N/A
Risk reduction measures and recovery arrangements are
implemented - Predefined risk reduction measures are implemented in
order to reduce continuity risks exposure. Contracts for the provision of
the recovery capability necessary to put the IT service continuity plans into
practice are acquired or negotiated.
Risk reduction measures are usually undertaken in conjunction with
Availability Management, and contracts are negotiated and agreed with
suppliers in conjunction with the Supplier Management process.
#N/A
IT Service Continuity Management purpose: to support the overall Business Continuity
Management (BCM) process by ensuring that the IT service provider can provide minimum agreed
business continuity-related service levels.
NOTE 1: IT Service Continuity Management focuses on events that have significant impact on the business
(including social movements, epidemics …). Less significant events will be treated as part of Event or
Incident Management processes.
NOTE 2: IT Service Continuity Management and Availability Management have a close relationship,

Staff is educated and trained - It is ensured that all staff are aware of
the implications of business and service continuity and consider them as
part of their normal activities, and that everyone involved in the plan has
been trained and has exercised how to implement these plans in case of
significant event or disruption.
#N/A
Continuity plans tests are planed and conducted - program of regular
testing for the IT service continuity plans is establisched, in line with
business (continuity plans) needs or legal requirements. Continuity test
scenarios, objectives and CSFs are defined and tests are conducted to
ensure that the IT service continuity plans work as intended in case of
significant event or disruption. In particular, all IT service continuity plans
should be tested after every major business or IT change.
Continuity plans tests should be performed at least annually. Four types of
tests can be undertaken: walk-through tests, full tests, partial tests,
scenario tests.
Continuity tests failures should be investigated and corrected by
instigating remedial actions.
#N/A
Advice and guidance is provided on IT service continuity issues - advice
and guidance is provided to all other areas of the business and IT on all IT
service continuity related issues.
In particular, IT Service Continuity Management should be involved in
defining SLRs and SLAs (particularly the Minimum Business Continuity
Objective), designing new or changed service (availability and recovery
design criteria), and analyzing change impact.
#N/A
#N/A
IT service continuity strategy is defined and maintained.
IT service continuity strategy - The strategy for IT service continuity built
on the results of the Business Impact Analysis and the Risk Analysis and
that establishes an optimum balance of risk reduction and recovery or
continuity options.
It includes consideration of the relative service recovery priorities and the
changes in relative service priority for the time of day, day of the week,
and monthly and annual variations.
#N/A
Business impact analysis (BIA) report is produced.
requirements for IT services.
The dependencies may include suppliers, people, other business
processes, IT services, etc. The requirements include Recovery Time
Objectives (RTO), recovery point objectives and minimum service level
targets for each IT service
#N/A
Risk assessment report is produced.
#N/A
IT service continuity plans are defined and maintained.
IT service continuity plans - A set of plans defining the steps required to
recover one or more IT services. Each plan will also identify the triggers
for invocation, people to be involved, communications, etc. The IT service
continuity plans should be part of a business continuity plan.
IT service continuity plan typically includes the following information: -
details of the combined component RTOs and RPOs and inclusion of the
IT Requirements Gap Analysis - IT architecture - roles and responsibilities -
invocation procedures - damage assessment - escalation and process
flow charts - procedures specifying how to recover each component of the
IT system - test plans specifying how to test that each component has
been recovered successfully - incident logs - contact details - fail-back
procedures - IT test plan
#N/A
IT service continuity test schedule is defined and maintained.
IT service continuity test schedule - Schedule for testing all the resilience
and recovery mechanisms. The test schedule should also document the
number of testers available for testing.
#N/A
IT service continuity test scenarios are defined and mainteined.
A detailed description of the tasks that will be undertaken whilst
conducting IT service continuity test. The test scenarios detail the scope
of the test and define the success criteria.
#N/A
Continuity test report is produced.
Continuity test report - A report on the tests done for all continuity and
recovery mechanisms.
#N/A
Business continuity strategy and plans are available.
Business continuity strategy and plans - Business continuity strategy: the
strategy for business continuity based on the results of the Business
Impact Analysis and the risk analysis. It should establish an optimum
balance of risk reduction and recovery or continuity options. Business
continuity plans: a set of plans defining the steps required to restore
business processes following a disruption.
The plan also identifies the triggers for invocation, people to be involved,
communications etc. IT service continuity plans form a significant part of
business continuity plans.
#N/A

ITIL Process Assessment - Service Design (XLS)

ITIL Process Assessment - Service Design (XLS)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ITIL Process Assessment - Service Design (XLS)

Similaire à ITIL Process Assessment - Service Design (XLS) (20)

Plus de Flevy.com Best Practices

Plus de Flevy.com Best Practices (20)

Dernier

Dernier (20)

ITIL Process Assessment - Service Design (XLS)