プロセス記録とプロセスシミュレーション：それぞれができること

Inhaltsverzeichnis+

プロセス記録が提供するもの

記録は、計算したい人々に過小評価されがちです。共通の図を持つことの利点：

• 現実に関する争いを終わらせます。 同じプロセスを別々に記述していた二つの部門は、図で初めて違いに気づきます。
• 責任を可視化します。 スイムレーンは引き渡しを示し、引き渡しは作業が滞る箇所です。
• 文書化、教育、監査、ソフトウェア開発の基礎となります。 計算モデルはそれには向きません。
• ほとんどコストがかかりません そしてプロジェクトではなくワークショップで作られます。

一般的な形式の違いは、擁護者が主張するほど大きくありません：

バリューストリームは計算に最も近いです：滞留時間と在庫を扱います。しかしそれは典型的な作業をある一日の時点で測るため、繁忙日の挙動には答えられません。

どの記録にも書かれていないこと

記法に関係なく、四つの情報が欠けています：

1. 到着量とその変動。 「1日あたり120件」や「月初に180件」はどの図にもありません。
2. 処理時間のばらつき。 「10分」と書かれたボックスは平均値です。しかし待ち行列は平均ではなく分布から生じます。
3. 役割ごとの能力。 3人×7時間のような生産的な時間です。この数値がなければ稼働率は出せません。
4. カレンダーとコスト。 いつ作業するか、その役割の1時間あたりのコストです。

これら四つがなければ、どの図も計算できません。BPMNにシミュレーションモジュールがあっても同様です：それらの値は個別のダイアログに入力する必要があります、詳しくはBPMN-Simulationを参照してください。

図が失敗する四つの問い

「ボトルネックはどこですか？」 図ではどのボックスも同じに見えます。ボトルネックは最も高い稼働率の工程であり、稼働率は図の性質ではありません。

「悪い場合はどれくらい時間がかかりますか？」 図には分布がありません。P50とP90の違いを図は知ることができず、約束はP90に対して行われます。

「ステップ3を自動化したらどうなりますか？」 図ではボックスが消えますが、実際には全量が次の工程に押し寄せ、ボトルネックが移動します。この連鎖効果が自動化プロジェクトの数値が外れる最も一般的な理由です。

「これはユーロでどれだけの価値がありますか？」 それには数量、時間、料金、そして大部分のコストが滞留する待ち行列が必要です。

記録で十分な場合

すべてのプロセスが計算モデルを必要とするわけではありません。以下の場合は記録で足ります：

• 誰も待っていない。 プロセスが容量のかなり下で動いているなら、処理時間がリードタイムです。その場合は加算する方がシミュレーションより正直です。
• 目的が文書化である。 監査、教育、引継ぎ、証明義務。
• プロセスが新設で誰も数値を持っていない。 まず描き、次に数値を集め、最後に計算します。
• 決定が既に固まっている。 既定の決定を裏付けるためのモデルは分析ではなく装飾です。

図からモデルへ：手順

移行は、多くの人が想定するよりも費用がかかりません。但し図をそのまま持ち込む衝動に抗える場合です。

1. 大まかに要約する。 文書化に耐える記録は30の活動を持ちます；計算モデルは5〜10を必要とします。 同じ役割が連続して行う作業をまとめてください。
2. 分岐は実態に合わせて減らす、各辺ごとの割合で示し、すべての例外を含めないでください。
3. 中断（離脱）を補う。 プロセスを離れるもの（拒否、取り下げ、放置）を含めてください。記録にはほとんど欠けていますが、計算では重要です。
4. 四つの欠けている情報を取得する。 これが実際の作業です：中規模のプロセスなら約2時間です。
5. 計算し、Little's Lawで検算する。 在庫 ÷ 日次スループット を計算されたリードタイムと比較してください。

転記に20分、データ収集に2時間を見積もってください。これらの比率を知れば、人は図をコストの高い部分だとは考えなくなります。

並列比較

実務的なルール： 両方を使いますが、順番に行い、同一の成果物に両方を詰め込まないでください。文書化と計算モデルを同時に満たそうとすると、双方について細かすぎるか粗すぎるものになります。