JP4439580B2 - プロセスマネジメント支援システム、及びシミュレーション方法 - Google Patents

Description

本発明は、企業のビジネスプロセスを設計してシミュレートすることにより、ビジネスパフォーマンスの予測や評価を行うプロセスマネジメント支援システム、及び該システムにおけるシミュレーション方法に関する。

企業を取り巻く環境に適応したビジネスプロセス、更にはその経営戦略を探索するために、様々なビジネスプロセスモデリングツール及びそのシミュレーション・解析ツールが開発されている。一般的に、ビジネスのタイプには、プロジェクト型とプロセス型が存在する。プロジェクト型のビジネスでは、１つの注文を処理するのに比較的長期間を要し且つその受注頻度は小さく、その仕事の仕方はそれぞれの注文によって異なる。よってこれらビジネスでは、１つ１つの注文ごとに、その注文に応じた仕事の仕方をプロジェクトとして計画する。これに対して、プロセス型のビジネスでは、１つの注文を処理するのに比較的短期間を要し且つその受注頻度は大きく、その処理の仕方は特定の処理プロセス（サービス）によって分類できる。よってこれらビジネスでは、サービスごとに多数の注文を処理する仕方をデザインする。既存の技術に基づくビジネスプロセスモデリングツールは、これら２つの異なるビジネスタイプに対してそれぞれ提供されている。以下、プロジェクト型のビジネスに対するツールをプロジェクトデザインツールといい、プロセス型のビジネスに対するツールをプロセスデザインツールという。

まずプロジェクトデザインツールとして、ネットワーク図及びアローダイアグラムによって、特定の注文について必要な仕事を定義し、その順序及び投入される人的資源の配置について計画することができるものが知られている（例えば、非特許文献１〜非特許文献４参照。）。これらのツールでは、配置された要員とその仕事量に基づいた山積み・山崩しのような簡単な計算によって、１つの注文を処理する際の各要員の負荷及び論理的な最短工期をシミュレーションすることができる。しかし、このシミュレーションは単純な計算であり、仕事の処理を通して発生する様々な不確定要素による遅延など、確率的分散は結果に反映されていない。

これに対して、産業用プロセスなどのモデル及びその評価を行うプロセスデザインツールの一部では、断続的に発生する複数の注文ついて、それぞれの注文のタイプに応じた処理作業を定義し、その順序及び投入される人的資源及びその他資源の配置について計画及びその評価をすることができる（例えば、非特許文献５及び非特許文献６参照。）。これらツールでは、イベントの発生、イベントの保持、イベントの待ち行列、条件分岐、イベントの分割・結合、及びイベントの消去など、様々な機能を有するオブジェクトを組み合わせてそのプロセスを詳細にモデルし、モンテカルロシミュレーションを実行することで、不確定要素による確率的な分散を結果に反映することができる。これらツールでは、その多彩なオブジェクトの機能によって、様々なプロセスを自由に且つ詳細にモデルすることができる反面、その自由度が故に複雑且つ煩雑なモデルとなってしまい、モデル化の重要な目的である可視性及び共有性を損なってしまう。また、シミュレーションによって得られる結果も、イベントのインターバル、待ち行列数、及びレートなど、イベントドリブンシミュレーションにとって基本的なものである。ユーザ自身がそれぞれ独自の評価指標を設定できるが、ビジネスプロセスにとって共通かつ重要な評価指標というものは定義されていない。

近年では、ＵＭＬなどオブジェクト指向に基づいたルールによってビジネスプロセスを記述し、モデルの可視性と共有性を高める方法も提案されている。この動向にあわせて、現実のビジネスプロセスを概念化するモデルを定義し、これらモデルで定義されたオブジェクトによってデザイン及びモンテカルロシミュレーションを実行し、且つその結果を得ることができるツールが登場してきている。この種のツールのうちプロセスデザインツールとして提供されているものの中には、ビジネスプロセスの一部をプロセスの開始と終了、条件によるプロセスの分岐、プロセスを構成する各作業（オペレーション）、及びそれら作業を実行する人的資源、などによってモデルするものがある（例えば、非特許文献７参照。）。シミュレーションにおいては、プロセスの開始オブジェクトでイベントを発生することで、処理するべき仕事を注文として発生する。この発生した仕事は、定義されたプロセスによって処理され、プロセスの終了において消去される。このとき、その処理時間に確率的な分散をもたせるなどすることにより、シミュレーション結果に不確定要素を反映することができる。更に、これらツールでは、１つの仕事が処理されるのに費やされる時間及びコストなどを、モデルしたビジネスプロセスを評価するための尺度として提供している。

更に、プロジェクトデザインツールの中には、プロジェクトの構造及びそのオブジェクトの関係を明確に定義したプロジェクトモデル、シミュレーション結果に反映される不確定要素及びその動作を明確に定義したＢｅｈａｉｖｏｒモデル、及びこのシミュレーション結果を評価するために定義された評価指標を提供しているツール（例えば、非特許文献８〜非特許文献１０参照。）がある。プロジェクトモデルでは、プロジェクトをプロジェクトの開始、終了、その完了に必要な仕事、その仕事に従事する要員、及びマイルストーンなどのオブジェクトとその関係によって定義している。Ｂｅｈａｖｉｏｒモデルでは、仕事アイテム、例外アイテム、及び情報交換アイテムなどシミュレーション中に発生しかつ要員によって処理されるこれらイベントの、発生及び処理に関わる動作及び特性について定義することで、工期、コスト、品質などプロジェクトパフォーマンスに影響を与える不確定要素をモデルしている。

仕事アイテムは、仕事オブジェクトからそのスケジュールに従って定期的に発生し、配置された要員によって処理される。この処理にかかる時間は仕事オブジェクトの特性（仕事の難易度、必要なスキル）及び配置された要員の特性（経験、スキルレベル）によって決定される。例外アイテムは、予測される例外の発生確率、仕事オブジェクトの特性（難易度、必要なスキル）、配置された要員の特性（経験、スキルレベル）、及び情報交換のあり方などによって決定される確率に従って発生する。要員は、発生した例外アイテムに対して、完全な手戻り、半分手戻り、全く無視のいずれかの処理を実行する。どの処理を実施するかは、組織の特性（権利集中性）に従って確率的に決定される。情報交換アイテムは、予測される情報交換確率、仕事オブジェクトの特性（不確実性）及び配置された要員の特性（経験）によって決定される確率に従って発生する。要員は発生した情報交換アイテムを、組織の特性（形式性）によって決定される確率に従って対処する。形式重視の組織では、横の風通しが悪いということで、これら情報交換アイテムが処理される確率は低くなる。

プロジェクトデザインの評価尺度としては、工期、コスト、及び品質を定義している。工期及びコストは、全ての仕事が完了するまでに要した時間、及びその間に投入された人員とその単価の積の総和でそれぞれ定義されている。品質は、不確定要素である例外及び情報交換への対処によって計量している。具体的には、処理された例外及び情報交換アイテムと発生したこれらアイテムのそれぞれの比によって定義している。この品質の計量は、Ｂｅｈａｖｉｏｒモデルが存在することによって可能となっている。更に、デザインされたプロジェクトの分析手法として、各仕事の作業期間、その内訳（直接作業、手戻り、上場交換、指示待ち）、及び遅れ作業量の変化などの指標を用意している。

ひと目でわかるMicrosoft Project Version 2002（マクロソフト公式解説書）、岡野智加、Microsoft Press（日経ＢＰソフトプレス）、２００２ Microsoft Office Project 2003 オフィシャルマニュアル クライアント編（マイクロソフト公式解説書）、E-Trainer.jp, Microsoft Press（日経ＢＰソフトプレス）、２００４ Microsoft Project 2000 ユーザーズガイド、Microsoft Co., 2000 KELLEY, JAMES E., JR., AND MORGAN R. WALKER. Critical path planning and scheduling. Proc. Eastern Joint Computer Conference (1959), 160-173 Business Process Modeling, Simulation, and Design, Manuel Laguna, Johan Marklund, Prentice Hall, 2005 Simulation Modelling for Business, Andrew Greasley, Ashgate Publising, February 2004 Business Process Management: Modeling through Monitoring Using WebSphere V6.0.2 Products, 2007 The Virtual Design Team: An Information Processing Model of the Design Team Management, Cohen, G. P., Unpublished Ph.D Thesis, Stanford University, 1992 The Virtual Design Team: A Computational Model of Project Organizations, Jin, Y. and R. E. Levitt, Computational and Mathematical Organization Theory, 2(3), 171-196 The Virtual Design Team: A Computational Simulation Model of Project Organizations, JOHN C. KUNZ2, RAYMOND E. LEVITT, YAN JIN, Communications of the Association for Computing Machinery, 41(11), pp84-92, 1998

上述したように、プロジェクト型のビジネスで利用されるプロジェクトデザインツールでは、プロジェクトモデル及びその評価尺度を明確に定義し、Ｂｅｈａｉｖｏｒモデルのような不確定要素についても明確に定義したツールが存在する。しかし、プロセス型のビジネスで利用されるプロセスデザインツールでは、ＵＭＬにより可視性及び共有性を高めたツールしか存在しない。即ち、注文の処理に際してその品質、コスト、及び実現納期に影響を与える様々な不確定要素、及び評価指標について明確に定義されたプロセスデザインツールはない。そして、プロジェクト型のビジネスプロセスでの定義をそのままプロセス型のビジネスプロセスに適応することはできない。

また、何れのツールも、注文の処理プロセスという企業内部の要素についてのみ考慮しており、ビジネスプロセスの継続的な改善という本来の目的を鑑みた場合、その改善の動機である企業を取り巻く環境（マーケット）という企業の外部環境について考慮したツールはまだない。言い換えれば、特定の問題に対して適切なプロセスを探索することはできても、企業戦略・経営戦略として企業を取り巻く様々な外部環境に対して適切なビジネスプロセスをデザインすることはできない。即ち、ビジネスプロセスにとってその処理する注文の源である顧客のような外部環境を含めて、ビジネスプロセスを定義したモデルを有するツールはない。以上のように、プロセス型ビジネスについては、企業戦略及び経営戦略のために「その取り巻く環境の変化に対して適応したビジネスプロセスを継続的に探索する」という重要な命題に対して対応するツールはない。

そこで、本発明は、プロセス型ビジネスに関する企業戦略及び経営戦略のために、外部環境の変化に対して適応したビジネスプロセスを継続的に探索することを支援するプロセスマネジメント支援システム及び該システムにおけるシミュレーション方法を提供することを目的とする。

本発明のプロセスマネジメント支援システムは、少なくとも１つのクライアントへサービス提供者がサービスを提供するためのビジネスプロセスをシミュレートすることにより、前記ビジネスプロセスを評価するプロセスマネジメント支援システムであって、前記各クライアントの活動内容を定義するクライアント定義部と、前記サービス提供者が提供するサービスに関して定義するサービス定義部と、所定期間において、前記各クライアントの活動によってサービスの要求が発生し、前記サービス提供者による前記サービスが提供される工程をシミュレートするシミュレーション部とを有し、前記クライアント定義部は、前記各クライアントが行う複数の活動を複数のクライアントオペレーション（ＣＯＰ）のそれぞれに対応させ、前記クライアント毎に前記シミュレート時における前記複数のＣＯＰの進行態様を定義するＣＯＰ定義手段と、前記複数のＣＯＰのそれぞれと、前記各ＣＯＰに対して前記サービス提供者によって提供されるサービスとを対応付けるＣＯＰ対応付け手段と、前記各ＣＯＰからサービスの要求を発生させるための条件を定義する発生条件定義手段とを有し、前記サービス定義部は、前記サービス提供者が前記ＣＯＰに対応付けられたサービスを提供するための手順を、前記サービス提供者の人的資源又は物的資源を対応付ける処理単位である複数のサービスオペレーション（ＳＯＰ）のそれぞれが処理される順序によって定義するＳＯＰ定義手段を有し、前記シミュレーション部は、前記各クライアントについて、前記進行態様に基づいて実行すべきＣＯＰを特定するクライアント処理進行手段と、前記クライアント処理進行手段によって特定されたＣＯＰに対応付けられたサービスの要求を、前記条件に基づいて発生させる要求発生手段と、前記要求が発生する毎に、前記特定されたＣＯＰに対応付けられたサービスに関して前記ＳＯＰ定義手段にて定義された手順として、前記各ＳＯＰの処理を、対応付けられた前記人的資源又は前記物的資源を使用して、前記定義された順序にて処理することにより、前記サービスを提供するための処理を行うサービス提供手段と、を有することにより、上記の課題を解決する。

本発明のプロセスマネジメント支援システムによれば、クライアント定義部を有し、サービスを要求する各クライアントの活動を明確に定義する。クライアントの各活動に対応する各クライアントオペレーション（ＣＯＰ）のシミュレーションにおける進行態様を、ＣＯＰ定義手段によって実際の活動の進行態様と同じように定義すれば、クライアント処理進行手段によってクライアントの実際の活動のようすをシミュレートすることができる。また、各ＣＯＰにサービスの要求を発生させる条件を、実際の活動においてサービスが要求される条件と同じように定義すれば、要求発生手段によってシミュレーションにおいてもクライアントからその条件にてサービスの要求が発生させることができる。サービス提供部は、要求発生手段における要求の発生に応じてクライアントへサービスを提供する。従って、本発明によれば、各クライアントの活動と通じてサービスの要求を発生させ、当該要求に応じてサービスを提供するプロセス型ビジネスの態様をシミュレーションすることができる。これにより、各クライアントによって異なる要求のタイミングや要求回数等に基づいたシミュレーション結果を得ることができ、更には、市況、社会的ニーズ、法制度、及び技術進歩など、企業を取り巻く外部環境を、クライアントオペレーションの動作として定義すれば、企業が適応すべき様々なマーケットの変化をモデルすることができる。この結果、様々なマーケットに対して、最適なビジネスプロセスの探索が可能となる。

ＣＯＰの進行態様には、例えば、ＣＯＰがシミュレーション上で実行状態となる順序、期間、優先度、実行状態となるための条件等がある。サービスの要求を発生させる条件には、例えば、所定の期間や、過去の実績に基づいた要求発生率、所定の項目の状態の他、乱数で発生させる場合も含む。なお、サービス定義部による各サービスの定義は、従来のビジネスプロセスモデリングツールにおける方法を、ビジネスプロセスの評価は、現実のビジネスプロセスの評価手法として一般的な方法を採用すればよい。

前記ＣＯＰ対応付け手段は、前記各ＣＯＰから発生する各要求に対してその要求の属性を定義してもよい。１回の要求についての作業量、複雑性、配達予定時間、対価等はクライアントによって異なるが、本発明のＣＯＰ対応付け手段によれば、これらクライアントによって異なる要求内容をクライアントから発生する要求の属性として設定することができる。

