4 个真实场景

这些是组织常见的四个真实场景。我们将从如何重新定义员工入职请求开始，这是另一种最常见的服务请求形式。然后，我们将讨论如何处理重大事件并尽快恢复服务。第三，我们将看到如何以最低风险实施重大变更，最后，我们将在 IT 资产管理 的背景下，了解如何在企业范围内推行操作系统升级。

这四个案例研究基于其他组织面临的情况以及我们与客户的互动经验。毋庸置疑，即使在 Zoho，我们也曾遇到这些情况。基于所有这些经验，我们设计了这些工作流，帮助您在 ITSM 工具中顺利过渡到最佳实践。话不多说，让我们直接进入今天的第一个场景：重新定义您的新员工入职请求。

如何将每个服务请求转变为提升 ITSM 成熟度的体验

所以，我们将展示如何将您的服务请求转变为对终端用户、招聘经理和新员工来说非常满意的体验。

案例研究：新员工请求——填补 8000 个空缺职位

这是我们这里的案例研究。我们有一家位于加利福尼亚的跨国科技公司，设计、开发并销售消费电子产品。该公司目前正处于快速扩张阶段。为了支持这一快速扩张，他们正在积极招聘，填补近8,000个空缺职位，这些职位分布在纽约、西雅图和德克萨斯等不同地理位置，也分布在硬件、软件和服务等不同领域。请记住，这种入职……让我重新表述，这种大规模入职需要在非常短的时间内完成。

从整体来看，单个新员工入职请求包含的内容是这样的。您有多个不同的部门，如HR、IT、法务、设施部门，他们都必须执行各自的一系列任务。执行这些任务时还涉及许多相互依赖关系。

例如，IT部门只有在设施部门提供了新员工的办公桌和工作站后，才能配置IT设备和IT服务。因此，如果没有入职策略或实施平台，组织将不得不使用电子表格和电子邮件等传统解决方案来管理这一切。平均而言，单个新员工入职请求，您的组织大约会发送五到六封电子邮件。

现在，将这一情况扩展到8,000个新员工入职请求。通过电子邮件处理如此大量的数据非常困难，而且很可能会遇到各种障碍，首先是您会丢失大量重要数据，因为在跟踪大量进入收件箱的电子邮件时出错是非常常见且人之常情的。我们还提到，执行任务涉及多个部门和多名技术人员。如果缺乏有效的沟通和协调，许多IT孤岛可能会出现，导致入职流程出现漏洞和不一致。

这导致您的服务台无法跟踪某些任务，任务因此被遗漏。缺乏对常规任务（如审批、路由、

分配）的自动化会导致大量延误。在我看来，没有SLA是一个严重错误，因为SLA确保您建立客户期望并及时满足这些期望。因此，所有这些障碍都会导致招聘经理、新员工以及服务台生产力本身的体验非常不满意。那么，您如何克服这些障碍呢？

为了让员工入职顺利进行，其应如何运作

这是我们Zoho遵循的最佳实践框架。招聘经理提出新员工请求，服务台收集新员工需求的必要详细信息。然后自动化启动，触发五阶段审批机制，随后服务请求被路由到合适的技术人员，由其执行各种任务。在整个过程中，后台有一个严密的SLA计时。

这就是您如何将服务请求从发起到完成的全过程，这里讲的是服务台方面。在整个过程中，您需要通过持续发送通知让终端用户保持知情。

这样可以确保他们不会频繁打扰您进行帮助台呼叫或创建重复请求。这就是理论上的最佳实践，接下来让我们看看如何使用具备相应功能的ITSM工具来实现它。

为此，我们将查看ManageEngine ServiceDesk Plus。您现在屏幕上看到的是招聘经理的自助门户。如您所见，招聘经理可以报告问题、请求新服务或浏览知识库中的现有解决方案。现在让我们让招聘经理请求一项新服务。

当我点击请求服务时，组织的服务目录弹出。选择User Management并点击Single User Onboarding。您面前看到的是一个非常典型的网页表单，您在任何组织（包括您所在的）都见过。顶部显示SLA，设定了招聘经理的期望。最开始是一些基本信息，如姓名、地点、描述，向下滚动，只剩一个字段。这很令人惊讶，因为我们之前提到新员工入职有很多需求，而这里只有一个字段来捕获所有信息。

让我们看看这里发生了什么。我选择该字段为permanent。点击permanent后，一组新的字段弹出。

这就是我们所说的动态表单。动态表单确保终端用户无需填写冗长的表单，同时帮助服务台捕获与服务请求相关的正确且简明的信息。正如您所见，一旦我选择了一个角色，比如regional field manager，另一组不同的字段就会弹出。

现在我们已经看到招聘经理门户中的网页表单，让我们看看技术人员在其门户中如何查看它。这是组织的技术人员门户，进入Service Catalog，点击User Management，选择相同的Single User Onboarding。

