ITIL Intermediate SOA – Demand Management Tutorial

What is ITIL demand management?

ITIL demand management helps a business understand and predict customer demand for services. Every business is subject to cyclical behavior. According to ITIL, the purpose of demand management is to understand, anticipate, and influence customer demand for services.

This means that demand for services can grow or shrink with the business cycle. In deciding whether to provide a service, IT Service Management must understand the patterns of business activity (PBAs) related to the service. While it is important to avoid having inadequate capacity, excess capacity is also a business risk, involving expense which typically cannot be recovered, since customers cannot be expected to pay for capacity they are not using.

PBAs are typically thought of in terms of transaction volumes. ITIL suggests other factors be considered as well, such as the source of the demand, special needs such as enhanced security, and tolerance for delay. The job of demand management is to identify appropriate PBAs and to associate them with user profiles (UPs). This becomes important input to the capacity management process in the Service Design lifecycle phase.

As a process, it is part of the ITIL service strategy stage of the ITIL lifecycle. Service strategy determines which services to offer to prospective customers or markets. The decisions that are made in the service strategy stage affect the service catalog, the business processes, the service desk, the required capacity, and the financial requirements of the service provider.

As part of the service strategy stage, demand management rationalizes and optimizes the use of IT resources. It ensures that the amount of technical and human resources that has been budgeted matches the expected demand for the service. If the prediction is too low, the agreed-upon service levels may not be delivered. If the predictions are too high, resources will have been allocated to a service that will not be used (or paid for). Demand management bridges the gap between service design, capacity management, and business relationship management to ensure that the predictions are accurate.

Demand management is a process within ITIL that is more supportive of other processes than a self-contained process. Unlike incident management, for example, the activities inside demand management are not visible to the customer. When service demand is not properly balanced, it affects nearly every part of the ITIL lifecycle.

Demand management roles

Like every process within the ITIL framework, demand management has a chain of responsibility and ownership. Here, the owners are called business relationship managers. Business relationship management creates and grows the connection between the customer and the service provider.

Demand management objectives and activities

The purpose of demand management is to detect and influence the demand that customers have on IT services. This process involves three main actions:

• Analyzing current customer usage of IT services: The easiest way to do this is to analyze service desk data regarding incidents, requests, and problems. Network usage and uptime can be measured via a service dashboard, such as the kind used in a network operations center (NOC) environment.
• Anticipating future customer demands for IT services: Here, the business relationship manager comes into play. He or she may speak with the customer directly about forecasted needs, will analyze trends in usage or tickets, and will make educated projections about future usage based on similar customers trends.
• Influencing consumption as necessary by financial or technical means: For example, if a customer uses more service than anticipated in the SLA, a service provider may charge fees for the excessive consumption to offset the costs of the unforeseen demand. Demand management also makes sure that the appropriate costs are included in the service design. Formally, this involves two processes:

Demand prognosis

In demand prognosis, the business relationship manager analyzes IT service consumption. This individual will also forecast future consumption based on known information, such as consumption trends and service-quality feedback from the customer. Sometimes, the customer will directly indicate when more capacity or a great number of services are needed. In ITIL, this is called the Pattern of Business Activity (PBA). According to ITIL, the PBA is a workload profile of one or more business activities that helps service providers establish usage patterns.

The pattern of business activity measures the following aspects of customer service usage:

• Frequency
• Volume
• Duration
• Location

The duration of usage is how long the pattern of business usage lasts. Does peak database usage occur only during business hours, for example, or only during certain months? How long ago did the increase or decrease in usage begin?

The volume of usage is the amount of activity. For example, this could be the number of transactions processed or a service desk ticket number. Volume can increase or decrease.

The frequency of usage is how often the volume of usage occurs.

The location of usage is where the business usage occurred. Is it in the service desk or the sales department, for example?

The PBA also includes a user profile, which is a pattern of service usage that is tied to a type of user. For example, developers may have a higher database usage pattern than business users.

Demand control

Demand control is the way that providers control IT service consumption. This can be done through technical means (such as network throttling) or financial means (such as increased charges for usage higher than the agreed-upon levels). The control is implemented until the capacity for greater demand is implemented into the service catalog.

Developing differentiated offerings and service packages also controls demand. Differentiated offerings and service packages control demand and cost while providing the customer with the services they use and value most.

The ITIL demand management communication flow

