ITIL 4 Foundation Certification Exam essentials

This article contains both ITIL 4 Foundation Certification Exam essentials and ITILv3 syllabus for the Foundation Exam; start reading the ITILv3 section first if you are new to the world of IT Service Management, then once you absorb some concepts jump to the new ITIL 4 section. Notice that the new version of ITIL is called '4' and not 'v4' as you would expect if it evolves from a previous version 3

If you work in an organisation heavily dependent of IT (virtually, ALL organisations are nowadays...), the chances are that they should be using the IT Service Management framework to control and manage their IT ecosystem and its relationship to the business. The latest version of this framework of guidelines is ITIL 4, which focuses on Value Creation rather than of Service Delivery as of its predecessor ITILv3. Axelos is the organisation that delivers the ITIL (Information Technology Infrastructure Library) materials and certifications

Before taking the ITIL 4 exam, I did a two-days course at The Knowledge Academy in central London, for a bout £600 which included the around £300 cost of the ITIL 4 Foundation Exam. Lucky me I booked the course during Black Friday when the prices were slashed by a quarter

• IITL 4
  • The Four Dimensions Model
    1. Organisations and People 
    2. Information and Technology 
    3. Partners and Suppliers 
    4. Value Streams and Processes 
  • The Service Value System
    • The 7 (plus 1) Guiding Principles (Focus on Value, Start where you are, Progress iteratively with feedback)
    • Governance
    • Continual Improvement (What is the Vision? Where are we now? Where do we want to be?)
  • The Service Value Chain
    • Plan, Improve, Engage, Design & Transition, Obtain & Build, Deliver & Support
  • ITIL Management Practices
    1. Continual Improvement
    2. Change Control
    3. Incident Management
    4. Problem Management
    5. Service Desk
    6. Service Level Management
    7. Service Request Management
• ITIL v3
  1. Service Strategy
  2. Service Design
  3. Service Transition
  4. Service Operation
  5. Continual Service Improvement
• The nutshells of IT Management 

ITIL 4

Unlike ITILv3 which specified a delivered service packaged to the customer, ITIL 4 theorises that value in the current digital climate is actually co-created with inputs from both providers and consumers; this form of value creation gives more power to the consumer. In terms of service relationships, ITIL 4 gives more value to collaboration over confrontation and proactivity over reactivity, knowing that service relationships can stretch from provision to consumption and include all those in between. Outcomes are positive results that help stakeholders; for example, an output might be a pair of glasses but the outcome is the increase satisfaction and confidence of the customer who wear the glasses

A cost is the expenditure allocated to a resource activity, and a product or service must have both utility and warranty value if it is to achieve outcomes successfully. In ITIL 4, every aspect of the framework is intended to help facilitate the co-creation of value

• Definition of Value; the perceived benefits, usefulness and importance of something, value can be subjective
• Definition of Value Stream; a series of steps an organisation undertakes to create and deliver products and services to customers
• Definition of Output; a tangible or intangible (in other words, something) created by carrying out or delivering an activity
• Definition of Outcome; a result for a stakeholder enabled by one or more outputs
• Definition of Process; a set of interrelated or interacting activities that transform one or more defined input into defined outputs, in other words: input > activity > output. Process are measurable, performance-driven and response to a specific trigger/s
• Definition of Utility; the functionality offered by a product or service to meet a particular need; to have utility a service must either support the performance of the consumer or remove constraints from the consumer (or do both); "what the service does", "fit for purpose"
• Definition of Warranty; assurance that a product or service will meet agreed requirements; warranty often relates to service levels and address areas such as the availability of the service; "how the service performs", "fit for use"
• Definition of Availability; the ability of an IT service or other configuration item to perform its agreed function when required
• Definition of Service Management ;a set of specialised organisational capabilities for enabling value for customers in the form of services; this requires an understanding of the nature of Value, the nature and scope of the stakeholders involved and how value creation is enabled through services
• Definition of Organisation; a person or group of people that has its own functions with responsibilities, authorities and relationships to achieve its objectives
• Definition of Organisation Velocity; the speed, effectiveness and efficiency with which an organisation operates; this is influence time to market, quality, safety, costs and risks
• Definition of Silos; silos are part of an organisation resistant to change, and that can prevent easy access to the information and specialise expertise that exist across the organisation; silos reduce efficiency and increase both costs and risks; silos are unable to collaborate because of their processes, systems, documentation and communications
• Definition of Customer; a person who defines the requirements for a service and takes responsibility for the outcomes of service consumption
• Definition of User; a person who uses services
• Definition of Sponsor; a person who authorises budget for service consumption
• Definition of Product; a configuration of an organisation's resources designed to offer value to a customer
• Definition of Services; a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks
• Definition of Release; a version of a service or other configuration item (or collection of items) that is made available to users
• Definition of IT asset: any financially valuable component that can contribute to the delivery of an IT product or service
• Definition of Service Offering; a formal description (NOT an activity) of one or more services, designed to address the needs of a target customer group; a service offering may include goods (a mobile phone), access to resources (access to the mobile network) and service actions (user support)
• Definition of Service Relationship; a cooperation between a service provider and a service consumer, it includes the activities by the organisation of Service Provision (configure delivery of the service,etc), Service Consumption (management of the consumer's resources needed to user the service, utilising the provider's resources,etc) and Service Relationship Management (joint activities performed between service provider and service consumer to ensure continual value co-creation based on agreed and available service offerings)
• Definition of Service Level; one or more metrics that define expected or achieved server quality
• Definition of feedback-loop; a situation where part of the output of an activity is used for new input
• Definition of Critical Success Factor (CSF); a necessary precondition for the achievement of intended skills
• Definition of Key Performance Indicator (KPI); an important metric used to evaluate the success in meeting an objective
• Definition of Performance; a measure of what is achieved or delivered by a system, person, team, practice or service
• Definition of Incident; an unplanned interruption to a service or reduction in the quality of a service
• Definition of Event; any change of state that has significance for the management of a service or other configuration item (CI); events are typically recognised through notifications created by an IT service, CI or monitoring tool
• Definition of Problem; a cause, or potential cause, of one or more incidents
• Definition of Known Error; a problem that has been analysed but has not been resolved
• Definition of Workaround; a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available
• Definition of Recovery Time Objective (RTO); the maximum acceptable period of time following a service disruption that can elapse before the lack of business functionality severely impacts the organisation, in other words the maximum agreed time within which a product must be recover or a service resume
• Definition of Recovery Point Objective (RPO) ;the point to which information used by an activity must be restored to enable the activity to operate on resumption
• Definition of Business Impact Analysis (BIA) ;an activity that identifies vital business functions -VBFs- and their dependencies; BIA defines the recovery requirements for IT services

ITIL 4 is composed of the Service Value System (SVS) plus the Four Dimensions model. Let's investigate first the Four Dimensions model: 

The Four Dimensions Model

As well as SVS, the ITIL 4 framework also depends on four dimensions that are crucial to the effective operation of IT services, and that can interact and synergise with all elements of the Service Value System. Before you implement anything, you need to consider these 4 dimensions.

ITIL believes that organisations should maintain a holistic attitude to their behaviour, without focusing too much on specific areas of operations, which can lead to carelessness with other areas. By giving each of the four dimensions an appropriate amount of focus, an organisation ensures its SVS remains balanced and effective. The four dimensions of service management are:

Organisations and people; each organisation needs a healthy culture to support its objectives and the right level of capacity and competency among its workforce. It is useful to promote a culture of trust and transparency that encourages its members to raise and escalate issues and facilities corrective actions before any issues have an impact on customers. Attention should be paid to:

• Skills and competencies of individual and teams
• Management and leadership styles
• Proper level of collaboration and coordination between departments

Every person in the organisation should have a clear understanding of their contribution towards creating value in the organisation. Stakeholders are anyone who will be affected, can be affected or you 'think' it may be affected. Leaders are critical, they must empower the workforce by upholding motivating values and creating an environment of shared attitude and organisational culture. This dimension focuses on the Roles and Responsibilities of the people involved in a process workflow

Information and technology; the culture of the organisation may have a significant impact on the technologies it chooses to use, as well as the nature of the business (a charity might go for Open Source while a Bank might not). This dimension includes the information created, managed and used in the course of the service provision, applications, databases, communication systems and their integrations, and all of these might be subject to security and regulatory compliance requirements such as GDPR, etc. When considering which technology to use, bear in mind the following: is this technology compatible with the current architecture of the organisation? does it align with the strategy of the organisation? does the organisation have the right skills across its staff to support the new technology? does this technology introduces new risks or constrains? for example locking into a specific vendor?

Cloud Computing enables on-demand network access to a share pool of configurable computing resources that can be rapidly provided with minimal management effort, resulting in computing resources elasticity that enables faster deployment and high-velocity service delivery

Partners and suppliers; this dimension also includes the alliances. When it comes to chose suppliers, an organisation strategy should be based on its goals, culture and business environment. These are the factors that influence an organisation at the time of choosing its partners and suppliers:

