用户请求管理(服务台)模块

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

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

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

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

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

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

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

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

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

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

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

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

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

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Adashboard1_userreqest.png

用户请求

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclassicon_userrequest.png用户请求用于记录用户提交的所有请求

用户请求属性

名称类型强制性的吗?
组织一个(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)变更的外键没有
解决代码可能的值:协助,错误修复,硬件修复,其他,软件补丁,系统更新,培训没有
多行字符串没有
排除非工作时间核心:属性偏差|没有
用户满意度可能的值:非常满意,非常受关注,相当不满意,非常不满意没有
用户评论多行字符串没有
超过SLA的TTO核心:AttributeStopWatch +(已通过100次)没有
SLA结束核心:属性停止观察® (100_overrun)没有
超过SLA的TTR核心:AttributeStopWatch +(已通过100次)没有
SLA结束核心:属性停止观察® (100_overrun)没有

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

标签

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

创建一个用户请求

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

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclasscreate_userrequest_1.png

显示以下表单:

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclasscreate_userrequest_2.png

管理公众和内部留言

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

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

内部留言是跟踪调查或操作的首选方式:命令行结果的copy/paste,与提供者的通信的总结等。

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Apublic-privatelog_userrequest.png

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

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

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

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

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

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

Managing CIs with Impact Analysis

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

与服务目录的依赖关系

帮助台模块链接到服务目录,以便:

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

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

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

https://www.itophub.io/wiki/media?w=500&tok=e22674&media=2_7_0%3Adatamodel%3Arelationshipswithservicecatalog_userrequest.png

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

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

可以分派向用户请求的团队列表由相应的客户的交付模式定义。创建用户请求时,用户必须选择客户组织,然后,团队列表严格限于为此客户定义的团队。如果缺少团队,则必须更新客户的交付模式以反映此需求。看到关于交付模式的更多信息 想要查询更多的信息

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

https://www.itophub.io/wiki/media?w=500&tok=8e8e75&media=2_7_0%3Adatamodel%3Arelationshipswithdeliverymodel_userrequest.png

自动化优先级计算

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

紧急度影响度部门服务
危急危急危急
危急

时限计算

为了满足与客户的服务协议,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将自动将子请求标记为“事件”。

用户请求生命周期

https://www.itophub.io/wiki/media?w=600&tok=101ec5&media=2_7_0%3Adatamodel%3Alifecycle_userrequest.png

 已分配升级的TTO等待批准被解决待定升级的TTR已关闭已批准拒绝
组织MMMMR/OMMR/OMM
呼叫人M MMR/O  R/OMM
状况R/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
来源    R/O  R/O  
标题    R/O  R/O  
描述    R/O  R/O  
服务    M  R/O  
服务子目录       R/O  
重点标记H HHR/O  R/OHH
热门原因H HHR/O  R/OHH
待定原因HHHHR/OMHR/OHH
请求类型 M  R/OMMR/O  
影响度    R/O  R/O  
紧急度    R/O  R/O  
优先级R/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
球队HM  R/OMMR/O  
处理人员HMHHR/OMMR/OHH
批准人HR/OH R/OR/OR/OR/OR/OH
开始日期R/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
最后更新R/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
分派日期HR/OHHR/OR/OR/OR/OHH
TTO时限R/OHR/OR/OHHHHR/OH
TTR时限HR/OHHHHR/OHHH
最后等待日期HHHHHR/OHHHH
解决日期HHHHR/OHHR/OHH
截止日期HHHHHHHR/OHH
父要求    R/O  R/O  
父问题    R/O  R/O  
父变更    R/O  R/O  
解决代码HHHHMHHR/OHH
HHHHMHHR/OHH
排除非工作时间HHHHR/OHHR/OHH
用户满意度HHHHHHH HH
用户评论HHHHHHH HH
超过SLA的TTOHR/OHHR/OR/OR/OR/OHH
SLA结束HR/OHHR/OR/OR/OR/OHH
超过SLA的TTRHHHHR/OHHR/OHH
SLA结束HHHHR/OHHR/OHH

表键:

  • H: 隐
  • RRO:只读
  • M: 强制性的

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


User request management (Service Desk) Module

There are two alternatives for managing user requests in iTop. You can choose to install one of the two following modules:

  • Simple Ticket Management

  • User Request Management ITIL V3

The Simple Ticket Management module provides a simplified ticketing system. It is used to keep track of end-users requests. There are two types of request:

  • Incidents are used to track unexpected issues that have an impact on the delivered services.

  • Service requests are used to request new services or features like installing a new PC, creating a new email address.

This module manages both types of requests in a single type of ticket. Incidents and service requests will follow the same workflow. This allows agent to easily manage any kind of ticket and reclassify a request without having to create a new one.

The User Request ITIL V3 module focuses on service requests.

In case you choose to install this module, and if you need to manage incidents as well, then you have to install the Incident Management module.

Whatever module you choose, a user request can be created via the customer portal or directly in iTop. The support agent can then modify and communicate with the customer via a journal called “Public log.” He can also communicate with internal teams within his company through a journal called “Private log”.

