Chapter 12
Service Design Processes: Design Coordination and Service Catalog Management

THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:

  • ✓  Design coordination and service catalog management are discussed in terms of
    • Purpose
    • Objectives
    • Scope
    • Value
    • Policies
    • Principles and basic concepts
    • Process activities, methods, and techniques
    • Triggers, inputs, outputs, and interfaces
    • Information management
    • Critical success factors and key performance indicators
    • Challenges
    • Risks

 ITIL service design covers the managerial and supervisory aspects of service design processes. It excludes the day-to-day operation of each process and the details of the process activities, methods, and techniques, and its information management. More detailed process operation guidance is covered in the service capability courses. Each process is considered from the management perspective. That means at the end of this chapter, you should understand those aspects that would be required to understand each process and its interfaces, oversee its implementation, and judge its effectiveness and efficiency.

Design Coordination

Service design involves many different aspects beyond designing a new application to provide new functionality (utility). Consideration must be given to how the service will operate, both now and in the future; what level of availability, security, continuity, and capacity will need to be provided; and the best approach to this (warranty). Other processes will interface with the service design processes. To ensure a successful outcome, the design activities must be coordinated.

The Purpose of Design Coordination

The purpose of the design coordination process is to carry out the coordination of the many different activities of service design. The many processes and numerous interfaces involved are all potential sources of conflict. By providing a single point of contact, complications and misunderstandings are avoided.

The Objectives of Design Coordination

The objectives of design coordination are quite straightforward. They are to ensure that there is a consistent approach applied to design across all five aspects of service design. Design is a complex lifecycle stage. Coordination of the design activities is a key objective because the activities will spread across projects, teams, and suppliers as well as across the many conflicting demands, which need to be managed. This will include time, money, and resources related to day-to-day operational activities.

To make sure the design processes are effective, there needs to be coordination of the resources and capabilities in use by each process. A common challenge is that there may be overlapping requirements for the same resources, and this is why it is important to have this coordination capability in place. This is a higher-level or strategic objective—for example, in the long term, what skills and how many designers are needed? Design coordination should not be about individual resource management for specific processes.

The design coordination process is responsible for ensuring the delivery of the service design package (SDP).

This means that the process is also responsible for managing the interfaces between the service lifecycle stages, ensuring the quality of the inputs and outputs.

Design coordination should ensure conformance of designs to policy, architecture and regulatory, legal, security, and other governance requirements.

As with all processes, there will be an element of continual service improvement relating to the management of the service design lifecycle stage and its processes.

The Scope of Design Coordination

The scope of the design coordination process includes all design activity, particularly all new or changed service solutions that are being designed for transition into (or out of, in the case of a service retirement) the live environment.

Design coordination should only be applied as necessary. Some design efforts will be part of a project, whereas others will be managed through the change process alone, without a formally defined project. Some design efforts will be extensive and complex while others will be simple and swift.

Each organization will need to define the criteria that will be used to determine the level of rigor or attention to be applied in design coordination for each design.

When we consider the further scope of the design coordination process, it should include assisting and supporting each project or other significant or major change. The process will also be responsible for maintaining policies, guidelines, standards, budgets, models, resources, and capabilities for all service design processes and activities. At a strategic level, design coordination will be responsible for coordinating, prioritizing, and scheduling service design resources to satisfy conflicting demands from all projects and changes. This is a major challenge for most organizations. It will involve planning and forecasting the resources needed for the future demand for service design activities.

Because the process is responsible for ensuring the output from the design lifecycle stage, it will be engaged in reviewing, measuring, and improving the performance of all service design activities and processes. This will also ensure that all requirements are appropriately addressed in service designs, particularly utility and warranty requirements. The final activity for the service design coordination process is ensuring the production of service designs and/or SDPs and their handover to service transition.

The Value of Design Coordination to the Business

The main value of the design coordination process to the business is the production of a set of consistent quality solution designs and SDPs that will provide the desired business outcomes.

