IT 服务台：现成的计算模型
模板已在 FlowVisual 中：分诊、分支、第一层级和第二层级，数量、区间、产能和费率已填入。它可在二十分钟内显示，时间是损失在处理过程中还是之前。
IT 工单模板将支持流程表示为三个工作步骤和一次分支：分诊与记录，然后判断“是否可立即解决？”。65% 进入一线解决，35% 进入二线。模板设置为每年 24,000 个工单，工作日约 96 个。在超过 20,000 次运行的压力测试中，分诊在 75% 的运行中为限制性瓶颈，二线为 14%，一线为 11%。服务台理论上每天能处理 118 个工单，而到达 96 个，平均足够，但 26% 的天数不足。中位通过时长为 0.08 个工作日，繁忙日（P90）为 4.9：工单在等待队列中“挂掉”，而不是在处理阶段。
29min
每张工单，按两个分支加权。
0.1 → 4.9天
普通天与繁忙天对比。
75%
不是那个常被认为是瓶颈的第二层级。
6
订单，报价，发票审批，投诉，入职，IT 工单。
模板包含内容
这些数字来自一个示例模型，而非客户委托。它们的取值使之相当于拥有数百名用户的内部 IT 服务。作为起点，而非参考。
入口： 每年 24 000 个工单，也就是每个工作日大约 96 个，日间波动为 28%，在 8% 的日子里有 1.35 的峰值因子。装配、发布、故障。
| 步骤 | 角色 | 比例 | 处理 | 容量 | 负载 Ø | 峰值日负载 |
|---|---|---|---|---|---|---|
| 01 分诊与记录 | Servicedesk | 100 % | 5–10 min | 2 人 × 8 h → 118/天 | 84 % | 129 % |
| 决定：能否立即解决？ | ||||||
| 02 一级解决 | Support | 65 % | 8–18 min | 105/天 | 62 % | 86 % |
| 03 二级 | IT | 35 % | 25–55 min | 7 人 × 7 h → 62/天 | 57 % | 91 % |
“比例”这一栏是本模板与其他模板不同的原因：第二层只看到三分之一的工单。如果按总量来计算其利用率，会得到 155%，从而把一个标示为 57% 的步骤判断为过载。
关键发现。 来自 20 000 次模拟的各步骤成为瓶颈的概率：
| 步骤 | 瓶颈概率 | 超出容量的天数 |
|---|---|---|
| 01 分诊与记录 | 75 % | 26 % |
| 02 一级解决 | 11 % | 4 % |
| 03 二级 | 14 % | 7 % |
该列相加为 100%：每次运行都会计为恰好一个约束步骤，即当天利用率最高的步骤。
二级在公司内部被认为是导致长交付时间的原因，但在 14% 的运行中才是瓶颈。Servicedesk 只是“接收”工单，耗时五到十分钟，却在 75% 的运行中成为瓶颈。流程在开始前就丢失时间，而不是在实际工作中丢失时间。
而这正是表格无法展示的地方：每张工单五分钟看起来无伤大雅，但 96 张工单乘以五到十分钟就不是小数目。
您要替换的六个数字
其他任何内容都可以保持不变。谁做更多调整，并不会改善结果，只会延长期限。
- 每工作日工单数。 用去年工单数 ÷ 工作日天数。该数值出现在 Helpdesk 报告中，也在统计重复和合并工单的地方。请使用您稍后复测时会用的同一定义。
- 峰值因子。 在最繁忙的一天与平常一天相比会到多少？周一、发布后的第二天、故障当天。1.3 到 2 的因子很常见。没有这个值会导致估算出一个从未处于高负载的 Servicedesk，而对于工单来说，高负载是常态。
- Servicedesk 的人员与他们用于分诊的工时。 不是团队编制人数。那种一边接电话一边做分诊的人并没有八小时都用于记录。
- 分诊的处理范围。 给出下限和上限。密码问题五分钟，需重建过程的一条故障报告二十分钟。恰是这一区间决定等待时间。
- 能立即解决的比例。 模板里是 65 比 35。这个数在每份 Helpdesk 报告里以“First Contact Resolution”出现，是您唯一真正能测量的数值。它只是把负载在分支之间移动，而不是影响分支之前的负载。
- 每个角色的全成本费率。 税前工资 ×1.5 到 1.8，除以约 1 500 年生产工时。在每年 24 000 个事务的情况下，每一欧元的费率差异都会放大；用工资 ÷ 2 080 小时得到的简单费率会使后续的欧元结论受到质疑。
在计算前的交叉验证： 在系统中数一数未完成的工单，再除以您一天关闭的工单数（Little's Law）。如果得到您已知的在途时间，模型就是可用的。如果差别很大，说明少了一个排队环节——对于工单来说，几乎总是缺少“等待用户回复”这一状态。
模板不包含的内容。 交付时间等于处理时间加上以工作日计的等待时间。模板未建模优先级：模型按到达顺序工作。若您有真实的优先级策略，应将其建为第二条带自己容量的分支；否则模型会对紧急工单算得过慢，对其余工单算得过快。同样未涵盖的还有工单在等待用户期间的静置时间。
四个杠杆，逐一计算
每次只改变一个杠杆。三个同时改变会产生一个无法归因于单一杠杆的数字，因此无法形成商业案例。以下四次运行使用相同模板，每次仅改变一项输入。
| 杠杆 | 周转时间 P90 | 高峰日分诊负荷 | 每张工单工时成本 | 新的最可能瓶颈 |
|---|---|---|---|---|
| 模板原始状态 | 4.9 天 | 129 % | €28.82 | 分诊（75 %） |
| 1 入口处使用表单（5–10 → 3–6 分钟） | 0.22 天 | 77 % | €26.38 | 一线（53 %） |
| 2 服务台增加第三人 | 0.38 天 | 86 % | €28.82 | 一线（46 %） |
| 3 知识库拦截 20 %（96 → 77/天） | 0.86 天 | 103 % | €28.82 | 分诊（75 %） |
| 4 更多工单当场解决（65 % → 75 %） | 5.0 天 | 129 % | €25.34 | 分诊（68 %） |
杠杆 1：入口处使用表单。 设备、应用、故障现象和紧急程度设为必填字段。分诊时间从 5–10 分钟降到 3–6 分钟，因为无需再还原情况。效果：周转时间的 P90 从 4.9 降到 0.22 个工作日，高峰日负荷从 129 % 降到 77 %。这是所有杠杆中成本最低的一个，也是唯一不需要增加人手的。
杠杆 2：服务台增加第三人。 同样效果明显（0.38 天），但要多一个岗位。它与杠杆 1 的对比，才是这张表真正要说的。
杠杆 3：知识库提前拦截 20 % 的工单。 工单越少越好，但它解决不了瓶颈：分诊在 75 % 的运行中仍是限制步骤，高峰日负荷只从 129 % 降到 103 %。少五分之一的量，只是让这个步骤勉强越过界线，仅此而已。
杠杆 4：在一线解决更多工单。 最有意思的零结论。把首次接触解决率从 65 % 提高到 75 % 是支持领域的标准建议，而且确实有效：每张工单的工时成本从 €28.82 降到 €25.34，因为昂贵的二线工时被便宜的一线工时取代。周转时间却没有跟着下降，甚至升到 5.0 天。这个杠杆省的是钱，不是时间。 如果把它当作提速措施来卖，就把一项本身正确的措施卖错了。
把四个杠杆分别计算，按每单位投入的效果排序。杠杆 1 是一张表单，杠杆 2 是一个岗位，而在模型中两者只差 0.16 天。
20,000 次运行如何变成每个步骤的百分比，见文章 流程的 Monte Carlo 仿真；为什么 85 % 的利用率已经太高，见 计算瓶颈。
最终纸面上的内容
在 捕获前、改变一个杠杆并进行第二次运行之后，页面标题栏中的 证明 显示：
- 变更前/变更后 周转时间，以 P50 和 P90 表示。服务承诺应针对 P90，而不是针对中位数。SLA 声明正是在这里与平均值声明不同：中位数为 0.08 天，但承诺仍会在每第十天被打破。
- 各步骤在高峰日的利用率以及措施后的新瓶颈。在此模型中，瓶颈在四个杠杆中的两个上移到了第一级。
- 吞吐量，以每周工单对比到达量表示：当前状态为 455 对 480。差值即为服务台每周重新积累的积压。
- 每工单的人工成本及年度成本，基于数量、时间和全成本费率计算。在 24,000 个事项下，每一分欧元都会产生影响，模板按每工单 28.82 € 计算。
- 假设清单，列出每一项估计输入。语句“未对优先级和休息时间建模”能在最尖锐的质疑提出之前先行化解。
输出为两份 PDF：一份给决策者的建议书，一份用于可追溯性的文档。带试用标记时免费；使用 Pro 则无水印，并带有您的信头。
同一模板，两类问题。 本页回答的是计算性问题：75% 的来源以及为什么减少五分之一的工单未能解决瓶颈。另一个问题（会推荐什么、滞留工单的成本是多少）属于方法范畴而非工具功能。该内容可在 FLOWREFY 的分析档案 中找到，与生成这些模板的 方法 一并收录。一个数据集，两类问题，两个读者群。
其他模板
随附六个模型。全部按同一模式：结构已成型，数字典型，有六个可调数值，且恰有一个明确瓶颈。
- 包含于
- FlowVisual 适用于 macOS 12+ 和 Windows 10/11，位于“浏览模板”或 文件 → “模板…”中
- 范围
- 3 个处理步骤，一项带有 65/35 路由比例的决策，具有离散性与峰值因子的到达量，产能，处理时长区间，角色，成本费率
- 需调整
- 工单/天，峰值因子，服务台分诊工时，分诊时长区间，立即解决比例，小时费率
- 计算依据
- 20,000 次运行，Seed 42。App 默认计算 400 次。中位数保持不变，P90 会变化几个百分点
- 典型陈述
- 瓶颈在分诊阶段（75 %），而不是第二级（14 %）
- 数字来源
- 示例模型，无客户数据。模板中已标注为示例
常见问题
为什么分诊是瓶颈而不是第二级？
因为分诊会看到每个工单，而二线只看到三分之一。服务台理论上每天能处理 118 个工单，但实际收到 96 个；二线能处理 62 个，收到 34 个。平均来看两者都低于临界值，但分诊的利用率是 84 %，二线是 57 %，而当利用率大约超过 85 % 时，排队增长速度会超过利用率上升的速度。在繁忙日，分诊的利用率达到 129 %。每张工单五分钟看起来无关紧要；但 96 张工单分别耗时五到十分钟就不是这样。
模板中的数字是真实的客户数据吗？
不是。这里是示例值，符合内部 IT 服务的典型数量级，并在模板中注明为示例。它们的作用是让模型能立即运行。应当用您自己的六个数字替换这些值。
更高的首次解决率会缩短 周转时间 吗？
不会，它降低的是成本。在模型中，从 65 % 提高到 75 % 会将每张工单的工时成本从 €28.82 降到 €25.34，因为第二层的昂贵分钟被第一层的廉价分钟替代。繁忙日的通过时间仍约为五天，因为限制步骤位于分支之前且不受其影响。措施是正确的，只有理由不对。
我们按紧急程度处理。为什么模板不据此计算？
因为优先级不改变容量，只改变顺序：紧急工单会更快，其他所有工单会更慢，平均等待时间保持不变。因此模板按到达顺序计算。如果您想查看对两类的影响，请将它们建模为具有各自容量的两个分支；比较会显示优先处理一类对另一类的代价。
为什么只用知识库拦截 20 % 的工单还不够？
它有帮助，但并未解决瓶颈。在模型中，分诊在高峰日的利用率从129％降至103％。在75％的仿真运行中它仍然是限制步骤，且通过时间的P90从4.9天降至0.86天。入口处的一份表单将分诊自身的处理时间从5–10分钟缩短为3–6分钟，会使其变为77％和0.22天。减少数量会线性起效，缩短处理时间会影响队列，而队列在这里就是整个通过时间。
我是否必须使用模板，还是可以直接开始？
您可以直接开始。根据经验，第一个自建模型通常做得过于细化（三十个步骤而不是三个），额外的细化增加输入工作，却不改变瓶颈。在现成模板中花三十秒可避免这点。
打开模板并输入您的六个数值
下载 FlowVisual，选择“浏览模板”，打开 IT 工单模型。建模、压力测试和保存都免费。
Guide: seven steps to the number