前記ＣＯＰ対応付け手段は、前記各ＣＯＰと前記各ＣＯＰに対して提供されるサービスに関して前記サービス定義部にて定義されるデータとを対応付け、前記シミュレーション部は、前記サービス定義部にて定義されるデータに基づいてシミュレーションを行い、前記シミュレーション部によるシミュレーションによって得られるデータを前記サービスに対応付けて管理し、前記得られるデータに基づいて前記サービスを提供するサービス提供者の活動を評価するための評価指標を求める評価処理手段が更に備えられてもよい。本発明によれば、サービス定義部によってサービスの範囲、例えばＳＯＰ、人的資源、資源の集合とそれらの相互関係を定義できる。従って、サービス提供者によるサービス活動の各サービスの範囲を明確化することができる。しかも、本発明のサービスは、クライアントの活動であるＣＯＰに対応するものであるため、サービス提供者が提供するサービス事業をＣＯＰを単位にしたサービスに分割して評価を得ることができる。「得られるデータに基づいて」とは、得られるデータのみの場合と他のデータも参照する場合とを含む。評価指標には、人的コスト、作業コスト、サービスリードタイム、例外発生の際のやり直し作業量等がある。これら評価指標は従来のプロジェクトデザインツールにおけるシミュレーションにおいても得られるが、当該ツールは工期でパフォーマンスを評価する。しかし、プロセス型ビジネスにおいては、例えば、処理待ち時間などの影響により、同じサービスによって処理される要求であっても、その処理に要する期間は異なるため、工期によってそのパフォーマンスを評価することは難しい。しかし、本発明によれば、工期ではなくサービス単位で評価指標を集計することができる。

前記評価処理手段は、前記要求を単位にした評価指標からその統計をして求めてもよい。本発明においては、クライアントからの要求に応じてサービスが提供されるため、シミュレーション中に複数の要求が発生した場合は、各要求に対してサービスが提供される。従って、要求を単位にデータを管理することにより、要求毎にパフォーマンスを評価することができる。各要求の評価指標を求めて分散値や標準偏差等の統計を得ることができる。クライアントの活動に基づいて要求が発生するので、その要求の処理に関わる待ち時間、サービスリードタイム、コストなどに、ある分散を持った統計が得られる。この分散は、従来技術のように処理速度あるいは処理時間に適当なばらつきを与えるものとは異なり、外部環境という根拠に基づいた意味あるばらつきであり、結果的に外部環境に対する感応度及びリスクを正確に評価することができる。

前記サービス定義部は、前記各サービス提供者を構成する複数のグループに関して定義するグループ定義手段と、前記各グループを、いずれかの前記ＳＯＰにそのＳＯＰを処理するグループとして対応付けるグループ配置手段と、を有し、前記サービス提供手段は、前記所定の順序に従って処理すべき前記ＳＯＰを特定する処理ＳＯＰ特定手段と、前記特定されたＳＯＰを、そのＳＯＰに対応付けられたグループの待ち行列に登録する行列登録手段と、前記待ち行列に登録された処理のうち、前記対応付けられたグループが実行すべき処理を決定し、前記対応付けられたグループによって前記実行すべき処理を実行させる処理実行手段と、を有していてもよい。

これにより、グループ定義手段により、サービスを提供するためにサービスに関する処理を実際に行う主体として複数のグループを設定でき、グループ配置手段によって各グループに処理するＳＯＰを対応付けることができる。そして、処理実行手段により、待ち行列に登録された処理から実行すべき処理が決定され、当該処理が対応付けられたグループによって実行されるシミュレーションが行われる。従って、誰がどの処理を実行するのかを明確に定義できる。また、複数の要求が連続的に発生した場合は、同時に複数のサービスを提供するための処理が実行され、サービスを提供するための処理全体としては、先行後続関係にある処理が同時に実行されることもあれば、同じ処理が繰り返し行われることもある。また、ある要求において先行する全てのＳＯＰが完了したとしても、後続するＳＯＰに処理待ちの先の要求がある場合、処理待ちの時間が発生する。各グループに待ち行列を設けることにより、複数の要求が連続して発生した場合に発生するこのような状態もシミュレーションすることができる。ＳＯＰに配置される要員は、たとえ処理する要求がなくても（処理する仕事がなくても）次の要求に備えて常時雇用されているので、時間に比例してコストが発生する。なお、待ち行列から実行すべき処理を決定する方法は、例えば、先入先出法（ＦＩＦＯ法）、後入先出法（ＬＩＦＯ法）、優先順位等の従来既知の方法でよい。

前記処理実行手段は、前記実行すべき処理が他のグループにも処理させる場合に、前記他の要員の待ち行列に前記実行すべき処理を登録し、前記対応付けられたグループの待ち行列に登録された処理から次に実行すべき処理を決定し、前記対応付けられたグループに前記次に実行すべき処理を実行させてもよい。サービスの処理中に例えば、上司の指示を得る場合や他の部署の者から情報を得る場合等、他のグループにも処理させる場合が発生すると、実行すべき処理は他のグループが処理し、対応付けられたグループは他のグループの処理待ち状態になる。しかし、本発明の処理実行手段によれば、待ち行列に次の処理が登録されている場合は、当該処理を実行すべき処理として決定し、対応付けられたグループに実行させることができる。

前記サービス定義部は、前記サービス提供者に含まれる複数のメンバーを定義するメンバー定義手段と、前記各ＳＯＰに対して、前記ＳＯＰを処理するグループを対応付けるグループ配置手段と、前記複数のメンバーのうち少なくとも１人を、前記複数のグループのうち少なくとも１つのグループに対応付けるメンバー配置手段と、を有し、前記メンバー配置手段は、前記各メンバーに関して、対応付けられた前記少なくとも１つのグループに前記メンバーが提供する労働力を設定する労働力設定手段と、前記メンバーが対応付けられた前記少なくとも１つのグループに対して、前記メンバーが提供する前記労働力の合計が、所定の上限を超えないように前記労働力設定手段を制御する労働力制御手段とを有し、前記サービス提供手段は、前記設定された労働力の総和を前記グループの労働力として前記グループによって処理される前記ＳＯＰの処理速度に影響させてもよい。

グループは、例えばＳＯＰを処理する主体を示す概念であり、例えば係、チーム、役職等が対応し、メンバーは具体的な個人に対応する概念である。これにより、ＳＯＰを処理する主体である各グループに、サービス提供者に含まれる具体的な複数のメンバーを割り当てることができる。従って、メンバーが複数のＳＯＰの処理を行う場合であっても、メンバーとグループとの対応付けを修正するだけで、メンバーの変化に対応することができる。各メンバーについて、対応付けられた各ＳＯＰに提供する労働力の総和が上限を超えないように各労働力が設定されるため、限られた労働力を備えた一人のメンバーを複数のＳＯＰに割り当てる状態を提供することができる。労働力を処理速度に影響させる態様には、例えば、労働力そのものが処理速度として利用される場合と、労働力が処理速度に影響する係数として利用される場合とがある。

前記サービス定義部は、前記各サービス提供者が利用可能な複数の道具を定義する道具定義手段と、前記各ＳＯＰに対して、前記ＳＯＰを処理するために利用される道具グループを対応付ける道具グループ配置手段と、前記複数の道具のうち少なくとも１つの道具を、前記複数の道具グループのうち少なくとも１つの道具グループに対応付ける道具配置手段と、を有し、前記道具配置手段は、前記各道具に関して、対応付けられた前記少なくとも１つの道具グループに前記道具が提供する処理能力を設定する処理能力設定手段と、前記道具が対応付けられた前記少なくとも１つの道具グループに対して、前記道具が提供する前記処理能力の合計が、所定の上限を超えないように前記処理能力設定手段を制御する処理能力制御手段とを有し、前記サービス提供手段は、前記設定された処理能力の総和を前記道具グループの処理能力として前記グループによって処理される前記ＳＯＰの処理速度に影響させてもよい。

「道具グループ」は、例えばプリンター、ファックス、パーソナルコンピュータ等の道具の種類を示す概念であり、「道具」はサービス提供者が実際に利用できる機械や備品等に対応する概念である。これにより、ＳＯＰの処理に利用される各道具グループに、サービス提供者が利用できる具体的な道具を割り当てることができる。各道具について、対応付けられた各ＳＯＰに提供する処理能力の総和が上限を超えないように各処理能力が設定されるため、限られた処理能力を備えた一つの道具を複数のＳＯＰに割り当てる状態を提供することができる。処理能力を処理速度に影響させる態様には、例えば、処理能力そのものが処理速度として利用される場合と、処理能力が処理速度に影響する係数として利用される場合とがある。

本発明のシミュレーション方法は、少なくとも１つのクライアントへサービス提供者がサービスを提供するためのビジネスプロセスをシミュレートすることにより、前記ビジネスプロセスを評価するプロセスマネジメント支援におけるシミュレーション方法であって、前記各クライアントの活動内容を定義するクライアント定義段階と、前記サービス提供者が提供するサービスに関して定義するサービス定義段階と、所定期間において、前記各クライアントの活動によってサービスの要求が発生し、前記サービス提供者による前記サービスが提供される工程をシミュレートするシミュレーション段階とを有し、前記クライアント定義段階は、前記各クライアントが行う複数の活動を複数のクライアントオペレーション（ＣＯＰ）のそれぞれに対応させ、前記クライアント毎に前記シミュレート時における前記複数のＣＯＰの進行態様を定義するＣＯＰ定義段階と、前記複数のＣＯＰのそれぞれと、前記各ＣＯＰに対して前記サービス提供者によって提供されるサービスとを対応付けるＣＯＰ対応付け段階と、前記各ＣＯＰからサービスの要求を発生させるための条件を定義する発生条件定義段階とを有し、前記サービス定義段階は、前記サービス提供者が前記ＣＯＰに対応付けられたサービスを提供するための手順を、前記サービス提供者の人的資源又は物的資源を対応付ける処理単位である複数のサービスオペレーション（ＳＯＰ）のそれぞれが処理される順序によって定義するＳＯＰ定義段階を有し、前記シミュレーション段階は、前記各クライアントについて、前記進行態様に基づいて実行すべきＣＯＰを特定するクライアント処理進行段階と、前記クライアント処理進行手段によって特定されたＣＯＰに対応付けられたサービスの要求を、前記条件に基づいて発生させる要求発生段階と、前記要求が発生する毎に、前記特定されたＣＯＰに対応付けられたサービスに関して前記ＳＯＰ定義手段にて定義された手順として、前記各ＳＯＰの処理を、対応付けられた前記人的資源又は前記物的資源を使用して、前記定義された順序にて処理することにより、前記サービスを提供するための処理を行うサービス提供段階とを有することにより、上記の課題を解決する。本発明のシミュレーション方法は、本発明のプロセスマネジメントシステムのシミュレーション方法として実現される。

また、前記ＣＯＰ対応付け段階において、前記各ＣＯＰから発生する各要求についてその要求の属性を定義してもよい。

上述したように、本発明によれば、クライアント定義部によって、クライアント１０３の活動を複数のＣＯＰの進行態様が定義され、各ＣＯＰとサービス提供者１０１のサービス１０４とが対応付けられ、シミュレーション部において、定義したＣＯＰの進行態様に基づいて実行すべきＣＯＰが特定され、特定されたＣＯＰからサービス１０４の要求（ＳＲＩ）を所定の条件に基づいて発生させ、ＳＲＩが発生する毎に、特定されたＣＯＰに対応付けられたサービス１０４を、ＳＲＩを発生させたクライアント１０３に提供させるようにビジネスプロセスのシミュレーションが行えるように構成したことにより、以上のように、外部環境の変化に対して適応したビジネスプロセスを継続的に探索することを支援するプロセスマネジメント支援システム等を提供することができる。

本発明のシステムにおいて定義されたＳＢＰＭを示す図。 クライアントのＣＯＰとサービスとの関係を示す図。 本発明のシミュレーションにおけるＣＯＰの動作を示す図。 複数のＣＯＰの実行順序の一態様を示す図。 複数のＣＯＰの実行順序の一態様を示す図。 複数のＣＯＰの実行順序の一態様を示す図。 サービスがモデル化された例を示す図。 シミュレーション結果として収益率を示すグラフ。 シミュレーション結果として作業効率を示すグラフ。 ＳＲＩを単位とするサービスリードタイムを示すグラフ。 ＳＲＩを単位とするサービス品質を示すグラフ。 サービスに関する仕掛量をＳＲＩを単位に示すグラフ。 ＳＯＰに関する仕掛量をＳＲＩを単位に示すグラフ。 ２つのＳＯＰについての作業内訳を示す表。 ケースを単位に比較されている作業内訳を示すグラフ。 サービス全体についてのコミュニケーション品質を示すグラフ。 ポジションについてのコミュニケーション品質を示すグラフ。 サービス全体についての管理品質を示すグラフ。 ポジションについての管理品質を示すグラフ。 本発明のエンタープライズ及びクライアントの一形態を示す図。 モデルエディタにてクライアントとサービスとが対応付けられたようすを示す図。 モデルエディタにて各ＣＯＰと各サービスとが対応付けられたようすを示す図。 図１５に示す１つのＣＯＰについてのプロセスが、モデルエディタ上でモデル化されたようすを示す図。 クライアントベースデシジョンに対応付けられるべき情報の一例を示す図。 確率ベースデシジョンに対応付けられるべき情報の一例を示す図。 予定作業量の一例を示す図。 ケース２としてのプロセスが定義されたようすを示す図。 ポジションがＳＯＰの実行に要求されるスキルを有する場合の、ポジションのスキルレベルとＳＯＰの複雑性とを処理速度に影響させる影響係数のテーブル。 ポジションがＳＯＰの実行に要求される以外のスキルを有する場合の、ポジションのスキルレベルとＳＯＰの複雑性とを処理速度に影響させる影響係数のテーブル。 リソースの効果を処理速度に影響させる係数のテーブル。 ポジションがＳＯＰの実行に要求されるスキルを有する場合の、ポジションのスキルレベルとＳＯＰの複雑性とを例外の発生率に影響させる影響係数のテーブル。 ポジションがＳＯＰの実行に要求される以外のスキルを有する場合の、ポジションのスキルレベルとＳＯＰの複雑性をと例外の発生率に影響させる影響係数のテーブル。 ケース１及びケース２のそれぞれについての作業効率を示すグラフ。 ケース１について、ＳＲＩを単位にしてサービスリードタイムを示すグラフ。 ケース２について、ＳＲＩを単位にしてサービスリードタイムを示すグラフ。 ケース１における各ＳＯＰの作業効率をクライアント別に示すグラフ。 ケース２における各ＳＯＰの作業効率をクライアント別に示すグラフ。 プロセスマネジメント支援システムのハードウェア構成を示す図。 プロセスマネジメント支援システムを実行するための全体の流れを示すフローチャート。 クライアント定義処理における処理の手順を示すフローチャート。 サービス定義処理における処理の手順を示すフローチャート。 クライアント処理における処理の手順を示すフローチャート。 サービス提供進行処理における処理の手順を示すフローチャート。 スタッフ及びマネージャーのそれぞれにおいてＳＲＩが処理されるようすを示す図。 複数のＳＲＩが処理のそれぞれに関して、スタッフ及びマネージャーのそれぞれにおいて行われる処理の時間的関係を示すシーケンス図。 スタッフ処理における処理の手順を示すフローチャート。 例外発生処理における処理の手順を示すフローチャート。 上司処理における処理の手順を示すフローチャート。 情報交換処理における処理の手順を示すフローチャート。 評価処理における処理の手順を示すフローチャート。 メンバーリスト作成画面を示す図。 本発明におけるサービスのプロセスの一例を示す図。 メンバー配置処理における処理の手順を示すフローチャート。 メンバー配置画面の一例を示す図。