• Strategy focus; some organisation prefer to rely as little as possible on others, using their own resources instead, retaining full control over important functions in that way
• Corporate culture; there might be a historical preference for one approach over another, and this behaviour is difficult to change without compelling reasons
• Resource scarcity (you must have a supplier for certain items/services), cost concerns, subject matter expertise (you need 3rd party experts), external constrains (government's policies, industrial code of conduct, etc) and demand patters (customer activity for services may be seasonal or demonstrate high degree of variability)

You book your flight with Expedia, but you actually fly with BA, it is all about collaboration. Partners and Suppliers can give you strategic, tactical or commodities services and products. All this and more we can learn in this article of ITIL 4 Foundation Certification Exam essentials

Value streams and processes; this dimension is concerned with how the various parts of the organisation work in an integrated and coordinated manner to enable value creation through products and services, it defines activities, workflows, controls and procedures needed to achieve objectives. Identifying and understanding the different value streams of an organisation is critical in order to improve the overall performance, non-value-adding or wasteful activities should be eliminated to increase productivity

Service providers do not operate in isolation, they are affected by many external factors that are studied under the PESTLE model (Political, Economical Social, Technology, Legal and Environmental), which as you can see on the above diagram it surrounded the 4 dimensions model. When excising Value Stream Mapping, in other words looking at what's happening, don't antagonise people!

The Service Value System

The purpose of SVS is to ensure that the organisation continually co-creates value with all stakeholder through the use and management of products and services. The key inputs of SVS are opportunity and demand; opportunities represent possibilities to add value for stakeholders and improve the organisation; demand is the need or desire for products and services from internal or external customers

The 7 (plus 1) Guiding Principles ;also known as Management Practices, are a set of recommendation that can guide an organisation in a variety of ITSM scenarios, from adopting new IT frameworks to communicating with stakeholders, and essentially create a foundation for a shared culture across the organisation. These 7+1, as I call them, Guiding Principles promote the core ITIL values and help organisations to prioritise the creation of value and undertake continual improvement

1. Focus on value; everything that the organisation does needs to map (directly or indirectly) to value for the stakeholders, and the first thing you need to do is to determine who the service customers are and who the key stakeholders are. Value from the different parties involved can come in many forms, and is important to know that value for the service customers is defined by their own needs, and it changes over time and in different circumstances

An important element of value are both Customer Experience (CX) and User Experience (UX), which must be both actively managed to determine how the customer feels about the organisation and its products and services. Collect feedback on value from customers/stakeholders on an ongoing basis and understand how they should be contributing to the co-creation of that value

2. Start where you are; do not start building something new without considering first what is already available and ready to be leveraged; understand your current state first and what can be re-used from it. When running analysis to understand what you have, be mindful of unintentional bias or distortion of data, direct observation should always be the preferred option

Apply your risk management skills with this principle; there are risks associated with re-using existing practices and processes (continuation of damaging old behaviours) but there also risks associated with putting something new in place (they new procedures might not perform correctly)

3. Progress iteratively with feedback; don't do everything at once, better organise the work into smaller and manageable sections that can be executed and completed in a timely manner; this methodology makes it easier to maintain a sharper focus on each effort. The overall initiative must be continually re-evaluated to reflect any changes in circumstances or priorities, and ensure that the focus on value has not been lost. 

No improvement iteration occurs in a vacuum: seeking and using feedback before, throughout and after each iteration ensures that actions are focuses and appropriated, even if the ecosystem changes. Work in time-boxes if needed, and once you received feedback analyse it to identify opportunities, risk and issues. You can use the MoSCoW method (Must have, Should have, Could have and Won't have) with this principle

4. Collaborate and promote visibility; working across boundaries produces results that are long-term and more relevant to the objectives; achieving objectives requires information, understanding and trust, work should be made visible, hidden agendas (silos) avoided and information share to the greatest degree possible; when improvement activities occurs in relative silence, assumption and rumours can prevail. This principle emphasises the need to understand the flow of work in progress, identify bottlenecks and uncover waste

Inclusion is generally better than exclusion, the more people that are aware of what's happening and why, the more they'll be willing to help. Collaboration between departments is key (however, note that collaboration doesn't mean consensus, so just know that it is impossible to make everyone happy)

Communicate to the audience in the way the want to hear, if they prefer a phone call then call them, if email  then write them. Note the difference between Transparency (I send you reports so you know what I want you to know) and Visibility (I give you read-only access to the dashboard, so you're involved and know what's happening); insufficient visibility of work leads to poor decision-making

In the Agile world they do something called "Daily Stand-up": everybody per turns describes what they are up to. JIRA is perfect for collaboration and visibility. Cooperation means that each partner has a different agenda, but Collaboration means they share the same agenda

5. Think and work holistically; the organisation should work as a whole and you need to understand how all the different parts are integrated. In complex systems the alteration of one element can have an impact on others. Collaboration is the key of thinking and working holistically, and whenever the opportunity and resources are available use automation to support end-to-end visibility for the organisation, and to provide an efficient means of integrated management

Objective="I want my customers to come back". Critical Success Factor (CSF)="Customers satisfaction". Key Performance Indicator (KPI)="Customers feedback"

6. Keep it simple and practical; (but don't forget Security, so simplify only the things that you fully understand). Always use outcome-base thinking to produce practical solutions that deliver results; if a process, service, action or metric fail to provide value or produce a useful outcome, then eliminate it (you can eliminate a process, action, metric or service...but never eliminate data, regardless of the outcome). Always ask whether it contributes to value creation and reduce all non-value adding work, using the minimum number of steps to accomplish an objective

Some tasks are done by historical reasons or to please a particular person/group, are they still adding value? To embrace new practices, make them easier to understand by staff, simplicity is the ultimate sophistication; do fewer things but do them better. You can keep it KISS (Keep It Simply Stupid) and add components on apps as the customers requires them

If the customer only wants 1-page report, don't give 200 pages; the 10p bags at Tesco are fit-for-purpose in certain circumstances

7. Optimise and automate; (this really should be Simplify, Optimise and Automate). Eliminate anything that is wasteful, and use technology to achieve whatever it is capable of; human intervention should only happen where it really contribute value; remove these annoying, tedious tasks that a script can do. Before an activity can be effective, it should be optimised

Ensure that each optimisation has the appropriate level of stakeholder engagement and commitment, execute the improvements in an iterative way and continually monitor the impact of optimisation. Before automate an activity you need to first simplify it and second optimise it, and always progress iteratively with feedback

7+1. How do we keep the momentum going? This step of the Continual Improvement Model is used once the improvement has delivered the expected value and the focus is now shifted to increase improvement or to maintain the gains made by the improvement initiative

Governance ;in ITIL governance means the system or systems by which an organisation is directed or managed. A governing body could be a board of directors, team of senior managers or just one chief executive. Governance in action takes the following forms (EDM, Evaluate, Direct and Monitor):

• Evaluation ;the governing body will evaluate the organisation on a regular basis to assess its status and objectives
• Direction ;the governing body will choose the organisation's priorities and establish how to achieve them
• Monitoring ;the governing body will observe the organisation's progress and ensure that they correlate with the strategic objectives

Governance are accountable at the highest level for the performance and compliance of the organisation with policies and any external regulator. ITIL must be supported and implemented at the top of the organisation. The governing body should also have visibility of the outcomes of continual improvements activities and the measurement of value for the organisation and its stakeholders

Continual Improvement ;for maximum effectiveness, the ITIL 4 framework should be adopted at all levels and in all areas of the organisation, and everyone working on a products or service should attempt to find opportunities for continual service improvement whenever possible, from strategic to operational. Logic and common sense should always prevail when using the continual improvement model, which steps can server as a workflow, a high-level reminder to ensure improvements are properly prioritised 

• What is the Vision? first define a high-level vision of the improvement, each improvement initiative should support the organisation's goals and objectives. For NASA in the 60s would have been to put a man in the moon, make it the culture's organisation; note that the vision could be aspirational and may never be achieved in full. Have a read at Sir Christopher Wren and JFK stories here
• Where are we now? defines point A of the journey, the success of an improvement initiative depends of how clear and accurate is the understanding of the starting point and the impact of the initiative; make an assessment of your current services, user's perception and value received, and create an objective baseline measurement
• Where do we want to be? defines point B of the journey, the target state, and between A and B a gap analysis can be performed, critical success factors (CSF) and key performance indicators (KPI) are identified
• How do we get there? define the plan of the journey as a series of iterations, because at first the plan of improvement might not be clear and it will sometimes be necessary to design experiments that will test which options have the most potential; outline the steps that will be undertaken by the organisation in order to achieve its goals and move the organisation closer to achieving its vision
• Take action ;if previously you designed the plan, now it is time to take it to action, this could involve a traditional waterfall-style approach or a more Agile one; during the action focus on measuring progress towards the vision and managing risks, as well as ensuring visibility and overall awareness of the initiative
• Did we get there? sometimes it is assumed that the expected benefits of an improvement plan have been achieved, but success must be validated, have the original objectives been achieved? are those objectives still relevant?
• How do we keep the momentum going? if the improvement has delivered the expected value, the focus of the initiative should shift to marketing these successes and reinforcing any new methods introduced, so that you ensure that the progress made is not lost and build support for the next improvement; if the expected results were not achieved, the stakeholders need to be informed of the reasons for the failure of the initiative

Service Value Chain

This is the engine of the Service Value System, as it facilitates value realisation through the creation and management of products and services. SV Chain has six constituent activities that combine to create several value streams, flexible enough that they can adapt to different development technologies such as DevOps, Agile, Lean or Kanban. These activities represent the steps an organisation takes in the creation of value. ITIL 4 is designed to be versatile enough to support many different business types, so the structure of the service value chain may vary between implementations in different organisations

According to the Theory of Constrains (ToC), the weakest link in the Value Chain determines the flow and throughput of the system, so make sure you identify which one this is by using value stream mappings

1. Plan activity ;its purpose is to ensure a share understanding of the overall vision, current status and improvement direction for all 4 dimensions and all products and services across the organisation; this activity includes strategic, tactical and operational plans. This activity includes portfolio decisions for Design & Transition

2. Improve activity ;used to ensure continual improvement of all outputs throughout the value chain and also the four dimensions of service management. The records of Incident Management are use as an input to improve activities based on the incident frequency and severity

3. Engage activity ;facilitates a strong understanding of stakeholder needs, transparency and relationships with all stakeholders, so they are participants and take part; yes, engage with the stakeholders! The key inputs for the Engage activity are:

• a product and service portfolio provided by plan
• requests, detailed requirements and feedback from customers
• marketing and cooperation opportunities, as well as knowledge and information from the products/services in Design & Transition and Obtain/Build

The key outputs of the Engage activity are:

• consolidate demands and opportunities for plan, as well as product and service requirements for Design & Transition
• change or project initiation request for Obtain/Build, as well as service performance reports for customers

4. Design & Transition ;activity used to guarantee that all products and services meet stakeholders expectations for quality standards, costs and time to market. For example, an action that a Service Request Management employee would undertake as part of D&T is initiating standard changes to fulfil service requests

5. Obtain & Build ;its purpose is to ensure that services components are available where and when needed, and meet agreed specifications. Service Request Management contributes to Obtain & Build by acquiring pre-approve service components to help fulfil service requests

6. Deliver & Support ;its purpose is to ensures that products and services are created to match the agreed specifications of stakeholders' expectations

ITIL Management Practices

There used to be called processes in ITIL v3. In ITIL 4 there are a total of 14 general, 17 service and 3 technical management practices (total of 34). Lucky you, for the purpose of the ITIL 4 Foundation exam you only need to understand 7 of those practices well, and know the purpose and key terms of other 8. Let's first of all explore the 7 core practices that you need to know and be very familiar with

Continual Improvement (General); the purpose of this practice is to align the organisation practices and services with the changes business needs to go through in the ongoing improvement of products, services, practices and any element involved in the management of products and services. In alignment with the organisation's overall strategy, there should be a continual culture improvement and one or more Continual Improvements Register (CIR) for the whole organisation or departments to identify and log improvements, secure time and budget, making business cases for improvements and measuring and evaluating the improvements results

When assessing the current state, there are many techniques that can be employed such as Strength, Weakness, Opportunity and Threats analysis (SWOT); organisation should not formally commit to too many different approaches 

Change Control (Service); it maximises the number of successful services and product changes by ensuring that risks have been properly assessed, changes have been authorised to proceed, and managing the Change Schedule for those chagnges. While organisational Change Management manages aspects of changes (people, process, etc) within the organisation, Change Control in the other hand focuses on change in products and services, ensuring that they deliver value and protect customers and users from the adverse effect of changes

Change Authority personnel should understand the risks of changes and the expected benefits. These are the types of changes:

• Standard changes; low-risk pre-authorised changes that are well understood and fully documented
• Normal changes; they need to be assessed, authorised and scheduled as part of 'continual improvement'
• Emergency changes; these must be implemented as soon as possible, for example to resolve an incident or implement a security patch

The Change Schedule is use to plan changes, assist in communication, avoid conflicts and assign resources to it. Change Control need to make beneficial changes and protect customers an users

Incident Management (Service); this practice minimise the negative impact of incidents by restoring normal service operation as quickly as possible. Incidents should be logged, managed and documented, prioritise based on business impacts and resources allocated to solve them efficiently; it is important that people working on an incident provide good-quality updates in a timely fashion manner

In some scenarios, disaster recovery plans may be invoked to resolve an incident, and some organisation use a technique called 'swarming' to help manage incident: when a ticket is logged many different stakeholders look at it until it becomes clear which team is best to deal with the incident

Problem Management (Service); the purpose of this practice is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, managing workaround and known errors. Incidents have an impact on users or businesses, and must be resolved so that business activities can take place, while problems are the underlying cause of incidents and they required investigation and analysis to identify the causes, develop workarounds and recommend longer-term resolutions. Problem Management involves 3 distinct phases:

1. Problem Identification; identifies, analyses and log the problem
2. Problem Control; include problem analysis, documenting workarounds and known errors
3. Error Control; workarounds should be evaluated each time they are used (remember though they are NOT documented under Error Control, but under Problem Control instead), to asses their effectiveness and improve them if necessary; Error Control manages known errors and identification of potential permanent solutions

Problem Management activities are closely related to Incident Management, and these 2 practices complement each other (problem management identifies the cause of an incident) but can also conflict with each other (investigating the cause of an incident may delay the actions needed to restore the service)

Service Desk (Service); its purpose is to capture demand for incident resolution and service requests; it should also be the entry and single point of contact for the service provider with all of its users, providing a clear path for users to report issues, queries and requests. The Support and Development teams need to work in close collaboration with the Service Desk to deliver a 'joined up' approach to users and customers. The Service Desk staff may not need to be technical, but they need to be empathetic and require training and competency across a number of broad technical and business areas; they need to demonstrate excellent customer service skills, incident analysis, prioritisation, effective communication and emotional intelligence

Service Level Management (Service); its purpose is to set clear business-based target for service levels and to ensure that the delivery of services is properly assessed, monitored and managed against these targets. The skills and competencies for Service Level Management include relationship management, business liaison, business analysis and commercial/supplier management, this practice requires pragmatic focus on the whole service and not simply its constituent parts. SLAs are used to measure the performance of services, but for them to be successful they need to include:

• They must be related to a defined 'service' in the service catalogue, otherwise they are simply individual metrics without a purpose
• The should relate to defined outcomes and not simply operational metrics
• They should reflect an 'agreement' between the service provider and the consumer
• They must be simply written and easy to understand and use for all parties

The watermelon SLA effect is when the services look green on the outside (the SLA agreements are all met) but the outcomes and customer satisfaction are all red inside. Service Level Management involves collating and analysing information from a number of sources, including:

• Customer engagement, listening, discovering and capture information and feedback from customers
• Customer feedback, by the means of surveys and key business-related documents
• Operational metrics, these are low-level indicators of operational activities that include system availability, incident respond and fix times, change an request processing times and system response times
• Business metrics, these can be any business activity deemed useful or valuable by the customer (business opening times, POS terminal availability, etc)

"Measured twice, do it once", but be mindful when using metrics, they could adversely affect the behaviour, for example, some trains are cancelled because the driver sees he/she will be late for a certain number of minutes, and before crossing that threshold and marking the service as late and under-performance, they prefer to cancel it; this is a good example of bad metrics in use and an example too of the Goodhart's Law: "when a measure becomes a target, it ceases to be a good measure"

Service Request Management (Service); its purpose is to support the agreed quality of a service by handling all pre-defined, user-initiated service request in an effective and user-friendly manner. Each service request may include one or more of the following:

• Request for a service delivery actions, for example provide a report or change a toner
• Request for information
• Request for provision of a resource or service, for example providing a laptop to someone
• Request for access to a resource or service, for example access to a file
• Manages Feedback, compliments and complaints from users

Service Requests are pre-defined and pre-agreed as a normal part of service delivery, some workflows are simple while others (like the setup of a new employee) could be quite complex, in either case the steps to fulfil the request should be well-known and proven. Some service requests required financial authorisation, others can be completed by automation and all of them are dependent of well-designed processes and procedures

The following are 15 ITIL 4 practices whose purposes and key terms you need to know for the ITIL 4 Foundation Exam:

Information Security Management (General); its purpose is to protect the information needed by the organisation to conduct its business; this includes confidentiality, integrity, authentication, non-repudiation and availability of information. The required security is established by means of policies, processes, behaviours, risk management and controls, which must maintain a balance between:

• Prevention - ensuring that security incidents don't occur
• Detection - rapidly and reliably detect incidents that can't be prevented
• Correction - recovering from incidents after they are detected

Relationship Management (General); the purpose of this practice is to establish and nurture the links between the organisation and its stakeholders, at strategic and tactical levels; it includes the identification, analysis, monitoring and continual improvement of relationships with and between stakeholders

Supplier Management (General); its purpose is to ensure that the organisation's suppliers and their performances are managed appropriately to support the seamless provision of quality products and services; activities that are central to this practice include:

• Create a single point of visibility and control to ensure consistency across all products, service components and procedures
• Maintaining a supplier strategy, policy and contract management information
• Negotiating and agreeing contracts and arrangements, working closely with procurement and performance management
• Managing supplier performance, monitoring them to ensure the terms, conditions and targets on their contracts are met

The different types of supplier relationships are In-sourcing (products are develop internally), Outsourcing, Single source or partnership and Multi-sourcing

Service Configuration Management (Service); ensures that accurate and reliable information about the configuration of services, the CIs that supports them and their relationship between them is available when and where is needed. Services are also treated as CIs, and configuration management helps the organisation understand how many CIs that contribute to a service work together. Configuration Management Databases (CMDB) is where configuration information is stored and published

IT Assets Management (Service); the purpose of this practice is to plan and manage the full life-cycle of all IT assets, in order to help the organisation to maximise value, control costs, manage risks, meet regulatory and contractual requirements and support decision-making about purchase, re-use, retirement and disposal of assets

IT Asset Management (ITAM) is dedicated to physical infrastructure, while Software Asset Management (SAM) specifically aim to the acquisition, development, release, deployment, maintenance and eventual retirement of software assets. In both cases, an inventory information or asset register is required. The IT assets costs and related contracts are kept in a Configuration Management System (CMS). Activities required by this practice are:

• Hardware assets must be labelled for clear identification
• Software assets must be protected from unlawful copying
• Cloud-based assets must be assigned to specific products or groups so that costs can be managed
• Clients assets must be assigned to individuals who take responsibility of their care

Monitor and Event Management (Service); this practice systematically observe services and service components to record and report selected changed of state identified as events (incorrect password entered, etc); this practice identifies the events (business, information, security, etc) and established the appropriate response to those, including conditions that could lead to potential faults or incidents

Monitoring should be performed in a highly automated manner, and can be done actively or passively

Release Management (Service); its purpose is to make new and changed services and features available to users. Release normally takes place before deployment, where deployment makes the new functionality available. In waterfall model Release/Deployment may be combined and executed as a single process, while in an Agile/Devops environment there can be significant release management after deployment

Staging of a release is often achieved using blue/green releases of feature flags, where two mirror production environment (blue/green) are use, one with the new tools and the other one without; feature flags therefore allow for a controller way of releasing specific features to users. Release Management needs to work across organisational boundaries to ensure that all components are compatible and provide a seamless experience to users; we also need to consider the impact of changes to third-party components and plan for how these will be released

Deployment Management (Technical); its purpose is to move new or change hardware, software , documentation, processes or any other component to live environments; though being a separated practice, deployment management works closely with Release Management and Change Control. In some organisation the term "provisioning" is use to describe deployment not just of software but of infrastructure too. These are the number of distinct approaches that organisation use depending on their specific services and requirements:

• Phased Deployment; the new or changed components are deployed to just one part of the production environment, this is repeated as many times as needed until the whole deployment is completed
• Continuous Delivery; components are integrated, tested and deployed when they are needed, providing opportunities for customer feedback loops
• Big-Bang Deployment; the components are deployed to all targets at the same time, this is needed when dependencies prevent Phased Deployment
• Pull Deployment; the components are made available in a controlled repository and users download the software to their devices when they choose

Communications around deployments is part of Release Management; in an environment with multiple suppliers it is important to understand the scope and boundaries of each organisation's deployment activities and how these will interact

These other remaining practices are good to know, but most likely you'll not be tested for them in the ITIL 4 Foundation exam:

Architecture Management (General); its purpose is to provide an understanding of all different elements that make up an organisation and how these elements interrelate, enabling the organisation to achieve objectives. It provides principles, standards and tools to manage complex changes in the organisation. There are different architecture types like Business, Service, Information Systems (including data and application architectures), Technology and Environmental architectures

Remember that even when your data is in AWS/Azzure you are not entirely risk free, AWS/Azzure and not a Controller, they're a Processor. The one who will go to court if your data is compromise is the Controller (your business) never the Processor

Knowledge Management (General); knowledge is one of the most valuable assets of an organisation (information, skills, procedures, solutions and problems); this practice's purpose is to maintain and improve the effective, efficient and convenient use of information and knowledge across the organisation. It is important to understand that knowledge is not simply information, it needs to be use in the right context: if your documentation is a 300-page manual (knowledge) that might not be useful for an analyst who needs to find a fast solution (information) for a particular problem.

Knowledge Management aims to ensure that stakeholders get the right information, in the proper format, at the right level and at the correct time, according to their access levels and other relevant policies

Measurement and Reporting (General); the purpose of this practice is to support good-decision making and continual improvement by decreasing the levels of uncertainty, this is achieved by collecting relevant data of products and services. After understanding the organisational goals, some CSFs and KPIs can be defined against which success can be measured

Reports and Dashboards should make it easy for the recipient to see what needs to be done and then take action, and remember that target-setting KPIs for individuals can also have a negative side, operational KPIs should ideally be set for teams

Organisational Change Management (General); the purpose of this practise is to ensure that changes in an organisation are smoothly and successfully implemented, ensuring that everyone affected by the changes accepts it and supports it, providing training, awareness and other means of ensuring a successful transition to the changed state

Human factor is critical, and cooperation, participation and enthusiasm of the people involve in the changes are required, for this to happens you need to have:

• Clear and relevant objectives, so that the change is clear and make sense to the stakeholders; the change must be seen of real value
• Strong and committed leadership, who should visibly support and consistently communicate their commitment to the change
• Willing and prepared participants, who need to be convinced of the importance of the change 
• Sustained improvement, this will prevent people reverting to the old ways of working after some time  

Sometimes organisations might benefits from the support and guidance of third party supplier regarding changes, but the actual change activities and accountability are always in-house; not all people in the organisation will respond to the same message or be motivated by the same drivers

Portfolio Management (General);  this practice is to ensure that the organisation has the right mix of programmes, projects, products and services to execute the organisation's strategy within its funding and resources constrains

Project Management (General); this practices ensures that all projects in the organisation are successfully delivered; they are different approaches to the way in which projects are delivered, with the waterfall and Agile methods being the most common

TCQ, Time, Cost and Quality, are the constrains of every project manager

Risk Management (General); this practices ensures that the organisation understands and effectively handles risks, where the organisation's portfolio can be mapped to a portfolio of risks to be managed; risk is normally perceived as something to be avoided but with all risks come opportunities, and failure to take opportunities on board can be a risk on itself, innovation is inherently risky but could provide major benefits

For risk management to be effective, risks need to be Identified (uncertainties affecting achievements of objectives must be considered and described), Assessed (probability, impact and proximity of risks must be estimated) and Treated (appropriate responses to risks must be planned, owners assigned and monitored). The ISO 31000:2018 are standard guidelines for Risk Management https://avalution.com/the-basics-of-iso-31000-risk-management/ 

Service Financial Management (General); this support the organisation's strategies and plans by ensuring the organisation's financial services and investments are being used effectively, allocating the financial resources as directed by the governing body and management of the organisation; budgeting, accounting and charging are common finance activities, adding nowadays payment models and blockchain (allow transactions to be audited and verified automatically and inexpensively, where all records of previous transactions are called blocks) 

Traditionally, IT resources were obtained using upfront capital expenditure (CAPEX), however under the cloud model the IT infrastructure is provide 'as a service' with a subscription-based model which are paid for out of operational expenditure (OPEX)

Strategy Management (General); the purpose of this practise is to formulate the goals of the organisation and adopt the course of action to allocate the necessary resources for achieving those goals; it establishes the organisation's direction, focuses effort and priorities. The starting point for strategy management is to understand the context of the organisation and define the desired outcomes

Workforce and Talent Management (General); this practice ensure that the organisation has the right people with the appropriate skills and knowledge, and in the correct roles, to support the business objectives; workforce and talent management plays a critical role in establishing organisational velocity. The activities included in this area are workforce planning, mentoring and succession planning, learning and development, personal development, performance measurement and of course recruitment

Availability Management (Service); this practice ensures that services deliver agreed levels of availability to meet the needs of customers and users; MTBF measures how frequently the service fails while MTRS measures how quickly the service is restore after a failure. It is important to understand user satisfaction and at what point is slow performance so bad that the service is effectively unusable

Business Analysis (Service); this practice analyses a business, define its associated needs and recommend solutions to address these needs and/or solve a business problem which must facilitate value creation for stakeholders; analysis and solutions should be approached in a holistic way that includes consideration of processes, organisational changes, technology, information, policies and strategic planning. Business requirements can be utility-focused or warranty-focused:

• Warranty requirements; typically non-functional requirements captured as inputs from key stakeholders and other practices; organisation should aim to manage a library of pre-defined warranty acceptance criteria for use in practices
• Utility requirements; functional requirements which have been defined by the customer and are unique to a specific product

Business analysis requires not only critical thinking and evaluation, but also listening, communication, facilitation skills, ability to analyse and document business processes and user cases, and perform data analysis and modelling. To be effective, business analysis needs access to all information related to the area under analysis, and might need to interview the people responsible of the processes

Capacity and performance management (Service); the purpose of this practice is to ensure that services achieve agreed and expected performance, satisfying current and future demand in a cost-effective way; service performance depends on service capacity, therefore an understanding of capacity and performance models and patterns helps to forecast demand and to deal with incidents and defects

Service Catalogue Management (Service); this practice provides a single source of consistent information on all services and service offerings, ensuring they are available and expressed clearly to the relevant audience. The catalogues should be flexible and be able to provide different views and level of details to different stakeholders. Request Catalogues are those that enables customer engagement, providing details for existing and new services

The role of the Service Catalog Manager should ensure that all service definitions are documented and communicated to all relevant parties

Service Continuity Management (Service); the purpose of this practice is to ensure that the availability and performance of a service are maintained at sufficient levels in case of a disaster, providing a framework for the organisation to produce resilience, business continuity management (BCM) and an effective response that safeguards the interest of key stakeholders and the organisation's reputation

Service continuity management focuses on those events that are consider as disasters, while less significant events are part of Incident Management, design the functional aspects of services, develop and manage design documentations and Service Design Packages (SDPs)

Service Design (Service); the purpose of this activity is to design products and services that are fit for purpose, fit for use and that can be delivered by the organisation and its ecosystem; design thinking includes a series of activities like Inspiration and Empathy, Ideation, Prototyping, Implementation and Evaluation. The CX and UX aspects of Service Design are essential to ensure products and services deliver the desired value for customers and the organisation

The role of Service Design Manager has these responsibilities: create and coordinate quality solutions plans for services

Service Validation and Testing (service); its purpose is to ensure that new or changed products and services meet defined requirements based on the defined service value from customers, business objectives and regulatory requirements. Acceptance criteria can be of 2 types:

1. Utility-focused / functional tests
   • Unit Test, test a single system component
   • System Test, overall testing of the system including software and platforms
   • Integration Test, testing a group of dependent software modules together
   • Regression Test, testing whether previously working functions were impacted
2. Warranty-focuses / non-functional test
   • Performance and capacity Test, checking speed and capacity under load
   • Security Test, testing vulnerability, policy compliance, penetration and denial of service risk
   • Compliance Test, checking that legal and regulatory requirements have been met
   • Operational Test, backup, event monitoring ,fail-over, recovery and reporting
   • Warranty requirements Test, checking for verification of necessary documentation, training, support, model definition and knowledge transfer
   • User acceptance Test, a test performed by users of a new or changed system to approve a release

Infrastructure and Platform Management (Technical); its purpose is to oversee the infrastructure and platforms used by the organisation. When carried out properly, this practice enables the monitoring of technology solutions available to the organisation, including the technology of internal service providers. IT infrastructure may be managed by the service provider or by an external supplier as dedicated, shared or cloud services, every organisation must develop its own strategy to achieve the intended outcome with any type of infrastructure or platform 

Cloud Services Models:

• Software as a service (SaaS); the users use the applications running on the cloud, without having any control over the underlying cloud infrastructure
• Platform as a service (PaaS); the consumer deploys onto the cloud their own software and have control over the applications, but not the infrastructure
• Infrastructure as a service (IaaS); the consumer gets processing, storage and other computing resources from the cloud

Cloud Service Deployment Models:

• Private Cloud; located within the organisation's premises, it is managed, owned and used exclusively by the organisation
• Public Cloud; located at the cloud provide premises, and provisioned by the organisation
• Community Cloud; this might be owned, managed and operated by one or more stakeholder, and may exist on or off the organisation premises
• Hybrid Cloud; this is a composition to tow or more distinct cloud infrastructure (private, public or community)

Software Development and Management (Technical); the purpose of this practice is to ensure that applications meet internal and external stakeholder needs in terms of functionality, reliability, maintainability, compliance and auditability. This practice includes activities such as solution architecture, solution design, software development, software testing, management of code repositories, package creation, version control, sharing and ongoing management of smaller blocks of code 

References

Everthing you officially need to know about ITIL 4 https://www.sysaid.com/blog/entry/everything-you-officially-need-to-know-about-itil-4

The ITIL 4 Service Value System Explanied https://itsm.tools/the-itil-4-service-value-system-explained/ 

What are the Four Dimensions of ITIL 4? https://info.axiossystems.com/blog/what-are-the-four-dimensions-of-itil-4 

The Service Value Chain Explained https://itsm.tools/itil4-service-value-chain/

The differences between ITIL v3 and ITIL 4 https://optimalconnections.com/2019/10/03/the-differences-between-itil-v3-and-4-and-whats-in-the-new-itil-4-modules/  

ITIL 4: Why are Practices better than Processes? https://freshservice.com/ITIL4-practices-and-processes-blog/  

How ITIL 4 heldps IT Teams drive digitial transformation https://business.udemy.com/blog/how-itil-4-helps-it-teams-drive-digital-transformation/ 

ITIL v3

ITIL is simply a framework for best practices. When you're walking on unknown territory, the best way for not to fall on your steps is to follow a path that has already been walked many times by other people. "Learn from the mistakes or others, you can't live long enough to make them all yourself". ITIL principles and baselines lay down for you a good amount of advise about how to manage IT services, they are not rules or regulations just best practices (all vendor neutrals) that tell you the things that work. First of all let's start with some handy definitions:

ITSM ;IT Service Management is a set of specialised organisational capabilities for providing value to the customers, in the form of quality IT services, that meet the needs of their business, this is basically the implementation of services that is a mix of people, process and information technology (computers, etc). Every IT department should be consider an IT service provider, and adopt the principles and practices of service management to deliver IT services

IT Service Provider ;ITIL envision 3 different types of service providers:

• Internal Service Provider ;located within the business unit it supports, for example the IT department of an University
• Shared Service Unit ;located within the business but shared among other business units (still in the same organisation), for example the IT department or a large multi-divisional organisation
• External Service Provider ;this is an outsourcing partner, who deliver their services outside of the provider organisation

Service ;service is a means of delivering value to customers, by facilitating outcomes that customers want to achieve, without them having to have ownership or to bear specific costs associated such as infrastructures. The services should be delivered at an affordable cost and acceptable level of quality and performance. The service should always be "fit for purpose", and they can be grouped according to the value they provide to the customers. A Service Package comes with three different types of services:

• Core Services ;deliver the basic outcomes required by the customers
• Enabling Services ;the ones that ensure the core services can be delivered successfully
• Enhancing Services ;makes the core services more appealing or attractive to the customer

Service Level Packages are a pick-&-mix of the above packages. Ultimately, all services need to provide value to the customers

Service Value ;value is in the eyes of the beholder, and in ITIL service value is determined by 3 key factors: Customer Perceptions, Customer Preferences and Business Outcomes. Be aware that value involves a warranty and an utility (and a reasonable expectation of what the customer expects). The formula to calculate Service Value is: Utility + Warranty = Value

• Utility is summarised as "what the service does" and is commonly known as 'fit for purpose'
• Warranty refers to the ability of the service to be available when needed, and have sufficient capacity to meet the customer requirements, this is commonly referred to as 'fit for use'

Process; a process is a specific set of activities designed to accomplish a specific objective; a process takes inputs (that could well be the outputs of other processes) and turns them into outputs. Once the output has been confirmed, the process can be declared as effective; if the activities utilised a minimum of resources ,the process can also be declare efficient. All Processes have four common characteristics: 1)Respond to a specific trigger. 2)Measurability, the activities's performance of each process can be measure. 3)Specific outputs, the result of a process must be identifiable and have a measure of value. 4)Customers & Stakeholders, the process should meet the expectations of the recipient

The Process Model is structured as below:

• Process Control ;process owner, process policy, objectives, documentation and process feedback
• Process ;the triggers, process metrics, roles, procedures, work instructions and process improvements
• Process enablers ;process resources and process capabilities

The Process Owner/s is/are accountable for the process being fit for purpose. All processes are and can be measured, and have specific results. It is important to understand that all processes across the life-cycle are linked, and that they interact and influence one another.

Assets ;assets can be divided in Resources and Capabilities, and all processes need to have them in order to be successful. Capabilities & Resources cannot provide value on their own, it is the combination of these two that enables a process to deliver successful service management

Resources ;they are the direct inputs for the production of services, and they cover everything from money, infrastructure items, applications, people, etc ;they are considered physical assets

Capabilities ;these are the assets that allow the organisation to achieve something of value, such as the ability to coordinate, control and deploy resources in the form of a service; typically these include experience and knowledge embedded in the organisation

Functions ;in ITIL a function is defined as a group of people (and other resources or tools) that are use to carry out a process or process activities. There are 5 well defined functions in ITIL:

• Service Desk ;single point of contact for users
• Technical Management ;expertise of the technological infrastructure
• Applications Management ;expertise of the management applications
• Facilities Management
• IT Operations Control 

Functions can be carried out by Group (number of people who perform similar activities), Team (a more formal structure, including a number of people working together with a common objective), Departments (formal organisation structures within the same organisation) or Division (number of departments grouped together, often within the same organisation)

Metrics ;metrics are use for the following 4 purposes:

• Validation ;authenticates whether the strategy and vision are supported or not
• Justification ;ensures whether you have the right targets and metrics
• Direction ;ensures that people can be guided to change their behaviours based on factual data
• Intervention ;ensures that corrective actions are applied

Customers ;ITIL differentiates between internal and external customers, this is because you need to be able to differentiate between service that supports an internal activity and those that deliver business outcomes. These are the 2 types of customers:

• Internal ;they work within the same organisation as the service provider
• External ;not employed by the organisation or employed by a separate legal entity. External customers pay for the services under agreement through a legally binding contract

Each customer is unique, and they value different things, one might value quality of services, others the prompt delivery, the cleanses, the spirit of empathy it goes with it, etc

Stakeholders ;are individual or groups that have an interest in the organisation, service or project, and that are engaged in activities, resources, target or deliverable from service management. Types of stakeholders:

• Customers ;buy goods or services
• Users ;use the service that is bought by the customer
• Suppliers ;are responsible for the supply of good or service that are required to deliver the IT services

Roles in ITIL the term role is defined as a set of responsibilities, activities and authorities that are granted to a person or a team (remember that a 'team' in ITIL is referred as a 'function'). Roles can be shared or combined, but there can only be one process-owner for each process, and as well for each service there can only be one service-owner. There are different roles to consider, these ones appear in all life-cycle stages:

• Service Owner ,remains accountable for the delivery of the service; service owner often own more than one service, and they need to ensure that the customer's requirements are understood, thus communicating with the customer is crucial. They also need to ensure that the services follow the information security management policies
• Process Owner, this could include the Process Manager and Process Practitioner, the one actually doing the work. The process owner is responsible for documentation and the Metrics & Measuring, ensuring that the processes they're responsible for are managed and reported correctly. They are also responsible for Improvement opportunities and strategy of the related process, and ensuring of course the process is fit for purpose
• Process Manager ;accountable for the success of a process and for managing its day-to-day implementation
• Process Practitioner ;the one actually doing the job and producing evidence in the form of records, the one carrying out the process activities. Process managers and process owners should seek out the views of the practitioners when attempting to identify possible improvements, they'll know for sure what is wrong 

RACI Model ; RACI is a simple method to identify potential conflicts or issues, visually in the matrix. It stands for Responsible (the people doing the work, the process practitioners), Accountable (ownership of the process), Consulted and Informed. If you're an IT Manager, do apply the RACI Model to your team: https://www.projectsmart.co.uk/raci-matrix.php These matrix are useful to represent, for example, Operational Level Agreements (OLAs)

Training and Competence ;training is not a one-off activity, but rather it needs to be continuous as the service evolves. The personnel need to be competent and communicate efficiently, both in speech and writing. The Skills Framework for the Information Age (SFIA) describes job roles and responsibilities here: https://www.sfia-online.org/en/framework/sfia-7/skills-home 

ROI ;Return of Investment, the formula is increased profit from service / cost

Service Automation ; this can be applied in all areas (knowledge, information, processes, etc) to enhance performance, capacity management and optimisation. To ensure that automation fulfil its promises of benefits, it is necessary to do prior preparation and clarify the exact steps that need to be carried out. Automation should always be tested, and the only tasks or processes subject to automation are those that have a recognisable recurring pattern

The ITIL principles are framed into 5 categories, also called 101 and/or the Circle of Life for services:

1.- Service Strategy

This is the core stage of the life-cycle, and it includes the business perspective, position, future plans and activities needed in order for the business to deliver the services. The objectives of the Service Strategy are the following:

• Providing an understanding of what the strategy is
• Identifying the services and the customers who will use them, as well as opportunities for services and how to make the best use of them
• Understanding how to define value creation, the organisational capabilities to deliver the services, the level of demands and how to establish a relationship between the provider and the customer
• Defining the processes and services that will deliver the strategic plans, and the level of investment that will be required
• Coordinating and documenting the use of service assets, how they can be use and how to optimise their performance

During the phase of Service Strategy the following questions are answered (notice that risks are not considered at this stage):

1. What services should we offer and to whom?
2. How can we justify strategic investments?
3. How do we stand out from competition?
4. How can we create value for customers and stakeholders?
5. How can we allocate resources and prioritise investments in the Service portfolio?
6. How can we use financial management to control value creation?
7. What are the Patters of Business Activity (PBA)?

The Service Strategy manages 3 processes: Demand Management, Financial Management and Service Portfolio Management

Pattern of Business Activity ;Customers are the key, identify well what the customers want and in that way you'll differentiate yourself from the competition. You can identify PBA in your own company by discovering what customers want; for example if your customers like coffee and you happens to have a coffee shop, your mornings will be busy! Another PBA is Valentine's day for flower shops. PBA knowledge allows you to divert and utilise your resources intelligently

Service Portfolio Management ;this process ensures that you have the appropriate mix of services delivered by the service provider to meet the requirements of the customer, its objectives are to maintain a managed portfolio of the services provided, distribute information about these services, provide control and track organisational spend on IT services throughout the service life-cycle.

The Service Portfolio is a document or graph that should include past (or retired) services that can function as an archived, showing documentation of why services were discontinued. The portfolio should also include current services, a menu or catalogue of the services in use. Finally, a service pipeline, route-map or strategy for the future should be included too in the portfolio, so we all know where the company is heading to. The service portfolio should also include the business case that was used to create the related service, this is so that (at the time of cutting the budget) people will know where and when this particular service came from and why it is necessary

Retired Services are part of the portfolio, not the catalogue

Finance Management ;money is the common language between all business, no matter the nature of the business all of them will understand a 10% sale increased. There are 3 main processes to consider in finance:

1. Budgeting, all about control in both ways of the flow, money coming in and out; budgeting consist of a periodic cycle (usually annual) of negotiation to set budgets and the monthly monitoring of the same
2. Accounting, accounts for the way money is spent, this includes the term Return of Investment (ROI)
3. Charging,the process of billing our customers to get income for the services provided. You might want to setup a Cost Center that will take care of the charging and also a Profit Center

Business Case ;there are 5 categories that need to be included in a business case when applying for money for a service

1. Introduction ;must have a killer intro, presenting the business objectives addressed by the service
2. Methods and assumptions, defines the boundaries of the business case such as its time period used to define its costs and benefits; make it real and cover your back to ensure what will happens if ingredients change
3. Business impacts ,the financial and non-financial results anticipated for the service initiative proposed in the business case
4. Risks and contingencies, tell what you'd do if things don't go as expected
5. Recommendations ,specific actions recommended that should include both financial and non-financial impacts

Business Relationship Management (BRM) ;as part of your Business Strategy you need to contact your customers and ensure you know what they need. Create a strong communication channel between you and the customer, knowing the purposes and objectives of the services. "Measure twice, cut once" is the motto you should use when delivering services to your customers. Create a Business Relationship Manager (BRM) to ensure the customer's expectation are met, go on regular meetings with the customers, get feedback on our services, etc. When you provide services, you need to know 'exactly' how your customers are doing and feeling. BRM should ensure the service is 'fit for purposes', the utility functionality and the warranty capacity. The customer should see our services as a value  

2.- Service Design

The success or failure of any service or project is largely dependant of its initial design. If a service is unable to deliver the level of service required consistently (because of poor availability, capacity issues, insufficient security or lack of service continuity), it will have failed to deliver the warranty required. The Service Design is involved in both the planning of new services and changes to the existing ones, ensuring that the new/changed services fulfils the Service Strategy by delivering the business objectives. Successful design depends on taking the time to plan ahead, identifying and managing the risks to ensure a successful outcome; insufficient planning leads to costly rework and delays

Service Design activities must be undertaken on a regular basis as they result of identifying a new or changed business requirement 

For Service Design you have Perspective, Positions (your place in the market), Plans (where you want to be) and Patters (conditions and activities to achieve your goals). These are the processes that are included within Service Design:

1. Design Coordination
2. Service Catalogue Management
3. Service level Management
4. Availability Management
5. Capacity Management
6. IT Service Continuity Management
7. Information Security Management
8. Supplier Management

Successful Service Design must consider the four key elements (also known as 4 Ps) involved in the design:

• People ;they need to be prepare (training) to support/design the service else it will fail
• Processes ;each one should be documented and assessed to identify whether changes are required
• Products ;technologies and tools chosen to assist in the design or to support the service later
• Partners ;are manufactures, vendors and suppliers, ensure they are chosen carefully to support the service

Service Design Package (SDP) enables the transition from design to live, and captures all required information. SDP consists of one or more documents, produced during the design stage that later on are passed to the Transition Stage. The components that are considered part of a SDP are:

1. Functional Requirements
2. Service Level Requirements
3. Management Requirements
4. Design and topology

The typical contents of a SDP are:

• Original agreed business requirements, how the service will be used, key contacts and stakeholders
• Functional, Management and Service Level requirements
• Technical design including hardware, software, networks, data, applications, technology, tools and documentation
• Service Life-cycle plan
• Service Transition plan
• Service operational Acceptance plan
• Service acceptance criteria (SAC)

Service Acceptance Criteria (SAC) ;ensures services meet both expected functionality and quality, and that the service provider is ready to deliver the service

Service Level Management (SLM);it is an important area because it is through the Service Level Management that the IT service provider ensures that the services offered are aligned to the business requirements. One of the objectives of SLM is to develop appropriate targets for each IT service, these target must be specific and measurable, no room for expressions such as "as soon as possible" or "reasonable endeavours" should be used in a SLA

Operational Level Agreement (OLA) are agreements between the different departments within the same company, and when these agreements have to be made between 3rd party providers are called Underpinning Contract (UC). The OLAs should be kept simple because they are between colleagues, don't add legal jargon or any obfuscation language. Ensure you provide to the customers on regular basis Service Reports, with the number of calls being closed, time responses and other metrics; you can submit these reports using SLAM Chart (Service Level Agreement Monitoring) with tables, colours, visual representations, etc

Service Level Requirements (SLRs) represent what is required by the customer for a particular aspect of the service, and are therefore based on business objectives; they relate primarily to the warranty aspects of the service, defining the capacity, security, availability and service continuity requirements.

Service Level Agreement (SLA) is an agreement between the Service Provider (SP) and the Customer. SLA should be specific, clear and unambiguous expectation, and include SLR (Service Level Requirement) and metrics that indicates whether the SP is meeting its targets. You must have measurable targets to proves the services that you provide. SLA should be written in plain language, with few technical expression as possible and a glossary included; legal terminology is unnecessary and can cause confusion. SLA should make a distinction between the service and the support provided for that service. In a SLA reliability of services can be measured with:

• MTBF ;Meantime Between Failures, it measures uptime
• MTBSI ;Meantime Between Services Incidents, it measures time between one failure and the next failure
• MTRS ;Meantime to Restore Service, how long will it take to come back online after a failure; this is an important part of the availability management: a machine can go down and take 30' to fix it, but if you need 3 days to call an engineer from Germany that time should be added too; this basically measures downtime

Every commitment in a SLA should be supported by an underpinning agreement, either an OLA or UC. ITIL organises the SLA according to their structure, which could be:

1. Service-base SLA ;the agreement refers to one service only
2. Customer-base SLA ;the customer requests one SLA for finance, one for marketing, etc, because each department has different needs. This approach is difficult to monitor by the provider
3. Multilevel-base SLA ;this structure prevents unnecessary duplication, and it has 3 levels: Corporate, Customer and Service

SLM interfaces with several other processes to ensure agreed services levels are met, like Problem, Availability, Capacity and Incident Management 

Service Improvement Plan (SIP) now known as Continual Service Improvement (CSI) ;is a plan to improve the service that you're delivering. Measuring the customer satisfaction level is also the responsibility of the Service Level Management, surveys should be done and meeting should happen regularly, the temptation of avoid face-to-face meetings by sending copies of reports should be resisted. The document that contains all of these is called SIP or CSI

QoS is what you get (Quality of Service) when you spend the proper time designing a service that aligns well with the customer and business need. The TCO (Time Cost Ownership) should go down when the right time is spent designing the service. There are 5 aspects that should be included in the SDP: 

1. Service ;the services should be listed
2. Tools ;the management information tools to manage the service
3. Technology ;should describe the architecture that the service will use (if it is a virtual design would it be VMware, Azzure, etc)
4. Processes ;a collection of activities describing who is responsible of what. Processes can be automated once they have been thoroughly tested ensuring that they are reliable and working
5. Measuring ;design the metrics and the way by which the service will be measured in the Service Operation mode 

Catalogue Management Process ;should have a portfolio that, as we know, is divided in 3 sections: pipeline, catalogue and retired services. The scope of the catalogue management process includes all services that are being transitioned or have been transitioned to the live environment. The Catalogue is the customer facing document of the company, and it should contain the following items: 

1. Provide a single source of the services that we provide, consistent information showing what is available
2. Make it available to those approved to access it

The Catalogue has 3 views: Customers (a view for customers group A, a view for customers group B, etc), another view for Technical Support and another view for Third Party provider. This different views of the catalogue is called Hierarchy of Services 

Availability Management ;the term used in availability managements are Reliability, Resilience, Serviceability and Maintainability; design well from the beginning to avoid fiasco later, and be aware that the failure of one component can make the whole service unavailable to the users. VBF (Vital Business Function) are to be considered and taken care of (make them resilience!), as they are the most critical part of the services. The availability management touches all the life cycle sections, and can be divided in: 

1. Proactive Activity type ;planning & designing, new or changed services, risk assessment and countermeasures implementations (redundancy, firewall, intrusion detection systems, etc); testing
2. Reactive Activity Type ;monitoring and investigations to ensure you have resilience in place

When calculating the availability of a service, 99.9% should be well understood: if the service is expected to run 24/7 then that 99.9% does not have the same impact as if the service is listed on the SLA to be available from 9am to 6pm, because a failure at 10pm of 2 hours will not affect the business, and is out of the scope of the SLA.

Availability is calculated using the formula AST-DT/AST x 100, where AST is Agreed Service Time and DT is downtime

Capacity Management ;this process has the responsibility for ensuring sufficient capacity exists at all times, the service might still work (so availability is there) but the performance could be appalling if capacity manager is not taken into consideration, it should be thought about it earlier on in the Service Life Cycle process. Capacity Management should ensure as well that, if the demand of the service fails, the capacity provided for that service should also reduced, to avoid unnecessary expenditure

1. Capacity Plan ; should include scenarios for different predictions (Valentine's, Christmas days, etc) including the business changes, and it should cover 12/18 months ahead so that any planned expenditure can be included in the negotiation of the annual IT budgets
2. Guidance ;record anything that could affect performance
3. SLAs should be included
4. Diagnosis and Impact of the new services to be implemented should also be considered

Regarding utilisation you can see trends, like the useful PRTG or Splunk. Regarding processes, there are 3 important Capacity Management sub-Processes to consider:

• Business Capacity Management ;(strategy) what they need now and in the future
• Service Capacity Manager ;(tactical) control, prediction and ensure the performance meets the expectation, monitoring, reporting, etc
• Component Capacity Management ;(operational) focus on individual items of the services, ensuring all of them perform well; be proactive and identify a trend on specific components before a retention occurs

The Capacity Management Information System (CMIS) is where all these activities and changes regarding capacity are stored; the CMIS forms part of the overall Service Knowledge Management System (SKMS)

IT Service Continuity Management (ITSCM) ; this process focus on major events that have a catastrophic impact on the ability of the service provider to supply the vital services that enable the business to achieve its aims; what would happens when the third party chip you use to make your motherboards become discontinued, or out of stock? You need to plan for that by doing the following:

• Business Impact Analysis (BIA) ; identify RTO (Recovery Time Objective) and have a plan for Disaster Recovery Plan (DRP)
• Business Continuity Plan (BCP) ;you must have one in place, else what would you do is your street is cut for 2 x days due to a fire, police investigation or terrorist attack?
• Vital Business Function (VBF) ; ensure there is a plan for Business Continuity Management (BCM)
• Contingency Plans ; test fail-over procedures by doing Business Impact Analysis Exercises, when in doubt test it out. This section should include negotiation with third-party suppliers too 

Risk Management ;You have threats, assets and vulnerabilities, and where they meet this is where you have a risk. The company needs to have risk identification, assessment, management and mitigation. Risk Management is a repetitive activity, and it should become part of the accepted culture of any program or initiative

Information Security Management (ISM) ;include security earlier in the Service Design process, do this rather than later on trying to add it as an 'add-on'. A service that is insecure will not deliver the value to the customer. The principles of ISM are:

1. Confidentiality ;data in transit should always be protected, this can be achieve using encryption, access control mechanism (AD, smart-cards,etc)
2. Integrity ;the information should be completed and not have been tampered, we can use hash to verify integrity
3. Availability ;the info should be available and useful when needed, for example use RAIDs, fault tolerance routing, High Availability, etc

During the Operations Cycle the Access Management takes care of the above CIA points (Confidentiality, Integrity and Availability), creating an Access Control Policy, Password Control Policy, email, internet and antivirus policy, remote access policy, Information Classification policy, document classification policy, assets disposal policy, records retention policy, etc. These policies are to be stored in the Security Management Information System (SMIS)

Security is an ongoing process, and for it to be effective it should be considered as an integral aspect of the design and operations

Service Design Supplier Management; ensures that partners and providers can continue to support our IT services. Supplier Management is on the design but it touches every area of the life cycle. Service Level Requirements (SLR), Service Level Agreements (SLA) and Service Level Management (SM) are values that are looked up when a business work with a supplier. To keep track of your supplier you use SCMIS (Supplier & Contract Management Information System) that could as well be an excel document with the supplier details.

Supplier Management does not deal with internal suppliers.

Design Coordination ;this process carry out the coordination of the many different activities of service design, acting as a single point where complications, potential sources of conflict and misunderstandings are avoided. Design Coordination checks that the design conforms to the agreed standards, that is both fit for use and purpose, try to identify any improvements and ensures consistency across the designs, thus reducing risks significantly (design coordination prevents you from using metrics measurements while other departments are using imperial)  

3.- Service Transition

Previously, during the Service Design stage, you would have created the SDP (Service Design Package) which has now been passed to the Service Transition team, to implement the services listed in the SDP, thus reducing risks, managing changes effectively, better expectations of all parties and a increased success deployment thanks to the fact that there is a SDP to follow

Service Transition is a bridge between the Design and the Operations; during the transition process we build, test, change, install, implement, configure, deploy and release the services and/or applications needed. Some of the processes of the Service Transition cycle are:

• A) Change Management
• B) Knowledge Management
• C) Service Access and Configuration Management
• D) Transition planning and support
• E) Release and Deploy Management
• Service Validation and Testing, not included in exam
• Change Evaluation, not included in exam

