Understanding Key Concepts of Service Strategy

This section covers the importance of value creation.

Utility and Warranty in Value Creation

As we discussed earlier, when considering the value of services, you should be concerned with delivering business outcomes and achieving business objectives. You can create this value by looking at two primary elements of a service: utility (fit for purpose) and warranty (fit for use). These work together to deliver the desired outcomes that allow customers to assess value.

Utility is what the service does, and warranty is how it is delivered, as you can see in Figure 2.3.

FIGURE 2.3 Services are designed, built, and delivered with both utility and warranty

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

image
Utility Utility is the functionality offered by a product or a service to meet a specific customer need. Often summarized as “what the service does,” this is where you understand if the service is able to meet the required outcomes. This is also commonly known as “fit for purpose.” This aspect of service value refers to tasks associated to achieving outcomes.
Warranty Warranty provides the assurance that a product or service will meet the agreed requirements. This may be captured as part of a formal agreement, such as a service level agreement or contract. It refers to the ability of the service to be available when needed, have sufficient capacity to meet the requirements, and be reliable in terms of both security and continuity. This is often summarized as “how the service is delivered” and commonly referred to as “fit for use.”

Value in Practice
Looking at any service-based industry can show an example of utility and warranty in a non-IT situation. For example, in a restaurant, no matter what the quality of the service required (fine dining or fast-food), there are basic requirements in terms of premises, furniture, kitchen, funding, food, staff, and so on. These are the utility aspects of providing the service.
The warranty aspects depend on the type of service being provided. For a fast-food experience, you would expect the restaurant to be available 24 hours in the day, whereas a fine-dining restaurant may have exclusive opening times. Fast-food is all about high turnover and high capacity, but once a fine-dining restaurant is fully booked, they are OK with ensuring their customers are not rushed, because it adds to the exclusivity and appeal. Security and continuity are managed appropriately to the dining experience. Fast-food restaurants often have special counters that allow them to keep finances away from the high volumes of customers, whereas a fine-dining experience has an exclusivity approach with staff on hand to ensure security. Continuity of service for both types of establishment has to be managed according to the requirements of their customers. Fast-food is dependent on high turnover, fine dining specializes in high quality, but both provide a valuable service.
The different types of service (fast-food or fine dining) have very different costs associated to them, but the customer has the ability to choose the most appropriate for their budget and their needs.

Assets, Resources, and Capabilities

All processes need to have the appropriate resources and capabilities in order to be successful.

Assets Resources and capabilities are classed as assets of an organization. All interactions between the service provider and customer are based on the use of assets, both those of the service provider and the customer. Because many customers use the services provided to deliver services or products to their own customers, customer assets from the service provider perspective may be considered to be service assets by the customer.

However the assets are perceived, the performances of all assets are part of defining the value of a service.

ITIL provides us with these definitions for assets:

Asset: Any resource or capability.

Customer asset: Any resource or capability used by a customer to achieve a business outcome.

Service asset: Any resource or capability used by a service provider to deliver services to a customer.

There are two types of asset used by both service providers and customers: resources and capabilities. They are used to create value in the form of goods and services.

Resources Resources are the direct inputs for the production of services. These cover everything from money, infrastructure items, applications, people, and anything that could be used to assist in the delivery of a service. They are often considered to be assets of an organization, and many will be classified under capital expenditure as a physical asset.
Capabilities Capabilities are the assets that represent the organization’s ability to do something to achieve value, such as the ability to coordinate, control, and deploy resources in the form of a service. Typically these are knowledge or information based and include experience, which is embedded in the organization.

Figure 2.4 shows some examples.

FIGURE 2.4 Examples of capabilities and resources

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

image

Capabilities cannot produce value by themselves; they need appropriate and sufficient resources. Equally, sufficient resources cannot provide value without the appropriate capability to make use of them to deliver value. It is the combination of resources and capabilities that enables a process to take place in order to deliver successful service management.

Governance and Its Place in the Lifecycle

ITIL defines governance as:

Ensures that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includes defining roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.

Governance is an area where IT and the business meet, and the two should operate together according to a common direction, policies, and rules for both parties to achieve the organizational goals.

It is often the case that service management initiatives are unsuccessful when they ignore the corporate governance approach and attempt to impose their own structures. Service management must include the standards and policies of corporate governance, which may require adaptation of best-practice approaches for the individual circumstance.

It is important to have a consistent approach for management at all levels of the organization. This begins with setting a clear strategy and defining the policies that drive the way it will be achieved. Policies also provide structure and boundaries, which will control the way that the organization carries out its operational approach. Governance also provides the controls for the strategy itself, in terms of evaluation, monitoring, and direction for the strategic goal of the organization.

There is an international standard for corporate governance of IT, designated ISO/IEC 38500. Information on this standard is available from the International Standards Organization (www.iso.org).

The role of governance is often the driver for improvement activity, so as well as being important in the role for strategic policy setting, it also plays a significant role in continual service improvement (CSI). CSI will have an effect on service strategy, as it will on the whole of the lifecycle, and as a result, governance provides structure across the whole of the service lifecycle.

