The document defines Wedgewood Inc.'s IT change management process, activities, and roles. It establishes a framework for managing infrastructure changes through standardized methods and procedures. The objectives are to improve service/support quality, reduce risks and costs from changes, and achieve compliance. Key aspects include a change advisory board, four-phase change lifecycle of initiate/assess, design/build, test, and deploy/validate/close, and roles such as change manager and project sponsors.
ITIL 4 service value chain data flows (input and outputs)Rob Akershoek
This document provides an overview of the inputs and outputs between activities in the IT service value chain. It shows that all activities engage with external parties, obtain new resources, plan, and improve. Key inputs include requirements, requests, incidents and feedback from customers and users. Outputs include improvement initiatives, status reports, and delivered services and components. The value chain aims to design, deliver, and support products and services based on strategic plans and customer needs.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
An Introduction to IT Management with COBIT 2019Gregor Polančič
This document provides an overview of key concepts from COBIT 2019, an enterprise governance of IT framework. It begins with an introduction to IT management and governance, explaining that IT management involves planning, building, running and monitoring IT activities in alignment with governance. Effective enterprise governance of IT (EGIT) helps realize benefits, optimize risks and resources, and improve business/IT alignment. Frameworks like COBIT provide best practices to assist with understanding, designing and implementing EGIT. COBIT 2019 builds on over 25 years of development and aligns with major standards. It defines six principles for effective governance systems and three principles for governance frameworks. The document concludes with an introduction to COBIT 2019 concepts.
The document describes Pink Elephant's service desk and support services. It offers service desk improvement programs to assess, improve, and implement service desks. It provides managed flexible employees to supplement or replace current resources. The service is designed to solve problems like demotivated staff, low fix rates, lack of knowledge management, and poor leadership. Features include help with improvement, management of staff training and motivation, assistance with tool selection, and off-shore capabilities. The company values focus on customers, accountability, and teamwork.
The document summarizes IT service management at Hanover Technology Group. It discusses what service management is and the benefits it provides to HTG and its business partners. These benefits include increased customer satisfaction, financial savings, and improved decision making. The document also outlines HTG's 2011 goals and objectives for its service management initiative, which include implementing ITIL processes and the Service-Now automation platform to transform HTG's operations and deliver more business value. Training offerings are mentioned to educate staff on these new services and processes.
Application Management and Support - Shared Services Featuring the Pay Per Ti...Jade Global
Today, a variety of IT applications support business processes, giving it a competitive edge. Hence, applications that drive these businesses need to evolve just as rapidly while ensuring uninterrupted service to the customer.
Systems and applications do stabilize over time, but they still need maintenance. However, maintaining support resources and infrastructure can be costly and time consuming. Several models have emerged in the recent past that try and address this challenge, however a majority of them have had little success, frustrating service providers and customers alike and leaving neither of them satisfied.
In this webinar, our Consulting Director, Manoj Machiwal, will talk about how to address these challenges using the Pay per Ticket Model, a phase of new revolution in the AMS industry.
Get the maximum from your application support and maintenance investments and take a look at the future road map of AMS.
Know more, please visit: http://www.jadeglobal.com/
ITIL 4 service value chain data flows (input and outputs)Rob Akershoek
This document provides an overview of the inputs and outputs between activities in the IT service value chain. It shows that all activities engage with external parties, obtain new resources, plan, and improve. Key inputs include requirements, requests, incidents and feedback from customers and users. Outputs include improvement initiatives, status reports, and delivered services and components. The value chain aims to design, deliver, and support products and services based on strategic plans and customer needs.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
An Introduction to IT Management with COBIT 2019Gregor Polančič
This document provides an overview of key concepts from COBIT 2019, an enterprise governance of IT framework. It begins with an introduction to IT management and governance, explaining that IT management involves planning, building, running and monitoring IT activities in alignment with governance. Effective enterprise governance of IT (EGIT) helps realize benefits, optimize risks and resources, and improve business/IT alignment. Frameworks like COBIT provide best practices to assist with understanding, designing and implementing EGIT. COBIT 2019 builds on over 25 years of development and aligns with major standards. It defines six principles for effective governance systems and three principles for governance frameworks. The document concludes with an introduction to COBIT 2019 concepts.
The document describes Pink Elephant's service desk and support services. It offers service desk improvement programs to assess, improve, and implement service desks. It provides managed flexible employees to supplement or replace current resources. The service is designed to solve problems like demotivated staff, low fix rates, lack of knowledge management, and poor leadership. Features include help with improvement, management of staff training and motivation, assistance with tool selection, and off-shore capabilities. The company values focus on customers, accountability, and teamwork.
The document summarizes IT service management at Hanover Technology Group. It discusses what service management is and the benefits it provides to HTG and its business partners. These benefits include increased customer satisfaction, financial savings, and improved decision making. The document also outlines HTG's 2011 goals and objectives for its service management initiative, which include implementing ITIL processes and the Service-Now automation platform to transform HTG's operations and deliver more business value. Training offerings are mentioned to educate staff on these new services and processes.
Application Management and Support - Shared Services Featuring the Pay Per Ti...Jade Global
Today, a variety of IT applications support business processes, giving it a competitive edge. Hence, applications that drive these businesses need to evolve just as rapidly while ensuring uninterrupted service to the customer.
Systems and applications do stabilize over time, but they still need maintenance. However, maintaining support resources and infrastructure can be costly and time consuming. Several models have emerged in the recent past that try and address this challenge, however a majority of them have had little success, frustrating service providers and customers alike and leaving neither of them satisfied.
In this webinar, our Consulting Director, Manoj Machiwal, will talk about how to address these challenges using the Pay per Ticket Model, a phase of new revolution in the AMS industry.
Get the maximum from your application support and maintenance investments and take a look at the future road map of AMS.
Know more, please visit: http://www.jadeglobal.com/
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
http://flevy.com/browse/business-document/itil-incident-management-workflow--process-guide-3020
DOCUMENT DESCRIPTION
This document establishes an Incident Management (IM) process according to ITIL v3 best practice and ISO 20000. (Word document including Visio diagram of the process)
This document introduces the Incident Management process Framework; the workflow, roles and responsibilities, RACI Matrix, KPIs, metrics, procedures, and policies needed to implement a high quality process.
Document contains suggested templates for:
Incident Life-cycle stages
Prioritization Matrix
Categorization
Incident Closure codes
Functional and Hierarchic Escalation Matrix
Major Incident Procedure
Reporting
The document describes an upcoming seminar on ITIL Foundation Certification. It will provide an overview of IT Service Management and ITIL, including the key concepts and areas of ITIL. Attendees will learn about the ITIL service lifecycle and why organizations implement ITIL. The seminar will also help prepare attendees for the ITIL Foundation Certification exam.
It Service Management Implementation OverviewAlan McSweeney
This document describes an IT service management framework and implementation. It discusses ITIL/ITSM and the service management processes including incident and service request management. It provides an overview of the incident and service request management process including its principles, relationships between processes, and detailed processes. The document emphasizes that implementing service management requires understanding why it's being done, what resources are needed, and should be done in phases.
Application Management & Support Best PracticesJulie Champagne
In today’s healthcare IT environment, it takes a lot of support and coordination – of highly skilled and experienced technical staff – to keep a modern healthcare organization running smoothly. When a HCO considers outsourcing any portion of their IT operation, there are many unknowns and considerations to assess. This webcast will present best practices and processes in both exploring an application management support solution or partner and rollout, transition and implementation. Whether supporting a legacy or production application, the solution or partner should take complex and time-consuming tasks off of the organizations plate, allowing focus on more productive, strategic, operation improving and patient experience enhancing activities.
How to build an integrated and actionable IT Service Catalogmboyle
This presentation provides a lower level of detail on how to build a n IT service catalog than provided by ITIL V3. It augments thinking in this area based on 25 years of building Service Catalogs
The document summarizes the objectives, process, roles, and activities involved in a Solution Architecture Concept workshop. The workshop is intended to define the scope, components, and architectural overview of a proposed IT solution by bringing together stakeholders to develop a shared understanding of business needs and technical requirements. Key parts of the workshop include preparation activities, a two-day session to discuss business/functional and technology/implementation views, and documentation of findings.
The document provides an overview and comparison of three major IT governance frameworks: ITIL, COBIT, and ISO 27001. ITIL focuses on IT service management and was originally developed by the UK government. COBIT is aimed at regulatory compliance and risk management. ISO 27001 contains information security standards and guidelines. Each framework takes a different approach, with ITIL emphasizing processes, COBIT control objectives, and ISO 27001 information security practices. Implementing the frameworks requires consideration of factors like organizational needs, budgets, and vendor expertise.
The document provides an overview of the ITIL 4 Foundation course mind map. It summarizes the key topics covered in the ITIL 4 Foundation certification including general management practices, service management practices, creating service value, the service relationship model, external factors, the service value system, the service value chain, service value streams, and the ITIL overview. It also includes an example case study of how ITIL principles could be applied at a car rental company.
Historically, IT operations management (ITOM) teams have been focused on system health and up-time, while separately, IT service management (ITSM) teams manage and remediate end-user issues. The silos between these two functions have spurned challenges that can be overcome with improved integration, collaboration, and transparency across practices. ITSM and ITOM teams are working toward the same goals of up-time, accessibility and improved customer experience. So why can’t they integrate better for delivering on these objectives?
In this presentation, we explore:
The cause and business impact of silo'ed ITSM and ITOM practices
The benefits of improving integration, collaboration, and transparency across practices
Ways for you to exploit the inefficiencies and key metrics you can present the business in advocating for a better solution
And, we’ll introduce the solution of platform thinking, where silos are broken down between IT practices, and technology is operated and managed as a unified front with an open framework of adaptability.
Learn how to present a better solution for improving IT efficiencies, delivering improved customer experience, and enabling innovation throughout your organization, by bringing ITSM and ITOM practices together.
ITOM Platform features to look for if ITSM integration is important to your organization:
SERVICE HEALTH MANAGEMENT: Unified discovery and intelligence, Live asset Inventory, Unified service performance, Visual workflows in service maps
AIOPS MACHINE LEARNING: Intelligent event correlation, Noise suppression, Situational awareness, Incident Response
INTEGRATED TICKETING REQUESTS: Automated Escalations, Comprehensive Incident Collaboration
POLICY AUTOMATION SCRIPTS: Out of the box scripts, Customize scripts
SERVICE REMEDIATION: Enforce Process Governance, Automated Remediation Policies, Secure Infrastructure Access
Learn more at https://www.opsramp.com
Also, follow us on social media channels to learn about product highlights, news, announcements, events, conferences and more:
Twitter - https://www.twitter.com/OpsRamp
LinkedIn - https://www.linkedin.com/company/opsramp
Facebook - https://www.facebook.com/OpsRampHQ/
ITIL and ISO 20000: Fundamentals and necessary compliance SynergiesPECB
The world of Information Technology (IT) is voluminous, fast paced, innovative and very exciting!
You have to love IT to make it work!
To love IT you must live IT, to live IT you must embrace a design for success and understand business impacts from system failures (not just the hardware). To embrace a design for success and mitigate system failures you need a formal structure and independent validation.
This webinar will introduce you to the structure and choices within the ITIL fundamentals (Information Technology Infrastructure Library fundamentals) and a mechanism to validate the performance of the implemented ITIL structure compliant with the ISO 20000 standard (Information Technology -- Service management -- Part 1: Service management system requirements). The object of this webinar is to excite you about a formal IT structure and encourage you to be fearless about independently validating your service management arrangements.
Main points covered:
- Introducing an IT structure for service delivery and a case for IT system validation
- ITIL component options for IT service provision structure
- ISO 20000 as an IT service provision validation mechanism
- Synergy of ISO 20000 requirements and mandatory ITIL components
Presenter:
Eugene is an accomplished high-calibre sustainability and resilience authority, professional engineer and Fellow of the Business Continuity Institute (BCI). With over 25 years of hands-on experience he has developed and improved corporate resilience for a number of organisations from various sectors. His accomplishments include delivery of legislative & regulatory compliance requirements, implementation of ITIL, service, business continuity, information security, quality & risk management systems. In addition Eugene has many years of experience auditing ISO management systems. Eugene has represented the UK Institute of Directors (IoD) on the British Standards Institute (BSI) technical committees responsible for developing ISO resilience standards. He has published many thought provoking articles and a book chapter endorsing the importance of standards as the foundation for good organisational practice. Eugene is an experienced design engineer, implementer, exercise facilitator, trainer and auditor with internationally gifted credentials.
Listen to the recorded webinar here:
https://youtu.be/2CmWnNtFrcY
Altnix offers IT infrastructure managed services and remote infrastructure management services (RIMS) for Global customers. Streamline your IT infrastructure management and operations using tools, processes and 24x7 support from Altnix.
ITIL is a set of best practices for managing IT services, development, and operations consisting of a series of books. A service desk provides a single point of contact for users and IT to improve customer service and support incident management, problem management, request fulfillment, and access management processes. An effective service desk is structured and staffed appropriately with trained personnel to resolve incidents quickly and at a low cost while meeting customer satisfaction metrics.
This document provides an overview of capacity management processes and concepts. It discusses key ITIL processes like incident management, problem management, change management and others. It then focuses on capacity management, describing the different levels of capacity planning from business to service to component. The document outlines the key activities, roles and artifacts of a capacity management process. It also discusses concepts like capacity planning, storage capacity planning and capacity models.
The document discusses the stages of change management including being oblivious to change, aware of change, announcing change, authorizing change, scheduling change, and verifying change. It describes the main aims of change management as ensuring standardized methods and procedures are used to efficiently handle changes while minimizing their impact. Benefits include evaluating risk, identifying required changes, maintaining change records, and ensuring changes are implemented with minimal disruption. Key roles in change management are identified.
Forget Big Data. It's All About Smart DataAlan McSweeney
This proposes an initial smart data framework and structure to allow the nuggets of value contained in the deluge of largely irrelevant and useless data to be isolated and extracted. It enables your organisation to ask the questions to understand where it should be in terms of its data state and profile and what it should do to achieve the desired skills level across the competency areas of the framework.
Every organisation operates within a data landscape with multiple sources of data relating to its activities that is acquired, transported, stored, processed, retained, analysed and managed. Interactions across the data landscape generate primary data. When you extend the range of possible interactions business processes outside the organisation you generate a lot more data.
Smart data means being:
• Smart in what data to collect, validate and transform
• Smart in how data is stored, managed, operated and used
• Smart in taking actions based on results of data analysis including organisation structures, roles, devolution and delegation of decision-making, processes and automation
• Smart in being realistic, pragmatic and even skeptical about what can be achieved and knowing what value can be derived and how to maximise value obtained
• Smart in defining an achievable, benefits-lead strategy integrated with the needs business and in its implementation
• Smart in selecting the channels and interactions to include – smart data use cases
Smart data competency areas comprise a complete set of required skills and abilities to design, implement and operate an appropriate smart data programme.
A template for capturing the overall high-level business requirements and expectations for business solutions with a significant impact on or requirement for data. (cf. the “Project Mandate” document in PRINCE2).
Your Challenge
It is difficult to start the project, engage the right people, and find the necessary requirements to drive the value of an enterprise architecture operating model.
It is challenging to navigate the common enterprise architecture (EA) frameworks and right-size them for your organization.
The EA practice may struggle to effectively collaborate with the business when making decisions, resulting in outcomes that fail to engage stakeholders.
Our Advice
Critical Insight
The benefits of an EA program are only realized when all components of the operating model enable the achievement of the program goals and objectives. Many times organizations overplay the governance card while ignoring the motivational aspects that can be addressed through the organization's structure or stakeholder relations.
Info-Tech’s methodology ensures that all components of an EA operating model are considered to optimize the performance of the EA program.
Impact and Result
Place and structure your EA team to address the needs of stakeholders and deliver on the previously created strategy.
Create an engagement model by understanding each relevant process of COBIT 5 and make stakeholder interaction cards to initiate conversations.
Recognize the need for governance and formulate the appropriate boards while considering various policies, principles, and compliance.
Develop a unique architecture development framework based on best-practice approaches with an understanding of the various architectural views to ensure the creation of a successful process.
Build a communication plan and roadmap to efficiently navigate through enterprise change and involve the necessary stakeholders.
This document provides guidelines for Wedgewood Inc.'s incident management process. It describes the process goals as restoring normal service operation quickly and minimizing business impact from incidents. Key activities are identified as incident identification and classification, initial support, investigation and diagnosis, resolution and recovery, and closure. Roles and responsibilities are defined for various positions along with metrics for monitoring process performance.
Resource Paper of Enterprise-Wide Deployment of EDMGlen Alleman
The acquisition of an Enterprise–wide software system requires careful planning and execution of a multitude of activities unrelated to the actual software systems being deployed.
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
http://flevy.com/browse/business-document/itil-incident-management-workflow--process-guide-3020
DOCUMENT DESCRIPTION
This document establishes an Incident Management (IM) process according to ITIL v3 best practice and ISO 20000. (Word document including Visio diagram of the process)
This document introduces the Incident Management process Framework; the workflow, roles and responsibilities, RACI Matrix, KPIs, metrics, procedures, and policies needed to implement a high quality process.
Document contains suggested templates for:
Incident Life-cycle stages
Prioritization Matrix
Categorization
Incident Closure codes
Functional and Hierarchic Escalation Matrix
Major Incident Procedure
Reporting
The document describes an upcoming seminar on ITIL Foundation Certification. It will provide an overview of IT Service Management and ITIL, including the key concepts and areas of ITIL. Attendees will learn about the ITIL service lifecycle and why organizations implement ITIL. The seminar will also help prepare attendees for the ITIL Foundation Certification exam.
It Service Management Implementation OverviewAlan McSweeney
This document describes an IT service management framework and implementation. It discusses ITIL/ITSM and the service management processes including incident and service request management. It provides an overview of the incident and service request management process including its principles, relationships between processes, and detailed processes. The document emphasizes that implementing service management requires understanding why it's being done, what resources are needed, and should be done in phases.
Application Management & Support Best PracticesJulie Champagne
In today’s healthcare IT environment, it takes a lot of support and coordination – of highly skilled and experienced technical staff – to keep a modern healthcare organization running smoothly. When a HCO considers outsourcing any portion of their IT operation, there are many unknowns and considerations to assess. This webcast will present best practices and processes in both exploring an application management support solution or partner and rollout, transition and implementation. Whether supporting a legacy or production application, the solution or partner should take complex and time-consuming tasks off of the organizations plate, allowing focus on more productive, strategic, operation improving and patient experience enhancing activities.
How to build an integrated and actionable IT Service Catalogmboyle
This presentation provides a lower level of detail on how to build a n IT service catalog than provided by ITIL V3. It augments thinking in this area based on 25 years of building Service Catalogs
The document summarizes the objectives, process, roles, and activities involved in a Solution Architecture Concept workshop. The workshop is intended to define the scope, components, and architectural overview of a proposed IT solution by bringing together stakeholders to develop a shared understanding of business needs and technical requirements. Key parts of the workshop include preparation activities, a two-day session to discuss business/functional and technology/implementation views, and documentation of findings.
The document provides an overview and comparison of three major IT governance frameworks: ITIL, COBIT, and ISO 27001. ITIL focuses on IT service management and was originally developed by the UK government. COBIT is aimed at regulatory compliance and risk management. ISO 27001 contains information security standards and guidelines. Each framework takes a different approach, with ITIL emphasizing processes, COBIT control objectives, and ISO 27001 information security practices. Implementing the frameworks requires consideration of factors like organizational needs, budgets, and vendor expertise.
The document provides an overview of the ITIL 4 Foundation course mind map. It summarizes the key topics covered in the ITIL 4 Foundation certification including general management practices, service management practices, creating service value, the service relationship model, external factors, the service value system, the service value chain, service value streams, and the ITIL overview. It also includes an example case study of how ITIL principles could be applied at a car rental company.
Historically, IT operations management (ITOM) teams have been focused on system health and up-time, while separately, IT service management (ITSM) teams manage and remediate end-user issues. The silos between these two functions have spurned challenges that can be overcome with improved integration, collaboration, and transparency across practices. ITSM and ITOM teams are working toward the same goals of up-time, accessibility and improved customer experience. So why can’t they integrate better for delivering on these objectives?
In this presentation, we explore:
The cause and business impact of silo'ed ITSM and ITOM practices
The benefits of improving integration, collaboration, and transparency across practices
Ways for you to exploit the inefficiencies and key metrics you can present the business in advocating for a better solution
And, we’ll introduce the solution of platform thinking, where silos are broken down between IT practices, and technology is operated and managed as a unified front with an open framework of adaptability.
Learn how to present a better solution for improving IT efficiencies, delivering improved customer experience, and enabling innovation throughout your organization, by bringing ITSM and ITOM practices together.
ITOM Platform features to look for if ITSM integration is important to your organization:
SERVICE HEALTH MANAGEMENT: Unified discovery and intelligence, Live asset Inventory, Unified service performance, Visual workflows in service maps
AIOPS MACHINE LEARNING: Intelligent event correlation, Noise suppression, Situational awareness, Incident Response
INTEGRATED TICKETING REQUESTS: Automated Escalations, Comprehensive Incident Collaboration
POLICY AUTOMATION SCRIPTS: Out of the box scripts, Customize scripts
SERVICE REMEDIATION: Enforce Process Governance, Automated Remediation Policies, Secure Infrastructure Access
Learn more at https://www.opsramp.com
Also, follow us on social media channels to learn about product highlights, news, announcements, events, conferences and more:
Twitter - https://www.twitter.com/OpsRamp
LinkedIn - https://www.linkedin.com/company/opsramp
Facebook - https://www.facebook.com/OpsRampHQ/
ITIL and ISO 20000: Fundamentals and necessary compliance SynergiesPECB
The world of Information Technology (IT) is voluminous, fast paced, innovative and very exciting!
You have to love IT to make it work!
To love IT you must live IT, to live IT you must embrace a design for success and understand business impacts from system failures (not just the hardware). To embrace a design for success and mitigate system failures you need a formal structure and independent validation.
This webinar will introduce you to the structure and choices within the ITIL fundamentals (Information Technology Infrastructure Library fundamentals) and a mechanism to validate the performance of the implemented ITIL structure compliant with the ISO 20000 standard (Information Technology -- Service management -- Part 1: Service management system requirements). The object of this webinar is to excite you about a formal IT structure and encourage you to be fearless about independently validating your service management arrangements.
Main points covered:
- Introducing an IT structure for service delivery and a case for IT system validation
- ITIL component options for IT service provision structure
- ISO 20000 as an IT service provision validation mechanism
- Synergy of ISO 20000 requirements and mandatory ITIL components
Presenter:
Eugene is an accomplished high-calibre sustainability and resilience authority, professional engineer and Fellow of the Business Continuity Institute (BCI). With over 25 years of hands-on experience he has developed and improved corporate resilience for a number of organisations from various sectors. His accomplishments include delivery of legislative & regulatory compliance requirements, implementation of ITIL, service, business continuity, information security, quality & risk management systems. In addition Eugene has many years of experience auditing ISO management systems. Eugene has represented the UK Institute of Directors (IoD) on the British Standards Institute (BSI) technical committees responsible for developing ISO resilience standards. He has published many thought provoking articles and a book chapter endorsing the importance of standards as the foundation for good organisational practice. Eugene is an experienced design engineer, implementer, exercise facilitator, trainer and auditor with internationally gifted credentials.
Listen to the recorded webinar here:
https://youtu.be/2CmWnNtFrcY
Altnix offers IT infrastructure managed services and remote infrastructure management services (RIMS) for Global customers. Streamline your IT infrastructure management and operations using tools, processes and 24x7 support from Altnix.
ITIL is a set of best practices for managing IT services, development, and operations consisting of a series of books. A service desk provides a single point of contact for users and IT to improve customer service and support incident management, problem management, request fulfillment, and access management processes. An effective service desk is structured and staffed appropriately with trained personnel to resolve incidents quickly and at a low cost while meeting customer satisfaction metrics.
This document provides an overview of capacity management processes and concepts. It discusses key ITIL processes like incident management, problem management, change management and others. It then focuses on capacity management, describing the different levels of capacity planning from business to service to component. The document outlines the key activities, roles and artifacts of a capacity management process. It also discusses concepts like capacity planning, storage capacity planning and capacity models.
The document discusses the stages of change management including being oblivious to change, aware of change, announcing change, authorizing change, scheduling change, and verifying change. It describes the main aims of change management as ensuring standardized methods and procedures are used to efficiently handle changes while minimizing their impact. Benefits include evaluating risk, identifying required changes, maintaining change records, and ensuring changes are implemented with minimal disruption. Key roles in change management are identified.
Forget Big Data. It's All About Smart DataAlan McSweeney
This proposes an initial smart data framework and structure to allow the nuggets of value contained in the deluge of largely irrelevant and useless data to be isolated and extracted. It enables your organisation to ask the questions to understand where it should be in terms of its data state and profile and what it should do to achieve the desired skills level across the competency areas of the framework.
Every organisation operates within a data landscape with multiple sources of data relating to its activities that is acquired, transported, stored, processed, retained, analysed and managed. Interactions across the data landscape generate primary data. When you extend the range of possible interactions business processes outside the organisation you generate a lot more data.
Smart data means being:
• Smart in what data to collect, validate and transform
• Smart in how data is stored, managed, operated and used
• Smart in taking actions based on results of data analysis including organisation structures, roles, devolution and delegation of decision-making, processes and automation
• Smart in being realistic, pragmatic and even skeptical about what can be achieved and knowing what value can be derived and how to maximise value obtained
• Smart in defining an achievable, benefits-lead strategy integrated with the needs business and in its implementation
• Smart in selecting the channels and interactions to include – smart data use cases
Smart data competency areas comprise a complete set of required skills and abilities to design, implement and operate an appropriate smart data programme.
A template for capturing the overall high-level business requirements and expectations for business solutions with a significant impact on or requirement for data. (cf. the “Project Mandate” document in PRINCE2).
Your Challenge
It is difficult to start the project, engage the right people, and find the necessary requirements to drive the value of an enterprise architecture operating model.
It is challenging to navigate the common enterprise architecture (EA) frameworks and right-size them for your organization.
The EA practice may struggle to effectively collaborate with the business when making decisions, resulting in outcomes that fail to engage stakeholders.
Our Advice
Critical Insight
The benefits of an EA program are only realized when all components of the operating model enable the achievement of the program goals and objectives. Many times organizations overplay the governance card while ignoring the motivational aspects that can be addressed through the organization's structure or stakeholder relations.
Info-Tech’s methodology ensures that all components of an EA operating model are considered to optimize the performance of the EA program.
Impact and Result
Place and structure your EA team to address the needs of stakeholders and deliver on the previously created strategy.
Create an engagement model by understanding each relevant process of COBIT 5 and make stakeholder interaction cards to initiate conversations.
Recognize the need for governance and formulate the appropriate boards while considering various policies, principles, and compliance.
Develop a unique architecture development framework based on best-practice approaches with an understanding of the various architectural views to ensure the creation of a successful process.
Build a communication plan and roadmap to efficiently navigate through enterprise change and involve the necessary stakeholders.
This document provides guidelines for Wedgewood Inc.'s incident management process. It describes the process goals as restoring normal service operation quickly and minimizing business impact from incidents. Key activities are identified as incident identification and classification, initial support, investigation and diagnosis, resolution and recovery, and closure. Roles and responsibilities are defined for various positions along with metrics for monitoring process performance.
Resource Paper of Enterprise-Wide Deployment of EDMGlen Alleman
The acquisition of an Enterprise–wide software system requires careful planning and execution of a multitude of activities unrelated to the actual software systems being deployed.
The document discusses the eDocumentation process for managing changes to policies, processes, and procedures. It describes the four phases of the process: plan, build, implement, and change. It emphasizes that the change phase is important for keeping documentation current and addresses how to track and update policies. It also outlines factors that are important for maintaining documentation easily, such as using templates, styles, subject matter experts, and a style guide. The overall process is meant to streamline maintenance of documentation.
The document discusses software maintenance and configuration management. It emphasizes tracking and controlling maintenance activities in response to change requests. It also discusses identifying configuration items, controlling releases and changes, and recording/reporting status. Configuration management aims to control changes by managing work products, versions, and imposed changes through activities like identification, control, implementation, and reporting of changes.
The document discusses the software development life cycle (SDLC) process, which consists of 7 phases: 1) conceptual planning, 2) planning and requirements definition, 3) design, 4) development and testing, 5) implementation, 6) operations and maintenance, and 7) disposition. It provides descriptions of each phase, from initially identifying a need for a new system through maintaining the system once operational. The document also discusses data flow diagrams, their components, and the process for developing them to model the flow of data in a system. Finally, it includes a project proposal for developing a T-Card game programming project using the SDLC process.
The document outlines 3E's approach to business process management solutions which includes 5 phases: 1) requirements gathering, 2) design and proof of concept, 3) implementation, 4) testing and deployment, and 5) transition including documentation, training, and support. The approach focuses on gathering technical and business requirements, designing workflows, prototyping, prioritizing and implementing functionality, testing, deploying the solution, and transitioning to support.
The document discusses software processes and activities. It describes common process models like waterfall, incremental development, and configuration management. The key activities involved in most processes are specification, development, validation, and evolution. Specification defines system requirements while development includes design, implementation, and debugging. Validation ensures the system meets requirements through testing. Processes also evolve to adapt to changing needs.
This document discusses software configuration management (SCM), including its definition, importance, and typical processes. SCM involves version control, change management, and maintaining the structure and status of a software system. It allows development teams to track changes and releases. The document recommends establishing SCM best practices like using version control and ticketing systems, and automating builds and tests. It notes that SCM tools do not replace other functions like help desk, project management, or personnel systems.
The document discusses Telelogic DOORS and Telelogic Change software for requirements management and change management. Key points:
1. Telelogic DOORS allows visual definition of requirements, management of changes, and traceability between requirements and tests/design/metrics. Telelogic Change provides a workflow for managing changes to requirements.
2. Telelogic Change allows users to implement their own change management process or use out-of-the-box best practices. It provides traceability between requirements and development activities.
3. The software provides customizable workflows for lifecycle change management, reporting and metrics, and managing distributed teams. It integrates with other Telelogic products for requirements-driven development.
Investments in High Availability and Disaster Recovery tools to support business continuity objectives can fall short of the mark when not managed well. Indeed, the presence of such tools can lead to a false sense of security, resulting in complacency in the face of insidious
challenges until it is too late. IT professionals responsible for providing highly available environments to support critical business operations will do well to understand how causes such as configuration drift come about rendering the their plans ineffective and what to do about them.
Software Configuration Management (SCM) involves identifying, organizing, and controlling changes to software components throughout the development lifecycle. The document defines SCM, outlines the SCM process, and describes key SCM activities like configuration control, version control, change management, and configuration auditing. It explains that SCM helps manage different versions of software, ensure quality, and track all changes made to the system.
GENERAL ASSESSMENT QUESTIONS
1.1 QUESTIONS TO ANALYZE THE DEVELOPMENT PROCESS DESCRIPTION
1.2 QUESTIONS TO CHARACTERIZE THE PROJECT APPLICATION
1.3 QUESTIONS TO IDENTIFY THE SUPPORTING TOOLS
2 ASSESSMENT ON CONFIGURATION AND CHANGE MANAGEMENT
2.1 PROJECT/DEVELOPMENT MANAGERS
2.2 DEVELOPERS
2.3 TESTERS
2.4 CONFIGURATION MANAGER
3 ASSESSMENT ON BUILD AND RELEASE MANAGEMENT
3.1 BUILD ENGINEER
3.2 RELEASE ENGINEER
File Can be downloaded from:
http://community.scmgalaxy.com/
This document provides a release management plan for the CMS Net application. It outlines the procedures for packaging and deploying code releases, including naming conventions, prerequisites, and roles and responsibilities. Emergency releases can be expedited if needed to address critical issues. The standard release process involves packaging code, testing, reconciliation steps, and deployment to production by various teams according to the defined responsibilities.
The document provides suggestions for implementing an effective change management process based on ITIL best practices. It recommends establishing extensible workflows, user roles, impact analysis, and auditing to manage the change lifecycle. Key steps include creating templates to track changes, an approval process, change advisory board meetings, and reports to analyze change data and provide oversight of the change management process. Establishing good communication and protocols for notifying users of changes is also suggested.
Software Project Management: Configuration ManagementMinhas Kamal
Software Project Management: ResearchColab- Configuration Management (Document-8)
Presented in 4th year of Bachelor of Science in Software Engineering (BSSE) course at Institute of Information Technology, University of Dhaka (IIT, DU).
This document provides guidance for software testing projects at the California Institute of Technology's Information Management Systems & Services (IMSS). It outlines the philosophy, goals, roles and responsibilities for testing. The testing strategy describes the stages of the testing lifecycle including preparation, unit testing, integration testing, system testing and user acceptance testing. Sample test strategies are provided for upgrading Oracle software and testing a data warehouse. The document also describes testing processes, procedures, documentation requirements and the testing environment.
An explanation of how Release, Change, Configuration, and Project Management work together to coordinate multiple implementations into test and production environments while reducing risk and business impact.
This document is a software requirements specification (SRS) for a project. It includes sections describing the purpose and scope of the project, the overall product functions and users, the operating environment, design constraints, and documentation. The document outlines the intended contents in each section at a high level without providing specific details about the project.
This document is a software requirements specification (SRS) for an unnamed project. It includes sections describing the purpose and scope of the project, the overall description including user classes and operating environment, external interface requirements, key system features and functional requirements, and other nonfunctional requirements. Appendices provide a glossary, any relevant analysis models, and a list of items yet to be determined. The SRS follows standard template headings and outlines the necessary high-level information about project requirements while many lower-level details remain unspecified pending further determination.
Similar to IT Change Management Process Guide & Standards v4.0 (20)
IT Change Management Process Guide & Standards v4.0
1. 1
Preparedby:
Project Sponsor(s):
ITIL Consultant:
Wedgewood, Inc. Contributors:
Date Created:
Date Last Modified:
Edward Pagsanhan
Paul Volkman
StephenReynolds
Douglas Fernandez
Edward Pagsanhan
StephenReynolds
Douglas Fernandez
07.24.2016
09.__.2016
IT Change Management v4.0
Process Guide & Standards
3. 2
DOCUMENT PURPOSE
This document defines the Wedgewood, Inc.’s IT Change Management (CM) process, activities, and accountable roles for the IT
organization.
Planningand adoption of an agreed upon ChangeManagement process (with supportingprocedures and tool enhancement) will assist
in the classification of changes to infrastructure & applications and defines the process & procedures of the change lifecycle. This
document is a guide to be updated as necessary in order to represent the current operational practices of the organization.
VERSION HISTORY
HISTORY LOG
Version RevisionDate Revisedby Description
1.0 7/24/2016 Edward Pagsanhan Initial Document Creation
1.2 8/3 EP Identify and Definingbase process requirements
1.3 8/7 EP Key Controls – Gates and Doc Deliverables
8/8 EP Key Controls – Gates and Doc Deliverables/workflows
1.4 8/9 EP Key Controls/SDLC stages definitions
8/11 EP Key Controls/SDLC stages entry/exit criteria
8/15 EP Key Controls/SDLC stages entry/exit criteria
1.7 8/17 EP Key Controls – Roles & Responsibilities
2.0 8/18 EP Key Controls – Roles & Responsibilities
2.1 8/21 EP Edit Definitions – Key Deliverables (Documents)
8/24 EP Re-Defined Deliverables and R&Rs
8/26 EP Re-Defined Deliverables and R&Rs
2.6 9/02 EP Entry/Exit Criteria defined - Roles & Responsibilities
(To Be Approved)
3.0 9/08 EP Draft v3.0
3.1 9/16 EP Draft edits
4.0 EP
4. 3
TABLE OF CONTENTS
I INTRODUCTION .................................................................................................................... 5
1.1 OVERVIEW...............................................................................................................................................................6
1.2 SCOPEAND APPLICABILITY.......................................................................................................................................7
1.3 DOCUMENT CONTROL AND COMMUNICATION .........................................................................................................8
1.4 PERIODIC REVIEW AND APPROVAL...........................................................................................................................8
1.5 GOVERNANCE &OVERSIGHT....................................................................................................................................8
II GLOSSARY OF TERMS, DEFINITIONS AND ACRONYMS....................................................... 9
2.1 TABLE 1: GLOSSARY.................................................................................................................................................9
III PROCESS FLOW OVERVIEW................................................................................................ 11
3.1 PROCESS NARRATIVE (HIGH LEVEL OVERVIEW)......................................................................................................11
3.2 CHANGE LIFECYCLE: DEFINITIONS ...........................................................................................................................11
3.2.1 Initiate, Assess & Approve – Phase I...............................................................................................11
3.2.2 DESIGN & BUILD –PHASE II......................................................................................................................12
3.2.3 TESTING & QUALITY ASSURANCE –PHASE III............................................................................................12
3.2.4 DEPLOY,VALIDATE &CLOSE –PHASE IV ..................................................................................................12
3.3 ENTRANCEAND EXIT CRITERIA................................................................................................................................13
IV ROLES & RESPONSIBILITIES OVERVIEW............................................................................. 10
4.1 TABLE 2: SUMMARY OF ROLES ...............................................................................................................................14
V THE CHANGE ADVISORY BOARD (CAB)......................... ERROR! BOOKMARK NOT DEFINED.
5.1 CAB – PROCESS OVERVIEW...................................................................................................................................15
5.2 THE EMERGENCY CHANGE ADVISORY BOARD (ECAB)............................................................................................15
5.3 PROCESS EXCEPTIONS ............................................................................................................................................15
VI CHANGE TYPES - THE ITIL NORMAL & EMERGENCY CHANGE MODEL............................. 16
6.1 NORMAL CHANGE TYPE …………………………………………………………………………………………………………..........17
6.1.1 Process Flow Diagram – Normal Change ……………………………………………………………………....17
6.2 EMERGENCY CHANGE TYPE ……......................................................................................................... 18
6.2.1 Process Flow Diagram – Emergency Change…………………………………………………………………..18
6.4 APPROVAL MATRIX………………………………………………………………………………………………………………………. 19
5. 4
VII ADDENDUM 1: PHASES 1 – 4 PROCESS FLOW NARRATIVES.…………………………………………20
7.1 NITIATE, ASSESS & APPROVE – PHASE I.……………………………………………………………………………………………..ERROR! BOOKMARK
NOT DEFINED.
7.1.1 Process Narrative…………………………………………………………………………………………………………..20
7.1.2 Entrance Criteria ……………………………………………………………………………………………………………20
7.1.3 Exit Criteria ……………………………………………………………………………………………………………….....20
7.1.4 Phase 1: Detailed Roles & Responsibilities...…………………………………………………………………..21
7.2 DESIGN & BUILD- PHASE II.………………………………………………………………………………………………….…..……..22
7.2.1 PROCESS NARRATIVE…………………………………………………………………………………………………….……..22
7.2.2 ENTRANCE CRITERIA . …………………………………………………………………………………………………………. 22
7.2.3 EXIT CRITERIA..…………………………………………………………………………………………………………..………22
7.2.4 BASELINE CONFIGURATION..…………………………………………………………………………………….………..... 23
7.2.5 DETAILED ROLES AND RESPONSIBILITIES ………………………………………………………………………………….. 23
7.3 TESTING & QUALITY ASSURANCE –PHASE III ……………………………………………………………………………………….24
7.3.1 PROCESS NARRATIVE ……………………………………………………………………………………………………….....24
7.3.2 Implementation Considerations …………………………………………………………………….………………25
7.3.3 Entrance Criteria…………………………………………………………………………………………………………….25
7.3.4 Rolling or Phased Implementations………………………………………………………………………………..25
7.3.5 EXIT CRITERIA (SUCCESSFUL IMPLEMENTATION)………………………………………………………………………….25
7.3.6 EXIT CRITERIA (UNSUCCESSFUL IMPLEMENTATION)……………………………………………………………………..25
7.3.7 DETAILED ROLES AND RESPONSIBILITIES……………………………………………………………………………………26
7.4 Deploy, Validate & Close – Phase IV..………………………………………………………………………………..………27
Table 10: Change Request Process PHASE IV Overview……………………………………………………………27
7.4.1 Process Narrative ………………………………………………………………………………………………………….27
7.4.2 ENTRANCE CRITERIA..................................................................................................................................27
7.4.3 EXIT CRITERIA ...........................................................................................................................................27
7.4.4 DETAILED ROLES AND RESPONSIBILITIES ....................................................................................................28
VIII ADDENDUM 2: EMERGENCY CHANGE PROCESS................................................................ 29
8.1 DEFINITION &PROCESS NARRATIVE ......................................................................................................................29
8.2 Detailed Roles & Responsibilities ...………………………………………………………………………………….31
6. 5
I Introduction
1.1 Overview
This document, the Change Management Process Guide and standards,is to primarily serve as and focus on establishing
the overall foundation for managingtechnology changes which predominantly support changes made to Infrastructure.
The change management standards encompass all modifications to backup, production servers, applications, networks
and infrastructure services; and changes made by any group that is visible to all other groups – collectively known as
Wedgewood, Inc.’s IT Infrastructure & Operations.
Wedgewood, Inc. acknowledges the risks associated with changes to technology as well as the benefits of controlled
deployment and changeprocesses. Wedgewood, Inc.’s CMProcess Guideand standards documentdefines the company’s
overall approach to managing infrastructure changes and associated risks. The policies, processes, protocols, and
Standards document contained in the CM Process Guide and standards document help protect the company from
business and technology risksby defininga framework thathelps ensurethat technology changes areproperly authorized,
planned, approved and validated by business and IT Leadership where needed.
The purpose of the Change Management process is to ensure that:
Standardized methods and procedures are used for efficient and prompt handling of all changes
All changesto service assetsand configurationitemsare recordedinthe ConfigurationManagement
System (CMS), or the Knowledge Base component of the system of record tool.
The objectives for Wedgewood, Inc.’s technology Change Management processes areto:
Improve service andsupporttoclientsandcustomersbydevelopingandmaintainingsystemsthatare
aligned with strategy, needs, and expectations;
Improve qualityby establishingbaseline controls throughoutthe Change Lifecycle (DEV – QA – Prod)
process;
Improve quality through the application of software quality assurance processes and procedures;
Ensure all infrastructure changes, described below, are approved and that the implications of such
changes are properly considered and planned;
Reduce downstream maintenance costs that result from poorly defined requirements or quality
assurance processes;
Minimize risks to the confidentiality, integrity, and availability of systems and data that may result
from inadequately managed changes; and
Achieve control objectives relevant to the Program Development and Program Change IT general
control domains, thereby facilitating compliance with Sarbanes-Oxley Section 404 requirements.
7. 6
1.2 Scope and Applicability
This document addresses changes to databases,operatingsystems, and network connected devices that fall into one of
the following categories:
1. Any core/production network devices
2. DB servers,
3. Application systems (typically includesconfiguration changes for codelaunch),
4. Security Changes,
5. Has a potential impact on revenue,
6. Requires downtime,
7. Could resultin downtime to internal users,customers and partners,
8. Will changesystemarchitecture and/or monitoringpractices,
9. Will impactother departments or systems.
Exclusions
The policies and processes described in the Change Management Process Guideand Standards document are applicable
to all Wedgewood, Inc.’s employees, Wedgewood, Inc.’s Consultants/Contractors and all aspects of the Wedgewood,
Inc.’s technology environment except for the following areas:
1. Office Machines – common office equipment such as facsimiles, printers, photocopiers, scanners, and
audio/visual devices are not subject to the processes defined in the ICM Standards document.
2. Computer Hardware – Desktop and laptops.
3. Development Infrastructure
4. Staging Infrastructure,
5. Application / Systems production running on end user dedicated desktops (Section 3.4)
6. Building Facilities
7. BuildingAccess Control –The systems and equipment providingcontrol over ingress and egress to Wedgewood,
Inc.’s facilities,such as automatic door locks and closed circuittelevision,arenotsubjectto the processes defined
in the CMPG standards document.
8. Non-Production Systems – Changes to non-production systems and data arenot subjectto the processes defined
in the ICM Standards document.
9. End User Computing Desktop Resources – Changes to end user computing (EUC) desktop tools such as
spreadsheets are not subject to the process defined in the CMPG standards document.
Exclusions Note:
While theseareas are currently not subject to Wedgewood, Inc.’s changemanagementprotocols, it is expected that thebusiness and/or technology
owner(s) of excluded entities and technologies conductallchanges with an appropriate levelofdue care.ITLeadership is permittedto addanyofthe
exclusions above to theChangeManagementprocess as theyseefit. Any questions concerning changes to excluded entities andtechnologies should
be directed to the ITInfrastructure & Operations ChangeManager (aka ITDevOps Program Manager and theDevOps Application Architect).
8. 7
1.3 Document Control and Communication
The CMPG and standards document is subjectto version control and all substantivechanges to the standards document
must be logged in the Revision History Log. All changes to the CMPG standards document must be approved by the
Change Manager and pre-determined IT Leadership (i.e., CIO, Application Development Program Manager, Application
Architect Manager) based on the type of change. All changes must be summarized and communicated to IT staff after
approval.
1.4 Periodic Review and Approval
The CMPG & standards document is evergreen and is updated on an as-needed basis as the people, processes, and
technologies supporting the change. As needed, but at a minimum of once per fiscal year, IT Leadership must inspect
the CMPG & standards document to ensure that it remains current and correctly reflects the processes in use by the
company. Evidence of this review is to be notated in the Revision History Log with any requisite updates.
At the conclusion of the annual inspection of the CMPG & Standards document, the ITLeadership Team must re-assess
and re-approve said document. Evidence of this approval will bedocumented in the Revision History Log,and if needed,
with any relevant supporting emails or other communications attached.
1.5 Governance & Oversight
All members of the IT Leadership team are responsible for adhering to, and enforcing, the standards and processes
defined by the Change Management Process Guide & Standards document within their teams. The acting Change
Managers and IT Senior Management shall providegovernance oversight and responsibility for enforcing policies and
processes. Policies and processes may be enforced through one or more of the following methods:
1) Implementation and use of security and change management software,
2) Periodic complianceauditsperformed by the IT Operations & Infrastructure Managers,the Change Manager or
his/her designee, and
3) Self-assessmentsurveys.
Notation 1: Manage Change - Control Objectives and Activities
Control activities must be implemented to satisfy the relevant Sarbanes-Oxley control objectives. In most cases, management must
be doing something to satisfy the control objective and have tangible evidence to substantiate what actions were taken to verify
that controls operate effectively.
9. 8
II Glossary of Terms, Definitions andAcronyms
The purpose of this glossary is to providean accessiblelistof commonly terms in this CM Process Guide& Standards
document and the definitions behind them.
2.1 Table 1: Glossary
Name Acronym Definition
Baseline
Configuration
Standards
BCS Baselineconfiguration standardsdocumentis theconfiguration standard thatis referred
to as an organization’s “best practices” applied across infrastructure components such
as routers,firewall,switches,servers,databaseservices etc. These form a guide to meet
an organization’s risk matrix.
Change
Advisory
Board
CAB A group of people that advices theChangeManager in the Assessment, prioritization and
scheduling of Changes. This board is usually made up of representatives from all areas
defined in Section 3.3.
Change
Management
CM Change Management is an IT Service Management discipline. The objective of change
management in this context is to ensure that standardized methods and procedures are
used for efficientand prompt handlingof all changes to control ITinfrastructure,in order
to minimize the number and impact of any related incidents upon service. Changes in
the IT infrastructuremay arisereactively in responseto problems or externally imposed
requirements, e.g. legislative changes, or proactively from seeking improved efficiency
and effectiveness or to enable or reflect business initiatives,or from programs,projects
or service improvement initiatives. Change Management can ensure standardized
methods, processes and procedures which are used for all changes, facilitate efficient
and prompt handlingof all changes,and maintain the proper balance between the need
for change and the potential detrimental impact of changes.
Request For
Change
OR
Change
Request
RFC or CR The addition,modification or removal of anything that could effect on IT Services.
Configuration
Item
CI The term configuration item or CI refers to the fundamental structural unit of a
configuration management system. Examples of CIs include individual requirements
documents, software, models, and plans. The Configuration management system
oversees the lifeof the CIs through a combination of process and tools by implementing
and enabling the fundamental elements of identification, change management, status
accounting,and audits.The objectiveof this systemis to avoid the introduction of errors
related to lack of testing as well as incompatibilities with other CIs.
10. 9
Name Acronym Definition
Configuration
Management
Database
CMDB A configuration management database (CMDB) is a repository of information related to
all thecomponents of an information system. Itcontains the details of the configuration
items (CI) in the ITinfrastructure.Although repositories similar to CMDBs havebeen used
by IT departments for many years, the term CMDB stems from ITIL (Information
Technology InfrastructureLibrary).In theITILcontext,a CMDB represents the authorized
configuration of the significant components of the IT environment. A CMDB helps an
organization understand the relationships between these components and track their
configuration. The CMDB is a fundamental component of the ITIL framework's
Configuration Management process. CMDB implementations often involve federation,
the inclusion of data into the CMDB from other sources,such as Asset Management, in
such a way that the source of the data retains control of the data. Federation is usually
distinguished from extract, transform, load (ETL) solutions in which data is copied into
the CMDB.
Critical
Success
Factor
CSF Critical success factor (CSF) is the term for an element that is necessary for an
organization or projectto achieveits mission.Itis a critical factor or activity required for
ensuringthe success of a company or an organization.The term was initially used in the
world of data analysis, and business analysis. For example, a CSF for a successful
Information Technology (IT) project is user involvement.
Incident
Management
IM Incident Management (IM) is an IT service management (ITSM) process area. The first
goal of the incident management process is to restore a normal service operation as
quickly as possible and to minimize the impact on business operations, thus ensuring
that the best possible levels of service quality and availability are maintained. 'Normal
service operation' is defined here as service operation within service-level agreement
(SLA). It is one process area within the broader ITIL Best Practices & Standards
environment.
Key
Performance
Indicator
KPI A performance indicator or key performance indicator (KPI) is a type of performance
measurement. An organization may use KPIs to evaluate its success, or to evaluate the
success of a particular activity in which it is engaged. Sometimes success is defined in
terms of making progress toward strategic goals, but often success is simply the
repeated, periodic achievement of some level of operational goal (e.g. zero defects,
10/10 customer satisfaction, etc.). Accordingly, choosing the right KPIs relies upon a
good understandingof what is importantto the organization.'Whatis important' often
depends on the department measuringthe performance - e.g. the KPIs useful to finance
will be quite different than the KPIs assigned to sales. Since there is a need to well
understand what is important (to an organization), various techniques to assess the
present state of the business,and its key activities,areassociated with the selection of
performance indicators.These assessments often lead to the identification of potential
improvements, so performance indicators are routinely associated with 'performance
improvement' initiatives.A very common way to choose KPIs is to apply a management
framework such as the balanced scorecard.
11. 10
Name Acronym Definition
Known-Error KE In ITOperations known errors may be logged in a system's Known Error Database(KEDB)
which is then used to prioritize changes and to develop customer support reference
information where a work around exists.
Operational
Level
Agreement
OLA An operational-level agreement (OLA) defines the interdependent relationships among
the internal support groups of an organization working to support a service-level
agreement (SLA). The agreement describes the responsibilities of each internal support
group toward other supportgroups,includingtheprocess and timeframe for delivery of
their services. The objective of the OLA is to present a clear, concise and measurable
description of the service provider's internal support relationships.
Request For
Change
RFC The Request for Change (RFC) is formal request for the implementation of a Change. A
Request for Change is to be submitted to Change Management for any non-standard
Change (a set of standard/ routine Changes is usually defined by Change Management;
these are minor Changes which do not require submission to the Change Management
process). A Change is backed by a Change Owner, holding a budget for its
implementation. In many cases the Change Owner is identical with the RFC initiator.
Typically Changes are owned by Service Management roles (e.g. the Problem Manager
or Capacity Manager) or by IT Leadership. The RFC is a precursor to the Change Record
and contains all information required to approvea Change. Further information is added
as the Change progresses through its lifecycle. The level of detail depends on the size
and likely impact of the Change. Often there will be references to further documents
containing more detailed information, e.g. a detailed Change proposal.
Root Cause
Analysis
RCA Root Cause Analysis (RCA) is a method of problem solving thattries to identify the root
causes of faults or problems that causeoperatingevents.
Service Level
Agreement
SLA A service-level agreement (SLA) is a partof a servicecontract where a serviceis
formally defined. In practice,the term SLA is sometimes used to refer to the contracted
delivery time (of the serviceor performance). As an example, internet serviceproviders
will commonly includeservicelevel agreements within the terms of their contracts with
customers to define the level(s) of servicebeingsold in plain languageterms.
Software as a
Service
SaaS Software as a Service is an "on-demand software" supplied by ISVs or "Application-
Service-Providers"(ASPs); is a software delivery model; in which software and
associated data arecentrally hosted on the cloud.
12. 11
III Process Flow Overview
3.1 Process Narrative Overview
The process for managing changes to infrastructure has been designed to ensure that changes to the IT Operations
production, corporate network and applications areof minimal impact to productivity and revenue streams . The four
phase process for managing technology is depicted below.
Table 2: Change Request Process Phase Overview
3.2 Change Lifecycle: Definitions (Phases 1 – 4)
3.2.1 Initiate, Assess & Approve – Phase I:
Change Requests (CRs) for IT projects are generally initiated through but are not limited to via email. These
are logged/documented into the system of record (KACE), and proceed to the SPRINT PLANNING MEETING
where they are:
1) Assessed and designated a change Type,
2) Assigned a Change Type grade based on the level of urgency using a pre-defined set of
criteria/parameters,
3) Assigned to IT development support staff to vet the scope of effort, and
4) Approved a tentative release date on an upcoming Sprint Schedule within the Change Management
module.
5) Technical requirements for the change are defined, documented, and approved, helping to ensure
Infrastructure changes are defined to minimize risk to the production environment.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Build Phase:
Solution design &
implementation plan
Test/QA Phase:
Test Plan execution
Deployment Phase:
Implementation,
validation & closure
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Build Phase: Test/QA Phase: Deployment Phase:
13. 12
3.2.2 Design & Build – Phase II: (Weeks 1 thru 2 of Sprint Cycle)*
1) Technical owners scope the effort and proceed with the design solution/dev plan for the change(s),
2) Develop implementation and rollback strategies, and
3) Perform all activities attesting to a successful build has been completed and documented
* (Key Control gate & deliverable due)
3.2.3 Testing & Quality Assurance – Phase III: (Weeks 2-4 of Sprint Cycle) *
Execution of technical tests in test environments. Testing/Validation activitiesareperformed followingthe
defined Test Plan and Scope approved duringthe prior 2 phases.
* (Key Control gate & deliverable due)
3.2.4 Deploy, Validate & Close – Phase IV: (Week 4 - Production) *
1) Infrastructure changes are implemented into production.
2) Validation procedures are performed to ensure the change is working properly.
3) The change is validated and the change request is closed.
* (Key Control gate & deliverable due)
Asessment Phase: Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Asessment Phase: Build Phase:
Test/QA Phase:
Test Plan execution
Deployment Phase:
Asessment Phase: Build Phase: Test/QA Phase:
Deployment Phase:
Implementation,
validation & closure
14. 13
2.3 Entrance and Exit Criteria – High Level Overview
Entry and exit criteria are defined for each stage. These criteria allow the project manager, as applicable, to
communicate the status of a project by phase. A project must generally meet all entrance criteria prior to entering a
phaseand generally meet all exitcriteria prior to transitioningto the next phase. The specific entry and exit criteria for
each phase are defined in detail in later sections of this document.
15. 14
IV Roles and Responsibilities Overview
4.1 Table 3: Summary of Roles
Role Descriptions
Business Subject Matter
Experts (SME)
(Project Managers,
Business System Analysts,
Application Developers,
QA/Test resources,etc.)
Individuals with extensive knowledge of Wedgewood, Inc.’s business processes and
how computer systems support those processes.
Business SMEs help define business requirements as well as defining and executing
user acceptance test scenarios. The Project Manager may represent the Change
Request during the design assessment (Sprint Planning) and release approval (Sprint
Go/No Go or CAB) as the SME as well.
IT Program Manager,
Application Architect
(acting Change Manager)
The individual assigned overall responsibility for defining, communicating,
implementing, and monitoring the company’s IT Change Management policies and
processes.
Requestor An individual or group requesting a change to systems or data. The Requestor may
also acton behalf of a tester as applicable. Additional duties may includetestingsign-
off for a vendor or business unit. TheProject Manager may represent as the Requestor
as times as well.
Implementer
The individual(s) responsible for implementing changes to production systems and
data.
IT Leadership and Team
Managers
The individual with overall day-to-day responsibility for managing the development of
program and or infrastructure changes.
IT Staff/IT Resource The individual assigned day-to-day responsibility for managingthe development of a
system or data change. The IT Staff or Technical Owner may also acton behalf of a
tester and or as applicablesign-off for a vendor.
16. 15
V SPRINT Go/No Go (Change Advisory Board)
5.1 SPRINT Go/No Go (aka Change Advisory Board or CAB) – Process Overview
RFCs or CRs sent to the Change Advisory Board (CAB), or otherwise referred to as the Sprint Go/No Go meeting, must
be approved after:
1) The appropriate assessment and approval in the Sprint Planning Review, followed by
2) Scheduling in a Sprint release calendar,
3) Has successfully completed the appropriate testing within the defined test scope, and,
4) Has met all deliverable due dates throughout the Sprint Cycle accordingly.
5.1.1 CAB Members & Stakeholders
The CAB or SPRINT Go/No Go sessions meets once per Sprint Cycle(4 weeks) basis to review all approved and
scheduled change requests, change dependencies and status of future, current or past changes. The CAB is
comprised of the followingmembers and is responsiblefor the communication back to the appropriateteams
and or business areas, as needed:
Change Manager, DevOps Manager/Lead, Application Architect/Dev Ops Technical Lead, Testing Leads (DevOps
BSAs, the CIO, etc.)
5.1.2 Process Owner & Facilitator
Facilitated by the DevOps Program Director (can be referred to as the IT Change Manager) on a regularly
scheduled basis. The CAB or Go/No Go approval is provided by the following:
The CIO,DevOps ProgramManager Enterprise Application Architect,DevOps BSAs, other ITLeadership or their
delegates.
5.2 The Emergency Change Advisory Board (ECAB)
Leveraged as an escalation path or expedited process for Changes to Production that requireto be deployed outsideof
the normal pre-defined lead time requirements.
The Emergency Change Advisory Board is a group called together by the Change Manager to act as decision makers on
ALL changes that are categorized as emergency. This group usually meet virtually as the nature of emergency change
means that it has been be agreed and authorized immediately.
** See Section 8, Addendum 2: Emergency Change Process (page 29)
5.3 Process Exceptions
The protocols for managingexceptions will be included in subsequent versions of the CMPG & Standards document and
will include the following areas, at a minimum:
Separation of duties conflicts,
Required deliverables are not prepared,
Required sign-offs or approvals are not received,
Overrides of implementation go/no-go decisions,
Non-emergency changes that must occur outside of release cycles, and
An adequate QA environment is not available for testing.
17. 16
VI CHANGEREQUEST Types – The ITIL Normal & Emergency Change Model
Different types of IT projects and infrastructure changes are categorized based on factors such as project size, number of
impacted systems, and overall risk to the organization. The type categories help to further clarify the scope of the policies
and processes defined by the CMPG & Standards document.
In terms of process scope,most Changes fall squarely in the middle of the Change Management process.Once the process is
in place, the tools have been deployed, these types of changes rarely present significant issues.
However, the key to a successful and effective Change Management program lies in the ability of the process to handlethe
changes which occur around the edges of the process scope – not just the middle.
A few examples:
How can we handle instances when a System Administrator needs to make a change to a setting on a
server? Doesthatfall withinthe scope of the ChangeManagementprocess,ordowe viewthisas routine
operational “tuning”?
How do we treat desktop moves (i.e. moving an employee to a new office or cube)?
What procedurestoleverage whenthere isaneed to increase the allocatedspace ona shareddrive (i.e.
enterprise storage)?
ALL of these changes are likely to be included in the scope of the process.
The problem with such a zero tolerance approach to unauthorized/uncontrolled change is that it has the potential to be
unwieldy and rigid. The IT Changes listed above occur on a (more or less) constant basis in most organizations, and the
suggestion that each instance would require a formal approval process is likely to bring the IT staff a constant and ever
increasing influx of unneeded effort.
Implementing ITIL’s base Standard Change Management Model (Normal, Standard, and Emergency) provides a solution in
eliminating bureaucracy, while streamlining the process.
18. 17
6.1 TYPE CHANGE
Change Requests that is not an EMERGENCY type and follows all thePhases and activities defined in the Wedgewood, Inc.’s
IT Change Management lifecycle process.
6.1.1 Process Flow Diagram – Normal Change
19. 18
6.2 EMERGENCY TYPE CHANGE
Classified as typically a Normal change deemed to be urgent and required to be implemented as soon as possible.
Essentially, it will follow the same process as the normal changes, but will be adapted to the emergency situation. If the
CAB cannot meet quickly,the ECAB, havingthe authority level needed to make decisions,will beinvoked. Testing must be
carried outas much as possible,and documentation of change and configuration data may be completed later (example of
urgent changes: solving a major incident, deploy an urgent security patch, etc.).
6.2.1 Process Flow Diagram – Emergency Change
20. 19
6.3 Approval Matrix
Table 4: Approval Matrix
Responsibilities
BusinessSubjectMatterExpert
(SME)
ProgramDirectororChange
Manager
Requestor
Implementer
ITLeadershiporManager
ITStaff
TechnicalOwner
TechnicalPeer
Normal Change
Change Requests that is not an EMERGENCY type
and follows all the Phases and activities defined
in the Change Management lifecycle process.
This CR type normally includes application new
functionalities, enhancements, calculation
changes and production fixes. This change type
requires IT Manager approval and release
scheduling prior to coming to the SPRINT Go/No
Go (or CAB).
X P X X P X X X
EmergencyChange
Immediate action is required to counter an
emergency, to avert great damage to the
business. System modifications necessary to
comply with legal and regulatory requirements
may also be considered emergencies.
An EmergencyChange mayalsobe basedonthe
critical functions of the business and can be
deemed an emergency once appropriately
reviewed. This change type requires IT Manager
approval prior a CAB member signature.
X P X X P X X X
P = Primary Responsibility
S = Secondary Responsibility
X= Incompatible;separation of duties
conflict
21. 20
VII Addendum: Phases 1 – 4 Process FlowNarratives
7.1 Initiate, Assess & Approve – Phase I
Table 5: Change Request Process Phase I Overview
7.1.1 Process Narrative
Initiateand Assess is the firstphase of the InfrastructureChange Management process. During this requests
for IT projects are generally initiated through the use of a technical work request, but are not limited to other
means i.e. email or other. Requests areassessed and if considered priorities,assigned to IT staff and assigned
tentative dates on an implementation calendar within the Change Management module. Technical
requirements for the changearedefined, documented, and approved,helpingto ensure Infrastructurechanges
are defined to minimize risk to the production environment.
Initiation – Changes, Technical Work Requests are resolutions or enhancements to application and or
infrastructure and are received in one of two ways:
7.1.2 Entrance Criteria
Change Request (CR) TFS Record /Change Requests formally Change Request is listed in agenda of the
SPRINT PLANNING MEETING for assessmentand approval considerations.
TFS (Document of Record) is updated.
7.1.3 Exit Criteria
Change Request formally submitted and documented in TFS. Change Request has been reviewed and
approved via SPRINT PLANNING MEETING
Tentative Release Schedule is assigned.
TFS (Document of Record) is updated.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation,
validation & closure
22. 21
7.1.4 Phase 1: Detailed Roles and Responsibilities
Any listed table steps below are not mandatory and may be used or not used based on the discretion of IT
Leadership and type of change;
Table 6: Phase I – Initiate and Assess
Responsibilities
BusinessSubjectMatter
Expert(SME)
Program
Director/Change
Manager
Requestor
Implementer
ITLeadershipor
Manager
ITStaff
TechnicalPeer
Phase I – Initiate and Assess
Identifyproductionproblemsandor
changeswanted to productionand
documentproductionchange needsan
Incident,Request,Projectsandor
Problems
S S P S
Manages andorganizesall requests S P S
Assessesrequestsforcosts,benefits,and
otherfactors
S P
Authorizesandprioritizesrequestsfor
development
S P
Cancels/Deferschange requests P S
TentativelyassignsRequeststothe
release calendar
S S P
Documentsa projectplan S P
Participatesinthe gathering of business
requirements
P S S
Documentsbusinessrequirements S S S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separationof duties
conflict
23. 22
7.2 Design & Build – Phase II
The second phase of the Change Management process in which, business and technical requirements for changes
are defined, documented, helping to ensure that design efforts are properly focused and changes to scope in later
phases are minimized. The detailed steps of this process are described below.
Table 7: Change Request Process Phase II Overview
7.2.1 Process Narrative
PhaseII of the lifecyclewhere the Technical owners scope the effort and proceed with the design solution,
development plan, map out the implementation plan and roll back strategies for the change(s). This
includes review of all activities that attests to a successful build has been completed and documented.
7.2.2 Entrance Criteria
Change Request record APPROVED
Scheduled on RELEASE CALENDAR (Sprint Cycle)
TFS (Document of Record) is updated
7.2.3 Exit Criteria
Completed Design/Dev Plan
Defined impact,Test Plan,Rollback Plan (if applicable)
TFS (Document of record) is updated
7.2.4 Baseline Configuration Standards
To meet the demand for high security and performance, baselineconfiguration standardsmay existfor all
Infrastructure components but is change dependent. Depending on the nature of the Infrastructure
change, updates to these baselineconfiguration standardsmay be required. Infrastructuregroups should
discusspendingchanges with ITLeadership and other relevant groups,ensuringthatbaselinestandardsare
updated, if appropriate.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation,
validation & closure
24. 23
7.2.5 Detailed Roles and Responsibilities
Table 8: PHASE II Roles & Responsibilities
Responsibilities
BusinessSubjectMatter
Expert(SME)
DevOpsProgramManager
orChangeManager
Requestor
Implementer
ITLeadershiporManager
TechnicalOwner
TechnicalPeer
Phase II – Design
Designs/configureschange intest lab
P S
DocumentsImplementationand
RollbackPlan P S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separationof duties
conflict
25. 24
7.3 Testing & Quality Assurance – Phase III
Table 9: Change Request Process Phase III Overview
7.3.1 Process Narrative
Implement is the fourth phase of the Infrastructure Change Management process. During this phase, changes
are implemented into production according to an established set of implementation procedures. Technical
validation occurs to help ensure the change is implemented properly. The detailed steps of this process are
described below.
Successful Implementation (Testing and/or Staging environment) Steps:
Notify Impacted Groups of Pending Implementation – The Implementer works with the appropriate
teams who then notify the impacted business and ITgroups of the pending implementation as defined
in the Implementation and Rollback Plan.
Implements Change into Production – The Implementer installs thechange into production as defined
in the Implementation and Rollback Plan.
Technical Validation – The Implementer executes the technical validation procedures defined in the
Implementation and Rollback Plan. If change is not a success Implementer goes to the steps for an
unsuccessful implementation.
Unsuccessful Implementation (Testing and/or Staging environment) Steps:
Resolve/Rollback –Dependingon the severity of any issues experienced,the Implementer firstattempts
to correct any related problems that can be corrected during the defined implementation window. If
the change cannot be resolved, the Implementer removes the change from production using the
procedures defined in the Implementation and Rollback Plan. If the change cannot be removed from
production, the emergency change process is initiated.
Notify Impacted Groups of Failed Implementation – Implementer works with the appropriate teams
who then notify the impacted business and IT groups of the implementation failure as defined in the
Implementation and Rollback Plan.
Perform Root CauseAnalysis –The Implementer logs any defects that are attributableto program code.
The Technical Owner manages a root cause analysis process to identify the source(s) of problems
encountered with the implementation.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation, validation
& closure
26. 25
7.3.2 Testing Considerations
If non-code related issues are encountered during the implementation, the Implementer should work
to resolveany issues and testthe change’s implementation plan,provided the issue(s) can beresolved
within the defined implementation staging window. Significant troubleshooting efforts should be
recorded.
7.3.3 Entrance Criteria
Defined Test Plan
Resource has been identified and assigned to execute Test effort.
7.3.4 Rolling or Phased Implementations (Staging environment)
The Implementation and Rollback Plan for some Infrastructure changes, such as deploying service
packs to company’s desktops, may define a rolling or phased implementation process whereby the
change(s) are firstdeployed to a subset of Infrastructurecomponents, evaluated, and then deployed
to a broader group. Such deployments may not always occur during the same implementation
window/timeframe.
After deployment authorization is received, Infrastructure groups should execute against the
approved Implementation and Rollback Plan.Additional approval is reviewed on a caseby case basis
and may be required for subsequent phases of the implementation, although the notification
requirements documented in the Strategy must be met throughout the process.
7.3.5 Exit Criteria (Successful Implementation)
Resultsare logged(includedwithChange Record –TFS)
7.3.6 Exit Criteria (Testing environment - Unsuccessful Implementation)
Results are logged (included with Change Record – TFS)
Notification of test results to ProgramManager, DevOps Lead, CIO, Change
Requestor, etc.
Assessment for re-testing, OR re-scheduling.
27. 26
7.3.7 Detailed Roles and Responsibilities
Table 10: PHASE III Roles & Responsibilities
Responsibilities
BusinessSubjectMatterExpert
(SME)
DevOpsProgramManageror
ChangeManager
Requestor
Implementer/TStaff/IT
LeadershiporManager
TechnicalPeer
Phase III - Implementation
Notifiesimpactedgroupsof
pendingimplementation S S P
Implementschange into
production
X X X P
PerformsTechnical Validation P S
Resolvesimplementation
issuesorexecutesrollback
procedures
X X X P S
Notifiesimpactedgroupsof
successful/failed
implementation,if applicable
P
Performsrootcause analysis,if
applicable S S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separation of
dutiesconflict
28. 27
7.4 Deploy, Validate & Close – Phase IV
Table 10: Change Request Process PHASE IV Overview
7.4.1 Process Narrative
Validate and Close is the fourth and final phase of the Infrastructure Change Management process.
Duringthis phase,a Business representativeand or ITStaff validates changes to help ensuretherequired
functionality operates correctly in production and that primary controls continue operate effectively.
The detailed steps of this process are described below.
Execute and Document User Validation – If RCA is considered necessary,the IT Manager may consider
the potential risks to application functionality and controls. If necessary, the IT Manager or delegate
coordinates user validation efforts with Business SMEs that help verify that the change does not
introduce application errors. Any issues noted during this process are logged as problems in problem
tickets and managed through the problem management process unless otherwisedeemed unnecessary
from IT Leadership. Otherwise, the request is closed by the IT Staff or Technical Owner.
Document Functional Acceptance – The IT Manager or designated IT Staff or Peer, where necessary,
evaluates the user validation test results and formally documents final acceptance of the change.
Close Change – The Technical Owner closes the Change.
7.4.2 Entrance Criteria
Testing has been fully executed and validated successfully.
Implementation (Production Environment) Plan defined.
7.4.3 Exit Criteria
Document of record (TFS) updated and state is updated to “CLOSED”.
Lessons Learned meeting summary, as applicable.
Asessment Phase:
Functional Design
Specification review &
RFC Classification
Design & Build
Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation, validation&
closure
29. 28
7.4.4 Detailed Roles and Responsibilities
Table 12: Phase VI: Validate and Close
Responsibilities
BusinessSubjectMatterExpert(SME)
DevOpsProgramManagerorChange
Manager
Requestor
Implementer
ITLeadershiporManager
ITStaff
TechnicalOwner
TechnicalPeer
Phase IV - Validate and Close
Determinesif UserValidationis
necessary
S S
ExecutesUserValidation P P S
Acceptschange,approvingUser
Validation
P
Closes Change S P S S
ConductsLessonsLearned
meeting,asneeded
S P S
P = Primary Responsibility
S = Secondary Responsibility
X = Incompatible;separationof
dutiesconflict
30. 29
VIII Emergency Change Process
Emergency changes result from production problems or other events and require immediate resolution.
Emergency changes areconsidered so importantthat the company’s risk toleranceis increased and a willingness
to implement changes that may not be fully defined and approved by the business or adequately tested exists.
Emergency changes may occur in one of the following scenarios:
1) A production problem that needs immediate action to counter or avert great damage to the business.
2) An unsatisfied legal or regulatory requirement exists and non-compliancepresents immediate issues to the
company.
8.1 Definition & Process Narrative
The Emergency Change process describes how the company manages changes that must be immediately
implemented to address a production problem or other issue. Requirements definition processes aregenerally
less rigorous for these changes due to the compressed timeframe. The detailed steps of this process are
described below.
Identify – Production problems are identified and logged as Change Request (TFS) through the change
management process. *
Investigate – IT staff / Technical Owner investigates the causeof the problem(s) and define a solution to address
the incident / problem or its symptom(s).
Review Proposed Solution – A Technical Peer reviews the proposed solution,contributingideas and challenging
the approach presented by the Technical Owner.
Approve Change – The Emergency Change is approved by the appropriate IT Management/resource (DevOps
BSA, Service Desk Leads, Applications Architect or Lead) alongwith the ProgramManager (Change Manager) or
IT Leadership.
Implement – If the changeis considered ready for production,the changeis implemented into production by the
Technical Owner immediately.
Validate – A Subject Matter Expert and or IT Staff validates thechange for the emergency and verifies that issue
have been corrected. If the emergency condition persists, the solution is re-visited and the process returns to
the Investigate stage.
Update and Close Change Request record (TFS) – The IT Staff / Technical Owner updates and closes the change
request. **
Root Cause Analysis – Whenever needed, the IT Staff performs a root causeanalysisof the issues thatresulted
in the emergency. If the solution implemented to address an emergency only corrects problem symptoms,
and not the root causeof the problem, a Technical Work Request must be opened to correct the root
cause followed by another Change Request to put into Production.
Post-Emergency Assessment – Whenever needed, the IT Leadership and Change Manager conducts a post-
emergency assessmentto gain an understandingof the issues encountered and the root causes of the issueas
well as to determine if additional design is required to correct other issues or further stabilize the system.
* During “urgent” Emergency circumstanceswhere timeisof the essence, changeswill go through the normal expedited
processand documentation effortscan be executed afterwards.
** Can be performed “after” emergency change hasbeen deployed/implemented into the Prod system.
31. 30
8.2 Detailed Roles and Responsibilities
Table 13: Emergency Changes – Detailed Roles and Responsibilities
Responsibilities
BusinessSubjectMatter
Expert(SME)
DevOpsProgramManager
orChangeManager
Implementer
ITLeadershiporManager
ITStaff
Phase IV - Validate and Close
Identifiesproductionemergencies P P
Investigatesproductionemergencies S P
Reviewsproposedsolution(s) S S
Approvesemergencychanges P P
Implementschange inproduction X X
Validateschange in production P P
Update and Close Change Request S
Post-EmergencyAssessment P P S
P = Primary Responsibility
S = Secondary Responsibility
X = Incompatible;separationof duties
conflict