The term IT Service Management (ITSM) is used in different ways by a variety of different IT-enabled organisations that are looking to increase and improve the level of IT governance and maturity.
Although different organisations have mildly different interpretations of ITSM, the official definition – as provided by ITIL – is “a set of specialised organisational capabilities for providing value to customers in the form of services”.
Within each different interpretation of ITSM, the following elements are usually included:
- A relatively comprehensive description of the processes needed to both deliver and support IT services for end users and customers.
- The development of the ability to deliver and support the technology or products needed by the organisation to meet specific key goals or objectives.
- The definition of roles and responsibilities for the people involved. These may include general IT stakeholders, IT support staff and customers.
- The management of external suppliers (partners) who are involved in the delivery and support of the technology and products within the overall IT mix.
The combination of the above elements provide the capabilities need by an IT-enabled organisation to deliver and support IT Services that have been defined by the organisation’s unique business needs and requirements.
The Four Attributes of ITSM within ITIL
In order to explain the concept of ITSM, four perspectives (“4Ps”) are used:
- Partners / Suppliers Perspective: taking partners and external suppliers into account when defining how Service Delivery is performed.
- People Perspective: whether the human resources focussed on Service Delivery (i.e. IT staff, stakeholders and customers) have the necessary knowledge and skills to perform their necessary functions.
- Products / Technology Perspective: taking hardware, software, tolls, budgets and general IT services into account.
- Process Perspective: the complete, full spectrum delivery of services based on the flow of defined processes.
In order to maximise the overall quality of ITSM and its continual improvement, all of the four perspectives need to be taken into account. The same should be said when new or modified Services are being defined.
The Benefits of ITSM
Typical benefits of ITSM can include:
- Improved quality service provision.
- Service quality that is cost-justified.
- Services that accurately meet business, end-user and customer needs and requirements.
- Well defined processes that are centralised and integrated.
- A complete understanding of individual roles and responsibilities within service provision.
- The ability to manage the knowledge gained (i.e. learn) from previous delivery and support experience.
- Comprehensive and useful performance indicators.
A major aspect of ITSM is making sure that the aforementioned benefits are aligned to the overall needs and requirements of the relevant stakeholders such as end-users, IT staff, suppliers, customers, senior management and business unit managers.
In terms of the overall alignment between business and IT, it is important that stakeholders do not lose sight of the actual benefits and purposes that their efforts can deliver to the business. This may happen when stakeholders have a purely internal focus on the technology being implemented and supported.
In order to prevent this from happening, it is useful to highlight the way an organisation is divided into supporting layers that all work towards meeting the organisational goals:
- Organisation: what are the key goals and objectives of the organisation?
- Core Business Processes: the processes that enable the key goals and objectives to be met.
- IT Service Organisation: the identification of IT Services that are needed to enable the required execution of the Core Business Processes.
- IT Service Management: the ITIL processes required for the delivery and support of the IT Services to a pre-determined quality standard.
- IT Technical Activities: the actual technical activities conducted by stakeholders that are required as part of the execution of the aforementioned ITIL processes.
What is ITIL?
The Information Technology Infrastructure Library (ITIL) is an international IT management framework describing a set of “good practices” for IT Service Management (ITSM). It should be noted that there are other sources of best practices, i.e. those practices formally documented as being successful in industry-wide use. These include:
- Public frameworks (COBIT, CMMI, etc)
- Standards (ISO 2000, BS 15000)
- Proprietary knowledge of different organisations and individuals.
The iteration of ITIL:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement
Now that you hopefully have a good idea of what ITIL and ITSM is all about, the next phase of your studies should be gaining a good understanding of the common ITIL terminology used to describe many of the concepts contained within ITSM and ITIL. You should do this before you started learning about the five distinct ITIL phases listed above.
ITIL Common Terminology
In order to make sure that all stakeholders are able to understand, participate with and fully apply the ITIL framework concept, it is vital to develop a common ITIL “language” that everyone involved is able to speak. For the purposes of the exam, it is vital that you recognise the terminology used and understand its correct meaning.
- IT Service Management: A collection of specialised organisational capabilities developed to provide value to customers.
- Capabilities: the specific ability of a person, process, organisation, application, IT service or configuration item (CI) to undertake a specific activity. This can include the functions and processes used to manage services, and can also include other assets which cannot be bought but can be developed and matured within the organisation over time. These capabilities are geared towards enabling the efficient and effective delivery of services.
- Resources: a generic term that includes practically all tangible elements required to deliver a service. This can include staff, budgets, tools, infrastructure or anything else.
- Process: A collection of activities which are coordinated in order to combine and implement resources so that an outcome that provides value to the customer is produced. Processes can be considered strategic assets when they create market differentiation or competitive advantage (relative to the rest of the industry). It is possible for the processes to define roles and responsibilities, policies, guidelines, standards, tools, work instructions and activities.
- Service: A way of delivering value to customers by creating the outcomes that the customers require without the same customers having to accept specific costs or risks.
- Functions: A group of people and the tools they use to undertake one or more Processes or Activities. Functions are used to design and create organisational units that are geared toward specific outcomes. The Functions covered within the ITIL – and the exam – are Service Desk, Technical Management, Application Management and IT Operations Management.
- Process Owner: the individual who is responsible for making sure that a given process is “fit for purpose” and who is accountable for the outputs of the process.
- Service Owner: the individual who is ultimately responsible for the delivery of a specific service and who is also responsible the continual improvement and management of change of Services under their care.
- Process Manager: the individual responsible for the operational management of a specific process. Note that there may be more than one Manager for a specific process, but they will all report to the Process Owner.
- Internal Service Provider: a service provider that exists within a specific business unit but does not extend into other business units.
- Shared Service Providers: an internal service provider that provides common IT-related services to multiple business units.
- External Service Providers: a service provider that provides IT-related
services to external customers. This is common when a particular service
- Business Case: A decision support and planning tool that attempts to clarify the expected consequences of a particular business action and that tries to provide justification for a specific item of expenditure. The business case usually includes information regarding costs, benefits, risks, potential problems, options and other issues.
Official Definition of Services
The official definition of a Service – is “a means of delivering value to Customers by facilitating outcomes customers want to achieve without the ownership of specific costs and/or risks”.
Processes and Functions
Processes can be defined as a structured set of coordinated activities that are designed to produce an outcome to customers or stakeholders that has value. A process takes one or more inputs, gives them to the activities and turns them into specific outputs.
It should be noted that – in order to be effective and useful – all processes should be measurable and performance driven in terms of costs, time, effort and utilised resources.
Processes can be considered strategic assets when they create a level of market differentiation and competitive advantage. They may be used to define roles and responsibilities, policies, guidelines, standards, tools, work instructions and activities.
A process owner is the individual responsible for making sure that a given process is “fit for purpose” and who is accountable for the outputs of the process.
A process manager is the individual responsible for the operational management of a specific process. Note that there may be more than one Manager for a specific process, but they will all report to the Process Owner. In smaller organisations, the process owner and process manager may be the same person.
Functions can be defined as the logical grouping of roles and automated measures that undertake a specific process, activity or both.
The Connection of Processes and Functions
In order to help in the overall definition of roles and responsibilities in a specific process, a RACI Model can be used. This model is used to define and document the roles and responsibilities of the different Functions in relation to Incident Management activities. RACI is the acronym used to denote:
- Responsibility, i.e. who does the actual service activity but reports to the individual who is accountable for the process. There may be more than one person allocated responsibility, especially when there is shared responsibility.
- Accountability, i.e. the individual who is accountable for making sure that the action takes place but does not perform the action themselves. Note that this role implies ownership and only one person can be accountable for the
- Consult, i.e. one or more individuals who can provide advice, information, knowledge and guidance before the action takes place.
- Inform, i.e. the position or function that must be informed after the event has occurred.
ITIL Service Lifecycle
ITIL Service Lifecycle because it attempts to ask both how a particular process should be designed and implemented and why it should be. This question can be defined as:
- How should the stakeholders design for the required levels of capacity, availability and service continuity?
- How can one respond to problems, known errors and incidents?
- Why is this service needed by the customer?
- Why does the customer need this service from us?
- Why should we provide specific levels of capacity, availability and service continuity?
The answers to these questions can greatly increase the ability of the provider to define strategic objectives for the IT-enabled organisation. In turn, this can be used to define how services are accurately designed, easily transitioned, effectively supported and comprehensively improved with the intention of maximising value for the customers and stakeholders.
How the ITIL Service Lifecycle works
The five volumes (or phases) of the ITIL Lifecycle may be distinct but they are not separate and they are not undertaken in a particular order (depending on business requirements). The five phases are designed are designed to affect each other on a cyclical basis, creating a continuous cycle. It should also be noted that the Continuous Service Improvement phase will be part of all the other phases.
The five ITIL phases are:
- Service Strategy Phase, which determines the needs, priorities, demands and comparative importance for desired services. This phase also identifies the overall service value to be created for the customer and the expected financial resources required to design, deliver and support these services.
- Service Design Phase, which designs the infrastructure, processes and support mechanisms required to meet the Availability levels defined by the customer.
- Service Transition Phase, which makes sure that the designed Service meets the overall “fit for purpose” criteria of the customer and is therefore justified for release to the customer.
- Service Operation Phase, which monitors the Availability provided to the customer and which also manages and resolves incidents that adversely affect Service Availability.
- Continual Service Improvement Phase, which coordinates the collection of data, information and knowledge relating to the performance and quality of the supplied services and the Service Management activities that are performed. Note that Service Improvement Plans are developed, implemented and coordinated to improve any and all aspects involved in IT service management.
ITIL Service Strategy
In general, the primary goals of this phase are to:
- Officially define the strategic objectives of the IT-enabled organisation.
- Design, develop and implement service management as a strategic asset that will be used to help the growth of the organisation.
- Develop the organisation’s ability to manage the associated costs and risks associated with their portfolio of services.
Achieving these goals will make sure that the organisation has a clear and concise understanding of how it can support the growth of the business and/or improve efficiencies.
Without the ability to clearly establish the value of a service, it will become difficult to define its overall price, cost and risk. In this respect, it is important to clearly establish its value in terms of price, competitiveness and market differentiation. This can be achieved using the following formula:
Warranty + Utility = Value
Utility describes the beneficial effects of a particular Service on business processes, tasks and activities, i.e. describing how a Service is “fit for purpose”. Two questions need to be answered to ascertain whether a Service is “fit for purpose”:
- Does the Service support the performance of the business?
- Are any business constraints removed by this Service?
If the answer to both questions is YES, then the service can be considered “fit for purpose”.
Warranty describes how well the Service can be delivered to the customer, i.e. describing how it is “fit for use”. In order to ascertain whether or not a Service is “fit for use”, four questions need to be asked:
- Is there sufficient capacity?
- Is there sufficient security?
- Is there enough continuity?
- Is there enough availability?
If the answers to all four questions is YES, then the Service can be considered “fit for use”.
It is important to note that overall Utility should only be delivered if there is enough Warranty.
Service Packages and Service Level Packages
Service Packages and Service Level Packages are commonly used descriptions to show how a particular Service can provide benefits to a customer. They are also used by Service Providers to make sure that they do not develop a single service to be marketed to multiple customers with different requirements.
A Service Package contains a combination of different bundled services that can be delivered to the customer to provide benefits. Service Package contents typically include:
- The Core Service Package, which is the basic services deemed critical to the customer.
- The Supporting Services Package, which is a variety of supporting services designed to attract the customer’s interest.
- The Service Level Package, which defines the levels of Service Utility and Service Warranty provided by the overall Package.
Service Level Packages are used to develop Service Packages with the Utility and Warranty appropriate to the requirements of the customer. Note that this relates – once again – to availability, security, continuity and capacity.
Service Strategy Processes
Within the ITIL Service Strategy lifecycle phase, there are three processes:
- Demand Management
- Service Portfolio Management
- Financial Management
When combined, these processes allow an organisation to maximise the overall value of service that are provided to customers and to generate the necessary information needed to make the correct financial decisions regarding IT investments.
The most important objective of Demand Management is to assist the Service Provider in accurately understanding and effectively influencing the demand for services and the provision of Capacity to meet this demand.
Other objectives include:
- Using specific techniques to influence and manage service demand in order to reduce excess capacity while maintaining customer and business satisfaction with the service.
- Identifying and analysing of Patterns of Business Activity (PBA) that constitute service demand.
Patterns of Business Activity constitute the variations in workload that occur within an IT infrastructure. By analysing and understanding PBA, capacity planning can be improved.
Effective Demand Management will assist in the other phases in the Service Lifecycle:
- Service Design can be improved through more effective Availability Management and Capacity Management.
- Service Transition can be improved by making sure that appropriate levels of Service Warranty are delivered.
- Service Operation can be enhanced by the correct optimisation of staff availability to support varying patterns of demand.
- Continual Service Improvement can be improved by identifying opportunities to consolidate demand or by defining different techniques to influence demand.
There are two ways to implement Demand Management:
- Financial, i.e. using charges levied on customers who approach or exceed capacity quotas. This is generally deemed to be expensive and difficult to implement.
- Physical / Technical, i.e. limit the number of users, connections and times at which applications can be executed.
It is vital that Demand Management works in conjunction with Financial Management, Service Portfolio Management and Service Level Management in order to ensure that Service Packages are developed appropriately and in order to make sure that the consumption of IT-related resources and services are influenced positively.
Service Portfolio Management
The most important objective of Service Portfolio Management is to provide strategic management and direction of IT Service Management investments in order to make sure that the correct combination of services are being maintained effectively.
Other goals can include:
- To maintain the correct information regarding planned, current and retired IT services.
- To improve the ability to support and improve business services and processes.
- To accurately define and identify the value that the IT services provide to the business.
The main emphasis of a Service Portfolio is to outline a provider’s services in such a way that overall business value can be recognised by the customer and can be compared with the business value provided by other providers. The information within the Service Portfolio is normally used to effectively manage the complete lifecycle of all the services provided for one or more customers.
Within the Service Portfolio, Services are categorised in the following manner:
- Service Pipeline, i.e. those services that are currently in development or that have been proposed.
- Service Catalogue, i.e. those services that are currently in operation and are available to the customer.
- Retired Services, i.e. those services that are no longer in operation and are not available to the customer.
Service Portfolio Management is a process that is continuous and changeable. It includes the following methods:
- Define – this method is used to validate the data included within the portfolio and is used to assess the service investments in relation to the possible benefits. It is also used to determine the capabilities and resources that are needed to support these service investments.
- Analyse – this method is used to highlight the overall intent of the strategic investment and to align, prioritise and balance demand and supply.
- Approve – this method is used to finalise any proposed portfolio and to authorise all the resources and services needed to deliver the services involved with the investment.
- Charter – this method is used to plan and monitor the overall progress of the service investment throughout the portfolio, and also to allocate the required resources.
Service Investments fall under three distinct categories:
- Run The Business, i.e. the investments are focussed on service operation maintenance.
- Transform The Business, i.e. the investments are focussed on moving or expanding the business into new market spaces by developing new capabilities.
- Grow The Business, i.e. the investments are focussed on expanding the organisation’s services.
The overall outcome for services that already exist can be categorised thus:
- Renew, i.e. the service is functionally OK but does not meet technical
- Replace, i.e. the service has unclear business functionality.
- Retain, i.e. the service is aligned with – and is relevant to – the overall organisational strategy.
- Refactor, i.e. the service meets technical and functional criteria but can be redeveloped to only include core functionality with other services being used to provide the remaining service(s).
- Retire, i.e. the service no longer meets functional and technical fitness.
- Rationalise, i.e. the service uses multiple versions of the same element (e.g. operating systems).
The sole objective of Financial Management is to provide a defined level of cost-effectiveness in relation to IT assets and to define the financial
resources used to provide those assets. The resources required will be used to assign service costs that can be reasonably assigned to the customer.
There are three basic activities for the successful Financial Management of specific IT services:
- Funding, i.e. predicting the future financial requirements used to continue to deliver and support services and making allowances in future budgets for these services.
- IT Accounting, i.e. enabling the organisation to monitor how the financial resources are being spent and whether or not the spending is effective.
- Chargeback, i.e. optionally charging customers for their use of specific services.
Service Strategy Summary
The ITIL Service Strategy phase allows the organisation to make sure that their objectives are well defined and that specific Services and Service Portfolios are value-maximised. This phase extends into other phases within the ITSM Service Lifecycle.
ITIL Service Design
Service Design phase – is directly connected to the overall design of IT services within an organisation. This includes (but is not exclusive to):
- IT architectures
- Service solutions
- Service Management tools and systems
- Measurement systems
The general driver within this phase is the requirement of an IT-enabled organisation to support dynamic business needs. Each time a new solution is designed and created, this phase makes sure that the new solution will integrate and interface with the services that are currently in existence, i.e. with those listed in the Service Catalogue of the Service Portfolio.
The three main goals of Service Design that provide guidance to the processes are:
- To make sure that quality and functionality become integral aspects of the holistic approach towards an integrated business IT architecture.
- To take the strategic goals outlined in the Service Strategy phase and turn them into relevant Services and Service Portfolios.
- To make sure that the direction, conventions and standards of the design are incorporated into all relevant processes and services in the future.
There are five main aspects of this phase that need to be taken into account in order to guarantee an integrated approach during the design activities:
- Service Portfolio, i.e. identifying the Service Management tools and systems to be used.
- Service Solutions, including the agreed capabilities, requirements and resources that will be required.
- Technology architectures, including the technology-based tools required to provide the relevant service.
- The Processes that are required to design, transition, operate and improve the relevant service.
- The measurement systems which will record the metrics of all the constituent parts of the relevant service.
The major focus of the design of new or changed services is to match relevant business requirements.
Service Design Processes
Within this ITIL phase, there are seven distinct processes. These are:
- Service Level Management
- Capacity Management
- Availability Management
- IT Service Continuity Management
- Information Security Management
- Supplier Management
- Service Catalogue Management
It should be noted that many of the activities from the aforementioned processes will also be incorporated within other lifecycle phases (especially Service Operation), and Service Level Management will play a major part in Continual Service Improvement.
Service Level Management
The main objective of this process is to make sure that current and/or future IT services are maintained and supported at an agreed-upon level. Service Level Management can also be used to identify and instigate improvements in IT services.
During this ITIL phase, Service Level Management will make use of the following agreements and contracts:
- Service Catalogue – a documented statement of available IT services, options, prices and default levels, as well as a list of the customers and/or business processes that use them.
- Service Level Agreement (SLA) – a documented agreement between a service provider and the relevant customer that codifies agreed service levels for a particular Service and that defines key service targets and responsibilities for both parties. Note: all SLAs must be clear, concise and measurable.
- Service Level Requirements – detailed documentation regarding the customer’s requirements and needs. This forms the basis of a new or modified service.
- Operational Level Agreement (OLA) – an internal agreement between two different units of the same organisation to support one unit in the delivery of specific services.
- Underpinning Contract – a contract with an external supplier who supports delivery of an IT service.
The Service Level Management process will be involved in the negotiation and agreement of Service Level Agreements and Operational Level Agreements. The Supplier Management process will be involved in the negotiation and agreement of Underpinning Contracts with external suppliers.
The three types of SLA structures are Customer-based, Service-based and Multi-level (or Hierarchical) SLAs. Many different issues need to be taken into account when deciding which SLA structure is the best fit for a particular organisation.
Typical components of a Multi-level SLA structure:
- Corporate level, e.g. security procedures – such as ID cards and network passwords – throughout an organisation.
- Customer level, e.g. security procedures that are extended in one particular security-sensitive business unit such as finance.
- Service level, e.g. the support of a specific service – such as email systems – throughout an organisation.
A Multi-level SLA structure has the potential to reduce excessive duplication of effort while still allowing the customisation of services for individual customers.
The prime objective of this process is to manage suppliers and their related services, to make sure that value for money is being obtained from the supplier and to work towards guaranteeing a high quality of service to the customer.
Other goals of Supplier Management include:
- Effectively maintaining a policy regarding suppliers.
- Managing overall supplier performance.
- Maintaining a Supplier and Contract Database (SCD).
- Making sure that UCs are closely aligned to business needs.
A Supplier and Contract Database (SCD) should be developed in order to make sure that effectiveness and consistency is maintained for whatever
supplier policy and strategy is developed by the business.
Service Catalogue Management
The main objective of this ITIL process is to make sure that a Service Catalogue – i.e. services that are currently available for deployment or that are live – is created and maintained and that it always contains accurate information.
Other goals of this process include:
- To ensure widespread availability to relevant stakeholders.
- To provide a single source of accurate and consistent information regarding available services.
Once the catalogue is created, it is divided into two parts:
- Business Service Catalogue, which includes pertinent details of all the IT services defined in the context of customers, the relevant relationships with the business units and the process they support. This section should incorporate relatively non-technical information designed to be understood by business stakeholders rather than technical managers.
- Technical Service Catalogue, which includes details of all the IT services delivered and available to the customer, but should also include details regarding shared services, CIs required for service delivery and documentation regarding the relationships between different supporting services. This section should be geared towards technical managers and staff rather than non-technical stakeholders.
The objective of this ITIL process is to ensure the present and future performance and capacity requirements of the customer with respect to IT service provision is provided cost-effectively.
Capacity Management is the process that aims to manage the right capacity level for the right customer at the right location at the right moment at the right costs. It provides a level of ongoing predictive capability that makes aligning resources to demand more effective and accurate.
There are three sub-processes incorporated within Capacity Management:
1. Business Capacity Management
- Identifies how business changes may affect IT performance and capacity.
- Manages capacity in order to align it to future business needs.
- Plans and develops sufficient capacity in a predefined timescale.
- Must be included in Change Management and Project Management.
2. Service Capacity Management
- Manages the ongoing performance of services (as per the SLAs).
- Creates baselines and profiles of service usage.
3. Component Capacity Management
- Identifies and manages all of the individuals components of an IT infrastructure. This can include processors, hard drives, network interface cards and routers.
- Evaluates technologies that may be procured in the future and how they may be implemented to overall business benefit.
All data collected by the three Capacity Management sub-processes are shared with Service Level Management and Financial Management.
Capacity Management essentially consists of the following activities:
- Performance Monitoring, i.e. making sure that the constituent components of the IT infrastructure are measured, monitored and correctly tuned.
- Demand Management, i.e. management of current demand in line with short-term strategies incorporated within Service Strategy.
- Application Sizing, i.e. predicting the expected workload on new or modified applications and calculating the infrastructure capacity required for these applications.
- Modelling, i.e. used to develop a forecast of how an infrastructure will behave under certain conditions.
- Tuning, i.e. small changes made to the infrastructure to allow for more effective utilisation.
- Storage of Capacity Management data.
- Capacity Planning.
The Capacity Manager is responsible for Capacity Management, and his/her roles include:
- Making sure that adequate capacity and performance exists for all IT services within the organisation.
- The development and management of the Capacity Plan.
- Oversee the monitoring of capacity and performance, and notify relevant stakeholders when specific alerts are generated by the infrastructure.
The main objective of this ITIL process is to make sure that service availability levels throughout the IT infrastructure either match or exceed the current or future agreed business requirements with a high degree of cost-effectiveness.
There are two aspects of Availability Management: proactive and reactive.
The proactive aspect involves the planning, design and improvement of IT availability throughout the entire infrastructure and all the services and processes. This is usually conducted within the Service Design phase of the Service Management lifecycle.
The reactive aspect involves the monitoring, measuring, analysis and respective management of all possible events, incidents and problems that may affect availability. This is usually conducted within the Service Operation phase of the Service Management lifecycle.
In order to pass the ITIL Foundation exam, it is important to clearly understand the following key words and phrases:
- Availability: the ability of a IT service – and its constituent components – to perform as required in any given instant or over a specific period of time.
- Security: all aspects of the IT infrastructure should be available to authorised users at authorised times.
- Reliability: freedom from operational failure.
- Resilience: the ability to withstand a variety of different component or service failures.
- Maintainability: the ability of a component to retained in – or restore to – an operational state using the capabilities of IT staff and using one or more ITSM tools. This should be considered internal to the organisation.
- Serviceability: the agreements – underpinned by contracts – with external suppliers that should include the respective service availability obligations. This should be considered external to the organisation.
- Vital Business Function (VBF): the IT-enabled business processes that are considered to be business critical. In general, this function should be expected to absorb a higher-than-average level of investment and effort in order for the process to be maintained and supported.
As Availability Management is related to making sure that the impact and duration of Incidents are minimised, the following metrics should be understood:
- Mean time between failures (MTBF): the average period of time between the recovery from one incident and the occurrence of the following incident. This metric relates to the reliability of a particular service and can also be termed “uptime”.
- Mean time to restore service (MTRS): the average period of time taken to completely restore an IT service or component after a failure. This metric can also be termed as “downtime”.
- Mean Time between System Incidents (MTBSI): the average period of time between two consecutive incidents. The formula of this metric is MTBSI = MTBF + MTRS.
It should be noted that a high MTBF/MTBSI ratio indicates that the infrastructure is experiencing a high number of small faults, while a low MTBF/MTBSI ratio indicates that the infrastructure is experiencing a small number of major faults.
The Availability Manager is responsible for Availability Management, and his/her roles include:
- Making sure that adequate availability of all IT services is provided.
- Overseeing the improvement and monitoring of process availability.
- The development and maintenance of an Availability plan.
It should be noted that the goal of the Availability Manager is to provide reasonable agreed levels of availability and not total availability at all times.
IT Service Continuity Management
The objective of IT Service Continuity Management – also known as Disaster Recovery Planning – is to make sure that the IT service provision and infrastructure required by business can be recovered within an agreed-upon time period.
In order to understand IT Service Continuity Management and pass the ITIL Foundation exam, it is important to understand the meaning of the following key words and phrases:
- Business Continuity Management (BCM): plans and strategies that are enacted in case of a disaster. BCM should be considered an integral part of IT Service Continuity Management.
- Disaster: “downtime” that is not part of daily operational activities and that requires a completely separate system due to its severity.
- Business Impact Analysis (BIA): used to quantify the impact of a major or complete service loss for a business.
- Risk Assessment: an evaluation of the vulnerabilities and threats to an IT infrastructure and its processes.
In order to recover from – and reduce the risk of – an event that effects IT Service Continuity, the following measures could be undertaken:
- Countermeasures: measures used to either prevent or recover from a disaster.
- Manual workaround: using solutions that are not IT-related to overcome the disruption to services.
- Gradual recovery: taking more than three days to recover from a disaster (also known as a cold standby).
- Intermediate recovery: taking between one and two days to recover from a disaster (also known as a warm standby).
- Immediate recovery: taking less than 24 hours (usually one to two hours) to recover from a disaster (also known as a hot standby).
- Reciprocal arrangement: an agreement with another company with similar requirements to share the cost and effort of disaster recovery measures.
Information Security Management
The objective of Information Security Management is to closely align IT security with overall business security and to make sure that information security is managed throughout all ITSM activities.
Information Security Management is responsible for maintaining the availability, confidentiality and integrity of all assets, data, information and IT-related services. Information Security Management must take the following perspectives into consideration:
- Organisational: security policies and improved staff awareness of these policies.
- Procedural: procedures incorporated to control overall security.
- Physical: measures taken to control physical access to security-sensitive sites.
- Technical: measures taken to protect the IT infrastructure against internal and external threats.
The Information Security Manager is responsible for Information Security Management, and his/her roles include:
- The management of the entire security process.
- Acting as a liaison with upper management on security issues.
The Security Officer acts as a day-to-day functionary within a company’s information security regime, and his/her role also includes advising staff on security measures and policies.
Service Design Summary
Effective Service Design measures make it possible to provide cost-effective, high-quality IT services to the customer and makes sure that agreed-upon business requirements will be met.
ITIL Service Transition
Service Transition – is focussed on the development and potential improvement of capabilities for changing from a service that needs to be changed to one that is new or modified.
It should be noted that any technical and/or functional errors that are not found during this phase are likely to result in relatively higher levels of business or infrastructure impact. In turn, this may result in higher costs to fix these errors once the error-prone service is in operation.
The processes included within this phase are:
- Knowledge Management
- Change Management
- Service Asset and Configuration Management
- Release and Deployment Management
- Service Validation and Testing
A successful Service Transition can drastically improve the ability of a service provider to effectively manage large volumes of releases and change throughout all IT infrastructures.
The primary focus of Knowledge Management is to allow organisations to improve the overall quality of the management decision-making process by making sure that secure and reliable data and information is continuously available throughout the lifecycle to staff and other IT stakeholders.
A major component of the Knowledge Management process is the Service Knowledge Management Systems (SKMS). This is a complete set of integrated data and information repositories that are used to collect and manage information and knowledge. Apart from other elements which may be included, the major element within the SKMS is the Configuration Management System (CMS).
The CMS is a collection of databases and tools that are used to effectively manage a service provider’s configuration data. It also includes relevant information regarding incidents, problems, changes, releases, known errors and other issues. The CMS is held and maintained by the Service Asset and Configuration Management manager. The two major components of the CMS are:
- The Configuration Management Database (CMDB) which holds information regarding IT infrastructure configuration.
- The Known Error Database (KEDB) which is a database created and supported by Problem Management and also used by Incident and Problem Management.
Service Asset and Configuration Management
The objective of this process is to support the agreed-upon level of IT service provision by effectively managing, storing and providing the necessary information about Configuration Items (CIs) and Service Assets.
In order to pass the ITIL Foundation exam, you need to understand the following terminology:
- Configuration Item (CI): a reference to any IT component (except staff) that goes towards supporting a specific IT service. Note that this can also include SLAs, records of incidents and Requests for Change (RFCs).
- Attribute: detail regarding individual CIs.
- Status Accounting: the reporting of all historical and current data regarding each CI, e.g. whether it is being tested, under development, currently in operation, about to be retired, etc.
- Configuration Baseline: configuration details at a particular point in time, These details can be used as a reference point for later analysis.
Service Asset and Configuration Management is performed by a number of different roles:
- Configuration Analyst
- Configuration Manager
- Service Asset Manager
- Change Manager
- CMS Administrator
The main objective of Change Management is to make sure standard methods and procedures are used for the effective handling of all changes with respect to impact minimisation and operational improvement.
In order to pass the ITIL Foundation exam, you need to understand the following terminology:
- Change: alterations to any Configuration Item.
- Change Models: a definition of how various different change categories are analysed.
- Normal Change: a change that is implemented using a standardised change process. This type of change is assessed by a Change Advisory Board or a Change Manager.
- Standard Change: a low-risk, relatively common change that has already been approved and that follows a specific procedure or work instruction. This can include a password change or setting up a new workstation for a new employee. This should not be considered an RFC.
- Emergency Change: an urgent change that must be implemented as soon as possible due to its potential business impact. A procedure focussing on Emergency Changes will have to be followed.
- Request for Change (RFC): a standard piece of documentation used to capture and process a change to any CI.
- Change Schedule: a schedule of approved changes that is usually communicated to the users by support staff.
- Change Advisory Board (CAB): a group of stakeholders that is chaired by – and can provide expert guidance to – the Change Manager.
- Emergency Change Advisory Board (ECAB): a subsection of the Change Advisory Board that can provide expert guidance to the Change Manager in the case of emergency decisions.
When examining all potential changes, anyone involved in Change Management should have the answers to the following questions:
- Who raised the change?
- What is the reason for the change?
- What is the return required from the change?
- What are the risks relating to the change?
- What are the resources required to implement the change?
- Who has the responsibility for building, testing and implementing the change?
- Is there a relationship between this change and other past or future changes?
When assessing any potential changes, the Change Manager must have approval of the following areas before change implementation takes place:
It should be noted that Change Management is not part of the overall planning or project management process. Change Management is primarily concerned with making sure that should anything go wrong with a change, a fallback plan is in place.
Four individuals and groups are responsible for Change Management:
1. The Change Manager
- Offers administration of all Requests For Change (RFCs).
- Prepares RFCs for Change Advisory Board (CAB) meetings.
- Authorize or reject changes.
- Provides leadership to the CAB.
2. The CAB
- Provides advice to the Change Manager.
- Includes the Change Manager (as the chair) and can also include customer representatives, technical experts, vendors, suppliers and other service staff (all depending on the nature of the change being discussed).
3. Release and Deployment Manager
- In charge of managing the release of changes.
- Provides advice to the Change Manager in relation to release issues.
4. Technical specialists
- Create, test and implement hardware and software change components.
Release and Deployment Manager
The primary objective of Release and Deployment Management is to implement new hardware and software releases into production, support the transition of the releases to service operation, and eventually enable its use in order to provide value to the customer.
For the purposes of the ITIL Foundation exam, it is vital that you recognise the following terminology and understand its correct meaning:
- Release – a collection of authorised changes to an IT service.
- Release Unit – A Release Unit outlines the section of an IT infrastructure service that is usually released according to the official release policy.
- Release Package – one or more release units that are to be released in one action.
- Definitive Media Library (DML) – a virtual storage space for all authorised versions of media CIs. This storage space should include all documentation and licenses.
- Definitive Spares (DS) – a physical storage space for all hardware spares that are maintained at the same level as CIs that are currently in operation.
It is important to remember that the items stored in the DML and the DS storage spaces are recorded and noted in the CMDB as CIs.
There are different options available when deploying Releases:
- Big Bang – changed or new services are released into a live environment in one action.
- Phased Approach – changed or new services are implemented within a section of the user base at first, and then the implementation is repeated for other sections via a pre-defined schedule.
- The Push Approach – a changed or new service is implemented from the centre and then “pushed out” to other locations.
- The Pull Approach – a changed or new service is made available in a centralised location, but the members of the user base are then free to implement the changed or new service whenever they choose or whenever their workstation restarts.
- Manual – a changed or new service requires manual action by a member of staff to implement the release.
- Automated – a changed or new service is implemented using automation tools.
Service Validation and Testing
The primary objective of this process is to make sure that the changed or new service will provide the necessary value to the customers.
The overriding concept of Service Validation and Testing is the provision of quality assurance, i.e. making sure that the service design and its subsequent release will provide the predefined standards and requirements of the customers and all the stakeholders.
Without sufficient testing, introducing a changed or new service into an operational environment may result in an increase in:
- Incidents – when customers complain about the discrepancy between what was wanted and what was delivered.
- Service Desk calls – when the delivered service does not perform as required.
- Problems and errors – when support staff have difficulty diagnosing faults in an operational environment.
- Costs – when errors become more costly to fix in a live environment than in a test environment.
- Services that are not used effectively – when users are unwilling and/or unable to use the service to positively impact the business.
It should be noted that Service Validation and Testing are closely linked with – and operate alongside – other processes in this phase as well as other phases.
Service Transition Summary
An effective ITIL Service Transition phase can dramatically improve an organisation’s ability to deal with high volumes of changes and releases across an installed base.
Other benefits of an effective Service Transition phase can include:
- Increasingly precise Service Level and Warranty estimations.
- Smaller variations from overall resource plans and from costs (when compared to budgets).
- Improved Change and Release success rates.
ITIL Service Operation
Service Operation lifecycle phase is the overall management of IT services in order to make sure that delivery and support are both efficient and effective.
This phase of the ITIL / ITSM lifecycle requires an effective level of coordination and execution of the processes and activities needed to deliver and manage IT services for the benefit of customers and to previously agreed levels. Service Operation is also required to provide continuous management of the technologies that are used to support and deliver services.
The main goal of this phase is to make sure that the support and delivery of requested IT services remain efficient and effective. Because Service Operation is such an essential capability, strategic objectives are almost always realised within this phase.
Another of the main roles of this phase is managing the conflict between adapting to the changing business and technology environment, maintaining the overall status quo and developing a balance between conflicting demands and priorities.
In order to understand the SO phase, it is important to note the definition of a function. Functions refer to the people / automated measures that undertake specific roles and that perform a specific activity, process or combination of both.
The Service Desk
The main objective of the Service Desk is to support and supply the agreed level of IT service provision by making sure that the availability and accessibility of the IT organisation is maintained and by undertaking a variety of predefined support activities.
There are three different types of Service Desk that are referred to in the ITIL Foundation exam and each one is performed by people with a specific skill level and service call resolution rate:
- Call Centre – handles large volumes of service calls and has a low first-time resolution rate.
- Help Desk – coordinates and manages incidents and has a medium first-time resolution rate.
- Service Desk – has a high level of technical expertise and a high first-time resolution rate.
Apart from the different types of Service Desk, there are also four different structures for the aforementioned Service Desks that specifically refer to their physical organisation:
- Local – situated in the same locality / time zone as the customer that it supports.
- Central – services more than one user group, all of whom are situated in different physical locations / time zones.
- Virtual – despite having no physical structure, this Service Desk relies heavily on technology to coordinate disparate Service Desk staff and to provide a centralised knowledgebase.
- Follow The Sun – uses multiple Service Desks across different time zones which will provide round-the-clock support.
The main objective of Technical Management is to assist in the planning, implementation and maintenance of a relatively stable technical infrastructure to support the organisation’s business aims. This is generally achieved by using technical skills to quickly diagnose and resolve technical failures, to design a resilient and cost-effective IT infrastructure and to use the available technical skills to support and maintain the infrastructure in an optimum condition.
It should be noted that the role undertaken by IT Operations Management (mentioned blow) is usually performed by either Technical Management or Application Management. It is also important to note that the function of Technical Management includes both service designers and support staff.
IT Operations Management
The main objective of IT Operations Management is to undertake the daily operational activities that are need to effectively manage the infrastructure in accordance with standards defined during the Service Design phase.
IT Operations Management has two specific functions:
- Facilities Management – the management of the physical IT environment.
- IT Operations Control – the undertaking of routine operational tasks as well as the monitoring of the infrastructure in general.
The main objective of Application Management is to assist in the design, implementation and maintenance of individual applications that assist the business in achieving its aims.
Application Management is most commonly separated into different departments in accordance with the portfolio of applications currently – or about to be – in use.
Service Operation Processes
Within the SO phase, there are five distinct processes that support the overall goal of making sure that the support and delivery of IT services are efficient and effective:
- Incident Management
- Access Management
- Event Management
- Problem Management
- Request Fulfilment
Incident Management, Access Management and Request Fulfilment are generally carried out by the Service Desk. In contrast, Problem Management and Event Management are – for the most part – “behind the scenes” processes.
The main objective of Incident Management is to make sure that normal service operations are restored as quickly as possible and to reduce the overall negative impact of an incident to the operations of the business according the Service Level Agreement (SLA) limits.
An incident can be defined as:
- A reduction in IT service quality.
- The failure of a CI that has yet to affect IT services but may do so in the near future.
- An unplanned interruption to an IT service.
It should be noted that Incident Management is not about finding the cause of a particular problem but is more about resuming IT services and addressing the symptoms of the problem.
A major incident is considered to be the highest category and has the most impact on a business. Any activity undertaken to deal with a major incident is usually carried out by Problem Management (see below) who make sure that the cause of the incident is dealt with and that it never happens again.
Any incident is dealt with by the Incident Manager, the Service Desk and the various levels of support groups which will probably include Application and/or Technical Management.
The main objective of Access Management is to provide the capabilities required to give authorised infrastructure users the right and ability to use a specific service while preventing unauthorised users from accessing the same service.
Access Management is generally defined by policies drawn up by Information Security Management.
The main objective of Event Management is to provide the necessary capabilities to detect certain events, understand what they mean and decide what the appropriate action should be. This makes Event Management part of Operational Monitoring and Control.
The type of information gathered by Event Management includes warnings and exceptions generated by the infrastructure itself. This information could be used to maintain service quality levels and to report service achievements.
The main objective of Problem Management is to manage the lifecycle of problems that occur with one or more IT infrastructures. This involves reducing the impact of unpreventable incidents, preventing the repeat of incidents and preventing problems and related incidents from occurring. Problem Management processes can be either reactive or proactive.
For the purposes of the ITIL Foundation exam, it is vital that you recognise the following terminology and understand its correct meaning:
- Problem – the unknown underlying cause of one or more Incidents.
- Known Error – the known cause of a Problem with a related workaround or permanent solution.
- KEDB – the Known Error Database, a database managed by Problem Management and which includes documented workarounds for specific problems.
- Workaround – not a permanent solution to a particular Problem; a fully documented technique that can be used to restore functionality to one or more users and that is stored in the KEDB.
The main objective of Request Fulfilment is to fulfil requests from infrastructure users using repeatable, consistent and documented methods.
Service Operation Summary
Service Operation is generally where clients can actually see value being generated. In short, this phase is the actual execution of all the strategies, designs and plans from the other ITIL lifecycle phases.
ITIL Continual Service Improvement (CSI)
Continual Service Improvement (CSI) – is to make sure that continuous improvements to overall IT Service Management processes are implemented in order to provide additional value to the customer’s organisation. This phase is meant to be included within all the other Service Lifecycle phases and is part of the process to make sure that the services and capabilities used to improve and mature IT services are effective and efficient.
The three processes included within this ITIL phase are:
- Service Level Management (part of Service Design as well)
- Service Measurement and Reporting
- Continual Service Improvement Process (a 7-step process)
Service Level Management
The main objective of this ITIL process is to make sure that a predefined IT service level is provided for all operational IT services and that future IT services achieve the same level of service. In addition, it also proactively searches for – and implements – improvements to the IT service level delivered to the end-user.
Within CSI, Service Level Management is focussed on improving overall IT services and processes – as well as identifying potential improvements – by constantly:
- Analysing the data gathered during the Service Operation phase.
- Reporting information construed from the data.
- Evaluating the information.
- Making improvements to services based on information and data gathered.
The Service Level Manager is the role that is most involved within Service Level Management and the potential Service Improvement Plans. The Service Improvement Plans are generated using data and information gathered from:
- Failures to meet agreed SLAs.
- The identification of documentation and training issues.
- The identification of external and internal support groups that are under-performing.
- System testing that is eventually considered to be ineffective and inefficient.
Service Measurement and Reporting
The main objective of this ITIL process is to provide a level of coordination for the design of metrics, reporting and data collection activities from other functions and processes.
The four main reasons for the monitoring and measurement of a service are to:
- Validate, i.e. are we following and supporting the initial vision and strategy?
- Direct, i.e. can we get users to change their behaviour in order to improve services?
- Justify, i.e. are we collecting the correct metrics and targets?
- Intervene, i.e. what corrective action can be taken?
All of the chosen process metrics are collected during all the Service Lifecycle phases and are used to develop reports that focus on potential improvements.
Three types of metrics are used by the Service Measurement and Reporting process:
- Service Metrics – the quantifiable results of and end-to-end service.
- Technology Metrics – often associated with performance levels, availability levels, etc. These metrics will most likely be defined by technical specialists and system designers.
- Process Metrics – these usually come in the form of activity metrics and key performance indicators (KPIs). These metrics are usually focussed on value, performance, compliance and quality of services.
CSI Improvement Process
The main objective of the 7- step ITIL process is to effectively coordinate an approach that is structured and that improves ITSM processes and IT services.
In general, the CSI Improvement Process originates from the Deming Cycle of Continual Improvement. The Cycle consists of four elements:
- Plan – define roles and responsibilities, specify requirements, define objectives, etc.
- Do – allocate funds, define policies, generate reports, manage systems, etc.
- Check – analyse reports, undertake surveys, monitor against plans, etc.
- Act – develop improvement policies, implement appropriate improvements, assess improvements, etc.
It should be noted that, as ITSM / ITIL is an activity that is ongoing and that is performed to provide quality improvements, the aforementioned four steps should be undertaken in the exact order mentioned above and as many times as appropriate and necessary.
Continual Service Improvement Summary
The CSI phase is designed to be used holistically throughout the entire Service Lifecycle. The main benefits of CSI are:
- Increased ROI (Return on Investment – the difference between the benefits gained and the cost expended to achieve the benefits).
- Increased VOI (Value on Investment – a sub-component of ROI and the additional value created by the implementation of the related benefits).
- Competitive advantage.
- Increased growth.
This concludes the outline of all the ITIL Service Lifecycle phases.