Strategy-Design

SERVICE STRATEGY

Service strategy shows organisations how to transform service management from an organisational capability into a strategic asset, and to then think and act in a strategic manner.

Service strategy helps clarify the relationships between various services, systems or processes and the business models, strategies or objectives they support.

The Objectives of Service Strategy

Service strategy shows organisations how to transform service management from an organisational capability into a strategic asset, and to then think and act in a strategic manner.

Service strategy helps clarify the relationships between various services, systems or processes and the business models, strategies or objectives they support.

Other objectives include:

- Provide business stakeholder value

 -Differentiate the organisation

 -Make solid cases for investment

 -Resolve conflicting demands for services

- Improve service quality by strategic planning

Value to the Organisation/Business of Service Strategy

 -Provides guidance on how to design, and put in place service management as a strategic asset

- Sets the principles for developing service management policies, guidelines and processes across the service lifecycle

 -Sets objectives and expectations of performance towards serving customers and market spaces

- Identifies and prioritises opportunities

 -Ensures that organisations can manage the costs and risks associated with their service portfolios

 -Asks questions and plans a strategy for how to do something before progressing

The Service Strategy volume 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 are 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 the development of markets, internal and external, service assets, Service Catalogue, and implementation of strategy through the Service Lifecycle. Financial Management, Service Portfolio Management, Organizational Development, and Strategic Risks are among other major topics. Organizations use the guidance to set objectives and expectations of performance towards serving customers and market spaces, and to identify, select, and prioritize opportunities. Service Strategy is about ensuring that organizations are in a position to handle the costs and risks associated with their Service Portfolios, and are set up not just for operational effectiveness but also for distinctive performance. Decisions made with respect to Service Strategy have far-reaching consequences including those with delayed effect.

Organizations already practising ITIL may use this publication to guide a strategic review of their ITIL-based service management capabilities and to improve the alignment between those capabilities and their business strategies. This volume of ITIL encourages readers to stop and think about why something is to be done before thinking of how. Answers to the first type of questions are closer to the customer’s business. Service Strategy expands the scope of the ITIL framework beyond the traditional audience of IT Service Management professionals.

The Following Processes are part of the ITIL Stage Service Strategy:

Strategy Management for IT Services

Process Objective: To assess the service provider’s offerings, capabilities, competitors as well as current and potential market spaces in order to develop a strategy to serve customers. Once the strategy has been defined, Strategy Management for IT Services is also responsible for ensuring the implementation of the strategy.

Service Portfolio Management

Process Objective: To manage the service portfolio. Service Portfolio Management ensures that the service provider has the right mix of services to meet required business outcomes at an appropriate level of investment.

Demand Management

Process Objective: To understand, anticipate and influence customer demand for services. Demand Management works with Capacity Management to ensure that the service provider has sufficient capacity to meet the required demand.

Financial Management for IT Services

Process Objective: To manage the service provider’s budgeting, accounting and charging requirements.

Business Relationship Management

Process Objective: To maintain a positive relationship with customers. Business Relationship Management identifies the needs of existing and potential customers and ensures that appropriate services are developed to meet those needs.

1. STRATEGY GENERATİON

For positive results, service provider needs to plan his services strategically. A good service strategy defines a unique approach for delivering better value.

Service Strategy Manager is the process owner of this process.

For long term success the service provider has to be able to think and act strategically. According to ITIL the service straregy proces incorporates four incorporates four fundamental activities:

·         Defining the market

·         Developing offerings

·         Developing strategic assets

·         Measuring and Preparation for implementation of strategy

Defining the market

It is necessary to take survey of services available in the market. It gives a clear perspective of cost and quality of services already present and what new service can be offered in competitive environment.

Developing offerings

In this service provider develops a portfolio which contain all the services that are visible and available for the customer. Service portfolio is developed in order to represent all binding service investments towards the market.

Developing strategic assets

It deals with buying new technologies, resources and capabilities to offer law-cost and high-value service to the customer.

Measuring and Preparation for implementation of strategy

In order to measure success or failure of the strategy, all critical success factors are measured. Also the completion in the market is observed and priorities are adjusted accordingly.

2.     DEMAND MANAGEMENT

Demand Management is very important and critical process in service strategy. It helps to understand customer demand for services so that appropriate capacity can be provisioned to meet those demands.

According to ITIL, the purpose of demand management is to understand, anticipate, and influence customer demand for services. 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 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.

3. SERVİCE  PORTFOLİO MANAGEMENT

What is Service Portfolio Management from an ITIL perspective?

A Service Portfolio describes the services of a provider (internal, outsourced etc) in terms of value to the business.

It is an ever changing method used to manage investments in Service Management across the organization, in terms of financial values.  Service Portfolio Management (SPM) enables Managers to assess the quality requirements and associated costs.

The primary goal of SPM is to realize maximum value whilst managing accompanying risks and costs.

So how can SPM help when decide what services clients require?  There are 5 basic questions that need to be answered:

§  Why should a client buy these services?

§  Why should a client buy these services from our organization?

§  What are the price and charge back models?

§  What are our strengths and weakness, priorities and risks?

§  How should our resources and capabilities be allocated?

Product Managers play a key role in Service Portfolio Management.  Their main responsibility is to manage services as products during their entire lifecycle.  Other roles include the co-ordination and focus of the organization as well as owning the Service Catalogue.

The Service Portfolio covers 3 subsets:

