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