5.6.3.4 复杂变更管理
变更管理ITIL模块
- 变更管理ITIL模块
- Change Management ITIL Module
变更用于记录IT中计划的所有修改:
- 补丁的安装
- 系统配置的更改
- 操作系统更新
- 软件安装
这样,您可以跟踪IT内进行的所有修改。很多事件是由于对IT环境所做的更改而引起的。通过记录它们,您可以轻松识别事件发生和复原服务发生时进行了哪些更改。
此外,此变更管理模块允许您自动分析影响度的基础架构和应用解决方案的更改。然后,IT工程师可以改善控制企业关键服务的可用性以及改进客户满意度的可用性。
更改由具有以下简档(角色)的人员管理:
- 变更实现者计划并实施更改
- 变更主管跟踪更改
- 变更经理批准更改
安装iTop时,可以在两个不同的模块之间进行选择,以记录更改。此处描述的模块经过设计,可以通过三种更改来实现ITIL V3变更管理:
- 例行公事的更改
- 正常变化
- 紧急变更
这三种类型的更改之间的差异依赖于它们各自的工作流。
与变更管理相关的团队或代理不需要任何特殊的限制配置。但是,请记住,通常会受到安全的限制:验证工单的气体签名时要选择的团队联系人必须位于允许用于当前用户的组织中。
紧急变更
ITIL紧急变更是可以在组织中定义的最高优先级变更。紧急更改被定义为需要在短时间内进行评估,评估以及拒绝或批准的更改。仅将变更定义为紧急情况并不能自动实现变更的实现。紧急变更咨询委员会(ECAB)将评估变更并向负责批准或拒绝紧急更改的受委托人提供建议。
紧急变更属性
名称 | 类型 | 强制性的吗? |
编号 | 字母数字字符串 | 是 |
组织 | 一个(n)组织的外键 | 是 |
状况 | 可能的值:已批准,已分配,已关闭,已实施,已监视,新,未批准,计划和计划,已拒绝,已验证 | 没有 |
标题 | 字母数字字符串 | 是 |
描述 | 多行字符串 | 是 |
批准备注 | 字母数字字符串 | 没有 |
提交人 | 一个人的外键 | 没有 |
球队 | 团队的外键 | 没有 |
处理人员 | 一个人的外键 | 没有 |
监控团队 | 团队的外键 | 没有 |
主管 | 一个人的外键 | 没有 |
管理团队 | 团队的外键 | 没有 |
经理 | 一个人的外键 | 没有 |
拒绝原因 | 字母数字字符串 | 没有 |
影响度 | 字母数字字符串 | 没有 |
断电 | 可能的值:否,是 | 是 |
回退计划 | 多行字符串 | 没有 |
父变更 | 一个(n)变更的外键 | 没有 |
创建日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
开始日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
结束日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
最后更新 | 日期和时间(年月日hh:mm:ss) | 没有 |
批准日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
截止日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
标签
标签 | 描述 |
配置项 | 此工单受影响的所有配置项目 |
联络人 | 与此工单链接的所有联系人 |
工作订单 | 工单的所有工作订单 |
相关要求 | 与此变更关联的所有用户请求 |
相关事件 | 与该变更相关的所有事件 |
相关问题 | 与此变更相关的所有问题 |
换小孩 | 与此变更链接的所有子更改 |
创建一个紧急变更
点击“ New变更”菜单:
然后在下面的表单中选择“紧急变更”:
然后单击“应用”以显示紧急变更创建表单:
紧急变更生命周期
紧急变更对象具有以下生命周期:
对象的状况上的依赖,其属性上的矛盾之处如下表所示:
新 | 已分配 | 计划和安排 | 已批准 | 不批准 | 已实施 | 受监控 | 已关闭 | |
编号 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
组织 | R/O | R/O | R/O | R/O | R/O | R/O | ||
状况 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
标题 | M | M | M | M | M | R/O | R/O | R/O |
描述 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | |
批准备注 | H | H | H | M | H | R/O | R/O | R/O |
提交人 | R/O | R/O | ||||||
球队 | H | M | M | M | M | M | R/O | R/O |
处理人员 | H | M | M | M | M | M | R/O | R/O |
监控团队 | H | M | M | R/O | R/O | R/O | R/O | R/O |
主管 | H | M | M | R/O | R/O | R/O | R/O | R/O |
管理团队 | H | M | M | R/O | R/O | R/O | R/O | R/O |
经理 | H | M | M | R/O | R/O | R/O | R/O | R/O |
拒绝原因 | H | R/O | R/O | R/O | M | R/O | R/O | R/O |
影响度 | H | H | M | R/O | R/O | R/O | R/O | R/O |
断电 | H | H | M | R/O | M | R/O | R/O | R/O |
回退计划 | H | H | M | M | M | M | R/O | R/O |
父变更 | R/O | R/O | ||||||
创建日期 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
开始日期 | H | H | M | M | M | R/O | R/O | R/O |
结束日期 | H | H | M | M | M | M | R/O | R/O |
最后更新 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
批准日期 | H | H | H | M | H | R/O | R/O | R/O |
截止日期 | H | H | H | H | H | H | H | R/O |
表键:
- H:隐藏
- RRO:只读
- M:必填
一般变更
ITIL一般变更是指必须遵循完整的变更管理流程进行的更改。根据定义,一般变更将继续执行变更管理流程的所有步骤,并最终由变更咨询委员会(CAB)进行审查。 CAB将向被认为负责批准或拒绝正常更改的人员提供有关一般变更的建议。
一般变更属性
名称 | 类型 | 强制性的吗? |
编号 | 字母数字字符串 | 是 |
组织 | 一个(n)组织的外键 | 是 |
状况 | 可能的值:已批准,已分配,已关闭,已实施,已监视,新,未批准,计划和计划,已拒绝,已验证 | 没有 |
标题 | 字母数字字符串 | 是 |
描述 | 多行字符串 | 是 |
批准备注 | 字母数字字符串 | 没有 |
审核备注 | 多行字符串 | 没有 |
提交人 | 一个人的外键 | 没有 |
球队 | 团队的外键 | 没有 |
处理人员 | 一个人的外键 | 没有 |
监控团队 | 团队的外键 | 没有 |
主管 | 一个人的外键 | 没有 |
管理团队 | 团队的外键 | 没有 |
经理 | 一个人的外键 | 没有 |
拒绝原因 | 字母数字字符串 | 没有 |
影响度 | 字母数字字符串 | 没有 |
断电 | 可能的值:否,是 | 是 |
回退计划 | 多行字符串 | 没有 |
父变更 | 一个(n)变更的外键 | 没有 |
创建日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
开始日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
结束日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
最后更新 | 日期和时间(年月日hh:mm:ss) | 没有 |
批准日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
验收日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
截止日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
标签
标签 | 描述 |
配置项 | 此工单受影响的所有配置项目 |
联络人 | 与此工单链接的所有联系人 |
工作订单 | 工单的所有工作订单 |
相关要求 | 与此变更关联的所有用户请求 |
相关事件 | 与该变更相关的所有事件 |
相关问题 | 与此变更相关的所有问题 |
换小孩 | 与此变更链接的所有子更改 |
创建一个一般变更
点击“ New变更”菜单:
然后在下面的表单中选择“一般变更”:
然后单击“应用”以显示一般变更创建表单:
一般变更生命周期
一般变更对象具有以下生命周期:
对象的状况上的依赖,其属性上的矛盾之处如下表所示:
新 | 已验证 | 拒绝 | 已分配 | 计划和安排 | 已批准 | 不批准 | 已实施 | 受监控 | 已关闭 | |
编号 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
组织 | R/O | R/O | R/O | R/O | R/O | R/O | ||||
状况 | ||||||||||
标题 | M | M | M | M | M | M | M | R/O | R/O | R/O |
描述 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | ||
批准备注 | H | H | H | H | H | M | H | R/O | R/O | R/O |
审核备注 | H | M | H | R/O | R/O | R/O | R/O | R/O | R/O | |
提交人 | M | M | R/O | R/O | ||||||
球队 | H | M | R/O | R/O | ||||||
处理人员 | H | H | H | M | M | M | M | M | R/O | R/O |
监控团队 | H | M | H | M | M | R/O | R/O | R/O | R/O | R/O |
主管 | H | H | H | M | M | R/O | R/O | R/O | R/O | R/O |
管理团队 | H | M | H | M | M | R/O | R/O | R/O | R/O | R/O |
经理 | H | H | H | M | M | R/O | R/O | R/O | R/O | R/O |
拒绝原因 | H | R/O | M | R/O | R/O | R/O | M | R/O | R/O | R/O |
影响度 | H | H | H | H | M | R/O | R/O | R/O | R/O | R/O |
断电 | H | H | H | H | M | R/O | M | R/O | R/O | R/O |
回退计划 | H | H | H | H | M | M | M | M | R/O | R/O |
父变更 | R/O | R/O | ||||||||
创建日期 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
开始日期 | H | H | H | H | M | M | M | R/O | R/O | R/O |
结束日期 | H | H | H | H | M | M | M | M | R/O | R/O |
最后更新 | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
批准日期 | H | H | H | H | H | M | H | R/O | R/O | R/O |
验收日期 | H | M | H | R/O | R/O | R/O | R/O | R/O | R/O | |
截止日期 | H | H | H | H | H | H | H | H | H | R/O |
表键:
- H:隐藏
- RRO:只读
- M:必填
标准变更
ITIL例行公事(标准)变更非常简单地指的是预先批准的更改。可以为各种任务定义预先批准的更改,但是它们通常是较低的风险,即省力的更改,其成本较低或已知。
标准变更属性
名称 | 类型 | 强制性的吗? |
编号 | 字母数字字符串 | 是 |
组织 | 一个(n)组织的外键 | 是 |
状况 | 可能的值:已批准,已分配,已关闭,已实施,已监视,新,未批准,计划和计划,已拒绝,已验证 | 没有 |
标题 | 字母数字字符串 | 是 |
描述 | 多行字符串 | 是 |
提交人 | 一个人的外键 | 没有 |
球队 | 团队的外键 | 没有 |
处理人员 | 一个人的外键 | 没有 |
监控团队 | 团队的外键 | 没有 |
主管 | 一个人的外键 | 没有 |
管理团队 | 团队的外键 | 没有 |
经理 | 一个人的外键 | 没有 |
拒绝原因 | 字母数字字符串 | 没有 |
影响度 | 字母数字字符串 | 没有 |
断电 | 可能的值:否,是 | 是 |
回退计划 | 多行字符串 | 没有 |
父变更 | 一个(n)变更的外键 | 没有 |
创建日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
开始日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
结束日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
最后更新 | 日期和时间(年月日hh:mm:ss) | 没有 |
截止日期 | 日期和时间(年月日hh:mm:ss) | 没有 |
标签
标签 | 描述 |
配置项 | 此工单受影响的所有配置项目 |
联络人 | 与此工单链接的所有联系人 |
工作订单 | 工单的所有工作订单 |
相关要求 | 与此变更关联的所有用户请求 |
相关事件 | 与该变更相关的所有事件 |
相关问题 | 与此变更相关的所有问题 |
换小孩 | 与此变更链接的所有子更改 |
创建一个标准变更
点击“ New变更”菜单:
然后在下面的表单中选择“标准变更”:
然后单击“应用”以显示标准变更创建表单:
标准变更生命周期
标准变更对象具有以下生命周期:
对象的状况上的依赖,其属性上的矛盾之处如下表所示:
新 | 已分配 | 计划和安排 | 已实施 | 受监控 | 已关闭 | |
编号 | R/O | R/O | R/O | R/O | R/O | R/O |
组织 | R/O | R/O | R/O | R/O | ||
状况 | R/O | R/O | R/O | R/O | R/O | R/O |
标题 | M | M | M | R/O | R/O | R/O |
描述 | R/O | R/O | R/O | R/O | R/O | |
提交人 | R/O | R/O | ||||
球队 | H | M | M | M | R/O | R/O |
处理人员 | H | M | M | M | R/O | R/O |
监控团队 | H | M | M | R/O | R/O | R/O |
主管 | H | M | M | R/O | R/O | R/O |
管理团队 | H | M | M | R/O | R/O | R/O |
经理 | H | M | M | R/O | R/O | R/O |
拒绝原因 | H | R/O | R/O | R/O | R/O | R/O |
影响度 | H | H | M | R/O | R/O | R/O |
断电 | H | H | M | R/O | R/O | R/O |
回退计划 | H | H | M | M | R/O | R/O |
父变更 | R/O | R/O | ||||
创建日期 | R/O | R/O | R/O | R/O | R/O | R/O |
开始日期 | H | H | M | R/O | R/O | R/O |
结束日期 | H | H | M | M | R/O | R/O |
最后更新 | R/O | R/O | R/O | R/O | R/O | R/O |
截止日期 | H | H | H | H | H | R/O |
表键:
- 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![]() | 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![]() | No |
Team | Foreign key to a![]() | No |
Agent | Foreign key to a![]() | No |
Supervisor team | Foreign key to a![]() | No |
Supervisor | Foreign key to a![]() | No |
Manager team | Foreign key to a![]() | No |
Manager | Foreign key to a![]() | 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
Tab | Description |
---|---|
CIs | All the configuration items impacted for this ticket |
Contacts | All the contacts linked to this ticket |
Work orders | All the work orders for this ticket |
Related requests | All the user requests linked to this change |
Related incidents | All the incidents linked to this change |
Related problems | All the problems linked to this change |
Child changes | All the sub changes linked to this change |
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:
New | Assigned | Planned and scheduled | Approved | Not approved | Implemented | Monitored | Closed | |
---|---|---|---|---|---|---|---|---|
Ref | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Organization | R/O | R/O | R/O | R/O | R/O | R/O | ||
Status | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Title | M | M | M | M | M | R/O | R/O | R/O |
Description | R/O | R/O | R/O | R/O | R/O | R/O | R/O | |
Approval comment | H | H | H | M | H | R/O | R/O | R/O |
Caller | R/O | R/O | ||||||
Team | H | M | M | M | M | M | R/O | R/O |
Agent | H | M | M | M | M | M | R/O | R/O |
Supervisor team | H | M | M | R/O | R/O | R/O | R/O | R/O |
Supervisor | H | M | M | R/O | R/O | R/O | R/O | R/O |
Manager team | H | M | M | R/O | R/O | R/O | R/O | R/O |
Manager | H | M | M | R/O | R/O | R/O | R/O | R/O |
Reject reason | H | R/O | R/O | R/O | M | R/O | R/O | R/O |
Impact | H | H | M | R/O | R/O | R/O | R/O | R/O |
Outage | H | H | M | R/O | M | R/O | R/O | R/O |
Fallback plan | H | H | M | M | M | M | R/O | R/O |
Parent change | R/O | R/O | ||||||
Creation date | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Start date | H | H | M | M | M | R/O | R/O | R/O |
End date | H | H | M | M | M | M | R/O | R/O |
Last update | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Approval Date | H | H | H | M | H | R/O | R/O | R/O |
Close date | H | H | H | H | H | H | H | R/O |
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![]() | 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
Tab | Description |
---|---|
CIs | All the configuration items impacted for this ticket |
Contacts | All the contacts linked to this ticket |
Work orders | All the work orders for this ticket |
Related requests | All the user requests linked to this change |
Related incidents | All the incidents linked to this change |
Related problems | All the problems linked to this change |
Child changes | All the sub changes linked to this change |
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:
New | Validated | Rejected | Assigned | Planned and scheduled | Approved | Not approved | Implemented | Monitored | Closed | |
---|---|---|---|---|---|---|---|---|---|---|
Ref | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Organization | R/O | R/O | R/O | R/O | R/O | R/O | ||||
Status | ||||||||||
Title | M | M | M | M | M | M | M | R/O | R/O | R/O |
Description | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | ||
Approval comment | H | H | H | H | H | M | H | R/O | R/O | R/O |
Acceptance comment | H | M | H | R/O | R/O | R/O | R/O | R/O | R/O | |
Caller | M | M | R/O | R/O | ||||||
Team | H | M | R/O | R/O | ||||||
Agent | H | H | H | M | M | M | M | M | R/O | R/O |
Supervisor team | H | M | H | M | M | R/O | R/O | R/O | R/O | R/O |
Supervisor | H | H | H | M | M | R/O | R/O | R/O | R/O | R/O |
Manager team | H | M | H | M | M | R/O | R/O | R/O | R/O | R/O |
Manager | H | H | H | M | M | R/O | R/O | R/O | R/O | R/O |
Reject reason | H | R/O | M | R/O | R/O | R/O | M | R/O | R/O | R/O |
Impact | H | H | H | H | M | R/O | R/O | R/O | R/O | R/O |
Outage | H | H | H | H | M | R/O | M | R/O | R/O | R/O |
Fallback plan | H | H | H | H | M | M | M | M | R/O | R/O |
Parent change | R/O | R/O | ||||||||
Creation date | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Start date | H | H | H | H | M | M | M | R/O | R/O | R/O |
End date | H | H | H | H | M | M | M | M | R/O | R/O |
Last update | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Approval Date | H | H | H | H | H | M | H | R/O | R/O | R/O |
Acceptance date | H | M | H | R/O | R/O | R/O | R/O | R/O | R/O | |
Close date | H | H | H | H | H | H | H | H | H | R/O |
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
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 |
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 |
Close date | Date and time (year-month-day hh:mm:ss) | No |
Tabs
Tab | Description |
---|---|
CIs | All the configuration items impacted for this ticket |
Contacts | All the contacts linked to this ticket |
Work orders | All the work orders for this ticket |
Related requests | All the user requests linked to this change |
Related incidents | All the incidents linked to this change |
Related problems | All the problems linked to this change |
Child changes | All the sub changes linked to this change |
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:
New | Assigned | Planned and scheduled | Implemented | Monitored | Closed | |
---|---|---|---|---|---|---|
Ref | R/O | R/O | R/O | R/O | R/O | R/O |
Organization | R/O | R/O | R/O | R/O | ||
Status | R/O | R/O | R/O | R/O | R/O | R/O |
Title | M | M | M | R/O | R/O | R/O |
Description | R/O | R/O | R/O | R/O | R/O | |
Caller | R/O | R/O | ||||
Team | H | M | M | M | R/O | R/O |
Agent | H | M | M | M | R/O | R/O |
Supervisor team | H | M | M | R/O | R/O | R/O |
Supervisor | H | M | M | R/O | R/O | R/O |
Manager team | H | M | M | R/O | R/O | R/O |
Manager | H | M | M | R/O | R/O | R/O |
Reject reason | H | R/O | R/O | R/O | R/O | R/O |
Impact | H | H | M | R/O | R/O | R/O |
Outage | H | H | M | R/O | R/O | R/O |
Fallback plan | H | H | M | M | R/O | R/O |
Parent change | R/O | R/O | ||||
Creation date | R/O | R/O | R/O | R/O | R/O | R/O |
Start date | H | H | M | R/O | R/O | R/O |
End date | H | H | M | M | R/O | R/O |
Last update | R/O | R/O | R/O | R/O | R/O | R/O |
Close date | H | H | H | H | H | R/O |
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