A customer user will see only the public log. The private log cannot be viewed from the portal.

A user request is controled by a workflow in order to make sure it is managed according to a defined process. Only authorized users can manage a user request and change its status.

A user request can be linked to a parent problem, or a parent change. In case you have installed the User Request ITIL V3 module, your request can be linked to a parent incident.

It is also possible to regroup user requests under a single user request.

The overview dashboard allows agents and managers to monitor the helpdesk activity.

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Adashboard1_userreqest.png

User Request

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclassicon_userrequest.pngUser request are used to document all the request submitted by users

User Request Properties

NameTypeMandatory?
OrganizationForeign key to a OrganizationYes
CallerForeign key to a PersonYes
StatusPossible values: Approved, Assigned, Closed, Escalated TTO, Escalated TTR, New, Pending, Rejected, Resolved, Waiting for approvalYes
OriginPossible values: mail, monitoring, phone, portalNo
TitleAlphanumeric stringYes
DescriptionMultiline character stringYes
ServiceForeign key to a ServiceNo
Service subcategoryForeign key to a Service SubcategoryNo
Hot FlagPossible values: No, YesNo
Hot reasonAlphanumeric stringNo
Pending reasonMultiline character stringNo
Request TypePossible values: Incident, Service requestNo
ImpactPossible values: A department, A service, A personYes
UrgencyPossible values: critical, high, medium, lowYes
PriorityPossible values: critical, high, medium, lowYes
TeamForeign key to a TeamNo
AgentForeign key to a PersonNo
ApproverForeign key to a PersonNo
Start dateDate and time (year-month-day hh:mm:ss)No
Last updateDate and time (year-month-day hh:mm:ss)No
Assignment dateDate and time (year-month-day hh:mm:ss)No
TTO DeadlineCore:AttributeStopWatch+ (100_deadline)No
TTR DeadlineCore:AttributeStopWatch+ (100_deadline)No
Last pending dateDate and time (year-month-day hh:mm:ss)No
Resolution dateDate and time (year-month-day hh:mm:ss)No
Close dateDate and time (year-month-day hh:mm:ss)No
Parent requestForeign key to a User RequestNo
Parent problemForeign key to a ProblemNo
Parent changeForeign key to a ChangeNo
Resolution codePossible values: assistance, bug fixed, hardware repair, other, software patch, system update, trainingNo
SolutionMultiline character stringNo
Resolution delayCore:AttributeDuration+No
User satisfactionPossible values: Very satisfied, Fairly statisfied, Rather Dissatified, Very DissatisfiedNo
User commentMultiline character stringNo
SLA tto passedCore:AttributeStopWatch+ (100_passed)No
SLA tto overCore:AttributeStopWatch+ (100_overrun)No
SLA ttr passedCore:AttributeStopWatch+ (100_passed)No
SLA ttr overCore:AttributeStopWatch+ (100_overrun)No

If you have installed the User Request ITIL V3 module the attribute Request Type will be set to “service request” and it cannot be modified

Tabs

TabDescription
CIsAll the configuration items impacted for this ticket
ContactsAll the contacts linked to this ticket
Child RequestsAll the requests that are linked to this parent request
Work ordersAll the work orders for this ticket

Creating a User Request

Click on the “New user request” menu:

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclasscreate_userrequest_1.png

The following form is displayed:

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Aclasscreate_userrequest_2.png

Managing Public & Private Log

The public and the private log are used to keep track of all communications and activities related to a user request.

The public log is aimed at exchanging information with the requestor.

The private log is the preferred way for keeping track of the investigations or operations: copy/paste of command line results, summary of communications with a provider, etc.

https://www.itophub.io/wiki/media?media=2_7_0%3Adatamodel%3Apublic-privatelog_userrequest.png

Each entry in the public or private log is tracked with the name of the user who updated it and when it was done. It cannot be modified nor deleted.

The public log is visible from the customer portal.

Managing impacted CIs and Contacts

When a user request is edited, the agent can specify which configuration items (CIs) or contacts are related to this request via the tabs “CIs” and “Contacts”. The objects manually added to the ticket are to be flagged as “Added manually” (which is the default).

When saving the ticket, the impact analysis engine automatically adds to this list all the other CIs (and Contacts) impacted by the original CIs. The “impact” computation is based on rules defined in the iTop data model. The additional objects resulting from this computation are also linked to the ticket and flagged as “Computed” (to differentiate them from the original objects marked as “Added manually”).

The impact rules of each type of CI are described in the Configuration management module.

Managing CIs with Impact Analysis

Since the computation of the “Impact” is run every time the list of CIs attached to the ticket is modified, it is useless to remove “Computed” CIs (or “Contacts”) from the ticket. The computation will add these elements again. To indicate that a CI (or a Contact) is actually not impacted for the given ticket, mark it as “Not impacted” (respectively “Do not notify”) before applying the modifications to the Ticket.

Dependencies with the service catalog

The Helpdesk module is linked to the service catalog in order to:

  • define which service and service subcategories can be selected for a given customer

  • define to which team a user request can be assigned

  • compute time to own (TTO) and time to resolve (TTR) deadlines

