变更管理ITIL模块

变更用于记录IT中计划的所有修改：

• 补丁的安装
• 系统配置的更改
• 操作系统更新
• 软件安装

这样，您可以跟踪IT内进行的所有修改。很多事件是由于对IT环境所做的更改而引起的。通过记录它们，您可以轻松识别事件发生和复原服务发生时进行了哪些更改。

此外，此变更管理模块允许您自动分析影响度的基础架构和应用解决方案的更改。然后，IT工程师可以改善控制企业关键服务的可用性以及改进客户满意度的可用性。

更改由具有以下简档（角色）的人员管理：

• 变更实现者计划并实施更改
• 变更主管跟踪更改
• 变更经理批准更改

安装iTop时，可以在两个不同的模块之间进行选择，以记录更改。此处描述的模块经过设计，可以通过三种更改来实现ITIL V3变更管理：

• 例行公事的更改
• 正常变化
• 紧急变更

这三种类型的更改之间的差异依赖于它们各自的工作流。

与变更管理相关的团队或代理不需要任何特殊的限制配置。但是，请记住，通常会受到安全的限制：验证工单的气体签名时要选择的团队联系人必须位于允许用于当前用户的组织中。

紧急变更

ITIL紧急变更是可以在组织中定义的最高优先级变更。紧急更改被定义为需要在短时间内进行评估，评估以及拒绝或批准的更改。仅将变更定义为紧急情况并不能自动实现变更的实现。紧急变更咨询委员会（ECAB）将评估变更并向负责批准或拒绝紧急更改的受委托人提供建议。

紧急变更属性

标签

创建一个紧急变更

点击“ New变更”菜单：

然后在下面的表单中选择“紧急变更”：

然后单击“应用”以显示紧急变更创建表单：

紧急变更生命周期

紧急变更对象具有以下生命周期：

对象的状况上的依赖，其属性上的矛盾之处如下表所示：

表键：

• H：隐藏
• RRO：只读
• M：必填

一般变更

ITIL一般变更是指必须遵循完整的变更管理流程进行的更改。根据定义，一般变更将继续执行变更管理流程的所有步骤，并最终由变更咨询委员会（CAB）进行审查。 CAB将向被认为负责批准或拒绝正常更改的人员提供有关一般变更的建议。

一般变更属性

标签

创建一个一般变更

点击“ New变更”菜单：

然后在下面的表单中选择“一般变更”：

然后单击“应用”以显示一般变更创建表单：

一般变更生命周期

一般变更对象具有以下生命周期：

对象的状况上的依赖，其属性上的矛盾之处如下表所示：

表键：

• H：隐藏
• RRO：只读
• M：必填

标准变更

ITIL例行公事（标准）变更非常简单地指的是预先批准的更改。可以为各种任务定义预先批准的更改，但是它们通常是较低的风险，即省力的更改，其成本较低或已知。

标准变更属性

标签

创建一个标准变更

点击“ New变更”菜单：

然后在下面的表单中选择“标准变更”：

然后单击“应用”以显示标准变更创建表单：

标准变更生命周期

标准变更对象具有以下生命周期：

对象的状况上的依赖，其属性上的矛盾之处如下表所示：

表键：

• H：隐藏
• RRO：只读
• M：必填

将用户请求分配给团队和处理人员

分派和变更可以加入的团队列表由相应的组织的交付模式定义。创建变更时，处理人员必须选择变更组织，然后，团队列表严格限于为此变更定义的团队。如果缺少团队，则必须更新变更的交付模式以反映此需求。有关更多信息，请参见有关交付模式的更多信息。

管理内部留言

变更工单仅具有一个内部留言来记录所有活动及其相关的通信。用户门户末端看不到这一条。

管理受影响的配置项和联系人

此部分类似于帮助台模块之一。请参考

原贴链接：https://www.itophub.io/wiki/page?id=2_7_0%3Adatamodel%3Aitop-change-mgmt-itil

Change Management ITIL Module

A change is used to document all the modifications that are planned in the IT:

• Patch installations

• System configuration changes

• OS updates

• Software installations

This way you can track all the modifications made within your IT. A lot of incidents are due to changes made to the IT environment. By documenting them, you can identify easily what changes had been made when an incident occurs and restore the service more quickly.

Moreover, this change management module allows you to analyze automatically the impact of the changes on the infrastructure and the application solutions. IT engineers can then better control the unavailability of the critical services in the enterprise, and improve customer satisfaction.

The changes are managed by the people having the following profiles:

• Change implementors plan and implement the changes

• Change supervisors follow up with the changes

• Change managers approve the changes

When installing iTop, you have the choice between two differents modules for documenting changes. The module described here has been designed to implement ITIL V3 change management with three types of changes:

• Routine changes

• Normal changes

• Emergency changes

The differences between those three types of changes rely in their respective workflows.

There is no special restriction/configuration needed for the Teams or Agents related to Change Management. However, keep in mind that the usual security restrictions apply: the teams/contacts to be selected when validating/assigning the ticket MUST be in an organization allowed to the current user.

