1-What is ITIL?

The ITIL name is come from initials of Information Technology Infrastructure Library keyword. ITIL is fundamentally a group of best practices designed to align IT services and operations with the needs of business.ITIL was developed by the UK Office of Government and Commerce and nowadays it is owned by the Cabinet Office, and supported by publications.

ITIL has had several versions and is currently on version 2011. In the picture below you can see the evolution of ITIL versions.

ITIL History:

Some critics argue that ITIL 2011 is not a new version of ITIL V3 but rather and enhancement to this version.

As the graph that is above , we could see evolution of ITIL. The source of evolotion of ITIL is deficion of versions of lover level ITIL versions. So ITIL getting better than other versions. İf we exeminate the versions of ITIL;

Why adopt ITIL?

ITIL does not define every role, tool or process within your organization. ITIL describes what needs to be done but not how it should be done.

The main ITIL benefits can be resumed as :

competitive advantage not only from improved internal cost savings, but also from the improved availability of your IT services and systems.

high user base, and brand recognition

extensive certification program

If we explain ITIL version that is commonly used now namely ITIL V3 :

ITIL V3:

To use ITIL V3 you must first understand the stages of the service lifecycle:

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service Improvement

This picture below shows the relationship between these stages.

İf we try to explain serveces that we could see picture that is above :

Service Strategy

Service Strategy deals with the strategic management approach in respect of IT Service Management; strategic analysis, planning, positioning, and implementation relating to service models, strategies, and strategic objectives. It provides guidance on leveraging service management capabilities to effectively deliver value to customers and illustrate value for service providers.

Service Desing

Service Design translates strategic plans and objectives and creates the designs and specifications for execution through service transition and operations. It provides guidance on combining infrastructure, applications, systems, and processes, along with suppliers and partners, to present feasible service offerings.

Service Transition

Service Transition provides guidance on the service design and implementation, ensuring that the service delivers the intended strategy and that it can be operated and maintained effectively.

Service Operation

Service Operation provides guidance on the management of a service through its day-to-day production life. It also provides guidance on supporting operations by means of new models and architectures such as shared services, utility computing, web services, and mobile commerce.

Continual Service İmprovement

Continual Service Improvement provides guidance on the measurement of service performance through the service life-cycle, suggesting improvements to ensure that a service delivers the maximum benefit.

Now we investigate our lesson that we will expain deeply , İt is Service Transition :

2-Service Transation

We select Service Transition Module of ITIL for final project. And we draw graph of that.

What is Transition Service?

The Service Transition publication is part of the ITIL Service Management Practices, which document industry best practice for the service lifecycle management of IT enabled services.

The purpose of Service Transition is to:

Plan and manage the capacity and resources required to package, build, test and deploy a release into production and establish the service specified in the customer and stakeholder requirements
Provide a consistent and rigorous framework for evaluating the service capability and risk profile beforea new or changed service is released or deployed
Establish and maintain the integrity of all identified service assets and configurations as they evolve through the Service Transition stage
Provide good-quality knowledge and information so that change, Release and Deployment Management can expedite effective decisions about promoting a release through the test environments and into production
Provide efficient repeatable build and installation mechanisms that can be used to deploy releases to the test and production environments and be rebuilt if required to restore service
Ensure that the service can be managed, operated and supported in accordance with the requirements and constraints specified within the Service Design.

The goals of Service Transition are to:

Set customer expectations on how the performance and use of the new or changed service can be used to enable business change
Enable the business change project or customer to integrate a release into their business processes and services
Reduce variations in the predicted and actual performance of the transitioned services
Reduce the known errors and minimize the risks from transitioning the new or changed services into production
Ensure that the service can be used in accordance with the requirements and constraints specified within the service requirements.

The objectives are to:

Plan and manage the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates
Ensure there is minimal unpredicted impact on the production services, operations and support organization
Increase the customer, user and Service Management staff satisfaction with the Service Transition practices including deployment of the new or changed service, communications, release documentation, training and knowledge transfer
Increase proper use of the services and underlying applications and technology solutions
Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.

2.1-Knowledge Management

Knowledge Management identifies an organization’s key requirements and issues and provides a framework for addressing these. A central repository (the Service Knowledge Management System) makes it possible for employees to easily find the information they need for a workable solution. Knowledge Management reduces employee hours, enhances service quality, and increases customer satisfaction by anticipating their wants and needs in the form of readily retrievable documentation.

The goal of Knowledge Management is to enable organizations to improve the quality of management decision making by ensuring that reliable and secure information and data is available throughout the service lifecycle.

The objectives of Knowledge Management include:

■ Enabling the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service

■ Ensuring staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the use of those services

■ Ensuring that, at a given time and location, service provider staff have adequate information on:

● Who is currently using their services

● The current states of consumption

● Service delivery constraints