Design coordination will improve each of these:

  • Achieve the intended business value of services through ensuring that design takes place within acceptable risk and cost levels
  • Minimize the rework and unplanned labor costs associated with reworking design issues during later service lifecycle stages
  • Support the achievement of higher customer and user satisfaction and improved confidence in IT and in the services received
  • Ensure that all services conform to a consistent architecture, allowing integration and data exchange between services and systems
  • Provide improved focus on service value as well as business and customer outcomes
  • Develop improved efficiency and effectiveness of all service design activities and processes, supporting higher volumes of successful change delivered in a timely and cost-effective manner
  • Achieve greater agility and better quality in the design of service solutions within projects and major changes

Design Coordination Policies

It is important to ensure that the service design lifecycle stage has a structured and holistic approach to design activities. It is the responsibility of the design coordination process to provide guidelines and policies to allow for this holistic approach and the coordination to ensure that the practices are followed.

The service provider should define policies for which service design efforts require which type of attention from design coordination.

For example, the policy might specify that the design portion of all projects, as well as for all changes that meet specific criteria (such as major changes), should be coordinated individually, while other changes must simply adhere to predefined design standards for the corresponding change type. These design standards are likely to be embedded in the change model and associated documented procedures for executing changes of that type.

The level of required documentation should also be established and recorded as a policy. For design efforts that are part of a project or are associated with changes that meet specific criteria (such as major changes), a full SDP will be required. For other changes, if they are in scope, the service design may be documented very simply and may even be prebuilt if a change has been made before.

The following design coordination policies should be included:

  • Adherence to corporate standards and conventions
  • Explicit attention to governance and regulatory compliance in all design activities
  • Standards for elements of a comprehensive design for new or changed services
  • Criteria for resolving conflicting demands for service design resources
  • Standard cost models

Design coordination policies should provide for appropriate variations within acceptable parameters for designs of different types and scopes. The policies and standards established should result in the most appropriate SDPs, while the least possible time and effort should be expended to produce them. It is important that design coordination does not become a “blocker” to successful and efficient design activity.

Principles and Basic Concepts for Design Coordination

Arguably, the single most important guideline to be followed in design coordination is balance. The goal is a comprehensive design that addresses all aspects of utility and warranty as well as the needs of the service throughout its lifecycle.

It can be easy to set up standards or documentation requirements that create excessive bureaucracy without consistently returning better services to the business and/or customer. The goal should be to put just enough definition, measurement, and control of design activities in place to successfully manage the work and improve results, but no more.

Consider the best approach to integrate with project management in your organization. Each organization will have a different approach, and although it may be based on best practice, all organizations are able to “adopt and adapt” to meet their own requirements. It is important for design coordination to be seen as an enabler in the project lifecycle and to provide a positive influence and principles of best practice.

When implementing a formal design coordination process, a service provider should build on its current practices and leverage the steps of the continual service improvement (CSI) approach as a guide. Consider the examples in Table 12.1.

Table 12.1 CSI approach for design coordination implementation

CSI approach step Guidance
What is the vision? Consider how, in a perfect world, service design should work at your organization. Come to consensus among the key stakeholders regarding what you would like to create and what the critical success factors for service design should be.
Where are we now? As objectively as possible, assess the current state of service design activities. How are they performed now? By whom are they performed and under what circumstances? What are the challenges and weaknesses in the current approach? What is working well? Where do the greatest pain points exist in the current approach? What capabilities do we have or will we need to have? What risks exist? To the extent possible, collect baseline measurements of the performance of current practices.
Where do we want to be? Based on the overall vision for service design and the current state of these activities, agree on priorities for improvement. Improvement opportunities will exist in many processes that are active during service design, but the implementation of the design coordination process should provide for reliable, repeatable, and consistent overall practices for service design. Based on the agreed priorities, select the specific design coordination practices to implement, defining them clearly with SMART objectives (specific, measureable, achievable, realistic, time-bound).
How do we get there? Devise a detailed plan for how to move from the current state to the achievement of the agreed improvements, and then execute the plan.
Did we get there? Use the metrics associated with the SMART objectives to determine if the improvement (or improvements) to service design practices has been successfully implemented. If a gap still remains between the new current state and the desired state, additional work may be necessary.
How do we keep the momentum going? Use ongoing monitoring of the performance of service design practices to ensure that new or revised practices become institutionalized. Encourage feedback and suggestions for improvement from all other stages in the lifecycle.

