USM’s unambiguous and logically repeatable definition of a service can help limit the confusion around service and request catalogs. We’ll use the service tree as an example.
A service tree is a hierarchical representation of the various services provided by an organization or a service provider. It provides a structured view of an organization’s services, their categorization, and their relationships. The service tree is a strategic document that helps align IT services with business needs.
At level 4 of the USM Value Maturity Model, services focus on outcomes.
A service catalog is a customer perspective of the service, supporting a strategic fit.
A request catalog is a user perspective of the service catalog, addressing specific user requests, and the day-to-day handling (i.e., procedures/work instructions) associated with user interactions.
Requests tend to focus on outputs.
For example, ‘support’ is not a standalone service. ALL services include support (a service is a supported facility). It’s the combination of goods and actions (aka, the facility) that customers want, and support requests are always in the context of the facility being provided to customers and users.
These requests are realized with the USM workflows and provide specific outputs, but it is the combination of multiple requests that provide successful customer outcomes.
A common challenge when creating service trees is the lack of a logically repeatable definition of a service. The typical result can be the creation of a request catalog which — while needed for operations and automation — may not provide clear linkages to successful customer outcomes (as defined by the customer!) if they are not clearly linked to services.
Scoping the Service Tree
Customers always take an end-to-end view of a service from their perspective. How long and complex the service supply chain or network that comprises ‘end-to-end’ is, is also a matter of perspective.
In addition, services almost always span organizational boundaries in spite of efforts to ‘compartmentalize’ them. A service tree can expand from a high-level portfolio view to a very specific supporting facility.
Keep in mind that the categorization and structure of the service tree will be iterated over time and continuously. The result should be a family tree structure that is broken down into individual services. The business will be (or should be) hyper-focused on external customers and external customer-facing business services – their value streams – which is why techniques such as Customer Expectation Management, Jobs to be Done Theory, Customer Journey Mapping, Design Thinking, and many others are used. This is consistent with ‘outside-in’ and ‘top-down’ design.
But we tend to implement bottom-up, and this is often where the true nature of the facility gets lost.
Services vs Service Management
When we use the Customer Expectation Management (CEM) approach, we identify things like Successful Customer Outcomes (SCO) and Moments of Truth (MOT)1.
These are efforts to understand the business process…
from the customer’s point of view.
Once a service is in production, it is operational, and as long as there’s no new wish, change or incident the only process the customer’s in from a USM perspective is the operate process. This is the customer’s perspective of the service. However, since customer requirements are under constant change and re-evaluation, we are constantly looking at the changing value streams from the customer’s perspective.
This is what drives wishes and changes, and how fast and how well we execute these (along with incident handling), is how the customer perceives the delivery of services – which is the result of the provider’s service management.
While it is true that the customer does not have a view into the details of the provider’s handling of wishes, changes, incidents, and requests, each of these touch points represent Moments of Truth (MOT).
The recursive nature of services and the pace of change today make iterating the customer view and the user view of the service catalog an ongoing, and challenging, exercise!
Creating Service Trees with USM
In USM, a service is a supported facility. Remember that your service is just one link in an often-complex chain or network of services. There may be many standardized requests in even a single service, so keep it simple and use the Customer-Provider Interaction Model as a guide. Remember, we are all providers and customers at the same time!
It is not necessary to define the specific support requests associated with the service at this stage. Just list the facilities and customer(s) (who agree to the service). If desired, you can identify key users or user groups as well. This is basically getting agreement on the customer-provider diagram for the targeted service.
Defining Services and Service Agreement Structure
Describe the facility for each service in terms of goods and actions provided, and characterized by functionality (i.e., what it does) and functioning (i.e., how well it does it). This will require some evaluation as to whether an action is being provided as part of the nature of the facility, or the action is a support request that is made by the customer. It is not necessary to split hairs at this point; but by identifying them you can fine-tune your service definition over time.
Then describe the support included, and characterize that as well by functionality (i.e., what kind of support you get) and functioning (i.e., how well that support should be delivered).
Note that for all services, support will include the functionality and functioning of all customer-facing process triggers as defined by the non-redundant USM process model:
- Wishes
- Change requests
- Failure recovery (Incidents)
- Service requests
These are the reactive triggers for the USM workflows that are customer driven. The requests in a request catalog will be mapped to one of the USM workflows triggered by these support requests, and linked to services.
Dependencies, Relationships and Documentation
For each service, identify the relationships and dependencies. This could include internal and/or external services; link to existing agreements (OLAs / UCs) if possible.
Identify the key managed infrastructure components that the service is dependent on and where information about these components can be found.
Linking to the Request Catalog
For each service, list the typical requests customers and users will make when using the service. For each request, identify the USM workflow type associated with the request. Note that the procedure should identify which team is responsible for the request, and the work instruction should identify the technical instructions and what tooling can be used to fulfill the request.
Iteration of the Service and Request Catalogs
Building out a request catalog and service tree will take time and is an ongoing activity.
The procedures and work instructions associated with these activities can leverage ITIL’s service portfolio, catalog, and request management practice areas.
By using USM’s unambiguous and logically repeatable definition of a service, all service teams can create unified building blocks that can be combined into endless service chains and networks.
In addition — by leveraging USM’s simple, non-redundant process model and eight standard workflows for ALL services and requests — the USM method can:
- Simplify maintenance of both service and request catalogs.
- Improve service agreements and reporting.
- Enable a unified view of improvement actions.
- Make all operational actions visible.
Service definition is an ongoing program of work and a critical aspect of service management.
- CEM defines a Level 1 business process as ONLY Moments of Truth, i.e., it is the business process as seen by the customer. This actually highlights the importance of service management to the customer experience…since the complete customer experience — which happens over time — includes not only those MOTs that are directly part of an operational/production service, but the USM touch points (Wishes, Changes, Requests, Incidents) as well.
In fact, some of these touch points/MOTs could be impacted by other ‘links in the chain’ that are invisible to the customer…just as lower-level business processes that do not directly touch the customer but impact a customer touch point/MOT.
The overall customer experience, over time, includes all these interactions, which are supported across the service supply chain by each of the providers’ routines. USM’s systems thinking approach therefore is ideally suited to anyone who wants to establish and sustain ‘XLAs’ across diverse service ecosystems. ↩︎