Watch this video on YouTube | Download MP4 | Transcript | All YaSM videos.
The service management processes create and use a number of documents and records, such as service definitions, the service portfolio, cstomer service agreements, and incident records.
The 'YaSM data model' and the 'object lifecycle diagrams' in the YaSM® Process Map provide an overview of these YaSM data objects and their key relationships.
If you have some experience with enterprise modeling and describing the essential components of a business, you will know that enterprise architectures usually cover different domains, such as
required by the organization to operate.
Looking at the way in which a business works is very important to get the full picture, and therefore the YaSM model also includes different types of views.
I presented many of them in earlier videos, and today we are going to take a look specifically at the "data model" and other data views contained in the YaSM Process Map.
But let's first recap a little:
The YaSM Process Map includes process diagrams of various types, such as this one which provides an overview of the incident management process, including the information flows between the processes. For each incident management sub-process you can open a swim lane diagram that describes the activities to be performed within the process. The lanes are labelled with "roles" to describe the responsibilities for the activities.
This is a typical example of a diagram from the process domain.
Next, we are going to have a quick look at the "RACI matrix" that comes with the YaSM model. This matrix describes the participation by the various YaSM roles in the YaSM processes, so what we have here is an example of how the human resources domain is covered in the YaSM Process Map.
So much - very briefly - about the process and role views in the YaSM model, and now let's have a closer look at the data domain.
You can open YaSM data model from the front page and, as you can see, it is rather large because it provides a complete overview of all documents and records used in the YaSM framework, with their key relationships.
If we zoom in on the objects that play a role in
we get to see, for example, that incidents may be related to "incident models" which describe how best to resolve them, and also that incident records are typically related to "configuration item records" - which may represent a piece of hardware or software affected by the incident.
So this data model provides you with a complete overview of the YaSM objects, and it helps you with understanding the relevance of each object within the YaSM framework.
From the data model you can also easily access more detailed information about every object, because the shapes are linked with checklists or document templates. In this case, the checklist for the incident record describes the typical contents of such records.
The second link takes you to a diagram with a complete view of the lifecycle of incident records: It shows where, in which YaSM processes, such records are
and you also get to see how their status changes as they are handed over from one process to another.
Here, for instance, an incident record changes its status from "open" to "resolved" after being resolved in 1st level support, and then it's set to "closed" by a specific process for the formal closure of incidents and service requests.
Of course, if you'd like to check out precisely what needs to be done by whom to close an incident, you can - as always in the YaSM model - click on the link in the process shape to open the process diagram. So it's very easy to move around in the YaSM model and to drill down into details.
Now let me close this diagram - and also this one - because I also want to show you another part of the YaSM data model: the area around the service definition.
The service definition is a key document in YaSM, because there is one such document for each service, defining the service properties. As we can learn from the data model, the service portfolio - which lists all services - contains a collection of service definitions.
And customer service agreements refer to the service definitions, because in each agreement we need to specify the service - or services - to be delivered.
It goes without saying that also for the service definition you can easily open a checklist that describes the typical contents of such documents. The 'Service definition' checklist is a Word™ document and you can use it as a template if you need to create service definitions in your organization.
And again there is a second link, taking you to the lifecycle diagram showing in which YaSM processes the service definitions are created, updated, read and archived.
So much about the data views contained in the YaSM Process Map. Our data model a very good starting point for understanding what the different documents and records in YaSM are good for.
Just in case you find this a bit overwhelming, I'd like to add that, of course, you don't have to create all those documents and records in your organization. YaSM is not a standard, and you are free to work with only those documents that you find useful.
In the YaSM Wiki you can check out and download the complete YaSM data model.
If you have any questions, please get in touch!