Design Coordination Process Activities, Methods, and Techniques

We will now take a look at each of the activities in design coordination. You will find it helpful to refer to Figure 12.1, which shows the process flow.

Diagram shows the process flow for the overall service design lifecycle stage on left column and the process flow for each design on right column.

Figure 12.1 Design coordination process flow

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

In the figure, you can see that design coordination activities fall into two categories. It is important to note that the activities are applicable in two different ways.

Activities Relating to Overall Design

The activities relating to the overall service design lifecycle stage include the development, deployment, and continual improvement of appropriate service design practices as well as the coordination of actual design activity across projects and changes. These activities may be performed by design coordination process manager(s).

Activities Relating to Each Individual Design

These activities focus on ensuring that each individual design effort and SDP, whether part of a project or simply associated with a change, conform with defined practices and that they produce a design that will support the required business outcomes. These activities may be performed by a project manager or other individual with direct responsibility for the project or change, with the assistance and guidance of the design coordination process manager(s).

Triggers, Inputs, Outputs, and Interfaces

We will now consider the triggers, inputs, outputs, and interfaces to the lifecycle stages for the process of design coordination.

Triggers

All processes respond to a trigger. The triggers for the design coordination process are changes in the business requirements and services. The main triggers are requests for changes (RFCs) and the creation of new programs and projects. Another major trigger would be the revision of the overall IT strategy, which would require the review of design coordination activities.

Inputs

When we consider the inputs to the design coordination process, a number of sources of information are relevant. These include the following examples:

  • Service charters for new or significantly changed services
  • Change requests, change records, and authorized changes
  • Information about the organization’s business and IT strategy, financial plans, and its current and future requirements
  • Business impact analysis, providing information on the impact, priority, and risk associated with each service or changes to service requirements
  • The service portfolio, including the service catalog and the business requirements for new or changed services in terms of service packages and service options
  • Governance requirements
  • Corporate, legal, and regulatory policies and requirements

Outputs

The process outputs of design coordination include a comprehensive and consistent set of service designs and service design packages. The output may also require a revision of the enterprise architecture, management systems, processes, and measurement and metrics methods. Design coordination will ensure that the appropriate updates are made to current relevant change records and the service portfolio.

Interfaces

As you would expect, the principal interfaces to the adjacent stages of the lifecycle are using information contained within the IT strategy and service portfolio for service strategy and the handover of the design of service solutions within the SDP for service transition.

The interfaces between design coordination and other individual processes are many because this is a key collaborative process for the lifecycle stage of service design. As a consequence, it is possible to draw a connection between this process and a number of others:

  • Service portfolio management
  • Change management
  • Financial management
  • Business relationship management
  • Transition planning and support
  • Strategy management
  • Release and deployment management
  • Service validation and testing
  • Change evaluation
  • Service level management
  • Availability, capacity, continuity, and security (the warranty processes)
  • Supplier management

Information Management

When we consider the key information generated by the design coordination process, we have to review the material included in the SDP, which contains everything necessary to take the service through all other stages of the service lifecycle. The SDP is likely to consist of multiple documents. These documents should be included in the overall service knowledge management system (SKMS) and described by records about the information held in the configuration management system (CMS).

Critical Success Factors and Key Performance Indicators

