VeriSM and YaSM

 

Comparison: YaSM and VeriSM™

Part of: YaSM vs. other service management frameworks and standards

 

Both YaSM and VeriSM™ are aligned with established service management best practice as described in ISO 20000, ITIL®, CMMI-SVC®, COBIT®, etc. But they are not the same:

While VeriSM™ [1] outlines an approach for managing services, YaSM® is a concise and detailed process model with ready-to-use templates for service management.

 

Fig. 1: VeriSM and YaSM service management
Process templates and diagrams for VeriSM projects.

What is the difference between YaSM and VeriSM?

VeriSM helps service providers understand the challenges and key principles of service management. It shows organizations how they can adopt a range of management practices to deliver the right service at the right time to their users.

VeriSM thus presents a high-level description of how services are defined, produced and provided, without being prescriptive about the low-level activities. Yet at some point, organizations need to go into detail and define their service management processes.

This can be a huge and difficult task, made easier by the YaSM model:

YaSM describes a complete set of service management processes, including their activities, responsibilities, inputs and outputs, and it provides ready-to-use process and document templates.

These service management templates are available in popular formats such as

• Visio®, Word®, Excel®,
• for BIC / BIC Process Design®,
• the ARIS Process Platform™,
• and also as BPMN XML documents.

All templates are fully editable, allowing organizations to design tailor-made processes without having to start from nothing.

Note: YaSM is not endorsed by the authors of VeriSM and YaSM cannot claim to be a 'VeriSM process model'.

Does VeriSM define processes?

VeriSM describes an approach to service management that allows organizations to adopt a range of management practices in a flexible way. It does not seek to replicate frameworks such as ITIL®.

For this reason, VeriSM does not provide detailed process specifications, nor does it recommend a range of specific processes that organizations should implement.

Yet VeriSM acknowledges that most business activities involve repeated tasks, and that defining and documenting processes has several benefits:

• For instance, documented processes allow the organization to define its preferred approach to managing specific tasks.
• Repeatable processes mean higher productivity and lower waste, as staff do not have to recreate an approach every time a task needs to be carried out.
• And with defined processes, metrics can be used to assess them and identify potentials for improvement.

So, processes definitely have a place in the VeriSM approach.

What's more, although VeriSM does not include an explicit list of processes, there are lots of hints between the lines:

For example, VeriSM advocates that organizations investigate repeat issues and proactively seek out potential issues. Turning this advice into practice will usually mean defining and implementing a problem management process. Another example would be the need to control changes, which calls for a change management process.

VeriSM stages and associated YaSM processes

VeriSM describes 'high-level stages' for products and services: Define, Produce, Provide and Respond.

These stages largely correspond to the service lifecycle that is the guiding principle of the YaSM process model, so the VeriSM stages are one area where VeriSM and YaSM are particularly well aligned.

The table below provides a first overview of the VeriSM 'high-level stages' and how they are associated with the YaSM service management processes.

The subsequent sections will then outline in detail how the YaSM processes, documents and templates are aligned with the VeriSM stages, and how YaSM provides detailed guidance for organizations that wish to adopt the VeriSM approach.

 

VeriSM™ stages and associated service management processes
VeriSM™ stage [1]	Associated YaSM processes
1 Define	LP1: Set the strategic direction LP2: Design new or changed services
2 Produce	LP3: Build new or changed services SP5: Assess and coordinate changes SP11: Manage suppliers
3 Provide	LP4: Operate the services LP5: Improve the services SP3: Manage customer relationships SP7: Ensure security SP8: Ensure continuity
4 Respond	LP4.6: Resolve incidents and service requests LP4.7: Resolve problems

(The VeriSM stages in this table are based on [IFDC, 2017])

 

VeriSM stage 1: Define

The Define stage in VeriSM starts when a client requires a new or changed service. This triggers activities to specify the requirements in detail and to design an appropriate service solution. The Define stage ends with the completion of a service blueprint that will direct the subsequent Produce stage.

The Define stage in the YaSM process model

In the YaSM process model, new services are introduced, or existing services modified if

• The need for new/changed services is identified during a strategic assessment
• Customers express the need for new/changed services

Major initiatives to develop new services are launched through the strategic process. In the case of minor ("non-strategic") service changes, the service design stage may be triggered, for example, from customer relationship management.

Once the business case for a new service has been approved, high-level requirements will be gathered, for instance in the form of a (draft) service definition. This information is an input for the service design process, where the new service and the implementation approach will be specified in detail. Several other YaSM processes are involved in the design activities to ensure all relevant aspects of the new service are considered, such as functionality, availability, capacity, continuity, security, compliance, infrastructure, supporting services, etc.

