用户请求管理（服务台）模块

在iTop中，有两种方法可以管理用户请求。您可以选择安装以下两个模块之一：

• 简单的工单管理
• 用户请求管理ITIL V3
  

简单工单管理模块提供了简化的售票系统。它用于跟踪终端用户请求。有两种类型的请求：

• 事件用于跟踪在交付的服务上具有影响度的意外问题。
• 服务请求用于请求新服务或功能，例如安装新PC，创建新发送邮件地址。
  

该模块在单一类型的工单中管理两种类型的请求。事件和服务请求将遵循相同的工作流程。这使处理人员可以轻松管理任何类型的工单并重新分类请求，而不必创建新请求。

用户请求ITIL V3模块着重于服务请求。

如果您选择安装此模块，并且还需要管理事件，则必须安装事件管理模块。

无论选择哪种模块，都可以通过客户门户或直接在iTop中创建用户请求。然后，支持人员可以通过称为“外部留言”的日记来修改客户并与之通信。他还可以通过名为“内部留言”的杂志与公司内部的团队进行沟通。

客户用户将仅看到外部留言。无法从门户查看内部留言。

用户请求由工作流控制，以确保根据定义的流程对其进行管理。仅授权用户可以管理用户请求和变更及其用户。

用户请求可以链接到父问题或父父。如果您已经安装了用户Request ITIL V3模块，则您的请求可以链接到父变更。

也可以在单个用户请求下重新组合用户请求。

仪表板概述使代理和管理者可以监视帮助台活动。

用户请求

用户请求用于记录用户提交的所有请求

用户请求属性

名称	类型	强制性的吗？
组织	一个（n）组织的外键	是
提交人	一个人的外键	是
状况	可能的值：已批准，已分配，已关闭，已升级的TTO，已升级的TTR，新增，待处理，已拒绝，被解决，正在等待批准	是
来源	可能的值：邮件，监控，电话，门户	没有
标题	字母数字字符串	是
描述	多行字符串	是
服务	一个（n）服务的外键	没有
服务子目录	一个（n）服务子目录的外键	没有
重点标记	可能的值：否，是	没有
热门原因	字母数字字符串	没有
待定原因	多行字符串	没有
请求类型	可能的值：事件，服务请求	没有
影响度	可能的值：一个部门，一个服务，一个人	是
紧急度	可能的值：临界，高，中，低	是
优先级	可能的值：临界，高，中，低	是
球队	团队的外键	没有
处理人员	一个人的外键	没有
批准人	一个人的外键	没有
开始日期	日期和时间（年月日hh：mm：ss）	没有
最后更新	日期和时间（年月日hh：mm：ss）	没有
分派日期	日期和时间（年月日hh：mm：ss）	没有
TTO时限	核心：AttributeStopWatch +（100_时限）	没有
TTR时限	核心：AttributeStopWatch +（100_时限）	没有
最后未决日期	日期和时间（年月日hh：mm：ss）	没有
解决日期	日期和时间（年月日hh：mm：ss）	没有
截止日期	日期和时间（年月日hh：mm：ss）	没有
父要求	用户请求的外键	没有
父问题	一个（n）问题的外键	没有
父变更	一个（n）变更的外键	没有
解决代码	可能的值：帮助，错误修复，硬件修复，其他，软件补丁，系统更新，培训	没有
解	多行字符串	没有
排除非工作时间	核心：AttributeDuration +	没有
用户满意度	可能的值：非常满意，合理规定，相当不满意，非常不满意	没有
用户评论	多行字符串	没有
超过SLA的TTO	核心：AttributeStopWatch +（已通过100次）	没有
SLA结束	核心：AttributeStopWatch +（100_overrun）	没有
超过SLA的TTR	核心：AttributeStopWatch +（已通过100次）	没有
SLA结束	核心：AttributeStopWatch +（100_overrun）	没有

如果已安装用户Request ITIL V3模块，则属性Request Type将设置为“服务请求”，并且无法修改

标签

标签	描述
配置项	此工单受影响的所有配置项目
联络人	与此工单链接的所有联系人
子请求	链接到此父请求的所有请求
工作订单	工单的所有工作订单

创建一个用户请求