This section includes some sample critical success factors (CSFs) for design coordination. Each organization should develop key performance indicators (KPIs) that are appropriate for its level of maturity, its CSFs, and its particular circumstances.

Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the CSI register for evaluation and possible implementation.

The examples of critical success factors and key performance indicators are as follows:

  • Critical success factor: “The accurate and consistent production of service design packages (SDPs).”
    • KPI: A reduction in the number of subsequent revisions of the content of SDPs.
    • KPI: A reduction (measured as a percentage) in the rework required for new or changed service solutions in subsequent lifecycle stages.
  • Critical success factor: “Managing conflicting demands for shared resources.”
    • KPI: Increased satisfaction with the service design activities within project and change management staff.
    • KPI: Improved effectiveness and efficiency in the service design processes, activities, and supporting systems.
  • Critical success factor: “New and changed services meet customer expectations.”
    • KPI: Customer satisfaction score for each new or changed service meets or exceeds a designated rating.
    • KPI: Increase (measured as a percentage) in the number of transitioned services that consistently achieve the agreed service level targets.

Additional examples are available in ITIL Service Design.

Challenges

The major challenge facing design coordination is maintaining high-quality designs and SDPs consistently across all areas of the business, services, and infrastructure. This requires multiskilled designers and architects. It also requires integration of standards and practices developed by design coordination into the organization’s project management methodology wherever appropriate.

It is important to ensure that sufficient time and resources are devoted to design coordination activities and that the roles and responsibilities of the process are assigned appropriately. In most organizations, many of the design coordination activities for an individual design may be assigned to a project manager. Overall lifecycle stage activities may be assigned to the process managers, but key contributions are likely to be made by the service design manager if one exists.

Another significant challenge is developing design practices without introducing unnecessary bureaucracy. It is important that the level of control around design activities be appropriate to the need. Too little control and designs will be inconsistent and fail to meet true required business outcomes. Too much control and creativity may be stifled and inefficiencies introduced. If the processes are too difficult to follow, resistance and noncompliance will result.

Risks

The main risks associated with the provision of the design coordination process are as follows:

  • A potential lack of skills and knowledge
  • Reluctance of the business to be involved
  • Poor direction and strategy
  • Lack of information on business priorities and impacts
  • Poorly defined requirements and desired outcomes
  • Reluctance of project managers to communicate and get involved with design coordination
  • Poor communication across IT, business, projects, and stakeholders
  • Lack of involvement from all relevant stakeholders, including customers, users, and support and other operations staff
  • Insufficient interaction with and input from other lifecycle stages
  • Trying to save time and money during the design stage, which will result in poorer designs requiring more changes after the new or changed service goes live

Service Catalog Management

A service catalog is defined in the ITIL glossary as follows:

A database or structured document with information about all live IT services, including those available for deployment. The service catalog is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business and supporting services required by the service provider to deliver customer-facing services.

Let’s examine this definition in more detail:

A database or structured document The catalog gathers the service information and presents it in a form that is easy for the business to understand.

Information about all live IT services, including those available for deployment The catalog contains details of services that are available to the business; in this way, it differs from the other components of the service portfolio (the service pipeline and retired services). Gathering and maintaining that information is the job of service catalog management.

Information about two types of IT service The catalog provides the details that the customers require about the services available, namely deliverables, prices, contact points, ordering, and request processes. There is another view of the service catalog—the view that is visible only to IT, showing the supporting services that must be in place if the customer services are to be delivered.

Let’s begin by looking at the purpose of the service catalog management process.

Purpose

The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services. It may also include those that are being prepared to be run operationally. The service catalog management process ensures that the service catalog is widely available to those who are authorized to access it.

Objectives

The objectives of the service catalog management process include managing the information contained within the service catalog. This ensures that the service catalog is accurate and reflects the current details, status, interfaces, and dependencies of all services that are being run, or being prepared to run, in the live environment.