The list of services displays only the service that have been purchased by the selected customer via a customer contract. The list of service subcategories displays only the sub categories corresponding to the selected service and the selected request type.

The following picture describes the relationships between the service catalog elements and user requests.

https://www.itophub.io/wiki/media?w=500&tok=e22674&media=2_7_0%3Adatamodel%3Arelationshipswithservicecatalog_userrequest.png

Only Services with a defined Service Family are proposed in the Enhanced Portal

Assigning a user request to a team and agent

The list of teams to which you can assign a user request is defined by the delivery model of the corresponding customer. When creating a user request, 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

The following picture describes the relationships between the delivery model and user requests.

https://www.itophub.io/wiki/media?w=500&tok=8e8e75&media=2_7_0%3Adatamodel%3Arelationshipswithdeliverymodel_userrequest.png

Automated priority computation

The priority is computed automatically. This computation depends on the impact and the urgency of the user request. The following matrix describes how the priority is computed:

Urgency / ImpactDepartmentServicePerson
criticalcriticalcriticalhigh
highcriticalhighmedium
mediumhighmediummedium
lowlowlowlow

Deadline computation

To meet service agreements with customers, iTop automatically computes time to own (TTO) and time to resolve (TTR) deadlines. These deadlines depend on the service level agreements defined in the customer contracts. In the basic version of iTop there is no coverage window. The calculations assume a 24*7 service coverage.

The measured TTO is the time cumulated while the user request is not assigned. When the TTO deadline is passed, the ticket status is automatically changed to “Escalated TTO”.

The measured TTR is the time cumulated while the user request is neither pending nor resolved. When the TTR deadline is passed, the ticket status is automatically changed to “Escalated TTR”.

The computation of the deadlines depends on:

  • The service level agreement defined in the customer contract for the selected service

  • The priority of the user request

  • The type of request

These are defined in the service level targets (SLT) corresponding to the service level agreement (SLA).

The deadlines computation is performed each time a modification is made on the user request.

When the cumulated TTO/TTR reaches 75% of the TTO/TTR deadline, then the user request is displayed in yellow. Once the deadline is passed, it becomes red.

Once the user request is resolved, deadlines and measures are kept within the user request. This can be used both for analyzing process issues and for reporting purposes.

The following information are recorded:

  • TTO deadline (date and time)

  • TTO cumulated (seconds)

  • TTO passed (yes / no)

  • TTO overrun (seconds)

  • TTR deadline (date and time)

  • TTR cumulated (seconds)

  • TTR passed (yes / no)

  • TTR overrun (seconds)

Regrouping User Request

It is sometimes useful to regroup user requests under an incident which is the root cause of the issue. For instance when a mail server is down, you may have several end users complaining about mailbox being unavailable.

To group user requests, use the field parent request.

If an incident ticket is parent of a user request, then each time its private and public logs are modified, iTop will automatically update the logs of the child requests. When the parent incident get resolved, iTop will automatically mark the child requests as “resolved”.

User Request Life Cycle

https://www.itophub.io/wiki/media?w=600&tok=101ec5&media=2_7_0%3Adatamodel%3Alifecycle_userrequest.png

 NewAssignedEscalated TTOWaiting for approvalResolvedPendingEscalated TTRClosedApprovedRejected
OrganizationMMMMR/OMMR/OMM
CallerM MMR/O  R/OMM
StatusR/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
Origin    R/O  R/O  
Title    R/O  R/O  
Description    R/O  R/O  
Service    M  R/O  
Service subcategory       R/O  
Hot FlagH HHR/O  R/OHH
Hot reasonH HHR/O  R/OHH
Pending reasonHHHHR/OMHR/OHH
Request Type M  R/OMMR/O  
Impact    R/O  R/O  
Urgency    R/O  R/O  
PriorityR/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
TeamHM  R/OMMR/O  
AgentHMHHR/OMMR/OHH
ApproverHR/OH R/OR/OR/OR/OR/OH
Start dateR/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
Last updateR/OR/OR/OR/OR/OR/OR/OR/OR/OR/O
Assignment dateHR/OHHR/OR/OR/OR/OHH
TTO DeadlineR/OHR/OR/OHHHHR/OH
TTR DeadlineHR/OHHHHR/OHHH
Last pending dateHHHHHR/OHHHH
Resolution dateHHHHR/OHHR/OHH
Close dateHHHHHHHR/OHH
Parent request    R/O  R/O  
Parent problem    R/O  R/O  
Parent change    R/O  R/O  
Resolution codeHHHHMHHR/OHH
SolutionHHHHMHHR/OHH
Resolution delayHHHHR/OHHR/OHH
User satisfactionHHHHHHH HH
User commentHHHHHHH HH
SLA tto passedHR/OHHR/OR/OR/OR/OHH
SLA tto overHR/OHHR/OR/OR/OR/OHH
SLA ttr passedHHHHR/OHHR/OHH
SLA ttr overHHHHR/OHHR/OHH

Table key:

  • H: hidden

  • R/O: read-only

  • M: mandatory

标签:
由 superadmin 在 2020/08/27, 17:32 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司