This section covers the importance of 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.
Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.
All processes need to have the appropriate resources and capabilities in order to be successful.
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.
Figure 2.4 shows some examples.
Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.
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.
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.
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.
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.
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.
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.
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:
Figure 2.5 gives some examples.
Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.
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.