WEBVTT
Kind: captions
Language: en

00:00:00.700 --> 00:00:03.560
Often when somebody asks me
what YaSM® is about

00:00:03.560 --> 00:00:05.660
I say that it is
like ITIL®

00:00:05.960 --> 00:00:08.580
- but less complex
and easier to understand.

00:00:09.100 --> 00:00:11.700
I think that's a good way
of introducing YaSM,

00:00:11.740 --> 00:00:13.200
because a lot of people
know that

00:00:13.200 --> 00:00:16.200
ITIL® offers advice for
managing services,

00:00:16.480 --> 00:00:19.760
and that's also the kind of
advice you will find in YaSM.

00:00:20.640 --> 00:00:21.720
There are, therefore,

00:00:21.720 --> 00:00:24.560
lots of similarities between
YaSM and ITIL®,

00:00:24.740 --> 00:00:26.180
but also differences:

00:00:26.740 --> 00:00:28.660
We introduced
some fresh ideas,

00:00:28.820 --> 00:00:30.480
a few simplifications

00:00:30.620 --> 00:00:32.800
and above all a
very clear structure

00:00:32.800 --> 00:00:37.420
that makes the whole framework
more accessible and ready-to-use.

00:00:38.000 --> 00:00:39.579
So today I'd like
to give you

00:00:39.580 --> 00:00:42.840
a better understanding of the
similarities and differences

00:00:42.840 --> 00:00:45.700
by taking you through
a couple of examples,

00:00:45.960 --> 00:00:47.140
and I want to show you

00:00:47.140 --> 00:00:49.900
how we managed to create
a streamlined framework

00:00:50.160 --> 00:00:53.220
that is still very much in line
with ITIL®.

00:00:54.780 --> 00:00:55.959
Let's first take a look at

00:00:55.960 --> 00:00:59.300
the process structures of the
ITIL® and YaSM frameworks.

00:00:59.660 --> 00:01:00.840
At the left, we have

00:01:00.840 --> 00:01:03.680
the ITIL® service lifecycle
with five stages:

00:01:04.040 --> 00:01:05.140
• Service strategy,

00:01:05.160 --> 00:01:06.160
• service design,

00:01:06.220 --> 00:01:07.340
• service transition,

00:01:07.360 --> 00:01:08.240
• service operation

00:01:08.240 --> 00:01:10.480
• and continual service improvement.

00:01:10.920 --> 00:01:14.320
Each stage of the lifecycle
contains several processes.

00:01:14.460 --> 00:01:17.860
All in all there are
26 processes in ITIL®.

00:01:18.640 --> 00:01:22.040
The figure at the right shows the
top-level processes for YaSM.

00:01:22.300 --> 00:01:24.860
There are fewer processes
(17),

00:01:24.860 --> 00:01:26.980
and at first sight we recognize
the same

00:01:26.980 --> 00:01:29.740
service lifecycle approach
as in ITIL®.

00:01:30.000 --> 00:01:33.460
But YaSM doesn't assign every process
to a lifecycle stage:

00:01:33.780 --> 00:01:36.460
Instead there are a number of
supporting processes

00:01:36.780 --> 00:01:39.840
- and this makes the whole structure
of the framework simpler.

00:01:40.380 --> 00:01:41.400
Now you might say

00:01:41.400 --> 00:01:43.840
that 17 processes
are still a lot,

00:01:44.000 --> 00:01:46.160
but you don't have to
implement all of them.

00:01:46.600 --> 00:01:50.300
You can pick those processes that
offer the most benefits for you

00:01:50.640 --> 00:01:51.800
- which is easy enough

00:01:51.800 --> 00:01:54.940
because of YaSM's
simple process structure.

00:01:55.360 --> 00:01:57.300
So there are fewer processes
in YaSM,

00:01:57.300 --> 00:02:00.140
and in case you wonder
what's missing in our new framework

00:02:00.140 --> 00:02:02.400
I'd like to show you
a couple of examples,

00:02:02.660 --> 00:02:05.580
to assure you that nothing
has fallen through the cracks.

00:02:06.120 --> 00:02:08.800
My first example is about
managing changes.

00:02:09.100 --> 00:02:12.000
ITIL® suggests we should have
a change management process

00:02:12.020 --> 00:02:14.880
and another one
for evaluating changes.

00:02:15.140 --> 00:02:16.320
In YaSM we think

