WEBVTT
Kind: captions
Language: en

00:00:00.880 --> 00:00:03.560
If you have some experience
with enterprise modeling

00:00:03.560 --> 00:00:06.460
and describing the essential
components of a business,

00:00:06.740 --> 00:00:07.600
you will know that

00:00:07.609 --> 00:00:10.809
enterprise architectures usually
cover different domains,

00:00:10.809 --> 00:00:11.579
such as

00:00:11.579 --> 00:00:12.919
• the business processes,

00:00:13.110 --> 00:00:14.370
• the human resources

00:00:14.420 --> 00:00:15.299
• and the data

00:00:15.299 --> 00:00:18.139
required by the organization
to operate.

00:00:19.000 --> 00:00:19.940
Looking at the way

00:00:19.940 --> 00:00:21.090
in which a business works

00:00:21.090 --> 00:00:23.570
is very important
to get the full picture,

00:00:23.960 --> 00:00:25.460
and therefore
the YaSM model

00:00:25.460 --> 00:00:28.200
also includes
different types of views.

00:00:28.820 --> 00:00:31.240
I presented many of them
in earlier videos,

00:00:31.240 --> 00:00:32.780
and today we are going
to take a look

00:00:32.780 --> 00:00:35.950
specifically at the "data model"
and other data views

00:00:35.950 --> 00:00:38.210
contained in the
YaSM® Process Map.

00:00:39.760 --> 00:00:41.660
But let's first recap a little.

00:00:42.200 --> 00:00:43.760
The YaSM Process Map
includes

00:00:43.760 --> 00:00:45.960
process diagrams
of various types,

00:00:46.240 --> 00:00:47.820
such as this one
which provides

00:00:47.820 --> 00:00:50.380
an overview of the
incident management process,

00:00:50.560 --> 00:00:53.840
including the information flows
between the processes.

00:00:54.940 --> 00:00:56.940
For each incident management
sub-process

00:00:56.940 --> 00:00:59.800
you can open a swim lane diagram
that describes

00:00:59.800 --> 00:01:02.680
the activities to be performed
within the process.

00:01:03.180 --> 00:01:04.880
The lanes are labelled
with "roles"

00:01:04.880 --> 00:01:08.040
to describe the responsibilities
for the activities.

00:01:08.740 --> 00:01:12.760
This is a typical example of a diagram
from the process domain.

00:01:13.900 --> 00:01:15.760
Next, we are going
to have a quick look

00:01:15.760 --> 00:01:18.920
at the "RACI matrix"
that comes with the YaSM model.

00:01:19.700 --> 00:01:22.039
This matrix describes
the participation

00:01:22.039 --> 00:01:25.459
by the various YaSM roles
in the YaSM processes,

00:01:26.000 --> 00:01:28.060
so what we have here
is an example of

00:01:28.069 --> 00:01:29.859
how the
human resources domain

00:01:29.859 --> 00:01:32.279
is covered in the
YaSM Process Map.

00:01:34.260 --> 00:01:35.960
So much - very briefly -
about

00:01:35.969 --> 00:01:38.509
the process and role views
in the YaSM model,

00:01:38.740 --> 00:01:41.600
and now let's have a closer look
at the data domain.

00:01:42.260 --> 00:01:46.060
A key diagram from the data domain
is the YaSM data model.

00:01:46.600 --> 00:01:48.240
You can open it
from the front page

00:01:48.240 --> 00:01:49.440
and, as you can see,

00:01:49.440 --> 00:01:50.600
it is rather large

00:01:50.609 --> 00:01:52.859
because it provides
a complete overview

00:01:52.859 --> 00:01:56.179
of all documents and records
used in the YaSM framework,

00:01:56.420 --> 00:01:58.300
with their key relationships.

00:01:59.640 --> 00:02:01.980
If we zoom in on the objects
that play a role in

00:02:01.989 --> 00:02:02.749
• incident management,

00:02:02.749 --> 00:02:03.560
• service request

00:02:03.560 --> 00:02:04.720
• and problem management,

00:02:04.720 --> 00:02:06.820
we get to see,
for example, that

00:02:06.820 --> 00:02:09.560
"incidents" may be related
to "incident models"

00:02:09.560 --> 00:02:11.980
which describe how best
to resolve them,

00:02:12.660 --> 00:02:13.480
and also that

00:02:13.480 --> 00:02:15.600
"incident records"
are typically related

00:02:15.610 --> 00:02:17.750
to "configuration item records"

00:02:17.920 --> 00:02:20.800
- which may represent a piece of
hardware or software

00:02:20.800 --> 00:02:22.520
affected by the incident.

00:02:23.440 --> 00:02:25.300
So this data model
provides you with

00:02:25.300 --> 00:02:27.860
a complete overview
of the YaSM objects,

00:02:27.860 --> 00:02:29.740
and it helps you with
understanding

00:02:29.750 --> 00:02:33.090
the relevance of each object
within the YaSM framework.

00:02:33.800 --> 00:02:36.360
From the data model
you can also easily access

00:02:36.360 --> 00:02:39.520
more detailed information
about every object, because

00:02:39.530 --> 00:02:42.690
the shapes are linked with "checklists"
or "document templates".

00:02:43.500 --> 00:02:46.360
In this case, the checklist for the
incident record

00:02:46.360 --> 00:02:49.700
describes the typical contents
of such records.

00:02:51.520 --> 00:02:53.600
The second link
takes you to a diagram