１．本発明のモデル構造
（１）ＳＢＰＭ
本発明のプロセスマネジメント支援ツールにおいては、プロセス型のビジネスを継続的に発生するサービスの要求及び提供として捉え、当該ビジネスの基本モデルを、図１に示すＳＢＰＭ（Ｓｅｒｖｉｓ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｍｏｄｅｌ）として、明確に定義した。このＳＢＰＭに従って個々のビジネスプロセスをモデルすることにより、ビジネスプロセスに含まれる情報を失うことなくこれを可視化し、理解可能で且つ共有可能な情報とすることができる。ＳＢＰＭでは、ビジネスプロセスの主要な要素及びそれらの関係を明確に定義し、それら要素を全てのビジネスプロセスに共通な部品として提供している。これら共通な部品の属性や組合せを変更することで、様々なビジネスプロセスケースを自由に設計することができる。

また、ＳＢＰＭでは、ビジネスプロセスをモデルする際に、複数のサービスに対する要員の配置割合、ツール使用による処理速度への効果、スキルレベルの効果、及び条件分岐など、これまで曖昧にされていた部分についても数値によって明確に定義される。この結果、従来は経験と勘による曖昧な判断に頼っていた部分が、数値に裏打ちされた合理的な判断によって行うことが可能となる。以下、ＳＢＰＭを構成する各オブジェクトについて説明する。

ＳＢＰＭでは、概観から詳細へ向けてビジネスプロセスが階層的に構成されている。これにより、複雑なプロセス型ビジネスのビジネスプロセスの構造を直感的に理解可能なモデルとして表現することを可能としている。ビジネスプロセスの主体である企業１０１（以下「エンタープライズ１０１」という。）の概観は、カスタマーリンク１０２によって対応付けられた１つ以上のクライアント１０３及びサービス１０４で表現される。カスタマーリンク１０２は、提供されるサービス１０４とこれを要求するクライアント１０３との需給関係を定義する。エンタープライズ１０１に対応付けられるべき属性には、例外発生確率、権利集中性、公式性、経験等がある。

クライアント１０３は、後続リンク１０５（以下「サクセサーリンク１０５」という。）によってその実行順序を定義されたＣＯＰ（Ｃｌｉｅｎｔ Ｏｐｅｒａｔｉｏｎ）によって構成される。ＣＯＰは、クライアント１０３自身の活動（オペレーション）であり、これらオペレーションにとって必要なサービス１０４の提供をエンタープライズ１０１に対して「要求」する。ＣＯＰとＣＯＰが提供を受けるサービス１０４との関係は、リクエストリンク１０７によって定義される。

サービス１０４の構成について説明する。サービス１０４は、クライアント１０３からの要求を処理するための方法であるプロセス１０８に対して、企業組織１０９（以下「オーガニゼーション１０９」という。）の要員１１０（以下「ポジション１１０」という。）及び資源１１１（以下「リソース１１１」という。）がどのように対応付けられるかを定義することで記述される。当該対応付けの定義は、アロケーションリンク１１２によって記述される。

プロセス１０８は、サービス１０４を提供するために必要なオペレーションであるＳＯＰ（Ｓｅｒｖｉｃｅ Ｏｐｅｒａｔｉｏｎ）によって構成される。複数のＳＯＰはサクセサーリンク１１８によって手順が定義され、かつコミュニケーションリンク１１９によって情報依存性が定義される。情報依存性とは、ＳＯＰに対応付けられたポジション１１０が他のポジション１１０から情報を得る必要性である。

オーガニゼーション１０９は、複数のポジション１１０で構成される。各ポジション１１０を結ぶレポートライン１２０によって、報告・指示系統が定義される。ポジション１１０は、サービスを提供する主体として機能するチーム、係、役職等の所定のグループに対応する概念であり、例えば、部下であるスタッフと上司であるマネージャーとがある。リソース１１１は、ＳＯＰが実行される際に利用される道具１２１（以下「ツール１２１」という。）などの集合である。

サービス１０４にて行われる処理を総称して仕事といい、プロセス１０８、オーガニゼーション１０９、及びリソース１１１によって行われる。本発明では、仕事の作業内容を３つの作業アイテム（Ｗｏｒｋ Ｉｔｅｍ、以下「ＷＩ」という。）で区別する。本形態のＷＩには、クライアント１０３からの要求に対応する仕事であるＳＲＩ（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ Ｉｔｅｍ）、ＳＲＩの処理過程で発生した例外に対応する仕事であるＥＩ（Ｅｘｃｅｐｔｉｏｎ Ｉｔｅｍ）、及び他のポジション１１０とのミーティング、会議等、情報交換に対応する仕事であるＣＩ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｉｔｅｍ）がある。

ＷＩは、クライアント１０３やサービス１０４、ポジション１１０、ＳＯＰなど、シミュレーション期間中存在し続けるオブジェクトと異なり、所定の条件に基づいて発生し、シミュレーション期間中に次々に発生及び消滅するイベントオブジェクトである。ＷＩの各アイテムの詳細については後述する。

（２）クライアント
クライアント１０３は１つ以上のＣＯＰの集合である。上述したように、ＣＯＰはクライアント自身の活動であり、ＣＯＰの実行順序はサクセサーリンク１０５によって定義される。例えば、図２に示すクライアント１０３は、自己の活動として４種のＣＯＰ１〜ＣＯＰ４を有し、サクセサーリンク１０５によってＣＯＰ１、ＣＯＰ２、及びＣＯＰ３は順に実行されるように定義され、ＣＯＰ４は独立して実行されるように定義されている。各ＣＯＰ１〜ＣＯＰ４は、リクエストリンク１０７によってサービス１〜サービス４に対応付けられている。クライアント１０３は、自身のＣＯＰ１〜ＣＯＰ４の実行に必要なサービスの提供要求としてＳＲＩを、リクエストリンク１０７によって対応付けられたサービス１〜サービス４に対して発生させる。

（３）ＣＯＰ
図２に示すＣＯＰ１〜ＣＯＰ３の動作について図３を用いて説明する。ＣＯＰは、活動が行われている「活動中」、又は活動が行われていない「待機中」の２つの状態を持つ。例えば、ＣＯＰ１〜ＣＯＰ３の場合、「待機中」のＣＯＰ２は、先行するＣＯＰ１の活動の終了によって「活動中」となり、この活動に必要なサービスの提供要求をＳＲＩとして発生する。ＳＲＩは、企業の過去の需給状況などを参考にして、所定の分散を持った確率によって発生する。そして、ＣＯＰ２の活動時間として予め設定された時間が経過すると、ＣＯＰ２はその活動を終了して「待機中」に戻り、後続のＣＯＰ３が「活動中」となる。

ＣＯＰには、その属性として、ＣＯＰの状態、ＳＲＩ発生条件としてのＳＲＩ発生分布、ＣＯＰの活動時間等の情報が対応付けられている。更に、活動の開始時刻及び終了時刻が設定されていてもよい。本形態におけるＳＲＩ発生分布は、ＣＯＰのサービス要求に関する確率の分散特性を示すものである。ＳＲＩには、その属性として、要求するサービスを実行するのに必要な技術の分野（以下、「スキル分野」という。）、優先度、コスト、提供されるサービスの対価、発生日時、実作業量、完了期限等の情報が対応付けられる。コストには時間当たりのコストの場合とＳＲＩ当たりのコストの場合がある。実作業量はシミュレーションにおいて実際に投入された作業量である。以下「実」と付く時は「シミュレーション結果としての」という意味である。

複数のＣＯＰの実行順序の態様の例を図４Ａ〜図４Ｃに示す。図４ＡはＣＯＰが直列状態に実行される場合を示し、図４ＢはＣＯＰが巡回するように実行される場合を示す。また、ＣＯＰが並列状態にかつ、一部のＣＯＰが繰り返し実行されてもよい。図４Ｃの例では、ＣＯＰ１、ＣＯＰ２、及びＣＯＰ３は１２０日周期で繰り返され、当該繰り返しに並行して、ＣＯＰ１の終了後にＣＯＰＡ及びＣＯＰＢが１４日周期でＮ回繰り返される。

（４）サービス
サービス１０４は、ＣＯＰから発生したＳＲＩを、プロセス１０８に通して、対応付けられたポジション１１０及びリソース１１１によって処理する仕組みである。サービス１０４が定義された例を図５に示す。図５の例では、オーガニゼーション１０９はポジション１１０ａ〜ポジション１１０ｄで構成され、ポジション１１０ａはマネージャー、ポジション１１０ｂ〜１１０ｄはマネージャーの部下であるスタッフである。また、リソース１１１はツール１２１ａ及びツール１２１ｂで構成されている。

プロセス１０８には、ＳＲＩによって要求されたサービスを提供するため処理であるオペレーション１３０ａ…１３０ｃの手順が記述されている。オペレーション１３０ａ…１３０ｃは、後述するようにＳＯＰの一種である。以下、オペレーション１３０ａ…１３０ｃを区別する必要のない時はオペレーション１３０、又はＳＯＰ１３０という時がある。各オペレーション１３０は、対応付けられたツール１２１を利用して対応付けられたポジション１１０によって実行される。図５に示すプロセス１０８においては、オペレーション１３０ａにポジション１１０ｂ及びツール１２１ａが対応付けられ、オペレーション１３０ｂにポジション１１０ｃ及びツール１２１ｂが対応付けられ、オペレーション１３０ｃにポジション１１０ｄ及びツール１２１ｂが対応付けられている。以下、ツール１２１又はポジション１１０がオペレーション１３０に「対応付けられた」ことを「配置された」という場合がある。クライアント１０３にて発生したＳＲＩがサービス１０４に受け付けられると、各オペレーション１３０ａ…１３０ｃが対応付けられたポジション１１０によって処理される。サービス１０４におけるＳＲＩに対応する処理は、プロセス１０８の最後のオペレーション１３０による処理を完了した時に終了し、クライアント１０３の要求に対してサービスが提供されたことになる。

（５）ＳＯＰ
ＳＯＰはＳＲＩを処理するための最小単位であり、サービスの入口１３１（以下「エントリー１３１」という。）、エグジット１３２（以下「エグジット１３２」という。）、分岐１３３（以下「デシジョン１３３」という。）、及びオペレーション１３０の４つに分類される。

エグジット１３２及びエントリー１３１は、それぞれＳＲＩに対応するプロセス１０８の出入り口である。エントリー１３１は、ＣＯＰにて発生したＳＲＩを受け取り、エグジット１３２は処理が完了したＳＲＩを、当該ＳＲＩを発生したＣＯＰへ提供する。デシジョン１３３は、クライアント１０３によって異なる注文、チェックなどによる合否判断、又は処理における状況などにより、同一サービス内で異なるＳＯＰ及び手順によってＳＲＩが処理される場合、その分岐の条件を定義する。デシジョン１３３には、例えば、クライアントの種類を条件に分岐するクライアントベース分岐、確率に応じて分岐する確率ベース分岐がある。いずれの種類のデシジョン１３３にも、その属性として分岐条件と分岐先ＳＯＰとが定義される。

オペレーション１３０は、クライアント１０３にて発生したＳＲＩに対応するための処理である。ＳＲＩはオペレーション１３０の処理の進行に従って、後続するオペレーション１３０へ移動する。各オペレーション１３０には、その属性として、要求されるスキルレベル（以下、「要求スキルレベル」という。）、不確定性、複雑性、予定作業量、例外発生率、情報交換頻度等の情報が対応付けられる。各オペレーション１３０には、そのオペレーション１３０を実行するポジション１１０と利用されるリソース１１１が対応付けられる。

（６）ワークアイテム
エンタープライズ１０１のサービス１０４では、クライアント１０３によって発生するＳＲＩを処理する際には、上述したように、その処理の過程で派生的に発生する例外及びコミュニケーションも処理される。発生したＷＩは、その処理を完了するか若しくは完了予定時間を経過するまで存在する。例えば、コミュニケーション及び例外に対する対処の指示に関する要請などは、あまりにもその返答に時間がかかった場合、要請側はそれらを待たずに自分の判断で仕事を先に進めてしまう場合もある。ＷＩが処理される場合、そのＷＩの作業量に応じた時間が消費される。

（ｉ）ＳＲＩ
ＳＲＩは、クライアントの活動であるＣＯＰの実行に必要なサービスの要求としてＣＯＰにて発生するＷＩである。本形態のＳＲＩの発生は、所定の分散を持った確率に基づいて決定される。属性項目は上述した通りである。
（ｉｉ）ＥＩ
ＥＩは、ＳＲＩが処理される際に発生する失敗又は予期しない事態（以下、総称して「例外」とう。）に対応するために発生するＷＩである。ＥＩの発生は、エンタープライズ１０１の例外発生率、処理対象のオペレーション１３０の難易度、ポジション１１０のスキルレベル等に基づいて決定される。属性項目として、作業量、優先度、ＥＩ発生日時、処理完了日時等が対応付けられる。
（ｉｉｉ）ＣＩ
ＣＩは、ＳＲＩが処理される際に発生する他のポジションとの情報交換に対応するために発生するＷＩである。ＣＩの発生は、エンタープライズ１０１の公式性、経験値、処理対象のオペレーション１３０の特徴（不確定性など）等に基づいて決定される。属性項目として、作業量、優先度、ＣＩ発生日時、処理完了日時等が対応付けられる。

（７）ポジション
ポジション１１０は、他のポジション１１０との報告・指示の関係を定義するレポートライン１２０と共にオーガニゼーション１０９を構成する。例えば、オペレーション１３０の処理において例外が発生した場合に、処理を担当するポジション１１０は、レポートライン１２０で対応付けられた上司としてのポジション１１０に指示を要求する場合がある。ポジション１１０には、その属性として、役割、スキル分野、スキルレベル（以下、スキル分野及びスキルレベルを総称して「スキル」という。）、経験レベル、人数、労働力、時間当たりコスト、サラリー等の情報が対応付けられる。労働力とは、オペレーション１３０を処理するためにポジション１１０が提供する単位時間当たりの人的量（人数）である。ポジション１１０は、対応付けられた各オペレーション１３０に関係するＳＲＩ、ＥＩ及びＣＩなどのＷＩを処理する。ポジション１１０は、ＷＩの処理を通じて次の５種類の状態となる。