00:02:16.320 --> 00:02:19.140
a single process for assessing
and evaluating changes

00:02:19.140 --> 00:02:21.780
is perfectly capable
of doing the job,

00:02:21.860 --> 00:02:23.820
so this makes
one process less.

00:02:24.900 --> 00:02:29.000
The next example is about managing
incidents and service requests.

00:02:29.100 --> 00:02:32.180
ITIL® v3 introduced
two separate processes,

00:02:32.180 --> 00:02:35.320
but big parts of these processes
follow the same pattern.

00:02:35.640 --> 00:02:39.560
Therefore, a lot speaks for combining
them into one single process

00:02:39.900 --> 00:02:41.940
- which, by the way,
worked very well

00:02:41.940 --> 00:02:43.700
in the times of
ITIL® v2.

00:02:44.380 --> 00:02:45.680
These were two examples

00:02:45.680 --> 00:02:48.580
where we could easily reduce
the number of processes.

00:02:48.720 --> 00:02:50.060
But there are also areas

00:02:50.060 --> 00:02:53.180
where YaSM follows the ITIL® advice
rather more closely,

00:02:53.340 --> 00:02:55.940
for instance in
incident management:

00:02:56.440 --> 00:02:57.440
ITIL® suggests that

00:02:57.440 --> 00:03:00.120
incident management should
include activities for

00:03:00.180 --> 00:03:02.480
• Logging and
categorizing incidents

00:03:02.640 --> 00:03:04.380
• Resolving
major incidents

00:03:04.740 --> 00:03:07.360
• Resolving incidents in
1st level support ...

00:03:07.420 --> 00:03:08.980
• ... and in
2nd level support

00:03:09.160 --> 00:03:12.140
• and also for the
formal closure of incidents.

00:03:12.640 --> 00:03:14.660
Open incidents should also
be monitored

00:03:14.660 --> 00:03:17.280
while support staff is busy
resolving them, and

00:03:17.480 --> 00:03:20.460
users should be kept up to date
about the progress.

00:03:21.360 --> 00:03:23.600
This will probably look
very familiar to you

00:03:23.600 --> 00:03:25.660
because this way of dealing
with incidents

00:03:25.660 --> 00:03:27.660
is used
in many organizations.

00:03:27.920 --> 00:03:30.340
It's established best practice
and works well,

00:03:30.600 --> 00:03:34.060
so we included an identical process
in the YaSM model.

00:03:34.320 --> 00:03:37.080
It simply didn't make sense
to reinvent the wheel.

00:03:38.660 --> 00:03:42.120
Now, my fourth and last example
is about service design,

00:03:42.440 --> 00:03:44.360
a rather difficult
ITIL® process

00:03:44.360 --> 00:03:46.420
where we had to inject
some fresh ideas

00:03:46.420 --> 00:03:48.240
to make it
less complex.

00:03:48.780 --> 00:03:50.000
According to ITIL®,

00:03:50.000 --> 00:03:52.680
service design includes
quite a few processes:

00:03:53.300 --> 00:03:55.940
At the center,
we find a coordination process

00:03:55.960 --> 00:03:58.580
that calls upon
other design processes, such as

00:03:58.780 --> 00:03:59.980
• Capacity management

00:04:00.140 --> 00:04:01.700
• Availability management,

00:04:01.880 --> 00:04:03.540
• IT service continuity management,

00:04:03.700 --> 00:04:04.819
• Supplier management and

00:04:04.820 --> 00:04:06.700
• Information security management.

00:04:07.260 --> 00:04:09.120
Two more processes
are responsible

00:04:09.120 --> 00:04:10.640
• for managing service levels

00:04:10.640 --> 00:04:12.760
• and for managing
the service catalog.

00:04:13.340 --> 00:04:14.300
The problem here is

00:04:14.300 --> 00:04:17.100
that we end up
with complex process interfaces,

00:04:17.240 --> 00:04:18.640
and that means figuring out

00:04:18.640 --> 00:04:22.320
how service design is supposed
to work is not easy.

00:04:22.800 --> 00:04:24.940
So how can we simplify
this in YaSM?

00:04:25.340 --> 00:04:28.420
We have to remind ourselves
that service design is about,

00:04:28.420 --> 00:04:30.300
well, designing services,

00:04:30.540 --> 00:04:32.040
and as such it needs
to include

00:04:32.040 --> 00:04:35.420
• activities for defining the
required service properties,