§  Service Pipeline-The service pipeline represents the strategic outlook that you, the service provider, should take. Services begin their lifecycle in the service pipeline, starting with the strategic assessment of the marketplace and/or customers to be  served. The pipeline includes the services that have been  requested and are currently being evaluated. Here, you  identify the requirements of the requested services. You  then define and analyze the services based on a number  of factors, including cost, risk, and expected business value. Based on the analysis, you either approve or reject requested services. Approved services proceed from the service pipeline to the service catalog. Service pipeline processes are defined in the ITIL V3 Service Strategy book.

§  Service Catalog-The service catalog is the subset of the service portfolio that is visible to customers. The service catalog includes all services that have been approved and are either in development or currently deployed.Services include outsourced, co-sourced, and managed services. ITIL V3 defines several attributes to be maintained by the service catalog for each service, such as the following:

v  Service description

v  Policies

v  SLAs

v  Ordering and request procedures

v  Support terms and conditions

v  Pricing and chargeback

Here, you assess the feasibility of the services that come into the service catalog from the service pipeline, and either charter or reject them. Chartered services move to the design and development phases. Developed services are then built, tested, released, and deployed. At this point, services become operational, and you engage resources to support them.The service catalog is used to develop requestable services that customers can purchase and consume. A mature service catalog is a very powerful tool for decision making. By analyzing the demand and fulfillment capabilities a service provides, a service portfolio management approach can

assist you in making decisions to expand a service or the marketplace to serve to meet future demands.

§   Retired Services – It is necessary to review the service portfolio periodically to determine whether any services should be retired. Services targeted for retirement may include those that are no longer needed by the business, those that have been superseded by other services, and those that are no longer cost-effective.Retire these services and identify them as “retired” in the service portfolio.

Finally, Service Portfolio provides input for refreshing services in the Service Catologue. 

Implementing and Leveraging the Service Portfolio

Solutions can facilitate the implementation and management of the service portfolio. For example, some include an automatic discovery capability that initially populates the CMDB and keeps it updated with changes. This ensures that your service catalog is always providing up-to-date information about available services. Solutions can be used to implement a business service catalog as well a technical service catalog and can provide tools to manage them. Gaining Control of Development Projects.Project portfolio management solutions leverage information in the service portfolio to permit more effective planning and management of service development projects. They can help you in a number of importantareas, including the following:

v  Project portfolio business value and risk analysis

v  Project portfolio prioritization

v  Project management with customizable processes and workflow

v  Project financials management

v  Program management

These solutions give you increased visibility into development projects across the enterprise. With this visibility, you can determine the most valuable projects to pursue, and you can execute those projects as efficiently as possible. In addition, you can make more accurate budget forecasts and build collaborative relationships with IT clients. As a result, you will achieve the optimum balance between market needs and your agility and ability to respond, and ultimately, can determine the Return on Investment (ROI) or Return on Value (ROV) of your projects.Automating Service Request Management. A major problem faced by many IT departments is that users do not know what services are available to them, let alone the details of those services, such as how to order them and what they cost. Typically, users contact the service desk to obtain this information, adding to an already high service desk workload.

Once users determine the services they want, they also havea difficult time procuring them, often because they need to deal with several different sources to complete a single business service. For example, a manager onboarding a new employee may have to deal with several departments to provision the employee with a furnished office, including computer equipment. After requesting services, the manager has to track delivery status across the multiple departments involved.Automated service request management systems can leverage the service catalog to provide automated service request management and fulfillment. The user consults an online service catalog to determine what services are available. The catalog contains all the information the user needs to know to order a service, such as service description,terms and conditions of use, performance and availability, warranties, price, and request procedure. A well-designed system displays only those services that the user is authorized to request, based on his or herrole.The user selects the service and enters the required information into the online service request form. The service request management system automatically triggers the required actions to process and fulfill the request. The system tracks the progress of each task and notifies the user when fulfillment has been successfully completed. In addition, the user can determine the status of a request at any time by consulting the system.It’scommon knowledge that 20 percent of all the services provide 80 percent of all the value and work effort. By automating these high-intensity services, you can create a very strong ROI. Automated service request management makes it easy for users to request a service. In addition, it incorporates best practices to help IT process requests in a timely manner, reducing service desk workload and enforcing company policies and standards. Extending Beyond IT Services Once you have put in place a strong IT service portfolio management capability, you can extend it beyond the management of IT services. This gives you the ability to apply service portfolio management principles and processes to other services that the enterprise provides and consumes, both internally and externally.

4. ITIL FINANCIAL MANAGEMENT

It is important to spend money wisely. Financial Management is a strategic tool that is relevant to all three service provider types. Increasingly, internal service providers are asked to operate with the same levels of financial visibility and accountability as their external counterparts. In the case of external service providers, the innovative provision of technology is the core revenue generating capability of their company.

Financial Management allows an organisation to understand the worth of their IT services in financial terms. It will also aid the understanding of the value of the assets provisioning those services and allows us to set realistic budgets. The key thing is to be able to attribute a value to the services being offered. This will cause a change in perception of IT and its value to the business.

As part of Financial Management we should be asking questions such as:

Which services cost us most to deliver and why?

What services are we offering, what is the demand for these services and how much does it cost us to provide them?

How efficient is the way we deliver service compared with the alternatives?

Where are our greatest service inefficiencies?