（ｉ）ダイレクトワーク（Ｄｉｒｅｃｔ Ｗｏｒｋ）
ダイレクトワークは、プロセス１０８が受け付けたＳＲＩに対応している状態である。
（ｉｉ）リワーク（Ｒｅｗｏｒｋ）
処理したオペレーション１３０に対して発生した例外に関する仕事（ＥＩ）に対応している状態である。本発明では、例外の対応措置として、例外が発生したオペレーションを再度やり直す場合がある。当該場合において、オペレーション１３０をやり直している状態である。
（ｉｉｉ）コミュニケーション（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）
オペレーション１３０が実行された場合、派生的にある確率で発生する他のポジション１１０との情報交換の必要性が発生する。コミュニケーションは情報交換に関する仕事（ＣＩ）に対応している状態である。
（ｉｖ）デシジョンウェイト（Ｄｅｃｉｓｉｏｎ Ｗａｉｔ）
ポジション１１０は、ＳＲＩを処理する際に発生した例外について、上司に報告し、その指示を要求する場合がある。この時、ポジション１１０は上司の指示を受け取るまでの間、そのＳＲＩの処理を中断し、かつ次に実行すべきＳＲＩが無い場合、指示待ち状態（デシジョンウェイト）となり、指示待ちのために労働力を消費する。
（ｖ）アイドル（Ｉｄｌｅ）
ポジション１１０が対応付けられた全てのオペレーション１３０で処理すべきＳＲＩ、ＣＩ、及びＥＩが存在しないなど、ポジション１１０が処理すべきＷＩが全くない場合、ポジション１１０は待機状態（アイドル）となり、待機のために労働力を消費する。

（８）リソース
リソース１１１には、オペレーション１３０を実行するために利用される計算機、ソフトウェア、システム、機械、作業標準などの道具であるツール１２１が含まれる。ツール１２１は、使用されるオペレーション１３０に対応付けられ、オペレーション１３０で処理されるＳＲＩの処理速度に対して影響を与える。各ツール１２１には、その属性として利用容易性、処理能力、操作の要求スキル等の情報が定義されている。

上記のようにＳＢＰＭの各オブジェクトが定義された１つのビジネスプロセスを本発明における「ケース」という。ＳＢＰＭにおけるいずれかの定義を変えることにより、複数のケースを作成することができる。例えば、プロセス１０８の定義内容が異なる複数のケースを定義すれば、複数のビジネスプロセスについてシミュレーション結果を比較検討することができる。また、クライアント１０３に関する定義を変更すれば、異なるクライアントに関するケースを作成することができる。

２．企業パフォーマンスの計量化
シミュレーションする期間及びシミュレーション実施回数などを設定することにより、上記のようにＳＢＰＭとして定義されたビジネスプロセスのシミュレーションが実行される。全てのシミュレーション期間を通して、企業活動のパフォーマンス（以下「企業パフォーマンス」という。）に係るデータが記録される。これら記録されたデータは、全てのシミュレーションが終了した後に、企業パフォーマンスを計量するのに利用される。

企業パフォーマンスを計量化するために使用されるパラメータの１つである本形態の処理時間について説明する。本形態では、労働力×処理時間＝作業量（人時間）と定義する。従って、処理時間は作業量÷労働力によって求められる。例えば、予定作業量がオペレーション１３０に設定されている場合、対応付けられているポジション１１０の労働力から、予定処理時間を算出できる。労働力は、上述したように単位時間当りの人数で示され、本形態における予定処理速度として機能する。従って、労働力を予定処理速度というときがある。予定処理速度に仕事のスキル分野、ポジション１１０のスキルレベル等が影響して実際の処理速度が求められる。当該影響については後述する。

以下、シミュレーションによって得られるデータに基づいて得られる評価指標について説明する。本発明の評価指標によって、企業パフォーマンスを計量化された状態で評価することができる。シミュレーション期間中に発生した全てのＳＲＩ、ＥＩ、及びＣＩに対応する処理にて発生した各種データは、ＣＯＰ即ちサービス毎に管理され、ＳＯＰ、ポジション、ＳＲＩ又はサービスといった所定の単位毎に求められる。複数のケースが存在する場合の評価指標はケース毎に求められる。

（１)収益性
収益性は、エンタープライズ１０１がサービスの対価として受け取った収入と、そのサービスを実行するために実際に投入したコストとの関係によって求められる。シミュレーションにおいて、ＳＲＩはＣＯＰから発生し、そのＳＲＩを処理することがサービスを提供することであるので、サービスのコストは、ＳＲＩを処理するシステムであるサービスに対するコストである。従って、サービスのコストはＳＲＩとＣＯＰとの関係ごとに定義され、所定期間中にサービスを実行する際に発生するオペレーション１３０に関わるコストと、ポジション１１０を配置することで発生する人件費に関わるコストとの総和である。

各コストはＳＲＩを単位にして次のように求められる。オペレーション１３０に関わるコストは、時間当り又はＳＲＩ当りのコストと処理時間又は処理件数の積により求められる。ポジション１１０のコストは、時間当りコスト、オペレーション１３０に配置された期間、及び労働力の積で求められる。シミュレーション期間中に複数の同じＣＯＰ１が実行され複数の同じＳＲＩが発生した場合は、各ＳＲＩについての収入及びコストを算出して集計する。なお、複数のＳＲＩが発生した場合の対価は、対価×処理件数によって求める。実際に投入したコストの収入に対する比が収益率である。収益率を示すグラフの例を図６Ａに示す。

また、本発明では、予定作業量と実作業量の関係によって各ＳＲＩについての作業効率を計量することもできる。まず、発生した各ＳＲＩに対応するプロセス１０８に含まれるＳＯＰ１３０の予定作業量の総和により、各ＳＲＩについての予定作業量を見積ることができる。これに対して、実作業量は、シミュレーション期間において各ＳＯＰ１３０に対して投入された実際の作業量の総和である。作業効率は、式１に示すように、各ＳＲＩについての予定作業量（ＲＷＶ）と実作業量（ＩＷＶ）との比によって求められる。作業効率を示すグラフの例を図６Ｂに示す。なお、ＳＯＰ１３０の予定作業量とＳＯＰ１３０の実作業量との比を算出することにより、ＳＯＰ１３０についての作業効率を得ることもできる。

作業効率＝ＲＷＶ／ＩＷＶ ・・・・式１

（２）顧客満足度
顧客満足度はサービスのリードタイム（以下「サービスリードタイム」という。）及びサービス品質の２つの評価指標によって評価される。サービスリードタイムは、個々のＳＲＩについて、ＣＯＰにおける発生から対応するサービスに関する処理が完了するまでに要した時間である。本発明では、図７Ａに示すように、シミュレーション期間中に処理された全ＳＲＩのサービスリードタイムとその個数との関係をヒストグラムで表示すると同時に、平均、分散及び標準偏差（σ）等も計算して表示する。これら分散は、サービス品質のばらつきという品質に関するリスクを表す。

サービス品質は、サービスがクライアント１０３の注文であるＳＲＩをどれだけ正確に完了することができたかを示す。サービス品質（ＳＱ）は、式２に示すように、ＳＲＩを完了するために必要な処理において予定される作業量（ＳＯＰの予定作業量）の総和である予定作業量（ＲＷＶ）のうち正確に完了することができた作業量（ＦＲＷＶ）の比で求められる。

サービス品質＝ＦＲＷＶ／ＲＷＶ ・・・・式２

ＦＲＷＶは、プロセス１０８の処理に関して、例外によるやり直しも含め最終的な処理完成度に対応する作業量として算出される。ＳＲＩに対応するプロセス１０８が、ＳＯＰ１、ＳＯＰ２及びＳＯＰ３で構成される場合について説明する。例えば、ＳＯＰ１、ＳＯＰ２及びＳＯＰ３のそれぞれの予定作業量が１人時間、２人時間、３時間であり、ＳＯＰ２とＳＯＰ３に例外が発生し、ＳＯＰ２は半分やり直し（５０％）、ＳＯＰ３は全部やり直し（１００％）となった場合、ＳＯＰ１及びＳＯＰ３の処理完成度は１００％であり、ＳＯＰ２の処理完成度は５０％である。従って、ＦＲＷＶは、１×１００％＋２×５０％＋３×１００％＝５人時間である。ＲＷＶは、１＋２＋３＝６人時間であるから、サービス品質は、５／６＝０．８３３３となる。

例外の発生が増加し、かつこれを無視する回数が増加するほどサービス品質は低下する。本発明では、図７Ｂに示すように、シミュレーション期間中に処理された全ＳＲＩのサービス品質とその個数の関係をヒストグラムで表示すると同時に、平均、分散及び標準偏差（σ）等も計算して表示する。これら分散は、サービス品質のばらつきという品質に関するリスクを表す。

（３）仕掛量
仕掛量は、サービス１０４又はＳＯＰ１３０において処理の完了を待っているＳＲＩの数量である。サービス１０４の仕掛量は、各ＳＯＰ１３０において処理中及び処理待ちにあるＳＲＩの合計であり、ＳＯＰ１３０の仕掛量は、ＳＯＰ１３０において処理待ちにあるＳＲＩの数量である。本発明では、シミュレーション期間中を通して、処理待ちにあるＳＲＩの数量（後述するイントレイに登録されているＳＲＩの数）とその状態の継続時間の合計とをヒストグラムで表示すると同時に、その平均及び分散を計算して表示する。サービス１０４又はＳＯＰ１３０に対するＳＲＩの入力数量がその処理能力より過大であれば、ヒストグラムのピークは右にシフトする。図８Ａはサービス１０４の仕掛量を示すグラフの例であり、図８ＢはＳＯＰ１３０の仕掛量を示すグラフの例である。

（４）作業内訳
作業内訳は、ポジション１１０がシミュレーション期間中に行った各作業の作業量の内訳を、エンタープライズ１０１、サービス１０４、及びＳＯＰ１３０毎に集計したものである。作業の内訳は、上述した５つの作業（ダイレクトワーク、リワーク、コミュニケーション、デシジョンウェイト、アイドル）で示される。この作業内訳を通して、実行された作業の質を分析することが可能となる。

ＳＯＰ１３０ａ及びＳＯＰ１３０ｂのそれぞれについての作業内訳について図９に示す。ＳＯＰ１３０ａに配置されたポジション１１０は１０人で構成され、そのうち労働力は５０％の５人である。ＳＯＰ１３０ｂに配置されたポジション１１０は８人で、そのうち労働力は２５％の２人である。作業内訳表では、各作業にかけられた作業量が全体の作業量に占める割合を示す。これにより、各作業の作業量のバランスを認識することができる。

また、複数のケースについてシミュレーションが行われた場合、ケース毎に各作業の作業量を集計することにより、作業内訳をケース間で比較することもできる。例えば、ケース１とケース２のそれぞれの作業内訳を図１０に示すグラフのように表示することができる。

（５）コミュニケーション品質
更に、コミュニケーションの品質を評価するためのコミュニケーション品質も提供する。コミュニケーション品質は、提供されたサービス又はポジション１１０に対してのＣＩに関する評価指標である。本発明のコミュニケーション品質は、ＣＩが発生してからこの問い合わせに対して応答するポジション１１０がその処理を完了するまでに要した時間（以下「ＣＩ処理時間」という。）とＣＩの個数との対応関係として、図１１Ａ及び図１１Ｂのように示される。各グラフとも、縦軸は発生したＣＩの個数であり、横軸はＣＩ処理時間を示す。図１１Ａはサービス１０４単位で集計された結果を示し、図１１Ｂは、応答するポジション単位で集計された結果を示す。ピークが右にあるほど、必要な情報を得るのに時間がかかることを表し、コミュニケーションの品質が悪くなることを示す。

（６）管理品質
また、例外が発生した場合の例外処理の品質を評価するための管理品質も提供可能である。管理品質は、提供されたサービス又はポジション１１０に対してのＥＩに関する評価指標である。本発明の管理品質は、ＥＩが発生してから、例外について対応措置を決定するポジション１１０がその処理を完了するまでに要した時間（以下「ＥＸ処理時間」という。）とＥＩの個数との対応関係として、図１２Ａ及び図１２Ｂのように示される。各グラフとも、縦軸は発生したＥＩの個数であり、横軸はＥＩ処理時間を示す。図１２Ａはサービス１０４単位で集計された結果を示し、図１２Ｂは、応答するポジション単位で集計された結果を示す。ピークが右にあるほど、例外に対する対応措置の決定に時間がかかることを表し、マネージメントの視点ではサービス管理状態が悪くなることを示す。

３．実施例
（１）ケースの定義
本発明におけるエンタープライズとして、電力会社、銀行、旅行会社、航空会社、空港管理会社等の様々な形態のサービスをクライアントに対して提供する組織が適用可能である。以下、図１３に示すようにエンタープライズ１０１としての船舶管理会社が２つのクライアント１０３ａ、１０３ｂとしての船舶にサービス１０４ａ…１０４ｃを提供するビジネスを、本発明に適用する場合について説明する。２つのクライアントは新造船１０３ａと高船齢船１０３ｂである。船舶管理会社１０１は、クライアント１０３ａ、１０３ｂが日常的に行うオペレーションである出航（Ｄｅｐａｒｔｕｒｅ）、航海（Ｎａｖｉｇａｔｉｏｎ）、及び入港（Ａｒｒｉｖａｌ）のそれぞれに対して、供給物資チェック１０４ａ、安全航行補助１０４ｂ、及び荷降ろしチェック１０４ｃをサービス１０４として提供する。エンタープライズ１０１のポジション１１０は、経験年数が比較的短いジュニアスタッフ、経験年数が比較的長いシニアスタッフ、及びスタッフの上司であるマネージャーで構成される。

まず、ケース１を定義する。ケース１には、ベストプラティクスの探索及びボトルネックの解析のベースとなるベースケースをモデリングすることが好ましい。

まず、ビジネスプロセスの概念において、最も外側の概観である、エンタープライズ１０１の提供するサービス１０４ａ…１０４ｃとそのクライアント１０３ａ、１０３ｂとの関係を定義する。当該定義を設定する手順について図１４を用いて説明する。本形態の場合、クライアント１０３及びサービス１０４は、モデルエディタ３００の右にあるパレット３０１からそれぞれに対応するシェープ３０２、３０３を選択し、これをモデルエディタ３００にマウスクリックによりドロップすることで作成できる。