Management of Risk in Service Management

In terms of risk management, the Service Strategy publication does not provide a comprehensive organization-wide approach but considers the basic risk management that is required by a project implementing an IT service management approach.

However, it is important to understand that any risk management approach that is adopted for IT should be complementary to the approach in place for the organization as a whole. The corporate approach to risk identification, assessment, management, and mitigation must be enhanced by the IT service provider, not be in conflict with it.

Identifying Risks

This is where the risk is identified and named, which does not mean you have to immediately explain or quantify the risk, but it should be possible to capture what may impact the project or strategy that is under consideration.

Each identified or suspected risk should be documented, and the potential consequences of the risk captured should be part of the record. A commonly used mechanism for capture is a risk register. This is a centralized record of the risks that need to be managed. It will be managed through the continual service improvement lifecycle stage.

Analysis of Risks

After the initial identification and capture of potential consequence, it is possible to begin analyzing the risk. This is where we consider what the impact will be if the risk becomes a reality and the consequence takes place.

The majority of risk management methods use both a numeric and quality calibration and description for the risks. It allows you to define the consequences in words, as well as an associated numeric value, so that a clear understanding can be achieved. The quantitative value is used to calculate a ranking for the risk, while the qualitative statements and descriptions are used for the definition of how to deal with or manage the risk.

Risk management has its basis in probability approaches and theories and can be an extremely mathematical discipline. Risk is the likelihood or potential for something to happen. It is important to ensure that common sense is also applied. A risk that has been identified with 100 percent probability is not a risk; it is a certainty. This should be classified as an issue and be recorded and managed accordingly. Similarly, a risk with a 0 percent probability can be removed from the risk register.

Managing Risks

As part of the documentation for risk management, each risk should be associated with an individual action plan, which incorporates the initial documentation with any outcomes from the analysis. These individual plans should be collated to form an overall risk management plan. This should be reviewed regularly to ensure that the individual risks are being managed appropriately and any actions that have been taken are delivering the expected results.

Throughout a project, there may be variations in the level of risk associated with an activity, and the management of individual risk may be such that it is completely mitigated and now has a 0 percent probability of happening. Alternatively, a risk considered to be low or unlikely at the start of a program may become high or more likely as circumstances change. It is important to continue to review the risk management plan and also to identify any new risks that may arise.

This should be part of the best-practice approach for any project management method and should also be part of the normal risk management approach adopted for operational management.

Risk management is a repetitive activity, and this should become part of the accepted culture of any program or initiative.

Understanding Patterns of Business Activity

Because services are there to enable a business activity and the business activity then generates the business outcome, it is necessary to understand any patterns in the business activity so that you can deliver services that meet the required outcomes. From your own experience in your organization, you will recognize that activities tend to form patterns if they are repeated frequently enough. These interactions form something recognizable and therefore potentially predictable. The more you can predict the likely patterns of business activity, the better you can be prepared to ensure the levels of capacity and availability meet the requirements of the customer outcome. In this way, you will increase the levels of satisfaction with your services and be seen to deliver value.

Business activity covers the use of customer assets such as people, processes, and applications, as well as the interactions between customers, suppliers, partners, and other stakeholders. Capturing and analyzing patterns of business activity are key factors in determining strategies that allow you to deliver services to meet customer demands.

Once a pattern of business activity (PBA) has been identified, you should attempt to understand the profile of the PBA and document it. It is recommended that the following items should be captured:

Classification This identifies the type of PBA and may reference its origins (user or automated), the type and impact of the outcomes that are supported, and the workload associated.
Attributes This includes frequency, volume, location, and duration.
Requirements This includes performance, security, availability, privacy, and tolerance for delays. Some of these could be classified as the warranty considerations.
Service Asset Requirements This is used by design teams to capture and understand what is required to support a specific PBA, in terms of resource and capability. This level of detail is important in the understanding of meeting the requirements for demand, as long as the actual requirements remain within a given forecast.

Figure 2.5 gives some examples.

FIGURE 2.5 Examples of patterns of business activity

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

image

Figure 2.5 shows an example of three PBAs from three separate organizational models. In the first, you can see an annual approach to pattern recognition. The greetings card company shown in example A will have customers buying according to major holidays or events. The IT service provider must recognize the impact of this activity on IT system usage and provide sufficient capability to enable the business to meet its peaks. Decisions must be made about carrying spare capacity at nonpeak times or how the workload will be balanced at peak times, for a cost-effective provision of service.

In the second example, you can see a weekly pattern of activity, for the use of time-sheet recording. This is obviously an important system, because it directly relates to the billing of external customers for services, so ensuring this can be managed and provided cost-effectively is important. It may be possible in this instance to work with the business to encourage different behaviors from its staff to enable a smoother PBA for the system, perhaps encouraging a daily entry of time allocated. In this way, you can meet the business outcome, but with the cooperation of the business in keeping the need for spare capacity manageable.

In the third example, you have a daily pattern to review. The workload of the business will not alter, because it is concerned with a print deadline. This is a pattern that will require the resources required to be available to match the requirement.

..................Content has been hidden....................

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