Which areas represent the highest priority opportunities for us to focus on in terms of Continual Service Improvement?

And after applying ITIL based financial management, both the client and the service provider aims to have the following capabilities:

* Enhanced decision making
* Speed of change
* Service portfolio management
* Financial compliance and control
* Operational control
* Value capture and creation

The Business Case

For each and every service offered there should be adequate business justification. A good business case will consider both qualitative and quantitative dimensions. In the case of the latter financial analysis is often key. A business case may take many forms but broadly speaking all will include objectives and impact and will take the following form:

An introduction

This serves to present the objectives addressed by the service. What is the proposal about and what do we hope to achieve?

Methods and assumptions

It is important to state any assumptions so that these may be compared later against reality. If there is a variance then this may identify why the expected outcome did not materialise. It is also important to document methods. These may help to identify scope, time periods and costs which will help with the evaluation. The likely beneficiary will also need to be identified.

The business impact.

This is where the beneficial outcomes, both financial and non-Âfinancial are identified. Clearly a commercial service provider will mostly be concerned with profitability of service whereas the not for profit organisation may propose a business case which focuses on altruism. Nevertheless both providers will need to show a degree of financial and organisational performance.

Risks and contingencies

The identification of possible alternate outcomes which might be experienced and the identification of ways of reducing the likelihood or accommodation of the outcome if it occurs.

SERVICE DESİGN

Provides a blueprint for the services. It not only includes designing of new service but also devises changes and improvements to existing ones.It also let the service provider know how the design capabilities for service management can be developed and acquired.

It is necessary for services to be adaptable to changing business requirements on dynamic basis. For this a balance must be maintained between following three factors:

·         Functionality with the required quality.

·         Resources i.e. staff, technologies, and available finances.

·         Timetable

Service Design focuses on the following aspects:

·         IT Services designed to meet business objectives.

·         Services designed to be both fit for purpose and fit for use.

·         Cost of ownership planed to achieve return on investment.

·         Balanced functionality, cost and performance.

·         IT services more stable and more predictable.

·         Potential risk mitigated, so the IT service is protected from security threats.

·         Design technology architectures, management architectures, and system management tools.

·         Design of the measurement systems, methods, and metrics for services, processes, architectures and underlying components.

·         Design of the service solution including all agreed functional requirements, resources and capabilities.

1. SUPPLIER MANAGEMENT

Supplier Management ensures that external services and configuration items, which are necessary for the service delivery, are available as requested and as agreed at the service level.

Supplier Management is responsible for consolidating requirements for external services and supplies, scanning the market for providers, negotiating with a chosen supplier, and for the contracting and monitoring of external services and service providers. Management of supplier relationships and supplier performance are additional tasks. Supplier Management is also responsible for establishing and updating the basic supplier framework, which is a Supplier Strategy and Supplier Policies.

Supplier Management is triggered from the Service Portfolio Management whenever a new supplier is necessary.

Supplier Management in

ITIL V3: part of Service Design

COBIT: part of Acquire and Implement

ISO/IEC 20000: Supplier Management

In ITIL V3, Supplier Management is part of the Service Design process to allow for a better integration into the Service Lifecycle - Supplier Management was covered within "ICT Infrastructure Management" in the previous ITIL version.

ITIL Supplier Management

Following the introduction of Design Coordination in ITIL 2011 the information flows have been adapted slightly. The process overview of ITIL Supplier Management (.JPG) is showing the most important interfaces (see Figure 1).

All suppliers and contracts are managed through the Supplier and Contract Management Information System (SCMIS), which in ITIL V3 was known as the Supplier & Contract Database (SCD).

2. SERVİCE CATALOG MANAGEMENT

Service Catalogue Management was added as a new process in ITIL V3.

Service Catalogue Management

In the previous ITIL version, the Service Level Management process mentioned the concept of a Service Catalogue.

ITIL V3 takes this concept further, introducing a dedicated process to ensure that the Service Catalogue is up-to-date and contains reliable information.

A clear distinction exists between Business Services in the Service Catalogue (services visible to the customer, defined by SLAs) and Supporting Services (services visible only inside the IT organization, defined by OLAs orUCs).

In ITIL 2011 the process interfaces have been adapted slightly following the introduction of the Design Coordination process. The process overview of Service Catalogue Management (.JPG) is showing the most important interfaces (see Figure 1).

Each service in the catalogue contains the following elements:

·         A identification label for the service

·         Description of services

·         Related service request types

·         Any supporting or underpinning services

·         Service categorization or type that allows it to be grouped with other similar services

·         Interfaces and dependencies between all services, and supporting components and configuration items (CIs) within the service catalogue and the CMS

·         Clear ownership of and accountability for the service

·         Associated costs

·         How to request the service and how its delivery is fulfilled

·         Escalation points and key contracts

·         Service level agreement (SLA) data

3. INFORMATION SECURITY MANAGEMENT

Description/Summary

Information Security Management deals with the implementation and monitoring of a predefined security level for the IT environment. In particular, it addresses areas such confidentiality, integrity and availability. Risk analysis, as the starting point, helps to define the customer requirements on a security level. An internal, minimal security requirement is named IT basic protection. Additional security requirements of the customer are to be defined on an individual basis.

Objectives

To introduce and maintain a required level of security, as defined by law, contracts or other agreements.

Information Security Management contributes to an integrated Service Management approach by achieving the following activities:

·         Identifying and defining the internal and external security requirements