The two key outputs from the service design process in YaSM are

• The service definition, specifying the required properties of the new or changed service
• The service implementation blueprint, describing what capabilities are required for the new or changed service, and outlining the approach to creating the required service infrastructure and other capabilities.

The combined service definition and implementation blueprint documents in YaSM correspond to the service blueprint as stipulated in the VeriSM approach.

YaSM processes supporting the Define stage

Two YaSM processes are primarily responsible for launching service development initiatives and defining new or changed services:

• LP1: Set the strategic direction
• LP2: Design new or changed services

In addition, a number of other YaSM processes support to the definition of services, in particular:

• SP3: Manage customer relationships
• SP7: Ensure security
• SP8: Ensure continuity
• SP9: Ensure compliance

YaSM documents and templates supporting the VeriSM Define stage

The YaSM model provides several templates for the documents and records supporting the VeriSM Define stage, for example:

• Service portfolio
• Service definition
• Service implementation blueprint
• Register of security risks
• Register of managed critical events
• Compliance register

VeriSM stage 2: Produce

The Produce stage performs build, test and implementation activities, as outlined in the service blueprint. Change control is a key aspect in this stage to minimize risk and avoid unnecessary service disruptions.

The Produce stage in the YaSM process model

Once service design has defined the implementation approach, YaSM's service build process will create, test and deploy the required technical infrastructure, supporting services, documentation, etc.

The activities to be performed will depend on the nature of the required service components. Applications and systems may need to be acquired, developed or configured. If supporting services are provided by third parties, suppliers must be selected, and agreements put in place.

Regardless of their nature, all service components and deployment mechanisms are subjected to rigorous testing according to the service design. After successfully passing the tests, the components can be deployed into the live environment, and the new or changed service is ready for activation.

The change assessment process supports these activities to ensure changes are implemented in a controlled manner and do not cause unnecessary negative impacts.

The key outputs from the service build process in YaSM are

• Test documentation
• Updated configuration information
• The updated service portfolio with up-to-date service definitions
• Updated processes and policies
• Operational documentation, such as operating manuals, incident and service request models, recovery plans, etc.

YaSM processes supporting the Produce stage

The following YaSM process performs build, test and implementation activities for new or changed services:

• LP3: Build new or changed services

In addition, several other YaSM processes support to the implementation of services, in particular:

• SP1: Set up and maintain the service management system
• SP2: Maintain the service portfolio
• SP5: Assess and coordinate changes
• SP11: Manage suppliers

YaSM documents and templates supporting the VeriSM Produce stage

The YaSM model provides several templates for the documents and records supporting the VeriSM Produce stage, for example:

• Service definition
• Service implementation blueprint
• Service portfolio
• Service agreement
• Test script
• Test report
• Change record
• Change model
• Change schedule
• Service operation manual

VeriSM stage 3: Provide

In the Provide stage, the service provider operates the service and ensures the service continues to fulfil the agreed performance and functional requirements. This stage also includes activities to promote and market the organization"s service offerings.

The Provide stage in the YaSM process model

The Provide stage is mostly associated with the service operation process in the YaSM process model, which ensures that services are delivered effectively and efficiently, in line with the contractual commitments. In particular, this process performs routine operational tasks and produces service quality reports to measure if the services are delivered as expected.

In addition, the service improvement process collects information about service quality, determines potentials for improvement, and takes corrective action if necessary.

Security needs and service continuity requirements are addressed in the YaSM processes for service security and continuity.

Marketing activities are mostly performed in the YaSM process for managing customer relationships, which is responsible for acquiring new customers and establishing a mutually beneficial relationship with existing customers.

The key outputs from the provisioning processes in YaSM are

• Service quality reports
• Identified needs for corrective action
• Updated service definitions and operational documentation
• Updated configuration information.

YaSM processes supporting the Provide stage

The following two YaSM process are responsible for operating and, if necessary, improving the services:

• LP4: Operate the services
• LP5: Improve the services

In addition, several other YaSM processes support to the provision of services, in particular:

• SP3: Manage customer relationships
• SP7: Ensure security
• SP8: Ensure continuity

YaSM documents and templates supporting the VeriSM Provide stage

The YaSM model provides several templates for the documents and records supporting the VeriSM Provide stage, for example:

• Service operation manual
• Service definition
• Service portfolio
• Service quality report
• Service agreement
• Service improvement plan
• Customer portfolio
• Register of security risks
• Register of managed critical events

VeriSM stage 4: Respond

In the Respond stage, the service provider handles issues reported by customers, as well as service requests and other enquiries.