Unlike other processes within the ITIL lifecycle, demand management relies on communication between different processes rather than on a self-contained set of procedures. Unlike some other processes, demand management interfaces with the other service strategy lifecycle processes. On one side, demand management receives customer feedback from the business relationship manager and the PBA. On the other side, demand management informs many other processes based on the information obtained and the conclusions drawn.

Demand management is seen in service strategy when the pattern of business activity is used alongside service portfolio management to invest in new services and increased capacity.

It is seen in service transition when the data collected is used to validate that the new service catalog meets the projected needs of the pattern of business activity.

It is used in service operation as the end point for feedback from the service desk. The service desk detects trends in service usage and sends that information to demand management, which alerts capacity management to increase or decrease resources as needed.

Finally, demand management is seen in continual service improvement (CSI) when the data from demand management and the PBA is used to proactively improve services based on usage forecasts.

Why is ITIL demand management so important?

Demand management is essential for one simple reason: It is impossible to adequately plan for and meet service demands based on gut check alone. Predicting how much service will increase based on what you think you remember about current demand versus the demand of other similar customers results in inaccurate data at best and expensive overstaffing at worst. Accurate planning requires analyzing the data gathered and client feedback, as seen in the demand prognosis process. Inaccurate estimates have negative impacts on:

• SLA metrics
• KPIs
• Customer satisfaction
• Financial management
• Incident management
• Business relationship management
• Service strategy

Poorly managed service demand is a huge risk for organizations. Inadequately planning for increases in service usage could mean missed service levels and poor service quality across the entire service catalog. For businesses, that could mean anything from financial implications to lost business altogether.

Related ITIL stages and processes

Demand management interfaces with many ITIL processes. As a part of the service strategy stage, it is closely aligned with service portfolio management, financial management for IT services and business relationship management. This is because the question of “how much” service is enough is integral to those processes. In financial management, for example, the question of how much of a service to provide directly impacts the IT budget and the costs passed on to the service customer. In service portfolio management, demand directly impacts which services are offered in the customer service catalog. service operations are thus also impacted, since it relies on the service catalog for its range of services, as well as on the associated capacity and asset management of operations.

Demand management is a small but important component within ITIL. Getting demand management wrong impacts the entire organization and the services rendered. Read on to learn about the other processes within service strategy.

Service Strategy

The Service strategy provides guidance on how to design, develop, and implement service management not only as an organizational capability but also as a strategic asset. Guidance is provided on the principles underpinning the practice of service management that is useful for developing service management policies, guidelines, and processes across the ITIL Service Lifecycle.

Service Strategy guidance is useful in the context of Service Design, Service Transition, Service Operation, and Continual Service Improvement.

Topics covered in Service Strategy include:

• Service portfolio management
  The development of markets
  Internal and external service assets
  Service Catalogue
  Implementation of strategy through the Service Lifecycle
  Financial Management
  Organizational Development
  Strategic Risk

Purpose and Objectives of Strategy Management for IT Service

Strategy management for IT services is the process of defining and maintaining an organization’s perspective, position, plans and patterns about its services and the management of those services.

• The purpose of a service strategy is to:
  1. Articulate how a service provider will enable an organization to achieve its business outcomes
  2. Establish the criteria and mechanisms to decide which services will be best suited to meet the business outcomes and the most effective and efficient way to manage these services.
  
  3. Ensure that the strategy is defined, maintained and achieves its purpose.
  

The objectives of strategy management for IT services are to:

•   Analyse the internal and external environments in which the service provider exists, to identify opportunities that will benefit the organization.
• Identify constraints that might prevent the achievement of business outcomes, the delivery of services or the management of services; and define how those constraints could be removed or their effects reduced.
• Agree the service provider’s perspective and regularly review to ensure continued relevance. This will result in a clear statement of the vision and mission of the service provider.
• Establish the position of the service provider relative to its customers and other service providers. This includes defining which services will be delivered to which market spaces, and how to maintain a competitive advantage.
• Produce and maintain strategy planning documents and ensure that all relevant stakeholders have updated copies of the appropriate documents. This will include the IT strategy, the service management strategy and the strategic plans for each service where appropriate.
• Ensure that strategic plans have been translated into tactical and operational plans for each organizational unit that is expected to deliver on the strategy.
• Manage changes to the strategies and related documents, ensuring that strategies keep pace with changes to the internal and external environments

Let us look into the scope of Strategy Management in the next section.

