Subido por loorobxqwdumphlondl

itil v3 service operation design guidelines

Anuncio
Exclusive New Report
ITIL Design Guidelines
Part 4 – ITIL Service Operation
Randy A. Steinberg
Robin Yearsley
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 1
ITIL Design Guidelines
Part 4 – ITIL Service Operation
Paper Overview
Purpose
This paper briefly describes the concept of using guidelines when
designing ITIL services. It then presents a starter set of design
guidelines that can be used by IT Service Management
Implementation teams.
Contents
This publication contains the following topics:
Topic
Paper Overview
Understanding Design Guidelines
Design Guideline Examples for ITIL Service Operation
© 2007 Randy A. Steinberg & Robin Yearsley.
See Page
1
2
9
Page: 2
Understanding Design Guidelines
Overview
Introduction
The following section provides some basic background on what
Design Guidelines are and how to use them.
Contents
This part contains the following topics:
Topic
Design Guidelines Defined
Components of a Design Guideline
Examples of Design Guidelines
Examples of Poorly Constructed Design Guidelines
Examples of Design Guideline Categories
© 2007 Randy A. Steinberg & Robin Yearsley.
See Page
3
4
6
7
8
Page: 3
Design Guidelines Defined
Introduction
The following section defines Design Guidelines within an ITIL
context and lists their key attributes.
Definition
Design Guidelines:
• Are statements about how IT Services should operate.
• Support the IT Service Management Vision.
• Are critical statements of direction that will have major impact on
how IT services should be designed and operated.
• Should be clearly understood and communicated both internally
and externally to IT Services.
Derivation
These Guidelines are derived from:
• Basic beliefs
• Experience
• Priorities
• Underlying culture within a business organization
• People involved with the delivery of IT Services.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 4
Components of a Design Guideline
Introduction
As an early activity in IT Service Management implementation,
consider each guideline in isolation. The underlying rationale for
advancing each guideline with its resulting implications and impacts
should be agreed to and documented.
Describing
Guidelines
Each guideline has three parts, which are described below:
• Statement
• Rationale
• Implications
Statement
This consists of a single sentence that states the guideline.
Example:
We will let our customers know the key services we offer them and
who is accountable.
Rationale
This lists reasons why the guideline should be accepted by the
business.
Considerations include:
• Why should the organization do this?
• What business benefits does this guideline advance?
• What characteristics can be used to defend the guideline?
Examples:
• Will provide clear accountability for the service.
• Will provide service clarity for the customer.
Continued on next page
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 5
Components of a Design Guideline, Continued
Implications
This lists areas of impact to business and IT units as a result of
operating with the guideline.
Considerations include:
• What needs to be done if the guideline is implemented?
• What impact will it have on business and IT units?
• What kind of behaviours, tools, data or processes need to be in
place to support it?
Example:
• We will need to define each service that we offer in a Service
Catalogue.
• We will need to develop cross-organizational capabilities.
• We will have to establish a formal communications program.
• We will have to establish a single owner for each service.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 6
Examples of Design Guidelines
Characteristics
Well designed guidelines have the following characteristics:
• States a fundamental belief of the enterprise in one or two clearly
written sentences.
• Relevant to the IT Service Management solutions.
• Worded directly and simply in terms understandable by both
business and IT managers.
• Widely applicable.
• Will not be outdated quickly by advancing technology.
• Have objective reasons for advancing it over the considered
alternatives.
• Have impacts which need to be documented.
Examples
The following are examples of some well constructed design
guidelines:
• External customer information will be kept strictly confidential
within policies set by the organization and regulatory agencies.
• Service Management solutions, whether purchased or developed
internally, will be highly structured and modular.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 7
Examples of Poorly Constructed Design Guidelines
Characteristics
The characteristics of a poorly designed guideline are:
• The statement is difficult to dispute.
• Is a general business or financial statement.
• Does not support business goals.
• Is stated at too low a level or names a product/technology.
• May be included with "because I say so".
Examples
Examples of some poorly designed guidelines are:
• The overall cost of computing must be reduced. (A business
objective but not a guideline)
• All servers will use the EISA Bus to achieve high performance.
(Specifies an exact standard at a very low technical level)
• Only Ethernet LANs will be implemented in our corporation.
(Specifies a standard with a specific technology already selected)
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 8
Design Guideline Examples for ITIL Service Operation
Overview
Introduction
The purpose of these examples to give the reader a starting point for
defining their own unique design guidelines, not to dictate or
recommend them.
For purposes of clarity, the examples are grouped by key topics within
the ITIL Version 3 Service Operation book.
Contents
This section contains the following topics:
Topic
Event Management Examples
Incident Management Examples
Request Fulfillment Examples
Problem Management Examples
Access Management Examples
Service Desk Examples
Common Service Operation Examples
© 2007 Randy A. Steinberg & Robin Yearsley.
See Page
10
19
26
31
35
42
49
Page: 9
Guideline Example #1 – Event Management
Guideline
• Event notifications will only go to those responsible for handling or
decision processes related to them.
Sample
Application
Each event is tagged to a set of distribution lists of who receives the
event. These lists are maintained though Change Management.
Rationale
• Directs event handling activities only to those who must process
them.
• Avoid needless notifications to those not directly involved in
processing events.
Implication
• We identify which departments, groups or individuals need to
respond to events.
• We maintain event routing information as new events are added or
personnel responsibilities change.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 10
Guideline Example #2 – Event Management
Guideline
All event management and support will be centralized.
Sample
Application
All events from distributed e-mail processing servers will be routed to
the main processing center for escalation and handling.
Rationale
• Avoids conflicts in management of events.
• Allows for appropriate operational response for new events and
changes in processes.
• Avoids support personnel receiving event notifications for events
they are not prepared to handle.
Implication
• A common rule base has been built and maintained.
• We process rule changes and additions through a change
management process.
• Support personnel have buy-in processes to accept/reject event
changes.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 11
Guideline Example #3 – Event Management
Guideline
All application events must utilize a common set of messaging and
logging standards.
Example
All ABC application transaction programs will raise their events by
logging an event alarm record. This record will have fields and a
structure that conform to the corporate standard record structure for
system events.
Rationale
• Consistent, common ways to process and handle events.
• Faster implementation of event processing.
• Sets common expectations for how events will be recognized and
handled.
Implication
• Publish a standard set of APIs, event message formats, usage and
event classification criteria.
• Communicate event management standards to application
development personnel.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 12
Guideline Example #4 – Event Management
Guideline
Only application events that are made available will be recognized
and processed.
Sample
Application
End-user availability of application ABC cannot be monitored unless
dummy transactions are developed that run automatically during
periodic intervals that drop status information. These dummy
transactions must be reflective of general end-user behavior and the
basis for end-to-end availability will be calculated from the logged
status information.
Rationale
• Cannot effectively monitor what cannot be seen.
Implication
• Application developers identify which application events are to be
recognized.
• Application developers build messaging hooks into the applications
for events they wish to recognize.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 13
Guideline Example #5 – Event Management
Guideline
Event processes will be automated whenever possible.
Sample
Application
Event handling procedures will be reviewed on a bi-monthly basis to
determine candidate activities for automation. A small Service
Improvement Program will be put into place to implement any
automation recommendations found.
Rationale
• Eliminates potential problems that can be caused by human error.
• Targets event processing that can occur transparently to end-users
and IT personnel.
Implications
• We implement programs to continuously look for candidates for
automation.
• Automation solutions for application events involve developers
who may need to construct additional scripts, code or procedures
to provide automated recovery at the applications level.
• Application dependencies are considered when developing
automated response handling.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 14
Guideline Example #6 – Event Management
Guideline
All events must subscribe to a standard classification scheme that
references common handling and escalation processes.
Sample
Application
All ABC application database events will be classified as application
level events and escalated to the applications support group.
Rationale
Implication
• Provides a consistent approach and set of expectations for handling
and managing events in a manner tied to service level objectives.
• Streamlines the number of escalation approaches and handling
processes that will need to be built.
• We tie common approaches to service levels and objectives for
problem severity, notification and priority levels.
• We establish common handling processes for each class of event.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 15
Guideline Example #7 – Event Management
Guideline
Only events that require operational intervention will be recognized.
Sample
Application
User-ID password resets will only be logged to the central security
database for audit purposes. Password reset attempts that exceed 3
tries will raise a Security event that will escalate to the Security
Management support group.
Rationale
• Eliminates needless notifications.
• Makes recognition of events more noticeable to support staff by not
mixing important events with unimportant notifications and
messages.
Implications
• We identify what messages are important.
• We list events in a common classification scheme.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 16
Guideline Example #8 – Event Management
Guideline
All recognized events will be captured and logged.
Sample
Application
All application ABC events will be tagged with their event
classification type and logged into event databases for review and
analysis. Event history will be maintained for 6 months.
Rationale
Implication
• Provides a means for examining problems and trends after events
have occurred.
• Serves as an aid for root cause analysis in Problem and Availability
Management.
• We log all recognized events.
• We provide adequate storage resources for event capture and
retention.
• We implement data manipulation, filtering and reporting to quickly
search and identify event situations.
• We interface events with Incident and Problem Management
databases.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 17
Guideline Example #9 – Event Management
Guideline
Every recognized event must have a clear owner.
Sample
Application
John Smith will own all events classified as security. John will triage
and forward events to needed operational support staff when they
have been recognized.
Rationale
Implication
• Clearly identifies responsibilities for event handling.
• Clearly communicates to support staff who should handle what
kind of events.
• We identify default owners by event or class of event.
• We differentiate roles and responsibilities between groups charged
with event handling responsibilities.
• We split roles and responsibilities for complex events.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 18
Guideline Example #10 – Incident Management
Guideline
Incident processing and handling must be aligned with overall service
levels and objectives.
Sample
Application
All application ABC database events must be escalated to third level
support if they have not been resolved within 5 minutes.
Rationale
• Ensures incident handling supports service levels and objectives.
• Identifies which incidents require high priority handling based on
actual business need.
Implications
• We understand service levels and objectives that need to be
provided for.
• We build event handling that is targeted towards service levels.
• We develop Service Desk and Incident Management Operational
Level Agreements to set thresholds for when Incident escalation
and notification actions should be taken.
• We implement reporting on service actions and thresholds within
Incident Management functions.
• We time stamp key Incident Management activities.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 19
Guideline Example #11 – Incident Management
Guideline
All incidents should be stored and managed in a single data
repository.
Sample
Application
A central repository database exists that is the definitive source for all
incident information.
Rationale
• Provides definitive recognized source for incident information
• Provides easier access for reporting and problem investigation efforts
Implications
• We have implemented an Incident Management Database capability
for incident information
• We have implemented integration between this repository and other
service management tools that use or provide incident related
information
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 20
Guideline Example #12 – Incident Management
Guideline
All incidents will subscribe to a standard classification schema that is
consistent across all of IT.
Sample
Application
A standard schema exists for classifying all incidents. All IT incidents
are logged to the categories in this schema.
Rationale
Implications
• Provides easy access to incident work-around and troubleshooting
information
• Critical for supporting Problem Management activities
• We have a well defined and communicated set of incident
classification categories
• It is impossible for anyone to enter non-standard categories for
incidents
• Service Desk and incident handling staff are aware of what
categories exist
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 21
Guideline Example #13 – Incident Management
Guideline
Incident records will be audited on a regular basis to ensure they have
been entered and categorized correctly.
Sample
Application
At the end of each day, closed incidents are audited to verify that they
have been entered and categorized correctly.
Rationale
• Ensures incident information is accurate and useable by Problem
management and other support areas
• Supports trending analysis and related activities around incidents
and problems
Implication
• We have an independent auditor role in our organization to audit
incident records for accuracy
• Feedback mechanisms are in place to communicate audit findings
and issues to incident handling staff
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 22
Guideline Example #14 – Incident Management
Guideline
IT will own and manage all definitive sources of knowledge used to
diagnose and troubleshoot incidents related to IT services.
Sample
Application
Each service unit within IT has the responsibility to provide
knowledge for diagnosing and handling incidents to Incident
management staff. This responsibility includes maintaining that
knowledge on a regular consistent basis to make sure it is timely and
accurate.
Rationale
• Ensures up-to-date and accurate information is available to incident
handling staff
• Supports efforts to get incidents handled faster and at first call more
frequently
Implications
• We have roles and responsibilities assigned for each service
component to input and maintain knowledge for incident handling
staff
• We have tools in place to capture and communicate knowledge and
knowledge changes to incident handling staff
• We handle knowledge changes through the Change Management
process
• We integrate with the Problem Management process to get
information on problems and work-arounds.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 23
Guideline Example #15 – Incident Management
Guideline
All incidents will be recorded in the incident management system.
Sample
Application
Periodic audits are conducted on a regular basis to check that all
incidents are being recorded. IT support labor is tied to incident tickets
to quickly raise awareness of resolution work for incidents not
recorded.
Rationale
• Ensures recognition of all incidents and activities taking place to
resolve them.
• Provides an authorized record of incident management activity.
• Ensures incidents do not “slip through the cracks” and go on
unaddressed.
• Provides IT management with an accurate picture of the quality and
issues with the IT infrastructure.
Implications
• An investment in an Incident Management system will be needed.
• Service Desk and IT support staff will need training for recording
and accessing the incident management system.
• Recognition and possible penalties need to be in place for incident
resolution activity taking place without a corresponding incident
ticket.
• A mechanism must be put into place for recording incidents raised
through automated tools and alerts.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 24
Guideline Example #16 – Incident Management
Guideline
Standard criteria will exist for identifying incident severity levels.
Sample
Application
The Service Desk maintains a standard chart showing all incident
severity levels and their criteria. Service Desk staff use this chart
extensively when escalating calls and reported incidents from end
users.
Rationale
• Prevents incidents from being handled based on isolated judgments
of IT support staff or business users.
• Prevents users from raising incidents to high levels to get attention
when that is unnecessary.
• Eliminates finger pointing over why incidents were handled one
way versus another.
Implications
• Detailed criteria for severity levels needs to be defined and well
communicated throughout the enterprise.
• Severity level criteria needs to be agreed to by the business.
• Service Desk and IT support staff need to understand that the criteria
determines the severity level, not the judgment of staff and callers.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 25
Guideline Example #17 – Request Fulfillment
Guideline
A separate process will exist for handling day-to-day IT requests from
the business.
Sample
Application
A business user contacts the Service Desk with a request to move her
PC to a new location. The Service Desk routes the request through a
request handling process that is separate from Incident and Change
Management processes.
Rationale
• Requests typically have known outcomes, approval and execution
paths that are not incidents or changes.
• Mixing requests with incidents and changes skews the real
operational quality picture when measuring the effectiveness of
those processes.
• Simplifies handling and tracking of day-to-day requests with a
minimal amount of management overhead.
Implications
• Well established criteria for what is a request versus a change or an
incident needs to be in place and well communicated.
• Requests need to be linked to change management as standard
changes.
• Business users need to be made aware of the request process and
what they can expect.
• Service targets and priorities will be different for requests than they
would be for incidents and changes.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 26
Guideline Example #18 – Request Fulfillment
Guideline
Criteria need to be in place that differentiates a request from an
incident or change.
Sample
Application
A Request Management Policy is in place that differentiates what
determines a request from an incident or change. Key criteria for this
includes:
• Must be recurring event that is performed frequently in the
company
• Must follow a standard processing path with a known outcome
• Approval has been provided in advance
• Follows the Change Management criteria for a Standard
Change
Rationale
• May mishandle request of not properly classified.
• IT staff should not be in position of making judgment calls on
whether the request should be handled via the Request Fulfillment
process versus Incident or Change processes.
• Sets expectations among business users and IT staff for how their
requests will be handled.
Implications
• Criteria for what determines a request will have to be clearly
defined and communicated.
• Both IT and the business need to agree on what events will be
considered requests.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 27
Guideline Example #19 – Request Fulfillment
Guideline
The means for processing requests will be planned for in advance.
Sample
Application
The company has established a predefined process workflow to
include the stages needed to fulfill requests for provisioning office
LAN servers. The individuals and support groups involved, target
timescales, and escalation paths have been designed in advance.
Provisioning the office servers has been established as a Standard
Change with Change Management. The ownership of those requests
will reside with the Service Desk, which will monitor, escalate,
dispatch and close the request.
Rationale
• Requests are planned events whereas incidents and changes are
not.
• Requests cannot be handled in a consistent efficient manner if the
means for handling them has not been planned for in advance.
• Planning is needed to ensure that unplanned events do not occur in
the course of handling a request.
Implications
• We need to understand which events will be categorized as
requests in advance.
• Procedures, activities, roles and responsibilities for processing
requests will have to be designed and built in advance.
• Training and communications to Service Desk and support staff
will be needed before processing of requests can begin.
• Service targets will need to be established and tested for in advance
of starting request fulfillment processing.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 28
Guideline Example #20 – Request Fulfillment
Guideline
All service requests must be handled in a consistent manner that meets
established service targets.
Sample
Application
The company IT department has created sets of pre-defined Request
Models to handle each kind of request that will be part of the Request
Fulfillment process. Development activities for this include preapproval by Change Management to establish them as standard
changes.
Rationale
• Variation in handling requests increases labor costs and threatens
service quality.
• Inadvertent handling of requests may bleed over into events that
would be better processed through incident or change
management.
• Increases overall business satisfaction with IT services.
• Reduces bureaucracy and overhead for handling of day-to-day
requests and needs.
Implications
• Standard processing for fulfilling requests needs to be planned for
in advance and well communicated to support staff.
• Request fulfillment procedures will need to be tested to ensure they
work and meet desired service targets.
• Any business needs that might cause variation in handling of a
requests should be known to the greatest extent possible.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 29
Guideline Example #21 – Request Fulfillment
Guideline
Handling and processing of requests should be automated to the
greatest extent possible.
Sample
Application
Company business users are offered a ‘menu’-type selection via a
web interface, so that they can select and input details of Service
Requests from a pre-defined list. In some cases, the requests
themselves are processed automatically with only a notification back
to IT. In other cases, work orders to IT support staff are automatically
generated.
Rationale
• Greatly increases the efficiency of handling and fulfilling requests.
• Greatly reduces the risk of human error when processing requests.
• Reduces labor costs.
• Increases business satisfaction with IT services.
• Services can be offered more easily 24x7 or when the business
needs them instead of confined to IT operating hours.
Implications
• Request types must be known in advance.
• Investment may be needed in automation tools to handle requests
electronically.
• Automated processing of requests must still be logged and
communicated.
• Increased skills among IT support staff will be needed to manage
and maintain any automated solutions used.
• Investment in a workflow management tool may be needed.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 30
Guideline Example #22 – Problem Management
Guideline
Every high severity problem will require a documented root cause and
control.
Sample
Application
All incidents marked as SEV1s will be assigned to a Problem Owner
who has the responsibility to identify and document the Root Cause.
Rationale
• Ensures Problem Management focus on all high severity incidents.
• Proactively works to reduce or eliminate future high severity
incidents.
• Provides upper management communication and assurances that
high severity incidents are being appropriately addressed.
Implication
• Problem Owners are assigned to every SEV1 generated.
• Solid skills are in place to identify Root Cause.
• Management communications are in place to communicate timely
and useful Incident information.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 31
Guideline Example #23 – Problem Management
Guideline
Problems will be tracked separately from Incidents.
Sample
Application
A separate database exists that contains Problem Records to record
Problem Tickets and status. Known Errors, Problem Workaround
information and status on Problem and Error Control activities is also
kept in this database.
Rationale
• Provides clear separation between proactive Problem Management
activities and reactive Incident activities
• Easier ability to track Problem management activities and progress
separately
Implication
• Tools are in place to track Problems separately from Incidents
• Problem categories and reporting are in place
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 32
Guideline Example #24 – Problem Management
Guideline
Every problem will have an assigned owner.
Sample
Application
After identifying a problem that appears to be causing multiple
incidents, the Problem manager has assigned an owner dedicated to
finding its Root Cause and coordinating activities to remove the error.
Rationale
• Ensures responsibility assigned to fix problems
• Provides single point of contact for communications about problems
Implication
• The Problem Owner role is understood and communicated
throughout the organization
• Problem Owners have appropriate authorization to coordinate and
take actions to identify Root Cause and remove the error
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 33
Guideline Example #25 – Problem Management
Guideline
Standard criteria will be in place to raise problems from incidents.
Sample
Application
An INCIDENT will become a PROBLEM when any of the following as
occurred:
• Incident management cannot match an incident to existing
Problems and Known Errors
• Trend analysis of logged incidents reveals an underlying problem
• The INCIDENT is a SEV1
Other IT areas identify that a problem condition exists
Rationale
• Provides clear distinction between Incidents and Problems within the
company.
• Focuses Problem management resources on higher priority areas.
Implication
• Clear communication on what is a PROBLEM versus an INCIDENT
needs to be understood and communicated
• Current practice of conducting root cause activities for ALL company
incidents may change
• May need to provide dummy Problem records that can be used by
Incident Management for low impact, non-recurring incidents.
• Need to clarify Incident management role in providing and
documenting root cause for incidents
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 34
Guideline Example #26 – Access Management
Guideline
The costs and overhead of an access management solution will be
balanced against the risks associated with the information or physical
facilities being accessed.
Sample
Application
It is our practice to require an employee at a high security facility to
spend 30 seconds to verify on the system; such users are unlikely to
feel offended by the technique or to find it an invasion of their privacy.
At the other extreme, if access is implemented to allow an employee
into the company cafeteria, the same access strategy will make that
employee feel uncomfortable or intruded upon unnecessarily.
Rationale
•
•
•
Implication
•
•
Low business satisfaction levels will occur if access mechanisms
are way too high for information and areas that are low in risk.
Costs may be higher than necessary to manage access.
IT needs to be aware of the risk levels they are managing against.
The level of risk exposures need to be known for each item or
facility being accessed.
High risk areas will require more investment in access
management supporting technologies.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 35
Guideline Example #27 – Access Management
Guideline
Access Management deployments must not be expanded to perform
broader verification or identification-related functions than originally
intended.
Sample
Application
A company policy exists that strongly states that Access Management
solutions are strictly for validating access to company secure
information, applications and physical facilities. Any expansion or
retraction of scope for access management solutions is accompanied
by full and public disclosure, under the oversight of an independent
auditing body, allowing individuals to opt-out of system usage if
possible.
Rationale
•
•
Implication
•
•
•
Risks are created when access management solutions are
employed for purposes beyond those originally intended.
Privacy policies and regulations may be compromised.
A strong policy defining the scope of access management solutions
must be in place and strictly enforced.
An independent auditing body may be needed to oversee scope of
access management solutions.
Investments in access management solutions may not be leveraged
for other purposes.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 36
Guideline Example #28 – Access Management
Guideline
There should be no establishment of a unique identifier within the
access management solution.
Sample
Application
The company implements sufficient protections to ensure that user
information cannot be used as a unique identifier. Enrollments to the
access management network are carefully controlled and encrypted
to ensure they also do not become unique identifiers.
Rationale
• Unique identifiers facilitate the gathering and collection of personal
information from various databases, and represent a significant
threat to privacy.
• This type of identifier could be used as an identifier across multiple
databases and applications.
Implications
• The unique identifier issue will become more problematic if a
biometric technology is developed which generates the same
template every time a user interacts with a system.
• There is a risk that DNA could develop to this point, as a user's
DNA profile does not change from day to day as does a finger or
facial-scan.
• Enrollment data for secured access solutions will have to be
carefully controlled as it could be shared across various agencies or
companies in unencrypted form.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 37
Guideline Example #29 – Access Management
Guideline
Protection of access management information should be tightly
controlled at all times.
Sample
Application
The company protects Biometric Information at all stages of its
lifecycle, including storage, transmission, and matching. The
protections enacted may include encryption, private networks, secure
facilities, administrative controls, and data segregation. The
protections necessary within a given deployment are determined by a
variety of factors, including the location of storage, location of
matching, the type of biometric used, and the capabilities of the
biometric system, which processes take place in a trusted
environment, and the risks associated with data compromise.
Rationale
• Exposure of information will create great risks for unauthorized
access to company resources.
• Loss of access management information may create a major business
disruption of resources cannot be accessed by those who need to.
Implication
• An investment in securing access management solutions must be
made.
• Policies and procedures for management of access must be tightly
controlled and strictly enforced.
• Compromise or failure of access management solutions should be
regarded as major incidents.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 38
Guideline Example #30 – Access Management
Guideline
Protection of post-match information should be tightly controlled at all
times.
Sample
Application
Data transmissions resulting from biometric comparisons are strongly
controlled and protected by the company. The network handling these
transmissions is securely controlled within the company’s DMZ.
Rationale
• Although these post-comparison decisions do not necessarily contain
any biometric data, their interception or compromise could result in
unauthorized access being granted to personal information.
• Some comparisons might take place in non-trusted environments
such as the Internet.
Implication
• The entire infrastructure used to underpin access management
activities and actions must be protected, not just the access
management solution itself.
• Access management solutions must be implemented within
company secure perimeters and trusted networks.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 39
Guideline Example #31 – Access Management
Guideline
Access management information must only be stored for the specific
purpose of usage in accessing systems and facilities and should not be
stored any longer than necessary.
Sample
Application
Company policies state that Biometric information should be
destroyed, deleted, or otherwise rendered useless when the system is
no longer operational; specific user information should be destroyed,
deleted, or otherwise rendered useless when the user is no longer
expected to interact with the system. This also applies to templates
generated during comparison attempts, such as a template generated
in the verification stage of an application.
Rationale
• The longer access information is left in storage, the greater the risk
it may be compromised.
• Allows for additional risks of exposing information for other
purposes than what was intended.
Implications
• Awareness of access management transactions needs to be in place
with events triggered to delete information at the earliest point
possible.
• Access management information may not be used for any other
purpose than what it was intended for.
• Periodic audits and oversight may be needed to validate that
information is being deleted properly.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 40
Guideline Example #32 – Access Management
Guideline
Ample and clear disclosure must be provided when individuals are
being enrolled in an access management system.
Sample
Application
Company policy states that ample and clear disclosure must be
provided when individuals are being enrolled in an access
management system. Disclosure must take place even if the
enrollment templates are not being permanently stored, such as in a
monitoring application. This includes employees enrolled in a facialscan system through badge card pictures or drivers’ licenses photos,
or telephone callers enrolled in a voice-scan system.
Rationale
• A basic privacy principle is that individuals must explicitly consent
to the collection, use and storage of personal information.
• Access information and data is personal information, and its
surreptitious collection for the purpose of enrollment is
inconsistent with reasonable privacy expectations.
• Access information can easily be shared between corporations,
partners, and other agents who may not adhere to the same data or
privacy protections as the original entity to whom the user
provided access data.
Implications
• Biometric information must only be used for the purpose for which
it was collected, within the system for which it was collected,
unless the user explicitly agrees to broader usage. There must be no
sanctions applied to any user who does not agree to broader usage
of his or her biometric information.
• As control over personal information is a basic privacy principle,
individuals should have the option of extending the utility of their
access data. For example, a user who accesses an online account
through a biometric should be allowed the option of securing
additional accounts with the same biometric information.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 41
Guideline Example #33 – Service Desk
Guideline
End-user support will be provided by a single toll-free number.
Sample
Application
All company ABC employees are to call 1-800-HELP-NOW to access
the company Service Desk.
Rationale
• Provides ease of access to services.
• Promotes use of the service interface.
• Reduces the number of interfaces.
• Promotes user satisfaction.
• Provides single-point-of-contact for all IT services.
Implications
• Service Desk support is effective.
• There is investment in tools to provide support.
• User satisfaction is continually measured.
• Telecom costs have been considered.
• Overseas calls are accommodated.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 42
Guideline Example #34 – Service Desk
Guideline
The Service Desk will be the single-point-of-contact for all
communications about IT incidents, problems, and announcements
throughout the company enterprise.
Sample
Application
During the course of a major incident, all requests for incident status,
expected recovery times and actions being taken for resolution are
communicated via the Service Desk.
Rationale
• Provides an authoritative source for all IT communications.
• Prevents IT labor from being spent on non-authorized activities
and requests.
• Ensures consistent communications – especially for major incidents
and IT actions.
• Allows IT to focus on resolving incidents and requests versus being
interrupted to provide status to many stakeholders.
Implications
• IT staff will need to be authorized to reject requests for help unless
authorized by the Service Desk.
• An incident and request ticketing solution needs to be in place.
• IT Labor reports may need to be tightly tied to incident tickets and
requests that they are working on.
• The Service Desk must be seen as helpful and the preferred way of
getting things done by business users throughout the company.
• The Service Desk will need to be easily accessible throughout the
company.
• Multiple channels of communication may be needed to
communicate with the Service Desk (e.g. Telephone, Fax, Email,
etc.).
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 43
Guideline Example #35 – Service Desk
Guideline
The Service Desk will prioritize activities based on service levels and
priorities for services being impacted.
Sample
Application
Email service for the company’s commodity traders receives priority
response from the Service Desk for even the most minor service
outage. Other company departments will receive priority response
only if entire departments are impacted. This decision is based on
business priorities since the commodity traders use Email as a critical
service to bring in major revenue dollars to the company.
Rationale
• Ensures that the most critical issues are addressed by the Service
Desk first.
• Aligns Service Desk activities and priorities with business
priorities.
• Ensures valuable Service Desk resources are not being overly
devoted to non-critical services.
Implications
• Services and service targets must be understood and well
communicated to the Service Desk.
• Warnings and alerts will be needed to identify critical service
targets that are being missed or in jeopardy.
• Management must provide support for Service Desk decisions on
service and business priorities.
• Some executives and users will try to raise the priority of their calls
and issues unfairly.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 44
Guideline Example #36 – Service Desk
Guideline
The Service Desk will ensure that the user who raised a call is satisfied
with the resolution prior to closure of the call.
Sample
Application
After indication that an incident has been resolved, the Service Desk
contacts the end user to obtain their agreement that the incident can be
closed.
Rationale
• IT should not take the decision to close an incident on their own
without business user agreement.
• Increases business satisfaction with IT services.
• Prevents frequent reopening of incidents after they have been
closed.
Implications
• Call management procedures should ensure that callbacks are
placed to the business user at the resolution of each incident or
service request reported.
• Incident tracking systems will need to recognize the difference
between tickets that IT says are complete distinctly from final
closure of them agreed to by the business.
• Service Desk call agent labor should take the time needed to
process user callbacks into account when determining staffing
levels and call agent targets.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 45
Guideline Example #37 – Service Desk
Guideline
An escalation policy should be established in order that the Service
Desk can make decisions on when an incident should be escalated
through the management chain.
Sample
Application
When an incident is reported, the Service Desk has established predefined time limits that define how long a call agent should try to
service a call before escalating to the duty manager.
Rationale
• Ensures timely handling of incidents.
• Raises awareness of more severe incidents more quickly and
efficiently.
• Lack of a policy will lead to delays, finger pointing and redundant
labor in handling incidents.
Implications
• An escalation policy needs to be defined and well communicated to
Service Desk and IT support staff.
• Automated warnings and event triggers may need to be defined to
recognize when calls are exceeding threshold times or for when
service levels are being threatened.
• Levels of management higher up the escalation chain must
explicitly understand and recognize their priorities in dealing with
calls that may be escalated to them.
• Communication and awareness needs to be established to identify
incidents that have been escalated and to what level.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 46
Guideline Example #38 – Service Desk
Guideline
Service Desk call handling will be designed to resolve as many calls
within the Service Desk as possible without escalation.
Sample
Application
Each month, the Service Desk manager reviews calls that have been
escalated outside the Service Desk to identify actions that can be taken
to avoid further escalations. This may include increased training of call
agents, better knowledge tools or identifying incident trends to IT
support staff.
Rationale
• Greatly increases business satisfaction with IT services.
• Greatly increases business confidence with the Service Desk.
• Prevents callers from bypassing the Service Desk.
• Maintains company investment in high quality Service Desk
support services.
Implications
• Additional investment in call ticket review activities will be
needed.
• There will be a temptation on the part of the Service Desk to not
escalate calls in order to show better results when in reality, those
calls should have been escalated right away.
• The Service Desk will require strong working relationships with
other IT support staff to implement improvements when needed.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 47
Guideline Example #39 – Service Desk
Guideline
The Service Desk should have easy access to a comprehensive,
accurate, and holistic view of the IT environment.
Sample
Application
The Service Desk has been co-located with the company’s IT
Command Center to provide easy local access to infrastructure
displays and alerts.
Rationale
• The Service Desk is the communications hub for the IT
infrastructure.
• Provides capability to resolve many more calls and incidents
without escalation to other support groups.
• Provides early warning of impending problems and issues that can
be communicated at the point of end user call.
• Service Desk cannot provide high quality service if it is not aware
of what is going on in the IT infrastructure.
• Other IT support groups do not always have an interest in
maintaining a holistic view of what is happening throughout the IT
infrastructure.
Implications
• Investment will be needed in consoles, monitoring tools, alerting
and display technologies.
• Service Desk staff will need to adopt a holistic view of the IT
infrastructure when providing services.
• Service Desk staff will need to be trained on monitoring and
display technologies that have been implemented.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 48
Guideline Example #40 – Common Service Operations
Guideline
There should be a common naming convention for job and event
scheduling.
Sample
Application
All naming conventions for job scripts, JCL and event schedules
matches the naming conventions in the IT Release Policy.
Rationale
• Simplifies administration across platforms.
• Common language across platforms.
• Simplifies integration between Systems Management and Service
Management.
Implications
• Common and integrated data model for Systems Management and
Service Management is needed.
• Must be aligned with naming conventions used across IT.
• Tools will be needed to administrate naming conventions.
• Ownership of the naming convention must be defined.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 49
Guideline Example #41 – Common Service Operation
Guideline
All documentation regarding scheduling should be located in one
place.
Sample
Application
Operational run books are kept online and easily accessible from the
company’s intranet. Hardcopy versions are also stored in each
command center in the event the intranet is not accessible. A
procedure is in place to keep hardcopy and online versions
synchronized triggered from Change Management.
Rationale
• Instruction will be available for corrections and re-executions.
• Increases quality in operations.
Implication
• Supporting tools will be needed.
• Centralized coordination will be required.
• Ownership must be defined.
• Documentation must be easy to access.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 50
Guideline Example #42 – Common Service Operation
Guideline
All changes in scheduling should be handled through the Change
Management process.
Sample
Application
The RFC for adding a new module to the Sales Reporting system
includes job schedule changes caused by the new reports that the
module will generate.
Rationale
• Increases the quality of services.
• Improved reliability and availability.
• Changes are possible to track.
• All changes within scheduling are documented.
Implications
• Testing environment must be available.
• More administrative overhead must be acceptable for making
scheduling changes.
• Well defined change categories are needed.
• Implemented Change Management process must be in place.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 51
Guideline Example #43 – Common Service Operation
Guideline
Backup process and tools must be 100% reliable, compatible and fault
tolerant.
Sample
Application
For backup jobs that handle critical company data, data validation
steps are performed to ensure data backed up is complete and
accessible. Backup media itself is stored in a separate media library
and this is rotated with an offsite storage facility.
Rationale
• Ensuring the availability of key systems and data that underpins
services is critical.
• Regulatory requirements and audits will require data to be
available or else severe penalties may result.
• Much wasted labor occurs to recover data that is lost or corrupted.
Implications
• All backups must be verified for successful completion.
• Change management must be in place.
• New applications, HW, tools, etc. related to backup must be tested
and certified.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 52
Guideline Example #44 – Common Service Operation
Guideline
Routine backups of data will be automated wherever possible.
Sample
Application
An automated backup and restore tool is used to schedule and execute
backups. Retrieval of backups is also automated.
Rationale
• Creates greater efficiencies and reduces errors.
• Facilitates greater levels of management control.
• Reduced human intervention and enables faster recovery.
Implications
• Costs and customization of tools will be required.
• Comprehensive documentation will be needed to enable manual
recovery when required.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 53
Guideline Example #45 – Common Service Operation
Guideline
All requests for non-standard operational services must be routed
through the Request Fulfilment Management process.
Sample
Application
A one-time request to extend hours of operation for the Sales Support
System for an extra 30 minutes is submitted via a Request For Service
submitted to the company’s Request Fulfilment process. That process
will coordinate the activities for the extension, ensure it does not
impact other operational schedules for that day and validate that the
extension has been put into place.
Rationale
• Provides an efficient way to support non-standard requests for
operational services.
• Ensures requests will not compromise day-to-day operational
activities and functions.
• Provides an audit trail and authoritative record for requests.
Implications
• A Request Fulfilment process must be in place.
• Operations personnel must be authorized to reject operational
requests if they were not initiated by Request Fulfilment.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 54
Guideline Example #46 – Common Service Operation
Guideline
The type and criticality of the data will determine the requirements for
backup and recovery as per Service Level Requirement.
Sample
Application
The backup strategy for the command center prioritizes backup of
data that supports vital business functions.
Rationale
• Provides an effective use of backup resources and investment.
• Avoids unnecessary backups.
• Ensures critical data gets the most attention.
• Reduces requirements for backup windows.
Implications
• Will need to understand services being delivered and criticality of
the data that supports them.
• Will need concurrence of the business for backup service targets.
If you enjoyed this Report, then why
not download part five in the series:
visit: http://www.ITILVersion3.com
and recommend us to get instant
FREE access.
© 2007 Randy A. Steinberg & Robin Yearsley.
Page: 55
Descargar