Der IT-Ticket-Prozess als fertiges Rechenmodell

入口： 每年 24 000 个工单，也就是每个工作日大约 96 个，日间波动为 28%，在 8% 的日子里有 1.35 的峰值因子。装配、发布、故障。

“比例”这一栏是本模板与其他模板不同的原因：第二层只看到三分之一的工单。如果按总量来计算其利用率，会得到 155%，从而把一个标示为 57% 的步骤判断为过载。

关键发现。 来自 20 000 次模拟的各步骤成为瓶颈的概率：

该列相加为 100%：每次运行都会计为恰好一个约束步骤，即当天利用率最高的步骤。

二级在公司内部被认为是导致长交付时间的原因，但在 14% 的运行中才是瓶颈。Servicedesk 只是“接收”工单，耗时五到十分钟，却在 75% 的运行中成为瓶颈。流程在开始前就丢失时间，而不是在实际工作中丢失时间。

而这正是表格无法展示的地方：每张工单五分钟看起来无伤大雅，但 96 张工单乘以五到十分钟就不是小数目。

1. 每工作日工单数。 用去年工单数 ÷ 工作日天数。该数值出现在 Helpdesk 报告中，也在统计重复和合并工单的地方。请使用您稍后复测时会用的同一定义。
2. 峰值因子。 在最繁忙的一天与平常一天相比会到多少？周一、发布后的第二天、故障当天。1.3 到 2 的因子很常见。没有这个值会导致估算出一个从未处于高负载的 Servicedesk，而对于工单来说，高负载是常态。
3. Servicedesk 的人员与他们用于分诊的工时。 不是团队编制人数。那种一边接电话一边做分诊的人并没有八小时都用于记录。
4. 分诊的处理范围。 给出下限和上限。密码问题五分钟，需重建过程的一条故障报告二十分钟。恰是这一区间决定等待时间。
5. 能立即解决的比例。 模板里是 65 比 35。这个数在每份 Helpdesk 报告里以“First Contact Resolution”出现，是您唯一真正能测量的数值。它只是把负载在分支之间移动，而不是影响分支之前的负载。
6. 每个角色的全成本费率。 税前工资 ×1.5 到 1.8，除以约 1 500 年生产工时。在每年 24 000 个事务的情况下，每一欧元的费率差异都会放大；用工资 ÷ 2 080 小时得到的简单费率会使后续的欧元结论受到质疑。

在计算前的交叉验证： 在系统中数一数未完成的工单，再除以您一天关闭的工单数（Little's Law）。如果得到您已知的在途时间，模型就是可用的。如果差别很大，说明少了一个排队环节——对于工单来说，几乎总是缺少“等待用户回复”这一状态。

模板不包含的内容。 交付时间等于处理时间加上以工作日计的等待时间。模板未建模优先级：模型按到达顺序工作。若您有真实的优先级策略，应将其建为第二条带自己容量的分支；否则模型会对紧急工单算得过慢，对其余工单算得过快。同样未涵盖的还有工单在等待用户期间的静置时间。

Hebel 1. Ein Formular am Eingang. Pflichtfelder für Gerät, Anwendung, Fehlerbild und Dringlichkeit。Die Triage fällt von 5–10 auf 3–6 Minuten，weil das Rekonstruieren entfällt。Wirkung: P90 der Durchlaufzeit von 4,9 auf 0,22 Arbeitstage，Auslastung am Spitzentag von 129 % auf 77 %。Der billigste Hebel im Feld，und der einzige，der ohne Personal auskommt。

Hebel 2. Eine dritte Person am Servicedesk. Wirkt ebenfalls deutlich (0,38 Tage)，kostet aber eine Stelle。Das Verhältnis zu Hebel 1 ist die eigentliche Aussage dieser Tabelle。

Hebel 3. Wissensdatenbank，die 20 % der Tickets vorher abfängt. Weniger Tickets ist immer besser，aber es löst den Engpass nicht：Die Triage bleibt in 75 % der Läufe der bindende Schritt，ihre Auslastung fällt nur von 129 % auf 103 % am Spitzentag。Ein Fünftel weniger Menge hebt einen Schritt gerade eben über die Linie，mehr nicht。

Hebel 4. Mehr Tickets im ersten Level lösen. Der interessanteste Null-Befund。Die First-Contact-Resolution von 65 auf 75 % zu heben ist die Standardempfehlung im Support，und sie wirkt：Die Arbeitszeit je Ticket fällt von 28,82 € auf 25,34 €，weil teure zweite-Level-Minuten durch billigere erste-Level-Minuten ersetzt werden。Die Durchlaufzeit ändert sich dabei nicht，sie steigt sogar minimal auf 5,0 Tage。Der Hebel spart Geld，keine Zeit。 Wer ihn als Laufzeitmassnahme verkauft，verkauft das Falsche an derselben richtigen Massnahme。

Rechnen Sie die vier einzeln und sortieren Sie nach Wirkung je Aufwand。Hebel 1 ist ein Formular，Hebel 2 eine Stelle，und im Modell liegen sie 0,16 Tage auseinander。

Wie aus 20 000 Läufen eine Prozentzahl je Schritt wird，steht im Artikel Monte-Carlo-Simulation für Prozesse；warum schon 85 % Auslastung zu viel sind，in Engpass berechnen。

保存当前状态、变更某个杠杆并进行第二次运行后，比较会给出：

• 变更前/变更后 Durchlaufzeit，以 P50 和 P90 表示。服务承诺应针对 P90，而不是针对中位数。SLA 声明正是在这里与平均值声明不同：中位数为 0,08 天，但承诺仍会在每第十天被打破。
• 各步骤在高峰日的利用率以及措施后的新瓶颈。在此模型中，瓶颈在四个杠杆中的两个上移到了第一级。
• 吞吐量，以每周工单对比到达量表示：当前状态为 455 对 480。差值即为服务台每周重新积累的积压。
• 每工单的人工成本及年度成本，基于数量、时间和全成本费率计算。在 24 000 个事项下，每一分欧元都会产生影响，模板按每工单 28,82 € 计算。
• 假设清单，列出每一项估计输入。语句“未对优先级和休息时间建模”能在最尖锐的质疑提出之前先行化解。

输出为两份 PDF：一份给决策者的建议书，一份用于可追溯性的文档；如果您已上传信头，将在文档中使用您的信头。

同一模板，两类问题。 本页回答的是计算性问题：75% 的来源以及为什么减少五分之一的工单未能解决瓶颈。另一个问题（会推荐什么、滞留工单的成本是多少）属于方法范畴而非工具功能。该内容可在 Flowrefy 的分析档案 中找到，与生成这些模板的 Vorgehen 一并收录。一个数据集，两类问题，两个读者群。

• 订单处理 从下单到订单确认整个流程。涉及分工角色的情况：两个看起来各自简单的步骤，其实是同一人在同一天下午完成的。
• 报价流程 是那种 Durchlaufzeit 影响收入而非成本的情况。
• 发票审批 是波动性案例：平均值在产能以下，但月末会超过产能。
• 在 投诉处理 场景中，瓶颈位于厂外，因此诚实的建议不是“自动化”。
• 员工入职 量少但参与者多，其中有一个步骤占用了 86 % 的流程次数。
• IT 工单 就是本页面。

每个模板都可以在欢迎窗口通过 查看模板 打开。第一次使用时，建议先打开一个模板，再开始建立您自己的模型。否则建模时会把细节做得过细。