Scope of Strategy Management for IT Services

Strategy management is the responsibility of the executives of an organization. It enables them to set the objectives of the organization, to specify how the organization will meet those objectives and to prioritize investments required to meet them. However, in medium to large organizations, it is unlikely that the executives themselves will conduct the assessments, draft the strategy documents and manage the execution.

This is normally performed by a dedicated strategy and planning manager reporting directly into the board of directors. An organization’s strategy is not limited to a single document or department. The overall strategy of an organization will be broken down into a strategy for each unit of the business. There are likely to be several strategies within each organization.

Strategy management for the enterprise has to ensure that these are all linked and consistent with one another. Strategy management for IT services has to ensure that the services and the way they are managed support the overall strategy of the enterprise.

Strategy management is described above as a generic process that could be applied to the business as a whole, or to any of the business units. However, this publication is specifically concerned with how this process is applied to IT as a service provider.

Please note that in an external service provider, the business strategy might be related to IT services delivered to an external customer, and the IT strategy would be related to how those services will be delivered and supported.

At the same time, external service providers do not just provide IT services to customers. They are also consumers of their own (and potentially other third-party) IT services. External service providers also have internal IT service requirements that must be met to enable them to survive.

Now, we will understand the value of Strategy Management.

Value of Strategy Management for IT Services

The strategy of an organization articulates its objectives, and defines how it will meet those objectives and how it will know it has met those objectives. Without a strategy, the organization will only be able to react to demands placed by various stakeholders, with little ability to assess each demand and how it will impact the organization.

In these cases, the actions of the organizations tend to be led by whoever is making the loudest demands, rather than by what is best for the organization. Strategy becomes a function of organizational politics and self-interest, rather than the overall achievement of its objectives. A well-defined and managed strategy ensures that the resources and capabilities of the organization are aligned to achieving its business outcomes, and that investments match the organization’s intended development and growth.

Strategy management ensures that all stakeholders are represented in deciding the appropriate direction for the organization and that they all agree on its objectives and the means whereby resources, capabilities, and investment are prioritized.

Strategy management also ensures that the resources, capabilities, and investments are appropriately managed to achieve the strategy. For a service provider, strategy management for IT services ensures that it has the appropriate set of services in its service portfolio, that all of its services have a clear purpose, and that everyone in the service provider organization knows their role in achieving that purpose.

Strategy management for IT services further encourages appropriate levels of investment, which will result in one or more of the following:

• Cost savings, since investments and expenditure are matched to the achievement of validated business objectives, rather than unsubstantiated demands Increased levels of investment for key projects or service improvements
• Shifting investment priorities. The service provider will be able to de-focus attention from one service, and re-focus on another, ensuring that its efforts and budget are spent on the areas with the highest level of business impact.
  

For the customer of the service provider, strategy management for IT services enables them to articulate clearly their business priorities in a way that is understandable to the service provider. The service provider is then able to make a decision about how to respond to the customer.

In some cases, the customer demand represents a departure from the service provider’s strategy. The service provider will use strategy management for IT services to make a decision about whether to change its strategy, or whether to turn down the business.

Where the service provider is an internal IT organization, the second option is not always possible, and in these cases, it will use strategy management for IT services to work with the business units to make them aware of the impact of their demand on the current strategy. The business executives will be able to work with IT either to change the existing strategy or to decline the opportunity.

In other cases, customer demands do not change the service provider’s strategy but will require it to change its priorities. Strategy management for IT services enables the service provider to determine the best way to change its priorities and balance its resources, capabilities, and investments.

Let us start with Service Design and Design Coordination Process in the next section.

Service Design and Design Coordination Process

Now let us get an insight into the Design Coordination process.

In the next section, we will discuss what Service Design provides us and what are the scopes of Service Design.

Service Design

The Service Design volume guides the design and development of services and service management processes. It covers design principles and methods for converting strategic objectives into portfolios of services and service assets.

The scope of Service Design is not limited to new services. It includes the changes and improvements necessary to increase or maintain value to customers over the lifecycle of services, the continuity of services, achievement of service levels, and conformance to standards and regulations.

It guides organizations on how to develop design capabilities for service management. The service offerings and Agreements related processes from Service Design are Service catalogue management, Service Level management and Supplier management

Let us now learn about the purpose and objectives of the Design Coordination process.

Purpose and Objectives of Design Coordination