·         Planning of security procedures

·         Creating a security chapter in the SLA and Service Description

·         Managing the implementation of security actions

·         Evaluating the security procedures and security measures

·         Security Reporting

·         Security Improvement

·          

Roles &Functions

Security Management specific roles

Static Process Roles

     Security Process Owner

Initiator of the process, accountable for defining the process strategic goals and allocating all required process resources. See Continual Process Improvement Management for a detailed description of these activities.

   Security Process Manager (Security Manager)

IT Security Management Process is controlled by the Security Manager. The Security Manager can delegate tasks to specialized staff. Should it be necessary to use external staff, an approval of the budget by the responsible person is required.

 

    IT Security Management Team

Team in Security Management perform mandatory tasks for the Security Manager.

Dynamic Process Roles

   Security Auditor

Security Auditor is providing the verification of security policies, processes and tools. Auditor should be altering an external and internal resource to provide independent and reliable audit.

Service Specific Roles

Roles depending on the affected service are found in the Service Description. The Service Description, including the service specific roles, is delivered from the Service Portfolio Management.

·         Service Expert/Service Specialist:

·         Service Owner:

·         Service User:

Customer Specific Roles

Roles depending on the affected customer(s) are found in the Service Level Agreement. The Service Level Agreement for the customer specific roles is maintained by the Service Level Agreement Management.

   Customer(s)

Customers of the affected service with a valid SLA

Information artifacts

Security Policy

The process depends on general security rules. Moreover, this process is responsible for the permanent improvement and adjustment of general security policies and rules.

Security Design Record

·         Security Design ID

·         Security Design Requester

·         Security Design Description

·         Security Design Agent

·         Security Design Owner

·         Service: The Service which has to be (re)designed

·         Service Integrity

·         Service Confidentiality

Security Transition Record

·         Security Transaction ID

·         Security Transition Requester

·         Security Transition Description

·         Security Transition Agent

·         Security Transition Owner

·         Service: Services affected by the Change

·         Configuration Items: CI affected by the Change

Security Verification record

·         Security Verification ID

·         Security Verification Requester

·         Security Verification Description

·         Security Verification Agent

·         Security Verification Owner

·         Security Verification Auditor

·         Service: Services affected by the Security Audit

·         Configuration Items: CI affected by the Security Audit

·         Customer: Customer affected by the Security Audit

·         User: User affected by the Security Audit

·         Expert/Specialists: Expert/Specialists affected by the Security Audit

Key Concepts

Availability

Information and the service must be accessible to authorised users.

Integrity

Information must not be modified by unauthorized users. Following levels of integrity are possible:

·         0: it can not be proven if integrity was violated

·         1: it can be proven if integrity was violated

·         2: it can be proved if integrity was violated and the violation can be reversed

Confidentiality

Information must not be accessible by unauthorized users. Following levels of confidentiality are possible:

·         public: information is available for all

·         confidential: information is available for authorised personnel only and assigned external partners

·         confidential - for intern use only: information is available for authorised personnel only

·         top secret: information is available for senior management only

The Confidentiality Levels can be expanded or adjusted.

Authentication

Verification of identity of a user or information.

Authorization

Methods and tools used to decide if user or information is allowed to have access other devices or sources of information.

Severity Breach Levels

Severity levels here indicate the importance of an optimization proposal or security incident. The following levels can be defined as:

Critical

The level "critical" needs to be implemented, including changes, as soon as possible.

High

The level "high" needs to be implemented, including changes, within next 2 days.

Low

The level "low" needs to be implemented, including changes, within next 7 days.

Process

Critical Success Factors

Critical Success Factors (CSF) define a limited amount of factors which influence the success of a process. For Security Management, the following factors can be defined as CSF:

·         Right dimension of security, by avoiding too strict or too lax security

·         Management support for security issues

·         Security awareness in the company

·         Definition of responsibilities between security implementation and security control activities and roles

Security Manager must review the CSFs and must define and implement measures to fulfill the process success.

Security Policy

High Level Process Flow Chart

This chart illustrates the Security Policy Creation and Control

Performance Indicators (KPI)

·         Number of changes to Security policy

·         Number of awareness programs

Process Trigger

Event Trigger

·         The process is is not time triggered

Time Trigger

·         Security Policy is activated periodically

Process Specific Rules

·         Each Change to the Security Policy has to be documented

·         Each Change to the Security Policy has to be published

Process Activities

Security Policy Definition

Security Policy Definition is dealing with definition of

·         Basic security rules collected in a Security Policy

Basic Security rules define the Security vision, organization and are business strategy aligned. Main orientation rule is the balance between high security standard for internal IT services, services provided and external supplied services and required services and good commercial “value for money” proposition.

Activity Specific Rules

·         Security Manager is set to the person who is responsible for security process

·         Security Process Owner Manager is set to the person who is accountable for security process

·         The Security Policy is created or updated

·         add new Rules

·         modify existing rules

·         delete unnecessary rules

·         The Security Policy is signed by the Senior Management and published

Security Policy Controlling

Security Policy Implementation and Monitoring is responsible for the implementation, communication, monitoring and update of security rules and policies.

Activity Specific Rules

·         Communicate Security Policy

·         Check for new Security Threats

·         trigger Security Policy update when necessary

·         Assure that staff understands and the rules by auditing and teaching staff

Security Design Assistance