Of all these processes, only the following 3 processes are fulfilled solely within the Service Transition phase: Change, Knowledge and Configuration (Service Assets) Management

Another hidden process is the "re-use", some apps or services that can be included in new releases, as well as "test environments" that you need to have to test the new services or releases

A) Change Management Process ;always ensure that Business Continuity is not affected when making changes to the system. ITIL defines this process as "to control the life-cycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services". Change Management keeps controls of all changes which must be authorised either by implied or explicit. The way it works is that you first present your change-request-for-change or RFC to the CAB (Change Advisory Board) who asses and analyses the implications of the change. CAB could have some prerequisites before even accepting a change, like for example if it needed, if there a risk, can be rollback, do we have resources to implemented, have the change being tested? CAB can prioritise the changes based on these metrics.  All changes should be:

• Approved
• Recorded, so we know what we are changing and can rollback if needed
• Updated ,reflect the new change in the CMS (Configuration Management System) of the company, updating documentation, etc

Change Control is the key of all these processes, you don't want to change stuff as people please, no, no: uncontrolled change may trigger or be the cause of incidents in the infrastructure. ITIL framework identifies these differences between a change, request for change and a change record:

• Change ;the addition, modification or removal of anything that could have an effect on IT services
• Request for Change ;formal proposal for altering a configuration item, it includes details of the change to be completed
• Change Record ;a capture of the details of the life-cycle of a change, change records should reference the configuration items affected by the change and they are stored in the configuration management system or service management tool

