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.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
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.
Disclaimer: examguides.com is neither associated nor affiliated with AXELOS Limited® or any other company. ITIL is trademarks of AXELOS Limited® and duly acknowledged. The Exam Cram notes material is a copyright of examguides.com and the same is not approved or endorsed by respective certifying bodies.