クライアント１０３とサービス１０４とを結ぶカスタマーリンク１０２は、パレット３０１よりコネクター・シェープ３０４を選択し、関連付けるクライアント１０３及びサービス１０４のシェープをクリックすることにより作成することができる。以上の手順により、クライアント１０３として新造船１０３ａ及び高船齢船１０３ｂ、サービス１０４として供給物資チェック１０４ａ、安全航行補助１０４ｂ、及び荷降ろしチェック１０４ｃが設定され、各クライアント１０３ａ、１０３ｂと各サービス１０４ａ、１０４ｂ、１０４ｃとを対応付けるカスタマーリンク１０２が設定される。サービス１０４にカスタマーリンク１０２によって対応付けられたクライアント１０３は、サービス１０４の提供先のクライアントとしてシステム上定義される。

次に、クライアント１０３をモデル化する方法について図１５を用いて説明する。クライアント１０３は、自身の活動であるＣＯＰを定義することによってモデル化される。例えば、新造船１０３ａをモデル化する場合、まず所定の方法によって新造船１０３ａをモデル化する対象として選択する。これにより、新造船１０３ａに関するモデルエディタ４００が表示される。このモデルエディタ４００上には、選択されたクライアント１０３と対応付けられたサービス１０４ａ…１０４ｃが表示されるので、新造船１０３ａのＣＯＰを作成して、各ＣＯＰとＣＯＰが要求する各サービス１０４ａ…１０４ｃとをリクエストリンク１０７によって対応付ける。

モデルエディタ４００の右側のパレット４０１より、ＣＯＰのシェープ４０２をクリックし、これをモデルエディタ４００上にドロップすることにより、ＣＯＰを設定することができる。リクエストリンク１０７及びＣＯＰの実行順序を設定するサクセサーリンク１０５は、パレット４０１よりコネクター・シェープ４０３を選択し、対応付ける各シェープをモデルエディタ４００上にてクリックすることで設定することができる。上記手順により、本形態では、ＣＯＰとして、出航１０６ａ、航海１０６ｂ、及び入港１０６ｃが設定され、各ＣＯＰはサクセサーリンク１０５によって処理順序が定義され、各ＣＯＰとそのＣＯＰ１０６に必要なサービス１０４とがリクエストリンク１０７によって対応付けられる。サービス１０４に関して設定された全てのデータ及び発生する全てのデータは、サービス１０４に関連付けられる。

更に、各ＣＯＰのシェープをクリックすることにより各ＣＯＰ１０６の属性を設定し、各リクエストリンク１０７をクリックすることにより各ＳＲＩの属性を設定する。ＣＯＰ１０６の属性及びＳＲＩの属性は上述した通りである。他のクライアント１０３ｂのＣＯＰについても同様に定義すればよい。

続いて、サービス１０４をモデル化する手順について図１６を用いて説明する。サービス１０４は、クライアント１０３からの注文であるＳＲＩを処理するために定義されたプロセス１０８に対して、これを実行するためにオーガニゼーション１０９に含まれるポジション１１０を配置することによって定義される。

例えば、サービス１０４として安全航行補助１０４ｂをモデル化する場合について説明する。まず、安全航行補助１０４ｂをモデル化対象のサービスとして所定の方法で選択する。選択されたサービス１０４ｂを定義できるモデルエディタ５００がモニタに表示される。モデルエディタ５００上にて、まず、プロセス１０８を設定する。設定方法は、ＣＯＰの設定方法と同様に、パレットに用意されているＳＯＰ、クライアントベースデシジョン１３３、デシジョン１３３、エグジット１３２、サクセサーリンク１１８等のシェープを使い所望のプロセス１０８をモデルエディタ５００上で形成する。

次に、オーガニゼーション１０９を定義する。パレットに用意されているスタッフ、マネージャー、及びレポートライン１２０等のシェープを使いエンタープライズ１０１のオーガニゼーション１０９の構成をモデルエディタ５００上で形成する。最後に、各ＳＯＰ１３０に対して、モデルエディタ５００上で形成された各ポジション１１０を配置する。パレットに用意されているアロケーションリンク１１２のシェープによって、エディタモニタ５００上でポジション１１０とＳＯＰ１３０とを対応付けることができる。

図１６は、新造船１０３ａと高船齢船１０３ｂのそれぞれについて、定期的に状態の分析処理を行い、異常があれば修理等の対応処理を実行する安全航行補助サービス１０４ｂのプロセス１０８が定義されたようすを示す。言い換えれば、クライアント１０３である船舶１０３ａ、１０３ｂが航海ＣＯＰを実行中に、定期的にエンタープライズ１０１に対して船舶１０３ａ、１０３ｂの状態をチェックすることを要求し、異常が発見された場合は対策が講じられるというプロセス１０８がモデル化されている。なお、ツール１２１の配置も、ＳＯＰ１３０とＳＯＰ１３０の処理に使用されるツール１２１とを、ポジション１１０と同様に、アロケーションリンク１１２のシェープを使って対応付ければよい。

本形態において定義されたプロセス１０８の詳細について説明する。まず、ポジション１１０のうちジュニアスタッフ１１０ｂが新造船１０３ａに関する処理に対応付けられ、シニアスタッフ１１０ｃが高船齢船１０３ｂに関する処理に対応付けられている。高船齢船１０３ｂからの注文の処理は新造船１０３ａに比べて難しく、かつ異常が発生する比率が高いので、２つの異なるプロセスによって処理する。クライアントベース分岐であるデシジョン１３３ａは、クライアント１０３が新造船１０３ａである場合と高船齢船１０３ｂである場合によってその後の処理プロセスを分岐させる。デシジョン１３３ａの定義画面にて、図１７Ａに示すように、各船舶１０３ａ、１０３ｂに対して分岐先であるＳＯＰ１３０との対応付けを定義する。この定義により、新造船１０３ａからのＳＲＩは上に分岐したプロセスで、高船齢船１０３ｂからのＳＲＩは下に分岐したプロセスでそれぞれ処理される。

それぞれのプロセスでは、クライアント１０３が新造船１０３ａの場合は、「分析処理（新）」において船舶の状態を分析し、異常があれば更に「対応処理（新）」が行われ、クライアント１０３が高船齢船１０３ｂの場合は、「分析処理（旧）」において船舶の状態を分析し、異常があれば更に「対応処理（旧）」において対策を講じることを記述している。この時「異常があれば」という確率的な条件は、確率ベース分岐であるデシジョン１３３ｂ、デシジョン１３３ｃにおいて設定される。この確率条件によってＳＲＩがどちらの後続処理へ進むのかが決定される。デシジョン１及びデシジョン２のそれぞれにおける確率が設定されたようすを図１７Ｂに示す。図１７Ｂでは、分析処理（新)及び分析処理（旧）による分析の結果、それぞれ２０％及び４０％の確率で「異常」な状態と判断され、各対応処理へ進むことを示している。言い換えると、新造船１０３ａは分析した結果２０％の確率で修理等対策が必要なのに対して、高船齢船１０３ｂでは４０％であることを示す。

本形態のプロセス１０８には、スキルレベルが高いシニアスタッフ１１０cとスキルレベルが低いジュニアスタッフ１１０ｂという２組のポジション１１０が設定されている。ジュニアスタッフ１１０ｂは難易度の小さい新造船１０３ａに関する処理に、シニアスタッフ１１０ｃは難易度の高い高船齢船１０３ｂに関する処理に対してそれぞれ配置されている。これら、２組のポジション１１０はマネージャー１１０ａによって管理されており、その関係がレポートライン１２０によって関連付けられることでオーガニゼーション１０９を形成する。

各ＳＯＰ１３０、各ポジション１１０の属性は、例えば、モデルエディタ５００の下方に表示されるプロパティウィンドウにおいて設定される。当該設定方法は従来技術に基づいて行えばよい。各オブジェクトの属性は上述した通りである。例えば、各ＳＯＰ１３０の処理に必要な予定作業量は、図１７Ｃに示すように設定される。予定作業量はポジションのスキルレベルに関係なく平均的な作業量である。従って、各ＳＯＰ１３０を処理するポジション１１０を「ケース１」と異なるように定義する後述の「ケース２」においても、各ＳＯＰ１３０の予定作業量は「ケース１」と同じである。

更に、いずれかのＳＯＰ１３０にコミュニケーションリンク１１９を設定する場合は、例えば、パレットからコミュニケーションリンク１１９を示すシェープを選択して、設定するＳＯＰ１３０と他のＳＯＰ１３０とを対応付ければよい。以上の手順により「ケース１」について定義されたことになる。

続いて、他のケースとして「ケース２」についても定義する。本形態のケース２は、図１８に示すように、ポジション１１０の配置の定義のみがケース１と異なる。ケース２では、船の種類に拘わらずジュニアスタッフ１１０ｂが分析処理を行い、シニアスタッフ１１０ｃが対応処理を行うように定義する。ケース２における各定義はケース１と同様の方法によって定義すればよい。

（２）テーブルの設定
本発明では、ＳＲＩの処理を通して、その処理速度、例外の発生、及び情報交換の発生などの処理時間に関わる要素を明確に定義している。そこで、シミュレーションの実行に当っては、処理時間に関わる要素と処理時間の影響との関係を示すに各種テーブルを、事前に設定する。本形態では、ＳＯＰ１３０に予め対応付けられた予定作業量及び労働力から、予定作業量／労働力によって予定される処理時間（以下「予定処理時間」という。）を求めることができる。また、エンタープライズ１０１に対して予め定義された例外発生率を予定例外発生率という。

設定されるべきテーブルの例を図１９Ａ〜図２０Ｂに示す。図１９Ａ及び図１９Ｂは、ポジション１１０のスキルレベルとＳＯＰ１３０の複雑性との関係が予定処理速度に与える影響を示すテーブルである。図１９Ａはポジション１１０のスキル分野とＳＯＰ１３０が求めるスキル分野とが一致する場合であり、図１９Ａは一致しない場合を示す。図１９Ｃは、ツール１２１の処理能力がＳＯＰ１３０の予定処理速度に与える効果を示すテーブルである。図２０Ａ及び図２０Ｂは、ポジション１１０のスキルレベルとＳＯＰ１３０の複雑性との関係が予定例外発生率に与える影響を示すテーブルである。各テーブルの各数値は係数（以下「影響係数」という。）として予定処理速度又は予定発生確率を変化させる。なお、各テーブルの値は予めデフォルト値が設定されていてもよい。

例えば、ジュニアスタッフ１１０ｂのスキルレベルは「低」、シニアスタッフ１１０ｃのスキルレベルは「高」に設定し、新造船１０３ａに関するＳＯＰ１３０の複雑性を「中」、高船齢船１０３ｂに関するＳＯＰ１３０の複雑性を「高」に設定した場合、スキル分野は一致するとすれば、ジュニアスタッフ１１０ｂが新造船１０３ａに関するＳＯＰ１３０を実行する処理速度は予定処理速度の０．９倍であり、例外発生確率は予定例外発生率の１．２倍になる。更に、当該ＳＯＰ１３０に対応付けられているツール１２１の処理能力がＲ２の場合の処理速度は、（予定処理速度×０．９）の１．２倍になる。また、シニアスタッフ１１０ｃが高船齢船に関するＳＯＰ１３０を実行する場合は処理速度及び例外発生確率は予定処理速度及び例外発生確率と同じである。

（３）シミュレーションの実行
シミュレーションを実行する際には、定義したビジネスプロセスを実行させる期間を、シミュレーション期間として設定する。例えば、月別カレンダーがモニタに表示され、シミュレーション開始日と終了日が、カレンダー上の日付をクリックすることにより設定されるように構成することが望ましい。

シミュレーション期間が設定されると、作成した全てのケースについてシミュレーションが実行される。これにより、各ケースのシミュレーション結果が得られるので、各ケースのシミュレーション結果を比較することができる。本形態では、上述した２つのケースについてシミュレーションが実行され、シミュレーション結果を比較することができる。

（４）シミュレーション結果の評価及び分析
シミュレーションが終了すると、シミュレーション中に発生したデータに基づいて、上述したように、収益、コスト、収益率、予定作業量、実作業量、作業効率、及びサービス品質、処理時間等の評価指標が算出される。これら評価指標により、収益性及び顧客満足度などビジネスプロセスのパフォーマンスを計量化し、客観的に評価することができる。例えば、図２１は、ケース１及びケース２について、サービスに関するパフォーマンスを、予定作業量、実作業量及び作業効率によって示したものである。この結果から、ケース１の方がケース２よりも作業効率が良いことが分かる。

図２２Ａ及び図２２Ｂは、顧客満足度に関するパフォーマンスを、ケース１及びケース２のそれぞれについて、サービスリードタイムに関するヒストグラムによって示したものである。横軸はサービスリードタイムを、縦軸は各時間内にサービスの提供を完了することができたＳＲＩの個数を示している。

この結果から、ケース１はケース２に対して、大きな差ではないもののサービスリードタイムが短いことがわかる。この理由としては、上述したようにケース１の方が作業効率が高いことが関係していると考えられる。そこで、より詳細な分析をすることで、プロセス１０８のボトルネックを特定する。

図２３Ａ及び図２３Ｂは、プロセス１０８中の２つのＳＯＰ（分析処理及び対応処理）の作業効率を、ケース１及びケース２についてそれぞれ示したものである。ケース１では、新造船１０３ａに関しては、連続する２つのＳＯＰ、即ち、分析処理（新）及び対応処理（新）の作業効率は同じである。高船齢船１０３ｂに関しても同様である。これに対して、ケース２では、新造船１０３ａと高船齢船１０３ｂとで連続するＳＯＰの作業効率が大きく異なる。これは、先行するＳＯＰ（分析処理）は、スキルレベルの低いジュニアが担当し、後続のＳＯＰ（対応処理）は、スキルレベルの高いシニアが担当することが原因である。結果的に、このポジション配置では、ジュニアが配置されたＳＯＰがボトルネックとなり、サービスリードタイムに影響を及ぼすことが判明する。

本発明のプロセスマネジメント支援ツールのハードウェア構成について説明する。図２４に示すように、本ツール２００はデータの入力を受け付ける入力部２１０と各種データが出力される出力部２２０と本ツールによる各種機能を制御する制御ユニット２３０とを備える。入力部２１０には、例えばユーザの入力を受け付けるキーボードやマウスの他、他システムからのデータを受け付けるインターフェースも含まれる。出力部２２０には、データやメッセージが表示されるモニタの他、他システムへデータを出力するインターフェースも含まれる。制御ユニット２３０は、ＣＰＵとその動作に必要なＲＡＭ、ＲＯＭ等の各種記憶域を備え、コンピュータとして構成される。ＲＯＭには、制御ユニット２３０を機能させるためのプログラムが記憶されている。