There are 3 different types of changes:

1. Normal change ;this goes through the CAB as explained above, and can of course be denied if, for example, the rollback procedure is not feasible. You need to have a well-thought out practice procedure before you put forward a RFC to the CAB
2. Standard change ;this is a change that has been pre-authorised by the CAB, it could be a low risk, low impact or a straight forward change; these types of changes greatly enhance the effectiveness of the Change Management Process
3. Emergency change ;this is a change that is urgent and must be implemented asap, still it needs to be approved by the E-CAB (Emergency CAB) who will need to provide authorisation as normally these emergency changes have not been tested or don't have a proper rollback procedure. Emergency changes should obviously be few and far in between

Remember that technicians just maintain, they're not allow to make any configuration changes without authorisation. Every Change Request should be subject to the known as "the seven Rs" of assessment questions:

1. Who raised the change?
2. What is the reason for the change?
3. What is the return required from the change?
4. What are the risks involved in the change?
5. What resources are required to deliver the change?
6. Who is responsible for the build, test and implementation of the change?
7. What is the relationship between this change and other changes?

B) Knowledge Management ;in the business you need to share experiences and information, and ensure they are available to the appropriate users; this info will allow us to execute better decisions in the future, thus saving money and time. Service Knowledge Management System (SKMS) is a platform that controls the access to the right individuals, inside the SKMS you can find the CMS (Configuration Management System), DLM, SLAs, as well as the Portfolio Catalogue. Please do not keep re-inventing the wheels, so have a DIKW structure in place:

• Data ;should be in the SKMS, for example an incident that has been logged of slow performance 
• Information ;that's what data transfer to, it gives context to the data, for example the incident logged occurred for 3 hours
• Knowledge ;is what we get from the information, for example those 3 hours happens to be during the backup process; knowledge is formed when you apply experience, context and understanding to the information analysis
• Wisdom ;strong common sense is acquired by knowledge, for example, be 'become wise and schedule the backup for off-operations hours"

C) Service Access and Configuration Management (SACM) ;this relates to an inventory of all your assets as well as the relationships between them. Configuration Items (CI) are stuff that you want to track on the inventory like Operating System, memory, hard drive, etc. The SACM should be able to capture the relationship between items and to provide the Status of the items (deployed, in maintenance or maintenance history, broken, historical allocation, etc) as well as Reports, Verification (data should be accurate) and Auditing. Whenever we do changes to certain components, having this information up to date is critical because one of the ways that an IT department can show its efficiency is by demonstrating that it has control over the assets it manages.  Service Assets and Configuration Management process ensures that configuration items are properly identified and managed

Configuration Management System (CMS) is another name for an inventory, and obviously it needs to contain a Configuration Management Database (CMDB) where all changes are recorded, this includes changes to contracts, agreements or physical assets

Software Assess Management (SAM) ;a platform to record all the licenses, software, where they have been installed, etc for the company. SAM is defined by a Definitive Media Library (DML) that keeps records of the different versions we have (1.0, 1.2, etc) all the ones that are more current, this can be understood like a folder with the latest versions of all software installed in the company

