我希望在一个只有两个人的 IT 部门实施 ITSM。我们有一个基于 Web 的工作流系统，其中定义了五种请求类型，这些请求最终都会进入我们的部门。请求类型划分背后的原理基本上是为了分类，但用户通常不明白应该选择哪种请求类型。
我计划通过只向用户提供一种请求类型来简化系统，然后我们会在必要时更改类型。但我认为，与其按技术领域进行分类（当前的请求类型是计算机支持、Web 支持、ERP 支持、CRM 支持和分析师支持），不如将其分为事件、问题、变更请求和服务请求。旧的分类方式将被替换为将每个请求链接到代表相关服务的项目，这将由我们而不是用户来完成。
现在，我们的工作流系统会将分配给您的所有请求显示在一个巨大的列表中。您可以自定义显示的字段，以便您可以看到哪些是事件，哪些是变更请求。我一直在考虑编写自己的前端，在屏幕上将每种请求类型列在单独的组中。这让我对请求的优先级产生了疑问。每个请求都分配了 1 到 5 之间的优先级，因此优先级 1 的变更请求比优先级 3 的变更请求更重要。但是，优先级 2 的事件比优先级 1 的变更请求更重要，因为它是一个事件吗？因为部门里只有我们两个人，所以我认为我们不能在事件发生时处理变更请求。我一直认为，在构建任何新东西之前，应该先修复损坏的东西。还是我对此一无所知？我们应该忽略请求类型，仅根据优先级来工作吗？
如果我按照正确的方式将所有事件的优先级排在所有其他事件之前，那么我应该如何优先处理其他类型的请求？我最初倾向于接下来处理服务请求，因为我希望它们处理得相当快，然后是变更请求，最后是问题。但是，我有点担心，如果把问题放在最后，它们将永远不会被调查。也许顺序应该是事件、服务请求、问题、变更请求？
答案1
我本来想把这个问题留在评论中，但实际上我要发表一个答案，因为虽然我认为你的意图是好的，但我认为你处理这个问题的方式比你需要的更复杂。
您正在计划某种票务系统，这是件好事，我认为对于超过 20 台计算机的计算机来说，这有助于跟踪事物。您需要记住的是，帮助台系统有多种形式和规模，从华丽的票务列表到具有许多类别、优先级、受让人、升级、SLA 和许多其他花哨功能的非常复杂的系统。您的 IT 部门越大、越独立，这些更复杂的系统带来的好处就越多，但对于较小的部门来说，它们可能比其他任何事情都更麻烦。
为了便于比较，我也在一个只有 2 名员工的 IT 部门工作，因此什么事都做一点，所以服务台上太多不同的选项会妨碍我。我们有一个相对简单的自制服务台，它有一个面向用户的一侧和一个面向技术人员的一侧。
面向用户的一侧具有最少数量的字段，以免信息过载（标题、类别、优先级、受影响的资产标签、问题描述）吓跑用户。所有 IT 问题都记录在这里，我们没有针对变更请求、服务请求等设置不同的系统。我们的类别也故意很宽泛，同样是为了不混淆问题（计算机硬件、打印机问题、Outlook、互联网、常规/其他）。
技术人员这边有更多字段，但仍然不太复杂（受让人、状态、跟进日期）。它为我们提供了足够的灵活性来对工单进行分类（主要用于报告目的），但不会妨碍实际解决问题。我们可以在工单上留下评论，显示我们已经做了什么，如果我们中的一个人需要处理其他人的工单，我们就知道已经做了什么。
我们帮助台的主要目标是跟踪我们的资产遇到的问题（以及谁创建了工单），这样我们就可以了解哪些资产最麻烦，或者哪些人可能需要培训。我们没有任何复杂的操作，例如事件、问题、服务请求、变更请求等的分类 - 这对我们来说是不必要的，所有事情都以工单的形式提交，我们会酌情处理。
如果您想比较优先级，我们的优先级通常如下。用户可以在创建工单时设置优先级，但我们也可以将其与现实情况重新对齐（我们都知道有一位用户为所有事情都创建了优先级 1 的工单 :P）。
- 任何无法工作的人
- 任何有问题但仍能工作的人
- 日常琐事和随机发生的事情
- 项目工作
简而言之，是的，您可能应该实施某种帮助台系统，但也许不需要像问题中描述的那么复杂。最终，您需要每天与此系统交互，因此它需要尽可能简化和易于使用。让流程为您服务，不要尝试使用为数十个 IT 部门设计的流程。如果您对流程的任何部分不满意，请对其进行一些更改，看看效果如何，并不断改进，直到您满意它为您高效工作为止。