Another objective is that this process should ensure that the service catalog is made available to those approved to access it in a manner that supports their effective and efficient use of its information. This may vary depending on the audience; for example, technical support staff need a different perspective on the services than the users.

Finally, it is important to ensure that the service catalog supports the evolving needs of all other service management processes for service catalog information, including all interface and dependency information.

Scope

The scope of the service catalog management process is to provide and maintain accurate information on all services that are being transitioned or have been transitioned to the live environment. It is up to the organization to define the point at which it is comfortable having services displayed as part of the service catalog. The services presented in the service catalog may be listed individually, or more typically, some or all of the services may be presented in the form of service packages.

The service catalog management process covers the following items:

  • Contribution to the definition of services and service packages
  • Development and maintenance of service and service package descriptions appropriate for the service catalog
  • Production and maintenance of an accurate service catalog
  • Interfaces, dependencies, and consistency between the service catalog and the overall service portfolio
  • Interfaces and dependencies between all services and supporting services within the service catalog and the configuration management system (CMS)
  • Interfaces and dependencies between all services, and supporting components and configuration items (CIs) within the service catalog and the CMS

The service catalog management process does not include the following:

  • Detailed attention to capturing, maintaining, and using service asset and configuration data because this is performed through the service asset and configuration management process
  • Detailed attention to capturing, maintaining, and fulfilling service requests because this is performed through the request fulfilment process

Value

The service catalog provides a central source of information on the IT services delivered by the service provider organization. It includes a customer-facing view (or views) of the IT services in use, how they are intended to be used, the business processes they enable, and the levels and quality of service the customer can expect for each service.

Through the work of service catalog management, organizations can do the following:

  • Ensure a common understanding of IT services and improved relationships between the customer and service provider by utilizing the service catalog as a marketing and communication tool
  • Improve service provider focus on customer outcomes by correlating internal service provider activities and service assets to business processes and outcomes
  • Improve efficiency and effectiveness of other service management processes by leveraging the information contained in or connected to the service catalog
  • Improve knowledge, alignment, and focus on the business value of each service throughout the service provider organization and its activities

Policies

Each organization should develop and maintain a policy with regard to both the overall service portfolio and the constituent service catalog, relating to the services recorded within them and what details are recorded (including what statuses are recorded for each of the services).

The policy should also contain details of responsibilities for each section of the overall service portfolio and the scope of each of the constituent sections. This will include policies regarding when a service is published in the service catalog as well as when it will be removed from the service catalog and appear only in the retired services section of the service portfolio.

Principles and Basic Concepts

There are different types of service delivered by a service provider. In Figure 12.2, you can see the types of service described by the framework.

Diagram shows the relationship between business processes, customers, SLAs, and the service catalog which includes customer-facing services and supporting services.

Figure 12.2 Types of service in a service catalog

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

Customer-facing services are IT services that are seen by the customer. They are typically services that support the customer’s business units/business processes, directly facilitating some outcome or outcomes desired by the customer.

Supporting services are the IT services that support or “underpin” the customer-facing services. They are typically invisible to the customer but essential to the delivery of customer-facing IT services.

To be most effective, the service catalog views should be tailored to meet the requirements of the audience. The information required from the customer’s perspective is different than that required by the technical support teams. In Figure 12.3 you can see the perspective of the service catalog in two views, the business or customer view and the technical view.

Diagram shows the service catalog that includes business or customer view and technical or supporting view along with its links to related information in the service assets or configuration records.

Figure 12.3 Two-view service catalog

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

The catalog should form a part of the configuration management system. This should be structured and presented in a manner appropriate to the organization.

In the example in Figure 12.4, the customer-facing catalog has been partitioned such that a business unit has sight of only the services it uses. This might be appropriate for a commercial service provider, where two different customer groups do not need to share visibility across the whole catalog. The two customer groups are generically referred to as either wholesale or retail customers.

Diagram shows the service catalog that includes wholesale customer view and retail customer view along with its links to related information in the service assets or configuration records.