如您所见，这是与终端用户或招聘经理看到的相同网页表单，但有明显差异。这里显示了总成本，许多之前不可见的字段现在可见，如审批、组等。

向下滚动，我们看到资源、成本明细，最重要的是任务选择。技术人员可以自主选择需要为特定服务请求执行的任务。那如何做到的？如何为同一服务分别为招聘经理和技术人员创建定制表单？让我们继续了解。

我点击这里的Admin Module，右侧可以看到Service Catalog。这是我们创建service templates的地方。所有服务项目都分类整齐。我滚动到User Management，点击Single User Onboarding模板。这里是我们构建网页表单的地方。我们有一个拖放画布，您可以拖动所需字段到模板中，并以视觉上吸引人的方式排列它们。您甚至可以添加不同数据类型的新字段。

如您所见，各个部分整齐排列，向下滚动看到名为Resource Info的部分，您可以添加问题，向招聘经理询问有关新员工需求的内容。然后是成本详情。您还可以将不同支持组关联到特定服务模板。最后，您可以将创意模板仅公开给特定用户组。

例如，您可能有一个仅HR团队可访问的HR专用模板。正如您所见，该模板考虑了所有因素，帮助您设计网页表单。

最后，让我们使网页表单动态化。我们有field and form rules功能，帮助您在招聘经理填写网页表单时执行基于条件的操作。

让我们回到最佳实践工作流，看看进展。招聘经理提出新员工请求，服务台通过定制的动态网页表单收集员工详细信息。剩下的就是配置服务请求将经过的工作流，这可以在模板的单个标签页中完成。

我点击这里的workflow标签页，里面包含审批机制、SLA以及为完成请求需要执行的不同任务。ServiceDesk Plus中最多可添加五个审批阶段，这些审批可以是命名审批或基于角色的审批。

现在我们配置了审批流程，接下来添加新的SLA。在这里定义或强制响应和完成的时间限制，若违反这些时间限制，您可以配置升级机制。

创建审批机制和配置SLA后，您需要定义为完成此服务请求需要执行的各种任务。您可以添加不同任务，分配给不同支持组或特定技术人员，并确保按正确顺序执行。之前提到有许多相互依赖关系，这里就是考虑它们的地方，确保有效跟踪，避免任务遗漏，利用依赖功能。

配置任务依赖后，确保任务按正确顺序执行。例如，外部配件的提供和软件安装必须在所需硬件采购后进行。所有任务完成后，才进行新员工的入职流程。这样确保没有任务遗漏，且相互依赖得到妥善处理。

现在我们创建了工作流，定义了SLA，并确保服务模板生效。回到最佳实践工作流，我们经历了每一步，如路由、五阶段审批机制、SLA和任务。剩下的就是查看服务请求的实际运行情况。服务请求已创建，所有新员工信息以整齐格式呈现。您面前显示服务成本，向下滚动看到对话标签。

您可以从这里与招聘经理发起对话以澄清问题。此操作在服务工单内完成，向下还有工单特定属性，如分类、归类和分配。

我快速浏览服务请求中的不同标签。我们看到很多关于任务的信息。模板中配置的所有任务都在这里体现，技术人员在处理服务请求时，可以通过工作量记录所花费的努力和时间。

这是审批在服务请求中的体现。不同阶段的审批既有命名审批，也有基于角色的审批。时间分析帮助您跟踪与服务请求相关的重要指标。最后，历史标签提供了服务请求所有操作的详细审计，且所有操作均有时间戳。

再次回到最佳实践工作流。我们遵循了每一步，将服务请求从发起到完成。现在只剩一步，即通知终端用户服务请求的进展。

利用自动化，Notification rules功能帮助您根据服务请求的操作发送自动通知。您可以选择在收到新请求时通过电子邮件向请求者发送确认。同样，当技术人员被分配或请求关闭时，也可以发送类似通知。所有通知模板均可自定义，便于添加工单特定信息。这样，使用最佳实践工作流，您就能在极短时间内完成8,000名员工的入职。

现在我们已经制定了策略，并了解了ITSM平台如何帮助实现最佳实践工作流。

关键绩效指标（KPI）

接下来是持续服务改进。我们将利用一些关键绩效指标（KPI）。这不是详尽列表，但包含我们认为您应关注的主要KPI。包括工单量、技术人员生产力、解决时间和待处理请求数量。这些都可以通过ServiceDesk Plus的报告模块进行衡量。

您拥有150多个预配置报告，帮助您监控各种指标。如果这些还不够，您可以创建自己的custom reports，并安排发送邮件给特定利益相关者。此外，还有图形化仪表板，实时呈现信息，帮助您跟踪服务台的表现。这就是我们今天第一个场景的结束。