プログラムが実行されることによって制御ユニット２３０は、定義部２３１、シミュレーション部２３２及び評価処理部２３３として機能する。定義部２３１はシミュレーションを行うためにＳＢＰＭの各オブジェクトを定義するための定義処理を制御する。定義部２３１は、主に、クライアント１０３に関する定義処理を制御するクライアント定義部２３１ａとサービス１０４に関する定義処理を制御するサービス定義部２３１ｂとで構成される。シミュレーション部２３２は定義が完成されたＳＢＰＭに基づいてシミュレーション処理を制御する。

シミュレーション部２３２は、主に、クライアント１０３の動作をシミュレーションするクライアント処理部２３２ａと、サービス１０４の提供に関する処理の進行を制御するサービス提供進行部２３２ｂと、ポジション１１０によって各ＳＲＩに対応する処理が実行される工程を制御するポジション処理部２３２ｃと、シミュレーション部２３２によって行われるシミュレーションにおける各種処理の処理時間や処理回数を主にオブジェクト毎に記録する処理ログ記録部２３２ｄとで構成される。ポジション処理部２３２ｃにおいては、各ポジション１１０に、処理すべき仕事が追加されるイントレイと処理が完了した仕事が追加されるアウトトレイが対応付けられている。評価処理部２３３は、シミュレーションにより得られたデータに基づいて、企業パフォーマンスを評価するための評価指標を求め、グラフや表等にビジュアル化してモニタに表示する。

本発明のプロセスマネジメント支援システムを実行するための手順の概略を図２５に示す。まず、ＳＢＰＭを構成する各オブジェクトの定義処理を行う。次に、シミュレーション期間を設定し、シミュレーションを実行する。シミュレーションでは、クライアント１０３の活動のシミュレーションであるクライアント活動処理が行われ、活動中のＣＯＰからＳＲＩが発生すると、ＳＲＩに対応するサービス提供処理が行われる。なお、サービス提供処理には後述するサービス提供進行処理とポジション処理とが含まれる。

クライアント１０３が複数の場合は、各クライアントについてクライアント活動処理が行われ、各クライアントの活動からサービスの要求であるＳＲＩが発生する。このように各クライアント１０３の活動を通して、各クライアント１０３の要求に応じたサービスを提供するための処理が発生する。シミュレーション期間が終了すると、シミュレーションの実行は終了し、シミュレーションによって得られたデータに基づいて評価処理が行われる。評価処理では、シミュレーション中に発生した各ＳＲＩに関する各種評価指標が求められ、グラフや表のようにビジュアル化してモニタに表示される。

以下、制御ユニット２３０の各部にて行われる処理について説明する。定義部２３１における定義処理について説明する。ます、クライアント定義部２３１ａによって制御されるクライアント定義処理について、図２６に示すフローチャートに従って説明する。まず、ステップＳ３０１にてクライアント１０３とサービス１０４との対応付けが行われる。次にステップ３０２へ進んで複数のＣＯＰの処理順序が設定され、ステップＳ３０３にて各ＣＯＰとサービスとの対応付けが設定される。最後にステップＳ３０４にて、ＳＲＩ発生条件等のＣＯＰの属性、及び対価や要求スキル分野等のＳＲＩの属性が設定される。具体的な設定方法や設定項目は実施例にて上述した通りである。なお、ＣＯＰに定義されるクライアント１０３の活動はエンタープライズ１０１に要求が必要な活動である。

次に、サービス定義部２３１ｂによって制御されるサービス定義処理について、図２７に示すフローチャートに従って説明する。まず、ステップＳ３１１にてプロセス１０８、オーガニゼーション１０９、ポジション１１０及びリソース１１１の各オブジェクトの定義が行われる。これにより、サービスの範囲が決定される。次に、ステップＳ３１２に進み、プロセス１０８を構成するＳＯＰ１３０、ツール１２１及びポジション１１０との対応付けを設定する。ステップＳ３１３では、ＥＩ及びＣＩに対応付けるべき属性を定義し、ステップＳ３１４ではＥＩ及びＣＩに対する対応及び処理速度等、ポジション１１０の振る舞いに関して影響を与える影響係数等シミュレーションに必要な事項を設定する。具体的な手順や設定項目は実施例にて上述した通りである。

シミュレーション部２３２にて行われるシミュレーションに関する処理について説明する。なお、シミュレーションは、実時間より高速に進行するシミュレーション用の時間に基づいて処理が行われる。従って、シミュレーションにおける時間の計時は、シミュレーション用に設定された時間の計時であり、実時間での処理が必要な場合には、シミュレーション用の時間が実時間に換算されて処理される。

まず、クライアント処理部２３２ａによって制御されるクライアント処理について、図２８に示すフローチャートに従って説明する。クライアント処理は複数のクライアント１０３が存在する時は、各クライアント１０３について実行される。まず、ステップＳ４０１にてシミュレーション期間が設定される。当該設定はユーザによって行われてもよいし、他のシステムの所定のデータに基づいて自動的に設定されてもよい。続いてステップＳ４０２にて当該期間が終了か否かが判断され、終了の場合はクライアント処理を終了する。シミュレーション期間が終了でない場合は、ステップＳ４０３に進んでクライアント活動処理が行われる。クライアント活動処理では、上述したように複数のＣＯＰを所定の順番で活動中の状態にし、活動中のＣＯＰにおいてＳＲＩが発生するタイミングを決定する。活動中のＣＯＰは、サクセサーリンク１０５によって定義された活動順序、及びＣＯＰに定義された活動時間等によって決定される。

ＳＲＩの発生タイミングは、ＳＲＩの属性に基づいて例えば所定の分散を持った確率に基づいて決定する。ステップＳ４０４にて、ＳＲＩが発生するタイミングであると判断された場合、ステップＳ４０５へ進んでＳＲＩが活動中のＣＯＰより発生し、ステップＳ４０２へ戻る。

サービス提供進行部２３２ｂによって制御されるサービス提供進行処理について図２９に示すフローチャートに従って説明する。なお、以下の説明において、複数のＳＲＩのそれぞれを識別する必要がある場合は、各ＳＲＩを「ＳＲＩ−ｎ」のように枝番を付記して示す。サービス提供進行処理はいずれかのＣＯＰにてＳＲＩが発生する毎に行われる。まず、ステップＳ５０１にてＣＯＰにてＳＲＩが発生したか否かを判断し、発生していない場合はサービス提供進行処理を終了する。ＳＲＩが発生した場合はステップＳ５０２へ進み、ＳＲＩが要求するサービスを特定する。本形態ではＣＯＰに対応付けられたリクエストリンク１０７により要求されたサービス１０４を特定する。次に、ステップＳ５０３にて、特定されたサービス１０４のプロセス１０８を構成する最初のＳＯＰを処理対象として特定する。続いてステップＳ５０４にて特定されたＳＯＰがデシジョン１３３か否かを判断し、デシジョン１３３の場合は、ステップＳ５０５へ進んでデシジョン処理が行われる。

ステップＳ５０５のデシジョン処理では、当該デシジョン１３３に対応付けられた分岐条件と分岐先に応じて、分岐先を決定する。分岐先が決定されると、ステップＳ５１１へ進む。ステップＳ５１１では発生したＳＲＩが要求するサービス１０４の提供が完了したか否かが判断される。分岐先がエグジット１３２の場合サービス１０４が完了したと判断され、ステップＳ５１３へ進む。分岐先がＳＯＰの場合サービスが完了ではないと判断され、ステップＳ５０３へ戻り、分岐先のＳＯＰに関する処理を行う。

ステップＳ５０４にて、特定されたＳＯＰがデシジョン１３３ではないと判断された場合、ステップＳ５０６へ進み、特定されたＳＯＰはオペレーション１３０か否かを判断する。オペレーション１３０でない場合は、ステップＳ５１１に進む。ステップＳ５１１では、例えば、特定されたＳＯＰがエグジット１３２の場合、サービスが完了したと判断され、ステップＳ５１３へ進む。サービスが完了ではないと判断された場合は、次のＳＯＰを特定するためにステップＳ５０３へ戻る。