Figure 12.4 Three-view service catalog

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

Process Activities, Methods, and Techniques

We will now consider the process activities from a management perspective. There are a number of activities to consider, not least of which is the agreement and documentation of services.

Key activities include ensuring that the services are defined and described appropriately within the documentation.

The service catalog should interface with the service portfolio, so the processes of service catalog management and service portfolio management should be closely linked. This will enable the content of both to remain accurate and up-to-date. The service catalog is a significant information source for the process of IT service continuity and supports business continuity management, ensuring that appropriate services are maintained according to the continuity needs of the business. It also serves to capture the relationships with suppliers and internal service provider teams (such as service asset and configuration management), supporting the understanding of the overall IT estate. The service catalog supports both service level and business relationship management, ensuring alignment to business requirements and processes.

All of these interactions require attention from the service catalog process manager to ensure the continued effective use of the information captured in the catalog.

Triggers, Inputs, Outputs, and Interfaces

First, we will consider the triggers for this process.

Triggers

The triggers for the service catalog management process include changes in the business requirements and services. Among the main triggers are requests for change (RFCs) and the change management process. This includes new services, changes to existing services, and services being retired.

Inputs

There are a number of sources of information that are relevant to the service catalog management process and form the inputs to the catalog:

  • Business information from the organization’s business and IT strategy, plans and financial plans, and information on its current and future requirements from the service portfolio
  • A business impact analysis (BIA) providing information on the impact, priority, and risk associated with each service or changes to service requirements
  • Business requirements; details of any agreed, new, or changed business requirements from the service portfolio
  • The service portfolio and all related data and documents
  • The configuration management system
  • Requests for change
  • Feedback from all other processes

Outputs

The outputs of the service catalog management process are as follows:

  • The documentation and agreement of a definition of the service
  • Updates to the service portfolio; should contain the current status of all services and requirements for services
  • Updates to requests for change
  • The service catalog; should contain the details and the current status of every live service provided by the service provider or every service being transitioned into the live environment, together with the interfaces and dependencies

Interfaces

Every service provider process uses the service catalog, so it could be said that the service catalog management process interfaces with all processes, but the following list includes some of the most prominent interfaces:

Service Portfolio Management This process determines which services will be chartered and therefore moved forward for eventual inclusion in the service catalog. It also includes critical information regarding each service or potential service, including any agreed service packages and service options.

Business Relationship Management This process ensures that the relationship between the service and the customer(s) who require it is clearly defined in terms of how the service supports the customer(s) needs.

Service Asset and Configuration Management This process works collaboratively with service catalog management to ensure that information in the CMS and information in the service catalog are appropriately linked together to provide a consistent, accurate, and comprehensive view of the interfaces and dependencies between services, customers, business processes, service assets, and configuration items (CIs).

Service Level Management This process negotiates specific levels of service warranty to be delivered, which will be reflected in the service catalog.

Demand Management In conjunction with service portfolio management, this process determines how services will be composed into service packages for provisioning and assists service catalog management in ensuring that these packages are appropriately represented in the service catalog.

Information Management

The key information for this process is that which is contained within the service catalog itself. Because the service catalog is part of the service portfolio, the main input for this information comes from the business via either the business relationship management or service level management process. It is important to verify the information for accuracy before it is recorded within the service catalog. The information and the service catalog itself need to be maintained using the change management process.

There are many different approaches to managing service catalog information:

  • Intranet solutions that are built by the service provider organization and leverage technology already in place
  • Commercially available solutions designed for service catalog management
  • Solutions that are part of a more comprehensive service management suite

The service catalog data may be held in a single repository or multiple repositories. Some service providers may maintain the data that supports different views of the service catalog in different locations or toolsets.

For example, detailed data for supporting services may be stored in the CMS and presented via the same interface used to access other service asset and configuration data, while data on customer-facing services may be held for presentation to the customers in a browser-based application via the corporate intranet.