Sub process Design in Security Management is responsible for the initial planing or planning of optimizations of the security process. If a change proposal on security process is classified the change needs to be planned as well. This is performed by an expert out of the responsible expert group in coordination with a member of the IT security staff. This sub process is triggered by Service Design. After the activity is finished, the status needs to be changed to planned.

The Process owner is the Security Manager. The Process agent is an expert assigned by "Security Staff".

High Level Process Flow Chart

This chart illustrates the Security Management Design process and its activities

Performance Indicators (KPI)

·         Number of new Security Design Assistance Requests

·         Number of "approved - successful" and "approved - unsuccessful" Security Design Assistance Requests

·         Ratio of "approved - successful" and "approved - unsuccessful" Security Design Assistance Requests

Process Trigger                                                                                             

Event Trigger

·         The process is initiated by the Change Management.

Time Trigger

·         Security Design Assistance is not time triggered

Process Specific Rules

·         Each Security Design assistance Request must be recorded

·         The Security Design Agent has to document the request and result of the design request

·         The Security Design Owner has to control the Agent

·         The Security Design Agent has to coordinate his work with other Design Agents

·         The Security Design Requester has to be informed

Process Activities

Design of Security Part in Service Design Package

Within this activity, the security section of the service design package is designed. This includes information on accessibility, security actions and measures, relevant passwords and policies etc.

Activity Specific Rules

·         set the Security Design Owner to a member of the IT security Management Staff

·         set the Security Design Agent to a member of the Service Expert or Specialist Group

·         Design Security according to the Security Requirements and the Security Policy

·         coordinate Security Design package with the activity "Service Design" and other relevant Service Designer

·         document in the Service Design package and fill out the Security Design Record

·         go to control activity "designed^"

Approval of Security Design Package

With this activity, the Security Manager approves the Security Design Package.

·         Security Design Package is finally neglected

·         Approval of the Security Design Package is temporarily refused and returned to the security expert for the improvement or optimization

·         Security Design Package is accepted.

Activity Specific Rules

·         set the Security Design Agent to Security Manager

·         Approval the Security Design Package and the documentation in the Security Design Record

·         If approval is posit iv go to control activity "approved - successful"

·         else

·         go to control activity "new" for a redesign of the Security Design Package

·         or "approved - unsuccessful" for final abortion

Security Transition Assistance

This activity, in cooperation with Change Management, supports the implementation and testing of security improvements by designing, testing, implementing and then testing the implementation again. These actions are headed by Change Management.

If a security improvement proposal is authorized and approved by Change Management, all action's functional descriptions and implementation procedures, which are described in the improvement proposal need to be detailed, tested and approved in cooperation with theChange Management. Afterwords the implementation should be assisted to provide help in case emergency or implementation issues.

A final PIR, conducted together with Change Management also includes testing.

High Level Process Flow Chart

This chart illustrates the Security Transition Assistance process and its 

Performance Indicators (KPI)

·         Number of Security Transition Assistance Request

·         throughput time (min/average/max) for a Transition Assistance Request until "assisted - closed"

Process Trigger

Event Trigger

·         Process is triggered by different activities in the Change Management.

Time Trigger

·         Security Transition Assistance is not time triggered

Process Specific Rules

·         Each Security Transition Assistance Request must be recorded

·         The Security Transition Agent has to document the request and result of the design request

·         The Security Transition Owner has to control the Agent

·         The Security Transition Agent has to coordinate his work with other Transition Agents

·         The Security Transition Requester from the Change Management has to be updated

Process Activities

Creation Risk Analysis and Feasibility Study

If a Security Transition Assistance is requested by Change Management the following 2 documents need to be defined:

·         Feasibility Study

·         Risk Analysis

Following aspects need to be addressed within a Feasibility Study:

·         Feasibility of proposal

·         Risk of implementation

·         Risk of neglecting proposal

·         Costs

A Feasibility Study is based on high level planning and should not address detailed planning because of the possibility that the proposed change will not be accepted. Detailed planning of the Change is part of the activity "Build - Implement - Test - Assistance " after the Change has been authorized.

A Feasibility Study is provided by an expert or specialist of the address service. Eventually additional requirements provided by other processes, such as Financial, Availability orCapacity Management will also need to be reviewed.

After the responsible expert finishes their contribution to the planning of the security actions, the status needs to be set on planned design package

Activity Specific Rules

·         set the "Security Transition Owner" to a member of the IT Security Management Staff

·         set the "Security Transition Agent" to a member of the Service Expert or Specialist Group

·         Create a Security Feasibility Study & Risk Analysis according to the Change Requirements and the Security Policy

·         coordinate Creation of the Security Feasibility Study & Risk Analysis package with others

·         document in the Security Feasibility Study & Risk Analysis Document as well as in the Security Transition Record

·         go to control activity "created^"

Build - Test - Implement - Assistance

If a security change is approved for implementation, Change Management will request assistance from Security Management, who in turn may request assistence from the sub-process Build, Test, Implement and Assistance.

This activity provides the following information:

·         A detailed definition of implementation instructions

·         A detailed definition of test procedures and documents

·         Support during implementation

·         Approval of the implementation

Within the change plan the order and time line of actions need to be described. Testing documentation must address the test design and ensure the effectiveness of the test.

The Test has to be executed before the live Change takes place and is split up into two main test areas:

·         1. Test of the implementation - "Does the provided document describe the right implementation actions in the right implementation order?"

