ITチケットプロセスの完成済み計算モデル

入力： 年間24 000件のチケット、つまり1営業日あたり約96件、日ごとのばらつきは28％、ピーク係数1.35の日が全体の8％です。導入作業、ロールアウト、障害対応。

「割合」列がこのテンプレートを他と異なる読み方にする理由です： 第2レベルはチケットの3分の1しか見ていません。負荷を全体件数で計算すると155 %になり、57 %という数値のステップを過負荷と判断してしまいます。

決定的な所見。 20 000回のランから得られた各ステップのボトルネック確率：

列の合計は100 %になります： 各ランで、その日の最も高い稼働率を示す唯一の制約となるステップが1つだけ数えられます。

社内で長い処理時間の原因とされている第2レベルは、ランの14 %で制約になっています。チケットを「受け取る」だけの役割で、5〜10分かかるサービスデスクは、ランの75 %で制約です。プロセスは作業中ではなく、作業の前に時間を失っています。

ここで表は役に立たなくなります： チケット1件あたり5分は目立ちませんが、96件分の5〜10分は決して小さくありません。

1. 1営業日あたりのチケット数。 過去1年のチケット数 ÷ 営業日数。ヘルプデスクの報告書に記載されています、重複やまとめチケットのカウント方法も同じ箇所です。後で再計測する際は同じ定義を用いてください。
2. ピーク係数。 最も多い日に通常日と比べて何倍になるか。月曜、ロールアウト後の翌日、障害発生日など。係数は通常1.3〜2。これがないとサービスデスクが負荷を受けない計算になり、チケットでは負荷が通常状態です。
3. サービスデスクの人数とトリアージに割く時間。 チームの頭数ではありません。電話対応などを兼務する人は記録に8時間全てを使えません。
4. トリアージの処理時間幅。 下限と上限。パスワードなら5分、再現が必要な障害なら20分。まさにこの幅が待ち時間を生みます。
5. 即時解決される割合。 このテンプレートでは65対35。この数値はすべてのヘルプデスク報告に「First Contact Resolution」として出ます。これだけは実際に計測できる値です。負荷は枝間で移動しますが、前段では変わりません。
6. 役割ごとの全経費率。 総支給額 × 1.5〜1.8、年間生産的時間約1 500時間で除する。年間24 000件の場合、1ユーロの差でも後のユーロ算出に大きく影響します。給与÷2 080時間の単純計算は後で金額の妥当性を損ないます。

計算前の照合： システム内の未処理チケット数を数え、1日に処理するチケット数で割ってください（Little's Law）。既知の滞留時間と一致すればモデルは使えます。大きくずれる場合は待ち行列が欠けているか、チケットではほとんどの場合「利用者の返答待ち」ステータスが抜けています。

テンプレートに含まれないもの。 リードタイムは処理時間と待ち行列の合計で営業日換算です。優先順位付けはモデル化していません： モデルは到着順で動きます。実際に優先順位がある場合は、それを独自のキャパシティを持つ第二の枝として表現してください。さもなければモデルは緊急チケットを遅く、その他を速く計算します。同様に、チケットが利用者の応答を待つ休止時間も含まれていません。

レバー1. 受付フォーム。 機器、アプリケーション、症状、緊急度を必須項目にします。状況を再構成する手間がなくなるため、トリアージは5–10分から3–6分に短縮されます。効果：リードタイムのP90は4.9営業日から0.22営業日に、ピーク日の稼働率は129 %から77 %に下がります。最も安価なレバーで、人員を増やさずに済む唯一のレバーです。

レバー2. サービスデスクに3人目。 同じくはっきり効きます（0.38日）が、1人分の人件費がかかります。レバー1との比較こそが、この表の本当のメッセージです。

レバー3. チケットの20 %を事前に吸収するナレッジベース。 チケットが減るのは常に良いことですが、ボトルネックは解消しません。トリアージは実行の75 %で制約となるステップのままで、ピーク日の稼働率は129 %から103 %に下がるだけです。件数が5分の1減っても、ステップがかろうじて限界を超えたままになるにすぎません。

レバー4. 1次対応で解決するチケットを増やす。 最も興味深い、効果なしの所見です。初回解決率を65 %から75 %に上げるのはサポートの定番の推奨で、実際に効きます。高価な2次対応の時間が安価な1次対応の時間に置き換わるため、チケット1件あたりの作業コストは€28.82から€25.34に下がります。一方でリードタイムは変わらず、わずかに5.0日へ延びます。このレバーが節約するのはお金で、時間ではありません。 これをリードタイム対策として売り込めば、正しい施策について誤った効果を売ることになります。

4つを個別に計算し、手間あたりの効果で並べてください。レバー1はフォーム1枚、レバー2は1人分の人員で、モデル上の差は0.16日です。

20,000回の実行からステップごとの割合がどう出るかは記事プロセスのモンテカルロ・シミュレーションに、なぜ稼働率85 %でもすでに多すぎるのかはボトルネックの計算方法にあります。

「前の状態をキャプチャ」のあと、レバーを1つ変えて2回目を実行すると、ページ見出しの「証明」に次が表示されます：

• 変更前/変更後のリードタイム を P50 と P90 で表示します。サービス保証は中央値ではなく P90 に対して行われます。この点が平均値による表現と SLA 表現の違いです：中央値は 0.08 日を示しても、10 回に 1 回の頻度で保証を破ってしまいます。
• ピーク日の各ステップの稼働率 と、施策後の新しいボトルネック。このモデルでは四つのレバーのうち二つでボトルネックが第 1 レベルに移動します。
• スループット を到着するチケットに対する週あたりの処理件数で示します：現状は 480 件中 455 件です。差分がサービ スデスクが毎週新たに蓄積する作業残です。
• チケットあたりの労働コスト と年間コストを、数量・時間・総原価率から算出します。処理件数が 24 000 件の場合、1 セントの違いが影響し、このテンプレートではチケットあたり 28.82 € を見積もっています。
• 仮定一覧 と各推定入力値。「優先順位付けと待機時間はモデル化していない」という一文が、最も厳しい追及の鋭さを投げかけられる前に和らげます。

出力は2つのPDFです：意思決定者向けの提案書と、追跡可能性のためのドキュメント。無料では試用マーク付き、Proでは透かしなしで自社のレターヘッド入りになります。

同じテンプレート、二つの問い。 このページは計算の問いにお答えします：75 % がどこから来るのか、そして 20 % 減のチケットがなぜボトルネックを解消しないのか。もう一つの問い（何を推奨するか、滞留するチケットのコストはいくらか）は手法に関するものでツールではありません。これは FLOWREFY の 分析アーカイブ に、これらのテンプレートが生まれた 手順 とともに掲載されています。1 件のデータセット、二つの問い、二つの読者層です。

• 受注処理は注文から受注確認までの流れです。役割が分担されている場合：個別には簡単そうに見える二つのステップが、同じ人の午後を占めます。
• 見積プロセスはリードタイムがコストではなく売上に影響するケースです。
• 請求書承認は変動性のある事例です：平均的にはキャパシティ以下ですが、月末にはそれを超えます。
• クレーム処理ではボトルネックが社外にあり、そのため率直な推奨は「自動化しない」です。
• 従業員オンボーディングは量が少なく関係者が多く、あるステップが 86 % の実行を占めます。
• 「IT-Ticket」はこのページです。

各テンプレートは、紹介シートの「テンプレートを参照」またはメニューの「ファイル」→「テンプレート…」から開けます。初めての場合はご自身のモデルを始める前に一つ開いておくとよいです。そうしないと細かく作り込みすぎます。