ステップＳ５０６にて、特定されたＳＯＰはオペレーション１３０であると判断された場合は、ステップＳ５０７へ進み、特定されたＳＯＰを実行するポジション１１０(以下「担当スタッフ」という。）を特定する。オペレーション１３０の定義時にオペレーション１３０に対応付けられたポジション１１０を特定すればよい。続いてステップＳ５０８に進み、特定された担当スタッフのイントレイに特定されたＳＯＰ１３０のＳＲＩ（例えば、ＳＲＩ−１とする。）を仕事として登録する。ＳＲＩ−１がイントレイに登録された後のＳＯＰ１３０の処理はポジション処理部２３２ｃによって制御されるポジション処理にて行われる。ポジション処理の詳細については後述する。

ステップＳ５０９にて、特定されたＳＯＰ１３０（ＳＲＩ−１に対応するＳＯＰ１３０）に関する仕事が完了したか否かが判断される。例えば、担当スタッフのアウトトレイにＳＲＩ−１に関する処理が完了したことを示す処理完了通知をポジション処理部２３２ｃから受けることによって、当該特定されたＳＯＰ１３０に関する仕事が完了したと判断する。ＳＯＰ１３０に関する仕事が完了した場合は、ステップＳ５１１へ進み、ＳＲＩが要求するサービスが完了した否か判断される。ＳＲＩに対応するプロセス１０８内の処理が全て終了している場合、即ち、次のＳＯＰがエグジット１３２にある場合、サービス完了と判断される。サービス完了の場合は、ステップＳ５１３へ進んで評価算出処理が行われる。ステップＳ５１３の評価算出処理では、処理が完了したＳＲＩに関して、処理ログ記録部２３２ｄが記録するデータに基づいて、当該ＳＲＩに関する評価指標が算出される。算出される評価指標は上述したように、収益性、作業効率、サービスリードタイム、サービス品質、作業内訳等である。評価算出処理終了後、サービス提供進行処理を終了する。ステップＳ５１１にて、サービス完了でないと判断された場合は、ステップＳ５０３へ戻り次のＳＯＰを特定する。

以下、ポジション処理部２３２ｃによって制御されるポジション処理について説明する。ポジション処理は、各ポジション１１０（担当スタッフ又はマネージャー）によってＳＯＰ１３０に関する処理が具体的に実行される手順をシミュレーションするための処理である。本形態のポジション処理の概略について図３０を用いて説明する。図３０に示す例では、ＳＯＰ１３０ａに、ＳＯＰ１３０ａを実行する担当スタッフとしてスタッフ１１０ｂが対応付けられ、スタッフ１１０ｂには上司としてマネージャー１１０ａが対応付けられている。スタッフ１１０ｂにはイントレイ１４０及びアウトトレイ１４１が、マネージャー１１０ａにはイントレイ１５０及びアウトトレイ１５１がそれぞれ対応付けられている。

各ポジション１１０においてイントレイ１４０、１５０に登録された仕事を処理する手順は基本的に同じである。まず、イントレイ１４０、１５０に登録された複数の仕事のうち、所定の条件に基づいていずれか１つの仕事を実行すべき仕事（以下「処理仕事」という。）として選択し、選択された処理仕事を実行する。シミュレーションにおける「処理仕事の実行」は、例えば、予定処理時間を上述した労働力及び予定作業量から求め当該時間を消費する。また、決定すべき事項がある場合は所定の条件に基づいて決定する。当該処理仕事が終了すると、終了した処理仕事を「処理済み仕事」としてアウトトレイ１４１、１５１に登録する。仕事の種類に応じて「処理済みＳＲＩ」「処理済みＥＩ」又は「処理済みＣＩ」という時がある。

図３０では、既にイントレイ１４０に２つのＳＲＩ（ＳＲＩ−１及びＳＲＩ−２）が仕事として登録されている状態において、ＳＯＰ１３０ａの処理を要求するＳＲＩ（ＳＲＩ−３）がイントレイ１４０に追加されるようすを示す。スタッフ１１０ｂはイントレイ１４０に登録された仕事を実行する。図３０のように複数の仕事がイントレイ１４０に存在する場合は、各仕事に対応付けられた優先度、或いはイントレイ１４０に登録された順等に基づいて実行すべき仕事を決定する。処理済み仕事はアウトトレイ１４１に登録され、サービス提供進行部２３２ｂに対して対応するＳＯＰ１３０の処理が完了したことが通知される。

なお、本形態では、ＳＯＰ１３０の処理に関して例外が発生した場合に例外に対応するための例外処理が行われる。例外処理は、スタッフ１１０ｂのみによって行われる場合と、マネージャー１１０ａから対応処置を示す指示を得ることによって行われる場合とがある。以下、マネージャー１１０ａから指示を得る場合の手順について説明する。例外の発生の有無は、処理済み仕事としての処理済みＳＲＩがアウトトレイ１４１に登録された段階で、所定の例外発生条件に基づいて判断される。処理済みＳＲＩが例外に対応するための仕事（ＥＩ）となってマネージャー１１０ａのイントレイ１５０に登録される。マネージャー１１０aは、イントレイ１５０に登録されたＥＩを、例えば登録された順に実行する。

マネージャー１１０ａにおける処理によって、ＥＩに関する指示が決定される。マネージャー１１０ａによる処理が終了した処理済み仕事はアウトトレイ１５１に登録され、指示を伴うＥＩ（以下、「指示ＥＩ」又は「意志決定済みＥＩ」という。）としてスタッフ１１０ｂのイントレイ１４０に登録される。イントレイ１４０に登録された指示ＥＩが処理仕事として選択されると、マネージャー１１０ａの指示に基づいて、例えばやり直し処理が実行される。当該やり直し処理が終了すると、処理済みＥＩがアウトトレイ１４１に登録され、処理済みＥＩに対応するＳＲＩに関する処理が完了したことがサービス提供進行部２３２ｂに対して通知される。

なお、本形態では、上述した例外処理と同様に、他のスタッフ１１０ｃでの処理を必要とする情報交換処理も実行される。情報交換処理の場合はＳＲＩは情報交換に対応する仕事（ＣＩ）となり、情報交換の相手となる他のスタッフ１１０ｃにおいて例外処理におけるマネージャー１１０ａと同様の処理が行われる。

時間の経過に伴ってＳＲＩがスタッフ１１０ａのイントレイ１４０に次々登録される場合の、スタッフ１１０ｂ及びマネージャー１１０ａそれぞれにおける処理の時間的関係について、図３１に示すシーケンス図を用いて説明する。例えば、ＳＲＩ−０に関して例外が発生し、マネージャー１１０ａから指示を得ることによってＳＲＩ−０の処理を完了するまでについて説明する。本形態では、イントレイ１４０、１５０に登録された仕事は登録順に処理される。なお、イントレイ１４０には、登録されているＳＲＩの枝番のみが示されている。スタッフ１１０ｂがＳＲＩ−０を処理中（ステップＳ１６０）にＳＲＩ−１がイントレイ１４０に登録される（ステップＳ１６１）。ＳＲＩ−０はその処理が終了するとアウトトレイ１４１に処理済みＳＲＩ−０として登録され、例外発生の有無が判断される（ステップＳ１６２）。

本形態では例外が発生したと判断され、かつ、更にマネージャー１１０ａの判断を求めるので、処理済みＳＲＩ−０はＥＩ−０としてマネージャー１１０ａのイントレイ１５０に登録される（ステップＳ１６３）。スタッフ１１０ｂはＥＩ−０に関して、マネージャー１１０ａの指示待ち状態となるが、その際、イントレイ１４０に別の仕事が登録されている場合は、当該仕事を処理する。本形態では、ＳＲＩ−１が登録されているので、処理仕事としてＳＲＩ−１が選択され（ステップＳ１６４）、スタッフ１１０ｂはＳＲＩ−１に対応するＳＯＰを実行する（ステップＳ１６５）。

マネージャー１１０ａは、ＥＸ−０がイントレイ１５０に登録された際には、他のスタッフからのＥＩ−Ｘ０に関する処理を実行している（ステップＳ１６６）。ＥＩ−Ｘ０に関する処理が終了すると、アウトトレイ１５１に登録され、指示付きの指示ＥＩ−Ｘ０が他のスタッフのイントレイに登録される（ステップＳ１６７）。ＥI−Ｘ０がアウトトレイ１５１に登録されると、処理待ち状態であったＥＩ−０が処理仕事として選択され（ステップＳ１６８）、ＥＩ−０が実行される（ステップＳ１６９）。ＥＩ−０が終了すると、即ち、例外に対する指示が決定すると、アウトトレイ１５１に指示ＥＩ−０が登録され（ステップＳ１７０）、続いて、指示ＥＩ−０はスタッフ１１０ｂのイントレイ１４０にも登録される（ステップＳ１７１）。

本形態では、イントレイ１４０には指示ＥＩ−０が登録される前にＳＲＩ−２が登録されている（ステップＳ１７２）。指示ＥＩ−０がイントレイ１４０に登録された時に実行中であったＳＲＩ−１が実行されると、処理済みＳＲＩ−１がアウトトレイ１４１に登録される（ステップＳ１７３）。アウトトレイ１４１に処理済みＳＲＩ−１が登録されると、例外が発生したか否かが判断され、本形態では、例外は発生しないと判断されるので、ＳＲＩ−１に対応する処理が完了したことがサービス提供進行部２３２ｂへ通知される（ステップＳ１７４）。

処理済みＳＲＩ−１がアウトトレイ１４１に登録されると、イントレイ１４１に登録された仕事から次の処理仕事が選択される。イントレイ１４１には、ＳＲＩ−２及び指示ＥＩ−０が登録されている状態であり、ＳＲＩ−２が先に登録されたので、ＳＲＩ−２が処理仕事として選択される（ステップＳ１７５）。ＳＲＩ−２が終了すると、例外発生の有無が判断され、本形態では例外が発生したと判断される（ステップＳ１７６）。例外の発生からマネージャー１１０ａから指示を得るまでの手順は上述の場合と同様である。一方、ＳＲＩ−２が終了する前に、ＳＲＩ−３がイントレイ１４１に登録される（ステップＳ１７７）。

ＳＲＩ−２が終了して処理済みＳＲＩ−２がアウトトレイ１４１に登録されると、スタッフ１１０ｂに対してイントレイ１４１に登録されている仕事から次の処理仕事が選択される。イントレイ１４０には、ＳＲＩ−３及び指示ＥＩ−０が登録されているが、指示ＥＩ−０が先に登録されたので、指示ＥＩ−０が処理仕事として選択される。スタッフ１１０ｂによるマネージャー１１０ａの指示に基づいて指示ＥＩ−０が行われ（ステップＳ１７９）、処理が終了すると処理済みＥＩ−０がアウトトレイ１４１に登録される（ステップＳ１８０）。例外処理を経た処理済みＥＩ−０に対しては、例外の有無は判断されずに、対応するＳＲＩ−０に関する処理が完了したことがサービス提供進行部２３２ｂへ通知される（ステップＳ１８１）。通知を受けたサービス提供進行部２３２ｂは、ＳＲＩ−０に関して次に実行すべきＳＯＰを特定する。

なお、図３１に示すスタッフ１１０ｂ、マネージャー１１０ａ、スタッフ１１０ｂのイントレイ１４０及びアウトトレイ１４１、マネージャー１１０ａのイントレイ１５０及びアウトトレイ１５１のそれぞれは、処理ログ記録部２３２ｄによって各ＷＩ（ＳＲＩ、ＣＩ、ＥＩ）に関する処理時間や処理回数等が記録されるオブジェクトである。例えば、各ＳＯＰについて各ＳＲＩの処理にかかった処理時間を記録する。イントレイ１４０、１５０については、イントレイ１４０、１５０に登録されているＳＲＩの固数とその個数の継続時間を記録する。また、シミュレーション中に処理されたＳＲＩ、ＥＩ及びＣＩの回数もカウントする。

更に、処理ログ記録部２３２ｄは、各ＷＩの発生時刻及び処理完了時刻を記録し、更に、ＳＯＰ毎に各ポジション１１０ａの状態とその継続時間も計時する。シミュレーション中に処理ログ記録部２３２ｄによって記録されるデータは、提供されるサービス１０４に関連付けられる。処理ログ記録部２３２ｄによってシミュレーション中に記録される処理時間、待ち時間、個数等は、従来のイベントドリブン型のシミュレーションツールで一般的なものである。これらのデータから、評価算出処理や後述する評価処理にて様々な角度からビジネスプロセスの実世界で利用される評価指標が得られる。

ポジション処理にはスタッフ１１０ｂの動作をシミュレートするスタッフ処理とマネージャー１１０ａの動作をシミュレートするマネージャー処理とが含まれる。まず、スタッフ処理について、図３２に示すフローチャートに従って説明する。スタッフ処理は、シミュレーション実行中に担当スタッフとしての各ポジション１１０について繰り返し実行される。

まず、ステップＳ６０１にてスタッフ１１０ｂに対応付けられたイントレイ１４０を参照し、イントレイ１４０に仕事が存在するか否かを判断する。イントレイ１４０に仕事が存在する場合はステップＳ６０２に進み、イントレイ１４０に存在する仕事から、例えばイントレイ１４０に登録された順に処理仕事を特定する。仕事には、ＳＲＩ、ＥＩ、及びＣＩがあるが、まず、ＳＲＩが処理仕事として特定された場合について説明する。処理仕事としてＥＩ及びＣＩが特定された場合については後述する。

処理仕事が特定されるとステップＳ６０３へ進み、仕事処理としてＳＲＩに対応するＳＯＰ１３０（以下「処理ＳＯＰ」という。）に関する処理を開始する。処理ＳＯＰに関する処理では、例えば、処理ＳＯＰが処理されることにより得られる処理時間が算出される。処理時間は、予定処理時間（予定作業量／処理速度）によって求められる。ステップＳ６０３において処理ＳＯＰに関する処理が終了するとステップＳ６０４へ進み、処理ＳＯＰについての処理済みＳＲＩをアウトトレイ１４１に登録する。

続いて、ステップＳ６０５に進み、アウトトレイ１４１に登録された仕事に関する処理が完了したか否かが判断される。登録されている仕事が処理済みＥＩ又は処理済みＣＩである場合、仕事は完了と判断され、ステップＳ６０６へ進んで対応するＳＲＩに関する処理完了通知がサービス提供進行部２３２ｂへ発行される。処理完了を通知後、次の仕事を処理するためにステップＳ６０１へ戻る、ステップＳ６０５にて仕事に関する処理が完了したと判断されない場合は、ステップＳ６０７へ進んで例外発生処理及び情報交換処理が行われる。例外発生処理及び情報交換処理については後述する。例外発生処理等の終了後、イントレイ１４０に登録されている次の仕事を処理するためにステップＳ６０１へ戻る。なお、スタッフ処理はシミュレーション期間が終了した時点で強制的に終了される。

例外発生処理について、図３３に示すフローチャートに従って説明する。まず、ステップＳ６１０にて例外が発生したか否かが判断される。例外の発生は上述したように、エンタープライズ１０１の予定例外発生率と影響係数に基づいて決定される。例外が発生しない場合は、ステップＳ６１７へ進んで対応するＳＲＩに関する処理完了通知をサービス提供進行部２３２ｂへ発行して例外発生処理を終了する。例外が発生した場合はステップＳ６１２へ進む。ステップＳ６１２では、意志決定者を決定する。本形態では、エンタープライズ１０１の権利集中性に基づいて、上司であるマネージャー１１０ａが対応するか、担当スタッフ１１０ｂが対応するかを決定する。例えば、権利集中性が高いほど、例外処理は上司によって対応されるように設定する。

マネージャー１１０ａが対応する場合は、ステップＳ６１４へ進み、アウトトレイ１４１の処理済みＳＲＩをマネージャー１１０ａのイントレイ１５０にＥＩとして登録して例外発生処理を終了する。マネージャー１１０ａにおいて行われる上司処理については後述する。一方、ステップＳ６１２にて、担当スタッフ１１０ｂ自身が対応すると決定された場合は、ステップＳ６１６にて担当スタッフ１１０ｂによるスタッフ対応処理が行われる。スタッフ対応処理では、当該例外に対応するための意志が決定され、当該処理が終了すると、ステップＳ６１８へ進み、意志決定済みＥＩを自身のイントレイ１４０に登録して例外発生処理を終了する。意志決定の処理時間は、ＥＩの作業量及び処理速度によって決定され、処理速度はＳＲＩの処理速度と同様にスタッフ１１０ｂのスキルによって影響を受ける。本形態における例外処理の意志決定は、処理ＳＯＰを完全にやり直す「リワーク」、半分やり直す「ハーフワーク」、「無視」のいずれかである。決定内容は所定の確率によって決定される。

マネージャー１１０ａにおける処理である上司処理について図３４のフローチャートに従って説明する。まず、ステップＳ６２１にて、イントレイ１５０に仕事が登録あるか否かが判断される。マネージャー１１０ａのイントレイ１５０に登録される仕事は各担当スタッフからのＥＩである。イントレイ１５０に仕事がある場合は、ステップＳ６２２にて実行する仕事（処理仕事）を決定する。スタッフ処理と同様に、登録順に処理仕事を特定する。処理仕事が特定されるとステップＳ６２３にて仕事処理として意志決定処理が行われる。意志決定処理においては、上述したスタッフ対応処理と同様の要領で例外に対するマネージャー１１０ａの意志を決定する。意志決定処理によって意志が決定されると、ステップＳ６２４へ進んで意志決定済みＥＩをアウトトレイ１５１へ登録し、担当スタッフのイントレイ１４０へ登録する。

スタッフ処理のステップＳ６０２において特定された仕事が意志決定済みＥＩの場合は、続くステップＳ６０３にて仕事処理としてＥＩ処理が行われる。ＥＩ処理とは、ＥＩに対応付けられた意志決定に基づいて行われる処理である。例えば、作業量が１０人時間のＳＯＰに対するＥＩの場合、意志決定がハーフワークである時は、作業量は５人時間となる。ポジション処理部２３２ｃは、作業量だけ変更して通常のＳＲＩの処理と同様の処理を実行する。ＥＩ処理終了後、ＥＩ処理が終了したことを示す処理済みＥＩがアウトトレイ１４１に登録される。

情報交換処理について図３５に示すフローチャートに従って説明する。まず、ステップＳ６３１にて、処理ＳＯＰに関して、情報交換に対応する仕事であるＣＩが発生するか否かが判断される。ＣＩの発生は上述したように、処理ＳＯＰの不確定性、エンタープライズ１０１の公式性等に基づいて決定される。例えば、公式性が高いほどミーティングや会議等の公式な情報交換を行う確率が高くなる。ＣＩが発生しない場合は、ステップＳ６３４にて対応するＳＲＩに関する処理完了通知を発行後、情報交換処理を終了する。ＣＩが発生した場合は、ステップＳ６３２に進み、処理ＳＯＰの情報依存先としてコミュニケーションリンク１１９によってリンクされているＳＯＰ１３０を特定する。情報依存先であるＳＯＰ１３０が特定されると、ステップＳ６３３へ進み、情報依存先のＳＯＰの担当スタッフ（以下、「依存先スタッフ」という。）のイントレイに、処理ＳＯＰに関するＣＩを登録して、情報交換処理を終了する。

依存先スタッフとしてのスタッフ処理について説明する。依存先スタッフにおけるスタッフ処理のステップＳ６０２にてＣＩが処理仕事として特定されると、ステップＳ６０３では仕事処理としてＣＩ処理が行われる。ＣＩ処理では、ＣＩに対応付けられた作業量に応じた処理時間が算出され、当該時間が消費される。ＣＩ処理が終了すると、処理ＳＯＰに関する処理済みＳＲＩが依存先スタッフのアウトトレイを経て担当スタッフ１１０ｂのアウトトレイ１４１に登録される。

最後に、評価処理部２３３によって制御される評価処理について図３６に示すフローチャートに従って説明する。まず、ステップＳ９０１にて、ユーザによって特定の評価指標が所定のメニューから選択されることにより、表示すべき評価指標が特定される。次にスップＳ９０２にて、選択された評価指標を算出するための全てのＳＲＩに関してステップＳ５１３にて算出された評価に関するデータを収集する。ステップＳ９０３にて、収集したデータに基づいて選択された評価指標を求め、上述したようなグラフや表としてモニタに表示する。その後、ステップＳ９０４へ進み、評価処理を終了するか否かが判断され、終了する場合は評価処理を終了し、終了しない場合は、ステップＳ９０１へ戻る。例えば、ユーザによって所定の終了操作がされた場合に、評価処理は終了すると判断される。

クライアント定義部２３１ａとしての制御ユニット２３０は、ステップＳ３０２によりＣＯＰ定義手段として機能し、ステップＳ３０３によりＣＯＰ対応付け手段として機能し、ステップＳ３０４により発生条件定義手段として機能する。サービス定義部２３１ｂとしての制御ユニット２３０はステップＳ３１１及びステップＳ３１２によりＳＯＰ定義手段として機能する。シミュレーション部２３２としての制御ユニット２３０は、ステップＳ４０３によりクライアント処理進行手段として機能し、ステップＳ４０４により要求発生手段として機能し、サービス提供進行処理及びスタッフ処理によりサービス提供手段として機能する。

更に、制御ユニット２３０は、評価処理により評価処理手段として機能する。また、サービス定義部２３１ｂとしての制御ユニット２３０は、ステップＳ３１１によりグループ定義手段として機能し、ステップＳ３１２によりグループ配置手段として機能する。シミュレーション部２３２としての制御ユニット２３０は、ステップＳ５０３により処理ＳＯＰ特定手段として機能し、ステップＳ５０８により行列登録手段として機能し、スタッフ処理によって処理実行手段として機能する。

本発明は上記形態に限定されることなく、種々の形態で実施することができる。例えば、上記形態では、各ポジション１１０について人数、及び労働力等を設定し、当該設定内容に基づいて処理を行ったが、各ポジション１１０に対して、オーガニゼーション１０９に所属する個々のメンバーを対応付けることも可能である。以下、各メンバーをポジション１１０に対応付ける手順について説明する。

まず、メンバーリストを作成する。メンバーリストは、図３７に示すようなメンバーリスト作成画面１０００にて行えばよい。メンバーリスト作成画面１０００では、各メンバーの氏名及び属性が登録可能である。メンバーの属性としては、例えば、スキルレベル、スキル分野、経験レベル、及びサラリー等がある。リスト部１０００ａには、メンバーリストに登録されているメンバーが表示される。図３７では、メンバーＡＡＡ〜メンバーＥＥＥの５人がリスト部１０００ａに表示されている状態である。例えば、所定のスクロール操作によって全てのメンバーを表示させることができる。

以下、図３８に示すプロセス１０８におけるポジション１１０に対してメンバーを配置するためのメンバー配置処理について、図３９に示すフローチャートに従って説明する。メンバー配置処理はサービス定義部２３１ｂ制御ユニット２３０によって制御される。図３８におけるプロセス１０８では、各ポジション１１０が各ＳＯＰに対応付けられた状態である。以下、スタッフＡが処理対象のポジション１１０である場合について説明する。まず、ステップＳ９５０にて、処理対象のポジション１１０であるスタッフＡに関してメンバーを対応付けるためのメンバー配置画面１１００がモニタに表示される。

例えば、モニタに表示されたプロセス１０８において、処理対象のスタッフＡが所定の選択方法によって選択されることにより、図４０に示すようなメンバー配置画面１１００がモニタに表示される。メンバー配置画面１１００が表示されると、メンバーの選択待ち状態となり、ステップＳ９５２にてスタッフＡに対応付けるメンバーが選択されたか否かが判断される。メンバー選択部１１００ａにおいて、メンバーリストに登録されているメンバーをプルダウンメニューによって表示させ、追加ボタンがクリックされると、「表示されたメンバーをスタッフＡを構成するメンバーとして選択」したと判断される。

このメンバーの選択の際に、選択されたメンバーに関して、スタッフＡへ提供する労働力の割合が設定される。ポジション１１０へ提供する労働力は、メンバー１人の労働力の最大値を１とした場合の割合で示す。スタッフＡに対応付けられたメンバーは配置メンバー表示部１１００ｂに表示される。図４０の例では、メンバーＡＡＡとメンバーＢＢＢがそれぞれ０．５の労働力でスタッフＡに対応付けられていることを示す。メンバー選択部１１００ａにて、メンバーＣＣＣが選択され、提供する労働力の割合が設定され、追加ボタンがクリックされることにより、メンバーＣＣＣが選択されたと判断される。続いて、ステップＳ９５４にて、選択されたメンバーＣＣＣの労働力の総和が１を超えているか否かが判断される。

このように、本形態では、各メンバーは複数のポジションに配置されることが可能であるが、各ポジションへ提供する労働力の総和が１を超えないように構成されている。例えば、各メンバーに対して、ポジション１１０に提供している労働力の累積値を提供労働力として対応付けておけばよい。メンバーＣＣＣの提供労働力が１を超える場合は、ステップＳ９５６に進み、エラーメッセージを表示してステップＳ９５２へ戻る。提供労働力が１を超えない場合は、ステップＳ９５８へ進み、メンバーＣＣＣの提供労働力を更新し、メンバーＣＣＣをスタッフＡの構成メンバーとして登録する。これにより、メンバーＣＣＣはポジション（スタッフＡ）に配置される。

次に、ステップＳ９６０にて、メンバー配置処理を終了するか否かが判断され、終了すると判断された場合はメンバー配置処理を終了する。終了すると判断されない場合は、メンバーを更に追加するためにステップＳ９５２に戻る。例えば、メンバー配置画面１１００が閉じられることにより、メンバー配置処理を終了すると判断する。以上の方法によってスタッフＡにメンバーが配置された場合、スタッフＡの労働力は、各メンバーのスタッフＡに関する提供労働力の総和になり、スタッフＡのコストは、各メンバーのサラリーの総和となる。また、スタッフＡとしてのスキルレベルが必要となる処理においては、例えばスタッフＡに配置されたメンバーのレベルの平均、最低レベルまたは最多レベル等を、スタッフＡのスキルレベルとして扱えばよい。

更に、ツール１２１をエンタープライズ１０１が利用可能な道具のグループという概念とすれば、ポジション１１０と同様に設定することが可能である。まず、エンタープライズ１０１が利用可能な道具のリストを作成する。次に、当該リストに登録されている各道具をいずれかのツール１２１を構成する道具として配置する。当該配置の際に、各道具が配置されるツール１２１に提供するその道具の処理能力の割合が０〜１の範囲で設定される。ツール１２１の処理能力は配置された道具の処理能力の割合の合計である。各道具に関して、その道具が配置された少なくとも１つのツール１２１に対して提供する処理能力の割合の合計が１を超えないように制御される。

更に、定義部２３１、シミュレーション部２３２、及び評価処理部２３３は、それぞれ物理的に異なる制御ユニット２３０に設けられ、必要なデータはデータ通信によって得られるように構成されてもよい。また、サービスを要求するクライアント及びサービスを提供するサービス提供者は様々な態様が考えられる。例えば、飛行機（クライアント）と飛行機管理会社（サービス提供者）の場合、空港（クライアント）と空港管理会社の場合、ビル（クライアント）とビル管理会社（サービス提供者）の場合等である。

また、クライアントの活動時間およびサービス提供者の活動時間を考慮してシミュレーションできるように構成してもよい。例えば、ＣＯＰ及の定義にクライアントの活動開始時刻および活動終了時刻を設定し、ＳＯＰの定義にサービス提供者の活動開始時刻及び活動終了時刻を設定し、シミュレーションにおいて、各活動時間にのみに活動されるように設定してもよい。これにより、クライアントとサービス提供者とが遠隔地にある場合、より正確なシミュレーションを提供することができる。なお、本形態にて示された各フローチャートにおける処理順序は、本発明を実現する限り変更可能である。

Claims (10)

1. 少なくとも１つのクライアントへサービス提供者がサービスを提供するためのビジネスプロセスをシミュレートすることにより、前記ビジネスプロセスを評価するプロセスマネジメント支援システムであって、
   前記各クライアントの活動内容を定義するクライアント定義部と、
   前記サービス提供者が提供するサービスに関して定義するサービス定義部と、
   所定期間において、前記各クライアントの活動によってサービスの要求が発生し、前記サービス提供者による前記サービスが提供される工程をシミュレートするシミュレーション部とを有し、
   前記クライアント定義部は、
   前記各クライアントが行う複数の活動を複数のクライアントオペレーション（ＣＯＰ）のそれぞれに対応させ、前記クライアント毎に前記シミュレート時における前記複数のＣＯＰの進行態様を定義するＣＯＰ定義手段と、
   前記複数のＣＯＰのそれぞれと、前記各ＣＯＰに対して前記サービス提供者によって提供されるサービスとを対応付けるＣＯＰ対応付け手段と、
   前記各ＣＯＰからサービスの要求を発生させるための条件を定義する発生条件定義手段とを有し、
   前記サービス定義部は、
   前記サービス提供者が前記ＣＯＰに対応付けられたサービスを提供するための手順を、前記サービス提供者の人的資源又は物的資源を対応付ける処理単位である複数のサービスオペレーション（ＳＯＰ）のそれぞれが処理される順序によって定義するＳＯＰ定義手段を有し、
   前記シミュレーション部は、
   前記各クライアントについて、前記進行態様に基づいて実行すべきＣＯＰを特定するクライアント処理進行手段と、
   前記クライアント処理進行手段によって特定されたＣＯＰに対応付けられたサービスの要求を、前記条件に基づいて発生させる要求発生手段と、
   前記要求が発生する毎に、前記特定されたＣＯＰに対応付けられたサービスに関して前記ＳＯＰ定義手段にて定義された手順として、前記各ＳＯＰの処理を、対応付けられた前記人的資源又は前記物的資源を使用して、前記定義された順序にて処理することにより、前記サービスを提供するための処理を行うサービス提供手段と、
   を有するプロセスマネジメント支援システム。
2. 前記ＣＯＰ対応付け手段は、
   前記各ＣＯＰから発生する各要求についてその要求の属性を定義する、請求の範囲第１項に記載のプロセスマネジメント支援システム。
3. 前記ＣＯＰ対応付け手段は、前記各ＣＯＰと前記各ＣＯＰに対して提供されるサービスに関して前記サービス定義部にて定義されるデータとを対応付け、
   前記シミュレーション部は、前記サービス定義部にて定義されるデータに基づいてシミュレーションを行い、
   前記シミュレーション部によるシミュレーションによって得られるデータを前記サービスに対応付けて管理し、前記得られるデータに基づいて前記サービスを提供するサービス提供者の活動を評価するための評価指標を求める評価処理手段が更に備えられた請求の範囲第１項又は第２項に記載のプロセスマネジメント支援システム。
4. 前記評価処理手段は、前記要求を単位にした前記評価指標からその統計を求める、請求項３に記載のプロセスマネジメント支援システム。
5. 前記サービス定義部は、
   前記サービス提供者を構成する複数のグループに関して定義するグループ定義手段と、
   前記各グループを、いずれかの前記ＳＯＰにそのＳＯＰを処理するグループとして対応付けるグループ配置手段と、を有し、
   前記サービス提供手段は、
   前記所定の順序に従って処理すべき前記ＳＯＰを特定する処理ＳＯＰ特定手段と、
   前記特定されたＳＯＰを、そのＳＯＰに対応付けられたグループの待ち行列に登録する行列登録手段と、
   前記待ち行列に登録された処理のうち、前記対応付けられたグループが実行すべき処理を決定し、前記対応付けられたグループによって前記実行すべき処理を実行させる処理実行手段と、を有する請求の範囲第１項〜第４項のいずれか１項に記載のプロセスマネジメント支援システム。
6. 前記処理実行手段は、前記実行すべき処理が他のグループにも処理させる必要がある場合に、前記他の要員の待ち行列に前記実行すべき処理を登録し、前記対応付けられたグループの待ち行列に登録された処理から次に実行すべき処理を決定し、前記対応付けられたグループを前記次に実行すべき処理を実行させる、請求項の範囲第５項に記載のプロセスマネジメント支援システム。
7. 前記サービス定義部は、
   前記サービス提供者に含まれる複数のメンバーを定義するメンバー定義手段と、
   前記各ＳＯＰに対して、前記ＳＯＰを処理するグループを対応付けるグループ配置手段と、
   前記複数のメンバーのうち少なくとも１人を、前記複数のグループのうち少なくとも１つのグループに対応付けるメンバー配置手段と、を有し、
   前記メンバー配置手段は、
   前記各メンバーに関して、対応付けられた前記少なくとも１つのグループに前記メンバーが提供する労働力を設定する労働力設定手段と、
   前記メンバーが対応付けられた前記少なくとも１つのグループに対して、前記メンバーが提供する前記労働力の合計が、所定の上限を超えないように前記労働力設定手段を制御する労働力制御手段とを有し、
   前記サービス提供手段は、前記設定された労働力の総和を前記グループの労働力として前記グループによって処理される前記ＳＯＰの処理速度に影響させる、請求の範囲第１項〜第４項のいずれかに記載のプロセスマネジメント支援システム。
8. 前記サービス定義部は、
   前記各サービス提供者が利用可能な複数の道具を定義する道具定義手段と、
   前記各ＳＯＰに対して、前記ＳＯＰを処理するために利用される道具グループを対応付ける道具グループ配置手段と、
   前記複数の道具のうち少なくとも１つの道具を、前記複数の道具グループのうち少なくとも１つの道具グループに対応付ける道具配置手段と、を有し、
   前記道具配置手段は、
   前記各道具に関して、対応付けられた前記少なくとも１つの道具グループに前記道具が提供する処理能力を設定する処理能力設定手段と、
   前記道具が対応付けられた前記少なくとも１つの道具グループに対して、前記道具が提供する前記処理能力の合計が、所定の上限を超えないように前記処理能力設定手段を制御する処理能力制御手段とを有し、
   前記サービス提供手段は、前記設定された処理能力の総和を前記道具グループの労働力として前記グループによって処理される前記ＳＯＰの処理速度に影響させる、
   ことを特徴とする請求の範囲第１項〜第４項のいずれかに記載のプロセスマネジメント支援システム。
9. 少なくとも１つのクライアントへサービス提供者がサービスを提供するためのビジネスプロセスをシミュレートすることにより、前記ビジネスプロセスを評価するプロセスマネジメント支援におけるシミュレーション方法であって、
   前記各クライアントの活動内容を定義するクライアント定義段階と、
   前記サービス提供者が提供するサービスに関して定義するサービス定義段階と、
   所定期間において、前記各クライアントの活動によってサービスの要求が発生し、前記サービス提供者による前記サービスが提供される工程をシミュレートするシミュレーション段階とを有し、
   前記クライアント定義段階は、
   前記各クライアントが行う複数の活動を複数のクライアントオペレーション（ＣＯＰ）のそれぞれに対応させ、前記クライアント毎に前記シミュレート時における前記複数のＣＯＰの進行態様を定義するＣＯＰ定義段階と、
   前記複数のＣＯＰのそれぞれと、前記各ＣＯＰに対して前記サービス提供者によって提供されるサービスとを対応付けるＣＯＰ対応付け段階と、
   前記各ＣＯＰからサービスの要求を発生させるための条件を定義する発生条件定義段階とを有し、
   前記サービス定義段階は、
   前記サービス提供者が前記ＣＯＰに対応付けられたサービスを提供するための手順を、前記サービス提供者の人的資源又は物的資源を対応付ける処理単位である複数のサービスオペレーション（ＳＯＰ）のそれぞれが処理される順序によって定義するＳＯＰ定義段階を有し、
   前記シミュレーション段階は、
   前記各クライアントについて、前記進行態様に基づいて実行すべきＣＯＰを特定するクライアント処理進行段階と、
   前記クライアント処理進行手段によって特定されたＣＯＰに対応付けられたサービスの要求を、前記条件に基づいて発生させる要求発生段階と、
   前記要求が発生する毎に、前記特定されたＣＯＰに対応付けられたサービスに関して前記ＳＯＰ定義手段にて定義された手順として、前記各ＳＯＰの処理を、対応付けられた前記人的資源又は前記物的資源を使用して、前記定義された順序にて処理することにより、前記サービスを提供するための処理を行うサービス提供段階と、
   を有するシミュレーション方法。
10. 前記ＣＯＰ対応付け段階において、前記各ＣＯＰから発生する各要求についてその要求の属性を定義する請求の範囲第９項に記載のシミュレーション方法。

Images