00:04:35.640 --> 00:04:37.880
• designing the
required infrastructure,

00:04:38.060 --> 00:04:40.280
• outlining the
implementation approach

00:04:40.480 --> 00:04:43.320
• and preparing the
service implementation.

00:04:43.660 --> 00:04:45.800
And when the service design
phase is complete,

00:04:45.800 --> 00:04:48.720
everything is ready for the
service implementation.

00:04:49.380 --> 00:04:52.460
This is a pretty straightforward
description of service design

00:04:52.500 --> 00:04:53.980
that's easy to understand

00:04:54.400 --> 00:04:55.820
- but now you might ask,

00:04:55.820 --> 00:04:57.280
isn't this too simple

00:04:57.280 --> 00:04:59.400
and where did all the
ITIL® processes go?

00:04:59.680 --> 00:05:03.360
For example, where are
capacity and availability management?

00:05:04.060 --> 00:05:06.120
Well, the real point is
that we need to

00:05:06.120 --> 00:05:08.720
manage service capacity
and availability,

00:05:09.000 --> 00:05:10.460
and in YaSM
this is done by

00:05:10.460 --> 00:05:13.940
taking service capacity
and availability into account

00:05:13.940 --> 00:05:16.720
at every stage
of the service lifecycle:

00:05:17.180 --> 00:05:20.400
• At the strategic level,
we try to come up with forecasts

00:05:20.400 --> 00:05:23.520
of how the service capacity
and availability requirements

00:05:23.520 --> 00:05:25.280
will evolve in the longer term.

00:05:25.980 --> 00:05:27.200
• During service design,

00:05:27.200 --> 00:05:30.540
we define the capacity and
availability requirements

00:05:30.540 --> 00:05:32.940
of new or changed services
in detail,

00:05:33.040 --> 00:05:35.140
in the form of
service level targets.

00:05:35.860 --> 00:05:38.260
• Then we set up the services
in a way that

00:05:38.300 --> 00:05:41.560
capacity and availability requirements
can be met,

00:05:42.020 --> 00:05:43.580
• and during service operation

00:05:43.580 --> 00:05:47.140
we measure actual service capacity
and availability

00:05:47.240 --> 00:05:49.720
and produce
service quality reports.

00:05:50.460 --> 00:05:53.600
• Finally, if it turns out
that the services do not deliver

00:05:53.600 --> 00:05:56.440
the required levels of
capacity and availability,

00:05:56.600 --> 00:06:00.880
we take corrective action and
implement service improvements.

00:06:02.780 --> 00:06:04.340
So as you can see,
we can do

00:06:04.340 --> 00:06:08.400
without capacity and availability
management processes in YaSM,

00:06:08.800 --> 00:06:09.940
but of course we ensure

00:06:09.940 --> 00:06:13.620
that service capacity and
availability are taken care of,

00:06:13.960 --> 00:06:16.360
and the necessary activities
are still there.

00:06:17.280 --> 00:06:19.780
And this leads to
much simpler processes,

00:06:20.000 --> 00:06:22.140
as I'd like to show you,
very briefly,

00:06:22.140 --> 00:06:24.140
in the YaSM model for Visio:

00:06:25.920 --> 00:06:29.180
This model contains a complete set
of Visio diagrams

00:06:29.180 --> 00:06:32.500
with detailed descriptions
of the YaSM processes.

00:06:32.660 --> 00:06:34.100
Since the
YaSM® Process Map

00:06:34.100 --> 00:06:36.700
is the subject
of quite a few other YaSM videos,

00:06:36.800 --> 00:06:38.540
we skip the introductory part

00:06:38.860 --> 00:06:41.040
and take the link from
the top-level diagram

00:06:41.040 --> 00:06:43.240
to go straight into
service design,

00:06:43.840 --> 00:06:47.300
to check out how services
are being designed in YaSM.

00:06:48.340 --> 00:06:49.900
What we get to see is,
first of all,

00:06:49.900 --> 00:06:52.360
a high-level view
of service design.

00:06:53.120 --> 00:06:54.340
As explained before,

00:06:54.340 --> 00:06:56.880
service design in YaSM
is quite straightforward

00:06:57.220 --> 00:07:00.200
and includes defining the
required service properties,

00:07:00.440 --> 00:07:02.740
designing the
required infrastructure,