Constructing different views of the service catalog should be based on the perspective and requirements of the intended audience. The service provider should consider which services (rows of data) and which data elements or fields (columns of data) should be included in each view. For example, details of relationships of supporting services may be important to include in a view intended for staff members of the service provider, whereas these details are typically of no interest to customers and are likely to be excluded from a customer-facing view.

Integration with the management of the service portfolio is critical here, as is the ability to access other closely related functionality. Customers should be able to view their service level agreement monitoring reports or access a self-help portal for service requests. Some commercially available service catalog tools are maturing to offer management of the full-service portfolio from proposal to retirement.

Each organization will have to understand the solution that will best serve its current and future needs. It is important, however, not to confuse the toolset used to present the service catalog with the catalog itself. An organization with a paper-based catalog and an organization with a robust technical solution both still have a service catalog.

Critical Success Factors and Key Performance Indicators

The following list includes some sample critical success factors and key performance indicators for service catalog management.

  • Critical success factor: “An accurate service catalog”
    • KPI: An increase in the number of services recorded and managed within the service catalog as a percentage of those being delivered and transitioned in the live environment
    • KPI: Reduction (measured as a percentage) in the number of variances detected between the information contained within the service catalog and the “real-world” situation
  • Critical success factor:: “Business users’ awareness of the services being provided”
    • KPI: Increase (measured as a percentage) in completeness of the customer-facing views of the service catalog against operational services
    • KPI: Increase (measured as a percentage) in business user survey responses showing knowledge of services listed in the service catalog
    • KPI: Increase in measured business user access to intranet-based service catalog
  • Critical success factor:: “IT staff awareness of the technology supporting the services”
    • KPI: Increase (measured as a percentage) in completeness of supporting services against the IT components that make up those services
    • KPI: Increase in service desk and other IT staff having access to information to support all live services, measured by the percentage of incidents with the appropriate service related information

Challenges

The major challenge facing the process of service catalog management is maintaining an accurate service catalog. This should be managed as part of a service portfolio, incorporating all catalog views as part of an overall CMS and SKMS.

For this to be achieved, the culture of the organization needs to accept that the catalog and portfolio are essential sources of information. It is then important to ensure that everyone within the IT organization understands that all are responsible for supporting the use and helping maintain its accuracy.

Risks

The risks associated with the provision of an accurate service catalog are as follows:

  • Inaccuracy of the data in the catalog and it not being under rigorous change control.
  • Poor acceptance of the service catalog and its usage in all operational processes. The more active the catalog is, the more likely it is to be accurate in its content.
  • Inaccuracy of service information received from the business, IT, and the service portfolio.
  • Insufficient tools and resources required to maintain the information.
  • Poor access to accurate change management information and processes.
  • Poor access to and support of an appropriate and up-to-date CMS and SKMS for integration with the service catalog.
  • Circumvention of the use of the service portfolio and service catalog.
  • Information that is either too detailed to maintain accurately or at too high a level to be of any value. It should be consistent with the level of detail within the CMS and the SKMS.

Summary

This chapter explored the first two processes in the service design stage, design coordination and service catalog management. It covered the purpose and objectives for each process and the scope. The scope includes all aspects of the design lifecycle stage, which require coordination.

We looked at the value of the processes, particularly for integration with complex projects. Then we reviewed the policies for each process and the activities, methods, and techniques.

Last, we reviewed triggers, inputs, outputs, and interfaces for each process, and the information management associated with the process. We also considered the critical success factors and key performance indicators, challenges, and risks.

We examined how each of these processes supports the other and the importance of these processes to the business and the IT service provider.

Exam Essentials

Understand the purpose and objectives of design coordination. It is important for you to be able to explain the purpose and objectives of the design coordination process. The process is there to ensure that the five aspects of design are carried out successfully and that a service design package is created and published.

Understand how continual service improvement should be used to support design coordination activities. This focus on CSI is important to make sure design coordination remains relevant.

