4.8.8 Design Co-ordination Process
Design Co-ordination is a process responsible for coordinating all service design activities, processes and resources. It ensures consistent and effective design of new or changed IT services, service management information systems, architectures, technology, processes, information and metrics
A) Purpose of Design Co-ordination Process
Ensure the goals and objectives of the service design stage are met by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle.
B) Objectives of Design Co-ordination Process
- Ensures all aspects of the design (architecture, processes and metrics) to provide utility and warranty to meet business requirements for now and in future.
- To resolve conflicts in demand in case of simultaneous competing projects including resources and time conflicts.
- To ensure everyone is clear about the requirements for handing over between different lifecycle (e.g. service design package to transition phase)
- To check whether all requirements are met and repeatable design practices are used
- To reduce risks associated with complexity of projects.
- To compile the service design package within inputs from various processes.
C) Scope of Design Co-ordination Process : Design Co-ordination process covers all activities in design and ensure consistency across them for new, existing and retiring services.
5. Service Transition
Service Transition establishes the services as specified in the Service Design phase, based on the customer and stakeholder requirements. A Service Transition is effective and efficient if the transition delivers what the business requested within the limitations in terms of money and other necessary resources.
5.1 Purpose of Service Transition
The Purpose of Service Transition is to ensure that new, modified or retired services meet the expectations of the business as documented in the service strategy and service design stages of the lifecycle
5.2 Objectives of Service Transition
1) Plan and manage changes to services (either introducing new or retiring existing services) and to deploy the new services successfully to support business objectives while ensuring the integrity of all existing services
2) Ensure the service can be operated and supported according to the service design
3) Manage the risks associated
4) Set the expectations of the business with testing on the performance
5) Provide knowledge and info of the service / service assets to relevant people to ensure smooth operation
5.3 Scope of Service Transition
1) Provides guidance for the development and improvement of capabilities for transitioning new and changed services into supported environments, including release planning, building, testing, evaluation and deployment.
2) Considers service retirement, transfer of services between service providers
3) Focuses on how to ensure that the requirements from service strategy, developed in service design, are effectively realized in service operation while controlling the risks of failure and subsequent disruption.
4) Includes the transition of changes in the service provider's service management capabilities that will impact on the ways of working, the organization, people, projects and third parties involved in service management.
5.4 Value to Business
Service Transitions creates value for the business by improving:
1) The ability to adapt quickly to new requirements.
2) The success rate of changes and releases for an organization.
3) The predictions of service levels and warranties for new and changed services.
4) Confidence in the degree of compliance with the organization requirements during change.
5) Clarity of plans so the business can link their organization change plans to transition plans.
5.5 Basic Concepts in Service Transition Processes
1) Service knowledge management system (SKMS): It is a set of tools and databases that is used to manage knowledge, information and data. The SKMS includes the Configuration Management System (CMS), as well as other databases and information systems. The SKMS includes tools for collecting, storing, managing, updating, analyzing and presenting all the knowledge, information and data that an IT service provider will need to manage the full lifecycle of IT services.
2) Configuration item (CI): A Configuration Item (CI) is an asset, service component or other item which is, or will be, under the control of Configuration Management. CIs may vary widely in complexity, size and type, ranging from an entire service or system including all hardware, software, documentation and support staff to a single software module or a minor hardware component.
3) Configuration management system: A set of tools, data and information that is used to support service asset and configuration management.
4) Definitive media library (DML): Is defined as one or more locations that securely store the definitive and approved versions of all software CIs.
5) Change: The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.
6) Change types
- Standard Change: A pre-approved Change that is low Risk, relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs 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. For example to resolve a Major Incident or implement a Security patch.
- The Change Management Process will normally have a specific Procedure for handling Emergency Changes.
- Normal Change: Any service change that is not a standard change or an emergency change. There are three types of normal changes:
- Minor change - authorized by change management staff directly.
- Significant change- requires advice from change advisory board (CAB)
- Major change -requires change proposal, business management approval
5. Service Transition
5.6.1 Change Management Process
Change Management Process is responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.
A) Purpose of Change Management Process
Purpose of change management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.
B) Objectives of Change Management Process
- Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change related Incidents upon service quality, and consequently to improve the day to day operations of the organization.
- Respond to changing business requirements.
- Minimize 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.
C) Scope of Change Management Process
- Cover everything from configuration items (servers, infrastructure, documentation, services and configuration), management systems and tools, processes, metrics, solution and architecture from design strategy to continual service management excluding organization and business changes, and minor operational changes.
- Manage all changes in a controlled manner on all levels (strategic, tactical and operational) by making reference to the service portfolio.
- Change management is not responsible for the coordination of processes for the successful implementation of projects. This will be handled through the planning and transition support process.
D) Types of change request
There are three service change types they are: Standard, Emergency and Normal.
1) Standard Change: A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction.
2) Emergency Change: A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch.
3) Normal Change: Any service change that is not a standard change or an emergency change. Normal changes are often categorized into three types:
- Minor change - authorized by change management staff directly.
- Significant change- requires advice from change advisory board (CAB)
- Major change-requires change proposal, business management approval
E) Change models
Change model is a repeatable way of dealing with a particular category of change. Change Models defines specific agreed steps that will be followed for a change of this category. Change models may be very complex with many steps that require authorization (e.g. major software release) or may be very simple with no requirement for authorization (e.g. password reset).
Change models include:
- Steps to handle the change, including issues and unexpected events.
- Order steps should be taken, with dependences or co-processing defined
- Responsibilities - who should do what?
- Timescales and thresholds for completion of the actions.
- Escalation procedures - who should be contacted and when
F) Remediation Planning
Remediation is an action taken to recover after a failed change or release. Remediation may include back-out, invocation of service continuity plans, or other actions designed to enable the business process to continue.
G) Change Advisory Board and Emergency Change Advisory Board
Change Advisory Board:
- A group of people that supports the assessment, prioritization, authorization and scheduling of changes.
- A change advisory board is usually made up of representatives from: all areas within the IT service provider; the business; and third parties such as suppliers.
Emergency Change Advisory Board
- A subgroup of the change advisory board that makes decisions about emergency changes.
- Membership may be decided at the time a meeting is called, and depends on the nature of the emergency change.
H) Lifecycle of a Normal change
The Change Management Process consists of seven high-level activities specifically developed to manage the life cycle of change requests. Typical activities in managing individual changes are:
1) Create and record the Request for Change (RFC).
2) Review the RFC
- Filter changes (e.g. incomplete or wrongly routed changes)
3) Assess and evaluate the change
- Establish the appropriate level of change authority
- Establish relevant areas of interest (i.e. who should be involved in the CAB)
- Evaluate justification, impact, cost, benefits, risks, and predicted performance
- Submit a request for evaluation to initiate activity from the change evaluation
4) Authorize the change
- Obtain authorization/rejection
- Communicate the decision with all stakeholders, in particular the RFC initiator
5) Plan updates
6) Coordinate change implementation
7) Review and close change
- Collate the change documentation, e.g. baselines and evaluation reports
- Review the change(s) and change documentation
- Ensure lessons learned details are recorded in the SKMS
- Close the change document when all actions are completed
5.6.2 Release and Deployment Management Process
Release and Deployment management is a process responsible for planning, scheduling and controlling the build, test and deployment of releases, and for delivering new functionality required by the business while protecting the integrity of existing services.
In the Release and Deployment management process different considerations apply in respect of the way in which the release is deployed. The most frequently occurring options for the rollout of releases are: "big bang" versus phased, "push and pull", automated or manual.
A) Purpose of Release and Deployment Management Process
- The purpose is to ensure that consistent and integral release packages are deployed in line with agreed policy and with plans agreed with the customers and stakeholders, and that this takes place under full and effective control.
- Any associated business and business process changes, including training and skills transfer, must be managed to take place in a timescale that is aligned with the release timetable.
B) Objectives of Release and Deployment Management Process
- The objective of release and deployment management is to build, test and deliver the capability to provide the services specified by service design.
- to define and agree on deployment plan with stakeholders
- Create and test release packages
- Maintain the integrity of the release packages and ensure that they are secured in DML.
- Ensure the new / changed services meets utility and warranty needs
- Capture lessons learned
- Ensure that skills and knowledge are transferred to operations and support staff
C) Scope of Release and Deployment Management Process
- The processes, systems, and functions required to deliver a release into production
- Build, ensure testing and deploy the release to the utility and warranty requirements
- Handover of service to operation teams
- 4) Manage all CIs and things related to the release.
D) Four phases of Release and Deployment Management Process
The process activities of release and deployment management are:
- Release and Deployment Planning - begins with planning a release and ends with change authorization to create the release
- Release Build and Test- the release package is built, tested, and checked into the DML, end with authorization to include the package in DML
- Deployment - deploy the package from DML and handover of service to operation, early life support might be needed for faster response and knowledge transfer
- Review and Close - experience and feedback are captured, performance targets, achievements are reviewed and lessons are learned
5.6.3 Knowledge Management Process
Knowledge Management is a process responsible for sharing perspectives, ideas, experience and information, and for ensuring that these are available in the right place and at the right time. The knowledge management process enables informed decisions, and improves efficiency by reducing the need to rediscover knowledge.
A) Purpose of Knowledge Management Process
The purpose of Knowledge Management is to ensure that the right person has the right knowledge at the right time to enable them to make sensible decisions about courses of action.
B) Objectives of Knowledge Management Process
- Improve the quality of management decision-making by ensuring that reliable and secure knowledge, information and data is available throughout the service lifecycle
- Enable the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service by reducing the need to rediscover knowledge
- Ensure staff have a clear and common understanding of the value their services provide to customers and ways in which benefits are realized from use of services
- Maintain a service knowledge management system (SKMS) that provides controlled access to knowledge, information and data that is appropriate for each audience
- Gather, analyze, store, share, use and maintain knowledge, information and data throughout the service provider organization
C) Scope of Knowledge Management Process
- the management of data and information across the service management processes share of information with customers and users
- NOT including the detailed collection and maintenance (in Service Asset and Configuration Management)
D) Data-to-Information-to-Knowledge-to-Wisdom (DIKW) structure
- Data -- discrete facts about Events. Most organizations capture significant amounts of data in highly structured databases such as service management and service asset and configuration management tools/systems and databases
- Information - comes from providing context to data. Information is typically stored in semi-structured content such as documents, email and multimedia. The key knowledge management activity around information is managing the content in a way that makes it easy to capture, query, find, re-use and learn from experiences so that mistakes are not repeated and work is not duplicated.
- Knowledge - includes tacit experiences, ideas, insights, values, and judgments of individuals. People gain knowledge both from their own and from their peers expertise, as well as from the analysis of information
- Wisdom - makes use of knowledge to create value through correct and well-informed decisions. Wisdom involves having the application and contextual awareness to provide strong common-sense judgment.
Knowledge Management is typically displayed within the Data-to-Information-to-Knowledge-to Wisdom (DIKW) structure.
E) Service knowledge Management System (SKMS)
SKMS is a set of tools and databases that are used to manage knowledge and information. The SMKS includes the Configuration Management System, as well as other tools and databases. The SKMS stores, manages, updates and presents all information that an IT Service Provider needs to manage the full Lifecycle of IT Services.
One very important part of the SKMS is the configuration management system (CMS). The CMS describes the attributes and relationships of configuration items, many of which are themselves knowledge, information or data assets stored in the SKMS.