ITIL is the most organized and acceptable approach of providing IT services to an organization. It has five core publications. I have already covered the first two in my previous articles on techulator. You can refer the below links to know more about it.
ITIL V3 Foundation or ITIL 2011
Now, I am going to cover the third publication of ITIL - Service Transition comes after Service Strategy and Service Design. Please refer the below links to know more about them. I have given a detailed process followed in these two publications.
ITIL V3 Foundation or ITIL 2011 - Service Strategy
ITIL V3 Foundation or ITIL 2011 - Service Design publication stages
Service Transition is a stage which is involved in building and deploying IT Services in an organization. It ensures the coordination while any changes taking place in IT Services and processes between all the parties involved.
It has 8 processes. They are as follows:
1. Change Management
2. Change Evaluation
3. Project Management (Planning and Support)
4. Application Development
5. Release and Deployment Management
6. Service Validation and Testing
7. Service Asset and Configuration Management and
8. Knowledge Management
Let's discuss each sub process in detail.
It controls the complete life cycle of any change being proposed. It aims at establishing advantageous changes with the least impact on IT Services.
A change manager provides templates for authorizing the change proposals and forwards the process information on planned and ongoing changes to ITSM after receiving change proposals from Service Strategy Management team and assess them to see if they meet the client's business needs and to identify possible prior issues before starting the design activities.
It rejects the change proposals which lack any potential information and the ones which do not seem practical. The change proposal is also known as Request for Change (RFC).
To test, approve and implement Emergency Changes as soon as possible. Whenever an incident or event or a problem occurs unexpectedly, change management team applies an immediate change to restore the services. This change is known as an Emergency Change.
If a change is minor, it can immediately authorized by change manager however, if there's any potential change to be implemented, it has to follow a specified and predefined procedure for approval. It is submitted to Change Advisory Board (CAB) for their review, assessment and authorization.
CAB assesses the Change Proposal and authorize it. CAB can also involve higher IT Management teams for approval process.
It schedules Change and plans its Release and assesses the final project plan before authorizing the change request.
This process involves the assessment of the Change components to be built have been properly tested and authorizes the Change Deployment.
It creates low risk and well defined and understood minor changes which might not require any coordination with Release Management.
It does post change implementation review and change closure the looking at the results achieved, verifies the history of the activities taken place during Change implementation phase and makes an analysis of mistakes committed for future learning purpose.
It's involved in the assessment process of any major or potential change before it goes into the next phase of the Change Management Life Cycle.
It assesses any major or substantial change to be authorized to enter into the Planning phase of Change Cycle.
It assesses the proposed potential change before it enters the Building phase of the Change life cycle.
It assesses proposed major change before it starts the Deployment phase of the Change life cycle.
It verifies if a change post-implementation has met all its objectives and also the errors made during the process and the lessons to be learned and remembered for the future Change life cycle.
It's involved in the planning and coordination of IT resources before a potential Release is deployed by keeping in mind the factors like cost, time and quality. A person with a Project Management Certification will be a good resource to lead the sub-processes discussed below.
ITIL Project Management process has sub-processes like Initiation, Planning, Control and Reporting.
Initiation sub-process involves defining the responsibilities and resources required and available for the project. It also coordinates all the stakeholders involved in the execution of the project. It discusses the risks, constraints, assumptions, hurdles, challenges, etc., involved or may occur during the project and documents them.
Planning involves in making sure that the transition project is planned according to the company's Project Management guidelines, coordinates resources and activities across the teams involved in the project and triggers the planning activities performed by other processes involved in the project.
Control sub-process involves monitoring the development or progress of the project and utilization of resources, looks at the expedition part of it and also takes corrective action if required.
Reporting sub-process involves the communication of the overall progress of the project to the customers and other Service Management processes.
This process involves in ensuring that the required applications and systems are available in IT services during the project, aims at developing and maintaining the applications and products to be obtained from software vendors.
Release and Deployment Management
This process is involved in the planning, scheduling and controlling the progress of a release in both Testing and Live Environment in the organization. The main goal of this process is to maintain the protection of the integrity of the live environment and ensures the releasing of the right components.
This process has sub processes like Release Management Support, Release Planning and Building, Release Deployment, Initial Release Deployment Support and its Closure.
Release management aims at providing guidelines and support for the Release deployment.
Release Planning sub process aims at assigning approval to Changes to the Release Package. It creates a schedule for building, testing and deploying the release. It places the required work orders and purchase requests to make sure required release components are either developed within the company or purchased from outside vendors and keep them for Testing phase.
Release Deployment aims at deploying the release components after testing phase into the Live environment. It's responsible for delivering the training to the end users and staff, circulates and documents the information about the newly deployed release to all the parties involved.
Initial Release Deployment Support aims at providing the resolution for the issues faced by the operations during the initial phase of deployment and eliminates the deficiencies and errors during the process.
Closure aims at formally closing the release after updating the management on the process, knowledge and information up to date.
Service Validation and Testing
This process is involved in validation if the deployed releases and the resulting products and services are meeting the customer expectations and also verifies if IT operations are able to deliver the new services effectively.
This process has a sub processes like Test Model, Release Components Acquisition, Release Test and Service Acceptance Test.
Test Model is involved in specifying the detailed procedure on how the Release is tested and quality assured. It defines the testing concepts and also decides on using the specific testing cases for testing Service Validation.
Release Acquisition aims at acquiring the proper Release Components and makes sure that only the best and quality components which meet the stringent quality standards are acquired and allowed to enter the intensive testing phase.
Release Test involves in testing the tools and processes required for the live deployment. It ensures that only the components meeting the most stringent quality standards are allowed to enter the Live Productive Environment.
Service Acceptance Test aims at enabling all the conditions meeting the new service, obtains the written consent from the customer that the new service meets the Service Level Agreement requirements. In this phase, if all the above processes and procedures are correctly and properly followed, there wouldn't be any errors. If the errors or defects come out, the Release Manager, Service Level Manager and Customer will collectively find out the actions to be taken to eliminate the hurdles.
Service Asset and Configuration Management
This process involves in maintaining the Configuration Items (CI) needed to deliver IT services.
This process has sub processes like Identification of Configuration, Control and Verification and Audit.
Identification of Configuration defines and maintains the information on CI. It specifies the attributes for CI types and its components.
Control aims at ensuring that the CIs are modified or added without any need for authorization and the modifications are recorded in Configuration Management System.
Verification and Audit aims at monitoring and ensuring that CMS is recorded with the correct information on CIs which are installed in live productive environment.
This process is involved in the gathering, analysis, storage and sharing of knowledge and information across all the required departments within the organization. Its primary focus is to increase the efficiency by reducing the need to discover or rediscover the information.
Service Knowledge Management System (SKMS) serves as the central repository for storing the data, knowledge and information about the IT services required by the organization. It forms knowledge or learning base for the employees for reference to carry out their daily job functions.
Hence this was all about Service Transition Publication of ITIL which is widely used and serves as the bet practice and approach in an IT organization.
More articles: Itil