● Difficulties faced by the customer in fully realizing the benefits expected from the service.

We will say now ” KM “ for Knowledge Management.

KM is to ensure the right information is delivered to the competent person at the right time to enable an informed decision.

Defines many benefits of KM Defines many benefits of KM SKMS defined with a broad scope

· Staff skill sets
· User skill sets
· Partner abilities
· Other, e.g. weather, user behaviour

An overall organizational knowledge management strategy is required.

Understand various methods for knowledge transfer knowledge transfer (a.k.a. learning methods)

· Establish Requirements
· When to capture
· How to structure
· Security and liability issues Security and liability issues
· Audience access rights

Define an information architecture

Establish procedures:

· Determine what to capture
· How to maintain it
· How to make it available
· How to store and retrieve it
· How to set authority rights How to set authority rights
· Retention & Transmission
· Backup & Recovery
· Requirements for review

Based on the above, we have designed the following database structure of Knowledge Management.

We can see on the above step of SLA organization step. If costumers have any question or problem, with SLA parameter show us limit of answer time.

What to include in the knowledge base Business language and terminology, how IT terminology is translated.

Business process, and how IT supports them
SLA OLA d UPC SLA, OLAs, and UPCs
Process maps
Known error logs and workarounds
Business and public calendars

2.2-Change Management:

Change management aims controlling and managing lifecycle of changes. Main objective of change management is to enable benefical changes to be made.Changes sometimes may be very risky.Also change management is responsible for minimize risks of changes to IT environment.

2.2.1-Change Management Process

2.2.1.1-Raising and Recording Changes

We must record new changes and we use several ways to record during recording :

Team member can generate a change manually .
Team member can request a change through the System Catalog.
A change can be requested from incident
A change can be requested from a problem.
İf user wants to create task , the task generator will ask them to "Please specift your task." .So tasks are always assigned a handlıng process.
İf inbound email action is configured . i can be generated from email.

2.2.2-Assesing and Evaluating Changes

Once a change request is in place, the change management team must populate the change request with as much information as possible in order to fully assess the requested change.

Information that can be collected out-of-box:

Priority

2.2.3-Planning Changes

Changes could be planned in change record , but it could be hard when we recording multi-step chenges. Project Management allows specificity of planning. Projects in the Project plugin can organize many layers of tasks, and present the tasks as a Gantt Chart timeline.

2.2.4-Authorizing Changes

Approvals for changes can be specified in one of several ways.

Specified by hand, using the Approvers related list

Generated using an Approval Rule

Generated using a workflow.

Using automated approvals, emails will be sent out informing the appropriate user that they need to approve the change. They can either update the Approval field on the form, or can simply respond to the email if the appropriate inbound email action is configured.

2.2.5- Closing Changes

Once the change has come to an end, and the change has been tested and confirmed, the change can be closed by changing the state. If the change was generated from an incident or problem, a business rule can be configured to automatically close them upon closing the change.

Continual Service Improvements to Change Management

The change management process can be improved by the service desk, using information gathered within the platform. Much of the data is already stored within the incident record. More information can be gathered by enabling auditing, which allows for an accurate review of the history of the problem. With Metric Definition Support, it is possible to define the Key Performance Indicators to monitor within the system. With these metrics, and the information within the database, it is possible to generate reports, which can then be added to homepages or automatically generated and distributed. With Database Views it is possible to join tables for reporting purposes.

Using this information, it is possible to refine automatic rules such as the assignment rules, workflow, approval engines, or scheduling to better suit the change management team's unique environment.

2.2-Transition Planning And Support

Transition planning and support defines the planning and coordination of resources in order to deliver the specification of the Service Design. Risks and issues are managed effectively through this process.

Contents conceal

1 survey

2 Process depiction

3 Sub Processes

4 Definitions

5 KPIs | Checklists

6 Roles | Responsibilities

There are a number of activities for Transition Planning, these include:

Set up transition strategy - This strategy defines the approach to Service Transition and the allocation of resources.

Prepare Service Transition - This consists of analysis and acceptance of input from the other Lifecycle phases and other inputs such as identifying, logging and planning Requests for Change (RFCs).

Plan and coordinate Service Transition - An individual plan describes the activities and tasks to roll out a release in different environments (Test and Live).

Support - Service Transition advises and supports all stakeholders. The Planning and Support team communicates with stakeholders and informs them regarding processes, supporting systems and tools.

Service Transition activities are base-lined and monitored so they can be compared with actual results.

Service Transition Planning and Support is in charge of planning and coordinating all the resources that the Service Transition processes need to package, build, test, release, deploy, and establish a new or changed service. Service Transition Planning and Support ensures that these activities are done within the predicted cost, quality, and time estimates.