4 个真实场景

这些是组织常见的四个真实场景。我们将从如何重新定义员工入职请求开始，这是另一种最常见的服务请求形式。然后，我们将讨论如何处理重大事件并尽快恢复服务。第三，我们将看到如何以最低风险实施重大变更，最后，我们将在 IT 资产管理 的背景下，了解如何在企业范围内推行操作系统升级。

这四个案例研究基于其他组织面临的情况以及我们与客户的互动经验。毋庸置疑，即使在 Zoho，我们也曾遇到这些情况。基于所有这些经验，我们设计了这些工作流，帮助您在 ITSM 工具中顺利过渡到最佳实践。话不多说，让我们直接进入今天的第一个场景：重新定义您的新员工入职请求。

如何将每个服务请求转变为提升 ITSM 成熟度的体验

所以，我们将展示如何将您的服务请求转变为对终端用户、招聘经理和新员工来说非常满意的体验。

案例研究：新员工请求——填补 8000 个空缺职位

这是我们这里的案例研究。我们有一家位于加利福尼亚的跨国科技公司，设计、开发并销售消费电子产品。该公司目前正处于快速扩张阶段。为了支持这一快速扩张，他们正在积极招聘，填补近8,000个空缺职位，这些职位分布在纽约、西雅图和德克萨斯等不同地理位置，也分布在硬件、软件和服务等不同领域。请记住，这种入职……让我重新表述，这种大规模入职需要在非常短的时间内完成。

从整体来看，单个新员工入职请求包含的内容是这样的。您有多个不同的部门，如HR、IT、法务、设施部门，他们都必须执行各自的一系列任务。执行这些任务时还涉及许多相互依赖关系。

例如，IT部门只有在设施部门提供了新员工的办公桌和工作站后，才能配置IT设备和IT服务。因此，如果没有入职策略或实施平台，组织将不得不使用电子表格和电子邮件等传统解决方案来管理这一切。平均而言，单个新员工入职请求，您的组织大约会发送五到六封电子邮件。

现在，将这一情况扩展到8,000个新员工入职请求。通过电子邮件处理如此大量的数据非常困难，而且很可能会遇到各种障碍，首先是您会丢失大量重要数据，因为在跟踪大量进入收件箱的电子邮件时出错是非常常见且人之常情的。我们还提到，执行任务涉及多个部门和多名技术人员。如果缺乏有效的沟通和协调，许多IT孤岛可能会出现，导致入职流程出现漏洞和不一致。

这导致您的服务台无法跟踪某些任务，任务因此被遗漏。缺乏对常规任务（如审批、路由、

分配）的自动化会导致大量延误。在我看来，没有SLA是一个严重错误，因为SLA确保您建立客户期望并及时满足这些期望。因此，所有这些障碍都会导致招聘经理、新员工以及服务台生产力本身的体验非常不满意。那么，您如何克服这些障碍呢？

为了让员工入职顺利进行，其应如何运作

这是我们Zoho遵循的最佳实践框架。招聘经理提出新员工请求，服务台收集新员工需求的必要详细信息。然后自动化启动，触发五阶段审批机制，随后服务请求被路由到合适的技术人员，由其执行各种任务。在整个过程中，后台有一个严密的SLA计时。

这就是您如何将服务请求从发起到完成的全过程，这里讲的是服务台方面。在整个过程中，您需要通过持续发送通知让终端用户保持知情。

这样可以确保他们不会频繁打扰您进行帮助台呼叫或创建重复请求。这就是理论上的最佳实践，接下来让我们看看如何使用具备相应功能的ITSM工具来实现它。

为此，我们将查看ManageEngine ServiceDesk Plus。您现在屏幕上看到的是招聘经理的自助门户。如您所见，招聘经理可以报告问题、请求新服务或浏览知识库中的现有解决方案。现在让我们让招聘经理请求一项新服务。

当我点击请求服务时，组织的服务目录弹出。选择User Management并点击Single User Onboarding。您面前看到的是一个非常典型的网页表单，您在任何组织（包括您所在的）都见过。顶部显示SLA，设定了招聘经理的期望。最开始是一些基本信息，如姓名、地点、描述，向下滚动，只剩一个字段。这很令人惊讶，因为我们之前提到新员工入职有很多需求，而这里只有一个字段来捕获所有信息。

让我们看看这里发生了什么。我选择该字段为permanent。点击permanent后，一组新的字段弹出。

这就是我们所说的动态表单。动态表单确保终端用户无需填写冗长的表单，同时帮助服务台捕获与服务请求相关的正确且简明的信息。正如您所见，一旦我选择了一个角色，比如regional field manager，另一组不同的字段就会弹出。

现在我们已经看到招聘经理门户中的网页表单，让我们看看技术人员在其门户中如何查看它。这是组织的技术人员门户，进入Service Catalog，点击User Management，选择相同的Single User Onboarding。