单击“新用户请求”菜单：

显示以下表单：

管理公众和内部留言

公众和内部留言用于跟踪与用户请求相关的所有通信和活动。

外部留言旨在与请求者交换信息。

内部留言是跟踪调查或操作的首选方式：命令行结果的复制粘贴，与提供者的通信的总结等。

公众或内部留言中的每个条目都以更新它以及完成时间的用户的名称来跟踪。它不能被修改或删除。

从客户门户可以看到外部留言。

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

编辑用户请求时，处理人员可以通过选项卡“配置项”和“联系人”指定与该请求相关的配置项目（配置项）或联系人。手动添加到配置项的对象将被标记为“手动添加”（默认设置）。

保存工单时，影响度分析引擎会自动将受原始配置项影响的所有其他配置项（和联系人）添加到此列表中。 “影响度”计算基于iTop影响度中定义的规则。此计算产生的其他对象也链接到工单，并标记为“已计算”（以与标记为“手动添加”的原始对象区分开）。

每种配置项的影响度规则在配置管理模块.

由于每次修改连接到工单的配置项的列表时都会运行“影响度”的计算，因此没有必要从工单中删除“已计算”的配置项（或“联系人”）。计算将再次添加这些元素。为了指示给定的工单实际上工单（或配置项）不受影响，在对配置项进行修改之前，将其标记为“不受影响”（分别为“不通知”）。

与服务目录的依赖关系

帮助台模块链接到服务目录，以便：

• 定义可以为给定的服务选择哪些服务和服务子类别
• 定义可以将用户请求分配给哪个团队
• 计算拥有时间（TTO）和截止时间解决（TTR）
  

服务列表仅显示选定的客户通过客户合同购买的服务。服务子类别列表仅显示与所选服务和所选请求类型相对应的子类别。

下图描述了服务目录元素和用户请求之间的关系。

增强门户中仅建议使用定义了服务族的服务

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