The service design stage of the lifecycle is responsible for the design of new or changed services for introduction into the live environment. It is essential to ensure that the design activities are driven principally by the business needs and requirements of the organization.

Service design considers all aspects and adopts a holistic approach to designing the services. The activities involved are elaborate and complex. To ensure the development of comprehensive and appropriate designs the various activities involved need to be managed and coordinated well. This is where the Design Coordination process plays an important role.

The purpose of Design Coordination is:

• to ensure that the goals and objectives of the service design stage are met by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle.
  

The objectives of this process is to:

• Ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information, and metrics to meet current and evolving business outcomes and requirements
• Coordinate all design activities across projects, changes, suppliers and support teams, and manage schedules, resources and conflicts where required
• Plan and coordinate the resources and capabilities required to design new or changed services
• Produce service design packages based on service charters and change requests
• Ensure that appropriate service designs and service design packages are produced and that they are handed over to service transition as agreed
• Manage the quality criteria, requirements and handover points between the service design stage and service strategy and service transition
• Ensure that all service models and service solution designs conform to strategic, architectural, governance and other corporate requirements
• Improve the effectiveness and efficiency of service design activities and processes
• Ensure that all parties adopt a common framework of standard, reusable design practices in the form of activities, processes and supporting systems, whenever appropriate
• Monitor and improve the performance of the service design lifecycle stage.
• In the next section, we will understand the scope of Design Coordination.

Design Coordination Scope

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.

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.

Not every design activity requires the same level of rigor to ensure success, so a significant number of design efforts will require little or no individual attention from the design coordination process. Most design coordination process activity focuses on those design efforts that are part of a project, as well as those that are associated with changes of defined types.

Typically, the changes that require the most attention from design coordination are major changes, but any change that an organization believes could benefit from design coordination may be included. Each organization should define the criteria that will be used to determine the level of rigor or attention to be applied in design coordination for each design.

Some organizations take the perspective that all changes, regardless of how small in scope, have a ‘design’ stage, as it is important that all changes have clear and correct plans for how to implement them.

In this perspective, the lifecycle stage of service design still occurs, even if the designs for simple or standard changes are usually pre-built and are reused frequently and quickly.

Sometimes the stage is quite complex and long and sometimes it is simply a rapid check that the right ‘design’ (procedure) is being used. Other organizations take the perspective that only changes that fit certain criteria, such as those associated with a project or major change, have a formal service design stage. In this perspective, changes that fail to meet the agreed criteria may be considered out of the scope of this process.

Whichever perspective is adopted by an organization, the end result should be more successful changes that deliver the required business outcomes with minimal disruption or other negative impacts on business operations. If an organization’s approach produces that result, then the organization is performing design coordination correctly.

The design coordination process includes:

• Assisting and supporting each project or other change through all the service design activities and processes
• Maintaining policies, guidelines, standards, budgets, models, resources and capabilities for service design activities and processes
  
• Coordinating, prioritizing and scheduling of all service design resources to satisfy conflicting demands from all projects and changes
• Planning and forecasting the resources needed for the future demand for service design activities
  
• Reviewing, measuring and improving the performance of all service design activities and processes
  
• Ensuring that all requirements are appropriately addressed in service designs, particularly utility and warranty requirements
  
• Ensuring the production of service designs and/ or SDPs and their handover to service transition.
  

The design coordination process does not include:

• Responsibility for any activities or processes outside of the design stage of the service lifecycle
  
• Responsibility for designing the detailed service solutions themselves or the production of the individual parts of the SDPs.
  

These are the responsibilities of the individual projects or service management processes. We will look into the value of the design coordination process in the next section.

Design Coordination Value

Service Management processes must be designed, implemented and managed in a way that they deliver the desired benefits to Business. The Design Coordination process also focuses in the same direction and delivers some benefits. The key value of this process is the production of consistently good quality solution designs and service design packages that will provide the desired business outcomes.

The other benefits are:

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

Value of Service

Services are a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Outcomes are possible from the performance of tasks and are limited by the presence of certain constraints.

Services facilitate outcomes by enhancing the performance and by reducing the grip of constraints. The result is an increase in the possibility of desired outcomes. While some services enhance the performance of tasks, others have a more direct impact. They perform the task itself.

Value

Value is often measured by how much the customer is willing to pay for the service, rather than the cost of the service or any other intrinsic attribute of the service itself. This indicates that the value of a service is determined by the person who receives or uses the service rather than the provider of the service.

