ITIL SERVİCE STRATEGY
ITIL Service Strategy is to decide on a strategy to serve customers. Starting from an
assessment of customer needs and the market place, the Service Strategy
lifecycle stage determines which services the IT organization is to offer and
what capabilities need to be developed. Its ultimate goal is to make the IT
organization think and act in a strategic manner.
Service
Strategy determines which types of services should be offered to which
customers or markets.
As per ITIL
2011, the following main processes are part of the ITIL
stage Service Strategy:
Processes
Itil Service Strategy
1)Strategy Management for IT Services
a)Objective
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, ITIL Strategy Management is also responsible for ensuring the
implementation of the strategy.
b)Sub Process
These are the Strategy
Management for IT Services sub-processes and their process objectives:
1)Strategic Service Assessment
To assess the present situation of
the service provider within its current market spaces. This includes an
assessment of current service offerings, customer needs and competing offers
from other service providers.
2)Service Strategy Definition
To
define the overall goals the service provider should pursue in its development,
and to identify what services will be offered to what customers or customer
segments, based on the results of the Strategic Service Assessment.
3)Service
Strategy Execution
To define and plan strategic initiatives, and ensure the implementation
of those initiatives.
c-)Definitions
The following ITIL terms and
acronyms are used in Strategy Management for IT Services to represent
process outputs and inputs:
1-)Business Planning Information
Business Planning Information includes
important input from clients and external service providers, especially for
devising the Service Strategy and looking for ways to improve services.
This input will highlight, for example, planned business initiatives like the
introduction of new product/ service offerings or the expansion into new
markets, as well as information on the future development of business activity,
especially expected increases in business transaction volumes. This information
helps the service organization understand the businesses it serves and their
plans for the future, allowing it to offer and develop the right set of services.
2-)Service Strategy Plan
The Service Strategy Plan (at times referred
to as the Service Strategy) is about translating a big idea regarding
customer needs into a distinctive and cost-effective set of connected
capabilities and resources to satisfy those needs.
3-)Strategic Action Plan
The Strategic Action Plan sets out the steps
required to implement the previously defined Service Strategy , defining
specific tasks and responsibilities.
4-)Strategic Service Assessment
The Service Strategy Assessment is
used to gain insight into a service provider's weaknesses, strengths and
opportunities prior to developing a Service Strategy.
d-)Roles Responsibilities
1-)Service Strategy Manager - Process Owner
The Service Strategy Manager supports
the IT Steering Group in producing and maintaining the service provider's
strategy. This role is also responsible for communicating and implementing the
service strategy.
2-)IT Steering Group (ISG)
The IT Steering Group (ISG) sets the
direction and strategy for IT Services. It includes members of senior
management from business and IT. The IT Steering Group reviews the business and
IT strategies in order to make sure that they are aligned. It also sets
priorities of service development programs/ projects.
2-)Service Portfolio Management
a-)Objective
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.
b-)Sub Process
These are the ITIL Service Portfolio
Management sub-processes and their process objectives:
1-)Define and Analyze new or changed Services
Process Objective: To define the desired outcomes of a proposed new or
changed service, analyze the impacts on existing services in the Service
Portfolio, and determine the assets required to offer the service.
2-)Approve new or changed Services
Process Objective: To submit a formal Change Proposal to Change
Management, and to initiate the design stage for the new or changed service if
the Change Proposal is authorized.
3-)Service Portfolio Review
Process Objective: To assess the Service Portfolio at regular
intervals in order to ensure the service provider offers economically viable
services which are aligned with the Service Strategy. This process also keeps
the Service Portfolio up to date.
c-)Definitions
The following
ITIL terms and acronyms are used in the Service Portfolio Management process to
represent process outputs and inputs:
1-)Change Proposal
Change
Proposal describes a proposed major Change, like the introduction of a new
service or a substantial change to an existing service. The purpose of Change
Proposals is to communicate a proposed major Change and assess its risk, impact
and feasibility before design activities begin. Change Proposals are typically
created in Service Portfolio Management.
2-)Service Charter
The Service
Charter is a high-level description of a new or substantially changed service
and the approach to build that service. In particular, the Service Charter
outlines the deliverables to be created during the service implementation
project, the required resources, and an initial project schedule. Service
Charters are passed to Service Design to initiate the detailed design of the
new or changed service. (Note: New output in ITIL 2011.)
3-)Service Model
Service Model
is a high-level description of a service and the components required to deliver
that service. The main purpose of Service Models is to facilitate an
understanding of what service components, assets and other resources are
necessary to create the service, including their interactions. Service Models
are a valuable tool for understanding the impact of proposed new or changed services
on other services at an early stage.
4-)Service Portfolio
The Service
Portfolio represents a complete list of the services managed by a service
provider; some of these services are visible to the customers, while others are
not. It contains present contractual commitments, new service development, and
ongoing service improvement plans initiated by Continual Service Improvement.
It also includes third-party services which are an integral part of service
offerings to customers. The Service Portfolio is divided into three phases:
Service Pipeline, Service Catalogue, and Retired Services.
5-)Service Portfolio Review Report
A document
containing the results and findings from a Service Portfolio. This report is an
important input to the strategic service assessment.
d-)Roles | Responsibilities
1-)Service Portfolio Manager - Process Owner
The Service Portfolio Manager
decides on a strategy to serve customers in cooperation with the IT Steering
Group, and develops the service provider's offerings and capabilities.
2-)IT Steering Group (ISG)
The IT Steering Group (ISG) sets
the direction and strategy for IT Services. It includes members of senior
management from business and IT. The IT Steering Group reviews the business and
IT strategies in order to make sure that they are aligned. It also sets
priorities of service development programs/ projects.
3-)Financial Management for IT Services
a-)Objective:
Manage the service provider's budgeting,
accounting and charging requirements.
b-)Sub Process
These are the ITIL Financial
Management sub-processes and their process objectives:
1-)Financial
Management Support
To define the necessary structures for the
management of
financial planning data and costs, as well as for the
allocation of cost to services.
2-)Financial
Planning
To determine the
required financial resources over the next planning period and to allocate those resources for
optimum benefits.
3-)Financial
Analysis and Reporting
To analyze the
structure of service provisioning cost and the profitability of services. The
resulting financial analysis allows Service Portfolio Management
to make informed decisions when deciding about changes to the Service Portfolio.
4-)Service
Invoicing
To issue invonces for the provision
of services and transmission of the invoice to the customer.
c-)Definitions
The following ITIL terms (information objects) are used
in Financial Management for IT Services to represent process outputs and
inputs:
1-)Budget Request
A request for a budget, typically issued from
any of the Service Management processes at the same time when compiling Request for Change. An approved Budget Request means that the required financial resources
for implementing a Change are approved by Financial Management.
2-)Budget Allocation
A budget allocated by the Financial Manager to implement a
Change. Budget Allocations are issued in response to Budget Requests
originating from any Service Management process in conjunction with Requests
for Change.
3-)Cost Data for Service Provisioning
The cost for providing a service, calculated
by Financial Management as a basis for calculating the price a customer is
expected to pay for a service.
4-)Financial Analysis
The
Financial Analysis is an important input to the Portfilo Process Management. It
contains information on the costs for providing services and provides insight
into the profitability of services and customers.
5-)Financial Data Categories
Various categories are used to structure
financial data, as a means to gain insight into the underlying cost of service and service
profitability.
6-)Indirect Cost Allocation Table
A table used to allocate indirect costs that
are shared among multiple services, defining the rules how those costs are
spread among the services.
7-)Invoice
The invoice for the delivery of a service or
product.
8-)IT Budget
The IT Budget is an annual financial plan
that provides a forecast of expected expenditures and allocates financial
resources to the various service management processes and organizational units
within the IT organization.
d-)Roles Responsiblities
1-)Financial Manager - Process Owner
The Financial Manager is responsible for
managing an IT service provider's budgeting, accounting and charging
requirements.
4-)Demand Management
a-)Objective:
Aims 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.
b-)Sub Process
No sub-processes are specified for ITIL
Demand Management.
c-)Definitions
The following Itil Terms and
Syncroms (information objects) are used in the ITIL Demand Management
process to represent process outputs and inputs:
1-)Pattern of Business Activity (PBA)
Patterns of Business Activity (PBA) are
workload profiles describing the demand for particular services. PBAs are an
important tool used by Demand Management for anticipating and influencing
service demand.
d-)Roles and
Responsibilities
1-)Demand Manager - Process Owner
The Demand Manager is responsible for understanding,
anticipating and influencing customer demand for services. The Demand Manager
works with capacity management to ensure that the service provider has
sufficient capacity to meet the required demand.
5-)Business Relationship Management
a-)Objective
Business Relationship Management has been
introduced as a new process in ITIL 2011.
The latest guidance places customer satisfaction surveys and the
management of complaints with in Business Relationship Management. As a result,
the corresponding processes have been moved from Continual Service Improvement
to Business Relationship Management. The process overview of Itil Business Relationship
Management.
b-)Sub Process
These are
the Business Relationship Management sub-processes and their process
objectives:
1-)Maintain Customer Relationships
Process Objective: To ensure that the
service provider continues to understand the needs of existing customers and
establishes relationships with potential new customers. This process is also
responsible for maintaining the Customer Portfolio.
2-)Identify Service Requirements
Process Objective: To understand and
document the desired outcome of a service and to decide if the customer's
need can be fulfilled using an existing service offering or if a new or changed
service must be created.
3-)Sign up Customers to Standard Services
Process Objective: To capture customer
requirements and agree service level targets with customers who request the
provision of existing standard services (no modifications to existing
Supporting Services are necessary in order to fulfill the customer's needs).
4-)Customer Satisfaction Survey
Process Objective: To plan, carry out and
evaluate regular customer satisfaction surveys The principal aim of this
process is to learn about areas where customer expectations are not being met
before customers are lost to alternative service providers.
5-)Handle Customer Complaints
Process Objective: To record
customer complaints and compliments, to assess the complaints and to
instigate corrective action if required.
6-)Monitor Customer Complaints
Process Objective: To continuously monitor
the processing status of outstanding customer complaints and to take
corrective action if required.
c-)Definitions
The following Itil Terms (information
objects) are used in the ITIL Business Relationship Management process to
represent process outputs and inputs:
1-)Complaint Status Information
A message containing the present status of a
complaint, typically sent to a customer who earlier made a complaint.
2-)Complaints and Compliments
Complaints and compliments from the customer
side which are addressed in the Business Relationship Management process.
3-)Complaints Log
The Complaints Log contains the full history
of all received customer complaints, complete with activities triggered by
those complaints.
4-)Customer Portfolio
The Customer
Portfolio is used to record all customers of the IT service provider. The Customer Portfolio is the Business Relationship
Manager’s view of the customers who receive services from the IT service
provider.
5-)Customer Survey Questionnaire
A questionnaire for surveying
customer satisfaction aimed at getting insight into overall customer
satisfaction and customers' views on specific (aspects of) services.
6-)Customer Survey Response
The response to a service
provider's customer survey, typically a completed questionnaire.
7-)Desired Service Outcomes
The desired outcomes of a service,
stated in the language of the customer. Based on this information, more
detailed documents are created to specify the requirements in the service
provider's language.
8-)Outline of Service Requirements
The desired outcome of a service,
stated in terms of required service functionality (utility) and service levels
(warranty). Based on this information, detailed service requirements are
specified during the Service Design stage.
ITIL SERVİCE TRANSITION
The goals of service transition:
·
“Aligning the new or changed service
with the organisational requirements and organisational operations”
·
Plan
and manage the capacity and resources required to package, build, test and
deploy a release into production
·
Provide
a consistent and rigorous framework for evaluating the service capability and
risk profile before a new or changed service is released
·
Establish
and maintain the integrity of all identified service assets and configurations
·
Provide
good quality knowledge and information to expedite effective decisions about
promoting a release
·
Provide
efficient, repeatable build and installation mechanisms to deploy releases to
test and production
·
Ensure
that the service can be managed, operated and supported in accordance with
service design
Other
objectives include:
·
Align
the new or changed service with the organisation requirements and business
operations
·
Ensure
that customers/users can use the new or changed service in a way that maximises
value to the organisation operations
·
Plan
and manage resources so that transitions come in on time, cost and quality
·
Ensure
minimum impact on current services
·
Increase
customer, user and service support satisfaction
Value to the organisation/business of
service transition
Creates
value for the business by improving:
·
The
ability to adapt quickly to new requirements
·
The
success rate of changes and releases for the organisation
·
The
predictions of service levels and warranties for new and changed services
·
Confidence
in the degree of compliance with the organisation requirements during change
·
Clarity
of plans so the business can link their organisation change plans to transition
plans
All the above give competitive edge and
help the agility and flexibility and the organisation.
The scope of service transition
The
scope of service transition includes the management and coordination of the
processes, systems and functions to package, build, test and deploy a release
into production and establish the service specified in the customer and
stakeholder requirements
The
following activities are excluded from the scope of service transition best
practices:
·
Minor
modifications to the production services and environment, for example,
replacement of a failed PC or printer, installation of standard software on a
PC or server, new user
·
Ongoing
continual service improvements that do not significantly impact the services or
service provider’s capability to deliver the services, for example, request
fulfilment activities driven from service operations
Service transition processes
·
Knowledge
management
·
Change
management
·
Release
and deployment management
·
IT
service asset and configuration management
·
Service
validation and testing
Knowledge management
Why have knowledge management?
An
organisations ability to deliver a quality service or process rests, to a significant
extent, on its ability to respond to circumstances. To enable this to happen,
those involved must have a sound understanding of the situation, the options,
consequences and benefits. An example of this knowledge in the service
transition phase may include:
·
Identity
of stakeholders
·
Acceptable
risk levels and performance expectations
·
Available
resource and timescales
The
quality and relevance of the knowledge rests in turn on the accessibility,
quality and continued relevance of the underpinning data and information
available to service staff.
The objectives of knowledge management
“The goal of knowledge management is to
enable organisations to improve the quality of management decision-making by
ensuring that reliable and secure information and data is available throughout
the service lifecycle”
The
primary purpose is to improve efficiency by reducing the need to rediscover
knowledge.
This
is achieved by:
·
Enabling
the service provider to be more efficient and improve the quality of the
service, reduce costs, increase satisfaction
·
Ensuring
staff have a clear and shared understanding of the value that their services
provide to customers and how they are realised
·
Ensuring
that, as required, service provider staff have adequate information on
o
Who
is currently using the service they are providing
o
The
current states of consumption
o
Service
delivery constraints
o
Difficulties
faced by customers, realising the expected benefits from services
The
above diagram is a very simplified illustration of the relationship of the
three levels, with data being gathered within the CMDB, and feeding through the
CMS into the SKMS as information to support the informed decision making
process.
Value to the organisation of knowledge
management
Knowledge
management is especially significant within service transition since relevant
and appropriate knowledge is one of the key service elements being
transitioned. Examples where successful transition rests on appropriate
knowledge management include:
·
User,
service desk, support staff and supplier understanding of the new or changed
service, including knowledge of errors signed off before deployment, to
facilitate their roles within that service
·
Awareness
of the use of the service, and the discontinuation of previous versions
·
Establishment
of the acceptable risk and confidence levels associated with the transition,
e.g. measuring, understanding and acting correctly on results of testing and
other assurance results
Effective
knowledge management is a powerful asset for people in all roles across all
stages of the service lifecycle. It is an excellent method for individuals and
teams to share data, information and knowledge about all facets of an IT
service. The creation of a single system for knowledge management is
recommended.
The activities of knowledge management
Knowledge identification capture and
maintenance – Specifically knowledge
management will identify and plan for the capture of relevant knowledge and the
consequential information and data that will support it.
Knowledge transfer – This is the activity through which one unit (e.g.
group or department) is affected by the experiences of another. The form of
knowledge transfer must suit those who will use it, examples of
criteria/examples that can be used are:
·
Learning
styles
·
Knowledge
visualisation
·
Driving
behaviour
·
Seminars,
webinars and advertising
·
Journals
and newsletters
The
transfer of knowledge can be observed through changes in the knowledge or
performance or recipients, and at an individual or unit level.
Data and information management – Knowledge rests on the management of the
information and data that underpins it. For this process to be efficient it
requires answers to some key input questions, such as how the data and
information will be used, what conditions will need to be monitored, what data
is available, what are the associated costs, legislative and requirements etc.
Establishing data and information
requirements – Often, data and
information is collected with no clear understanding of how it will be used and
this can be costly. Efficiency and effectiveness are delivered by establishing
the requirements for information.
Establishing data and information
management procedures – When the
requirements have been set up, data and information management to support
knowledge management can be established. This will include, defining procedures
required to maintain the data and information, procedures for access, storage
(including backup and recovery), retrieval, rights and responsibilities etc.
Evaluation and improvement – As with all processes, the capture and use of data
and information to support knowledge management and decision making requires
attention to ongoing improvement.
The
service improvement plan, produced by the Service Level Manager, will use the
following relevant input:
·
Measurements
of the use made of the data transactions
·
Evaluate
usefulness of the data and information
·
Identification
of any data or information (or registered users) that is no longer to the
organisation’s knowledge requirements
The terminology of knowledge management
SKMS: Service Knowledge Management System
CMS: Configuration Management System
KEDB: Known Error Database
DML: Definitive Media Library. The secure library in which the definitive
authorised versions of all media CIs are stored and protected. The DML should
include definitive copies of purchased software (along with license documents
or information), as well as software developed on site
Change management
Why have change management?
Change
is inevitable, and the rate of change in technology is increasing and the
organisation’s processes and business models constantly have to adapt to the
economic climate, competitive pressures, and the opportunity to create through
change and innovation. Change management, as a discipline in distributed
computing is usually somewhat lacking. Yet, change management for IT operations
is critical to improving availability, performance and throughput. Strong
operational change management reduces errors, as well as planned and unplanned
downtime.
Changes
arise for a variety of reasons:
·
Proactively,
e.g. seeking organisational benefits such as reducing costs or improving
services or increasing the ease and effectiveness of support
·
Reactively
as a means of resolving errors and adapting to changing circumstances
Changes
should be managed to:
·
Optimise
risk exposure (supporting the risk profile required by the organisation)
·
Minimise
the severity of any impact and disruption
·
Be
successful at the first attempt
Such
an approach will deliver direct financial benefit for the organisation by
delivering early realisation of benefits (or removal of risk), with a saving of
money and time.
To
make an appropriate response to all requests for change entails a considered
approach to assessment of risk and business continuity, change impact, resource
requirements, change authorisation and especially to the realisable
organisation benefit. This considered approach is essential to maintain the
required balance between the need for change and the impact of the change.
The objectives of change management
The
goal of the change management process is to ensure that standardised methods
and procedures are used for efficient and prompt handling of all changes, in
order to minimise the impact of change related Incidents upon service quality,
and consequently to improve the day to day operations of the organisation.
Other
objectives include:
·
Respond
to changing business requirements
·
Minimise
impact/risk of implementing changes
·
Ensure
all changes are approved at the appropriate level with the business and IT
·
Implement
changes successfully
·
Implement
changes in times that meet business needs
·
Use
standard processes to record all changes
Not every change is an improvement, but
every improvement is a change!
The scope of change management
Addition,
modification or removal of:
·
Any
service or configuration Item or associated documentation Including
·
Strategic,
tactical and operational changes Excluding
·
Business
strategy and process
·
Anything
documented as out of scope
The activities of change management
Activities
undertaken will involve:
·
Change
logging and filtering/acceptance
o
Does
the RFC (request for change) have enough, quality, information
o
Unique
identification number
o
Filter
out impractical RFCs and provide feedback to issuer
·
Managing
changes and the change process
o
Prioritise
RFCs (based on risk assessment)
o
Categorise
RFCs (e.g. minor, significant or major impact)
·
Chairing
the CAB (Change Advisory Board) and the ECAB (Emergency Change Advisory Board)
o
Assess
all RFCs (but not all during the meeting!! CAB is a consulting body)
o
Impact
and resource assessment
o
Approval
based on financial, business and technical criteria
o
The
Forward Schedule of Change (FSC)
·
Coordinate
the change
o
Supported
by release management, change management coordinates the building, testing and
implementation of the change
·
Reviewing
and closing RFCs
·
Management
reporting
Emergency
changes follow the same steps, but usually in a different order. The ECAB
approves an emergency change immediately and the building, testing and
implementation are done before the paperwork, which is usually completed
retrospectively, but don’t forget the documentation!
The Change Process
The value to the organisation of change
management
·
Prioritising
and responding to organisation and customer/user change proposals
·
Implementing
changes that meet the customers’ agreed service requirements while optimising
costs
·
Contributing
to meet governance, legal, contractual and regulatory requirements
·
Reducing
failed changes and therefore service disruption, defects and rework
·
Delivering
change promptly to meet business timescales
·
Tracking
changes through the service lifecycle
·
Contributing
to better estimations of the quality, time and cost of change
·
Assessing
the risks associated with the transition of services
·
Aiding
productivity of staff through minimising disruptions due to high levels of
unplanned or emergency change and hence maximising service availability
·
Reducing
the Mean Time to Restore Service (MTRS), via quicker and more successful
implementations of corrective changes
The terminology of change management
Normal change
A change that follows all of the steps of
the change process.
Standard change
A pre-approved change that is low risk,
relatively common and follows a procedure or work instruction, e.g. password
reset or provision of standard equipment to a new employee. RFC’s are not
required to implement a standard change, and they are logged and tracked using
a different mechanism, such as a service request.
Emergency change
A change that must be introduced as soon as
possible. e.g. to resolve a major incident or implement a security patch. The
change management process will normally have a specific procedure for handling
emergency changes.
Requests for change
Every change to the IT Infrastructure has to
go through change management. A Request for Change (RFC) is formally issued for
every change request.
The Change Manager
Responsible for the change management
process.
Change Advisory Board (CAB)
A dynamic group of people (depending on the
change) that approve changes with medium to high priority, risk and impact.
CAB/EC
CAB Emergency Committee approves and
authorises changes with high urgency, risk and impact.
Change models
Some organisations use change models prior
to implementation to estimate the impact of the change. Change management and
capacity management work together on this.
FSC
The Forward Schedule of Change (FSC)
contains details of all approved changes and their proposed implementation
date.
Release and deployment management
Why have release and deployment
management
The goal of release and deployment
management is to deploy releases into production and enable effective use of
the service in order to deliver value to the organisation/customer/user.
The objectives of release and deployment
management
The objective of release and deployment
management is to build, test and deliver the capability to provide the services
specified by service design. This includes the processes, systems and functions
to package, build, test and deploy a release into production and prepare for
service operation.
Other
objectives include:
·
To
provide clear and comprehensive plans enabling change projects to align their
activities
·
To
ensure that the hardware and software being changed is traceable, secure and
that only correct, authorised and tested versions are installed
·
To
ensure that master copies of all software are secured in the Definitive Media
Library (DML)
·
To
ensure that release packages are built, installed, tested and deployed
efficiently
·
To
ensure that skills and knowledge are transferred to operations and support
staff
·
To
ensure that new or changed services meet the utility, warranty and service
levels
·
Minimise
unpredicted impact
·
To
communicate and manage expectations of the customer during the planning and
rollout of new releases
The scope of release and deployment
management
The scope of release and deployment
management includes the processes, systems and functions to package, build, and
test and deploy a release into production and establish the service specified
in the service design package before final handover to service operations.
The value to the organisation of release
and deployment management
Effective release and deployment management
enables the service provider to add value to the organisation by:
·
Delivering
change, faster and at optimum cost and minimised risk
·
Assuring
that customers and users can use the new or changed service in a way that
supports the organisation goals
·
Improving
consistency in implementation approach across the organisation change, service
teams, suppliers and customers
Release and deployment management
activities
·
Release
policy and planning
·
Release
design, build and configuration
·
Release
testing and acceptance
·
Deployment
and planning
·
Extensive
testing to predefined acceptance criteria
·
Sign
off of the release for implementation
·
Communication,
preparation and training
·
Audits
of hardware and software prior to and following the implementation of changes
·
Installation
of new or upgraded hardware
·
Storage
of controlled software in both centralised and distributed systems
·
Release,
deployment and the installation of software
Release units
A release unit describes the portion of a
service or IT infrastructure that is normally released together according to
the organisation’s release policy. The unit may vary, depending on the type(s)
or item(s) of service asset or service component, such as software and
hardware.
The
objective is to decide the most appropriate release unit level for each service
asset or component. An organisation may, for example, decide that the release
unit for critical applications is the complete application in order to ensure
that testing is comprehensive. The same organisation may decide that a more
appropriate release unit for a website is at the page level.
The
following factors should be taken into account when deciding the appropriate
level for release units:
·
„The ease and amount of change necessary to release and deploy a release
unit
·
The
amount of resources and time needed to build, test, distribute and implement a
release unit
·
The
complexity of interfaces between the proposed unit and the rest of the services
and IT infrastructure
Release and deployment options
Big bang – The new or changed service is deployed to all user
areas in one operation. This will often be used when introducing an application
change and consistency of service across the organisation is considered
important.
Phased – The service is deployed to a part of the user base
initially, and then this operation is repeated for subsequent parts of the user
base via a scheduled rollout plan.
Push – Is used where the service component is deployed from the centre and
pushed out to the target locations
Pull – Used for software releases, where the software is made available in a
central location, but users are free to pull the software down to their own
location at a time of their choosing or when a workstation restarts.
Automation – Helps to ensure repeatability and consistency. The
time required to provide a well designed and efficient automated mechanism may
not always be available or viable.
Manual – Important to monitor and measure the impact of many
repeated manual activities, as they are likely to be inefficient and error
prone.
The terminology of release and
deployment management
Release – A collection of authorised changes to an IT service.
Release unit – The portion of the IT infrastructure that is released
together, e.g. major release: major roll out of new hardware and/or software;
minor release: a few minor improvements and fixes to known errors. Emergency
fix: a temporary or permanent quick fix for a problem or known error
Definitive Spares (DS) – (previously known as DHS) Physical storage of all spare
IT components and assemblies maintained at the same level as within the live
environment. These can then be used when needed for additional systems or in
the recovery from incidents (details are recorded in the CMDB, controlled by
release management).
Definitive Media Library (DML) – (previously known as the DSL) the secure library in
which the definitive authorised versions of all media CIs are stored and
protected. The DML should include definitive copies of purchased software
(along with license documents or information) as well as software developed on
site.
CMDB – Configuration Management Database.
Service asset and configuration
management
Why have service asset and configuration
management
This process ensures the integrity of
service assets and configurations in order to support the effective and
efficient management of the IT organisation.
The
main reason for configuration management is to gather the information needed
(in a non-duplicated manner) about the IT components and how they relate to
each other. The reason for this is to ensure that the relevant information is
available for all the other processes to ensure that detailed impact and risk
analysis can take place.
The objectives of service asset and
configuration management
·
Account
for all the IT assets and configurations within the organisation and its
services
·
Provide
accurate information on configurations and their documentation to support all
the other service management processes
·
Provide
a sound basis for incident management, problem management, change management
and release management
·
Verify
the configuration records against the infrastructure and correct any exceptions
·
Plan,
identify, control, record, report, audit and verify service assets and
configuration items
·
Account
for manage and protect the integrity of service assets and configuration items
throughout their lifecycle
·
Provide
accurate information to support business and service management
·
Ensure
the integrity of those items by creating and maintaining an accurate Configuration
Management System (CMS) as part of the Service knowledge management System
(SKMS)
The value to the organisation of service
asset and configuration management
Optimising the performance of service assets
and configurations improves the overall service performance and optimises the
costs and risks caused by poorly managed assets, e.g. service outages, fines,
correct licence fees and failed audits. SACM provides visibility of accurate
representations of a service, release or environment that enables:
·
Better
forecasting and planning of changes
·
Changes
and releases to be assessed, planned and delivered successfully
·
Incidents
and problems to be resolved within the service level targets
·
Service
levels and warranties to be delivered
·
Better
adherence to standards, legal and regulatory obligations
·
More
business opportunities as able to demonstrate control of assets and services
·
Changes
to be traceable from requirements
The activities of service assets and
configuration management
Configuration management planning
A
configuration management plan should define:
·
The
purpose, scope and objectives of configuration management
·
Related
policies, standards and processes that are specific to the support group
·
Configuration
Management roles and responsibilities
·
CI
(Configuration Item) naming conventions
·
The
schedule and procedures for performing Configuration Management activities:
configuration identification, control, status accounting, configuration audit
and verification
·
Interface
control with third parties, e.g. Change Management, suppliers
·
Configuration
management systems design, including scope and key interfaces
Configuration identification
·
CIs
are the components used to deliver a service. The CIs include software,
documentation and SLA’s
·
Also
identify the relationship between CI’s and the attributes for every CI
Control of CI’s
The objective of configuration control is to
ensure that only authorized and identifiable CI’s are recorded in the CMDB upon
receipt.
Configuration status accounting
·
Status
reports should be produced on a regular basis, listing, for all CI’s under
control, their current version and change history. Status accounting reports on
the current, previous and planned states of the CI’s should include:
o
Unique
identifiers of constituent CI’s and their current status, e.g. under
development, under test, live
o
Configuration
baselines, releases and their status
o
Latest
software item versions and their status for a system baseline/application
o
The
person responsible for status change, e.g. from under test to live
o
Change
history/audit trail
o
Open
problems/RFC’s
Configuration verification and audit
·
Service
desk staff, while registering incidents, can do daily verification
·
Configuration
audits should be considered at the following times:
o
Shortly
after implementation of a new configuration management system
o
Before
and after major changes to the IT infrastructure
o
Before
a software release or installation to ensure that the environment is as
expected
o
Following
recovery from disasters and after a return to normal (this audit should be
included in contingency plans)
At random intervals
·
In
response to the detection of any unauthorised CI’s
·
At
regular intervals
Configuration Management Database (CMDB)
·
Backup,
administration, housekeeping
Service validation and testing
Why have service validation and testing?
The goal of service validation and testing
is to assure that a service will provide value to organisation.
The
underlying concept to which service validation contributes is quality assurance
– establishing that the service design and release will deliver a new or
changed service or service offering that is fit for the purpose and fit for
use. Testing is a vital area within service management and has often been the
unseen underlying cause of what was taken to be inefficient service management
processes.
If
services are not tested sufficiently then their introduction into the
operational environment will bring rise in:
·
Incidents
– failures in service elements and mismatches between what was wanted and what
was delivered impact on business support
·
Service
desk calls for assistance – services that are not functioning as intended are
inherently less intuitive causing higher support requirements
·
Problems
and errors – that are harder to diagnose in the live environment
·
Costs
– since errors are more expensive to fix in production than if found in testing
·
Services
– that are not used effectively by the users to deliver the desired value
The objectives of service validation and
testing
The objectives are:
·
Provide
confidence that a release will create a new or changed service or service
offerings that deliver the expected outcomes and value for the customers within
the projected costs, capacity and constraints
·
Validate
that a service is fit for purpose – it will deliver the required performance
with desired constraints removed
·
Assure
a service is fit for use – it meets certain specifications under the specified
terms and conditions of use
·
Confirm
that the customer and stakeholder requirements for the new or changed service
are correctly defined, and remedy any errors or variances early in the service
lifecycle as this is considerably cheaper than fixing errors in production
The value to the organisation of service
validation and testing
Service failures can harm the organisation
and can result in outcomes such as:
·
loss
of reputation
·
loss
of Money
·
loss
of time
The key value to the business and customers
from service testing and validation is in terms of the established degree of
confidence that a new or changed service will deliver the value and outcomes
required of it and understanding the risks. Successful testing depends on all
parties understanding that it cannot give, indeed should not give, any
guarantees but provides a measured degree of confidence. The required degree of
confidence varies depending on the customer’s business requirements and
pressures of an organisation.
The V model
The V Model concept of
establishing acceptance requirements against the requirements and design can
apply, with each iterative design being considered for the degree of integrity
and competence that would justify
release to the customer for trail and assessment.
The left
hand side represents the specification of the service requirements down to
the detailed service design.
The right
hand side focuses on the validation and test activities that are performed
against the specifications defined on the left hand side, there is direct
involvement by the equivalent party on the right hand side.
It
shows that service validation and acceptance test planning should start with
the definition of service requirements, e.g. customers who sign off the agreed
service requirements will also sign off the service acceptance criteria and
test plan.
The terminology of service validation
and testing
Validation
The
activity that ensures a new or changed IT service, process, plan or other
deliverable meets the needs of the business. Validation ensures that business
requirements are met even though these may have changed since the original
design phase.
Acceptance
Formal
agreement that an IT service, process, plan or other deliverable is complete,
accurate reliable and meets its specified requirements. Acceptance is usually
preceded by evaluation or testing and is often required before proceeding to
the next stage of a project or process.
Test
The
activity that verifies that a CI, IT service, process etc., meets its
specification or agreed requirements.
Evaluation
Responsible
for assessing a new or changes IT service to ensure that risks have been
managed and to help determine whether to proceed with the change.
Fit for purpose
Describes
whether the process, CI, IT service etc., is capable of meeting its objectives
or service levels.
Fit for use
Meets
certain specifications under the specified terms and conditions of use.
ITIL SERVICE OPERATİON
Operation is where service value is realized. This view handles a service
after it has been deployed and is active to the customer. It is mainly about
handling user requests, fixing services carrying operation problem tasks.
This volume has following processes:
·
Event Management
·
Incident Management
·
Request Fulfilment
·
Access Management
·
Problem Management
·
IT Operations Management
·
IT Facilities Management
Service
Operation Principles
·
Internal view x external view: internal IT
view is the way components are managed to deliver a service. External business
view is the way a client sees a service. There is an eternal conflict between
this two views in a company and there is a need to try to achieve a balance
between them.
·
Stability x responsiveness: no matter how
a good service is provided, there will be always a need to change something.
Considering that every change is a potential risk in service stability, a
change would not be good. But business needs changes, and they are going to
happen anyway. Balance here is to change services without losing stability.
These changes may be at several levels, as technology, capacity management,
grow strategy, problems experienced.
·
Quality of service x cost of service
·
Reactive x proactive: management
that is solely reactive is not effective, but management that is overly
proactive is not effective either. When staff are too proactive, this may
result in increased expense and distracted staff.
Key terms
Some key terms
needed for Service Operations:
·
Event or Alert: a change
in state that has significance for management.
·
Incident: an unplanned interruption in
service or loss of quality.
·
Failure: a loss of ability to operate
service. Normally a failure results in an incident.
·
Error: a design malfunction that causes a
failure.
·
Problem: A cause of one or more Incidents.
The cause is not usually known at the time a Problem Record is created
·
Known error: a problem that has documented root
cause or a workaround.
·
Request For a Change (RFC): formal request
for a change to be made.
Processes
Event Management
Event or alert is any change in state
that may have implications in how service is perceived by
customer. These events are a signal that service has been interrupted or there
is a loss of quality. Since warranty is one of two axis for service quality,
this processes is one of most important of ITIL.
The
process works on filter and categorization of events and to decide on
appropriate actions.
Sub processes
are:
·
Maintenance of Event Monitoring Mechanisms
and Rules
·
Event Filtering and Categorization
·
Event Correlation and Response Selection
·
Event Review and Closure
Incident
Management
Objective of this process is to manage the
lifecycle of all Incidents. Incident Management ensures that normal service
operation is restored as quickly as possible and the business impact is
minimized.
Incident
management may be used to handling of failures, providing answers to users
questions/queries (usually by Helpdesk/Service Desk). It is questions or
queries made by users (many times by service desk). Its important to realize
that not all events are incidents.
When correction
of an incident by second level a Problem Record is created and the
error-correction transferred to Problem Management.
Subprocesses
are:
·
Incident Management Support
·
Incident Logging and Categorization
·
Immediate Incident Resolution by 1st Level
Support
·
Incident Resolution by 2nd Level Support
·
Handling of Major Incidents
·
Incident Closure and Evaluation
·
Incident Monitoring and Escalation
·
Pro-Active User Information
·
Incident Management Reporting
Request Fulfilment
Process Objective: To fulfil Service
Requests, which in most cases are minor (standard) Changes (e.g. requests to
change a password) or requests for information.
In ITIL 2011, Request Fulfilment has been
completely revised. To reflect the latest guidance Request Fulfilment now
consists of five sub-processes, to provide a detailed description of all
activities and decision points. Request Fulfilment now contains interfaces with
Incident Management - if a Service Request turns out to be an Incident and with
Service Transition - if fulfilling a Service Request requires the involvement
of Change Management.
The Sub-Processes are;
Request
Fulfilment Support Process Objective: To provide and maintain the tools, processes,
skills and rules for an effective and efficient handling of Service Requests.
Request Logging
and Categorization Process Objective: To record and categorize the Service Request with
appropriate diligence and check the requester's authorization to submit the
request, in order to facilitate a swift and effective processing.
Request Model
Execution Process Objective: To process a Service Request within the agreed
time schedule.
Request
Monitoring and Escalation Process Objective: To continuously
monitor the processing status of outstanding Service Requests, so that
counter-measures may be introduced as soon as possible if service levels are
likely to be breached.
Request Closure
and Evaluation Process Objective: To submit the Request Record to a final quality
control before it is closed. The aim is to make sure that the Service Request
is actually processed and that all information required to describe the
request's life-cycle is supplied in sufficient detail. In addition to this,
findings from the processing of the request are to be recorded for future use.
Access Management
Process
Objective: To grant authorized users the right to use a service, while
preventing access to non-authorized users. The Access Management processes
essentially executes policies defined in IT Security Management. Access
Management is sometimes also referred to as Rights Management or Identity
Management.
Problem Management
Process
Objective: To manage the lifecycle of all Problems. The primary objectives of
Problem Management are to prevent Incidents from happening, and to minimise the
impact of incidents that cannot be prevented. Proactive Problem Management
analyses Incident Records, and uses data collected by other IT Service
Management processes to identify trends or significant Problems.
IT Operations Management
Process
Objective: To monitor and control the IT services and IT infrastructure. The
process IT Operations Management executes day-to-day routine tasks related to
the operation of infrastructure components and applications. This includes job
scheduling, backup and restore activities, print and output management, and
routine maintenance.
IT Facilities
Management
Objective: The objective of ITIL Facilities
Management is to manage the physical environment where the IT infrastructure is
located. IT
Facilities
Management includes all aspects of managing the physical environment, for
example power and cooling, building access
management, and
environmental monitoring.
ITIL SERVİCE DESİGN
Service Design covers the fundamentals
of designing services and processes. It provides a holistic design
approach to help an organization deliver better services.
Designing a service to meet an organization’s strategic and customer
needs requires coordination and collaboration. Aim for high service
maturity when designing services rather than the completion of an IT project.
The higher the service maturity the higher customer and user satisfaction
will be.
The five key aspects of Service Design are:
1.
Designing the service solution
2.
Management information systems
and tools
3.
Technology
4.
Processes
5.
Measurements and metrics
Approach all aspects with service oriented thinking and
decision making.
As per ITIL 2011, the following main processes are part of the ITIL
stage Service Design:
Process
Objective: To coordinate all service design activities, processes and
resources. Design coordination ensures the consistent and effective design of
new or changed IT services, service management information systems,
architectures, technology, processes, information and metrics.
Process
Objective: To ensure that a Service Catalogue is produced and maintained,
containing accurate information on all operational services and those being prepared
to be run operationally. Service Catalogue Management provides vital
information for all other Service Management processes: Service details,
current status and the services' interdependencies.
Process
Objective: To negotiate Service Level Agreements with the customers and to
design services in accordance with the agreed service level targets. Service
Level Management is also responsible for ensuring that all Operational Level
Agreements and Underpinning Contracts are appropriate, and to monitor and
report on service levels.
Process
Objective: To identify, assess and control risks. This includes analyzing the
value of assets to the business, identifying threats to those assets, and
evaluating how vulnerable each asset is to those threats.
Process
Objective: To ensure that the capacity of IT services and the IT infrastructure
is able to deliver the agreed service level targets in a cost effective and
timely manner. Capacity Management considers all resources required to deliver
the IT service, and plans for short, medium and long term business
requirements.
Process
Objective: To define, analyze, plan, measure and improve all aspects of the
availability of IT services. Availability Management is responsible for
ensuring that all IT infrastructure, processes, tools, roles etc. are
appropriate for the agreed availability targets.
Process
Objective: To manage risks that could seriously impact IT services. ITSCM
ensures that the IT service provider can always provide minimum agreed Service
Levels, by reducing the risk from disaster events to an acceptable level and
planning for the recovery of IT services. ITSCM should be designed to support
Business Continuity Management.
Process
Objective: To ensure the confidentiality, integrity and availability of an
organization's information, data and IT services. Information Security
Management usually forms part of an organizational approach to security
management which has a wider scope than the IT Service Provider.
Process
Objective: To ensure IT services, processes and systems comply with enterprise
policies and legal requirements.
Process
Objective: To define a blueprint for the future development of the
technological landscape, taking into account the service strategy and newly
available technologies.
Process
Objective: To ensure that all contracts with suppliers support the needs of the
business, and that all suppliers meet their contractual commitments
Hiç yorum yok:
Yorum Gönder