可以分派向用户请求的团队列表由相应的客户的交付模式定义。创建用户请求时，用户必须选择客户组织，然后，团队列表严格限于为此客户定义的团队。如果缺少团队，则必须更新客户的交付模式以反映此需求。看到[  :8082/bin/view/5/5.6/5.6.3/5.6.3.1/#delivery_model]关于交付模式的更多信息[/url] 想要查询更多的信息

下图描述了交付模式和用户请求之间的关系。

自动化优先级计算

优先级是自动计算的。此计算依赖于用户请求的影响度和紧急度。以下矩阵型描述了如何计算优先级：

紧急度影响度	部门	服务	人
危急	危急	危急	高
高	危急	高	中
中	高	中	中
低	低	低	低

时限计算

为了满足与客户达成的服务协议，iTop会自动计算拥有时间（TTO）和解决（TTR）截止日期的时间。这些截止日期依赖于客户合同中定义的服务级别协议。在iTop的基本版本中，没有工作时段。该计算假定服务覆盖率为24 * 7。

测得的TTO是未分配用户请求时的累积时间。通过TTO时限时，工单状况自动更改为“升级的TTO”。

测得的TTR是用户请求既未挂起也不被解决时所累积的时间。通过TTR时限时，工单状况自动更改为“升级的TTR”。

截止日期的计算依赖于：

• 客户合同中为所选服务定义的服务级别协议
• 用户的优先级请求
• 请求类型
  

这些定义在与服务级别协议（SLA）相对应的服务级别目标（SLT）中。

每次对用户请求进行修改时，都会执行截止期限计算。

当累计的TTO/TTR达到TTO/TTR时限的75％时，用户请求将以黄色显示。通过时限后，它会变成红色。

一旦用户请求为被解决，截止日期和措施将保留在用户请求中。这可用于分析用户问题和用于报告目的。

记录以下信息：

• TTO时限（日期和时间）
• TTO累计（秒）
• TTO通过（是）
• TTO超限（秒）
• TTR时限（日期和时间）
• TTR累计（秒）
• TTR通过（是）
• TTR超限（秒）
  

重新组合用户请求

在事件（问题的根因）下重新组合用户请求有时有时很有用。例如，当一个邮件服务器关闭时，您可能有几个最终用户抱怨邮箱不可用。

要对用户请求进行分组，请使用父字段。

如果事件工单是用户请求的父，则每次修改其私有日志和公众日志时，iTop都会自动更新子请求的日志。当父事件获得事件时，iTop将自动将子请求标记为“事件”。

用户请求生命周期

	新	已分配	升级的TTO	等待批准	被解决	待定	升级的TTR	已关闭	已批准	拒绝
组织	M	M	M	M	R/O	M	M	R/O	M	M
提交人	M		M	M	R/O			R/O	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
描述					R/O			R/O
服务					M			R/O
服务子目录								R/O
重点标记	H		H	H	R/O			R/O	H	H
热门原因	H		H	H	R/O			R/O	H	H
待定原因	H	H	H	H	R/O	M	H	R/O	H	H
请求类型		M			R/O	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	R/O
球队	H	M			R/O	M	M	R/O
处理人员	H	M	H	H	R/O	M	M	R/O	H	H
批准人	H	R/O	H		R/O	R/O	R/O	R/O	R/O	H
开始日期	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
分派日期	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
TTO时限	R/O	H	R/O	R/O	H	H	H	H	R/O	H
TTR时限	H	R/O	H	H	H	H	R/O	H	H	H
最后未决日期	H	H	H	H	H	R/O	H	H	H	H
解决日期	H	H	H	H	R/O	H	H	R/O	H	H
截止日期	H	H	H	H	H	H	H	R/O	H	H
父要求					R/O			R/O
父问题					R/O			R/O
父变更					R/O			R/O
解决代码	H	H	H	H	M	H	H	R/O	H	H
解	H	H	H	H	M	H	H	R/O	H	H
排除非工作时间	H	H	H	H	R/O	H	H	R/O	H	H
用户满意度	H	H	H	H	H	H	H		H	H
用户评论	H	H	H	H	H	H	H		H	H
超过SLA的TTO	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
SLA结束	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
超过SLA的TTR	H	H	H	H	R/O	H	H	R/O	H	H
SLA结束	H	H	H	H	R/O	H	H	R/O	H	H

表键：

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

用户请求管理（服务台）模块

在iTop中，有两种方法可以管理用户请求。您可以选择安装以下两个模块之一：

• 简单的工单管理
• 用户请求管理ITIL V3
  

简单工单管理模块提供了简化的售票系统。它用于跟踪终端用户请求。有两种类型的请求：

• 事件用于跟踪在交付的服务上具有影响度的意外问题。
• 服务请求用于请求新服务或功能，例如安装新PC，创建新发送邮件地址。
  

该模块在单一类型的工单中管理两种类型的请求。事件和服务请求将遵循相同的工作流程。这使处理人员可以轻松管理任何类型的工单并重新分类请求，而不必创建新请求。

用户请求ITIL V3模块着重于服务请求。

如果您选择安装此模块，并且还需要管理事件，则必须安装事件管理模块。

无论选择哪种模块，都可以通过客户门户或直接在iTop中创建用户请求。然后，支持人员可以通过称为“外部留言”的日记来修改客户并与之通信。他还可以通过名为“内部留言”的杂志与公司内部的团队进行沟通。

客户用户将仅看到外部留言。无法从门户查看内部留言。

用户请求由工作流控制，以确保根据定义的流程对其进行管理。仅授权用户可以管理用户请求和变更及其用户。

用户请求可以链接到父问题或父父。如果您已经安装了用户Request ITIL V3模块，则您的请求可以链接到父变更。

也可以在单个用户请求下重新组合用户请求。

仪表板概述使代理和管理者可以监视帮助台活动。

用户请求

用户请求用于记录用户提交的所有请求

用户请求属性

名称	类型	强制性的吗？
组织	一个（n）组织的外键	是
提交人	一个人的外键	是
状况	可能的值：已批准，已分配，已关闭，已升级的TTO，已升级的TTR，新增，待处理，已拒绝，被解决，正在等待批准	是
来源	可能的值：邮件，监控，电话，门户	没有
标题	字母数字字符串	是
描述	多行字符串	是
服务	一个（n）服务的外键	没有
服务子目录	一个（n）服务子目录的外键	没有
重点标记	可能的值：否，是	没有
热门原因	字母数字字符串	没有
待定原因	多行字符串	没有
请求类型	可能的值：事件，服务请求	没有
影响度	可能的值：一个部门，一个服务，一个人	是
紧急度	可能的值：临界，高，中，低	是
优先级	可能的值：临界，高，中，低	是
球队	团队的外键	没有
处理人员	一个人的外键	没有
批准人	一个人的外键	没有
开始日期	日期和时间（年月日hh：mm：ss）	没有
最后更新	日期和时间（年月日hh：mm：ss）	没有
分派日期	日期和时间（年月日hh：mm：ss）	没有
TTO时限	核心：AttributeStopWatch +（100_时限）	没有
TTR时限	核心：AttributeStopWatch +（100_时限）	没有
最后未决日期	日期和时间（年月日hh：mm：ss）	没有
解决日期	日期和时间（年月日hh：mm：ss）	没有
截止日期	日期和时间（年月日hh：mm：ss）	没有
父要求	用户请求的外键	没有
父问题	一个（n）问题的外键	没有
父变更	一个（n）变更的外键	没有
解决代码	可能的值：帮助，错误修复，硬件修复，其他，软件补丁，系统更新，培训	没有
解	多行字符串	没有
排除非工作时间	核心：AttributeDuration +	没有
用户满意度	可能的值：非常满意，合理规定，相当不满意，非常不满意	没有
用户评论	多行字符串	没有
超过SLA的TTO	核心：AttributeStopWatch +（已通过100次）	没有
SLA结束	核心：AttributeStopWatch +（100_overrun）	没有
超过SLA的TTR	核心：AttributeStopWatch +（已通过100次）	没有
SLA结束	核心：AttributeStopWatch +（100_overrun）	没有

如果已安装用户Request ITIL V3模块，则属性Request Type将设置为“服务请求”，并且无法修改

标签

标签	描述
配置项	此工单受影响的所有配置项目
联络人	与此工单链接的所有联系人
子请求	链接到此父请求的所有请求
工作订单	工单的所有工作订单

创建一个用户请求

单击“新用户请求”菜单：

显示以下表单：

管理公众和内部留言

公众和内部留言用于跟踪与用户请求相关的所有通信和活动。

外部留言旨在与请求者交换信息。

内部留言是跟踪调查或操作的首选方式：命令行结果的复制粘贴，与提供者的通信的总结等。

公众或内部留言中的每个条目都以更新它以及完成时间的用户的名称来跟踪。它不能被修改或删除。

从客户门户可以看到外部留言。

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

编辑用户请求时，处理人员可以通过选项卡“配置项”和“联系人”指定与该请求相关的配置项目（配置项）或联系人。手动添加到配置项的对象将被标记为“手动添加”（默认设置）。

保存工单时，影响度分析引擎会自动将受原始配置项影响的所有其他配置项（和联系人）添加到此列表中。 “影响度”计算基于iTop影响度中定义的规则。此计算产生的其他对象也链接到工单，并标记为“已计算”（以与标记为“手动添加”的原始对象区分开）。

每种配置项的影响度规则在配置管理模块.

由于每次修改连接到工单的配置项的列表时都会运行“影响度”的计算，因此没有必要从工单中删除“已计算”的配置项（或“联系人”）。计算将再次添加这些元素。为了指示给定的工单实际上工单（或配置项）不受影响，在对配置项进行修改之前，将其标记为“不受影响”（分别为“不通知”）。

与服务目录的依赖关系

帮助台模块链接到服务目录，以便：

• 定义可以为给定的服务选择哪些服务和服务子类别
• 定义可以将用户请求分配给哪个团队
• 计算拥有时间（TTO）和截止时间解决（TTR）
  

服务列表仅显示选定的客户通过客户合同购买的服务。服务子类别列表仅显示与所选服务和所选请求类型相对应的子类别。

下图描述了服务目录元素和用户请求之间的关系。

增强门户中仅建议使用定义了服务族的服务

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

可以分派向用户请求的团队列表由相应的客户的交付模式定义。创建用户请求时，用户必须选择客户组织，然后，团队列表严格限于为此客户定义的团队。如果缺少团队，则必须更新客户的交付模式以反映此需求。看到[  :8082/bin/view/5/5.6/5.6.3/5.6.3.1/#delivery_model]关于交付模式的更多信息[/url] 想要查询更多的信息

下图描述了交付模式和用户请求之间的关系。

自动化优先级计算

优先级是自动计算的。此计算依赖于用户请求的影响度和紧急度。以下矩阵型描述了如何计算优先级：

紧急度影响度	部门	服务	人
危急	危急	危急	高
高	危急	高	中
中	高	中	中
低	低	低	低

时限计算

为了满足与客户达成的服务协议，iTop会自动计算拥有时间（TTO）和解决（TTR）截止日期的时间。这些截止日期依赖于客户合同中定义的服务级别协议。在iTop的基本版本中，没有工作时段。该计算假定服务覆盖率为24 * 7。

测得的TTO是未分配用户请求时的累积时间。通过TTO时限时，工单状况自动更改为“升级的TTO”。

测得的TTR是用户请求既未挂起也不被解决时所累积的时间。通过TTR时限时，工单状况自动更改为“升级的TTR”。

截止日期的计算依赖于：

• 客户合同中为所选服务定义的服务级别协议
• 用户的优先级请求
• 请求类型
  

这些定义在与服务级别协议（SLA）相对应的服务级别目标（SLT）中。

每次对用户请求进行修改时，都会执行截止期限计算。

当累计的TTO/TTR达到TTO/TTR时限的75％时，用户请求将以黄色显示。通过时限后，它会变成红色。

一旦用户请求为被解决，截止日期和措施将保留在用户请求中。这可用于分析用户问题和用于报告目的。

记录以下信息：

• TTO时限（日期和时间）
• TTO累计（秒）
• TTO通过（是）
• TTO超限（秒）
• TTR时限（日期和时间）
• TTR累计（秒）
• TTR通过（是）
• TTR超限（秒）
  

重新组合用户请求

在事件（问题的根因）下重新组合用户请求有时有时很有用。例如，当一个邮件服务器关闭时，您可能有几个最终用户抱怨邮箱不可用。

要对用户请求进行分组，请使用父字段。

如果事件工单是用户请求的父，则每次修改其私有日志和公众日志时，iTop都会自动更新子请求的日志。当父事件获得事件时，iTop将自动将子请求标记为“事件”。

用户请求生命周期

	新	已分配	升级的TTO	等待批准	被解决	待定	升级的TTR	已关闭	已批准	拒绝
组织	M	M	M	M	R/O	M	M	R/O	M	M
提交人	M		M	M	R/O			R/O	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
描述					R/O			R/O
服务					M			R/O
服务子目录								R/O
重点标记	H		H	H	R/O			R/O	H	H
热门原因	H		H	H	R/O			R/O	H	H
待定原因	H	H	H	H	R/O	M	H	R/O	H	H
请求类型		M			R/O	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	R/O
球队	H	M			R/O	M	M	R/O
处理人员	H	M	H	H	R/O	M	M	R/O	H	H
批准人	H	R/O	H		R/O	R/O	R/O	R/O	R/O	H
开始日期	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
分派日期	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
TTO时限	R/O	H	R/O	R/O	H	H	H	H	R/O	H
TTR时限	H	R/O	H	H	H	H	R/O	H	H	H
最后未决日期	H	H	H	H	H	R/O	H	H	H	H
解决日期	H	H	H	H	R/O	H	H	R/O	H	H
截止日期	H	H	H	H	H	H	H	R/O	H	H
父要求					R/O			R/O
父问题					R/O			R/O
父变更					R/O			R/O
解决代码	H	H	H	H	M	H	H	R/O	H	H
解	H	H	H	H	M	H	H	R/O	H	H
排除非工作时间	H	H	H	H	R/O	H	H	R/O	H	H
用户满意度	H	H	H	H	H	H	H		H	H
用户评论	H	H	H	H	H	H	H		H	H
超过SLA的TTO	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
SLA结束	H	R/O	H	H	R/O	R/O	R/O	R/O	H	H
超过SLA的TTR	H	H	H	H	R/O	H	H	R/O	H	H
SLA结束	H	H	H	H	R/O	H	H	R/O	H	H

表键：

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