Explain the different approaches of design coordination. Explain the coordination of the overall design effort within the process. Explain the approach to the coordination of the individual processes within the service design lifecycle stage.

Understand the critical success factors and key performance indicators for the process. Measurement of the process is an important part of understanding its success, so it is important to understand the reasoning for the KPIs and CSFs for this process.

Understand the purpose and objectives of service catalog management. Be able to explain how the service catalog supports the overall lifecycle and the requirement to maintain the data accuracy.

Understand the exclusions from the service catalog. Service asset and configuration management is concerned with the management of CIs. Fulfilment of service requests are not managed through the service catalog.

Explain the different views of the service catalog. There are a number of views that can be used to display information in the service catalog. You need to be able to differentiate between technical and business views and explain the purpose for each. It is also important to understand when to provide multiple views of the service catalog to the organization.

Understand the relationship between the service catalog and the service portfolio. Be able to explain the relationship between the service portfolio and the service catalog, and be able to understand when a service moves from the service portfolio pipeline into the service catalog.

Explain the role of information management in service catalog management. Information is key to the service catalog management process. The output from the process is accurate information and its maintenance.

Review Questions

You can find the answers to the review questions in the appendix.

  1. What is the purpose of the design coordination process?

    1. Manage the service level management process
    2. Manage the service transition lifecycle stage
    3. Ensure the production of the service design package
    4. Ensure that the strategy is managed throughout the lifecycle
  2. Which description (X, Y, or Z) best matches each catalog type (1, 2, and 3)?

    1. Business/customer catalog
    2. Technical catalog
    3. Multiview catalog
    4. View of all services that are used
    5. View of the supporting services used to deliver the customer-facing services
    6. View of the customer-facing services that are directly delivered to the customer
      1. X=3, Y=2, Z=1
      2. X=1, Y=2, Z=3
      3. X=2, Y=1, Z=3
      4. X=2, Y=3, Z=1
  3. Which of the following is the correct definition of the service catalog?

    1. A document that describes the IT service, service level targets, and responsibilities of the IT service provider and the customer
    2. The complete set of services managed by a service provider, used to manage the entire lifecycle of all services
    3. A database or document with information about all live IT services
    4. Justification for a particular item of expenditure, including information about costs, benefits, options, and risks
  4. Which of the following are included in a service catalog?

    1. Customer-facing services
    2. Strategic services
    3. Supporting services
    4. Retired services
      1. 1 and 2
      2. 1, 2, 3, and 4
      3. 1 and 3
      4. 2 and 3
  5. Which of the following statements is true?

    1. The service catalog forms part of the service portfolio.
    2. The service portfolio forms part of the service catalog.
    3. There is no relationship between the service catalog and the service portfolio.
    4. Customer-facing services appear in the service catalog, and supporting services appear in the service portfolio.
      1. 1 and 3
      2. 1 only
      3. 2 and 4
      4. 4 only
  6. Which of the following options is NOT a responsibility of design coordination?

    1. To ensure that the goals and objectives of the design stage are met
    2. To design the solution
    3. To provide a single coordination point
    4. To ensure that the design meets the requirements
  7. Which of the following are outputs from design coordination?

    1. The service design package
    2. The CMS
    3. The governance requirements
    4. Suggestions for improvements to be made to the design stage
      1. 2, 3, and 4
      2. 1 and 2 only
      3. All of the above
      4. 1 and 4 only
  8. Which of the following statements about the service catalog is TRUE?

    1. The service catalog contains information on customer-facing services only.
    2. The service catalog contains information on supporting services only.
    3. The service catalog shows which IT service supports each business process.
    4. The service catalog shows details of services under development.
  9. True or False? Service catalog management can be connected to the majority of the lifecycle processes.

    1. True
    2. False
  10. True or False? Design coordination is responsible for the management of the service operation processes that have design responsibilities.

    1. True
    2. False
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset