YaSM and ITIL® V3 (Video)

Often when somebody asks me what YaSM® is about I say that it is like ITIL® - but less complex and easier to understand.

I think that's a good way of introducing YaSM, because a lot of people know that ITIL® offers advice for managing services, and that's also the kind of advice you will find in YaSM.

There are, therefore, lots of similarities between YaSM and ITIL®, but also differences:

We introduced some fresh ideas, a few simplifications and above all a very clear structure that makes the whole framework more accessible and ready-to-use.

So today I'd like to give you a better understanding of the similarities and differences by taking you through a couple of examples, and I want to show you how we managed to create a streamlined framework that is still very much in line with ITIL®.

Let's first take a look at the process structures of the ITIL and YaSM frameworks.

ITIL V3 (ITIL 2011) and YaSM: A comparison of the process structures

At the left, we have the ITIL service lifecycle with five stages:

• Service strategy,
• service design,
• service transition,
• service operation
• and continual service improvement.

Each stage of the lifecycle contains several processes. All in all there are 26 processes in ITIL V3 2011.

The figure at the right shows the top-level processes for YaSM.

There are fewer processes (17), and at first sight we recognize the same service lifecycle approach as in ITIL V3. But YaSM doesn't assign every process to a lifecycle stage: Instead there are a number of supporting processes - and this makes the whole structure of the model simpler.

Now you might say that 17 processes are still a lot, but you don't have to implement all of them. You can pick those processes that offer the most benefits for you - which is easy enough because of YaSM's simple process structure.

So there are fewer processes in YaSM, and in case you wonder what's missing in our new framework I'd like to show you a couple of examples, to assure you that nothing has fallen through the cracks.

Where YaSM is simpler: Change management and request fulfilment

My first example is about managing changes:

ITIL V3 suggests we should have a change management process and another one for evaluating changes. In YaSM we think a single process for assessing and evaluating changes is perfectly capable of doing the job, so this makes one process less.

The next example is about managing incidents and service requests.

ITIL V3 introduced two separate processes, but big parts of these processes follow the same pattern. Therefore, a lot speaks for combining them into one single process - which, by the way, worked very well in the times of ITIL® V2.

These were two examples where we could easily reduce the number of processes.

An example for established best practice: Incident management

But there are also areas where YaSM follows the ITIL® advice rather more closely, for instance in incident management:

ITIL suggests that incident management should include activities for

• Logging and categorizing incidents
• Resolving major incidents
• Resolving incidents in 1st level support ...
• ... and in 2nd level support
• and also for the formal closure of incidents.

Open incidents should also be monitored while support staff is busy resolving them, and users should be kept up to date about the progress.

This will probably look very familiar to you because this way of dealing with incidents is used in many organizations. It's established best practice and works well, so we included an identical process in the YaSM model. It simply didn't make sense to reinvent the wheel.

Example for simpler process interfaces in YaSM: Service design

Now, my fourth and last example is about service design, a rather difficult ITIL V3 process where we had to inject some fresh ideas to make it less complex.

According to ITIL, service design includes quite a few processes: At the center, we find a coordination process that calls upon other design processes, such as

• Capacity management
• Availability management,
• IT service continuity management,
• Supplier management and
• Information security management.

Two more processes are responsible

• for managing service levels
• and for managing the service catalog.

The problem here is that we end up with complex process interfaces, and that means figuring out how service design is supposed to work is not easy.

So how can we simplify this in YaSM? We have to remind ourselves that service design is about, well, designing services, and as such it needs to include

• activities for defining the required service properties,
• designing the required infrastructure,
• outlining the implementation approach
• and preparing the service implementation.

And when the service design phase is complete, everything is ready for the service implementation.

This is a pretty straightforward description of service design that's easy to understand - but now you might ask, isn't this too simple and where did all the ITIL processes go? For example, where are capacity and availability management?

Well, the real point is that we need to manage service capacity and availability, and in YaSM this is done by taking service capacity and availability into account at every stage of the service lifecycle:

• At the strategic level, we try to come up with forecasts of how the service capacity and availability requirements will evolve in the longer term.
• During service design, we define the capacity and availability requirements of new or changed services in detail, in the form of service level targets.
• Then we set up the services in a way that capacity and availability requirements can be met,
• and during service operation we measure actual service capacity and availability and produce service quality reports.
• Finally, if it turns out that the services do not deliver the required levels of capacity and availability, we take corrective action and implement service improvements.

So as you can see, we can do without capacity and availability management processes in YaSM, but of course we ensure that service capacity and availability are taken care of, and the necessary activities are still there.

And this leads to much simpler processes, as I'd like to show you, very briefly, in the YaSM model for Visio®:

The YaSM model: Ready-to-use process diagrams and checklists

This model contains a complete set of Visio diagrams with detailed descriptions of the YaSM processes. Since the YaSM® Process Map is the subject of quite a few other YaSM videos, we skip the introductory part and take the link from the top-level diagram to go straight into service design, to check out how services are being designed in YaSM.

What we get to see is, first of all, a high-level view of service design. As explained before, service design in YaSM is quite straightforward and includes

• defining the required service properties,
• designing the required infrastructure,
• outlining the implementation approach
• and preparing the service implementation.

Now, if we go further, say into the process for defining the required service properties, we find the recommended steps - or activities - for defining a service.

And here we can see the activities for defining the capacity and performance targets, as well as for defining the availability targets. In this way, we ensure that service capacity and availability are taken care of when designing services, and I hope you will agree that it's easy enough to understand how this is supposed to work.

Obviously, the capacity and availability targets must be documented somewhere - in the service definition document that we find in the upper part of this diagram among the process outputs.

For such documents, YaSM includes checklists that describe their typical contents. If we open the checklist, we can see that this particular one describes the information that should usually be contained in service definitions.

And if we scroll down a little, we find the section that specifies the availability requirements for the service, and a bit further down we have also the section that describes the capacity and performance targets.

So the YaSM model not only describes the YaSM processes in great detail, but you also get ready-to-use document templates. With these, creating your first service definitions should not be too much of a challenge.

And that's it for today.

I hope I was able to get across that YaSM is not simply a kind of stripped-down ITIL® ("ITIL® Light"), but a complete service management model that we created by injecting lots of fresh ideas into the ITIL® recommendations.

Our prime objective was a perfectly clear structure so YaSM is easy to understand.

If you would like to learn more about YaSM, please visit yasm.com - where you will find a complete Service Management Wiki and more videos about YaSM.

And if you have questions, we are happy to answer them!