·         2. Test the functionality of the new service in the test-system - "Does the system perform the functions defined in Change?". This test is performed according to the defined testing documentation. The result has to be documented an the Change Management has to be informed.

Implementation activities are fulfilled and lead by Change Management. Security Management only assists and supports with regards to the security aspects and functions.

Activity Specific Rules

·         support creation of the implementation plan including fallback plan

·         support creation of the test plan

·         support test of the implementation plan including fallback plan

·         support implementation

·         document activities and Test results

·         coordinate work with Change Management

·         go to control activity "assisted"

Evaluation and Closure Assistance

In coordination with the Post Implementation Review of the Change, Security Managment helps to test the implementation from the security point of view. In cases of a failed tests, the Change Management has to decide if the fallback plan has to be executed or the implementation can be accepted despite any issues in testing.

Activity Specific Rules

·         support Post Implementation Review and tests

·         consult Change Managment about Fallback Execution

·         support fallback implementation if nessecary

·         document Activities and Security Test results & Fallback Implementation

·         go to control activity "assisted - closed"

Security Verification

This activity is performed by the Security Manager. The target of the activity is to verify, if implemented, that security optimization fulfills the planned results - Verification uses the "Four-Eye Principle".

If actions do not provide the results planned, the status can be set to re-designed. Planning activity needs to be started again. If it is decided that a security improvement action is not approved, then the status should be set to cancelled. If the Security Management approved that decision, the status is being set to OK. In the perspective of Security Management, these actions are approved and can be implemented once the Change Management has authorized the actions.

High Level Process Flow Chart

This chart illustrates the Security Management Verification process and its activities

Performance Indicators (KPI)

·         Number of security incidents per audit by breach level

·         Number of external security audits

·         Number of internal security audits

·         Top Ten services with the most security incidents

Process Trigger

Event Trigger

·         Any request for a Security Audit

·         from any Process Manager or Process Owner

·         from any Service Owner

·         from Senior Management

·         from Customer and Customer Owner (Account Manager)

Time Trigger

·         Security Audits are often time triggered and processed on regular base. Regular Security Audits are defined in

·         Security Policy

·         the Process Description

·         the Service Description

·         Servie Level Agreements (SLA)

·         Operational Level Agreements (OLA)

·         Underpinning Contracts

Process Specific Rules

Process Activities

Planning of Verification Activities

This activity plans the audit activities. Issues to be addressed by the planning:

·         Which services need to be audited regrading security issues?

This depends on the number of security incidents and the severity of security incidents per service as well as the importance of a service.

·         What is the scope of the audit?

What is the extend of the audit: full audit or just the check of few indicators?

·         Auditing method?

Audit to be fulfilled by checks, real life tests or just an questionnaire?

·         How often is the audit needed?

This depends on the number of security incidents and the severity of security incidents per service as well as the importance of a service and how exposed a service is to external and internal threads.

·         Who is performing the audits?

Auditors need to be alternated often to assure that the auditor is independent, not influenced by options or customer relationship and by the will to keep the auditing contract.

Result of this activity is a audit plan, that need to be communicated.

Activity Specific Rules

·         set Security Verification Agent to member of IT Security Management Staff

·         set Security Verification Owner to Security Manager

·         set Security Verification Requester

·         create Security Verification Description

·         select Security Verification Auditor according to the Security Policy

·         document Service affected by the Security Audit

·         document Configuration Items affected by the Security Audit

·         document Customer affected by the Security Audit

·         document User affected by the Security Audit

·         document Expert/Specialists affected by the Security Audit

·         create audit plan

·         go to control activity "planed"

Performing Verification Activities

Based on an audit plan, the audit is performed by the Security Verification Auditor

Activity Specific Rules

·         set Security Verification Agent to Security Verification Auditor

·         set Security Verification Owner to Security Manager

·         documet result in Security Verification Record

·         go to control activity "performed"

Review of Verification Results

Results of the audit need to be checked. If Security incidents occur these need to be classified in severity breach levels and handled by the Process Manager. In case of minor changes the Change Management is addressed, in case of major changes, the process is started with a redesign of new design of e Security Package.

Activity Specific Rules

·         set Security Verification Agent to Security Verification Auditor

·         evaluation & classification of each Security Incident

·         trigger Incident, Problem or Change Management where necessary

·         document result in Security Verification Record

·         go to control activity "reviewed"

4. CAPACITY MANAGEMENT

ITIL capacity management is responsible for ensuring that adequate capacity is available at all times to meet the agreed needs of the business in a cost-effective manner. The capacity management process works closely with service level management to ensure that the business’ requirements for capacity and performance can be met. Capacity management also serves as a focal point for any capacity issues in IT Service Management. Capacity management supports the service desk and incident and problem management in the resolution of incidents and problems related to capacity.

Successful capacity management requires a thorough understanding of how business demand influences demand for services, and how service demand influences demand on components. This is reflected by the three subprocesses of capacity management: business capacity management, service capacity management, and component capacity management. It is required that capacity management develop a capacity plan, which addresses both current capacity and performance issues, as well as future requirements. The capacity plan should be used throughout IT Service Management for planning and budgeting purposes.

Capacity management is responsible for defining the metrics to be captured during service operation to measure performance and use of capacity. This includes monitoring tools, which can provide input to the event management process. Capacity management may be called upon to perform tactical demand management, which involves using techniques such as differential charging to change users’ behavior so that demand does not exceed supply. Other activities of Capacity management include sizing (working with developers to understand capacity requirements of new services) and modeling (building statistical representations of systems).

Capacity Management Definitions

Before implementing capacity management, it’s important everyone is on the same page. One way for an organization to accomplish this is to learn and own the definition. Capacity management introduces new ideas and terms that should be discussed before they are implemented, including component, capacity plan, capacity report, capacity management information system, and performance.

A component is the underlying structure behind a service. For example, it is the database behind the application or the server underneath the website. It is a component that must be purchased, built, maintained, and monitored. Improving performance often involves a replacement, upgrade, or load balancing of the individual component.

The capacity plan contains different scenarios for predicted business demand and offers costed options for delivering the service-level targets as specified. This plan allows service designers to make the best choices about how to provide quality service at an affordable price point.

The capacity report is a document that provides other IT management with data regarding service and resource usage and performance. This is used to help other managers make service-level decisions or decisions regarding individual components.

The capacity management information system (CMIS) is the virtual repository used to store capacity data. Dashboards are one way to store and report on capacity data.

Performance is how quickly a system responds to requests. For example, how quickly an application processes data and returns a new screen is one indicator of its performance. 

The Purpose of Capacity Management

The purpose of capacity management is to determine how much capacity should be provided based on the information from demand management regarding what should be provided. In particular, capacity management is concerned with speed and efficiency. If IT capacity forecasts are accurate and the amount of IT capacity in place meets business needs, the capacity management process is a success.

Capacity Management Activities

This process involves constant measurement, modeling, management, and reporting. More specifically, these activities include:

·         Designing a service so that it meets service-level agreement (SLA) objectives once implemented

·         Managing resource performance so that services meet SLA objectives

·         Assisting with the diagnosis of performance-related incidents and problems

·         Creating and maintaining a capacity plan that aligns with the organization’s budget cycle, paying particular attention to costs against resources and supply versus demand

·         Continually reviewing current service capacity and service performance

·         Gathering and assessing data regarding service usage, and documenting new requirements as necessary

·         Guiding the implementation of changes related to capacity

In practice, implementing this from scratch would involve the same steps as for other projects. For example, implementation might follow these broad steps:

1. Gather the data

Work with business to determine the service-level need. Determine what this means relative to service availability and service capacity. Identify the individual components necessary. Work with demand management resources to predict demand based on user roles. Work with the financial management team to determine the costs.

2. Design a service and reach agreement

Once you've identified the services and the level of performance needed, the cost, and the expected demand, you'll be able to work with ITIL service level management to build an SLA that everyone can agree to. You will also have designed a service at this point.

3. Build the service

The next step is to build the service. This involves purchasing the components and building the IT infrastructure, processes, and documentation necessary to support the new service/s. Capacity management should continue to monitor the business needs and any new data to ensure that the service being built will have the necessary capacity for quality performance. Financial management will be involved at this stage to facilitate purchasing of components and other resources. 

4. Operation

Once you have built the service, and everyone agrees it will meet demand, capacity, and availability requirements, it's go-live time. This is when service operation takes over. Capacity management then supports service operation to deliver services that meet targets.

Monitoring and managing services and their individual components are most easily done via monitoring dashboards that provide data on multiple components in one location. Gathering the data manually from each service or component adds to the total time it takes to produce service-capacity reports.

Capacity Management Processes

This process is built on several sub-processes, including business capacity management, service capacity management, component capacity management, and capacity management reporting. These processes share common activities, such as modeling, workload management, analysis, and optimization.

Business capacity management is the sub-process that turns the needs of the business into IT service requirements. It is involved in service strategy and service design, reviewing the data to ensure that there will be not be any changes in demand before the IT service is implemented. This sub-process works with demand management to ensure that the service is meeting business needs. Other sub-processes make sure that the service meets service-level targets; this sub-process ensures that the service-level targets meet the business needs. A thorough understanding of the business and the service-level agreements is necessary to effectively perform the activities in this sub-process.

Service capacity management is the sub-process that focuses on the operation of the service. Unlike component capacity management, this process focuses solely on the service itself. It ensures that the end-to-end service provided meets agreed-upon service-level targets. For example, this process would monitor, control, and predict a ticketing system to ensure it was up and running efficiently.

Component capacity management focuses on the technology that provides the performance and capacity to the IT service. Components are things like hard disks, phones, and databases. This sub-process requires knowledge of how each component individually contributes to service performance. It manages, controls, and predicts performance usage and capacity of individual components rather than the service as a whole (as seen in service capacity management). The goal of this sub-process is to reduce the total amount of service downtime by monitoring current performance and predicting future performance. Component capacities are designed around service capacities and not the other way around.

Capacity management reporting is the final sub-process. It gathers and then provides other stages with the data related to service capacity, service usage, and service performance. The output of this sub-process is the service capacity report.

Capacity Management and Other ITIL Processes

Capacity management must interface with other processes within ITIL, including demand management, availability management, service-level management, and financial management. When the business has a service need, it comes from demand management. It's then relayed to the business continuity management team, which then translates it into an SLA and capacity terms. Service-level management helps with this. Once the service is deployed, service capacity management and component capacity management come in to keep everything at peak performance. Availability management works hand-in-hand with capacity management to keep services running and prevent downtime. Financial management comes into play when individual components must be estimated, purchased, maintained, and replaced. Not working closely with financial management can result in either untimely drops in uptime or organizational budget losses.

5. AVAILABILITY MANAGEMENT

Is one of five components in the ITIL Service Delivery area. It is responsible for ensuring application systems are up and available for use according to the conditions of the Service Level Agreements (SLAs).

The Availability Management team reviews business process availability requirements and ensures the most cost effective contingency plans are put in place and tested on a regular basis to ensure business needs are met. For example, Internet applications supporting online ordering systems may have 30-minute or less recovery requirements, so they may be provisioned with infrastructure components providing several levels of redundancy. Less critical, non-customer-facing applications used by a few users in small offices with a 5-day recovery period may be provisioned on less expensive infrastructure with limited redundancy capabilities.

Availability Management is also the lead in Component Failure Impact Analysis and Service Outage Analysis initiatives, determining cause, analyzing trends and taking any appropriate actions to ensure service availability meets SLAs.

Availability Management activities include:

·         Ensuring service availability meets SLAs

·         Determining the cause of availability failures

·         Reviewing business requirements for availability of business systems

·         Cataloging business requirements

·         Ensuring proper contingency plans are in place and tested

·         Establishing high-availability, redundant systems to support mission-critical applications

  Benefits to implementing Availability Management processes include:

·         Services are available for use during expected timeframes as specified in SLAs.

·         Services are provisioned on specific infrastructure depending upon their availability needs. This avoids unnecessary costs due to provisioning services with longer recovery times on more expensive high-availability platforms.

·         Potential service availability issues are identified and corrected before they negatively impact services.

Availability Management processes are tightly integrated with Service Level Management, Capacity Management, IT Service Continuity Management, and Incident Management.

TeamQuest Predictor allows you to run multiple scenarios to show business units the impact of various availability management decisions, helping to determine the optimal performance levels needed to meet business unit goals while ensuring that these metrics can be tracked and reported on an ongoing basis.

TeamQuest Analyzer allows you to monitor availability metrics of a large number of systems through color indicators. It also provides detailed diagnostic capabilities to quickly determine the probable cause of an outage, and more importantly, how to keep the problem from recurring. TeamQuest Analyzer also captures historical data for trend reporting, allowing IT to proactively predict potential issues and address them before they become problems.

TeamQuest Surveyor automatically publishes reports containing availability metrics taken from not only the TeamQuest CMIS, but other performance databases as well. You can customize availability reports for different audiences by organizing and annotating them, choosing appropriate charts and graphs, adding a corporate logo, and arranging it all with appropriate explanations and labeling.

TeamQuest tools support Availability Management by:

·         Gathering historical and real-time data on service performance

·         Providing the performance data required to make informed decisions regarding IT's ability to meet SLAs

·         Allowing you to experiment with multiple scenarios to determine resources needed to meet business unit goals

·         Determining the cause of outages

·         Preventing availability problems from recurring

·         Proactively identifying potential availability issues so they can be resolved before they impact users

·         Tracking and reporting availability metrics on an ongoing basis

6. SERVICE LEVEL MANAGEMENT

Is the process by which the quality of the IT services offered is defined, negotiated and supervised. Is responsible for finding a realistic compromise between the customers' needs and expectations and the costs of associated services, such that these are acceptable to both the customer and to the IT organisation.

Service Level Management must:

·         Document all the IT services offered.

·         Present the services in a way that is comprehensible to the customer.

·         Focus on the customer and the customer's business and not the technology.

·         Work closely with the customer to propose realistic IT services that match the customer's needs.

·         Establish the necessary agreements with customers and suppliers in order to offer the services required.

·         Define the key IT service performance indicators.

·         Monitor the quality of the agreed services with the overall goal of improving them at a cost acceptable to the customer.

·         Prepare reports on the quality of service and service improvement plans (SIP).

The main benefits of good Service Level Management are:

·         The IT services are designed with the real goal in mind: meeting the customer's needs.

·         Communication with customers is enhanced and misunderstanding about the characteristics and quality of the services offered are avoided.

·         Clear and measurable objectives are set.

·         The respective responsibilities of the customer and the service providers are clearly established.

·         Customers know and accept the quality levels offered and clear protocols of action are put in place which can be used to tackle any deterioration in service.

·         The constant monitoring of the service allows the weakest links in the chain to be identified so they can be improved.

·         IT management knows and understands the services offered, facilitating agreements with suppliers and subcontractors.

·         The Service Desk personnel has the necessary documentation (SLAs, OLAs,etc.) to enable fluid dealings with customers and suppliers.

·         The SLAs help IT management to calculate costs and justify prices to customers.

In the long term this results in improved service and the resulting satisfaction of customers and users.

The main difficulties when implementing Service Level Management may be summarised as:

·         A lack of good communications with customers and users, which means the SLAsagreed do not meet their real needs.

·         The service level agreements are based more on the customer's wishes and expectations than on services that the IT infrastructure can offer with an adequate level of quality.

·         IT services are not properly aligned with the customer's business processes.

·         The SLAs are excessively long and technical, thus failing to fulfil their primary objective.

·         Insufficient resources are dedicated to service level management as the management views it an extra cost and not an integral part of the service offered.

·         Communication problems: not all the users know about the characteristics of the service and the levels of quality agreed.

·         Compliance with SLAs is not monitored adequately or consistently, making it difficult to improve the quality of service.

·         There is no genuine commitment in the organisation to the quality of the IT service offered.