This process also plans and coordinates resources so that the new or changed service meets the requirements outlined in Service Design. In addition, Service Transition Planning and Support identifies, manages, and controls any disruptions that take place when transitioning the new or changed service into the live environment. This process provides support to all the processes and personnel involved in the Service Transition phase.

The goals of Transition Planning and Support are to:

■ Plan and coordinate the resources to ensure that the requirements of Service Strategy encoded in service Design are effectively realized in Service Operations

■ Identify, manage and control the risks of failure and disruption across transition activities.

The objective of Transition Planning and Support is to:

■ Plan and coordinate the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates

■ Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities

■ Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.

2.3-Service Transition - Asset and Configuration Management

The traditional software configuration management (SCM) process is widely considered to be the best approach to handling changes in IT projects. We use Configuration Management to identify the functional and physical attributes of our service at various points in time, and then systematically control any changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the lifecycle of the service. In ITIL, items are managed as Configuration Items (CIs) under the control of Configuration Management.

To be efficient, every organisation needs to manage their assets well. ITIL recommends maintaining a complete inventory of assets where asset details and those who can change those assets are documented and recorded. ITIL refers to Service Asset Management as the process of managing those assets to support the overall Service Management process.

In ITIL we treat both of these functions as SACM - Service Asset and Configuration Management.

SACM activities

Planning and Management
Identifying Configuration Items
Controlling Configuration
Status Reporting
Auditing

The protection of assets is an important part of the ITIL service lifecycle. All service assets are identified and recorded during SACM. We report, audit and verify our assets on regular basis to capture attributes, versions and baselines. Penalties for not managing assets correctly can include fines and service outages. These are the kind of things we want to avoid.

By capturing information and keeping it up to date, we help people make informed decisions at the right time. In addition, providing accurate configuration information can proactively help resolve incidents and problems much faster. We all know that having the information to hand is much better than having to go out and find it.

Benefits

By implementing SCAM we can:

Provide better forecasting
Help new releases to be implemented successfully
Resolve incidents faster (out of date information is never helpful!)
Adhere to standards and contracts
Track costs associated with the service

2.4-Service Transition - Release Management

Release Management is a proactive approach to planning and preparing new services for release to ensure optimum cost and minimized risk. Release management protects the live service environment to avoid unwanted impact, whilst delivering services specified through Service Design to meet the stakeholders requirements.

During Release Management we define and agree release deployment plans and ensure that any released packages consist of assets and components that are fully compatible. Before releasing a service we need to make sure it can be tracked, installed, tested and also verified. This is obviously done before we release a package, as it would be extremely risky to just assume a package is ready for deployment.

As a service is released into the customers environment, they need information to use the new service effectively and accommodate it into their business processes. We pre-plan this by using knowledge transfer during the Release Management process. The helpdesk and operations also need information regarding the new service to be able to reliably support and maintain the service and meet agreed service levels. Release Management provides this skill and knowledge transfer to the support and operation teams.

What do we produce during Release Management

Release plans
Release packages
User documentation
Training

Each release plan is authorized through Change Management and defines the following:

Scope of release
Risk assessment
Stakeholders affected
Who is responsible for release (e.g. which team)

Each service must pass through a serious of checkpoints before its considered ready for production. We usually setup the following environments; build, test and production. The test environment is used to check the service components operate in harmony and evaluate any potential risks. As the release passes through each checkpoint, it gets closer to the production environment, by which time any issues have been fully corrected and the service is in a satisfactory state. In addition to the test environment, we sometimes use a pilot scheme to test drive the service with a small user base. This can provide some superb feedback and help us modify the service appropriately to delivery maximum value.

Which method of deployment
There are a variety of methods to deploy releases. These range from deploying the entire service to gradual roll outs across user bases. We can also look at ITIL software to automate rollouts and cut down on the time required by our support teams to perform repeatable actions and even a central 'push' rollout from a distribution centre. The Service Design stage will usually select the most suitable release model that includes methods, procedures and resources required to build and release on time.

2.5-Evalation Process

Evaluation is a generic process that considers whether the performance of something is acceptable, value for money, etc. – and whether it will be proceeded with, accepted into use, paid for, etc.

Purpose: to provide a consistent and standardized means of determining the performance of a service change in the context of existing and proposed services and IT infrastructure

Actual performance of a change is assessed against its predicted performance and any deviations between the two are understood and managed

Wikipedia defines evaluation as "systematic determination of merit, worth, and significance of something using criteria against a set of standards". In ITIL we evaluate the effects of a service change and any of the unintended effects to help Change Management make effective decisions as to whether changes should be approved or not.

In reality, it's easy to predict the intended effects because those are what we expect to occur. The unintended effects are much harder to predict and in some cases are not even seen until the service change is actually implemented and we're in production already.

As with most ITIL practices, evaluation is concerned with value. If used effectively, evaluation will deliver benefit from informed decisions from Change Management and the future services delivered. Continual Service Improvement also feeds from our evaluation at the transition stage to enhance future predictions and performance.