Let us now look at the characteristics of value:

• Value is defined by customers – It is the customers who will decide what they will do with the service, what return and objectives they will achieve by utilizing the service. Thus the ultimate decision as to whether a service is valuable or not rests with the customers.
  
• Value is an affordable mix of features – Customers normally select the service that has the best mix of features, meeting their requirements, at the price they are willing to pay.
  
• Achievement of objectives – While some commercial organizations focus on achieving financial objectives, non-commercial or government organizations focus on other objectives. From this perspective, the value of service is determined by measuring how far the service supports achievement of stated objectives.
  
• Value changes over time and circumstances – With changing business needs, objectives, and environmental factors, a service that is valuable today may not be valuable at a later point in time.
  

Creating Value

The value of a service can be considered to be the level to which that service meets a customer’s expectations. It is often measured by how much the customer is willing to pay for the service, rather than the cost of the service or any other intrinsic attribute of the service itself. Unlike products, services do not have much intrinsic value. The value of a service comes from what it enables someone to do.

Following this reasoning, the characteristics of value are:

• Value is defined by customers: No matter how much the service provider advertises the worth of their services, the ultimate decision about whether that service is valuable or not rests with the customer.
  
• An affordable mix of features: it is possible to influence the customer’s perception of value through communication and negotiation, but that still does not change the fact that the customer will still make the final choice about what is valuable to them.

A good salesperson can convince a customer to change the priorities influencing their purchase, but the customer will select the service or product that represents the best mix of features at the price they are willing to pay.

• Achievement of objectives: Customers do not always measure value in financial terms, even though they may indicate how much they are prepared to pay for a service that helps them to realize the desired outcome.
  

For example, the police might focus on reduction in crime or the apprehension of criminals; social welfare departments might focus on the amount of funding disbursed to needy families; a mountain rescue organization might focus on the number of people warned about, or rescued from, avalanches.

• Value changes over time and circumstances: What is valuable to a customer today might not be valuable in two years. For example, retail outlets might focus on selling a higher percentage of luxury goods when the economy is good, but during a recession, they shift the focus to budget product lines and fewer luxury goods.
  

What service(s) did IT provide? If IT is only perceived as managing a set of servers, networks and PCs, it will be very difficult for the customer to understand how these contributed to the value.

The value is achieved regarding 3 areas:

• The business outcomes achieved
  
• The Customer’s Preference
  
• The Customer’s perception of what was delivered
  

Now let’s understand value from the customer’s perception in the next section.

Perception of Value

Perceptions of value are influenced by expectations. Customers have reference values on which they base their perceptions of added value from a service. The reference value may be vaguely defined or based on hard facts. An example of the reference value is the baseline that customers maintain on the cost of in-house functions or services.

What matters is that it is important for the service provider to understand and get a sense of what this reference value is. This may be obtained through extensive dialogue with the customer, prior experience with the same or a similar customer, or through research and analysis available in the market.

The economic value of the service is the sum of this reference value and the net difference in value the customer associates with the offered service. Positive difference comes from the utility and warranty of the service. Negative difference comes from losses suffered by the customer from utilizing the service due to poor quality or hidden costs.

Utility and Warranty

From a customer’s perspective, the value of a service is directly related to the extent to which it supports achieving business objectives. However, two primary elements represent the value of a service. Let us now discuss these two elements.

Utility

A utility is a functionality offered by a service to meet a particular need. In other words, it states ‘what the service does’ and represents whether it is ‘fit for purpose.’

Warranty

Warranty represents the performance aspects of service and refers to the ability of a service to be available when needed, to provide the required capacity, and to provide the required reliability regarding continuity and security. In other words, it indicates whether the service is ‘fit for use.’

It should be noted that these elements are not mutually exclusive. A service can create value, only when it is fit for purpose as well as fit for use. It is therefore important that both utility and warranty should be designed and delivered together. Failure to do so often results in a limited ability to deliver the utility, and attempts to design warranty after a service has been deployed can be expensive and disruptive.

Service providers differentiate themselves from equipment vendors purely through added value even while using the equipment from those same vendors as assets. Differentiation can arise from the provision of communication services instead of routers and switchboards. Further differentiation may be gained from the provision of collaboration services instead of simply operating email and voicemail services.

The focus shifts from attributes to the fulfillment of outcomes. With a marketing mindset, it is possible to understand the components of value from the customer’s perspective. As described earlier, value consists of two components: utility or fitness for purpose and warranty or fitness for use.