D) Transition Planning and Support ;this process provides overall planning and coordination of resources and all of the changes, ensuring change A does not damage change B and vice verse, and that certain policies have to be followed, use this or that software for the update, etc; if there is a conflict between changes this is where it gets resolve, in the transition planning and support. During this process not only the staff members are consulted but also the business and user community.

• Technical Management Function ;management of the IT infrastructure
• Application Management Function ;managing applications 

E) Release and Deployment Management process ;plan, schedule and control the deployment of software releases is the main purpose of Release and Deployment Management. Building, Testing and Deployment should be part of the SDP and should cause no harm and be compatible between versions. Knowledge and Transfer shall be present in the new deployments, so people know what the new features are and how to use them. A Release Policy should be defined to ensure effective management of releases, specifying the requirements and a definition of what is actually a release, because minor operational changes can be addressed by change management; the policy should specify the expected frequency for releases, any automation that can be applied, the entry and exit criteria for each stage of the release, etc

Release and Deployment is structured in four phases:

1. Release and Deployment Planning ;stars with the authorisation from change management to make a release, then a plan in created. Change Management authorised the changes before they are deploy in new releases   
2. Release Build and Test ;in this phase the package is built, test and checked into the DML with proper documentation
3. Deployment ;the package is deployed to the live environment, and handover to the service operation team is done
4. Review and Close ;this is where experience and feedback are captured, performance targets are reviewed, achievements are assessed and lessons are learned

