The YaSM Process Map: Introduction

This video on YouTube | Read the full transcript.


Process templates for your enterprise service management or ITSM initiative. - Start here if you are looking for an introduction to the structure and the contents of the YaSM process model.

For organizations that want to get serious with introducing YaSM and best-practice service management or ITSM processes we offer a complete and detailed process model with ready-to-use process diagrams and document templates, called the "YaSM® Process Map".

Resources and further information

More videos
Related pages

Video transcription

Hello, I am Stefan Kempter, and today I am going to present the YaSM® Process Map: a set of process diagrams and document templates for organizations that want to get serious with introducing YaSM.

These diagrams and templates are the ideal tool for developing a sound understanding of service management best practice, and they will save you a lot of time and work when designing and documenting the service management processes in your organization.

The YaSM® Process Map is available in English and German for Visio® and ARIS™

So you can get the process model as a set of Visio diagrams or as a complete ARIS process model. The contents are always the same.

Since Microsoft Visio is a very popular application, I'm going to do today's presentation in Visio.

But first I have a couple of slides here to explain the basic principle behind our product. That principle is actually quite simple:

Structure of the service management model

The YaSM® Process Map is a collection of process diagrams, neatly arranged in several layers of detail in the form of a pyramid:

All in all there are some 120 process diagrams contained in the YaSM process model.

And now let's switch over to Visio to see how we have implemented this in the form of Visio diagrams.

Top level diagram: Service lifecycle and supporting service management processes

Here is, first of all, the "top level diagram" with a complete overview of the YaSM processes at the highest level of detail.

At the top we have the service lifecycle processes,

Below the service lifecycle we can see the supporting service management processes, for example

Overview diagrams for every YaSM main process

Now, if we want to know in more detail what's going on in, say, service operation, we can simply click on a link and go down to the next level of detail, where we find a diagram with more details about service operation.

I'll zoom in in a second, but first let me explain

Information flows in the YaSM process model

As you can see we use two types of shapes in these diagrams: The green shapes represent processes and the orange shapes represent data objects or information objects.

We use the information objects to show the information flows between the processes - and that's a very imported principle in our process model, because we want to show you not only what processes are there but also how the YaSM processes cooperate.

Here, for example, we can see that "incident management" sends all the "incident records" to the "problem management" process, where the problem manager would further analyze the incidents. If, based on the analysis, the problem manager detects a problem and is able to provide a "workaround" for some type of incident that happens fairly often, then a "problem record" with a description of the workaround will be sent back into incident management where it will help with resolving future incidents.

So this is how the loop is closed between the incident and problem management processes, and this is how we show in these diagrams how things work in YaSM.

What's more, if you click on a process shape like this one and if you then look at the right hand side of my screen, you can see that, in the "shape data window", we have a number of attributes attached to the shape. So the process shape here does not only have a name, but it also has a field where you can find a brief description of the process.

The same applies to the data object shapes: If you click on the incident record shape, you can see that this shape also has a name and a brief description here in the shape data fields.

Now, it's nice to have such a brief description, but of course a lot more can be said about an incident record! That's why such data object shapes are often linked to checklists.

Checklists and document templates

YaSM checklists are Word™ documents - and they can be opened with a link as you might almost expect.

If I click on the link, that will open Word™ and, as you can see, the checklist for the incident record describes in quite a bit of detail the structure of the data we would typically expect to find in such a record.

There are some 100 checklists of this kind in the YaSM® Process Map. There is another one, for example, for the "service definition". And because it's a Word™ document that can be modified, you can use the checklist for the service definition as a template or starting point once you need to create such documents in your organization.

Let's now close the checklist ... and go back to Visio - and explore what's behind the second link of the data object shape.

Object lifecycle diagrams

That link takes us to the object lifecycle diagram for the incident record, which tells you where - in what YaSM processes - such records are being

So these diagrams give you the complete picture at a glance, showing you how the documents and records flow between the YaSM processes.

And now, from this level of detail let's go down further, for example into the process for resolving incidents and service requests.

A detailed view of "incident management"

Again we take a link and that will open a diagram with more details about how incidents and service requests are being dealt with in YaSM. As before, we have inputs on the left, outputs on the right, and now in the center we have an overview of the sub-processes of incident management.

The first sub-process makes sure all incidents and service requests are being logged, and the other ones take care, for instance, of fulfilling service requests and resolving incidents.

As for resolving incidents,

So this diagram shows the major steps required for dealing with incidents and service requests, ...

Flowchart diagrams with activities

... and from here we can go down once more to the lowest level of detail contained in the YaSM® Process Map to the level of the sub-processes. Down here, as you can see, the diagrams look a bit different, because in the bottom part of these diagrams we now have a swim lane with "activities".

But let's first zoom in ...

Swim lanes are used to assign "responsibilities": The yellow shapes on the swim lanes represent "YaSM roles"; they indicate who is responsible for performing the activities in the swim lane.

Probably it's almost self-explanatory what the diagram here tries to tell us:

Then when these activities are complete, a decision needs to be taken: we need to decide whether we can resolve the incident here in 1st level support or not. That decision has a number of possible outcomes:

There are actually two end-points for this process:

And now, if you want to know: How does this go on from here? How is this going on in 2nd level support? Then you would look again into the upper part of the diagram:

The YaSM® Process Map at a glance

And that's what I wanted to show you today in this short video. To keep it short we concentrated on the most important components included in the YaSM® Process Map:

Our product also contains other components, such as

I'm not going into detail here, because we cover these components in other videos.


What's more, if you purchase a license, you'll also benefit from our services, which include

This service is free of charge during the first year.

So much for today. If you'd like to learn more about the YaSM® Process Map please get in touch with us. Thanks for watching - and take care!