Overview
of part 1: Specification
ISO/IEC
20000-1:2005 defines the requirements for a service provider to deliver
managed services. It may be used:
1.
by businesses that are going out to tender for their services;
2.
to provide a consistent approach by all service providers in a supply
chain;
3.
to benchmark IT service management;
4.
as the basis for an independent assessment;
5.
to demonstrate the ability to meet customer requirements;
6.
to improve services.
ISO/IEC
20000-1:2005 promotes the adoption of an integrated process approach to
effectively deliver managed services to meet business and customer
requirements. For an organization to function effectively it has to identify
and manage numerous linked activities. Co-ordinated integration and
implementation of the service management processes provides the ongoing
control, greater efficiency and opportunities for continual improvement.
Organizations require increasingly advanced facilities (at minimum cost) to
meet their business needs. With the increasing dependencies in support
services and the diverse range of technologies available, service providers
can struggle to maintain high levels of customer service. Working reactively,
they spend too little time planning, training, reviewing, investigating, and
working with customers. The result is a failure to adopt structured, proactive
working practices. Those same service providers are being asked for improved
quality, lower costs, greater flexibility, and faster response to customers.
In contrast, effective service management delivers high levels of customer
service and customer satisfaction. It also recognizes that services and
service management are essential to helping organizations generate revenue and
be cost-effective. The ISO/IEC 20000 series enables service providers to
understand how to enhance the quality of service delivered to their customers,
both internal and external.
The ISO/IEC 20000 series draws a distinction between the best practices of
processes, which are independent of organizational form or size and
organizational names and structures. The ISO/IEC 20000 series applies to both
large and small service providers, and the requirements for best practice
service management processes are independent of the service provider's
organizational form. These service management processes deliver the best
possible service to meet a customer's business needs within agreed resource
levels, i.e. service that is professional, cost-effective and with risks which
are understood and managed.
Overview
of the Checklist
The process of defining what is necessary for
compliance with a service management process
standard such as “ISO/IEC Standard 20000-1:2005” is often confusing and
laborious because the directions contained in the standards are unclear or
ambiguous. To aid in determining
what is actually “required” by the document in the way of physical
evidence of compliance, the experts at SEPT have produced this checklist.
This checklist is constructed around a classification scheme of
physical evidence comprised of policies, procedures, plans, records,
documents, audits, and reviews. There must be an accompanying record of some type when an
audit or review has been accomplished. This
record would define the findings of the review or audit and any corrective
action to be taken. For the sake
of brevity this checklist does not call out a separate record for each review
or audit. All procedures should
be reviewed but the checklist does not call out a review for each procedure,
unless the standard calls out the procedure review. In this checklist, “manuals, reports, scripts and
specifications” are included in the document category.
When the subject standard references another standard for physical
evidence, the checklist does not call out the full requirements of the
referenced standard, only the expected physical evidence that should be
available.
The author has carefully reviewed the document “ISO/IEC Standard
20000-1:2005 Service management - Part 1: Specification and defined the
physical evidence required based upon this classification scheme.
SEPT has conducted a second review of the complete list to ensure that
the documents’ producers did not leave out a physical piece of evidence that
a “reasonable person” would expect to find.
It could certainly be argued that if the document did not call it out
then it is not required; however if the standard was used by an organization
to improve its process, then it would make sense to recognize missing
documents. Therefore, there are
documents specified in this checklist that are implied by the standard or in
common use in software engineering, though not specifically called out in the
document, and they are designated by an asterisk (*) throughout this
checklist. If a document is
called out more than one time, only the first reference is stipulated.
There are occasional situations in which a procedure or document is not
necessarily separate and could be contained within another document.
For example, the “Service Management Audit
Plan could be a separate plan or part of the Service Management Process
Specific Plan. It would all
depend of the size of the company and project.
The author has called out these individual items separately to ensure
that the organization does not overlook any facet of physical evidence.
If the organization does not require a separate document, and an item
can be a subset of another document or record, then this fact should be
denoted in the detail section of the checklist for that item.
This should be done in the form of a statement reflecting that the
information for this document may be found in section XX of Document XYZ.
If the organizational requirements do not call for this physical
evidence for a particular project, this should also be denoted with a
statement reflecting that this physical evidence is not required and why. The reasons for the evidence not being required should be
clearly presented in this statement. Further
details on this step are provided in the Detail Steps section of the
introduction. The size of these
documents could vary from paragraphs to volumes depending upon the size and
complexity of the project or business requirements.
Checklist
Preparation Steps
This
checklist was prepared by analyzing each clause of this document for the key
words that signify a:
|
·
Policy
·
Procedure
·
Plan
·
Record
·
Document (including Manuals, Reports, and Specifications)
·
Audit
·
Review
|
|
This checklist specifies evidence that is unique.
After reviewing the completed document, the second review was conducted
from a common sense “reasonable man” approach: If a document or other
piece of evidence appeared to be required, but was not called out in the
document, then it is added with an asterisk (*Suggested Item) after its
notation in the checklist. This
notation is listed in the footnotes for each section. The information was then
transferred into checklist tables, based on the type of product or evidence.
Using the Checklist
When
a company is planning to use "ISO/IEC 20000-1:2005" (and sometimes
also ISO 9001:2000) standard, the company should review the evidence
checklist. If the company’s
present process does not address an ISO/IEC 20000-1:2005 (or ISO 9001:2000)
standard product, then this question should be asked:
Is the evidence product required for the type of business of the
company? If in the view of the
company the evidence is not required, the rationale should be documented and
inserted in the checklist and quality manual.
This rationale should pass “the
reasonable person rule.” If
the evidence is required, plans should be prepared to address the missing
item(s).
Detail
Steps
An
organization should compare the proposed output of their organization against
the checklist. In doing this,
they will find one of five conditions that exist for each item listed in the
checklist. The following five
conditions and the actions required by these conditions are listed in the
table below.
Condition
|
Action Required
|
|
1. The
title of the documented evidence specified by the checklist (document,
plan, etc) agrees with the
title of the evidence being planned by the organization.
|
Record in checklist that the organization is
compliant.
|
|
2.
The title of the documented evidence specified by the checklist
(document, etc) disagrees with
the title of the evidence planned by the organization but the content is
the same.
|
Record in the checklist the evidence title the
organization uses and record that the organization is compliant, and the
evidence is the same although the title is different.
|
|
3.
The title of the documented evidence specified by the checklist
(document, etc) is combined
with another piece of evidence.
|
Record in the checklist the title of the evidence
(document, etc) in which this information is contained.
|
|
4.
The title of the documented evidence specified by the checklist
(document, etc) is not planned by
the organization because it is not required.
|
Record in the checklist that the evidence is not
required and the rationale for this decision.
|
|
5.
The title of the documented evidence called out by the checklist
(document, etc) is not planned by the
organization and should be
planned by it.
|
Record in the checklist when this evidence will be
planned and reference a plan for accomplishing the task.
|
|