2.6-Service Validation and Testing

The objective of ITIL Service Validation and Testing is to ensure that deployed Releases and the resulting services meet customer expectations, and to verify that IT operations is able to support the new service.

· Process for establishing that the Service Design and release will deliver a new or

changed service or service offering that is fit for purpose and fit for use ·Goal: to assure that a service will provide value to customers and their business

· The Service V Model can be used to map the types of test to each stage of development The Service Validation and Testing process is responsible for planning and coordinating tests to ensure that specifications for the service design are met and validated through delivery of the service and, including co-operation with the Release and Deployment process, to manage and limit risks that could result from insufficient utility and warranty of the service in operation. Service Validation and Testing takes the technical proficiencies and plans of quality assurance for IT and strategically places them in the larger context of service quality for the business. The strategic issue is that the business must be able to grow and adapt in order to maintain its success and critical competencies in its market ecosystem of customers, partners and competitors. This makes both Capacity and Change strategic areas of risk, and consequently it makes investments in service deliveries and service modifications part of financial management as well as business risk management.

The ultimate goal of the Service Validation and Testing track is a full alignment of

Service characteristics to the utility and warranty requirements of the business.

The subway map in this way:

• Adopt Best Practices

• Validate and Verify

• Perform Tests

• Closure and Reporting

Adopt Best Practices

The key practices of Service Validation and Testing will be

• A model for identifying business alignment

• An integrated set of test plans

• Training, knowledge transfer, and communications

• Verification of results through pre-defined tracking and reporting

These practices are represented in the following table, which illustrates the incorporation

of testing within a larger process framework (inputs, activities, and eventual outcomes) of

identifying business value from quality assurance.

The inputs for this high-level process express two things: a proactive identification of the

customer’s view of a service, and the perspectives of the testing organization as driven by

that view. Explicit definitions and standardized formulations of the relevant factors across

the process are reusable, which allows for direct comparisons of different testing occasions.

A service management organization will want to reach a level of confidence that the various

items exist and are clearly related to each other. This will call for assigning clear

responsibilities for routine production and review of the items.

Validate & Verify

The outstanding feature of Service Validation and Testing is its deliberate synchronization of

test types with defined business requirements, agnostic to particular technologies and to the

variations of hardware and software. The following illustration presents an overview of

this synchronization.

Tracking Validations Versus Requirements

• Specs decompose from top down—business to service to supplier

• Tests build from bottom up—components to functions to business agreements

Perform Tests

The essence of manageable testing is the ability to define tests as repeatable,

measurable procedures.

This introduces the aspect of Key Performance Indicators (KPIs). As noted in most literature

on performance management, KPIs are metrics that address efficiency, effectiveness and

cost issues traceable to the design of an executing process and related to the outputs of that

process. Indicators identify output characteristics that correlate to desired outcomes, and the

means of driving those indicators will be seen as Critical Success Factors (CSFs).

Accordingly, testing will feature standards, scripts (methods) and metrics that are defined and

logically related to each other before test execution actually begins.

The processes may feed each other as participants in shared workflow. In the ITIL subway

map of processes, this is notable especially where the Build and Release of a service package

involves validation and testing.

One of the most important aspects of these process integration points is the documentation

that occurs and is used from validation and testing. For example, a test plan usually precedes

release and deployment activities, and an update of service records in a configuration

management database (CMDB) usually follows deployment but precedes a

postimplementation review (PIR). This arrangement highlights the cooperation expected

between managers of services, configurations, changes and releases.

Report / Closure

Documentation of results is also a fundamental deliverable of the Service Validation and

Testing effort, as testing itself is expected to be the source of evidence that the service is

not ready for delivery and may go through another iteration of development or modification

before it can succeed.

As part of proper management of testing itself, these cycles of tests need directives

identifying and justifying whether the scope and depth of testing is to be different or not in

the next cycle versus the prior one. Because test cycling directly affects the turnaround time

between development and release, the management of the test iterations affects the ability of

the organization to meet service level agreements with customers.

Test reporting explicitly establishes the reasons why something is tested and why it is deemed

suitable for release or not. As material for decision support, the reporting affects resource

allocations as well as readiness for compliance auditing

Conclusion

As you reach the end point of the Validation and Testing journey outlined in the CA Service

Transition process map, your organization should have a better handle on the steps needed to

promote successful service deployments. Specifically, bringing deployment efforts in line with

ITIL best practices:

• Improve business process capabilities

• Effectively upgrade the IT infrastructure in timely alignment with business needs

• Foster the efficient delivery of multiple IT services

• Improve the quality of technical support

• Stronger integration with other ITSM and ITIL best practices

Information Technology Infrastructure Library Service Transition Education

14 Haziran 2013 Cuma