00:07:02.980 --> 00:07:05.220
outlining the
implementation approach

00:07:05.220 --> 00:07:08.060
and preparing the
service implementation.

00:07:08.880 --> 00:07:10.920
Now, if we go further, say

00:07:10.920 --> 00:07:14.240
into the process for defining
the required service properties,

00:07:14.400 --> 00:07:17.140
we find the recommended steps
- or activities -

00:07:17.140 --> 00:07:18.780
for defining a service.

00:07:19.820 --> 00:07:21.820
And here we can see
the activities

00:07:21.820 --> 00:07:24.560
for defining the capacity and
performance targets,

00:07:25.020 --> 00:07:28.380
as well as for defining
the availability targets.

00:07:28.920 --> 00:07:32.400
In this way, we ensure that
service capacity and availability

00:07:32.400 --> 00:07:35.660
are taken care of
when designing services,

00:07:35.940 --> 00:07:37.080
and I hope you will agree

00:07:37.080 --> 00:07:38.860
that it's easy enough
to understand

00:07:38.860 --> 00:07:40.840
how this is supposed to work.

00:07:42.600 --> 00:07:45.640
Obviously, the capacity
and availability targets

00:07:45.640 --> 00:07:47.280
must be documented
somewhere

00:07:47.760 --> 00:07:49.580
- in the
service definition document

00:07:49.580 --> 00:07:52.240
that we find in the upper part
of this diagram

00:07:52.240 --> 00:07:54.070
among the process outputs.

00:07:55.360 --> 00:07:56.560
For such documents,

00:07:56.560 --> 00:08:00.180
YaSM includes checklists that
describe their typical contents.

00:08:00.820 --> 00:08:02.260
If we open the checklist,

00:08:02.260 --> 00:08:06.000
we can see that this particular one
describes the information

00:08:06.000 --> 00:08:09.440
that should usually be contained
in service definitions.

00:08:10.680 --> 00:08:13.560
And if we scroll down a little,
we find the section

00:08:13.560 --> 00:08:17.120
that specifies the availability
requirements for the service,

00:08:18.140 --> 00:08:20.640
and a bit further down
we have also the section

00:08:20.640 --> 00:08:23.840
that describes the capacity
and performance targets.

00:08:25.100 --> 00:08:26.700
So the YaSM model not only

00:08:26.700 --> 00:08:29.340
describes the YaSM processes
in great detail,

00:08:29.640 --> 00:08:32.840
but you also get
ready-to-use document templates.

00:08:33.300 --> 00:08:34.100
With these,

00:08:34.100 --> 00:08:36.020
creating your first
service definitions

00:08:36.020 --> 00:08:38.800
should not be too much
of a challenge.

00:08:40.880 --> 00:08:42.300
And that’s it for today.

00:08:42.780 --> 00:08:44.600
I hope I was able
to get across that

00:08:44.600 --> 00:08:48.420
YaSM is not simply a kind of
stripped-down ITIL® light,

00:08:48.740 --> 00:08:50.980
but a complete
service management framework

00:08:51.260 --> 00:08:52.300
that we created

00:08:52.300 --> 00:08:56.420
by injecting lots of fresh ideas
into the ITIL® recommendations.

00:08:57.360 --> 00:09:00.300
Our prime objective was
a perfectly clear structure

00:09:00.320 --> 00:09:02.480
so YaSM is
easy to understand.

00:09:03.400 --> 00:09:05.240
If you would like
to learn more about YaSM,

00:09:05.240 --> 00:09:06.960
please visit
yasm.com

00:09:07.200 --> 00:09:08.080
- where you will find

00:09:08.080 --> 00:09:10.080
a complete
service management Wiki

00:09:10.080 --> 00:09:12.040
and more videos
about YaSM.

00:09:12.720 --> 00:09:14.120
And if you have
questions,

00:09:14.120 --> 00:09:15.300
we are happy
to answer them

00:09:15.300 --> 00:09:17.220
in the
YaSM support community.

00:09:17.720 --> 00:09:19.000
[ Visit yasm.com ]

00:09:19.040 --> 00:09:21.620
[ Free YaSM Wiki: A complete 
introduction to the YaSM framework. ]

00:09:21.620 --> 00:09:24.720
[ More videos and information about YaSM 
and the YaSM® Process Map. ]

00:09:24.780 --> 00:09:27.840
[ Get answers to your questions
in the YaSM community! ]