YaSM and ITIL® have a lot in common, but there are also differences. Above all, the YaSM framework has a very clear structure. And we introduced lots of fresh ideas that make the whole framework more accessible and ready-to-use.
In this video Stefan Kempter gives you a better understanding of the similarities and differences between YaSM and ITIL by taking you through a couple of examples, and he shows you how we managed to create a streamlined framework that is in line with ITIL and covers all key aspects of service management best practice.
Please ask your questions and share your thoughts in the YaSM support community!
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.
At the left, we have the ITIL® service lifecycle with five stages:
Each stage of the lifecycle contains several processes. All in all there are 26 processes in ITIL®.
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®. 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 framework 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.
My first example is about managing changes:
ITIL® 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.
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
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.
Now, my fourth and last example is about service design, a rather difficult ITIL® 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
Two more processes are responsible
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
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:
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®:
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
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 framework 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.
And if you have questions, we are happy to answer them in the YaSM support community!