Emergency Changes

 An ITIL emergency change is the highest priority change that can be defined in an organization. Emergency changes are defined as changes that need to be evaluated, assessed and either rejected or approved in a short timeframe. Simply defining a change as an emergency does not automatically entail the change should be implemented. The Emergency Change Advisory Board (ECAB) will assess the change and provide advice to the delegated person responsible for approving or rejecting emergency changes.

Emergency Change Properties

Name	Type	Mandatory?
Ref	Alphanumeric string	Yes
Organization	Foreign key to a Organization	Yes
Status	Possible values: Approved, Assigned, Closed, Implemented, Monitored, New, Not approved, Planned and scheduled, Rejected, Validated	No
Title	Alphanumeric string	Yes
Description	Multiline character string	Yes
Approval comment	Alphanumeric string	No
Caller	Foreign key to a Person	No
Team	Foreign key to a Team	No
Agent	Foreign key to a Person	No
Supervisor team	Foreign key to a Team	No
Supervisor	Foreign key to a Person	No
Manager team	Foreign key to a Team	No
Manager	Foreign key to a Person	No
Reject reason	Alphanumeric string	No
Impact	Alphanumeric string	No
Outage	Possible values: No, Yes	Yes
Fallback plan	Multiline character string	No
Parent change	Foreign key to a Change	No
Creation date	Date and time (year-month-day hh:mm:ss)	No
Start date	Date and time (year-month-day hh:mm:ss)	No
End date	Date and time (year-month-day hh:mm:ss)	No
Last update	Date and time (year-month-day hh:mm:ss)	No
Approval Date	Date and time (year-month-day hh:mm:ss)	No
Close date	Date and time (year-month-day hh:mm:ss)	No

Tabs

Creating a Emergency Change

Click on the “New change” menu:

Then select “Emergency Change” in the form below:

And click “Apply” to display the Emergency Change creation form:

Emergency Change Life Cycle

Emergency Change objects have the following life cycle:

Depending on the status of the object, the contraints on the properties vary as shown on the table below:

Table key:

• H: hidden

• R/O: read-only

• M: mandatory

Normal Change

An ITIL normal change refers to changes that must follow the complete change management process. By definition a normal change will proceed through all steps of the change management process and will eventually be reviewed by the Change Advisory Board (CAB). The CAB will provide advice regarding the change to the person who is deemed responsible to approve or reject normal changes.

Normal Change Properties

Name	Type	Mandatory?
Ref	Alphanumeric string	Yes
Organization	Foreign key to a Organization	Yes
Status	Possible values: Approved, Assigned, Closed, Implemented, Monitored, New, Not approved, Planned and scheduled, Rejected, Validated	No
Title	Alphanumeric string	Yes
Description	Multiline character string	Yes
Approval comment	Alphanumeric string	No
Acceptance comment	Multiline character string	No
Caller	Foreign key to a Person	No
Team	Foreign key to a Team	No
Agent	Foreign key to a Person	No
Supervisor team	Foreign key to a Team	No
Supervisor	Foreign key to a Person	No
Manager team	Foreign key to a Team	No
Manager	Foreign key to a Person	No
Reject reason	Alphanumeric string	No
Impact	Alphanumeric string	No
Outage	Possible values: No, Yes	Yes
Fallback plan	Multiline character string	No
Parent change	Foreign key to a Change	No
Creation date	Date and time (year-month-day hh:mm:ss)	No
Start date	Date and time (year-month-day hh:mm:ss)	No
End date	Date and time (year-month-day hh:mm:ss)	No
Last update	Date and time (year-month-day hh:mm:ss)	No
Approval Date	Date and time (year-month-day hh:mm:ss)	No
Acceptance date	Date and time (year-month-day hh:mm:ss)	No
Close date	Date and time (year-month-day hh:mm:ss)	No

Tabs

Creating a Normal Change

Click on the “New change” menu:

Then select “Normal Change” in the form below:

And click “Apply” to display the Normal Change creation form:

Normal Change Life Cycle

Normal Change objects have the following life cycle:

Depending on the status of the object, the contraints on the properties vary as shown on the table below:

Table key:

• H: hidden

• R/O: read-only

• M: mandatory

Routine Change

An ITIL routine (standard) change quite simply refers to pre-approved changes. Pre-approved changes can be defined for a variety of tasks, but they will typically be low risk, low effort changes that have a low or known cost.

Routine Change Properties

Tabs

Creating a Routine Change

Click on the “New change” menu:

Then select “Routine Change” in the form below:

And click “Apply” to display the Routine Change creation form:

Routine Change Life Cycle

Routine Change objects have the following life cycle:

Depending on the status of the object, the contraints on the properties vary as shown on the table below:

Table key:

• H: hidden

• R/O: read-only

• M: mandatory

Assigning a user request to a team and agent

The list of teams to which you can assign a change is defined by the delivery model of the corresponding organization. When creating a change, the agent has to select the customer organization, then the list of teams is strictly limited to the teams defined for this customer. If a team is missing, the delivery model of the customer must be updated to reflect this need. See More about Delivery model for more information

Managing Private Log

A change ticket only have a private log to document all the activities and communications related to it. This one is not visible on the end user portal.

Managing impacted CIs and Contacts

This section is similar to the one of the Helpdesk module. Please refer to it