The Respond stage in the YaSM process model

The YaSM process model contains a specific process for the resolution of service incidents and fulfilment of service requests. It includes steps for gathering information about the reported issues, as well as for their classification, resolution and closure. The process also ensures customers stay informed about the status of any open issues.

Any knowledge gained from resolving service issues and answering inquiries is added to a knowledge base, often in the form of incident and service request models.

The investigation of repeat issues and proactive identification of potential issues is the responsibility of the problem management process.

The key outputs from these processes in YaSM are

• Records of submitted incidents and service requests
• Models (templates) for the resolution of incidents and fulfilment of service requests
• Records of identified problems (repeat issues)

YaSM processes supporting the Respond stage

The following two YaSM process are responsible for responding to customer inquiries, issues, requests etc.:

• LP4.6: Resolve incidents and service requests
• LP4.7: Resolve problems

YaSM documents and templates supporting the VeriSM Respond stage

The YaSM model provides several templates and checklists for the documents and records supporting the VeriSM Respond stage, for example:

• Incident Record (see also: free Incident record template in this wiki)
• Incident model
• Service request record
• Service request model
• Problem record

Other VeriSM elements and YaSM

The VeriSM Management Mesh

The Management Mesh in VeriSM is made up of the resources, environment, management practices and technologies used by the service provider organization.

The Management Mesh allows for flexibility, so organizations are able to pick from a variety of management practices, technologies etc., as required.

The YaSM model helps organizations that wish to include established service management best practice into their Management Mesh, by providing a streamlined set of processes and templates based on frameworks and standards such as ITIL®, ISO 20000, CMMI-SVC®, COBIT® etc.

Service management principles

VeriSM advocates that organizations define their service management principles to act as "guardrails" for their service teams.

A good starting point for establishing such principles are the principles underpinning the time-tested service management frameworks such as ITIL®, CMMI-SVC® and COBIT®, and also the requirements set out in ISO 20000, the international standard for service management.

Since the YaSM model is aligned with these frameworks and standards, it provides a solid basis for organizations in their effort to adopt sound service management principles

Governance

VeriSM describes governance as a 'system of directing and controlling'. Among the key aspects of good governance are transparency, accountability, responsiveness, effectiveness and efficiency.

The foundation of good governance are adequate policies and well-defined processes, for which the YaSM process model supplies ready-to-use templates.

Some organizations choose to get certified against ISO 20000, to ensure good governance in the longer term.

This is supported by the YaSM - ISO 20000 Bridge with templates that connect the YaSM processes with the ISO 20000 standard, describing a solution for every single requirement.

Progressive management practices

In addition to "traditional" service management guidance, VeriSM acknowledges that many organizations have started to adopt "progressive" practices in their quest to work smarter and become more flexible. These practices often have their roots in other areas such as manufacturing and software development, and include concepts such as DevOps, Agile, Kanban, Lean etc.

As a rule, the progressive management practices don't offer detailed guidance such as specifications of low-level activities to be carried out. They rather describe

• Principles
• Management techniques
• Approaches
• Values
• And even philosophies.

DevOps, for example, introduces the concept of cross-functional teams who manage a service across the whole lifecycle. And it puts the emphasis on automated and frequent deployment, helped by technologies such as virtualization and containerization. So DevOps is not an alternative to time-tested service management guidance, but a source of ideas for the design of better, leaner processes.

Since there is no fixed list of "progressive management practices" and every organization will have its own requirements, the YaSM process model is not specifically adapted to any such practice. Rather, YaSM provides a streamlined, straightforward set of processes and templates that give organizations the flexibility to build practices such as DevOps and Agile into their service management procedures.

Related articles

What is VeriSM™ - 'Value-driven, Evolving, Responsive, Integrated, Service Management'?

What is VeriSM™ - 'Value-driven, Evolving, Responsive, Integrated, Service Management'?

A short introduction to the VeriSM service management approach:
[ ... Read more ]

 

References

[1] IFDC (International Foundation for Digital Competences) (2017). VeriSM™ - A Service Management Approach for the Digital Age. Zaltbommel, Niederlande: Van Haren Publishing.

Notes

[1] VeriSM™ is a registered trademark of IFDC.
[2] ISO/IEC 20000® is a registered trademark of ISO.
[3] ITIL® is a registered trademark of AXELOS Limited.
[4] CMMI® und Capability Maturity Model® are registered trademarks of Carnegie Mellon University.
[5] COBIT® is a registered trademark of ISACA.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

 

Comparison: VeriSM and YaSM  › Does VeriSM define processes?  › VeriSM stages and associated processes