Identifying and Understanding Customer Requirements

The accurate identification, documentation, and agreement of customer and business requirements are fundamental to the production of good service solution designs. ITIL Service Design enforces the principle that the initial service design should be driven by some factors, including the functional requirements, the requirements within service level agreements (SLAs), the business benefits, and the overall design constraints.

Aspects of Service Design

Service design stage of the lifecycle adopts a holistic approach to designing a new, changed or retiring service. There are five aspects of Service Design which are considered, and we shall now be taking a brief view of these five aspects.

The first aspect is ‘design of service solution.’

The requirements for the new or changed services are taken from the service portfolio. Each of these requirements is analyzed, documented and solution design is produced. It is ensured that the design is consistent with other services and that all other services that interface with, underpin or depend on the new or changed service are consistent with the new service.

The second aspect is ‘the design of management information systems and tools.’

The management information systems and tools are reviewed to ensure that they are capable of supporting the new or changed service. In case any new systems and tools have required the designs for the same will be created.

The third aspect is ‘the design of technology architectures and management architectures.’

These are reviewed to ensure that all the technology architectures and management architectures are consistent with the new or changed service and have the capability to operate and maintain the new service. If required these are amended or new designs created.

The fourth aspect is ‘the design of required processes.’

All IT and service management processes are reviewed to ensure that these processes, related roles and responsibilities and skills have the capability to operate, support and maintain the new or changed services. Updates and adjustments to the design are made where required.

The fifth aspect is ‘the design of measurement methods and metrics.’

The existing measurement methods are reviewed to ensure that they can provide the required metrics on the new or changed service. If required, new metrics are designed, and updates to existing ones are made.

In the next section, we will discuss how to identify service requirements.

Identifying Service Requirements

Service Design must consider all elements of the service by taking a holistic approach to the design of a new service.

Following are some of the considerations:

• This approach should consider the service and its constituent components and their inter-relationships, ensuring that the services delivered meet the functionality and quality of service expected by the business in all areas
  
• The scalability of the service to meet future requirements, in support of the long-term business objectives
  
• The business processes and business units supported by the service
  
• The IT service and the agreed business functionality and requirements
  
• The service itself and its Service Level Requirement (SLR) or Service Level Agreement (SLA)
  
• The technology components used to deploy and deliver the service, including the infrastructure, the environment, the data and the applications
  
• The internally supported services and components and their associated Operational Level Agreements (OLAs)
  
• The externally supported services and components and their associated underpinning contracts, which will often have their own related agreements and schedules
  
• The performance measurements and metrics required
  
• The legislated or required security levels
  

No service can be designed, transitioned and operated in isolation. The relationship of each service to its supporting components and services must be clearly understood and recognized by all people within the service provider organization.

It is also essential that all targets contained within supporting agreements, such as OLAs and contracts, underpin those agreed between the service provider and its customers. Some of these concepts are discussed in more detail in later sections of the publication, concerning the individual aspects of Service Design.

However, when an individual aspect of a service is changed, all other areas of the service should also be considered to ensure that any amendments necessary to support the change are included in the overall design. Increasingly, services are complex and are delivered by some partner or supplier organizations.

Where multiple service providers are involved in the delivery of a service, it is vital that a central Service Design authority is established, to ensure services and processes are fully integrated across all parties. Within the specific area of technology, there are four separate technology domains that will need to be addressed, as they are the supporting components of every service and contribute to its overall performance. They are:

Infrastructure: the management and control of all infrastructure elements, including mainframes, servers, network equipment, database systems, storage area networks (SANs), network-attached storage (NAS), systems software, utilities, backup systems, firewalls, development and test environments, management tools, etc.

Environmental: the management and control of all environmental aspects of all major equipment rooms, including the physical space and layout, power, air conditioning, cabling, physical security, etc.

Data: the management and control of all data and information and its associated access, including test data where applicable

Applications: the management and control of all applications software, including both bought-in applications and in-house developed applications software.

Now, we will understand how to identify customer requirements.

Identifying Customer Requirements

IT must retain accurate information on business requirements and drivers if it is to provide the most appropriate catalog of services with an acceptable level of service quality that is aligned to business needs. Business drivers are the people, information, and tasks that support the fulfillment of business objectives.

