The YaSM Process Map: Introduction (Video)

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 about 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:

• At the top of the pyramid we have a diagram with a complete, high-level overview ("top level diagram") of the YaSM processes. This is the main entry point into the process model, and from here we can drill down into details by following hyperlinks.
• Going down to the next level we will find a set of 17 diagrams: one diagram for each YaSM main process. An example for such a main process would be "service design".
• From this main process level we can go down further to the levels 3 and 4 with the sub-processes, where we finally get to see swim lane diagrams with single activities. So down here at the sub-process level, we explain in quite a bit of detail what needs to be done by whom and in what sequence.

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,

• for establishing a service strategy,
• for designing,
• building
• and operating services,
• and for continual service improvement.

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

• for assessing and coordinating changes
• or for managing projects.

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

• that on these diagrams we always get to see "inputs" at the left. So here at the left we have the other YaSM processes and the inputs these processes send into service operation.
• At the right we have the "outputs" from service operation and where they go to
• and in the middle we have the processes from service operation, which include the well-known processes for resolving incidents and service requests, and for dealing with problems.

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

• created,
• updated,
• read,
• and archived.

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,

• there is one process specifically for dealing with major incidents,
• and another one for resolving incidents in 1st level support.
• And - if 1st level support cannot do anything about an incident it will go on to the specialists in 2nd level support.
• Finally, once the incidents and service requests have been resolved, they will be formally closed down here.

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 ...

• ... on the top area where, first of all, at the left we have all the inputs required for this process and where they come from, and then to the right we have the outputs from the process and where they go to.
• Moving to the bottom part of the diagram we get to see a swim lane with activities.

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:

• It says that 1st level support should first carry out an initial analysis,
• search the knowledge base
• and try to match the incident with existing incidents or problems.

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:

• It could be that we cannot do anything about the incident here in 1st level support and it must be transferred to 2nd level support.
• Or we can actually resolve the underlying root cause for this incident: this would be ideal!
• If we cannot resolve the root cause maybe we have a workaround at hand.
• Or - if that's not the case - maybe we have an idea for a new workaround. Then we would apply the new workaround ...
• ... and so on ...
• ... until the process ends here at the right hand side.

There are actually two end-points for this process:

• We either managed to resolve the incident, by resolving the root cause or by applying a workaround.
• If we move up a bit we can see the second end-point: If we haven't been able to resolve the incident, we've passed it on to 2nd level support.

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:

• There you will find the incident record being passed along to the 2nd level support process.
• And if you click on the link behind that shape then you are taken right into the subsequent process where you can see how this goes on in 2nd level support.

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:

• The process diagrams
• and the document templates.

Our product also contains other components, such as

• a RACI matrix,
• a data model,
• an Excel® repository,
• and the "YaSM - ISO 20000 Bridge" (an optional component): a set of diagrams specifically for organizations that wish to get certified against ISO 20000.

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

Support

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

• updates,
• answers to your questions about YaSM
• and technical support.

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!