如您所见，这是与终端用户或招聘经理看到的相同网页表单，但有明显差异。这里显示了总成本，许多之前不可见的字段现在可见，如审批、组等。

向下滚动，我们看到资源、成本明细，最重要的是任务选择。技术人员可以自主选择需要为特定服务请求执行的任务。那如何做到的？如何为同一服务分别为招聘经理和技术人员创建定制表单？让我们继续了解。

我点击这里的Admin Module，右侧可以看到Service Catalog。这是我们创建service templates的地方。所有服务项目都分类整齐。我滚动到User Management，点击Single User Onboarding模板。这里是我们构建网页表单的地方。我们有一个拖放画布，您可以拖动所需字段到模板中，并以视觉上吸引人的方式排列它们。您甚至可以添加不同数据类型的新字段。

如您所见，各个部分整齐排列，向下滚动看到名为Resource Info的部分，您可以添加问题，向招聘经理询问有关新员工需求的内容。然后是成本详情。您还可以将不同支持组关联到特定服务模板。最后，您可以将创意模板仅公开给特定用户组。

例如，您可能有一个仅HR团队可访问的HR专用模板。正如您所见，该模板考虑了所有因素，帮助您设计网页表单。

最后，让我们使网页表单动态化。我们有field and form rules功能，帮助您在招聘经理填写网页表单时执行基于条件的操作。

让我们回到最佳实践工作流，看看进展。招聘经理提出新员工请求，服务台通过定制的动态网页表单收集员工详细信息。剩下的就是配置服务请求将经过的工作流，这可以在模板的单个标签页中完成。

我点击这里的workflow标签页，里面包含审批机制、SLA以及为完成请求需要执行的不同任务。ServiceDesk Plus中最多可添加五个审批阶段，这些审批可以是命名审批或基于角色的审批。

现在我们配置了审批流程，接下来添加新的SLA。在这里定义或强制响应和完成的时间限制，若违反这些时间限制，您可以配置升级机制。

创建审批机制和配置SLA后，您需要定义为完成此服务请求需要执行的各种任务。您可以添加不同任务，分配给不同支持组或特定技术人员，并确保按正确顺序执行。之前提到有许多相互依赖关系，这里就是考虑它们的地方，确保有效跟踪，避免任务遗漏，利用依赖功能。

配置任务依赖后，确保任务按正确顺序执行。例如，外部配件的提供和软件安装必须在所需硬件采购后进行。所有任务完成后，才进行新员工的入职流程。这样确保没有任务遗漏，且相互依赖得到妥善处理。

现在我们创建了工作流，定义了SLA，并确保服务模板生效。回到最佳实践工作流，我们经历了每一步，如路由、五阶段审批机制、SLA和任务。剩下的就是查看服务请求的实际运行情况。服务请求已创建，所有新员工信息以整齐格式呈现。您面前显示服务成本，向下滚动看到对话标签。

您可以从这里与招聘经理发起对话以澄清问题。此操作在服务工单内完成，向下还有工单特定属性，如分类、归类和分配。

我快速浏览服务请求中的不同标签。我们看到很多关于任务的信息。模板中配置的所有任务都在这里体现，技术人员在处理服务请求时，可以通过工作量记录所花费的努力和时间。

这是审批在服务请求中的体现。不同阶段的审批既有命名审批，也有基于角色的审批。时间分析帮助您跟踪与服务请求相关的重要指标。最后，历史标签提供了服务请求所有操作的详细审计，且所有操作均有时间戳。

再次回到最佳实践工作流。我们遵循了每一步，将服务请求从发起到完成。现在只剩一步，即通知终端用户服务请求的进展。

利用自动化，Notification rules功能帮助您根据服务请求的操作发送自动通知。您可以选择在收到新请求时通过电子邮件向请求者发送确认。同样，当技术人员被分配或请求关闭时，也可以发送类似通知。所有通知模板均可自定义，便于添加工单特定信息。这样，使用最佳实践工作流，您就能在极短时间内完成8,000名员工的入职。

现在我们已经制定了策略，并了解了ITSM平台如何帮助实现最佳实践工作流。

关键绩效指标（KPI）

接下来是持续服务改进。我们将利用一些关键绩效指标（KPI）。这不是详尽列表，但包含我们认为您应关注的主要KPI。包括工单量、技术人员生产力、解决时间和待处理请求数量。这些都可以通过ServiceDesk Plus的报告模块进行衡量。

您拥有150多个预配置报告，帮助您监控各种指标。如果这些还不够，您可以创建自己的custom reports，并安排发送邮件给特定利益相关者。此外，还有图形化仪表板，实时呈现信息，帮助您跟踪服务台的表现。这就是我们今天第一个场景的结束。