- [Instructor] Welcome to the
edureka! ITIL Foundation course. Before we get started and dive into ITIL it's only fair that we
understand what ITIL stands for and what it encompasses. So ITIL stands for IT
Infrastructure Library. It is the most widely
adopted set of guidelines for IT service management. Essentially an integrated set
of best practice processes for delivering IT services to customers. ITIL primarily focuses on
maximizing value to customers by aligning IT resources
with business needs. It is important to note
that ITIL is not a standard, but more a set of best
practices guidelines that can be customized
to any organization. So why is ITIL so popular and why have you taken your time to learn ITIL? It's extremely important
that we understand why ITIL is so popular around the world. The three fundamental reasons. One, it is vendor neutral,
two, it is non-prescriptive, and three, ITIL is a best practice based on thought leadership. So these are the three
things that make ITIL extremely important and
big around the world. Let talk about a little bit
about the history of ITIL. It's a pretty interesting story. ITIL dates back to the 1980s, when the UK government's CCTA, which stands for Central Communications and Telecommunications Agency required guidelines to operate
its government data centers. Back then, ITIL was
defined as a practical, no-nonsense framework for
identifying planning, delivering, and supporting IT
services to the business. So this was the scope of
ITIL back in the '80s. Essentially ITIL was a set of books that discussed specific
IT service management best practices, based on
recommendations from CCTA and in course of time IT
organizations across the world began adopting ITIL as a
defacto standard for IT service. Little bit of history there,
but extremely important to understand the history before we get into the
core volumes of ITIL. The 2011 edition of ITIL
is the latest edition, and this course sort of covers the 2011 edition of ITIL at length. Just a short overview of the program. Consists of five exams,
the ITIL Foundation, followed by ITIL Intermediate, followed by ITIL Managing
Across the Lifecycle, which is popularly known as MALC. Followed by ITIL Expert and
finally the pinnacle of ITIL called ITIL Master. The ITIL qualification scheme
uses a modular credit system called the ITIL credit
system, so what does it mean? This means that each of
these exams, the Foundation, the Intermediate, the MALC, the Expert, and finally the Master, every time you clear these exams you get, you pick up credits and the culmination of your ITIL expertise depends on how many
credits you have completed. This particular course from edureka! prepares you for the first step, which is the ITIL Foundation exam. A little bit about the exam. Essentially 40 multiple choice questions that need to be answered
over a period of 60 minutes. You have the option of taking
the ITIL Foundation exam online or a paper based exam. Good news, there is no negative marking, and in order to clear
the ITIL Foundation exam you need to have a 65% pass percentage, which essentially means
that 26 out of these 40 multiple choice questions
need to be answered correctly. Here's a more detailed overview of ITIL. As you can see in the tab in the center there is the ITIL master, the ITIL expert, managing across a
lifecycle, which is MALC, and right below there is the Foundation that we are gonna start with. As I mentioned before, there exams are based on
the core volumes of ITIL that deal with aspects
like service strategy, service design, transition,
service operations, and continuing service improvement. More or less this is the scope
of the ITIL Foundation exam, and of course, once you clear this you can choose to clear
the other exams as well. We spent a little bit
of time understanding why ITIL is so popular
across the world, and we also figured out a small story
about the history of ITIL. The next critical question
obviously is to understand what ITIL means in terms of business and how an ITIL Foundation certification and clearing the exam will be invaluable for the organization
that you are serving at. So it is essentially a valuable skill for any IT professional
irrespective of domain, job role, and years of experience you might have. ITIL is ideal of IT professionals who are working within an organization that has already adopted ITIL and enables them to
contribute to an ongoing service improvement program. I do not know of any
organization which doesn't aspire for service improvement, and ITIL provides a valuable framework around service improvement. And an ITIL certified
professional is obviously an asset to an organization that takes
service improvement seriously. ITIL is ideal of IT
professionals, business managers, and business process owners. Of course, it's not
restricted to these job roles, but these are some of
the popular job roles where ITIL certification
makes a lot of sense. It is however important to note that a semi technical
knowledge is desirable if you wish to pursue all
the five levels of ITIL, but the good news is to clear
the ITIL Foundation exam there are absolutely no prerequisites and you can be part of any
domain within your organization and still clear the ITIL Foundation exam. Which is still an important
certification to have and which will be well respected
within your organization. So why is ITIL so successful globally? ITIL sort of lists down these success factors globally. ITIL is successful because it
delivers value to customers through services and improving
customer satisfaction. ITIL aims to integrate
strategy for services with the business strategy
and customer needs. What this essentially
means is the fact that a business might have a set
of services that it sells and it also has in all
probability a business strategy and the third spoke in
the cycle is the customer. It is extremely important that
all three aspects are aligned and the strategy that the
business has is aligned to the services that it
offers and the customer who is the ultimate
beneficiary of these services. It is extremely important
that these three stakeholders are in perfect harmony. And ITIL ensures that they are
indeed in a perfect harmony. ITIL also measures, monitors,
and optimizes IT services and service providers performance, and of course reduce costs. So this is more or less the aim of ITIL, and this is the cart that
drives many organizations to be ITIL aligned. ITIL also tells you to manage the IT investment,
budget, risk, knowledge, and capabilities to deliver services effectively and efficiently. This is an extension of the
previous point where you need, you have a business strategy, you have the all important customer, and you have a suite of services that are tailored to your customers, and it is extremely important that you spend the right amount
of money with minimal risk, leveraging the knowledge and capabilities that your workforce
has to deliver services effectively and efficiently. ITIL enables an option
of a standard approach to service management
across the enterprise. What this essentially means
is that a large organization might have different departments that deal with different
aspects of the strategy, service, and customer cycle and it is extremely important that all of these function together. So ITIL is also a blanket certification that adopts a standard
approach to service management across the enterprise, across the various
departments of the enterprise. By doing this, what does
the organization achieve? Through ITIL it changes
your organization's culture, and supports the achievement
of sustained success. Every organization, big or
small, wants to be successful and once this philosophy is embedded closely to the organization's structure, profits grow by leaps and bounds. Hence, ITIL understands that the role, one of its fundamental roles is to modify the organization's culture to ensure that sustained
success is achievable. Again, a point which is
closely related to this, how does one achieve sustained success, how does an organization
achieve sustained success? By improving the
interaction and relationship with its customers. Customer is king and it
is extremely important that you connect with the customer and customer sees value in your service as well as the interactions
that you have with them. And continually improving the interaction between the business and the customers is extremely important for success. Of course, ITIL is also
tailored to optimize and reduce cost for an organization. Very simply put, ITIL
helps an organization to understand its customers, ensure that you tailor your
services to the customer, and you continually keep
interacting with the customer to ensure that you are aligned
to the needs of the customer. Of course, at an optimal
cost with minimal risk. So this pretty much encompasses what ITIL means to an organization and why a lot of global
organizations big and small have adopted ITIL and have seen results. Having understood why ITIL is important from a certification point of view for any employee within an organization, and having understood why
ITIL as a certification is so important to the
organization itself, it's only fair that we
understand what it takes to clear the Foundation
level of the ITIL exam. Pretty simple process. You register at peoplecert.org. So PeopleCert is the official certification partner for ITIL. So all you need to do is to register and you would be provided a unique ID. You log in, choose your
product from the dropdown menu. ITIL Foundation in our case. Obviously PeopleCert has
other certifications as well. But as far as we are concerned you need to choose ITIL Foundation. Make an online payment of about $195, which at current rates
shouldn't be more than about 13,000 Indian rupees. Once you make the payment after
choosing the certification, which is ITIL Foundation, you get to choose the
batch of your choice. We are now talking about the online option of taking the course. You are presented multiple
options of time slots and you can choose batches
up to four hours ahead. So you have chosen a batch now
and of course nothing left, you can take the exam through your desktop or your laptop computer. 40 questions, one hour. Once you are through it you get an instant score
at the end of the exam, which will be followed
by the certification, the certificate, rather, within 10 days of completion of the exam. Good news of course, once you
clear the ITIL Foundation exam you are an ITIL Foundation
certified individual for the rest of your life. So then, let's start with the
business that we are here for, the first module of ITIL Foundation, which is obviously to understand
ITIL in all its glory. The structure of the ITIL exam
is divided into five modules, starting with service strategy, moving over to service design,
then to service transition, service operations, and the final module which is ITIL continual
service improvement. The pretty much is the scope
and the boundaries within which the ITIL Foundation exam
syllabus is based on. So then, service management as a practice, which is the first module of ITIL, and the second module of our
course here, let's get to it. So service management as a
practice, what does it deal with? It deals with IT service management, which comprises of service,
process, and function. So in any IT services organization, there are three things that
are extremely important for effective service management. A service, a process, and a function. So service management as a
practice takes a deep dive into all of these three aspects, as well as helps you understand what a RACI architecture means, and also gives you an
overview of the tools that can be used for service management. So then, let's understand
how to define a service, what a service means to an organization. In the context of ITIL,
service is defined as a means of delivering value to customers
by facilitating outcomes customers want to
achieve without of course the ownership of specific costs and risk. Let's take a step back,
in order to understand what service management stands for, it is extremely important to
understand the definitions of service and process and the
need for service management. A service is something that
you provide to the customer, and customer sees value
in what you provide. ITIL chooses to describe this as a means of delivering value to customers through your product of
course, or your service, and a service facilitate
outcomes for the customers. And obviously the customer
doesn't want to be at the receiving end of cost and risk. So as far as the customer is concerned, he or she is getting a
service at an affordable cost, and the duty of providing the service and absorbing the risk, lies
with the service provider, in this case the business. So in very simply words, a
service is a piece of value that you give to the customer, where you bear the cost and risk. A process on the other hand is a structured set of activities designed to accomplish
a specific objective. It takes one or more defined inputs and turns them into defined outputs. What does it mean? In the context of ITIL,
if a service is your goal, what you do towards it is a
process or a set of processes. You have defined a service, and that service makes
sense to the customer. The customer believes that
your service is affordable, and any risk and cost differential
that affects the service is the responsibility of the business. Now, how do you make sure that your service reaches the customer? Through a process. ITIL obviously defines this as a structured set of activities that accomplishes a specific objective. The objective in this
case is something which the user or the customer believes will add value the his or her life. So that is the objective. What does it take for this objective to flow from your
organization to the customer. It may take one or it may
take more defined inputs, and provide a very cognitive
defined output to the customer. If service is your goal, what you do towards it is a process. You want to provide a
service to your customer, that is your goal, how do
you do it, through a process. Now, it is also important to understand that the user, which
is who is predominately the beneficiary of your service, is not interested in the process. He or she cares only about
the service or the goal. And the goal will be an organization goal. The process is entirely
interested to the organization and the user or the customer
has nothing to do with it. A process however has four
characteristic features. It responds to specific events. The results are delivered to customers and results are predefined. And of course they have to be measurable. A process is meaningful only
if it meets these four goals. So how is all of it tied
to business outcomes? Again, encapsulating service management, the basics of service
management, you have a service, the customer sees value in it, all the customer is concerned about is what he gets as a service. Of course, for a business
to provide this service, there are processes that
need to be followed. And the process needs to
respond to specific events, they have to be delivered to customers. They have to be predefined. The company or the
organization should have a very good idea of what
services need to be provided to what customer and this
needs to be predefined, this needs to be documented. And of course it has to be
measured at some point of time. A successful process is one
that meets these four goals. The ultimate goal of
course is to make sure that the customer perceives your service as something which is valuable
to his or her business. Having understood what
service and a process mean, let's put these two things
together and understand what service management means. ITIL defines service management
as a set of specialized organizational capabilities for
providing value to customers in the form of services. Very simply put it is a set of processes that provide a service. Service management in other
words deals with the process of providing a set of processes as a service. So then, what is the need
for service management? It is extremely important
for a service organization to ensure that IT service quality keeps improving. And the simple reason
for this is the fact that user expectations evolve,
and for companies of any size there is constant pleasure to provide a higher quality of
service at reduced costs. The second reason, business and technology
changes constantly, and these changes affect
IT systems and processes. And a third reason, competition forces organizations
to push service barriers. Essentially what this means
is there is a strong need to document and have a strategy
around service management because customers
constantly keep evolving. Their expectations change. They are exposed to a lot
of new services and products from the ecosystem, hence their
expectations keep changing and the service quality
of an organization, of your organization,
should always makes sure that these new expectations are met. Parallely, technology keeps evolving, business needs keep changing, and all of these factors
affect service management. The third reason of course,
every business has a USP but obviously there are other companies and organizations out
there that are going after the same customer pool as yours, and it is only a matter of time before somebody else believes
that they can provide the same service at reduced costs. So in terms of service management it is imperative to the
organization to ensure that your service management
caters to competition as well. Going slightly deeper
into service management, let's understand the major
stakeholders in the cycle. To take a step back, there is a service that
you provide to a customer, and you follow a process
to deliver the service to the customer. So who are the major touchpoints? Who are the major stakeholders in the service management lifecycle? Of course, there's the
all-important customer. There is however the user as well. There might be a service provider, and then there's a supplier. Let's now understand what the role that each of these folks play. The all important customer
is obviously the recipient of the services that you provide. The user is somebody
who uses the services, and the service provider helps
you provide the services. It is extremely important
to understand here that there is a very fine
but distinct difference between a customer and a user. Let's take an example. Your IT organization, or any business or
organization that you work for, might be a customer of a
broadband connectivity framework. As far as the provider is concerned, the connectivity provider is concerned, your organization is the customer. However, you are the user. You are an employee of the
organization, of the company, and you are the one who is using the broadband internet
for your day to day work. Your company is the customer,
you are the user, right? In other words the customer
is the recipient of services, while the user is the
actual user of the services. Who is a service provider? A service provider is one who helps you provide these services. Now, service providers are
divided into two categories, three categories, rather,
according to ITIL. There is an internal service provider, an external service provider,
and a shared service provider. Pretty simple to figure out. An internal service
provider is one who provides services within an organization, and external service provider is one who provides services
to external customers, and a shared service
provider is someone who provides IT services to
more than one business unit, mostly internal. Now, and though this might
sound slightly confusing, it is very easy to decipher. Suppose there is a department
within your organization, say an IT department, right? And the IT department
provides connectivity or a laptop to its employees, right? So your IT department is the
internal service provider who provides the laptops to employees. However, if there is an
external service provider who provides the broadband
connectivity framework, so here's a service
provider who doesn't sit within the organization, is a third party. So the third party becomes
an external service provider. And a new sort of service provider that has evolved over the years
is a shared service provider who provides IT services to
more than one business unit. So in large organizations
there are different countries, different geographies,
different departments that a centralized IT team
might need to service. So in this scenario the service provider would be a shared service provider where multiple departments or countries deal with this service
provider for their needs. So now we have spoken about
the customer, the user, the service provider, and the supplier. Interestingly, customers are also divided into internal and external customers. Customers that share the same business are internal customers, while those that have a
completely different business are external customers. Very simple to figure out again. Internal customers are
customers of your own business within the organization. And external customers are
those who are sitting outside your organization and are
beneficiaries of your service. Finally, who is a supplier? A supplier is a third party who supplies specific goods or services. Just to recap and ensure
that we understand these core concepts very clearly, a customer is your business who buys the internet broadband
connectivity framework for you. You are obviously the user. The company that provides the broadband is the service provider, and in case there is a
third party involved, that third party becomes a supplier. With the same example of
internet broadband connectivity, suppose there is a third
vendor who actually comes and installs the fiber optic cable. The cable provider becomes a supplier. That completes the four
fundamental stakeholders of service management,
the customer, the user, the service provider, and in some cases the supplier as well. In order to get the best service or rather the best results from the service management process, there are specific functions
that need to be allocated. These functions can be
people or processes. In the context of ITIL,
a function is defined as an organization that
defines a specific process, an activity, or a combination
of process and activity. Functions in ITIL include service desk, operation management,
technical management, and sometimes application
management as well. So what does this mean? There is a service you're
providing to a customer. There are different
stakeholders, like users, customers, suppliers. Where does functions in
service management fit in? You need to make sure
that the relationship between these four stakeholders
is extremely tight, is extremely interactive to ensure best results
for an organization. Your organization
obviously has spent money to make sure that the right
service reaches the right users using the service of probably a supplier. This cycle needs to be extremely tight, it needs to be extremely
efficient at all times. And ITIL prescribes the
functions of service management to do precisely this. A function could be a
process, an activity, or a combination of a
process and activity. We have already understood
what a process is. An activity is nothing but a minuscule process within a process, which enures that the
process doesn't break. And ITIL prescribes that functions like a service desk, an operations management
department, technical management, or application management will ensure that the right functions are in place and are working efficiently
toward service management. A function can obviously be a role or it can be a process, right? So when a function becomes a
role, ITIL follows something what it calls the RACI
architecture, R-A-C-I. The RACI architecture stands
for responsible, accountable, consulted and informed. R for responsible, A for accountable, C for consulted, and I for informed. At various stages of service management the RACI stages have been
followed, have to be followed, and relevant stakeholders are constantly depending on this structure to ensure that the
organization functions well. Let's take a step back again and understand what a role is before we deep dive into the RACI model. Of course we now understand
what R-A-C-I stand for. It is also important to understand
the definition of a role. A role according to ITIL is an authority given to a person or a group of people to execute an activity. A role is something that you
need to do day in and day out and to a great extent it is a power, an authority that is given
to either a person or a group within an organization, with the aim of executing
an activity efficiently. So RACI stands for
responsible, accountable, consulted, and informed. What do these mean? Responsible, a person or a group of people responsible for getting the job done, or getting a particular task done. The responsibility lies with this person so that person or group
is R in the RACI model. A for accountable. For every task only one
person can be accountable, and that person is tagged as A. For getting a job done, you might need to consult other people. The people who are consulted and whose opinions are
usually sought and respected form the consulted bit
in the RACI architecture. And informed are people
who are kept up to date on a progress made. The RACI architecture
also touches upon the role of various stakeholders within this cycle, within this model, and these stakeholders
primarily are process owners, practitioners and process managers. We will do a deep dive into all of these, but at this point of time
it is extremely important to understand the fine
distinction between R, A, C and I. Suppose you undertake a
project, there has to be someone who's responsible for it
just in case things break. We obviously hope that they
don't, but if something breaks there has to be a particular
team or a particular individual who is responsible for
the state of affairs. And that person or group
is the R in the RACI model. In order to actually
perform the real task, the actual task at hand, there is one person who
is an expert at doing it, and he or she is accountable. Before starting the project
obviously the organization or the senior management would
have consulted a few people whose opinion would have been
incorporated in the plan. And simply these are the folks who make up the C in the RACI model. And of course, informed
deals more with visibility for an organization. Might be somebody who is fairly senior or somebody who takes
care of the operations bit in an organization, who
needs to be informed about any particular job, a project, or a task. Let's now understand this with an example, or rather a typical RACI chart. So there might be a CEO, a business executive, a CIO, a business process owner, a
chief architect, and others, so. Typically job roles in an organization and activities that the
organization undertakes, and how this chart sort of
encapsulates who are the, which are the job roles
that need to be consulted, need to be accountable,
need to be informed. A typical chart, let's
say if we were to create a framework for defining IT services, the business executive will
obviously have been consulted. The CIO is obviously accountable because we are dealing with defining new IT services for the organization. The chief architect should be informed because he or she might be closely linked to the business process owner or the CIO. And the service management
should be part of the R. In this case obviously,
with such an example, it's the ideal scenario where a framework for defining new IT
services has been created and the right person
will have been assigned the right RACI roles. The other things in this
chart obviously refer to other typical projects that an
organization might undertake. Of course, we can go through
each of them in detail, but the idea here is to understand a typical RACI structure
within specific projects in an organization. So who are the key stakeholders
in the RACI architecture? We touched upon this point
a couple of slides back, but now is the time to take a deep dive. There is a process owner, and the role of the process owner is to design, develop, and document processes that meet business objectives. In other words the role
of the process owner is to develop and document processes that are aimed at new business
objectives for the company. Some of the core duties
of a process owner include sponsorship, design, change
management, addressing issues during the time of process execution, providing the right resources to support the service lifecycle, tracking the metrics to
measure the progress, and being accountable for the
process to be fit for purpose. This is what ITIL prescribes to be the role of a process owner. In order to understand
this in simple words, a process owner is someone
who owns a particular process, a service generating process. The whole nine yards of the
service generating process, starting from sponsorship of the process, design of the process, change management that we
will learn about in some time. Taking care of possible issues
during the execution phase. Ensuring that the right
minds and the right teams are part of the service lifecycle for this particular project. Providing the right resources. And of course, extremely important from an organization standpoint
is to measure the process through effective metrics. So all of these are the responsibilities of the process owner in the
service management lifecycle. So now let's understand who
the key stakeholders are as part of the RACI architecture. There is the all important process owner, whose job is to design, develop, document processes that meet business objectives. The duties of the process
owner include sponsorship, design, change management, addressing issues at the
time of process execution. The role is also to provide resources to support the entire service lifecycle, track the metrics to measure the process, and being accountable for the
process to be fit for purpose. So what this essentially means is this, there is a process owner, the touchpoint, or the stakeholder who
owns the entire process, the service development process. The job role includes
designing, developing, and documenting the process. So you provide a set of
services for the customer, and you follow a process while doing this. The job of the process owner is to be entirely responsible for
this process end to end. It is the responsibility
of the process owner to design, develop, and
document the process. And of course, ensure that the process meets business objectives. To break this down, the duties include
sponsorship of the process, designing the process,
ensuring change management. We will be talking about change management in a little while. With role of the process owner
is also to address issues that might pop up during the
time of process execution. So the process owner has
sponsored a particular process, he has designed the process, change management has been taken care of. But while the actual
process execution happens, sudden issues might pop up,
and taking care of these issues is also the job of the process owner. The process owner also
provides the right resources. Which means he or she
has to identify, earmark, team members who are efficient
enough to ensure that the process lifecycle is not affected, the service lifecycle is not affected, and earmarking these resources
for a particular process is the responsibility
of the process owner. Of course, tracking the
metrics, measuring the progress, is part of the role. And also to be accountable
for the entire process to be fit for purpose. Every business has a purpose, and every process has a purpose, and it is the process
owner who is responsible and accountable in ensuring
that the purpose is fulfilled. Who are the other stakeholders? There is a process practitioner
who is responsible for executing one or more process activities. A process cannot exist in isolation. In order to meet business goals
there are multiple processes and it is the job of
the process practitioner to be responsible for
executing multiple processes within one particular goal, or within one particular activity. A process practitioner should possess practical understanding
of the process design, implementation, and operation. So design, implementation and operation, pretty much is a process end to end. And it is the process
practitioner who should have the real practical tactical understanding of the process design,
implementation, and operation. A thorough understanding of
the scope of the project, the key concepts that
encapsulate the process, and the terminology used
in a achieving the result from a particular process
is the responsibility of a process practitioner. Obviously then, the process practitioner should also understand and
implement relationships and interdependencies
with other ITIL processes. As mentioned before, an ITIL process, or any process for that matter,
cannot exist in isolation. And a process process
practitioner has to ensure that he or she has complete understanding on how to make sure that processes work in tandem with each other, multiple processes work
in tandem with each other. Managing those relationships
and interdependencies is a key role of the process practitioner. The process manager on the other hand, is responsible for the
operations of a process in the areas of planning and coordination. A large process obviously
requires intervention from multiple stakeholders and in a scenario where
there are multiple processes, it is extremely important
that these processes are operationally managed efficiently. And the job role of the process manager is to be responsible for
operations management of a process in terms of planning and coordination. A complex process obviously
requires a lot of planning and a lot of intelligence when it comes to coordination between multiple processes, and the process manager should efficiently be able to do this. A process manager should carry, monitor, and report performance of the process to relevant stakeholders. And in case there are
several process managers for a particular process
or a bunch of processes, it is the duty of the process manager be in sync with individual
process management for a large process. The last spoke of a RACI
key stakeholder would be the service owner, who is
responsible for initiation and ongoing support to the
customer in delivering services. So here we have delivered a service, a process has been completed, and now the service owner steps
in and takes responsibility for the initiation and ongoing
support to the customer. Going back to our previous example, you have purchased a broadband
framework from a vendor, from an external vendor, and the external vendor
will have a process by which the vendor ensures that there
is adequate level of service being provided to you as a customer, and as part of this promise, the vendor will have a
service owner who steps in after the implementation has been done to ensure that he or she becomes
the single point of contact in case the customer, which
is you or your business, to ensure that you do not have any issues. And in case you have an issue, the service owner will be
the one responsible for it. The service owner is accountable for specific delivery of a service, and reports either to the service manager or probably a service director, depending on size of the company. The service owner liaisons with the business relationship
manager to ensure that service, the service which has been delivered meets customer requirements. If you have asked for a particular sort of broadband connection, the
vendor has to ensure that the specifications have been met, and the service owner when he takes over, after the implementation,
needs to make sure from his or her business
relationship manager that what, the service that has
been delivered is in sync with what the customer has requested for. The service owner participates
in negotiating SLA and OLA because the service owner
is closest to the customer, and obviously understands
the level of service that can be provided,
and more importantly, in case there is a service or
a service excellence promise that may or may not be
fulfilled by the company, it is the duty of the service
owner to bring this up and ensure that the
SLA is not compromised. And he or she is also an integral part of creating the SLA itself
to ensure that service levels that are agreed are
practically achievable. The service owner again,
since he or she is closest and most intimate to the customer, is also in the best position to recommend process improvement
for his or her company. Here is an example of
a simple process model where as part of process control, there is a process policy,
there are objectives, there is feedback, and there's a mechanism
for product documentation. And then there are process inputs where there are complex metrics. There are process roles
that have been assigned. There are process improvement strategies, and the final step, which
is the process enablement, where the right resources are invoked, and the right process
capabilities are undertaken. In order to achieve service management, every service management or every business can leverage tools for specific tasks within
service management. These include workflow engines,
event management tools, discovery applications,
reporting dashboards, diagnostic tools, content
management systems, self-help portals. Very simply put, these
are some of the tools that a business can use for
efficient service management. These can also be looked
upon as separate departments within the service management
umbrella department for an organization. Workflow engines, management
tools, dashboards, diagnostic tools, that
will help you achieve an optimum level of service management. With that ladies and gentlemen, we have come to the end
of service management, the module on service
management as a practice. And now we move on to the next module, which is service strategy, which is the second core
volume of ITIL Foundation. So let's understand the core
objectives of service strategy. The objectives of core
strategy is to identify the services that the business offers, defining the service
quality for each service, creating an documenting
the value for customers, differentiating value from customers, performing financial management to provide value-centric
visibility and control, and allocating specific resources. So this core volume of
ITIL deals with devising a service strategy. This is the first step in a
service transformation exercise. Every organization that
chooses to transform its service delivery has to embark on a service
transformation journey. And this module of ITIL
deals with precisely that. Before the design,
transition, and operations, it is critical to define
a strategy, right? You have the customer, and
you have a vague idea of the kind of services you
can provide to the customer, and you have a fair
belief that the customer would see value in those services. But before you actually
design, transition, and get into the operational
aspects of a service, it is extremely important
to define the strategy in the first place. It is essentially the
long term service vision and allocation of related
cost and resources. You need to have a long term vision around the suite of
services that you offer. This is precisely the
strategy that you have. It is extremely essential
that you also pay attention to allocation of cost and
the right number of resources to deliver a particular
service or a suite of services. So how do you define a strategy? Defining a strategy is based on a few fundamental requirements. You need to first identify the services, you need to have a very deep understanding of your own services that you
are providing to the customer. You need to then define service quality for each and every particular service. You have a bunch of services and customer obviously
likes these services. You now need to define
the quality of service that you are going to
provide to the customer for each one of these services. You then need to create and document the value that supposedly the customer will get from your service, and you need to differentiate the value that you provide to the customer as against the competitor. Your business has a USP, and you have a competitive advantage. You need to make sure that
this is well documented, and this will go a long way in defining your own self service strategy
and the suite of services that you provide to the customer. It is also important to
have financial management in providing value-centric
visibility and control. You need to figure out how much
you can charge the customer and how much you pay
for your own resources for your business to provide
a service to the customer. Hence, budgeting from the customer's end in terms of affordability and budgeting how much
you are willing to spend on each of your resources to disseminate that particular service to your customer is extremely important. Financial management is
one of the key aspects that ITIL takes very seriously. And then of course
ensuring that you allocate the right resources
for the right services. Within an organization there is a pool of specialized individuals
whose specialties range from strategy to implementation
and everything else. You need to ensure, or
rather ITIL prescribes that you ensure the right job
role for the right person. In other words, the allocation
of specific resources for a specific task or a specific process is extremely important
from an ITIL standpoint. So what is the purpose
of service strategy? The objective or purpose
of service strategy can be encapsulated into
the four Ps of strategy, so what do the four Ps stand for? There is perspective, position,
planning, and patterns. Perspective stands for the
vision and direction of business, the basic vision and direction
that your business believes is of extreme importance to the customer. Position, which is your
core value proposition that differentiates you
from other competitors who operate in the similar domains. Planning, having the
right metrics of business, service provider and customer. Patterns, which might be
repeatable or non-repeatable. Let's take a deep dive into each of these. This is extremely critical
from an ITIL standpoint. The four Ps of service strategy, it is extremely important
for the organization to reach from current state
to goals of excellence. It is extremely important to
have the right perspective. Every business should have a vision and a direction for its business. This is obviously closely
tied to the services that you offer the customer, and the services that
you offer the customer will be based on an internal
vision and a direction that you have set for the
business from your end. Positioning, your business
provides a set of services and that differentiates
you from competition. You have a core value proposition that you believe the
customer is paying you for. It is extremely important to
get this positioning right. This is what will help you
get from a current state to a desired position or a
desired goal of business. The next obvious step is to plan for it. Make a metrics of where you
want your business to be X years from now, X months from now. What is the nature of service providers you are going to collaborate with and how customer requirements are changing and what is the customer
profile that you are after. It is extremely important to plan. The next obvious step is
to figure out a pattern in this journey of providing
service to the customer. There might be certain
tasks that are repeatable, and then there are tasks
that are non-repeatable. It is extremely important
to document these patterns into repeatable and non-repeatable buckets to ensure that there's a
smooth flow of services from your business to the customer. Of late there is also a fifth P which has unofficially been
used by businesses worldwide. This is ploy, so ploy essentially means companies modifying their business goals based on competitor's
strength and weakness. Let's take a step back. The four Ps. You have a perspective, you
have positioned your service, you have planned, and you have figured out
the pattern of business. Now the next logical thing you can do is to do a competitor
analysis and figure out where your competitor is lacking
and hope to fill that gap. Now this is the fifth P, which is ploy. Obviously, the fifth P
which is ploy is not created by Mintzberg in 1994 where
the four Ps were created. The goal of the four
Ps is simply to remain uniquely valuable to customers
for as long as possible, and continually follow the cycle to stay relevant and differentiated. You have to be valuable, you need to continue to remain
valuable to your customer, you need to be a unique value
proposition to your customers. Your service has to become
valuable to the customers and for this to happen
you need to transform your service management
into a strategic asset within the constraints
that you have identified for your business. The four Ps of service strategy is also aimed at
establishing the direction and creating the guiding principle for service management activities across the ITIL service lifecycle by setting goals, policies,
guidelines, and processes and all the while measuring performance across this lifecycle. So then, which are that key
components for service strategy? You now have a strategy in place, you have understood your
customer, you have a USP, you have documented at
length about the services that you are going to offer, what is the next step? Which are those key components
that you need to keep in mind while devising a service strategy? First step of course,
you need a business case. The business case is documentation of a specific strategy, documentation of the cost involved. Identifying the problem
you are trying to solve and encapsulate the risks involved. A business case is the
first step of any strategy, of any business strategy. You need to define your strategy, you need to figure out the costs involved, you need to identify the problem you are trying to solve for the customer, and understand the risks
involved in this process. ITIL defines a business
case as a strategy document with supporting evidence in order to make an informed decision approved ideally by senior management. So the business case is a
document with supporting evidence on what the customer is looking for, how your service is helping the customer, and the goal of the customer
is to make an informed decision and obviously this is a document
that needs to be approved internally by senior management. In order to understand the
very basics of business case you can take a very very simple example right from your childhood. As a child when you wanted
to buy your first bicycle or rather procure a first bicycle, you would have made a
business case in your head, and presented it to your parents. You would have included
data on how much time you would save in reaching school, how the bicycle is going to help you fetch stuff from the grocery store. Basically, in your own head
you had a justification to why you needed a bicycle. And how the bicycle
would solve the problems of you as a user and probably
your parents as a customer. A business case in an ITIL
scenario is only a magnification of this in a business scenario. A business case should be
reasoned, and have a structured details with supporting
evidence and references that justifies the project
on either financial or strategic grounds,
and should be approved by senior management. Just an extension of you
procuring your first bicycle. Within a service strategy,
there are other components. You have now completed a business case. You now have it documented. The next step is to assess risk. And to assess risk it
is extremely important to understand what a risk is. So what is a risk? A risk is an event in the future, a risk is an uncertain condition
that may or may not occur. If it occurs it'll have an impact on the outcome of the strategy. And a negative outcome
of a risk is a threat while a positive outcome
is an opportunity. A risk can have one or more causes, and a risk can be classified
into high, medium, low. Pretty much the dictionary
definition of risk for a business case, or a service strategy according to ITIL, a risk is defined as something
which is likely to happen. Or rather, it is something
that may or may not happen but for any efficient business
it is extremely important to expect that a risk will pop up sometime during the service strategy. It is obviously uncertain
that may or may not occur, but if it occurs it'll
definitely have an impact on the outcome of the strategy. If something has an impact on
the outcome of the strategy it is imperative that it will
have an impact on the business which obviously means that the
customer will be dissatisfied with the level of service
that you're providing him. Though risk is mostly associated
with a negative outcome as a threat, there are times when
there is positive outcome and this can be seen by the
business as an opportunity. For example, suppose your business suffers because of a natural
calamity like a flood. It'll obviously have an
impact on service quality, it'll obviously have an impact on what the customer gets from you. But a positive outcome from all of this would be the fact that you
might be dealing with vendors with whom you have an SLA, a service level agreement
that they haven't met, and in order to continue
their relationship with you, they might actually slash their prices or they might actually give you offers which are extremely lucrative
for your own business. As long as there is minimal
effect on the customer in using and leveraging from your service it is business as usual. A risk is mostly negative, but there are times when
a risk can be positive and can be seen as an
opportunity for your business. A risk can obviously have a
single cause or multiple causes. Risk can obviously be classified
into high, medium, low, depending on the effect it
has on your service promise to the customer, or your
co-service to the customer. Obviously if it is something
that has extremely high impact it is a high risk activity, or if it has negligible effect on service quality as perceived by the
customer, it is low risk. The good news is that the
impact and probability of a risk can be assessed through qualitative and quantitative analysis, and ITIL encourages you
to do precisely this. The process of understanding
the impact and probability of risk through qualitative
and quantitative analysis, again is referred to as risk analysis. And the process responsible
for identifying, assessing, and controlling risk is
called risk management. Two extremely important
terms, risk analysis and risk management, pretty
much self-explanatory. You analyze the risk, the
probability of a risk, qualitatively and
quantitatively, risk analysis. And strategies for managing the risk, identifying, controlling it, the process is called risk management. Now we know what risk is let's
understand what value is. Value lies in the eyes of the beholder. It is defined by the customer, it is ideally an
affordable mix of features, and a perception of achievement
of a particular objective. What is value, as a dictionary definition. Value is something tangible
which somebody receives. Value, the benchmark of value
is decided by the person who is consuming the value. So obviously, it lies in
the eyes of the beholder. In a business scenario, value
is defined by the customer. If the customer feels that the service that you're providing to
him or her is affordable, and it is of some value to the customer, it is good value that are
provided to the customer. A value is ideally an
affordable mixture of features that the customer gets, and the customer perceives
a sense of achievement or reaching a particular
goal or an objective by paying your for that
particular service. We can take a simple example. You want into a restaurant,
you place an order for food, you eat the food, you come back, and what are the chances
that you are going to go back to the restaurant again? Your probability of going
back to the same restaurant is decided by your perception of value that you got from the
particular restaurant. In your own head, how do
you perceive this value? A, do you like the ambiance? B, do you like the food? C, do you believe that
you paid the right food for the amount of, I mean the quality and the quantity of
food that you have had? C, do you believe it
makes sense to go back to the same restaurant
again in spite of having many other restaurants in the vicinity? If you see value in a
particular restaurant you will go back to that restaurant. This is a very simple example
of how value is perceived in a business scenario as well. Specific to an IT organization, value can be defined by
asking three core questions. Which IT services are being
provided to the customer? What is the customer
achieving from these services? And what are the cost of these
services to the customer? Three fundamental aspect. What is the precise service
that you are providing? What is in it for the customer? How does the customer perceive the IT service that they are provided? How much is the customer
paying for your service? Value is defined by these three questions for any IT organization
across the world, of any size. Next step obviously,
how do you create value? It is extremely important to understand the customer's perception of value and how it maps against business outcomes. You are not running a business
for charity of course. And you need to provide
tangible value to the customer, and also make sure that you
have a profitable venture. Let's now understand, or
at least try to understand, a customer's perception
of a service provider and how the customer believes that there is value in your product. It is influenced by four things. The actual attributes
of the service provided, the customer's present
and prior experience with similar attributes, the relative capability
of the service provider's competitors and other peers. And the customer's self-image
and position in the market. This again can be understood by going back to a restaurant example. Which are the particular dishes
that the restaurant serves that you like. You have obviously gone to
other restaurants in the area before going to this
particular restaurant. So what do you like about
this particular restaurant? Compared to other restaurants in the area, how much do you think you value this particular restaurant more? And whether as a customer
I would like to be seen as going to this particular restaurant as against other restaurants. From a business perspective, what is the core service
that you are providing. What is the attribute of the
service you are providing. The customer's present
and previous experience with similar companies like yours, similar businesses like yours. The capability of other service providers. There are other restaurants in your area. How do you perceive value relative to the value that they provide. And the customer's self-image
and position in the market and whether it makes
sense for that customer to buy their service from you. Obviously, you can put
business metrics to this in terms of outcome,
preference, perception, and value finds the most important and central place in this. We can also talk of value by mapping it against gain or loss. If a customer doesn't feel
a strong sense of value that obviously means the customer is not gaining enough from you. What are the gains from
utilizing your service as against what are the losses
from utilizing your service. If the gains are dramatically
higher than the losses, it is a win-win situation
for your business as well as your customer. There is obviously a reference value, which is based on competing services that other businesses provide. And as long as this gap is optimal, it is still a win-win situation for you as a business and your customer. Value is fundamentally
created as a product of two components,
capabilities and resources. And both of these are service
assets for your business. For effective value creation,
both these components must perform optimally. In order for you to deliver
a particular service to a particular customer
or a group of customers, you need two things. You need the right capabilities that you have probably defined
in your service strategy, you have defined in your business case, you know what your strengths are. You may also know what the weaknesses of your competitors are. You know your capabilities. And then you have earmarked
the right resources for the right capability. You have the right bunch of people and you have the right idea. So capabilities and resources, extremely important to
achieve service excellence. Capabilities can obviously
be broken down into, broken down further into
management, organization, process, knowledge, and people. While resources can be broken
down into financial capital, infrastructure, application,
information, and people again. Obviously people form an
integral part of any business and they cut across capabilities
and resources alike. This is just an example to encapsulate how capabilities and
resources are service assets, and service assets are responsible for value creation of your business. Let's now get to the next
aspect of demand management. So what is demand management? ITIL, demand management aims
to understand, anticipate, and influence customer
demand for services. Demand management works
with capacity management to ensure that a service
provider has sufficient capacity to meet the required demand. Let's now try and understand
this in simple words. Suppose you wish to buy air
tickets for your holiday. There is definitely a
trend in air ticket rates. If you were to book your
tickets let's say 45 days or two months or three months
before your planned vacation, obviously the flight fares are low. As you approach your journey
date prices shoot up. But again, if you were
to make a sudden plan and you were to fly
within the next two hours to a particular destination, again the air ticket rates crash. This is demand management
from the airline. The airline understands,
anticipates, and influences your buying behavior for its tickets. If the airline is able fill 80% of its capacity four hours before a particular flight, it makes sense for the
airline to crash the price in the last minute and make
sure that the final 20% off the seats would much
rather fetch a lower price than go empty. This is a very simple
explanation of demand management. Going back to the ITIL
definition of demand management is to understand,
anticipate, and influence customer demand for your service. It is closely tied to capacity management. Again, going back to the same example, if a flight is only 50% full, it makes sense for it to take
a slight beating on profits but make some money off
the remaining 50% of seats to ensure that there is
some chance of break even. So it is closely tied, demand
management is closely tied to capacity management, and ensures that a service
provider has sufficient capacity to meet the required demand. Again, if the airline
were to crash prices, if it were to maintain the
same price 45 days in advance to one hour before the flight, it is not managing its
capacity well enough. If it is able to predict
customer behavior is when there is optimum capacity management. So in the diagram here, there is a demand pattern. There is a service
process that churns along. And then there's a business process that is closely linked too. There is a pattern for demand. There is a capacity management
process that occurs, and then the final delivery of
the service to the customer. Obviously, if there is
good demand management, there is efficient demand management, there are incentives and
penalties to influence consumption and this pattern of business activity continues to roll on and on. The next important aspect here is service portfolio management. So the next important
aspect of service strategy is service portfolio management. Service portfolio management
is essentially an offering or a group of offerings that you sell. It includes offerings
that you currently sell as well as offerings that are expected to roll out in future. Also included is the
retirement service catalog, the service knowledge management system, and many other aspects. Let's first understand this, let's understand this one by one. Service portfolio is a group of offerings that you sell, obviously, so
these are the set of services that you provide to the customer. You have a document that
lists down all the services that you provide to the customer. That document is called
the service portfolio. The service portfolio includes offerings that you currently sell. As well as offerings that you are expected to roll out in the future. A service catalog is a document which is pretty much a menu
card for your business, while a service pipeline
is a plan menu card for your business. The service catalog, the service pipeline, the service portfolio,
all of these are sitting in what is know as a service
knowledge management system. A service knowledge management system is nothing but a collection
of a service portfolio, a service catalog, and a service pipeline. So what is the need for
service portfolio management? What is the goal? The goal is to provide strategic
direction and management of investments into IT service management so that an optimum portfolio of services is continually maintained. If we remember, we spoke about
how it is extremely important to be in touch with the
customer at all times and understand how customer
requirements are changing, how customer expectations are evolving, and how competitors are also evolving. It is extremely important
for a business to ensure that a service portfolio contains
the right set of services, the right mix of services
for the right audience, the right customers. Extremely important from
an ITIL standpoint as well because it is looked at, looked upon as one of the fundamental
steps in service strategy. To document your service
offerings effectively and later on assess the
impact it has on the customer. What are some of the deeper objectives of service portfolio management? The goal, it is to investigate and design, it is to investigate and design, it is to investigate and
decide as to which service to provide based on potential return and accepted risk level. It is to provide an improved
ability for supporting and enhancing business
processes and business services. It is to identify and
define business value provided by IT services. It is to control which
services are offered, under what conditions, at
what level of investment, and to maintain accurate information regarding planned, current,
and retired IT services. Let's understand this one by one. The core objective of
service portfolio management is to investigate and decide which service should be provided based
on potential return and accepted risk level. What does this mean? You have a set of services and
you have a target audience, your customer that consumes your services. The fundamental goal of
service portfolio management is to decide which service
should be provided, to what kind of customer, and this is possible only if you have listened to your customer
in the first place. You should also figure
out the potential returns that you are getting from the customer and ensure that the
risks that your business is going through in order to
achieve that particular goal is within accepted limits. The goal of service portfolio
management is also to provide ability for supporting and enhancing processes and business services. For the clock to keep ticking
it is extremely important that you keep oiling the right parts. For a business to be successful,
for a business to sustain it is extremely important to
keep updating internal systems to ensure that the customer
is continually happy. The role of service portfolio management is also to define the business value provided by IT services. The perception of value changes
from customer to customer as we have figured out by now. It is also important for the
business to find a pattern of specific types of
customers who might feel a specific perception of value. To identify this value,
and to define the value against IT services that you provide, is something that service
portfolio management deals with. Service portfolio
management also deals with controlling the services that you provide and with what level of investment. Obviously everybody
goes through inflation, every business is a victim of inflation. At the same time, if the customer feels that you are not delivering
value for the money he or she shells out, there is a mismatch. The goal of service portfolio
management is to control and understand the
circumstances and figure out the level of investment if at
all it needs to go up or down depending on customer feedback. Since customers are ever evolving, and their expectations
are ever evolving as well, it is extremely important to
maintain accurate information about planned, current,
and retired IT services. You need to plan for new
services to be rolled out. You should also be prepared
to roll back certain services that you have rolled out in the past. And there might be circumstances
where a particular service doesn't make sense to the customer anymore and the business should
not have any reluctance in pulling it out of the service catalog. So this is an integral part of service portfolio management as well. Some strategic questions you need to ask. Why should a customer buy your services? Why should they buy
their services from you? What are your pricing
of chargeback models? What are the strengths and weaknesses, priorities and risk of my business? And how should the resources
and capabilities be allocated? Once you are able to
answer these core questions it is only a matter of
time before you have an extremely good
looking service strategy. A service knowledge
management system functions. Imagine it as a bucket that
contains the service portfolio, we know what a service portfolio is. There's a service pipeline. We know what that is too as well. And then there's a service catalog, and then there's a list
of retired services. The service lifecycle cuts
across service pipeline, service catalog and retired services, and touches upon aspects
like service status, requirements, analysis, approval, development, build, test, release, and other processes. At the end of it,
obviously the beneficiary the all important customer. The next aspect within
the service strategy is financial management. In ITIL the goal of financial management is to optimize the cost of IT services while taking into account
quality and risk factors. The analysis balances costs
against quality and risk to create intelligent metric-based cost optimization strategies. It is defined as providing
cost effective stewardship of IT assets and the financial resources used in providing IT services. The goal here is simply to
secure an appropriate level of funding in delivering IT services that support the strategy and are aligned to the goals of business. The key is to ensure that the business, directly or indirectly, does not commit to services
that cannot be delivered on time or at a particular cost. Going back to the fundamentals,
you have a suite of services that are provided to the customer. You have understood the
customer well enough to fine tune your services
every now and then to ensure that there is a high, you have fine tuned your
services to ensure that there is perception of high
value from the customer side. The next logical step obviously is to build financials around it. The next logical step obviously, the next logical step obviously is to have a financial management
framework around your services. You obviously have to optimize
the cost of IT services while taking into account
quality and risk factors. Quality, under no circumstances
can be compromised. The customer's perception
of value cannot go down. If it does, your business
suffers, it's a simple equation. So what do you need to do, you need to optimize the
cost of your IT services and you need to remember that
quality cannot be compromised and risk factors also have to
be taken into consideration. Financial management also deals with enabling the organization,
enabling your organization to account fully for the
spend on IT services. You obviously spend on IT services. You spend X dollars a month
or a year on IT services to ensure that the right services
reach the right audience, the right customer. And you need to, every dollar
should be accounted for. Financial management, according
to ITIL, is defined as providing cost effective
stewardship of IT assets and the financial resources
used in providing IT services. A business needs to be cost effective. A business also needs to invoke the right financial resources, and it should provide
the right IT services. Financial management encapsulates all three of these pillars. The goal is obviously to secure an appropriate level of funding in delivering IT services
that support strategy and are aligned to goals in business. The goal is obviously to ensure
that you are able to secure an appropriate level of
funding in delivering the right IT services that
support your business strategy and are aligned to the goals of business. You need to earmark the
right amount of money to ensure that your business goals are met and your business strategy is in sync with the goals of business. So what is the purpose
of financial management? The purpose is simply to
secure an appropriate level of funding in delivering IT
services that support strategy. That we just spoke about. It also to ensure that
the IT service provider does not commit to services
that cannot be delivered. Service level agreements
are extremely important. You need to ensure that
your service provider, or even your vendor, does
not commit to services that cannot be delivered. You obviously will not be
a happy man or woman if you have a service provider
that does not stick by his own commitment to the
level of service quality. That holds true for your business as well. You need to ensure that to your customer you do not commit to services
that you cannot deliver at a given time or with the
optimum level of service that is expected out of you. Your financial management
framework should also identify and ensure that there's a balance between cost, quality, supply and demand. There is a cost involved
for your business to provide a particular service. From the customer standpoint there is a quality of
service that is expected. For your business you need to anticipate how your customer base is going to grow. The goal of financial
management is also to identify a fine balance between cost,
quality, supply and demand. For your service there is
obviously a cost involved. You spend X dollars to create
that particular service. From a customer standpoint
there is expectation of a service quality, a
certain service quality. You need to supply the service based on demand from the customer. Cost, quality, supply, demand. There has to be a fine balance, and things have to function in harmony, and that is one of the core principles on which financial management operates. What is the scope of financial management? It is to control and manage
the overall IT budget and enable the fair and
equitable recovery of debts for provision of IT services. You need to control and
maintain an IT budget for your organization to ensure that you are able to cut
costs, enhance quality, and meet supply with adequate demand. You also need to monitor
targets of expenses and billing customers
for services provided. Your perception of value
should never go down. You need to bill customers
to the extent to which they believe they are
paying the right price, and you also need to make
sure that your expenses in order to provide that
service do not suffer as well. You need to make forecasts of expenditure. You need to optimize costs
by reducing external clients, making capacity analysis, et cetera. There are processes involved
within financial management to help you make futuristic forecasts of expected expenditure with
the goal of optimizing costs by reducing charging clients
and make capacity analysis. Financial management can
be summed up as A, B, C, accounting, budgeting, charging. ITIL makes this very simple for us. As far as financial
management is concerned all you need to remember is A, B, C, accounting, budgeting, and charging. Accounting calculates the
cost of IT service provision. It ensures that the actual
spend can be compared with the predicted spend at any time, and that the account for the
money spent in IT services for a given period is encapsulated well. Accounting simply deals
with calculating the cost of the service that you provide. You have to account in order
to ensure that the actual spend can be compared with the
predicted spend at any time. If you remember we have predicted cost, we have predicted value. We have to ensure now that
what you have predicted is pretty much in sync with
what your actual spend is. You also need to account for the money that was spent in IT
services for a given period. You have obviously invested
in IT to ensure that your services are up to the mark and is perceived as high
value from the customer. We have to account for the money that we have spent in IT services. Second point, after accounting, budgeting. Predict the amount of
money required to run IT services for a given period. Accounting and budgeting
are pretty much closely tied to each other, but while
accounting deals with the actual amount of money spent to reach your service to the customer, budgeting has to do with
predicting the money that you need in the future
to run these services. Obviously your service catalog
might have new services, might have older services
that have retired. Obviously budgeting changes
as and when these happen. The third part of financial
management, which is charging, after A, B, comes C. Accounting, budgeting, and now charging. It is applicable only for customers internal to the organization. So what does charging mean,
it acts as an incentive to the provider and provides
leverage to the customer who can demand value for money. It is an incentive that
can be used as a leverage for customers who can
demand value for money. Let's understand charging now. Charging enables an organization
to recover the costs of IT services from the
customers of the service. It operates the IT services as
a business unit if required. You have accounted for your service, you have budgeted for future business, now you need to charge accordingly. Charging is the closest
touchpoint to the customer. It is the customer who
is shelling out money for your service. And obviously your charging
mechanism should provide enough leverage for the customer who has the right to
demand value for money. Charging also deals with enabling
an organization to recover the costs of IT from the
customers of the service. As we all know we do not
run businesses for charity. And we need to ensure that we
make money out of the customer and by providing the services, by providing the right
services for the customer, and in the bargain make a profit as well. Charging simply deals with
making money from the customer to provide perceived value and
make profit for the business. Before we end the module
on service strategy it is also important to discuss BRM. So BRM stands for business
relationship management. The business relationship
management process within ITIL is defined as the process where
you establish and maintain a good relationship between
the service provider and the customer. How do you do this? Simply by understanding
the business drivers for the customer. The need for BRM is to ensure that something called the watermelon
syndrome does not appear. Before we end the module
on service strategy it is extremely important to
understand what BRM stands for. BRM is an important aspect of ITIL and it stands for business
relationship management. It's a process where you
establish and maintain a good relationship between
the service provider and the customer. How do you do this? By simply understanding
the business driver for the customer. BRM is a pretty interesting concept. The need for BRM is to
ensure that something called the watermelon syndrome does not occur. So what is a watermelon syndrome? All of us know what a watermelon is. A watermelon is green from the outside and red from the inside,
pretty much like a customer, where the SLA looks green and attractive but the customer is bleeding red inside. While metrics may indicate
a successful relationship the truth may be that he
isn't so happy after all. So there needs to be a
touchpoint from the business to get the real picture. What we understand from
the watermelon syndrome is pretty much what ITIL
explains as purpose of BRM. The purpose of BRM is to provide
guidance and best practice on planning, developing, and management. The purpose of BRM is to provide
guidance and best practice on planning, developing, and
managing business relationship between internal and
external IT service providers and their customers. The purpose is also to
identify customer needs, and assist the customer in understanding the value of services. The scope of BRM focuses on achieving end business
objectives and success, and it is concerned with
customer satisfaction. Going back to the watermelon example, there's no point if
your business perceives that everything is fine,
everything is hunky dory, the watermelon looks good from the outside but the customer is actually
bleeding red from the inside. SLAs have to be extremely clear, but it is also important
that SLAs are met, SLAs are realistic, and SLAs are tangible. Business relationship
management deals with striking this balance of
expectation and reality. It provides guidance and best practice on planning, developing, and
managing business relationships between IT service providers,
probably an external vendor, and also the customer. You're a business, you're
providing a service to a customer with or without the help
of a service provider. Value should not diminish in
this cycle, in this process. This is all that BRM says. You have to focus your
attention on achieving end business objectives
and success because this is precisely what your business is going to be judged upon and the all important
customer has to be satisfied. So BRM is centered around
customer satisfaction in ensure that what you
promise is what you deliver. So after a service strategy is in place complete with risk and value assessment the next step is obviously to
curate your suite of services. This operation is called service design. It is essentially the
blueprint of the service you wish to offer. It is conceptualized based
on scalability, redundancy, and continuity in order to ensure that the suite of services is sustainable. ITIL defines this as
the module that focuses on the design of IT services
and covers the architecture, processes, policies and documentation that will enable you to design services that meet the needs of the
organization or the program. Very simply put, this is obviously the blueprint
of your service offering. Obviously the goal here is also to design efficient and effective processes, and for subsequent lifecycle processes. Service design has to
identify and manage risks and it has to design measurements,
methods, and metrics. ITIL defines this as the
module which is the next step, the next logical stage
after service strategy. You have a strategy in place, now you build services around it. You ensure that you
have the right blueprint for your business to ensure
that your set of services reaches the right audience,
the all important customer. So what is the scope
of service management? It is new services, changes
to existing services, or improvements of existing services. No explanation required here. You can have an entirely
new set of services or an entirely new service
that you have added based on user feedback, customer feedback. You might have modified
an existing service or a bunch of existing services, again based on customer feedback. And of course as any
good business should do, should continually do, you improve your existing
suite of services. So what are some of the core
values that service design provides for the business. Provides reduced total cost of ownership. It provides reduced total cost of, it provides reduced
total cost of ownership. It provides improved and
consistent quality of service. Faster implementation of
new and improved services that you have figured out. Very importantly, it ensures
that your new bunch of services are aligned to customer needs and they are also aligned to
the other service offerings that you provide. It is extremely important that
when you launch a new service it is in sync with both
what the customer needs as well as your existing
suite of services. The customer might
actually ask for an upgrade from a specific service
that they are provided, from an existing service. And it is extremely important that your new bunch of services are based on your existing set of services to ensure that the customer
is able to migrate seamlessly. You need to improve the
governance around your services. You need to ensure that the new services are performing optimally. And that they are an upgrade to the existing set of services. And at the end of the day,
since you are running a business and that business is not for charity, you need to make sure that
your new bunch of services enable better decision
making for your business. ITIL has prescribed, ITIL
has divided service design, ITIL has defined the four
fundamentals of service design as the four Ps of every
service organization. People, processes, products, and partners. Though people are an integral
part of any organization, when it comes to services,
the business is more dependent on the process rather than people. It is more important for an organization that even if people break,
the processes don't. So the four Ps of service
design as prescribed by ITIL, people, process, products, and partners, with service management as the end goal. An important aspect of service design is the service design package, or the SDP. The SDP follows the lifecycle of a service from when it was first
suggested as a possibility to when it finally retired. It is a central reference point for all the documentation of a service. Very simply put, the
service design document, very simply put, the
service design package is a significant document
defining all the aspects of an IT service and its requirements through each stage of its lifecycle. A service design package is
produced for each new service, each major change in a particular service, and retirement of a particular service. The SDP, the service design package, follows a simply cycle
of business requirements, service design, organizational readiness, and a service lifecycle plan. Let's try and simplify this. You now have a fair
idea of the new services that you wish to offer. You now document it in a
service design package. It defines all the
aspects of the IT service and its requirements through
each stage of its lifecycle. Every IT service has a lifecycle. It has to follow the right processes in order to meet customer demand and to perceive high
value from the customer. So the service design package
requires you to document every new IT service that you create, or based on user feedback,
based on customer feedback, if you were to make a major
change in an existing service that has to be documented
in the SDP as well. And in case, based on
customer feedback again, you decide to retire a particular service or a suite of services,
the service design package should contain all the
information around it. The SDP, so the service design package, so for the service design
package to be effective, you need to encapsulate
the business requirement, the service design. You need to assess
organizational readiness in order to roll out a particular service, and you need to have a service
lifecycle plan in place before an SDP can be effectively used. The next important step
is design coordination. The next important step in service design, design coordination. What does it do? The role of design
coordination is to ensure design consistency of new
or changed IT services, service management information
systems, architectures, technology, processes,
information, and metrics. In simple words, design
coordination is now responsible for coordinating the design activities carried out by other
service design processes. We now know that service design deals with creating new services, retiring old services, or
updating existing services. Having done that, design
coordination comes in to coordinate these activities, and linking it closely to the business and the objective of the business. Design coordination ensures
that all the processes in service design follow
a consistent design and is aligned to the
requirements of service strategy. And service strategy
obviously is tied closely to the business, and hence
design coordination ensures that service design is closely linked to business objectives as well. Design coordination also
deals with ensuring that the SDP is produced and handed over to a service transition as agreed. After you have created a design your organization has to invoke a team that performs service transition. The role of service design
is to design, retire, or update your suite of services and pass it on to the service transition for them to actually go and implement it. Design coordination ensures that aspects that have been
mentioned in the SDP are handed over effectively to
the service transition team. Of course, design coordination has the goal to improve the effectiveness and efficiencies of
service design activities. For any business it is extremely important to keep listening to your
customer for feedback, for suggestions, and incorporating them into your suite of services. Improving the effectiveness and efficiency obviously is an integral
part of this process and design coordination hence
has a huge role to play. So what is the scope? Assisting and supporting each
project, or any other change through all the service design
activities and processes. Maintaining a guide, maintaining a document with
policies, guidelines, standards, budgets, models,
resources and capabilities for service design
activities and processes. And ensuring that all requirements are appropriately addressed
in service design, particularly utility and
warranty requirements. One thing that ITIL strongly
recommends is to document every step of service transition all the way from current state
to excellence of business. Even with service design, ITIL
prescribes that you maintain documentation around policies,
guidelines, future plans, even warranty agreements and
SLAs with partners and vendors. Let's now talk about
service catalog management. Service catalog is an integral part of the service transformation. The aim of a service
catalog is to ensure that all services that are being transitioned or transitioned into production
are encapsulated well. It is a critical stage of
documentation for better clarity and future planning
initiatives for the business. The role of service catalog
management very simply is produced, protected,
and maintained backup. And encapsulating accurate
information on all services live and those ready for deployment. You might have services
that are already live, you might have services
that are in the pipeline. It is extremely important that all of them find a place in the
service management catalog. We now need to understand what a service level management is. What is the role of
service level management? It is to define, document,
agree, monitor, measure, report and review the level of IT
services within your business. To improve the relationship
and communication with businesses and partners. To ensure specific and
measurable targets are developed for all IT services. Monitor and improve customer satisfaction. And provide cost effective
proactive measures to improve service level even
though targets are achieved. Very simply put, service level management has to ensure that you
have accurately documented and you continue to monitor
the IT service initiatives that you have taken up, whether it is creating new
services, retiring old services, or updating existing services. You might have partners,
or vendors that you use that you leverage from
in order to ensure that your service reaches your customer. And you need to ensure that there is a good working relationship and a relationship based on
communication and interactivity between your business, your partners, and probably your vendors as well. You need to monitor and
improve customer satisfaction. This point keeps coming
back over and over again. Because it is extremely
important from an ITIL standpoint to keep listening to your
customer, take feedback, and incorporate feedback into your future initiatives of business. Let's now try and
understand the service level management process, or as it is called by, as it is referred to by ITIL, the SLM. We first need to understand
the definition of and SLA, or a service level agreement. So what is an SLA, it
is an agreement between an IT service provider
and the external customer. Pretty simple, you are
the IT service provider, you have the customer, and an SLA is simply an agreement
between the two for you. A service level agreement
describes the IT service, documents service level
targets, and specifies the responsibilities of
the IT service provider and the customer. The customer perceives a
certain value of your business, is willing to pay X dollars
for that particular service, now it is your duty as the business that is providing the services, to ensure that there is an
agreement between your business and the customer in terms of the service that you are going to
provide to the customer. The interruptions that the customers should and should not expect,
and your responsibilities as a service provider to your customer. There are different types of SLAs, there are customer based SLAs, service based SLAs and
multilevel based SLAs. All IT services that are
delivered to a particular customer as agreed, falls understand
the customer based SLA. You might be providing an
IT service to the customer, and you are providing
it abiding by the rules that you and your customer have agreed to. This is the customer based SLA, this is a service based
SLA which relates to a specific service
delivered to a customer. You might be providing
one particular service to the customer, and you may or may not have invoked the services of a vendor but if it is a service,
a long term service, and not something
tangible that the customer can take away immediately, it
becomes a service based SLA. Suppose you have multiple
customers or a large organization which is your customer, and there are multiple touchpoints
within the organization, the multilevel based SLA comes into play. Which is essentially a single agreement which covers a single corporate, a service, or multiple customers. It is also important
in the context of SLAs to understand what an OLA means. An OLA is nothing but an
operation level agreement which is an agreement between
an IT service provider, and another part of the same organization. For example, the IT service provider and the procurement
department might have an OLA to decide agreed timelines
of hardware rollout. This simply means that
within an organization a particular department
might have set SLAs for the rest of the organization. The IT department or the
procurement department within your organization,
within your business, might also have an SLA with
the rest of the business to ensure that hardware
components are delivered and refreshed in time. The final part of service level agreement is something called
underpinning contract or UC. This is essentially a contract between an IT service
provider and a third party. The third party provides good or services that support the delivery of
an IT service to a customer. Going back to what we have learned, one of the fundamental things we learned, there is your all important customer, and then you provide
services to the customer, and you might have the need to invoke a service partner or a vendor. The agreement between
you as a service provider and a third party is a UC. The contract between a third party vendor and you as a business is a UC. It is also important to understand from a service level management process the various activities that go into SLM. There are a bunch of activities that need to be followed diligently and ITIL prescribes these activities as first, designing SLA
frameworks, identifying SLRs, that stands for service
level requirements. The next step is to agree and document service level agreements, after which you need to
negotiate and document OLAs and UCs, if any. The next step is to monitor
service performance against SLA, this is an extremely important part where once you have created SLAs
and you have prescribed OLAs or UCs, it is extremely
important to keep monitoring and ensure that they operate in sync. The real service performance
as against prescribed SLAs should always be in sync,
they should always have a meaningful, should always be in sync. Of course as a business
you need to measure and continually improve customer
satisfaction guidelines. Of course as a business
you need to measure and continually improve
customer satisfaction. You need to procure service reports, and service reports are
documents that will help you ensure that what you have
promised in your SLAs is exactly what you are
offering to the customer. You need to review and revise
SLAs, OLAs and UCs regularly since customer expectations change, customer's perception
of value might change depending on competition that pops up. So it is extremely important
to keep revising SLAs and of course to develop new
contracts and relationships as business grows. The next important aspect here
is availability management. ITIL availability management
aims to define, analyze, plan, measure and improve all aspects of availability of IT services. Availability management is
responsible for ensuring that all IT infrastructure,
processes, tools, roles, are appropriate for the
agreed availability targets. The core objective of
availability management is to maintain an up to
date availability plan. We will talk more about
the availability plan in detail later but for
now we need to understand that availability management
is an important stage, service management that deals
with defining, analyzing, planning, measuring, and
improving the availability of IT services within an organization. So what is the purpose
of service availability? It is to ensure that, so what is the purpose of
availability management, it is simply to ensure that the level of service availability matches
the current or future needs of business in a cost
effective and timely manner. The scope of availability
management covers design implementation,
measurement, management, and improvement of IT services
and component availability. In order for your business to
provide satisfactory services to the customer, and to
ensure that the customer continually feels that you are providing good value to the customer, it is extremely important to ensure that your own IT backbone is, your own IT backbone functions flawlessly. The idea of availability
management, according to ITIL, is to ensure that the
right IT infrastructure, the right IT backbone, that matches current or future
needs of your own business, is procured in a cost
effective and timely manner. There are four aspects of
availability management. Availability, reliability,
maintainability, and serviceability. Pretty simple explanations
here, pretty easy to pick up. Availability is the ability of an item to perform as required. Reliability is ability of
the same item to perform for an extended period of time. Maintainability is availability
of an item to bounce back to normalcy after a failure. And serviceability is
the ability of the item to be serviced by a third party with agreed timelines
and scope of service. The concepts of availability
is based on a few principles like high availability,
continuous availability, continuous operation, and fault tolerance. Let's understand these
concepts one by one. Designing of availability. Availability identifies, ITIL
defines high availability as an approach or design
that minimizes or hides the effect of configuration item failure from users of an IT service. Continuous operation on the
other hand is an approach or design to eliminate planned
downtime of an IT service. Continuous availability
is an approach to design and achieve 100% availability. And fault tolerance is the
ability of an IT service or any other configuration
item to continue to operate correctly after failure
of a component part. ITIL understands the fact that
things are bound to break. IT backbones will get injured. But availability takes
care of these lapses through high availability,
continuous operation, continuous availability,
and fault tolerance. Four ideologies that are
pretty simple to understand. High availability is
when a design minimizes a particular fault or an expected fault. Continuous operation is to
ensure that no breakdown of IT affects business, business
should go on as usual. Continuous availability talks about consistency of IT services. And fault tolerance is the
ability of an IT services to bounce back if a fault
or interruption occurs. The next important aspect
is IT security management. IT security management
from an ITIL standpoint aims to ensure the
confidentiality, integrity, authenticity, and availability
of an organization's information data and IT services. It is extremely important to understand the fine distinction between these terms, confidentiality, integrity, authenticity. We also need to remember that
here we are not talking about tangible services, or tangible products, we are talking about data, particular data that is
intrinsic to your business. The data that helps in creating services that ultimately reaches your customers. Every organization, big and
small, will obviously have a large amount of data
that has been procured from interactions with customers. Information about specific
products and service offerings, data around planned initiatives for better customer satisfaction,
and a lot of other data. IT security management
is modeled to ensure that all of this data is safe. Coming back to confidentiality,
integrity, and authenticity. Confidentiality simply
means that data should be accessed only by authorized personnel. Integrity says that a security
rule must be put in place which ensures that data
and configuration items are modified only by authorized personnel. More importantly,
integrity deals with having accurate answers to possible
causes of modifications such as hardware failure,
environmental causes, human error, among others. Availability is the (mumbles)
means the reliability, maintainability, serviceability
and performance of IT as measured against
promised service levels and actual downtime. Confidentiality ensures
that all of your data should be secure and the right data is accessed by the right people and in other words data should be accessed only by authorized personnel. If it is accessed by personnel
who are not authorized to view that particular data it is obviously a security breach. Integrity on the other
hand deals with having accurate answers to possible
causes of modification. If a particular piece of
data has to be modified, updated, changed or deleted,
it needs the approval of authorized personnel. Data integrity is a buzz word
which is extremely popular in the context of security management. Integrity of data is extremely important for future business growth as well. Every piece of data has, every piece of data needs to be accessed only by the right people and if modification of
those data needs to be made, the right approvals have to be in place. Data obviously needs to be authentic. Data obviously needs to be authentic because data is the truth. There is no two versions of the truth. Data is the truth and
it is the truth on which businesses are built and
future plans are made. Hence, authenticity of
data cannot be compromised. In accordance with ISO 27,000 guidelines the ITIL security
framework prescribes that organizations should follow the plan, implement, evaluate, learn,
in a controlled environment. Very simply put, the IT
security management process can be broken down into four. Plan, implement, evaluate, and learn. Planning simply refers to
creation of documents such as service level agreements, contracts, operation level agreements,
and policy statements. The next obvious step after planning is obviously to implement
what you have documented, classifying and registration information, personal security, physical security, network security,
management of access right, security incident procedures. So these are extremely important
steps, or rather sub-steps within IT security
management that deals with the actual implementation
of security policies. After you have planned and
implemented your policies, the next logical step is to evaluate them, have internal audits, external audits, security incident audits, to ensure that what you have planned and what security management frameworks you have implemented are
tested, are tested effectively to ensure that there are no leakages. Having planned, implemented and evaluated, you need to learn. You need to learn from the cycle, you need to improve
your security framework, you need to learn from it, and you need to implement and keep, you need to improve, you need to learn, and you need to implement
it in the future. And the cycle continues
over and over again. Plan, implement, evaluate, learn, four important aspects
of security management that functions in a controlled manner within your business organization. And ITIL prescribes that your
security management framework follows the plan, implement,
evaluate, learn process in a controlled environment within your business organization. The next core aspect of
security management is, the next core aspect
is capacity management. ITIL capacity management
aims to ensure that the capacity of IT services
and the IT infrastructure is able to deliver the
agreed service level targets in a cost effective and timely manner. It encompasses both hardware and software. According to ITIL the objectives
of capacity management are to produce and maintain
appropriate capacity plans, provide advice and guidance on capacity and performance related issues. Ensure service performance, ensure that service performance, ensures that service performance
achieves agreed targets. Assists on diagnose on
capacity related issues. And assess the impact
of changes to capacity. Capacity has more to do with the future in terms of readiness
for increasing demand. It is essentially a balancing
act between supply and demand and costing and resources. The very simple way of
understanding capacity management from an ITIL standpoint
is to understand that capacity management
plays, is to understand that capacity management
essentially is the balancing act between supply and demand. Your IT department provides
the right resources to help you create services
for your customers. Customers on the other
hand demand for services. It is the job of capacity
management to ensure that there is enough, it is the
job of capacity management to ensure that the customer does not feel, that your business does not suffer because of lack of quantity of services that you provide to your customer. Capacity management is
also a balancing act between cost and resources. You charge the customer for
a service that you provide. You also need to pay, you
also need to pay your, you also need to pay,
you also incur a cost in creating those services. Capacity management ensures that you make enough money from the customer, and you effectively spend, and you efficiently spend
on creating the services in the first place. Of course, you are not running
a business for charity, you need to make money. At the same time, you cannot
afford to dilute the perception of value in the eyes of
the all important customer. Capacity management according to ITIL, the objectives are to produce and maintain appropriate and up to date capacity plans. Ensure service performance
achievements meet agreed targets. And assess the impact of all charges, and assess the impact of
changes from capacity. There are three sub-processes
within capacity management. These are business capacity management, service capacity management, and component capacity management. A simple understanding
of these three terms. A very simple way of
understanding these three terms is to understand that
business capacity management has to do with forcing
future business requirements of IT services and infrastructure. Service capacity management
is to ensure business as usual for existing IT services
and infrastructure. And component capacity management
is to manage and control performance of individual IT components. Based on customer feedback your business obviously has
to plan for future business, and creating new services requires support from your existing IT infrastructure. The plan for future
requirements of IT services and IT infrastructure falls under business capacity management while ensuring that the engine
keeps running is the duty of service capacity management, while component level capacity management and ensuring that individual components, ensuring that the performance
and utilization of individual, utilization of individual
components is optimum is the duty of component
capacity management. Let's now move over to
the next core aspect, which is IT continuity management. IT continuity management
fundamentally aims to manage risk that could seriously impact IT services. Continuity management ensures
that the IT service provider can always provide minimum
agreed service levels by reducing the risk from disaster events to an acceptable level, and planning for the
recovery of IT services. This encompasses every
from natural calamities to terrorist attacks. The objectives here are to
maintain a set of continuity and recovery plans, ensure
that after a calamity services can be restored
within the agreed timelines. Ensure that there's a
continuity plan in place to meet or exceed business targets, and negotiate and agree service
contracts with suppliers. Continuity management is
simply as the word suggests a mechanism by which the
business rolls along as usual. For this to happen, rolls along as usual. Of course I established
before, every business operates on the truth that faults will happen, risk can be expected at any time, and continuous business might suffer due to external or internal factors. The role of IT continuity, the role of IT continuity management that there is a recovery plan in place. If and when IT and
service facilities falter the IT continuity
management can be invoked in order to get things back to normal. It ensures that appropriate
continuity plans are documented and in place to meet business targets
and possibly exceed them. Continuity management
for large organization may require intervention
from a third party and IT continuity management
department has to make sure that service level
agreements and negotiations with suppliers and solution
providers are documented well. IT continuity management
from an ITIL standpoint deals with two core components, risk assessment, and
business impact analysis. Risk assessment deals with
initial steps of risk management, analyzing the value of
assets to the business, identifying threats to those assets, and evaluating how
vulnerable each asset is to those threats. Risk assessment can be
quantitative or qualitative. Business impact analysis on the other hand is the activity in business
continuity management that identifies vital business functions and their dependencies. These dependencies may
include suppliers, people, other business processes,
IT services, et cetera. These requirements include
recovery time objectives, recovery point objectives, and minimum service level
targets for each IT service. Essentially what ITIL
has done here is to give a slightly technical framework
to IT continuity management and dividing it into risk assessment and business impact analysis. Obviously by now we
know that every business has a certain risk associated with it, a certain risk associated with it. It is extremely important
to assess the risk as and when it happens, to enable businesses to forecast risk. And if a risk were to occur
do a business impact analysis to understand how impact of this nature can be prevented the next time around. With this we come to the
end of service design. And the next module of ITIL Foundation is service transition. Service transition is the
process of building and deploying new or modified services. Service transition encompasses two things, a new service or product that
your business has created that needs to be delivered to production. Your customer has migrated
from a competitor to you and you need to ensure a smooth transition of your customer's business, on time with the right kind of quality, with the right resources. This is what service
transition is all about. Service transition needs to ensure that the right mix of technology
and applications are used to deliver business value. It needs to ensure that
you are able to identify the right personnel for the transition. And you need to ensure that
minimum unpredicted impact to business is done. You also need to use
service management practices to ensure minimum distraction
during transition. Let's try and simplify this concept. We now know obviously that
the customer has choices. You have provided some
value to the customer but there is competition lurking
around, and every now and then the competition might out score you, and if you are lucky and if
your business plans are in place you might be a better
choice for your customer than a new competitor or an existing one. In such a scenario it
becomes slightly complex for your customer to migrate from an existing service provider to you. This is where service transition comes in. The objective of service
transition from your end, from your business end, is
to plan and manage resources to establish new or changed
service into production. Though this might sound
like an easy thing, planning and managing resources that have enough know-how about
your service portfolio is slightly challenging. According to ITIL, service
transition also needs to ensure minimum unpredicted impact to business. For everybody, business
is money, time is money, and we need to ensure that
your business does not suffer while you are helping a customer
migrate to your business or your service offering. At the same time, you also
need to make sure that you do not impact your own business because you are migrating
somebody else onto your platform. You need to ensure that you
use the best of technology, you use the right
technology and applications to deliver services that obviously brings value to customers. And the aim of service
transition according to ITIL is also to enhance service
management effectiveness through service transition practices that we shall talk about in some time. Now let's understand the purpose and scope of service transition. It is very important to
follow the build, test, deploy methodology during transition. The scope of service transition
includes the management and coordination of processes,
systems and functions to package, build, test, evaluate, and deploy your release into production. And also retirement of a service according to the service design package. Our next slide is a good recap
of the service design package just in case you've
forgotten what that is about. Just to encapsulate the purpose
of service transition again, you need to build, test, and deploy a release into production. There is a good reason why
this is highlighted here, and from an ITIL standpoint
this is extremely important because before migrating
somebody on to your system you need to make sure that you build the right set of services, you test the right set
of services internally, and then you deploy. Wait and watch to see
if there are any errors, solve these errors and then
finally release into production. Having done that you also
need to record and maintain integrity and relationships
with all IT service assets. You need to provide good quality
information and knowledge that will help take
better business decisions. And you need to also ensure
that services are managed, operated as per service
delivery agreements. The scope of service transition
obviously then includes the management and coordination
of processes, systems and functions to package,
build, test, evaluate and deploy a release a new bunch of
services into production, and also retirement of a service based on the service design package. Now if you remember this, the SVP, the service design package, obviously is an important document that defines all the
aspects of an IT service and its requirements across
each stage of the lifecycle. An SDP is created for each
new IT service, major change, or an IT service retirement, and it follows a simple lifecycle of encapsulating business requirements, creating service design, creating an organization
readiness assessment document, and finally a service lifecycle plan. There are five core processes
under service transition that ITIL prescribes. These are transition planning and support, change management, service asset and configuration management,
otherwise known as SACM. Release and deployment management, and finally knowledge management. We shall discuss each of these
in detail in upcoming slides. As of now we need to remember thoroughly the five core processes that fall under the service transition bucket. Let's start with transition
planning and support. Now, transition planning
and support is nothing but a basic understanding of
what needs to be done, who are the persons involved,
and what is the end goal. The most important aspects
here are predicted cost, quality and timelines, and
coordination between personnel who manage each of these. According to ITIL the process objective of transition planning and
support is to plan and coordinate the resources to deploy a major release within the predicted cost,
time, and quality estimates. Again, three important buzz words in the context of service transition and transition planning and support. Predicted cost, quality, and time scales. These are pretty much the
three boxes you need to tick if you are undergoing a process of transition planning and support. You need to migrate services, you need to understand
what needs to be done, you need to have a fair
understanding of the end goal, but most importantly it needs to fit into the boundaries of predicted cost, expected quality, and
estimated time scales. Change management on the other hand, the goal here is to ensure
that changes are executed in a controlled manner
by evaluating for impact, risk, time, and cost. We have obviously discussed at
length about what these mean, impact, risk, time, and cost. Change management needs to ensure that changes are executed
in a controlled manner. The important thing here is
to know that changes should be approved and authorized only
if they are allied to business. No change, no business
change can be justified if there is no business goal in sight, or it is not aligned to the
organizational business goals. According to ITIL, the process objective of change management is to control the
lifecycle of all changes. The primary objective of change management is to enable beneficial changes to be made with minimum disruption to IT services. Again an important point. Change management needs to ensure that beneficial changes are
made to the IT framework or to the service that you
provide, or the mechanism in which you provide
service to the customer. But this needs to be done
with minimum disruption to IT services at your end as
well as the customer's end. This includes addition, modification, and removal of service if required. This includes addition,
modification, or removal of services if required depending on
business needs of the customer. Changes are classified into three. There are standard changes and
there are emergency changes. Changes are classified
into standards changes and emergency changes. Standard changes are the changes that, a standard change is a change
to IT services or environment which is relatively low risk, very frequent, with low impact, and these changes are
usually preauthorized. An emergency change on the other hand are changes to any
component of the service, should be handled in a controlled manner after requisite approvals, even if it is verbal, and evaluation. For example, a website outage is an ideal example of
an emergency change. Even if there is a verbal
approval it would suffice because what is critical is the fact that business continuity should,
what is important is that business continues as usual
without any effect on profits. Standard changes obviously are slightly easier to understand. These are low risk,
frequent, low impact changes. Ideally something like a update or a patch to existing
software is a standard change, while an emergency change is usually associated with a
risk or multiple risk factors. There are three components of change. Or rather, there are three
important aspects to change. Standard change or emergency change, there are three important aspects. There is the change advisory
board, remediation planning, and change proposal. These are three important points
that one needs to remember in the context of change management. A change advisory board
is a group of people that look after
assessment, prioritization, authorization and scheduling of changes. These are ideal for standard changes, or rather changes that
are planned in advance. A group of people that look
after the prioritization, authorization, and scheduling
of changes to ensure that either the changes are deployed
department by department, or set by set, or all in one go to ensure minimal business disruption. Remediation planning
again is a plan of action that defines a way to get
back to the existing state in case a change is unsuccessful. Obviously changes come with
their own risk factors. A change may not always be
successful in the first goal. Remediation planning ensure that things bounce back to normal as soon as possible after a change is carried out and is unfortunately unsuccessful. Change proposal on the other hand is the process of
assessing the risk, impact, and feasibility of a change. Change proposal is sometimes
the first step towards change in any organization,
especially small organizations. You first do an analysis of
the risk, you assess the risk, you have a vague idea of the
impact it's going to create, and the feasibility of
the particular change. And then usually you create
a change advisory board, and then in case things go wrong you always have remediation planning. So these are the three important aspects of change management according to ITIL. Let's now move on to service asset and configuration management,
otherwise known as SACM. The role here is to manage
the integrity of IT services. Ensure that that assets
under the control of IT are identified, controlled, and cared for. According to ITIL, the
process objective of SACM is to ensure that deployed releases and the resulting services
meet customer expectations, and to verify that IT operations is able to support the new service. Again, going back to
our favorite scenario, you have a bunch of
services that you have sold to the customer, the customer
sees value in your services and hence has chosen you over competition. And in case the customer has migrated from competition recently
to your own business, you obviously have successfully service transitioned
your business as well. Now the role of service asset
and configuration management is to manage the integrity of
the services that you provide. The role of SACM is also
to ensure that assets under the control of IT are identified, controlled, and cared for. You need to watch your
own IT with a hawk's eye. You need to ensure that
every component of your IT is identified, it is controlled
by the right personnel, and cared for, cared for meaning
it has to be taken care of, and if there's a warranty of any component that is likely to end,
you need to ensure that the warranties are extended if need be. So again, just to recap,
the process objective, to again, to recap, the
process objective of SACM is to ensure that deployed releases and the resulting services
meet customer expectations, and to verify that IT operations is able to support the new service. Just in case you release new patches or deploy new releases to your customer as part of your service package, you need to ensure that the releases and the resulting services
meet customer expectations, and obviously from your
end you also need to verify that your IT operations is able
to support the new service. There is no point releasing
something new to the customer if you are unable to support it if it comes with an associated risk. So you need to make sure that
the customer is able to use it seamlessly at the same time
you should have the ability to service it if need be. Let's now try and understand
the various components of SACM. The various components of
SACM are service asset, configuration item, configuration record, and a service knowledge management system. From ITIL standpoint, it
is extremely important to understand in detail what
each of these concepts mean. Let's start with service asset. A service asset is any
resource or capability that could contribute to
the delivery of a service. A service asset can be people,
process, knowledge or IP, applications, infrastructure,
or financial capital. Let's try and recap and understand this in very simple terms. What is asset? An asset is something that
is extremely dear to you. An asset is something
that is valuable to you, and an asset is something which is used to provide value to somebody else. In this case, an asset
or rather a service asset is an extremely valuable
component of your business that is extremely critical
into the services you build which are consumed by the consumer. Or rather, that are
consumed by your customers. Obviously your assets could
be people, your workforce, processes, processes that you have created and the process document. It could be IP, or knowledge, which means your unique
selling proposition. Your own core IP, something
that you have created based on your understanding
of what the customer needs. This could be IT applications
that you have created to ensure that you are able
to deliver the service, you are able to deliver the service up to customer satisfaction levels. It could be the IT infrastructure
that you have set up to ensure that your business
continues without interruption. And obviously, one of your service assets could obviously be the financial capital that you have used to create all of this. The next component of SACM,
which is extremely integral is something called configuration item, otherwise known as CI. CI refers to the
fundamental structural unit of configuration management system. Now examples of CIs include individual requirement documents, software, models, and plans. These are structural units of a configuration management system. Configuration management
system is made up of small minute units, but the
most fundamental them of all is a configuration item. Configuration items include
documents, software, models, and even blueprints. Configuration record. A configuration record
contains the lifecycle of a CI. The lifecycle of every
configuration item is, the lifecycle of every configuration item is recorded in a configuration record. And the SKMS, or the service
knowledge management system, is simply a combination
of tools and databases that are used to manage information and knowledge about services. In other words, a
repository of tools and data that are used to manage information and knowledge about services that you have already rolled out or plan to roll out in the near future. In the context of service asset
and configuration management it is extremely important to
understand the role of the DML and the DS. DML stands for definitive media library, a secure physical library
where authorized versions of all configuration items are stored. DS on the other hand stands
for definitive spares, another physical library where hardware specs are closely stored. Now examples of data stored
in DML are hardware assets like CDs with licenses and
copies of (mumbles) software installed for business. And examples of data stored in the DS would be hardware spares, keyboard, mouse, server components, et cetera. A very simple way of understanding
the difference between a DML and a DS, DML is
where you store software. More or less most of what
is stored inside a DML are software licenses, where
only authorized versions of configuration items are stored. DS is more of a physical locker where hard copies with CDs, (mumbles) software installed for business, even hardware spares or
for your IT infrastructure. Everything from monitors, keyboards, mice, ethernet cables, and everything else. DML and DS. DML is where all the software is stored, DS is a zone where all
the hardware is stored. Now let's move on to release
and deployment management, another important step
in the service transition lifecycle of your business. According to ITIL release
and deployment process aims to plan, schedule, and
control the movement of releases to test and live environments. The primary goal of release management and deployment management
is to ensure that the integrity of live
environments is protected, and that the correct
components are released. The purpose is to plan,
schedule, control the build, test, deploy the release into production. A very critical process which deals with the actual
deployment of a release effectively and efficiently
without ensuring that the customer does not
need a long learning cycle which might affect the
customer's business, and also from your business
it has to make sure that the release is seamless and does not put too much
burden on your own IT. Let us now understand the concepts of release and deployment. We need to understand
what a release policy is. A release is simply a document containing unique identification,
numbering and naming conventions for different types of releases. The release policy more
importantly should comply with the DML and ensure that
no unauthorized software is used in your organization. Also, the expected frequency of releases must be well documented
in this release policy. Release policy in other words
is nothing but a repository, a physical repository of
documents that deal with roles and responsibilities
of the release manager. It should contain unique
identification, numbering, and naming conventions for
different types of release. It should encapsulate the requirements to use only software assets from the definitive
media library, the DML, and it should also encapsulate
the expected frequency for each type of release. So essentially, a concept document, an all inclusive concept document for release and deployment management. Release, build and test. Release management follows
a simple cycle of release, build, test, roll back. This is a methodology prescribed by ITIL for release, build and test. Release, build, test, and
roll back if required. Any release must first be
deployed in a test environment, after which it can be disseminated
to a widespread release. The phase starts with change
management authorizing to build the release and
ends in change management authorize the release package
to be checked into DML. If your business decides
that what has been rolled out is unsatisfactory, it can
always be rolled back. Release and deployment management, release and deployment
planning, is very simply put, the official authorization stage. This is where a release is authorized. But we need to remember that
even if it is authorized by release and deployment planning, it can still be rolled
back at the last minute. The key takeaway from this
slide should be the fact that ITIL prescribes a release,
build, test, roll back mechanism and emphasizes on the role
of the release policy, which is an all encompassing document that has every information end to end about release and deployment
plans of your organization. Deployment can happen in various ways. It can be big bang, or phased. It can be automatic or
manual, or it could be ELS. Let's come to each one of them. Big bang or phased, a
release can either be a full throttle deployment or use a particular geography
as a test environment. In other words it can be push or pull, you can push to your customers a release, having already planned the impact and having discussed
it with your customers. Or you can listen for a
particular complaint or an issue that a customer faces and
a release can be a patch to ensure that business continuity, to ensure that your
customer does not suffer. It can be big bang or phased. You can do a full throttle deployment of a particular service used by let's say hundreds of customers, or you can decide to leverage
a particular geography as a test environment
to see and to observe how change is being
accepted by your customers, and then go for a big bang deployment. A release can be automatic or manual. You can auto send updates
or request for download. Obviously this is something
that you have known even in terms of home computing. You end up receiving updates
on your mobile device or your desktop machine. And there are times
when you have to request for a particular download
if you are prompted that there is an update that is available. So obviously a release can
be automatic or manual. The final step obviously, the final stage of deployment is ELS, otherwise known as early life support. It's more of a hand
holding guide for users to get familiarized with
a new tool or service. Every tool or service, or even a modification
to an existing service, might require the customer to
go through a learning curve and this should be documented in ELS. A hand holding guide for users to get familiarized with the
new service as soon as possible to ensure that business does not suffer. In fact, it should add
to business productivity as soon as possible. The final stage of release and deployment is to review and close. This is done by formalizing an SLA, capturing user experience
and feedback from customers in case you need to roll back or in case you need to make
minor tweaks to your release to ensure that it is effective. To ensure that it is deployed
worldwide without any tremors. Let's now get to knowledge management. This is the final stage of
change management as a process. This is the final stage
of service transition. According to ITIL, knowledge
management aims to gather, analyze, store, and share
knowledge and information within an organization. The primary purpose of
knowledge management is to improve efficiency by reducing the need to
rediscover knowledge. Documented knowledge can
be stored in any form, as a SharePoint document,
an internal wiki, or even spreadsheets. The role of knowledge
management according to ITIL is to improve management decisions through reliable and secure
information data available. It is also to gather,
analyze, store, share, use and maintain
information data available from the service provider and to reduce cost,
improve quality of service, and increase satisfaction
levels for your customer. Very simply put, knowledge
management is a repository of everything that you offer the customer. It is a mechanism to gather,
analyze, share knowledge and information within your
own organization, across teams. To ensure that you improve
efficiency by reducing the need to rediscover knowledge. Here is a scenario where you have created a particular service for a
BFSI or a banking client, or a bunch of banking customers, but later in the day you might,
your business might require to create a similar suite
of services for let's say a manufacturing sector. While it's no rocket science
that both of these domains, BFSI and manufacturing, come with their own set
of unique challenges, the very basic blueprint of your services might remain the same. You can save a lot of time and money and business productivity
if you were to reuse the knowledge that you
have already gathered while you were creating the
service for the banking clients. Knowledge management plays a
huge part in this migration and it takes care of all
the documented knowledge in any form, as documents,
physical documents, e-mail interactions, blueprint documents, SharePoint documents, internal wiki, even spreadsheets that
you have used to create, create and disseminate
services to existing clients, an extremely important
phase of service transition to ensure that you don't redis, a critical stage in the
service transition lifecycle to ensure that you do
not rediscover the wheel every single time. Knowledge, interestingly
is also a capability when it comes to building a service and hence even knowledge
can help in reducing cost, increasing efficiency of service, and increasing customer satisfaction. The goal of knowledge management
is simply to ensure that the right knowledge is
available at the right place, accessible to the right people, and knowledge management also
shares aspects of the SKMS. Now, we shall understand SKMS in a while, but this is just to recap
what we spoke earlier. The goal is obviously to
ensure that the right knowledge is available at the right place. If you need to prevent yourself
from reinventing the wheel, the right data or the right
knowledge, and the right IP should be available at the right place, with the right people, so you know exactly whom to
call into the meeting room to create that new suite of
services for the new domain. The service knowledge
management process obviously to ensure that you don't
reinvent the wheel, there is obviously a context,
there is understanding. There is a context of business, and you have an
understanding of the business based on your own relationships
with existing clients. You need to make sure that the right data is converted to the right information, and knowledge, and wisdom, which will dramatically ensure
that you're able to roll out new services to new business domains without wasting too much time and probably much faster than competition. With that we come to the end of the service transition module
as part of ITIL Foundation. Now let's attack the next
module, service operation. The objective of service
operation is to make sure that all IT services are delivered effectively and efficiently. This includes fulfilling user requests, resolving service
failures, fixing problems, as well as scouting out
routine operational tasks. The aim of service
operation according to ITIL is to maintain stability
in service operations, minimize the impact of service
outage to the customer, achieve effectiveness and efficiency in delivery and support of services. Service operation defined is that in order to keep the lights on, the metrics of services,
technology and people must keep working
efficiently day after day. Knowledge of all these spokes is critical to efficient service operation. Of all the aspects of a
service, it is service operation that is most intimately
connected to the customer. Let's now try and understand
this in simple words. It is important that the
lights are all on the time, and only with three particular components. Your suite of services, the technology backbone that you use, and your workforce of people keep ticking like clockwork
in order to ensure that, keep working like clockwork
to ensure that your business continues un, your business
continues uninterrupted. Which is why of all
the aspects of service, it is service operation that is most intimately
connected to the customer, and hence the most important
aspect of service delivery as prescribed by ITIL. So then what is the purpose
of service operation? The purpose is simply to
coordinate and carry out the activities and processes
required to deliver and manage live services at agreed
levels for the customer. The scope obviously is to
describe the processes, functions, organizations, and tools used to underpin activities. And these include services,
the service management process, technology and people. As stated earlier, services,
technology and people are obviously the three
most important spokes in order to keep the lights on, and obviously there is the requirement of a service management process as well. The ongoing management process
executed in operations, even though some of these may organize, some of these may originate
from service design or service transition. The use of right technology
in delivering the services of, the use of right technology in
delivering these services is, the use of right technology
in delivering these services is obviously an important spoke, as well as the bunch of great people who manage the above services,
processes, and technology, continually day in and day out. Service operation is impossible unless the metrics of
services, technology and people keep working efficiently all year long. There are several processes
within service operation and from an ITIL standpoint
it is extremely important that we understand each of these. These include incident
management, problem management, event management, request
management, and access management. Let's now go into each
one of these in detail. The goal of incident management is to restore service
operation as soon as possible. It is not a permanent solution, but a solution that
ensures minimal downtime. For example, if a particular
printer in your organization ceases to work, incident
management will step in, and ensure that you are given the option of printing your documents from
the next available printer, even if it means you need to travel from one floor to another
to access this printer. It is a stopgap arrangement, but it ensure that there
is minimal downtime. An incident is a good base for
root cause analysis as well. Incident management may
lead to temporary reduction in quality but no interruption
to business whatsoever. Incidents again are graded using the principles of
impact, urgency, and priority. Impact is a measure of an incident, urgency is how long it is
likely to stay an incident, and priority is how critical
the affected task is. We will talk about incidents
in some time, but for now, it is important to understand the role of incident management, which is essentially to
provide an alternative as soon as possible to ensure
minimal business disruption. Problem management on the other hand tells you how to minimize
the impact of disruption to IT services by
identifying the root cause. Unlike incident management, problem management deals
with permanent solution. It is fundamentally used to
identify the underlying cause of one or more incidents. The aim is to ensure permanent solutions through a change management process. There are two types of problem management, reactive and proactive. Reactive obviously is when
you identify, classify, and diagnose an issue, and a
proactive change management is when you undergo trend analysis and preventive action is taken to ensure minimal disruption to business. Event management on the other hand is where you detect
events, make sense of them, take control action. It is defined as a change of state that has significance for the
management of an IT service, and event management is the process responsible for managing events
throughout the lifecycle. Events occur as a result of alerts, which is basically a notification that the threshold has been breached. And that's a consequence
a failure has occurred. The moment an alert is sounded, it is evident that some
failure has occurred. It is an event and event
management takes care managing an event with minimal
disruption to business. Request management according to ITIL aims to fulfill service requests, which in most cases are minor. Usually the end user uses
a self-service portal or a service catalog to
request for a service. The objective of request management is to source the requested components, software licenses, et cetera. It is essential in the
context of request management to understand a service request which is essentially a
formal request from a user for something that needs to be provided. Ideal example is a reset password request or standard services to a user. Request management pretty much deals with low cost, low impact,
high frequency requests that are usually made from
a particular staff member. Access management on the other hand, the role here is to simply
grant authorized users the right to use a service while preventing access
to non-authorized users. It should respond efficiently
to granting, restricting, and revoking access rights. The role of access management
is also to manage policies and actions as defined
in security management. We'll come to security
management in a bit. Access management is
simply the process by which your organization ensures
that the right data is accessed by the right
people within your company, within your business. Let's now deep dive into each of these. Event management detects
events, makes sense of them, takes control action. An event is defined as a change of state that has significance for the
management of an IT service, and this is the process
that is responsible for managing events
throughout the lifecycle. As mentioned before, events
are results of alerts, which is essentially a documentation or a notification that a
threshold has been breached, a particular threshold has been breached, and a failure has occurred. Event management provides the entry point for execution of service operation
processes and activities. It provides a way of
comparing actual performance and behavior against
design standards and SLAs. If you remember you provided
an SLA, a mutually agreed SLA, to your customer in case an event happens. In the event of a failure or an alert, you need to make sure, or
rather the event management has to make sure that accurate
performance as against SLAs, the effect is minimal. Event management is
obviously then the basis for operational monitoring and control, and provides a basis for
service assurance and reporting, and service improvement
all at the same time. If you track a trend of event management, your business can obviously
fine tune SLAs in the future and it acts as a basis for
service assurance and service, and service improvements
in the months to come, in the days to follow, and even in the creation of new
services for your customers. We have already spoken about
these in previous slides, this is more of a reminder,
but from an ITIL standpoint it is extremely important that you understand these
definitions, principles, and basic concepts of event management. An event, as we mentioned
before, is a change of state that has significance for the
management of an IT service or other configuration item. Events typically require
IT operations personnel to take actions, and often
lead to incidents being logged. Event management is simply
the process responsible for managing events
throughout the lifecycle. And alert is a notification
that a particular threshold has been breaching, something has changed, a failure has occurred. Alerts are usually created and managed by system management tools, and are managed by the
event management process. Extremely important definitions
from an ITIL standpoint but pretty simple now
that you have understood the difference between an alert, an event, the relationship between
an alert and an event, and what event management
predominantly deals with. Incident management as
we touched upon before, the goal here is to
restore service operation as soon as possible. It is obviously not a permanent solution but a stopgap arrangement. But however a solution that
ensures minimal downtime. The printer example,
where you are redirected to a different printer to ensure that your documents do not suffer and your business does
not lose valuable time. But of course if you see
a pattern of incidents, if you see that the
same printer is getting, if you see that the same printer
is malfunctioning regularly it is obviously a cause for, or rather a good base
for root cause analysis. Root cause analysis
obviously is the process where you try and understand
and go right to the basics of what the cause of a
particular problem could be. And remove it from the root and
ensure that in the long term similar incidents do not
occur from the same point, or from the same piece of hardware. Incidents are graded using
the principles of impact, urgency, and priority. Again, three extremely important words in the context of ITIL,
impact, urgency, and priority. Impact is a measure of an incident. Urgency is how long it is
likely to stay an incident, and priority is how critical
the affected task is. All of these are obviously
closely aligned to the SLA that you have agreed with your customer. Taking a deep dive into
these three definitions. An impact is often based
on how service levels are likely to be affected. Impact and urgency are
used to assign priority. Urgency on the other hand is a measure of how long it will remain an incident problem or change, and how it has a significant
impact on business. For example a high impact
incident may have low urgency if the impact will to affect the business until the end of the financial year. And impact and urgency are
used to assign priority. Priority on the other hand is
based on impact and urgency and is used to identify the required times for action to be taken. For example the service
level agreement, the SLA, may state that priority two incident must be resolved within 12 hours, and based on the priority
that you have prescribed in the SLA the incident management team or the incident management
department of your business has to make sure that these
SLAs are not breached. Challenges in incident management,
from an ITIL standpoint, there are challenges,
there are common challenges that incident management brings with it. Some of the challenges
are the ability to detect incidents as early as possible. Convincing all the staff that
all incidents must be logged and should not bypass the service desk. Incident management, has also
prescribed that your business needs to increase self-help
web-based capabilities for providing first line support, availability of information
about problems and known errors should be documented. It must be integrated into the CMS, the content management system, to determine relationships between the Cis along with history of previous incidents. Incident management also
requires you to provide a correct assessment of impact
and priority of incidents. And the invocation of
escalation procedures at appropriate times as deemed necessary. Pretty simple. You need to detect incidents
as soon as possible. The earlier you detect incidents, the faster you are able to solve them and lesser interruptions to business. This can be done by
encouraging your workforce to actively use self-help
web-based capabilities. This ensures that your
employees lose minimal time in documenting a particular incident, and by using web-based
tools you also ensure that all of these are logged
and tracked efficiently. If incident management is tied to the CMS, it is obviously easy
to determine a pattern. You can obviously perform
root cause analysis. You can assess the impact
and priority of incidents and solve them according to priority. And of course, in severe cases you can always initiate
escalation procedures to ensure that it does not stay
an incident for a long time. Let's now get to problem management. Problem management basically tells you how to minimize the impact
of disruption to IT services by identifying the root cause. Unlike incident management, problem management deals
with permanent solutions. If you remember incident management finds a stopgap arrangement. Problem management on the other hand deals with permanent solutions. It is fundamentally used to identify the underlying cause of
one or more incidents. Going back to our previous example, if we find that the same
printer is malfunctioning every week, there is
obviously a deep rooted cause that needs to be explored. Problem management is
fundamentally used to identify the underlying cause of
one or more incidents. The aim here is to ensure
a permanent solution through a change management process. There are two types of project, problem management can
be done in two ways, reactive and proactive, pretty
much simple to understand. Reactive problem management is
where you identify, classify and diagnose a particular incident. Proactive problem management
is where you perform trend analysis and take preventive action. Reactive problem management
generally is executed as part of service operation. It encompassed problem
identification and recording, problem classification
depending on the level of impact on your business. Investigation of the problem
and diagnosis of the problem. Proactive problem
management on the other hand is initiated in service
operation but is generally driven as part of continual service improvement, CSI if you remember. This encapsulates trend
analysis and targeting preventive action to ensure
minimal disruption to business. And to ensure that the same incidents do not occur over and over again. A few concepts that
are extremely important from an ITIL standpoint
around problem management, a few basic principles, a few concepts. Known error is basically
a problem that has, that has a documented root
cause and a workaround. Known errors are created and managed throughout the lifecycle
by problem management and known errors may also be identified by development or suppliers. There might be an error
which is not directly related to your business or your service offering. It might be an error that is caused because of the inefficiency, because of the inefficiency
of a particular vendor or a service provider, and these are known as known errors. A workaround on the other
hand, as the word suggests, deals with reducing or eliminating
the impact of an incident or a problem for which a full resolution is not yet available. An ideal example would be by restarting a failed configuration item. Workarounds for problems are documented in known error records, and workarounds for incidents
that do you not have associated problem records are documented in the incident record. A known error database, if you can just break
down these three words, pretty simple to understand. A database containing
all known error records. This database is created
by problem management and used by incident management. The known error database may be part of a configuration management system, or may be stored elsewhere in the service knowledge
management system. Three important concepts,
known error, workaround, known error database. Related to error management is the concept of request management. According to ITIL request fulfillment, according to ITIL, request management aims to
fulfill service requests, which in most cases are minor. Usually the end user uses
a self-service portal or a service catalog in
the request for a service. The objective of request management is to source the requested information, components, licenses, et cetera. It is essential in the
context of request management to understand the meaning
of a service request. A service request is
essentially a formal request from a user for something
that needs to be provided. Ideal example would be
a reset password request or standard services to a new user like a log in, password,
e-mail address, et cetera. These are low cost, low impact, and have a high frequency of occurrence. Let's now take a deep
dive into each of these. Again, like we said, a service request is a formal request from a user for something to be provided. Service requests are managed by the request fulfillment process, usually in conjunction
with the service desk. Most service requests are made
from service desk by the user and hence this is a pull mechanism. And hence it operates as a pull mechanism. Service requests may be
linked to a request for change as part of fulfilling
a particular request. The ownership of service requests resides with the service desk, and the role of the service
desk is to monitor, escalate, dispatch, and often fulfill
the user request end to end. What is the scope of request fulfillment? Service request normally
follows a standard change parameters, which
are low risk, low impact, and frequently occur,
and are pre-approved, as we figured out before in the case of the password reset example. It is appropriate obviously then to have a service request process
as a separate work stream where large volumes of request fulfillment needs to be handled, and this
depends on the organization, the size of the organization. If you have too many users
who are joining in and out it makes sense to have a
dedicated service request portal or a group of people
exclusively handling this. Or as ITIL suggests,
a separate work stream where a large volume of
service fulfillment needs need to be handled at
any given point of time. Let's now talk about access management. The role of access
management according to ITIL is simply to grant authorized users the right to use a service while preventing access
to non-authorized users. Making sure that the right tools are accessed only by the right personnel within your organization. Access management should
respond efficiently to granting, restricting,
and revoking access rights. Its role is also to manage
policies and actions defined in security management. In other words, access
management deals with granting authorized users with a user for service or group of services, while ensuring that others do not use it. Obviously then you have to
manage policies and actions that are defined in security management. You might need to change access right depending on role changes, or new personnel joining your teams. And hence you need to
manage policies and actions. You need to respond efficiently to granting and accessing rights, and importantly you also
need to oversee access to service rights to ensure
that the rights granted are properly used and not misused. The moment they are misused
you can obviously roll back, and manage policies in a
way that unauthorized users do not get access to
critical information or data. Let's now get to service desk. The fundamental role of a
service desk is to ensure that normal service is restored
to users as soon as possible. Service desk is the
single point of contact for all users of IT
within an organization. It logs and manages all
incidents, service requests, access requests and all
other services and processes. The primary aim of service desk should obviously involve resolving incidents or fulfilling a service
request or answering a query. Anything that is needed to allow the users to return to delivering
services satisfactorily. Service desk an important,
an extremely important spoke as a new point of contact for users of IT within an organization to ensure that all requests
are able to be processed in the shortest time possible with minimal disruption to business. There are different
types of service desks. Three types to be precise. A local service desk, a
centralized service desk, and a virtual service desk. A local service desk is a service desk which will only be applicable where an organization has
presence only in one location. Let's say a relatively
small company where there is one single consolidated service desk which serves or services employees within the same workplace. Users and IT service
providers are co-located. This obviously aids physical presence, communication, culture
and the same time zone. Local service desks can be
inefficient and expensive as the arrival volume of calls
may not be just staffing. Local service desks can be
inefficient and expensive if your company were to become bigger and grow in terms of volume because in case there are inbound calls, too many inbound calls, it
may not justify staffing. The service desk obviously has, ITIL prescribes that an
ideal midsize service desk should have separate departments
for technical management, application management,
operations management, third party support,
and request fulfillment. Pretty simple concepts of everything that a service desk deals with
on a day to day basis. Centralized service desk on the other hand is a sort of service desk
which will only be recommended where an organization
has physical presence in different locations. But a very important point
as prescribed by ITIL, the service desk, or rather
a centralized service desk is centrally located. Your organization might
have a presence in locations across the world, but the
service desk will reside in only one these locations. The policies, procedures, severity codes, are all in one central place. It is obviously then cost effective and core IT support will be
located at the head office with local IT support
teams in different sites. This allows fewer staff to deal
with higher volume of calls. A centralized service desk
that caters to services or service requests from your employees from across the globe or any
location that you exist in, and what ITIL prescribes
as a second line support, which provides more
interactive localized support for each branch office. The only difference here
in terms of architecture or organization is the fact that there is an additional
second line support layer that is added to technical management, application management,
operations management, third party support,
and request fulfillment, just like a local service desk. Let's now understand a
virtual service desk. As the name suggests it may
not be a physical service desk where you see actual employees working. It is more virtual and
you raise the ticket and your support team sitting
elsewhere in the world takes care of the ticket
and solves your issue. A virtual service desk according to ITIL is a combination of local
and centralized service desk. It has the benefits of the local and centralized service desk alike. This sort of service desk is
recommended for organizations with physical presence across the globe. However this is becoming out of fashion as there is a need to have 24 X 7 support across all these places, and this means that the service desk staff will be required to work on three shifts, and this will obviously be expensive. To overcome this limitation, a new variant of the virtual service desk has evolved called follow the sun. As the term follow the sun suggests, there are virtual service desks, and depending on the time zone that you raise a service request, the service desk sitting
at a conducive time zone will honor and process your request. Suppose sitting in India
you raise a service request early in the morning, it
might be the San Francisco service desk that might be servicing it. Or later in the day it might
be the Beijing service desk as shown in this diagram. The key takeaway from here, the virtual service desk obviously, the virtual service desk
need to provide 24 X support across all regions of your business, however since this is not possible the follow the sun concept has evolved, where depending on the time of a request, a conducive service desk
located anywhere in the world processes your request. Obviously the follow the sun
method would require employees to work only one shift
and before leaving office would hand over any pending
calls to the next service desk where there is sun. However, common processes,
tools, share information, database, and robust handover
procedure is essential for this to be successful. Yes, the follow the sun
method looks very lucrative and conducive to business,
but ITIL prescribes that before the next shift
of employees takes over, takes over from a
different part of the world there has to be an effective
and seamless handover of processes, tools, and
commonly shared information for this model to be successful. This is especially true for incidents that might require a long term solution. As in this image, the Rio
de Janeiro service desk might have begun your
incident management process but it might be the Beijing service desk that ultimately closes it. So extremely important from an ITIL, so extremely important
from an ITIL standpoint to ensure that proper handover
is done across the world, across the different
virtual service desks. So that brings us to the
close of service operation. And now ladies and gentlemen we come to the final
module of ITIL Foundation, that goes by the name of
continual service improvement. So what does this mean? The purpose of continual
service improvement, otherwise known as CSI, is to align IT services
with changing business needs by identifying and
implementing improvements. According to ITIL the purpose also extends to improve activities that
supports a lifecycle approach. And continuously seek ways to
improve service effectiveness and cost effectiveness. In simpler terms, once we have gone through
the cycle of identifying the right services to
provide to our customer base, listening to our customer base, and re-evaluating our service portfolio to provide the best possible service, differentiating ourselves
from competition, and ensuring that our business solves critical problems of the customer, in order to ensure that this cycle keeps going on and on effectively we need to ensure continual
service improvement for our business. As we have figured out
right at the beginning, customer expectations change,
customer expectations evolve. Competition influences customer behavior, and it is extremely essential
from ITIL standpoint as well to ensure that the service
portfolio of your business keeps itself updated. Continual service improvement by ITIL is targeted at achieving precisely this. So then, the scope of
continual service improvement, otherwise known as CSI, is to ensure continual
alignment of the portfolio of IT services with current
and future business needs. The maturity of the enabling
IT service management processes for each service in continual
service lifecycle model, and continual improvement of
all aspects of the IT service and the IT service
assets that support them. So the common thread here
is continual improvement. Once we have set an
effective service lifecycle it is extremely important
to keep the wheel running and continually improving and enhancing our service portfolio to
ensure that we stay relevant to the needs of the customer. So what value does CSI
provide to your business? It leads to a gradual
and continual improvement in service quality, wherever justified. It ensures that IT services
remain continually aligned to business requirements,
again something that we have touched upon in the past. It is extremely important
that whatever IT services you invest in, whatever
IT services you deploy, should be in sync with your
business requirements as well as have the ability to solve the business problems of your customer. SCI also touches upon
helping your business make gradual improvements
in cost effectiveness through a reduction of costs or capacity to handle more
work at the same cost. Essentially optimization
of cost and service. CSI also deals with using, monitoring, and reporting to identify opportunities for improvement in all lifecycle areas of service management
and in all processes, and across all processes
that are used internally. Pretty evident then
that CSI also helps you identify opportunities for improvements in your organizational structure,
resourcing capabilities, relationship with partners, the technology that you have
deployed, skills of your staff, and training and communications across all these touchpoints. Essentially, the value it
provides to the business is to handle more work at the same cost. In other words, be efficient. According to ITIL, a typical CSI model would
look something like this. It will start with the
basic vision of the company, where your business currently stands now, what your vision is as a
company, where you want to be let's say X months from now,
a quarter or two from now. What is your strategy to get there, and so far are we on track. Continual service improvement, as we learned from the previous slide, touches upon the business
mission, goals and objectives. It can be translated to
baseline assessments, setting up of measurable targets, strategies for process improvement, and using the right
measurements and metrics to ensure that we are on track. The ultimate aim of course is of course to keep the
momentum going and ensure that you continually improve
your service portfolio. There are a few important aspects
and phrases related to CSI that are extremely important
from an ITIL standpoint. Let's go deep into each one of them. Firstly, we need to understand
the role of a CSI register. As the name suggests, it is a database or a structured document that is use to record and
manage improvement opportunities across your lifecycle. By now we have figured out that
ITIL pays a lot of emphasis on documenting data at all relevant points across the service management and service improvement lifecycle. Continual service
improvement is no different. You need to maintain a structured document where you record and manage
improvement opportunities throughout the lifecycle of your business. ITIL also prescribes
that it is likely that several initiatives or possibilities for improvements are identified. It is also recommended
that a CSI register is kept to record all improvement opportunities and that each one should be categorized into small, medium or large undertakings. Obviously opportunities can be categorized into small, medium, or large depending on how much
investment needs to be made, what is the end impact going to be, and how it's going to help your customer, and what impact it's going to have on your internal service portfolio. Hence the CSI register
should also make sure that this categorization is done between small, medium,
or large undertakings. Initially they should also be categorized into initiatives that
can be achieved quickly, or in the medium term or long term. So now we have two categorizations here. A, you need to categorize
improvement areas into small, medium or large improvements. You also need to measure
them in terms of time, on how much each one of
these improvement areas is going to take before
it's completely deployed. It could be an immediate
service improvement, it could be a mid term or
medium term service improvement, or a long term service
improvement strategy. ITIL also prescribes that
each improvement initiative should also show the benefits
that is likely to be achieved after its implementation. In other words, what the
customer is going to achieve from the CSI initiative, and
what impact it's going to have on your business in terms of
cost and other liabilities. It's quite evident then that if you create an in depth CSI register and you have categorized
service improvement areas, you are actually creating
a wealth of information or in other words, a prioritized list that can be produced in
front of your management and can have a bearing on
long term business goals. Couple of other buzz words
that are extremely important from an ITIL standpoint
with regard to CSI. The difference between CSF and KPI. CSF which stands for
critical success factor according to ITIL. This is something that must
happen if an IT service, process, plan, project or
any activity is to succeed. Key performance indicators
are used to measure the achievement of each
critical success factor. For example a critical success factor of protecting IT services
when making decisions could be measured by key
performance indicators such as percentage reduction
in unsuccessful changes. KPI or key performance indicator
is a metric that is used to help manage an IT service,
process, plan, project or other activity. And key performance
indicators are used to measure the achievement of
critical success factors. They should be selected to
ensure efficiency, effectiveness, and cost effectiveness
of all managed services. KPIs can be qualitative and quantitative. Qualitative KPI relates to a quality or a character of something
whereas quantity of KPI relates to size or quality. In other words, a CFS is
something that you identify, a success factor. A success factor that is likely to positively impact your business, and how do you map a CSF? By using a KPI, a key
performance indicator. Which is essentially a
metric that is used to help manage an IT service,
process, plan, project, or any other activity
related to the CSI lifecycle. Talking about the CSI lifecycle, this is pretty much how it'll look like for an average organization. As we mentioned before, it is closely linked to the
long term vision of the company, the current mission of the company, the goals that have been achieved so far, objectives for future. And then the CFS and the
KPI find a place after which metrices are tracked,
measurements are made, and a continual service
improvement or a CSI plan is put to action. In the context of CSI
ITIL also touches upon the PDCA cycle, as created
by W. Edwards Deming. It is essentially a four step process, that is used to monitor, measure, review, and implement CSI initiatives. It follows a simple four point checklist, plan, do, check, act, the PDCA. P for plan, D for do, C
for check, and E for act. At the planning stage you
create a project plan, pretty much a blueprint
for service improvement. At the actual implementation
stage, the do stage, is when the real core
of the project is built. You check, you audit, you
test, and then new actions are implemented in the act stage. PDCA as prescribed by W. Edwards Deming, is a very critical part
of any organization's continual service improvement, CSI plan. First you plan, then you
create the actual project, you check the viability,
and act on new actions. A simple four step
process, the PDCA cycle, which is pretty much the mantra for any organization's CSI initiative. ITIL also prescribes a
couple of more things that are extremely important for CSI. A service measurement,
essentially a baseline or a snap shot that is
used as a reference point. Many snap shots may be taken
and recorded over time, but only some will be used as baselines. Baseline, as the name suggests,
is more of a reference point for your service improvement plans. For example, an ITSM baseline can be used as a starting point to measure the effect of a service improvement plan. And a configuration management baseline can be used to enable IT
infrastructure to be restored to a known configuration if
a change or release fails. The takeaway from here is pretty simple. Service measurement should be, should have an effective baseline for you on which the entire CSI
initiative of your business is centered around. Talking of metrics, which is
pretty much the final point in continual service improvement. There are three type of metrics. Before that let's understand
what a metric means. The dictionary meaning of
it is obviously something that is measured and reported
to help manage a process, IT service, or an activity. It is a measurable chunk of
any activity or any initiative that you have taken up. Metrics in the context of ITIL
can be subdivided into three, technology metrics, process
metrics, or service metrics. Technology metrics, as the name suggests, is associated with component
and application based metrics such as availability,
performance, and others. While process metrics
are captured in the form of CSFs, KPIs, or
specific activity metrics for the service management process. Obviously, as we have understood before ITIL is extremely process
oriented and when it comes, and when one has to choose
between people and processes it is okay if the people break,
but the processes shouldn't. Every process is extremely integral to a service improvement
plan of an organization, of your organization, of your business, and it is extremely
important that you have the right processes in place,
you have the right KPIs and activity metrics have
been tracked to ensure that you are able to determine the
overall health of a process at any given point of time. And obviously this will
have a bearing on the vision and mission of your business. Service metrics on the other
hand, as the name suggests, is the result of an end to end service, and component metrics are used
to compute service metrics. Service metrics is nothing
but an overall 360 degree view of how your service portfolio is doing at any given point of time. It also makes sure that
your technology metrics and process metrics have
been captured effectively. And service metrics is
more of a larger picture of where your business
stands and how it's in sync with your long term business objectives, your mission, and vision. The last and final point of
continual service improvement is service reporting
as prescribed by ITIL. A very important role of a
continual service improvement manager who is responsible
for managing improvements to IT service management
processes and IT services. Everything that you have
discussed about CSI so far, there has to be one personnel
within your organization who should be responsible
for service improvement, and that would be the continual
service improvement manager. The CSI manager will continually measure the performance of the service provider and design improvements
to process, services, and infrastructure in order
to increase efficiency, effectiveness, and cost effectiveness. In the context of continual
service improvement manager it is also important to
note that this is a role that has to be closely
linked to business leaders, should be constantly in
touch with business leader to ensure that there is an alignment to the organization's
goals, long term vision, current mission, and future
plans of your business. With that we come to
the end of the edureka! ITIL Foundation course.
