Keith Swenson氏は最近ブログでビジネス・プロセス・シミュレーションの便利さについて取り上げた(リンク)。このことはしばしば議論がおこなわれ、その議論には2つの陣営が存在しているという。
シミュレーションに楽観的な側は、対象とするビジネスプロセスが将来どれだけ利用されるかについて細かい情報が得られることをいくぶん期待しすぎているようだ。
楽観的な側は、そのプロセスに関わる人々が何をするかを正確に定量化できると考えます。シミュレーションはそのような情報を与えてくれるかもしれません。しかしそのためには、将来起きるケースと実行にかかる時間の量を正確に定量化し、実行をおこなう労働者について正確なモデルをシミュレータに与えないといけません。このようなことは可能なのは基本的に同質なケースが非常に多くあり、かつ各労働者のスキル、知識、経験の違いが作業の違いを生じないような場合だけでしょう。ただそのような場合であってもアクティビティ（活動）にかかる時間の情報と状況ごとの情報を正確に追跡するにはシミュレーション結果の評価よりも労力がかかります。楽観的な人たちは過度に期待をしますが、比較的分かりやすいケース、たとえば「負荷を20%多くしたらどれだけリソース消費が増えるか」や「リスクが限りなく低いケースの全ての内90%のケースで1ステップを省略したとしたら、そのリスクを被った時にかかる時間的コストと省略による節約時間はどのような関係になるだろうか」といったケースでも、シミュレーションから良い情報が得られるという保証はありません。
悲観的な側は通常シミュレーションから多くを期待はしない。それでも氏は次のように考える。
シミュレーションをおこなうことでそのモデルが持つ動的な側面について知ることができ、それはプロセスがモデルどおりになっているかを理解する助けになります。形式的な図式を使ったモデルは大抵の人にとって全く違和感のないものとはいえませんが、それでもモデルを理解するためのツールとして開発に携わる全員が使うことができるものです。この「デバッグ」と呼んでもいいような性質によって、開発の次のステップに進む前に基本的な問題をビジネスアナリストは発見することができるのです。
シミュレーションの重要性について両陣営の観点から評する中で、氏は次のように述べている。
悲観的な人たちにとっては、シミュレーションはとても重要なものです。なぜならそれによってビジネスサイドの人が、ビジネスレベルのモデルをシステムドメインのモデルに変換される前に検証することができるからです。変換をして別のレベルに進むほど欠陥は拡大します。だからこそ次のレベルに進む前に、どんな手法であってもデバッグに使えるものがあれば利用することが重要になるのです。
氏はこうも述べている。
楽観的な人たちにとっては、ビジネスドメインモデルのシミュレーションがシステムドメインあるいは実行ドメイン（enactment domain）と関連していること、あるいはしてないことが問題になります。労働者や処理量について的確なモデルを構築するのに多大な時間をかけたとしても、モデルが実際に実行可能なものに変換されれば無意味なものになってしまうかもしれません。ビジネスモデルの段階で最適なフローを生み出すリソースレベルを求めたとしても、実際にモデルが変換されたら最適なソリューションでなかったということが起きるかもしれないのです。システムドメインあるいは実行ドメインでシミュレーションをすればもっと最適化できるでしょうが、これらのドメインはビジネスアナリストにとっては意味のないものですし、その最適な状態をビジネスドメインに変換し直す確かな方法があるとはかぎりません。シミュレーション楽観主義者が今理解しつつあるのは、モデルが変換されるとシミュレーションが劇的に複雑になるという事実です。
Bruce Silver氏はこのテーマについてより深く掘り下げている(リンク) 。氏はプロセスシミュレーションが「非常に価値のあるものになるかもしれない」、しかしそれはシミュレーションツールがある程度は役に立つものである場合だけだ、と述べている。氏はシミュレーションツールにあるべき7つの最重要機能を定義している。まず活動時間と待機時間をパラメータで設定できることについて説明し、それから次のリストを挙げている。
- イベントが起きる確率と時間の設定。BPMN（Business Process Modeling Notation：ビジネスプロセスを図式的に表すための表記法）では、現実世界で起きる例外をイベントで図式化して表現できます。実際、そのような現実での例外は大抵、AS-ISプロセスでパフォーマンスを害する根本的な原因となっています。期待するTO-BEへ改善をおこなうには、プロセスモデルにおいてイベントの発生する確率と時間が設定できるようにする必要があります。
- 反復アクティビティ。BPMNにはループ（DoWhile）とマルチインスタンス（ForEach）と呼ばれる2種類の反復アクティビティがあります。反復アクティビティのためには反復数を表すパラメータをシミュレーションで指定できる必要があります。
- インスタンスのプロパティ。ほとんどのシミュレーションモデルではイベントが起きる確率には関連性がありません。しかし現実世界のプロセスでは、高い関連性があります。たとえば、あるタスクにかかる時間、あるゲートウェイで出力が起きる確率、いくつかのイベントを同時に追跡することになる確率などです。言い換えれば、ある種のクラスのインスタンスは、かかる時間が長くなったり、経路1ではなくゲートウェイ外の経路2を通ったり、その時点で起きている他のイベントよりも起きる確率が高くなる、ということです。シミュレーションのパラメータを定義する方法には、単純な数（平均や標準偏差）ではなく、インスタンスのひとつあるいは複数のプロパティを表現できるものがあります。たとえば、高・中・低の値をもてる優先値がそうです。そのようなパラメータによってより高度にインスタンス生成を設定でき（生成するインスタンスの割合を定義するなど）、より良い結果を得ることが可能になります。
- 代替リソースへの割り当て。ほとんどのシミュレーションツールでは、時間あたりのコストあるいは利用ごとのコストについてのパラメータを決めたり、どれが同一のグループなのかを決められます。しかし、通常利用するリソースはＡ、もしＡが利用できない時はＢに割り当てる、といったことができるツールはあまりありません。
- シミュレーション開始時点の未処理タスクの設定。一般的にシミュレーションモデルはシステムに何もインスタンスがない状態を開始点とします。しかしそれはリソース割り当て最適化のためのユースケースとはなりません。つまり、実際に実行されるプロセスの処理が滞った時でも未処理分の処理を進行できるようにするには、他のさまざまな選択肢を試す必要があるということです。シミュレーション開始時の状態をあからさまに変えるだけでもだめです。
- シミュレーションの生データが使えるようにする。あらかじめ指標やチャートがシミュレーションツールに設定されているのは便利なものですが、それらが実際の分析に必要な詳細情報を与えてくれることはあまりありません。生データを使えるようにするには、各プロセスインスタンスごとの記録や、各アクティビティ/イベントのインスタンスごとの記録がExcelやデータベースにダンピングされるようになってないといけません。それができればアクティビティベースでコストが分かるヒストグラムを作れたり、その他有益な分析が可能になります。それができなければ、きれいな図を見て目の保養ができる程度でしょう。
シミュレーションツールを改善すればシミュレーション結果の質と信頼性も改善される。そうすればシミュレーションの楽天家も悲観家も恩恵が受けられるのではないだろうか。