4.- Service Operation

It is during Service Operation when the services are actually being delivered and optimise. The outputs from Service Strategy, Design and Transition become all visible during service operation. It consist of delivering the service efficiently, at an acceptable cost and within the SLA parameters previously designed and agreed. In the ITIL universe "functions" are just a team of people, ITIL describes four functions that are part of the Services Operations life-cycle:

1. Technical Management ;required to manage the IT infrastructure and also provide technical support; should be involved during the technical strategy of the service
2. Application Management ;this function shares many features with the technical management, the difference only relates to the management of IT application software (including external supplier applications) and not infrastructure or application development. They help in the design of the application, assist in their deployment, support it in live environment and identify and implement improvements
   • Application Development vs Application Management ;there is a big difference between the two: while application development is normally a finite activity (it finished once the app is developed) the application management on the other hand remains involved throughout the life-cycle of the application. There is a growing tendency, however in business, to end the division between these two teams
3. Operations Management ;its role is to carry out all the day-to-day activities that are required to deliver the services provided; operations management should always strive to optimise the use of exiting technology and exploit new technical advances to provide the required level of service at the best cost. Operation Management is mainly divided in two parts:
   1. Operations Control ;this part of Operations Management oversees the IT infrastructure, management of batch jobs (database updates, etc), carrying out backups, printing and electronic distribution, maintenance activities, patches and virus updates, etc
   2. Facilities Management ;they are responsible of the physical IT environment, like power supply and power grid, air conditioning, etc
4. Service Desk ;Help Desk should be the single point of contact for Customers, the one-stop shop for all the customers needs so that customers satisfaction is increased. The different structures could be:
   1. Local Service Desk ;there is a clear presence of the technical team
   2. Centralised Service Desk ;it has central and branch office reporting to the same technical support site
   3. Virtual Service Desk ;use remote access or other technology to provide support, this encapsulates offshoring 
   4. Follow-the-Sun Service Desk ;usually implemented in international organisation to provide 24/7 support services depending of who is awake on a given time zone; for this to work the company needs to have common tools, processes and knowledge as well as language skills 

Part of the service operation processes are Incident and Problem Management, two of the most more important of all the ITIL processes

Request Fulfilment process ;this process is responsible for managing the life-cycle of all service requests from the users, its objective is to provide efficient fulfilment of simple requests to meet the requirements of the business, like for example keyboards or mice. It is important to differentiate between a Request and an Incident when creating/analysing a ticket, a change becomes part of the Request Fulfilment Process when the cost and risk oft he change are low. This process is the 1st step by which users contact the Service Desk, it identifies whether they have an incident (printer not working) or a service request (password needs reset); this process handles the request for calls other than incidents. "Service Request" is a term generally use for many things, low risks that don't affect the performance or delivery of the system. The benefits of having service request are:

• Happy users, as well as general complains and enquiries, are all deal with the Service Request team
• Standard channel of contact
• Provide information regarding procedures and availability of services

Major incidents (like no Internet or router failure) need immediate attention and focus. The status of the incidents could be Open, Assigned, Allocated or In Progress, On Hold, Resolved and Closed (how about re-Open?), and the Incident Record contains all the information concerning a particular incident. Reported incidents go through a number of steps:

1. Incident Identification ;incident management is a reactive process, therefore no problem can be solved unless it is reported first!
2. Incident Logging ;gather and log as much information as possible of the incident, who reported, why, what, when, where
3. Incident Categorisation ;network issue? infrastructure? application or database issue? this pipes the incident to the right team
4. Incident Prioritisation ;if the incident impacts business continuity, then it is urgent
5. Initial Diagnosis ;service desk will look in the Known Error Database for a match of the incident, an initial routine that can be applied to troubleshooting, etc, ensure paper on the printer, turn it off then back on again
6. Incident Escalation ;if service desk is unable to resolve the incident, it is then escalated to support groups or third parties; sometimes incidents are automatically escalated based on SLA targets
7. Investigation & Diagnosis ;this is the major activity that takes place during the incident
8. Resolution & Recovery ;potential incident resolutions should be tested to ensure that they actually resolve the issue completely with no unintended consequences. Once the incident is resolved, it returns to service desk for closure
9. Incident Closure ;once resolved, service desk will contact the user to verify that the incident may be closed.

Incident Management process ;incident is defined as an unplanned interruption to an IT service, reduction of the quality of the service or failure of a CI. Incident Management deals with restoring the access asap and getting tickets resolved, this sections tells you how to restore normal access and solve problems (normally as specified in the SLA). The Service Desk could use an Incident Model, a predefined document with the ordered steps they need to follow to narrow down what's happening and how to solve the issue

Major incidents and hierarchical escalation needed are part of Incident Management. Incident Resolution does not necessarily includes understanding why the fault has occurred or preventing its recurrence, these are matter of problem management, if the same incidents are recurring we need to investigate the root cause of the issues, this root-cause analysis is part of the Problem Management

