5.6.4 Service Asset
and Configuration Management Process (SACM)
Service Asset and Configuration management process
ensures the integrity of service assets and configurations
in order to support the effective and efficient management
of the IT organization.
The main reason for configuration management is to
gather the information needed (in a non-duplicated manner)
about the IT components and how they relate to each
other. The reason for this is to ensure that the relevant
information is available for all the other processes
to ensure that detailed impact and risk analysis can
take place.
A) Purpose of Service Asset and Configuration Management
Process(SACM)
SACM ensures that the assets required to deliver
services are properly controlled, and that accurate
and reliable information about those assets is available
when and where it is needed.
This information includes details of how the
assets have been configured and the relationships
between assets.
B) Objectives of Service Asset and Configuration
Management Process(SACM)
Account for all the IT assets and configurations
within the organization and its services.
Provide accurate information on configurations
and their documentation to support all the other
service management processes.
Provide a sound basis for incident management,
problem management, change management and release
management.
Verify the configuration records against the
infrastructure and correct any exceptions
Plan, identify, control, record, report, audit
and verify service assets and configuration items.
Account for manage and protect the integrity
of service assets and configuration items throughout
their lifecycle.
Provide accurate information to support business
and service management.
Ensure the integrity of those items by creating
and maintaining an accurate Configuration Management
System (CMS) as part of the Service knowledge management
System (SKMS)
C) Scope of Service Asset and Configuration Management
Process(SACM)
1) Management of the complete lifecycle of every
Configuration Items (CIs)
Ensures CIs are identified, base-lined and maintained,
and changes controlled
Ensures that releases into controlled environments
and operational use are done on the basis of formal
authorization.
Provides a configuration model of the services
and service assets by recording the relationships
between configuration items
2) Interfaces to internal and external service providers
where there are assets and configuration items to be
controlled, e.g. shared assets
5.6.5 Transition Planning
and Support Process
Transition planning and support process is responsible
for planning all service transition processes and coordinating
the resources that they require.
A) Purpose of Transition Planning and Support Process
Plan and coordinate the resources to ensure
that the requirements of Service Strategy encoded
in Service Design are effectively realized in Service
Operations.
Identify, manage and control the risks of failure
and disruption across transition activities.
B) Objectives of Transition Planning and Support
Process
Plan and coordinate the resources to establish
successfully a new or changed service into production
within the predicted cost, quality and time estimates.
Ensure that all parties adopt the common framework
of standard re-usable processes and supporting systems
in order to improve the effectiveness and efficiency
of the integrated planning and coordination activities.
Provide clear and comprehensive plans that enable
the customer and business change projects to align
their activities with the Service Transition plans.
C) Scope of Transition Planning and Support Process
Maintaining policies, standards and models for
service transition activities and processes.
Guiding each major change or new service through
all service transition processes.
Coordinating efforts to enable multiple transitions
to be managed at the same time.
Prioritizing conflicting requirements for service
transition resources.
Planning budget and resources to fulfill future
requirements for service transition.
Reviewing and improving performance of transition
planning and support activities.
Ensuring that service transition is coordinated
with program and project management, service design
and service development activities.
6. Service Operation
6.1 Purpose of Service
Operation
The purpose of Service Operation is to coordinate
and carry out the activities and processes required
to deliver and manage services at agreed levels to business
users and customers. Service Operation is also responsible
for the ongoing management of the technology that is
used to deliver and support services.
6.2 Objectives of
Service Operation
1) Maintain business satisfaction and confidence
in IT through effective and efficient delivery and support
of agreed IT services.
2) Minimize the impact of service outages on day-to-day
business activities.
3) Ensure that access to agreed IT services is only
provided to those authorized to receive those services.
6.3 Scope of Service
Operation
1) The services themselves - activities that form
part of a service is included in service operation,
whether it is performed by the service provider, an
external supplier or the user or customer of that service.
2) Service management processes - the ongoing management
and execution of the many service management processes
that are performed in service operation.
3) Technology - the management of the infrastructure
used to deliver services
4) People - regardless of what services, processes
and technology are managed, they are all about people.
It is people who drive the demand for the organization's
services and products and it is people who decide how
this will be done.
6.4 Value to Business
1) Ensuring that services are operated within expected
performance parameters
2) Restoring services quickly in the event of service
interruption.
3) Minimizing impact to the business in the event
of service interruption.
4) Providing a focal point for communication between
users and the Service Provider organization
6.5 Processes
6.5.1 Incident Management
Process
An incident is defined as an unplanned interruption
to an IT service, a reduction in the quality of an IT
service, or a failure of a CI (configuration item) that
has not yet impacted an IT service.
Incident Management is responsible for progress of
all incidents from reporting to closing - usually the
responsibility of service desk.
A) Purpose of Incident Management Process
The purpose of Incident Management is to recover
normal (i.e. agreed) service operation, as quickly as
possible, after an incident has been detected / recorded.
B) Objectives of Incident Management Process
Make sure that standardized procedures and methods
are used for prompt and efficient response, documentation,
analysis, reporting of incidents and ongoing management
Communication and visibility of incidents should
be improved.
Improve business perception of IT with the help
of a professional approach so that incidents will
be resolved and reported quickly.
Align incident management activities and priorities
with those of the business.
Maintain the user satisfaction without losing
the quality of IT services.
C) Scope of Incident Management Process
Handle all incidents (event which disrupts, or which
could disrupt, a service), either by service desk reports
or event management tool alerts. Incidents are reported
and/or logged by technical staff.
D) Basic Concepts
Incident: An incident is defined as an unplanned
interruption to an IT service, a reduction in the
quality of an IT service, or a failure of a CI (configuration
item) that has not yet impacted an IT service.
Timescales: Timescales must be agreed for all
incident handling according to their priority; this
includes response and resolution targets. All support
groups should be made fully aware of these timescales.
The tool should be used to automate timescales and
escalate the incident as required based on predefined
rules.
Incident Model: An incident model is a template
that can be reused for recurrent incidents. It can
be practical to predefine 'standard' incident models
and apply them when incidents occur. They contribute
to a faster entry and a more efficient treatment.
Major Incident: define what constitutes a major
incident and follow pre-defined procedures, need
to inform users on the progress.
Incident Status Tracking.
Incident status tracking field value examples:
1) New - an incident is submitted but is not assigned
to a group or resource for resolution.
2) Assigned - an incident is assigned to a group
or resource for resolution.
3) In process - the incident is in the process of
being investigated for resolution.
4) Resolved - a resolution has been put in place.
5) Closed - the user has agreed that the incident
has been resolved and that normal state operations have
been restored
6) Expanded Incident Life cycle: Detailed stages
in the lifecycle of an incident. The stages are detection,
diagnosis, repair, recovery and restoration. The expanded
incident lifecycle is used to help understand all contributions
to the impact of incidents and to plan for how these
could be controlled or reduced.
7) Impact: A measure of the effect of an incident,
problem, or change on business processes. Impact is
often based on how service levels will be affected.
Impact and urgency are used to assign priority
8) Urgency - a measure of how long it will be until
an incident, problem or change has a significant impact
on the business.
9) Priority - a category used to identify the relative
importance of an incident, problem or change, based
on impact and urgency. High priority (Priority 1) is
given for an incident with high impact and high urgency.
E) Incident Management Process Activities
Lifecycle of Incidents are as follows:
1) Incident Identification - realize an incident
before the user notices / reports with event management
(a reactive process)
2) Incident Logging - log ALL incidents for service-level
management reporting and problem management. Information
may include:
unique reference number
incident category
impact, urgency and priority
steps to resolution and known errors
time from logging to closure
Activities undertaken to resolve the incident
and when these took place.
Resolution date and time
Closure category, date and time
3) Incident Categorization - use a simple categorization
for effective implementation
4) Incident Prioritization - consider business impact
and urgency, to be completed in a pre-agreed time depending
on the priority, may change during the lifecycle
5) Initial Diagnosis - the service desk to diagnose
the fault and try to resolve it with the known error
database (by problem management), incident models or
other tools (incident matching)
6) Incident Escalation - the incidents are owned
by service desk (need to track till closure).
Functional escalation - service desk unable
to solve the incident within a given time.
hierarchic escalation - inform management of
major incidents / incidents not progressing based
on SLA target time
7) Investigation and Diagnosis - try to find out
what has happened and how to resolve
8) Resolution and Recovery - test potential resolutions
to ensure the incident has been solved without causing
adverse consequences
9) Incident Closure - contact user to verify and
review categorization, finish documentation. Closed
incidents may be re-opened if the incident re-surfaces
again. Any appropriate function can close the incident.
Figure: Lifecycle of Incidents
F) Incident Management Process- Interfaces with other
stages of ITIL Service Lifecycle.
1) Interfaces with Service Design
Service Level Management: The ability to resolve
incidents in a specified time is a key part of delivering
an agreed level of service.
Information Security Management: Providing security-related
incident information as needed to support service
design activities and gain a full picture of the
effectiveness of the security measures as a whole
based on an insight into all security incidents.
Capacity Management: Incident management provides
a trigger for performance monitoring where there
appears to be a performance problem.
Availability Management: Availability management
will use incident management data to determine the
availability of IT services and look at where the
incident lifecycle can be improved.
2) Interfaces with Service Transition:
a) Service asset and configuration management:
Provides data used to identify and progress
incidents and to assess the impact of an incident;
also contains information on which categories of
incident to assign to which support group.
In turn, incident management can maintain the
status of faulty CIs. It can also assist service
asset and configuration management to audit the
infrastructure when working to resolve an incident.
b) Change Management:
Where a change is needed to implement a workaround
or resolution, it will be logged as an RFC and progressed
through change management.
In turn, incident management is able to detect
and resolve incidents that arise from failed changes.
3) Interfaces with Service Operation:
a) Problem management:
For some incidents, it will be appropriate for
problem management to investigate and resolve the
underlying cause to prevent or reduce the impact
of recurrence.
Incident management provides reporting point
for these.
Problem management can provide known errors
for faster incident resolution through workarounds
to restore service.
b) Access management:
Incidents should be raised when unauthorized
access attempts and security breaches have been
detected
A history of incidents should also be maintained
to support forensic investigation activities, resolution
of access breaches.