- Service Strategy
- Process Objective: To decide on a strategy to serve customers. Starting from an assessment of customer needs and the market place, the Service Strategy process determines which services the IT organization is to offer and what capabilities need to be developed. Its ultimate goal is to make the IT organization think and act in a strategic manner.
- Service Design
- Process Objective: To design new IT services. The scope of the process includes the design of new services, as well as changes and improvements to existing ones.
- Service Transition
- Process Objective: To build and deploy IT services. Service Transition also makes sure that changes to services and Service Management processes are carried out in a coordinated way.
- Service Operation
- Process Objective: To make sure that IT services are delivered effectively and efficiently. The Service Operation process includes fulfilling user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks.
- Continual Service Improvement – CSI
- Process Objective: To use methods from quality management in order to learn from past successes and failures. The Continual Service Improvement process aims to continually improve the effectiveness and efficiency of IT processes and services, in line with the concept of continual improvement adopted in ISO 20000.
ITIL in System Center
- Change Control
The procedures to ensure that all changes are controlled, including the submission, recording, analysis, decision making, and approval of the change. Within information technology (IT), change control is a component of change management.
Certain experts describe change control as a set of six steps:
- Record / Classify
- Build / Test
- Close / Gain Acceptance
- Change Management
The Service Management process responsible for controlling and managing requests to effect changes to the IT Infrastructure, or any aspect of IT services, to promote business benefit while minimizing the risk of disruption to services.
One can infer from these definitions that change control is a process that is largely internal to the IT department and focused on prioritizing and approving infrastructure changes based exclusively on their technical merit and technical impact. IT technicians, for whom change is a constant, almost daily occurrence, often see formalized change control as an administrative burden restricting their ability to react quickly to the rapid pace of change in an increasingly complex business/technology environment. For the great majority of changes–routine changes with no great impact on users or the business (e.g., moving an application from one server to another because of a conflict, etc.), the change control protocol seems a pointless formality that stands in the way of getting the actual work done. After all, everyone in IT probably already knows through informal communications what has to be done and why and in what timeframe, so the approval process functions as little more than a bureaucratic exercise, and is often ignored or only receives minimal compliance.
The problem is that changes to the infrastructure are not always routine and light in terms of impact to the infrastructure and to the organization both inside and outside of IT. It is in these cases that simple change control does not have the appropriate depth of process or organizational reach to handle the complex change events it is charged with regulating. On top of this, the weak compliance that the process receives for low impact changes is often little better for changes with a significant organizational impact. The results—poor decisions are made to go forward or deny changes, business impacts to areas of the business are not considered, changes are badly prioritized and implementations of changes are disruptive. In essence, many organizations with IT-focused change control process regimens have too much process for many simple changes and not enough process for the major changes that really matter.
Operations Deparments must realize that infrastructure changes need be managed not simply controlled. In fact, change control is an important but subordinate procedural component of a robust change management process. The additional significant components, the “secret sauce” of change management that makes it effective are procedures that emphasize assessing the business impact and ramifications of a change and the communication and coordination activities involved in evaluating, approving and implementing a change.
The broader goal of change management is to ensure that the service risk and business impact of each change is communicated to all impacted and implicated parties, and to coordinate the implementation of approved changes in accordance with current organizational best practices. The result of effective change management is that changes are handled quickly in a uniform way and have the lowest possible impact on service quality.
Release management is a software engineering process intended to oversee the development, testing, deployment and support of software releases. The practice of release management combines the general business emphasis of traditional project management with a detailed technical knowledge of the systems development lifecycle (SDLC) and IT Infrastructure Library (ITIL) practices.
Release management usually begins in the development cycle with requests for changes or new features. If the request is approved, the new release is planned and designed. The new design enters the testing or quality assurance phase, in which the release is built, reviewed, tested and tweaked until it is ultimately accepted as a release candidate. The release then enters the deployment phase, where it is implemented and made available. Once deployed, the release enters a support phase, where bug reports and other issues are collected; this leads to new requests for changes, and the cycle starts all over again.
Organizations that have adopted agile software development are seeing much higher quantities of releases. More software releases have led to increased reliance on release management teams to track and execute complex application release processes. Operations teams have used methodologies—such as Information Technology Infrastructure Library ITIL 2011 Book: Service Transition (which contains a section on release management) to improve their release management capabilities as they relate to both business applications and internal IT services. Agile methodologies has also driven development and operations teams to collaborate more closely during production release events—this trend is referred to as DevOps.
Release management software allows release teams to plan, manage and control the release schedule and track the status of each release to ensure production worthiness. It also provides the added benefit of applying central governance and auditing over releases before decision-makers approve releases to production.
Incident Management (IcM)
Incident management (IcM) is an area of IT Service Management (ITSM) that involves returning service to normal as quickly as possible after an incident, in a way that has little to no negative impact on the business. In practice, incident managment often relies upon temporary workarounds to ensure services are up and running while the incident is investigated, the root problem identified and a permanent fix put in place.
In this context, an incident is an event that disrupts normal operation. A problem is an underlying issue that could lead to an incident; problem management consists of the measures taken to prevent that occurence.
Activities of IcM defined by ITIL v3:
- Identification – detect or reported the incident
- Registration – the incident is registered in an ICM System
- Categorization – the incident is categorized by priority, SLA etc. attributes defined above
- Prioritization – the incident is prioritized for better utilization of the resources and the Support Staff time
- Diagnosis – reveal the full symptom of the incident
- Escalation – should the Support Staff need support from other organizational units
- Investigation and diagnosis – if no existing solution from the past could be found the incident is investigated and root cause found
- Resolution and recovery – once the solution is found the incident is resolved
- Incident closure – the registry entry of the incident in the ICM System is closed by providing the end-status of the incident
ISO/IEC 20000 was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework.
Service Request Fulfillment
Needs to be proven – it has been performed successfully before and has been reviewed and approved via Change Management