YaSM® was designed to be well aligned with the IT Infrastructure Library ITIL®[1] so that users familiar with ITIL will instantly recognize the common principles.
YaSM, however, is somewhat leaner and less complex. This was important to us because we think both large and small organizations should be able to benefit from service management best practice.
This does not mean that YaSM is simplistic: Every ITIL process serves a purpose, so YaSM does not merely omit a number of ITIL processes, as a number of approaches for "light" or "lean" ITIL would advocate. Rather, YaSM is less complex because it departs in some areas from ITIL's rigorous service lifecycle structure, and introduces a simpler and more intuitive process structure which distinguishes between "service lifecycle processes" and "supporting service management processes".
To understand why this leads to more simplicity, consider the following example: ITIL treats configuration management as part of service transition. But configuration management activities also occur elsewhere in the service lifecycle, and configuration information is needed as an input for virtually every ITIL process. This is why YaSM takes the view that it is more straightforward and intuitive to treat configuration management as a "supporting" process outside the service lifecycle.
What is more, the ITIL processes focus on managing services throughout their lifecycle, but there are no explicit processes for setting up and maintaining the service management processes themselves [2]. For example, ITIL describes an incident management process, but is less explicit about how the process comes into existence. YaSM addresses this issue by adding a number of additional supporting processes.
YaSM does not include the more "esoteric" details of ITIL, as it is meant to provide a streamlined and focused set of processes. YaSM's strategic process, for example, is considerably less extensive than in the ITIL books. Organizations using the YaSM model are thus able to start with a set of processes that is easy to understand and readily implementable. If more sophistication is needed in some process areas, users of YaSM can obtain additional guidance from various sources, including the ITIL publications.
Finally, ITIL and YaSM at times use different terminology because ITIL was originally written primarily for IT service providers, whereas YaSM is for any type of organization providing services. This often required the introduction of language that is more readily understood outside IT organizations.
ITIL processes and corresponding YaSM processes
As YaSM was written to be aligned with ITIL, there are one or several related YaSM service management processes for every ITIL process, as described in the following tables. The notes column contains further explanations on how YaSM relates to specific ITIL processes:
YaSM is an independent framework and is not officially endorsed by the owners of ITIL.
All ITIL processes in the following tables are linked to IT Process Map's "IT Process Wiki" where you can find the relevant descriptions of the ITIL processes.
The process structure in this table is based on ITIL 2011 Edition.
YaSM contains a streamlined strategic process which is broadly in line with ITIL, describing the activities for performing strategic assessments as well as crafting and executing the service strategy.
ITIL provides additional guidance and background information, for example about analyzing the internal and external environments and defining the service provider's position in the market spaces to be served.
Like ITIL, YaSM stipulates that the service provider's complete set of customer and supporting services is to be managed through the service portfolio.
YaSM's process for maintaining the service portfolio has a narrower focus than the service portfolio management process as described in ITIL: The YaSM process is mainly concerned with controlling changes to the service portfolio, ensuring its completeness and consistency, and publishing any service catalogs.
Decisions about the composition of the service portfolio (i.e. the mix of services to be offered to customers) are the responsibility of YaSM's strategic process.
Both ITIL and YaSM contain financial management processes which do not aim to describe all aspects of financial management, but are meant to highlight a number of financial management practices as related to service management.
ITIL offers more detailed advice in a number of areas: for example, it explains commonly used cost models and charging methods.
Instead of defining a separate demand management process, YaSM describes how several YaSM processes contribute to ensuring that demand for services is properly managed. In particular, services are designed for specific levels of demand in the service design process, and actual demand for services is measured and reported during service operation. If required, the service improvement process will initiate measures to cope with any issues related to service demand.
The ITIL publications provide additional guidance, for example on the concept of patterns of business activity.
YaSM's customer relationship management process is well aligned with the ITIL recommendations: It is responsible for maintaining a business relationship between the service provider and the customer and for understanding customer needs.
This includes communicating with customers on a regular basis, measuring customer satisfaction and dealing with customer complaints.
YaSM contains a specific process for managing projects which is tasked with coordinating all service development projects. This includes the coordination of service design activities.
A key output from YaSM's service design process is the "service implementation blueprint", which describes what capabilities are required in order to be able to offer a new or changed service, and outlines the approach to creating the required service infrastructure and other capabilities. The equivalent in ITIL is the "service design package (SDP)". The SDP is supposed to contain a considerable amount of additional information, such as various policies and plans. YaSM keeps such information in other documents.
Both ITIL and YaSM define service catalogs as specific views of the information contained in the service portfolio, but ITIL practitioners often seem to use the terms service catalog and service portfolio interchangeably. YaSM tries to avoid this confusion by mostly relating to the service portfolio.
The YaSM process for maintaining the service portfolio contains activities for publishing service catalogs and keeping them consistent and up to date, in line with updates to the service portfolio.
YaSM takes the view that several processes need to cooperate to manage service levels throughout the service lifecycle. Therefore, YaSM does not include a specific process for managing service levels.
The required service levels - as well as the required service functionality - are defined in the service design stage, based on the needs of the customer. Monitoring and reporting of the achieved service levels is the responsibility of service operation. The service improvement process will review the achieved service levels against the committed levels and initiate corrective action if required.
The service owners are ultimately responsible for delivering the agreed service levels and play a key role in these activities.
YaSM's customer management process is responsible for determining the expected service outcomes from the customer viewpoint as well as negotiating and signing customer service agreements.
For most service providers, agreements with their customers need to cover service level targets ("warranty"), but also the required service functionality ("utility") and some other aspects. For this reason YaSM refers to "customer service agreements", "operational service agreements" and "external service agreements" where ITIL uses the terms "service level agreements (SLAs)", "operational service agreements (OLAs)" and "underpinning contracts (UCs)".
ITIL provides some additional advice, for example on the design of SLA frameworks.
YaSM and ITIL stipulate that service availability must be managed, but YaSM does not contain a specific availability management process. Rather, service availability is treated as an aspect of services to be managed through the service lifecycle processes:
Availability requirements are defined during the service design stage, and services are then built with those requirements in mind. The operating process will be responsible for measuring the actually achieved availability levels, which allows the service improvement process to initiate corrective measures through service improvement plans if availability must be enhanced.
The ITIL books offer additional guidance, for example on how to design services and their underlying technical infrastructure for availability.
ITIL contends that "capacity management is a process that extends across the service lifecycle". Consequently, YaSM does not contain a specific capacity management process but treats service capacity and performance as aspects to be managed through the service lifecycle processes:
Capacity and performance requirements are defined during the service design stage, and services are then built with those requirements in mind. The operating process will be responsible for measuring capacity and performance levels, which allows the service improvement process to initiate corrective measures through service improvement plans if capacity must be adjusted or performance enhanced.
The ITIL books may be consulted for additional advice, for example with regards to capacity monitoring, analysis and tuning.
Both processes ("ITSCM" in ITIL and "Prepare for disaster events" in YaSM) focus on those events that are considered significant enough to be treated as a "disaster".
YaSM recommends that the disaster events against which the service provider has decided to set up some kind of protection are documented in a register of managed disaster events.
Service continuity plans describe how service continuity is ensured with regards to particular types of disasters. The implementation of the required continuity arrangements is managed through the continuity improvement plan.
Once a disaster event occurs, YaSM deals with it through the major incident resolution process. This process will establish a major incident team which is authorized to invoke suitable service continuity plans.
ITIL offers additional advice, such as examples of potential risks and threats as well as recovery options.
YaSM's process to ensure security does not relate specifically to "information security", since YaSM is a concept which can be applied by all types of organizations providing services (i.e. not only IT service providers).
ITIL recommends setting up an "information security management system (ISMS)", including a "security management information system (SMIS)". YaSM describes and documents the security management procedures within its process model and a set of security policies. The security risks to be managed are documented in the register of security risks, which also specifies the adopted risk responses. The implementation of security controls and measures is managed through the security improvement plan.
The ITIL publications contain additional advice, such as a list of recommended (supporting) security policies, and an overview of risk assessment and management methods.
The supplier management process described in YaSM is in line with the ITIL recommendations, with the following qualifications:
YaSM puts the service design process in charge of defining the requirements and deciding whether a supporting service should be provided by an internal or external party. Once this decision is taken, supplier management is called upon to select and establish suitable suppliers and to set up the external services.
The service operation process is responsible for monitoring the achieved service quality and producing service quality reports. This includes the monitoring of externally provided supporting services.
YaSM's service improvement process ensures that external services are reviewed on a regular basis. The findings from service reviews may lead to the identification and implementation of service improvements through a service improvement plan.
ITIL offers additional recommendations, for example criteria for the selection of new suppliers and suggestions for supplier categorization.
YaSM's project management process is responsible for the planning and coordination of significant service management initiatives, such as the creation of new or significantly changed services. This includes planning and coordination of the service transition phase.
ITIL takes a slightly different approach: The transition planning and support process is specifically meant to provide "overall planning for service transition projects". Some detailed transition planning is performed by two other ITIL processes, change management and release and deployment management.
The change assessment process described in YaSM is in line with the ITIL recommendations, with the following qualifications:
YaSM defines requests for change (RFCs) not as a separate data object type, but as the initial state of a change record that contains all information required to assess a proposed change. More information is added to the change record as it progresses through its life cycle.
YaSM does not distinguish between changes and change proposals.
ITIL suggests that some changes are evaluated at various points in their lifecycle, for example before build and test or prior to deployment. YaSM takes a simpler approach, assessing all proposed changes upon receiving a request for change, and performing a post-implementation review once the changes are implemented. The change owners as well as project, test and deployment managers are responsible for ensuring that the organization’s rules for planning, testing and implementing changes are observed and that the expected change benefits are realized.
YaSM's change assessment process assesses the risks associated with a proposed change but puts less emphasis on change planning or scheduling. For initiatives on a bigger scale, planning activities are typically performed by YaSM's project management process.
While ITIL stipulates that the change manager produce a list of projected service outages (PSO), YaSM suggests that operational staff is in a better position to maintain a "calendar of planned service outages". This calendar takes into account outages due to various reasons, such as change deployments, operational activities, security tests, ...
The configuration management process described in YaSM is in line with the ITIL recommendations, with the following qualifications:
YaSM's process for managing configuration information provides the framework for controlling configu-ration items and the related configuration information. In particular, the configuration manager is responsible for specifying what types of CIs are to be controlled, and who is authorized to modify those CIs and the related contents of the CMS.
The actual modifications to the CMS are mostly performed by other service management processes. The configuration manager will track and verify the modifications and perform regular audits of the information in the CMS.
With regards to status accounting, YaSM's configuration management process defines a suitable set of allowed states for each CI type, and relies on other service management processes to record the status changes.
YaSM's project management process is responsible for the planning and coordination of significant service management initiatives, such as the creation of new or changed services. This includes planning and controlling the build, test and deployment activities for new services and their underlying infrastructure.
The service build process ensures that all required service components are tested before being deployed and that configuration information in the CMS is updated as required. New services are only allowed to be activated once it has been confirmed that the organization is ready to operate the service.
ITIL offers additional advice, for example on the design of release packages and deployment options for IT infrastructure.
YaSM does not contain a separate testing process. Rather, the service build process contains the activities for testing the infrastructure and other capabilities required for a new or significantly changed service (see notes on ITIL process: Release and deployment management). The service build process will also initiate corrective action if the tests reveal defects in the service components.
The ITIL books contain additional information, such as an explanation of commonly used testing strategies and test types.
ITIL stipulates that certain types of (significant) changes should be subjected to a formal change evaluation process. There is no separate change evaluation process in YaSM. Instead, YaSM treats change evaluation as part of its change assessment process.
The YaSM model does not include a specific knowledge management process. YaSM takes the view that knowledge is managed and knowledge management principles are used in several service management processes. For example, the incident resolution process manages knowledge on how to deal with certain types of service incidents.
YaSM does not define a specific event management process. The service operation process includes activities for configuring the event monitoring systems as well as for monitoring events and selecting appropriate responses.
YaSM also states that the incident resolution process may be triggered when certain types of events are detected which require human intervention.
The ITIL publications contain additional guidance, for example on event filtering and correlation rules.
The process for resolving incidents and service requests described in YaSM is in line with the ITIL recommendations, with the following qualifications:
While ITIL suggests implementing two separate processes for managing incidents and service requests, YaSM takes the view that these processes are very similar in nature. There is thus one process in YaSM to deal with both incidents and service requests.
ITIL states that incident management is about restoring services as quickly as possible, while problem management is about diagnosing and resolving the underlying causes of incidents. Individual organizations, however, are given some freedom regarding the precise rules on when to invoke problem management from incident management. In this respect, YaSM adopts a simple approach: The incident resolution process takes all necessary action to resolve an incident, possibly by applying a workaround and involving experts in 2nd and 3rd level support. The problem resolution process is called upon only after the incident has been closed, for example in cases where the underlying cause of an incident is unresolved or unclear.
The process for resolving incidents and service requests described in YaSM is in line with the ITIL recommendations, with the following qualifications:
While ITIL suggests implementing two different processes for managing incidents and service requests, YaSM suggests that these processes are very similar in nature. There is thus one process in YaSM to deal with both incidents and service requests.
The problem resolution process described in YaSM is in line with the ITIL recommendations, with the following qualifications:
Since according to ITIL known errors are "problems with an identified underlying cause and a workaround", YaSM recommends storing information about underlying causes and possible workarounds as part of the problem records. ITIL advocates managing known errors in a "known error database (KEDB)".
If a problem resolution requires a change, YaSM's problem resolution process will describe the change and prepare a business case; the change is then typically implemented through a service or process improvement plan under the responsibility of a service or process owner.
ITIL offers additional background information, especially on problem analysis techniques.
YaSM does not contain a specific access management process. The service operation process includes activities for configuring the access control systems as well as for tracking access to services.
The security manager sets the rules for granting access to services by issuing a suitable security policy, and reviews the granted access rights at regular intervals.
Individual requests for access to a service are dealt with in the form of service requests.
The ITIL publications contain additional information, for example on how to apply user profiles for granting access rights.
The "seven-step improvement process" presented in the ITIL books is in fact the description of a methodology which can be universally applied to identify shortcomings in services and processes and to implement improvements.
The principles it advocates are engrained in a number of YaSM processes. One example is the service improvement process.
While YaSM is somewhat more streamlined than ITIL in many areas, there are also a number of YaSM processes which go beyond the ITIL recommendations. These processes were mostly introduced to improve the alignment of YaSM with other service management standards and frameworks, such as ISO 20000, COBIT®[3], USMBOK™ [4] and CMMI-SVC®[5].
The following table provides an overview of the additional processes and explains their purpose within the YaSM model:
ITIL focuses on managing services throughout their lifecycle, but is somewhat vague about how the service management processes come into existence.
ISO 20000 specifies requirements for service providers to "plan, establish, implement, operate, monitor, review, maintain and improve a service management system (SMS)", of which the service management processes are a key component.
This means there is a certain gap between ITIL and ISO 20000 which YaSM closes by introducing a specific process for setting up and maintaining the service management system.
According to ITIL, a number of processes perform coordinating activities, especially design coordination, transition planning and support, change management, as well as release and deployment management. The problem with this approach is that there are several coordination processes, each coordinating specific parts of service development projects.
YaSM prefers one central instance that is tasked with planning and coordinating all aspects of service development projects from beginning to end.
YaSM's project management process is also more versatile, because it can be applied not only when new services are being introduced, but also when other significant initiatives are to be managed (for example an upgrade to the service provider’s technical infrastructure on a bigger scale).
Compliance is becoming increasingly important for many organizations. For this reason, YaSM contains a specific process for ensuring compliance with laws, regulations, industry standards, etc., which highlights the most important compliance management activities and identifies the interfaces with the other YaSM processes.
This process also improves YaSM's alignment with COBIT and USMBOK, which both contain sections on ensuring compliance.
Skills and skill development are dealt with in several ITIL processes but there is no well-defined responsibility for the important task of managing human resources. This is why YaSM contains a human resources management process.
YaSM's HR process does not describe all aspects generally associated with managing human resources but focuses on developing the skills required to offer the service provider’s range of services.
This process also improves YaSM's alignment with ISO 20000 and CMMI-SVC, which stipulate that human resources should be properly managed.
ITIL functions and YaSM
Apart from a set of processes ITIL also describes a number of "functions". For instance, incident management is introduced as a process and facilities management as a function.
By definition, a function is an organizational entity, often characterized by a special area of knowledge or experience. Examples would be the human resources department or a team of experts operating a certain part of the technical infrastructure.
Processes, in contrast, are clusters of activities which produce a defined outcome, like the incident resolution process. Several functions may play their part in a process (the team of technical experts may have to perform some activities within the incident resolution process).
Much confusion stems from the fact that in the real world there are often functions and processes with identical names: For example, the human resources management team (a "function") will perform a set of HR-related activities, which as a whole are called the human resources process.
In this context, YaSM consists of a set of processes and does not specifically relate to functions or organizational structures.
Roles are the only type of organizational information described in the YaSM model: For example, the role of 1st level support figures in the incident resolution process, because 1st level support needs to perform a number of activities in this process. This notwithstanding, 1st level support agents will typically belong to an organizational unit or function, such as a support team headed by a support manager.
Once in a while I get asked during our webinars if YaSM is an alternative to ITIL. It almost seems quite a few people would like to avoid having to deal with ITIL - but is it a good idea to ignore it? [...]
YaSM is definitely lighter than ITIL (actually we decided to create YaSM because many of our customers looked for something lighter). But we don't want YaSM to be confused with what is often called "ITIL lite" or "lean ITIL" because we think the existing approaches are often flawed: [...]
AXELOS announced a new initiative to promote the usage of ITIL® in non-IT environments: Their aim is provide additional guidance, so that non-IT service providers are better able to benefit from ITIL. [...]
References
[Cabinet Office, 2011a]. -- The Cabinet Office: ITIL® Service Strategy (2011 Edition). - The Stationery Office; London, UK, July 2011.
[Cabinet Office, 2011b]. -- The Cabinet Office: ITIL® Service Design (2011 Edition). - The Stationery Office; London, UK, July 2011.
[Cabinet Office, 2011c]. -- The Cabinet Office: ITIL® Service Transition (2011 Edition). - The Stationery Office; London, UK, July 2011.
[Cabinet Office, 2011d]. -- The Cabinet Office: ITIL® Service Operation (2011 Edition). - The Stationery Office; London, UK, July 2011.
[Cabinet Office, 2011e]. -- The Cabinet Office: ITIL® Continual Service Improvement (2011 Edition). - The Stationery Office; London, UK, July 2011.
External links
[IT Process Wiki]. -- S. Kempter & Kempter, A.: "IT Process Wiki. -- The Wiki about the IT Infrastructure Library ITIL® (ITIL 2011, ITIL V3 & V2), ISO 20000 and IT Service Management (ITSM). - IT Process Maps; Pfronten, Germany.
[IT Process Wiki - ITIL Service Strategy]. -- S. Kempter: IT Process Wiki, "ITIL Service Strategy. - IT Process Maps; Pfronten, Germany.
[IT Process Wiki - ITIL Service Design]. -- S. Kempter: IT Process Wiki, "ITIL Service Design. - IT Process Maps; Pfronten, Germany.
[IT Process Wiki - ITIL Service Transition]. -- S. Kempter: IT Process Wiki, "ITIL Service Transition. - IT Process Maps; Pfronten, Germany.
[IT Process Wiki - ITIL Service Operation]. -- S. Kempter: IT Process Wiki, "ITIL Service Operation. - IT Process Maps; Pfronten, Germany.
[1] ITIL® is a registered trade mark of AXELOS Limited. - IT Infrastructure Library® is a registered trade mark of AXELOS Limited.
[2] ISO 20000 refers to the service management processes - and other elements like service management policies and plans - as the "service management system (SMS)".
[3] COBIT® is a registered trademark of ISACA (Information Systems Audit and Control Association).
[4] USMBOK™ is a Registered Trade Mark of Virtual Knowledge Solutions International Incorporated (VKSII).
[5] CMMI® and Capability Maturity Model® are registered trademarks of Carnegie Mellon University.
and Stefan Kempter 
