(57)【要約】【課題】１つの側面では、再利用が可能なプロセス定義を生成する。【解決手段】各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部（２０）に蓄積する。制御部（１８）により、業務は、記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、業務の内容を示しかつ複数の作業群間の関係を規定する業務サービスとに分離される。複数の作業群の各々は、作業群毎に業務を形式化したプロセス定義が生成される。生成されたプロセス定義を示す情報、及び業務サービスを示す情報は記憶部に記憶される。このように、業務を複数の作業群と複数の作業群間の関係を規定する業務サービスとに分離して、作業群毎に再利用可能なプロセス定義を生成することができる。【選択図】図１
2015114951.tif 000002
【特許請求の範囲】
【請求項１】
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部に蓄積し、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、
前記作業群毎に前記業務を形式化したプロセス定義を生成し、
前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
ことを含む処理をコンピュータに実行させるための業務形式化プログラム。
【請求項２】
前記複数の作業群は、前記業務の依頼に関係する作業を含む作業群と、前記業務の依頼の遂行に関係する作業を含む作業群とを含み、
前記業務の依頼に共通の作業または類似の作業を形式化したプロセス定義、及び前記業務の依頼の遂行に共通の作業または類似の作業を形式化したプロセス定義を生成する
請求項１に記載の業務形式化プログラム。
【請求項３】
前記業務サービスは、前記業務の依頼に関係する作業、及び前記業務の依頼の遂行に関係する作業の少なくとも一方の作業を行う作業者の集合を示す業務ドメインを、前記複数の作業群に含まれる少なくとも１つの作業群に関連付ける情報を含む
請求項１または請求項２に記載の業務形式化プログラム。
【請求項４】
前記業務サービスは、前記業務の依頼を、前記業務の依頼の遂行の作業を行う作業者または前記業務ドメインに振り分ける振分規則を含む
請求項３に記載の業務形式化プログラム。
【請求項５】
コンピュータが、
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部に蓄積し、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、
前記作業群毎に前記業務を形式化したプロセス定義を生成し、
前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
ことを含む業務形式化方法。
【請求項６】
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を蓄積する記憶部と、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、前記作業群毎に前記業務を形式化したプロセス定義を生成し、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する制御部と、
を備えた業務形式化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務形式化プログラム、業務形式化方法及び業務形式化装置に関する。
【背景技術】
【０００２】
業務上で行われる作業を分類して抽出することにより、システム上でのプロセスとして形式化し、形式化されたプロセスを再利用して同一の業務または類似する業務をシステム上で実行したり分析したりする処理が行われている。例えば、業務の流れを形式化したプロセスとして予め定義しておき、定義されたプロセスに従って処理を進めるワークフローシステムが知られている。ワークフローシステムでは、業務を分析してワークフローシステムを構築すること、及び業務の変更に応じてプロセスの追加、並びにプロセスの内容または順序を変更することによるワークフローシステムを再構築することが行われる。
【０００３】
ワークフローシステムについて、業務の複雑化及び迅速な業務の分析の要求等に伴い、ワークフローシステムの構築及び再構築を簡単に行う技術が知られている。例えば、ワークフローシステムに業務アプリケーションまたは業務データベースを新規に追加したり更新することを簡単に行う技術がある。また、ワークフローシステムで使用するアプリケーションプログラムの再利用を促進するために、業務仕様の類型を生成し、生成した業務仕様の類型を利用してワークフローシステムの開発を支援する技術が知られている。さらに、ワークフローの再利用を可能にするために、一連の手続を示すワークフローに含まれる利用困難な手続について、利用可能な手続を探索し、探索結果を再利用可能に対応付けてデータベースへ登録する技術が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−２０７４７４号公報
【特許文献２】特開平１１−８５８８０号公報
【特許文献３】特開２００４−１３３７４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、業務には、業務上で行われる特定の作業について、高度な技術を有する専門家の協力が求められる場合がある。この場合、依頼者が特定の作業を専門家に依頼して、専門家が依頼された作業を受領して遂行する業務の流れとなり、業務は、作業を依頼する依頼側と作業の依頼を受領して遂行する受領側との両者の観点で考えることができる。従って、依頼側と受領側との作業内容を考慮して業務を形式化することで、プロセス定義を再利用することができる。
【０００６】
依頼側の作業と受領側の作業との双方の作業内容を考慮して業務を形式化する場合、業務の再現性は向上するものの、プロセス定義が膨大かつ複雑になり、業務を形式化した後の保守に膨大な負担が求められる。例えば、依頼側で受領側の作業内容を考慮する場合、作業の依頼の受領率向上と、プロセス定義の膨大化による保守性の低下とのトレードオフの関係になる。また、受領側で作業内容を考慮してプロセス定義を追加する場合、類似した作業内容のプロセス定義が増加し、保守の負担が増加する。さらに、受領側で作業を遂行する専門家毎に作業内容が相違する場合、専門家毎に場合分けする形式化のプロセス定義、または専門家毎に別個のプロセス定義を生成することになり、保守の負担が増大する。なお、専門家別に形式化した業務は、個々の作業が固定的になり汎用性に乏しくなり、プロセス定義を再利用できない場合もある。
【０００７】
そこで、ワークフローに業務アプリケーションと業務データベースを新規に追加したり更新する技術を用いて、業務を形式化することが考えられる。しかしながら、ワークフローに業務アプリケーション等を新規に追加したり更新することでは、依頼側の作業と受領側の作業との双方の作業内容を考慮されないことがある。また、作業の種類ごとにワークフローが増大し、保守の負担が増大する。従って、ワークフローに業務アプリケーション等を新規に追加したり更新することでは、業務を形式化したプロセス定義を再利用できない場合がある。
【０００８】
また、生成された業務仕様の類型を利用する技術では、依頼側の作業と受領側の作業との双方の作業内容を考慮されないことがある。従って、業務仕様の類型を利用することでも、業務を形式化したプロセス定義を再利用できない場合がある。
【０００９】
さらに、ワークフローに含まれる利用困難な手続の探索結果を再利用可能に対応付けてデータベースへ登録する技術では、利用困難な手続への対象は可能であるものの、依頼側の作業と受領側の作業との双方の作業内容を考慮されないことがある。従って、ワークフローに含まれる利用困難な手続の探索結果を再利用可能に対応付けてデータベースへ登録することでも、業務を形式化したプロセス定義を再利用できない場合がある。
【００１０】
１つの側面では、簡単に再利用できるプロセス定義を生成することを目的とする。
【課題を解決するための手段】
【００１１】
１つの態様では、各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部に蓄積する。業務は、記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、業務の内容を示しかつ複数の作業群間の関係を規定する業務サービスとに分離される。複数の作業群の各々は、作業群毎に業務を形式化したプロセス定義が生成される。生成されたプロセス定義を示す情報、及び業務サービスを示す情報は記憶部に記憶される。このように、業務を複数の作業群と複数の作業群間の関係を規定する業務サービスとに分離して、作業群毎に再利用可能なプロセス定義を生成することができる。
【発明の効果】
【００１２】
１つの側面では、再利用が可能なプロセス定義を生成することができる、という効果を有する。
【図面の簡単な説明】
【００１３】
【図１】実施形態に係る業務形式化装置の一例を示すブロック図である。
【図２】コンピュータシステムの一例を示すブロック図である。
【図３】コンピュータシステムを機能的に表現した一例を示すブロックである。
【図４】作業依頼履歴データベースの一例を示すイメージ図である。
【図５】業務サービスデータベースの一例を示すイメージ図である。
【図６】業務ドメインデータベースの一例を示すイメージ図である。
【図７】振り分けルールデータベースの一例を示すイメージ図である。
【図８】作業項目データベースの一例を示すイメージ図である。
【図９】プロセス定義データベースの一例を示すイメージ図である。
【図１０】作業項目定義データベースの一例を示すイメージ図である。
【図１１】業務を遂行する処理の全体的な流れの一例を示すフローチャートである。
【図１２】業務遂行処理での各部の関係の一例を示すシーケンスフローの一部である。
【図１３】業務遂行処理での各部の関係の一例を示すシーケンスフローの一部である。
【図１４】業務遂行処理での各部の関係の一例を示すシーケンスフローの一部である。
【図１５】業務遂行処理での各部の関係の一例を示すシーケンスフローの一部である。
【図１６】業務遂行リストの表示画面の一例を示すイメージ図である。
【図１７】作業遂行画面の一例を示すイメージ図である。
【図１８】作業項目の遂行処理の流れの一例を示すフローチャートである。
【図１９】作業項目の遂行処理での各部の関係の一例を示すシーケンスフローである。
【図２０】作業依頼処理の一例を示すフローチャートである。
【図２１】作業依頼処理での各部の関係の一例を示すシーケンスフローである。
【図２２】業務サービスの利用に関する説明図である。
【図２３】業務ドメインへの依頼に関する説明図である。
【図２４】業務サービスの提案処理の流れの一例を示すフローチャートである。
【図２５】業務サービスの提案処理での各部の関係の一例を示すシーケンスフローの一部である。
【図２６】業務サービスの提案処理での各部の関係の一例を示すシーケンスフローの一部である。
【図２７】業務サービスの提案処理で業務サービス特定の一例を示す説明図である。
【図２８】業務サービスの提案処理で業務サービス設定の一例を示す説明図である。
【図２９】業務サービスの提案に関係する情報の流れの一例を示す説明図である。
【図３０】業務サービスの統合に関係する情報の流れの一例を示す説明図である。
【図３１】コンピュータシステムの継続的な処理の流れの一例を示す説明図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。
【００１５】
図１に、本実施形態に係る業務形式化装置の一例を示す。業務形式化装置１０は、ＣＰＵ１２及びメモリ１４を含んでおり、メモリ１４には業務形式化プログラム１６が記憶されている。業務形式化装置１０では、ＣＰＵ１２が業務形式化プログラム１６を実行することにより、制御部１８として動作する。また、業務形式化装置１０は、不揮発性の記憶部２０を備えており、記憶部２０には、作業の依頼履歴を示す情報、プロセス定義を示す情報、及び業務サービスを示す情報が蓄積される。
【００１６】
業務形式化装置１０の制御部１８は、記憶部２０に蓄積された業務に含まれる作業の依頼履歴に基づいて、業務を、複数の作業群と、業務の内容を示しかつ複数の作業群間の関係を規定する業務サービスとに分離する。例えば、業務は、依頼側の作業を含む作業群と受領側の作業を含む作業群とに分離される。制御部１８は、複数の作業群の各々について、作業群毎に業務を形式化したプロセス定義を生成する。プロセス定義は、作業群による業務を形式化した情報である。制御部１８は、生成したプロセス定義を示す情報、及び業務サービスを示す情報を記憶部２０に再利用可能に記憶する。本実施形態では、作業群毎の業務に関係するメンバによる業務ドメイン単位で作業に対応することができる。
【００１７】
業務ドメインは、業務に関係するメンバを含む組織の総称を示す情報に対応する。メンバを含む組織は、公式組織、及び非公式組織の何れの組織を示す情報でもよい。また、業務ドメインは、メンバを追加するためのメンバ不在の組織を示す情報でもよい。さらに、業務ドメインは、他の業務ドメインとの所有関係を示す情報によって、業務ドメイン間で関係させることができ、所有関係を示す情報に基づく複数の業務ドメインによって組織の構造を表現することができる。業務ドメインの管理者は、例えば、組織として業務ドメインを司る場合には組織の管理責任者を対応させることができ、業務ドメインのメンバが窓口を司る場合にはメンバ自身を対応させることができる。
【００１８】
なお、業務ドメインは、業務上の作業の依頼を受領する受領側の単位として機能することができる。つまり、依頼者は、作業の遂行者を指定することなく、業務ドメインを指定して作業を依頼することができる。また、業務ドメインは、作業の引き受け、取り下げ、若しくは他の業務ドメインへの再依頼を行う受領側の単位として機能することができる。例えば、業務ドメインは、業務上の作業の依頼を受領し、各々予め定義された依頼振り分けルールに従って、メンバが作業を引き受ける、または取り下げる、若しくは他の業務ドメインに再依頼する処理を実行する当事者として機能することができる。依頼振り分けルールは、業務ドメインに含まれるメンバを特定するための条件を示す。
【００１９】
業務サービスは、引き受け可能な作業の依頼を募集する窓口の総称に対応する。例えば、業務サービスは、業務ドメインに登録されたメンバが引き受け可能な作業の仕様を示す情報に対応する。引き受け可能な作業の仕様の一例には、目的、入力情報、出力情報、及び期限などの情報が含まれる。業務サービスは、業務ドメインに登録されたメンバに、引き受け可能な作業の仕様を公開することで、利用を希望する業務サービスをメンバが検索することできる。引き受け可能な作業の仕様の公開、及び引き受け可能な作業の仕様の作成は、業務ドメインの管理者により行われる。つまり、業務ドメインの管理者は、業務サービスを作成し、業務ドメインに登録されたメンバに業務サービスを公開することができる。業務サービスには、引き受けた作業を遂行するためのプロセス定義と、依頼振り分けルールを指定して対応付けることができる。業務サービスの受領者は、対応付けたプロセス定義を利用したり管理することで、依頼者と受領者のプロセス定義の管理範囲を区分することができる。
【００２０】
なお、業務形式化装置１０は開示の技術における業務形式化装置の一例であり、業務形式化プログラム１６は開示の技術における業務形式化プログラムの一例である。また、本実施形態における制御部１８は開示の技術における制御部に対応し、記憶部２０は開示の技術における記憶部に対応する。
【００２１】
図２に、業務形式化装置１０をコンピュータで実現可能なシステムの一例としてコンピュータシステム１１を示す。また、図３に、図２に示すコンピュータシステム１１を機能的なブロックにより表現した一例を示す。図２及び図３に示すコンピュータシステム１１は、サーバ装置２２、及び複数のクライアント装置６６を備えている。業務形式化装置１０（図１）は、サーバ装置２２によって実現可能である。
【００２２】
サーバ装置２２はＣＰＵ２４、メモリ２６、及び不揮発性の格納部３６を備えている。ＣＰＵ２４、メモリ２６、及び格納部３６は、バス６４を介して互いに接続されている。また、サーバ装置２２は、ディスプレイ等の表示部２８、キーボード及びマウス等の入力部３０を備え、表示部２８及び入力部３０はバス６４に接続されている。また、サーバ装置２２は、挿入された記録媒体６５に対して読み書きするための装置（ＩＯ装置）３２がバス６４に接続されている。なお、格納部３６はＨＤＤ(Hard Disk Drive)やフラッシュメモリ等によって実現できる。また、サーバ装置２２はコンピュータネットワーク２１に接続するためのインタフェースである通信制御部３４を備え、通信制御部３４はバス６４に接続されている。
【００２３】
格納部３６には、業務形式化プログラム１６としての制御プログラム３８、及びデータベース（ＤＢ）５０が記憶されている。制御プログラム３８は、エンジン処理ルーチン４０、業務ドメイン管理処理ルーチン４２、定義管理処理ルーチン４４、業務サービス管理処理ルーチン４６、及び作業履歴管理処理ルーチン４８を含んでいる。ＣＰＵ２４が制御プログラム３８を格納部３６から読み出してメモリ２６に展開し、制御プログラム３８が有する各処理ルーチンを実行することで、サーバ装置２２は業務形式化装置１０の制御部１８（図１）として動作する。
【００２４】
なお、ＣＰＵ２４がエンジン処理ルーチン４０を実行することで、サーバ装置２２は図３に示すプロセスエンジン部８６として動作する。また、ＣＰＵ２４が業務ドメイン管理処理ルーチン４２を実行することで、サーバ装置２２は図３に示す業務ドメイン管理部９２として動作する。また、ＣＰＵ２４が定義管理処理ルーチン４４を実行することで、サーバ装置２２は図３に示すプロセス定義管理部９０として動作する。また、ＣＰＵ２４が業務サービス管理処理ルーチン４６を実行することで、サーバ装置２２は図３に示す業務サービス管理部８８として動作する。さらに、ＣＰＵ２４が作業履歴管理処理ルーチン４８を実行することで、サーバ装置２２は図３に示す作業依頼履歴管理部９４として動作する。
【００２５】
プロセスエンジン部８６は、プロセス定義の実行処理及び作業状態の管理処理を行うことができる。業務ドメイン管理部９２は、業務ドメインの登録処理、業務ドメインの検索処理、業務ドメインへの作業依頼処理、及び依頼振り分けルールの登録処理を行うことができる。プロセス定義管理部９０は、プロセス定義の登録処理、及びプロセス定義の検索処理を行うことができる。業務サービス管理部８８は、業務サービスの登録処理、業務サービスの検索処理、及び業務サービスの利用処理を行うことができる。作業依頼履歴管理部９４は、作業依頼履歴の登録処理、作業依頼履歴の検索処理、業務サービス公開の提案処理、及び業務サービスの利用の提案処理を行うことができる。
【００２６】
格納部３６に記憶されるデータベース５０には、作業項目定義データベース５９を含む作業項目データベース５８、及び作業依頼履歴データベース６０が蓄積される。また、データベース５０には、プロセス定義データベース６２、業務ドメインデータベース５２、業務サービスデータベース５４、振り分けルールデータベース５６が蓄積される。なお、以下の説明では、データベースをＤＢと略記する。
【００２７】
図４〜図１０に、ＤＢ５０に格納される各種ＤＢの一例を示す。図４に、作業依頼履歴ＤＢ６０の一例を示す。作業依頼履歴ＤＢ６０には、業務に関係する作業の依頼履歴を示す情報が登録される。図４では作業依頼履歴ＤＢ６０に、「ＩＤ」、「業務サービス」、「依頼元」、「依頼先」、「割当者」、「状態」、「依頼開始時刻」、「作業項目」、及び、「振り分けルール」の情報が登録される一例を示す。なお、「業務サービス」の情報には、業務サービスＤＢ５４（図５）に示されるＩＤが登録される。また、「依頼元」、「依頼先」、及び「割当者」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。さらに、「作業項目」の情報には、作業項目ＤＢ５８（図８）に示されるＩＤが登録される。さらにまた、「振り分けルール」の情報には、振り分けルールＤＢ５６（図７）に示されるＩＤが登録される。
【００２８】
図５に、業務サービスＤＢ５４の一例を示す。業務サービスＤＢ５４には、業務サービスに関係する情報が登録される。図５では業務サービスＤＢ５４に、「ＩＤ」、「名称」、「公開元」、「公開範囲」、「振り分けルール」、「プロセス定義」、「入力情報」、「出力情報」、及び、「タイプ」の情報が登録される一例を示す。なお、「公開元」と「公開範囲」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。また、「振り分けルール」の情報には、振り分けルールＤＢ５６（図７）に示されるＩＤが登録される。さらに、「プロセス定義」の情報には、プロセス定義ＤＢ６２（図９）に示されるＩＤが登録される。図６に、業務ドメインＤＢ５２の一例を示す。業務ドメインＤＢ５２には、業務ドメインに関係する情報が登録される。図６では業務ドメインＤＢ５２に、「ＩＤ」、「名称」、「タイプ」、「管理者」、「メンバ」、及び、「振り分けルール」の情報が登録される一例を示す。なお、「管理者」と「メンバ」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。また、「振り分けルール」の情報には、振り分けルールＤＢ５６（図７）に示されるＩＤが登録される。
【００２９】
図７に、振り分けルールＤＢ５６の一例を示す。振り分けルールＤＢ５６には、振り分け処理を行う場合の規則が登録される。図７では振り分けルールＤＢ５６に、「ＩＤ」、及び、「ルール定義」の情報が登録される一例を示す。図８に、作業項目ＤＢ５８の一例を示す。作業項目ＤＢ５８には、作業の項目を示す情報が登録される。図８では作業項目ＤＢ５８に、「ＩＤ」、「遂行者」、「状態」、「開始時刻」、及び、「作業項目定義」の情報が登録される一例を示す。なお、「遂行者」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。図９に、プロセス定義ＤＢ６２の一例を示す。プロセス定義ＤＢ６２には、プロセス定義を示す情報が登録される。図９ではプロセス定義ＤＢ６２に、「ＩＤ」、「名称」、「作成時刻」、及び「管理者」の情報が登録される一例を示す。なお、「管理者」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。図１０に、作業項目定義ＤＢ５９の一例を示す。作業項目定義ＤＢ５９には、作業の項目の定義を示す情報が登録される。図１０では作業項目定義ＤＢ５９に、「ＩＤ」、「名称」、「作成内容」、「依頼先」、「開始条件」、「終了条件」、及び、「プロセス定義」の情報が登録される一例を示す。なお、「依頼者」の情報には、業務ドメインＤＢ５２（図６）に示されるＩＤが登録される。また、「プロセス定義」の情報には、プロセス定義ＤＢ６２（図９）に示されるＩＤが登録される。
【００３０】
なお、本実施形態では、サーバ装置２２がプロセスエンジン部８６、業務ドメイン管理部９２、プロセス定義管理部９０、業務サービス管理部８８及び作業依頼履歴管理部９４として動作する場合を説明するが、複数の装置で動作するようにしてもよい。例えば、プロセスエンジン部８６、業務ドメイン管理部９２、プロセス定義管理部９０、業務サービス管理部８８及び作業依頼履歴管理部９４の少なくとも一部を別個の装置で動作させてもよい。
【００３１】
クライアント装置６６の各々はＣＰＵ６８、メモリ７０、及び記録部７２を備えている。ＣＰＵ６８、メモリ７０、及び記録部７２は、バス８４を介して互いに接続されている。また、クライアント装置６６の各々は、ディスプレイ等の表示部７６、キーボード及びマウス等の入力部７８を備え、表示部７６及び入力部７８はバス８４に接続されている。また、クライアント装置６６の各々は、挿入された記録媒体６５に対して読み書きするための装置（ＩＯ装置）８０がバス６４に接続されている。また、クライアント装置６６の各々はコンピュータネットワーク２１に接続するための通信制御部８２を備え、通信制御部８２はバス８４に接続されている。
【００３２】
記録部７２には、操作プログラム７４が記憶されている。操作プログラム７４は、依頼、受領、及び管理の各々に関する処理ルーチンを含んでいる。クライアント装置６６は、業務の依頼者、依頼の受領者、及び業務ドメインの管理者の各々により操作される。クライアント装置６６では、ＣＰＵ６８が操作プログラム７４を記録部７２から読み出してメモリ７０に展開し、操作プログラム７４に含まれる依頼に関する処理ルーチンを実行することで、クライアント装置６６は図３に示す依頼装置６６Ａとして動作する。また、ＣＰＵ６８が操作プログラム７４に含まれる受領に関する処理ルーチンを実行することで、クライアント装置６６は図３に示す受領装置６６Ｂとして動作する。さらに、ＣＰＵ６８が操作プログラム７４に含まれる管理に関する処理ルーチンを実行することで、クライアント装置６６は図３に示す管理装置６６Ｃとして動作する。
【００３３】
依頼装置６６Ａでは、作業の依頼、作業状態の変更、及びプロセス定義の編集の何れかの処理における操作が行われる。受領装置６６Ｂでは、作業の受領、作業状態の変更、及びプロセス定義の編集の何れかの処理における操作が行われる。管理装置６６Ｃでは、業務ドメインの登録、及び業務サービスの登録の何れかの処理における操作が行われる。
【００３４】
なお、依頼装置６６Ａ、受領装置６６Ｂ、または管理装置６６Ｃの何れかの装置として動作するクライアント装置６６の各部を区別する場合、クライアント装置６６の各部に記号Ａ、Ｂ、Ｃを付与して説明する。
【００３５】
次に、本実施形態の作用を説明する。
【００３６】
ところで、業務を形式化する場合、作業をどの程度詳細に考慮して形式化するのか、形式化後の保守をどの程度考慮して形式化するのか、業務の依頼側と業務の依頼の受領側とで観点が相違する作業をどこまで形式化するのか、の各々を考慮することが好ましい。
【００３７】
そこで、本実施形態では、業務サービスを境界として作業の依頼者及び受領者の各々の関心事を分離して形式化する。つまり、例えば、依頼者側のメンバは、「いつどのような作業を依頼するのか」等の情報を、経験的に取得している。本実施形態では、依頼者側で経験的に取得している情報（所謂ノウハウなど）を、「プロセス定義中の業務サービスを利用する作業項目」として形式化する。また、受領者側のメンバも、「依頼を誰がどのように遂行するのか」等の情報を、経験的に取得している。本実施形態では、受領者側で経験的に取得している情報を、「業務サービスに登録された依頼振り分けルール」として形式化する。依頼者側及び受領者側において経験的に取得している情報を形式化することで、依頼者側と受領者側との各々の情報を切り離して形式化することができる。
【００３８】
図１１に、業務を遂行する処理の全体的な流れの一例を示す。また、図１２〜図１５に、クライアント装置６６及びサーバ装置２２における各部の関係をシーケンスフローとして示す。なお、本実施形態では、業務を遂行する遂行者が、自己が遂行する候補となる業務及び作業の一覧である業務遂行リスト（所謂ＴｏＤｏリスト）を参照して、業務を遂行する場合を説明する。図１６には、業務遂行リスト１０２が表示された画面の一例としてＴｏＤｏ画面１００を示す。
【００３９】
コンピュータシステム１１では、クライアント装置６６のＣＰＵ６８が操作プログラム７４を実行し、サーバ装置２２のＣＰＵ２４が制御プログラム３８を実行する。まず、コンピュータシステム１１では、ステップ２００で、業務を遂行する遂行者自身に関係する業務の確認処理が実行される。つまり、業務を遂行する遂行者は、遂行者自身に関係する業務を確認するために、（図１２に示す工程Ｊ０１）、クライアント装置６６を操作する。クライアント装置６６は、遂行者により入力された情報に基づき、プロセスエンジン部８６へ作業項目リストの取得を要求する情報を出力する（工程Ｊ０２）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８を参照して作業項目リストを生成し、クライアント装置６６へ送信する（工程Ｊ０３）。クライアント装置６６は、プロセスエンジン部８６から送信された作業項目リストを用いて業務遂行リストを生成し、業務遂行リストの操作画面を表示部７６に表示する（工程Ｊ０４）。遂行者は、表示部７６を参照し、業務を確認する（工程Ｊ０５、図１６も参照）。
【００４０】
コンピュータシステム１１では、ステップ２０２で、作業依頼を引き受けるか否かの判断処理が実行され、肯定判断された場合にはステップ２０４で、作業依頼の引き受け処理が実行され、ステップ２０８へ処理が移行される。つまり、遂行者は、クライアント装置６６における業務遂行リストの操作画面を参照し、作業依頼を引き受けるか否かを判断し（図１２に示す工程Ｊ０６）、クライアント装置６６を操作する。作業依頼を引き受けるためにクライアント装置６６が操作された場合（工程Ｊ０７）、クライアント装置６６は、プロセスエンジン部８６へ作業依頼の引き受けを要求する情報を出力する（工程Ｊ０８）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８及び作業依頼履歴ＤＢ６０を用いて作業依頼引受処理を実行し（工程Ｊ０９）、作業依頼引受処理の成功を示す情報をクライアント装置６６へ送信する（工程Ｊ１０）。クライアント装置６６は、プロセスエンジン部８６から送信された情報によりＴｏＤｏ画面１００における業務遂行リスト１０２の作業項目における状態を、「引受待ち」から「開始」に変更し、作業遂行画面１１０を表示部７６に表示する（工程Ｊ１１）。つまり、クライアント装置６６では、図１７に示す作業遂行画面１１０へ画面が遷移される。遂行者は、表示部７６を参照し、業務を確認する（工程Ｊ１８）。なお、図１７に示すように、作業遂行画面１１０は、作業依頼ツールの表示領域１１２と業務検索ルーツの表示領域１１４とを含んでいる。
【００４１】
ステップ２０８では、コンピュータシステム１１が過去に類似の作業依頼が存在するか否かの判断処理を実行し、肯定判断された場合には、ステップ２１０で、類似した作業依頼が達成されたときのプロセス定義を推薦する処理が実行される。プロセス定義の推薦処理は、特定の業務ドメインに新規に作業依頼がなされたときに、最も類似度が高い作業依頼を探索して、探索結果の作業依頼に対して使用したプロセス定義を推薦する処理である。つまり、クライアント装置６６は、作業遂行画面１１０を表示する（図１２に示す工程Ｊ１１）と共に、作業依頼履歴管理部９４へプロセス定義の推薦を要求する情報を出力する（工程Ｊ１２）。作業依頼履歴管理部９４は、作業依頼履歴ＤＢ６０を参照して過去に類似する作業依頼を検索する処理を実行し（工程Ｊ１３）、類似した作業依頼があるとき、プロセス定義管理部９０へプロセス定義の推薦を要求する情報を送信する（工程Ｊ１４）。プロセス定義管理部９０は、作業依頼履歴管理部９４から要求された作業依頼に対応するプロセス定義を取得し（工程Ｊ１５）、取得した情報を推薦するプロセス定義としてクライアント装置６６へ送信する（工程Ｊ１６）。クライアント装置６６は、プロセス定義管理部９０から送信された情報を選択可能に表示部７６へ表示する（工程Ｊ１７）。遂行者は、表示部７６を参照することにより、類似する作業依頼のプロセス定義を確認できる（工程Ｊ１８）。なお、類似した作業依頼がないときは、工程Ｊ２４（図１３）へ処理が移行される。
【００４２】
類似する作業依頼の判定は、次の類似度演算処理によって実行できる。まず、２つの作業依頼の類似度simの演算式を示す。
【数１】
2015114951.tif 000003
ただし、
rn           ： 作業依頼
rvn          ： 作業依頼から生成した特徴ベクトル
cos(rv1,rv2) ： 特徴ベクトルのコサイン類似度
とする。上記の数式により、sim(r1,r2)の値が１に近いほど，２つの作業依頼は類似していると判定する。
【００４３】
また、特徴ベクトルｒｖｎの定義を次に示す。
・特定業務ドメインへの全ての作業依頼について、依頼名、依頼内容、入力情報の各項目名、出力情報の各項目名から形態素解析により、単語を抽出する。
・依頼ｒｎにおける単語ｗｍの重要度Ｖｎｍを次式で定義する。
Ｖｍｎ（ｗｍ,ｒｎ）＝ＴＦ−ＩＤＦ（ｗｍ,ｒｎ）
・特徴ベクトルｒｖｎは，各単語の重要度を項目とする実数ベクトルである。
【数２】
2015114951.tif 000004
ただし、
TFmn        ： 依頼rnに含まれる全単語の内，単語wmが占める割合
IDFm        ： 単語wmの一般性を表す指標
単語wmがより多くの依頼に含まれるほど，この値は小さくなる
Nmn         ： 依頼rnに含まれる，単語wmの個数
ΣkNkn      ： 依頼rnに含まれる全ての単語の総個数
|D|         ： 依頼の総個数
|{d:d∋wm}| ： 単語wmを含むような依頼の総個数
とする。
【００４４】
一方、作業依頼を引き受けることを拒否するためにクライアント装置６６が操作され、ステップ２０２で否定判断された場合、ステップ２０６で、作業依頼の取り下げ処理が実行され、ステップ２００へ処理が戻される。つまり、遂行者は、作業依頼の引き受けを拒否するために、クライアント装置６６を操作し、クライアント装置６６が作業依頼の取り下げの要求を示す情報をプロセスエンジン部８６へ送信する（図１２に示す工程Ｊ１９、Ｊ２０）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８及び作業依頼履歴ＤＢ６０を用いて作業依頼を取り下げる処理を実行し、クライアント装置６６へ送信する（工程Ｊ２１）。クライアント装置６６は、プロセスエンジン部８６からの処理完了を示す情報により、ＴｏＤｏ画面１００における業務遂行リスト１０２の作業項目における状態を、「引受待ち」から「取下」に変更して表示部７６に表示する。遂行者は、表示部７６を参照することで、作業依頼が散り下げられたことを確認できる（工程Ｊ２２）。
【００４５】
次に、コンピュータシステム１１では、ステップ２１２で、推薦したプロセス定義を利用する指示がなされたか否かの判断処理が実行される。ステップ２１２で、肯定判断された場合にはステップ２２０で、推薦したプロセス定義によるワークフローを開始する処理が実行され、ステップ２２２へ処理が移行される。つまり、遂行者は、クライアント装置６６に表示された推薦されたプロセス定義の中のプロセス定義を利用か否かを判断し（図１３に示す工程Ｊ２３）、クライアント装置６６を操作する。プロセス定義を利用するためにクライアント装置６６が操作された場合（工程Ｊ３４）、クライアント装置６６は、プロセスエンジン部８６へプロセス定義を利用してワークフローを開始する要求を示す情報を出力する（工程Ｊ３５）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８及びプロセス定義ＤＢ６２を用いてワークフローを開始する（工程Ｊ３６）。
【００４６】
一方、推薦されたプロセス定義を利用せずにワークフローを開始させるためにクライアント装置６６が操作され、ステップ２１２で否定判断された場合、ステップ２１４で、利用を希望するプロセス定義の検索処理を行うか否かの判断処理が実行される。ステップ２１４で肯定判断された場合、ステップ２１６で、プロセス定義の検索処理が実行される。つまり、遂行者は、利用を希望するプロセス定義を検索するために、クライアント装置６６を操作し、クライアント装置６６がプロセス定義の検索要求を示す情報をプロセス定義管理部９０へ送信する（図１３に示す工程Ｊ２５、Ｊ２６）。プロセス定義管理部９０は、クライアント装置６６からの要求に従って、プロセス定義ＤＢ６２を用いてプロセス定義を検索する処理を実行し、検索結果をクライアント装置６６へ送信する（工程Ｊ２７）。クライアント装置６６は、プロセス定義管理部９０からの検索結果を表示部７６に表示する（工程Ｊ２８）。遂行者は、表示部７６を参照して検索結果を確認し（工程Ｊ２９）、検索結果に含まれるプロセス定義を利用するか否かを判断する（工程Ｊ３０）。プロセス定義を利用する場合、ワークフローを開始する段階へ移行し（工程Ｊ３４）、利用しない場合、プロセス定義を作成する段階へ移行する（工程Ｊ３１）。
【００４７】
ステップ２１４で否定判断された場合、ステップ２１８で、プロセス定義の作成処理が実行される。つまり、遂行者は、プロセス定義を作成するために、クライアント装置６６を操作し、クライアント装置６６がプロセス定義の作成要求を示す情報をプロセス定義管理部９０へ送信する（図１３に示す工程Ｊ３１、Ｊ３２）。プロセス定義管理部９０は、クライアント装置６６からの要求に従って、プロセス定義ＤＢ６２を用いてプロセス定義を作成する処理を実行し、検索結果をクライアント装置６６へ送信する（工程Ｊ３３）。クライアント装置６６は、プロセス定義管理部９０からの情報に基づいてワークフローを開始する処理へ移行する（工程Ｊ３５）。
【００４８】
コンピュータシステム１１では、ワークフローを開始すると、ステップ２２２で、ワークフローの開始条件を満たす作業項目定義が存在するか否かの判断処理が実行される。ステップ２２２で肯定判断された場合にはステップ２２４で、開始条件を満たす作業項目によるワークフローが開始され、ステップ２２６へ処理が移行される。一方、ステップ２２２で否定判断された場合、コンピュータシステム１１では、ステップ２２６へ処理が移行される。つまり、プロセスエンジン部８６は、ワークフローの開始条件を満たす作業項目定義が存在するか否かを判断し（図１４に示す工程Ｊ３７）、肯定判断された場合、作業項目ＤＢ５８を用いて、開始条件を満たす作業項目を開始する（工程Ｊ３８）。工程Ｊ３７で否定判断された場合、プロセスエンジン部８６は、作業項目が遂行されることを待機し、作業項目の遂行待機を示す情報を、クライアント装置６６へ送信する（工程Ｊ３９）。クライアント装置６６は、プロセスエンジン部８６からの情報を表示部７６に表示し、作業項目の遂行を待機する（工程Ｊ４０）。
【００４９】
次に、コンピュータシステム１１では、ステップ２２６で、遂行希望の作業項目が存在するか否かが判断され、否定判断された場合、ステップ２２８で、作業項目定義を追加する処理を行うか否かが判断される。ステップ２２８で否定判断された場合には、ステップ２３４で、ワークフローの完了処理が実行される。つまり、遂行者は、遂行希望の作業項目が存在せず、作業項目定義の追加も希望しない場合（図１４に示す工程Ｊ４１、Ｊ４２で共に否定）、クライアント装置６６を操作する（工程Ｊ４３）。クライアント装置６６は、ワークフローの完了要求を示す情報をプロセスエンジン部８６へ送信する（工程Ｊ４４）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８を用いてワークフローを完了する処理を実行する（工程Ｊ４５）。
【００５０】
一方、作業項目定義の追加処理を行う場合、ステップ２２８で肯定判断され、ステップ２３０で作業項目定義の追加処理が行われた後に、ステップ２３２で、追加された作業項目の開始処理が実行される。つまり、遂行者が作業項目定義の追加も希望する場合（図１５に示す工程Ｊ４６）、クライアント装置６６は、作業項目定義の追加要求を示す情報をプロセスエンジン部８６へ送信する（工程Ｊ４７）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、作業項目ＤＢ５８及びプロセス定義ＤＢ６２を用いて作業項目定義を追加する処理を実行する（工程Ｊ４８）。次に、プロセスエンジン部８６は、作業項目が開始されたことを示す情報（成功通知）を、クライアント装置６６へ送信し（工程Ｊ４９）、クライアント装置６６は、プロセスエンジン部８６からの情報を表示部７６に表示する（工程Ｊ５０）。遂行者は、作業項目が開始されたことを示す情報（成功通知）を参照することにより、作業項目を遂行できる（工程Ｊ５１）。
【００５１】
また、遂行希望の作業項目が存在する場合（ステップ２２６で肯定判断）、ステップ２３６で作業項目が遂行され（詳細は後述）、ステップ２３８へ処理が移行される。コンピュータシステム１１では、ステップ２３８で、完了条件を満たす作業項目が存在するか否かが判断される。ステップ２３８で否定判断される場合、ステップ２２２へ処理が戻され、肯定判断される場合、ステップ２４０で作業項目の完了処理が行われ、ステップ２４２へ処理が移行される。コンピュータシステム１１では、ステップ２４２で、ワークフローを完了するか否かが判断され、否定判断される場合、ステップ２２２へ処理が戻され、肯定判断される場合には処理を終了する。つまり、遂行者は作業項目を遂行した後（図１５に示す工程Ｊ５１）、作業項目の更新を要求するためにクライアント装置６６を操作する（工程Ｊ５２）。クライアント装置６６は、作業項目の更新要求を示す情報をプロセスエンジン部８６へ送信する（工程Ｊ５３）。プロセスエンジン部８６は、クライアント装置６６からの要求に従って、完了条件に合致する作業項目が存在するとき（工程Ｊ５４で肯定）、作業項目ＤＢ５８を用いて作業項目を完了する処理を実行する（工程Ｊ５５）。
【００５２】
次に、コンピュータシステム１１で実行される図１１に示すステップ２３６の処理（作業項目の遂行処理）をさらに説明する。図１８に、作業項目の遂行処理の流れの一例を示す。また、図１９に、作業項目の遂行処理の流れに従ったクライアント装置６６及びサーバ装置２２における各部の関係をシーケンスフローとして示す。
【００５３】
コンピュータシステム１１では、図１１に示すステップ２３６の処理で、図１８に示す作業項目の遂行処理が実行される。まず、コンピュータシステム１１では、ステップ３００で、作業を依頼するか否かの判断処理が実行され、否定判断の場合、ステップ３０８へ処理が移行される。一方、ステップ３００で肯定判断された場合、ステップ３０２で作業を依頼する処理（詳細は後述）が実行され、次のステップ３０４で、作業依頼の成否を記録する処理が実行される。次に、ステップ３０６では、再依頼するか否かの判断処理が実行され、肯定判断の場合、ステップ３００へ処理が戻され、否定判断の場合、ステップ３０８へ処理が移行される。つまり、遂行者は、作業を依頼するか否かを判断し（図１９に示す工程Ｋ０１）、作業を依頼する場合にクライアント装置６６を操作する（工程Ｋ０２）。クライアント装置６６は、作業依頼履歴管理部９４へ依頼の成否の記録を要求する情報を出力する（工程Ｋ０３）。作業依頼履歴管理部９４は、クライアント装置６６からの要求に従って、作業依頼履歴ＤＢ６０を用いて依頼の成否を記録する（工程Ｋ０４）。また、遂行者は、作業を依頼した後、再依頼するか否かを判断し（工程Ｋ０５）、再依頼するときは工程Ｋ０２へ戻る。
【００５４】
なお、ステップ３０４における、作業依頼の成否を記録する処理では、依頼元の作業項目と、依頼先のプロセス定義によるプロセスとの両方が失敗せずに完了したときに、作業依頼が成功したものとして記録する。また、ステップ３０４では、依頼元で使用された作業項目定義、依頼先で使用されたプロセス定義、及び依頼先で使用された依頼振り分けルールの各々も記録される。
【００５５】
ステップ３０８では、コンピュータシステム１１が出力情報の追加処理を実行するか否かの判断処理を実行し、肯定判断された場合には、ステップ３１０で、出力情報を追加する処理が実行された後、ステップ３０８へ処理が戻される。つまり、遂行者は、出力情報の追加処理を実行するか否かを判断し（図１９に示す工程Ｋ０６）、クライアント装置６６を操作する。クライアント装置６６は、作業遂行画面１１０を表示し（図１７）、遂行者により（図１７に示す作業依頼ツールの表示領域１１２に対して）入力された出力情報を追加する処理を実行する（工程Ｋ０７）。
【００５６】
次に、コンピュータシステム１１では、ステップ３１２で、明示的に作業項目を完了する処理を行うか否かが判断され、肯定判断された場合、ステップ３１４で、作業項目の完了要求処理が実行され、ステップ３１６へ処理が移行される。ステップ３１２で否定判断された場合には、ステップ３１６へ処理が移行される。ステップ３１６では、作業項目定義の更新処理が実行される。つまり、遂行者は、作業項目を完了するか否かを判断し（図１９に示す工程Ｋ０８）、作業項目の完了を要求するためにクライアント装置６６を操作する（工程Ｋ０９）。クライアント装置６６は、要求に応じて作業項目の状態を「完了」に変更する（工程Ｋ１０）。一方、遂行者が、作業項目を完了しないとの判断の場合（工程Ｋ０８で否定）、作業項目定義の更新を要求するためにクライアント装置６６を操作する（工程Ｋ１１）。クライアント装置６６は、プロセス定義管理部９０へ作業項目定義の更新要求を示す情報を送信する（工程Ｋ１２）。プロセス定義管理部９０は、クライアント装置６６からの要求に従って、プロセス定義ＤＢ６２を用いて作業項目定義の更新する（工程Ｋ１３）。
【００５７】
コンピュータシステム１１では、図１８に示すステップ３０２の処理で、図２０に示す作業依頼処理が実行される。なお、図２１に、作業依頼処理における各部の関係をシーケンスフローとして示す。まず、コンピュータシステム１１では、ステップ３２０で、入力情報、出力情報、及び依頼内容の設定処理が実行される。次に、ステップ３２２では、業務サービスを利用するか否かの判断処理が実行され、肯定判断の場合、ステップ３２４で業務サービスの検索処理が実行された後に、業務サービスへの依頼処理が実行される。つまり、遂行者は、入力情報、出力情報、及び依頼内容を設定し（図２１に示す工程Ｋ２０）、業務サービスを利用するか否かを判断する（工程Ｋ２１）。遂行者は、業務サービスを利用する場合、業務サービスを検索するためにクライアント装置６６を操作する（工程Ｋ２９）。クライアント装置６６は、業務サービス管理部８８へ業務サービスの検索を要求する情報を出力する（工程Ｋ３０）。業務サービス管理部８８は、クライアント装置６６からの要求に従って、業務サービスＤＢ５４を用いて、要求された業務サービスを検索し、検索結果をクライアント装置６６へ送信する（工程Ｋ３１）。クライアント装置６６は、業務サービス管理部８８から送信された情報を選択可能に表示部７６へ表示する（工程Ｋ３２）。つまり、クライアント装置６６は、作業遂行画面１１０の業務検索ツール内の検索結果の領域に、業務サービス管理部８８から送信された情報を業務サービス利用画面として表示する。遂行者は、表示部７６を参照することにより、利用する業務サービスを確認し、クライアント装置６６を操作する（工程Ｋ３３）。クライアント装置６６は、業務サービス管理部８８へ業務サービスへの依頼を要求する情報を出力する（工程Ｋ３４）。業務サービス管理部８８は、クライアント装置６６からの要求に従って、業務サービスＤＢ５４を用いて、要求された業務サービスへの依頼を行う（工程Ｋ３５）。また、業務サービス管理部８８は、プロセスエンジン部８６へ業務ドメインへ依頼したことを示す情報を出力する。プロセスエンジン部８６は、依頼された業務サービスの成功または失敗を待機する（工程Ｋ３６）。
【００５８】
一方、ステップ３２２で否定判断された場合、ステップ３２８で業務ドメインを検索する処理が実行された後に、ステップ３３０で、業務ドメインへの依頼処理が実行される。コンピュータシステム１１では、ステップ３３２で、依頼が成功するまで、または失敗するまで処理が待機される。つまり、一方、遂行者は、業務サービスを利用しない場合、業務ドメインを検索するためにクライアント装置６６を操作する（工程Ｋ２２）。クライアント装置６６は、業務ドメイン管理部９２へ業務ドメインの検索を要求する情報を出力する（工程Ｋ２３）。業務ドメイン管理部９２は、クライアント装置６６からの要求に従って、業務ドメインＤＢ５２を用いて、要求された業務ドメインを検索し、検索結果をクライアント装置６６へ送信する（工程Ｋ２４）。クライアント装置６６は、業務ドメイン管理部９２から送信された情報を選択可能に表示部７６へ表示する（工程Ｋ２５）。つまり、クライアント装置６６は、作業遂行画面１１０の業務検索ツール内の検索結果の領域に、業務ドメイン管理部９２から送信された情報を業務ドメインへの依頼画面として表示する。遂行者は、表示部７６を参照することにより、利用する業務ドメインを確認し、クライアント装置６６を操作する（工程Ｋ２６）。クライアント装置６６は、業務ドメイン管理部９２へ業務ドメインへの依頼を要求する情報を出力する（工程Ｋ２７）。業務ドメイン管理部９２は、クライアント装置６６からの要求に従って、業務ドメインＤＢ５２を用いて、要求された業務サービスへの依頼を行う（工程Ｋ２８）。また、業務ドメイン管理部９２は、プロセスエンジン部８６へ業務ドメインへ依頼したことを示す情報を出力する。プロセスエンジン部８６は、依頼された業務サービスの成功または失敗を待機する（工程Ｋ３６）。
【００５９】
図２２に、業務サービスへの依頼に関係する情報の流れの一例を示す。依頼側の業務の遂行者（依頼者）であるメンバ１２０は、プロセス定義１２２に、新規の作業項目定義を追加して、業務サービス１２４へ作業依頼を行う。業務サービス１２４は、振り分けルール１２６及びプロセス定義１２８が関連付けられている。業務サービス１２４への依頼に対して、振り分けルール１２６に従って、受領者が設定される。つまり、業務サービス１２４には、業務サービス１２４を遂行可能な業務ドメイン１３０が設定されており、業務ドメイン１３０に登録されたメンバ１３４，１３６に依頼を振り分ける規則が、振り分けルール１２６に設定される。なお、業務ドメイン１３０では、業務ドメイン１３０に対する振り分けルール１３２が関連付けられている。図２２では、メンバ１３６に依頼を振り分けるルールが規則が、振り分けルール１２６に設定される例である。メンバ１３６には、プロセス定義１２８に従って作業項目１３８が依頼される。なお、メンバ１３６は、作業項目１３８の依頼を引き受けるか、または取り下げるかを選択できる。従って、依頼側は、プロセス定義１２２を管理すればよく、受領側は、プロセス定義１２８を管理すればよい。
【００６０】
図２３に、業務ドメインへの依頼に関係する情報の流れの一例を示す。依頼側の業務の遂行者（依頼者）であるメンバ１２０は、プロセス定義１２２に、新規の作業項目定義を追加して、業務ドメイン１３０へ作業依頼を行う。業務ドメイン１３０は、振り分けルール１３２が関連付けられている。業務ドメイン１３０への依頼に対して、振り分けルール１３２に従って、受領者が設定される。例えば、業務ドメイン１３０に関連づけられた振り分けルール１３２に従ってメンバ１３６に依頼が転送される。メンバ１３６では、プロセス定義１２９が新規に生成され、生成されたプロセス定義１２９に従って作業項目１３８が依頼される。なお、メンバ１３６は、作業項目１３８の依頼を引き受けるか、または取り下げるかを選択できる。従って、依頼側は、プロセス定義１２２を管理すればよく、受領側は、プロセス定義１２９を管理すればよい。
【００６１】
次に、コンピュータシステム１１による業務サービスの提案について説明する。図２４に、業務サービスの提案処理の流れの一例を示す。また、図２５、及び図２６に、業務サービスの提案に関係するクライアント装置６６及びサーバ装置２２における各部の関係をシーケンスフローとして示す。なお、図２４に示す業務サービスの提案処理は、コンピュータシステム１１において定期的に実行される。
【００６２】
まず、コンピュータシステム１１では、ステップ４００で、同一業務ドメインに対して類似する作業依頼が閾値回数以上成功したか否かの判断処理が実行され、否定判断された場合には本ルーチンを終了する。ステップ４００で、肯定判断された場合には、ステップ４０２へ処理が移行される。つまり、作業依頼履歴管理部９４は、作業依頼履歴ＤＢ６０を参照し、同一業務ドメインに対して閾値回数以上成功した類似する作業依頼が存在するか否かを判断する（図２５に示す工程Ｌ０１）。作業依頼履歴管理部９４は、類似する作業依頼が閾値回数未満のとき処理を終了する。
【００６３】
なお、ステップ４００は、次式を満たす依頼ｒｎが存在する場合に肯定判断することができる。
【数３】
2015114951.tif 000005
ただし、
rs         ： 類似比較の対象となる依頼
sim(rn,rs) ： 依頼rnとrsの類似度．前記[数１]で説明した数式
sim_th     ： 類似しているかどうかを判断するための閾値である実数
類似度がこの値よりも大きければ，十分に類似していると判断される
freq_th    ： 依頼が頻出しているかどうかを判断するための閾値である実数
類似する依頼の個数がこの値よりも大きければ，十分に頻出している
と判断される
とする。
【００６４】
成功した類似する作業依頼が閾値回数以上のとき、コンピュータシステム１１では、ステップ４０２で、推薦する業務サービスの設定が生成され、次のステップ４０４で、業務ドメインの管理者に向けて業務サービスの作成及び公開の依頼が行われる。つまり、作業依頼履歴管理部９４は、推薦する業務サービスの設定を生成し（工程Ｌ０２）、業務ドメイン管理部９２へ、業務サービスの作成及び公開の依頼を要求する。業務ドメイン管理部９２は、業務ドメインＤＢ５２を用いて、業務ドメインの管理者へ業務サービスの作成及び公開を依頼する（工程Ｌ０３）。つまり、業務ドメイン管理部９２は、業務ドメインの管理者のクライアント装置６６（管理装置６６Ｃ）へ依頼を示す情報を出力する。クライアント装置６６（管理装置６６Ｃ）は、業務ドメイン管理部９２からの情報を表示部７６へ表示し、遂行者である業務ドメインの管理者に確認を要求する（工程Ｌ０４）。
【００６５】
ステップ４０２における業務サービスの設定を生成する処理では、次の条件が適用される。第１条件は、依頼ｒｎの依頼先業務ドメインを業務サービスの公開場所とし、依頼ｒｎの依頼先で使用された依頼振り分けルールを業務サービスの依頼振り分けルールとすることである。第２条件は、依頼元の依頼ｒｓの依頼元業務ドメインを、業務サービスの公開範囲とすることである。但し、所有関係にある業務ドメインの内、予め定めた閾値割合以上を依頼元の業務ドメインが占める業務ドメインも公開範囲に含めることができる。第３条件は、依頼ｒｎで依頼先が使用したプロセス定義で、最初の作業項目定義の入力情報を業務サービスの設定の入力情報とし、最後の作業項目定義の出力情報を業務サービス設定の出力情報とし、プロセス定義の名称を業務サービスの名称とすることである。
【００６６】
次に、コンピュータシステム１１では、ステップ４０６で、業務ドメインの管理者が依頼を引き受けたか否かが判断され、否定判断された場合、本ルーチンを終了し、肯定判断された場合、ステップ４０８へ処理が移行される。ステップ４０８では、推薦された業務サービスの設定を修正し、業務サービスを作成して公開する処理が実行される。次のステップ４１０では、類似する作業依頼について、依頼元の作業項目定義を見つけ、依頼元の業務ドメインに作業項目の書き換えを依頼する処理が実行される。つまり、遂行者は、業務ドメイン管理部９２から要求された依頼を引き受けるか否かを判断し（図２５に示す工程Ｌ０５）、引き受ける場合、業務サービスの作成及び公開を要求するためにクライアント装置６６を操作する（工程Ｌ０６）。クライアント装置６６は、要求に応じて、推薦された業務サービスの設定を修正し、業務サービスを作成及び公開することを示す情報を業務サービス管理部８８へ出力する（工程Ｌ０７）。業務サービス管理部８８は、業務サービスＤＢ５４に、要求された業務サービスを新規に登録する処理を実行し、作業依頼履歴管理部９４へ通知する（工程Ｌ０８）。作業依頼履歴管理部９４は、業務サービス管理部８８からの通知により、類似の作業依頼について依頼元の作業項目定義を見つけて依頼元の業務ドメインに作業項目の書き換えを依頼する要求を、クライアント装置６６へ出力する（工程Ｌ０９）。クライアント装置６６は、作業依頼履歴管理部９４からの情報を表示部７６へ表示し、遂行者である業務ドメインの管理者に確認を要求する（工程Ｌ１０）。
【００６７】
また、コンピュータシステム１１では、ステップ４１２で、業務ドメインの管理者が依頼を引き受けたか否かが判断され、否定判断された場合、本ルーチンを終了し、肯定判断された場合、ステップ４１４へ処理が移行される。ステップ４１４では、業務ドメインに依頼している作業項目定義を業務サービスへの依頼に書き換える要求処理が実行される。つまり、遂行者は、作業依頼履歴管理部９４から要求された依頼を引き受けるか否かを判断し（図２６に示す工程Ｌ１１）、引き受ける場合、作業項目定義の書き換えを要求するためにクライアント装置６６を操作する（工程Ｌ１２）。クライアント装置６６は、要求に応じて、業務ドメインに依頼の作業項目定義を業務サービスへの依頼に書き換える要求を示す情報をプロセス定義管理部９０へ出力する（工程Ｌ１３）。プロセス定義管理部９０は、プロセス定義ＤＢ６２に、要求された作業項目定義を書き換える処理を実行し、作業依頼履歴管理部９４へ通知する（工程Ｌ１４）。
【００６８】
さらに、コンピュータシステム１１では、ステップ４１６で、類似の作業依頼を処理する業務サービスが複数存在するか否かが判断され、否定判断された場合、本ルーチンを終了し、肯定判断された場合、ステップ４１８へ処理が移行される。ステップ４１８では、上位業務サービスの公開の依頼の要求処理が実行される。つまり、作業依頼履歴管理部９４は、プロセス定義管理部９０からの通知により、作業依頼履歴ＤＢ６０を参照し、類似の作業依頼を処理する業務サービスが複数存在するか否かを判断する（工程Ｌ１５）。作業依頼履歴管理部９４は、類似の作業依頼を処理する業務サービスが複数存在する場合、上位の業務サービスの公開を依頼する要求を、クライアント装置６６へ出力する（工程Ｌ１６）。クライアント装置６６は、作業依頼履歴管理部９４からの情報を表示部７６へ表示し、遂行者である業務ドメインの管理者に確認を要求する（工程Ｌ１７）。
【００６９】
次に、コンピュータシステム１１では、ステップ４２０で、業務ドメインの管理者が依頼を引き受けたか否かが判断され、否定判断された場合、本ルーチンを終了し、肯定判断された場合、ステップ４２２へ処理が移行される。ステップ４２２では、上位業務サービスを作成して公開する処理が実行される。つまり、遂行者は、作業依頼履歴管理部９４から要求された依頼を引き受けるか否かを判断し（図２６に示す工程Ｌ１８）、引き受ける場合、上位業務サービスの作成及び公開を要求するためにクライアント装置６６を操作する（工程Ｌ１９）。クライアント装置６６は、要求に応じて、上位業務サービスの作成及び公開することを示す情報を業務サービス管理部８８へ出力する（工程Ｌ２０）。業務サービス管理部８８は、業務サービスＤＢ５４に、要求された上位業務サービスを新規に登録する処理を実行する（工程Ｌ２１）。
【００７０】
図２７に、業務サービスの提案処理（図２４）で、提案対象とする業務サービスを特定するときの情報の一例を示す。まず、作業依頼履歴ＤＢ６０のデータを基にして、類似する作業依頼が閾値回数以上成功し、特定の業務ドメインに対して直接行われた作業依頼の関連情報を、各ＤＢから抽出して外部結合するテーブルを生成する。図２７に、外部結合したテーブルとして結合テーブル１４０を示す。また、図２７に、結合テーブル１４０に対応し、閾値回数以上成功した類似する作業依頼の判定に用いる類似度テーブル１４２も示す。図２７に示す例で、閾値を０．５とした場合、最も他の依頼履歴と類似度の合計が大きい、ＩＤ５０２の依頼履歴が代表となる。
【００７１】
図２８に、業務サービスの提案処理（図２４）で、業務サービスの設定を生成するときの情報の一例を示す。まず、作業依頼履歴ＤＢ６０のデータを基にして生成された結合テーブル１４０（図２７）から、推薦する業務サービスの設定が生成される。図２８に、推薦する業務サービスの設定を示す情報１４４を示す。情報１４４は、ＩＤ５０２の依頼を対象とする場合、振り分けルールが２００になる。また、全依頼元は「１０１，１０３」であり、業務ドメインのＩＤ１００に含まれるメンバの２／３を占めるため、業務ドメインは、ＩＤ１００になる。さらに、依頼ｒｎ＝ＩＤ５０２は依頼先のプロセス定義としてＩＤ４０２を利用することになる。つまり、入力情報が（スペイン語原稿、文書、期限、年月日時)となり、出力情報が（コメント、文字列、校正後文書、文書)となり、名称が（スペイン語原稿のチェック）となる。次に、情報１４４から業務サービスを設定するための情報１４６が生成される。業務サービスを設定するための情報１４６は、名称が「スペイン語原稿のチェック」、公開元が「１０２（業務ドメインＤＢ５２内のＩＤ）」、及び公開範囲が「１００（業務ドメインＤＢ５２内のＩＤ）」の各情報を含む。また、情報１４６は、振分ルールが「２００（振り分けルールＤＢ５６内のＩＤ）」、プロセス定義が「４０２（プロセス定義ＤＢ６２内のＩＤ）」の各情報を含む。さらに、情報１４６は、入力情報が「スペイン語原稿：文書，期限：年月日時」、出力情報が「コメント：文字列，校正後文書：文書」、タイプが「非公式」の各情報を含む。
【００７２】
図２９に、業務サービスの作成及び提案に関係する情報の流れの一例を示す。まず、作業依頼履歴ＤＢ６０を分析することで、類似する依頼がなされることが予測される業務サービス設定１５２を生成する処理１５０が実行される。生成された業務サービス設定１５２は、処理１５４により業務ドメインの管理者に提案される。処理１５４による提案が、業務ドメインの管理者に引き受けられると、新規の業務サービスが公開される。また、作業依頼履歴ＤＢ６０を分析することで、特定の業務サービスの元となる依頼履歴と類似する依頼履歴が特定される。特定された依頼履歴に含まれるプロセス定義に登録される業務サービスの管理者に、業務サービス１５６の利用を提案する処理１５８が実行される。これにより、業務サービスを増大することを抑止することができる。
【００７３】
図３０に、業務サービスの統合の提案に関係する情報の流れの一例を示す。まず、作業依頼履歴ＤＢ６０を分析することで、類似する依頼を受領している業務サービス１６０，１６２が特定される。次に、特定された業務サービス１６０，１６２を公開している複数の業務ドメイン１６４，１６６に対して，新規に上位の業務ドメイン１６８を作成し、総合窓口となる業務サービス１７２を公開することを提案する処理１７０が実行される。このように、類似する依頼を受領している複数の業務サービスを網羅した業務サービスが生成されることによって、業務ドメイン間でメンバの連携を実現できる。
【００７４】
図３１に、コンピュータシステム１１における継続的な情報の流れの一例を示す。本実施形態に係るコンピュータシステム１１は、業務の遂行と、業務及び組織の改善に寄与する。つまり、業務の遂行では、依頼者が作業を依頼すること、受領者が作業依頼を受領することの各々が繰り返される。つまり、業務の遂行では，依頼、受領、遂行の繰り返しにより，プロセス定義が追加または更新される。従って業務サービスを用いて、僅かな記述によるプロセス定義でワークフローを運用することができる。また、業務及び組織の観点では、業務サービスの公開を提案、提案された業務サービスを公開、業務サービスの統合、業務サービスの利用、及びプロセス定義の更新の各々が独立して実行される。従って、業務及び組織の改善では，業務の履歴の分析から，依頼のための記述を抑制したり，効率的な依頼、受領、及び遂行に寄与するように，業務サービスを組織的に構築することができる。
【００７５】
効果：メイン
以上説明したように、本実施形態では、業務サービスを境界として、依頼者側及び受領者側において経験的に取得している情報を形式化する。このため、依頼者側は受領者側の状況を考慮せずにプロセス定義を作成でき、受領者側は受領者側の状況を考慮してルールを管理すればよく、管理の煩雑さを抑制できる。また、受領者側の状況が変化した場合であっても、業務サービスの入出力データが変化しない限り、依頼者側のプロセス定義は維持することができ、保守工数の増大を抑制できる。
【００７６】
また、受領者側で、既存の業務サービスを利用する場合、類似した作業項目を含むプロセス定義の増大に伴って、プロセス定義の保守を実行する工数が増大する。また、類似した依頼であっても各々の依頼に個別に対応するために依頼を遂行する工数が増大する。本実施形態では、受領者側で既存の業務サービスを利用することにより、プロセス定義の保守の工数が抑制され、依頼を遂行する工数が抑制される。つまり、依頼者側のプロセス定義は、業務サービスが遂行される内容に影響されることはない。また、受領者側では、経験的に取得している情報に応じた依頼の形式に統一される依頼となる。
【００７７】
さらに、本実施形態では、依頼側及び受領側において共通の作業または類似の作業を形式化したプロセス定義を生成するので、プロセス定義の増大を抑制することができる。
【００７８】
さらにまた、本実施形態では、業務サービスとして、依頼側及び受領側の各々において入出力される情報を独立して定義するので、依頼側及び受領側の各々のプロセス定義を独立して管理することができる。
【００７９】
本実施形態では、業務サービスに作業者の集合を示す業務ドメインを関連付けるので、組織単位でプロセス定義を管理することができる。
【００８０】
また、本実施形態では、業務サービスに、依頼を振り分ける振分規則を関連付けるので、振分規則に従って迅速に依頼することができる。
【００８１】
さらに、本実施形態では、依頼に基づく業務の依頼の遂行が成功した業務の依頼履歴を記憶するので、依頼の遂行が成功した有効な依頼履歴を利用することができる。
【００８２】
さらにまた、本実施形態では、依頼履歴に基づき、類似した業務に関する業務サービスを提案するので、継続的に使用することが予測される業務サービスを高精度で採用することができる。
【００８３】
また、本実施形態では、複数の業務サービスについて上位の業務サービスを生成して提案するので、業務サービスの利用者を増加させることができる。
【００８４】
なお、上記では業務形式化装置１０をサーバ装置２２により実現する一例を説明した。しかし、これらの構成に限定されるものではなく、上記説明した要旨を逸脱しない範囲において、各種の改良及び変更を行っても良いのはもちろんである。
【００８５】
また、上記ではプログラムが記憶部に予め記憶（インストール）されている態様を説明したが、これに限定されるものではない。例えば、開示の技術におけるプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。
【００８６】
本明細書に記載された全ての文献、特許出願及び技術規格は、個々の文献、特許出願及び技術規格が参照により取り込まれることが具体的かつ個々に記された場合と同程度に、本明細書中に参照により取り込まれる。
【００８７】
以上の実施形態に関し、更に以下の付記を開示する。
【００８８】
（付記１）
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部に蓄積し、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、
前記作業群毎に前記業務を形式化したプロセス定義を生成し、
前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
ことを含む処理をコンピュータに実行させるための業務形式化プログラム。
【００８９】
（付記２）
前記複数の作業群は、前記業務の依頼に関係する作業を含む作業群と、前記業務の依頼の遂行に関係する作業を含む作業群とを含み、
前記業務の依頼に共通の作業または類似の作業を形式化したプロセス定義、及び前記業務の依頼の遂行に共通の作業または類似の作業を形式化したプロセス定義を生成する
付記１に記載の業務形式化プログラム。
【００９０】
（付記３）
前記業務サービスは、前記複数の作業群間で入出力される情報を、前記複数の作業群の各々で入出力される情報として定義した情報を含む
付記１または付記２に記載の業務形式化プログラム。
【００９１】
（付記４）
前記業務サービスは、前記業務の依頼に関係する作業、及び前記業務の依頼の遂行に関係する作業の少なくとも一方の作業を行う作業者の集合を示す業務ドメインを、前記複数の作業群に含まれる少なくとも１つの作業群に関連付ける情報を含む
付記１〜付記３の何れか１項に記載の業務形式化プログラム。
【００９２】
（付記５）
前記業務サービスは、前記業務の依頼を、前記業務の依頼の遂行の作業を行う作業者または前記業務ドメインに振り分ける振分規則を含む
付記４に記載の業務形式化プログラム。
【００９３】
（付記６）
前記依頼履歴は前記業務の依頼の遂行の成否を示す情報を含み、
前記記憶部に蓄積された依頼履歴に基づいて、前記依頼に基づく前記業務の依頼の遂行が成功した前記業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記１〜付記５の何れか１項に記載の業務形式化プログラム。
【００９４】
（付記７）
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記１〜付記６の何れか１項に記載の業務形式化プログラム。
【００９５】
（付記８）
前記依頼履歴は前記業務の依頼の遂行に関係する作業を行う作業者を示す情報を含み、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の複数の業務の依頼の遂行に関係する作業を行う作業者の集合を示す上位業務ドメインを作成し、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の依頼の遂行に関係する作業を含む作業群に、前記上位業務ドメインを関連付けた上位業務サービスを生成する、
付記１〜付記７の何れか１項に記載の業務形式化プログラム。
【００９６】
（付記９）
コンピュータが、
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を記憶部に蓄積し、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、
前記作業群毎に前記業務を形式化したプロセス定義を生成し、
前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
ことを含む業務形式化方法。
【００９７】
（付記１０）
前記複数の作業群は、前記業務の依頼に関係する作業を含む作業群と、前記業務の依頼の遂行に関係する作業を含む作業群とを含み、
前記業務の依頼に共通の作業または類似の作業を形式化したプロセス定義、及び前記業務の依頼の遂行に共通の作業または類似の作業を形式化したプロセス定義を生成する
付記９に記載の業務形式化方法。
【００９８】
（付記１１）
前記業務サービスは、前記複数の作業群間で入出力される情報を、前記複数の作業群の各々で入出力される情報として定義した情報を含む
付記９または付記１０に記載の業務形式化方法。
【００９９】
（付記１２）
前記業務サービスは、前記業務の依頼に関係する作業、及び前記業務の依頼の遂行に関係する作業の少なくとも一方の作業を行う作業者の集合を示す業務ドメインを、前記複数の作業群に含まれる少なくとも１つの作業群に関連付ける情報を含む
付記９〜付記１１の何れか１項に記載の業務形式化方法。
【０１００】
（付記１３）
前記業務サービスは、前記業務の依頼を、前記業務の依頼の遂行の作業を行う作業者または前記業務ドメインに振り分ける振分規則を含む
付記１２に記載の業務形式化方法。
【０１０１】
（付記１４）
前記依頼履歴は前記業務の依頼の遂行の成否を示す情報を含み、
前記記憶部に蓄積された依頼履歴に基づいて、前記依頼に基づく前記業務の依頼の遂行が成功した前記業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記９〜付記１３の何れか１項に記載の業務形式化方法。
【０１０２】
（付記１５）
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記９〜付記１４の何れか１項に記載の業務形式化方法。
【０１０３】
（付記１６）
前記依頼履歴は前記業務の依頼の遂行に関係する作業を行う作業者を示す情報を含み、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の複数の業務の依頼の遂行に関係する作業を行う作業者の集合を示す上位業務ドメインを作成し、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の依頼の遂行に関係する作業を含む作業群に、前記上位業務ドメインを関連付けた上位業務サービスを生成する、
付記９〜付記１５の何れか１項に記載の業務形式化方法。
【０１０４】
（付記１７）
各々複数の作業を含みかつ各々依頼に基づく複数の業務の各々の依頼履歴を蓄積する記憶部と、
前記業務を、前記記憶部に蓄積された依頼履歴に基づいて、複数の作業群と、前記業務の内容を示しかつ前記複数の作業群間の関係を規定する業務サービスとに分離し、前記作業群毎に前記業務を形式化したプロセス定義を生成し、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する制御部と、
を備えた業務形式化装置。
【０１０５】
（付記１８）
前記複数の作業群は、前記業務の依頼に関係する作業を含む作業群と、前記業務の依頼の遂行に関係する作業を含む作業群とを含み、
前記制御部は、前記業務の依頼に共通の作業または類似の作業を形式化したプロセス定義、及び前記業務の依頼の遂行に共通の作業または類似の作業を形式化したプロセス定義を生成する
付記１９に記載の業務形式化装置。
【０１０６】
（付記１９）
前記業務サービスは、前記複数の作業群間で入出力される情報を、前記複数の作業群の各々で入出力される情報として定義した情報を含む
付記１９または付記２０に記載の業務形式化装置。
【０１０７】
（付記２０）
前記業務サービスは、前記業務の依頼に関係する作業、及び前記業務の依頼の遂行に関係する作業の少なくとも一方の作業を行う作業者の集合を示す業務ドメインを、前記複数の作業群に含まれる少なくとも１つの作業群に関連付ける情報を含む
付記１９〜付記２１の何れか１項に記載の業務形式化装置。
【０１０８】
（付記２１）
前記業務サービスは、前記業務の依頼を、前記業務の依頼の遂行の作業を行う作業者または前記業務ドメインに振り分ける振分規則を含む
付記２０に記載の業務形式化装置。
【０１０９】
（付記２２）
前記依頼履歴は前記業務の依頼の遂行の成否を示す情報を含み、
前記制御部は、前記記憶部に蓄積された依頼履歴に基づいて、前記依頼に基づく前記業務の依頼の遂行が成功した前記業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記１９〜付記２３の何れか１項に記載の業務形式化装置。
【０１１０】
（付記２３）
前記制御部は、前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の業務について、前記業務サービスを示す情報、及び前記プロセス定義を示す情報を前記記憶部に記憶する
付記１９〜付記２４の何れか１項に記載の業務形式化方法。
【０１１１】
（付記２４）
前記依頼履歴は前記業務の依頼の遂行に関係する作業を行う作業者を示す情報を含み、
前記制御部は、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の類似度を求め、前記業務の類似度が所定値以上の複数の業務の依頼の遂行に関係する作業を行う作業者の集合を示す上位業務ドメインを作成し、
前記記憶部に蓄積された依頼履歴に基づいて、前記業務の依頼の遂行に関係する作業を含む作業群に、前記上位業務ドメインを関連付けた上位業務サービスを生成する、
付記１０〜付記１６の何れか１項に記載の業務形式化装置。
【符号の説明】
【０１１２】
１０    業務形式化装置
１１    コンピュータシステム
１２    ＣＰＵ
１４    メモリ
１６    業務形式化プログラム
１８    制御部
２０    記憶部
２２    サーバ装置
２４    ＣＰＵ
２６    メモリ
２８    表示部
３０    入力部
３６    格納部
３８    制御プログラム
４０    エンジン処理ルーチン
４２    業務ドメイン管理処理ルーチン
４４    定義管理処理ルーチン
４６    業務サービス管理処理ルーチン
４８    作業履歴管理処理ルーチン
５０    データベース
５２    業務ドメインデータベース
５４    業務サービスデータベース
５６    振り分けルールデータベース
５８    作業項目データベース
５９    作業項目定義データベース
６０    作業依頼履歴データベース
６２    プロセス定義データベース
６５    記録媒体
６６    クライアント装置
８６    プロセスエンジン部
８８    業務サービス管理部
９０    プロセス定義管理部
９２    業務ドメイン管理部
９４    作業依頼履歴管理部
【図１】
2015114951.tif 000006
【図２】
2015114951.tif 000007
【図３】
2015114951.tif 000008
【図４】
2015114951.tif 000009
【図５】
2015114951.tif 000010
【図６】
2015114951.tif 000011
【図７】
2015114951.tif 000012
【図８】
2015114951.tif 000013
【図９】
2015114951.tif 000014
【図１０】
2015114951.tif 000015
【図１１】
2015114951.tif 000016
【図１２】
2015114951.tif 000017
【図１３】
2015114951.tif 000018
【図１４】
2015114951.tif 000019
【図１５】
2015114951.tif 000020
【図１６】
2015114951.tif 000021
【図１７】
2015114951.tif 000022
【図１８】
2015114951.tif 000023
【図１９】
2015114951.tif 000024
【図２０】
2015114951.tif 000025
【図２１】
2015114951.tif 000026
【図２２】
2015114951.tif 000027
【図２３】
2015114951.tif 000028
【図２４】
2015114951.tif 000029
【図２５】
2015114951.tif 000030
【図２６】
2015114951.tif 000031
【図２７】
2015114951.tif 000032
【図２８】
2015114951.tif 000033
【図２９】
2015114951.tif 000034
【図３０】
2015114951.tif 000035
【図３１】
2015114951.tif 000036