Problem Management process ;looks at the root-cause analysis of the previously reported incidents, this is normally not as urgent to resolve as any Incident Management issue, and therefore it takes a slow approach to problem-solving, being more proactive than reactive. Generally, one or two similar incidents of the same nature lead to a Problem Management analysis. Known-error databases are a place to look for previous errors. Problem Management aims to reduce repeated incidents and to reduce the frequency of failures. Problem Management contain a number of steps, as follows:

1. Detecting Problems ;first identify that a problem actually exist; problem could be reported reactively (the user tells you) or proactively (event monitoring sends you an alert before the item fails)
2. Logging Problems ;the problem record must contain all relevant information
3. Categorising Problems ;
4. Prioritising Problems ;all problems need to be allocated a priority in relation to the impact to the business
5. Investigating and Diagnosing Problems ;resources might need to be diverted to solve problems; when test environments exits they can be use to re-create the fault and try solutions
6. Identifying a workaround ;although the aim of Problem Management is to find and remove the underlying cause of incidents, sometimes the development of a workaround is needed
7. Raising a Known Error Record ;when the problem has been identified and documented, the information should be added to the Known Error Database (KEDB)

Lessons can be learned from what went well as well as from what went bad; on problem closure a review should be actioned

Problem Management interacts with other stages of the life-cycle as follows:

• Service Strategy:
  • Financial Management for IT services ;possible solutions or workaround must be financially justified
• Service Design:
  • Availability Management ;availability management has similar aims to problem management: to prevent downtime, and by proactively identifying the risks a problem could be prevented
  • Capacity Management ;as with availability, problem management can supply information about the success of any measures taken
  • IT Service Continuity Management ;when a significant problem is causing or will cause major disruption to the business, it may be necessary to invoke the ITSCM plan until the problem is resolved
  • Service Level Management ;the service level manager has to report to the business about any failures and what is being done to avoid them in the future
• Service Transition:
  • Change Management ;when a change is required to resolve a problem or implement a workaround, it is submitted to change management in the form of an RFC
  • Service Asset and Configuration Management ;CMS provides the identification of faulty CIs, as well as to which CIs are common to several incidents, hence helping Problem Management
  • Release and Deployment Management ;when a change to solve a problem is approved, it is the Deployment Management that will implement it in the live environment
  • Knowledge Management ;The KEDB is an essential input into knowledge transfer, the SKMS may hold both problem records and the KEDB
• Continual Service Improvement:
  • The 7-step improvement process ;the 7-step process can be used by CSI or Problem Management to identify and resolve underlying problems

Event Management process ;failures do occur and you need to have systems in place that notify you when changes of status are occurring; PRTG is a great example of this. Event management can also include fire detectors, software licensing expiration detectors, intrusion detection on the network or on the building, etc. There are two types of event monitoring tools:

1. Active Monitoring tools, they poll/ask devices to check if they are working correctly
2. Passive Monitoring tools, they don't send polling messages; they detect events generates by CIs

Monitoring and Event Management are different activities, as follows:

• Event Management ;concerned with generating events and detecting notification that have been produced
• Monitoring ;detects notifications and actively checks the CIs to ensure they are working correctly, whether or not an event has been generated

We can have different types of events like Informational (a users has login, and e-mail has been sent, etc), Warning (cpu goes to 90%, still can operate but is worrying, storage used up to 90%, etc) and finally Exceptions (critical errors that need your immediate action, for example an attack being detected, a VM that has failed, etc)

Access Management process ;controls the access to data, requesting access to a service, and ensures only those authorised have got access to the data; it follows the CIA (Confidentiality, Integrity and Accessibility) principles to the data. The users needs to identify themselves correctly before access to the data is granted. This sections also defines the creation of roles where permissions are set (role-based access control). Access should be revoked once the user leaves the organisation. The decision of how to control the access (either AD, LDAP, multi-factor, fingerprint, etc) should have been made in the earlier process, and should be with the SDPP

Communications ;this is a key function of the business, teams need to be able to communicate issues to one another effectively and quickly; setup an intranet or another meaning where users can check the status of the services. Communicate projects, changes, exceptions, emergencies, performance monitoring, etc

Advertising ;make it easy for users to report to the Service Desk, a single phone, single point of contact, etc     

5.- Continual Service Improvement

CSI does not work in isolation, it is actually the key to success because organisations do not stay static in their requirements. Reviewing performance and identifying improvement opportunities allow the continued development of higher-quality, lower-cost services.

CSI uses the business data to understand the vision and the needs of the business and what it is trying to accomplish, once it has identify where the company wants to go, it questions where are we know, and it sets a baseline. Where do we want to be? Measurable targets are needed to know whether we are getting close or not to the destination. It could take a long time -a decade, etc- to achieve the final goal of the company, but annual goals can be set and regular appraisals. Measurement is critical to the success of continual improvement

The adoption of ITIL will result in controlled, gradual and maintainable improvements. In the life cycle diagram Continual Service Improvement (CSI) circle all the other sections as it intends to look for improvements in all the areas. Some of the purposes of CSI are:

1. Increase efficiency
2. Maximise effectiveness
3. Optimising the cost expenditures

The recommendation is to create a CSI Register where all individual improvements can be recorded

Service Reporting are great to know is we are improvement or not, and to pin point where the improvements need to be made. Have an anonymous box where user can report what needs to be improved.

CSI Register ;a document where you save all the ideas for improve, this document is normally kept inside the SKMS 

Deming Cycle (PDCA) ; Edward Deming quote "Without data you're just another person with an opinion" summaries the principle he created.  There are four basis steps for quality improvement in this continuous process cycle: Plan (project plan)> Do (do the project) > Check (audit) > Act! (new actions)

Critical Success Factor  ;CSF is something that must happen if an IT service, process, plan or other activity is to succeed, they are measurements using KPI, key performance indicators. Measurement is a fundamental part of all processes, because all processes must be measurable; CSI cannot take place without the results of the measurement. To be useful, measurements must be objective

It is recommended that a service or process have no more than 2 to 5 CSF, and that each CSF have no more than 2 to 5 KPIs for measuring success. Performance Indicators should be relevant and provide useful information. KPIs can helps asses 4 areas: quality, performance, value and compliance in following the process. There are two types of KPIs:

• Qualitative KPIs ;improving service quality, their metrics is original customer satisfaction while the measurements is incident handling survey score
• Quantitative KPIs ;reducing IT costs, their metrics are costs or handling incidents while their measurements are time and resources spent on the incident

Metrics ;a metric is a scale of measure that allows you to define what is to be measured; there are 3 types of metrics that an organisation will need to collect to support the activities of CSI and other service management processes:

1. Technology Metrics ;associated with managing components, monitoring systems, etc
2. Process Metrics ;they are captured in the terms of the CSFs and KPIs
3. Service Metrics ;they measure end-to-end service performance, and consist of the results produced from the technology and process metrics

Baselines are used to provide a clear starting point for any improvement activity, so it is important that when capturing a baseline you ensure that it is accurate

Seven-Step Improvement Process ;the ITIL Service Improvement involves 7 well identifies steps, based on baselines that validates, set direction of activities, justify and intervene at the right place to strength the weakest link in the change; these 7 steps are:

The purpose of the 7-step is to successfully implement improvements. One of the key considerations is that the improvement should be cost effective: if the cost of the implementation outweighs the benefits then the improvement must be carefully assessed.

1. Identify the Strategy for Improvement ;create business plans and strategy, service review meetings, vision and mission statements, customer satisfaction surveys, CSI register, etc
2. Define what you will measure ;SLRs and targets, Service Portfolio and Catalogue, Budget Cycle, Benchmark data, baseline data, risks assessments and risks mitigation plans
3. Gather the data ;the inputs are existing SLAs, new business requirements, trend analysis reports, etc
4. Process the data ;the processing take care to consider the frequency of processing the data, tools and system use for the processing, evaluation techniques to verify the accuracy of the data 
5. Analyse the Information and data ;inputs include existing KPIs and targets, results of monitoring data, information and perception from customers satisfaction surveys
6. Present and Use the Information ;there are four common audiences types: the Customers , Senior IT Management, Internal IT and Suppliers
7. Implementing Improvement ;inputs include agreed-upon implementation plans, CSI register, knowledge gained from presenting and using the information

There is an association between the DIKW model and the 7-step improvement process:

• Data ; 2)define what you'll measure 3)gather the data
• Information ; 4)process the data 
• Knowledge ; 5)analyse the information and data 6)present and use the information
• Wisdom ; 7)Implement improvement 1)Identify Strategy for improvement

There is also an association between the PDCA model and the 7-step improvement process:

• Plan; 1)Identify Strategy for improvement 2)define what you'll measure 
• Do; 3)gather the data 4)process the data 
• Check; 5)analyse the information and data 6)present and use the information
• Act; 7)Implement improvement 

References

Continual Service Improvement is NOT a Service Lifecycle Stage https://www.thinkhdi.com/library/supportworld/2017/continual-service-improvement-not-service-lifecycle-stage.aspx   

An introduction to ITIL - Continual Service Improvement http://www.cmnogueira.pt/2013/05/10/an-introduction-to-itil-part-55-continual-service-improvement/

An overview of ITIL CSI and the 7-step Imrpvement Process https://www.invensislearning.com/resources/itil/overview-of-itil-csi-and-the-7-step-improvement-process

The Deming Cycle https://www.balancedscorecard.org/BSC-Basics/Articles-Videos/The-Deming-Cycle

Service Transition https://www.hci-itil.com/ITIL_v3/books/3_service_transition/service_transition_ch4_3.html

ITIL https://www.wikiwand.com/en/ITIL 

The DIKW model for Knowledge Management http://www.theitsmreview.com/2016/04/dikw-model-knowledge-management/ 

The nutshells of IT Management

"I know what I'm doing, but I have no idea what the business is doing", this statement should be eliminated from every employee with the help of ITIL

Always explain the risk to the business, if they are willing to tolerate then go ahead with the changes/not-changes. Remember that IT do not take any business decisions, put policies in place to protect yourself from risks

In IT we tend to provide the solutions quickly, you need this or your need that, etc.... wrong! Always capture the requirements first before you attempt to provide a solution 

To understand the culture of an organisation, visit the smoking room, this is where all the gossip are happening. Risks are not always bad, they are also a source of opportunity. I can't motivate you, but I can understand what motives you so I can provide the right environment for you to be motivated

Program vs Project: a project focuses on the output (it creates a wing for a plane) while the program ensures the aircraft is finished and operational. Program Management outlast Project Management

The 2 more important words in ITIL 4 are Adopt and Adapt, because you'll need to adopt the methodology and adapt to the changes. Once in a while you should go around your user's desk looking for sensitive information, password behind keyboards, logon details attached to the screens, etc, make sure you remove all that you find!

London, 26th December 2019, boxing day!