This requires that IT develops and maintains close, regular and appropriate relationships and exchange of information to understand the operational, tactical and strategic requirements of the business. This information needs to be obtained and agreed in two main areas to maintain service alignment.

Information on the requirements of existing services – what changes will be required to existing services with regard to:

• New facilities and functionality requirements
  
• Changes in business processes, dependencies, priorities, criticality and impact
  
• Changes in volumes of service transactions
  
• Increased service levels and service level targets due to the new business driver, or reduced for old services, lowering priority for those due for replacement
  
• Additional needs for Service Management information.

This collection of information is the first and most important stage for designing and delivering new services or major changes to existing services. The need for accurate and representative information from the business is paramount. This must be agreed and signed off with senior representatives within the business.

If the incorrect or misleading information is obtained and used at this stage, then all subsequent stages will be delivering services that do not match the needs of the business. Also, there must be some formal process for the agreement and acceptance of changes to the business requirements, as these will often change and evolve during the Service Lifecycle.

The requirements and the design must evolve with the changing business environment to ensure that the business expectations are met. However, this must be a carefully managed process to ensure that the rate of change is kept at an agreed and manageable level, and does not ‘swamp’ and excessively delay the project or its implementation.

ITIL Intermediate Navigator tool

To find out what other ITIL Intermediate modules could complement this certification and teach skills relevant to these job roles, use our ITIL Intermediate Navigator tool.

ITIL Intermediate – Service Offerings and Agreements (SOA)

While working for the North Atlantic Treaty Organization (NATO) with responsibility for global service level agreements, certifying in ITIL^®’s Intermediate Service Offerings and Agreements (SOA) module was essential.

I really recognized the power of ITIL and service management while working as part of the NATO-led International Security Assistance Force (ISAF) in Afghanistan: each of the commands (military bases) there – which might have included a few tents on a hilltop with a laptop – was running its service desk independently.

By getting all 36 commands in the country to connect to a single toolset supported by ITIL meant the forces were able to differentiate between an IT incident and a Taliban attack.

On returning from Afghanistan, my new role was about transitioning generally-funded IT support in NATO to becoming customer-funded. This move meant having to explain better how IT was spending money, what a service was and why customers were paying for it.

This needed a re-examination of the whole organization, a centralization of IT operations and how to roll-out services to customers (i.e. the various commands, such as NATO’s Supreme Headquarters Allied Powers Europe).

The value of ITIL’s SOA

The commands want to be assured IT is following a business standard they can reference, which tells them you’re providing services correctly and can justify what you’re doing. For example, explaining the different elements that go into providing email, who is going to manage the service and why funding is required.

Having the certification is a step up and is recognized widely by other people in NATO, as even officers have studied ITIL Foundation.

Skills for the practitioner

Studying and certifying in SOA provides ITIL practitioners with a good understanding of the complexity in negotiating services and knowing whether you can deliver them or not.

For example, take service design. Someone might have an idea for a service, but they need to understand how they will support it, integrate it, select the right processes, monitor and report results.

Equally, with the growth of cloud services and the potential difficulties with how services will interact across an organization, SOA is the perfect certification to help you think about cloud infrastructure, negotiating the underpinning agreements, understanding security implications and what you will get under a service level agreement.

Having this knowledge is critical to have a fair chance of putting together a reliable, dependable, secure, outsourced IT infrastructure in the cloud.

Achieving ITIL’s SOA module makes you more valuable to your employer and able to represent your organization when negotiating cloud or SaaS technologies – you’re simply more aware of the questions you need to ask before signing on the dotted line.

ITIL® Intermediate Service Offerings and Agreements (SOA) focuses on the practical application of SOA practices.

ITIL® Intermediate Service Offerings and Agreements (SOA) is one of the ITIL® Service Capability modules. It focuses on the practical application of SOA practices to enable portfolio, service level, service catalogue, demand, supplier and financial management.

SOA has been designed to help organisations and professionals understand how the five stages of the ITIL lifecycle (service strategy, service design, service transition, service operation and continual service improvement) can offer value to organisations and projects. It also provides guidance on how service offerings can be developed to support the needs of both the business and the user.

The SOA certification can only be taken following an accredited training course.

Who is SOA for:

The SOA qualification would be suitable for IT professionals in roles such as IT Management, IT Finance Manager, Capacity Manager, Availability Manager, Service Level Manager, Business Continuity Manager, Service Portfolio Manager, Supplier Relationship Manager.