00:02:53.610 --> 00:02:57.150
with a complete view of the
lifecycle of incident records:

00:02:57.700 --> 00:02:58.840
It shows where,

00:02:58.840 --> 00:03:00.120
in which YaSM processes,

00:03:00.120 --> 00:03:02.020
such records are
• created,

00:03:02.020 --> 00:03:03.040
• updated,

00:03:03.040 --> 00:03:03.660
• read

00:03:03.660 --> 00:03:04.960
• and archived,

00:03:05.520 --> 00:03:08.200
and you also get to see
how their status changes

00:03:08.200 --> 00:03:11.600
as they are handed over
from one process to another.

00:03:12.660 --> 00:03:13.620
Here, for instance,

00:03:13.620 --> 00:03:17.500
an incident record changes its status
from "open" to "resolved"

00:03:17.500 --> 00:03:20.180
after being resolved
in "1st level support",

00:03:20.680 --> 00:03:22.340
and then it's
set to "closed"

00:03:22.350 --> 00:03:23.720
by a specific process

00:03:23.720 --> 00:03:27.020
for the formal closure of
incidents and service requests.

00:03:28.240 --> 00:03:28.940
Of course,

00:03:28.940 --> 00:03:30.640
if you'd like to
check out precisely

00:03:30.650 --> 00:03:33.350
what needs to be done by whom
to close an incident,

00:03:33.350 --> 00:03:35.710
you can
- as always in the YaSM model -

00:03:35.710 --> 00:03:39.590
click on the link in the process shape
to open the process diagram.

00:03:40.040 --> 00:03:43.140
So it's very easy to move around
in the YaSM model

00:03:43.150 --> 00:03:45.410
and to drill down
into details.

00:03:46.860 --> 00:03:49.020
Now let me close this diagram

00:03:49.020 --> 00:03:50.400
- and also this one -

00:03:50.660 --> 00:03:52.180
because I also
want to show you

00:03:52.190 --> 00:03:54.110
another part of the
YaSM data model:

00:03:54.340 --> 00:03:56.880
the area around
the "service definition".

00:03:57.860 --> 00:04:00.560
The service definition is
a key document in YaSM,

00:04:00.560 --> 00:04:03.640
because there is one such document
for each service,

00:04:03.640 --> 00:04:05.920
defining the service properties.

00:04:06.480 --> 00:04:08.340
As we can learn from
the data model,

00:04:08.340 --> 00:04:11.360
the "service portfolio"
- which lists all services -

00:04:11.360 --> 00:04:14.200
contains a collection
of service definitions.

00:04:15.080 --> 00:04:18.820
And "customer service agreements"
refer to the service definitions,

00:04:18.820 --> 00:04:20.199
because in each agreement

00:04:20.199 --> 00:04:24.079
we need to specify the service
- or services - to be delivered.

00:04:25.580 --> 00:04:26.879
It goes without saying

00:04:26.879 --> 00:04:28.559
that also for the
service definition

00:04:28.560 --> 00:04:30.360
you can easily open
a checklist

00:04:30.370 --> 00:04:33.690
that describes the typical
contents of such documents.

00:04:34.880 --> 00:04:36.860
This checklist is a
Word™ document

00:04:36.860 --> 00:04:38.860
and you can use it
as a template

00:04:38.860 --> 00:04:42.700
if you need to create service definitions
in your organization.

00:04:44.000 --> 00:04:45.760
And again there is
a second link,

00:04:45.760 --> 00:04:48.000
taking you to the
"lifecycle diagram"

00:04:48.000 --> 00:04:49.720
showing in which
YaSM processes

00:04:49.729 --> 00:04:52.049
the service definitions are
• created,

00:04:52.049 --> 00:04:52.889
• updated,

00:04:52.889 --> 00:04:53.480
• read

00:04:53.480 --> 00:04:54.720
• and archived.

00:04:57.480 --> 00:05:01.320
So much about the data views
contained in the YaSM Process Map.

00:05:01.680 --> 00:05:04.960
Our data model a very good
starting point for understanding

00:05:04.969 --> 00:05:08.329
what the different documents
and records in YaSM are good for.

00:05:09.100 --> 00:05:11.419
Just in case you find this
a bit overwhelming,

00:05:11.419 --> 00:05:13.099
I'd like to add that,
of course,

00:05:13.100 --> 00:05:14.379
you don't have to create

00:05:14.379 --> 00:05:17.319
all those documents and records
in your organization.

00:05:17.960 --> 00:05:19.740
YaSM is not a standard,

00:05:19.749 --> 00:05:21.999
and you are free to work
with only those documents

00:05:21.999 --> 00:05:23.419
that you find useful.

00:05:24.360 --> 00:05:25.620
In the YaSM Wiki

00:05:25.629 --> 00:05:29.009
you can check out and download
the complete YaSM data model,

00:05:29.220 --> 00:05:30.900
and if you have
any questions,

00:05:30.900 --> 00:05:32.060
please get in touch.

00:05:32.780 --> 00:05:34.440
[ yasm.com ]

00:05:34.440 --> 00:05:36.960
[ More videos and all you need to know
about the YaSM Process Map. ]

00:05:36.960 --> 00:05:39.180
[ Please get in touch with us
if you have any questions! ]

00:05:39.180 --> 00:05:42.540
[ Our free YaSM Wiki provides
a complete introduction to YaSM. ]

