1. Release Management
1.1. Definition - Release
1.1.1. A version of a service or other configuration item, or a collection of configuration items, that is made available for use.
1.2. Purpose
1.2.1. The purpose of the release management practice is to make
1.2.2. new and changed services and features available for use.
1.3. Release Management in different environments
1.3.1. Release management in a traditional/waterfall environment
1.3.2. Release management in an Agile/DevOps environment
2. Change Enablement/ Change Control
2.1. Definition - Change
2.1.1. The addition, modification, or removal of anything that could have a direct or indirect effect on services
2.2. Purpose
2.2.1. To maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.
2.3. Scope
2.3.1. Change enablement must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effect of changes.
2.3.2. The scope of change control is defined by each organization. It will typically include all IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service.
2.3.3. It is important to distinguish change control from organizational change management!
2.3.4. Organizational change management: manages the people aspects of changes to ensure that improvements and organizational transformation initiatives are implemented successfully.
2.3.5. Change enablement: is usually focused on changes in products and services.
2.4. Types of Change
2.4.1. Standard
2.4.1.1. Low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization.
2.4.2. Normal
2.4.2.1. Changes that need to be scheduled, assessed, and authorized following a standard process. Change models based on the type of change determine the roles for assessment and authorization. Initiation of a normal change is triggered by the creation of a change request.
2.4.3. Emergency
2.4.3.1. Changes that must be implemented as soon as possible. Emergency changes are not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly.
2.5. Change Authority
2.5.1. All changes should be assessed by people who are able to understand the risks and the expected benefits; the changes must then be authorized before they are deployed.
2.5.2. The person or group who authorizes a change is known as a change authority.
2.5.3. It is essential that the correct change authority is assigned to each type of change to ensure that change enablement is both efficient and effective.
2.6. Change Schedule
2.6.1. The change schedule is used to help plan changes, assist in communication, avoid conflicts, and assign resources. It can also be used after changes have been deployed to provide information needed for incident management, problem management, and improvement planning.
3. Problem Management
3.1. Many problem management activities rely on the knowledge and experience of staff, rather than on following detailed procedures. People responsible for diagnosing problems often need the ability to understand complex systems, and to think about how different failures might have occurred.
3.2. Definitions
3.2.1. Definition • Problem
3.2.1.1. A cause, or potential cause, of one or more incidents.
3.2.2. Definition • Workaround
3.2.2.1. A solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Some workarounds reduce the likelihood of incidents.
3.2.3. Definition • Known error
3.2.3.1. A problem that has been analysed but has not been resolved.
3.3. Purpose
3.3.1. To reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors
3.4. Problems vs Incidents
3.4.1. Incidents have an impact on users or business processes, and must be resolved so that normal business activity can take place.
3.4.2. Problems are the causes of incidents. They require investigation and analysis to identify the causes, develop workarounds, and recommend longer-term resolution. This reduces the number and impact of future incidents.
3.5. Problem Phases
3.5.1. Problem Identification
3.5.1.1. Problem identification activities identify and log problems. These include:
3.5.1.2. performing trend analysis of incident records
3.5.1.3. detection of duplicate and recurring issues by users, service desk, and technical support staff
3.5.1.4. during major incident management, identifying a risk that an incident could recur
3.5.1.5. analyzing information received from suppliers and partners
3.5.1.6. analyzing information received from internal software developers, test teams, and project teams.
3.5.1.7. Other sources of information can also lead to problems being identified.
3.5.2. Problem Control
3.5.2.1. Problem analysis: - Problems are prioritized for analysis based on the risk that they pose, and are managed as risks based on their potential impact and probability. - It is not essential to analyze every problem; it is more valuable to make significant progress on the highest-priority problems than to investigate every minor problem that the organization is aware of.
3.5.2.2. Documenting workarounds
3.5.2.2.1. When a problem cannot be resolved quickly, it is often useful to find and document a workaround for future incidents, based on an understanding of the problem
3.5.2.2.2. An effective incident workaround can become a permanent way of dealing with some problems when resolving the problem is not viable or cost-effective.
3.5.2.3. Documenting known errors.
3.5.3. Error Control
3.5.3.1. managing known errors, which are problems where initial analysis has been completed;
3.5.3.1.1. it usually means that faulty components have been identified.
3.5.3.2. identification of potential permanent solutions which may
3.5.3.2.1. result in a change request for implementation of a solution • but only if this can be justified in terms of cost, risks, and benefits.
3.5.3.3. regularly re-assessing the status of known errors that have not been resolved, including overall impact on customers, availability and cost of permanent resolutions, and effectiveness of workarounds.
3.5.3.3.1. The effectiveness of workarounds should be evaluated each time a workaround is used, as the workaround may be improved based on the assessment.
3.6. Interface with other practices
3.6.1. Examples of interfaces between problem management, risk management, change control, knowledge management, and continual improvement are as follows:
3.6.1.1. Problem management activities can be organized as a specific case of risk management
3.6.1.2. Implementation of problem resolution is often outside the scope of problem management
3.6.1.3. Output from the problem management practice includes information and documentation concerning workarounds and known errors
3.6.1.4. Problem management activities can identify improvement opportunities in all four dimensions
4. Service Request Management
4.1. Definition • Service request
4.1.1. A request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery
4.2. Purpose
4.2.1. To support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner.
4.3. Different kind of service requests
4.3.1. Each service request may include one or more of the following:
4.3.1.1. a request for a service delivery action
4.3.1.1.1. e.g., providing a report or replacing a toner cartridge
4.3.1.2. a request for information
4.3.1.2.1. e.g., how to create a document or what the hours of the office are
4.3.1.3. a request for provision of a resource or service
4.3.1.3.1. e.g., providing a phone or laptop to a user, or providing a virtual server for a development team
4.3.1.4. a request for access to a resource or service
4.3.1.4.1. e.g., providing access to a file or folder
4.3.1.5. feedback, compliments, and complaints
4.3.1.5.1. e.g., complaints about a new interface or compliments to a support team
4.4. Service request fulfilment
4.4.1. Fulfilment of service requests may include changes to services or their components; usually these are standard changes.
4.4.2. Service requests are a normal part of service delivery and are not a failure or degradation of service, which are handled as incidents.
4.4.3. Service requests should be pre-defined and pre-agreed
4.4.3.1. they can usually be formalized, with a clear, standard procedure for initiation, approval, fulfilment, and management.
4.4.4. The steps to fulfil the request should be well-known and proven allowing the service provider to agree times for fulfilment and provide clear communication to the users. Service requests may:
4.4.4.1. have very simple workflows, such as a request for information
4.4.4.2. be quite complex and require contributions from many teams and systems for fulfilment, e.g., the setup of new employee
4.4.4.3. be completely fulfilled by automation from submission to closure, allowing for a complete self-service experience e.g., client software installation or provision of virtual servers
4.5. Service request authorization
4.5.1. Some service requests require authorization according to financial, information security, or other policies, while others may not need any. To be handled successfully, service request management should follow these guidelines:
4.5.1.1. Service requests and their fulfilment should be standardized and automated to the greatest degree possible.
4.5.1.2. Policies should be established regarding what service requests will be fulfilled with limited or even no additional approvals so that fulfilment can be streamlined.
4.5.1.3. The expectations of users regarding fulfilment times should be clearly set, based on what the organization can realistically deliver.
4.5.1.4. Opportunities for improvement should be identified and implemented to produce faster fulfilment times and take advantage of automation.
4.5.1.5. Policies and workflows should be included for the documenting and redirecting of any requests that are submitted as service requests, but which should actually be managed as incidents or changes.
5. Monitoring and Event Management
5.1. Definition - Event
5.1.1. Any change of state that has significance for the management of a service or other configuration item (CI). Events are typically recognized through notifications created by an IT service, CI, or monitoring tool.
5.2. Purpose
5.2.1. To systematically observe services and service components, and record and report selected changes of state identified as events. This practice identifies and prioritizes infrastructure, services, business processes, and information security events, and establishes the appropriate response to those events, including responding to conditions that could lead to potential faults or incidents.
6. IT Asset Management
6.1. Definition - IT Asset
6.1.1. Any financially valuable component that can contribute to the delivery of an IT product or service.
6.2. Purpose
6.2.1. To plan and manage the full lifecycle of all IT assets, to help the organization:
6.2.2. maximize value
6.2.3. control costs
6.2.4. manage risks
6.2.5. support decision-making about purchase, re-use, and retirement of assets
6.2.6. meet regulatory and contractual requirements.
7. Service Configuration Management
7.1. Definition • Configuration item
7.1.1. Any component that needs to be managed in order to deliver an IT service.
7.2. Purpose
7.2.1. To ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed. This includes information on how CIs are configured and the relationships between them.
8. Incident Management
8.1. Definition - Incident
8.1.1. An unplanned interruption to a service or reduction in the quality of a service.
8.2. Purpose
8.2.1. To minimize the negative impact of incidents by restoring normal service operation as quickly as possible.
8.3. Incident management process
8.3.1. Formal Process for Logging
8.3.1.1. There should be a formal process for logging and managing incidents.
8.3.1.2. This process does not usually include detailed procedures for how to diagnose, investigate, and resolve incidents, but can provide techniques for making investigation and diagnosis more efficient.
8.3.1.3. There may be scripts for collecting information from users during initial contact, and this may lead directly to diagnosis and resolution of simple incidents.
8.3.1.4. Investigation of more complicated incidents often requires knowledge and expertise, rather than procedural steps.
8.3.1.5. There are usually separate processes for managing major incidents, and for managing information security incidents.
8.3.2. Incident management Practice Design
8.3.2.1. Organizations should design their incident management practice to provide
8.3.2.2. appropriate management and resource allocation to different types of incident.
8.3.2.3. Incidents with a low impact must be managed efficiently to ensure that they do not consume too many resources.
8.3.2.4. Incidents with a larger impact may require more resources and more complex management.
8.4. Who can resolve Incidents?
8.4.1. Incidents may be diagnosed and resolved by people in many different groups, depending on the complexity of the issue or the incident type:
8.4.1.1. Some incidents will be resolved by the users themselves, using self-help. • Use of specific self-help records should be captured for use in measurement and improvement activities.
8.4.1.2. Some incidents will be resolved by the service desk.
8.4.1.3. More complex incidents will usually be escalated to a support team for resolution. • Typically, the routing is based on the incident category, which should help to identify the correct team.
8.4.1.4. Incidents can be escalated to suppliers or partners, who offer support for the products and services they supply.
8.4.1.5. The most complex incidents, and all major incidents, often require a temporary team to work together to identify the resolution. • This team may include representatives of many stakeholders, including the service provider, suppliers, users, etc.
8.4.1.6. In some extreme cases, disaster recovery plans may be invoked to resolve an incident.
8.5. It Service Management tool
8.5.1. Information about incidents should be stored in incident records in a suitable tool.
8.5.2. It is important that people working on an incident provide good-quality updates in a timely fashion.
8.6. Impact on Business
8.6.1. Incident management can have an enormous impact on customer and user satisfaction, and on how customers and users perceive the service provider.
8.6.2. Every incident should be logged and managed to ensure that it is resolved in a time that meets the expectations of the customer and user.
8.6.3. Target resolution times are agreed, documented, and communicated to ensure that expectations are realistic.
8.6.4. Incidents are prioritized based on an agreed classification to ensure that incidents with the highest business impact are resolved first.
9. Service Desk
9.1. Purpose
9.1.1. To capture demand for incident resolution and service requests. It should also be the entry point and single point of contact for the service provider with all its users.
9.2. Value
9.2.1. Provides a clear path for users to report issues, queries, and requests, and have them acknowledged, classified, owned, and actioned.
9.2.2. With increased automation and the gradual removal of technical debt, the focus of the service desk is to provide support for ‘people and business’ rather than simply technical issues.
9.2.3. No matter how efficient the service desk and its people are, there will always be issues that need escalation and underpinning support from other teams.
9.2.4. It plays a vital role in the delivery of services, and must be actively supported by its peer groups. It is also essential to understand that the service desk ‘ has a major influence on user experience and how the service provider is perceived by the users.
9.2.5. Add value not simply through the transactional acts, i.e., incident logging, but also, by understanding and acting on the business context of this action.
9.3. Channels
9.3.1. phone calls, which can include specialized technology, such as interactive voice response (IVR), conference calls, voice recognition, and others
9.3.2. service portals and mobile applications, supported by service and request catalogues, and knowledge bases
9.3.3. chat, through live chat and chatbots
9.3.4. email for logging and updating, and for follow-up surveys and confirmations.
9.3.5. walk-in service desks
9.3.6. text and social media messaging
9.3.7. public and corporate social media and discussion forums for contacting the service provider and for peer-to-peer support.
9.3.8. With increased automation, AI, and chatbots, etc. service desks are moving to provide more self-service logging and resolution. This reduces phone contact and minimize low-level work enabling the service desk to focus on excellent CX when personal contact is needed.
9.4. Structures
9.4.1. The service desk could be:
9.4.1.1. centralized e.g., a tangible team, working in a single location or
9.4.1.2. virtualized allowing agents to work from multiple locations, geographically dispersed
9.4.2. A virtualized service desk requires a more sophisticated supporting technology, involving more complex routing and escalation
9.4.3. The service desk should be the empathetic and informed link between the service provider and its users.
9.5. Staff
9.5.1. Service desk staff require training and competency across a number of broad technical and business areas. In particular they need to demonstrate:
9.5.1.1. excellent customer service skills such as empathy,
9.5.1.2. incident analysis and prioritization,
9.5.1.3. effective communication, and
9.5.1.4. emotional intelligence.
9.5.2. The key skills for service desk staff
9.5.2.1. To be able to fully understand and diagnose a specific incident in terms of business priority, and to take appropriate action to get this resolved, using available skills, knowledge, people, and processes.
10. Service Level Management
10.1. Definition • Service level agreement (SLA)
10.1.1. A documented agreement between a service provider and a customer that identifies, both services required and the expected level of service.
10.2. Purpose
10.2.1. To set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored, and managed against these targets
10.3. Activities
10.3.1. This practice involves the definition, documentation, and active management of service levels.
10.3.1.1. Service level management provides the end-to-end visibility of the organization’s services. To achieve this, service level management:
10.3.1.1.1. establishes a shared view of the services and target service levels with customers
10.3.1.1.2. ensures the organization meets the defined service levels through the collection, analysis, storage, and reporting of the relevant metrics for the identified services
10.3.1.1.3. performs service reviews to ensure that the current set of services continue to meet the needs of the organization and its customers
10.3.1.1.4. captures and reports on service issues, including performance against defined service levels
10.4. Skillset needed for SLM
10.4.1. This practice involves the definition, documentation, and active management of service levels.
10.4.1.1. The skills and competencies for service level management include:
10.4.1.2. relationship management,
10.4.1.3. business liaison,
10.4.1.4. business analysis,
10.4.1.5. and commercial/supplier management.
10.4.2. The practice requires pragmatic focus overall service and not simply on its constituent parts. Simple individual metrics (such as percentage of system availability) should not be taken to represent the whole service
10.5. Sources of information
10.5.1. Service level management involves collating and analyzing information from a number of sources, including:
10.5.1.1. Customer engagement
10.5.1.1.1. • This involves initial listening, discovery, and information capture on which to base metrics, measurement, and ongoing progress discussions.
10.5.1.2. Customer feedback, ideally gathered from a number of sources, both formal and informal, including:
10.5.1.2.1. • Surveys
10.5.1.2.2. • Key business-related measures which are measures agreed between the service provider and its customer, based on what the customer values as important.
10.5.1.3. Operational metrics
10.5.1.3.1. • Low-level indicators of various operational activities and may include system availability, incident response and fix times, change and request processing times, and system response times.
10.5.1.4. Business metrics
10.5.1.4.1. • Can be any business activity that is deemed useful or valuable by the customer and used as a means of gauging the success of the service.
10.6. Key requirements for SLAs
10.6.1. They must be related to a defined ‘service’ in the service catalogue
10.6.1.1. Otherwise, they are simply individual metrics without a purpose, that do not provide adequate visibility or reflect the service perspective
10.6.2. They should relate to defined outcomes and not simply operational metrics
10.6.2.1. This can be achieved with balanced bundles of metrics, such as customer satisfaction and key business outcomes
10.6.3. They should reflect an ‘agreement’, i.e., engagement and discussion
10.6.3.1. between the service provider and the service consumer
10.6.3.1.1. It’s important to involve all stakeholders, including partners, sponsors, users, and customers
10.6.4. They must be simply written and easy to understand and use for all parties
10.6.5. They should not use a single-system-based metrics
10.6.5.1. as targets can result in misalignment and a disconnect between service partners regarding the success of the service delivery and the user experience.